トーク

普段Kotlinを使った開発をしている中で、ビルドエラーに困ったことはありませんか？

単純なコンパイルエラーなら修正して終わりですが、Gradleプラグインのエラーなどは場合によっては原因の特定に時間がかかる場合があります。

また、ビルドが成功しても、ビルドした結果に疑問を持ったことはありませんか？自分はKMPでiOS向けにビルドする際、生成されたObjective-Cの型名や関数名にアンダースコアが付与されるなど、なぜこのようなビルド結果になるのかと思ったことがあります。

そんなとき、KotlinコンパイラーやGradleプラグインのソースコードに対してブレークポイントを貼り、普段のAndroidアプリ開発と同じようにDebuggerを使ってデバッグする方法を紹介します。

KoogでAIエージェントを、Ktorと公式MCP-SDKでサーバーを、そしてCMPでUIを構築し、フルKotlinで実現するシステムの実践的なプラクティスを提示します。
ただライブラリを使うのではなく、各モジュールの責務の定義、拡張性の高い設計やKMPを活かしたIFの共通化などをどのように実現するのか。
体系的な仕組みと「Kotlinらしい」アプローチをコードと共に解説します。

■ この発表で学べること
・MCPサーバーの構築： Ktorと公式SDKを使い、外部の情報をAIに提供する方法
・AIエージェントの構築： Koogを使い、 MCPサーバーとの疎通やビジネスロジックを「ツール」としてAIエージェントから利用する方法
・UIの構築： AIからのストリーミング応答をCMPで扱う方法
・責務分離に基づいたシステム設計： 各モジュールの役割を分ける設計思想と、その具体的なパターン

私たちは、レガシーコードのリファクタリングを通じてKotlinが持つ強力な言語特性を最大限に活かすための要素を模索し、「Kotlinらしいコードとは何か」という本質的な問いに向き合ってきました。

本セッションでは、AIを強力なパートナーとして活用し、単に動くコードを生成するだけでなくレガシーコードを「Kotlinらしい」真にモダンなコードに置き換える実践的なアプローチを深掘りします。

特に重要なのが、高品質な「Kotlinらしいコード」を生成させるための効果的なプロンプトです。本セッションでは、実際に試行錯誤を通じて得られた効果的な対話の例や、改善点、そしてそれによって生成されたコードの比較を具体的に示します。これにより、参加者の皆様が自身のプロジェクトでAIを用いてコードを刷新する際の実践的なヒントとノウハウを提供し、コードを生まれ変わらせる一助となることを目指します。

LINEマンガは累計5000万ダウンロードを超え、日々多くのユーザーにレコメンデーションを提供しています。 一見シンプルなバッチ処理も、この規模になると、億単位のデータを高速に連携する必要があるなど、全く別の課題が生まれます。 私たちは、これらの大規模データ処理を、Kotlinで実装したETLバッチパイプラインで支えています。

本セッションでは、この大規模ETLシステムの構築で直面している課題と、改善に向けたリアルな試行錯誤を共有します。

本セッションのポイント:

• 大規模データ処理における現実的な課題
• Kotlin Coroutines/Channel/Flowを用いた様々なトライ&エラー
• 失敗と成功から得られた実践的な指針

実サービスの試行錯誤を通じて見えてきた、Kotlinによる大規模データETLのリアルをお伝えします。

Kotlin 2.2で安定化されたコンテキストパラメータは、関数型スタイルによるDSL設計と依存管理の在り方を根本から変える言語機能です。
このセッションでは、従来のDIフレームワークに頼らずに、文脈に応じた型安全な設計を可能にする新しい開発スタイルを、実践的なコード例と共に紹介します。

たとえば、設定、認証、ログ、トランザクション管理など、アプリケーションに不可欠な「コンテキスト」は、従来しばしば暗黙的でテストしづらい依存として扱われてきました。コンテキストパラメータを活用することで、それらを明示的かつ再利用可能な文脈依存の値として、安全に受け渡すことが可能になります。

本セッションのゴールは、Kotlinの型とコンテキストでコードを制御するという新しいパラダイムを体感し、従来の設計から脱却して、より堅牢で理解しやすいコードベースへ進化する方法を学んでいただくことです。

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

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

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

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

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

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

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 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で広がるユーザ体験
• 初回読み込みの最適化

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

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

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

トーク内容

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

日々のコーディングで誰もが向き合う「文字列操作」。その面倒な作業が、いかにKotlinで楽しく、効率的になるか紹介します。

どのプログラミング言語でもある文字列というオブジェクトにフォーカスをあてて、Kotlinでは基本となる文字列操作から、あまり知られていない拡張関数まで、Kotlinで使える便利な文字列操作の世界へみなさまをご案内します。

KotlinPlaygroundはブラウザ上で編集・実行・共有が完結する、JetBrainsによって提供されているウェブサイトです。
Kotlinのバージョンや実行環境を簡単に変更して、ウェブ上で実行結果まで確認できるため、手軽に動作を確認できるサンプルコードを共有するツールとして活用されています。

直近では、Compose MultiplatformやSwift export、Canvas等の様々な実行環境のサポートが行われており、動くUIのサンプルを書いて共有することもできるようになっています。このセッションでは機能紹介からはじめ、ショートカットや、できることの限界といった点まで触れて効果的なコード共有を実現するためのベストプラクティスを含む内容を紹介します。

「動く」コードサンプルでチームのコミュニケーションをよりスムーズにしてみませんか？

KotlinによるServer Side Web FrameworkといえばSpringあるいはKtorかと思います。
Springを採用している組織がやや多い印象を受けますが、やはりPure KotlinなKtorも人気があります。
そんな昨今の状況において、Ktorを紹介する記事やセッションはちらほらと見かけますが「Ktorでしておくべき設定」にフォーカスした記事やセッションはあまり見た覚えがありません(主観)。

そこでこのセッションではよりKtorを深堀し、Ktorでぜひ設定しておきたい以下の機能についてお話ししようと思います。

• Auto Reload
• Tracing requests
• Type-Safe Routing
• Application structure

またこれらの機能を設定することで、「実際にどのような恩恵を受けられるか？」までお話しします。