マルチエージェントオーケストレーション

Coordinator-Subagent パターンによるマルチエージェントオーケストレーションは、CCA-F（Claude Certified Architect Foundations）試験における最も頻繁に問われる設計パターンであり、CCA-F Domain 1（エージェンティックアーキテクチャとオーケストレーション、試験全体の27%）の中核に位置する。タスクステートメント1.2「coordinator-subagent パターンによるマルチエージェントシステムのオーケストレーション」は、マルチエージェント研究システムシナリオクラスターに直接現れ、ワークフローが2つ以上の論理ステップを持つすべての他のシナリオにも概念が流れ込む。coordinator がどのように委任するか、coordinator と subagent の間でコンテキストがどのように流れる（または流れない）か、並列 Task 呼び出しがどのように組み合わさるかを誤読すると、受験ごとに少なくとも3問で試験が求める特定の解答を逃す。

本章節では CCA-F 受験者が推論できることを期待される全表面をカバーする。ハブアンドスポークのアーキテクチャ形状・分離された subagent コンテキストの保証・分解と合成における coordinator の責務・Task ツールと AgentDefinition のスコープ・並列 vs 逐次ディスパッチ・反復精錬ループ・coordinator が分解しすぎてクロスカッティングシグナルを見失う高頻度の失敗モード——すべてを解説する。すべてのセクションはマルチエージェント研究システムシナリオとその最も問われる試験トラップにマッピングされる。

Claude におけるマルチエージェントオーケストレーションとは何か

Coordinator-Subagent パターンによるマルチエージェントオーケストレーションは、複雑なタスクを2つ以上の Claude エージェントインスタンスに分割するアーキテクチャアプローチを指す。coordinator はトップレベルの目標を所有し、subagent はそれぞれがより狭い責務を所有する。coordinator は subagent の作業を自身で行わない。計画し、ディスパッチし、合成する。subagent が実行する。この分割は、単一の Claude コンテキストウィンドウが有限の容量を持ち、単一の線形会話が分岐した探索の並列化や分離を有用に行えないため存在する。

試験において、マルチエージェントオーケストレーションは抽象的なアーキテクチャ図としてテストされることはない。常に具体的なシナリオ——最も一般的なのはマルチエージェント研究システムシナリオ——を通じてテストされる。coordinator が複合的な調査質問に答えるために複数の subagent をそれぞれ独立して異なるサブ質問の調査に派遣し、その結果を1つの合成された答えに折り込むシナリオだ。試験は委任のメカニズムを理解する受験者を評価する：subagent がどのように生成されるか、どのコンテキストを継承し継承しないか、結果がどのように返るか、そして coordinator はそれらの結果でどうすることを義務付けられているか。

なぜマルチエージェントで、大きな1つのプロンプトではないのか

単一セッションエージェントしか構築したことのない受験者は、すべてを行うよう1つの Claude インスタンスにプロンプトするだけで、なぜ調整オーバーヘッドを導入するのかとよく尋ねる。マルチエージェント設計を駆動する4つの構造的理由があり、すべてが試験シナリオに現れる。

• コンテキスト分離。 行き詰まった検索パスを探索する subagent は、無関係なツール結果で coordinator のコンテキストを汚染しない。
• 並列性。 独立したサブタスクを同時にディスパッチでき、実際の経過時間レイテンシを削減する。
• 専門化。 subagent には汎用的な coordinator が使うものよりも狭い allowedTools リストとより集中したシステムプロンプトを与えられる。
• スケール。 単一のコンテキストウィンドウを超えるような研究タスクが、各 subagent が関連するサブ質問のスライスのみを消費することで扱えるようになる。

マルチエージェント研究システムシナリオは1つの複合的な質問でこれら4つの理由すべてを行使するため、それらを内在化することは素早く報われる。

ハブアンドスポーク：正典的な Coordinator-Subagent の形状

ハブアンドスポークパターンは CCA-F 試験がデフォルトで想定するアーキテクチャ形状だ。

ハブとスポークの比較

ハブ（coordinator）はフルのユーザーリクエスト・計画・未完了/完了のサブタスクリスト・集計された結果を保持する。エンドユーザーと話すのはハブだけだ。各スポークは狭いブリーフを受け取り、独自のエージェンティックループを実行し、構造化された結果を返す。スポークは互いに話さず、ハブのより広いコンテキストを見ない。

なぜハブアンドスポークでメッシュではないのか

