MVP開発とは？PoCとの違い・費用相場・会社の選び方を解説

MVP開発とは、事業の仮説を確かめるために、学びを得られる最小限の製品を作って実際の顧客に使ってもらう進め方です。PoCが「技術的に実現できるか」を確かめるのに対し、MVPは「顧客が使い続けるか、お金を払うか」を確かめます。費用は開発会社の公開値で見ると、小規模な構成で100万〜300万円前後、決済や外部連携が入ると数百万円から1,000万円を超える範囲まで上がります。機能の数に加えて、決済・外部連携・複数の利用者区分が入るかどうかで、費用の段が一段上がるのが各社に共通する傾向です。

この記事は、新規事業の担当者やスタートアップの創業者に向けて、「何を作り、何を作らないか」「何を見て続けるかやめるかを決めるか」「いくらかかり、誰にどう頼むか」を判断するための表を、出典つきでまとめたものです。費用の細かい試算方法よりも、見積もりを取る前に社内で決めておくべきことに重心を置いています。

本記事の情報について: MVPの定義と指標の考え方はEric Ries氏の公開記事、契約の考え方は情報処理推進機構（IPA）のアジャイル開発版モデル契約、機能の優先度付けはAgile Business ConsortiumのDSDMの解説に基づいています。費用は2026年10月1日に開発会社などの公開ページで確認した目安で、特定の案件の見積もりではありません。料金は改定されることがあるため、依頼前に各社の最新の情報を確認してください。

状況別の読み分け早見表

いまの状況に合わせて、先に読む節を選んでください。

MVP開発とは

MVP開発とは、顧客について最も多くを学べる最小限の製品を作り、仮説が正しいかを実際の利用で確かめる開発の進め方です。MVPはMinimum Viable Productの略で、日本語では「実用最小限の製品」と訳されます。

この言葉を広めたEric Ries氏は、2009年の記事Minimum Viable Product: a guideで、MVPを「チームが最小の労力で、顧客についての検証された学びを最大限に集められる、新しい製品のバージョン」と定義しています。日本の公的な資料では、IPA（情報処理推進機構）がアジャイル開発版の情報システム・モデル取引・契約書の中で、「MVP開発」を実用最小限の製品を開発することと説明しています。

MVPは「小さい製品」ではなく「学ぶための最小単位」

MVPで削るのは「まだ確かめる必要のない機能」であり、確かめたい価値の中心は実際に使える品質で作ります。予算に合わせて一律に機能を減らすと、確かめたい価値の中心まで削ってしまい、リリースしても何も学べない製品になります。

Ries氏は同じ記事で、MVPは名前に反して「最小の製品を作ること」が目的ではないと念を押しています。最初の製品から何かを学ぶには、顧客と話す時間や、指標を測る仕組みに相応の手間がかかるため、MVPはむしろ余分な負担を伴うとも書いています。つまり、MVP開発の費用には「作る費用」だけでなく「学ぶ費用」が含まれます。測る仕組みのないMVPは、安く作れても学びが残りません。

期間についても誤解があります。「MVPは2週間で作るもの」という決まりはありません。Ries氏は、自身が共同創業したIMVUの最初のMVPは市場に出すまで6か月かかったと書いています。一方で、誰も欲しがらない機能に2週間をかけてしまった経験もあり、その時は検索広告で反応を見る簡単なテストで先に分かったはずだと振り返っています。適切な大きさは、確かめたい仮説によって変わるということです。

MVP開発が向く場面・向かない場面

MVP開発が向くのは、「顧客がその価値を求めているか」に不確かさが残り、その答えによって次の投資額が大きく変わる場面です。反対に、作るべきものがすでに決まっている場面では、MVPという手順はかえって遠回りになります。

Ries氏も、はっきりした困りごとを手早く解消したいだけの場合や、すぐに売却するための製品であれば、MVPは要らないと書いています。この記事では、MVPを「不確かさを減らすための投資」と捉え、不確かさが小さい案件では使わない判断も正解だと考えます。

MVP開発の進め方

