AI 開発

A2A Extensions は 9 月 9 日に何を公開したか？AI Agent 拡張と JSON プロトコル（2026）

JSONSort 2026-08-28 公開 2026-08-28 更新約 15 分

2025 年 9 月 9 日、Google は Developers Blog で A2A Extensions を公開した。Agent2Agent プロトコルに、差し込み可能なドメイン能力を足す仕組みだ。2026 年には、この「URI による識別 + Agent Card JSON での宣言 + A2A-Extensions ヘッダーでの交渉」が、複数 Agent 相互運用の第三のピースになっている——Function Calling、MCP と並ぶ位置づけだ。本稿では、その日に何が公開されたかを再現し、現行仕様に沿って JSON の書き方、交渉、実装まで分解する。

読む前の要点

観点	説明
公式公開	2025-09-09 Google Developers Blog《A2A Extensions: Empowering Custom Agent Functionality》
コア成果物	URI で識別する任意のプロトコル拡張：新しいデータ、新しい制約、新しい RPC、新しいステートマシン
JSON の置き場	Agent Card の `capabilities.extensions[]`
交渉方式	HTTP ヘッダー `A2A-Extensions`。デフォルトでは起動しない
2026 年の位置づけ	A2A は Agent 相互運用を担い、Extensions はドメインのカスタムを担う。MCP や Function Calling の代替ではない

9 月 9 日に何を公開したか？

A2A（Agent2Agent）はすでに、Agent 同士がどう発見し、タスクを送り、結果をストリーミングで返すかを定めている。しかしコアプロトコルは汎用でなければならない——「音声遅延のブロードキャスト」「エンドツーエンド追跡」「ゼロトラストのハンドシェイク」といった垂直機能を内蔵することはできない。2025 年 9 月 9 日、Google のエンジニアが公式ブログで出した答えが Extensions だった。

その日に公開されたのは、単一の新しい RPC ではなく、一式のオープンな拡張メカニズムである：

誰でも拡張を定義・公開・実装でき、一意の URI で識別する（バージョン番号を含めることを推奨。例：https://example.com/ext/my-extension/v1）。
Agent は Agent Card（能力を記述する JSON）で、どの拡張をサポートするかを宣言する。
Client は単一リクエスト上で HTTP ヘッダーにより必要なときだけ起動する。宣言していないクライアントはコアプロトコルのまま動き、壊れない。
公式は同時に Hello World を示した：Message / Artifact の metadata にタイムスタンプを付ける。

2026 年には、仕様は A2A Extensions の特集に書き込まれ、ガバナンス枠組みも現れている（公式拡張は https://a2a-protocol.org/extensions/ プレフィックスを使う）。以下、JSON プロトコルとしてメカニズムを分解する。

A2A プロトコルと Agent Card JSON

Agent Card は Agent の「機械可読な名刺」と考えてよい：名前、説明、入口 URL、入出力 MIME、スキル一覧、そして capabilities。Extensions は capabilities にぶら下がり、別ファイルにはしない。

拡張付き Agent Card は概ね次のとおり（構造は公式サンプル、フィールド名は現行仕様に従う）：

{
  "name": "Magic 8-ball",
  "description": "An agent that can tell your future... maybe.",
  "version": "0.1.0",
  "url": "https://example.com/agents/eightball",
  "capabilities": {
    "streaming": true,
    "extensions": [
      {
        "uri": "https://example.com/ext/konami-code/v1",
        "description": "Provide cheat codes to unlock new fortunes",
        "required": false,
        "params": {
          "hints": [
            "When your sims need extra cash fast"
          ]
        }
      }
    ]
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "fortune",
      "name": "Fortune teller",
      "description": "Seek advice from the mystical magic 8-ball",
      "tags": ["mystical"]
    }
  ]
}

この JSON をデバッグするときは、JSONSort の整形で括弧とカンマを確認してから、Schema と照合して extensions[] の欠落を見る。Agent Card はネットワーク上で公開されるので、params に秘密鍵を書いてはならない。

拡張メカニズム：宣言、デフォルトオフ、リクエスト単位で起動

Extensions の設計目標はA2A を拡張しつつコア標準を引き裂かないことだ。仕様はいくつかの境界を明示している：

デフォルトでは起動しない。 拡張を知らないクライアントでもコアメソッドを呼べ、ベースライン体験を得られる。
Client が能動的に opt-in する。 HTTP リクエストに A2A-Extensions を付け、値はカンマ区切りの URI リストとする。
Agent は未対応の URI を無視し、レスポンスヘッダーで実際に起動した拡張をエコーバックする。
required: true はハード依存。 クライアントが起動しない、または従わないなら、Agent はリクエストを拒否すべき。データ表示系の拡張に required を付けてはいけない。

拡張は他の拡張に依存できる（必須または任意）。仕様は拡張の説明書に依存関係を明記するよう求め、起動時は Client が依存 URI もまとめて付ける。バージョン番号は URI に書く：破壊的変更は必ず新しい URI に切り替え、Agent はこっそり別バージョンへフォールバックしてはならない。

AgentExtension JSON フィールド詳解

フィールド	型	意味
uri	string	拡張の一意な識別子。実装側はこれで起動するかを決め、Client はこれで互換性を判断する。
description	string	この Agent がその拡張をどう使うかを説明する。完全な意味論は拡張仕様ドキュメントに書く。
required	boolean	true のとき、Client は理解して従わねばならず、そうでなければリクエストは拒否されるべき。
params	object	拡張自身の設定。フィールドの意味は拡張仕様が定義し、デフォルト値や Agent 側の宣言を置ける。

仕様はさらに一線を引いている。拡張がコア型の検証を壊さないためだ：プロトコルが既に定義したデータ構造に必須フィールドを足したり削ったりしない。カスタム属性は既存の metadata map に入れる。列挙に新しい値を足さない。追加の意味も同じく metadata に書く。この二条が、JSON の形を直接決める。

リクエスト交渉：HTTP ヘッダー + JSON-RPC メッセージ

起動は「接続したら永続的にオン」ではなく、毎回の HTTP リクエストで起きる。典型的なリクエスト（公式 Hello World 風）：

POST /agents/eightball HTTP/1.1
Host: example.com
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "method": "SendMessage",
  "id": "1",
  "params": {
    "message": {
      "messageId": "1",
      "role": "ROLE_USER",
      "parts": [{"text": "Oh magic 8-ball, will it rain today?"}]
    },
    "metadata": {
      "https://example.com/ext/konami-code/v1/code": "motherlode"
    }
  }
}

対応するレスポンスは、起動に成功した拡張をエコーバックする：

HTTP/1.1 200 OK
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "message": {
      "messageId": "2",
      "role": "ROLE_AGENT",
      "parts": [{"text": "That's a bingo!"}]
    }
  }
}

注意点として、params.metadata のキーは拡張 URI にパス接尾辞を足したものであり、適当な短いフィールド名ではない。こうすれば複数の拡張が同じ JSON-RPC にデータを載せても名前が衝突しない。「拡張が効かない」を調べるときは、まずリクエストヘッダーに URI があるかを見て、次にリクエスト/レスポンス JSON を diff する——JSON Diff は、起動前後の metadata 比較に向いている。

4 種類の拡張：データ、Profile、メソッド、ステートマシン

仕様は「拡張で何ができるか」を意図的に広く書いているが、2026 年に見通せる用法は四類にまとめられる：

データ型（Data-only）：Agent Card に構造化情報を足すだけで、リクエスト-レスポンスの流れは変えない。例：GDPR 準拠フィールドの宣言。こうした拡張に required: true を付けてはいけない。
Profile 型：コアメッセージに、より厳しい構造や状態制約を重ねる。A2A に profile を一枚被せるイメージ。例：すべての parts が某 Schema に合う DataPart であること；または TaskStatus.state === "working" のとき metadata["generating-image"] でサブ状態を表す。
メソッド型（Extended Skills）：コア集合の外に RPC を足す。例：task-history 拡張が tasks/search を足し、Agent に「履歴タスクを検索できる」スキルを一つ増やす。
ステートマシン型：タスクのステートマシンに状態や遷移を足す。一線を踏みやすい類であり、新しい意味は必ず metadata に置き、コア列挙を改変してはならない。

公開当日に名前が挙がった導入事例

Google のブログは抽象メカニズムだけを語ったのではなく、当時すでに使われていた拡張を列挙し、JSON が何を担うべきかを対照しやすくした。

Traceability（追跡可能性）：コアメッセージは ResponseTrace——主プロトコルから独立した構造化ログで、Agent が踏んだステップを記録する。各 Step は ToolInvocation（ツール/API 呼び出し）か AgentInvocation（別の Agent を再呼び出し）のいずれか。ステップは入れ子にできる：下流 Agent もこの拡張をサポートしていれば、その trace は上流ステップにぶら下がり、エンドツーエンドの呼び出し木になる。複数 Agent 協調の評価や障害切り分けに不可欠だが、A2A コアに書き込む必要はない。

Twilio Latency Extension：音声 Agent（ConversationRelay）は遅延をブロードキャストし、最適な下流モデルの選定や優雅なフォールバックに使う。遅延は Agent Card のコアフィールドではない。Twilio が拡張で補ったのは、「ドメインデータでコアプロトコルを汚してはならない」典型例だ。

Identity Machines：拡張で Agent 間のゼロトラスト・ハンドシェイクを行う。タスク委譲の前に、目的、予算、能力、モデル、PII 状態などカスタム条件をポリシーゲートで検査する。ここで JSON が担うのはポリシー文脈であり、チャット本文ではない。

ブログは Ethereum の ERC-8004 方向にも触れている：オンチェーンの身元/評判/検証レジストリで、組織横断の Agent に信頼層を載せる。A2A Extension として公開されるとは限らないが、同じ問題——コアプロトコルは「どう話すか」を解決し、拡張と外部標準は「なぜ信頼するか」を解決する——を示している。

MCP、Function Calling とは何の関係か？

三つとも JSON を出すが、階層が違う。2026 年に互いに置き換えてはならない：

層	JSON がしていること	典型フィールド
Function Calling	モデル API 内：単発で呼べる関数を記述	`tools[]` / `tool_calls`
MCP Tool Schema	ツール供給：外部 Server が能力を公開	`inputSchema`
A2A Extensions	Agent 相互運用：対向プロトコルにドメイン能力を重ねる	`capabilities.extensions[]`

よくあるアーキテクチャは層を分ける：MCP Server がツールを提供 → ホストがツールをモデルの Function Calling に写像 → 複数 Agent 間は A2A でタスクを配送し、Extensions で追跡・遅延・身元など横断データを運ぶ。前の二層の JSON 比較は、前稿 MCP Tool Schema vs Function Calling を参照。

JSON Schema で拡張データを制約する

拡張仕様は少なくとも次を書く：URI 一覧、params の schema、Client/Agent 間の追加データ構造、新しいリクエスト-レスポンス流。実装時は：

AgentExtension.params と metadata キーそれぞれに JSON Schema を保つ。
CI でサンプル payload を検証する。Agent Card は公開 API 契約として扱う。
拡張関連の入力はすべて信頼できないデータとみなし、先に parse してから validate する。

JSON Schema の書き方は本サイトの JSON Schema 完全チュートリアルを参照。ローカルでの整形、構文チェック、複数バージョンの Diff は JSONSort で足りる。ポリシーや身元情報を含む Card を第三者サイトへアップロードする必要はない。

よくある誤解

Extension を「好きなフィールドを足す」と思い込む。 コア構造は変えない。新しいデータは metadata へ。
データ型拡張に required を付ける。 大量のクライアントを無意味に拒否する。
URI にバージョンを付けない。 破壊的変更の逃げ場がなく、交渉も乱れる。
バージョン不一致のとき古い実装へフォールバックする。 仕様は、その起動要求を無視せよと求めており、こっそり互換してはならない。
新しい RPC が既存の認可を迂回する。 拡張メソッドはコアメソッドと同じ認証・認可を通さねばならない。
MCP のツール一覧と混同する。 MCP は「どのツールがあるか」を解決し、A2A Extension は「二つの Agent がドメインの作法でどう話すか」を解決する。

よくある質問（FAQ）

A2A Extensions は 2026 年 9 月 9 日に公開されたのか？

公式ブログの日付は 2025 年 9 月 9 日。2026 年の読者もこの日付で「何が公開されたか」を検索する。メカニズム自体は現行 A2A 仕様に書き込まれ、ガバナンスとサンプル拡張（Traceability、Timestamp、Secure Passport など）が続いている。

拡張を実装しないと A2A は使えないのか？

不要。拡張はデフォルトでオフ。相手の Agent Card がある拡張を required と標しているときだけ、仕様どおり起動して従う必要がある。

拡張 JSON はメッセージ本体と HTTP ヘッダーのどちらに置くべきか？

起動リストは A2A-Extensions ヘッダー。拡張が運ぶ業務データは JSON-RPC の params.metadata（または仕様が指定する他の位置）。ヘッダーが交渉を担い、JSON がペイロードを担う。

Agent Card と拡張 metadata をどうデバッグするか？

ローカルで JSONSort を使い、Card を整形し、Schema を検証し、二つのバージョンの extensions 配列を diff する。身元やポリシーを含む JSON をオンラインツールに貼り付けてはいけない。

まとめ

9 月 9 日に公開されたのは、また一つのベンダー私有 API ではなく、A2A のオープンな拡張層だ：URI で能力に名前を付け、Agent Card JSON で宣言し、A2A-Extensions でリクエストごとに起動し、metadata でドメインデータを載せる。2026 年に複数 Agent システムを組むときは：コア対話は A2A、ツール供給は MCP、モデルの意図は Function Calling、垂直要件は Extensions——四つが各層を担い、JSON Schema をパラメータと拡張データの単一の事実源とする。

Google：A2A Extensions 公開ブログ 2025-09-09 原文と事例
A2A Extensions 仕様特集宣言、起動、ガバナンスと制限
MCP Tool Schema vs Function Calling ツール層 JSON の比較
JSONSort ローカル JSON ツール箱整形、構文検証、Diff

更新履歴：2026-08-28 初稿公開