アプリストア審査で落ちる原因と、リリース前に確認すべき項目

スマホアプリをストアで公開するには、各ストアの審査を通過する必要があります。審査で指摘を受けて差し戻される、いわゆる「リジェクト」は珍しいことではありません。問題は、リジェクトそのものよりも、それによって公開日が遅れ、キャンペーンや店舗のオープン、取引先への約束に間に合わなくなることです。そして、指摘の多くは、設計や準備の段階で予防できる論点に集中しています。

この記事は、初めてアプリを公開する事業者や、開発会社に依頼してアプリを作っている発注担当者に向けて書いています。審査で指摘されやすい論点（課金、ログイン、プライバシー、最低限の機能、審査用の準備）、それぞれの対策、リリース前に確認すべき項目、審査をスケジュールに織り込む方法を順に説明します。

結論から言えば、審査対策で最も大切なのは、「アプリ内で何を売るか」「誰がどうログインするか」「どんな情報を集めるか」の三点を、開発の初期段階で各ストアの規約に照らして確認しておくことです。これらは後から変えると設計の大きな手戻りになるため、公開直前の確認では間に合いません。なお、ストアの規約や審査の運用は随時改定されるため、この記事は考え方の整理として読み、具体的な判断は必ず最新の公式のガイドラインで確認してください。

アプリストア審査とは何を確認しているのか

アプリストア審査 は、ストアを運営する事業者が、公開されるアプリが自社の定める規約に沿っているかを確認する仕組みです。主に次のような観点から確認が行われます。

• 安全性：利用者に害を与える内容や、不適切な情報の扱いがないか
• 性能と完成度：アプリが正常に動作し、未完成の部分がないか
• ビジネス上のルール：課金の方法や広告の扱いが規約に沿っているか
• デザインと機能性：アプリとして十分な機能や価値を提供しているか
• 法令とプライバシー：個人情報の扱いが適切に説明され、同意が取られているか

iOSとAndroidでは、審査の進め方や重視する点に違いがあります。一般に、iOSの審査は人による確認も含めて細かく見られる傾向があり、Androidは自動的な確認が中心で、公開後に問題が見つかって対応を求められることもあります。どちらも規約は改定されるため、両方の最新の情報を確認しておく必要があります。

指摘されやすい論点1：課金と決済

課金に関する論点は、審査で最も指摘を受けやすく、かつ後から直すのが大変な部分です。

アプリ内でデジタルの商品を売る場合

アプリ内で利用できる機能、コンテンツ、サブスクリプションなど、デジタルの商品を販売する場合は、原則として各ストアが提供するアプリ内課金の仕組みを使うことが求められます。外部の決済サービスに誘導して販売すると、規約違反として指摘を受ける可能性があります。この扱いは、地域や法規制の動向によって例外や変更が生じている分野でもあるため、最新の規約を必ず確認してください。

物やサービスの代金を受け取る場合

商品の配送、店舗でのサービス、人が提供するサービスなど、アプリの外で消費されるものの代金であれば、外部の決済サービスを使うことができるのが一般的です。ECアプリや予約アプリなどがこれにあたります。

判断が分かれやすいケース

Webで販売している会員プランをアプリでも使えるようにする場合や、オンラインで提供するレッスンなど、デジタルと実物の境目にあるサービスは、扱いの判断が分かれやすい部分です。設計の初期段階で、どの区分に当たるかを確認し、必要に応じてアプリ内課金を組み込む前提で費用とスケジュールを見込んでおきましょう。決済の導入の考え方は MVPでの決済導入 でも扱っています。

指摘されやすい論点2：ログインとアカウント

ログインとアカウントに関する論点も、指摘を受けやすい部分です。

アカウントの削除

アプリ内でアカウントを作成できる場合、アプリ内からアカウントの削除を行える手段を用意することが求められるのが一般的です。「問い合わせフォームから依頼してください」だけでは不十分と判断される場合があります。退会の処理は、データの削除範囲や、課金中のサブスクリプションの扱いなど、設計で決めることが多いため、早めに仕様を固めておく必要があります。

外部サービスのアカウントでのログイン

SNSなどの外部サービスのアカウントでログインできるようにする場合、ストアによっては、プライバシーに配慮した特定のログイン方法の併用が求められることがあります。要件は改定されることがあるため、採用するログイン方法を決める段階で確認しましょう。ログイン機能の実装全般は 会員ログイン機能の実装 で説明しています。

ログインしないと何もできない設計

アプリを起動するとすぐにログインを求められ、ログインしないと何も見られない設計は、アプリの性質によっては指摘を受けることがあります。会員専用のサービスであればログインが前提で問題ありませんが、一般向けのアプリでは、ログインなしで見られる部分を用意する方が、利用者にとっても親切です。

指摘されやすい論点3：プライバシーと個人情報

個人情報の扱いは、近年特に厳しく確認されるようになっている分野です。

プライバシーポリシー

アプリが個人情報を扱う場合、プライバシーポリシーを用意し、アプリ内とストアの掲載情報の両方から確認できるようにする必要があります。内容は、アプリが実際に集めている情報と一致していなければなりません。プライバシーポリシーの内容は法令に関わるため、専門家の確認を受けることをおすすめします。

