個人開発アプリの審査リジェクト対策｜2026年の落とし穴

「個人開発のアプリが審査でリジェクトされたけど、何をどう直せばいいの？」
「申請する前にリジェクト対策をひととおり済ませておきたい！」

個人開発でアプリを作ったあと、最後に立ちはだかるのがストアの審査です。
手元では問題なく動いているのに落ちる、という状況ほど手の打ちようがなくて困りますよね。

先に結論をお伝えすると、審査で見られているのはコードの品質ではなくガイドラインとの適合でした。
この記事では両ストアのリジェクト理由を条番号つきで整理し、設計段階から潰す手順までまとめています。

個人開発アプリの審査でリジェクトが起こる仕組み

個人開発アプリが審査で落ちるとき、原因がコードそのものにあることはあまりありません。
まずは審査という仕組みの成り立ちから整理していきましょう。

審査は「バグ探し」ではなくガイドラインとの照合

申請したアプリが落ちると、多くの方はまず自分の書いたコードを疑います。
ところが、レビュー担当が見ているのはそこではありません。

App Storeの審査は、提出されたアプリがApp Review Guidelinesという規約に適合しているかを、項目ごとに照合していく作業です。

動作が快適かどうか、コードが読みやすいかどうかは判定軸に入っていません。
だから「手元では完璧に動くのに落ちる」が当たり前のように起きます。

この前提が入れ替わるだけで、対策の立て方は大きく変わります。
テストを厚くするより、要件の抜けを潰すほうが先なんですよね。

私も最初のリリースでは動作確認ばかり厚くやって申請し、機能としては何も壊れていない箇所で落とされました。
公開手段の選び方そのものはAIで作ったアプリの公開方法｜5つの方法を詳しく解説！でも整理しています。

リジェクト通知に書かれた条番号の読み方

リジェクト通知は定型文で届きます。
読み慣れないうちは何を直せと言われているのか判然としませんが、実は3つの層に分かれています。

1層目がGuideline番号（2.1、5.1.1など）、2層目がガイドラインの見出し文、3層目がレビュー担当の書いた個別コメントです。

直すべき中身が書いてあるのは、3層目だけです。
1層目と2層目は、あくまで「どの棚に分類されたか」を示すラベルにすぎません。

個別コメントに「Please provide〜」「We were unable to〜」といった文言があれば、それは実装ではなく情報の問題です。
この場合、直すべきなのはコードではなく提出物のほうでした。

逆に「Your app crashed on〜」のように動作の記述が入っていれば、再現条件を特定する作業から始まります。

App StoreとGoogle Playで審査の性格が違う

同じ「審査」という言葉でも、AppleとGoogleでは中身がまるで違います。
ここを混ぜて考えると、対策の順番を間違えてしまうんですよね。

Appleは人が触るぶん、説明で解決できる余地が残されています。
一方のGoogleは機械判定の比重が高く、そもそも人と会話する前提になっていません。

この違いがあるので、両ストアへの同時申請は個人開発では避けたほうが安全です。
原因の切り分けが二重になり、どちらの修正が効いたのか判断できなくなります。

まずは片方を通し、その修正内容をもう片方に反映してから出す。
遠回りに見えて、結果的にはこちらのほうが早く公開までたどり着けます。

個人開発アプリの審査が2026年に厳しくなった理由

ここ1〜2年、個人開発アプリが審査を通りにくくなったという声が目立って増えました。
背景には申請数の急増と、それに合わせたガイドラインの改定があります。

年間55万件超の申請とAI製アプリの氾濫

まず、母数そのものが膨らんでいます。
Forbesの報道によれば、2025年にApp Storeへ提出された新規アプリは約55万7,000件でした。

これは2024年比で24%増、2016年以降で最多の水準です。
生成AIでアプリを組み立てられるようになった影響が、そのまま数字に出ています。

問題は、増えた分の多くが実際には使われていないことでした。
同記事では、収益の大半がごく一部のアプリに集中している実態も指摘されています。

Apple側は90%を48時間以内に処理していると説明していますが、開発者からは2週間以上待たされたという報告も出ています。

個人開発では、この待ち時間そのものがコストになります。
だからこそ、一発で通す準備の価値が以前より上がりました。

