Skip to main content
ブランドエージェントはブランドプロトコルのタスクを実装する MCP サーバーです。DAM、タレント事務所、ブランドポータルはブランドエージェントを構築して、データを AdCP 経由でバイヤーエージェントに提供します。 エージェントは get_adcp_capabilitiessupported_protocols: ["brand"] を宣言します。実装する具体的なタスクがその役割を定義します:

サーバーセットアップ

すべてのブランドエージェントは、AdCP タスクをツールとして登録する MCP サーバーから始まる。
バイヤーエージェントがサポートするプロトコルを発見できるよう get_adcp_capabilities を登録する:

トランスポートと HTTP セットアップ

MCP サーバーを HTTP エンドポイントに接続し、バイヤーエージェントがネットワーク経由で到達できるようにする:
これにより /mcp にステートレスな HTTP エンドポイントができます。本番環境では認証ミドルウェアと CORS ヘッダーを追加します。

ティア1: アイデンティティのみ

get_brand_identity を実装して、DAM またはブランドポータルからブランドデータを提供します。

パブリックデータと認可データ

すべての get_brand_identity レスポンスにはパブリックの基本情報が含まれます: brand_idhousenamesdescriptionindustrieskeller_type、基本的な logostagline。認証は不要。 sync_accounts でリンクされた認可済みの呼び出し元は、その基本情報に加えてより深いデータを取得できる: 高解像度アセット、音声合成設定、トーンガイドライン、権利の可用性。
パブリックの呼び出し元が fields: ["logos", "tone"] をリクエストすると、logos は取得できるが tone は取得できません。レスポンスには available_fields: ["tone"] が含まれ、アカウントをリンクすることで何がアンロックされるかを呼び出し元が知ることができます。

Adding verify_brand_claim

verify_brand_claim は、パートナーがブランドエージェントにそのアイデンティティについて権威ある yes/no の質問をできるようにします — 「この子会社はあなたのものか」「このプロパティはあなたのものか」「この商標はあなたのものか」。これはアイデンティティ層の上の階層化された機能です: 同じブランドデータに加え、静的な brand.json が表現できないよりリッチな状態(pending_reviewtransferringdisputedlicensed_in)です。 信頼モデルは方向によって非対称です。署名付きの拒否(disputed / not_ours)は一方的に権威を持ちます — ブランドは相互性なしに関連を拒否する立場を持ちます。署名付きのアサーション(owned / pending_review / transferring / licensed_*)は情報提供的ですが、単独では信頼を拡張しません。相互側が依然として確認しなければなりません。これが負荷を担う概念です — 完全な規範表については brand.json § エージェント強化検証 を参照。

Capability declaration

get_adcp_capabilitiesverify_brand_claim をアドバタイズし、ツールごとの拡張を通じてどのクレームタイプを実装するかを宣言します。ブランドエージェントは、4 つすべてではなくスライス(例: クリエイティブクリアランス用の property のみ、またはガバナンス信頼拡張用の subsidiary+parent)を出荷してもかまいません(MAY)。
supported_claim_types が省略された場合、エージェントは 4 つすべてのサポートをアドバタイズします。コンシューマーは、特定のクレームタイプに依存する前に確認しなければなりません(MUST)。サポートされていないタイプは UNSUPPORTED_CLAIM_TYPE を返さなければなりません(MUST)。

State model

エージェントは各クレームタイプに対応する内部データを必要とします。brand.json をこれらのストアの公開投影として扱います — エージェントは同じ事実に加え、よりリッチなライフサイクル状態を提供します。

Tool registration and request validation

verify_brand_claimclaim_type で判別します。タイプごとに claim ペイロードを検証します — 必須フィールドは異なり、欠けているか不正な場合は INVALID_INPUT が正しいレスポンスです。

Per-claim-type response shaping

