> ## 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 のキャンペーンガバナンス監査証跡が完全な内部ビューとスコープされた共有可能ビューにどう分かれるか、各相手方が安全に見られるもの。 プロトコルは、バイヤーが相手方と何を共有しなければならないかを義務付けません。しかし同じ監査証跡の 2 つの異なるビューを生成するプリミティブを与えます: * **内部ビュー** — すべてのチェック、発見、予算移動、人間レビューのバイヤーの完全な記録。自己防衛、規制当局監査、内部コンプライアンスレビューに使われる。 * **共有可能ビュー** — 1 つの相手方（セラー、エージェンシー、第三者監査人）に宛てられたスコープされたサブセット。その当事者が自身のアクションを検証するために必要なものだけを明かす。 両方とも [`get_plan_audit_logs`](/docs/governance/campaign/tasks/get_plan_audit_logs) から生成されます。分割はフィルタリングとフィールド選択の問題であり、別のプロトコルではありません。 ## そもそもなぜ分割するか バイヤーが異なるビューを維持する 3 つの理由: 1. **戦略リーク。** すべてのセラー全体の合計承認予算、チャネル配分、残ヘッドルームは競争シグナルです。派生した比率は生の金額より安全ではないことに注意 — `budget.utilization_pct` は、セラーが自身のコミット済みシェアを知っている場合、1 ステップの逆問題です。単一のセラーは自身のバイを検証するためにバイヤーの完全なプランを知る必要はありません。 2. **相手方間分離。** セラー A はセラー B の発見、ガバナンスコンテキスト、結果を見る必要はありません。共有可能ビューは常にリクエスト当事者の `governance_context` 値にスコープされます。 3. **内部レビューフィールド。** 人間レビュー理由、ドリフトメトリック、監督しきい値はバイヤー自身のガバナンス姿勢です。それらは規制当局監査でバイヤーを保護します。それらは相手方に宛てられていません。 ## フィールドタグ付け 以下のテーブルは、[`get_plan_audit_logs`](/docs/governance/campaign/tasks/get_plan_audit_logs#response) レスポンスのすべてのフィールドを、誰が安全に見られるかで分類します。 | 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 つのセラーのアクションにスコープされたリクエスト:** ```json theme={null} { "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 フィールドの証明を共有します: ```json theme={null} { "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 つを求めます: 1. **必要な場所で人間の監督が起こったか?** 解決されたポリシーからの `summary.human_reviews[]` と `requires_human_review` フラグを共有。理由は編集除去または要約されてもよい。解決とタイムスタンプは無傷であるべき。 2. **バイは特定の規制に準拠したか?** 規制の `policy_id`（例: `us_coppa`）を含む `policies_evaluated` でスコープされたエントリーを共有。規制当局がプランリビジョンに対して検証できるよう `plan_hash` を含める。 3. **監督メトリックはしきい値内か?** `summary.drift_metrics` とポリシー導出のしきい値を共有。`human_review_rate_min` を下回る `human_review_rate` は説明する価値のあるシグナル。 プロトコルは規制当局 API を定義しません。相手方ルールが開示を統制します。監査証跡が開示を可能にします。 ## 実例: クリーンなバイ OLV/ディスプレイキャンペーンに $500K 承認されたプラン。オーケストレーターは `get_products` で意図チェックを実行し、次に $150K の `create_media_buy` で実行チェック、次に結果を報告します。完全な内部監査レスポンス: ```json theme={null} { "$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` を呼び拒否されます: ```json theme={null} { "$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` を自動反転します。ブランドプロフィールが異議申立連絡先を公開しない場合、チェックは実行可能な説明とともにフェイルクローズします: ```json theme={null} { "$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`](/docs/governance/campaign/tasks/sync_plans) 経由でプランに設定され、オペレーターの主要なレバーです。同じ呼び出し元、同じペイロード、同じ発見が、モードに応じて 3 つの異なる結果を生成します。 **`mode: "enforce"`** — バイはガバナンス層でブロックされます: ```json theme={null} { "$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"`** — バイは進行します。オペレーターは事後に対処する重大な発見を得ます: ```json theme={null} { "$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"`** — バイは黙って進行します。発見は遡及的分析のためログにあります: ```json theme={null} { "$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](https://github.com/adcontextprotocol/adcp/issues/3156)）。 ## プロトコルが保証するもの 共有可能ビューを設計するとき依存できる 2 つの不変条件: * **`plan_hash` は検証可能。** それはチェックが対して評価されたプランリビジョンにわたる `base64url_no_pad(SHA-256(JCS(plan_payload)))` です。プランリビジョンを持つ任意の当事者はダイジェストを再計算しバイト比較できます。[プランバインディングと監査](/docs/governance/campaign/specification#plan-binding-and-audit) を参照。 * **インラインポリシーはレジストリポリシーを緩和できない。** バイヤーのカスタム `policy` エントリーはレジストリソースのポリシーの上に制限を追加することのみできます。したがって共有可能ビューが `policies_evaluated: ["us_coppa"]` を表示するとき、相手方はレジストリバージョンの `us_coppa` が宣言された `enforcement` レベルで適用されたことを信頼できます — バイヤーは黙ってそれをダウングレードしませんでした。[ポリシーレジストリ](/docs/governance/policy-registry#policy-categories) を参照。 ## 関連 * [`get_plan_audit_logs`](/docs/governance/campaign/tasks/get_plan_audit_logs) — リクエストとレスポンススキーマ * [キャンペーンガバナンス仕様](/docs/governance/campaign/specification) — プランバインディング、ドリフト検出、ガバナンスコンテキストライフサイクル * [ポリシーレジストリ](/docs/governance/policy-registry) — ポリシーバージョニング、`effective_date`、レジストリ対インラインポリシー * [Annex III と Art 22 の義務](/docs/governance/annex-iii-obligations) — 人間レビューがいつ必要か