👁️‍🗨️

サイロ化されてしまうAIエージェントを救う未来？ Google発の「Agent2Agent (A2A)」を探索してみた

に公開
Google
Microsoft
Model Context Protocol
Agent
A2A
tech

2025年4月のGoogle Cloud Next '25、AI関連の発表が盛りだくさんでしたね。

個人的に「これは面白そうだ！」と注目したのが、Agent2Agent (A2A) プロトコルの発表です。(本記事タイトルの出落ち感は否めませんが･･･)


図1: Google Cloud Next '25で発表されたAgent2Agentプロトコル

これまで別々の場所で、別々の言葉を話していたAIエージェントたちが、このA2Aという共通言語を使うことで、まるで人間のように「会話」し、協力してタスクを進められるようになる――。そんな可能性を秘めた、オープンなプロトコルが登場しました。

AIエージェントというと、どうしても特定のサービスやプラットフォームの中で完結しがちで、システム間の連携には頭を悩ませることも少なくありませんでした。A2Aは、その壁を壊し、もっと自由にエージェントたちが繋がれる世界を目指しているようです。

この記事では、このA2Aプロトコルが一体どんなもので、どんな仕組みで動き、我々ITエンジニアにとってどんな意味を持つのか、公式ドキュメントや発表内容、そして実際に簡単なデモを動かしてみた経験も交えながら、できるだけ噛み砕いて解説していこうと思います。

なぜ今、A2Aなのか？ エージェント連携の課題

ちょっと立ち止まって、これまでのシステム連携を振り返ってみましょう。アプリケーションの実行基盤は、物理サーバーから仮想化、そしてクラウド（IaaS）へと進化し、リソースの確保はずいぶん楽になりました。


図2: インフラ進化の概略

そして現在、AI、特にLLMを活用したエージェントが登場し、自律的に考え、ツールを使いこなすソフトウェアが現実のものとなりつつあります。クラウドでリソース確保は容易になりましたが、次の課題としてソフトウェア、特にこれらの自律的なAIエージェント間の連携が浮上してきました。

多くのエージェントは特定のLLMや開発フレームワーク、サービスの中で作られてきました。例えるなら、それぞれ独自の文化や言語を持つ国のようなもので、お互いに意思疎通を図るのが難しかったのです。個々のエージェントがどれだけ優秀でも、連携できなければその能力は限定的になってしまいます。

例えば、あるエージェントは最新の市場データを分析するのが得意でも、社内の基幹システムにアクセスできる別人事エージェントと直接対話できない。結果として、人間が間に入って情報をやり取りしたり、個別の連携システムを時間とコストをかけて開発したりする必要がありました。これでは、AIエージェントの真価を発揮させることはできません。


図3: サイロ化されたエージェント（直接連携がない状態）

GoogleがA2Aで目指すのは、まさにこの「言葉の壁」を取り払うことです。インターネットの世界でHTTPやJSONが果たした役割のように、AIエージェント間の共通語をオープンな仕様として定めることで、誰もが自由に、そして安全にエージェント同士を接続できるようにしよう、というわけです。これは、特定ベンダーによる囲い込みではなく、業界全体でAIエージェントのエコシステムを育てていこうという意思の表れとも言えるでしょう。

A2Aプロトコルの仕組み：エージェントたちの会話ルール

では、A2Aは具体的にどのようにエージェント間の会話を実現するのでしょうか？ その核心部分を見ていきましょう。

このプロトコルの背景には、Googleが掲げる5つの重要な設計原則があります。それは、

  1. エージェント自身の能力を活かす（Leverage agentic capabilities）
  2. Web標準技術を基盤とする（Build on existing standards）
  3. セキュリティを重視する（Secure by default）
  4. 長時間タスクを扱える（Support long-running tasks）
  5. 多様なデータ形式に対応する（Be modality-agnostic）

というものです。これらの原則が、これから説明する具体的な仕組みに反映されています。

基本的な考え方：クライアントとリモート

