App Store の審査でアプリが差し戻される八つの理由

短い答え：App Store と Google Play でのアプリのリジェクトの大半は、コードのバグが原因ではありません。原因は、開発者ではなく事業オーナーが管理している事務的な項目です。審査担当者がログインできるデモアカウント、完全なプライバシーポリシー、実態と一致するデータ申告、会社名義の開発者アカウント、そしてすでに過ぎてしまった技術的な期限。これらはどれも、コードを一行も書かずにローンチの二週間前に準備できます。

スケジュールへの影響は見た目以上に大きいものです。リジェクトはアプリの出来が悪いという意味ではなく、修正のたびにアプリが審査待ちの列の最後尾に戻るという意味です。そのため、季節やイベントに合わせたローンチキャンペーンが、終わりの見えない遅延に変わってしまいます。だからこそ公開用資料は、最終日に回す事務作業ではなく、プロジェクトの一部として扱うべきなのです。

1 — 審査担当者がアプリを開くためのデモアカウントがない

ログイン画面から始まるアプリで最も多い理由です。審査担当者はあなたの顧客ではなく、あなたのシステムに登録された電話番号も持っていないため、すぐに使えるログイン情報がなければ最初の画面で止まってしまいます。Apple のアプリの完全性に関するルール（App Completeness、2.1）は明確です。最終版を提出すること、アプリにログイン機能がある場合はデモアカウントの情報を含めること、そしてバックエンドサービスを稼働させておくこと。法的またはセキュリティ上の義務により実際のアカウントを提供できない場合は、Apple の事前承認を得たうえで、アプリの全機能を示す組み込みのデモモードを用意することができます。

実務的には、有効期限が切れず、データのクリーンアップでも削除されない常設アカウントを用意し、ステージングサーバーが営業時間中だけでなく審査期間中ずっと稼働しているようにしてください。

2 — ストアがアプリを「パッケージし直しただけのウェブサイト」と見なす

最低限の機能に関するルール（Minimum Functionality、4.2）は、アプリにはパッケージし直しただけのウェブサイト以上の価値をもたらす機能、コンテンツ、UI が必要であり、主にマーケティング資料、ウェブの切り抜き、コンテンツのアグリゲーター、リンク集であるアプリは受け付けられないと定めています。多くの企業は競合が持っているからという理由でアプリを求め、その結果、製品はウェブサイトを殻で包んだだけのコピーとして出来上がります。

解決策は二つあります。ブラウザでは提供できない本当の価値をアプリに持たせるか（オフライン利用、注文状況に応じた通知、バーコードスキャン、端末内に保存されるデータ、決済や地図との連携）、あるいはストアを通さずにプログレッシブウェブアプリとして公開するかです。この選択についてはプログレッシブウェブアプリかネイティブアプリかで解説しました。

3 — プライバシーポリシーが不完全、またはアプリ内にない

Apple のデータ収集に関するルール（Data Collection、5.1.1）は、App Store Connect のメタデータとアプリ内のアクセスしやすい場所の両方に、プライバシーポリシーへのリンクを置くことを求めています。ポリシーには、どのデータを、どのように収集し、それぞれどのように利用するのかを明記し、データを共有するあらゆる第三者（分析ツール、広告ネットワーク、サードパーティ SDK）が同等の保護を提供していることを確認し、保存と削除の方針、そしてユーザーが同意を撤回する方法を説明しなければなりません。

これは他のサイトからコピーしてくるページではありません。あなたのシステムが実際に何をしているかを記述したものであり、私たちのPDPL 実践ガイドで説明しているとおり、サウジアラビアの個人データ保護法（PDPL）に基づく義務と整合している必要があります。

4 — アプリ内でアカウントを削除できない

ルール 5.1.1 (v) は明確です。アプリがアカウント作成に対応しているなら、アプリ内でのアカウント削除も提供しなければなりません。さらに、多くのチームが見落としている規定も加えています。アプリにアカウントに基づく重要な機能がないのであれば、ログインなしで使えるようにし、コア機能に直接関係するか法律で求められる場合を除いて、個人情報を要求してはならない、というものです。

