AI 時代に MVP はまだ必要か？2.11 億行のコードが示した手戻り率 3.3% → 7.1%
アイデアを AI に投げると、十回のうち八回は、返ってくる第一声が「まず実用最小限の版を作りましょう」だ。
判断のように聞こえるが、これは記憶である。Agile Manifesto は 2001 年、『The Lean Startup』は 2011 年のもので、この二つとそこから派生した何十万本ものブログ記事、講座、事後検証が、すべて AI の学習データに入っている。AI が反復を勧めるのは、自分の勘定を計算したからではない。
計算しているのは人間の勘定だ。そしてこの二枚の請求書は、構造がちょうど逆を向いている。
MVP が成り立つ四つの前提、今日残っているのは三つ
反復は自然法則ではない。ある具体的な制約の下での最適解である。その制約はこうだ。
- コードを書くのは遅く、高い。 一つの機能が、理解できた状態から動く状態になるまで人日単位かかる。
- 直すのは書くより高い。 直すにはまず読まねばならず、読むには他人（あるいは三か月前の自分）の頭の中に入り直さねばならない。
- 要求は進める過程で精度が上がる。 ユーザーは実物を見てはじめて自分が何を欲しいか分かるので、早く見せることに利がある。
- 決定的な一つ：粗い実装と完全な実装のあいだに、大きなコスト差がある。
最後の一つが MVP の経済的な地盤だ。とりあえず localStorage に置く、とりあえず権限は作らない、とりあえず設定を数個べた書きする——そうして浮いた数週間は本物であり、それを仮説検証に回すのは本当に割の良い取引だった。
四つのうち三つは今日も成立する。四つ目が消えた。
localStorage と PostgreSQL、AI の手では数分差
V2EX にこれを最も端的に言い当てた投稿がある（t/1216691、題は「AI コーディング時代に MVP 思考はもう効かないのか？」）。投稿者の言葉はこうだ。Cursor に「localStorage でデータを保存」と説明するのと「PostgreSQL にコネクションプールを付けて」と説明するのとで、生成時間は数分しか変わらない。
コストが同じなら、なぜ簡易版を作るのか。
この一文で地盤の半分が抜ける。浮くのはもはや数週間ではなく数分であり、その代わりに背負い込むもの——差し替えられる運命のストレージ層、それを前提に書かれた一群の呼び出し、やり直すことになる移行——は一つも減っていない。
粗いことはもう安くない。ただ不完全なだけだ。
AI の請求書：主体はタスクではなく文脈
地盤のもう半分はコスト構造のところで崩れる。この層のほうが見えにくい。
agentic なタスクを一回走らせるとき、入力トークンの大半は決してあなたのタスク説明ではない。システムプロンプトであり、リポジトリの地図であり、会話履歴であり、AI が読んだファイルである。タスク説明の占める割合は無視できるほど小さい。
そこから導かれる事柄は、いずれも実測されている。
- リトライのたびに文脈一式を丸ごと送り直す。二回のリトライで一セッションのコストは三倍になりうる。
- 文脈のオーバーヘッドを勘定に入れると、実コストは素の見積もりの 3〜5 倍。PR 一本あたり 0.27〜3.25 ドル、複雑なリポジトリなら単一タスクで 20 ドル超も珍しくない。
- arXiv の論文『Cheap Code, Costly Judgment』（2607.01087）の実測では、agentic タスクが消費するトークンは通常のコード対話の 1000 倍、しかも同じタスクを繰り返し走らせたときのトークン消費の分散は最大 30 倍に達する。
ここで人間の反復と AI の反復を並べて計算する。
人が一つの仕事を三期に分けるとき、各期のコストはだいたい同じだ。人は前の期に何をやったかを覚えているからである。文脈は頭の中にあり、呼び出しは無料だ。
AI は覚えていない。毎期、文脈を買い直す。
| 同じ「三期に分ける」 | 人 | AI |
|---|---|---|
| 各期の主なコスト | 作業そのもの | 文脈の再構築 |
| 前期の記憶 | 頭の中、呼び出しは無料 | 存在しない、積み直しが必須 |
| 三期の総コスト | ≈ 三人分の工賃 | ≈ 三人分の工賃 + 二回の再構築費 |
| 一回多く区切る限界費用 | 一度の会話 | 文脈一式の買い直し一回 |
| 反復で買えるもの | 道を誤らずに済む機会 | 同じ機会、ただし摩擦費が別途 |
反復は人間にとって保険であり、AI にとっては摩擦費である。
GitClear が手戻りを実測した：3.3% → 7.1%
ここまでは推論だ。ここからは実測である。
GitClear は 2.11 億行の変更コードを分析し、churn という指標を追った。マージされてから数日のうちに大幅に書き直されるか削除されるコードの割合である。これが測っているのは、まさに「一度で正しく作れていない」という事実だ。
| 年 | churn |
|---|---|
| 2023 年以前（基準） | 3.3% |
| 2024 年 | 5.7% |
| 2025 年 | 7.1% |
二年で二倍以上。同じ研究の他の指標も同じ方向を指している。
- コミット内のコピーペースト +41%
- コードブロックの重複 +81%
- エラーを覆い隠す書き方 +47%
- ファイル横断の関数呼び出し（再利用の代理指標）−35%
- リファクタリングによる行移動 −70%
GitClear は AI が増幅した手戻りを三種類に分けている。どれも「まず半製品を出す」ことの直接の帰結だ。
- 位置が違う——論理も構文も正しいが、アーキテクチャ上の誤った場所に置かれ、後で人が移す
- 二度作った——既にある機能を再利用せず、もう一度実装した
- 数日後に書き直し——マージした後、エッジケースや規約違反が理由で大幅に変更される
同じ一連の研究で、AI が書いた PR の平均問題数は 10.83、人が書いたものは 6.45。1.7 倍である。
開発者自身の実感もこの数字と合う。Stack Overflow 2026 開発者調査から。
- 84% が AI ツールを使っている
- 45% が、AI 生成コードのデバッグは自分で書くより時間がかかると答えた
- 66% が、最大の不満は「ほぼ正しいが、完全には正しくない」出力だと答えた
- そして AI の出力への信頼度は 3%
別の調査では、AI 生成のコード変更の 43% が本番環境でのデバッグを要するとされている。
「ほぼ正しい」が肝だ。それは問題があなたの検収の瞬間には露出せず、マージの後に露出することを意味する。つまり次の期の頭に落ちてくる。省いたつもりのその一周は、後ろで請求される。
「一度で正しく」は「一度で全部」ではない：納品粒度と実行粒度
ここが標語に滑り落ちやすい。反復をやめて一度で全部やれ、と。それは間違いで、しかも危険な間違いだ。
分けるべき粒度が二つある。
- 実行粒度：一度に一箇所だけ変え、変えたら検証する。これは今日も成立するどころか、以前より重要だ——AI が一度に十ファイル触ると、人間のレビューが追いつかない。
- 納品粒度：この一周で渡すものが、完成品かどうか。
「一度で正しく」が言っているのは後者である。制約しているのは完成度であって、機能の数ではない。
範囲は狭くてよい。一ページ、一エンドポイントまで狭くてよい。だがこの一周でやると決めた部分は完全でなければならない。本物のデータ構造であってプレースホルダではないこと。読み込み・空・エラー・成功の四状態が揃っていて、理想経路だけではないこと。実際に動いて人が使えるものであって、スクリーンショットではないこと。
MVP という語の最大の問題は、「範囲が狭い」と「作りが粗い」を抱き合わせで売ったことだ。かつては本当に抱き合わせだった——金を節約するには両方を節約するしかなかった。今は切り離せる。範囲は依然として狭くてよいが、粗さはもう節約にならない。
「MVP は仮説検証であって AI とは無関係」——四つの反論のうち二つは立つ
あの V2EX の投稿に付いた反論のほうが、本文より価値がある。一つずつ見る。
1.「MVP の核心は仮説の検証だ。コードとは関係ないし、AI かどうかとも関係ない。」
立つ。そしてこれは問題の在り処をそのまま指している。MVP という語はずっと二つのものを抱き合わせてきた——仮説を検証することと、不完全な実装を出すことである。かつては不可分だった。仮説を検証する安い方法が、粗いものを作ることしかなかったからだ。今は分離した。仮説はもちろん検証すればよい。ただし完全なもので検証できる。
2.「潜在ユーザーの要求を一度で全部把握することは決してできない。」
立つ。そして「一度で正しく」とは衝突しない。全機能を一度で作れと言っている者はいない。今回作ると決めた部分を中途半端に残すな、と言っている。
3.「論理の複雑な案件、とくに込み入った業務ループや状態機械を持つシステムは、一足飛びにやると惨状になる。」
これは本物の問題だが、実行粒度の問題である。複雑な状態機械は当然一歩ずつ、各段で検証しながら作る。それは「書き直すと分かっている版をまず出す」根拠にはならない。
4.「AI があれば反復は猛烈に速く、コストもごく低い。」
これは立たない。上の二節がその反例だ。速くなったのは生成であって、収束ではない。churn が 3.3% から 7.1% に上がったことが、まさにその差を測っている。
「反復開発の禁止」をグローバルルールに書き込んでから
自分のグローバルルールに一行、固定で書いてある。反復開発の禁止、納品とは完成品のこと、MVP も段階的納品も認めない。
具体的な動作に落ちるとこうなる。
- 最初の一周から本物のデータ構造と本物の内容を要求する。Lorem ipsum 禁止、ダミーデータ禁止
- 四状態を一度に揃える。読み込み・空・エラー・成功
- 納品の前に自分で一度動かす。ブラウザで開き、コマンドラインで実行し、エンドポイントを curl で叩く
代価は実在する。最初の説明がはるかに長くなる。 着手前に境界・状態・データ構造を考え切らねばならない。この作業は AI に取り上げられてはおらず、「三周目の手戻りで考えざるを得なくなる」から「一周目の開始前に自分から考え切る」へ移動しただけだ。
見返りも直接的だ。同じことを二度、三度と説明し直さなくて済む。そして説明し直すことこそ、先の請求書で最も高い項目である。
範囲をどこまで狭く切るか、AI は助けられない
この問いにはまだ答えがない。
「一度で正しく」の前提は、範囲を正しく切れていることだ。広く切りすぎれば「一度」が「とても長い一度」になり、狭く切りすぎれば作ったもので何の仮説も検証できない。この線をどこに引くかは、ユーザーと状況についての判断に懸かっている——あの論文の題がすでに言い切っている。コードは安くなった。判断は安くなっていない。
ディスカッション