Elasticsearch で A2A プロトコルと MCP を使用して LLM エージェント ニュースルームを作成する: パート I

Agent Builder は現在、テクニカルプレビューとして利用可能です。Elastic Cloud トライアルを開始し、こちらでAgent Builderのドキュメントを確認してください。

はじめに

現在の 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) とは何ですか?

定義とコアコンセプト

公式仕様: 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 を提供していることに注意してください。

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

2. 交渉

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

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

3. タスクと状態の管理

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

タスクメッセージの例:

このサンプル タスク メッセージは、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 - ユースケース

まとめ

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