以下の内容は、LangChainのブログ記事「How and when to build multi-agent systems」を日本語に翻訳し、マークダウン形式に変換したものです。
https://blog.langchain.com/how-and-when-to-build-multi-agent-systems/
興味深い内容でしたので、記録しておきます。
マルチエージェントシステムの構築方法とタイミング
先週末、一見すると正反対のタイトルのブログ記事が2つ発表されました。Cognitionチームによる「Don’t Build Multi-Agents」と、Anthropicチームによる「How we built our multi-agent research system」です。
タイトルこそ対照的ですが、実は両者には多くの共通点があり、マルチエージェントシステムをいつ・どのように構築すべきかについての示唆に富んでいます。
- コンテキストエンジニアリングが重要
- 主に「読む」マルチエージェントシステムは「書く」システムよりも簡単
コンテキストエンジニアリングが重要
マルチエージェント（または単一エージェント）アプリケーションの構築で最も難しい点の一つは、モデルに対して「何を求められているか」のコンテキストを効果的に伝えることです。Cognitionのブログ記事では、この課題を「コンテキストエンジニアリング」と呼んでいます。
2025年現在、モデルは非常に賢くなっていますが、どんなに優秀な人間でも、求められていることのコンテキストがなければ仕事をうまくこなせません。「プロンプトエンジニアリング」は、タスクをLLMチャットボットにとって理想的な形式で記述するための努力を指す言葉です。「コンテキストエンジニアリング」はその次の段階で、動的なシステム内でこれを自動的に行うことです。よりニュアンスが求められ、AIエージェントを構築するエンジニアにとって最重要の仕事となります。
いくつかの簡単な例を通じて、マルチエージェントシステムを使うと、各サブエージェントに適切なコンテキストを与えることがより難しくなることが示されています。
Anthropicのブログ記事では「コンテキストエンジニアリング」という用語は使われていませんが、同じ課題について何度も言及しています。Anthropicチームがコンテキストエンジニアリングに多大な時間を費やしていることは明らかです。以下に主なポイントをまとめます。
-
長い会話の管理
- 本番運用のエージェントは、しばしば数百回の会話を繰り広げます。標準的なコンテキストウィンドウでは十分ではなく、賢い圧縮やメモリ機構が必要です。
- 作業フェーズの完了ごとに要約し、重要な情報を外部メモリに保存してから次のタスクに進むパターンを実装しました。
- コンテキストの限界に近づいた場合、新しいサブエージェントを生成し、クリーンなコンテキストでスタートさせつつ、慎重な引き継ぎで連続性を保ちます。
- 保存されたコンテキスト（例：研究計画）をメモリから取り出せるため、作業内容を失うことはありません。
- この分散型アプローチにより、コンテキストオーバーフローを防ぎつつ、長い会話の一貫性を維持できます。
-
リードエージェントによるタスク分解
- リードエージェントがクエリをサブタスクに分解し、各サブエージェントに説明します。
- 各サブエージェントには目標、出力形式、使用するツールや情報源、明確なタスク境界が必要です。
- 詳細なタスク記述がないと、エージェントが重複作業をしたり、必要な情報を見つけられなかったりします。
コンテキストエンジニアリングは、エージェントシステムを確実に機能させるために不可欠です。この知見は、LangGraph（エージェントおよびマルチエージェントフレームワーク）の開発にも活かされています。フレームワークを使う際は、LLMに何が渡されるかを完全にコントロールし、どのステップをどの順序で実行するかも完全にコントロールする必要があります。LangGraphは隠れたプロンプトや強制される「認知アーキテクチャ」がない低レベルのオーケストレーションフレームワークであり、必要なコンテキストエンジニアリングを自由に行えます。
「読む」マルチエージェントシステムは「書く」システムよりも簡単
主に「読む」タスクを目的としたマルチエージェントシステムは、「書く」タスクを目的としたシステムよりも管理しやすい傾向があります。この違いは、Cognitionのコーディング中心のシステムとAnthropicの研究指向のアプローチを比較すると明確です。
コーディングも研究も「読む」「書く」の両方を含みますが、重視する側面が異なります。重要な知見は、「読む」行動は本質的に並列化しやすいということです。「書く」行動を並列化しようとすると、エージェント間でコンテキストを効果的に伝え、その出力を一貫性を持って統合するという二重の課題に直面します。Cognitionのブログ記事にもあるように、「行動には暗黙の決定が伴い、矛盾した決定は悪い結果を招きます」。これは「読む」「書く」両方に当てはまりますが、矛盾した「書く」行動は「読む」行動よりもはるかに悪い結果を招きます。複数のエージェントが同時にコードやコンテンツを書くと、矛盾した出力が生まれ、統合が困難になります。
AnthropicのClaude Researchはこの原則をよく示しています。システムには「読む」と「書く」の両方が含まれますが、マルチエージェントアーキテクチャは主に研究（読む）部分を担当します。実際の「書く」作業（調査結果をまとめてレポートにする）は、わざわざ複数エージェントで行わず、単一のメインエージェントが一括で処理します。この設計選択は、協調的な「書く」作業が不要な複雑さを招くことを認識しているからです。
ただし、「読む」中心のマルチエージェントシステムであっても、実装は簡単ではありません。高度なコンテキストエンジニアリングが必要です。Anthropicはこれを実体験しています。
当初は「半導体不足を調査せよ」のようなシンプルで短い指示をリードエージェントから与えていましたが、指示が曖昧すぎてサブエージェントがタスクを誤解したり、同じ検索を複数のエージェントが重複して行ったりしました。例えば、あるサブエージェントは2021年の自動車用チップ危機を調査し、他の2体は2025年のサプライチェーンを重複して調査するなど、効率的な役割分担ができませんでした。
本番運用の信頼性とエンジニアリングの課題
マルチエージェントシステムであれ、複雑な単一エージェントシステムであれ、信頼性やエンジニアリングの課題がいくつか発生します。Anthropicのブログ記事はこれらをよくまとめています。これらの課題はAnthropic特有ではなく、かなり一般的なものです。私たちが構築してきたツールの多くは、こうした課題を一般的に解決することを目的としています。
-
耐障害性とエラー処理
- エージェントはステートフルで、エラーが連鎖します。
- エージェントは長時間動作し、多くのツール呼び出しを跨いで状態を維持します。
- コードを耐障害的に実行し、途中でエラーが発生しても対応できる仕組みが必要です。
- 効果的な対策がないと、小さなシステム障害でもエージェントにとっては致命的です。
- エラー発生時に最初からやり直すのはコストが高く、ユーザーも不満です。
- エラー発生時の状態から再開できるシステムを構築しました。
- この耐障害的な実行はLangGraphにも組み込まれており、長時間動作するエージェントには必須と考えています。
-
エージェントのデバッグと可観測性
- エージェントは動的に決定し、同じプロンプトでも実行ごとに非決定的です。
- これによりデバッグが難しくなります。
- ユーザーから「明らかな情報を見つけられない」との報告があっても、原因が分かりません。
- エージェントが不適切な検索クエリを使ったのか、不適切な情報源を選んだのか、ツール障害が起きたのかを判断できません。
- 本番運用トレースを追加することで、エージェントの失敗原因を診断し、体系的に修正できるようになりました。
- LLMシステムの可観測性は従来のソフトウェアの可観測性とは異なり、こうした課題に対応できるように最適化する必要があります。
- LangSmith（エージェントのデバッグと可観測性のためのプラットフォーム）を2年間開発し、これらの課題に対応しています。
-
エージェントの評価
- Anthropicの記事には「エージェントの効果的な評価」に関するセクションもあります。
- 評価は小さく始める（20件程度のデータポイントでも十分）
- LLM-as-a-judge（LLMを評価者として使う）ことで実験の自動採点が可能
- 人間によるテストも依然として重要
- このアプローチはLangSmithにも反映されています。
- データセットを簡単に管理
- LLM-as-a-judgeをサーバーサイドで実行（今後さらに機能追加予定）
- アノテーションキューで人間評価の調整・促進
結論
Anthropicのブログ記事には、マルチエージェントシステムがどこでうまく機能し、どこで機能しないかについての知見も含まれています。
- 内部評価では、マルチエージェント研究システムは、複数の独立した方向性を同時に追求する必要がある幅広いクエリで特に優れています。
- マルチエージェントシステムが機能する主な理由は、問題解決に十分なトークンを使えるからです。
- マルチエージェントアーキテクチャは、単一エージェントの限界を超えるタスクに対してトークン使用量を効果的にスケールさせます。
- 経済的に成立させるには、タスクの価値が増加分のパフォーマンスに十分に見合う必要があります。
-
すべてのエージェントが同じコンテキストを共有する必要がある領域や、エージェント間の依存関係が多い領域は、現時点ではマルチエージェントシステムに適しません。
- 例えば、コーディングタスクは研究ほど並列化できるタスクが少なく、LLMエージェントは他のエージェントへのリアルタイムな協調や委任がまだ得意ではありません。
- マルチエージェントシステムは、重い並列化、単一コンテキストウィンドウを超える情報量、多数の複雑なツールとの連携が必要な高価値タスクで優れています。
エージェントの構築が進むにつれ、「万能の解決策は存在しない」ことが明らかになってきました。解決したい問題に応じて、いくつかの選択肢を検討し、最適なものを選ぶ必要があります。
選ぶエージェントフレームワークは、このスペクトルのどこにでも対応できるものであるべきです。LangGraphはこの点を特に重視しています。
マルチエージェント（または複雑な単一エージェント）システムを機能させるには、新しいツールも必要です。耐障害的な実行、デバッグ、可観測性、評価といったツールは、アプリケーション開発者の負担を軽減します。幸い、これらは汎用的なツールなので、LangGraphやLangSmithのようなオフ・ザ・シェルフのツールを使うことで、インフラよりもビジネスロジックに集中できます。