MVP開発は、仮説を言葉にし、作らずに確かめられることを先に試し、残った問いのために最小限の製品を作って、事前に決めた基準で判断する、という順で進めます。各段階の詳しい判断のしかたは、この後の節で順に解説します。

1. 仮説を1文にする: 「誰が、どんな課題に、どの解決策を使い、何を払うか」を1文で書きます。複数の仮説がある場合は、外れたときに事業全体が成り立たなくなるものを最初に選びます
2. 作らずに確かめられることを先に試す: 顧客への聞き取り、申し込みページ、手作業での提供などで、作る前に答えが出る問いを片づけます（作らずに確かめる方法）
3. 技術の不確かさがあればPoCで確かめる: AIや新しい技術を使う場合は、顧客に出す前に技術が成り立つかを確かめます
4. 機能を絞り、作らないものを合意する: MoSCoWで分類し、Won't Haveの一覧を関係者で合意します（機能の絞り方）
5. 指標と判断基準を決める: 見る指標を2〜3個に絞り、続行・修正・撤退の基準と、期間・予算の上限を決めます（検証指標と続ける・やめるの基準）
6. 作って公開する: 指標を測る仕組みを、最初のリリースから入れておきます
7. 基準に照らして判断する: 期限が来たら、事前に決めた基準で続行・修正・撤退を決め、学んだことを記録します

開発の手法としては、短い期間で作って見せることを繰り返すアジャイル開発と相性が良い進め方です。アジャイル開発とスクラムの関係は、アジャイルとスクラムの違いの記事で整理しています。AIを使った開発で、どの工程が速くなりどこが速くならないかは、AI駆動開発の解説を参考にしてください。

MVP・PoC・プロトタイプの違い

MVP・PoC・プロトタイプの違いは、「何を確かめるか」です。PoCは技術的に実現できるか、プロトタイプは操作や画面の流れが伝わるか、MVPは顧客が使い続けるか・お金を払うかを確かめます。

3つとも「小さく作って試すもの」なので混同されやすいのですが、確かめる相手と、終わった後の判断が違います。発注先との打ち合わせで言葉の意味がずれると、片方は技術の検証、もう片方は顧客への提供を想定して見積もることになり、金額も期間も比べられなくなります。

順番は決まっていません。AIや新しい技術を使うサービスなら、PoCで技術が成り立つことを確かめてから、MVPで顧客の反応を見るのが自然です。技術的な不安がなければ、PoCを省いてプロトタイプやMVPから始めて構いません。AIを使った検証の進め方と合否の決め方は、AIエージェントPoCの外注ガイドで詳しく扱っています。

確かめたいことから作るものを選ぶ

作るものは、いちばん不確かな問いから逆算して選びます。下の図は、確かめたい問いごとに、PoC・プロトタイプ・作らずに確かめる方法・動くMVPのどれを選ぶかを示したものです。

PoCやプロトタイプで答えが出たら、図の次の問いに進みます。図の最後の分かれ道が、MVP開発の費用をいちばん左右します。「作らずに確かめられるか」を先に考えるだけで、開発費をかけずに答えが出る仮説がかなりあるからです。次の節で、その方法を整理します。

作らずに確かめる方法も選択肢に入れる

顧客の反応は、製品を作る前にも確かめられます。申し込みページで関心を測る、人が手作業でサービスを提供してみる、裏側を人が処理して画面だけ自動に見せる、といった方法です。開発費をかける前に、作らずに答えが出る問いを先に片づけます。

「MVP開発とは」の節で紹介した、Ries氏の「検索広告で反応を見る簡単なテスト」は、表の1行目の方法にあたります。こうした方法で「顧客は困っていない」と分かれば、開発費をかけずに方向を変えられます。反対に、使い続けてもらわないと分からない問い（毎週使うか、業務に組み込まれるか）は、動くMVPを作らないと確かめられません。

注意点として、申し込みページや事前予約で人を集める場合は、まだ提供していないことと、提供時期の見込みを利用者に正しく伝えます。存在しない機能をあるかのように見せて申し込みや支払いを受けると、信頼を損ない、取引上の問題にもなりかねません。

