martinfowler.com寄稿記事が指摘するのは、サブエージェント活用でよくある前提への異論だ。サブエージェントは実行時間の短縮や並列処理のために使われると語られがちだが、記事はそこに価値を置かない——「オーケストレーターのコンテキスト内のすべてのトークンは、その注意力を奪い合っている」のであり、サブエージェントの真の価値は速さではなく、オーケストレーターのコンテキストから何を排除できるかにあると論じる。複数のサブエージェントを組んで運用するチームにとって、これは設計の重心を動かす指摘だ——サブエージェントを「時間短縮の道具」として並列数を増やす方向ではなく、「オーケストレーターの作業記憶を守る道具」として、何を委任し、結果として何をコンテキストに戻すかを設計する方向に軸足が移る。マルチエージェント設計を巡る議論が「何体並べられるか」から「委任のルールをどう明文化するか」という運用規律の話へ重心を移しつつある、という大きな流れを裏付ける一例でもある。だとすれば本当の問いは、エージェント数や並列度ではなく、オーケストレーターという有限な注意力資源をどう配分するルールを設計するかに移る。

何が起きたか

ソフトウェアエンジニアリングの論考を集めるサイトmartinfowler.comに、マルチエージェントのオーケストレーション設計を扱うゲスト寄稿記事が掲載された。記事の主眼は、サブエージェントを使う理由としてよく語られる「実行時間の短縮」や「並列処理による高速化」という説明を退け、真の価値は別のところにあると主張する点にある。

仕組み・詳細

記事の核心にあるのは次の一文だ——「オーケストレーターのコンテキスト内のすべてのトークンは、その注意力を奪い合っている」。オーケストレーター（複数のサブエージェントに作業を割り振る親エージェント）が保持できるコンテキストは有限であり、そこに何を入れるかは常に取捨選択を伴う。これが記事の言う「税」の正体だ。

この前提に立てば、サブエージェントの役割も再定義される。記事はサブエージェントを「オーケストレーターの作業記憶を守るためのツール」と位置づけ、「保持する必要のない推論をオフロードする」ものだとする。つまりサブエージェントの仕事は実行速度を上げることではなく、詳細な調査・試行錯誤・中間生成物といった「オーケストレーターが覚えておく必要のない過程」を、オーケストレーターのコンテキストの外側で処理し、結論だけを返すことにある。

この考え方を実務に落とし込む鍵として、記事は「いつ・どのように委任するかについて、オーケストレーターに明確なルールを与えること」を挙げている。委任を場当たり的にオーケストレーター自身の判断に委ねるのではなく、委任の条件やタイミングをあらかじめ明文化しておくことが、コンテキストの浪費を防ぐという主張だ。

背景

サブエージェント（オーケストレーターから作業を委任される子エージェント）を使ったマルチエージェント設計は、開発の高速化・並列化を主な動機として語られることが多い。この記事は、その一般的な語られ方に対する反論として位置づけられる——並列化やレイテンシ短縮という副次的な効果ではなく、オーケストレーターというボトルネックのコンテキストをいかに汚さないかという観点から、サブエージェントの設計原理を組み直そうとする論考だ。

なぜ重要か

この指摘が実務家に効くのは、評価の単位を変える点だ。サブエージェント導入の是非を「何秒速くなるか」「何体並列に走らせられるか」で測っていると、委任のたびにオーケストレーターへ戻ってくる大量のログ・中間結果・ステータス報告がコンテキストを圧迫し、長時間稼働するオーケストレーターほど後半で判断の質が落ちるという副作用を見落とす。記事の主張に従うなら、委任の設計で問うべきは速度ではなく「このサブエージェントの結果のうち、オーケストレーターのコンテキストに戻していいのはどこまでか」であり、委任のタイミングと方法に関する明確なルールを事前に持っているかどうかが、マルチエージェントシステムが実務で機能するかどうかを左右する。

これは、AIエージェントのオーケストレーション設計を巡る議論が、「何体のエージェントを並べられるか」という規模の競争から、「オーケストレーターという有限な注意力資源をどう配分するルールを設計するか」という運用規律の競争へと重心を移しつつある、という大きな流れの一例でもある。本当の問いは並列度ではなく、委任の設計原則そのものに移っている。