2026年、新規開発者のためのGoogle Play公開要件

Google Playの承認は1つではありません。リリースの手前には独立した関門がいくつも連なり、関門ごとに「誰に適用されるか」のルールが違います。つまり、この先に並ぶ要件のうち、かなりの部分は自分には関係がないはずです。

以下の要件はすべて同じ4点をそろえています。誰に適用されるのか、何をするのか、何をもって完了とみなすのか、そして根拠となる公式ページはどれかです。Google自身のページどうしが食い違っている箇所（本稿では2点あります）では、こちらの推測を書かず、両方の記述をそのまま並べます。

Google Play公開要件の全体像

すべての関門を、それが自分に及ぶかどうかを決めるルールと、Play Console上で完了を示すものとあわせて並べます。条件付きと付いた行は、開発者によっては丸ごと不要です。

実際に進む順番

全部で8つのステージがあり、この順番は好みの問題ではありません。うち3つは、次のステージを始めるための前提条件です。

1. デベロッパー アカウントを選び、確認を済ませる アカウント種別、登録料、本人確認、そしてPlay Consoleに表示される場合はデバイス確認。
2. アプリを作成し、要件を満たすビルドを用意する アプリの登録とアプリケーションID、App Bundleと署名、ターゲットAPI、ビルドの事前チェック。
3. Androidデベロッパー認証への登録を確認する アプリとパッケージができたあとに、Play Consoleで状況を確認するだけの作業。
4. ストアの掲載情報と素材を仕上げる 文字数の上限、必須の画像、アイコンのマスク、AI生成素材の申告。
5. アプリのコンテンツと審査担当者用のアクセスを仕上げる プライバシー、データセーフティ、削除、レーティング、対象ユーザー、広告、全アプリ共通の2つの申告、ログイン手順。
6. 要件を満たすクローズド テストを実施する テスター12人が14日間連続でオプトイン。対象は2023年11月13日より後に作成した個人用アカウントのみ。
7. 製品版へのアクセスを申請する テスト、アプリ、準備状況について答える3部構成の質問票。
8. 製品版リリースを提出して公開する 対象国、価格、バンドル、リリースノート、審査への送信、そして公開。

1. デベロッパー アカウントを選び、確認を済ませる

まず、2段階認証プロセスを有効にしたGoogleアカウントが必要です。登録時にデベロッパー販売/配布契約とPlay Consoleの利用規約に同意します。そのうえで、公開までに3つを通過しなければなりません。登録料、本人確認、そしてPlay Consoleに表示される場合はデバイス確認です。

US$25の登録料とは何であり、何ではないのか

登録料の支払いはクレジットカードまたはデビットカードのみです。利用できるカードの種類は地域によって異なり、プリペイドカードは使えないとGoogleが明記しています。

個人用か組織用か。そして選ぶ余地がない場合

先にカテゴリの質問に答えてください。アプリによっては、そもそも選ぶ余地がありません。

どのカテゴリにも当てはまらないなら、選ぶのは自分です。どちらの種別でも公開も収益化もでき、違いの一部はGoogleが何を確認するかというだけです。ただし書類の手間だけの差ではありません。2023年11月13日より後に作成した個人用アカウントには、要件を満たすクローズド テストも課されます。これは本ガイドで最も長い、短縮のきかない項目です。詳しい比較は個人用アカウントと組織用アカウントの違いをご覧ください。

アカウントの本人確認で求められるものと、期間がぶれる理由

Googleは公開の前に、アカウント単位で本人が誰かを確認します。個人用アカウントは公的な本人確認書類を提出し、組織用アカウントはそれとあわせて組織の情報を提出します。何を求められるかは、お支払いプロファイルですでに確認済みの内容によって変わることがあります。同じガイドを読んだ2人が別々のものを求められるのは、そのためです。デベロッパーの本人確認情報を確認する

Playのアカウント本人確認について、Googleは保証された処理期間を公表していません。よく引用される「最大5日」もそれには当たらず、この数字はGoogleのお支払い関連のドキュメントに由来するもので、Playの本人確認ページのものではありません。Play Consoleに表示されるタスクを片づけ、追加の書類確認が入る前提で余裕を見てください。お支払い方法の確認はさらに別で、支払いを受け取るための販売者確認です。無料アプリのデベロッパー全員が始めなければならない手続きではありません。アカウント情報と販売者確認