A2Aの通信モデルはシンプルで、基本的に「クライアントエージェント」と「リモートエージェント」という二者の役割に基づいています。

  • クライアントエージェントは、ユーザーからの指示を受け取ったり、タスクを開始したりする起点となります。そして、そのタスクを実行するために適切なリモートエージェントに依頼を出します。
  • リモートエージェントは、クライアントからの依頼を受けて、自身の専門知識やアクセス権限を活かして実際の処理（情報検索、計算、外部APIの実行、コンテンツ生成など）を行い、結果をクライアントに返します。

この二者が、タスクという単位で、決められたプロトコルに従って対話を進めていきます。


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

通信の技術基盤：馴染み深いWeb標準

A2Aは、魔法のような新技術の上に成り立っているわけではありません。むしろ、私たちWeb開発者にとって馴染み深い、実績のあるWeb標準技術を基盤としています。

  • 通信の土台となるのは HTTP/HTTPS です。
  • メッセージのやり取りには JSON-RPC 2.0 を採用しています[8]。これは軽量なリモートプロシージャコール（RPC）の規約で、メソッド呼び出し、パラメータ、結果、エラーなどの構造が明確に定義されています。これにより、エージェント間の「関数呼び出し」のようなやり取りを標準化できます。
  • LLMの応答のように、結果が少しずつ生成される場合や、時間のかかる処理の進捗を伝えたい場合には、Server-Sent Events (SSE) を利用したストリーミング通信もサポートされています[9]。

JSON-RPCメッセージの基本的な形は以下のようになります。

// リクエスト例: ドキュメント検索を依頼
{
  "jsonrpc": "2.0",
  "method": "searchDocuments", // 実行してほしい操作
  "params": { "query": "A2A protocol specs", "max_results": 3 }, // 操作に必要な情報
  "id": "req-xyz-1" // このリクエストを識別するID
}

// レスポンス例 (成功): 検索結果を返す
{
  "jsonrpc": "2.0",
  "result": [ // 操作の結果
    { "title": "Official A2A Protocol Documentation", "url": "https://google.github.io/A2A" },
    { "title": "A2A Announcement Blog Post", "url": "https://developers.googleblog.com/..." }
  ],
  "id": "req-xyz-1" // どのリクエストに対する応答かを示すID
}

// レスポンス例 (エラー): メソッドが見つからない場合
{
  "jsonrpc": "2.0",
  "error": { // エラー情報
    "code": -32601, // 標準的なエラーコード
    "message": "Method 'searchDocuments' not found."
  },
  "id": "req-xyz-1"
}

このJSONデータをHTTP POSTリクエストのボディに入れて送受信するのが基本です。非常にシンプルで、既存のWeb API開発の知識やインフラ（APIゲートウェイ、ロードバランサーなど）を流用しやすいのが利点ですね。

A2Aを支える主要なコンセプト

A2Aプロトコルが円滑なエージェント間連携を実現するために、いくつかの重要なコンセプトが定義されています。


図5: A2Aプロトコルの主要機能 (引用:[1])

1. 能力発見 (Capability Discovery) と エージェントカード (Agent Card)

クライアントエージェントは、どうやって無数に存在するかもしれないリモートエージェントの中から、自分のタスクに最適な相手を見つけるのでしょうか？ その答えが「エージェントカード」です。これは、各エージェントが持つJSON形式の「自己紹介カード」のようなものです。

