<![CDATA[Justin Castilla - Elasticsearch Labs]]> <![CDATA[Justin Castilla - Elasticsearch Labs]]> https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt1121c0bf0e8a6e65/6a88da6340a1841030ef456f/search-labs-thumbnail.png https://www.elastic.co/jp/search-labs/author/justin-castilla https://www.elastic.co/jp/search-labs/author/justin-castilla Mon, 28 Sep 2026 13:34:59 GMT <![CDATA[Elasticsearch で A2A プロトコルと MCP を使用して LLM エージェント ニュースルームを作成する: パート II]]> A2AとMCP：コードの動作

これは、記事「Elasticsearch で A2A プロトコルと MCP を使用して LLM エージェント ニュースルームを作成する」の補足記事です。この記事では、同じエージェント内に A2A と MCP の両方のアーキテクチャを実装して、両方のフレームワークの独自のメリットを最大限に活用するメリットについて説明しました。自分でデモを実行したい場合、リポジトリが利用可能です。

A2A & MCP プロトコルエージェントワークフロー

ニュースルームのエージェントが A2A と MCP の両方を使用して協力し、ニュース記事を作成する方法を見ていきましょう。エージェントの動作を確認するための付属リポジトリは、ここにあります。

ステップ1：ストーリーの割り当て

ニュースチーフ（クライアントとして行動）がストーリーを割り当てます。

{ "message_type": "task_request", "sender": "news_chief", "receiver": "reporter_agent", "payload": { "task_id": "story_renewable_energy_2024", "assignment": { "topic": "Renewable Energy Adoption in Europe", "angle": "Policy changes driving solar and wind expansion", "target_length": 1200, "deadline": "2025-09-30T18:00:00Z" } } }

ステップ2: 記者が調査を依頼する

レポーター エージェントは背景情報が必要であることを認識し、A2A を介してリサーチャー エージェントに委任します。

{ "message_type": "task_request", "sender": "reporter_agent", "receiver": "researcher_agent", "payload": { "task_id": "research_eu_renewable_2024", "parent_task_id": "story_renewable_energy_2024", "capability": "fact_gathering", "parameters": { "queries": [ "EU renewable energy capacity 2024", "Solar installations growth Europe", "Wind energy policy changes 2024" ], "depth": "comprehensive" } } }

ステップ3: 報告者がアーカイブエージェントに歴史的背景をリクエストする

レポーターエージェントは、歴史的背景が記事の内容を強めることを認識しています。A2A 経由でアーカイブエージェント( Elastic の A2A エージェントを搭載) に委任し、ニュースルームの Elasticsearch 搭載記事アーカイブを検索します。

{ "message_type": "task_request", "sender": "reporter_agent", "receiver": "archive_agent", "payload": { "task_id": "archive_search_renewable_2024", "parent_task_id": "story_renewable_energy_2024", "capability": "search_archive", "parameters": { "query": "European renewable energy policy changes and adoption trends over past 5 years", "focus_areas": ["solar", "wind", "policy", "Germany", "France"], "time_range": "2019-2024", "result_count": 10 } } }

ステップ4: アーカイブエージェントはMCPでElastic A2Aエージェントを使用する

アーカイブ エージェントはElastic の A2A エージェントを使用し、A2A エージェントは MCP を使用して Elasticsearch ツールにアクセスします。これは、A2A がエージェントのコラボレーションを可能にし、MCP がツール アクセスを提供するハイブリッド アーキテクチャを示しています。

# Archive Agent using Elastic A2A Agent async def search_historical_articles(self, query_params): # The Archive Agent sends a request to Elastic's A2A Agent elastic_response = await self.a2a_client.send_request( agent="elastic_agent", capability="search_and_analyze", parameters={ "natural_language_query": query_params["query"], "index_pattern": "newsroom-articles-*", "filters": { "topics": query_params["focus_areas"], "date_range": query_params["time_range"] }, "analysis_type": "trend_analysis" } ) # Elastic's A2A Agent internally uses MCP tools: # - platform.core.search (to find relevant articles) # - platform.core.generate_esql (to analyze trends) # - platform.core.index_explorer (to identify relevant indices) return elastic_response

アーカイブエージェントはElastic の A2A エージェントから包括的な履歴データを受信し、それをレポーターに返します。

{ "message_type": "task_response", "sender": "archive_agent", "receiver": "reporter_agent", "payload": { "task_id": "archive_search_renewable_2024", "status": "completed", "archive_data": { "historical_articles": [ { "title": "Germany's Energiewende: Five Years of Solar Growth", "published": "2022-06-15", "key_points": [ "Germany added 7 GW annually 2020-2022", "Policy subsidies drove 60% of growth" ], "relevance_score": 0.94 }, { "title": "France Balances Nuclear and Renewables", "published": "2023-03-20", "key_points": [ "France increased renewable target to 40% by 2030", "Solar capacity doubled 2021-2023" ], "relevance_score": 0.89 } ], "trend_analysis": { "coverage_frequency": "EU renewable stories increased 150% since 2019", "emerging_themes": ["policy incentives", "grid modernization", "battery storage"], "coverage_gaps": ["Small member states", "offshore wind permitting"] }, "total_articles_found": 47, "search_confidence": 0.91 } } }

このステップでは、Elastic の A2A エージェントがニュースルームのワークフローにどのように統合されるかを示します。Archive Agent（ニュースルーム固有のエージェント）は、Elastic の A2A Agent（サードパーティの専門家）と連携して、Elasticsearch の強力な検索および分析機能を活用します。Elastic のエージェントは内部的に MCP を使用して Elasticsearch ツールにアクセスし、エージェント調整 (A2A) とツール アクセス (MCP) を明確に分離します。

