【Kotlin 2.4】ついに登場!コレクションリテラル(実験的サポート)と型推論の仕組みを徹底解説

Kotlin開発者の皆さん、お待たせしました!

2026年6月にリリースされた Kotlin 2.4 にて、待望の「コレクションリテラル(Collection Literals)」が実験的(Experimental)にサポートされました。

これまで listOf()mutableListOf()arrayOf() などの関数を使って記述していた配列やリストの生成が、ついにスクエアブラケット [] を使って、よりシンプルかつ直感的に書けるようになります。

この記事では、コレクションリテラルの導入方法から、最も重要な挙動である「文脈依存の型推論(Context-sensitive Type Inference)」について詳しく解説します。

 

🧑🏻‍💻 コレクションリテラルとは?

Kotlin 2.4.0からは、以下のようにブラケット [] を使ってコレクション(配列やリストなど)を簡潔に作成できるようになります。


// Kotlin 2.4からの新しい書き方(リテラル表記)
val names = ["Joe", "Alice"]

従来の listOf("Joe", "Alice") と比べてタイピング量が減り、他言語(Javaの配列リテラルや、JavaScript/TypeScript/Pythonなどの配列・リスト表記)に慣れている開発者にとっても、より親しみやすいコードになります。

 

🧑🏻‍💻 導入方法(実験的サポートの有効化)

Kotlin 2.4時点では、この機能はまだ実験的(Experimental)な位置づけです。そのため、プロジェクトで利用するにはコンパイラオプションで明示的に機能を有効化する必要があります。

build.gradle.kts に以下の設定を追加してください。


kotlin {
    jvmToolchain(21)
    compilerOptions {
        // コレクションリテラルを有効化するコンパイラ引数
        freeCompilerArgs.add("-Xcollection-literals")
    }
}

 

🧑🏻‍💻 注目すべき「型推論」の挙動

コレクションリテラルを使う上で、最も興味深いのが「コンパイラがどのように型を推論するか」という点です。

Kotlinのコレクションリテラルは、単一の固定された型を表すのではなく、周囲の文脈(期待される型)に応じて最終的な型が変化する「文脈依存(Context-sensitive)」の性質を持っています。

具体的なコードで比較してみましょう。

1. 明示的な型指定がない場合

ターゲットとなる型を何も指定せずにリテラルを書いた場合、コンパイラはデフォルトで Array(配列) と推論します。


val names = ["Joe", "Alice"]
// 推論される型: Array<String>

2. 期待される型(型注釈)がある場合

変数の型を明示的に指定すると、リテラルの中身は同じ [] であっても、コンパイラが文脈を読み取って適切なコレクション型へと変換してくれます。


val names: MutableList<String> = ["Joe", "Alice"]
// 推論される型: MutableList<String>

このように、左辺の MutableList<String> という情報をコンパイラが解釈し、[] の部分を適切に MutableList として扱ってくれるのが、今回の型推論の面白いところです。

 

🧑🏻‍💻 まとめ:Kotlinのコードはさらに洗練される

Kotlin 2.4のコレクションリテラルは、ただの「書き方の省略」にとどまらず、Kotlinの強力な型推論エンジンとシームレスに融合している点が大きな特徴です。

現在はまだ実験的な機能であるため、プロダクション環境への導入には慎重になる必要がありますが、将来的に正式機能となれば、Kotlinのコードをさらにモダンでスッキリとしたものに変えてくれることは間違いありません。

興味のある方は、ぜひコンパイラオプションを追加して、手元のプロジェクトで新しい書き味を試してみてください!


Jetpack Compose のワンタイムイベントで SharedFlow をやめて Channel にした理由

Jetpack Compose で Snackbar、Navigation、Toast のような「一度だけ処理したいイベント」をどう扱うかは、多くの Android エンジニアが一度は悩むポイントです。

私も長い間 SharedFlow を使っていました。

しかし最終的には、Compose の UI イベント用途では Channel を使うようになりました。

この記事では、

