App Storeのガイドライン2.1（App Completeness）リジェクト：再提出前にやるリリースビルドのテスト計画（2026年）

App Storeのガイドライン2.1（App Completeness）によるリジェクトは、審査担当者がユーザーと同じようにアプリを使えなかったことを意味します。クラッシュした、プレースホルダーのコンテンツが表示された、ログイン画面で先に進めなかった、あるいはアプリ内課金が見つからなかった、といった原因が考えられます。修正がコード1行で済むことはまずありません。再提出の前に、新規インストールの状態で、App Reviewに渡すのと同じ認証情報を使い、リリースビルドで短いテスト計画を実行しましょう。この記事ではそのテスト計画を順に解説し、他の開発者が同じリジェクトをどう解決したかも紹介します。

App Storeのガイドライン2.1（App Completeness）では何がチェックされるのか？

ガイドライン2.1では、提出したビルドが完成済みで正しく動作するアプリかどうかがチェックされます。完全なメタデータ、機能するリンク、デモ用ログイン、稼働中のバックエンド、そして審査担当者が見つけて使えるアプリ内課金が必要です。

AppleのApp Reviewガイドラインでは、2.1は2つに分かれています。2.1(a)では、提出物は「必要なメタデータをすべて含み、URLが完全に機能する最終版であるべき」とされ、プレースホルダーのテキストや中身のないWebサイトは削除するよう求めています。また、バグや安定性について実機でテストすること、そして「アプリにログイン機能がある場合はデモアカウントの情報を含める（そしてバックエンドサービスをオンにしておく！）」ことも求めています。Appleは「不完全なアプリバンドルや、クラッシュする、または明らかな技術的問題があるバイナリはリジェクトする」としています。2.1(b)では、アプリ内課金は「完全で最新の状態であり、審査担当者から見えて、機能する」ものでなければならないとしています。設定済みの課金アイテムがアプリ内で見つからない場合は、その理由を審査メモで説明してください。

このリジェクトはよくあるものです。AppleのApp Reviewの準備（Preparing for App Review）ページには、「平均して、未解決の問題の40%以上がガイドライン2.1：App Completenessに関連しており、これにはクラッシュ、プレースホルダーのコンテンツ、不完全な情報などが含まれます」と書かれています。

なぜデバッグビルドのテストでは2.1の問題を見つけられないのか？

デバッグビルドは、審査担当者の手元にあるアプリと同じようには動きません。審査担当者は、配布用に署名されたリリースビルドを、保存されたセッションもデバッグ用の近道もないクリーンな端末にインストールします。

あなたのシミュレータはすでにサインイン済みです。ローカルのAPIは、絶対に落ちないステージングサーバーを向いているかもしれません。デバッグフラグでペイウォールがスキップされ、機能フラグはデフォルトでオンになっています。審査担当者の環境にはどれもありません。さらにAppleの審査ページは「最新のソフトウェアを搭載した端末で徹底的にテストする」よう求めているため、審査担当者はあなたのテスト端末より新しいiOSを使っている可能性があります。

審査担当者の環境に最も近づけるのがTestFlightです。TestFlightの概要によると、App Store Connectのチームから最大100人の内部テスターを、さらに最大10,000人の外部テスターを追加できます。1つのビルドは最長90日間テストできます。提出予定のビルドそのものをアップロードし、そのアプリを一度も実行したことのない端末にTestFlightからインストールして、そのコピーをテストしましょう。

再提出前のリリースビルドのテスト計画では何を確認すべきか？

リリースビルドのテスト計画では、初めて触る審査担当者が行き詰まりうるポイントをすべて確認します。起動、権限、ログイン、バックエンド、コンテンツ、リンク、課金、ネットワーク障害、そしてiPadです。TestFlightビルドで以下の手順を順番に実行し、各結果を記録しておけば、審査メモでそのまま引用できます。

