サブエージェントは減らすべきか｜Claude 公式の単一ループ指針と判断基準

公式が出した「サブエージェントを畳む」指針の範囲

Anthropic は 2026 年 10 月 22 日、Claude の公式サイトに「Building agents: When to fold subagents into your main agent loop」を公開しました。著者は Diane Sarkis 氏です。Claude Platform でエージェントを作るときに、サブエージェントを減らして、段階的に開示されるコンテキストとツールに置き換える考え方をまとめた記事です。

公式の記事は、サブエージェントをやめるべきだとまでは言い切っていません。サブエージェントが有効な場面を 3 つ挙げたうえで、それ以外の構成を 1 つずつ畳む手順を示しています。この記事では、公式の記述に沿って要点を整理します。数字を扱う箇所では、公式がそう書いているのか、自分たちの解釈なのかを分けて書きます。

サブエージェントの作り方は Claude Code の subagent で役割分担する設計と実用パターン に、エージェントの設計パターン全体は AI エージェント設計パターン入門 にまとめています。今回の指針は、それらで分けた構成を「いつ畳むか」の見直しにあたります。

FIXIT

サブエージェントって、増やすほど賢くなるんじゃないの？

Tsukasa

結論から言うと、増やすほど良くなるとは限りません。公式は、残す条件と畳む手順を示しています。

FIXIT

じゃあ、全部なくせばいいってこと？

Tsukasa

いいえ。今の構成が公式の 3 条件のどれかに当たるかどうかで決めます。

公式が言っていること｜スキル付きの単一エージェントが上回る傾向

公式は、複数の企業導入を比べると、スキルを持つ単一のエージェントが、1 つのプロンプトで全部をこなす設計と、サブエージェントを使う設計の両方を、品質で上回ることが多かったと述べています。タスクあたりのコストと遅延も低いことが多かったとのことです。

背景として、ルーター、プランナー、領域別のサブエージェントをメインのエージェントループに統合して良い結果を得た企業導入がある、という傾向を Applied AI チームが最近見つけたと書かれています。例として、ある企業の顧客向けエージェントには約 12 個の専門サブエージェントがあり、一貫したブランド体験を保つのが難しく、遅延も利用者の体験を損ねていたと紹介されています。

よく見る設計案としては、インテント分類器、固定の多段推論パイプライン、ユーザーセグメント、推奨の分岐、その上に載るオーケストレーターが挙げられています。こうした案へのフィードバックは、構造の大半はモデルがもう肩代わりしてもらう必要のない処理をしていた、というものが多いとのことです。明確なシステムプロンプト 1 つ、薄いデータツール 4〜5 個、厳格な出力ガードレールで、その用途の大半をまかなえるという指摘も添えられています。

項目	公式の記述
比較の結果	スキル付きの単一エージェントは、品質で上回ることが多く、コストと遅延も低いことが多い
よく見る設計案	インテント分類器、固定の多段パイプライン、ユーザーセグメント、推奨の分岐、オーケストレーター
足りるとされる例	システムプロンプト 1 つ、薄いデータツール 4〜5 個、出力ガードレール

比較に使った企業名や件数、品質の差の大きさは、記事に書かれていません。「多く」という書き方なので、すべての構成で単一ループが勝つという意味には読めません。

サブエージェントを残す 3 つの条件

公式は、次のいずれかに当てはまる場合にサブエージェントが有効だと書いています。

1. 単一のループが、コンテキストの肥大化によって測定可能な性能低下を起こしている
2. 複数のタスクを、終われば捨てられる新しいコンテキストで並列に処理する必要がある
3. 単一のエージェントがツールの選択に苦労する、またはシステムプロンプトの中に矛盾する指示がある

サブエージェント自体は、独自のコンテキスト、ツール、指示を持ち、コーディネーターが統括する仕組みです。公式は、検証、並列作業、権限の切り分けといった場面に向くとしています。

2025 年に Anthropic が公開した マルチエージェントの調査機能の開発記事 も、同じ方向で読めます。マルチエージェントの構成は通常のチャットの約 15 倍のトークンを使うため、そのコストに見合うだけ価値の高い仕事でないと採算が合わない、と書かれています。向く仕事として挙がるのは、並列化しやすい仕事、1 つの文脈に収まらない量の情報を扱う仕事、多数の複雑なツールを扱う仕事です。全エージェントが同じ文脈を共有する必要がある仕事や、エージェント間の依存が多い仕事には、現時点では向かないとしています。例として、多くのコーディング作業は調査に比べて本当に並列化できる部分が少ない、と書かれています。今回の記事は、その考え方に「分けた後に、いつ畳むか」を足したものと言えます。

