BlogAIエージェントClaudeClaude CodeAnthropic

「サブエージェントを使うな」は誤読？ Anthropic記事の本意とエージェント間通信の使い分け

Anthropicの記事は「サブエージェント禁止」ではなく、組織図どおりに分けた多層構成を見直す提案です。残すべき3条件、単一ループ＋スキル・ツールへの移行手順、サブエージェント・Agent Teams・A2A・MCPの使い分けを整理します。

著者
岡崎 太
CTO / AIアーキテクト
公開日
読了時間
13分で読めます
Share

2026年10月22日、Anthropicが「Building agents: When to fold subagents into your main agent loop」という記事を公開しました。SNSでは「Anthropicがサブエージェントを使うなと言っている」という受け止めも見られます。

結論から言うと、この要約は言い過ぎです。記事が見直しを求めているのは、チームごとに専門のサブエージェントを作り、ルーターやプランナーでつなぐ多層構成です。サブエージェントそのものは、検証や並列作業に有効だと明記されています。記事全体の主張は「測ってから分けよ。組織図に合わせて分けるな」とまとめられます。

もう一つ、「エージェント同士は会話できる仕組みがあるのだから、分けても問題ないのでは」という疑問も出てきます。後半では、Claude Codeのサブエージェント・Agent Teams、A2A、MCPを比べて、会話できることと、分けるべきことは別の問題である理由を整理します。

本記事は2026年10月24日時点の公式資料に基づきます。原文の引用には出典を添え、筆者の見解は見解として書き分けます。

記事が言っていること：減らすと品質が上がる場合がある

記事の冒頭には、次の一文があります。

…using fewer subagents in favor of progressively disclosed context and tools can improve quality while reducing cost and latency.

サブエージェントを減らし、必要な情報とツールをその都度読み込ませる（段階的開示、progressive disclosure）方式に替えると、品質が上がり、コストとレイテンシも下がりうる、という主張です。

一方で、同じ記事はサブエージェントをエージェント設計の中核的な要素と位置づけ、次の用途に有効だと書いています。

They are effective at verification, parallel work, and modular permissioning.

検証、並列作業、権限の分離の3つです。記事は「subagents still have their place」とも書いており、サブエージェントを否定してはいません。

見直しの対象は「組織図をそのまま写した構成」

記事が問題にしているのは、大きな組織でよく起きる次のような状態です。

失敗パターン 記事の説明（要旨）
サブエージェントの乱立 チームごとに作るため、重複したサブエージェントが数百に増える
Frankenprompt 各チームがシステムプロンプトに一文ずつ足し、ルールが矛盾して一貫した声がなくなる
偏った評価 各チームが自分のサブタスクに最適化した評価を足し、全体を管理する人がいない
情報の欠落 エージェント間で受け渡すたびに、情報の正確さが落ちる

記事はこれを、エージェントの構成が組織図の写しになる「Conwayの法則」の表れだと指摘しています。

速度の差も示されています。マルチエージェント構成と単一のエージェントループを比べた顧客では、単一ループのほうがおよそ2倍速く動いたそうです（顧客名は記事に書かれていません）。

背景にはモデルの進化があります。記事は「Opus 4.5以降、モデルは多くのチームの想定よりはるかに多くのことを1つのループで扱えるようになった」と述べています。記事によれば、多層構成の多くは、モデルがもう自力でこなせる仕事を代わりに担っていました。さらに、固い構造そのものが、新しいモデルにより多くの仕事を任せる妨げになっていた、とも指摘しています。

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

記事は、次のいずれかに当てはまる場合にサブエージェントを使う、という基準を示しています（原文）。

  1. 単一のループで、コンテキストの肥大による性能低下が測定できるとき
  2. 複数の作業を並列で進めたく、終われば捨てられる新しいコンテキストが必要なとき
  3. 単一のエージェントが適切なツールを選べない、またはシステムプロンプト内に矛盾する指示があるとき

1つ目に「測定できる」とある点が重要です。「なんとなく長くなりそうだから分ける」は、記事の基準に当てはまりません。

代わりに勧めている構成：1つのループに、スキル・ツール・ナレッジベース

記事は、よくある多層構成の設計案について、「明確なシステムプロンプト1つ、薄いデータツール4〜5個、厳格な出力ガードレール」でユースケースの大半をまかなえる、という見立てを示しています。そのうえで、専門サブエージェントが持っていた中身を、次の3つに移すよう勧めています。

移し先 向いているもの（記事の基準）
ツール（MCPツールなど） 行動を起こす、システムのライブデータを読む
スキル そのチームが仕事をどう進めるか（手順・ルール・判断基準）
ナレッジベース ときどきしか必要にならない参照資料

ツールは、APIごとではなくユーザーの意図ごとにまとめます。記事によれば、システムプロンプト内のツール定義が30〜50個を超えると、ツール選択の精度が落ちやすくなります。また、エンティティ解決のように「安く、ほぼ常に必要な」処理は、引き続きコードで処理してかまわないとしています。

Anthropic自身の例として、より高度なモデル向けのClaude Codeのシステムプロンプトを80%以上削減したことも紹介されています。

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

