> ## 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_claims > verify_brand_claims は verify_brand_claim のバルクバリアント — 1 つのブランドエージェントに対して多くのクレームを単一ラウンドトリップで検証。同じ 4 つのクレームタイプ（subsidiary、parent、property、trademark）。結果はリクエストと位置的に揃えて返される。 [`verify_brand_claim`](/docs/brand-protocol/tasks/verify_brand_claim) のバルクバリアント。エージェントは多くの検証質問に単一ラウンドトリップで答え、呼び出し元が送ったのと同じ順序でクレームごとに 1 つの結果を返します。MCP ラウンドトリップコストがクレームごとの作業を支配するときに使います — ブランドポートフォリオをリフレッシュするクローラー、1 つの権利保有者に対してクリエイティブバッチをクリアするクリエイティブクリアランスパイプライン、ハウスに対してサプライパスを検証する在庫オンボーディングスキャン。 **これはバルクアフォーダンスで、異なる操作ではありません。** クレームごとのセマンティクス — 信頼モデル、適用可能なステータス、認可階層、クレームタイプごとの `details` 形状 — は単一ターゲットツールと同一です。単一ターゲットページで文書化されるすべてが結果ごとに適用されます。このページはバルク固有の関心事のみをカバーします。 ## バルクバリアントをいつ使うか | Workflow | Variant | Why | | ------------------------------------------------------ | --------------------------------------------------------------------- | ------------------------------------- | | 1 回限りの検証（単一ページ、単一クリエイティブ、単一子会社チェック） | [`verify_brand_claim`](/docs/brand-protocol/tasks/verify_brand_claim) | バッチングの利益なし。シンプルなエラーモデル。 | | ポートフォリオリフレッシュ（1 ブランドのすべての既知の子会社 / プロパティ / マークを再検証） | `verify_brand_claims` | MCP オーバーヘッドが支配。 | | クローラー駆動の完全ポートフォリオ検証（Nike ポートフォリオ: リージョン全体で約 100 プロパティ） | `verify_brand_claims` | 100 → 1 ラウンドトリップ。 | | クリエイティブクリアランスバッチ（1 つの権利保有者に対して N クリエイティブをプリフライトでクリア） | `verify_brand_claims` | バッチに同じレート制限スロット（下記参照）。 | | クロスブランド検証（異なるエージェントに対する異なるクレーム） | ブランドエージェントごとに 1 バルク呼び出し | 各エージェントは別のアドレス可能なエンドポイント。バルクはエージェント内。 | ## スキーマ * **Request**: [`verify-brand-claims-request.json`](https://adcontextprotocol.org/schemas/v3/brand/verify-brand-claims-request.json) * **Response**: [`verify-brand-claims-response.json`](https://adcontextprotocol.org/schemas/v3/brand/verify-brand-claims-response.json) ## ケイパビリティディスカバリー バルクサポートは単一ターゲットツールと別にアドバタイズされます。エージェントは単一ターゲットツールのみ、バルクツールのみ、または両方を出荷してもよい（MAY）。`supported_claim_types` 宣言は、両方がアドバタイズされるとき両ツールに適用されます — バルクバリアントは、エージェントの単一ターゲット実装が答えられないクレームタイプを受け入れられません。 ```json theme={null} { "supported_protocols": ["brand"], "supported_tasks": [ "get_brand_identity", "verify_brand_claim", "verify_brand_claims" ], "brand": { "verify_brand_claim": { "supported_claim_types": ["subsidiary", "parent", "property", "trademark"] } } } ``` エージェントは仕様の 100 上限より低い呼び出しごとのバッチシーリングをアドバタイズしてもよい（MAY）。シーリングが異なるとき、ケイパビリティ記述子の `extensions` スタイルエントリー経由でアドバタイズするか帯域外で文書化します。消費者は 100 を最大として扱うべきで（SHOULD）、エージェントの上限がより低いとき、それに応じてチャンクすべきです（SHOULD）。 ## 順序が保持される エージェントは、リクエストの `claims[]` と同じ順序で `results[]` を返さなければなりません（MUST）（インデックスによる位置 zip）。呼び出し元は位置インデックスバッチを渡しインデックスで結果を消費します。この保証は、呼び出し元が再キーなしに入力と出力を相関できるようにします: ``` request.claims[7] ↔ response.results[7] ``` バッチが全体的に失敗する場合（認証、レート制限、不正な形式のリクエスト）、レスポンスはトップレベル `errors[]` を運び `results` を省略します。「結果 かつ バッチエラーを伴う部分レスポンス」モードはありません — バッチエラーと結果ごとのエラーはワイヤーで相互排他的です。 ## 部分失敗 — 結果ごとのエラー クレームごとの失敗（多くのクレームの 1 つの `UNSUPPORTED_CLAIM_TYPE`、プロパティのポートフォリオの 1 つの商標クエリの `AMBIGUOUS_MATCH`）はバッチを失敗させません。`results[]` の対応するエントリーは `claim_type`/`status` の代わりに `error` フィールドを運び、バッチの残りは影響を受けません: ```json theme={null} { "results": [ { "claim_type": "property", "status": "owned", "details": { "regions": ["US"] } }, { "error": { "code": "AMBIGUOUS_MATCH", "message": "Multiple registrations match 'CONVERSE'; narrow with registry+number." } }, { "claim_type": "subsidiary", "status": "not_ours" } ] } ``` バッチレベルエラーは、エージェントが何も答えられない失敗のために予約されます: | Tier | Where it goes | Example codes | | ------ | ------------------ | ------------------------------------------------------------------ | | 結果ごと | `results[i].error` | `UNSUPPORTED_CLAIM_TYPE`、1 アイテムの `INVALID_INPUT`、`AMBIGUOUS_MATCH` | | バッチレベル | トップレベル `errors[]` | `AUTH_INVALID`、`RATE_LIMITED`、不正な形式のリクエスト、上限超過の `claims[]` | 完全なエラーコードセマンティクスは [単一ターゲットタスクページ § Error handling](/docs/brand-protocol/tasks/verify_brand_claim#error-handling) で文書化されています。 ## キャッシング 各結果は自身の古さを運んでもよい（MAY） — `pending_review` は短命（≤1h）、`owned` は安定（24-72h）。ステータスごとのキャッシングガイダンスは単一ターゲットページに従います。 バルクレスポンスのトップレベル `Cache-Control: max-age` は **バッチ全体の最小共通 max-age** を表します: 1 つの `pending_review` と 99 の `owned` 結果を持つバッチは `pending_review` シーリングでキャッシュすべき（SHOULD）、なぜなら消費者側キャッシュ無効化は通常レスポンス粒度で動作するから。結果ごとの古さを必要とする呼び出し元は、期待されるステータス変動性でバッチを分割するか、変動的なクレームを個別に再検証すべきです。 結果ごとのキャッシュヒントをサポートするエージェントは、`ext`（例: `results[i].ext.cache.max_age_seconds`）経由でそれらを表示してもよい（MAY）。これは拡張表面のままで、規範的レスポンスの一部ではありません。 ## レート制限 バルク呼び出しは、結果ごとではなく呼び出しごとに **単一のレート制限スロット** を消費します。100 クレームのバッチは `{caller, query-target}` ごとの制限に 100 回ではなく 1 回ヒットします。これはバルクバリアントの中核的経済論拠です — 制限は検証作業ではなくラウンドトリップにあります。 含意: * エージェントは、バルクがアドバタイズされるとき、クレーム/ウィンドウではなく呼び出し/ウィンドウでレート制限をサイズすべきです（SHOULD）。クレームボリュームが運用上重要な場合、バッチごとのクレーム上限をアドバタイズ（ケイパビリティディスカバリーを参照）。 * 呼び出し元は、同じエージェントに対して検証するとき N 単一呼び出しより 1 バルク呼び出しを優先すべきです（SHOULD） — コストと制限内に留まるため。 * バルク呼び出しの `RATE_LIMITED` レスポンスはバッチレベルエラーです。バッチ全体が拒否されます。`Retry-After` を尊重してリトライ。 ## Trust model 単一ターゲットツールと同一です。結果ごとの `status` は同じ方向非対称ルールに従います: 拒否（`disputed` / `not_ours`）は単一の署名付きレスポンスで権威的。主張（`owned` / `pending_review` / `transferring` / `licensed_*`）は肯定的信頼を拡張する前に相互性を要求します。 1 つのトップレベル `signed_response` エンベロープが完全な `results[]` 配列を証明します。その `request_hash` は `claims[]` リクエスト全体、呼び出し元アイデンティティ、解決された `brand_domain`、応答する `agent_url` をバインドします。結果ごとの署名はありません。オンライン決定に署名付きバルク結果を使う消費者は、単一ターゲットタスクと同じ鮮度ルールを適用します: HTTP キャッシュ期限切れと `signed_response.payload.exp` のうち早い方を使う。バルクレスポンスから 1 つの拒否された結果を抽出する監査ストアは、元のバッチリクエストと結果インデックスも保持しなければなりません（MUST）、なぜならエンベロープはスタンドアロンの結果ごとアーティファクトではなくバッチ全体を検証するから。 **「単一呼び出し相互主張」ショートカットはありません。** 1 つのエージェントに対するバルク呼び出しは、関係ペアの両半分が同じバルクリクエスト内に現れても、そのバッチの主張方向クレームの相互主張を確立しません。相互主張は同意する 2 当事者の性質です — `owned` を返す任意の `subsidiary` クレームにはリーフ側エージェントを別途呼ばなければならず、任意の `licensed_in` にはライセンサーのエージェントを呼ばなければならず、などなど。バッチングは MCP ラウンドトリップ経済についてで、信頼モデルを崩すことではありません。 完全な信頼テーブルについては [`brand.json` § エージェント拡張検証](/docs/brand-protocol/brand-json#agent-augmented-verification) を参照してください。 ## 例 — ポートフォリオリフレッシュ クローラーが既知の Nike ポートフォリオ（1 子会社チェック + 3 プロパティチェック）を 1 ラウンドトリップでリフレッシュ: ```json theme={null} { "claims": [ { "claim_type": "subsidiary", "claim": { "subsidiary_domain": "converse.com", "subsidiary_brand_id": "converse" } }, { "claim_type": "property", "claim": { "property": { "type": "website", "identifier": "nike.com" } } }, { "claim_type": "property", "claim": { "property": { "type": "website", "identifier": "nike.cn", "region": "CN" } } }, { "claim_type": "trademark", "claim": { "mark": "AIR JORDAN", "registry": "USPTO", "number": "1234567" } } ] } ``` ```json theme={null} { "results": [ { "claim_type": "subsidiary", "status": "owned", "details": { "brand_id": "converse" } }, { "claim_type": "property", "status": "owned", "details": { "relationship": "owned", "brand_id": "nike", "regions": ["US", "CA", "GB", "FR", "DE", "JP", "AU"] } }, { "claim_type": "property", "status": "owned", "details": { "relationship": "owned", "brand_id": "nike", "regions": ["CN"] }, "context_note": "Regional site for China market" }, { "claim_type": "trademark", "status": "owned", "details": { "matched_registration": { "registry": "USPTO", "number": "1234567", "mark": "AIR JORDAN", "registration_status": "active" }, "countries": ["US"], "nice_classes": [25, 41] } } ] } ``` `subsidiary` 結果を通じてガバナンス信頼を拡張するには、呼び出し元は依然として `claim_type: "parent"` で Converse のブランドエージェントを呼ぶ必要があります。バルク呼び出しはラウンドトリップ経済です。信頼モデルショートカットではありません。 ## バッチレベルエラー例 ```json theme={null} { "errors": [ { "code": "RATE_LIMITED", "message": "Caller has exhausted per-window quota. Retry after the indicated interval." } ] } ```