プロポーザル

自分はわかっていませんでした。
HTTPクライアントでJSONレスポンスを扱う際、型変換の冗長な実装をジェネリクス使って書いたぐらい。
その時もコンパイルエラーと戦って試行錯誤してなんとか乗り切っていました。

本セッションでは、Kotlinの機能である inline + reified 型パラメータを使った関数がどのように振る舞うか、何が理解できたらコンパイルエラーに勝てるかを考えていきます。

話す内容

• クラス情報の受け渡しが不要な、型推論を活かしたAPI設計
• List<User> のようなジェネリック型も正しく扱える型安全性
• inline + reified を使う最も適したケースは?
• HTTPクライアント実装における reified の実践的な活用パターン

Kotlin 2.2とIDEA 2025で追加された「Stack Trace完全復元」「ローカル変数保持」「Suspend History」により、Coroutineデバッグが一変。

デバッグビルドでは最適化を自動停止し、kotlinx-coroutines-debug 1.10+ がサスペンドチェーン全体を結合した完全Stack Traceを生成。
Suspend Historyパネルは中断・再開ポイントを時系列表示し、原因を直感的に特定できます。
本セッションでは仕組みを図解しつつ、既存プロジェクトを5分で対応させるGradle設定、CI連携、リリースビルドとの棲み分けを解説。
JetBrains社内で調査時間を70％短縮した実例を基に、再現困難バグを即解決するワークフローや最適化を紹介します。

大規模なKotlinプロジェクトでは、数百から数千の依存ライブラリが存在し、それらの管理は容易ではありません。 また、昨今のサプライチェーン攻撃の高度化により、依存ライブラリ管理の重要性も増しています。

そこで、本セッションでは、開発者目線の、Gradle/Trivy/GitHub Actionsを用いた依存ライブラリ管理の自動化パイプラインの構築例を紹介します。

本セッションのポイント

• Gradleのdependency関連機能について
• 既存のSBOMツールの課題とLockfile & Trivyによる解決
• GitHub Actionsによる自動パイプラインの構築
• OSSスキャナを用いた定期的な脆弱性スキャンの導入

Kotlin ScriptによるGradle Taskの実装例も交えつつ、明日からでもすぐに試せる、段階的に導入できる実践的なテクニックを紹介します。

私たちは、自社プロダクトのバックエンドを100% Kotlinでフルスクラッチ開発し、全面リニューアルを実現しました。
PoCや部分導入ではなく、Kotlinを採用したリアルシステム開発の結果を総括してお届けします。
特に設計方法として、DDDとクリーンアーキテクチャをKotlinと組み合わせることは非常に魅力的な選択肢であり、ぜひノウハウを紹介させてください。

プロダクトとしては、全国から収集したご家庭のテレビ視聴ビッグデータを解析してユーザに提供しており、toC向けとして "TVAL now" も公開しています。
Kotlinで本格的なプロダクト開発を検討中の方にとって、技術選定や体制づくりのヒントになる内容をお話しします。

アプリを開発していると「SNSでシェア」や「レポートを出力」という処理を実装することがあります。
その際、表示されている画面をそのままキャプチャする場合は問題ないのですが、そうではないケースも存在します。
例えば、シェア用にロゴを追加したい場合や、縦向き画面を横向きで画像生成したい場合です。

この際に役立つのが、画面に表示していないUI要素から画像を生成する技術です。
alpha=0FやViewCompositionStrategy、NoTouchFrameLayoutを組み合わせることで、
画面表示とは独立したシェア専用UI要素のキャプチャが実現できます。
実際のプロダクトでの実装例と共に、この実用的な技術をお伝えします。

Kotlin Conf 2025 で will become part of the language の発表があった "Power Assert compiler plugin" は、失敗したアサーションの中間値を可視化するという“あの体験”を実現します

具体的には assert(actual == expected) と書くだけで非常に読みやすい Assertion Error が入手できます

本セッションでは、

• 実 Gradle Project への導入スニペット

から始まり

• 複雑条件／Soft Assertion
• created_at 等の特定フィールド無視比較

などの課題の解決策を具体的なコードとライブデモで紹介し、明日から既存テストを段階的に Power Assert に置き換える手順を持ち帰っていただきます

長年にわたりKotlinを愛でてきた皆さんの中には、慣れ親しんだ「古き良き」書き方で開発を進めている方も多いでしょう。私もその一人です。しかしKotlinは進化し、最新バージョンでは設計を大きく改善できる新機能が豊富です。このセッションでは、皆さんのKotlin知識をアップデートし、最新機能がもたらす設計改善の可能性を探ります。
特に、使い分けに悩む数種類ある「class」について、それぞれの特性とユースケースを詳解します。
このセッションを通じて、「古き良き」良さを活かしつつ最新機能で設計を改善し、より質の高い開発を進めるヒントを得られるはずです。