- なぜ SharedFlow で問題が起きやすいのか
- なぜ Channel の方が自然だったのか
- Compose のライフサイクルと何が噛み合わないのか

を整理してみます。

 

🧑🏻‍💻 One-Time Event とは?

まず前提として、Compose には大きく 2 種類のデータがあります。


State
└─ 画面が「今どういう状態か」

Event
└─ 一度だけ実行したいもの

例えば:

State は「現在値」が重要です。

しかし Event は違います。

「発生した」という事実だけ重要

つまり:

- 1回だけ消費したい
- 再購読時に再実行したくない
- 画面回転で再発火したくない

という特徴があります。

 

🧑🏻‍💻 SharedFlow を使っていた頃

最初は多くのサンプルと同じように SharedFlow を使っていました。


private val _event = MutableSharedFlow<UiEvent>()
val event = _event.asSharedFlow()

UI 側では:


LaunchedEffect(Unit) {
    viewModel.event.collect { event ->
        when (event) {
            is UiEvent.ShowSnackbar -> {
                snackbarHostState.showSnackbar(event.message)
            }
        }
    }
}

一見すると問題なさそうです。

しかし実運用では、徐々に違和感が出てきました。

 

🧑🏻‍💻 Collector がいないとイベントが消える

SharedFlow(replay = 0) は、

購読者がいない時のイベントを保持しません

つまり:


ViewModel emits event
        ↓
Compose がまだ collect 開始していない
        ↓
イベント消失

が起きます。

特に Compose では:

- 画面遷移直後
- Lifecycle 切り替え
- BackStack 復帰
- 一時的な recomposition

などで collector の開始タイミングがズレやすいです。

 

🧑🏻‍💻 replay = 1 にすると今度は別問題

では replay = 1 にすれば良いのでしょうか?


MutableSharedFlow(
    replay = 1
)

これは確かにイベント消失を防ぎます。

しかし次は:

画面回転したら
昔のイベントが再配信される問題が発生します。

例えば:


Snackbar 表示
↓
画面回転
↓
Snackbar 再表示

これは UX 的にかなり不自然です。

Navigation だとさらに危険です。

画面回転しただけで
再度 navigate される

ことがあります。

 

🧑🏻‍💻 SharedFlow は「共有ストリーム」

ここで改めて考えると、SharedFlow は本来:

複数 collector に
同じデータを共有する

ための仕組みです。

つまり設計思想としては:

- 状態通知
- Broadcast
- Hot stream

寄りです。

一方 One-Time Event は:

- 1回だけ消費したい

なので、実は思想が少しズレています。

 

🧑🏻‍💻 Channel に変えた

そこで最終的にこうなりました。


private val _event = Channel<UiEvent>(
    capacity = Channel.BUFFERED
)

val event = _event.receiveAsFlow()

送信:


viewModelScope.launch {
    _event.send(
        UiEvent.ShowSnackbar("Saved")
    )
}

受信:


LaunchedEffect(Unit) {
    viewModel.event.collect { event ->
        when (event) {
            is UiEvent.ShowSnackbar -> {
                snackbarHostState.showSnackbar(event.message)
            }
        }
    }
}

 

🧑🏻‍💻 なぜ Channel の方が自然だったのか

Channel は:

Queue

です。

つまり:


送る
↓
溜まる
↓
1個ずつ消費

になります。

これは One-Time Event の性質にかなり近いです。

特に:

- Snackbar
- Navigation
- Dialog
- Toast

のような

順番に1回だけ処理したい

イベントと相性が良いです。

 

🧑🏻‍💻 BUFFERED が重要

Compose では collector が少し遅れて開始することがあります。

そのため:

Channel.BUFFERED

を使うことで、

collector 開始前のイベント

もある程度保持できます。

これは SharedFlow(replay = 0) よりかなり扱いやすく感じました。

 

🧑🏻‍💻 ただし Channel にも注意点はある

もちろん Channel が万能ではありません。

特に重要なのは:

基本的に single consumer 前提

である点です。

つまり:

