個人でAndroidアプリをGoogle Playに公開する完全ガイド──API 36必須化とクローズドテスト12人×14日【2026年版】

はじめに

はじめて Android アプリを Google Play に公開する――これは技術的にも運用的にも「複合プロジェクト」です。コードは動くのに、コンソールでやることが想像以上に多い、と感じる方がほとんどでしょう。本ガイドは事実ベースで、2026年8月時点の最新要件に沿って、初公開までのマイルストーンを講義形式で整理します。最後に「そのまま使えるチェックリスト」も付けます。

たとえば「同人誌を頒布する準備」に例えると、作品（アプリ）が完成しても、表紙（ストア素材）、年齢区分（コンテンツレーティング）、注意書き（プライバシーポリシー）を整え、知人にレビュー（クローズドテスト）を頼み、出展許可（Production access）を得る、といった段取りが要ります。コード以外の"用意"が成功の鍵です。

全体像：6つのマイルストーン

1. 開発者アカウントとプロジェクトの技術準備（本人確認・支払い情報・ターゲットAPI・署名・Android App Bundle）
2. Play コンソールでのアプリ作成と基本設定（パッケージ名・国/地域・価格）
3. ストア掲載情報とポリシー申告（データセーフティ・プライバシーポリシーURL・ターゲット年齢・広告）
4. テスト運用（内部/クローズド/オープン、特に新規個人アカウントの「12人×14日」要件）
5. 審査申請〜本番リリース（Production access 申請・段階的ロールアウト）
6. 公開後の運用（Android Vitals・クラッシュ解析・レビュー返信・アップデート）

やることは多いですが、順番に進めれば必ず到達できます。本ガイドの章立てに沿って、淡々と進めましょう。

1. 開発者アカウントとプロジェクトの技術準備

1-1. 個人/組織アカウントと本人確認

• Google Play の開発者登録では、個人か組織かを選び、本人確認・連絡先・決済情報を登録します。
• 2023年11月13日以降に新規作成された個人アカウントには、後述のクローズドテスト要件（12名・14日連続オプトイン）が課されます。これは2026年8月現在も変わっていません。
• 組織アカウントでは、法的情報の入力や企業識別の入力が求められることがあります。
• 有料アプリやアプリ内課金を扱う場合は決済口座や税務情報が必要です。収益化は後回しでも構いませんが、先にテスト運用で品質を固めるのがおすすめです。

1-2. パッケージングは「APK」ではなく Android App Bundle（AAB）

• Google Play では新規アプリは AAB 形式での公開が前提です（APK 単体では公開できません）。
• Android Studio では Build → Generate Signed Bundle / APK… → Android App Bundle を選び、署名付きの .aab を生成します。

1-3. 署名（App Signing）とアップロードキー

• 新規アプリは Play App Signing の利用が前提です。プロジェクトの「本番署名鍵」は Google 側に保管され、開発者はアップロード鍵で署名して AAB を提出します。
• 既存サービス（Google サインイン等）を使う場合は、SHA-1 証明書の設定（OAuth クライアント等）を忘れずに。アップロード鍵とアプリ署名鍵の区別に注意しましょう。

1-4. ターゲット API レベル（2026年の重要な切り替わり）

ここが2025年版から最も変わったポイントです。

• 2026年8月現在の新規公開・更新には、API レベル35（Android 15）以上が最低条件です。
• さらに 2026年8月31日以降は、新規アプリ・アップデートともに API レベル36（Android 16）以上^[1]へのターゲットが必須になります。準備が間に合わない場合は、Play Console のポリシーステータスページから2026年11月1日までの延長を申請できます。
• 既存アプリも、新しいAndroid端末上で新規ユーザーに配信され続けるには API 35 以上を維持する必要があります。
• Wear OS は API 35 以上、Android TV・Android Automotive OS・Android XR もそれぞれ個別の期限とAPIレベルが定められているため、対象プラットフォームがある場合は Play Console のヘルプで最新の表を確認してください。

1-5. リリースビルドの基本