機能の絞り方

MVPに入れる機能は、「この機能がないと、確かめたい仮説を確かめられないか」という1つの問いで決めます。候補を並べると、どれも必要に見えるものですが、この問いに当てると多くは後回しにできます。手作業で代わりができる機能や、検証が終わってから必要になる機能は、最初のリリースには入れません。

MoSCoWで機能を4つに分ける

機能の優先度を付けるときは、MoSCoW（モスコウ）という分類が使いやすい方法です。アジャイル開発の手法DSDMを管理するAgile Business ConsortiumのMoSCoWの解説では、要件を次の4つに分けます。

• Must Have: 必ず届けると約束する最小限の要件（DSDMはMinimum Usable SubseTと呼ぶ）。DSDMの解説は「この要件を満たさなかったらどうなるか」と問い、「プロジェクトを中止する。満たさない解決策を作る意味がない」という答えになるものがMust Haveだとしています
• Should Have: 重要だが不可欠ではなく、外すと痛手でも解決策としては成り立つもの。手作業などの代わりの方法で一時的にしのげる
• Could Have: あると望ましいが重要度は低く、外したときの影響がShould Haveより小さいもの
• Won't Have this time: 今回は作らないとチームで合意したもの

DSDMの解説は、Must Haveの目安として「それがないと法令上許されない」「それがないと安全でない」「それがないと成り立つ解決策を届けられない」といった基準も挙げています。手間のかかる手作業でも代わりの方法があるなら、Must HaveではなくShould HaveかCould Haveだとしています。

同じ解説は、Must Haveの作業量を全体の60%以内に抑えることを勧めています。60%を超えると失敗の危険が生じ、例外は、見積もりが正確で、進め方をよく理解し、チームが十分に機能していて、外部要因で遅れる危険が低い、という条件をすべて満たす場合に限られるとしています。Could Haveを全体の20%程度用意しておくのも、遅れたときに削れる余白を残すためです。MVPに当てはめると、「全部Must Haveにしない」ことが、期限と予算を守る仕組みそのものになります。

機能ごとの判定表

ここでは例として、法人向けの会議室・備品の予約サービスで「総務の担当者は、予約の重複と問い合わせ対応を減らすためにお金を払うか」を確かめる場合を考えます。機能の候補をMoSCoWの問いに当てると、次のように分かれます。

この例で、Must Haveに「ログインとデータの分離」が入っている点が大事です。DSDMがMust Haveの目安に「安全でない」「法令上許されない」を挙げているとおり、実際の顧客に使ってもらう以上、セキュリティや個人情報の扱いは省けません。削るのは「便利さ」であって、「安全に使えること」ではありません。

判定に迷ったら、次の3つを順に確認します。

1. その機能がないと、確かめたい仮説の答えが出ないか。出ないならMust Have
2. 手作業や既存のツール（表計算ソフト、メール、チャット）で代わりにできるか。できるなら最初は代わりの方法で運用する
3. 検証が終わってから必要になる機能か。そうならWon't Have this timeとして、作らないことを関係者と合意しておく

3つ目の「作らないことの合意」は、スコープが広がるのを防ぐうえで特に効きます。DSDMの解説も、Won't Haveを優先度付きの要件一覧に記録しておくことで範囲が明確になり、後から非公式に紛れ込むのを防げるとしています。開発の途中で「これもあったほうがいい」という意見が出たとき、合意済みのWon't Haveの一覧があれば、検証の後に回す判断がしやすくなります。

検証指標と続ける・やめるの基準

検証指標は、結果を見て「次に何をするか」が決まるものを選びます。累計の登録者数やページの閲覧数のように、増えても次の行動が決まらない数字は、MVPの判断には使いません。

見る指標を決める

