AI Studio がテキストの指示から Kotlin/Compose のアプリを生成し、そのまま USB で実機へ転送できるようになってから、私は手元の Pixel で生成結果を直接動かすことが増えました。ところが、ある日いつもの端末へ転送しようとした瞬間、インストールが赤い一行で止まります。
adb: failed to install app-debug.apk:
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Existing package com.example.wallpaper
signatures do not match newer version; ignoring!]
先に結論をお伝えします。これは AI Studio の不具合でも、生成されたコードの問題でもありません。その端末に Google Play 版の同名アプリがすでに入っていて、Android が「署名が違うものでの上書き」を拒否している——ただそれだけです。原因が分かれば、数分で安全に回避できます。
私は壁紙や癒し系のアプリを Google Play で公開していて、普段使いの端末にはその本番版が入っています。だからこそ、生成したばかりの実験ビルドを同じ端末へ入れようとして、毎回この壁にぶつかっていました。同じ状況の方は少なくないと思うので、私自身の切り分け手順を残しておきます。
エラーの一行をそのまま読む
まず INSTALL_FAILED_UPDATE_INCOMPATIBLE という語と、続く signatures do not match を分けて読みます。前半は「既存パッケージの更新として両立しない」、後半が「署名が一致しない」です。つまり Android のパッケージマネージャは、同じパッケージ名（applicationId）のアプリを更新する際、署名証明書が前回と同一であることを必須にしているわけです。
ここで重要なのは、エラーが出ているのは AI Studio でも adb でもなく、端末側の OS だという点です。adb install -r（再インストール）でも -d（ダウングレード許可）でも結果は変わりません。これらは「同じ署名であること」という前提を緩めるオプションではないからです。署名が違う限り、何度叩いても同じ一行が返ってきます。
似たエラーに INSTALL_FAILED_VERSION_DOWNGRADE がありますが、こちらは versionCode が下がったときのものです。文面が違うので、まずはどちらが出ているかを確認してください。
なぜ署名が一致しないのか
理由は Play App Signing にあります。Google Play 経由で配信されたアプリは、端末上ではあなたのアップロード鍵ではなく、Google が保管するアプリ署名鍵で署名された状態になっています。一方、AI Studio が生成して転送するビルドや、ローカルでそのまま実行したビルドは、既定のデバッグ用キーストア（~/.android/debug.keystore）で署名されています。
この二つは別物です。デバッグ署名のビルドで Play 版を上書きしようとしても、証明書が一致しないため Android は拒否します。これは設定ミスではなく、なりすまし更新を防ぐための仕様です。むしろ、ここで弾かれてくれるおかげで、第三者が同名アプリで利用者のデータを乗っ取ることが防がれています。
整理すると、衝突しているのは「公開済み本番版（Play 署名）」と「生成された実験版（デバッグ署名）」が、同じ applicationId を取り合っている状態です。解き方は二つあります。本番版を一度消すか、実験版の名前をずらすかです。
| 方法 | 本番アプリ | データ | 向いている場面 |
|---|---|---|---|
| 本番版をアンインストール | 消える | 消える | その端末で実験版だけを試したいとき |
| applicationIdSuffix で並走 | 残る | 残る | 本番を使いながら実験版も入れたいとき |
その場ですぐ入れたいときの最短手順
実験版だけを試せればよく、本番アプリのデータが消えても構わないなら、先に本番版を消してから入れます。
# 端末に入っている同名パッケージを確認
adb shell pm list packages | grep wallpaper
# 本番版を削除してから実験版を入れ直す
adb uninstall com.example.wallpaper
adb install app-debug.apk注意点は二つあります。アンインストールでアプリのローカルデータ（設定・購入状態のキャッシュ等）が消えること、そして本番版を消したあとに元へ戻すには改めて Play から入れ直す必要があることです。私は普段使いの端末ではこの方法を避けています。テスト用のサブ端末やエミュレータなら、迷わずこの最短手順で問題ありません。
本番を消さずに並べて試すなら applicationIdSuffix
普段の端末で本番アプリを使い続けながら、生成した実験版も入れたい——これが個人開発では一番多い要望だと思います。その場合は、デバッグビルドの applicationId をずらして、別アプリとして並走させます。Gradle（Kotlin DSL）ではこう書きます。
// app/build.gradle.kts
android {
defaultConfig {
applicationId = "com.example.wallpaper"
}
buildTypes {
debug {
// デバッグ版だけ別パッケージにする
applicationIdSuffix = ".debug"
versionNameSuffix = "-debug"
resValue("string", "app_name", "Wallpaper (Debug)")
}
release {
isMinifyEnabled = true
}
}
}こうするとデバッグ版は com.example.wallpaper.debug という別の applicationId になり、Play 版（com.example.wallpaper）とは衝突しません。ホーム画面にアイコンが二つ並び、署名も別物として扱われるため、先ほどの一行は出なくなります。resValue で表示名に「(Debug)」を足しておくと、本番とどちらを触っているか一目で分かります。
AI Studio が生成した Gradle をそのまま使う場合は、転送前にこの applicationIdSuffix が入っているかを確認してください。エージェントが生成する初期設定は素直な単一 applicationId のことが多く、ここを足すだけで実機転送の事故がほぼ消えます。私はこの一手間を、生成物を端末へ送る前の定番チェックにしています。
同じ事故を繰り返さないために
予防の要点は、本番署名のアプリと実験署名のアプリを同じ applicationId で同じ端末に同居させないことに尽きます。具体的には次の三つを習慣にしています。
一つ目は、デバッグビルドに常に applicationIdSuffix を入れておくこと。テンプレートの時点で仕込んでおけば、生成物にも自然と引き継がれます。二つ目は、自分の公開アプリを入れていない検証専用の端末かエミュレータを一台用意しておくこと。署名の衝突がそもそも起きません。三つ目は、エージェントに Gradle を触らせたあとは signingConfigs と buildTypes の差分を必ず目視すること。生成のたびに署名設定が書き換わっていないかを、私は差分で確認するようにしています。
公式の挙動を確認したいときは、Android Developers のアプリのデジタル署名とPlay アプリ署名が一次情報として確実です。
生成から実機検証までの距離が縮んだぶん、署名まわりのつまずきは以前より身近になりました。原因さえ腹落ちすれば怖がる必要はありません。同じところで止まっている方の手が、少しでも早く動き出せば嬉しいです。