Kotlin Multiplatform 入門：概要・メリットと環境構築ガイド

2026年6月7日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 Kotlin Multiplatform の概要とメリット
2 開発環境のセットアップと Gradle Kotlin DSL 設定
3 プロジェクト構成とモジュール分割のベストプラクティス
- 3.1 典型的なディレクトリ構造
- 3.2 sourceSet の関係性
4 共通コード実装と expect/actual パターン
5 プラットフォーム別ビルド・デバッグと推奨ライブラリ導入
6 テスト戦略と CI/CD パイプライン例（GitHub Actions）
- 6.1 テストコードの配置と実行
- 6.2 GitHub Actions ワークフロー例
7 まとめと次のステップ
- 7.1 参考文献

スポンサードリンク

Kotlin Multiplatform の概要とメリット

Kotlin Multiplatform (KMP) は、1 つのコードベースで Android・iOS・macOS・Linux・Web といった複数プラットフォーム向けにビジネスロジックを共有できる仕組みです。このセクションでは、実際に期待できるコード共有率や保守性の向上といった具体的な効果を示し、本ガイド全体で扱うテーマの位置付けを明確にします。

コード共有率：公式ドキュメントや JetBrains の開発者調査（2023 年）では、UI 以外のロジックが 70 % 前後 まで共通化できるケースが多いと報告されています[^1]。
保守コストの削減：バグ修正や機能追加は commonMain に 1 回書くだけで全プラットフォームに反映され、テストコードも統一できるためリリースサイクルが短縮します。
開発者体験の向上：Kotlin 1.9 系と Gradle Kotlin DSL の組み合わせにより、IDE が提供するコード補完・リファクタリング支援をフル活用できます。

KMP を導入すれば「同じロジックを複数回書く」必要がなくなり、品質と開発速度の両面でメリットが得られます。

開発環境のセットアップと Gradle Kotlin DSL 設定

KMP プロジェクトは、最新の IDE とツールチェーンをベースに構築することが推奨されます。このセクションでは、IntelliJ IDEA または Android Studio のインストール手順と、Kotlin 1.9 系・Gradle Kotlin DSL (KTS) を用いた基本設定方法を解説します。

IntelliJ IDEA / Android Studio のインストール

まず公式サイトから IntelliJ IDEA Community（または Ultimate） もしくは Android Studio Flamingo をダウンロードし、インストーラの指示に従ってインストールしてください。
インストール後は「Check for updates」を有効化して常に最新バージョンを保ちます。また、Plugins → Kotlin でプラグインが有効になっていることを確認します。

詳細な手順は Android Developers が提供する公式 Codelab（[KMP 入門]）をご参照ください。

Kotlin プラグインと JDK の設定

Kotlin プラグインは IDE に同梱されていますが、バージョンは 1.9.x 以上 を使用してください。
JDKは少なくとも JDK 22（LTS）を選択し、Project Structure → SDKs で設定します。

Gradle Kotlin DSL の基本構成例

以下は典型的な build.gradle.kts（ルート）の雛形です。プラグインやリポジトリの宣言だけでなく、共通設定を allprojects に集約しています。

plugins {
    kotlin(&quot;multiplatform&quot;) version &quot;1.9.24&quot;
    id(&quot;com.android.application&quot;) version &quot;8.4.0&quot; apply false
}

repositories {
    google()
    mavenCentral()
}

// すべてのサブプロジェクトで共通リポジトリを使用
allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

plugins {

kotlin("multiplatform") version "1.9.24"

id("com.android.application") version "8.4.0" apply false

}

repositories {

google()

mavenCentral()

}

// すべてのサブプロジェクトで共通リポジトリを使用

allprojects {

repositories {

google()

mavenCentral()

}

プラットフォーム別 `sourceSet` の設定

kotlin {
    androidTarget()
    iosX64()
    iosArm64()
    js(IR) { browser() }

    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation(&quot;org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0&quot;)
            }
        }
        val androidMain by getting
        val iosMain by creating {
            dependsOn(commonMain)
        }
        val jsMain by getting {
            dependencies {
                implementation(&quot;io.ktor:ktor-client-js:2.3.6&quot;)
            }
        }
    }
}

