Kotlin Multiplatformのシステム開発の完全ガイド

Kotlin Multiplatformのシステムとは、AndroidやiOSなど複数の環境で業務ロジックを共有しながら、各端末らしい操作性と機能も両立できるシステムです。

「AndroidアプリをiOSにも展開したい」「共通化で費用を抑えたいが、結局二重開発にならないか分からない」という担当者に向けて、KMPの仕組み、向いている業務、開発の進め方、費用相場、セキュリティ、開発会社／ベンダーの選び方までをまとめます。技術を採用すること自体を目的にせず、自社の業務と運用に合うか判断できるよう、共通化する部分と個別に作る部分を分けて解説します。

Kotlin Multiplatformのシステムとは何ですか？

Kotlin Multiplatform（KMP）は、同じKotlinコードを複数のプラットフォーム向けに利用するための仕組みです。AndroidとiOSの業務システムでは、認証、入力チェック、データモデル、API通信、同期処理などを共通化し、カメラや通知、端末ストレージなどは各OSの実装として分ける構成が現実的です。公式ドキュメントでも、共有範囲は一部モジュールから段階的に広げられると説明されています（出典：Kotlin Multiplatform公式ドキュメント、2026年7月確認）。

KMPとCompose Multiplatformは同じものではありません

KMPは、ビジネスロジックやデータ処理を共有するための基盤です。一方、Compose Multiplatformは、Kotlinで画面のUIまで共有するための選択肢です。KMPを採用したからといって、AndroidとiOSの画面を同じコードで作る必要はありません。むしろ最初はAndroidをJetpack Compose、iOSをSwiftUIやUIKitで作り、共通化の効果が高い層だけを共有するほうが、既存のデザインやOS固有の操作を保ちやすい場合があります。

共有しやすい機能と個別実装が必要な機能

共有しやすいのは、業務ルール、計算、入力バリデーション、APIクライアント、JSONの変換、認証状態、キャッシュ、ローカルDBとのやり取り、オフライン時の同期キューなどです。AndroidとiOSで同じ在庫数や承認条件を使うため、ロジックを一つにまとめれば仕様の食い違いを抑えられます。

反対に、カメラ、Bluetooth、位置情報、プッシュ通知、生体認証、キーチェーンやKeystoreへの保存、ファイル共有、アクセシビリティ、OS固有のジェスチャーは個別実装が発生しやすい領域です。ここを「共通化できるはず」と見積もると、後からネイティブ側の追加工数が膨らみます。共通化率は高ければよいのではなく、機能ごとの品質、保守性、開発速度で評価します。

システムの種類と基本アーキテクチャ

KMPのシステムは、モバイルアプリだけで完結するとは限りません。業務API、データベース、管理画面、認証基盤、端末管理、監視を組み合わせて初めて、現場で使える業務システムになります。ここでは、UIの共有範囲と業務の利用形態から、代表的な構成を整理します。

共有ロジックとネイティブUIを組み合わせる構成

最も導入しやすいのは、共通モジュールにドメインルール、データモデル、API通信、認証、同期を置き、画面は各OSで作る構成です。既存のAndroidアプリがある場合は、まずログインや通信処理を共有モジュールへ移し、iOSアプリから利用する順番にすると、画面全体を作り直さずに移行できます。

画面も共有するCompose Multiplatform構成

AndroidとiOSで画面の構造やデザインを揃えたい場合は、Compose MultiplatformによるUI共有を検討できます。入力フォーム、一覧、検索、承認など、両OSで同じ振る舞いを求める画面では開発効率を高めやすい一方、OSごとのナビゲーション、戻る操作、アクセシビリティ、キーボード、通知許可の導線は別途確認が必要です。画面を100％共有することを先に決めず、1〜2画面で実機検証してから範囲を広げます。

業務API・管理画面・端末管理まで含む構成

在庫、作業実績、顧客情報、承認などを扱う場合、KMPアプリの外側にAPIとデータベースが必要です。管理者向けのWeb画面、権限管理、監査ログ、帳票出力、端末の利用制限、障害監視も含めて設計します。KMPはSaaSやクラウドサービスそのものではなく、主にクライアントと共有ロジックの実装技術です。バックエンドを既存のJava／Kotlin系、別言語のAPI、クラウド基盤のどれにするかは、既存資産と運用体制で決めます。

向いている業務と、採用を慎重に検討する条件

