Google Play クローズドテスト完全ガイド — 個人開発者は必須、企業でも活用すべき理由

この記事を読んでいただく際の注意点: 2026年4月時点の Google Play Console の要件・仕様に基づいています。Google Play のポリシーは随時変更される可能性があるため、最新情報は Google Play Console ヘルプ [1] を併せてご確認ください。

この記事の対象読者

この記事は、Google Play のクローズドテストについて「個人開発者」と「企業での開発者」両方の視点で記載しています！
それぞれの視点で、下記のように読み進めていただくのが良いと考えております。

個人開発者の方：第1部（共通基礎）→ 第2部（個人開発者向け）→ 第4部（まとめ）の順。第2部では、テスターの集め方や審査突破のコツなど、個人開発者特有の課題に焦点を当てています。

企業でストア申請を担当される方：第1部（共通基礎）→ 第3部（企業向け）→ 第4部（まとめ）の順。第3部では、QA プロセスへの組み込み方や CI/CD との統合など、企業での戦略的な活用方法を扱っています。

第1部: 共通基礎 — クローズドテストの全体像

1. クローズドテストとは何か

1.1 Google Play のテストトラック全体像

Google Play Console では、アプリを本番リリースする前に品質を段階的に検証するための「テストトラック」が用意されています。全体像は以下の通りです。

内部テスト（Internal Testing）
    ↓
クローズドテスト（Closed Testing）  ← 本記事の主題
    ↓
オープンテスト（Open Testing）  ※ 本番環境へのアクセス取得後に利用可能
    ↓
製品版（Production）

各トラックの特徴を比較すると、次のようになります。

トラック	対象者	主な用途	Google による審査	テスター上限	利用条件
内部テスト	最大100名の内部テスター	開発チーム内の動作確認。アップロード後数秒〜数分で配布可能	なし（通常は審査対象外）	100名	アプリ作成直後から利用可能
クローズドテスト	指定されたテスターグループ	QA・ステークホルダー向けの品質検証。フィードバック収集	あり	制限なし（グループ単位で管理）	アプリのセットアップ完了後
オープンテスト	誰でも参加可能	公開前の大規模テスト。一般ユーザーからのフィードバック収集	あり	制限なし	本番環境へのアクセス取得後
製品版	全ユーザー	本番リリース	あり	—	個人アカウントはクローズドテスト完了後

注意: オープンテストは本番環境へのアクセスを取得した後にはじめて利用可能になります。したがって、新規の個人アカウントでは「クローズドテストの代わりにオープンテストを使う」ということはできません。

1.2 クローズドテストの位置付け

クローズドテストは、この段階的なテストプロセスの中で「信頼できる限られたユーザーに対して、本番に近い環境でアプリを配信し、品質検証とフィードバック収集を行う」という役割を担います [3]。

内部テストが「開発チーム内の素早い動作確認」を目的とするのに対し、クローズドテストは「開発チーム外のユーザーによる、より実践的な検証」を目的としています。Google による審査も入るため、ストアポリシーへの準拠状況もこの段階で確認されます。

また、デフォルトのクローズドテストトラックまたはオープンテストトラックに AAB または APK をアップロードすると、Google Play Console の Pre-launch Report（公開前レポート）[4] が自動生成されます。
Pre-launch Reportでは複数の実機デバイスでのクラッシュ検出やアクセシビリティチェックが含まれます。
クローズドテストを実施するだけで、この自動品質チェックの恩恵も受けられる点は見逃せないメリットです。

1.3 なぜ Google はクローズドテストを重視するのか

Google がクローズドテストの要件を強化した背景には、Google Play ストア全体の品質向上という明確な意図があります。具体的には、低品質なアプリや不具合の多いアプリがストアに溢れることを防ぐこと、ダウンロード直後にクラッシュするようなアプリによるユーザー体験の悪化を防ぐこと、そして十分なテストを経ていない悪質なアプリを排除することが目的です。

開発者にとっては負担が増える側面がありますが、長期的にはストアのエコシステム全体の健全性を維持するための施策といえます。

2. 誰に必須で、誰に任意なのか

2.1 対象者の判定

クローズドテストが「本番リリースの前提条件」として必須かどうかは、アカウントの種類と作成時期によって決まります。

条件	クローズドテスト	備考
2023年11月13日以降に作成された個人アカウント	必須	本番環境へのアクセス申請にクローズドテストの完了が前提条件
2023年11月13日より前に作成された個人アカウント	任意（推奨）	直接製品版にリリース可能
組織アカウント（時期を問わず）	任意（推奨）	直接製品版にリリース可能

2.2 あなたはどちらに該当しますか？

以下のフローチャートで判定できます。

あなたの Google Play デベロッパーアカウントは？
    │
    ├── 組織アカウント
    │       → クローズドテストは「任意」
    │         （ただし品質向上のために活用を推奨 → 第3部へ）
    │
    └── 個人アカウント
            │
            ├── 2023年11月13日より前に作成
            │       → クローズドテストは「任意」
            │
            └── 2023年11月13日以降に作成
                    → クローズドテストは「必須」
                      （12名 × 14日間の要件を満たす必要あり → 第2部へ）

2.3 「必須ではない」場合でも活用すべき理由