分ける場合の切り方についても、記事ははっきりした基準を示しています。

When agents are split by problem type, they engage in a “telephone game,” passing information back and forth with each handoff degrading fidelity.

問題の種類で分けると（たとえば「請求担当」「配送担当」のように。例は筆者）、エージェント同士が情報をやり取りするたびに精度が落ちる「伝言ゲーム」になる、という指摘です。代わりに、他の部分からほとんど情報を必要としない作業を1つの単位として切り出し、短い結果を返させるよう勧めています。

呼び出し方については、移行の段階も示されています。第一歩は、既存のサブエージェントを書き直さずに、メインのエージェントがツールとして呼ぶ形に変えることです。そうすれば、ユーザーとの会話はメインが持ち続けられます。ただし記事は、この形でも呼び出しのたびに情報の欠けた要約が返ってくる、という課題が残ると指摘しています。そのため最終的には、サブエージェントの中身をスキルとツールへ畳み込んでいく流れです。サブエージェントに会話そのものを引き継ぐ「完全なハンドオフ」は、サブエージェントがユーザーと直接話す必要がある場合に限って勧めています。

移行は一度に1つ、評価で比べながら

記事の内容を筆者が整理すると、移行は次の流れになります。慎重で実務的な進め方です。

  1. エンドツーエンドの評価セットを作る。ゴールデンサンプル10件からでも始められる
  2. まずサブエージェントをツールとして呼ぶ形に変える。サブエージェント自体は書き直さずに済む
  3. 統合する順番を決める。互いの出力を受けて動く、同じデータに触る、よく一緒に呼ばれる専門エージェント同士から統合する
  4. 1つずつスキルとツールへ畳み込み、前後のスコアを比べる
  5. 平均点だけでなく、結果が変わったタスクを見る

5つ目には具体例があります。統合後、メインのエージェントが注文検索ツールを持ったまま自分で回答してしまい、配送担当に配送日を確認しなくなりました。この不具合は2回の実行のうち1回しか出なかったため、各タスクを複数回実行して確かめるよう勧めています。

記事は次の言葉で締めくくられます。

measure, change one thing at a time, and keep what holds up.

測る、一度に1つだけ変える、効果が続くものを残す。特定の構成よりも、この原則のほうが大事だというのが記事の結論です。

「エージェント同士は会話できる」とはどう関係するのか

ここからは、エージェント間の通信の仕組みを整理します。代表的なものは次の4つです。

仕組み 何をつなぐか 特徴
Claude Codeのサブエージェント 親エージェントと子エージェント 子は独立したコンテキストで作業し、結果の要約だけを親に返す。名前を付けたサブエージェント同士がメッセージを送り合うこともできる
Claude CodeのAgent Teams 同じチームの複数のClaude Codeセッション 共有タスクリストを使い、teammate同士が直接メッセージを送り合う。2026年10月時点では実験的機能
A2A（Agent2Agent） ベンダーやフレームワークが異なるエージェント Googleが2025年4月に発表し、同年6月にLinux Foundationへ移管されたエージェント間通信のオープン標準
MCP（Model Context Protocol） AIアプリケーションと外部のシステム・データ Anthropicが2024年11月に発表し、2025年12月にLinux Foundation傘下のAgentic AI Foundationへ寄贈したオープン標準

A2AとMCPは競合ではありません。A2Aの公式サイトは両者を「競合ではなく、強く補完し合う関係」と説明しています。MCPがエージェントとツール・データをつなぎ、A2Aがエージェント同士をつなぐ、という役割分担です。

会話できても、コンテキストは別々のまま

ここで押さえておきたいのは、どの仕組みを使ってもそれぞれのエージェントは別のコンテキストで動いているという点です。エージェント同士が会話できても、相手に渡るのは送った情報だけです。筆者の理解では、Anthropicの記事が言う「伝言ゲーム」は、通信手段がないから起きるのではありません。受け渡すたびに、情報が要約されたり欠けたりするから起きます。

コストの面でも同じです。Agent Teamsの公式ドキュメントは「単一のセッションより大幅に多くのトークンを使う」と明記し、定型的な作業には単一セッションのほうが費用対効果が高いとしています。

一方で、エージェント間の会話が力を発揮する場面もあります。筆者の見解では、次の2つです。

  • 独立して進められる並列作業：複数の観点で別々に調べ、最後に突き合わせる
  • あえて文脈を切り離したい作業：書き手の思い込みに引きずられない独立したレビューなど

どちらも、Anthropicの記事が挙げる「並列作業」「検証」と重なります。つまり、会話できるから細かく分けるのではなく、分けるべきだと測れたところだけ分け、その連携に通信の仕組みを使うという順番です。

判断のためのチェックリスト

