スマホアプリを配信する場合に確認すべきストア審査の基本

冒頭段落の末尾（審査リジェクトリスクに触れている箇所の直後）にリンクを挿入します。

-- 個人や複業で開発したアイデアを、いよいよスマートフォンアプリとして配信する。そのとき最後に立ちはだかる壁が「ストア審査」です。Webサービスであれば公開して終わりですが、スマホアプリはApp Store（iOS）やGoogle Play（Android）という運営会社の審査を通過しなければ、そもそもユーザーの手元に届きません。個人開発者の間では「審査でリジェクト（却下）された」「原因が分からず何度も再提出した」という声がよく聞かれ、公開スケジュールが大きくずれ込む原因のひとつになっています。なお、AIを活用して非エンジニアが自分でアプリを形にするケース自体が増えていますが、その場合も最終的にはこうしたストア審査を突破できるかどうかが本番化の分かれ目になる。非エンジニアが自分でアプリを作る現実的な限界では、その線引きについて詳しく解説されている。この記事では、アプリストア審査の基本的な仕組みと、個人・複業でアプリを配信する場合に特に見落とされやすいポイントを、実務目線で整理します。

この記事で分かること

• App Store・Google Playの審査は「機能が動くか」だけでなく、個人情報の扱いやコンテンツの内容、収益化の方式まで幅広く見られること
• 個人開発者がリジェクトされやすい典型パターンと、その回避策
• 審査に落ちたときの正しい対処フロー、および審査以外に配信前に準備すべき法務文書との関係

結論を先に3点に整理すると、次のようになります。

• 審査は「一発通過」を前提に作らない。個人開発の多くは1回以上のリジェクトを経験するのが実情に近く、審査期間込みでスケジュールを組んでおくことをおすすめします。
• リジェクトの多くは技術的な不具合ではなく、規約の読み込み不足や記載内容の整合性不足が原因です。プライバシーポリシーの内容とアプリの実際の動作が一致しているか、という基本的な整合性チェックが特に重要です。
• 審査基準は不定期に更新されるため、「昔ネットで見た情報」を鵜呑みにせず、提出直前に各ストアの最新のガイドラインを確認することをおすすめします。

そもそもストア審査とは何を審査しているのか

App Store・Google Playともに、アプリを公開する前に運営会社（Apple・Google）による審査を通過する必要があります。この審査で確認される観点は、大きく分けて次のようなものです。

1. 技術的な安定性：クラッシュしないか、主要機能が説明通りに動作するか
2. コンテンツの適切性：暴力的・性的な表現、著作権侵害、誤解を招く表示がないか
3. 個人情報・データの取扱い：どの情報を取得し、何に使い、誰と共有するのかが明示されているか
4. 収益化の方式：アプリ内課金・サブスクリプション・広告の実装がストアのルールに沿っているか
5. ビジネスモデルの妥当性：実質的な機能を持たない「作っただけ」のアプリ、既存アプリの焼き直しとみなされるものは却下される傾向があります

個人開発者が誤解しやすいのは、審査を「バグチェック」だと捉えてしまう点です。実際には、アプリの説明文・プライバシーポリシーのリンク・アプリ内の実際の挙動・課金導線までを一体として見られており、コードが正しく動いていても、説明や文書との整合性が取れていないだけでリジェクトされることが少なくありません。

言い換えると、ストア審査は「エンジニアのテスト」ではなく「サービス全体の一貫性チェック」に近いものだと捉えておくと、対応の優先順位を付けやすくなります。個人開発では、機能実装に時間をかけた分、説明文や利用規約・プライバシーポリシーといった「文章の整備」が後回しになりがちです。しかし審査担当者から見れば、コードの品質は画面越しには分かりにくい一方、文書と実装の食い違いは比較的発見しやすい部分でもあります。結果として、開発の完成度よりも文書整備の完成度の方が、初回審査の通過率を左右しやすいという逆転現象が起きやすいのが、個人開発特有の落とし穴です。

また、審査担当者は短時間で多数のアプリを確認しているとされ、説明文だけを読んですぐに機能を把握できない場合、実際に操作を試みて挙動を確認します。このとき、ログインが必要なのにテスト用のアカウントが用意されていない、初回起動時の説明（オンボーディング）が分かりにくく操作方法が読み取れない、といった状況が続くと、機能自体に問題がなくても「動作を確認できない」という理由でリジェクトされることがあります。個人開発者は自分がアプリの仕組みを熟知しているため、この「初見のユーザー（審査担当者）にとっての分かりにくさ」に気づきにくい点も、あらかじめ意識しておくとよいでしょう。

