モダン Kotlin 2026 完全ガイド - Kotlin 2.1・Compose Multiplatform・Ktor・Exposed・KSP・Arrow 深掘り

プロローグ — Kotlin はマルチランタイム時代の標準になった

2026 年春、Kotlin はもう「Android の言語」ではない。サーバーでは Ktor 3 と Spring Boot 3.4 Kotlin DSL が二分し、モバイルでは Compose Multiplatform 1.7 が iOS・Android・Desktop・Web をひとつのコードベースから出力し、Web では Kotlin/Wasm GC が React 風コンポーネントを描けるまでに成熟した。JetBrains が Kotlin 2.0(2024 年 5 月)で K2 コンパイラを GA に乗せて以降、2.1 と 2.2 が続き、コンパイル速度は平均で約 2 倍速くなり、コンパイラプラグインは KSP 2 に統一された。

本記事は 2026 年の Kotlin スタックを最初から最後まで — 言語・並行性・KMP・UI・サーバー・DB・DI・テスト・Web・コミュニティまで — 一息でまとめる。コードはすべて動くコードを引用し、ライブラリのバージョンは 2026 年 5 月時点の最新に固定する。

覚えておくべき一文:Kotlin はもう「JVM 上のよりよい言語」ではなく、「マルチランタイム時代のマルチプラットフォーム言語」だ。

第 1 章 · Kotlin 2.1 と 2.2 — K2 コンパイラが変えたもの

まず言語そのもの。Kotlin 2.0(2024 年 5 月)の核心は K2 コンパイラ GA だった。K2 は既存コンパイラのフルリライトで、フロントエンド(パーサー・型チェッカー)とバックエンド(IR 生成)をモジュール化した。その結果:

• 平均コンパイル速度は約 2 倍(大規模プロジェクトでは 3 倍以上)
• IntelliJ の解析応答性が改善(K2 モード)
• コンパイラプラグイン API が安定化(Compose・kotlinx.serialization・Anvil)

Kotlin 2.1(2024 年 11 月)で安定化した項目:

• when 式のガード条件(guard conditions)が stable
• 非局所 break/continue が preview
• マルチドル補間($$"...")— 文字列内のリテラル $ を自由に書ける
• kotlin.uuid.Uuid を標準ライブラリに追加

Kotlin 2.2(2025 年 6 月)は context parameters を stable に昇格させ、expect/actual の表現力を高めた。context parameters は旧 context receivers をより明確な構文で置き換えるものだ。

context(logger: Logger)
fun process(input: String) {
  logger.info("processing: $input")
}

// 呼び出し側
with(myLogger) {
  process("hello")
}

2.2 のもう一つの変化:expect/actual の簡素化。今では単純な typealias だけで actual を完結できる場面が増え、同一シグネチャでのボイラープレートはほぼ消えた。

第 2 章 · Coroutines 1.10 — 構造化並行性の完成

コルーチン(kotlinx.coroutines)は Kotlin の非同期標準だ。2026 年の 1.10 リリースを基準に整理する。

核となる原則 — 構造化並行性(Structured Concurrency):すべてのコルーチンは親 CoroutineScope の中で生きる。親がキャンセルされれば子もキャンセルされ、子が失敗すれば親も失敗する(SupervisorJob は例外)。

import kotlinx.coroutines.*

suspend fun fetchUserData(): UserData = coroutineScope {
  val profile = async { fetchProfile() }
  val orders = async { fetchOrders() }
  val recs = async { fetchRecommendations() }
  UserData(profile.await(), orders.await(), recs.await())
}

coroutineScope は三つのうちどれかが失敗すれば残りをキャンセルし例外を投げる。これが構造化並行性の本質だ。

ディスパッチャ選択:

• Dispatchers.Main — UI スレッド(Android・Compose)
• Dispatchers.IO — ブロッキング I/O(ファイル・DB・ネットワーク)
• Dispatchers.Default — CPU バウンド(JSON パース・画像処理)
• Dispatchers.Unconfined — ほぼ使うべきではない

1.10 の新機能:CoroutineStart.UNDISPATCHED_PROCESSING、より精緻な cancellation propagation、そして Channel.consumeEach の deprecation。