Ries氏は2009年の記事Vanity Metrics vs. Actionable Metricsで、気分は良くなるが次の行動の手がかりにならない数字を「虚栄の指標（vanity metrics）」、判断につながる数字を「行動につながる指標（actionable metrics）」と呼んで区別しました。例として、サイトの総アクセス数が1万あっても、何がその訪問をもたらし、次に何をすべきかは分からないと書いています。行動につながる指標に近づける方法として、比較実験（A/Bテスト）、顧客1人あたり・顧客の区分ごとに見る指標、利用の段階ごとの数字と、利用開始時期が同じ顧客の集団（コホート）を追う分析を挙げています。

これをMVPに当てはめると、次のように指標を選べます。

指標は、1回の検証で見るものを2〜3個に絞ります。多くの数字を並べると、都合の良い数字だけを見て「うまくいった」と判断しやすくなるためです。

続行・修正・撤退の基準を先に置く

続けるか、直すか、やめるかの基準は、MVPを公開する前に数字で決めておきます。公開後に基準を決めると、手元の結果に合わせて基準を動かしてしまい、判断になりません。

基準の数字そのものは事業によって違うため、ここでは一律の値を示しません。決めるときは「この数字を下回ったら、追加投資はしない」と言える水準を、意思決定者と事前に合意しておくことが大事です。撤退も正しい結論の1つで、MVPの費用で本格開発の大きな投資を避けられたと考えられます。

期間と予算の上限も一緒に決めます。たとえば「検証期間は8週間、追加の改修は2回まで」のように区切っておくと、「もう少し機能を足せば数字が伸びるかもしれない」という先延ばしを防げます。

検証で「続行」と判断した後は、MVPのまま顧客を増やすのではなく、本番に向けた作り直しや補強の範囲を決めます。検証のために後回しにしたShould Haveの機能、手作業で代わりにしていた業務、簡略化していた設計のうち、利用者が増えたときに問題になるものから順に手を入れます。このとき、検証で使った指標の計測は止めずに続けると、本番化した後に数字が下がったときに原因を追いやすくなります。

MVP開発の費用相場と決まり方

MVP開発の費用相場は、開発会社の公開値で見ると小規模な構成で100万〜300万円前後、決済・外部連携・複数の利用者区分が入ると数百万円から1,000万円を超える範囲です。費用は主に、関わる人数と期間で決まり、その人数と期間を押し上げるのが機能の難しさです。

TWOSTONE&Sonsも、MVP開発の費用で最も比重が高いのはエンジニアやデザイナーの人件費で、開発期間に応じて計上されると説明しています。このほか、サーバーやデータベースなどのクラウドの利用料が、利用量に応じてかかります。

開発会社が公開している費用の目安

2026年10月1日に、MVP開発の費用を自社サイトで公開している開発会社など5社の目安を確認しました。区分の名前と区切り方は各社で異なるため、各社の表現のまま並べています。

Otsumuは、このSprintについて300万〜800万円程度を検討の目安とし、機能数・外部連携・セキュリティ要件で変動するとしています。公開後も支援を続ける場合、Otsumuは月額50万〜150万円程度（税別）を参考に個別に見積もるとしています。Wurは、標準的なMVP開発の着手ラインの目安を「期間2か月〜、費用337.5万円〜」としています。表のうち税別と明記しているのはOtsumuのみで、他社の金額が税込か税別かは、各社のページで確認してください。TWOSTONE&Sonsのノーコードの金額は個人開発者やフリーランスに頼む場合の目安で、ノーコード専門の制作会社に頼む場合はそれよりやや高めになるとしています。

この表から読み取れるのは、同じ「中規模」でも上限が会社によって600万円（Wur）と800万円（Beekle）のように違うことです。区分の名前が同じでも中身の定義が違うため、他社の相場表の数字だけで見積もりの高い安いは判断できません。

費用の段が上がる条件

Beekleが機能の数で区分しているように、機能が増えれば費用は上がります。そのうえで各社の区分を並べると、次の3つが入ったところで一段上がる点が共通しています。

生成AIを組み込むMVPでは、これに加えて、回答の品質を確かめるための評価用データの準備と、利用量に応じて毎月かかるAPIの利用料も、開発費とあわせて見込んでおく必要があります。APIの利用料の試算方法は、AIエージェント開発の費用と進め方の記事で例とともに解説しています。