組織アカウントや、要件適用前の個人アカウントであっても、クローズドテストを活用することには大きなメリットがあります。本番リリース前に実ユーザーの環境で品質を検証できること、ステークホルダーへの事前デモとフィードバック収集ができること、段階的ロールアウト前にクラッシュ率や ANR 率を事前に把握できること、そして Google Play の Pre-launch Report（自動テスト）と合わせて品質保証を多層化できることなど、企業にとって特に価値のある活用方法があります。

これらの詳細は第3部で掘り下げます。

3. 具体的な要件の詳細

3.1 基本要件（個人アカウント向け必須要件）

2023年11月13日以降に作成された個人アカウントがアプリを本番リリースするためには、以下の要件をすべて満たす必要があります。

要件項目	内容
テスター数	最低 12名以上がクローズドテストにオプトイン
テスト期間	本番環境アクセスの申請時点から遡って、直近14日間連続でオプトイン状態が維持されていること
テスターの要件	実際の Android デバイスを使用する実在のユーザー。エミュレータやバッチ作成アカウントは無効
テスト対象	アプリごとに毎回クローズドテストが必要（1つのアプリでテストを通過しても、次の新規アプリには再度必要）

補足: この要件は当初「20名以上」でしたが、2024年末に「12名以上」へ緩和されました。最新の要件は公式ヘルプ [1] で確認してください。

3.2 14日間要件の正確な意味

14日間の要件は「14日間のカウントダウンがスタートする」という仕組みではありません。正確には、本番環境へのアクセスを申請する時点で、12名以上のテスターが直近14日間連続してオプトインしている状態であることが求められます。

つまり、Google が確認するのは「申請した瞬間から遡って14日間、常に12名以上がオプトインし続けていたかどうか」です。この理解は実務上の行動に直結します。たとえば、テスターが13日目にオプトアウトしてしまった場合、その時点からさらに14日間待つ必要が生じます。

3.3 オプトイン・オプトアウトの仕組み

テスターの「オプトイン」「オプトアウト」は、14日間要件の判定に直結する重要な概念です。

オプトインとは、テスターがテスト用のリンク（Web またはアプリ）にアクセスし、テストプログラムへの参加を承諾することです。オプトインが完了すると、テスターは Google Play からアプリのテスト版をインストールできるようになります。

オプトアウトとは、テスターがテストプログラムから離脱することです。オプトアウトはテスト用 Web リンクの画面からのみ可能であり、単にアプリをアンインストールしただけではオプトアウトにはなりません。

ここで特に重要なポイントがあります。テスターがオプトインした後、アプリをアンインストールしたとしても、オプトイン状態は維持されます。つまり、アプリのアンインストールだけでは14日間のカウントは途切れません。一方で、テスターがテスト用 Web リンクから明示的にオプトアウトした場合、その時点でそのテスターのカウントは無効になります。再度オプトインしても「連続14日間」の条件を満たせなくなるため、新たなテスターを補充する必要があります。

3.4 内部テストとの違いに関する注意

内部テストは、クローズドテストの14日間要件にはカウントされません。内部テストはあくまで開発チーム内での素早い動作確認用であり、本番環境へのアクセス要件とは無関係です。必ずクローズドテストトラックでテストを実施してください。

3.5 任意で実施する場合の要件

組織アカウントや要件適用前の個人アカウントが任意でクローズドテストを利用する場合、上記の「12名 × 14日間」という数値要件はありません。テスターが1名でも、期間が数日でも実施可能です。ただし、クローズドテストトラックにリリースを作成すると Google による審査が入る点は共通です。

4. クローズドテストの実施手順

ここでは、Google Play Console でクローズドテストを実施する一連の手順を解説します [2]。この手順は個人開発者・企業の両方に共通です。

4.1 前提条件

クローズドテストを開始する前に、以下の準備が完了している必要があります。

Google Play Console でアプリの作成が完了していること
Play App Signing が有効化されていること（2021年8月以降に作成されたアプリではデフォルトで有効）
Upload Key で署名されたリリース用の AAB（Android App Bundle）ファイルがビルド済みであること
ストア掲載情報（アプリ名、説明、スクリーンショット等）の基本的なセットアップが完了していること
コンテンツレーティングやデータセーフティセクションの設定が完了していること

AAB と署名について: 2021年8月以降、Google Play への新規アプリ提出は AAB 形式が必須です（APK 形式では提出できません）。AAB は Upload Key で署名してアップロードし、Google が App Signing Key で再署名してユーザーに配布します。Upload Key を紛失した場合は Play Console からリセット申請が可能なため、アプリの更新が不可能になるリスクを回避できます。詳細は Play App Signing のドキュメント [6] を参照してください。

4.2 ステップ1: クローズドテストトラックの作成

Google Play Console にログインし、対象のアプリを選択します。左サイドバーから「テストとリリース」→「テスト」→「クローズドテスト」を選択します。「トラックを作成」からクローズドテスト用のトラックを作成してください。（以下画像の赤枠箇所）

カスタムトラックを作成する場合、トラック名は任意ですが、用途がわかる名前（例: qa-round1、stakeholder-review など）を付けることを推奨します。

