A2Aプロトコルとは？仕組み・MCPとの違い・活用事例・セキュリティまでわかりやすく解説

A2A（Agent-to-Agent）プロトコルは、異なるベンダー・フレームワークで構築されたAIエージェント同士が、安全に通信・連携するためのオープン標準規約だ。Googleが2025年4月に発表し、現在はLinux Foundation傘下のAgentic AI Foundation（AAIF）が中立的に管理している。

この記事でわかること:

• A2Aプロトコルの基本的な定義と、なぜ必要なのか
• プロトコルの仕組み（3層構造・Agent Card・タスクライフサイクル）
• MCP（Model Context Protocol）との違いと補完関係
• v1.0（2026年3月リリース）で追加された新機能
• 企業の活用事例とエコシステムの現状（150社以上が参加）
• セキュリティリスクと対策のポイント
• A2Aが必要な場面・不要な場面の判断基準

想定読者: AIエージェントの連携を検討しているエンジニア・アーキテクト、マルチエージェントシステムの標準化動向を把握したいIT部門の意思決定者、生成AIの最新プロトコルを正確に理解したいビジネスパーソン。

A2Aプロトコルとは — エージェント間通信のオープン標準

A2A（Agent2Agent）プロトコルは、AIエージェント同士がお互いの内部実装を公開せずに、タスクの発見・委譲・実行を行うための通信規約だ。Apache License 2.0のもと、完全にオープンソースで公開されている。

基本情報を整理すると以下のとおり。

ポイントは、A2Aが特定のベンダーに依存しない中立的な標準として設計されている点だ。Googleが開発したが、2025年6月にLinux Foundationへ寄贈され、OpenAI・Anthropic・Google・Microsoft・AWS・Blockの6社が共同設立したAAIFのもとで運営されている。特定企業の囲い込みではなく、業界全体のインフラとして機能することを目指している。

A2Aプロトコルが必要とされる背景

なぜA2Aプロトコルが生まれたのか。その背景には、AIエージェントの急速な普及と「相互運用性の欠如」という課題がある。

エージェント乱立と「通信の壁」

2025年以降、企業が業務に導入するAIエージェントは爆発的に増えた。Gartnerの調査では、2026年までにエンタープライズアプリの40%がタスク特化型AIエージェントを搭載すると予測されている（2025年は5%未満だった）。

しかし、各エージェントは異なるフレームワーク（LangGraph、CrewAI、Google ADK、Semantic Kernelなど）で構築されており、ベンダーごとに独自のAPI仕様を持っている。結果として、エージェントAとエージェントBを連携させたいのに、通信手段が統一されていないという問題が生じた。

これはかつてのWebブラウザ戦争やメッセージングアプリの乱立と似た構図だ。共通の通信プロトコル（HTTPやSMTPのような）がないまま、各社が独自の接続仕組みを構築していた。

A2Aの役割 — 「共通言語」を作る

A2Aプロトコルは、この課題に対してエージェント間の「共通言語」を提供する。具体的には以下の3つの問題を解決する。

• 発見: あるエージェントが、別のエージェントの存在と能力を把握する手段がない → Agent Cardで解決
• 通信: 異なるフレームワークのエージェント同士がメッセージをやり取りする共通の方法がない → JSON-RPC/gRPC/HTTP RESTで解決
• タスク管理: 委譲したタスクの進捗追跡や完了確認の統一手段がない → Task ライフサイクルで解決

マルチエージェントの概念全般については「マルチエージェントAIとは？仕組み・活用事例・フレームワーク・導入判断まで徹底解説」で詳しく解説している。

A2Aプロトコルの仕組み — 3層構造とコアコンセプト

A2Aの技術仕様は、3つのレイヤーで構成されている。順番に見ていこう。

3層アーキテクチャ

この3層分離により、プロトコルの仕様変更が起きても、各レイヤーを独立して更新できる設計になっている。

5つのコアコンセプト

A2Aの通信は、以下の5つの概念で成り立っている。

1. Agent Card（エージェントカード）

