Kotlin Multiplatform、2025年の現状を調べてみた

「Kotlin/Nativeってまだ実験的でしょ？」

そう思って3年ぶりに調べてみたら、2025年にはKotlin Multiplatform（KMP）全体が完全に別物になっていた。

2022年頃に触ったときは「将来性はあるけど、iOSの並列処理が死んでるし…」って感じで諦めたのだが、気づいたら大手企業が本番環境で採用し、技術的な問題もほぼ解決されていた。

この記事では、Kotlin Multiplatformが2025年時点でどこまで進化したのか、何ができて何ができないのかを、事実ベースで整理していく。

Kotlin Multiplatformって何？

まず基本から。Kotlin Multiplatform（KMP）は、Kotlinコードを複数プラットフォームで共有する技術の総称だ。

KMPの構成

KMPは以下の要素で構成されている：

• Kotlin/Native – iOS/macOS等でビジネスロジックをネイティブバイナリにコンパイル
• Kotlin/JVM – Android/サーバー向けのJVMバイトコード生成
• Kotlin/JS – Web向けのJavaScript生成
• Compose Multiplatform – UI共通化フレームワーク（オプション）

この記事で主に扱うのはKotlin/Nativeの進化だ。

Kotlin/Nativeの立ち位置

重要なのは、Kotlin/NativeはUI技術ではないということ。

Kotlin/Nativeの役割はビジネスロジックを共通化すること。

つまり：

• API通信
• データベース処理
• 認証ロジック
• バリデーション
• ビジネスルール
• データ変換

こういった「UIに依存しない部分」を一度書けば、全プラットフォームで動く。

実際の使われ方

2025年現在、主流の構成：

【Android】
UI: Jetpack Compose
ビジネスロジック: Kotlin/Native ← 共通

【iOS】
UI: SwiftUI
ビジネスロジック: Kotlin/Native ← 共通

【Web】
UI: React / Vue
ビジネスロジック: Kotlin/Wasm ← 共通

UIは各プラットフォームのネイティブ技術を使い、ビジネスロジックだけKotlin/Nativeで共通化する。

これがFlutterやReact Nativeとの最大の違いだ。

※補足：Compose Multiplatformを使えばUIも共通化できるが、2025年現在の主流は「ネイティブUI + Kotlin/Native」という構成。

対応プラットフォーム（2025年12月時点）

• Android – 完璧に対応
• iOS – arm64、Simulator対応
• macOS – x64/arm64（Apple Silicon）対応
• watchOS / tvOS – Appleエコシステム全般
• Linux – x64/arm64
• Windows – mingwX64（まだプレビュー）
• Web – WebAssembly（2024年末から正式サポート）

3年前の認識（2022年頃）

正直に言う。2022年頃のKotlin/Nativeは、正直厳しかった。

コンパイルが死ぬほど遅い

• 小さな変更でも数分待ち
• 増分ビルドがまともに動かない
• 開発体験が最悪

iOSデバッグが無理ゲー

• Xcodeのブレークポイントがほぼ効かない
• printlnデバッグに頼るしかない
• クラッシュ時のスタックトレースが意味不明

iOSでの並列処理が地獄

これが最大の問題だった。

旧Memory Manager（〜Kotlin 1.7.19）での制約：

• オブジェクトは作成されたスレッドでしか使えない
• 他スレッドで使うにはfreeze()が必要（不変化）
• Mutableな状態を複数スレッドで共有不可
• Dispatchers.Defaultすらメインスレッドで動く
• 実質シングルスレッド運用

// これが動かなかった（2022年）
GlobalScope.launch {
    val result = withContext(Dispatchers.Default) {
        // 重い処理
        api.fetchData()
    }
    // InvalidMutabilityException で死ぬ
}

API呼び出しすらまともに書けない状態。

「将来性はあるけど…」状態

• 大手企業の採用事例がほぼゼロ
• コミュニティも小さい
• 「実験的」の域を出ない

結論：「様子見かな…」

そう思って離れた。

2025年に起きてた衝撃の進化

で、2025年12月。久々に調べたら全部解決してた。

コンパイル速度が劇的に改善

Kotlin 1.9〜2.0で導入されたK2コンパイラにより：

