要件ガイド
製品版へのアクセス申請アンケートの答え方(設問別の回答例)
クローズド テストを終えて製品版へのアクセスを申請すると、テストに関する質問に回答する必要があります。人が読んで判断するため、回答が不十分だと却下されます。Google が尋ねる 3 つのパートの設問を 1 つずつ取り上げ、弱い回答と良い回答を並べて、何を書くべきかをまとめました。
最終確認日 2026/09/20。
1. アンケートでは何が見られるのか
クローズド テストの 14 日間を満たすと、Play Console で製品版へのアクセスを申請できます。このときクローズド テストに関する質問に回答する必要があり、Google はその回答を人が読んで審査します。審査は通常 7 日以内に終わります。
ポイントは 1 つです。テストを形だけ済ませたのではなく、実際に行ったかどうかが見られます。そのため “テストを無事に終えました” のような文は何の情報も与えないので弱い回答になり、何を確認して何を直したのかが入ってはじめて強い回答になります。
2. ステップ 1: クローズド テストについて
テストをどのように進めたかを尋ねるステップです。4 つのことを尋ねられます。
テスターの募集は難しかったか
難易度を尋ねる質問なので、正解はありません。正直に書きつつ、どのように集めたかを 1 行添えれば十分です。
この書き方では弱い
いいえ。簡単でした。
このように書くとよい
簡単ではありませんでした。知人やコミュニティだけでは人数が足りず、実機テスト サービスもあわせて利用して 12 人以上を確保しました。
テスターはアプリのすべての機能を使ったか
すべて使ったと言い切るより、どこまで確認できたかを区別して書くほうが信頼されます。使えなかった機能があれば、その理由まで書くとよいでしょう。
この書き方では弱い
はい、すべての機能を使いました。
このように書くとよい
初回起動から主要な画面(ログインなしで使えるホーム・一覧・詳細)までは、すべてのデバイスで確認しました。決済とプッシュ通知は実際のアカウントが必要なため、デベロッパーのアカウントでのみ確認しました。
テスターの使い方は実際のユーザーに近かったか
この書き方では弱い
はい、近いです。
このように書くとよい
インストール後に毎日アプリを起動してホーム画面に入るまでを確認する方式だったため、1 日に何度も長時間使う実際のユーザーとは使用時間に差があります。その代わり、さまざまなメーカー・OS バージョンで初回起動が正常かを繰り返し確認しました。
どのような意見をどのように集めたか
最も重要な質問です。集めた方法と 集めた内容を分けて書きます。
この書き方では弱い
テスターはよく動くと言っていました。
このように書くとよい
デバイスごとの実行記録と実行画面のキャプチャで確認し、失敗した実行はエラーコードとデバイスのモデルをあわせて記録しました。Android 11 のデバイス 2 台で、初回起動時に権限リクエストの画面が背面に隠れてしまう問題を見つけました。
3. ステップ 2: アプリについて
アプリそのものに関する質問です。ターゲット ユーザー、アプリの価値、リリース後 1 年間の予想インストール数を尋ねられます。ここはテストとは関係がないので、宣伝文句ではなく事実を書けば大丈夫です。
- ターゲット ユーザー — “朝起きるのが苦手な 20〜30 代の会社員”のように絞り込んで書きます。“すべてのユーザー”は避けます。
- アプリの価値 — 競合アプリと何が違うのかを 1 文で。機能を並べるより、“何を代わりにやってくれるのか”で書きます。
- 1 年目の予想インストール数 — 範囲で回答します。誇張しないほうが賢明です。根拠のない大きな数字は、準備状況への疑いを招きます。
4. ステップ 3: 製品版の準備状況
テストでわかったことをアプリにどう反映したかを尋ねられます。承認されるかどうかが最も分かれるポイントです。
この書き方では弱い
バグを修正して安定化しました。
このように書くとよい
テスト中に 3 回アップデートしました。1.0.3 では Android 11 で権限の画面が隠れる問題を修正し、1.0.4 では初回起動の読み込みが長いという点を受けてスプラッシュ画面を短くしました。1.0.5 では低スペックのデバイスでのメモリ使用量を抑えました。
バージョン番号と何を直したかがそろっていれば、審査担当者が確認できます。そのため、テスト期間中に 3〜4 日おきにアップデートを公開しておくことが、この回答を書くうえで大いに役立ちます。
5. 回答を書く前に集めておく資料
アンケートを記憶だけで書くと、内容が漠然としてしまいます。次の 5 つを先に集めておけば、質問ごとにそのまま書き写せます。
- テストの開始日と終了日、その間に維持されたインストール済みデバイスの数
- テスト中に公開したバージョンの一覧と、各バージョンで変更した内容
- 実行に失敗したデバイスと、そのときのエラー・OS バージョン
- 初回起動画面のキャプチャ(権限リクエスト・オンボーディングが正常であることを示す資料)
- 確認できなかった機能とその理由
6. 書いてはいけない回答
- なかったフィードバックを作り上げる。“テスター 12 人が UI が使いやすいと言った”のように確認できない文を作って書くと、問題になったときにアプリではなくアカウントが危険にさらされます。
- すべての質問に “はい” とだけ書く。困ったことが 1 つもなかったという回答は、かえってテストをしていないように見えます。
- コピーしたテンプレートをそのまま出す。同じ文が複数のアプリで繰り返されれば、審査担当者は気づきます。
- 機能を並べて分量を稼ぐ。尋ねられているのは機能の一覧ではなく、テストで何を学んだかです。
よくある質問
- アンケートを代わりに書いてくれるサービスを使ってもよいですか?
- おすすめしません。なかったテスターの体験を作り上げて提出するのは Google に虚偽の情報を出すことであり、問題になった場合はアプリではなくデベロッパー アカウントが危険にさらされます。実際に起きたことを根拠にご自身で書くほうが安全で、承認される可能性も高くなります。
- 英語で書く必要がありますか?
- 日本語で書いてもかまいません。ただし文章が長くあいまいだと伝わらないので、数字と具体的な事実を中心に簡潔に書くのがおすすめです。
- テスターから実際にはフィードバックがなかった場合、何を書けばよいですか?
- 受け取っていないフィードバックを作り上げず、実際に行ったことを書きます。たとえば、デバイスごとの実行で確認したエラー、クラッシュログ、インストールに失敗したデバイスの OS バージョンなど、テストの過程で観察した事実も十分な根拠になります。
- どれくらいの長さで書けばよいですか?
- 分量より具体性です。質問ごとに 3〜5 文で十分で、数字(デバイス数、期間、バージョン数)と実際の変更内容が入っているかが重要です。
- 却下されたら最初からやり直しですか?
- 却下の理由によります。アンケートの内容が不十分で却下された場合は補足して再申請できますが、テスト自体が要件を満たしていなかった場合は、クローズド テストをさらに続ける必要があることがあります。
テスターを集めずに要件を満たすなら
DUIRE は実際の Android デバイスでクローズド テストに参加し、14 日間毎日アプリを起動します。アプリの登録とインストール可否の確認は、お支払いなしで行えます。