バイブコーディングの逆効果なインセンティブ

2025年5月15日原文(fredbenenson.medium.com)

概要

AIコーディングアシスタントは「vibe coding」による中毒性とコスト増大の問題を抱える。トークン数課金モデルが冗長なコード生成を促進し、経済的な逆インセンティブを生む。簡潔さを求めると正確性が損なわれるというトレードオフも存在する。ユーザー側の工夫で対策は可能だが、根本的な解決には企業側のインセンティブ設計の見直しが必要。 AIの問題というよりは、ビジネスモデルの設計に起因する現象であることを強調する。

Vibe Codingの逆インセンティブ

AIコーディングアシスタント（例：Claude Code）は 中毒性 が高いことを体感すること
「もう一歩で完璧な解決策が得られる」という 可変比率強化 が依存傾向を加速すること
労力に対して大きな報酬が得られる「 effort discounting」効果が心理ループを生み出すこと
完了バイアス （始めたタスクは終わらせたい本能）と組み合わさり、プロンプトを繰り返す傾向が強まること
結果として、利用コストが高騰しやすい現象を分析すること

コストと冗長なコード生成の問題

Claude CodeなどのAIは 冗長で過剰なコード を書きがちであることを確認
経験豊富な開発者なら数行で済むところを、AIは 段階的かつ過剰防御的 に解決しがちであること
LLMは 抽象的な論理設計 が苦手なため、根本的な解決策よりも小手先の対応が増える傾向を持つこと
実例として、人間によるminimax実装400行に対し、Claude Codeは627行＋多数の追加ファイルを要したこと
バグ修正のたびに冗長なコードをAPIに送信する必要があり、 コストと手間が増大 すること

LLMの訓練データと経済的インセンティブ

LLMの訓練データには 冗長で非効率なコード が多く含まれている可能性が高いこと
AIコーディングアシスタントは トークン数課金 （生成・処理したテキスト量による課金）を採用していること
これにより「 トークン消費を増やすほど企業の収益が増える」という逆インセンティブが働くこと
冗長なコードがやり取りのたびに文脈として含まれ、 無駄なコストが積み重なる 現象を説明
企業側はこの問題を積極的に解決する動機が弱いこと（Upton Sinclairの格言に例えること）

簡潔さと正確性のトレードオフ

Giskard AIのPhareベンチマーク研究によると、「 簡潔に答えよ」という指示は 正確性を損なう 傾向があること
モデルは短くするために 事実誤認や不正確な回答 をしやすくなることを確認
コード生成でも同様に、 簡潔さを優先すると品質が下がる 現象が日常的に観察されること
LLMは chain-of-thought reasoning （思考の連鎖）で冗長に説明したほうが精度が上がる傾向があること
経済的インセンティブ（トークン消費最大化）と品質（正確性やエレガントなコード）との 根本的なミスマッチ が存在すること

ユーザーができる対策

実装前に必ず計画を立てさせること ：詳細な設計プランをAIに作成させることで、無駄な実装を減らすこと
明示的な許可プロトコル ：AIがコード生成前に必ず許可を求めるよう指示し、無駄な出力を抑制すること
Gitによる実験と大胆な枝切り ：バージョン管理を活用し、うまくいかない場合は枝ごと捨てることで冗長な修正を避けること
安価なモデルの利用 ：小型・安価なモデル（例：Claude 3.5 Haiku）を使うことで、自然と簡潔なコードを得やすくすること
- Claude 3.5 HaikuはClaude 3.7の26%の価格で利用可能であり、冗長さも少ない傾向があること

より良いインセンティブ設計への提案

LLMコーディングエージェントの評価・報酬を コード品質指標 （簡潔・保守性・正確性など）で行うよう転換すること
- ただし、品質指標の策定は主観的になりやすい課題があること
企業は 効率性を報いる価格モデル の導入を検討すること（現時点では具体案は未確定）
LLMの訓練時に RLHF（人間によるフィードバック強化学習） を活用し、エレガントな解答を優遇すること
- 複数案から最良コードを選ばせる手法の導入を検討すること
企業が 冗長なコード生成が長期的には損失につながる と認識すること
- Sam AltmanがChatGPTユーザーの丁寧な言葉遣いがコスト増につながっていると認めた事例を紹介すること

結論：AIの問題ではなくビジネスモデルの課題

本質的にはAIそのものの問題ではなく、 ビジネスモデルや収益構造 が逆インセンティブを生んでいること
ユーザー・開発者が価値を感じるのは「 根本的な問題解決をもたらす、簡潔で保守性の高いコード」であること
企業がこの価値と経済的インセンティブを 整合させる設計 を目指すべきであること
それまでは「 簡潔さは知性の証、だが機械に魂はない」という意識で使いこなすこと
AIは指示通りに動くだけであり、問題の根源は 人間のインセンティブ設計 にあると認識すること

Hackerたちの意見

その「もう少しで完璧」な感じ、つまり完璧な解決策まであと一歩という感覚が、すごく中毒性があるんだよね。バイブコーディングは、変動比強化の原則に基づいていて、これは報酬が予測できない形でやってくる強力なオペラント条件付けの一種なんだ。固定された報酬とは違って、この間欠的な成功パターン（「コードが動いた！すごい！でも壊れた！なんで！？」）は、ギャンブル行動に似た、脳の報酬経路でより強いドーパミン反応を引き起こすんだ。自分は「バイブコーダー」ではないけど、GenAIツールの「魅力」の一部としてこれをすごく理解してる。画像生成ツールに自分の思い通りにやらせようとするのは、まさに「ギャンブルみたい」な感じがする。