ガイドライン4.3(b)の改定で「ありふれたアプリ」が落ちる

2026年6月、AppleはApp Review Guidelinesを改定しました（9to5Macによる報道）。
個人開発に効いてくるのは、スパムを扱う4.3の条文です。

改定後の4.3(b)には「すでに広く出回っているものと区別がつかないアプリを提出しないこと」という趣旨の文言が加わりました。

そのうえで、デーティング・懐中電灯・効果音・壁紙・単純なタイマー・占いといったカテゴリが名指しされています。
これらは「意味のある改善がない限り受け付けない」という扱いです。

条文には「平凡で、品質が低く、労力がかかっておらず、App Storeに価値を加えないもの」という強い表現も入りました。
判断の余地が広い分、レビュー担当の裁量で弾ける範囲が広がっています。

対策としては、企画段階で「このアプリは既存の何と違うのか」を一文で言えるようにしておくことです。
説明できないなら、審査より先に企画のほうを見直したほうが早いです。

AIで作ったアプリが引っかかりやすい3つの理由

ここからが、他ではあまり書かれていない話です。
AI支援で開発したアプリには、審査で落ちやすくなる構造的な理由があります。

1つめは、AIが実装するのは機能要件だけという点です。
「投稿機能を作って」と頼めば投稿機能は出てきますが、通報・ブロック・アカウント削除は指示しない限り出てきません。

これらは機能としては誰も欲しがらないのに、規約上は必須という性質のものです。
AIは「ユーザーが欲しい機能」の平均像を出すので、この穴を自発的には埋めてくれません。

2つめは、学習データの平均に寄ることです。
指示が曖昧なほど「よくある実装」が出てくるので、結果として既存アプリに似た構成になり、先ほどの4.3に近づきます。

3つめが、生成時の残りかすでした。
プレースホルダーのテキスト、英語のままの権限説明、テスト用の広告ユニット。こうしたものが混ざったまま提出され、2.1や5.1.1で止められます。

生成されたコードをそのまま信用しない姿勢が要ります。
この観点はAIコードレビューのやり方とツール比較｜料金・手順も解説とも重なる部分です。

App Storeで個人開発アプリがリジェクトされる5つの理由と対策

App Storeのリジェクトは、条番号で見ると出どころがかなり限られます。
個人開発アプリで実際によく飛んでくる5つを、対策とセットで並べていきます。

【理由1】プライバシー（5.1.1）— 個人情報の取りすぎと申告漏れ

リジェクト理由として最も多いのが、このプライバシー関連です。
やっかいなのは、悪意なく落ちるケースがほとんどという点でした。

5.1.1が求めているのは、収集するデータをコア機能に必要な範囲へ絞ることと、その内容をプライバシーポリシーで開示することの2点です。

ログイン機能を付けた流れで生年月日や性別まで取っていないか、まずそこを確認してください。
アプリの動作に不要なら、項目ごと削るのが一番速い対策です。

SDKが裏で送っているデータも、申告義務は開発者側にあります。
導入したライブラリの公式ドキュメントで、収集項目を1つずつ拾い直す作業は避けて通れません。

ポリシー文書そのものの書き方は個人開発SaaSの利用規約と特定商取引法｜必要項目と書き方に必要項目をまとめてあります。

【理由2】ユーザー投稿コンテンツ（1.2）— 通報とブロックが後回し

ユーザーが何かを投稿できるアプリは、それだけで審査の難易度が一段上がります。
コメント欄やプロフィール画像のアップロードも、当然この対象に入ります。

ガイドライン1.2が要求しているのは、不適切な投稿をフィルタする仕組み、通報の導線、迷惑ユーザーのブロック、そして問い合わせ先の公開です。

ここで多いのが「まずリリースして、通報機能は次のアップデートで入れます」という進め方でした。
これは通りません。投稿機能が実装された時点で、安全機能もセットで求められます。

運用体制まで聞かれることもあります。
個人開発なら「通報がメールで届き、確認後に該当投稿を非表示にする」という流れをレビューノートに書いておけば十分に伝わります。

逆に、投稿機能がどうしても間に合わないなら、初回リリースでは投稿を閉じてしまうのも手です。

【理由3】課金・サブスクリプション（3.1.2）— 表記と購入の復元