KMPの判断では、対象OSが複数あることだけでなく、同じ業務ルールを複数アプリで使うかを確認します。業務データと処理を共有したい案件ほど効果を説明しやすく、端末固有の体験が中心の案件ほど個別実装の比率が高くなります。

現場入力・承認・データ照会を行う業務に向いています

営業支援、点検、保守、倉庫、配送、店舗、訪問サービスなど、AndroidとiOSの両方で同じ業務を行う現場に向いています。特に、電波が不安定な場所で入力し、後から同期する業務では、共有ロジックにオフライン保存、再送、重複防止、競合解決をまとめやすくなります。バーコードやカメラの呼び出しはOSごとに分けても、読み取った値の検証や登録処理は共有できます。

既存Androidアプリを持ち、将来iOSにも展開したい企業にも適しています。全画面を移植するのではなく、認証、API、データ層から段階的に共有すれば、利用中のAndroid業務を止めずに移行計画を立てやすくなります。

1つのOSだけ、または固有機能が大半なら慎重にします

対象OSが一つだけで、既存のネイティブ開発体制も整っている場合は、KMP導入の初期コストが効果を上回る可能性があります。短期の単純なWebビューで足りる場合も、KMPを選ぶ必然性は高くありません。反対に、複数OSを長期運用し、同じ業務ロジックを繰り返し改修するなら、共有による品質と保守の効果を検討しやすくなります。

3D描画、端末センサー、特殊なBluetooth機器、決済、動画処理など、OS固有のSDKや性能要件が大部分を占める案件では、個別実装を前提に比較します。KMPを採用する場合も、固有機能をどの程度SwiftやAndroid側に残すか、検証端末を何台用意するかをPoCで決めます。

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

開発前に業務を整理し、共有範囲を小さく検証してから本開発へ進むことが重要です。特に、紙やExcelから移行する業務では、画面を作る前に業務ルール、マスタ、例外処理、権限を確認します。KMPの導入を急ぐより、何を共通化すると将来の変更が減るかを合意することが成功につながります。

▶ 詳細はこちら：Kotlin Multiplatformのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

現行業務の棚卸しと要件定義を行います

最初に、利用者、拠点、端末、業務フロー、対象OS、同時利用者数、既存API、連携先、データ保持期間を洗い出します。画面一覧だけでなく、正常系と例外系を並べることがポイントです。たとえば、在庫登録なら通信断、二重送信、数量の訂正、締め後の変更、権限外の操作まで要件に含めます。

RFPには、オフラインの許容時間、同期失敗時の再送方法、RTOとRPO、監査ログの保持、端末紛失時の対応、対応OSと最低バージョン、実機テストの対象を記載します。共通コード、Android固有、iOS固有、API、管理画面、移行、テストを分けて書くと、後の見積比較がしやすくなります。

PoCで共有範囲と技術リスクを確かめます

本開発の前に、ログイン、1つのAPI通信、ローカル保存、同期、エラー表示、AndroidとiOSのビルドを含む小さなPoCを作ります。既存Androidからの移行なら、共通モジュールをAndroidへ組み込み、同じモジュールをiOSから呼び出せるかを確認します。画面の見た目だけでなく、Xcode、Gradle、CI、実機、証明書、クラッシュログまで通すことが大切です。

PoCの判定基準は「動いたか」だけでは不十分です。共通コードのテストが両OSで実行できるか、iOS側の公開APIが扱いやすいか、ビルド時間が許容範囲か、障害時にどの層を調査できるか、担当者が継続運用できるかを確認します。PoCの成果物として、共有する機能、個別実装する機能、残る課題、概算工数を文書化します。

設計・実装では共通層とOS固有層を分けます

基本設計では、commonMainに置くものと、androidMain、iosMainに置くものを機能単位で決めます。ドメインルール、データモデル、入力チェック、API通信、同期状態は共通層に置き、カメラ、通知、暗号化ストレージ、生体認証などはexpect／actualや各OSのアダプターで分離します。画面はネイティブUIを基本とし、共有UIを採用する画面だけ別途アクセシビリティと操作性を評価します。

ソースコードだけでなく、設計書、テスト仕様、依存ライブラリ一覧、SBOM、CI/CD設定、署名とリリース手順も納品対象にします。Kotlin、KMP、Compose、Xcode、Gradle、ライブラリの組み合わせは更新で変わるため、誰が互換性を確認し、どの頻度で更新するかを決めておきます。

テスト・リリース・定着までを計画します

