スピードを落とせ、それがエージェント時代の答えだ

元のタイトル:スピードを落とすことについての考察
原作者：マリオ・ゼクナー
翻訳：ペギー、ブロックビーツ

編集者注：生成型AIがソフトウェアエンジニアリングに急速に浸透するにつれ、業界の認識は「能力への畏敬の念」から「効率性への不安」へと変化しつつある。執筆速度が遅すぎる、十分に活用していない、自動化が不十分である――これらすべてが、時代遅れになるというプレッシャーを生み出すように思われる。しかし、コーディングエージェントが実際に運用環境に入ると、より実際的な問題がいくつか浮上し始めます。エラーが拡大し、複雑さが制御不能になり、システムがますます不透明になり、効率の向上は品質の向上に比例して結びつかないのです。

本稿は、現場での実践に基づき、現在の「エージェント・コーディング」のトレンドについて冷静な考察を提供する。著者は、エージェントは人間のように間違いから学ぶことができないと指摘している。ボトルネックやフィードバック機構がない場合、小さな問題がすぐに拡大してしまうのだ。複雑なコードベースにおいては、彼らの局所的な視点と限られた記憶能力が、システム構造の混乱をさらに悪化させる。これらの問題の本質は、技術そのものにあるのではなく、人間が不安に駆られて判断力と制御力を時期尚早に放棄してしまうことにある。

したがって、「AIを全面的に受け入れるべきかどうか」という不安に陥るのではなく、人間とツールの関係を再調整する方が良い。つまり、システム設計、品質保証、重要な意思決定はしっかりと人間の手に委ねつつ、エージェントには局所的で制御可能なタスクを任せるべきだ。このプロセスにおいて、「ペースを落とす」ことは一つの能力となる。つまり、システムを理解し、トレードオフを行い、自分の仕事に対するコントロール感を維持できるということだ。

進化し続けるツールの時代において、真に希少なのは、より高速な生成能力ではなく、複雑さを判断する能力、そして効率性と品質の間で選択を行う確固たる意志なのかもしれない。

以下は原文です。

カメの表情は、私がこの業界をどう見ているかを表しています。

約1年前から、「プロジェクト全体を最初から最後まで完了させる」ことができる真のコーディングエージェントが登場し始めた。Aiderや初期のCursorのようなツールは以前にもあったが、それらは「エージェント」というよりはアシスタントに近いものだった。新世代のツールは非常に魅力的で、多くの人が余暇の多くを、これまでやりたかったけれど時間がなくてできなかったプロジェクトに費やしている。

これはそれ自体は問題ではないと思います。余暇に何かをするのは本質的に楽しいことであり、ほとんどの場合、コードの品質や保守性について気にする必要はあまりない。これは、新しい技術スタックを学ぶための道筋にもなります。

クリスマス休暇シーズン中、AnthropicとOpenAIは「無料クレジット」も配布し、まるでスロットマシンのように人々を惹きつけた。多くの人にとって、これは「エージェントコーディング」の魔法を初めて本格的に体験する機会となった。参加者は増加傾向にある。

近年では、エージェントを使ったコーディングが本番環境のコードベースにも取り入れられ始めている。12ヶ月が経過し、私たちはこの「進歩」の結果を目の当たりにし始めている。これが私の現在の考えです。

全てが崩壊している

これはほとんどが個人的な経験に基づくものだが、現在のソフトウェアは確かに「今にも壊れそうだ」という感覚を与える。稼働率98%は、大規模なサービスであっても、例外的な状況から標準的な状況へと移行しつつある。ユーザーインターフェースには、品質保証チームが一目見ただけで気づくべきだった、あらゆる種類のばかげたバグが満載されている。

この状況はエージェントが現れる前から存在していたことを認めます。しかし今、この問題は明らかに加速している。

企業内部の真の状況は把握できないが、時折情報が漏洩することがあり、例えば噂されている「AIが原因のAWS障害」などがその例だ。アマゾンウェブサービスは速やかに声明を「訂正」したが、その後すぐに社内で90日間の再編計画を開始した。

マイクロソフトのCEOであるサティア・ナデラ氏も最近、同社のコードの大部分がAIによって書かれていることを強調している。直接的な証拠はないものの、確かにWindowsの品質が低下しているという感覚がある。マイクロソフト自身が公開したブログ記事の中にも、暗黙のうちにこれを認めているように見えるものがある。

