erberkk/review-readiness

審査準備チェックリスト

目的

一度提出して通過する。ほとんどの却下理由はアプリのアイデア自体ではなく、レビュアーがログインできない、購入できない、プレースホルダーを見た、メタデータとアプリに矛盾がある、といった点に起因します。

前提条件

• 提出する正確なビルドが TestFlight / Play テストトラックにあること。
• subscriptions-and-payments チェックポイントを通過していること（両プラットフォームで実際の購入によりプレミアムがアンロックされた状態）。
• privacy-and-declarations が完了していること。listing-and-aso バリデーターがクリーンであること。スクリーンショットがアップロードされていること。

知識ゼロのレビュアーとして考える

レビュアーは、あなたがテストしていない端末（iPhone 専用アプリでも iPad 互換モードで審査される可能性あり）、新しいストアアカウント、限られた時間で、クリーンビルドをインストールすると仮定します。レビュアーはあなたのノートを読み、サインインを試し、購入を探し、スクリーンショットとアプリを比較します。一回の却下で複数の要素（アカウント状態、バックエンド動作、メタデータ）が重なることがあります。

手順

1. デモアカウント

• 認証情報は App Store Connect › App Review Information（「Sign-in required」）と Play › App content › App access に記載します。リポジトリには絶対に含めません。
• アカウントはメールアドレス + パスワードでサインインします。 通常のサインインがメールワンタイムコードやマジックリンクの場合、レビュアーはそれを受信できません。審査用アドレスのみパスワードパスを追加する（サーバーサイドで許可リスト）か、そのアドレスでのみ機能する固定テストコードを用意します。
• データが投入されていること: プロフィールが完了、数日分の履歴、すべての主要画面にデータが表示される状態。空のアカウントでは機能が隠れ、「機能 X を見つけられませんでした」という却下を招きます。
• プレミアムがアンロックされていること: サーバーサイドで手動付与（審査中に期限切れにならないもの）により、レビュアーは購入せずに有料機能を確認できます。
• 別途、新規ユーザーがペイウォールに到達し、レビュアーのサンドボックスアカウントで購入できること（審査時にも購入テストが行われます）。
• 審査が公開されている間、このアカウントを変更、削除、再シードしないでください。

2. 購入（2.1(b) および 3.1.x）

• 初回バージョンのサブスクリプションは App Store Connect のバージョンページ（「In-App Purchases and Subscriptions」セクション）に紐付けられ、審査用スクリーンショットとノートが必要です。新しい App Store Connect UI ではバージョンページにこのセクションがない場合があります。その場合はサブスクリプショングループと各サブスクリプションを開き、Add for Review → Draft Submission を使用します。バージョン自体はそのページから追加します。ドラフトにはバージョン、グループ、すべてのサブスクリプションがリストされている必要があります。
• 各サブスクリプションには最低1つの表示名 + 説明のローカライゼーションと審査用スクリーンショットが必要です。これがないと「Add for Review」が失敗します（「You must add at least one subscription localization / a Review Information screenshot」）。
• 審査用スクリーンショットは実際のペイウォールと実際の価格、正しいストア表記を示す必要があります。ウィジェット/UI テストからレンダリングする場合は iOS プラットフォームを強制し（そうしないと「Google Play」と表示される）、実際のストア価格を入力します。「価格情報なし」の状態は許容されません。
• App Store のバージョン文字列はビルドのマーケティングバージョン（CFBundleShortVersionString）と一致している必要があります。 バージョン 1.0 と名付けると、1.0.0 としてアップロードされたビルドは表示されません。「Build」セクションに「Upload your builds」と表示され「Add Build」ボタンがありません。バージョン名を一致させてください。
• TestFlight で新しいサンドボックス Apple アカウント（あなたのアプリアカウントとリンクしていないもの）を使用して：商品がロードされ、購入が機能し、リストアが機能すること。
• ペイウォールのエラー状態は再試行を表示し、無効な「Coming soon」を表示しないこと。
• アプリ内で IAP にアクセスできない場合（例：特定リージョンのみ）、審査ノートでその理由を説明してください。
• 「購入をリストア」、「利用規約」、「プライバシー」のリンク、サブスクリプション管理リンクが存在すること。

3. 端末とビルド

• ネットワークなし、低速ネットワーク、機内モードの切り替えでのコールドスタート：クラッシュなし、無限スピナーなし。
• iPad: iPhone 専用アプリでも iPad 互換モードで動作し、そこで審査される可能性があります。iPad シミュレーターで全フローを実行：サインイン（Apple でサインインを含む）、ペイウォールのスクロール、購入シート、フォーム上のキーボード、許可プロンプト、画面回転。HealthKit など一部の API が利用できない場合は、丁寧なメッセージを表示し、クラッシュしないこと。
• 最小対応電話と最大テキストサイズ：ペイウォールや同意画面でボタンがクリップされないこと。
• リリースビルド（デバッグではない）：デバッグバナー、テストメニューなし。分析/クラッシュレポートは本番設定で動作すること。
• 物理端末で、提出する正確なビルドを使用して全アカウントライフサイクルを確認：インストール、サインアップ、主要機能、サンドボックス購入、アカウント削除、削除後のアプリ表示。

