メインコンテンツへスキップ

2026年版アプリ審査ガイドライン:AppleとGoogle Playの初回申請チェックリスト

2026年の初回申請向けアプリ審査ガイドライン。Apple App StoreとGoogle Playの審査期間、ガイドライン項目、デモアカウント、プライバシー、よくあるリジェクト理由を解説します。

2026年版アプリ審査ガイド:Apple App StoreとGoogle Playへの初リリースに向けたチェックリスト Capgo ブログ用イラスト

簡単に言うと: アプリ審査ガイドライン は、アプリをリリースする前にAppleとGoogleが適用する審査ルールです。Appleの審査は、 App Storeの審査ガイドライン 以下のカテゴリに分類されています: 安全性、パフォーマンス、ビジネス、デザイン、および法的要件。Google Playは、リリース内容を デベロッパープログラムポリシーが および、コンテンツレーティングやデータセーフティなどのPlay Consoleの要件に照らして審査します。 審査時間: Appleによると、App Reviewは24時間体制で行われており、通常、少なくとも 申請の50%が24時間以内に完了し、 と 90%が48時間以内に完了します。 (アプリ審査ガイド). Googleによると、一部のアカウントでは待機が発生する場合があります 最大7日間、あるいはそれ以上 例外的なケースとして(アプリを公開する)。また、新しい個人用Play Consoleアカウントでは、少なくとも 14日間連続で参加し続ける12名以上のテスターが、 クローズドテストにおいて必要となります。 本番環境への申請時には、 少なくとも12名が参加している状態である必要があります。 初回のリジェクト(却下)は 多くの場合、以下の原因に起因します 2.1 アプリの完成度 (クラッシュ、リンク切れ、デモアカウントの不備など) 2.3 メタデータの正確性や 5.1 プライバシー iOSでの不備、さらにAndroidでのPlayポリシーやテスト手順の不足。詳細は ガイドライン 4.2 および 4.3 戦略については、以下を参照してください。 2026年にApp Storeの審査を通過する方法。評価やペアレンタルコントロールについては、次を参照してください: App Storeの年齢制限ガイド。登録料については、以下を参照してください。 App Storeへのアプリ公開コスト.

初めてのアプリをApp StoreやPlay Storeに申請するのは、圧倒されるかもしれません。ガイドラインは常に変化し、2026年はより厳しく運用されるため、承認には細部への注意が欠かせません。このチェックリストでは、iOSとAndroidの初回申請でレビュアーが確認する点を解説します。さらに詳しいAppleの却下対策プレイブックは、当社の 2026年にApp Storeの審査を通過する方法 ガイドを、この概要以上のガイドライン詳細が必要なときにご覧ください。

2026年の審査プロセスを理解する

近年、AppleとGoogleはプライバシー、セキュリティ、ユーザーエクスペリエンスを重視し、審査プロセスを大幅に厳格化しています。初めてアプリをリリースする開発者にとって、これらの変更を理解しておくことは非常に重要です。

iOS App Store の審査タイムライン

Appleは審査時間を アプリ審査ガイド ページで公開しています:

  • 一般的な審査時間:申請の少なくとも50%が24時間未満、90%が48時間未満で審査完了
  • 提出内容の不備: メタデータ、デモ用のアクセス情報、コンプライアンス回答が欠けていると、審査が遅れたり通らなかったりする可能性があります
  • 複雑なアプリ: Appleは、より詳細な審査が必要なアプリは時間がかかる可能性があると述べています(提出後の流れ)
  • 優先審査: App Store Connectで提出し、以下のフォームからリクエストを送信すれば、重大なバグ修正や期間限定イベントに利用できます Appleの迅速審査リクエストフォーム

公開されている平均値をもとに計画し、体験談ベースの審査待ちの急増に惑わされず、レビューノートの不足はすべて遅延リスクとみなしてください。

App Store Connect で表示されるステータス

  • 提出準備中: ビルドまたはメタデータの準備中です
  • 審査待ち: Apple の審査キューに並んでいます
  • 審査中: レビューチームがアプリを審査しています
  • デベロッパによるリリース待ち: 承認済みですが、手動リリースの選択待ちです
  • 却下 / 未解決の問題: 承認前に修正が必要です

Google Play Store の審査タイムライン (2026年版)

Googleによる審査期間の記載 アプリを公開する:

  • 標準的な公開: レビュー完了後、速やかにアップデートが処理・公開されます
  • レビューの長期化: 一部のデベロッパーアカウントでは、Googleによる審査に 最大7日間、または例外的にそれ以上の時間がかかる場合があります
  • クローズドテストの要件: 2023年11月13日以降に作成された個人アカウントは、少なくとも 12名のテスターが14日間以上連続で参加し続ける クローズドテストが必要で、さらに 本番環境へのアクセスを申請する時点で、少なくとも12名のテスターが引き続き 参加している必要があります
  • テスト終了後: アプリの公開前に、Playのポリシーに沿った本番審査が引き続き行われます

重要なお知らせ: Googleは現在、一部の新規Play Consoleアカウントに対してかなり厳格なテストを求めており、これについては以下で詳しく説明します。

Apple Developer Account のセットアップ

最初のiOSリリースを行う前に、Apple側の設定が正しく完了しているか確認してください:

  • 以下に登録してください: Apple Developer Program
  • 登録に使用するApple Accountで2ファクタ認証を有効にする
  • 適切なメンバーシップタイプを選択してください:
    • 個人 / 個人事業主: App Storeの販売者名が、あなたの法的な個人名になります
    • 組織: 法人、D-U-N-S番号、公開ウェブサイト、およびAppleとの契約を締結する権限を持つ担当者が必要です
  • 登録時は本名を使用してください。姓名欄に別名や会社名を入力すると、承認が遅れる可能性があります。
  • 登録が承認されたら、App Store Connectにサインインし、最終的なbundle ID、アプリ名、SKU、プライマリ言語でアプリレコードを作成してください。

