いいえ。リセットされません
自由に更新してください。新ビルドでも14日間の時計はそのまま進みます新しいリリースを作ったからといって、クローズドテスト（closed testing）の時計がリセットされるルールはありません。14日間の要件は、オプトイン済みテスターを少なくとも12人、連続で維持しているかで測られます。アプリのバージョン、versionCode、アップロード回数とは無関係です。
オプトイン済みテスター数が12人を下回ること。
テスターが正式にオプトアウトし最低人数を割ると、連続のストリークが途切れます。更新したからではなく、12人を割ったからです。
簡潔な回答
いいえ。14日間のクローズドテスト中にアプリを更新しても、時計はリセットされません。必要なだけ新ビルドを出せます。既存のクローズドテストトラックへ新しいビルド（AAB）をアップロードしても、14日間は最初からやり直しになりません。時計はアプリのバージョン、versionCode、署名鍵ではなく、オプトイン済みテスターを少なくとも12人、連続で維持しているかに紐づきます。連続の窓を途切れさせるのは、オプトイン済み人数が12人を下回ること、または正式なオプトアウトだけです。更新は安全で、Googleはむしろ継続を勧めています。PrimeTestLabは実機のテスターを少なくとも12人、オプトイン済みで連続維持するので、修正を出しながら時計を進められます。
クローズドテストでいちばん多い不安のひとつがこれです。14日間の途中でバグを見つけ、修正を上げたら進捗が消え、2週間をやり直すのではないかと固まる。そんなことは起きません。14日間の時計が見ているのはテスターであり、ビルドではありません。本ガイドは、クローズドテストのタイマーをリセットするものとしないものを切り分け、任意の操作を自分で試せる2つのインタラクティブツールを用意し、更新の配信がGoogleの望む行動である理由を説明します。内容は2026年6月30日時点です。
このガイドの内容
アプリのアップデートは14日間のクローズドテスト時計をリセットする？
いいえ。テスト期間中の開発者がいちばん抱きやすい不安ですが、答えは安心できるものです。既存のクローズドテストトラックへ新しいアプリバンドルをアップロードしても、14日間連続のテスト要件はリセットされません。
14日間の時計はビルドではなくテスターに紐づきます。Googleの要件は、直近14日間を連続して、オプトイン済みテスターを少なくとも12人維持しているかで測られます。アプリのバージョン番号、AABのアップロード回数、リリースノートの内容は、そのタイマーの一部ではありません。
同じ質問はGoogle Playデベロッパーコミュニティでも繰り返し出ます。クローズドテスト用の新リリースを作ると14日間がリセットされるのか、アプリを更新するとカウンターが戻るのか、という議論です。独自に検証できないフォーラム投稿をそのまま引用する代わりに、本ガイドはPlay Consoleヘルプの公式ドキュメントに依拠します。要件はオプトイン済みテスターと時間だけで定義され、ビルドのアップロード回数では定義されていません。
これまでに支援したアプリ7,400+件を通じて、同じクローズドトラックへの通常のビルド更新だけで時計がリセットされた例はありません。特定の操作が心配なら、下のチェッカーで今からやろうとしていることを選び、14日間タイマーに触れるかどうかをすぐ確認できます。
どの操作が心配ですか？
Googleが公開するPlay Consoleの要件（オプトイン済みテスター×連続日数）と、広く報告されている開発者の経験に基づきます。コミュニティで注意が挙がる2点はその旨を明示しています。
14日間タイマーを実際にリセットするものは？
14日間連続の窓は、ただ日めくりが進むカレンダーではなく、一貫性のチェックとして理解するのが正確です。Googleが見たいのは、オプトイン済みテスターを少なくとも12人、途切れなく維持していることです。その連続を壊すと確認されているトリガーは次の2つだけです。
オプトイン済みが12人未満になる
1人でもオプトアウトして11人になると、連続が途切れ、2週間まるごとやり直しになり得ます。これがDIY開発者が失敗する最大の理由です。
テスターが正式にオプトアウトする
テスターは、テスト用のWebリンクを開き離脱を選ぶことでオプトアウトします。アンインストールとは別で、12人を割る場合にだけ時計に悪影響します。
新しいビルドのアップロードはそのリストに入りません。ストア掲載の誤字修正、テスターからのフィードバック、端末上のクラッシュも同様です（クラッシュこそテストの意味です）。下のシミュレーターで差は一目瞭然です。更新ボタンを連打しても何も動きませんが、テスターが12人を割るとストリークは崩れます。
時計をリセットしないもの
同じトラックへ新しいAABをアップロード
リリースノートやストア掲載情報の編集
テスターからのフィードバック
テスター端末でのクラッシュ
versionCodeやバージョン名の上げ直し
オプトアウトなしのアンインストール
クローズドテストへアップデートを出すには？
アップデートの出し方は、最初のリリースと同じ流れです。重要な違いは1つだけです。テスターがすでにオプトインしている同じクローズドテストトラック上に新しいリリースを作ること。新しいテストを始めるのではなく、すでに走っているテストにビルドを足すので、14日間の時計はそのまま進みます。Play Consoleでの2ステップは次のとおりです。
クローズドトラックで新しいリリースを作成 テスト > クローズドテスト > トラックを管理
これまで運用しているクローズドテストトラックを開き、新しいリリースを作成を選び、更新したアプリバンドル（AAB）をアップロードします。変更点を短いリリースノートに書き、保存します。同じトラック上に置くことが、14日間連続の窓を守るポイントです。
レビューしてロールアウト リリースを確認 > ロールアウトを開始
次へとリリースを確認を進め、クローズドトラックへのロールアウトを開始します（公開の概要で変更を審査に送信を求められたら送信）。新しいリリースが公開されると（Googleによると、公開した変更がテスターに届くまで数時間かかることがあります）、端末は新しいビルドへ自動更新されます。再インストールも再オプトインも不要です。
これで時計はリセットされません。テスターがすでにオプトインしている同じクローズドトラックへ出すため、14日間連続の窓は新ビルドの下で動き続けます。新しいテストを始めるのではなく、ビルドを足しているだけです。それが本ガイドの中心的な答えです。
招待済みとオプトイン済みテスターの違いは？
初めて公開する人ほどここでつまずきやすく、ビルドが時計に関係しない理由の核心でもあります。Googleの仕組みはテスターをファネルで進め、重みを持つのは後半の段階だけです。
招待済み
テスターリストまたはGoogle Groupにメールアドレスを追加しただけ。それ以上はまだ起きていません。
オプトイン済み
オプトインリンクを開き、Googleアカウントでログインし、「テスターになる」を選んだ状態。14日間の時計が測るのはこのステータスです。
インストール＆利用
アプリをダウンロードし使い続けている状態。生の人数は変わりませんが、製品版へのアクセス申請時にGoogleが重く見るエンゲージメントです。
Googleのドキュメントが示すとおり、メールを追加しただけでは足りません。各テスターがオプトインリンクを開き、認証し、明示的にテスターになるまでカウントされません。だからこそアプリ更新で進捗が消えないのです。テスターはオプトイン状態を離れないので、新しいビルドをまたいでも時計は進み続けます。手順の全体像はテスターを正しく招待する方法を参照してください。
数千件のテスト運用からのヒント：静的なメールリストよりGoogle Group経由でテスターを運用してください。GroupをPlay Consoleに接続しておけば、入れ替えはGroupの編集だけで済み、オプトインリンクは同じまま、トラックも止まりません。リスト調整の際にアクティブなテスターを誤って消すリスクが減ります。それこそ連続を本当に壊し得る数少ない操作のひとつです。
Googleの正確な要件文言は？
Google公式のPlay Consoleヘルプ「新しい個人用デベロッパーアカウントのアプリテスト要件」は、次のように定めています。
「新たに作成した個人用デベロッパー アカウントをお持ちの場合は、12 人以上のテスターが 14 日以上連続でオプトインしてアプリの クローズド テストを実施する必要があります。」
Google Play Consoleヘルプ · answer 14151465（日本語）製品版へのアクセスを申請する時点については、別に次のように書かれています。
「製品版へのアクセスを申請する時点で、少なくともテスター12人がクローズドテストにオプトインしている必要があり、そのオプトインは直近14日間連続で維持されていなければなりません。」
Google Play Consoleヘルプ · answer 14151465Googleは日数が連続でなければならないことも明示しています。オプトインして14日未満でテストしたあとオプトアウトしたテスターはカウントされず、再オプトインしても、14日間は連続でなければ足りません。この一文だけで「14日間は累積」という誤解は崩れます。そして同じくらい重要なのは、ビルドについて一言も触れていないことです。
押さえておく3つの事実
テスト中のアップデートは良いのか悪いのか？
ここで開発者の不安は機会に変わります。クローズドテスト中の更新は、広く良いエンゲージメントのシグナルと見なされています。Googleが公式に言うことと、開発者コミュニティが結論づけていることを分けておくと整理しやすいです。重なりはありますが同一ではありません。
直し続け、改善し続ける
Play Consoleヘルプは継続的な改善を勧めています。ユーザー報告の問題やバグを直すあいだもクローズドテストを使い続け、製品版の前にクローズドテストで更新するのは「低品質なレビューや評価を抑えるのに役立つ」とされています。
製品版へのアクセスを申請するとき、質問票では受け取ったエンゲージメントと、テスターのフィードバックをどう扱ったかの説明を求められます。
動いている方が凍結より良い
実務側はさらに踏み込みます。14日間ずっとバージョン1.0のまま無活動だとチェックボックスのためのテストに見えやすく、フィードバックに応じて更新を出す姿は本物の開発に見えます。反応の良さを示すため、小さな更新を2～3回出す開発者もいます。
これはコミュニティの合意と妥当な推論であり、Googleが公開したルールではありません。「X回更新せよ」という数値要件は示されていません。
要点：更新は安全で推奨され、そこで築くエンゲージメントの物語は製品版へのアクセス質問票への回答にも役立ちます。本当のリスクは「出す行為」ではなく「何を出すか」にあります。それが唯一の本質的な注意点につながります。
壊れたアップデートは間接的に時計をリセットする？
はい。ここが本当に重要な例外です。更新という行為そのものがタイマーを直接リセットすることはありませんが、壊れた更新の結果としてリセットされ得ます。連鎖は次のとおりです。
ルールはシンプルです。自由に更新してよいが、クローズドトラックへ出す前に最低限の安定性を確認すること。そしてちょうどテスター12人で走らないこと。壊れたビルドからの1人のオプトアウトで沈み得るからです。12人を超えるバッファがそのリスクを吸収します。
連鎖を正確に読んでください：リセットの原因は更新そのものではありません。オプトイン済みが12人を下回ったことです。壊れたビルドは、オプトアウトを引き起こしたきっかけにすぎません。ビルドを安定させ、バッファを保てば、間接リスクも消えます。
アップデート後、再インストールや再オプトインは必要？
いいえ。一度オプトインしてインストールすれば、更新はGoogleが自動で扱います。クリックし直すものも、再送するものもありません。
更新は自動で届く
GoogleのPlay Consoleヘルプ「オープン、クローズド、または内部テストの設定」（answer 9845334）は次のように述べています。「テスターがアプリをインストールすると、数分以内に自動的にテスト版へ更新されます。」テスターはビルドをまたいでオプトインを維持します。再インストールも、オプトインの再クリックも不要です。
同じGoogleページのタイミング上の注意：追加の変更を公開したとき、端末への自動更新が始まるまで「数時間、テスターに届かない場合がある」とあります。しかし14日間の時計が測るオプトイン状態は、新しいAABをまたいでも引き継がれます。だからビルド更新で時計がリセットされないのです。テスターは一度も離れていません。
重要な例外 新しい権限はサイレント更新を妨げ得る
サイレントに届かないビルドが1種類あります。ACCESS_FINE_LOCATION、カメラ、マイクなど危険（機密）な権限を新たに足す更新です。権限とターゲットAPIレベルによっては、Google Playがバックグラウンドではなく、テスターがタップして承認する更新を表示することがあり、無視した人は古いビルドのままです。サイレントに入っても、新しい権限は実行時に付与されるため、許可されるまで権限依存の機能が壊れているように見えることがあります。
クローズドテストでは静かな罠です。5日目に権限の重い更新を出すと、プロンプトに気づかないテスター分だけアクティブ人数が落ち得ます。それは製品版へのアクセス申請時にGoogleが重く見るエンゲージメント信号そのものです。リスクの高い新権限は、権限の申告審査を引き起こし、ビルド公開自体を遅らせることもあります。
テスト途中でロールアウトする前に：新しいマニフェストの権限を現行ビルドと比較してください。権限セットが変わった場合、Playストアを開いて手動で更新し（新しいプロンプトも許可するよう）テスターへ連絡し、申告審査の可能性も見込んでください。
クローズドテストでよくある誤解を解く
更新まわりの不安の多くは、数個の誤解に帰着します。開発者の睡眠をいちばん奪う5つと、実際のところは次のとおりです。
誤解1「新しいリリースを作ると時計がリセットされる。」
誤解2「アンインストール＝オプトアウト。」
誤解3「14日間は累積。」
誤解4「ちょうどテスター12人で足りる。」
誤解5「テスターは毎日アプリを使わなければならない。」
時計をリセットするもの／しないもの
この問いを一画面にまとめました。保存し、スクショし、チーム内で繰り返し聞かれる人に送ってください。ビルドに関することは安全で、テスター人数に関することだけが危険です。
| 操作 | 14日間をリセット？ |
|---|---|
| 同じクローズドトラックへ新しいAABをアップロード | いいえ |
| リリースノートやストア掲載メタデータの編集 | いいえ |
| テスターからのフィードバック | いいえ |
| テスター端末でのクラッシュ | いいえ |
| テスターのアンインストール（オプトアウトなし） | いいえ* |
| オプトイン済みが12人未満になる | はい |
| Webリンクからの正式なオプトアウト | はい** |
| オプトアウトを招き12人割れを起こす壊れたビルド | 間接的に |
| クローズドテストトラックの一時停止 | 報告されるリスク |
| テスターリストを上書きしアクティブを外す | 報告されるリスク |
* タイマーは技術的には続きますが、アンインストールした人はほとんど戻りません。** 12人を割る場合のみ。下2行はコミュニティで報告される注意であり、Googleが確定した文書ではありません。「リスクを取らない」前提で扱ってください。Google Groupを使えばリスト上書きリスクを避けられます。
要件はこれまでどう変わってきたか
古いチュートリアルを読むと人数が合わないのはこのためです。期間はずっと14日間連続で、動いたのはテスター人数だけです。
2023年11月より前は、製品版に進むための必須クローズドテストはありませんでした。テスターを集めなくても公開できました。
2023年11月13日以降に作成した個人用アカウントは、オプトイン済みテスター20人で14日間連続のクローズドテストが必要でした。組織用アカウントは対象外でした。
2024年12月11日、最低人数は20人から12人へ下がり、14日間という期間は変わりませんでした。組織用アカウントは引き続き対象外です。
いまもテスター20人を集めろと書いているガイドは古いです。切り替えの詳細は20人から12人への変更（英語）で扱っています。
知っておくべき2026年のポリシー変更
クローズドテストは単独で存在しません。2026年のいくつかの締切がローンチ計画と交差し得ます。14日間の時計の仕組み自体は変えませんが、カレンダーを見ていないとテスト期間とぶつかることがあります。
タイムラインと交差し得る2026年の締切
日付はGoogle Play Consoleヘルプ（ターゲットAPIレベル）とAndroid Developers Blog（developer verification）に基づきます。Verificationの時期は段階的で2026～2027年に広がる可能性があるため、計画前に公式ページで確認してください。一覧は2026年公開要件ガイドで追っています。
PrimeTestLabが時計を途切れさせにくくする仕組み
クローズドテストでいちばん難しいのはルール理解ではなく、改善を続けながら実在の人を12人以上、オプトイン済みかつ関与した状態で14日間途切れなく保つことです。PrimeTestLabはそのためにあります。実機でオプトインするテスターを提供し、Play Consoleの設定を伴走するので、時計をきれいに始め、修正を出しながら進めやすくなります。含まれる内容はGoogle Playクローズドテストサービスを参照してください。成功率は99.9%（過去実績）、アプリ7,400+件、テスト開始は通常4～6時間以内です。
Play Consoleに当社テスターを追加し、テスト用URLを共有すれば時計が始まります。あとは好きなだけビルドを更新できます。テスターはオプトインを維持するため、ストリークはその下で進み続けます。
表示価格に加え、別途サービス手数料5%がかかります。保証は無料再テストまたは全額返金から選べます。
多くの開発者がテスター12人の最低ラインより多く選ぶのは、壊れたビルドによるものを含め、1人のオプトアウトで12人を割って時計がリセットされないようにするためです。バッファは、連続を本当に壊すものに対するいちばん安い保険です。
よくある質問
クローズドテスト中にアプリを更新しても、14日間はやり直されませんか？
はい。既存のクローズドテストトラックへ新しいビルドをアップロードしても、14日間連続の窓はやり直しになりません。時計はアプリのバージョンではなく、オプトイン済みテスターを少なくとも12人、連続で維持しているかに紐づきます。テスターは自動更新されオプトインを維持するため、ビルドをまたいでも進捗は引き継がれます。
クローズドテストの時計をリセットするものは何ですか？
14日間連続の窓が途切れるのは、オプトイン済み人数が12人を下回ったとき、または正式なオプトアウトで最低人数を割ったときです。ビルドの更新、ストア掲載情報の編集、クラッシュではリセットされません。12人より多いバッファを保つことが、連続維持を守るいちばん確実な方法です。
招待済みテスターとオプトイン済みテスターの違いは？
招待済みは、メールアドレスをリストに追加しただけの状態で、要件にはカウントされません。オプトイン済みは、リンクを開き、Googleアカウントでログインし、「テスターになる」を選んだ状態で、14日間の時計が測るのはこちらです。要件に入るのはオプトイン済みだけなので、オプトイン手順まで完了しているか必ず確認してください。
アップデート後、テスターは再オプトインが必要ですか？
いいえ。一度オプトインしてインストールすれば、Googleは数分以内に更新を自動配信します。再インストールやオプトインリンクの再クリックは不要です。14日間要件が測るオプトイン状態は、同じクローズドトラックへ出す新しいビルドすべてで途切れずに続きます。
アンインストールはオプトアウトと同じですか？
いいえ。正式なオプトアウトは、テスト用のWebリンクを開き離脱を選んだときだけです。アンインストールしただけでは、タイマーは技術的には動き続けます。ただし実務上、アンインストールしたテスターはほとんど戻らず、製品版へのアクセス申請時のエンゲージメントを弱くし得るため、アクティブな利用を保つ意味はあります。
Googleはテスト中のアップデートを求めていますか？
Googleのドキュメントは、製品版の前にクローズドテストで問題を直し続け、今後の更新も定期的にテストすることを勧めています。開発者コミュニティでは、更新のない凍結アプリより、フィードバックに応じて更新する姿を良いエンゲージメントのシグナルと見なす傾向があります。更新回数の数値要件は公開されていないため、形式的な連打ではなく本物の改善として繰り返してください。
クローズドテストに本当に必要なテスターは何人ですか？
Googleの最低ラインは、2023年11月13日以降に作成した個人用アカウントで、オプトイン済みテスター12人を14日間連続です。1人のオプトアウトで12人を割り連続が途切れ得るため、多くの開発者はバッファとしてテスター20～25人で運用します。PrimeTestLabはテスター12人、20人、25人のプランを$19.99から（別途サービス手数料5%）提供しています。
まとめ
要約
14日間のクローズドテスト中のアプリ更新は安全で、普通で、推奨されます。時計はオプトイン済みテスターを少なくとも12人、連続で維持しているかで測られるため、新しいビルドだけではリセットされません。本当のリスクは、オプトイン済みが12人を割ること、正式なオプトアウト、または離脱を招くほど壊れたビルドを出すことです。修正を出し、フィードバックで改善し、最低ラインを超えるバッファで人数を守ってください。途切れにくい時計が必要なら、PrimeTestLabは実機のテスター12～25人をオプトイン済みで維持し、$19.99から（別途サービス手数料5%）、テスト開始は通常4～6時間以内です。料金プランを見る →