> ## 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 ポリシーレジストリと同期に保つ運用パターン — バージョンピン留め、レジストリバージョンバンプ、effective_date 採用、サンセット動作、インラインポリシーの追加のみ不変条件。

キャンペーンガバナンスを設計するワーキンググループは、ポリシーがバイヤー、セラー、ガバナンスエージェント間でどう同期されるかについて同じ質問セットを尋ねます。このページは、5 つのセクションと FAQ で運用パターンを捕捉します。

## プランにポリシーバージョンをピン留めできるか?

**いいえ — `policy_ids[]` は今日バージョン修飾子を運びません。** キャンペーンプランは ID のみでレジストリポリシーを参照します:

```json theme={null}
{
  "plan_id": "plan_q1_2027_acme",
  "policy_ids": ["us_coppa", "alcohol_advertising"],
  "policy_categories": ["age_restricted"]
}
```

すべての [`check_governance`](/docs/governance/campaign/tasks/check_governance) 呼び出しで、ガバナンスエージェントは各 ID をレジストリに対して解決し、**現在のバージョンが何であれ** それを使います。プランレベルのバージョンピンフィールドはありません。同じプランの 2 つのチェック間でレジストリポリシーがバージョンバンプする場合、2 番目のチェックは新しいバージョンに対して評価します。