Apple Developer Program 登録ページ

WebでAppleの登録を続行

適切なApple Developerエンティティタイプを選択

重要: AppleはSDKの最小要件を随時変更します。 2026年4月28日時点では、App Store Connectにアップロードするアプリは iOS & iPadOS 26 SDK 以降を.

Android テストの重要な要件

使用する必要があります。初めてAndroidで公開する開発者が最も戸惑う変更点はこれです:

新規個人 Android アカウントの 12 人テスター要件

Google Play デベロッパーアカウントが 2023年11月13日以降に作成された個人アカウントの場合、アプリを本番環境にリリースする前に、クローズドテスト期間を完了する必要があります:

要件:

  • 最低12名のテスター: 継続的にテストに参加し続けるテスターが少なくとも12名必要です
  • 14日間のテスト期間: アプリがクローズドテスト中である少なくとも連続した14日間、テスターが参加状態を維持する必要があります
  • 本番環境へのアクセス申請: 申請時、クローズドテスト期間終了後も少なくとも12名のテスターが参加している必要があります
  • フィードバックの収集: 見つかった問題、行った修正、テスターがアプリをどう使ったかを記録しておきましょう

テストトラックの設定方法

  1. クローズドテストトラックの作成

    • Google Play Consoleにアクセス
    • テストとリリース > テスト > クローズドテストへ移動
    • クローズドテストトラックで新しいリリースを作成
    • Android App Bundleをアップロードしてください(.aab)
  2. テスターの募集

    テスターの探し方:

    • 友人や家族(最も手軽な方法)
    • 開発者コミュニティ(Redditの /r/androiddev、/r/betatests)
    • SNSのフォロワー
    • ベータテストプラットフォーム(BetaList, BetaTesting.com)
    • 大学生(コネクションがある場合)

    重要テスターの条件を確認:

    • 有効なGmailアカウントを持っていること
    • 実際にAndroidデバイスを使用していること
    • 14日間、継続してオプトイン状態を維持すること
  3. テスターを招待する

    • Play Consoleでテスターリストを作成する
    • テスターのメールアドレスを追加する
    • テスターにオプトインURLを共有する
    • アプリのインストールと利用を促すリマインダーを送る
  4. テスト活動をモニタリング

    • Play Consoleでインストール数を確認
    • クラッシュレポートとANR(Application Not Responding)を追跡
    • テスターからのフィードバックを収集
    • 本番昇格前に致命的な問題を修正
  5. 本番環境に昇格

    • 申請時点で、少なくとも12名のテスターが引き続きオプトインしており、かつ直前14日間継続してオプトインしている必要があります
    • Play Consoleのダッシュボードから本番アクセスを申請する
    • すべてのクラッシュレポートとフィードバックを確認
    • 本番リリースを作成し、最終レビューに提出

Google がこの要件を導入した理由

Googleがこの要件を導入した目的は:

  • 低品質なアプリのスパムを削減
  • ユーザーに届く前にアプリのテストを徹底
  • 実際の利用パターンから悪意のあるアプリを特定する
  • Play Store全体の品質を向上させる

現実チェック: これにより、リリースまでのスケジュールが少なくとも2〜3週間延びます。余裕を持った計画を立て、早めにテスターを確保しましょう。

認証とログインの要件

リジェクトされる最も一般的な理由の一つは、認証システム、特にソーシャルログインの実装不備です。

Sign in with Apple の要件(iOS では必須)

Appleの規約: アプリがサードパーティのソーシャルログイン(Google、Facebook、Twitterなど)を提供している場合、 必ず Sign in with Appleも選択肢として提供する必要があります。

これは以下に適用されます:

  • Google Sign-In
  • Facebook Login
  • Twitter/X ログイン
  • LinkedInログイン
  • その他のサードパーティ認証サービス

以下には適用されません::

  • メールアドレスとパスワードのみの認証
  • 政府発行の身分証明システム
  • エンタープライズSSO(特定の企業向けアプリの場合)
  • 教育機関の認証システム

Sign in with Apple の実装

ソーシャルログインを使用している場合は、以下の実装が必要です:

import { SignInWithApple } from '@capacitor-community/apple-sign-in';

async function signInWithApple() {
  try {
    const result = await SignInWithApple.authorize({
      clientId: 'com.yourapp.service',
      redirectURI: 'https://yourapp.com/auth/callback',
      scopes: 'email name',
      state: '12345',
      nonce: 'nonce',
    });

    // result contains:
    // - identityToken
    // - authorizationCode
    // - email (may be null if user previously authorized)
    // - givenName
    // - familyName

    // Send to your backend for verification
    await verifyAppleToken(result.identityToken);

  } catch (error) {
    console.error('Apple Sign In failed:', error);
  }
}

重要な考慮事項:

  1. メールアドレスのプライバシー:ユーザーはメールアドレスを非表示にできます。Appleはプライベートリレー用のメールアドレス(例: abc123@privaterelay.appleid.com)を提供します。アプリ側でこれに対応する必要があります。

  2. 初回ユーザーとリピーターの違い:Appleがユーザー詳細(名前、メールアドレス)を提供するのは初回認証時のみです。2回目以降のサインインでは含まれないため、この情報を保存してください。

  3. ボタンのデザイン:Sign in with Appleボタンには厳格なデザインガイドラインがあります。公式のアセットを使用してください。

  4. バックエンドでの検証:IDトークンは必ずバックエンドサーバーで検証してください。クライアント側のトークンのみを信頼してはいけません。

