スタートアップ向けモバイルアプリチェックリスト：MVPからApp Store承認まで34項目（2026）

スタートアップ向けモバイルアプリチェックリスト：MVPからApp Store承認まで34項目（2026）

AppleのApp Store Review Guideline 5.1.1(v)は、私たちがこれまでに出荷してきたどんなバグよりも多くのスタートアップのリリース日を潰してきました。アカウント削除ボタンの付け忘れひとつをデモデイの前夜に提出すれば、スケジュール全体が1週間後ろにずれます。このスタートアップ向けモバイルアプリチェックリストが存在するのは、そのミスが完全に避けられるものだからです。そして、原因となるガイドライン番号を書き留めている人はほとんどいません。

要点：

• Appleはアカウント削除フローとプライバシーポリシーリンクの欠落を理由にアプリをリジェクトします。ガイドライン5.1.1と1.5がまさにそれを明記しています。
• Google Playはアプリ内と公開Webの両方にアカウント削除パスを求めており、2024年5月31日の延長期限を経て適用が進んでいます。
• iOSとAndroidの申請チェックリストは別物です。ひとつの統合リストとして扱うことが、直前のリリース遅延の原因第1位です。

コードを書く前に

最初の1画面を設計する前に、3つ確定させておくべきことがあります。MVPとは実際何なのか、プライバシーポリシーは必要か（必要です）、そしてGDPRまたはトルコのKVKKのいずれかがユーザーに適用されるか、です。この段階を飛ばすことが、創業者が提出したい週の直前にリーガルページを慌てて書くはめになる理由です。

MVPとは一言でいえば、コアとなる仮説を実際のユーザーで検証するための、製品の最小バージョンです。フルビジョンの機能を削ったバージョンではありません。スコープがまだ曖昧なら、コードを1行も書く前にビルドのスコープを正しく決めることで、開発の途中で機能を削る事態ではなく、事前に削る事態を防げます。

Apple自身のガイドラインは、プライバシーポリシー要件について率直です。**ガイドライン5.1.1(i)**は、アプリがApp Store Connectのメタデータに、そして多くの場合はアプリ内に「プライバシーポリシーへのリンクを含めなければならない（must include a link to their privacy policy）」と定めています。これは提案ではありません。欠落していれば提出を止めるブロッカーです。

• MVPのスコープを一文で定義する
• プライバシーポリシーが必要であることを確認する（ほぼ常に必要です）
• サポートURLを用意する（Appleガイドライン1.5が必須要件としています）
• EUまたはトルコのユーザーがいる場合、GDPR/KVKKの適用可否を確認する
• ネイティブかクロスプラットフォームか、技術スタックを決める

MVPビルド週間

MVPビルド週間とは、実際に何を出荷し、何を切るかを決める場です。そして正直な答えはこうです。創業者が予想するより多くを切ることになります。アナリティクスとクラッシュレポートはビルド後ではなく、ビルド中に入れます。ローンチ後に後付けすると、最初の仮説を検証するためにまさに必要なデータが失われます。

v1のスコープから実際に切るのは、ほとんどの場合、検証対象の「その一つ」に該当しないものすべてです。プッシュ通知、ソーシャルログイン、6個のトグルが並ぶ設定画面、すべて待てます。創業者がこれに抵抗するのはもっともで、未完成のものを出す気分になるからです。実際、未完成です。それが狙いです。

複数のアプリを出荷してきたある創業者がdev.toのチェックリスト記事で書いたように、初期段階でフィードバック機構を省くことは、彼が「毎回後悔した」ミスです。最初のレビューが届いてからではなく、今すぐ組み込んでください。スコープ決めの会話そのものを速めたいなら、ビルド開始前にAIを使ったスコープ決めの高速化も一読の価値があります。

• 最初のTestFlight/社内ビルドより前にアナリティクスを組み込む
• クラッシュレポートを接続する（SentryまたはFirebase Crashlytics）
• アプリ内にフィードバック機構を組み込む
• 検証対象のコア機能に該当しない機能をすべて切る
• 最初のバージョン文字列を書く（バージョニングは後述）