kotlin {

androidTarget()

iosX64()

iosArm64()

js(IR) { browser() }

sourceSets {

val commonMain by getting {

dependencies {

implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0")

}

val androidMain by getting

val iosMain by creating {

dependsOn(commonMain)

}

val jsMain by getting {

dependencies {

implementation("io.ktor:ktor-client-js:2.3.6")

}

上記構成は公式ガイドの「マルチプラットフォームプロジェクトのセットアップ」と同等です。

プロジェクト構成とモジュール分割のベストプラクティス

大規模アプリでも管理しやすいディレクトリ構造を設計することは、KMP 成功の鍵となります。この章では、shared, androidApp, iosApp の典型的なモジュール構成と、それぞれが担う役割を具体例で示します。

典型的なディレクトリ構造

my-kmp-project/
├─ build.gradle.kts
├─ settings.gradle.kts
├─ shared/                 // 共通ロジック (commonMain / commonTest)
│   └─ src/
│       ├─ commonMain/kotlin/
│       └─ commonTest/kotlin/
├─ androidApp/             // Android アプリモジュール
│   └─ src/main/kotlin/
├─ iosApp/                 // iOS アプリ（Xcode 連携）
│   └─ src/main/kotlin/
└─ buildSrc/               // カスタムプラグイン・バージョン管理

my-kmp-project/

├─ build.gradle.kts

├─ settings.gradle.kts

├─ shared/ // 共通ロジック (commonMain / commonTest)

│ └─ src/

│ ├─ commonMain/kotlin/

│ └─ commonTest/kotlin/

├─ androidApp/ // Android アプリモジュール

│ └─ src/main/kotlin/

├─ iosApp/ // iOS アプリ（Xcode 連携）

│ └─ src/main/kotlin/

└─ buildSrc/ // カスタムプラグイン・バージョン管理

shared：データモデル、リポジトリ、Coroutines などビジネスロジックを配置。テストは commonTest にまとめることで、全プラットフォームで同一テストが走ります。
androidApp / iosApp：プラットフォーム固有の UI やシステム API 呼び出しを保持し、shared に依存します。

`sourceSet` の関係性

kotlin {
    sourceSets {
        val commonMain by getting
        val androidMain by getting { dependsOn(commonMain) }
        val iosMain by creating { dependsOn(commonMain) }
    }
}

kotlin {

sourceSets {

val commonMain by getting

val androidMain by getting { dependsOn(commonMain) }

val iosMain by creating { dependsOn(commonMain) }

}

この構成は公式ガイドでも推奨されており、コードの所在が明確でビルド時間も最適化できます。

共通コード実装と `expect/actual` パターン

KMP の核となる機能は expect/actual によるプラットフォーム抽象化です。この章では、シンプルな TODO アプリを例にデータモデル・リポジトリ・Coroutine スコープの実装方法と、期待インターフェース／実装の分離手順を示します。

`commonMain` におけるデータモデルとビジネスロジック

// shared/src/commonMain/kotlin/model/TodoItem.kt
data class TodoItem(
    val id: Long,
    val title: String,
    val completed: Boolean = false
)

// shared/src/commonMain/kotlin/repository/TodoRepository.kt
interface TodoRepository {
    suspend fun getAll(): List&lt;TodoItem&gt;
    suspend fun add(item: TodoItem)
    suspend fun toggleCompleted(id: Long)
}

// shared/src/commonMain/kotlin/model/TodoItem.kt

data class TodoItem(

val id: Long,

val title: String,

val completed: Boolean = false

)

// shared/src/commonMain/kotlin/repository/TodoRepository.kt

interface TodoRepository {

suspend fun getAll(): List<TodoItem>

suspend fun add(item: TodoItem)

suspend fun toggleCompleted(id: Long)

}

Coroutine スコープの提供

// shared/src/commonMain/kotlin/util/ScopeProvider.kt
import kotlinx.coroutines.CoroutineScope
import kotlinx.coroutines.Dispatchers
import kotlin.native.concurrent.ThreadLocal

@ThreadLocal          // iOS のシングルトン化に必須
object ScopeProvider {
    val ioScope = CoroutineScope(Dispatchers.IO)
}

// shared/src/commonMain/kotlin/util/ScopeProvider.kt

import kotlinx.coroutines.CoroutineScope

import kotlinx.coroutines.Dispatchers

import kotlin.native.concurrent.ThreadLocal

@ThreadLocal // iOS のシングルトン化に必須

object ScopeProvider {

val ioScope = CoroutineScope(Dispatchers.IO)

}

`expect / actual` によるプラットフォーム固有 API

期待インターフェース（共通側）

// shared/src/commonMain/kotlin/platform/Logger.kt
expect fun logDebug(message: String)

// shared/src/commonMain/kotlin/platform/Logger.kt

expect fun logDebug(message: String)

Android 実装

// androidApp/src/main/kotlin/platform/Logger.android.kt
import android.util.Log

actual fun logDebug(message: String) {
    Log.d(&quot;KMP_SAMPLE&quot;, message)
}

// androidApp/src/main/kotlin/platform/Logger.android.kt

import android.util.Log

actual fun logDebug(message: String) {

Log.d("KMP_SAMPLE", message)

}

iOS 実装

// iosApp/src/main/kotlin/platform/Logger.ios.kt
import platform.Foundation.NSLog

actual fun logDebug(message: String) {
    NSLog(message)
}

// iosApp/src/main/kotlin/platform/Logger.ios.kt

import platform.Foundation.NSLog

actual fun logDebug(message: String) {

NSLog(message)

}

expect/actual により 「共通ロジックはプラットフォーム非依存」 で記述でき、実装だけを切り替えることで差分が解消されます。

プラットフォーム別ビルド・デバッグと推奨ライブラリ導入

KMP は Kotlin /Native（iOS）と Kotlin /JS の両方を対象にできます。本章ではそれぞれのビルド設定、デバッグ手順、および 2024 年時点で実務的に利用されている主要ライブラリの導入例を紹介します。

iOS（Kotlin /Native）ビルドと Xcode デバッグ

Gradle タスク ./gradlew iosX64Binaries または iosArm64Binaries を実行し、.framework が生成されます。
Xcode で新規プロジェクトを作成し、Framework Search Paths に build/bin/iosX64/debugFramework（または iosArm64）を追加します。
Swift 側からは shared.TodoRepository 等のクラスをそのまま呼び出せます。ブレークポイントは Xcode のデバッガで有効です。

JS ビルドと Chrome デバッグ

js(IR) {
    browser {
        commonWebpackConfig { cssSupport.enabled = true }
    }
}

js(IR) {

browser {

commonWebpackConfig { cssSupport.enabled = true }

}

./gradlew jsBrowserDevelopmentRun でローカルサーバが起動し、Chrome DevTools のブレークポイントやネットワークタブを利用できます。

実務で選ばれる主要ライブラリ

ライブラリ	用途	Gradle 依存例
Ktor	マルチプラットフォーム HTTP クライアント/サーバ	`implementation("io.ktor:ktor-client-core:2.3.6")`
SQLDelight	ネイティブ対応 SQL データベース	`implementation("com.squareup.sqldelight:runtime:2.0.0")`
MOKO resources	文字列・画像リソースの統一管理	`implementation("dev.icerock.moko:resources:0.23.0")`

Room から SQLDelight への移行手順（概略）

shared に SQLDelight のスキーマ (Todo.sq) を作成し、プラグインでコード生成。
Android モジュールでは従来の RoomDatabase と併用せず、生成された TodoQueries を利用。
iOS でも同じ Kotlin/Native API が呼び出せるため、データ永続化ロジックが完全に共有されます。

この流れを踏めば、既存 Android アプリの Room 実装からほぼ自動的に KMP 対応へ移行できます。

テスト戦略と CI/CD パイプライン例（GitHub Actions）

KMP プロジェクトでは 共通テスト (commonTest) とプラットフォーム別テスト を組み合わせた品質保証が基本です。この章ではテストコードの配置方法、実行手順、および GitHub Actions による自動ビルド・テストパイプラインを具体例とともに示します。

テストコードの配置と実行

commonTest：JUnit5 と Kotlin Test を併用し、ロジック全体を検証。
kotlin // shared/src/commonTest/kotlin/repository/TodoRepositoryTest.kt class TodoRepositoryTest { private val repo = FakeTodoRepository()
@Test fun add item increases size() = runBlocking { repo.add(TodoItem(1, "Write article")) assertEquals(1, repo.getAll().size) } } - **androidUnitTest**：AndroidJUnitRunner を使用し、Android コンテキストが必要なコードを検証。 - **iosTest**：Kotlin/Native のtest タスクで実行し、Xcode のテストレポートに統合可能。

GitHub Actions ワークフロー例

name: KMP CI

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build-test:
    runs-on: macos-latest   # iOS ビルドが必要なため macOS を使用
    strategy:
      matrix:
        platform: [android, ios, js]

    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 22
        uses: actions/setup-java@v3
        with:
          java-version: '22'
          distribution: temurin

      - name: Cache Gradle packages
        uses: actions/cache@v3
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle.kts') }}
          restore-keys: |
            ${{ runner.os }}-gradle-

      - name: Build &amp; Test (${{ matrix.platform }})
        run: |
          case &quot;${{ matrix.platform }}&quot; in
            android)
              ./gradlew :androidApp:assembleDebug :shared:testDebugUnitTest ;;
            ios)
              ./gradlew iosX64Binaries iosX64Test ;;
            js)
              ./gradlew jsBrowserDevelopmentRun jsNodeTest ;;
          esac

name: KMP CI

on:

push:

branches: [ main ]

pull_request:

jobs:

build-test:

runs-on: macos-latest # iOS ビルドが必要なため macOS を使用

strategy:

matrix:

platform: [android, ios, js]

steps:

- uses: actions/checkout@v4

- name: Set up JDK 22

uses: actions/setup-java@v3

with:

java-version: '22'

distribution: temurin

- name: Cache Gradle packages

uses: actions/cache@v3

with:

path: ~/.gradle/caches

key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle.kts') }}

restore-keys: |

${{ runner.os }}-gradle-

- name: Build & Test (${{ matrix.platform }})

run: |

case "${{ matrix.platform }}" in

android)

./gradlew :androidApp:assembleDebug :shared:testDebugUnitTest ;;

ios)

