AndroidのversionCodeとversionNameの違いは？Google Play更新時の決め方・重複エラーまで解説

初回掲載日:2026年10月4日
最終更新日:

AndroidアプリのversionCodeとversionName、Google Play更新の関係を示すオリジナル図解

結論：versionCodeはGoogle PlayやAndroidが新旧を判定するための内部番号、versionNameはユーザーに見せる表示名です。

通常の更新では、versionCodeを前回より大きくする
versionNameは「1.1」「2.0.0」など、ユーザー向けの文字列として管理する
versionCodeは必ず+1である必要はないが、通常の連続リリースでは大きい値を使う
一度Play Consoleへアップロードした番号は、再提出で再利用できると決めつけず、新しい番号を用意する

この記事ではAndroid DevelopersとGoogle Play Consoleの公式説明を基準に、個人開発で迷いやすい採番・再提出・ロールバックを整理します。

versionCodeとversionNameの違い

Androidアプリのバージョン情報は、見た目が似ていても役割が異なります。versionCode = 12、versionName = "2.3"のように、数字をそろえる必要はありません。

項目	versionCode	versionName
用途	新旧リリースの判定	ユーザー向けの表示
型	正の整数	文字列
ユーザーに見えるか	通常は見せない	Google Playやアプリ内で表示可能
更新時	通常は前回より大きくする	内容に合わせて表示名を更新
値の例	`1`、`12`、`120`	`1.0`、`1.1.1`、`2026.10`
Playでの役割	アップデート可否・新旧判定	リリースを識別する表示情報

Android Developersは、versionCodeを「高いほど新しい」と判定する内部番号、versionNameをユーザーに表示する文字列として説明しています。Play Consoleでは、使用済みのversionCodeを再度アップロードできません。Android Developers「Version your app」、Google Play Console Help「Version codes」

versionCodeは内部判定、versionNameはユーザー表示であることを示すオリジナル図解 — versionCodeとversionNameは、同じ数字にする必要がありません。

Google Play更新時は、次に何番にする？

迷ったときは、まずそのAABがPlay Consoleへアップロードされたかを確認します。未アップロードのローカルビルドと、すでにPlay側へ渡したビルドでは扱いが異なるためです。

状況	versionCode	versionName	判断
初回公開	`1`など正の整数	`1.0`など	今後増やせる余地を残す
通常アップデート	前回より大きい値	変更内容に応じて変更	+1でも、別の大きい値でもよい
AAB未アップロードで修正	同じ値で再生成可能	必要なら変更	Play Consoleの使用済み判定はまだ発生していない
Play Consoleへアップロード後に修正	新しい大きい値を用意	修正内容に合わせる	使用済み番号の再利用を避ける
審査reject後	Consoleの状態を確認し、既使用なら新しい値	必要なら変更	同じ番号を使えると推測しない
過去版相当へ戻したい	古いソースでも新しい値	表示名は任意に整理	「古いコード＋新しいversionCode」で考える

+1はGoogle Playの必須ルールではありません。公式は、後続リリースでより大きい値を使うことを求めています。10から20へ飛ばす設計もできますが、将来の上限を早く消費する採番は避けてください。

初回公開、通常更新、アップロード済みAAB、ロールバック時のversionCode判断フローを示すオリジナル図解 — 採番は「公開状況」と「Play Consoleへ渡したか」を基準に判断します。

「version code already used」エラーの対処

Version code xxx has already been usedと表示されたら、同じAABを繰り返し送るのではなく、まず生成物とPlay Consoleの履歴を確認します。

症状	確認する場所	対処
version code already used	Gradle設定、Play ConsoleのApp bundle explorer	未使用の、より大きいversionCodeでAABを再生成
番号を変えたのに同じエラー	生成したAABの実値、product flavor、build type	想定したvariantをビルドしているか確認
versionCodeが小さく更新できない	Productionだけでなくテストtrack	端末に届くtrackと各artifactの番号を確認
AABを修正して再提出	アップロード済みか、審査状態か	既使用なら新しいversionCode。未確認ならConsoleの表示を優先

Google Playは、アプリの更新ごとにversionCodeを増やすこと、上限以下であることを案内しています。テストtrackを含め、ユーザーが受け取る候補では適格な中で最も高いversionCodeが選ばれるため、Productionとテストの番号関係にも注意が必要です。

AABを作り直す場合

まだアップロードしていない：コードを修正して同じversionCodeで作り直せます。ただし、別のAABをアップロード済みでないかを確認します。
Play Consoleへアップロード済み：同じ番号を再利用できると決めつけず、通常はより大きいversionCodeで再ビルドします。
審査reject後：修正内容だけでなく、Play Consoleが番号を使用済みとして扱っているかを確認し、エラーが出るなら新しい番号にします。

公式情報だけでは、すべてのドラフトや審査状態ごとの再利用可否を同じ文章で保証していません。記事では安全側に倒し、Play Consoleに既使用と表示された番号は再利用しない方針にしています。

GradleでversionCodeとversionNameを設定する

Android Developersの例では、モジュールのbuild.gradleまたはbuild.gradle.ktsのandroid { defaultConfig { ... } }に設定します。

// build.gradle.kts
android {
    defaultConfig {
        versionCode = 12
        versionName = "2.3"
    }
}

