# Agent Cardとは何か——発見から最初のタスクまで

著者：Kotaro OKUYAMA / AgentCollusion  
公開・確認日：2026年9月7日  
技術的な基準：A2A仕様リリース v1.0.1、通信上のプロトコルバージョン 1.0  
英語記事：[Agent Cards, Explained](https://agentcollusion.ai/news/a2a-agent-card-explained)

エージェントが別のエージェントに仕事を頼むには、相手が何を提供し、どこに接続でき、どのような認証が必要かを知る必要があります。その情報をソフトウェアが読める形にまとめるのが、Agent Cardです。

たとえば、購買アシスタントが見積書を比較する専門エージェントを探しているとします。サービス名だけでは連携できません。接続先、対応プロトコル、入力形式、認証条件を把握したうえで、比較の依頼を送ります。Agent Cardが受け持つのは、この最初の自己紹介です。

本稿の見積比較サービス、ドメイン、依頼内容は説明用の架空例です。稼働しているAgentCollusionのサービスを示すものではありません。仕様上の事実は一次資料にリンクし、独自の運用提案はその旨を記しています。

## 1. Agent Cardが記述するもの

Agent Cardは、Agent2Agent（A2A）プロトコルに参加するエージェントサービスの発見用ドキュメントです。プロトコル定義では `AgentCard` という型名で表されます。A2Aがエージェント間の通信方法を定めるのに対し、カードは、接続を始めるために必要な相手の情報を提供します。

サービス内部のモデル、ツール、実行基盤は提供者が実装できます。カードだけから、それらの構成や能力の実測値が分かるわけではありません。[A2AのAgent Discovery仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#8-agent-discovery-the-agent-card)

| 知りたいこと | 主な項目 | 読み方 |
| --- | --- | --- |
| 誰が何を提供するか | `name`、`description`、`provider`、`version` | サービス名、説明、任意の提供者情報、サービスのリリース番号 |
| どこに、どの方法で接続するか | `supportedInterfaces` | 接続URL、プロトコルバインディング、対応バージョンの優先順リスト |
| 通信上のどの機能に対応するか | `capabilities` | ストリーミング、プッシュ通知、拡張機能、認証付き拡張カードなど |
| 何の仕事を、どの形式で頼めるか | `skills`、`defaultInputModes`、`defaultOutputModes` | 提供する能力と入出力のメディアタイプ。スキルごとの上書きも可能 |
| どう認証するか | `securitySchemes`、`securityRequirements` | 名前付き認証方式の定義と、それを参照する要件 |
| 署名された文書を検証できるか | `signatures` | 適切に信頼された鍵で検証する、任意のJWS署名 |

`capabilities.streaming` は通信上の機能です。一方、「見積書を比較する」という業務上の能力は `skills` に記述します。この区別が、カードを読む最初のポイントです。[v1.0.1のプロトコル定義](https://github.com/a2aproject/A2A/blob/v1.0.1/specification/a2a.proto)

## 2. JSON例を読む

[記事内の操作可能な解説](https://agentcollusion.ai/news/a2a-agent-card-explained#read-the-card)では、Identity、Connection、Skills、Accessを選ぶと、その項目のJSONと解説を表示できます。Full JSONで全体を確認できます。[JSONファイルを開く](https://agentcollusion.ai/examples/agent-card-v1.json)

例のサービス名は `Quote Comparison Agent` です。渡された見積書について総額、納期、要件への適合を比較し、発注は行わないと説明しています。`example.com` 配下のURLはすべて例示用です。認証情報と署名は含まれません。

### サービスのバージョンと通信のバージョン

カードの `version: "2.1.0"` は提供者が管理するサービスのリリース番号です。一方、`supportedInterfaces` 内の `protocolVersion: "1.0"` は、その接続先で使えるA2A通信のバージョンです。どちらもモデル名ではありません。

さらに、本稿が参照する仕様リリースは **v1.0.1** です。通信に使うバージョンではメジャーとマイナーを表すため、ここでは **1.0** と宣言します。[バージョニング仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#36-versioning)

### スキルIDと呼び出しメソッド

`skills[].id` の `compare-quotes` は、記述された能力の識別子です。自動的に同名のRPCメソッドや引数用JSON Schemaが作られるわけではありません。依頼はA2Aの `SendMessage` などの操作で送ります。業務固有の詳細な入力契約は、サービスの文書や合意された拡張で別途定めます。[Agent Cardとスキルの定義](https://github.com/a2aproject/A2A/blob/v1.0.1/specification/a2a.proto)

### 認証方式の定義と認証要件

`securitySchemes` は、Bearerなどの認証方式に名前を付けて定義する項目です。`securityRequirements` は、利用時に必要な方式をその名前で参照します。この例では、次の形になります。

```json
{
  "securitySchemes": {
    "bearer": {
      "httpAuthSecurityScheme": {
        "scheme": "Bearer"
      }
    }
  },
  "securityRequirements": [
    {
      "schemes": {
        "bearer": {}
      }
    }
  ]
}
```

`bearer` の値が空のオブジェクトなのは、この例がOAuthスコープのリストを指定していないためです。Bearer認証が不要という意味ではありません。実際のトークンはカードの外で取得します。[SecurityRequirementとSecuritySchemeの定義](https://github.com/a2aproject/A2A/blob/v1.0.1/specification/a2a.proto)

## 3. 発見から最初のタスクまで

### ステップ1：カードを見つける

Well-known URI方式を採用するサービスでは、次のような要求でカードを取得します。架空のドメインを使ったHTTP例です。

```http
GET /.well-known/agent-card.json HTTP/1.1
Host: quotes.example.com
```

これは、ドメインが分かった後の取得先をそろえる仕組みです。存在するすべてのエージェントを自動的に発見する検索エンジンではありません。公式文書は、レジストリ／カタログ、直接設定による発見も説明しています。また、統一されたレジストリAPIを規定していません。非公開環境ではカードの取得自体に認証を要求することもあります。[発見方法の公式ガイド](https://a2a-protocol.org/latest/topics/agent-discovery/#discovery-strategies)

### ステップ2：互換性のある接続先を選ぶ

業務スキルと入出力形式を確認し、`supportedInterfaces` の優先順に、自分が対応するバインディングとバージョンを選びます。HTTP+JSONしか扱えないクライアントが、同じHTTPだからという理由でJSON-RPCの接続先を使うことはできません。互換性がなければ、その不一致を扱う必要があります。

例では、次の業務要求を `https://quotes.example.com/a2a` に送ります。カードを取得した `/.well-known/agent-card.json` にタスクを投げるわけではありません。選んだインターフェースに `tenant` が指定されている場合は、その値を要求にも引き継ぎます。本稿の例には `tenant` はありません。[接続先選択の仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#832-client-protocol-selection)

### ステップ3：認証し、要求の権限を確認する

クライアントは必要な認証情報を別の手順で取得し、通信方式に対応するヘッダーやメタデータで送ります。サーバーは呼び出し元を認証し、自身のポリシーに基づいて要求を認可します。[認証と認可の仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#7-authentication-and-authorization)

購買の例なら、見積比較を依頼する権限と発注する権限は別に扱うべきです。「発注しない」と説明文に書くことは意図の共有に役立ちますが、その境界を守らせるにはサーバーとツールの権限制御が必要です。これは、この架空例に対する運用上の提案です。

### ステップ4：A2Aのメッセージを送る

アクセスが確立した後、選んだJSON-RPC接続先へ `SendMessage` を送ります。英語記事には要求本文の例を掲載しています。通信のヘッダーには `Content-Type: application/json`、`A2A-Version: 1.0`、必要な認証ヘッダーを付けます。認証情報そのものは例に含めていません。

例の依頼は、価格100＋送料10で3日後に届く見積Aと、送料込み105で5日後に届く見積Bの比較です。納期と総額の違いを説明し、発注はしないように伝えます。

`SendMessage` の結果は、直接の `Message`、または追跡対象の `Task` です。タスクを使う場合は識別子を使って状態や結果を取得できます。対応機能に応じて、ストリーミングやプッシュ通知も利用できます。カードが接続の入口を記述するのに対して、タスクは実行状態や成果物を扱います。[Send Message仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#311-send-message)、[JSON-RPCバインディング](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#9-json-rpc-protocol-binding)

## 4. MCPやモデルカードとの関係

購買アシスタントがA2A経由で見積比較サービスへ仕事を依頼し、そのサービスが内部でMCPツールを使って利用可能な仕入先情報を取得する構成も考えられます。Agent Cardは相手のサービスへの入口を記述します。MCPはツールやリソースとの別の接続を担います。A2Aの公式文書も両者を補完関係として説明しています。[A2AとMCPの公式比較](https://a2a-protocol.org/latest/topics/a2a-and-mcp/)

モデルカードは、モデルという成果物とその文書化された特性を対象にします。Agent Cardは、サービスとして外部へ公開するインターフェースを記述します。同じ見積比較スキルを維持しながら内部モデルを変えることも、複数のサービスが同じモデルを使うこともあり得ます。[Open Weights Move the Trust Boundary](https://agentcollusion.ai/news/openai-gpt-oss-hugging-face-agent-provenance)

## 5. 古いJSON例との違い

検索で見つかるコードやSDKの例には異なる世代のA2Aが混在します。コピーする前に、対象バージョンを確認してください。

| 概念 | v0.3の例 | v1.0の構造 |
| --- | --- | --- |
| 接続先とバインディング | `url`、`preferredTransport`、`additionalInterfaces` | `supportedInterfaces[]` 内の `url` と `protocolBinding` |
| プロトコルバージョン | カード直下の `protocolVersion` | 各インターフェース内の `protocolVersion` |
| 認証付き拡張カード | `supportsAuthenticatedExtendedCard` | `capabilities.extendedAgentCard` |
| 認証要件 | `security` と直接のスコープ配列 | `securityRequirements` 内の `schemes`。値は `StringList` オブジェクト |

前半の構造変更は公式移行ガイドに、認証要件の形式はv1.0.1のプロトコル定義に基づきます。[移行ガイド](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/whats-new-v1.md#agentcard-object)、[プロトコル定義](https://github.com/a2aproject/A2A/blob/v1.0.1/specification/a2a.proto)

v1.0のスコープ指定では、空でないスコープ配列は `list` プロパティを持つオブジェクトで表します。Bearerの例ではOAuthスコープを指定しないため `{}` を使います。認証方式の定義も、この例なら `httpAuthSecurityScheme` という型を表すフィールドで包まれます。

説明用サンプルに古いフィールド表記が残っている場合もあります。正確なシリアライズ形式が必要な場面では、参照するリリースを固定したプロトコル定義と、実際に利用するSDKの対応バージョンを確認してください。

## 6. 署名・認証付き拡張カード・更新

### 署名は文書の完全性を検証する

A2Aのカードは任意でJWS署名を持てます。検証には、署名自体を除外し、フィールドの有無や既定値の扱いを仕様どおりに処理したうえで、JSONの正規化を適用します。任意の `JSON.stringify` の結果をそのまま署名するだけではありません。検証者は鍵を適切に信頼できる必要もあり、期限切れ・失効済みの鍵を受け入れてはいけません。[カード署名の仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#84-agent-card-signing)

本稿の例は署名を付けていません。実際の署名は、署名された文書と署名者に関する証拠になります。一方、見積比較の正しさ、依頼者の委任範囲、仕入先の独立性は、それぞれ別の証拠を必要とします。

### 認証付き拡張カードで詳細を開示する

`capabilities.extendedAgentCard` が `true` なら、認証付き拡張カードの取得に対応しています。公開カードでは概要だけを示し、権限を持つ呼び出し元に詳しい能力を開示できます。取得方法は選択したバインディングに従います。JSON-RPCは `GetExtendedAgentCard`、HTTP+JSONは `GET /extendedAgentCard` です。[拡張カード取得の仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#3111-get-extended-agent-card)

見積比較サービスなら、特定の顧客だけが使える非公開カタログの存在を、拡張カードに記述する利用例が考えられます。これは仮説上の例です。運用上は、開示内容とキャッシュを認証済みの顧客に適切に結び付け、別の顧客へ流用されないようにすることを提案します。[選択的開示のField Note](https://agentcollusion.ai/news/extended-agent-cards-selective-disclosure)

### 古いカードを適切に更新する

接続先、能力、認証条件は変化します。仕様はHTTPのキャッシュ制御や `ETag`、期限が切れたカードに対する条件付きリクエストを推奨しています。サービスのバージョン番号があるからといって、カードを無期限に保持してよいわけではありません。[キャッシュ仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md#86-caching)

監査に向けた設計としては、どのカードをいつ取得し、どの接続先とインターフェースを選んだかを記録することを提案します。必要な情報は適切に秘匿化してください。後からサービスの説明や実装が変わった場合にも、当時の振り分け判断を追いやすくなります。[Agent Card Caches Can Outlive Trust](https://agentcollusion.ai/news/agent-card-cache-invalidation)

## 7. AgentCollusionが注目するその先

購買アシスタントの例で必要なのは、サービスを見つけ、比較スキルとテキスト入力を確認し、JSON-RPC 1.0の接続先を選び、認証して依頼を送ることです。その後、返ってきた比較を確認し、購買判断を説明する証拠を保持します。

カードは、適したサービスを探して接続を始めるための情報です。権限は委任やアクセスポリシーから、結果への確信は実際の仕事に関する証拠から得ます。

複数のサービスがもっともらしいカードを公開しながら、同じ運営者、仕入先との関係、報酬上の利害を共有している可能性もあります。AgentCollusionの研究では、カードを宣言上の出発点として捉え、その後の相互作用や集団としての結果を調べます。

続き：[An Agent Card Is Not a Trust Passport](https://agentcollusion.ai/news/agent-card-is-not-a-trust-passport)

## 主な一次資料

- [A2A v1.0.1リリース](https://github.com/a2aproject/A2A/releases/tag/v1.0.1)
- [A2A v1.0.1プロトコル定義](https://github.com/a2aproject/A2A/blob/v1.0.1/specification/a2a.proto)
- [A2A v1.0.1仕様](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/specification.md)
- [A2A v1.0移行ガイド](https://github.com/a2aproject/A2A/blob/v1.0.1/docs/whats-new-v1.md)
- [Agent Discovery公式ガイド](https://a2a-protocol.org/latest/topics/agent-discovery/)
- [A2AとMCPの公式比較](https://a2a-protocol.org/latest/topics/a2a-and-mcp/)

実験との接点：[4エージェントのA2A購買実験](https://agentcollusion.ai/news/astra-fable-a2a-collusion-experiment)