メインコンテンツへスキップ
Dev Tools 20分で読める

サブエージェントは畳むべきか｜Anthropic公式指針とsingle-agent-loop-kitの使い方

#Claude#Anthropic#AIエージェント#サブエージェント#Agent Skills#マルチエージェント#評価#Claude API

120脚の椅子の見積もりで、価格担当のサブエージェントが「2,160 × 120 = 288,000」と書いた。正しくは259,200だ。3回目の実行では、取りまとめ役のエージェント（コーディネーター）がその数字をそのまま写し、顧客への見積もりは28,800デンマーククローネ高くなった。1回目では、同じコーディネーターが自分で計算し直して正しい金額を出していた。

これはKim Olsen氏がDEV Communityに投稿した比較実験の一場面だ（出典: AI sales agent test: four subagents vs one loop with skills、2026年10月23日、原文は英語、要約は筆者）。同じ条件で、スキルを読み込む単一エージェントは3回とも自分で掛け算をして正解していたと報告されている。

実験のきっかけは、前日の10月22日にAnthropicのApplied AIチームが公開した記事だ。複数のサブエージェントに仕事を振る構成と、1つのエージェントで完結させる単一エージェント構成のどちらがよいか、という問いを扱っている。タイトルは「Building agents: When to fold subagents into your main agent loop」。サブエージェントを本体のループに「畳み込む（fold）」べきなのはいつか、という指針である。移行用のキットも同時に公開された。

自分（電脳狐影）はエンジニアではなくPMだ。ただ、この記事の半分は技術というより組織の話だった。

この記事はこんな人におすすめ
  • Claude APIやAgent SDKで、ルーター＋専門サブエージェント構成のエージェントを作っている方
  • Claude Codeでサブエージェントを量産して、トークン消費や遅さが気になっている方
  • 「チームごとにエージェントを作る」計画を立てているPM・リード
結論（忙しい人向け）
  • 公式の主張: 複数の企業導入の比較で、スキル付きの単一エージェントが、1プロンプト型にもサブエージェント型にも品質で勝つことが多かった。コストと遅延も低い傾向
  • 残すべき3ケース: 単一ループの品質低下が測れる／並列で新しいコンテキストが欲しい／ツール選択や指示の矛盾で迷う
  • 移行の鉄則: 先に評価（正解付きの例で採点するテスト、10件程度から）を作り、サブエージェントを1つずつ畳んで比較する
  • 注意: 公式は具体的な数値をほとんど公開していない。キットはサポートなしの参照実装
  • 外部の実験では: 単一エージェントが費用・処理時間とも約半分（1件2.0セント対4.1セント）
  • 筆者の判断: 新規なら単一ループから始める。既存のマルチ構成は、評価を作るまで触らない
  • 上司への一言: 「新規は単一ループで作り、既存は評価を作ってから1つずつ畳む」

Anthropicの記事は何を言っているのか

著者はApplied AIチームのDiane Sarkis氏だ（出典: Building agents: When to fold subagents into your main agent loop、2026年10月22日）。主張は一文にまとまる。サブエージェントを減らし、情報とツールを必要になった時点で小出しに渡す設計（progressive disclosure）にすると、品質が上がり、コストと遅延が下がることがある、というものだ。

PMとして一番引っかかったのは、大企業のエージェント構成が「組織図のコピーになっている」という指摘だった。記事は大企業でよく起きる失敗を5つ挙げている。

失敗パターン中身
引き継ぎでの情報欠落エージェント間で渡す文脈を選ぶたびに、細部が落ちる
サブエージェントの乱立各チームが自分のサブエージェントを出し、重複したものが数百に増える
「Frankenprompt」各チームがシステムプロンプトにルールを足し、矛盾して声色がばらばらになる
局所的な評価各チームが自分の担当分だけを最適化し、経営は断片的なスコアで判断する
遅延入れ子のループが増えるたびに待ち時間が積み上がる

記事によれば、ある顧客はマルチエージェント構成と単一ループを比べ、単一ループで実行時間がおよそ2倍速くなった（顧客名や測定条件は非公開）。Claude Code自身も、新しいモデル向けのシステムプロンプトを80%以上削ったと記事は述べている。スキルとツールを必要なときに開示する方式に寄せた結果だという。