完了の条件： Play Consoleに、そのアカウントの本人確認タスクが表示されなくなること。提出済みと承認済みは別の状態です。書類を出しただけでは、公開のブロックは外れません。

デバイス確認：多くのガイドが見落とす関門

新規の個人用デベロッパー アカウントには、別途デバイスのタスクがあります。アカウント所有者としてログインした状態でPlay Consoleモバイルアプリを使い、root化していないAndroid実機（Android 10以降）にアクセスできることを確認します。新しいアカウントのデバイス確認の要件

これは本人確認でもなく、要件を満たすクローズド テストでもなく、テスターに関するルールでもありません。クローズド テストに参加する12人がこの端末条件を満たす必要があるとは、どこにも書かれていません。Play Consoleのホーム画面にある独立した項目で、エミュレータでは完了できません。

完了の条件： Play Consoleのホーム画面から、デバイス確認のタスクが消えること。

後からアカウント種別を変更する

個人用デベロッパー アカウントは、Googleの確認手続きを通じて組織用アカウントに変換できます。組織のウェブサイトを確認し、組織のお支払いプロファイルを作成または選択して確認し、既存のアカウント内で変更を完了します。変換後は、新しいアプリを提出する前に72時間以上あけることをGoogleは推奨しています。逆方向、つまり組織用から個人用への変更には、新しいアカウントが必要です。アカウント種別の変更

2. アプリを作成し、要件を満たすビルドを用意する

大きく2つに分かれます。Play Consoleで作成するアプリの登録情報と、そこにアップロードする成果物です。ここでの決定のうち1つはアプリの一生についてまわるので、いま30秒かける価値があります。

後戻りできない決定

Play Consoleでアプリを作成すると、アプリ名、デフォルトの言語、アプリかゲームか、無料か有料かが決まります。アプリケーションIDはそれとは別物です。Play Consoleのフォームではなくビルド設定に置かれ、両者はアップロードの時点で初めて突き合わされます。空のアプリ登録情報がすでに確定させてくれていると思い込まず、アップロードの前にビルド側のアプリケーションIDを確認してください。アプリを作成して設定するアプリケーションID

Android App Bundleと、署名の2つの役割

通常の新規一般公開アプリでは、Google PlayはAPKではなくAndroid App Bundle（.aab）を受け付け、アプリはPlay App Signingを使います。これは絶対のルールというより、適用範囲として一度おさえておく話です。対象となる既存アプリにはAPKのワークフローが残っており、Android TVアプリでは2023年6月からApp Bundleが必須で、企業向けの限定公開アプリの配布はまた別です。Android App Bundleについて限定公開アプリ

Play App Signingは2つの役割を分けるしくみで、自分で2本の鍵を持つという意味ではありません。アプリ署名鍵はGoogleが管理し、ユーザーがインストールするものに署名します。アップロード鍵はアップロードの前にバンドルに署名し、それが自分から来たものであることをGoogleに示します。2つの役割は同じ鍵でも別々の鍵でもまかなえますが、推奨はアップロード鍵を別に用意する構成です。紛失してもリセットできるからです。アプリに署名する

端末の種類ごとのターゲットAPIレベル

アップロードそのものを止める可能性が最も高い要件です。しかも単一の数字ではなく、何を提出するかによって変わります。

Googleは、条件によっては2026年11月1日まで延長できる期間を文書で示していますが、対象になるかどうかはアプリごとにPlay Console内で判定されます。ターゲットAPIレベルの要件 移行の詳細はターゲットAPIのガイドにまとめています。

事前チェック：一見問題のないバンドルが弾かれる理由

完成したように見えるプロジェクトを引っかけるチェックが2つあります。どちらも条件付きなので、どちらも当てはまらないアプリなら読み飛ばして先へ進んでください。

ネイティブライブラリ：64ビットと16 KBのページサイズ

アプリがネイティブコードを含む場合は、直接書いたものでも、SDK経由でも、アプリビルダーが生成したものでも、64ビット対応と16 KBのページサイズへの互換性を確認し、16 KBの環境で実際にテストしてください。依存関係も含めてJavaまたはKotlinだけで書かれたアプリは、該当するページサイズにすでに対応しています。確認するのは実際にアップロードするバンドルです。自分側では何も変えていなくても、依存関係が32ビットや4 KB境界のライブラリを再び持ち込むことがあります。16 KBのページサイズ64ビット