試験がハブアンドスポークを一貫して好む理由は、メッシュトポロジーが3つの失敗モードを複合するからだ——コンテキストブリード（ピアが互いの行き詰まりを継承する）・調整の曖昧さ（最終答えを誰が合成するか？）・エラー帰属（1つのピアが別のピアを汚染した場合に追跡不可能）。ハブアンドスポークは合成を1箇所に保ち、すべての失敗モードを各スポークに局所化する。

マルチエージェント研究システムシナリオにおけるハブアンドスポーク

試験が行使する具体的なシナリオ：ユーザーが研究 coordinator に「過去10年間の Kubernetes・Terraform・Redis のオープンソースライセンス戦略を比較し、ベンダー持続可能性リスクへの影響を要約せよ」と尋ねる。単一の Claude インスタンスでは、3つのプロジェクトをすべて探索するとコンテキストが枯渇し、一貫した比較を生成できない。coordinator は代わりに：

1. 3つのサブ質問——各プロジェクト1つ——と4番目の「クロスプロジェクト合成」サブタスクに分解する。
2. 3つの subagent を並列でディスパッチし、それぞれが1つのプロジェクトの狭いブリーフを持つ。
3. 3つすべての subagent の結果が返るまで待つ。
4. 4番目の subagent を実行（または自身で作業）してクロスカッティングパターンを合成する。
5. ユーザーに1つのまとまった答えを返す。

試験はこの正確な形をテストし、各ステップで coordinator の責務を特定できる受験者を評価する。

Coordinator の責務

coordinator は「賢い方」で subagent は「単純な方」ではない。どちらも同じ Claude モデルクラスで実行される。coordinator の役割は認知的ではなく構造的だ。7つの明示的な責務がある。

責務1：分解

coordinator は元のユーザーリクエストを計画に変換する——各サブタスクが実行中に意図を明確化する必要なく単一の subagent が実行できるほど具体的なサブタスクのリスト。良い分解は独立した（一方の結果が他方の実行をブロックしない）・スコープが明確な（完了の定義が明確）・重複しない（2つのサブタスクが同じ事実を返さない）サブタスクを生む。

責務2：ブリーフの作成

すべてのサブタスクについて、coordinator が subagent のブリーフを書く——subagent の会話を初期化するユーザーターンに相当するものだ。ブリーフは自己完結していなければならない。subagent が coordinator のコンテキストを見ないからだ。ブリーフの作成は coordinator が実行する最もレバレッジの高い活動であり、タスクステートメント1.3（subagent の呼び出し・コンテキスト渡し・生成の設定）の下で試験が最も積極的にテストするスキルだ。

責務3：ディスパッチ

coordinator は subagent ごとに1回 Task ツール（または SDK の同等物）を呼び出す。サブタスクが独立している場合は並列で、下流のサブタスクが上流の結果に依存する場合は逐次的に。ディスパッチは「呼び出して忘れる」ではない——coordinator はどのスポークが進行中でどれが返ってきたかのメンタルマップを保持する。

責務4：集計

subagent の結果が返ってくると、coordinator がそれらを集計する。集計は合成ではない。集計とは、どの subagent がどのクレームを生成したかを保持する方法で構造化された出力を coordinator のコンテキストに収集することだ。試験はこれを Domain 5.6（情報来歴）の下でテストする——どの subagent が何を言ったかを見失う coordinator は、競合するクレームについて推論できない。

責務5：合成

必要なすべての subagent の結果が揃ったら、coordinator が元のユーザーリクエストに答える単一の回答にそれらを合成する。合成には結果の相互参照（「Subagent A は X と言い、Subagent B は Y と言う——これらは一致しているか？」）、競合の解決、またはフォローアップのディスパッチを必要とするギャップの特定が必要な場合がある。

責務6：エラー処理と再試行

subagent が構造化されたエラーまたは曖昧な部分的な結果を返した場合、coordinator は精錬されたブリーフで再試行するか、異なるアプローチで新しい subagent をディスパッチするか、またはユーザーにエスカレートするかを決定する。これは下のセクションでカバーする反復精錬ループだ。

責務7：最終応答

coordinator がエンドユーザーへの最終メッセージの唯一の作者だ。subagent はユーザーと直接話さない。この制約は、個々の subagent がそうでなくても coordinator がフルの話を持っているため、subagent のコンテキスト分離が生き残れる理由だ。

分離された Subagent コンテキスト：最も問われるメカニズム

分離された subagent コンテキストは、単一エージェントの tool use のみを研究した受験者が最も見逃す CCA-F の概念だ。試験がこの点を徹底的にテストするのは、正しいメンタルモデルがコンテキストが自然に蓄積するマルチターンアシスタントを構築したことのある人には直感に反するからだ。