エージェントカードの例 (抜粋)
{
  "a2a_version": "0.1.0",
  "agent_id": "DocumentQA-Agent",
  "display_name": "社内ドキュメントQAボット",
  "description": "社内ドキュメントに関する質問に回答します。",
  "capabilities": [
    {
      "name": "answer_question",
      "description": "ドキュメントに基づいて質問に回答する",
      "input_schema": { // ★ 入力仕様 (JSON Schema)
        "type": "object",
        "properties": {
          "question": { "type": "string", "description": "ユーザーからの質問" },
          "document_scope": {
            "type": "string",
            "enum": ["internal", "public"],
            "description": "検索対象ドキュメントの範囲"
           }
        },
        "required": ["question"]
      },
      "output_schema": { // ★ 出力仕様 (JSON Schema)
        "type": "object",
        "properties": {
          "answer": { "type": "string", "description": "生成された回答" },
          "source_documents": {
            "type": "array",
            "items": { "type": "string" },
            "description": "回答の根拠となったドキュメント"
          }
        }
      }
    },
    {
      "name": "summarize_document",
      "description": "指定されたドキュメントを要約する"
      // ... (スキーマ定義) ...
    }
  ],
  "supported_modalities": { // ★ 対応モダリティ
    "inputs": ["text/plain"], // テキスト入力のみ対応
    "outputs": ["text/plain", "text/markdown"] // テキストとMarkdown出力に対応
  },
  "authentication": [ // ★ 認証要件
    {
      "type": "oauth2",
      "flows": {
        "client_credentials": { // Client Credentials Grant フロー
          "token_url": "https://auth.example.com/token",
          "scopes": { // 必要なスコープ
            "read:internal_docs": "社内ドキュメントへの読み取りアクセス"
          }
        }
      }
    }
  ]
}

ここには、エージェントの名前、バージョン、開発元といった基本情報に加え、何ができるか（提供するメソッドや機能）、どんな種類のデータ（テキスト、画像、音声など）を入出力できるか（モダリティ）、守るべきルール（利用ポリシーやレート制限など）、必要な認証情報といった詳細が記述されています。特に capabilities では、各機能の入力（input_schema）と出力（output_schema）をJSON Schemaで厳密に定義できます。これは、まるでWeb APIの仕様書のように機能し、エージェント間で型安全なデータ交換を行うための基礎となります。
エージェント同士は、接続を確立する最初の段階（ハンドシェイク）でこのカードを交換します。これにより、相手の能力や制約を理解した上で、その後のコミュニケーションを進めることができます。「君はMarkdown形式で応答できるんだね (supported_modalities) 、じゃあその形式でお願いするよ」といった動的な調整が可能になります。


図6: エージェントカードの主要構造

2. タスク管理 (Task Management)

A2Aにおけるコミュニケーションの中心は「タスク」です。これは、単なる一往復のメッセージ交換ではなく、task_id によって識別され、明確なライフサイクル（例：PENDING, RUNNING, SUCCEEDED, FAILED）を持つオブジェクトとして管理されます。
タスクがすぐに完了しない場合、リモートエージェントはクライアントエージェントに対して進捗状況（例: RUNNING 状態の更新）を非同期に通知することができます（SSEストリーミングなど）。タスクが完了すると、その結果として「成果物 (artifact)」が生成されることがあります。この artifacts は、タスクIDに紐づいた結果データを保持する配列で、単なるテキストだけでなく、ファイルへのURI、インラインの画像データ（Base64エンコードなど）、あるいは次のタスクに引き継ぐための構造化データなど、様々な形式を取ることができます。これはレポートファイル、生成されたコード、分析データのサマリーなど、タスクの種類によって様々です。


図7: タスクライフサイクルの簡単な状態遷移図

3. コラボレーション (Collaboration) を支えるメッセージ構造

タスク遂行の過程で、エージェントは複数のメッセージを交換し、協調して作業を進めます。A2Aのメッセージは、単なるテキスト応答だけでなく、よりリッチな情報を伝えるための構造を持っています。一つのメッセージの中に、複数の「パート (parts)」を含めることができ、それぞれのパートが異なる種類のコンテンツ（テキスト、画像データ、ファイルへのリンク、構造化データなど）を持つことができます。各パートにはMIMEタイプ（例: text/plain, image/png, application/json）が指定され、受け手はその種類に応じて適切に処理します。これにより、例えば「この画像について説明して」といったマルチモーダルな依頼や、「分析結果のテキストと、それを可視化したグラフ画像を一緒に送る」といった複雑な応答も、標準化された方法で実現できます。

例えば、テキスト解説と画像URIを含むメッセージは以下のようになります。

