Google Play製品版アクセス申請の回答例｜クローズドテスト後

クローズドテストの条件を満たすと、Play Consoleから製品版アクセスを申請できます。

申請では、人数と期間だけでなく、テストをどのように実施し、フィードバックをアプリ改善へどう反映したかを回答します。

製品版アクセス申請で答える内容

14日が終わったら何をする？

14日間が経過しても、その時点で製品版へのアクセスが自動的に与えられるわけではありません。14日が終わったら、次の順で進めます。

Google公式

12人以上のテスターが直近14日間連続でオプトインしていると、Play Consoleのダッシュボードから本番環境へのアクセスを申請できるようになります。

条件の確認 — 12人以上が直近14日間連続でオプトインしている状態かを確認します。途中参加や途中離脱があった場合、テスターごとに14日間連続の完了時点がずれるため、人数表示だけでは判断できません
申請可能かの確認 — Play Consoleのダッシュボードで、製品版アクセスの申請が可能になっているかを確認します
テスト内容の整理 — テスターに確認してもらった内容、受け取ったフィードバック、修正した内容を整理します
ストア情報の準備 — ストア掲載情報、プライバシーポリシー、データ安全性など、製品版公開に必要なポリシー関連の項目を確認します
申請 — 「本番環境へのアクセスを申請」から進みます

申請で聞かれる内容は、次の3セクションに分かれています。

申請フォームの構成

Google公式

条件を満たすと、Play Consoleのダッシュボードから「本番環境へのアクセスを申請」できるようになります。申請フォームは「クローズドテストについて」「アプリ/ゲームについて」「製品版への準備状況」の3セクションで構成され、審査は通常7日以内に完了しますが、それ以上かかることもあります。

セクション	聞かれる内容（公式で確認できる範囲）
クローズドテストについて	テスター募集の難易度、テスターが全機能を使ったか、想定ユーザーに近い使い方だったか、フィードバックの内容と収集方法
アプリ/ゲームについて	対象ユーザー、価値提案、初年度の推定インストール数
製品版への準備状況	テスト結果を受けて変更した内容、製品版の準備ができたと判断した方法

この記事は、この3セクションの順番に沿って回答の作り方を説明します。

セクション1：クローズドテストについて

テスター募集の難易度、テストの実施内容、フィードバックの内容と収集方法を回答します。

募集の難易度

TestCrewの推奨

回答は「簡単だった／大変だった」だけではなく、実際の募集経路と人数の経過を具体的に書くことを推奨します。これはGoogleの指定フォーマットではなく、事実を伝えやすくするための実務上の工夫です。

回答へ含める項目：

テスターの属性
募集経路
対象端末
参加時に伝えた条件
テストを継続してもらう方法

回答例

以下の例はそのままコピーせず、実際に行ったテスト内容へ置き換えてください。実在しない募集経路や人数を書かないでください。

個人のAndroidアプリ開発者と、アプリの想定利用者に近い協力者を対象に募集しました。
参加者には、登録したGoogleアカウントでクローズドテストへオプトインし、Playストアからアプリをインストールしてもらいました。
新規登録、ログイン、データ保存、履歴表示を確認項目として伝え、テスト期間中は参加状態を維持してもらいました。

実際に知人だけで募集した場合は、開発者コミュニティと書かないでください。

全機能を使ったか・想定ユーザーに近い使い方だったか

確認した機能や端末条件を具体的に書きます。確認できていない機能がある場合は、それも事実として書きます。

回答例

以下は必ず自分の実施内容に置き換えてください。実施していない確認を書かないでください。

テスターには、初回起動、新規登録、ログイン、写真の保存、保存履歴の編集と削除、アプリ再起動後のデータ表示を確認してもらいました。
複数のAndroidバージョンと異なる画面サイズの端末で操作してもらい、問題が発生した場合は端末名、Androidバージョン、再現手順を共有してもらいました。

フィードバックの内容と収集方法

収集方法（メール、フォーム、Playの非公開フィードバックなど）と、実際に受け取った内容を書きます。「好評だった」だけではなく、改善につながる意見を書きます。

回答例

受け取っていないフィードバックを書かないでください。数値も実測値に置き換えてください。