デフォルトトラックと Pre-launch Report: Pre-launch Report（公開前レポート）が自動生成されるのは、デフォルトのクローズドテストトラックまたはオープンテストトラックに AAB または APK をアップロードした場合に限られます。カスタムトラックでは Pre-launch Report が生成されない場合があるため、品質チェックの恩恵を受けたい場合はデフォルトトラックの使用を推奨します。

4.3 ステップ2: テスターの設定

テスターの管理方法には3つの方式があります。利用シーンに応じて使い分けてください。

方式A: メールリストを利用する方法

Play Console 上で直接テスターのメールアドレス（Gmail アドレス）を登録します。1つのリストあたり最大2,000名、1つのトラックあたり最大50リストまで作成可能です。テスターの顔ぶれが明確な場合に適しています。

方式B: Google グループを利用する方法

Google グループ（groups.google.com）で新しいグループを作成し、テスターのメールアドレスをメンバーとして追加します。作成したグループを Play Console のクローズドテスト設定で紐付けます。この方式のメリットは、テスターの追加・削除がグループ側で管理できるため運用が楽な点です。注意点として、Google Play Console の仕様上、グループは「外部公開」に設定する必要があります。社内テスト用途の場合は、推測されにくいグループ名にすることを推奨します。

方式C: オプトイン URL（テストリンク）を利用する方法

Play Console のテスター設定画面でオプトイン URL を有効にすると、テスト参加用のリンクが発行されます。このリンクを共有するだけで、テスターが自分自身でオプトインできます。事前にメールアドレスを収集する必要がないため、SNS やコミュニティで広くテスターを募集する場合に最も実用的な方法です。個人開発者がコミュニティで募集する際には、この方式が最も手軽で推奨されます。

方式の使い分けの目安として、個人開発者がコミュニティで広く募集する場合はオプトイン URL 方式が最適です。個人開発者が知人に依頼する場合はメールリスト方式が手軽です。企業でテスターの入れ替えが頻繁に発生する場合は Google グループ方式が運用しやすい傾向にあります。

4.4 ステップ3: 対象国・地域の設定

クローズドテストの「国 / 地域」タブで、テスターがアプリをダウンロードできる国・地域を設定します。テスターの所在国がここに含まれていない場合、テスターはアプリにアクセスできず、オプトインができません。テスターの所在国が確実に対象に含まれていることを必ず確認してください。これは見落としやすいポイントであり、後述のトラブルの原因にもなります。

すべての国を対象にする場合は、先頭のチェックボックスで全選択が可能です。

4.5 ステップ4: AAB のアップロードとリリース作成

クローズドテストトラックに新しいリリースを作成し、ビルド済みの AAB ファイルをアップロードします。リリースノート（テスター向けの説明）を記入し、リリースを送信します。

この時点で Google による審査が開始されます。審査には通常数日かかりますが、初回リリースの場合は最大1週間程度かかることもあります。年末年始や大型連休の時期にはさらに延びる場合があるため、スケジュールに余裕を持たせてください。

4.6 ステップ5: テストリンクの共有

Google の審査が通過すると、テスト用のリンクが利用可能になります。テスター設定で方式C（オプトイン URL）を有効にしている場合は、その URL をテスターに共有してオプトインを依頼します。方式A・B を使用している場合も、テスターに対してアプリのインストール手順を案内します。

テストリンクには「Android で参加」のリンク（テスターが Android デバイスから直接アクセスしてオプトインおよびインストールを行う）と、「Web で参加」の URL（テスターが PC ブラウザ等からアクセスしてオプトインを行う）の2種類があります。

なお、クローズドテスト版のアプリは通常の Google Play ストア検索には表示されません。テスターにはリンクを直接共有する必要があります。

4.7 ステップ6: テスト期間の運用

テスターのオプトインが揃ったら、14日間の連続オプトイン期間の確保に向けた運用を開始します。この期間中に行うべきことは、Play Console のテスター数のタブで定期的にオプトイン状況を確認すること、テスターからのフィードバックを収集し、可能であればアプリの改善・更新を行うこと、そしてテスター数が12名を割らないよう監視し、減少した場合は速やかに補充することです。

重要: テスト期間中にアプリを1回も更新しないと、本番環境アクセス申請時に「追加テスト」を求められるリスクがあります。小さな改善でもよいので、テスト期間中に少なくとも1回は更新を行うことを強く推奨します。この点については第2部のセクション6で詳しく解説します。

4.8 ステップ7: 本番環境へのアクセス申請（個人アカウントのみ）

12名以上のテスターが直近14日間連続でオプトインしている状態を確認できたら、Play Console のダッシュボードから「本番環境へのアクセスを申請」（Apply for production access）をクリックします。

申請時には、以下の3パートで構成されるアンケートに回答する必要があります。

Part 1: クローズドテストについて（About your closed test）— テスト期間中にどのようなフィードバックを受け、どのような改善を行ったか。

Part 2: アプリ / ゲームについて（About your app/game）— アプリの概要、主要な機能、対象ユーザー。

Part 3: 本番リリースの準備状況（Production readiness）— アプリが本番リリースに向けて十分に準備できているかどうか。

申請後の審査には通常7日程度かかりますが、場合によってはそれ以上かかることもあります。