共通ロジックの単体テストに加えて、AndroidとiOSの結合テスト、実機テスト、OSバージョン別テスト、通信断テスト、同期競合テストを行います。現場業務では、入力を急いだとき、端末を交換したとき、途中でアプリを終了したとき、同じデータを複数人が更新したときに不具合が出やすいため、理想的な通信環境だけで確認してはいけません。

リリース後は、クラッシュ率、同期失敗率、APIエラー、処理時間、利用率、問い合わせ件数を追跡します。現場の利用者に操作教育を行い、紙やExcelとの二重入力をいつ終了するかも決めます。システムを導入しても業務ルールやマスタが整理されていなければ、不正確なデータを速く作るだけになるため、定着支援を開発計画に含めます。

費用相場とコストの内訳

KMP専用の国内公的統計は確認できないため、以下は2025〜2026年に公開されたモバイルアプリや業務システムの見積もり例を、KMPの構成に当てはめた目安です。実際の費用は、画面数よりもAPIの複雑さ、オフライン、権限、データ移行、端末検証、運用要件で大きく変わります。KMPを採用すれば自動的に半額になるとは考えず、共通化で減る工数と、初期の基盤整備で増える工数を分けて見ます。

▶ 詳細はこちら：Kotlin Multiplatformのシステム開発の見積相場や費用/コスト/値段について

▶ 詳細はこちら：Kotlin Multiplatformのシステム開発の発注/外注/依頼/委託方法について

規模別の費用と期間の目安

技術検証や共有モジュールのPoCは、認証、API、1機能、AndroidとiOSのビルドを対象に100万〜300万円、1〜2か月程度が目安です。小規模な社内業務アプリは、5〜15画面、ログイン、一覧・登録、簡易管理画面を含めて500万〜1,000万円、3〜5か月程度を見込みます。

API連携が複数あり、20〜50機能、オフライン、通知、権限、端末検証まで必要な中規模案件は1,500万〜3,000万円、6〜10か月程度が一つの目安です。複数拠点、基幹連携、データ移行、監査、SLA、24時間運用を含む大規模案件は3,000万〜8,000万円以上、12〜24か月以上になることがあります。2026年の公開相場でも、業務システム連携アプリは500万〜1,500万円、大規模なサービスアプリは1,500万円以上というレンジが示されています（出典：国内アプリ開発会社の2026年費用解説、2026年7月確認）。

既存AndroidやiOSをKMPへ段階移行する場合は、共有効果の高い認証、通信、ドメイン層から始めて300万〜1,500万円程度、2〜12か月程度を想定します。ただし、既存コードの品質、テスト不足、外部SDK、画面とロジックの密結合によって幅が広がります。これはKMPの定価ではなく、要件と既存資産に基づく推定です。

見積書では共通コード以外の費用も分けて確認します

費用の内訳は、企画・要件定義、UI／UX、共通モジュール、Android固有、iOS固有、API・データベース、管理画面、テスト、CI/CD、ストア申請、データ移行、教育、保守に分けます。業務システムでは、アプリ本体だけでなくAPIや管理画面が総工数の大部分を占めることがあります。共通化によってアプリ側の重複実装が減っても、バックエンド、テスト、実機検証、リリース作業が消えるわけではありません。

費用配分は、要件定義10〜15％、基本設計15〜20％、開発30〜40％、結合・総合テスト15〜20％、移行・導入5〜10％を起点に考えられます。これは業務システムの一般的な配分を使った概算であり、UIを共有するか、オフラインを実装するか、既存APIを改修するかで変動します。見積書に「一式」しかない場合は、作業範囲と成果物を再確認します。

保守費と更新費を初期見積もりに含めます

リリース後は、OSアップデート、KMPやライブラリの更新、脆弱性対応、証明書、ストア申請、クラウド、監視、障害対応、軽微な改善が発生します。年間保守費は初期開発費の15〜20％程度を一つの目安にできますが、24時間監視や厳しいSLA、頻繁な機能改善を含めると上振れします（出典：2026年の国内iOSアプリ費用解説、2026年7月確認）。

見積もりでは、更新作業を誰が行うか、互換性検証の対象バージョン、緊急時の対応時間、依存ライブラリの脆弱性通知、端末紛失時のデータ削除、ログの保管期間を確認します。初期費用だけでなく、3年または5年の総保有コストで比較すると、安価に見える構成が長期的に高くなるリスクを抑えられます。

セキュリティ・品質・運用で確認すること

