Anthropic（Claude）の公式リソースで、企業向けエージェント設計のガイド「Building agents: when to fold subagents into your main agent loop」が公開された。組織図どおりに専門エージェントを増やしがちだが、単一エージェント＋Skills＋ツール検索の方が品質・コスト・レイテンシで勝つ例が多い、と整理している。サブエージェントは文脈肥大・並列処理・ツール選択の混乱などが測定できるときだけ、という判断基準が実務にそのまま使える。
要点（3行）
- マルチエージェントは「組織図のコピー」（コンウェイの法則）になりやすく、オーケストレーター経由の受け渡しで文脈が欠落し、品質・コスト・レイテンシが悪化しがち
- 多くの業務は単一エージェント＋Agent Skills＋ツール検索（progressive disclosure）で足りる。サブエージェントは文脈肥大・並列・ツール選択の混乱などが測定できるときに限定する
- 公式は折りたたみの移行キットと評価手順も示している。クライアント／パートナー向けの設計レビューに使える内容
何が問題か：組織図コピーのマルチエージェント
Anthropicによると、企業のエージェント設計では「リサーチ担当」「執筆担当」「レビュー担当」のように人間のチーム構成をそのままサブエージェントに写すパターンがよく見られる。一見すると自然だが、次のような副作用が起きやすい。
- 文脈の欠落：オーケストレーター経由の要約受け渡しで、元の依頼や制約が落ちる
- コスト増：エージェント間の往復ごとにトークンが積み上がる
- レイテンシ増：直列の受け渡しが待ち時間になる
- 品質のばらつき：各サブエージェントが部分最適になり、全体の一貫性が崩れる
公式は「サブエージェントを足すほど賢くなる」わけではない、と明示している。複雑さは必要が生じたときに足す、というスタンスだ。
推奨パターン：単一エージェント＋Skills＋ツール検索
多くのユースケースでは、1つのエージェントに十分なツールと手順を与え、Agent Skillsで専門知識をモジュール化し、必要に応じてツールを検索・選択させる方がよい、としている。Skillsは手順・制約・ドメイン知識を切り出して再利用できるため、「担当エージェントを増やす」より「能力を足す」方が運用しやすい。
ポイントは次のとおり。
- 同じ会話スレッド内で文脈を保持できる（要約の往復が減る）
- ツール呼び出しと手順（Skills）を一本のループで制御できる
- 評価（eval）も単一経路に寄せやすく、改善サイクルが短い
サブエージェントを使うべきとき
公式が「サブエージェントを使う」典型として挙げるのは、おおむね次のような場合だ（検証・並列・権限のモジュール分離にも有効、と前段で触れている）。
| 条件 | 理由 |
|---|---|
| コンテキスト肥大 | 単一ループで文脈が膨らみ、測定可能な性能劣化が出るとき |
| 並列＋使い捨て文脈 | 独立タスクを新鮮なコンテキストで同時実行し、終わったら捨てられるとき |
| ツール選択の混乱／指示の衝突 | 単一エージェントでは適切なツール選択が難しい、またはシステムプロンプト内の指示が衝突するとき |
「担当が違うから分ける」「組織図どおりにエージェントを置く」だけでは不十分で、上記のような測定可能な理由があるかを先に確認する、というのが実務向けの判断軸になる。
移行キットと評価の考え方
すでにマルチエージェント構成がある場合向けに、公式は折りたたみ（fold）の進め方と移行キットを示している。大枠は次のような流れだ。
- 共通のエンドツーエンド評価（eval）を用意する（まずはゴールデン例10件程度でも可）
- サブエージェントのプロンプトをSkillsへ、API呼び出しをツール（MCP等）へ移し替える
- 1つ折りたたんだうえで、折りたたみ前／後のevalを比較する（最終スコアだけでなく、どのタスクが逆転したかも見る）
- 折りたたみ版の方が悪い場合のみサブエージェントとして残す。良い／同等ならメインループ側に統合する
- 残す場合でも、可能ならメインエージェントからツールとして呼ぶ（会話の主導権はメインに残す）
移行キットは Claude API 向けスキルを連結したガイド付きワークフローで、モックでのデモも用意されている。公式が挙げている関連スキル例は /claude-api build-eval、prompt-audit、hillclimb、cost-optimize など。「全部まとめる／全部残す」ではなく、測ってから1つずつ減らすのがポイントだ。
クライアント・パートナー向けに刺さる読みどころ
バズ瞬間の新機能紹介というより、設計方針の整理に近い。特に次のような場面でそのまま議論の土台にできる。
- 「部門ごとにエージェントを増やしたい」提案の見直し
- 既存マルチエージェントのコスト／遅延の原因切り分け
- Agent Skills やツール検索を前提にした単一エージェント設計への移行計画
- 権限分離が本当に必要かのセキュリティ／ガバナンス議論
Anthropic自身が「サブエージェントは手段であり、最初の設計原則ではない」と公式に書いている点は、導入支援側としても説明しやすい。
注意点・補足
- 本記事はAnthropic公式リソースの整理であり、特定プロダクトの価格やSLAを保証するものではない
- Agent Skills／サブエージェントの実装詳細はClaude CodeやAPIの最新ドキュメントも併読すること
- 自社のデータ権限・監査要件によっては、単一エージェントにまとめられないケースもある（その場合は権限分離条件に該当）
関連リンク（AB通信）
出典
- Anthropic / Claude — Building agents: when to fold subagents into your main agent loop（一次出典）
