AI-native MVP の作り方：最初に作るべき機能、作ってはいけない機能
MVP は「最小機能」ではなく「最小検証単位」。AI で速く作れる時代の MVP スコープ設計を整理する。
この記事の結論
- MVP は 最小機能 ではなく 最小検証単位 です。検証したい仮説を 1 つ決めて、それを確かめるために必要なものだけ作ります。
- 最初に入れるべき機能は 5 つ: 認証 / ロール / テナント分離、課金、監査ログ、問い合わせ導線、規約・退会導線。これらは後から入れるとコストが大きく膨らみます。
- 最初は作らない機能は 4 つ: SNS シェア / 招待 UI、アプリ内チャット、リッチな管理画面、A/B テスト基盤。トラフィックが立つまでは作っても活きません。
- AI で短縮できるのは 実装 です。ユーザー像、業務要件、KPI、法務観点 は人間が決めないと進みません。
- 投資家に見せる前に整えるのは「デモ映え」ではなく、仮説・利用ログ・継続兆候・データと認証の最低ライン の 4 点です。
「とりあえず MVP を作って、ユーザーに見せたい」
スタートアップや新規事業の相談で、最初に出てくる言葉です。意気込みは正しい。ただし、ここで「MVP = 機能を最小にしたシステム」と理解していると、ほぼ確実にスコープを誤ります。
MVP は 最小機能 ではなく、最小検証単位 です。検証したい仮説を 1 つ決めて、それを確かめるために必要なものだけを作る。そのために削るべき機能と、絶対に削ってはいけない機能の見分け方を、AI で実装が速くなった現在の前提で整理します。
Cursor、Claude Code、Codex といった AI 開発ツールが揃った現在、MVP の実装そのものは、過去より大きく速くなりました。Anthropic が公開している創業者向けプレイブックでも、AI ネイティブのスタートアップは Idea / MVP / Launch / Scale の 4 段階で、それぞれ違う実装と設計の優先順位を持つ、と整理されています (The founder's playbook / Anthropic)。OpenAI も同様に、Codex の社内利用が「コードを書く職」を超えて、アナリスト・マーケター・コーポレートファイナンスといった非エンジニアの仕事にまで広がっている事例を公開しています (Codex for every role, tool, and workflow / OpenAI)。
つまり、「作ること」自体は安くなりました。にもかかわらず、MVP の失敗が減らないのは、作る前の判断 に時間を投じていないからです。
MVP を「最小検証単位」として定義する
MVP は Minimum Viable Product の頭文字ですが、Viable (実行可能な) という単語が曲者です。直訳すると「実行可能な最小の製品」になりますが、現場の感覚に翻訳すると次のとおりです。
その事業が成立するかどうかを判断するために、最小限のものだけを作って、最も重要な仮説を検証する。
ここでの仮説は、たとえばこのレベルまで具体化されている必要があります。
- 「店舗オーナーは、来店促進のために月 1 万円を払う」
- 「中小企業の経理担当者は、補助金情報を毎週確認したい」
- 「介護施設の現場リーダーは、シフト調整を Excel から SaaS に移したい」
「便利なツールを作る」「市場の課題を解決する」のような抽象では、検証のしようがありません。Yes か No か、もしくは数値で判定できるレベル まで仮説を具体化したものが、MVP のスコープを決めるための起点になります。
「MVP = 雑でいい」は誤解
「MVP だから、雑でいい」と発注されることがあります。半分は正しいですが、全部の領域を雑にしてはいけない のがポイントです。
| 雑にしてよい領域 | 雑にしてはいけない領域 |
|---|---|
| 管理画面の UI (Excel か Google Sheets で代用してよい) | 認証・テナント分離 |
| レポート機能 (リリース後 1〜2 ヶ月、手動で集計してよい) | 決済 |
| 多言語対応 (初期は 1 言語で十分) | データモデル |
| ダーク・ライトモード | 個人情報の扱い |
| 細かい権限制御 (3 ロール以上は最初要らないことが多い) | 障害時の問い合わせ導線 |
「動けばいい」を雑にしてよい領域に当てはめるのは正解です。事業の根幹に当てはめると、半年後に立て直しコストを払うことになります。
最初に入れるべき 5 つ: 事業として「動かす」のに不可欠
MVP に入れるべき最低限の機能を 5 つに絞ります。toC・toB・toBtoB を問わず、有償サービスとして公開するなら共通する項目です。
1. 認証 / ロール / テナント分離
「ログイン機能」だけでなく、「自社の他のお客さんのデータを見られない」境界 を最初から設計する必要があります。Clerk、Firebase Auth、Auth0、Supabase Auth など、現時点で標準的な認証プロバイダを使えば、初期の実装コストは抑えられます。
ポイントは、認証 = ログインではなく、テナント識別子 + ロール の組み合わせで設計することです。
- 認証時に確定するもの: ユーザー ID、所属するテナント (組織) の ID、そのテナント内でのロール
- データアクセス時に効かせるもの: テナント ID で必ず絞り込む、ロールに応じて操作を制限
Supabase なら Row-Level Security、Firestore なら セキュリティルール、自前 API なら Use Case 層でこれを強制する設計に最初から組み込みます。
後回しにすると起きること: 後から権限・テナント境界を入れる作業は、新規実装ではなく既存実装全体の再点検になります。情報漏えいリスクを抱えたままユーザー数が増えると、損害賠償リスクと信頼失墜が両方発生します。
2. 課金 / 請求
無料でローンチするサービスでも、課金の入り口は最初に作っておく 方が楽です。Stripe Customer / Subscription を最初から組み込み、フラグで ON / OFF できる構造にしておく。
これをやっておくと、
- 有料化のタイミングで「課金画面を新規に作る」工程がなくなる
- 「無料トライアル → 有料」の動線をデータで追跡できる
- 解約・返金の処理が、設計段階から織り込まれる
Stripe を使う場合、Webhook の冪等性 (同じイベントが 2 回来ても壊れない設計) と、解約時のデータ取扱いポリシーは、最初の段階で決めておきます。
後回しにすると起きること: 有料化のたびに大きな改修が必要になり、課金開始のタイミングを逃します。また、Webhook の冪等性が後付けになると、二重決済・二重請求といった事故につながります。
3. 監査ログ / イベント発火
「何が起きたか」を後から追える状態を、最初から作っておきます。
- 主要な状態変更 (アカウント作成、課金、解約、退会) は append-only でイベントテーブルに記録
- Firestore なら別コレクション、SQL なら separate イベントテーブル
- Domain Event / Outbox パターンで、状態変更とイベント記録を分離する
この設計だと、
- リリース後の不具合調査が、ログから出せる
- 「何月の解約は何人だったか」のような事業 KPI を、後から集計できる
- 監視・通知・改善の土台になる
後回しにすると起きること: 過去のデータが取れないので、リリース初日からの履歴は永久に失われます。事業 KPI の集計も「今日から測る」しかできません。
4. 障害時の問い合わせ導線
ユーザーが困ったときの逃げ道がないシステムは、初期段階で離脱を増やします。
- LINE 公式アカウント、Intercom、メール、Slack 共有チャネルのいずれかを、リリース日から用意
- ヘルプセンターは Notion でよい (初期に CMS を内製する必要はない)
- 緊急時の電話番号は、サービス特性によっては必要 (BtoB 業務 SaaS、決済を扱うサービス)
初期はチャット機能を内製せず、外部 SaaS と通知で割り切る のが、運用が一番楽です。社内側の問い合わせ受け取り体制 (Slack 通知 + 当番) を整える方が、ツール選定よりも重要です。
後回しにすると起きること: 初期ユーザーが困っても声を上げる経路がなく、サイレント離脱になります。アンケートを取ってもなぜ離脱したか分かりません。
5. 利用規約 / プライバシーポリシー / 退会導線
サービスとして必須の 3 点セットです。あとから整備すると、運用しながら修正することになり、つらい領域になります。
- 利用規約 (テンプレを弁護士にレビューしてもらう)
- プライバシーポリシー (取得・利用・第三者提供を明示する)
- 退会導線 (個人情報削除の運用も決めておく)
特定商取引法に基づく表示、運営会社の情報、お問い合わせ窓口は、初期から固定ページとして用意します。SaaS で B2C を扱うなら、ここを軽視すると後でリスクになります。
後回しにすると起きること: 法令違反のリスク、ユーザー対応のクレーム、退会したいユーザーから「退会できない」と SNS で書かれる、といった事故につながります。
最初は作らない 4 つ: 立ち上がってから足す
逆に、MVP 段階で作りがちだが、後回しにしてよい 機能を 4 つ整理します。
| 後回しにしてよい機能 | 理由 |
|---|---|
| SNS シェア / 招待 UI を作り込む | トラフィックが立つまでは機能を作っても回らない。LP のシェアボタンで十分 |
| アプリ内チャット | CS の運用負荷が一気に上がる。LINE / Intercom / メールで初期はスケールする |
| リッチな管理画面 | 初期は社内オペは Excel・Sheets・Notion で十分。本当に必要な項目を見極めてから足す |
| 凝った A/B テスト基盤 | トラフィックが少ない段階の A/B テストはノイズで答えが出ない。PostHog / GA4 の単純な分岐で十分 |
これらは「いつか作るかもしれない」けれども、MVP 段階で時間と予算を割く優先度ではありません。
ここまでで MVP のスコープ感が見えてきたら、次は「自社の検証仮説に合わせて、Must / Manual / Later / Never で機能を仕分ける」作業に入ります。min's では、MVP の構想段階での壁打ちを無料で行っています。
AI で「作れる」部分と、AI で「決められない」部分
ここまで「何を作るか」を整理しました。次に、その作るべきものの中で、AI でどこまで安くなるか、を分けます。
| 工程 | AI で短縮 | 備考 |
|---|---|---|
| 認証ライブラリの組み込み | ◎ | Clerk・Supabase Auth・Auth0 はテンプレ通り |
| データモデルの初期設計 | △ | たたき台は AI で出る、整合性判断は人間 |
| CRUD 画面の実装 | ◎ | 大幅に短縮 |
| Stripe 連携 | ○ | Webhook の冪等性は要レビュー |
| 集計ロジック | △ | 数字の責任は人間が握る |
| メール・通知テンプレ | ◎ | コピーライティングまで AI でいける |
| エラー監視の組み込み | ○ | Sentry の SDK は AI で速い |
| 業務要件の言語化 | × | これは人間が決める |
| ユーザー像と KPI 設計 | × | 仮説は経営判断 |
| プライバシー・法務観点 | × | 専門家の判断が必要 |
「AI で全部作る」と決めてしまうと、上の表の右側 (×) の領域に判断を入れずに進んでしまい、リリース後に詰まります。「決められない部分にだけ、人間の時間を集中投入する」 のが、AI ネイティブ MVP の基本姿勢です。
OpenAI が紹介している事例でも、Codex がデータアナリスト・マーケター・コーポレートファイナンスの仕事で活用されているのは、「定型的な作業を任せて、判断と方針決定に人間の時間を移している」点が共通しています (Codex for every role, tool, and workflow / OpenAI)。MVP の作り方も同じ構造で考えるとブレません。
リリース前に見るべき KPI と品質ライン
MVP は「動いた」だけでは不十分です。何をもって成功とするか を、リリース前に決めておく必要があります。
KPI の最小セット
事業フェーズによって変わりますが、最初の 90 日で見るべき KPI を、toB と toC に分けて整理します。
| 区分 | toB SaaS | toC サービス |
|---|---|---|
| アクティベーション | 招待した会社のうち、何社が最初の主要操作を完了したか | 初回登録から主要アクションまでの完了率 |
| 利用継続 | 7 日後・30 日後にログインしている割合 | Day 7 / Day 30 Retention |
| 価値創出 | 業務削減時間 (お客さんから報告ベース) | Referral / 既存ユーザー紹介率 |
| 機能利用 | どの機能がどれくらい使われているか | 主要機能の利用分布 |
| 課題シグナル | お問い合わせ率と内容 | 解約理由 (定性的に集める) |
KPI を決めると、自動的にログ設計と画面設計が変わります。「Day 30 Retention を見たい」と言った瞬間に、ユーザーごとの操作履歴を残す必要があることが決まります。だからこそ、KPI の検討は実装よりも前に終わらせるのが理想です。
品質ラインの最小セット
MVP の品質を「どこまで上げるか」も決めておきます。
- ログイン・課金・主要機能 (例: 予約、申込) は、自動テストで保護する
- 画面の崩れは、主要なブラウザ (Chrome 最新版、Safari 最新版) でだけ確認
- パフォーマンスは、主要ページの初回ロード 3 秒以内が目安
- セキュリティは、SQL インジェクション・XSS・認証バイパスは少なくとも防ぐ
- アクセシビリティは、最低限のキーボード操作と alt 属性くらいから
品質ラインを決めずに着手すると、「テストをどこまで書くか」「どこまで動作確認するか」が個人の感覚に依存して、見積もりがブレます。逆に、最初に「ここまで」と決めておけば、AI に書かせるテストの範囲も決まります。
投資家に見せる前に整えるポイント
MVP を投資家に見せる予定があるなら、デモ映えだけでなく、次の観点を整えておきます。
1. 仮説と検証結果が、1 ページで言える
「誰が、なぜ、いくら払うのか」が 1 段落で説明できる。MVP のスクリーンショットと、それを使った数値 (たとえ少数でも) を添えられる。
2. 利用ログが定量的に見える
「PoC で 3 社に使ってもらった」だけでなく、3 社が どの機能を、何回使ったか を画面で見せられる。Mixpanel、PostHog、Amplitude のような基本的な分析ツールを入れて、数字を出せる状態にしておく。
3. 継続利用の兆候がある
Day 7 / Day 30 で戻ってきているユーザーの数を、絶対値で示せる。少数でいいので、「使い続けたい」と言っているユーザーの言葉を、定性で並べられる。
4. データと認証の最低ラインがクリアできている
投資家は「これ、技術 DD したら詰みませんか」を内心気にしています。
- 認証・テナント分離が、最低限の設計になっている
- 個人情報の扱いが、規約として整っている
- 主要なバグが、リリース後 30 日で修正されている
- 障害時の対応経路が、ユーザー向けに用意されている
AI で作っているからダメ、ということはありません。むしろ「速く仮説検証できる」点はプラスに評価されます。作り方ではなく、運用の最低ラインが揃っているか が見られるポイントです。
min's の MVP 開発スタイル
min's では、MVP の開発を「全部発注」ではなく、創業チームと一緒に進める形を取ることが多いです。具体的には、
- 構想 (1〜2 週間): 仮説、ユーザー、KPI、最小機能セットを定義
- 設計 (1〜2 週間): データモデル、画面遷移、認証・権限、課金導線の設計
- 実装 (4〜8 週間): AI を併用しながら、Must の機能だけ実装
- 改善 (継続): ユーザーから出た要望と、KPI を見ながら、月次で改善
予算感のレンジは、構想 + 設計 + 初期実装で 200〜400 万円が典型的です。これに継続支援を月 30〜100 万円で並走する形が多くあります。AI を組み込んでいる分、過去より少ない人月で動かせるようになっています。
MVP の構想段階から相談したい方へ
min's では、Idea / 構想段階の壁打ち、MVP スコープの整理、AI を組み込んだ MVP 開発、リリース後の改善まで支援しています。
以下のような状態であれば、ご相談ください。
- 検証したい仮説はあるが、何を作るか整理しきれていない
- 既存業務を SaaS 化したいが、最小スコープが分からない
- AI を組み込んだ機能を MVP に入れたい
- 投資家に見せる前に、MVP の品質ラインを整えたい
- リリース後の KPI 設計から相談したい
仕様が固まっていない段階で来ていただけると、最も価値が出ます。
次に読む記事
参考
- The founder's playbook / Anthropic — AI ネイティブ・スタートアップの Idea / MVP / Launch / Scale フレーム、技術負債とセキュリティ実装の段階差
- Codex for every role, tool, and workflow / OpenAI — Codex の活用が開発者を超えて、アナリスト・マーケター・コーポレートファイナンスにまで広がっている事例