AdCP — ガバナンス監査証跡

プロトコルは、バイヤーが相手方と何を共有しなければならないかを義務付けません。しかし同じ監査証跡の 2 つの異なるビューを生成するプリミティブを与えます:

内部ビュー — すべてのチェック、発見、予算移動、人間レビューのバイヤーの完全な記録。自己防衛、規制当局監査、内部コンプライアンスレビューに使われる。
共有可能ビュー — 1 つの相手方（セラー、エージェンシー、第三者監査人）に宛てられたスコープされたサブセット。その当事者が自身のアクションを検証するために必要なものだけを明かす。

両方とも get_plan_audit_logs から生成されます。分割はフィルタリングとフィールド選択の問題であり、別のプロトコルではありません。

そもそもなぜ分割するか

バイヤーが異なるビューを維持する 3 つの理由:

戦略リーク。 すべてのセラー全体の合計承認予算、チャネル配分、残ヘッドルームは競争シグナルです。派生した比率は生の金額より安全ではないことに注意 — budget.utilization_pct は、セラーが自身のコミット済みシェアを知っている場合、1 ステップの逆問題です。単一のセラーは自身のバイを検証するためにバイヤーの完全なプランを知る必要はありません。
相手方間分離。 セラー A はセラー B の発見、ガバナンスコンテキスト、結果を見る必要はありません。共有可能ビューは常にリクエスト当事者の governance_context 値にスコープされます。
内部レビューフィールド。 人間レビュー理由、ドリフトメトリック、監督しきい値はバイヤー自身のガバナンス姿勢です。それらは規制当局監査でバイヤーを保護します。それらは相手方に宛てられていません。

フィールドタグ付け

以下のテーブルは、get_plan_audit_logs レスポンスのすべてのフィールドを、誰が安全に見られるかで分類します。

Field	Internal	特定セラーと共有可能	規制当局/監査人と共有可能
`plans[].plan_id`, `plan_version`	yes	yes（スコープ時）	yes
`plans[].status`	yes	yes（スコープ時）	yes
`plans[].budget.authorized`	yes	no	yes
`plans[].budget.committed`	yes	no	yes
`plans[].budget.remaining`	yes	no	yes
`plans[].budget.utilization_pct`	yes	no	yes
`plans[].channel_allocation.*`	yes	no	yes
`plans[].governed_actions[].governance_context`	yes	yes（自身のコンテキストのみ）	yes
`plans[].governed_actions[].purchase_type`	yes	yes（自身のコンテキストのみ）	yes
`plans[].governed_actions[].status`	yes	yes（自身のコンテキストのみ）	yes
`plans[].governed_actions[].committed`	yes	yes（自身のコンテキストのみ）	yes
`plans[].governed_actions[].check_count`	yes	yes（自身のコンテキストのみ）	yes
`plans[].summary.checks_performed`, `outcomes_reported`	yes	no	yes
`plans[].summary.statuses`	yes	no	yes
`plans[].summary.findings_count`	yes	no	yes
`plans[].summary.human_reviews[]`	yes	no	理由を編集除去。リクエスト時に解決 + タイムスタンプを共有
`plans[].summary.drift_metrics.*`	yes	no	バイヤーの相手方ルールが開示を要求する場合に利用可能
`plans[].entries[].id`, `type`, `timestamp`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].caller`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].tool`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].check_type`, `verdict`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].mode`	yes	yes（自身のコンテキストのみ）	yes — `audit` 下で `denied` を `approved`-with-finding から区別
`plans[].entries[].explanation`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].categories_evaluated`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].policies_evaluated`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].findings[]`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].plan_hash`	yes	yes（自身のコンテキストのみ）	yes — 監査人がこれを検証
`plans[].entries[].governance_context`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].purchase_type`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].outcome`, `outcome_status`	yes	yes（自身のコンテキストのみ）	yes
`plans[].entries[].committed_budget`	yes	yes（自身のコンテキストのみ）	yes

共有可能ビューの生成

「セラー X と何を共有すべきか?」に答えるには、監査クエリをそのセラーに属するコンテキストにフィルターし、プランレベルの集計を落とします。 1 つのセラーのアクションにスコープされたリクエスト:

