verify_brand_claim のバルクバリアント。エージェントは多くの検証質問に単一ラウンドトリップで答え、呼び出し元が送ったのと同じ順序でクレームごとに 1 つの結果を返します。MCP ラウンドトリップコストがクレームごとの作業を支配するときに使います — ブランドポートフォリオをリフレッシュするクローラー、1 つの権利保有者に対してクリエイティブバッチをクリアするクリエイティブクリアランスパイプライン、ハウスに対してサプライパスを検証する在庫オンボーディングスキャン。
これはバルクアフォーダンスで、異なる操作ではありません。 クレームごとのセマンティクス — 信頼モデル、適用可能なステータス、認可階層、クレームタイプごとの details 形状 — は単一ターゲットツールと同一です。単一ターゲットページで文書化されるすべてが結果ごとに適用されます。このページはバルク固有の関心事のみをカバーします。
バルクバリアントをいつ使うか
スキーマ
- Request:
verify-brand-claims-request.json - Response:
verify-brand-claims-response.json
ケイパビリティディスカバリー
バルクサポートは単一ターゲットツールと別にアドバタイズされます。エージェントは単一ターゲットツールのみ、バルクツールのみ、または両方を出荷してもよい（MAY）。supported_claim_types 宣言は、両方がアドバタイズされるとき両ツールに適用されます — バルクバリアントは、エージェントの単一ターゲット実装が答えられないクレームタイプを受け入れられません。
extensions スタイルエントリー経由でアドバタイズするか帯域外で文書化します。消費者は 100 を最大として扱うべきで（SHOULD）、エージェントの上限がより低いとき、それに応じてチャンクすべきです（SHOULD）。
順序が保持される
エージェントは、リクエストのclaims[] と同じ順序で results[] を返さなければなりません（MUST）（インデックスによる位置 zip）。呼び出し元は位置インデックスバッチを渡しインデックスで結果を消費します。この保証は、呼び出し元が再キーなしに入力と出力を相関できるようにします:
errors[] を運び results を省略します。「結果 かつ バッチエラーを伴う部分レスポンス」モードはありません — バッチエラーと結果ごとのエラーはワイヤーで相互排他的です。
部分失敗 — 結果ごとのエラー
クレームごとの失敗（多くのクレームの 1 つのUNSUPPORTED_CLAIM_TYPE、プロパティのポートフォリオの 1 つの商標クエリの AMBIGUOUS_MATCH）はバッチを失敗させません。results[] の対応するエントリーは claim_type/status の代わりに error フィールドを運び、バッチの残りは影響を受けません:
完全なエラーコードセマンティクスは 単一ターゲットタスクページ § 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 § エージェント拡張検証 を参照してください。
例 — ポートフォリオリフレッシュ
クローラーが既知の Nike ポートフォリオ（1 子会社チェック + 3 プロパティチェック）を 1 ラウンドトリップでリフレッシュ:subsidiary 結果を通じてガバナンス信頼を拡張するには、呼び出し元は依然として claim_type: "parent" で Converse のブランドエージェントを呼ぶ必要があります。バルク呼び出しはラウンドトリップ経済です。信頼モデルショートカットではありません。