AIエージェントと、決して行われないリファクタリング

Rodrigo Rosenfeld Rosas AIエージェントと、決して行われないリファクタリング 2026年9月2日 午後12時 AIエージェントと日々接していると、懸念すべき傾向に気づき始めました。経験豊富なエンジニアでさえ、かつては知っていたはずですが、チームは静かに、システムの最も複雑な部分を書き直したり再構築したりすることをやめてしまいました。それはエージェントが書くコードの品質の問題ではありません。かつてはほとんど反射的に行われていた、しかし今ではめったに行われなくなった決定、すなわち「これは管理不能になった、さらに進む前にリファクタリングする必要がある」と立ち止まって言う決定についてです。 人間のコンテキストは小さく、それがソフトウェアの構築方法を形作った コンピュータは、人間よりもはるかに多くの情報を「ワーキングメモリ」に保持できます。数十の方向に分岐し、それぞれの分岐が独自の含意を持ち、すべてが相互接続されている複雑なシステムについて推論することはできません。それは単に一度に頭に入れておくには多すぎます。そのため、歴史的に私たちはできる唯一のこと、つまり、孤立して理解できるほど小さなモジュールにシステムを分割し、そしてそれらのモジュールを理解可能なインターフェースで接続する努力を費やしました。モジュール性、カプセル化、レイヤリング — これらは美的嗜好ではありません。それらは人間のワーキングメモリのサイズへの譲歩です。システムを、各部分が一人で理解できるサイズにまで分解します。なぜなら、それが人が推論し、安全に変更し、他人の変更をレビューできる唯一の方法だからです。 リファクタリングの反射 システムが混乱した状態で始まることはめったにありません。コードの一部は、要件がまだ単純なときに書かれ、最初はきれいに読めます。その後、要件が変更されます。開発者は新しいケースのために分岐を追加し、次に例外のために別の分岐を追加し、その例外の上にさらに特別なケースを追加します。十分な反復を経て、コードが表現していた元の「ルール」は例外の下に埋もれてしまいます — 時には要件が大きくシフトし、コードがもはや例外の塊となり、明確なルールが全く残っていない状態になります。経験豊富な開発者なら誰でも認識する瞬間があります：デバッグ中に、コードを追っていくと、迷子になります。分岐はもはや頭の中で描ける絵を形成しなくなります。 歴史的に、その感覚はシグナルでした。シニアエンジニアは、システムのどこかで迷子になったら、立ち止まってこう言うでしょう：「これは管理不能になった — これ以上何かを追加する前に、再び理解できるように書き直すかリファクタリングする必要がある」。エレガントさのためではなく、彼ら自身とその後継者たちが推論し、将来の変更を安全にレビューできるようにするためです。その反射 — 「迷子になった、だからリファクタリングの時だ」 — は、長命なシステムを保守可能に保つ上で最も重要な力の一つでした。そしてそれは人間の限界によって引き起こされました：人がコードを追えなくなった瞬間です。 公平を期すために言うと、その反射はAIエージェントのはるか以前からすでに圧力を受けていました。締め切り、ロードマップ、そして「動くものをなぜ書き直すのか？」と尋ねるマネージャーたちは常にそれに抵抗してきました。そしてリファクタリングは通常、優先順位が最も低くなるものでした。シニアエンジニアはすでに、長年かけて、システムが管理不能になったときに以前ほど強く抵抗しなくなっていました。エージェントはその弱点を作り出したわけではありません。彼らがやったことは、それにもかかわらず発火していた最後の内部トリガー — 人間が迷子になるという本質的な経験 — を取り除いたことです。 AIエージェントは迷子にならない 問題はここにあります。AIエージェントは、人間と同じようには人間のコンテキストの限界に縛られません。エージェントは、絡み合った関数を読み、すべての呼び出し元をトレースし、人間なら完全に立ち往生するような混乱を理解できます。それは次の分岐を正しく追加し、その後の分岐も追加し、チームの誰ももはや完全に理解していないコードの中で自信を持って作業できます。それは強みのように聞こえますし、短期的にはそうです。しかし、何が欠けているかに注目してください：エージェントは決して迷子にならないので、シグナルは決して発火しません。エージェントには「これは管理不能になった、立ち止まってリファクタリングすべきだ」と言う反射がありません。それは単に分岐の山に積み重ねていきます。ハーネス、プロンプト、または明示的なレビュー基準を通じて、後退して構造に疑問を呈するように指示されない限り、混乱を無期限に維持することに満足するでしょう。なぜなら、混乱はエージェントにとって問題ではないからです。 本当のリスク：人間がコードを監視できなくなる 失敗モードは、エージェントが悪質なコードを書くことではありません。それは、自然なチェックポイントが消滅し、人間がコードが自分たちの理解を超えて漂流していることに気づかなくなることです。時間が経つと、次のようなシステムに至ります： チームのどの開発者も、コードの重要な部分を完全に推論できません。 レビューは、レビュー担当者が変更を判断するのに十分に従うことができないため、単なるスタンプラリーになります。 チームは、自分たちがコードを理解できなくなったからこそ、エージェントをますます信頼するようになります — これは信頼が機能すべき方法とは正反対です。 その時点で、あなたは重要なものを失いました：エージェントを仲介者とせずに、自分たちのシステムについて推論する能力です。そして、単一の警告的な瞬間なしに、徐々にそれを失いました。なぜなら、かつて警告を発した瞬間 — 人間が迷子になること — は、ループから静かに取り除かれたからです。 クリーンなコードはエージェントにとっても安価である これらすべてを、単なる原則的な懸念 — 私たちは自分たちのシステムを理解すべきだ — としてフレーム化し、そこに留めるのは魅力的です。しかし、コードを整理された状態に保つことには、現実的で実用的な理由があり、エージェントに作業を任せることに完全に満足している場合でも、それは有効です。決して迷子にならないエージェントでさえ、混乱のために代償を払います。コードが絡み合い、相互接続されているほど、エージェントは正しい変更を行うために、より多くのコンテキストをロードして保持する必要があります：読むべきファイルが増え、トレースすべき分岐が増え、すべての編集ごとに燃焼するトークンが増えます。理解しやすい小さく自己完結したモジュールから構築されたシステムは、人間にとって優しいだけでなく、運用コストも安くなります。なぜなら、将来のすべての変更は、エージェントが理解するのにかかるコストが低くなるからです。そして、それはコストだけの問題ではありません。関連するロジックが、境界付けられた、一貫したスライスに収まらない場合、エージェントはスレッドを失い、幻覚を起こしやすくなります — 分岐が実際にはそうしないと仮定したり、3レベル下にある例外を見落としたりします。システムを人間の頭の中に保つ同じモジュール性が、各変更をエージェントが確実に推論できる、適切に定義された境界内に保ちます。クリーンな境界は、同じ理由で、両側での間違いを減らします。したがって、ソースを整理された状態に保つことは、エージェントの犠牲で人間に行う親切ではありません。それは人間に利益をもたらし、エージェントの精度を向上させ、そのコードに対して将来行うすべての変更のトークンコストを削減します。私たちが失う危機にあるリファクタリングの反射は、決して人間の快適さのためだけではありませんでした — それは良い経済性にもつながることが判明しました。 自己監視 私は、答えはエージェントを無力化することだとは思いません。答えは、それがもはや自発的に起こらないので、チェックポイントを意図的に取り戻すことです。エージェントが尋ねない質問を私たち自身がし続けなければなりません：このシステムのその部分をまだ理解していますか、それともエージェントに理解させていましたか？もし人間がエージェントなしでこれをデバッグしなければならなかったとしたら、追うことができたでしょうか？このコードが、もはやルールがなく例外だらけになったほど要件は逸脱しましたか — それが書き直しの時であることを示す古典的なシグナルです？今が機能作業を一時停止し、これを人が再び頭に入れられるものにリファクタリングする時でしょうか？ あなたはまた、これをハーネスに押し込むこともできます — モジュールが合理的なサイズや分岐の複雑さを超えて成長したときにフラグを立てるようにエージェントに指示したり、拡張するだけでなくリファクタリングを提案させたり、変更が推論するのが困難になっているときに呼び出させたりします。それは役立ちます。しかし、最終的な責任は私たちに残ります。なぜなら、私たちが自分たちのシステムを理解する必要があるのは私たちであり、注意を払っていない場合にその能力を失うのも私たちだからです。決して迷子にならないエージェントの利便性は本物です。しかし、「エージェントはまだそれを理解できる」ということは、「システムは健全である」ということと同じではありません。