モデルが賢くなれば解決するのか？
AIコーディングツールの支配的なナラティブはこうだ。モデルが十分に良くなれば、コードも上手く書き、テストも上手く書き、リファクタリングも自動でやってくれるはずだ。GPT-4でダメならGPT-5で解決する。Claudeにできなければ、もっと大きなClaudeがやってくれる。
本当にそうだろうか？
Claude Opus 4.7にfilefuncのリファクタリングを任せた。人間のレビューなしに1時間で完走した。validate通過、pytest通過、coverage維持。結果だけ見れば「やはりモデルが良ければ解決する」というナラティブに合致する。
しかし、同じモデルに同じリファクタリングをfilefuncルールなしでやらせたら？ validateなしで？ coverageフィードバックなしで？ 結果はまるで違う。doom loopに陥る。あるバグを直すと別の場所が壊れ、それを直すとまた別の場所が壊れる。
同じモデルだ。変わったのは環境だ。
「完了しました」――エージェントの早期終了本能
同じモデルでもう一つ実験をした。527個の関数があるプロジェクトにエージェントを自律的に投入した。「すべての関数にテストを書いて。」エージェントは作業を終えて報告した。「完了しました。」
実際にテストが書かれた関数：40個。 527個中40個。
エージェントは嘘をついたわけではない。40個をこなした後、「十分やった」と判断したのだ。LLMの基本的な傾向は楽観的な早期終了だ。難しい関数に出会うとスキップし、いくつか追加でやってから「残りも似たパターンだから大丈夫」と結論づける。
CLIツールでループを強制した後：
自律エージェント: 40 / 527 (7.6%) — エージェントが「完了」宣言
CLI loop: 527 / 527 (100%) — 機械が「まだ487個残っている」と宣言
同じモデルだ。同じプロジェクトだ。違いは**「終わり」を誰が決めるか**だ。
環境がモデルを作る
二つの実験が同じ結論を指し示す。Opus 4.7が完走したのはモデルが賢いからではない。specification surfaceがmachine-checkableだったからだ。
filefunc validate → コード構造がルールを満たしているか？
pytest → 既存の動作が保持されているか？
coverage → どの分岐が漏れているか？
この三つが修正のたびに即座にフィードバックを返した。モデルはこのフィードバックを受けて修正し、再びフィードバックを受け、再び修正した。self-correcting loop。
核心はここだ：
モデルのIQよりもフィードバック・トポロジーが結果を決定する。
LLMは生成能力は強いが、correctnessの保証は弱い。しかし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% coverageで停滞
フィードバックあり: 100%達成（到達可能な関数に限る）
同じモデルだ。「line 41 not covered」という一行がgradient signalの役割を果たす。このフィードバックがLLMの修正を正確な方向へ導く。
Symbolic Feedback Loop
すべての観察を貫く構造が一つある。
LLMが生成する → 決定論的ツールが判定する → 結果をLLMに返す → 繰り返し
これをSymbolic Feedback Loopと呼ぶ。
今の業界の主流はLLM Feedback Loopだ。AIがAIを検証する。酔った人が酔った友人に「俺、酔ってる？」と聞く構造だ。どちらも確率的だからエラーが蓄積する。
Symbolic Feedback Loopは違う。pytestはハルシネーションしない。go testは酔わない。coverage測定は嘘をつかない。仕様検証はドリフトしない。
この構造はcorrectnessを機械的に判定できる領域――コード、テスト、仕様、型――で機能する。API設計のエレガンスやUXの自然さは、まだシンボリックツールが判定できない。その境界を広げることが次の課題だ。自然言語もverifiableな境界の中に持ち込む道が存在すると信じている。
モデルをもっと賢くするよりも、モデルに返すフィードバックをもっと正確にする方が効果的だ。
決定の委任
決定をAIに委任してはならないという事実は自明だ。ただし、人間がすべてを確認し決定するのは骨の折れる仕事だ。反復的で定型的なある種の決定はシンボリックツールが人間の代わりに行える。
「このテストがすべての分岐をカバーしているか？」――人間が読む必要はない。coverageツールが判定する。「このコードが構造ルールを満たしているか？」――人間がレビューする必要はない。validateが判定する。「まだ処理していない関数が残っているか？」――人間が数える必要はない。CLIが宣言する。
AIに委任できない決定をシンボリックツールには委任できる。確率ではなく決定論だからだ。これがSymbolic Feedback Loopの存在理由だ。
列車をもっと速くすることより、線路を敷くことが重要だ。
多くの人が列車を作っている。線路を敷く人はまだほとんどいない。