AIエージェントは「多いほど賢い」とは限らない：Anthropicが単一ループへの移行を推奨

Anthropicは2026年10月22日、企業が用途や部門ごとに構築してきた複数のAIエージェントを、単一のエージェントループへ段階的に統合するための技術ガイドを公開した。従来の構成では、異なる役割を持つサブエージェントがそれぞれ独立した会話履歴や指示を持ち、主担当のエージェントから作業を引き継ぐ。新たな指針では、こうした役割分担を必要に応じて見直し、一つのAIモデルが判断、ツールの実行、結果の確認、計画の修正を繰り返す構成を推奨している。

同社は、複数の企業導入事例で単一ループ構成が回答品質を改善し、コストや処理時間も削減できる場合が多かったと説明する。ある顧客の比較では、従来のマルチエージェント構成に比べて処理時間が約半分になったという。ただし、顧客名や詳細な比較条件は公表されておらず、すべてのシステムで同様の効果が得られることを示すものではない。今回のガイドは、こうした導入経験に基づく技術的な指針であり、査読を経た研究論文ではない。

サブエージェントを減らし、判断を単一ループに集約

従来のマルチエージェント構成では、主担当のエージェントが業務を振り分け、計画や検索、専門的な処理を別々のサブエージェントに任せる。しかし、各エージェントは独立した文脈で動作するため、作業を引き継ぐ際に情報が要約され、重要な細部が失われることがある。担当するエージェントが増えるほど、こうした情報の受け渡しが複雑になり、処理時間やコストも増加しやすい。

Anthropicが提案する単一ループでは、一つのモデルがユーザーの要求を理解し、必要なツールを呼び出して結果を確認しながら、次の処理を判断する。従来はルーターや計画担当、分野別のサブエージェントに分散していた判断を、同じ文脈に集約する仕組みだ。作業の途中で新しい情報が得られた場合も、その情報を踏まえて計画を修正できるため、エージェント間で説明を引き継ぐ必要が少なくなる。

ただし、すべての業務手順やツールの仕様を、最初からシステムプロンプトに詰め込むわけではない。Anthropicは、必要な情報を段階的に読み込む「Progressive Disclosure（段階的な情報開示）」を重視している。まずスキルやツールの短い説明をモデルに提示し、実際に必要になった段階で詳細な手順や定義を読み込む。スキルは特定の業務を進めるための手順や判断基準をまとめたもので、サブエージェントが保持していた専門的な指示の一部を置き換える役割を持つ。

この構成でも、複数の処理を並列に実行することは可能だ。互いに依存しないツール呼び出しは実行基盤が同時に処理し、その結果を同じモデルへ返す。モデルは得られた情報を共通の文脈で確認し、次の行動を決める。つまり、判断を担うエージェントを一つにまとめることと、処理を逐次実行することは別の話である。

Anthropicは、高性能モデルに合わせた設計変更の一環として、Claude Codeのシステムプロンプトを80%以上削減したことも明らかにしている。ただし、これはモデルへ最初に渡す指示文の削減率であり、総トークン消費量や利用料金が80%減ったという意味ではない。単一ループによってコストや処理時間を減らせる可能性はあるものの、その効果は業務内容や使用するモデル、ツールの構成によって異なる。

サブエージェントを残す基準は「部門」ではなく「文脈」

Anthropicは、すべてのサブエージェントを廃止すべきだとは主張していない。単一ループで扱う情報量が増えすぎて性能が低下する場合や、他の業務とは独立した作業を並列に進める場合には、サブエージェントを残す方が適している。また、単一のモデルでは適切なツールを選びにくい場合や、異なる業務の指示が衝突する場合も、役割を分離する理由になる。独立した検証や権限の分離が必要な業務でも、サブエージェントは有効な選択肢だ。

重要なのは、企業の組織図をそのままエージェント構成に反映しないことだ。Anthropicが9月2日に公開した商取引向けAIエージェントの設計ガイドでは、返品処理を例に、業務を分割する際の問題を説明している。返品の可否を判断するには注文履歴だけでなく、商品カタログやカートの内容を参照する必要がある。こうした情報を担当エージェントごとに分散させると、同じ顧客に関する情報を繰り返し取得したり、判断に必要な文脈が欠落したりする可能性がある。

一方、判断に必要な情報を集約しても、AIが実行できる権限まで一元化するわけではない。Anthropicの商取引向け設計では、AIが購入内容を準備しても、実際の発注はユーザーがボタンを押して確定する。AIが呼び出すAPIには直接課金できる操作を用意せず、支払いを実行する権限を分離している。販売事業者向けの価格変更なども、まずサーバーが発行したIDを持つ変更案として提示し、担当者の承認後に適用する。その際には、承認時点の条件に照らして制約を再確認する仕組みだ。

10月のガイドでも、この原則は維持されている。モデルの実行回数や費用の上限、書き込み操作の許可条件は、モデルを動かす実行基盤（ハーネス）が管理し、権限の確認や承認はツール側で強制する。スキルは業務の進め方をモデルに伝えるが、実行の可否を最終的に判断するのはコード側だ。判断に必要な情報は共有しながら、重要な操作の権限は実行基盤で制限するという役割分担が、単一ループの設計でも重要になる。

