本文へスキップ

回答ワークブック · 2026

製品版アクセス質問票の回答例 | Google Play 2026

製品版へのアクセスを申請するときに表示されることのある質問について、回答例とカスタマイズの手引きをまとめました。

9 初回申請の質問数
1 再申請で報告された質問数
<300 各例の文字数
2026年版のGoogle Play製品版アクセス質問票の回答ワークブック。各項目を自分のクローズド テストの記録から書き起こす流れを示しています
Google Playの製品版アクセス質問票:各項目を自分のテスト記録から書き起こすためのワークブック

要点

回答は募集、テスト、フィードバック、変更、準備状況の記録から書きます。以下の例は下書きの型として使い、事実はすべて自分のものに置き換えたうえで、自分のPlay Consoleのフォームに表示される文言と文字数制限に従ってください。

フォームが尋ねるのは、いま終えたテスト、作ったアプリ、そして公開するという判断です。このページでは項目ごとに下書き例を示し、証拠が乏しいとき、数値ではなく声しかないとき、コードを一行も変えずに終わったときに何を書くかまで扱います。

製品版アクセス質問票とは?

クローズド テストが条件を満たすと、アプリのダッシュボードに「製品版へのアクセスを申請」(Apply for access to production)が表示されます。このパネルにはまだ満たしていない条件が並び、質問のプレビュー(Preview questions)へのリンクもあるので、始める前にフォームの中身を読めます。Googleが尋ねるのは次の3つのセクションです。

セクション1 クローズド テストについて テスターをどう集めたか、それがどれくらい大変だったか、テスターが何をしたか、どんな声が届いたか。
セクション2 アプリ・ゲームについて 誰のためのもので、その人に何をもたらし、初年度のインストール数をどのくらい見込んでいるか。
セクション3 製品版への準備状況 テストで何が変わったか、そして公開できると判断した根拠。
Play Console · 製品版へのアクセスを申請 Play Consoleの「製品版へのアクセスを申請」パネル。クローズド テストの条件と質問のプレビューへのリンクが並び、カウンターにはテスター12人が12日間連続でオプトイン中と表示され、製品版へのアクセスを申請するボタンはグレーアウトしている
当社が関わっているPlay Consoleのアカウントで実際に表示されたパネルです。カウンター(ここでは「12日間連続」)が両方の条件を満たすまで、製品版へのアクセスを申請するボタンはグレーのままです。Play Consoleの画面は変わるので、仕様ではなく1枚のキャプチャとして扱い、文言は自分のアカウントで確認してください。

Googleは、クローズド テストに関するセクションの目的を、アプリが公開前に十分にテストされていることの確認だと説明しています。セクション2はもっとも軽い部分で、その回答はGoogle Playには表示されず、Play Consoleの機能の利用にも影響しないとされています。

Googleが公開している内容

  • 審査は通常7日以内で、それより長くかかることもあります。
  • 有効なテスターが12人に届かない場合や、テスターがアプリを十分に使っていない場合は、テストの継続を求められることがあります。
  • セクション2の回答は公開されず、機能の利用にも影響しません。
  • 最後まで進めずにフォームを離れると、保存していない回答が失われることがあります。各セクションで「次へ」(Next)を押し、最後に「申請」(Apply)を押してください。

出典:Play Consoleヘルプ「個人用デベロッパー アカウントのテスト要件」。

質問は何問ありますか?

このページでは、初回申請の9問と、テストの継続を求められた開発者から報告されている再申請の1問を扱います。Googleは確定した一覧を公開しておらず、報告される文言、入力形式、表示される質問はアカウントによって異なります。自分のフォームに従ってください。

回答の長さについて

このページの例はすべて300文字未満で、それぞれ文字数を表示しています。その前後に上限があるという開発者の報告もありますが、現時点で共通の上限は確認できませんでした。基準になるのは自分のフォームのカウンターです。回答の長さが結果を左右するという公開された根拠はありません。

どんな証拠を用意すればいいですか?

ここを一度そろえてしまえば、このフォームは書き方の問題ではなくなります。開く前に次の3つを集めてください。このページの内容はすべて、そこから組み立てます。

01
突き合わせる数字