Play Billing Libraryのバージョン

アプリがPlay Billingを組み込んでいる場合に限り、新規の提出には通常Billing Libraryのバージョン8以降が必要です。バージョン7の通常の期限は2026年8月31日で、対象となる延長が適用される場合は2026年11月1日まで延びます。この話は、Play Billingを組み込んでいないアプリにはまったく及びませんし、すでにインストールされている古いアプリが動かなくなるという意味でもありません。Billing Libraryのサポート終了スケジュール

完了の条件： 署名済みの.aabがターゲットAPIエラーも形式エラーもなくアップロードでき、バージョンコードがこれまでにアップロードしたどれよりも大きく、さらにアプリがネイティブコードを含む場合は、互換性チェックと16 KB環境での実行の両方に合格していること。Play Consoleがアップロードを検証することと、依存関係がテスト済みであることは別です。ブロックとなる問題を解消し、警告にも目を通してください。

3. Play ConsoleでAndroidデベロッパー認証への登録を確認する

これが前のステージの後に来るのは、アプリが存在していることを前提にするからです。登録は、Google Playだけでなくエコシステム全体を対象に、アプリ、つまりパッケージ名と署名鍵のフィンガープリントを、確認済みのデベロッパーIDに結びつけます。ステージ1のアカウント単位の本人確認とは別物で、そちらはアカウントを保持できる人物であることを示す手続きです。

Playで公開する側にとって、実務上の問いは狭いものです。自分のアプリは登録されているか。Play ConsoleのAndroidデベロッパー認証ページで状況を確認してください。Googleは自動登録を試み、すでに完了している本人確認を再利用するため、ほとんどのPlayデベロッパーにとっては作業ではなく状況確認で済みます。別途Android Developer Consoleのアカウントを用意する必要はなく、本人確認をやり直すこともありません。登録を確認し、そこに未対応の操作が表示されていれば片づけてください。Playのパッケージ名を登録する

未登録のままのアプリは、2026年9月30日から世界中のGoogle Playで削除の対象になりえます。ここは見落としやすい点です。この日付を扱う記事の多くは、同じプログラムの別の部分である4か国でのインストール確認しか説明していないからです。逆に、気にしなくてよいものが2つあります。無料のLimited Distributionアカウントは、ごく少数の端末に配布する趣味の開発者向けであり、Google Playへ出るための無料の抜け道ではありません。もう1つ、端末側の検証機能が対応するAndroidの下限はドキュメントによって記述が食い違っており（Android Developersのよくある質問はAndroid 7以降、AndroidヘルプはAndroid 8以降としています）、これは対応が必要な要件ではなく、Googleの2つのページ間で未解決の矛盾が残っているだけです。Androidヘルプ

完了の条件： Play ConsoleのAndroidデベロッパー認証ページでアプリが登録済みと表示され、そのアプリに未対応の操作が残っていないこと。

4. ストアの掲載情報と素材を仕上げる

掲載情報は、ユーザーと審査担当者が最初に目にするものであり、保存そのものを止める厳密な上限があります。おさえておくと役に立つ境界線は、公開のためにGoogleが必須とするものと、おすすめ掲載のためにGoogleが推奨するものの違いです。以下では両者を分けて示します。

公開に必須のもの

Google Play Console · 実際のスクリーンショット

推奨されるが、公開の条件ではないもの

Googleのプレビュー用アセットのガイダンスには、大きな表示枠やおすすめの掲載面に取り上げられる条件も書かれています。スクリーンショットを増やす、解像度を上げる、取り上げてほしいデバイスの区分ごとに一式そろえる、といった内容です。これらが欠けていてもリリースはブロックされません。Wear OS、TV、XRの掲載情報には、さらに独自の素材ルールがあります。プレビュー用アセット

アイコンの角のマスク

アップロードするのは正方形のアイコン全体で、Google Playはアイコンのサイズの30%に相当する半径で動的な角のマスクを適用します。そのため、角の近くにあるものは表示結果で切り取られます。これは現行の仕様であり、よく言われるような2026年に導入された変更ではありません。参照元ページの更新日は、ルールがいつ始まったかの証拠にはなりません。アイコンのデザイン仕様

