Anthropic のエージェント設計ガイド サブエージェントをメインのループに取り込む

グラレコ

上のグラレコは、この記事で扱う Anthropic の記事の要点を1枚にまとめたものです。サブエージェントが今も役に立つ場面、組織図のコピーになる問題、大きな組織で起きやすい失敗、必要なときだけ読み込む設計、1つのループの動き方、分けるなら何で分けるか、1体ずつ取り込む手順、チームごとの持ち物までを8つのブロックに並べています。下の帯は移行の流れです。細かい話は本文で1つずつ見ていくので、まずは全体の地図として眺めてみてください 🗺️

はじめに

Anthropic は 2026年10月22日、Claude の公式サイトのリソースに「Building agents: When to fold subagents into your main agent loop」という記事を公開しました。著者は Diane Sarkis 氏で、カテゴリーは「Best practices」「Perspectives」、対象の製品は Claude Platform です。

この記事のテーマは、複数のサブエージェントで組んだエージェントを、どういうときに「1つのメインループ＋スキル＋ツール」の形に寄せるべきかです。Anthropic の Applied AI チームが企業のエージェント導入を支援する中で、ルーター（振り分け役）、プランナー（計画役）、領域ごとのサブエージェントをメインのループに取り込むことで良くなったケースが続いた、というのが記事の出発点になっています。

記事の主張を一言でまとめると、次のようになります。

サブエージェントを減らし、そのぶんコンテキストとツールを必要になったときに段階的に読み込むようにすると、品質を上げつつ、コストと遅延を下げられることがある。

ただし、記事は「サブエージェントは不要になった」とは言っていません。今でも使うべき場面をはっきり挙げたうえで、「組織図をそのままエージェント構成にしてしまう」ことへの注意を促す内容です。あわせて、移行を手伝う single-agent-loop-kit（移行キット）も GitHub で公開されています。

この記事では、元記事の内容を日本語で整理し、移行キットの中身も補足しながら紹介します。

この記事でわかること 📌

• サブエージェントが今でも役に立つ3つの場面と、そうでない場面
• 大きな組織でエージェントを作るときに起きやすい5つの失敗
• 「必要なときに読み込む」設計が効く3つの理由
• 目指すべき「1つのエージェントループ」の動き方と、コンテキストの置き場所
• サブエージェントを段階的に減らす3つの方法と、評価の作り方
• 複数のチームが1つのエージェントに関わり続けるための役割分担
• 移行を手伝う Claude Code のコマンドと、移行キットの使い方

想定読者は、Claude Platform（Claude API）や Claude Agent SDK などで、複数のサブエージェントを組み合わせたエージェントを作っている、または設計を検討している開発者の方です。

サブエージェントとは、そして今でも使うべき場面 🤝

サブエージェントのおさらい

元記事では、サブエージェントを「独自のコンテキストウィンドウ・ツール・指示を持ち、取りまとめ役（コーディネーター）によって指揮されるエージェント」と定義しています。エージェント設計の中心的な部品で、元記事によると、次のような用途で効果を発揮します。

• 検証（別の目で結果を確かめる）
• 並列作業（複数の調べものを同時に進める）
• 権限の分離（部品ごとに使えるツールを分ける）

Anthropic 自身も、Claude Platform で作る多くのエージェントでサブエージェントを使っていて、例としてマルチエージェントのリサーチシステムが挙げられています。

それでも「取り込んだ方が良かった」ケースが増えている

一方で、企業向けのエージェントでは、ルーター・プランナー・領域ごとのサブエージェントをメインのループに取り込んだ方が良くなるパターンが見えてきた、と元記事は書いています。複数の企業導入での比較では、スキルを持つ単一のエージェントが、「1つのプロンプトに何でも詰め込む設計」と「サブエージェント設計」の両方を品質で上回ることが多く、タスクあたりのコストと遅延も低いことが多かったそうです。

具体例として挙げられているのは、ある企業の顧客向けエージェントです。中に十数個の専門サブエージェントがあり、そのせいでブランドに沿った一貫した体験を保つのが難しく、遅延も増えてユーザー体験を損ねていました。

よく見かける「5層構造」

元記事には、提案されるエージェント設計によく見られる「お決まりの流れ」も紹介されています。次の図は、元記事の図をもとに、その構造を書き起こしたものです。

意図の分類器、固定の多段推論パイプライン、ユーザー区分ごとの振り分け、推薦の分岐、そして一番上にマルチエージェントの司令塔という、モデルの周りに5層の構造を積み上げた形です。

