▣ アプリ開発/2026-06-27上級

AI Studio が選んだ Gradle と AGP のバージョンが、既存アプリのビルドを静かに壊す前に

AI Studio が生成した Kotlin/Compose 画面を既存の Android アプリへ取り込むと、AGP・Kotlin・依存ライブラリのバージョンがずれてビルドが静かに壊れます。version catalog で単一の真実を固定し、取り込み口で生成側の宣言を検査するゲートの設計を、実測とコードでまとめました。

antigravity³⁹⁴ ai-studio³ android²⁴ gradle² jetpack-compose³

✦ プレミアム記事

生成された画面はエミュレータで完璧に動いていました。問題は、その画面のフォルダを自分の壁紙アプリのモジュールへコピーした瞬間に起きました。./gradlew assembleRelease は通るのに、デバッグビルドだけが Unsupported class file major version で落ちる。原因にたどり着くまで半日かかりましたが、犯人は私のコードでも生成されたコードでもなく、AI Studio が同梱してきた build.gradle.kts の中で宣言された AGP と Kotlin のバージョンでした。

AI Studio が Kotlin と Jetpack Compose のアプリをテキストから生成し、エミュレータ実行から実機転送、Google Play 内部テストまで一画面でつなげられるようになって、個人開発の試作と配布の距離はずいぶん縮みました。けれど生成物は「新規アプリ」として整っているだけで、既に動いている自分のアプリに混ぜる前提では作られていません。ここに静かな落とし穴があります。

ここでは、生成された Compose を既存アプリへ取り込むときに発生するバージョンずれを、version catalog を単一の真実として固定し、取り込み口で生成側の宣言を機械的に検査するゲートで防ぐ設計をまとめます。私が個人開発で運用している Android 壁紙アプリの実運用で踏んだ失敗と、それを止めた具体的な構成を中心にまとめます。

なぜ「動いた生成コード」が既存アプリで壊れるのか

AI Studio の生成物は、その時点で最新の安定版に寄せた依存を宣言します。一方、長く運用しているアプリは、互換性を確かめながら少しずつ上げてきた固有のバージョン構成を持っています。この二つを単純にマージすると、Gradle は依存解決の途中でより新しい方へ寄せるため、あなたが意図的に止めていたバージョンが、取り込みと同時に黙って引き上げられます。

実際に私が遭遇した壊れ方を、影響範囲とともに整理します。

ずれた要素	生成側が宣言しがちな値	既存アプリで起きたこと
AGP（Android Gradle Plugin）	最新メジャー（例: 9.x 系）	Java 8 API を使う旧ライブラリで `NoClassDefFoundError`。desugaring の有効化が前提に
Kotlin / Compose コンパイラ	最新安定	Compose コンパイラと Kotlin の対応表からずれ、`Compose Compiler requires Kotlin version` で停止
core ライブラリ（画像・DI 等）	最新	API シグネチャ変更で既存画面側がコンパイルエラー
minSdk / targetSdk	生成時点の推奨	minSdk が上がり、サポート対象だった旧端末が配信対象から外れる

このうち AGP の引き上げは特に厄介でした。私のアプリでは画像表示ライブラリが内部で Java 8 の Supplier を参照していて、AGP のメジャー更新後に Android 6.0.1 帯の端末で起動直後にクラッシュするようになったのです。解決自体は一行で、coreLibraryDesugaringEnabled を有効化して desugaring ライブラリを足すだけでしたが、「生成コードを混ぜたらクラッシュ率が上がった」という因果が見えにくいのが本当の問題でした。この desugaring 周りの詳しい挙動は古い端末で起きる Java 8 由来のクラッシュを desugaring で止めた記録に切り分けの手順を書いています。

ここで効くのが「単一の真実（single source of truth）」という考え方です。バージョンを各モジュールの build.gradle.kts に散らさず、gradle/libs.versions.toml の version catalog 一箇所に集約しておけば、生成物が独自に宣言したバージョンは取り込みの時点で必ず catalog と突き合わせられるようになります。

version catalog を単一の真実として固定する

まず、プロジェクト全体のバージョンを version catalog に寄せます。生成物が個別に書いてくる implementation("androidx.compose...:1.x.x") のような直書きを排除し、すべて catalog 参照に統一するのが出発点です。