1. 最新iOSでのクリーンインストール。 以前のコピーをすべて削除し、TestFlightからインストールして、何も保存されていない状態で起動します。コールドスタートを3回行い、オンボーディングでクラッシュしないことを確認します。
2. すべての権限リクエストを一度は拒否する。 通知、位置情報、カメラ、トラッキングを拒否します。それでもアプリは使える画面までたどり着けるべきです。また、アプリやそのSDKが使う保護されたリソースすべてについて、Info.plistに使用目的の説明があることも確認します。
3. デモ用の認証情報そのものでサインインする。 パスワードマネージャーからではなく、App Store Connectからコピーしてください。アカウントには現実的なデータが入っていて、メール確認が不要で、あなた自身のスマートフォンに紐づいた2ファクタ認証を使っていないことが条件です。
4. バックエンドが本番環境で稼働していることを確認する。 ビルドは本番のエンドポイントを向いている必要があります。レート制限、IP許可リスト、地域ブロックで審査担当者が締め出されないようにします。ガイドライン2.1(a)は、バックエンドサービスをオンにしておくよう求めています。
5. すべてのタブと画面を確認する。 lorem ipsum、「近日公開」の画面、説明のない空の状態、テスト用の画像、押しても何も起きないボタンがないか探します。
6. すべてのリンクをタップする。 プライバシーポリシー、サポート、利用規約、あらゆるWebビューが対象です。Appleは「最新の連絡先情報を記載したユーザーサポートへのリンクと、プライバシーポリシーへのリンクは、すべてのアプリで必須」としています。
7. すべてのアプリ内課金を開く。 新規アカウントでサインインします。そのバージョンと一緒に提出した各プロダクトが価格付きで表示されること、サンドボックスで購入できること、「購入を復元」が機能することを確認します。
8. 低速または切断されたネットワークでテストする。 操作の途中で機内モードをオンにします。わかりやすいエラーメッセージなら問題ありません。止まらないスピナーやクラッシュはNGです。
9. 対応している場合はiPadも確認する。 アプリがiPadで動作するなら、iPadで起動し、レイアウトのせいでユーザーが操作不能にならないことを確認します。

手順3のデモアカウントは、他のどの手順よりも繰り返しのリジェクトを招きます。長く使えるデモアカウントの作り方は、App Store審査用デモアカウントの設定ガイドで解説しています。

2.1のリジェクトメッセージから修正方法をどう導くか？

2.1のリジェクトから修正方法を導くには、ガイドライン番号の次の文を読みます。そこに症状が書かれており、症状ごとにテスト計画の該当する手順が決まります。

たとえば、習慣トラッカーアプリが「起動時にクラッシュしたため、アプリを審査できませんでした」というメッセージでリジェクトされたとします。2つ目のメモには、審査担当者がアプリ内課金を見つけられなかったと書かれています。下の表は、よくある症状を原因、テスト、修正方法に対応させたものです。

あらゆるリジェクトメッセージを読み解くための幅広い方法は、App Storeリジェクトの直し方：ガイドライン別解説をご覧ください。

他の開発者の2.1リジェクトはどのようなものだったか？

公開されている2.1の事例には共通のパターンがあります。開発者の環境では動作するのに、新規インストールや他人のログインでしか表面化しない何かが原因で、審査担当者の環境では失敗するのです。

• 使用目的の説明の欠落によるクラッシュ。 Solar2Dフォーラムでは、ある開発者が、TestFlightでは動作していたにもかかわらず、iOS 18.3.2を搭載したiPhone 13 miniで「起動時にクラッシュしたため、アプリを審査できませんでした」と通知されました。別のメンバーが、添付のクラッシュログに「このアプリは、使用目的の説明なしにプライバシーに関わるデータにアクセスしようとしたためクラッシュしました」という記述を見つけました。開発者は「NSUserTrackingUsageDescriptionを追加したら通った」と報告しています。
• 審査担当者が使えなかったソーシャルログイン。 Apple Developer Forumsでは、ある開発者が、審査担当者が「ソーシャルログインを使用できなかった」という理由で2.1のリジェクトを繰り返し受けたと報告しました。AppleとGoogleのデモアカウントを提供していましたが、Apple IDのサインインには開発者のスマートフォンに送られる確認コードが必要でした。Appleのスタッフは、App Reviewから直接連絡すると回答しました。解決方法は公開されていません。
• アプリ内課金が「提出されたバイナリ内で見つからなかった」。 RevenueCatのコミュニティスレッドでは、サンドボックスでの購入は機能していたのに、月額プランがバイナリ内で見つからないとしてリジェクトされた開発者がいました。回答者の一人は、ペイウォールへのすべての経路を詳しく説明し、スクリーンショットを添えて返信したところ、同様のリジェクトが解決したと述べています。RevenueCatのスタッフは、提出したすべてのプロダクトをデフォルトのペイウォールに表示し、StoreKitのテストファイルをArchiveスキームに含めないよう助言しました。