こうした設計に対して寄せられるフィードバックは、「この構造の大半は、もうモデルが手伝ってもらう必要のない仕事をしていた」というものが多いそうです。代わりに勧められているのが、次のシンプルな形です。

2つの図を見比べると、層の数がまったく違います。筆者の見方では、上の5層構造は分類や分岐をあらかじめ構造として決めていて、下の1ループはその判断をモデルに任せている、という違いです。元記事は「明確なシステムプロンプト1つ、薄いデータツール4〜5個、確かな出力ガードレールで、ユースケースの大半をカバーできる」とまとめています。

サブエージェントを使うべき3つの場面

誤解のないように、元記事はサブエージェントが今でも必要な場面を明記しています。研究の最前線でも、サブエージェントはまだ居場所がある、と書かれています。

場面	具体的には
コンテキストの肥大化	1つのエージェントループで、コンテキストが膨らみすぎて測定できるほどの性能低下が起きている
新しいコンテキストでの並列作業	複数のタスクを並列に進める必要があり、それぞれ新しいコンテキストで取り組み、終わったら捨ててよい
ツール選択の難しさ・指示の衝突	1つのエージェントが適切なツールを選べない、またはシステムプロンプトの中に矛盾する指示がある

どれも「実際に問題や必要性が見えている」ことが前提になっている点がポイントです。特に1つ目は「測定できるほどの」と明記されています。「なんとなく分けた方がきれいそう」は、この3つのどれにも当てはまりません 🙂

組織図のコピーになっていないか

元記事がもう1つ指摘しているのが、エージェント構成が組織図のコピーになってしまう問題です。

企業がチームや問題の種類ごとに専用のサブエージェントを持たせ、エージェントのアーキテクチャが組織図のコピーになっている例を、あまりにも頻繁に目にします（コンウェイの法則が働いている状態です）。

コンウェイの法則は、「システムの構造は、それを作った組織のコミュニケーション構造に似る」という経験則です。チームごとにサブエージェントを作ると、技術的な理由ではなく組織上の理由で境界が引かれてしまいます。

大きな組織で起きやすい5つの失敗 ⚠️

元記事は、大きな組織がエージェントを作るときによく起きる流れを、次のように説明しています。

1. 会社としては、複数の製品や機能を1つの顧客向け窓口にまとめたい
2. それぞれの機能は別々のチームが持っているので、まず各チームに自分たちのエージェントを作ってもらう
3. その上に、中央のプラットフォームチームが司令塔を作る（司令塔＋サブエージェント型、または各エージェントを MCP ツールとして公開する型）

一見すると一番シンプルな解決策に見えますが、元記事によると、すぐに次の5つの複雑さが生まれます。

失敗	何が起きるか
コンテキスト管理	エージェント間でどのコンテキストをやり取りするかを決める必要があり、やり取りの中で細部が抜け落ちやすい
サブエージェントの乱立	各チームが自分のサブエージェントを出すので、重複した数百のサブエージェントが、統一された基準も特定の担当者もないまま並ぶ
つぎはぎプロンプト（元記事では "The Frankenprompt"）	各チームがシステムプロンプトに1文ずつ足していくので、ルールが矛盾し、口調もそろわなくなる
審査されない、局所的すぎる評価	各チームが自分のサブタスクに最適化しすぎた評価を足す。全体を持つ人も保守する人もおらず、経営層は薄められた局所的なスコアをもとに判断することになる
遅延	マルチエージェント構成の複雑さが遅延を増やす。ある顧客では、マルチエージェント構成と単一のエージェントループを比べたところ、後者の方がおよそ2倍速く動いた

この中で、地味に効いてくるのが「つぎはぎプロンプト」と「局所的な評価」だと思います。どちらも1つひとつは善意の追加なのに、積み重なると「誰も全体を説明できない」状態になってしまいます（チームが多い組織ほど、これは起きやすいはずです）。

「必要なときに読み込む」エージェントループ 📚

段階的な開示とは

ここまで見てきた司令塔＋サブエージェント型は、チームをまたいで作られた専門家をまとめる方法としては妥当です。ただ元記事は、多くの場合それより効果的になりうる方法として、次の2つを挙げています。

• スキルでコンテキストを段階的に開示する
• ツール検索でツールを段階的に開示する