4. コンテンツとメタデータ

• アプリの文字列とリストで以下を検索：TODO、lorem、coming soon、beta、test、[PRICE]、プレースホルダー画像。これらが表示されてはいけません。
• iOS ビルドとメタデータに Android / Google Play の表記がないこと。Play に Apple 専用の表記がないこと（2.3.10）。アプリ内文字列も含む。「Cancel in App Store or Google Play」のような表記はランタイムでプラットフォームに合わせたテキストにすること。
• すべてのスクリーンショットが現在の UI と一致していること。説明文の数字がアプリと一致していること。
• プライバシーポリシー、利用規約、サポート、アカウント削除の URL がログインなしで読み込め、アプリについて言及し、プライバシーフォームと一致していること。
• 年齢制限が利用規約と一貫していること。

5. バックエンド

• バックエンドが起動しており、審査中に制限に達しないプランであること（無料枠が一時停止/スロットリングされると却下）。
• 審査中に破壊的変更をデプロイしないこと。審査中のビルドに対して後方互換性のある API。
• アラートが設定されていること（post-launch-ops）。審査中の障害に気づくため。

6. 審査ノート

templates/review-notes.md を記入します。事実のみを記載：機能の場所、サインイン方法、購入のテスト方法、AI と健康データの取り扱い、アカウント削除の場所。

Apple は審査の代わりに ガイドライン 2.1「Information Needed」 で応答することがあります。ある事例では以下の6項目を求められました。最初の提出でこれらを事前に回答しておくことでラウンドトリップを回避できます：

1. 最新 OS の物理端末での画面録画。アプリ起動から、登録、ログイン、アカウント削除、ユーザー生成コンテンツ（報告/ブロック機能）、有料コンテンツへのアクセスまでの典型的なフロー。提出するビルドで録画し、提出のメッセージにファイルを添付（またはリンク）し、ノートにその旨を記載。削除部分にはデモアカウントを使用せず、録画内で新規アカウントを作成すること。
2. アプリの目的とターゲットオーディエンス：解決する問題とその価値。
3. 主要機能のセットアップとアクセス手順。デモ認証情報とメニューパス。
4. コア機能の背後にあるすべての外部サービス：認証/データベース、決済（StoreKit + ラッパー）、AI プロバイダー、データソース（地図 API など）、メール、ヘルスフレームワーク。
5. 地域差、またはすべての地域で同じ機能であるという声明。
6. 規制対象分野または第三者の保護コンテンツ：該当しない旨のドキュメントまたは声明（例：「一般ウェルネス、医療機器ではない」）。

7. Go/No-Go レポート

templates/go-no-go-report.md に各項目の証拠（スクリーンショット、ビルド番号、コマンド出力）を記入します。ブロッキング項目で No がある場合は提出不可。

8. 提出（APPROVAL）

アカウント所有者にレポートを添付して明示的な承認を求めます。iOS では手動リリースを選択し、承認後すぐに公開されないようにします。Play では、プロダクションアクセス（新規個人アカウント）には14日間のクローズドテスト完了とプロダクションアクセス申請が先に必要です。

却下後

references/rejection-playbook.md を参照：正確なガイドラインを読み、再現し、根本原因（多くの場合複数レイヤー）を修正し、Resolution Center で具体的に返信し、再提出。異議申し立ては、レビュアーが証明可能な事実を誤解した場合のみ。

人間の承認が必要な判断ポイント

提出、リリース方法の選択、却下への返信（トーンとコミットメント）、異議申し立ての提出、審査アカウントへのプレミアム付与。

検証

Go/No-Go レポートが証拠とともに完全であり、機能を構築していない人がクリーン端末で審査ノートを実行し成功すること。

よくある落とし穴

• デモアカウントがレビュアーの読めないメールコードに依存している。
• デモアカウントが空、凍結、またはクリーンアップジョブで削除されている。
• 商品が「Missing Metadata」（審査用スクリーンショットなし）の状態で、審査中にロードされない。
• バージョンを審査から取り下げる（「Developer Rejected」）と、サブスクリプションもドラフトから削除される。再提出前にグループと各サブスクリプションを再追加しないと、バージョン単独で提出される。
• プロダクトページアセットはバージョンが「Waiting for Review」の間ロックされる（例：新しい Header アセット）。提出前にすべて追加する。そうしないと、バージョンを審査から取り下げ、編集し、再提出する必要があり（キュー内の位置を失う）。
• Apple の「Add for Review」チェックが通っても、オプションアセットが設定されているとは限らない：空の Header アセットが許可されるため、提出前にその点を判断すること。
• レビュアーの新しい Apple アカウントがリストア/移行ルールと衝突し、購入が「失敗」する。
• バックエンドが非アクティブ後に一時停止するプラン、またはレビュアーをレート制限するプラン。
• ビルド内に「Coming soon」が存在する。
• アプリ内テキストが他ストアに言及している。
• 審査ノートがデモログインの説明のみ（録画、目的、サービス、地域の説明がない）。