第2部: 個人開発者向け — 必須要件の突破ガイド

5. テスターの集め方

個人開発者にとって、クローズドテスト最大の壁は「12名以上のテスターを14日間確保すること」です。ここでは、テスターを確保するための具体的な手段を紹介します。

5.1 手段1: 友人・知人への依頼

最もシンプルな方法は、身近な人にテスターになってもらうことです。Google の公式ヘルプでも、テスター募集の第一の手段として「友人、家族、同僚、クラスメートなどの個人的・仕事上のネットワーク」が挙げられています。Android デバイスを持っている身近な人に声をかけ、テストリンクからオプトインしてもらいましょう。

この方法のメリットは、信頼できる相手であるためオプトアウトのリスクが低い点と、直接的なフィードバックが得られる点です。一方、Android ユーザーが身近に12名以上いるとは限らないというのが現実的な課題です。

5.2 手段2: 開発者コミュニティでの相互テスト

同じくクローズドテストを突破したい個人開発者同士で、お互いのアプリのテスターになり合うという方法があります。Discord や X（旧 Twitter）上には、Android 個人開発者がテスターを募集し合うコミュニティが存在しています。

私が所属しているAndroidクローズドテストコミュニティ（ACTC）もテスターを募集し合うためのコミュニティとなっているので、是非下記リンクからご参加ください！

この方法は、開発者同士であるため操作に慣れており、的確なフィードバックが得られやすいという利点があります。また、自分も他の人のテスターになることで、相互に協力関係を築けます。

5.3 手段3: SNS・海外コミュニティでの募集

X（旧 Twitter）で #AndroidDev、#個人開発、#クローズドテスト などのハッシュタグを活用して広く呼びかける方法があります。

また、海外の開発者コミュニティも視野に入れると、テスター確保の選択肢が大幅に広がります。Reddit では r/androidapps、r/AndroidAppTesters、r/alphaandbetausers などのサブレディットがテスター募集に活用されています。英語でアプリの説明とテストリンクを投稿すれば、海外のテスターにも参加してもらえます。テスターの所在国が対象国・地域に含まれていることを事前に確認してください（セクション4.4参照）。

5.4 テスター確保のための実践的なアドバイス

バッファを持つ: 12名ぴったりではなく、15〜20名程度を目標にテスターを集めることを推奨します。途中でオプトアウトするテスターが出た場合に備えるためです。12名を割った状態で14日間が経過してしまうと、新たなテスターを補充した上でさらに14日間待つ必要が生じます。

テスターへの事前説明を丁寧に行う: テスターに依頼する際は「何をすればよいか」を明確に伝えてください。具体的には、テストリンクからオプトインすること、アプリをインストールして一度は起動・操作すること、14日間はオプトアウトしないこと（アプリのアンインストールは問題ない旨を明記）、可能であればフィードバックを共有してほしい旨を伝えます。テスターが「何をどこまでやればいいのか」がわからないと、オプトインの手順で躓いたり、不安になってオプトアウトしてしまうケースがあります。

Google グループの公開設定を事前に済ませる: Google グループ方式を採用する場合、グループの参加設定を「誰でも参加できる」状態にしておかないと、テスターが参加できません。事前に設定を完了しておくことで、スムーズにテストを開始できます。

6. 本番環境アクセス申請と審査のポイント

6.1 申請の流れ

12名以上のテスターが直近14日間連続でオプトインしている状態が確認できたら、Play Console のダッシュボードから「本番環境へのアクセスを申請」（Apply for production access）をクリックします。

申請時には3パート構成のアンケートへの回答が求められます（セクション4.8で述べた Part 1〜3）。このアンケートの記述内容は審査結果に直結するため、十分に注意して回答してください。

6.2 アンケート回答のコツ

Part 1（クローズドテストについて）の回答が最も重要です。 ここでは、テスト期間中にどのようなフィードバックを受け、それに対してどのような改善を行ったかを具体的に記述します。

具体的に書く: 「特に問題はありませんでした」「テスターからフィードバックはありませんでした」のような曖昧な記述は避けてください。テスト期間中に何を確認し、何を改善したかを具体的に記述します。たとえば「テスターからボタンの配置がわかりにくいというフィードバックがあり、ログイン画面のレイアウトを修正した」のような形です。

改善の実績を示す: テスト期間中にアプリの更新を行った場合は、その内容（バグ修正、UI 改善、パフォーマンス最適化等）を明記します。アプリを実際にアップデートした事実は、テストプロセスを真剣に実施した証拠になります。

正直に書く: 虚偽の記載やコピーペーストの回答は、審査で不利に働く可能性があります。実際のテスト内容と改善活動を誠実に記述してください。

6.3 「追加テスト」（More testing）を求められるケース

14日間のクローズドテストが完了し、本番環境へのアクセスを申請したにもかかわらず、Google から「追加テスト」（More testing）を求められるケースが報告されています。これは、さらに14日間のクローズドテストの延長を意味し、合計で28日間以上を要することになります。

追加テストが要求される主な原因として考えられるのは、テスト期間中にアプリの更新が一度も行われなかったこと（テスターが積極的にテストに関わっていないと判断される）、テスターのアプリへのエンゲージメントが低いと判断されたこと、アンケートの回答内容が不十分であったこと、そして申請時にオプトインテスターが12名を満たしていなかったことです。

