エージェント相互運用性のためのオープンプロトコル パート1:MCP上のエージェント間通信
Nick Aldridge、Marc Brooker、Swami Sivasubramanianによる 2025年5月19日 人工知能、生成AI、オープンソース、思想的リーダーシップ パーマリンク コメント シェア
AWSでは、オープンスタンダードが私たちのDNAに深く根付いており、すべての活動の原動力となっています。そのため、Amazon Elastic Cloud Compute(EC2)をプロトコルに依存しないクラウドコンピューティングサービスとして、Amazon SageMakerをフレームワークに依存しないディープラーニングサービスとして構築することを決定しました。エージェント型AI時代に入った今も、私たちのオープン性へのコミットメントはエージェント間通信にまで及んでいます。この機能を可能にする複数のプロトコルが登場しており、その中には2024年にAnthropicによってオープンソース化されたModel Context Protocol(MCP)や、今年Googleによって導入されたAgent2Agent protocol(A2A)が含まれます。私たちはMCPとA2Aの両方が多くの可能性を秘めていると考えています。これらのオープンスタンダードへのコミットメントを示すため、AWSはMCPの運営委員会に参加します。複数のプロトコルをサポートすることで、開発者が一つの標準に縛られることなく、画期的なエージェントアプリケーションを構築できるようにします。
オープンソースプロトコルはイノベーションを可能にする鍵となってきました。RESTやGraphQLなどのインターネットプロトコルから、TensorFlowやPyTorchなどのディープラーニングフレームワークまで、これらの標準は広範な開発と採用を可能にしてきました。現在、開発者がワークフローの自動化やインテリジェントな体験の創造のためにエージェントの協調を活用する中で、MCPやA2Aのような新しい標準が、LLM駆動のエージェントをツールや他のエージェントに接続するために登場しています。
AWSは、新しいサービス、オープンソースへの貢献、ベストプラクティスを通じて、開発者が相互接続された生成AI アプリケーションを構築するのを支援しています。最近、わずか数行のコードでAIエージェントを構築・実行するためのオープンソースSDKであるStrands Agentsをリリースしました。StrandsはAmazon Bedrock、Anthropic API、Llama API、Ollama、およびLiteLLMを通じた他のモデルなど、さまざまなモデルをサポートしています。MCPと連携し、近くA2Aや可観測性のためのOpenTelemetry(OTEL)もサポートする予定です。私たちは、エージェント型AIの可能性を最大限に引き出すには、オープンで相互運用可能な標準が不可欠だと考えています。
このブログ投稿は、これらの進歩の技術的詳細を掘り下げるシリーズの第一回です。MCPがどのようにエージェント間通信を可能にするかを探り、このパターンを簡素化するためのAWSの取り組みを紹介します。この投稿はMCPの進化に焦点を当てていますが、コードファーストのSDK、エージェント間通信、オープンな可観測性標準など、エージェント型AIの分野ではさらなる取り組みが必要だと考えています。エージェント型AIの進化する風景を引き続き探求していきますので、ご期待ください。
MCPの進化
開発者は、生成AIエージェントと外部システムを接続するための標準としてMCPを採用してきました。当初の焦点はツール統合でしたが、MCPのアーキテクチャはこれらの相互作用に必要な基本的な機能をすでに提供しているため、エージェントが他のエージェントと対話することも可能にします。当然のことながら、MCPコミュニティが自発的にプロトコルを進化させ、追加のエージェント間機能と抽象化を提供するよう貢献しているのを目にしています。
MCP上のエージェント間通信をさらに改善するために、AWSはMCPに貢献し、LangGraph、CrewAI、LlamaIndexなどの主要なオープンソースエージェントフレームワークと協力して、プロトコル上のエージェント間通信の未来を形作っています。また、Autodesk、Confluent、Dynatrace、Elastic、IBM、Workday、Writerなどの革新的な企業とも協力しており、これらの企業はMCP上で構築できるものの境界を押し広げ、コミュニティを集団的に前進させています。
強固な技術基盤の構築
MCPの核心には、柔軟性と拡張性が設計されており、ツール統合からエージェントの協力まで広がる基盤を作り出しています。MCPはすでに、複数の通信体制、認証/認可、機能交渉、コンテキスト共有など、エージェントが互いに通信するために必要な中核的なインフラストラクチャを提供しています。
柔軟な通信のためのストリーム可能なHTTP
マルチエージェント通信は、相互作用するエージェントの複雑さと設計に応じて、さまざまなパターンを取ることができます。MCPのストリーム可能なHTTP実装により、開発者は一から作り直す必要なく、豊富な相互作用パターンを利用できます。シンプルな一回限りのエージェント間のやり取りには、ステートレスなリクエスト/レスポンスフローを実装できます。より複雑な対話には、永続的なIDを持つステートフルなセッション管理により、複数のやり取りにわたってコンテキストが保持されます。
ストリーム可能なHTTPトランスポートは、Server-Sent Events(SSE)を使用したレスポンスストリーミングもサポートしており、リアルタイムのデータ交換が可能です。SSE上で、MCPは進捗通知、リクエストのキャンセル、クライアント切断中のレスポンスバッファリングをサポートしています。これらの機能は、継続的な更新を互いに共有する必要がある長時間実行エージェントの構築に最適です。
MCP機能の発見と交渉
エージェントが効果的に協力するためには、それぞれが相手の能力を理解する必要があります。MCPはこのニーズを機能発見機能で対応しています。エージェントが接続すると、セッション中に利用可能なプロトコル機能を交渉できます。この決定はサーバーレベルで行われますが、エージェントが互いに公開するツールやスキルなどの個々の機能にまで及びます。
各エージェントは、受け入れるパラメータとともに、その能力(ツールとしてモデル化)の詳細な説明を宣言できます。ツール通知システムにより、エージェントは新しい機能が利用可能になったり、既存の機能が変更されたりした場合に通知を受けることができます。この通知により、エージェントが互いの進化するスキルセットを発見し活用できる動的なエコシステムが形成され、時間とともに適応し、より有能になるネットワークが形成されます。
MCPセキュリティ
信頼とセキュリティは、効果的なエージェント協力の基盤を形成します。MCPはトランスポート層でOAuth 2.0/2.1ベースの認証と認可を実装し、エージェントが互いのアイデンティティを検証し、適切なアクセス制御を維持できるようにします。
コンテキスト共有
人間と同様に、エージェントも互いにコンテキスト(ファイル、アプリケーションの状態、エージェントのメモリ)を共有するための信頼性の高いメカニズムが必要です。MCPはリソース機能を使用して、エージェントが幅広いデータを共有できるようにします。MCPリソースを使用すると、エージェントは利用可能なコンテキストに関する情報を共有し、他のエージェントがそのコンテキストを取得できるようにします。MCPはまた、エージェントがリソースの変更に関する通知を購読できるようにし、開発者がエージェント間の依存関係を持つ洗練されたエージェント間ワークフローを実装できるようにします。
エージェントはプロンプトを互いに共有することもでき、さらにLLMも共有できます。この機能はサンプリングと呼ばれます。サンプリングはインタラクティブな支援の提供などのエージェントワークフローを可能にし、次のように機能します:
- サーバーがサンプリングリクエストをクライアントに送信する
- クライアントがリクエストを確認し、修正することができる
- クライアントがLLMからサンプリングする
- クライアントが完了を確認する
- クライアントが結果をサーバーに返す
MCP上のエージェント間通信の実装
詳細に入る前に、今日のMCPでエージェント間通信を実装する方法と関連するアーキテクチャコンポーネントを分解してみましょう。
画像1:MCPを使用したエージェント間相互作用の視覚化。
エージェント: エージェントはAIを使用してタスクを自律的に完了します。エージェントはしばしば、タスクの完了を支援するために外部データやサービス、または他のエージェントに依存しています。MCPはエージェントが外部データやサービスと対話できるようにする通信層を提供し、エージェントが他のエージェントと対話することも可能にします。
ツール/エージェントスキル: ツールはしばしばAPIやデータベースに対する操作を実行しますが、ツールはエージェントスキルやエージェントの特定の能力を実装することもできます。これらのエージェント型ツールは内部的にエージェントを呼び出して、受信したリクエストを処理します。
MCPサーバー: MCPサーバーは受信したリクエストを処理し、適切なツール/リソースメソッドにルーティングし、結果を呼び出し元に返します。
MCPクライアント: MCPクライアントはMCPサーバーと通信する方法を提供します。エージェントはエージェントのタスク完了を支援するために、MCPクライアントを使用してMCPサーバーに接続することがあります。例えば、エージェントはMCPクライアントを呼び出し、ツールをトリガーするためにCallToolRequestを開始することができます。MCPクライアントは接続しているMCPサーバーに対してCallToolRequestを開始します。
人事(HR)の従業員が従業員のスキルについてHRエージェントに質問する簡略化された例を考えてみましょう。HRエージェントはユーザーの質問に答えるために、別のエージェントである従業員情報エージェントに依存しています。
画像2:HRエージェント(エージェント1)が従業員データ管理エージェント(エージェント2)と対話するシーケンス図。
Spring AIを使用してこのアーキテクチャをJavaで構築する方法を見てみましょう。まず、従業員データベース用のデータを公開するMCPサーバーがあるとします。これで従業員データベースMCPサーバーからのツールを使用するエージェント(従業員情報エージェント)を構築できます:
@Bean
ChatClient chatClient(
List<McpSyncClient> mcpSyncClients,
ChatClient.Builder builder
) {
return builder
.defaultToolCallbacks(
new SyncMcpToolCallbackProvider(mcpSyncClients)
)
.build();
}
...
// MCPツール呼び出しを行い、フローにシステムプロンプトを追加するエージェント
String employeeInfoAgent(String query) {
return chatClient
.prompt()
.system("abbreviate first names with first letter and a period")
.user(query)
.call()
.content();
}
この例では、ChatClientがLLMへのインターフェースを提供し、ツール呼び出し(MCPを使用)を処理し、LLMとの必要なマルチターン会話を行います。
従業員情報エージェントを他のエージェントに公開するには、MCPサーバーツールでラップするだけです:
@Tool(description = "answers questions related to our employees")
String employeeQueries(
@ToolParam(description = "the query about the employees",
required = true) String query) {
return employeeInfoAgent(query);
}
これで従業員情報エージェントがMCPサーバーとして公開されたので、それをHRエージェントという別のエージェントと統合する方法を見てみましょう。HRエージェントがRESTエンドポイントとして公開されているとします。MCPを使用して従業員情報エージェントを使用するようにHRエージェントを設定できます。コードは単純に:
/* MCPサーバーの設定、例えばapplication.propertiesで:
spring.ai.mcp.client.sse.connections.employee_root.url=${mcp-
service.url:http://localhost:8081}
*/
// MCPを介して従業員情報エージェントを使用するように設定されたLLMチャットクライアント
@Configuration
class ConversationalConfiguration {
@Bean
ChatClient chatClient(List<McpSyncClient> mcpSyncClients, ChatClient.Builder builder) {
return builder
.defaultToolCallbacks(new SyncMcpToolCallbackProvider(mcpSyncClients))
.build();
}
}
record Prompt(String question) { }
@RestController
class ConversationalController {
private final ChatClient chatClient;
ConversationalController(ChatClient chatClient) {
this.chatClient = chatClient;
}
@PostMapping("/inquire")
String inquire(@RequestBody Prompt prompt) {
return chatClient
.prompt()
.user(prompt.question())
.call()
.content();
}
}
これがSpring AIとMCPでエージェント間通信を行うために必要なすべてです。もちろん、他の言語やエージェントフレームワークを使用したり、技術を組み合わせたりすることもできます。
MCPサーバーとして公開されるエージェントは、MCPを共通のプロトコルとして活用し、エージェント同士を分離するマイクロサービスのようなアーキテクチャを提供します。完全な動作例はこちらで入手できます。
エージェント間協力のためのMCPの強化
既存の基盤の上にMCPを進化させることで、MCP上でエージェント間の相互作用を構築する体験をさらに向上させることができると考えています。AWSとMCPコミュニティの残りのメンバーは、エージェント間の相互作用を強化するための適切な投資を定義するための活発な議論に参加しています。以下はほんの一部です:[議論] [議論] [議論]。提案された強化(AWS主導の提案を含む)には以下が含まれます:
- ヒューマンインザループ相互作用。MCPサーバーがエンドユーザーからより多くの情報を要求できるようにする「引き出し」を導入するためのMCP仕様とPython SDKの更新。[仕様PR] [実装PR]
- 部分的な結果のストリーミング。長時間実行リクエストを処理しているサーバーが部分的な結果を提供できるようにするためのMCP仕様とPython SDKの更新。注:中間結果はすでにSSEを介してサポートされています。[仕様PR] [実装PR]
- 強化された機能発見。ツール/エージェントスキルが出力スキーマを宣言し、ツール/エージェントスキルに追加の機能メタデータを組み込むことを可能にするためのMCP仕様とPython SDKの更新。[仕様PR] [実装PR] [仕様PR]
- 非同期通信。非同期通信、共有状態、クライアントポーラー駆動のステータスチェックのためのよりシンプルな抽象化をサポートするためのMCP仕様の更新。[仕様PR]
私たちはシームレスなエージェント間協力という目標にコミットしており、MCP上のエージェント間協力の未来を形作るために、この分野で積極的に活動している人々からのフィードバックを歓迎します。AWSからもこの分野でさらに多くの情報が提供される予定です。これはほんの始まりに過ぎません。
MCPは興奮と機会を生み出している
企業やテック・コミュニティ全体の開発者からのMCPに対する興奮は明らかです。生成AIでイノベーションを推進している多くのパートナーは、MCPをエージェント間通信のための選択プロトコルと見なしています。私たちは、MCPをオープンに改善するために協力し、互いに学び合うことができることに興奮しています。
「Confluentのリアルタイムデータストリーミングプラットフォームがツールとエージェントの間の接続組織として機能することで、MCPは前例のない相互運用性を実現します。AWSとMCPコミュニティと共に、自律型エージェントにリアルタイムコンテキストの完全な力をもたらす統一された標準を推進できることを誇りに思います。これにより、エージェント間の相互作用とデータ共有がシームレスになります。」 – Pascal Vantrepote、Sr. Director、Partner Innovation Engineering、Confluent
「CrewAIでは、スケーラブルで安全なエージェントエコシステムの基盤としてオープンスタンダードを長い間支持してきました。エージェントの相互運用性に関して複数のパターンが出現しているのを目にしており、まだ初期段階ですが、MCPが実際に牽引力を得ていることは明らかであり、このレイヤーの最終バージョンがどのようなものになるかを意味のある形で形作ると予想しています。統一されたMCPはエージェントの相互運用性に向けた重要なステップであり、AWSがMCPコミュニティでそれを前進させるのを嬉しく思います。エージェントシステムが成熟するにつれて、ベンダーやシステム間の協力が鍵となります。私たちは、柔軟性とオープン性を私たちが構築するすべてのコアとして、その未来に貢献することを約束します。」 – João Moura、創設者兼CEO、CrewAI
「BedrockとDynatraceを使用することで、顧客は自動修復、保護、自動化のためのスマートなエージェントシステムを構築できます。顧客は、これらのユースケースを構築するために、さまざまな商用MCP統合やオープンソースコミュニティの貢献から選択する柔軟性を持っており、すべてがエージェントの相互運用性によって可能になっています。」 – Alois Reitbauer、Chief Technical Strategist、Dynatrace
「Elasticは、組織がイノベーションを進めるためのオープンスタンダードの推進に取り組んでいます。ツール、リソース、エージェント間の相互運用性のための統一されたMCP標準は、統合を簡素化し、AI駆動アプリケーション全体でよりスマートな自動化を可能にすることで、顧客の成功を加速します。AWSとより広範なMCPコミュニティと協力して、アクセス可能でスケーラブルなAIを持つ未来を形作るのを嬉しく思います。」 – Steve Kearns、GVP and GM of Search、Elastic
「MCPはエージェントの風景を開放する機会を提供し、IBMはソフトウェアでエージェント相互運用性レイヤーとしてMCPを使用すると同時に、Watsonx OrchestrateなどのそのAI重視の製品にMCP機能を構築しています。AWSとより広範なMCPコミュニティと協力することを楽しみにしています。」 – Anant Jhingran、IBM Fellow & CTO、Software、IBM
「LinkedIn、Uber、Klarnaなどに採用されているLangGraphは、その制御可能性とステートフルなメモリレイヤーにより、開発者がエージェントを構築するための最も人気のある方法の一つです。オープンで相互運用可能であることはLangGraphの中核的な信条の一つであり、MCPのファーストクラスサポートを持つことにコミットしています - エージェントとツールの相互運用性を可能にします。」 – Harrison Chase、CEO of LangChain
「エージェントが知識労働の意味のある部分を自動化するためには、企業データを取り込み、合成し、行動を起こすための高品質なツールが必要です。MCPはエンタープライズにおけるエージェント型知識管理と相互運用性のこのビジョンにとって非常に重要だと考えており、AWSがAIエコシステム全体に利益をもたらすオープンで相互運用可能な標準を開発するためにコミュニティと協力することを嬉しく思います。」 – Jerry Liu、CEO of LlamaIndex
「Writerは、AWSとの成長する協力関係を構築し、企業でのMCPの開発に意味のある役割を果たすことを楽しみにしています。企業生成AIのリーダーとして、私たちはフォーチュン500企業にエンタープライズグレードのエージェントを提供するために必要な高い基準について深い理解を培ってきました。セキュリティと信頼性への注力が高まる中、MCPのようなオープンソースプロトコルが顧客のエージェント相互運用性を促進するために不可欠になると考えています。」 – Waseem AlShikh、CTO and Co-founder、Writer
「BroadcomのTanzu部門は、Javaの開発者にインテリジェントなアプリケーションを構築するための強力で使いやすいツールを提供することに専念しています。私たちのSpring AIチームはModel Context Protocol(MCP)の可能性をすぐに認識し、初期リリースからわずか16日後にサポートを提供し、私たちの実装を公式JavaSDKとして寄贈しました。MCPはインテリジェントで協調的なマルチエージェントシステム—自律型エージェントがユーザーの問題を解決するために通信し調整するアプリケーション—の基盤となる可能性があると考えています。MCPがJavaとSpringの開発者の多様なニーズを満たすように進化する中で、AWS、Anthropic、そしてより広範なコミュニティと協力することを楽しみにしています。」 -Ryan Morgan、Senior Director、Tanzu Division、Broadcom
MCP上のエージェント間通信の始め方
MCPが初めての方は、中核概念と機能を理解するために公式MCP文書を探索することから始めましょう。また、開発者が実装パターンを共有、質問をし、プロトコルの強化に協力するGitHubのコミュニティディスカッションに参加することもできます。コミュニティは活発でサポート的であり、初心者と専門家の両方がプロトコルの継続的な開発に貢献しています。MCP を使用してエージェント間アプリケーションの構築を開始するには、MCPクライアントとサーバーのセットアップのための入門ガイドに従ってください。また、AWS MCP 入門ガイドとサーバーデプロイメントガイドを参照して、AWS 上で MCP アプリケーションをすばやくセットアップする方法を確認することもできます。こちらは、このブログからの MCP エージェント間コードサンプルへのリンクです。
編集者注:Broadcom は公開後にこの投稿に引用を追加しました。
Nick Aldridge
Nick Aldridge は AWS のプリンシパルエンジニアです。過去 6 年間、彼は Amazon Lex や Amazon Bedrock を含む複数の AI/ML イニシアチブに取り組んできました。最近では、Amazon Bedrock Knowledge Bases を立ち上げるチームを率いました。現在は、エージェント間の協力と関数呼び出しに焦点を当てた生成 AI と AI インフラストラクチャに取り組んでいます。AWS 以前は、シカゴ大学で MS を取得しました。
Marc Brooker
Marc Brooker は AWS の VP 兼 Distinguished Engineer です。AWS での 16 年間で、Marc は EC2、EBS、Lambda に取り組み、最近では Aurora DSQL を立ち上げたチームを率いました。現在は、エージェント型 AI のインフラストラクチャと、大規模システムの可用性とセキュリティに焦点を当てています。AWS 以前は、ケープタウン大学で PhD を取得しました。

Swami Sivasubramanian
Swami Sivasubramanian は Amazon Web Services (AWS) のエージェント型 AI 担当バイスプレジデントです。AWS では、Swami は Amazon DynamoDB、Amazon SageMaker、Amazon Bedrock、Amazon Q などの主要な AI サービスの開発と成長を率いてきました。彼のチームの使命は、顧客とパートナーがエージェント型 AI を使用して自信を持ってイノベーションを行い、強力で効率的なだけでなく、信頼性と責任を持つエージェントを構築するために必要な規模、柔軟性、価値を提供することです。Swami はまた、2022 年 5 月から 2025 年 5 月まで、国家 AI イニシアチブに関連するトピックについて米国大統領と国家 AI イニシアチブオフィスに助言する任務を負った国家人工知能諮問委員会のメンバーを務めました。
Discussion