マルチエージェントシステムをいつどのように構築するか
LangChain Blog は、単一エージェントの限界を超え、複数の AI エージェントが協調して複雑なタスクを解決するマルチエージェントシステムの設計手法と、実装すべき具体的なタイミングについて詳述している。
キーポイント
設計手法とアーキテクチャ
単一の LLM では処理しきれない複雑なタスクに対し、役割分担された複数のエージェントを協調させるためのシステム設計パターンを解説している。
実装タイミングの判断基準
マルチエージェントシステムの導入が有益となるのは、タスクが単一のプロンプトやワークフローでは解決不可能な場合に限られるという判断基準を示している。
複雑性とコストのトレードオフ
システム構築による柔軟性の向上と、その分生じる管理コストやレイテンシ増大のバランスを考慮する必要性について言及している。
影響分析・編集コメントを表示
影響分析
本記事は、AI エージェント開発における「マルチ化」が単なるトレンドではなく、特定の複雑性を持つタスクに対する構造的な解決策であることを明確に定義した点で重要です。開発者に対し、システム設計の初期段階からエージェント間の協調を考慮するよう促し、実装の失敗リスクを低減させる指針を提供しています。
編集コメント
「いつ作るか」という判断基準に焦点を当てた実践的な記事であり、過剰設計を防ぐ上で非常に有益です。
先週後半、一見すると対照的なタイトルを持つ 2 つの素晴らしいブログ記事が公開されました。Cognition チームによる「マルチエージェントを構築するな」と、Anthropic チームによる「どのようにして私たちのマルチエージェント研究システムを構築したか」です。
対照的なタイトルにもかかわらず、これらには実は多くの共通点があり、マルチエージェントシステムをいつ、どのように構築すべきかについての洞察が含まれていると私は考えます：
- コンテキストエンジニアリングが極めて重要である
- 主に「読む」ことに特化したマルチエージェントシステムは、「書く」ことに特化したものよりも構築しやすい
コンテキストエンジニアリングの重要性
マルチエージェント（あるいは単一エージェント）アプリケーションを構築する際の最も難しい部分の一つは、モデルに対して、何を実行すべきかの文脈を効果的に伝達することです。Cognition のブログ記事では、この課題を説明するために「コンテキストエンジニアリング」という用語を紹介しています。
**2025 年現在、利用可能なモデルは極めて知的です。しかし、最も賢い人間であっても、自分が何をするよう求められているかという文脈がなければ、職務を効果的に遂行することはできません。「プロンプトエンジニアリング」という用語は、LLM チャットボットに対してタスクを理想的な形式で記述するために必要な努力を表すために作られました。一方、「コンテキストエンジニアリング」はその次の段階です。これは動的システムにおいてこれを自動的に行うことを意味します。より微妙なニュアンスが必要とされ、AI エージェントを構築するエンジニアにとって事実上最も重要な仕事となっています。
彼らはいくつかの玩具的な例を通じて、マルチエージェントシステムを使用すると、各サブエージェントが適切な文脈を持っていることを保証することが難しくなることを示しています。
Anthropic のブログ記事では明示的に「コンテキストエンジニアリング」という用語は使用されていませんが、複数の箇所で同じ課題に言及しています。Anthropic チームがコンテキストエンジニアリングに相当な時間を費やしたことは明らかです。以下にそのいくつかのポイントを挙げます：
長期の会話管理。 本番環境のエージェントは、数百ターンにわたる会話を頻繁に行うため、慎重なコンテキスト管理戦略が必要です。会話が続くにつれて、標準的なコンテキストウィンドウでは不十分となり、知的な圧縮とメモリ機構が求められます。私たちは、エージェントが完了した作業フェーズを要約し、新しいタスクに進む前に重要な情報を外部メモリに保存するパターンを実装しました。コンテキスト制限に近づくと、エージェントはクリーンなコンテキストを持つ新たなサブエージェントを起動しつつ、慎重な引き継ぎを通じて継続性を維持します。さらに、研究計画などの保存されたコンテキストをメモリから検索することで、コンテキスト限界に達しても以前の作業を失うことなく対応できます。この分散型アプローチは、コンテキストのオーバーフローを防ぎつつ、拡張された相互作用全体で会話の一貫性を保ちます。
当システムでは、リードエージェントがクエリをサブタスクに分解し、それらをサブエージェントに記述します。各サブエージェントには、目的、出力形式、使用するツールやソースに関するガイダンス、明確なタスクの境界が必要です。詳細なタスク説明がない場合、エージェントは作業の重複、ギャップの発生、または必要な情報の見落としを引き起こします。
コンテキストエンジニアリングは、エージェントシステムを信頼性高く動作させるために極めて重要です。この洞察が、私たちが開発した LangGraph というエージェントおよびマルチエージェントフレームワークの基盤となっています。フレームワークを利用する際には、LLM（大規模言語モデル）に渡される内容について完全な制御権を持ち、また、どのようなステップをどの順序で実行するかについても完全な制御権を持つ必要があります（これは LLM に渡されるコンテキストを生成するためです）。私たちはこれを LangGraph で優先しており、LangGraph は隠されたプロンプトも強制された「認知アーキテクチャ」もない低レベルのオーケストレーションフレームワークです。これにより、必要な適切なコンテキストエンジニアリングを完全に制御して行うことができます。
主に「読み取り」タスクに設計されたマルチエージェントシステムは、「書き込み」タスクに焦点を当てたものよりも管理しやすい傾向があります。この違いは、2 つのブログ記事を比較すると明確になります：コーディングに特化した Cognition のシステムと、研究指向のアプローチを持つ Anthropic です。
コーディングと研究の両方とも、読むことと書くことを伴いますが、強調される側面は異なります。重要な洞察は、読み取りアクションが書き込みアクションよりも本質的に並列化しやすいということです。書き込みを並列化しようとすると、エージェント間で文脈を効果的に伝達し、その出力を一貫性のある形で統合するという二重の課題に直面します。Cognition のブログ記事が指摘しているように、「アクションには暗黙的な意思決定が含まれており、矛盾する意思決定は悪い結果をもたらす」からです。これは読み取りと書き込みの両方に当てはまりますが、矛盾する書き込みアクションは、矛盾する読み取りアクションよりもはるかに深刻な結果を生み出す傾向があります。複数のエージェントが同時にコードやコンテンツを書き込む場合、その矛盾する意思決定は互換性の低い出力を生み出し、それを調整することが困難になります。
Anthropic の Claude Research はこの原則をよく示しています。同システムには読み取りと書き込みの両方が含まれますが、マルチエージェントアーキテクチャは主に研究（読み取り）コンポーネントを処理します。実際の書き込み—つまり発見事項を一貫したレポートに統合すること—は、意図的に単一のメインエージェントによって一つの統一された呼び出しで処理されます。この設計上の選択は、共同での書き込みが不必要な複雑さを導入することを認識しています。
しかし、読み取り中心のマルチエージェントシステムであっても、実装が容易というわけではありません。依然として高度な文脈エンジニアリングが必要です。Anthropic はこれを身をもって発見しました：
まず、リードエージェントに「半導体不足を調査する」のような単純で短い指示を与えるようにしましたが、これらの指示は曖昧すぎて、サブエージェントがタスクを誤解したり、他のエージェントと同じ検索を重複して実行したりすることが多いことが分かりました。例えば、ある 1 つのサブエージェントが 2021 年の自動車用チップ危機を探求している一方で、他の 2 つのサブエージェントは現在の 2025 年のサプライチェーン調査という同じ作業を重複して行っており、効果的な役割分担が行われていませんでした。
生産性の信頼性とエンジニアリング上の課題
マルチエージェントシステムを使用する場合も、複雑な単一エージェントシステムを使用する場合でも、いくつかの信頼性およびエンジニアリング上の課題が生じます。Anthropic のブログ記事はこれらの点を非常にうまく指摘しています。これらの課題は Anthropic のユースケースに固有のものではなく、実際にはかなり一般的なものです。私たちが構築してきたツールの多くは、このような問題を汎用的に解決することを目的としています。
永続的な実行とエラーハンドリング**
エージェントは状態を持ち、エラーが蓄積します。 エージェントは長時間実行され、多くのツール呼び出しを介して状態を維持します。これは、コードを永続的に実行し、その過程でエラーを処理する必要があることを意味します。効果的な緩和策がない場合、システムにおける軽微な障害でもエージェントにとっては壊滅的になり得ます。エラーが発生した場合、最初から再起動することはできません：再起動はコストが高く、ユーザーにとってストレスになります。代わりに、エラー発生時にエージェントがいた場所から再開できるシステムを構築しました。
この永続的な実行は、エージェントオーケストレーションフレームワークである LangGraph の重要な一部です。私たちは、すべての長時間稼働するエージェントがこの機能を必要とすると考えており、したがってこれはエージェントオーケストレーションフレームワークに組み込まれるべきだと考えています。
エージェントのデバッグと観測性
**エージェントは動的な意思決定を行い、同じプロンプトを使用した場合でも実行ごとに非決定的になります。これがデバッグを困難にします。例えば、ユーザーはエージェントが「明白な情報を見つけられない」と報告しますが、なぜそうなるのか私たちにはわかりませんでした。エージェントが悪質な検索クエリを使用していたのでしょうか？不適切なソースを選択していたのでしょうか？ツールの失敗に遭遇していたのでしょうか？完全なプロダクショントレーシングを追加したことで、エージェントが失敗した理由を診断し、体系的に問題を修正できるようになりました。
私たちは長年、LLM システムの観測性は従来のソフトウェアの観測性とは異なることを認識してきました。その主な理由は、これらの種類の課題をデバッグするために最適化される必要があるからです。これが具体的に何を意味するか確信が持てない場合は、エージェントのデバッグや観測性のためのプラットフォームである LangSmith をご覧ください。私たちは過去 2 年間、これらの種類の課題に対応するために LangSmith の構築を行ってきました。ぜひお試しください。なぜこれがそれほど重要なのかをご確認ください！
エージェントの評価
Anthropic の投稿には、「効果的なエージェント評価」に dedicated されたセクションがあります。私たちが気に入っているいくつかの重要なポイント：
- 評価（evals）は小さく始める。データポイントが約20個程度でも十分です
- LLM-as-a-judge を用いれば、実験の採点を自動化できます
- ただし、人間によるテストも依然として不可欠です
これは、我々の評価に対するアプローチと心から共鳴するものです。LangSmith にはすでに評価機能を組み込んでおり、これらの側面を支援するためのいくつかの機能に落ち着いています：
- データセット：データポイントを容易にキュレーションするため
- サーバーサイドでの LLM-as-a-judge の実行（まもなくさらに多くの機能が追加されます！）
- アノテーションキュー：人間による評価を調整し、促進するため
結論
Anthropic のブログ記事には、マルチエージェントシステムがどこで最もよく機能するか、あるいはそうでないかに関するいくつかの知恵も含まれています：
我々の内部評価では、マルチエージェント研究システムは、複数の独立した方向を同時に追求する幅優先（breadth-first）クエリにおいて特に優れていることが示されました。
マルチエージェントシステムが主に機能するのは、問題解決に十分なトークンを費やすことができるからです。マルチエージェントアーキテクチャは、単一エージェントの限界を超えるタスクに対してトークン使用量を効果的にスケールさせます。
経済的な実現可能性のためには、マルチエージェントシステムは、そのタスクの価値が高すぎてパフォーマンス向上のコストを支払えるようなタスクを必要とします。
さらに、すべてのエージェントが同じコンテキストを共有する必要があったり、エージェント間の依存関係が多かったりするドメインは、現状ではマルチエージェントシステムには適していません。例えば、コーディングタスクの多くは研究に比べて真に並列化可能なタスクが少なく、LLM エージェントはまだリアルタイムで他のエージェントとの調整や委任が得意ではありません。私たちは、マルチエージェントシステムが、高度な並列処理を要する価値あるタスクや、単一のコンテキストウィンドウを超える情報量の多いタスク、多数の複雑なツールとのインターフェースが必要なタスクにおいて卓越していることを発見しました。
エージェントを構築する過程で急速に明らかになっているように、「万能な解決策」は存在しません。むしろ、いくつかの選択肢を検討し、解決しようとしている問題に応じて最適な選択を行う必要があります。
あなたが選ぶどのエージェントフレームワークも、このスペクトラム上のどこでも柔軟に動作できるものであるべきです。これは LangGraph で独自に強調している点でもあります。
マルチエージェント（または複雑な単一エージェント）システムを機能させる方法を考えるには、新しいツールも必要となります。永続的な実行、デバッグ、観測性、評価はすべて、アプリケーション開発者の生活をより楽にするための新たなツールです。幸いなことに、これらはすべて汎用的なツールです。つまり、LangGraph や LangSmith などのツールを使用して、これらの機能をすぐに利用可能にでき、インフラストラクチャの構築よりもアプリケーションのビジネスロジックに集中できるようになります。
Related content
エージェントアーキテクチャ
クラウドの中立性よりもモデルの中立性が重要である理由
ニール・ダルケ
2026 年 6 月 4 日
7 分
オープンソース
エージェントアーキテクチャ
LangGraph
LangGraph におけるフォールトトレランス：リトライ、タイムアウト、エラーハンドラ
Q. ロング、
S. ランクル
2026 年 6 月 4 日
7 分
オープンソース
LangChain
エージェントアーキテクチャ
ディープエージェント
カスタムエージェントハッチの構築方法
シドニー・ランクル
2026 年 6 月 3 日
6 分
エージェントが実際に何をしているかを確認する
LangSmith は、エージェントエンジニアリングプラットフォームであり、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるように支援します。
原文を表示
Late last week two great blog posts were released with seemingly opposite titles. “Don’t Build Multi-Agents” by the Cognition team, and “How we built our multi-agent research system” by the Anthropic team.
Despite their opposing titles, I would argue they actually have a lot in common and contain some insights as to how and when to build multi-agent systems:
- Context engineering is crucial
- Multi-agent systems that primarily “read” are easier than those that “write”
Context engineering is critical
One of the hardest parts of building multi-agent (or even single-agent) applications is effectively communicating to the models the context of what they’re being asked to do. The Cognition blog post introduces the term “context engineering” to describe this challenge.
In 2025, the models out there are extremely intelligent. But even the smartest human won’t be able to do their job effectively without the context of what they’re being asked to do. “Prompt engineering” was coined as a term for the effort needing to write your task in the ideal format for a LLM chatbot. “Context engineering” is the next level of this. It is about doing this automatically in a dynamic system. It takes more nuance and is effectively the #1 job of engineers building AI agents.
They show through a few toy examples that using multi-agent systems makes it harder to ensure that each sub-agent has the appropriate context.
The Anthropic blog post doesn’t explicitly use the term context engineering, but at multiple points it addresses the same issue. It’s clear that the Anthropic team spent a significant amount of time on context engineering. Some highlights below:
Long-horizon conversation management. Production agents often engage in conversations spanning hundreds of turns, requiring careful context management strategies. As conversations extend, standard context windows become insufficient, necessitating intelligent compression and memory mechanisms. We implemented patterns where agents summarize completed work phases and store essential information in external memory before proceeding to new tasks. When context limits approach, agents can spawn fresh subagents with clean contexts while maintaining continuity through careful handoffs. Further, they can retrieve stored context like the research plan from their memory rather than losing previous work when reaching the context limit. This distributed approach prevents context overflow while preserving conversation coherence across extended interactions.
In our system, the lead agent decomposes queries into subtasks and describes them to subagents. Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information.
Context engineering is critical to making agentic systems work reliably. This insight has guided our development of LangGraph, our agent and multi-agent framework. When using a framework, you need to have full control what gets passed into the LLM, and full control over what steps are run and in what order (in order to generate the context that gets passed into the LLM). We prioritize this with LangGraph, which is a low-level orchestration framework with no hidden prompts, no enforced “cognitive architectures”. This gives you full control to do the appropriate context engineering that you require.
Multi-agent systems that primarily “read” are easier than those that “write”
Multi-agent systems designed primarily for "reading" tasks tend to be more manageable than those focused on "writing" tasks. This distinction becomes clear when comparing the two blog posts: Cognition's coding-focused system and Anthropic's research-oriented approach.
Both coding and research involve reading and writing, but they emphasize different aspects. The key insight is that read actions are inherently more parallelizable than write actions. When you attempt to parallelize writing, you face the dual challenge of effectively communicating context between agents and then merging their outputs coherently. As the Cognition blog post notes: "Actions carry implicit decisions, and conflicting decisions carry bad results." While this applies to both reading and writing, conflicting write actions typically produce far worse outcomes than conflicting read actions. When multiple agents write code or content simultaneously, their conflicting decisions can create incompatible outputs that are difficult to reconcile.
Anthropic's Claude Research illustrates this principle well. While the system involves both reading and writing, the multi-agent architecture primarily handles the research (reading) component. The actual writing—synthesizing findings into a coherent report—is deliberately handled by a single main agent in one unified call. This design choice recognizes that collaborative writing introduces unnecessary complexity.
However, even read-heavy multi-agent systems aren't trivial to implement. They still require sophisticated context engineering. Anthropic discovered this firsthand:
We started by allowing the lead agent to give simple, short instructions like 'research the semiconductor shortage,' but found these instructions often were vague enough that subagents misinterpreted the task or performed the exact same searches as other agents. For instance, one subagent explored the 2021 automotive chip crisis while 2 others duplicated work investigating current 2025 supply chains, without an effective division of labor.
Production reliability and engineering challenges
Whether using multi-agent systems or just a complex single agent one, there are several reliability and engineering challenges that emerge. Anthropic's blog post does a great job of highlighting these. These challenges are not unique to Anthropic's use case, but are actually pretty generic. A lot of the tooling we've been building has been aimed at generically solving problems like these.
Durable execution and error handling
Agents are stateful and errors compound. Agents can run for long periods of time, maintaining state across many tool calls. This means we need to durably execute code and handle errors along the way. Without effective mitigations, minor system failures can be catastrophic for agents. When errors occur, we can't just restart from the beginning: restarts are expensive and frustrating for users. Instead, we built systems that can resume from where the agent was when the errors occurred.
This durable execution is a key part of LangGraph, our agent orchestration framework. We believe all long running agents will need this, and accordingly it should be built into the agent orchestration framework.
Agent Debugging and Observability
Agents make dynamic decisions and are non-deterministic between runs, even with identical prompts. This makes debugging harder. For instance, users would report agents “not finding obvious information,” but we couldn't see why. Were the agents using bad search queries? Choosing poor sources? Hitting tool failures? Adding full production tracing let us diagnose why agents failed and fix issues systematically.
We have long recognized that observability for LLM systems is different than traditional software observability. A key reason why is it needs to be optimized for debugging these types of challenges. If you’re not sure what exactly this means - check out LangSmith, our platform for (among other things) agent debugging and observability. We’ve been building LangSmith for the past two years to handle these types of challenges. Try it out and see why this is so critical!
Evaluation of agents
A whole section in the Anthropic post is dedicated to “effective evaluation of agents”. A few key takeaways that we like:
- Start small with evals, even ~20 datapoints is enough
- LLM-as-a-judge can automate scoring of experiments
- Human testing remains essential
This resonates whole-heartedly with our approach to evaluation. We’ve been building evals into LangSmith for a while, and have landed on several features to help with those aspects:
- Datasets, to curate datapoints easily
- Running LLM-as-a-judge server side (more features coming here soon!)
- Annotation queues to coordinate and facilitate human evaluations
Conclusion
Anthropic’s blog post also contains some wisdom for where multi-agent systems may or may not work best:
Our internal evaluations show that multi-agent research systems excel especially for breadth-first queries that involve pursuing multiple independent directions simultaneously.
Multi-agent systems work mainly because they help spend enough tokens to solve the problem…. Multi-agent architectures effectively scale token usage for tasks that exceed the limits of single agents.
For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance.
Further, some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time. We’ve found that multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools.
As is quickly becoming apparent when building agents, there is not a “one-size-fits-all” solution. Instead, you will want to explore several options and choose the best one according to the problem you are solving.
Any agent framework you choose should allow you to slide anywhere on this spectrum - something we’ve uniquely emphasized with LangGraph.
Figuring out how to get multi-agent (or complex single agent) systems to function also requires new tooling. Durable execution, debugging, observability, and evaluation are all new tools that will make your life as an application developer easier. Luckily, these are all generic tooling. This means that you can use tools like LangGraph and LangSmith to get these off-the-shelf, allowing you to focus more on the business logic of your application than generic infrastructure.
Related content
Agent Architecture
Why Model Neutrality Matters More Than Cloud Neutrality
Neil Dahlke
June 4, 2026
7
min
Open Source
Agent Architecture
LangGraph
Fault Tolerance in LangGraph: Retries, Timeouts, and Error Handlers
Q. Long,
S. Runkle
June 4, 2026
7
min
Open Source
LangChain
Agent Architecture
Deep Agents
How to Build a Custom Agent Harness
Sydney Runkle
June 3, 2026
6
min
See what your agent is really doing
LangSmith, our agent engineering platform, helps developers debug every agent decision, eval changes, and deploy in one click.
関連記事
LangSmith のノーコードエージェントビルダーの紹介
LangChain が提供する LangSmith に、プログラミング不要で AI エージェントを構築できる新機能が導入された。
深層エージェントにおけるコンテキスト管理
LangChain Blog は、複雑なタスクを処理する深層エージェントの性能向上のために、コンテキストを効果的に管理・最適化する手法について解説している。
エージェントフレームワークをどう捉えるべきか
LangChain Blog は、開発者が複雑なエージェントフレームワークの設計思想や選択基準を理解するための思考法を解説している。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み