details フィールドは claim_type によって異なります。内部記録から型付きレスポンスを構築し、呼び出し元がリンクされていない場合は認可専用フィールドを取り除きます。
同じシェイピングパターンが property(パブリック呼び出し元には details.use_case_authorization を省略)と trademarkmatched_registrationlicensor_domaincountriesnice_classes はパブリックに保持し、use_case_authorization は認可の背後にゲートする)に適用されます。

Public vs authorized field gating

get_brand_identity からのパブリック/認可の分割をミラーします。クレームタイプごとの分割: キュー位置、チケット状態、チームルーティングは、いかなる層でも決して公開されません。

Aging contract for pending_review

エージェントは、expected_resolution_window_days が経過したら、pending_review 記録を終端ステータス(owneddisputednot_ourstransferringarchived)または unknown に遷移させなければなりません(MUST)。コンシューマーは、古い pending_review レスポンスを unknown として扱い、クロールベースの検証にフォールバックすべきです(SHOULD)— しかしエージェントはいずれにせよ遷移を負っています。 cron 駆動のスイープが最もシンプルな実装です。
イベント駆動の実装も機能します — 記録作成時に first_observed_by_house_at + expected_resolution_window_days に遅延ジョブをスケジュールし、unknown に反転する前に人間のアクションが介入しなかったことをジョブで確認します。

Signing setup

レスポンスはブランドの adcp_use: "response-signing" JWK の下で署名されます。これは、エージェントが自身のアウトバウンド呼び出しに使う request-signing 鍵とは別個の鍵です — 目的ごとの鍵の慣例に従い、受信者は JWK の adcp_use レベルで目的を強制します。目的をまたいで鍵を再利用することは仕様で禁止されています。 署名は、レスポンスボディの内部に運ばれる JWS ペイロードエンベロープです(RFC 9421 §2.2.9 のトランスポートレスポンス署名ではありません — そのプリミティブは 3.x で未定義です)。verify_brand_claimverify_brand_claims は、仕様の指定タスクレスポンス署名リストにある唯一のタスクです — 閉じたリストのルールと入場基準はそこにあります。 エンベロープはレスポンスの signed_response フィールドに運ばれ、response-payload-jws-envelope.json に従います。brand_domain を呼び出し元の入力からではなく、サーバー側のテナント解決から投入します。共有マルチブランドフリートも、brand_domain ごとに別個のレスポンス署名鍵素材と別個の kid 値を必要とします。ブランドをまたいだ鍵の再利用はテナントバウンドのリプレイ分析を無効にし、adcp_use: "response-signing" について非準拠です。 AdCP 3.1 の適合性は、通常のタスクレスポンスに加えてネストされた signed_response を使います。JWS エンベロープをレスポンスボディ全体として返したプレリリースの例は 3.1 準拠ではありません。検証者は、プライベート移行中のみそのドラフト形状を受け入れてもかまいませんが(MAY)、それを準拠した指定タスクレスポンスとして扱ってはなりません(MUST NOT)。 エージェントの JWKS に JWK を公開し、brand.json の関連する agents[] エントリから参照します。
コードでは、返す前にレスポンスペイロードに署名します。署名なしの外側のフィールドは通常のタスクコンシューマーのために残ります。署名されたペイロードが正準の証明可能なオブジェクトです。
キーペア生成と JWKS 公開のパターンについては request-signing を参照。レスポンス署名鍵は、異なる adcp_use タグを持つ同じ形状に従います。 レスポンスボディミドルウェアの注意。 署名されるオブジェクトは signed_response.payload で、署名検証前に RFC 8785/JCS で正規化されます。そのサブオブジェクトの外側の空白やキー順の変更は署名に影響しませんが、signed_response.payloadsigned_response.protectedsigned_response.signature を変更するミドルウェアは検証を壊します。外側の便宜フィールドが存在する場合、検証者は、それらが signed_response.payload.response と一致しないとき署名付きレスポンスを拒否しなければなりません(MUST)。

Rate limiting

