> ## 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. # ポリシー帰属 > プロデューサーがメカニズムレベルのフィルターと測定を認可ポリシーでタグ付けし、監査証跡とガバナンス発見が特定のしきい値や評価がなぜ存在するかに遡れるようにする方法。 バイヤーがオーディエンスの子供構成を 15% で上限設定するとき、しきい値自体はなぜかを説明しません。数字は機械的です。*理由*（UK HFSS）は別の場所に存在します。帰属なしでは、6 か月後にプロパティリストを読む監査人は、人間の解釈なしに「なぜこのリストは高子供構成プロパティを除外するのか?」に答えられません。 ポリシー帰属はそのギャップを閉じます。プロデューサーはメカニズムレベルのフィルターと測定を `policy_id` でタグ付けし認可ポリシーを記録します。ガバナンス発見は拒否を発行するとき同じ `policy_id` をエコーするため、トレースはエンドツーエンドで走ります。 ## 3 つの表面、1 つのパターン | Surface | Producer | Use | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------- | ---------------------------------- | | [`core/feature-requirement.json`](https://adcontextprotocol.org/schemas/v3/core/feature-requirement.json) | バイヤー（またはバイヤーのコンプライアンスツール） | バイヤー作成のしきい値述語をそれを認可したポリシーでタグ付け | | [`creative/creative-feature-result.json`](https://adcontextprotocol.org/schemas/v3/creative/creative-feature-result.json) | クリエイティブエージェント / セラー | 測定レコードを評価を動機付けたポリシーでタグ付け | | [`property/validation-result.json`](https://adcontextprotocol.org/schemas/v3/property/validation-result.json) `features[].policy_id` | プロパティリストエージェント | フィーチャーごとの検証結果をチェックをトリガーしたポリシーでタグ付け | 3 つのフィールドすべてがオプションです。最初の 2 つは 3.0 GA で予約されました。3.1 でそれらを投入することは厳格な 3.0 検証者にとって非破壊的です。3 番目は 3.0 以来 validation-result に存在します。 ## `policy_id` をいつ投入するか **フィルターまたは測定が特定の認可ポリシーのために存在する** — そしてプロデューサーがそのポリシーのエンコーディングとして特定のメカニズムを選んだ — とき `policy_id` を投入します。 ポリシーが単に一般的に適用されるとき `policy_id` を投入 **しません**。プランレベルのポリシー適用性は、プラン自体で `policy_ids[]` 経由で宣言されます（`sync_plans` を通じてバイヤーのガバナンスエージェントに送られる）。フィルターレベルフィールドはメカニズムの著作者であり、一括適用性ではありません。 ### プランレベル対フィルターレベル これらは異なる仕事です: | Buyer says | Where it lives | Who picks the mechanism | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | ---------------------------------- | | 「COPPA を適用 — ガバナンスが誰が該当するか判断」 | `plan.policy_ids: ["us_coppa"]` | バイヤーのガバナンスエージェント | | 「COPPA へのコンプライアンスは意味する: プロパティにそれを証明するよう要求」 | `feature_requirements: [{feature_id: "registry:us_coppa", value: true}]` | バイヤー、測定をセラーの `registry:` フィーチャーに委譲 | | 「HFSS を ≤15% 子供構成としてエンコード」 | `feature_requirements: [{feature_id: "audience_children_composition", max_value: 15, policy_id: "uk_hfss"}]` | バイヤー、しきい値を自身で選択 | 3 番目の行のみがフィルターレベル `policy_id` を運びます。最初の 2 行は既により高い抽象化レベルで意図を捕捉しています — 2 番目のケースではレジストリフィーチャー ID 自体がポリシー参照です。 ## ガバナンス発見経由のラウンドトリップ 帰属ループは filter → ガバナンスエージェント → finding → audit と走ります。バイヤーのプランで動作するエージェントは `check_governance` を呼びます。`phase` に応じて、これは **意図チェック**（オーケストレーター側、コミット前）または **実行チェック**（セラー側、計画された配信のバインド前）のいずれかです。両パスは同じ形状の発見を生成します。 ``` Buyer's property list (stored at the property-list agent) feature_requirements: - feature_id: audience_children_composition max_value: 15 policy_id: uk_hfss ← authored here │ │ Acting agent resolves the property list, sees policy_id as pass-through metadata ▼ Planned action would violate the requirement │ │ check_governance(plan_id, payload | planned_delivery, governance_context) │ - orchestrator on intent check (tool + payload) │ - seller on execution check (planned_delivery) ▼ Buyer's Governance agent emits a finding: findings: - category_id: regulatory_compliance policy_id: uk_hfss ← echoed from the originating requirement severity: block explanation: "Planned targeting exceeds the 15% children-composition cap." │ ▼ Audit: "why was this denied?" → uk_hfss → grep buyer's filters → find the originating requirement. ``` 動作するエージェント（フェーズに応じてオーケストレーターまたはセラー）は通過点です — それは発見を生成しません。バイヤーのガバナンスエージェントがプロデューサーで、バイヤーのフィルターに直接アクセスできます（同じ信頼境界）ので、基盤となる要件を読むことで発見に `policy_id` を投入できます。 ## プロデューサーのコントラクト **`feature-requirement` を作成するバイヤー（またはバイヤーのコンプライアンスツール）:** * 要件がバイヤーが選んだ特定のポリシーしきい値をエンコードするとき `policy_id` を投入すべき（SHOULD）。 * 要件が任意のポリシーと無関係な一般的フィーチャーフィルターのとき `policy_id` を投入すべきでない（SHOULD NOT）。 * ポリシーレジストリまたはプランの `custom_policies[]` のいずれかで解決する `policy_id` を参照しなければならない（MUST）。 **`creative-feature-result` を作成するクリエイティブエージェントまたはセラー:** * フィーチャーが特定のポリシー評価の目的で測定されたとき `policy_id` を投入すべき（SHOULD）。 * フィーチャーが任意のポリシーと無関係な汎用測定（カーボンスコア、ブランド一貫性）のとき `policy_id` を投入すべきでない（SHOULD NOT）。 **発見を発行するガバナンスエージェント:** * 基盤となる違反が `policy_id` を運ぶフィルターまたは測定に遡るとき、発見で `policy_id` をエコーすべき（SHOULD）。 * 元のフィルターに存在しなかった `policy_id` を発明してはならない（MUST NOT） — 発見 `policy_id` は追跡可能性のためで、新しいポリシー適用性を宣言するためではない（それは `policies_evaluated[]` に属する）。 ## 実例 ### UK HFSS — バイヤーエンコードのしきい値 バイヤーのコンプライアンスチームは UK HFSS を「オーディエンスは 15% 未満の子供でなければならない」と解釈します。彼らはその解釈をフィーチャー要件としてエンコードします: ```json theme={null} { "feature_requirements": [ { "feature_id": "audience_children_composition", "max_value": 15, "policy_id": "uk_hfss" } ] } ``` 別のチームが後で「なぜ 15? なぜ 20 ではない?」と尋ねる場合、policy\_id は根拠と事例が存在する UK HFSS のレジストリエントリーを指します。 ### COPPA — セラーのレジストリフィーチャーに委譲 バイヤーは COPPA のしきい値を選びません — 評価を完全に委譲します。`registry:` プレフィックスはフィーチャー命名規約（[`property-feature-definition`](https://adcontextprotocol.org/schemas/v3/property/property-feature-definition.json) と [ポリシーレジストリ](/docs/governance/policy-registry#feature-prefix-convention) を参照）で、フィーチャー ID `registry:` が標準化されたポリシーを直接参照します: ```json theme={null} { "feature_requirements": [ { "feature_id": "registry:us_coppa", "value": true } ] } ``` フィーチャー ID *が* ポリシー参照です。ここに `policy_id: "us_coppa"` を追加することは冗長で — 実際には委譲したのにバイヤーがメカニズムを作成したことを含意します。 ### クリエイティブ測定 — エージェントが理由を記録 クリエイティブエージェントがクリエイティブを HFSS コンプライアンスについて評価し記録します: ```json theme={null} { "feature_id": "uk_hfss_compliance", "value": false, "policy_id": "uk_hfss", "methodology_version": "v2.1", "measured_at": "2026-05-17T14:00:00Z" } ``` `policy_id` は「なぜこの評価が実行されたか?」に答えます。クリエイティブの測定履歴をレビューする誰でも、この結果を元のポリシーと相関できます。 この結果がクリエイティブレベルのガバナンスチェックを失敗すると、ガバナンスエージェントの発見は同じ `policy_id` をエコーします: ```json theme={null} { "category_id": "regulatory_compliance", "policy_id": "uk_hfss", "severity": "block", "explanation": "Creative failed UK HFSS compliance evaluation." } ``` バイヤーは両レコード全体で `policy_id` を一致させることで発見を元の測定に相関できます。 ## 帰属がカバーしないもの * **バイヤーからセラーへのトップダウンポリシー宣言。** バイヤーがメカニズムをエンコードせずにセラーにポリシーの専門的処理（HIPAA ベンダー、COPPA データセット）を適用してほしいとき、それは [#4629](https://github.com/adcontextprotocol/adcp/issues/4629) で追跡される別の表面です。 * **オーディエンスセレクターの基準ごと帰属。** プランのオーディエンス除外はバイヤーのガバナンスエージェントによってプランレベルの `policy_ids[]` から導出されるべきで — バイヤーが手作成しポリシー権威でタグ付けするのではありません。オーディエンスセレクタースキーマは `policy_id` を運びません。 * **ターゲティングオーバーレイの基準ごと帰属。** ターゲティングフィールド（`geo_countries_exclude`、年齢制限、デバイスプラットフォーム）はエントリーごとの形状なしのフラット配列を使います。基準ごと帰属はスキーマ再構築を要求します。これらの制約にはプランレベル宣言を使います。 ## 関連項目 * [ポリシーレジストリ](/docs/governance/policy-registry) — `policy_id` の共有ライブラリ * [ポリシーレジストリ同期](/docs/governance/policy-registry-sync) — プランが `policy_ids[]` と `custom_policies[]` 経由でポリシーをどう参照するか * [`check_governance`](/docs/governance/campaign/tasks/check_governance) — `policy_id` 追跡可能性で発見が発行される場所