【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のコードをさらにモダンでスッキリとしたものに変えてくれることは間違いありません。

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


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 チャンネルを覗いてみるのがおすすめ。そこでは、より人間的で身近な困りごとや質問が、消化しやすい形で活発に議論されている。


Embracing AGP 9 and JDK 21: A Gradual Path to Android Build Optimization

As Android developers, major AGP (Android Gradle Plugin) updates are always significant. AGP 9 in particular promises a stricter, faster build environment, moving away from ambiguous configurations.

Instead of waiting for its full release and then scrambling to fix issues, why not start preparing your project now, gradually aligning it with "AGP 9 standards" through your gradle.properties file?

 

🤔 Why JDK 21 and AGP 9 Now? (The Ultimate Synergy)

When transitioning to AGP 9, updating to JDK 21 isn't just a "requirement"; it's a powerful "booster" that dramatically enhances your development experience.

  • Performance Synchronization: JDK 21's improved resource management, including features like Virtual Threads, allows Gradle to fully leverage its parallel build capabilities, leading to more stable and efficient builds.
  • Language Specification Alignment: By targeting Java 21, you bridge potential gaps in type inference and bytecode generation in mixed Java/Kotlin projects, especially as Kotlin 2.x gains traction.
  • Precision R8 Optimization: AGP 9 is optimized to parse and transform class files generated by JDK 21. This means that even with stricter settings, R8 can more accurately understand modern code structures, reducing the need for excessive keep rules while safely shrinking code.

This combination offers the kind of seamless experience you get from pairing the latest OS with the latest CPU.

 

🤔 Prepare with gradle.properties: 10 Flags to Enable Today

The strategy is simple: enable one flag at a time, fix any errors that arise, and then move to the next. This iterative approach is the most reliable way to prepare for AGP 9.

1. Structure Enforcement (Clean Up Your Project)

  • android.uniquePackageNames=true: Prevents duplicate package names across modules, eliminating resource conflicts.
  • android.usesSdkInManifest.disallowed=true: Enforces placing minSdk, targetSdk, etc., in build.gradle instead of AndroidManifest.xml.
  • android.defaults.buildfeatures.resvalues=true: Explicitly controls the generation of resValue entries.

2. Build Speed Enhancements

  • android.enableAppCompileTimeRClass=true: Uses lightweight R classes during app compilation, significantly improving build times for large projects.
  • android.sdk.defaultTargetSdkToCompileSdkIfUnset=true: Automatically sets targetSdk to compileSdk if unspecified, preventing inconsistent behavior.
  • android.dependency.useConstraints=true: Utilizes Gradle's "Constraints" feature for dependency resolution, making library version management more robust.

3. Aggressive R8 / Optimization Settings (The Biggest Hurdle)

  • android.r8.strictFullModeForKeepRules=true: Enables R8's Full Mode. This maximizes optimization but requires precise keep rules for code that relies on reflection, potentially leading to crashes if not handled correctly.
  • android.r8.optimizedResourceShrinking=true: Employs a more advanced algorithm for removing unused resources, leading to smaller app sizes.

4. Next-Gen Defaults

  • android.builtInKotlin=true: Prioritizes AGP's built-in Kotlin support.
  • android.newDsl=false: Use this to maintain the current DSL while preparing for future changes.

 

🤔 Conclusion: One Flag at a Time for a Smoother Future

The AGP 9 update is akin to a major cleanup. Attempting it all at once can be overwhelming, but tackling it gradually makes it incredibly rewarding.

Why not start with android.uniquePackageNames=true? With each flag you enable, your project will move closer to a more modern, robust, and efficient build environment.

👉 AGP 9.0 移行ガイド:新旧コード比較で見るモダンビルド設定


3大 AIプラグイン ショートカット比較表(Copilot / JetBrains AI / Gemini)

 

🤔 3大AIプラグイン ショートカット比較表(Copilot / JetBrains AI / Gemini)