記事が勧める単一ループの形はシンプルだ。1つのモデルと1つのコンテキストでツールを呼び続ける。ターン数とコストの上限、書き込みの関所は、ハーネス（エージェントを動かす外側のプログラム）側で決める。

業務の手順書はスキル（エージェントが必要なときに読み込む手順書ファイル）に、守るべき制限や承認はツールに置く。ツール定義が30〜50個を超えると選択の精度が落ちやすいため、APIごとではなく「利用者の意図」単位でまとめるよう勧めている。

実際に比べた人たちの声

公式の主張には数字が少ない。だから外部の検証が重要になる。

冒頭のOlsen氏の実験は、架空の家具卸の見積もり窓口で、メール12通を各設計で3回ずつ処理した。4エージェント側は、コーディネーターと価格・納期・取引条件の専門サブエージェント3体の構成だ。モデルはどちらもClaude Sonnet 5.5（effortはmedium）。

指標単一エージェント4エージェント
完全正解の見積もり36/3629/36
見積もり1件あたりのモデル呼び出し2回8〜9回
トークン（中央値）6,23912,704
処理時間（中央値）7.3秒13.9秒
費用（1件あたり）約2.0セント約4.1セント

※ 数値はOlsen氏の記事より。費用はテスト実行にかかったAPI料金（米ドル、税・手数料を含まない第三者の実験値）。処理時間は本人も概算としている。

4エージェント側の失敗の中身を見ると、商品コードの抜けが7件あり、どれもコーディネーターがコードを聞かなかった回だった。Olsen氏は「検算は任意で、同じ入力の2回の実行でコーディネーターの判断が分かれた」と書いている（前掲記事、原文は英語、筆者訳）。

一方で、単一エージェントは毎回3つのスキルを全部読み込んでいた。つまり「必要なときだけ読む」節約は起きていない。勝因は共有コンテキストとまとめての照会だった、と本人が分析している。Olsen氏自身も、これは手法の見本であって「単一ループが常に勝つ証明ではない」と念を押している。

反対側の声もある。Qiitaで@nogataka氏は、単一エージェントで300〜400ターンを超えた頃から「検証を省き、存在しない関数名を書いて押し切ろうとする挙動が明確に出始め」たと書いている（出典: Claude Codeのサブエージェントを使い倒す、2026年4月13日）。同氏は計画・生成・評価を分ける構成に寄せて、長時間タスクが安定したという。本人も体感ベースだと断っているが、Anthropicの「残すべきケース」の1つ目、コンテキスト肥大による品質低下に当てはまる例だと自分は見ている。

Anthropicの記事自身も、失敗例を隠していない。あるサポート用エージェントでサブエージェントを1つ畳んだところ、遅延は減ったが、それまで通っていた処理が壊れた。本体のエージェントが、配送担当に届け日を確認せず、注文の質問に自分で答えてしまったのだ。

Devinを開発するCognitionのWalden Yan氏の整理も参考になる。2025年に「Don’t Build Multi-Agents」を書いた同氏は、2026年4月の続編で、うまくいくのは書き込み役を1つに絞り、他のエージェントは「行動ではなく知性を足す」構成だと述べた（出典: Multi-Agents: What’s Actually Working、2026年4月22日、原文は英語、筆者訳）。コンテキストを持たない状態から見るコードレビューは、その代表例だという。

「マルチエージェントが90%強い」と言っていたのでは？

ここで混乱する人もいるはずだ。Anthropicは2025年6月、Opus 4を指揮役、Sonnet 4をサブエージェントにした構成が、単体のOpus 4より社内のリサーチ評価で90.2%上回ったと発表していた（出典: How we built our multi-agent research system、2025年6月13日）。

矛盾ではない、と自分は読んだ。同じ記事は、マルチエージェントはチャットの約15倍のトークンを使うこと、全員が同じ文脈を共有する作業や依存関係の多い作業（例としてコーディング）には向かないことも書いていた。2026年1月の公式記事も、同じタスクでマルチエージェントは単一の3〜10倍のトークンを使うとし、分割は「文脈を本当に切り離せるとき」だけにせよと述べている（出典: When to use multi-agent systems (and when not to)、2026年1月23日）。