App StoreとGoogle Playの審査の違い

両者は似ているようで、実務上の違いがいくつかあります。個人開発者が両OS向けに同時配信を計画している場合は、この違いを踏まえてスケジュールを組むことをおすすめします。

App Store（Apple）の特徴

• 審査は人間のレビュアーが目視で確認する比率が比較的高いとされ、初回提出時のリジェクト率が高い傾向があります
• 「App Review Guidelines」という詳細な規約が公開されており、個人情報・課金・メタデータ（アプリ名やスクリーンショット）まで細かく規定されています
• リジェクトの際、レビュアーとテキストでやり取り（Resolution Center）できる仕組みがあり、疑問点を質問して再提出することが可能です
• 年間の開発者登録料が発生します（個人・法人問わず必要で、毎年の更新が必要です）

Google Play（Android）の特徴

• 審査は自動チェックの比率が比較的高いとされ、初回公開自体は比較的早く通ることが多いとされますが、公開後に規約違反が発覚すると事後的にアプリが停止されるケースもあります
• 「Google Play デベロッパー ポリシー」が規約の基準になり、特にユーザーデータ・機密性の高い権限（位置情報、連絡先など）へのアクセスに関するポリシーが厳格です
• 開発者登録は一度きりの登録料で、App Storeのような年次更新はない運用が一般的です（登録料の有無や金額は変更されることがあるため、登録前に最新の公式情報を確認することをおすすめします）

どちらも、審査基準・料金体系・手続きは変更されることがあります。この記事の内容は2026年時点の一般的な情報として書いていますが、実際に配信準備を始めるタイミングで、必ず各ストアの公式ガイドライン（App Store Review GuidelinesおよびGoogle Play デベロッパー ポリシー）を直接確認することを強くおすすめします。

また、両ストアともに「審査を経て公開した後も、規約は守られ続けていることが前提になっている」点は共通しています。一度審査に通過したからといって、その後アプリの仕様を変更してもよい、というわけではありません。特に個人開発では、公開後に「思いついた機能をどんどん追加する」ことが多くなりますが、追加した機能が新たに個人情報を取得するものであったり、収益化方式を変更するものであったりする場合、次のアップデート申請時に改めて審査対象となり、そこでリジェクトされることもあります。運用を始めてからも、機能追加のたびに「この変更は審査基準に影響しないか」を意識しておくことをおすすめします。

さらに、個人開発者が見落としがちな点として、両ストアの審査には「対象年齢レーティング」の申告があります。アプリ内のコンテンツ（暴力的表現、ギャンブル的要素、ユーザー生成コンテンツの有無など）に応じて対象年齢を自己申告する仕組みで、実態と異なるレーティングを申告すると、後から指摘を受けて修正を求められることがあります。特にユーザー同士が投稿・コメントできる機能を持つアプリは、モデレーション（不適切な投稿の管理）の仕組みがあるかどうかも審査観点に含まれる場合があるため、コミュニティ機能を持つアプリを作る場合は早めに確認しておくとよいでしょう。

個人開発者がリジェクトされやすい典型パターン

実際に多くの個人開発者が経験する、典型的なリジェクト理由を整理します。これらはいずれも、事前に知っていれば回避できるものです。

パターン1：プライバシーポリシーの不備・不整合

最も多いパターンのひとつです。具体的には次のようなケースが該当します。

• アプリ内にプライバシーポリシーへのリンクが設置されていない、またはリンクが切れている
• プライバシーポリシーの文面が、取得している情報の種類（位置情報、連絡先、カメラ、通知など）を網羅していない
• ストアの申請フォーム（App Store Connectの「App Privacy」欄やGoogle Playの「データセーフティ」欄）に記載した内容と、実際にアプリが取得しているデータの種類が一致していない

特に3つ目は見落としがちです。開発中に「後で使うかも」と権限リクエストのコードだけ残していて、フォーム記載を更新し忘れる、というミスが起こりやすいポイントです。プライバシーポリシーの整備自体は法務面でも必須ですが、ストア審査の観点でも「実装と文書の一致」が厳しく見られていると理解しておくとよいでしょう。

パターン2：アプリの機能不足・説明との不一致