ステップ5: 研究者はMCPサーバーを使用する

研究者エージェントは複数の MCP サーバーにアクセスして情報を収集します。

# Researcher Agent using MCP to access tools async def gather_facts(self, queries): results = [] # Use News API MCP Server news_data = await self.mcp_client.invoke_tool( server="news_api_mcp", tool="search_articles", parameters={ "query": queries[0], "date_range": "2024-01-01 to 2024-09-30", "sources": ["reuters", "bloomberg", "euractiv"] } ) # Use Statistics MCP Server stats_data = await self.mcp_client.invoke_tool( server="eurostat_mcp", tool="get_energy_statistics", parameters={ "metrics": ["solar_capacity_mw", "wind_capacity_mw"], "countries": ["EU27"], "year": 2024 } ) # Use Fact-Checking MCP Server verified_facts = await self.mcp_client.invoke_tool( server="factcheck_mcp", tool="verify_claims", parameters={ "claims": [ "EU solar capacity increased 40% in 2024", "Germany leads in wind installations" ] } ) return self._synthesize_research(news_data, stats_data, verified_facts)

ステップ6: 研究者が報告者にデータを返す

研究者エージェントは、包括的な研究を A2A 経由で返送します。

{ "message_type": "task_response", "sender": "researcher_agent", "receiver": "reporter_agent", "payload": { "task_id": "research_eu_renewable_2024", "status": "completed", "research_data": { "key_facts": [ { "claim": "EU solar capacity reached 260 GW in 2024", "source": "Eurostat Q3 2024 Report", "confidence": 0.95, "verified": true }, { "claim": "Germany installed 12 GW of wind capacity in 2024", "source": "German Federal Network Agency", "confidence": 0.92, "verified": true } ], "statistics": { "solar_growth_rate": "35%", "wind_growth_rate": "28%" }, "sources_count": 15 } } }

ステップ7：記者が記事を書く

Reporter Agent は、調査データと独自の LLM 機能を使用して記事を作成します。書き込み中、Reporter はスタイルとテンプレートに MCP サーバーを使用します。

# Reporter Agent writing with MCP assistance async def write_article(self, research_data, assignment): # Get style guidelines via MCP style_guide = await self.mcp_client.get_resource( server="newsroom_mcp", resource="style://editorial/ap_style_guide" ) # Get article template via MCP template = await self.mcp_client.get_resource( server="newsroom_mcp", resource="template://articles/news_story" ) # Generate article using LLM + research + style draft = await self.llm.generate( prompt=f""" Write a news article following these guidelines: {style_guide} Using this template: {template} Based on this research: {research_data} Assignment: {assignment} """ ) # Self-evaluate confidence in claims confidence_check = await self._evaluate_confidence(draft) return draft, confidence_check

ステップ8：自信が低い場合は再調査を促します

レポーター エージェントは下書きを評価し、1 つの主張の信頼性が低いことを発見しました。研究者エージェントに別のリクエストを送信します:

{ "message_type": "collaboration_request", "sender": "reporter_agent", "receiver": "researcher_agent", "payload": { "request_type": "fact_verification", "claims": [ { "text": "France's nuclear phase-down contributed to 15% increase in renewable capacity", "context": "Discussing policy drivers for renewable growth", "current_confidence": 0.45, "required_confidence": 0.80 } ], "urgency": "high" } }

研究者はファクトチェックMCPサーバーを使用して主張を検証し、更新された情報を返します。

{ "message_type": "collaboration_response", "sender": "researcher_agent", "receiver": "reporter_agent", "payload": { "verified_claims": [ { "original_claim": "France's nuclear phase-down contributed to 15% increase...", "verified_claim": "France's renewable capacity increased 18% in 2024, partially offsetting reduced nuclear output", "confidence": 0.88, "corrections": "Percentage was 18%, not 15%; nuclear phase-down is gradual, not primary driver", "sources": ["RTE France", "French Energy Ministry Report 2024"] } ] } }

ステップ9: 記者が修正して編集者に提出する

記者は検証された事実を組み込み、完成した原稿を A2A 経由で編集者エージェントに送信します。

{ "message_type": "task_request", "sender": "reporter_agent", "receiver": "editor_agent", "payload": { "task_id": "edit_renewable_story", "parent_task_id": "story_renewable_energy_2024", "content": { "headline": "Europe's Renewable Revolution: Solar and Wind Surge 30% in 2024", "body": "[Full article text...]", "word_count": 1185, "sources": [/* array of sources */] }, "editing_requirements": { "check_style": true, "check_facts": true, "check_seo": true } } }

ステップ10: MCPツールを使用した編集者のレビュー

エディター エージェントは複数の MCP サーバーを使用して記事をレビューします。

# Editor Agent using MCP for quality checks async def review_article(self, content): # Grammar and style check grammar_issues = await self.mcp_client.invoke_tool( server="grammarly_mcp", tool="check_document", parameters={"text": content["body"]} ) # SEO optimization check seo_analysis = await self.mcp_client.invoke_tool( server="seo_mcp", tool="analyze_content", parameters={ "headline": content["headline"], "body": content["body"], "target_keywords": ["renewable energy", "Europe", "solar", "wind"] } ) # Plagiarism check originality = await self.mcp_client.invoke_tool( server="plagiarism_mcp", tool="check_originality", parameters={"text": content["body"]} ) # Generate editorial feedback feedback = await self._generate_feedback( grammar_issues, seo_analysis, originality ) return feedback