言い換えると、エージェントにはまずスキルとツールの短い説明文だけを見せておき、本文やツールの定義は必要になったときだけ読み込ませる、という設計です。次の図は、返品の問い合わせを例にした筆者による例です（元記事にはない例です）。

この図のポイントは、返品と関係のない領域のスキルやツールは、最後まで一度も読み込まれないことです。システムプロンプトを短く保ったまま、エージェントが扱える領域を広げられます。

この設計が理にかなう3つの理由

元記事は、この方法が理にかなっている理由を3つ挙げています。

① 共有されたコンテキストが、より良い答えを生む 🧠

長く動くエージェントでは、いくつものタスクのコンテキストがメインのコンテキストウィンドウに載っていてほしい、と元記事は書いています。それまでの各ステップの結果を見てきたエージェントは、それらを結びつけられます。サブエージェントから返ってくる要約の寄せ集めより、豊かな出力と良い洞察につながります。コンテキストウィンドウの数が減り、情報が抜け落ちる引き継ぎも減ります。

② 段階的な開示が、コンテキストの肥大化を防ぐ 📉

段階的な開示を使えば、すべてのコンテキストを1つの長いシステムプロンプトに最初から詰め込まなくても、幅広いタスクをこなす単一のエージェントを作れます。元記事は「これで、チームがこれまで仕事をサブエージェントに分けていた一番の理由がなくなる」と書いています。実際、Anthropic は、より高性能なモデル向けの Claude Code のシステムプロンプトを 80% 以上削減していて、その中にはスキルとツールの段階的な開示に関係する削減も含まれていたそうです。

③ モデルの能力が上がっている 🚀

元記事によると、Opus 4.5 以降、モデルはほとんどのチームが予想していたよりもはるかに多くのことを1つのループで管理できるようになりました。Opus 5.5 と Fable 5.1 では思考（thinking）をオフにできず、最近のモデルはますます、作業しながら進捗を説明し、自分の仕事を確かめるようになっているため、ハーネス（モデルを動かす周辺のコード）の一部の要素は不要になっています。

新しいモデルが出るたびに、判断をハーネスからモデル自身に移せる範囲が広がります。さらに、シンプルなループは次のモデルへの移行も楽です。元記事には「私たちが手伝った移行では、硬直したマルチエージェント構造こそが、新しいモデルにもっと仕事を任せる妨げになっていたことが多かった」と書かれています。

単一ループには規律が要る

ただし、単一ループは「何でも1つに詰め込めばよい」という話ではありません。元記事は、次のような規律が必要だと書いています。

• 丁寧に管理されたシステムプロンプト
• 適切なタイミングで呼び出されるスキルとツールの説明文
• コンテキストウィンドウ、記憶、メモ取りの意図的な扱い

そして、1つの中央チームが、エンドツーエンドの品質とシステムプロンプトを持つべきだとしています。中央チームは、新しいツールや評価をリリース前にすべて審査します。このチームを小さく保つことで、改善のサイクルを速く回せ、大きな組織での調整コストも下げられるそうです。

分けるなら「問題の種類」ではなく「コンテキスト」で ✂️

それでもマルチエージェントにする場合について、元記事は2つのアドバイスをしています。

1. うまくいきそうな一番シンプルなパターンから始める（生成役＋検証役、司令塔＋サブエージェントなど）
2. 境界は「コンテキスト」で分ける。各サブエージェントには、システムの他の部分からほとんど何も必要としない仕事を渡し、コンパクトな結果を返してもらう

良い候補として挙げられているのは、独立した調査の筋、きれいなインターフェースで分かれた別々のコンポーネント、中身を知らなくてよい検証（ブラックボックス検証）です。

逆に、問題の種類で分けると「伝言ゲーム」になる、と元記事は警告しています。引き継ぐたびに情報の正確さが落ちていくからです。元記事の図にある例を、Mermaid で描き直すと次のようになります。まずは問題の種類で分けた場合です。

引き継ぐたびにコンテキストが失われ、テストを書くエージェントは、なぜその実装にしたのかを知りません。次に、コンテキストで分けた場合です。

テストを実行して結果を報告するだけの検証役なら、実装のコンテキストは要りません。ここで分けても、伝言ゲームにはならないわけです。

「誰が担当しているか」ではなく「その仕事に、どこまでのコンテキストが必要か」で境界を引く、という考え方は、エージェント以外の設計にもそのまま使える話だと思います。

目指すべき「1つのエージェントループ」の設計 🔁

ループの動き方

