相談する

Kotlin Multiplatformのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Kotlin Multiplatform（KMP）のシステム開発は、要件整理から稼働と定着まで、全6段階で進みます。

最初に業務と共有範囲を決め、PoCで技術リスクを確かめてから本開発に入るのが流れです。全体像は、完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・Kotlin Multiplatformのシステム開発の完全ガイド

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

Kotlin Multiplatformのシステム開発の全体像

KMPを中心に共有ロジック、OS別実装、CMPの画面共有、ネイティブ連携を配置した図解
共通化の範囲は機能ごとに考えられます。

Kotlin Multiplatform（KMP）は、KotlinのコードをAndroidやiOSのほか、デスクトップ、Web、サーバーなどで共有できる仕組みです。また、Googleは、AndroidとiOSのあいだでビジネスロジックを共有することを公式にサポートしています。2026年7月29日更新のAndroid Developersの案内では、KMPを安定版かつ本番利用可能な技術としています（出典: Google Android Developers、2026年）。

KMPとCompose Multiplatformの違い

KMPは共有ロジックの仕組みで、Compose Multiplatform（CMP）は、KotlinでUIまで共有するフレームワークです。両者は共有する範囲が違うため、どちらを使うかは要件に照らして決めます。

  • KMPで共有：認証、権限判定、入力検証、API、データモデル、オフライン同期
  • OS別に実装：Android画面はJetpack Compose、iOS画面はSwiftUI
  • CMPで画面共有：画面まで共有する選択肢

ただし、アクセシビリティ、OS固有の操作、既存デザインシステムとの適合は、事前の検証が必要です。カメラや地図などのネイティブ連携も、事前に確かめておきます。

KMPを採用する目的は、機能ごとに品質と保守性に寄与する共有範囲を選ぶことにあります。100％の共通化は、その目的に含まれません。

業務システムで共有しやすい機能

業務システムでは、AndroidとiOSで同じ業務ルールを使う機能が共有の候補になります。

  • 業務ロジック：認証、権限、承認ルール、入力チェック、通知判定
  • データ処理：顧客・商品マスタ、API通信、監査ログの整形
  • オフライン処理：ローカルDB、入力、同期キュー、再送、競合解決
  • OS固有機能：端末保存、生体認証、通知、Bluetooth、カメラ、位置情報

計算式や状態遷移をcommonMainなどに集めると、仕様変更のときの修正漏れを減らせます。一方で、端末機能はOSのAPIを使うため、androidMainとiosMainに分けて設計するのが基本です。機能一覧を「共通」「Android固有」「iOS固有」「要検証」に分けておくと、見積もりを同じ基準で比べられます。

2026年時点で確認したい最新動向

KMPの構成とライブラリの対応状況は更新されるため、導入時には、標準構成、AGP 9.0の要件、対応ライブラリの3点を確かめます。

  • 標準構成：JetBrainsは2026年5月、sharedとアプリの分離を発表しています（出典: JetBrains Kotlin Blog、2026年5月）
  • AGP 9.0：共有モジュールとAndroidの入口を分離
  • 対応ライブラリ：AndroidとiOSをTier 1とするJetpackのKMP対応ライブラリにRoom、DataStore、Navigationなど

Android Gradle Plugin 9.0の要件は、新規案件と既存案件の更新計画に影響します。さらに、ライブラリや対象OSの成熟度は一様ではないため、本番対応や更新頻度、iOS実機テストを確かめてください。既知の制約や障害時の代替案も、あわせて確かめてください。

ポイント

KMPで共有するかは、機能ごとに品質と保守性への効果で判断します。画面の共有や端末機能、最新の構成は、PoCで確かめてから決めます。

Kotlin Multiplatformのシステム開発の進め方

KMP開発が要件整理、PoC、設計・開発、テスト、稼働と定着へ進む流れ図
技術検証の後に開発と運用の準備が続きます。

KMP開発は、業務の標準化と共有範囲の判断から始め、そのあとで技術検証と画面の開発に進みます。各段階で決める内容と判断の基準を、6つの段階に分けて示します。

