マルチエージェントシステムの構築：導入すべきタイミングと活用方法
シングルエージェントシステムでも、大半のエンタープライズワークフローは効果的に処理できます。しかし、マルチエージェントアーキテクチャを活用すれば、組織にさらなる価値をもたらすことが可能です。本記事では、これらをいつ、どのように活用すべきかを解説します。
マルチエージェントシステムとは？
マルチエージェントシステムとは、複数の LLM インスタンスがそれぞれ独立した会話コンテキストを持ち、コードを通じて連携して動作するアーキテクチャを指します。各エージェントがタスクの個別スライスを処理します（例えば、サブエージェントがリサーチしながらオーケストレーターが計画を立てるなど）。これによりコンテキストを保護して並行作業を可能にし、単一のエージェントでは維持できない専門化を可能にします。
エージェントスウォーム、機能ベースシステム、メッセージバスアーキテクチャといった複数の連携パターンが存在する中で、本記事は「オーケストレーター・サブエージェント」パターンに焦点を当てます。これは、リードエージェントが特定のサブタスク専用のサブエージェントを立ち上げ、管理する階層型モデルです。このパターンは連携モデルとして分かりやすく、マルチエージェントシステムを初めて導入するチームにとって理想的な出発点となります。その他のパターンについては、次回の記事で詳しく掘り下げます。
現在、マルチエージェントシステムは、単一エージェントで十分に機能する場面でも過剰に適用されるケースが目立ちます。ただし、モデル性能の向上に伴い、この最適な適用範囲の判断基準も常に変化し続けています。Anthropic では、数ヶ月かけて複雑なマルチエージェントアーキテクチャを構築したチームが、結局は単一のエージェントのプロンプトを改善するだけで同等の結果を得られた、というケースを何度も目にしてきました。
私たちはマルチエージェントシステムの開発および、プロダクション環境へのデプロイを支援する過程で、単一エージェントを明確に上回る 3 つのシナリオを特定しました。それは「コンテキストの肥大化によるパフォーマンス低下の回避」「タスクの並行処理」、そして「専門性によるツール選択とタスク集中の最適化」です。これら以外の状況では通常、エージェント間の連携コストが導入のメリットを上回ってしまいます。
本記事では、単一のエージェントの限界を見極める方法、マルチエージェントシステムが真価を発揮する 3 つのシナリオ、そしてよくある実装上のミスを回避する方法をご紹介します。
単一のエージェントから始めるべき理由
適切なツールを備えた設計の優れた単一のエージェントは、多くの開発者の予想をはるかに超えるタスクを遂行できます。
マルチエージェントシステムにはオーバーヘッドが伴います。エージェントを追加するたびに、潜在的な障害ポイントや保守すべきプロンプトが増え、予期せぬ挙動を引き起こす要因も増加してしまうのです。
計画、実行、レビュー、反復改善といった工程ごとに個別のエージェントを割り当てて緻密なシステムをチームが構築した結果、引き継ぎのたびにコンテキストが欠落し、実際のタスク処理よりもエージェント間の連携調整に多くのトークンを消費してしまったケースも確認されています。社内のテストでは、マルチエージェントの実装は同等のタスクを行う単一のエージェントのアプローチと比較して、通常 3〜10 倍のトークンを消費することが分かっています。このオーバーヘッドは、エージェント間でのコンテキストの複製、連携のためのメッセージのやり取り、そして引き継ぎに向けた結果の要約処理によるものです。
マルチエージェントシステム導入の判断フレームワーク
マルチエージェントアーキテクチャが価値を提供するのは、シングルエージェントでは克服できない特定の制約を解消できる場合です。つまり、追加コストを正当化できるほどの明確なメリットをもたらすケースにのみ、このアーキテクチャを採用すべきと言えます。マネージドインフラストラクチャでも、この処理を代行できます（Claude Managed Agents のマルチエージェントオーケストレーションをご覧ください）。
以下のパターンは、この投資に対する確かな見返りが一貫して確認されているケースを示しています。
コンテキストの保護
大規模言語モデルのコンテキストウィンドウは有限であり、コンテキストが増大するにつれてレスポンスの品質が低下する可能性があります。あるサブタスクからの情報が後続のサブタスクには無関係なまま蓄積されると、「コンテキストの汚染」が発生します。このような汚染を防ぐのがサブエージェントです。タスクごとにコンテキストを切り離すことで、それぞれが不要な情報を持たないクリーンな状態で特定の作業に集中できるようになります。
技術的な問題を診断しながら注文履歴を取得する必要があるカスタマーサポートエージェントを例に考えてみましょう。注文を検索するたびに数千トークンがコンテキストに追加されると、技術的な問題について推論するエージェントの能力は低下してしまいます。
シングルエージェントのアプローチ：
# Single agent accumulates everything in context
conversation_history = [
{"role": "user", "content": "My order #12345 isn't working"},
{"role": "assistant", "content": "Let me check your order..."},
# Tool result adds 2000+ tokens of order history
{"role": "user", "content": "... (order details, past purchases, shipping info) ..."},
{"role": "assistant", "content": "Now let me diagnose the technical issue..."},
# Context is now polluted with order details the agent doesn't need
]エージェントは、無関係な注文履歴を含む 2000 トークン以上をコンテキストに保持したまま技術的な問題に対処しなければならず、注意力が分散し応答品質の低下を招きます。
マルチエージェントのアプローチ：
from anthropic import Anthropic
client = Anthropic()
class OrderLookupAgent:
def lookup_order(self, order_id: str) -> dict:
# Separate agent with its own context
messages = [
{"role": "user", "content": f"Get essential details for order {order_id}"}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=messages,
tools=[get_order_details_tool]
)
# Returns only essential information
return extract_summary(response)
class SupportAgent:
def handle_issue(self, user_message: str):
if needs_order_info(user_message):
order_id = extract_order_id(user_message)
# Get only what's needed, not full history
order_summary = OrderLookupAgent().lookup_order(order_id)
# Inject compact summary, not full context
context = f"Order {order_id}: {order_summary['status']}, purchased {order_summary['date']}"
# Main agent context stays clean
messages = [
{"role": "user", "content": f"{context}\n\nUser issue: {user_message}"}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=2048,
messages=messages
)
return response注文照会エージェントは注文履歴の全体を解析し、要約のみを抽出します。メインエージェントは実際に必要な 50〜100 トークンのみを受け取るため、コンテキストが集中した状態を維持できます。
コンテキストの分離が最も効果を発揮するのは、サブタスクが大量のコンテキスト（1000 トークン以上）を生成するものの、その大半がメインタスクと無関係であるケースです。また、抽出情報の基準が明確でサブタスクが十分に定義されている場合や、利用前にフィルタリングを要する検索・照会操作においても優れた機能を発揮します。
並行処理（パラレル化）
複数のエージェントを並行して実行することで、シングルエージェントではカバーしきれない広範な検索スペースの探索が可能になります。このパターンは、検索や調査タスクにおいて特に有用であることが実証されています。
Anthropicの研究チームは、マルチエージェント研究システムの構築についての記事で、この件を文書化しました。リードエージェントがクエリを分析し、異なる側面を並行して調査するための複数のサブエージェントを生成。各サブエージェントは独立して検索を行い、抽出した調査結果を返します。マルチエージェントによる検索は、より広大な情報空間を横断した探索を可能にするため、シングルエージェントのアプローチと比較して大幅な精度の向上が見られます。
コアとなる実装では、質問を独立した側面に分解し、サブエージェントを並行して稼働させた後、結果を統合します。
import asyncio
from anthropic import AsyncAnthropic
client = AsyncAnthropic()
async def research_topic(query: str) -> dict:
# Lead agent breaks query into research facets
facets = await lead_agent.decompose_query(query)
# Spawn subagents to research each facet in parallel
tasks = [
research_subagent(facet)
for facet in facets
]
results = await asyncio.gather(*tasks)
# Lead agent synthesizes findings
return await lead_agent.synthesize(results)
async def research_subagent(facet: str) -> dict:
"""Each subagent has its own context window"""
messages = [
{"role": "user", "content": f"Research: {facet}"}
]
response = await client.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
messages=messages,
tools=[web_search, read_document]
)
return extract_findings(response)このようなカバレッジの向上にはコストが伴います。前述の通り、マルチエージェントシステムは同等のタスクに対して、シングルエージェントの 3 〜 10 倍のトークンを消費します。これは、各エージェントが個別のコンテキストを必要とし、連携のためのメッセージ交換が発生し、エージェント間で結果を渡す際に要約処理が求められるためです。並行処理によって一連の作業を順次実行するよりも全体的な実行時間を短縮できる一方で、計算量が絶対的に増加するため、結果的にシングルエージェントシステムよりも全体の処理時間が長くなるケースも少なくありません。
並行処理の最大の利点は、スピードではなく徹底性にあります。膨大な情報空間を検索する必要がある場合や、複雑な質問に対して多角的な調査が求められる場合、並行エージェントはコンテキスト制限内で動くシングルエージェントよりも広範囲をカバーできます。より包括的な結果を得る代償として、トークン使用量の増加と、全体的な実行時間の延長というトレードオフを受け入れることになります。
専門化
タスクによっては、固有のツールセット、システムプロンプト、または専門知識の領域を使い分けることで成果が向上します。単一のエージェントに何十ものツールへのアクセス権を与えるよりも、それぞれの役割に合わせた専用のツールセットを持つ特化型のエージェントを用意する方が、信頼性の向上に繋がります。
ツールセットの専門化
エージェントが多すぎるツールにアクセスできると、パフォーマンスは低下します。以下の 3 つのサインが現れた場合、ツールの専門化が有効です。
- 量の多さ ツールが多すぎる（多くの場合 20 個以上）エージェントは、適切なツールの選択に苦戦してしまいます。
- ドメインの混同ツールが関連性のない複数の領域（データベース操作、API コール、ファイルシステム操作など）にまたがっている場合、エージェントはどのドメインをタスクに適用すべきか混乱してしまいます。
- パフォーマンスの低下新しいツールを追加することで既存タスクのパフォーマンスが落ちる場合、エージェントがツール管理のキャパシティ上限に達していることを示唆しています。
システムプロンプトの専門化
タスクによっては、組み合わせると相反するような異なるペルソナ、制約、または指示が求められることがあります。カスタマーサポートのエージェントには共感力と忍耐が、コードレビューのエージェントには正確性と批判的な視点が必要です。コンプライアンスチェックには厳格なルール遵守が求められますが、ブレインストーミングには創造的な柔軟性が不可欠です。単一のエージェントがこうした相反する行動モードを切り替えなければならない場合、それぞれに最適化されたシステムプロンプトを持つ特化型エージェントに分割することで、より一貫した結果が得られます。
各専門化されたエージェントの質はその指示次第です。単一エージェントの出力を向上させる同じプロンプトエンジニアリングのベストプラクティスが、すべてのサブエージェントのシステムプロンプトに適用されます。
ドメイン知識の専門化
一部のタスクでは、汎用的なエージェントには処理しきれないような、深い専門知識が求められます。たとえば、法務分析エージェントには判例や規制の枠組みに関する膨大なコンテキストが必要となり、医学研究エージェントには臨床試験の手法に関する専門知識が欠かせません。すべてのコンテキストを単一のエージェントに詰め込むのではなく、各エージェントを特定の役割に関連する専門知識に特化させることが有効です。
例：マルチプラットフォームの統合CRM、マーケティングオートメーション、およびメッセージングプラットフォームを横断してエージェントを稼働させる統合システムを考えてみましょう。各プラットフォームには 10 〜 15 個の関連 API エンドポイントが存在します。40 個以上のツールを持つ単一エージェントは、適切な選択に苦戦し、プラットフォーム間で似たような操作を混同しがちです。これを専用のツールセットと最適化されたプロンプトを持つ特化型エージェントに分割することで、選択エラーを解消できます。
from anthropic import Anthropic
client = Anthropic()
# Specialized agents with focused toolsets and tailored prompts
class CRMAgent:
"""Handles customer relationship management operations"""
system_prompt = """You are a CRM specialist. You manage contacts,
opportunities, and account records. Always verify record ownership
before updates and maintain data integrity across related records."""
tools = [
crm_get_contacts,
crm_create_opportunity,
# 8-10 CRM-specific tools
]
class MarketingAgent:
"""Handles marketing automation operations"""
system_prompt = """You are a marketing automation specialist. You
manage campaigns, lead scoring, and email sequences. Prioritize
data hygiene and respect contact preferences."""
tools = [
marketing_get_campaigns,
marketing_create_lead,
# 8-10 marketing-specific tools
]
class OrchestratorAgent:
"""Routes requests to specialized agents"""
def execute(self, user_request: str):
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system="""You coordinate platform integrations. Route requests to the appropriate specialist:
- CRM: Contact records, opportunities, accounts, sales pipeline
- Marketing: Campaigns, lead nurturing, email sequences, scoring
- Messaging: Notifications, alerts, team communication""",
messages=[
{"role": "user", "content": user_request}
],
tools=[delegate_to_crm, delegate_to_marketing, delegate_to_messaging]
)
return responseこのパターンは、あらゆる領域の専門知識を網羅しようとするジェネラリストよりも、それぞれの役割に合ったツールを持つ専門家同士のコラボレーションの方が高い効果を発揮するという、実際のプロフェッショナルな協業の形を反映したものです。ただし、専門化にはルーティングの複雑さが伴います。オーケストレーターはリクエストを正確に分類し、適切なエージェントへと振り分ける必要があります。ここでルーティングを誤れば、出力の品質は著しく低下してしまいます。また、複数の特化型エージェントを維持することで、プロンプトのメンテナンスにかかる工数も増加。専門化が最も効果を発揮するのは、領域が明確に分離可能であり、かつルーティングの判断基準に曖昧さがない場合です。
シングルエージェントアーキテクチャの限界を超えた合図
一般的なフレームワークに加え、シングルエージェントのパターンが限界に達していることを示す具体的なサインが存在します。
コンテキスト制限への接近。エージェントが日常的に大量のコンテキストを使用し、パフォーマンスが低下している場合、コンテキストの圧迫がボトルネックになっている可能性があります。だし、近年のコンテキスト管理技術の進歩（自動コンテキスト圧縮など）によりこの制限は緩和されつつあり、単一エージェントでもより長期的な視点で効果的なメモリを維持できるようになっています。
多くのツールの管理エージェントが 15 〜 20 個以上のツールを持つようになると、モデルは選択肢を理解するためにかなりのコンテキストと注意力を消費します。マルチエージェントアーキテクチャを採用する前に、すべての定義を事前にロードするのではなく、Claude に必要なツールを動的に発見させるツール検索ツール（Tool Search Tool）の活用をご検討ください。これにより、ツール選択の精度を向上させるとともに、トークン使用量を最大 85% 削減できます。
並行化可能なサブタスクタスクが自然に独立した要素（複数ソースにまたがる調査や、複数コンポーネントのテストなど）に分解できる場合、並行サブエージェントによって大幅なスピードアップが期待できます。
これらの境界線は、モデルの進化に伴って変化していくものです。現在の制限は、根本的な制約ではなく、あくまで実用的なガイドラインとして捉えてください。
コンテキスト中心の分解
マルチエージェントアーキテクチャを導入する際、最も重要な設計上の判断は「作業をエージェント間でどのように分割するか」です。現場ではこの判断を誤り、マルチエージェント設計の利点を打ち消すほどの連携オーバーヘッドを引き起こしているチームが頻繁に見受けられます。
重要なのは、作業を分解する際に、「課題中心」ではなく、コンテキスト中心の視点を取り入れることです。
課題中心の分解（多くの場合逆効果）作業の種類による分割（機能実装、テスト作成、コードレビューといった分担）は、絶え間ない調整コストを発生させる原因となります。引き継ぎのたびにコンテキストが欠落し、テスト作成エージェントは特定の実装判断が下された背景を知らず、コードレビュアーは探索や検証のプロセスといったコンテキストを欠いた状態に陥ります。
コンテキスト中心の分解（一般的に効果的）コンテキストの境界で分割するということは、ある機能を担当するエージェントが、必要なコンテキストをすでに保持しているため、その機能のテストも行うべきだという考え方です。作業を分割すべきなのは、コンテキストを完全に分離できる場合のみに留めるべきです。
この原則は、マルチエージェントシステムにおける失敗パターンを観察する中で導き出されました。課題の種類によってエージェントを分割すると、情報が伝言ゲームのように行き来し、引き継ぎのたびに精度が劣化していきます。ソフトウェア開発の役割（プランナー、実装者、テスター、レビュアー）ごとにエージェントを特化させたある実験では、サブエージェントは実際の作業よりも連携調整に多くのトークンを消費する結果となりました。
効果的な分解境界の例は次の通りです。
- 独立した調査経路 「アジアの市場動向」と「ヨーロッパの市場動向」の調査は、共有コンテキストなしで並行して進めることができます。
- クリーンなインターフェースを持つ独立したコンポーネント API 仕様（コントラクト）が明確に定義されていれば、フロントエンドとバックエンドの開発を並行して進められます。
- ブラックボックス検証テストを実行して結果を報告するだけの検証エージェントであれば、実装の背景やコンテキストは不要です。
問題を引き起こしやすいタスク分割の境界線の例は次の通りです。
- 同一作業の連続したフェーズ 同一機能の計画、実装、テストは、共有すべきコンテキストが多すぎます。
- 密結合したコンポーネント 一定のやり取りが必要なコンポーネントは、同じエージェント内に配置すべきです。
- 状態の共有を前提とするタスク 認識のすり合わせを頻繁に行う必要のある作業は、エージェントを分割せずに統合しておく必要があります。
検証サブエージェントのパターン
さまざまな領域で一貫して高い効果を発揮するマルチエージェントパターンの一つが、検証サブエージェントです。メインエージェントの作業のテストや検証を専任とするエージェントを指します。
注目すべきは、より高性能なオーケストレーターモデル（Claude Opus 4.5 など）は、個別の検証プロセスを挟むことなく、サブエージェントの作業を直接評価できるようになりつつある点です。れでも、より軽量なオーケストレーターを使用する場合や、検証に専用のツールが必要な場合、さらにはワークフロー内に明確な検証チェックポイントを設けたい場合には、検証サブエージェントは依然として有用です。
検証サブエージェントが機能する理由は、前述した「伝言ゲーム」の問題を回避できる点にあります。検証という作業は性質上、コンテキストの移行が最小限で済みます。そのため、検証エージェントは構築の全履歴を把握することなく、システムをブラックボックステストすることが可能です。
マルチエージェントシステムの実装
まず、メインエージェントが作業の単位を完了させます。次の工程へ進む前に、検証対象となる成果物、明確な成功基準、および検証を実行するためのツールを備えた検証サブエージェントを生成。
検証エージェントは、そのアーティファクトがなぜそのように構築されたのかを理解する必要はありません。指定された基準を満たしているかどうかを判断するだけで十分です。
from anthropic import Anthropic
client = Anthropic()
class CodingAgent:
def implement_feature(self, requirements: str) -> dict:
"""Main agent implements the feature"""
messages = [
{"role": "user", "content": f"Implement: {requirements}"}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
messages=messages,
tools=[read_file, write_file, list_directory]
)
return {
"code": response.content,
"files_changed": extract_files(response)
}
class VerificationAgent:
def verify_implementation(self, requirements: str, files_changed: list) -> dict:
"""Separate agent verifies the work"""
messages = [
{"role": "user", "content": f"""
Requirements: {requirements}
Files changed: {files_changed}
Run the test suite and verify:
1. All existing tests pass
2. New functionality works as specified
3. No obvious errors or security issues
You MUST run the complete test suite before marking as passed.
Do not mark as passing after only running a few tests.
Run: pytest --verbose
Only mark as PASSED if ALL tests pass with no failures.
"""}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
messages=messages,
tools=[run_tests, execute_code, read_file]
)
return {
"passed": extract_pass_fail(response),
"issues": extract_issues(response)
}
def implement_with_verification(requirements: str, max_attempts: int = 3):
for attempt in range(max_attempts):
result = CodingAgent().implement_feature(requirements)
verification = VerificationAgent().verify_implementation(
requirements,
result['files_changed']
)
if verification['passed']:
return result
requirements += f"\n\nPrevious attempt failed: {verification['issues']}"
raise Exception(f"Failed verification after {max_attempts} attempts")マルチエージェントシステムアプリケーション
検証サブエージェントは以下の用途で真価を発揮します。
- 品質保証（QA） テストスイートの実行、コードのリンティング、スキーマに基づく出力の検証。
- コンプライアンスチェック ドキュメントがポリシー要件を満たしているかの確認、ルールに基づく出力の検証。
- 出力の検証 成果物を引き渡す前に、生成されたコンテンツが仕様を満たしているかを確認する工程。
- 事実検証 生成されたコンテンツ内の主張や引用について、独立したエージェントに検証させる業務。
「早すぎる成功宣言」の罠
検証サブエージェントにおいて最も警戒すべき失敗パターンは、徹底的なテストを行わずに出力を「合格」として処理してしまうことです。検証エージェントが 1 〜 2 個のテストを実行し、それが通過しただけで成功を宣言してしまうケースがこれに該当します。
この問題を防ぐための軽減策として、以下が挙げられます。
- 具体的な基準の設定「正しく動作することを確認する」といった曖昧な指示ではなく、「テストスイート全体を実行し、すべてのエラーを報告する」と明確に指定します。
- 包括的なチェック 複数のシナリオやエッジケースのテストを検証エージェントに要求します。
- ネガティブテスト失敗するはずの入力を意図的に与え、実際に失敗することを確認するよう指示します。
- ハッキリとした指示「合格とする前に、必ずテストスイート全体を実行すること」といった指示が不可欠です。包括的な検証を求める明示的な要件がない場合、検証エージェントはプロセスを省略しがちです。
シングルエージェントシステムとマルチエージェントシステムの選択
マルチエージェントシステムは強力ですが、あらゆる場面で万能というわけではありません。複数のエージェントを連携させるという複雑なアーキテクチャを導入する前に、以下の点を確認してください。
- コンテキストの制限、並行処理による効率化、専門化の必要性など、マルチエージェント化によって解決でき「真の制約」が存在するか。
- タスクの切り分けが、課題の種類ではなくコンテキストに基づいているか。作業の種類ではなく、必要とされるコンテキストごとに作業をグループ化します。
- サブエージェントが全コンテキストを必要とせずに作業を検証できる、明確な検証ポイントが存在するか。
私たちからのアドバイスは、「まずは機能する最もシンプルな方法から始め、明確な根拠や必要性が生じた場合にのみ複雑さを追加していく」ことです。
本稿は、マルチエージェントシステムに関する連載記事の第 1 回です。単一エージェントパターンの詳細については、効果的なエージェントの構築をご覧ください。コンテキスト管理戦略については、AI エージェントのための効果的なコンテキストエンジニアリングをご覧ください。 また、当社のマルチエージェントリサーチシステムの構築プロセスについては、マルチエージェントリサーチシステムの構築方法で詳しく解説しています。
謝辞
執筆：Cara Phillips 氏、協力：Paul Chen 氏、Andy Schumeister 氏、Brad Abrams 氏、Theo Chu 氏