エージェントの「名刺」に相当する。エージェントが自身のID・機能・スキル・エンドポイント・認証要件をJSON形式で公開するメタデータ文書だ。他のエージェントはAgent Cardを読むことで、そのエージェントに何を依頼できるかを把握する。

v1.0ではJWS（JSON Web Signature）による暗号署名（Signed Agent Card）に対応し、組織をまたいだエージェントの信頼性を検証できるようになった。

2. Task（タスク）

エージェント間の作業単位。以下のライフサイクルで管理される。

CREATED → WORKING → INPUT_REQUIRED / AUTH_REQUIRED → COMPLETED / FAILED / CANCELED / REJECTED

数秒で完了するタスクから、数日かかる長時間タスクまで対応している点が特徴だ。

3. Message（メッセージ）

クライアント（依頼する側）とサーバー（処理する側）間のやり取り。contextId でグループ化し、taskId で既存タスクへの参照ができる。

4. Part（パート）

メッセージの最小コンテンツ単位。v1.0で TextPart・FilePart・DataPart が統合Partに一本化され、テキスト・ファイル・構造化データを1つの型で扱えるようになった。

5. Artifact（アーティファクト）

タスクの出力物。1つ以上のPartで構成される。たとえば「レポートのPDF」「分析結果のJSON」などがArtifactとして返される。

通信プロトコル — 3つの選択肢

A2Aは用途に応じて3つの通信方式から選べる。

リアルタイムの進捗通知が必要な場合はSSE（Server-Sent Events）、非同期処理にはWebhook（Push Notification）、シンプルな状態確認にはポーリング（GetTask）が用意されている。

5つの設計原則

Googleの公式仕様では、A2Aの設計思想として以下の5原則が掲げられている。

1. Agentic Capabilities — 共有メモリ・ツール・コンテキストなしでエージェント同士が協調動作
2. Existing Standards — HTTP、SSE、JSON-RPCなど既存の業界標準上に構築
3. Enterprise Security — OpenAPI互換の認証・認可に対応
4. Long-running Tasks — 数秒〜数日のタスクをサポート
5. Modality Agnostic — テキスト・音声・動画のマルチモーダル通信に対応

特に重要なのは1つ目の「Agentic Capabilities」だ。A2Aでは、エージェント同士がお互いの内部ロジックやメモリを覗けない「opaque（不透明）」設計を採用している。これにより、企業の知的財産やビジネスロジックを保護したまま、エージェント間連携が実現できる。

A2AとMCPの違い — 「横方向」と「縦方向」の補完関係

A2Aプロトコルを理解するうえで最も重要なのが、MCP（Model Context Protocol）との違いと関係性だ。

結論: A2AとMCPは競合ではなく補完関係

Google公式は、MCPを「手足」（ツール接続）、A2Aを「対話」（エージェント間通信）と位置づけている。いずれもLinux Foundation（AAIF）傘下で管理されており、両者を組み合わせて使うのが推奨設計だ。

いつA2Aを使い、いつMCPで十分か

Google公式の開発者ガイドでは、「MCPから始めて、必要に応じてA2Aを追加する」ことを推奨している。

MCPで十分な場面:

• エージェントが外部ツール（データベース、API、ファイルシステム）にアクセスしたい
• 1つのエージェント内で完結するタスク
• ツールの入出力が明確で、エージェント同士の対話は不要

A2Aが必要になる場面:

• 異なるベンダー・フレームワークのエージェントを連携させたい
• 社外のパートナー企業のエージェントとタスクを委譲し合いたい
• 内部ロジックを公開せずにエージェント間で協調動作させたい
• 数時間〜数日かかる長時間タスクをエージェント間で管理したい

両方を組み合わせるパターン

実務では、1つのエージェントがMCPでツールに接続しつつ、A2Aで他のエージェントとタスクを委譲し合う構成が一般的だ。たとえば以下のようなフローになる。

1. ユーザーが「来月の売上予測レポートを作って」とエージェントAに依頼
2. エージェントAはA2AでエージェントB（データ分析専門）にデータ集計タスクを委譲
3. エージェントBはMCPで社内データベースやBIツールに接続してデータを取得・分析
4. エージェントBが分析結果をA2AでエージェントAに返す
5. エージェントAはレポートを整形してユーザーに出力