• コンパイル速度が5〜10倍高速化
• 増分ビルドが実用レベルに
• iOSフレームワークの生成が劇的に速くなった

実測で、以前5分かかっていたビルドが30秒に。

iOSの並列処理問題が完全に解決

これが最大の進化ポイント。

Kotlin 1.7.20（2022年8月）以降、新Memory Managerがデフォルトで有効になり：

✅ freeze()が不要に
✅ Mutableな状態を複数スレッドで共有可能
✅ JVM/Androidと同じように書ける
✅ Dispatchers.Defaultが本物のバックグラウンドスレッド
✅ 並列処理も普通に動く

// これが普通に動く！（2025年）
suspend fun fetchUserData(userId: String): UserData = 
    withContext(Dispatchers.IO) {
        val user = userApi.getUser(userId)
        val posts = postApi.getUserPosts(userId)
        val friends = friendApi.getFriends(userId)
        
        // 並列処理も問題なし！
        val details = awaitAll(
            async { fetchUserDetails(user.id) },
            async { calculateUserStats(posts) },
            async { analyzeFriendNetwork(friends) }
        )
        
        UserData(user, posts, friends, details)
    }

このコードが、Android/iOS/macOS/Windows/Linux全部で同じように動く。

Kotlin 1.9.20（2023年11月）でレガシーMemory Managerが完全削除され、もう後戻りできない状態に。

CPU毎の最適化が完全自動化

x86_64、ARM64、ARMv7、Apple Silicon…各アーキテクチャ毎の最適化を、KMPが完全に自動でやってくれる。

CPU	2022年	2025年
x86_64	手動最適化必要	自動最適化
ARM64	SIMDが使えない	NEON自動活用
Apple Silicon	専用ビルド必要	デフォルト対応

Kotlinで書くだけで、LLVM最適化が走ってネイティブコード並みの性能が出る。

Wasm対応でWeb展開も可能に

2024年末からWebAssembly（Wasm32）が正式サポート。

これにより：

• 初回ロード1秒以内
• SEO完全対応
• バンドルサイズ1MB未満

同じビジネスロジックを、モバイルでもWebでも使える。

ベータ卒業（2023年11月）

Kotlin 1.9.20でKotlin Multiplatformがベータ卒業。

これは「もう本番環境で使っていいよ」という公式のお墨付き。

実際の使い方：コード例

具体的にどう書くのか？実例を見てみよう。

ビジネスロジックをKMPで実装

// commonMain/src/repositories/UserRepository.kt
// このコード、Android/iOS/macOS/Windows/Linux/Web全部で動く
class UserRepository(private val apiClient: ApiClient) {
    
    suspend fun login(email: String, password: String): Result<User> =
        withContext(Dispatchers.IO) {
            runCatching {
                val response = apiClient.post<LoginResponse>("/auth/login") {
                    setBody(LoginRequest(email, password))
                }
                User(
                    id = response.userId,
                    email = response.email,
                    name = response.name,
                    token = response.token
                )
            }
        }
    
    suspend fun getProfile(userId: String): User =
        apiClient.get("/users/$userId")
    
    suspend fun updateProfile(user: User): Result<User> =
        withContext(Dispatchers.IO) {
            runCatching {
                apiClient.put("/users/${user.id}") {
                    setBody(user)
                }
            }
        }
}

Androidから呼び出す（Jetpack Compose）

// Android側
@Composable
fun LoginScreen(repository: UserRepository) {
    var email by remember { mutableStateOf("") }
    var password by remember { mutableStateOf("") }
    val scope = rememberCoroutineScope()
    
    Column {
        TextField(value = email, onValueChange = { email = it })
        TextField(value = password, onValueChange = { password = it })
        
        Button(onClick = {
            scope.launch {
                repository.login(email, password)
                    .onSuccess { user ->
                        // ログイン成功
                    }
            }
        }) {
            Text("ログイン")
        }
    }
}

iOSから呼び出す（SwiftUI）

// iOS側
struct LoginView: View {
    @State private var email = ""
    @State private var password = ""
    private let repository = UserRepository(apiClient: ApiClient())
    
    var body: some View {
        VStack {
            TextField("Email", text: $email)
            SecureField("Password", text: $password)
            
            Button("ログイン") {
                Task {
                    let result = try await repository.login(
                        email: email,
                        password: password
                    )
                    // ログイン成功
                }
            }
        }
    }
}

