> ## 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.

# キャンペーンガバナンス

> AdCP キャンペーンガバナンスは、三者信頼を使って自律的なメディアバイを承認済みプラン、予算制限、コンプライアンスポリシーに対して検証します。

# キャンペーンガバナンスプロトコル

<img src="https://mintcdn.com/pier1inc/vHTnro7E5QeRFhdT/images/walkthrough/diagram-governance-triangle.png?fit=max&auto=format&n=vHTnro7E5QeRFhdT&q=85&s=761df99e77db6d707ca689351cfa3f9c" alt="三者ガバナンス: バイヤーオーケストレーターがガバナンスエージェントにプランを送信し、ガバナンスエージェントが検証して承認を返し、オーケストレーターがセラーにバイを送信し、セラーがガバナンスエージェントで検証します。どの当事者も自分自身の採点はしません。" style={{ width: '100%', borderRadius: '12px', marginBottom: '1.5rem' }} width="1376" height="768" data-path="images/walkthrough/diagram-governance-triangle.png" />

キャンペーンガバナンスは、バイサイドの広告トランザクションの自動検証を提供します。AI エージェントが自律的にメディアを購入するとき、キャンペーンガバナンスは独立したレビュー層として機能し、すべてのアクションを承認済みプラン、ブランドポリシー、予算制限、コンプライアンス要件に対して検証します。

## 問題

AI エージェントがブリーフを解釈し、セラーを選び、メディアバイを交渉し、人間が見ていない中でライブにする — これが「ノーアイズ」問題だ: 自律エージェントが、購入が承認されたものと一致するかどうかの独立したチェックなしに実際の財務コミットメントを行います。

既存の AdCP ガバナンスドメインは、広告がどこに配信されるか（プロパティガバナンス）、どのコンテンツが隣接するか（コンテンツスタンダード）、どのクリエイティブが安全か（クリエイティブガバナンス）、ブランドが誰か（ブランドプロトコル）を解決します。しかしどれも**何が購入されてなぜか**を統治しません。

バイサイドにガバナンス層がないと:

* エージェントが承認された予算を超えたり、承認されたパラメーター外に支出を再配分したりする可能性があります
* エージェントがブリーフを誤解する可能性がある — ブリーフが「Mexico」と言っているのに「New Mexico」で購入します
* ターゲティングがブランドポリシーに違反したり差別的なパターンを生み出したりする形でドリフトする可能性があります
* セラーのレスポンスがリクエストされたものと異なっていても、自動検証がない
* コンプライアンスポリシーが断片化されている — すべてのキャンペーンプランに自然言語文字列としてコピー＆ペーストされており、標準ライブラリがなく、ポリシーを定義する者とキャンペーンを実行する者の分離もない

キャンペーンガバナンスは3つのメカニズムでこのギャップを埋める: 何が許可されているかを定義する**プラン**（エージェントとは独立して）、バイヤーとは独立して購入を検証する**セラーサイドのガバナンスチェック**、コンプライアンスルールをガバナンスエージェント全体で標準化する**ポリシーレジストリ**。

ガバナンスは3つの動作モードを通じた段階的な採用をサポートする: **audit**（すべてをログに記録し、絶対にブロックしない）、**advisory**（事後レビューのために問題にフラグを立てる）、**enforce**（違反時にブロックします）。組織は、執行を有効にする前に信頼を築くために audit モードで開始できます。

### 業界の先例

キャンペーンガバナンスは、今日のアドテックに手動プロセスとして存在するパターンを形式化する:

| 手動プロセス                | キャンペーンガバナンスの相当物          |
| --------------------- | ------------------------ |
| エージェンシートレーディングデスクの QA | IO に対する自動検証              |
| DSP のプリビッドルール         | 予算権限とターゲティングコンプライアンスチェック |
| 広告主の承認ワークフロー          | 高リスクアクションの人間エスカレーション     |
| ポストキャンペーン監査           | セラーの検証とデリバリー検証           |
| コンプライアンスレビュー          | 管轄ごとの規制チェック              |

## 仕組み

オーケストレーターは [`sync_plans`](/docs/governance/campaign/tasks/sync_plans) でキャンペーンプランをプッシュし、セラーに送信するすべてのアクションの前に `binding: "proposed"` で [`check_governance`](/docs/governance/campaign/tasks/check_governance) を呼び出す。セラーは実行前に `binding: "committed"` で `check_governance` を独立して呼び出す。セラーのレスポンスを受け取った後、オーケストレーターは [`report_plan_outcome`](/docs/governance/campaign/tasks/report_plan_outcome) を呼び出してループを閉じる。ガバナンスエージェントは試みられたアクションだけでなく、確認された結果から予算を追跡します。

