--- title: "Kotlin Multiplatform（KMP）とFlutter・React Native比較｜導入判断" url: "https://www.issoh.co.jp/tech/details/3310/" published: 2024-08-08 updated: 2026-08-01 categories: ["アーキテクチャ"] publisher: "株式会社一創" --- # Kotlin Multiplatform（KMP）とFlutter・React Native比較｜導入判断 Kotlin Multiplatformは、AndroidとiOSで同じコードを動かす仕組みのなかでも位置づけが特殊です。FlutterやReact Nativeが画面まで共通化するのに対し、KMPが共有するのはビジネスロジックで、UIはプラットフォームごとに書くことも、Compose Multiplatformで共通化することも選べます。採用判断はほぼこの一点で決まります。KMPの基本概念と仕組みは[Kotlin Multiplatformとは？その概要と基本的な仕組みを理解する](/column/details/3459/)で扱っているので、本記事は他技術との比較と、2026年7月時点で本番採用してよい範囲に絞ります。 ## まとめ：採用可否の結論 先に判断の分岐点を出します。**既存のAndroidアプリがKotlinで書かれていて、iOS版と共通化したいのはロジックだけ**——この条件ならKMPが最も無理のない選択です。画面の作りをネイティブのまま維持でき、共通化する範囲を自分で決められます。 KMPの利点は、共有する範囲を自分で決められることに尽きます。通信・データ変換・バリデーション・課金判定だけを共通化し、画面はネイティブのまま残す、という選び方ができます。逆に**UIも含めて一気に共通化して開発コストを半分にしたい**のであれば、KMPは期待に応えません。UIを共通化するには[Compose Multiplatform](https://www.issoh.co.jp/tech/details/16032/)を別途採用することになり、そこはFlutterと同じ土俵の勝負になります。この場合は成熟度で選ぶほうが合理的です。 本番投入の可否はターゲットで分かれます。Android・iOS・デスクトップ・サーバーサイドはStableですが、**Kotlin/WasmによるWebはコア・Compose Multiplatformともにまだ Beta** です。Webを含む3プラットフォーム展開を前提にするなら、この一点が制約になります。 ## FlutterやReact Nativeとの違い｜共通化する層で分かれる 3者の決定的な違いは、共通化する層です。Flutterは独自の描画エンジンで画面まで描き、React NativeはJavaScriptからネイティブUIを操作します。どちらもUIを共通化する前提で作られています。KMPはそこを空けてあり、UIはネイティブのまま残せます。 | 観点 | Kotlin Multiplatform | Flutter 3.44.8 | React Native 0.86.2 | | ----------- | ------------------------ | ------------------ | ----------------------- | | 共通化する層 | ロジック（UIは選択制） | ロジック＋UI | ロジック＋UI | | 言語 | Kotlin | Dart | JavaScript / TypeScript | | UIの描画 | ネイティブ or Compose | 独自エンジンで描画 | ネイティブUIを操作 | | 既存アプリへの部分導入 | 共有モジュールを追加 | 可（add-to-app・画面単位） | 可（画面単位） | | Web対応 | Wasmは Beta | 対応 | 別途react-native-web | | 見た目の一致 | ネイティブUIならOS差／Composeなら揃う | 完全に揃う | ネイティブ部品由来のOS差が残る | ここから導ける判断は単純です。**すでに動いているネイティブアプリがあるならKMP**、**ゼロから作り、デザインを完全に統一したいならFlutter**です。KMPは共有モジュールをライブラリとして既存プロジェクトに追加できるため、全面刷新を避けられます。FlutterにもReact Nativeにも既存アプリへ組み込む方法（Flutterのadd-to-app）はありますが、そちらは画面単位の埋め込みになり、ビルドと状態管理の構成が複雑になります。 チームの言語も現実的な制約です。AndroidエンジニアがKotlinを書けるなら、KMPの共有モジュールに新しい言語の学習は要りません。[Androidアプリ開発の言語はKotlinとJavaのどちらか？選定基準と環境まで解説](/tech/details/15321/)で触れているとおり、AndroidのKotlin移行はすでに前提になっているため、この点でKMPは有利です。 ## ターゲット別の安定性｜Webだけ扱いが違う KMPは「すべてのプラットフォームで安定している」わけではありません。公式が公開しているターゲット別の安定性は次のとおりです（2026年7月時点）。 | ターゲット | コアKMP | Compose Multiplatform | | ---------------- | ------ | --------------------- | | Android | Stable | Stable | | iOS | Stable | Stable | | デスクトップ（JVM） | Stable | Stable | | サーバーサイド（JVM） | Stable | 該当なし | | Web（Kotlin/JS） | Stable | 該当なし | | Web（Kotlin/Wasm） | Beta | Beta | | watchOS / tvOS | Beta | 該当なし | 実務で効くのは**Web（Wasm）がBetaに留まっている**点です。Betaは互換性のない変更が入りうる段階なので、Web版を長期運用する前提の案件では、移行作業が発生する可能性を見込む必要があります。Kotlin/JSはStableですが、こちらはCompose Multiplatformの対象外で、UIは別途用意します。 iOSは、コアもCompose MultiplatformもStableです。Compose MultiplatformのiOS対応がStableになったのは1.8.0（2025-05-06公開）で、それ以前はAlpha・Betaの段階でした。ただしStableは「動作が保証される」という意味であり、iOSらしい挙動が自動で得られるという意味ではありません。スクロールの慣性やナビゲーションの作法に差が出るため、UIをネイティブで書く選択肢は依然として有効です。 ## Kotlin 2.4.10とCompose Multiplatform 1.11.1｜版の依存関係 採用検討時に確認すべき版は3つです。Kotlin本体の最新安定版は**2.4.10（2026-07-14公開）**、Compose Multiplatformは**1.11.1（2026-06-02公開）**で、1.12.0は2026-07-28時点でbeta03です。KMPの機能はKotlin本体のリリースサイクルに乗るため、Kotlinの版を上げずにKMPだけ新しくすることはできません。 この関係は導入計画に影響します。既存のAndroidプロジェクトがKotlinの古い版で止まっている場合、KMP導入の第一歩はKotlinのアップグレードになります。Gradleプラグインとの互換も同時に確認してください。 ## 開発環境の要件｜IDEとiOSビルドの前提 ### IDEとプラグインの最小版 導入判断の段階で見落とされやすいのが環境の制約です。KMPの開発にはIntelliJ IDEAまたはAndroid Studioと、**Kotlin Multiplatform IDEプラグイン**が必要です。公式が求めるIDEの最小版はIntelliJ IDEA 2025.2.2以上、Android Studioは Otter 2025.2.1 以上で、プラグインが依存関係もあわせて導入します。 プロジェクトの新規作成はIDEのウィザードから行います。IntelliJ IDEAなら「File → New → Project」でKotlin Multiplatformを選び、Android・iOS・デスクトップ・Web・サーバーのうち必要なターゲットにチェックを入れます。Android Studioでは「Phone and Tablet」カテゴリの中にKotlin Multiplatformのテンプレートがあります。 ### iOSビルドに必要なmacOS環境 **iOS向けのビルドにはmacOSとXcodeが必須です。**これはKMPの制約ではなくAppleのツールチェーンの制約なので回避できません。Xcodeはインストール後に一度起動して初期セットアップを終える必要があり、Xcodeを更新するたびに手動での再起動とツールのダウンロードが要ります。WindowsやLinuxの端末しかないチームでは、iOSターゲットのビルドと実機確認ができない点を計画に織り込んでください。 JDKはJetBrains Runtime（JBR）の利用が推奨されています。公式が挙げる理由は、クラスの再定義に対応しておりデスクトップ向けKMPアプリの互換性が上がることです。IntelliJ IDEAには同梱されているので、IDE経由で開発する限り追加の準備は不要です。環境変数は`JAVA_HOME`とAndroid SDKを指す`ANDROID_HOME`を設定します。 ## KMPのデメリットと、採用を見送るべき条件 次のいずれかに当てはまるなら、KMPの採用は見送るか、時期をずらすほうが安全です。 - **チームにKotlin経験者がいない**。共有モジュールはKotlinで書きます。JavaScript資産を活かしたいならReact Native、新規で言語を選べるならFlutterのほうが立ち上がりが速くなります。 - **Webを本番の主戦場にする**。Kotlin/WasmはBetaです。Webが売上の中心なら、成熟した選択肢を採るべきです。 - **UIの実装コストを削るのが最大の目的**。KMP単体はUIを共通化しません。Compose Multiplatformを併用する前提なら、Flutterと同じ比較軸で成熟度を評価してください。 - **アプリが画面表示中心でロジックが薄い**。共有する対象が少なければ、マルチプラットフォーム構成の管理コストだけが残ります。 逆に、決済・同期・オフラインキャッシュ・課金判定のように**両OSで完全に同じ挙動をさせたいロジックが厚い**アプリでは、KMPの効果がはっきり出ます。共有した範囲では実装のズレによるバグが発生しなくなるためで、これは行数の削減より価値があります。 ## よくある質問 ### KMMとKotlin Multiplatformは違うものですか？ KMM（Kotlin Multiplatform Mobile）は、Kotlin MultiplatformのうちAndroidとiOSに絞った呼び名として使われていた名称です。現在はモバイル以外のターゲットも含めてKotlin Multiplatform（KMP）に呼称が統一されており、新しい資料でKMMという表記を見かけることは少なくなっています。指しているものは同じ技術です。 ### KMPでiOSアプリのUIも共通化できますか？ できます。Compose MultiplatformのiOS対応はStableです。ただしUIを共通化するかどうかは選択で、公式もロジックだけを共有してUIはネイティブで書く構成を対等な選択肢として案内しています。OSごとの操作感を優先するなら後者、開発リソースを優先するなら前者になります。 ### KMPとFlutterはどちらが良いですか？ 既存のネイティブアプリに部分的に導入したいならKMP、ゼロから作って見た目を完全に統一したいならFlutterです。KMPは共有モジュールをライブラリとして既存プロジェクトへ追加できる一方、Flutterはアプリ全体をFlutterで構成する前提のため、途中からの部分導入には向きません。 ### KMPは本番で使える段階ですか？ Android・iOS・デスクトップ・サーバーサイドについてはStableで、本番利用が想定された段階です。Web（Kotlin/Wasm）とwatchOS・tvOSはBetaのため、互換性のない変更が入る可能性を見込んだうえで判断してください。 ### KMPを導入するとコードはどれくらい共通化できますか？ 共通化できる割合はアプリの構成で大きく変わるため、一律の目安は当てになりません。判断の目安になるのは行数ではなく、「両OSで同じ挙動をさせたいロジックがどれだけあるか」です。通信・データ変換・バリデーション・状態管理が厚いアプリほど共有できる範囲が広がり、画面表示が中心のアプリでは共有対象が少なくなります。 ## 関連記事 - [Kotlin Multiplatformとは？その概要と基本的な仕組みを理解する](/column/details/3459/) - [Androidアプリ開発の言語はKotlinとJavaのどちらか？選定基準と環境まで解説](/tech/details/15321/) - [Kotlinとは？Javaとの違いとK2コンパイラ・2.4系の現在地を実装者目線で解説](/tech/details/15789/) - [Lynxとは？ByteDance製クロスプラットフォーム開発フレームワークの特徴とReact Native・Flutterとの違い](/tech/details/5715/) --- 出典: [Kotlin Multiplatform（KMP）とFlutter・React Native比較｜導入判断]()（株式会社一創）