v1.0の主な新機能（2026年3月リリース）

A2Aプロトコルは2026年3月12日にv1.0.0をリリースし、本番環境での利用に耐える安定版となった。ここでは主要な新機能を整理する。

Signed Agent Card（暗号署名付きエージェントカード）

JWS（JSON Web Signature、RFC 7515）とJSON Canonicalization（RFC 8785）を使った暗号署名が可能になった。組織の境界を越えてエージェントを連携させる際に、そのAgent Cardが確かに特定の組織が発行したものであることを検証できる。

gRPCバインディング

v0.x系ではJSON-RPC over HTTPのみだったが、v1.0でgRPC（Protocol Buffers）が正式追加された。マイクロサービス間の高速通信や型安全なエージェント連携が求められるエンタープライズ環境で有用だ。

マルチテナンシー

単一のエンドポイントで複数のエージェントを安全にホスティングできるようになった。SaaS型のエージェントプラットフォーム構築に必要な機能だ。

Part型の統合

v0.xでは TextPart・FilePart・DataPart に分かれていた型が、統合Partに一本化された。これにより開発者は1つの型でテキスト・ファイル・構造化データを統一的に扱える。

バージョンネゴシエーション

異なるバージョンのA2Aを実装したエージェント同士でも、互換性を確認してから通信を開始する仕組みが追加された。

A2Aプロトコルでできること — 10の機能

A2Aプロトコルが提供する機能を整理する。

1. エージェント発見 — Agent Cardを通じて、他のエージェントの機能・スキル・エンドポイントを発見できる
2. タスク委譲 — クライアントエージェントからリモートエージェントへ、タスクの委譲と状態追跡が可能
3. マルチモーダル通信 — テキスト・ファイル・構造化データ・音声・動画のやり取りに対応
4. 長時間タスク管理 — 数秒〜数日にわたるタスクのライフサイクルを追跡・管理
5. リアルタイムストリーミング — SSEによる進捗通知で、タスクの中間結果をリアルタイムに受け取れる
6. 非同期処理 — Webhook（Push Notification）による非同期通知に対応
7. マルチテナンシー — 単一エンドポイントで複数エージェントを安全にホスティング（v1.0）
8. 暗号的アイデンティティ検証 — Signed Agent Cardでエージェントの発行元を暗号的に検証（v1.0）
9. バージョンネゴシエーション — 異なるバージョンのA2Aエージェント間の互換性確保
10. フレームワーク非依存 — LangGraph・CrewAI・Semantic Kernel・Google ADK等、どのフレームワークとも連携可能

できないこと・対象外

A2Aは万能ではない。以下はA2Aの対象外だ。

• ツール接続: エージェントと外部ツール・データソースの接続はMCPの領域
• エージェントの内部ロジック制御: 相手エージェントに「このアルゴリズムで処理せよ」と強制する仕組みはない
• 認可モデルの規定: 認証方式（OAuth等）は規定しているが、「何にアクセスできるか」の認可モデルは未規定
• ワークフローの強制: 「スキルXを必ず実行せよ」というセマンティクスの標準化は不十分

A2Aプロトコルの活用事例

A2Aプロトコルがどのような場面で使われるのか、具体的なユースケースを見ていこう。

金融 — 不正検知の多段階連携

銀行が複数のAIエージェントを組み合わせて不正取引を検知するケース。取引監視エージェント（ベンダーA製）が異常を検出すると、A2Aで本人確認エージェント（ベンダーB製）にタスクを委譲。さらに規制報告エージェント（ベンダーC製）が自動的に当局への報告書を生成する。各エージェントは自社の不正検知アルゴリズムを公開せずに連携できる。

ヘルスケア — 患者データの安全な共有

病院内の診断支援エージェント、薬剤チェックエージェント、保険請求エージェントがA2Aで連携する。患者データの取り扱いルールが異なる部門間でも、Agent Cardの認証要件に基づいてアクセスを制御できる。

製造業 — スマートファクトリーの工程最適化

