いいえ。リセットされません
通常の更新なら、テスターのオプトイン期間はそのまま進みます新しいリリースを作成するとクローズドテスト（closed testing）がやり直しになる、というルールをGoogleは公開していません。要件は、各テスターが14日間連続でオプトインを続け、申請時にそうしたテスターが少なくとも12人いることです。バージョンコードやアップロードしたビルドの数は要件に含まれません。
テスターがテストを抜け、途切れのない14日間を満たす人が12人未満になること。
オプトアウトして再参加したテスターは、その人自身の14日間を最初からやり直し、補充したテスターは1日目から始まります。その結果、途切れのない14日間を満たすテスターが12人未満になると、申請はそれまで待つことになります。原因は更新ではありません。
簡潔な回答
いいえ。同じアプリを進行中のクローズドテストトラックで更新しても、それだけでテスターのオプトイン期間がやり直しになることはありません。2023年11月13日以降に作成された個人用デベロッパーアカウントでは、製品版へのアクセスを申請する時点で、それぞれ直近14日間連続でオプトインを続けているテスター12人以上が必要です。オプトアウトしたテスターは、その人自身の14日間を最初からやり直します。Googleはフィードバックへの対応を推奨していますが、必要なリリース回数は公開していません。テスターに新しいビルドが表示されない場合は、公開状況、ロールアウトの対象、端末側の更新を確認してください。
クローズドテストでよくある不安のひとつがこれです。14日間の途中でバグを見つけたものの、修正をアップロードしたら進捗が消えて2週間をやり直すことになるのでは、と手が止まってしまう。そうはなりません。14日間の要件が見ているのはテスターであり、ビルドではありません。本ガイドでは、クローズドテストの期間を中断させるものとさせないものを切り分け、任意の操作を自分で確かめられる2つのインタラクティブツールを用意し、テスターに新しいビルドが表示されないときの確認点を説明します。内容は2026年10月16日時点のGoogleヘルプページで確認しています。
このガイドの内容
アプリのアップデートは14日間のクローズド テスト時計をリセットする？
いいえ。テスト期間中の開発者が最もよく抱く不安ですが、答えは安心できるものです。既存のクローズドテストトラックへ新しいアプリバンドルをアップロードしても、それだけでテスターのオプトイン期間がやり直しになることはありません。
14日間の要件はビルドではなくテスターに紐づいています。Googleはテスターごとに測ります。製品版へのアクセスを申請する時点で、少なくとも12人のテスターがそれぞれ直近14日間連続でオプトインしている必要があります。アプリのバージョン番号、新しいAABをアップロードした回数、リリースノートの内容は、この要件には含まれません。
まさにこの質問は、Google Playデベロッパーコミュニティで何度も出てきます。Play Consoleヘルプは、要件をオプトイン済みテスターと期間だけで定義しており、ビルドのアップロードには一切触れていません。2024年1月には、Googleのプロダクトエキスパートがコミュニティで承認済みの回答として実務的な答えを示しました。テスト中の更新は審査が必要になることはあっても、14日間はリセットされない、というものです。これはポリシーに対する専門家の解釈であり、ポリシー本文の記述ではありません。
特定の操作が不安ですか？下のチェッカーで、これから行う操作を選ぶと、それがテスターの14日間に影響するかどうかがわかります。
どの操作が心配ですか？
Googleが公開するPlay Consoleの要件（オプトイン済みテスター×連続日数）と、広く報告されている開発者の経験に基づきます。コミュニティで注意が挙がる2点はその旨を明示しています。
14日間タイマーを実際にリセットするものは？
14日間連続の窓は、ただ日めくりが進むカレンダーではなく、一貫性のチェックとして理解するのが正確です。Googleが見たいのは、オプトイン済みテスターを少なくとも12人、途切れなく維持していることです。その連続を壊すと確認されているトリガーは次の2つだけです。
オプトイン済みが12人未満になる
1人のテスターが抜けて要件を満たすテスターが11人になると、12人目のテスターが途切れのない14日間を満たすまで申請できず、補充したテスターは1日目から始まります。これがちょうど12人で運用するのが危険な理由です。
テスターが正式にオプトアウトする
テスターは、テスト用のWebリンクを開いて離脱を選ぶことでオプトアウトします。これはアンインストールとは別です。そのテスター自身の14日間は止まり、再参加すると最初からやり直しになります。申請が遅れるのは、その結果、要件を満たすテスターが12人未満になる場合だけです。
新しいビルドのアップロードはそのリストに入りません。ストア掲載の誤字修正、テスターからのフィードバック、端末上のクラッシュも同様です（クラッシュこそテストの意味です）。下のシミュレーターで差は一目瞭然です。更新ボタンを連打しても何も動きませんが、テスターが12人を割るとストリークは崩れます。
時計をリセットしないもの
同じトラックへ新しいAABをアップロード
リリースノートやストア掲載情報の編集
テスターからのフィードバック
テスター端末でのクラッシュ
versionCodeやバージョン名の上げ直し
オプトアウトなしのアンインストール
クローズド テストへアップデートを出すには？
アップデートの出し方は、最初のリリースと同じ流れです。重要な違いは1つだけです。テスターがすでにオプトインしている同じクローズド テストトラック上に新しいリリースを作ること。新しいテストを始めるのではなく、すでに走っているテストにビルドを足すので、14日間の時計はそのまま進みます。Play Consoleでの2ステップは次のとおりです。
クローズドトラックで新しいリリースを作成 Test and release > Testing > Closed testing > Manage track
これまで運用しているクローズドテストトラックを開き、Create new release（新しいリリースを作成）をクリックして、更新したアプリバンドル（AAB）をアップロードします。パッケージ名と署名の設定は同じままにし、ビルドにはより大きいversionCodeを付けてください。versionNameだけを変えてもアップグレードにはなりません。変更点を短いリリースノートに書き、保存します。同じトラック上で出すことが、テスターの14日間を進め続けるポイントです。
レビューしてロールアウト リリースを確認 > ロールアウトを開始
Next（次へ）とReview release（リリースを確認）を進め、クローズドトラックへのロールアウトを開始します。次にPublishing overview（公開の概要）を開きます。保留中の変更があればSend changes for review（変更を審査に送信）を選び、公開の管理がオンになっている場合は、承認された変更をご自身で公開します。提出した更新は、テスターに届く前にIn review（審査中）と表示されることがあり、Googleによると、公開した変更がテスターに届くまで数時間かかることがあります。既存のテスターは通常そのまま更新され、再インストールも2回目のオプトインも不要です。
これでテスターのオプトイン期間がやり直しになることはありません。テスターがすでにオプトインしている同じクローズドトラックへリリースするため、新しいビルドの裏で14日間は進み続けます。新しいテストを始めるのではなく、ビルドを追加しているだけです。それでもテスターに新しいビルドが表示されない場合は、次のセクションの確認項目を順に試してください。
テスターに新しいビルドが届かないのはなぜ？
まず目的のビルドがテスターのトラックに公開されているかを確認し、次にテスターのアカウントとインストールされているバージョンを確認し、最後に端末を確認します。これは確認の順番であり、よくある原因のランキングではありません。対象のテスターが目的のビルドをインストールし、変更点を再テストした時点で完了です。ストア掲載情報の日付が新しくなっただけでは不十分です。
更新がまだ審査中のまま
提出した更新は、そのビルドがテスターに届く前に審査が必要になることがあります。Play ConsoleでPublishing overview（公開の概要）を開き、表示内容に応じて対応してください。
- まだ送信されていない変更：一覧を確認し、Send changes for review（変更を審査に送信）を選びます。
- 審査中：正しいアプリ、トラック、バージョンであることを確認し、Console内のメッセージがあれば従ってください。状況を更新するためだけに別のビルドをアップロードしないでください。Googleは最後に提出された変更から審査時間を数えます。
- 公開できる変更：公開の管理がオンになっているため、承認された変更をご自身で公開します。
リリースが審査待ちであることと、テスターがオプトインを続けていることは別の状態です。Googleは、通常の更新の審査によってテスターのオプトイン期間が一時停止したりリセットされたりするとは説明していません。
一部のテスターしか更新できない
公開された更新が届くのは、ロールアウト対象であり、かつ受け取る資格のあるテスターだけです。次の順に確認してください。
- 段階的ロールアウト：クローズドテストを含むテストトラックの更新ではロールアウト率を設定でき、その割合は自動では上がりません。Closed testing > Releases でManage rolloutを開き、割合とロールアウトが停止されていないかを確認してください。
- アカウント：リストやGoogleグループに登録したアドレス、オプトインしたアカウント、Playストアにログインしているアカウントが同じである必要があります。
- 内部テスト：内部テストにオプトインしたままのテスターは、内部テストを抜けてクローズドテストに参加するまで、クローズドテストのビルドを受け取る資格がありません。これは登録状態の修復であり、通常の更新手順ではありません。
- バージョンコード：Google Playは、テスターが受け取れる互換性のあるビルドのうち、versionCodeが最も大きいものをインストールします。versionNameを変えるだけではアップグレードになりません。
- 端末：ビルドがテスターの端末に対応しており、配信設定にその端末が含まれている必要があります。
リリースは公開済みなのに、端末には古いビルドのまま
テスターの登録状態に手を付ける前に、Playストア本来の更新手順を試してください。
- テストリンクからアプリのPlayストア掲載ページを開き、更新が表示されていればタップします。または、プロフィール > アプリとデバイスの管理 > 利用可能なアップデート を開きます。
- 自動更新を確認します。オフになっている、Wi-Fi接続時のみに制限されている、このアプリだけオフになっている、といった場合があります。
- 通信状況と空き容量を確認し、Playストアをいったん閉じて開き直します。
- それでも駄目な場合に限り、Playストアのキャッシュを削除します（アプリ情報 > ストレージとキャッシュ > キャッシュを削除）。キャッシュを削除しても、まだ審査中のリリースが公開されることはありません。
更新を受け取るためにテストを抜けて再参加するよう、テスターに頼まないでください。抜けると、そのテスターの途切れのない14日間が途切れます。アプリのアンインストール、Google Play開発者サービスのデータ削除、端末のリセットも、通常の更新手順には含まれません。
招待済みとオプトイン済みテスターの違いは？
初めて公開する人ほどここでつまずきやすく、ビルドが時計に関係しない理由の核心でもあります。Googleの仕組みはテスターをファネルで進め、重みを持つのは後半の段階だけです。
招待済み
テスターリストまたはGoogle Groupにメールアドレスを追加しただけ。それ以上はまだ起きていません。
オプトイン済み
オプトインリンクを開き、Googleアカウントでログインし、「テスターになる」を選んだ状態。14日間の時計が測るのはこのステータスです。
インストール＆利用
アプリをダウンロードし使い続けている状態。生の人数は変わりませんが、製品版へのアクセス申請時にGoogleが重く見るエンゲージメントです。
Googleのドキュメントが示すとおり、メールアドレスを追加するだけでは不十分です。各テスターがオプトインリンクを開き、認証し、明示的にテスターになって初めてカウントされます。通常のアプリ更新で進捗がやり直しにならないのもこのためです。テスターはオプトインしたままなので、新しいビルドをまたいでも日数は数え続けられます。手順の全体像はテスターを正しく招待する方法のガイドを参照してください。
数千件のテストを運用してきた経験からのヒント：テスターは静的なメールリストではなくGoogleグループで管理してください。GoogleはCSVをアップロードすると以前のテスターリストが上書きされると説明しているため、グループを使えば、リストを調整する際にアクティブなテスターを誤って消してしまうことを防げます。ただし、グループは万全ではありません。アクセスは引き続きメンバー登録で決まるため、グループから誰かを削除したり、別のグループを紐づけたりすると、対象となるテスターが変わります。
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はそのようなノルマを公開していません（下のリリース回数のセクションを参照）。
これはコミュニティの意見と妥当な推論であり、Googleが公開したルールではありません。Googleは「更新をX回出す」という数値要件を定めていません。
要点：更新は安全で推奨され、そこで築くエンゲージメントの物語は製品版へのアクセス質問票への回答にも役立ちます。本当のリスクは「出す行為」ではなく「何を出すか」にあります。それが唯一の本質的な注意点につながります。
クローズドテスト中にリリースは2～3回必要？
Googleが公開しているクローズドテストのガイダンスには、リリース回数の下限は定められていません。テスターのフィードバックに対応し、テストで見つかった問題を修正することが推奨されており、製品版へのアクセスの申請では、行った変更について説明を求められます。アップロード回数は要件に含まれていません。
- 少なくとも12人のテスターを途切れのない14日間オプトインさせておく （公開されている要件）
初日から、各テスターの途切れのないオプトインを守る。 - フィードバックに対応し、テストで見つかった問題を修正する （Googleのガイダンス）
フィードバック、修正、再テストを簡単に記録しておく。 - 何があってもリリースを2～3回出す （コミュニティの俗説で、公開されたノルマはない）
変更をでっち上げず、リリース回数で承認が得られるとは期待しない。
この助言の出どころ：私たちが確認できた最も古い明示的な例は、2024年10月の議論で、ある開発者が「2～3回更新すれば、フィードバックに基づいて作業したことをGoogleに示せるかもしれない」と推測したものです。この話は数週間のうちにコミュニティのスレッドで繰り返され、その後、Googleの推奨であるかのようにガイド記事に載るようになりました。元の出典は不明で、何度か更新した場合でも更新しなかった場合でも審査落ちの報告があるため、リリース回数だけでは何も証明できません。
テストで実際の問題が見つかったら、修正してビルドを出し、テスターに再テストを依頼してください。見つからなかった場合は、製品版へのアクセスの質問票に回答する際に、そのとおり正直に書いてください。更新が審査中の間に見た目だけのビルドをアップロードすると、審査の順番が後ろに戻ることもあります。Googleは最後に提出された変更から審査時間を数えるためです。
壊れたアップデートは間接的に時計をリセットする？
はい。ここが本当に重要な例外です。更新という行為そのものがタイマーを直接リセットすることはありませんが、壊れた更新の結果としてリセットされ得ます。連鎖は次のとおりです。
ルールはシンプルです。自由に更新してよいが、クローズドトラックへ出す前に最低限の安定性を確認すること。そしてちょうどテスター12人で走らないこと。壊れたビルドからの1人のオプトアウトで沈み得るからです。12人を超えるバッファがそのリスクを吸収します。
この連鎖を正しく読んでください：更新によって誰かのオプトイン期間がやり直しになるわけではありません。遅れの原因は要件を満たすテスターを失ったことで、壊れたビルドはオプトアウトのきっかけにすぎません。ビルドを安定させ、バッファを保てば、この間接的なリスクはずっと小さくなります。
アップデート後、再インストールや再オプトインは必要？
いいえ。オプトインしてアプリをインストールした既存のテスターは、通常、Google Play経由でそのまま更新されます。再びオプトインする必要はなく、リンクを再送する必要もありません。
更新は通常そのままインストールされる
GoogleのPlay Consoleヘルプ「オープン、クローズド、または内部テストの設定」（answer 9845334）は次のように述べています。「テスターがアプリをインストールすると、数分以内に自動的にテスト版へ更新されます。」テスターはビルドをまたいでオプトインを維持します。再インストールも、オプトインの再クリックも不要です。
同じGoogleページのタイミング上の注意：追加の変更を公開したとき、端末への自動更新が始まるまで「数時間、テスターに届かない場合がある」とあります。しかし14日間の時計が測るオプトイン状態は、新しいAABをまたいでも引き継がれます。だからビルド更新で時計がリセットされないのです。テスターは一度も離れていません。
重要な例外 新しい権限はサイレント更新を妨げ得る
サイレントに届かないビルドが1種類あります。ACCESS_FINE_LOCATION、カメラ、マイクなど危険（機密）な権限を新たに足す更新です。権限とターゲットAPIレベルによっては、Google Playがバックグラウンドではなく、テスターがタップして承認する更新を表示することがあり、無視した人は古いビルドのままです。サイレントに入っても、新しい権限は実行時に付与されるため、許可されるまで権限依存の機能が壊れているように見えることがあります。
クローズドテストでは、これが気づきにくい落とし穴になります。テスト途中で権限の多い更新を出すと、一部のテスターが古いビルドのままになったり、権限を許可するまで機能が使えなかったりすることがあります。リスクの高い新しい権限を追加すると、そもそもビルドを公開する前にPlay Consoleで権限の申告が必要になる場合もあります。端末上での実行時の同意と、Consoleでの申告は別々のチェックです。
テスト途中でロールアウトする前に：新しいマニフェストの権限を現行ビルドと比較してください。権限セットが変わった場合、Playストアを開いて手動で更新し（新しいプロンプトも許可するよう）テスターへ連絡し、申告審査の可能性も見込んでください。
クローズド テストでよくある誤解を解く
更新まわりの不安の多くは、数個の誤解に帰着します。開発者の睡眠をいちばん奪う5つと、実際のところは次のとおりです。
誤解1「新しいリリースを作ると時計がリセットされる。」
誤解2「アンインストール＝オプトアウト。」
誤解3「14日間は累積。」
誤解4「ちょうどテスター12人で足りる。」
誤解5「テスターは毎日アプリを使わなければならない。」
時計をリセットするもの／しないもの
この問いを一画面にまとめました。保存し、スクショし、チーム内で繰り返し聞かれる人に送ってください。ビルドに関することは安全で、テスター人数に関することだけが危険です。
| 操作 | 14日間をリセット？ |
|---|---|
| 同じクローズドトラックへ新しいAABをアップロード | いいえ |
| リリースノートやストア掲載メタデータの編集 | いいえ |
| テスターからのフィードバック | いいえ |
| テスター端末でのクラッシュ | いいえ |
| テスターのアンインストール（オプトアウトなし） | いいえ* |
| オプトイン済みが12人未満になる | はい |
| Webリンクからの正式なオプトアウト | はい** |
| オプトアウトを招き12人割れを起こす壊れたビルド | 間接的に |
| クローズド テストトラックの一時停止 | 報告されるリスク |
| テスターリストを上書きしアクティブを外す | 報告されるリスク |
* オプトアウトではありませんが、アプリをインストールしていないテスターはテストをしていないことになります。** 要件を満たすテスターが12人未満になる場合のみ。ここでの「はい」は、最短の申請日が後ろにずれることを意味します。残ったテスターは日数を保ちますが、補充したテスターは1日目から始まります。GoogleはCSVのアップロードで以前のリストが上書きされること、テストの一時停止でそのテストへの更新が止まることを説明していますが、その後の日数の数え方は説明されていないため、最後の2行は「リスクを取らない」ものとして扱ってください。
要件はこれまでどう変わってきたか
古いチュートリアルを読むと人数が合わないのはこのためです。期間はずっと14日間連続で、動いたのはテスター人数だけです。
2023年11月より前は、製品版に進むための必須クローズド テストはありませんでした。テスターを集めなくても公開できました。
Googleは2023年11月9日にこの要件を発表しました。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%（過去実績）、アプリ12,100+件、テスト開始は通常4～6時間以内です。
Play Consoleに当社のテスターを追加し、テスト用URLを共有すれば、14日間が始まります。あとは必要なときに更新を出せます。改善を重ねている間も、テスターはオプトインしたままです。
最低12人を上回るプランなら、同じ日に開始する追加のテスターが加わるため、壊れたビルドが原因のものも含め、1人がオプトアウトしても12人を割ることはありません。バッファが役に立つのは、そのテスターが早めにオプトインした場合だけです。後から補充したテスターは、その人自身の14日間から始まります。料金はアプリごとで、決済時に別途サービス手数料5%（最低$1.50）がかかります。
よくある質問
クローズド テスト中にアプリを更新しても、14日間はやり直されませんか？
はい。同じアプリを進行中のクローズドトラックで通常どおり更新しても、それだけでテスターのオプトイン期間がやり直しになることはありません。既存のテスターが資格を保ち、オプトインを続けている状態を維持してください。新しいビルドは、テスターがインストールできるようになる前に審査と公開が必要な場合もあるため、配信状況はテスト要件とは別に確認してください。
クローズド テストの時計をリセットするものは何ですか？
Googleは、Consoleのあらゆる操作を網羅したリセットのチェックリストを公開していません。要件が対象とするのは、各テスターの連続したオプトインです。いったん抜けて再参加したテスターは、その人自身の14日間を最初からやり直します。要件を満たすテスターを十分な人数失うと、申請が遅れることがあります。新しく補充したテスターは1日目から始まります。通常のビルド更新は、これとは別の出来事です。
招待済みテスターとオプトイン済みテスターの違いは？
招待済みとは、アカウントがテスターリストまたはGoogleグループに登録されている状態です。オプトイン済みとは、テスターがそのアカウントでテストリンクを開き、テストに参加した状態です。アドレスを登録しただけでは登録は完了しません。テスターにアカウントを確認してもらい、インストールしてアプリを使い、意味のあるフィードバックを送ってもらってください。
アップデート後、テスターは再オプトインが必要ですか？
通常は不要です。資格のある既存のテスターは、同じテストに再参加しなくても、Google Play経由で通常の更新を受け取ります。登録状態はそのままにして、掲載ページとインストールされているビルドを確認してもらってください。自動インストールは、リリースが利用可能になっていることと端末の設定に左右されるため、全テスターに数分以内に更新が届くとは約束しないでください。
アンインストールはオプトアウトと同じですか？
いいえ。アンインストールは端末からアプリを削除することで、オプトアウトはテストへの参加状態を変えることです。今日のインストール数も、今日の招待リストも、連続して登録されていたことの証明にはなりません。また、アンインストールしたテスターはそのインストールでテストできないため、まだテストに参加しているかを確認し、再インストールしてテストを続けてもらってください。
Googleはテスト中のアップデートを求めていますか？
Googleはテスターのフィードバックに対応して問題を修正することを推奨しており、製品版へのアクセスの申請では、テスト後に何を変更したかを尋ねられます。必要なリリース回数は公開されていません。必要なときに役立つ修正を出し、変更点を記録して再テストしてください。「2～3回更新すべき」という俗説を満たすためだけに、見た目だけのリリースを出すのはやめましょう。
クローズド テストに本当に必要なテスターは何人ですか？
2023年11月13日以降に作成した個人用アカウントの場合、最低ラインは、申請時点でそれぞれ直近14日間連続でオプトインを続けているテスター12人です。追加のテスターを早めに集めておくとバッファになります。後から追加した補充テスターは、抜けたテスターの日数を引き継ぎません。また、テスターの人数によって製品版へのアクセスが保証されることはありません。
通過するには更新を2～3回リリースする必要がありますか？
Googleが公開しているガイダンスには、そのようなノルマはありません。問われるのは、テスト、フィードバック、変更点、公開の準備状況です。テストで実際の問題が見つかったら修正し、再テストを記録してください。見つからなかった場合は、テストの内容をありのままに説明してください。リリース回数だけでは、有意義なテストを行った証明にもならず、製品版へのアクセスが許可される保証にもなりません。
リリースは公開済みなのに、テスターがまだ古いバージョンのままなのはなぜですか？
テスターのGoogleアカウント、トラックへの登録状態、ロールアウト率、versionCodeを確認してください。次に、テスターにPlayストアの掲載ページを開いて更新があるか確認してもらいます。自動更新はオフにできるほか、端末の状態によって遅れることもあります。実際にビルドがインストールされたかを確認してください。掲載ページの更新日だけでは不十分です。
「審査中」の間、14日間のテストは一時停止しますか？
審査中の更新は、Googleがそのビルドを処理するのを待っている状態です。Googleは、通常の更新の審査によってテスターのこれまでのオプトイン期間が一時停止するとは説明していません。進行中のテストが引き続き利用可能で、登録状態が保たれていることを確認してください。別の提出を重ねるとリリースの審査が遅れることがありますが、それは連続テストの要件とは別の話です。
更新を受け取るために、テスターはテストを抜けて再参加すべきですか？
いいえ。クローズドテストを抜けて再参加しても更新の問題は解決せず、そのテスターの連続したオプトイン日数が途切れます。まず公開状況、テスターのアカウント、ロールアウト、versionCodeを確認し、そのうえでPlayストアの通常の更新手順を試してください。登録状態が本当に誤っている場合は、そのテスターの14日間にどう影響するかを理解したうえで、別途修復してください。
まとめ
要約
14日間のクローズドテスト中にアプリを更新するのは、安全で、ごく普通のことで、むしろ推奨されています。Googleが測るのは各テスターの途切れのないオプトインなので、同じクローズドトラックへの通常の更新で、テスターの14日間がやり直しになることはありません。本当のリスクは、要件を満たすテスターを失うこと、テスターが正式にオプトアウトすること、テスターが離脱するほど壊れたビルドを出すことです。本物の修正を出し、フィードバックに対応し、早めに集めたバッファでテスター数を守ってください。テスター12人以上のオプトインを維持する手助けが必要なら、PrimeTestLabは実在のテスター12～25人を$19.99から（別途サービス手数料5%、最低$1.50）ご用意し、テストは4～6時間で始まります。テスト期間を終えても製品版へのアクセスが許可されなかった場合は、無料再テストまたは全額返金を選べます。料金プランを見る →