HN 日本語サマリー

← 一覧へ戻る
プログラミング

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

AI Agents and the Refactoring That Never Happens (rosenfeld.page)

28 pointsby rosenfeld36 コメント

要約

AIエージェントの普及により、開発者はコードの複雑化に気づきにくくなり、リファクタリングの必要性を感じなくなっている。AIは人間のように「迷子」にならないため、コードが管理不能になっても信号が発せられず、結果として人間がコードを理解できなくなるリスクがある。コードの整理は、人間だけでなくAIエージェントの効率と正確性も向上させるため、意図的にリファクタリングの機会を設けることが重要である。

全文翻訳

AIエージェントと決して起こらないリファクタリング

Rodrigo Rosenfeld Rosas

2026年9月2日 午後12時

AIエージェントと日々接していると、懸念すべき傾向に気づき始めました。経験豊富なエンジニアでさえ、システムの最も複雑な部分の書き直しや再構築を積極的に行わなくなってきているのです。これはエージェントが書くコードの質の問題ではありません。かつてはほぼ反射的に行われていた、「これは管理不能になった、さらに進む前にリファクタリングが必要だ」と立ち止まって判断する、という決断が、今やめったに行われなくなったのです。

人間のコンテキストは小さく、それがソフトウェアの構築方法を形作ってきた

コンピューターは、人間が持てる「ワーキングメモリ」よりもはるかに多くの情報を保持できます。数十の方向に分岐し、それぞれの分岐が独自の含意を持ち、すべてが相互に接続されているような複雑なシステムについて、私たちは推論することはできません。それは単に、一度に頭に入れておくには多すぎるのです。

そのため、歴史的に私たちはできる唯一のこと、つまり、孤立して理解できるほど小さなモジュールにシステムを分割し、そして理解可能なインターフェースでそれらのモジュールを接続することに労力を費やしてきました。モジュール性、カプセル化、レイヤリング — これらは美的嗜好ではありません。これらは人間のワーキングメモリのサイズへの譲歩です。私たちは、システムを、各部分が一人の人間の頭に収まるまで分解します。なぜなら、それが人間が推論し、安全に変更し、他人の変更をレビューできる唯一の方法だからです。

リファクタリングの反射

システムが最初から混乱していることは稀です。コードの一部は、要件がまだ単純なときに書かれ、最初はきれいに読めます。その後、要件が変更されます。開発者は新しいケースのために分岐を追加し、次に例外のために別の分岐を追加し、その例外の上にさらに特別なケースを追加します。十分な反復を経ると、コードが表現していた元の「ルール」は例外の下に埋もれてしまいます — 時には要件が大きく変化し、コードはもはや明確なルールが残っていない、例外の塊になっていることさえあります。

経験豊富な開発者なら誰でも認識する瞬間があります。デバッグ中にコードを追っていくと、迷子になります。分岐はもはや頭の中で描ける絵を形成しなくなります。歴史的に、その感覚はシグナルでした。ベテランエンジニアは、システムのどこかで迷子になったら、立ち止まってこう言うでしょう。「これは管理不能になった — これ以上追加する前に、理解できるように書き直すかリファクタリングする必要がある」と。エレガントさのためではなく、自分自身と後続の全員がそれを推論し、将来の変更を安全にレビューできるようにするためです。

その反射 — 「迷子になった、だからリファクタリングの時期だ」 — は、長寿命のシステムを保守可能に保つ上で、静かに最も重要な力の一つでした。そしてそれは、人間の限界によって引き起こされていました:人間がコードを追えなくなった瞬間です。

公平を期すために言えば、その反射はAIエージェントが登場するずっと前からすでに圧力を受けていました。締め切り、ロードマップ、そして「動くものをなぜ書き直すのか?」と尋ねるマネージャーたちは、常にそれに抵抗してきました。そしてリファクタリングは、通常、優先順位が最も低くなるものでした。ベテランエンジニアはすでに、長年にわたって、システムが管理不能になったときにかつてほど強く抵抗しなくなっていました。エージェントがその弱点を作り出したわけではありません。彼らがしたことは、それに反して発火していた最後の内部トリガー — 人間が迷子になるという実感 — を取り除いたことです。

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

問題はここにあります。AIエージェントは、人間と同じような方法で人間のコンテキストの限界に縛られていません。エージェントは、絡み合った関数を読み、すべての呼び出し元をトレースし、人間なら完全に立ち往生するような混乱を理解することができます。それは次の分岐を正しく追加し、その後の分岐も追加し、チームの誰ももはや完全に理解していないコードの中で自信を持って作業します。