生産計画エージェント、品質管理エージェント、物流エージェントが工場の稼働データを共有しながら最適化を行う。各エージェントは異なるベンダーのIoTプラットフォーム上で動作していても、A2Aで統一的に通信できる。

エンタープライズ — 部門横断の業務自動化

人事部門のエージェント（採用管理）と経理部門のエージェント（給与計算）がA2Aで連携し、新入社員のオンボーディングを自動化する。異なるSaaS（Workday、SAP等）上のエージェントが、共通プロトコルで情報をやり取りする。

A2Aプロトコルのメリット

A2Aを採用することで得られる具体的なメリットを整理する。

1. ベンダーロックインの回避

オープン標準のため、特定のクラウドやフレームワークに縛られない。Google ADKで構築したエージェントと、Microsoft Semantic Kernelで構築したエージェントを自由に連携できる。ベンダー移行の際にもプロトコル層は共通のまま維持できる。

2. 既存インフラとの親和性

A2AはHTTP・JSON-RPC・gRPCなど、すでに広く使われている技術スタックの上に構築されている。企業の既存のAPIゲートウェイ、ロードバランサー、監視ツールをそのまま活用できる。

3. セキュリティの標準化

OAuth 2.0（Authorization Code + PKCE、Client Credentials、Device Code）、OpenID Connect、Mutual TLSなど、エンタープライズで実績のある認証方式をサポート。v1.0のSigned Agent Cardにより、組織間の信頼検証も暗号的に行える。

4. スケーラブルなエコシステム

150社以上のパートナー、5言語のSDK、3大クラウド（Google Cloud・Azure・AWS）の統合対応により、実装の選択肢が豊富。エコシステムの規模自体が、プロトコルの信頼性を裏付けている。

A2Aプロトコルのリスクと注意点

一方で、A2Aの導入にはリスクと課題もある。NRI Secureや各セキュリティ専門家の指摘も含めて整理する。

N^2スケーリング問題

A2Aのピアツーピアモデルでは、エージェント数が増えると接続数がO(n^2)で増大する。エージェントが10台なら45本の接続で済むが、100台では4,950本になる。HiveMQの分析では、大規模環境ではMQTTベースのメッセージブローカーなどで補完する必要があると指摘されている。

認可モデルの不在

A2Aは認証方式（「誰であるか」を確認する方法）は規定しているが、認可モデル（「何にアクセスしてよいか」のルール）は規定していない。エンタープライズ環境では、スコープベースのアクセス制御を自前で設計・実装する必要がある。

信頼の連鎖の脆弱性

NRI Secureは、エージェント間の委譲チェーンにおける以下のリスクを指摘している。

• なりすまし（Spoofing）: 偽のAgent Cardを提示して他のエージェントになりすます
• 偽情報の伝播: 悪意のあるエージェントが偽の分析結果を返し、それが後続のエージェントに伝播する
• リソース独占: 大量のタスクを送りつけて他のエージェントのリソースを消費させる

Signed Agent Card（v1.0）はなりすましリスクを軽減するが、偽情報の伝播やリソース独占への対策は、現時点ではアプリケーション層での実装が必要だ。

攻撃面の拡大

MCPとA2Aを併用すると、ツール接続（縦方向）とエージェント通信（横方向）の両方が攻撃対象になる。NRI Secureは「攻撃面が指数的に拡大する」と警告しており、両プロトコルを導入する際はセキュリティ監査の強化が不可欠だ。

実行の決定性が弱い

A2Aは柔軟な設計を重視しているため、エージェントへの依頼が必ず意図どおりに処理される保証はない。「スキルXを実行せよ」と指示しても、受信側エージェントの解釈に依存する。ミッションクリティカルな業務では、実行結果の検証ロジックを組み込む必要がある。

セキュリティ対策のポイント

A2A導入時に最低限対応すべきセキュリティ対策をまとめる。

• HTTPS必須: すべてのA2A通信はHTTPS上で行う
• Signed Agent Cardの利用: 組織間連携では暗号署名付きAgent Cardで身元を検証する
• 認可ポリシーの設計: A2Aが規定しない認可モデルを自前で設計し、スコープを制限する
• タスク委譲チェーンの監視: 委譲の深さを制限し、異常な連鎖を検出するロジックを入れる
• レート制限: リソース独占を防ぐため、エージェントごとのタスク送信レートを制限する