複数 collector が同時に collect

すると、どこが消費するか不定になります。

そのため:

UI Event 専用

として割り切るのが重要です。

 

🧑🏻‍💻 個人的な使い分け

現在は大体こう整理しています。

かなり安定しました。

 

🧑🏻‍💻 Compose では「State」と「Event」を分けるのが重要

Compose は State 管理が非常に強力です。

しかしその反面、

Event を State と同じ感覚で扱う

と事故りやすいです。

特に:

- Snackbar
- Navigation
- Dialog
- Permission request

などは:

状態ではなく副作用

として考えた方が整理しやすいです。

 

🧑🏻‍💻 まとめ

SharedFlow は優秀ですが、

One-Time Event に完全最適

とは限りません。

Compose のライフサイクルと組み合わさると:

- イベント消失
- replay 問題
- collector timing 問題

に遭遇しやすいです。

一方 Channel は:

FIFO queue

として動作するため、

- 一度だけ処理したい
- 順番保証したい
- 再配信したくない

という UI Event とかなり自然に噛み合いました。

最近は:

State は StateFlow
Event は Channel

という形に落ち着いています。

 

🤔 参考


Kotlin by JetBrains「Jake Wharton | KotlinConfersations'26」の文字起こし

Android開発やKotlinコミュニティのキーパーソンであるジェイク・ウォートン(Jake Wharton)氏へのインタビューです。

 

🤔 1. 自己紹介とKotlinとの歩み [00:26]

経歴:
長年Androidデベロッパーとして活動。Square(現Block)、Cash Appを経て、現在はSkylightに在籍。

Kotlinとの出会い:
Square時代、Java 7の機能不足やGoogleのツール進化の遅さに悩んでいた「プレ1.0(正式リリース前)」の頃にKotlinに注目。社内向けに導入提案書(プロポーザル)を作成。

反響:
その提案書を公開したところコミュニティで大きな話題となり、SquareでのKotlin導入だけでなく、エコシステム全体の盛り上がりに繋がった。

 

🤔 2. AndroidにおけるKotlinとコミュニティの力 [01:50]

Googleでの活動:
一時期Googleに籍を置き、AndroidにおけるKotlinの公式サポート(KTXライブラリなどの立ち上げ)を支援。

エコシステムの進化:
KTXライブラリのコード自体は現在通常のライブラリに統合されて役目を終えたが、それは言語が成熟した良い証拠であると語る。

Apple(Swift)とのアプローチの違い:
iOSのSwiftがAppleという中央集権からトップダウンで提供されたのに対し、AndroidにおけるKotlinは「草の根(グラスルーツ)的なコミュニティの熱意」から始まり、最終的にGoogleが公式サポートせざるを得ない流れを作った点がユニークである。

非Androidへの広がり:
「KotlinはGoogle製でも、Android専用でもない」という点が、15年経った今ではAndroid以外の開発者にも広く認知されるようになった。

 

🤔 3. Kotlin Multiplatform (KMP) の挑戦 [05:35]

これまでのクロスプラットフォーム:
過去のXamarinやPhoneGap、現代のReact NativeやFlutterなどを評価した上で、Cash App時代にKotlin Multiplatform(KMP)とCompose Multiplatformを選択。

アプローチの特徴:
UI層はiOSならUIKit/SwiftUI、WebならHTML DOM、AndroidならCompose UIといった「各プラットフォーム独自のネイティブビュー」を尊重し、バックエンドのビジネスロジックやプレゼンターロジックのみを共通化(シェア)する方針をとった。

KMPの強み:
他のクロスプラットフォーム言語と異なり、WebならJavaScript、iOSならネイティブコード、AndroidならJavaバイトコードと、ターゲットごとに最適な形へコンパイルされるため、メモリ空間の競合や相互運用の壁(Interop layer)が少ない。

エコシステムへの貢献:
5年前に始めた当時はJetBrainsのComposeも初期段階だったため、自分たちで足りないターゲットを作るなどしてエコシステムを強力にプッシュした。

 

