Campaign Governance specification
実験的機能。 キャンペーンガバナンスは、実験的サーフェスとして AdCP 3.0 の一部です — 少なくとも 6 週間の予告をもって 3.x リリース間で変更される可能性があります。これを実装するセラーは
experimental_features で governance.campaign を宣言しなければなりません（MUST）。完全なコントラクトについては 実験的ステータス を参照。Campaign plan
キャンペーンプランは、すべての検証における真実の源泉です。プランはsync_plans を通じてガバナンスエージェントにプッシュされ、キャンペーンのプランパラメーター — 予算制限、チャンネル、フライト日程、プラン市場 — を定義します。ガバナンスエージェントはブランドのコンプライアンス設定から適用可能なポリシーを解決します。プランは policy_ids でレジストリポリシーを直接参照したり、custom_policies でキャンペーン固有のルールを含めたりすることもできます。
Purchase types
ガバナンスプランは、メディアバイだけでなくすべての金銭的コミットメントを管理します。check_governance の purchase_type フィールドが、どの種類のコミットメントが検証されているかを識別します。
すべての購入タイプは同じガバナンスループを共有します:
sync_plans → check_governance → 実行 → report_plan_outcome。ガバナンスエージェントは、すべてのタイプにわたって予算権限、ジオコンプライアンス、フライトコンプライアンスを検証します。メディアバイ固有の検証（チャンネルコンプライアンス、セラー集中度、配信ペーシング）は、purchase_type が media_buy の場合、またはペイロードが関連フィールドを含む場合にのみ適用されます。
purchase_type が省略された場合、ガバナンスエージェントは media_buy を想定します。
将来の購入タイプ: コンテンツ標準、プロパティリストのキュレーション、測定/検証サービス（ブランドリフト調査、ビューアビリティ、フラウド検出）はすべて、スキーマに
pricing_options を運び、report_usage を通じて課金します。これらのサービスは現在、バイヤーがサービスにコミットする明示的な有効化ツールを欠いています — 課金関係は暗黙的です。プロトコルがこれらのサービスの有効化サーフェスを追加する際、コミットメント時点でのガバナンスチェックを可能にするために、対応する購入タイプが追加されます。Budget reallocation
budget.reallocation_threshold（必須の数値）は、予算再配分の自律性を管理します。これは、データ主体に影響する決定の必須の人間によるレビューをカバーしません — それについてはプランレベルの human_review_required フィールドを参照。
Budget allocations
プランは任意で、allocations を使って総予算を購入タイプ間で分割できます。
allocations が存在する場合、ガバナンスエージェントはタイプごとの割り当てと全体の総額の両方に対して支出を検証します。存在しない場合、購入タイプに関係なくすべての支出が単一の総額に対してカウントされます。割り当てはガードレールであり、ハードな分割ではありません — 割り当ての合計は総額と異なってもかまいません（MAY）。
allocations が存在するが購入タイプがリストされていない場合（例: media_buy と rights_license のみを割り当てるプランに対して signal_activation が試みられる）、ガバナンスエージェントはアクションをプランの総予算のみに対して検証します。リストされていないタイプは拒否されません — 共有プールから引き出します。支出をリストされたタイプのみに制限するには、明示的な制約を持つ custom_policies を設定します。
Human review required
human_review_required は、予算再配分の自律性とは独立に、プラン上のすべてのアクションの人間による監督を義務付けるプランレベルのブール値（デフォルト false）です。
ガバナンスエージェントは、プラン上の解決されたポリシーまたは policy_category が requires_human_review: true を運ぶ場合、human_review_required: true を自動的に設定します。これには、fair_housing、fair_lending、fair_employment、pharmaceutical_advertising などの規制業種、および附属書 III のユースケースにおける決定をカバーする eu_ai_act_annex_iii ポリシーが含まれます。
human_review_required が true の場合、ガバナンスエージェントは — プランの reallocation_threshold に関係なく — プラン上のあらゆるアクションを実行前に人間のレビューにエスカレーションしなければなりません（MUST）。プランが human_review_required: true を運ぶとき、寛容な再配分しきい値は人間のレビューをバイパスしません。2 つの次元は合成されます。
このフィールドは budget.reallocation_threshold とは異なります。
呼び出し元は、トリガーとなるポリシーが存在しない場合でも、プラン上で
human_review_required: true を明示的に設定してもかまいません（MAY）。呼び出し元は、人間のレビューを要求するポリシーをオーバーライドするために false に設定してはなりません（MUST NOT）— ガバナンスエージェントはすべての同期でこのフラグを解決されたポリシーから再評価し、トリガーとなるポリシーが存在する場合、呼び出し元が提供した false をオーバーライドします。
Spend-commit invocation
バイヤー側のガバナンス呼び出しは、アドバイザリではなく強制可能です。プランにガバナンスエージェントが設定されている場合、バイヤーエージェントは、セラーに支出コミットリクエストを送信する前にcheck_governance を呼び出さなければならず（MUST）— 例外なく — そのリクエストに添付する意図フェーズの governance_context トークンを生成します。ガバナンスエージェントは、プランの budget.reallocation_threshold と human_review_required フィールドに従って、自動承認、条件適用、拒否、または人間のレビューへのエスカレーションを内部的に決定します。呼び出しルールにドル金額、ベースライン計算、オペレーター宣言の下限は現れません — それらの自動承認の高速パスは、呼び出すかどうかというバイヤーの決定ではなく、ガバナンスエージェント自身のポリシーの内部に属します。
Spend-commit tasks
呼び出しの MUST は、リクエストの時点で金銭的義務を付与するすべての AdCP タスクに適用されます。create_media_buy— パッケージ全体のコミット済み予算update_media_buy— 増分コミットデルタ（新予算 − 以前にコミットされた額）acquire_rights— 権利価格update_rights— 増分コミットデルタactivate_signal— 有効化料build_creative— クリエイティブ生成料- 将来の支出コミットタスク
get_products、get_signals）、レポートタスク（例: get_media_buy_delivery）、または運用ステータスタスクには必須ではありません。MUST は金銭的義務の時点で特に発火します。
プランにガバナンスエージェントが設定されていない場合、check_governance の呼び出しは必須でも意味もありません — 呼び出す対象がありません。セラーは、独自の商業ポリシーの問題として、ガバナンスエージェントが設定されていないプランでの取引を拒否してもかまいません（MAY。エンタープライズセラーは通常拒否します）。プロトコルはガバナンスエージェントを義務付けず、ブランドが公開する設定が、セラーが 1 つ存在するかどうかを発見する手段です。
同じプランを複数のセラーにファンアウトするオーケストレーターは、aud がターゲットセラーにバイト単位でバインドされるため、セラーごとに 1 つの意図トークンを生成します。これは正しいプロトコル形状ですが、ガバナンスエージェントがプラン上のバイヤーの完全な買い物リストを見ることを意味します。買い物の意図を商業的に機密と見なすオペレーターは、データ処理の姿勢を信頼できるガバナンスエージェントを選ぶべきです（SHOULD）。
Seller enforcement
ガバナンスエージェントが設定されたプランの支出コミットリクエストを受け取ったセラーは、リクエスト上で有効で期限内の意図フェーズのgovernance_context トークンを要求しなければならず（MUST）、セラー検証チェックリストに従って検証します。トークンは phase: "intent" を運び、（sub を通じて）リクエストの plan_id に一致し、（aud）このセラー宛てでなければなりません。トークンのないリクエスト、検証に失敗するトークンを持つリクエスト、または別のプラン・別のセラー・非意図フェーズ向けに発行されたトークンを持つリクエストは、PERMISSION_DENIED で拒否しなければなりません（MUST）。次にセラーは、planned_delivery と受け取った governance_context を伴って check_governance を呼び出すことで自身の実行チェックを実行します。その呼び出しは、メディアバイライフサイクルの残りに使われる purchase フェーズのトークン（セラーが割り当てた media_buy_id にバインド）を生成します。この 2 段階のフローが、バイヤー側の MUST を実効化します。check_governance をスキップするバイヤーは有効な意図トークンを生成できず、支出コミットはセラーが実行チェックに到達する前に拒否されます。
セラーは、受け入れた意図トークンとその後保持するライフサイクルトークンを、最低限 jti をキーとして、iss、aud、sub（plan_id）、phase、決定結果、受け入れのタイムスタンプとともに永続化しなければなりません（MUST）。保持はセラーの規制上の保持期間に従います。セラー側の保持がなければ、監査ログはガバナンスエージェントからの単一ソースになります。セラー記録と get_plan_audit_logs の間の独立した照合が、侵害されたまたは不正なガバナンスエージェントを捕捉するクロスチェックです。
セラー側ガバナンス（セラー自身がアカウントにガバナンスエージェントを設定している場合）は独立した層です。バイヤーの成功した check_governance は、セラーにリクエストの受け入れを義務付けません。セラー自身のコンプライアンスポリシーは、依然として PERMISSION_DENIED を通じてアクションを拒否してもかまいません（MAY）。
承認されたトークンは、検証時点で権威を持つ exp を運びます。トークンの有効ウィンドウ内でのポリシー変更は、あらゆる署名決定システムの受容される残余リスクです。厳しい exp 値（意図トークンは JWS プロファイルに従い 15 分以内に期限切れになるべき（SHOULD））は、ウィンドウを閉じるのではなく制限します。ウィンドウを許容できないオペレーターは、キャッシュに関係なくすべてのアクションが内部の人間によるレビューを通るよう、reallocation_threshold を 0 に、または human_review_required: true に設定しなければなりません（MUST）。
Audit logging
すべてのcheck_governance 呼び出しは、get_plan_audit_logs を通じて取得可能な監査ログエントリを生成しなければならず（MUST）、次を捕捉します。
- タイムゾーンオフセット付き ISO 8601 文字列としての呼び出しタイムスタンプ
- 検証されるツール（
create_media_buy、acquire_rightsなど）とプランの通貨でのコミット額 - 結果（
approved、denied、conditions。および人間のレビューが内部的に呼び出されたかどうか） - 人間のシグナルが記録された場合の人間のアクターの識別と権限
- ダウンストリームの支出コミットタスクの監査エントリおよび
report_plan_outcomeからのクロスリファレンス用のcheck_id
check_id を生成します。report_plan_outcome は単一のチェック識別子ではなく plan_id を通じて相関させます。支出コミットを再構築する監査人は、バイヤー側エントリ、セラー側エントリ、セラーが永続化したトークン記録を照合します。
Interaction with idempotency
- 以前の意図フェーズ
governance_contextを運ぶ同一ペイロードのリトライ: 再呼び出しなし。キャッシュされたガバナンスレスポンスが再利用されます。トークンの署名と鮮度が再検証されます。セラー側のリプレイ重複排除キー（検証チェックリストを参照）は、同じidempotency_keyを運ぶ繰り返されたjtiを、リプレイ攻撃ではなく正当なリトライとして扱わなければなりません（MUST）— これが唯一の狭い適用除外です。 - 異なるペイロードでの再プラン（冪等性に従う新しい
idempotency_key）: 新しいcheck_governance呼び出しが必要です。新しいgovernance_contextトークンが発行されます。
purchase フェーズトークンに対して動作します。これは、バイヤーの意図チェックではなく、セラーの実行チェックによって管理される別個のアーティファクトです。
Channel mix targets
mix_targets フィールドは、許容される配分範囲を定義します。ガバナンスエージェントは、すべてのメディアバイにわたる集計支出がこれらの範囲内に収まることを検証します。ビデオ支出を総予算の 70% 超に押し上げる create_media_buy は、conditions または denied のステータスをトリガーします。
Delegations
プランは、どのエージェントがプランに対して実行を認可されているか、どのような制約でかを指定するdelegations 配列を含めることができます。これにより、ブランドとエージェンシー間の委任関係がプロトコル内で明示的になります。
委任が存在する場合、ガバナンスエージェントは、アクションを承認する前に
check_governance の caller URL が委任の agent_url に一致することを検証します。マッチングは厳密な URI 比較（RFC 3986 に従う正規化後、大文字小文字を区別）によります。フランスでメディアバイを要求するエージェントは、markets にフランスを含む委任を持たなければなりません。execute_only 権限を持つエージェントは、チャンネル間で予算を再配分できません。
委任が存在しない場合、ガバナンスエージェントはどのエージェントがプランに対して行動できるかを制限しません。
delegations.authority は、委任された実行エージェントがプランを代行して何ができるかを管理します。これはプランの予算自律性（budget.reallocation_threshold / budget.reallocation_unlimited）とは無関係で、plan.human_review_required とも無関係です。3 つの別個の関心事: エージェントごとのスコープ、予算運用、決定ごとのレビュー。Portfolio governance
ホールディングカンパニーやマルチブランド組織のために、プランはクロスブランド制約を定義するportfolio オブジェクトを含めることができます。ポートフォリオプランはメンバープランを管理します — メンバープランに対して検証されるあらゆるアクションは、ポートフォリオプランの制約に対しても検証されます。
total_budget_cap: すべてのメンバープランにわたる最大集計支出。ガバナンスエージェントはすべてのメンバープランにわたってコミット済み予算を追跡し、上限を超えるアクションを拒否します。shared_policy_ids: 個々のブランドコンプライアンス設定に関係なく、すべてのメンバープランにわたって強制されるレジストリポリシー。どのブランドチームもオーバーライドできないコーポレートレベルの規制。shared_exclusions:PolicyEntry形状を使って、すべてのメンバープランに適用されるビスポークな除外ポリシー。追加のみ — プランレベルのcustom_policiesと同じ制約。
member_plan_id を参照する場合、ガバナンスエージェントはポートフォリオプランを受け入れ、メンバープランが同期されるにつれてポートフォリオ制約の強制を開始すべきです（SHOULD）。これにより、特定の順序を要求することなく、メンバープランの前にポートフォリオプランを同期できます。
並行性: オーケストレーターは、複数のセラーに同時に
create_media_buy リクエストを送信し、それぞれが committed チェックをトリガーする場合があります。予算チェックは特定時点のもので予算を予約しないため、同時承認が合計でプラン予算を超える場合があります。ガバナンスエージェントは結果レポート時にオーバースペンドを検出します。同時のオーバースペンドを防ぐには、実行エージェント間で予算を分割するために、エージェントごとの budget_limit を持つ 委任 を使います。Aggregated-spend evaluation (fragmentation defense)
ガバナンスしきい値（reallocation_threshold、human_review_required のトリガーポイント、レジストリポリシーのドル下限）は、プランごとまたはメディアバイごとに単独ではなく、トレーリングウィンドウにわたる集計コミット済み支出に対して評価しなければなりません（MUST）。意図した 999,900 ドルの支出を 100 × 9,999 ドルのバイに分割するバイヤー — それぞれが個別にはオペレーターの 10,000 ドルの人間レビューしきい値を下回る — は、そうでなければレビューを完全にバイパスします。これはガバナンスに対するフラグメンテーション攻撃であり、正当な利用パターンではありません。ガバナンスエージェントはこれを閉じなければなりません（MUST）。
ガバナンスエージェントは、任意のしきい値を評価する際、次のすべてにわたってコミット済み支出を集計しなければなりません（MUST）。
- 同じ
(buyer_agent, seller_agent, account_id)タプルに帰属可能なすべてのプラン — 同じアカウント上のプラン間でのフラグメンテーションは集計をリセットしません。委任されたサブエージェント（委任を参照）は委任元バイヤーの集計を共有します: キーのbuyer_agent要素は委任元プリンシパルであり、サブエージェントのagent_urlではありません。委任は新しいエージェントごとの集計ウィンドウを作りません。そうでなければ委任サーフェス自体がフラグメンテーションの穴を再び開くからです（999,900 ドルを 100 のサブエージェントに分割し、それぞれが独自の 9,999 ドルの予算を得る）。 - すべての 支出コミットタスク — タスクサーフェス間でのフラグメンテーションは集計をリセットしません。支出コミットタスクのインベントリが唯一の権威あるリストです。そこに追加される新しい支出コミットタスクは、本セクションでの別個の編集なしに自動的に集計に加わります。
governance.aggregation_window_daysケイパビリティを通じて宣言されるトレーリングウィンドウ（下記 get_adcp_capabilities を参照）。ウィンドウはプラン境界ではなく実時間でスライドします。
aggregate を適用可能な各しきい値に対して評価します。現在の受信コミットは合計に含まれます。完全に拒否されたコミットは寄与しません。承認された、または条件付きで承認されたコミットは寄与します。now は評価時のガバナンスエージェントの実時間です。スライディングウィンドウの境界はプランやカレンダーの境界にスナップされません。
コミットメントはウィンドウ内でスティッキーです。 c.amount は承認時にコミットされた額であり、配信された額ではありません。アンダーデリバリー、キャンセル、メイクグッド、承認後の予算削減は、トレーリングウィンドウがそれをロールオフする前に、コミットの集計への寄与を減じてはなりません（MUST NOT）。そうでなければ、バイヤーは承認済みコミットをキャンセルして直ちにしきい値未満で再コミットすることでフラグメンテーションの余地を解放できます — ラウンドトリップにわたって完全な支出が移動し、各レグが単独で通過します。コミット済み予算を増やす update_media_buy はデルタ（新コミット済み予算 − 以前のコミット済み）として入ります。減少は減じません。
個々のコミットが単独ではしきい値を下回るが、トレーリングウィンドウの集計をしきい値超に押し上げる場合、ガバナンスエージェントはそのコミットにしきい値の帰結（人間レビューへのエスカレーション、拒否、または条件）を適用しなければなりません（MUST）。ガバナンスエージェントは、監査人が完全な結果ストリームから再導出せずにフラグメンテーション防御の決定を再構築できるよう、get_plan_audit_logs レスポンスに aggregate_committed フィールドを公開してもかまいません（MAY）。フィールドの形状（単位、通貨、ウィンドウ境界のレポート）は 3.x ではガバナンスエージェント固有で、後の改訂で標準化されます。それを公開する実装は、get_plan_audit_logs レスポンスとともに形状を文書化すべきです（SHOULD）。
ガバナンスエージェントは、より狭い集計スコープ（ブランドごと、キャンペーンごと）を追加で評価してもかまいませんが（MAY）、オペレーターの署名なしに宣言されたウィンドウより広いスコープを評価してはなりません（MUST NOT）。「より広い」は両方の次元をカバーします: より長いトレーリングウィンドウ（時間）とより広いキータプル（例: account_id にまたがって折りたたみ、2 つのアカウントが集計を共有する）。いずれかの次元での黙って広げられたスコープは、黙って狭められたスコープと同じくらいオペレーターにとって驚きです。
Composition with reallocation_threshold
再配分自体が支出コミットです: update_media_buy は増分コミットデルタ（新コミット済み予算 − 以前にコミットされた額）を運び、そのデルタは集計に入り reallocation_threshold 評価にカウントされます。バイヤーは、1 つの 30,000 ドルの再配分を 6 つの 4,999 ドルの更新に分割することで 25,000 ドルの再配分しきい値を回避できません — 各更新のデルタはトレーリングウィンドウの集計に蓄積され、累積デルタがそれを超えるとしきい値をトリップします。
Conformance example
エージェントがaggregation_window_days: 30 を宣言します。プランはコミット済み支出 10,000 ドルで human_review_required トリガーを設定します（(buyer_agent, seller_agent, account_id) をキーとする）。
エスカレーションなしに行 2 を承認するガバナンスエージェントは非準拠です: 30 日ウィンドウにわたる集計に失敗したか、正しいタプルでキー付けに失敗したか、受信コミットを合計に含めることに失敗したかのいずれかです。
Governance aggregation capability
セラーとガバナンスエージェントは、get_adcp_capabilities の governance.aggregation_window_days を通じて集計ウィンドウを宣言します。コンプライアンスのために特定のウィンドウに依存するバイヤー（例: ブランドレベルの週次ケイデンスレビュー）は、集計セマンティクスに依存する前にこのケイパビリティを確認しなければなりません（MUST）— aggregation_window_days: 7 を宣言するガバナンスエージェントは、30 日の四半期末プッシュにまたがって広がるフラグメンテーションから防御しません。宣言がないことは、エージェントがいかなる集計ウィンドウにもコミットしていないことを意味し、バイヤーはコミットごとの評価のみを想定しなければなりません（MUST。フラグメンテーション攻撃サーフェスが開いている）。スキーマのデフォルトはありません: 省略は宣言された 30 日ウィンドウと同等ではありません。
Brand compliance configuration
コンプライアンスポリシーは、個々のキャンペーンプランではなくブランドレベルに存在します。ブランドのポリシーチームがブランドのコンプライアンスプロファイルを設定し、ガバナンスエージェントがそのブランドのプランを処理する際にそれを解決します。ブランドコンプライアンス設定のスキーマとホスティングメカニズムは、AgenticAdvertising.org ガバナンスワーキンググループによって開発中です。以下は概念モデルを説明します。実装は異なる場合があります。
- レジストリポリシー: AdCP ポリシーレジストリ の標準化されたポリシーへの ID による参照。各参照は、ブランド向けにポリシーをカスタマイズする設定パラメーターを含んでもかまいません（MAY）。
- カスタムポリシー: 自然言語文字列として表現されるブランド固有のルール。プロンプトベースのポリシーと同じアプローチでガバナンスエージェントが評価します。
Policy registry
ポリシーレジストリは、標準化された機械可読な広告コンプライアンスポリシーのコミュニティ管理ライブラリです。ブランドは独自に記述する代わりに ID でポリシーを参照します。 レジストリは 3 つのカテゴリをカバーします。
レジストリの各ポリシーには、ID、適用管轄、説明、およびガバナンスエージェントがプログラム的に評価できる機械可読なルールがあります。ポリシーは規制の変更に応じてバージョン管理されます。ブランド参照は特定のバージョンにピン留めしてもかまいません（MAY）。バージョンなしの参照は現在のバージョンに解決されます。レジストリ形式とホスティングメカニズムは AgenticAdvertising.org ガバナンスワーキンググループによって開発中です。
このモデルは、IEEE 7012（Machine Readable Personal Privacy Terms）が確立したパターンに従います。IEEE 7012 は、当事者が個別に起草するのではなく参照する標準化された合意の中立的な名簿を維持します。
Policy resolution
ポリシーはpolicy_ids と custom_policies を通じてプラン上で直接宣言されます。プランが同期されると、ガバナンスエージェントはアクティブなポリシーセットを解決します。
policy_idsで参照されるレジストリポリシーを読み込む- プランの
countriesとregionsと交差させる — プランの市場に適用可能なポリシーのみがアクティブ - すべての
custom_policiesを含める（これらは地理に関係なく適用される）
countries と regions フィールドはジオ強制としても機能します: ガバナンスエージェントは、プランの許可された地理の外の市場をターゲットにする被管理アクションを拒否しなければなりません（MUST）。regions: ["US-MA"] のプランは、他の点でコンプライアントであっても、明示的にマサチューセッツをターゲットにしないアクションを拒否します。これらのフィールドは product-filters、offerings、create_media_buy と同じ ISO コードとセマンティクスを使います。
解決されたポリシーセットは、ガバナンスエージェントが check_governance 中に評価するものです。brand_policy と regulatory_compliance カテゴリについて、ガバナンスエージェントはこの解決されたセットに対して検証します。
プランに policy_ids または custom_policies がない場合、ガバナンスエージェントはポリシーベースのカテゴリについて空のポリシーセットで動作します。他のカテゴリ（budget_authority、strategic_alignment など）は、プランのパラメーターに基づいて依然として適用されます。
Audience governance
キャンペーンプランは、オーディエンスターゲティング制約、制限属性、ポリシーカテゴリを宣言します。ガバナンスエージェントはこれらを使って、セラーのターゲティングが規制要件とキャンペーンの意図に準拠していることを検証します。Three-layer model
オーディエンスガバナンスは 3 つの関心事を分離します。
製薬会社は常にファーマ（アイデンティティ）ですが、一般的な認知キャンペーンは製薬広告規制をトリガーしないかもしれず（レジーム）、EU 管轄のキャンペーンのみが健康データターゲティングを制限するかもしれません（制限）。
Audience constraints
プランは、オーディエンスセレクターを使ってaudience.include と audience.exclude 配列を宣言できます。各セレクターは signal_ref または自然言語の説明のいずれかです。
ガバナンスエージェントは、check_governance でこれらの制約をセラーのターゲティングに対して評価します。
planned_delivery.audience_targetingをプランのaudience.include/excludeと比較planned_delivery.audience_targetingを同じ制約と比較（コミット済みチェック用）- オーケストレーターが要求したものとセラーが有効化するものの間の乖離を検出
Structural governance matching
シグナル定義はrestricted_attributes と policy_categories を自己宣言できます。そうする場合、ガバナンスエージェントは構造的マッチング — プランの制限とシグナルの宣言の間の集合の交差 — を実行します。これは決定的で、LLM 推論を必要としません。
ガバナンスメタデータを宣言しないシグナルについて、ガバナンスエージェントはセマンティックマッチング — シグナル名と説明から機密性を推論する — にフォールバックします。構造的マッチングはセマンティックマッチングより高信頼度の検出事項を生成します。
制限属性は include と exclude の両方のターゲティングに適用されます。制限データを使ってオーディエンスを除外すること（例: 製薬広告から健康状態のある人を除外する）は、それを包含に使うのと同じくらい禁止されています — どちらもターゲティング決定のための制限された個人データの使用を構成します。
Audience distribution drift
配信中、セラーはdelivery_metrics で audience_distribution をレポートします。インデックス値は、宣言されたベースライン（census、platform、または custom）に対する人口構成を示します。値 1.0 は同等を意味します。大幅に上または下の値はスキューを示します。
ガバナンスエージェントは、期間ごとのインデックスとすべてのレポート期間にわたる累積インデックスの両方を追跡します。これにより、単一のレポート期間では見えないかもしれない体系的なバイアスの検出が可能になります。
State tracking
ガバナンスエージェントは 2 つのレベルで状態を追跡します。- プランレベル: コミット済み総予算、チャンネル配分パーセンテージ、プランステータス
- キャンペーンレベル:
governance_contextごとのコミット済み予算、アクティブなメディアバイ参照、検証履歴
check_governance が予算権限をチェックするとき、プランに紐付けられたすべてのキャンペーンを考慮します。report_plan_outcome がセラー確認をレポートするとき、ガバナンスエージェントは要求された額ではなくセラーの実際の額から予算をコミットします。
Plan status
ステータスが
suspended の場合、ガバナンスエージェントは、エスカレーションが解決されるまで、すべての check_governance および report_plan_outcome リクエストを CAMPAIGN_SUSPENDED エラーで拒否しなければなりません（MUST）。
Budget tracking
予算は、検証されたアクションではなく確認された結果に基づいてコミットされます。フロー:tool+payload（意図チェック）を伴うcheck_governanceが、提案された支出がプランに収まるかをチェックします。まだ予算はコミットされません。- オーケストレーターがセラーとアクションを実行します。
report_plan_outcomeがセラーの確認済み額をレポートします。ガバナンスエージェントはこの額をプラン予算にコミットします。
report_plan_outcome を呼び出すときにのみコミットされます。
予算チェックは特定時点のものです: check_governance は現在のコミット済み総額に対して検証しますが、予算を予約しません。複数のエージェントが同じプランに対して同時に実行する場合、2 つのチェックが両方通過し、組み合わせた結果が認可された予算を超える可能性があります。ガバナンスエージェントは結果レポート時にオーバースペンドを検出し、budget_authority 検出事項を返します。同時のオーバースペンドを防ぐには、実行エージェント間で予算を分割するために、エージェントごとの budget_limit を持つ 委任 を使います。
Drift detection
監査ログには、プランの存続期間にわたる集計ガバナンストレンドを表面化するdrift_metrics が含まれます。
組織はドリフトメトリクスにしきい値を設定できます。メトリクスがしきい値を超えると、ガバナンスエージェントは次のガバナンスチェックに検出事項（深刻度
warning）を含めるべきです（SHOULD）。
human_review_rate_min は監視の侵食を捕捉します。human_review_rate_max はポリシーの誤キャリブレーションを捕捉します。human_override_rate_max は、推奨が一貫して間違っているガバナンスエージェントを捕捉します。すべてのしきい値フィールドは任意です。
Plan amendments
既存のplan_id で sync_plans を呼び出すと、プランが更新されます（upsert）。ガバナンスエージェントは plan_version をインクリメントし、新しいパラメーターを直ちに適用します。以前のプランバージョンで承認されたアクティブなメディアバイは自動的に再検証されません — ガバナンスエージェントは次の check_governance 呼び出し（例: 次の配信チェック）でそれらを更新されたプランに対して評価します。修正が予算を現在のコミット済み額を下回るように削減する場合、ガバナンスエージェントは次のガバナンスチェックでこれを検出事項としてフラグを立てます。
Validation logic
ガバナンスエージェントは、各 検証カテゴリ を独立して評価します。- いずれかのカテゴリがステータス
failedを持ち、その失敗が修正可能な場合、ステータスは提案された修正を伴うconditionsです - いずれかのカテゴリがステータス
failedを持ち、その失敗が呼び出し元によって修正不可能な場合、ステータスはdeniedです - すべてのカテゴリが通過するが全体のリスクプロファイルが人間のレビューを正当化する場合、ガバナンスエージェントはレビューを内部的に処理し（タスクは非同期になる）、最終的に
approvedまたはdeniedに解決します - すべてのカテゴリが通過する場合、ステータスは
approvedです
conditions 配列は、ステータスが conditions の場合にのみ存在します。各条件は、特定のフィールド、その現在の値、提案された値、変更の理由を識別します。
Finding confidence
ガバナンスの検出事項には、確実な違反を曖昧なものから区別する任意のconfidence スコア（0-1）と uncertainty_reason が含まれます。
- 高信頼度（0.9 以上）: 検出事項は確定的です。EU ユーザーを明示的にターゲットにしたキャンペーンでの GDPR 違反。
- 中信頼度（0.6-0.9）: 検出事項は、ガバナンスエージェントが完全に解決できないコンテキストに依存します。未成年者を含む可能性のあるオーディエンスセグメント、規制管轄と部分的に重なるジオターゲティング。
- 低信頼度（0.6 未満）: 検出事項は推測的です。ガバナンスエージェントは、自律的に行動するのではなく、人間のレビューのためにフラグを立てます。
Phase inference
ガバナンスエージェントは、check_governance の tool パラメーターから検証フェーズを推論します。
フェーズコンテキストは累積的です。購入中、ガバナンスエージェントはディスカバリー中に発見されたものを考慮します。
check_governance が返す check_id は、report_plan_outcome がセラーのレスポンスを検証されたアクションにリンクするために使われます。
Capability declaration
ガバナンスエージェントは、get_adcp_capabilities でキャンペーンガバナンスのサポートを宣言します。
Integration with create_media_buy
バイヤーは create_media_buy リクエストに plan_id を、プロトコルエンベロープに governance_context を含めます。これらのフィールドは、どのガバナンスプランが適用されるかをセラーに伝え、セラー側のガバナンスチェックを可能にします。
planned_delivery — セラーが実際に実行するもの — が含まれます。
planned_delivery は、リクエストに対するセラーの解釈 — 使用する実際の配信パラメーター — です。2 つの目的を果たします。
- ガバナンスチェック — アカウントにガバナンスエージェントが設定されている場合、セラーはメディアバイを確認する前に検証のために
planned_deliveryをガバナンスエージェントに送信します。 - 透明性 — バイヤーは、配信開始前に早期に差異を捕捉するために、
planned_deliveryを要求したものと比較できます。
Governance checks
キャンペーンガバナンスのバイヤー側検証には信頼の限界があります: バイヤーのオーケストレーターが自分の宿題を採点します。LLM エージェントはガバナンス承認を幻覚したり、検証をスキップしたり、何が検証されたかを誤って表現したりする可能性があります。セラー側のガバナンスチェックは、購入が承認されていることをセラーが独立して確認する方法を与えることで、このギャップを閉じます。 被管理アクションイベントが発生すると、セラーはバイヤーが設定したガバナンスエージェント URL に POST します。ガバナンスエージェントはすべての状態を維持し、plan_id + governance_context でリクエストを相関させます — セラーはガバナンス履歴を追跡したり、呼び出し間で ID をチェーンしたりする必要はありません。
Both checks must pass
すべての被管理アクションは、バイヤー側の意図チェックとセラー側の計画配信チェックの両方に合格しなければなりません（MUST）。両方の呼び出しは同じ権威（バイヤーのガバナンスエージェント）に到達するため、「2 つのエージェントが意見を異にする」ケースはありません — しかし両方の呼び出しが成功しなければならないという不変条件は負荷を担っています。- バイヤー側の意図チェックは、プランが原則として支出を許可することを確認します。
- セラー側の計画配信チェックは、セラーの実際の配信パラメーターが承認されたプランと一致することを確認します。
denied を返す場合、アクションは進めてはなりません（MUST NOT）。両方が空でない conditions を伴って approved を返す場合、適用されるセットは両方のレスポンスの条件の和集合です。矛盾する条件（一方が X を要求し、他方が NOT X を要求する）は、黙った優先ではなく、構造化された finding を伴う denied に解決されます。
自身のコンテンツ標準や商業的理由で取引を拒否するセラーは、ガバナンス競合に参加しているわけではありません — それは別個の商取引層の拒否（例: TERMS_REJECTED）であり、通常の拒否パスに従います。ガバナンスはバイヤーのプランについてのみ語ります。
Setup
バイヤーはsync_governance を通じてガバナンスエージェントを同期し、各アカウントを呼び出すガバナンスエージェントエンドポイントとペアリングします。各エージェントには、ガバナンスエージェントがセラーの識別を検証できるよう認証情報が含まれます。
check_governance を呼び出す際に認証情報を提示します。ガバナンスエージェントは、Bearer トークンが plan_id に関連付けられたアカウントの登録済み認証情報に一致することを検証しなければならず（MUST）、認識されないまたは一致しない認証情報を持つリクエストを拒否しなければなりません（MUST）。
Governance modes
ガバナンスモード（audit、advisory、enforce）は、ガバナンスエージェントの内部実装の詳細であり、プロトコルレベルのフィールドではありません。呼び出し元はcheck_governance を送信し、approved、denied、または conditions を受け取ります — どのモードがその決定を生成したかを知る必要はありません。
これは次を意味します。
- audit モードのガバナンスエージェントは、内部的に常に検出事項を添付して
approvedを返します - advisory モードのガバナンスエージェントは、内部的に
deniedを返す場合がありますが、組織はそれを非ブロッキングとして扱います - enforce モードのガバナンスエージェントは
deniedを返し、呼び出し元が停止することを期待します
get_plan_audit_logs レスポンスにモード情報を含めてもかまいませんが（MAY）、呼び出し元はモードに基づいて動作を分岐してはなりません（MUST NOT）— 受け取ったステータスに基づいて行動します。
クロール・ウォーク・ランの採用パスについては 安全モデル を参照。
Governance context
governance_context フィールドは、check_governance レスポンスでガバナンスエージェントが発行する不透明な文字列です。任意の被管理アクションのライフサイクルを相関させ、主要な監査/レポートキーです。ガバナンスエージェントは、必要な内部状態（プラン参照、予算スナップショット、チェック履歴）をこの値にエンコードします。
呼び出し元は governance_context を解釈してはなりません（MUST NOT）。永続化して転送します。
- バイヤー:
check_governanceレスポンスからgovernance_contextを受け取り、メディアバイをセラーに送信する際にプロトコルエンベロープに添付します。 - セラー: エンベロープで
governance_contextを受け取り、メディアバイとともに保存し、そのメディアバイのライフサイクルの後続のすべてのcheck_governance呼び出しに含めます。 - ガバナンスエージェント:
governance_contextを使って各ライフサイクルイベントを元のプラン、キャンペーングルーピング、予算状態に再接続します。
check_governance 呼び出し（コンテキストが存在する前）では、ガバナンスエージェントは payload と plan_id から必要なものを抽出します。後続の呼び出しでは、governance_context が継続性を提供するため、ガバナンスエージェントはペイロードから状態を再導出する必要がありません。
ガバナンスエージェントは、governance_context をガバナンス状態のプレーンテキストエンコーディングとしてではなく、サーバー側状態へのルックアップキーまたは署名付きトークンとして扱うべきです（SHOULD）。状態が直接エンコードされる場合、中間者による改ざんが検出可能になるよう署名されなければなりません（MUST。例: HMAC）。
AdCP 3.0 では、エンコードされた値は AdCP JWS プロファイルに従って署名されたコンパクト JWS です。トークンは、証明をガバナンスエージェントが評価した正確なプラン状態にバインドする必須の plan_hash クレームを運びます（下記 Plan binding and audit を参照）。呼び出し元は依然として値を相関のために不透明として扱います。検証にオプトインするセラーは セラー検証チェックリストに従い、トークンの真正性、認可スコープ、鮮度を検証します — バイヤーのプランは検証しません。
Plan binding and audit
plan_hash クレームは、署名付き governance_context 証明を、ガバナンスエージェントが評価した正確なプラン状態に永遠にバインドする暗号学的レシートです。これは監査層プロパティです — セラーはそれを検証せず、検証することも期待されません。バイヤーのプランは、バイヤーがセラーと共有しない商業的に機密なデータ（クロスセラー配分、セラーごとの上限、目標、approved_sellers リスト、カスタムポリシー、ext）を運びます。3.x にはプラン取得メカニズムはなく、計画もされていません。plan_hash は、JWS がすでにガバナンスエージェントが生成する署名付きアーティファクトであるため JWS の内部に同行しますが、ワイヤー検証コントラクトの一部ではありません。
クレームが提供するもの:
- 事後の説明責任。 すべてのガバナンス証明は、それが証明したプラン状態に永遠にバインド可能です。規制当局とフォレンジック監査は、保持された JWS とガバナンスエージェントのリビジョン記録のみを使って、何年も後に「このトランザクションは時刻 T にプラン状態 X の下で認可された」ことを証明できます。
- ガバナンスエージェントの自己整合性。 すべての
check_governance呼び出しで、ガバナンスエージェントは現在のプラン状態を再評価し再ハッシュします。呼び出し間でガバナンスエージェントの永続化されたプランを改ざんすると、保持されたリビジョン記録に対する不一致として表面化します。 - バイヤー側のコンプライアンス検証。 バイヤー自身のツールは、そのガバナンスエージェントがバイヤーが実際にプッシュしたプランに一致するトークンを生成していることを検証できます — 侵害されたまたは不正なガバナンスベンダーを捕捉します。
Canonicalization
plan_hash = base64url_no_pad(SHA-256(JCS(plan_payload))) ここで:
JCSは RFC 8785 JSON Canonicalization Scheme — 冪等性ペイロード等価性に使われるのと同じスキームです。ガバナンスエージェントと監査人の検証者は、そこにリストされているのと同じライブラリ実装を使うべきです（SHOULD）。JCS はオブジェクトキーをコードポイントで辞書順にソートし（sync_plansリクエストでの呼び出し元のキー順はハッシュに影響しません）、省略された任意フィールドと明示的なnullの区別を保持します（これらは異なるハッシュを生成します）。ガバナンスエージェントはプランを供給されたままハッシュしなければならず（MUST）、省略された任意項目をデフォルト値に合成してはならず（MUST NOT）、明示的な null を削除してはなりません（MUST NOT）。plan_payloadはsync_plansで供給されたplans[]配列の 1 要素 です — 単一のプランオブジェクトであり、sync_plansリクエストエンベロープでもplansラッパー配列でもありません。プリイメージは証明時点での現在のプランリビジョン状態、すなわちガバナンスエージェントがちょうど評価したプランオブジェクトです。プリイメージを構築する実装は、プランリビジョンオブジェクトから開始し、下記にリストされた閉じた帳簿フィールドのセットを削除します。base64url_no_padは、末尾の=パディングを取り除いた RFC 4648 §5 に従います — JWS プロファイルのjtiや他の base64url 値と一貫しています。ガバナンスエージェントはパディングなしの形式を発行しなければなりません（MUST）。検証者（自身のトークンを再検証するガバナンスエージェント、監査人、バイヤー側コンプライアンスツール）は、両側を base64url デコードして生の 32 バイト SHA-256 ダイジェストにし、バイトを比較して比較しなければならず（MUST）— エンコードされた形式の文字列等価性ではなく — パディング、大文字小文字、アルファベットの変動が、偽の不一致を生成するのではなくデコード失敗として拒否されるようにします。正確に 32 バイトにデコードされないplan_hashは拒否しなければなりません（MUST）。
Excluded fields
閉じたリスト — ガバナンスエージェントはそれを拡張または縮小してはならず（MUST NOT）、追加はプロファイルバージョンのバンプを要求する破壊的変更で、ペイロード等価性と同じルールです。version— ガバナンスエージェントのリビジョンカウンター、各再同期でエージェントが設定status— エージェントが管理するプランライフサイクルステータスsyncedAt— 各再同期で書き込まれるタイムスタンプrevisionHistory— エージェント内部の追記のみのリビジョンログ（追記のみのアーカイブでなければならず（MUST）、実装は revisionHistory エントリをハッシュに使うアクティブなプランオブジェクト形状に読み戻してはなりません（MUST NOT））committedBudget— ダウンストリームのcheck_governance/report_plan_outcomeアクティビティから導出committedByType— 同じアクティビティから導出
sync_plans リクエストスキーマ（プランアイテムの additionalProperties: false）に現れません。ガバナンスエージェントの永続化されたプラン状態にのみ存在します。リストは、内部状態構造体を素朴にハッシュする実装者が正しいフィールドを取り除くよう、明示的に述べられています。このリストを超えて永続化されたプラン状態に追加の GA 内部フィールドを発見した実装は、プロファイルバージョンがバンプするまでそれらのフィールドをプリイメージ内として扱わなければなりません（MUST）— 除外ではなく包含へのフェイルセーフ。「帳簿のように見えるもの → 取り除く」というショートカットは、異なる推測をするすべての実装を黙って乖離させます。安全なデフォルトは「閉じたリストになければ、ハッシュの一部である」です。
他のすべてのフィールド — ext、custom_policies、objectives、delegations、human_override、および sync_plans プランアイテムスキーマで宣言されたすべてのフィールドを含む — はプリイメージ内です。呼び出し元へのガイダンス:
extはプリイメージの一部です。 バイヤーは、プラン上のext内に回転するトークンやリトライ不安定な値を置いてはなりません（MUST NOT）。再同期間で変わる値は、バイヤーの宣言された意図が変わらない場合でも、プランのすべての未処理の governance_context トークンを無効化します（冪等性のextの扱いと一貫）。delegations[].expires_atは宣言された意図であり、同じプランの再同期間で安定しているべきです（SHOULD）。すべての同期で「now + N days」から再生成すると、ハッシュのチャーンを引き起こします。- 配列順序 は
policy_ids、policy_categories、custom_policies、approved_sellers、delegations、countries、regions、channels.required、channels.allowedにおいて意味的に重要ではありませんが、JCS はそれを保持します。バイヤーはこれらを再同期間で安定した順序で発行すべきです（SHOULD）。 - JCS は Unicode 正規化しません。 RFC 8785 §3.2.5 に従い、JCS は文字列を供給されたまま保持します — 視覚的に区別できない Unicode 変種（ラテン
a対キリルа、NFC 対 NFD 合成、混同可能なホモグリフ）は異なるバイトを生成し、したがって異なるハッシュを生成します。plan_hashはこの乖離を暗号層で正しく検出しますが、プランセマンティクス層はそうではありません:policy_idsまたはpolicy_categoriesがホモグリフ置換のみで異なる 2 つのプランは、ガバナンスエージェントおよびダウンストリームコンシューマーで異なる強制結果を認可します。バイヤーとガバナンスエージェントは、policy_idsとpolicy_categoriesを発行または評価する前に、サーバー側で正規の許可リストに対して検証すべきです（SHOULD）。これはハッシュルールではなくプランコンテンツルールです —plan_hashの整合性はどちらの場合も無傷です。許可リストが、ホモグラフ置換が異なる認可決定を生成するのを防ぐものです。
Governance-agent obligations
ガバナンスエージェントは次を行わなければなりません（MUST）。- すべての
check_governance呼び出しで現在のプラン状態にわたってplan_hashを計算し、署名付き JWS ペイロードに含める。ハッシュはエージェントがちょうど評価したプランにわたってでなければなりません。変異したプランにわたる古い証明を生成してはなりません（MUST NOT）。 - すべての
check_governance呼び出しで署名をリフレッシュする — 新しいjti、iat、exp、plan_hash。ガバナンスエージェントは、プランリビジョンにまたがって以前に署名されたgovernance_contextトークンをキャッシュして再発行してはなりません（MUST NOT）。エンベロープの冪等性レスポンスキャッシュは別個のレジームです —governance_contextは、リプレイ時に回転できるよう、ペイロード等価性の閉じた除外リストに含まれています。 - 各内部プランリビジョン記録とともにリビジョンごとの
plan_hashを保持する —audit_log_pointerが公開されているかどうかに関係なく MUST。保持が永遠にバインドするプロパティを提供するものです。普遍的な保持がなければ、audit_log_pointerを使わないすべてのガバナンスエージェントは、そのトークンコーパス全体の監査層を黙って無効にします。証明されたプラン状態に結合し直せない監査ログは監査証跡の半分であり、自身の履歴トークンを検証できないガバナンスエージェントは、自身のストアの改ざんを検出できません。保持された値は実装内部で、get_plan_audit_logsの正規化されたレスポンスを通じて以外はワイヤー上で決して公開されません。それはエントリごとにplan_hashをエコーするため、監査人はガバナンスエージェントのプライベート記録から再構築する必要はありません。
Wire-verification contract
plan_hash は crit にリストされません。crit はワイヤー検証者のセマンティクス（RFC 7515 §4.1.11）です: リストされたクレームを処理できない検証者にトークンを拒否させます。plan_hash を処理するワイヤー検証者はありません — プリイメージを取得できる唯一の当事者（ガバナンスエージェント、監査人、バイヤーコンプライアンス）はオフワイヤーです。crit にリストすると、検証する根拠のないトークンをセラーに拒否させ、相殺する利益はありません。ガバナンスエージェントはクレームを発行しなければならず（MUST）、crit にリストしてはなりません（MUST NOT）。
セラーは governance_context をそのまま永続化して転送し、15 ステップの JWS 検証チェックリスト — 真正性、認可スコープ、鮮度 — を実行します。トークン内の plan_hash を不透明なカーゴとして扱い、決して検査しません。
Verification recipes
監査人レシピ。 プランの監査ログにアクセスできる規制当局やサードパーティ監査人は、次のように履歴証明を検証します。include_entries: trueを伴ってget_plan_audit_logsを呼び出して監査証跡を取得します。各checkエントリはplan_hash（発行時に主張されたクレーム）とgovernance_context（署名付き JWS）を運びます。- 各 governance_context について、コンパクト JWS をデコードし、ガバナンスエージェントの公開 JWKS に対して 15 ステップの JWS コントラクト（署名、brand.json の
iss、aud、expなど）を検証します。 - デコードされた JWS ペイロードから
plan_hashクレームを抽出し、base64url デコードして 32 生バイトにします。 - エントリレベルの
plan_hashを 32 生バイトにデコードし、クレームとバイト比較します。不一致は、保持された監査記録が署名付きトークンと矛盾することを意味します — トークンが改ざんされたか記録が改ざんされたかのいずれかで、ガバナンスエージェントの整合性が疑われます。 - 任意: ガバナンスエージェントの保持されたリビジョンごとのプラン記録から
plan_hashを再計算し（監査人がガバナンスエージェントのリビジョンストアへの認証済みアクセスを持つ場合）、再度バイト比較します。ここでの不一致は、署名と監査の間にガバナンスエージェント自身のストアが改ざんされたことを意味します。
- プロトコルエンベロープを通じてセラーに流れる
governance_contextトークンを観察します（バイヤーはすでにこれらを持っています。取得不要）。 - 各トークンについて、JWS をデコードし、
plan_hashクレームを抽出し、base64url デコードして 32 バイトにします。 - トークンが証明するリビジョンでのバイヤー自身のプランのコピーにわたって
plan_hashを再計算します。バイヤーは自身のsync_plans呼び出しから権威あるプラン状態を持っています。 - バイト比較します。不一致は、ガバナンスエージェントがバイヤーが実際にプッシュしたプランに一致しない証明に署名していることを意味します — ベンダーの侵害またはバグのいずれかです。どちらもバイヤーがエスカレーションすべき重大な検出事項です。
plan_hash ダイジェストを比較する際に定数時間バイト比較（例: Node の crypto.timingSafeEqual、Python の hmac.compare_digest、Go の crypto/subtle.ConstantTimeCompare）を使うべきです（SHOULD）。SHA-256 長の比較でのタイミングサイドチャネルは今日実際には悪用可能ではありません。ルールは、より短いダイジェストで比較コードを再利用する将来のデプロイや、検証者ホスト上でのコテナンシーを持つ攻撃者に対する安価な保険です。
Privacy considerations
再同期にわたるplan_hash の変化は、何が変異したかを明かさなくても、プランが変異したことを明かします。トークンを長期保持する当事者（governance_context をそのまま転送するセラー、監査人、規制当局）は、特定の plan_id について観察する別個のハッシュのシーケンスから、プランの変異ケイデンスを推論できます。ほとんどのデプロイでこれは許容可能または望ましいものです — 変異ケイデンスは監査シグナルの一部です。変異頻度自体が商業的または運用的に機密である機密ガバナンスデプロイ（例: バイヤーがセラーにキャンペーンポートフォリオ全体の再プランケイデンスを推論されたくない）は、これをトークン保持ポリシーに織り込むべきです（SHOULD）: governance_context のより短いセラー側保持ウィンドウ、またはクロストークンのリンク可能性を断つためのプランの jti 名前空間の定期的な回転。
Reference test vectors
static/compliance/source/test-vectors/plan-hash/ の 11 個のベクターが、正規化をビット単位で正確にピン留めします: 最小限のプラン、すべての任意フィールドを行使するプラン、帳簿を取り除いたケース（GA 内部フィールドが保存されたプランに存在するがハッシュ前に取り除かれ、帳簿なしの等価物と同じハッシュを生成する）、省略対明示 null、policy_categories の配列順序、回転する ext.trace_id がすべて別個のハッシュを生成することを証明するペアベクター、JCS が RFC 8785 §3.2.5 に従い正規化しないことを確認する Unicode ケース、および手作りの JSON.stringify + key sort ではなくライブラリの選択をピン留めする小数パーセンテージ付きの数値正規化ケース。各ベクターは、プリイメージ、正規の JCS バイト、SHA-256 16 進ダイジェスト、最終的な plan_hash クレーム値を記録します。ガバナンスエージェントと監査人の検証者は、これらのハッシュをビット単位で正確に再現しなければなりません（MUST）。
Governance phases
ガバナンスチェックは、3 つのフェーズを通じてメディアバイのライフサイクル全体をカバーします。phase フィールドは省略された場合 purchase にデフォルトするため、既存の実装は変更なしに動作し続けます。
ガバナンスエージェントはすべての状態を維持し、plan_id + governance_context でリクエストを相関させます。セラーはチェック ID をチェーンしたり会話履歴を追跡したりしません — 何が起きたかをポストし、ガバナンスエージェントがコンテキストをルックアップします。
Purchase phase
セラーがgovernance_agents を持つアカウントで create_media_buy リクエストを受け取ったとき:
- セラーはリクエストを解釈し、その
planned_deliveryを決定します。 - セラーは
phase: "purchase"、plan_id、planned_deliveryを伴ってcheck_governanceを呼び出します。 - ガバナンスエージェントは計画された配信をキャンペーンプランに対して検証します。
approvedなら、セラーはメディアバイを確認します。deniedなら、セラーはGOVERNANCE_DENIEDエラーでメディアバイを拒否します。conditionsなら、セラーは条件を満たすように計画された配信を調整して再検証するか、拒否します。
Modification phase
セラーがupdate_media_buy リクエストを受け取ったとき:
- セラーは更新を解釈し、新しい
planned_deliveryを決定します。 - セラーは
phase: "modification"、更新されたplanned_delivery、modification_summaryを伴ってcheck_governanceを呼び出します。 - ガバナンスエージェントは
plan_id+governance_contextで被管理アクションをルックアップし、変更をプランに対して評価します。 approvedなら、セラーは更新を確認します。deniedまたはconditionsなら、セラーは購入フェーズと同じフローに従います。
reallocation_threshold 内の小さな予算増加は自動承認され、一方で大きな予算増加や新しいジオ市場はより厳格な精査を必要とするかもしれません。
Delivery phase
セラーは、アクティブな配信中に定期的にphase: "delivery" を伴って check_governance を呼び出します。これにより、セラーとバイヤーのガバナンスエージェントの間に直接のレポートチャネルが作られます。
- セラーはレポート期間の配信メトリクスを収集します。
- セラーは
phase: "delivery"、現在のplanned_delivery、delivery_metricsを伴ってcheck_governanceを呼び出します。 approvedなら、レスポンスにはnext_check— セラーが次にレポートすべき時 — が含まれます。deniedなら、セラーは直ちに配信を一時停止します。conditionsなら、セラーは配信を調整し（例: ペーシングを遅くする、ジオターゲティングをシフトする）、直ちに再検証します。
next_check を含めることで配信レポートにオプトインします。購入レスポンスに next_check がない場合、ガバナンスエージェントは配信レポートを期待しません。
ガバナンスエージェントは next_check を通じてレポートケイデンスを制御します。ドリフトや条件を検出したときにケイデンスを締め（より短い間隔）、配信が安定しているときに緩める（より長い間隔）ことができます。ガバナンスエージェントは、見逃した next_check の期限を次の配信チェックでの検出事項として扱ってもかまいません（MAY）。
Verification examples
購入リクエスト:next_check フィールドは、ガバナンスエージェントが配信レポートを期待していることを示します。存在しない場合、配信レポートは期待されません。
拒否（購入）:
Enforcement
アカウントにgovernance_agents が存在する場合、セラーは任意のメディアバイを確認する前に check_governance を呼び出さなければなりません（MUST）。バイヤーは、購入が独立して検証されるように特にエンドポイントを提供しました — それをスキップすることは目的を無に帰します。
governance_agents が存在しない場合、セラーはメディアバイリクエストを通常どおり処理します。バイヤー側のガバナンスループ（意図チェック → 実行 → report_plan_outcome）は依然として適用されますが、セラー側の検証はありません。
セラーは、すべてのアカウントの前提条件としてガバナンスチェックを要求してはなりません（MUST NOT）。governance_agents のないアカウントからのメディアバイの処理を拒否するセラーは、キャンペーンガバナンスを使わないバイヤーとの相互運用性を壊します。
purchase フェーズのガバナンスが使われる場合でも、delivery フェーズは任意です。セラーは、継続的な配信レポートなしに購入承認をサポートしてもかまいません（MAY）。ガバナンスエージェントは、購入レスポンスに next_check が存在することを通じて、配信レポートを期待するかどうかを示します。
ガバナンスエージェントに到達できない場合（タイムアウト、ネットワークエラー）、セラーはメディアバイを進めてはなりません（MUST NOT）。ガバナンスチェックは、登録済み governance_agents を持つアカウントでの購入確認の前提条件です。セラーは短い遅延の後にチェックを再試行すべきで（SHOULD）、エージェントが到達不能なままなら GOVERNANCE_UNAVAILABLE エラーでメディアバイを拒否すべきです。
オーケストレーターがセラーから GOVERNANCE_UNAVAILABLE を受け取ったとき、遅延の後に create_media_buy を再試行すべきです（SHOULD）。ガバナンスエージェントが利用不可のままなら、オーケストレーターは代替セラーを試みるのではなく人間にエスカレーションすべきです（SHOULD）— ガバナンス障害は同じアカウント上のすべてのセラーに影響します。オーケストレーターからの以前の意図チェック承認は、セラーの実行チェックの代替にはなりません。セラーは独立して検証し、オーケストレーターの承認を使えません。
Performance expectations
ガバナンスエージェントの実装は、意図チェックについては 5 秒以内、実行チェックについては 10 秒以内にcheck_governance 呼び出しに応答すべきです（SHOULD）。セラーは適切なタイムアウトを設定し、タイムアウトを利用不可と同じように扱うべきです（再試行し、その後 GOVERNANCE_UNAVAILABLE で拒否）。
Wire format
セラーは、MCP over HTTP（Streamable HTTP トランスポート）を使って、登録された URL で各ガバナンスエージェントを呼び出します。リクエストは、ツール名check_governance とツール入力としてのリクエスト引数を持つ MCP tools/call 呼び出しです。認証は、Authorization ヘッダーのエージェントの authentication.credentials からの Bearer トークンを使います。
One governance agent per account
アカウントは、sync_governance ごとに正確に 1 つのガバナンスエージェントにバインドされます。登録はスキーマによって単一エージェントです — governance_agents は 3.0 が出荷したものであるため配列ですが、負荷を担う不変条件として maxItems: 1 に制約されています（緩和に向けた段階ではありません）。エンベロープは単一の governance_context トークンを運びます。すべてのライフサイクル呼び出しはその 1 つのエージェントにルーティングされます。上限を緩めるには、sync_governance、プロトコルエンベロープ、トークンをスレッドするすべてのライフサイクルタスクにまたがる協調的な変更が必要です — その変更は計画されていません。
これは意図的です。ガバナンスプランは単一的です — 予算権限、配信監視、ブランドセーフティ、規制コンプライアンスは、異なる権威が持つ独立した専門分野ではありません。それらは同じプラン状態に対する同じ評価のフェーズとファセットです。
- 認可、忠実性、ドリフトは専門分野ではなくフェーズです。
check_governanceはすでにそれらをphase軸（purchase/modification/delivery）で分離しています。それらをエージェント間で分割すると、同じプラン状態を別個の権威に分割することになり、ドリフト、不一致、または同じプランの重複した再読み取りしか生成できません。 - 規制ルールはプランにエンコードされ、別個のエージェントが保持しません。
enforced_policies、restricted_attributes、policy_ids、human_review_requiredはプラン自体に存在します。「支出権限」エージェントとは別の「規制コンプライアンス」エージェントは、同じプランを再評価して同じ決定に達するか、乖離します — どちらも有用ではありません。 - 内部の専門家レビューはガバナンスエージェントの内部に属します。 法務、ブランドセーフティ、カテゴリ専門家のレビューを望むバイヤーは、それらのレビュアーを単一のガバナンスエージェントエンドポイントの背後で構成します（人間レビュー、内部ルーティング、複数レビュアーの合意はすべてガバナンスエージェント内部の関心事）。プロトコルは 1 つのエージェントを見ます。エージェントの内部組織はエージェントの問題です。
- 1 つのライフサイクル、1 つのトークン、1 つの監査証跡。 プランバインディング（
plan_hash）、署名付きコンテキスト（governance_context）、get_plan_audit_logsはすべて単一エージェント設計です。単一エージェントが、事後の説明責任（「このトランザクションは時刻 T にエージェント Y によってプラン状態 X の下で認可された」）をクリーンで検証可能なクレームにするものです。
check-governance-response.findings[] を通じて監査可能です。各検出事項は category_id（エージェント内部のタクソノミー — ファーマ MLR、ブランドセーフティ、法務コンプライアンス、どの専門分野がフラグを立てたか）と policy_id（検出事項をトリガーした特定のポリシー）を運びます。バイヤーとセラーは 1 つの統合された決定を見ます。検出事項ごとの帰属により、読者は、分割を別個のプロトコルレベルエージェントとして表面化させることなく、ガバナンスエージェント内のどの専門家が拒否や条件に寄与したかを追跡できます。
違反が、プロデューサーがタグ付けしたサーフェス — バイヤーが作成した feature_requirements[i].policy_id、クリエイティブエージェントが記録した creative-feature-result.policy_id、またはプロパティリストエージェントが発行した validation-result.features[i].policy_id — に遡る場合、ガバナンスエージェントはエンドツーエンドのトレーサビリティのためにその policy_id を検出事項にエコーします。プロデューサーコントラクトについては ポリシー帰属 を参照。
キャンペーンガバナンスの内部ではなく隣接する関連する専門家レビュー — クリエイティブのブランドセーフティ事前スクリーン、プロパティリストポリシー、コンテンツ標準評価 — は、独自のエージェントと独自のライフサイクルを持つ別個のガバナンスサーフェスです（build_creative、プロパティガバナンス、コンテンツ標準ガバナンスを参照）。キャンペーンガバナンスはプランについてのみ語ります。
Governance checks and the governance loop
ガバナンスチェックはバイヤー側のガバナンスループを補完します。置き換えません。delivery フェーズは、セラーが実際に配信しているものへのリアルタイムの可視性をガバナンスエージェントに与えます。バイヤー側の report_plan_outcome はオーケストレーターの正直なレポートに依存します。delivery フェーズはセラーから直接レポートを得ます。
バイヤー側とセラー側のガバナンスチェックは同じエージェント — sync_governance を通じてアカウントに登録されたもの — に到達します。オーケストレーターは意図チェックのためにそれを呼び出し、セラーは実行チェックのためにそれを呼び出します。両方の会話が同じプラン状態を持つ同じ権威に到達します。
Orchestrator integration pattern
ガバナンスチェックは、オーケストレーターのアクションループにおける同期呼び出しです。オーケストレーターは、セラーにリクエストを送信する前にtool + payload（意図チェック）を伴って check_governance を呼び出します。セラー側の実行チェックはオーケストレーターに対して透過的です — オーケストレーターは、ガバナンスチェックが設定されているかどうかに関係なく同じ create_media_buy リクエストを送信します。修正と配信フェーズのチェックは、オーケストレーターのガバナンスループとは独立に、セラーとガバナンスエージェントの間で発生します。
Audit trail
すべてのプランは、get_plan_audit_logs を通じて取得可能な、すべての検証されたアクションとレポートされた結果の順序付き監査証跡を維持します。証跡には次が含まれます。
- チェック ID、タイムスタンプ、ツール
- ステータスとカテゴリ評価
- 結果ステータスとコミット済み予算
- 結果レポートからの検出事項
- 内部エスカレーションとその解決（ガバナンスエージェントが記録）
- 人間の承認者の識別（人間レビューが内部的に発生した場合）
- 時間経過に伴う配信メトリクス
Conformance testing
ガバナンスエージェント実装のための適合性テストスイートが計画されています。テストベクターは構造化された入出力ペア — プラン、ポリシーのセット、check_governance リクエスト、期待されるレスポンスステータスと検出事項 — を提供します。ガバナンスエージェントはこれらのベクターを実行して、ポリシー評価が一貫した結果を生成することを検証できます。
ポリシーレジストリの exemplar（ポリシーごとの合否シナリオ）が原材料を提供します。テストベクターはこれらを、任意のガバナンスエージェントが検証できる実行可能なアサーションに形式化します。AdCP クライアントテストライブラリは、標準テストスイートの一部としてこれらのベクターを含めます。