編集者注：AIエージェントがますます安価になり、呼び出しやすくなるにつれて、ソフトウェア開発は新たな段階に入っています。問題は、より多くのエージェントを起動できるかどうかではなく、人間がそれらの出力を管理し、判断し、統合するのに十分な注意を払えるかどうかです。

この記事は、「オーケストレーション税」という示唆に富んだ概念を提起している。エージェントを起動するコストは低く、単なるプロンプトの入力や1回のクリックで済む。しかし、真に高価なのはその後のプロセスだ——結果が正しいか確認し、システムアーキテクチャへの影響を理解し、異なるエージェント間の衝突を処理し、最終的にどのコードをメインブランチに取り込むかを決定することである。これらの作業は単純に並列化できず、依然として同じシーケンシャルなリソース、すなわち人間の判断力に依存している。

著者は開発者を、AIエージェントシステム内の「GIL」に例えている。GILとは、並列処理システムの最終的なスループットを制限する単一スレッドのロックである。複数のエージェントは同時に実行できるが、アーキテクチャの判断、コードレビュー、コンフリクトのマージ段階に達すると、必ず開発者の脳を経由しなければならない。したがって、エージェントが増えても、生産性が必ずしも向上するとは限らず、レビュー待ちのタスクキューが長くなるだけで、開発者がより頻繁なコンテキストスイッチと認知的疲労に陥る可能性がある。

これは現在のAIプログラミングツールのブームにおいて見過ごされがちな点でもある：効率感と実際の生産性は常に一致するわけではない。画面全体にAgentのダッシュボードが動作していると、「多産」であるかのような錯覚を生むが、開発者がこれらの変更を真正に理解し、審査し、統合しなければ、最終的に蓄積されるのは生産性ではなく、技術的負債と認知的負債となる可能性がある。

したがって、本記事で真正に議論されているのは「より多くのエージェントを使用する方法」ではなく、「人間の注意を再設計してワークフローを再構築する方法」である。エージェント時代において、重要な能力は質問をしたりタスクを割り当てたりすることだけでなく、どのタスクを機械に並列処理させることができるか、どのタスクは人間の判断を必要とするかを理解すること、いつバッチでレビューすべきか、いつ編成を停止して核心的な問題に再集中すべきかを知ることである。

AIはソフトウェア生産の並列処理能力を拡大しているが、人の注意は依然としてシステム中最も希少で、複製不可能なリソースである。真正に成熟したエージェントワークフローとは、すべてのタスクを機械に丸投げすることではなく、生産システムを設計するように、自らの注意アーキテクチャを丁寧に設計することである。

以下が原文です：

今や、より多くのAIエージェントを起動するのは簡単になりました。しかし、多くのエージェントが同時に動作するからといって、「あなた」が増えるわけではありません。あなたの認知帯域幅は並列化できません。それらを導き、結果を判断し、統合・修正するためのすべての判断力は、結局のところ、同じ直列プロセッサ——つまりあなた自身——を通らなければなりません。

所謂「編排税」，本質上就是你忘記這一點後所付出的代價。而唯一的真正解決方法，是像設計任何並發系統一樣，開始設計你自己的注意力。

以前、Google I/O でリチャード・セロター、アジャ・ハマーリー、シエラ・ジャスパンと共に、現在のソフトウェアエンジニアリングの姿と、今後どのように進化するかについてパネルディスカッションに参加しました。ディスカッションの終わり近く、リチャードは私たちに質問しました。「開発者がこの話を聞いて、最も大切にし、変えるべきことは何ですか？」

この数ヶ月間、繰り返し考えてきたことを言います：忙しいと感じることは、実際に成果を出していることとは限りません。20個のエージェントを同時に実行していて、とても忙しいと感じても、それは20個のエージェント分の作業量を提供したことを意味しません。

その会話の前半で、リチャードはこの問題に名前を付けた。彼は「あなたが先ほど述べたのは、まさに税の整理だ。自分の頭の中で20のエージェントを管理することはできない。」と言った。

彼の言っていることは完全に正しいです。この概念をより完全に分解して説明したいと思います。これは自己制御の問題ではなく、アーキテクチャの問題だからです。

そのパネルディスカッションで、私はふと口にした言葉だが、その後ずっと頭から離れない：複数のエージェントを運用することは、世界にあなたがもう一人増えることではない。

人々が考慮していない非対称性

エージェントのワークフローには、隠された非対称性が存在します。