多くのチームは、すでに司令塔と専門エージェントの組み合わせを本番で動かしています。元記事は、そこから目指していく単一ループの設計を、次のように説明しています。

• 1つのモデルと1つのコンテキストウィンドウで、終わりの決まっていないツールループを回す。上限（ターン数とコストの予算、書き込み前の承認ゲート）はハーネス側で設定する
• 毎ターン、モデルはツール呼び出しをまとめて出す。ハーネスはそれらを並列に実行し、生の結果を同じモデルに返す。モデルは次の一手（次のまとまり、ユーザーへの質問、または回答）を決める
• ループは、モデルが回答するか、予算に達したら止まる。回答の後に、任意でゴールや検証役のチェックを走らせられる
• モデルは最初のターンに計画をコンテキストに書き、結果が届くたびに改訂する

元記事は、司令塔＋専門エージェント型からの一番大きな変化は最後の点だと書いています。計画を書くモデルと、それを実行するモデルが同じなので、ターンの途中でも計画を変えられるのです。逆に言えば、司令塔が計画を立てて専門家が実行する構成では、実行中にわかったことを計画に反映するのに、引き継ぎの往復が必要になる、ということです（この1文は筆者の補足です）。

移行キットに含まれる参照実装（reference_loop/loop.py）は、このループを読みやすく書いたものです。コードの Budget クラスにある既定の予算は、次のようになっています。

@dataclass
class Budget:
    max_turns: int = 25
    max_tokens: int = 400_000   # input plus output, summed over one call to run(), subagents included
    max_batch: int = 16         # tool calls run from one model turn; the rest get an error result

ターン数、トークン数（サブエージェントが使った分も含む）、1ターンで実行するツール呼び出しの数に上限を設けています。上限はハーネス側で設定する、という元記事の考え方が、そのままコードになっています（loop.py の冒頭には「上限はプロンプトではなくハーネスに置く」とあります）。参照実装は「フレームワークではなく参照用。自分のハーネスに足りない部分をコピーして使ってほしい」と位置づけられています。

コンテキストはどこに置くか

単一ループでも、コンテキストはもちろん読み込まれます。違うのは、それをエージェント自身が管理することです。元記事が示す置き場所を表にまとめると、次のようになります。右端の列は、1行目を除いて筆者の補足です（元記事が理由を書いているのは1行目だけです）。

何を	どこに置くか	補足（1行目のみ元記事）
ルールのカタログから計画を書き換えるコード	不要になる	各ステップをモデルが決めるから
手順の順序や、その領域のやり方	スキル	必要なときに読み込めばよい
ハードな制限（検証、承認ゲート）	ツール	ツールの中なら確実に守らせられる
会話の途中で必要になるもの（記憶の参照など）	ツール	必要になったときにモデルが呼べる
安くて、ほぼ常に関係するもの（例：エンティティの特定。顧客や商品が誰・何なのかを確定する処理）	コード	ほぼ毎回必要なら、コードで用意した方が安い
機械的な処理（ペイロードの組み立て、ストリームの解析、確認の質問からの再開）	コード（ループが呼ぶツールの中）	判断が要らない部分はコードの方が確実

筆者なりにまとめると、判断が要るものはモデルとスキルへ、確実に守らせたいものはツールへ、判断の要らない機械的なものはコードへ、という分け方です。

元記事は、この単一ループの設計が、多くのチームが目指している最終形、つまりユーザーの大きな目標を理解して、代わりに行動してくれるエージェントにもつながると書いています。エージェントが学んだことを、すべて1つのコンテキストにとどめておけるからです。

移行の第一歩：タスク完了の評価を作る 🎯

ここからは、マルチエージェント構成から単一ループへ、段階的に移っていく方法です。最初の一歩は、評価セットを作ることです。

評価の持ち方

元記事でうまくいったとされている評価の構造は、次の2層です。

中央チームが持つ共有のエンドツーエンド評価セットと、各チームが自分のスキルと一緒に出す小さな評価セットの組み合わせです。元記事は「正解付きの例が10件あれば、始めるには十分」と書いています。最初から完璧な評価を作ろうとしなくてよい、というのは心強い話です。

何を測るか

測る対象は、移行の段階によって変わります。

段階	測るもの
最初の出発点	エージェントの最終メッセージを、採点基準に沿って採点する
司令塔が残っている間	（最終メッセージの採点に加えて）振り分けの正確さ（正しいサブエージェントを選んだか）
サブエージェントを取り込んだ後	振り分けの代わりに、正しいスキルを読み込んだか、正しいツールを呼んだか
長期的に目指すもの	タスク完了の評価（アーキテクチャを比べるときに一番大事）