Android ソーシャルログインの要件

AndroidはiOSのように特定のプロバイダーを必須としていませんが、Googleのガイドラインがあります:

Google Sign-Inの要件:

  • 公式のGoogle Sign-In SDKを使用すること
  • Googleのブランディングガイドラインに従うこと
  • 提供する場合は主要な選択肢にすること

クロスプラットフォームのベストプラクティス: 一貫性を保つため、両方のプラットフォームで同じログインオプションを提供してください:

  • メールアドレス/パスワード
  • Sign in with Apple (iOSのみ、またはWebベースのAppleログインをサポートする場合はAndroidでも可)
  • Google でサインイン
  • その他のソーシャルオプション (Facebook、Twitterなど)

デモアカウントの要件

審査における重要事項: アプリにログインが必要な場合は、 必ず App Review Notesに動作確認用のデモ用認証情報を記載してください。

Demo Account Information:

Username: reviewer@demo.com
Password: ReviewTest123!

OR

Test Phone: +1 555-0123
Test OTP: 123456 (static for review)

Notes:
- This account has full premium features enabled
- All payment flows work in sandbox mode
- Account will reset daily

よくある間違い:

  • 期限切れの認証情報を提供してしまう
  • デモアカウントで全機能にアクセスできない
  • 電話番号認証の回避方法を記載していない
  • サンドボックス決済の詳細を記載し忘れる

現在、両方のアプリストアでアクセス可能なプライバシーポリシーと利用規約が必須となっています の前に 最初の申請が承認されます。

プライバシーポリシーの要件

プライバシーポリシーの要件:

  1. 公開されていること

    • ログイン不要の公開URLでホストされていること
    • 標準的なWebブラウザで閲覧できること
    • アプリと同じ言語で提供されていること
  2. 以下の必須項目を網羅すること:

    • 収集するデータの内容(具体的に記載)
    • 収集したデータの利用目的
    • 第三者へのデータ提供の有無
    • データの保持期間
    • ユーザーの権利(アクセス、削除、ポータビリティ)
    • プライバシーに関するお問い合わせ先
    • 子どものプライバシー(アプリが13/16歳未満のユーザー向けの場合)
  3. アプリ内にリンク

    • 設定またはアカウント画面からアクセスできること
    • ワンタップで到達できること(メニューの奥に埋もれさせない)
    • デフォルトブラウザまたはアプリ内ブラウザで開くこと

プライバシーポリシーのホスティング先

オプション1:自社ウェブサイト (推奨)

https://yourapp.com/privacy-policy
https://yourapp.com/terms-of-service

オプション2:GitHub Pages (無料)

https://yourusername.github.io/app-privacy-policy

オプション3: プライバシーポリシー生成ツール (クイックスタート)

重要: ジェネレーターは最初の作成には便利ですが、実際のデータの取り扱いを正確に反映したポリシーにしてください。アプリに合わない汎用テンプレートは指摘の対象になります。

利用規約の要件

利用規約は常に必須ではありませんが、作成を強く推奨します。以下に該当する場合は必須です:

  • アプリ内課金やサブスクリプションを提供する場合
  • ユーザー生成コンテンツ(UGC)がある場合
  • アプリの基本機能以外のサービスを提供する場合
  • 法的保護を希望する場合

必須項目:

  • 適正利用ポリシー
  • アカウント終了条件
  • 責任の制限
  • 知的財産権
  • 紛争解決プロセス
  • 返金ポリシー(特にIAP)

アプリ内実装

// Settings or Account Screen
function LegalLinks() {
  return (
    <div className="legal-section">
      <h3>Legal</h3>
      <a
        href="https://yourapp.com/privacy-policy"
        target="_blank"
        rel="noopener noreferrer"
      >
        Privacy Policy
      </a>
      <a
        href="https://yourapp.com/terms-of-service"
        target="_blank"
        rel="noopener noreferrer"
      >
        Terms of Service
      </a>
      <a
        href="https://yourapp.com/contact"
        target="_blank"
        rel="noopener noreferrer"
      >
        Contact Us
      </a>
    </div>
  );
}

App Store メタデータ要件

両ストアとも、アプリ申請時にプライバシーポリシーのURLを提出する必要があります:

iOS - App Store Connect:

  • アプリ情報 > 基本情報 > プライバシーポリシーURL
  • HTTPS必須(HTTPは拒否されます)
  • App Storeのページに表示されます
  • ユーザーが連絡できるサポートURLを追加してください
  • 申請前に年齢制限のアンケートに回答してください

Android - Google Play Console:

  • ストアの掲載情報 &gt; ストアの設定 &gt; プライバシー ポリシー
  • 子供向けアプリには必須
  • すべてのアプリに強く推奨

プライバシーラベル (iOS)

iOSでは「栄養ラベル」形式での詳細なプライバシー開示が必要です:

必ず申告すべきカテゴリ:

  • 連絡先:メールアドレス、氏名、電話番号
  • 財務情報:支払い情報、クレジットカード、銀行口座
  • 位置情報:正確な位置情報またはおおよその位置情報
  • ユーザーコンテンツ:写真、動画、音声、メッセージ
  • 識別子:ユーザーID、デバイスID、広告ID
  • 利用データ:製品の操作、広告データ、クラッシュログ
  • 診断情報: クラッシュデータ、パフォーマンスデータ

データ型ごとに指定:

  • 収集の有無
  • ユーザーIDとの紐付けの有無
  • トラッキング目的での使用有無
  • 収集の目的

よくある間違い: 分析用の SDK がデータを収集しているのに、データを収集していないと申告してしまうこと。すべてのサードパーティSDKのデータ収集状況を監査してください。