編集者は記事を承認し、送信します。

{ "message_type": "task_response", "sender": "editor_agent", "receiver": "reporter_agent", "payload": { "status": "approved", "quality_score": 9.2, "minor_edits": [ "Changed 'surge' to 'increased' in paragraph 3 for AP style consistency", "Added Oxford comma in list of countries" ], "approved_content": "[Final edited article]" } }

ステップ11: パブリッシャーがCI/CD経由でパブリッシュする

最後に、プリンター エージェントは、CMS および CI/CD パイプラインの MCP サーバーを使用して承認された記事を公開します。

# Publisher Agent publishing via MCP async def publish_article(self, content, metadata): # Upload to CMS via MCP cms_result = await self.mcp_client.invoke_tool( server="wordpress_mcp", tool="create_post", parameters={ "title": content["headline"], "body": content["body"], "status": "draft", "categories": metadata["categories"], "tags": metadata["tags"], "featured_image_url": metadata["image_url"] } ) post_id = cms_result["post_id"] # Trigger CI/CD deployment via MCP deploy_result = await self.mcp_client.invoke_tool( server="cicd_mcp", tool="trigger_deployment", parameters={ "pipeline": "publish_article", "environment": "production", "post_id": post_id, "schedule": "immediate" } ) # Track analytics await self.mcp_client.invoke_tool( server="analytics_mcp", tool="register_publication", parameters={ "post_id": post_id, "publish_time": datetime.now().isoformat(), "story_id": metadata["story_id"] } ) return { "status": "published", "post_id": post_id, "url": f"https://newsroom.example.com/articles/{post_id}", "deployment_id": deploy_result["deployment_id"] }

出版社はA2Aを通じて出版を確認します。

{ "message_type": "task_complete", "sender": "printer_agent", "receiver": "news_chief", "payload": { "task_id": "story_renewable_energy_2024", "status": "published", "publication": { "url": "https://newsroom.example.com/articles/renewable-europe-2024", "published_at": "2025-09-30T17:45:00Z", "post_id": "12345" }, "workflow_metrics": { "total_time_minutes": 45, "agents_involved": ["reporter", "researcher", "archive", "editor", "printer"], "iterations": 2, "mcp_calls": 12 } } }

以下は、上記と同じエージェントを使用した付属のリポジトリ内の A2A ワークフローの完全なシーケンスです。

#

から

に

アクション

プロトコル

説明

1

ユーザー

ニュースチーフ

ストーリーの割り当て

HTTP ポスト

ユーザーがストーリーのトピックと角度を提出する

2

ニュースチーフ

内部

ストーリーを作成する

-

固有のIDを持つストーリーレコードを作成します

3

ニュースチーフ

記者

委任の割り当て

A2A

A2Aプロトコル経由でストーリー割り当てを送信します

4

記者

内部

割り当てを受け入れる

-

割り当てを内部に保存する

5

記者

MCP サーバー

アウトラインを生成

MCP/HTTP

記事のアウトラインと研究の質問を作成します

6a

記者

研究者

調査依頼

A2A

質問を送信します（6bと並行）

6b

記者

アーキビスト

アーカイブを検索

A2A JSONRPC

歴史的な記事を検索します（6aと並行）

7

研究者

MCP サーバー

研究上の質問

MCP/HTTP

MCP経由でAnthropicを使用して質問に答えます

8

研究者

記者

リターンリサーチ

A2A

調査の回答を返す

9

アーキビスト

Elasticsearch

検索インデックス

ES REST API

news_archiveインデックスをクエリ

10

アーキビスト

記者

アーカイブに戻る

A2A JSONRPC

過去の検索結果を返します

11

記者

MCP サーバー

記事を生成する

MCP/HTTP

研究/アーカイブの文脈で記事を作成する

12

記者

内部

ストアドラフト

-

下書きを内部に保存

13

記者

ニュースチーフ

下書きを送信

A2A

完成した草稿を提出する

14

ニュースチーフ

内部

ストーリーを更新

-

下書きを保存し、ステータスを「draft_submitted」に更新します

15

ニュースチーフ

エディタ

レビュー草稿

A2A

レビューのために編集者に自動ルーティング

16

エディタ

MCP サーバー

総説

MCP/HTTP

MCP経由でAnthropicを使用してコンテンツを分析します

17

エディタ

ニュースチーフ

返品レビュー

A2A

編集上のフィードバックと提案を送信します

18

ニュースチーフ

内部

ストアレビュー

-

編集者のフィードバックを保存

19

ニュースチーフ

記者

編集を適用

A2A

レビューのフィードバックをレポーターに転送する

20

記者

MCP サーバー

編集を適用

MCP/HTTP

フィードバックに基づいて記事を修正する

21

記者

内部

下書きの更新

-

修正を加えて下書きを更新する

22

記者

ニュースチーフ

返品修正

A2A

修正された記事を返す

23

ニュースチーフ

内部

ストーリーを更新

-

修正した下書きを保存し、ステータスを「修正済み」にする

24

ニュースチーフ

出版社

記事を公開する

A2A

パブリッシャーへの自動ルーティング

25

出版社

MCP サーバー

タグを生成する

MCP/HTTP

タグとカテゴリを作成する

26

出版社

Elasticsearch

インデックス記事

ES REST API

記事をnews_archiveインデックスにインデックスします

27

出版社

ファイルシステム

マークダウンを保存

ファイルI/O

記事を.mdとして保存します/articles内のファイル

28

出版社

ニュースチーフ

公開の確認

A2A

成功ステータスを返します

29

ニュースチーフ

内部

ストーリーを更新

