Kotlin Multiplatform Mobile — その概要、主要概念、KMMアーキテクチャ

Kotlin Multiplatform Mobileとは？

Kotlin Multiplatform Mobile（KMM）は、モバイルアプリケーションの共有ビジネスロジックをKotlinで記述し、コードの重複なしにiOSとAndroidで使用できるテクノロジーです。IonicやCordovaとは異なり、KMMはWebViewでインターフェースをレンダリングしません。UIは完全にネイティブのままで、SwiftUI（iOS）とJetpack Compose（Android）で記述されます。

KMMは2019年にJetBrainsによってKotlin Multiplatform戦略の一部として発表されました。他のクロスプラットフォームソリューションとの主な違いは、フレームワークがUIを統一しようとせず、両方のプラットフォームで本当に同一であるコード、つまりネットワークリクエスト、データモデル、フォームバリデーション、ビジネスルール、データベース操作の共有に焦点を当てていることです。

JetBrainsデベロッパーサーベイ（2025）によると、KMMはモバイル開発者の14%によって使用されており、この割合は年間5%ずつ増加しています。このテクノロジーは、ハイブリッドソリューションが受け入れられない、パフォーマンスとネイティブユーザーエクスペリエンスに高い要求を持つ企業によって選ばれています。

KMMアーキテクチャ：共有モジュールとプラットフォーム実装

KMMアーキテクチャは、shared（Kotlinの共通コード）、iosApp（SwiftのネイティブiOSアプリケーション）、androidApp（KotlinのネイティブAndroidアプリケーション）の3つのモジュールで構成されています。共有モジュールは、Android用にJAR、iOS用にユニバーサルフレームワーク（Apple Framework）にコンパイルされます。

共有モジュール：共通コードに含まれるもの

共有モジュールには、すべてのプラットフォーム独立レイヤーが含まれます。Ktor Clientを使用するネットワークレイヤー、kotlinx.serializationによるシリアライゼーションを持つデータモデル、データ管理のためのリポジトリ、フォームバリデーション、ビジネスルール（配達コストの計算やアクセス権限の確認など）です。

共有モジュールはGradle Multiplatform Pluginを使用し、commonMain（共通コード）、androidMain（Android固有の実装）、iosMain（iOS固有の実装）の3つのソースセットを含みます。Kotlin/Nativeコンパイラは共通コードをiOS用のネイティブライブラリに変換し、XCFrameworkを介してSwiftプロジェクトにリンクされます。

プラットフォームモジュール

Androidモジュール — Jetpack ComposeまたはViewBindingを使用したKotlinの標準Androidアプリケーションです。共有モジュールは通常のGradle依存関係として接続され、commonMainのすべてのクラスが直接アクセス可能です。

iOSモジュールはSwiftまたはObjective-CのXcodeプロジェクトです。共有モジュールはCocoaPods、Swift Package Manager、またはXCFrameworkを介して接続されます。Kotlin/NativeはKotlin型をエクスポートするためのObjective-Cヘッダーを生成し、Swiftからアクセス可能にします。

KMMのexpect/actualメカニズム

expect/actualは、共有コード内でAPIを宣言し（expect宣言）、各プラットフォームごとに個別に実装を提供する（actual宣言）Kotlin Multiplatformのメカニズムです。コンパイラは、すべてのターゲットプラットフォームに対してactualが存在することを確認します。

expect/actualの典型的なユースケース：タイムゾーンを考慮した現在時刻の取得、SharedPreferences（Android）/ UserDefaults（iOS）の操作、暗号化関数、UUID生成です。各プラットフォームは独自のシステムAPIを使用します。

expect/actualがなければ、統一されたビジネスロジックコードを維持することは不可能です。なぜなら、ファイルシステム、ネットワーク、ストレージを操作するAPIは、システムコールレベルでiOSとAndroidで異なるからです。このメカニズムにより、開発者がプラットフォーム固有の部分を実装し忘れることがなくなります。

カメラや生体認証などのプラットフォーム呼び出しには、KMMはexpect/actualメカニズムをCordovaのようなプラグインと組み合わせて提供しますが、Kotlin/Native上で動作します。JetBrainsはまた、日付と時刻の操作を抽象化するkotlinx-datetimeライブラリをリリースしています。

KMMのコード例

UUID生成のためのexpect関数宣言と、iOSおよびAndroid向けの実装を含むKMMプロジェクトの基本構造を見てみましょう。

// commonMain — 共通宣言
expect fun generateUUID(): String

// androidMain — Android実装
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — iOS実装
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

共有コードでは、expect fun generateUUID()が宣言されます。Androidはjava.util.UUIDを使用し、iOSはFoundationフレームワークのNSUUIDを使用します。共有モジュールの残りのコードでは、この関数はプラットフォームに関係なく呼び出されます。

共有コードでKtor Clientを使用したネットワークリクエストの例：

import io.ktor.client.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(
    val id: Int,
    val name: String
)

class UserRepository {
    private val client = HttpClient()

    suspend fun getUser(id: Int): User {
        val response: HttpStatement =
            client.get("https://api.example.com/users/$id")
        return Json.decodeFromString(response.bodyAsText())
    }
}

このコードは変更なしで両方のプラットフォームで動作します。Ktor Clientは、追加設定なしでAndroidではOkHttp、iOSではNSURLSessionを自動的に使用します。kotlinx.serializationによるJSONシリアライゼーションもクロスプラットフォームです。

KMMとFlutter・React Nativeの比較

KMMはクロスプラットフォームテクノロジーの中で独自の位置を占めており、FlutterやReact Nativeとは異なり、ネイティブUIを置き換えようとはしません。KMMはロジックを共有するためのソリューションであり、インターフェースを統一するためのものではありません。

KMMの主な利点は、UIを完全に制御できることです。アプリケーションが各プラットフォームでネイティブに表示され動作する必要がある場合（例えば、プラットフォームアニメーションを持つiOS TabBarとAndroid BottomNavigationを使用する場合）、KMMは回避策なしでこれを提供する唯一のクロスプラットフォームソリューションです。

欠点は、チームがKotlin、Swift、Jetpack Compose、SwiftUIを同時に習得する必要があり、採用が複雑になることです。FlutterとReact Nativeは1つの言語と1つのフレームワークの知識で十分です。

KMM採用の利点と課題

Kotlin Multiplatform Mobileは強力なテクノロジーですが、その採用にはバランスの取れたアプローチが必要です。主要な利点とチームが直面する典型的な課題を見てみましょう。

KMMの利点

第一の、そして最も重要な利点は、コードの重複削減です。JetBrainsのケーススタディ（2024）によると、KMMを採用したチームは、ネットワークレイヤーで60–80%、ビジネスロジック全体で40–50%の重複コードを削減しています。これは開発速度とバグの数に直接影響します。

第二の利点は、ネイティブアプリケーションレベルのパフォーマンスです。ハイブリッドフレームワークとは異なり、KMMはUIとシステムの間に抽象化レイヤーを追加しません。ビジネスロジックコードは、各プラットフォーム用に個別にSwiftやKotlinで記述された場合と同じ速度で実行されます。

採用の課題

主な課題はチームのスキルです。開発者はKotlin（共有モジュール用）に加えて、SwiftとJetpack Compose（UI用）を習得する必要があります。万能なスペシャリストを見つけるのは難しいため、チームは通常、AndroidとiOSの開発者で構成され、共同で共有モジュールを管理します。

第二の課題はツーリングです。KMMにはGradle、CocoaPods、Swift Package Managerの設定に加えて、Xcodeとの統合が必要です。プロジェクトの初期段階では、特にCライブラリを扱う場合にビルド設定の問題がよく発生します。

第三の課題はデバッグです。Kotlin/NativeとSwiftの境界でバグが発生した場合、モノリシックアプリケーションよりも原因の特定が困難です。JetBrainsはデバッグツールを継続的に改善していますが、実際にはチームは最大20%の時間をインフラストラクチャタスクに費やしています。