Google Play データ セーフティ セクション

iOSと同様、Androidでもデータ セーフティの申告が必要です:

ステップ:

  1. Play Console > アプリのコンテンツ > データ セーフティに移動
  2. データ収集に関する質問に答える
  3. 収集するデータの種類を指定する
  4. セキュリティ対策(暗号化など)を説明する
  5. プライバシーポリシーへのリンクを提供する

重大: この情報は法的拘束力を持ちます。虚偽の申告は、アプリの削除やアカウント停止につながる可能性があります。

初回審査でよくあるリジェクト理由

アプリがリジェクトされる理由を理解することで、以下の落とし穴を回避できます:

1. アプリのクラッシュまたは起動不可

なぜ起こるのか:

  • 実機ではなくエミュレータのみでテストしている
  • ネットワーク障害のエラーハンドリングが不足している
  • 到達できないAPIエンドポイントのハードコード
  • 特定のデバイス機能(カメラ、GPS)を前提にする

防止策:

// Always implement proper error handling
async function loadData() {
  try {
    const response = await fetch('https://api.yourapp.com/data');

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    const data = await response.json();
    return data;

  } catch (error) {
    // Show user-friendly error
    showError('Unable to load data. Please check your connection.');

    // Log for debugging
    console.error('Data load failed:', error);

    // Graceful degradation
    return getCachedData();
  }
}

テストチェックリスト:

  • 実機でテスト(最低2〜3種類のモデル)
  • 低速ネットワークでテスト(Network Link Conditionerを使用)
  • 機内モードでテスト
  • 権限を拒否した状態でテスト
  • クリーンインストールでテスト(キャッシュなし)

2. 主要機能の欠落または動作不良

なぜ起こるのか:

  • スクリーンショットに未実装の機能がある
  • デモ用アカウントで広告機能が使えない
  • プレミアム機能が表示されているが未実装
  • アプリ内に「Coming Soon」の表示がある

防止策:

  • 全機能が完成してから申請すること
  • デモ用アカウントに全権限があるか確認する
  • 未完成の機能は削除または無効化する
  • 最新のビルドとスクリーンショットを一致させる

3. 年齢レーティングに不適切なコンテンツ

なぜ起こるのか:

  • 年齢レーティングが4+なのに、アプリにソーシャル機能がある
  • 年齢レーティングが実際のコンテンツと一致していない
  • モデレーションのないユーザー生成コンテンツ (UGC)
  • モデレーションされていない外部コンテンツへのリンク

正しい年齢レーティングの設定方法:

iOSの年齢レーティング:

  • 4+ (不適切なコンテンツなし)
  • 9+ (時折、軽微なコンテンツあり)
  • 12+ (中程度のコンテンツ)
  • 17+ (頻繁または激しいコンテンツ)

Androidのコンテンツレーティング:

  • すべてのユーザー
  • 10歳以上
  • ティーン
  • 17歳以上
  • 18歳以上限定

重要ユーザー同士でコンテンツを共有できる場合、以下が必要です:

  • コンテンツモデレーションシステム
  • 通報・ブロック機能
  • 明確なコミュニティガイドライン
  • 必要に応じた年齢制限

4. 誤解を招くメタデータ

なぜ起こるのか:

  • アプリ名で存在しない機能をうたっている
  • 競合他社のスクリーンショットやモックアップの使用
  • 偽のレビューや評価の操作
  • 根拠のない誇大表現が説明文に含まれている

問題のあるメタデータの例:

❌ NG例:

  • アプリ名: 「最高のフィットネストラッカー - No.1アプリ」
  • 説明文: 「史上最高に驚異的で革命的なアプリが登場!」
  • スクリーンショット: ありきたりなストックフォト

✅ OK例:

  • アプリ名: 「FitTrack - ワークアウト記録」
  • 説明文: 「カスタマイズ可能なルーチンと進捗チャートでワークアウトを記録しましょう。」
  • スクリーンショット:現在のビルドの実際のアプリ画面

5. テスト不足 (特にAndroidのクローズドテスト)

なぜ起こるのか:

  • 必須の14日間テスト期間をスキップしている
  • テスターの数が不足している
  • テスターが実際にアプリを使用していない
  • テスト中にクラッシュ監視を行っていない

防止策:

  • リリース予定の3〜4週間前からテスターを募集する
  • テスト中に Firebase Crashlytics などを使用する
  • テスターと積極的にコミュニケーションを取る(アンケート、フィードバックフォーム)
  • 本番環境へ移行する前に致命的な問題を修正する

6. 正当な理由のない権限要求

なぜ起こるのか:

  • 位置情報を要求するだけで使用していない
  • 説明なしのカメラ権限
  • 目的が不明確な連絡先へのアクセス
  • ナビゲーション機能のないアプリでのバックグラウンド位置情報

修正方法:

iOS - Info.plist:

<key>NSCameraUsageDescription</key>
<string>Camera access is required to scan QR codes for quick login.</string>

<key>NSLocationWhenInUseUsageDescription</key>
<string>Location helps us show nearby fitness centers and outdoor running routes.</string>

<key>NSPhotoLibraryUsageDescription</key>
<string>Photo library access lets you upload a profile picture and share workout photos.</string>

Android - パーミッション戦略:

<!-- Only request what you actually need -->
<uses-permission android:name="android.permission.CAMERA" />

<!-- Use when-in-use rather than always for location -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<!-- Avoid if possible -->
<!-- <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> -->

実行時パーミッションのリクエスト:

import { Camera } from '@capacitor/camera';

