この記事は、Web、Google Workspace、各種連携を横断して検索する Anthropic の Research 機能についてのエンジニアリング報告であり、それをプロトタイプから本番へと移行させる過程で、システムアーキテクチャ、ツール設計、プロンプトエンジニアリングについてチームが何を学んだかを述べている。記述されているアーキテクチャはオーケストレーター–ワーカー型である。リードエージェントがユーザーのクエリを分析し、戦略を立て、異なる側面を並列に探索するサブエージェントを起動する。各サブエージェントは凝縮した調査結果を返し、リードエージェントがそれを統合する。
この形がなぜ有効なのかについての記事の論拠は、圧縮とトークン容量にある。検索は膨大なコーパスから洞察を抽出する営みと位置づけられ、サブエージェントはそれぞれ独自のコンテキストウィンドウで並列に作業したうえで、重要なものをリードエージェントのために凝縮することでそれを促進するものとして示されている。ツール、プロンプト、軌跡を分離することで経路依存性も減る。チームは、ある外部のブラウジングベンチマークで測定した性能のばらつきの大部分がトークン使用量だけで説明できると報告しており、これを、トークンあたりでより賢いアーキテクチャではなく、並列の推論容量を追加するアーキテクチャの妥当性を裏づけるものと読んでいる。
記事は、このアプローチが適用できない領域とそのコストについて異例なほど率直であり、その約半分は成果ではなく問題に充てられている。プロンプトによって取り除かねばならなかった協調の失敗、同じ経路を二度とたどらないシステムを評価することの難しさ、そして状態を持ち長時間稼働するエージェントが小さな誤りを積み重ねて障害に至らないようにするために必要な本番エンジニアリングである。
要点
- チームの報告によれば、Claude Opus 4 をリードエージェント、Claude Sonnet 4 をサブエージェントとするマルチエージェントシステムは、社内のリサーチ評価において単一エージェントの Claude Opus 4 を 90.2% 上回った。例として、S&P 500 の情報技術セクターの企業の取締役をすべて特定するという依頼が挙げられており、単一エージェントは遅い逐次的な検索を通じてこれに答えることができなかった。
- BrowseComp の評価では、3 つの要因が性能のばらつきの 95% を説明すると報告されている。トークン使用量だけで 80% を説明し、残る 2 つはツール呼び出しの回数とモデルの選択である。記事は、Claude Sonnet 4 へのアップグレードのほうが、Claude Sonnet 3.7 でトークン予算を倍にするよりも大きな向上だったと付け加えている。
- コストは率直に述べられている。エージェントは通常、チャットでのやり取りの約 4 倍のトークンを使い、マルチエージェントシステムは約 15 倍を使う。そのため、このアプローチにはそれを正当化できるだけの価値を持つタスクが必要となる。
- 記事は、現時点では適合しないと考える領域を挙げている。すべてのエージェントが同じコンテキストを共有する必要がある領域や、エージェント間に多くの依存関係がある領域、そして大半のコーディングタスクである。コーディングタスクは、リサーチと比べて真に並列化できるサブタスクが少なく、エージェントがリアルタイムで協調し委任することがまだ得意ではないとされる。
- このアーキテクチャは、クエリに最も類似したチャンクを取得する Retrieval Augmented Generation の静的な検索と対比され、調査結果が届くにつれてそれに適応する多段階の検索のほうが支持されている。
- リードエージェントは計画をメモリに保存する。200,000 トークンを超えるコンテキストウィンドウは切り詰められるからである。最後に、別の CitationAgent が文書と報告書の草稿を処理し、引用を置くべき箇所を特定する。
- 初期の協調の失敗が具体的に報告されている。単純なクエリに対して 50 のサブエージェントを起動する、存在しない情報源を延々と探し続ける、過剰な更新で互いの注意をそらす、といったものである。
- 曖昧な委任は特定の失敗として挙げられている。「半導体不足を調査せよ」という短い指示では、あるサブエージェントは 2021 年の自動車向け半導体危機を調べ、他の 2 つは 2025 年のサプライチェーンについて重複した作業を行った。各サブエージェントには、目的、出力形式、ツールと情報源に関するガイダンス、そして明確なタスクの境界が必要だとされる。
- エージェントは作業量の見積もりが苦手なため、作業量をスケールさせるルールがプロンプトに書き込まれた。単純な事実確認にはおよそ 1 つのエージェントで 3〜10 回のツール呼び出し、直接的な比較には 2〜4 のサブエージェントでそれぞれ 10〜15 回の呼び出し、複雑なリサーチには責任を分担した 10 を超えるサブエージェントである。
- 欠陥のある MCP ツールを繰り返し使い、その説明を書き直したツールテスト用エージェントによって、新しい説明を使う後続のエージェントのタスク完了時間が 40% 短縮されたと報告されている。
- 2 種類の並列化が導入された。リードエージェントがサブエージェントを逐次ではなく一度に 3〜5 つ起動することと、サブエージェントが 3 つ以上のツールを並列に使うことである。記事によれば、これにより複雑なクエリでのリサーチ時間が最大 90% 短縮された。
- 評価について、チームは小さなサンプルですぐに始めるべきだと主張しており、実際の利用パターンを代表する約 20 のクエリから始めたと報告している。その理由として、初期の変更は劇的な効果を持つ傾向があること（例として、プロンプトの微調整で成功率が 30% から 80% に上がることがある）、そしてその規模の効果であれば少数のテストケースで見えることが挙げられている。
- LLM による判定者は、事実の正確さ、引用の正確さ、網羅性、情報源の質、ツールの効率性というルーブリックに照らして出力を採点した。チームの報告では、1 つのプロンプトで 0.0〜1.0 のスコアと合否判定を出力する単一の LLM 呼び出しのほうが、別々の構成要素を評価する複数の判定者よりも一貫性があり、人間の判断ともよく一致した。
- 人間によるテストは、自動化が見逃したものを捉えたと報告されている。その中には、初期のエージェントが、学術論文の PDF や個人ブログのように権威はあるが検索順位の低い情報源よりも、SEO に最適化されたコンテンツファームを一貫して好むという傾向があった。これはプロンプトに情報源の質に関するヒューリスティクスを追加することで対処された。
- 記事はエージェントを、誤りが積み重なる状態を持つシステムとして描いており、そのため最初からやり直すことは現実的でない。そのアプローチは、障害が起きた時点からの再開、ツールが失敗していることをエージェントに伝えて適応させること、そしてリトライのロジックや定期的なチェックポイントといった決定論的な安全策を組み合わせたものである。
- 本番環境での完全なトレースによって非決定的な障害が診断可能になったとされている。記事は、チームがエージェントの意思決定のパターンとインタラクションの構造を監視しているが、個々の会話の内容は監視していないと述べている。
- エージェントはほぼ継続的に稼働しており、デプロイ時にはプロセスのどの段階にいてもおかしくないため、チームはレインボーデプロイメントを用いている。旧バージョンと新バージョンを両方動かしながら、トラフィックを段階的に移していく方式である。
- 現在の制約として名指しされているのは同期実行である。リードエージェントはサブエージェントの各セットを待つ。これは協調を単純にするが、リードエージェントはサブエージェントを舵取りできず、サブエージェント同士は協調できず、1 つの遅いサブエージェントがシステム全体をブロックすることを意味する。
- 付録では、さらに 3 つの実践が加えられている。状態を変更するエージェントをターンごとではなく最終状態で評価すること、完了したフェーズを外部メモリに要約することで長期にわたる会話を管理すること、そしてサブエージェントに出力をファイルシステムに書かせて軽量な参照だけを返させることで、コーディネーターを介した「伝言ゲーム」を避けることである。
背景
性能の数値はチーム自身のものであり、チーム自身の社内リサーチ評価で測定されたものである。記事はその評価の構成を説明していない。唯一引用されている外部ベンチマークである BrowseComp は、スコアを報告するためではなく、どの要因がばらつきを説明するかについての主張を裏づけるために使われている。トークンの倍率の数値（4 倍と 15 倍）は、方法を示さないまま、チームのデータからの観察として示されている。
記事が掲げるプロンプティングの哲学は、硬直したルールではなくヒューリスティクスを植え付けることであり、これは熟練した人間がどのようにリサーチを行うかの研究から導かれている。質問を分解すること、情報源の質を評価すること、新しい情報に応じてアプローチを調整すること、そして深さと幅のどちらを取るかを選ぶことである。記事はまた、自らの処方に留保をつける創発的な振る舞いについての主張もしている。リードエージェントへの小さな変更がサブエージェントの振る舞いを予測できない形で変えうるため、チームは最良のプロンプトを、指示としてではなく、分業、問題解決のアプローチ、作業量の予算を定める協働のためのフレームワークとして位置づけている。
締めくくりの捉え方、すなわちエージェントシステムでは「最後の 1 マイルがしばしば行程の大半になる」こと、そしてプロトタイプと本番の間の隔たりは予想以上に大きいということが、一般的な教訓として示されている。記事が従来のソフトウェアと対比して示すのは、従来のソフトウェアではバグは機能を壊したり性能を低下させたりするのに対し、エージェント型のシステムでは 1 つのステップの失敗がエージェントをまったく異なる軌跡へと送り出しうる、という点である。