check_governance
実験的機能。 キャンペーンガバナンス（
sync_plans、check_governance、report_plan_outcome、get_plan_audit_logs）は、実験的サーフェスとして AdCP 3.0 の一部です — 少なくとも 6 週間の予告をもって 3.x リリース間で変更される可能性があります。これを実装するセラーは experimental_features で governance.campaign を宣言しなければなりません（MUST）。完全なコントラクトについては 実験的ステータス を参照。
ガバナンスエージェントがすべての状態を維持します。呼び出し元はチェック ID をチェーンしたり会話履歴を追跡したりしません — アクションをポストし、ガバナンスエージェントが
plan_id で相関させます。後続のライフサイクルチェックでは、呼び出し元は継続性のために前のレスポンスの governance_context を含めます。
アカウントは1つのガバナンスエージェントにバインドされます（sync_governance と アカウントごとに1つのガバナンスエージェント を参照）。被管理アクションのすべてのライフサイクル呼び出しは、その同じエージェントに送られます。
チェックタイプ
意図チェック（オーケストレーター）
オーケストレーターは、セラーにツール呼び出しを送信する前に、tool と payload を伴って check_governance を呼び出します。ガバナンスエージェントは意図したアクションをキャンペーンプランに照らして評価します。
- オーケストレーターがセラーツール（例:
create_media_buy）を呼び出すことを決定する - オーケストレーターがツール名と完全なペイロードを伴って
check_governanceを呼び出す approvedなら、オーケストレーターはツール呼び出しをセラーに送信するdeniedなら、オーケストレーターはツール呼び出しを送信しないconditionsなら、オーケストレーターはペイロードを調整してcheck_governanceを再呼び出しする- ガバナンスエージェントが人間のレビューを必要とする場合、タスクは非同期になり、最終的に
approvedまたはdeniedに解決する
実行チェック（セラー）
セラーは、ガバナンスエージェントが設定された（sync_governance で設定）アカウントでリクエストを処理する際に、governance_context と planned_delivery を伴って check_governance を呼び出します。実行チェックは常に拘束的です — ガバナンスエージェントが拒否した場合、セラーは進めてはなりません。
チェックを実行する前に、セラーはバイヤーからプロトコルエンベロープに到着した署名付き governance_context トークンを検証します。バイヤーは意図フェーズのトークンを生成します（JWS プロファイルに従う）。セラー自身の実行チェックは、ライフサイクルの残りについて、割り当てられた media_buy_id にバインドされた purchase/modification/delivery フェーズのトークンを生成します。
セラーは、コミット済みガバナンスチェックを段階的に採用できます。
- レベル 1: 購入のみ —
create_media_buyごとに 1 回の呼び出し。最小限の実行可能な統合。 - レベル 2: + 変更 —
update_media_buyごとに 1 回の呼び出し。 - レベル 3: + 配信レポート — アクティブな配信中の定期的な呼び出し。
呼び出し要件
プランにガバナンスエージェントが設定されている場合、バイヤーエージェントはすべての支出コミットリクエスト（create_media_buy、update_media_buy、acquire_rights、update_rights、activate_signal、build_creative）の前に check_governance を呼び出さなければなりません（MUST）— 例外なく。ドル下限も、異常しきい値も、コールドスタート免除もありません。すべてのコミットがガバナンスエージェントを通ります。バイヤー側の呼び出しは意図チェック（tool + payload）であり、バイヤーがセラーへのリクエストに添付する意図フェーズの governance_context トークンを生成します。ガバナンスエージェントは、プランの budget.reallocation_threshold と human_review_required フィールドに従って、自動承認、条件適用、拒否、または人間のレビューへのエスカレーションを内部的に決定します。
セラー側の強制が、署名付き governance_context トークンを通じて MUST を実効化します。ガバナンスエージェントが設定されたプランの支出コミットを受け取ったセラーは、有効で期限内の意図フェーズトークン（phase: "intent"、sub がプラン ID に等しい、aud がこのセラー宛て）を要求しなければならず（MUST）、そうでなければ PERMISSION_DENIED で拒否しなければなりません（MUST）。次にセラーは自身の実行チェックを実行します — planned_delivery と受け取った governance_context を伴って check_governance を呼び出す — これがライフサイクルの残りについて、新たに割り当てられた media_buy_id にバインドされた purchase フェーズのトークンを生成します。意図チェックをスキップするバイヤーは有効な意図トークンを生成できないため、コミットはセラーが実行チェックに到達する前に拒否されます。
プランにガバナンスエージェントが設定されていない場合、check_governance の呼び出しは必須でも意味もありません — 呼び出す対象がありません。セラーは、独自の商業ポリシーの問題として、ガバナンスエージェントが設定されていないプランでの取引を拒否してもかまいません（MAY）。
完全な定義（監査要件、セラー側の保持 MUST、冪等性との相互作用を含む）については 仕様 を参照。
ステータス値
期限切れ
expires_at は verdict が approved または conditions の場合に存在します。失効した承認は承認ではありません — 呼び出し元は進める前に check_governance を再呼び出ししなければなりません。
条件
verdict が conditions の場合、呼び出し元は進める前に調整したパラメーターで check_governance を再呼び出ししなければなりません（MUST）。required_value を持つ条件は機械処理可能です — 呼び出し元はプログラム的に値を適用できます。required_value のない条件はアドバイザリです — 呼び出し元は reason を解釈してそれに応じて調整すべきです。
ガバナンスエージェントは、同じアクションに対する 3 回の失敗した再呼び出しの後、（conditions ではなく）denied を返すべきです（SHOULD）。これは無限の交渉ループを防ぎます。特に、セラーがキャンペーンプランを見えないセラー側チェックで有効です。
人間によるレビュー
ガバナンスエージェントが人間のレビューが必要と判断した場合（例: アクションがプランのreallocation_threshold を超える、またはプランが human_review_required: true を運ぶ）、エージェントは内部的にエスカレーションを処理します。check_governance タスクは非同期になります — 呼び出し元は標準の非同期タスクライフサイクルステータス（submitted、working）を受け取り、人間が行動すると最終的に approved または denied を得ます。呼び出し元は、非同期タスクをサポートすること以外に、このケースの特別な処理を必要としません（タスクライフサイクルを参照）。
committed チェック（セラー側）では、セラーがタイムアウトを設定します。ガバナンスエージェントがタイムアウト内に応答しない場合、セラーはそれを denied として扱い、オーケストレーターにエラーを返します。オーケストレーターは、ガバナンスエージェントが解決した後にメディアバイを再開始できます。
結果とのリンク
レスポンスにはcheck_id が含まれます。これを report_plan_outcome で使い、結果をそれを認可したガバナンスチェックにリンクします。
ガバナンスエージェントが利用不可の場合
ガバナンスエージェントが設定されていて、呼び出し元がそれに到達できない場合（タイムアウト、ネットワークエラー）、呼び出し元は進めてはなりません（MUST NOT）。ガバナンスはゲートです — ゲートに到達できないとき、デフォルトは停止です。呼び出し元はバックオフを伴って再試行し、失敗を上流にレポートすべきです（SHOULD）。配信ケイデンス
レスポンスにnext_check が存在することは、ガバナンスエージェントが継続的な配信レポートを期待しているというシグナルです。セラーは next_check の時刻までに呼び出すべきです（SHOULD）。ガバナンスエージェントは、期限の見逃しを次の配信チェックでの検出事項として扱ってもかまいません（MAY）。
リクエスト
意図チェック（オーケストレーターがセラーに送信する前にチェック）
check_governance 呼び出しで、ガバナンスエージェントは payload から必要なものを抽出します。レスポンスには、呼び出し元がプロトコルエンベロープに添付し、この被管理アクションの後続のすべてのガバナンス呼び出しに含める governance_context 文字列が含まれます。3.0 では、ガバナンスエージェントは、セラーが真正性、認可スコープ、鮮度（15 ステップのセラーチェックリスト）を検証できるよう、AdCP JWS プロファイルに従って署名されたコンパクト JWS を発行しなければなりません（MUST）。トークンは必須の plan_hash 監査層クレームも運びます — 正規化ルール、保持義務、およびガバナンスエージェントの実装者が出荷前に検証すべき 11 個の参照ベクターについては プランバインディングと監査 を参照。
意図チェック（権利ライセンス）
実行チェック — purchase
実行チェック — modification
実行チェック — delivery
レスポンス
approved（意図チェック）
expires_at の前に create_media_buy をセラーに送信します。
approved（実行チェック — 配信オプトイン付き purchase）
next_check の存在は、ガバナンスエージェントがその時刻から配信レポートを期待していることを示します。
approved（実行チェック — delivery）
next_check にスケジュールします。
denied（意図チェック）
denied（実行チェック — delivery ジオドリフト）
conditions（実行チェック — purchase）
check_governance を再呼び出ししなければなりません（MUST）。
conditions（実行チェック — delivery オーバーペーシング）
check_governance を再呼び出ししなければなりません（MUST）。next_check は、ガバナンスエージェントが修正を検証できるよう通常より近くに設定されます。
フィールド
リクエスト
配信メトリクス
レスポンス
エラーコード
関連タスク
sync_plans— このガバナンスチェックが照合するプランreport_plan_outcome— アクションが確認された後に何が起きたかをレポートget_plan_audit_logs— プラン状態と監査証跡を表示