async function takePicture() {
  // Request with context
  const permissionStatus = await Camera.requestPermissions();

  if (permissionStatus.camera === 'granted') {
    const photo = await Camera.getPhoto({
      quality: 90,
      allowEditing: true,
      resultType: 'uri'
    });

    return photo;
  } else {
    // Explain why permission is needed
    showDialog(
      'Camera access required',
      'To upload a profile picture, please enable camera access in Settings.'
    );
  }
}

iOS特有の要件

App Storeのスクリーンショットとプレビュー

必要なサイズ:

  • 6.7” iPhone: 1290 x 2796
  • 13” iPad: 2064 x 2752
  • 12.9” iPad: 2048 x 2732

重要: アプリがiPadに対応している場合は、iPad用のスクリーンショットをアップロードする必要があります。iPhone用のスクリーンショットをiPad用に引き伸ばして使用しないでください。

スクリーンショットのベストプラクティス:

  • 実際のアプリ画面を表示すること(モックアップは不可)
  • ステータスバーを非表示にするか、リアルな内容を表示する
  • サポートされているすべての言語でローカライズする
  • 過剰なテキストの重ね表示を避ける
  • 最初の2〜3枚のスクリーンショットで主要機能を伝える

App Store Connectのメタデータ設定

提出前に、App Store Connectの以下の項目を完了させてください:

  • プライバシーポリシーURL: iOSアプリでは必須です
  • サポートURL: 必須項目です。実際の問い合わせ先に繋がるようにしてください
  • 年齢制限: アプリを公開するためにアンケートに回答してください
  • App Review情報: レビュー担当者の連絡先、ログインが必要な場合は動作するデモ用の認証情報、レビューチーム向けの明確なメモを追加してください
  • 輸出コンプライアンス: 暗号化に関する質問に回答するか、設定してください ITSAppUsesNonExemptEncryption における Info.plist 適切な場合に設定すれば、uploadのたびに同じ回答を繰り返さずに済みます

App Review前のTestFlight

本番レビュー前に、TestFlightで実際に一通り確認しましょう:

  • TestFlightから全く同じビルドをインストールする
  • 提出予定のレビュー用アカウントでサインインする
  • 購入、復元、キャンセルのフローを一通り確認する
  • 隠れた設定なしで、レビュアーが主要機能にアクセスできるか確認する
  • 両方サポートしている場合は、iPhoneとiPadの両方でテストする

要件:

  • 15〜30秒程度
  • 実際のアプリの映像を必ず含めること
  • 短いテキストオーバーレイは使用可能
  • 著作権に問題のある音楽を使用しない
  • スクリーンショットと同じ解像度にする

Sign in with Appleの実装

前述のとおりですが、ソーシャルログインがある場合はiOS審査で極めて重要です。

アプリ内課金の要件

デジタル商品やサービスを提供する場合:

必須の開示事項:

  • 購入前に価格を明確に表示する
  • サブスクリプションの規約を明記する
  • 解約方法を表示する
  • 「購入を復元」ボタン

規約に準拠したサブスクリプション画面の例:

function SubscriptionOffer() {
  return (
    <div className="subscription-screen">
      <h2>Choose Your Plan</h2>

      <PlanCard>
        <h3>Monthly</h3>
        <p className="price">$9.99/month</p>
        <ul>
          <li>Unlimited workouts</li>
          <li>Personalized plans</li>
          <li>Progress tracking</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <PlanCard>
        <h3>Annual</h3>
        <p className="price">$79.99/year</p>
        <p className="savings">Save 33%</p>
        <ul>
          <li>Everything in Monthly</li>
          <li>Priority support</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <div className="subscription-terms">
        <p>
          Subscription automatically renews unless cancelled at least
          24 hours before the end of the current period. Manage your
          subscription in Settings.
        </p>
        <button onClick={restorePurchases}>Restore Purchases</button>
      </div>

      <div className="legal-links">
        <a href="/privacy/">Privacy Policy</a> |
        <a href="/terms">Terms of Service</a>
      </div>
    </div>
  );
}

Android特有の要件

Google Play Consoleのアカウント設定

最初の Android リリースの前に、Play Console アカウントとアプリのシェルが存在することを確認してください:

  • デベロッパーアカウントの作成はこちら: Play Console サインアップ
  • Play Console で、次に移動します: ホーム &gt; アプリを作成
  • デフォルトの言語、アプリ/ゲームのタイプ、サポート用メールアドレスを選択します
  • 必須の Play ポリシー、輸出、Play App Signing に関する宣言に同意します
  • アプリがどちらに該当するかを選択します: 無料 または 有料

重要: Googleでは有料アプリを後から無料に変更できますが、一度無料にしたアプリを有料に戻すことはできません。

App Bundleの要件

重要: Google PlayではAPKではなく、Android App Bundle (.aab) 形式が必須です:

# Sync the native Android project first
bunx cap sync android

# Then build the release app bundle
cd android
./gradlew bundleRelease

ターゲット API レベルの要件

現在の要件: 新規アプリおよびアップデートは、Android 15 (API レベル 35) 以上をターゲットにする必要があります。

android/app/build.gradle を更新:

android {
    compileSdkVersion 35

    defaultConfig {
        targetSdkVersion 35
        minSdkVersion 23  // Minimum supported version
    }
}

Google Play データ セーフティ

前述の通りですが、Androidの承認を得るために極めて重要です。

クローズドテストトラック(現在の要件)

新規作成の個人開発者アカウントにとって最大の難関は、本ガイドの前半で説明した「12人のテスターが14日間継続してオプトインする」要件です。

タイムライン:

  1. 第1週:テスターの募集、クローズドテストの設定
  2. 第2〜3週:アクティブなテスト期間(最低14日間)
  3. 第4週:問題の修正、本番リリースの準備
  4. 第5週:本番リリースの審査に提出

ターゲット層とコンテンツレーティング