# gradle/libs.versions.toml — プロジェクトで唯一バージョンを宣言する場所
[versions]
agp = "9.0.1"                # ここで止める。生成物が 9.1.x を宣言しても上げない
kotlin = "2.2.20"
composeCompiler = "2.2.20"   # kotlin と一致させる（Kotlin 2.x は composeOptions 不要だが明示管理）
composeBom = "2026.05.01"
coreDesugar = "2.1.5"        # AGP メジャー更新後の Java 8 由来クラッシュ対策
minSdk = "23"                # Android 6.0。生成物が上げてきても維持する
targetSdk = "36"
 
[libraries]
compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "composeBom" }
compose-ui = { group = "androidx.compose.ui", name = "ui" }
compose-material3 = { group = "androidx.compose.material3", name = "material3" }
desugar-jdk-libs = { group = "com.android.tools", name = "desugar_jdk_libs", version.ref = "coreDesugar" }
 
[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
kotlin-compose = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

次に、モジュール側ではバージョンを一切書かず、catalog の別名だけを参照します。Compose は BOM 経由で版を揃えるので、個々のライブラリにバージョンを付けないのが要点です。

// app/build.gradle.kts — バージョンは書かない。catalog の別名だけを使う
plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
    alias(libs.plugins.kotlin.compose)
}
 
android {
    compileSdk = libs.versions.targetSdk.get().toInt()
    defaultConfig {
        minSdk = libs.versions.minSdk.get().toInt()
        targetSdk = libs.versions.targetSdk.get().toInt()
    }
    compileOptions {
        // AGP メジャー更新で古い端末が落ちないよう desugaring を常時有効化
        isCoreLibraryDesugaringEnabled = true
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }
}
 
dependencies {
    val composeBom = platform(libs.compose.bom)
    implementation(composeBom)
    implementation(libs.compose.ui)
    implementation(libs.compose.material3)
    coreLibraryDesugaring(libs.desugar.jdk.libs)  // 上の TOML と対で必ず入れる
}

これで「どのモジュールから見てもバージョンは catalog の一箇所」という状態になります。生成物をこのプロジェクトに混ぜるとき、生成側が直書きしたバージョンはそのままでは catalog 経由にならないので、取り込み口でそれを検出できます。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦AI Studio が生成した Compose 画面を、自分の既存アプリへ取り込むときにビルドが壊れていた人が、依存の衝突を事前に止める固定方法を今日から実装できる

✦AGP・Kotlin・Compose コンパイラ・主要ライブラリのバージョンを version catalog で単一の真実として束ね、生成コードの宣言を取り込み口で検査するゲートを構築できる

✦段階公開中の本番アプリに生成画面を混ぜても、Android 6.0 帯のクラッシュや密度バケットの欠落を再発させずに配信フローへ載せられるようになる

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

取り込み口で生成側の宣言を検査するゲート

設定を固定しただけでは、生成コードをコピーした人がうっかり直書きの依存を残すと、また同じ事故が起きます。そこで、取り込みを「手でコピーする作業」ではなく「検査を通過した差分だけが入る作業」に変えます。私は staging フォルダに生成物を置き、そこに対して検査スクリプトを走らせてから本体へ移すという二段構えにしています。

#!/usr/bin/env bash
# import_gate.sh — AI Studio 生成物を本体へ取り込む前の検査ゲート
# 使い方: ./import_gate.sh path/to/generated_module
set -euo pipefail
 
SRC="$1"
VIOLATIONS=0
 
# (1) build.gradle に直書きされたバージョン付き依存を検出
#     例: implementation("androidx.foo:bar:1.2.3") のような :バージョン 付き宣言
if grep -REn 'implementation\("[^"]+:[^"]+:[0-9]' "$SRC" 2>/dev/null; then
  echo "❌ バージョン直書きの依存が見つかりました。libs.versions.toml の別名参照に置き換えてください"
  VIOLATIONS=$((VIOLATIONS+1))
fi
 
# (2) 生成物が独自に AGP / Kotlin / minSdk を宣言していないか
for KEY in 'com.android.application' 'org.jetbrains.kotlin' 'minSdk' 'compileSdk'; do
  if grep -REn "$KEY[^a-zA-Z].*[0-9]+\.[0-9]" "$SRC" 2>/dev/null | grep -v 'libs\.'; then
    echo "❌ 生成物が $KEY を直接宣言しています（catalog の単一の真実に反します）"
    VIOLATIONS=$((VIOLATIONS+1))
  fi
done
 
# (3) desugaring 前提の API を使っていないか（java.time など）。使うなら本体側で desugar 有効が必須
if grep -REn 'import java\.time\.' "$SRC" 2>/dev/null; then
  echo "⚠️ java.time を使用。minSdk 23 では desugaring 必須（本体は有効化済みか確認）"