尋ねられる数字を、Play Consoleの参加資格の情報(テスターの人数や継続日数)と自分の記録の両方から拾い、書く内容と食い違わないようにします。

  • 何人がオプトインし、それはいつだったか。
  • 直近14日間、オプトインが途切れず続いたかどうか。
  • 各テスターが最後に使ったのはどのリリースか。

アンインストールは離脱ではありません。アプリを削除したテスターも、オプトインしたままです。離脱は意図的な操作で、テスト参加用リンクか、Play Storeにあるアプリのベータ版の欄から行います(アプリのベータ版プログラムを離脱する)。つまりインストール数は、テストが行われたことも、止まったことも証明しません。

02
テスターが実際にしたこと

形容詞ではなく行動を書きます。完了したフローと、それをどうやって把握したかを控えておいてください。

  • どの中心的なフローが使われたか。登録、主な作業、共有、設定、支払い。
  • アプリがどれくらいの頻度で、どの期間に開かれたか。
  • どこでつまずいたか。分かるなら、どの端末やAndroidのバージョンでか。

数字の出どころを明示してください。テスターの報告にもとづく数と、解析ツールが記録した数は、同じ数字の形をしていても別物です。どちらも使えます。どちらなのかを書いてください。

03
フィードバック、対応、確認

GoogleはPlay Consoleの「テストのフィードバック」ページを案内し、記録を残すことを勧めています。1件につき1行で十分です。

  • フィードバックが届いた場所(Play Consoleのフィードバック、アプリ内フォーム、チャット、メール)。
  • それに対して何をリリースしたか、どのバージョンでか。
  • 直ったことをどう確認したか、どの指摘がまだ残っているか。

9問のうち4問に答えられる記録

必要なのは3列だけです。以下の行は次のセクションで登場する架空のアプリのもので、自分の表はまったく違う中身になります。そこが肝心です。

テストで分かったこと リリースした内容 確認の方法
名簿を編集したあと、シフトのリマインダーが届かなかった。 バージョン1.4.1:名簿の編集後にリマインダーを組み直すよう修正。 報告した2人のテスターが、次の2回のシフトでリマインダーの受信を確認。
通信が遅いと名簿の公開に失敗し、下書きが消えた。 バージョン1.4.2:下書きを端末に保存し、公開が成功するまで再送する。 通信を制限した状態で前後を再テスト。下書きは残った。
画面の小さい端末で週表示が窮屈だった。 未リリース。公開後に対応予定。 未対応。修正済みとはせず、準備状況の回答で残っている項目として挙げた。

詳しい解析データがない場合は?

セッションの解析を取っていなくても、すべての質問に答えられます。できないのは、印象を計測値に見せかけることです。分かっていることを書き、どうやって分かったかを明示してください。「テスター12人のうち10人が、少なくとも1つは名簿を作ったと話してくれた。セッションの解析データはない」は使えますし、確かめることもできます。作り出した平均セッション時間は使えません。

事前起動レポートについても同じです。Googleはこれを自社の端末で行う自動テストだと説明しており、カバーできる範囲にも限界があります(事前起動レポートで問題を特定する)。これが示すのは自動のクロールであって、人によるテストではありません。

Android vitalsにクラッシュが表示されない場合

ダッシュボードが空でも、クラッシュがゼロだったと示したことにはなりません。Android vitalsは対象となる診断データに依存しており、選択したフィルタではデータが不足しているために表示が空になることがある、とGoogleは説明しています(Android vitals)。データが少ない場合は、その限界も書いてください。

回答はいったん別の場所で書く

各セクションで「次へ」を押し、最後に「申請」を押さずにフォームを離れると、入力が失われることがあるとGoogleは注意しています。まずドキュメントに書き、回答どうしを見比べてから貼り付けてください。

まだテスターが必要ですか?

テストを完了している場合は、以下の例を使ってご自身の記録から回答を準備し、各回答が実際の出来事と一致しているか確認してください。まだテスターが必要な場合は、テストサポートを比較してください。PrimeTestLabはテスト後に質問票の回答を提供し、お客様がその内容を確認して申請を提出します。

この回答例の使い方