AIで生成したストア素材の申告

掲載情報の画像、動画、宣伝素材をAIで生成または編集した場合、Play Consoleのコンテンツ作成フローには素材ごとの自己申告が組み込まれており、該当する規制の範囲に入る素材にはラベルが付きます。Googleのヘルプページには開始日も、対象となる規制の網羅的な一覧も書かれていないため、本稿でもどちらも作り出しません。これはストア素材の話であり、生成AIアプリがユーザーに対して出力する内容を規定するポリシーとは別です。AI生成コンテンツを申告する

掲載情報が却下されるメタデータのルール

Googleの掲載情報のガイダンスは、検索結果や陳列面に出る項目、つまりタイトル、アイコン、デベロッパー名、簡単な説明での宣伝的な表現に厳しい姿勢を取っています。

完了の条件： メインのストアの掲載情報が素材不足のエラーなく保存でき、アップロードした画像が角のマスクの適用後も正しく読み取れること。

5. アプリのコンテンツと審査担当者用のアクセスを仕上げる

アプリのコンテンツは、初めて公開する人が軽く見がちな部分です。エンジニアリングの作業は1つもないのに、どれもが公開を止めるからです。申告の積み重ねであり、未完了または不正確な回答は、公開が止まる最もよくある原因の1つです。

プライバシーポリシー：すべてのアプリに、2か所で必要

プライバシーポリシーはすべてのアプリに必要です。よく説明されるような、子ども向けアプリだけの話ではありません。Play Consoleにリンクを登録し、さらにアプリ内にもリンクまたはポリシー本文を置きます。URLはPDFではなく、有効で、一般に公開されていて、地域制限のかかっていないものを使ってください。データを一切収集しないアプリにも必要で、「何も収集していません」だけではポリシーになりません。アプリとデベロッパーを特定し、プライバシーに関する連絡先を示し、扱うデータがあればその取り扱いと保持についても説明する必要があります。ユーザーデータに関するポリシー

データセーフティ

クローズド、オープン、製品版のいずれかのトラックにあるアプリは、すべてデータセーフティのフォームに回答します。内部テストのトラックだけで動かすアプリは対象外で、これは早い段階で内部テストを使う実際の理由になります。何も収集しないアプリも、フォームに回答してその旨を示します。データセーフティのセクションで情報を提供する

アプリが実際に収集し共有する内容を、自分の代わりにSDKが行うことも含めて申告します。ここが最も間違えやすい部分です。分析、広告、クラッシュレポートのSDKは、自分がそのコードを書いたかどうかに関係なくデータを収集しますが、申告する責任は自分にあります。ベンダー単位でまとめて判断せず、SDKごとのドキュメントを読んでください。

アカウントとデータの削除

アプリ内でユーザーがアカウントを作成できる場合、アプリ内からも、アプリの外からも削除をリクエストできるようにしなければなりません。外からの経路とは、一般にアクセスできるウェブ上のURLです。そして、アカウントの削除は関連データの削除も伴う必要があります。法令や正当な業務上の理由で保持しなければならないものがあれば、それを開示してください。

アプリのコンテンツに残るその他の項目

上で扱ったプライバシー、データセーフティ、削除、アプリのアクセス権のほかに、次の項目が残っています。このうち2つは、名前から条件付きに見えるせいで見落とされがちです。健康アプリと金融機能の申告は、クローズド、オープン、製品版のいずれかのトラックにある通常の一般公開アプリに対して、どちらの機能も持たない場合でも必須です。どちらのフォームにも機能なしという回答があり、回答したからといって医療や金融の免許に関するルールが適用されるようになるわけでもありません。健康アプリの申告金融機能の申告

Google Play Console · 実際のスクリーンショット

審査担当者が実際に使えるアクセスを渡す

アプリの一部でもログインなどの制限の後ろにあるなら、アプリのアクセス権に記入します。Play Consoleは最大5組の手順を登録できます。これは手順のセットであって、必ずしも5組のログイン情報という意味ではありません。ログインが1つで制限付きの経路が複数ある場合に、この違いが効いてきます。アプリの審査を受ける準備をする

