「バイテンポラルデータモデル」という言葉を聞いたことがあるでしょうか？ビジネス時間と処理時間の2つの時間軸でデータを管理する概念で、時制を扱う必要があるシステムを設計するにあたって非常に有用なデータモデルです。Reladomoは、これを透過的に扱える稀有なORMですが、残念ながらKotlinから使うには多くの壁がありました。

本セッションでは、バイテンポラルデータモデルの概要を説明するとともに、Claude Codeをペアプログラミングパートナーとして、Kotlinを用いた型安全な設計、拡張関数、DSL等を活用してReladomoをKotlin with Spring Boot で簡単に扱えるようにしたお話をします。

このセッションでは、実際のコードとデモに加え、Claude Codeとの対話ログも一部お見せし、AIエージェントとのリアルなものづくりの実態もお伝えします。

普段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で扱う方法
・責務分離に基づいたシステム設計： 各モジュールの役割を分ける設計思想と、その具体的なパターン

多くのプログラミング言語には、言語仕様書が用意されています。
言語仕様書を読むことで、その言語に対する理解を深めるのみならず、知らなかった機能を発見することもあります。

しかし、言語仕様書を読みたいと思う一方で、とっつきにくいと感じている人も多いのではないでしょうか。
本発表では、型システムや継承など普段からよく使用する機能を取り上げて、言語仕様の観点から解説します。

日頃何気なく書いているコードを体系的に理解することで、次の2点の達成を目指します。
・Kotlinのより深い理解: 表層的な使い方から一歩踏み込み、Kotlinの本質的な理解につなげる
・言語仕様書を読む意義の理解: 「なぜコードがそのように動くのか」の答えが見つかる仕様書の意義・魅力を知り、読んでみたいと思ってもらう

想定聴講者: Kotlinを業務・個人開発で使用し、より深く理解したい方（脱初級者を目指す方）

一部の言語では文字列補間をカスタマイズすることで、リッチな体験を実現することができます。
例えばScalaのdoobieでは、SQLに値を埋め込むように書いても、実際には安全なplaceholder構文に変換することができます。
https://typelevel.org/doobie/

残念ながらKotlinにはこの仕組みはありませんが、Kotlin Compiler Pluginを使えば実現可能です。

そこで、Kotlin Compiler Pluginを活用することで前述したScalaのdoobieのようにSQLを書くことができる「kuery-client」というライブラリを開発してみました。
https://github.com/be-hase/kuery-client
このライブラリを題材に、Kotlin Compiler Pluginの開発事例をご紹介したいと思います。

書籍『ThoughtWorksアンソロジー』には「オブジェクト指向エクササイズ」(Object Calisthenics)と呼ばれる、手続き型プログラミングからオブジェクト指向プログラミングのコード設計の発想に親しむための訓練方法として(少々大胆で今や古めかしい?)ルール集が登場します。
関数型言語使い/関数型プログラミング実践者の立場から、静的型付きオブジェクト指向言語Kotlinに無理なく馴染み現実的にメリットのある形で関数型プログラミングを実践するための「関数型エクササイズ」(Functional Calisthenics)をご提案します。

構成(案)

1. 関数型プログラミングの基本的な発想と道具
2. 関数型プログラミングのコード設計に親しむための「関数型エクササイズ」(vs 「オブジェクト指向エクササイズ」)
3. Kotlinらしい実践のしかた

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

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

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

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

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

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

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

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

KoogはAIエージェントを構築するためのライブラリです。
シンプルにLLMにアクセスできる一方、複雑なワークフローを構築することもできます。
Kotlin愛好者はKotlinの知識を活かせるほか、KMPの資産を活用して様々なアプリケーションを開発できます。
実際、私はKoogを利用して作業効率化のためのデスクトップアプリやCLIツールを開発しています。

いまこそKotlinの知識を活かしてAIエージェントを構築するチャンスです。
本セッションでは、まず基本的な概要と使い方をご紹介します。
その後、Koogの最大の特徴であるエージェントワークフローの構築方法を解説し、
その設計の考え方を具体的な事例を交えてご紹介します。

内容
・基本的な概要、他のフレームワークとの比較
・基本機能の使い方
・Strategy Graphsで複雑なワークフローを構築する方法
・ワークフローの設計の考え方

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

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

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

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

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

トーク内容

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

KMPやサーバーサイドKotlinも台頭する中で、Coroutinesの利用者は最近も増え続けています。
シンプルな文法から「簡単」と称される一方、ブラックボックス化されているが故に、実際には「難しい」と感じる方も多いです。

この課題を解決すべく、私はCoroutinesを内部実装から解読し、知見を発信してきました[1-3]。
本発表では、Coroutinesの理解に役立つ、3つの仕組みを解説します。

1.中断・再開を可能とするContinuation[1]
2.制御・キャンセル・例外処理を支えるStructured Concurrency[2]
3.タスクスケジューリングを担うCoroutineDispatcher[3]

[1] https://bit.ly/3FZyjFG
[2] https://bit.ly/4ndeNpT
[3] https://bit.ly/45toABP