コンテンツレーティングのアンケート:

  • すべてのアプリで必須
  • 回答時間は10〜15分程度
  • 年齢レーティング(全年齢、ティーン、成人向けなど)を決定
  • 回答に影響するコンテンツ変更があれば、その都度更新してください

対象トピック:

  • 暴力表現
  • 性的コンテンツ
  • 不適切な表現
  • 規制薬物
  • ギャンブル
  • ユーザーインタラクション機能

重要:ユーザー生成コンテンツ(UGC)やソーシャル機能がある場合は、その旨を開示し、モデレーションを実装する必要があります。

ストア掲載情報の要件

必須アセット:

  • アプリアイコン (512 x 512 PNG)
  • フィーチャーグラフィック (1024 x 500 JPG または PNG)
  • スマホ用スクリーンショット (最小2枚、最大8枚)
  • 7インチタブレット用スクリーンショット (任意だが推奨)
  • 10インチタブレット用スクリーンショット (任意だが推奨)

説明文の要件:

  • 短い説明 (最大80文字)
  • 詳細な説明 (最大4000文字)
  • アプリの機能を正確に記述すること
  • 連絡先や価格情報は含めないこと

提出前のチェックリスト

提出前に、以下のチェックリストを必ず確認してください。

技術要件

  • 実機でアプリが正常に起動すること
  • スクリーンショット内の全機能が動作すること
  • プレースホルダーや「Coming Soon」がないこと
  • すべてのサードパーティ製 API キーが本番用であること
  • ネットワークエラーのハンドリングが実装されていること
  • 権限リクエストに明確な説明が含まれていること
  • 不安定なネットワーク環境でもクラッシュしないこと
  • 権限を拒否した状態でテスト済みであること
  • サポート対象の最小OSバージョンでテスト済みであること
  • メモリリークのチェックと修正が完了していること

認証 &amp; ログイン

  • ソーシャルログインを使用する場合、Sign in with Appleが含まれていること (iOS)
  • レビューノートにデモアカウントの認証情報を記載
  • デモアカウントですべての機能にアクセス可能
  • パスワードリセットのフローが動作すること
  • ログアウト機能が正しく動作すること
  • アカウント削除オプションを用意 (GDPR/CCPAで必須)
  • プライバシーポリシーが公開されていること
  • ストアの掲載情報にプライバシーポリシーのURLを追加
  • 利用規約が公開されていること (該当する場合)
  • アプリ内 (設定画面) にプライバシーポリシーへのリンクを設置
  • プライバシーラベルの内容が正確であること (iOS)
  • データ セーフティ セクションを完了 (Android)
  • すべてのデータ収集目的を明記
  • サードパーティによる SDK のデータ収集を開示済み

コンテンツ & メタデータ

  • アプリ名がガイドラインに準拠 (キーワードの詰め込みなし)
  • 説明文が機能を正確に記述
  • スクリーンショットが実際の最新アプリ画面を表示
  • すべての対応言語でスクリーンショットをローカライズ
  • 説明文に競合他社の名前を含めない
  • 根拠のない最上級表現を使用しない
  • 年齢制限が実際のコンテンツと一致
  • 連絡先メールを監視

iOS特有

  • Sign in with Appleの実装(ソーシャルログイン利用時)
  • 必要なすべてのスクリーンショットサイズが揃っている
  • iPad対応時は実際のiPadスクリーンショットをアップロード済み
  • Info.plistの権限説明が明確である
  • 実際の連絡先情報を含むサポートURLが追加されている
  • App Store ConnectにプライバシーポリシーURLが追加されている
  • 年齢レーティングのアンケートが完了している
  • 輸出コンプライアンスに正しく回答済み
  • App Reviewの連絡先と、期限のないデモアカウントを提供済み
  • ターゲットiOSが15.0以上
  • IAP利用時:価格が明確で、購入の復元ボタンがある
  • Androidや他プラットフォームへの言及がないこと

Android固有

  • App Bundle (.aab) 形式を使用していること
  • ターゲット API 35 以上であること
  • コンテンツのレーティング回答が完了していること
  • フィーチャーグラフィックがアップロード済みであること
  • Play Consoleのアカウント要件に応じてクローズドテストを完了していること(12名以上のテスターが14日間連続で参加し、申請時も12名以上が継続していること)
  • テスト中のクラッシュレポートを確認し、修正済みであること
  • iOSや他プラットフォームへの言及がないこと

テスト(Androidの現在の要件)

  • Playストアのクローズドテスト要件を満たす12名以上のテスターを確保
  • クローズドテスト用トラックの作成
  • 14日間連続で12名以上のテスターが継続して参加し、申請時も12名以上が参加していること
  • テスターがアプリを実際に使用していること(インストールのみは不可)
  • テスト期間中のクラッシュモニタリングの有効化
  • テストで見つかった致命的なバグの修正
  • テスターからのフィードバックの記録

レビュー時のメモ:記載すべき内容

レビュー時のメモの内容次第で、即時承認か却下かが決まります。含めるべき内容は以下の通りです:

レビュー用メモのテンプレート

APP REVIEW INFORMATION

=== Test Account ===
Email: reviewer@testapp.com
Password: TestReview123!
(This account has all premium features enabled)
(This account stays active during review)

=== Review Contact ===
Name: Jane Developer
Email: review@yourapp.com
Phone: +1 555-0100

=== Testing Instructions ===
1. Launch app and tap "Sign In"
2. Enter test credentials above
3. Navigate to "Dashboard" to see main features
4. Tap "Upgrade" to test subscription flow (sandbox mode)
5. Go to Settings > Account to see privacy policy and terms

