キャンペーンガバナンス仕様
ステータス: コメント募集中
最終更新: 2026年3月
このドキュメントのキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は RFC 2119 の説明に従って解釈されるべきです。
このドキュメントはキャンペーンガバナンスのデータモデル、検証ロジック、統合パターンを定義します。
キャンペーンプラン
キャンペーンプランはすべての検証の真実の源泉です。プランは sync_plans 経由でガバナンスエージェントにプッシュされ、キャンペーンのプランパラメーター — 予算制限、チャンネル、フライト日程、プラン市場 — を定義します。ガバナンスエージェントはブランドのコンプライアンス設定から適用可能なポリシーを解決します。プランは policy_ids でレジストリポリシーを直接参照したり、custom_policies でキャンペーン固有のルールを含めたりすることもできます。
{
"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",
"authority_level": "agent_limited",
"per_seller_max_pct": 40,
"reallocation_threshold": 25000
},
"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": ["No competitor brand adjacency"],
"approved_sellers": null,
"ext": {}
}
予算権限レベル
| レベル | 意味 |
|---|
agent_full | エージェントは人間の承認なしに総予算内で任意の支出を実行できる |
agent_limited | エージェントは閾値内で実行できるが、大きな変更(reallocation_threshold で定義)はエスカレートしなければなりません(MUST) |
human_required | すべての支出コミットメントに人間の承認が必要 |
チャンネルミックスターゲット
mix_targets フィールドは許容可能な配分範囲を定義します。ガバナンスエージェントはすべてのメディアバイにわたる累積支出がこれらの範囲内に収まることを検証します。動画支出を総予算の70%以上に押し上げる create_media_buy は conditions または escalated ステータスをトリガーします。
プランには delegations 配列を含めることができ、どのエージェントがプランに対して実行権限を持ち、どのような制約があるかを指定します。これにより、ブランドとエージェンシー間のプリンシパル・エージェント関係がプロトコルで明示的になります。
{
"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"
}
]
}
権限レベル:
| レベル | 意味 |
|---|
full | 委任の予算と市場の制約内で任意のアクションを実行できる |
execute_only | 事前承認されたアクションを実行できるが、新しいキャンペーンを開始したり予算を再配分したりできない |
propose_only | ガバナンスレビューのためにアクションを提案できるが、明示的な承認なしに実行できない |
委任が存在する場合、ガバナンスエージェントはアクションを承認する前に check_governance の caller URL が委任の agent_url と一致することを検証します。マッチングは正確な URI 比較(RFC 3986 に従って正規化後、大文字小文字を区別)で行われる。フランスでメディアバイをリクエストするエージェントは、markets にフランスを含む委任が必要です。execute_only 権限を持つエージェントはチャンネル間で予算を再配分できません。
委任が存在しない場合、ガバナンスエージェントはどのエージェントがプランに対して行動できるかを制限しません。
ポートフォリオガバナンス
ホールディングカンパニーやマルチブランド組織の場合、プランにはクロスブランド制約を定義する portfolio オブジェクトを含めることができます。ポートフォリオプランはメンバープランをガバナンスする — メンバープランに対して検証されたアクションは、ポートフォリオプランの制約に対しても検証されます。
{
"plan_id": "portfolio_q1_2026_global",
"brand": { "domain": "acmecorp.com" },
"objectives": "Global Q1 media governance across all Acme brands",
"budget": { "total": 50000000, "currency": "USD", "authority_level": "agent_limited" },
"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": [
"No advertising on properties owned by competitor holding companies"
]
}
}
ポートフォリオ制約:
total_budget_cap: すべてのメンバープランにわたる最大累積支出。ガバナンスエージェントはすべてのメンバープランにわたるコミット済み予算を追跡し、上限を超えるアクションを拒否します。
shared_policy_ids: 個々のブランドのコンプライアンス設定に関わらず、すべてのメンバープランに強制されるレジストリポリシー。いかなるブランドチームもオーバーライドできないコーポレートレベルの規制。
shared_exclusions: すべてのメンバープランに適用される自然言語除外ルール。
ガバナンスエージェントはメンバープランのアクションをメンバープラン固有の制約とポートフォリオプランの制約の両方に対して検証します。いずれかのレベルからの拒否がアクションをブロックします。
ポートフォリオプランがガバナンスエージェントにまだ認識されていない member_plan_id を参照している場合、ガバナンスエージェントはポートフォリオプランを受け入れ、メンバープランが同期されるにつれてポートフォリオ制約の強制を開始すべきだ(SHOULD)。これにより、ポートフォリオプランをメンバープランより先に同期できます。
並行性: オーケストレーターは複数のセラーに同時に create_media_buy リクエストを送信することがあり、それぞれが committed チェックをトリガーします。予算チェックはポイントインタイムで予算を予約しないため、同時に承認が行われると合計でプラン予算を超える可能性があります。ガバナンスエージェントは結果報告時に超過支出を検出します。同時超過支出を防ぐには、委任をエージェントごとの budget_limit と共に使用して、実行エージェント間で予算を分割します。
ブランドコンプライアンス設定
コンプライアンスポリシーは個々のキャンペーンプランではなく、ブランドレベルに存在します。ブランドのポリシーチームがブランドのコンプライアンスプロファイルを設定し、ガバナンスエージェントはそのブランドのプランを処理する際にそれを解決します。
ブランドコンプライアンス設定のスキーマとホスティングメカニズムは AgenticAdvertising.org ガバナンスワーキンググループが開発中です。以下は概念モデルを説明するものであり、実装は異なる場合があります。
ブランドのコンプライアンス設定には2種類のポリシーが含まれます:
- レジストリポリシー: ID で識別される AdCP ポリシーレジストリの標準化されたポリシーへの参照。各参照にはブランド向けにポリシーをカスタマイズする設定パラメーターを含めることができる(MAY)。
- カスタムポリシー: 自然言語文字列として表現されたブランド固有のルール。プロンプトベースポリシーと同じアプローチでガバナンスエージェントが評価します。
ポリシーチームはブランドに適用するレジストリポリシーを選択し、必要に応じてパラメーターを設定し、ブランド固有のカスタムポリシーを追加します。バイイングチームはこの設定に一切関与しない — ブランドを参照するキャンペーンプランを作成し、ガバナンスエージェントが適用可能なポリシーを自動的に解決します。
ブランドの業種は自動ポリシーマッチングに役立つ — たとえば、飲料業界のブランドはその業種にタグ付けされたレジストリポリシーを受け取ります。
ポリシーレジストリ
ポリシーレジストリは、標準化された機械可読な広告コンプライアンスポリシーのコミュニティメンテナンスライブラリです。ブランドは独自のポリシーを書く代わりに ID でポリシーを参照します。
レジストリは3つのカテゴリをカバーする:
| カテゴリ | 例 |
|---|
| 管轄 | 英国 HFSS 規制、米国 COPPA、EU GDPR 年齢制限、カリフォルニア AI 開示(SB 942) |
| 業種 | アルコール年齢確認、製薬フェアバランス、ギャンブル自己排除、金融サービス APR 開示 |
| ブランドセーフティ | ブランドセーフティベースライン、コンテンツスータビリティ層 |
レジストリの各ポリシーには ID、適用可能な管轄、説明、ガバナンスエージェントがプログラム的に評価できる機械可読ルールがあります。ポリシーは規制の変化に応じてバージョン管理される; ブランド参照は特定のバージョンにピン留めすることができ(MAY)、バージョン指定のない参照は現在のバージョンに解決されます。レジストリの形式とホスティングメカニズムは AgenticAdvertising.org ガバナンスワーキンググループが開発中です。
このモデルは IEEE 7012(機械可読個人プライバシー条件)によって確立されたパターンに従う。IEEE 7012 は各自が個別に起草するのではなく参照できる標準化された合意の中立的なロスターを維持します。
ポリシー解決
ポリシーはプランの 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 など)は引き続きプランのパラメーターに基づいて適用されます。
オーディエンスガバナンス
キャンペーンプランはオーディエンスターゲティング制約、制限属性、ポリシーカテゴリを宣言します。ガバナンスエージェントはこれらを使ってセラーのターゲティングが規制要件とキャンペーン意図に準拠していることを検証します。
三層モデル
オーディエンスガバナンスは3つの問題を分離する:
| 層 | フィールド | 目的 | 例 |
|---|
| アイデンティティ | brand.industries | 企業が何をするか | ["pharmaceuticals", "consumer_packaged_goods"] |
| 規制レジーム | plan.policy_categories | このキャンペーンにどの規制が適用されるか | ["pharmaceutical_advertising", "health_wellness"] |
| データ制限 | plan.restricted_attributes | ターゲティングに使用できない個人データ | ["health_data"] |
製薬会社は常に製薬(アイデンティティ)だが、一般認知キャンペーンは製薬広告規制(レジーム)をトリガーしないかもしれない。EU 管轄のキャンペーンのみがヘルスデータターゲティングを制限するかもしれない(制限)。
オーディエンス制約
プランはオーディエンスセレクターを使って audience.include と audience.exclude 配列を宣言できます。各セレクターはシグナル参照(特定のデータプロバイダーシグナルへの参照)または自然言語の説明のいずれかです。
ガバナンスエージェントは check_governance でセラーのターゲティングをこれらの制約に対して評価する:
planned_delivery.audience_targeting をプランの audience.include/exclude と比較します
planned_delivery.audience_targeting を同じ制約と比較する(committed チェックの場合)
- オーケストレーターがリクエストしたものとセラーがアクティブにするものの間の乖離を検出します
構造的ガバナンスマッチング
シグナル定義は restricted_attributes と policy_categories を自己宣言できます。そうする場合、ガバナンスエージェントは構造的マッチング — プランの制限とシグナルの宣言の間の集合積 — を実行します。これは決定論的で LLM 推論を必要としません。
ガバナンスメタデータを宣言していないシグナルの場合、ガバナンスエージェントはシグナル名と説明から感度を推論するセマンティックマッチングにフォールバックします。構造的マッチングはセマンティックマッチングよりも高い信頼度の検出事項を生成します。
制限属性は include と exclude ターゲティングの両方に適用されます。除外に制限データを使うこと(たとえば製薬広告から健康状態を持つ人を除外すること)は、inclusion に使うことと同様に禁止されている — 両方ともターゲティング決定への制限された個人データの使用に相当します。
オーディエンス分布ドリフト
配信中、セラーは delivery_metrics で audience_distribution を報告します。インデックス値は宣言されたベースライン(国勢調査、プラットフォーム、またはカスタム)に対する人口統計構成を示します。1.0 はパリティを意味し、大きく上下する値はスキューを示します。
ガバナンスエージェントはすべてのレポート期間にわたって期間ごとのインデックスと累積インデックスの両方を追跡します。これにより、単一のレポート期間では見えないかもしれない体系的なバイアスの検出が可能になります。
状態追跡
ガバナンスエージェントは2つのレベルで状態を追跡する:
- プランレベル: コミット済み総予算、チャンネル配分率、プランステータス
- キャンペーンレベル:
governance_context ごとのコミット済み予算、アクティブなメディアバイの参照、検証履歴
単一のプランは複数のキャンペーンにわたることができます。check_governance が予算権限をチェックする際、プランに紐付けられたすべてのキャンペーンを考慮します。report_plan_outcome がセラーの確認を報告する際、ガバナンスエージェントはリクエストされた金額ではなくセラーの実際の金額から予算をコミットします。
プランステータス
| ステータス | 意味 |
|---|
active | 検証リクエストと結果報告を受け付けている |
suspended | 重大なエスカレーションの人間レビューを待ちながら一時停止中 |
completed | プラン終了; 読み取り専用 |
ステータスが suspended の場合、ガバナンスエージェントはエスカレーションが解決されるまで CAMPAIGN_SUSPENDED エラーですべての check_governance と report_plan_outcome リクエストを拒否しなければなりません(MUST)。
予算追跡
予算は検証されたアクションではなく確認済みの結果に基づいてコミットされます。フロー:
binding: "proposed" の check_governance は提案された支出がプランに収まるかどうかをチェックします。予算はまだコミットされない。
- オーケストレーターはセラーとアクションを実行します。
report_plan_outcome がセラーの確認済み金額を報告します。ガバナンスエージェントはこの金額をプラン予算にコミットします。
これにより予算追跡が現実を反映することが保証されます。セラーが予算を150Kから120K に削減した場合、ガバナンスエージェントは 120Kをコミットし、差異に関する検出事項を返します。アクションが完全に失敗した場合、ガバナンスエージェントは0 をコミットします。
committed の承認はセラーの計画された配信をプランに対して検証するが、予算はコミットしません。予算がコミットされるのは、オーケストレーターがセラーの確認済みレスポンスで report_plan_outcome を呼び出す時のみです。
予算チェックはポイントインタイムだ: check_governance は現在のコミット済み総額に対して検証するが予算を予約しません。複数のエージェントが同じプランに対して並行して実行する場合、2つのチェックが両方パスし、合計の結果が認可予算を超える可能性があります。ガバナンスエージェントは結果報告時に超過支出を検出し、budget_authority 検出事項を返します。同時超過支出を防ぐには、エージェントごとの budget_limit と共に委任を使用して、実行エージェント間で予算を分割します。
ドリフト検出
監査ログにはプランのライフタイムにわたる集計ガバナンストレンドを表示する drift_metrics が含まれます:
{
"summary": {
"checks_performed": 847,
"drift_metrics": {
"escalation_rate": 0.03,
"escalation_rate_trend": "declining",
"auto_approval_rate": 0.91,
"human_override_rate": 0.02,
"mean_confidence": 0.88
}
}
}
これらのメトリクスは監視ドリフト — 人間からの制御の段階的な移行 — を検出します。エスカレーション率の低下は、ガバナンスエージェントが適切にキャリブレーションされていることを示すかもしれない、あるいは監視が侵食されていることを示すかもしれない。トレンドを表示することで、組織がその判断を行えるようにします。
| メトリクス | 測定内容 |
|---|
escalation_rate | エスカレーションに至ったチェックの割合 |
escalation_rate_trend | プランのライフタイムにわたる方向(increasing、stable、declining) |
auto_approval_rate | 人間の介入なしに承認されたチェックの割合 |
human_override_rate | 人間がガバナンスエージェントをオーバーライドしたエスカレーションの割合 |
mean_confidence | 検出事項にわたる平均信頼スコア(信頼度が報告される場合) |
組織はドリフトメトリクスに閾値を設定できます。メトリクスが閾値を超えると、ガバナンスエージェントは次のガバナンスチェックに検出事項(重大度 warning)を含めるべきだ(SHOULD):
{
"drift_metrics": {
"escalation_rate": 0.01,
"escalation_rate_trend": "declining",
"auto_approval_rate": 0.97,
"thresholds": {
"escalation_rate_min": 0.02,
"auto_approval_rate_max": 0.95
}
}
}
この例では、両方の閾値が破られている — エスカレーション率(0.01)が最小値(0.02)を下回り、自動承認率(0.97)が最大値(0.95)を超えています。これはガバナンスエージェントが過度に広く承認していることを示すかもしれない、あるいはリスクの低いキャンペーンに対してポリシーが適切にキャリブレーションされていることを示すかもしれない。閾値の破れは問いを表面化させる; 組織が答えを決定します。
組織は自身の懸念に関連する閾値のみを設定します。escalation_rate_min は監視の侵食を捕捉し; escalation_rate_max はポリシーの誤キャリブレーションを捕捉します。human_override_rate_max は推奨が一貫して間違っているガバナンスエージェントを捕捉します。すべての閾値フィールドはオプションです。
プラン修正
既存の plan_id で sync_plans を呼び出すとプランが更新されます(upsert)。ガバナンスエージェントは plan_version をインクリメントし、新しいパラメーターを直ちに適用します。以前のプランバージョンの下で承認されたアクティブなメディアバイは自動的に再検証されない — ガバナンスエージェントは次の check_governance 呼び出し(例: 次の配信チェック)でそれらを更新されたプランに対して評価します。修正によって予算が現在のコミット済み金額を下回る場合、ガバナンスエージェントは次のガバナンスチェックでこれを検出事項としてフラグします。
検証ロジック
ガバナンスエージェントは各検証カテゴリを独立して評価する:
- いずれかのカテゴリでステータスが
failed で、失敗が修正可能な場合、提案された修正を含む conditions ステータス
- いずれかのカテゴリでステータスが
failed で、失敗が呼び出し元によって修正できない場合、denied ステータス
- すべてのカテゴリがパスするが、全体的なリスクプロファイルが人間のレビューを要件とする場合、
escalated ステータス
- すべてのカテゴリがパスする場合、
approved ステータス
conditions 配列はステータスが conditions の場合にのみ存在します。各条件は特定のフィールド、その現在の値、提案された値、変更の理由を識別します。
検出事項の信頼度
ガバナンスの検出事項にはオプションの confidence スコア(0-1)と uncertainty_reason が含まれ、確実な違反と曖昧なものを区別する:
{
"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)。
フェーズ推論
ガバナンスエージェントは check_governance の tool パラメーターから検証フェーズを推論する:
| tool | フェーズ |
|---|
get_products | ディスカバリー — 検索意図、セラー適格性、製品適性を検証する |
create_media_buy | 購入 — 予算権限、ターゲティングコンプライアンス、フライト日程を検証する |
update_media_buy | 購入 — 変更の大きさ、再配分閾値を検証する |
フェーズコンテキストは累積します。購入中、ガバナンスエージェントはディスカバリー中に発見されたものを考慮します。
check_governance が返す check_id は、report_plan_outcome がセラーのレスポンスを検証されたアクションにリンクするために使用します。
ケイパビリティ宣言
ガバナンスエージェントは get_adcp_capabilities でキャンペーンガバナンスのサポートを宣言する:
{
"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."
}
]
}
}
}
バイヤーは create_media_buy リクエストに plan_id を含め、プロトコルエンベロープに governance_context を含めます。これらのフィールドはセラーにどのガバナンスプランが適用されるかを伝え、セラーサイドのガバナンスチェックを可能にします。
{
"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 が含まれる — セラーが実際に実行するもの:
{
"media_buy_id": "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つの目的を果たす:
- ガバナンスチェック — アカウントに
governance_agents がある場合、セラーはメディアバイを確認する前に planned_delivery をガバナンスエージェントに送信して検証します。
- 透明性 — バイヤーは配信が始まる前に早期に差異を発見するために、
planned_delivery をリクエストしたものと比較できます。
ガバナンスチェック
キャンペーンガバナンスのバイヤーサイド検証には信頼の限界がある: バイヤーのオーケストレーターが自分の宿題を採点します。LLM エージェントはガバナンス承認を幻覚したり、検証をスキップしたり、検証されたものを偽って表現したりする可能性があります。セラーサイドのガバナンスチェックは、セラーが購入が承認されているかどうかを独立して確認する方法を提供することでこのギャップを閉じる。
セラーはメディアバイイベントが発生した際、バイヤーの governance_agents URL に POST します。ガバナンスエージェントはすべての状態を維持し、plan_id + media_buy_id でリクエストを相関させる — セラーは呼び出し間でガバナンス履歴を追跡したり ID をチェーンしたりする必要はない。
セットアップ
バイヤーはセラーとアカウントを同期する際に governance_agents を登録します。各エージェントには、ガバナンスエージェントがセラーの身元を確認できる認証クレデンシャルが含まれます:
{
"tool": "sync_accounts",
"arguments": {
"accounts": [
{
"brand": { "domain": "acmecorp.com" },
"operator": "pinnacle-media.com",
"billing": "operator",
"governance_agents": [
{
"url": "https://governance.pinnacle-media.com",
"authentication": {
"schemes": ["Bearer"],
"credentials": "gov_token_acme_pinnacle_2026_xyz..."
}
}
]
}
]
}
}
セラーはこれらのエンドポイントを保存し、check_governance を呼び出す際にクレデンシャルを提示します。ガバナンスエージェントは Bearer トークンが plan_id に関連するアカウントの登録済みクレデンシャルと一致することを確認しなければならず(MUST)、認識されないまたは不一致のクレデンシャルのリクエストを拒否しなければなりません(MUST)。
ガバナンスモード
ガバナンスエージェントの動作モードは sync_plans の mode フィールドでプランごとに設定でき、デフォルトは enforce。モードは sync_accounts でセラーに公開されない — セラーは check_governance を呼び出してレスポンスステータスに従って行動します。ガバナンスエージェントが audit、advisory、または enforce モードにあるかどうかを知る必要はない。これにより、モード変更時のアカウント再同期が不要になり、セラーがモードに基づいて動作を調整することを防ぐ。
| モード | 動作 | ユースケース |
|---|
audit | すべてのチェックをログに記録します。決してブロックしない — 検出事項を添付して常に approved を返します。 | 初期展開。ライブキャンペーンを中断せずにガバナンスが何をフラグするかを確認します。 |
advisory | 実際のステータス(denied、conditions、escalated)で検出事項を返すが、実行をブロックしません。 | 事後的な人間のレビュー。ガバナンスエージェントが意見を表明し、人間がそれに従って行動します。 |
enforce | denied または escalated でブロックします。進む前に解決を要求します。 | 本番ガバナンス。デフォルト。 |
デフォルトは enforce。組織は enforcement を有効にする前にガバナンスエージェントのキャリブレーションに対する信頼を構築するために audit モードから始めることができます。
audit モードでは、ガバナンスエージェントは完全な評価を実行して検出事項を返す — 唯一の違いはステータスが常に approved であること。これにより、組織が本番稼働前に偽陽性率を評価してポリシーをキャリブレーションするためにレビューできる完全な監査証跡が生成されます。
advisory モードでは、ガバナンスエージェントは enforcement 下で返すはずだったステータスを返します。チェックレスポンスには mode フィールドが含まれるので、監査人は「advisory モードで拒否(アクションは進んだ)」と「enforce モードで拒否(アクションはブロックされた)」を区別できます。
すべてのモードで、委任違反、クレデンシャルの不一致、その他の認可チェックは検出事項としてログに記録されます。audit と advisory モードでは、これらの検出事項はアクションをブロックしない — レビューのために記録されます。enforce モードでのみ認可違反がブロックされます。
ガバナンスコンテキスト
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)、ガバナンス状態のプレーンテキストエンコーディングとして扱うべきではありません。状態が直接エンコードされる場合、中間者による改ざんが検出可能なように署名(例: HMAC)されなければなりません(MUST)。
ガバナンスフェーズ
ガバナンスチェックは3つのフェーズを通じてメディアバイライフサイクル全体をカバーする:
| フェーズ | トリガー | 検証内容 |
|---|
purchase | create_media_buy | 予算、ジオ、チャンネル、フライト日程、ポリシー |
modification | update_media_buy | 変更の大きさ、再配分、新しいパラメーター |
delivery | 定期的(セラー開始) | ペーシング、消化率、ジオドリフト、チャンネル分配 |
省略された場合の phase フィールドのデフォルトは purchase なので、既存の実装は変更なしで動作し続ける。
ガバナンスエージェントはすべての状態を維持し、plan_id + media_buy_id でリクエストを相関させる。セラーはチェック ID をチェーンしたり会話履歴を追跡したりしない — 何が起きたかをポストし、ガバナンスエージェントがコンテキストを調べる。
購入フェーズ
セラーが governance_agents を持つアカウントで create_media_buy リクエストを受け取った場合:
- セラーはリクエストを解釈して
planned_delivery を決定します。
- セラーは
phase: "purchase"、plan_id、planned_delivery で check_governance を呼び出す。
- ガバナンスエージェントは計画された配信をキャンペーンプランに対して検証します。
approved なら、セラーはメディアバイを確認します。
denied なら、セラーは GOVERNANCE_DENIED エラーでメディアバイを拒否します。
conditions なら、セラーは条件を満たすように計画された配信を調整して再検証するか、拒否します。
変更フェーズ
セラーが update_media_buy リクエストを受け取った場合:
- セラーは更新を解釈して新しい
planned_delivery を決定します。
- セラーは
phase: "modification"、更新された planned_delivery、modification_summary で check_governance を呼び出す。
- ガバナンスエージェントは
plan_id + media_buy_id でメディアバイを調べ、プランに対して変更を評価します。
approved なら、セラーは更新を確認します。
denied または conditions なら、セラーは購入フェーズと同じフローに従う。
ガバナンスエージェントは最初の購入とは異なるロジックを変更に適用できます。たとえば、reallocation_threshold 内の小さな予算増加は自動承認されるかもしれないが、大きな予算増加や新しいジオ市場はより厳格な審査を必要とするかもしれない。
配信フェーズ
セラーはアクティブな配信中に 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)。
検証例
購入リクエスト:
{
"tool": "check_governance",
"arguments": {
"plan_id": "plan_q1_2026_launch",
"binding": "committed",
"caller": "https://seller.example.com",
"media_buy_id": "mb_seller_456",
"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"]
}
}
}
承認(購入 + 配信オプトイン):
{
"check_id": "auth_001",
"status": "approved",
"binding": "committed",
"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 フィールドはガバナンスエージェントが配信レポートを期待していることを示します。存在しない場合、配信レポートは期待されない。
拒否(購入):
{
"check_id": "auth_002",
"status": "denied",
"binding": "committed",
"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"]
}
}
]
}
承認(配信):
{
"check_id": "auth_004",
"status": "approved",
"binding": "committed",
"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"
}
アカウントに governance_agents が存在する場合、セラーはいかなるメディアバイを確認する前にも check_governance を呼び出さなければなりません(MUST)。バイヤーは購入が独立して検証されるために特別にエンドポイントを提供した — スキップすることは目的を台無しにします。
governance_agents が存在しない場合、セラーはメディアバイリクエストを通常通り処理します。バイヤーサイドのガバナンスループ(check_governance(binding: proposed) → 実行 → report_plan_outcome)は引き続き適用されるが、セラーサイドの検証はない。
セラーはすべてのアカウントの前提条件としてガバナンスチェックを要求してはなりません(MUST NOT)。governance_agents を持たないアカウントからのメディアバイの処理を拒否するセラーは、キャンペーンガバナンスを使用しないバイヤーとの相互運用性を損なう。
delivery フェーズは purchase フェーズのガバナンスが使用されている場合でもオプションです。セラーは継続的な配信レポートなしに購入承認をサポートすることがある(MAY)。ガバナンスエージェントは購入レスポンスの next_check の有無によって配信レポートを期待するかどうかを示します。
ガバナンスエージェントが到達不可能(タイムアウト、ネットワークエラー)の場合、セラーはメディアバイを進めてはなりません(MUST NOT)。ガバナンスチェックは governance_agents が登録されたアカウントでの購入確認の前提条件です。セラーは短い遅延後にチェックをリトライすべきであり(SHOULD)、エージェントが引き続き到達不可能な場合は GOVERNANCE_UNAVAILABLE エラーでメディアバイを拒否します。
オーケストレーターがセラーから GOVERNANCE_UNAVAILABLE を受け取った場合、遅延後に create_media_buy をリトライすべきだ(SHOULD)。ガバナンスエージェントが利用不可能なままの場合、オーケストレーターは代替セラーを試みるのではなく人間にエスカレートすべきだ(SHOULD) — ガバナンス障害は同じアカウントのすべてのセラーに影響します。オーケストレーターからの事前の proposed 承認はセラーの committed チェックの代替にはならない; セラーは独立して検証し、オーケストレーターの承認を使用できません。
パフォーマンス期待値
ガバナンスエージェントの実装は proposed チェックに対して5秒以内、committed チェックに対して10秒以内に check_governance 呼び出しに応答すべきだ(SHOULD)。セラーは適切なタイムアウトを設定し、タイムアウトを利用不可能と同様に扱うべきだ(SHOULD)(リトライ、その後 GOVERNANCE_UNAVAILABLE で拒否)。
ワイヤーフォーマット
セラーは登録された URL で MCP over HTTP(Streamable HTTP トランスポート)を使用して各ガバナンスエージェントを呼び出す。リクエストはツール名 check_governance とリクエスト引数をツール入力とした MCP tools/call 呼び出しです。認証は Authorization ヘッダーのエージェントの authentication.credentials からの Bearer トークンを使用します。
マルチエージェント構成
アカウントは sync_accounts の governance_agents 配列を通じて複数のガバナンスエージェントを登録することがある(MAY)。それぞれが異なる検証カテゴリを担当します。たとえば、1つのエージェントが予算権限と戦略的整合性を担当し、別のエージェントが規制コンプライアンスとブランドポリシーを担当します。
複数のガバナンスエージェントが登録されている場合、セラーは検証されるアクションに categories が重なる各エージェントを呼び出さなければなりません(MUST)。アクションが進むためにはすべての適用可能なエージェントが承認しなければなりません(全員一致の承認)。いずれかのエージェントが denied または escalated を返した場合、アクションはブロックされます。
単一のガバナンスエージェントを持つアカウントの場合、1要素の配列を渡します。
ガバナンスチェックとガバナンスループ
ガバナンスチェックはバイヤーサイドのガバナンスループを補完するものであり、代替するものではない:
| 問題 | バイヤーサイド(check_governance、binding: "proposed") | セラーサイド(check_governance、binding: "committed") |
|---|
| チェックする主体 | バイヤーのガバナンスエージェント、オーケストレーターが呼び出す | バイヤーのガバナンスエージェント、セラーが呼び出す |
| タイミング | バイヤーがリクエストを送信する前 | 確認前、更新時、配信中 |
| 検証内容 | バイヤーの意図したアクション | セラーの計画された実際の配信 |
| 信頼モデル | 自己証明 | 独立して検証 |
| 予算追跡 | あり(プラン状態) | ガバナンスエージェントが状態を維持 |
| 継続的監視 | report_plan_outcome 経由 | delivery フェーズ経由 |
delivery フェーズはガバナンスエージェントにセラーが実際に配信しているものへのリアルタイムの可視性を与えます。バイヤーサイドの report_plan_outcome はオーケストレーターが正直に報告することに依存する; delivery フェーズはセラーから直接レポートを得ます。
バイヤーサイドとセラーサイドのガバナンスチェックは同じエージェントまたは別々のエージェントによって処理されることがある(MAY)。プロトコルは関係を規定しない — セラーがアカウントに登録された governance_agents URL を呼び出せることのみを要求します。
オーケストレーター統合パターン