バイの期間中に決定的なポリシーテキストが必要な場合、レジストリポリシーをプランの [`custom_policies[]`](/docs/governance/campaign/tasks/sync_plans) にコピーします — 下の [Pinning by inline copy](#pinning-by-inline-copy) を参照。監査証跡はすべてのチェックで `policies_evaluated[]` を記録するため、履歴バージョンは [`/api/policies/history`](https://adcontextprotocol.org/api/policies/history) 経由でチェックごとに回復可能です。

これは他のアドテックプロトコル（TCF v2 の TC 文字列、OpenRTB GPP）が取る同じ姿勢です — バージョンはリクエスト作成時ではなく評価時に解決します。解決時最新が正しい 99% のケースで、バイヤーをバージョン依存管理ビジネスから外し続けます。

## Pinning by inline copy

決定的なポリシーテキストが必要なとき — 規制当局の事前クリアランス、凍結されたブランドセーフティ契約、初日のポリシーに対して評価されなければならない複数月のブランドキャンペーン — 利用可能なパターンは、プラン作成時に **異なる `policy_id`** の下でレジストリポリシーを `custom_policies[]` にコピーすることです:

```json theme={null}
{
  "plan_id": "plan_q1_2027_acme",
  "policy_ids": ["us_coppa"],
  "custom_policies": [
    {
      "policy_id": "alcohol_advertising_pinned_2026Q4",
      "version": "2.1.0",
      "name": "Alcohol Advertising Standards (pinned to v2.1.0)",
      "category": "standard",
      "enforcement": "must",
      "policy": "<full natural-language text copied verbatim from the v2.1.0 registry entry>",
      "exemplars": { "...": "copied from registry" }
    }
  ]
}
```

**レジストリのものと異なる `policy_id` を使ってください。** バイヤーが `custom_policies` で正準 ID `alcohol_advertising` を再利用する場合、ガバナンスエージェントの動作は仕様で未定義です — [policy-entry スキーマ](https://adcontextprotocol.org/schemas/v3/governance/policy-entry.json) の追加のみルールは、その ID についてレジストリテキストを権威的としてピン留めします。`alcohol_advertising_pinned_2026Q4`（またはあなたの内部バージョニング規約）のようなピン留め ID はコンフリクトを回避します。

プランリビジョンは今や凍結されたテキストを運びます。インラインポリシーの `version` フィールドは情報的です — テキストが評価されるものです — が、監査人がインラインコピーを特定のレジストリリリースに相関できるようフォレンジックな追跡可能性のため設定する価値があります。

**ライフサイクル。** インラインコピーは、バイヤーがプランの各再同期で `custom_policies` にエントリーを保つ限り保持されます。ガバナンスエージェントの追加のみ `revisionHistory` は監査のため以前のプランリビジョンをアーカイブしますが、ライブ評価は常に最新の `sync_plans` ペイロードにあるものを使います — したがって再同期でインラインポリシーを落とすバイヤーは次のチェックでピンを失います。

**トレードオフ。** ピン留めされたポリシーはレジストリ訂正を拾いません。`alcohol_advertising` v2.2.0 が明確化を出荷する場合、ピン留めされたプランは誰かが手動で新しいテキストで `custom_policies` を再同期するまで v2.1.0 に対して評価し続けます。それが安定性の代償です。

## インラインポリシーはレジストリに対して追加のみ

インライン `custom_policies[]` は [policy-entry スキーマ](https://adcontextprotocol.org/schemas/v3/governance/policy-entry.json) からのハードな不変条件を運びます: それらはレジストリソースのポリシーの上に制限を **追加** することのみできます。インラインポリシーは、レジストリポリシーの `enforcement` レベルを緩和したり、レジストリポリシーが義務付けるカテゴリーを免除したり、そうでなければレジストリベースラインを弱めたりしてはなりません（MUST NOT）。任意のレジストリポリシーと交差しないバイヤー作成のインラインポリシーは制約されません — レジストリポリシーとの関係のみが統制されます。

具体的には、`policy_ids: ["us_coppa"]` と `custom_policies` エントリーの両方を持つプランを評価するガバナンスエージェントは、`us_coppa` をピン留めまたは拡張できます（例: リネームされた ID の下のブランド固有事例セット）が、「このキャンペーンでは COPPA を無視」と言うインラインポリシーを追加できません。監査エントリーで `policies_evaluated: ["us_coppa"]` を見る相手方は、したがってレジストリバージョンの `us_coppa` が宣言された `must` レベルで適用されたことを信頼できます — バイヤーは黙ってそれをダウングレードしませんでした。

これを検証したい相手方は、プランリビジョンをリクエストし `plan_hash` を再計算できます（[キャンペーンガバナンス仕様](/docs/governance/campaign/specification#plan-binding-and-audit)）。プランバインディングは、追加のみ不変条件を単に宣言されたものではなく検証可能にする暗号表面です。エージェント側の強制はダウングレードが起こることを防ぐものです。ハッシュは事後に決定を証明可能にするものです。

## キャンペーン中のレジストリバージョンバンプの処理

プランがアクティブな間にレジストリポリシーがバージョンバンプするとき:

| Plan state                                      | Behavior                                                                                                        |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| プランが `policy_ids` のみでポリシーを参照                    | 次の `check_governance` が新しいバージョンを解決。既にコミットされたバイはコミットされたまま（その監査エントリーが古いバージョンの解決タイムスタンプを記録）。新しいチェックが新しいテキストに対して評価。 |
| プランが `custom_policies`（リネームされた ID の下）でポリシーをピン留め | プランはインラインテキストに対して評価し続ける。レジストリ変更は、バイヤーが新しいテキストで `custom_policies` を再同期するまでこのプランに影響しない。                           |
| プランが削除または完了                                     | 継続的なチェックなし。評価なし。監査ログはフォレンジック回復のため `policies_evaluated[]` を保持。                                                   |

完了したバイのバージョン安定性を気にするバイヤーは何もする必要はありません — 監査証跡が評価されたものを捕捉します。*アクティブな飛行中の* バイの安定性を気にするバイヤーはインラインコピーパターンを使うべきです。

## 段階的採用のための `effective_date`

「最初は最小限の制限」パターンは、プランごとの設定ではなくレジストリの文書化された動作です。ガバナンスエージェントは、ポリシー ID を参照するすべてのプランにわたって `effective_date` を自動的に尊重します:

1. **Day 0** — コミュニティがドラフトポリシーに合意。将来 60 日以上の `effective_date` でレジストリに公開。
2. **Day 0–60** — ポリシー ID を参照する任意のプランを評価するすべてのガバナンスエージェントが情報的発見を発行。バイヤーとセラーは何がフラグされたはずかを正確に見る。バイはブロックされない。
3. **Day 60** — `effective_date` が経過。同じ評価が今やポリシーの宣言された `enforcement` レベルでブロック。任意のプランで設定変更不要。
4. **Day 60+** — 段階的採用ウィンドウのバイヤーは、在庫とクリエイティブを調整する 2 か月のテレメトリーを持っていた。遅い開始者はハードなカットオーバーを得る。

`effective_date` は段階的採用の時間軸です。**スコープベースの段階化** — チャネル、管轄、`policy_categories` サブセットによるフェーズ — はレジストリレベルで行われる別の動きです: まず狭い管轄または狭いカテゴリーのポリシーを公開し、次により広いものを公開。2 つの軸は合成します。単一のポリシーがスコープ狭窄と時間段階化ウィンドウに同時に存在できます。

## サンセット動作

レジストリポリシーがその `sunset_date` に到達すると、ガバナンスエージェントは後続のチェックでそれの評価を停止します。`policies_evaluated[]` にポリシーを記録した既存の監査エントリーは変わりません — 証跡はいつ何が評価されたかについて真実を伝えます。バイヤーからのアクションは不要です。サンセットされたポリシーはすべてのアクティブプランから自動的に脱落します。

サンセットされたポリシーが後継に置き換えられる場合（例: ある規制が別のものに取って代わる）、レジストリコントリビューターは両方を公開します: `sunset_date` が設定された古いエントリー、`effective_date` が設定された新しいエントリー。バイヤーは次のプランリビジョンで新しいエントリーを参照するよう `policy_ids[]` を更新します — 古い ID はそのサンセット日まで評価し続け、その後静かに停止します。

## よくある質問

**キャンペーン中に規制が変わるとき飛行中のバイに何が起こるか?** [キャンペーン中のレジストリバージョンバンプの処理](#handling-registry-version-bumps-mid-campaign) の下のテーブルが答えです。短縮版: コミットされたバイはコミットされたまま。次のチェックが現在のものを解決。`custom_policies` 経由のピン留めが特定のテキストを凍結する方法です。

**新しい objective を追加するときプランは再評価するか?** プランリビジョン（監査ログエントリーの `plan_version`、プランが再同期するたびに記録）はそれ自体で解決されたポリシーテキストをリフレッシュしません — 次の `check_governance` は依然として構成されたとおりレジストリにヒットします。リビジョンでポリシーテキストをリフレッシュするには、新しいプランリビジョンで `policy_ids[]`（または `custom_policies` のインラインコピー）を変更します。

**どのバージョンが適用されたかを相手方にどう証明するか?** 3 つの層: (1) セラーの `governance_context` トークンが特定のチェックを相関、(2) そのチェックの監査ログエントリーが `policies_evaluated[]` と `plan_hash` を運ぶ、(3) レジストリの [`/api/policies/history`](https://adcontextprotocol.org/api/policies/history) エンドポイントが任意の `policy_id` の完全なリビジョンシーケンスを返すため、監査人はどのバージョンが履歴タイムスタンプでアクティブだったかをリプレイできます。

**管轄ごとのオーバーライド。** グローバル標準と管轄固有の締め付けの両方を宣言（例: `policy_ids: ["alcohol_advertising", "alcohol_advertising_norway"]`）。ガバナンスエージェントは両方を評価。追加のみルールは 2 つのうちより制限的なものが勝つことを意味します。

**ブランド固有拡張。** 共有レジストリに属さないルール（競合排除、ブランドボイスガイドライン、内部コンプライアンスフレームワーク）には `custom_policies[]` を使います。`policy_ids[]` と並んでそれらを参照します。

## 関連

* [ポリシーレジストリ](/docs/governance/policy-registry) — レジストリ概念、ポリシー構造、シードされたポリシー、制限属性
* [キャンペーンガバナンス仕様](/docs/governance/campaign/specification) — プランバインディング、`plan_hash`、ガバナンスコンテキストライフサイクル
* [監査証跡: 内部対共有可能ビュー](/docs/governance/campaign/audit-trail) — 評価履歴を相手方に表示する方法
* [`sync_plans`](/docs/governance/campaign/tasks/sync_plans) — `policy_ids`、`policy_categories`、`custom_policies`
* [Annex III と Art 22 の義務](/docs/governance/annex-iii-obligations) — 人間レビューがいつ必要か