App StoreとGoogle Playへの公開は、完成したファイルをアップロードするだけの作業ではありません。
開発者登録、署名、ストア情報、プライバシー申告、テスト用アカウント、審査対応、段階配布をOSごとに準備します。
実装中から該当する審査条件をテストへ入れ、公開直前の差し戻しを減らしてください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 項目 | App Store | Google Play |
|---|---|---|
| 開発者側の登録 | Apple Developer Program | Play Console開発者アカウント |
| 提出成果物 | 署名済みiOSビルド | 署名済みAndroid App Bundleなど |
| 管理画面 | App Store Connect | Play Console |
| テスト、配布 | テスト配布と審査提出 | テストトラックと公開管理 |
| 継続作業 | ガイドライン、証明書、SDK対応 | 対象API、署名、ポリシー対応 |
二つのストアで共通する準備と異なる条件を分ける
共通するのは、アプリ識別、署名、説明、画像、プライバシー情報、問い合わせ先、審査用の操作手順です。
異なるのは登録制度、署名方式、提出形式、管理画面、テスト配布、審査項目です。
| 準備物 | 共通の目的 | ストア別に分けるもの |
|---|---|---|
| アプリ識別 | 既存アプリと更新を対応 | Bundle IDとApplication ID |
| 署名 | 配布者と成果物を確認 | 証明書、鍵、管理方法 |
| ストア情報 | 利用者へ機能を説明 | 画像寸法、入力項目、地域 |
| 審査情報 | 主要機能を再現 | テストアカウント、補足手順 |
| 配布 | 対象利用者へ届ける | テストトラック、段階公開 |
iOS側ではApp Review Guidelinesを実装前から確認します。
安全性、動作、ビジネス、デザイン、法的要件など、該当部分を要件とテストへ変換してください。
Android側ではAndroid Developersの公開準備が、リリース設定、署名、テスト、配布を順に説明しています。
Debugビルドで動くことと、署名済みのRelease成果物が正しく動くことを分けて確認します。
登録から公開までを七段階で進める
ストア登録を最後の担当者へ丸投げせず、技術、法務、デザイン、運用の成果物を一つの計画へまとめます。
- 個人または組織の開発者登録と権限を準備する
- アプリ識別子、署名鍵、証明書、担当者を確定する
- 署名済みのReleaseビルドを対象実機で試す
- 名前、説明、画像、カテゴリ、問い合わせ先を用意する
- プライバシー、課金、広告、年齢区分を実装と照合する
- テストアカウントと主要機能の操作手順を添える
- テスト配布、審査、段階公開、監視、戻し方を実行する
Appleの登録条件と現在の費用はApple Developer Programの参加案内で確認します。
Google Play側はPlay Consoleの開始案内を使い、本人確認を含む登録条件を確認してください。
組織登録では、退職や異動に備えて契約者、管理者、公開担当、請求担当を分けます。
一人の個人メールと端末だけで、鍵と管理権限を保持しないことが重要です。
二ストアと六成果物の確認件数を出す計算例
次の数字で、同じ情報を一度作れば両ストアへ自動反映されるという見落としを防ぐと仮定しましょう。
アプリ名、説明、画像、プライバシー情報、問い合わせ先、審査手順の6成果物を、2ストアで確認するとします。
基本確認は6成果物×2ストアで12件です。
日本語と英語の2言語へ公開するなら、文言と画像の言語確認は12件×2言語で24件になります。
| 確認範囲 | 計算 | 件数 |
|---|---|---|
| 一言語、二ストア | 6成果物×2 | 12 |
| 二言語、二ストア | 12件×2言語 | 24 |
入力欄の有無や画像条件はストアごとに異なるため、単純なコピーで完了にしません。
公開日、版、言語、確認者をチェック記録へ残してください。
審査担当者が主要機能を再現できる情報を渡す
ログインしないと使えないアプリでは、期限内に利用できるテストアカウントを用意します。
二段階認証、組織招待、外部機器、位置制限がある場合は、審査環境で再現できる方法を説明してください。
説明文と画面が一致しない状態も避けます。
未提供の機能を画像へ載せず、地域、端末、契約による制限を利用者と審査担当者が理解できるようにします。
課金や収益化の条件は、古い手数料記事から転記しません。
Google Playではサービス手数料に関する公式案内を使い、対象取引と現在のプログラム条件を確認します。
Apple側も審査ガイドラインとプログラム条件を現在の公式情報で照合します。
規約判断に迷う機能は、公開直前ではなく要件定義時に専門家やストア窓口へ確認してください。
公開後の監視と次回更新を初回版から準備する
公開操作の成功と、利用者が正常に使えることは別です。
クラッシュ、ログイン成功率、重要操作、問い合わせ、課金、外部APIエラーを公開直後に重点監視します。
段階公開やテストトラックを使い、異常があった場合の配布停止、前版、サーバー側機能停止を決めます。
ストア上で前版へ即時に戻せるとは限らないため、サーバー側の機能フラグや互換性も用意してください。
公開版ごとに、ソース版、署名情報、ストア入力、審査回答、公開日時、既知の問題を残します。
次回更新で同じ質問へ回答できるよう、審査とのやり取りも運用記録に含めます。
Android公開の具体的な順序は公式公開ドキュメントを更新ごとに確認してください。
iOS側も最新のApp Review Guidelinesを読み直します。
App Store、Google Play公開でよくある質問
ストアへ登録すればすぐ公開できますか？
登録後にアプリ情報、署名済み成果物、審査情報をそろえ、各ストアの確認や審査を通します。
Google Playの登録開始はPlay Console公式案内で現在の条件を確認してください。
二つのストアで同じ画像と説明を使えますか？
内容を共通化できても、入力欄、画像条件、端末表示、言語、審査向け補足は別に確認します。
ストアごとのプレビューで、文字切れと現在版との不一致がないかを見てください。
審査に落ちたら別のアプリとして登録しますか？
通常は指摘理由を読み、対象機能、説明、操作手順を修正して同じアプリの提出を更新します。
iOSでは公式の審査ガイドラインと指摘箇所を照合し、変更内容と再現手順を明確に回答してください。
署名と審査再現をそろえてから二ストアへ公開する
ストア公開の完成条件は、管理画面で提出ボタンを押したことではありません。
正しい権限で署名された版が審査環境で再現され、公開後の監視と更新担当まで引き継がれている状態です。
- 二ストアで共通する識別、署名、説明、画像、プライバシー、審査情報
- ストアごとに分ける登録、提出形式、テスト配布、審査条件
- 組織で管理する契約者、管理者、公開担当、請求担当、署名鍵
- 公開版の記録に必要なソース版、入力情報、審査回答、日時、既知問題
海外向けのストア情報も用意するなら、多言語対応アプリの翻訳、表示、テスト手順でアプリ内とストアの言語資産を一緒に管理できます。