「分離された」が実際に意味すること

coordinator が Task ツールを通じて subagent をディスパッチするとき、subagent は新鮮な会話から始まる——元のユーザーメッセージなし・coordinator のシステムプロンプトなし・他の subagent のブリーフなし・以前の coordinator のツール呼び出しやターンなし。subagent がまさに2つのものを見る：AgentDefinition（システムプロンプト・ツール・モデル）と Task 呼び出しのタスクの説明。

分離が特徴である理由

分離こそがマルチエージェントオーケストレーションをスケールさせるものだ。すべての subagent が coordinator のフル履歴を継承するなら、各 subagent はコンテキストがほぼ満杯の状態から開始する。分離はまた、ノイジーな coordinator が subagent の推論を偏らせることを防ぎ、coordinator がコンテキストの衝突なしに多くの subagent を並列でディスパッチできるようにする。

トラップ：コンテキストが下に流れると想定する

最高頻度の CCA-F トラップは、subagent が「coordinator が知っていることを知っている」と想定することだ。coordinator がターン3で事実を学び、ターン5で subagent をディスパッチするが、ブリーフでその事実を言い直さない。subagent はターン3の知識にアクセスできず、ハルシネートするかまたはユーザーが答えられない質問をする。

正しいパターン：subagent が必要とするすべてのものがブリーフの中になければならない。 coordinator が以前のツール呼び出しから重要な事実を学んだ場合、その事実はすべてのディスパッチで言い直されなければならない。

fork_session との対比

Agent SDK は fork_session 機能を公開しているが、それは異なるセマンティクスを持つ別のメカニズムだ。フォークされたセッションは、会話の分岐がコミットすることなく代替パスを探索できるよう、その履歴を含むフルの会話をクローンする。フォーキングは subagent の生成と同じではない。生成された subagent は分離されている；フォークされたセッションはコピーだ。試験はこの区別を明示的にテストし、2つを混同する受験者を減点する。

Task ツール：ディスパッチのメカニズム

Task ツールは coordinator が subagent を生成する主要なインタフェースだ。

メカニズム

coordinator が Task を呼び出すと、Claude Code ランタイム（または Agent SDK）が新しい subagent セッションを立ち上げ、ターミナルの stop_reason になるまで独自のエージェンティックループを実行し、最終的なアシスタントメッセージを tool_result として返す。coordinator の観点から、Task は時間がかかりリッチな構造化された結果を返す1回のツール呼び出しだ。

Task ツールの引数

• subagent_type — 実行する AgentDefinition（システムプロンプト + 許可されたツール + モデルを選択する）。
• description — ログ / タスクリスト追跡の短いラベル。
• prompt — フルのタスクブリーフ、最初のユーザーターンのように書かれる。

最も一般的なミスは prompt の過少指定だ。「Redis のオープンソースライセンスを調査する」のようなブリーフは、どの年か・どの側面か・どの出力形式かを subagent に推測させる。subagent が必要とするすべてを言い直す。

並列ディスパッチ：1ターンでの複数の Task 呼び出し

coordinator は単一のアシスタントターンで複数の Task ツール呼び出しを発行できる。そうすると、ランタイムはそれらすべてを並列で実行し、次のユーザーターンにまとめて結果を返す。これがマルチエージェント研究システムシナリオが実際の経過時間レイテンシ削減を達成するメカニズムだ。

並列ディスパッチはサブタスクが真に独立していることを必要とする。Subagent B が Subagent A の結果をブリーフの作成に必要とする場合、coordinator はまず A をディスパッチし、A の返却を待ち、次に B をディスパッチしなければならない——1つの並列ターンではなく、2つの逐次ターンだ。

AgentDefinition と allowedTools

各 subagent は AgentDefinition——subagent のシステムプロンプト・allowedTools リスト・オプションでモデルを指定する設定オブジェクト——の下で実行される。allowedTools リストは意図的な制約だ：研究 subagent には WebSearch・WebFetch・Read が与えられるが Write や Bash は与えられない場合がある。ツール表面を狭めることで subagent の攻撃表面を削減し、注意を集中させ、そのスポークの外に伝播する偶発的な副作用を防ぐ。

試験は Domain 2（ツール設計）の下で allowedTools をテストし、センシティブなタスクのために subagent をディスパッチするシナリオが含まれる場合に参照する。すべての subagent にフルのツールパレットを与える coordinator は一般的な誤答の形だ。

タスク分解戦略

