プロポーザル

Kotlin 2.1から、KotlinをSwiftから利用する新しいinterop、Swift Exportが登場しました。

従来は、KotlinコードをObjective-Cとしてしか出力できず、Kotlinの言語機能を発揮しきることができませんでした。

しかし、K2 Compilerの新しいアーキテクチャによって、よりSwiftから利用しやすいinteropが実現しようとしています。

このトークでは、従来のObjective-C ExportやSKIEと比較しつつ、K2コンパイラ内でSwift Exportがどのように実現されているかを紹介します。
また、現在の状況や、今後のロードマップについても見ていきましょう。

チームのコーディング規約、形骸化していませんか？
コーディング規約はチーム開発において不可欠ですが、曖昧なルール、チームメンバーの変化、レビューコストの増加など、コーディング規約を運用するのには様々な課題があります。

本セッションでは、KotlinのLinterであるdetektのカスタムルール機能を利用してコーディング規約を運用する方法について以下の内容を紹介します。
・コーディング規約を取り巻く課題
・プロジェクト独自の規約を直感的なKotlinコードで明文化する方法
・実際に運用してみて効果的だったルール

このセッションを通じて、明日から開発生産性の向上に取り組める実践的な方法を得ることができます！

直近のCompose Animationのアップデートで、Modifier.animateBoundsが追加されました。
レイアウトのアニメーションが簡単に実装できるようになっています。
このアニメーションはアプリのUIを美しくし、ユーザー体験を向上させます。

本セッションは特にModifier.animateBoundsと、その基盤となるLookaheadScopeを深掘りし、
多様なレイアウトの変化をアニメーションさせる方法を紹介します。

・Compose Animationの新機能・動向
・Modifier.animateBounds、LookaheadScopeの概要と使い方、しくみ
・movableContentOfなどと組み合わせて多様なレイアウト変化をアニメーションする方法
・Modifierの適用順などの注意点

エンジニアリングマネージャー(EM)からエンジニアに戻り、初めてサーバーサイドKotlin開発に挑戦した実践と学びの記録です。
多言語でのプロダクト開発経験を持つKotlin初心者の私が、EM経験で培ったマインドを活用しながら、Kotlinやそのエコシステムをキャッチアップし、プロダクト開発にコミットした過程を紹介します。

以下のトピックを中心にお話しします。

• 高速な学習フィードバックループの構築方法
• Kotlinとライブラリの効率的な習得術
• サーバーサイドKotlinとプロダクトの親和性
• プロダクト課題の発見から解決までの実践
• ペアプロによる知識共有の効果
• AI活用の具体的な実例

これからサーバーサイドKotlinに挑戦する方へ、
苦戦したことも含めた実体験から「やってみたい！」と思える実践的なヒントをお届けします。

デッドコードはコードの保守性を低下させる要因の一つですが、新規開発が優先されることが多く、結果としてコードベースの健全性が損なわれることがあります。
私たちのプロダクトでは、開発生産性向上のためにフィーチャーフラグを活用しています。
しかし、リリース後に不要となったフィーチャーフラグがデッドコードとして残る問題に直面しました。
この問題を解決するために、kotlin-compiler-embeddableを用いた構文解析とGradleプラグイン開発によるデッドコード削除の自動化を試みました。

このセッションでは、それぞれの実装方法について言及しつつ、フィーチャーフラグに起因するデッドコードの削除を自動化した経験を共有します。
これらのテクニックはデッドコード削除以外にも応用可能であり、セッション参加者の皆様のアイデア実現の一助となれば幸いです。

既存の機能を拡張する際に、手順書や仕様書を頼りに実装したことはありませんか？
しかし、ドキュメントはすぐに陳腐化します。コードこそが最も正確で信頼できる唯一のドキュメントです。

コードが実装漏れを教えてくれれば、手順書や仕様書は不要になるはずです。その表現方法の１つとしてコンパイルエラーを用いることができます。
もし、実装漏れによってコンパイルエラーになれば、コードを実行すること・本番環境にリリースすることはできません。

本セッションでは、コンパイルエラーによって実装漏れを検知するための設計と、その実践事例、トレードオフについて紹介します。

キーワード
・コンパイルエラー、直和型、網羅性、interface、設計

本セッションでは、生成AIの活用に特化した新しい仕組み「Model Context Protocol（MCP）サーバー」を、KotlinとSpring AIを用いてどのように構築したかをご紹介します。
MCPは、AIアプリケーションと外部のデータソースやツールを連携させるための標準化されたプロトコルであり、AIアプリケーションの柔軟性と再現性を高める注目のプロトコルです。
セッションでは、Spring AIを実際に使用した際の所感や、MCPサーバーとしての活用方法に加え、設計方針や実装上のポイントについて解説します。
次世代AIアーキテクチャの実践事例として、今後MCPの導入を検討している開発者の皆様に、具体的なヒントをお届けします。

自分はわかっていませんでした。
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の実装例も交えつつ、明日からでもすぐに試せる、段階的に導入できる実践的なテクニックを紹介します。

アプリを開発していると「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 に置き換える手順を持ち帰っていただきます

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

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

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という選択肢を選べることを願っています。

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の理解を深め、最適なコレクションライブラリを選択する一助となれば幸いです。

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

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

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

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

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

トーク内容

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

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

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