> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# Specification

> AdCP キャンペーンガバナンスの正式仕様 — プランスキーマ、予算権限モデル、検証ロジック、統合パターン。

# Campaign Governance specification

<Note>
  **実験的機能。** キャンペーンガバナンスは、実験的サーフェスとして AdCP 3.0 の一部です — 少なくとも 6 週間の予告をもって 3.x リリース間で変更される可能性があります。これを実装するセラーは `experimental_features` で `governance.campaign` を宣言しなければなりません（MUST）。完全なコントラクトについては [実験的ステータス](/docs/reference/experimental-status) を参照。
</Note>

**Status**: Request for Comments
**Last Updated**: March 2026

本ドキュメント内のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL" は、[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) に記載のとおりに解釈されます。

本ドキュメントは、キャンペーンガバナンスのデータモデル、検証ロジック、統合パターンを定義します。

## Campaign plan

キャンペーンプランは、すべての検証における真実の源泉です。プランは [`sync_plans`](/docs/governance/campaign/tasks/sync_plans) を通じてガバナンスエージェントにプッシュされ、キャンペーンのプランパラメーター — 予算制限、チャンネル、フライト日程、プラン市場 — を定義します。ガバナンスエージェントはブランドのコンプライアンス設定から適用可能なポリシーを解決します。プランは `policy_ids` でレジストリポリシーを直接参照したり、`custom_policies` でキャンペーン固有のルールを含めたりすることもできます。

```json theme={null}
{
  "plan_id": "plan_q1_2026_launch",
  "brand": {
    "domain": "acmecorp.com"
  },
  "objectives": "Drive awareness for spring product launch among 25-54 adults in the US, focusing on premium video and high-impact display.",
  "budget": {
    "total": 500000,
    "currency": "USD",
    "reallocation_threshold": 25000,
    "per_seller_max_pct": 40
  },
  "channels": {
    "required": ["olv"],
    "allowed": ["olv", "display", "ctv", "audio"],
    "mix_targets": {
      "olv": { "min_pct": 40, "max_pct": 70 },
      "display": { "min_pct": 10, "max_pct": 30 },
      "ctv": { "min_pct": 0, "max_pct": 20 },
      "audio": { "min_pct": 0, "max_pct": 10 }
    }
  },
  "flight": {
    "start": "2026-03-15T00:00:00Z",
    "end": "2026-06-15T00:00:00Z"
  },
  "countries": ["US"],
  "policy_ids": ["us_coppa", "alcohol_advertising"],
  "custom_policies": [
    {
      "policy_id": "no_competitor_adjacency",
      "enforcement": "must",
      "policy": "No advertising adjacent to competitor brand content."
    }
  ],
  "approved_sellers": null,
  "ext": {}
}
```

### Purchase types

ガバナンスプランは、メディアバイだけでなくすべての金銭的コミットメントを管理します。`check_governance` の `purchase_type` フィールドが、どの種類のコミットメントが検証されているかを識別します。

| Purchase type       | Tool                                  | What's governed |
| ------------------- | ------------------------------------- | --------------- |
| `media_buy`（デフォルト）  | `create_media_buy`、`update_media_buy` | メディアインベントリの購入   |
| `rights_license`    | `acquire_rights`、`update_rights`      | ブランド権利ライセンス料    |
| `signal_activation` | `activate_signal`                     | データシグナル有効化料     |
| `creative_services` | `build_creative`                      | クリエイティブ生成料      |

すべての購入タイプは同じガバナンスループを共有します: `sync_plans` → `check_governance` → 実行 → `report_plan_outcome`。ガバナンスエージェントは、すべてのタイプにわたって予算権限、ジオコンプライアンス、フライトコンプライアンスを検証します。メディアバイ固有の検証（チャンネルコンプライアンス、セラー集中度、配信ペーシング）は、`purchase_type` が `media_buy` の場合、またはペイロードが関連フィールドを含む場合にのみ適用されます。

`purchase_type` が省略された場合、ガバナンスエージェントは `media_buy` を想定します。

<Note>
  **将来の購入タイプ**: コンテンツ標準、プロパティリストのキュレーション、測定/検証サービス（ブランドリフト調査、ビューアビリティ、フラウド検出）はすべて、スキーマに `pricing_options` を運び、`report_usage` を通じて課金します。これらのサービスは現在、バイヤーがサービスにコミットする明示的な有効化ツールを欠いています — 課金関係は暗黙的です。プロトコルがこれらのサービスの有効化サーフェスを追加する際、コミットメント時点でのガバナンスチェックを可能にするために、対応する購入タイプが追加されます。
</Note>

### Budget reallocation

`budget.reallocation_threshold`（必須の数値）は、予算再配分の自律性を管理します。これは、データ主体に影響する決定の必須の人間によるレビューをカバーしません — それについてはプランレベルの `human_review_required` フィールドを参照。

| Value                        | Meaning                                                   |
| ---------------------------- | --------------------------------------------------------- |
| `0`                          | すべての再配分に人間の承認が必要                                          |
| `budget.total` 未満の正の数        | エージェントはこの金額までエスカレーションなしに再配分できる。より大きい変更は人間のレビューにエスカレーションする |
| `budget.total` に等しい（またはそれ以上） | エージェントはプランの総予算内で自由に再配分できる                                 |

### Budget allocations

プランは任意で、`allocations` を使って総予算を購入タイプ間で分割できます。

```json theme={null}
{
  "budget": {
    "total": 500000,
    "currency": "USD",
    "reallocation_threshold": 25000,
    "allocations": {
      "media_buy": { "amount": 400000 },
      "rights_license": { "amount": 75000 },
      "signal_activation": { "amount": 25000 }
    }
  }
}
```

`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` とは異なります。

| Field                           | Scope | Purpose                                                   |
| ------------------------------- | ----- | --------------------------------------------------------- |
| `budget.reallocation_threshold` | 運用面   | プラン内での予算再配分に対するエージェントの自律性を制御                              |
| `human_review_required`         | 規制面   | 個人に影響する決定（例: GDPR 第22条、EU AI Act 附属書 III）の人間によるレビューを義務付ける |

呼び出し元は、トリガーとなるポリシーが存在しない場合でも、プラン上で `human_review_required: true` を明示的に設定してもかまいません（MAY）。呼び出し元は、人間のレビューを要求するポリシーをオーバーライドするために `false` に設定してはなりません（MUST NOT）— ガバナンスエージェントはすべての同期でこのフラグを解決されたポリシーから再評価し、トリガーとなるポリシーが存在する場合、呼び出し元が提供した `false` をオーバーライドします。

### Spend-commit invocation

バイヤー側のガバナンス呼び出しは、アドバイザリではなく強制可能です。プランにガバナンスエージェントが設定されている場合、バイヤーエージェントは、セラーに支出コミットリクエストを送信する前に [`check_governance`](/docs/governance/campaign/tasks/check_governance) を呼び出さなければならず（MUST）— 例外なく — そのリクエストに添付する**意図フェーズ**の `governance_context` トークンを生成します。ガバナンスエージェントは、プランの `budget.reallocation_threshold` と `human_review_required` フィールドに従って、自動承認、条件適用、拒否、または人間のレビューへのエスカレーションを内部的に決定します。呼び出しルールにドル金額、ベースライン計算、オペレーター宣言の下限は現れません — それらの自動承認の高速パスは、呼び出すかどうかというバイヤーの決定ではなく、ガバナンスエージェント自身のポリシーの内部に属します。

#### Spend-commit tasks

呼び出しの MUST は、リクエストの時点で金銭的義務を付与するすべての AdCP タスクに適用されます。