🤔 4. オープンソース(OSS)の重要性 [10:53]

キャリアへの影響:
オープンソースに貢献することで、自身のスキルアップだけでなく、新しい人との出会いや転職の機会など、キャリアの節目で何度も救われた。

企業とOSSの関係:
REST APIとの通信や画像読み込み、依存関係の解決(DI)など、どのアプリでも共通する「ビジネスの知的財産(IP)ではない部分」のコードはオープンにすべき。結果的に会社の採用活動(「OSSを見て応募した」という優秀な人材の獲得)など、数字に表れにくい大きなリターン(無形の資産)をもたらす。

 

🤔 5. 生成AI(LLM)とライブラリの未来 [15:11]

「AIがコード生成できるならライブラリ投資は不要か?」という問いへの持論:
「コードを書くこと(Writing code)」自体は、ソフトウェア開発において決して最も難しい部分ではない。AIは既存のスキルを加速させる(アクセラレーター)ツールとして使うべきであり、それなしではコードが書けないような依存の仕方はリスクがある(将来的なコスト高騰も含めて)。

コードは書かれる回数より、読まれる回数の方が10倍多い(Code is read 10 times more than it's written)。 要件は常に変わるため、全体を俯瞰して理解できるコード設計が重要。

ライブラリの役割:
ライブラリの真の価値は「再利用可能なコードの境界線(デリミテーション)」を明確に引き、人間の認知負荷を下げることにある。パレートの法則のように「80〜85%の共通ユースケース」を綺麗にカプセル化することが大切。人間にとって直感的で優れた設計は、言語モデル(AI)にとっても扱いやすいはずである。

 

🤔 6. 2026年現在のKotlinへの期待 [22:45]

K2コンパイラの恩恵:
長年開発が続けられてきた「K2コンパイラ」への移行(大きな山場)を乗り越えたことで、言語自体の進化スピードが再び加速している。

注目している新機能:
Rich Errors(エラー処理の改善)プロポーザルの刷新
未使用の戻り値チェッカー(Unused return value checker)
when 式のデフォルト網羅性(Exhaustive when by default)

現在の心境:
K2の開発に全力を注いでいた停滞期を抜け出し、標準ライブラリ(datetimeやco-routinesなど)や言語プロポーザルが活発に進化している今の状況は、初期のKotlinのワクワク感を思い出させる。

 

🤔 7. コミュニティへの参加に気後れしている人へのアドバイス [27:30]

提案書(KEEP)の難しさ:
KEEP(Kotlin Evolution and Enhancement Process)はコンパイラの構文解析や各プラットフォームのバイトコードまで考慮しなければならず、内容が非常に高度で圧倒されるのは当然。

おすすめの関わり方:
Kotlin公式Slack(Kotlinlang Slack)にある language-proposal や language-evolution チャンネルを覗いてみるのがおすすめ。そこでは、より人間的で身近な困りごとや質問が、消化しやすい形で活発に議論されている。


Androidアーキテクチャの現状:GoogleのUDFと現実世界の「MVI風MVVM」の比較

現代のAndroid開発においてどのアーキテクチャを採用するかを議論する際、議論はほぼ常にMVVM対MVIのどちらにするかという点に集約されます。

しかし、近年の傾向を見ると、この2つは対立する力ではなく、収束しつつあることは明らかです。

 

🧑🏻‍💻 Googleの立場:特定のパターン名よりもUDFを優先

Googleの公式「アプリアーキテクチャガイド」を詳しく見てみると、「MVI」という用語はほとんど出てこないことに気づくでしょう。その代わりに、Googleは一貫してUDF(単方向データフロー)という概念を推奨しています。

Googleは、コミュニティに既に馴染みのある「MVI」ではなく、なぜ抽象的な用語である「UDF」を使用するのでしょうか?

その理由は、Googleが柔軟性を重視していることにあり、彼らの哲学は次のようなものと思われます。

「MVIのような厳格な命名規則にとらわれすぎないでください。アーキテクチャの本質である一方向のデータフローが維持されるようにするだけで十分です。」

Reduxのような厳密な状態管理ライブラリを使用する場合でも、シンプルなViewModelで実装する場合でも、Googleが重視するのは「状態は下へ流れ、イベントは上へ流れる」という基本原則に従うことです。

 

🧑🏻‍💻 現代の標準:MVI風MVVMの実装

現場では、Googleが推奨するUDFに対する最も一般的なアプローチは、私が「MVI風味のMVVM」と呼ぶもので、MVIルールをMVVMコンテナに詰め込むものです。これには、状態、意図、効果という3つのコア要素が含まれます。

実際には以下のようになります。


Composeのバケツリレーが限界? CompositionLocalでスマートに解決

etpack Composeで階層が深くなると発生する「バケツリレー(Prop Drilling)」。

「自分(中間コンポーネント)は使わないのに、孫に渡すためだけに引数を定義する」という不毛な作業は、CompositionLocal でスマートにショートカットしましょう。

🧑🏻‍💻 1. CompositionLocal の仕組み

通常、データは「親 → 子 → 孫」と引数で手渡ししますが、CompositionLocal はツリー全体にデータを「漂わせる」イメージです。

下の階層にいるコンポーネントは、必要なときにそのデータを「キャッチ」するだけで済みます。

🧑🏻‍💻 2. 実装例:2つのデータ(名前と色)を孫まで飛ばす

「ユーザー名」と「テーマカラー」の2つのデータを、中間の「子」を介さずに「孫」へ届けます。

① データの「鍵」を定義する

まず、共有したいデータの種類ごとに CompositionLocal オブジェクトを作成します。


import androidx.compose.runtime.staticCompositionLocalOf
import androidx.compose.ui.graphics.Color

// 1. 各データの「鍵」を作成(デフォルト値を設定)
val LocalUserName = staticCompositionLocalOf { "ゲスト" }
val LocalUserColor = staticCompositionLocalOf { Color.Black }

② 親・子・孫の実装

中間の ChildView が引数を一つも受け取っていない点に注目してください。


@Composable
fun ParentScreen() {
    val name = "桃太郎"
    val brandColor = Color(0xFFFF5722) // オレンジ

    // 2. CompositionLocalProvider で値を注入(複数一気に指定可能)
    CompositionLocalProvider(
        LocalUserName provides name,
        LocalUserColor provides brandColor
    ) {
        // 子を呼び出す(引数で渡す必要なし!)
        ChildView()
    }
}

// --- 中間のコンポーネント ---
@Composable
fun ChildView() {
    // 自身はデータを使わないので、引数も処理もスッキリ!
    println("ChildView: 私は何も知りません。")
    GrandChildView()
}

// --- データの使い道がある末端(孫) ---
@Composable
fun GrandChildView() {
    // 3. .current を使って必要なデータだけを直接取得
    val name = LocalUserName.current
    val color = LocalUserColor.current

    Column {
        Text(text = "こんにちは、${name}さん!", color = color)
        Text(text = "親から直接データを受け取りました。")
    }
}

🧑🏻‍💻 3. なぜ「2方向」でも楽なのか?

バケツリレーの場合、渡す項目が「名前」「色」「権限」「ID」と増えるたびに、ルートから末端までの全関数の引数を書き直す必要があります。

CompositionLocal なら:
親: provides を追加するだけ

子: 修正不要(ここが最大のメリット!)

孫: .current で取り出すだけ

🧑🏻‍💻 4. 注意点:使いすぎに注意!

魔法のように便利な CompositionLocal ですが、使いすぎると「このコンポーネントは何に依存しているのか?」がコードから読み取りにくくなります。

推奨: アプリ全体のテーマ(色・フォント)、ログインユーザー情報、ロケール設定など。

非推奨: その画面内の特定のボタンでしか使わないような一時的なフラグ。

バケツリレーが3階層を超え、中間コンポーネントが「ただの運び屋」になっていたら、CompositionLocal への切り替え時かもしれません。