🌟

Geminiを利用したAndroidプロジェクトの時短依存関係整理

に公開
Android
Gemini
tech

マルチモジュールな Android プロジェクトで Deps.kt から Version Catalogの移行を担当しました。Deps.kt と libs.versions.toml の併用は、バージョンや定義の二重管理につながりやすく、チーム開発での手間も増えていきます。

この課題を解消するために、今回は Gemini などの AI を使い時短をしながら、Version Catalog への全面移行を自動化したプロセスを紹介します。

Step 1: Deps.kt から [versions] を抽出する

まずは既存の Deps.kt から、バージョン定義（object Versions）を抽出して libs.versions.toml の [versions] セクションへ変換します。

Deps.kt の例

object Versions {
    const val kotlin = "1.9.23"
    const val composeCompiler = "1.5.11"
    const val compose = "1.6.7"
    const val activityCompose = "1.9.0"
    const val lifecycle = "2.8.0"
}

object Deps {
    const val activityCompose = "androidx.activity:activity-compose:${Versions.activityCompose}"
    const val lifecycleViewModel = "androidx.lifecycle:lifecycle-viewmodel-ktx:${Versions.lifecycle}"
}

変換後の libs.versions.toml 

[versions]
kotlin = "1.9.23"
composeCompiler = "1.5.11"
compose = "1.6.7"
activityCompose = "1.9.0"
lifecycle = "2.8.0"

[libraries]
activity-compose = { module = "androidx.activity:activity-compose", version.ref = "activityCompose" }
lifecycle-viewmodel = { module = "androidx.lifecycle:lifecycle-viewmodel-ktx", version.ref = "lifecycle" }

Step 2: build.gradle.kts の一括変換スクリプトを AI に書かせる

Deps 形式から Version Catalog（libs.xxx.yyy）形式へ移行するために、すべての build.gradle.kts を対象に一括で依存関係の書き換えを行うスクリプトを AI に生成してもらいました。

当初は Kotlin スクリプトを想定していましたが、最終的には bash スクリプトとして以下のような形に落ち着きました。

実際に使ったスクリプト（抜粋）

replace_dependency "Deps.lifecycleViewModelx" "libs.androidx.lifecycle.viewmodel.ktx"

FILES=(
    "./app/build.gradle.kts"
    "./feature-mypage/build.gradle.kts"
    # ...（マルチモジュール全体）
)

replace_dependency() {
    local old_dep="$1"
    local new_dep="$2"
    local escaped_old_dep=$(echo "$old_dep" | sed 's/\./\\./g')

    for file in "${FILES[@]}"; do
        if [ -f "$file" ]; then
            sed -i.bak "s/$escaped_old_dep/$new_dep/g" "$file" && rm "${file}.bak"
        fi
    done
}

このようにして、定義済みの置換ルールを AI に生成させ、置換対象ファイルの一覧もプロンプトで明示することで、ブレのない変換が可能になりました。

テスト検証方法

変換後の検証としては、Android Studio の Dependencies ビューでビルド構成前後のライブラリ一覧を出力し、
diff コマンドで突き合わせることで差分を確認しました。
この方法により、変換によって依存関係が過不足なく移行できているかを視覚的に把握することができ、作業の信頼性を担保できます。

AIとのやりとりで気づいたこと

命名規則のブレ

AI に「lifecycle-viewmodel にして」と伝えても、しばしば lifecycleViewmodel のようにキャメルケースで返されてしまうことがあります。

# ❌ AIが返した例
lifecycleViewmodel = { module = "androidx.lifecycle:lifecycle-viewmodel-ktx", version.ref = "lifecycle" }

# ✅ 期待される形式
lifecycle-viewmodel = { module = "androidx.lifecycle:lifecycle-viewmodel-ktx", version.ref = "lifecycle" }

このような細かなブレは、手作業で修正するか、プロンプトを明示的に工夫して対応する必要がありました。

文脈がリセットされにくい問題

一度キャメルケースで命名された文脈が維持されると、ケバブケースへの切り替え指示が通りにくくなるケースもありました。

「前の命名は忘れて」「リセットして」と伝えてもすぐには切り替わらないため、最初からルールを明確に伝えるか、セッションを変えることが有効と感じました。

まとめ

AIにすべてを任せるのは、現時点ではまだ難しいと感じることは多いため、最初から最後まで完璧にやってもらうのではなく、作業を細かく分解しながら、変換や置換ツールなどを一緒に作ってもらうような使い方が、今のところちょうど良い距離感なのかもしれません。

今回の移行タスクでは、「変換の実行」ではなく、「作業を自動化する仕組み」 をAIに作ってもらうことで、効率と安定性の両立が図れました。

命名規則や文法の癖を把握して使えば、AIは非常に心強い味方になります。
Version Catalogへの移行や類似の整備作業では、AIをうまく活用することで、時短をしながら技術的負債の解消を強力に後押ししてくれるはずです。

Discussion