自分の構成が 3 つのどれにも当てはまらないなら、畳む候補です。ただし、当てはまるかどうかは感覚で決めず、測って決めます。測る方法は後の節で扱います。

単一ループに畳むと良くなる 3 つの理由と、数字の読み方

公式は、オーケストレーターとサブエージェントの構成よりも効果的なことが多い方法として、スキルで文脈を、tool search でツールを段階的に開示する方法を挙げています。エージェントにはスキルとツールの短い説明だけを見せ、必要になったときに全文を読み込みます。この方法を勧める理由として、公式は 3 つを挙げています。

1. 共有コンテキストで、前の段階の結果を踏まえた、より深い回答が出せる
2. 段階的な開示でコンテキストの肥大化を防げる
3. Opus 4.5 以降のモデルは、多くのチームが予想したよりずっと多くを 1 つのループで管理できるようになった

2 つめの根拠として、Claude Code のシステムプロンプトを、より高性能なモデル向けに 80% 以上削減したと書かれています。削った分には、スキルとツールの段階的開示に関わるものも含まれます。リンク先の Claude の開発者ブログ (英語) によると、対象は Claude Opus 5 や Claude Fable 5 のようなモデルで、社内のコーディング評価では測定できる低下が無かったとのことです。

3 つめについて公式は、最近のモデルは進み具合を自分で言葉にし、作業を確認しながら進めるため、ハーネスの一部の要素が不要になると述べています。単純なループのほうが次のモデルへ移りやすく、移行を手伝った例では、硬い複数エージェントの構造が新しいモデルに仕事を任せる妨げになっていたことが多かったとも書かれています。

もう 1 つの数字が実行速度です。ある顧客が、複数エージェントの構成と単一のエージェントループを比べたところ、単一のループのほうが実行時間がおよそ 2 倍速かったと書かれています。

この 2 つの数字は、どちらも公式の記述です。第三者による検証は、確認できた範囲では見当たりません。「約 2 倍」は 1 社の比較で、自社の構成で同じになる保証はありません。「80% 以上」は Claude Code のシステムプロンプトの話で、読者のエージェントのプロンプトが同じだけ減るという意味ではありません。自分の構成で測った値だけを、判断の根拠にします。

単一ループは、放っておいて成り立つものではありません。公式は、システムプロンプトの管理、スキルとツールの説明の書き方、コンテキスト・メモリ・メモの扱いに、規律が要ると書いています。

大規模組織で起きる 5 つの失敗

公式は、大きな組織でエージェントを作るときの失敗も挙げています。前提は、各チームが自分のエージェントを作り、中央のチームがその上にオーケストレーターを載せる構成です。この構成で起きやすい失敗として、次の 5 つが並んでいます。

• コンテキストの管理。エージェント間でどの文脈を渡すかを決める必要があり、やり取りのたびに細部が抜けやすい
• サブエージェントの乱立。チームごとに重複したサブエージェントが数百できて、基準もオーナーも不明確になる
• Frankenprompt。各チームがシステムプロンプトに 1 文ずつ足した結果、ルールが矛盾し、一貫した口調が失われる
• 偏った eval。各チームが自分の担当範囲だけに合わせて評価を作り、全体を持つ人がいない。経営層は局所的な点数で判断することになる
• 遅延。単一ループとの比較で、実行時間がおよそ 2 倍違った例が挙げられている

この失敗に対して公式が出す答えは、組織の側の設計です。中央の小さな 1 チームが、エンドツーエンドの品質とシステムプロンプトを持ち、新しいスキル、ツール、eval を出す前に審査します。チームを小さく保つと改善が速く回り、大きな組織での調整の手間も減るとしています。各チームは、エージェントを持つ立場から、スキルとツールを持つ立場へ移ります。

サブエージェントが必要な場合の分け方にも指針があります。他の部分にほとんど依存せず、コンパクトな結果を返せる作業の単位で分けます。問題の種類で分けると、受け渡しのたびに情報が失われる「伝言ゲーム」になる、とのことです。

公式が勧める単一ループの形

畳む先として、公式は次のような単一ループの形を示しています。