エージェントを起動するのは非常に安価です。キーボードを一度叩くだけで、あるいは一つのプロンプトを書くだけで済みます。しかし、エージェントのサイクルを完了させるのは決して安価ではありません。エージェントが返した結果が正しいかどうかを誰かが確認し、他のエージェントが変更した内容と再調整する必要があるからです。

これがあなたです。そして、あなたは一人だけです。

先月、私は『あなたの並列エージェントの上限』でこの問題の一部を扱い、主に環境的な不安について議論しました——どの並列スレッドが静かに失敗しているかがわからないという状況です。この記事では、そのコストの背後にある構造に焦点を当てます。

エージェント開発を並列システムとして捉え始めるとき、人間自身がこのシステム内の一つのコンポーネントにすぎないことに気づくだろう。非常に遅いシーケンシャルなコンポーネントだ。

あなたがそのシングルスレッドリソースだ

並列コードを書いたことがあるなら、すでにこの問題を直感的に理解している。ただ、これまでその直感を間違った場所で使ってきただけだ。

Pythonにはグローバルインタプリタロック（GIL）があります。任意のスレッドを作成できますが、すべてのスレッドがこのロックを取得しなければならないため、同時に1つのスレッドのみがPythonバイトコードを実行できます。

あなたはあなたのAIエージェントのGILです。

それらはすべて同時に実行できます。ただし、それらの作業がシステムアーキテクチャを真正に理解する必要がある場合、またはマージコンフリクトを解決する必要がある場合は、まずこの鍵を取得しなければなりません。この鍵は1つしかなく、あなたが所有しています。

アムダールの法則は、並列化による速度向上の上限が、依然として直列で完了しなければならない部分に依存していることを非常に正確に示しています。あなたのプロセスの大部分が並列化できない場合、どれだけ多くのコアを投入しても、最終的には硬い上限に突き当たります。

エージェント開発において、この直列部分が判断力である。

8つのエージェントを起動しても、あなたの判断時間を短縮しません。それどころか、処理を待っているキューが長くなるだけです。

これはパフォーマンスエンジニアリングにおける非常に古くから知られた事実ですが、多くの人が依然としてこれに驚きます。ボトルネックでない部分を最適化しても、全体のスループットは向上しません。ただ、未完了の作業をボトルネックの前に積み上げるだけです。

エージェントの最適化は、本来制約ではなかった部分を改善しています。真の制約はレビュー工程であり、システム全体のスループットは、まさにこの工程のスループットと一致します。

タックスの編成とは、エージェントの生産能力とあなたが実際に統合できる内容との間の構造的なギャップです。これは、シングルスレッドのリソースに並列システムの管理を任せる際に発生します。

硬派に乗り切ることは構造的上限を解決できない

そのパネルディスカッションで、私は次のように言いました：これまでに、自分のツールがこれほど効率的だと感じたことはありませんが、同時にこれほど疲れたこともありません。

这两种感受はどちらも完全に真実であり、同じ原因から生じています。

この疲労感には非常に具体的な由来があります：それは、シングルスレッドプロセッサを100%まで常に駆動し、余裕を一切与えない状態で感じるものです。

あなたが注意範囲から外れたエージェントを再び確認するたびに、コンテキストスイッチのコストが発生します。脳を空にし、別のコンテキストをゼロから再読み込みする必要があります。

CPUはマイクロ秒単位でこの作業を完了できますが、アーキテクトはそれでも頻繁な切り替えを避けようとします。一方、あなたには数分かかり、コンテキストを完璧に復元することは決してできません。

5つのエージェントは、1つの作業量を5回繰り返すわけではありません。それは5回のクールスタート型のコンテキスト再読み込みに加え、バックグラウンドで継続して動作し、今あなたがどのエージェントをチェックすべきかを絶えず心配する大脳プロセスです。

構造的な制約を「より一生懸命」やることで解決することはできない。この税金は常に支払わなければならない。

無理に抵抗しようとすると、それは別の形で現れる：コードレビューが次第に浅くなるか、あるいは「認知的降伏」状態に陥る——自分自身で判断を下すのがあまりにも注意力を消費するため、エージェントが書いたコードをそのまま受け入れてしまう。

あなたはこの税金を自ら支払うか、それとも、それが暗くゆっくりとあなたのシステムに対する理解を破壊するのを放置するかのどちらかです。

注意力をデザインシステムのように設計する

したがって、あなたは自分の注意を希少なシーケンシャルリソースとして扱う必要があります。

