LASSIC Media らしくメディア
App Store審査リジェクトの理由と対応・外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- App Store審査リジェクトの原因はApple「App Store Review Guidelines」に照らし合わせて判断されるため、ガイドラインの事前確認が対応の出発点になります
- 頻出するリジェクト理由は「機能不完全・バグ」「UI設計（Guideline 4.0）」「プライバシー・パーミッション」など複数あり、理由別に対応アプローチが異なります
- 外注で対応する場合は、Resolution Centerでの補足説明から修正・再申請まで一貫して委託できるパートナーを選ぶことが手戻りを減らすポイントです
目次
App Store審査リジェクトとは — Guidelinesが判断基準
App Store審査リジェクト（App Store Review rejection）とは、iOSアプリをApp Storeに公開・更新する際にAppleが実施するレビューで、合否基準に満たないと判断されたアプリが申請を却下される状態を指します*1。Appleのレビュアーは「App Store Review Guidelines」を根拠に合否を判断するため、このガイドラインがリジェクト対応の出発点です。
リジェクトを受けた場合、Appleは App Store Connect の「Resolution Center」（解決センター）を通じてリジェクト理由を通知します。そこに引用されるGuideline番号（例：4.0、1.2）が修正の手がかりになります。
リジェクトはリリース遅延に直結するため、リリーススケジュールを管理する担当者にとっては大きなリスクです。事前対策と発生後の迅速な対応の両方が求められます。
頻出リジェクト理由7パターンの整理
App Store Review Guidelinesに照らして判断される理由のうち、実務上で頻出するものを7つ整理します。複数の理由が同時に通知されることもあるため、一つひとつ順に確認していくことが大切です。
- ① 機能不完全・バグ・クラッシュ・リンク切れ：アプリが起動時にクラッシュする、または機能が正常に動作しない場合
- ② Guideline 4.0（デザイン/UI）：UIの品質が基準を満たさない。Sign in with Appleボタンが他ログイン手段より目立たない配置になっているケースが典型例
- ③ Guideline 1.2（ユーザー生成コンテンツ）：UGC（ユーザーが投稿するコンテンツ）を扱うアプリで、不適切な投稿を24時間以内に対処する仕組みがない場合
- ④ プライバシー・パーミッション：カメラ・マイク・写真へのアクセス要求に利用目的の説明（purpose string）が不足している場合
- ⑤ メタデータ・説明・URLの不備：アプリ説明文の内容と実際の機能が一致しない、またはサポートURLが機能していない場合
- ⑥ Guideline 3.2.1（金融サービス）：投資・保険・金融関連のアプリで規制上の要件や免責事項が不十分な場合
- ⑦ Guideline 4.2（最小限の機能/既存アプリの模倣）：機能が少なすぎてウェブサイトと変わらない、または既存アプリと酷似しているとみなされる場合
これらの理由はAppleが公開する「App Store Review Guidelines」の各セクションに対応しています*1。リジェクト通知に記載されたGuideline番号を確認し、該当箇所を精読することが対応の基本です。
理由別の対応：機能不完全・バグ・クラッシュ
機能不完全やクラッシュは、Appleのレビュアーが実際にアプリを操作した際に発見されます。対応には「テスト環境の整備」と「動作確認の範囲拡大」の2つが柱になります。
複数環境でのテスト実施が前提
AppleのレビュアーはさまざまなデバイスとiOSバージョンでアプリを操作します。開発時に使っていた端末では再現しないクラッシュが、別の端末やOSバージョンで発生するケースがあります。申請前にiPhone・iPadの複数世代、かつ最新版と一世代前のiOSでそれぞれ動作確認を行うことが大切です。
特に注意が必要なのは「サンドボックス環境でのテストデモ」です。レビュアーがサンドボックス課金を試みた際にクラッシュしたり、ログインが必要な機能でデモアカウントが設定されていない場合、即リジェクトの対象になります。App Store Connectにはレビュアー向けのデモアカウント情報を登録できるため、事前に記入しておきます。
クラッシュログの確認と修正
リジェクト理由に「クラッシュ」が含まれる場合、Xcode OrganaizerのCrash Reportsや Firebase Crashlytics（クラッシュ分析ツール）でスタックトレースを取得し、原因箇所を特定します。ネットワーク接続が不安定な環境や、特定の入力値で再現するクラッシュは、開発環境では見過ごされやすいため、低速ネットワーク・オフライン状態でのテストも含めることが必要です。
理由別の対応：UI・Sign in with Apple・ユーザー生成コンテンツ・プライバシー
Guideline 4.0（デザイン/UI）と1.2（UGC）、プライバシー関連のリジェクトは、コードの修正だけでなく設計・ポリシーの見直しを伴うことがあります。
Guideline 4.0 — Sign in with Appleの配置ルール
アプリがサードパーティのログイン（Google・Facebookなど）を提供する場合、Sign in with Appleも同等以上に目立つ位置と同等以上のサイズで表示することがGuideline 4.0で求められます*1。他のボタンより小さく、下部に追いやられている配置は指摘対象になります。
対応としては、ログインボタンの並び順とサイズを統一し、Apple公式のHuman Interface Guidelinesが示すSign in with Appleボタンのスタイルを使用することが必要です。ボタンの色・フォント・最小サイズにも指定があるため、デザイン実装前にガイドラインを確認しておくことが手戻りを防ぎます。
Guideline 1.2 — UGCモデレーション体制の実装
SNS・掲示板・レビュー機能などユーザーが投稿できるアプリには、不適切なコンテンツを24時間以内に対処する仕組みが必要とされます*1。具体的には、「報告（Report）ボタンの設置」「運営によるコンテンツ削除機能」「利用規約への違反処理方針の明記」が含まれます。
これらの機能が実装されていない状態で申請すると、Guideline 1.2を理由にリジェクトされます。バックエンドのモデレーション管理画面も含めた実装が必要になるため、開発スコープとして最初から計画に入れておくことが大切です。
プライバシー・パーミッション — purpose stringの記述
カメラ・マイク・位置情報・写真ライブラリへのアクセスを要求するアプリは、Info.plistファイルにpurpose string（利用目的の説明文）を記述する必要があります。「カメラへのアクセスが必要です」のような抽象的な説明では不十分で、「プロフィール写真を撮影するためにカメラへのアクセスが必要です」のように具体的な用途を記述することが求められます。
また、実際には使用しないパーミッションをInfo.plistに記載している場合もリジェクト対象になります。使用するAPIとpurpose stringの組み合わせを事前に洗い出し、不要なパーミッション記述を削除しておくことが大切です。
理由別の対応：メタデータ・金融・最小機能
メタデータ関連と金融サービス・最小機能のリジェクトは、コード修正ではなくApp Store Connect上の設定変更や追記で対応できる場合があります。
メタデータ・説明・URLの不備
アプリの説明文に記載されている機能が実際のアプリに存在しない場合や、スクリーンショットが実際の画面と一致しない場合、メタデータ不備としてリジェクトされます。サポートURL・プライバシーポリシーURLが無効（404エラー）になっている場合も同様です。
対応は比較的シンプルです。説明文・スクリーンショットを現在の機能に合わせて更新し、URLが正常に機能しているか事前に確認します。プライバシーポリシーは外部のページに置いている場合も多いため、申請直前にアクセス確認を行うことが大切です。
Guideline 3.2.1 — 金融サービスの要件
投資・保険・ローン・クレジットなどの金融サービスを提供するアプリには、適用される法的要件・規制当局への登録状況・免責事項をアプリ説明または本文内に明示することが求められます*1。各国の規制が異なるため、提供対象国ごとの対応が必要になる場合があります。
Guideline 4.2 — 機能の充実度と独自性
Webサイトの内容をそのままWebViewで表示するだけのアプリや、App Storeにすでに存在するアプリとほぼ同じ機能しか持たないアプリはGuideline 4.2でリジェクトされます。「このアプリを使うことでユーザーにどのような独自の価値が提供されるか」をApp Store Connectの説明文で明確に示すとともに、アプリ固有の機能を実装しておくことが必要です。
Resolution Centerで再申請を進める手順
リジェクトを受けた後の正式な対応窓口がApp Store Connectの「Resolution Center」（解決センター）です。ここでAppleのレビュアーとやり取りを行い、修正内容を説明または質問ができます。
Resolution Centerでの補足説明
修正が完了したらResolution Centerで変更内容をコメントとして送付します。何を修正したかを具体的に記述することが大切です。「Guideline 4.0に関するご指摘を受け、Sign in with Appleボタンのサイズを他のサービスのボタンと同一にしました」といった形で、どのGuideline番号の指摘に対してどの変更を行ったかを明示します。
意図が伝わりにくいケース（UGCモデレーションの内部管理機能など）は、スクリーンショットや動画をResolution Centerに添付して説明することも有効です。一般ユーザー向け画面には表示されない管理機能の存在は、添付資料で可視化しないと審査側に伝わらないことがあります。
再申請時の留意点
修正後に再申請する際は、変更点を簡潔にまとめた「What’s New」（更新履歴）とともにバイナリをアップロードします。修正した箇所だけでなく、関連する機能全体が正常に動作することを複数環境で確認したうえで申請することが、再リジェクトを防ぐ基本です。
不服がある場合は、App Storeの「Appeal」（異議申し立て）プロセスを利用できます。ただし異議申し立ては修正対応より時間がかかるため、まず修正で対応できないかを検討することが現実的です。
外注でリジェクト対応を進める5ステップ
リジェクト対応を外注で進める場合、発注側がリジェクト理由の通知を受け取った段階で、外注先に情報を共有する体制を整えておくことが大切です。
ステップ1：リジェクト通知の内容共有と優先度の確認
Resolution Centerに届いたリジェクト通知（Guideline番号・指摘内容）を外注先と共有します。複数の理由が列挙されている場合、リリーススケジュールへの影響が大きいものから優先度を決めます。理由によっては対応期間が大きく異なるため、まず見積もり・スケジュール確認を行うことが大切です。
ステップ2：修正スコープの確定
各リジェクト理由に対して「コード修正が必要か」「メタデータ・説明文の変更で対応可能か」「設計変更が必要か」を仕分けします。コード修正が必要な場合は現行のソースコードへのアクセス権限を外注先に付与し、開発環境のセットアップを先行させます。
ステップ3：修正対応と動作確認
外注先が修正を行う間、発注側はResolution Centerのやり取り内容と修正内容が整合しているかをレビューします。特にpurpose stringやSign in with Appleのボタン配置など、ガイドラインへの準拠を発注側でも目視確認しておくことが手戻りを減らします。
ステップ4：Resolution Centerへの補足説明の準備
修正完了後、Resolution Centerに送付するコメントの草案を外注先に作成してもらい、発注側が承認してから送付します。英語での説明が求められる場合、外注先がAppleとのやり取りに慣れているかを事前に確認しておくことが大切です。
ステップ5：再申請と結果確認
修正バイナリをアップロードし再申請します。Appleの審査は通常数日以内に結果が通知されますが、複雑な案件ではより時間がかかることもあります。再審査中も外注先との連絡体制を維持し、追加の問い合わせが来た場合に素早く対応できる状態を保つことが大切です。
内製vs外注 — 比較と判断の目安
リジェクト対応を内製で行うか外注するかは、チームのiOS開発経験・App Store申請の頻度・リリーススケジュールの余裕によって判断が変わります。以下の比較表を参考にしてください。
| 比較軸 | 内製 | 外注 |
|---|---|---|
| 必要なスキル | iOS開発経験（Swift/Objective-C）＋App Store申請・Guidelines精読の経験＋英語での審査対応スキル | 発注側は要件整理とレビューができれば対応可能。 Apple対応の専門スキルは外注先に委ねられます。 |
| 対応スピード | 社内での意思決定が早い分、修正着手は迅速。 ただしApp Store申請経験が少ないと調査に時間がかかることがあります。 |
申請経験が豊富な外注先であれば、修正方針の策定が迅速。 契約・情報共有の準備があれば着手が早まります。 |
| リスク | 担当者のGuidelines理解度に依存。 修正が不十分なまま再申請し、再リジェクトになるリスクがあります。 |
ソースコードの共有や外注先とのコミュニケーションコストが発生します。 要件整理が不十分だと修正の方向がずれることがあります。 |
| 向いているケース | 社内にApp Store申請経験者がいて、修正量が軽微な場合。 継続的に申請・更新を行うアプリで申請ノウハウが蓄積されている場合 |
Guidelines精読が必要な複雑なリジェクト理由の場合。 社内にiOS開発リソースがなく、初めての申請またはリリーススケジュールが切迫している場合 |
内製を選ぶ場合でも、Guideline 3.2.1（金融）やGuideline 1.2（UGC）のように設計変更が必要な理由は、外注の専門知識を部分的に活用することでリスクを下げられます。
外注先選定で確認すべき3つのポイント
App Store審査リジェクト対応の外注は、一般的なiOSアプリ開発の外注とは異なる専門性が求められます。外注先を選ぶ際に確認すべき点を3つ挙げます。
App Store申請・リジェクト対応の実績があるか
iOSアプリの開発実績があっても、App Store申請やリジェクト対応の経験が少ない外注先では、Guidelinesの解釈や審査対応のノウハウが不足している場合があります。過去に同様のリジェクト理由への対応実績があるか、また複数アプリの申請・維持管理を手がけているかを確認します。
Resolution Centerでの英語対応・説明文作成ができるか
AppleのResolution Centerでのやり取りは英語です。修正内容を正確に伝える説明文の作成は、技術的な対応と同様に審査結果に影響します。英語での審査対応を外注先が担当できるか、または発注側が担当する場合にどのようにサポートを受けられるかを事前に確認しておくことが大切です。
修正後の動作検証と複数環境テストを納品物に含むか
修正コードを納品するだけで動作確認が含まれない場合、再申請後に別の箇所でクラッシュが発生するリスクがあります。外注先が複数のiOS端末・バージョンでの動作確認を実施し、テスト結果を報告書として提出するかを確認します。修正対応と動作検証を一貫して行える外注先であると、再リジェクトのリスクを下げられます。
まとめ：リジェクト対応を外注で成功させる3つの判断軸
本稿では、App Store審査リジェクトの判断基準であるApp Store Review Guidelinesの概要から、頻出リジェクト理由と理由別の対応、Resolution Centerでの再申請手順、外注で進める5ステップ、内製との比較までを整理しました。要点を3つにまとめます。
第一に、リジェクト理由はGuideline番号を起点に確認することです。通知に記載されたGuideline番号の該当箇所を精読し、対応の方向性を定めることがすべての出発点になります。感覚的な修正では再リジェクトのリスクが高まります。
第二に、理由によって対応の難易度が大きく異なる点を踏まえてスコープを確定することです。メタデータの修正で完結するものから、UGCモデレーション機能の新規実装が必要なものまで幅があります。外注時は最初の見積もり段階でスコープを明確にすることが手戻りを防ぎます。
第三に、外注先はApp Store申請実績・英語対応力・動作検証の範囲の3点で選定することです。この3点を事前に確認することで、修正後の再申請がスムーズに進む可能性が高まります。
よくある質問
リジェクト後の再申請まで、どのくらいの期間を見込めばよいですか。
修正の内容によって異なります。メタデータの変更のみであれば数日以内に対応できることがあります。コード修正を伴う場合は修正・テスト・バイナリ生成の工程が必要で、数日から数週間の期間を見込むのが現実的です。Appleの再審査も通常数日かかるため、リリーススケジュールに余裕を持たせた計画が大切です。
リジェクト理由が英語で書かれていて意味がわかりません。どうすればよいですか。
Resolution Centerの通知に記載されているGuideline番号（例：4.0、1.2）をApple公式の「App Store Review Guidelines」*1で検索すると、日本語版の説明を確認できます。指摘の意味が判断しにくい場合はResolution Centerから追加の質問を送ることもできます。外注先に依頼する際は通知のテキストをそのまま共有することで、正確な判断につながります。
Sign in with Appleはすべてのアプリに必須ですか。
App Store Review Guidelines（Guideline 4.0）では、サードパーティのログイン（Google・Facebook・Twitterなど）を採用するアプリはSign in with Appleも提供することが求められています*1。ただし、特定のビジネス向けSSOのみを使用するアプリなど、例外が認められるケースもあります。自社アプリに当てはまるかはガイドラインの該当箇所を確認するか、外注先に判断を依頼することが大切です。
リジェクトに異議申し立て（Appeal）を行った場合、どのような流れになりますか。
Appleには「App Review Board」への異議申し立てプロセスがあります。App Store Connectのヘルプページから申請でき、通常の再申請とは独立した審査を経て結果が通知されます。ただし異議申し立ては修正対応よりも時間がかかる場合があります。まずResolution Centerでの対話と修正再申請で解決を試み、それでも合意に至らない場合の選択肢として検討することが現実的です。
プライバシー・パーミッションのpurpose stringはどのように書けばよいですか。
purpose string（利用目的の説明文）は、ユーザーがパーミッションを許可・拒否する判断ができる程度に具体的に記述することが求められます。「カメラを使用します」という抽象的な記述ではなく、「QRコードの読み取りに使用します」「プロフィール写真の撮影に使用します」のように、アプリ内での具体的な用途を記述します。Info.plistファイルにNSCameraUsageDescription等のキーで記述し、使用するすべてのパーミッションにそれぞれ記載が必要です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple「App Store Review Guidelines」
