How and when to build multi-agent systems｜マルチエージェントシステムをいつどのように構築するか | AIニュース最前線

![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbaab1649e3ebd9d13bb29_supervisor.png) 先週後半、一見すると対照的なタイトルを持つ 2 つの素晴らしいブログ記事が公開されました。Cognition チームによる「[マルチエージェントを構築するな](https://cognition.ai/blog/dont-build-multi-agents?ref=blog.langchain.com)」と、Anthropic チームによる「[どのようにして私たちのマルチエージェント研究システムを構築したか](https://www.anthropic.com/engineering/built-multi-agent-research-system?ref=blog.langchain.com)」です。 対照的なタイトルにもかかわらず、これらには実は多くの共通点があり、マルチエージェントシステムをいつ、どのように構築すべきかについての洞察が含まれていると私は考えます： - コンテキストエンジニアリングが極めて重要である - 主に「読む」ことに特化したマルチエージェントシステムは、「書く」ことに特化したものよりも構築しやすい ## コンテキストエンジニアリングの重要性 マルチエージェント（あるいは単一エージェント）アプリケーションを構築する際の最も難しい部分の一つは、モデルに対して、何を実行すべきかの文脈を効果的に伝達することです。Cognition のブログ記事では、この課題を説明するために「コンテキストエンジニアリング」という用語を紹介しています。 **2025 年現在、利用可能なモデルは極めて知的です。しかし、最も賢い人間であっても、自分が何をするよう求められているかという文脈がなければ、職務を効果的に遂行することはできません。「プロンプトエンジニアリング」という用語は、LLM チャットボットに対してタスクを理想的な形式で記述するために必要な努力を表すために作られました。一方、「コンテキストエンジニアリング」はその次の段階です。これは動的システムにおいてこれを自動的に行うことを意味します。より微妙なニュアンスが必要とされ、AI エージェントを構築するエンジニアにとって事実上最も重要な仕事となっています。 彼らはいくつかの玩具的な例を通じて、マルチエージェントシステムを使用すると、各サブエージェントが適切な文脈を持っていることを保証することが難しくなることを示しています。 Anthropic のブログ記事では明示的に「コンテキストエンジニアリング」という用語は使用されていませんが、複数の箇所で同じ課題に言及しています。Anthropic チームがコンテキストエンジニアリングに相当な時間を費やしたことは明らかです。以下にそのいくつかのポイントを挙げます： **長期の会話管理。** 本番環境のエージェントは、数百ターンにわたる会話を頻繁に行うため、慎重なコンテキスト管理戦略が必要です。会話が続くにつれて、標準的なコンテキストウィンドウでは不十分となり、知的な圧縮とメモリ機構が求められます。私たちは、エージェントが完了した作業フェーズを要約し、新しいタスクに進む前に重要な情報を外部メモリに保存するパターンを実装しました。コンテキスト制限に近づくと、エージェントはクリーンなコンテキストを持つ新たなサブエージェントを起動しつつ、慎重な引き継ぎを通じて継続性を維持します。さらに、研究計画などの保存されたコンテキストをメモリから検索することで、コンテキスト限界に達しても以前の作業を失うことなく対応できます。この分散型アプローチは、コンテキストのオーバーフローを防ぎつつ、拡張された相互作用全体で会話の一貫性を保ちます。 **当システムでは、リードエージェントがクエリをサブタスクに分解し、それらをサブエージェントに記述します。各サブエージェントには、目的、出力形式、使用するツールやソースに関するガイダンス、明確なタスクの境界が必要です。詳細なタスク説明がない場合、エージェントは作業の重複、ギャップの発生、または必要な情報の見落としを引き起こします。** コンテキストエンジニアリングは、エージェントシステムを信頼性高く動作させるために極めて重要です。この洞察が、私たちが開発した [LangGraph](https://github.com/langchain-ai/langgraph?ref=blog.langchain.com) というエージェントおよびマルチエージェントフレームワークの基盤となっています。フレームワークを利用する際には、LLM（大規模言語モデル）に渡される内容について完全な制御権を持ち、また、どのようなステップをどの順序で実行するかについても完全な制御権を持つ必要があります（これは LLM に渡されるコンテキストを生成するためです）。私たちはこれを LangGraph で優先しており、LangGraph は隠されたプロンプトも強制された「認知アーキテクチャ」もない低レベルのオーケストレーションフレームワークです。これにより、必要な適切なコンテキストエンジニアリングを完全に制御して行うことができます。 主に「読み取り」タスクに設計されたマルチエージェントシステムは、「書き込み」タスクに焦点を当てたものよりも管理しやすい傾向があります。この違いは、2 つのブログ記事を比較すると明確になります：コーディングに特化した Cognition のシステムと、研究指向のアプローチを持つ Anthropic です。 コーディングと研究の両方とも、読むことと書くことを伴いますが、強調される側面は異なります。重要な洞察は、読み取りアクションが書き込みアクションよりも本質的に並列化しやすいということです。書き込みを並列化しようとすると、エージェント間で文脈を効果的に伝達し、その出力を一貫性のある形で統合するという二重の課題に直面します。Cognition のブログ記事が指摘しているように、「アクションには暗黙的な意思決定が含まれており、矛盾する意思決定は悪い結果をもたらす」からです。これは読み取りと書き込みの両方に当てはまりますが、矛盾する書き込みアクションは、矛盾する読み取りアクションよりもはるかに深刻な結果を生み出す傾向があります。複数のエージェントが同時にコードやコンテンツを書き込む場合、その矛盾する意思決定は互換性の低い出力を生み出し、それを調整することが困難になります。 Anthropic の Claude Research はこの原則をよく示しています。同システムには読み取りと書き込みの両方が含まれますが、マルチエージェントアーキテクチャは主に研究（読み取り）コンポーネントを処理します。実際の書き込み—つまり発見事項を一貫したレポートに統合すること—は、意図的に単一のメインエージェントによって一つの統一された呼び出しで処理されます。この設計上の選択は、共同での書き込みが不必要な複雑さを導入することを認識しています。 しかし、読み取り中心のマルチエージェントシステムであっても、実装が容易というわけではありません。依然として高度な文脈エンジニアリングが必要です。Anthropic はこれを身をもって発見しました： まず、リードエージェントに「半導体不足を調査する」のような単純で短い指示を与えるようにしましたが、これらの指示は曖昧すぎて、サブエージェントがタスクを誤解したり、他のエージェントと同じ検索を重複して実行したりすることが多いことが分かりました。例えば、ある 1 つのサブエージェントが 2021 年の自動車用チップ危機を探求している一方で、他の 2 つのサブエージェントは現在の 2025 年のサプライチェーン調査という同じ作業を重複して行っており、効果的な役割分担が行われていませんでした。 ## 生産性の信頼性とエンジニアリング上の課題 マルチエージェントシステムを使用する場合も、複雑な単一エージェントシステムを使用する場合でも、いくつかの信頼性およびエンジニアリング上の課題が生じます。Anthropic のブログ記事はこれらの点を非常にうまく指摘しています。これらの課題は Anthropic のユースケースに固有のものではなく、実際にはかなり一般的なものです。私たちが構築してきたツールの多くは、このような問題を汎用的に解決することを目的としています。 ## 永続的な実行とエラーハンドリング **エージェントは状態を持ち、エラーが蓄積します。** エージェントは長時間実行され、多くのツール呼び出しを介して状態を維持します。これは、コードを永続的に実行し、その過程でエラーを処理する必要があることを意味します。効果的な緩和策がない場合、システムにおける軽微な障害でもエージェントにとっては壊滅的になり得ます。エラーが発生した場合、最初から再起動することはできません：再起動はコストが高く、ユーザーにとってストレスになります。代わりに、エラー発生時にエージェントがいた場所から再開できるシステムを構築しました。 この永続的な実行は、エージェントオーケストレーションフレームワークである [LangGraph](https://github.com/langchain-ai/langgraph?ref=blog.langchain.com) の重要な一部です。私たちは、すべての長時間稼働するエージェントがこの機能を必要とすると考えており、したがってこれはエージェントオーケストレーションフレームワークに組み込まれるべきだと考えています。 **エージェントのデバッグと観測性** **エージェントは動的な意思決定を行い、同じプロンプトを使用した場合でも実行ごとに非決定的になります。これがデバッグを困難にします。例えば、ユーザーはエージェントが「明白な情報を見つけられない」と報告しますが、なぜそうなるのか私たちにはわかりませんでした。エージェントが悪質な検索クエリを使用していたのでしょうか？不適切なソースを選択していたのでしょうか？ツールの失敗に遭遇していたのでしょうか？完全なプロダクショントレーシングを追加したことで、エージェントが失敗した理由を診断し、体系的に問題を修正できるようになりました。 私たちは長年、LLM システムの観測性は従来のソフトウェアの観測性とは異なることを認識してきました。その主な理由は、これらの種類の課題をデバッグするために最適化される必要があるからです。これが具体的に何を意味するか確信が持てない場合は、エージェントのデバッグや観測性のためのプラットフォームである [LangSmith](https://smith.langchain.com/?ref=blog.langchain.com) をご覧ください。私たちは過去 2 年間、これらの種類の課題に対応するために LangSmith の構築を行ってきました。ぜひお試しください。なぜこれがそれほど重要なのかをご確認ください！ **エージェントの評価** Anthropic の投稿には、「効果的なエージェント評価」に dedicated されたセクションがあります。私たちが気に入っているいくつかの重要なポイント： - 評価（evals）は小さく始める。データポイントが約20個程度でも十分です - LLM-as-a-judge を用いれば、実験の採点を自動化できます - ただし、人間によるテストも依然として不可欠です これは、我々の評価に対するアプローチと心から共鳴するものです。LangSmith にはすでに評価機能を組み込んでおり、これらの側面を支援するためのいくつかの機能に落ち着いています： - データセット：データポイントを容易にキュレーションするため - サーバーサイドでの LLM-as-a-judge の実行（まもなくさらに多くの機能が追加されます！） - アノテーションキュー：人間による評価を調整し、促進するため ## 結論 Anthropic のブログ記事には、マルチエージェントシステムがどこで最もよく機能するか、あるいはそうでないかに関するいくつかの知恵も含まれています： 我々の内部評価では、マルチエージェント研究システムは、複数の独立した方向を同時に追求する幅優先（breadth-first）クエリにおいて特に優れていることが示されました。 マルチエージェントシステムが主に機能するのは、問題解決に十分なトークンを費やすことができるからです。マルチエージェントアーキテクチャは、単一エージェントの限界を超えるタスクに対してトークン使用量を効果的にスケールさせます。 経済的な実現可能性のためには、マルチエージェントシステムは、そのタスクの価値が高すぎてパフォーマンス向上のコストを支払えるようなタスクを必要とします。 さらに、すべてのエージェントが同じコンテキストを共有する必要があったり、エージェント間の依存関係が多かったりするドメインは、現状ではマルチエージェントシステムには適していません。例えば、コーディングタスクの多くは研究に比べて真に並列化可能なタスクが少なく、LLM エージェントはまだリアルタイムで他のエージェントとの調整や委任が得意ではありません。私たちは、マルチエージェントシステムが、高度な並列処理を要する価値あるタスクや、単一のコンテキストウィンドウを超える情報量の多いタスク、多数の複雑なツールとのインターフェースが必要なタスクにおいて卓越していることを発見しました。 エージェントを構築する過程で急速に明らかになっているように、「万能な解決策」は存在しません。むしろ、いくつかの選択肢を検討し、解決しようとしている問題に応じて最適な選択を行う必要があります。 あなたが選ぶどのエージェントフレームワークも、このスペクトラム上のどこでも柔軟に動作できるものであるべきです。これは LangGraph で独自に強調している点でもあります。 マルチエージェント（または複雑な単一エージェント）システムを機能させる方法を考えるには、新しいツールも必要となります。永続的な実行、デバッグ、観測性、評価はすべて、アプリケーション開発者の生活をより楽にするための新たなツールです。幸いなことに、これらはすべて汎用的なツールです。つまり、LangGraph や LangSmith などのツールを使用して、これらの機能をすぐに利用可能にでき、インフラストラクチャの構築よりもアプリケーションのビジネスロジックに集中できるようになります。 ## Related content ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a20e9ecceb33c3aa6859462_neutrality.png) エージェントアーキテクチャ ## クラウドの中立性よりもモデルの中立性が重要である理由 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a20ea98c4a790a40caac819_Screenshot%202026-06-03%20at%208.01.36%E2%80%AFPM.png) ニール・ダルケ 2026 年 6 月 4 日 7 分 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a21b18252c6946e4744edfb_92%20(1).png) オープンソース エージェントアーキテクチャ LangGraph ## LangGraph におけるフォールトトレランス：リトライ、タイムアウト、エラーハンドラ ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a21b46ce3c7b10f36e622cc_image%20(19).png) ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69dcee60745f0e15b18ad4d5_sydney-runkle.png) Q. ロング、 S. ランクル 2026 年 6 月 4 日 7 分 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a2035adfcf624bfe1b4fd22_94%20(1).png) オープンソース LangChain エージェントアーキテクチャ ディープエージェント ## カスタムエージェントハッチの構築方法 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69dcee60745f0e15b18ad4d5_sydney-runkle.png) シドニー・ランクル 2026 年 6 月 3 日 6 分 ## エージェントが実際に何をしているかを確認する LangSmith は、エージェントエンジニアリングプラットフォームであり、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるように支援します。

マルチエージェントシステムをいつどのように構築するか

背景や根拠まで確認しますか？

調べる

選ぶ

サイト