Kotlin マルチプラットフォーム（Kotlin Multiplatform / KMP）は、ビジネスロジックやドメイン層を共通コードとして共有し、UIやプラットフォーム依存部分は個別に実装することを前提とした開発アプローチです。
いわゆる「すべてを1つのコードで書く完全クロスプラットフォーム」とは異なり、共有する範囲を意図的にコントロールする設計思想を持っている点が最大の特徴です。
この考え方により、
- ネイティブ品質
- パフォーマンス
- 保守性
を犠牲にせず、開発効率を高めることが可能になります。
対応プラットフォームと安定度
Kotlin Multiplatform は、以下のプラットフォームをターゲットにできます。
ただし、すべてが同じ成熟度ではない点は理解しておく必要があります。
- Android（JVM）：Stable
- iOS（Kotlin/Native）：Stable
- Desktop（JVM：Windows / macOS / Linux）：Stable
- Server-side（JVM / Native）：Stable
- Web（Kotlin/JS）：Stable
- Web（Kotlin/Wasm）：Beta
特に Web 領域では JS と Wasm で安定度が異なるため、用途に応じた選択が重要です。
どの部分を共有できるのか
共有に向いている領域
Kotlin Multiplatform で最も価値を発揮するのは、以下のようなUIから独立したロジック層です。
- ビジネスロジック
- ドメインモデル
- バリデーション
- API 通信（REST / GraphQL）
- データ変換・整形処理
- 状態管理や ViewModel 相当の層
アプリの性質によって差はありますが、ロジック中心のアプリでは共有比率が高くなりやすい傾向があります。
※ 具体的な共有率はアプリ構造に強く依存するため、数値を一律に断定することはできません。
共有しにくい領域
一方で、以下の領域は無理に共有しない方がよいケースが多いです。
- UI レイヤー
- OS 固有 API（通知、Bluetooth、位置情報など）
- プラットフォーム特有の UX 表現
これらをネイティブ実装に任せることで、「クロスプラットフォームだが使いにくい」という事態を避けられます。
expect / actual による差分吸収
Kotlin Multiplatform の中核となる仕組みが expect / actual です。
- 共通コード側（expect）
「この機能が存在する」ことを宣言 - 各プラットフォーム側（actual）
具体的な実装を提供
この仕組みにより、プラットフォーム差を型安全に吸収できます。
実務では、
- 既存のマルチプラットフォーム対応ライブラリを優先
- 本当に必要な箇所だけ expect / actual を使う
という設計が推奨されることが多く、乱用は避けるのが一般的です。
プロジェクト構成の基本
最も基本的な構成は以下のようになります。
shared/
├─ commonMain/
├─ commonTest/
├─ androidMain/
└─ iosMain/
- commonMain：共通ロジックの中心
- platformMain：プラットフォーム固有実装
実際のプロジェクトでは、iOS の複数ターゲット（実機 / Simulator など）を階層的ソースセット（hierarchical structure）でまとめる構成になることもあります。
代表的な技術スタック
Kotlin Multiplatform でよく利用されるライブラリ例は以下の通りです（あくまで代表例）。
- 非同期処理：Kotlin Coroutines / Flow
- ネットワーク：Ktor
- シリアライズ：kotlinx.serialization
- データベース：SQLDelight、Realm Kotlin
- DI：Koin、または手動 DI
プロジェクト規模やチーム構成によって最適解は変わるため、「定番だから使う」ではなく設計意図を優先すべきです。
UI をどう扱うか：2つの戦略
UI はネイティブ実装（最も一般的）
- Android：Jetpack Compose / XML
- iOS：SwiftUI / UIKit
メリット
- UX の自然さ
- OS アップデートへの追従が容易
- 既存ネイティブ資産を活かしやすい
Compose Multiplatform を利用する
Compose Multiplatform は、Android / Desktop / Web に加え、iOS も Stable（production-ready）とされています。
メリット
- UI も Kotlin で統一できる
- Desktop や Web との親和性が高い
注意点
- ネイティブ特有の細かな表現が必要な場合は工夫が必要
- チームの Kotlin / Compose 習熟度が影響する
「使えるかどうか」ではなく、「プロダクト特性に合うかどうか」で選ぶ段階に入っています。
Flutter・React Native との位置づけの違い
| 観点 | Kotlin Multiplatform | Flutter / React Native |
|---|---|---|
| 基本思想 | ロジック共有 | UI含めて共有 |
| 実行方式 | ネイティブ | 独自ランタイム |
| UI | 原則ネイティブ | 共通UI |
| 既存資産活用 | 非常に容易 | やや難 |
Kotlin Multiplatform は、既存のネイティブ開発体制を壊さずに導入できる点が大きな強みです。
向いているプロジェクト
- Android / iOS 両対応アプリ
- ロジックが複雑な業務アプリ
- 長期運用前提のプロダクト
- ネイティブ品質を重視するチーム
一方、短期の試作や小規模アプリでは、導入コストが見合わない場合もあります。
実務的な価値
Kotlin Multiplatform の本質的な価値は、
- バグ修正・仕様変更を一箇所で反映できる
- ロジックの仕様ズレを防げる
- テスト資産を再利用できる
といった 設計品質の一貫性にあります。
単なる「コード削減」ではなく、長期的な保守性と品質を高めるためのアーキテクチャ選択と考えるのが適切です。
まとめ
Kotlin マルチプラットフォームは、
- 無理にすべてを共通化しない
- ネイティブの強みを活かす
- 長期視点での設計を重視する
という思想に基づいた、実務向けのクロスプラットフォーム技術です。
以上、Kotlinのマルチプラットフォームについてでした。
最後までお読みいただき、ありがとうございました。