{
  "jsonrpc": "2.0",
  "method": "process_order_update", // タスク内でのメソッド呼び出し
  "params": {
    "task_id": "task-abc-123", // 関連するタスクID
    "parts": [ // 複数の情報パート
      {
        "mime_type": "text/plain",
        "content": "注文内容を確認し、関連する製品画像を添付しました。" // テキスト情報
      },
      {
        "mime_type": "image/png",
        "uri": "gs://my-bucket/product_images/item-xyz.png" // 画像ファイルへの参照 (URI)
      }
    ]
  },
  "id": "msg-xyz-789"
}

4. ユーザー体験のネゴシエーション (User Experience Negotiation)

個人的に、A2Aの設計思想がよく表れていると感じるのがこの点です。A2Aは、単なるバックエンド間の通信規約に留まらず、最終的にユーザーにどのように情報を提供するか、というUI/UXの側面まで考慮に入れています。
前述のメッセージパートの仕組みやエージェントカードの capabilities を使い、エージェントは互いに「どんな表現形式（例：テーブル表示、ボタン付きカード、地図表示）をサポートしているか」といった情報を伝え合うことができます。クライアントエージェント（UIに近い側）が「インタラクティブなチャートを表示できるよ」と能力を提示すれば、リモートエージェント（データ処理側）は可能な限りチャートに適した形式でデータを返す（例: application/vnd.chartjs+json のようなカスタムMIMEタイプでデータを返すなど）、といった協調が可能です。これにより、複数のエージェントが連携していても、ユーザーにとっては一貫性のある、最適なインターフェースで情報を受け取れる可能性が高まります。

セキュリティへの配慮

企業システムでの利用を考えると、セキュリティは最優先事項の一つです。A2Aプロトコルは、この点を強く意識して設計されています (設計原則の「Secure by default」)。

  • 通信経路は HTTPS で暗号化されることが前提です。
  • エージェント間の認証には、OAuth 2.0 (様々なフローに対応)、APIキー、mTLS（相互TLS認証） など、業界標準の方式を利用できます。OpenAPI Specificationで定義されている認証スキームとの互換性も考慮されています。
  • エージェントカードの authentication セクションには、サポートする認証方式や、必要な認証情報（例: トークンURL、必要なスコープ）を具体的に記述でき、接続時に相手に要求することができます。
  • 認可に関しても、エージェントカードで公開された能力 (capabilities) やポリシーに基づいて、クライアントはリモートエージェントが実行できる操作を判断したり、リモートエージェントはクライアントのリクエストが許可された権限（例: OAuthスコープ）の範囲内かを確認したりできます。

これにより、信頼できる相手とのみ安全に通信し、各エージェントが持つ権限の範囲内で適切に動作することを保証しやすくなります。監査ログの取得なども、このプロトコル基盤の上で実装することが考えられます。

実際に触ってみよう！ Pythonデモで体感するA2A

さて、理屈だけではイメージしにくい部分もあるかと思いますので、実際にA2Aのデモを動かしてみましょう。Googleは公式リポジトリ[4]でTypeScriptとPythonのリファレンス実装を提供しています。ここでは、クラスメソッドさんのブログ記事[7]でも紹介されているPython版を使って、簡単なやり取りを試してみます。

公式リポジトリ:
https://github.com/google/A2A

Pythonデモの全体像


図8: サンプルdemoの全体像(引用:[4])

実際に動かしていく前に､ぜひこの上の図8を吟味してほしいです｡

ほぼこの図で､ここまで書いてきたA2Aのアーキテクチャや思想が透けて見えてくるんじゃないかと思います｡

セットアップ

では､早速デモを動かしていきましょう｡
今回動かすのは､以下の3つのフレームワークで作成されたエージェントをA2AでHostエージェントから動かしていきます｡

0. 前提

uvがすでに入っていること､uvにてPython3.13系が入っていることを前提で以下を進めていきます｡

参考にMac+brew環境でのuvに関するセットアップを示します｡

uv関係の下準備
brew install uv
uv python install 3.13
uv python pin 3.13

1. ローカル側の準備

続いて､リポジトリをローカルの任意の場所にクローンします｡