業務アプリは、端末に個人情報、営業情報、位置情報、作業記録を保持することがあります。KMPを使うかどうかに関係なく、端末保存、認証・認可、通信、プライバシー、ログ、脆弱性対応を要件化します。モバイルアプリのセキュリティ基準では、機微データの安全な保存、認証・認可、ネットワーク、プライバシーなどを確認項目として整理できます（出典：OWASP MASVS、2026年8月確認）。

端末に保存するデータと権限を最小限にします

端末には、必要な期間と項目だけを保存し、機微情報は暗号化や安全なOSストレージを利用します。アクセストークン、キャッシュ、添付ファイル、ログに個人情報が混ざらないかも確認します。認証済みでも、利用者の所属、拠点、役職、担当案件に応じてAPI側で認可を行い、アプリの画面を隠すだけで権限管理を終えないことが重要です。

カメラ、位置情報、通知、Bluetoothなどの権限は、なぜ必要かを利用者に説明し、拒否された場合の代替フローを用意します。端末を紛失した場合は、アカウント停止、セッション無効化、遠隔削除、監査ログ確認の手順を決めます。個人情報を扱う場合は、委託先管理、保管場所、越境移転、漏えい時の報告と連絡も法務・情報システム部門と確認します。

CI・テスト・監視を共有コードの前提にします

共有コードは一度の修正が複数OSに影響するため、単体テストと自動ビルドを早い段階で整備します。プルリクエストごとに共通コードのテスト、Androidビルド、iOSビルド、静的解析を実行し、主要端末では定期的に画面と業務フローを確認します。依存ライブラリを更新する前には、互換性、脆弱性、ビルド時間、アプリサイズを記録します。

運用監視では、APIエラーとアプリのクラッシュだけでなく、同期キューの滞留、端末時刻のずれ、データ競合、通知未達も対象にします。障害の一次切り分けで、共通コード、Android固有、iOS固有、APIのどこに問題があるか分かるログ設計にします。エラー内容に顧客情報やアクセストークンを出力しないことも忘れてはいけません。

開発会社／ベンダーの選び方

KMPの開発会社を選ぶときは、KMPという技術名だけでなく、業務要件から設計し、AndroidとiOSを長期運用できるかを見ます。KMP専門の支援会社、モバイルに強い受託会社、業務システムとAPIまで扱う会社では、得意範囲と契約の進め方が異なります。自社の課題に必要な体制を先に定義してから比較します。

公開実績ではなく担当範囲と成果物を確認します

実績確認では、KMPを試しただけなのか、本番で複数OSを運用しているのかを分けて質問します。新規開発と既存アプリ移行のどちらに強いか、UIをネイティブと共有UIの両方で設計できるか、オフライン、カメラ、通知、端末管理、API連携に対応できるかを確認します。可能なら、共通コードのテスト、障害対応、リリース後の更新まで含む事例を説明してもらいます。

契約前には、ソースコード、設計書、テスト仕様、CI/CD設定、依存関係一覧、SBOM、アプリストアのアカウント、知的財産権の帰属を確認します。納品後に自社で保守する場合は、コードレビューや引き継ぎ、内製化支援の時間も見積もりに入れます。特定の担当者だけに知識が偏らない体制かも重要です。

見積もり前に同じ質問を投げて比較します

候補先には、共通化率を何％と見込むかではなく、どの機能を共有し、どの機能をOS別に実装するかを示してもらいます。iOS固有工数、実機テスト台数、API改修、データ移行、CI整備、ストア申請、保守を別々に記載してもらうと、会社ごとの見積条件をそろえられます。安い提案ほど、含まれない作業と追加料金の条件を確認します。

プロジェクト管理では、要件変更の扱い、課題管理、品質基準、受け入れ条件、リリース判定、障害時の連絡経路を確認します。KMPの技術リードだけでなく、業務を理解する担当者、iOSとAndroidの実装担当、バックエンド担当、QA担当が必要です。体制図と役割分担が曖昧なまま契約すると、共通化の判断が後工程に持ち越されます。

▶ 詳細はこちら：Kotlin Multiplatformのシステム開発でおすすめの開発会社/ベンダー6選と選び方

失敗しやすいパターンと対策

KMPの失敗は、言語やフレームワークの問題だけで起きるわけではありません。業務を整理せずに画面を増やす、共通化率を目標にする、iOSの実機検証を後回しにする、保守担当を決めないといった計画上の問題が、品質と費用に直結します。

