スマホアプリの開発を発注して、いよいよ完成が見えてきた。ところが「ストアに公開するには審査があるらしい」「落ちたら公開が遅れるのでは」と聞いて、急に不安になる。初めてスマホアプリを発注する担当者の多くが、リリース直前にぶつかる悩みです。
「アプリをApp StoreやGoogle Playに公開するまでに何が必要で、審査に落ちることはあるのか知りたい」
先に結論をお伝えします。審査に落ちること（リジェクト）はめずらしくありません。ただし、多くは事前の準備と、あらかじめ決めておくことで防げます。そして審査対応の中身の大半は、開発会社の技術力ではなく、発注者側にしか用意できない「アカウント・書類・テスト用の情報」です。
この記事では、アプリ公開（リリース）までに必要なものを整理し、審査で指摘されやすいポイント、発注者が開発開始前に決めておきたいこと、開発会社への質問例をまとめます。内容は2026年10月時点の公式情報にもとづきます。ストア側のルールは変わることがあるため、最終確認は必ず各公式ページで行ってください。
アプリ公開に必要なものは「開発」以外にも4つある
アプリが完成しても、それだけでは公開できません。ストアに出すには、次の4つが必要です。
| 必要なもの | 中身 | 主に用意する人 |
|---|---|---|
| 開発者アカウント | Appleの「Apple Developer Program」、Googleの「Google Play Console」への登録 | 発注者（名義の決定が必要） |
| ストア掲載情報 | アプリ名・説明文・スクリーンショット・年齢区分・カテゴリ | 発注者と開発会社 |
| 規約まわりの書類 | プライバシーポリシー、利用規約、問い合わせ先 | 発注者 |
| 審査用のビルドと情報 | 審査用のアプリ本体、テスト用ログイン情報、審査担当者への説明 | 開発会社（情報は発注者と相談） |
ここで大事なのは、1行目の「開発者アカウント」と3行目の「書類」は、発注者が主体になるものだという点です。開発会社は手続きを手伝えますが、会社としての名義や、個人情報をどう扱うかの方針は、発注者にしか決められません。
まず決める：開発者アカウントは誰の名義にするか
最初に決めたいのが、ストアに登録する開発者アカウントの名義です。ここが曖昧なまま進めると、公開直前に手続きが止まったり、後で引き継ぎ問題になったりします。
📰 出典：Apple Developer「Apple Developer Program 登録のご案内（Become a member）」
Appleの公式案内では、Apple Developer Programの年会費は99米ドル（執筆時点。現地通貨で表示される地域があります）とされています。法人（Organization）として登録する場合は、法人を確認するための D-U-N-S 番号（企業を識別する番号）が必要で、取得に数営業日かかることがあります。Googleは、Google Play Consoleの登録に一度きりの登録料（25米ドル、執筆時点）がかかります。
名義の選び方は、大きく3つです。
- 発注者の法人名義で登録する（基本の考え方）：アプリの持ち主が自社であることが明確になり、開発会社を変えても引き継ぎやすくなります。
- 開発会社の名義で登録してもらう：手続きは早いですが、ストア上の発行者名が開発会社になり、将来の引き継ぎや契約終了時に手間がかかります。
- 個人名義で登録する：登録は簡単でも、ストアに個人名が表示されたり、後述のテスト要件が加わったりします。事業用なら避けるのが無難です。
AWSアカウントの名義と同じ考え方で、「アプリの持ち主＝アカウント名義人」にしておくと、後のトラブルを避けやすくなります。なお、契約や名義の扱いは個別の事情で変わります。判断に迷う場合は、弁護士や専門家へご相談ください。
審査は2回ある？Appleと Google の違い
公開前の審査（レビュー）は、AppleとGoogleでやり方が少し違います。
| 項目 | App Store（Apple） | Google Play |
|---|---|---|
| 審査の中身 | 人による確認を含む審査。App Review Guidelines に沿って確認される | 自動チェックと人による確認の組み合わせ（ポリシーに沿って確認） |
| 審査にかかる時間 | 提出ごとに異なる。公式に固定の日数は示されていない | 同様に、状況によって異なる |
| 事前の追加条件 | 特になし（アカウント登録の確認はある） | 個人アカウントのうち一定の時期以降に作成したものは、クローズドテストの実施が公開の条件になる場合がある |
| 指摘されたとき | App Store Connect 上のメッセージで理由が届き、修正して再提出する | Play Console 上で通知が届き、修正して再提出する |
Google Playの個人アカウントでは、公開の前に「一定人数のテスターが、一定期間連続してテストする」ことが求められる仕組みがあります。新規の個人アカウントが対象で、人数や日数は過去に見直されており、執筆時点では「12人以上が14日間連続でテストする」と案内されている例があります。法人アカウントでは扱いが異なる場合があるため、最新の条件は Google Play Console のヘルプで確認してください。
📰 出典：Google Play Console ヘルプ「新しい個人用デベロッパー アカウントのアプリ テスト要件」
スケジュールへの影響が大きいのは、このテスト期間です。「完成した翌日に公開」はできない前提で、リリース希望日から逆算して、少なくとも数週間の余裕を見ておくのが安全です。
審査で落ちる（リジェクトされる）よくある理由
「落ちる」と聞くと不合格のようですが、実際は「このままでは公開できないので、ここを直してください」という指摘です。直して再提出すれば、通ることが一般的です。指摘されやすいポイントを、公式のガイドラインから整理します。
📰 出典：Apple Developer「App Review Guidelines」
理由1：審査担当者がアプリを使いきれない
Appleのガイドラインでは、ログインが必要なアプリには、テスト用のアカウント情報（デモアカウント）を提出し、審査中はバックエンドのサーバーも動かしておくことが求められています。テスト用アカウントがない、サーバーが止まっている、といった理由で動作を確認できないと、審査が進みません。
審査用のアカウントは開発会社が用意することが多いですが、「どの権限のアカウントが必要か」「本番データに触れないようにするか」は、発注者が決めておきたい点です。
理由2：Webサイトを包んだだけで、アプリとしての価値が弱い
Appleのガイドライン（4.2）は、アプリには「単なるWebサイトの再パッケージを超える機能・コンテンツ・UI」が必要だと示しています。既存のWebサイトをそのままアプリ化しただけだと、指摘される可能性があります。「Webと同じものを包むだけでよい」と考えている場合は、開発会社に審査上のリスクを確認しましょう。
理由3：プライバシーポリシーとデータの扱いが不十分
Appleのガイドライン（5.1.1）では、すべてのアプリにプライバシーポリシーへのリンクを、ストアの情報とアプリ内の両方に用意することが求められています。何のデータを集め、どう使い、どれくらい保管し、ユーザーがどう削除を依頼できるかも書く必要があります。
さらに、アプリ内でアカウントを作成できるなら、アプリ内からアカウントを削除できる機能も必要とされています（執筆時点）。この機能は、後から追加すると画面・サーバー・データ削除の仕組みまで手を入れることになり、費用と期間に響きます。最初の見積もりに含まれているかを確認しましょう。
Google Playでも、アプリが扱うデータについて申告する仕組み（データセーフティ）があり、申告内容と実際の動きが食い違うと指摘されることがあります。
理由4：課金の仕組みがルールに合っていない
アプリ内でデジタルの機能やコンテンツを販売する場合、Appleのガイドライン（3.1.1）では、原則としてアプリ内課金（Appleの決済の仕組み）を使うことが求められています。自社の決済ページへ誘導する、ライセンスキーで機能を解放する、といった設計は指摘の対象になりえます。ストアの手数料が発生することも含め、収益モデルは設計の初期に確認しておく必要があります。
なお、物品の販売や現実のサービスの決済などは扱いが異なります。自社のケースがどちらに当たるかは、開発会社と一緒にガイドラインで確認してください。
理由5：未完成のまま提出している
仮の文章（ダミーテキスト）、つながらないリンク、動かないボタン、クラッシュなどが残っていると、「完成していない」という理由で指摘されます。公開前の動作確認は、発注者側の受け入れテストでも行いましょう。受け入れテストの進め方は、システムの受け入れテスト（検収）で何をチェックする？で解説しています。
審査に落ちたとき、費用と日程はどうなる？
指摘が来たときの典型的な流れは、次のとおりです。
- 指摘内容（理由）がストアの管理画面に届く
- 開発会社が原因を確認し、修正方針を決める
- 修正して再提出する（アプリの修正が必要な場合は新しいビルドを作る）
- 再審査を受ける
ここで揉めやすいのが「再提出の修正費用を誰が負担するか」です。ストア側の判断は開発会社にも完全には予測できないため、契約や見積もりで次の点をあらかじめ合意しておくと安心です。
- 審査対応（提出作業・1回目の指摘への修正）を、見積もりの範囲に含めるか
- 何回目の指摘から追加費用の相談とするか
- 指摘の原因が「発注者が決めた仕様」にあった場合の扱い（例：アカウント削除を不要としていたが、ルール上は必要だった）
契約形態による違いについては、請負契約と準委任契約の違いも参考になります。契約書への書き方など個別の判断は、弁護士や専門家にご確認ください。
公開後も続く作業：OSの更新とストアの規約変更
公開して終わりではありません。スマホのOSは年に一度の大きな更新があり、ストア側も、対象とするOSのバージョンなどの要件を定期的に見直します。要件を満たさなくなったアプリは、更新ができなくなったり、ストアでの表示に影響が出たりすることがあります。
そのため、公開後の保守契約に、OS更新への追従とストアの要件変更への対応を含めるかを決めておく必要があります。保守費用の考え方は、システムの保守費用は何に払っている？にまとめています。
発注者がやること チェックリスト
- ☐ 開発者アカウントの名義（自社の法人名義か）を、開発開始前に決めた
- ☐ 法人で登録する場合、D-U-N-S番号の取得など登録に時間がかかる手続きを早めに始めた
- ☐ プライバシーポリシーと利用規約を、アプリの機能（集めるデータ・外部サービス）に合わせて用意する担当を決めた
- ☐ 会員登録がある場合、アカウント削除機能が見積もりに入っていることを確認した
- ☐ 審査用のテストアカウントと、審査期間中にサーバーを動かしておく体制を決めた
- ☐ 課金がある場合、アプリ内課金のルールに合う設計かを開発会社に確認した
- ☐ リリース希望日から逆算して、審査・再提出・テスト期間の余裕を数週間見た
- ☐ 審査で指摘された場合の費用負担と回数の扱いを、契約前に合意した
- ☐ 公開後のOS更新・ストア要件変更への対応を、保守の範囲として決めた
開発会社への質問例
打ち合わせでそのまま使える質問です。
- 「ストアの開発者アカウントは、弊社の名義で作る前提でよいでしょうか。登録に必要な書類や期間を教えてください」
- 「このアプリの機能で、AppleやGoogleの審査で指摘されやすい点はどこですか。過去に指摘された例があれば、一般的な範囲で教えてください」
- 「会員登録機能がある場合、アカウント削除やデータ削除の機能は見積もりに含まれていますか」
- 「審査で指摘を受けた場合、再提出までの対応はどこまで見積もりに含まれていますか。追加費用になる条件も教えてください」
- 「公開後のOSの大きな更新やストアの規約変更に、保守でどこまで対応していただけますか」
まとめ
- スマホアプリの公開には、開発のほかに、開発者アカウント・ストア掲載情報・規約の書類・審査用の情報が必要です。
- 審査での指摘はめずらしくありませんが、多くは事前の準備と合意で防げます。直して再提出すれば通ることが一般的です。
- 名義、プライバシーポリシー、アカウント削除、課金の設計、再提出の費用負担は、開発が始まる前に決めておくと、公開直前の手戻りが減ります。
- Google Playの個人アカウントでは公開前のテスト要件がある場合があり、スケジュールには数週間の余裕を見ておきましょう。
ストアのルールは更新されます。公開に向けて動くときは、各公式ページ（App Review Guidelines、Google Play Console ヘルプ）で最新の条件を確認し、開発会社と同じ情報を見ながら進めてください。
あわせて読みたい関連記事