「思いつき」から生まれたアプリでは、機能がまだ最小限（MVP（実用最小限の製品）的な状態）である場合も多いですが、審査観点では次のような点が問題視されることがあります。

• アプリストアの説明文で紹介している機能が、実際のアプリには実装されていない、または動作しない
• ログインを要求するにもかかわらず、テスト用のアカウント情報がレビュアーに提供されていない（審査担当者がログインできず、機能を確認できないためリジェクトされる）
• 明らかに情報量が少なく、Webサイトの単純なラッパー（WebView表示のみ）に見えるもの

特にログイン必須のサービスの場合、審査用のテストアカウントを申請フォームに明記しておくことは基本ですが、個人開発では見落とされがちなポイントです。

パターン3：収益化・決済に関するルール違反

アプリ内でデジタルコンテンツやサブスクリプションを販売する場合、多くのケースで各ストアの決済システム（In-App Purchase / Google Play の課金システム）を利用することが義務付けられています。Stripeのような外部決済サービスを、デジタルコンテンツの購入手段として直接組み込んでしまうと、この規約に抵触してリジェクトされる可能性があります（物理的な商品・実店舗サービスの決済など、対象外となるケースもあるため、自分のサービス内容がどちらに当たるかは事前に確認することをおすすめします）。

このルールは複雑で、かつ改定されることがあるため、課金機能を実装する前の設計段階で、該当するかどうかを必ず確認することをおすすめします。実装が終わった後に規約違反が分かると、決済方式自体の作り直しが必要になり、大きな手戻りになります。

パターン4：メタデータ・表現に関する不備

• アプリ名やアイコンが、既存の有名アプリと混同されるようなデザイン・名称になっている
• スクリーンショットに実際の画面と異なる誇張された表現が使われている
• キーワードの乱用（スパム的なキーワード詰め込み）

これらは審査基準としては明文化されているものの、「どこまでが許容範囲か」の線引きが曖昧な部分もあり、判断に迷う場合は保守的な表現にとどめておくことをおすすめします。

パターン5：外部サービス・APIの利用規約違反

個人開発では、地図・SNSログイン・翻訳・生成AIなど、外部サービスのAPIを組み込むケースが増えています。この際、外部サービス側の利用規約でも「商用利用の可否」「表示すべきクレジット表記」「データの再配布の可否」などが定められており、これを守っていないと、ストア審査そのものは通過しても、後から外部サービス提供元との間でトラブルになることがあります。ストア審査担当者が外部APIの規約まで細かく確認するとは限りませんが、審査を通過したこと自体が「すべての規約に適合している証明」にはならない、という点は理解しておくことをおすすめします。

パターン6：不十分な動作環境への対応

個人開発のアプリは、開発者自身が使っている端末・OSバージョンでの動作確認に留まりがちです。しかし審査担当者は、公開対象として設定した最小OSバージョンの端末でも動作確認を行うことがあり、古いOSバージョンでクラッシュする、画面レイアウトが崩れるといった問題が見つかると、それだけでリジェクトの対象になります。対応可能なOSバージョンの範囲を欲張らず、実際にテストできる範囲に絞って申請することも、リジェクトを避ける実務的な工夫のひとつです。

審査でリジェクトされたときの対処フロー

リジェクトは失敗ではなく、個人開発でもよくあるプロセスの一部と捉えることをおすすめします。慌てずに、次の順番で対応するとよいでしょう。

1. リジェクト理由を正確に読む：ストアから送られてくる通知には、該当するガイドラインの条項番号が記載されています。まずはこの条項の原文を確認します。
2. 該当箇所を特定する：機能なのか、文書（プライバシーポリシー等）なのか、メタデータなのかを切り分けます。
3. 修正する、または疑義を申し立てる：明らかな不備であれば修正して再提出します。理由に納得できない場合、App Storeであれば「App Review」に問い合わせる、Google Playであれば「ポリシーに関するお問い合わせ」から異議申し立てを行う手段があります。
4. 再提出後の審査期間を見込んでおく：再提出してもすぐに通過するとは限らないため、公開予定日には十分な余裕（1〜2週間程度）を持たせることをおすすめします。

短期間に何度もリジェクトされると、審査自体に時間がかかるようになったという声もありますが、これは公式に明言された仕組みではなく、個人開発者の間で語られる経験則の域を出ません。過度に恐れる必要はありませんが、同じ理由で繰り返しリジェクトされないよう、1回ごとに原因を丁寧に潰していく姿勢が結果的に一番早い近道です。

