プロトタイプとMVPの違いとは？投資家に見せる前に実装しておくべき「非機能要件」リスト

スタートアップの現場で「MVPができました」と言われて内容を確認すると、実際にはプロトタイプだったというケースが頻繁にある。この混同は単なる言葉の問題ではなく、投資家への提示タイミングやユーザーテストの進め方に直結する実務上の問題だ。

プロトタイプとMVPを明確に区別する

プロトタイプとは、アイデアの検証装置だ。「こういうUIで、こういう操作をする」というコンセプトを確認するための試作品。データが実際に保存されなくても、操作の一部がモックでも、見た目がそれっぽければ目的を達成できる。社内メンバーや少数のヒアリング対象者に見せるためのものだ。

**MVP（Minimum Viable Product）**は、実際のユーザーが継続して使えるプロダクトだ。「最小限」という言葉が付くが、機能の少なさを意味するのであって、品質の低さを許容するものではない。本番環境で動作し、データが安全に保存され、何百人が使っても壊れないことが前提になる。

日本のスタートアップコミュニティでは、この2つが混在して使われがちだ。「MVPを投資家に見せる」と言いながら実態はFigmaのプロトタイプだったり、逆に「まだプロトタイプなので」と言いながら実際に課金ユーザーがいる、という状況が起きる。

2つを8つの軸で比較する

この表を見ると、プロトタイプとMVPの間には「見た目の差」ではなく「実装の深さ」の差があることがわかる。

投資家が実際に何を見るか

エンジェル投資家やシードVCがデモを見る際、UI/UXの美しさより先に確認するポイントがある。

「実際のユーザーデータがあるか」——本番環境で動いているプロダクトなのか、それともデモ用のデータなのかは、数分で見抜かれる。URLのドメイン、ログイン方法、エラー時の挙動で判断できる。

「他のユーザーのデータを見られないか」——テクニカルなデューデリジェンスの担当者は、ログインしたまま別のユーザーIDのURLを叩いてみることがある。データが取れたら一発アウトだ。

「サービスがいつ落ちているかわかるか」——監視や通知の仕組みがないプロダクトは、「障害が起きてもわからない」状態だ。事業として運営する意識が問われる。

つまり投資家のデューデリジェンスは、技術的な非機能要件が意識されているかどうかの確認でもある。

実装しておくべき4つの非機能要件

1. 堅牢な認証

AIが省略する理由： Bolt.newやLovableが生成するコードは、認証フローを簡略化しがちだ。特にSupabaseを使う場合、RLSが無効のままテーブルを作ることがある。

具体的な実装： Supabase + Clerkで認証を作る場合、RLSポリシーをゼロから書く必要がある。最低限、auth.uid() = user_id という条件でユーザーが自分のデータにしかアクセスできないポリシーを全テーブルに適用する。

-- usersテーブルのRLSポリシー例
CREATE POLICY "Users can only see own data"
ON users FOR ALL
USING (auth.uid() = id);

実装時間の目安： 1〜2日（既存コードへのRLS追加は、テーブル数に比例して増える）

2. データの永続化とバックアップ

AIが省略する理由： デモ段階ではデータが消えても誰も困らない。でも本番に移した後にDBが壊れると、ユーザーの信頼を一瞬で失う。

具体的な実装： Supabaseは有料プランでPoint-in-Time Recovery（PITR）が使える。最低限、Proプラン（月$25〜）に上げてPITRを有効にし、バックアップからの復元手順を一度テストしておく。RTO（復旧目標時間）とRPO（データ損失許容量）を明示しておくこと。

実装時間の目安： 1日（設定自体は数時間、復元テストを含めると1日）

3. エラーログ監視

AIが省略する理由： エラー処理は「動かないときにわかれば十分」という思考でスキップされやすい。でも本番では「何が起きているかわからない」状態が最も危険だ。

具体的な実装： Sentryの無料プランを導入するだけで、フロントエンドとバックエンドのエラーをSlackやメールに通知できる。Next.jsへの組み込みは30分で完了する。

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

これだけで、ユーザーが白い画面を見た瞬間に開発者が通知を受け取れるようになる。

実装時間の目安： 半日〜1日

4. 利用規約・プライバシーポリシー

AIが省略する理由： コードではないため、AIツールの守備範囲外だ。でも個人情報を収集する時点で、プライバシーポリシーなしの運営は法的リスクを伴う。

具体的な実装： 最低限、個人情報保護法に対応したプライバシーポリシーのテンプレートを用意し、サービス内からリンクを張る。弁護士監修を受けるのが理想だが、初期フェーズではプライバシーポリシー生成ツール（iubenda等）で対応する選択肢もある。

実装時間の目安： 1〜2日（法的レビューを含めると1〜2週間）

投資家デモの前日に確認する10項目

最後に、デモ前日のチェックリストをまとめる。

1. 本番URLで動作することを確認した
2. テストアカウントでログインできる
3. 別のユーザーIDのデータが見えないことを確認した
4. フォームに不正な入力を入れてもエラーなく処理される
5. Sentryまたは同等のエラー監視が有効になっている
6. バックアップが有効になっている
7. プライバシーポリシーのページが存在する
8. HTTPS接続になっている
9. 環境変数にAPIキーがハードコードされていない
10. 管理者アカウントのパスワードがデフォルトのままになっていない

この10項目が揃っていないデモは、プロトタイプだ。投資家に「本番MVPです」として提示するのは避けた方がいい。逆にこれが揃っていれば、技術的な信頼性という面では最低ラインをクリアしている。