App Storeリジェクトの対処法：ガイドライン別の直し方（2026年版）

App Storeのリジェクトとは、App Reviewから届くメッセージで、ガイドラインを引用し、審査担当者が確認した内容を伝え、修正・説明・異議申し立てのいずれかを行うまでリリースを保留するものです。まずは、そのメッセージを検証可能な課題に落とし込みましょう。次の手順は、審査担当者がアプリを使えなかったのか、ポリシーとの不一致を見つけたのか、追加情報を必要としているのかによって変わります。2026年10月時点で、App Reviewガイドラインの最終更新は2026年10月16日です。条項を引用する前に、最新の番号を確認してください。

App Storeのリジェクトメッセージから実際に何がわかるのか？

App Storeのリジェクトメッセージには、審査担当者が適用したガイドライン、確認した具体的な挙動、次に取るべき手順が記載されています。デバイス、iOSのバージョン、スクリーンショットが含まれていることもよくあります。

メッセージ全文、スクリーンショット、ビルド番号、デバイスの情報を保存しておきましょう。引用された条項を最新のガイドラインページで読みます。そのうえで「審査担当者はYが原因でXを完了できなかった」という一文を書きます。メッセージが不具合の報告ではなく不足している情報を求めている場合は、何が不足しているのかを正確に書き出します。Appleの2.1の定型文には再現方法も書かれています：「新規アプリの場合は、デバイスからアプリの以前のバージョンをすべてアンインストールしてからインストールし、手順に従って問題を再現してください。」

• メッセージがクラッシュ、アクセスできない画面、未完成の機能を指摘している場合は、提出したリリースビルドで、Appleが指定したデバイスの種類を使ってそのフローを再現します。
• スクリーンショット、説明文、審査メモを指摘している場合は、メタデータの修正だけで解決できるか確認します。
• 支払い、ログイン、プライバシー、最低限の機能を指摘している場合は、プロダクトの挙動を引用されたガイドラインと照らし合わせます。

App Storeのリジェクトで引用されるガイドラインと、その要件は？

各ガイドラインは具体的な要件を定めているので、引用された番号をその文言と照らし合わせ、その文言に沿ってテストします。下の表は、リジェクトメッセージでよく引用されるガイドラインの現行の文言を示しています。

2026年10月16日の更新では、以前は2.3.1で扱われていた隠し機能、休眠機能、文書化されていない機能について 2.5.19 が新設されました。また、クリエイティブアセットに関する 2.3.14 が追加され、Music Streaming Servicesエンタイトルメントは3.1.1(a)のStoreKit External Purchase Linkエンタイトルメントに統合されました。この表は出発点として使い、確実な解決策とは考えないでください。1つのガイドラインがさまざまな問題をカバーしており、審査担当者が示した例こそが解決すべき具体的なケースです。

4.2 Minimum Functionalityのリジェクトはどう直す？

4.2のリジェクトは、説明文を書き換えるのではなく、アプリとしての実質的な価値を加えることで解決します。ガイドライン4.2には「アプリが特に有用でも、独自でも、『アプリらしく』もない場合、App Storeにふさわしくありません」と書かれています。

ユーザーがあなたのアプリで何ができれば、アプリとして役に立つと言えるのかを考えましょう。ワークフローを完了できる、意味のある状態を保存できる、アプリに合った形でデバイスの機能を使える、デバイス向けに作られたモバイル体験を得られる、などです。承認を保証する公開された機能リストはありません。そうしたワークフローがすでにあるなら、正確な手順とスクリーンショットを添えて審査メモに記載します。アプリがほぼWebページを表示しているだけなら、プロダクト側の作業が必要です。ネイティブらしく見せるためだけに通知や空の設定画面を追加しても、ユーザーにとっての実質的な価値の代わりにはなりません。

App Store ConnectでApp Reviewに返信するには？

App Store Connectで返信します。アプリの未解決の問題のリンクから提出物を開き、「解決」をクリックしてから「App Reviewに返信」をクリックします。Appleのヘルプページによると、これにはアカウント保有者、管理、またはApp Managerの役割が必要です。

1. アプリで対象のアプリを選択します。
2. ページ上部にある、未解決の問題があることを示すリンクをクリックします。
3. 進行中のセクションで、提出物の横にある解決をクリックします。
4. App Reviewに返信をクリックし、本文を入力します。
5. スクリーンショットや書類を添付するにはファイルを添付をクリックし、返信をクリックします。