フェーズ1：要件整理と業務・共通化範囲の確定

最初に、誰がどの端末でどの業務を行い、どのデータを使うのかを整理します。

  • 現行業務：紙、Excel、電話、FAXのやり取り、二重入力、例外処理
  • 要件：対象OSと最低対応バージョン、利用者数、端末管理方式、画面、帳票、既存API、オフライン時間
  • 非機能：データ保持期間、RTO・RPO、監査ログ、認証方式、管理画面の要件
  • 共有範囲：「共有」「OS固有」「共通化しない」「PoCで判断」のいずれかへの分類

現行業務とあるべき業務フローは、分けて記録します。部署ごとの違いを残したまま移すと、不正確なデータ入力を速めるだけになり、技術の効果も測れません。

完了時には、主要業務の受入条件と、共通化しない機能の理由を、発注者と開発会社が説明できる状態にします。

フェーズ2：技術と開発会社の選定

まず、KMP、Compose Multiplatform、Flutterを要件に照らして比べます。React Nativeと完全ネイティブも、同じ基準で比較の対象になります。

  • KMPが有力：AndroidとiOSのロジックを同じ品質で保ちたい
  • 採用を再検討：対象OSが一つ、短期の単純なWebビューで足りる
  • 採用を再検討：端末固有機能が大半を占める
  • UI方式：画面共有か、SwiftUIとJetpack Composeの個別実装か

開発会社には、本番実績や既存Androidアプリからの段階移行、SwiftUIやUIKitとの連携について尋ねます。オフライン同期、端末検証、CI/CDの実績も確かめます。ストア申請やリリース後の保守の実績も見ておきます。

提案書は、共通コード、OS固有、バックエンドを分けて示してもらいます。管理画面とQA、移行と教育も、項目ごとに分けてもらいます。コードを書くだけでなく、業務要件と受入条件まで管理できる会社を選びます。

フェーズ3：PoCによる技術リスクの検証

選定のあとは小さなPoCを行い、サンプル画面が表示されるだけで済ませず、実際のリスクを確かめます。

  • 実装範囲：認証、API、ローカル保存、主要な1画面、簡易テスト
  • ビルド：AndroidとiOSのビルド、共有コードの呼び出し
  • 異常系：APIエラー、期限切れ、通信切断、同期失敗、権限拒否

iOSから共有Kotlinコードを呼ぶときの型や例外の扱いも、確かめておきます。評価指標は、共有率、ビルド・起動時間、実機メモリです。

さらに、クラッシュ、API復旧、CI再現性を見ます。Swift側の呼びやすさや、障害解析、OS更新のしやすさも評価します。

成果物には、採用・不採用のライブラリと構成図を含めます。そのうえで、未解決リスクと量産開発の見積前提を記録しておきます。

フェーズ4：設計・開発と共有モジュールの育成

本開発では、共有ロジックとOS固有機能の境界をはっきりさせます。

  • 共有モジュール：ドメイン、データ、検証、API、状態、同期
  • OS別モジュール：Keychain・Keystoreを使う安全な保存、通知、カメラ、位置、生体認証、Bluetooth
  • ネイティブUI：共有層から渡す状態、イベント、エラーの定義

2026年の標準構成を参考にする場合は、共有ロジックと実行アプリを分け、各モジュールの責任を一つに近づけます。ただし、既存案件で全面移行が必須とは限りません。Android Gradle PluginとKotlinをはじめとする開発ツールの互換性を固定し、更新はCIで検証します。

成果物は、ソースコードに加えて、設計書、依存一覧、SBOMです。さらに、テスト仕様やCI/CD、リリースと障害対応の手順も含まれます。

フェーズ5：テストによるOS差分と業務品質の確認

テストは、共有コードの単体テストに加えて、共有ロジックと実機の両方を検証します。

  • 共有ロジック：境界値、状態遷移、同期処理
  • 実機：権限、通知、カメラ、ファイル、復帰、回転、通信切断
  • 業務受入：入力、承認、連携、帳票、監査ログの一連の流れ

個人情報や営業情報を扱う場合は、端末保存とログ、紛失時の扱いをテストします。退職者のアカウント停止も、テストの対象です。