fi
 
if [ "$VIOLATIONS" -gt 0 ]; then
  echo "🛑 ${VIOLATIONS} 件の違反。生成物を修正してから再実行してください。"
  exit 1
fi
echo "✅ 取り込みゲート通過。本体へマージできます。"

このスクリプトは CI でも回せますし、エージェントに「取り込みは必ず import_gate.sh を通してから」と手順として渡せます。Antigravity のフックでプッシュ前に同種の検査を挟む発想は配信の番号付けを単一の真実から決める設計とも地続きで、生成物の取り込みもその延長線上に置けます。

Gradle 側の最終防衛線 — 意図しない引き上げを失敗させる

スクリプトの検査をすり抜けても、Gradle の解決段階で「上がってはいけないバージョンが上がった」ことをビルド失敗として検出する保険を張れます。resolutionStrategy でクリティカルな依存を固定し、ずれたら落とします。

// settings.gradle.kts などで全モジュールに適用
configurations.all {
    resolutionStrategy {
        // 取り込みでこっそり上がると困る依存を明示的にロックする
        force("com.android.tools:desugar_jdk_libs:2.1.5")
        // 解決の途中でバージョンが動的に変わったら失敗させる
        failOnVersionConflict()
    }
}

failOnVersionConflict() を入れておくと、生成物が引き連れてきた推移的依存が既存のものと食い違った瞬間にビルドが止まります。最初はうるさく感じますが、「リリースしてからクラッシュで気づく」より「マージ直後にビルドで気づく」方が桁違いに安いというのが、段階公開を何度も回してきた実感です。

三層で守ると決めておく

ここまでの仕組みは、役割の違う三つの層で重ねると安定します。

catalog 層: バージョンの宣言を gradle/libs.versions.toml の一箇所に集約し、モジュールは別名参照だけにする
検査層: import_gate.sh で、生成物が直書きした依存や独自の AGP/minSdk 宣言を取り込み前に弾く
解決層: failOnVersionConflict() で、すり抜けた推移的依存のずれをビルド失敗として止める

段階公開の指標で言えば、私はこの三層を入れる前後で Crash-free users を 99.7% 以上・ANR を 0.20% 未満に保てるかどうかを判断材料にしています。生成画面を混ぜた回の配信で、この二つの数値が崩れなければ、取り込みは安全だったと見なしています。

取り込み後に必ず確認する3点

ゲートを通してマージできても、生成物特有の見落としが本番で表面化することがあります。私が毎回確認しているのは次の3点です。

確認項目	なぜ生成物で起きやすいか	確認方法
密度バケットの欠落	生成物は単一密度の画像しか持たないことがあり、Play の密度分割で低密度端末に配信されない	低密度の `drawable-nodpi/` 配置を確認し、APK Analyzer で密度別を点検
旧端末のクラッシュ	AGP 引き上げ＋Java 8 API で Android 6.0 帯が起動直後に落ちる	minSdk 端末の実機/エミュレータで cold start を実測
実機とエミュレータの差	生成画面はエミュレータで検証されただけで、実機固有のフォント・解像度差が未検証	実機差を塞ぐ検証ゲートを別途用意する

3点目の実機差については、生成された Compose を本番に載せる前の検証としてエミュレータでは緑なのに実機で崩れる差を塞ぐ検証ゲートに切り分けの観点をまとめてあります。生成の速さに引っ張られて、この実機確認を飛ばすと、配信後のクラッシュとして返ってきます。

どこまで生成に任せ、どこを自分で握るか

長く個人開発を続けていると、新しい生成ツールが出るたびに「どこまで任せるか」を考え直すことになります。AI Studio の Kotlin/Compose 生成は、画面の試作や配信導線の確認には素直に強い。けれどビルドの足回り——バージョンの単一の真実だけは、生成側に明け渡さないというのが、いま私が置いている線引きです。生成物はあくまで「新しい画面の提案」として受け取り、それを既存の構成へ着地させる責任は人間側に残す。version catalog と取り込みゲートは、その線引きを仕組みとして固定するための道具です。

まず手を動かすなら、いま運用しているアプリのバージョン宣言を一度 gradle/libs.versions.toml に集約し、failOnVersionConflict() を一行足すところから始めてみてください。生成物を取り込む前に、自分の足場が単一の真実になっているかどうか——そこが最初の分かれ目になります。