結論：Googleの公開要件はversionCodeではなく、テスターの連続オプトインです。Google自身も、クローズドテスト中のアプリ更新を推奨しています。
「更新すると14日間が振り出しに戻る」という不安から、テスト期間中の修正をため込む開発者がいますが、Googleが公式に公開している要件と推奨を確認すれば、ため込む理由はありません。この記事では、公式で確認できること、公開されていないこと、TestCrewとしての実務上の安全策を分けて整理します。
公開仕様なし
「versionCodeを更新すると14日間がリセットされる／されない」というルールを、Googleは独立した仕様としては公開していません。公開されているのは、テスター各自の14日間連続オプトインという要件です。
TestCrewはテスター募集とテスト参加を支援するサービスです。Google Playの本番アクセス、審査、公開を保証するものではありません。要件は変更される可能性があるため、公式ヘルプも併せて確認してください。
公式で確認できること
Google公式
Googleは、ユーザーから報告された問題やバグを解決している間も、引き続きクローズドテストを実施することを推奨しています。また、製品版リリース前にクローズドテストでアプリを更新することで、低評価を最小限に抑えられるとしています。
要件が「テスターの連続オプトイン」であり、Google自身がテスト中の更新を推奨している、この2点が公式で確認できる範囲です。
14日間で維持するものは何か
12人・14日要件で確認されているのは、次の2つです。
- テスター数：12人以上がクローズドテストへオプトインしている
- 継続期間：各テスターが直近14日間連続でオプトインしている
つまり要件の中心は「アプリのバージョン」ではなく「各テスターのオプトイン状態」です。
Google公式
オプトイン期間が14日間にならないうちにテスターがオプトアウトした場合、その人は要件を満たすテスターとしてカウントされません。再度オプトインした場合、その人について再び14日間連続のオプトインが必要です。
カウントの基準はアプリのバージョンではなく、テスター側の参加状態にあります。テスト中に何が進行を崩すかといえば、通常のアプリ更新よりも、テスターのオプトアウトやテスター構成の変更です。
更新をため込まないでよい根拠
公式で確認できる事実を並べると、次のとおりです。
- 公開要件はテスターの連続オプトインであり、versionCodeではありません
- Googleは問題やバグを修正している間もクローズドテストを継続することを推奨しています
- 製品版リリース前にクローズドテストでアプリを更新することも推奨されています
テスターが修正版を確認し、問題が解消されたことを記録として残せるのは、申請の回答にも役立ちます。修正 → 再確認のサイクルを回さない方が、むしろテスト期間を無駄にする可能性が高いでしょう。
更新時の実務上の安全策
「リセットされるかどうか」の保証表現は避けますが、テストの継続状態に影響し得る変更は知っておくべきです。
TestCrewの推奨
次の3点を実務上の安全策として推奨します。いずれもGoogleの必須条件ではなく、テストの進行を崩さないための運用上の配慮です。
- 同じクローズドテストトラックを維持して更新する
- テスター構成（グループ・リスト・トラック）を不用意に変更しない
- 更新後はテスターに修正版の再確認を依頼する
具体的に、次のような変更はテストの継続状態に影響する可能性があります。
| 変更 | 影響 |
|---|---|
| パッケージ名（applicationId）の変更 | 別アプリとして扱われ、テストをやり直すことになる可能性が高い |
| トラックの作り直し・別トラックへの移行 | テスター設定や参加状態が引き継がれない場合がある |
| テスターグループ・メールリストの作り直し | 参加対象が変わり、人数が減って見える |
| 既存テスターの削除 | 12人を下回り、要件を満たすテスターの確保が後ろ倒しになる |
| 配信対象国や対応端末の絞り込み | 一部テスターが最新版を取得できなくなる |
また、versionCodeを増やさずにAABを差し替えようとすると、更新自体が失敗するか、テスター端末へ配信されません。更新時はversionCodeを必ず増やします。
更新版がテスターに届かない場合は、Google Playクローズドテスト版が更新されない原因で切り分けられます。
テスターが途中で抜けた場合
アプリ更新の前に確認すべきは、むしろこちらです。テスターが14日間未満でオプトアウトすると、その人は要件を満たすテスターとしてカウントされず、再オプトイン時には改めて14日間の連続オプトインが必要です。
- 12人ぴったりで運用していると、1人の離脱で要件を満たす人数を下回る
- 離脱に備えて、余裕を持って募集する（TestCrewの運用目安では14〜16人程度。Googleの要件ではありません）
- 12人を下回った場合は、再び12人以上が連続14日の条件を満たせる時点が後ろ倒しになる
途中離脱への対策と「リセットされたように見える」現象全般については、Google Playクローズドテストの14日間がリセットされる原因で、アプリ更新とは別の観点から整理しています。同記事は「人数低下・リスト変更・トラック混同」などリセットの原因全般、この記事は「アプリ更新」に限定した解説です。
更新後、何を確認してもらうべきか
アップデートしても終わりではありません。修正版を配信したら、テスターに次を確認してもらいます。
- ストアから最新版へ更新できているか
- 修正したはずの不具合が解消されているか
- 更新によって新たな問題が出ていないか
- 主要機能が引き続き動くか
この「修正 → 再確認」のサイクルを回せるかどうかが、テスト期間の質を左右します。テスターへ再確認を依頼するときは、次のような文面が使えます。
修正版（v2）を公開しました。Playストアからアプリを最新版に更新して、
以前教えていただいた○○の問題が解消されているかご確認ください。
テストへの参加はそのまま維持していただいてOKです。
更新後のテスト運用例
TestCrewでテスターを管理している場合、更新後の再確認もTestCrewから依頼できます。
【従来】
バグ修正 → 新しいAABをアップロード → 以前のテスターを思い出す
→ Discordやメールで個別に連絡 → 返信を手作業で集計
【TestCrew】
バグ修正 → 新しいAABをアップロード
→ TestCrewの「更新後の確認」から以前のテスターへ再確認を依頼
→ 結果（問題なく確認できた／問題があった）を一覧で受領
以前テストに参加したテスターへ更新後の確認を依頼できる機能について、詳しくはアプリ更新後にテスターへ再確認を依頼できるようになりましたで紹介しています。
申請前には、修正履歴とテスターの再確認結果が整理されていると、製品版アクセス申請の「テスト結果を受けて変更した内容」の回答が書きやすくなります。
まとめ
- Googleの公開要件は、テスターの連続オプトイン（12人以上・直近14日間）であり、versionCodeではありません
- Googleは問題やバグを修正している間もクローズドテストを続け、製品版リリース前にテストでアプリを更新することを推奨しています
- 「更新するとリセットされる／されない」というルール自体は独立した仕様として公開されていないため、保証表現ではなく公式要件で判断する
- 更新時は、同じトラックの維持・テスター構成を勝手に変えない・更新後の再確認依頼、を安全策として行う
- テスターの途中離脱こそが条件を崩す。募集は余裕を持って
テスト期間中の人数が減っていないか定期的に確認する習慣は、クローズドテストの進捗・日数の確認方法で解説している確認方法とセットで運用してください。
一次情報
公式参考資料
Google PlayやFirebaseの画面・要件は変更される場合があります。公開作業の前に、リンク先の最新情報も確認してください。
Google Playクローズドテストの14日間がリセットされる原因
Google Playクローズドテストの14日間がリセットされたように見える原因を解説。12人目の参加日、途中離脱、テスター変更、トラック混同、表示更新を確認します。
記事を読む
Google Playクローズドテスト版が更新されない原因
Google Playクローズドテストの更新版がPlayストアに表示されない原因を解説。versionCode、公開トラック、処理状態、複数トラック、端末互換性を確認します。
記事を読む
Google Playクローズドテストでテスター人数がカウントされない原因
Google Playクローズドテストで参加者数が増えない原因を解説。メール登録、オプトイン、Googleアカウント、Playストア、反映時間、参加解除を確認します。
記事を読む
Google Play製品版アクセス申請の回答例｜クローズドテスト後
Google Play製品版アクセス申請で聞かれる内容と回答の作り方を解説。テスター募集、テスト内容、フィードバック、改善点を具体化する例を紹介します。
記事を読む