Agent discovery は「見つける機能」ではなく、誰に何を見せるかの運用設計だ

要点

要点まとめ

A2A では agent の自己紹介を `Agent Card` という JSON で標準化するが、見つけ方は 1 つではない。
公開向けなら `/.well-known/agent-card.json`、企業内なら curated registry、閉じた関係なら direct configuration という 3 系統が示されている。
重要なのは discovery の便利さより、Agent Card に何を載せ、どこまでを誰に見せるかを auth と cache まで含めて決めることだ。
card には URL、skill、auth scheme が入るため、内部 agent の card を無防備に配ると、それ自体が情報漏えい面になる。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 作る前に確認したい

API や設定を試す前に、先に落とし穴を知りたい人向け。

同じテーマで読む AIエージェント

ツール利用、MCP、Agent SDK、長時間タスク、実行責任の設計。

次の記事 LangGraph Interrupts は「承認ボタン」ではなく停止と再開の契約を実装させる

人の確認を入れたいなら、確認画面を足す前に、途中で止まった仕事をどの状態からどう再開するかを決めないと危ない。

読解

何が変わったのか

この docs は discovery を registry 検索の一言で済ませていません。public 寄りの `well-known`、enterprise 向けの curated registry、固定関係向けの direct configuration を明示し、それぞれの向き不向きを書いています。さらに、Agent Card 自体に authentication scheme や skills が入りうるので、card を守るための mTLS、OAuth 2.0、IP 制限、selective disclosure まで含めて説明しています。加えて実務上重要なのは cache です。Agent Card は頻繁には変わらない前提で、`Cache-Control` や `ETag` を使って再取得を減らしつつ、skill や auth 要件の更新を eventually 反映させる方針が示されています。

日本の文脈

なぜ重要か

日本の開発現場では、agent discovery が「便利な catalog」扱いになりやすく、内部 URL や権限要件を誰に見せるかの設計が後回しになりがちです。しかし card には、攻撃者が知りたい情報がかなり入ります。運用が雑だと、まだ使わせるつもりのない agent や敏感な skill が先に露出します。agent network を本番導入するなら、discovery は UX 機能ではなく access design として扱うべきです。

技術ポイント

技術的ポイント

`Agent Card` は agent の名刺に相当する JSON で、name、provider、service endpoint、capabilities、auth scheme、skills などを持ちます。
public discovery では `https://{domain}/.well-known/agent-card.json` という標準場所が推奨されますが、sensitive な情報を含むなら endpoint 自体に認証が必要です。
curated registry は skill や tag で agent を探せる反面、registry の運用と access control が新しい責務になります。しかも現行 spec は registry API を標準化していません。
文書は authenticated extended agent cards を勧めており、client の identity に応じて返す情報を変える selective disclosure も想定しています。
cache では `Cache-Control` と `ETag` を使い、client 側は `If-None-Match` などの conditional request を使うべきだとしています。discovery は検索だけでなく更新反映まで含む、という意味です。

用語

英日キーワード

英語	日本語	補足
Agent Card	Agent Card / agent 情報カード	agent の場所、能力、認証方法を記述する JSON。便利な名刺である一方、公開面にもなる。
well-known URI	標準公開パス	決まった URL で情報を公開する方式。見つけやすさと露出面の両方を増やす。
curated registry	管理された registry	agent 情報を集中管理する catalog。便利だが access control と運用責務が増える。
selective disclosure	選択的開示	相手の権限に応じて見せる情報を変えること。同じ card を全員へ返さないための考え方。
mTLS
ETag

試す

試すなら

まず agent 一覧を作り、public discovery、社内 registry、固定設定のどれに置くべきか分ける。
Agent Card に載る URL、skill、auth requirement を見て、外部公開してよい情報か確認する。
registry を作る前に、client の権限ごとに同じ card を返してよいか、情報を出し分けるべきかを決める。
cache を無視せず、skill 更新や auth 変更が client にいつ届くかを設計に入れる。

注意

注意点

A2A spec は registry の標準 API までは定めていません。企業内 catalog を作るなら、その運用負債は自分たちが持ちます。
Agent Card は単なる説明文ではありません。auth scheme や endpoint の扱いを誤ると、discovery 面そのものが攻撃面になります。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。