最後に、記事の基準を自社の構成に当てはめるための問いを、筆者なりに整理しました。

  • そのサブエージェントは、チームの都合で作ったものか、コンテキストの都合で作ったものか
  • 統合した場合と比べた評価結果はあるか。なければ、まず10件の評価セットを作る
  • 互いの出力を受け渡すだけのサブエージェント同士はないか。あれば統合候補
  • そのサブエージェントの仕事は、今の作業の本体から独立し、結論だけを返せば済むか
  • ツール定義が30〜50個を超えていないか。意図ごとにまとめられないか
  • 残すサブエージェントは、会話を引き継がせずにツールとして呼べないか。さらに、スキルとツールへ畳み込めないか

フィールフロウでも、Claude Codeを使った社内の開発では、手順はスキルに、検証や制約はツールやフックに置き、サブエージェントは独立したレビューや並列の調査に絞って使っています。この記事の整理は、私たちが現場で感じてきた手応えとも重なります。

「サブエージェントを使うな」という強い言葉は拡散しやすい一方で、そのまま受け取ると、検証や並列作業という本来の強みまで捨ててしまいかねません。大切なのは、構成を流行で決めず、評価で決めることです。

改めてわかった、AI仕様駆動開発の大切さ

この記事を読んで、AI仕様駆動開発が大事だと改めてわかりました。

Anthropicが勧めているのは、エージェントの構成を変える前に評価セットを作り、何をもって「正しく終えた」とするかを決めることです。チームごとの進め方はスキルとして書き出し、守るべき制約はツールに持たせます。これは、仕事の目的、手順、制約、検証方法、完了条件を先に仕様として整え、AIと人が同じ仕様を参照しながら進めるAI仕様駆動開発の考え方と、そのまま重なります。

逆に言えば、仕様と完了条件が曖昧なままでは、サブエージェントを減らすべきか、残すべきかも判断できません。構成の良し悪しを測る物差しがないからです。エージェントの構成を見直す第一歩は、プロンプトや構成図を描き直すことではなく、仕事の仕様と評価の基準を書き出すことだと、筆者は考えています。

Issue駆動とスコープが、サブエージェントを使う場面を決める

AI仕様駆動開発で同じくらい大事にしているのが、Issue駆動とスコープです。仕事は必ずIssueから始め、1つのIssueに、何を作るか、受け入れ条件、守るべき制約を書いて、扱う範囲を絞ります。「認証機能を実装して」ではなく、「JWTトークンを検証するミドルウェアを実装する。受け入れ条件はこの3つ。既存のファイルを拡張する」と書く、という具合です。この書き方の違いでAIの動きが大きく変わった経験は、AI仕様駆動開発はなぜ生まれたのかで紹介しています。

スコープを考えると、サブエージェントを使うべき場面がはっきりしてきます。

  • スコープの中の仕事は、1つのループで進める。1つのIssueを仕上げるための手順・判断・検証は互いに深く関わっています。同じコンテキストに置いたほうが、それらを結びつけて考えられます。ここを担当ごとに分けると、Anthropicの記事が言う伝言ゲームになります。
  • スコープの本体から独立した仕事は、サブエージェントに切り出す。たとえば、出典や仕様の裏取り、実装した本人とは別の目で行うレビュー、複数の候補の並列調査です。どれも本体の作業からほとんど情報を必要とせず、結論だけを返せばよい仕事なので、記事の「コンテキストで分ける」基準に当てはまります。書き手の思い込みを持ち込まないという意味でも、別のコンテキストで行う価値があります。
  • スコープの外で見つけたことは、その場で直さない。作業中に気づいた別の課題は別のIssueとして記録し、今のコンテキストに持ち込みません。スコープを守ることは、コンテキストの肥大を防ぐことでもあります。
  • 受け入れ条件が、そのまま評価になる。Issueに書いた受け入れ条件は、「正しく終えたか」を測る物差しです。サブエージェントを統合する前と後を比べるときにも使えます。

実はこの記事も、同じやり方で作りました。本文の執筆は1つのループで進め、一次資料の裏取りと公開前の校正は、書き手の文脈を持たないサブエージェントに任せています。裏取りでは原文にない言い回しを使わないよう注意を受け、校正では筆者の解釈が記事の主張のように読める箇所を指摘されました。

サブエージェントを使うかどうかは、構成図を眺めて決めるものではありません。Issueのスコープを見て決めるものだと、筆者は考えています。

この考え方を体系的に知りたい方には、次の書籍がおすすめです。

  • 『AI仕様駆動開発 公式ガイド』（株式会社フィールフロウ）：AI仕様駆動開発の全体像、標準仕様、公式実装、導入手順、適合性評価を一冊にまとめた公式ガイドです。AIと人が同じ仕様を参照する開発プロセスを導入したいチームに向けた本です。
  • 『AIアーキテクト』（岡崎 太）：仕様化した仕事を、安全に動き続けるAIシステムへ変えるための設計の教科書です。安全性、監視、改善までを含めたアーキテクチャの考え方を体系化しています。エージェントの構成を設計・運用する立場の方に向けた本です。

方法論の全体像は、AI仕様駆動開発の紹介ページでもまとめています。

株式会社フィールフロウでは、生成AIエージェントの構成診断や評価セットの設計、段階的な移行の支援を行っています。既存のマルチエージェント構成を見直したい方は、お問い合わせからご相談ください。

関連記事

参考資料