* [`create_media_buy`](/docs/media-buy/task-reference/create_media_buy) — パッケージ全体のコミット済み予算
* [`update_media_buy`](/docs/media-buy/task-reference/update_media_buy) — 増分コミットデルタ（新予算 − 以前にコミットされた額）
* [`acquire_rights`](/docs/brand-protocol/tasks/acquire_rights) — 権利価格
* [`update_rights`](/docs/brand-protocol/tasks/update_rights) — 増分コミットデルタ
* [`activate_signal`](/docs/signals/tasks/activate_signal) — 有効化料
* [`build_creative`](/docs/creative/task-reference/build_creative) — クリエイティブ生成料
* 将来の支出コミットタスク

呼び出しは、ディスカバリータスク（例: `get_products`、`get_signals`）、レポートタスク（例: `get_media_buy_delivery`）、または運用ステータスタスクには必須ではありません。MUST は金銭的義務の時点で特に発火します。

プランにガバナンスエージェントが設定されていない場合、`check_governance` の呼び出しは必須でも意味もありません — 呼び出す対象がありません。セラーは、独自の商業ポリシーの問題として、ガバナンスエージェントが設定されていないプランでの取引を拒否してもかまいません（MAY。エンタープライズセラーは通常拒否します）。プロトコルはガバナンスエージェントを義務付けず、ブランドが公開する設定が、セラーが 1 つ存在するかどうかを発見する手段です。

同じプランを複数のセラーにファンアウトするオーケストレーターは、`aud` がターゲットセラーにバイト単位でバインドされるため、セラーごとに 1 つの意図トークンを生成します。これは正しいプロトコル形状ですが、ガバナンスエージェントがプラン上のバイヤーの完全な買い物リストを見ることを意味します。買い物の意図を商業的に機密と見なすオペレーターは、データ処理の姿勢を信頼できるガバナンスエージェントを選ぶべきです（SHOULD）。

#### Seller enforcement