データの収集に関する申告

各ストアでは、アプリがどのような情報を集め、何に使い、第三者と共有するかを申告する仕組みがあります。ここで注意が必要なのは、自社のコードだけでなく、組み込んでいる外部の部品（分析ツール、広告、ログイン、通知などのSDK）が集める情報も申告の対象になる点です。開発会社に、組み込んでいる部品とそれぞれが集める情報の一覧を出してもらい、申告内容と一致しているかを確認しましょう。

端末機能の利用許可

カメラ、位置情報、写真、連絡先などを使う場合、利用者に許可を求める画面で、何のために使うのかを分かりやすく説明する必要があります。説明があいまいだったり、実際の利用目的と合っていなかったりすると指摘の対象になります。また、使っていない機能の許可を求めることも避けるべきです。

指摘されやすい論点4：機能と完成度

アプリとしての価値が不十分

Webサイトの画面をそのままアプリの中で表示するだけのアプリは、アプリとしての価値が不十分と判断されることがあります。アプリならではの機能（通知、端末機能の活用、オフラインでの利用など）や、Webとは異なる使い勝手を提供しているかが問われます。アプリにする必要があるかどうかは、そもそもの判断として PWAとネイティブアプリの比較 で整理しておくとよいでしょう。

未完成・不具合

起動時に落ちる、ボタンを押しても反応しない、「準備中」の画面が残っている、仮の文章や画像が表示されている、といった状態は指摘の対象になります。審査は実際にアプリを操作して行われるため、主要な操作の流れがすべて動くことを、公開前に確認しておく必要があります。

広告や外部サイトへの誘導

アプリ内に広告を表示する場合は、広告がアプリの操作を妨げないこと、誤って押してしまうような配置になっていないことが求められます。また、外部のWebサイトへ誘導する場合も、誘導先で課金を促すような作りになっていると、課金の論点と合わせて指摘を受けることがあります。子ども向けのアプリでは、広告や外部サイトへの誘導、情報の収集についてさらに厳しい基準が設けられているのが一般的なので、対象年齢を決める段階で確認しておきましょう。

利用者が投稿できるアプリ

利用者が文章や画像を投稿でき、他の利用者がそれを見られるアプリでは、不適切な投稿を通報する仕組み、利用者をブロックする仕組み、運営者が投稿を削除できる仕組みなど、投稿の管理機能が求められるのが一般的です。これらは管理画面の開発にも関わるため、見積もりの段階で含めておく必要があります。

審査で指摘されやすい論点の整理

ここまでの論点を表にまとめます。

表を見ると、多くの論点が要件定義の段階で決めるべきものであることが分かります。審査対策は、公開直前の作業ではなく、設計の一部として扱うことが大切です。

リリース前に確認すべき項目と申請の準備

審査の申請前に、次の手順で準備と確認を進めます。

1. ストアのアカウントを自社の名義で用意する：開発会社の名義ではなく、自社の名義で開発者アカウントを取得します。法人として登録する場合は、必要な手続きに時間がかかることがあるため、早めに着手します。
2. 主要な操作の流れを実機で確認する：会員登録、ログイン、主要な機能、課金、退会までの一連の流れを、実際の端末で確認します。
3. 審査用のアカウントを用意する：ログインが必要なアプリでは、審査担当者が使えるテスト用のアカウントと、必要な説明を用意します。特定の条件でしか使えない機能がある場合は、確認の方法を説明に書きます。
4. 掲載情報をそろえる：アプリの説明文、画面写真、アイコン、サポート用の連絡先、プライバシーポリシーのURLを用意し、実際のアプリと一致しているか確認します。
5. データ収集の申告を確認する：組み込んでいる部品も含めて、集めている情報の申告内容を確認します。
6. 年齢区分などの設定を確認する：アプリの内容に応じた年齢区分の設定や、対象地域の設定を確認します。
7. 審査への補足説明を書く：業務用で一般には使えない、特定の機器が必要、といった事情がある場合は、審査担当者向けの補足説明を用意します。

申請直前のチェックリスト

• 会員登録から退会までの流れが、実機で最後まで動くか
• 仮の文章、仮の画像、「準備中」の画面が残っていないか
• 課金の方法が、販売するものの区分に合っているか
• 購入の復元（機種変更時などに購入済みの内容を戻す操作）ができるか
• アプリ内から退会（アカウント削除）ができるか
• プライバシーポリシーがアプリ内とストアの両方から確認できるか
• 外部の部品を含めたデータ収集の申告が実態と一致しているか
• 端末機能の許可を求める画面に、利用目的が具体的に書かれているか
• 審査用のテストアカウントと確認方法の説明を用意したか
• 画面写真と説明文が、実際のアプリの内容と一致しているか
• サポート用の連絡先が有効で、問い合わせに対応できるか

リリース前の確認全般については MVPリリース前チェックリスト も参考になります。

審査をスケジュールに織り込む方法

審査にかかる期間は、ストアやその時期の混雑、アプリの内容によって変わり、事前に正確に読むことはできません。そのため、スケジュールには次のように余裕を持たせておくことが大切です。