以下の例に出てくる事実は、すべて架空です。どれも1つの架空アプリの話で、1つのテスト記録が9つの筋の通った回答になる様子が分かるようにしてあります。そのまま提出できる回答はひとつもありませんし、短くしたところで提出できるようにもなりません。

使う前に、名前、数字、日付、機能、分かったことを、すべて自分のものに置き換えてください。「Shiftly」と書いたままの回答や、実際にはそうでないのに14日間でテスター12人と書いた回答は、他人のテストの説明です。

どのバリエーションを選べばいいですか?

既定の下書きは、どれも架空のShiftlyのテストに沿っています。別のタブは状況が違う場合です。別の募集方法、証拠が乏しい場合、種類の違うアプリ。自分のテストに合うものを選び、関連する回答どうしをそろえてください。変更なしの回答は、修正をリリースしたと書くフィードバックや準備状況の回答とは両立しません。ゲームのタブは、別の架空のゲームです。

下書きの読み方

  • このように示した部分は、置き換えるべき事実です。
  • テンプレートとしてコピーを押すと、その一つひとつが角かっこ付きの指示に変わり、できあがった文がそのまま渡ることはありません。
  • 解説は下書きのパネルの外にあるので、編集メモをフォームに貼り付けてしまうことはありません。
  • 文字数が数えているのは例文であって、置き換えたあとの文章ではありません。

説明のための例であり、実在のアプリではありません

Shiftly

小さな店舗やカフェ向けの、架空のシフト管理アプリです。9つの回答の筋を通すためだけに、このページ全体で使います。顧客でも事例紹介でもなく、成果を主張するものでもありません。

  • クローズド テスト テスター12人、14日間連続
  • 中心となるフロー 登録、週の名簿を作る、同僚を招待する、公開する、シフトのリマインダーを受け取る
  • テスト中のリリース 1.4.1と1.4.2
  • 残っている項目 画面の小さい端末で週表示が窮屈

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

このセクションでは、募集、利用の状況、フィードバックを説明します。Play Consoleの参加資格の情報と自分のテスト記録に合わせたうえで、ダッシュボードの数値には表れない活動、フィードバック、確認の中身を書いてください。

Q1 自由記述

クローズド テストのテスターはどのように集めましたか?

Googleが尋ねているのは、テスターの出どころです。実際に使った経路を挙げ、テストを回したのが誰かを書いてください。経路を分けるのは望ましい進め方ですが、1つの経路を禁じる決まりではありません。作り話の一覧を並べるより、実際に使った1つの経路を正直に書くほうが、はるかに中身のある回答になります。

この項目に必要なこと

  • 実際に使った経路(1つでも複数でも)。
  • テスターが、アプリの想定利用者とどう重なるか。
  • シナリオを決め、フィードバックを読み、変更をリリースしたのは誰か。

下書き例(架空)

12人のテスターを、自分の人脈(コワーキングスペースの同僚5人、店のシフトを組んでいる友人4人、テストのフォーラムから3人)から集めました。全員が2日以内にオプトインし、14日間そのまま参加を続けました。テストのシナリオは自分で決め、フィードバックも自分で読みました。

この例は134文字
弱い書き方と、そこで抜け落ちるもの

「オンラインでテスターを見つけました。」

経路も、利用者との関係も、テストを回した人も出てきません。

代行サービスの名前を出すことが結果に影響するという公開情報はありません。大事なのは、フォームの残りの回答がそれと食い違わないことです。テスターを集めたのが代行会社なら、シナリオを決め、フィードバックを読み、変更を加え、それを確認したのが誰かを書いてください。

Q2 選択式

テスターを集めるのはどのくらい大変でしたか?

「とても大変」から「とても簡単」までの段階です。自分の実感に合うものを選んでください。どれが望ましいかを示した公開情報はありません。以下の説明はあくまで目安で、基準ではありません。募集の大変さには、ここに当てはまらない事情もあります。

  • とても大変 12人に届かず、テストが遅れたり止まったりした。
  • 大変 何度も頼んだり、長い期間に何度も試したりした。
  • どちらでもない 多少の手間はかかり、想定どおりの時間で集まった。
  • 簡単 1回か2回声をかけたら埋まった。
  • とても簡単 枠より希望者のほうが多かった。

