そのサブエージェント、本当に必要？まとめる・残すの判断基準

サブエージェントを増やす前に、分ける理由を部署の違い以外で説明できるかを確かめてください。Anthropic が 2026 年 10 月 22 日に公開した記事 Building agents: When to fold subagents into your main agent loop は、サブエージェントをメインのループへまとめるかどうかの判断基準を示しています。この記事の内容を「まとめる候補」「残す条件」「確かめ方」に整理し、自分の開発環境に当てはめた結果も添えて紹介します。

---

サブエージェントとは何か

サブエージェントは、メインの AI（親）から仕事を頼まれる手伝い役の AI です。親とは別に、自分専用の文脈（その時点で覚えている作業メモ）、ツール（検索や操作を実行する機能）、指示を持ちます。

文脈が別になっているので、親が知っている事情は自動では伝わりません。子に使ってほしい情報は、親から渡す設計が必要です。

サブエージェントが役に立つ場面として、元記事は次の用途を挙げています。Anthropic 自身もこの使い方をしているそうです。

• 検証: コードを書いた本人と切り離して確かめる
• 並列: 別々の作業を同時に進める
• 権限: できることを担当ごとに分ける

便利なので、つい増やしたくなります。問題は増え方にあります。

サブエージェントが増えていく理由

元記事は、AI の構成が会社の組織図のコピーになりがちだと指摘しています。システムの形は、それを作った組織の連絡の取り方に似てくる、というコンウェイの法則として昔から知られている現象です。

ここからは私の見立てですが、作る側にとって自分の会社の部署の分け方がいちばん分かりやすいからだと考えています。部署ごとに窓口が決まっているので、AI も同じ分け方にすれば現場に説明しやすくなります。営業部が営業 AI を作り、次にサポート部がサポート AI を、経理部が経理 AI を頼む。頼まれた順に足していくだけで、構成は組織図と同じ形になります。誰かが悪いわけではなく、自然にそうなります。

ただし、説明しやすい構成と AI が働きやすい構成は別物です。

分けすぎると起きること

元記事は、受け渡しが増えるほど失うものも増えるとして、次の問題を挙げています。

人でも、仕事を引き継ぐたびに細かい事情は落ちていきます。AI も同じで、渡すたびに情報が薄くなります。

待ち時間の約 2 倍という数字は、元記事に書かれた 1 社の比較結果です。測定条件は元記事を参照してください。どの構成でも 2 倍になるわけではありません。また、観察として「1 つの AI とスキルの組み合わせが品質で上回ることが多い」とも書かれていますが、詳しい測定結果までは公開されていません。

それでも、答えの質に不満があるとき、モデルを替える前に構成を見直す余地がある、というのが元記事の主張です。

問い合わせのたらい回しにたとえると

身近な例に置き換えると分かりやすくなります（これは説明のためのたとえで、元記事にある話ではありません）。

保険や携帯電話の契約変更の問い合わせで、受付から担当 A、担当 B と回されるたびに「最初から説明してください」と言われた経験がある人は多いと思います。時間がかかるうえ、話の細部が毎回少しずつ変わっていきます。

一方、同じ担当者が最初から最後まで話を聞き、必要なときだけ手元の棚からマニュアルを開く形なら、説明し直しは起きません。人を増やす前に手順書を整えるという考え方は、AI にも人にも当てはまります。

提案：1 つの AI で回し続ける

元記事が提案しているのは、1 つの AI と 1 つの文脈でループを回し続ける構成です。

ループの中身は単純で、AI 自身が最初のターンで計画を書き、ツールを呼び、結果を読んで次を決める、という流れを回答できるまで繰り返します。計画を立てる AI と実行する AI が同じになるので、結果を見ながら計画をその場で直せます。止まるのは、回答できたとき、またはターン数や費用の上限に達したときです。書き込みを許すかどうかといった制御は、AI 本人に任せず、外側の仕組みで決めておきます。

誤解しやすいのは「1 列に順番に処理する」という意味ではない点です。調べたいものが 3 つあれば、ツール呼び出しを 3 つまとめて並列に出せます。

文脈を太らせないコツ

1 つの AI に全部持たせると、文脈がパンパンになって遅くなったり、間違えたりしないかが気になります。元記事の答えは、最初は目次だけを見せ、必要になったら本文を読ませるやり方（段階的な読み込み）です。

元記事には、次の 2 つの数字も出てきます。

• 80% 超: Claude Code で、高性能モデル向けのシステムプロンプトを削減できた割合。段階的な読み込み以外の工夫も含んだ数字です
• 30〜50 個: システムプロンプトに載せるツール定義がこれを超えると、ツールの選択が落ちやすくなる目安。使えるツール数の上限ではありません

