1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

# 個人開発者がアプリ審査で落ちる6つの地雷と、設計段階で潰す方法【2026年版・条番号付き】

1
Posted at

審査リジェクトの多くは提出時のミスではなく、設計段階の決定で運命が決まっています。本記事では個人開発で特に踏みやすい6テーマを、ガイドライン条番号付きで整理します(ガイドライン確認日: 2026-07-16)。

1. UGC(ユーザー投稿) — 通報・ブロックは「あとで」が効かない

投稿・コメント・チャットなど、ユーザーの作った内容が他人に見える機能があるなら:

  • 通報機能・ユーザーブロック機能が必須(Apple 1.2 / Play UGCポリシー)
  • 不適切コンテンツのフィルタと、通報への迅速な対応体制(24時間以内の対応が期待される)
  • Google Playは2026年4月改定で「投稿前の利用規約同意」も明文化
  • 匿名・ランダムチャットもUGC扱い(Apple 2026年2月改定で明確化)

UI・DB設計に食い込む要件なので、後付けは実質的な作り直しになります。

2. 課金 — リストア忘れは定番の初回リジェクト

  • デジタルコンテンツはストア内課金(IAP / Play Billing)経由が基本(Apple 3.1.1)
  • サブスクは購入前に価格・期間・自動更新条件の明示が必要(Apple 3.1.2)
  • 購入の復元(リストア)機能を忘れずに。機種変更で課金が消える設計はリジェクト対象

外部決済は流動的です: Apple日本はスマホ新法(2025年12月施行)で可能になったものの実質手数料~26%でメリット薄。Google Playは米英欧で2026年6月30日解禁、日本は2026年12月31日予定。「原則NGだが変わりつつある」が2026年7月時点の正確な状況です。

3. アカウント — 「Sign in with Apple必須」は古い情報

  • 他社ログイン(Google等)を置く場合、2024年改定後の正確な要件は「プライバシー保護型ログインの併設」(Apple 4.8)。Sign in with Appleはその最有力候補であって唯一の選択肢ではない
  • アカウント作成があるならアプリ内からの削除機能が必須(Apple 5.1.1(v) / 両ストア共通)
  • Googleはさらに厳しく、Web上の削除手段も必要(アンインストール後でも削除できるように)

4. プライバシー — SDKの収集分も「あなたの申告義務」

  • AdMobやFirebaseが収集するデータも、App Privacy(Apple)/データセーフティ(Google)への申告対象
  • IDFAを使うならATT許可ダイアログ必須(Apple 5.1.2)
  • 収集ゼロでもプライバシーポリシーURLと質問票は必須
  • 申告・ポリシー・実態の三者が食い違うと削除リスク

5. 最小機能 — 「サイトをアプリ化」は構成ごとアウト

Webビュー表示だけのアプリはApple 4.2(Minimum Functionality)でリジェクト対象。審査では機内モードにされ、白画面が出たら即アウトです。プッシュ通知・オフライン対応・ネイティブなナビゲーションが最低ライン。Google Playも2026年更新で同種のアプリを「低価値」として拒否する方針を強化しています。

そもそもストア配布が目的でないなら、PWAなら審査不要・手数料ゼロという選択肢もあります。

6. 対象年齢 — 13歳未満向けは個人開発の難所

  • 使える広告SDKが制限される(Google: ファミリー自己認証済みSDKのみ / Apple Kidsカテゴリ: 第三者広告・分析が原則禁止)
  • 外部リンク・課金には保護者ゲート必須(Apple 1.3)
  • COPPA等の法規制対応も乗る。設計段階で対象年齢を13歳以上に引き上げるのも合理的な判断

番外: そもそも公開まで辿り着けない — Google Playの「12人×14日」ルール

個人開発者にとって最大の関門は、審査以前にあります。2023年11月13日以降に作成した個人デベロッパーアカウントは、製品版公開の前に:

  • 12人以上のテスターが(20人から2024年12月に緩和)
  • 14日間継続してクローズドテストにオプトインした状態を維持

しないと製品版へのアクセス申請すらできません。しかも人数が揃えばOKではなく、テスターが実際にアプリを開いて使っているか(エンゲージメント)も見られます。エミュレータや捨てアカウントはカウントされません。

つまり個人開発者は「アプリを作る」前に「テスターを12人集める算段」から設計する必要があります。友人・家族で足りなければ、テスター相互支援コミュニティ等を使うのが現実解です。組織アカウントには適用されないため、法人化している場合は無関係です(Google公式: 新しい個人デベロッパーアカウントのテスト要件)。

この要件は日本語の一次情報が少なく、知らずにリリース直前で詰む人が後を絶ちません。

これを自動でチェックするツールを作りました

上記6テーマ+対象ストア(12人×14日ルール含む)を質問形式で診断し、該当する要件だけを条番号・原文リンク・対処法付きの「カルテ」として出力するWebツールを公開しました。出す予定のないストアの要件は表示されません。無料・登録不要・データは端末内のみです。

👉 アプリ審査リスク診断

判定の誤りを見つけたらぜひコメントで教えてください。審査情報は正確性が命なので、指摘が一番の貢献です。


本記事はガイドラインの公開情報に基づく参考情報です。提出前に必ず各ストアの最新原文をご確認ください。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?