powered by TechFeed
表示モード
Deep Dive

Anthropicのガイドを解説:「AIエージェントは分割しすぎるな」— サブエージェント乱立が招く5つの落とし穴と、単一ループへの統合指針

10月24日、madrobot.blogが「Subagents vs skills: when to use subagents, and when one Claude agent does the job better」と題した記事を公開した。Anthropicが2026年10月22日にApplied AIチームの知見としてまとめたガイドを基に、Claudeエージェント設計においてサブエージェントとスキルをどう使い分けるべきかを詳しく解説している。結論から言えば、ほとんどのケースでサブエージェントは不要であり、単一エージェントループにスキルとして統合した方が品質・コスト・速度のすべてで優れるというものだ。サブエージェントとスキル、何が違うかまず用語を整理する。

10月24日、madrobot.blogが「Subagents vs skills: when to use subagents, and when one Claude agent does the job better」と題した記事を公開した。Anthropicが2026年10月22日にApplied AIチームの知見としてまとめたガイドを基に、Claudeエージェント設計においてサブエージェントとスキルをどう使い分けるべきかを詳しく解説している。結論から言えば、ほとんどのケースでサブエージェントは不要であり、単一エージェントループにスキルとして統合した方が品質・コスト・速度のすべてで優れるというものだ。

サブエージェントとスキル、何が違うか

まず用語を整理する。

  • サブエージェント:独自のコンテキストウィンドウ・ツール・指示を持つ別エージェント。コーディネーターがタスクを渡し、結果のサマリーを受け取る仕組み。
  • スキル:タスクが必要とするときだけメインエージェントのコンテキストに読み込まれる指示のパッケージ。すべての情報が同一のコンテキストウィンドウに収まる。

なお、ここでいう「スキル」はAnthropicが定義する固有の概念であり、機械学習一般で使われる「スキル(モデルが汎化して獲得した能力)」とは別物として捉えていただきたい。

両者の最大の差はコンテキストの連続性にある。サブエージェントはサマリーしか返さないため、前の工程で得た情報が失われる。単一エージェントは全ステップを見ているため、それらを結びつけてより豊かな回答を生成できる、とAnthropicは説明している。

なお、スキルはオープンフォーマットとして整備が進んでおり、Anthropicは同日(10月22日)にAgent SkillsをLinux Foundationへ移管している。

「サブエージェントが多すぎる」組織によくある5つの問題

Anthropicが特に警鐘を鳴らすのが、大企業でよく見られるパターンだ。各チームが自分のプロダクト向けエージェントを作り、プラットフォームチームがその上にオーケストレーターを乗せる。結果、エージェントの構成が組織図のコピーになる。

そこから派生する問題を5つ挙げている:

  • コンテキスト管理の複雑化:エージェント間でどの情報を渡すかを誰かが決める必要があり、やり取りのたびに詳細が失われる
  • サブエージェントの乱立:各チームが独自に作り続け、最終的には重複する何百ものサブエージェントが標準もオーナーもなく存在する
  • 「フランケンプロンプト」:全チームがシステムプロンプトに一文ずつ追加し、矛盾するルールと一貫性のない声になる(Anthropicはこれを"Frankenprompt"と呼ぶ)
  • 局所的な評価:各チームが自分のサブタスクしかテストせず、全体的な品質管理が機能しない
  • レイテンシの増大:層が増えるたびにユーザーの待ち時間が伸びる

ある顧客企業のカスタマー向けエージェントは12の専門サブエージェントを持っていたが、一貫したブランドボイスの維持が困難で応答も遅かった。Anthropicは、その設計の大半を明確なシステムプロンプト1つ、薄いデータツール4〜5本、出力ガードレールで置き換えられると指摘している。

サブエージェントを使うべき3条件