タスク分解は、subagent がディスパッチされる前に coordinator が行う計画だ。良い分解はマルチエージェントの成功の最大の予測因子であり、タスクステートメント1.6で重点的に行使される。

良いサブタスクの基準

適切に形成されたサブタスクは独立（進行中の別のものを待たない）・スコープが明確（完了の定義が明確）・自己完結（ブリーフが必要なすべてのコンテキストを持つ）・非重複（2つのサブタスクが同じ事実を生成しない）・検証可能（coordinator が再実行なしにそれを確認できる）だ。

分解パターン

3つのパターンがほぼすべてのマルチエージェントシナリオをカバーする：

• エンティティ別 — 異なるエンティティごとに1つの subagent（ライセンス比較の例）。
• 側面別 — 分析の次元ごとに1つの subagent（セキュリティレビュー：認証に1つ・認可に1つ・入力検証に1つ）。
• ステージ別 — パイプラインステージごとに1つの subagent、逐次ディスパッチ（収集 → 抽出 → 相互参照）。

エンティティ別と側面別は自然に並列化する；ステージ別は本質的に逐次だ。

過度に狭い分解の失敗モード

試験のお気に入りのトラップ：coordinator が「3つのプロジェクトのライセンス戦略を比較する」を3つのサブタスク（プロジェクトごと）ではなく12のサブタスク（プロジェクトごと年ごと）に分割する。各年別の subagent は自身の狭いスライスについて合理的に見える事実を返すが、Project A のライセンシングが Project B の以前の動きに応じて変化したことに気づく subagent は1つもない。そのパターンは年ごとの粒度では見えず、プロジェクトごとの粒度でのみ現れる。

分解とチェーニングの比較

タスク分解（マルチエージェント）はプロンプトチェーニング（単一エージェント）とは異なる。プロンプトチェーニングは1つの Claude セッションを単一のコンテキスト内の複数の逐次プロンプトを通じて進める。分解は複数の分離された Claude セッションにまたがる。チェーニングはコンテキストを保持し；分解はそれを破棄する。試験はどちらに手を伸ばすかをテストする。

並列 Task 呼び出しと反復精錬ループ

並列ディスパッチはメカニズム的な側面であり；反復精錬は時間的な側面だ——coordinator がターンをまたいで subagent の結果を使用して最終答えを改善する方法。

並列ディスパッチのメカニズム

1つのアシスタントターンで coordinator が複数の Task 呼び出しを発行できる。ランタイムがそれらをファンアウトし、すべての並列 subagent がターミナルの stop_reason に達したとき、次のユーザーターンに並列 tool_result ブロックとしてすべての結果をまとめて返す。並列ディスパッチはサブタスクに依存関係がある場合は逐次に折り畳まれる——coordinator は1つの結果を待ってから次のブリーフを書かなければならない。

反復精錬ループ

subagent の結果の最初のラウンドが最終的であることはまれだ。ループ：計画 → ディスパッチ → 集計 → 評価 → 精錬 → 合成、coordinator がカバレッジを適切と判断するまでディスパッチから精錬を繰り返す。各反復はより対象を絞ったブリーフを生成する。coordinator が以前のラウンドで何を見逃したかを今や知っているからだ。タスクステートメント3.5の下でテストされ；マルチエージェント研究システムシナリオがその正典的な媒体だ。

反復を止めるタイミング

決して止まらない coordinator はコンテキストウィンドウを収穫逓減を追いかけて使い果たす。coordinator は停止基準を持たなければならない：カバレッジ基準（「すべてのサブ質問が少なくとも1つの subagent の結果で答えられた」）またはバジェット基準（「最大2つの精錬ラウンド」）のいずれか。試験シナリオは停止基準を間接的にテストすることが多い——無制限の反復を提案する選択肢は通常誤りだ。

Coordinator と Subagent の間のコンテキスト渡し

分離された subagent コンテキストがデフォルトであるため、コンテキスト渡しは coordinator が分離境界を越えて特定の情報を意図的に送り込むメカニズムだ。コンテキスト渡しは完全に Task ツールの prompt 引数を通じて起こる——暗黙のチャンネルはない。

渡すもの

最低限、すべての subagent のブリーフには次を含めるべきだ：

• サブタスクの目標。 特定の検証可能な成果として表現。
• スコープの境界。 subagent が拡張すべきでないもの。
• 出力形式。 coordinator が解析できるスキーマのような期待。
• subagent が独立して再発見できない関連する事実。 coordinator が以前のターンで学んだ事実。
• 許可されたツールとその期待される使用。 subagent に狭いツールリストがある場合、ブリーフは各ツールがいつ適切かのヒントを与えるべきだ。