社内のシステムを再現しにくい環境や、ユーザーとのやり取りをシミュレーションしにくい環境では、評価を作るのは簡単ではありません。元記事では、Anthropic 社内でうまくいった方法として、重要なイベントにタイムスタンプを記録しておき、後で再生して狙いを絞った評価として使う方法が紹介されています。

サブエージェントを減らす3つの方法 🧩

単一ループに近づくには、サブエージェントをツールやスキルに取り込んでいきます。元記事が挙げる方法は3つです。元記事の図をもとに整理すると、次のようになります。

① 領域ごとのエージェントを統合する

最初の統合の前に、小さなエンドツーエンド評価を作っておきます。そのうえで、コンテキストを共有しているものから、利用の多いサブエージェントを優先してまとめていきます。

統合の候補になるのは、次のような専門エージェントです。

• お互いの出力を連鎖して使っている
• 同じデータを触っている
• 一緒に呼ばれることが多い

元記事の例では、本番のトラフィックのかなりの割合が「ある専門家の後に、別の専門家」という流れになっているなら、その2つは強く結びついたペアで、1つの領域エージェントにまとめる候補になる、とされています。

② サブエージェントをツールとして呼ぶ

先ほどの「サブエージェントを使うべき3つの場面」のどれかに当てはまり、サブエージェントを残す場合は、メインのエージェントがサブエージェントをツールとして呼ぶ形にすると効果的な場合があります。こうすると、メインのエージェントがユーザーとの会話を持ち続けられます。

元記事は、サブエージェントが会話を丸ごと引き継ぐ完全な引き継ぎを勧めるのは、そのサブエージェントがユーザーと直接話す必要があるときだけだとしています。それ以外は、メインループのスキル＋ツールにできるからです。

ツールとして呼ぶ形には、次のような利点があります。

• サブエージェントの共通の応答スキーマを定義できる
• 結論を、メインのエージェントが実データと照らし合わせて確かめられる
• 最後のまとめのステップへの入力を絞れる
• サブエージェントを書き直す必要がないので、最初の一歩として取り組みやすい
• 取り込むかどうかを決める前に、タスク完了評価の基準値が取れる

一方で、次の失敗はまだ残ります。

• 専門家ごとに、プロンプト・コンテキスト・担当チーム・評価がバラバラなまま
• 呼び出すたびに、情報が抜け落ちた要約が返ってくる
• 呼び出しのたびにモデルのループが入れ子になり、遅延が増える

③ スキルとツールに取り込む

最後が本命の方法です。サブエージェントを1体ずつメインのエージェントに取り込みます。

• 各サブエージェントのプロンプトはスキルにする
• 各サブエージェントの API 呼び出しは MCP ツールにする
• そのサブエージェントがある場合とない場合で、評価の成績を比べる
• どちらを残すかを決める

元記事の結びにある「小さなエンドツーエンド評価を作り、サブエージェントを1体取り込み、取り込んだ版の成績が悪い場合だけサブエージェントとして残す。それを繰り返す」という手順を、そのまま図にしたものです。

比べるときの落とし穴：最終スコアだけを見ない

比べるときに大事なのは、最終スコアだけを見ず、どのタスクの結果がひっくり返ったかを見ることです。元記事には、サンプルのサポートエージェントで試したときの例が載っています。

1つのサブエージェントを別のサブエージェントに取り込んだところ、遅延は下がりましたが、それまで通っていた処理が壊れました。メインのエージェントが注文検索ツールを持っていて、配送の専門家に配達日を聞かずに、自分で答えてしまったのです。

平均スコアだけを見ていると、こうした「1つの処理が静かに壊れる」ことを見落としかねません。そこで元記事は、変更の前に次の2点を確認するよう勧めています。

• 評価に、本番で一緒に動くエージェントの連鎖ごとのタスクと、エージェントが破ってはいけないルールごとのタスクがあること
• 各タスクを複数回実行すること（この例の壊れ方は、2回に1回しか現れなかったそうです）

LLM の出力には揺らぎがあるので、1回の実行で「大丈夫だった」と判断するのは危ない、ということです。この話は、エージェントの評価全般に通じる大事な注意だと思います 🔍

複数のチームが1つのエージェントに関わり続ける方法 👥