{
  "tool": "get_plan_audit_logs",
  "arguments": {
    "plan_ids": ["plan_q1_2026_launch"],
    "governance_contexts": ["gc_mb_seller_456"],
    "include_entries": true
  }
}

これは governed_actions と entries をリクエストされたコンテキストに絞ります。バイヤーは依然として転送前に budget.*、channel_allocation.*、summary.findings_count、summary.statuses、summary.drift_metrics を除去する責任があります — それらのサマリーはプラン全体をカバーし、他のセラー全体の合計を明かします。 最小コンプライアンス証明（エントリーなし）: バイが統制されたことの証明のみを必要とする相手方には — 完全な証跡ではなく — 監査レスポンスから導出された 4 フィールドの証明を共有します:

{
  "governance_context": "gc_mb_seller_456",
  "verdict": "approved",
  "plan_hash": "oR0jFDEtzcwgPbNf-Ofd_fZHYfAyD1TRbzGOFBVCG-c",
  "policies_evaluated": ["us_coppa", "alcohol_advertising"]
}

セラーは plan_hash を彼らが署名したプランリビジョンに対して検証でき、policies_evaluated リストはどのレジストリポリシーが適用されたかを確認します。バイヤーのポートフォリオについて他は何も開示されません。

規制当局と監査人のビュー

規制当局は通常 3 つのうちの 1 つを求めます:

必要な場所で人間の監督が起こったか? 解決されたポリシーからの summary.human_reviews[] と requires_human_review フラグを共有。理由は編集除去または要約されてもよい。解決とタイムスタンプは無傷であるべき。
バイは特定の規制に準拠したか? 規制の policy_id（例: us_coppa）を含む policies_evaluated でスコープされたエントリーを共有。規制当局がプランリビジョンに対して検証できるよう plan_hash を含める。
監督メトリックはしきい値内か? summary.drift_metrics とポリシー導出のしきい値を共有。human_review_rate_min を下回る human_review_rate は説明する価値のあるシグナル。

プロトコルは規制当局 API を定義しません。相手方ルールが開示を統制します。監査証跡が開示を可能にします。

実例: クリーンなバイ

OLV/ディスプレイキャンペーンに

500K 承認されたプラン。オーケストレーターは `get_products` で意図チェックを実行し、次に

150K の create_media_buy で実行チェック、次に結果を報告します。完全な内部監査レスポンス:

{
  "$schema": "/schemas/governance/get-plan-audit-logs-response.json",
  "status": "completed",
  "plans": [
    {
      "plan_id": "plan_q1_2027_acme",
      "plan_version": 1,
      "status": "active",
      "budget": {
        "authorized": 500000,
        "committed": 150000,
        "remaining": 350000,
        "utilization_pct": 30
      },
      "governed_actions": [
        {
          "governance_context": "11ab64d0-2e20-4b62-8964-b024cfc98d36",
          "purchase_type": "media_buy",
          "status": "active",
          "committed": 150000,
          "check_count": 1
        }
      ],
      "summary": {
        "checks_performed": 2,
        "outcomes_reported": 1,
        "statuses": { "approved": 2, "denied": 0, "conditions": 0 },
        "findings_count": 0
      },
      "entries": [
        {
          "id": "chk_378be2f1",
          "type": "check",
          "timestamp": "2027-01-15T14:32:41.008Z",
          "caller": "https://ads.seller-a.example",
          "tool": "create_media_buy",
          "check_type": "execution",
          "mode": "enforce",
          "purchase_type": "media_buy",
          "governance_context": "11ab64d0-2e20-4b62-8964-b024cfc98d36",
          "verdict": "approved",
          "explanation": "All governance checks passed.",
          "policies_evaluated": [],
          "categories_evaluated": ["delegation_authority"],
          "findings": []
        },
        {
          "id": "out_9b2c1f04",
          "type": "outcome",
          "timestamp": "2027-01-15T14:32:41.105Z",
          "outcome": "completed",
          "committed_budget": 150000,
          "purchase_type": "media_buy",
          "governance_context": "11ab64d0-2e20-4b62-8964-b024cfc98d36"
        }
      ]
    }
  ]
}