「ちょっとしたWebアプリを作りたいけど、Kotlinしか書けないしなあ…」と思ったことはないでしょうか？
Androidエンジニアの私は結婚式の余興でアプリを作ろうと思った時に同様の悩みを抱き、閃きました。
「そういえば、Compose for Webがあるじゃん！」と。
Kotlin/WasmによってComposeをブラウザ上で動かすこの技術はまだα版ですが、2024年に主要ブラウザがWasm GCをサポートしたことで実用性が大きく高まりました。
本セッションでは、登壇者がクイズアプリを開発した経験をもとに、Androidとの実装の違いや、Webならではの機能・落とし穴を共有します。

• Compose for Webの最新動向
• Androidアプリのこれ、Webだとどう実装する？
• こんなこともできる！Browser APIで広がるユーザ体験
• 初回読み込みの最適化

data classがネストすればするほど、copy()関数の呼び出しは複雑になり、コードの可読性は著しく低下します。この、多くのKotlin開発者が直面したことがあるであろう「copy()地獄」を、関数型プログラミングライブラリArrowのOpticsが解決します。
本セッションでは、まず中核概念であるLensの使い方から、その仕組みを自作するライブコーディング風の解説を通して深く理解します。さらに、Lensだけでは扱いきれないコレクションやsealed classを華麗に操作するTraversalやPrismといったOpticsの世界へご案内します。セッションを終える頃には、あなたのイミュータブルデータ操作は、より宣言的でシンプルで安全なものへと進化しているはずです。

CMPのiOS版がStableとなり、UIを一つのコードで表現できるようになりました。しかし、iOS側のUIがマテリアルデザインになってしまうというデザイン制約から、CMPではなくKMPを選択することも多いのではないでしょうか。

本セッションでは、大部分のUIをComposeで共通化し、iOS特有のこだわりがあるUIをSwiftUIで記述するハイブリッドCMP開発の手法についてご紹介します。この手法はiosAppモジュールに配置したSwiftUIをKoinでsharedモジュールに提供し、画面単位またはUIパーツ単位でSwiftUIをComposeの画面に埋め込むことで実現できます。これによりCMPの利点であるUIのコード共通化を行いつつ、デザイン自由度の制約を最小限にできます。

このセッションを通じ、iOSのUIにも妥協したくない人がCMPという選択肢を選べることを願っています。

Model Context Protocol (MCP) は、AI agentと外部を接続するためのプロトコルです。 JetBrainsにより公式Kotlin SDKがリリースされ、KotlinでもMCPサーバー/クライアントの実装が可能です。

本セッションでは、まずMCP Serverとは何かを説明した後、公式Kotlin SDKの内部実装を丁寧に解説します。基本的な技術の積み重ねで実現されています。
前半ではMCPの概要とユースケースを、後半では具体的な実装を扱います

・MCP Serverの役割と連携方法
・MCP Server プロトコルの基本構造
・Kotlin SDKのアーキテクチャ, Ktorを使ってる
・実際のMCP Server実装の解説

実際に動くコード例を交えながら、MCPをKotlinで扱う方法を基礎から実装まで体系的に解説します。

Android 15で進化したADPFは、CPUとGPUの協調的管理を可能にし、パフォーマンス管理に革命をもたらします。
しかし、その強力なAPIはC/C++製であり、Kotlinから安全に利用するにはJNIの壁が立ちはだかります。
本セッションでは、このネイティブAPIをKotlinのFlowや型安全なDSLを用いて、いかにクリーンで宣言的に抽象化するかを解説。
複雑なJNIコールを隠蔽し、パフォーマンスの未来を設計するための実践的テクニックをコードと共に提示します。

トーク予定内容
・ Android 15におけるADPFの進化やAPIについて
・ callbackFlowを用いたリアクティブな熱監視の実装手法
・ 型安全ビルダーによる宣言的なJNIラッパーの設計

Kotlin での開発といえば長らく JetBrain 社の IntelliJ IDEA が事実上の標準として選択されてきました。

今年の KotlinConf 2025 では Kotlin の LSP サーバ実装 (kotlin-lsp) の開発開始が JetBrains 社からアナウンスされました。kotlin-lsp は Visual Studio Code での利用が念頭におかれていますが、standalone 版も提供されているため、Emacs でも使える可能性はあります。本セッションでは Kotlin 開発を Emacs でしたいと思っている Emacser に向けて、以下のような機能の整備に挑戦した内容について共有します。

• eglot で kotlin-lsp を使うようにする
• tree-sitter
• flycheck + ktlint

Claude CodeやGitHub Copilot, Cline, Junie等のコーディングエージェントはもはやソフトウェア開発に欠かせないツールと言えるでしょう。