OWASP MASVSでは、確認領域としてストレージ、暗号、認証を挙げています。さらに、通信、OS連携、コード品質も含まれます。耐タンパー性とプライバシーも、確認領域です（出典: OWASP MASVS、2026年確認）。

KMPを使う場合は、共有モジュールの中だけでなく、OS別の実装も含めてセキュリティを確かめます。

フェーズ6：運用設計から始める稼働と定着

リリース前に、配布の方法と初期データを決めます。そのうえで、問い合わせ先と障害時の切り戻しも決めておきます。稼働の起点は公開日ではなく、現場が安全に使え、正しいデータが業務システムへ流れた時点です。

  • 配布準備：ストア申請、MDM、端末配布、アカウント発行
  • 試験運用：代表拠点でパイロットを実施
  • 確認指標：利用率、入力完了、差戻し、同期エラー、問い合わせ

全拠点へ一斉に展開するのは避け、パイロットの状況を見てから段階的に広げます。

定着のためには、業務ルールの変更点、連絡先、データ修正の責任者を文書に書いておきます。また、週次レビューで未利用の機能や紙へ戻った工程を確かめ、改善項目に反映します。

契約では、運用後にどこまでを誰が受け持つかを明確にします。具体的には、OS更新や脆弱性、障害時SLAが対象です。ライブラリ更新と引き継ぎ方法も、契約に含めます。

ポイント

業務と共有範囲が決まらないまま本開発に入ると、後から範囲を直すことになります。PoCで技術リスクを先に確かめてから進めます。

Kotlin Multiplatformのシステム開発費用相場

PoC、小規模、中規模、大規模の4区分とそれぞれの推定費用レンジを示す図解
規模が上がると費用レンジも大きくなります。

KMP専用の公的な国内費用統計は確認できません。そのため、ここに示すのは、公開相場と共有範囲を踏まえた推定レンジです。

KMPを採用すれば費用が自動的に下がるとは限りません。要件定義やバックエンド、管理画面などの作業も必要です。QAや端末検証のほか、申請と保守も含めて考えます。

金額は税別の目安として、前提条件と合わせて比較してください。

規模別の費用レンジと期間

費用と期間は、画面数や連携機能などの規模に応じて変わります。

  • PoC：認証、API、1機能、両OSビルド、簡易テストで100万〜300万円程度、1〜2か月
  • 小規模：5〜15画面、ログイン、一覧・登録、簡易管理画面で500万〜1,000万円程度、3〜5か月
  • 中規模：20〜50機能、複数API、オフライン、通知、権限、端末検証で1,500万〜3,000万円程度、6〜10か月
  • 大規模：複数拠点・システム、移行、監査、SLA、24時間運用で3,000万〜8,000万円以上、12〜24か月以上となる可能性があります
  • 既存アプリ移行：共有効果の高い認証・通信・ドメイン層から着手し、300万〜1,500万円程度を一つの検討レンジとします

公開相場とKMP案件を混同しない見方

公開されているアプリ単体の相場と、KMP業務システムの費用範囲は、分けて考えます。

  • 最低限の機能：50万〜100万円
  • 基本機能：100万〜200万円
  • 複雑な機能：200万〜300万円
  • 高度な機能：300万円以上

この金額はベンダーが公表した例で、公的な標準相場ではありません。対応OSや機能規模、開発手法で変わるほか、人月単価や保守の範囲によっても違いが出ます（出典: LASSIC、2026年5月）。

SIAの2026年7月の解説では、業務システム連携iOSアプリは500万〜1,500万円が目安です。また、工数配分は実装40〜50％、テスト15〜20％、企画・要件定義10〜15％とされています。

KMPでは、共有モジュールのPoCやAPI、データ移行も加味します。さらに、Android実装や、共有できない端末機能も見込みます（出典: SIA株式会社、2026年7月）。

初期費用以外に必要なランニングコスト