ガバナンスエージェントが設定されたプランの支出コミットリクエストを受け取ったセラーは、リクエスト上で有効で期限内の**意図フェーズ**の `governance_context` トークンを要求しなければならず（MUST）、[セラー検証チェックリスト](/docs/building/by-layer/L1/security#セラー検証チェックリスト)に従って検証します。トークンは `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`](/docs/governance/campaign/tasks/get_plan_audit_logs) を通じて取得可能な監査ログエントリを生成しなければならず（MUST）、次を捕捉します。

1. タイムゾーンオフセット付き ISO 8601 文字列としての呼び出しタイムスタンプ
2. 検証されるツール（`create_media_buy`、`acquire_rights` など）とプランの通貨でのコミット額
3. 結果（`approved`、`denied`、`conditions`。および人間のレビューが内部的に呼び出されたかどうか）
4. 人間のシグナルが記録された場合の人間のアクターの識別と権限
5. ダウンストリームの支出コミットタスクの監査エントリおよび `report_plan_outcome` からのクロスリファレンス用の `check_id`

バイヤー側の意図チェックとセラー側の実行チェックはそれぞれ別個の `check_id` を生成します。`report_plan_outcome` は単一のチェック識別子ではなく `plan_id` を通じて相関させます。支出コミットを再構築する監査人は、バイヤー側エントリ、セラー側エントリ、セラーが永続化したトークン記録を照合します。

#### Interaction with idempotency

* **以前の意図フェーズ `governance_context` を運ぶ同一ペイロードのリトライ:** 再呼び出しなし。キャッシュされたガバナンスレスポンスが再利用されます。トークンの署名と鮮度が再検証されます。セラー側のリプレイ重複排除キー（[検証チェックリスト](/docs/building/by-layer/L1/security#セラー検証チェックリスト)を参照）は、同じ `idempotency_key` を運ぶ繰り返された `jti` を、リプレイ攻撃ではなく正当なリトライとして扱わなければなりません（MUST）— これが唯一の狭い適用除外です。
* **異なるペイロードでの再プラン（[冪等性](/docs/building/by-layer/L1/security#冪等性)に従う新しい `idempotency_key`）:** 新しい `check_governance` 呼び出しが必要です。新しい `governance_context` トークンが発行されます。

人間の承認後のリトライはガバナンスを再呼び出ししません。既存のトークンは期限切れになるまで認可のままです。実行後のライフサイクルリトライは、セラーの `purchase` フェーズトークンに対して動作します。これは、バイヤーの意図チェックではなく、セラーの実行チェックによって管理される別個のアーティファクトです。

### Channel mix targets

`mix_targets` フィールドは、許容される配分範囲を定義します。ガバナンスエージェントは、すべてのメディアバイにわたる集計支出がこれらの範囲内に収まることを検証します。ビデオ支出を総予算の 70% 超に押し上げる `create_media_buy` は、`conditions` または `denied` のステータスをトリガーします。

### Delegations

プランは、どのエージェントがプランに対して実行を認可されているか、どのような制約でかを指定する `delegations` 配列を含めることができます。これにより、ブランドとエージェンシー間の委任関係がプロトコル内で明示的になります。

```json theme={null}
{
  "plan_id": "plan_q1_2026_launch",
  "brand": { "domain": "acmecorp.com" },
  "delegations": [
    {
      "agent_url": "https://buying.pinnacle-media.com",
      "authority": "full",
      "budget_limit": { "amount": 300000, "currency": "USD" },
      "markets": ["FR", "DE", "GB"],
      "expires_at": "2026-06-30T00:00:00Z"
    },
    {
      "agent_url": "https://buying.nova-agency.com",
      "authority": "execute_only",
      "markets": ["US"],
      "expires_at": "2026-06-30T00:00:00Z"
    }
  ]
}
```

権限レベル:

| Level          | Meaning                                          |
| -------------- | ------------------------------------------------ |
| `full`         | 委任の予算と市場の制約内で任意のアクションを実行できる                      |
| `execute_only` | 事前承認されたアクションを実行できるが、新しいキャンペーンを開始したり予算を再配分したりできない |
| `propose_only` | ガバナンスレビュー用にアクションを提案できるが、明示的な承認なしに実行できない          |

委任が存在する場合、ガバナンスエージェントは、アクションを承認する前に `check_governance` の `caller` URL が委任の `agent_url` に一致することを検証します。マッチングは厳密な URI 比較（RFC 3986 に従う正規化後、大文字小文字を区別）によります。フランスでメディアバイを要求するエージェントは、`markets` にフランスを含む委任を持たなければなりません。`execute_only` 権限を持つエージェントは、チャンネル間で予算を再配分できません。

委任が存在しない場合、ガバナンスエージェントはどのエージェントがプランに対して行動できるかを制限しません。

<Note>
  `delegations.authority` は、委任された実行エージェントがプランを代行して何ができるかを管理します。これはプランの予算自律性（`budget.reallocation_threshold` / `budget.reallocation_unlimited`）とは無関係で、`plan.human_review_required` とも無関係です。3 つの別個の関心事: エージェントごとのスコープ、予算運用、決定ごとのレビュー。
</Note>

### Portfolio governance

ホールディングカンパニーやマルチブランド組織のために、プランはクロスブランド制約を定義する `portfolio` オブジェクトを含めることができます。ポートフォリオプランはメンバープランを管理します — メンバープランに対して検証されるあらゆるアクションは、ポートフォリオプランの制約に対しても検証されます。

```json theme={null}
{
  "plan_id": "portfolio_q1_2026_global",
  "brand": { "domain": "acmecorp.com" },
  "objectives": "Global Q1 media governance across all Acme brands",
  "budget": { "total": 50000000, "currency": "USD", "reallocation_threshold": 2000000 },
  "flight": { "start": "2026-01-01T00:00:00Z", "end": "2026-06-30T00:00:00Z" },
  "countries": ["US", "GB", "FR", "DE", "JP"],
  "portfolio": {
    "member_plan_ids": ["plan_sparkle_q1", "plan_glow_q1", "plan_nova_q1"],
    "total_budget_cap": { "amount": 50000000, "currency": "USD" },
    "shared_policy_ids": ["eu_gdpr_advertising", "eu_ai_act_article_50"],
    "shared_exclusions": [
      {
        "policy_id": "no_competitor_properties",
        "enforcement": "must",
        "policy": "No advertising on properties owned by competitor holding companies."
      }
    ]
  }
}
```

ポートフォリオ制約:

* **`total_budget_cap`**: すべてのメンバープランにわたる最大集計支出。ガバナンスエージェントはすべてのメンバープランにわたってコミット済み予算を追跡し、上限を超えるアクションを拒否します。
* **`shared_policy_ids`**: 個々のブランドコンプライアンス設定に関係なく、すべてのメンバープランにわたって強制されるレジストリポリシー。どのブランドチームもオーバーライドできないコーポレートレベルの規制。
* **`shared_exclusions`**: `PolicyEntry` 形状を使って、すべてのメンバープランに適用されるビスポークな除外ポリシー。追加のみ — プランレベルの `custom_policies` と同じ制約。

ガバナンスエージェントは、メンバープランのアクションを、メンバープラン自身の制約とポートフォリオプランの制約の両方に対して検証します。どちらのレベルからの拒否もアクションをブロックします。

ポートフォリオプランがガバナンスエージェントがまだ認識していない `member_plan_id` を参照する場合、ガバナンスエージェントはポートフォリオプランを受け入れ、メンバープランが同期されるにつれてポートフォリオ制約の強制を開始すべきです（SHOULD）。これにより、特定の順序を要求することなく、メンバープランの前にポートフォリオプランを同期できます。

<Note>
  **並行性**: オーケストレーターは、複数のセラーに同時に `create_media_buy` リクエストを送信し、それぞれが `committed` チェックをトリガーする場合があります。予算チェックは特定時点のもので予算を予約しないため、同時承認が合計でプラン予算を超える場合があります。ガバナンスエージェントは結果レポート時にオーバースペンドを検出します。同時のオーバースペンドを防ぐには、実行エージェント間で予算を分割するために、エージェントごとの `budget_limit` を持つ [委任](#delegations) を使います。
</Note>

### 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)` タプルに帰属可能なすべてのプラン — 同じアカウント上のプラン間でのフラグメンテーションは集計をリセットしません。委任されたサブエージェント（[委任](#delegations)を参照）は委任元バイヤーの集計を共有します: キーの `buyer_agent` 要素は委任元プリンシパルであり、サブエージェントの `agent_url` ではありません。委任は新しいエージェントごとの集計ウィンドウを作りません。そうでなければ委任サーフェス自体がフラグメンテーションの穴を再び開くからです（999,900 ドルを 100 のサブエージェントに分割し、それぞれが独自の 9,999 ドルの予算を得る）。
* すべての [支出コミットタスク](#spend-commit-tasks) — タスクサーフェス間でのフラグメンテーションは集計をリセットしません。支出コミットタスクのインベントリが唯一の権威あるリストです。そこに追加される新しい支出コミットタスクは、本セクションでの別個の編集なしに自動的に集計に加わります。
* `governance.aggregation_window_days` ケイパビリティを通じて宣言されるトレーリングウィンドウ（下記 [get\_adcp\_capabilities](#governance-aggregation-capability) を参照）。ウィンドウはプラン境界ではなく実時間でスライドします。

**評価時のセマンティクス（テスト可能）。** 支出コミットの時点で、ガバナンスエージェントは次を計算します。

```
aggregate = sum(c.amount for c in commit_history
                where c.key == this.key
                  and c.ts > now - aggregation_window_days × 86400s)
            + this.amount
```

次に、`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)` をキーとする）。

| # | Prior 30-day aggregate | Incoming commit            | Post-aggregate | Expected outcome                                    |
| - | ---------------------- | -------------------------- | -------------- | --------------------------------------------------- |
| 1 | \$4,000                | \$2,500 `create_media_buy` | \$6,500        | 自動承認 — しきい値未満                                       |
| 2 | \$8,000                | \$2,500 `create_media_buy` | \$10,500       | 人間レビューにエスカレーション — 受信コミットが単独では 2,500 ドルでも集計がしきい値を超える |

エスカレーションなしに行 2 を承認するガバナンスエージェントは非準拠です: 30 日ウィンドウにわたる集計に失敗したか、正しいタプルでキー付けに失敗したか、受信コミットを合計に含めることに失敗したかのいずれかです。

#### Governance aggregation capability

セラーとガバナンスエージェントは、[`get_adcp_capabilities`](/docs/protocol/get_adcp_capabilities) の `governance.aggregation_window_days` を通じて集計ウィンドウを宣言します。コンプライアンスのために特定のウィンドウに依存するバイヤー（例: ブランドレベルの週次ケイデンスレビュー）は、集計セマンティクスに依存する前にこのケイパビリティを確認しなければなりません（MUST）— `aggregation_window_days: 7` を宣言するガバナンスエージェントは、30 日の四半期末プッシュにまたがって広がるフラグメンテーションから防御しません。宣言がないことは、エージェントがいかなる集計ウィンドウにもコミットしていないことを意味し、バイヤーはコミットごとの評価のみを想定しなければなりません（MUST。フラグメンテーション攻撃サーフェスが開いている）。スキーマのデフォルトはありません: 省略は宣言された 30 日ウィンドウと同等ではありません。

## Brand compliance configuration

コンプライアンスポリシーは、個々のキャンペーンプランではなくブランドレベルに存在します。ブランドのポリシーチームがブランドのコンプライアンスプロファイルを設定し、ガバナンスエージェントがそのブランドのプランを処理する際にそれを解決します。

<Note>
  ブランドコンプライアンス設定のスキーマとホスティングメカニズムは、AgenticAdvertising.org ガバナンスワーキンググループによって開発中です。以下は概念モデルを説明します。実装は異なる場合があります。
</Note>

ブランドのコンプライアンス設定には 2 種類のポリシーが含まれます。

* **レジストリポリシー**: [AdCP ポリシーレジストリ](/docs/governance/policy-registry) の標準化されたポリシーへの ID による参照。各参照は、ブランド向けにポリシーをカスタマイズする設定パラメーターを含んでもかまいません（MAY）。
* **カスタムポリシー**: 自然言語文字列として表現されるブランド固有のルール。[プロンプトベースのポリシー](/docs/governance/overview#prompt-based-policies)と同じアプローチでガバナンスエージェントが評価します。

ポリシーチームはブランドに適用されるレジストリポリシーを選択し、必要に応じてパラメーターを設定し、ブランド固有のカスタムポリシーを追加します。バイイングチームはこの設定と対話することはありません — ブランドを参照するキャンペーンプランを作成し、ガバナンスエージェントが適用可能なポリシーを自動的に解決します。

ブランドの業種が自動ポリシーマッチングに情報を与えます — 例えば、飲料業界のブランドはその業界向けにタグ付けされたレジストリポリシーを受け取ります。

## Policy registry

ポリシーレジストリは、標準化された機械可読な広告コンプライアンスポリシーのコミュニティ管理ライブラリです。ブランドは独自に記述する代わりに ID でポリシーを参照します。

レジストリは 3 つのカテゴリをカバーします。

| Category         | Examples                                                         |
| ---------------- | ---------------------------------------------------------------- |
| **Jurisdiction** | UK HFSS 制限、US COPPA、EU GDPR 年齢確認、California AI ディスクロージャー（SB 942） |
| **Vertical**     | アルコール年齢確認、ファーマのフェアバランス、ギャンブルの自己排除、金融サービスの APR ディスクロージャー          |
| **Brand safety** | ブランドセーフティのベースライン、コンテンツ適合性の階層                                     |

レジストリの各ポリシーには、ID、適用管轄、説明、およびガバナンスエージェントがプログラム的に評価できる機械可読なルールがあります。ポリシーは規制の変更に応じてバージョン管理されます。ブランド参照は特定のバージョンにピン留めしてもかまいません（MAY）。バージョンなしの参照は現在のバージョンに解決されます。レジストリ形式とホスティングメカニズムは AgenticAdvertising.org ガバナンスワーキンググループによって開発中です。

このモデルは、[IEEE 7012](https://standards.ieee.org/ieee/7012/7192/)（Machine Readable Personal Privacy Terms）が確立したパターンに従います。IEEE 7012 は、当事者が個別に起草するのではなく参照する標準化された合意の中立的な名簿を維持します。

## Policy resolution

ポリシーは `policy_ids` と `custom_policies` を通じてプラン上で直接宣言されます。プランが同期されると、ガバナンスエージェントはアクティブなポリシーセットを解決します。

1. `policy_ids` で参照されるレジストリポリシーを読み込む
2. プランの `countries` と `regions` と交差させる — プランの市場に適用可能なポリシーのみがアクティブ
3. すべての `custom_policies` を含める（これらは地理に関係なく適用される）

<Warning>
  **`custom_policies` は追加のみです。** ガバナンスエージェントは、レジストリソースのポリシーテキストをシステムレベルの指示としてピン留めしなければならず（MUST）、`custom_policies`（またはプランの `objectives` フィールド）がレジストリソースのポリシーを緩和、オーバーライド、または無効化することを許可してはなりません（MUST NOT）。カスタムポリシーはより厳しい制限を追加できます — 強制レベルを下げたりカテゴリを免除したりできません。レジストリポリシーと矛盾する `custom_policies` エントリは、その代わりにではなく並行して評価されます。より厳格な制約が支配します。
</Warning>

プランの `countries` と `regions` フィールドは**ジオ強制**としても機能します: ガバナンスエージェントは、プランの許可された地理の外の市場をターゲットにする被管理アクションを拒否しなければなりません（MUST）。`regions: ["US-MA"]` のプランは、他の点でコンプライアントであっても、明示的にマサチューセッツをターゲットにしないアクションを拒否します。これらのフィールドは `product-filters`、`offerings`、`create_media_buy` と同じ ISO コードとセマンティクスを使います。

解決されたポリシーセットは、ガバナンスエージェントが [`check_governance`](/docs/governance/campaign/tasks/check_governance) 中に評価するものです。`brand_policy` と `regulatory_compliance` カテゴリについて、ガバナンスエージェントはこの解決されたセットに対して検証します。

プランに `policy_ids` または `custom_policies` がない場合、ガバナンスエージェントはポリシーベースのカテゴリについて空のポリシーセットで動作します。他のカテゴリ（`budget_authority`、`strategic_alignment` など）は、プランのパラメーターに基づいて依然として適用されます。

## Audience governance

キャンペーンプランは、オーディエンスターゲティング制約、制限属性、ポリシーカテゴリを宣言します。ガバナンスエージェントはこれらを使って、セラーのターゲティングが規制要件とキャンペーンの意図に準拠していることを検証します。

### Three-layer model

オーディエンスガバナンスは 3 つの関心事を分離します。

| Layer        | Field                        | Purpose              | Example                                             |
| ------------ | ---------------------------- | -------------------- | --------------------------------------------------- |
| **アイデンティティ** | `brand.industries`           | 会社が何をするか             | `["pharmaceuticals", "consumer_packaged_goods"]`    |
| **規制レジーム**   | `plan.policy_categories`     | このキャンペーンにどの規制が適用されるか | `["pharmaceutical_advertising", "health_wellness"]` |
| **データ制限**    | `plan.restricted_attributes` | ターゲティングに使えない個人データは何か | `["health_data"]`                                   |

製薬会社は常にファーマ（アイデンティティ）ですが、一般的な認知キャンペーンは製薬広告規制をトリガーしないかもしれず（レジーム）、EU 管轄のキャンペーンのみが健康データターゲティングを制限するかもしれません（制限）。

### Audience constraints

プランは、オーディエンスセレクターを使って `audience.include` と `audience.exclude` 配列を宣言できます。各セレクターは `signal_ref` または自然言語の説明のいずれかです。

ガバナンスエージェントは、`check_governance` でこれらの制約をセラーのターゲティングに対して評価します。

1. `planned_delivery.audience_targeting` をプランの `audience.include`/`exclude` と比較
2. `planned_delivery.audience_targeting` を同じ制約と比較（コミット済みチェック用）
3. オーケストレーターが要求したものとセラーが有効化するものの間の乖離を検出

### 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`](/docs/governance/campaign/tasks/check_governance) が予算権限をチェックするとき、プランに紐付けられたすべてのキャンペーンを考慮します。[`report_plan_outcome`](/docs/governance/campaign/tasks/report_plan_outcome) がセラー確認をレポートするとき、ガバナンスエージェントは要求された額ではなくセラーの実際の額から予算をコミットします。

### Plan status

| Status      | Meaning                   |
| ----------- | ------------------------- |
| `active`    | 検証リクエストと結果レポートを受け付け中      |
| `suspended` | 重大なエスカレーションの人間レビュー待ちで一時停止 |
| `completed` | プラン完了。読み取り専用              |

ステータスが `suspended` の場合、ガバナンスエージェントは、エスカレーションが解決されるまで、すべての `check_governance` および `report_plan_outcome` リクエストを `CAMPAIGN_SUSPENDED` エラーで拒否しなければなりません（MUST）。

### Budget tracking

予算は、検証されたアクションではなく**確認された結果**に基づいてコミットされます。フロー:

1. `tool` + `payload`（意図チェック）を伴う `check_governance` が、提案された支出がプランに収まるかをチェックします。まだ予算はコミットされません。
2. オーケストレーターがセラーとアクションを実行します。
3. `report_plan_outcome` がセラーの確認済み額をレポートします。ガバナンスエージェントはこの額をプラン予算にコミットします。

これにより、予算追跡が現実を反映します。セラーが予算を 150K ドルから 120K ドルに削減した場合、ガバナンスエージェントは 120K ドルをコミットし、差異について検出事項を返します。アクションが完全に失敗した場合、ガバナンスエージェントは 0 ドルをコミットします。

実行チェックの承認は、セラーの計画された配信をプランに対して検証しますが、予算をコミットしません。予算は、オーケストレーターがセラーの確認済みレスポンスを伴って `report_plan_outcome` を呼び出すときにのみコミットされます。

予算チェックは特定時点のものです: `check_governance` は現在のコミット済み総額に対して検証しますが、予算を予約しません。複数のエージェントが同じプランに対して同時に実行する場合、2 つのチェックが両方通過し、組み合わせた結果が認可された予算を超える可能性があります。ガバナンスエージェントは結果レポート時にオーバースペンドを検出し、`budget_authority` 検出事項を返します。同時のオーバースペンドを防ぐには、実行エージェント間で予算を分割するために、エージェントごとの `budget_limit` を持つ [委任](#delegations) を使います。

### Drift detection

監査ログには、プランの存続期間にわたる集計ガバナンストレンドを表面化する `drift_metrics` が含まれます。

```json theme={null}
{
  "summary": {
    "checks_performed": 847,
    "drift_metrics": {
      "human_review_rate": 0.03,
      "human_review_rate_trend": "declining",
      "auto_approval_rate": 0.91,
      "human_override_rate": 0.02,
      "mean_confidence": 0.88
    }
  }
}
```

これらのメトリクスは監視ドリフト — 人間から制御が徐々に移行すること — を検出します。人間レビュー率の低下は、ガバナンスエージェントが適切にキャリブレーションされていることを示すかもしれず、または監視が侵食されていることを示すかもしれません。トレンドを表面化させることで、組織がその判断を下せます。

| Metric                    | What it measures                                  |
| ------------------------- | ------------------------------------------------- |
| `human_review_rate`       | 内部の人間レビューを必要としたチェックの割合                            |
| `human_review_rate_trend` | プランの存続期間にわたる方向（`increasing`、`stable`、`declining`） |
| `auto_approval_rate`      | 人間の介入なしに承認されたチェックの割合                              |
| `human_override_rate`     | 人間がガバナンスエージェントをオーバーライドした人間レビューの割合                 |
| `mean_confidence`         | 検出事項全体の平均信頼スコア（信頼度がレポートされる場合）                     |

組織はドリフトメトリクスにしきい値を設定できます。メトリクスがしきい値を超えると、ガバナンスエージェントは次のガバナンスチェックに検出事項（深刻度 `warning`）を含めるべきです（SHOULD）。

```json theme={null}
{
  "drift_metrics": {
    "human_review_rate": 0.01,
    "human_review_rate_trend": "declining",
    "auto_approval_rate": 0.97,
    "thresholds": {
      "human_review_rate_min": 0.02,
      "auto_approval_rate_max": 0.95
    }
  }
}
```

この例では、両方のしきい値が破られています — 人間レビュー率（0.01）が最小値（0.02）を下回り、自動承認率（0.97）が最大値（0.95）を超えています。これは、ガバナンスエージェントが広く承認しすぎていることを示すかもしれず、または低リスクキャンペーンにポリシーが適切にキャリブレーションされていることを示すかもしれません。しきい値の破れが問いを表面化させます。組織が答えを決めます。

組織は懸念に関連するしきい値のみを設定します。`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

ガバナンスエージェントは、各 [検証カテゴリ](/docs/governance/campaign/index#validation-categories) を独立して評価します。

* **いずれか**のカテゴリがステータス `failed` を持ち、その失敗が修正可能な場合、ステータスは提案された修正を伴う `conditions` です
* **いずれか**のカテゴリがステータス `failed` を持ち、その失敗が呼び出し元によって修正不可能な場合、ステータスは `denied` です
* すべてのカテゴリが通過するが全体のリスクプロファイルが人間のレビューを正当化する場合、ガバナンスエージェントはレビューを内部的に処理し（タスクは非同期になる）、最終的に `approved` または `denied` に解決します
* すべてのカテゴリが通過する場合、ステータスは `approved` です

`conditions` 配列は、ステータスが `conditions` の場合にのみ存在します。各条件は、特定のフィールド、その現在の値、提案された値、変更の理由を識別します。

### Finding confidence

ガバナンスの検出事項には、確実な違反を曖昧なものから区別する任意の `confidence` スコア（0-1）と `uncertainty_reason` が含まれます。

```json theme={null}
{
  "category_id": "regulatory_compliance",
  "severity": "critical",
  "confidence": 0.85,
  "uncertainty_reason": "Targeting includes 'New Mexico' which partially overlaps LATAM HFSS jurisdiction boundaries",
  "explanation": "Potential HFSS jurisdiction violation based on targeting geography."
}
```

信頼度は適切な応答に情報を与えます。

* **高信頼度（0.9 以上）**: 検出事項は確定的です。EU ユーザーを明示的にターゲットにしたキャンペーンでの GDPR 違反。
* **中信頼度（0.6-0.9）**: 検出事項は、ガバナンスエージェントが完全に解決できないコンテキストに依存します。未成年者を含む可能性のあるオーディエンスセグメント、規制管轄と部分的に重なるジオターゲティング。
* **低信頼度（0.6 未満）**: 検出事項は推測的です。ガバナンスエージェントは、自律的に行動するのではなく、人間のレビューのためにフラグを立てます。

信頼度がなければ、すべての検出事項が等しく確実として提示され、（確実として扱えば）過剰にブロックするか、（多くが偽陽性なら）人々に検出事項を無視するよう訓練します。ガバナンスエージェントは、評価が自然言語の解釈や確率的マッチングを伴う場合、信頼度を含めるべきです（SHOULD）。

### Phase inference

ガバナンスエージェントは、`check_governance` の `tool` パラメーターから検証フェーズを推論します。

| tool               | Phase                               |
| ------------------ | ----------------------------------- |
| `get_products`     | ディスカバリー — 検索意図、セラー適格性、プロダクト適合性を検証   |
| `create_media_buy` | 購入 — 予算権限、ターゲティングコンプライアンス、フライト日程を検証 |
| `update_media_buy` | 購入 — 変更の大きさ、再配分しきい値を検証              |
| `acquire_rights`   | 購入 — 予算権限、ジオコンプライアンス、フライト日程を検証      |
| `update_rights`    | 購入 — 変更の大きさ、再配分しきい値を検証              |
| `activate_signal`  | 購入 — 予算権限、ジオコンプライアンス、フライト日程を検証      |
| `build_creative`   | 購入 — 予算権限、ジオコンプライアンスを検証             |

フェーズコンテキストは累積的です。**購入**中、ガバナンスエージェントは**ディスカバリー**中に発見されたものを考慮します。

`check_governance` が返す `check_id` は、`report_plan_outcome` がセラーのレスポンスを検証されたアクションにリンクするために使われます。

## Capability declaration

ガバナンスエージェントは、`get_adcp_capabilities` でキャンペーンガバナンスのサポートを宣言します。

```json theme={null}
{
  "governance": {
    "campaign_governance": {
      "categories": [
        {
          "category_id": "budget_authority",
          "description": "Validates spend against plan budget limits and allocation rules."
        },
        {
          "category_id": "strategic_alignment",
          "description": "Validates that purchases match campaign brief and channel mix targets."
        },
        {
          "category_id": "bias_fairness",
          "description": "Checks targeting for discriminatory patterns and protected category compliance.",
          "jurisdictions": ["US", "EU", "UK"]
        },
        {
          "category_id": "regulatory_compliance",
          "description": "Validates jurisdiction-specific advertising regulations.",
          "jurisdictions": ["US", "EU", "UK"]
        },
        {
          "category_id": "seller_verification",
          "description": "Compares seller setup against original requests to detect discrepancies."
        },
        {
          "category_id": "brand_policy",
          "description": "Enforces brand-level compliance policies resolved from the brand configuration and policy registry."
        }
      ]
    }
  }
}
```

## Integration with `create_media_buy`

バイヤーは `create_media_buy` リクエストに `plan_id` を、プロトコルエンベロープに `governance_context` を含めます。これらのフィールドは、どのガバナンスプランが適用されるかをセラーに伝え、セラー側のガバナンスチェックを可能にします。

```json theme={null}
{
  "tool": "create_media_buy",
  "arguments": {
    "plan_id": "plan_q1_2026_launch",
    "account": { "agent_url": "https://seller.example.com", "id": "acc_123" },
    "brand": { "domain": "acmecorp.com" },
    "start_time": "2026-03-15T00:00:00Z",
    "end_time": "2026-06-15T00:00:00Z",
    "packages": ["..."]
  }
}
```

セラーのレスポンスには `planned_delivery` — セラーが実際に実行するもの — が含まれます。

```json theme={null}
{
  "seller_reference": "mb_seller_456",
  "packages": ["..."],
  "planned_delivery": {
    "geo": { "countries": ["US"] },
    "channels": ["olv"],
    "start_time": "2026-03-15T00:00:00Z",
    "end_time": "2026-06-15T00:00:00Z",
    "total_budget": 150000,
    "currency": "USD",
    "frequency_cap": { "max_impressions": 3, "per": "user", "window": { "interval": 1, "unit": "days" } },
    "audience_summary": "Adults 25-54, US, premium video inventory",
    "enforced_policies": ["us_coppa"]
  }
}
```

`planned_delivery` は、リクエストに対するセラーの解釈 — 使用する実際の配信パラメーター — です。2 つの目的を果たします。

1. **ガバナンスチェック** — アカウントにガバナンスエージェントが設定されている場合、セラーはメディアバイを確認する前に検証のために `planned_delivery` をガバナンスエージェントに送信します。
2. **透明性** — バイヤーは、配信開始前に早期に差異を捕捉するために、`planned_delivery` を要求したものと比較できます。

## Governance checks

キャンペーンガバナンスのバイヤー側検証には信頼の限界があります: バイヤーのオーケストレーターが自分の宿題を採点します。LLM エージェントはガバナンス承認を幻覚したり、検証をスキップしたり、何が検証されたかを誤って表現したりする可能性があります。セラー側のガバナンスチェックは、購入が承認されていることをセラーが独立して確認する方法を与えることで、このギャップを閉じます。

被管理アクションイベントが発生すると、セラーはバイヤーが設定したガバナンスエージェント URL に POST します。ガバナンスエージェントはすべての状態を維持し、`plan_id` + `governance_context` でリクエストを相関させます — セラーはガバナンス履歴を追跡したり、呼び出し間で ID をチェーンしたりする必要はありません。

### Both checks must pass

すべての被管理アクションは、バイヤー側の意図チェックとセラー側の計画配信チェックの両方に**合格しなければなりません（MUST）**。両方の呼び出しは同じ権威（バイヤーのガバナンスエージェント）に到達するため、「2 つのエージェントが意見を異にする」ケースはありません — しかし両方の呼び出しが成功しなければならないという不変条件は負荷を担っています。

* バイヤー側の意図チェックは、*プランが原則として支出を許可する*ことを確認します。
* セラー側の計画配信チェックは、*セラーの実際の配信パラメーターが承認されたプランと一致する*ことを確認します。

これらは冗長ではありません。バイヤーの意図チェックが通過し（プランはプレミアムビデオに 100K ドルを許可する）、セラーの計画配信チェックが失敗する（セラーの計画されたラインナップにプランが除外するインベントリが含まれる）ことがあります。どちらかが `denied` を返す場合、アクションは進めてはなりません（**MUST NOT**）。両方が空でない `conditions` を伴って `approved` を返す場合、適用されるセットは両方のレスポンスの条件の**和集合**です。矛盾する条件（一方が X を要求し、他方が NOT X を要求する）は、黙った優先ではなく、構造化された `finding` を伴う `denied` に解決されます。

自身のコンテンツ標準や商業的理由で取引を拒否するセラーは、ガバナンス競合に参加しているわけではありません — それは別個の商取引層の拒否（例: `TERMS_REJECTED`）であり、通常の拒否パスに従います。ガバナンスはバイヤーのプランについてのみ語ります。

### Setup

バイヤーは [`sync_governance`](/docs/accounts/tasks/sync_governance) を通じてガバナンスエージェントを同期し、各アカウントを呼び出すガバナンスエージェントエンドポイントとペアリングします。各エージェントには、ガバナンスエージェントがセラーの識別を検証できるよう認証情報が含まれます。

```json theme={null}
{
  "tool": "sync_governance",
  "arguments": {
    "accounts": [
      {
        "account": {
          "brand": { "domain": "acmecorp.com" },
          "operator": "pinnacle-media.com"
        },
        "governance_agents": [
          {
            "url": "https://governance.pinnacle-media.com",
            "authentication": {
              "schemes": ["Bearer"],
              "credentials": "gov_token_acme_pinnacle_2026_xyzxyzxyz..."
            }
          }
        ]
      }
    ]
  }
}
```

セラーはこれらのエンドポイントを保存し、`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）— 受け取ったステータスに基づいて行動します。

クロール・ウォーク・ランの採用パスについては [安全モデル](/docs/governance/campaign/safety-model) を参照。

### 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 プロファイル](/docs/building/by-layer/L1/security#adcp-jws-プロファイル)に従って署名されたコンパクト JWS です。トークンは、証明をガバナンスエージェントが評価した正確なプラン状態にバインドする必須の `plan_hash` クレームを運びます（下記 [Plan binding and audit](#plan-binding-and-audit) を参照）。呼び出し元は依然として値を相関のために不透明として扱います。検証にオプトインするセラーは [セラー検証チェックリスト](/docs/building/by-layer/L1/security#セラー検証チェックリスト)に従い、トークンの真正性、認可スコープ、鮮度を検証します — バイヤーのプランは検証しません。

### 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](https://www.rfc-editor.org/rfc/rfc8785) — [冪等性ペイロード等価性](/docs/building/by-layer/L1/security#ペイロード等価性)に使われるのと同じスキームです。ガバナンスエージェントと監査人の検証者は、そこにリストされているのと同じライブラリ実装を使うべきです（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）、追加はプロファイルバージョンのバンプを要求する破壊的変更で、[ペイロード等価性](/docs/building/by-layer/L1/security#ペイロード等価性)と同じルールです。

* `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` は、リプレイ時に回転できるよう、[ペイロード等価性](/docs/building/by-layer/L1/security#ペイロード等価性)の閉じた除外リストに含まれています。
* 各内部プランリビジョン記録とともに**リビジョンごとの `plan_hash` を保持する** — `audit_log_pointer` が公開されているかどうかに関係なく MUST。保持が永遠にバインドするプロパティを提供するものです。普遍的な保持がなければ、`audit_log_pointer` を使わないすべてのガバナンスエージェントは、そのトークンコーパス全体の監査層を黙って無効にします。証明されたプラン状態に結合し直せない監査ログは監査証跡の半分であり、自身の履歴トークンを検証できないガバナンスエージェントは、自身のストアの改ざんを検出できません。保持された値は実装内部で、[`get_plan_audit_logs`](/docs/governance/campaign/tasks/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 検証チェックリスト](/docs/building/by-layer/L1/security#セラー検証チェックリスト) — 真正性、認可スコープ、鮮度 — を実行します。トークン内の `plan_hash` を不透明なカーゴとして扱い、決して検査しません。

#### Verification recipes

**監査人レシピ。** プランの監査ログにアクセスできる規制当局やサードパーティ監査人は、次のように履歴証明を検証します。

1. `include_entries: true` を伴って [`get_plan_audit_logs`](/docs/governance/campaign/tasks/get_plan_audit_logs) を呼び出して監査証跡を取得します。各 `check` エントリは `plan_hash`（発行時に主張されたクレーム）と `governance_context`（署名付き JWS）を運びます。
2. 各 governance\_context について、コンパクト JWS をデコードし、ガバナンスエージェントの公開 JWKS に対して 15 ステップの JWS コントラクト（署名、brand.json の `iss`、`aud`、`exp` など）を検証します。
3. デコードされた JWS ペイロードから `plan_hash` クレームを抽出し、base64url デコードして 32 生バイトにします。
4. エントリレベルの `plan_hash` を 32 生バイトにデコードし、クレームとバイト比較します。不一致は、保持された監査記録が署名付きトークンと矛盾することを意味します — トークンが改ざんされたか記録が改ざんされたかのいずれかで、ガバナンスエージェントの整合性が疑われます。
5. 任意: ガバナンスエージェントの保持されたリビジョンごとのプラン記録から `plan_hash` を再計算し（監査人がガバナンスエージェントのリビジョンストアへの認証済みアクセスを持つ場合）、再度バイト比較します。ここでの不一致は、署名と監査の間にガバナンスエージェント自身のストアが改ざんされたことを意味します。

**バイヤー側コンプライアンスレシピ。** 自身のツールがガバナンスエージェントが正直なトークンを生成していることを検証したいバイヤー:

1. プロトコルエンベロープを通じてセラーに流れる `governance_context` トークンを観察します（バイヤーはすでにこれらを持っています。取得不要）。
2. 各トークンについて、JWS をデコードし、`plan_hash` クレームを抽出し、base64url デコードして 32 バイトにします。
3. トークンが証明するリビジョンでのバイヤー自身のプランのコピーにわたって `plan_hash` を再計算します。バイヤーは自身の `sync_plans` 呼び出しから権威あるプラン状態を持っています。
4. バイト比較します。不一致は、ガバナンスエージェントがバイヤーが実際にプッシュしたプランに一致しない証明に署名していることを意味します — ベンダーの侵害またはバグのいずれかです。どちらもバイヤーがエスカレーションすべき重大な検出事項です。

このパスは、セラー、監査人、プロトコルを関与させずに不正なガバナンスベンダーを捕捉します。データはすでにバイヤー側にあります。

**定数時間比較。** 3 種類の検証者すべて — ガバナンスエージェントの自己整合性、監査人、バイヤー側コンプライアンス — は、`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/`](https://github.com/adcontextprotocol/adcp/tree/main/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          | Trigger                                                                | What's validated         |
| -------------- | ---------------------------------------------------------------------- | ------------------------ |
| `purchase`     | `create_media_buy`、`acquire_rights`、`activate_signal`、`build_creative` | 予算、ジオ、チャンネル、フライト日程、ポリシー  |
| `modification` | `update_media_buy`、`update_rights`                                     | 変更の大きさ、再配分、新しいパラメーター     |
| `delivery`     | 定期的（セラー起動）                                                             | ペーシング、支出率、ジオドリフト、チャンネル分布 |

`phase` フィールドは省略された場合 `purchase` にデフォルトするため、既存の実装は変更なしに動作し続けます。

ガバナンスエージェントはすべての状態を維持し、`plan_id` + `governance_context` でリクエストを相関させます。セラーはチェック ID をチェーンしたり会話履歴を追跡したりしません — 何が起きたかをポストし、ガバナンスエージェントがコンテキストをルックアップします。

### Purchase phase

セラーが `governance_agents` を持つアカウントで `create_media_buy` リクエストを受け取ったとき:

1. セラーはリクエストを解釈し、その `planned_delivery` を決定します。
2. セラーは `phase: "purchase"`、`plan_id`、`planned_delivery` を伴って `check_governance` を呼び出します。
3. ガバナンスエージェントは計画された配信をキャンペーンプランに対して検証します。
4. `approved` なら、セラーはメディアバイを確認します。
5. `denied` なら、セラーは `GOVERNANCE_DENIED` エラーでメディアバイを拒否します。
6. `conditions` なら、セラーは条件を満たすように計画された配信を調整して再検証するか、拒否します。

```mermaid theme={null}
sequenceDiagram
    participant O as Orchestrator
    participant S as Seller
    participant A as Governance Agent

    O->>S: create_media_buy(plan_id, packages, ...)
    S->>S: Interpret request → planned_delivery
    S->>A: POST check_governance(phase: purchase)
    A->>A: Validate against plan
    A-->>S: approved
    S-->>O: media_buy confirmed (planned_delivery)
```

### Modification phase

セラーが `update_media_buy` リクエストを受け取ったとき:

1. セラーは更新を解釈し、新しい `planned_delivery` を決定します。
2. セラーは `phase: "modification"`、更新された `planned_delivery`、`modification_summary` を伴って `check_governance` を呼び出します。
3. ガバナンスエージェントは `plan_id` + `governance_context` で被管理アクションをルックアップし、変更をプランに対して評価します。
4. `approved` なら、セラーは更新を確認します。
5. `denied` または `conditions` なら、セラーは購入フェーズと同じフローに従います。

```mermaid theme={null}
sequenceDiagram
    participant O as Orchestrator
    participant S as Seller
    participant A as Governance Agent

    O->>S: update_media_buy(budget: $200K, end: Jul 15)
    S->>S: Determine new planned_delivery
    S->>A: POST check_governance(phase: modification)
    A->>A: Look up media buy, evaluate changes
    A-->>S: approved
    S-->>O: media_buy updated
```

ガバナンスエージェントは、初期購入とは異なるロジックを修正に適用できます。例えば、`reallocation_threshold` 内の小さな予算増加は自動承認され、一方で大きな予算増加や新しいジオ市場はより厳格な精査を必要とするかもしれません。

### Delivery phase

セラーは、アクティブな配信中に定期的に `phase: "delivery"` を伴って `check_governance` を呼び出します。これにより、セラーとバイヤーのガバナンスエージェントの間に直接のレポートチャネルが作られます。

1. セラーはレポート期間の配信メトリクスを収集します。
2. セラーは `phase: "delivery"`、現在の `planned_delivery`、`delivery_metrics` を伴って `check_governance` を呼び出します。
3. `approved` なら、レスポンスには `next_check` — セラーが次にレポートすべき時 — が含まれます。
4. `denied` なら、セラーは直ちに配信を一時停止します。
5. `conditions` なら、セラーは配信を調整し（例: ペーシングを遅くする、ジオターゲティングをシフトする）、直ちに再検証します。

ガバナンスエージェントは、購入承認レスポンスに `next_check` を含めることで配信レポートにオプトインします。購入レスポンスに `next_check` がない場合、ガバナンスエージェントは配信レポートを期待しません。

```mermaid theme={null}
sequenceDiagram
    participant S as Seller
    participant A as Governance Agent

    loop Every reporting period
        S->>A: check_governance(phase: delivery, metrics)
        A->>A: Check pacing, geo drift, spend rate
        A-->>S: approved (next_check: +7d)
    end

    Note over S,A: If drift detected
    S->>A: check_governance(phase: delivery, metrics)
    A-->>S: conditions (slow pacing)
    S->>S: Adjust delivery
    S->>A: check_governance(phase: delivery, updated metrics)
    A-->>S: approved (next_check: +3d)
```

ガバナンスエージェントは `next_check` を通じてレポートケイデンスを制御します。ドリフトや条件を検出したときにケイデンスを締め（より短い間隔）、配信が安定しているときに緩める（より長い間隔）ことができます。ガバナンスエージェントは、見逃した `next_check` の期限を次の配信チェックでの検出事項として扱ってもかまいません（MAY）。

### Verification examples

**購入リクエスト:**

```json theme={null}
{
  "tool": "check_governance",
  "arguments": {
    "plan_id": "plan_q1_2026_launch",
    "caller": "https://seller.example.com",
    "governance_context": "gc_from_buyer_envelope",
    "phase": "purchase",
    "planned_delivery": {
      "geo": { "countries": ["US"] },
      "channels": ["olv"],
      "start_time": "2026-03-15T00:00:00Z",
      "end_time": "2026-06-15T00:00:00Z",
      "total_budget": 150000,
      "currency": "USD",
      "frequency_cap": { "max_impressions": 3, "per": "user", "window": { "interval": 1, "unit": "days" } },
      "audience_summary": "Adults 25-54, US, premium video inventory",
      "enforced_policies": ["us_coppa"]
    }
  }
}
```

**承認（配信オプトイン付き購入）:**

```json theme={null}
{
  "check_id": "auth_001",
  "verdict": "approved",
  "plan_id": "plan_q1_2026_launch",
  "explanation": "Planned delivery is within plan parameters. Budget: $150,000 of $500,000 plan total. Geo: US (within plan). Channel: OLV (within 40-70% target range).",
  "expires_at": "2026-03-15T01:00:00Z",
  "next_check": "2026-03-22T00:00:00Z"
}
```

`next_check` フィールドは、ガバナンスエージェントが配信レポートを期待していることを示します。存在しない場合、配信レポートは期待されません。

**拒否（購入）:**

```json theme={null}
{
  "check_id": "auth_002",
  "verdict": "denied",
  "plan_id": "plan_q1_2026_launch",
  "explanation": "Planned delivery targets CA (Canada) which is not an authorized market for this plan.",
  "findings": [
    {
      "category_id": "strategic_alignment",
      "severity": "critical",
      "explanation": "Geo targeting includes CA but plan only authorizes US.",
      "details": {
        "plan_countries": ["US"],
        "planned_countries": ["US", "CA"]
      }
    }
  ]
}
```

**承認（配信）:**

```json theme={null}
{
  "check_id": "auth_004",
  "verdict": "approved",
  "plan_id": "plan_q1_2026_launch",
  "explanation": "Delivery on track. Week 1 spend: $12,500 of $150,000 (8.3%). Pacing is on target for 13-week flight.",
  "next_check": "2026-03-29T00:00:00Z"
}
```

### 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`](/docs/accounts/tasks/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` を検出事項にエコーします。プロデューサーコントラクトについては [ポリシー帰属](/docs/governance/policy-attribution) を参照。

キャンペーンガバナンスの内部ではなく隣接する関連する専門家レビュー — クリエイティブのブランドセーフティ事前スクリーン、プロパティリストポリシー、コンテンツ標準評価 — は、独自のエージェントと独自のライフサイクルを持つ別個のガバナンスサーフェスです（[`build_creative`](/docs/creative/task-reference/build_creative)、プロパティガバナンス、コンテンツ標準ガバナンスを参照）。キャンペーンガバナンスはプランについてのみ語ります。

### Governance checks and the governance loop

ガバナンスチェックはバイヤー側のガバナンスループを補完します。置き換えません。

| Concern       | Intent checks (orchestrator, `tool` + `payload`) | Execution checks (seller, `governance_context` + `planned_delivery`) |
| ------------- | ------------------------------------------------ | -------------------------------------------------------------------- |
| **誰がチェックするか** | オーケストレーターが呼び出すバイヤーのガバナンスエージェント                   | セラーが呼び出すバイヤーのガバナンスエージェント                                             |
| **いつ**        | バイヤーがリクエストを送信する前                                 | 確認前、更新時、配信中                                                          |
| **何が検証されるか**  | バイヤーの意図したアクション                                   | セラーの計画された、実際の配信                                                      |
| **信頼モデル**     | 自己申告                                             | 独立して検証                                                               |
| **予算追跡**      | Yes（プラン状態）                                       | ガバナンスエージェントが状態を維持                                                    |
| **継続的な監視**    | `report_plan_outcome` 経由                         | `delivery` フェーズ経由                                                    |

`delivery` フェーズは、セラーが実際に配信しているものへのリアルタイムの可視性をガバナンスエージェントに与えます。バイヤー側の `report_plan_outcome` はオーケストレーターの正直なレポートに依存します。`delivery` フェーズはセラーから直接レポートを得ます。

バイヤー側とセラー側のガバナンスチェックは同じエージェント — `sync_governance` を通じてアカウントに登録されたもの — に到達します。オーケストレーターは意図チェックのためにそれを呼び出し、セラーは実行チェックのためにそれを呼び出します。両方の会話が同じプラン状態を持つ同じ権威に到達します。

## Orchestrator integration pattern

```mermaid theme={null}
flowchart TD
    A[Sync plan] --> B[Agent decides to act]
    B --> C["check_governance(plan_id, tool, payload)"]
    C --> D{Status?}
    D -->|approved| E[Send create_media_buy to seller]
    D -->|conditions| F[Apply conditions]
    F --> C
    D -->|denied| G[Log denial, skip action]
    D -->|async| J[Task goes async — human review internal to governance agent]
    J --> K[Resolves to approved or denied]
    K --> C
    E --> L{Governance agent?}
    L -->|yes| M["Seller calls check_governance (purchase)"]
    L -->|no| N[Seller processes normally]
    M --> O{Approved?}
    O -->|approved| N
    O -->|denied| P[Seller rejects media buy]
    O -->|conditions| Q[Seller adjusts or rejects]
    N --> R[Receive seller response with planned_delivery]
    R --> S["report_plan_outcome(plan_id, check_id, outcome)"]
    S --> T{Status?}
    T -->|accepted| U[Continue]
    T -->|findings| V[Review findings, decide next action]
    V --> U
    U --> W{Update needed?}
    W -->|yes| X["check_governance(tool: update_media_buy, payload)"]
    X --> Y["Seller calls check_governance(governance_context, phase: modification)"]
    W -->|no| Z{Delivery active?}
    Z -->|yes| AA["Seller calls check_governance (delivery) periodically"]
    AA --> AB{Delivery approved?}
    AB -->|approved| Z
    AB -->|denied| AC[Seller pauses delivery]
    AB -->|conditions| AD[Seller adjusts delivery]
    AD --> Z
```

ガバナンスチェックは、オーケストレーターのアクションループにおける同期呼び出しです。オーケストレーターは、セラーにリクエストを送信する前に `tool` + `payload`（意図チェック）を伴って `check_governance` を呼び出します。セラー側の実行チェックはオーケストレーターに対して透過的です — オーケストレーターは、ガバナンスチェックが設定されているかどうかに関係なく同じ `create_media_buy` リクエストを送信します。修正と配信フェーズのチェックは、オーケストレーターのガバナンスループとは独立に、セラーとガバナンスエージェントの間で発生します。

## Audit trail

すべてのプランは、[`get_plan_audit_logs`](/docs/governance/campaign/tasks/get_plan_audit_logs) を通じて取得可能な、すべての検証されたアクションとレポートされた結果の順序付き監査証跡を維持します。証跡には次が含まれます。

* チェック ID、タイムスタンプ、ツール
* ステータスとカテゴリ評価
* 結果ステータスとコミット済み予算
* 結果レポートからの検出事項
* 内部エスカレーションとその解決（ガバナンスエージェントが記録）
* 人間の承認者の識別（人間レビューが内部的に発生した場合）
* 時間経過に伴う配信メトリクス

この監査証跡はコンプライアンスとレポートのニーズに応えます。規制カテゴリ（政治広告、金融サービス）について、証跡はすべてのトランザクションにガバナンスが適用されたという証拠を提供します。

## Conformance testing

ガバナンスエージェント実装のための適合性テストスイートが計画されています。テストベクターは構造化された入出力ペア — プラン、ポリシーのセット、`check_governance` リクエスト、期待されるレスポンスステータスと検出事項 — を提供します。ガバナンスエージェントはこれらのベクターを実行して、ポリシー評価が一貫した結果を生成することを検証できます。

ポリシーレジストリの exemplar（ポリシーごとの合否シナリオ）が原材料を提供します。テストベクターはこれらを、任意のガバナンスエージェントが検証できる実行可能なアサーションに形式化します。AdCP クライアントテストライブラリは、標準テストスイートの一部としてこれらのベクターを含めます。

## Property list governance

キャンペーンガバナンスは、メディアバイがプロパティリストを参照するときにプロパティガバナンスと交差します。ガバナンスエージェントは、メディアバイリクエストで参照されるプロパティリストがプランのブランドセーフティとコンプライアンス要件を満たすことを検証してもかまいません（MAY）。これにより、プロパティリストがブランドのコンプライアンス設定と強制されたポリシーに整合することを保証します。