それは強みのように聞こえますし、短期的にはそうです。しかし、何が欠けているかに注目してください:エージェントは決して迷子にならないので、シグナルは決して発火しません。エージェントには「これは管理不能になった、立ち止まってリファクタリングすべきだ」と言う反射がありません。それは単に、分岐を山に追加し続けます。ハーネス、プロンプト、または明示的なレビュー基準によって、ステップバックして構造に疑問を投げかけるように具体的に指示されない限り、混乱はエージェントにとって問題ではないため、喜んで混乱を無期限に維持します。

真のリスク:人間がコードを監視できなくなる

失敗モードは、エージェントが悪質なコードを書くことではありません。それは、自然なチェックポイントが消滅し、人間がコードが自分たちの理解を超えて漂流していることに気づかなくなることです。時間が経つと、次のようなシステムに至ります:

  • チームの開発者は、コードの重要な部分について完全に推論できなくなる。
  • レビューは、レビューアが変更を判断するのに十分なほど追うことができないため、単なる形式的なものになる。
  • チームは、自分たちがコードを理解できなくなったまさにその理由で、ますますエージェントを信頼するようになる — これは信頼が機能すべき方法とは正反対です。

その時点で、私たちは重要な何かを失ったことになります:エージェントを仲介者とせずに、自分たちのシステムについて推論する能力です。そして、警報を鳴らしていた瞬間 — 人間が迷子になること — が静かにループから取り除かれたため、私たちはそれを徐々に、単一の警告的な瞬間なしに失いました。

クリーンなコードはエージェントにとっても安価

これらすべてを純粋に原則的な懸念 — 私たちは自分たちのシステムを理解すべきだ — としてフレーム化し、そこで終えるのは誘惑的です。しかし、コードを整理された状態に保つことには、現実的で実用的な理由があり、エージェントに作業を任せることに完全に満足している場合でも、それは生き残ります。

迷子にならないエージェントでさえ、混乱には代償を払います。コードの絡み合いや相互接続性が高ければ高いほど、エージェントは正しい変更を行うために、より多くのコンテキストをロードして保持する必要があります:読むべきファイルが増え、トレースすべき分岐が増え、すべての編集でより多くのトークンが消費されます。理解しやすい小さな自己完結型モジュールから構築されたシステムは、人間にとって優しいだけでなく、運用コストも安くなります。なぜなら、将来のすべての変更は、エージェントが理解するためのコストが低くなるからです。

そしてそれはコストだけではありません。関連するロジックが、境界付けられた、首尾一貫したスライスに収まらない場合、エージェントはスレッドを見失い、幻覚を見る可能性が高くなります — 分岐が実際とは異なることを行っていると仮定したり、3レベル下にある例外を見落としたりします。システムを人間の頭の中に保つモジュール性と同じモジュール性が、各変更をエージェントが確実に推論できる、適切に定義された境界内に保ちます。クリーンな境界は、同じ理由で、両側での間違いを減らします。

したがって、ソースを整理された状態に保つことは、エージェントの犠牲で人間に与える親切ではありません。それは人間に利益をもたらし、エージェントの精度を向上させ、そのコードに対して今後行うすべての変更のトークンコストを削減します。私たちが失う危機にあるリファクタリングの反射は、決して人間の快適さのためだけではありませんでした — それは良い経済学でもあることが判明しました。

自己監視

私は、答えはエージェントを無力化することだとは思いません。答えは、それがもはや自発的に起こらないので、チェックポイントを意図的に再導入することです。エージェントが尋ねない質問を、私たち自身がし続けなければなりません:

  • このシステムのこの部分をまだ理解していますか、それともエージェントに私の代わりに理解させていましたか?
  • 人間がエージェントなしでこれをデバッグする必要があった場合、それを追うことができましたか?
  • 要件が大きく変化し、このコードが今や例外の塊でルールがなくなった — リライトの時期であることを示す典型的なシグナル — という状況になりましたか?
  • 今が機能作業を一時停止し、これを人間が再び頭に入れられるものにリファクタリングする時ですか?

また、これをハーネスに押し込むこともできます — モジュールが合理的なサイズや分岐の複雑さを超えて成長したときにフラグを立てるようにエージェントに指示したり、単に拡張するだけでなくリファクタリングを提案させたり、変更を推論するのが困難になっているときに指摘させたりします。それは役立ちます。しかし、最終的な責任は私たちにあります。なぜなら、私たちが自分たちのシステムを理解する必要があるのは私たちであり、私たちが注意を払っていなければその能力を失うのも私たちだからです。

迷子にならないエージェントの利便性は本物です。しかし、「エージェントはまだそれを理解できる」ということは、「システムは健全である」ということと同じではありません。前者はエージェントの能力に関するものであり、後者は私たちの能力に関するものです。リファクタリングの時期かどうかを問い続ける — なぜなら、迷子になることであなたに思い出させてくれたツールは、もはや迷子にならないからです。