導入：AGP更新は「コード修正」じゃなくて「整合性調整」
AGP（Android Gradle Plugin）を更新すると、だいたいこうなります。
- 昨日までビルドできてたのに突然エラー
- 依存関係が解決できない
- Kotlinのターゲットが合わない
- JDKが違うと言われる
これ、AGPが悪いというより、周辺の噛み合わせが崩れただけのことがほとんどです。
AGP更新は「IDEアップデート」や「SDK上げ」とセットで起こることも多く、原因が散らばります。
この記事では、AGP更新で壊れがちなポイントを依存関係・JDK・Kotlinの整合性に絞って、切り分けの順番を整理します。
先に結論（3行）です。
- AGP更新は「Gradle」「JDK」「Kotlin」をセットで見ないと詰む
- まずツールチェーン（JDK/Gradle/AGP）を固定し、次に依存を直す
- エラーは1個ずつ潰す。まとめて上げると地獄
まず押さえる：AGP更新で壊れる“典型パターン”
壊れ方はだいたいパターン化しています。
パターン1：GradleとAGPの組み合わせが合ってない
AGPはGradle本体のバージョンに強く依存します。
AGPだけ上げてGradle Wrapperを放置すると、普通にビルドが死にます。
パターン2：JDKが合ってない（特にCIとローカル差）
ローカルはJDK 17、CIはJDK 11、みたいなズレがあると、AGP更新で突然顕在化します。
「自分のPCだけ通る」「CIだけ落ちる」はこのパターンが多いです。
パターン3：KotlinとAGP/Compose/プラグインの噛み合わせが崩れる
Kotlinのバージョンは、AGPだけでなく Compose Compiler や各プラグインとも絡みます。
ここがズレると、ビルドは通ってもタスク実行時に落ちたりします。
パターン4：依存関係が解決できない（Repository/バージョン競合）
Mavenの解決戦略が変わったり、古い依存が新しい環境に対応していなかったりで詰みます。
特にマルチモジュールは連鎖します。
切り分けの鉄則：上から順に固定する
AGP更新で詰まった時、やるべき順番があります。
- 1) JDK（Java toolchain / Gradle JVM）
- 2) Gradle Wrapper（gradle-wrapper.properties）
- 3) AGP（com.android.tools.build:gradle）
- 4) Kotlin（kotlin-gradle-plugin）
- 5) 依存関係（AndroidX/各SDK/Compose等）
いきなり「依存のエラー」から直すと、根っこがJDKだったりして無限ループになります。
まず土台を固定。これが最優先です。
JDK整合性：まずここを揃える
最近のAGP更新で一番多い地雷が、JDK周りです。
チェック1：Gradleが使っているJDKは何？
Android Studioの設定でGradle JVMがどれを指しているか確認します。
ローカルで複数JDKが入っている場合、ここがズレます。
チェック2：CIのJDKと一致している？
CIだけ落ちるなら、まずJDKが違うと思っていいです。
CI側のJavaバージョンを固定し、ローカルと揃えます。
チェック3：Kotlin JVM target と Java target がズレてない？
AGP更新で「compileOptionsは17なのに、kotlinOptionsは1.8」みたいなズレが顕在化します。
このズレは、地味に起動時クラッシュやClassNotFoundの原因になります。
Gradle Wrapper：AGP更新とセットで上げる
AGP更新は、基本的にGradle Wrapperの更新とセットです。
この時にやりがちなのが、
- ローカルのGradleだけ更新してWrapperを更新しない
- Wrapper更新したけど、CIが古いGradleを使っている
Wrapperは「プロジェクトのビルド環境の固定」です。
AGP更新の時は、まずWrapperを揃えてから進めます。
Kotlin整合性：プラグイン・Compose・KSP/KAPTが絡む
Kotlinは「1個上げればOK」ではありません。
AGP更新と一緒に上げると、次のどれかが爆発しがちです。
- Kotlin Gradle Plugin
- KSP / KAPT
- Compose Compiler
- 各種プラグイン（Firebase, Hilt, Navigationなど）
典型エラー：Kotlinコンパイラ周り
症状としては、compileKotlinタスクで落ちたり、Composeのコンパイルで落ちたりします。
「Kotlinのバージョンに対して、このプラグインが未対応」みたいな状態です。
対策：Kotlinとプラグインをまとめて管理する
versions.toml や buildSrc でバージョン管理を一本化し、ズレを作らないのが最終的に一番楽です。
マルチモジュールでは特に。
依存関係：AGP更新で露呈する“古い依存”
AGP更新は、依存関係の古さを炙り出します。
よくある壊れ方
- 古いsupport系や古いAndroidXが混ざっている
- 依存のバージョン競合（同じgroupの別バージョン）
- 古いSDKが新しいcompileSdk/targetSdkに未対応
まずやる：依存ツリーの可視化
何が競合しているかは、依存ツリーを出すと一発で見えることがあります。
./gradlew :app:dependenciesマルチモジュールなら、落ちているモジュール単位で出すのがコツです。
次にやる：バージョン固定（依存の揺れを止める）
依存が揺れていると、マシンや時間で結果が変わります。
まずはBOM（Firebase/Composeなど）を使う、あるいはバージョンを固定して再現性を上げます。
落ちやすいポイント集（実務で遭遇しがち）
1) Kotlin/JDK target mismatch
Java 17でコンパイルしてるのに、Kotlinが1.8ターゲットのまま、など。
このズレはコンパイルエラーだけでなく、実行時の不整合も呼びます。
2) KAPT/KSPのバージョン不一致
AGP更新でGradleタスクが変わると、KAPTタスクやKSPタスクが爆発します。
「Kotlinは上げたがKSPが追従してない」がありがちです。
3) R8/Proguardの挙動差（debugは通るがreleaseで落ちる）
AGP更新でR8の挙動が変わり、releaseでだけClassNotFoundが出ることがあります。
この場合は keep ルールの不足を疑います。
4) リポジトリ/ミラーの差（CIだけ依存が取れない）
社内ミラーやネットワーク制限が絡むと、依存取得でコケます。
リポジトリ順や認証設定の差が原因になりやすいです。
安全な更新手順（実務のおすすめ）
AGP更新で事故らないための手順をまとめます。
- Step 1：JDKを固定（ローカル/CI）
- Step 2：Gradle Wrapperを更新
- Step 3：AGPを更新（まずは1段階）
- Step 4：Kotlinを更新（対応する範囲で）
- Step 5：依存の競合を解決
- Step 6：releaseビルドも必ず通す
「全部一気に上げる」は、原因が追えなくなるので避けたいです。
デバッグ/確認チェックリスト
- Gradleが使っているJDKがローカル/CIで一致している
- Gradle Wrapperのバージョンを更新した
- AGPとGradleの組み合わせが破綻していない
- Kotlin/JDK targetが揃っている
- KSP/KAPT/Composeなど周辺プラグインの整合性が取れている
- 依存ツリーを出して競合を潰した
- debugだけでなくreleaseでもビルド/起動確認した
よくある質問（Q&A）
Q. AGPだけ上げたい。Kotlinは据え置きでいい？
可能な場合もありますが、周辺プラグインがKotlinに依存しているため、結果的にKotlinも上げざるを得ないことが多いです。
「据え置きで通るならOK」ですが、通らないならKotlin側の整合性を見た方が早いです。
Q. CIだけ落ちる時、何から見る？
まずJDKです。次にGradle Wrapperが同じか。
依存取得のネットワーク条件も含めて、ローカルと差分が出やすいのはここです。
Q. debugは通るのにreleaseで落ちる
R8/Proguardの影響が濃厚です。keepルール不足や、リフレクションを使うSDKの設定を疑います。
AGP更新で“たまたま通ってた”ものが壊れることがあります。
まとめ：AGP更新は「噛み合わせ」を直す作業
- AGP更新で壊れる原因は整合性の崩れが大半
- JDK → Gradle → AGP → Kotlin → 依存の順で固定する
- 一気に上げず、1つずつ潰して再現性を保つ
迷ったら：JDKとWrapperを先に揃える。
ここが揃うだけで、地獄の8割は回避できます。
コメント