ここに推奨の選択肢はありません。文言や選択肢の数は、上に挙げたものと違うことがあります。自分のフォームを読んでください。

Q3 自由記述

テスターのエンゲージメントについて説明してください

この項目についてGoogleが挙げている例は、機能の使われ方と、それが実際の製品版の利用に近いかどうかです。「積極的に使われた」では、誰も情景を思い浮かべられません。フロー、期間、使われ方の傾向、そして数字の出どころを書いてください。

この項目に必要なこと

  • テスターの人数と、その期間。
  • 実際に完了したフローを2つから4つ、名前を挙げて。
  • 使われ方の傾向と、数字の出どころ。

下書き例(架空)

14日間で、12人のテスターが合計31件の週の名簿を作りました。全員が登録と名簿作成を終え、9人が同僚を招待、7人がシフトのリマインダーを受け取りました。複数店舗のテスターはほぼ毎日、1店舗のテスターは週1回アプリを開いていました。これらの数はアプリ内のイベントログによるものです。

この例は141文字
弱い書き方と、そこで抜け落ちるもの

「テスターは積極的で、アプリを使ってくれました。」

人数も、期間も、具体的なフローの名前も、その出どころもありません。

Q4 自由記述

受け取ったフィードバックの概要を教えてください

Googleは、フィードバックの中身と集め方の両方を尋ねています。届いた場所、実際に挙がった論点、そしてそれぞれへの対応を、まだ手をつけていないものも含めて書いてください。短い欄に複数の指摘を収めるところが、いちばん手を入れる部分です。

この項目に必要なこと

  • フィードバックが届いた場所。
  • 実際に挙がった論点を、いくつであってもそのまま。
  • そのうちリリース済みのものと、まだ残っているもの。

下書き例(架空)

フィードバックは、Play Consoleの「テストのフィードバック」とグループチャットで届きました。論点は、名簿を編集したあとにシフトのリマインダーが届かないこと、通信が遅いと名簿の公開に失敗すること、画面の小さい端末で週表示が窮屈なことの3つです。最初の2つは修正してリリース済み、3つ目はまだ残っています。

この例は156文字
弱い書き方と、そこで抜け落ちるもの

「フィードバックは好意的でした。」

経路も、論点も、対応も出てきません。この項目が尋ねている3つが、そろって抜けています。

本当にすべて好意的だったのなら、そう書いたうえで、何についての評価だったのかを添えてください。作り話の不具合は、Q8やQ9とも辻褄を合わせ続けなければならなくなります。

14日間途切れずにオプトインを続けてくれるテスターが足りていませんか?

PrimeTestLabなら、条件を満たしたテスター12人を$19.99から手配し、4~6時間以内にテストを開始できます。

プランを見る

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

これらの回答はGoogle Playには表示されず、Play Consoleの機能の利用にも影響しないとGoogleは説明しています。素直に書いてください。ストアの紹介文ではないので、ここで売り込んでも得るものはありません。

Q5 自由記述

このアプリの想定利用者は誰ですか?

Googleは具体的に書くよう求めています。「すべての人」では誰のことも説明できません。どんな人で、どんな困りごとがあり、どんなときにアプリを開くのかを書いてください。利用者が本当に2種類いるなら、両方を挙げます。

この項目に必要なこと

  • どんな人か。役割、置かれた状況、本当に関係があるなら年齢層も。
  • このアプリがない状態で抱えている困りごと。
  • いつ、どれくらいの頻度で使うか。

下書き例(架空)

Shiftlyは、スタッフ3人から20人ほどの店舗やカフェのオーナーと店長のためのアプリです。この人たちは今、紙やメモアプリでシフトを組んでいます。使うのは翌週の予定を立てる週1回と、シフト交代の相談が来たときの短い時間です。

この例は113文字
弱い書き方と、そこで抜け落ちるもの

「すべての人。」

利用者も、困りごとも、使う場面も出てきません。そして、そもそも事実であることがほとんどありません。

Q6 自由記述

このアプリが利用者にどのような価値をもたらすか説明してください

まず何ができるようになるかを書き、それを生む機能を2つか3つ挙げます。ゲームなら、価値は体験そのものです。ループ、他と違う点、1回のプレイの長さ、そしてまた戻ってくる理由を書きます。

