> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# verify_brand_claim

> verify_brand_claim は、ブランドエージェントに自身のアイデンティティについての特定のクレームが owned、pending、disputed、licensed かを尋ねる統一 AdCP ブランドプロトコルタスク。1 ツール、4 つのクレームタイプ — subsidiary、parent、property、trademark — claim_type フィールドで判別。

ブランドエージェントに、そのアイデンティティの一側面についての検証質問を尋ねます。**これは前提条件ゲートです — 進む前にチェックする、決定がロックされた後に消費するシグナルではありません。** 4 つのクレームタイプを持つ 1 つのツールが検証次元をカバーします:

| `claim_type` | The question                   | Used at                             |
| ------------ | ------------------------------ | ----------------------------------- |
| `subsidiary` | 「このブランドはあなたの子会社か?」             | ブランド関係確立、メンバー機能プロビジョニング、ガバナンス信頼拡張   |
| `parent`     | 「このブランドはあなたの親ハウスか?」（リーフ側ミラー）   | エージェント層での相互主張確認                     |
| `property`   | 「このサイト / アプリ / プロパティはあなたのものか?」 | 在庫オンボーディング、クリエイティブクリアランス、不正エスカレーション |
| `trademark`  | 「この商標はあなたのものか?」                | クリエイティブクリアランスゲート、ライセンシー姿勢確認         |

ブランドエージェントは自身のデータを使って答えます — それは brand.json プラス、静的ファイルが表現できないよりリッチな状態（`pending_review`、`transferring`、`licensed_in` など）です。ツールは `get_brand_identity` が読むのと同じアイデンティティ表面の上の 1 つの特定質問アフォーダンスです。

高ボリューム検証（ポートフォリオリフレッシュ、クリエイティブクリアランスバッチ、クローラースキャン）には、バルクバリアント [`verify_brand_claims`](/docs/brand-protocol/tasks/verify_brand_claims) を使います — 同じクレームごとのセマンティクス、バッチ全体に 1 ラウンドトリップと 1 レート制限スロット。

## 信頼ルール — 1 つではなく 2 つの呼び出し

**単一の署名付き `owned` レスポンスは信頼拡張ではありません。相互主張が肯定的信頼のフロアのままです。** これは非対称信頼モデルの荷重を担うルールです — 主張方向は両側の同意を要求します。消費者は関係信頼を拡張するとき両側を呼ばなければなりません（MUST）:

* `subsidiary` クレームには、`claim_type: "parent"` でリーフのブランドエージェントも呼ぶ（またはリーフの `brand.json` を `house_domain` のためクロール）。
* `property` クレームには、ブランドの静的 `brand.json` `properties[]` と（ドメインには）DNS/TLS 証拠に対してクロスチェック。
* `trademark` クレームには、公開レジストリレコードをクロスチェック。特に `licensed_in` には、ライセンシング関係が信頼される前に、`details.licensor_domain` で名指しされたライセンサーが同じマークについて `licensed_out` を相互にすべき（SHOULD）。
* **拒否（`disputed` / `not_ours`）のみが単一の署名付きレスポンスで権威的** — ブランドは一方的に関連を拒否する立場を持つ。