覚えておくべき一文:コルーチンは軽量スレッドではなく、軽量な関数呼び出しだ。

第 3 章 · Flow・StateFlow・SharedFlow — リアクティブの新標準

Kotlin のリアクティブ API は RxJava を置き換えた。三者の違いから。

Flow の例 — combine・flowOn・stateIn:

val searchQuery: StateFlow<String> = ...
val filters: StateFlow<Filters> = ...

val results: StateFlow<List<Item>> = combine(searchQuery, filters) { q, f ->
  q to f
}
  .debounce(300)
  .mapLatest { (q, f) -> repository.search(q, f) }
  .flowOn(Dispatchers.IO)
  .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), emptyList())

flowOn は上流のディスパッチャを変える(下流はコレクタのコンテキスト)。stateIn はコールド Flow をホット StateFlow に変換しつつ 5 秒の stop timeout を設ける — 画面回転のような短い購読断絶では検索を再トリガしない。

mapLatest vs flatMapLatest:新しい値が来ると進行中の作業をキャンセルする。検索のオートコンプリートのように「最後だけが大事」な場合に使う。

SharedFlow の例 — イベントバス:

private val _events = MutableSharedFlow<UiEvent>(extraBufferCapacity = 1)
val events: SharedFlow<UiEvent> = _events.asSharedFlow()

fun trigger(e: UiEvent) {
  _events.tryEmit(e)
}

第 4 章 · Kotlin Multiplatform — KMP が安定段階に入った理由

KMP は Kotlin 1.9.20(2023 年 11 月)で stable 宣言された。2026 年現在の採用事例:

• Cash App — iOS・Android 共通のビジネスロジック(数年来)
• Netflix — 一部モジュールを共有化(2024 年ケーススタディ)
• McDonald's Global Mobile App — KMP・CMP iOS の採用例(2024 KotlinConf キーノート)
• Forbes、Philips、Autodesk — KMP 本番運用

KMP の構造は単純だ:共通ソースセット(commonMain) にはプラットフォーム非依存のコードを、プラットフォーム別ソースセット(androidMain、iosMain、jvmMain、jsMain) には実装を置く。

// commonMain
expect fun platformName(): String

// androidMain
actual fun platformName(): String = "Android ${Build.VERSION.SDK_INT}"

// iosMain
actual fun platformName(): String = "iOS ${UIDevice.currentDevice.systemVersion}"

Kotlin 2.2 は expect/actual をより簡素化した。単純な typealias で完結するケースが増え、default implementation を expect 側に置けるようになった。

何を共有するか:

• モデル・ドメインロジック(Result<Either<Failure, Success>> など)
• ネットワーク(Ktor Client)
• シリアライゼーション(kotlinx.serialization)
• ストレージ(SQLDelight・Room KMP)
• 日付/時刻(kotlinx-datetime)
• コルーチン(kotlinx.coroutines は最初から KMP-first)

何を共有しないか:UI は選択肢。Compose Multiplatform を使うなら共有、SwiftUI を選ぶなら分離。

第 5 章 · Compose Multiplatform 1.7 — iOS Stable の意味

JetBrains の Compose Multiplatform(CMP)は 2024 年 5 月の 1.6.10 で iOS を beta に、そして 2024 年 11 月の 1.7 で iOS stable を宣言した。2026 年 5 月時点の安定版は 1.7.x 系だ。

CMP は Android の Jetpack Compose UI ツールキットを Skia ベースですべてのプラットフォームに運ぶ:

• Android — Jetpack Compose と同じランタイム上で動作
• iOS — Skia + Metal の直接レンダリング、UIKit インターロップ
• Desktop (JVM) — Skia + OpenGL/Direct3D
• Web (Wasm GC) — Skia を Wasm にコンパイル

iOS インターロップ:CMP の composable を SwiftUI に埋め込んだり、SwiftUI ビューを CMP に埋め込んだりできる(UIKitView・UIViewController ラッパー)。

@Composable
fun App() {
  MaterialTheme {
    Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {
      Text("Hello from CMP 1.7", style = MaterialTheme.typography.headlineMedium)
      // iOS・Android・Desktop・Web すべてで同じコードが動く
    }
  }
}