git clone https://github.com/google/A2A.git
cd A2A/samples/python # Python実装のディレクトリへ移動

そして､Pythonの仮想環境を準備していきます｡

uv仮想環境準備&アクティベート
uv venv
source .venv/bin/activate

次に､GeminiのAPIキーを.envファイルにコピーします｡

APIキー準備
echo "GOOGLE_API_KEY=your_api_key_here" > .env

これでセットアップは完了です｡続いて､A2Aサーバ側の各Agentを順次起動していきましょう｡

2. A2Aサーバ側の各Agentの起動:LangGraph

まずは､LangGraph側のエージェントを起動させます｡以下のコマンドで起動できます｡
デフォルトだと､ポート10000で起動されます｡

LangGraphエージェントの起動
cd agents/langgraph
uv run .

参考程度ですが､もし任意のポート番号(以下の例では10000)で起動させたい場合は､以下のコマンドとなります｡

uv run . --host 0.0.0.0 --port 10000

このエージェントでできることとしては､簡単にまとめると以下となります｡詳しくは､READMEをご参照ください｡

  • 自然な会話で通貨換算
  • 足りない情報は聞き返す: もし金額や通貨の種類を言い忘れても、「どの通貨に換算しますか？」のように、エージェントが聞き返す
  • リアルタイムな情報: 外部のAPI（Frankfurter API）と連携し、常に最新の為替レートで計算
  • 途中の状況も教えてくれる

また､疎通確認として別のセッションから以下のコマンドで､このエージェントのメタデータ=Agent Cardを取得できます｡

curl http://0.0.0.0:10000/.well-known/agent.json

正常に動作していれば､以下のようにこのエージェントのAgent Cardを取得できます｡

出力例
{
	"name": "Currency Agent",
	"description": "Helps with exchange rates for currencies",
	"url": "http://localhost:10000/",
	"version": "1.0.0",
	"capabilities": {
		"streaming": true,
		"pushNotifications": true,
		"stateTransitionHistory": false
	},
	"defaultInputModes": [
		"text",
		"text/plain"
	],
	"defaultOutputModes": [
		"text",
		"text/plain"
	],
	"skills": [
		{
			"id": "convert_currency",
			"name": "Currency Exchange Rates Tool",
			"description": "Helps with exchange values between various currencies",
			"tags": [
				"currency conversion",
				"currency exchange"
			],
			"examples": [
				"What is exchange rate between USD and GBP?"
			]
		}
	]
}

続いて､動作確認として現在のドル円は何円か?を以下のコマンドを通してエージェントに聞いてみましょう｡

curl -X POST \
  http://localhost:10000 \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 12, 
    "method": "tasks/send",
    "params": {
      "id": "130", 
      "sessionId": "8f01f3d172cd4396a0e535ae8aec6687", 
      "acceptedOutputModes": [
        "text"
      ],
      "message": {
        "role": "user",
        "parts": [
          {
            "type": "text",
            "text": "1ドルは何円ですか？"
          }
        ]
      }
    }
  }'

すると以下のような結果が返ってくると思います｡

出力例
{
	"jsonrpc": "2.0",
	"id": 12,
	"result": {
		"id": "130",
		"sessionId": "8f01f3d172cd4396a0e535ae8aec6687",
		"status": {
			"state": "completed",
			"timestamp": "2025-04-14T01:21:45.869476"
		},
		"artifacts": [
			{
				"parts": [
					{
						"type": "text",
						"text": "1ドルは142.84円です。"
					}
				],
				"index": 0
			},
			{
				"parts": [
					{
						"type": "text",
						"text": "1ドルは142.84円です。"
					}
				],
				"index": 0
			}
		],
		"history": []
	}
}

3. A2Aサーバ側の各Agentの起動:CrewAI

この調子でCrewAIエージェントを起動していきましょう｡先程のLangGraphエージェントと流れは全く一緒です｡別のターミナルウィンドウを開いて以下を実行します｡

CrewAIエージェントの起動
cd agents/crewai
uv run .

このエージェントについては詳しくは､READMEをご参照ください｡

