解説
複数AIエージェントより「1体」が速く安い理由 Anthropic解説
AIエージェントを業務に導入する際、「役割ごとに複数のエージェントを組み合わせる方が高性能」という思い込みは見直す時期に来ています。Anthropicは、ひとつの主エージェントが必要な情報だけを読み込む構成の方が、速度・コスト・品質の面で優れる場合が多いと公表しました。社内でAIエージェントの設計を検討している管理職にとって、構成の見直しは投資対効果に直結する論点です。
何が起きたか
Anthropicは、ひとつの主エージェントが必要に応じてコンテキストを読み込む「単一エージェント」構成が、複数の専門エージェントを組み合わせる「マルチエージェント」構成よりも、品質・コスト・応答速度で優れる場合が多いと公表しました。あわせて、自社のエージェント構成を見直す手順を示した移行キットをGitHub上で公開しています。
Opus 4.5以降の世代、およびOpus 5.5、Fable 5.1といった新しいモデルは、複雑な計画を単一のループ内で直接管理でき、コストや待ち時間を抑えられる場合があるといいます。ある比較では、単一エージェント構成がマルチエージェント構成の約2倍の速さで動作したと報告されています。
この見解は、複数の企業導入を手がけたAnthropicのApplied AIチームの知見に基づくものです。ある企業では、顧客対応用エージェントの内部に12個の専門サブエージェントが組み込まれ、一貫したブランド体験を保つのが難しく、応答の遅さがユーザビリティを損なっていたといいます。
背景・解説
マルチエージェント構成とは、意図検出、処理パイプライン、ユーザーの振り分け、推奨ロジックなど、役割ごとに特化したサブエージェントを複数組み合わせ、「オーケストレーター」が束ねる設計を指します。これに対して単一エージェント構成は、ひとつの主エージェントが必要なときだけスキルやツールの情報を読み込み、自分でタスクの計画・実行・検証までをこなす設計です。
これまでマルチエージェントが選ばれてきたのは、モデル単体では複雑な作業を一貫して管理する能力に限界があり、役割を分担させる必要があったためです。しかし新しいモデルは、従来オーケストレーターや人間の設計者が担っていた調整作業の多くを自力でこなせるようになっているといいます。Anthropicはこの状況を、エージェント設計の現場で起きがちな問題として「エージェント版のコンウェイの法則」と呼んでいます。チームごとに独自のサブエージェントを作り続けた結果、共通の基準がないまま数百もの重複したエージェントが積み上がり、各チームが追加したルールが互いに矛盾する「フランケンプロンプト」が生まれるという指摘です。
実例として、Anthropicは新しいモデル向けにClaude Codeのシステムプロンプトを80%以上削減したといいます。スキルやツールを必要なときだけ読み込む仕組みを取り入れたことが一因です。一方でサブエージェントがなお有効な場面も示されています。単一エージェントのコンテキストウィンドウで性能劣化が測定できる場合、複数タスクを別々のコンテキストウィンドウで並列実行する必要がある場合、単一エージェントがツールの選び方で行き詰まる場合です。あわせて、ツールの定義が30〜50個を超えると選択精度が落ちる傾向があるとも説明しています。
Anthropicはこの見解が独自調査にとどまらないとも述べています。Vals社の調査では、複数エージェントのチームは単一エージェントより速くなる場合はあるものの品質は向上せず、10体から30体、100体へと規模を拡大してもコストが増えるだけで品質向上は見られなかったといいます。OpenAIの開発者Eric Provencher氏も、多数のエージェントを群で動かす手法の価値に疑問を呈し、「ほぼ確実に」無駄な出費になると述べています。
仕事や業務への影響 — AI Topicaの見方
社内でAIエージェントを複数組み合わせて運用している会社ほど、まず構成の棚卸しをすべきです。例えば、従業員300人規模のSaaS企業で、問い合わせ対応用に10個前後の専門サブエージェントを運用している情シス担当者なら、各サブエージェント間で情報の受け渡しが発生するたびに文脈が失われていないか、応答の一貫性が崩れていないかを点検する価値があります。Anthropicが示した事例のように、12個のサブエージェントを抱えたことでブランド体験が崩れ、応答が遅くなるケースは十分に起こり得ます。
判断の目安は明確です。コンテキストウィンドウの性能劣化が確認できる、複数タスクを同時並行で処理する必要がある、ツールの数が30〜50個を超えて選択精度が落ちている、このいずれかに当てはまらない限り、サブエージェントを分ける理由は乏しくなります。統合によって速度が約2倍になった比較結果や、システムプロンプトを80%超削減できた例は、構成を見直す際の具体的な目標値として使えます。
ただし機械的な統合は危険です。サポート業務でサブエージェントを単一エージェントに統合した結果、待ち時間は短縮されたものの、専門担当に確認すべき処理を主エージェントが自己判断で処理してしまい、それまで機能していた業務フローが壊れた例が報告されています。構成変更は、業務ごとの正確さを検証しながら段階的に進めるべきです。エージェント基盤をゼロから開発する企業は少なく、既存のツールを使う企業が大半である以上、「エージェントを増やせば賢くなる」という発想自体を見直す必要があります。
不確かな点・注意
Anthropicが示した「約2倍速い」という結果は特定の比較に基づくもので、対象業務や評価条件の詳細は明らかにされていません。業種や用途によって効果の大きさは変わる可能性があります。
Anthropicは単一エージェントが「多くの場合」優れるとしており、すべてのケースで当てはまるとは述べていません。コンテキストウィンドウの劣化や並列処理の必要性など、サブエージェントが依然として有効な条件も併記されています。
Anthropic自身がClaudeシリーズを提供する立場であり、自社の推奨に沿った移行キットを公開している点は踏まえておく必要があります。Vals社の調査やOpenAI開発者の発言も引用されていますが、調査方法や発言の詳細な文脈は十分に示されていません。移行キットの対応言語や適用範囲も、現時点では明らかになっていません。