A2A（Agent2Agent）プロトコルとは？｜AIエージェント同士がつながる標準規格をMCPと比べて読む

「AIにツールを持たせる」話は、この1年でずいぶん一般的になりました。

Claudeのようなアシスタントが自社のデータベースを検索したり、社内APIを叩いたりする仕組みは、MCP（Model Context Protocol）としてこのブログでも紹介した通りです。

ただ、実際の業務は1つのAIエージェントだけで完結しないことのほうが多いはずです。自社の見積もりエージェントが、取引先の在庫確認エージェントに問い合わせ、さらに配送会社の手配エージェントに連絡する——そんなエージェント同士の会話が必要な場面が増えています。

この「エージェントがエージェントに話しかける」層を標準化しようとしているのが、Googleが開発し、現在はLinux FoundationがホストするA2A（Agent2Agent）プロトコルです。

この記事では、A2Aが何を解決しようとしているのか、MCPとはどう違うのか、そしてこの1年でどこまで実装が進んだのかを、公式リポジトリと配布パッケージの情報をもとに整理します。最後に、プロダクトやGTMの現場が今どこまで備えておくべきかも考えます。

大企業だけの話だと思われがちですが、そうとも言い切れません。少人数で複数のSaaSを組み合わせて運営しているAIソロプレナーやインディーハッカーほど、自社で全部を作らずに外部のエージェントへ処理を任せたくなる場面は多いはずです。標準化された会話の作法がある方が、連携先を選ぶたびに独自仕様を調べ直す手間は減ります。

A2Aプロトコルとは何か

A2Aは、異なる開発者・異なるベンダーが作ったAIエージェント同士が、互いの内部実装を知らないまま連携できるようにする、オープンな通信プロトコルです。GoogleがApache 2.0ライセンスのオープンソースとして公開し、中立な運営のためにLinux Foundationへ寄贈しました。あるエージェントを実装した企業が、別の企業のエージェントの中身を知らなくても、決まった作法でやり取りできるようにするための約束事、と考えるとわかりやすいでしょう。

名刺代わりの「Agent Card」

A2Aの中心的な仕組みが、Agent Cardと呼ばれる自己紹介用のJSONです。エージェントは自分にどんな能力があり、どんな入出力形式に対応し、どこにアクセスすればよいかを、このカードとして公開します。ほかのエージェントはまずこのカードを取得し、依頼したい仕事をこなせる相手かどうかを判断してから連携を始めます。

簡略化した例を示すと、次のような形になります（実際の項目はもっと多く、あくまで説明用の一例です）。

{
  "name": "shipping-scheduler-agent",
  "description": "配送スケジュールの空き確認と仮予約を行う",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "url": "https://partner.example.com/a2a"
}

ここでいうcapabilitiesは、このエージェントがストリーミング形式の応答やプッシュ通知に対応しているかを示す部分で、urlが実際に問い合わせを送る宛先です。呼び出す側のエージェントは、依頼を送る前にこのカードを読み、対応形式や認証方法を確認したうえで会話を始めます。人が初対面の相手に名刺を渡し、連絡先と得意分野を確認してから商談に入る流れと似ています。

JSON-RPCの上に乗った3つのやり取り

A2Aは通信方式を一から発明していません。JSON-RPC 2.0をHTTP(S)の上に乗せるという、すでに広く使われている枠組みを土台にしています。そのうえで、単発の質問に答える同期のリクエスト・レスポンス、処理の進捗を流し続けるサーバー送信イベント（ストリーミング）、そして時間のかかる作業が終わったら知らせる非同期通知という、3つのやり取りの型を用意しています。見積もりのように数秒で終わる依頼から、配送手配のように数時間かかる依頼まで、同じ枠組みで扱えるようにする狙いです。

MCPとの違いは「縦」か「横」か

