9月3日、Rosenfeld（rosenfeld.page）が「AI Agents and the Refactoring That Never Happens」と題した記事を公開した。AIエージェントが「迷子にならない」という能力そのものが、長年ソフトウェア品質を守ってきたリファクタリングのトリガーを静かに消滅させている——この問題提起は、AIエージェントを日常的な開発ワークフローに組み込み始めたチームにとって、今すぐ向き合うべき構造的な課題だ。
「迷子になる感覚」がリファクタリングを生んでいた
経験あるエンジニアなら身に覚えがあるはずだ。デバッグ中にコードを追いかけていくうちに、頭の中で全体像が組み立てられなくなる瞬間。分岐が増えすぎ、例外が例外を覆い、元々そのコードが表現していたルールが完全に埋もれている状態だ。
その「迷子になる感覚」は、長年にわたってリファクタリングを促す最も重要なトリガーだった。シニアエンジニアはその感覚を受けて立ち止まり、「これは管理不能になっている。次の機能を追加する前に再構築が必要だ」と判断してきた。
モジュール化、カプセル化、レイヤリングといった設計原則は、美的なこだわりではない。人間のワーキングメモリ（作業記憶）の限界への適応だ。ワーキングメモリとは、人間が同時に意識的に処理できる情報量の上限を指す認知科学の概念であり、一般に「7±2チャンク」程度とされる。システムを「一人の頭に収まるサイズ」に分割することで、変更を安全に行い、コードレビューを機能させてきた。技術的負債という概念が広く語られてきた背景にも、この認知的制約がある。
AIエージェントは迷子にならない
ここに問題がある。AIエージェントは人間と同じ文脈の制約を受けない。どれだけ複雑に絡み合った関数でも、すべての呼び出し元をトレースし、人間なら立ち往生するような混乱を整理して、次のブランチを正確に追加できる。GitHub Copilot WorkspaceやCursorのようなエージェント型ツールは、リポジトリ全体を参照しながらコード変更を自律的に提案・実行する。これは生産性の大幅な向上をもたらす一方で、見落とされがちな副作用も生む。
エージェントは迷子にならないので、トリガーが発火しない。
「これは管理不能になった」という反射が起きないまま、エージェントは混乱した状態のコードに新たなブランチを積み上げ続ける。プロンプトやレビュー基準で明示的に指示しない限り、エージェントにとって「混乱したコード」は問題ではないからだ。
気づかぬうちに「理解できないシステム」が出来上がる
この失敗パターンは、エージェントが悪いコードを書くことではない。自然なチェックポイントが消え、人間がコードの劣化に気づかなくなることだ。行き着く先はこうなる：
- チームの誰もコードの重要な部分を完全に把握できなくなる
- レビューが形骸化する（レビュアーが変更内容を追えないため）
- コード自体を理解できないからこそエージェントを信頼するという、本来とは逆転した依存関係が生まれる
そして、この劣化には「ある瞬間」がない。かつて警報を鳴らしていた「人間が迷子になる体験」がループから静かに除外されるため、誰も異変に気づかないまま進む。
これは従来から議論されてきた技術的負債の蓄積と本質的には同じ問題だが、エージェント時代にはその進行が人間の目に見えにくくなるという点で質的に異なる。
コードの整理はエージェントにとっても合理的
この問題を「原則的に自分たちのシステムを理解すべきだ」という精神論で終わらせないために、著者は実利的な観点も提示している。
エージェントが迷子にならないとしても、複雑なコードにはコストがかかる。絡み合ったコードほど、正確な変更のために読み込むファイルが増え、トレースすべき分岐が増え、消費するトークン数（LLMが処理するテキストの単位）が増える。小さく自己完結したモジュールで構成されたシステムは、変更のたびにエージェントが負担する処理を削減できる。
さらに精度の問題もある。関連するロジックが明確な境界に収まっていないと、エージェントは「あの分岐は○○をしている」と誤って推測したり、3層下に埋もれた例外を見落としたりしやすくなる。人間の頭に収まる設計は、エージェントの推論精度も上げる。
チェックポイントを意図的に取り戻す
著者の結論は「エージェントを制限せよ」ではない。エージェントが自動では問わない問いを、人間が意識的に問い続けることだ。記事では以下の問いを定期的に自分に課すよう提案している：
- このシステムの該当部分を、自分はまだ理解しているか。それともエージェントに「理解させている」だけか？
- エージェントなしで人間がデバッグしようとしたとき、コードを追えるか？
- 要件の変化でコードが「例外だらけでルールのない状態」になっていないか？（リライトの古典的なサイン）
- 今こそ機能開発を止めて、人間の頭に収まる形にリファクタリングすべきタイミングではないか？
エージェントの設定（ハーネス）側で対処することも可能だ。モジュールが一定以上の規模や分岐複雑度に達したら警告を出すよう指示したり、拡張だけでなくリファクタリング案を提案させたりする方法が挙げられている。ただし、最終的な責任は人間にある。システムを理解できなくなって困るのは人間だからだ。
「エージェントがまだ解釈できる」と「システムが健全である」は別の話だ。前者はエージェントの能力の話であり、後者は私たちの能力の話である。
詳細はAI Agents and the Refactoring That Never Happensを参照していただきたい。