「製品の100％がAIによって生成されている」と主張する企業は、ほぼ例外なく想像しうる最悪の製品を生み出すことになる。誰かを非難するつもりはないが、ギガバイト単位のメモリリーク、UIの混乱、機能の欠落、頻繁なクラッシュなど…これらはどれも彼らが「品質保証」と考えていたものではなく、「エージェントにすべてを任せよう」という肯定的な実証とは到底言えない。

非公式な場では、大企業から小規模チームまで、ますます多くの人が同じことを口にするようになるだろう。「エージェントコーディング」によって、自分たちは窮地に追い込まれている、と。コードレビューを行わず、設計上の決定をエージェントに委ね、さらに不要な機能を山ほど追加していく――当然ながら、良い結果にはならないだろう。

なぜエージェントをこのように使用すべきではないのか

私たちは工学的な規律や主観的な判断をほぼ完全に放棄し、代わりに「中毒性のある」働き方に陥ってしまった。つまり、結果を全く考慮せず、可能な限り短い時間でできるだけ多くのコードを生成することだけが目標となっているのだ。

あなたは、自動化されたエージェント軍を指揮するための足場となるレイヤーを構築しているのです。あなたはBeadsをインストールしましたが、それが実質的にアンインストール不可能な「マルウェア」であることに全く気づいていません。あなたがそれをしているのは、ネット上の情報源が「みんなやっている」と言っているからに過ぎない。このやり方をしないと、「ngmi」（成功しない）ことになるよ。

あなたは「マトリョーシカ人形のようなループ」の中で、絶えず自己消費を続けている。

ほら、Anthropicはエージェントのグループを使ってCコンパイラを作成したんだ。まだ問題はあるけど、次世代モデルならきっと直せるはずだよね？

さて、Cursorは多数のエージェントを使用してブラウザを構築しましたが、現状では基本的に使い物にならず、時折手動での介入が必要になります。しかし、次世代モデルはきっとそれを処理できるようになるでしょう。そうですよね？

「分散型」、「分割統治」、「自律システム」、「ブラックライトファクトリー」、「ソフトウェア問題を解決するのに6ヶ月」、「SaaSは死んだ、私の祖母はClawを使ってShopifyストアを立ち上げた」…

これらの物語は面白そうだ。

もちろん、この方法は、あなた自身を含めてほとんど使われていないサイドプロジェクトには「依然として有効」かもしれません。もしかしたら、この方法を使って、ゴミではない、真に使えるソフトウェア製品を作り出すことができる天才が本当に存在するのかもしれない。あなたがその人なら、私は心からあなたを尊敬します。

しかし、少なくとも私の開発者仲間の中では、この方法が本当に効果的に機能した事例をまだ見たことがありません。もちろん、私たち全員が単に経験不足なだけなのかもしれません。

学習なし、ボトルネックなし、遅延爆発におけるエラーの蓄積

エージェントの問題点は、彼らがミスを犯すということだ。それ自体は大した問題ではない。人間だって間違いを犯すものだ。単なる修正ミスである可能性もあり、特定して修正するのは容易です。回帰テストを追加することで、さらに安定性が向上します。また、リンターでは検出できないコードの悪臭である可能性もあります。例えば、使用されていないメソッド、不適切な型、重複したコードなどです。個々に見れば大した問題ではなく、人間の開発者もこういった小さなミスを犯すことがある。

しかし、「機械」は人間ではない。人間は同じ間違いを何度も繰り返すと、たいていはそれを繰り返さないように学ぶ。誰かに叱られるか、あるいは真の学習過程を経て自ら変わるかのどちらかだ。

エージェントには、少なくともデフォルトでは、このような学習能力は備わっていない。彼らは同じ間違いを何度も繰り返すだけでなく、訓練データに基づいて、さまざまなエラーの素晴らしい組み合わせを「作り出す」ことさえあるかもしれない。

もちろん、エージェントを「訓練」することもできます。例えば、AGENTS.md にルールを記述して、エージェントが同様のミスを繰り返さないようにしたり、過去のエラーやベストプラクティスを照会するための複雑なメモリシステムを設計したりすることができます。これは確かに、特定の種類の問題に対して効果的です。しかし、前提として、まずそれがこの間違いを犯したという事実を観察する必要がある。

主な違いは以下のとおりです。人間がボトルネックになっているのであって、エージェントはそうではない。

人間は数時間で2万行ものコードを吐き出すことはできない。エラー率がそれほど低くない場合でも、1日に発生するエラーの数には限りがあり、その蓄積は緩やかである。通常、「ミスによる痛み」が一定のレベルに達すると、人間は（本能的な痛み回避の心理から）立ち止まって問題を修正しようとする。あるいは、交換されて、別の誰かが修理する。いずれにせよ、問題は解決されるだろう。

