A2A（Agent2Agent）とは｜MCPとの違いとエージェント連携の標準化

A2A（Agent2Agent）プロトコルとは

A2Aは、独立したAIエージェント同士が互いを発見し、タスクを依頼し合い、進捗と成果物をやり取りするためのオープンな通信プロトコルです。ベンダやフレームワークを問わずエージェント間の相互運用を成立させることを目的にしています。

A2Aの定義

A2Aプロトコル（Agent2Agent Protocol）は、エージェントの機能宣言と発見（Agent Card）、依頼と進捗管理（Task）、非同期メッセージのやり取り（Message／Streaming）を1本の仕様に束ねたものです。HTTPをトランスポート、JSON-RPC 2.0を呼び出し規約、Server-Sent Events（SSE）を長時間タスクのストリーミングに使う構成で、既存のWebスタックにそのまま乗ります。

一次情報はA2A公式サイトとGitHubのa2aproject組織にまとまっており、仕様書・サンプル実装・SDKが同じ場所から辿れます。

誕生の背景（Google発表とLinux Foundation寄贈）

A2Aは2025年4月9日にGoogleが「A New Era of Agent Interoperability」として発表しました（発表ブログはGoogle Developers Blog）。単体エージェントを賢くする流れから、複数エージェントを繋いで協業させる流れへの移行が背景にあります。

発表時点で50社超の企業とSaaS群が賛同を表明。企業横断で使えるオープン仕様として広がり、2025年6月にはガバナンス強化のためGoogle CloudからLinux Foundationへ寄贈されています（寄贈発表ブログ）。特定ベンダの囲い込みではないという点は、企業導入判断で問われやすいポイントです。

日本語で読める公式解説はGoogle Cloud Blog 日本語版にあります。仕様の細部を追う前に、まずここで背景と全体像を押さえておくと理解が速いです。

位置づけ（マルチエージェント時代の標準化）

いま企業で作られているエージェントは、フレームワーク（LangGraph・CrewAI・AutoGen など）ごとに独自のメッセージ設計になっており、他社／他部門が作ったエージェントとそのままでは繋がらない問題を抱えています。

A2Aは「エージェント同士がどうやって自己紹介し、どう依頼し合い、どう応答するか」を仕様として固定することで、この分断を解消しにいくものです。汎用のフレームワークとしてのマルチエージェント連携はAIエージェント開発フレームワーク比較｜LangGraph・CrewAI・AutoGenにまとめています。

A2AとMCPの違い（比較表）

もっとも問い合わせが多いのがMCP（Model Context Protocol）との違いです。役割が競合しているように見えて、実際は補完関係にあります。

MCPは「縦」、A2Aは「横」

• MCP：エージェント（≒LLMホスト）とツール／データソースを繋ぐ縦のプロトコル。1つのエージェントに何ができるかを拡張する

• A2A：エージェントとエージェントを繋ぐ横のプロトコル。複数エージェントの分業と連携を成立させる

MCP単体の解説はModel Context Protocolとは｜MCPの仕組み・活用事例をエンジニア視点で解説を参照してください。

比較表

役割が別レイヤなので、置き換え関係にはなりません。実運用では両方使うと考えて設計するのが早いです。

実運用では併用する

現場でよく使われるのは「個別エージェントの中はMCPでツールを繋ぎ、束ねる層でA2Aで連携する」2層構造です。たとえば「求人検索エージェント」がMCP経由でATS（採用管理システム）に繋がっており、「面接調整エージェント」が別途MCP経由でカレンダーに繋がる。両者をA2Aで会話させれば、採用担当者は「候補者Aさんとの面接を設定して」と自然文で1回頼むだけで済みます。

ミニFAQ

Q. A2AはMCPを置き換えますか？

いいえ。役割が別レイヤのため、MCPで作った資産はそのまま活かしつつ、A2Aで束ねる形になります。

Q. どちらから学ぶべきですか？

LLM単体アプリの延長で入るならMCPが先です。複数エージェント構成を作る段階でA2Aに進むと理解が繋がります。

A2Aプロトコルの仕組み

仕様は「Agent Card」「Task／Message」「通信レイヤ」「認証・認可」の4点で押さえられます。技術的詳細はGitHub a2aproject/A2A と公式サイトが一次情報です。