しかし、これらのツールをKotlin開発で効果的に活用するには、Kotlin特有の言語機能や慣習を理解した上での使い方が重要です。
本セッションでは、コーディングエージェントとの協働でKotlinらしいコードを生成するための実践的なテクニックを紹介します。
また、具体的なプロンプトの書き方やKotlin固有の機能を正しく生成させる方法、MCPサーバ等のツールの使い所などについて触れていきます。

本セッションでは以下の内容を含みます。

• コーディングエージェントを使っていて辛いところ
• 辛さをのりこえるために工夫していること
• 人間がやったほうが良いこと

Kotlinではイミュータブルなプログラミングスタイルが推奨され、kotlin.collectionsではListのようなイミュータブルなデータ構造が好まれます。
しかし、これらはミュータブルなコレクションへのダウンキャストが可能であったり、結合時に線形時間がかかったりといった欠点も存在します。

本セッションでは、この課題に対する選択肢として、kotlinx.collections.immutableで提供されるPersistentCollectionを紹介します。
PersistentCollectionは関数型プログラミングで頻繁に用いられるデータ構造であり、上記のイミュータブルコレクションが抱える欠点を克服しています。

本セッションが、PersistentCollectionの理解を深め、最適なコレクションライブラリを選択する一助となれば幸いです。

Kotlinでは、ベースとなるJavaで書かれたものを含めて、ライブラリが定義したGeneric Typeを安全にユーザー定義型と組み合わせて使えます。
皆さんも、日常的に List<User>, Map<ProductId, Product> 等の型を使ったコーディングを行っていると思います。

本セッションでは、この Generic Type について、型を越えたメソッドの再利用性以外の部分である、実際の継承関係にあるクラスと組み合わせたときの代入可能性を見ていきます。
タイトルの例は、まさに Java では×、Kotlin では○という、Kotlin をより安全たらしめる読み取り専用 List の例となっています。
このような活用について概念と実例の両方を理解し、Generics をより安全に利用・作成できるようになることをセッションのゴールとしています。

Coroutine、FlowはKotlinの便利な機能ですが、うまくテストできているでしょうか？
テストをうまく制御できなかったり、うまくテストできず、修正まで時間がかかってしまうこと、ありがちだと思います。

本セッションでは、CoroutineやFlowのテストに絞って、ポイントやハマりどころを解説します。
Flowのテストでは、Turbineというライブラリもご紹介します。
さらにこれらのテストの可読性や保守性を高めるためのTipsもご紹介します。

内容
・Coroutine、Flow、suspend関数のテストの基本とポイント
・Turbineライブラリの紹介
・機能テストなど大きめのテストでCoroutine/Flowを制御する方法
・テストダブルでうまくCoroutine/Flowを制御する方法

kotlin-metadata-jvmは、コンパイルされたKotlinクラスからメタデータを読み取るツールです。
kotlin-reflectよりも軽量で、よりKotlinに適したメタデータの取り扱いを行うことができます。

本セッションでは、kotlin-metadata-jvmの基本的な使い方と、実際の活用例を紹介します。
Metadataの概要を理解することでありがたみが伝わる、Binary Compatibility Validatorの「ビルドが壊れた」検知に触れます。
本セッションを通してkotlin-medadata-jvmを使ったメタプログラミングをより身近に感じてもらうことを目指します。

トーク予定内容

• なぜkotlin-metadata-jvmなのか
• kotlin-metadata-jvmの活用例
• BCVを用いた「ビルドが壊れた」の検知

Compose Multiplatform for iOSがStableとなり、iOSアプリをKotlinだけで開発する選択肢が、現実的な視野に入ってきました。

しかし、過去の歴史が示すように、マルチプラットフォーム技術は常に諸刃の剣です。
事業やチームの変化により、いつかその技術から「撤退」する日が来るかもしれません。
本セッションでは、この予期せぬ「撤退戦」までを考慮に入れた技術選定の重要性を提起します。

トーク内容

• マルチプラットフォームにおける「共通化」の功罪
• なぜ技術選定で「撤退戦」を考慮すべきなのか？
• Compose MultiplatformとKotlin Multiplatformの現在地
• 撤退シナリオから見る、Kotlin Nativeの真価 Kotlin+UIKitの組み合わせ
• 変化の時代における、プラットフォーム専門家が活きる技術選択の指針

Kotlinの言語機能ではないものの実際の開発で便利な機能がkotlinxライブラリとして提供されています。
馴染みの深いものだとcoroutiesやserializationなどは日常的に使っているのではないでしょうか。

そして、kotlinxには他にも多くの便利なライブラリが存在し、それらを適切に活用することで、よりよいコード、開発体験を得ることができます。
本セッションでは、よく知られたものからまだあまり知られていないものまで、kotlinxライブラリ群を紹介していきます。
また、各ライブラリがどのような課題を解決し、実際のプロジェクトでどう活用できるのか、具体的なユースケースとコード例を交えながら解説します。また、コミュニティライブラリとの使い分けや、言語公式のライブラリを利用するメリットについてもお話します。