「MVPを作りたいので見積もりをお願いします」と依頼して返ってきた金額が、想定の3倍だった——新規事業や社内DXの初期段階で、頻繁に起きる出来事です。
依頼した側は「最小限のものを試しに作る」つもりでした。見積もった側は、提示された要件を実現するために必要な工数を積み上げました。どちらも誠実に対応しているのに、金額の感覚が合いません。原因は「最小限」という言葉が、両者の間でまったく違うものを指していることにあります。
本記事では、MVPの費用がなぜ見積もりにくいのかを分解し、費用を左右する変数を整理します。そのうえで、多くの記事が触れていない「予算をどう決めるか」——つまりいくらまでなら払ってよいのかを判断する方法を扱います。相場を提示するのではなく、自社のケースで金額を決められる状態を目指します。
目次
発注側が「最小限」と言うとき、多くの場合それは費用と期間の話です。安く、早く、試したい。一方、受注側が要件を読むときに見ているのは実現すべき機能の範囲です。
この二つは連動しません。「顧客が申し込みできて、管理者が一覧を見られるだけ」という一見シンプルな要件でも、申込内容の確認メール、重複申込の判定、管理者のログイン、データの書き出しといった付随機能が必要になります。発注側は本体だけを数え、受注側は付随機能まで含めて数える。ここで金額の感覚が3倍ずれます。
見積もりを比較するために機能一覧を作る発注担当者は多いのですが、MVPにおいてこの方法はあまり機能しません。同じ「申込フォーム」でも、入力項目が5つか30か、条件分岐があるか、既存システムに連携するかで工数が桁違いになるためです。
より本質的には、MVPの費用は作るものの規模ではなく、検証したいことの複雑さで決まります。次のセクションで、その変数を整理します。
最も影響が大きい変数です。仮説が1つなら、それを確かめるために必要な最小の画面を作れば済みます。仮説が3つあると、それぞれを検証できる状態にする必要があり、費用は単純に3倍にはならず、それ以上に膨らみます。機能同士の組み合わせを考慮する必要が出るためです。
実務でよくあるのは、企画書に検証したいことが列挙されているケースです。「需要があるか」「使い続けるか」「対価を払うか」「既存業務と両立するか」——すべて重要ですが、同時に検証しようとした瞬間、それはMVPではなく製品開発になります。費用を下げる最も効果的な方法は、仮説を1つに絞ることです。
見落とされやすい変数です。ダミーデータで動かすだけなら、データ構造は単純で構いません。実際の業務データを入れる場合、表記の揺れ、欠損、想定外の値への対処が必要になり、工数が大きく増えます。
ただしこれは削ってよい工数ではありません。実データを入れた瞬間に噴出する問題こそが、本番化の要件だからです。ダミーで済ませたMVPは安く作れますが、検証としての価値が大きく下がります。費用を抑えるなら、データの量を絞ってください。全社の全データではなく、1部門の1か月分で足ります。
公開範囲は費用に直結します。社内の限られたメンバーだけが使うなら、認証も権限設計も最小限で済みます。社外のユーザーに出す場合、認証、権限設計、アクセス制御の点検、個人情報の取り扱いが必要になり、工数が階段状に増えます。
とくにデータベースのアクセス制御は、設定していなくてもアプリは正常に動くため、点検工数を削ると事故につながります。公開範囲を広げる判断は、費用を数十パーセント増やす判断だと理解してください。検証の目的上、本当に社外に出す必要があるのかを先に確認する価値があります。
最後の変数は、既存システムとの連携です。これも階段状に費用が変わる項目で、しかも相手側の事情に左右されるため見積もりの精度が下がります。
連携先のAPI仕様が公開されているか、テスト環境があるか、社内の別部門の承認が必要か——これらは着手してみないと分からないことが多く、見積もり時点では不確実性を織り込んだ金額になります。結果として、連携を含めた瞬間に金額が跳ね上がります。
MVPの段階では、連携を外して手動のデータ取り込みで代替できないかを必ず検討してください。1日1回のCSV取り込みで検証が成立するなら、費用も期間も大きく下がります。連携の自動化は、検証が成功して本番化する段階で実装すれば十分です。
ここが本記事の中心です。多くの企業はMVPの予算を「これくらいなら出せる」という感覚で決めています。しかし本来、検証への投資額はその検証によって回避できる損失の大きさから逆算すべきです。
考え方はこうです。仮に検証せずに本番開発へ進み、その判断が間違っていた場合、失う金額はいくらか。開発費、投入する人件費、機会損失を合計します。その金額の一部を払って判断の精度を上げるのが、MVPへの投資の本質です。
この逆算をすると、判断が変わることがあります。数千万円規模の投資判断を控えているなら、その一部を検証に使う合理性は高い。逆に、失敗しても数十万円の損失で済む案件なら、検証にそれ以上かけるのは本末転倒です。作らずに決めてしまうほうが合理的な場面もあります。
逆算の結果として、「MVPを作らない」という結論が出ることがあります。これは正しい判断です。
判断の目安を整理します。以下は絶対的な基準ではなく、社内で議論するための出発点として使ってください。
| 状況 | MVPへの投資判断 |
|---|---|
| 誤った場合の損失が大きく、判断材料が乏しい | 検証する価値が高い。相応の予算を確保する |
| 誤った場合の損失が小さい | 検証費用が損失を上回らないか確認する |
| すでに判断材料が揃っている | 作らずに決める。検証は追認にしかならない |
| 結果にかかわらず実施が決まっている | 作らない。検証の意味がない |
最終行は珍しくありません。経営判断としてすでに実施が決まっている案件で、形式的にMVPを作る。この場合、費用は検証ではなく手続きのために支払われています。そうと分かったうえで実施するなら問題ありませんが、検証だと思い込んでいると、結果が悪くても実施される矛盾に直面します。
予算の上限が決まったら、その範囲に収める工夫が必要になります。効果の大きい順に整理します。上に行くほど、発注前に自社だけで実行できる施策です。
| 方法 | 効果 | 注意点 |
|---|---|---|
| 仮説を1つに絞る | 最大。検証範囲が決まり、作るものが確定する | 絞れないなら企画が固まっていない |
| 既存システム連携を外す | 大。手動取り込みで代替する | 連携自体が仮説なら外せない |
| 公開範囲を社内に限定する | 大。認証と権限設計が最小限で済む | 社外の反応が仮説なら限定できない |
| データ量を絞る | 中。1部門の1か月分で十分な場合が多い | データの種類は減らさない |
| デザインを作り込まない | 中。標準の見た目で機能検証は可能 | 体験価値が仮説なら削れない |
| 管理画面を作らない | 小〜中。初期は手作業で運用する | 運用者の工数と引き換え |
各行の注意点に共通するのは、「その要素自体が検証対象なら削れない」という点です。デザインの良し悪しが受容性を左右する仮説なら、デザインは削れません。何を削れるかは、仮説が何かによって決まります。ここでも起点は仮説の明確さです。
費用を最も下げる方法は、アプリを作らないことです。検証したい仮説によっては、これが可能です。
需要そのものを確かめたいなら、説明ページと申込フォームだけを公開して反応を見る方法があります。体験価値を確かめたいなら、自動化されているように見せて裏側は人が手作業で処理する方法が使えます。「AIが自動で見積書を作る」という仮説なら、初期はフォームで受け付けて担当者が手で作って返せば、AI実装ゼロのまま体験価値を検証できます。
業務フローが回るかを確かめたいだけなら、既存の汎用ツールを組み合わせて運用してみる方法もあります。すでに全社ライセンスがあるなら追加費用はほぼゼロです。ここで運用が回るなら、そもそも専用アプリを作る必要がないかもしれません。「作らない」という結論もMVPの正しい成果です。
MVPを誰がどう作るかによって、費用の性質が変わります。金額の大小だけでなく、固定費か変動費か、社内工数がどれだけ発生するかを含めて比較してください。
AIアプリビルダーを使う場合の費用感を、公式価格ページの実数で示します。LovableのProプランは月25ドルで100クレジット、BoltのProプランは月25ドル、v0のPlusプランは1ユーザーあたり月30ドルです。Lovableの公式ドキュメントによれば、コードを変更するBuildモードの消費は作業量に応じて0.50〜2.00クレジットが目安とされており、単純計算では100クレジットで50〜200回程度の指示に相当します。
この数字が示すのは、ツール代そのものはMVPの費用の主要因ではないということです。月数千円規模であり、支配的なのは人件費です。内製なら社内担当者の工数、外注なら委託費。内製が安く見える比較表の多くは、社内人件費を計上していません。
既存のノーコード基盤で作る場合は、ユーザー課金が中心になります。kintoneのスタンダードコースは1ユーザーあたり月1,800円（税抜、最小10ユーザー）です。MVPの検証は限られた人数で行うため、この規模なら大きな負担にはなりません。
複数社から見積もりを取る場合、金額を比較する前に前提を揃える必要があります。前提が違う見積もりを並べても、金額差は「安さ」ではなく「解釈の違い」を意味するだけです。
最低限、次を書いた1枚を作って全社に同じものを渡してください。この1枚がないまま相見積もりを取ると、比較になりません。
6番を明示できるかが、発注側の準備度を示します。作るものの一覧は誰でも書けますが、作らないものを決めるには仮説が固まっている必要があるためです。
また契約形態にも注意してください。MVPは要件が動くことを前提とした工程です。成果物の完成を約束する契約で発注すると、変更のたびに手続きが必要になります。IPAの「情報システム・モデル取引・契約書」でも工程の性質に応じた契約形態の使い分けが示されており、探索的な工程は準委任が適しています。
「最小限」の解釈がずれている可能性が高いです。発注側は費用と期間を、受注側は機能の範囲を見ています。本体機能だけを数えていても、確認メール、重複判定、ログイン、データ書き出しといった付随機能が積み上がります。「作らないもの」を明示すると差が縮まります。
あります。誤った場合の損失が小さい場合、すでに判断材料が揃っている場合、そして結果にかかわらず実施が決まっている場合です。とくに最後のケースでは、費用は検証ではなく手続きのために支払われることになります。
安くはなりますが、検証としての価値が大きく下がります。実データを入れた瞬間に噴出する問題こそが本番化の要件だからです。費用を抑えるなら、データの量を絞ってください（1部門の1か月分など）。種類を減らすのは避けます。
仮説によっては可能です。需要を確かめたいなら説明ページと申込フォームだけで反応を見る、体験価値を確かめたいなら裏側を人が手作業で処理する、業務フローを確かめたいなら既存の汎用ツールを組み合わせる。「作らない」という結論もMVPの正しい成果です。
AIアプリビルダーはProプラン相当で月25〜30ドル程度です。既存のノーコード基盤はユーザー課金が中心で、kintoneのスタンダードコースは1ユーザーあたり月1,800円（税抜、最小10ユーザー）です。ツール代はMVP費用の主要因ではなく、支配的なのは人件費です。
比較の仕方によります。内製が安く見える比較表の多くは、社内担当者の人件費を計上していません。金額の大小だけでなく、固定費か変動費か、社内工数がどれだけ発生するかを含めて比較してください。
前提を揃えた1枚を作り、全社に同じものを渡してください。仮説、成功判定基準、使うデータ、公開範囲、連携の有無、そして「作らないもの」の6点です。前提が違う見積もりを並べても、金額差は解釈の違いを意味するだけです。