AIエージェントが増えるにつれて、別の会社が作ったエージェントに仕事を頼みたい場面が出てきました。
ところが作り方も呼び出し方もばらばらだと、組み合わせごとに専用のつなぎ込みが要ります。
このつなぎ方をそろえるために作られたのが、A2A（Agent2Agent）プロトコルです。
よく並べて語られるMCPとの違いが分かると、どちらをどこで使えばよいかにも説明がつきます。
A2Aはエージェント同士の共通語
A2Aは、別々に作られたAIエージェントが互いの能力を知り、仕事を頼み、結果を受け取るためのオープンな規格です。
Googleが2025年4月9日に発表した時点で、50を超える企業が支援を表明していました。
Googleの発表ブログでは、A2AはAnthropicのMCPを補う規格として紹介されています。
Google Cloudの発表のとおり、同じ年の6月23日には仕様書やSDKがLinux Foundationへ寄贈されました。
2026年3月12日に最初の安定版v1.0が公開され、2026年9月時点でもプロトコルの版は1.0です。
5月には、仕様書の記述を直したv1.0.1もGitHubで公開されました。
さらに2026年8月17日には、MCPと同じAgentic AI Foundation（AAIF）のホストプロジェクトになりました。
AAIFの発表によると、支援する組織は150を超えています。
仕様の原則には、内部の考えや使うツールを相手に明かさなくても協力できる「不透明な実行」も含まれています。
名刺を読んでから仕事を頼む
A2Aのやり取りは、相手の自己紹介を読むところから始まります。
Agent Cardで相手を知る
Agent Cardは、エージェントが自分の名前やできること、接続先を書いて公開するJSONの名刺です。
置き場所の標準は https://{ドメイン}/.well-known/agent-card.json と決められています。
仕様書のサンプルを短くすると、次のような中身になります。
{
"name": "GeoSpatial Route Planner Agent",
"supportedInterfaces": [
{"url": "https://georoute-agent.example.com/a2a/v1", "protocolBinding": "JSONRPC", "protocolVersion": "1.0"}
],
"capabilities": {"streaming": true, "pushNotifications": true},
"securitySchemes": { ... },
"skills": [
{"id": "route-optimizer-traffic", "name": "Traffic-Aware Route Optimizer", ... }
]
}省いた箇所は ... にしました。
skills には引き受けられる仕事が、securitySchemes には求める認証方式が入ります。
呼び出す側はこのカードを読んで、頼む相手とつなぎ方を決めます。
タスクで進み具合を追う
依頼を受けたエージェントは、その仕事を一意のIDが付いた「タスク」として管理します。
タスクがたどる状態は、受付と処理中、そして終わりを表す完了・失敗・取り消し・拒否です。
途中で情報が足りなければ「入力待ち」、認証が要れば「認証待ち」の状態で止まり、依頼側の返事を待ちます。
仕様書の例は、航空券の予約を頼まれたエージェントが出発地と行き先を聞き返す場面です。
{
"task": {
"id": "task-uuid",
"status": {
"state": "TASK_STATE_INPUT_REQUIRED",
"message": {
"role": "ROLE_AGENT",
"parts": [{"text": "I need more details. Where would you like to fly from and to?"}]
}
}
}
}依頼側は同じタスクIDを付けて答えを送り、そのまま会話を続けられます。
メッセージとアーティファクトで受け渡す
依頼や聞き返しは「メッセージ」で送り、1通のメッセージは「パート」を並べて組み立てます。
パートには、テキスト、ファイルそのものかファイルのURL、JSONのような構造化データを入れられます。
仕事の成果物は「アーティファクト」と呼ばれ、報告書や画像などをパートで組み立てて返します。
通信は既存のWeb技術の上で動く
A2Aは、HTTPやJSON-RPC 2.0、Server-Sent Eventsといった既存の技術の上に作られています。
v1.0の仕様が定める標準のつなぎ方は、JSON-RPC 2.0 over HTTP(S)、gRPC、HTTP+JSON（REST）の3種類です。
どれに対応しているかはAgent Cardに書かれ、呼び出す側は並び順の先頭から自分が使えるものを選びます。
進み具合の受け取り方も、次の3通りが用意されています。
- ポーリング: 依頼側が定期的にタスクの状態を聞きに行く
- ストリーミング: Server-Sent Eventsで途中経過を受け取り続ける
- プッシュ通知: 状態が変わるたびに、依頼側が登録したWebhookへHTTP POSTが届く
接続を保たずに済むプッシュ通知まであるのは、長時間の仕事や人の確認を挟む仕事を前提にしているためです。
各方式の決まりとリクエスト例は、A2Aの仕様書にまとまっています。
MCPとの使い分け
MCPは、AIエージェントと外部のツールやデータをつなぐための規格です。
MCPそのものの仕組みは、別の記事で説明しています。
A2Aの公式ドキュメントは、2つの違いを「縦」と「横」のつながりで説明しています。
MCPは1つのエージェントに道具を足して、できることを深くする縦のつながりです。
A2Aはチームや会社の境目を越えて、別のエージェントと手を組む横のつながりです。
MCPはエージェントが道具を使うため、A2Aはエージェント同士が仕事を分け合うための規格と覚えると整理しやすくなります。
相手が計算やデータベース検索のように、入力と出力の形が決まった道具ならMCPで呼びます。
MCPのツールの説明は、LLMの関数呼び出しに近い形で書かれます。
相手が自分で考え、いくつもの道具を使い、何往復かの会話で仕事を進めるエージェントならA2Aの出番です。
公式ドキュメントでは、自動車の修理工場を例に2つの役割を分けています。
- 客やその代理のエージェントが、店長役のエージェントに症状を伝える（A2A）
- 作業を任された整備士役のエージェントが、診断スキャナーや修理マニュアルを呼ぶ（MCP）
- 部品が要ると分かったら、部品業者のエージェントに在庫を問い合わせる（A2A）
A2AとMCPの比較ページは、2つを組み合わせて使うことを勧めています。
どちらかを選ぶより、システムのどの境目にどちらを置くかで考えると迷いにくくなります。
つなぐ前に確かめたいこと
安定版になったとはいえ、使い始める前に知っておきたい点がいくつかあります。
0.3とv1.0では書き方が違う
v1.0には、0.3からの変更のうち互換性のない修正がいくつも含まれています。
依頼側はリクエストごとに A2A-Version ヘッダーで版を伝え、ヘッダーが空なら受け手は0.3として扱う決まりです。
2026年3月より前の解説やサンプルは0.3以前の書き方なので、項目名が今の仕様と合うかを確かめてから参考にしてください。
v1.0の発表によると、Agent Cardで0.3とv1.0の両方に対応していると示せるため、少しずつ移行することもできます。
認証の中身はつなぐ側で決める
A2Aが決めているのは、Agent Cardで認証方式を示すところと、資格情報をヘッダーに載せて送るところまでです。
資格情報そのものは、OAuthなどの手続きでプロトコルの外から手に入れます。
受け手はリクエストを毎回認証し、何を許すかは自分の方針で判断します。
どの相手にどこまで任せるかは、プロトコルが決めてくれない設計の部分です。
相手の名刺と通知をうのみにしない
Agent Cardには電子署名を付けられますが、付けるかどうかは任意です。
依頼側には、TLS証明書で相手のサーバーが本物かを確かめることが推奨されています。
プッシュ通知を受ける側は、届いたWebhookが本物かを検証しなければなりません。
通知を送る側には、宛先のURLを検査して、内部ネットワークへのリクエストに悪用される攻撃を防ぐことが勧められています。
最後に
A2Aは、別々に作られたエージェントが中身を見せ合わないまま、仕事を頼み合うための共通の作法です。
Agent Cardで相手を知り、タスクで進み具合を追い、アーティファクトで成果を受け取る流れを押さえておくと、仕様書も読みやすくなります。
道具をつなぐならMCP、エージェント同士をつなぐならA2Aという線引きがあれば、2つの名前を同時に見かけても迷わずに済みます。
以上です。
コメントを残す