```mermaid theme={null}
flowchart LR
    subgraph brand["ブランド組織"]
        policy["ポリシーチーム"]
        buying["購買チーム / エージェンシー"]
        orchestrator["オーケストレーター"]
        gov["認証 /<br/>ガバナンスエージェント"]
        policy -->|"コンプライアンスを設定"| gov
        buying -->|"操作"| orchestrator
        orchestrator -->|"1. プランを同期"| gov
        orchestrator -->|"2. check_governance<br/>(binding: proposed)"| gov
        orchestrator -->|"5. 結果を報告"| gov
        gov -->|"ステータス / 結果"| orchestrator
    end

    orchestrator -->|"3. create_media_buy<br/>(plan_id)"| seller["セラーエージェント"]
    seller -->|"4. check_governance<br/>(binding: committed)"| gov
    seller -->|"確認 + planned_delivery"| orchestrator
    gov -.->|"エスカレーション"| human["人間の承認者"]
```

キャンペーンガバナンスには3つの当事者が参加する:

* **オーケストレーター**はアクションをセラーに送信する前にプランに対して検証する（バイヤーサイドのガバナンスループ）。
* **セラー**はバイヤーのガバナンスエージェントをプランデリバリーパラメーターで呼び出すことで、独立して購入をチェックする（セラーサイドのガバナンスチェック）。
* **ガバナンスエージェント**は同じキャンペーンプランに対して、オーケストレーターの意図されたアクションとセラーの計画されたデリバリーの両方を検証します。

これにより、バイヤーもセラーも一方的に何が承認されたかを誤って表現できない信頼モデルが生まれる。オーケストレーターはガバナンスをスキップできない（セラーが独立してチェックします）し、セラーは承認されたものと異なるものを配信できない（ガバナンスエージェントは計画されたデリバリーの記録を持っています）。

## 職務分離

キャンペーンガバナンスは**ポリシーを定義する者**と**キャンペーンを実行する者**の間に自動化された分離を強制する:

* **ポリシーチーム**は[ポリシーレジストリ](#ポリシー解決)から適用可能なコンプライアンスポリシーを選択し、ブランド固有のルールを設定し、ブランドのコンプライアンスプロファイルを維持します。この設定は個々のキャンペーンプランではなく、ブランドレベル（brand.json 内）に存在します。
* **購買チーム**（またはエージェンシー）はオーケストレーターを操作し、キャンペーンプランを作成し、メディアバイを実行します。プランはキャンペーンコンテキスト（予算、チャンネル、フライト日程、承認市場）を指定し、必要に応じて追加のレジストリポリシーやキャンペーン固有のルールを参照できます。
* **ガバナンスエージェント**はブランドのコンプライアンス設定から適用可能なポリシーを解決し、それらに対してすべてのオーケストレーターアクションを検証します。

オーケストレーターはブランドのコンプライアンスポリシーをバイパスまたは変更できない — それらはガバナンスエージェントによってブランド設定から解決されます。プランは `policy_ids` と `custom_policies` で追加ポリシーを重ねられるが、ブランドのベースラインは常に適用されます。規制が変更されると、ポリシーチームはブランド設定を一度更新し、すべてのアクティブなキャンペーンが自動的に変更を取り込む。

## ポリシー解決

ガバナンスエージェントはプランのブランド参照を通じて適用可能なポリシーを解決する:

1. プランには `brand.domain`（必須）とオプションで `countries`/`regions`（このキャンペーンの承認市場）が含まれます
2. ガバナンスエージェントは[ブランドプロトコル](/docs/brand-protocol/index)でブランドを解決し、コンプライアンス設定を取得します
3. ブランド設定は ID で**ポリシーレジストリ**から標準化されたポリシーを参照し、ブランド固有のカスタムポリシーを含みます
4. ガバナンスエージェントはこれらのポリシーとプランの承認市場を交差させる — それらの市場に適用可能なポリシーのみがこのプランでアクティブになります
5. 解決されたポリシーセットが `check_governance` で評価されるもの
6. 承認市場外をターゲットにするメディアバイは、ポリシーコンプライアンスに関わらず拒否されます

\*\*[ポリシーレジストリ](/docs/governance/policy-registry)\*\*はコミュニティが管理する標準化された機械可読な広告コンプライアンスポリシーのライブラリだ — 管轄（UK HFSS 制限、US COPPA、EU GDPR）、ポリシーカテゴリ（子供向け、医薬品、公正住宅、公正雇用）、ブランド安全ベースラインをカバーします。ブランドは独自のポリシーを書く代わりにレジストリから適用可能なポリシーを選択します。

## ガバナンスループ

すべてのセラーインタラクションは前後パターンに従う:

1. **前**: オーケストレーターは送信する予定のツールとペイロードで `binding: "proposed"` で `check_governance` を呼び出す。ガバナンスエージェントはステータスを返します。
2. **実行**: 承認された場合、オーケストレーターは `plan_id` と `governance_context` を含めてセラーにアクションを送信します。
3. **チェック**: アカウントに `governance_agents` がある場合、セラーは `binding: "committed"` とその `planned_delivery`（実際に実行するもの）で `check_governance` を呼び出す。ガバナンスエージェントは承認または拒否します。
4. **後**: オーケストレーターはセラーのレスポンスで `report_plan_outcome` を呼び出す。ガバナンスエージェントは状態を更新し、不一致にフラグを立てる。

このパターンは探索（`get_products`）、購入（`create_media_buy`、`update_media_buy`）、定期的なデリバリーレポーティングに適用されます。

## 計画されたデリバリー

セラーがメディアバイを確認するとき、実際に配信するものを説明する `planned_delivery` オブジェクトを返す — 使用するジオターゲティング、チャンネル、フライト日程、フリークエンシーキャップ、予算。これはバイヤーがリクエストしたものと異なる場合がある（例: セラーが追加のフリークエンシーキャップを適用したり、利用可能なインベントリに合わせてジオを調整したりする場合）。

`planned_delivery` は2つの目的を果たす:

1. **ガバナンスチェック**: セラーはバイヤーのガバナンスエージェントに `planned_delivery` を送信し、キャンペーンプランと一致することを確認します。これにより、セラーがバイヤーが承認しなかったものを配信することを防ぐ。
2. **不一致の検出**: バイヤーは `planned_delivery` を元のリクエストと比較し、`report_plan_outcome` で差異にフラグを立てることができ、デリバリーが始まる前に設定のドリフトをキャッチします。

## セラーサイドのガバナンスチェック

バイヤーサイドのガバナンスには信頼の制限がある: オーケストレーターが自身のコンプライアンスを証明します。LLM エージェントはガバナンスの承認を幻覚したり、検証をスキップしたり、検証されたものを誤って表現したりする可能性があります。お金を使っているエージェントが、そのお金を使うことが OK かどうかをチェックするエージェントでもあることは信頼できません。

セラーサイドのガバナンスチェックがこれを解決します。バイヤーはアカウントを同期するときに `governance_agents`（認証情報付きの URL）を登録します。セラーが `create_media_buy` を受け取ると、配信する予定のものでガバナンスエージェントを呼び出す。ガバナンスエージェントはプランに対してチェックし、`approved`、`denied`、または `conditions` を返します。

これは誤解もキャッチします。ブリーフが「Mexico」と言っていてセラーが「New Mexico」と解釈した場合、ガバナンスエージェントはプランに対するジオの不一致を見て、ライブになる前にバイを拒否します。

Webhook はメディアバイのライフサイクル全体をカバーする:

* **購入**: `create_media_buy` を確認する前に POST — このバイは承認されているか?
* **変更**: `update_media_buy` を確認する前に POST — この変更は OK か?
* **デリバリー**: デリバリー中に定期的に POST — デリバリーはまだ軌道に乗っているか?

ガバナンスエージェントがすべての状態を管理します。セラーは何が起きているかをポストするだけ — チェーン、会話履歴、サーバー間で追跡する状態はない。

ガバナンスチェックはすべてのフェーズでオプションです。セラーは購入のみで開始し（バイごとに1回の POST）、変更とデリバリーチェックを段階的に追加できます。完全なプロトコルは[仕様](/docs/governance/campaign/specification#governance-checks)を参照。

ガバナンスチェックを実装するセラーは競合優位を得る: 実行前に購入が独立して検証されたことをバイヤーに証明できます。これにより紛争リスクが減り、コンプライアンス検証が自動化され、厳格な監督要件を持つバイヤーに信頼を示します。

## 採用パス

キャンペーンガバナンスはバイヤーのポリシーチームがガバナンスエージェントで設定する3つの動作モードをサポートする:

| モード        | 動作                                                                            | 使用する場合                                        |
| ---------- | ----------------------------------------------------------------------------- | --------------------------------------------- |
| `audit`    | すべてのチェックをログに記録し、絶対にブロックしません。添付された結果とともに常に `approved` を返します。                   | 最初のロールアウト。執行を有効にする前にキャリブレーションの信頼を築く。          |
| `advisory` | 実際のステータス（`denied`、`conditions`、`escalated`）を返すが、セラーはすべてのレスポンスを非ブロッキングとして扱います。 | 事後の人間レビュー。ガバナンスエージェントが意見を表明し、人間がそれに基づいて行動します。 |
| `enforce`  | `denied` または `escalated` でブロックします。進む前に解決を要求します。                               | 本番ガバナンス。デフォルト。                                |

`audit` モードで開始してガバナンスがフラグを立てるものを確認します。`advisory` に移行してリアルキャンペーンで結果をテストします。信頼が確立されたら `enforce` に切り替える。これは直接購入する単一ブランドと、35のブランドと複数のエージェンシーパートナーを持つホールディングカンパニーの両方で同じように機能します。

### 小規模ブランドの場合

直接購入するブランド（エージェンシーなし、ポリシーチームなし）でも以下が得られます:

* キャンペーンプランからの自動予算制限とジオ執行
* [ポリシーレジストリ](/docs/governance/policy-registry)からのコンプライアンスカバレッジ — レジストリポリシーはコミュニティが管理しており、ブランドごとの設定は不要
* ガバナンスチェックを介したセラーサイドの検証
* `get_plan_audit_logs` による完全な監査証跡

ガードレールを定義するために `authority_level: "agent_limited"` と `reallocation_threshold` を設定します。ガバナンスエージェントが残りを処理します。

### マルチエージェンシーとホールディングカンパニーの設定

プランは、プランに対してどのエージェントが実行できるかをスコープする[委任](/docs/governance/campaign/specification#delegations)をサポートする — 権限レベル、予算制限、市場、有効期限で。ブランドはヨーロッパ市場向けに1つのエージェンシーに `full` 権限を、北米向けに別のエージェンシーに `execute_only` 権限を委任できます。

複数ブランドを管理するホールディングカンパニーの場合、[ポートフォリオガバナンス](/docs/governance/campaign/specification#portfolio-governance)はクロスブランドの制約を定義します: 総ポートフォリオ支出上限、共有ポリシー執行、個々のブランドプランが上書きできない企業レベルの除外。

### 信頼の発見

ガバナンスの結果には「これは確実に GDPR に違反する」（0.95）と「これはオーディエンスセグメントの解決方法によっては違反する可能性がある」（0.6）を区別するオプションの[信頼スコア](/docs/governance/campaign/specification#finding-confidence)（0〜1）が含まれます。これによりブランドが適切に対応できる — 高信頼の結果は自動解決でき、中信頼の結果は人間レビューのためにフラグが立てられます。

### ドリフト検出

[監査ログ](/docs/governance/campaign/tasks/get_plan_audit_logs)にはトレンド指標を持つ集計メトリクス（エスカレーション率、自動承認率、人間オーバーライド率）が含まれます。エスカレーション率の低下は、システムが適切にキャリブレートされているか、監督が侵食されていることを意味するかもしれない。トレンドを表面化させることで、組織がその判断を下せる。

## ライフサイクルフェーズ

キャンペーンガバナンスは3つのフェーズにわたってステートフルだ:

| フェーズ      | タイミング                                     | 検証される内容                                       |
| --------- | ----------------------------------------- | --------------------------------------------- |
| **探索**    | `get_products` 前                          | 検索意図がプランと一致、承認されたセラーからのプロダクト、価格が適切            |
| **購入**    | `create_media_buy` / `update_media_buy` 前 | 予算が制限内、ターゲティングが準拠、フライト日程が一致、クリエイティブアサインメントが適切 |
| **デリバリー** | 定期レポーティング                                 | ペーシングがパラメーター内、支出率が一貫、デリバリーメトリクスが軌道に乗っている      |

各フェーズは以前のフェーズのコンテキストを基に構築されます。**購入**中、ガバナンスエージェントは**探索**中に発見（および承認）されたプロダクトを把握しています。**デリバリー**中は、購入されたものに対して実行を監視します。

## 検証カテゴリ

| カテゴリ                    | チェック内容                                                                                                        |
| ----------------------- | ------------------------------------------------------------------------------------------------------------- |
| `budget_authority`      | 承認された制限内の支出、セラーごとの集中度、再配分の規模                                                                                  |
| `strategic_alignment`   | チャンネルミックス、オーディエンスの一致、パブリッシャー品質ティア、ブリーフの一貫性                                                                    |
| `bias_fairness`         | 保護カテゴリのターゲティング、オーディエンス構成、不均衡な影響。プランの `policy_categories` で定義された `restricted_attributes` に対してオーディエンスセレクターを照合する |
| `regulatory_compliance` | ブランドのコンプライアンス設定とプランの承認国/地域から解決された管轄固有の規制                                                                      |
| `seller_verification`   | 設定の正確さ、未開示の変更、デリバリーの妥当性                                                                                       |
| `brand_policy`          | ブランド設定とポリシーレジストリから解決されたブランドレベルのコンプライアンスポリシー — 競合他社の分離、カテゴリ隣接、カスタムブランドルール                                      |

ガバナンスエージェントは `get_adcp_capabilities` でどのカテゴリを評価するかを宣言します。

## ステータス

すべてのガバナンスチェックは構造化されたステータスを返します:

| ステータス        | 意味          | 呼び出し元のアクション                        |
| ------------ | ----------- | ---------------------------------- |
| `approved`   | すべてのチェックに合格 | 進める                                |
| `denied`     | ハードポリシーに違反  | 進まない; ユーザーに報告する                    |
| `conditions` | 特定の変更で合格できる | 条件を適用し、`check_governance` を再呼び出しする |
| `escalated`  | 人間のレビューが必要  | 一時停止して人間の承認者に通知する                  |

結果の深刻度レベルは緊急性を示します:

* **`info`** -- 監査のためにログに記録。承認レスポンスの助言的な結果に使用。
* **`warning`** -- 人間がレビューすべき。アクションが許可されているが注意が必要な場合の承認レスポンスに使用。
* **`critical`** -- アクションがブロックされます。人間の承認が必要な場合のエスカレートレスポンスに使用。

ステータスが `escalated` の場合、呼び出し元は深刻度に関わらず進んではなりません。非ブロッキングの懸念は `findings` が付いた `approved` ステータスを使用します。

人間のエスカレーションは既存の AdCP HITL メカニズムと統合します。エスカレートされたアクションはプロトコルエンベロープで `input-required` ステータスを返し、人間が標準の `context_id` 継続で解決するまでオーケストレーターは一時停止します。

## 他のガバナンスドメインとの関係

キャンペーンガバナンスは既存のドメインと構成する — それらを重複させない:

| ドメイン                                                        | 関係                                                                                                               |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **[プロパティガバナンス](/docs/governance/property/index)**           | キャンペーンガバナンスはオーケストレーターがプロパティリストを正しく*使用*しているかを検証する（例: バイパスしていないか）。プロパティガバナンスがリストを提供します。                            |
| **[コンテンツスタンダード](/docs/governance/content-standards/index)** | キャンペーンガバナンスはコンテンツスタンダード参照がメディアバイに含まれていることを検証します。コンテンツスタンダードが実際のコンテンツ評価を処理します。                                    |
| **[クリエイティブガバナンス](/docs/governance/creative/index)**         | キャンペーンガバナンスはクリエイティブアサインメントがフォーマット要件と一致することを検証します。クリエイティブガバナンスがクリエイティブ自体をスキャンします。                                 |
| **[ブランドプロトコル](/docs/brand-protocol/index)**                 | キャンペーンガバナンスはブランドプロトコルを通じてブランドのコンプライアンス設定を解決します。ブランドのポリシーチームが brand.json にコンプライアンスポリシーを設定し、ガバナンスエージェントが自動的に適用します。 |

## 次のステップ

<CardGroup cols={3}>
  <Card title="安全モデル" icon="shield-check" href="/docs/governance/campaign/safety-model">
    三者信頼モデル、職務分離、構造的制御がエージェンティックな広告を安全にする仕組み。
  </Card>

  <Card title="仕様" icon="file-lines" href="/docs/governance/campaign/specification">
    データモデル、検証ロジック、ケイパビリティ宣言、オーケストレーター統合パターン。
  </Card>

  <Card title="タスク" icon="list-check" href="/docs/governance/campaign/tasks/index">
    タスクリファレンス: `sync_plans`、`check_governance`、`report_plan_outcome`、`get_plan_audit_logs`。
  </Card>
</CardGroup>
