Sierraの単一窓口Agentは複合タスクに強いのか？4条件で検証した結果
要約
3機能以上のタスクでは、単体SpecialistのSingleが完遂率0%、単一窓口のUnifiedが100%だった。
一方、全体で最も安く速かったのはmulti-agentではなくMonolith（1体に全役割と全toolを与えた条件）だった。
結論は「単一窓口はUIの答え。内部構成は完遂率・品質・時間・成功単価を測って決める」。
Sierraの記事で気になった「Agent, singular」とは何か
Sierraの「AI-pilling our company: lessons learned」で、特に気になったのが「Agent, singular」という考え方でした。
Sierraは当初、Support、Data、Engineering、Salesなど、役割ごとにAgentを用意していたそうです。しかし、利用者が「どのAgentに頼めばよいか」を覚える必要があり、さらに重要な仕事ほど複数チームをまたぐという問題にぶつかりました。
そこで、窓口をPineconeという1つのAgentに統合。1つのSlack handle、1つのURL、依頼から完了まで途切れないthreadを持たせ、どのシステムを参照し、何をすべきかはAgent側が判断する形に変えています。
もう1つ印象に残ったのは、session数やtool call数ではなく、仕事が本当に終わったかを見るべきだという指摘です。ここから、1つの疑問が生まれました。
窓口を1つにすることはUXを良くするだけなのか。それとも、複数機能をまたぐ仕事の完遂率そのものを上げるのか。
差が明確に出たのはどこか：3機能以上
差は3機能層に集中していました。Strict完遂率と95% CIを4条件で並べると、それが分かります。
主仮説は、1機能ならSpecialistが同等以上でもよい。一方、調査、分析、文書作成、状態更新と仕事が複数機能をまたぐほど、Unifiedの厳格完遂率が上がる。
ちなみに、比較したのは次の4条件です。
Single：正解を知るoracleが最適な専門Agentを1体選ぶ。ほかのAgentへの委譲は禁止
Unified：1つのCoordinatorが必要な専門Agentを自動選択し、共有manifestで連携
Oracle chain：正しい専門Agentの順番をあらかじめ指定
Monolith：1体のAgentに全役割の指示と全toolを与える
全条件で同じclaude-sonnet-5、入力、参照データ、正解条件を使いました。toolの定義自体も共通ですが、各条件へ公開するtoolの範囲は、比較設計として事前に固定しています。
ここで大事なのは、2機能だけならSingleもUnifiedも100%だったことです。「複数機能なら常にUnifiedが勝つ」という結果ではありません。明確な差が出たのは3機能以上でした。
raw traceにも構成差は表れていました。
1セル平均で、Unifiedはchild thread IDが2.64件、tool callが11.1回、出力tokenが8,590。Monolithはchild thread 0件、tool callが5.8回、出力tokenが2,289でした。これはUnifiedの高いコストと長い時間に整合しますが、prompt、tool配置、session、引継ぎ方式も同時に違うため、差を「連携overheadだけ」の因果効果とは解釈できません。
単一窓口を構成する3つの層
「単一窓口」は3つの層に分けて考えられます。
1. 窓口：利用者が担当Agentやtoolを選ばなくてよい
2. 能力範囲：窓口の背後から、完遂に必要なtoolと権限へ到達できる
3. 実行構成：1体で処理するか、専門Agentへ委譲するか
Unifiedの成功単価はSingleの3.48倍で、時間中央値は約4.4倍です。
一方、MonolithはUnifiedと同じ100%を達成しながら、今回のfixtureでは最も安く、Unifiedより速く完了しました。副次Judge品質はUnifiedの方が高いため、Monolithがあらゆる意味で最適だったとも言えません。
これは解釈上、とても重要だなと。Unified対Singleでは、複合タスク全体へ届く構成の方が完遂しやすい結果でした。一方、UnifiedとMonolithの完遂率は同じで、専門Agentへの分割が必要だったとは確認できないからです。
「multi-agentが最も優れている」「専門Agentを連携させれば必ず性能が上がる」とは言えません。
今回の検証で言えること、言えないこと
今回の結果から言えることは、次の3点です。
1. この固定範囲では、Unified対Singleの事前登録した交互作用が支持された
2. 差が明確に現れたのは2機能ではなく3機能以上だった
3. Monolithも100%で、Unifiedより安く速かった
一方、次のことは言えません。
Sierraの内部architectureを再現・実証した
単一窓口にしたことが性能差の原因である
multi-agentが最良の内部構成である
実運用でも同じ完遂率やコストになる
Sierraが記事で触れている生産性や事業成果を確認した
この評価は固定fixtureと模擬tool上の比較です。Slack、CRM、Linear、email、Xなどの実サービスには一切読み書きしていません。モデル、tool遅延、権限設計、失敗時の復旧、人間のreview、task分布が変われば、完遂率もコストも変わります。
単一窓口と内部構成の使い分け
単一窓口はUIの答えであり、内部構成は測って決めるべきものです。Sierraの記事を読む時、私は「単一窓口」と「1体の万能Agent」をほぼ同じものとして捉えていました。しかし、実際には分けて考える必要があります。
単一窓口の価値は、利用者が担当Agentを選ばなくてよいことと、調査から成果物、最後の状態更新まで同じ文脈で追い続けられることです。
今回の結果は、「複合タスクでは1体よりmulti-agentが強い」ではなく、「複合タスクでは1役に閉じると完遂範囲が足りず、全工程へ到達できる設計が必要だった」と読むのが正確です。
だから、私の結論は「とりあえずmulti-agentにする」ではありません。
利用者から見た窓口を1つにする。共有文脈を保つ。成果物を作るだけでなく、最後の状態更新までを完了条件にする。そのうえで、内部構成は完遂率、品質、時間、成功単価を実際の業務で測って決める。
Sierraの記事を読んで検証した結果、いちばん強く残ったのはこの学びでした。
FAQ
単一窓口Agentにすれば複合タスクの完遂率は上がるのか？
この検証では、3機能以上のタスクでSingleが完遂率0%、Unifiedが100%でした。
ただし原因が「窓口を1つにしたこと」だとは確認できていません。
prompt、tool配置、session、引継ぎ方式も同時に違うためです。
2機能のタスクでもUnifiedが有利なのか？
いいえ。2機能だけならSingleもUnifiedも100%でした。
明確な差が出たのは3機能以上です。
「複数機能なら常にUnifiedが勝つ」という結果ではありません。
multi-agent構成が最も優れているのか？
言えません。MonolithはUnifiedと同じ100%を達成し、今回のfixtureでは最も安く、Unifiedより速く完了しました。
Unifiedの成功単価はSingleの3.48倍、時間中央値は約4.4倍です。
ただし副次Judge品質はUnifiedの方が高いため、Monolithがあらゆる意味で最適だったとも言えません。
比較した4条件はどう違うのか？
Singleはoracleが最適な専門Agentを1体選び委譲を禁止、Unifiedは1つのCoordinatorが専門Agentを自動選択して共有manifestで連携します。
Oracle chainは正しい専門Agentの順番をあらかじめ指定、Monolithは1体に全役割の指示と全toolを与えます。
全条件で同じclaude-sonnet-5、入力、参照データ、正解条件を使いました。
この結果を実運用にそのまま当てはめてよいのか？
いいえ。固定fixtureと模擬tool上の比較で、Slack、CRM、Linear、email、Xなどの実サービスには一切読み書きしていません。
モデル、tool遅延、権限設計、失敗時の復旧、人間のreview、task分布が変われば、完遂率もコストも変わります。
自社の業務でこの「窓口を1つにする / 内部構成は測って決める」を実際に回してみたい方は、AI Agent CAMPで、完遂率・品質・時間・成功単価を測りながらエージェントを設計する進め方を扱っています。検証設計から一緒に組み立てたい場合の相談先としても使ってください。
初出: X（2026-07-14）