提出前の1週間

ここは競合のチェックリストがことごとく丸ごと飛ばしている段階であり、最も防ぎやすい遅延が起きる場所でもあります。アプリのセマンティックバージョニングはMAJOR.MINOR.BUILDパターン（1.0.0、パッチなら1.0.1、機能追加なら1.1.0）に従います。今すぐ方式を決めてください。版本号の付け方が一貫していないと、アプリストア側も自チームも混乱します。

段階的ロールアウトとは、アップデートをまず少数のユーザー（多くの場合1%、次に10%、そして50%）に配信し、その後全員へ展開することです。私たちが確認した3つの競合チェックリストのうち、これに言及していたのは1つだけで、しかも触りだけでした。クラッシュがすり抜けた場合、段階的ロールアウトなら影響範囲を限定できますが、そうでなければ100%のユーザーが同時に被害を受けます。

クライアントの提出をゴーサインする前に私たちが問うのは、シンプルな質問です。クリティカルパスは、今この瞬間に、実機でエンドツーエンドで動くか（シミュレーターではなく）。クラッシュフリー率は許容範囲か。ストア掲載用アセットは本当に最終版か、プレースホルダーではないか。

• バージョン番号が一貫した方式に従っていることを確認する
• クリティカルパスをもう一度エンドツーエンドでテストする
• ストアが対応している場合、段階的ロールアウトの割合を準備する
• 提出前にクラッシュフリー率が許容範囲であることを確認する
• ストア掲載用アセットをすべてスクリーンショット・準備する

提出日：iOS vs. Android

iOSとAndroidの申請は、異なる理由で失敗します。そして、これらをひとつの統合チェックリストとして扱うことが、私たちが目にする直前リリース遅延の単一最大の原因です。AppleのApp Store Review GuidelinesとGoogle Playのデベロッパーポリシーは、それぞれ具体的で確認可能な要件を明記しています。そしてほとんどの創業者は、リジェクトメールを受け取って初めてそれを知ります。

私たち自身のアプリ提出において、初めての創業者が最もつまずきやすいのは、アカウント削除要件と到達不能なサポートURLの2点です。どちらも、提出前に気づいていれば1行の修正で済みます。気づいていなければ、どちらも自動リジェクトの原因になります。

AppleのApp Store Review Guidelinesは具体的です。**ガイドライン5.1.1(v)**はアカウント作成に対応するアプリにアプリ内アカウント削除の提供を義務づけ、ガイドライン1.6はData Securityの開示を扱い、ガイドライン1.5は動作するサポートURLを必須としています。Androidでは、Google Playのデベロッパーポリシーがアプリ内の削除パスと、アカウント削除依頼用の公開Web URLの両方を求めています。Googleは2023年4月にこの要件を発表し、Data safetyフォームのデータ削除関連質問について2023年12月7日の期限を設け、2024年5月31日までの延長を認めました。以降、非準拠アプリは適用措置の対象となります。これは小規模アプリ向けに事実上撤廃された古いルールではありません。今も有効です。

2つの申請フローは、書類上だけでなく仕組みとしても分かれています。iOSでは、XcodeまたはTransporterでビルドをアップロードし、App Store Connectがそれを処理します（数分から1時間以上かかります）。そこから、TestFlightで社内テスター・外部テスターに配布するか、直接App Reviewに提出します。TestFlightは任意の雑務ではありません。レビュアーにリジェクトされるはずのバグを事前に潰すための、Appleが想定する手順です。Androidでは、Google Play Consoleは単一の提出ではなくトラック制で動き、内部テスト、クローズドテストまたはオープントテスト、そしてプロダクションへと進みます。それぞれに独自のオーディエンスと独自の昇格ステップがあります。段階的ロールアウトが登場するのは、既存のプロダクションリリースを更新するときだけです。Google自身のリリースドキュメントが「最初のリリースを展開する場合、ロールアウトの割合を選択するオプションは表示されません（if you're rolling out your first release, you won't see the option to select a rollout percentage）」と書いているとおり、初めてのローンチを割合の段階引き上げ前提で計画しないでください。それは後から使うものです。