• Build variant を release に切替え、minify（R8）・リソース圧縮を有効に。難読化を使う場合は mapping.txt を Play Console にアップロードしておくと、クラッシュ解析が読みやすくなります。
• versionCode はアップデートごとに増分、versionName は表示用。テスト/本番で最も高い versionCode が端末に配信されます。

2. Play コンソールでのアプリ作成と基本設定

2-1. アプリを作成

• Play Console の Home → Create app から新規作成。
• デフォルト言語・アプリ名 を設定し、アプリ/ゲーム・無料/有料 を選択します（後から一部変更可）。

2-2. 国/地域・価格

• 配信したい国/地域を選びます。課金や年齢制限ポリシーは国によって異なるため、当面は主要ターゲット国から始めるのが運用しやすいです。

2-3. 端末カテゴリ

• Phone/Tablet、Large screens（タブレット/Chromebook）、Wear OS、TV など、フォームファクターごとに配布可否やスクリーンショット要件が異なります。まずは Phone から着手し、順次広げるのが定石です。

ミニまとめ：コンソール上の基本設定は"公開先の地図"。最初はシンプルに、後で拡張できるようにしましょう。

3. ストア掲載情報とポリシー申告

3-1. ストア素材（最低限）

• アプリアイコン：512×512（PNG、アルファ可）
• 機能グラフィック：1024×500（PNG/JPEG）
• スクリーンショット：Phone/Tablet/Wear/TV ごとに追加。Large screens（タブレット/Chromebook）は最低4枚が推奨・要件になります。Wear/TV は最低1枚と TV バナー等の追加要素が必要です。
• テキストは短く具体的に（先頭3行は特に重要）。

3-2. データセーフティ（Data safety）

• 公開前にデータの収集・共有・暗号化・削除方法などを申告します。サードパーティ SDK の挙動も含め、実装と申告の不一致はリジェクト原因になります。

3-3. プライバシーポリシー URL（必須条件の整理）

• URL はログイン不要で誰でもアクセス可、常時公開、地理制限なし、編集不可な静的ページが要件です。PDF は不可と明記されています。
• 例：自サイト（S3+CloudFront、GitHub Pages、静的ホスティング等）に /privacy を用意し、全アプリで共通化して管理すると運用が楽です。アプリ固有の差分はセクション分けで追記します。

3-4. ターゲット年齢とコンテンツレーティング

• Target audience & content と Content rating の2段を正しく回答します。子ども（13歳未満）を含む場合は Families ポリシー（自己認証 SDK など）への準拠が必須です。
• レーティングは IARC 方式で各地域の機関（PEGI/ESRB 等）によって自動付与されます。虚偽申告は掲載停止の対象です。

3-5. アプリ内容の宣言（Ads・アクセス保護・制限付き権限）

• アプリに広告があるか、ログインやアクセス制限があるか、バックグラウンド位置情報などの制限付き権限を使うか、を正しく申告します。該当時は追加の宣言フォームやドキュメント提出が求められます。

ミニまとめ：ここは"法務・広報・CS"の領域。書いてあることと実装が一致しているかを何度も見直しましょう。

4. テスト運用：種類と要件（新規個人アカウントはここが要）

4-1. テストの種類

• 内部テスト（Internal）：最速配布。最大100名のテスターをメールアドレスで指定します。初期 QA に最適。
• クローズドテスト（Closed）：メールリストや Google グループでテスターを管理。大きめのフィードバック収集に向きます。
• オープンテスト（Open）：Play 上にテスト版を一般公開。誰でも参加可能。※Production access（本番アクセス）獲得後に利用できます。

4-2. 新規個人アカウントの必須要件（12人×14日）

• 要件：少なくとも12名のテスターが連続14日間クローズドテストにオプトインしていること。
• 重要なポイント：要件は「テスターの連続オプトイン」に紐づきます。ビルド更新やストア文言の微修正それ自体でカウントがリセットされるという公式記載はありません。ただし、12人が同じ14日間の窓の中で重なっている必要があり、途中でテスターがオプトアウトして人数が割れば、その時点でカウントは崩れます（再オプトインしても非連続となるため注意）。
• オープンテストは要件クリア後に解禁です。先にクローズドをしっかり回しましょう。