画面、ナビゲーション、通知、端末設定まで一つの実装に寄せると、OS固有の使いやすさやアクセシビリティを損ねる場合があります。共通化率をKPIにせず、業務ロジックの重複削減、バグの修正回数、リリース速度、テスト工数など、事業に近い指標で判断します。共有の境界は固定せず、実機と利用者の評価を見ながら調整します。

開発完了後の更新と内製化を考えていない

開発会社がKMPの基盤を作っても、OS更新や依存ライブラリの更新は続きます。更新を止めると、ストア審査、脆弱性、ビルド環境の問題が一度に現れます。保守契約の範囲、内製化の時期、コードレビューの方法、緊急修正の体制をリリース前に決めます。

また、現場の利用者を要件定義に参加させず、紙の運用をそのままアプリへ置き換えることも危険です。入力項目を減らせるか、マスタを統合できるか、承認の責任者を明確にできるかを先に議論します。KMPは業務改善を自動化する技術ではないため、業務標準化と定着支援を同時に進めます。

よくある質問（FAQ）

KMPの導入では、技術の安定性だけでなく、既存資産、チーム、業務の複雑さ、運用責任を合わせて判断します。ここでは、発注前によく出る質問に直接回答します。

Kotlin Multiplatformなら開発費は必ず安くなりますか？

必ず安くなるわけではありません。共通ロジックが多いAndroid・iOSの長期運用では、二重実装や保守の重複を減らせる可能性がありますが、PoC、iOS連携、CI整備、実機検証、バックエンド、保守費は必要です。初期費用と3〜5年の総保有コストを分け、共通化の対象と削減効果を見積書で確認します。

iOSの知識やSwiftの担当者は必要ですか？

必要です。KMPで共有ロジックを書いても、iOSのライフサイクル、権限、通知、ストレージ、画面遷移、審査、実機の不具合を扱うにはiOSの知識が欠かせません。Kotlinだけで全てを完結させる体制ではなく、共通コードとSwiftUI／UIKitなどの接続点を理解する担当者を置くことが安全です。

オフライン対応の業務システムにも使えますか？

使えますが、オフラインを前提にしたデータ設計が必要です。端末に保存するデータ、入力の期限、再送、重複防止、複数端末での競合解決、同期失敗時の利用者への案内を決めます。KMPでは同期やバリデーションの共通ロジックを共有しやすい一方、ネットワーク状態やバックグラウンド処理などのOS差分は個別に検証します。

既存のAndroidアプリを残したまま導入できますか？

できます。認証、データモデル、API通信、入力チェックなど、既存画面から分離しやすい部分を共有モジュールへ移し、Androidで動作を確認してからiOSへ展開する段階移行が一般的です。ただし、既存コードと画面が密結合している場合は、先にテストを追加し、移行対象と見送る対象を分ける必要があります。

まとめ

採用判断では共通化の範囲を先に決めます

KMPは100％共通化を目指す技術ではなく、業務ロジック、データ、通信、同期など、複数OSで同じ品質を保ちたい部分を選んで共有する技術です。画面や端末機能は、利用者の操作性とOSの特性を確認しながら個別実装または共有UIを選びます。

発注前にPoC・費用・保守を一つの計画にします

現行業務を整理し、PoCで技術リスクを確認し、共通コード、OS固有実装、API、テスト、運用の費用を分けて比較します。開発会社／ベンダーには、納品後の更新、セキュリティ、障害対応、内製化まで含む体制を確認してから契約します。

Kotlin Multiplatformのシステムは、AndroidとiOSの業務ロジックを共有し、両OSのネイティブ機能も活かせる選択肢です。KMPとCompose Multiplatformを分けて考え、最初は認証、通信、データ、バリデーション、同期など効果の高い層から共通化することが重要です。

導入前には、現行業務の棚卸し、オフラインや監査の要件化、小さなPoC、実機テスト、CI、保守体制を確認します。費用はPoCで100万〜300万円、小規模で500万〜1,000万円、中規模で1,500万〜3,000万円、大規模で3,000万〜8,000万円以上を一つの目安とし、共通コード以外のAPI、管理画面、QA、移行、運用を含めて比較します。

開発会社／ベンダーは、KMPの実績だけでなく、業務要件、iOSとAndroidの固有機能、セキュリティ、成果物、引き継ぎ、リリース後の更新まで説明できるかで選びます。自社にとってKMPが適切か迷う場合は、採用する条件と見送る条件をRFPに明記し、同じ質問で複数の提案を比較してください。