疎通確認や動作確認は割愛します｡

4. A2Aサーバ側の各Agentの起動:Google Agent Development Kit

最後にGoogle ADKエージェントを起動していきましょう｡

Google ADKエージェントの起動
cd agents/google_adk
uv run .

LangGraphエージェントのときに載せるのを忘れてしまいましたが､疎通確認としてAgent Cardの取得をすると､以下のようにエージェント実行ターミナル画面上では､200となります｡

INFO:     Started server process [88672]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://localhost:10002 (Press CTRL+C to quit)
INFO:     127.0.0.1:58064 - "GET /.well-known/agent.json HTTP/1.1" 200 OK

このエージェントについては詳しくは､READMEをご参照ください｡

5. デモアプリの実行

ようやく､デモアプリの実行まできました｡あともう一息です｡

今一度､全体像の確認のために図8を再掲しておきます｡

図8: サンプルdemoの全体像(引用:[4])

以下のコマンドを実行すると､http://localhost:12000にて､デモアプリのUIへとアクセスできます｡

cd demo/ui
echo "GOOGLE_API_KEY=your_api_key_here" > .env
uv run main.py

アクセスしてみますと､以下のような画面が表示されます｡


図9: サンプルdemoアプリUI

6. 2-4で作成した各エージェントの登録

以下の画像内の①Remote Agentのアイコンを押下し､ここまで作成してきたA2A Server側のエージェントを画像内の②から追加していきます｡


図10: Remoteエージェント登録管理画面

2-4で作成した各エージェントのポート番号を以下の画像のように､それぞれ入力して登録していきます｡

上記の2-4の手順においてデフォルトのポートを使用している場合は登録する入力値は以下となります｡(任意のポート番号で各エージェントを起動している場合は適宜変更してください｡)

  • localhost:10000
  • localhost:10001
  • localhost:10002


図11: Remoteエージェント登録画面