• 初回の申請は、公開希望日から十分に前倒しする：指摘を受けて修正・再申請することを前提に、少なくとも一回分の差し戻しに対応できる期間を確保します。
• 公開日を外部に約束する場合は、審査通過後に公開できる設定を使う：審査を通過してから、任意のタイミングで公開できる設定を使えば、公開日を固定しやすくなります。
• 大きな変更を含む更新は、早めに申請する：課金やログインの方法を変える更新は、新規の申請と同じように慎重に確認されることがあります。
• 審査の結果を受けて判断する担当者を決めておく：指摘を受けたときに、修正するのか、審査側に説明するのかを素早く判断できる体制を整えます。

開発会社に依頼している場合は、申請作業と指摘への対応が見積もりに含まれているか、再申請が何回まで含まれるのかも確認しておきましょう。指摘への対応が別料金になる契約だと、差し戻しのたびに追加の調整が必要になり、対応が遅れる原因になります。また、審査の結果はストアのアカウントの持ち主に通知されるため、自社の名義でアカウントを持つ場合は、通知を受け取る担当者と開発会社への連絡の流れを決めておくことも大切です。

具体例：フィットネス教室のレッスン予約アプリ

架空の一般例として、店舗型のフィットネス教室が、レッスンの予約とオンラインレッスンの視聴ができるアプリを作るケースを考えます。

当初の計画では、店舗のレッスン予約と、月額のオンラインレッスン視聴プランを、どちらもWebと同じ外部の決済サービスで支払えるようにする予定でした。しかし要件定義の段階で、オンラインレッスンの視聴はアプリ内で消費されるデジタルのサービスにあたる可能性が高いと分かりました。

そこで、店舗のレッスン予約は外部決済のまま、オンラインレッスンの視聴プランはアプリ内課金でも購入できるように設計を変更しました。Webで購入した会員は、アプリでログインすれば同じプランを使えるようにし、両方の購入経路を管理画面で一元的に確認できるようにしています。

あわせて、アプリ内からの退会機能、位置情報の利用目的の説明（近くの店舗を表示するため）、審査用のテストアカウントとオンラインレッスンの確認方法の説明を用意しました。設計の段階で論点を洗い出したことで、公開直前の大きな手戻りを避けられました。

よくある失敗とその避け方

失敗1：課金の方法を公開直前に確認する 課金の方法が規約に合わないと分かったときには、決済まわりの設計を作り直す必要があります。企画・要件定義の段階で確認しましょう。

失敗2：外部の部品が集める情報を把握していない 分析ツールや広告の部品が集めている情報を把握せずに申告し、指摘を受けるケースです。開発会社に部品の一覧と収集する情報を出してもらいましょう。

失敗3：審査用のアカウントや説明が不十分 ログインできない、機能を確認する方法が分からない、という理由で差し戻されるのはもったいない失敗です。審査担当者が迷わず確認できる準備をしましょう。

失敗4：公開日を審査前に外部に告知する 審査の期間は読めないため、公開日を先に告知すると、指摘を受けたときに予定を守れなくなります。審査通過後に公開日を確定するか、十分な余裕を持たせましょう。

よくある質問

Q. リジェクトされたら、どう対応すればよいですか？

まず指摘の内容を正確に読み、どの規約に関する指摘なのかを確認します。修正が必要なら修正して再申請し、誤解に基づく指摘であれば、審査側に説明して再確認を求めることもできます。指摘の内容があいまいな場合は、問い合わせて具体的な点を確認しましょう。

Q. 一度通過すれば、更新のときは審査されませんか？

更新のたびに審査が行われます。小さな修正であれば通過しやすいものの、規約の改定によって、以前は問題なかった点が指摘されることもあります。継続的に規約の変化を確認する必要があります。継続的な対応は スマホアプリの保守 で扱っています。

Q. 社内だけで使う業務アプリでも、ストアの審査は必要ですか？

一般のストアで公開する場合は審査が必要です。社内や特定の取引先だけで使うアプリには、一般公開しない配布の仕組みもありますが、条件や手続きはストアごとに異なります。配布の方法は、利用者の範囲と端末の管理方法をもとに検討してください。

Otsumuに相談できること

機能が単純で、課金もログインもなく、個人情報もほとんど扱わないアプリであれば、この記事の確認項目と公式のガイドラインを照らし合わせるだけで、多くの論点は社内で対応できます。開発会社にアプリ公開の経験が十分あれば、申請作業を任せることもできるでしょう。

一方で、デジタルの商品を販売する、Webとアプリで会員や課金を共通にしたい、利用者が投稿できる、個人情報を多く扱う、といったアプリでは、要件定義の段階から審査の論点を設計に織り込む必要があります。公開日が事業上の重要な予定に結びついている場合も、早めの検討が欠かせません。

Otsumuでは、事業の目的と収益の仕組みを伺ったうえで、審査の論点を踏まえた機能の設計、開発、申請の準備、公開後の更新まで一貫して支援しています。アプリ開発については スマホアプリ開発 のページをご覧ください。

公開を控えていて不安な点がある、という段階でも構いません。30分の無料相談 で状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01