App Store・Google Play のリジェクト対応: 最初に見ること
アプリが審査で却下された時の原因整理と再提出の進め方です。
リジェクトされたら、理由を読まずに再提出しないでください。原因を再現し、メタデータ、デモアカウント、決済、プライバシー、ログイン、クラッシュ、制限コンテンツ、審査メモを確認します。多くは小さな修正と明確な説明で改善できます。
実用的な質問でアプリ見積もり依頼を準備する
アカウント、カート、決済、管理画面、連携、データ保存、公開支援など必要な機能を選びます。
重要ポイント
- 原因を再現するまで再提出しません。
- デモアクセス、サーバー、審査メモを先に確認します。
- メタデータとプライバシーは実際のビルドと一致させます。
- 再提出メモで修正内容を明確に伝えます。
Decision framework
リジェクトは嫌ですが、有益なフィードバックでもあります。ランダムに画面を直して再提出しないでください。ストアのメッセージを不具合報告として扱い、該当ルール、審査者の操作、証拠、修正場所を整理します。
まずアクセスを確認します。審査者がログインできない、有料機能を試せない、QR フローを見られない、サーバーが止まっている、という理由はよくあります。デモアカウントとサンプルデータを用意します。
What to include
| 領域 | 決めること | 作業量が変わる理由 |
|---|---|---|
| 製品の約束 | 確実に動くべきユーザー操作 | 副次的な機能を作りすぎないため |
| データ | 保存、表示、変更、送信する内容 | サーバー側、管理画面、テスト範囲を決める |
| 例外ケース | 決済失敗、弱い通信、審査却下、未対応言語 | 公開時の想定外を減らす |
| 運用 | 誰が確認し、直し、支援するか | 公開後の手作業サポートを減らす |
次にメタデータです。スクリーンショット、説明、年齢区分、プライバシー、サポートURL、機能説明が実際のアプリと一致している必要があります。
決済とプライバシーは慎重に見ます。デジタル商品はストア課金ルールに関わることが多く、物理商品やサービスは説明が必要です。
再提出前に、何を直したか、どこで試せるか、どのアカウントを使うかを短く書きます。
Appfyl での使い方
Appfyl usually plans this kind of work through the main user flow, team operations in the admin panel, analytics, testing and release risk. We do not treat a complex feature as a checkbox until it is clear where it saves money, reduces support or helps the user complete an important action.
詳しくは Appfyl の事例.
Appfyl が作る範囲を公開済みプロダクトに変える流れを見る。 Appfyl の事例を見る.
アプリのアイデアがあり、次の一手を整理したいですか？
アイデアを相談する関連する Appfyl ガイド
- Mobile app launch checklist
- Mobile app QA before launch
- ASO before mobile app launch
- Payments and subscriptions cost
- Mobile app security checklist
Appfyl が作る範囲を公開済みプロダクトに変える流れを見る。 Appfyl の事例を見る.
役立つリンク
次のステップ
If this topic affects your product, mark the relevant features in the Appfyl の機能ブリーフ. It helps us separate the first version from later improvements.
この要点を使って現実的な初期版を設計しましょう。
MVPを見積もる調査をローンチ計画へ
Appfyl はアイデアを、アプリの計画、最初に作る機能リスト、初回の作業計画に整理します。
アプリの計画を相談役立つリンク
よくある質問
明らかな問題は先に直します。アプリが規則に合っていて誤解に見える場合は異議申し立てを検討します。
必ずではありません。メタデータ、審査メモ、デモ認証情報で済む場合もあります。クラッシュ、決済、プライバシーは修正が必要なことが多いです。
原因が明確で、審査対応と新機能開発を分ければ可能なことが多いです。