./gradlew iosX64Binaries iosX64Test ;;

js)

./gradlew jsBrowserDevelopmentRun jsNodeTest ;;

esac

マトリクスビルドにより Android、iOS、JS のそれぞれが同時並行で実行されます。
ビルドが成功すれば GitHub の Checks に結果が表示され、プルリクエストの品質ゲートとして活用できます。

この構成は公式ガイドに基づいた最小限の設定ですが、プロジェクト規模に合わせてデプロイやスナップショット公開のステップを追加可能です。

まとめと次のステップ

Kotlin Multiplatform を採用すると、共通ロジックの再利用率が高まり、保守コストが削減されるだけでなく、テストや CI/CD の自動化も一元管理できます。本ガイドで示した開発環境・プロジェクト構成・expect/actual パターン・推奨ライブラリは、実務ですぐに適用できるベストプラクティスです。次のステップとして、まずは小規模なモジュール（例：認証ロジック）を shared に移行し、ビルドとテストが問題なく走ることを確認してください。

参考文献

[^1]: JetBrains が公開した「Kotlin Multiplatform Survey 2023」― コード共有率は 70 % 前後が一般的という結果（https://blog.jetbrains.com/kotlin/2023/09/kmp-survey-results）

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-Kotlin

comment コメントをキャンセル