対応の際にもうひとつ意識しておきたいのは、リジェクト通知に書かれた理由が、実際の原因を完全に言い当てているとは限らない、という点です。特に「ガイドラインの趣旨に反する」といった抽象的な理由が示された場合、該当条項をそのまま読んでもピンとこないことがあります。このような場合は、次のような切り分けを試すと原因の特定がしやすくなります。

• 直前のアップデートで何を変更したかを一覧化し、変更点と指摘内容を突き合わせる
• 同じカテゴリの既存アプリ（審査を通過している競合アプリ）が、該当機能をどう実装・説明しているかを確認する
• 該当条項の原文を、ガイドライン全体の中でどの章に位置しているか（プライバシー章か、コンテンツ章か、ビジネス章か）から文脈を読み取る

これらを行っても原因が判然としない場合は、無理に自己判断で修正を重ねるより、レビュアーへの問い合わせ窓口を使って具体的に質問する方が、結果的に速く解決することが多いです。個人開発では「サポートに問い合わせるのは大げさかもしれない」と遠慮してしまう人もいますが、これは公式に用意されている手続きであり、遠慮する必要はありません。

配信前に確認しておきたいチェックリスト

アプリの提出前に、次の項目を一度見直しておくことをおすすめします。

• [ ] プライバシーポリシーが公開URLとして用意されており、アプリ内・ストア申請フォームの両方から正しくリンクされているか
• [ ] プライバシーポリシーに記載した取得情報の種類が、実際にアプリが取得する情報と完全に一致しているか
• [ ] 利用規約（利用規約）を用意しているか（必須ではないストアもありますが、トラブル予防の観点で用意しておくことをおすすめします）
• [ ] ログインが必要なアプリの場合、審査用のテスト用アカウント情報を申請フォームに記載したか
• [ ] デジタルコンテンツを販売する場合、各ストアの公式決済システムを利用しているか（外部決済サービスを直接組み込んでいないか）
• [ ] アプリ名・アイコン・スクリーンショットが実際の機能を正確に表しているか
• [ ] 位置情報・カメラ・通知など、OSレベルの権限リクエストがある場合、その利用目的をアプリ内で説明しているか
• [ ] 特定商取引法に基づく表記の表示が必要な有料サービスの場合、該当ページを用意し、アプリ内または関連Webサイトから確認できるようにしたか

このチェックリストは主要な項目を挙げたものであり、実際の審査基準はサービス内容によって細部が変わります。あくまで「最低限の見落とし防止」として使い、最終的な判断はストアの公式ガイドラインに沿って行うことをおすすめします。

Q&A：個人開発者からよく聞かれる質問

Q. 個人でも法人と同じ審査基準が適用されますか？

一般的には、個人開発者向けアカウントと法人（組織）向けアカウントで、審査基準そのものが大きく変わるわけではないとされています。ただし、App Storeでは組織アカウントの場合に一部の機能（複数人での管理など）が使えるといった運用上の違いがあります。個人事業主として登録するか、法人として登録するかの判断は、審査基準よりも個人事業主としての事業運営全体の観点で検討することをおすすめします。

Q. 審査にはどのくらいの期間がかかりますか？

ストアや時期、混雑状況によって変動するため、一概には言えません。数日程度で完了することもあれば、内容によってはより時間がかかることもあります。公開予定日を対外的に告知する場合は、審査期間の余裕を織り込んだ日程にすることをおすすめします。

Q. リジェクトが続いて開発者アカウントが停止されることはありますか？

規約への重大な違反（詐欺的な内容、繰り返しの規約違反など）があった場合、アカウントの停止や凍結といった措置が取られる可能性があるとされています。単純な機能不足や文書の不備によるリジェクトが直接アカウント停止につながるものではないと一般的には理解されていますが、悪質と判断されるパターン（同じ違反の放置、虚偽の申告など）は避けるべきです。不安な場合は、各ストアの規約やサポート窓口で確認することをおすすめします。

Q. Webアプリ（PWA）として配信すれば審査を回避できますか？

技術的には、ブラウザから直接アクセスできるWebアプリ（PWA）として配信すれば、ストア審査を経由せずにサービスを提供することは可能です。実際に、個人開発の初期段階ではPWAやレスポンシブ対応のWebサービスとしてまずMVP（実用最小限の製品）を検証し、需要が見えてからネイティブアプリ化を検討するという進め方も一般的に行われています。ただし、プッシュ通知や一部のOS機能を使いたい場合、ストア経由での配信が必要になることもあるため、自分のサービスに必要な機能次第で判断するとよいでしょう。

Q. リジェクトされた場合、公開日を予告していたSNS投稿などはどうすればよいですか？

個人開発では、SNSで「◯月◯日に公開します」と先に予告してしまい、リジェクトで公開が遅れて困るケースが少なくありません。審査には不確定要素がある以上、対外的な告知は「◯月中を予定」といった余裕のある表現にとどめ、確実な公開日が決まった後（審査通過後）に具体的な日付を発表する、という順序にしておくことをおすすめします。焦って公開日を固定してしまうと、リジェクト対応中に無理な妥協をしてしまい、結果的に品質を落とすことにもつながりかねません。

Q. 審査対応は自分でやるべきですか、それとも発注先に任せるべきですか？

アプリ開発を外部の開発会社やフリーランスに依頼している場合、ストア申請・審査対応まで契約範囲に含まれているかを事前に確認しておくことをおすすめします。審査対応が契約範囲外だと、リジェクトのたびに追加費用が発生したり、対応が後回しにされたりすることがあります。発注時の契約内容(SOW（作業範囲記述書）等)に、審査対応の範囲と、リジェクトへの対応工数がどちらの負担になるかを明記しておくと、後のトラブルを避けやすくなります。

専門知識を活かしたツールの場合の審査上の注意点

士業や医療・福祉などの専門職が、自身の専門知識を活かしたアプリ（診断支援、記録管理、業務効率化ツールなど）を配信する場合、通常のアプリ以上に審査で慎重に見られる傾向があります。特に次の点に注意することをおすすめします。

• 医療・健康・金融に関わる情報を扱う場合、追加の審査観点が設けられていることがあります。例えば、健康に関する助言や診断的な機能を持つアプリは、免責事項の明示や、専門家の助言を代替するものではない旨の表示が求められる場合があります。
• 資格が必要な業務をアプリ経由で提供する場合、ストア審査とは別に、業法上の制約を確認する必要があります。ストアの審査を通過したこと自体は、業法上の適法性を保証するものではありません。この点は審査観点とは独立した論点であり、別の記事で詳しく扱っています。
• 専門用語をアプリ内やストアの説明文で使う場合、一般ユーザーにも誤解を与えない表現に留めることをおすすめします。専門職向けの精緻な用語のまま公開すると、審査担当者が内容を正確に理解できず、確認の往復が増えることがあります。
• レビュアーへの補足説明欄（App Store Connectの「App Review情報」内のメモ欄など）を活用し、「このアプリは何を目的としており、専門家向けの補助ツールである」といった背景を一言添えておくと、誤解によるリジェクトを避けやすくなります。

専門職スピンオフ型でアプリを作る場合、機能そのものは既に業務の中で磨き込まれていることが多い一方、「一般消費者向けアプリとして配信する際の作法」に不慣れなことがあります。ストア審査を単なる事務手続きと軽視せず、早い段階でガイドラインに目を通しておくことをおすすめします。

加えて、専門職が自身の名前・資格を前面に出してアプリを配信する場合、審査担当者から見ると「個人の権威性を利用した訴求」と「サービスの実際の機能」が一致しているかどうかも確認対象になり得ます。例えば「医師監修」「弁護士が作った」といった表現をアプリの説明文やスクリーンショットに含める場合、その表現が実態を正確に反映しているか、誤解を招く誇張表現になっていないかを、公開前に見直しておくことをおすすめします。士業・医療職の肩書きは読者からの信頼を得やすい一方、その信頼性の根拠が審査上でも問われる、という点は意識しておくとよいでしょう。

店舗・地域事業でアプリを配信する場合の視点

店舗経営者が自店舗向けの予約管理・会員証・ポイントカードアプリなどを配信し、後に他店舗へも展開する場合、審査上は一般的な個人開発アプリと同じ扱いになりますが、実務上の注意点がいくつかあります。まず、店舗の実在性を示す情報（店舗名・住所・連絡先）がアプリ内またはWebサイトに明記されているかが、ユーザーからの信頼だけでなく、審査担当者が「実体のあるサービスか」を判断する材料にもなります。単なるアイデア段階のモックアップのようなアプリは、実質的な機能不足と判断されるリスクがあるため、最低限の実データ・実店舗情報を用意した状態で申請することをおすすめします。

また、複数店舗への展開を見込んでいる場合、店舗ごとに個別のアプリを作るのか、1つのアプリの中で店舗を切り替えられるようにするのかで、審査での見られ方が変わります。同じような機能・デザインのアプリを店舗ごとに量産すると、ストア側から「スパム的な複製アプリ」と判断され、まとめてリジェクトや削除の対象になることがあるため、複数店舗展開を計画する時点で、1アプリ多店舗対応の設計にしておくことをおすすめします。

審査対応と、その他の法務準備との関係

ストア審査でチェックされるプライバシーポリシーや利用規約は、審査を通すための「体裁」ではなく、本来はサービス運営そのものに必要な法務文書です。審査対応を進める過程で、次のような周辺の法務準備も同時に見直しておくことをおすすめします。

• 個人情報を取得するアプリであれば、プライバシーポリシーの内容が実際のデータ取得範囲と一致しているか（審査対応と個人情報保護の実務は表裏一体です）
• 有料サービスを提供する場合、特定商取引法に基づく表記に基づく表示や利用規約の整備が済んでいるか
• アプリ内課金やサブスクリプションを設計する場合、決済サービスの選定・審査対応が別途必要になる場合があること

これらは、ストア審査という「関所」を通るためだけに用意するのではなく、サービスを長く安全に運営していくための基盤です。審査対応を機に、一度まとめて整備しておくと、後々の手戻りを減らせます。

さらに、アプリが個人情報を取得する以上、プライバシーポリシーで「何を取得するか」を明示するだけでなく、実際にその情報をどう管理しているか（誰がアクセスできるか、外部にどう共有しているか、削除依頼にどう対応するか）についても、運営体制として整えておく必要があります。ストア審査ではここまで詳細な運用体制を確認されるわけではありませんが、ユーザーからの問い合わせや、まれに発生する情報漏えい等のインシデント対応に備えて、審査対応と同じタイミングで見直しておくと効率的です。個人開発でも、最低限のセキュリティ対応方針を文書化しておくことをおすすめします。

開発を外部発注している場合の審査対応の分担

自分でコードを書かず、開発会社やフリーランスにアプリ開発を依頼している場合、ストア申請・審査対応の分担を契約前に明確にしておくことを強くおすすめします。よくある行き違いとして、次のようなケースがあります。

• 開発会社の開発者アカウントでアプリを申請してしまい、後にアプリの所有権（開発者アカウント間の移管）を巡ってトラブルになる
• リジェクトへの対応が「追加要望」として扱われ、都度追加費用を請求される
• プライバシーポリシー・利用規約の作成が発注者・開発会社のどちらの責任か曖昧なまま進み、審査直前になって用意されていないことが発覚する

これらを避けるためには、発注前の段階で「アプリは発注者自身の開発者アカウントで公開する」ことを原則にし、審査対応の範囲・工数見積もりを見積書やSOW（作業範囲記述書）に明記してもらうことをおすすめします。開発会社によっては審査対応の実績・ノウハウを豊富に持っているところもあるため、発注先を選ぶ際の判断材料のひとつとして、過去のストア審査対応の経験を聞いてみるのもよいでしょう。

まとめ

スマホアプリのストア審査は、個人・複業での開発者にとって、公開直前に立ちはだかる最後の関門です。しかし、その多くは「機能が動くかどうか」よりも、プライバシーポリシーの整合性、説明文と実装の一致、収益化方式の適合性といった、事前に確認可能なポイントに起因しています。この記事で紹介したチェックリストを参考に、提出前の見直しを行うことをおすすめします。

なお、審査基準は各ストアの運営方針によって随時更新されるものであり、この記事の内容は2026年時点の一般的な傾向を整理したものです。実際の提出にあたっては、必ず該当するタイミングの公式ガイドライン（App Store Review Guidelines、Google Play デベロッパー ポリシー）を確認し、判断に迷う点があれば専門家（アプリ審査対応の実績がある開発者や、必要に応じて弁護士等）に確認することをおすすめします。

この記事の次に読みたい記事

• 決済サービスの審査に通るために、事前に準備しておくこと
• 個人情報を扱うサービスで、最低限守るべきルール
• 公開前に用意する利用規約・プライバシーポリシーの最低ライン
• 内製か外注か、そして契約と法務。開発期をやり切るための実務ガイド

--