渡すべきでないもの

ブリーフには含めるべきでない：

• フルの元のユーザーリクエスト（直接必要でない限り）。ユーザー会話全体を再渡しすることは分解の目的を損なう。
• 他の subagent の結果（実際の依存関係がない限り）。subagent を相互汚染することは並列性の利点を損なう。
• coordinator の内部計画。 subagent は分解に疑問を持つべきでない。

出力形式の規律

coordinator の集計ステップは、すべての subagent が予測可能な形で結果を返す場合に最も容易だ。ブリーフは出力形式を明示的に指定すべきだ：「license_changes・timeline・sustainability_signals フィールドを持つ JSON オブジェクトを返す。」subagent がフリーフォームの散文を返す場合、coordinator は結論を合成する代わりに散文を解析するためにコンテキストバジェットを費やす。

エラーの伝播と回復

subagent は失敗する。coordinator はそれらの失敗を処理しなければならない。CCA-F はタスクステートメント5.3の下でマルチエージェントシステムのエラー処理をテストする。

失敗モード

試験シナリオに現れる3つの一般的な subagent の失敗モード。

• ツールレベルのエラー。 subagent のツール呼び出しが失敗する（ネットワークタイムアウト・権限拒否・不正な形式の応答）。subagent は何が失敗したかを説明する構造化されたエラーを返すべきだ。
• タスクレベルの失敗。 subagent がループを完了するが要求された出力を生成できない（情報が利用できない・リクエストが曖昧・スコープが不十分）。
• stop_reason の不一致。 subagent が完了前に max_tokens または stop_sequences に達し、部分的な結果を返す。

構造化されたエラー応答

subagent がエラーを返す場合、coordinator が推論できる構造化された形で返すべきだ——エラーカテゴリ・再試行可能フラグ・人間が読めるな詳細。汎用的なエラー文字列を受け取る coordinator は、再試行するか・エスカレートするか・または中止するかを推測しなければならない。{ errorCategory: "transient", isRetryable: true, detail: "WebSearch がタイムアウトした" } を受け取る coordinator は決定論的に再試行できる。これは Domain 2.2（構造化されたエラー応答）に結びつき、試験で頻繁にテストされる。

Coordinator の回復戦略

subagent の失敗が与えられると、coordinator には4つの選択肢がある：

1. 同じブリーフで再試行 — エラーが一時的な場合。
2. 精錬されたブリーフで再試行 — エラーがブリーフが曖昧または過少指定だったことを示唆する場合。
3. 別の subagent をディスパッチ — 失敗が subagent タイプまたは許可されたツールが間違っていたことを示唆する場合。
4. 明示的なギャップを持つ部分的な合成 — 回復が非経済的でユーザーが正直な部分的な答えでより良く提供される場合。

試験シナリオは選択肢4をテストすることが多い——常に「再試行し続ける」にデフォルトする受験者は、正解が時々不完全な結果を受け入れることを含むと見逃す。

やさしい解説: マルチエージェントオーケストレーション

マルチエージェントオーケストレーションは、調整と分離がすでに身近な物理的システムに固定することで直感的になる。

Analogy 1: ニュースルーム — 編集長・記者・分離されたビート

ニュースルームには1人の編集長と多くの記者がいる。編集長は複雑な取材任務（「3つのスウィングステートの選挙結果を取材し、上院の多数派にとって何を意味するか説明せよ」）を受け取る。編集長はどのステートも個人的に取材しない。代わりに、編集長は3つのブリーフ——ス ウィングステートごとに1つ——を書き、3人の記者を派遣する。各記者は割り当てられたステートで独立して作業する：ミシガン担当記者はペンシルバニア担当記者のインタビューには同席せず、その逆も然り。記者は編集長に原稿を提出する。編集長は3つすべてを読み、クロスカッティングのパターンに気づき（「3つのステートすべてが同じように転じた」）、最終的なフロントページの合成記事を書く。

coordinator-subagent パターンのすべての部品にニュースルームの類比がある：

• Coordinator = 編集長。
• Subagent = 担当記者。
• ハブアンドスポーク = すべての記者が互いにではなく編集長に提出する。
• 分離された subagent コンテキスト = ミシガン担当記者はミシガンのブリーフだけを見る。
• Task のブリーフ = 編集長が各記者に渡す取材指示書。
• 並列ディスパッチ = 3人の記者が同時に作業する。
• 反復精錬 = 編集長が原稿を読み、欠けている角度に気づき、フォローアップのために記者を再派遣する。
• 過度に狭い分解 = 「選挙を取材する」を27の取材任務（郡ごとに1つ）に分割し、州全体の話を見る記者が1人もいないようにする。
• 合成 = 編集長の最終記事。