追加テストを避けるための実践的な対策として、テスト期間中に少なくとも1回はアプリの更新（小さなバグ修正やレイアウト修正でも可）を行うこと、テスターに対してアプリを実際に操作してもらうよう依頼すること、アンケートには具体的かつ詳細な内容を記述すること、そして追加テストに備えて14日間の余裕をスケジュールに含めておくことが有効です。

スケジュール感の目安: クローズドテスト全体のプロセスには、最短でも3〜4週間を見込んでください。内訳は、AAB アップロード後の Google 審査（数日〜1週間）、14日間のテスト期間、申請後の審査（約7日）です。追加テストが発生した場合はさらに14日間加算されるため、リリース予定日から逆算して余裕を持ったスケジュールを立てることを強く推奨します。

6.4 審査完了後

申請が承認されると、製品版トラックへのアクセスが解放され、アプリを本番リリースできるようになります。同時にオープンテストも利用可能になります。

なお、一度製品版アクセスを取得したアプリについては、以降のアップデートで再度クローズドテストを行う必要はありません。ただし、新しいアプリを公開する場合は、そのアプリごとに再度クローズドテストが必要です。

7. よくあるトラブルと対処法

7.1 テスターがオプトインできない

原因1: リリースがまだ審査中
→AAB をアップロードした後、Google の審査が完了するまでテストリンクは有効になりません。審査完了を待ってからリンクを共有してください。

原因2: 対象国・地域の設定漏れ
→クローズドテストの対象国にテスターの所在国が含まれていない場合、そのテスターはアプリにアクセスできません。Play Console の「国 / 地域」タブでテスターの所在国が含まれているか確認してください。

原因3: テスターが Google グループに未参加
→Google グループ方式を採用している場合、テスターがグループに参加していないとオプトインできません。オプトイン URL 方式に切り替えることで、この問題を回避できます。

原因4: テストリンクの URL が不完全
→テストリンクをコピーする際に URL が途中で切れている場合があります。完全な URL を共有しているか確認してください。

7.2 テスター数が12名を割った

テスト期間中にテスターがオプトアウトし、12名を下回った場合は速やかに新しいテスターを補充する必要があります。14日間の要件は「申請時点で12名以上が直近14日間連続でオプトインしている」ことが条件です。新たに追加したテスターについては、そのテスターがオプトインした日からさらに14日間の連続オプトインが求められるため、結果としてテスト期間が延長されることになります。安全のために、最初から15〜20名程度のバッファを持った人数でテストを開始することが重要です。

7.3 審査が長引く

クローズドテストリリースの審査や本番環境アクセス申請の審査が想定以上に長引くことがあります。特に年末年始や大型連休の時期は審査が遅延しやすい傾向にあります。リリーススケジュールには十分なバッファを設けて計画してください。Play Console のヘルプページから Google にサポートリクエストを送ることも可能です。

7.4 「More testing」（追加テスト）が要求された

前述の通り、追加テストを求められた場合はさらに14日間のクローズドテストが必要になります。追加テスト期間中には何かしらのアプリ更新を行い、再申請時にはその更新内容を具体的に記述してください。追加テスト後の再申請では「追加テスト期間中に何を変更したか」の記述が求められるため、最低でも1つの改善アップデートを行う必要があります。

第3部: 企業向け — 戦略的活用ガイド

8. 企業がクローズドテストを活用すべき理由

組織アカウントではクローズドテストは必須ではありませんが、本番リリース前の品質保証プロセスとして積極的に活用すべきです。ここでは、企業がクローズドテストを導入することで得られるビジネス価値を整理します。

8.1 本番リリース前の品質検証による手戻りコストの削減

本番リリース後にクラッシュやバグが発見された場合、修正版の開発・テスト・再審査・再リリースに要するコストは、リリース前の修正コストと比較して格段に大きくなります。クローズドテストを実施することで、実際のユーザーデバイスでの動作検証を本番リリース前に完了でき、手戻りコストを大幅に削減できます。

8.2 ステークホルダーへの事前デモと承認プロセス

企業でのアプリリリースでは、PM・経営層・クライアントなど複数のステークホルダーの承認が必要になることが一般的です。クローズドテストを活用すれば、ステークホルダーに Google Play 経由で実際のアプリ（本番とほぼ同等のビルド）を配布し、実機で触ってもらった上で承認を得ることができます。APK を手動で配布する方法と比較して、インストール手順がシンプルであり、自動更新にも対応できるメリットがあります。

8.3 Pre-launch Report による品質の自動検証

デフォルトのクローズドテストトラックまたはオープンテストトラックに AAB または APK をアップロードすると、Google Play Console の Pre-launch Report（公開前レポート）[4] が自動生成されます。
そして、以下のカテゴリで問題が検出されます。

安定性（Stability）: クラッシュ、ANR、非対応 API の使用。パフォーマンス（Performance）: 起動時間の遅延、メモリの問題。アクセシビリティ（Accessibility）: コンテンツラベルの欠如、色のコントラスト不足、タッチターゲットサイズの不足。