広く調べる・独立に検証する仕事は分ける。1つの文脈でつながった業務は畳む。今回の記事は、その線引きを企業の業務エージェント向けに言い直したものだと理解している。

移行キット single-agent-loop-kit の使い方

キットはGitHubのanthropics/single-agent-loop-kitにある。READMEによれば、手順は「測る→まとめる→畳む」の3段階だ。

  1. 測る: 評価を見つけるか作り、今の構成を採点する
  2. まとめる: いつも一緒に動くサブエージェントを統合する
  3. 畳む: 残りを1つずつスキル＋ツールに変え、前後で比較する。独立した文脈で動かす価値があるものは、ツールとして呼ぶ形で残す

導入はスキルをコピーし、Claude Codeから呼ぶだけだ。

git clone https://github.com/anthropics/single-agent-loop-kit
cp -r single-agent-loop-kit/skill <あなたのリポジトリ>/.claude/skills/single-agent-loop
# Claude Codeで「Run the single-agent-loop skill.」と依頼する

スキルは最初に監査を行い、サブエージェントごとに「畳む・統合・ツール化・残す」の判断を求めてくる。費用が発生する実行の前にはトークン見積もりを出して止まる。費用をかけずに流れを見たいなら、付属のサポートデスク例で偽モデルを使える。

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

キットは補助として /claude-api build-eval（評価づくり）、/claude-api prompt-audit（古いモデル向けの指示の洗い出し）、/claude-api hillclimb（評価に対する反復改善）、/claude-api cost-optimize（費用削減の提案）を使う。

キットを使う前の注意
  • READMEは「参照実装でメンテナンスされない」「issueやPRは見ていない」と明記している。フォーク前提だ
  • 付属例を実モデルで回したのは1人・2回で、統合（merge）や保守の手順は実モデルでは未検証とされている
  • 評価の実行はタスクごとにAPIを呼ぶ。READMEは10タスク×2〜3回から始めるよう勧めている

自分ならこうする

この記事の一番の価値はキットではなく「評価を先に作れ」という順番だと思う。Olsen氏の実験でも、同じ入力で結果が割れた。1回だけ回して「速くなった」と判断するのは危うい。

自分なら次のように動く。

  • 新しく作るエージェント: 最初から単一ループ＋スキルで作る。サブエージェントは、評価で困ったときに足す
  • 既存のマルチ構成: 評価を10件作るまで構成は触らない。作ったら、同じデータを触るサブエージェントから1つだけ畳む
  • 残すもの: 独立したリサーチと、まっさらな文脈で見るレビュー役は残す。ここはAnthropicもCognitionも「分ける価値がある」側に置いている
  • 組織面: システムプロンプトの持ち主を1チームに決める。PMとして一番効くのはここだ。Frankenpromptは技術ではなく、誰が承認するかの問題だからだ

わからない点もある。Anthropicは「品質で勝つことが多かった」と書くが、何社でどれだけ差が出たかは公開していない。自分の業務で再現するかは、自分の評価でしか確かめられない。

スキルの効果も数値で確かめる

畳んだサブエージェントはスキルになる。そのスキルが本当に効いているかを測る claude plugin eval の使い方を整理した。

スキルの評価方法を読む

関連記事

免責事項

  • 本記事の情報は2026年10月24日時点のものです。最新の内容はAnthropicの記事とキットのリポジトリを参照してください。
  • DEV Community、Qiita、Cognitionからの引用・数値は各著者の環境における報告で、筆者が再現検証したものではありません。英語の引用は筆者による翻訳・要約で、意訳を含みます。
  • 構成の変更は、ご自身の評価と環境で確認したうえで行ってください。本記事の情報に基づく変更で生じた損害について、筆者は責任を負いません。
  • 本記事はAnthropic社およびその関連会社と提携・提供関係にあるものではなく、内容は筆者独自の見解です。本記事にアフィリエイトリンクは含まれません。

※ 記載の会社名・製品名は各社の商標または登録商標です。

Share