4-3. 実務：テスター募集と運用のコツ

• 招待導線：クローズドのオプトインURLを共有。Google グループでの管理も有効（参加者をリスト化できる）。
• コミュニケーション：テスター向けに「試してほしい機能」「再現手順の書き方」「連絡先（メール/フォーム）」を明示。Play のテストフィードバック機能も活用しましょう。
• 複数テストの同時運用：同一アプリで複数のクローズドトラックを平行可能。内部テスターは内部テストに参加中は他のトラックを受け取れない点に注意。

4-4. よくある落とし穴（Q&A）

• Q：14日間の途中でビルドを差し替えるとテストやり直し？
• Q：要件を満たしたのに「もっとテストを」と言われた
• Q：内部/クローズド/オープンに同じテスターを入れてもよい？

A：公式要件は「連続14日間オプトイン」。ビルド差し替え自体のリセット規定は明記されていません。テスターが離脱しない運用（通知・手順の明確化）が肝です。 A：テスター数や連続性に加え、テスターの関与度（実際に使われたか）も見られます。フィードバックの要約や改善内容を Production 申請時に丁寧に記述しましょう。 A：内部に参加中のユーザーは他トラックを受け取れない仕様です。クローズドで回したいときは内部からオプトアウトしてもらいます。

ミニまとめ：テストは"人数×継続×関与度"。数字だけでなく使われ方の記録も残しましょう。

5. 審査申請〜本番リリースの流れ

5-1. Production access の申請

• クローズド要件を満たしたら、Dashboard → Apply for production から申請。3セクション（Closed test / App概要 / Production readiness）に回答します。
• 回答では、テスター募集の容易さ/関与度/得られたフィードバック/反映内容を具体的に記述します。保存せず離脱すると未保存になる点に注意。

5-2. レビューと結果

• レビューは通常数日で完了（変動あり）。不足があれば「継続テスト」を求められることがあります（人数不足・関与度不足など）。
• 承認されると Production と Open testing が解放されます。まずは段階的ロールアウト（例：5%→20%→50%→100%）で品質メトリクス（クラッシュ率/ANR）を監視しましょう。

5-3. 配信ロジックの基本

• ユーザーには、自分が参加しているトラックの中で最も高い versionCode のビルドが配信されます。内部参加者は内部版しか受け取れない点に注意。

ミニまとめ：申請は「レポート提出」。数と質（フィードバックの扱い）を両輪で示すのが合格への近道です。

6. 公開後の運用

6-1. Android Vitals とプレローンチレポート

• Play の Pre-launch report（自動試験）で起動・画面崩れ・権限ダイアログの問題を早期検出。公開後は Android Vitals でクラッシュ/ANR を継続監視します。

6-2. レビューとユーザー対応

• レビュー返信は24〜72時間以内が理想。頻出課題はFAQやアプリ内ヘルプに反映し、ストア説明文も継続改善します。

6-3. アップデート運用

• 小さな修正はクローズドで先行検証→段階的ロールアウトで本番配信、のリズムを確立しましょう。
• ターゲット API の年次更新（2026年8月31日以降はAPI 36）は締切前に確実に対応を。

ミニまとめ：公開後は「計測→改善→検証→配信」のサイクル。運用体力がアプリ寿命を伸ばします。

付録：チェックリストと実務Tips

コラム：プライバシーポリシーは"共通ページ"を用意すると楽

プライバシーポリシーは毎回書き直すより、共通骨子を1ページにまとめるのが運用効率的です。たとえば example.com/privacy に以下の章を設けます。

• 収集するデータ（連絡先・使用状況・広告ID 等）
• 目的（機能提供・分析・広告）
• 共有の有無（第三者 SDK との共有・匿名化）
• 暗号化・保存期間・削除方法（アプリ内/問い合わせ）
• 連絡先（メール）
• 各アプリ固有の差分

ポイント：常時アクセス可能・編集不能な静的ページにする。PDF は不可、地域制限も不可なので注意です。