Pre-launch Report の結果は Play Console のレポート画面 [5] で確認できます。重大な問題が検出された場合は本番リリース前に修正対応が可能です。

注意: Pre-launch Report は自動クローリングによるテストであり、Android Vitals [12] のダッシュボードに表示される統計指標（クラッシュ率、ANR 率等）とは異なります。Android Vitals の統計指標は十分なユーザーデータが蓄積されて初めて有意な数値として表示されるため、クローズドテストの少人数規模ではデータが表示されないのが一般的です。品質の事前検知には Pre-launch Report を活用してください。

8.4 段階的リリース戦略の一部としての活用

企業における理想的なリリースフローは、内部テストで開発チーム内の動作確認を行い、クローズドテストで QA チーム・ステークホルダーの検証を経て、オープンテストで大規模なベータテストを実施し、製品版で段階的ロールアウト（1% → 5% → 10% → 25% → 50% → 100%）を行うという流れです。クローズドテストはこの段階的リリース戦略の中で、「限定された信頼できるユーザーによる品質ゲート」として機能します。

8.5 Google Play レビュープロセスへの事前対応

クローズドテストトラックにリリースを作成すると Google による審査が入ります。これは、本番リリース時の審査と同様のポリシーチェックが事前に行われることを意味します。クローズドテスト段階でポリシー違反が検出されれば、本番リリース前に修正対応が可能です。よくある審査指摘事項としては、データセーフティセクションの申告不備、不必要なパーミッション要求、プライバシーポリシーの不備などがあります。

9. 企業でのテスト運用設計

9.1 テスターグループの設計

企業では、役割や目的に応じて複数のテスターグループを設計することを推奨します。

グループ	対象者	目的	推奨するテストトラック
開発チーム	エンジニア、デザイナー	日常的な動作確認、機能検証	内部テスト
QA チーム	QA エンジニア、テスター	体系的な品質検証、テストケース実行	クローズドテスト
ステークホルダー	PM、PO、経営層、クライアント	承認、ビジネス要件の確認	クローズドテスト
外部パートナー	連携先企業、外部テスター	API 連携テスト、互換性確認	クローズドテスト
ベータユーザー	一般ユーザーの先行利用者	大規模フィードバック収集	オープンテスト

クローズドテストでは複数のトラックを作成できるため、QA チーム用とステークホルダー用でトラックを分け、それぞれ異なるテスターグループを紐付けることも可能です。

9.2 テストトラックの使い分け戦略

開発者の手元    →  内部テスト        →  クローズドテスト    →  オープンテスト   →  製品版
                   （開発チーム）          （QA + SH）          （ベータ）         （段階的ロールアウト）
                   ・数分で配布           ・Google 審査あり     ・誰でも参加可     ・1% → 5% → ...
                   ・100名まで            ・グループ管理        ・大規模FB収集     ・Android Vitals 監視
                   ・審査なし             ・Pre-launch Report   ・ストア上で公開    ・ロールバック可能

内部テストとクローズドテストの使い分けポイントは下記があります！

内部テスト：は審査不要で数秒〜数分以内に配布できるため、日常的な開発サイクルでの動作確認に適しています。開発中のイテレーションで使うのが良い。
クローズドテスト：Google の審査を経由するため配布まで数日かかりますが、本番に近い条件での検証が可能であり、Pre-launch Report による自動品質チェックも受けられます。リリース候補版の品質検証に使うのが良い。

9.3 CI/CD パイプラインとの統合

クローズドテストトラックへのデプロイは、手動で行うと AAB のビルド、署名、Play Console へのアップロードという一連の作業を毎回繰り返すことになります。この手作業はヒューマンエラーや作業漏れの原因になりやすく、特にリリース頻度が高いプロジェクトでは大きな負担となります。

CI/CD パイプラインにクローズドテストへのデプロイを組み込むことで、以下のようなメリットが得られます。

リリースブランチへのプッシュやタグ付けをトリガーに、ユニットテスト → AAB ビルド → クローズドテストトラックへのアップロードを自動化できる
手作業による署名ミスやアップロード漏れを防止できる
デプロイの履歴が CI/CD のログとして記録され、トレーサビリティが向上する
チームメンバーの誰でも同じ手順でデプロイできるようになり、属人化を排除できる

デプロイ自動化に利用できる主なツール

Google Play へのデプロイを自動化するためのツールがいくつか提供されています。CI/CD 基盤やプロジェクト構成に応じて選択してください。

ツール	概要	適したCI/CD基盤	特徴
Fastlane `supply` [8]	Ruby ベースのモバイルリリース自動化ツール。iOS / Android 両対応	GitHub Actions, CircleCI, GitLab CI, Bitrise 等（CI/CD 基盤を問わない）	iOS と Android の CI/CD を統一して管理できる。Ruby 環境の維持が必要
`r0adkll/upload-google-play` [7]	GitHub Actions 向けのサードパーティアクション	GitHub Actions	YAML に数行追加するだけで導入でき、最も手軽。個人開発者によるメンテナンス
`gradle-play-publisher` [9]	Gradle プラグインとしてビルドに直接組み込む方式	Gradle ベースのあらゆる環境	`./gradlew publishBundle` でビルドとデプロイを一体化できる
Bitrise 公式ステップ [10]	Bitrise が提供する「Google Play Deploy」ステップ	Bitrise	Fastlane 不要。Ruby 環境が不要で導入が容易