分散システムを設計する際にボトルネックをまったく考慮しないことはありません。それと同じように、あなたの脳にも同じくらいの敬意を払ってください。

以下は私にとって本当に効果的な方法です：

優れた並行システムは、バッファオーバーフローを防ぐためにバックプレッシャー機構を使用します。プロデューサーは、コンシューマーの処理能力に合わせて速度を落とす必要があります。

あなたのエージェントの数が生産者であり、あなたのレビュー能力が消費者です。適切な並列エージェントの数は、あなたが真剣にコードレビューを完了できる数です。多くの人にとって、これは通常非常に低い単一桁の数です。

AIツールは当然、20個のエージェントを起動することを喜んでサポートしますが、それはあくまでUIの機能に過ぎず、あなたが実際にそれらを管理できる能力があるという意味ではありません。

リチャードがこの件をどう対処すべきか尋ねたとき、私はこの方法を挙げました。私はタスクを二つのグループに分けます。

最初のグループは比較的独立した作業であり、クラウドのバックグラウンドで動作するエージェントに任せるつもりです。これらのタスクは非同期で実行でき、最終的に私が一度だけチェックすれば十分です。

二番目の山は複雑なタスクであり、真の仕事は判断である。例えば、非常に奇妙なバグやアーキテクチャ設計などである。

最も大きな誤りは、第二類のタスクも並列化しようとする点である。複数の複雑なタスクを並列処理しても、あなたの生産性は拡大せず、かえってそのロックを繰り返し争奪することになり、最終的にはすべての結果が悪化する。

コンテキスト切り替えには常に高いコストがかかる。1つのAgentの結果を見て、他のことをしてから再び冷スタートして次の結果を見るよりも、一度に4つのAgentの結果をまとめてレビューする方がはるかに効率的である。

エージェントに長いリードをつけてください。作業を少し溜めてから、バッチとして処理してください。

機械が自ら検証できることに、あなたの脳を無駄に使う必要はありません。Agentに合格するテストを書かせたり、スクリーンショットを生成させたりしてください。

それら自身に、退屈だが検証可能な80％を証明させよう。そうすれば、あなたが限られた注意を本当に人間の判断を要する20％に集中できる。

ボトルネックには、エージェントチェックの間の残りの断片的な時間ではなく、あなたの最良の時間が必要です。

時には、最高のレバレッジの行動は、完全に構成を停止することである：エージェントで満たされたコンピューターをオフにし、一つの問題にだけ集中し、プロセス全体を通じてその鍵をしっかりと握り続けることである。

編成は本当の仕事ではない。それは仕事に伴うオーバーヘッドにすぎない。

Ajaは、アーキテクチャ能力が今や最も緊急のスキルとなっていると指摘した：どのタスクをエージェントに任せ、どのタスクがそれには大きすぎるかを理解する必要がある。

もう一点追加したいのですが、あなた自身もこのシステムの一部です。あなたの注意には、既知で非常に低い直列スループットがあります。システムはこの数値を尊重するか、それともあなたの基準を静かに引き下げることでこれを回避します。

忙しいことは生産性が高いことではない

これは非常に重要です。なぜなら、この失敗モードはあなた自身にはほとんど見えないからです。

20個の稼働中のエージェントは、「生産性が爆発している」ような感覚を与える。ダッシュボードがぎっしりと埋まり、すべてが動いている。しかし、この感覚と、高品質なコードをメインブランチにマージすることの間には、すでに乖離が生じている。

あなたは極限まで忙しくなるが、ほとんど実質的な成果を上げない。内側から見ると、この両者はほぼ同じに見える。

Cieraは、Margaret-Anne Storeyの債務に関する研究に言及しました。私たちは技術的負債と認知的負債について話し合いました。

支払いのない編成税は、あなたがこの両方の債務を蓄積することになります。

あなたは自分自身で真剣に読んだことのないものを統合しました。コードベースに対するあなたのメンタルモデルは完全に古くなっています。これらの問題は今日、ダッシュボードには現れません。本番環境で障害が発生したときに明らかになります——そのとき、あなたはシステムを見て、自分がもうどうやって動いているのかまったく分からなくなっていることに気づくのです。

したがって、真の結論は：Agentを起動することは能力ではない。誰でも20個実行できる。

真の能力とは、複製できず、並列化できないシーケンシャルリソースを中心にシステムを設計することである。

このリソースは、あなたの注意です。

生産環境で依存する重要なコンポーネントと同じように設計してください。