課金を入れた初回申請で、ほぼ必ず一度は引っかかるのがこの3.1.2です。
実装の難しさではなく、単純な入れ忘れで落ちます。

最頻出は購入の復元（リストア）ボタンの欠落でした。
機種変更したユーザーが購入済みの権利を取り戻す導線は、規約上の必須要件です。

次に多いのが、サブスクリプションの表示不足です。
価格・期間・自動更新される旨・解約方法を、購入画面とストア説明文の両方に書く必要があります。

アイテムの提出漏れは見落としがちです。
App Store Connect上で課金アイテムが「送信準備完了」になっていないと、レビュー担当の画面では購入ボタンを押しても何も起きません。

結果として、実装の問題ではなく2.1の「機能を確認できなかった」で落ちます。

【理由4】アプリの完成度（2.1）— クラッシュとデモアカウント

2.1は範囲が広く、通知だけでは原因を絞りにくい条番号です。
ただ個人開発で当たるのは、だいたい2種類に分かれます。

1つはクラッシュです。
正常系のテストは通っているのに、ネットワークを切った状態やデータが空の状態でnilを踏む、という異常系の抜けがよく指摘されます。

レビュー担当は開発者と同じ順番でアプリを触りません。
いきなり深い階層へ飛んだり、入力せずに次へ進んだりするので、想定外の経路が普通に踏まれます。

もう1つが情報不足でした。
位置情報や外部連携のように、レビュー環境では再現しづらい機能を持つアプリは、動画を用意しておくと往復が一気に減ります。

動画は限定公開のURLで渡せば問題ありません。

【理由5】メタデータ（2.3・5.2.5）— スクリーンショット・説明文・商標

コードを1行も触らずに落ちるのが、このメタデータ系です。
提出物の側だけで完結するので、直すのは早いです。

2.3が求めているのは、スクリーンショット・説明文・プレビュー動画が実際のアプリと一致していることでした。
開発途中のUIで撮ったまま差し替え忘れる、というのが定番です。

iPad用のスクリーンショットを実機で撮り直さずに引き伸ばして提出し、指摘されるケースもよく見かけます。

商標については5.2.5が根拠になります。
「スマホで使える」のように一般名詞へ置き換えれば、それだけで解決します。

細かい話に見えますが、ここで1往復すると数日単位で公開が遅れました。
提出前に説明文とスクショを声に出して読み直す時間は、確実に元が取れます。

Google Playで個人開発アプリが落ちる3つの要因と対策

Google Play側は、Appleとは落ち方がまったく違います。
とくに個人のデベロッパーアカウントには、公開そのものを止める独自の要件があります。

12人×14日間のクローズドテスト要件

これは審査というより、審査を受ける資格の話です。
知らずに開発を進めると、完成してから2週間以上足止めされます。

Google Play Consoleヘルプによれば、2023年11月13日以降に作成された個人用デベロッパーアカウントは、製品版を公開する前にクローズドテストを実施しなければなりません。

条件は12人以上のテスターが14日以上連続でオプトインしている状態です。
途中で抜けたテスターはカウントされないので、実質的には日数のやり直しになります。

テスターの集め方は、個人開発コミュニティで相互協力を募るのが現実的です。
知人に頼む場合も、14日間アンインストールしないよう最初に伝えておいてください。

逆算すると、開発の終盤ではなく中盤でテスト用のビルドを配り始めるのが正解でした。

データセーフティフォームの申告ズレ

Google Play側でプライバシーに相当するのが、このデータセーフティです。
Appleと違い、公開後の自動スキャンで不一致が見つかって止められることがあります。

申告するのは、収集するデータの種類・用途・第三者共有の有無・暗号化の状況などです。
ここで見落とされるのが、自分で書いたコード以外の部分でした。

広告SDKや解析SDKを入れているなら、それらが集める識別子も申告対象に入ります。
「自分は何も集めていない」という認識のままだと、実物と申告が食い違います。

広告を1つ入れただけでもプライバシーポリシーは必要になります。
無料アプリだから不要、という判断はここでは通用しません。

権限の過剰要求と「低価値アプリ」判定

3つめが、アプリそのものの作りに関わる部分です。
Googleも近年、中身の薄いアプリへの姿勢を明確に厳しくしています。