-

ストーリーのステータスを「公開済み」に更新します

まとめ

A2A と MCP はどちらも、現代の拡張 LLM インフラストラクチャ パラダイムにおいて重要な役割を果たします。A2A は複雑なマルチエージェント システムに柔軟性を提供しますが、移植性が低くなり、運用が複雑になる可能性があります。MCP は、マルチエージェント オーケストレーションを処理するようには設計されていませんが、実装と保守がより簡単なツール統合のための標準化されたアプローチを提供します。

選択は二者択一ではありません。私たちのニュースルームの例で示されているように、最も洗練され効果的な LLM 対応システムは、多くの場合、両方のアプローチを組み合わせています。つまり、エージェントは A2A プロトコルを通じて調整と専門化を行いながら、MCP サーバーを通じてツールやリソースにアクセスします。このハイブリッド アーキテクチャは、MCP の標準化とエコシステムの利点に加えて、マルチエージェント システムの組織上の利点も提供します。これは、選択する必要が全くないかもしれないことを示唆している。単に両方を標準的なアプローチとして使うだけでよい。

開発者またはアーキテクトとして、両方のソリューションの最適な組み合わせをテストして決定し、特定のユースケースに適した結果を生み出すのはあなた次第です。それぞれのアプローチの長所、制限、適切な適用を理解することで、より効果的で保守性と拡張性に優れた AI システムを構築できるようになります。

デジタル ニュースルーム、顧客サービス プラットフォーム、リサーチ アシスタント、またはその他の LLM を利用したアプリケーションを構築する場合でも、調整ニーズ (A2A) とツール アクセス要件 (MCP) を慎重に検討することで、成功への道が開かれます。

参考資料

]]> https://www.elastic.co/search-labs/blog/a2a-protocol-mcp-llm-agent-workflow-elasticsearch https://www.elastic.co/search-labs/blog/a2a-protocol-mcp-llm-agent-workflow-elasticsearch Mon, 24 Nov 2025 00:00:00 GMT <![CDATA[Elasticsearch で A2A プロトコルと MCP を使用して LLM エージェント ニュースルームを作成する: パート I]]> はじめに

現在の LLM 対応システムは、単一モデルのアプリケーションから、専門のエージェントが連携して、現代のコンピューティングではこれまで不可能と思われていたタスクを達成する複雑なネットワークへと急速に進化しています。これらのシステムの複雑さが増すにつれて、エージェントの通信とツールへのアクセスを可能にするインフラストラクチャが開発の主な焦点になります。これらのニーズに対応するために、マルチエージェント調整用のAgent2Agent (A2A)プロトコルと、標準化されたツールおよびリソース アクセス用のModel Context Protocol (MCP) という2 つの補完的なアプローチが登場しました。

それぞれの機能をいつ、またいつ単独で、調和して使用するかを理解することは、アプリケーションのスケーラビリティ、保守性、および有効性に大きな影響を与える可能性があります。この記事では、専門の LLM エージェントが協力してニュース記事の調査、執筆、編集、公開を行うデジタル ニュースルームの実際の例を通して、 A2Aの概念と実装について説明します。

付属のリポジトリはここにあります。セクション 5 の最後の方で、A2A の実際の動作の具体的な例を検討します。

要件

リポジトリは、A2A エージェントの Python ベースの実装で構成されています。Flask には API サーバーが用意されているほか、ログ記録や UI 更新のメッセージをルーティングする Event Hub というカスタム Python メッセージング サービスも用意されています。最後に、ニュースルームの機能をスタンドアロンで使用するための React UI が提供されます。実装を容易にするために、すべてが Docker イメージ内に含まれています。マシンで直接サービスを実行する場合は、次のテクノロジがインストールされていることを確認してください。

言語とランタイム

  • Python 13.12 - コアバックエンド言語

  • Node.js 18+ - オプションのReact UI

コアフレームワークと SDK:

  • A2A SDK 0.3.8 - エージェントの調整と通信

  • Anthropic SDK - AI生成のためのClaude統合

  • Uvicorn - エージェントを実行するためのASGIサーバー

  • FastMCP 2.12.5+ - MCP サーバーの実装

  • React 18.2 - フロントエンドUIフレームワーク

データと検索

  • Elasticsearch 9.1.1 以上- 記事のインデックス作成と検索

Docker のデプロイメント (オプションですが推奨)

  • Docker 28.5.1 以上

セクション 1: Agent2Agent (A2A) とは何ですか?

定義とコアコンセプト

Agent2Agent (A2A) は、独立した LLM エージェント間の相互作用のための標準化されたプロトコルです。A2A は、すべてのタスクを処理する単一のモノリシック システムではなく、複数の専門エージェントが通信、調整、および連携して、単一のエージェントでは効率的に処理するのが困難、遅い、またはまったく不可能な複雑なワークフローを実現できるようにします。

公式仕様: https://a2a-protocol.org/latest/specification/

起源と進化

エージェント間通信、つまりマルチエージェント システムの概念は、数十年前に遡る分散システム、マイクロサービス、およびマルチエージェントの研究に根ざしています。分散型人工知能の初期の研究は、交渉、調整、共同作業ができるエージェントの基盤を築きました。これらの初期のシステムは、大規模な社会シミュレーション、学術研究、電力網管理に特化していました。

LLM が利用可能になり、運用コストが削減されたことで、Google や AI 研究コミュニティ全体の支援を受けて、マルチエージェント システムが「プロシューマー」市場で利用可能になりました。現在 Agent2Agent システムとして知られている A2A プロトコルの追加により、複数の大規模言語モデルが取り組みとタスクを調整する時代に合わせて特別に設計された最新の標準へと進化しました。

