結論から言うと、A2Aプロトコルは「AIエージェント同士をつなぐための共通会話レイヤー」です。 MCPがエージェントからツールやデータソースを呼び出すための規約だとすれば、A2Aは別ベンダー、別フレームワーク、別部署で動くエージェント同士が、相手の内部実装を知らないまま依頼・進捗確認・成果物受け取りを行うための規約です。
この記事では、Googleが2025年4月に発表したAgent2Agent Protocol（A2A）と、A2A Projectの仕様ドキュメントをもとに、2026年時点で実装時に見るべき要点を整理します。公式情報では、A2Aは異なるベンダーやフレームワークで作られたエージェント間の相互運用性を高めるためのオープン標準として説明されています（Google Developers Blog、A2A Protocol Specification）。
ベンチマークの速度や「何倍速くなる」といった数字は、公式仕様には載っていません。なので本稿では性能数値を盛らず、導入判断に必要な設計パターン、境界、失敗例に絞ります。すぐ試せるコード例も載せますが、本番導入では認証、監査ログ、テナント分離、タスク保持期間を必ず自社要件に合わせてください。
A2Aプロトコルとは何か
A2Aプロトコルは、独立したAIエージェントシステムが互いの能力を発見し、タスクを依頼し、進捗や成果物をやり取りするためのアプリケーションレベルのプロトコルです。公式仕様では、A2Aの目的として、エージェントの能力発見、インタラクション方式の調整、共同タスク管理、そして相手の内部状態・メモリ・ツールへ直接アクセスせずに安全に情報交換することが挙げられています。
ここが重要です。A2Aは「すべてのエージェントを一つの巨大な脳にまとめる」規格ではありません。むしろ逆で、各エージェントをブラックボックスのまま扱います。請求書チェックエージェント、法務レビューエージェント、営業提案エージェントがそれぞれ別の技術スタックで動いていても、公開された入口と能力情報だけで連携できる状態を目指します。
公式のCore Conceptsでは、A2A Clientはユーザーの代わりに通信を開始する側、A2A ServerはHTTPエンドポイントを公開して依頼を受けるリモートエージェントとして整理されています（Core Concepts and Components in A2A）。社内実装に置き換えると、ポータルやチャットボットがClient、個別業務エージェントがServerになる構成が自然です。
すでにMCPやStructured Outputsを使っているチームほど、A2Aの位置づけを誤解しやすいです。MCPはエージェントが道具を使うための接続口、A2Aはエージェント同士が仕事を受け渡すための接続口。役割を混ぜると、権限境界が曖昧になり、監査ログも追いにくくなります。
まず押さえる構成要素：Agent Card、Task、Message
A2Aを読むときは、最初に三つだけ覚えれば十分です。Agent Card、Task、Messageです。Agent Cardは、エージェントの名刺です。名前、説明、対応プロトコル、URL、入力形式、出力形式、能力、スキル、認証方式をJSONで表します。クライアントはこの情報を見て、どのエージェントに何を頼めるかを判断します。
Taskは、依頼された仕事の単位です。A2Aは短い一問一答だけでなく、長時間動く処理、人間確認を挟む処理、途中成果物が増えていく処理を想定しています。そのため、結果だけを返すのではなく、タスクID、状態、履歴、成果物を持つ設計になります。Messageは、ユーザーやエージェントが送る会話・指示の単位です。Messageの中にtextやファイル、構造化データのPartを入れます。
この三つの関係を雑に言うと、Agent Cardで相手を見つけ、Messageで依頼し、Taskで進捗と成果物を管理します。AIエージェント連携でありがちな「どこまで処理したか分からない」「どのエージェントが何を返したか分からない」問題を、仕様側で扱おうとしているわけです。
既存のfunction callingだけで十分に見えるケースもあります。ただ、function callingは単一アプリ内の道具呼び出しには強い一方、別組織・別サービスのエージェントを発見して、タスクの状態を追い、ストリーミングやキャンセルまで共通化するには設計を足す必要があります。A2Aはその足りない部分を標準化する試みです。
5分で分かるAgent Cardの最小設計
社内でA2Aを試すなら、最初に作るべきものは高度な推論エージェントではなくAgent Cardです。Agent Cardを作ると、「このエージェントは誰に、何を、どの形式で、どの権限で提供するのか」が強制的に言語化されます。ここを飛ばして実装を始めると、あとで権限や責任範囲が崩れます。
以下は請求書チェック用の社内エージェントを想定した例です。公式サンプルのフィールド構造に寄せていますが、URLやスコープは架空のものです。本番では公開Agent Cardに出してよい情報と、認証後のExtended Agent Cardだけに出す情報を分けてください。
{
"name": "Invoice Review Agent",
"description": "請求書PDFを読み取り、差分確認と承認前チェックを行う社内エージェント",
"supportedInterfaces": [
{
"url": "https://agents.example.com/invoice/a2a/v1",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"version": "2026.05.1",
"capabilities": {
"streaming": true,
"pushNotifications": false,
"extendedAgentCard": true
},
"securitySchemes": {
"corp_oauth": {
"oauth2SecurityScheme": {
"authorizationUrl": "https://idp.example.com/oauth/authorize",
"tokenUrl": "https://idp.example.com/oauth/token",
"scopes": {"invoice.read": "請求書の参照"}
}
}
},
"security": [{"corp_oauth": ["invoice.read"]}],
"defaultInputModes": ["text/plain", "application/json"],
"defaultOutputModes": ["text/plain", "application/json"],
"skills": [
{
"id": "invoice-risk-check",
"name": "請求書リスクチェック",
"description": "請求書の金額、支払期日、契約書との差分を確認する",
"tags": ["invoice", "approval", "backoffice"],
"examples": ["この請求書を契約書と照合して、承認前の注意点を出して"]
}
]
}ポイントは、スキル名を人間向けに書くだけでなく、inputModesやoutputModes、認証要件までセットで考えることです。A2AのAgent Discoveryドキュメントでは、標準的な発見場所としてhttps://{agent-server-domain}/.well-known/agent-card.jsonが説明されています（Agent Discovery）。ただし、社内エージェントの全能力を公開カードに出す必要はありません。むしろ、敏感なスキルや内部システム名は認証後のカードに寄せる方が安全です。
この段階で「人事評価の要約」「顧客別粗利の分析」「未公開案件の提案書生成」のようなスキルが入るなら、公開範囲を見直してください。Agent Cardは便利ですが、能力一覧そのものが情報資産になります。
実装フロー：発見、選択、SendMessage、Task追跡
A2Aの実装フローは、複雑に見えても大枠は単純です。まずクライアントがAgent Cardを取得します。次に対応プロトコルとスキルを見て、依頼先として妥当か判断します。その後、SendMessageで依頼し、返ってきたTaskを追跡します。必要ならGetTask、ListTasks、CancelTask、SubscribeToTaskを使います。
まずはAgent Cardを取得して、目的のスキルがあるかを確認するクライアント側の最小例です。実際にはキャッシュ、署名検証、HTTPステータスごとのリトライ、認証付きExtended Agent Cardの扱いが必要です。
import requests
AGENT_DOMAIN = "https://agents.example.com"
card_url = f"{AGENT_DOMAIN}/.well-known/agent-card.json"
res = requests.get(card_url, timeout=10)
res.raise_for_status()
card = res.json()
bindings = card.get("supportedInterfaces", [])
jsonrpc = next(
(b for b in bindings if b.get("protocolBinding") == "JSONRPC"),
None,
)
if not jsonrpc:
raise RuntimeError("このエージェントはJSON-RPCバインディングを公開していません")
skills = {skill["id"]: skill for skill in card.get("skills", [])}
if "invoice-risk-check" not in skills:
raise RuntimeError("請求書チェックskillが見つかりません")
print("endpoint:", jsonrpc["url"])
print("skill:", skills["invoice-risk-check"]["name"])次に、JSON-RPCバインディングのSendMessageの例です。A2A仕様ではJSON-RPC、gRPC、HTTP JSON RESTなど複数のバインディングが整理されており、JSON-RPCではSendMessage、SendStreamingMessage、GetTaskなどのメソッドが定義されています。ここでは処理が長くなる前提でblockingをfalseにしています。
POST /a2a/v1 HTTP/1.1
Host: agents.example.com
Content-Type: application/json
Authorization: Bearer <access_token>
{
"jsonrpc": "2.0",
"id": "req-20260527-001",
"method": "SendMessage",
"params": {
"message": {
"role": "ROLE_USER",
"parts": [
{"text": "請求書ID inv_123 を契約書 ctr_456 と照合して、承認前の確認点を出して"}
]
},
"configuration": {
"blocking": false,
"historyLength": 5
}
}
}実務では、SendMessageの返却が直接Messageになる場合とTaskになる場合があります。単純な問い合わせなら直接回答で終わることもありますが、審査、集計、外部API待ち、人間承認を含む処理はTaskとして返し、状態を追えるようにした方が運用しやすいです。Taskが返った後は、画面側で「受付済み」「処理中」「入力待ち」「完了」「失敗」などを表示できます。
エラー処理も設計に入れておきます。公式仕様では、タスクが見つからない、アクセスできない、キャンセル不可、コンテンツタイプ非対応といったケースが整理されています。実装時は、ユーザーに見せるメッセージと監査ログに残す詳細を分けるのが安全です。とくに「存在しない」と「権限がない」を外部に明確に分けて返すと、リソース列挙の手がかりになる場合があります。
MCPとの違い：道具を使うか、相手に仕事を頼むか
A2AとMCPの違いは、設計レビューで必ず出る論点です。公式のA2A and MCPページでは、MCPはAIエージェントがデータベースやAPIなどの個別ツール・リソースを利用するためのもの、A2Aはエージェント同士が相互に発見し、タスクを管理し、文脈や成果物を交換するためのものとして説明されています（A2A and MCP）。
たとえば営業提案エージェントが社内CRMを読むならMCPが向いています。一方、営業提案エージェントが法務レビューエージェントへ「この契約条件を確認して」と依頼するならA2Aの領域です。前者は道具の呼び出し、後者は別の責任主体への仕事の委任です。
この違いを曖昧にすると、MCPサーバーが実質的に業務判断エージェントになったり、A2Aエージェントが内部ツールを過剰に公開したりします。権限設計の観点では、MCPはツール単位のスコープ、A2Aはエージェント単位・タスク単位のスコープで考えると整理しやすいです。MCP側の安全設定は、既存記事のMCP Tool Annotations実装｜安全な権限設計5設定も合わせて確認してください。
もう一つの実務的な判断基準は、相手が「状態を持つ仕事」をするかどうかです。単発の検索や変換ならMCPで十分です。長時間の調査、複数成果物、途中確認、キャンセル、再購読が必要ならA2Aを検討します。A2Aの強みは、会話というより「仕事の受け渡し」を扱える点にあります。
ストリーミングと非同期処理をどこまで使うか
A2Aは短い応答だけでなく、ストリーミングや長時間タスクを想定しています。公式仕様では、SendStreamingMessageによるServer-Sent Events、既存タスクへのSubscribeToTask、プッシュ通知設定などが整理されています。すべてを最初から実装する必要はありませんが、どの処理が同期で、どの処理が非同期かは最初に決めるべきです。
ユーザー体験の観点では、30秒以内に終わる単純処理なら同期でも構いません。複数ファイルを読む、外部システムをまたぐ、人間承認を待つ、夜間バッチに回す、といった処理はTask化して非同期にした方が安定します。画面やチャットUIでは、Task IDを持たせて後から状態を確認できるようにします。
ストリーミングを使うと、途中の進捗や部分成果物を見せられます。以下は公式仕様のJSON-RPCメソッド名に沿った最小イメージです。実際の本番環境では、SSEの再接続、イベント順序、途中切断、権限切れ、最終状態の再取得を必ずテストしてください。
# Server-Sent Eventsで進捗を受けたい場合の最小イメージ
curl -N
-H "Authorization: Bearer <access_token>"
-H "Content-Type: application/json"
-d '{
"jsonrpc":"2.0",
"id":"req-stream-001",
"method":"SendStreamingMessage",
"params":{
"message":{"role":"ROLE_USER","parts":[{"text":"月次レポートを作成して"}]}
}
}'
https://agents.example.com/invoice/a2a/v1非同期設計で特に大事なのは、再実行と重複実行の扱いです。ユーザーが同じ依頼を二回送ったときに、二重請求、二重メール送信、二重承認依頼が起きると事故になります。A2Aの仕様だけでは業務上の冪等性までは保証されません。タスク作成時に業務キーを持たせる、同一キーの処理中タスクを返す、最終成果物の生成を一回に制限する、といったアプリ側の設計が必要です。
権限設計：Agent Cardに書くこと、書かないこと
A2A導入で一番危ないのは、プロトコル実装そのものではなく権限境界です。Agent Cardにはエージェントの能力、エンドポイント、認証方式が載ります。便利だからといって、内部システム名、顧客セグメント、特権スキル、管理者向け操作を公開カードにそのまま出すと、攻撃者に地図を渡すことになります。
公開カードは最小限にし、認証済みユーザーだけが取得できるExtended Agent Cardに詳細スキルを出す構成を検討します。また、Taskの取得、一覧、キャンセル、購読では、必ず呼び出し元のテナント、ユーザー、スコープを確認します。A2A仕様のSecurity Considerationsでも、タスク関連操作に対する認可境界や、HTTPS、監査ログ、異常なタスク作成・キャンセルの監視が重要な観点として示されています。
# 疑似コード: A2Aリクエストの入り口で必ず見る境界
caller = verify_oauth_token(request.headers["Authorization"])
card = load_agent_card_for(caller)
if not caller.has_scope("invoice.read"):
raise PermissionDenied("invoice.read scope is required")
if request.method in ["GetTask", "ListTasks", "CancelTask", "SubscribeToTask"]:
task = task_store.get(request.params["id"])
if task.owner_tenant_id != caller.tenant_id:
raise TaskNotFoundOrNotAccessible()
log_security_event(
actor=caller.subject,
method=request.method,
task_id=request.params.get("id"),
decision="allow"
)この設計は、AIエージェントのガバナンス全体とも直結します。エージェントの権限、操作ログ、承認フロー、失敗時の責任分界は、プロトコル導入より先に決めるべきです。全体像はAIエージェント ガバナンス・権限設計2026でも整理しています。
もう一つの注意点は、Agent Cardのキャッシュです。Agent Cardは頻繁に変わるものではありませんが、スキル追加や認証要件変更があるとクライアント側の見え方が変わります。HTTPキャッシュを使う場合も、権限変更時に古いカードが残って危険なUIを出さないよう、短いTTL、バージョン、条件付きリクエスト、セッション単位のキャッシュ破棄を設計に入れてください。
社内導入の設計パターン3つ
一つ目は、業務ポータルをA2A Clientにするパターンです。ユーザーは一つのポータルから依頼し、裏側で請求書、法務、営業、調査の各エージェントへ仕事を振り分けます。既存のSlackボットや社内チャットを入口にする場合も同じです。ユーザーから見ると一つの窓口ですが、実際には複数のA2A Serverが独立して動きます。
二つ目は、専門エージェント同士の委任パターンです。たとえば提案書エージェントが市場調査エージェントへ調査を依頼し、法務レビューエージェントへ契約文言確認を依頼します。この場合、エージェント間の責任範囲を明確にしないと、誤回答の責任が曖昧になります。Taskのメタデータに依頼元、依頼先、目的、入力データの出どころを残すと追跡しやすくなります。
三つ目は、外部ベンダー連携パターンです。自社エージェントが外部の専門エージェントへ限定的に依頼する構成です。ここでは公開Agent Card、OAuth、監査ログ、データ最小化、契約上のデータ処理条件が重要になります。外部連携では「便利だから全部渡す」が最悪です。依頼に必要な最小データだけをMessageのPartに入れ、機密情報はマスキングまたは参照トークン化します。
どのパターンでも、最初から全社横断の巨大エージェント網を作らない方がいいです。まずは一つの業務、二つのエージェント、三つ程度のTask状態から始めるのが現実的です。たとえば「営業提案エージェントが調査エージェントへ市場調査を依頼する」くらいに絞ると、A2Aの価値と運用負荷が見えます。
失敗パターン：A2Aを入れても破綻するケース
失敗パターンの一つ目は、Agent Cardをカタログとして整備しないことです。エージェントが増えるほど、どれが本番で、どれが検証中で、どれが廃止予定なのか分からなくなります。A2Aは発見の仕組みを提供しますが、社内のライフサイクル管理までは自動でやってくれません。所有者、SLO、データ分類、変更履歴を別途管理する必要があります。
二つ目は、Task状態をUIに出さないことです。裏側でTaskを使っていても、ユーザーに進捗が見えなければ「止まった」「失敗した」「もう一回押そう」となります。最低でも受付、処理中、入力待ち、完了、失敗、キャンセルの状態は見せましょう。長時間処理では、最後に成功したステップや次の待ち理由も出せると運用が楽です。
三つ目は、構造化出力を軽視することです。A2Aでエージェント同士がつながっても、成果物が毎回自由文だと次のエージェントが扱いにくくなります。人間向けの説明文と、次工程向けのJSONを分ける設計が有効です。JSON SchemaやStructured Outputsを使う場合は、Structured Outputs実装完全ガイド2026の設計観点も参考になります。
四つ目は、MCPサーバーをそのままA2A Server扱いにすることです。MCPツールは便利ですが、A2AのServerはタスクの責任主体です。ツールを呼べることと、業務タスクを引き受けられることは違います。A2A Serverにするなら、失敗時の説明、再実行、キャンセル、監査、所有者を持たせてください。
導入チェックリスト
最後に、実装前のチェックリストを置いておきます。A2Aは新しいから入れるものではなく、複数エージェント間で責任ある仕事の受け渡しが必要になったときに検討するものです。
- 対象業務は、単発のツール呼び出しではなく、別エージェントへ委任する意味があるか
- Agent Cardに公開してよい情報と、認証後だけに出す情報を分けたか
- Taskの状態、保持期間、キャンセル可否、再実行方針を決めたか
- Messageに入れるデータを最小化し、機密情報のマスキングを設計したか
- MCPで十分な処理と、A2Aが必要な処理を分けたか
- ユーザーUIに進捗、入力待ち、失敗理由を表示できるか
- 監査ログに、依頼元、依頼先、タスクID、権限判定、成果物IDを残せるか
- 外部ベンダーとつなぐ場合、契約、データ処理条件、削除要件を確認したか
もし一つでも曖昧なら、まずはPoCの範囲を絞りましょう。A2Aはエージェント同士の橋になりますが、橋をかける先の責任範囲が曖昧なままだと、事故が起きたときに誰も止められません。
まとめ：A2Aはマルチエージェント時代の業務境界を作る
A2Aプロトコルは、単なる新しいAPI仕様ではありません。AIエージェントが増えた組織で、「どのエージェントに何を頼めるのか」「依頼した仕事はどこまで進んだのか」「成果物は誰の責任で返されたのか」を扱うための業務境界です。
2026年時点で、A2Aは仕様と実装エコシステムが整いつつある段階です。GitHub上のA2A Projectでは仕様やリリース情報が公開されており、v1.0.0タグも確認できます（a2aproject/A2A）。ただし、導入効果の数字は自社の業務、UI、権限設計、運用設計に強く依存します。公式にないベンチマークを根拠なく置くより、まず一つの業務でTask成功率、平均処理時間、手戻り率、ユーザー満足度を測る方が堅いです。
実装の第一歩は、Agent Cardを一枚書くことです。そこに書けない能力は、まだ社内で提供する準備ができていない可能性があります。小さく始め、Task管理と監査ログを先に固め、MCPとの役割分担を明確にする。A2Aは、その順番で導入すると現実的に使えます。
関連記事・次に読む
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