=== Key Features to Test ===
- Workout tracking (tap "New Workout" on Dashboard)
- Progress charts (Analytics tab)
- Social sharing (Share button on workout details)
- Camera upload for profile picture (Settings > Profile)

=== Third-Party Services ===
- Firebase Authentication (for login)
- Stripe (for payments - sandbox mode)
- AWS S3 (for image uploads)
- Google Maps SDK (for location features)

=== Notes ===
- Location permission is optional, app works without it
- Camera permission only requested when uploading profile picture
- All subscription flows use Apple/Google sandbox environments
- Background location is not used
- Support URL and privacy policy are available from Settings > Account

=== Contact ===
For questions: developer@yourapp.com
Response time: Within 24 hours

iOS向けのレビュー用メモ

iOSの場合は、以下も追加してください:

=== Device Coverage ===
Tested on: iPhone 15 Pro Max, iPad Pro 13-inch

=== App Store Connect Metadata ===
Support URL: https://yourapp.com/support
Privacy Policy: https://yourapp.com/privacy-policy

=== Submission Notes ===
- iPad screenshots match the current iPad UI
- Export compliance answered for this build
- Sign in with Apple is available on the login screen

Android向けのレビュー用メモ

Androidの場合は、以下も追加してください:

=== Testing Track Information ===
Closed testing period: [Start Date] to [End Date]
Number of active testers: 23
Critical issues found during testing: 2 (both fixed)
Test distribution method: Email invite list

=== Crash Data ===
Testing period crashes: 3 total
Crash rate: 0.8%
All crashes fixed in this build

=== API Levels ===
Target SDK: 35 (Android 15)
Min SDK: 23 (Android 6.0)
Tested on: Android 11, 12, 13, 14, 15

リジェクトされた場合の対処法

慌てないでください。特に初回申請ではリジェクトはよくあることです。対応方法は次のとおりです:

リジェクト後のステップ

  1. リジェクト内容をよく読む

    • 違反した具体的なガイドラインを確認(例:4.3、5.1.1)
    • レビュアーのコメントを隅々まで読む
    • スクリーンショットがあれば確認する
  2. 問題を把握する

    • 公式ドキュメントでガイドラインを調べる
    • オンラインで類似事例を検索する
    • 誤解か正当な指摘かを見極める
  3. 根本原因を修正する

    • その場しのぎではなく、根本から修正する
    • 修正内容を徹底的にテストする
    • 変更箇所をドキュメント化する
  4. 適切に対応する

    リジェクトが妥当な場合:

    Thank you for the feedback. I have addressed the issue:
    
    Issue: Missing Sign in with Apple option
    
    Resolution: Added Sign in with Apple as a login option
    alongside Google Sign-In. The button appears on the login
    screen and follows Apple's design guidelines. You can test
    with the provided demo account or by creating a new account
    with Apple Sign-In.
    
    Changes made in: v1.0.1 (build 2)

    誤解であると思われる場合:

    Thank you for reviewing my app. I believe there may be a
    misunderstanding regarding [specific issue]:
    
    [Explain clearly with screenshots if needed]
    
    The functionality exists at: Settings > [specific location]
    
    I've added additional detail to the review notes to help
    locate this feature.
  5. 迅速に再提出する

    • 再提出は通常、審査が早まります(24〜48時間)
    • 修正内容を説明するレビューノートを添える
    • 必要に応じて前回の提出内容を参照する

よくあるリジェクト理由への対応

リジェクト理由:「起動時にアプリがクラッシュします」

回答例:

I sincerely apologize for the crash. I have identified and fixed
the issue:

Root cause: The app attempted to fetch data before network
initialization completed, causing a null reference exception.

Fix: Implemented proper async initialization with error handling
and offline mode. The app now gracefully handles network issues.

Testing: Verified on iPhone 12 (iOS 17), iPhone 14 Pro (iOS 17.1),
tested with WiFi, cellular, and airplane mode.

Build version: 1.0.2 (build 3)

リジェクト理由: 「プライバシーポリシーの不足」

回答例:

Thank you for the feedback. I have added the privacy policy:

URL: https://myapp.com/privacy-policy
Location in app: Settings > Privacy Policy (tappable link)
Also added to: App Store Connect > App Information > Privacy Policy URL

The privacy policy covers all data collection as disclosed in the
Privacy Nutrition Labels.

リジェクト理由: 「4.2 - Minimum Functionality に準拠していません」

これはより厄介です。アプリとして成立するだけの機能が足りない、という意味です。詳しくは 2026年にApp Storeの審査を通過する方法 4.2と4.3の完全な対応プレイブックはこちら。アピール文の例:

回答例:

Thank you for the feedback. I'd like to clarify the app's
functionality:

Core Features:
1. [Feature 1 with specific details]
2. [Feature 2 with specific details]
3. [Feature 3 with specific details]

The app provides significant utility beyond a simple website by:
- Offline functionality for [specific feature]
- Native camera integration for [specific feature]
- Push notifications for [specific feature]
- Device hardware access for [specific feature]

Test account credentials have been provided to demonstrate all
features. Please let me know if you need additional clarification.

承認後のベストプラクティス

おめでとうございます!アプリが承認されました。承認状態を維持するためのポイントは以下の通りです:

リリース後のモニタリング

注視すべき重要なメトリクス:

  • クラッシュ率 (1%未満を維持)
  • ANR率 (Android - 0.5%未満を維持)
  • App Store/Play Store の評価
  • レビュー内容(すべてのレビューに返信)
  • ユーザーからのバグ報告

活用すべきツール:

  • Firebase Crashlytics
  • App Store Connect Analytics
  • Google Play Console Vitals
  • Sentry または同様のエラー追跡ツール

アップデートのガイドライン