Navigation 2:2026 年現在 dev 段階。KMP ネイティブな Navigation API で、type-safe routing と deep link を共通コードに書ける。

第 6 章 · Jetpack Compose 1.7 — Strong Skipping と性能

Android の Jetpack Compose は 1.7(2024 年 9 月)で strong skipping をデフォルト有効にした。それ以前は @Stable 注釈付き型のみが自動で再構成(recomposition)をスキップしたが、strong skipping ではラムダを含むすべての関数がデフォルトでスキップされる。

@Composable
fun UserCard(user: User, onClick: () -> Unit) {
  // strong skipping のおかげで user が同じなら、
  // onClick が毎回新しいラムダでもこの関数は再構成されない。
  Card(onClick = onClick) {
    Text(user.name)
  }
}

Lazy レイアウトの改善:LazyColumn・LazyRow・LazyGrid が prefetch と sticky header でより速い。

Compose Compiler 統合:Kotlin 2.0 以降、Compose Compiler は Kotlin 本体に統合され、バージョンマッチングの悩みは消えた。

基本的なパフォーマンスパターン:

• remember なしにラムダを毎回作らない — strong skipping があってもメモリ圧は残る
• derivedStateOf で派生状態の計算をキャッシュ
• key を明示して項目の再配置を防ぐ
• Modifier チェーンをコンポーザブル内の関数に切り出さない(毎回新規生成される)

覚えておくべき一文:Compose は「宣言的」だが、その宣言は毎フレーム再実行される — だからスキップこそが性能だ。

第 7 章 · Ktor 3.0 — サーバーサイドの標準

JetBrains が作る Ktor は 3.0(2024 年 10 月)で JVM だけでなく Native・JS もサーバーとしてを標準に乗せた。Spring Boot と比べて小さく、軽く、コルーチンネイティブだ。

import io.ktor.server.application.*
import io.ktor.server.engine.*
import io.ktor.server.netty.*
import io.ktor.server.routing.*
import io.ktor.server.response.*

fun main() {
  embeddedServer(Netty, port = 8080) {
    routing {
      get("/") {
        call.respondText("Hello Ktor 3.0")
      }
      get("/users/{id}") {
        val id = call.parameters["id"]
        call.respondText("user: $id")
      }
    }
  }.start(wait = true)
}

3.0 の新機能:

• SSE (Server-Sent Events) プラグインが stable — チャットボット・リアルタイム通知にそのまま使える
• Content Negotiation — JSON/Protobuf/XML の協商を一行で
• OpenTelemetry プラグインを標準提供
• HTTP/3 preview

install(SSE)

routing {
  sse("/stream") {
    repeat(10) { i ->
      send(ServerSentEvent("tick: $i"))
      delay(1000)
    }
  }
}

Native ビルド:kotlin-multiplatform と ktor-server-cio を組み合わせれば Linux/macOS の単一バイナリが作れる — Lambda・Cloud Run の cold start が劇的に短くなる。

第 8 章 · Exposed 0.56 — Kotlin ORM の標準

JetBrains の Exposed は 0.56(2025 年)でコルーチン統合と R2DBC サポートを安定化した。二つの API を提供する。

DSL API — SQL をほぼそのまま移したビルダー:

object Users : IntIdTable() {
  val name = varchar("name", 50)
  val email = varchar("email", 100).uniqueIndex()
  val createdAt = datetime("created_at").defaultExpression(CurrentDateTime)
}

transaction {
  Users.insert {
    it[name] = "Alice"
    it[email] = "alice@example.com"
  }

  Users.selectAll()
    .where { Users.name like "A%" }
    .map { it[Users.name] }
}

DAO API — エンティティオブジェクトマッピング:

class User(id: EntityID<Int>) : IntEntity(id) {
  companion object : IntEntityClass<User>(Users)
  var name by Users.name
  var email by Users.email
}

transaction {
  val alice = User.new {
    name = "Alice"
    email = "alice@example.com"
  }
}

