A2A と MCP: 新たなエージェントエコシステムのための 2 つの補完的プロトコル

本記事は元々 blog.logto.io に掲載されたものです。

AI エージェント — ユーザーに代わって推論と行動を行う自律的または半自律的なソフトウェアエンティティ — の採用が増えることで、アプリケーションアーキテクチャの新しい層が生まれつつあります。

2025年初頭、これに対処するために 2 つの異なるプロトコルが登場しました。A2A (Agent-to-Agent) と MCP (Model Context Protocol) です。その役割を理解するための簡単な方法は次のとおりです:

A2A: エージェント同士がどのように相互作用するか

MCP: エージェントがツールや外部コンテキストとどのように相互作用するか

reference: https://google.github.io/A2A/#/topics/a2a_and_mcp

これらは、複数のエージェント、複数の LLM、および複数のコンテキストソース が一緒に協力する必要があるシステム構築の根本的な課題に対処するものです。

これを「MCP は垂直統合 (アプリケーションからモデルへ) を、A2A は水平統合 (エージェントからエージェントへ) を提供します」と表現することができます。

あなたがデベロッパーであるかどうかにかかわらず、AI プロダクトやエージェンティックシステムを構築する誰もがその基礎となるアーキテクチャを理解するべきです。なぜなら、それが製品の設計、ユーザーインタラクション、エコシステム、長期的な成長を形作るからです。

この記事では、デベロッパーや AI プロダクトビルダーのために、これらのプロトコルを簡単かつ理解しやすく紹介し、重要なポイントを強調しています。

A2A (Agent-to-Agent) とは?

A2A (Agent-to-Agent) は Google と 50 を超える業界パートナーによって開発されたオープンプロトコルです。その目的は、エージェント間の相互運用性 を可能にすることです。誰がそれを構築したか、どこにホストされているか、どんなフレームワークを使用しているかに関係なくです。

A2A プロトコルのメカニズム

A2A は、通信メカニズムとして JSON-RPC 2.0 over HTTP(S) を使用し、**Server-Sent Events (SSE)**をサポートして更新をストリームします。

A2A 通信モデル

A2A は、2 つのエージェントがどのように相互作用するかの構造化されたモデルを定義します。1 つのエージェントが “クライアント”エージェント の役割を果たし、リクエストやタスクを開始し、もう 1 つが “リモート”エージェント としてリクエストを受け取り、実行しようとします。クライアントエージェントは最初に 能力の発見 を行い、どのエージェントが特定の仕事に最も適しているかを判断します。

では、エージェントはどのようにお互いを発見するのでしょうか。各エージェントは、自身の能力、スキル、API エンドポイント、認証要件を記述した エージェントカード (通常は /.well-known/agent.json のような標準 URL にホストされる JSON メタデータドキュメント) を公開することができます。

エージェントカードを読むことで、クライアントエージェントは、そのタスクに適したパートナーエージェントを特定でき、エージェントが知っていることやできることのディレクトリのようなものになります。一度目標となるエージェントが選ばれると、クライアントエージェントは タスク オブジェクトを送信するために作成します。

reference: https://google.github.io/A2A/#/

タスク管理

A2A のすべての相互作用は、タスクを実行することを中心に構築されています。タスクは、リクエストの詳細を含み、その状態を追跡する構造化されたオブジェクト (プロトコルのスキーマで定義) です。

A2A では、それぞれのエージェントが以下の 2 つの役割のどちらかを担います:

• クライアントエージェント: タスクを開始する
• リモートエージェント: タスクを受け取り、処理する

タスクには、レポートの生成、データの取得、ワークフローの開始など、あらゆる形態の作業を含めることができます。結果は アーティファクト として返され、エージェントは実行中の調整や明確化のために構造化された メッセージ を送信できます。

協力とコンテンツ交渉

A2A は単純なタスク要求以上のものをサポートします。エージェントはテキスト、JSON、画像、ビデオ、またはインタラクティブコンテンツを含む リッチで多パートなメッセージ を交換できます。これにより、各エージェントが処理または表示できる形式に基づいた 形式交渉が可能になります。

たとえば、リモートエージェントはグラフを生データとしてまたは画像として返すことができ、または対話型のフォームを開くように要求することができます。このデザインは柔軟で、モダリティに依存しない通信をサポートするものであり、エージェントが内部ツールやメモリを共有する必要がありません。