A2A プロトコルは、LLM が接続して通信するインタラクション ポイントに一貫した標準と原則を適用することで、エージェント間のシームレスな通信と調整を保証します。この標準化により、異なる開発者のエージェントが、異なる基盤モデルを使用して、効果的に連携できるようになります。

通信プロトコルは新しいものではなく、インターネット上で行われるほぼすべてのデジタル取引に広く定着しています。https://www.elastic.co/search-labsと入力した場合この記事にアクセスするためにブラウザにログインすると、TCP/IP、HTTP トランスポート、DNS ルックアップ プロトコルがすべて実行され、一貫したブラウジング エクスペリエンスが保証される可能性が高くなります。

主な特徴

A2A システムは、スムーズな通信を確保するためにいくつかの基本原則に基づいて構築されています。これらの原則に基づいて構築することで、異なる LLM、フレームワーク、プログラミング言語に基づくさまざまなエージェントがすべてシームレスに対話できるようになります。

主な原則は次の 4 つです。

  • メッセージパッシング: エージェントは、明確に定義されたプロパティとフォーマットを持つ構造化されたメッセージを通じて通信します。

  • 調整: エージェントは、他のエージェントをブロックすることなく、タスクを互いに委任し、依存関係を管理することで、複雑なワークフローを調整します。

  • 専門分野: 各エージェントは特定のドメインまたは機能に焦点を合わせ、その分野の専門家となり、そのスキルセットに基づいてタスクの完了を提供します。

  • 分散状態: 状態と知識は集中化されるのではなくエージェント間に分散され、エージェントはタスクの状態と部分的な戻り値(成果物)の進捗状況を相互に更新する機能を持ちます。

ニュースルーム：実例

ジャーナリズムのさまざまな側面に特化した AI エージェントによって駆動されるデジタル ニュースルームを想像してみてください。

  • ニュースチーフ（コーディネーター/クライアント）：ストーリーを割り当て、ワークフローを監督する

  • 記者エージェント：調査やインタビューに基づいて記事を書く

  • 研究エージェント: 事実、統計、背景情報を収集します

  • アーカイブエージェント: Elasticsearchを使用して過去の記事を検索し、傾向を特定します

  • エディターエージェント: 記事の品質、スタイル、SEO最適化をレビューします

  • パブリッシャーエージェント: 承認された記事をCI/CD経由でブログプラットフォームに公開します。

これらのエージェントは単独では機能しません。ニュースチーフが再生可能エネルギーの導入についての記事を割り当てる場合、記者は統計を収集する研究者、草稿を確認する編集者、そして最終記事を公開する発行者を必要とします。この調整は A2A プロトコルを通じて行われます。

セクション2: A2Aアーキテクチャの理解

クライアントエージェントとリモートエージェントの役割

A2A アーキテクチャでは、エージェントは主に 2 つの役割を担います。クライアント エージェントは、タスクを策定し、システム内の他のエージェントに伝達する役割を担います。リモート エージェントとその機能を識別し、この情報を使用してタスクの委任について十分な情報に基づいた決定を下します。クライアント エージェントはワークフロー全体を調整し、タスクが適切に分散され、システムが目標に向かって進行することを保証します。

対照的に、リモート エージェントは、クライアントによって委任されたタスクを実行します。リクエストに応じて情報を提供したり特定のアクションを実行したりしますが、独自にアクションを開始することはありません。リモート エージェントは、割り当てられた責任を果たすために必要に応じて他のリモート エージェントと通信し、特殊な機能の共同ネットワークを作成することもできます。

私たちのニュースルームでは、ニュースチーフがクライアントエージェントとして機能し、レポーター、リサーチャー、エディター、パブリッシャーはリクエストに応答し、互いに調整するリモートエージェントとして機能します。

コアA2A機能

A2A プロトコルは、マルチエージェントのコラボレーションを可能にするいくつかの機能を定義します。

1. 発見

A2A サーバーは、クライアントが特定のタスクにいつどのようにサーバーを利用できるかがわかるように、その機能をアナウンスする必要があります。これは、エージェントの能力、入力、出力を記述する JSON ドキュメントであるエージェント カードを通じて実現されます。エージェント カードは、一貫性のあるよく知られたエンドポイント (推奨される/.well-known/agent-card.jsonエンドポイントなど) で利用できるようになり、クライアントはコラボレーションを開始する前にエージェントの機能を検出して照会できるようになります。

以下は、Elastic のカスタム アーカイブ エージェント「Archie Archivist」のエージェント カードの例です。Elastic などのソフトウェア プロバイダーは A2A エージェントをホストし、アクセス用の URL を提供していることに注意してください。

{ "name": "Archie Archivist", "description": "Helps find historical news documents in the Elasticsearch Index of archived news articles and content.", "url": "https://xxxxxxxxxxxxx-abc123.kb.us-central1.gcp.elastic.cloud/api/agent_builder/a2a/archive-agent", "provider": { "organization": "Elastic", "url": "https://elastic.co" }, "version": "0.1.0", "protocolVersion": "0.3.0", "preferred_transport": "JSONRPC", "documentationURL": "https://www.elastic.co/docs/solutions/search/agent-builder/a2a-server" "capabilities": { "streaming": false, "pushNotifications": false, "stateTransitionHistory": false }, "skills": [ { "id": "platform.core.search", "name": "platform.core.search", "description": "A powerful tool for searching and analyzing data within your Elasticsearch cluster.", "inputModes": ["text/plain", "application/json"], "outputModes": ["text/plain", "application/json"] }, { "id": "platform.core.index_explorer", "name": "platform.core.index_explorer", "description": "List relevant indices, aliases and datastreams based on a natural language query.", "inputModes": ["text/plain", "application/json"], "outputModes": ["text/plain", "application/json"] } ], "defaultInputModes": ["text/plain"], "defaultOutputModes": ["text/plain"] }