• 1 つのモデルと 1 つのコンテキストで、終わりの決まっていないツールループを回す。ターン数とコストの予算、書き込みのゲートといった制限は、ハーネス側で設ける
• モデルは毎ターン、ツール呼び出しをまとめて出す。ハーネスはそれを並列に実行し、生の結果を同じモデルへ返す。モデルは、次の呼び出し、利用者への質問、回答のどれに進むかを決める
• モデルが回答するか、予算に達したらループを止める。回答の後に、目標や検証役のチェックを任意で走らせられる
• 計画は、モデルが 1 ターン目にコンテキストへ書き、結果に応じて直す。計画を書くモデルと実行するモデルが同じなので、途中で計画を変えられる
• 順序と業務の手順はスキルへ移す。検証や承認ゲートのような強い制限と、メモリの参照のように会話の途中で要るものはツールへ移す
• 安くてほぼ常に必要なもの (エンティティの解決など) の読み込みと、ペイロードの組み立てやストリームの解析のような機械的な処理は、引き続きコードで扱える

畳む手順｜eval を作って 1 つずつ

公式の手順は、段階に分かれています。

段階	やること
1	タスク完了の eval を作る。10 個のゴールデンサンプルでも始められる
2	利用の多いサブエージェントから始め、連鎖して使われる、同じデータに触れる、よく一緒に呼ばれる組を 1 つに統合する
3	サブエージェントを、メインのエージェントが会話を保ったまま呼ぶツールにする
4	サブエージェントのプロンプトをスキルに、API 呼び出しを MCP ツールに、1 つずつ折り込む

1 つめの eval は、最終回答をルーブリックで採点するところから始めます。オーケストレーターが残っている間は、正しいサブエージェントを選んだかというルーティングの精度も追います。サブエージェントを統合した後は、その代わりに、正しいスキルを読み込んだか、正しいツールを呼んだかを見ます。社内システムを再現しにくく、利用者の操作も模擬しにくい環境では、重要なイベントにタイムスタンプを記録しておき、後から再生して対象を絞った eval として流す方法が、Anthropic の社内でうまくいったと紹介されています。

eval の持ち方は、中央のチームが共通のエンドツーエンドの eval を持ち、各チームが自分のスキルと一緒に小さな eval を出す形がうまくいったとのことです。

2 つめの段階の例として、本番のトラフィックの大きな割合が、ある専門エージェントの後に別の専門エージェントが続く流れなら、その 2 つは強く結びついた組で、1 つの領域エージェントへ統合する候補になると書かれています。

3 つめの段階では、サブエージェントが利用者と直接話す必要があるときに限って、完全なハンドオフを勧めています。それ以外は、メインのエージェントが会話を持ち続けます。3 条件のどれかに当たってサブエージェントを残す場合にも、この形が向くとしています。サブエージェントを書き換えずに始められ、畳むかどうかを決める前の基準値も取れます。ただし、各専門エージェントのプロンプト・文脈・オーナー・eval が分かれたままになる、呼び出しのたびに情報の抜けた要約が返る、呼び出しごとに入れ子のモデルループが遅延を足す、という問題は残ります。

4 つめの段階で公式が挙げる例は、畳むときの注意として読めます。サンプルのサポートエージェントで、サブエージェントを別のサブエージェントに統合したところ、遅延は下がりました。しかし、すでに通っていた処理が壊れました。メインのエージェントが注文検索のツールを直接持った結果、配送の専門エージェントに配送日を尋ねずに答えるようになったためです。この不具合は、2 回のうち 1 回しか出なかったとのことです。

そのため公式は、変更の前に、本番で一緒に動くエージェントの連鎖ごと、守らせるルールごとに eval のタスクを用意し、各タスクを複数回流すよう勧めています。

Skills・MCP ツール・ナレッジの置き分け

複数のチームが 1 つのエージェントに関わるとき、公式は置き場所を 3 つに分けています。

置き場所	向くもの	公式の補足
MCP ツール	行動を取る、ライブデータを読む、固定形式で結果を返すもの	API ごとではなく、利用者の意図ごとにまとめる。tool search の遅延読み込みを使う
Skills	チームの仕事の進め方である手順、ルール、判断基準	作成と監査の支援に /skill-creator、コストと利用頻度の確認に /skill-doctor
ナレッジベース	必要なときだけ参照する資料。ポリシー、指標定義、製品仕様	検索ツールで取るか、スキル内の参照ファイルにする。コードでプロンプトに貼り付けない

ツールを意図ごとにまとめる理由として、公式は、システムプロンプト内のツール定義が 30〜50 個を超えるとツール選択の精度が落ちやすい点を挙げています。この目安は、サブエージェントを残す理由としてではなく、ツールのまとめ方と tool search を使う理由として書かれています。私たちは、まず意図ごとにまとめ直し、次に tool search を使い、それでも選択に迷うなら 3 条件の 3 つめを検討する、という順で読んでいます。