実際に最初の提出を阻むのはコードではなく書類です。Appleは、よく使われるサードパーティSDK（アドネットワーク、アナリティクス、クラッシュレポーター）の定義済みリストに対してプライバシーマニフェストを義務づけています。そして、その責任の所在についてのApple自身のガイダンスは率直です。「アプリでサードパーティSDKを使用する場合、SDKがアプリに含めるすべてのコードについて開発者が責任を負い、そのデータ収集と利用の慣行を把握しておく必要がある」（AppleのサードパーティSDK要件ページより）。リスト掲載SDKのマニフェストを省略すると、ビルドはApp Store Connectを通過できません。Google Playで相当する書類上の関門はData safetyフォームで、内部テスト専用ビルドを除くすべてのトラックのすべてのアプリで必須です。「Google Playで公開されているアプリを持つすべてのデベロッパーは、クローズド、オープン、プロダクションのテストトラック上のアプリを含め、Data safetyフォームに回答しなければならない」（Google PlayのData safetyドキュメントより）。誤って記入し、申告内容と実際のアプリ動作の不一致が表面化すれば、Googleは「適用措置を含む適切な対応を取る場合がある」と明言しています。

ポリシーの文言とは無関係の3つ目の失敗モードがあります。レビュアーがアプリを文字通りテストできない、というものです。Appleのガイドライン2.1はこれを直接明記しています。「アプリにログインが含まれる場合、デモアカウント情報を含め（そしてバックエンドサービスを起動して！）ください（include demo account info (and turn on your back-end service!) if your app includes a login）」。動作するデモ認証情報がない、レビュー期間中にバックエンドが動いていない、サポートURLに到達できない、こうした状態では、アカウント削除フローがどれだけ準拠していても差し戻されます。アプリの一部がペイウォールやログインの背後にあるなら、そこへ正確にたどり着く方法をレビュアー用メモに書いてください。2分で終わるステップですが、初めての創業者は恒常的に飛ばします。

もうひとつ、同じ文脈に属するAndroid専用の関門があります。ターゲットAPIレベルです。Android自身のデベロッパー向けドキュメントは、「新しいアプリとアプリの更新は、Google Playに提出するために」現在要求されているAndroid APIレベルをターゲット「しなければならない（new apps and app updates must target ... to be submitted to Google Play）」とし、「古いアプリは、新しいバージョンのAndroidを搭載したデバイスの新規ユーザーには利用できなくなる（out-of-date apps are unavailable to new users of devices that run newer versions of Android）」と述べています。これはアカウント削除ともData Safetyとも無関係ですが、提出を同じように容赦なくブロックします。しかも毎年変わる種類の要件なので、リリースをビルドする前に現在の数値を確認してください。

この検索で上位表示されているチェックリストで、App Storeのガイドライン番号を1つでも引用しているものはゼロです。私たちは引用します。コンプライアンスを推測で済ませることが、リリースが1週間ずつ遅れる原因だからです。より幅広いデータ取り扱い体制を構築しているなら、ローンチ前のデータ取り扱いチェックリストが、ここで重複させないセキュリティ面をカバーしています。

iOS申請チェックリスト：

• プライバシーポリシーURLが公開され、到達可能である
• アプリ内アカウント削除パスを出荷済み（ガイドライン5.1.1(v)）
• サポートURLが公開済み（ガイドライン1.5）
• Data Securityの開示を完了済み（ガイドライン1.6）
• 一般公開の提出前にTestFlightビルドが承認済み

Android申請チェックリスト：

• Play ConsoleでData Safetyフォームを完了済み
• アプリ内アカウント削除パスを出荷済み
• アカウント削除依頼用の公開Web URLが公開済み（Google Play要件）
• 段階的ロールアウトの割合を設定済み
• ターゲットAPIレベルが現在のPlay要件を満たしている

ローンチ当日

ローンチ当日とは、アプリが実際のユーザーに向けて本当に公開される日のことです。提出とは別物で、提出はその数日から数週間前に行われます。そして1週目とも別物で、1週目はその後の顛末です。初日の段階的ロールアウト監視こそが、拡大を続けるか一時停止するかを判断する材料になります。

最初の24時間は、App Store ConnectまたはPlay Consoleのダッシュボードを毎日ではなく毎時確認してください。クラッシュフリー率が下がったら、さらに100人のユーザーが同じバグを踏んだ翌朝ではなく、1時間以内に知りたいはずです。ロールバック用ビルドをすぐ出せる状態にしておきます。AI機能で使っている堅牢化・安定化・デプロイの規律は、ここでもそのまま当てはまります。

• 最初の24時間はクラッシュフリー率を毎時監視する
• サポートチャネルに人員を配置し、対応できる状態にする
• 段階的ロールアウトが計画どおり拡大していることを確認する
• 重大なバグに備え、ロールバック用ビルドをすぐ出せる状態にしておく

公開後1週間

公開後の1週間に、実際の作業のほとんどは起こります。にもかかわらず、計画を立てている人はほとんどいません。毎日のクラッシュレポート確認と最初のストアレビューへの返信は、ローンチ当日にやったどんなことよりも重要です。

「ローンチそのものは、思っているより重要ではありません。重要なのは、その後の数週間で何をするかです」。ある創業者が自身のローンチ後チェックリストでこう書いています。それが1週目の正直な姿です。素早くパッチし、個別に返信し、実際のユーザーが身をもって試す前に、データ削除フローが動くことを本当に確認しておく。ここで、これらすべての開発・維持コストが気になり始めたら、公開後のメンテナンスとアップデートの予算計画が対になる記事です。この記事は準備態勢をカバーし、あちらは請求書をカバーします。

• 最初の1週間、毎日クラッシュレポートを確認する
• 最初の10件のストアレビューに個別に返信する
• 重大なバグは48時間以内にトリアージしてパッチする
• データ削除依頼のプロセスが本当にエンドツーエンドで動くことを確認する
• 本来のMVP仮説とアナリティクスを照合する頻度を決める

Techsyのアプローチ

私たちは、すべてのクライアントビルドで提出前レビューを同じやり方で扱っています。提出をゴーサインする前に、クリティカルパスが実機で動くか、クラッシュフリー率が維持されているか、そしてガイドラインが義務づけるすべてのフロー（アカウント削除、プライバシーポリシー、サポートURL）が実際に機能するか、モックアップ上に存在するだけでなく動くかを問います。短いリストですが、アプリが初回で審査を通過するかどうかを決めるのは、このリストです。

これらのガイドラインを乗り越えた経験のある誰かに提出を任せたいなら、私たちのモバイルアプリ開発プロセスは、まさにこの提出前レビューのステップを中心に組み立てられています。これは自分で下調べをすることの代わりではなく、下調べを終えた後に私たちが行うことです。

よくある質問

MVPとは何ですか？ローンチチェックリストにとってなぜ重要なのですか？

MVPとは、ひとつのコアとなる仮説を実際のユーザーで検証するための、製品の最小バージョンです。ここで重要になるのは、このチェックリストのすべての項目がスコープに比例して増えるという点です。MVPを絞るほど、提出時に問題になりうるものは減り、1週目に計測・監視・パッチすべき機能も減ります。

アプリがApp Storeからリジェクトされるのはなぜですか？

最も多い、防げる理由は、プライバシーポリシーリンクの欠落（ガイドライン5.1.1(i)）、アプリ内アカウント削除の不在（ガイドライン5.1.1(v)）、そして到達不能なサポートURL（ガイドライン1.5）です。いずれも修正にエンジニアリングの努力は要りません。バグではなく、チェックリストの項目です。