このエージェント カードでは、Elastic のアーカイブ エージェントのいくつかの重要な側面について説明します。エージェントは自身を「Archie Archivist」と名乗り、Elasticsearch インデックス内の過去のニュース文書の検索を支援するという目的を明確に述べています。カードはプロバイダー (Elastic) とプロトコル バージョン (0.3.0) を指定し、他の A2A 準拠エージェントとの互換性を確保します。最も重要なのは、 skills配列が、強力な検索機能やインテリジェントなインデックス探索など、このエージェントが提供する特定の機能を列挙していることです。各スキルはサポートする入力モードと出力モードを定義し、クライアントがこのエージェントと通信する方法を正確に理解できるようにします。このエージェントは Elastic の Agent Builder サービスから派生したもので、データ ストアからデータを取得するだけでなく、データ ストアと対話するためのネイティブ LLM 対応ツールと API エンドポイントのスイートを提供します。Elasticsearch の A2A エージェントへのアクセスについては、こちらをご覧ください。

2. 交渉

クライアントとエージェントは、適切なユーザー インタラクションとデータ交換を確保するために、コミュニケーション方法 (インタラクションがテキスト、フォーム、iframe、またはオーディオ/ビデオを介して行われるかどうか) について合意する必要があります。このネゴシエーションはエージェントのコラボレーションの開始時に行われ、ワークフロー全体にわたるエージェントの相互作用を管理するプロトコルを確立します。たとえば、音声ベースのカスタマー サービス エージェントはオーディオ ストリーム経由での通信をネゴシエートする可能性がありますが、データ分析エージェントは構造化された JSON を好む可能性があります。交渉プロセスにより、両当事者がそれぞれの能力と現在のタスクの要件に適した形式で情報を効果的に交換できるようになります。

上記の JSON スニペットにリストされている機能にはすべて入力スキーマと出力スキーマがあり、これらによって、他のエージェントからこのエージェントと対話する方法の期待値が設定されます。

3. タスクと状態の管理

クライアントとエージェントには、タスク実行全体を通じてタスクのステータス、変更、依存関係を通信するためのメカニズムが必要です。これには、タスクの作成と割り当てから進捗状況の更新とステータスの変更までのタスクのライフサイクル全体の管理が含まれます。一般的なステータスには、保留中、進行中、完了、失敗などの状態が含まれます。また、システムは、依存タスクが開始する前に前提条件となる作業が完了していることを確認するために、タスク間の依存関係を追跡する必要があります。エラー処理と再試行ロジックも重要なコンポーネントであり、システムが障害から正常に回復し、主な目標に向かって前進し続けることを可能にします。

タスクメッセージの例:

{ "message_id": "msg_789xyz", "message_type": "task_request", "sender": "news_chief", "receiver": "researcher_agent", "timestamp": "2025-09-30T10:15:00Z", "payload": { "task_id": "task_456abc", "capability": "fact_gathering", "parameters": { "query": "renewable energy adoption rates in Europe 2024", "sources": ["eurostat", "iea", "ember"], "depth": "comprehensive" }, "context": { "story_id": "story_123", "deadline": "2025-09-30T18:00:00Z", "priority": "high" } } }

このサンプル タスク メッセージは、A2A 通信のいくつかの重要な側面を示しています。

  • メッセージ構造には、一意のメッセージ識別子、送信されるメッセージの種類、送信者と受信者の識別、追跡およびデバッグ用のタイムスタンプなどのメタデータが含まれます。

  • ペイロードには実際のタスク情報が含まれており、リモート エージェントで呼び出される機能を指定し、その機能を実行するために必要なパラメータを提供します。

  • コンテキストセクションでは、受信側エージェントが広範なワークフローを理解するのに役立つ追加情報が提供されます。これには、エージェントがリソースを割り当てて作業をスケジュールする方法を示す期限や優先度レベルなどが含まれます。

4. コラボレーション

クライアントとエージェントは、動的かつ構造化されたインタラクションをサポートし、エージェントがクライアント、他のエージェント、またはユーザーに説明、情報、またはサブアクションを要求できるようにする必要があります。これにより、エージェントが最初の指示が曖昧な場合にフォローアップの質問をしたり、より適切な決定を下すために追加のコンテキストを要求したり、より適切な専門知識を持つ他のエージェントにサブタスクを委任したり、完全なタスクに進む前にフィードバック用の中間結果を提供したりできる共同作業環境が作成されます。この多方向のコミュニケーションにより、エージェントは孤立して作業するのではなく、継続的な対話に参加してより良い結果を得ることができます。

分散型ピアツーピア通信

A2A は、エージェントが異なる組織によってホストされ、一部のエージェントが社内で管理され、他のエージェントがサードパーティのサービスによって提供される分散通信を可能にします。これらのエージェントは、複数のクラウド プロバイダーまたはオンプレミスのデータ センターにまたがる可能性のある、さまざまなインフラストラクチャで実行できます。エージェントによっては、GPT モデルを活用したエージェント、Claude を活用したエージェント、オープンソースの代替手段を活用したエージェントなど、基盤となる LLM が異なる場合があります。エージェントは、データ主権の要件に準拠したり、待ち時間を削減したりするために、異なる地理的領域にまたがって動作する場合もあります。この多様性にもかかわらず、すべてのエージェントは情報を交換するための共通の通信プロトコルに同意し、実装の詳細に関係なく相互運用性を保証します。この分散アーキテクチャにより、システムの構築と展開に柔軟性が提供され、組織は特定のニーズに合わせて最適なエージェントとインフラストラクチャを組み合わせることができます。

これはニュースルーム アプリケーションの最終的なアーキテクチャです。

セクション3: モデルコンテキストプロトコル (MCP)

定義と目的

モデル コンテキスト プロトコル (MCP) は、Anthropic によって開発された標準化されたプロトコルであり、ユーザー定義のツール、リソース、プロンプト、その他の補足的なコードベースの追加機能を使用して個々の LLM を強化および強化します。MCP は、言語モデルと、タスクを効果的に完了するために必要な外部リソースとの間のユニバーサル インターフェイスを提供します。この記事では、ユースケース、新たなトレンド、Elastic 独自の実装の例を挙げて、MCP の現状を概説します。

MCPのコアコンセプト

MCP は、次の 3 つの主要コンポーネントを持つクライアント サーバー アーキテクチャで動作します。

  • クライアント: MCP サーバーに接続してその機能にアクセスするアプリケーション (Claude Desktop やカスタム AI アプリケーションなど)。

  • サーバー: 言語モデルにリソース、ツール、プロンプトを公開するアプリケーション。各サーバーは、特定の機能またはデータ ソースへのアクセスを提供することに特化しています。

    • ツール: モデルがデータベースの検索、外部APIの呼び出し、データに対する変換の実行などのアクションを実行するために呼び出すことができるユーザー定義関数

    • リソース:モデルが読み取り可能なデータ ソース。動的または静的データが提供され、URI パターン (REST ルートに類似) 経由でアクセスされます。

    • プロンプト:特定のタスクを実行するためにモデルをガイドする変数を含む再利用可能なプロンプト テンプレート。

リクエスト・レスポンスパターン

MCP は、REST API に似た、使い慣れた要求と応答の相互作用パターンに従います。クライアント (LLM) がリソースを要求するかツールを呼び出すと、MCP サーバーが要求を処理して結果を返します。LLM はこれを使用してタスクを続行します。周辺サーバーを備えたこの集中型モデルは、ピアツーピアのエージェント通信に比べて、よりシンプルな統合パターンを提供します。

ニュースルームのMCP

私たちのニュースルームの例では、個々のエージェントが MCP サーバーを使用して必要なツールとデータにアクセスします。

  • 研究者エージェントは以下を使用します:

    • ニュース API MCP サーバー (ニュース データベースへのアクセス)

    • ファクトチェックMCPサーバー（信頼できる情報源との照合による主張の検証）

    • 学術データベース MCP サーバー (学術論文と研究)

  • レポーターエージェントは以下を使用します:

    • スタイルガイド MCP サーバー (ニュースルームの執筆基準)

    • テンプレート MCP サーバー (記事テンプレートとフォーマット)

    • 画像ライブラリ MCP サーバー (ストック写真とグラフィック)

  • エディターエージェントは以下を使用します:

    • 文法チェッカーMCPサーバー（言語品質ツール）

    • 盗作検出MCPサーバー（独創性検証）

    • SEO分析MCPサーバー（見出しとキーワードの最適化）

  • Publisher Agent は以下を使用します:

    • CMS MCP サーバー (コンテンツ管理システム API)

    • CI/CD MCP サーバー (デプロイメント パイプライン)

    • Analytics MCP サーバー (追跡と監視)

セクション4: アーキテクチャの比較

A2Aを使用する場合

A2A アーキテクチャは、真のマルチエージェントコラボレーションを必要とするシナリオに優れています。調整を必要とする複数ステップのワークフローでは、特にタスクに複数の順次または並列ステップが含まれる場合、反復と改良が必要なワークフロー、およびチェックポイントと検証のニーズがあるプロセスの場合に、A2A から大きなメリットが得られます。私たちのニュースルームの例では、ストーリーのワークフローでは記者が記事を書く必要がありますが、特定の事実に対する信頼性が低い場合は研究者に繰り返し報告し、その後編集者に進み、最終的に発行者に渡す必要がある場合があります。

複数の領域にわたるドメイン固有の特化は、A2A のもう 1 つの強力な使用例です。より大きなタスクを達成するためにさまざまな分野の複数の専門家が必要であり、各エージェントがさまざまな側面に関する深いドメイン知識と専門的な推論機能を提供する場合、A2A はそれらの接続を行うために必要な調整フレームワークを提供します。ニュースルームはこれを完璧に例証しています。リサーチャーは情報収集、レポーターは執筆、編集者は品質管理を専門としており、それぞれが異なる専門知識を持っています。

自律的なエージェントの動作の必要性により、A2A は特に価値が高まります。独立した意思決定を行い、変化する状況に基づいて積極的な行動を示し、ワークフロー要件に動的に適応できるエージェントは、A2A アーキテクチャで成功します。特化された機能の水平スケーリングも重要な利点の 1 つです。単一の万能エージェントではなく、複数の特化エージェントが連携して動作し、同じエージェントの複数のインスタンスがサブタスクを非同期的に処理できます。たとえば、ニュースルームでニュース速報を取材しているとき、複数の記者エージェントが同時に同じニュースのさまざまな角度から取材することがあります。

最後に、真のマルチエージェントコラボレーションを必要とするタスクは A2A に最適です。これには、陪審員としての LLM 評価メカニズム、合意形成および投票システム、および最善の結果に到達するために複数の視点が必要となる共同問題解決が含まれます。