ツール選定にあたっては、チームの技術スタックとの親和性、長期的なメンテナンスコストを考慮した上で判断することが重要です。

CI/CD 統合時の注意点

CI/CD パイプラインからクローズドテストトラックへデプロイする際には、以下の点に注意してください。

サービスアカウントの認証情報管理: Google Play へのデプロイにはサービスアカウントの JSON キーが必要です。この認証情報は CI/CD ツールのシークレット管理機能（GitHub Actions の Secrets 等）に保存し、リポジトリに直接含めないでください
署名鍵のセキュアな取り扱い: Upload Key の Keystore ファイルも同様にシークレットとして管理し、ビルド完了後にはワークスペースからの削除を徹底してください
トラック名の指定: デプロイ先のトラックは、各ツールの設定でトラック名を指定することで切り替えられます。製品版は production、オープンテストは beta、内部テストは qa がデフォルトのトラック名です。クローズドテストには公式に定義されたデフォルトトラック名はなく、Play Console でトラックを作成する際に設定した名前をそのまま指定します [11]。

9.4 フィードバック収集の仕組み化

クローズドテストで収集するフィードバックを組織的に活用するための仕組みを整備しておくことを推奨します。

フィードバックの収集チャネルとしては、下記のものが考えられます。

Google Play Console 内のテスターフィードバック機能（テスターからのレビュー。クローズドテスト中のフィードバックは開発者にのみ表示され、公開の評価には影響しません）
Google フォームやアンケートツールによる構造化されたフィードバック収集
Jira や GitHub Issues との連携によるバグチケットの自動起票
Firebase Crashlytics [14] によるクラッシュログの自動収集

テスターに対して「何を確認してほしいか」を明確に伝えるテスト手順書を用意することで、フィードバックの質と量を向上させることができます。手順書には、テスト対象の主要機能リスト、確認してほしい操作フロー、フィードバックの報告方法（報告先 URL やテンプレート）を含めてください。

10. 開発プロセスへの組み込み方

10.1 ウォーターフォール開発での組み込み

日本の SI 業界で多く採用されるウォーターフォール開発では、クローズドテストを工程の一部として WBS に明確に位置付けることが重要です。

要件定義 → 基本設計 → 詳細設計 → 実装 → 単体テスト → 結合テスト
    → 総合テスト → α版（内部テスト）→ β版（クローズドテスト）
    → ストア提出（本番リリース）

WBS への組み込み時の留意点と具体的な日数の目安

クローズドテスト関連の工程には、合計で最低3〜5週間のスケジュール確保を推奨します。内訳としては、AAB アップロード後の Google 審査に数日〜1週間、テスト期間として最低1〜2週間（企業のテスト計画に応じた期間）、フィードバック対応と修正版の再デプロイに数日〜1週間、本番リリース時の審査に1〜7日です。追加テストや再審査が発生した場合のバッファとしてさらに1〜2週間を見込んでおくと安全です。

企業の場合、「12名 × 14日間」の制約はないため、テスト期間はプロジェクトの品質基準やテスト計画に応じて柔軟に設定できます。ただし、十分な検証を行うためには最低1〜2週間のテスト期間を確保することを推奨します。

10.2 アジャイル開発での組み込み

アジャイル開発（Scrum / Kanban）では、クローズドテストをスプリントレビューの延長線上に位置付け、リリースサイクルに組み込みます。

推奨するリリースサイクルは、2〜4スプリントに1回の Google Play リリースを目安とすることです。毎スプリント後に内部テストトラックへデプロイし、開発チーム内でのデモと動作確認を行います。リリーススプリントではクローズドテストトラックへデプロイし、QA チームとステークホルダーによる検証を実施します。検証通過後、製品版へ段階的ロールアウトを開始します。

カンバンボードの設計例として、クローズドテストに対応するカラムを追加することを推奨します。

Backlog → Refined → Dev Ready → In Dev → In Review → QA
    → Store Ready（クローズドテスト中）→ Done

「Store Ready」カラムは、クローズドテストトラックにデプロイされ、QA・ステークホルダーの検証を待っている状態を示します。

スプリントレビューでの活用として、内部テストトラック経由でステークホルダーの実機にアプリを配布し、スプリントレビューの場で実際にアプリを操作してもらいながらフィードバックを収集する方法が効果的です。リリーススプリントのレビューでは、クローズドテストトラックの検証結果を共有し、本番リリースの可否判断を行います。

第4部: まとめ

11. チェックリストとまとめ

11.1 個人開発者向けチェックリスト

クローズドテストの開始前から本番リリースまでの流れを、チェックリスト形式でまとめます。

テスト開始前

#	チェック項目	確認
1	Google Play Console でアプリの作成が完了している	☐
2	Play App Signing が有効化されている	☐
3	ストア掲載情報（アプリ名、説明、スクリーンショット等）を設定済み	☐
4	コンテンツレーティング・データセーフティセクションを設定済み	☐
5	Upload Key で署名されたリリース用 AAB ファイルをビルド済み	☐
6	テスターを15〜20名程度確保する目途が立っている（バッファ込み）	☐

