🌏

Agent2Agent（A2A）技術解説ブログ

2025/07/06に公開

 第1章 はじめにAnnouncing the Agent2Agent Protocol (A2A)

 1.1 背景2024～2025年にかけて、生成AIは「1アプリ＝1エージェント」から複数エージェントが協調してタスクを解決する“マルチエージェント時代”へ急速にシフトしました。検索・要約・コーディング・ワークフロー自動化など、異なる専門性を持つエージェントが同じ業務フローに並列参加するケースが増えたことで、相互運用（インターオペラビリティ）を満たす標準プロトコルの欠如がボトルネックに浮上しています。こうした課題を受けてGoogle Cloudは2025年3月にAgent2Agent（A2A）を提唱しました。

 1.2 A2Aの目的A2Aプロトコルは「エージェント同士が 安全に発見し合い、意思を共有し、合意形成を行い、協調アクションを実行する」ためのオープンかつベンダーフリーな共通言語を提供します。50社を超えるSaaSベンダー／SIer が賛同し、Box・Salesforce・ServiceNowなど既存ビジネスアプリとの連携を視野に入れた設計が特徴です。

 1.3 オープンガバナンスへの移行公開後わずか2か月で、A2AはLinux Foundation傘下のAgent2Agent Projectとして寄贈され、Google・Amazon・Ciscoらが発起メンバーとなりました。これにより中立的なガバナンスモデルの下で仕様策定・実装・IP 管理が行われる体制が整い、今後の長期的な普及と拡張が期待されています。

 1.4 オープンソース実装の位置付けGitHubで公開されているa2aproject/A2AはTypeScript製のリファレンス実装で、JSON Schemaに基づくコア仕様、CLI／サーバーランタイム、各言語 SDK（Python・Java・Go など）を包括的に提供します。開発者は同リポジトリをforkするだけでローカル環境にエージェントを立て、サンプル集で通信フローを即座に再現できます。a2aproject/A2A

 1.5 本ブログのゴール本シリーズではA2Aのプロトコル仕様、アーキテクチャ、セキュリティ設計、OSSエコシステム、パフォーマンス検証、研究トピックを体系的に解説し、以下の疑問に答えることを目的とします。

なぜA2Aが必要なのか？ 既存API連携やMCP（Multimodal Communication Protocol）とどう違うのか

どのように実装するのか？ SDK／CLIを用いた最小構成とCI/CDパイプライン

研究開発で押さえるべきポイントは？ 意図理解アルゴリズム、フェデレーテッド学習、マルチモーダル拡張

エンタープライズ導入時の論点は？ ガバナンス、監査、ゼロトラスト、SLA／スループット指標
これから順を追って技術詳細を掘り下げていくので、A2A を自社プロダクトに組み込みたいあるいはマルチエージェント連携の研究テーマを探しているという方はぜひ最後までお付き合いください。

 第2章 A2Aプロトコル概要
 2.1 定義とスコープAgent2Agent（A2A）はAI エージェント同士がタスク指向で安全に協調するためのオープン・プロトコルです。JSON-RPC 2.0 over HTTP(S)をベースに、同期/ストリーミング（SSE）/非同期pushという３形態の通信をカバーし、テキスト・ファイル・構造化JSONまで扱える汎用メッセージレイヤーを提供します。Agent2Agent (A2A) Protocol

スコープは①エージェントの発見、②タスク管理、③ステート同期、④ユーザー体験（UX）交渉の４機能に絞られており、モデル実行やツール呼び出しは対象外です。これにより任意の LLM／フレームワークを抱えた“ブラックボックス”エージェントでも相互運用が可能になります。

 2.2 設計原則（5 Key Principles）Google Cloudと50社超のパートナーが策定したA2Aは、以下５つの原則に従います。


#
原則
意図


1
Agent-First
内部メモリやツールを公開せず “純粋なエージェント” として協調できる

2
既存標準の活用
HTTP・SSE・JSON-RPCなど既存IT資産と親和性を確保

3
Secure by Default
OAuth2／OpenAPI相当の認証・認可を前提に設計

4
Long-Running Task 対応
研究タスクなど数時間～数日掛かる処理でも途中経過をストリーム共有

5
Modality Agnostic
テキストだけでなく画像・音声・動画も扱えるメッセージ部品構造


 2.3 プロトコルスタックと通信モデル
Agent Card（発見）
JSON ファイルで公開されるメタデータ。スキル、インターフェース URL、認証方式を宣言。


Handshake（確立）
Client AgentがRemote AgentのAgentCardを取得し、送信可能コンテンツタイプや認証方式をネゴシエート。


Task Lifecycle（管理）

Taskオブジェクトを中心にcreate → update → completeイベントで状態遷移。生成物はArtifactとして共有。


Message Parts（UX 交渉）
各メッセージは複数partを持ち、content-typeごとにUI要件（iframe, video など）を宣言してフォールバックを防止。


 2.4 コアデータ構造

構造体
主キー
主なフィールド
補足


AgentCard
id

skills[], endpoint, auth

Static JSON。Discovery APIまたはOSS Directoryに登録

Task
task_id

state, inputs, outputs, owner_agent


stateは pending / running / completed / failed

Message
message_id

task_id, sender, parts[]

各partにmime_type, size, url


Artifact
artifact_id

task_id, type, payload_ref

生成物（画像・PDFなど）を指すBlob参照


 2.5 セキュリティとガバナンス
AuthZ/AuthNはBearer Token（OAuth2/JWT）、双方向TLS、あるいはカスタムAPI Keyをサポート。

暗号化はTLS+メッセージ署名。メッセージ部分暗号化の拡張提案もGitHub Issueで議論中。

監査ログはtask.event_logとしてJSON Linesでエクスポート可能。SIEM連携も想定。

 2.6 Linux Foundation への寄贈とOSSガバナンス2025年6月、Google CloudはA2AをLinux Foundation Agent2Agent Projectとして寄贈。AWS・Cisco・Microsoft・Salesforceなどがファウンディングメンバーとなり、中立的な仕様策定・IP管理が敷かれました。

ライセンスはApache 2.0。GitHub上のPRはGovernance WGが3営業日以内に一次レビューし、仕様変更は2/3多数決でマージ、といった運営ルールが公開されています。

 2.7 OSS リファレンス実装の位置づけGitHub a2aproject/A2AにはTypeScript サーバー / CLI と SDK ファミリー（Python・JS・Java）が同梱され、TaskライフサイクルやAgentCard Schemaの公式サンプルが提供されています。研究・PoCではまず npm i @a2a-js/sdk && a2a run samples/hello-worldで動かし、Protocol観測ツールa2a monitorでパケットを確認するのが最速です。

 第3章 アーキテクチャと通信モデル!本章の狙い

この章では、A2Aがどのようにエージェント間通信を設計しているかを――役者・フロー・データ構造・トポロジまで――コードと仕様の両面から把握します。

 3.1 主要コンポーネントと役割

役者
説明
実装上のファイル例


User
人間または外部サービス。Host Agent に指示を与える
－

Host Agent：Client Agent
ユーザに最初に応答し、適切なRemote Agentへタスクを委譲する“プロジェクトマネージャ”
src/server/host.ts

Remote Agent：Specialist
専門タスクを実行。自身の能力をAgent Cardで公開
examples/weather/agent.ts

Discovery Directory：任意

.well-known/agent.jsonをクローリングしてAgent Cardをカタログ化
services/discovery.ts

エージェント自身はクライアントにもサーバーにもなり得る ― 典型的には “スター型” でHostがハブとなりますが、途中で役割が入れ替わることも許容されます。

Agent In the Middle – Abusing Agent Cards in the Agent-2-Agent (A2A) Protocol To ‘Win’ All the Tasks

agents

 3.2 基本シーケンス（High-Level Flow）
Agent Discovery
Host AgentはURLもしくはDirectoryからAgent Card(JSON)を取得。


Handshake

GET /.well-known/agent.json → POST /handshake で MIME type・認証方式を交渉。


Task Create
HostがPOST /taskにTaskを作成（状態 = pending）。


Task Run & Streaming Updates
Remote AgentはPUT /task/{id}で状態をrunningに更新し、必要に応じSSEで部分結果をpush。


Task Complete / Fail
最終結果をArtifactとしてアップロードし、状態をcompleted／failedで確定。


Result Merge
Host Agentは複数Agentの成果物をマージし、Userへ応答。

ポイント ― タスクが “長時間” 化した場合でも、SSE により進捗メッセージをストリーム送信できる。

 3.3 タスクライフサイクル!pending → running → (intermediate updates) → completed / failed / cancelled

Check-points：updateイベントで目前の進捗を共有

Retries：failed → running で再開可

Cancellation：UserもしくはHostがDELETE /task/{id}で中断

A2Aは “仕事単位＝Task” を第一級概念に据え、MCPの関数呼び出し型とは対照的に状態管理を組み込みますMCP and A2A, what are these Protocols?,A2A Protocol Simply Explained: Here are 3 key differences to MCP!

 3.4 ３つの通信チャネル

チャネル
使われる場面
トランスポート


同期リクエスト／レスポンス
軽量・即時応答タスク
JSON-RPC 2.0 over HTTPS

ストリーミング
長時間タスクの経過報告
Server-Sent Events (SSE)

非同期 Push
バックグラウンド完了通知
Webhook (HTTP POST)

設計原則Async-Firstにより、遅延やネットワーク分断を前提とした非同期設計がデフォルト。

 3.5 メッセージ構造と UX ネゴシエーション{
  "message_id": "msg-123",
  "task_id": "task-42",
  "sender": "agent://weather",
  "parts": [
    { "mime_type": "text/markdown", "content": "...", "ux": "chat" },
    { "mime_type": "image/png",     "url": "https://..." , "ux": "iframe" }
  ]
}

Multipart：テキスト・画像・JSONなどを同梱

UX Hint：uxフィールドにchat/iframe/videoを宣言し、フロントエンドでのレンダリング合意を取る仕組み。

Artifact：完成版ファイルはArtifactとしてタスク外に保存し、url参照で共有。

 3.6 典型トポロジ設計

トポロジ
特徴
採用例


スター型（Hub & Spoke）
Host Agentが全Remote Agentを管理。実装容易・集中管理
SaaSワークフロー自動化

チェーン型
タスク完了後に次Agentを選定して委譲。柔軟・レイテンシ増
研究用パイプライン

メッシュ型（P2P）
Agent間が自由に呼び出し。Discovery 負荷↑・単障害なし
大規模協調ボット

OSSリポジトリでは./samplesにスター型の最小例が含まれています。Agent2Agent: A practical guide to build agents

 3.7 コードベースとのマッピング

ディレクトリ
役割
関連セクション


schemas/

agent_card.schema.json・task.schema.json等のJSON Schema
3.1, 3.5

src/server/
HTTP & SSE サーバー、Webhook ハンドラ
3.2, 3.4

src/client/
SDK 利用例（タスク送信・ストリーム受信）
3.2

samples/
Hello-World, WeatherAgent など
3.6

読者はnpm start → curl -X POST /task でローカルにフルフローを再現できるので、ぜひ試してみてください。

 まとめA2Aは「エージェントを一つのマイクロサービス」と見立て、HTTP／SSE／Webhook の既存技術で疎結合ネットワークを構築するプロトコル です。タスクを中心に据えたstatefulな設計、豊富なストリーミング更新、UXネゴシエーションといった仕組みにより、長時間・多モーダル・高信頼のマルチエージェント連携を実現します。
次章では、これらの通信モデルを支えるセキュリティ機構（認証・暗号化・監査ログ）を掘り下げていきます。

 第4章 セキュリティ&コンフィデンシャリティ!本章のポイント

“エージェント同士が安全に協調する”──A2A の存在価値はまさにここにあります。TLSで包むだけでは十分ではなく、認証・認可・メッセージ完全性・可観測性・サプライチェーンまでを360°で設計するのがA2Aの流儀です。

 4.1 脅威モデルとゼロトラスト前提
境界の喪失：A2AはSaaS／オンプレ／エッジの混在を仮定し、ネットワーク境界を信用しません。

想定攻撃者：悪意あるエージェントの混入、途中経路での改ざん・リプレイ、LLMプロンプトインジェクション、秘密鍵漏えいなど。

基本方針：①通信は常に暗号化、②すべての呼び出しを認証、③重要データは署名・監査で追跡、④権限は最小化。Potential Attack Surfaces in Agent2Agent (A2A) Protocol

 4.2 認証 & 認可（AuthN / AuthZ）

項目
デフォルト
オプション
ガイドライン


プロトコル
OAuth 2.0 Bearer Token

OAuth 2.1（導入予定）、API Key
エージェント⇄エージェント間でもClient Credentials Flowを推奨
OAuth 2.1-compliant Authorization for A2A


IDトークン
JWT
mTLS + SPIFFE
JWTには agent_id scopes exp を必須に

権限制御
最小権限のスコープ
動的ABAC
「Task 作成」と「Artifact 取得」を分離し、長期トークンの横展開を防止


 4.3 通信経路の保護
TLS 1.3強制。暗号スイートはTLS_AES_128_GCM_SHA256以上。

mTLS（相互TLS）は機密ワークロード向けに推奨。Agent Cardでtls_required=trueを布告可能。

SSE / WebhookもすべてHTTPS上に載せる設計で、ポートバインディングの穴は残さない。

 4.4 メッセージ完全性 & 再送攻撃対策message_id   : UUID v7
timestamp    : RFC 3339 (ms 精度)
signature    : HMAC-SHA256( body, agent_secret )

署名ヘッダー：X-A2A-Signature -- 受信側はmessage_idとtimestampを照合し、リプレイを排除。

タスク状態遷移（pending→running→completed）でイミュータブルログを生成し、観測性と改ざん検知を両立。In-band confirmation

 4.5 部分暗号化（Part-Level Encryption）Draft Issue #390 “In-band confirmation” で、parts[n] ごとにSign → (Optionally) Encryptのハイブリッド方式が提案中。添付ファイルのみ暗号化し本文は平文など粒度制御が可能。
今後のPRでNoise-NNハンドシェイク採用／enc属性追加が議論されています。

 4.6 鍵管理 & ローテーション短期 JWT（≤15 min）＋Refresh Token

KMS連携：GCP KMS / AWS KMS / HashiCorp Vaultで対称鍵を集中管理

自動ローテーション：失効イベントはPOST /key-revoked Webhookでブロードキャスト

 4.7 監査ログと可観測性

ログ種別
保持単位
形式


Task Event Log
Task ごと
JSON Lines（state, actor, sig, latency_ms）

Access Log
Agent ごと
Common Log Format + JWT sub

A2A Inspector
開発時
gRPC Tap + WebUI でリアルタイム可視化
a2a-inspector


ログはSIEM（Chronicle / Splunk 等）連携を想定し、30日以上保存を推奨。

 4.8 サプライチェーン & SBOMリファレンス実装はSLSA Level 2 + Provenance（GitHub Actions → Sigstore） でビルド。

sbom.spdx.jsonを自動生成し、依存ライブラリをCVEスキャン。

OpenSSF Scorecardによる“0.91↑”をCI破線ラインとして設定。

 4.9 リスクとベストプラクティス

リスク
具体例
推奨対策


悪性エージェント混入
改ざんAgent CardでPIIを窃取
Directoryで署名付きAgent Card、LLM出力のフィルタリング
Potential Attack Surfaces in Agent2Agent (A2A) Protocol


Prompt Injection
悪意エージェントがSystem Promptを挿入
Content-Security-Policy相当のpolicyパラメータを導入

キー漏えい
長期API KeyのGitHub流出
15分JWT + 自動無効化Webhook

リプレイ攻撃

message_id使い回し
UUID v7 + 5minウィンドウで拒否


 4.10 コンプライアンス対応
GDPR / APPI：task.inputsに個人データ分類タグを付与し、自動マスキングを実装可能。

HIPAA：メッセージ暗号化 + 監査ログの改ざん防止で “addressable implementation spec” を充足。

ISO 27001：A.12（運用セキュリティ）／A.13（通信セキュリティ）を標準設定でカバー。

 4.11 まとめA2Aのセキュリティ設計は「既存 Web 標準 × エージェント固有要件」をブレンドし、Zero Trust ネイティブに落とし込んだ点が最大の特徴です。Transport-TLS → JWT / OAuth → 署名 → （将来）部分暗号化と多層で守り、さらにタスクイベントログとSBOMで“あとから検証できる安全”も担保します。

 第5章 オープンソース実装&GitHubリポジトリ徹底解剖!本章のゴール
GitHub上の公式実装群（A2A本体、各種SDK、ツール、サンプル）の全体像を把握する
ビルド／実行／テスト／リリースまでのDevOpsフローを具体的に示す
コントリビューションやセキュリティ運用のポイントを整理する

 5.1 リポジトリ・ファミリー構成

役割
Repo
主な言語 / LOC
更新頻度
コメント


仕様 & TypeScript 実装（コア）
a2aproject/A2A
TS ~18 K
週数回
仕様書（docs/）とリファレンス・サーバー／CLIが同梱

サンプル集
a2aproject/a2a-samples
多言語
週次
HelloWorldほか15以上のデモ

Python SDK
a2aproject/a2a-python
Py ~0.7 K
週次

pip install a2aで利用可。FastAPIベースのサーバー実装付き

Java SDK
a2aproject/a2a-java
Java ~1 K
週次
Spring Boot/Maven対応

JS / Node SDK
a2aproject/a2a-js
TS ~1 K
週次
ブラウザ & Node のクライアント／サーバー

Go SDK
a2aproject/a2a-go
Go
隔週
エッジ／IoT用の軽量実装

観測ツール
a2aproject/a2a-inspector
Py/React
隔週
SSEパケットをリアルタイム可視化


 5.2 A2A 本体ディレクトリ構成A2A/
├─ packages/
│  ├─ core/          # JSON-RPC ハンドラ & タスク状態機械
│  ├─ server/        # Express 製 HTTP & SSE サーバー
│  └─ cli/           # a2a <cmd>（init, run, inspect…）
├─ schemas/          # agent_card.schema.json, task.schema.json
├─ docs/             # 仕様書 (Markdown) / OpenAPI yaml
├─ .github/          # CI 定義 (lint, test, SLSA provenance)
└─ examples/         # ts-node で動く最小エージェント
ポイント

モノレポ＋PNPM Workspaces採用で依存を一元管理。
スキーマはJSON Schema $id バージョン付き。CLI の型生成にも利用。

OpenAPI 3.1 はnpm run openapiで生成し、SDK側のコード自動生成にも再利用。

 5.3 ビルド & 実行（TypeScript 実装）git clone https://github.com/a2aproject/A2A.git
cd A2A
pnpm i            # 依存解決
pnpm build        # tsc & schema generation
pnpm cli init     # ./agent-card.json を生成
pnpm cli run examples/echo-agent.ts
デフォルトでlocalhost:8080にHTTP + SSEサーバーを起動。

.well-known/agent.jsonと/taskエンドポイントが自動公開される。

 5.4 サンプルリポジトリ活用git clone https://github.com/a2aproject/a2a-samples.git
cd a2a-samples/samples/python/agents/helloworld
uv pip install -r requirements.txt
uv python agent.py      # Remote Agent
uv python test_client.py  # Host Agent
PythonサンプルはFastAPI + Uvicorn。Docker Composeも完備で即検証可能。
JavaScript サンプルはBunにも対応。WindowsユーザはNode版を推奨。

 5.5 SDK ファミリー quick look

SDK
主要クラス
特徴 / 補足



Python (a2a-python)

Agent, TaskClient, ArtifactStore

Pydantic v2 ベース。async/await対応


Java (a2a-java)

A2AServer, AgentCardBuilder

Spring Boot Auto-config、Maven Centralにパッケージ済


JS/TS (a2a-js)

A2AClient, A2AServer

Edge Functions（Vercel / Cloudflare）でそのまま動作


Go (a2a-go)

server.Agent, client.Client

gRPC-Gateway経由の高速実装、ARM64 バイナリ配布


 5.6 CI / CD & セキュリティサプライチェーン
GitHub Actions
Lint → Unit Test → Build → SBOM生成 → Sigstore Cosign署名 → Release。


SLSA Level 2 & OpenSSF Scorecardをパス。依存はDependabot PRで自動更新。

ProvenanceファイルはOCI ArtifactとしてGitHub Container Registryへpush。

 5.7 コントリビューション・フロー
Issue作成（feat: / bug: / spec: ラベル）

Fork → Draft PR（小変更なら直接 PR も可）

CLA（Apache 2.0）チェック & CI Greenを満たす

Governance WGが3日以内に一次レビュー → 2週間以内にマージ/リジェクト
!Tip

仕様変更は docs/spec/*.md にPR → spec-changeラベル必須。

 5.8 Dev Container & Docker// .devcontainer/devcontainer.json
{
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "postCreateCommand": "pnpm install && pnpm build",
  "features": { "docker-in-docker": "latest" }
}
VS Code Remote Containersでゼロセットアップ。

docker-compose.ymlにはHost + Remote Agent + Inspectorの３サービス定義がプリセット。

 5.9 テスト戦略

レイヤ
フレームワーク
カバレッジ目標


Unit
Vitest / Pytest / JUnit
90%以上

Contract
OpenAPI schema fuzz
100% schema pass

E2E
Playwright (Inspector UI)
タスク成功 / 失敗 / 再試行シナリオ

CI成功後a2a-inspectorでSSE ログを可視化し、リグレッションを確認するフローが推奨。

 5.10 リリース & バージョニング
SemVer (v0.x はドラフト、v1.0 で安定化予定)。

npm / PyPI / Maven Centralへ同時デプロイ（GitHub Release 名がタグ）。
LTS ブランチはrelease/v1 → セキュリティフィックス後ろ流し。

 まとめA2AのOSS 実装は「仕様・サーバー・CLI・多言語 SDK・可視化ツール・サンプル」 がモノレポ & サブレポで整理され、Docker / Dev Container / CI/CD / SLSAまで整備された“フルスタック・リファレンス”です。Forkして5分でローカル実行、PRで仕様に貢献、Inspectorで可視化──学習・検証・運用までワンストップで試せる点が最大の魅力と言えるでしょう。

 第6章 開発環境セットアップ&ハンズオン今後追記予定

 第7章 主要ユースケース今後追記予定

 第8章 MCPとの比較と相互運用今後追記予定

 第9章 パフォーマンス&スケーラビリティ検証今後追記予定

 第10章 研究開発トピック今後追記予定

 第11章 今後のロードマップとコミュニティ動向今後追記予定

 第12章 まとめ&次のステップ今後追記予定

役者	説明	実装上のファイル例
User	人間または外部サービス。Host Agent に指示を与える	－
Host Agent：Client Agent	ユーザに最初に応答し、適切なRemote Agentへタスクを委譲する“プロジェクトマネージャ”	`src/server/host.ts`
Remote Agent：Specialist	専門タスクを実行。自身の能力をAgent Cardで公開	`examples/weather/agent.ts`
Discovery Directory：任意	`.well-known/agent.json`をクローリングしてAgent Cardをカタログ化	`services/discovery.ts`

SDK	主要クラス	特徴 / 補足
Python (`a2a-python`)	`Agent`, `TaskClient`, `ArtifactStore`	Pydantic v2 ベース。async/await対応
Java (`a2a-java`)	`A2AServer`, `AgentCardBuilder`	Spring Boot Auto-config、Maven Centralにパッケージ済
JS/TS (`a2a-js`)	`A2AClient`, `A2AServer`	Edge Functions（Vercel / Cloudflare）でそのまま動作
Go (`a2a-go`)	`server.Agent`, `client.Client`	gRPC-Gateway経由の高速実装、ARM64 バイナリ配布

#	原則	意図
1	Agent-First	内部メモリやツールを公開せず “純粋なエージェント” として協調できる
2	既存標準の活用	HTTP・SSE・JSON-RPCなど既存IT資産と親和性を確保
3	Secure by Default	OAuth2／OpenAPI相当の認証・認可を前提に設計
4	Long-Running Task 対応	研究タスクなど数時間～数日掛かる処理でも途中経過をストリーム共有
5	Modality Agnostic	テキストだけでなく画像・音声・動画も扱えるメッセージ部品構造

構造体	主キー	主なフィールド	補足
AgentCard	`id`	`skills[]`, `endpoint`, `auth`	Static JSON。Discovery APIまたはOSS Directoryに登録
Task	`task_id`	`state`, `inputs`, `outputs`, `owner_agent`	`state`は pending / running / completed / failed
Message	`message_id`	`task_id`, `sender`, `parts[]`	各`part`に`mime_type`, `size`, `url`
Artifact	`artifact_id`	`task_id`, `type`, `payload_ref`	生成物（画像・PDFなど）を指すBlob参照

チャネル	使われる場面	トランスポート
同期リクエスト／レスポンス	軽量・即時応答タスク	JSON-RPC 2.0 over HTTPS
ストリーミング	長時間タスクの経過報告	Server-Sent Events (SSE)
非同期 Push	バックグラウンド完了通知	Webhook (HTTP POST)

トポロジ	特徴	採用例
スター型（Hub & Spoke）	Host Agentが全Remote Agentを管理。実装容易・集中管理	SaaSワークフロー自動化
チェーン型	タスク完了後に次Agentを選定して委譲。柔軟・レイテンシ増	研究用パイプライン
メッシュ型（P2P）	Agent間が自由に呼び出し。Discovery 負荷↑・単障害なし	大規模協調ボット

ディレクトリ	役割	関連セクション
`schemas/`	`agent_card.schema.json`・`task.schema.json`等のJSON Schema	3.1, 3.5
`src/server/`	HTTP & SSE サーバー、Webhook ハンドラ	3.2, 3.4
`src/client/`	SDK 利用例（タスク送信・ストリーム受信）	3.2
`samples/`	Hello-World, WeatherAgent など	3.6

項目	デフォルト	オプション	ガイドライン
プロトコル	OAuth 2.0 Bearer Token	OAuth 2.1（導入予定）、API Key	エージェント⇄エージェント間でもClient Credentials Flowを推奨 OAuth 2.1-compliant Authorization for A2A
IDトークン	JWT	mTLS + SPIFFE	JWTには `agent_id` `scopes` `exp` を必須に
権限制御	最小権限のスコープ	動的ABAC	「Task 作成」と「Artifact 取得」を分離し、長期トークンの横展開を防止

ログ種別	保持単位	形式
Task Event Log	Task ごと	JSON Lines（`state`, `actor`, `sig`, `latency_ms`）
Access Log	Agent ごと	Common Log Format + JWT sub
A2A Inspector	開発時	gRPC Tap + WebUI でリアルタイム可視化 a2a-inspector

リスク	具体例	推奨対策
悪性エージェント混入	改ざんAgent CardでPIIを窃取	Directoryで署名付きAgent Card、LLM出力のフィルタリング Potential Attack Surfaces in Agent2Agent (A2A) Protocol
Prompt Injection	悪意エージェントがSystem Promptを挿入	Content-Security-Policy相当の`policy`パラメータを導入
キー漏えい	長期API KeyのGitHub流出	15分JWT + 自動無効化Webhook
リプレイ攻撃	`message_id`使い回し	UUID v7 + 5minウィンドウで拒否

役割	Repo	主な言語 / LOC	更新頻度	コメント
仕様 & TypeScript 実装（コア）	`a2aproject/A2A`	TS ~18 K	週数回	仕様書（`docs/`）とリファレンス・サーバー／CLIが同梱
サンプル集	`a2aproject/a2a-samples`	多言語	週次	HelloWorldほか15以上のデモ
Python SDK	`a2aproject/a2a-python`	Py ~0.7 K	週次	`pip install a2a`で利用可。FastAPIベースのサーバー実装付き
Java SDK	`a2aproject/a2a-java`	Java ~1 K	週次	Spring Boot/Maven対応
JS / Node SDK	`a2aproject/a2a-js`	TS ~1 K	週次	ブラウザ & Node のクライアント／サーバー
Go SDK	`a2aproject/a2a-go`	Go	隔週	エッジ／IoT用の軽量実装
観測ツール	`a2aproject/a2a-inspector`	Py/React	隔週	SSEパケットをリアルタイム可視化

レイヤ	フレームワーク	カバレッジ目標
Unit	Vitest / Pytest / JUnit	90%以上
Contract	OpenAPI schema fuzz	100% schema pass
E2E	Playwright (Inspector UI)	タスク成功 / 失敗 / 再試行シナリオ

第1章 はじめに

1.1 背景

1.2 A2Aの目的

1.3 オープンガバナンスへの移行

1.4 オープンソース実装の位置付け

1.5 本ブログのゴール

第2章 A2Aプロトコル概要

2.1 定義とスコープ

2.2 設計原則（5 Key Principles）

2.3 プロトコルスタックと通信モデル

2.4 コアデータ構造

2.5 セキュリティとガバナンス

2.6 Linux Foundation への寄贈とOSSガバナンス

2.7 OSS リファレンス実装の位置づけ

第3章 アーキテクチャと通信モデル

3.1 主要コンポーネントと役割

3.2 基本シーケンス（High-Level Flow）

3.3 タスクライフサイクル

3.4 ３つの通信チャネル

3.5 メッセージ構造と UX ネゴシエーション

3.6 典型トポロジ設計

3.7 コードベースとのマッピング

まとめ

第4章 セキュリティ&コンフィデンシャリティ

4.1 脅威モデルとゼロトラスト前提

4.2 認証 & 認可（AuthN / AuthZ）

4.3 通信経路の保護

4.4 メッセージ完全性 & 再送攻撃対策

4.5 部分暗号化（Part-Level Encryption）

4.6 鍵管理 & ローテーション

4.7 監査ログと可観測性

4.8 サプライチェーン & SBOM

4.9 リスクとベストプラクティス

4.10 コンプライアンス対応

4.11 まとめ

第5章 オープンソース実装&GitHubリポジトリ徹底解剖

5.1 リポジトリ・ファミリー構成

5.2 A2A 本体ディレクトリ構成

5.3 ビルド & 実行（TypeScript 実装）

5.4 サンプルリポジトリ活用

5.5 SDK ファミリー quick look

5.6 CI / CD & セキュリティサプライチェーン

5.7 コントリビューション・フロー

5.8 Dev Container & Docker

5.9 テスト戦略

5.10 リリース & バージョニング

まとめ

第6章 開発環境セットアップ&ハンズオン

第7章 主要ユースケース

第8章 MCPとの比較と相互運用

第9章 パフォーマンス&スケーラビリティ検証

第10章 研究開発トピック

第11章 今後のロードマップとコミュニティ動向

第12章 まとめ&次のステップ

Discussion

第1章はじめに

第3章アーキテクチャと通信モデル

第4章セキュリティ&コンフィデンシャリティ

第5章オープンソース実装&GitHubリポジトリ徹底解剖

第6章開発環境セットアップ&ハンズオン

第7章主要ユースケース

第9章パフォーマンス&スケーラビリティ検証

第10章研究開発トピック

第11章今後のロードマップとコミュニティ動向

第12章まとめ&次のステップ