初期開発費の15〜20％程度を年間保守費とする公開例があります。

  • 更新・保守：Kotlin、KMP、CMP、Xcode、Gradle、依存ライブラリ、OS
  • 運用基盤：脆弱性対応、CI実行環境、クラウド、監視、端末買い替え
  • 配信関連：Apple Developer Program年額費用、証明書、審査、プライバシー表示
  • オフライン運用：同期API、競合解決、再送、データ保持

保守の対象があいまいだと、OS更新のたびに追加の見積もりが発生することがあります。

開発費と保守費は分けて示してもらい、OS更新や障害対応、軽微な改修の境界を項目別に確かめます。追加機能や問い合わせ対応についても、どこまでが保守に含まれるかを決めておきます。

ポイント

費用は規模で大きく変わるため、同じ規模どうしの見積もりを並べて比べます。公開相場は前提が異なるので、共有範囲と保守の条件をそろえて判断します。

Kotlin Multiplatformの見積もりを取る際のポイント

見積もりは、総額だけでなく、共有範囲とリスクの負担者を比べるために取ります。「KMP一式」のような見積もりでは、内訳が見えません。

発注前には、機能一覧と業務フロー、APIと画面を用意します。さらに、端末とセキュリティ、受入条件もそろえます。

見積書の共通・Android固有・iOS固有による内訳

見積書の項目を分けると、共有範囲の変更が費用に与える影響を比べられます。

  • 全体工程：要件、UI・UX、テスト、教育、保守
  • 共通領域：共有ロジック、認証、API、モデル、検証、DB、同期
  • Android固有：Keystore、権限、通知、端末差分、Google Play
  • iOS固有：SwiftUI/UIKit、Keychain、生体認証、通知、App Store、実機
  • 周辺作業：バックエンド、管理画面、移行、CI/CD、ストア申請

共通と固有の工数が分かれていれば、開発会社は、共通化で減る工数と残る工数を説明できます。

発注前に確認するチェックリスト

見積もり前に、対象範囲と運用条件を一覧にします。

  • 規模：対象OSと最低対応バージョン、端末、利用者・同時利用数、画面数、帳票数、API数
  • データ：外部サービス、オフライン時間、同期方式、マスタ管理者、データ移行件数、監査ログ
  • 管理：認証・権限、紛失時対応、管理画面、CI/CD、ストア、教育、保守、SLA
  • 契約・成果物：成果物の権利、ソースコードの引き渡し

オフラインや端末機能は、画面数だけでは工数を判断しにくい項目です。そのため、切断後の利用時間や、複数端末の更新の優先順、撮影失敗時の再試行まで、受入条件に含めます。

要件を確定できない場合は、本開発の見積もりに含めず、期間と成果物を限ったPoCを先に分けて行う方法があります。

複数社の同条件での比較

各社に同じRFPとPoC条件を渡し、価格だけでなく、体制や責任範囲も比べます。

  • 技術判断：KMP・CMPの理由、ネイティブUIを残す判断
  • 実行体制：実機テスト台数、iOS人材、CI構築範囲、ライブラリ更新担当
  • 運用支援：障害一次対応、納品後の内製化支援

見積もりが安いときは、対象外の項目や、発注側で担う作業が増えていないかを確かめます。

契約前には、コードと設計書の権利、再委託の扱いを見ます。さらに、OSSライセンスとSBOM、秘密情報、個人情報の委託管理も確かめます。

海外拠点や越境移転の有無、契約終了時の引き継ぎも確認します。特定の会社しかビルドできない状態になると、将来の保守費用が上がる可能性があります。第三者が環境を再現できるよう、手順書とCI設定を納品条件に含めます。

見積に含める失敗リスクと対策

失敗を避けるには、共通化率だけでなく業務と保守のリスクも見積もります。

  • 共通化率を先に固定：機能ごとの品質、速度、障害率を測る
  • 例外業務を未確認：現場代表者を要件整理と受入テストへ招く
  • API・マスタを過小評価：品質とデータ条件を事前に調べる
  • テストを後回し：工程にテストと受入条件を含める
  • 保守担当が不明：リリース後の責任者と対応範囲を決める

見積書には、前提と対象外、変更時の扱いを記載します。さらに、PoC項目と予備工数、節目と受入条件も含めます。