ここでいうアカウント削除は、画面上のボタン一つではなく、バックエンド全体にわたる処理の流れです。法律上削除できない顧客の注文、請求書、会計記録はどうなるのでしょうか。一般的な答えは、開発が始まった後ではなく始まる前に、本人識別データと財務記録を分離しておくことです。

5 — Google Play のデータセーフティ申告がアプリの実際の動作と一致しない

Google はすべての開発者に対し、アプリが収集して端末外に送信するデータを申告するよう求めています。これにはサードパーティのライブラリや SDK が収集するデータも含まれます。さらに、収集が必須か任意か、目的、送信時にデータが暗号化されているか、削除リクエストの仕組みがあるかも申告対象です。ポリシーでは、申告の正確性について責任を負うのは開発者のみであり、違反があればアップデートのブロックや Google Play からの削除につながると定めています。

よくある間違いは単純です。開発者が自分の作業を楽にするために分析ツールやクラッシュレポートツールを追加し、誰もそれを申告に載せていなかった、というものです。提出前にチームへ一つだけ質問してください。このアプリに含まれるサードパーティパッケージの完全なリストは何か、そしてそれぞれが何を送信しているのか、と。

6 — アプリが古い Android バージョンをターゲットにしているためアップデートが却下される

2026 年 8 月 31 日以降、Google Play は新規アプリとアプリのアップデートに対し、Android 16（API レベル 36）以上をターゲットにすることを求めています。例外として、Wear OS と Android Automotive はレベル 35、Android TV と Android XR はレベル 34 です。延長を申請した開発者は 2026 年 11 月 1 日まで猶予があります。

事業オーナーにとっての運用上の影響はこうです。公開済みのアプリはストアに残りますが、要求されたレベルで再ビルドされるまで、アップデートを一切配信できません。緊急のセキュリティ修正や価格変更でさえもです。一年間更新されていないアプリは、緊急リリースが必要になる前に、この点を確認しておくべきです。

7 — 新規アカウントは公開前に 12 人のテスターと 14 日間が必要

2023 年 11 月 13 日以降に Google Play で作成された個人の開発者アカウントは、すぐには一般公開できません。製品版へのアクセスを申請する前に、少なくとも 12 人のテスターが 14 日以上継続して参加するクローズドテストが必要です。スケジュールにさらに二週間が加わり、本物の Google アカウントを持つ本物の人が 12 人必要になるということです。

一方、組織として Apple Developer Program に登録するには、D-U-N-S 番号と契約を締結できる法人が必要で、登録は組織の正式な法人名で行います。屋号や支店名では登録できません。番号の取得と審査の通過には数日かかります。ローンチの週ではなく、プロジェクトの最初の週に着手してください。

8 — ストアのメタデータ、スクリーンショット、支店ごとの別アプリ

三つの小さなルールがリリース全体を沈めます。スクリーンショットはタイトル画像、ログインページ、スプラッシュ画面ではなく、使用中のアプリを示さなければならないこと（2.3.3）。アプリ名は 30 文字までに制限され、メタデータに商標用語、人気アプリの名前、価格を詰め込んではならないこと（2.3.7）。そして同じアプリについて複数の bundle ID を作成してはならないこと（4.3a）。これはまさに、企業が支店ごとや都市ごとに別アプリを求めたときに起こることです。正しいパターンは、ユーザーが支店を選択できる一つのアプリです。

この関門をプロジェクト計画にどう組み込むか

  • 開発者アカウントは自社名義で登録する。開発者や代理店の名義ではありません。ソフトウェアの権利は誰のものかで解説したとおり、ドメインと同じく会社の資産です。
  • アカウントは最初の週に開設する。Apple は年間 99 ドル、Google Play は一回限りの 25 ドルで、時間がかかるのは支払いではなく審査・認証です。
  • 契約書に条項を入れる。誰がビルドを提出し審査のコメントに対応するのか、そして料金に何回分の審査サイクルが含まれるのかを明記します。
  • 公開用資料を独立した成果物として扱う。プライバシーポリシー、データ申告、スクリーンショット、説明文、デモアカウント、そしてサードパーティパッケージのリストです。
コードはローンチの一週間前に完成する。公開用資料には二週間かかる。この順序を取り違えることが、遅れたローンチの大半の原因です。

出典