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

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

なぜ動くのか

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

LLM → 人間 → LLM → 人間

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

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

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

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

LLMはunreliable componentだ。しかしunreliable componentの上にreliable protocolを載せるのは工学の基本だ。TCPはunreliable networkの上でreliable deliveryを実現する。RAIDはunreliable diskの上でreliable storageを実現する。ECCはunreliable memoryの上でreliable computationを実現する。

コーディングエージェントが動く理由は同じだ。unreliable LLMの上にdeterministic verifier（テスト、ビルド、リンター、型チェッカー）を載せたからだ。モデル性能ではなくtopologyが成功の原因だ。

ではなぜ壊れるのか

動くと言った。しかし時折壊れる。なぜか。

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

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

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

200エンドポイントのうち180にはテストがあり20にはない。エージェントは180を完璧に処理し、20で静かにバグを仕込む。「ほぼできているのにどこかおかしい」が生まれる理由だ。

フィードバックの情報量が足りない

1000語をソートする実験をした。CPUは0.08msで100%。LLMは438秒で97.7%。それ自体驚くべきことだ――純粋な認知で97.7%とは。しかし本当の発見は別のところにあった。

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

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

「間違っている」とだけ伝えると、過剰修正でかえって悪化する。エラーの個数を伝えると目標値が生まれ、執拗に探し出す。位置まで伝えると完璧に直す。

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