アプリにアカウント削除オプションを付けないとどうなりますか？

iOSでは、アプリがアカウント作成に対応している場合、ガイドライン5.1.1(v)によりこれが自動リジェクト理由になります。Androidでは、Google Playがアプリ内と公開Webの両方の削除パスを求めており、2024年5月31日の延長期限を過ぎると非準拠アプリは適用措置の対象となります。そして、これを省略すると両プラットフォームで提出がブロックされます。

スタートアップでもモバイルアプリにプライバシーポリシーは必要ですか？

はい、ほぼ常に必要です。Appleはガイドライン5.1.1(i)でリンク付きプライバシーポリシーを必須とし、Google PlayはData Safetyフォーム内での記載を求めています。サインアップ用のメールアドレスだけでも、ユーザーデータを収集するなら、提出前に用意する必要があります。

App StoreとGoogle Playへの提出では何が違いますか？

Appleの審査は、指名された条項（5.1.1、1.5、1.6）と人間のレビュアーによるガイドライン主導型です。Google PlayはData Safetyフォームと自動チェックに重きを置いています。アカウント削除要件は趣旨こそ似ていますが、仕組みが異なります。上記の比較表を参照してください。

アプリストアの審査は実際どれくらいかかりますか？

どちらのストアも保証された処理時間を公表していません。そのため、どこかで読む数字は約束ではなく、おおまかな目安として扱ってください。私たちのクライアント提出では、Appleの承認は概ね1〜2日以内に着地し、アカウント削除やデータ開示に関わるものは長引く傾向があります。Google Playは通常より速い傾向です。どちらにせよ、ローンチ日は余裕を持たせて計画してください。

段階的ロールアウトとは？使うべきですか？

段階的ロールアウトとは、アップデートをまず少数のユーザーに配信し、一気に100%へ展開するのではなく、徐々に拡大していくことです。ストアが対応しているなら常に使ってください。一時停止して修正する前にバグを踏むユーザー数を限定できます。

アプリの提出にサポートURLは必要ですか？

はい。Appleのガイドライン1.5は、提出の一部として動作するサポートURLを必須とし、Google Playもサポート連絡先を求めています。ここがリンク切れや無人の受信トレイだと、簡単に避けられるリジェクト理由になります。

アプリの公開後1週目に何を監視すべきですか？

クラッシュレポートを毎日、最初の10件のストアレビュー、そしてデータ削除依頼のプロセスが本当にエンドツーエンドで動くか、です。この時期はまた、MVPが検証するために作られた仮説と、実際の利用データを照合し始めるタイミングでもあります。

GDPRやKVKKは小規模スタートアップのアプリにも関係しますか？

EUにユーザーがいるなら、会社の規模に関係なくGDPRが適用されます。トルコにユーザーがいるなら、KVKKが同じように適用されます。どちらの法律にも小規模スタートアップの免除規定はないため、適用可否は実際のユーザーデータを保護する段階になってからではなく、スコープ決めの段階で確認してください。

著者について

Mert BaturはTechsy.ioの共同創業者です。同社チームはB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを出荷しています。Techsyチームが本番環境で実際に使っているLLMツールスタックについて執筆しています。LinkedInでつながる

結論

スタートアップ向けモバイルアプリチェックリストがその存在価値を持つのは、今日すぐに行動できるほど具体的な場合だけです。MVPを一文で定義し、ビルド前にアナリティクスを組み込み、提出前の1週間にバージョン方式を見直し、iOSとAndroidのチェックリストをひとつのリストとして扱わず分けること。アカウント削除とプライバシーポリシーの項目だけで、私たちが見てきた避けられるリジェクトの大部分を占めます。

チェックリストを印刷し、段階ごとに進めてください。そして公開後の1週目を飛ばさないでください。そこは競合のチェックリストがすべて省いている部分であり、ローンチが定着するかどうかを実際に決める部分です。提出前に第三者の目で確認してほしいなら、無料相談を受ける →