単一ループにすると、「各チームの居場所がなくなるのでは」と心配になるかもしれません。元記事の答えは、各チームの持ち物を「エージェント」から「スキルとツール」に移すというものです。

領域ごとの知識や判断は、ナレッジベース、スキル、MCP ツールから取り出せます。各チームはスキルとツールを持ち、1つの小さな中央チームがシステムプロンプトとエンドツーエンドの品質を持ちます。中央チームは、新しいスキル・ツール・評価をリリース前に審査します。

3つの部品の使い分け

元記事では、領域の知識や判断を取り出す先として、3つの部品を挙げています。各チームの持ち物として元記事が明示しているのは、このうちスキルとツールです。

部品	向いているもの	設計のポイント
MCP ツール 🔧	アクションを起こす、システムからライブデータを読む、決まった形の結果を返す	ユーザーの意図ごとにまとめる（API ごとに1つではない）。ツール検索で遅延読み込みする。前提条件と権限チェックはツールの中で行う
スキル 📘	チームの仕事のやり方（以前は専門サブエージェントのプロンプトに入っていた手順・ルール・判断）	チームごとの担当責任者（DRI）が持つ。よく作られていて、他と重ならず、適切な評価と一緒に出す
ナレッジベース 📚	エージェントがときどきしか必要としない参照資料（ポリシー、指標の定義、製品仕様）	モデルが呼ぶ検索ツールの裏に置くか、スキルの中に参照ファイルとして入れる。コードで取ってきてプロンプトに貼るのは避ける

MCP ツールの設計で気をつけること

ツールについては、元記事に具体的な数字があります。

システムプロンプトのツール定義が 30〜50 個を超えると、ツールの選択がうまくいかなくなる傾向があります。

そのため、API ごとに1つのツールを作るのではなく、ユーザーの意図ごとにまとめることが勧められています。あわせて、ツール検索を使った遅延読み込みも推奨されています。ツールは、移行中にサブエージェントを呼び続けるための手段としても使えます。

前提条件の扱い方も参考になります。元記事の例では、「Y の処理に X の出力が必要」という場合、Y のツールが X の出力の有無をチェックし、なければモデルが次にどう動けばよいかわかる指示を返します。ハードな前提条件はできるだけ減らし、残る前提条件はツールの中に入れる、という方針です。

ユーザーごとの権限も同じ考え方で扱えます。

各ツールが、呼び出したユーザーに何が見えて何ができるかを確認し、モデルが読める平易な拒否を返します。こうすると、権限レベルごとに別のエージェントを用意しなくても、1つのループで権限の違うユーザーに対応できます。

スキルの増えすぎを防ぐ

スキルについて、元記事は「スキルの保守は、スキルを書く人たちに返す」という方針を取っています。重い作業は、ほかのスキルを作成・テスト・整理するスキルを使って Claude に任せられます。

スキルの乱立を防ぐには、チームごとの担当責任者（DRI）が自分たちのスキルを持ち、よく作られていて、他と重ならず、適切な評価と一緒に出されるようにします。そのための道具として、元記事では次の2つのコマンドが紹介されています。

• /skill-creator: 最初からきちんとした形の新しいスキルを書ける。既存のスキルを監査して、削る・重複をなくす・構成し直すこともできる
• /skill-doctor: ライブラリの各スキルにどれだけコストがかかり、実際にどれくらい使われているかを確認し、使われていないスキルを削除できる

なお、移行キットの README によると、/skill-creator はプラグインで、/plugin install skill-creator@claude-plugins-official でインストールします。

移行を加速するツール 🛠️

元記事では、ここまでの作業の大半を手伝う Claude API スキルも紹介されています。Claude Code のコマンドとして使えるものです。

コマンド	何をするか	移行での使いどころ
/claude-api build-eval	評価セットを作る	中央チームが持つ最初のエンドツーエンド評価や、各チームがスキルと一緒に出す小さな評価を作る
/claude-api prompt-audit	プロンプト・スキル・ツールの説明文から、古いモデル向けに書かれた指示を見つけ、修正案を差分で示す	以前のモデルのために足され、今ではエージェントを遅く・硬くしているルールを探す。各チームの担当者が自分のスキルにも使える
/claude-api hillclimb	既存の評価をもとに、アプリの改善を繰り返し重ねる	「取り込んだ版」と「残した版」の比較に使う。スキル＋ツールに取り込んだ後、その説明文の改善を重ね、サブエージェント版に並ぶか上回るかを見る。システムプロンプトにも使える
/claude-api cost-optimize	呼び出しの内訳を調べ、プロンプトキャッシュ、不要な入出力トークンの削減、effort、モデル選択などから、1つずつ節約案を出す	ある設計のコストと遅延を下げる（移行キットでは、設計が固まった後に使うとしている）

