コーディングエージェントはなぜ動き、なぜ壊れるのか Image: AI generated

同じモデルだ。ウェブチャットでhallucinateしていたそのモデルが、Claude Codeでは200行の機能を一発で仕上げる。Codexの/goalはissue一つを丸ごと解決する。モデルが急に賢くなったわけではない。変わったのは構造だ。

なぜ動くのか

対話型AIのループはこうだ:

LLM → 人間 → LLM → 人間

フィードバックはすべて自然言語。確率的生成に確率的評価が続く。精度が積で劣化する。

コーディングエージェントのループは違う:

LLM → コード生成 → ファイル保存 → テスト実行 → pass/fail → LLM
LLM → コード修正 → ビルド → 成功/失敗 → LLM
LLM → 型チェック → エラーメッセージ → LLM

ループの中に決定論的ゲートが挟まっている。ファイルシステムは書いたとおりに保存する。テストはpassかfailだ。コンパイラは間違っていたら間違っていると言う。これらが意図せずラチェットの役割を果たしている。

LLMは不安定なコンポーネントだ。しかし不安定なコンポーネントの上に信頼性のあるプロトコルを構築するのは工学の基本だ。フォン・ノイマンは1956年に多数決投票だけでノイズの多い部品が信頼性のある計算を実行できることを数学的に証明した (Von Neumann, 1956)。TCPは不安定なネットワーク上で信頼性のある配送を構築する。RAIDは不安定なディスク上で信頼性のあるストレージを構築する。ECCは不安定なメモリ上で信頼性のある計算を構築する。

コーディングエージェントが動く理由は同じだ。不安定なLLMの上に決定論的検証器(テスト、ビルド、リンター、型チェッカー)を載せたからだ。SWE-agent研究は、同じモデルでもAgent-Computer Interfaceの設計によって性能が劇的に異なることを実証した (Yang et al., NeurIPS 2024)。成功の原因はモデルの性能ではなくトポロジーだ。

ではなぜ壊れるのか

動くと言った。だが時々壊れる。なぜか。

たまたま挟まっているラチェットと、意識的に設計されたラチェットは違うからだ。

ラチェットのない区間が存在する

テストのないコードをエージェントが修正するとどうなるか?ビルドは通る、リントも通る、だが機能は壊れている。決定論的ゲートのない区間ではLLMが確率的に判断し、確率的判断は積で劣化する。

200エンドポイントのうち180にはテストがあり20にはない。エージェントは180を完璧に処理し、20に静かにバグを植える。「ほぼできたけど何かおかしい」になる理由だ。

フィードバックの情報量が不足している

1,000語のソート実験をした。CPU:0.08msで100%。LLM:438秒で97.7%。それ自体驚異的だ — 純粋な認知で97.7%。だが本当の発見は別のところにあった。

同じ結果に対してフィードバックのレベルだけを変えてみた:

フィードバック結果
なし6個のエラー(99.4%)
「エラーがある」10個のエラー(99.0%) — 悪化
「23個のエラーがある」1個のエラー(99.9%)
「6個のエラー、ここにある」0個のエラー(100%)

「間違っている」とだけ伝えると過剰修正で逆に悪化する。エラー数を伝えると目標ができて執拗に探す。位置まで伝えると完璧に修正する。

今のエージェントは大半が2番目のレベルに留まっている。テストが失敗すると「何かおかしい」とは分かるが、なぜおかしいかの構造的理由までは伝えない。エラーメッセージはあるが、それは原因ではなく症状だ。

死角が存在し、繰り返しでは解決しない

ソート実験でLLMはR2で6個のエラーを残した。R3で「エラーなし」と報告。R4bでも「エラーなし」と報告。同じ6個を同じ方法で見落とした。

ヒントなしでは何回繰り返しても99.4%に収束した。「6個残っている」と伝えてようやく100%を達成した。

コーディングエージェントでも同じことが起きる。エージェントがバグを作り、self-reviewで「問題なし」と判断し、もう一度直せと言っても同じ場所を見落とす。Huang et al.(2024)は、外部フィードバックなしでLLMが自身の推論エラーを自己修正すると性能がむしろ低下することを示した (Huang et al., ICLR 2024)。retryが解決策でない理由がこれだ。死角はモデルの確率的性質に由来する構造的限界であって、努力不足ではない。

スケールで掛け算が作動する

97.7%の精度を2回チェーン:0.977² = 95.4%。3回:93.2%。10回:79.2%。

エージェントがファイル1つを修正するのは上手くいく。だが100ファイルにまたがるリファクタリングを頼んだら?各ステップが97%でも、100ステップで0.97¹⁰⁰ = 4.8%。事実上失敗が保証される。

これが「vibe codingが200エンドポイントで崩壊する」の数学的説明だ。小さなプロジェクトではチェーン回数が少ないから確率が持ちこたえ、大きなプロジェクトでは掛け算が破滅的に作動する。

何が必要か

動く理由と壊れる理由が同じ場所を指している:決定論的検証ゲートの有無だ。

今のエージェントはたまたま挟まっているラチェット(テスト、ビルド、リンター)に依存している。これを意識的に設計すればもっと強くなる。

ラチェットを意識的に設計するとは:

第一に、ラチェットのない区間を特定する。テストのないコード、スキーマのないAPI、型のないデータ。エージェントが確率的に判断しているすべての場所が脆弱点だ。

第二に、フィードバックの情報量を高める。pass/failだけ返すと過剰修正を誘発する。「どこで、なぜ、何が期待と違うのか」を構造化して伝えなければならない。

第三に、チェーンの途中に決定論的ゲートを挟む。10ステップを一度に回すと掛け算が破滅的だが、各ステップでラチェットで固定すれば劣化がリセットされる。

LLMは驚異的なジェネレーターだ。1,000語を純粋な思考で97.7%の精度でソートする。人間にもできないことだ。だが100%でないすべてのものは繰り返すと崩壊する。0.977の2乗は0.954だ。

コーディングエージェントが動くのはモデルが賢いからではない。ループの中に決定論的ゲートが挟まっているからだ。壊れるのはそのゲートが抜けているからだ。

生成は確率的でよい。検証は決定論的でなければならない。


関連記事

出典

  1. Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Shannon, C.E. & McCarthy, J. (Eds.), Automata Studies, Annals of Mathematical Studies, No. 34, Princeton University Press, pp. 43-98.
  2. Saltzer, J.H., Reed, D.P., & Clark, D.D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems, 2(4), 277-288.
  3. Patterson, D.A., Gibson, G., & Katz, R.H. (1988). “A Case for Redundant Arrays of Inexpensive Disks (RAID).” Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pp. 109-116.
  4. Hamming, R.W. (1950). “Error Detecting and Error Correcting Codes.” The Bell System Technical Journal, 29(2), 147-160.
  5. Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
  6. Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
  7. Jimenez, C.E. et al. (2024). “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
  8. Yang, J. et al. (2024). “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024.
  9. Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
  10. Kamoi, R. et al. (2024). “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs.” TACL, 12, 1298-1318.
  11. Cemri, M. et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657.
  12. Arbuzov, M.L., Shvets, A.A., & Beir, S. (2025). “Beyond Exponential Decay: Rethinking Error Accumulation in Large Language Models.” arXiv:2505.24187.

変更履歴

  • 2026-05-16: 初版