まず権限です。
開発途中で試して使わなくなった権限がマニフェストに残っていると、それだけで説明を求められます。

とくに位置情報のバックグラウンド取得、連絡先、SMS、ストレージの全体アクセスあたりは、用途の申告と実装の一致を厳しく見られます。

既存のWebサービスをアプリ化する場合は、通知・オフライン閲覧・端末機能の活用のどれかを最低1つ載せてください。
ここが「アプリである理由」の説明になります。

同じ考え方はApp Store側にもあり、こちらはガイドライン4.2の最小機能という条項が受け皿です。
Webビューでサイトを包んだだけの構成は、両ストアとも同じ理由で弾かれると思っておいてください。

個人開発アプリのリジェクトを設計段階で防ぐ3つの手順

ここまでの内容は、実は全部あと出しでも対応できます。
ただ、1往復あたり数日から数週間かかるので、先に潰しておくほうが圧倒的に安上がりです。

【手順1】審査要件を仕様に落としてから作り始める

私がリジェクトを減らすためにやっているのは、機能要件リストの隣に審査要件リストを置くことです。
この2つは、目的も出どころもまったく違います。

機能要件は「ユーザーが使いたいもの」から出てきます。
対して審査要件は「規約が求めるもの」から出てくるので、ユーザーインタビューをいくら重ねても出てきません。

だから最初に、自分のアプリが持つ属性を洗い出します。
投稿機能があるか、課金があるか、アカウント作成があるか、位置情報を使うか。この4つだけでも必要な要件は決まります。

AI支援で開発するなら、このリストをそのままプロンプトに含めてしまうのが効きます。
「投稿機能を作って」ではなく「通報とブロックを含む投稿機能を作って」と書くだけで、抜けはかなり減りました。

指示していないものは出てこない、という前提で頼むのがコツです。

【手順2】申請前チェックリストで抜けを一気に潰す

実装が終わったら、提出ボタンを押す前に一度立ち止まります。
ここで使うチェックリストは、共通項目とストア別項目に分けておくと迷いません。

この表を毎回コピーして、チェックを付けながら進めます。
記憶に頼ると、慣れたころに一番単純な項目を飛ばします。

とくに3行目は、AI支援で書いたコードでは必ず確認してください。
生成の過程で紛れ込んだ仮の値が、そのまま本番ビルドに乗っていることがあります。

【手順3】レビューノートとデモ動画で情報不足を先回りする

提出フォームにあるレビューノートは、個人開発でこそ効く欄です。
ここが空欄だと、レビュー担当は推測でアプリを触ることになります。

書くべきなのは、アプリの説明ではありません。
担当者がつまずきそうな箇所と、その通り方だけを書きます。

たとえば「主要機能は位置情報の取得後に表示されます。シミュレータでは動作しないため、実機での確認をお願いします」といった具合です。

動画はスマホの画面収録で十分でした。
編集も不要で、操作から結果までが一続きで映っていれば伝わります。

そのうえで、リリース日は審査の往復を2回分見込んで置いてください。
初回で通る前提のスケジュールを組むと、告知だけが先に走って苦しくなります。

個人開発アプリがリジェクトされた後の再申請の進め方

準備しても落ちるときは落ちます。
大事なのは、落ちたあとに何往復で抜けられるかのほうです。

リジェクト文を分解して原因を特定する

最初にやるのは、条番号ごとに指摘を切り分ける作業です。
複数の条番号がまとめて届くことも珍しくありません。

そのときは、実装の修正が必要なものと、説明で済むものに仕分けます。
2.1のクラッシュや1.2の機能欠落は前者、メタデータ系や情報不足は後者です。

順番としては、実装の修正から先に片付けます。
ビルドを差し替える必要があるので、説明側の準備と並行して進めるのが効率的でした。

2つめは意外とやります。
バージョン番号とビルド番号のどちらを上げるべきか迷ったら、ビルド番号は必ず上げてください。

3つめを避けるには、通知を読む順番を逆にするのが有効でした。
条番号から入らず、担当者コメントを先に読んでから条文を確認すると、指摘の的が外れにくくなります。

Resolution Centerで返信するか、直して出し直すか

ここが競合記事でもあまり触れられていない部分です。
リジェクトへの対応は「直して再提出」だけではありません。