重要なポイント

同じビジネスロジック（UserRepository）を、AndroidとiOSの両方から使っている。

変更があった場合：

1. Kotlinのコードを1箇所修正
2. ビルドし直す
3. Android、iOS両方に自動反映

バグ修正も1回で済む。テストも1箇所でOK。

Firebase / AWS連携の現状

「でも、Firebase使えないんでしょ？」

いや、普通に使える。

Firebaseとの連携

// commonMain/src/repositories/FirebaseRepository.kt
// このコード、Android/iOS/macOS全部で動く
class FirebaseRepository {
    private val auth = Firebase.auth
    private val firestore = Firebase.firestore
    
    suspend fun signIn(email: String, password: String): Result<User> =
        withContext(Dispatchers.IO) {
            runCatching {
                auth.signInWithEmailAndPassword(email, password)
                    .user?.let { firebaseUser ->
                        User(
                            id = firebaseUser.uid,
                            email = firebaseUser.email ?: ""
                        )
                    } ?: throw Exception("Login failed")
            }
        }
    
    suspend fun getUser(uid: String): User =
        firestore.collection("users")
            .document(uid)
            .get()
            .data<User>()
    
    suspend fun savePost(post: Post) =
        firestore.collection("posts")
            .add(post)
}

サービス	対応状況	共有可能？
Firestore	firebase-kotlin-sdk	○ 完全共有可能
Auth	firebase-kotlin-sdk	○ 完全共有可能
Storage	firebase-kotlin-sdk	○ 完全共有可能
Analytics	プラットフォーム固有	△ UI層で実装推奨

AWSとの連携

実は、公式SDKより自前実装の方が軽くて速い。

// commonMain/src/aws/AwsClient.kt
object AwsClient {
    private val client = HttpClient(CIO) {
        install(ContentNegotiation) { json() }
        install(AwsSigV4) {  // AWS Signature V4自動付与
            region = "ap-northeast-1"
            service = "execute-api"
            credentialsProvider = DefaultCredentialsProvider()
        }
    }

    // S3アップロード
    suspend fun uploadToS3(key: String, data: ByteArray): Result<String> =
        withContext(Dispatchers.IO) {
            runCatching {
                client.put("https://my-bucket.s3.amazonaws.com/$key") {
                    setBody(data)
                    header("Content-Type", "image/png")
                }
                "https://my-bucket.s3.amazonaws.com/$key"
            }
        }

    // Lambda呼び出し
    suspend fun invokeLambda(
        functionName: String,
        payload: JsonObject
    ): JsonObject =
        client.post("https://xxxxx.lambda-url.amazonaws.com/") {
            setBody(payload)
        }.body()
}

全プラットフォームで動作。しかも：

• 公式SDKより10倍軽量
• ビルド時間が圧倒的に短い
• メモリ使用量が少ない

大手企業の採用事例（2025年時点）

本番環境で使ってる企業（公式確認済み）：

• Netflix – スタジオアプリ（Prodicle）のコア機能
  • 公式Tech Blog
• Cash App (Square) – 決済ロジック（2018年から本番採用、3000万MAU）
  • 公式Case Study
• VMware – Workspace ONEプロダクト群
• McDonald’s – モバイルアプリの支払い機能
• Baidu – Wonder App（データ層とビジネスロジック）
• 9GAG – 全アプリ（Flutter/React Nativeから移行）
• Forbes – 80%以上のロジック共有
• Autodesk – オフライン同期ロジック
• Philips – HealthSuite Digital Platform SDK
• Duolingo – 複数機能で採用

特筆すべき点

Cash App: 2018年から本番採用し、現在3000万月間アクティブユーザー規模で安定稼働。決済という最もクリティカルな機能で使用。

Netflix: FAANG企業で初のKMP本番採用。物理的な映画・TV制作現場という「オフライン環境」での信頼性を実現。

McDonald’s: 支払い機能という最もクリティカルな部分で採用。「実験が成功した後、アプリ全体に拡大」と公式発表。

Google: Google Docs実験プロジェクトで使用し、「実験は成功だった。非常に満足している」と評価。Googleですら検討している技術。