この項目に必要なこと

  • 何ができるようになるかを、機能を並べる前に一文で。
  • それを生む機能を2つか3つ。
  • ゲームなら、ループ、他と違う点、1回のプレイの長さ。

下書き例(架空)

Shiftlyを使うと、店長が先週のシフトをそのまま使い回し、スタッフにシフトを公開し、各シフトの前にリマインダーを送れます。スタッフは、メッセージではなくアプリ上で交代を申請します。

この例は92文字
弱い書き方と、そこで抜け落ちるもの

「便利で、良い機能がそろったアプリです。」

できるようになることも、機能も、利用者も出てきません。しかもGoogleが公開しない項目です。

ゲームのタブはShiftlyではなく、2つ目の架空の例です。こちらを使うなら、残りの回答もシフト管理アプリではなく、自分のゲームの話になります。

Q7 選択式

初年度のインストール数はどのくらいを見込んでいますか?

Googleはおおよその見込みで構わないとしており、範囲もあえて広く取られています。自分の利用者像と公開の計画から説明できる範囲を選んでください。望ましい範囲を示した公開情報はなく、真ん中の帯を選ぶという通説にも根拠はありません。

  • 0~1万
  • 1万~10万
  • 10万~100万
  • 100万以上
  • わからない これも立派な選択肢で、作り出した数字よりは説明がつきます。

ここに推奨の選択肢はなく、どの範囲を選んでもアプリについて何かを意味するわけではありません。範囲の区切りや文言は変わります。自分のフォームを読んでください。

パート3:製品版への準備状況

このセクションでは、テストから何が生まれたか、そしてなぜ公開すると決めたかを尋ねられます。どちらの回答も、ここで初めて出てくる主張ではなく、先に作った記録から導いた結論として読めるようにしてください。

Q8 自由記述

クローズド テストをふまえて、どのような変更を行いましたか?

実際に行った変更と、その確認の方法を書きます。公開されているガイダンスは、この項目の採点方法もアップデートの最低回数も示していません。それは回答に効果がないという意味ではありませんし、公開を妨げる問題やポリシー上の問題を放っておいてよいという意味でもありません。終わった作業と、これからの作業は分けて書いてください。

この項目に必要なこと

  • テストで分かったことを、自分の言葉で。
  • それに対して何をリリースしたか。バージョンがあればバージョンも。
  • どう確認したか、そして何が残っているか。

下書き例(架空)

テスト中のリリースは2回です。1.4.1で名簿の編集後にリマインダーを組み直すよう修正し、1.4.2で通信が遅いときの名簿の公開を直しました。不具合を報告したテスターに確認してもらい、公開のほうは通信を制限した状態で自分で再テストしました。週表示が窮屈な点は、直さずに残しています。

この例は141文字
弱い書き方と、そこで抜け落ちるもの

「アプリを改善しました。」

分かったことも、リリースも、確認も出てこないので、フィードバックの回答と突き合わせようがありません。

変更を行わなかった場合は?

ガイダンスはアップデートの回数を定めていませんし、変更のないアプリが自動的に弱い申請になるわけでもありません。回答を弱くするのは、説明のないテストです。上の変更なしのタブを使って、どのフローと条件を確認し、結果はどうだったか、それはどこから分かったか、そして何が解決していないかを書いてください。報告する修正がほしいからといって、不具合をでっち上げてはいけません。

Q9 自由記述

このアプリが製品版に出せると、どのように判断しましたか?

Googleが尋ねているのは自信ではなく、判断の基準です。見た点を2つか3つ挙げ、それぞれの根拠を添えてください。ここに書くことは、フォームの前のほうにすでに出ているはずで、確認の経緯も同じでなければなりません。

この項目に必要なこと

  • 使った基準を、基準として書く。
  • それぞれの根拠。
  • 残っている項目と、それが公開を妨げない理由。

下書き例(架空)

判断の基準は3つです。リマインダーの修正は、影響を受けたテスターに確認してもらいました。1.4.2のあと、通信を制限した状態で名簿の公開を再テストしました。週表示が窮屈な点は残っていますが、見た目の問題で、テスト済みの中心的なフローは問題なく使えます。