代替:Komapper(コンパイル時コード生成でより高速)、Ktorm(軽量 DSL)、JOOQ(エンタープライズ標準だが Kotlin フレンドリー)。

第 9 章 · KSP 2.x — KAPT は死んだ

KSP(Kotlin Symbol Processing)は KAPT を置き換えるコンパイラプラグインフレームワークだ。KAPT は Java の annotation processing API に合わせるため Java スタブを生成していたために遅かった。KSP は Kotlin コンパイラの IR を直接読み、約 2 倍速い。

KSP 2.x(2024 年 GA)は K2 コンパイラの上で動作する。主要 annotation processor のほとんどが KSP に移行した:

• Room — KSP を推奨
• Dagger / Hilt — KSP stable
• Moshi — KSP only
• kotlinx.serialization — コンパイラプラグイン(KSP とは独立)
• kotlin-inject — KSP ベース
• AutoValue/AutoFactory — KSP に移植

// build.gradle.kts
plugins {
  id("com.google.devtools.ksp") version "2.1.0-1.0.29"
}

dependencies {
  ksp("androidx.room:room-compiler:2.7.0")
}

KAPT を使うプロジェクトは移行を推奨 — ビルド時間が一夜にして半分になることが多い。

第 10 章 · Arrow 2.0 — Typed Errors と Raise DSL

Arrow は Kotlin の functional programming ライブラリだ。2.0(2024 年 1 月)で Raise DSL を stable に乗せ、typed errors の新パラダイムを提示した。

従来の Either<Failure, Success> ではモナド内包表記や flatMap チェーンが必要だった:

// Arrow 1.x スタイル
fun process(input: String): Either<Error, Result> = either {
  val parsed = parse(input).bind()
  val validated = validate(parsed).bind()
  compute(validated).bind()
}

Arrow 2.0 の Raise は同じ意味を関数コンテキストで表現する:

context(raise: Raise<Error>)
fun parse(input: String): Parsed = ...

context(raise: Raise<Error>)
fun process(input: String): Result {
  val parsed = parse(input)        // bind は不要
  val validated = validate(parsed)
  return compute(validated)
}

// 呼び出し側 — 一箇所でキャッチする
val result: Either<Error, Result> = either {
  process(userInput)
}

Raise の利点:

• bind() 呼び出しがなくなり、コードがフラットになる
• Either・Result・Option の間の変換が自由
• Kotlin 2.2 の context parameters(stable)と自然に組み合わさる

Arrow 2 はさらに optics(deep immutable updates)と typed FP utilities(traverse・sequence・zip)も提供する。

第 11 章 · kotlinx.serialization 1.7 — JSON・Protobuf・CBOR 統合

JetBrains のシリアライゼーションライブラリは 1.7(2024 年)でコンパイル時コード生成とマルチプラットフォームを一度に解決する。リフレクションがないので Kotlin/Native と Wasm でも動く。

import kotlinx.serialization.*
import kotlinx.serialization.json.*

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

val user = User(1, "Alice", "alice@example.com")
val jsonStr = Json.encodeToString(user)
val parsed = Json.decodeFromString<User>(jsonStr)

1.7 のハイライト:JSON 以外に Protobuf・CBOR・HOCON フォーマットを追加、Json.encodeToStream(ストリーミング API)、そして polymorphic serialization の改善。

@Serializable
sealed interface ApiResponse {
  @Serializable @SerialName("success") data class Ok(val data: User) : ApiResponse
  @Serializable @SerialName("error") data class Err(val code: Int, val message: String) : ApiResponse
}

val response: ApiResponse = Json.decodeFromString<ApiResponse>(jsonStr)

Ktor・Retrofit・OkHttp すべてが kotlinx.serialization コンバータを標準サポートする。

第 12 章 · 依存性注入 — kotlin-inject・Koin 4・Anvil

JVM の Dagger 2 は依然として標準だが、Kotlin・KMP 環境では選択肢が増えた。

kotlin-inject(KSP ベース、KMP 対応):

@Inject class UserService(private val repo: UserRepository)

@Component abstract class AppComponent {
  abstract val userService: UserService
}

Koin 4(ランタイム DSL、もっとも簡単):

