Google が Agent2Agent 発表！50社超が参画、AI連携の新時代を拓くオープンプロトコル徹底解説

April 11, 2025

URLをコピーしました！

AIエージェント、最近よく耳にしますよね。「自分の代わりに仕事をしてくれたら便利だろうな」と思う反面、「でも、うちの会社で使ってるシステムと連携できるの？」「いろんな会社のAIエージェントがあるけど、一緒に動かせるのかな？」なんて疑問も湧いてきませんか？

そんな悩みを解決するのが、Googleが中心となって発表した新しいオープンプロトコル「 Agent2Agent (A2A)」です！これは、まるでAIエージェントたちのための共通語。メーカーや作られた技術が違っても、Agent2Agentに対応していれば、エージェント同士が安全に情報を交換し、協力して複雑なタスクをこなせるようになります。

例えば、採用活動で候補者探しから面接設定、背景調査まで、複数の専門エージェントが連携して進めてくれる、そんな未来がもうすぐそこまで来ています。すでに50社以上の企業がこの取り組みに参加しており、AI活用の新しいスタンダードになる可能性を秘めているんです。Agent2Agentによって、AIエージェントの連携が加速し、私たちの仕事や生活が大きく変わるかもしれません。

この記事では、Agent2Agentプロトコルの基本から仕組み、具体的な活用例、そして将来性まで、わかりやすく解説していきます。

Agent2Agentとは？AIエージェント連携の新基準を学ぶ

Agent2Agent（A2A）の概要

まず、Agent2Agent（エージェント・ツー・エージェント、略してA2A）とは何か、簡単に説明します。これは、コンピューター上で人間の代わりに色々な作業をしてくれる「AIエージェント」たちが、お互いに「会話」をして協力し合うための、新しい共通ルール（プロトコル）のことです。Googleが中心になって開発を進めていて、誰でも使えるオープンな規格になっています。

今のAIエージェントは、例えば「A社の作ったエージェント」と「B社の作ったエージェント」がいて、それぞれ得意なことが違うのですが、お互いに直接話して協力するのが難しという課題がありました。まるで、違う言葉を話す人同士が一緒に仕事をするような感じですね。

AIエージェントとは何かを知りたい方はまずこちらの記事をご覧ください！

Agent2Agentが解決する課題：相互運用性の欠如

現代の企業では、業務効率化や自動化を目指して、様々なAIエージェントが導入されつつあります。例えば、顧客からの問い合わせに対応するエージェント、在庫を管理するエージェント、経費精算を処理するエージェントなど、多岐にわたります。これらは個々のタスクにおいては非常に有効ですが、多くの場合、それぞれが独立したシステムやアプリケーション上で動作しており、互いに連携することが困難でした。これを「相互運用性の欠如」と呼びます。

この相互運用性の欠如は、AIエージェントの潜在能力を十分に引き出す上での大きな障害となっています。なぜなら、実際の業務プロセスは、複数のシステムや部門にまたがることが多いからです。例えば、顧客からの注文を受けるプロセスを考えてみましょう。注文受付エージェントが注文を受け付けた後、在庫確認エージェントに在庫状況を問い合わせ、配送手配エージェントに配送指示を出し、請求処理エージェントに請求情報を渡す、といった一連の流れが必要です。これらのエージェントが連携できなければ、結局は人間が間に入って情報を手作業でシステム間を移動させたり、調整したりする必要があり、自動化のメリットが限定的になってしまいます。

Agent2Agentプロトコルは、まさにこの「相互運用性の欠如」という課題を正面から解決するために設計されました。異なるベンダーや異なる技術基盤（フレームワーク）で構築されたエージェントであっても、A2Aという共通の通信規約に従うことで、互いに情報を交換し、タスクを連携して実行できるようになります。

Agent2Agentの主要な利点：連携・統合・要件対応

Agent2Agentプロトコルを採用することには、企業や開発者にとって多くのメリットがあります。主な利点は以下の3点です。

シームレスなエージェント連携: これがAgent2Agentの最も重要な価値です。異なる開発元やフレームワークのエージェントでも、標準プロトコルを通じて効果的に通信・協力できます。これにより、相互運用性の問題が解消され、ユーザーは単一インターフェースから指示するだけで、裏でエージェントが協調してタスクを遂行します。
エンタープライズシステムへの容易な統合: 既存の企業アプリケーションにAIエージェント機能を組み込むための、シンプルで標準化された方法を提供します。企業は自社の技術環境全体でエージェント能力を活用でき、特定のベンダーに縛られずに柔軟な導入が可能です。
主要なエンタープライズ要件のサポート: 企業利用に必要なコア機能を提供します。
- 能力発見 (Capability Discovery): エージェントが自身の能力を他者に知らせる仕組み。
- ユーザー体験交渉 (User Experience Negotiation): ユーザーとの最適な対話方法（テキスト、フォーム等）を調整する仕組み。
- タスクおよび状態管理 (Task and State Management): タスク進捗を追跡・共有する仕組み。
- セキュアな連携 (Secure Collaboration): 安全な認証・認可に基づく通信。

これらの利点により、Agent2AgentはAIエージェント導入を加速し、その価値を最大化するための強力な基盤となることが期待されます。開発者は標準化された方法で連携機能を実装でき、企業はより柔軟かつ安全にAIエージェントを活用したシステムを構築できるようになるでしょう。

Agent2AgentとMCPの補完関係：ツールとエージェントの連携