しかし、綿密に計画されたエージェントの大軍を展開すれば、ボトルネックも「痛み」も発生しない。こうした最初は取るに足らない小さなミスが、やがて手に負えないほどの速さで積み重なっていく。あなたは情報から取り残され、一見無害に見えるこれらの不具合が巨大な問題へと成長したことに気づいていませんでした。本当に痛みを感じる頃には、たいてい手遅れになっている。

ある日、新しい機能を追加しようとしたときに、現在のシステムアーキテクチャ（実質的にはエラーの山）では変更に対応できないことが判明したり、最新リリースに問題がある、あるいはさらに悪いことにデータが失われたとしてユーザーが激しく苦情を言い始めたりしたときに初めて、問題が発生するのです。

この時点であなたは気づくのです。このコードベースはもはや信用できません。

さらに悪いことに、エージェントによって生成される何千、何万もの単体テスト、スナップショットテスト、エンドツーエンドテストも同様に信頼性が低い。システムが正しく機能しているかどうかを判断する唯一の方法は、手動テストを行うことである。

おめでとうございます。あなたは自分自身（そして会社）を窮地に追い込んでしまいましたね。

複雑性の商人

エージェントに制御を委ねてしまったため、システム内で何が起こっているのかを完全に把握できなくなっています。そして根本的に、エージェントの仕事は「複雑さを売る」ことにある。彼らは訓練データの中に数多くのひどい設計上の決定を目にしており、強化学習の過程でこれらのパターンを繰り返し強化してきた。彼らにシステム設計を任せれば、結果は予想通りになる。

結果として出来上がるのは、様々な「業界のベストプラクティス」の粗悪な模倣品が混ざり合った、非常に複雑なシステムであり、問​​題が手に負えなくなる前に何の制約も課さなかったのだ。

しかし、問題はそれだけにとどまらない。エージェント同士は実行プロセスを共有せず、コードベース全体を閲覧することもできず、あなたや他のエージェントが過去に下した決定についても一切知りません。したがって、彼らの決定は常に「地域的」なものである。

これは、前述の問題、すなわち大量の重複コード、抽象化のための過剰な抽象化構造、あらゆる種類の矛盾に直接つながります。これらの問題は複合的に作用し、最終的には修復不可能なほど複雑なシステムを生み出す。

これは実際、人間が作成したエンタープライズレベルのコードベースと非常によく似ています。唯一の違いは、この種の複雑さは通常、長年の蓄積の結果であるということだ。苦痛は多くの人々に分散され、それぞれが「修正しなければならない」という閾値に達しておらず、組織自体も高い許容度を持っているため、複雑さと組織は「共進化」する。

しかし、人間とエージェントの組み合わせの場合、このプロセスは大幅に加速される。2人の人間と多数のエージェントがいれば、わずか数週間でこのレベルの複雑さに到達できる。

エージェント検索のリコール率は低い

エージェントが「混乱を片付けてくれる」ことを期待したり、リファクタリングや最適化を支援してシステムをクリーンにしてくれることを期待したりするかもしれません。しかし問題は、彼らにはもうそれができないということだ。

コードベースが大きすぎて複雑すぎるため、彼らはその一部しか見ることができないのです。これは単にコンテキストウィンドウが十分に大きくないとか、数百万行のコードに対してロングコンテキストメカニズムが機能しないといった問題ではない。問題はもっと陰湿だ。

エージェントがシステムを修復しようとする前に、まず修正が必要なすべてのコードと、再利用可能な既存の実装をすべて見つけ出す必要があります。このステップを、私たちはエージェント型検索と呼んでいます。

エージェントがこれを実行する方法は、提供されるツールによって異なります。Bash + ripgrep、検索可能なコードインデックス、LSPサービス、ベクターデータベースなどです。

しかし、どのようなツールを使用するかにかかわらず、本質は同じである。コードベースが大きくなるほど、リコール率は低下する。リコール率が低いということは、エージェントが関連するコードをすべて見つけることができず、当然ながら正しい修正を行うことができないことを意味します。

これが、最初に「コードの臭い」という軽微なエラーが発生する理由でもあります。既存の実装が見つからなかったため、車輪の再発明を行い、矛盾が生じるのです。最終的には、これらの問題は拡大し、重なり合い、極めて複雑な「腐った花」へと成長していくでしょう。

では、どうすればこうした事態を回避できるのでしょうか？

