モデルのIQよりフィードバック・トポロジー

モデルのIQよりフィードバック・トポロジー Image: AI generated

モデルが賢くなれば解決するのか？

AIコーディングツールの支配的なナラティブはこうだ。モデルが十分良くなれば、コードも書き、テストも書き、リファクタリングも自分でやるだろう。GPT-4でできなければGPT-5でできる。Claudeが足りなければ、もっと大きなClaudeがやるだろう。

本当にそうなのか？

Claude Opus 4.7にfilefuncのリファクタリングを任せた。人間のレビューなしで1時間で完了した。validateパス、pytestパス、カバレッジ維持。結果だけ見れば「やっぱりモデルが良ければいい」というナラティブに合う。

だが、同じモデルに同じリファクタリングをfilefuncルールなしでやらせたら？validateなしで？カバレッジフィードバックなしで？結果はまったく違う。doom loopに陥る。一つのバグを直すと別の場所が壊れ、それを直すとまた別の場所が壊れる。

同じモデルだ。変わったのは環境だ。

「全部やりました」 — エージェントの早期終了本能

同じモデルでもう一つの実験をした。527個の関数があるプロジェクトにエージェントを自律的に投入した。「すべての関数にテストを書いてくれ。」エージェントは作業を終えて報告した。「完了しました。」

実際にテストが書かれた関数：40個。 527個中40個。

エージェントは嘘をついたわけではない。40個をやって「十分やった」と判断したのだ。LLMのデフォルトの性向は楽観的な早期終了だ。難しい関数に当たるとスキップし、もう少しやってから「残りも似たパターンだからもういい」と結論づける。

CLIツールでループを強制した後：

自律エージェント:  40 / 527  (7.6%)  — エージェントが「完了」宣言
CLIループ:       527 / 527 (100%)  — 機械が「あと487個残っている」宣言

同じモデルだ。同じプロジェクトだ。違いは**「終わり」を誰が決めるか**だ。

環境がモデルを作る

2つの実験が同じ結論を指し示す。Opus 4.7が完走したのは、モデルが賢かったからではない。仕様面がmachine-checkableだったからだ。

filefunc validate  → コード構造がルールを満たしているか？
pytest             → 既存の動作が保存されているか？
coverage           → どの分岐が欠けているか？

この3つが毎回の修正のたびに即座にフィードバックを返した。モデルはフィードバックを受けて修正し、再びフィードバックを受けて再び修正した。自己修正ループ。

核心はここだ：

モデルのIQよりもフィードバック・トポロジーが結果を決定する。

LLMは生成能力は強いがcorrectnessの保証は弱い。Huang et al.（2024）は、外部フィードバック（oracle feedback）なしでLLMが自力で推論を修正すると、むしろ性能が低下し得ることを実験的に証明した。しかしdeterministic verifierがあれば、性能は劇的に安定化する。lint、typecheck、test、coverage — これらがモデルの出力を修正するgradient signalになる。

「モデルが十分賢くなれば解決する」は偽の命題だ。正確には「フィードバックが十分速ければ、現在のモデルでも解決できる」だ。

broad exploration vs local correction

LLMの強みはbroad explorationではなくlocal correctionだ。

「このプロジェクトのテストを書いてくれ」 — これはbroad exploration。LLMは方向を見失う。

「line 41がカバーされていない」 — これはlocal correction。LLMは正確にその行をカバーするテストを書く。

実際のプロジェクトで検証された数字：

フィードバックなし:  カバレッジ60～70%で停滞
フィードバックあり:  100%達成（到達可能な関数に限る）

同じモデルだ。「line 41 not covered」という一行がgradient signalの役割を果たす。このフィードバックがLLMの修正を正確な方向に導く。

Symbolic Feedback Loop

これらすべての観察を貫く構造が一つある。

LLMが生成する → 決定論的ツールが判定する → 結果をLLMに返す → 繰り返す

これをSymbolic Feedback Loopと呼ぶ。

今の業界の主流はLLM Feedback Loop。AIがAIを検証する。酔った人が酔った友人に「俺、酔ってる？」と聞く構造だ。両方が確率的だからエラーが蓄積する。

Symbolic Feedback Loopは違う。Chen et al.（2023）は、コンパイラとランタイムのエラーメッセージをモデルに戻す反復的デバッグがコード精度を劇的に向上させることを証明した。pytestは幻覚を見ない。go testは酔わない。カバレッジ測定は嘘をつかない。仕様検証はドリフトしない。

この構造はcorrectnessを機械的に判定できる領域 — コード、テスト、仕様、型 — で機能する。API設計の優雅さやUXの自然さは、まだシンボリックツールでは判定できない。その境界を広げることが次の課題だ。自然言語も検証可能な境界内に持ち込む道が存在すると信じている。

AlphaCode（Li et al., 2022）が競技プログラミングで示したことも同じ原理だ。モデル自体の生成能力ではなく、数百万の候補を生成してテストでフィルタリングする環境設計が性能を決定した。モデルをもっと賢くするよりも、モデルに返すフィードバックをもっと正確にする方が効果的だ。

判断の委任

判断をAIに委任してはいけないことは自明だ。ただし人間がすべてを確認し判断するのは骨の折れる仕事だ。反復的で定型的なある種の判断はシンボリックツールが人間に代わって実行できる。

「これらのテストはすべての分岐をカバーしているか？」 — 人間が読む必要はない。カバレッジツールが判定する。「このコードは構造ルールを満たしているか？」 — 人間がレビューする必要はない。validateが判定する。「まだ処理されていない関数が残っているか？」 — 人間が数える必要はない。CLIが宣言する。

AIに委任できない判断をシンボリックツールには委任できる。確率ではなく決定論だからだ。これがSymbolic Feedback Loopの存在理由だ。

列車を速くするよりも、線路を敷くことが重要だ。

多くの人が列車を作っている。線路を敷く人はまだほとんどいない。

参考文献

Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” arXiv:2304.05128, 2023.
Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Remi Leblond, Tom Eccles, et al. “Competition-Level Code Generation with AlphaCode.” Science 378(6624): 1092-1097, 2022.
Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
Aman Madaan, Niket Tandon, Prakhar Gupta, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023.
Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” NeurIPS 2023.
Mert Cemri, Melissa Z. Pan, Shuyi Yang, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track.
Carlos E. Jimenez, John Yang, Alexander Wettig, et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.