PoC と MVP と本番開発の違い
目的が違えば、必要な品質・予算・期間・成果物も変わる。
この記事の結論
- PoC は技術検証、MVP は事業仮説検証、本番開発 は継続運用を前提にした開発。目的が違うので、必要な品質・予算・期間も全部違います。
- 混同すると、PoC を本番投入する / MVP を作り込みすぎる / 本番開発を検証目的で曖昧にする という典型的な失敗が起きます。
- PoC は数日〜数週間、MVP は 4〜12 週間、本番開発は 12 週間以上、という期間感が現実的な目安です。
- 開発会社に相談すべきタイミングは、「どの段階に、いま自社があるか」が決まってから です。
「PoC を作ってください」「MVP を作りたいです」「本番システムを作って」
これらは似て見えますが、目的も成果物もまったく違います。発注時に区別がついていないと、「PoC のつもりで作ったものを本番で使おうとして詰まる」「MVP に本番品質を求めて予算が膨らむ」 という典型的な失敗が起きます。
この記事では、PoC / MVP / 本番開発の違いを、目的・成果物・品質・期間・予算で整理します。
PoC (Proof of Concept) とは
PoC は「概念実証」と訳されます。ある技術や仕組みが、想定通り動くかを確かめる ための実装です。
目的
「この技術で、この問題が解決できるか」を確かめる。
例:
- AI モデルで、画像から不良品を検出できるか
- 既存システムと新 API が接続できるか
- ライブラリの組み合わせで、想定の性能が出るか
- 業務システムに音声入力を組み込めるか
成果物
- 動くプロトタイプ (1〜2 機能だけ)
- 検証結果のレポート
- 次フェーズ (MVP / 本番) への提言
品質ライン
- 動けば OK
- セキュリティ最低限 (社内利用前提)
- テストは限定的
- UI は雑でいい
- スケーラビリティは不問
期間と予算
- 期間: 1 週間〜1 ヶ月
- 予算: 30〜200 万円
失敗パターン
- PoC で動いたものを、そのまま本番に出してしまう
- PoC の結果を活かさず、本番で同じ検証をやり直す
MVP (Minimum Viable Product) とは
MVP は「最小限の実行可能なプロダクト」です。事業として成立するか を確かめる最小のシステム。
目的
「この事業が成立するか」を、最小限のシステムで確かめる。
例:
- 月 1 万円払うユーザーが、5 社獲得できるか
- リリース後 30 日の継続率が 30% を超えるか
- 業務削減時間が、想定通り出るか
成果物
- 顧客が使える状態の最小システム
- KPI 計測の仕組み
- 限定的なユーザー (5〜20 名 / 社) への提供
品質ライン
- 顧客の業務に組み込める最低限の安定性
- 認証・テナント分離は必須
- 課金は最初から組み込む
- 主要フローの自動テストはあり
- 管理画面は Excel 代用で OK
期間と予算
- 期間: 4〜12 週間
- 予算: 200〜800 万円
失敗パターン
- MVP に本番品質を求めて、予算が膨らむ
- リリースしたが KPI を測れず、評価できない
- 仮説が曖昧なまま機能を増やしすぎる
詳しくは AI-native MVP の作り方 で展開しています。
本番開発とは
本番開発は 継続運用を前提にしたシステム開発 です。
目的
「事業を成長させるための土台」を作る。
例:
- 複数顧客でスケールできる業務 SaaS
- 規模が拡大しても運用が回るシステム
- 内製チームに引き継げる品質のコード
成果物
- スケール可能なシステム
- 運用 Runbook、監視、障害対応設計
- 内製化を見据えたドキュメントとテスト
- セキュリティレビュー結果
品質ライン
- 同時利用の整合性が保たれる
- 認証・権限・テナント・監査ログがすべて揃う
- 自動テスト、CI、デプロイ、ロールバックが整備
- セキュリティスキャン済み
- 監視・通知の経路が確立
期間と予算
- 期間: 12 週間以上 (機能数による)
- 予算: 500 万〜数千万円
失敗パターン
- 本番開発として発注したが、検証目的が曖昧 (事業仮説が曖昧)
- リリース後の運用設計が抜けている
- 内製化のドキュメントが作られない
OpenAI が AWS 提携で強調しているのも、エンタープライズで AI を本番利用するには既存のセキュリティ・コンプライアンス・ガバナンスフローに乗ることが鍵だ、という点です (OpenAI frontier models and Codex on AWS / OpenAI)。本番開発は、技術以上に 運用とガバナンスの設計 が中心になります。
ここまでで「自社はどの段階に進むべきか」が見えてきたら、構想段階の壁打ちから始めるのが現実的です。
3 つを並べて比較
| 観点 | PoC | MVP | 本番開発 |
|---|---|---|---|
| 目的 | 技術検証 | 事業仮説検証 | 継続運用 |
| ユーザー | 社内 (検証担当) | 限定顧客 (5〜20) | 全顧客 |
| 品質 | 動けば OK | 業務に組み込める | スケール対応 |
| 期間 | 1 週間〜1 ヶ月 | 4〜12 週間 | 12 週間以上 |
| 予算 | 30〜200 万円 | 200〜800 万円 | 500 万〜数千万円 |
| 成果物 | プロトタイプ + レポート | 顧客が使えるシステム | スケール可能なシステム |
| 失敗条件 | 技術が動かない | KPI に届かない | 運用が回らない |
| 次のステップ | MVP に進む or 中止 | 本番開発 or pivot | 改善 / スケール |
Anthropic の創業者向けプレイブックでも、AI ネイティブ・スタートアップは Idea / MVP / Launch / Scale の段階ごとに、必要な実装と設計の優先順位が変わると整理されています (The founder's playbook / Anthropic)。同じことが、PoC / MVP / 本番開発の判断にも当てはまります。
どの段階で開発会社に相談すべきか
「いつ相談したらいいですか」という質問を多く受けます。答えは 「PoC の前」 からです。
構想段階 (PoC 前)
- 何を検証すべきかが固まっていない
- 技術的な選択肢を相談したい
- 「PoC で十分か、MVP に進むべきか」を判断したい
ここで相談すると、「そもそも PoC が必要か」 から議論できます。技術が枯れていて検証不要なら、PoC を飛ばして MVP に直行できることも多い。
PoC 段階
- 検証したい技術が複数あって、どれから着手すべきか
- PoC の合格基準をどう設計するか
- PoC の結果を MVP につなげる方法
MVP 段階
- 仮説を絞れない
- スコープを Must / Manual / Later / Never で仕分けたい
- 限定リリースの設計を相談したい
本番開発段階
- MVP で得た学びを、本番システムにどう反映するか
- スケール対応、セキュリティ、運用設計
- 内製化への引き継ぎ計画
最も価値が出るのは「構想段階」での相談 です。「PoC のつもりで本番を作ってしまう」「MVP を本番品質で作って予算が膨らむ」というよくある失敗を、初期段階で防げます。
min's の支援スタイル
min's では、PoC / MVP / 本番開発のいずれの段階でも支援できる体制を取っています。
PoC 支援
- 期間 1〜4 週間
- 費用 30〜200 万円
- 成果物: プロトタイプ + 検証レポート + 次フェーズ提案
MVP 支援
- 期間 4〜12 週間
- 費用 200〜800 万円
- 成果物: 限定顧客向けシステム + KPI 計測
本番開発支援
- 期間 12 週間以上
- 費用 500 万〜数千万円
- 成果物: スケール可能なシステム + 運用設計
各段階の終わりに、次フェーズに進むかどうかを判断する場 を設けます。事業の数字が想定通りなら次へ、想定外なら pivot を含めて判断、というステップごとの意思決定が、ムダな投資を抑えます。
自社の段階に合った開発の進め方を相談したい方へ
min's では、PoC / MVP / 本番開発のどの段階の相談にも対応しています。
以下のような状態であれば、ご相談ください。
-
PoC を作るべきか、いきなり MVP に進むべきか迷っている
-
MVP に何を入れて、何を入れないか整理したい
-
MVP から本番開発への移行を相談したい
-
AI を組み込んだ PoC / MVP の進め方を相談したい
次に読む記事
参考
- The founder's playbook / Anthropic — AI ネイティブ・スタートアップの Idea / MVP / Launch / Scale フレーム
- OpenAI frontier models and Codex on AWS / OpenAI — エンタープライズ AI 導入における既存ガバナンスとの整合