7. Let`t play!

それでは早速､実際にデモアプリを動かしていきましょう!
左メニューから「Home」を押下し、Conversationを押下すると、Hostエージェント達とチャットをすることができます｡

以下がその様子です｡
以下のように2タスク依頼すると､いい感じにエージェント間で協調して2タスク同時に実行してくれたみたいです｡


図12: チャット実演画面

上記の会話について､左メニューから「Event List」を押下してみて､実際にどういった挙動をしたのかイベントログで確認してみましょう｡


図13: イベントログ画面

デモからわかること

この簡単なデモだけでも、A2Aの基本的なコンセプトが体感できます。

  • クライアントとリモート（サーバー）という役割分担があること。
  • HTTPとJSON-RPCという標準技術で通信が行われていること。
  • エージェントは特定のクラスとして実装され、サーバー側で差し替え可能であること。
  • リファレンス実装を使えば、プロトコルの詳細を完全に理解していなくても、エージェント間の基本的なやり取りを比較的容易に構築できること。

もちろん、これは非常に単純な例です。実際の応用では、もっと複雑なタスク管理、非同期処理、マルチモーダルデータの扱い、エラーハンドリング、セキュリティ設定などが必要になりますが、その基礎となる通信の仕組みは、このデモで確認できた流れに基づいています。

A2Aがもたらす未来：協調するAIの世界

A2Aが広く普及した場合、私たちの開発やビジネス、あるいは日常生活にどのような変化をもたらす可能性があるでしょうか？

可能になること：より賢く、柔軟なAI連携

A2Aの最大の価値は、専門性や得意分野の異なるAIエージェントたちが、あたかも人間の専門家チームのように連携できるようになる点です。

  • 複雑な業務プロセスの自動化として､例えば、顧客からの問い合わせに対し、まず内容を理解するエージェントが対応し、次に製品知識を持つエージェントが回答案を作成、最後に顧客情報DBにアクセスできるエージェントが過去の対応履歴を踏まえて回答をパーソナライズする、といった連携が考えられます。
  • 企業やシステムの壁を越えた連携として､パートナー企業の在庫確認エージェントに、自社の販売予測エージェントが直接問い合わせて発注量を調整する、といったサプライチェーン全体の最適化も夢ではありません。
  • より自然で統合されたユーザー体験として､ユーザーは、背後で複数のエージェントが動いていることを意識することなく、あたかも一つの非常に賢いアシスタントと対話しているかのような体験を得られます。A2AのUXネゴシエーション機能が、その一貫性を担保する役割を果たします。

これは、「一つの万能AI」に全てを依存するのではなく、多様なAIの「集合知」を活用するアプローチと言えます。それぞれのAIが得意なことに集中できるため、より効率的で、質の高い結果が期待できます。

他の技術との関係：競争か、協調か？

A2Aが唯一の連携プロトコルというわけではありません。類似の目的を持つ他の技術や取り組みも存在します。

AnthropicのMCP (Model Context Protocol)

MCP自体は主にアプリケーション（クライアント）とLLM本体との間のやり取り（コンテキスト情報や利用可能なツールの提示など）を標準化することに焦点を当てています。エージェント同士の横連携を目指すA2Aとは補完的な関係にあり、両者を組み合わせて使うことも可能です。GoogleのVertex AI ADKもMCPをサポートしています[2]。つまり、MCPで垂直統合（アプリケーション-モデル）を提供し、A2Aは水平統合（エージェント間）を提供するイメージで、MCPを使用して構築されたエージェントはA2Aを使用して他のエージェントと連携できるということが可能になるイメージと私としては解釈しています。

ちなみに、公式の以下のページがMCPとA2Aの違いをちゃんと解説してくれてます。
A2A and MCP

個人的には以下のツイート内の解説と図解が参考になりました。
https://x.com/Aurimas_Gr/status/1910671639869530502

そもそもMCPとはなんぞや?という方は以下の記事で解説していますのでご参照いただければ幸いです。(# PR)
https://zenn.dev/chips0711/articles/e71b088f26f56a
https://zenn.dev/chips0711/articles/ba72417a1f6c34

AGNTCY (Cisco, LangChainなど)

LangChainなどが参加する、A2Aと同様にエージェント間通信の標準化を目指すコンソーシアムです。LangChain自身はA2Aのパートナーでもあるため、将来的には標準仕様が一本化される可能性も考えられます。

https://agntcy.org/

Microsoft AutoGenなど

特定のフレームワーク内でエージェント間連携を容易にする機能を提供しています。これらはA2Aのようなオープンなプロトコルとは異なりますが、将来的にはA2Aのような標準プロトコルをサポートする可能性もあります。

現状では、どのプロトコルが最終的に業界標準となるかはまだ分かりません。しかし、Googleは他の標準化団体とも協力していく姿勢を示しており、A2Aが完全に閉じた規格になるのではなく、他の良いアイデアを取り込みながら進化していく可能性も十分にあります[5]。重要なのは、GoogleがA2AをGitHub上でオープンソースとして開発を進めており、仕様自体もコミュニティからのフィードバックを受けて進化させていく姿勢を見せている点です[1, 4]。IssueやPull Requestを通じて、誰でも仕様改善の提案や議論に参加できます。これは、A2Aが特定の企業にロックインされた技術ではなく、業界全体で育てていくオープンな標準を目指していることの表れと言えるでしょう。開発者としては、これらの動向を注視しつつ、まずは実績のある技術から試していくのが良さそうです。

エコシステムと将来展望

A2Aの成功は、技術的な優位性だけでなく、どれだけ多くの開発者や企業が参加するエコシステムを構築できるかにかかっています。Googleが発表時点で50社以上のパートナー（主要SaaSベンダー、AIスタートアップ、コンサルティングファームなど）を巻き込んでいる点は、その本気度を示しています[1]。


図14: A2A発表時のパートナー企業・組織 (引用:[1])

今後、これらのパートナー企業が自社のプラットフォームやサービスでA2Aをサポートし始めれば、具体的な活用事例が増え、採用が加速する可能性があります。Google自身もVertex AIのエージェント関連サービス群（Agentspace, Agent Builder, ADKなど）でA2Aを中核技術として位置づけており、自社サービスでの実装を推進しています[2]。

もちろん、課題もあります。他のクラウド大手（Microsoft, AWSなど）がA2Aにどう対応するかは大きな要素です。また、実際に企業が既存システムにA2Aを導入するには、セキュリティ、ガバナンス、運用体制など、技術的なプロトコル以外の側面も考慮する必要があります。例えば、多数のエージェントが存在する中で信頼できる相手をどう発見・選択するか、複数のエージェントが連携する際のデバッグや状態管理の複雑さ、プロトコルやエージェント自身のバージョンアップへの追従など、実際に導入・運用していく上では新たな課題も出てくるでしょう。

しかし、AIエージェントがますます高度化し、専門化していく中で、それらを連携させるための標準的な「共通言語」の必要性は高まる一方でしょう。A2Aは、そのニーズに応える有力な候補として、非常に大きなポテンシャルを秘めていると言えます。

長期的には、A2AはインターネットやWebサービスが実現したような、プログラム同士が自律的に連携し合う巨大なネットワークのAI版、つまり「エージェント・インターネット」のようなものを実現する基盤となるかもしれません[1]。そうなれば、人間はより創造的、戦略的なタスクに集中し、定型的な作業や情報収集はAIエージェントたちの連携に任せる、といった未来が訪れるかもしれません。

まとめ

GoogleのAgent2Agent (A2A) プロトコルは、乱立しがちなAIエージェントの世界に「共通言語」をもたらし、異なるエージェント同士の協調作業を可能にする、非常に野心的な取り組みです。

技術的には、JSON-RPCやHTTPといった枯れた技術をベースにしつつ、エージェントカードによる能力発見、タスク管理、マルチモーダル対応、UI/UXネゴシエーションといった、エージェントならではの要求に応える仕組みが盛り込まれています。

これが普及すれば、私たちはまるで優秀なアシスタントチームを抱えるかのように、複数のAIエージェントに複雑なタスクを任せられるようになるかもしれません。開発者としては、再利用可能なエージェント部品を作ったり、エージェントを組み合わせて新しい価値を生み出したりする、新たなチャレンジが待っていそうです。

もちろん、標準化競争の行方や、実際の普及度合いなど、まだ見えない部分も多くあります。しかし、Googleが多くのパートナーを巻き込み、オープンな形で進めようとしている姿勢には好感が持てます。
個人的には、このA2Aが、単なるバズワードではなく、本当にAIエージェント間の連携を促進し、私たちの開発やビジネスに大きなインパクトを与える技術になることを期待しています。今後の動向を引き続きウォッチしていきたいですね！

参考文献

  1. Google Developers Blog: Announcing the Agent2Agent Protocol (A2A)
  2. Google Cloud Blog: Build and manage multi-system agents with Vertex AI
  3. A2A Protocol Documentation (GitHub Pages)
  4. A2A GitHub Repository (Source code & Specs)
  5. VentureBeat: Google's Agent2Agent interoperability protocol aims to standardize agentic communication
  6. InfoWorld: Google's Agent2Agent open protocol aims to connect disparate agents
  7. クラスメソッド開発者ブログ: Google Cloud Next '25 で発表された AI エージェント間通信プロトコル Agent2Agent (A2A) を Python で試してみた
  8. JSON-RPC 2.0 Specification
  9. Server-Sent Events (MDN Web Docs)
免責事項

本記事は情報提供を目的としており、2025年4月14日時点の情報に基づいています。本記事について､内容の正確性・完全性は保証されず、誤りを含む可能性があります｡公式ドキュメントで最新情報をご確認ください。記事内のコードサンプルは自己責任でご利用ください。APIキー等の機密情報は適切に管理し、公開環境での使用時はセキュリティに十分ご注意ください。本記事内容の利用によって生じたいかなる損害（サービスの中断、データ損失、営業損失等を含む）についても、著者は一切の責任を負いません。本記事に掲載されている各社製品・サービスは各社の利用規約に従ってご利用ください。

Discussion