MCPを使用する場合

モデル コンテキスト プロトコルは、単一の AI モデルの機能を拡張する場合に最適です。単一の AI モデルが複数のツールやデータ ソースにアクセスする必要がある場合、MCP は、集中型の推論と分散ツール、および簡単なツール統合を組み合わせた完璧なソリューションを提供します。私たちのニュースルームの例では、研究者エージェント (1 つのモデル) は、ニュース API、ファクトチェック サービス、学術データベースなど、標準化された MCP サーバーを介してアクセスされる複数のデータ ソースにアクセスする必要があります。

ツール統合の広範な共有と再利用性が重要になる場合は、標準化されたツール統合が優先されます。MCP は、一般的な統合の開発時間を大幅に短縮する、事前に構築された MCP サーバーのエコシステムを備えているため、この点で優れています。シンプルさと保守性が求められる場合、MCP の要求応答パターンは開発者に馴染みがあり、分散システムよりも理解やデバッグが容易で、運用上の複雑さも少なくなります。

最後に、MCP は、システムとのリモート通信を容易にするためにソフトウェア プロバイダーによって提供されることがよくあります。プロバイダーが提供するこれらの MCP サーバーは、独自のシステムへの標準化されたインターフェースを提供しながら、オンボーディングと開発時間を大幅に短縮し、カスタム API 開発よりも統合をはるかに簡単にします。

両方を使用する場合 (A2A ❤️ の MCP)

MCP 統合に関する A2A ドキュメントに記載されているように、多くの高度なシステムは A2A と MCP を組み合わせることでメリットを得られます。調整と標準化の両方を必要とするシステムは、ハイブリッド アプローチに最適です。A2A はエージェントの調整とワークフロー オーケストレーションを処理し、MCP は個々のエージェントにツール アクセスを提供します。私たちのニュースルームの例では、エージェントは A2A を介して調整し、ワークフローは記者から研究者、編集者、そして発行者へと移行します。ただし、各エージェントは専用のツール用に MCP サーバーを使用するため、アーキテクチャが明確に分離されます。

ツール アクセスにそれぞれ MCP を使用する複数の特殊エージェントは、A2A によって処理されるエージェント調整レイヤーと、MCP によって管理されるツール アクセス レイヤーがある一般的なパターンを表します。このように関心事を明確に分離することで、システムの理解と保守が容易になります。

両方のアプローチを組み合わせることによる利点は非常に大きいです。特殊化、自律性、並列処理などのマルチエージェント システムの組織的な利点が得られると同時に、ツールの統合やリソース アクセスなどの MCP の標準化とエコシステムの利点も享受できます。エージェント調整 (A2A) とリソース アクセス (MCP) は明確に区別されており、重要なのは、API アクセスなどの小規模なタスクのみには A2A は必要ないことです。MCP は、マルチエージェント オーケストレーションのオーバーヘッドなしで、これらのタスクを効率的に処理します。

FAQ: A2A vs. MCP - ユースケース

機能

エージェント2エージェント（A2A）

モデルコンテキストプロトコル（MCP）

ハイブリッド（A2A + MCP）

主な目標

マルチエージェント調整: 専門エージェントのチームが、複雑な複数ステップのワークフローで連携できるようにします。

単一エージェントの拡張: 外部ツール、リソース、およびデータを使用して、単一の LLM/エージェントの機能を拡張します。

組み合わせた強み: A2A がチームのワークフローを処理し、MCP が各チーム メンバーにツールを提供します。

ニュースルームチームの例

ワークフロー チェーン: ニュース チーフ → レポーター → リサーチャー → 編集者 → 発行者。これは調整レイヤーです。

個々のエージェントのツール: スタイル ガイド サーバーとテンプレート サーバーにアクセスする Reporter Agent (MCP 経由)。これはツール アクセス レイヤーです。

完全なシステム: 記者は編集者 (A2A) と連携し、画像ライブラリ MCP サーバーを使用して記事のグラフィックを検索します。

いつどれを使うか

真のコラボレーション、反復、改良、または専門知識を複数のエージェントに分割する必要がある場合。

1 つのエージェントが複数のツールやデータ ソースにアクセスする必要がある場合、または独自のシステムとの標準化された統合が必要な場合。

マルチエージェント システムの組織的利点と、MCP の標準化およびエコシステムの利点が必要な場合。

コアベネフィット

自律性とスケーリング: エージェントは独立して決定を下すことができ、システムは特殊な機能の水平スケーリングを可能にします。

シンプルさと標準化: 集中化された推論によりデバッグと保守が容易になり、リソースに対する汎用的なインターフェースが提供されます。

関心事の明確な分離: システムを理解しやすくなります: A2A = チームワーク、MCP = ツール アクセス。

まとめ

これは、データとツールへのサポートと外部アクセスを提供するために MCP サーバーで強化された A2A ベースのエージェントの実装を扱った 2 部構成の最初のセクションです。次の部分では、実際のコードを調べて、オンライン ニュースルームのアクティビティをエミュレートするためにそれらが連携して動作する様子を示します。どちらのフレームワークも、それ自体で非常に有能で柔軟性に優れていますが、連携して動作することで、どれだけ互いを補完し合うかがわかります。

]]> https://www.elastic.co/search-labs/blog/a2a-protocol-mcp-llm-agent-newsroom-elasticsearch https://www.elastic.co/search-labs/blog/a2a-protocol-mcp-llm-agent-newsroom-elasticsearch Thu, 13 Nov 2025 00:00:00 GMT