AIエージェントは迷子にならない — だからリファクタリングが行われにくくなる

9月2日、rosenfeld.pageが「AI Agents and the Refactoring That Never Happens」と題した記事を公開した。AIエージェントの普及によって、エンジニアが長年持ち続けてきた「リファクタリングすべき」という直感が静かに失われつつある——その構造的な理由と、人間側がとるべき対処を論じた内容だ。

「迷子になる感覚」がリファクタリングを駆動していた

熟練エンジニアなら覚えがあるはずだ。デバッグ中にコードを追っていくうち、分岐が複雑になりすぎて頭の中で全体像が結べなくなる瞬間。あの「迷子になる感覚」は、単なる不快感ではなく、「これ以上続ける前にリファクタリングが必要だ」というシグナルだった。

モジュール化・カプセル化・レイヤリングといった設計原則は美的こだわりではない。これらは人間のワーキングメモリの限界への対処として自然発生した慣習だ。人間は複雑なシステムを丸ごと頭に入れて推論できないため、「一人の人間が把握できる単位」まで分割することで、安全に変更を加え、レビューできる状態を保ってきた。

そのリファクタリングの衝動は、締め切りやロードマップによってすでに以前から圧迫されてきた。「動いているものをなぜ書き直す？」という問いに、シニアエンジニアが押し返す力は年々弱まっていた。AIエージェントはその弱点を作り出したわけではない。ただ、それでも発火していた最後の内的トリガーを取り除いてしまった。

エージェントは迷子にならない

AIエージェントは、人間が立ち往生するような絡み合った関数を読み、すべての呼び出し元を追跡し、正確に次の分岐を追加できる。短期的にはこれは明らかな強みだ。

しかし問題はここにある。エージェントは迷子にならないので、シグナルが発火しない。「このコードは手に負えなくなった、一度立ち止まるべきだ」という反射がエージェントには存在しない。

ハーネス——エージェントを動かすための実行環境・設定一式を指す。LangGraphやAutoGenのようなマルチエージェントフレームワーク、あるいは自前のオーケストレーション層がこれに該当する——やプロンプト、明示的なレビュー基準で指示しない限り、エージェントは混乱したコードに対して延々と分岐を積み上げ続ける。そのカオスはエージェントにとって問題ではないからだ。

本当のリスク：人間がコードを把握できなくなる

失敗の形は「エージェントが悪いコードを書く」ことではない。自然なチェックポイントが消え、人間が「コードが理解の範囲を超えた」ことに気づかなくなることだ。

時間が経つにつれ、システムはこういう状態に陥る：

チームのどの開発者も、コードの重要な部分を完全に把握できない
レビューが形骸化する。レビュアーが変更の中身を実際に追えないからだ
チームはエージェントを信頼するようになる。自分たちがコードを理解できなくなったまさにその理由で——これは信頼のあり方として完全に逆方向だ

この状態に至っても、「人間が迷子になる瞬間」という警報が取り除かれているため、誰も異変に気づかない。技術的負債が積み上がる典型的なパターンだが、AIエージェント時代にはその蓄積が従来より速く、かつ不可視になりやすい点が新しい。

実利的な理由もある：クリーンなコードはエージェントにも安く付く

これを「原則の問題」として論じるだけでは弱い。記事はより実務的な論点も示している。

エージェントは迷子にならなくても、混乱したコードのコストを払う。コードが複雑に絡み合っていると、エージェントは正確な変更を行うために読み込むファイルが増え、追うべき分岐が増え、編集のたびに消費するトークン数が増える。小さく自己完結したモジュールで構成されたシステムは、人間にとって扱いやすいだけでなく、エージェントの運用コストも下がる。

さらに精度の問題もある。関連するロジックが整理されていないと、エージェントはスレッドを見失いやすく、「この分岐は〇〇をする」という誤った仮定（いわゆるハルシネーション）を引き起こしやすい。クリーンな境界はミスを減らす。これは人間にとっても、エージェントにとっても同じ理由で成立する。

リファクタリングの衝動は人間の快適さのためだけにあるのではなく、エコノミクスとしても正当化できるという指摘だ。

自分たちで問い続けるしかない

記事の結論は明快だ。エージェントを制限するのではなく、人間側がチェックポイントを意図的に持ち込む必要があるということだ。具体的には、次の問いを定期的に自分に課すことが求められる：

このシステムの該当部分を、自分はまだ理解しているか？それともエージェントに理解させているだけか？
エージェントなしで人間がデバッグしようとしたとき、追えるコードになっているか？
要件がここまで変わったなら、このコードは今や「例外しかない」状態になっていないか——それが書き直しの古典的なシグナルだ
今こそ機能開発を止めて、人間が頭に収められる形にリファクタリングすべき瞬間ではないか？

ハーネス側でのアプローチも有効で、モジュールが一定の規模や分岐の複雑さを超えたらフラグを立てる、拡張だけでなくリファクタリングを提案させる、推論しにくい変更を指摘させる——こうした設定は助けになる。しかし最終的な責任は人間側にある。システムを理解できなければならないのは人間であり、注意を払わなければその能力を失うのも人間だからだ。

「エージェントがまだ理解できている」と「システムが健全だ」は別の話だ。前者はエージェントの能力の話であり、後者は人間側の能力の話である。

詳細はAI Agents and the Refactoring That Never Happensを参照していただきたい。