ユースケースの例

ここでは、A2A が企業シナリオでどのように使用されるかの 実際の例 を示します:

大企業で新しい従業員が雇用されています。複数のシステムと部門がオンボーディングに関与しています:

• 人事部は記録を作成し、歓迎メールを送信する必要があります
• IT 部門はラップトップと会社のアカウントを提供する必要があります
• 施設管理部門はデスクとアクセスバッジを準備する必要があります

従来、これらのステップは手動で処理されるか、内部システム間の密接に結合された統合を通じて処理されていました。

システムごとにカスタム API を作成する代わりに、各部門が A2A プロトコルを使用して独自のエージェントを公開します:

エージェント	責任
hr-agent.company.com	従業員記録の作成、文書の送信
it-agent.company.com	メールアカウントの作成、ラップトップの発注
facilities-agent.company.com	デスクの割り当て、アクセスバッジの印刷

複数のエージェントシステム — 例として OnboardingPro (例: onboarding-agent.company.com) — がオンボーディングワークフロー全体を調整します。

1. 発見: 各エージェントの .well-known/agent.json を読み取り、能力と認証を理解します。
2. タスクの委任:
   • HR エージェントに createEmployee タスクを送信します。
   • IT エージェントに setupEmailAccount と orderHardware を送信します。
   • 施設管理エージェントに assignDesk と generateBadge を送信します。
3. ストリーミング更新: エージェントはサーバー送信イベントを使用して進捗をストリームします (例: 「ラップトップが出荷されました」、「デスクが割り当てられました」)。
4. アーティファクトの収集: 最終結果 (例: PDF バッジ、確認メール、アカウントの資格情報) は A2A アーティファクトとして返されます。
5. 完了: OnboardingPro はオンボーディングが完了したことを採用マネージャーに通知します。

MCP(Model Context Protocol) とは?

MCP (Model Context Protocol) は、Anthropic によって開発され、外部アプリケーションがランタイムで言語モデルベースのエージェントに 構造化されたコンテキストとツール を提供する方法を解決します。

エージェント間の通信を促進するのではなく、MCP は コンテキストウィンドウ — LLM の作業メモリに焦点を当てています。その目標は:

• モデルの推論セッションに動的に関連するツール、ドキュメント、API 機能、またはユーザーステートを注入する
• プロンプトやロジックをハードコーディングせずにモデルが関数を呼び出したり、ドキュメントを取得したりできるようにする

MCP の主要アーキテクチャ

MCP を理解するには、まず全体的なアーキテクチャ — すべての部分が一緒になってどのように機能するかを理解する必要があります。

MCP ホスト: “あなたが話している AI”

MCP ホスト を AI アプリそのものと考えてください — Claude Desktop やあなたのコーディングアシスタントのようなものです。

それは、あなたが使用しているインターフェースであり — あなたがタイプまたは会話をする場所です。

モデルがより良い回答をするのを助けるために、ツールとデータを引き込もうと しています。

MCP クライアント: “コネクタ”

MCP クライアント は、あなたの AI ホスト (たとえば Claude) と外部世界とをつなぐソフトウェア部分です。それはスイッチボードのようなもので — それは異なる MCP サーバーと安全で 一対一 の接続を管理します。AI が何かにアクセスしたいとき、それはクライアントを通じて行います。

ChatGPT、Claude chat、または Cursor IDE のようなツールを MCP ホスト として考えると役立ちます — それらはあなたがインタラクトするインターフェースを提供します。舞台裏では、それらは MCP クライアント を使用して MCP サーバーを通じて異なるツールやデータソースに接続します。

refrence: https://modelcontextprotocol.io/introduction

MCP サーバー: “ツールプロバイダー”

MCP サーバー は、1 つの特定のツールまたは機能を公開する小さく焦点を当てたプログラムです — 例えば:

• コンピュータ上のファイルを検索する
• ローカルデータベースのデータを検索する
• 外部 API (天気、財務、カレンダーなど) を呼び出す

各サーバーは MCP プロトコルに従っており、AI がその能力と呼び出し方法を理解することができます。

ローカルデータソース: “自分のファイル & サービス”

一部の MCP サーバーは、自分のマシン上のものに接続します — 例えば:

• ドキュメントとフォルダ
• コードプロジェクト
• データベースまたはローカルアプリ

これにより、AI はデータをクラウドにアップロードせずに、検索、取得、または計算することができます。

リモートサービス: “API とオンラインツール”

他の MCP サーバーはインターネットに接続されています — それらは次のようなものと通信します:

• APIs (例: Stripe, Notion, GitHub)
• SaaS ツール
• クラウドの会社データベース

したがって、AI はたとえば「GitHub サーバーを呼び出して、オープン PR のリストを取得してください」と言うことができます。

MCP は現在、リモート MCP サーバーへの接続 をサポートしています。これは、MCP クライアントが より強力な能力 を獲得できることを意味します。理論上、

適切なセットの MCP サーバーを使用すると、ユーザーはすべての MCP クライアントを「すべてのアプリ」にすることができます。

reference: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

まとめ

では、すべての動作を図を使って見てみましょう。

1. あなたは AI に複雑なことを依頼します
2. AI (ホスト) は クライアント に支援を求めます
3. クライアントは適切な** MCP サーバー** を呼び出します — たとえば、ファイルをチェックしたり API をヒットしたりするもの
4. サーバーはデータを返したり、関数を実行したりします
5. 結果はモデルに戻され、タスクを完了するのを助けます

A2A vs MCP — 比較

カテゴリー	A2A (Agent-to-Agent)	MCP (Model Context Protocol)
主な目的	エージェント間のタスク交換を可能にする	LLM が外部ツールやコンテキストにアクセスできるようにする
対象	自律的エージェント間のコミュニケーション	推論中の単一エージェントの能力強化
焦点	マルチエージェントワークフロー、調整、委任	動的なツールの使用、コンテキストの拡充
実行モデル	エージェントがタスクとアーティファクトを送受信する	LLM が推論中にインラインでツールを選択して実行する
セキュリティ	OAuth 2.0、API キー、宣言的スコープ	アプリケーション統合レイヤーで処理
開発者の役割	エンドポイントを通じてタスクとアーティファクトを公開するエージェントを構築する	モデルが使用できる構造化されたツールとコンテキストを定義する
エコシステムパートナー	Google、Salesforce、SAP、LangChain など	Anthropic、ツールベースの LLM UI での新たな採用

それらが一緒に機能する方法

A2A と MCP は互いに補完的 です。多くのシステムでは、両方が一緒に使用されます。

ワークフローの例

1. ユーザーがエンタープライズエージェントインターフェースで複雑な要求を提出します。
2. オーケストレーティングエージェントが A2A を使用して専門的なエージェント (例えば、分析、人事、財務) にサブタスクを委任します。
3. これらのエージェントの 1 つが MCP を内部で使用して検索機能を呼び出したり、ドキュメントを取得したり、モデルを使用して何かを計算したりします。
4. 結果は A2A 経由でアーティファクトとして返され、モジュラーなツールアクセスを伴い、エージェント間の完全なコラボレーションが可能になります。

このアーキテクチャは エージェント間のコミュニケーション (A2A) と エージェント内の能力の呼び出し (MCP) を分離し、システムを簡単に構成、拡張、セキュリティ確保します。

結論

A2A は エージェントがネットワーク越しに他のエージェントと話すこと に関するものです — 安全に、非同期で、タスク中心に。

MCP は モデルセッションに構造化された能力を注入すること に関するもので、LLM がコンテキストに基づいてツールやデータを推論することができます。

一緒に使用することで、拡張可能で相互運用性のある多エージェントシステム をサポートします。

MCP と A2A の基盤インフラストラクチャが、将来のエージェント製品市場をどのように変えるか

最後に、このコア技術基盤が AI 市場の未来をどのように形作るか、そして AI 製品を構築する人々にとって何を意味するかについて話したいと思います。

人間とコンピュータの相互作用の変化

この変化の明確な例は、開発者とサービスのワークフローに見られます。MCP サーバーが IDE やコーディングエージェントに統合されることで、開発者がツールとやり取りする方法が基本的に変わりつつあります。

以前は、典型的なワークフローは、適切なサービスを検索し、ホスティングを設定し、ドキュメントを読み込み、API を手動で統合し、IDE でコードを書き、ローコードダッシュボードを通じて機能を構成するものでした。これは分散した体験であり、各ステップでコンテキストスイッチングと技術的なオーバーヘッドを伴っていました。