この例は126文字
弱い書き方と、そこで抜け落ちるもの

「準備できたと感じました。」

感覚は基準ではないので、同意することも、異を唱えることもできません。

回答でよくあるミス

どれもGoogleが公開している決まりではありません。書いた本人が意図したほどには伝わらなくなる、よくある型です。

01
行動を書くべきところに形容詞

「積極的に使ってくれた」「とても好評だった」「入念にテストした」。どれも短い欄を埋めるだけで、フローも、人数も、期間も出てきません。

02
回答どうしが食い違う

ある欄に「問題は見つかりませんでした」と書き、次の欄に「いくつか不具合を直しました」と書く。両方が成り立つことはなく、読む側にはどちらが本当かを知る手がかりがありません。

03
経路のないフィードバック

フィードバックを書くなら、それが届いた場所も書いてください。Play Consoleの「テストのフィードバック」、アプリ内フォーム、チャットのグループ、メール。それがないと、出どころのない要約になります。

04
自分のものではない事実

貼り付けた例が、他人のアプリ、他人の利用者、他人の不具合のままなら、それは自分のテストの説明ではありません。このページのものも含め、どんなテンプレートにも同じ落とし穴があります。

05
出どころのない数字

厳密そうに見せるために作ったパーセンテージは、裏づけのない主張です。テスターの報告から数えた数字は十分に使えます。そう書けばよいだけです。

06
終わった作業とこれからの作業が混ざる

どの修正がリリース済みで、どれが予定なのかを書き分けてください。予定をリリースのように書けば、自分のバージョン履歴と食い違います。

07
選択式を戦略で選ぶ

実際に起きたことではなく、聞こえのよい選択肢を選ぶと、選択式の回答が自由記述と食い違います。望ましい選択肢を示した公開情報もありません。

提出する前に回答を確認する

フォームは1つの文書として読まれます。弱くなる原因の多くは、下手な一文ではなく、食い違う二文です。9つの回答を並べて、この確認を通してください。

このチェックリストで結果が分かるわけではありません。フォームが自分自身と言い争うのを防ぐための確認です。

申請したあとに起きること

区別しておきたい結果が4つあります。そのうち2つは、よく取り違えられます。審査が進行中であることは、テストの継続を求められたことではありませんし、アクセスが付与されたことと、アプリが公開されたことも別です。

審査を見守る

審査中

Googleは、審査は通常7日以内で、それより長くかかることもあると説明しています。Play Consoleとアカウントのメールを確認し、Googleから求められたことには対応してください。待ち時間が長いというだけでは、出し直しやテストのやり直しの理由になりません。

もう1ステップ

製品版へのアクセスが付与された

アクセスがあることと、アプリが公開されていることは別です。製品版のリリースを用意して段階的に公開する必要があり、それ自体にも審査があります。Googleのリリースの手順と、当社の製品版へのアクセスとリリース審査にかかる時間を参照してください。

届いた通知を読む

「More testing required」

文言だけでなく、テストそのものについての判断です。詳しくは下で説明します。

文言ではなくアプリの問題

審査担当者がアプリを開けなかった

アプリがログインの内側にある場合など、何らかの制限がかかっている場合は、審査担当者に使える認証情報が必要です。審査用のログイン情報として渡してください。質問票のどの回答も、アクセスの代わりにはなりません。

Googleからテストの継続を求められたら

同じフォームを出し直さないでください。原因が書き方だったと決めつけるのもやめましょう。次の順に進めます。

1
実際に届いたメッセージを読む

通知にはたいてい理由が書かれています。有効なテスターが12人に届かない、14日間の途中でオプトインが途切れた、テスターがアプリを十分に使っていない、といったものです。このページを含め、どんな一般的なガイドよりも、そのメッセージを優先してください。

2
まず土台になる証拠を立て直す

テスターが足りなかった場合や、オプトインが途切れた場合は、再申請の前に、直近の履歴が途切れていない有効なテスター12人の状態に戻してください。新しいテスターなら、そこからさらに14日間かかります。テスターの記録が変わらないまま回答を書き直しても、参加資格の情報は変わりません。