: Kotlin

Kotlin Multiplatform プロジェクト作成ガイド【2026年最新版】

Android Studio Flamingo 2025以降とKotlin 2.0で、shared・androidApp・iosApp・js/wasmの4モジュール構成を一括生成し、ビルド・テスト・CIまで網羅する最新手順を紹介します。

: Kotlin

Android Studio Flamingo インストールと Kotlin/Compose 開発環境の構築方法

最新 Android Studio Flamingo のインストールと SDK 設定、Kotlin/Compose プロジェクトの作成・デバッグ・Google Play 公開までを具体的に紹介します。

: Kotlin

Android Studio Electric Eelで始めるJetpack Compose入門ガイド

Android Studio Electric Eel と Gradle Kotlin DSL を用いた Jetpack Compose 開発環境の構築手順と、基本コンポーザブル・状態管理・ナビゲーション実装を解説します。

: Kotlin

KotlinでAI SDKを始める：JDK・Gradle設定とAWS/MCP選択ガイド

JDK 17とGradle 8のKotlin DSL環境を整え、AWS SDK for Kotlin と MCP Kotlin SDK の違いと導入方法、認証のベストプラクティス、コルーチンでの非同期クライアント実装まで網羅的に解説します。

: Kotlin

Kotlin Multiplatform 最新安定版とIDE設定・Gradle構築ガイド (2024年4月)

Kotlin Multiplatformの最新安定版確認方法からIDE設定、プロジェクト作成、Gradle構成、共通ロジック実装までを網羅した2024年4月版ガイドです。

Androidコルーチンパフォーマンス評価フレームワーク2025

Ruby 3.2 新機能とパフォーマンス改善のまとめ

Kotlin Multiplatform 入門：概要・メリットと環境構築ガイド

Kotlin Multiplatform の概要とメリット

開発環境のセットアップと Gradle Kotlin DSL 設定

IntelliJ IDEA / Android Studio のインストール

Kotlin プラグインと JDK の設定

Gradle Kotlin DSL の基本構成例

プラットフォーム別 sourceSet の設定

プロジェクト構成とモジュール分割のベストプラクティス

典型的なディレクトリ構造

sourceSet の関係性

共通コード実装と expect/actual パターン

commonMain におけるデータモデルとビジネスロジック

Coroutine スコープの提供

expect / actual によるプラットフォーム固有 API

期待インターフェース（共通側）

Android 実装

iOS 実装

プラットフォーム別ビルド・デバッグと推奨ライブラリ導入

iOS（Kotlin /Native）ビルドと Xcode デバッグ

JS ビルドと Chrome デバッグ

実務で選ばれる主要ライブラリ

Room から SQLDelight への移行手順（概略）

テスト戦略と CI/CD パイプライン例（GitHub Actions）

テストコードの配置と実行

GitHub Actions ワークフロー例

まとめと次のステップ

参考文献

プラットフォーム別 `sourceSet` の設定

`sourceSet` の関係性

共通コード実装と `expect/actual` パターン

`commonMain` におけるデータモデルとビジネスロジック

`expect / actual` によるプラットフォーム固有 API

iOS（Kotlin /Native）ビルドと Xcode デバッグ