AIエージェントのエコシステムにおいて、Agent2Agent（A2A）とModel Context Protocol（MCP）は、競合ではなく相互補完的な関係にあります。

この図は、MCPがエージェントとツール/リソースを接続し、A2Aがエージェント同士を接続する役割分担を示しています。

MCP: 主にAIモデルが外部の「ツール」（API、データベース検索など、構造化された入出力を持つもの）と連携するためのプロトコルです。ツールへのアクセス方法を標準化します。Google ADKもMCPツールをサポートしています。
A2A: 自律的な「エージェント」同士が協力するためのプロトコルです。エージェントは対等な立場で対話し、タスクを交渉しながら動的に連携します。メモリやツールを共有していなくても、マルチモーダルな通信が可能です。

複雑なタスク達成には、多くの場合ツールと他のエージェントの両方との連携が必要です。例えば自動車修理工場の例えでは、作業員（エージェント）が工具（MCPツール）を使う一方、顧客や部品サプライヤー（他のエージェント）とは異なるコミュニケーション（A2A）が必要だと説明されています。

この図のように、エージェントアプリケーションは、特定の機能アクセスにはMCPを、他のエージェントとの連携にはA2Aを使用するのが理想的です。

推奨される使い分けは、構造化された機能はMCPツール、自律的な判断や対話が必要な場合はA2Aエージェントとして公開することです。A2Aエージェント自体もMCPリソースとして公開することで、両プロトコルが連携したエコシステムが形成されます。

Agent2Agentプロトコルの設計思想

Agent2Agentを支える5つの基本原則

Agent2Agentプロトコルは、実用的かつ安全なエージェント連携のため、以下の5つの設計原則に基づいて開発されました。

エージェント能力の尊重: エージェントを単なるツールではなく、自律性や対話能力を持つ存在として扱います。メモリやツールを共有せずとも、エージェント本来の能力で協力できる真のマルチエージェント連携を目指します。
既存標準の活用: 導入を容易にするため、HTTP, JSON-RPC, Server-Sent Events (SSE) など、広く普及した技術を基盤とします。これにより、既存のITインフラや開発スキルを活用できます。
デフォルトでの安全性: エンタープライズ利用を前提とし、設計段階から認証・認可を重視します。OpenAPI互換の認証スキーマサポートを目指し、安全な通信を標準で確保します。
長時間タスクへの対応: 「数時間、あるいは人間が介在する場合は数日かかる」ようなタスクも想定し、リアルタイムの進捗フィードバックや通知、状態更新を提供するメカニズム（ストリーミング、プッシュ通知）を備えます。
モダリティ非依存: テキストだけでなく、音声や動画のストリーミングなど、多様な情報形式（モダリティ）でのコミュニケーションをサポートし、自然で豊かなインタラクションを可能にします。

これらの原則により、Agent2Agentは多様なAIエージェントが安全かつ柔軟に連携するための信頼性の高い基盤を提供します。

基盤技術：HTTP, SSE, JSON-RPCの採用

Agent2Agentプロトコルが導入しやすい理由は、広く普及している標準的なWeb技術を基盤としている点です。特別なインフラや知識を必要とせず、既存のスキルを活用できます。

主要な基盤技術は以下の通りです。

HTTP (HyperText Transfer Protocol): Web通信の基本。A2Aのエージェント間リクエスト・レスポンスはHTTP(S)上で行われ、既存のWebインフラ上で展開可能です。
JSON-RPC (JSON Remote Procedure Call): A2Aのメソッド呼び出し（例: タスク送信）のフォーマット。軽量なJSON形式を用いるため、多くの言語で実装が容易です。
SSE (Server-Sent Events): サーバーからクライアントへの一方向データストリーミング技術。A2Aでは、長時間タスクの進捗や成果物のリアルタイム更新（ストリーミング機能）に使用され、効率的な通信を実現します。

これらの実績ある標準技術の採用により、Agent2Agentは特定のベンダーに依存しない、オープンで相互運用性の高いプロトコルとなっています。開発者は使い慣れたツールで効率的に開発を進めることができます。

Agent2Agentのコアメカニズム：エージェント連携の舞台裏

役割分担：クライアントエージェントとリモートエージェント

Agent2Agentプロトコル通信は、基本的に「クライアントエージェント」と「リモートエージェント」という二つの役割間で行われます。

クライアントエージェント (Client Agent):
- 役割: タスクの「依頼元」。
- 責任: ユーザー指示や自身の目的達成のため、タスク内容を策定し、リモートエージェントに伝達。応答や進捗を受け取り、ユーザーへのフィードバックや追加指示を行う。
リモートエージェント (Remote Agent):
- 役割: タスクの「依頼先」。
- 責任: 依頼されたタスクを解釈し、自身の能力で実行。進捗、結果、追加情報の必要性などをクライアントに応答する。

この図は、クライアントとリモート間の基本的なやり取りと、それを支えるA2Aの主要機能（能力発見、UX交渉、タスク管理、セキュア連携）を示しています。クライアントがタスクを発見・依頼し、リモートが処理して応答するという流れが、これらの機能によって円滑に進められます。

この役割はタスクごとに相対的に決まり、エージェントは状況に応じて両方の役割を担うことがあります（例: A→Bへの依頼、B→Cへの依頼）。Agent2Agentは、このクライアント・リモート間の円滑な通信手順とデータ形式を提供し、複雑なマルチエージェント連携を可能にします。

能力発見：Agent Cardで「何ができるか」を知る

エージェント同士が協力するには、まず相手の能力を知る必要があります。Agent2Agentでは、この「能力発見 (Capability Discovery)」のために「Agent Card」を使用します。

Agent Cardは、リモートエージェントが自身の情報を公開するJSON形式の自己紹介ファイルで、通常 `/.well-known/agent.json` という標準的なパスで提供されます。

クライアントエージェントは、連携したい相手のAgent Cardを取得・解析することで、そのエージェントの様々な情報を把握できます。主な内容には以下が含まれます。

基本情報: エージェントの名前、説明、A2A通信を受け付けるURL、バージョン、提供元組織など。これらの情報は、エージェントがどのような存在であるかを識別するために役立ちます。
技術的能力: ストリーミングやプッシュ通知といったA2Aの特定機能に対応しているかどうかの情報。これにより、クライアントはどのような通信方式を選択できるかを知ることができます。
スキル情報: エージェントが実行可能な具体的なタスク（スキル）のリスト。各スキルには、名称、説明、関連タグ、具体的な利用例などが記述されます。クライアントはこれを見て、依頼したいタスクに適したエージェントか判断します。
通信モード: デフォルトで受け入れ可能な入力データ形式（テキスト、JSONなど）や、出力可能なデータ形式。クライアントはこれを見て、どのような形式でデータを送受信すればよいかを知ります。
認証情報: エージェントへのアクセスに必要な認証方式（APIキー、OAuthなど）の情報。安全な通信のために必要です。

このAgent Cardにより、クライアントは「どのエージェントに何を頼むべきか」「どうやって通信すればよいか」を事前に判断でき、動的で効率的な連携が可能になります。

タスク管理：ライフサイクルと状態の追跡

Agent2Agent連携の中心は「タスク (Task)」であり、プロトコルはその明確な定義と管理方法を提供します。タスクはクライアントからリモートへの一連の作業依頼単位です。

タスクの識別と状態:

各タスクは、クライアントが発行する一意のID (Task ID)で識別されます。タスクの状態は、TaskStatusオブジェクトで管理され、現在の状態 (state)、関連メッセージ (message)、更新時刻 (timestamp) を持ちます。

Task オブジェクトの主な構成要素例:

{
"id": "unique-task-id-123",
"sessionId": "optional-session-id",
"status": {
"state": "working", // TaskStateを示す文字列 (例: "submitted", "working", "completed")
"message": {
"role": "agent",
"parts": [{"type": "text", "text": "処理中です..."}]
}, // Messageオブジェクト (オプション)
"timestamp": "2025-04-10T12:00:00Z" // ISO 8601 文字列 (必須)
},
"artifacts": [ /* Artifactオブジェクトの配列 (オプション) */ ],
"history": [ /* Messageオブジェクトの配列 (オプション) */ ],
"metadata": { /* 任意のキーバリュー (オプション) */ }
}

TaskStatus オブジェクトの主な構成要素:

{
"state": "working", // TaskStateを示す文字列 (必須)
"message": { /* Messageオブジェクト (オプション) */ },
"timestamp": "2025-04-10T12:00:00Z" // ISO 8601 文字列 (必須)
}

Task & State ManagementはA2A連携のコア機能です。

タスクの状態 (TaskState) とライフサイクル:

タスクは、その処理過程で以下のような定義済みの状態間を遷移します。クライアントが tasks/send または tasks/sendSubscribe でタスクを開始すると、まずsubmitted状態となり、リモートエージェントが処理を開始するとworkingに移行します。処理の途中でクライアントからの追加情報が必要になるとinput-required状態で待機し、クライアントからの応答を受けて再びworkingに戻ることもあります。最終的にcompleted（正常完了）、failed（エラー発生）、またはクライアントが tasks/cancel を呼び出した場合はcanceled（キャンセル要求）のいずれかの終状態に至ります。

タスク操作メソッド (API):

A2Aプロトコルでは、これらのタスクを操作するための標準的なAPIメソッド（JSON-RPCのメソッド名）が定義されています。

tasks/send: 同期的にタスクを開始し、最終結果（Taskオブジェクト）を待つ場合に使用します。
tasks/sendSubscribe: ストリーミングでタスクを開始し、途中の状態更新や成果物をリアルタイムに受け取る場合に使用します。
tasks/get: 指定したTask IDの現在の状態や履歴、成果物を取得します。
tasks/cancel: 指定したTask IDの処理をキャンセルするよう要求します。

これらの標準化された管理方法とAPIにより、クライアントはリモートエージェントの処理状況を一貫して把握・制御でき、特に長時間タスクや複数回の対話が必要なタスクで有効です。エラー処理も標準化されています（例: TaskNotFoundエラー）。

メッセージとPart：多様な情報交換の単位

Agent2Agentプロトコルでのエージェント間コミュニケーションは、「メッセージ (Message)」オブジェクトを介して行われます。これは対話における一回の発言や情報伝達に相当します。

メッセージオブジェクトの構造:

メッセージは主に以下の要素で構成されます。

role: 送信者の役割 (“user” または “agent”)。どちらからの発言かを示します。
parts: メッセージ内容を格納する「Part」オブジェクトの配列。これがメッセージの中身です。
id (オプション): メッセージを一意に識別するためのID。
metadata (オプション): 関連タスクIDなど、追加情報を格納する場所。

Partオブジェクトの種類:

メッセージの内容を具体的に表現するのがPartオブジェクトです。JSON仕様によると、Partオブジェクトは`type`フィールドを持ち、その値によって種類が決まります。主な種類は以下の通りです。

TextPart (`type: “text”`): 最も基本的なテキスト情報。「text」フィールドに文字列を持ちます。
FilePart (`type: “file”`): ファイルデータを扱います。「file」フィールドに、ファイル内容を直接埋め込む形式(FileContent: bytes, mimeType, name)か、ファイルの場所を示す形式(FileUri: uri, mimeType, name)のどちらかを持ちます。画像やドキュメントの送受信に使われます。
DataPart (`type: “data”`): 構造化されたJSONデータを扱います。「data」フィールドにJSONオブジェクトを持ちます。Webフォームの定義やAPIのパラメータ/レスポンス交換などに利用されます。例えば、フォームの場合は `{“type”: “form”, “form”: {…}, “form_data”: {…}}` のような構造が考えられます。

メッセージと多様なPartを組み合わせることで、Agent2Agentはテキスト、ファイル、構造化データ、UI要素など、リッチな情報を標準化された方法で交換可能にし、高度な連携を実現します。

アーティファクト：タスクによって生成される成果物

リモートエージェントがタスクを実行した結果生み出す具体的な「成果物」を、Agent2Agentでは「アーティファクト (Artifact)」と呼びます。画像、ドキュメント、コード、分析結果データなど、タスクの目的に応じた多様な出力を表現します。

アーティファクトオブジェクトの構造:

アーティファクトは主に以下の要素で構成されます。

parts: 成果物の内容を保持する「Part」オブジェクト（TextPart, FilePart, DataPart）の配列。必須です。これにより、テキストの説明と生成された画像を一つの成果物としてまとめる、といったことが可能です。
name (オプション): アーティファクト名（例: “report.pdf”）。
index (オプション): 複数アーティファクト生成時の順序（0始まり）。ストリーミング更新時の識別にも使用。
append (オプション, デフォルト false): ストリーミング更新時に、既存アーティファクトに追加するか(true)、置き換えるか(false)を指定。

アーティファクトの役割:

最終成果物の提示: タスク完了時にTaskオブジェクトのartifactsフィールドに含まれ、クライアントに渡されます。
中間成果物の共有: ストリーミング利用時、タスク実行中にTaskArtifactUpdateEventとしてクライアントに逐次送信されることがあります。JS Coder Agentサンプル（下記）では、生成中のコードがファイルごとにアーティファクトとしてストリーミングされます。

このファイル内の coderAgent 非同期ジェネレータ関数の中で、ai.generateStream から得られたストリーミングデータ (chunk) を処理し、ファイルの内容が更新されるたびに、あるいはファイルが完成したと判断されたタイミングで、以下のような形式のオブジェクトを yield しています。

yield {
  index: prevFileIndex, // アーティファクトのインデックス
  name: prevFilename,   // アーティファクト名（ファイル名）
  parts: [{ type: "text", text: prevFileContent }], // アーティファクトの内容
  lastChunk: true, // このファイルについては完了 (A2A仕様とは少し異なるが、意図は同様)
};

この yield されるオブジェクトが、A2Aプロトコルにおける TaskArtifactUpdateEvent に相当する情報をクライアント（この場合は A2AServer の内部処理）に渡しており、「生成中のコードがファイルごとにアーティファクトとしてストリーミングされる」という挙動を実現しています。

アーティファクトにより、Agent2Agentは多様な形式の成果物を標準化して扱え、エージェントは具体的で価値ある出力を提供し、クライアントは一貫した方法で受け取れます。

コラボレーションの実現：対話を通じた協力

Agent2Agentプロトコルは、単なるタスク依頼・結果受領だけでなく、エージェント同士が「コラボレーション (Collaboration)」し、対話を通じて協力して目標達成することを可能にします。

A2Aにおけるコラボレーションの側面:

コンテキスト共有: クライアントは最初のメッセージでタスクの背景や目的を伝え、リモートエージェントの理解を助けます。
双方向の対話: リモートエージェントは確認事項や追加情報要求をメッセージで返し (input-required状態など)、クライアントとの対話を通じてタスクを進めます。
中間報告とフィードバック: ストリーミング時、リモートエージェントは処理の途中経過をメッセージで送信できます。
成果物の共有: 生成されたアーティファクトも、完了時だけでなく途中で共有されることがあります。
ユーザー指示の仲介: クライアントエージェントは、エンドユーザーからの追加指示をリモートエージェントに伝えます。

メッセージオブジェクトを介した柔軟な情報交換により、複数のエージェントが人間のように連携して複雑な問題を解決できます。これは、A2Aの重要な特徴であり、「エージェント能力の活用」原則にも繋がっています。

UX交渉：ユーザーに最適な体験を提供

AIエージェントが効果的に機能するには、ユーザーの利用環境（デバイス、インターフェース）に合わせた最適な表現方法（UX）を選択する必要があります。

Agent2Agentは、このための「ユーザー体験交渉 (User Experience Negotiation)」メカニズムを提供します。クライアントエージェント（ユーザー接点を持つ）とリモートエージェント（コンテンツ生成側）が、情報の提示方法や入力受付方法について調整します。

UX交渉のキーポイント:

クライアントの能力通知: クライアントは、自身がサポートするUI能力（画像表示可、フォーム表示可など）を、タスク依頼時の acceptedOutputModes パラメータ（受け入れ可能なMIMEタイプリスト）等でリモートに伝えます。
コンテンツタイプの明示: リモートは、生成するPartにMIMEタイプを指定します (例: “text/plain”, “image/png”, “application/json; type=form”)。
形式の選択とフォールバック: リモートは、クライアントのacceptedOutputModesに合わせて最適な出力形式を選択します。対応していなければ代替形式（例: フォーム→テキスト質問）で応答します。
多様なUI要素への対応: テキストやファイルだけでなく、iframe, ビデオストリーミング, Webフォームなどの交換も想定しています。

このUX交渉により、Agent2Agentシステムはユーザー環境に応じて表示や対話を動的に最適化し、利便性とアクセシビリティを高めます。

ストリーミング対応：リアルタイムな進捗と結果

AIエージェントのタスクには完了までに時間がかかるものがあります。その間、ユーザーやクライアントがただ待つのはUXが良くありません。

Agent2Agentは「ストリーミング (Streaming)」機能でこれに対応します。リモートエージェントがタスク実行中に、進捗や中間結果をリアルタイムでクライアントに継続送信する仕組みです。

ストリーミングの仕組みと利点:

Server-Sent Events (SSE) 利用: Web標準技術SSEを基盤とし、サーバーからクライアントへの効率的な一方向データプッシュを実現します。
tasks/sendSubscribe メソッド: クライアントがストリーミング更新を受けたい場合にタスク開始に使用するAPI操作名です。
能力の事前確認: Agent Cardの capabilities.streaming プロパティで対応可否を確認できます。
リアルタイム更新通知 (イベント): SSEを通じて以下のJSONイベントが送信されます。
- TaskStatusUpdateEvent: タスク状態変化や中間メッセージ (status.message) を通知。イベントデータは、タスクIDを示すidと、TaskStatusオブジェクトを含むstatusを持ちます。finalプロパティがtrueならストリーム終了を示します。
- TaskArtifactUpdateEvent: 生成された成果物 (artifact) を通知。イベントデータは、タスクIDを示すidと、Artifactオブジェクトを含むartifactを持ちます。
ユーザー体験向上: クライアントは進捗や生成コンテンツを逐次表示でき、ユーザーの待ち時間ストレスを軽減します。ブログ記事で述べられている「リアルタイムのフィードバック、通知、状態更新」が可能になります。

Agent2Agentのストリーミングは、特に応答に時間のかかるタスクにおいて、インタラクティブな連携とUX改善を実現する重要な機能です。

プッシュ通知機能：非同期連携の実現

ストリーミングは常時接続が必要ですが、非常に長時間のタスクや、クライアントのネットワークが不安定な場合、あるいはクライアントがサーバーからの接続を受け付けられない環境では不向きです。

このため、Agent2Agentは「プッシュ通知 (Push Notifications)」による非同期連携も提供します。リモートエージェントがタスクの重要更新（状態変化、完了、入力要求など）を、クライアント指定のWebhook URLに能動的にHTTPリクエストで通知する仕組みです。

プッシュ通知の仕組みと設定:

対応確認: Agent Cardの capabilities.pushNotifications プロパティで確認。
設定登録 (tasks/pushNotification/set): クライアントが、対象タスクID (id) と、通知先URL (url) ・認証情報 (authentication) を含むPushNotificationオブジェクトを指定して呼び出すAPI操作名。
設定取得 (tasks/pushNotification/get): 設定済み情報を取得できるAPI操作名。
Webhook エンドポイント: クライアント側で通知を受け取るHTTPエンドポイントを実装します。
通知内容: リモートエージェントは、重要更新時にWebhook URLへ、TaskStatusUpdateEvent または TaskArtifactUpdateEvent を含むHTTP POSTリクエスト等を送信します。
URL検証 (オプション): サンプルコードのように、リモートが設定時にURLの正当性をGETリクエスト等で確認できます。
認証 (セキュリティ): なりすまし防止のため、JWTによる署名検証が推奨されます。リモートは秘密鍵でJWTを生成しAuthorization: Bearerヘッダーで送信。クライアントは事前に取得した公開鍵（例: /.well-known/jwks.json）でJWT署名を検証し、ボディのハッシュ値も照合して正当性を確認します。iat（発行時刻）チェックでリプレイ攻撃も防ぎます。

プッシュ通知により、クライアントエージェントはリモートエージェントとの常時接続を維持する必要がなくなり、より柔軟でスケーラブルな非同期連携が可能になります。

Agent2Agentの活用事例：デモに見る連携の実際

ユースケース紹介：候補者ソーシングプロセスの自動化

Agent2Agentが実際のビジネスプロセスをどう効率化するか、Google Developers Blogで紹介された「ソフトウェアエンジニアの候補者ソーシング」例を見てみましょう。

従来の課題: 採用担当者は、候補者検索、連絡、面接設定、評価、背景調査など多くのステップを、複数のツールで手作業で行う必要がありました。

Agent2Agentによる解決策: ユーザー（採用担当者）は「Agentspace」のような統合インターフェースから「ホストエージェント」に指示します。

指示: 「〇〇ポジション、XX地域、YY/ZZスキルに合う候補者を探して」
連携開始 (A2A): ホストエージェントは指示を理解し、A2Aで専門リモートエージェント（候補者検索、スキル評価など）にタスク依頼。
結果集約: 各リモートエージェントが結果を返し、ホストが集約してユーザーに提示。
追加指示: ユーザーが候補者リストを確認し、「面接を設定して」と指示。
次の連携 (A2A): ホストはA2Aで「面接設定エージェント」（カレンダー連携、候補者連絡担当）に依頼。
さらなる連携 (A2A): 採用候補者が絞られたら、ユーザー指示でホストはA2Aで「背景調査エージェント」に依頼。

この連携フローは、次に紹介するデモ動画（次項で解説）で視覚的に確認できます。Agent2Agentにより、単一インターフェースからの指示で、裏側で専門エージェントが連携し、採用プロセス全体を効率化。担当者は候補者評価など、より本質的な業務に集中できます。

デモ動画から読み解くAgentSpace連携フロー

以下のデモ動画は、Agent2Agentプロトコルによる連携が実際にどのように機能するかを具体的に示しています。

出典：https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

動画から読み取れる連携フロー:

ユーザーはAgentSpaceで「ホストエージェント」に自然言語で指示（例: 「候補者を探して」）。
ホストエージェントは指示を解釈し、最適な「リモートエージェント」にA2Aでタスクを委任。
リモートエージェントが処理を実行（例: DB検索）。
リモートは結果（例: 候補者リスト）をA2Aでホストに返却（ストリーミングならリアルタイム）。
ホストは結果を整理し、AgentSpace上でユーザーに提示。
ユーザーは提示情報に基づき追加指示（例: 「面接を設定して」）。
ホストは再びA2Aで別エージェント（例: 面接設定エージェント）に連携。
フォーム表示など、リッチなインタラクションも可能（A2AのUX交渉とDataPart活用）。

このデモは、Agent2Agentにより、異なるAIエージェントがユーザー中心にシームレスに連携し、複雑なワークフローを効率化できることを具体的に示しています。

デモアプリケーションの構造：UI, ホスト, リモート連携

GitHub公開のAgent2Agentデモアプリは、A2Aシステム構築の具体例です。主に3つのコンポーネントで構成されます。

このアーキテクチャ図はデモアプリの構成を示しています:

フロントエンド (Mesop UI):
- ユーザーインターフェース (Python製Mesopフレームワーク)。
- ユーザー入力をホストエージェントに送信し、応答（テキスト、フォーム、画像等）を表示。
- 新エージェント追加、会話、履歴/ログ閲覧機能を提供。
ホストエージェント (Google ADK):
- アプリ中核。ユーザー指示を解釈し、適切なリモートエージェントにタスクを委任するオーケストレーター。
- Google ADKで実装 (samples/…/host_agent.py)。
- リモートからの応答を集約し、UIに渡す。
リモートエージェント接続 (ADK + A2A Client):
- 外部A2Aサーバー（専門エージェント）への接続部。
- ADKエージェントでラップされ、内部でA2AClientを使用 (samples/…/remote_agent_connection.py)。
- Agent Card取得後、A2Aで外部サーバー（LangGraph, CrewAI等）にタスク依頼をプロキシ。
- 外部からのA2A応答（タスク状態、アーティファクト）を受け取りホストに伝達。

この構造により、UIはホストエージェントとのみ通信し、ホストがA2Aによる外部連携を管理。スケーラブルで保守性の高いマルチエージェントシステム構築が可能になります。

Agent2Agentの未来：エコシステムと発展性

広がる協力の輪：50社以上のパートナー企業

Agent2AgentはGoogle単独ではなく、AIエージェント技術の未来を共創する50社以上の企業との協力で推進されています。

パートナーは多岐にわたります:

大手テクノロジー/プラットフォーム企業: Atlassian, Box, Cohere, Intuit, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UKG, Workday 等。自社サービスとA2A連携を進め、統合されたユーザー体験を目指します。
AI関連ツール/サービス企業: Langchain, Arize AI, C3 AI, DataStax, Datadog, Elastic, Weights & Biases 等。A2Aを自社ツールに組み込み、開発者のA2Aエージェント構築・運用を支援します。
コンサルティング/SI企業: Accenture, BCG, Capgemini, Deloitte, KPMG, McKinsey, PwC, TCS, Wipro 等。顧客企業のA2A活用によるシステム変革を支援します。

この広範な協力体制は、Agent2Agentがオープンな業界標準として発展する強力な基盤となります。多様なプレイヤーが連携し、組織やシステムの壁を越えたAIエージェントによる効率化とイノベーションを目指します。

パートナー企業からのコメント：A2Aへの期待

Agent2Agent発表に際し、多くのパートナーから期待の声が寄せられています。

Atlassian: A2Aはエージェント間の発見・調整・推論を助け、大規模連携を可能にする。
Box: BoxエージェントとGoogle Cloudエコシステムの連携で、ワークフロー自動化や信頼できるAI出力を推進。
Cohere: オープンなA2Aはセキュアな環境でも信頼できる連携を保証し、企業の大規模イノベーションを支援。
LangChain: エージェント間対話は近い未来。ビルダーとユーザーのニーズを満たす共有プロトコルで協力。
Salesforce: A2A標準サポートを主導し、Agentforce内外のエージェント連携でデジタルワークフォースを強化。
SAP: A2Aでエージェント相互運用性の未来を形成。SAP Joule等が企業プラットフォーム間で連携し、ビジネスプロセスを最大化。
ServiceNow: Google Cloudと協力し業界標準を設定。A2Aは効率的で接続されたサポート体験を開く。
Accenture: A2Aはドメイン固有エージェントを結ぶ架け橋。シームレスな通信と集合知を可能に。
Deloitte: A2Aイニシアチブはエコシステムを結集させ、AI採用を加速させる。

これらのコメントは、セキュリティ、拡張性、統合、自動化、標準化、エコシステム形成といったA2Aへの多様な期待を示しています。

将来のロードマップ：プロトコルとサンプルの進化

Agent2Agentは継続的に進化します。フィードバックに基づき、プロトコルとサンプル実装の両方が改善される予定です。

GitHubリポジトリで示唆される将来計画:

プロトコルの改善計画:

エージェント発見強化: Agent Cardへの認証情報・方式の明確な標準化検討。
連携能力の動的確認: 未知スキルを問うQuerySkillメソッド等の検討。
タスク中のUX交渉: 実行中にUI形式（テキスト→音声等）を動的変更・交渉する仕組み検討。
通信機能拡張・改善: タスク管理以外のクライアントメソッド呼び出しサポート、ストリーミング/プッシュ通知の信頼性向上探求。

サンプルとドキュメントの改善計画:

入門容易化: 「Hello World」サンプルをよりシンプルに。
ユースケース拡充: 各種フレームワーク連携や特定機能（フォーム、ファイル転送等）のサンプル追加。
ライブラリ文書充実: 共通クライアント/サーバーライブラリ（Python, JS）の詳細文書作成。
仕様書可読性向上: JSON Schemaから読みやすいHTML仕様書を自動生成する仕組み導入。

これらの改善により、Agent2Agentはより成熟し、開発者が多様なシナリオで活用しやすくなることを目指します。ブログ記事によると2025年後半には本番利用可能なバージョンのリリースが目標です。

コミュニティへの参加方法：貢献とフィードバック

Agent2Agentはオープンソースプロジェクトであり、コミュニティからの参加と貢献を歓迎しています。

参加・貢献の方法:

仕様・文書レビュー/フィードバック: 公式ウェブサイトやGitHubリポジトリの仕様ドラフト・文書を確認し、GitHub Issuesで報告・提案。非公開フィードバックはGoogleフォームから。
GitHub Discussions参加: 設計思想、ユースケース等について、GitHub Discussionsで意見交換。
サンプルコード利用・貢献: Python / JavaScriptサンプルを試用し、バグ報告や改善提案、新サンプルのプルリクエストを行う。
ドキュメント貢献: ドキュメントの修正、改善、翻訳等で品質向上に貢献（プルリクエスト）。詳細はコントリビューションガイド参照。
CLA署名: コードやドキュメントへの貢献（プルリクエスト）にはGoogle CLAへの同意・署名が必要。

プロジェクトはGoogle OSS Community GuidelinesとCode of Conductに基づき、オープンで建設的なコミュニティを目指しています。ぜひ参加し、プロトコルの発展に貢献してください。

開発者向けガイド：Agent2Agentの実装に向けて

公式ドキュメントとJSON仕様の読み解き方

Agent2Agent開発の第一歩は、公式技術ドキュメントとJSON仕様の理解です。

技術ドキュメント:
- 場所: A2A Website – Documentation
- 内容: プロトコル全体像、主要概念（Agent Card, Task等）、APIメソッド解説。
- 活用法: 全体像と機能概要を把握。実装したい機能の関連セクションを重点的に読む。
JSON仕様:
- 場所: GitHub – specification/json/a2a.json
- 内容: 全データ構造（リクエスト、レスポンス、オブジェクト）をJSON Schema形式で厳密に定義。フィールド型、必須/任意、説明など。
- 活用法: プロトコルの「設計図」。実装時に参照し、送受信データが仕様準拠か確認。主要パラメータ（例: TaskSendParams内のid, message）やレスポンス構造、エラーコード（例: -32000 Task not found）を正確に把握。ツールによるデータクラス自動生成も可能。

技術ドキュメントで概要を掴み、JSON仕様で詳細を確認する流れが効果的です。これらを活用し、プロトコル理解に基づいた実装を目指しましょう。

サンプルコード（Python/JS）の活用方法

公式サンプルコードは、Agent2Agentプロトコルの実装方法を具体的に学ぶための非常に強力なツールです。

活用方法 (Python, JavaScript):

基本動作の確認: CLIホストとサンプルエージェントを動かし、Agent Card取得、タスク送受信、ストリーミング等を体験する。
クライアント/サーバー実装の理解: 共通ライブラリのコードを読み、HTTP処理、JSON-RPC処理、SSEハンドリング、エラー処理、タスク管理等の実装方法を学ぶ。
フレームワーク連携の学習: 各サンプルエージェント（ADK, LangGraph, CrewAI, Genkit等）が、それぞれのフレームワーク上でA2Aサーバー機能をどう実装しているか（タスク処理のラップ方法、ストリーミング対応等）を確認する。
- PythonサンプルではTaskManager継承、on_send_task/on_send_task_subscribeオーバーライドが一般的。
- JS (Genkit) サンプルではTaskHandler (非同期ジェネレータ)内でGenkit APIを呼び出しTaskYieldUpdateをyield。
特定機能の実装例参照: フォーム送受信（ADK）、画像ファイル扱い（CrewAI）、プッシュ通知（LangGraph + CLI）など、目的に合ったサンプルを参照する。
開発のスタート地点として: Apache 2.0ライセンスのため、雛形として利用・改変が可能。

実際に動かし、デバッグすることで理解が深まります。各サンプルのREADMEで前提条件を確認してください。

