Kotlin Multiplatform（KMP）のシステム発注は、業務課題と共通化の範囲を整理し、PoCで技術を確かめ、契約と保守の条件を合意する順に進めます。この順で進めると、発注先と費用の前提を揃えやすくなります。
全体像は、下に挙げた完全ガイドでも確認できます。
▼全体ガイドの記事
・Kotlin Multiplatformのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
Kotlin Multiplatformのシステムを発注する前に知っておきたい全体像
Kotlin Multiplatform（KMP）は、Kotlinのコードを複数の環境で共有できるオープンソースの技術です。共有先には、Android、iOS、デスクトップ、Web、サーバーなどがあります。
ただし、一つのコードですべての画面を作る技術とは限りません。機能ごとに共有範囲を設計し、業務データと処理を共通化しながら、操作感や端末機能はネイティブで実装する構成も選べます。
KMPとCompose Multiplatformの違い
KMPとCMP（Compose Multiplatform）では共有する対象が違うため、発注範囲を決めるには、ロジックとUIの違いを押さえておく必要があります。
- KMP：ドメインルールや認証などのロジックを共有する。APIクライアント、データモデル、入力検証、オフライン同期も含む
- CMP：Kotlinで、AndroidやiOSなどのUIを共有するフレームワーク
- OS別UI：KMPを使う場合も、AndroidはJetpack Compose、iOSはSwiftUIまたはUIKitを選択できます
業務アプリでは、共通ロジックを先に導入し、UIはOSごとに作る方式が段階的に導入しやすい傾向があります。また、発注時は見積書でもKMPとCMPを分けて記載してもらいます。
画面も共有するなら、PoCの段階で、アクセシビリティや画面遷移、入力欄、端末の戻る操作、既存デザインシステムとの整合を確かめておきます。
発注効果が出やすい共通化の範囲
共通化しやすいのは、業務ルールやデータを扱う処理です。AndroidとiOSで仕様を揃えやすい領域には、たとえば次のようなものがあります。
- 認証と権限：ログインや権限判定
- 業務データ：顧客・商品・在庫のデータモデル
- 通信と入力：REST・GraphQLのAPI接続、入力チェック
- 状態管理：通知の状態、オフライン保存と再送処理
共通コードに集約しておけば、AndroidかiOSのどちらか一方だけ修正が漏れ、業務結果が食い違うリスクを抑えられます。
一方で、カメラ、Bluetooth、位置情報、生体認証、プッシュ通知、ファイル共有は、OS固有の差が出やすい領域です。共通化率を上げるために無理にまとめると、テストや不具合対応が複雑になる場合があります。
RFPでは、画面数や機能数だけでなく、共通ロジック、Android固有、iOS固有、CMPによる共通UIの4区分で対象を示すと、提案と見積を比べやすくなります。
発注形態の選び方
発注形態は、完成責任を外部に任せるか、自社チームで技術を蓄積するかによって選びます。技術検証だけを専門会社に依頼し、本開発は別の会社に発注する方法もあります。
開発全体を一社に任せる前に、PoCで共有範囲と体制を確かめておくと、発注者の判断材料が増えます。
一括請負型が向くケース
一括請負型が合うかどうかは、完成責任をどこまで任せるかと、委託先の技術理解で見極めます。
- 一括管理：要件定義からリリースまでの成果物と納期を、一括で任せたい会社向け
- 社内体制：KMPやiOSの専門人材が少なく、窓口を一本化したい会社にも適する
- 技術理解：共有範囲やOS固有の実装に詳しくない委託先では、追加工数や保守費が膨らむことがある
見積の金額だけで比べると、後からiOS側の工数や保守費が増えていく点を見落としやすくなります。
納品対象は、ソースコードだけに限りません。設計書、API仕様書、テスト仕様書、端末検証結果、依存ライブラリ一覧、SBOMを含めます。さらに、CI/CD設定、ストア申請手順、障害対応手順も、納品の範囲として定めておきます。
ソースコードの著作権や第三者ライブラリのライセンス、再委託の範囲、検収条件は、契約の前に確かめておく必要があります。
伴走・ラボ型のメリット
伴走型やラボ型は、発注側の体制と開発の進め方を踏まえて選びます。
- 向く体制：社内にプロダクト責任者や技術担当者がいる場合
- 進め方：優先順位に応じて要件を変えながら、開発する
- チーム活用：共通モジュール、Android移行、iOS連携、テスト自動化に、月単位で取り組む
- 契約の組み合わせ：PoCは伴走型で進め、本開発で請負または準委任へ切り替える方法もある
KMPの共有範囲は、機能ごとに最適な形が変わります。また、チームで取り組めば、学習と内製化を同時に進められます。
作業時間に応じて支払う契約では、優先順位と受入基準を発注者が管理します。
月額料金の数字からは、委託先のチームがどの技術を担い、どれだけ稼働するのかが読み取れません。そこで、KotlinとSwiftの体制、月間稼働時間、担当交代の条件を、契約の前に委託先へ確かめます。運用面の条件も、契約前に合わせておく必要があります。
- CI/CDの体制
- セキュリティの体制
- 成果物の引き渡し方法
RFPと要件整理で決める項目
RFPは、技術名よりも、解決したい業務課題と発注条件を揃えて伝える資料です。そのうえで、KMPを採用する目的を冒頭に書きます。例として、業務ルールの統一、既存アプリの段階移行、開発と保守の重複削減などがあります。
KMPを前提にしつつ、ネイティブや別のクロスプラットフォーム技術の提案も認めておくと、技術ありきの比較を避けやすくなります。
業務要件と機能要件の整理範囲
要件整理では、利用環境、機能の優先度、端末ごとの運用条件を押さえておきます。
- 利用条件：利用者、場所、端末、業務の開始と完了の基準をあらかじめ決める
- 機能の優先度：認証、権限、顧客・商品・在庫・案件・作業実績、承認、帳票、ファイル、通知を分類する
- オフライン：保存内容と期間、暗号化、再送時期、複数端末での更新時の競合、失敗時の表示を定める
- 端末機能：カメラやBluetoothの対象機種、権限を拒否された場合の代替操作、バックグラウンド動作を記す
機能は必須、できれば必要、将来対応に分けておきます。場面が変われば、設計と見積も変わります。たとえば、営業の訪問利用、倉庫でのバーコード読み取り、工場の通信圏外入力などがあります。
端末利用やオフライン時の条件を具体的に書いておくと、提案を出す各社が同じ前提で見積もれます。
非機能要件と運用条件を先に決める理由
画面数以外の費用や納期の要因を揃えるため、運用条件はRFPの段階で具体化しておきます。
- 性能・稼働：同時利用者数、応答時間、対応OS・端末、運用の時間帯
- 継続性と監査：バックアップ、RTO・RPO、監査ログ、障害通知、データ保持期間、管理者権限
- 情報保護：端末保存、暗号化、認証強度、紛失時のリモート削除、退職者の停止、委託先のアクセス記録
- 脆弱性対応：診断の実施者、修正期限、ログの保管場所、インシデントの連絡時間
個人情報や営業情報、位置情報を扱う場合は、端末に保存するかどうかも要件に含めます。KMPを採用したあとも、安全性は要件として個別に定め、確かめる必要があります。そのときは、OWASP MASVSのストレージ、暗号、認証、ネットワーク、プラットフォーム、プライバシーの項目を、チェックリストにできます。
KMPを使う場合も、共通コードとOS固有コードの両方をテストします。
契約形態の選び方（請負と準委任）
契約形態は、要件がどこまで確定しているかと、発注者側でどこまで管理できるかで選びます。KMPでは、技術検証と本開発で適した契約が異なることがあります。
契約書の名称だけでは、何を任せ、何を受け取るのかが分かりません。そこで、作業範囲、成果物、検収の条件を、契約書の中身で確かめます。
- 報告の方法
- 知的財産の扱い
- 再委託の範囲
- 瑕疵対応の条件
- 変更管理の方法
なお、法務や会計の最終判断は、自社の専門部署や専門家にも確かめます。
請負契約が使いやすい工程
請負契約では、完成責任と変更管理を明確にするため、対象範囲や変更の条件をあらかじめ決めておきます。
- 適する工程：成果物を合意できる本開発やリリース作業
- 成果物の定義：commonMainのモジュール、Android・iOS固有実装、テスト合格条件
- 合意する仕様：画面、API、データ移行、テスト項目、対応端末、検収条件
- 変更管理：受付方法、追加単価、納期の再計画、軽微変更の上限
請負契約は、決めた条件どおりに成果物を完成させる工程で使いやすい契約です。共通化率だけで納品範囲を示すと、何が納品されるのか曖昧になるため、成果物を具体的に書いておきます。
要件変更により、当初の見積の範囲を超える場合があります。そのため、追加請求の扱いで行き違いが生じにくいよう、変更の条件を先に合意しておきます。
準委任契約が使いやすい工程
準委任契約は、方針が変わりうる工程で使いやすい契約です。また、管理と記録の内容も整理しておきます。
- 適する工程：要件定義、PoC、設計検討、既存アプリ移行の調査、内製化支援
- 技術検討：共有範囲、Swift連携、Android・iOSのCI検証など、調査で方針が変わる作業
- 週次報告：成果、判断事項、リスク、次週の計画
- 記録と終了条件：設計書、検証コード、判断記録、課題一覧、PoCの判定項目
準委任は、一定期間の業務遂行を委託する形です。そのため、不確実性が高い段階でも検討を進めやすくなります。
PoCの終了条件は、「動いた」という結果に加えて、主要端末のビルド時間、APIエラー時の挙動、認証、共有範囲、保守性などで判定します。
Kotlin Multiplatformのシステム発注費用・相場の目安
KMP専用の公的な国内費用統計は確認できていません。そのため、2026年時点の国内モバイルアプリやBtoBアプリの公開相場を基にした、KMP業務システム発注の目安として扱います。
費用は、画面数だけでなく既存APIの有無やオフライン対応、端末検証で変わります。さらに、データ移行、セキュリティ、運用監視、共有範囲も金額を左右します。金額は定価ではなく、前提を付けた幅として見ます。
規模別の費用レンジ
規模ごとの費用は、対象範囲と前提をそろえて比べます。
- PoC：認証、API接続、1機能、Android・iOSのビルドとテストで100万〜300万円程度
- 小規模：5〜15画面、ログイン、一覧・登録、簡易管理画面で500万〜1,000万円程度
- 中規模：20〜50機能、複数API、権限、通知、オフライン、端末検証で1,500万〜3,000万円程度
- 大規模：複数拠点・システム連携、移行、監査、SLA、24時間運用で3,000万〜8,000万円以上の可能性
- 既存Android移行：共有効果の高い認証・通信・ドメイン層から段階的に進める場合で300万〜1,500万円程度
実際の金額は、既存APIを使えるかどうかや、バックエンドを新たに開発するかどうかで変わります。
中規模と大規模の幅は、株式会社ripla「BtoBアプリ開発の進め方」と、2026年のSIA株式会社の業務システム連携アプリの相場を参考にした推定です（出典: 株式会社ripla、SIA株式会社、2026年）。
既存移行の見積は、全画面を一度に作り直す費用として扱わず、既存コードの品質、テスト、依存ライブラリ、Swift側の実装状況を調べてから取り直します。
見積金額の内訳項目
見積書は「KMPアプリ開発一式」とまとめず、工程や実装範囲ごとに分けてもらいます。そうすると、共通化で減る工数と、基盤や相互運用で増える初期工数を分けて確認できます。
- 設計と開発：要件定義、基本設計、共通コード、Android・iOS固有実装、CMPのUI
- 連携と移行：バックエンド・API、管理画面、データ移行
- 品質と導入：テスト、CI/CD、ストア申請、導入支援
- 運用：保守、システムの監視
KMPで二重実装を減らせる可能性はあります。ただし、要件定義、バックエンド、実機テスト、運用監視、ストア審査の工数は残ります。
費用配分の目安は、要件定義10〜15%、基本設計15〜20%、開発30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%という考え方です。
この比率は、見積の抜けを探す確認軸として使い、標準の比率とみなさないようにします（出典: 業務システムの費用配分に関するNotebookLMリサーチノート、2026年）。
年間保守費は、初期開発費の15〜20%程度が公開相場の一つです。ただし、OS更新、脆弱性対応、障害対応時間、軽微改修、サーバー費の範囲によって変わります（出典: SIA株式会社、2026年）。
委託先の選定と見積比較で確認すべきポイント
委託先は、KMPという技術名だけで選ばず、本番利用の経験、Android・iOSの体制、ネイティブUIとCMPの使い分けを確かめて決めます。また、業務連携、オフライン、端末機能、セキュリティ、保守も、同じ基準で比べます。
公開事例があっても、自社と似た規模や利用環境で作られたとは限りません。そのため、担当エンジニアに質問して、実績の中身を確かめます。
提案時に委託先へ確認する質問
提案の場では、共有範囲、iOS実装、開発基盤、業務導入の四つの観点で、委託先に質問します。
- 共有範囲：commonMain、Android・iOS固有機能、CMPとネイティブUIの分担
- iOS実装：Swift側の作業、iOS固有API、主要端末の検証方法
- 開発基盤：CIビルド、ライブラリ更新、Xcode・Gradle・Kotlinの互換性
- 業務導入：現場ヒアリング、マスタ整理、既存API調査、移行、教育、問い合わせ対応
JetBrainsは、2025年8月のロードマップで、Swift Exportの改善、互換性マトリクス、KMPのIDE体験の向上を掲げました。さらに、2026年にはSwiftとKotlinの相互運用に必要な安定化を目指す方針です。
発注時には、採用するバージョンと更新の判断者を契約に記しておきます。なお、現場業務を理解しないまま開発すると、誤入力や二重管理を招く可能性があります。
提案書には、業務フロー、例外処理、導入後の定着支援が含まれているかを見ます。
複数社の見積書の比べ方
見積を比べるときは、前提条件と内訳をそろえてから、価格差の理由を確かめます。
- 同じ前提：一つのRFPを全社に渡し、APIが既存か新規か、オフライン対応の条件をそろえる
- 範囲の明記：含む・除外する内容、追加費用の条件、端末、テスト環境、発注者側の作業
- 内訳比較：共通ロジック、OS固有、バックエンド、QA、PM、セキュリティ、移行、保守ごとに比べる
- 価格差の確認：金額の差が、どの項目から生じているかを見る
- 調整：機能を一律に削らず、目的に合わせた優先順位で決める
APIを既存で使える会社、新規開発を含む会社、オフラインを将来対応とする会社では、見積の前提が違います。そのため、金額をそのまま並べても、優劣は判断できません。
極端に安い見積では、iOS実機テスト、データ移行、CI/CD、ストア申請、障害対応が別料金になっていないかを確かめます。一方で、高い見積では、過剰なCMP共通UIや不要な基盤整備が含まれていないかを尋ね、目的に応じて調整します。
見積に含めるPoCと段階導入
初めてKMPを導入する場合や、既存Androidから移行する場合は、リスクの高い機能を対象に、PoCを見積に含めます。
- 認証・通信：API接続や認証処理
- データ処理：ローカルDBやオフライン再送
- OS連携：iOSへの公開API、カメラ、通知
PoCの成果物は、サンプル画面にとどまらず、技術報告書にまとめます。報告書には、採否の判断、性能、ビルド手順、想定される保守の負荷、残課題を含めます。
まず、本開発では認証や通信など共有効果の高い機能から進めます。AndroidとiOSは同じCIでビルドし、機能単位でリリースします。
成果を追う指標は、共通コードのテストカバレッジ、OS別の不具合件数、ビルド時間、クラッシュ率、業務完了時間、問い合わせ件数です。共通化率の数字そのものではなく、二重実装の削減と業務品質を測ります。
よくある質問（FAQ）
発注時には、技術の採否だけでなく、発注条件、費用の前提、保守体制も確かめておく必要があります。よくある質問を順に取り上げます。
Kotlin Multiplatformなら開発費用は必ず安くなりますか？
業務ルールや通信処理を共有できれば、二重実装と二重保守を減らせる可能性があります。ただし、必ず安くなるとは限りません。
導入の初期には、PoC、ビルド基盤、iOS相互運用、実機テストの費用がかかります。そのため、共通化率ではなく、要件定義から保守までの総保有コストで比べます。
発注先にSwiftエンジニアがいなくても依頼できますか？
依頼はできます。ただし、iOS固有機能を扱う案件では、SwiftやSwiftUI・UIKitの知識を持つ担当者がいるかを確かめます。
認証、通知、カメラ、Bluetooth、ストア申請、アクセシビリティは、iOS側の判断が必要になる場面です。そのため、担当者の所属形態よりも、設計レビューから実機検証、障害対応まで責任者が関わるかを見ます。
既存のAndroidアプリをKotlin Multiplatformへ移行できますか？
移行は可能です。一般的には、全体を作り直すのではなく、認証、データモデル、通信、業務ルールなど共有効果の高い層から、段階的に進めます。
移行対象と見送る対象は、既存コードのテスト不足、Android固有APIへの依存、ライブラリの互換性、iOS側に必要なAPI設計を調べたうえで決めます。
保守契約では何を確認すればよいですか？
開発環境の更新担当は、Kotlin、KMP、CMP、Xcode、Android Studio、Gradleの各項目ごとに確かめます。依存ライブラリと対応OSの更新担当も、契約に含めておきます。
保守契約では、脆弱性対応の期限、障害の一次切り分け、端末紛失、ストア審査のリジェクト、軽微改修の月間上限、障害時の連絡時間と復旧目標を定めておきます。
初期開発費の15〜20%程度という公開目安はあるものの、保守のサービス範囲をそろえて比べなければ、適正価格かどうかは判断できません。
まとめ
発注前に決めておくこと
まず、対象業務、利用者、対応端末、オフラインの有無を一枚にまとめます。そのうえで、既存連携、共通化する処理、納品後の運用担当も書き添えます。こうしておくと、提案の前提を揃えやすくなります。
最初に取るべき行動
発注を具体化するには、現場の要件確認から委託先の評価までを、順に進めます。
- 現場担当者と業務フローを確かめ、業務課題と利用環境を整理する。
- 機能単位で、共通ロジック、Android固有、iOS固有、共通UIの範囲を決めておく。
- 候補の会社に、RFPとPoCの相談を同時に出し、見積の前提、契約形態、保守の責任、引き渡しの条件を尋ねる。
- 準委任と請負は工程で使い分ける。技術検証や要件が固まりきらない段階は準委任、成果物と検収条件を決められる本開発は請負です。
- PoC、小規模、中規模、大規模、既存移行の費用幅を前提付きで把握し、見積は実装範囲ごとに分けてもらう。
- 金額だけでなく、実機検証、セキュリティ、更新、ソースコードと設計書の引き渡しも比べ、共有範囲を合意する。
見積の費用がどこに入っているかは、共通コード、OS固有実装、バックエンド、QA、移行ごとに見ます。CI/CDや保守の費用も、同じように確かめます。見積とPoCを通じて、自社で継続して運用できる提案かどうかを見極めます。
▼全体ガイドの記事
・Kotlin Multiplatformのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。