テスト実施中

#	チェック項目	確認
7	クローズドテストトラックを作成した（デフォルトトラック推奨）	☐
8	テスターの設定を完了した（メールリスト / Google グループ / オプトイン URL）	☐
9	対象国・地域にテスターの所在国が含まれている	☐
10	AAB をアップロードし、リリースを送信した	☐
11	Google の審査が通過し、テストリンクが利用可能になった	☐
12	テスターにリンクを共有し、オプトインを完了してもらった	☐
13	12名以上のテスターがオプトインしていることを確認した	☐
14	テスト期間中に少なくとも1回はアプリを更新した	☐
15	テスターからのフィードバックを収集・記録した	☐

テスト完了後

#	チェック項目	確認
16	12名以上が直近14日間連続でオプトインしている状態を確認した	☐
17	本番環境へのアクセスを申請した	☐
18	アンケート3パート（テスト内容・アプリ概要・本番準備）に具体的な内容を記述した	☐
19	審査結果の通知を受け取り、製品版アクセスが解放された	☐

11.2 企業向けチェックリスト

企業でのクローズドテスト活用に向けたチェックリストです。

事前準備

#	チェック項目	確認
1	テスターグループの設計が完了している（QA、ステークホルダー、外部パートナー等）	☐
2	テストトラックの使い分け方針が決まっている（内部テスト / クローズドテスト / オープンテスト）	☐
3	フィードバック収集の仕組み（チャネル、テンプレート、チケット管理連携）が整備されている	☐
4	テスト手順書をテスター向けに作成済み	☐
5	CI/CD パイプラインにクローズドテストへの自動デプロイを組み込み済み（推奨）	☐

テスト実施中

#	チェック項目	確認
6	デフォルトのクローズドテストトラックにリリース候補版をデプロイした	☐
7	Google の審査が通過した	☐
8	Pre-launch Report の結果を確認し、重大な問題がないことを確認した	☐
9	QA チームによるテストケース実行が完了した	☐
10	ステークホルダーのレビュー・承認が完了した	☐
11	検出された問題の修正と再テストが完了した	☐

本番リリース準備

#	チェック項目	確認
12	R8 有効のリリースビルドで全機能の動作確認が完了している	☐
13	mapping.txt を Crashlytics にアップロード済み	☐
14	リリースノート（What's New）を日本語で記載済み	☐
15	段階的ロールアウトの計画（開始%、監視指標、ロールバック基準）が決まっている	☐
16	versionCode がインクリメントされている	☐

11.3 記事のまとめ

この記事では、Google Play のクローズドテストについて、個人開発者と企業の両方の視点から包括的に解説しました。

個人開発者にとって、クローズドテストは2023年11月13日以降に作成されたアカウントでは本番リリースの前提条件です。12名以上のテスターを14日間確保することが最大の壁となりますが、開発者コミュニティの活用やバッファを持った人数設計により、この壁は乗り越えられます。テスト期間中にアプリを更新し、審査アンケートの3パートに具体的な内容を記述することで、スムーズな審査通過を目指してください。スケジュールには最低3〜4週間（追加テスト発生時はさらに2週間）の余裕を見込むことを推奨します。

企業にとって、クローズドテストは必須ではないものの、本番リリース前の品質ゲートとして極めて有用です。QA プロセスの一環として体系的に運用することで、手戻りコストの削減、ステークホルダーの早期承認、Pre-launch Report による品質の自動検証といったビジネス価値を得られます。CI/CD パイプラインとの統合や、開発プロセス（ウォーターフォール・アジャイル）への明確な位置付けにより、持続可能な運用を実現してください。

参考リンク

[1] Google Play Console ヘルプ: テスト要件（個人アカウント向け） — https://support.google.com/googleplay/android-developer/answer/14151465
[2] Google Play Console ヘルプ: テストのセットアップ — https://support.google.com/googleplay/android-developer/answer/9845334
[3] Google Play Console 公式: クローズドテスト紹介ページ — https://play.google.com/console/about/closed-testing/
[4] Pre-launch Report の設定と使い方 — https://support.google.com/googleplay/android-developer/answer/9842757
[5] Pre-launch Report の結果の見方 — https://support.google.com/googleplay/android-developer/answer/9844487
[6] Android Developers: アプリ署名（Play App Signing） — https://developer.android.com/studio/publish/app-signing
[7] r0adkll/upload-google-play（GitHub Actions） — https://github.com/r0adkll/upload-google-play
[8] Fastlane supply: upload_to_play_store — https://docs.fastlane.tools/actions/upload_to_play_store/
[9] Triple-T/gradle-play-publisher（Gradle プラグイン） — https://github.com/Triple-T/gradle-play-publisher
[10] Bitrise: Google Play Deploy ステップ — https://github.com/bitrise-steplib/steps-google-play-deploy
[11] Google Play Developer API: Tracks リファレンス — https://developers.google.com/android-publisher/tracks
[12] Android Vitals の概要 — https://developer.android.com/distribute/best-practices/launch/vitals
[13] Google Play Console — https://play.google.com/console/
[14] Firebase Crashlytics — https://firebase.google.com/docs/crashlytics