組織運営については、少人数の中央チームがシステムプロンプトと業務全体の品質評価を管理し、各部門が専門分野のスキルやツールを担当する体制を推奨している。また、システムプロンプトに含まれるツール定義が30〜50を超えると、モデルが適切なツールを選びにくくなる傾向にも言及した。これは厳密な上限ではなく、必要なツールを検索し、使用時に定義を読み込む設計を検討するための目安である。

処理時間の短縮だけでは不十分、業務の完了品質も評価

サブエージェントを統合すると、モデル間の受け渡しが減り、処理時間が短くなる可能性がある。しかし、Anthropicは、処理が速くなったことだけで設計の改善を判断すべきではないと指摘する。実際に同社が公開したサンプルでは、サブエージェントを統合した結果、配送担当への確認が省略され、従来は成功していた業務が失敗するケースが確認された。

具体的には、主担当のエージェントが注文情報を取得するツールを直接利用できるようになったことで、配送担当のサブエージェントに配送日を確認せず、自ら回答を生成してしまった。処理時間は短縮されたものの、必要な確認が抜け落ち、2回の試行のうち1回で失敗したという。これはマルチエージェント構成の方が常に優れていることを示すものではなく、統合によって既存の業務手順が失われる可能性を示した事例だ。

こうした問題を防ぐため、Anthropicは業務全体の完了条件を確認する評価テストの整備を勧めている。中央チームが一連の業務を対象とする共通の評価を管理し、各部門は担当するスキルやツールの評価を受け持つ。まず10件程度の正解例から評価を始め、サブエージェントを一つずつ統合しながら、変更前後の結果を比較する方法だ。ただし、10件は評価を始めるための目安であり、その件数だけで品質を十分に保証できるわけではない。

評価では平均スコアだけでなく、個々のタスクで結果がどう変化したかを確認する必要がある。統合前には成功していた業務が失敗するようになった場合、その原因がツールの選択なのか、情報不足なのか、必要な確認手順の省略なのかを調べなければならない。特に、複数の担当エージェントを順に利用していた業務については、一連の処理が統合後も正しく完了するかを試すことが重要だ。

Anthropicが公開した移行キットの初回検証でも、こうした評価範囲の不足が見つかっている。当初の評価には、返品を禁止する条件を確認するテストや、アカウント関連の業務から返品処理へ進む一連の経路を対象としたテストが含まれていなかった。後から評価項目が追加されたものの、初回の実行結果は追加された条件まで検証したものではない。個々の機能が正しく動作することと、複数の業務をまたぐ処理が最後まで完了することは、分けて評価する必要がある。

公式移行キットの実モデル検証は限定的

Anthropicは今回のガイドに合わせ、既存のマルチエージェント構成を単一ループへ移行するための参照実装「single-agent-loop-kit」をGitHubで公開した。公式READMEによると、キットは既存システムの評価から始め、密接に連携するサブエージェントの結合、スキルやツールへの置き換えを段階的に進める。各変更の前後で同じ評価を実行し、統合によって品質が維持されるかを確認する設計だ。

ただし、キットの全機能が実際のAIモデルを使って検証されたわけではない。公開記録によると、実モデルで試されたのは、1人の実行者が1種類のモデルを使用して行ったサンプルシステムの2回の実行に限られる。完成形の単一ループ全体や、ほかの企業システムへの適用まで実証されたものではない。

検証対象	公開記録で確認できる範囲	未検証・確認が必要な点
実モデルでの実行	1人・1モデルによるサンプルシステムの2回の実行	異なるモデルや実業務での再現性
10月8日の初回実行	claude-opus-5で12タスクを各構成2回ずつ評価	返品禁止条件、業務をまたぐ経路、追加タスクの成績
移行キット全体	一部の統合手順と、サブエージェントをツールとして呼び出す方式を実行	完成形のsingle_loop、結合・保守工程、評価テストがない状態からの移行
実行後のコード変更	オフラインテストで確認	変更後の構成を実モデルで動かした場合の品質

初回実行記録によると、2026年10月8日の試験では12タスクを各構成2回ずつ実行した。その後、業務をまたぐ処理や既存機能の破綻を検出するためのタスクが追加され、評価項目は19件に増えている。ただし、追加されたタスクは初回試験には含まれていない。また、スキルを使用する場合と使用しない場合の比較も完了しておらず、公開された結果だけでスキルへの置き換えが常に有利だとは判断できない。

公式READMEは、実モデルで検証されていない範囲として、完成形の単一ループ、サブエージェントの結合と保守の工程、評価テストを持たないシステムからの移行、サンプル以外のシステムへの適用などを明示している。実行後に安全対策や評価コードが改良された部分についても、確認はオフラインテストにとどまる。なお、この移行キットは保守や外部からの貢献を受け付けない参照実装として公開されており、実際の業務に採用する場合は導入企業自身が継続的な管理と検証を担う必要がある。

Anthropicの新たな指針は、AIエージェントの数を増やして機能を分担させる設計から、必要な文脈を共有しつつ、スキルとツールで専門性を補う設計への移行を提案するものだ。ただし、単一ループが常に最適というわけではなく、独立した処理や検証にはサブエージェントを残す選択肢もある。企業が移行を検討する際には、処理時間やコストの削減だけでなく、業務全体の完了率や必要な承認手順が維持されているかを確かめ、実測結果に基づいて構成を選ぶことが重要となる。