Claudeのサブエージェントを統合するか — メインループに畳む判断基準

Claude Platformで複数のサブエージェントを持つエージェントを作ったなら、その一部はメインのエージェントループに畳めるかもしれません。AnthropicのApplied AIチームは、複数の企業導入を比べた結果、スキルを持たせた単一のエージェントが「1つのプロンプトに全部詰める設計」と「サブエージェント設計」の両方を品質で上回ることが多く、コストと遅延も下がりやすいと報告しています。

ここでの「畳む」とは、ルーターやプランナー、領域別のサブエージェントを廃して、その役割をスキルとツールに移すことです。残してよいサブエージェントは3条件のどれかに当たるものだけで、それ以外は評価セットを作ったうえで1つずつ畳めます。ただし畳むと、通っていた処理が壊れることがあります。

サブエージェントを残してよいのは3つの場面だけか

結論から言うと、残す理由は次の3条件のどれかに当たるときです。

サブエージェント自体が悪いわけではありません。検証、並列作業、権限の分離には向いており、Anthropic自身のマルチエージェントのリサーチシステムでも使われています。問題にされているのは、チームや問題の種類ごとにサブエージェントを1つずつ置く設計です。エージェントの構成が組織図のコピーになる、いわゆるコンウェイの法則が出ている状態です。

Claude Codeのサブエージェントの解説でも、同じ方向の線引きがあります。メインの会話を使うのは、往復や反復が多いとき、計画・実装・テストのように複数の段階が文脈を共有するとき、小さな変更を素早く入れたいとき、遅延が効くときです。サブエージェントに向くのは、冗長な出力をメインに残したくない作業、ツール制限や権限を強制したい作業、自己完結して要約を返せる作業です。Claude Codeの側でも、使い回す手順はスキルで足りるという案内が付いています。

いまの構成は畳めるか — 状況別の判断表

3条件とClaude Codeの線引きを重ねると、判断は次のようになります。

3条件に権限の分離が入っていない点は、読み落とされやすいところです。設計ガイドは複数の企業導入を比べた結果で、Claude Codeのdocsは製品の機能の説明なので、見ている範囲が違います。権限が理由で置いたサブエージェントは、3条件に当たらなくても畳む候補から外してかまいません。

大きな組織でサブエージェントが増えると何が起きるか

各機能を別のチームが持つ会社では、まず各チームが自分のエージェントを作り、あとから中央のプラットフォームチームがオーケストレーターを載せる流れになりがちです。一見いちばん簡単ですが、次の問題が同時に出ます。

遅延については数字が出ています。マルチエージェントの構成を単一のエージェントループに替えた顧客では、実行時間がおよそ2倍速くなりました。また、専門のサブエージェントを十数個抱えた顧客向けエージェントでは、一貫したブランドの応対を保つのが難しく、遅延が体験を損なっていた例も挙がっています。

意図分類器、固定の多段推論パイプライン、ユーザー区分ごとの分岐、レコメンドの別ブランチ、その上にマルチエージェントのオーケストレーター、という設計案がよく出ます。この種の構造の多くは、モデルがもう肩代わりしなくてよい仕事をしています。明確なシステムプロンプト1つ、薄いデータツール4〜5個、出力の確かな制約があれば、用件の大半は足ります。

なぜ単一ループのほうが成績が良くなりやすいのか

Anthropicが挙げる理由は3つです。

1. 共有コンテキストのほうが答えが良くなる。長く動くエージェントでは、複数のタスクの文脈が同じウィンドウにあるほうが、各ステップの結果を見たうえで結び付けられる。サブエージェントが返す要約の寄せ集めより、出力が豊かになり、コンテキストウィンドウの数も情報の欠けた受け渡しも減る
2. 段階的な開示でコンテキストの肥大を防げる。スキルとツールの説明だけを見せ、必要になったときに全文を読み込めば、長大なシステムプロンプトを避けられる。これはサブエージェントに分けていた主な理由を消す。Claude Codeのシステムプロンプトは、より高度なモデル向けに80% 以上削られ、その中にはスキルやツールの段階的な開示に関する削減も含まれる
3. モデルが賢くなった。Opus 4.5以降は、単一のループで多くを扱えるようになった。ループが単純なほど次のモデルへ移りやすく、硬直したマルチエージェント構造が新しいモデルの足を引っ張った例もあるという