アップデートを提出する際は:

  • 初回提出時と同様に徹底的にテストする
  • UIが大幅に変更された場合はスクリーンショットを更新する
  • データ収集内容が変更された場合はプライバシーラベルを更新する
  • 「新機能」の説明を明確に記載する
  • 大幅な変更には段階的なリリースを検討する

コンプライアンスの維持

毎年の必須要件:

  • Androidのコンテンツレーティングを更新(毎年必須)
  • 運用が変わった場合はプライバシーポリシーを更新
  • コンテンツ変更時は年齢レーティングを見直して更新する
  • サードパーティSDKのコンプライアンスを監査する

継続的なモニタリング:

  • ガイドラインの変更を常に把握する
  • Apple/Googleのデベロッパーニュースレターに登録する
  • デベロッパーコミュニティに参加する
  • App Store/Play Storeのポリシーブログをチェックする

リソースと参考資料

公式ドキュメント

Apple:

Google:

コミュニティリソース

プライバシーポリシーツール

よくある質問

アプリの審査ガイドラインとは?
Appleのものです App Storeの審査ガイドライン およびGoogleの デベロッパープログラムポリシーがレビュアーはリリース前に、バイナリ、メタデータ、プライバシー開示、アカウント設定を確認します。

2026年のアプリ審査にはどのくらい時間がかかりますか?
Appleは、申請の50%を24時間以内、90%を48時間以内に審査することを目標としています。Googleは、アカウントによっては7日以上かかる場合があります。新しい個人のPlay Consoleアカウントでは、このルールが適用される場合、クローズドテストで少なくとも12人のテスターが14日間連続でオプトインし続け、申請時にも少なくとも12人がオプトインしている必要があります。

Appleのガイドラインの5つのセクションとは?
安全性、パフォーマンス、ビジネス、デザイン、法的です。パフォーマンスは完成度とメタデータ(2.3を含む)、法的はプライバシー(5.1を含む)を対象とします。

初回申請の前に何を修正すべきですか?
動作するデモ用ログイン、HTTPSのプライバシーポリシーとサポートリンク、実態に即したプライバシーラベル、実機テスト、ビルドと一致するストア用アセット。次を完了してください: 年齢制限のアンケート アプリに該当する場合は、両方のストアで。

ガイドライン4.2と4.3はどこに該当しますか?
これらは、アプリの機能不足や重複を理由としたApple Designの却下事例です。 2026年にApp Storeの審査を通過する方法 その範囲向けで、このチェックリストではありません。

Appleでの公開にはいくらかかりますか?
詳細は App Storeへのアプリ公開コスト 現在の登録料と掲載料については

アプリの審査でお困りですか?

審査が不安な方や、一発で通過できるよう専門家のアドバイスが欲しい方は、ぜひご相談ください!

チームとの相談を予約する 以下の内容について個別サポートを受けられます:

  • App StoreおよびPlay Storeの審査準備
  • プライバシーポリシーと法的ドキュメントの確認
  • Sign in with Appleの実装
  • テスト戦略とテスターの募集
  • 審査用ノートの準備
  • リジェクト対応と異議申し立て
  • アプリ申請プロセスを完了する

当社のチームは、これまで何百人もの開発者がアプリ審査を通過できるよう支援してきました。試行錯誤による数週間のロスを防ぐことができます。

まとめ

初めてのアプリ申請は不安なものですが、適切に準備すれば一度の審査で通過できます。以下の重要ポイントを覚えておきましょう:

  1. 早めに始める: 特にAndroidの場合、リリース予定日の少なくとも3週間前には12人のテスターを確保してください
  2. プライバシー優先: プライバシーポリシーを用意し、実際のデータ取り扱い内容を正確に反映させてください
  3. Appleでサインイン: ソーシャルログインを使用する場合は、iOSでSign in with Appleを含める必要があります
  4. 徹底的にテストする: 実機、不安定なネットワーク環境、権限を拒否した状態でテストしてください
  5. 正直に: 正確なメタデータとプライバシー開示は、リジェクトや法的トラブルを防ぎます
  6. 詳細なレビューノート: レビュアーがアプリをすぐに理解できるようにします

現在のAndroidのテスト要件によりプロセスには時間がかかりますが、最終的にはアプリの品質が上がり、リリース後のトラブルも減ります。Androidの申請には追加で3〜4週間を見込んでおけば、成功につながります。

アプリのリリース、頑張ってください!たとえリジェクトされても、それは学びの機会です。成功しているアプリの多くも、承認までに何度もレビューを経ています。

一人で進めるのは不安ですか? コンサルティングを予約して 専門家にプロセスを案内してもらいましょう。


アプリ承認後のライブアップデート実装でお困りですか?こちらをチェック: Capgoのlive updateソリューション なら、ストア審査なしでシームレスにアプリを更新できます。

App Review Guidelines 2026 から続ける

セキュリティやコンプライアンスの計画に アプリ審査ガイドラインの チェックリストを使用する場合は、以下と連携させてください 暗号化 暗号化の実装詳細について コンプライアンス コンプライアンスの実装詳細について Capgo セキュリティスキャナー Capgo Security Scanner のプロダクトワークフローについて Capgo のセキュリティ Capgo Security のプロダクトワークフロー向け、および Capgo トラストセンター Capgo Trust Center のプロダクトワークフロー向け。

Capacitor アプリ向けの Live Updates

Web レイヤーのバグが本番で発生したら、App Store の審査を何日も待たずに Capgo で修正を配信しましょう。ネイティブの変更は通常の審査フローに残したまま、ユーザーはバックグラウンドでアップデートを受け取れます。

最新のブログ記事

Capgoは、真にプロフェッショナルなモバイルアプリを作るために必要な最高のインサイトを提供します。