Android Gradle Pluginを含む開発ツールの更新で、ビルドが止まるリスクもあります。対策として、バージョンの固定と更新の検証、ロールバック、緊急対応費を確かめます。

こうした確認を重ねると、初期費用だけでなく、総保有コストも比べられます。

ポイント

見積もりは、共通・Android固有・iOS固有の内訳と前提条件をそろえて比べます。対象外や保守の範囲が書かれていない見積もりは、同じ条件で出し直してもらいます。

Kotlin Multiplatformのシステム開発でよくある質問

KMPの導入では、費用や人材がよく検討されます。さらに、ネイティブ機能や既存アプリの移行も検討の対象になります。そのうえで、要件に照らしてPoCや段階移行の範囲を決めます。

Kotlin Multiplatformのシステム開発費用はいくらですか？

技術検証のPoCは100万〜300万円程度、小規模な社内業務アプリは500万〜1,000万円程度が推定レンジです。

中規模の業務システム連携は、1,500万〜3,000万円程度が推定レンジです。画面数に加えて、バックエンドやオフライン同期、データ移行の有無で大きく変わります。端末検証やセキュリティの対策、管理画面や保守の有無も、費用に影響します。

これらは、案件の条件に基づく推定額で、KMPの定価ではありません。

SwiftのエンジニアがいなくてもKMPを導入できますか？

iOS画面や端末機能を作る場合、SwiftUIやUIKit、Xcode、Appleの審査・配布に対応できる人材が必要です。

KMPを使っても、iOSの知識が要らなくなるわけではありません。具体的には、共有Kotlinコードの組み込みやエラー解析、OS更新への対応が必要です。

KMPなら画面もAndroidとiOSで完全に共通化できますか？

Compose Multiplatformを使えば、画面も共有できます。ただし、完全な共通化は必須ではありません。アクセシビリティやOS固有の操作なども含め、共有範囲は機能ごとに判断します。

認証などの共有ロジックをKMPに集め、画面はJetpack ComposeとSwiftUIに分ける構成から始めると、品質リスクを抑えやすくなります。

既存のAndroidアプリをKMPへ移行できますか？

移行はできます。共有効果の高い認証やAPI、データモデルから、共有モジュールへ切り出します。検証の部分も、切り出しの対象になります。

既存のAndroid画面を動かしたまま、段階的に進める方法が一般的です。依存関係やテストの不足を、PoCで確かめます。加えて、iOSの設計とAPI差分も確認します。

機能ごとに、移行の費用対効果を判断してください。

ポイント

費用の目安は案件の条件で変わるため、画面数だけで判断しません。要件に照らして、PoCや段階移行の範囲を先に決めます。

まとめ

KMP開発では、AndroidとiOSで共有する業務ロジックを整理し、画面や端末機能は分けて進めます。

要件整理で業務とデータを標準化し、KMPとCMPの役割を決めます。そのうえで、PoCにより認証やAPI、保存のリスクを確かめます。さらに、同期やCI、実機のリスクも確認します。

まず決めるべき3つのこと

最初に、共有機能とOS固有機能を機能一覧に記載します。次に、非機能要件を整理します。

非機能要件には、既存APIやマスタ、オフラインの扱いを含めます。さらに、認証と端末管理、監査も入れます。

最後に、PoCの合格条件と、開発後の保守・更新責任を決めます。この3点が明確なら、KMP、ネイティブ、別手法を価格だけに頼らず比較できます。

次のアクション

KMPの採用を判断するには、準備から見積もり確認まで、材料を次の順にそろえます。

  1. 現場にヒアリングし、業務フロー、機能一覧、API、端末、セキュリティ、受入条件をまとめたRFPを作ります。
  2. KMPの本番実績があり、両OS、バックエンド、QA、保守を説明できる会社へ同じ条件で相談します。
  3. 見積もりは、共通・固有・運用の内訳と前提条件を確かめます。必要であれば、100万〜300万円程度のPoCから始め、将来の手戻りを抑えます。

▼全体ガイドの記事
・Kotlin Multiplatformのシステム開発の完全ガイド

▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。