└

ギャンブルみたいじゃなくて、実際にギャンブルだよ。ドルをチップ（トークン、カジノによってはチップをトークンって呼ぶところもある）に交換して、機械に入れて賞品を得るチャンスを得るんだ。レバーを引いてもうまくいかないかもしれないけど、2回目はうまくいくかもしれないし、そうじゃないかもしれない。どちらにしても、ハウスが勝つ。これはギャンブルとして規制されるべきだよ、だってそうなんだから。メタファーなんてない、スロットマシンと違うのはAIが現金を直接出力することはないってことだけで、ただお金を生む可能性のある出力をするだけ。だから、最初のギャンブルで運が良ければ、次のチャンスを与えてくれるんだ。ギャンブルは続くよ。

└

でも、何にでも同じことが言えるよね？スタートアップ、結婚、子供。解雇されたコーダーたちは、うまくいかなかったキャリアに賭けてたんだ。人生にもっと確実性が欲しいなら、政治に関わらなきゃいけない。たとえそうしても、未来がどうなるかなんて保証はない。社会は30年後、100年後に崩壊するかもしれない…これはすべて、前の世代の物語に基づく幻想を満たすためのロールプレイに過ぎない。

└

イメージジェネレーターに自分の思い通りにやらせようとするのは、まるで「ギャンブル」みたいな感じだよね。特に、ヌードみたいに明確に生成しないって言われてるものを生成させようとすると、ハッキングしてる気分になる。

そうだね。遅くまでClineやClaude（他のシステムも）を正しい答えに導くために頑張ってきたよ。AWS Bedrockを使えるのはすごく良かった（注：私はAmazonで働いてる）。2. エージェントを制約のあるエリアで、機能やオブジェクトに取り組ませると良い結果が出てる。明確に定義した（私が定義した）境界の中でね。もしジュニアエンジニアの評価基準が、彼らを1日1回訂正することなら、エンジニアは週に1回、シニアは月に1回、プリンシパルは四半期に1回…みたいな感じ。これらのエージェントを超エネルギッシュなインターンみたいに扱って、頻繁にちょっと手を加えてあげて。3. 標準的な組織管理のコーディングプラクティスが適用される。エージェントに作業を見せさせたり、計画を立てさせたり、ユニットテストをさせたり、調査させたりするんだ。基本的に、私たちはオンデマンドの低品質なインターンを持つソフトウェア開発マネージャーになってきてるってことだね。これはすごく強力なツールだけど、彼らから超エレガントでコンパクトなコードを期待しないで。今はそれをシニアエンジニア（人間）に任せておこう。（注：AlphaEvolveの発表を見て、次は超エネルギッシュな応用科学インターンが来るのかなって思ってる…）

面白いことに、Sonnet 3.7のごちゃごちゃした問題の約90%は、プロンプトの最後にちょっと言葉を追加するだけで解決するんだ。「必要な最小限のコードを書いて」ってね。言葉の選び方にはそれほど敏感じゃなくて、「簡潔に」や「最小限の変更を加えて」も同じことになるんだけど、結果的にそのコードは指示なしのバージョンよりも50%は短くなることが多い。

└

まあ、記事にはそれが精度を下げるって書いてあるね。そういう問題にしょっちゅう直面するの？

└

一方、Geminiは超防御的なコーディングをする傾向があるね。絶対に起こらないような状況でも、すべてのエッジケースを個別にチェックするし、もし起こったとしてもNOPだし。

LLMを使ってコーディングするのがギャンブルみたいで、あと一つのプロンプトで欲しいものが手に入るかもっていう最初の主張について、もっと書かれていたらよかったな。これって、プロセスに対するコントロールがどれだけ少ないかを本当に表してるし、同時にコントロールがあるという幻想も持ってる。コードが冗長になるのは、もっと利益を上げるためだとはあまり思わない。モデル提供者が簡潔なコードを優先していない要素はあるかもしれないけど、もし「質」を保ちながら簡潔さが可能なら、あるモデルが他のモデルに対して十分な優位性を持つことになるから、提供者はそれをやるだろうと思う。

└

アンドレイ・カルパティの元ツイートで気になったのは、「雰囲気に身を任せて」って言ってたことで、これが結果にも当てはまるのかなって思った。

└

同意するよ、最近Cursorを使ってReactアプリを作ってるから、最初の主張についてよく考えてる。フロントエンド開発ではフィードバックループがかなり短縮されるから、より一般的だと思う。ポジティブなフィードバックを多くもらうほど、コードを書くときにそれを使うことに慣れてくるんだ。ここにはもう一つの逆説的なインセンティブがあると思う - 組織は機能や製品を早く生産したいと思っていて、LLMがそれを助けるけど、長期的には開発者の認知能力やスキルが低下するリスクがあるんだ。使わないことでそれを失ってしまうからね。

└

プロセスに対するコントロールがどれだけ少ないかを本当に捉えている一方で、コントロールの幻想を持っている。これは実際、人生についての大きな洞察で、いくつかの東洋の哲学では、私たちはそれに到達することが求められている。私たちはコントロールの幻想を愛しているけど、実際にはそれを持っていない。人生はほとんど、私たちが経験するように展開されていくものだ。

Hacker Newsで議論の続きを見る

ハクソク