{caller_identity, claim_type, claim-target} ごとにレート制限します — 1 つの商標を叩き続けるバイヤーは多くのプロパティを調査するバイヤーとは異なり、それらを混同すると過剰または過小なブロックを招きます。制限時は Retry-After を返し、ハードな RATE_LIMITED エラーよりもキャッシュされた以前の回答を返すことを優先します。呼び出し元は古い owned に基づいて行動できます。429 には基づいて行動できません。

Cache headers per status

レスポンスに Cache-Control: max-age=N を設定します。タスクページからの推奨値: コンシューマーは下方にオーバーライドしてもかまいませんが(MAY)、エージェントが提供する max-age を超えるべきではありません(SHOULD NOT)。

Notification loop for pending_review

verify_brand_claim 呼び出しが未知の子会社/プロパティ/商標に着地し、エージェントのポリシーが「ポートフォリオチームに尋ねる」である場合、エージェントは pending_review 記録をエンキューし、チームに通知を表面化します。実装はエージェント側です。一般的なパターン:
  • brand.json contact.email のアドレスでポートフォリオチームにメールする。
  • ブランドの既存トラッカー(Jira、Linear、Zendesk)でチケットを開く
  • ポートフォリオチャンネルに Slack 通知する。
通知はクレームペイロード、呼び出し元アイデンティティ、expected_resolution_window_days を運びます。レビュアーのアクション — 受け入れ、拒否、移転、アーカイブ — が記録のステータスを反転させ、同じクレームでの次の verify_brand_claim 呼び出しが終端の回答を返します。

UI considerations

エージェントが disputed または not_ours を返すと、コンシューマーは拒否を自身の UI(DSP インベントリショッピング、ポートフォリオエクスプローラー、クリエイティブクリアランス)でレンダリングします。エージェントは明確な context_note を負っています — その文字列は人間の前に現れます。context_note テキストを書く際に留意すべきコンシューマー側の慣例については、拒否されたクレームの UI ガイダンス を参照。

ティア2: 権利のみ

タレント事務所や音楽シンクプラットフォーム向けに、権利探索とライセンスのために get_rightsacquire_rights を追加します。
acquire_rights は同じパターンに従う — get_rights からの rights_idpricing_option_id を受け取り、既存の契約に照らしてクリアし、生成資格情報付きの条件を返します。レスポンスには認証済みの approval_webhookpush-notification-config を使用)が含まれ、バイヤーがレビュー用のクリエイティブを送信できます。完全なスキーマは acquire_rights タスクリファレンス を参照。

機密ブランドルール

ブランドには開示できないルールがあることが多い — 公人ポリシー、内部の除外リスト、法的制限。エージェントはこれらを内部で評価し、ルール自体を明かさずにサニタイズされた理由を返します。 プロトコルはシンプルな慣例でこれをサポートする: 拒否に suggestions が含まれている場合、バイヤーは問題を修正できます。含まれていない場合、拒否は最終的でバイヤーは次に進むべきです。
同じパターンが get_rights の除外にも適用されます: バイヤーがクエリを調整できる場合(別のマーケット、別の日程)は除外結果に suggestions を含め、除外が交渉不可の場合は省略します。

プロービングへの防御

執拗なバイヤーエージェントが若干異なる変数で get_rights を呼び出す — 異なるブランド、業界、国 — 拒否のパターンから機密ルールをマッピングしようとするかもしれない。次の方法で軽減する:
  • 類似した機密拒否全体で一貫した汎用的な表現を使用します。 3つの異なるルールがすべて「これはタレントのライフスタイルガイドラインに抵触します」と表示されれば、バイヤーは繰り返しの試みから何も学べない。
  • どの特定のルールがトリガーされたかに関わらず同じ理由を返します。 ルールに基づいて表現を変えないこと — サイドチャンネルが生まれる。
  • バイヤーごとに探索呼び出しをレート制限します。 buyer_brand ごとのクエリ量を追跡し、閾値を超えたら徐々に具体性を下げた理由を返します。
