axiom-app-store-submission について
App Store に iOS アプリやアップデートを提出する開発者向けの事前確認スキルです。ビルド、プライバシー、メタデータ、審査情報を整理し、よくある却下原因も確認できます。
主な機能
- 01提出前の分類別チェックリスト
- 02プライバシーポリシーとマニフェストの確認
- 03メタデータと年齢レーティングの確認
- 04よくある却下原因と対処法
活用シーン
- 01初めての iOS アプリ提出前の要件確認
- 02アップデート前のプライバシーとメタデータの確認
- 03App Review 却下後の不足項目の特定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ charleswiltgen/ axiom --skill axiom-app-store-submissionインストール後、Claude Code で/axiom-app-store-submissionを入力して読み込まれたか確認します。
詳細
App Store 提出
概要
提出前に確認すべき体系的なチェックリストです。App Store での却下原因の90%を事前に検出します。基本原則:一度で正しく出荷する。App Store での却下の40%以上は、ガイドライン2.1(アプリの完全性)が原因です。クラッシュ、プレースホルダー、リンク切れなどが該当します。さらに30%はメタデータとプライバシーの問題です。規律ある提出前プロセスによって、こうした防げる却下をなくせます。
重要なポイント:Apple は2024年に約193万件の提出を却下しました。却下の大半はポリシーへの意見の相違ではなく、チェックリストの確認漏れが原因です。提出前に30分かけて確認すれば、却下・修正・再提出のサイクルにかかる3〜7日を節約できます。
このスキルを使うタイミング
✅ 次のような場合にこのスキルを使います:
- アプリまたはアップデートを App Store に提出する準備をしている
- 新しい開発者として初めてアプリを提出する
- App Review での却下に対応する
- TestFlight または本番公開の前に提出前監査を実施する
- 長い期間を空けて既存アプリを更新する(新しい要件が適用される場合があります)
- 「アプリを提出する準備はできているか」と確認したい
❌ 次の用途にはこのスキルを使わないでください:
- コード署名とプロビジョニングプロファイル(build-debugging を使用)
- CI/CD パイプラインの設定
- パフォーマンス最適化(ios-performance を使用)
- UI テストの自動化(ui-testing を使用)
- アプリ内課金の実装(storekit-ref を使用)
- プライバシーマニフェストの詳細(実装の詳しい説明には privacy-ux を使用)
質問例
このスキルで回答できる、開発者からよく寄せられる質問:
1. 「アプリを App Store に提出する準備はできていますか?」
このスキルでは、ビルド、プライバシー、メタデータ、アカウント、審査情報、コンテンツ、地域ごとの要件を網羅した完全な提出前チェックリストを提供します
2. 「初めて iOS アプリを提出する前に必要なものは何ですか?」
このスキルでは、プライバシーマニフェスト、メタデータ項目、スクリーンショット、デモ用認証情報、年齢制限指定など、必要なものを最初からすべて確認します
3. 「何度も却下されるのですが、何が足りないのでしょうか?」
このスキルでは、具体的な却下原因を示すアンチパターンと、抜け漏れを特定するための判断フローを提供します
4. 「App Store に提出する前のチェックリストは何ですか?」
このスキルでは、項目が欠けると却下につながる必須項目を分類したチェックリストを提供します
5. 「プライバシーマニフェストは必要ですか?」
はい。2024年5月以降、プライバシーマニフェストがないと自動的に却下されます。このスキルでは、必要となる条件と対応方法を説明します。
6. 「メタデータの問題でアプリのアップデートが却下されました」
このスキルでは、メタデータの完全性に関する要件と、ガイドライン2.3に基づく却下につながるよくある抜け漏れを扱います
アンチパターン
1. デバイスでテストせずに提出する
所要時間:3〜7日(却下+修正+再提出の待ち時間)
症状:ガイドライン2.1(アプリの完全性)に基づく却下。App Review によってクラッシュ、動作しないフロー、機能の欠落が見つかります。
❌ 悪い例:シミュレーターでのみテストし、ビルドに成功したら提出する
"It works in Simulator, ship it"
→ Rejection: App crashes on launch on iPhone 15 Pro (memory limit)
→ 3-7 day delay
✅ 良い例:最新の公開 OS を搭載した実機でテストし、ユーザーの操作フローをすべて確認する
# Build for device
xcodebuild -scheme YourApp \
-destination 'platform=iOS,name=Your iPhone'
# Test critical paths:
# - Launch → main screen loads
# - All tabs/screens accessible
# - Core user flows complete without crash
# - Edge cases: no network, low storage, interruptions
効果がある理由:シミュレーターでは、メモリ制限、モバイルネットワークの挙動、ハードウェア固有の API、熱によるパフォーマンス制限など、実機特有の制約が見えません。App Review は実機でテストします。
2. プライバシーポリシーの欠如または不備
所要時間:2~5 日(却下+ポリシーの作成+再提出)
症状:ガイドライン 5.1.1(i) — データの収集と保存に基づく却下です。プライバシーポリシーがない、アクセスできない、または実際のデータ取り扱いと一致していません。
❌ 悪い例:プライバシーポリシーの URL がない、または実際のデータ収集に合わない汎用テンプレートを使用している
Privacy Policy URL: (empty)
— or —
Privacy Policy: "We respect your privacy" (generic, no specifics)
✅ 良い例:プライバシーポリシーに 2 か所からアクセスでき、アプリのデータ取り扱いに即した内容になっている
1. App Store Connect → App Information → Privacy Policy URL
2. In-app → Settings/About screen → Privacy Policy link
3. Policy content lists:
- All collected data types
- How each type is used
- Third-party sharing (who and why)
- Data retention period
- How to request deletion
3 要素の整合性:Apple は、(a)アプリの実際の動作、(b)プライバシーポリシーの内容、(c)ASC のプライバシーラベルを照合します。3 つすべての内容を一致させる必要があります。いずれかが一致しないと、5.1.1 に基づいて却下されます。各 SDK のドキュメントで、プライバシーマニフェストとデータ収集の開示を確認してください。アプリ全体のデータ収集には、アプリのコードだけでなく、すべての SDK によるデータ収集も含まれます。
効果がある理由:ガイドライン 5.1.1(i) では、ASC のメタデータとアプリ内の両方からプライバシーポリシーにアクセスできることが求められます。汎用テンプレートではなく、アプリのデータ取り扱いを具体的に記載する必要があります。
3. ビルドにプレースホルダーのコンテンツが残っている
所要時間:3~5 日(却下+コンテンツの差し替え+再提出)
症状:ガイドライン 2.1 — アプリの完全性に基づく却下です。審査担当者が、プレースホルダーのテキスト、空の画面、または TODO の残骸を見つけます。
❌ 悪い例:開発時の残骸がユーザーに見える状態でリリースする
- "Lorem ipsum" text in onboarding
- Empty tab that shows "Coming Soon"
- Button that opens alert "Not implemented yet"
- Default app icon (white grid)
✅ 良い例:すべての画面に最終的なコンテンツと本番用アセットを用意する
Pre-submission content audit:
- [ ] Every screen has real content (no lorem ipsum)
- [ ] All images are final production assets
- [ ] No "Coming Soon" or "Under Construction" screens
- [ ] All buttons perform their intended action
- [ ] Default/empty states have proper messaging
- [ ] App icon is final and meets spec (1024x1024, no alpha)
効果がある理由:App Review は、エッジケースと思われる状態も含め、すべての画面とタブをテストします。すべてのメニューを開き、すべてのボタンをタップし、すべてのタブを切り替えます。
4. プライバシーマニフェストを無視している
所要時間:1~3 日(自動却下+マニフェストの作成+再提出)
症状:人による審査の前に自動却下されます。PrivacyInfo.xcprivacy がない、または Required Reason API が宣言されていません。
❌ 悪い例:プライバシーマニフェストがない、または Required Reason API の宣言が不足している
No PrivacyInfo.xcprivacy in project
— or —
Using UserDefaults, file timestamps, disk space APIs
without declaring approved reasons
✅ 良い例:プライバシーマニフェストを用意し、すべての Required Reason API を宣言している
Project must contain:
├── PrivacyInfo.xcprivacy
│ ├── NSPrivacyTracking (true/false)
│ ├── NSPrivacyTrackingDomains (if tracking)
│ ├── NSPrivacyCollectedDataTypes (all types)
│ └── NSPrivacyAccessedAPITypes (all Required Reason APIs)
│
└── Third-party SDK manifests (each SDK includes its own)
宣言が必要な一般的な Required Reason API:
UserDefaults→ 理由CA92.1- ファイルのタイムスタンプ API → 理由
C617.1 - ディスク容量 API → 理由
E174.1 - システムの起動時刻 → 理由
35F9.1
効果がある理由:2024 年 5 月以降、これは自動チェックのゲートとなっています。人による審査は行われず、必要なプライバシー宣言が不足している提出物は、ビルド処理システムによって却下されます。
5. Sign in with Apple がない
所要時間:3~7 日(SIWA の実装+再提出)
症状:ガイドライン 4.8 に基づく却下です。アプリでサードパーティのログイン(Google、Facebook、メール)を提供しているものの、Sign in with Apple の選択肢がありません。
❌ 悪い例:SIWA を使わずにサードパーティのログインを提供する
// Login screen offers:
// - Sign in with Google
// - Sign in with Facebook
// - Email/password
// ← Missing: Sign in with Apple
✅ 良い例:サードパーティのログインと並べて、同等の選択肢として SIWA を提供する
// Login screen offers:
// - Sign in with Apple ← Required if others exist
// - Sign in with Google
// - Sign in with Facebook
// - Email/password
例外(SIWA が不要な場合):
- 社内向けまたは従業員専用のアプリ
- 既存の学校アカウントを使用する教育アプリ
- 政府発行 ID が必要な政府機関、税務、銀行関連のアプリ
- 特定のサードパーティサービス専用のクライアントであるアプリ
- 会社独自の認証システムのみを使用するアプリ
効果がある理由:ガイドライン 4.8 では、サードパーティまたはソーシャルログインを少しでも提供する場合、SIWA を選択肢として用意することが求められます。Apple はこれを厳格に適用しています。
6. アカウント削除の手段がない
所要時間:5~10 日(実装+テスト+再提出)
症状:ガイドライン 5.1.1(v) に基づく却下です。アプリでアカウントを作成できますが、削除する手段がありません。
❌ 悪い例:アカウントを作成できるが、削除できない
- Sign up button exists
- No "Delete Account" anywhere in app
- "Contact support to delete" (not sufficient)
- "Deactivate account" (not the same as delete)
✅ 良い例:アプリ内から利用できる、完全なアカウント削除の手順を用意する
Account deletion requirements:
1. Discoverable in Settings/Profile (not hidden)
2. Clearly labeled "Delete Account" (not "Deactivate")
3. Explains what deletion means (data removed, timeline)
4. Confirms completion to user
5. If Sign in with Apple used → revoke SIWA token
6. If active subscriptions → inform user to cancel first
7. Deletion completes within reasonable timeframe (days, not months)
// Revoking Sign in with Apple token (required)
let appleIDProvider = ASAuthorizationAppleIDProvider()
let request = appleIDProvider.createRequest()
// After user confirms deletion:
// POST to Apple's revoke endpoint with the user's token
// Then delete server-side account data
効果がある理由:2022 年 6 月以降、必須となっています。実際に削除できる必要があり(無効化だけでは不十分)、アプリ内で完結する必要があります(メールやウェブサイトだけでは不十分)。SIWA を使用している場合は、そのトークンも取り消さなければなりません。Apple はこの手順を特にテストします。
7. 不適切な年齢レーティング
所要時間:2〜4日(質問票への再回答+コンテンツの変更が必要になる場合あり+再提出)
症状:ガイドライン 2.3.6「不正確なメタデータ」による却下です。年齢レーティングが、アプリの実際のコンテンツや機能を反映していません。
❌ 悪い例:低いレーティングを得るために、コンテンツを実際より控えめに申告する
App has user-generated content (chat, posts)
but age rating questionnaire answered "No UGC"
App has cartoon violence in gameplay
but answered "No violence"
✅ 良い例:年齢レーティングの質問票に正確に回答する
Declare honestly:
- User-generated content (chat, forums, social features)
- Violence (even cartoon/fantasy)
- Mature themes
- Profanity / crude humor
- Gambling (simulated or real)
- Horror / fear themes
- Medical / treatment information
- Unrestricted web access (WebView with open URLs)
更新された年齢レーティング(2026年1月31日適用):Apple はレーティングを 4+/9+/12+/17+ の 4 段階から、メッセージ機能、UGC、広告、ペアレンタルコントロールに関する新たな機能申告を含む 5 段階(4+/9+/13+/16+/18+)に拡大しました。すべての開発者は更新された質問票への回答を完了する必要があります。回答が完了していない場合、アプリのアップデートはブロックされます。
効果がある理由:レーティングの不一致はガイドライン 2.3.6 に違反します。Apple は、質問票への回答と、確認されたアプリの動作を照合します。UGC とウェブアクセスは、申告漏れが最も多い項目です。
8. デモ用ログイン情報の未提供
所要時間:3〜5日(却下+ログイン情報の作成+再提出の待機)
症状:ガイドライン 2.1 による却下です。ログインが必要で、テスト用アカウントも提供されていないため、審査担当者がアプリをテストできません。
❌ 悪い例:アプリでログインが必要なのに、審査メモにデモ用アカウントが記載されていない
App Review Information:
Notes: (empty)
Demo Account: (empty)
Demo Password: (empty)
→ Reviewer sees login screen, can't proceed, rejects
✅ 良い例:動作するデモ用ログイン情報と明確な手順を提供する
App Review Information:
Demo Account: [email protected]
Demo Password: AppReview2025!
Notes: "Log in with the demo account above.
The account has sample data pre-loaded.
To test [feature X], navigate to Tab 2 > Settings.
If 2FA is required, use code: 123456"
Requirements:
- Account must not expire during review (1-2 weeks minimum)
- Account must have representative data
- Include any special setup steps
- If hardware required, explain workarounds
- If location-specific, provide test coordinates
効果がある理由:審査担当者はアクセスできないものをテストできません。自分でアカウントを作成することもありません。アプリで何らかの認証が必要な場合、デモ用ログイン情報は必須です。ログインフローがあるアプリで、却下理由として特に多いものの一つです。
判断フローチャート
Is my app ready to submit?
│
├─ Does it crash on a real device?
│ ├─ YES → STOP. Fix crashes first (Guideline 2.1)
│ └─ NO → Continue
│
├─ Privacy manifest (PrivacyInfo.xcprivacy) present?
│ ├─ NO → Add privacy manifest with Required Reason APIs
│ └─ YES → Continue
│
├─ Privacy policy URL set in App Store Connect?
│ ├─ NO → Add privacy policy URL in ASC
│ └─ YES → Is it also accessible in-app?
│ ├─ NO → Add in-app privacy policy link
│ └─ YES → Continue
│
├─ All screenshots final and matching current app?
│ ├─ NO → Update screenshots for all required device sizes
│ └─ YES → Continue
│
├─ Does app create user accounts?
│ ├─ YES → Account deletion implemented and discoverable?
│ │ ├─ NO → Implement account deletion flow
│ │ └─ YES → Continue
│ └─ NO → Continue
│
├─ Does app offer third-party login (Google, Facebook, etc.)?
│ ├─ YES → Sign in with Apple offered?
│ │ ├─ NO → Add SIWA (unless exemption applies)
│ │ └─ YES → Continue
│ └─ NO → Continue
│
├─ Does app have in-app purchases or subscriptions?
│ ├─ YES → IAP items submitted for review in ASC?
│ │ ├─ NO → Submit IAP for review (can be reviewed separately)
│ │ └─ YES → Restore Purchases button implemented?
│ │ ├─ NO → Add Restore Purchases functionality
│ │ └─ YES → Continue
│ └─ NO → Continue
│
├─ Does app use encryption beyond standard HTTPS?
│ ├─ YES → Export compliance documentation uploaded?
│ │ ├─ NO → Add ITSAppUsesNonExemptEncryption to Info.plist
│ │ │ and upload compliance documentation
│ │ └─ YES → Continue
│ └─ NO → Set ITSAppUsesNonExemptEncryption = NO in Info.plist
│
├─ Distributing in EU?
│ ├─ YES → DSA trader status verified in ASC?
│ │ ├─ NO → Complete trader verification in ASC
│ │ └─ YES → Continue
│ └─ NO → Continue
│
├─ Does app require login to function?
│ ├─ YES → Demo credentials in App Review notes?
│ │ ├─ NO → Add working demo account + password + instructions
│ │ └─ YES → Continue
│ └─ NO → Continue
│
├─ Age rating questionnaire completed honestly?
│ ├─ NO → Complete updated questionnaire (new 13+/16+/18+ ratings)
│ └─ YES → Continue
│
├─ Any placeholder content remaining?
│ ├─ YES → Replace all placeholders with final content
│ └─ NO → Continue
│
└─ All checks passed → READY TO SUBMIT
提出前の必須チェックリスト
提出するたびに、このチェックリスト全体を実施してください。該当すると思う項目だけでなく、すべての項目を確認してください。
1. ビルド設定
- 現在必要な SDK でビルド済み(2025年時点では iOS 18 SDK/Xcode 16、2026年4月28日以降は iOS 26 SDK/Xcode 26 が必須)
- Info.plist で
ITSAppUsesNonExemptEncryptionを設定済み(HTTPS のみの場合はNO) - 最新の正式リリース版 iOS を搭載した実機でアプリをテスト済み
- IPv6 のみのネットワークでアプリが動作する(Apple の審査ネットワークは IPv6)
- 非公開または非公式の API を使用していない
- 対象 OS 向けでない限り、プレリリース版/ベータ版 OS の機能への参照がない
- 最低デプロイメントターゲットが妥当である(不必要に高く設定していない)
- リリースビルドをテスト済み(デバッグ設定のみではない)
2. プライバシー
- アプリのターゲットに
PrivacyInfo.xcprivacyファイルが含まれている - すべての Required Reason API を、承認済みの理由コードとともに申告済み
- 各サードパーティ SDK に独自のプライバシーマニフェストが含まれている
- App Store Connect にプライバシーポリシーの URL を設定済み
- アプリ内(設定/情報画面)からプライバシーポリシーにアクセスできる
- プライバシーポリシーの内容が実際のデータ収集方法と一致している
- すべての
NS*UsageDescription用途説明文が存在する(カメラ、位置情報など) - 用途説明文でユーザーにとってのメリットを説明している(「アクセスが必要です」だけではない)
- ユーザーをトラッキングする場合は App Tracking Transparency を実装済み(ATT)
- Privacy Nutrition Labels がマニフェストと一致するよう ASC で入力済み
3. メタデータ
- アプリ名(30文字以内、キーワードの詰め込みなし)
- サブタイトル(30文字以内)
- 説明(正確で、誤解を招く主張がない)
- キーワード(100文字以内、カンマ区切り)
- カテゴリとサブカテゴリを設定済み
- 必要なすべてのデバイスサイズのスクリーンショットを用意済み(iPhone:6.9インチ、6.7インチ、6.5インチ、5.5インチ。ユニバーサルアプリの場合、iPad:13インチ)
- スクリーンショットが現在のアプリ UI を反映している(古くない)
- App Preview の動画が最新である(使用している場合)
- サポート URL が有効で、アクセス可能
- マーケティング URL が有効(設定している場合)
- 著作権表記の年が最新
- バージョン番号とビルド番号を更新済み
- アップデートの場合、「新機能」のテキストを作成済み
4. アカウントと認証
- アカウント作成機能がある場合、アカウント削除のフローを実装済み
- アカウント削除で実際に削除される(無効化のみではない)
- アカウント削除時にSIWAトークンを取り消す(SIWAを使用する場合)
- サードパーティーのログイン機能がある場合、「Sign in with Apple」を提供
- アカウント削除時に有効なサブスクリプションを処理
- 購入を復元ボタンが機能する(IAPがある場合)
- IAP項目をASCで審査に提出済み(新規または変更がある場合)
- 購入前にサブスクリプションの条件を明確に伝える
5. アプリ審査情報
- 連絡先情報(氏名、電話番号、メールアドレス)を入力済み
- デモアカウントのユーザー名を入力済み(ログインが必要な場合)
- デモアカウントのパスワードを入力済み(ログインが必要な場合)
- 審査期間中(1~2週間)にデモアカウントの有効期限が切れない
- デモアカウントに代表的なサンプルデータがある
- ハードウェアに依存する機能について特別な手順を記載
- 自明でない機能やフローについて説明を記載
- アプリが位置情報を使用する場合、テスト用の座標を記載
6. コンテンツの完全性
- プレースホルダーテキスト(lorem ipsum、TODO、「近日公開」)がない
- リンク切れや行き止まりの画面がない
- すべての画像が本番用アセットである(透かし入りのストック画像がない)
- アプリアイコンが仕様を満たしている(1024x1024、アルファチャンネルなし、角丸なし)
- すべてのタブ/画面に機能するコンテンツがある
- エラー状態と空の状態に適切なメッセージがある
- オンボーディング/チュートリアルのフローが完成しており、正確である
- すべてのディープリンクとユニバーサルリンクが正しく解決される
7. 地域およびコンプライアンス
- EUで配信する場合、EU DSAのトレーダー資格を確認済み
- 年齢レーティングの質問票を更新されたカテゴリ(13+/16+/18+)で記入済み
- 年齢レーティングが実際のコンテンツを反映している(UGC、暴力、ウェブアクセスを申告済み)
- 輸出コンプライアンス文書をアップロード済み(免除対象外の暗号化を使用する場合)
- 各配信地域の現地法にコンテンツが準拠している
- GDPRに準拠している(EUで配信する場合)
8. 2025~2026年の新要件
- 更新された年齢レーティングの質問票を記入済み(2026年1月31日以降必須)
- アクセシビリティ栄養ラベルを申告済み(新規提出で必須化予定)
- 外部AIサービスの同意モーダルを用意済み(アプリが個人データを外部AIに送信する場合)
- SDKの最低バージョンを満たしている(現在はXcode 16/iOS 18 SDK、2026年4月28日からはXcode 26/iOS 26 SDK)
プレッシャーのかかる状況
シナリオ1:「今日中にリリース」
状況:PMから、来週のマーケティング開始に向けて、今日中にアプリを提出する必要があると言われます。
プレッシャー:締め切り+経営陣の注目
ありがちな合理化:
- 「プライバシーポリシーは承認後に修正します」
- 「プレースホルダーがあるのは1画面だけなので、気づかれないでしょう」
- 「アカウント削除は次のアップデートで追加します」
- 「社内テストには合格したので、実機テストは不要です」
必須:出荷前チェックリストをすべて実施してください。すべての項目が対象です。項目の見落としは却下につながり、さらに3~7日かかります。チェックリストにかかる30分より、はるかに大きな損失です。
30分を節約するためにチェックリストを省略すると、却下された場合に3~7日を失います。
コミュニケーション用テンプレート:「出荷前チェックで、却下につながる問題が[N]件見つかりました。修正には[X時間]かかります。修正せずに提出すれば確実に却下され、少なくとも3~7日かかります。今すぐ修正させてください。公開までの最短ルートです。」
シナリオ 2:「3回目の却下、もう何でもいいから通したい」
状況:アプリが毎回異なる問題で3回却下されました。開発者は苛立ちを感じ、手を抜いたり、Appleと議論したりしたくなっています。
プレッシャー:苛立ち+サンクコスト+修正する代わりに不服申し立てをしたい誘惑
合理化の落とし穴:
- 「次々と新しい問題を見つけてくる。不公平だ」
- 「今回は不服申し立てをする。理不尽だ」
- 「審査担当者には、その画面を隠しておこう」
必須:却下メッセージをすべて全文読んでください。完全な事前チェックリストを最初から実施してください。審査担当者が後続の審査で新たな問題を見つけることはよくあります。審査のたびに、前回たどり着かなかった画面を確認し、前回省略したフローをテストし、より厳しい注意を払って審査するためです。
却下のたびに、提出前のプロセスに抜けがあるという兆候が示されています。フィードバックに反論するのではなく、受け止めて、抜けを体系的に埋めてください。
コミュニケーションテンプレート:「却下が複数回続くのは、運が悪いのではなく、体系的な抜けがあるということです。完全な事前チェックリストを実施します。30分かかりますが、部分的な修正のあとに新たな却下を受けるという3~7日周期を防げます。」
シナリオ 3:「ただのバグ修正アップデートです」
状況:1行だけの簡単なバグ修正です。アプリはすでに承認されているため、開発者はアップデートも問題なく審査を通過すると考えています。
プレッシャー:油断+過去の承認による誤った自信
合理化の落とし穴:
- 「前回は同じメタデータで承認された」
- 「変更したのは1ファイルだけだから、すべてを再審査する必要はない」
- 「プライバシー関連は変更していないから、再確認されることはない」
必須:アップデートは現行のガイドラインに基づいて審査されます。リリースの間に要件が変更されることがあります。プライバシーマニフェストはサイクルの途中で必須になりました。年齢レーティングの質問票は全面的に改定されました。SDK の最低要件は毎年引き上げられます。バグ修正のアップデートでも、前のバージョンが承認された時点では存在しなかった問題で却下される可能性があります。
毎回、事前チェックリストを実施してください。アプリが最後に審査された時点では存在しなかった要件が、今は適用されている可能性があります。
コミュニケーションテンプレート:「バグ修正だけの場合でも、App Review は前回承認された時点のガイドラインではなく、現行のガイドラインを適用します。プライバシーマニフェストの要件と年齢レーティングの改定は、どちらもサイクルの途中で導入されました。今30分の事前チェックを行えば、予期せぬ却下を防げます。」
スクリーンショットの要件
スクリーンショットは、現在のアプリの UI と一致している必要があります。必要なサイズ、寸法、ルールについては app-store-ref のパート1を参照してください。
却下への対応
却下メッセージを読む
却下メッセージには、次の内容が含まれています。
- ガイドライン番号 — 違反した特定のセクション
- 説明 — 審査担当者が確認した内容
- スクリーンショット/録画 — 視覚的な証拠(該当する場合)
- 提案 — 修正方法が記載される場合があります
対応方針
1. Read the FULL rejection message (every word)
2. Identify ALL guidelines cited (may be multiple)
3. Fix EVERY cited issue (not just the first one)
4. Run the complete pre-flight checklist
5. In your resubmission notes, explain what you fixed
6. Do NOT argue or explain why you think the rejection is wrong
不服申し立てをする場合
次の場合は、不服申し立てが適切です。
- 審査担当者がアプリの機能を誤解したと思われる
- アプリが、指摘されたガイドラインに明らかに準拠している
- 自分の主張を裏付ける証拠がある
次の場合、不服申し立ては適切ではありません。
- ガイドライン自体に異議がある
- 却下の技術的な判断は正しいものの、不公平だと感じる
- 問題の修正を先延ばしにしたい
不服申し立ての手順
App Store Connect → Resolution Center → Reply
- Explain clearly why you believe the rejection is incorrect
- Provide specific evidence (screenshots, documentation)
- Remain professional and factual
- Apple's App Review Board will re-review
- One appeal per rejection
- Must respond to all information requests BEFORE appealing
優先審査
対象となるシナリオは2つです。
- 重大なバグ修正 — 現在公開中のバージョンでバグを再現する手順を記載してください
- イベント関連アプリ — イベント名、開催日、イベントとの関係を記載してください
コミュニケーションの選択肢(見落とされがち)
- 「App Review との面談」セッション — Apple は定期的に30分の予約枠を提供しています。空き状況は developer.apple.com/events で確認してください(常時予約可能とは限りません)
- バグ修正に対する柔軟な対応 — Apple は、追加で対応すべき法的・安全性に関わらない問題について情報メモを付け、リリースをブロックせずにバグ修正の提出を承認する場合があります。保証はありませんが、実際に行われることがあります。
- App Store Connect モバイルアプリを使った外出先でのステータス確認
メタデータの却下とバイナリの却下
| 種類 | 意味 | 対応方法 |
|---|---|---|
| メタデータの却下 | スクリーンショット、説明、またはASCの項目を修正する必要があります | ASCで修正して再提出します(新しいビルドは不要です) |
| バイナリの却下 | コード/アプリの問題を修正する必要があります | コードを修正し、新しいアーカイブを作成して、新しいビルドをアップロードします |
アプリ内課金の審査
IAP項目は個別の審査が必要です。IAPの不足や不具合は、ガイドライン3.1.1における却下の主な原因です。
IAP提出チェックリスト
- すべてのIAP製品をASCで作成し、メタデータをすべて入力している
- 各製品のIAP審査用スクリーンショットをアップロードしている(購入時にユーザーに表示される画面を示すもの。審査専用で、App Storeには表示されません)
- IAP製品をこのバージョンに紐付けている(初回提出時のみ:App Versionページ → In-App Purchasesセクション → Select → 各製品にチェックを入れます)。初回承認後は、以降のIAPを個別に提出できます。
- IAP製品を審査に提出している
- 購入を復元ボタンが表示され、機能している
- 購入確認の前にサブスクリプションの条件(価格、期間、自動更新)が表示されている
- 購入画面に利用規約とプライバシーポリシーへのリンクが表示されている(ガイドライン3.1.2(c)で参照されているDPLAのSchedule 2で必須です)。
SubscriptionStoreViewはASCのメタデータから自動的に処理します。カスタムのペイウォールUIを使用する場合は、リンクを手動で追加してください。 - 無料トライアルの条件が明確に伝えられている
- 表示されている価格がASCの設定と一致している
- エンタイトルメントの対象となる場合を除き、外部購入リンクがない(ガイドライン3.1.1)
- サンドボックス環境でStoreKitのテストを完了している
よくあるIAPの却下パターン
❌ "Buy Premium" button that does nothing → Guideline 3.1.1
❌ No Restore Purchases option → Guideline 3.1.1
❌ Subscription auto-renews without clear disclosure → Guideline 3.1.2
❌ Free trial duration not shown before purchase → Guideline 3.1.2
❌ External purchase link without entitlement → Guideline 3.1.1
❌ IAP products not attached to submission version → Guideline 2.1 (reviewer can't see them)
❌ No review screenshot on IAP product → Guideline 2.1 (reviewer can't verify purchase UI)
❌ Terms of Use / Privacy Policy missing from paywall → DPLA Schedule 2 (use SubscriptionStoreView to avoid)
よくある却下理由のクイックリファレンス
| ガイドライン | 問題 | 防止策 |
|---|---|---|
| 2.1 | クラッシュ、機能の不具合、未完成 | デバイステスト、コンテンツ監査 |
| 2.1 | 審査担当者にIAPが表示されない | IAPをバージョンに紐付ける(ASCでチェックボックスを選択)、審査用スクリーンショットをアップロードする |
| 2.3 | 不正確なメタデータ、誤ったスクリーンショット | スクリーンショットの監査、メタデータの確認 |
| 2.3.6 | 不適切な年齢制限指定 | 質問票に正直に回答し、UGCを申告する |
| 3.1.1 | IAPの問題、購入を復元の不足 | すべてのIAPフローをテストし、復元機能を追加する |
| 4.0 | デザイン:UIの品質が低い、標準的でないパターン | HIGに従い、すべてのサイズでテストする |
| 4.8 | Appleでサインインがない | サードパーティのログインを導入する場合は、SIWAを追加する |
| 5.1.1(i) | プライバシーポリシーの不足/不備 | ASCとアプリ内の両方に掲載し、具体的な内容を記載する |
| 5.1.1(v) | アカウント削除機能がない | アプリ内で削除できるようにし、無効化だけにしない |
| 5.1.2 | 必須理由APIの不足 | プライバシーマニフェストを完成させる |
App Store Connectの提出ワークフロー
ASCへのアップロード手順とビルド処理の詳細については、app-store-refのPart 9を参照してください。
暗号化の輸出コンプライアンス
ほとんどのアプリでは、ITSAppUsesNonExemptEncryption = falseが必要です。判断フロー全体については、app-store-refのPart 5を参照してください。
アクセシビリティの栄養成分表示(2025年開始)
新規提出では、アクセシビリティの栄養成分表示が必須になりつつあります。表示項目の一覧と申告ルールについては、app-store-refのPart 10を参照してください。申告前にaxiom-accessibility-diagを実行してください。
初めて提出する開発者向けチェックリスト
アプリを初めて提出する開発者が見落としがちな追加項目を以下に示します。プライバシーポリシーを一から作成する必要がある場合は、プライバシーポリシーのジェネレーター(無料のものも多数あります)を使用し、アプリの実際のデータ取り扱いに合わせてカスタマイズしてください。一般的なテンプレートのままでは却下されます。
Apple Developer Program
- Apple Developer Programに登録している(年間99ドル)
- 最新のApple Developer Program License Agreementに同意している
- ASCで税務情報と銀行情報を入力している(有料アプリ/IAPの場合)
- 配布証明書を作成している
- 正しいバンドル識別子でApp IDを登録している
- App Store配布用のプロビジョニングプロファイルを作成している
App Store Connect の設定
- ASC で新しいアプリのレコードを作成済み
- Bundle ID が Xcode プロジェクトと完全に一致
- メイン言語を設定済み
- コンテンツの権利を申告済み(オリジナルコンテンツまたはライセンス取得済み)
- 価格と配信状況を設定済み
- 配信対象地域を選択済み(全世界または特定の国)
初回によくあるミス
| ミス | 結果 | 修正方法 |
|---|---|---|
| Xcode と ASC の Bundle ID が一致しない | アップロードが却下される | 大文字・小文字を含め、完全に一致させる |
| 配布証明書の期限切れ/未作成 | アーカイブをアップロードできない | Developer Portal で新しい証明書を作成する |
| ライセンス契約に同意していない | アップロードがブロックされる | developer.apple.com で同意する |
| 税務書類が未完了 | 有料アプリが配信されない | ASC → Agreements, Tax, and Banking で手続きを完了する |
| Xcode で誤ったチームを選択 | 署名エラーが発生する | Signing & Capabilities で正しいチームを選択する |
実際の効果
事前:開発者がチェックリストなしで提出 → プライバシーマニフェストの不足で却下(3日) → 修正して再提出 → SIWA の不足で却下(5日) → 修正して再提出 → プレースホルダーコンテンツを理由に却下(3日) → 防げた問題で11日を浪費
事後:開発者が30分の提出前チェックを実施 → 3つの問題をすべて発見 → 4時間で修正 → 初回提出で承認
重要なポイント:チェックリストにかかる時間は30分です。却下のたびに3~7日かかります。計算は簡単です。
リソース
WWDC:2022-10166、2025-328、2025-224、2025-241
ドキュメント:/app-store/review/guidelines、/app-store/submitting、/app-store/app-privacy-details、/support/offering-account-deletion-in-your-app、/documentation/security/complying-with-encryption-export-regulations
スキル:axiom-privacy-ux、axiom-storekit-ref、axiom-accessibility-diag、axiom-testflight-triage、axiom-app-store-connect-ref