val appModule = module {
  single<UserRepository> { UserRepositoryImpl(get()) }
  factory { UserService(get()) }
}

startKoin { modules(appModule) }

Dagger Anvil(Square):Dagger の上に Kotlin DSL を乗せボイラープレートを減らす。2.5 で KSP をサポート。

選択基準:

• 小さなアプリ・KMP → Koin 4
• コンパイル時検証が重要 → kotlin-inject(KMP)または Dagger Anvil(Android)
• 大規模レガシー Android → Dagger / Hilt

第 13 章 · Kotlin/Native と iOS インターロップ

Kotlin/Native は LLVM ベースのバックエンドで、JVM なしにマシンコードへコンパイルする。iOS・macOS・Linux・Windows・Wasm をターゲットにする。

iOS インターロップ:Objective-C・Swift と双方向。Swift 5.10 以降、swift-export 機能(まだ experimental)がより自然な Swift API を生成する。

// Kotlin
class Greeter {
  fun greet(name: String): String = "Hello, $name"
}

// Swift から使用
let greeter = Greeter()
let msg = greeter.greet(name: "Alice")

メモリモデル:Kotlin/Native は 2022 年に新メモリモデルへ移行した。以前の「freeze」制約がなくなり、マルチスレッドコードを JVM と同じように書ける。コルーチンはデフォルトで thread-safe に動く。

制約:

• iOS ビルドは Mac でのみ可能(Xcode が必要)
• KMP の cinterop で C ヘッダを wrap できるが手間がかかる
• Kotlin/Native のビルド時間は JVM より長い(LLVM コンパイル)

第 14 章 · Android 16 — SDK 35・Predictive Back・Material 3 Expressive

2026 年 5 月現在、Android 15(API 35)は安定、Android 16 は dev preview。Kotlin 開発者が知っておくべき要点:

SDK 35(Android 15):

• Predictive Back — システム戻るジェスチャが次画面をプレビュー表示する。OnBackPressedDispatcher API 変更
• Edge-to-edge enforced — targetSdk = 35 ではシステムバー領域までコンテンツが自動拡張
• 15 秒単位の作業制約 — バックグラウンドの重い作業は WorkManager 推奨
• Foreground service types がより厳格に

Material 3 Expressive(Android 16 preview):

• より表現力豊かなモーションと色
• 新コンポーネント:LoadingIndicator、WavyProgress、ToolbarScaffold
• Kotlin Compose では androidx.compose.material3:1.4.x 系で導入中

開発環境:

• Android Studio Ladybug 以降(2024 年 10 月〜)
• Kotlin 2.x を推奨
• Compose Compiler は Kotlin と一緒に配布(別バージョン管理は不要)

第 15 章 · サーバーサイド — Spring Boot・Micronaut・Helidon Nima

JVM サーバーで Kotlin は一級市民だ。2026 年時点の主要フレームワーク:

Spring Boot 3.4(2024 年 11 月):Kotlin DSL サポート、Virtual Threads(Loom)統合、GraalVM Native Image stable。

@SpringBootApplication
class Application

@RestController
class UserController(private val userService: UserService) {
  @GetMapping("/users/{id}")
  fun get(@PathVariable id: Long): User = userService.findById(id)
}

fun main(args: Array<String>) {
  runApplication<Application>(*args)
}

Micronaut 4.7:AOT コンパイル + Kotlin Symbol Processing。cold start は Spring Boot より 5 倍短い。

Helidon Nima(Oracle):Virtual Threads の上に同期コードスタイルで書くサーバー。Kotlin コルーチンとのシナジーには直接ラッパーが必要だが、「同期のように書き、非同期のように動く」という絵は魅力的だ。

選択基準:

• 既存 Spring 資産の活用 → Spring Boot 3.4 + Kotlin
• Native Image ビルド → Micronaut または Quarkus
• KMP サーバーや軽量マイクロサービス → Ktor 3

第 16 章 · Gradle Kotlin DSL — ビルド設定も Kotlin で

build.gradle.kts は事実上の標準だ。Groovy DSL との比較:

plugins {
  kotlin("jvm") version "2.1.0"
  kotlin("plugin.serialization") version "2.1.0"
  id("com.google.devtools.ksp") version "2.1.0-1.0.29"
}

dependencies {
  implementation("io.ktor:ktor-server-core:3.0.0")
  implementation("io.ktor:ktor-server-netty:3.0.0")
  implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.10.0")
  implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.0")

  testImplementation(kotlin("test"))
  testImplementation("io.kotest:kotest-runner-junit5:5.9.0")
}

tasks.test {
  useJUnitPlatform()
}

Version catalog(libs.versions.toml)を推奨 — 依存バージョンを一箇所で管理し、モジュール間の一貫性を強制する。

Configuration cache:Gradle 8.x からデフォルト。初回実行後はタスクグラフを再利用して 30〜70% 速くなる。

第 17 章 · Testing — JUnit 5・Kotest・MockK・Turbine

2026 年の Kotlin テストスタック:

JUnit 5 + kotlin.test:最も一般的なベース。@Test、@BeforeEach、@DisplayName がそのまま使える。

Kotest 5.9:BDD スタイル + property-based testing。

class UserSpec : StringSpec({
  "should return name in uppercase" {
    User("alice").nameUpper() shouldBe "ALICE"
  }

  "all positive numbers double" {
    checkAll<Int> { n ->
      if (n > 0) (n * 2) shouldBeGreaterThan n
    }
  }
})

MockK 1.13:Mockito に似ているが Kotlin ネイティブ。coEvery でコルーチンを自然に mock できる。

val repo = mockk<UserRepository>()
coEvery { repo.findById(1) } returns User(1, "Alice")

val service = UserService(repo)
runTest {
  service.getName(1) shouldBe "Alice"
}

Turbine(Cash App):Flow テストの標準。

runTest {
  myFlow.test {
    awaitItem() shouldBe "first"
    awaitItem() shouldBe "second"
    awaitComplete()
  }
}

第 18 章 · KMP ライブラリエコシステム — Datetime・IO・Crypto

KMP が stable になって以降、JetBrains は標準ライブラリの整備を始めた。

• kotlinx-datetime(0.6+) — マルチプラットフォーム日付/時刻。Java java.time を知っていれば馴染みやすい
• kotlinx-io(0.5+) — Source/Sink ベースの IO。Okio の後継
• kotlinx-coroutines — 最初から KMP-first
• kotlinx-serialization — KMP 前提
• ktor-client — マルチプラットフォーム HTTP クライアント
• SQLDelight 2.x — 型安全 SQL、KMP
• Multiplatform Settings — プラットフォーム別 key-value(Android SharedPreferences・iOS NSUserDefaults 等)
• Compose Multiplatform — 上で扱った UI ツールキット

import kotlinx.datetime.*

val now: Instant = Clock.System.now()
val zoned = now.toLocalDateTime(TimeZone.of("Asia/Seoul"))
val plus3h = now.plus(3.hours)

第 19 章 · Kotlin/Wasm — Web の新たな可能性

Kotlin 1.9.20 で Kotlin/Wasm ターゲットが追加された。2024 年に Wasm GC 標準が Chrome・Firefox で stable になったことで、Kotlin は JS 変換なしに Wasm バイナリを作れるようになった。

なぜ重要か:Kotlin/JS は出力サイズが大きく、インターロップ表面も広かった。Wasm GC は JVM・V8 と同じガベージコレクタをブラウザ内に持つので、Kotlin・Compose のオブジェクトモデルが変換なしで動く。

ステータス(2026 年 5 月):Kotlin/Wasm 自体は alpha だが、Compose Multiplatform for Web はこのバックエンドの上で stable に近づいた。JetBrains のライブデモ(Compose Image Viewer)がその証拠だ。

KVision、Kobweb:Kotlin/Wasm・JS で作るフルスタック Web フレームワーク。Kobweb は Compose ベース、KVision は React 風のコンポーネントモデル。

// Compose for Web (Wasm GC)
@Composable
fun App() {
  var count by remember { mutableStateOf(0) }
  Column {
    Text("Count: $count")
    Button(onClick = { count++ }) { Text("Increment") }
  }
}