Analogy 2: キッチンブリゲード — エクスペダイター・ステーション・バーナー間の会話なし

忙しいサービスのレストランキッチンは異なる名前でハブアンドスポークパターンを実行する。エクスペダイター（またはヘッドシェフ）が伝票を読み、料理をコンポーネントに分解し、各ステーションにタスクを呼び出す：グリルコックがステーキを焼き・ソースステーションがジュをかけ・ガルドマンジェがサラダを仕上げる。各ステーションは独立して作業する——グリルコックはソースステーションに踏み込まない。エクスペダイターは戻ってきたすべてのコンポーネントから最終料理を盛りつける。

この類比は3つのメカニズムを明確にする：

• ステーション専門化 = AgentDefinition と allowedTools。グリルコックは鍋ではなくグリルを持つ。
• 並列実行 = 1ターンでの複数の Task 呼び出し。ステーキ・ソース・サラダがすべて同時に進む。
• 盛りつけのタイミング = エクスペダイターがすべてのコンポーネントが揃うまで待ってから盛りつける。coordinator も同様に合成する前にすべての並列 subagent を待つ。

パターンに違反するキッチン——グリルコックが盛りつけてソースステーションに話しかけることも許す——は混乱を生む。これが CCA-F 試験が警告するメッシュトポロジーだ。

Analogy 3: 研究図書館 — 館長と専門図書館員

利用者が館長に複合的な質問をする：「自由意志についての3人の哲学者の見解を比較した論文を書いています。何を読むべきですか？」館長は図書館内のすべての本を個人的に知ることができない。代わりに、館長は3人の専門図書館員——古代哲学専門・近世哲学専門・現代哲学専門——を派遣する。各専門家はそれぞれのセクションのみを検索し、厳選された読書リストを返す。館長は3つのリストを相互参照し、利用者に合成された参考文献を手渡す。

図書館の類比はコンテキスト渡しを説明するのに優れている。館長が現代専門家を派遣するとき、ブリーフに複合的な質問のコンテキストを含めなければならない——「利用者は2人の古代人と比較している」——現代専門家は他の専門家の作業を見ず、相互参照を独立して発見できないからだ。これがまさに「subagent が必要とするすべてのものがブリーフの中になければならない」ルールだ。

試験日にどの類比を使うか

• coordinator の責務と合成についての問題 → ニュースルームの類比。
• 並列ディスパッチ・ツール分離・専門化についての問題 → キッチンブリゲードの類比。
• コンテキスト渡しと分解の粒度についての問題 → 図書館の類比。

Agent Teams と Subagent：関連するが異なる2つの概念

Agent Teams（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS の下で出荷された機能）とsubagent（一般的な Claude Code および Agent SDK の機能）の間には微妙だが試験でテストされる区別がある。これらを混同する受験者はシナリオのニュアンスを見逃す。

Subagent（一般的なパターン）

Subagent はこの章節全体で説明した一般的なパターンだ：coordinator が Task ツールを通じて subagent を生成し、subagent が独立して実行し、subagent が結果を返す。subagent は最初の Agent SDK リリース以来利用可能であり、プロジェクト・ユーザー・プラグイン・CLI のスコープで AgentDefinition の設定を通じて定義される。

Agent Teams（Claude Code の機能）

Agent Teams は subagent メカニズムの上に構造化された調整プリミティブを追加する Claude Code の機能だ——チームメート生成・タスクリスト追跡・専門フック（TeammateIdle・TaskCreated・TaskCompleted）。Agent Teams は Agent SDK アプリケーション内の単一ターンのディスパッチではなく、Claude Code 内での長時間実行マルチセッション調整のために設計されている。

試験がどちらをテストしているか

シナリオが「数時間または数日にわたって他の Claude Code セッションを調整する Claude Code セッション」を説明する場合、Agent Teams をテストしている。シナリオが「coordinator が研究タスクをディスパッチする Agent SDK アプリケーション」を説明する場合、一般的な subagent をテストしている。ハブアンドスポークと分離されたコンテキストのメカニズムは両方に適用される。

マルチエージェントオーケストレーションの一般的な試験トラップ

Coordinator-Subagent パターンによるマルチエージェントオーケストレーションに関連する CCA-F シナリオには5つの繰り返し発生するトラップパターンがある。