保存操作の完了が分かりにくい、ログイン失敗時のメッセージから次の操作が判断しにくい、小さい画面で一部の説明文が折り返されるというフィードバックがありました。
一方で、主要な保存・編集機能は指定した端末で正常に利用できることを確認しました。

セクション2：アプリ/ゲームについて

対象ユーザー、価値提案、初年度の推定インストール数を回答します。初年度の推定インストール数は、数値を文章で書く項目ではなく、初年度の推定インストール数の範囲をPlay Consoleに表示される選択肢から選択する形式です。

対象ユーザー・価値提案

回答例

対象ユーザーと価値提案は、ストア掲載情報と矛盾しない内容で書きます。

対象ユーザー：
20〜40代の2人世帯を想定しています。

価値提案：
共通支出の入力と確認を1か所で行い、家計共有の手間を減らします。

初年度の推定インストール数

見積もり根拠を記述する欄ではないため、文章例は不要です。自分のアプリの実態に近い範囲を選択してください。

セクション3：製品版への準備状況

テスト結果を受けて変更した内容と、製品版の準備ができたと判断した方法を回答します。

テスト結果を受けて変更した内容

回答例

実際に実施した修正だけを書いてください。行っていない修正を書かないでください。

保存完了後に確認メッセージを表示し、保存ボタンの状態を変更しました。
ログインエラー文を、原因と再試行方法が分かる内容へ修正しました。
小さい画面でのレイアウトを調整し、修正版を同じクローズドテストへ公開してテスターに再確認してもらいました。

「改善予定」だけでなく、実施済みの変更と再確認結果を分けます。

準備ができたと判断した方法

回答例

利用していないサービスや実施していない監視方法を書かないでください。

クローズドテストで確認した主要機能について、致命的な問題がないことを確認しました。
テスターから報告された操作上の問題を修正し、更新版で再確認しました。
プライバシーポリシー、問い合わせ方法、データの削除方法、アプリ内の権限説明も確認しています。
今後もCrashlyticsとユーザーフィードバックを確認し、問題があれば更新します。

回答を作るための記録

回答例を自分の内容へ置き換えるために、テスト中から次の記録を残します。

項目	記録例
テスター数	14人
対象期間	8月1日〜8月16日
Android版	12〜16
主な機能	登録、保存、編集、削除
フィードバック	8件
修正	文言2件、UI2件、不具合1件
再確認	versionCode 43で完了

件数を誇張する必要はありません。少数でも具体的な内容が重要です。

避けたい回答

12人が14日間テストしたので問題ありません。

すべて正常です。バグはありません。

多くのユーザーから高評価でした。

これらは、何を確認したのか、どのように改善したのかが分かりません。

回答を短くする場合

入力欄の文字数に合わせ、次の4点を残します。

誰に何を確認してもらったか
どんな問題や意見があったか
何を変更したか
修正版をどう確認したか

申請前チェックリスト

12人以上が14日間継続して参加した
テスト内容を記録した
具体的なフィードバックがある
修正内容を説明できる
再確認した内容がある
回答が実際のアプリと一致している
ポリシー・プライバシー設定を確認した

TestCrewで下書きを作る

TestCrewに掲載・テストの記録がある場合、Web版TestCrewのMy Appsにある「本番環境の申請文を作成」から、テスト結果やフィードバックをもとにした回答の下書きを生成できます。

TestCrewの推奨

生成された下書きは必ず確認・編集してから申請に使ってください。AIや自動生成された文面も、実際のテスト記録と一致するか確認する必要があります。存在しないテストやフィードバックが含まれたまま提出しないでください。

機能の詳細は、本番環境アクセス申請の下書き作成機能の更新情報を参照してください。

まとめ

製品版アクセス申請では、3セクションの質問に対して、実施したテストの事実を順に回答します。

実際のテスターに主要機能を確認してもらった
→ 問題と改善点が見つかった
→ アプリを修正した
→ 更新版で再確認した
→ 製品版公開後の対応準備も確認した

回答例はあくまで構成の参考であり、実際のテスト内容・フィードバック・修正と置き換えて使ってください。

申請後に「さらにテストが必要」と案内された場合は、再申請の改善手順を確認してください。

一次情報

公式参考資料

新しい個人デベロッパーアカウントのアプリテスト要件

Google PlayやFirebaseの画面・要件は変更される場合があります。公開作業の前に、リンク先の最新情報も確認してください。