MCPとA2Aは、名前も由来も近いのでよく混同されますが、向いている方向が異なります。MCPは、1つのAIモデルが自社の道具箱（データベースやAPI、検索ツール）につながるための縦方向の接続です。対してA2Aは、独立した組織が運用する複数のエージェントが、対等な当事者として連携するための横方向の接続です。

この違いは実装の思想にも表れています。MCPで公開されるツールは、あらかじめ決められた入出力を持つ関数のようなものです。一方でA2Aのもう一方のエージェントは、内部にどんな判断ロジックや別のツール群を持っているかを相手に見せる必要がありません。内部の実装を隠したまま、対話のインターフェースだけを公開するという点が、単なるツール呼び出しとの決定的な違いです。

下の表に、両者の位置づけを整理しました。

重要なのは、どちらか一方を選ぶという話ではないという点です。1つのエージェントが、社内のデータベースにはMCPで接続しながら、取引先のエージェントとはA2Aで会話する、という併用がむしろ標準的な構成になっていきます。MCPが道具箱への接続で、A2Aが会議室への接続というイメージを持っておくと理解しやすいはずです。

受発注を例に流れを追ってみる

具体例で考えるとイメージがつきやすいでしょう。ある小売店の発注エージェントが、仕入先の在庫確認エージェントに商品の在庫を尋ねる場面を想像してください。発注エージェント自身は、社内の発注システムや在庫台帳にはMCP経由でアクセスして、必要な数量を割り出します。そのうえで、仕入先のAgent Cardを取得し、対応している問い合わせ形式を確認してからA2Aで在庫確認を依頼します。仕入先側のエージェントがどんな社内システムを使って在庫を調べているかは、発注エージェントには一切見えません。見えるのは「在庫あり・納期いつ」という応答だけです。この内部を隠したまま結果だけをやり取りする構造こそが、A2Aが解決しようとしている中心的な課題です。

この1年で何が起きたか

規格が発表されただけで実装が進まない例は、技術の世界では珍しくありません。A2Aについては、公式リポジトリと配布パッケージの更新履歴を追うと、実装が着実に積み上がっている様子が確認できます。

発表からLinux Foundationでの運営へ

A2Aは2025年にGoogleが発表し、その後Linux Foundationへ寄贈されました。公式のA2Aプロジェクトのリポジトリには、「Linux Foundationがホストし、Googleが最初にコントリビュートしたオープンソースプロジェクト」と明記されています。特定の一社が仕様を独占するのではなく、複数の企業が対等に議論できる場に運営を移した形です。

バージョンの積み重ねが示す実装の勢い

仕様そのものも止まっていません。2025年のうちに相互認証（mTLS）対応や、Agent Cardへの署名機能などが段階的に追加され、2026年3月には破壊的変更を含む最初の安定版v1.0.0が公開されました。OAuth 2.0まわりの認可フローが整理され、gRPCでのマルチテナント対応や仕様書自体の再構成も行われた、大きな節目です。2ヶ月後の5月にはv1.0.1で不具合修正が入っています。

仕様書だけでなく、実装ライブラリの更新頻度からも勢いがうかがえます。Python向けの公式SDKであるa2a-sdkは、2026年4月のv1.0.0以降だけで4回のマイナー・パッチリリースを重ね、直近は同年7月のv1.1.2です。仕様が固まったあとも、実装側の改善が継続的に入っていることがわかります。

こうした更新頻度は、仕様書だけが独り歩きしているのではなく、実際に動くコードとして使われ、そのフィードバックが仕様へ反映され続けていることの傍証になります。

プロダクト・GTMの現場は何を準備すればいいか

ここからは技術仕様を離れて、プロダクトやGTMの現場にとっての意味を考えます。

「エージェントの来訪者」という新しいアクセス経路

エージェントブラウザの記事では、AIが人に代わってブラウザを操作し、クリックやフォーム入力を行うケースを扱いました。A2Aが広がると、これとは別の経路が増えます。相手企業のエージェントが、あなたのサイトの画面を経由せず、A2A対応のエンドポイントへ直接問い合わせてくる、というパターンです。