App StoreにはResolution Centerという窓口があり、レビュー担当と文章でやり取りできます。
実装が規約に沿っているのに誤解で落ちている場合、ここで説明するだけで通ることがあります。

判断の分かれ目は、指摘内容が事実かどうかです。
事実なら直す、事実誤認なら返信する。この線引きだけ持っておけば迷いません。

返信は感情を挟まず、事実と手順だけで構成します。
納得が得られなければApp Reviewボードへの異議申し立て（Appeal）に進めますが、結論が出るまで1週間以上かかることも見込んでおいてください。

落ち続けたときに検討する仕様変更と逃げ道

3回、4回と落ち続けると、判断そのものを見直す局面に入ります。
粘るコストと、方針を変えるコストを並べて比べてください。

一番現実的なのは、引っかかっている機能を初回リリースから外すことです。
公開してユーザーの反応を得るほうが、審査と戦い続けるより得られるものが多い場面はよくあります。

ストアを変えるのも一つの手です。
App Storeで規約に触れる仕様でも、Google Play側では問題なく公開できるケースは実際に存在します。

Webアプリとして先に出し、反応を見てからネイティブ化する道もあります。
審査という関門がない分、検証だけなら圧倒的に速く回せます。

個人開発アプリの審査とリジェクト対策に関するよくある質問

Q：アプリの審査にはどのくらいの日数がかかりますか？

A：App Storeは公式には90%が48時間以内とされていますが、2026年に入ってから数日から2週間程度かかったという報告も出ています。Google Playは初回公開の審査に加えて、個人アカウントならクローズドテストに14日以上が必要です。
リリース日は往復2回分の余裕を見て設定してください。

Q：リジェクトされるとアカウントに不利な記録が残りますか？

A：通常のリジェクトが繰り返されただけで、アカウントに罰則が及ぶことはありません。ただし、規約違反を承知で回避しようとした場合や、審査時と公開後で挙動を変えるような行為はデベロッパープログラムからの除名対象になります。正直に直して出し直すぶんには、回数を気にする必要はないです。

Q：アカウント作成機能があると、追加で何を実装しますか？

A：まず、アプリ内でアカウント削除まで完結できる導線が必須です（5.1.1(v)）。設定画面から数タップで到達できる位置に置いてください。

あわせて確認したいのが4.8のログインサービス条項です。第三者のソーシャルログインだけを提供する場合は、収集を氏名とメールに限定し、メールアドレスを非公開にできる同等の選択肢を併設してください。
Sign in with Appleはこの条件を満たしますが、必ずそれを使えと決まっているわけではありません。

Q：AIで作ったアプリは申請時に申告が必要ですか？

A：開発にAIを使ったこと自体を申告する義務はありません。ただし、アプリがユーザー向けにAI生成コンテンツを提供する場合は、モデレーション機能やデータの取り扱いについて説明を求められます。
第三者のAIサービスへ個人データを渡すなら、その旨をプライバシーポリシーに明記して同意を得る必要があります。

Q：個人開発でも法人アカウントにしたほうがいいですか？

A：Google Playのクローズドテスト要件は法人アカウントには適用されないため、その点だけ見れば有利です。ただし法人アカウントにはD-U-N-S番号の取得が必要で、開設までに時間がかかります。個人開発で始めるなら、テスト要件を織り込んだスケジュールを組むほうが現実的です。

まとめ

個人開発アプリの審査でリジェクトを避ける要点は、審査を品質の試験ではなく要件の照合として捉え直すことでした。
そのうえで、AIに書かせた部分ほど審査要件が抜けやすいという前提を持っておくと事故が減ります。

2026年は申請数の増加とガイドライン4.3(b)の改定で、判定の幅が広がった年でもあります。
「既存の何と違うのか」を一文で言えるかどうかが、以前より重く効いてくるようになりました。

個人開発の全体像は個人開発によるAI搭載SaaSの始め方｜アイデアから法人化まで総まとめにまとめてあります。

審査は理不尽に見えて、実のところ読める仕組みです。
今つくっているアプリは、どの属性の審査要件を背負っているでしょうか。

手を動かしながら足りない知識を埋めたい場合、月額で使える学習サービスを併走させる手もあります。スタアカの評判は本当？月額1,280円で学べる範囲と注意点を確認してみてください。