本番アクセス申請が却下された時の原因と対策・アンケート回答のコツ

Google Playの本番環境へのアクセス申請が通らなかった場合、主な原因は「オプトインしたテスターが12人未満だった」か「テスターのエンゲージメントが不十分だった」のどちらかです。公式ヘルプでも、審査後にこれらの理由でクローズドテストの継続を求められることがあると説明されています。対策は、テスターに実際にアプリを使ってもらい、テスト期間中にアップデートを重ね、その経緯をアンケートで具体的に書くことです。この記事では、却下されたときに確認すべきポイントと、アンケート3パートの答え方を整理します。

> 前提: クローズドテストの全体像は Google Playクローズドテスト 完全ガイド をご覧ください。

却下（テスト継続）になったときに最初にやること

1通のメールを読み直す

審査が終わると、Googleからアカウント所有者にメールが届きます。却下時のメールには、テストを継続する必要があることや、その理由の方向性が書かれています。まずは感情的にならず、どの要素が足りないと言われているのかを確認しましょう。

ダッシュボードの数字を確認する

Play Consoleのダッシュボードで、次の点を確認します。

• 現在オプトインしているテスターが12人以上いるか
• その12人以上が、直近14日間連続でオプトインしているか
• クローズドテストトラックのリリースが「公開中」になっているか

「申請時点では12人いたが、その後数人がオプトアウトしていた」というケースは珍しくありません。

クローズドテストを止めない

再申請に向けて、クローズドテストトラックはそのまま継続します。トラックを一時停止したり、テスターリストを大きく入れ替えたりすると、14日間のカウントがやり直しになるテスターが増えてしまいます。

却下の主な原因

公式に明示されている理由と、そこから考えられる具体的な原因を分けて見ていきます。

原因1：オプトインしたテスターが12人未満

最もわかりやすい原因です。次のようなパターンがよくあります。

• メールリストには12人以上いるが、実際にオプトインしたのは10人程度だった
• 途中でオプトアウトした人がいて、14日連続の人数が12人を割っていた
• 途中で追加したテスターの14日がまだ経過していなかった

対策は単純で、12人より多めのテスターを確保し、全員が14日連続で残っている状態で申請することです。

原因2：テスターのエンゲージメントが不十分

公式ヘルプで明示されているもう一つの理由です。Googleが具体的な判定基準を公開しているわけではありませんが、アンケートで「テスターが利用可能な機能をすべて使ったか」「本番ユーザーの想定と比べてどうだったか」を聞かれることから、アプリが実際に使われたかどうかが重視されていると考えられます。

ありがちなのは次のような状態です。

• オプトインとインストールだけしてもらい、ほとんど起動されていない
• テスターに何を試してほしいか伝えておらず、主要機能が使われていない
• テスト期間中に一度もアップデートを配信していない

原因3：アンケートの回答が抽象的

公式ヘルプが「却下理由」として明示しているわけではありませんが、アンケートの回答は審査の材料になります。「問題はありませんでした」「多くの人が使いました」のように中身のない回答では、テストを通じてアプリが改善されたことが伝わりません。

原因4：アプリの情報とリリース内容が食い違っている

ストアの掲載情報、アプリの説明、アンケートで書いた想定ユーザーや機能が、実際のアプリと合っていないケースです。たとえば、アンケートで「ユーザーが写真を共有できる」と書いているのに、テスト版にその機能がない、といった状態は避けましょう。

アンケート3パートの答え方

公式ヘルプによると、申請時の質問は3つのパートに分かれています。それぞれ、何を書けばよいかを見ていきます。

パート1：クローズドテストについて

主な質問は次のとおりです。

• テスターを集めるのは簡単だったか
• テスターは利用可能な機能をすべて使ったか
• テスターの使い方は、本番ユーザーに想定している使い方と同じだったか（異なる場合はどう違ったか）
• テスターから得たフィードバックの概要と、その収集方法

ここでは事実ベースで具体的に書くことが大切です。たとえば次のような書き方が考えられます。

> 回答例：テスターには、メインの記録機能・カレンダー表示・データのエクスポートの3つを重点的に試してもらうよう依頼しました。フィードバックはアプリ内のフォームとメールで受け付け、起動時の読み込みが遅いという指摘が複数あったため、2回目のアップデートで初期化処理を見直しました。

数字を書く場合は、実際に確認できた数字だけを使いましょう。テストログやクラッシュレポートを見れば、どの端末で何が起きたかを根拠として書けます。

パート2：アプリ・ゲームについて

• 想定しているユーザー層
• アプリが提供する価値
• 1年目の想定インストール数の範囲

想定ユーザーは「誰でも」ではなく、「毎日の家計を手軽に記録したい20〜40代の会社員」のように具体的に書きます。インストール数の見込みは、選択肢の中から現実的な範囲を選びます。過大な数字を選んでも有利になるわけではありません。

パート3：本番環境の準備状況

• クローズドテストで見つかった問題に対して行った変更
• 本番公開の準備ができたと判断した根拠

ここは、テスト期間中のアップデート履歴がそのまま材料になります。

> 回答例：テスト期間中に3回アップデートを配信しました。1回目でAndroid 14端末での起動時クラッシュを修正し、2回目で読み込み速度を改善、3回目で設定画面の文言を分かりやすく変更しました。最終版では主要機能でクラッシュが報告されておらず、テスターからの指摘にもすべて対応したため、公開の準備が整ったと判断しました。

書くときの注意点

• テンプレートをそのまま貼らず、自分のアプリの実際の内容に合わせる
• 確認していない数字や評価を書かない
• 「バグはありませんでした」より「見つかった問題と対応」を書く
• 日本語でも英語でも構わないが、読みやすい文章にまとめる

申請画面では「次へ」や「適用」をクリックせずに離れると入力内容が保存されません。長文になる場合は、別のメモアプリで下書きしてから貼り付けると安全です。

よくある回答のNG例と改善例

抽象的な回答と、具体的な回答の違いを表にまとめました。自分の下書きと見比べてみてください。

ポイントは「何をして、何がわかり、どう変えたか」を一つの流れで書くことです。うまくいかなかった点を正直に書いても、そこからの改善が説明できていれば問題ありません。

ストア掲載情報も見直す

アンケートだけでなく、ストアの掲載情報も審査の前に見直しておきましょう。次のような点がそろっていると、アプリの内容が伝わりやすくなります。

• アプリ名と短い説明が、実際の機能を正しく表している
• 詳しい説明に、主な機能と使い方が書かれている
• スクリーンショットが最新版の画面になっている
• プライバシーポリシーのURLが有効で、アプリの内容と合っている
• データセーフティの申告内容が、アプリが実際に扱うデータと一致している

テスト期間中に画面や機能を大きく変えた場合は、スクリーンショットや説明文も忘れずに更新しましょう。

却下後の再申請までの流れ

却下の連絡を受けてから再申請するまでは、おおむね次の順番で進めると無駄がありません。

• 審査結果のメールを読み、足りないと指摘された点を把握する
• ダッシュボードでオプトイン人数と、14日連続の状態を確認する
• 人数が足りなければテスターを補充し、補充した人の14日経過を待つ
• テスターに試してほしい機能を改めて伝え、アップデートを配信する
• 記録をもとにアンケートを書き直し、再申請する

焦って同じ内容で再申請するより、指摘された点を一つずつ解消してから申請したほうが、結果的に早く公開できることが多いです。

テスト期間中の記録の残し方

アンケートを具体的に書けるかどうかは、テスト期間中にどれだけ記録を残したかで決まります。難しいことをする必要はなく、次のような項目を日付ごとにメモしておくだけで十分です。

Play Consoleの「Android Vitals」でクラッシュやANR（アプリが応答しない状態）の発生状況を確認できる場合は、その推移も記録しておくと、修正の効果を説明する材料になります。

記録は申請のためだけのものではありません。本番公開後に同じような不具合が報告されたとき、過去の対応を振り返る手がかりにもなります。

再申請までのチェックリスト

アップデートの回数とタイミング

アップデートの回数に公式の基準はありません。ただ、アンケートで「テストで見つかった問題への変更」を聞かれる以上、テスト期間中に一度も更新がないと回答が書きにくくなります。目安としては、14日間で2回以上、理想は3〜4日おきに3〜4回程度、小さな改善でも配信しておくと、変更履歴として説明しやすくなります。

アップデートのたびに、何を直したかを1〜2行で記録しておきましょう。それがそのままパート3の回答になります。

審査期間の目安

公式ヘルプでは、審査は通常7日以内に完了し、それ以上かかる場合もあるとされています。審査中もクローズドテストは継続しておきましょう。却下された場合にすぐ再申請できる状態を保てます。

再申請を楽にするための外部サービス

却下の原因の多くは「人数の維持」と「テスト期間中の継続的な利用・更新」です。これを手作業で回すのが大変な場合は、自動化サービスを使う方法もあります。

Doply では、最低14名（通常16名）のテスターアカウントと36台の実機で、毎日アプリの新バージョンを確認して自動更新し、アプリの起動を続けます。テスト期間は予備日を含めて18日間維持され、テストログと本番申請アンケートの下書きも用意しています。ただし、Doplyを使っても本番アクセスの承認が保証されるわけではなく、アップデートの配信やアンケートの最終確認は開発者ご自身で行う必要があります。詳しくは ご利用ガイド をご覧ください。

よくある質問（FAQ）

Q. 却下されたら、また14日間待つ必要がありますか？

12人以上のテスターが直近14日間連続でオプトインしていれば、追加で待たずに再申請できる場合があります。テスターが入れ替わった場合は、新しく入った人の14日が経過するまで待つ必要があります。

Q. 却下の具体的な理由は教えてもらえますか？

審査結果のメールで、テストの継続が必要な理由の方向性が示されます。公式ヘルプには、テスターが12人未満の場合やエンゲージメントが不十分な場合などが挙げられています。

Q. アンケートは英語で書いたほうが有利ですか？

公式に「英語のほうが有利」とする記載は見当たりません。言語よりも、内容が具体的で事実に基づいていることが大切です。

Q. 却下された後、テスターに改めてお願いすることはありますか？

テスターが引き続きオプトインした状態を保ってもらうよう、一言伝えておくと安心です。あわせて、まだ試してもらっていない機能があれば、具体的に試してほしい内容を伝えると、次の申請でエンゲージメントの説明がしやすくなります。

Q. 審査中にアップデートを配信しても大丈夫ですか？

クローズドテストトラックへのアップデート配信は、審査中でも続けて構いません。むしろ、テストを継続して改善を重ねておくと、再申請が必要になったときにアンケートで説明できる材料が増えます。

Q. 何回まで再申請できますか？

再申請の回数制限について、公式ヘルプに明確な記載はありません。回数を重ねるより、却下の原因を一つずつ解消してから申請するほうが確実です。