hillclimb について、移行キットの手順書では、取り込んだ版がサブエージェント版に及ばなかったとき、すぐにあきらめずに説明文の改善を重ねてから判断するために使う、という位置づけになっています。この使い方は覚えておくとよさそうです。

移行キット single-agent-loop-kit の中身 🧰

元記事の冒頭と末尾で紹介されている移行キットは、GitHub の anthropics/single-agent-loop-kit で公開されています（Apache-2.0）。ここからは、元記事には書かれていない、キットの README と手順書の内容を補足します。

📝 README には「参照実装であり、メンテナンスされておらず、コントリビューションも受け付けていない」と明記されています。Issue やプルリクエストも見られていないので、フォークして自分のシステムに合わせて使う前提のものです。

キットの考え方

キットの README は、「単一ループが常に勝つとは仮定しない。測る」と書いています。すべての変更を、同じ評価で前後比較し、置き換え先が持ちこたえると数字が示したときだけサブエージェントを外します。手順は大きく3段階です。

1. 測る: 既存の評価を探し、足りない部分を補い、今のシステムの点数を取る。評価がなければ、一緒に作る
2. 統合する: いつも一緒に動くサブエージェントをまとめる
3. 取り込む: 残ったサブエージェントを1体ずつスキルとツールに変えて比べる。独自のコンテキストに値するものは残し、ツールとして呼ぶ

その後は、1つの小さなチームがシステムプロンプトと共有の評価を持ち、各領域チームがスキルを持つ形で維持していきます。

4種類の判定

キットの監査ステップでは、各サブエージェントに次のどれかの判定を付けます。

判定	どんなときに付けるか
fold（取り込む）	既定の判定。サブエージェントがプロンプト（手順・領域の知識）と API 呼び出しの組み合わせで、別のコンテキストを必要としない。スキル・ツールまたはその両方になる
merge:<相手>（統合する）	2つのサブエージェントが、お互いの出力を連鎖して使う、同じデータを読む、大半のトレースで一緒に動く
as-tool（ツールとして呼ぶ）	独自のコンテキストを持つべきで、仕事が1回の区切られた呼び出しに収まる。メインのエージェントが構造化された結果を受け取り、会話を持ち続ける
keep（そのまま残す）	ユーザーとの会話を自分で持つ必要がある、または他社のもので変更できない。まれ

判断に迷いやすいのが、「独自のコンテキストに値するか」です。キットの手順書は、次の3つのどれかが当てはまることを条件にしています。

• コンテキスト: メインのエージェントが後で必要とするよりはるかに多くを読む（ログ、長い文書、大きな検索結果など）。目安として、1回の呼び出しで数万トークンなら該当し、数千トークンなら該当しない。ただし、ツールが返す量を減らせる（絞り込み・検索・ページ分割）なら、より良いツールを作って fold にする方がよいことが多い
• 並列・独立した作業: 複数の新しいコンテキストで別々に調べる、または作り方を見ずに他の仕事を確かめる
• スキルでは解決できないツール過多や衝突: すべて読み込んだ状態で、メインのエージェントが測定できるほど間違ったツールを選ぶ、または指示が本当に矛盾している

逆に、別のコンテキストに値しない理由として、次のものが挙げられています。

• 社内の別のチームが持っている（持ち物はスキルとその評価に移す）
• 独自のペルソナや口調がある（1つのエージェントは1つの口調であるべき）
• プロンプトが長い（スキルの本文は必要なときだけ読み込まれる）
• ツールが多い（ツール検索で、ツール定義を必要なときに読み込める）
• 手順が決まっている（決まった手順はワークフロー、つまり普通のコードで書ける）

キットの判定条件を、筆者が流れ図にまとめると次のようになります（キット自体に流れ図や判定の順番があるわけではありません。また、監査ではルーター自身に main という判定が付き、これが単一ループの本体になります）。

「別チームが持っているから」「口調が違うから」という理由で残したくなる気持ちはわかりますが、キットははっきり「それは理由にならない」としています。冒頭の「組織図のコピー」の話と、ここでつながってきます。

使い方

自分のシステムに使う場合、README の手順は次の通りです。