裏返すと、MVPの費用を抑えるいちばん確実な方法は、これら3つを最初のリリースから外せないかを検討することです。前の節の判定表で、オンライン決済を「請求書払いの申し込み」で代わりにしたのはこのためです。

一方で、費用を抑えるために削ってはいけないものもあります。実際の顧客のデータを扱う以上、ログインやデータの分離、通信の暗号化などの基本的な安全対策は、MVPでも省けません。また、Otsumuが費用の目安とは別に運用の月額を示しているように、公開後の不具合対応や問い合わせ対応にも費用がかかります。開発費だけで予算を組まず、検証期間中の運用費も見込んでおきます。

見積もりを比べる前にそろえる条件

複数社の見積もりは、前提をそろえてから比べます。前提がずれたまま比べると、ある会社は画面の試作品を、別の会社は本番に耐える製品を見積もっていて、金額が数倍違うということが起こります。

1. 確かめたい仮説と、MVPで作る範囲（Must Haveの一覧と、作らないと合意したWon't Haveの一覧）
2. 利用者区分の数と、それぞれができる操作
3. 決済・外部連携の有無と、連携先のシステム名
4. 扱うデータの種類（個人情報や取引情報を含むか）
5. 検証期間中の運用の範囲（不具合対応、問い合わせ対応、指標の計測と報告）
6. MVPのコードを本番開発でも使い続けるか、作り直す前提か

6つ目は見落とされやすい点です。Beekleは、MVPが動いた後に本番化でさらに大きな費用が出てくる「後出しの見積もり」を避けるため、MVPの段階で本番化に必要な追加費用を先に見積もると書いています。発注する側も、「MVPの後、本番化にはいくらかかる見込みか」を最初の見積もりの段階で聞いておくと、検証が成功したときの予算を早めに確保できます。

人月単価や体制から総額を自分で試算する方法は、受託開発の見積もり相場の記事で、規模別の費用と妥当性の確かめ方とあわせて解説しています。

MVP開発でよくある失敗と防ぎ方

MVP開発の失敗の多くは、作る前の決めごとが抜けていることから起こります。どれも開発の腕の問題ではなく、何を作らないか、何を見て判断するかを先に決めていれば防げるものです。

開発会社に依頼する場合も、これらの決めごとは発注側が持つものとして考えておくと、依頼の範囲がはっきりします。システム開発全体の失敗のパターンは、システム開発の失敗事例の記事で、統計とあわせて整理しています。

MVP開発会社の選び方と発注時の注意

MVP開発会社は、「作る力」よりも「何を作らないかを一緒に決められるか」と「学ぶ仕組みまで作れるか」で選びます。MVPの成否は、機能の絞り込みと指標の設計でほぼ決まるためです。

依頼先のタイプ

依頼先は大きく4つのタイプに分かれます。どのタイプが合うかは、社内に仮説を検証した経験のある担当者がいるかと、MVPの後に本番開発を誰が担うかで変わります。

前の節の表に出てくる会社では、Beekleは初回相談と完成イメージを合わせる簡易デモまでを無料で行い、実データでの検証やMVP開発から有償としています。OtsumuはPoC / MVP Sprintという、6週間を目安にした形を参考価格（税別300万円〜）として示しています。このように、検証の入口を小さく区切って提供している会社もあるため、いきなり大きな契約を結ばずに、最初の範囲を区切って依頼できるかを確認するとよいでしょう。開発会社の評価のしかたは、開発パートナーの選び方で7つの基準として整理しています。

契約形態：請負と準委任

MVP開発では、作りながら機能の追加や優先順位の変更をするため、準委任契約が基本になります。IPAのアジャイル開発版モデル契約は、あらかじめ決めた成果物の完成に対価を払う請負契約ではなく、開発会社が専門家として業務を行うこと自体に対価を払う準委任契約を前提にしています。

