プロポーザル

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のようなイミュータブルなデータ構造が好まれます。
しかし、これらはMutableListへのダウンキャストが可能であったり、結合時に線形時間がかかったりといった欠点も存在します。

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

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

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

本セッションでは、この Generic Type について、Generics は、型を越えたメソッドの再利用性以外の部分、実際の継承関係にあるクラスと組み合わせたときの代入可能性を見ていきます。
タイトルの例は、まさに 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には他にも多くの便利なライブラリが存在し、それらを適切に活用することで、より効率的でKotlinらしいコードを書くことができます。本セッションでは、よく知られたものからまだあまり知られていないものまで、kotlinxライブラリ群を紹介していきます。また、各ライブラリがどのような課題を解決し、実際のプロジェクトでどう活用できるのか、具体的なユースケースとコード例を交えながら解説します。また、コミュニティライブラリとの使い分けや、言語公式のライブラリを利用するメリットについてもお話します。

株式会社asken では、バックエンドもモバイルもKotlinで統一した開発に挑戦してきました。

PHPからKotlinへのリプレイスを経て、KMP（Kotlin Multiplatform）導入、
iOS先行・Android後追いという試行錯誤、そしてKMPで職能の壁を越えて協業する開発体制へ。
ついにはBFFやAIネイティブな世界まで踏み込もうとしています。

Kotlinで広がる開発の可能性と、その奮闘の歴史を一緒に覗いてみませんか？
私たちのリアルな軌跡を紹介します。

Kotlinコミュニティ、特に地域Kotlinコミュニティは他のプログラミング言語と比べて意外に少ないのが現状です。
「ないなら作れば良い」という精神のもと、私は今年1月に京都でKyoto.ktを立ち上げました。
キックオフから現在まで計4回のイベントを開催し、徐々に参加者も増加しています。

本セッションでは、コミュニティを始めるモチベーションから初回開催までの具体的な道のり、継続運営のために心掛けていることなどを実体験ベースで発表します。
そのほか開催後に得たことや、学んだこと、地域ならではの特色などについてお話ししたいと思います。

このセッションをきっかけに「自分の地域でもKotlinコミュニティを作りたい！」と考えている方の後押しができればと考えております。少しでも何かの参考になれば幸いです。
あなたがお住まいのその地域で「ご当地Kotlinコミュニティ」を爆誕させてみませんか？

kintoneのAndroidアプリは2019年にリニューアルして以来、技術の進化に伴い様々な変更が必要となりました。とくに問題となっていたのはデータフローの高い複雑性で、新機能の開発を阻害したり、新規加入者の学習負荷を高くしていました。

そこで、私たちのチームはアプリの保守性と再利用性を向上させる大規模なリファクタリングを実施しました。

具体的には、Googleのアプリアーキテクチャに基づきマルチモジュール化を行い、RxをCoroutinesに置き換え、シングルトンインスタンスを削減し、独自ユーティリティクラスの使用を最小限に抑えました。さらに、一部のViewをComposeに移行しました。手動テストと自動テストの使い分け方も見直しました。これらの変更を、段階的に実施しました。

このセッションを通じて、大規模リファクタリングの具体的な進め方、チーム開発のヒントを得ることができます。

多くのKotlinプロジェクトで導入されるLinter/Formatter。
しかし、導入後に「警告が無視される」「設定が放置される」など、形骸化していませんか？ルールが機能しない状態は、一貫性を損ない、レビューコストの増大や技術的負債の原因となります。

Linterは一度設定して終わりではありません。チームの成長や議論を反映し、共に育てていく「品質基盤」です。
特にAI Agentによるコード生成が普及し始めた今、チームの合意を反映したLinterは、プロジェクトの品質を守るガードレールとなります。

本セッションでは、どうやって設定するか？からはじめ、放置された設定の見直し方、段階的な改善方法、Kotlinの言語機能を活かすCustomLintの活用、そしてチームの「理想のコード」を定義し、守る方法を探求します。
継続的にコード品質を高めるために、改めて設定を見直してみませんか？

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

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

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

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

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

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

みなさんはZodというTypeScriptのライブラリをご存じでしょうか。例えばメールアドレスを文字列として渡すと、それをパースして正しいメールアドレスの形式か？を判定してくれたりします。

では iolite というKotlin版ZodなOSSライブラリをご存じでしょうか。おそらく知らないと思います。なぜなら私がこのプロポーザルを書く5分前に公開したライブラリだからです。このライブラリはGeneric Value Objectの集まりとでも呼ぶべきものです。

このセッションでは、

• ioliteはどのようなものか
• ioliteはどのように使えるのか
• ioliteはどのように実装されているのか
• 開発にあたって使ったツール
• リリースまで苦労したこと
  についてお話しできればと思います。

Gradleでも使われているKotlin DSLはKotlinを利用してコンフィグなどのプロパティを記述することができる機能です 。
Kotlin DSLの一般的な利用方法と、変則的なKotlin DSLを使いこなすことでできることでできることを、実例を交えてお話ししたいと思います。
このセッションでは具体的に以下のことについてお話しします。

• Kotlin DSLの実装方法
• Kotlin DSLの実装例
• Kotlin DSLのコンポーネント化(部品化)
• 動的なKotlin DSLの実装

Dependency injection (DI) は保守性の高いアプリケーションを開発するために必須と言っても過言ではない設計パターンではないでしょうか。

Kotlinで開発をするうえで、言語機能を利用した手動DIや、KoinやDagger等のライブラリやSpring DIやQuarkus ArCのようなサーバサイドのアプリケーションフレームワークに組み込まれたものを利用するなど、様々なアプローチが存在します。
このセッションでは、DIの目的や原則などについておさらいをしながら、各アプローチについて具体的なコードとともに触れつつ、それらを利用するメリットとどのような場合に使うのが良いかの解釈についてお話していきます。

一部プラットフォーム固有の話が含まれる想定ですが、Kotlinが幅広い利用目的があることなどをふまえて、極力プラットフォームに関係なく話ができればと考えております。

業務オブジェクトが複雑化すると、新しい状態を追加するたびに「既存ロジックが壊れないか」と不安になりませんか？

私たちのプロジェクトでも同様の課題に直面しました。機能追加とともに業務オブジェクトの責務が肥大化し、プロジェクトが進むにつれて、さまざまな状態や処理が1つのクラスに集約され、ビジネスロジックが複雑化していきました。多様な状態を1クラスに詰め込んだ結果、可読性と保守性が低下し、新しい状態を追加するたびに既存ロジックへ影響するリスクが高まっていました。

本セッションでは、この複雑化したクラスを状態ごとに分割し、Railway-orientedフローを組み込むことで、「不正状態をコンパイル時に検知し、実行時には型で安全にハンドリングする」までの過程をお話しします。型システムを活かして、保守性と開発速度を両立させるヒントをお持ち帰りください。

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

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

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

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