Agent Card（エージェントの自己紹介）

Agent Cardは、エージェントが「自分は何ができて、どのURLで呼び出せて、どんな認証を要求するか」を宣言するメタデータです。JSON形式で、原則として /.well-known/agent-card.json に配置されます。相手エージェントはこのCardを取得することで、話しかけてよい相手かをまず判断します。

カード内で宣言される主な項目

• name / description（エージェント名と概要）

• url（呼び出しエンドポイント）

• skills（提供する機能の配列）

• authentication（要求する認証方式）

• inputModes / outputModes（受け付け可能な入出力形式）

Agent Cardは公開範囲の設計が重要です。全社公開すべきか、社内エージェントに限るか、パートナー企業のドメインだけかを最初に決めておかないと、意図しないエージェントから呼ばれる導線ができてしまいます。

Task / Message / Artifact のデータモデル

エージェント間のやり取りは「Task」という単位で管理されます。

• Task：1つの依頼のライフサイクル（作成 → 実行中 → 完了／失敗）を持つ単位

• Message：Task内でやり取りされる会話メッセージ（user / agentの発話）

• Artifact：Taskが生成した成果物（ファイル・データ・URL等）

Taskは非同期で長時間動くケースを想定した設計で、状態遷移とストリーミング更新が仕様に組み込まれています。MCPは主にツール呼び出し中心の設計なのに対し、A2Aは長時間タスクの進捗共有まで前提に置きやすい違いがあります。

通信レイヤ（HTTP + JSON-RPC 2.0 + SSE）

通信はHTTPをトランスポート、JSON-RPC 2.0を呼び出し規約、SSE（Server-Sent Events）を進捗ストリーミングに使います。既存のREST API開発スキルでほぼそのまま入れるのが特徴で、gRPCや独自プロトコルを覚え直す必要はありません。

長時間タスク（例：レポート生成、コード書き換え、複雑な分析）ではSSEでMessage・Artifactの追加を都度プッシュする設計になっており、クライアント側がポーリングで叩き続ける実装にはしません。

セキュリティ（認証・認可の設計）

Agent Card内で authentication を宣言し、OAuth 2.0 / APIキー / Bearerトークン等の一般的な方式が使えます。設計で注意すべき論点は「Agent Cardを誰に見せるか」と「Taskの中身を誰まで監査するか」の2点で、社内SSOや監査ログ基盤との接続を最初に決めておくと後戻りが減ります。

ミニFAQ

Q. Agent Cardは全エージェントで公開必須ですか？

仕様上は必須ではなく、外部公開しない社内専用エージェントは Agent Card を公開しない選択も可能です。ただしA2A対応の主目的が相互発見なので、社内でもディレクトリを1つ用意しておく設計が現実的です。

A2Aの主要ユースケース

Google発表の資料や参加企業のデモから、実装が進んでいる領域を挙げます。

採用（人材データ × スケジュール調整）

「候補者検索エージェント」＋「面接調整エージェント」＋「オファー作成エージェント」を連携させる例が代表的です。採用担当者が自然文で1回依頼すれば、候補者検索から面接枠提示までを複数エージェントが分業で進めます。ATS・カレンダー・メールが別ベンダでも、A2A対応していれば連携できるのが利点です。

社内業務（IT運用・アカウント発行）

新入社員のオンボーディングを、人事情報エージェント → アカウント発行エージェント → 端末手配エージェント → 教材配信エージェントの連携で自動化する例。これまでRPAやワークフローエンジンで組んでいた領域を、エージェントの会話で構築し直す動きがPoCとして始まっています。

顧客対応（複数SaaSまたぎ）

サポート窓口で「請求エージェント」「契約エージェント」「技術サポートエージェント」を横断させ、1つの問い合わせに対して必要な担当エージェントに自動で振り分ける構成です。個別エージェントが自社製・他社製で混在していても、A2Aで束ねられれば統一UIで扱えます。

対応SDKと実装の始め方

A2Aの公式SDKは、GitHub a2aprojectから入手できます。既存スキルの延長で入れるのが強みです。

対応言語一覧

Pythonが最も情報量が多く、LangGraphなど既存フレームワーク側の対応事例も先行しています。LangGraphの基礎はLangGraphとは｜LangChainとの違い・エージェント構築の基本を参照してください。

