サブエージェントアーキテクチャとは、1 つのエージェントがプロジェクト全体にわたって状態を保持しようとするのではなく、専門化したサブエージェントがクリーンなコンテキストウィンドウで焦点を絞ったタスクを担い、メインエージェントが高レベルの計画に基づいて作業を調整する構成である。Anthropic はこれを、長期タスクにおけるコンテキストウィンドウの制約を回避するための 3 つの手法の 1 つとして、コンパクション および 構造化ノートテイキング と並べて提示している。
用法
サブエージェントは深い技術的作業を行うか、ツールを使って関連情報を探す。それぞれが広範に探索することもある（Anthropic はその規模を数万トークン以上としている）が、返すのは作業を凝縮・蒸留した要約だけであり、その量は多くの場合 1,000〜2,000 トークンだとされる。その結果、関心事が明確に分離される。詳細な検索コンテキストはサブエージェントの中に隔離されたままとなり、リードエージェントは結果の統合と分析に集中できる。
Anthropic の Claude Code のベストプラクティス文書は、同じ仕組みに 2 つの異なる役割を与えている。この 2 つを分けて考えるのが有用なのは、それぞれが新しいコンテキストの異なる性質に依拠しているからである。1 つ目は調査である。コードベースを調べるには多くのファイルを読む必要があり、そのどれもがメインの会話のコンテキストを消費するため、調査をサブエージェントに委ね、別個に探索させて要約を報告させれば、メインのウィンドウを実装のためにクリーンに保てる。これは上で述べたコンテキスト節約の議論を、リサーチではなくコーディングの場面に置き換えて述べ直したものである。
2 つ目は敵対的レビューであり、ここでの価値は節約ではなく独立性にある。新しいサブエージェントのコンテキストで動くレビュアーは、与えられた差分と基準だけを見て、その変更を生み出した推論は見ないため、結果をそれ自体の基準で評価する。文書の捉え方では、エージェントが無人で長く作業するほど、その作業を完了とみなす前の独立したチェックが重要になる。レビュアーはサブエージェントとして動くので、その指摘は実装を行っているセッションに直接返され、人間がウィンドウ間で指摘を運ばなくても、そのセッションが修正して再レビューできる。
同じ文書は 2 つ目の用途の失敗モードもはっきり述べており、これはパターンと併せて記録しておく価値のある注意点である。欠陥を見つけるよう指示されたレビュアーは、作業に問題がない場合でも、それが求められたことである以上、たいてい何かしら報告してくる。すべての指摘を追いかけると過剰設計（余分な抽象化レイヤー、防御的なコード、起こりえないケースのためのテスト）につながるとされ、推奨される緩和策は、正しさや明示された要件に影響する欠陥だけを指摘するようレビュアーに指示し、それ以外は任意として扱うことである。
3 つ目の記述である 私たちはマルチエージェントのリサーチシステムをどう構築したか は、同じ構成を実際に出荷された形で説明し、それをオーケストレーター・ワーカーパターンと名付けている。リードエージェントがユーザーのクエリを分析し、戦略を立て、異なる側面を同時に探索するサブエージェントを生成する。サブエージェントは知的なフィルターとして働き、検索ツールを反復的に使って得た知見を返し、リードエージェントはそれを統合したうえで、さらなる調査が必要かどうかを判断する。この本番システムの 2 つの詳細は、パターンの形ではなく、それを長時間動かすことに固有のものである。1 つは、コンテキストウィンドウが 200,000 トークンを超えると切り詰められるため、リードエージェントが計画をメモリに保存すること、もう 1 つは、最後に別個の CitationAgent が文書とレポートの草稿を処理し、引用を置くべき箇所を特定することである。この記事は構成全体を、検索拡張生成（Retrieval Augmented Generation）の静的な検索（クエリに最も類似したチャンクを取得すること）と対比し、知見が得られるにつれて適応する多段階の検索を支持している。
この記述は、パターンがなぜ機能するのかについて、巧妙さではなく容量にかかわる説明も与えている。BrowseComp 評価において、チームは性能のばらつきの 95% を説明する 3 つの要因を報告しており、トークン使用量だけで 80% を説明し、残りの 2 つはツール呼び出しの回数とモデルの選択である。チームはこれを、作業を別々のコンテキストウィンドウに分散して並列の推論容量を加えるアーキテクチャの妥当性を裏付けるものと読んでいる。
4 つ目の記述はベンダー側ではなく導入する側からのものであり、このパターンをリサーチではなく通常のプロダクト開発に適用している。エンジニア2人 × AI で回すプロダクト開発 — “開発プロセスの半分以上をAIが主導的に行う” 体制の実践 は、37 個の Skill と 24 個の SubAgent を運用する 2 人のエンジニアのチームを描いている。そこでは Skill が専門知識や求められる振る舞い（どの順序で物事を行うか、品質の基準は何か、失敗したときに何をするか）を定義し、SubAgent は 1 つの領域を担う専門エージェントで、それ自体が Skill を使うこともある。メインエージェントは Skill を使って SubAgent をオーケストレーションし、その構成はクエリごとではなくフェーズごとである。ビジネス要件には 3 つの SubAgent（analyzer、generator、validator）、技術設計とタスク分割にまたがって 7 つ、実装には言語に応じて選ばれるさらに一群があり、加えて 2 つのレビュアーが並列に実行される。
1 つのエージェントに仕事全体を任せないのはなぜかという問いに対するこの記事の答えは、同じコンテキストの議論を実践の側から述べたものである。1 つのエージェントがすべてを行うとコンテキストが膨れ上がって性能が落ちるが、専門家に分割すれば出力品質が安定する。そしてベンダー側のどの記述もアーキテクチャの根拠としては挙げていない 2 つ目の運用上の理由として、失敗したフェーズを実行全体ではなくそのフェーズだけやり直せることを加えている（Anthropic も別の箇所で実行途中からの回復を扱ってはいるが、それは作業を分割する理由としてではなく、そのシステムが備えるよう構築された性質としてである）。この記事はまた、サブエージェントを互いに独立させておくための具体的な仕組みも示している。これは自らの考案とせず、以前の記事の定式化として紹介しているものである。各タスクファイルは自己完結するように書かれ、独自のスキーマ、API 仕様、そして Given-When-Then 形式の完全なテスト項目を含むため、実装時に設計書を参照する必要がまったくない。記事が挙げる理由は、これらのタスクは別々のセッションで並列に実装されるので、タスク間のコンテキスト依存はゼロでなければならないというものであり、エージェント間のインターフェースとなるのは会話ではなくファイルである。
5 つ目の記述は他のものより範囲が狭く、そもそもサブエージェントがどのように選ばれるのかを扱っている。AIコードレビューを「単一責任の原則」で育てた話 は、各サブエージェントを Markdown ファイル（フロントマターに名前、description、モデル設定を、本文にシステムプロンプトを置く）として定義しているチームを紹介し、オーケストレーションを行うエージェントがそれらの description フィールドを読んでどれを実行するかを選ぶと報告している。この記述によれば、トリガー条件は description とは別の場所で設定されるのではなく、このサブエージェントを選ぶべきファイルパターンの明示的なリストとして description の中に書き込まれる。したがって description を具体的に書くことそのものがディスパッチの仕組みであり、抽象的な description は、呼び出されるべきときに呼び出されないことと、不要なときに呼び出されることの両方の原因として挙げられている。チームは各 description をサブエージェント自身のシステムプロンプトからモデルに書かせる一方で、それが意図どおりに呼び出されるかどうかは別の問題として、テスト用のプルリクエストを作成して経験的に確かめていると報告している。明確なファイルパターンのトリガーはオーケストレーターにとって判断しやすいが、それ以外のケースはそうではないからである。
6 つ目の記述である Jimmy Song のオンラインハンドブック『智能体构建指南』の草稿章は、このパターンを AI プログラミング向けに述べ直し、その動機として、単一エージェントのコンテキストは会話が進むにつれて膨らみ、メインスレッドを汚染することを挙げている。同章はサブエージェントを、専門化されコンテキストが隔離されたサブロールとして説明する。それぞれが明確に定義されたサブタスクを自身のコンテキストで完了し、その結果がメインスレッドに集約される。また、Claude Code などのプラットフォームがこれを製品機能にしたと述べている。同章は 4 つの利点を挙げている。コンテキストの隔離、専門化（各サブエージェントに、依存関係のアップグレード、コードレビュー、i18n チェックといった 1 つのアトミックな責務を与える）、再利用とガバナンス（ツールや権限の境界を設定できるプロジェクトレベルまたはユーザーレベルの設定による）、そして合成（信頼性と検証可能性のために、複数のサブエージェントをワークフローとして順に実行する）である。
同章は、サブエージェントが呼び出される方法を 3 つ挙げている。プラットフォームがサブエージェントの description をコンテキストと照合する自動委任、プロンプト内での明示的な呼び出し、そしてトリガー条件とデフォルトの振る舞いを記述して呼び出しをより決定的にする .claude/agents/*.md などの設定ファイルである。設計上のポイントとしては、アトミックな粒度、メインスレッドや他のサブエージェントがデータを渡せるようにするための、サブエージェントが生成するファイルパスを含む入出力の宣言、一時ディレクトリの下などへの中間結果の明示的なファイル書き出し（読み書きの権限とファイル名は description に記述する）、自動委任で選ばれる頻度を高めるための description 中の use PROACTIVELY や MUST BE USED といったキーワード、そして安全性のガバナンスのためのサブエージェントごとのモデルとツールの個別設定を挙げている。その実例は、ドメインモデルにフィールドを追加するための再利用可能なワークフローであり、依存関係アップグレード担当、ドメインモデルのフィールド拡張担当、Maven ビルドの専門家、テスト担当という 4 つのサブエージェントを順に実行し、それぞれの出力が次の入力となって、最後にメインエージェントまたは検証エージェントが最終的な準拠チェックを行う。
適用範囲
-
並列の探索が成果をもたらす、複雑なリサーチや分析に適用される。Anthropic はこれを、広範なやり取りを要するタスクに推奨するコンパクション、および明確なマイルストーンを伴う反復的な開発に推奨するノートテイキングと対比している。
-
高レベルの計画を保持するメインエージェントと、新しいコンテキストウィンドウで焦点を絞ったタスクを与えられるサブエージェントがあること、そして各サブエージェントが作業コンテキスト全体ではなく蒸留した要約を返すという取り決めがあることを前提とする。
-
Anthropic は、このパターンが複雑なリサーチタスクにおいて単一エージェントのシステムを大きく上回る改善を示したと報告している。同社のリサーチ機能に関するエンジニアリング記事は、この主張に数値と構成を与えている。Claude Opus 4 をリードエージェント、Claude Sonnet 4 をサブエージェントとするシステムが、チームの社内リサーチ評価において単一エージェントの Claude Opus 4 を 90.2% 上回り、とりわけ複数の独立した方向を同時に追う幅優先型のクエリで優れていたとされる。示されている実例は、情報技術セクターの S&P 500 企業の取締役全員を特定するというもので、単一エージェントのシステムは遅い逐次的な検索によってこれに答えられなかった。この数値の裏にある評価そのものは説明されていないため、その難易度や対象範囲をここから確認することはできない。
-
追加する容量に比例してトークンを消費する。同じ記事によれば、エージェントは通常チャットのやり取りの約 4 倍、マルチエージェントシステムは約 15 倍のトークンを使うため、この構成には性能に見合う対価を払えるだけの価値あるタスクが必要となる。
-
すべての領域に適合するわけではない。同記事は現時点で適合しにくいものとして、すべてのエージェントが同じコンテキストを共有する必要がある領域や、エージェント間に多くの依存関係を伴う領域を挙げ、とくにほとんどのコーディングタスクを名指ししている。その根拠は、コーディングタスクにはリサーチに比べて真に並列化できるサブタスクが少ないこと、そしてエージェントはまだリアルタイムで互いに調整し委任し合うのが得意ではないことである。
-
上で紹介した導入側の記述は、この最後の点に対する直接的な反証となっており、両者は折り合いをつけるよりも併せて読む価値がある。この記述は、要件定義からプルリクエストのレビューに至るコーディングのパイプライン全体でこのパターンを運用し（リリースは今後の課題リストに残っている）、3〜4 個のタスクを並列に維持していると報告している。各タスクファイルを自己完結させ、各実行をそれぞれ独自の
git worktreeとセッションに隔離することで Anthropic が挙げる依存関係を取り除いており、並列のタスクストリーム間の調整は実行時に交渉されるのではなく、タスクを書く時点で事前に決着している。単一のタスク実行の内部では、調整は依然としてリアルタイムかつ集中的である。オーケストレーター役の Skill がタスクに必要な専門の SubAgent を選んで起動し、結果を判断し、修正を再委任する。したがってこの構成が移し替えているのはタスク間の依存関係であって、エージェント同士の調整そのものではない。どちらの側も測定されてはいない。導入側のチームは並列コーディングの主張を裏付ける評価なしに自らの構成を報告しており、ベンダー側の領域適合性の限界も、同じ記事の他の箇所にある数値とは異なり、評価の裏付けなしに述べられた一般的な記述である。したがって導入側の記述が示しているのは、この限界がタスクの切り方次第であるということであって、それが誤りだということではない。 -
前提とするのではなく、プロンプトによって抑え込む必要のある調整コストを伴う。同システムの初期バージョンは、単純なクエリに対して 50 個のサブエージェントを生成したり、タスクの説明が曖昧なときに互いの作業を重複させたりしたと報告されており、チームはこれをアーキテクチャの変更ではなく、明示的な労力スケーリングのルールと詳細な委任指示によって解決した。
-
その実装の限界として挙げられているのが同期実行である。リードエージェントはサブエージェントの各セットが終わるのを待つため、調整は単純になるが、途中でそれらを誘導することはできず、サブエージェント同士が調整し合うこともできず、1 つの遅いサブエージェントがシステム全体を止めてしまう。
-
上で紹介したハンドブックの章は、独自に 3 つのコストを挙げている。サブエージェントを起動するたびにコンテキストとリソースを再読み込みしなければならないことによるレイテンシ、隔離を保つためにサブエージェントは通常メインスレッドの完全なコンテキストを継承しないので、パラメータやファイルを明示的に渡さなければならないというコンテキスト切り替えのコスト、そしてチームのサブエージェントライブラリは重複や衝突を避けるためにキュレーションと規約を必要とするという保守性である。
関連用語
- コンパクション
- 構造化ノートテイキング
- コンテキストエンジニアリング
- コードレビューエージェント — 上記のレビュー用途を、それ自体として主題にしたもの
- LLM-as-a-Judge — 同じ独立性の議論を評価に適用したもの
- Claude Code — その文書が上記の 2 つの用途を説明しているツール