トラップ 1: Subagent が Coordinator のコンテキストを継承すると想定する

最頻度のトラップ。選択肢は subagent が coordinator が知っていることを知っていると暗黙的に想定する。正解はブリーフを通じた常に明示的なコンテキスト渡しを必要とする。「subagent は自動的に以前の会話を見る」と言う選択肢は誤りだ。

トラップ 2: 過度に狭い分解

以前に独自のコールアウトでカバーした。シナリオが多くの小さなタスクの分解を提示し、なぜ合成が浅いかを尋ねる。誤答は coordinator のモデルを責める；正答は分解の粒度を特定する。

トラップ 3: 合理的なデフォルトとしてのメッシュトポロジー

選択肢はピアツーピアの subagent 通信を設計として提案する。ハブアンドスポークは Claude 推奨のデフォルトだ；メッシュが正解であることはまれで、シナリオが明示的にピア調整を必要とする場合（CCA-F スコープではほぼない）にのみ勝つ。

トラップ 4: 無制限の反復精錬

選択肢は「答えが完璧になるまでフォローアップ subagent を派遣し続ける」と提案する。実際のワークフローには停止基準が必要だ。無制限の反復を説明する選択肢は通常誤りだ。

トラップ 5: fork_session と Subagent ディスパッチの混同

選択肢は fork_session と Task を互換的に使用する。それらは異なるメカニズムだ——フォーキングはコンテキストをクローンし、ディスパッチは新鮮な分離されたコンテキストを作成する。シナリオが分離を求める場合、答えは Task（subagent を生成する）だ。シナリオが現在の会話の代替ブランチを探索することを求める場合、答えは fork_session だ。

実践アンカー：マルチエージェント研究システムシナリオ問題テンプレート

Coordinator-Subagent パターンによるマルチエージェントオーケストレーションに関連する CCA-F 練習問題は5つの形にまとまる。各形はマルチエージェント研究システムシナリオにクリーンにマッピングされる。

テンプレート A: コンテキスト分離の認識

coordinator エージェントがターン3でユーザーの会社が EU で運営されており厳格な GDPR 要件があることを学ぶ。ターン5で、coordinator が利用可能なベンダー API を調査するために subagent をディスパッチする。subagent はいくつかの米国のみのベンダーを含むリストを返す。最も可能性の高い根本原因は何か？正解：coordinator が subagent のブリーフに EU/GDPR の制約を渡さなかったため、subagent の分離されたコンテキストではその制約を独立して知ることができなかった。

テンプレート B: 分解粒度の選択

研究 coordinator が10年間にわたって3つのオープンソースプロジェクトを比較しなければならない。どの分解が最良のクロスプロジェクト合成を生むか？正解：プロジェクトごとに3つの subagent。誤答には30の subagent（プロジェクトごと年ごと——過度に狭い）と単一のモノリシック subagent（過少分解、コンテキストを使い果たす）が含まれる。

テンプレート C: 並列 vs 逐次ディスパッチ

サブタスク B がサブタスク A の出力を必要とする。coordinator はどのようにディスパッチすべきか？正解：1ターンでタスク A を実行し、結果を待ち、その後の別のターンでタスク B を実行する。両方を1ターンで並列にディスパッチする答えは、B のブリーフにまだ A の結果を含められないため誤りだ。

テンプレート D: Subagent の失敗からの回復

subagent が { errorCategory: "transient", isRetryable: true } を返す。coordinator は何をすべきか？正解：同じブリーフで再試行する。エラーが { errorCategory: "permission", isRetryable: false } だった場合、正解は調整された allowedTools を持つ別の subagent をディスパッチするかエスカレートするにシフトする。

テンプレート E: Task と fork_session の選択

coordinator は現在の状態に戻る能力を保ちながら、現在の研究質問の代替的な言い回しを探索したい。どのメカニズムが適用されるか？正解：fork_session——目標は分離されたサブタスクをディスパッチするのではなく、現在の会話を分岐させることだからだ。

記憶すべき数字とパターン

マルチエージェントオーケストレーション よくある質問（FAQ）

Claude における coordinator と subagent の違いは何か？

同じモデルで実行される。違いは認知的ではなく構造的だ。coordinator は元のユーザーリクエストを所有し、分解を実行し、Task ツールを通じて subagent をディスパッチし、返された結果を集計し、最終答えを書く。subagent は孤立したエージェンティックループを狭いブリーフに対して実行し、1つの構造化された結果を coordinator に返す。subagent はエンドユーザーと話さず、互いに話さない。coordinator はエンドツーエンドのステートの唯一の所有者であり、最終応答の唯一の作者だ。

