個人でAndroidアプリをGoogle Playに公開する完全ガイド（2025）

はじめに――みなさん、はじめての「Google Play公開」までを一気に俯瞰しましょう

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

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

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

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

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

1. 開発者アカウントの準備（最新ルール対応）

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

Google Play の開発者登録では、個人か組織かを選び、本人確認・連絡先・決済情報を登録します。
2023年以降、新規に作成された個人アカウントには、後述のクローズドテスト要件（12名・14日連続オプトイン）が課されます。
組織アカウントでは、法的情報の入力や（場合により）企業識別の入力が求められることがあります。

1-2. 請求・税務情報

有料アプリやアプリ内課金を扱う場合、決済口座や税務情報（各国の税ルールに応じた申告）が必要です。収益化は後回しでも構いませんが、先にテスト運用で品質を固めるのがおすすめです。

ミニまとめ：開発者アカウントは“アプリの法人格”のようなもの。本人確認と連絡手段を明確にし、あとで慌てないように基本情報を整えておきます。

2. アプリ公開の技術準備

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

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

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

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

2-3. ターゲット API レベル（最新要件）

2025年8月31日以降の新規公開・更新には、API レベル 35（Android 15） のターゲットが必要です。古いターゲットのままだと公開できない／新規ユーザーに表示されなくなる場合があります。

2-4. リリースビルドの基本

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

ミニまとめ：技術面の関門は「AAB」と「署名」と「API レベル」。ここを間違えなければ、提出の土台は整います。

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

3-1. アプリを作成

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

3-2. 国/地域・価格

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

3-3. 端末カテゴリ

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

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

4. ストア掲載情報とポリシー申告（ここがボリューム大）

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

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

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

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

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

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

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

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

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

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

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

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

5-1. テストの種類

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

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

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

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

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

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

Q：14日間の途中でビルドを差し替えるとテストやり直し？

A：公式要件は「連続14日間オプトイン」。ビルド差し替え自体のリセット規定は明記されていません。テスターが離脱しない運用（通知・手順の明確化）が肝です。

Q：要件を満たしたのに “もっとテストを” と言われた

A：テスター数や連続性に加え、テスターの関与度（実際に使われたか）も見られます。フィードバックの要約や改善内容を Production 申請時に丁寧に記述しましょう。

Q：内部/クローズド/オープンに同じ tester を入れてもよい？

A：内部に参加中のユーザーは他トラックを受け取れない仕様です。クローズドで回したいときは内部からオプトアウトしてもらいます。

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

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

6-1. Production access の申請

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

6-2. レビューと結果

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

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

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

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

7. 公開後の運用

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

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

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

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

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

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

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

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

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

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

ポイント：常時アクセス可能・編集不能な静的ページにする（CMS の閲覧専用公開や静的ホスティング）。PDF は不可、地域制限も不可なので注意です。

付録A：そのまま使えるチェックリスト

準備

[ ] 開発者アカウント登録・本人確認完了（個人/組織）
[ ] プロジェクトのパッケージ名確定（公開後は変更不可）
[ ] ターゲット API 35（Android 15）を満たす
[ ] 署名：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 更新

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

ビルド設定

build.gradle（app）で minifyEnabled true、shrinkResources true を設定（必要に応じて）。
versionCode を増分、versionName を更新。

署名設定

Play App Signing に登録済みであることを前提に、アップロード鍵の keystore/alias を準備。

AAB 生成

Android Studio：Build → Generate Signed Bundle / APK… → Android App Bundle → Next
keystore/alias を選択し、Release を指定 → Finish

アップロード

Play Console → Testing（Internal/Closed） へ .aab をアップロード → Release ノート添付 → 保存/公開。

mapping.txt のアップロード（難読化利用時）

Android Vitals でのクラッシュ解析に役立つため、Deobfuscation files にアップロード。

付録C：よくある“勘所”まとめ

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

おわりに

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

自叙伝ドットコム

あなたの人生は書く価値がある。

AIにだから語れる、本当の自分がある。記憶の断片を拾い集め、ひとつの物語へ。

覗いてみる