AIエージェントのセキュリティ対策全般については「AIエージェント セキュリティ 対策」で詳しく解説している。

A2Aプロトコルのエコシステム — 対応状況と関連プロトコル

A2Aのエコシステムは、1年間で急速に拡大した。ここでは主要な対応状況と、関連プロトコルを整理する。

技術運営委員会（TSC）

A2Aの技術的方向性を決定するTSC（Technical Steering Committee）には、以下の8社が参加している。

AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNow

AAIF（Agentic AI Foundation）とは

2025年12月に設立されたAAIFは、A2AとMCPの両方を中立的に管理する組織だ。OpenAI・Anthropic・Google・Microsoft・AWS・Blockの6社が共同設立し、Jim Zemlin（Linux Foundation Executive Director）が「長期的な中立性・協力・ガバナンス」を保証すると表明している。

AAIFの存在は重要だ。A2A（Google発）とMCP（Anthropic発）がそれぞれ独自に進化して分断するリスクを防ぎ、エコシステム全体の一貫性を担保する役割を担っている。

クラウドプラットフォームの対応状況

3大クラウドすべてがA2Aをサポートしている点は、プロトコルの普及において大きな意味を持つ。

主要パートナー企業

150社以上のパートナーには、以下のような企業が含まれている。

• クラウド: Google Cloud、Microsoft Azure、AWS
• エンタープライズSaaS: Salesforce、SAP、ServiceNow、Workday、Intuit
• テクノロジー: Atlassian、Box、MongoDB、PayPal
• AI/ML: Cohere、LangChain
• コンサルティング: Accenture、BCG、Capgemini、Deloitte、KPMG、McKinsey、PwC

関連プロトコル

A2Aの周辺には、以下の関連プロトコルが存在する。

AP2は、A2Aでタスクを委譲した際の対価の支払いを標準化するプロトコルだ。エージェントエコノミーが拡大した場合に、エージェント間の商取引を実現するインフラとなる可能性がある。

A2Aプロトコルの料金

A2Aプロトコル自体は完全無料だ。Apache License 2.0のオープンソースとして公開されており、プロトコル仕様・SDK・サンプル実装すべてを無償で利用できる。

ただし、A2Aエージェントを実行するインフラのコストは別途発生する。

プロトコル自体にロイヤリティや課金は一切発生しない。これはHTTPやSMTPと同様の位置づけだ。

A2Aが向いているケース・向いていないケース

A2Aを導入すべきかどうかは、プロジェクトの要件によって判断が分かれる。

こんなケースにA2Aは向いている

• 異なるベンダーのエージェントを連携させたい: Google ADK製、LangChain製、Semantic Kernel製のエージェントをまたいで動作させるならA2Aが必要
• 社外パートナーのエージェントと接続したい: 取引先や協力会社のエージェントとタスクを委譲し合う場合、Agent Cardベースの発見・認証が役立つ
• 内部ロジックを公開したくない: 自社のビジネスロジックやアルゴリズムを秘匿しつつ、外部エージェントと連携する要件がある場合
• 長時間タスクの管理が必要: 数時間〜数日かかる業務プロセスをエージェント間で追跡・管理したい場合
• エンタープライズ規模のマルチエージェントシステムを構築する: 3大クラウドの統合対応やエンタープライズセキュリティが活かせる

こんなケースにはA2Aは不要

• 単一エージェントで完結する: 1つのエージェントがツールに接続するだけならMCPで十分
• 社内の同一フレームワーク内での連携: 同じLangGraphプロジェクト内のエージェント同士なら、フレームワーク内部の通信機能で事足りる
• エージェントの数が少ない: 2〜3台のエージェント連携なら、直接的なAPI連携のほうがシンプル
• プロトタイプや実験段階: 学習コストや設計の複雑さを考えると、まずMCPから始めるのが合理的
• リアルタイム性が極めて高い要件: A2AのRPCモデルでは、ミリ秒単位のリアルタイム要件には適さない場合がある