段階的な開示は、ツール側にも同じ考え方があります。Claude APIのツール検索は、全ツールの定義を最初から読み込む代わりに、カタログを検索して必要な定義だけを読み込みます。ドキュメントによると、GitHub・Slack・Sentry・Grafana・Splunkのような複数サーバー構成では、仕事を始める前に定義だけで約55kトークンを消費することがあります。ドキュメントは、ツール検索で通常85% 以上減らせると書いています。使えるツールが30〜50個を超えると選択精度が落ちる点も、ここで触れられています。

スキル側の段階的開示の設計は、Agent Skillsの命名規則と段階的開示の設計原則で詳しく扱っています。

畳んだ後のループはどんな形か

目指す単一ループの形は、次のとおりです。

役割の移し先は決まっています。

• ルールのカタログから計画を書き換えるコード段階は不要になる。各ステップをモデルが決めるため
• 順序やドメインの手順は、スキルに移す
• 検証や承認ゲートのような厳密な制約と、会話の途中で必要になるもの(記憶の検索など)は、ツールに移す
• 安くてほぼ常に要る処理(エンティティの解決など)と、機械的な部分(ペイロードの組み立て、ストリームの解析)は、コードに残してよい

この形には、エージェントが学んだことを1つのコンテキストに保てるという利点もあります。ユーザーの高い水準の目標を理解して代わりに動くエージェントへ向かう際に、土台になります。

畳む順序はどう決めるか

一度に全部を畳む必要はありません。Anthropicが勧めるのは、評価セットを先に作り、サブエージェントを1つずつ畳み、効果を測る進め方です。

最初にタスク完了の評価セットを作る

評価は、中央のチームが持つ1つのエンドツーエンドのセットと、スキルを持つチームが付ける小さなセットを組み合わせるのが有効です。10件の模範例でも、始めるには足ります。

最終メッセージをルーブリックで採点するのが出発点です。オーケストレーターが残っている間は、ルーティング精度(正しいサブエージェントを選んだか)も追います。畳んだ後は、正しいスキルを読み込んだか、正しいツールを呼んだかに見方を替えます。内部システムの再現が難しい環境では、重要なイベントのタイムスタンプを記録しておき、あとで再生して狙った評価に使う手があります。

結合の強いものから合流させる

小さなエンドツーエンドの評価を作ってから、最初の合流に入ります。共有コンテキストの強いもの、特に最もよく使われるサブエージェントから始めます。互いの出力に連鎖する専門役、同じデータに触れる専門役、よく一緒に呼ばれる専門役は、まとめる候補です。本番のトラフィックの大きな割合が「専門役Aの次にB」なら、密に結合した組で、1つのドメインエージェントに合流できます。

残すサブエージェントはツールとして呼ぶ

3条件のどれかに当たって残すなら、メインのエージェントがサブエージェントをツールとして呼ぶ形が効果的です。メインがユーザーとの会話を持ち続けられます。会話そのものを引き渡す完全なハンドオフは、サブエージェントがユーザーと直接話す必要があるときだけにします。それ以外は、メインループのスキルとツールで足ります。

この形なら、サブエージェント向けに共通の応答スキーマを定め、結論を実データでメインが確かめ、最終の統合段階への入力を削れます。サブエージェントを書き換えずに済むので、最初の一歩として手頃で、畳む前のタスク完了評価のベースラインも取れます。一方で、次の弱点は残ります。

• 専門役ごとにプロンプト、コンテキスト、担当チーム、評価がある
• 呼び出しのたびに、情報の欠けた要約が返る
• 呼び出しごとに入れ子のモデルループが走り、遅延が増える

スキルとツールへ1つずつ畳む

最後に、サブエージェントのプロンプトをスキルに、API呼び出しをMCPツールに変えます。1つ畳むごとに、畳む前後で評価を比べ、どちらを残すか決めます。

畳んだら壊れるのは何か

