---
title: "サブエージェントはいつ畳むか：Anthropicの判断基準と移行の手順"
description: "AnthropicのApplied AIチームが、企業のエージェントで専門のサブエージェントをメインのループに戻した事例と、その判断の仕方を公開しました。残すべき3つの条件、スキルとツールへの移し方、10件の評価から始める手順と、付属の移行キットで何ができるかを確かめます。"
url: https://udon-dev.com/notes/fold-subagents-single-agent-loop/
lang: ja
published: 2026-10-25
topic: [ai]
tags: ["claude", "ai-agent", "subagents", "skills", "claude-platform"]
---

# サブエージェントはいつ畳むか：Anthropicの判断基準と移行の手順

- Anthropicは、企業のエージェントのいくつかで、ルーターや分野別のサブエージェントを1つのループに戻したほうが、品質が上がり、費用と待ち時間も下がることが多かったとしています。比べた数値そのものは公開していません
- サブエージェントを残すのは、文脈が膨らんで性能の低下を測れたとき、使い捨ての文脈で並列に進めたいとき、ツールの選び間違いや指示の衝突が起きるときの3つです
- 移すときは先に10件ほどの評価を作り、サブエージェントを1つずつスキルとツールに置き換えて比べます。1回の実行では出ない失敗があるので、各タスクを複数回走らせます
- 付属の移行キットはルーターと6つのサブエージェントを持つ見本で、APIキーなしの点検から試せます。評価の本番の実行はモデルを呼ぶので、費用がかかります

エージェントを作り込むほど、役割ごとにサブエージェントを足したくなります。問い合わせを振り分けるルーター、計画を立てる役、注文や配送を受け持つ専門の役、という形です。AnthropicのApplied AIチームは10月22日、こうした作りの一部をメインのループに戻したほうがよい場合と判断の仕方を、[Claudeの公式サイト](https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop)で公開しました。対象はClaude Platformで作るエージェントです。

先に断っておくと、記事は「サブエージェントはもう要らない」とは言っていません。検証、並列の作業、権限の切り分けには有効だとし、Anthropic自身の調べものの仕組みでも使っていると書いています。問題にしているのは必要のないところまで分けた作りです。

（図: Claudeの公式記事「Building agents: When to fold subagents into your main agent loop」の画像。薄い緑の地に、4つの点を線でつないだ稲妻の形の図）
出典：[Building agents: When to fold subagents into your main agent loop（Claude公式）](https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop)

## 何がうまくいかなかったのか