第 20 章 · 韓国 Kotlin コミュニティ — Kotlin Seoul と Kotlin Days Korea

ソウル中心の Kotlin コミュニティは活発だ:

• Kotlin Seoul — 定期ミートアップとサイドプロジェクト。JetBrains 公認 KUG の一つ
• Kotlin Days Korea — JetBrains と協業する年次カンファレンス、2023 年から毎年開催
• Korean Android Developers — Android・Kotlin の合同コミュニティ
• GDG Seoul Android — Google Developer Group 傘下

学習リソース:JetBrains Academy 韓国語版、"Kotlin in Action" 第 2 版韓国語訳、"Kotlin Coroutines: Deep Dive" 翻訳版。

企業の採用市場で Kotlin は Android 以外にサーバー(Ktor・Spring Boot Kotlin)・フィンテック(KMP)で急速に伸びている。2026 年時点で Naver・Kakao・Toss・Coupang が Kotlin サーバーを運用している。

第 21 章 · 日本 Kotlin コミュニティ — Kotlin Fest と DroidKaigi

東京も負けず劣らず活発だ:

• Kotlin Fest — 毎年東京で開催される日本最大の Kotlin カンファレンス。2018 年スタート、2024 年に再開
• DroidKaigi — Android カンファレンスだが Kotlin セッションが半分以上。KMP・CMP の発表が毎年増えている
• JetBrains Tokyo — JetBrains 日本法人主催の定期イベント
• Kotlin Tokyo — JetBrains 公認 KUG

企業では Cyberagent、DeNA、Mercari、Yahoo! Japan、LINE などが Kotlin・KMP をプロダクションで使う。Mercari の KMP 導入ケース(2022 年)は KotlinConf で発表された。

学習リソース:"Kotlin in Action" 日本語版、Wantedly・Mercari エンジニアリングブログの Kotlin シリーズ、DroidKaigi の動画アーカイブ。

第 22 章 · 2026 年 Kotlin 採用マトリクス — どこで何を使うか

最後にまとめ。**「何を作るときに何を使うか」**の単純なマトリクス。

覚えておくべき一文:Kotlin はもうツールではなくエコシステムだ。何を作るにせよ — その場に合う Kotlin ツールが既に存在する。

エピローグ — マルチプラットフォームが本当に働く時代

2026 年の Kotlin は「JVM 上のよりよい Java」という最初のアイデンティティをとっくに超えている。K2 コンパイラ GA でコンパイル速度が解放され、Compose Multiplatform 1.7 で iOS が stable になり、Wasm GC が Web の最後のピースを埋めた。KSP 2 と Arrow 2 がコンパイラ拡張と typed FP の標準になり、Ktor 3 がサーバーサイドに定着した。

Kotlin を初めて触る人には — Coroutines と Flow から学ぶのが最短ルートだ。Android だけならそこから Compose へ、サーバーをやるなら Ktor へ、マルチプラットフォームを見るなら KMP ライブラリ(kotlinx-*)から。

最後の一文:「一度書けばすべてのプラットフォームで動く」という約束はしばしば嘘だったが — 2026 年の KMP ではビジネスロジックに限ればほぼ本当だ。

参考資料

1. Kotlin Blog — Kotlin 2.0 Released
2. Kotlin Blog — Kotlin 2.1.0 Released
3. Kotlin Blog — Kotlin 2.2.0 Released
4. Kotlin Multiplatform Stable Announcement
5. Compose Multiplatform 1.7 — iOS Stable
6. Jetpack Compose 1.7 Release Notes
7. Kotlin Coroutines Documentation
8. Ktor 3.0 Release
9. Exposed — Kotlin SQL Framework
10. KSP 2 Documentation
11. Arrow 2.0 — Typed Errors
12. kotlinx.serialization Guide
13. kotlin-inject
14. Koin 4 Documentation
15. Spring Boot 3.4 Release Notes
16. Kotlin Multiplatform Libraries List
17. Kotlin/Wasm Documentation
18. SQLDelight 2.x
19. Kotest Documentation
20. Turbine — Flow Testing
21. Android 15 Behavior Changes
22. Material 3 Expressive — Android Developers