【Android開発記 #1】環境構築におけるAGP 9.0の罠。「バイブコーディング」でも公式ドキュメントは必須

最近はAIの進化で、初心者でも「なんとなく」動くコードが書けるようになりました。一方で、AIが出したコードが何回たっても何回直してもらってもエラーが出る
そんな状態に苦しんだことも多いのでは？

AIが生成してくれるとはいえ、公式ドキュメントまで辿り着き内容を読む力は必須です！

今回、新作アプリ「記事構成メーカー」の立ち上げではじめてAndroidStudoを使って環境構築してみたのでその作業記録と、その中で感じた工夫すべき点だと感じたところを残したいと思います！

スペックが足りない時は大人しくペアリングでの実機デバッグへの即時移行を。

開発のスタートライン。意気揚々とAndroid Studioを立ち上げたものの、そもそも自分が使っているのはIntel Core i3（1.1GHz デュアルコア）搭載の旧型Mac……。

ガチ化石です。笑

案の定、エミュレータを起動しようものなら恐ろしいほどの時間がかかりました笑

まぁそんな時は大人しく自分のスマホを繋いで、「実機デバッグ」への即時移行をしてしまいましょう！

私はアンドロイド端末(Pixel)を使用しているのでAndroidで開発者むけオプションを有効にする方法など載せておきますね。

<参考サイト>

開発者向けオプションを有効にする簡単2STEP

STEP1
[設定] > [端末情報] > [ビルド番号] に進み設定場所へ移動する

STEP2
[ビルド番号] オプションを 7 回タップすると、「You are now a developer!」というメッセージが表示されます。

前の画面に戻ると、下部に [開発者向けオプション] が表示されます。

Wi-Fi経由でのペアリングをONにすると、実機と接続できます！

「バイブコーディング」の代償：古い情報ソースが使われることによるハルシネーション

古いバージョンの記載を引きずりCannot add extension with name "kotlin"エラー

今回も基本的な環境構築はAIに投げて0→1のハードルを下げようと目論みましたが、結構致命的なエラーがしばらく出ていました。それがこちら

Cannot add extension with name "kotlin", as there is an extension already registered with that name.

「Kotlinの設定を足そうとしたけど、もう二重に登録されてるよ！」という重複エラーです。

何が起きていたのかというと、実は **Android Gradle プラグイン 9.0（AGP 9.0）からデフォルトで有効になった「組み込みの Kotlin（Built-in Kotlin）」という超メジャーな仕様変更が犯人でした。

<参考資料>

これまでの古いネット記事やAIの知識では、ビルドファイル（build.gradle.kts）に手動で `org.jetbrains.kotlin.android`（または `kotlin-android`）プラグインを明示的に記述するのが常識でした。

しかし、AGP 9.0以降の最新環境では、ビルドシステム自身がKotlinのサポートを最初から標準搭載しているため、この手動のプラグイン記述自体が「書いてはいけない古い慣習」に変わっていたのです！
AIだとこういうバージョンアップを掬い上げるのは難しいようです。

ということで知らずに追加した結果、システム内でプラグインが2回適用され、重複エラーでビルドが即死してしまっていました。

＜解決策＞
シンプルに、プロジェクトのモジュールレベルやルートレベルのビルドファイルから、不要になった `kotlin-android` プラグインの記述を完全に削除しました。

さらに、この「組み込みKotlin仕様」に移行したことで、もう一つの連鎖エラーが発生します。

KSPの処理と組み込みKotlinの競合エラー

そして引き続きビルドしようとすると以下エラー。

Using kotlin.sourceSets DSL to add Kotlin sources is not allowed with built-in Kotlin 

新しい組み込みKotlinが有効な状態では、古いディレクトリ登録処理（`kotlin.sourceSets`）を使用したソース追加が禁止されるという仕様変更によるものです。

なんと、データベース（Room）の自動コード生成を行うためのツール「KSP」が、裏側でこの古い仕組み（`kotlin.sourceSets`）を使ってファイルを登録しようとして、エラーに弾かれてしまっていたのです。

＜解決策＞
これはKSP側の対応を待つ必要があるため、暫定の回避策として、`gradle.properties` ファイルに以下の特別許可（エラーの検証を抑制する設定）を1行追加することで見事に突破できました。

android.disallowKotlinSourceSets=false 

※テックリードとして付け加えるなら、これはあくまで「暫定」です！
本来はAGPとKSPのバージョンを最新の互換マップに合わせるべきです…
開発を前に進めるためには、時にはこうした「泥臭いハック」でエラーをねじ伏せる胆力も必要になるなと温かい目で読んでください！笑

AIに頼り切らず公式ドキュメントを「盾」とする

バイブコーディングをするときに、AI頼りでエラーを力技でねじ伏せるのが適切じゃないことを改めて感じた今回の環境構築でした。

バージョンがたくさんあるようなプラグインを使うとAIって簡単に間違えた情報を吐き出すんですよね！

そこで重要なのはAIを「答えを出す機械」ではなく「一次情報を読み解くための解析パートナー」として使うことだと思っています。

とはいえどうすれば？と思う方は例えば以下のような手順で使ってみてはどうでしょうか？

1. Googleの公式ドキュメント「組み込みの Kotlin に移行する」や、AGPのリリースページを特定する。

2. その最新仕様（AGP 9.3以降の変更点）をAIに「インプット（知識）」として徹底的に読み込ませる。

3. 「今の私の環境はAGP 9.3.1です。このドキュメントの仕様に基づいて、libs.versions.toml の矛盾を修正してください」と、自分の「見立て（仮説）」をぶつける。

AIにハンドルを握らせるのではなく、自分が公式ドキュメントという地図を持ち、AIをナビゲーターとして使う。
この思考プロセスができるのとできないのとでは１つの開発にかかる時間に天と地の差が出るような気がします。

エラーなくHello Android!に辿り着いた構成

格闘の末に辿り着いた構成をまとめておきます。

libs.versions.toml（安定のバージョン管理）

[versions]
agp = "9.3.1"
coreKtx = "1.10.1"
junit = "4.13.2"
junitVersion = "1.3.0"
espressoCore = "3.7.0"
lifecycleRuntimeKtx = "2.11.0"
activityCompose = "1.13.0"
kotlin = "2.2.10"
composeBom = "2026.02.01"

[plugins]
android-application = { id = "com.android.application", version.ref = "agp"}
kotlin-compose = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

build.gradle.kts (Module: app)

plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.compose)
    id("com.google.devtools.ksp") version "2.2.10-2.0.2"
}

まとめ：AI時代だからこそ「一次情報 ＋ AI」のハイブリッドで「賢い」開発を

初めて触るソフトや言語・ライブラリを触るときに取るべきスタンスは、「一次情報 ＋ AI」のハイブリッドだと感じています。

AIは強力な加速装置だが、ハンドルを握るのは常に自分自身であること。それは忘れてはいけないなと改めて思った環境構築でした。

引き続きこのアプリについては開発して開発記を書いていこうと思います！

Xでも日々情報発信しているのでぜひフォローしてください！