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.

​

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

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

​

問題

AI エージェントがブリーフを解釈し、セラーを選び、メディアバイを交渉し、人間が見ていない中でライブにする — これが「ノーアイズ」問題だ: 自律エージェントが、購入が承認されたものと一致するかどうかの独立したチェックなしに実際の財務コミットメントを行います。 既存の AdCP ガバナンスドメインは、広告がどこに配信されるか（プロパティガバナンス）、どのコンテンツが隣接するか（コンテンツスタンダード）、どのクリエイティブが安全か（クリエイティブガバナンス）、ブランドが誰か（ブランドプロトコル）を解決します。しかしどれも何が購入されてなぜかを統治しません。 バイサイドにガバナンス層がないと:

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

キャンペーンガバナンスは3つのメカニズムでこのギャップを埋める: 何が許可されているかを定義するプラン（エージェントとは独立して）、バイヤーとは独立して購入を検証するセラーサイドのガバナンスチェック、コンプライアンスルールをガバナンスエージェント全体で標準化するポリシーレジストリ。 ガバナンスは3つの動作モードを通じた段階的な採用をサポートする: audit（すべてをログに記録し、絶対にブロックしない）、advisory（事後レビューのために問題にフラグを立てる）、enforce（違反時にブロックします）。組織は、執行を有効にする前に信頼を築くために audit モードで開始できます。

​

業界の先例

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

​

仕組み

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

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

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

​

職務分離

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

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

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

​

ポリシー解決

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

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

**ポリシーレジストリ**はコミュニティが管理する標準化された機械可読な広告コンプライアンスポリシーのライブラリだ — 管轄（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）、変更とデリバリーチェックを段階的に追加できます。完全なプロトコルは仕様を参照。 ガバナンスチェックを実装するセラーは競合優位を得る: 実行前に購入が独立して検証されたことをバイヤーに証明できます。これにより紛争リスクが減り、コンプライアンス検証が自動化され、厳格な監督要件を持つバイヤーに信頼を示します。

​

採用パス

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

​

小規模ブランドの場合

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

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

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

​

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

プランは、プランに対してどのエージェントが実行できるかをスコープする委任をサポートする — 権限レベル、予算制限、市場、有効期限で。ブランドはヨーロッパ市場向けに1つのエージェンシーに full 権限を、北米向けに別のエージェンシーに execute_only 権限を委任できます。 複数ブランドを管理するホールディングカンパニーの場合、ポートフォリオガバナンスはクロスブランドの制約を定義します: 総ポートフォリオ支出上限、共有ポリシー執行、個々のブランドプランが上書きできない企業レベルの除外。

​

信頼の発見

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

​

ドリフト検出

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

​

ライフサイクルフェーズ

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

​

検証カテゴリ

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

​

ステータス

すべてのガバナンスチェックは構造化されたステータスを返します: 結果の深刻度レベルは緊急性を示します:

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

ステータスが escalated の場合、呼び出し元は深刻度に関わらず進んではなりません。非ブロッキングの懸念は findings が付いた approved ステータスを使用します。 人間のエスカレーションは既存の AdCP HITL メカニズムと統合します。エスカレートされたアクションはプロトコルエンベロープで input-required ステータスを返し、人間が標準の context_id 継続で解決するまでオーケストレーターは一時停止します。

​

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

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

​

次のステップ