現在、MCP に接続されたコーディングエージェントを使用することで、その複雑さの多くを抽象化できます。開発者は、会話のプロンプトを通じてツールをより自然に発見し、使用できます。API の統合は、コーディングフロー自体の一部となり、通常は別の UI や手動の設定を必要としません。(ちょうど AWS やマイクロソフトのダッシュボードがどれほど複雑であるかを考えてみてください。) インタラクションはよりスムーズになり — 機能を組み立てるというよりは、動作をガイドするものです。

このモデルでは、ユーザーまたは開発者のインタラクションが機能の構成から行動のオーケストレーションにシフトします。これにより、プロダクトデザインの役割も変わります。

UI を使用して技術的な課題を「補う」 (例えば、「これはコード化が難しいので、設定パネルを作ろう」) のではなく、次のことを考える必要があります:

• エンドツーエンドの体験 について考える
• AI + ユーザーインタラクション がどのように、そしていつ結びつくべきかをデザインする
• AI がロジックを処理し、意図やフローを通じてユーザーをガイドする

課題は、AI とユーザーの入力がどのタイミングで結びつくべきかを決定し、適切なインタラクションを適切なタイミングで挿入し、AI がロジックを処理し、意図やフローを通じてユーザーをガイドすることです。

私は、開発者サービスと API 製品を例に挙げてユーザーインタラクションがどのように変わるかを示しましたが、同じことがビジネスソフトウェアにも当てはまります。長い間、ビジネスツールは複雑で使いにくいものでした。自然言語インタラクションは多くのワークフローを簡素化する可能性を秘めています。

エージェンティックプロダクトパラダイムと SaaS に与える影響

私たちは、MCP サーバー の増加を目にし始めています。Airbnb が 予約 MCP サーバー を提供したり、Google Maps が 地図 MCP サーバー を公開することを想像してみてください。

エージェント (MCP クライアントとして) は、これらのサーバーに同時に接続し、以前はカスタム統合やしっかりと結びついたアプリが必要だったワークフローをアンロックできます。

SaaS 時代では、統合は手動であったり固定的であることが多かったのに対して、このモデルはより自律的なワークフローと サービス間のフルードな接続 を可能にします。次の 2 つの例を挙げます:

1. ドキュメントからのデザイン

   あなたは Notion で PRD を書きます。Figma エージェントがそのドキュメントを読み取り、コアコンセプトをレイアウトしたワイヤーフレームを自動的に作成します — 手動の引き渡しは必要ありません。

2. エンドツーエンドの競合分析

   あなたが競合分析を依頼します。一連のエージェントがウェブを検索し (安全な認証を使用して)関連するサービスにサインアップし、結果を収集し、それを整理して Notion ワークスペースに戻します。

認証と認可の境界における課題

エージェント間の接続の増加と MCP クライアントから MCP サーバーへの接続の増加に伴い、エージェントが人間やユーザーの代わりに行動し、資格情報がこの旅を通じて安全に保持されなければならないため、認証と認可に関する多くの基礎的なニーズがあります。

これまでのところ、エージェント間の接続と MCP の新たな出現に固有のシナリオがいくつかあります。

1. エージェント vs SaaS & ウェブサイトアプリ
2. MCP クライアント (エージェント) vs MCP サーバー
3. ユーザー vs エージェント
4. エージェント vs エージェント

興味深いユースケースの 1 つは、Google によって言及された多重アイデンティティ連合(Google)です。

たとえば、ユーザー U が A エージェントとともに作業しており、A システムの識別子を必要としています。その場合、エージェント A はツール B またはエージェント B に依存しており、それが B システムの識別子を要求する場合、ユーザーは A システムと B システムの識別子を単一のリクエストで提供する必要があるかもしれません。(A システムは企業の LDAP アイデンティティであり、B システムは SaaS プロバイダーのアイデンティティであると仮定します)。

Logto は、AI 統合の未来に適した OIDC および OAuth プロバイダーです。

柔軟なインフラストラクチャを備えており、その機能を積極的に拡張しています。また、開発者が迅速に始められるように一連のチュートリアルを公開しています。

質問がありますか?

お問い合わせ — または Logto を使用して何が構築できるかを探ってください。