原文タイトル：The Orchestration Tax

原文著者：Addy Osmani

翻訳：Peggy

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

本稿は非常に示唆に富む概念——「オーケストレーション税」を提唱している。エージェントを起動するコストは低く、プロンプト1つかクリック1回で済む。しかし、本当に高くつくのはその後の工程だ：結果が正しいかどうかの確認、システムアーキテクチャへの影響の理解、異なるエージェント間の競合の処理、そして最終的にどのコードをメインブランチにマージするかの決定。これらの作業は単純に並列化できず、依然として同じ直列リソース、すなわち人間の判断力に依存する。

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

これは現在のAIプログラミングツールブームにおいて見落とされがちな点である：効率感と実際の生産性は必ずしも一致しない。エージェントのダッシュボードが画面いっぱいに実行されていると、「高生産性」の錯覚を生む。しかし、開発者がこれらの変更を真に理解、レビュー、統合しなければ、システムに蓄積されるのは生産性ではなく、技術負債と認知負債である可能性が高い。

したがって、本稿が真に議論しているのは「より多くのエージェントをどう使うか」ではなく、「人間の注意力を中心にワークフローをどう再設計するか」である。エージェント時代において、重要な能力は質問の仕方やタスクの割り振り方だけでなく、どのタスクを機械に並列処理させ、どのタスクを人間の判断に委ねるべきか、いつバッチレビューを行い、いつオーケストレーションを停止して一つの核心問題に集中すべきかを知ることである。

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

以下が原文です：

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

いわゆる「オーケストレーション税」とは、本質的に、これを忘れたときに支払う代償です。そして唯一の真の解決策は、並行システムを設計するように、自分の注意力を設計し始めることです。

以前、Google I/OでRichard Seroter、Aja Hammerly、Ciera Jaspanと共に、ソフトウェアエンジニアリングの現状と今後の進化についてのパネルディスカッションに参加しました。終盤に近づいたとき、Richardが質問しました：開発者がこの話を聞いて、最も持ち帰って変えるべきことは何か？

私はここ数ヶ月ずっと考えていたことを述べました：自分が忙しいと感じることと、実際に成果を上げることは決してイコールではない。20のエージェントを同時に実行し、忙しくて仕方ないと感じることはできる。しかし、それは20のエージェント分の作業を納品したことにはならない。

その対話の早い段階で、Richardはこの問題に名前をつけていました。彼は言いました：「今あなたが話したのは、まさにオーケストレーション税だ。自分の頭の中で20のエージェントをうまく管理することは不可能だ。」

彼の言う通りです。この概念をもっと詳しく分解したいと思います。なぜなら、これは自己規律の問題ではなく、アーキテクチャの問題だからです。

そのパネルで、ほとんど口から出まかせに言った一言が、その後ずっと頭から離れません：複数のエージェントを実行しても、世界にあなたが増えるわけではない。

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

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

エージェントを起動するのは非常に安価です。キーボードを叩くか、プロンプトを書くだけです。しかし、エージェントのループを完了するのは決して安価ではありません。誰かがその結果が正しいかどうかを確認し、他のエージェントが変更した内容と再調整しなければなりません。

その誰かがあなたです。そしてあなたは一人しかいません。

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

Agent開発を並行システムとして捉え始めると、人間自身がそのシステム内の単なる一つのコンポーネントに過ぎないことに気づく。それは非常に遅いシリアルコンポーネントだ。

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

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

Pythonにはグローバルインタプリタロック（GIL）がある。スレッドはいくつでも作成できるが、Pythonバイトコードを実行できるのは一度に一つのスレッドだけだ。なぜなら、すべてのスレッドがまずこのロックを取得しなければならないからだ。

あなたは、あなたのAI AgentにとってのGILなのだ。

Agentはすべて同時に実行できる。しかし、その作業がシステムアーキテクチャを真に理解する必要がある場合や、マージコンフリクトを解決する必要がある場合、まずこのロックを取得しなければならない。そして、このロックはただ一つだけ存在し、あなたが保持している。

アムダールの法則はこれを非常に正確に説明している：並列化による高速化の上限は、依然としてシリアルに実行しなければならない作業部分に依存する。もしプロセス内に並列化できない大きな部分があれば、どれだけ多くのコアを投入しても、最終的にはハードな上限にぶつかる。

Agent開発において、このシリアル部分こそが判断力である。

8つのAgentを起動しても、判断時間は短縮されない。ただ、あなたの処理を待つキューが長くなるだけだ。

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

Agentを増やすことは、そもそも制約ではない部分を最適化しているに過ぎない。真の制約はレビュー工程であり、システム全体のスループットは、まさにこの工程のスループットと等しくなる。

オーケストレーション税とは、Agentの生産能力と、実際にマージできる内容との間の構造的なギャップである。これは、シングルスレッドリソースに並行システムを管理させるときに発生する。

無理に耐えても構造的上限は解決できない

あの円卓会議で、私はこう言った：これほど自分のツールが効率的だと感じたことはないが、これほど疲れたこともない、と。

この二つの感覚はどちらも完全に真実であり、そしてそれらは同じ原因から来ている。

この疲れには非常に具体的な原因がある：それは、シリアルプロセッサを継続的に100%に押し上げ、余裕を一切与えないときの感覚なのだ。

一度あなたの注意範囲から外れたAgentを振り返って確認するたびに、コンテキストスイッチのコストを支払わなければならない。頭を空っぽにして、ゼロから別のコンテキストを再読み込みする必要がある。