子 AI の中身の移し先

サブエージェントをまとめるとき、中に入っていたものを捨てるわけではありません。引っ越しのように、持ち物を移す先があります。

ツールは裏側のシステムの API ごとに作るのではなく、使う人がやりたいこと単位で束ねると扱いやすくなります。スキルの仕組みは Agent Skills の解説記事、文脈の設計全般は コンテキストエンジニアリングの解説記事 で詳しく紹介しています。

まとめる候補と残す条件

元記事の判断基準は、まとめる候補を見つける基準と、サブエージェントを残す条件の 2 つに分かれています。どちらも入り口の目安で、最終的に決めるのは後述の評価です。

まとめる候補：どれかに当てはまる組

当てはまっただけで決めてはいけません。 「まとめられるかもしれない」という候補にとどまります。

残す条件：どれか 1 つに当てはまれば残す

1 つ目で注意したいのは「測定できる」という部分です。やり取りが長くなって精度が落ちそうだ、というのは感覚の話で、実際に点数が下がるのを見て初めて残す理由になります。

切り方：部署ではなく文脈で切る

残すと決めたあとも、切り方は見直せます。営業 AI・経理 AI・サポート AI のように部署で切ると、前後の話を毎回渡す必要があり、受け渡しで細部が消えやすくなります。

元記事が勧めているのは、周りの事情をほとんど知らなくてもできる仕事だけを切り出し、短い結果だけを返してもらう切り方です。例として、独立した調査や、ブラックボックス検証（中のやり方を見ずに、入力と出力が合っているかだけを確かめる検証）が挙げられています。線を引く基準は、部署の違いではなく、その仕事に必要な周辺情報の量です。

評価で比べながら 1 つずつ統合する

ここまでの基準で候補が見つかっても、一気に作り替えてはいけません。元記事が示す手順は、作り替えるより先に物差しを作ることから始まります。

1. 評価を用意する: 「この質問ならこう答えれば正解」という正解例を用意し、AI の答えを採点できるようにする。正解例は 10 件からでも始められる。答えの文面だけでなく、必要な照会や承認まで実行できたかも確かめる
2. 今の子 AI をツールとして呼ぶ: 今のサブエージェントをそのままツールとして呼ぶ形にし、返す形をそろえて、今の構成の点数（基準）を取る
3. 1 つずつ統合する: スキルとツールへ 1 つずつ移し、そのたびに統合の前後の点数を比べる

一度に複数を変えると、どの変更が効いたのか分からなくなります。一度に変えるのは 1 つだけです。

統合で、通っていた処理が壊れることもある

元記事には、サポート用の AI を統合した結果、応答は速くなったのに、通っていた処理が壊れた例が出てきます。

統合前は、納期を聞かれると配送担当のサブエージェントに確認してから答えていました。統合後は、主担当の AI が確認をせずに自分で答えるようになりました。本来必要な確認が、構成を変えたことで抜け落ちたのです。

しかもこの不具合は 2 回に 1 回しか現れませんでした。1 回だけ試して通ったら、見逃してしまいます。応答が速くなったことだけを見ていれば、改善したようにも見えます。

ここから得られる教訓は 2 つです。

• 同じタスクを複数回、回して確かめる
• 合計点だけで判断しない。前に通っていたタスクと通らなかったタスクが入れ替わっても、合計点は変わらないことがある。どのタスクが反転したかを見る

自分の開発環境に当てはめてみた

私は普段、実装役とレビュー役を別々の AI に分けて開発しています。この分担を、元記事の観点で仮に整理してみました。判定は私によるもので、元記事に書かれたものではありません。

迷ったのは 3 つ目の実装役です。出力を引き継いでいるので、基準に照らすと「まとめる候補」に入ります。ただ、私が実装を分けているのは、費用を抑えたい、作業に合わせてモデルを使い分けたいという理由もあるからです。基準に当てはまったからといってすぐにまとめるのではなく、分ける理由を言えないものから評価にかける、という順番で考えています。

まとめ

サブエージェントは全部やめるべきものではありません。性能・並列・検証・権限分離といった目的で分ける理由を説明でき、測って確かめられるなら、残してかまいません。説明できない分割から見直していきます。

明日から試せることは、次の 3 つです。

1. 今使っているサブエージェントを紙に書き出す（それだけでも、増えた経緯が見えてきます）
2. まとめる候補と残すものに分ける
3. 正解例 10 件を用意し、1 つだけ統合して比べる

KDDIアイレットでは、Claude Code を使った AI 駆動開発の実践知を社内で継続的に共有しています。AI エージェントの設計や開発プロセスへの組み込みについては、お気軽にご相談ください。