記事によると、いくつかの企業のエージェントで、スキルを持つ1つのエージェントを、全部を1つのプロンプトに詰めた作りと、サブエージェントに分けた作りの両方と比べました。スキルを持つ1つのエージェントは品質で上回ることが多く、1件あたりの費用と待ち時間も下がることが多かったそうです。ただし、比べた数値そのものは載っていません。外部の検証記事を書いた[Kim Olsenさん](https://dev.to/kimolsen/ai-sales-agent-test-four-subagents-vs-one-loop-with-skills-58eg)も、その点を指摘しています。

例として挙がっているのは、顧客向けのエージェントに十数個の専門のサブエージェントを持たせていた会社です。ブランドとして一貫した応対を保ちにくく、待ち時間が増えて使い心地を損ねていました。

大きな組織では機能ごとに担当のチームが自分のエージェントを作り、その上に中央のチームが振り分け役を置く、という順で作りがちです。記事はこれを、組織図がそのまま設計になる「コンウェイの法則」の例として挙げ、次の5つの問題が起きると指摘しています。

| 問題 | 起きること |
|---|---|
| 文脈の受け渡し | エージェントのあいだで何を渡すかを決める必要があり、やり取りの途中で細部が落ちる |
| サブエージェントの乱立 | 各チームが自分の分を出すので、重なり合うものが数百に増え、基準も持ち主もいない |
| つぎはぎのプロンプト | 各チームがシステムプロンプトに1文ずつ足し、規則が食い違い、語り口がそろわない |
| 局所的な評価 | 各チームが自分の部分に最適化した評価を足し、全体を見る人がいない |
| 待ち時間 | ある顧客の比較では、1つのループのほうが約2倍速かった |

## 1つのループとスキルで回す形

Anthropicが勧めるのは、1つのモデルと1つのコンテキストウィンドウで回すループです。モデルは毎ターン、ツールの呼び出しをまとめて出し、ハーネス（ループを動かす側のコード）がそれを並列に実行して、結果をそのまま同じモデルに返します。モデルは最初のターンで計画を書き、結果が届くたびに直します。計画を書く役と実行する役が同じなので、途中で計画を変えられます。記事はこれを、振り分け役と専門の役に分けた作りとの一番の違いとしています。ターン数や費用の上限、書き込みの許可の関門は、ハーネスの側に置きます。

1つのループにすると文脈が膨らみそうですが、そこを抑えるのが段階的な読み込みです。[スキル](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview)は、起動の時点では名前と説明だけがシステムプロンプトに入り、依頼が説明に合ったときに本文を読み込みます。公式ドキュメントでは、説明だけなら1つのスキルで約100トークンです。ツールも、[ツール検索](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool)で`defer_loading: true`を付けたものは、探して見つかるまで文脈に入りません。

記事はこの形を選ぶ理由を3つ挙げています。1つ目は前の手順の結果を同じ文脈で見られるので、サブエージェントから返る要約を寄せ集めるより、手順どうしを結び付けた答えになることです。2つ目は、サブエージェントに分ける主な理由だった文脈の膨張を、上の段階的な読み込みで避けられることです。Claude Code自身も、新しいモデル向けのシステムプロンプトを80%以上減らしたとしています。3つ目はモデルの能力で、Opus 4.5以降は多くのチームの予想より多くを1つのループで扱えるようになったと書いています。

もともとサブエージェントや固定の手順が受け持っていた中身は、行き先が分かれます。

| 中身 | 移す先 |
|---|---|
| 手順の順番や、分野ごとのやり方 | スキル |
| 検証、承認の関門、会話の途中で要る処理（記憶の参照など） | ツール |
| 安くてほぼ毎回要るもの（入力の対象を特定する処理など） | コードで先に読み込む |
| 方針、指標の定義、製品の仕様のような参照資料 | 検索のツールか、スキルの中の参照ファイル |

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

Anthropicが挙げる、サブエージェントを残してよい条件は3つあります。1つのループで文脈の膨張による性能の低下を測れたとき、複数のタスクを終わったら捨てる新しい文脈で並列に進めたいとき、1つのエージェントがツールを選び間違えたりシステムプロンプトの中で指示が食い違ったりするときです。

残す場合の分け方にも注意があります。問題の種類で分けると、伝言ゲームのように引き渡しのたびに情報が劣化します。記事が勧めるのは文脈で分ける方法で、システムの残りからほとんど情報を要らない作業を渡し、短い結果を返させます。向いているのは独立した調べもの、境目のはっきりした部品、中身を知らずに行う検証です。

3つの条件のどれかに当たってサブエージェントを残すときは、メインのエージェントがサブエージェントをツールとして呼び、利用者との会話は手放さない形を勧めています。会話そのものを引き渡すのは、そのサブエージェントが利用者と直接話す必要があるときだけです。それ以外は、スキルとツールとしてメインのループに入れられるとしています。

## 移す手順は評価から

記事の手順は先に評価を作るところから始まります。最初は10件の正解つきの例で足りるそうです。最後のメッセージを採点の基準で評価するのが出発点で、振り分け役が残っているあいだは、正しいサブエージェントを選んだかも見るよう勧めています。畳んだあとは正しいスキルを読み込んだか、正しいツールを呼んだかに見る点を変えます。

次に、一緒に動くものからまとめます。互いの出力を受けて動く、同じデータを触る、よく一緒に呼ばれる、という専門の役どうしが候補です。実際の利用で、ある専門の役のすぐあとに別の役が呼ばれる割合が大きければ、1つの分野のエージェントにまとめる候補になります。

書き直す前の一歩として、サブエージェントをツールとして呼ぶ形もあります。この形なら、サブエージェントが返す形をそろえられ、メインのエージェントが本物のデータで結論を確かめられます。ただ、専門の役ごとにプロンプトや評価が分かれたままで、呼ぶたびに情報の落ちる要約が返り、入れ子のループの分だけ待ち時間も増えます。

最後に、残りを1つずつスキルとツールに置き換えて、置き換える前と後で評価を比べます。記事は合計の点数だけでなく、結果が変わったタスクを見るよう勧めています。見本のサポート用エージェントで試したとき、待ち時間は減ったものの、通っていた処理が1つ壊れました。メインのエージェントが注文の検索ツールを持ったことで、配送の担当に届く日を聞かずに自分で答えてしまったのです。この壊れ方は2回の実行のうち1回でしか出なかったため、各タスクを複数回走らせる必要があります。

## 複数のチームで1つのエージェントを育てる

1つのループにしても、各チームの持ち場は残ります。記事の案では各チームはエージェントの代わりにスキルとツールを持ち、小さな中央のチームがシステムプロンプトと全体の品質を持ちます。新しいスキル、ツール、評価は、中央のチームが確かめてから出します。

ツールは操作をする、システムから最新のデータを読む、決まった形で結果を返す、といったときに使います。APIごとに1つではなく、利用者の意図ごとにまとめるよう勧めています。ツールの定義が30から50を超えると、選ぶ精度が落ちやすいという理由です。利用者ごとの権限もツールの中で確かめ、許されない操作には、モデルが読める断りの文を返します。こうすれば、権限の段階ごとに別のエージェントを用意しなくても済みます。

スキルはチームの仕事の進め方、つまり専門の役のプロンプトが持っていた手順や規則、判断の目安を書く場所です。スキルが増えすぎないよう、チームごとに責任者を置き、`/skill-creator`で形を整え、`/skill-doctor`でスキルごとの費用と使われた回数を見て、使われていないものを消すよう勧めています。

## 移行キットで何ができるか

記事には[移行キット](https://github.com/anthropics/single-agent-loop-kit)が付いています。見本は振り分け役と6つのサブエージェントを持つ架空のサポート窓口で、19件の評価のタスクと、200件の合成の実行記録が入っています。`KIT_MODEL=fake`を付けた点検はAPIキーが要らず、費用もかかりません。ただ、これは仕組みがつながっているかを見るだけで、採点はしません。

自分のリポジトリに使うときは、キットのスキルを`.claude/skills/`に写し、Claude Codeで実行します。最初にサブエージェントの一覧を作り、それぞれを「畳む」「まとめる」「ツールとして呼ぶ」「残す」に分けて見せたところで、一度止まる作りです。費用のかかる実行の前、基準の測定のあと、変更のたびにも止まり、実行の前にはトークンの見積もりが出ます。評価の実行はタスクと繰り返しの回数ごとにモデルを呼ぶので、READMEは10件のタスクと2〜3回の繰り返しから始めるよう勧めています。

キットは参照用の実装で、保守も貢献の受け付けもしないと明記されています。実際のモデルで動かしたのは見本での2回だけで、まとめる手順や、評価のないリポジトリから始める流れは、まだ実際のモデルで試していないとREADMEに書かれています。

READMEはキットが要らない場合も挙げています。まだサブエージェントがないなら、最初から1つのループで始めればよく、サブエージェントが文脈を分ける意味を持っているなら残すという判断です。テスト用の依頼でシステムを動かす方法と、正しい結果を判定できる人のどちらかが欠けているなら、先にそれを用意します。点数がなければ、移すかどうかは意見の問題になってしまうためです。

## 外部の検証では

記事の翌日、Kim Olsenさんが[見積もりの窓口を2通りに作って比べた結果](https://dev.to/kimolsen/ai-sales-agent-test-four-subagents-vs-one-loop-with-skills-58eg)を公開しています。架空の家具会社に届いた12通のメールを、振り分け役が3つの専門の役に問い合わせる作りと、スキルを読み込む1つのループで、それぞれ3回ずつ処理しました。8つの確認の項目を全て満たしたのは、1つのループが36件中36件、4つのエージェントが36件中29件でした。見積もり1件あたりの時間の中央値は、4つのエージェントが13.9秒、1つのループが7.3秒です。費用の平均は4.1セントと2.0セントで、こちらも1つのループが約半分でした。

4つのエージェントが落とした7件は、どれも製品コードの抜けを含んでいました。振り分け役は商品の一覧を持たず、価格の担当への質問で製品コードを求めなかった7件で、見積もりに商品名だけが載りました。もう1つ、Olsenさんは引き渡しでの掛け算の誤りも挙げています。120脚の注文で、価格の担当は3回のうち2回、掛け算を間違えました。振り分け役は、そのうち1回は計算し直し、もう1回は誤った合計をそのまま見積もりに写しています。一方で、1つのループは毎回3つのスキルを全て読み込んだため、段階的な読み込みによる節約はこの例ではありませんでした。差は1つの文脈で検索をまとめて実行したところから出ています。検証は1つの窓口、1つのモデル、架空のデータでの結果で、Olsenさん自身も、1つのループが常に勝つ証明としては扱わないよう書いています。

Anthropicの記事も結びで、どの作りを選ぶかより、測ること、1度に1つだけ変えること、成り立ったものを残すことを原則に置いています。モデルが変われば、使い方の理解も勧める作りも変わるため、特定の作りより原則のほうが大事だという理由です。手元にサブエージェントがいくつもあるなら、どれが3つの条件のどれに当たるかを書き出すところから始められそうです。