Share
アプリのストア申請手順｜審査日数・リジェクト対策までくわしく解説
アプリのストア申請は、開発プロセスにおける“最終関門”です。
コードを書き終えただけでは、アプリはまだ世の中に公開されません。
Google Play や App Store の審査を通過して初めて、ユーザーのスマートフォンに届けることができます。
ストアに掲載されているアプリは、各プラットフォームの審査基準を満たしたものだけです。
そのためユーザーは安心してインストールできますが、裏を返せば、開発者側はストアごとの明確なルールを理解していなければ公開できないということでもあります。
ストア申請で重要になるのは、次の2点です。
アプリをストアに申請する具体的な方法
審査を通過するために必要な情報と手順
本記事では、Android（Google Play）および iOS（App Store）の2大ストアにアプリを公開するための手順を、実際の管理画面の流れに沿って解説します。さらに、審査にかかる平均日数や、よくあるリジェクト理由とその対策まで整理します。
アプリ開発の外注先をお探しの方へ
ストア申請まで見据えたアプリ開発には、設計・実装だけでなく、各ストアの審査基準への理解や公開後の運用設計も欠かせません。
Rabilooでは、小売・業務アプリを中心に、企画設計から開発、ストア申請、公開後の運用・保守まで一貫して支援しています。
「開発リソースが足りない」
「ストア申請対応までまとめて任せたい」
といったお悩みをお持ちでしたら、ぜひ一度ご相談ください。
Google playにストア申請する手順
Android向けアプリは、Google Playを通じてユーザーに提供されます。
その管理プラットフォームが Google Play Console です。
Google Play Consoleでは、アプリ情報の登録、審査申請、公開管理、アップデート配信までを一元管理します。
ここでは、アプリをGoogle Playに登録し、公開するまでの流れを順を追って解説します。
ステップ 1
Google Play Console
https://play.google.com/console にアクセスしてログインします。
初めて利用する場合は、Google Playデベロッパーアカウントの登録が必要です。
登録には、1回限り25ドル（USD）の登録料がかかります。
※法人で登録する場合は、会社情報の入力や本人確認手続きが求められます。
ステップ 2
ログイン後、「All apps」画面が表示されます。
新規アプリを作成する場合 → 右上の「Create app」を選択
既存アプリの更新を行う場合 → 該当アプリを選択
アプリを作成したら、左側メニューの 「General」→「App information」 から、ストア掲載に必要な基本情報を入力していきます。
まずは アプリ名、デフォルト言語、アプリ種別（App / Game）、料金（無料 / 有料） などの項目を設定します。
アプリ名
Google Play上に表示される名称です。
価格表記・ランキング文言・過度な装飾や絵文字は使用できません。
デフォルト言語
アプリの主要言語を選択します。
多言語対応する場合も、基準となる言語をここで設定します。
カテゴリ（Category）
アプリの種類に応じてPrimaryカテゴリを選択します。
必要に応じてSecondaryカテゴリも設定できます。
例：ビジネス、教育、ショッピングなど。
料金の有無
「無料」または「有料」を選択します。
※有料→無料への変更は可能ですが、無料→有料への変更はできません。
アプリ名は後から変更可能です
しかし パッケージ名（アプリID）は作成後に変更できません
パッケージ名は将来的なブランド展開やアプリ拡張も考慮し、慎重に設計しましょう。
入力が完了したら、利用規約に同意し、「アプリ作成」をクリックします。
ステップ3：リリースの作成と設定
アプリを選択したら、左側メニューの「Release」から「Production」を選択します。
初回リリースの場合は、画面右上の「Create new release」をクリックして、新しいリリースを作成します。
「Create new release」をクリックすると、以下の画面が表示されます。
本番環境に公開する場合は「Production」を選択します。
既に公開済みのアプリを更新する場合も、この画面からバージョンアップを行います。
リリーストラックの種類
Google Playでは、アプリは「Draft（下書き）」状態から各リリーストラックへ進み、審査を経て公開されます。
いきなり全ユーザーへ公開するのではなく、段階的に検証を行える設計になっているのが特徴です。
利用できるリリーストラックは次の4種類です。
内部テスト（Internal testing）
社内メンバーなど、限定されたテスター向けに配布するトラックです。
最大100人まで追加でき、審査も比較的迅速に行われます。
重大な不具合や基本動作確認など、技術的な初期検証フェーズに適しています。
クローズドテスト（Closed testing）招待した特定ユーザーに配布します。
Googleの審査を経て公開されるため、本番環境に近い形での実践的なテストが可能です。
実際の利用シナリオやUX検証に向いています。
オープンテスト（Open testing）
Google Play上でテスターを募集できるトラックです。
本番公開前に幅広いユーザーからフィードバックを得たい場合に利用します。
本番公開（Production）
一般ユーザー向けに正式公開するトラックです。
審査を通過すると、指定した国・地域でアプリが公開されます。
初回リリースでは
内部テスト → クローズドテスト → Production
という順で段階的に進めるのが実務上のセオリーです。
品質リスクを抑えながら公開することが、企業アプリ運用では重要になります。
リリースファイルのアップロード
次に、「新しいリリースの作成」または「リリースの編集」を選択します。
ここで、アプリの AAB（Android App Bundle）ファイル をアップロードします。
AABはAndroidアプリのプログラム全体を含むパッケージ形式です。
従来利用されていたAPKと異なり、AABには次の特徴があります。
・端末ごとに最適化された構成のみが配信されるため、アプリサイズが軽量化される
・セキュリティ保護が強化される
・アップデート管理が効率化される
現在、Google Playでは新規アプリはAAB形式での提出が必須です。
ストア要件は随時更新されるため、最新の公式ガイドラインを確認することが重要です。
リリース情報の入力
AABファイルのアップロード後、リリース情報を入力します。
リリース名
Google Play上には表示されません。
管理用名称で、デフォルトではアップロードしたバンドル名が自動入力されます。
リリースノート
今回の変更内容や修正点を記載します。
ユーザーに表示されるため、簡潔かつ具体的に書きましょう。
例： ・ログイン不具合の修正
・パフォーマンス改善
・新機能「〇〇」の追加
開発者情報の入力
続いて、ストア上に表示される開発者情報を入力します。
Developer name：Google Playに表示される開発者名（50文字以内）
Physical address：連絡先となる住所。有料アプリやアプリ内課金を提供する場合は正確な登録が必須
Website address：公式WebサイトのURL
※住所情報に不備があると、公開停止やアカウント制限の対象になる可能性があります。
プライバシーポリシーの登録
アプリのプライバシーポリシーURLを登録します。
ユーザーデータの取り扱いについて明示することは、審査通過のためだけでなく、ユーザーからの信頼確保のためにも重要です。
未公開ページや内容不備は、審査差し戻しの原因になります。
URLには実際に公開されているWebページを入力します。
入力が完了したら、「保存」→「リリースの確認」を選択し、審査提出へ進みます。
Declarations（宣誓事項）の確認
リリースを審査に進める前に、「Declarations（宣誓事項）」で各チェック項目を確認・同意します。
主な確認項目は次のとおりです。
・Developer Program Policies：Google Playのポリシーに準拠していることを確認
・Play App Signing：AAB公開に必要な利用規約への同意
・US export laws：暗号化等に関する輸出規制への同意
※この画面でチェックできない場合、アカウント権限（Owner / Adminなど）が不足している可能性があります。
ステップ4：ロールアウト設定
リリース内容を確認したら、公開範囲と配信割合を設定します。
■ ロールアウトパーセンテージ（Staged roll-out）
本リリースを適用するユーザーの割合を指定します。
通常は「100％」を選択し、すべての対象ユーザーへ一斉公開します。
ただし、利用者数が多いアプリや、大規模な機能追加・仕様変更を含むアップデートの場合は、以下のように段階的に配信するケースもあります。
10％ → 30％ → 50％ → 100％
これを「ステージドロールアウト（Staged roll-out）」と呼びます。
段階的に公開することで、
・重大な不具合の早期発見
・クラッシュ率やユーザー行動のモニタリング
・万が一の影響範囲の限定
が可能になります。
企業アプリやユーザー数が多いサービスでは、リスク管理の観点から段階配信が推奨されます。
■ 国 / 地域（Country availability）
アプリを公開する国・地域を選択します。
「Available in all targeted countries」を選択すると、事前に設定している対象国すべてに公開されます。
特定の地域のみに公開したい場合は、「Select specific countries / regions」を選択し、個別に指定します。
海外展開を行う場合は、ストア説明文・プライバシーポリシー・法規制への対応状況も合わせて確認しましょう。
ステップ5：審査へ提出
すべての設定内容を確認後、「Review release」から本番環境への展開を開始します。
問題がなければリリースを確定し、Googleの審査プロセスへ進みます。
Google Playの審査期間は通常数時間〜3営業日程度ですが、
・新規アカウント
・個人情報を扱うアプリ
・金融・ヘルスケア系アプリ
などは審査が長引く傾向があります。
審査状況はGoogle Play Console上で確認できます。
Google Playでよくあるリジェクト理由
Google Playは自動審査の割合が高いものの、ポリシー違反には非常に厳格です。
特に以下の理由で公開停止や差し戻しになるケースが多く見られます。
① デベロッパーポリシー違反
禁止コンテンツ（暴力・差別・違法行為など）
誤解を招く説明文や誇張表現
実装されていない機能をストアに記載
・Google Playデベロッパーポリシーを事前に確認
・スクリーンショットと実装内容を一致させる
② プライバシーポリシー未整備
プライバシーポリシーURLが未登録
実際のデータ取得内容と記載が一致していない
広告SDKや解析SDKの説明不足
特に「個人情報」「位置情報」「連絡先」などを扱う場合は要注意です。
③ 権限（Permissions）の過剰要求
不要なカメラ・マイク・位置情報権限
背景での位置情報取得の不明確な説明
ストレージへの広範なアクセス
Googleは最小権限の原則（Least Privilege）を重視しています。
使用理由はアプリ内とポリシーの両方で明示する必要があります。
④ スパム・低品質アプリ判定
ほぼ同じ内容のアプリを複数公開
WebViewのみの簡易アプリ
コンテンツが極端に少ない
価値が低いと判断されるとリジェクト対象になります。
⑤ 課金・広告ポリシー違反
Google Play Billingを使わないデジタル販売
外部決済への誘導リンク
誤認を招く広告表示
デジタルコンテンツ販売は原則Google Play Billingの使用が必須です。
⑥ 不安定・クラッシュ
初回起動時クラッシュ
特定端末・OSバージョンでの動作不良
ANR（Application Not Responding）多発
自動審査で検出されるケースもあります。
実務上のポイント
Google Playは「自動検知」が多いため、
ポリシー違反
権限説明不足
SDK未申告
このあたりで止まるケースが非常に多いです。
Appleよりも審査は速い傾向にありますが、
ポリシー違反があると即時公開停止になるリスクもあるため注意が必要です。
App Storeにアプリを申請する手順
iOSアプリを一般公開するには、Appleの審査を通過する必要があります。
そのための管理プラットフォームが「App Store Connect」です。
App Store Connectでは、アプリ情報の登録、バージョン管理、審査申請、公開設定までを一元的に管理します。
ここでは、アプリの新規登録から審査提出までの具体的な流れを解説します。
ステップ1：App Store Connectにログイン
App Store Connect（https://appstoreconnect.apple.com）にアクセスし、Apple IDでログインします。
開発者アカウントをお持ちでない場合は、Apple Developer Programへの登録が必要です。
Apple Developer Programの登録費用は年間99ドルです。
法人登録の場合は、以下の情報が求められます。
・法人名
・D-U-N-S番号
・代表者情報
登録審査には数日かかる場合があります。
ログイン後、App Store Connectの管理画面が表示されます。
新規アプリを作成する場合は「My Apps」を選択します。
ステップ2：アプリの新規作成
まだアプリを作成していない場合は、「My Apps」を選択し、右上の「＋」→「New App」をクリックします。
ここでアプリの基本情報を入力します。
入力項目
Platform：通常は「iOS」を選択します。iPadOSやmacOSを同時に管理することも可能ですが、まずはiOSを選択して問題ありません。
Name：App Storeに表示されるアプリ名です（30文字以内）。商標や既存アプリとの重複には注意が必要です。
Appleは類似名称にも敏感なため、事前に検索確認を行いましょう。
Primary Language：アプリの主要言語を選択します。
後から多言語対応を追加することも可能ですが、最初に設定した言語が基準となります。
Bundle ID：Xcodeで設定済みのBundle Identifierと一致させます。
※Androidの「パッケージ名」に相当する識別子です。
Bundle IDは一度登録すると変更できません。
アプリのブランド展開や将来的な拡張も見据えて設計しましょう。
SKU：App Store Connect内で管理する内部識別IDです。App Store上には表示されません。
作成後に変更できないため、
「companyname_appname_ios_v1」など、社内で一意に管理できる命名規則を決めておくと安全です。
User Access：アプリ管理の権限設定です。通常は「Full Access」を指定します。
チーム開発の場合は、後から役割ごとに権限を分けることも可能です。
すべて入力したら「Create」をクリックしてアプリを作成します。
作成後、アプリの管理画面へ遷移します。
ステップ3：バージョン情報の設定と審査準備
リリース対象バージョンの選択
「App Store」タブを開き、リリース対象となるバージョン（例：1.0）を選択します。
ここが App Store申請における基本情報入力のスタート地点 です。
新規アプリの場合は、最初のバージョン（通常は1.0）を作成します。
既存アプリの更新の場合は、＋ボタンから新しいバージョンを追加します。
基本情報の入力
バージョンをクリックすると編集画面が表示されます。
まずは必須となる基本情報を入力します。
Version
公開するバージョン番号を入力します。
例：1.0 / 1.0.1 / 2.0 など
Copyright
コピーライト表記を入力します。
通常は「© 2026 Company Name」の形式で記載します。
Routing App Coverage File（必要な場合）
マップやナビゲーション機能を提供するアプリの場合に必要となるファイルです。
該当しない場合は入力不要です。
プレビュー・スクリーンショットの登録
基本情報を入力したら、「App Previews and Screenshots」セクションへ進みます。
・iOSはデバイスサイズごとに推奨スクリーンショットサイズが異なります
・代表的な解像度（例：6.7インチ / 5.5インチ）を用意すれば基本的に対応可能
・画像形式はRGBカラーのJPGまたはPNG
スクリーンショットは審査通過だけでなく、ダウンロード率にも直結します。
単なる画面キャプチャではなく、利用価値が伝わる構成にすることが重要です。
ストア掲載情報（テキスト項目）
続いて、App Store上に表示されるテキスト情報を入力します。
主な入力項目
■ プロモーションテキスト
アップデートを提出せずに変更できる紹介文です。
現在のアプリの魅力を短く伝えます。
■ キーワード
検索結果に影響する重要項目です。
カンマ区切りで入力します。
■ 説明
アプリの詳細説明です。
機能・対象ユーザー・利用シーンを明確に記載します。
■ サポートURL
ユーザー向けサポートページのURL
■ マーケティングURL
公式サイトやプロモーションページURL
これらのテキストは、検索表示順位やダウンロード率に直接影響します。
審査情報（App Review Information）
Apple審査担当者がアプリを検証するための情報を入力します。
■ Sign-In Information
ログインが必要なアプリの場合は、
テスト用アカウント（ID・パスワード）を必ず入力します。
ここが空欄だと審査が停止するケースが非常に多いため注意が必要です。
■ Contact Information
審査中に問題が発生した場合の連絡先を入力します。
■ Notes
審査担当者向けの補足説明を記載します。
例： ・特定機能の操作手順
・外部サービス連携のテスト方法
・ログイン後の遷移説明
丁寧に書くほど審査がスムーズになります。
■ Attachment
デモ動画や補足資料を添付できます。
複雑なアプリの場合は、動画を添付すると理解が早まります。
リリースタイミングの設定
審査通過後の公開方法を選択します。
選択肢
Manually release this version：審査通過後、手動で公開します。
Automatically release this version：審査通過後、すぐに自動公開されます。
Automatically release this version after App Review, no earlier than：審査通過後、指定日時以降に公開されます。
Appleの審査期間は変動するため、
公開日が決まっている場合は公開方法を慎重に選びましょう。
ステップ4：審査へ提出
すべての入力と設定が完了したら、
「Submit for Review（審査のために提出）」
を選択します。
これでAppleの審査プロセスが開始されます。
App Storeでよくある審査落ちパターン
App Storeの審査は年々厳格化しています。
特に以下のポイントで差し戻し（リジェクト）になるケースが非常に多いです。
① テスト用ログイン情報の不備
最も多いリジェクト理由です。
ログイン必須アプリなのにテストアカウント未記載
ワンタイムコードが届かない
2段階認証で審査担当がログインできない
審査環境でサーバーが動いていない
・審査専用アカウントを用意する
・2段階認証はオフにする
・Notes欄に操作手順を書く
② プライバシーポリシーの不備
URLが存在しない
アプリ内のデータ収集内容と記載が一致しない
Cookieやトラッキングの記述が不足
子ども向けアプリなのにCOPPA未対応
・実際のデータ取得内容と一致させる
・アプリ内SDK（Firebase等）の記載も忘れない
③ スクリーンショットと実際のUIが一致しない
古いバージョンの画面を掲載
存在しない機能を掲載
「近日公開」機能を表示している
Appleは「誤解を招く表示」に非常に厳しいです。
④ 課金まわりのルール違反
外部決済への誘導リンク
Web課金への直接誘導
AppleのIAPを使わずにデジタルコンテンツ販売
これは一発リジェクト率が高いです。
⑤ アプリがクラッシュする
初回起動でクラッシュ
特定OSバージョンで動作しない
審査用実機で不具合発生
Appleは「再現性のある不具合」に厳格です。
⑥ 最低限の機能しかないアプリ
WebViewのみの簡易アプリ
テンプレート量産アプリ
コンテンツが空の状態
「価値が低い」と判断されると却下されます。
⑦ 利用規約・年齢制限の未設定
ギャンブル・医療・金融関連で適切な警告がない
年齢レーティングが不適切
審査通過率を上げるための実務ポイント
✔ 提出前にTestFlightで必ず実機検証
✔ Notes欄に審査手順を書く
✔ 機能制限がある場合は説明する
✔ サーバーは必ず本番相当で稼働させる
実際の現場では、
「機能の問題」より
「説明不足」「ログイン不可」「ポリシー不備」
で落ちるケースが圧倒的に多いです。
つまり、
技術より“申請設計
App StoreとGoogle Playの審査期間比較
アプリ公開スケジュールを組むうえで重要なのが、ストアごとの審査スピードの違いです。
App Store（iOS）
平均：1〜3営業日
90％は48時間以内に完了
初回リリースはやや長め（2〜4日）
医療・金融・暗号資産系は審査が厳格で時間がかかる傾向
リジェクト後の再審査は比較的早い（1〜2日）
Appleは人的レビュー（Human Review）が中心のため、審査のばらつきがあります。
Google Play（Android）
平均：数時間〜3営業日
初回リリースは1〜3日
アップデートは比較的早い（数時間〜1日）
自動審査＋人手レビューのハイブリッド方式
Googleは自動審査の割合が高いため、通常はApp Storeよりも早い傾向にあります。
ただし、新規アカウントやポリシーに敏感なカテゴリでは、数日かかる場合があります。
実務上のスケジュール設計のポイント
公開日が決まっている場合は、少なくとも1週間前に両ストアへ提出
iOSを基準にスケジュールを組むのが安全
大型連休・年末年始は審査が遅れる可能性を想定する
リジェクトを想定し、再提出期間をバッファに含める
ストア審査は技術力だけでなく、申請設計と準備の質で差が出ます。
まとめ
アプリのストア申請は、単なる「アップロード作業」ではありません。
Google PlayとApp Storeそれぞれに異なる審査基準があり、
リリーストラックの選択、権限設定、プライバシーポリシー整備、スクリーンショット設計、課金ルールの遵守など、公開前に確認すべき項目は多岐にわたります。
特に近年は、個人情報保護や課金ポリシーの厳格化により、
「実装は問題ないのに申請で止まる」というケースも少なくありません。
ストア審査をスムーズに通過させるためには、
各ストアの最新ガイドラインの把握
リジェクトを想定した事前設計
公開スケジュールを見据えた申請管理
といった、開発以外の視点も重要になります。
アプリ開発・ストア申請でお困りの方へ
Rabilooでは、小売・業務アプリを中心に、
設計・開発からストア申請、公開後の運用まで一貫してサポートしています。
「申請で何度も差し戻されている」
「ストア要件まで含めて任せられる開発パートナーを探している」
「社内リソースが不足している」
といったお悩みをお持ちでしたら、下記のフォームよりぜひ一度ご相談ください。
関連記事：
▶︎CodePushをアプリに組み込んで得られる【５つのメリット】
Share