LASSIC Media らしくメディア
Kotlin Multiplatform（KMP）開発を外注する費用と委託先の選び方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- KMPはビジネスロジックを共通化しつつUIを各プラットフォームのネイティブに保てるため、既存アプリへの部分導入が可能という特性があります
- Flutter/React Nativeとの違いと、KMP対応エンジニアの希少性を理解してから外注先を選ぶと、後工程のリスクを下げられます
- 外注費用はロジック共通化の範囲と対象プラットフォーム数によって大きく異なり、要件定義フェーズでの複数社見積もりが実態把握の近道です
目次
KMPとは — ロジック共通化・UIは選択という特性
Kotlin Multiplatform（KMP）外注開発とは、KotlinでiOS・Android・Webなど複数プラットフォーム向けのビジネスロジックを共通コードとして開発し、その設計・実装を外部パートナーに委託する開発形態を指します。
KMPが他のクロスプラットフォーム技術と大きく異なるのは、「UIまで含めてすべてを共通化する」のではなく、「共通化するのはビジネスロジック層に留め、UIは各プラットフォームのネイティブコンポーネントで実装する」という設計思想にあります。
具体的に共通化できる層は、ネットワーク通信（Ktor）、データ永続化（SQLDelight）、ドメインロジックやViewModelです。一方、UIレイヤーはiOSであればSwiftUI・UIKit、AndroidであればJetpack Composeをそれぞれ使うのが基本です。この「ロジック共通・UIは選択」という設計が、KMPを他のクロスプラットフォーム技術と区別する中心的な特性です。
KMPは2023年11月にJetBrainsがKotlin Multiplatform（KMP）をStableとして正式リリースしました。Google（Android）もKMPを公式にサポートしており、AndroidX（Room、DataStore等）のKMP対応が進んでいます。JetBrainsの公式発表はJetBrains公式ブログ（2023年11月）で確認できます。
Flutter/React Nativeとの違いとKMPが向くケース
クロスプラットフォーム開発の選択肢としてFlutterやReact Nativeと比較されることが多いですが、KMPは設計の前提が根本的に異なります。
| 比較軸 | KMP | Flutter | React Native |
|---|---|---|---|
| 共通化の対象 | ビジネスロジック層（選択的） | UI含む全層 | UI含む全層 |
| UI描画 | 各OS ネイティブ（SwiftUI / Compose） | 独自エンジン（Skia/Impeller） | ネイティブコンポーネントへのブリッジ |
| 使用言語 | Kotlin（共通）＋Swift/Kotlin（UI） | Dart | JavaScript/TypeScript |
| 既存ネイティブへの部分導入 | しやすい（段階導入が得意） | 難しい（フルスコープ前提） | できるが設計コストが高い |
| ネイティブ体験 | 損ないにくい（UIはネイティブ） | 独自描画なので差異が出ることがある | ネイティブコンポーネントだが調整が必要なことがある |
| 対応プラットフォーム | iOS/Android/Web/Desktop | iOS/Android/Web/Desktop | iOS/Android中心 |
KMPが向くケースは主に3つです。第一に、既存のiOS・Androidネイティブアプリを保有している場合です。二重管理になっているビジネスロジックをKMPに移行し、UIはそれぞれのネイティブのまま保つことができます。
第二に、プラットフォーム固有のネイティブ体験を優先したい場合です。金融・医療・エンタープライズ向けアプリのように、iOS/Androidそれぞれのデザインガイドラインやアクセシビリティへの対応が厳格に求められるケースでは、独自描画エンジンに依存しないKMPが選ばれやすいです。
第三に、段階的にクロスプラットフォーム化を進めたい場合です。一度にフルスコープで移行するのではなく、まずネットワーク層だけ共通化するといったアプローチが取れるため、既存サービスへのリスクを抑えながら導入できます。
逆に、ゼロからアプリを立ち上げてUIも含めてコードを一元管理したい場合や、Dartエンジニアを確保しやすい環境であればFlutterの方が適している場合もあります。要件と既存資産を整理した上で選択してください。
Compose Multiplatformの位置づけ — UIも共通化する選択肢
KMPのエコシステムには、Compose Multiplatform（JetBrains製のUI共通化ライブラリ）も存在します。これはAndroid向けのJetpack ComposeをiOS・Web・Desktopにも展開するもので、KMP上でUIも共通コードで記述できるようになります。
Compose MultiplatformのiOS対応は、2025年5月リリースのバージョン1.8.0で正式にStable（安定版・プロダクション対応）となりました。JetBrainsは積極的にiOS対応を推進しており、プロダクション利用の事例も出始めていますが、Stable（安定版）とは言えない部分があります。最新の安定状況はJetBrains公式（Compose Multiplatform公式ページ）で確認されることをお勧めします。
KMPとCompose Multiplatformの関係を整理すると、以下のようになります。
- KMP（ロジックのみ共通化）：UIはSwiftUI/Jetpack Composeをそれぞれネイティブで実装。最もネイティブ体験に近く、既存アプリへの部分導入もしやすい
- KMP + Compose Multiplatform（UI含め共通化）：ビジネスロジックとUIを一つのKotlinコードベースで管理できる。iOSのCompose対応は2025年5月にStableに到達。採用時はKotlinバージョン追随や保守体制を確認
外注を検討する際は、委託先がCompose MultiplatformのiOS対応の成熟度をどう評価しているかを確認することが重要です。「UIも共通化できる」という提案を受けた場合は、現時点での安定性リスクと保守コストを合わせて確認してください。
KMP外注開発の費用相場と費用に影響する要素
KMP外注開発の費用は、共通化する範囲・対象プラットフォーム数・エンジニアの希少性によって大きく変わります。以下は市場参考値であり、一次資料に基づく確定値ではありません。実際のプロジェクトでは要件定義フェーズでの複数社見積もりを経て確認してください。
| 開発スコープ | 費用の目安（市場参考値） | 主な内容 |
|---|---|---|
| 既存アプリへの部分導入 （ロジック層のみKMP化） |
数百万円台〜 | ネットワーク・データ層の共通化。 既存UIはそのまま維持。 |
| iOS/Android新規KMPアプリ （ロジック共通・UIはネイティブ） |
700万〜1,500万円程度 | 共通ロジック＋各OSネイティブUI実装。 機能規模・工期による変動大。 |
| KMP + Compose Multiplatform （UI含め共通化） |
1,000万〜2,500万円以上 | UI共通化の設計コスト増。 iOSのCompose対応の検証工数を含む。 |
費用に影響する主な要素は以下の通りです。
- 共通化するロジックの複雑度：オフライン同期・暗号化・プッシュ通知処理など複雑なビジネスロジックほど工数が増えます
- 対象プラットフォーム数：iOS/AndroidだけでなくWeb・Desktopにも対応する場合、各プラットフォーム固有の実装コストが加算されます
- 既存コードの品質と移行コスト：既存アプリへのKMP部分導入では、既存コードの設計依存度によってリファクタリング工数が大きく変わります
- KMP対応エンジニアの希少性：KMPエンジニアは国内では絶対数が少ないため、単価は一般的なAndroid開発より高めになる傾向があります
特にKMPエンジニアの希少性は費用に直結します。KotlinとiOSの両方に精通し、さらにKMPエコシステム（Ktor・SQLDelight・Coroutinesなど）の実務経験がある人材は、国内市場では採用が難しい状況にあります。この人材確保の課題を外注で解決するという判断が、KMP開発外注の実用的な理由の一つです。
内製でKMPチームを組む場合、KMPエンジニアの採用・育成には半年から1年規模のリードタイムを要することもあります。プロジェクトのタイムラインと比較した上で、外注の活用を検討することをお勧めします。
外注先と進める開発フロー — 要件定義からリリースまで
KMP外注開発を外部委託先と進める際の標準的なフローは以下の5ステップです。要件定義フェーズを省略すると、共通化の範囲が確定せず手戻りリスクが高まります。
- 要件定義・技術選定：共通化するロジック層の範囲を確定。UIをネイティブにするかCompose Multiplatformを使うか、対象プラットフォームを決定します
- PoC（概念実証）：共通化の核心となるモジュールを小規模に試作。iOS・Android双方でのビルド・動作を検証します
- 設計・アーキテクチャ決定：共通コード（commonMain）と各プラットフォーム固有コード（iosMain/androidMain）の分離設計。依存性注入（DI）やテスト設計も含めます
- 開発・テスト：共通ロジックの実装と単体テスト（kotlinx.coroutines test等）、各プラットフォームのUI実装とUIテストを並行します
- ストア審査・リリース：iOS App StoreとGoogle Play、両プラットフォームの審査基準に沿ったメタデータ・スクリーンショット準備を行います
KMP開発で外注先に確認すべき技術的な観点があります。KMPプロジェクトでは、Gradleのビルド設定（Kotlin Multiplatform Gradle plugin）の管理が重要です。ビルド設定の誤りが原因でiOS向けフレームワーク（XCFramework）のエクスポートに失敗するケースがあり、この部分の経験が外注先の技術力を判断する指標になります。
また、共通コードとiOS固有コードの橋渡しにはexpect/actual機構（KMPにおいてプラットフォーム固有の実装を注入する仕組み）を使います。この機構を正しく設計できるかどうかが、保守性・拡張性を左右します。
KMP実績・希少人材確保を見極める委託先の選び方
KMP対応の外注先を選ぶ上で確認すべき点は、一般的なアプリ開発会社の評価軸とは異なります。KMPに特有の技術力と実績を具体的に確認してください。
- KMPを使ったプロジェクト実績：「Kotlin経験あり」ではなく「KMPプロジェクトの完成実績」を具体的に確認します。GitHubのリポジトリやポートフォリオを提示してもらうとよいでしょう
- iOS開発（Swift/SwiftUI）の対応力：KMPは「Kotlinが書ける」だけでは不十分です。iOS側のUIをSwiftUIで実装する担当者の在籍と実績を確認してください
- KMPエコシステムの習熟：Ktor（ネットワーク）・SQLDelight（DB）・kotlinx.serialization・Coroutinesなどのライブラリ実務経験があるかを確認します
- Gradleビルド管理とXCFramework出力の経験：iOS向けフレームワーク生成の実務経験は、KMP開発の完成度を左右する重要な技術力です
- 保守・アップデート体制：KMPはKotlinのバージョンアップに追随する必要があります。リリース後の保守担当者とサポート範囲を契約前に確認してください
国内でKMP対応を明示している開発会社は限られています。見積もり依頼時に上記の観点で質問し、具体的な回答ができるかどうかで技術力を見極めてください。「KMPもできます」という曖昧な回答ではなく、「こういう構成で実装します」という具体的な提案が出てくるかどうかが判断の目安になります。
外注先との契約形態は、要件が固まっていない段階では準委任契約（作業内容を委託する形態）で要件定義・PoCを進め、スコープが確定した後で請負契約（成果物を委託する形態）に切り替えるパターンが現実的です。KMPの技術的不確実性を考えると、最初から請負で全スコープを固定することは双方にリスクがあります。
内製チームにKMP経験者がいない場合、要件定義から外注先と一緒に進めることで、自社のエンジニアがKMPのアーキテクチャを理解しながら開発に参加できます。これは長期的な保守コスト削減にもつながります。
まとめ：KMP外注で押さえる3つの判断軸
本稿では、KMP外注開発の特性・費用・進め方・委託先の選び方を整理しました。要点を3つにまとめると次の通りです。
第一に、KMPは「UIを各プラットフォームのネイティブに保ちつつビジネスロジックだけを共通化する」という特性があります。FlutterやReact Nativeとは設計の前提が異なり、既存ネイティブアプリへの段階導入が得意です。この特性を正しく理解しているかどうかが、外注先の技術力を見極める第一の軸です。
第二に、費用はロジック共通化の範囲とプラットフォーム数によって幅があります。部分導入から始める場合と新規フルスコープでは費用感が大きく変わります。要件定義フェーズを外注先と丁寧に進め、複数社見積もりで実態を把握することが費用管理の基本です。
第三に、KMP対応エンジニアは国内では希少です。委託先選びではKMP固有の実績（ポートフォリオ・iOS/Android両方の開発力・KMPエコシステムの習熟）を具体的に確認してください。曖昧な「対応可能」ではなく、具体的な提案内容で技術力を見極めることが、後工程のリスクを下げる判断軸になります。
よくある質問
KMPとFlutterはどちらを選べばよいですか？
目的によって選択が異なります。既存のiOS/Androidネイティブアプリを保有しており、UIはネイティブのまま共通ロジックだけを統合したい場合はKMPが向いています。一方、ゼロからクロスプラットフォームアプリを立ち上げ、UIも含めてコードを統一したい場合はFlutterが候補になります。外注先に両案を提示してもらい、既存資産・チームスキル・保守計画を踏まえて判断することをお勧めします。
KMP開発を外注する費用の目安はどのくらいですか？
共通化する範囲と対象プラットフォーム数によって大きく変わります。既存ネイティブアプリへのKMP部分導入（ネットワーク・データ層のみ共通化）であれば数百万円台から着手できる場合があります。新規にiOS/Android両対応のKMPアプリをフルスコープで開発する場合は、1,000万円以上になるケースも珍しくありません。いずれも市場参考値であり、一次資料に基づく確定値ではありません。要件定義フェーズで複数社から見積もりを取ることが実際のコスト把握への近道です。
Compose MultiplatformとKMPは別物ですか？
Compose MultiplatformはKMPのエコシステムの一部として位置づけられます。KMPがビジネスロジックをプラットフォーム間で共通化する仕組みであるのに対し、Compose MultiplatformはJetBrainsが開発したUI共通化ライブラリです。2025年5月リリースのバージョン1.8.0でiOS対応が正式にStable（安定版・プロダクション対応）となりました。最新の安定状況は公式リリースノートでの確認をお勧めします。UIも含めてKMPで統一したい場合はCompose Multiplatformの活用が選択肢になりますが、成熟度を考慮した採用判断が必要です。
KMP開発ができる外注先はどうやって見つければよいですか？
KMP対応エンジニアは国内では希少なため、まずは開発実績の有無を直接確認することが重要です。具体的には、KMPを使ったプロジェクトのポートフォリオ、iOS/Android両方の開発経験者の在籍状況、Kotlinへの習熟度（Coroutines・Ktor・SQLDelightなどKMPエコシステムのライブラリ経験）を確認するとよいでしょう。公式のKotlin Multiplatformコミュニティや国内の技術カンファレンスで実績を持つベンダーを探す方法も有効です。
既存のAndroidアプリにKMPを部分導入することはできますか？
可能です。KMPの大きな特徴の一つが、既存ネイティブアプリへの段階的な部分導入です。たとえば、既存のAndroid（Kotlin）アプリのネットワーク通信層やデータモデル層だけをKMPの共通コードに切り出し、iOSアプリにも同じロジックを使い始めるというアプローチが取れます。UIは引き続きSwiftUIとJetpack Composeでそれぞれネイティブに保てるため、ユーザー体験への影響を最小化しながらコードの二重管理を段階的に解消できます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：JetBrains「Kotlin Multiplatform Is Stable and Production-Ready」（2023年11月）