git clone https://github.com/anthropics/single-agent-loop-kit
cp -r single-agent-loop-kit/skill <your repo>/.claude/skills/single-agent-loop

あとはエージェントのリポジトリで Claude Code を開き、「Run the single-agent-loop skill.」と頼みます。スキルはまず監査を行い、各サブエージェントの判定（fold / merge / as-tool / keep）を示して止まります。間違っている判定を直したら、計画に沿って1つずつ変更を進め、変更ごとに評価を実行して比較し、残すかどうかは人が決めます。

キットは、毎回同じ4か所で止まって確認を求めるように作られています。変更前の点数を測ること自体が最初の有料の実行になるので、確認②はその前に来ます。

評価がまだない場合でも始められます。その場合、スキルは本番の外でテスト用のリクエストを安全に流す方法と、いくつかの実際のリクエストを求め、10件ほどのタスクを下書きして、それぞれの「完了」の定義を人に直してもらってから実行します。

まずは10分で試せるサンプル

キットには、examples/support-desk という小さなサンプルが入っています。架空の小売店「Tamberwick Home」のサポートデスクで、ルーター＋6つのサブエージェント（account、claims、diagnostics、orders、returns、shipping）で構成されています。各サブエージェントには、あらかじめ「正しい判定」が決められています。

最初は、API キーもコストもかからない無料のチェックから始められます。

cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smoke

オフラインの代役モデルで19件のタスクが流れ、配管が正しく動くかを確認できます（代役はキーワードのルールで動くだけなので、このときの結果は採点されません）。実際のモデルでの監査と取り込みは、RUNBOOK.md の手順で進めます。

📝 キットの example-run/ には、実際のモデルで動かした2回分の記録があります。1回目は 2026年10月8日に claude-opus-5 で実行したもの（監査、12件のタスクで測った変更前の点数、returns サブエージェントの取り込み）、2回目はその翌日に17件のタスクで diagnostics をツールとして呼ぶ形に変えたもの（example-run/as-tool/）です。README によると、測定結果とそこから導いた結論は解説（README と PLAN.md）からは削除されていますが、記録（採点結果とトレース）はそのまま残っていて、比較結果は付属のスクリプトでそこから表示します。また、繰り返し2回では少ない、と記録自身が注意しています。

まとめ 🌱

元記事の主張は、「サブエージェントはもう要らない」ではなく、「サブエージェントの数は、組織図ではなく測定で決める」というものです。

コンテキストの肥大化、新しいコンテキストでの並列作業、ツール選択の難しさや指示の衝突。この3つに当てはまる場面では、今でもサブエージェントが活躍します。一方で、「チームが違うから」「担当領域が違うから」という理由で分けたサブエージェントは、つぎはぎのプロンプト、局所的な評価、伝言ゲームによる情報の抜け落ち、遅延の増加を招きやすくなります。モデルの能力が上がり、スキルとツール検索で必要なときだけコンテキストを読み込めるようになった今、より多くのサブエージェントを、1つのループの中のスキルとツールに置き換えられるようになっている、というのが元記事の見立てです。

この記事で一番持ち帰りたいのは、元記事の結びにある次の原則です。

測る。一度に1つだけ変える。持ちこたえたものを残す。

一度にすべてを作り替える必要はありません。正解付きの例を10件ほど集めて小さなエンドツーエンド評価を作り、利用の多いサブエージェントを1体だけスキルとツールに取り込み、複数回実行して、どのタスクの結果が変わったかを見る。成績が悪ければサブエージェントとして残し、問題なければ次の1体に進む。今のエージェントにサブエージェントがいくつもあるなら、まずは移行キットのサンプルで無料のチェックを流して、流れをつかむところから始めてみてください 🙌

参考

• Building agents: When to fold subagents into your main agent loop — Anthropic（Diane Sarkis、2026年10月22日）。この記事の元記事
• anthropics/single-agent-loop-kit — 元記事の移行キット（Apache-2.0、参照実装）
• How we built our multi-agent research system — Anthropic。サブエージェントを使う例として元記事が参照
• Building multi-agent systems: When and how to use them — 元記事が参照するマルチエージェントの使いどころの記事
• Building agents with Skills: Equipping agents for specialized work — 元記事が参照するスキルの記事
• Tool search tool — Claude Platform ドキュメント。ツールの遅延読み込み
• Task budgets — Claude Platform ドキュメント。ループの予算
• The new rules of context engineering for Claude 5 generation models — Claude Code のシステムプロンプト削減の出典として元記事が参照