提出の前に、ログイン情報がまだ使えること、そして制限付きの機能すべてに自分以外の人がたどり着けることを確認してください。失効したアカウント、自分の電話にしか届かないワンタイムコード、社内アカウントでしか解放されない機能が、よくある失敗です。

完了の条件： アプリのコンテンツに未対応のタスクがなく、アプリのアクセス権に書いたとおりの情報で自分以外の人がログインできること。

カテゴリ別の申告

上のフォームに加えて、アプリが実際に何をするかによって適用されるポリシーがあります。こちらは本当に条件付きです。

• 健康アプリは、申告だけでは終わりません。アプリに実際に健康関連の機能がある場合、「健康に関するコンテンツとサービス」ポリシーにより、医療機器としての表示と、規制対象外の健康アプリに対する免責の記載が追加で求められます。また、指定された種類の健康アプリには組織用アカウントが必要です。健康に関するコンテンツとサービス
• 生成AIアプリ。禁止された出力を防ぎ、ユーザーがアプリ内で報告またはフラグを立てられる手段を用意します。これはアプリが生成するものについての話で、上のストア素材の申告とは別です。AIを利用したアプリのすべてにラベルが付くというルールでもありません。AI生成コンテンツに関するポリシー
• 写真と動画の権限。中核となる機能に必要な場合にだけ広い範囲のアクセスをリクエストし、それ以外はシステムのフォトピッカーを使います。
• 位置情報と連絡先。どちらも、具体的な日付と限定された適用範囲を伴う最小スコープの要件が控えています。期限と条件付きの変更点をご覧ください。
• その他のカテゴリ。ニュースと雑誌、金融サービス、政府アプリなどには、それぞれアプリのコンテンツからリンクされたポリシーページがあります。

6. 必要な場合は、要件を満たすクローズド テストを完了する

適用対象： 2023年11月13日より後に作成した個人用デベロッパー アカウント。組織用アカウントと、その日付より前に作成した個人用アカウントには、この要件はまったくありません。該当するならリリースの提出まで飛ばして構いません。

ルールそのものは短いです。製品版へのアクセスを申請する直前の14日間連続で、少なくとも12人のテスターがオプトインしている状態にして、クローズド テストを実施すること。テスター20人から12人への引き下げは2024年12月11日に適用され、14日間という長さはそのまま据え置かれました。テスト要件テスター20人から12人への変更

Google Play Console · 実際のスクリーンショット

トラックは3つ、要件を満たすのは1つだけ

内部テストはいかにも近道に見えますし、実際に役立ちます。ただし、この要件には使えません。

Googleが見るのは2点です。テスターの人数と、テスターのエンゲージメントです。追加のテストを求める理由としてGoogle自身が挙げる例には、テスト期間中にアプリを使っていなかったテスターが含まれます。つまり、リストに12人分の名前が並んでいることが要件なのではありません。一方でGoogleが公表していないのは、1日あたりの利用時間やセッション数に関するルールです。具体的な1日の数値をどこかで読んだとしても、それはGoogle発の情報ではありません。その数値を前提にテストを計画しないでください。

実際に満たすには

ここまでの要件は、どれも自分でコントロールできる事務作業かエンジニアリングです。これだけは違います。実機のAndroid端末を使う実在の12人が、オプトインし、14日間途切れずにオプトインしたままでいる必要があります。

完了の条件： Play Consoleにテスター12人以上がオプトイン済みと表示され、クローズド テストが14日間以上連続で実施されている状態になり、ダッシュボードで「製品版へのアクセスを申請」が使えるようになること。

7. 必要な場合は、製品版へのアクセスを申請する

適用対象： クローズド テストと同じアカウント、つまり2023年11月13日より後に作成した個人用アカウント。それ以外の方は、そのままリリースへ進みます。

クローズド テストの基準を満たしただけでは、製品版に移れるわけではありません。Play Consoleのダッシュボードから申請し、質問票に回答します。10問固定のフォームだと説明されることが多いのですが、Googleは文言を折に触れて変えています。頭の中では3つのテーマとして整理しておくほうが確実です。

実際に行ったテストをもとに書いてください。承認を保証する言い回しはありません。役に立つのは、本当のテストと本当の変更についての具体的な記述です。一般論だけの回答は、追加のテストを求められる典型的な経路として知られています。回答例は、自分のテストをどう説明するかを示すためのものであって、そのまま写す台本ではありません。

