--- title: "Orchestrator-Subagentとは？Anthropic公式の協調5パターンとClaude Agent SDKでの実装" url: "https://www.issoh.co.jp/tech/details/12108/" published: 2026-05-14 updated: 2026-11-13 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # Orchestrator-Subagentとは？Anthropic公式の協調5パターンとClaude Agent SDKでの実装 Orchestrator-Subagentは、1体のorchestrator（lead agent）が仕事を分解し、境界のはっきりしたサブタスクを専用のコンテキストを持つsubagentへ任せ、戻ってきた結果を統合する構成です。Anthropicは2026年4月10日のブログ「[Multi-agent coordination patterns: Five approaches and when to use them](https://claude.com/blog/multi-agent-coordination-patterns)」で協調の型を5つに整理し、「For most use cases, we recommend starting with orchestrator-subagent.」と書いています。本記事は5パターンの違いを押さえたうえで、Claude Agent SDK（Python版0.2.180）での書き方、Claude Codeの機能との対応、2026年10〜11月に出た後続の公式記事が示す「subagentを減らす判断」までを扱います。 ## まとめ：Orchestrator-Subagentでの開始と課題に応じた他パターンへの移行 結論は、まずOrchestrator-Subagentで組み、問題が観測できた箇所だけ別の型へ移すことです。原文は5つを「building blocks, not mutually exclusive choices」と位置づけており、本番では組み合わせて使います。 | パターン | 向く仕事 | 崩れ方 | Claudeでの近い機能 | | --------------------- | -------------- | ------------------- | ------------------ | | Generator-Verifier | 合格基準を書き出せる出力 | 基準が曖昧で素通し | 検証用subagent | | Orchestrator-Subagent | 分解が明確で依存の少ない仕事 | orchestratorに情報が詰まる | subagent（Agentツール） | | Agent Teams | 独立した長時間の並列作業 | teammate同士の変更が衝突 | Agent Teams（実験機能） | | Message Bus | イベントから流れが決まる処理 | 誤配送で黙って失敗 | 該当機能なし（自前実装） | | Shared State | 発見を積み上げる共同調査 | 反応の応酬が止まらない | 共有ストアを自前で用意 | そもそも複数のエージェントに分けるべきかは、この5つを選ぶ前の判断です。Anthropicの2026年1月23日の記事は、同じ仕事でマルチエージェントはシングルの3〜10倍のトークンを使うと書いています。分けるかどうかの判断基準は[シングルエージェントとは？マルチエージェントとの違いと使い分けの判断基準](/tech/details/4261/)、マルチエージェント全体の構成は[マルチエージェントとは？仕組み・構成パターンと採用判断](/tech/details/13604/)で扱っています。 ## Orchestrator-Subagentの仕組み：orchestratorとsubagentの役割分担 原文は「Hierarchy defines this pattern.」と書き出しています。orchestratorは計画・委譲・統合を担い、一部のサブタスクは自分で処理し、残りをsubagentへ出します。subagentは自分のコンテキストウィンドウで作業し、要約した結果だけを返します。orchestratorの文脈が探索の途中経過で埋まらないことが、この型の利点の中心です。 ### orchestratorとsubagentの違い | 項目 | orchestrator | subagent | | ------ | ------------- | --------------------------- | | 役割 | 分解・割り当て・統合 | 1つのサブタスクの実行 | | 受け取る情報 | ユーザーの依頼と全体の会話 | 非forkは委譲指示・定義等／forkは親の会話も継承 | | 寿命 | セッションの間ずっと | 結果を返したら終了 | | 返すもの | 最終成果物 | 要約された結果 | 2つ目の行は実装で最も効く点です。[Claude Agent SDKのsubagentドキュメント](https://code.claude.com/docs/en/agent-sdk/subagents)は、fork以外のsubagentについて、親から渡す会話内容はAgentツールのprompt文字列だと説明しています。forkは例外として親の会話履歴を継承します。fork以外では親の会話履歴やツール結果が見えないので、ファイルパス、エラーメッセージ、決定済みの前提は委譲の指示文に書き込む必要があります。 ### 原文が挙げる適用例：Claude Codeと自動コードレビュー 原文はClaude Code自体がこの型だと説明しています。メインのエージェントがコード編集やコマンド実行を自分で行い、大きなコードベースの検索や独立した調査が要るときにsubagentをバックグラウンドで起動し、結果を受け取りながら作業を続けます。もう1つの例はPull Requestのレビューで、セキュリティ・テストカバレッジ・コードスタイル・アーキテクチャの整合をそれぞれ別のsubagentに調べさせ、orchestratorが1本のレビューにまとめます。検査ごとに必要な文脈が違い、出力の形もはっきりしているため、分け方に迷いません。 ### 弱点：情報の詰まりと、並列にしないと遅いだけになる点 原文は弱点を2つ挙げています。1つは、orchestratorが情報の通り道になることです。セキュリティ担当が見つけた認証の欠陥がアーキテクチャ担当の分析に関わる場合、その情報は一度orchestratorへ戻り、orchestratorが関連に気づいて回さないと届きません。中継が重なるほど細部が要約で落ちます。もう1つは直列実行です。明示的に並列にしない限りsubagentは1つずつ動き、トークンはマルチエージェント分かかるのに速くならない、と原文は書いています。サブタスク同士が頻繁に情報を渡し合うなら、この型は合っていません。 ## Claude Agent SDKによるOrchestrator-Subagentの実装 Claude Agent SDKでは、`ClaudeAgentOptions`の`agents`にsubagentの定義を渡し、Claudeが`Agent`ツールで呼び出します。次の例は原文のコードレビューの例を、読み取り専用の2体と、Bashを利用できるテスト担当1体で組んだものです。PyPIの[claude-agent-sdk](https://pypi.org/project/claude-agent-sdk/)の最新は0.2.180（2026年11月9日公開）で、定義に使っているフィールド名は同版の`AgentDefinition`と一致します。 ``` import asyncio from claude_agent_sdk import ( query, ClaudeAgentOptions, AgentDefinition, AssistantMessage, ToolUseBlock, ResultMessage, ) READ_ONLY = ["Read", "Grep", "Glob"] AGENTS = { "security-reviewer": AgentDefinition( description="変更差分のセキュリティ上の問題だけを調べる。PRレビューで使う。", prompt="認証・入力検証・秘密情報の混入だけを見る。指摘は ファイル:行 と根拠を1行ずつ返す。", tools=READ_ONLY, model="sonnet", maxTurns=20, ), "test-reviewer": AgentDefinition( description="変更に対するテストの不足だけを調べる。PRレビューで使う。", prompt="変更された関数ごとに、対応するテストの有無と欠けているケースを返す。", tools=READ_ONLY + ["Bash"], # テスト実行のためBashだけ足す model="sonnet", maxTurns=20, ), "style-reviewer": AgentDefinition( description="命名・構成など規約違反だけを調べる。PRレビューで使う。", prompt="リポジトリの規約ファイルに照らした違反だけを返す。好みの指摘はしない。", tools=READ_ONLY, model="haiku", maxTurns=10, ), } async def main(): options = ClaudeAgentOptions( allowed_tools=READ_ONLY + ["Agent"], # 委譲に使う Agent ツールも自動承認に入れる agents=AGENTS, max_turns=40, ) prompt = ("git diff main...HEAD の変更をレビューする。" "security-reviewer・test-reviewer・style-reviewer を並列に起動し、" "3つの報告が揃ってから重複を除いて重要度順に統合すること。") async for msg in query(prompt=prompt, options=options): if isinstance(msg, AssistantMessage): for block in msg.content: # v2.1.63より前は "Task"、現行は "Agent" で出る if isinstance(block, ToolUseBlock) and block.name in ("Agent", "Task"): print("委譲:", block.input.get("subagent_type")) elif isinstance(msg, ResultMessage): print(msg.result) if __name__ == "__main__": asyncio.run(main()) ``` 書くときの要点は3つあります。`description`はClaudeが「いつこのsubagentを使うか」を決める材料なので、担当範囲を1文で限定します。`tools`をRead・Grep・Globだけに制限すれば、レビュー役のファイル変更とコマンド実行を制限できます。ただし、この例のtest-reviewerにはBashがあるため、ツール一覧だけでは書き込み禁止を保証できません。指示文で「並列に起動」「報告が揃ってから統合」と書くのは、原文が指摘する直列化と途中統合を避けるためです。実行時はSDKの導入と認証を済ませ、mainとHEADを比較できるGitリポジトリを作業ディレクトリにします。テストコマンドを実行させる場合は、そのコマンドを承認する権限設定も必要です。 ### AgentDefinitionで指定できる項目 0.2.180の`AgentDefinition`のフィールドは次の13個です。Python版でも`disallowedTools`や`maxTurns`はcamelCaseのまま書きます（公式ドキュメントは通信形式に合わせるためと説明）。 | フィールド | 用途 | | ------------------------------------ | ------------------------------------- | | description（必須） | いつ使うかの説明 | | prompt（必須） | subagentのシステムプロンプト | | tools / disallowedTools | 使えるツールの許可・除外 | | model | sonnet・opus・haiku・inherit または完全なモデルID | | skills / mcpServers | 読み込むスキル・MCPサーバー | | memory | user・project・local | | initialPrompt / maxTurns | 最初の指示・ターン上限 | | background / effort / permissionMode | 実行方式・推論量・権限モード | ### Claude Codeのsubagentの既定値：バックグラウンド・入れ子3層・同時20体 [Claude Codeのsubagentドキュメント](https://code.claude.com/docs/en/sub-agents)によると、メインの会話から起動したsubagentは何も設定しなければバックグラウンドで動き、SDKではAgentツールの結果が`status: "async_launched"`となって報告は後のターンに届きます。subagentがさらにsubagentを起動できるのはメインの会話から3層下までで、`CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH`で変えられます（`1`で入れ子を無効化）。同時に動くsubagentが20体に達すると、次の起動は`Concurrent subagent limit reached`で失敗します（`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`で変更）。Task ツールはv2.1.63でAgentへ改名され、設定ファイルの`Task(...)`は別名として引き続き効きます。.claude/agents/ に書くファイル形式の定義は[Claude Codeのサブエージェントとは？作り方・設定項目・役割分担の例](/tech/details/7911/)、OpenAIのCodexでの同等機能は[Codexカスタムエージェントの作り方](/tech/details/11463/)にまとめています。 ## Generator-Verifier：合格基準を列挙したループの書き方 Generator-Verifierは、生成役の出力を検証役が基準に照らして判定し、不合格なら理由を添えて差し戻す型です。原文は5つのうち最も単純で、最も多く使われている型の1つと書き、失敗の典型として「A verifier told only to check whether output is good, with no further criteria, will rubber-stamp the generator’s output.」と警告しています。基準のない検証役は何でも通し、品質管理をしているように見えるだけになります。 原文はもう2つ注意を挙げています。生成と検証が同じくらい難しい仕事（新しい発想の良し悪しの評価など）では検証役が問題を見抜けないこと、差し戻しを直せないまま往復し続けることです。後者には、反復回数の上限と、上限に達したときの行き先（人へ回す、注意書き付きで最良の案を返す）を決めておきます。次のコードは、モデル呼び出しを`generate`関数に任せ、ループの骨格だけを書いたものです。 ``` from dataclasses import dataclass # 合格基準は「良いか」ではなく、照合できる項目で列挙する RUBRIC = [ ("出典URLを1件以上含む", lambda t: "https://" in t), ("必須項目A・B・Cに触れている", lambda t: all(k in t for k in ("A", "B", "C"))), ("400字以内", lambda t: len(t) <= 400), ] @dataclass class Verdict: passed: bool failures: list def verify(text): failures = [name for name, check in RUBRIC if not check(text)] return Verdict(passed=not failures, failures=failures) def generator_verifier(task, generate, max_rounds=3): if not isinstance(max_rounds, int) or isinstance(max_rounds, bool) or max_rounds < 1: raise ValueError("max_rounds must be a positive integer") feedback, best = [], None for round_no in range(1, max_rounds + 1): draft = generate(task, feedback) verdict = verify(draft) if verdict.passed: return {"status": "passed", "round": round_no, "output": draft} if best is None or len(verdict.failures) < len(best[1].failures): best = (draft, verdict) feedback = verdict.failures # 落ちた項目だけを差し戻す # 上限に達したら止め、未達項目を添えて人へ回す return {"status": "needs_review", "output": best[0], "unmet": best[1].failures} ``` 3回目で基準を満たす生成関数を渡すと`{'status': 'passed', 'round': 3, ...}`が、満たせない関数を`max_rounds=2`で渡すと未達の2項目を添えた`needs_review`が返ります。検証役をLLMにする場合も、判定させる項目はRUBRICのように列挙し、自由記述の「良し悪し」を聞かないことが要点です。 ## Agent Teams：worker持続性と、Claude Code Agent Teamsとの違い 原文のAgent Teamsでは、coordinatorが複数のworkerを独立したプロセスとして起動し、workerは共有キューからタスクを取って複数ステップを自律的に進めます。Orchestrator-Subagentとの違いを原文は「The difference from orchestrator-subagent is worker persistence.」と一言で示しています。subagentは1つのサブタスクを終えると消えますが、teammateは複数の割り当てをまたいで生き残り、担当領域の文脈を溜めていきます。原文の例は大規模コードベースのフレームワーク移行で、サービスごとにteammateを割り当て、最後にcoordinatorが結合テストを回します。 弱点は、teammate同士が途中の発見を共有しにくいことです。原文は、あるteammateの作業が別のteammateに影響しても互いに気づかず出力が衝突しうること、2分で終わる者と20分かかる者が混在して完了の判定が難しいことを挙げています。同じファイルやデータベースを触るなら、分割の時点で担当範囲を分けておく必要があります。 名前が同じでも、Claude Codeの[Agent Teams](https://code.claude.com/docs/en/agent-teams)は原文の型そのものではありません。2026年11月時点でも実験機能で、`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`で有効にします。teammateは共有タスクリストからタスクを取るうえに、メールボックス（`~/.claude/teams/{team-name}/inboxes/{agent-name}.json`）経由で互いに直接メッセージを送れます。原文の弱点だった「中間の発見を共有しにくい」を、直接のやり取りで補った形です。その分、ドキュメントの比較表はトークン消費をsubagentより「Higher」とし、消費量は動いているteammateの数に応じて増えると書いています。teammateが自分のteammateを作る入れ子のチームは使えません。使い方と料金の詳細は[Claude Code Agent Teamsとは？使い方・設定・料金とサブエージェントとの違い](/tech/details/10960/)で解説しています。 ## Message Bus：イベント駆動の連携と誤配送のリスク Message Busでは、エージェントは関心のあるトピックを購読し、別のエージェントが発行したイベントをrouterが購読者へ届けます。発行側は受け手を知らなくてよく、新しい種類のエージェントを既存の配線を変えずに足せます。原文の例はセキュリティ運用の自動化で、triage役がアラートを重要度と種類で分け、ネットワーク系はネットワーク調査役へ、認証情報系はID分析役へ回し、調査役が追加情報の要求を発行し、最後に対応調整役が処置を決めます。脅威の種類が増えるたびに担当エージェントを足していけるのが、この型を選ぶ理由です。 原文が強く警告しているのは誤配送です。「If the router misclassifies or drops an event, the system fails silently, handling nothing but never crashing.」とあり、何も処理しないのにエラーも出ません。5体をまたぐ連鎖を後から追うには、イベントごとの相関IDと判断理由のログを最初から用意しておく必要があります。routerをLLMにすると曖昧な分類に対応できる反面、LLM特有の失敗が加わる、とも原文は書いています。種類フィールドや重要度ラベルが揃っている入力なら、ルールで振り分けるほうが追跡しやすくなります。 ## Shared State：終了条件の3つの選択肢と1,000エージェントの実例 Shared Stateには中央の調整役がいません。各エージェントが共有のデータベース・ファイルシステム・文書を読み書きし、初期化の段階で問いやデータを入れたところから作業が始まります。原文の例は研究の統合で、学術文献・業界レポート・特許・ニュースを別々のエージェントが調べ、学術担当が見つけた重要な研究者を業界担当がすぐに参照できます。中央の調整役を単一障害点にしないことも利点です。ただし、共有ストア自体の可用性は別途設計する必要があります。 同じ対象を2体が追う重複や書き込みの競合は、ロック・バージョニング・パーティショニングという既知の手法で解けます。厄介なのは、AがBへの発見を書き、Bがそれに応じて書き返すという応酬が止まらない反応的なループです。原文は「Reactive loops are a behavioral problem and need first-class termination conditions」として、終了条件を次の3つから設計の最初に決めるよう求めています。 - 時間の予算（time budget） - 収束のしきい値（N回の巡回で新しい発見がなければ終了） - ストアに十分な答えが揃ったかを判断する専任のエージェント ### Claude Fable 5.2の1,000エージェント：階層とShared Stateの組み合わせ Anthropicが2026年11月9日に公開した「[Safely scaling multi-agent teams with Claude Fable 5.2](https://claude.dev/blog/safely-scaling-multi-agent-teams-with-fable-5-2/)」は、5パターンを組み合わせた大規模な実例です。Claude Fable 5.2の初期版で動く1,000エージェント（lead 1体と999体のhelper）が、フェルマーの最終定理の形式的証明を28.7時間で再現しました。同社が9月に行った形式化（研究者1人と数十のエージェントで11日・出力約60億トークン）と比べ、出力トークンは3分の1、証明の長さは7分の1だったと報告されています。 構造はOrchestrator-Subagent型の階層ですが、メッセージ用のツールは与えられておらず、連携は共有のPostgresとGitだけでした。leadは最初の10分でAnnounce（全体への指示）・Assign（誰が何を担当するか）・Notes（作業の宣言と進捗）・Subtasks（誰でも足せて最初に取った者が担当する作業リスト）・Landed（完了の記録）の5テーブルを作り、helperはこのストアを読み書きして動きました。タスクの木は最大10階層・2,418件まで育っています。安全面では、各エージェントが自分のGitブランチにだけpushでき、SQLは1文5秒まで、256MiBを超える書き込みは拒否、ネットワークは遮断という制約を置いていました。1台のマシンを共有する構成は約100エージェントで限界に達し、1体ごとに軽量VMを割り当てています。原文の「building blocks」という言い方が、規模を上げたときにどう現れるかを示す例です。 ## 5パターンの選び方：迷ったときの決め手 原文は隣り合う型の比較を4組示しています。決め手を1つの問いにすると次のとおりです。 | 迷う組み合わせ | 決め手の問い | 答えと選ぶ型 | | ----------------------------------- | ----------------- | ----------------- | | Orchestrator-Subagent / Agent Teams | workerに文脈を溜めさせたいか | 不要＝前者／必要＝後者 | | Orchestrator-Subagent / Message Bus | 手順を事前に決められるか | 決まる＝前者／イベント次第＝後者 | | Agent Teams / Shared State | 途中の発見を互いに使うか | 使わない＝前者／使う＝後者 | | Message Bus / Shared State | 流れるのはイベントか知識か | イベント＝前者／蓄積する知識＝後者 | 移る順番は、実際に詰まってから決めます。シングルで基準値を測り、品質が問題になったら検証役を足し（Generator-Verifier）、文脈が溢れたら分解し（Orchestrator-Subagent）、同じ種類の仕事を繰り返すworkerに慣れが要るならAgent Teamsへ、処理の流れがイベントで決まるならMessage Busへ、発見の共有と耐障害性が要るならShared Stateへ、という順です。Microsoft Agent Frameworkなど他のフレームワークが用意するオーケストレーションの型とコードは[マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード](/tech/details/13600/)で扱っています。 他のSDKでも、制御を誰が持つかで型が分かれます。[OpenAI Agents SDKのドキュメント](https://openai.github.io/openai-agents-python/multi%5Fagent/)は、マネージャーが会話の制御を持ったまま専門エージェントを`Agent.as_tool()`で呼ぶ方式と、triage役が会話そのものを専門エージェントへ引き渡すhandoffを区別しています。前者がOrchestrator-Subagentに当たり、後者は引き渡した時点で中央の統合役がいなくなります。LangGraphの[langgraph-supervisor](https://github.com/langchain-ai/langgraph-supervisor-py)はリポジトリがアーカイブされ、READMEは多くの用途でライブラリよりツール呼び出しでsupervisorを直接組む方法を勧めています。 ## subagentを増やさない判断：2026年10月の公式指針 Orchestrator-Subagentから始めるべきだという原文の推奨と並んで、Anthropicは2026年10月22日に「[Building agents: when to fold subagents into your main agent loop](https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop)」を公開し、増えすぎたsubagentを本体のループへ戻す方法を示しました。協調パターンの原文も、Orchestrator-Subagentの弱点の節からこの記事へリンクしています。要点は次のとおりです。 - 企業ではチームや問題の種類ごとにsubagentを持たせ、構成が組織図の写しになりやすい（記事はコンウェイの法則と表現）。 - ある顧客は、マルチエージェント構成よりシングルのループのほうが実行時間が約2倍速かった。 - システムプロンプトのツール定義が30〜50個を超えるとツール選択が劣化しやすいので、スキルとtool searchで必要なときだけ読み込ませる。Claude Codeでは上位モデル向けのシステムプロンプトを80%超削った。 同記事がsubagentを残す理由として挙げるのは、文脈の膨張で性能低下が測定できる、使い捨ての新しい文脈で並列に処理したい、1体ではツール選択や指示の衝突に困る、の3つです。どれにも当たらないsubagentは、スキルやツールとして本体に戻す候補になります。 コストの数字は出典ごとに比較対象が違います。2025年6月13日の「[How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)」はチャット比で約15倍（エージェント単体は約4倍）、2026年1月23日の「[Building multi-agent systems](https://claude.com/resources/articles/building-multi-agent-systems-when-and-how-to-use-them)」は同じ仕事のシングルエージェント比で3〜10倍です。前者はOpus 4のleadとSonnet 4のsubagentの構成が単体のOpus 4を社内評価で90.2%上回り、BrowseComp評価における性能のばらつきの80%を、トークン使用量だけで説明できたとも書いています。品質改善や時間短縮による価値が追加費用に見合わない仕事では、マルチエージェント構成を採用すべきではありません。社内業務へのエージェント導入をどの構成で始めるかの相談は、[AIエージェント開発の支援](/service/ai/agent/)でも受け付けています。 ## よくある質問 ### Orchestrator-Subagentとは何ですか？ 1体のorchestratorが仕事を分解し、境界のはっきりしたサブタスクを専用のコンテキストを持つsubagentへ任せ、結果を統合するマルチエージェントの構成です。Anthropicは2026年4月10日のブログで、多くの用途ではこの型から始めるよう推奨しています。 ### orchestratorとsubagentの違いは何ですか？ orchestratorは計画・委譲・統合を担い、セッションの間ずっと動きます。subagentは委譲された1つのサブタスクを処理し、要約した結果を返して終わります。fork以外のsubagentには親の会話履歴が渡らないため、必要な前提を委譲の指示文に書きます。forkは親の会話履歴を継承します。 ### Claude CodeのsubagentとAgent Teamsはどの型に当たりますか？ subagentはOrchestrator-Subagentです。Agent Teamsは原文のAgent Teams型に近いものの、teammate同士が直接メッセージを送れる点で原文の型より結合が強く、トークン消費はsubagentより多くなります。2026年11月時点でAgent Teamsは実験機能です。 ### subagentは何体まで同時に動かせますか？ Claude Codeの既定では、同時に動くsubagentが20体に達すると次の起動が失敗します。入れ子はメインの会話から3層下までです。それぞれ`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`と`CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH`で変更できます。 ### マルチエージェントにするとトークンはどれくらい増えますか？ Anthropicの数字では、チャットと比べて約15倍（2025年6月の研究システムの記事）、同じ仕事のシングルエージェントと比べて3〜10倍（2026年1月の記事）です。比較の基準が違うので、2つの倍率を同列に並べないでください。 ## 関連記事 - [マルチエージェントとは？仕組み・構成パターンと採用判断を研究データで解説【2026年10月】](/tech/details/13604/) - [シングルエージェントとは？マルチエージェントとの違いと使い分けの判断基準【2026年10月】](/tech/details/4261/) - [マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード【2026年10月】](/tech/details/13600/) - [Claude Codeのサブエージェントとは？作り方・設定項目・役割分担の例【v2.1.318対応】](/tech/details/7911/) - [Claude Code Agent Teamsとは？使い方・設定・料金とサブエージェントとの違い](/tech/details/10960/) --- 出典: [Orchestrator-Subagentとは？Anthropic公式の協調5パターンとClaude Agent SDKでの実装]()（株式会社一創）