とはいえ、Anthropic自身もサブエージェントを使っており(自社のマルチエージェント研究システムを含む)、有効なケースは存在する。条件は明確に3つに絞られている:

  1. コンテキスト肥大:単一エージェントループがコンテキスト過多で性能低下を示している
  2. 並列処理:複数タスクを独立したコンテキストウィンドウで同時に処理する必要がある
  3. ツール・指示の競合:一つのエージェントが適切なツール選択に失敗する、またはシステムプロンプトに矛盾する指示がある

分割する際のポイントも具体的だ。「問題の種類ではなく、コンテキストで分割する」こと。問題タイプで分けると、エージェント間で情報が往復して劣化する「電話ゲーム」になる。独立した調査パスや、インターフェースが明確な別コンポーネント、ブラックボックス検証が良い候補だという。

ツール数の上限と「ツール検索」

単一エージェント設計を実現する技術的な背景として、30〜50を超えるツール定義を読み込むとツール選択の精度が下がるというAnthropicの知見がある。

これを解決するのがTool Searchだ(元記事が参照している公式ドキュメントのURLであり、仕様変更で移動している場合は最新のAnthropicドキュメントを確認されたい)。ツールにdefer_loading: trueを付けておくことで、Claudeが必要なときだけ検索・ロードする仕組みで、ツール定義が占めるコンテキストを85%以上削減でき、1リクエストで最大10,000の遅延ツールに対応する。

また、記事によれば最新モデルは単一ループで扱える範囲が大幅に拡大しており、AnthropicはClaude Codeのシステムプロンプトを高度なモデル向けに80%以上削減したという。(※使用されているモデルの型番については元記事を直接ご確認いただきたい)

サブエージェントをスキルに統合する手順

Anthropicが推奨する移行ステップは以下の通りだ:

  1. まずエンドツーエンドの評価を作る:「ゴールデン」サンプル10タスクで十分。最終回答をルーブリックで採点する
  2. 常に連続して呼ばれるサブエージェントを統合する:トラフィックの多くがA→Bの順で呼ばれるなら統合候補
  3. 残りをツールとして呼び出す:メインエージェントがサブエージェントをツールのように呼ぶ構成。リライト不要でベースラインスコアが得られる
  4. 1つずつスキルとツールに変換する:プロンプトをスキルに、API呼び出しをMCPツールに変換し、スコアを比較
  5. タスク単位でのスコア変化を見る:合計スコアではなく「どのタスクが改善・悪化したか」を追う

最後のステップが特に重要だ。Anthropicの自社テストでは、サポートエージェントのあるサブエージェントを統合したところレイテンシは下がったが、それまで正常に動いていたプロセスが壊れた(メインエージェントが配送日を配送専門エージェントに聞かずに自己判断で回答した)。しかもこの問題は2回のうち1回しか再現しなかった。各タスクを複数回実行し、本番で使われるすべてのエージェント連鎖を評価対象に含めることが必要だ。

無償で使える「single-agent-loop-kit」

Anthropicはこのガイドと同時に、single-agent-loop-kitをGitHub上でApache 2.0ライセンスで公開した。Claude Codeスキルとして動作し、既存のマルチエージェント構成を監査して各サブエージェントに「統合・マージ・ツール化・維持」のいずれかの判定を出し、1変更ずつスコアを比較しながら移行を進める。

ルーターと6つのサブエージェントを持つデモ用サポートデスクが付属しており、APIキーなしでスタンドインモデルを使って約10分で動作確認できる。ただしAnthropicはメンテナンスを行わないリファレンス実装としており、修正を待つのではなくフォークして使うことを推奨している。

加えて、Claude APIスキルから使える4つのコマンドも提供されている:

  • /claude-api build-eval:エンドツーエンド評価の自動構築
  • /claude-api prompt-audit:旧モデル向けの記述を検出して改善案を提示
  • /claude-api hillclimb:評価スコアを指標にスキル・ツール・システムプロンプトを段階的に改善
  • /claude-api cost-optimize:プロンプトキャッシュやトークン削減など、コスト削減策を1つずつ提案

詳細はSubagents vs skills: when to use subagents, and when one Claude agent does the job betterを参照していただきたい。