Googleは、この審査は通常7日以内だが、場合によってはそれ以上かかることがあるとしています。7日を見込みつつ、それを上限とは考えないでください。製品版へのアクセスの審査期間 アクセスが認められなかった場合、多くは却下ではなく追加のテストの要請という形になります。再申請の準備をするあいだ、クローズド テストを止める必要はありません。「さらにテストが必要」と言われたあとの進め方をご覧ください。

完了の条件： Play Consoleに製品版へのアクセスが付与されたと表示されること。その前の段階は、チェックリストを埋め終えていても、14日間をまるまる満たしていても、付与そのものではありません。判断するのはGoogleです。

8. 製品版リリースを提出して公開する

製品版へのアクセスは、適用される場合でも、トラックを解放するだけで、何かを公開してくれるわけではありません。リリースはそれ自体が一連の手順であり、すべて完了しているのに何も公開されていないという状態で人がたどり着くのが、まさにここです。リリースを準備して公開する

1. 国と地域 まず狭く始めて、あとから広げることもできます。
2. 価格 最初のリリースの前に設定します。無料アプリを、同じパッケージ名のまま後から有料にすることはできません。
3. リリースするバンドルを追加する テスト用にすでにアップロードした対象のバンドルを選ぶか、バージョンコードを上げた新しいビルドをアップロードします。テスト済みの成果物を製品版リリースに移すこと自体に、ビルドのやり直しは必要ありません。
4. リリース名とリリースノート リリース名は内部向けです。リリースノートは、このバージョンについてユーザーが目にする内容です。
5. エラーと警告を読む Play Consoleはエラーでは先に進ませず、警告は通します。どちらにも目を通してください。あとで効いてくるのは警告のほうであることが多いです。
6. 変更を審査に送信する 送信するまで、何も提出されていません。リリースのページが仕上がっているのに変更が未送信という状態は、公開が最も静かに止まるパターンの1つです。
7. 審査から公開までを見届ける 審査中、公開準備完了、公開済みは、それぞれ別の状態です。公開の管理が利用可能で有効になっている場合、承認された変更は「変更を公開」を選ぶまで待機します。承認されただけでは公開になりません。そのあと、掲載情報が実際に表示されるまでに時間がかかることもあります。

完了の条件： 公開の概要に未送信の変更がなく、製品版リリースが承認済みではなく公開済みと表示されること。公開の管理が適用される場合、その最後の操作は自分で行います。公開の管理と公開状態

公開までにかかる期間と、重ねられる作業

ゴールの手前には審査が2つあり、これらは別物です。質問票のあとの製品版へのアクセスの審査と、リリースそのものの審査です。Googleは、アクセスの審査は通常7日以内だがそれ以上かかることもあるとしており、アプリの審査も例外的なケースでは7日を超えることがあるとしています。どちらも1週間が上限というわけではありません。審査と公開のタイミング 段階ごとの目安は審査期間のガイドにまとめています。

本当に何が何を止めるのか

ここまでの大半は、どの順番で進めても構いません。例外は4つで、その4つを把握しているかどうかが、3週間で公開できるか6週間かかるかの差になります。

これはあくまで計画上の目安です

新規の個人用アカウントなら3〜5週間以上を見込むのが妥当です。これはGoogleのサービスレベルではなく当社の計画上の目安で、アプリがすでにほぼ完成していること、テスターが速やかにオプトインすること、大きな手戻りがないことを前提にしています。アプリの開発期間はこの数字に含まれておらず、手戻りが1回あればその分だけ延びます。

Play Consoleが伝えていることと、その直し方

行き詰まりのほとんどは、6種類のメッセージのどれかとして現れます。当てずっぽうで再提出する前に、自分がどれに当たるのかを読み取ってください。

段階別の準備状況チェックリスト

使っているアカウントと、いま目指している段階を選んでください。よくあるチェックリストが混ぜてしまう3つを分けて示します。いま必要なもの、あとの段階で必要になるもの、そして自分にはまったく関係のないものです。自分用の進捗管理ツールであり、Play Consoleの状態を見ているわけではありません。埋め終えても承認を意味しません。