Appleによると、やり取りやファイルの添付は「App Reviewに再提出するまで」可能なので、再提出の前に証拠を送りましょう。返信は短く事実に即したものにし、何を変更したか、それがどこにあるか、どう確認できるかを伝えます。同じことをしているように見える他のアプリを引き合いに出して反論するのはやめましょう。

メタデータを直すか、新しいビルドを上げるか、異議申し立てか？

誤っていたのが掲載情報だけなら、メタデータを修正して同じビルドを再提出します。アプリの動作を変える必要がある場合は、新しいビルドをアップロードします。アプリがすでにガイドラインに準拠していると考える場合に限り、異議申し立てを行います。

Appleの異議申し立てに関するガイダンスでは、アプリがガイドラインを「どのように満たしているかを項目ごとに説明」するよう求めています。また、すでに問題を修正して再提出した後には異議申し立てをしないよう記載されています。完全な異議申し立てであっても、判断が覆ることは「保証されません」。すでにストアに公開されているアプリについては、ガイドラインのBug Fix Submissionsポリシーにより、「法的または安全上の問題に関わるものを除き」、ガイドライン違反を理由にバグ修正が遅らされることはありません。

他の開発者は実際のApp Storeリジェクトをどう解決したのか？

公開フォーラムのスレッドでは、2.1のリジェクトの多くが、審査担当者の環境と開発者の環境の違い、つまりネットワーク、デバイス、権限の状態の違いから生じていました。4.2のリジェクトはプロダクトの問題なので、小さな調整で解消されることはほとんどありません。

2.1でのログインエラー。 Apple Developer Forumsのある開発者は、「具体的には、エラーのためログインできませんでした」というメッセージを引用していました。公開版とTestFlight版では同じ認証情報でログインできていたにもかかわらずです。スレッド内の他の開発者は、それぞれ異なる解決策を報告しています。ある人は「Webサーバーのhttpをhttpsに変更する」ことで解決しました。別の人は3回のリジェクトの後、終わらないローディング表示の代わりに「接続を確認してください」という状態を追加しました。3人目は5回のリジェクトの後、デプロイメントターゲットからiPadを外しましたが、これはiPad対応をやめることで問題を回避したにすぎません。

起動時のクラッシュ。 Solar2Dフォーラムでは、iOS 18.3.2を搭載したiPhone 13 miniで「起動時にクラッシュしたため、アプリを審査できませんでした」と伝えられた開発者がいました。添付されたクラッシュログには、NSUserTrackingUsageDescription キーの欠落が示されていました。開発者は「NSUserTrackingUsageDescriptionを追加したら通りました」と報告しています。

4.2でのWebViewアプリ。 Apple Developer Forumsのある開発者は、WebViewベースのアプリで10回目のリジェクトを受けたと報告しました。審査担当者は左メニューのスクリーンショットを送り、コンテンツが不足していると指摘していました。主要な画面はネイティブになっていましたが、2〜3画面はまだWebViewを開いていました。回答としてマークされた返信はApp Reviewからのもので、App Reviewとの1対1の相談を勧めていました。スレッドでは承認されたかどうかは確認されていません。

比較すると、2.1のケースは審査担当者の条件を再現し、クラッシュログを読むことで解決しました。4.2のケースは、依然として大部分がWebサイトであるアプリの一部しか再提出のたびに変更しなかったため、行き詰まりました。

同じリジェクトを繰り返さないためには？

解決した課題をそれぞれリリースチェックリストの項目にし、提出のたびにリリースビルドで再テストします。Appleのガイドラインは、同じガイドライン違反で繰り返しリジェクトされると審査に「時間がかかる」と警告しています。

• アプリを削除してから、実機のiPhoneとiPadにリリースビルドを新規インストールします。
• 開発用サーバーやHTTPの例外がないネットワークで、審査用アカウントでログインします。
• すべての権限ダイアログを表示し、Info.plistの各使用目的の説明が存在することを確認します。
• すべてのApp内課金が提出済みで、表示され、審査メモで説明されていることを確認します。
• フローを変更したら必ず審査メモを更新します。6リリース前のメモをそのまま貼り付けないでください。

2.1の問題については、2.1リジェクト向けリリースビルドのテスト計画に従い、審査担当者用のデモアカウントを用意しましょう。そのうえで、次のビルドに向けて提出チェックリストを確認します。審査メッセージを読んでもまだ行き詰まっている場合は、詳細をお送りください。足りないのがアクセス、メタデータ、コードのどれなのかを一緒に見極めます。