段階的な導入ステップ

Google公式の開発者ガイドでは、以下の段階的アプローチが推奨されている。

1. MCPから始める: まずエージェントとツールの接続をMCPで構築
2. 必要に応じてA2Aを追加: 異なるベンダー間・組織間の連携が必要になった段階でA2Aを導入
3. 6つのプロトコル（MCP、A2A、AP2等）を一度に導入する必要はない: 必要な機能から段階的に採用

AIエージェントの全体像については「AIエージェントとは？定義・仕組み・活用例をわかりやすく解説」を参照。エージェント向けのフレームワーク選びは「AIエージェントフレームワーク比較」で詳しく解説している。

よくある質問（FAQ）

Q1. A2AプロトコルとAPIの違いは何ですか？

通常のAPIは「このエンドポイントにこのパラメータを送ると、この結果が返る」という固定的な仕様だ。A2Aは、エージェントが自律的にタスクを発見・委譲・交渉するための通信規約であり、Agent Cardによる動的な能力発見やタスクのライフサイクル管理が含まれる。単なるAPI呼び出しではなく、エージェント同士の「協調プロトコル」と理解するのが正確だ。

Q2. A2Aを使うにはGoogleのサービスが必要ですか？

不要だ。A2AはApache License 2.0のオープンソースであり、Google以外のクラウド（Azure、AWS）やオンプレミス環境でも利用できる。Googleが開発したが、Linux Foundationに寄贈済みのため、特定ベンダーへの依存はない。

Q3. 現時点でA2Aの本番利用は可能ですか？

v1.0.0が2026年3月にリリースされており、仕様としては本番利用可能な段階にある。ただし、各言語のSDKはv1.0対応の進捗が異なる可能性がある。本番導入前には、使用するSDKのバージョンと安定性を確認することを推奨する。

Q4. A2AとMCPの両方を使う必要がありますか？

必ずしも両方を使う必要はない。エージェントがツールに接続するだけならMCPで十分だ。異なるベンダーのエージェント間で通信する必要が出てきた段階でA2Aを追加するのが合理的なアプローチだ。

Q5. 日本語のドキュメントはありますか？

公式ドキュメントは英語のみだ（2026年4月時点）。ただし、プロトコルのコアは既存のWeb標準（HTTP、JSON-RPC、gRPC）に基づいているため、Web開発の知識があれば仕様の理解は難しくない。

Q6. A2Aは無料で使えますか？

プロトコル仕様・SDK・サンプル実装はすべてApache License 2.0のオープンソースで完全無料だ。ただし、エージェントを実行するクラウドインフラ（Google Cloud、Azure、AWS等）の利用料金は別途発生する。

まとめ

A2Aプロトコルは、AIエージェント同士が安全かつ標準化された方法で通信・連携するためのオープン標準だ。Googleが開発し、現在はLinux Foundation傘下のAAIFが中立管理しているため、特定ベンダーへの依存なく利用できる。

押さえておくべきポイント:

• MCPが「エージェントとツールの接続」（縦方向）なら、A2Aは「エージェント間の通信」（横方向）。両者は補完関係
• v1.0（2026年3月）でgRPC対応・Signed Agent Card・マルチテナンシーが追加され、本番利用可能な段階に到達
• 150社以上のパートナーと3大クラウドの統合対応により、エコシステムは急速に拡大中
• N^2スケーリング問題、認可モデル不在、信頼チェーンの脆弱性などのリスクを理解した上で導入判断が必要
• 「MCPから始めて、必要に応じてA2Aを追加する」段階的アプローチが公式推奨

異なるベンダー・組織のエージェントを連携させる要件があるなら、A2Aは現時点で最も有力な標準プロトコルだ。一方、単一エージェントで完結する構成や、同一フレームワーク内の連携であれば、無理にA2Aを導入する必要はない。自社の要件に照らして、導入のタイミングを判断してほしい。

関連記事: 「AIエージェントとは？」 / 「マルチエージェントAIとは？」 / 「AIエージェントフレームワーク比較」 / 「AIエージェント おすすめ 比較」 / 「AIエージェント セキュリティ 対策」