3
変わった点を書き直し、分かりにくかった点をはっきりさせる

変わった事実を更新し、足りなかったり曖昧だったりした回答をはっきりさせてください。すでに持っていた証拠が、回答のせいで伝わらないことはあります。一方で、書き直しでは直せないのが、テストそのものの問題です。2回目のテストで新しい観察、フィードバック、変更、確認が生まれることもありますが、必ずそうなるわけではなく、新しいリリースが必要なわけでもありません。

4
不承認の通知が示す時期に合わせて再申請する

Googleは直近14日間連続で有効なテスターがいることを求めているため、12人に届かない状態で申請してはいけません。そのうえで、追加の期間を示す通知もあれば、何も示さない通知もあります。再申請までの共通の間隔を、Googleは公開していません。当社の「More testing required」で不承認になったあとの再申請ガイドでは両方を扱っており、テスターにいったん離脱して入り直してもらうと、積み上げた履歴が消えてしまう理由も説明しています。

フォームではなくテストそのもので何がまずかったのかを知りたい場合は、クローズド テストが却下される理由と直し方から始めてください。

Q10 自由記述 · 条件付き 条件付きの項目

今回はどのような点を変えましたか?

テストの継続を求められたあとに再申請した開発者から報告されている質問です。報告される文言はさまざまで、表示されたという報告がないアカウントもあります。出る、出ないを決めつけず、自分のフォームを確認してください。

書くのは記録のどこが変わったかであって、気持ちの持ちようではありません。2回目のテストが1回目と同じ中身だったのなら、再申請の前に直すべきなのはそこです。

この項目に必要なこと

  • テストそのもののどこを変えたか。
  • それが何を生んだか。分かったこと、リリース、確認。
  • いまの証拠が、前回の判断にどう答えているか。

下書き例(架空)

前回の申請のあと、テスター12人で14日間のテストをもう一度行い、一人ひとりが何をしたかを記録しました。リマインダーの不具合が2件見つかり、1.4.3で修正して、報告したテスターに確認してもらいました。ここでの回答は、そのテストとそれらのリリースについて書いています。

この例は134文字
弱い書き方と、そこで抜け落ちるもの

「今回はフィードバックの収集と反映に力を入れました。」

意気込みの説明であって、違いの説明ではありません。この項目が尋ねているのは、その違いだけです。

この下書きはあとの段階の状況です。2回目のテストと、そこでの1.4.3というリリースがあります。自分に当てはまるなら、残りの回答も、以前の1.4.1と1.4.2の記録ではなく、いまのテストの話になります。

PrimeTestLabはテストと申請をどう支えるか

ここまでの話は、書くもとになる記録があることが前提です。詰まっているのが記録そのもの、つまり14日間途切れずにオプトインを続ける12人を集めることなら、そこは当社の仕事です。実在の人が実機で、4~6時間以内に開始し、14日間を走り切ります。進み具合は、その間ずっと見えます。

Starterプランはテスター12人で$19.99、Professionalプランはテスター20人で$29.99、Enterpriseプランはテスター25人で$27.99。いずれも14日間まるごとの保証付きです。

Starter テスター12人
$19.99 別途手数料5%

最低要件をきっちり満たす

人気
Enterprise テスター25人
$27.99 別途手数料5%

同じ14日間で最大のカバー

Professional テスター20人
$29.99 別途手数料5%

同じ14日間で、より多くのエンゲージメント

フォームのために手に入るもの

名前の分かるテスター、途切れのないオプトインの履歴、何をしたかの記録、そして文章で残るフィードバック。Q1、Q3、Q4、Q8の材料になります。回答を書くのはあなた自身です。回答は自分のものでなければならないからです。

手に入らないもの

当社が質問票を代わりに提出することはありませんし、審査に影響を与えることもできません。このページのどこにも、結果を予測するものはありません。そうではないと言うサービスがあれば、まずその主張を確かめてください。

クローズド テストのプランを比較する

よくある質問

この回答例をテンプレートとして使えますか?

型としてなら使えます。そのまま提出する文章としては使えません。ここに出てくる事実はすべて架空のアプリのもので、その事実を残したままの回答は、他人のテストの説明になります。名前、数字、機能、分かったことをすべて置き換えてください。コピー機能が角かっこ入りのテンプレートを渡すのは、まさにそのためです。