現在の期限と、条件付きのポリシー変更

ここに挙げるのは、作るものや出す時期を変えうる、日付のついた項目です。ほとんどは自分のアプリには及びません。どれかに手をつける前に、3列目を読んでください。

期限のない、常時有効な要件

いま有効でありながら、どの「変更点」リストにも載らないものです。だからこそ、1〜2年前にこの手続きを覚えた人がつまずきます。

• クローズド テスト：テスター12人、14日間連続。対象は2023年11月13日より後に作成した個人用アカウントです。人数は2024年12月11日に20人から12人へ引き下げられました。
• アカウントの所有権の移管は、Play Consoleの移管フローを通して行います。所有者の直接移管の対象は、組織用アカウントと、収益化していない個人用アカウントです。収益化している個人用アカウントは、新しいアカウントを作ってアプリを移管する別の経路をとります。第三者を介したアカウントの売買や貸し借りは禁止されています。デベロッパー アカウントの所有権の移管
• 組織用アカウントが必須なのは、指定された金融サービス、健康、承認を受けたVpnService、政府のアプリです。
• 写真と動画の権限は、すでに適用されています。広い範囲のアクセスは中核機能に必要な場合だけにとどめ、それ以外はシステムのフォトピッカーを使います。

PolicyBytes：2026年4月のポリシー更新

上で触れた連絡先とアカウント移管のポリシー、そして位置情報と年齢制限付きコンテンツの更新について、GoogleのDeveloper Experienceチームが解説します。視聴は任意で、実務的にすべきことは表にまとめてあります。

YouTube

PrimeTestLabがクローズド テストでできること

8つのステージのうち7つは、自分でコントロールできる事務作業とエンジニアリングです。残る1つには、実機のAndroid端末を使う実在の12人が、オプトインしたうえで14日間途切れず実際に使い続けることが必要です。ソロ開発者が止まるのがこのステップであり、当社が担うのもここだけです。

お客様はクローズド テストのオプトインリンクを共有してください。招待、オプトインの確認、日々のエンゲージメント監視、14日間のフル維持、そして離脱者が出たときの補充まで当社が対応します。アプリの言語は問わず、対象国も柔軟に指定できます。

現在のプラン

返金保証 · テスト開始は通常4～6時間後 · サブスクリプションなし

よくある質問

次にすべきこと

各要件の出典

重要な主張には、それぞれの箇所で出典をリンクしています。ここはその一覧版です。Googleのヘルプページの多くは日付が示されていないため、ページの更新日はポリシーがいつ施行されたかの証拠にはなりません。

今回の改訂で変わったこと

2026年9月11日

2026年9月8日時点で確認したGoogleのドキュメントに照らして全面的に作り直し、その改訂版をさらに再監査したうえで手を入れました。修正：ターゲットAPIの要件（端末の種類別のマトリクスに変更）、クローズド テストの前提条件の順番、個人用から組織用への変換、D-U-N-S番号の所要期間、2026年9月30日の登録期限の適用範囲と、その経路（アプリができたあとにPlay Consoleで状況を確認する形）、連絡先と位置情報をAPI 37以降・2027年1月27日に改め、実装と申告の両方が必要であることを明示、アイコンとスクリーンショットとプロモーション動画の仕様、審査担当者向けアクセスは手順5組であること、アプリケーションIDはPlay Consoleの登録情報ではなくビルドの属性であること、そしてリリースの仕組み（テスト済みの対象バンドルを再利用できること、公開の管理が適用される場合は承認が公開を意味しないこと）。追加：デバイス確認、アプリ作成とリリースのステージ、ネイティブコードとPlay Billingの事前チェック、AI生成のストア素材の申告、健康アプリと金融機能の申告（該当する機能がなくても必須）、行き詰まりの一覧表、そして重要な主張ごとの出典。根拠がないため削除：2026年1月28日という健康アカウントの移行日、本人確認「5日」の俗説、2025年4月のAndroid IDの説明、宣伝用画像の1 MB上限、そして「最も避けやすい却下理由の第1位」という順位付け。準備状況チェックリストは2度作り直し、いまは「あとの段階で必要」と「該当しない」を分け、提出しただけの作業を完了とは見なさなくなりました。

2026年6月24日

初回公開。