前提条件の扱いにも指針があります。強い前提条件は減らし、必要なものはツールの中へ移します。たとえば Y が X の出力を必要とするなら、Y のツールがそれを確かめ、足りなければモデルが次に動ける指示を返します。利用者ごとの権限も、同じようにツールが確かめます。呼び出した利用者が見てよいもの・してよいことを確かめ、足りなければモデルが読める拒否を返します。こうすれば、権限の段階ごとに別のエージェントを作らずに、1 つのループで権限の違う利用者に対応できます。また、移行中はツール経由でサブエージェントを呼び続けることもできます。

Skills の共有の設計は Agent Skills とは、業務ツールを MCP でつなぐ方法は MCP サーバーの自作ガイド で扱っています。

作業を助けるスキルと移行キット

公式は、ここまでの作業の多くを助ける Claude API のスキルを公開したと書いています。いずれも Claude Code から実行するコマンドです。

• /claude-api build-eval。中央のチームが持つ最初のエンドツーエンドの eval や、各チームがスキルと一緒に出す小さな eval の作成を支援する
• /claude-api prompt-audit。プロンプト、スキル、ツールの説明から古いモデル向けの指示を見つけ、直しを差分で示す
• /claude-api hillclimb。既存の eval に対して改善を繰り返す。統合版と維持版の比較にも、システムプロンプトの改善にも使える
• /claude-api cost-optimize。呼び出しの内訳を調べ、プロンプトキャッシュや不要なトークンの削減、effort、モデルの選択などから節約案を 1 つずつ示す

これらのスキルを 1 つの案内付きワークフローにつないだのが、公式の 移行キット (single-agent-loop-kit) です。Claude Code の skill として、対象のリポジトリの .claude/skills/ に置いて使います。最初にサブエージェントを棚卸しし、それぞれについて fold (スキルとツールに畳む)、merge (統合する)、call as a tool (ツールとして呼ぶ)、keep (残す) の判定を示します。その後は 1 回に 1 つずつ変更し、変更ごとに eval を流して前後を比べます。自分のエージェントで使う前に試せる、模擬のサポートシステムのデモも付いています。README には参照実装であり、保守もコントリビューションの受け付けもしないと書かれています。

自分の構成を判断する｜FIXIT の見方

ここからは公式の記述ではなく、私たちの見方です。

専門のエージェントを何体も並べた構成の案を見たときは、公式の指針に照らして、次の順番で確かめるのがよいと考えています。

1. 3 条件のどれに当たるかを先に確かめる。当たらない分割は、畳む候補にする
2. 分割の単位が、問題の種類になっていないかを見る。問題の種類で分けた構成は、受け渡しで情報が失われやすい
3. eval があるかを確かめる。eval が無い構成は、畳んでも畳まなくても、良し悪しを言えない
4. ツール定義の数を数える。30〜50 個を超えているなら、意図ごとにまとめ直す余地と、tool search を使う余地を探す

FIXIT

畳んだら品質が落ちた、ってことにならない？

Tsukasa

落ちる構成はあります。だから 1 つずつ畳んで前後の eval を比べ、統合版が劣るならそのサブエージェントは残します。

構成を決める前に eval を持っておくと、発注側も提案を評価しやすくなります。提案された構成の複雑さが品質に見合う価値なのか、単なるコストなのかを、同じ eval で比べて確かめられるからです。

公式に書かれていないこと

確認した範囲で、公式の記事に書かれていないことがあります。

• 比較した企業の名前、件数、品質の差の大きさ
• コストの金額、または削減率
• 速度 2 倍と、Claude Code のシステムプロンプトの 80% 超の削減を、第三者が検証した結果
• Claude Code のサブエージェント機能について、減らすべきかどうか

記事は Claude Platform でエージェントを作る場面を対象にしています。書かれていない部分を、書かれているかのように補って読まないでください。原文は Building agents: When to fold subagents into your main agent loop (英語) で確認できます。

FIXIT の運用｜構成の見直しを測ってから決める

エージェントの構成は、感覚ではなく評価の結果で決めるのがよいと考えています。畳むにしても残すにしても、前後を同じ基準で比べます。

モデルが更新されるたびに、以前は必要だった分割が不要になる可能性があります。構成を一度決めて終わりにせず、見直す手順を持っておくほうが、運用の手間は小さく済むと考えています。

まず eval を 10 個作る

構成を見直すなら、最初の一歩は、実際の業務から取った 10 個ほどのサンプルと、合格の基準を書くことです。公式が書くとおり、10 個でも始められます。

エージェントの構成の見直しや、AI を組み込んだプロダクトの設計は AI エージェント開発 で、AI を前提にした開発体制づくりは AI 駆動開発 でお手伝いしています。サブエージェントを使った設計の作り方は Claude Code の subagent の記事 にあります。個別のご相談は お問い合わせ から承っています。