同じ証跡のセラーの共有可能ビューは、governed_actions[] エントリーと governance_context = 11ab64d0... にフィルターされた entries[] です。プランレベルの budget.authorized、budget.remaining、summary 集計はバイヤー側に留まります。

違反がどう見えるか

発見は監査証跡がリスクを伝える方法です。知る価値のある 2 つのパターン:

セキュリティ形状の発見: 認可されていないセラー

プランは approved_sellers: ["https://ads.seller-approved.example"] を宣言します。別のセラーが check_governance を呼び拒否されます:

{
  "$schema": "/schemas/governance/check-governance-response.json",
  "check_id": "chk_0ac8d7de",
  "plan_id": "plan_2027_apex_athletic",
  "verdict": "denied",
  "explanation": "Denied: Caller https://ads.seller-rogue.example is not in the plan's approved sellers list.",
  "categories_evaluated": ["delegation_authority", "seller_compliance"],
  "policies_evaluated": [],
  "findings": [
    {
      "category_id": "seller_compliance",
      "severity": "critical",
      "explanation": "Caller https://ads.seller-rogue.example is not in the plan's approved sellers list."
    }
  ]
}

対応するプランサマリーは statuses.denied: 1 と findings_count: 1 を記録します。認可されていないセラーの governance_context は依然として記録されます — 証跡は成功だけでなく試みを捕捉します。

コーチング形状の発見: Annex III 前提条件が欠けている

policy_categories: ["fair_lending"]（住宅ローン、消費者信用など）を持つプランは human_review_required: true を自動反転します。ブランドプロフィールが異議申立連絡先を公開しない場合、チェックは実行可能な説明とともにフェイルクローズします:

{
  "$schema": "/schemas/governance/check-governance-response.json",
  "check_id": "chk_8360a36d",
  "plan_id": "plan_2027_nova_mortgage",
  "verdict": "denied",
  "explanation": "Denied: Plan requires human review (Annex III / Art 22) but brand does not expose data_subject_contestation. Art 22(3) requires a discoverable contact point for the data subject to request human intervention, express their view, and contest the decision. Set brand.data_subject_contestation in brand.json.",
  "categories_evaluated": ["data_subject_contestation", "delegation_authority"],
  "policies_evaluated": [],
  "findings": [
    {
      "category_id": "data_subject_contestation",
      "severity": "critical",
      "explanation": "Plan requires human review (Annex III / Art 22) but brand does not expose data_subject_contestation. Set brand.data_subject_contestation in brand.json."
    }
  ]
}

拒否はまたコーチングの瞬間です — オペレーターは何を修正すべきかを正確に見ます。これは良いガバナンス発見が取るべき形状です: カテゴリー、重大度、前進の道。

オペレーターのダイヤル: enforce / advisory / audit

mode は sync_plans 経由でプランに設定され、オペレーターの主要なレバーです。同じ呼び出し元、同じペイロード、同じ発見が、モードに応じて 3 つの異なる結果を生成します。 mode: "enforce" — バイはガバナンス層でブロックされます:

{
  "$schema": "/schemas/governance/check-governance-response.json",
  "check_id": "chk_enforce_001",
  "plan_id": "plan_mode_enforce",
  "verdict": "denied",
  "explanation": "Denied: Caller https://ads.seller-rogue.example is not in the plan's approved sellers list.",
  "categories_evaluated": ["delegation_authority", "seller_compliance"],
  "policies_evaluated": [],
  "findings": [
    {
      "category_id": "seller_compliance",
      "severity": "critical",
      "explanation": "Caller https://ads.seller-rogue.example is not in the plan's approved sellers list."
    }
  ]
}

mode: "advisory" — バイは進行します。オペレーターは事後に対処する重大な発見を得ます:

{
  "$schema": "/schemas/governance/check-governance-response.json",
  "check_id": "chk_advisory_001",
  "plan_id": "plan_mode_advisory",
  "verdict": "approved",
  "explanation": "Approved with 1 advisory finding(s).",
  "expires_at": "2027-01-15T15:32:41Z",
  "categories_evaluated": ["delegation_authority", "seller_compliance"],
  "policies_evaluated": [],
  "findings": [
    {
      "category_id": "seller_compliance",
      "severity": "critical",
      "explanation": "Caller https://ads.seller-rogue.example is not in the plan's approved sellers list."
    }
  ]
}

mode: "audit" — バイは黙って進行します。発見は遡及的分析のためログにあります:

{
  "$schema": "/schemas/governance/check-governance-response.json",
  "check_id": "chk_audit_001",
  "plan_id": "plan_mode_audit",
  "verdict": "approved",
  "explanation": "All governance checks passed.",
  "expires_at": "2027-01-15T15:32:41Z",
  "categories_evaluated": ["delegation_authority", "seller_compliance"],
  "policies_evaluated": [],
  "findings": [
    {
      "category_id": "seller_compliance",
      "severity": "critical",
      "explanation": "Caller https://ads.seller-rogue.example is not in the plan's approved sellers list."
    }
  ]
}

トレードオフ:

Mode	Velocity	Safety	When to use
`enforce`	最も遅い — チェックがバイをブロック	最高 — 違反は出荷できない	規制されたブランドの本番。新しいオペレーターのデフォルト
`advisory`	フルベロシティ	発見は表面化するがブロックしない	新しいポリシーの展開。締める前の動作観察
`audit`	フルベロシティ	発見は黙ってログされる	バックストップテレメトリー。決して唯一のガバナンス姿勢でない

プランはリビジョン間でモードをシフトできます — 監査証跡のガバナンス決定は、各履歴バイがどう統制されたかについて真実を伝えます。運用モードはすべての監査エントリーで可視であるべきです。今日それは check_governance ごとのレスポンスに現れますが、get_plan_audit_logs レスポンスには一貫して現れません（#3156）。

プロトコルが保証するもの

共有可能ビューを設計するとき依存できる 2 つの不変条件:

plan_hash は検証可能。 それはチェックが対して評価されたプランリビジョンにわたる base64url_no_pad(SHA-256(JCS(plan_payload))) です。プランリビジョンを持つ任意の当事者はダイジェストを再計算しバイト比較できます。プランバインディングと監査を参照。
インラインポリシーはレジストリポリシーを緩和できない。 バイヤーのカスタム policy エントリーはレジストリソースのポリシーの上に制限を追加することのみできます。したがって共有可能ビューが policies_evaluated: ["us_coppa"] を表示するとき、相手方はレジストリバージョンの us_coppa が宣言された enforcement レベルで適用されたことを信頼できます — バイヤーは黙ってそれをダウングレードしませんでした。ポリシーレジストリを参照。

はじめに

AdCP で構築する

プロトコル

FAQ

トラストとセキュリティ

リファレンス

AAO

認定

監査証跡: 内部ビュー対共有可能ビュー

そもそもなぜ分割するか

フィールドタグ付け

共有可能ビューの生成

規制当局と監査人のビュー

実例: クリーンなバイ

違反がどう見えるか

セキュリティ形状の発見: 認可されていないセラー

コーチング形状の発見: Annex III 前提条件が欠けている

オペレーターのダイヤル: enforce / advisory / audit

プロトコルが保証するもの

関連

​そもそもなぜ分割するか

​フィールドタグ付け

​共有可能ビューの生成

​規制当局と監査人のビュー

​実例: クリーンなバイ

​違反がどう見えるか

​セキュリティ形状の発見: 認可されていないセラー

​コーチング形状の発見: Annex III 前提条件が欠けている

​オペレーターのダイヤル: enforce / advisory / audit

​プロトコルが保証するもの

​関連

そもそもなぜ分割するか

フィールドタグ付け

共有可能ビューの生成

規制当局と監査人のビュー

実例: クリーンなバイ

違反がどう見えるか

セキュリティ形状の発見: 認可されていないセラー

コーチング形状の発見: Annex III 前提条件が欠けている

オペレーターのダイヤル: enforce / advisory / audit

プロトコルが保証するもの

関連