最小構成の始め方

学習の入り口としては以下の順序が現実的です。

1. 公式サイトの A2A公式サイト でAgent Card仕様に目を通す

2. GitHubのサンプル実装（a2aproject/a2a-samples）でPython製の最小エージェントを動かす

3. LangGraphなど既存フレームワークで作ったエージェントに、A2A対応のエンドポイントを1つ生やす

4. 別のエージェントからそのAgent Cardを取得し、Task経由で依頼を投げる

HTTP APIとPythonでのLLMアプリ開発に慣れている人なら、1〜2日程度で最小PoCまで到達しやすい印象で、既存のLLMアプリ実装経験があれば学習コストは高くありません。

ミニFAQ

Q. LangChain／LangGraphで作ったエージェントをA2A対応にできますか？

はい。エージェント本体はそのままに、A2A用のHTTPエンドポイントとAgent Cardを追加する形で対応できます。既存の内部ロジックを書き換える必要はありません。

フリーランスエンジニアから見たA2A案件

「学ぶ価値はあるが、案件数は限定的」というのが2026年9月時点の実感です。ここは他の情報源で拾いにくい観点なので、母集団を明示して整理します。

案件の傾向（PoC中心）

現時点で見かけるA2A関連案件は、主要フリーランスエージェント数社の公開案件と面談時に提示される非公開案件をあわせて見た限り、次のような傾向があります（首都圏中心・週4〜5日稼働の準委任案件を想定した観測）。

• 完全にA2Aを主題にした案件はまだ少数で、多くは「マルチエージェントアーキテクチャの設計・PoC」の一部としてA2Aが挙がる形

• 発注元は生成AI活用に前のめりな事業会社の内製チームや、AIコンサル系のSIerが中心

• ロールは「LLMアプリ開発エンジニア」または「エージェント基盤アーキテクト」の名称が多い

案件全体像はAIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説で扱っています。A2A固有ではないものの、エージェント案件のパイの中で見るとスケール感が掴みやすいです。

必要スキル

• Python（a2a-sdk、既存のLLMアプリ実装経験）

• LangGraph／CrewAI等のエージェントフレームワーク経験

• REST API設計・JSON-RPC 2.0・SSEの実装経験

• OAuth 2.0など認証・認可の設計経験

• 社内SSO・監査ログ基盤との接続経験（エンタープライズ導入時）

LLMアプリ実装＋API設計＋認証設計の3点セットが揃っていれば参入可能です。ゼロからA2Aだけを覚えるより、既存のエージェント開発案件で価値を出しながらA2A対応を差し込む方が単価は伸ばしやすい印象です。

単価目安と案件の探し方

公開案件ベースでは、AIエージェント開発案件全般の月額単価目安は2026年9月時点で首都圏中心の主要フリーランスエージェント数社の公開案件を確認した限り、月80〜130万円台のレンジが目立ちます（週4〜5日稼働・準委任案件・実務経験3年以上想定）。A2A固有の付加価値は現時点で単価差として明示的には出にくく、上振れは「マルチエージェント設計を1人でリードできる」といった役割定義側で決まります。

非公開案件では、面談時に個別条件で上振れするケースも見られます。同じレンジで語らず、母集団の違いは分けて捉えるのが読み間違いを防ぐコツです。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。案件を探す入り口はフリコンの案件一覧から辿れます。

ミニFAQ

Q. A2A案件はフリーランスとして今すぐ取れますか？

A2A単体を主題にした案件はまだ少ないですが、LLMアプリ実装案件やAIエージェント開発案件の中でA2A対応が求められるケースは増え始めています。既存のエージェント案件で入りつつ、A2A対応を差し込む動き方が現実的です。

MCP × A2A の併用アーキテクチャ（このページにしかない整理）

競合記事の多くは「A2AとMCPは違うレイヤ」で終わるため、現場で組む2層構造の設計指針をここで整理します。

2層構造の設計例

• 下層（エージェント内部）：MCPでツール・データソースに接続

- 例：カレンダーMCP、Slack MCP、社内DB MCP、外部API MCP

• 上層（エージェント間）：A2AでエージェントとエージェントをつなぐA2A