エージェントとはどのように協力していくべきか（少なくとも現時点では）

エージェントを使ったコーディングは、まるで海の怪物と格闘するようなものだ。極めて高速なコード生成速度と、「断続的ではあるが、時折驚異的な」知能が、人を惹きつける。彼らはしばしば、単純な作業を驚くべき速さと高い品質で完了させることができる。本当の問題は、「このコンピューターは強力すぎるから、私の代わりに仕事をやってくれ！」という考えが浮かんだときに始まるのです。

タスクをエージェント自身に委任すること自体は、もちろん問題ありません。優れたエージェントタスクには通常、いくつかの特徴があります。範囲が明確に定義されており、システム全体を理解する必要がないこと。タスクがクローズドループであり、エージェントが結果を独自に評価できること。出力がクリティカルパス上になく、内部使用のための一時的なツールやソフトウェアに過ぎず、実際のユーザーや収益に影響を与えないこと。あるいは、単に思考を助ける「ラバーダック」が必要な場合、つまり、自分のアイデアをインターネットからの圧縮された知識や合成データと衝突させることです。

これらの条件が満たされる場合、このタスクはエージェントに引き渡すのに適しています。ただし、最終的な品質管理は人間であるあなたが担う必要があります。

例えば、アンドレイ・カルパシーの自動調査手法を用いて、アプリケーションの起動時間を最適化することは可能でしょうか？素晴らしい。しかし、このツールが出力するコードは決して実運用に耐えうるものではないことを理解しておくことが重要です。自動調査が効果的なのは、特定の指標（起動時間や損失など）を中心に最適化するための適合度関数を与えているからです。しかし、この適合度関数は非常に狭い範囲しかカバーしていません。エージェントは、適合度関数に含まれていないすべての指標（コードの品質、システムの複雑さ、場合によっては正確性など）を大胆に無視します。これは、適合度関数自体に欠陥がある場合に起こります。

基本的な考え方は非常にシンプルです。退屈で教育的ではない作業や、あなたがこれまで時間的に挑戦できなかった探索的な作業をエージェントに任せればいいのです。次に、結果を評価し、真に合理的で正しい部分を選び出し、最終的な実装を完了する。もちろん、この最終ステップでもエージェントを利用することができます。

でも私が本当に強調したいのは、もう少しペースを落としてください、ということです。

自分が何をしているのか、そしてなぜそれをしているのかについて、じっくり考える時間を取りましょう。「いや、これは必要ない」と言う機会を自分に与えましょう。エージェントに明確な制限を設定してください。1日に生成できるコードの量を決め、実際のレビュー能力に見合った量に設定してください。アーキテクチャやAPIなど、システムの「全体的な形状」を決定するすべての部分は、あなたが記述する必要があります。オートコンプリート機能を使って「手書きでコードを書く」感覚をつかんだり、エージェントとペアプログラミングをしたりすることもできますが、重要なのは、コードの中に身を置くことです。

なぜなら、自分でコードを書いたり、コードが段階的に構築されていく様子を見たりすることには、ある種の「摩擦」が生じるからだ。この摩擦こそが、自分が何をしたいのか、システムがどのように機能するのか、そして全体的な「感覚」がどのようなものなのかをより明確にしてくれるのです。ここで経験と「センス」が重要になってくるのであり、まさにこれこそが、最も先進的なモデルでもまだ代替できないものなのだ。ペースを落とし、多少の摩擦に耐えること――これこそが学びと成長の道なのだ。

最終的に得られるのは、少なくともエージェントが現れる前より悪くない、維持可能なシステムです。はい、過去のシステムも完璧ではありませんでした。しかし、あなたの製品は「使える」ものであり、急いで寄せ集めたガラクタの山ではないため、ユーザーはあなたに感謝するでしょう。

機能は少なくなるが、より正確になる。「ノー」と言うことを学ぶこと自体が、一つのスキルである。システム内で何が起こっているかを把握でき、コントロール権も保持しているため、安心して眠ることができます。この理解こそが、エージェント検索におけるリコール問題に対処することを可能にし、エージェントの出力の信頼性を高め、パッチ適用の必要性を減らすことにつながります。

システムに不具合が生じた場合は、自ら手を動かして修正することができます。設計が最初から欠陥があった場合は、問題点を理解し、より良い形にリファクタリングすることができます。エージェントが存在するかどうかは、実際にはそれほど重要ではない。

これらすべてには規律が必要だ。これらすべては人間と切り離せない関係にある。

[オリジナル記事]