すぐわかる答え
「More testing required」は製品版へのアクセス申請の結果であり、アプリに対するポリシー違反の処分ではありません。Googleは実施したクローズド テストと申請での回答を審査し、アカウント所有者にメールを送ります。審査で十分と判断されなかった場合は、テストの継続を求められます。まずは受け取った判定がどれかを確かめ、次に自分の記録が要件・アプリの利用・フィードバック・準備状況について何を示しているかを整理してください。
これに対して、アプリやリリースが具体的に指摘された問題を理由に却下された場合は、その問題の修正と再提出の手順に従ってください。テスターを増やしても、ポリシー上の判定は解消されません。
この記事は診断のための記事です。受け取った判定はどれか、手元の材料それぞれで何が言えて何が言えないのか、そして再申請の前に何を直すのか。PrimeTestLabが毎週実施しているクローズド テストと、必要な箇所でリンクしたGoogleの案内に基づいています。2026年9月11日時点の内容です。
この記事の読み方
- Googleの必須要件 必ず満たさなければならない資格・提出・ポリシー上の条件です。
- Googleの推奨 Googleが推奨している、または申請で尋ねられる項目です。数値の基準は公開されていません。
- 当社の提案 当社が実施しているテストから得た実務上のやり方であり、評価の基準になるルールではありません。
まず、Googleが却下したものを見極める
「クローズド テストが却下された」と言われる判定には3種類あり、それぞれ必要な対処が違います。実際に受け取った文面と照らし合わせてください。
どのメッセージを受け取りましたか？
| 受け取った内容 | 意味すること | 次にすること |
|---|---|---|
| ダッシュボードにテスト要件が未達と表示される | ダッシュボードが、満たされていないテスト条件を示しています。何を続ける必要があるかを決める前に、表示されている条件そのものを確認してください。 | クローズド テストを完了させます。テスター12人以上が、それぞれ直近14日間連続でオプトインしている状態にします。 |
| 申請後に「More testing required」（追加のテストが必要） | 申請は審査されましたが、まだ承認されていません。Googleはテストの継続を求めています。指摘された懸念点は、判定とアカウント所有者宛てのメールに書かれています。 | 下の5つの領域を順に確認し、見つかった点を直してから、自分のアカウントから再申請します。 |
| アプリまたはリリースが問題を指摘されて却下される | アプリ自体についての判定で、ポリシーまたは品質の問題が明示されています。テスターの人数についての判断ではありません。 | 指摘された問題について、修正と再提出の手順に従ってください。テスターを増やしても解決しません。 |
製品版トラックがロックされているという事実だけでは、残っているのがテスト要件なのか、申請の判定なのか、アカウント側の別の手続きなのかは分かりません。ロックではなく、実際に受け取ったメッセージを手がかりに進めてください。
出典：アプリのテスト要件と製品版へのアクセス、およびアプリの公開と審査状況。
この要件が自分に当てはまるかを確認する
Googleの必須要件この要件の対象は、2023年11月13日以降に作成された個人用デベロッパーアカウントです。Googleは、これらのアカウントではアプリを公開できるようになる前に所定のテスト要件を満たす必要があるとしています。自分のアカウントが対象なら、次の3つを順に行います。
- 1内部テストだけでなく、クローズド テストを実施します。
- 2テスター12人以上が14日間連続でオプトインしている状態を維持します。
- 3製品版へのアクセスを申請し、テスト、アプリ、準備状況についての質問に答えます。
要件を満たすことは承認ではありません
要件を満たすと、申請できるようになります。申請はそれ自体が審査されるため、14日間を問題なく終えることは手続きの終わりではなく始まりです。詳しくはテスター要件の仕組みをご覧ください。
5分で原因を切り分ける
このリストの横にPlay Consoleを開いて、各質問に正直に答えてください。答えられない項目が、読み始めるべき場所です。
このツールでできること、できないこと
このツールはPlay Consoleのアカウントから何も読み取らないため、テスターの人数やオプトインの日付を確認することはできません。すでに分かっていることを、審査で問われる順番に並べ替えるだけのものです。
次のステップ
「追加のテストが必要」と判断されたあとの手順は、再申請ガイドをご覧ください。診断の結果、人によるテストがさらに必要だとわかった場合は、テストサポートを比較してください。Googleがアプリやポリシーの問題を指摘している場合は、まずそれを修正してください。別のテスターグループを用意しても解決しません。
製品版へのアクセスが却下されたあとに確認する5つの領域
調べられる順に並べた、調査対象の領域です。却下の原因になりやすい順ではありません。その順位を示す公開データはないからです。
テスターの要件または継続性が満たされていない
Googleは直近14日間以上連続でオプトインしたテスター12人以上を求めています。連続性はテスターごとに見ます。オプトインしたあと14日未満でテストをやめてオプトアウトした人は、その途切れた期間については数に入りません。いったん離れたテスターも、あらためて14日間途切れずオプトインすれば、また条件を満たせます。
確認すること
- 使っているのがクローズド テストのトラックであることを確認します。内部テストに参加したままのテスターには、そこから抜けてもらうまでクローズド テストが届きません。
- 数えるのはリストに追加したアドレスではなく、オプトインした人数です。アドレスを追加しただけでは、本人がリンクを承諾するまで何も起きません。
- その前の14日間だけでなく、製品版へのアクセスを申請する時点までオプトインを続けてもらうよう、テスターに依頼します。
例：連続性はテスターごと
15人のテスターが同時に参加して1人が離れた場合でも、残る14人はそれぞれ自分の期間を途切れさせていないため、条件を満たしている可能性があります。あとから入る代わりのテスターは自分のカウントを最初から始め、離れたテスターの経過日数を引き継ぐことはありません。
最低人数に少しだけ上乗せして余裕を持たせます。ちょうど12人でも条件は満たせるため、余裕を見ておくのは、オプトアウトが出ても最低ラインを下回らないようにするための当社のやり方であって、Googleが求めるものではありません。
出典：新しい個人用デベロッパーアカウントのアプリテスト要件、テスターリストとオプトインリンクについてはオープンテスト、クローズド テスト、内部テストを設定する。手順の解説：テスターの招待とオプトインを確認すると内部テストとクローズド テストの違い。
テスターがアプリを実質的に利用していなかった
申請では、テスターが機能を使ったか、その使われ方が製品版で想定している利用に近いかを尋ねられます。Googleは、テスト中のテスターの関与が不十分だった場合にテストの継続を求められることがあるとも述べています。確認した案内にエンゲージメントの数値基準は示されていないため、やるべきことは実際の利用を具体的に説明することです。
同じ数字ではない3つの指標
| 指標 | 何を数えているか | この指標で言えること |
|---|---|---|
| オプトイン済みのテスター | 自分のクローズド テストのオプトインリンクを承諾し、そのままオプトインを続けている人数です。 | 要件を満たすかどうかを決める数字で、3つのうち12人・14日間のルールに結びついている唯一の指標です。 |
| インストール済みユーザー数 | 過去30日間に使用した端末の少なくとも1台にアプリがインストールされているユーザーの数です。 | アプリが実際に使われている端末に届いたことは分かります。誰かがアプリを開いたことまでは示せません。 |
| 1日のアクティブユーザー（DAU） | その日にアプリを開いた人数です。 | アプリが開かれたことは分かります。それでも、どの機能が使われたか、テスターがそれをどう感じたかは分かりません。 |
出典：アプリの統計情報を確認する。Googleは利用データを保有しているので、エンゲージメントがGoogleから見えていないわけではありません。公開されていないのは、審査がどのシグナルをどの水準で重視するかです。
確認すること
- 試してほしい操作フローを挙げた短い案内と、返信先となる窓口を1つ、テスターに渡します。
- 良いか悪いかの結論ではなく、具体的な観察を求めます。何を試し、どの端末で、何が起きたかです。
- 重要な修正をリリースしたら、その箇所をもう一度確認してもらいます。変更を検証した記録が残ります。
アプリにとって重要なタスクを実際に完了してもらい、気づいたことを自分の言葉で報告してもらい、重要な修正が入ったらその箇所を再確認してもらってください。「1日1回アプリを開く」といった決まりごとは、任意のテスト運用であって、Googleのルールではありません。
フィードバックと申請の回答に具体的な裏づけがない
申請では、受け取ったフィードバックと、それをもとに行った変更をまとめて記載するよう求められます。Googleはテストの進行中にフィードバックの傾向を記録しておくことを推奨しており、その記録があるかどうかが、具体的な回答と一般論との分かれ目になります。
テスト記録の例（形式の参考で、内容をそのまま使うものではありません）
| ビルド・操作フロー・環境 | 検出事項 | 対応または検証 |
|---|---|---|
| ビルド8、パスワード再設定、Android 14 | 再試行のメッセージが分かりにくい | ビルド9で文言を明確化、テスターが再確認 |
| ビルド9、設定の保存、Android 13 | 再度開いたあとも設定が保持されていた | 問題なしとして記録、変更は不要 |
これは記録の形式の提案で、Googleが求めるテンプレートや提出物ではありません。列は構成の参考として使い、行の内容をそのまま貼り付ける事実として扱わないでください。問題を記録することと同じくらい、問題なく確認できたことを記録するのも重要です。それがあれば、ありもしない問題をつくり出さずに準備状況の質問に答えられます。
確認すること
- Play Consoleの「テストのフィードバック」と、テスターに伝えた連絡窓口を使います。ストアの公開評価はここには含まれません。
- まずフィードバックを傾向ごとにまとめます。声の大きい1件がまとめ全体になってしまうのを防げます。
- テスターの言葉を引用するか正確に要約するかは自由ですが、具体的な観察そのものは残してください。
- 申請に書く機能が、テストしたビルドに実際に含まれていて、実際に操作されたことを確認します。別途テストしたものや、今回のテストの対象外としたものは、その旨を書き添えます。
出典：オープンテスト、クローズド テスト、内部テストを設定すると製品版へのアクセスに関する案内。再利用できる記録のテンプレートは立て直しの記事にあり、製品版へのアクセスの回答を正確に準備するではフォーム自体を順に解説しています。
検出事項に対応していない、または準備状況が不明確
申請では、分かったことをもとに何を変更したかを尋ねられます。Googleはテスト中にフィードバックへ対応することを推奨しています。確認した案内にリリース回数のノルマは出てこないため、重要なのは回答がテストで分かったことを正しく反映しているかどうかです。
変更が必要なかった場合の書き方
テストで直さなければならない点が出てこなかった場合は、確認した操作フロー、実行した端末、結果を記載し、その記録から準備が整ったと判断した理由を説明します。報告する変更をつくるために問題をねつ造したり、見た目だけのリリースを出したりすると、回答はかえって弱くなります。
確認すること
- まず本当の検出事項に対応し、どの修正がどのビルドに入ったかを書きます。
- それぞれの変更を、きっかけになったフィードバックと結びつけます。回答が原因と結果として読めるようになります。
- 重要な問題が未解決のままなら、アプリを準備完了として示す前に解決します。
この回答でつまずくところ
弱い回答は「テストは順調でした」で終わります。強い回答は、何を確認し、何が分かり、何をして、どう検証したかを挙げます。具体的な回答のほうが評価しやすくなります。
アクセス・安定性・機能の問題が残っている
Googleは、クラッシュやフリーズなど正常に動作しないアプリを認めていません。また、審査でアプリにたどり着ける必要もあります。ログインの先にある部分があるなら、使えるログイン情報と手順をリリースに添えてください。
確認すること
- 提出したビルドについて、使える審査用のログイン情報と、制限された機能にたどり着くために必要な手順を用意します。
- テスターがそのビルドをインストールして開けることを確認します。内部テストに残っている人は、まずそこから抜ける必要があります。
- リリース前レポートを実行し、テスターが使った操作フローについてクラッシュとANRのシグナルを確認して、再現できるものを直します。
問題なしのレポートで証明できないこと
リリース前レポートは、処理能力に余裕があるときに自動で生成されます。保護されたコンテンツにたどり着いて対象の操作フローを実行させるには、ログイン情報や個別の設定が必要になることがあります。また、自動テストで問題が出なかったことは、手動テストの代わりにはなりません。Android vitalsは、一部の端末とOSバージョンについて、収集に同意した診断データをもとにしています。そのため、データが表示されない画面は、選択したフィルタの範囲ではデータ件数が少なすぎることを表している場合があります。公開されている望ましくない動作のしきい値は技術的な品質に関するもので、製品版へのアクセスの合格基準ではありません。
出典：機能、コンテンツ、ユーザーエクスペリエンス、審査に向けてアプリを準備する、リリース前レポートで問題を特定する、Android vitalsで技術的な品質を監視する。
それぞれの材料で言えること、言えないこと
どの材料がどの問いに答えるのかが分かると、テスターの問題、裏づけの問題、アプリの問題を切り分けられます。
言えること申請できる状態だったかどうか。テスター12人以上が、それぞれ直近14日間連続でオプトインしていたかです。
言えないことそのうち誰かがアプリを使ったか、回答が十分に具体的だったかは分かりません。
言えること表示されている各日に、何人がアプリを開いたかです。
言えないこと1人が何回開いたか、どの機能を使ったか、使ってどう感じたかは分かりません。
言えること選択した画面には、現在のフィルタでは問題を特定できるだけのデータがないということです。
言えないことアプリがクラッシュしなかったことは示せません。vitalsは一部の端末とバージョンについて収集に同意したデータを使うため、画面が空であっても、それは集まったデータ件数が少なすぎるという意味である場合があり、問題が何も起きなかったことを示すわけではありません。
言えること別の開発者がその文面を報告したということです。判定のかたちを知る参考にはなります。
言えないこと自分のアカウントに何が伝えられたかは分かりません。コミュニティで転載された文面は個々の事例にすぎず、自分の再申請の時期を決める根拠にはなりません。
言えることテスター自身の言葉による、対応もでき説明もできる具体的な観察です。
言えないことそれが広く起きているかは分かりません。1件は手がかりで、複数のテスターに共通する傾向が検出事項になります。
再申請の前に確認すること
Googleの推奨- 1Play Consoleの判定とアカウント所有者宛てのメールを両方読み、自分のアプリに示された指示に従います。
- 2自分のアプリに実際に示された追加のテスト期間があれば、それを最後まで完了させ、その間はクローズド テストのトラックを動かし続けます。
- 3判定で指摘された懸念点の解消を続け、そのうえで自分のアカウントに表示されている手順で再申請します。
決めつけてはいけない2つのこと
期間が書かれていないことは、すぐに再申請してよいという許可ではありません。また、テストを継続するようにという指示は、テスター全員の経過日数が消えた証拠でもありません。確認した公開情報には一律のリセットルールは示されていないため、自分のアカウントに別のことが書かれていない限り、どちらも不明として扱ってください。
Googleは、そのあとの審査は通常7日以内に完了するとしつつ、それ以上かかることもあるとしています。これは審査の話で、その前のテストの話ではありません。手順は「More testing required」の判定後に再申請する方法で解説しています。
出典：製品版へのアクセスの次のステップ。
テスターの関与を保つ方法
Googleの推奨Googleによると、多くの開発者は友人、家族、同僚、コミュニティ、ソーシャルメディアを通じてテスターを集めています。また、想定ユーザーを代表していて、端末固有の問題が見つかる程度に幅のあるテスターが推奨されています。
参加とフィードバックを管理しないと、募集はうまくいきません。仕組みのない14日間の約束は、協力者の1週間にある他のすべてと取り合いになります。気をつけたい参加とフィードバックの問題は次の3つです。
自前で運用するグループが14日間を取りこぼすところ
出典：アプリのテスト要件。Googleがテスターの集め方について説明しているページです。選択肢はテスター12人を正当な方法で集めるで比較しています。
自前で運用するか、運用を任せるか
どちらの方法でも、満たす要件は同じです。違うのは、14日間にわたって人数を見張り、フィードバックを追いかけるのが誰かという点です。
| 申請の結果を左右するもの | 自前で運用するグループ | 運用を任せるテスト |
|---|---|---|
| オプトイン済みのテスター12人を14日間連続で維持する | 自分で見張ります。オプトアウトによって条件を満たすテスターが足りなくなると、要件の達成が遅れることがあります。 | 当社が見張り、名簿を最低人数より多い状態で保ちます。 |
| 実機 | 協力者が持っている端末次第です。 | Android 7から17までをカバーする実機の端末です。 |
| 開始まで | 募集にかかる時間次第です。 | テスターは通常4～6時間以内に開始します。 |
| まとめられるフィードバック | 集め方によって大きく変わります。 | 窓口を1つにまとめて集め、当社から報告します。 |
| 費用 | 無料。ただし14日間、自分の時間がかかります。 | テスター12人で$19.99から。 |
どちらの方法でも、申請の審査のされ方は変わりません。運用を任せれば参加が途切れるリスクはなくなりますが、フィードバックや準備状況の質問に代わりに答えてくれるわけではなく、承認を約束できる人もいません。
テストの支援
当社の提案診断の結果が参加の問題を指しているなら、PrimeTestLabがクローズド テストを代わりに運用します。実機のオプトイン済みテスターが14日間ずっと参加し、人数は最低人数より多く保ち、フィードバックは1か所にまとまります。足りていないのがログインの不具合や、具体的に指摘されたポリシーの問題なら、テスターを増やしても解決しません。
この完了率はGoogleの承認率ではなく、当社の運用実績です。当社が運用したテストが、必要なテスターの人数と途切れないオプトイン期間を終了日まで保てた割合を示しています。
よくある質問
Google Playに「More testing required」と表示されるのはなぜですか？
製品版へのアクセスの申請は審査されましたが、まだ承認されていないため、Googleはテストの継続を求めています。Googleが挙げている例には、オプトイン済みのテスターが12人に満たないこと、クローズド テスト中にテスターの関与が不十分だったことがあります。指摘された懸念点は、Play Consoleの判定とアカウント所有者に送られたメールの両方を読んで確認してください。
テスター12人が14日間連続でオプトインしている必要がありますか？
2023年11月13日以降に作成された個人用デベロッパーアカウントなら、必要です。Googleは、テスター12人以上が直近14日間以上連続でオプトインしているクローズド テストを求めています。ちょうど12人でも条件を満たし、招待したアドレスは本人がオプトインするまで数に入りません。
14日間の途中で1人がオプトアウトしました。最初からやり直しですか？
必ずしもそうではありません。連続性はテスターごとに測るため、自分の期間を途切れさせていない人はそのまま数に入ります。途切れた期間そのものは数に入りませんが、いったん離れたテスターも、あらためて14日間途切れずオプトインすれば、また条件を満たせます。起きないのは引き継ぎです。あとから参加する代わりのテスターは自分の期間を最初から始め、離れたテスターの経過日数を引き継ぐことはありません。
テストで直すべき点が見つからなかった場合は、何と答えればよいですか？
確認した操作フロー、実行した端末、結果を記載し、その記録から準備が整ったと判断した理由を説明してください。確認した案内にリリース回数のノルマは出てこず、テスト中に更新を出さなければならないとも書かれていません。問題をねつ造しても、回答が弱くなるだけです。
却下されたあと、すぐに再申請できますか？
根本原因を直してから、もう一度申請してください。時期は、自分の準備状況で決めます。メッセージには追加のクローズド テスト期間が明記されている場合もあり、テストを継続するようにとだけ書かれ、期間が示されていない場合もあります。期間の記載がないことは、すぐに再申請してよいという許可ではなく、確認した公開情報にも一律のリセットルールは示されていません。
Googleが製品版へのアクセスの申請を審査するのに、どのくらいかかりますか？
Googleは、審査は通常7日以内に完了するとしつつ、それ以上かかることもあるとしています。これは審査だけの話です。その前のクローズド テストは別に14日間連続で必要で、判定で求められた追加のテストがあれば、それもさらに別です。
次にすべきこと
5分でできる診断に戻り、答えられなかった最初の質問を取り上げてください。そこを1つ直し、テストで実際に何が分かったかを書き出し、自分のアカウントに表示されている手順で再申請します。足りていないのが裏づけではなく参加のほうなら、次に申請する前にテスターを手配して、テストの途中で期間が再び途切れないようにします。
まとめ
「More testing required」は、実施したテスト、申請での回答、そしてアプリが準備できているかについての判定です。下限は決まっていて公開されています。2023年11月13日以降に作成された個人用デベロッパーアカウントでは、テスター12人以上が14日間連続でオプトインしていることです。下限を超えた部分については、テストで何が分かったかを回答で正確に説明してください。言葉を整えても、実質的なテストや正常に動くアプリの代わりにはなりません。