- 例：スケジュール調整エージェント、営業支援エージェント、コード改修エージェント同士の依頼と応答

各エージェントは中で何でも自由に組んでいいが、外向きの窓口はAgent CardとA2A準拠のエンドポイントで統一する。この分担でチームや会社をまたいでも部品の交換が効くようになります。

実装時の分担指針

導入の落とし穴

• 役割の混同：MCPをエージェント間通信に流用しようとして詰まる例。役割が違うので、無理に片方で全部やろうとしない

• Agent Cardの公開範囲：全社Cardをそのまま外部公開してしまい、想定外のエージェントから呼ばれる事故

• 長時間タスクにSSEを設計しない：レポート生成のような数分以上かかるTaskで、SSEを組まずにHTTP同期で待たせてタイムアウトする事故

A2Aを扱うときによくある失敗

初回実装で詰まりやすいポイントを実務目線で3つ挙げます。

失敗①：MCPの延長で理解してしまう

MCPで「ToolがLLMホストの外にある」構造を理解すると、A2AもToolの拡張のように誤解しがちです。A2Aは相手が「LLMホストを持つ別のエージェント」という点で階層が違います。相手が自律的に判断してくる前提で設計しないと、依頼の粒度がずれます。

失敗②：Agent Cardの公開範囲を絞らない

社内エージェントのAgent Cardをドメイン制限なしで公開すると、意図しないエージェントからの呼び出し導線ができます。認証と公開範囲は最初に決めておくのが原則です。

失敗③：長時間タスクにSSEを設計しない

数分〜数時間かかるTaskで、SSEストリーミングを組まずに同期HTTPで待たせる設計は、タイムアウト事故とUX劣化の温床になります。Task定義段階で「これはSSE前提か、即応答か」を判断してから実装に入るのが安全です。

実践チェックリスト

A2A対応のPoCに入る前に、以下を確認しておくと手戻りが減ります。

• Agent Cardの公開範囲（外部公開／社内限定／パートナー限定）を決めたか

• 認証方式（OAuth / APIキー / Bearer）を決めたか

• Task定義でSSEストリーミングが必要な処理か即応答かを判断したか

• 既存のMCPツールをどのエージェントに閉じ込めるかを決めたか

• 依頼側エージェントと受け側エージェントの責務分担を明文化したか

• 監査ログを取る単位（Task単位／Message単位）を決めたか

• SDKの言語選定（Python優先か、既存スタック優先か）を決めたか

まとめ

A2A（Agent2Agent）は、AIエージェント同士の相互運用を可能にするオープンプロトコルです。MCPを置き換えるのではなく、個別エージェントの中はMCP、エージェント同士はA2Aという2層構造で組むのが基本形になります。

• A2AはGoogle発表・Linux Foundation寄贈のオープン仕様で、特定ベンダの囲い込みではない

• 仕様の柱はAgent Card・Task・Messageで、HTTP＋JSON-RPC 2.0＋SSEの既存Webスキルで実装できる

• 対応SDKは5言語で提供され、Pythonが情報量・事例ともに先行している

• フリーランス案件は主題化はこれからだが、LLMアプリ実装＋API設計＋認証設計のスキルセットで参入できる

• 実装時は「Agent Cardの公開範囲・認証・SSE設計」を先に決めておくと事故が減る

まずは公式サイトで仕様に目を通し、GitHubサンプルでPython製の最小構成を動かすところから始めるのが最短ルートです。既存のエージェント開発スキルを活かしつつ、A2A対応を武器として差し込んでいく動き方が、フリーランスとしては現実的です。

参照した一次情報

• A2A公式サイト

• GitHub a2aproject

• Google Developers Blog｜A New Era of Agent Interoperability

• Google Developers Blog｜Google Cloud donates A2A to Linux Foundation

• Google Cloud Blog 日本語版｜A2A: エージェント相互運用性の新時代

関連記事

• Model Context Protocolとは｜MCPの仕組み・活用事例をエンジニア視点で解説

• AIエージェントとは？仕組み・種類・活用事例をわかりやすく解説

• AIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説

• AIエージェント開発フレームワーク比較｜LangGraph・CrewAI・AutoGen

• LangGraphとは｜LangChainとの違い・エージェント構築の基本