採用率の推移

時期	採用率	状況
2023年初頭	12%	ベータ版、様子見
2024年末	23%	18ヶ月で倍増
2025年	増加中	本番採用が標準に

React Native（38%）やFlutter（主流）には及ばないが、確実に成長している。

まだ厳しい部分（2025年12月時点）

良いことばかりではない。現実も見ておこう。

コミュニティがまだ小さい

• Flutter、React Nativeに比べると情報が少ない
• ライブラリも少なめ
• 日本語情報は特に少ない

学習コストはそれなりにある

• Kotlinを覚える必要がある
• iOSの場合、SwiftUIも必要
• Androidの場合、Jetpack Composeも必要

「全部Kotlinで完結」ではない点に注意。

Flutterとの統合は未成熟

「Flutter（UI）+ KMP（ロジック）」という構成は技術的には可能だが：

• 公式ツールは存在しない
• サードパーティライブラリ（Klutter等）は超小規模（スター数200程度）
• メンテナンスも不安定

現実的には、ネイティブUI + KMPの構成が主流。

Windows対応はまだプレビュー

mingwX64は動くが、公式サポートが「プレビュー」のまま。

本番投入するなら、Linux/macOS/iOS/Androidに絞るべき。

まとめ

2025年12月時点で言えること：

✅ 確実に進化した

1. Kotlin Multiplatformがベータ卒業（2023年11月）
2. Kotlin/Native（iOS）の並列処理問題が完全解決（2022年8月〜）
3. コンパイル速度が劇的改善
4. 大手企業が本番採用
5. 採用率が18ヶ月で倍増

✅ 実用レベルに到達

• ネイティブUI（SwiftUI/Jetpack Compose）+ Kotlin/Native（ビジネスロジック）という明確な立ち位置
• Firebase/AWS連携も実用レベル
• パフォーマンスもネイティブ並み
• （オプション）Compose MultiplatformでUIも共通化可能

❌ 銀の弾丸ではない

• コミュニティはまだ小さい
• 学習コストはある
• Flutterとの統合は未成熟
• 主流は「UIは各プラットフォーム毎、ロジックのみ共通化」

こんなプロジェクトに最適

• 新規プロダクト立ち上げで、Android/iOS両対応が必要
• ビジネスロジックが複雑で、プラットフォーム毎に実装したくない
• 保守性・テスタビリティを重視したい
• チームにKotlin経験者がいる（学習コスト低い）
• ネイティブUIの品質を妥協したくない

おわりに

正直、3年前に諦めたのを後悔してる。

2025年のKotlin Multiplatformは、もう「実験的」じゃない。本番環境で使える技術になっていた。

特に2022年8月のKotlin/Native（iOS）並列処理問題の解決は、決定的だったと思う。

これがなければ、どんなにコンパイルが速くなっても使い物にならなかった。

もちろん、FlutterやReact Nativeのように「UIもロジックも全部共有」という手軽さはない。

でも、ネイティブUIの品質を保ちつつ、ビジネスロジックだけ共有というアプローチは、特定のプロジェクトには最適解だと思う。

Kotlin Multiplatform、2025年は本気で触る価値がある。

補足：UI共有はどうなの？（2025年）

Compose Multiplatformを使えば、Android/iOSでUI共有も可能（2025年5月Stable化）。ただし、主流は依然として「ネイティブUI + 共有ロジック」パターン。

理由：

• プラットフォーム固有のUI/UX（iOS: Cupertino、Android: Material）
• デザイナーとの協業（SwiftUI/Jetpack Composeの方が通じる）
• 採用事例でもロジック共有が中心

UI共有が有効なケース：

• 社内ツール、管理画面
• デザイン統一を最優先するアプリ
• 小規模チームでスピード重視

参考: Compose Multiplatform公式

---

参考リンク：

公式ドキュメント：

• Kotlin/Native公式ドキュメント
• Kotlin Multiplatform公式
• 新Memory Managerへの移行ガイド

ライブラリ：

• firebase-kotlin-sdk
• Ktor（HTTP Client）
• SQLDelight（データベース）

企業事例：

• Netflix Tech Blog – KMP採用事例
• Cash App Case Study
• JetBrains公式 – 全企業事例