create_media_buy と並行する — get_rights から pricing_option_id を選択してキャンペーン詳細を提供します。エージェントは既存の契約に照らしてクリアし、条件、生成資格情報、開示要件を返します。
スキーマ
- リクエスト:
acquire-rights-request.json - レスポンス:
acquire-rights-response.json
応答時間
acquired または rejected まで数秒から数分。pending_approval ステータスは権利保有者がレビューする必要があることを意味する — 解決には数時間から数日かかる場合があります。
クイックスタート
パラメーター
リクエスト
レスポンスステータス
レスポンスはstatus の判別共用体を使用します:
拒否されたレスポンスに
suggestions が存在する場合、拒否は実行可能 — バイヤーはリクエストを調整して再試行できます。suggestions がない場合、拒否は最終的でバイヤーはこの権利/タレントの組み合わせで再試行すべきではありません。この慣例は acquire_rights の拒否、get_rights の除外結果、クリエイティブ承認の拒否全体で一貫して適用されます。
Request validation
acquire_rights について 2 つのキャンペーンフィールド検証が規範的です。どちらも、問題の field を投入した INVALID_REQUEST と recovery: "correctable"（バイヤーはリクエストを修正して再試行できる）を生成します。
Expired campaign window
ブランドエージェントは、リクエスト時点でcampaign.end_date が過去にある場合、INVALID_REQUEST と field: "campaign.end_date" で拒否しなければなりません（MUST）。すでに経過したウィンドウの権利を取得すると、期間ゼロの付与が生成され、これはほぼ常にバイヤー側のバグです — それを決定的に表面化させることは、直ちに期限切れになる資格情報を黙って発行するよりも有用です。
create_media_buy と同様に、権利の付与は経過したウィンドウについて時間シフト可能ではありません: コントラクトは要求された期間に付随するため、拒否のみが acquire_rights の正しいコントラクトです。
ブランドエージェントは、campaign.start_date が権利エージェントの設定された猶予ウィンドウより過去にある場合にも拒否してもかまいません（MAY。権利は遡及的に付与できないため、通常、権利エージェントは now - 24h より前の開始日を拒否します）。その決定はコントラクト固有で、field: "campaign.start_date" を使うべきです（SHOULD）。end_date < now チェックが規範的な下限です。
CPM-priced rights under a governance plan
リクエストは、ブランドエージェントが資格情報を発行する前にガバナンスプランに対してコミットメントを投影する場合にガバナンス対応です。それは 2 つのパスのいずれかで発生します。- インラインパス — リクエストが プロトコルエンベロープに意図フェーズの
governance_contextトークンを運ぶ。バイヤーはリクエストごとに明示的にトークンをスレッドする。 - バインドパス — リクエストが
account（セラーが割り当てたaccount_id、またはバインドされたアカウントに解決するaccount.brand+account.operator）を運び、ブランドエージェントがsync_governanceを通じてそのアカウントに以前バインドされたガバナンスエージェントを持つ。ブランドエージェントは、バイヤーがリクエストごとに何もスレッドせずに、バインドされたエージェントをルックアップする。
governance_context トークンとバインドされたガバナンスエージェントを持つ account — インライントークンが勝ちます。トークンはリクエストごとで、特定のプランに対して JWS 署名され、監査とレポートの主要な相関キーです。バインドされたエージェントは、トークンがスレッドされていない場合のリゾルバーフォールバックとして機能します。ブランドエージェントは、両方が存在する場合、バインドされたエージェントと異なっていても、インライントークンで識別されるエージェントを参照しなければなりません（MUST）— バイヤーのリクエストごとの決定が永続化されたバインディングをオーバーライドします。
両方のパスは同じ投影ルールをトリガーします。リクエストがガバナンス対応で選択された料金オプションが model: "cpm" を持つ場合、campaign.estimated_impressions がブランドエージェントが残りのプラン予算に対してコミットメントを投影するために使う入力です。その投影を実装間で決定的にするには:
- ブランドエージェントは、リクエストがガバナンス対応（いずれかのパス）で、選択された
pricing_option.modelが"cpm"で、campaign.estimated_impressionsが省略または0の場合、INVALID_REQUESTとfield: "campaign.estimated_impressions"で拒否しなければなりません（MUST）。実装者が選んだデフォルト（例: 100 万インプレッションを想定）は非準拠です — それらは各実装の内部にポリシー決定を隠し、同一のリクエストに対して異なるガバナンス結果を生成します。 estimated_impressionsが提供され非ゼロの場合、投影されたコミットメントは(pricing_option.price / 1000) × campaign.estimated_impressionsで、pricing_option.currencyで評価されます。pricing_option.currencyがガバナンスプランの予算通貨（プランで運ばれる）と異なる場合、ブランドエージェントはINVALID_REQUESTとfield: "pricing_option_id"で拒否しなければなりません（MUST）— ガバナンス投影に通貨変換は指定されていないため、通貨不一致のオファーは被管理プランに対してクリアできません。- 投影されたコミットメントがバイヤーの残りのプラン予算を超える場合、エージェントは
INVALID_REQUESTとfield: "campaign.estimated_impressions"で拒否しなければならず（MUST）、バイヤーが調整できるようreasonに投影されたコミットメントと残り予算を投入します。 - 非 CPM の料金オプション（
model: "flat_rate"など）は、インプレッションボリュームに関係なくフラット額をコミットします。ブランドエージェントは、それらのオプションについてガバナンス投影のためにestimated_impressionsを要求してはなりません（MUST NOT）。バイヤーは、上限追跡の目的で依然としてestimated_impressionsを提供してもかまいません（MAY）。
governance_context トークンもバインドされたガバナンスエージェントを持つアカウントもない — はこの検証の影響を受けません。その場合、estimated_impressions は任意のままです（セラーは、支出コミットの呼び出しに従い、商業ポリシーの問題としてガバナンスされていないプランでの取引を拒否してもかまいませんが（MAY）、その拒否はこの投影ルールとは独立です）。
生成資格情報
権利が取得されると、エージェントは LLM プロバイダーと連携してスコープ付き資格情報を発行する:- エージェントが既存の契約に照らして権利をクリアします
- エージェントがプロバイダー（例: Midjourney）に伝える: 「このタレントの権利キーを発行し、このバイヤーにライセンスする」
- エージェントがバイヤーに資格情報を返す
権利制約
status が acquired の場合、レスポンスには rights_constraint オブジェクトが含まれます:
クリエイティブのライフサイクル
権利取得後:- 生成: クリエイティブエージェントが
generation_credentialsを使ってコンテンツを制作 - マニフェスト:
acquire_rightsレスポンスのrights_constraintをクリエイティブマニフェストのrights配列に直接埋め込む。権利エージェントは合意された条件の正しい有効期間、国の制限、インプレッション上限を含むこの制約を事前に構築します。 - 承認: 提供された資格情報で認証しながら、
approval_webhookURL にcreative-approval-requestを POST します。レスポンスはステータスapproved、rejected、またはpending_reviewを持つcreative-approval-responseだ。pending_reviewの場合は、返されたstatus_urlを定期的にポーリングする（推奨: 5分ごと、1時間後は30分ごとにバックオフ）。 - 配信: 国と日程の制限を守りながら
create_media_buyで承認されたクリエイティブを配信 - 報告: 上限追跡と請求のために
rights_idを含むreport_usageを使用
acquire_rights が pending_approval を返し、push_notification_config を提供した場合、ステータスが acquired または rejected に変わるとウェブフック通知を受け取ります。それ以外の場合は、estimated_response_time の間隔後に同じ rights_id と idempotency_key で acquire_rights を再度呼び出す。この期間中に構築したクリエイティブマニフェストには approval_status: 'pending' を設定します。
取り消し
権利保有者が権利を取り消す必要がある場合（タレントの論争、契約違反など）、取得時に提供された資格情報で認証しながら、バイヤーのrevocation_webhook に revocation-notification を POST します。通知には notification_id（重複排除用）、rights_id、brand_id、reason、effective_at タイムスタンプが含まれます。
バイヤーの責任:
notification_idによる重複排除 — 同じ取り消しが複数回届く場合がありますeffective_atまでにクリエイティブの配信を停止します- アクティブなキャンペーンから影響を受けたクリエイティブを削除または置き換える
- 生成資格情報の使用を停止する（プロバイダーも独立して資格情報を無効化する場合があります）
revoked_uses が存在する場合、それらの使用のみ取り消されます（例: 音声は取り消されるが肖像は残る）。
取り消しの確認
取り消し通知を受け取って検証したらすぐに HTTP200 を返します。権利保有者は非 2xx レスポンスに対して指数バックオフ（1秒、5秒、30秒、5分、30分）で再試行します。6回の失敗後、権利保有者は他のチャンネルでエスカレーションする場合があります。
すべてのウェブフック認証は AdCP の プッシュ通知署名慣例 を使用する — HMAC-SHA256 による X-ADCP-Signature と X-ADCP-Timestamp ヘッダー。
インプレッション上限と超過
terms.impression_cap が設定されている場合、それはソフト上限だ。上限で配信が自動的に停止されることはない — バイヤーは report_usage を通じて使用状況を監視し、それに応じて配信を管理する責任があります。上限を超えたインプレッションは terms.overage_cpm で請求されます。権利保有者がハード上限（制限を超えた配信なし）を望む場合、restrictions でそれを指定します。
使用状況報告
取得されたレスポンスのusage_reporting_url は、権利エージェントが HTTP ベースのインプレッション報告のために提供する便利なエンドポイントです。report_usage MCP タスクと同じペイロードを受け付けます。パイプラインにとってシンプルな方を使用する — エージェント間ワークフロー用の MCP ツール、または広告サーバーからの直接 HTTP 呼び出し用の URL。
更新と更新
権利付与を延長、インプレッション上限の調整、価格の変更、一時停止/再開にはupdate_rights を使用します。延長された付与には再発行された生成資格情報と、マニフェストに再埋め込みするための更新された rights_constraint が含まれます。
次のステップ
update_rights
既存の権利付与を延長、調整、または一時停止します。
report_usage
請求と上限追跡のために権利付与に対するインプレッションを報告します。
brand.json 仕様
クリエイティブマニフェストの権利制約。