比べるときは、最終スコアだけでなく、どのタスクの成否が入れ替わったかを見てください。サポートエージェントの例で、あるサブエージェントを別のものに畳むと遅延は下がりましたが、通っていた処理が壊れました。メインが注文照会ツールを持ったことで、配送担当に配達日を尋ねずに、自分で答えてしまうようになったのです。

対策として次の2点があります。

• 本番で連鎖して動くエージェントの組ごとに、評価のタスクを用意する。破ってはいけないルールごとにも用意する
• 各タスクを複数回走らせる。この壊れ方は、2回に1回しか現れなかった

権限の分離が理由で残すサブエージェントの設計は、Claude Codeのサブエージェント権限ルール設計で扱っています。

担当チームの役割はどう変わるか

畳んだ後のエージェントでは、各チームの持ち場がエージェントからスキルとツールに移ります。システムプロンプトとエンドツーエンドの品質は、小さな中央チームが持ち、新しいスキル、ツール、評価を出荷前に確かめます。中央を小さく保つと、反復が速く、組織全体の調整コストも下がります。

ツールは「行動と生データと固定形式」の置き場

ツールが向くのは、行動を起こす、システムから最新のデータを読む、決まった形で結果を返す、のいずれかです。ユーザーの意図ごとにまとめ、API 1つにツール1つの対応にはしません。システムプロンプトに載る定義が30〜50個を超えると、ツールの選択が悪化しやすいためです。

厳密な前提条件はツールの側に移します。YがXの出力を必要とするなら、YのツールがXの出力の有無を確かめ、モデルが従える指示を返します。ユーザーごとの権限も同じです。各ツールが呼び出したユーザーに許される範囲を確認し、モデルが読める平易な拒否を返せば、権限の水準ごとにエージェントを分けなくても、1つのループが異なるアクセス権のユーザーを扱えます。

返す内容の形は、たとえば次のようなものです(説明用の例です)。

{
  "status": "blocked",
  "message": "配送状況の照会には、先に注文の本人確認が必要です。verify_order を呼んでください。"
}

スキルは「チームの仕事の進め方」の置き場

スキルが向くのは、専門のサブエージェントのプロンプトが持っていた手順、ルール、判断の置き場です。スキルが増え過ぎないよう、チームごとの責任者がスキルを持ち、出来がよく、重複せず、評価を添えて出荷されるようにします。

整備のためのコマンドも挙がっています。/skill-creator は整った新しいスキルを作り、既存のものを刈り込み、重複を除き、構造を直します。/skill-doctor は各スキルの読み込みコストと実際の利用頻度を示し、使われないものを削る助けになります。

知識ベースは「ときどき要る参照資料」の置き場

方針、指標の定義、製品仕様のような参照資料は、モデルが呼ぶ検索ツールの裏に置くか、スキルの中の参照ファイルとして出荷します。コードで取り出してプロンプトに貼り付ける形は避けます。

畳む判断を助けるコマンド

AnthropicはClaude API用のスキル群を出しており、移行キットがそれらを1つの誘導付きワークフローにまとめています。実システムの前に試せるデモ付きです。

prompt-audit は、以前のモデルのために足したルールが今はエージェントを遅く、硬くしていないかを調べるのに使えます。hillclimb は、サブエージェントをスキルとツールに畳んだあと、スキルとツールの説明文を反復して改善し、畳んだ版が元と並ぶか上回るかを確かめる使い方が挙がっています。

畳むかどうかの決め方

大事なのはアーキテクチャよりその裏の原則で、測り、1つずつ変え、持ちこたえたものを残すことです。

• 小さなエンドツーエンドの評価を作る
• サブエージェントを1つ畳む
• 畳んだ版のスコアが悪いときだけ、サブエージェントのまま残す
• 繰り返す

モデルが賢くなり、エージェントが長く動くようになるほど、サブエージェントの多くはスキルとツールで置き換えられます。ただし判断を一括でする必要はなく、動いているサブエージェントを今日すぐ消す理由にもなりません。

Agent SDKでループ自体の挙動を確かめたい場合は、Agent SDKのエージェントループを理解するが前提になります。Claude Codeで並列に走らせる設計はClaude Codeのサブエージェント並列設計にあります。