準委任契約では、発注側の関わり方がより重要になります。IPAのモデル契約は、プロダクトの方向性と内容に責任を持つ「プロダクトオーナー」を発注側の企業が選ぶこととし、開発チームが必要とする情報や判断を適時に提供する役割を明確にしています。IPAの同じページは、発注側がアジャイル開発の利点を生かすには、主体的で積極的な関与が必要で、相応の負担を伴うとも書いています。「準委任で頼めば開発会社が全部決めてくれる」わけではありません。

また、受発注の契約の下でアジャイル開発を行うと、偽装請負を指摘されるリスクがあるとされてきました。IPAのページは、この点について厚生労働省が2021年9月21日に疑義応答集（第3集）を公表しており、その内容を参考に進めることで懸念の解消が期待されると案内しています。契約形態ごとの責任の違いは、ラボ型開発の記事で請負・SES・内製と比べています。

最初の打ち合わせで聞くこと

最初の打ち合わせでは、開発会社がMVPを「小さく作ること」ではなく「学ぶこと」として扱っているかを確かめます。次の質問への答え方で、その会社が検証の設計まで考えているかが分かります。

1. この仮説を、作らずに確かめる方法はありますか。あるなら、開発の前に何を試すべきですか
2. 提示した機能の中で、最初のリリースから外せるものはどれですか。その理由は何ですか
3. 検証で見る指標は何がよいと考えますか。それを測る仕組みは見積もりに含まれていますか
4. 決済・外部連携・複数の利用者区分を入れた場合と外した場合で、費用と期間はどう変わりますか
5. 検証期間中の不具合対応・問い合わせ対応・指標の報告は、どこまで費用に含まれますか
6. MVPのコードは本番開発でも使い続けられますか。作り直す場合、本番化の費用はいくらくらいの見込みですか
7. 作ったコードや設計書の権利は、契約上どちらに帰属しますか。社内や別の会社に引き継ぐときに、何を受け取れますか
8. 発注側で、誰がどのくらいの時間を確保する必要がありますか

質問1と2で、すぐに機能を足す提案ばかりが返ってくる会社は、MVPの考え方が合っていない可能性があります。質問7の権利と引き継ぎは、MVPが成功した後に開発会社を変えたり内製化したりするときに効いてきます。外注と内製をどう組み合わせるかは、外注と内製の比較の記事も参考になります。

発注前チェックリスト

IPAのモデル契約には、契約を結ぶ前に発注側と開発会社の双方で確かめる「契約前チェックリスト」が用意されています。プロジェクトの目的やゴールが明確か、発注側で適切なプロダクトオーナーを選び権限を任せられるか、完了基準や品質基準が明確か、といった項目です。これにMVP特有の確認を加えると、発注前に次の項目を確かめておくと安心です。

• 確かめたい仮説を1文で説明でき、関係者の認識がそろっている
• 作らずに確かめられる問いは、すでに試したか、試す計画がある
• Must Haveの一覧と、作らないと合意したWon't Haveの一覧がある
• 見る指標が2〜3個に絞られ、続行・修正・撤退の基準が数字で決まっている
• 検証の期間と予算の上限が決まっている
• 発注側で、優先順位を決める担当者（プロダクトオーナー）と、その人が使える時間が決まっている
• 契約形態（準委任か請負か）と、作ったものの権利・引き継ぎの範囲を確認した
• MVPの後の本番化について、費用の見込みを開発会社から聞いた

提案依頼書（RFP）をまとめる場合は、RFPの書き方ガイドで項目ごとの例文を確認できます。

よくある質問

MVP開発の相談先

koromoは、事業の仮説を整理する段階から、PoC・MVPの設計と開発、公開後の改善までを支援しています。仮説はあるものの何を作らずに済ませるかを決めたい場合や、PoCの後に顧客の反応を確かめる段階へ進みたい場合、社内に引き継げる形でMVPを作りたい場合は、要件が固まる前の段階からご相談いただけます。

一方で、確かめたい問いがまだ言葉になっていない段階なら、先に顧客への聞き取りを数件行うほうが早く進みます。申し込みページやノーコードで答えが出る段階であれば、開発会社に頼まずに自社で試すことをおすすめします。そのうえで、作らないと確かめられない問いが残ったときに、範囲の決め方からご相談ください。