CPUならマイクロ秒でこれを完了できるが、それでもアーキテクトは頻繁なスイッチを避けようとする。一方、あなたは数分かかり、しかもコンテキストを完全に復元することは決してできない。

5つのAgentは、1倍の作業量を5回繰り返すことではない。それは、5回のコールドスタート的なコンテキスト再読み込みであり、さらにバックグラウンドで常に「今どのAgentをチェックすべきか」と気にかける脳のプロセスが走り続けることだ。

構造的な制限を「もっと頑張る」ことで解決することはできない。この税金は常に支払わなければならない。

無理に耐えようとすれば、最終的には別の形で現れる。コードレビューがどんどん浅くなるか、あるいは「認知的降伏」状態に陥るかだ——自分の判断を下すのに注意力を消耗しすぎるため、Agentが書いたコードをそのまま受け入れてしまう。

あなたはこの税金を自ら支払うか、あるいは陰でゆっくりと自分のシステムへの理解を蝕ませるかのどちらかだ。

システムを設計するように注意力を設計せよ

だからこそ、自分の注意力を希少なシリアルリソースとして扱わなければならない。

分散システムを設計する際に、ボトルネックをまったく考慮しないことはないだろう。ならば、自分の脳にも同じ敬意を払ってほしい。

以下は、私にとって本当に効果的だった方法だ。

UIの能力ではなく、レビュー能力に基づいてAgentチームを拡大せよ

優れた並行システムはバックプレッシャーを利用して、キューが無限に増えるのを防ぐ。プロデューサーはコンシューマーの処理能力に合わせて速度を落とす。

あなたのAgent数がプロデューサーであり、レビュー能力がコンシューマーだ。適切な並行Agent数は、あなたが真剣にコードレビューを完了できる数である。ほとんどの人にとって、それは通常、低い一桁の数字に過ぎない。

AIツールは喜んで20のAgentを起動させてくれるだろうが、それは単なるUI機能であり、あなたが実際にそれらを管理できる能力があることを意味しない。

タスクを分類せよ

Richardがこの件についてどう対処するか尋ねたとき、私はこの方法に言及した。タスクを2つの山に分けるのだ。

最初の山は、比較的独立した作業であり、クラウド上でバックグラウンド実行されるAgentに任せたいものです。これらのタスクは非同期で実行でき、通常は最終段階で一度だけ確認すれば済みます。

二つ目の山は、複雑なタスクであり、本当の作業そのものが判断です。例えば、奇妙なバグやアーキテクチャ設計などです。

最大の誤りは、二つ目のカテゴリのタスクも並列化しようとすることです。複数の複雑なタスクを並行処理しても、成果が拡大するわけではなく、ロックが何度も奪い合われ、最終的にすべての結果が悪化するだけです。

バッチレビュー。

コンテキストスイッチのたびに高いコストがかかります。一度に座って4つのAgentの結果をレビューする方が、一つを見て、別のことをして、またコールドスタートで戻って別の結果を見るよりもはるかに効率的です。

Agentには長めのリードを与えましょう。作業を少し蓄積させてから、それらを一つのバッチとして処理します。

このロックは判断にのみ使う。

機械が自動検証できることに脳を浪費してはいけません。Agentにテストを通るコードを書かせたり、スクリーンショットを生成させたりしましょう。

退屈だが検証可能な80%の部分は、Agent自身に証明させます。そうすれば、あなたの貴重な注意力は、本当に人間の判断が必要な20%にのみ使われます。

シリアルタイムを守る。

ボトルネックには、あなたの最高の時間が必要です。Agentのチェックの合間に残った断片的な時間ではありません。

時には、最もレバレッジの効くアクションは、完全に編成を止めることです：Agentで溢れたPCをシャットダウンし、一つの問題だけに集中して考え、そのプロセス全体でロックをしっかりと保持することです。

編成は本当の仕事ではありません。それは仕事にまつわるオーバーヘッドに過ぎません。

Ajaは、アーキテクチャ能力が今や最も緊急のスキルになっていると指摘しています：どのタスクがAgentに適しているか、どのタスクが大きすぎるかを知る必要があります。

さらに付け加えたいのは、あなた自身もこのシステムのコンポーネントの一つだということです。あなたの注意力には既知の、非常に低いシリアルスループットがあります。システムはこの数値を尊重するか、さもなければ、こっそりと基準を下げることでそれを回避します。

忙しさは生産性ではない

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

20のエージェントが稼働していると、「生産性が爆発的に向上した」感覚に陥ります。ダッシュボードはぎっしりと埋まり、すべてが動いています。しかし、この感覚は、実際に高品質なコードをメインブランチにマージすることとは、すでに切り離されています。

限界まで忙しくしていても、実質的な成果がほとんど出ていないことがあります。内部的な体験としては、この両者はほぼ同じです。

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

オーケストレーション税を支払わないと、この両方の負債が同時に蓄積されます。

自分がしっかりと確認していないコードをマージしてしまいます。コードベースに対するメンタルモデルは完全に時代遅れになります。これらの問題は今日のダッシュボードには現れません。それらは、本番環境で障害が発生したときに顕在化します——その時、システムを見つめながら、自分がもはやそれがどう動いているのか理解できていないことに突然気づくのです。

したがって、本当の結論はこうです：エージェントを起動することは能力ではありません。誰でも20個は動かせます。

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

そのリソースとは、あなたの注意力です。

それを、本番環境で依存する重要なコンポーネントと同じように設計してください。

[原文リンク]

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia