Google Agent Registry 2026：Agent Card とは何か。A2A エージェントは能力・Tools・Skills をどう JSON で書くか

カタログであり、第三のプロトコルではない

Agent Registry と聞くと、Google がまた会話プロトコルを作ったと思う人が多い。違う。A2A はいまも、エージェントが自分をどう述べ、Task をどう受けるかを決める。Registry は Google Cloud 上の発見可能なコンポーネントのカタログで、既存のエージェントを検索できる資源にする。登録後、同じプロジェクトのオーケストレータ、Gemini Enterprise、Agent Gateway がスキルのキーワードで見つけられる。プロトコルは A2A のまま。変わったのは、誰が Card を覚えておくかだ。カタログがなければ URL をオーケストレータ設定に直書きする。それは 2025 年の住所録であり、2026 年の発見ではない。

登録は自動か手動か。同じプロジェクトの Agent Runtime、AI エージェントのラベルと Card 注釈付きの GKE、機能タイプ付きの Cloud Run、Google 自身の Workspace / Gemini エージェントは自動でカタログに入れる。自動登録は本プロジェクトだけを見る。横断プロジェクト、オンプレ、自動発見のないランタイムは手書きの Service が要り、そこから読み取り専用の Agent ができる。中枢のガバナンスプロジェクトが spoke のエージェントを見るなら、魔法の組織横断スキャンではなく、手動の横断登録だ。Register agents のページは 2026-09-22 に更新された。

同じカタログは MCP サーバも受ける。ファイルは toolspec.json、tools/list の戻りと同じ形で、上限も 10KB。だから Registry には横の同僚と下方向の手が同時にいる。両方を一つの汎用バリデータで扱わないこと。呼び出しホップの引数の見方は MCP と JSON Schema。今日はカタログがどう覚えるかだけだ。

Agent Card：索引されるソース JSON

Agent Card は A2A サーバのデジタル名刺だ。仕様上のパスはいまも /.well-known/agent-card.json。詳しくは A2A v1.0 の変更。A2A 準拠の項目について Registry はそのカードを取り、skills をキーワード索引にする。カード自体は公式 A2A スキーマを通さねばならない。1.0 では転送を supportedInterfaces に置き、各項に url、protocolBinding、protocolVersion を書く。トップレベルの url と protocolVersion は 0.3 の契約だ。1.0 クライアントはそれを主フィールドとして読まない。

人向けの身元は name、description、version。ここでの version はエージェント自身の版であり、プロトコル版ではない。プロトコル版はインタフェースに付く。skills[] の各項には id、name、description が要る。Registry が探すのは tags。examples は人向けのプロンプトであり、引数スキーマではない。フィールド表は次稿。今日覚えるのは、合法な Card がなければ A2A 型の自動抽出は起きないこと。10KB を超えると Registry は拒み、オーケストレータは一生見つけない。

下はリポジトリに入れてよい 1.0 カードだ。まず parse させ、公式スキーマを通す。runbook 全文を description に流し込むと、上限に先に当たる。発見面は短い説明と tags であり、手引きを名刺に詰め込むことではない。

{
  "name": "Invoice Specialist",
  "description": "Finds and summarizes invoices for finance. Does not post payments.",
  "version": "1.2.0",
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/invoice/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "search-invoices",
      "name": "Search invoices",
      "description": "Look up invoices by week, status, or counterparty.",
      "tags": ["invoices", "finance", "search"],
      "examples": ["Find overdue invoices for last week"]
    }
  ]
}

登録のあと：カタログ項目はこう見える

仕様は Google にローカルの「カタログスナップショット」を出せとは言わない。レビューは、索引された中身を見たい。結果を fixture に折る。displayName、specType（A2A_AGENT_CARD か NO_SPEC）、cardVersion、抽出した skill id、interfaces、searchKeywords。このスナップショットは A2A スキーマのインスタンスではない。Card スキーマで検証しない。CI のアサーションだ。登録成功は、検索可能と同じではない。

{
  "registry": "google-cloud-agent-registry",
  "displayName": "Invoice Specialist",
  "specType": "A2A_AGENT_CARD",
  "cardVersion": "1.0",
  "skillsIndexed": ["search-invoices"],
  "searchKeywords": ["invoices", "finance", "search"],
  "interfaces": [
    {
      "url": "https://agents.example.com/invoice/a2a",
      "protocolBinding": "JSONRPC"
    }
  ]
}

自動抽出は A2A 準拠の項目だけで起きる。Registry は /.well-known/agent-card.json を問い合わせ、名乗ったスキルをカタログへ書く。NO_SPEC の REST エンドポイントはカタログに入るが、探すスキルがない。オーケストレータは「エージェントがいる」と見えるが、「請求書を調べる同僚」には当たらない。検索可能にするなら Card を足すか、独立したスキル資源を登録する。Gemini Enterprise は独立スキルをトップレベルの Skill 資源としても登録できる。それは別のガバナンス線だ。Card の skills[] と同じファイルに混ぜない。

スナップショットとコミットした Card を並べて diff する。キーワードが食い違えば tags 漏れか索引の遅れ。URL が食い違えば古いエンドポイントを登録した。Card は合法なのに skillsIndexed が空なら、Registry が 1.0 の規則で 0.3 のカードを読んでいないか見る。supportedInterfaces が無いと抽出は黙って痩せる。チケットには「見つからない」とだけ書かれる。

Card の skills は MCP tools でも Plugin スキルでもない

同じ語に三層ある。Card の skill は、このエージェントが引き受けると名乗る仕事で、カタログ検索とオーケストレータの選定のためにある。MCP の tool は決定的な呼び出しで、契約は inputSchema。Plugin / Agent Skills の SKILL.md は同じエージェント自身のモデル向けの手引きだ。Registry が索引するのは第一のもの。MCP のツール名を Card.skills[].id に写せば検索は当たることがある。委譲の対面は不透明なエージェントのままで、tools/call ではない。複数ターンの確認と非同期コールバックは、関数呼び出しの形を破る。

一部の Card 実装は skill に inputSchema を付ける。それは形のヒントであり、MCP の実行契約ではない。Card を plugin.schema.json で検証しない。tools/call を Card で検証しない。三つの JSON はどれも「能力」と書くが、失敗の扱いが違う。悪い Card は発見の失敗。悪い inputSchema は呼び出しの失敗。一つのコーディングエージェントがスキルと手をどう増やすかは Plugin Manifest の実践。今日は別のエージェントがカタログにどう覚えられるかだけだ。

NO_SPEC の項目にはその名乗りがない。カタログではホスト名だけの住所録に見える。キーワードでは見つからない。独立スキルを足すか Card を書く。先に「見つかる必要があるか」を決め、そのあと A2A を話すかを決める。カタログのためだけの空の Card は空のスキル配列を索引する。登録しないより悪い。

0.3 と 1.0：二つの契約を混ぜて検証しない

Registry は 0.3 と 1.0 の両方を受ける。新しいカードは 1.0 にすべきだ。1.0 はプロトコル版と主 URL を supportedInterfaces へ移した。extendedAgentCard は capabilities の下。0.3 の stateTransitionHistory は中核能力ではない。二つのフィールド集合を混ぜると、クライアントはそれぞれ半分を読み、カタログ索引は半分を失う。A2A 自身の破壊的変更は v1.0 の変更ページにあり、Google の私的フォークではない。

レビューには少なくとも二枚残す。上の合法な 1.0 と、url をトップレベルに置きながら 1.0 として登録する負例。後者は 1.0 検証で落ちるか、主エンドポイントが無視される。CI が二つのスキーマを一つの「汎用エージェント検査」に潰すなら、クライアントより乱れている。Registry は宣言した版で規則を選び、読み込み中にスキーマを取りに行かない。Plugin Manifest と同じ規律だ。

署名、拡張カード、GetExtendedAgentCard は認証後の安全層であり、カタログの入場条件ではない。公開カードが先にスキルを渡し、オーケストレータが認証付きの二通目を取るかを決める。署名は今日の範囲外。tags を検索可能にすることが先だ。

fixture は JSONVue に残す

レビュー fixture は少なくとも三つ。上の 1.0 Card、カタログスナップショット、0.3 と 1.0 を混ぜた負例。一枚目は A2A 1.0 スキーマを通す。二枚目は自前のスナップショットスキーマか、skillsIndexed と tags のアサーション。三枚目は必ず失敗する。閉じた Plugin フィールドを Card に写したり、MCP の inputSchema 全表を skills[] に流し込んだりすれば、diff で一目で分かる。

MCP の対照を一枚足す。合法な toolspec.json で、カタログの第二のソースファイルを示す。Card スキーマを掛けない。tools[].name はランタイムのため、skills[].tags は検索のため。秘密をコミットした fixture に置かない。Card は公開名刺だ。取られる前提で書く。

ブラウザでできる：JSON 整形で Card とスナップショットが parse するか見る。JSON Schema 検証で 1.0 の supportedInterfaces と skills を見る。JSON Diffでコミットした Card とスナップショットの tags / URL のずれを拾う。データは手元を出ない。続きはA2A vs MCP、MCP 検証、Plugin Manifest。

関連：A2A vs MCP、MCP と JSON Schema、Plugin Manifest の実践。

よくある質問

まとめと次の一手

2026 年の Google Agent Registry は一文に折れる。カタログであり、Card が索引されるソース JSON だ。オーケストレータが探すのは tags とスキル名であり、スライドのトポロジではない。

出す順はこうだ。合法な 1.0 Card。登録時に specType を見る。スナップショットでスキルが本当に載ったかをアサートする。MCP は別の toolspec.json。三つの契約を JSONVue で見る。層は A2A vs MCP の稿。フィールドは次稿。歩き方はその次。