機能 GitHub Copilot JetBrains AI Assistant Gemini for Android Studio
AIコード補完の表示 ⌥](次候補)
⌥[(前候補)
⌥Space ⌘I または Ctrl+I
AI候補を確定 Tab または Enter Enter Enter
補完候補を拒否 Esc Esc Esc
AIチャットを開く ⌘⇧I ⌥⇧A ⌘⇧.
選択コードの説明 / 修正 ⌘⇧\\ ⌥Enter → 「AI提案」 ⌘⇧L
コメントからコード生成 // コメント後に Enter AIチャットから「コード生成」 コメント入力 → ⌘Enter
コードの最適化・修正 ⌘.(Quick Fix) ⌥Enter → 「AIでリファクタ」 ⌘⇧M
ドキュメント生成 / 説明追加 ⌘⇧/ AIチャット「この関数を説明して」 ⌘⇧D
選択範囲に対するAI操作 ⌘⇧\\(説明・修正) ⌥Enter ⌘⇧L
ファイル全体を改善 なし(コメントから提案) ⌥⇧A → 「ファイルを改善」 ⌘⇧F

 

🤔 AIプラグイン運用おすすめ(衝突回避パターン)

利用スタイル 構成 特徴・おすすめポイント
① コーディング中心型
(AI補完を重視)
Copilot + JetBrains AI(Copilot優先) Copilotの補完をメインに、JetBrains AIは「説明」「修正」時のみ使用。
⌥EnterをAI専用に割り当てると安定。
② 設計・レビュー重視型
(AI説明とチャットを多用)
JetBrains AI + Gemini(Copilotオフ) チャットでの説明・リファクタが中心。GeminiでAndroid特有の質問も可能。
⌥⇧A⌘⇧. の競合に注意。
③ Android特化開発型
(Geminiメイン)
Geminiのみ or Gemini + Copilot Android Studio統合が深く、ComposeやAPI質問が即答。
Copilotを補完専用に使うと最も安定。
④ 学習・試行型
(全部試すタイプ)
Copilot + JetBrains AI + Gemini(全併用) ショートカット競合が多発。どれを「補完用」「チャット用」にするか明確化必須。
設定から「Keymapのカスタム」を推奨。

 

🤔 AIプラグイン ショートカット競合リスク表

組み合わせ 競合リスク 主な衝突ショートカット 対策・回避策
Copilot + JetBrains AI ★★★☆(中〜高) ⌥Enter, Tab, ⌘. JetBrains側のAI提案を「右クリック呼び出し」に変更推奨。
CopilotをTab確定中心に設定。
JetBrains AI + Gemini ★★★(中) ⌥⇧A, ⌘⇧. どちらを「チャット起動」に使うか決める。
Geminiを ⌘⇧; にリマップ推奨。
Copilot + Gemini ★★(低〜中) Enter, ⌘I 競合は軽度。Copilotを補完専用・Geminiをチャット専用に分離。
Copilot + JetBrains AI + Gemini ★★★★(高) ⌘⇧I, ⌥Enter, Enter 全AIのショートカットを手動で再割り当て必須。
Preferences → Keymapで確認・上書きを推奨。

 

🤔 まとめ:

・同時導入するなら「補完」「チャット」「リファクタ」の役割を分ける。
・競合は特に ⌥Enter⌘⇧I に集中。
・キー設定は Keymap → Search: “AI” で全体を確認しておくのが安全。

Copilot:補完が最速で自然、Tab確定中心の軽快操作。
JetBrains AI:リファクタやドキュメント生成など開発支援が得意。
Gemini:Android Studioに最も深く統合され、自然言語操作が強力。


『AIで書いたコードは危険』と語る著名プログラマーたちのコメント

 

🤔 Jake Wharton

I really dislike all this 'auto complete sold as AI by big corpo' crap.

私はこの“大企業がAIとして売っているオートコンプリート”というクソみたいなものが本当に嫌いだ。

Don't blindly trust code generated by AI; always review and understand it.

AIが生成したコードを盲目的に信頼してはいけない。必ずレビューし、理解すること。

 

🤔 Andrew Ng

Just vibe coding is not going to help. Using and relying on generated code is dangerous. AI generated code can produce hallucinations.

vibe codingは役に立たない。生成されたコードを使って頼るのは危険だ。AIが生成するコードは幻覚を生じる可能性がある。

 

🤔 Martin Fowler

When I’m using AI for coding, I find myself constantly making little risk assessments about whether to trust the AI, how much to trust it, and how much work I need to put into the verification of the results.

AIを使ってコーディングをしているとき、私は常にAIを信頼するかどうか、その信頼度をどの程度にするか、結果の検証にどれだけの労力をかけるべきかを小さなリスク評価として行っています。

 

🤔 Kent Beck

I feel good about the correctness & performance, not so good about the code quality. When I try to write the code as a literate program there's ...

私は正確性とパフォーマンスには満足していますが、コードの品質にはあまり満足していません。コードをリテラルプログラムとして書こうとすると…

 

🤔 Robert C. Martin

The clean coder 'Uncle Bob' aka Robert C. Martin reflects on his career, the way he works and what advice he would give to his younger self if he were to start ...

クリーンコーダー“Uncle Bob”ことRobert C. Martinは、自身のキャリア、働き方、そして若い頃の自分にどんなアドバイスをするかについて振り返っています。

 

🧑🏻‍💻 まとめ

著名なプログラマー達は、AIをコーディングの補助ツールとして評価しつつも慎重な姿勢を見せています。

AIが生成したコードは盲信せず、品質管理の最終的な責任は開発者自身が負うべきだと彼らは強調します。

結論として、AIは便利なツールですが、その出力は常に人間の手でレビュー・検証される必要があります。

 

🤔 参考

👉 AI を使ったプロンプトに入れておきたい著名プログラマーの哲学的名言100