get_rights レスポンスの exclusivity_status.existing_exclusives フィールドは特に注意が必要です。具体的な契約条件(「Acme Sports がオランダで Q3 まで独占権を持っている」)を入力すると競合情報を明かすことになります。曖昧な説明(「このカテゴリーで独占的なコミットメント」)を使うか、機密性が懸念される場合はフィールドを省略します。

フィールド選択とユースケース

fields パラメーターにより呼び出し元は必要なセクションのみをリクエストできます。効率的に実装する — リクエストされていない場合は高コストのデータ(アセットカタログ、音声設定)の読み込みを避ける:
use_case パラメーターは参考情報 — 返されたセクション内のコンテンツを調整するが fields をオーバーライドしません。"likeness" ユースケースは logos セクションでアクションフォトを優先し、"creative_production" ユースケースはベクターロゴとブランドマークを優先します。

マルチテナンシー

単一の MCP エンドポイントで複数のブランドを提供できます。各リクエストの brand_id パラメーターが呼び出し元がどのブランドについて尋ねているかを明確にします。
ロスター内の各ブランドは、バイヤーエージェントが MCP 呼び出しをする前に発見できるよう brand.json ファイルの brands 配列にも表示される必要があります。

アカウントリンク

バイヤーはあなたのエージェントで sync_accounts を呼び出すことで認可を確立します。リンク後、その後の get_brand_identity リクエストは認可済みと認識されます。 これをサポートするために アカウントプロトコル を実装します。リンクされたアカウントは MCP トランスポートの呼び出し元の資格情報で識別される — ブランドプロトコルリクエストにアカウント ID を渡す必要はない。

呼び出し元アイデンティティの抽出

呼び出し元の識別方法は認証セットアップによる。MCP トランスポートがセッション情報を提供し、認証ミドルウェアがそれをリンクされたアカウントにマッピングします。パターンについては 認証ガイド を参照。

権利とクリエイティブの統合

バイヤーが acquire_rights で権利を取得すると、generation_credentialsrights_constraint を受け取ります。これらは権利付与とクリエイティブ制作をつなぐ。

ブランドエージェント側の視点

acquire_rights を実装する際は、承認後にレスポンスで両方を返します:

バイヤー側での使用方法

バイヤーのオーケストレーターが generation_credentials をクリエイティブエージェントに渡し、クリエイティブエージェントがそれを AI プロバイダーで使用します。rights_constraint はクリエイティブマニフェストの rights 配列に埋め込まれる — クリエイティブと一緒にサプライチェーンを伝わり、チェーン内のすべてのシステムが使用条件を知ることができます。
クリエイティブエージェントは generation_credentials を使って AI プロバイダー(Midjourney、ElevenLabs など)に認証してアセットを制作します。rights 配列はクリエイティブマニフェストのメタデータの一部となる — ダウンストリームシステム(広告サーバー、検証ベンダー)はそれを調べてクリエイティブが適切にライセンスされていることを確認できます。 完全なクリエイティブマニフェストの仕様は クリエイティブマニフェスト を参照。

テスト

validate_brand_agent MCP ツールを使ってエージェントが到達可能で正しく応答しているかを確認します。開発中の自動テストには MCP SDK のインメモリトランスポートを使用します:
確認すべき主要事項: パブリックの呼び出し元にはコアフィールドが返されること、認可済みの呼び出し元にはより深いデータが返されること、available_fields が保留中のセクションをリストアップすること、無効な ID には brand_not_found エラーが返されること。

デプロイチェックリスト

  • brand.json/.well-known/brand.json にホストされ、brand_agent.url が MCP エンドポイントを指しています
  • get_adcp_capabilitiessupported_protocols: ["brand"] を返す
  • get_brand_identity がパブリックの呼び出し元にコアフィールドを返す
  • get_brand_identity が認可済みの呼び出し元に深いデータを返す
  • available_fields が保留中のセクションを正しくリストアップします
  • エラーレスポンスが errors 配列フォーマットを使用します
  • 権利を実装する場合: get_rights が価格オプションを返し、acquire_rights が条件を返す

関連