ショートカットは信頼モデルを殺します。相互性ステップなしでは、悪意ある、または誤ったハウスが、実際には持たない子会社、プロパティ、ライセンスマークを主張しうる。完全な規範的信頼テーブルと悪意あるハウスのウォークスルーについては [`brand.json` § エージェント拡張検証](/docs/brand-protocol/brand-json#agent-augmented-verification) を参照してください。

## スキーマ

* **Request**: [`verify-brand-claim-request.json`](https://adcontextprotocol.org/schemas/v3/brand/verify-brand-claim-request.json)
* **Response**: [`verify-brand-claim-response.json`](https://adcontextprotocol.org/schemas/v3/brand/verify-brand-claim-response.json)

## ケイパビリティディスカバリー

ブランドエージェントは `get_adcp_capabilities` レスポンスでこのタスクをアドバタイズします。一部のクレームタイプのみをサポートするエージェントは、ツールごとのケイパビリティ拡張経由でこれを宣言します:

```json theme={null}
{
  "supported_protocols": ["brand"],
  "supported_tasks": [
    "get_brand_identity",
    "verify_brand_claim"
  ],
  "brand": {
    "verify_brand_claim": {
      "supported_claim_types": ["subsidiary", "parent", "trademark"]
    }
  }
}
```

`supported_claim_types` が省略されるとき、エージェントは 4 つすべてのサポートをアドバタイズします。消費者は特定のクレームタイプに依存する前にチェックしなければなりません（MUST）。サポートされないタイプは `UNSUPPORTED_CLAIM_TYPE` を返します（[Error handling](#error-handling) を参照）。

### 最小実行可能採用

ブランドエージェントは 4 つすべてのクレームタイプを一度に出荷する必要はありません。ワークフローに一致するスライスを選びます:

* **Property のみ** — クリエイティブクリアランスと在庫オンボーディング消費者。最小の有用な表面。
* **Subsidiary + parent** — ブランド関係確立またはガバナンス信頼拡張を行うパートナー。相互主張がエージェント層で完了するよう両半分を一度に出荷。
* **Trademark のみ** — ライセンシー姿勢を必要とするクリエイティブクリアランスパイプライン（レジストリクロールからの差別化要因）。
* **すべて 4 つ** — 完全カバレッジ。多くのメンバー構成をサーブする AAO ホストエージェントに推奨。

実装するタイプのみをアドバタイズします。パートナーは `supported_claim_types` をチェックしそれに応じてルーティングします。サポートされないタイプはクリーンに `UNSUPPORTED_CLAIM_TYPE` を返します。

## 認可階層

クレームタイプごとの公開/認可分割:

| Tier                                                                     | What the agent returns                                                                                                                                                                            |
| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Public**（リンクされたアカウントなし）                                                | `claim_type`、`verification_status`（常に）。該当するクレームタイプには: `details.brand_id`、`details.relationship`、`details.matched_registration`、`details.countries`、`details.nice_classes`。投入されたとき `context_note`。 |
| **Authorized**（[`sync_accounts`](/docs/accounts/tasks/sync_accounts) 経由） | 上のすべて、プラス: `details.first_observed_by_house_at`、`details.expected_resolution_window_days`、`details.use_case_authorization`、`details.licensor_domain`（licensed\_in のとき）。                           |

キュー位置、内部チケット状態、チームルーティングは決して露出されません。

## クレームタイプごとのリクエストとレスポンス形状

レスポンスの `details` フィールドは `claim_type` によって変わります。以下: リクエストペイロードと各クレームタイプが返す型付き `details` フィールド。

### `claim_type: "subsidiary"`

ハウス側: 消費者が `converse.com` が `house_domain: nikeinc.com` を主張するのを検出。Nike のエージェントに尋ねる:

```json theme={null}
{
  "claim_type": "subsidiary",
  "claim": {
    "subsidiary_domain": "converse.com",
    "subsidiary_brand_id": "converse",
    "observed_at": "2026-05-14T10:00:00Z"
  }
}
```

```json theme={null}
{
  "claim_type": "subsidiary",
  "verification_status": "owned",
  "details": { "brand_id": "converse" }
}
```

ブランドは拒否もできる — 拒否方向は単一の署名付きレスポンスで権威的、相互性不要:

```json theme={null}
{
  "claim_type": "subsidiary",
  "verification_status": "not_ours",
  "context_note": "We have no record of this brand; the leaf's claim is in error."
}
```

該当ステータス: `owned`、`pending_review`、`transferring`、`disputed`、`not_ours`、`archived`、`unknown`。（`licensed_in` / `licensed_out` は適用されない — 子会社はライセンスされない。ブランドと商標がされる。）`archived` は、ブランドがかつてこの子会社を保持していた（例: 分離された事業単位）がもはやしないことを意味 — `not_ours`（決して所有しない）と区別。

**リクエスト `claim` フィールド:**

| Field                 | Required | Notes                                                                             |
| --------------------- | -------- | --------------------------------------------------------------------------------- |
| `subsidiary_domain`   | Yes      | `house_domain` クレームが検証されているリーフブランドのドメイン。                                          |
| `subsidiary_brand_id` | No       | リーフが自身に使う安定したブランド識別子。推奨。複数のブランドがドメインを共有するときエージェントが曖昧性解消するのを助ける。                   |
| `observed_at`         | No       | ISO 8601 タイムスタンプ — 呼び出し元がリーフのクレームを観測したとき。エージェントがクレームをエイジングし内部キューで新鮮なものを優先するのを助ける。 |

**レスポンス `details` フィールド:**

| Field                             | Tier       | Returned when                                                                | Notes                                                                                                                                                                         |
| --------------------------------- | ---------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `brand_id`                        | Public     | `verification_status` ∈ {`owned`, `pending_review`, `transferring`}          | この子会社のハウスの brand\_id。                                                                                                                                                         |
| `first_observed_by_house_at`      | Authorized | any                                                                          | ハウスが最初にクレームを認識したとき。                                                                                                                                                           |
| `expected_resolution_window_days` | Authorized | `verification_status` が `pending_review` のとき **必須**。そうでなければ存在するとき Authorized | エイジングウィンドウ。強制はエージェント側: エージェントはウィンドウが経過したらクレームを終端ステータスまたは `unknown` に遷移しなければならない（MUST）。`pending_review` レスポンスが宣言されたウィンドウより古いとき、消費者はそれを `unknown` として扱いクロールにフォールバックすべき（SHOULD）。 |

### `claim_type: "parent"` (leaf-side mirror)

リーフ側: 消費者がその親についてのリーフの権威的な答えを望む。Converse のエージェントに尋ねる:

```json theme={null}
{
  "claim_type": "parent",
  "claim": {
    "parent_domain": "nikeinc.com",
    "claimant_says": "Nike's brand_refs[] lists converse.com"
  }
}
```

```json theme={null}
{
  "claim_type": "parent",
  "verification_status": "owned",
  "details": { "house_domain": "nikeinc.com" }
}
```

リーフは能動的に拒否もできる:

```json theme={null}
{
  "claim_type": "parent",
  "verification_status": "disputed",
  "context_note": "We are not a Nike subsidiary; their claim is in error."
}
```

該当ステータス: `subsidiary` と同じ（ミラー）。

**リクエスト `claim` フィールド:**

| Field           | Required | Notes                                                                                                     |
| --------------- | -------- | --------------------------------------------------------------------------------------------------------- |
| `parent_domain` | Yes      | このブランドの親として主張されているハウスのドメイン。                                                                               |
| `claimant_says` | No       | 主張者が公開したものについてのフリーテキストコンテキスト（例: "Nike's brand\_refs\[] lists converse.com"）。競合するクレームをエージェントが曖昧性解消するのを助ける。 |
| `observed_at`   | No       | ISO 8601 タイムスタンプ — 呼び出し元が親クレームを観測したとき。                                                                    |

**レスポンス `details` フィールド:**

| Field                       | Tier       | Returned when                                     | Notes                                                          |
| --------------------------- | ---------- | ------------------------------------------------- | -------------------------------------------------------------- |
| `house_domain`              | Public     | `verification_status` ∈ {`owned`, `transferring`} | ブランドの宣言された親ハウス。`pending_review` には返されない — リーフがまだ親クレームを受諾していない。 |
| `first_observed_by_leaf_at` | Authorized | any                                               | リーフが最初にその親子関係についての第三者クレームを認識したとき。                              |

`claim_type: "subsidiary"`（ハウス上）AND `claim_type: "parent"`（リーフ上）の両方の `verify_brand_claim` が同じ関係について `owned` を返すとき、**相互主張がエージェント層で確立** — 静的ファイルクロール不要。これは信頼拡張の最もクリーンなパスです。

### `claim_type: "property"`

リクエストは 1 つのプロパティについて尋ねます。レスポンスは、関係が適用されるすべてのリージョン（クエリで名指しされたものを超えるかも）を含む、そのプロパティとのブランドの関係を記述します。

```json theme={null}
{
  "claim_type": "property",
  "claim": {
    "property": {
      "type": "website",
      "identifier": "nike.cn",
      "region": "CN"
    },
    "use_case": "advertising"
  }
}
```

```json theme={null}
{
  "claim_type": "property",
  "verification_status": "owned",
  "details": {
    "relationship": "owned",
    "brand_id": "nike",
    "regions": ["CN"],
    "use_case_authorization": { "advertising": true }
  },
  "context_note": "Regional site for China market"
}
```

複数のリージョンにまたがるプロパティ（例: グローバル e コマース表面）はそれらすべてを返す:

```json theme={null}
{
  "claim_type": "property",
  "claim": { "property": { "type": "website", "identifier": "nike.com" } }
}
→
{
  "claim_type": "property",
  "verification_status": "owned",
  "details": {
    "relationship": "owned",
    "brand_id": "nike",
    "regions": ["US", "CA", "GB", "FR", "DE", "JP", "AU"]
  }
}
```

ブランドは拒否もできる — 拒否方向は単一の署名付きレスポンスで権威的:

```json theme={null}
{
  "claim_type": "property",
  "claim": { "property": { "type": "website", "identifier": "fake-nike-store.com" } }
}
→
{
  "claim_type": "property",
  "verification_status": "not_ours",
  "context_note": "Unaffiliated third-party site; we do not authorize use of our marks on it."
}
```

該当ステータス: `owned`、`transferring`、`disputed`、`not_ours`、`archived`、`unknown`。（`pending_review` はプロパティには珍しい。飛行中の所有権変更には `transferring` を使う。）`archived` は、ブランドがかつてこのプロパティを運用していた（例: 売却されたドメイン）がもはやしないことを意味。

**リクエスト `claim` フィールド:**

| Field                 | Required   | Notes                                                                                               |
| --------------------- | ---------- | --------------------------------------------------------------------------------------------------- |
| `property.type`       | Yes        | `website`、`mobile_app`、`ctv_app`、`desktop_app`、`dooh`、`podcast`、`radio`、`streaming_audio`。          |
| `property.identifier` | Yes        | ウェブサイト/ポッドキャストにはドメイン、アプリにはバンドル id など。                                                               |
| `property.store`      | タイプがアプリのとき | `apple`、`google`、`amazon`、`roku`、`fire_tv`、`samsung`、`lg`、`vizio`、`other`。                          |
| `property.region`     | No         | 単一の ISO 3166-1 alpha-2 コード（または `"global"`） — 呼び出し元が気にするリージョン。レスポンスの `details.regions` が完全な該当セットを運ぶ。 |
| `use_case`            | No         | フリーテキストユースケース（例: `"advertising"`）。エージェントはそれに応じて答えをスコープしてもよい（MAY）。                                   |

**レスポンス `details` フィールド:**

| Field                    | Tier       | Returned when                                     | Notes                                                                                                                                                  |
| ------------------------ | ---------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `relationship`           | Public     | `verification_status` ∈ {`owned`, `transferring`} | `owned` / `direct` / `delegated` / `ad_network` — brand.json の `properties[].relationship` をミラー。                                                       |
| `brand_id`               | Public     | `verification_status` ∈ {`owned`, `transferring`} | このプロパティを所有するハウス内のブランド。                                                                                                                                 |
| `regions`                | Public     | `verification_status` ∈ {`owned`, `transferring`} | ISO 3166-1 alpha-2 コード、またはリージョン制限なしの `["global"]` センチネル。リクエストが名指ししたものを超えるリージョンを含むかも。                                                                   |
| `use_case_authorization` | Authorized | any                                               | ユースケースごとの権限マップ。登録されたキー: `advertising`、`endorsement`、`retail_listing`、`editorial`、`commercial_advertising`、`merchandise_resale`。エージェントは拡張を追加してもよい（MAY）。 |

### `claim_type: "trademark"`

```json theme={null}
{
  "claim_type": "trademark",
  "claim": {
    "mark": "AIR JORDAN",
    "registry": "USPTO",
    "number": "1234567"
  }
}
```

```json theme={null}
{
  "claim_type": "trademark",
  "verification_status": "owned",
  "details": {
    "matched_registration": {
      "registry": "USPTO",
      "number": "1234567",
      "mark": "AIR JORDAN",
      "registration_status": "active"
    },
    "countries": ["US"],
    "nice_classes": [25, 41]
  }
}
```

```json theme={null}
{
  "claim_type": "trademark",
  "verification_status": "licensed_in",
  "details": {
    "matched_registration": { "registry": "EUIPO", "number": "EU98765", "mark": "CONVERSE", "registration_status": "active" },
    "licensor_domain": "converseholdings-eu.com",
    "countries": ["FR", "DE", "IT", "ES"],
    "nice_classes": [25]
  }
}
```

**`licensed_in` 相互性。** 消費者は、名指しされた `licensor_domain` のブランドエージェントが同じマークについて `licensed_out` を相互にするまで、`licensed_in` を **未検証** として扱うべきです（SHOULD）（所有権と同じ相互主張形状、ただしライセンシングエッジ全体で）。相互性なしでは、ブランドが存在しないライセンス関係を一方的に主張しうる。

ブランドは拒否もできる — 拒否方向は単一の署名付きレスポンスで権威的:

```json theme={null}
{
  "claim_type": "trademark",
  "claim": { "mark": "AIR JORDAN", "registry": "EUIPO" }
}
→
{
  "claim_type": "trademark",
  "verification_status": "disputed",
  "context_note": "EU mark in this jurisdiction held by separate entity; we contest their registration and do not authorize use as ours."
}
```

該当ステータス: `owned`、`licensed_in`、`licensed_out`、`transferring`、`disputed`、`not_ours`、`archived`、`unknown`。（`pending_review` は珍しい — 商標登録は任意の時点で確定的な所有権を持つ公開記録イベント。）`archived` は、ブランドがかつてこのマークを保持していた（期限切れ、キャンセル、別の当事者に移転）がもはやしないことを意味。

**`details` フィールド:**

| Field                    | Tier       | Notes                                                                                                   |
| ------------------------ | ---------- | ------------------------------------------------------------------------------------------------------- |
| `matched_registration`   | Public     | エージェントがクエリをマッチした登録。`verification_status` が `owned`、`licensed_in`、`licensed_out`、`transferring` のとき返される。 |
| `licensor_domain`        | Public     | `verification_status` が `licensed_in` のときライセンサーのドメイン。                                                   |
| `countries`              | Public     | レスポンスがカバーする ISO 3166-1 alpha-2 コード。                                                                     |
| `nice_classes`           | Public     | Nice 分類クラス番号。クロス産業マークを曖昧性解消。                                                                            |
| `use_case_authorization` | Authorized | このマークのユースケースごとの権限 — レジストリクロールからの差別化要因。                                                                  |

## Trust model

エージェントのレスポンスはブランドの `adcp_use: "response-signing"` JWK の下で署名されます。これはペイロードエンベロープ JWS です — 署名はレスポンスボディ内に存在し、RFC 9421 §2.2.9 トランスポートレスポンス署名（AdCP 3.x は定義しない）と区別されます。`verify_brand_claim` は仕様の [指定タスクレスポンス署名リスト](/docs/building/by-layer/L1/security#designated-task-response-signing) にあります。そのリスト外のタスクでのレスポンス署名は禁止されます。

署名は、エンベロープの `iat`/`exp` ウィンドウ中にブランドの公開鍵の下でレスポンスペイロードの著作を証明します。それは否認防止レシートではなく、下の方向非対称セマンティクスを超えてブランドを主張に拘束しません。必須の `signed_response` エンベロープは、レスポンスを指定タスク、解決された `brand_domain`、応答する `agent_url`、呼び出し元アイデンティティ、リクエストペイロード、鮮度ウィンドウにバインドします。署名に依存する検証者は、エンベロープを [`response-payload-jws-envelope.json`](https://adcontextprotocol.org/schemas/v3/core/response-payload-jws-envelope.json) に対して検証しなければならず（MUST）、オンライン決定のため期限切れエンベロープを拒否し、署名されていないタスクボディフィールドと `signed_response.payload.response` 間の任意の不一致を拒否しなければなりません。

信頼モデルは **方向非対称** です:

* **拒否方向**（エージェントが `disputed` / `not_ours` と言う）は権威的。ブランドは一方的に関連を拒否できる。相互性不要。
* **主張方向**（エージェントが `owned` / `pending_review` / `transferring` / `licensed_*` と言う）は情報的だがそれ自体では信頼拡張ではない。相互する側が信頼拡張前に依然として確認しなければならない。

ハウス側とリーフ側エージェントの両方が話すとき（それぞれ `claim_type: "subsidiary"` と `claim_type: "parent"` 経由）、**相互主張がエージェント層で確立** されます。片側のみがエージェントを持つとき、[`brand.json` § 相互主張信頼モデル](/docs/brand-protocol/brand-json#mutual-assertion-trust-model) に従いクロールベースの相互主張推論にフォールバックします。

完全な信頼テーブルと悪意あるハウスのウォークスルーについては [`brand.json` § エージェント拡張検証](/docs/brand-protocol/brand-json#agent-augmented-verification) を参照してください。

## キャッシング

ステータスごと:

* `owned` / `not_ours` / `disputed` — 安定。24-72h。
* `pending_review` — 変動的。Max-age ≤1h。
* `transferring` — 遷移まで変動的。Max-age ≤4h。
* `licensed_in` / `licensed_out` — 中程度に変動的。24h。
* `use_case_authorization` — 最も変動的。セッションごとに再チェック。
* `unknown` — 短いキャッシュ（≤1h）。

エージェントは `Cache-Control: max-age=N` を設定すべきです（SHOULD）。消費者は下方にオーバーライドしてもよい（MAY）が、エージェント供給の `max-age` を超えるべきでありません（SHOULD NOT）。

エージェントは `signed_response.payload.exp` を `Cache-Control: max-age` が含意する HTTP 鮮度寿命より遅くない時に設定すべきです（SHOULD）。オンライン決定に署名付きレスポンスを使う消費者は、HTTP キャッシュ期限切れと署名付き `exp` のうち早い方を使わなければなりません（MUST）。その時点の後、エンベロープは新鮮な認可シグナルではなく監査証拠のみのままです。

## Error handling

| Error code               | Cause                                                                                                                             |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| `AUTH_INVALID`           | 呼び出し元の署名付きエンベロープが検証されなかった。                                                                                                        |
| `RATE_LIMITED`           | エージェントが `{caller_identity, claim_type, claim-target}` ごとに呼び出し元をレート制限した。エージェントは `Retry-After` を返しキャッシュされた以前の答えを返すことを優先すべき（SHOULD）。 |
| `UNSUPPORTED_CLAIM_TYPE` | エージェントが要求された `claim_type` を実装しない。`get_adcp_capabilities` 経由で `supported_claim_types` をチェック。                                       |
| `INVALID_INPUT`          | 必須の `claim` フィールドが欠けているか不正な形式（例: `subsidiary_domain` が有効なホスト名でない）。                                                                |
| `AMBIGUOUS_MATCH`        | `claim_type: "trademark"` — 複数の登録が一致。`registry`、`number`、`countries` で絞る。                                                         |

```json theme={null}
{
  "errors": [
    {
      "code": "UNSUPPORTED_CLAIM_TYPE",
      "message": "claim_type 'property' is not supported by this agent. Supported: subsidiary, parent, trademark."
    }
  ]
}
```