そのまま使えるチェックリスト

準備

• [ ] 開発者アカウント登録・本人確認完了（個人/組織）
• [ ] プロジェクトのパッケージ名確定（公開後は変更不可）
• [ ] ターゲット API 35以上、2026年8月31日以降はAPI 36（Android 16）を満たす
• [ ] 署名：Play App Signing 登録、アップロード鍵運用
• [ ] リリースビルド（minifyEnabled true、不要リソース削除）
• [ ] AAB 生成（Generate Signed Bundle）

ストアとポリシー

• [ ] アプリアイコン 512×512、機能グラフィック 1024×500
• [ ] スクリーンショット（Phone 必須。Large screens は最低4枚、Wear/TV は最低1枚＋TVバナー）
• [ ] データセーフティの申告（SDK 含む）
• [ ] プライバシーポリシー URL（常時公開・静的・非PDF）
• [ ] ターゲット年齢・コンテンツレーティング回答（IARC）
• [ ] 広告・アクセス保護・制限付き権限の宣言

テスト

• [ ] 内部テスト（最大100人）で初期 QA
• [ ] クローズドテストを開始（オプトインURL/Google グループ）
• [ ] 12人が14日間連続でオプトインしていることをモニタ
• [ ] フィードバック収集・要約・改善記録

申請・配信

• [ ] Dashboard から Apply for production に回答（3セクション）
• [ ] 承認後、段階的ロールアウト（例：5%→20%→50%→100%）
• [ ] Pre-launch report / Android Vitals を監視
• [ ] レビュー返信・FAQ 更新

Android Studioでのリリース AAB 作成手順（実務）

1. ビルド設定：build.gradle（app）で minifyEnabled true、shrinkResources true を設定（必要に応じて）。versionCode を増分、versionName を更新。
2. 署名設定：Play App Signing に登録済みであることを前提に、アップロード鍵の keystore/alias を準備。
3. AAB 生成：Android Studio：Build → Generate Signed Bundle / APK… → Android App Bundle → Next → keystore/alias を選択し、Release を指定 → Finish
4. アップロード：Play Console → Testing（Internal/Closed） へ .aab をアップロード → Release ノート添付 → 保存/公開。
5. mapping.txt のアップロード（難読化利用時）：Android Vitals でのクラッシュ解析に役立つため、Deobfuscation files にアップロード。

よくある"勘所"まとめ

• APK を上げても受け付けられない→ 新規公開は AAB 必須。
• Open testing を先に使いたい→ Production access 獲得後に利用可。まずはクローズドで 12人×14日。
• 14日カウントのリセットが不安→ 条件は「12人が同じ14日間の窓で重なっていること」。ビルド更新の是非ではなく、連続性に注目して運用。
• 「もっとテストを」と言われた→ 人数/連続性だけでなく 関与度 を示す。機能別の使用状況、既知課題、改善履歴を申請フォームに整理。
• プライバシーポリシーの設置場所→ 自サイトの静的ページが最も運用しやすい。PDF/認証制限/地域制限は不可。
• ターゲット API 忘れ→ 年次で要件が上がる。2026年8月31日以降はAPI 36。ビルド前に targetSdk を必ず確認。

おわりに

初公開の壁は"情報の量"です。しかし、手順に落とし込めば必ず前進します。本ガイドのチェックリストをそのままタスク化し、クローズドテストで「人数×継続×関与度」を満たすこと。ここをクリアすれば、Production access の扉は開きます。公開後は Android Vitals とユーザーフィードバックで品質を磨き続けましょう。

なお、同じ内容をiOS側で整理した個人でiOSアプリをApp Storeに公開する完全ガイドもあります。iOSは年会費とMacという入口が重く、Androidは12人×14日というテスト要件が重い、という非対称があるため、両方に出す予定なら並行して読むと段取りを組みやすくなります。

参考文献・出典

1. [1]Play Console ヘルプ, Target API level requirements for Google Play apps. ↩
2. [2]Android Developers, Meet Google Play's target API level requirement. ↩
3. [3]Android Developers, About Android App Bundles. ↩