製品版アクセス質問票とは何ですか?

クローズド テストのあとに製品版へのアクセスを申請するとき、記入するフォームです。実施したテスト、アプリやゲーム、製品版への準備状況について尋ねられます。Play Consoleのアプリのダッシュボードにある「製品版へのアクセスを申請」から開き、質問のプレビュー(Preview questions)のリンクで事前に内容を読むこともできます。

回答はどのくらいの長さまで書けますか?

このページの例はすべて300文字未満で、その前後に上限があるという開発者の報告もあります。現時点で共通の上限は確認できなかったので、基準になるのは自分のフォームのカウンターです。回答の長さが結果を左右するという公開された根拠はありません。

有料のテスト代行サービスを使ったと書くべきですか?

正直に答えて構いません。代行サービスの名前を出すことが結果に影響するという公開情報はなく、作り話の経路を並べるほうがよほど危険です。経路を挙げたうえで、シナリオを決め、フィードバックを読み、変更を加え、それを確認したのが誰かを書いてください。

テストの解析データがない場合はどうすればいいですか?

セッションの解析を取っていなかった場合は、分かっていることと、それをどうやって知ったかを書きます。「テスター12人のうち10人が、登録を終えたと話してくれた」は使えますが、作り出した平均セッション時間は使えません。テスターの報告から数えた数字も立派な数字です。そう書きさえすれば構いません。

クローズド テスト中に変更を行わなかった場合は?

ガイダンスはアップデートの回数を定めていませんし、変更のないアプリが自動的に弱い申請になるわけでもありません。回答を弱くするのは、説明のないテストです。どのフローと条件を確認し、結果はどうだったか、それはどこから分かったか、そして何が解決していないかを書いてください。

製品版へのアクセスの審査にはどのくらいかかりますか?

Googleは、通常7日以内で、それより長くかかることもあるとしています。審査が進行中であることは、不承認ではありません。Play Consoleとアカウントのメールを確認し、Googleから求められたことには対応してください。

Googleからテストの継続を求められました。いつ再申請できますか?

届いたメッセージを読んでください。追加の期間を具体的に示すものもあれば、示さないものもあり、再申請までの共通の間隔をGoogleは公開していません。いずれの場合も、直近14日間連続で、有効なテスターが12人以上必要です。上の立て直しの手順と、「More testing required」の詳しいガイドを参照してください。

まとめ

要約

回答はすべて自分の記録から書いてください。誰がテストし、何をして、何を報告し、何をリリースし、それをどう確認したか。このページの作り物の細部はすべて置き換え、自分の状況に合う選択肢を選び、自分のフォームに表示される文言とカウンターに従い、最後に回答をまとめて読み返して、互いに食い違っていないか確かめてください。

足りないのが記録なら、クローズド テストのプランを比較してみてください。

Kefayatullah Khadem、ソフトウェアエンジニア · Google Play公開スペシャリスト

執筆

Kefayatullah Khadem

ソフトウェアエンジニア · Google Play公開スペシャリスト

Kefayatullah Khademは、スケーラブルなアプリを8年以上手がけてきたソフトウェアエンジニアです。PrimeTestLabでは、Google Playのクローズド テスト要件でつまずく個人開発者を支援しています。これまでにAndroidアプリ9,800+件の製品版へのアクセスを支援し、成功率99.9%、120か国以上に広がります。開発者の公開サポートの傍ら、Google Playのポリシー、審査落ちのパターン、製品版アクセス質問票の答え方についても書いています。

9,800+ テスト実績
99.9% 成功率
120+ 対応国
4.9/5 評価

成功率99.9%

実在のテスターが実機で、14日間ずっとテストします

これまでにアプリ9,800+件をテスト。実在の人が実際に使い、質問票にそのまま答えられる記録が残ります。

$19.99から · 別途サービス手数料5%

4~6時間以内に開始 · 14日間フルでテスト · 返金保証

PrimeTestLabとともに公開を進めた開発者は9,800人を超えています

テスター12人を用意 · $19.99 WhatsApp