subagent は coordinator の会話履歴を継承するか？

しない。これが最も問われる CCA-F のメカニズムだ。subagent は AgentDefinition（システムプロンプト・ツール・モデル）と coordinator が Task ツール呼び出しで渡したタスクの説明のみが含まれる新鮮な会話から始まる。coordinator の以前のターン・元のユーザーメッセージ・他の subagent の結果は subagent には見えない。subagent が必要とするすべてのものはブリーフで明示的に言い直されなければならない。コンテキストがハブアンドスポーク階層を下に流れると想定する受験者は壊れたシステムを設計し、試験の問題を見逃す。

subagent を並列でディスパッチすべきか逐次的にすべきか？

サブタスクが真に独立している場合——どちらのサブタスクのブリーフも他方の出力を必要としない——は並列でディスパッチする。単一のアシスタントターンで複数の Task ツール呼び出しを発行し、ランタイムがそれらを同時にファンアウトする。下流のサブタスクのブリーフが上流の結果に依存する場合は逐次的にディスパッチする——最初の Task を1ターンで呼び出し、その返却を待ち、次の Task を後続のターンで呼び出す。ほとんどのマルチエージェント研究システムシナリオは最初の分解に並列ディスパッチを使用し、精錬ラウンドに逐次ディスパッチを使用する。

Task ツールと fork_session の違いは何か？

Task は履歴なしの新しい分離された subagent セッションを作成する——ハブアンドスポークのディスパッチメカニズム。fork_session は現在のセッションをクローンし、ブランチが必要に応じてフォーク前の状態に戻る能力を保ちながらコミットせずに代替パスを探索できるようにする。それらは互換的ではない。分離と並列性を求めるときは Task を使用する。現在の会話で仮説を探索し、バックトラックする能力を保ちたいときは fork_session を使用する。CCA-F 試験シナリオはその区別を直接テストする。

なぜ CCA-F 試験はメッシュトポロジーよりハブアンドスポークを好むのか？

メッシュトポロジー——ピアツーピアの subagent 通信——は3つの失敗モードを複合する：ピア間のコンテキストブリード・最終合成を誰が所有するかについての調整の曖昧さ・何かがうまくいかない場合のエラー帰属の困難さ。ハブアンドスポークは合成の権限を1箇所（coordinator）に保ち、すべての subagent の失敗モードをそれ自身のスポークに局所化する。Claude の Agent SDK と Agent Teams のドキュメントはどちらもハブアンドスポークをデフォルトとして推奨する。メッシュトポロジーを提案する選択肢は試験でほぼ常に誤りだ。

タスクを分解しすぎるとどうなるか？

過度に狭い分解は、それぞれが自分の狭いスライスについて正確に見える答えを返す多くの小さなサブタスクを生むが、クロスカッティングパターンに気づくのに十分なコンテキストを持つ subagent が1つもいない。coordinator の合成ステップはそれから証拠がより広いパターンをキャプチャしなかったため浅い最終答えを生む。修正は各 subagent がそのスライス内のパターンを見るのに十分なコンテキストを保持できるよう分解の粒度を粗くすることだ。モノリシックなプロンプトから過剰修正した受験者が反対の失敗モードに陥るため、過度に狭い分解は一般的な CCA-F のトラップだ。

coordinator はいくつの精錬ラウンドを実行すべきか？

実用的なデフォルトは2ラウンドだ：ラウンド1が最初の分解をカバーし、ラウンド2がラウンド1の合成中に特定されたギャップに対処する。ラウンド2でもまだギャップが残る場合、第3ラウンドをディスパッチするのではなく残る不確実性を正直に述べた部分的な答えを返す。無制限の精錬は coordinator のコンテキストウィンドウを使い果たし、しばしば収穫逓減を生む。「完璧になるまで反復し続ける」を選択肢として提供する CCA-F シナリオは、停止基準が必要であることを認識するかをテストしている。

さらなる読み物

• Orchestrate teams of Claude Code sessions (Agent Teams): https://code.claude.com/docs/en/agent-teams
• Create custom subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Subagents in the Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Agent SDK overview: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Chain complex prompts for stronger performance: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/chain-prompts
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

関連 ExamLab 章節：エージェンティックループと自律タスク実行、Subagent の呼び出しとコンテキスト渡し、タスク分解戦略、セッション状態・再開・フォーキング、マルチエージェントシステムにおけるエラー伝播。