3つの事例すべてで、開発者自身のテストは通っていました。失敗が表面化したのは、2FA用のスマートフォンも過去のセッションもなく、ペイウォールの場所も知らない、審査担当者の出発点からだけでした。上のテスト計画は、まさにその出発点を再現するものです。

2.1のリジェクト後、App Reviewの審査メモには何を書くべきか？

2.1のリジェクト後の審査メモには、動作するデモ用の認証情報、リジェクトされたビルドからの変更点、そしてアプリ内課金やわかりにくい機能の具体的な場所を書きます。

Appleの審査ページは、アカウントの詳細や特別な設定はApp Reviewに関する情報（App Review Information）セクションに記載するよう求めています。準備が難しいハードウェアや環境が必要な機能については、「デモ動画またはハードウェアを提供できるよう準備しておく」ことも求めています。ガイドライン2.3.1(a)はさらに、新機能は審査メモで「具体的に」説明しなければならず、「一般的な説明はリジェクトされる」としています。短く構造化されたメモが効果的です。

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

法的またはセキュリティ上の義務によりデモアカウントを用意できない場合、ガイドライン2.1(a)はアプリ内蔵のデモモードを認めていますが、それはAppleの事前承認がある場合に限られ、そのモードではアプリのすべての機能を示す必要があります。承認なしにデモモードへ切り替えないでください。

2.1のリジェクト後、どう再提出または不服申し立てをするか？

2.1のリジェクト後に再提出するには、テストしたビルドをアップロードまたは選択し、App Store ConnectでApp Reviewに変更点を返信し、審査メモを更新してから再度提出します。不服申し立ては、審査担当者がアプリを誤解したと考える場合にだけ行いましょう。

1. App Store Connectでバージョンに紐づいているビルド番号が、テストしたTestFlightビルドと一致していることを確認します。
2. リジェクトのメッセージに、各修正の短い要約を添えて返信します。課金やナビゲーションの問題であれば、手順とスクリーンショットも添えます。
3. App Reviewに関する情報（App Review Information）セクションを、最新の認証情報とメモで更新します。
4. 審査に提出します。2026年10月時点で、Appleは通常「提出の少なくとも50%を24時間以内に、90%を48時間以内に」審査するとしています。

Appleの判断が誤っていると考える場合は、App ReviewページからApp Review Boardに不服申し立てができます。アプリが準拠している具体的な理由を示してください。また「審査に通らなかった提出1件につき、不服申し立ては1回だけ」とされています。ただし2.1のリジェクトでは、反論するよりクリーンな端末で問題を再現するほうがたいてい早く片づきます。再提出を任せたい場合、The App GuyのApp Store提出サービスは、両ストアの審査準備とリジェクトへの対応を$599で提供しています（デベロッパーアカウントの費用は別途）。

2.1の問題は、新しい機能フラグ、ローテーションしたAPIキー、期限切れのデモアカウントなど、後のアップデートで再発しがちです。このテスト計画を、App Store提出チェックリストと合わせてリリースの定型作業に組み込みましょう。アップデートでは、段階的リリースを使えば、見落としたバグが届くユーザー数を抑えられます。リジェクトされたビルドについてセカンドオピニオンが欲しい場合は、リジェクトのメッセージを添えてyagyeshsrbobde@gmail.comまでメールしてください。