主要トピック解説：A2AとMCP、発見、エンタープライズ、通知

Agent2Agentプロトコルを使いこなす上で、特に知っておきたい重要なポイントがいくつかあります。公式ドキュメントサイト(A2A Website)でも詳しく解説されている、以下の4つのトピックについて、もう少し具体的に見ていきましょう。

A2A ❤️ MCP (A2AとMCPの関係): 「仲間」と「道具」の使い分け
- 解説ページ
- 考え方: A2AとMCPはライバルではなく、役割分担するパートナーです。MCPはAIエージェントが特定の機能を持つ「道具」（APIやデータベース検索ツールなど、決まった作業をするもの）を使うためのルールです。一方、A2AはAIエージェント同士が「仲間」として、相談したり、仕事を分担したりするためのルールです。
- 具体例: 例えば、旅行計画エージェントを考えましょう。フライトの空席を調べる（決まった作業）にはMCPで「空席検索ツール」を使います。しかし、「どんな観光地がおすすめ？」と別の「観光情報エージェント」に相談したり、「ホテル予約お願いできる？」と「ホテル予約エージェント」に依頼したりする場面では、A2Aを使って対話や協力を行います。
- ポイント: 複雑な仕事をするには、「道具（MCP）」と「仲間（A2A）」の両方が必要になることが多いのです。どちらのプロトコルを使うかは、連携相手が「決まった作業をするツール」なのか、「自律的に考えて対話できるエージェント」なのかで見極めるのが良いでしょう。
エージェント発見 (Agent Discovery): 仲間探しと自己紹介
- 解説ページ
- 考え方: 新しい友達を探すとき、まず相手がどんな人か知りたいですよね？エージェント発見は、まさにそれと同じです。他のエージェントが「何ができるのか」「どうやって話しかければいいのか」を知るための仕組みです。
- 具体例: その中心となるのが「Agent Card」というJSON形式のファイルです。これはエージェントの「自己紹介カード」のようなもので、通常、Webサイトの決まった場所（`/.well-known/agent.json`）に置かれています。このカードには、エージェントの名前、得意なこと（スキル）、どんな話し方（テキスト？画像もOK？）ができるか、話しかけるためのアドレス（URL）、そして特別な話し方（認証方法）が必要か、などが書かれています。
- ポイント: クライアントエージェントは、このAgent Cardを読むことで、仕事を頼みたい相手を見つけ、そのエージェントに合った方法でコミュニケーションを始めることができます。
エンタープライズ対応 (Enterprise Ready): 会社で安心して使うために
- 解説ページ
- 考え方: 会社で使うシステムには、特に安全性や信頼性が求められます。A2Aは、企業が安心して使えるように、セキュリティなどをしっかり考慮して設計されています。
- 具体例: 例えば、「Secure by default（最初から安全第一）」という考え方で作られており、通信相手が本物かを確認する「認証」や、何をして良いかを決める「認可」の仕組みを、Webサービスで広く使われているOpenAPIという規格と同じレベルでサポートすることを目指しています。また、もし通信中に問題が起きても、JSON仕様で定義されたエラーコード（例: `-32600 Invalid Request`：リクエストがおかしいよ、`-32601 Method not found`：そんな命令はないよ、`-32001 Task not cancelable`：その仕事はキャンセルできないよ）を使って、何が問題なのかを分かりやすく伝えられるようになっています。
- ポイント: これにより、企業はセキュリティリスクを抑えつつ、A2Aを使ったエージェント連携システムを導入・運用できます。
プッシュ通知 (Push Notifications): 「終わったら教えて！」を実現
- 解説ページ
- 考え方: 時間のかかる作業を誰かにお願いしたとき、ずっと隣で見ているわけにはいきませんよね。「終わったら教えて」と頼んでおくのが普通です。プッシュ通知は、AIエージェント間でそれを実現する仕組みです。
- 具体例: クライアントエージェントは、タスクを依頼する際に「終わったり、何か進捗があったら、この連絡先（Webhook URLという特別なWebアドレス）に知らせてね」とリモートエージェントに伝えます。リモートエージェントは、タスクが完了したり、追加情報が必要になったりした時に、その連絡先にメッセージを送ります。この時、送られてきたメッセージが本当に頼んだ相手からのものかを確認するために、「デジタル署名（JWT/JWK認証）」という本人確認の仕組みも使われます。
- ポイント: これにより、クライアントはずっと接続し続ける必要がなくなり、特にスマホアプリのように接続が不安定な場合や、非常に時間のかかるタスク（数日かかることも！）を扱う場合に便利です。

この図は「A2A ❤️ MCP」トピックで参照されているもので、両プロトコルがエージェントアプリケーション内でどのように連携するかを示しています。

これらの解説を読むことで、Agent2Agentの背景思想や特定機能の詳細理解が深まり、効果的なアプリケーション設計・実装に繋がります。

本記事をご覧いただいた方にはこちらの資料がおすすめです！

【目的別】生成AIの使い方がわかる！生成AI活用事例集

「生成AIって色々ありすぎてよくわからない・・・」という方向けに、汎用型生成AIであるChatGPT、Claude、Gemini、Perplexityの比較や、画像、音声、動画生成のツールなどを、どの様な場面のときにどのように使用するのが効果的かという点を重点的に、事例をまとめて紹介いたします。これを読めば、生成AIの効果的な使い方がわかります！本資料は、