見積もり依頼や在庫確認のような定型的なやり取りほど、この形に置き換わりやすいでしょう。自社にA2A対応のエンドポイントを用意する予定がなくても、取引先や連携先が対応を始めれば、それ経由のリクエストがログに混ざり始めます。ファネルやコンバージョンの数字を見るときに、どこまでが人の操作でどこからがエージェント同士のやり取りかを区別する必要性は、今後さらに高まっていくはずです。

MonaLensのような解析ツールでも、流入元をSNSや広告のように分類する仕組みはすでにありますが、エージェント経由のアクセスをひとつの区分として扱うという発想は、まだ一般的ではありません。人の訪問とエージェントの訪問を同じ数字で束ねてしまうと、「コンバージョン率が急に上がった/下がった」といった変化の理由を見誤りやすくなります。

契約・認可・監査ログという新しい論点

社内向けのAIエージェントについては、人間の承認を挟むガードレールの設計が既に論点になっています。A2Aのように他社が運用するエージェントと直接やり取りする場合、この論点はさらに重くなります。どの権限の範囲で、どんな認可のもとに、相手のエージェントに何を伝えたのか。A2Aのv1.0.0でOAuth 2.0まわりの認可フローが整理されたのも、この種のやり取りが単なる技術検証ではなく、実際の業務で使われ始めていることの裏返しといえます。

エージェント同士の会話が見積もりや在庫確認の一部を自動で進めるようになるほど、「誰が、いつ、どの権限で、何を依頼したか」の記録は、技術ログというより業務記録として扱う必要が出てきます。AP2による決済の自動化を扱った記事でも触れた通り、エージェントが人に代わって取引の一部を進める場面では、事後にその経緯を追跡できる仕組みが欠かせません。A2Aによるエージェント間の対話は、その決済より手前にある「交渉・確認」の段階を担う層として位置づけられます。

導入を検討する際に見ておきたい注意点

ここまで前向きな話が中心でしたが、導入を急ぐ前に押さえておきたい点もいくつかあります。

• 安定版v1.0.0が公開されたのは2026年3月で、標準としてはまだ日が浅く、0.x系から1.0への移行でも破壊的変更が入っています。今後も仕様が変わる前提で追随できる体制が必要です。
• 社内で完結する道具の接続であれば、まずはMCPで十分なことが大半です。A2Aが効いてくるのは、自社が管理できない外部のエージェントと定型的にやり取りする必要が出てきてからです。
• Agent Cardによる能力の自己紹介や、動的な連携先の発見といった「エージェントの自律性」を実際に必要としないなら、既存のWebhookやAPI連携のほうがシンプルで運用しやすい場合も多いはずです。標準規格に乗ること自体を目的にしないほうがよいでしょう。

つまり、判断の軸は「話題になっているから対応する」ではなく、「自社が管理していない相手のエージェントと、定型的かつ継続的にやり取りする必要が実際にあるか」に置くべきだということです。この条件に当てはまらないうちは、様子を見ながら仕様の成熟を待つという選択も十分に合理的です。

まとめ

A2Aプロトコルは、一言でいえば「異なる会社のAIエージェント同士が、互いの中身を知らないまま話すための共通語」です。MCPが自社のAIと道具をつなぐ縦方向の標準だとすれば、A2Aはその先で、組織の壁を越えた横方向の標準を担おうとしています。

2025年の発表から2026年の安定版v1.0.0まで、仕様と実装の両方が着実に積み上がってきた経緯を見る限り、A2Aは一時的な流行語では終わらなそうです。すぐに自社で対応エンドポイントを用意する必要はなくても、取引先や連携先のエージェントが、あなたのサイトやAPIへA2A経由でアクセスし始める日は、思っているより早く来るかもしれません。人の訪問者とエージェントの訪問者を分けて見る準備を、今のうちから少しずつ進めておく価値はあるはずです。