// build.gradle
android {
    defaultConfig {
        versionCode 12
        versionName "2.3"
    }
}

product flavorやbuild typeで値を上書きしているプロジェクトでは、defaultConfigだけ直しても、実際に生成したvariantの値が変わらないことがあります。最終的には、アップロードするAABのvariantと値を確認してください。

versionCodeの反映を確認する

Android StudioのGradleツールウィンドウにあるsigningReportは署名情報を確認するためのものですが、variantの取り違えを見つけるきっかけになります。versionCodeそのものは、生成物やPlay ConsoleのApp bundle explorerで確認するのが安全です。

Play Consoleで許可されるversionCodeの最大値は2,100,000,000です。日時をそのまま連結して、将来すぐ上限に近づく採番は避けます。

ロールバックは「古いコードを再公開」ではない

前の機能に戻したいとき、古いソースコードを使うこと自体はできます。しかし、Google Playへ提出するartifactのversionCodeまで古い番号に戻せるとは限りません。

実務では、次のように考えます。

戻したい時点のソースやGit tagを用意する
現在のPlay Consoleで使われている最大番号を確認する
古いソースを、より大きい新しいversionCodeでビルドする
テストtrackで動作を確認してから段階的に公開する

これはGoogle必須の採番テンプレートではなく、既使用番号との衝突を避けるための運用例です。versionNameは、ユーザーに「修正版」「復旧版」と伝わる名前へ整理できます。

個人開発向けの採番ルール

以下はGoogle Playの必須仕様ではなく、SysTecevoの推奨運用例です。

リリース	versionCode	versionName
初回	`1`	`1.0`
小規模更新	`2`	`1.1`
不具合修正	`3`	`1.1.1`
大型更新	`4`	`2.0`

Git tagやGitHub ReleaseとversionCodeは別物です。ただし、v1.1.1のtagにversionCode=3を記録するようにすれば、PC移行後も対応関係を追いやすくなります。

公開前チェックリスト

Play Consoleで、直近に使われたversionCodeを確認した
今回のAABが想定したbuild type・product flavorである
versionCodeが前回より大きく、上限2,100,000,000未満である
versionNameがユーザーに見せる表記として自然である
AABを作り直した場合、古いartifactをアップロードしていない
ロールバックなら、古いソースと新しいversionCodeを組み合わせた
Git tag・リリースメモに採番を記録した

前日のGoogle Playの署名鍵とアップロード鍵の記事では、AABを正しい鍵で署名する確認も扱っています。versionCodeと署名は別の問題ですが、公開前チェックでは続けて確認すると切り分けがしやすくなります。

FAQ

versionCodeとversionNameは何が違いますか？

versionCodeは内部判定用の正の整数、versionNameはユーザー向け表示文字列です。

Google Play更新時は両方変更しますか？

versionCodeは通常、前回より大きくします。versionNameはユーザーに見せる内容が変わるときに更新する運用が一般的ですが、Google Playの新旧判定はversionCodeで行われます。

versionCodeは必ず1ずつ増やしますか？

必ず+1ではありません。後続リリースでより大きい値にすればよく、将来の余地を残す採番をおすすめします。

versionCodeを飛ばしても大丈夫ですか？

仕様上は飛ばせます。ただし、日時やビルド回数を無計画に連結して上限へ急速に近づけないでください。

一度使ったversionCodeは再利用できますか？

Play Consoleへアップロードした番号が既使用と表示された場合は再利用せず、より大きい番号を使います。内部アプリ共有など別の仕組みは公開用リリースと条件が異なるため、混同しないでください。

versionCodeを下げられますか？

通常の単一アプリ更新では、前回より小さい番号へ下げないでください。過去版へ戻す場合も、古いソースを新しいversionCodeでビルドする考え方が安全です。

AABを作り直したらversionCodeも変更しますか？

Play Consoleへまだアップロードしていないなら、同じ番号で作り直せます。アップロード済みなら、既使用エラーを避けるため新しい番号を検討します。

審査に落ちたらversionCodeを上げますか？

修正後に新しいAABを作る場合、Play Consoleが番号を既使用として扱うなら上げます。審査状態ごとの再利用可否を推測せず、Consoleの表示を優先してください。

versionNameは1.0.0形式でなければいけませんか？

いいえ。versionNameは文字列なので、1.0.0以外の表示も可能です。個人開発では1.0、1.1.1、2.0のようなルールを決めておくと伝わりやすくなります。

versionCodeの最大値はいくつですか？

Google Playが許可する最大値は2,100,000,000です。Androidの一般的な整数上限とPlay Consoleのアップロード上限は分けて考えてください。

まとめ

versionCodeはGoogle Playが新旧を判断する内部番号、versionNameはユーザー向けの表示名です。通常更新ではversionCodeを前回より大きくし、AABをアップロード済みなら同じ番号を再利用しない方針で切り分けます。

個人開発では、採番表を作り、Play Consoleの履歴・Gradleのvariant・実際のAABを確認してから提出するだけで、重複エラーやロールバック時の混乱を減らせます。

参考：Android Developers「Version your app」／Google Play Console Help「Version codes」／Google Play Console Help「Create and set up your app」