はじめに
Kotlin プロジェクトでアノテーション処理を使うとき、
長らく kapt が主流でしたが、最近は ksp(Kotlin Symbol Processing)が推奨される流れになっています。
この記事では両者の違いと、なぜ ksp が登場したのか歴史を含めて整理します。
1. 歴史的背景
Java 時代の Annotation Processing
- Java には JSR 269 に基づく APT(Annotation Processing Tool) が存在し、
Dagger, ButterKnife, Room など多くのライブラリがコード生成に利用していました。
Kotlin の登場と kapt (2016〜)
- Kotlin 1.0(2016年)リリース当初は、既存の Java APT を Kotlin プロジェクトでも動かしたいニーズが強かった
- JetBrains が kapt (Kotlin Annotation Processing Tool) を開発し、Kotlin → Java スタブを生成して APT を利用できるようにした
- これにより Kotlin でも Dagger, Room などのライブラリをそのまま使えた
- ただし スタブ生成のオーバーヘッド によりビルドが遅いという課題があった
ksp の誕生 (2020〜)
- Google が公式に KSP (Kotlin Symbol Processing) を発表
- Kotlin コンパイラのシンボルを直接扱う仕組み → スタブ不要、処理が高速
- Android Jetpack ライブラリ(Room, Hilt, Moshi など)が順次 KSP 対応を開始
- 以降「新規プロジェクトは KSP 推奨、kapt は互換用」という流れに
現在、Google の公式ドキュメントや Android 開発ガイドでも KSP を使うことが推奨 されています。
2. kapt とは?
kapt (Kotlin Annotation Processing Tool) は、
Kotlin で Java の標準アノテーションプロセッサ を利用するための仕組みです。
仕組み
- Kotlin コードを一度 Java のスタブに変換
- Java APT を実行
- 生成コードを Kotlin 側で利用
特徴
- 既存の Java APT 資産を Kotlin でそのまま利用可能
- ただしビルドが遅い
3. KSP とは?
KSP (Kotlin Symbol Processing) は、Google が公式に提供している Kotlin ネイティブのアノテーション処理 API。
kapt の課題を解決するために作られた後継です。
仕組み
- Kotlin の シンボル情報(クラス・関数・プロパティ) を直接処理
- Java スタブ生成が不要 → ビルドが速い
特徴
- ビルド速度は kapt より 2〜3倍高速
- Kotlin Multiplatform (KMP) に対応しやすい
- Jetpack 系ライブラリは順次 KSP に移行済み
4. 比較表
| 項目 | kapt | ksp |
|---|---|---|
| 登場時期 | 2016頃(Kotlin 1.0〜) | 2020頃(Kotlin 1.4〜) |
| 処理方式 | Kotlin → Java スタブ → APT | Kotlin シンボルを直接処理 |
| ビルド速度 | 遅い | 速い |
| 親和性 | Java 向け | Kotlin 向け |
| KMP 対応 | 難しい | しやすい |
| 今後の立ち位置 | 互換用(徐々に廃止) | 主流になる |
5. 実際の導入例
kapt の場合
plugins {
kotlin("kapt")
}
dependencies {
kapt("com.google.dagger:hilt-compiler:2.x")
}
ksp の場合
plugins {
id("com.google.devtools.ksp")
}
dependencies {
ksp("com.google.dagger:hilt-compiler:2.x")
}
Room, Hilt, Moshi, Retrofit などはすでに ksp に対応済み。
新規プロジェクトなら ksp を選ぶのがベストです。
まとめ
-
kaptは Java APT 資産を利用するための互換レイヤー -
kspは Kotlin ネイティブの後継 API(ビルド高速 & KMP 対応) - 今から始めるなら ksp 一択、既存資産が必要なときだけ kapt
参考: