> ## 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.

# 正準フォーマットへの移行

> v1 名前付きフォーマットから正準フォーマット製品バインド宣言に移行するセラー、クリエイティブエージェント、バイヤー、ツールのための具体的な移行パス。

# 移行: v1 名前付きフォーマット → 正準フォーマット

このガイドは、v1 名前付きフォーマット（別途定義されたフォーマットファイルを参照する `{ agent_url, id }` としての `format_id`）から、[RFC #3305](https://github.com/adcontextprotocol/adcp/issues/3305) が導入した正準フォーマット製品バインド宣言へのシフトを歩きます。v1 名前付きフォーマットは 4.x を通じてファーストクラスパスのままです。正準フォーマットは新しいパスで、無期限にオプトインです。

アーキテクチャについては、まず [`canonical-formats`](/docs/creative/canonical-formats) を読んでください。このページは移行の仕組みだけです。

> *命名ノート*: このページ全体で使われる v1↔v2 用語は、2 つのフォーマット作成モデル — `format_ids`（レガシー、v1）対 `format_options`（正準フォーマット、v2）— を記述します。AdCP プロトコル自体のバージョン（現在 3.x）を指すものでは **ありません**。「v2」パスは正準フォーマットパスとも呼ばれます。両方の言い回しは同じことを意味します。

## 何が変わらないか

AdCP のほとんどは変わりません。v2 は既存のプリミティブの上に構築されます:

* すべてのアセットプリミティブスキーマ（`image-asset.json`、`video-asset.json`、`audio-asset.json`、`vast-asset.json`、`daast-asset.json`） — 変わらず
* カタログとオファリングスキーマ — 変わらず
* マニフェストエンベロープ形状（`assets` マップでキーされた `creative-manifest.json`） — 変わらず
* レスポンスエンベロープ、エラースキーマ、共通タイプ — 変わらず
* v1 名前付きフォーマット（複合 `format_id` を持つ `format.json`） — 依然として 4.x を通じてサポート
* v1 `list_creative_formats` ツール — 非推奨だが 4.x を通じて機能。5.0 で削除
* すべての既存プロデューサーと消費者 — 変更なしで動作し続ける

## 並列比較: v1 名前付きフォーマット → v2 製品フォーマット宣言

### v1 — 製品が参照する別のフォーマットファイル

```json test=false theme={null}
// formats/meta_reels.json
{
  "format_id": { "agent_url": "https://creative.adcontextprotocol.org", "id": "meta_reels" },
  "name": "Meta Reels",
  "type": "video",
  "assets": [
    {
      "asset_id": "video_file",
      "asset_type": "video",
      "asset_role": "hero_video",
      "item_type": "individual",
      "required": true,
      "requirements": {
        "min_duration_ms": 3000,
        "max_duration_ms": 90000,
        "aspect_ratio": "9:16",
        "min_width": 1080,
        "min_height": 1920,
        "containers": ["mp4"],
        "codecs": ["h264"]
      }
    }
  ]
}

// products/meta_reels_us.json
{
  "product_id": "meta_reels_us",
  "name": "Meta Reels — United States",
  "format_ids": [
    { "agent_url": "https://creative.adcontextprotocol.org", "id": "meta_reels" }
  ],
  // ... pricing, targeting, etc.
}
```

### v2 — 製品上のインラインフォーマット宣言

```json test=false theme={null}
{
  "product_id": "meta_reels_us",
  "name": "Meta Reels — United States",
  "format_options": [
    {
      "format_kind": "video_hosted",
      "params": {
        "orientation": "vertical",
        "aspect_ratio": "9:16",
        "duration_ms_range": [3000, 90000],
        "min_width": 1080,
        "min_height": 1920,
        "video_codecs": ["h264"],
        "containers": ["mp4"],
        "headline_max_chars": 25,
        "primary_text_max_chars": 72,
        "cta_values": ["LEARN_MORE", "SHOP_NOW", "DOWNLOAD", "SIGN_UP"],
        "composition_model": "deterministic",
        "platform_extensions": [
          { "uri": "https://creative.adcontextprotocol.org/translated/meta/extensions/meta_pixel", "digest": "sha256:..." }
        ]
      }
    }
  ],
  // ... pricing, targeting, etc.
}
```

`format_options` は配列です。90% のケースは 1 要素 — 製品向けに絞られた 1 つの正準。複数要素配列は、製品がリストされたフォーマットオプションのいずれかを受け入れることを宣言し、`sync_creatives` 時にバイヤーが選びます。一般的な複数要素ユースケース: サードパーティホストクリエイティブ（例: Flashtalking サーブの `html5`）または内部 `display_tag` のいずれかを受け入れるプレースメント。ホストアップロード（`video_hosted`）またはタグ（`video_vast`）を受け入れる動画製品。各エントリーは判別された union です: `format_kind` が正準フォーマットを名指し、`params` がその正準のパラメータースキーマを運びます。SDK は TypeScript と Pydantic でクリーンなタグ付き union をコード生成します。

**移行ウィンドウ中のデュアル発行**: 製品は `format_ids`、`format_options`、または両方を運べます（MAY）。少なくとも 1 つが必要です（スキーマは `oneOf` ではなく `anyOf` でこれを強制します）。推奨されるセラーパターンは一度作成し、SDK に [v1↔v2 正準マッピングレジストリ](https://adcontextprotocol.org/schemas/v3/registries/v1-canonical-mapping.json) 経由で両方のワイヤー形状に投影させることで、すべてのバイヤーが知っているものを読みます。両方の形状が製品に存在するとき、2 つは同じ基盤フォーマット宣言を参照しなければなりません（MUST） — `format_options[i]` はレジストリ経由で `format_ids[i]` が解決する正準を絞らなければなりません。1 つのソースから両方の形状を導出する SDK はこの不変条件を保証します。両方を手作成する SDK は分岐をビルドエラーとして扱い発行を拒否しなければなりません（MUST）。両方が存在するときバイヤーは `format_options` を優先します。`format_ids` を v1 のみのバイヤーのフォールバックとして扱います。v1 名前付きフォーマットにクリーンな v2 投影がないセラーは、v1 フォーマットに明示的な `canonical` 宣言を追加するまで（下の「v1 → v2 正準マッピング」を参照）それらの製品に `format_ids` のみを出荷します — SDK は投影不可能なフォーマットに `format_options` を発行してはなりません（MUST NOT）。

12 の正準フォーマットすべてにまたがる 14 の完全に検証されたリファレンス製品フィクスチャ — Meta Reels（`video_hosted` 縦）、IAB MREC（`image` 300×250）、NYTimes HTML5（`html5`）、GAM 3P display tag（`display_tag`）、Meta Carousel（`image_carousel`）、YouTube VAST pre-roll（`video_vast`）、ポッドキャスト 30s ホストリード（`audio_hosted`）、Triton DAAST audio（`audio_daast`）、Amazon Sponsored Products（`sponsored_placement`）、Taboola Content Recommendation（`native_in_feed`）、Google PMax（`responsive_creative`）、ChatGPT ブランドメンション（`agent_placement`）、Veo 15s 生成動画（`synthesis_nondeterministic` + `provenance_required` 付き `video_hosted`） — プラスバンドル拡張を行使する 1 つの `get_products` レスポンスフィクスチャについては、`static/examples/products/canonical/` と `static/examples/get_products_responses/canonical/` を参照してください。Veo フィクスチャは `synthesis_nondeterministic: true` と `provenance_required: true` を行使します。各フィクスチャは `npm run test:canonical-fixtures` を通過します。

## v1 → v2 正準マッピング

下のスロットレベル `asset_group_id` ブリッジは、v1 スロットがどの v2 正準 *スロット* に対応するかを SDK に伝えます。フォーマットレベルマッピング — v1 名前付きフォーマットがどの v2 *正準フォーマット* に投影されるか — は 2 つの補完的メカニズムで解決されます:

### 正準マッピングレジストリ

[`/schemas/registries/v1-canonical-mapping.json`](https://adcontextprotocol.org/schemas/v3/registries/v1-canonical-mapping.json) は権威的な AAO 公開レジストリです。SDK はデュアル発行と v1↔v2 翻訳中に v1 フォーマットを v2 正準に投影するためそれを消費します。エントリーごとに 2 つのマッチモード:

* **`format_id_glob`** — v1 `format_id.id` に対する完全 / glob マッチ。IAB 慣習サイズ（`iab/mrec_300x250` → `image` 300×250）、名前付きプラットフォームフォーマット、一般的なパブリッシャー慣習をカバー。
* **`structural`** — フォーマットのスロット形状、アセットタイプ、バージョン制約に対するマッチ。異なる名前の下で構造的に標準フォーマットであるカスタム v1 フォーマットを捕捉（セラーの `acme_homepage_300x250` は構造的に IAB MREC）。

初期レジストリは約 15 の曖昧でないエントリー（IAB ディスプレイサイズ、VAST 4.x、DAAST 1.x）をカバーします。後続の PR が、アダプターフィードバックがパターンを表面化するにつれカバレッジを拡張します。ガバナンスは `asset-group-vocabulary.json` と同じルールに従います: 根拠 + 1 つ以上のリファレンスアダプター + AAO メンテナーレビュー付き PR。エントリーは追加的でダイジェストピン留めされます。

### v1 フォーマット宣言の `canonical` フィールド（カスタム / 未登録フォーマット）

レジストリでカバーされないカスタムセラーフォーマットには、セラーは v1 フォーマット宣言レベルでマッピングをインラインで宣言します:

```json test=false theme={null}
{
  "format_id": "acme/sponsored_recipe_card",
  "name": "Sponsored Recipe Card",
  "canonical": { "kind": "sponsored_placement" },
  "canonical_parameters": {
    "format_kind": "sponsored_placement",
    "params": {
      "supported_catalog_types": ["product"],
      "supported_id_types": ["sku"],
      "fanout_mode": "per_item",
      "item_production_model": "buyer_uploaded"
    }
  },
  "assets": [
    { "asset_id": "headline", "asset_type": "text", "asset_group_id": "headline", "required": true },
    { "asset_id": "recipe_image", "asset_type": "image", "asset_group_id": "image_main", "required": true }
  ]
}
```

`canonical` フィールドは v2 正準を名指します。`canonical_parameters`（オプション）は、SDK がこの v1 フォーマットを投影する完全な ProductFormatDeclaration を運びます。各 `assets[]` エントリーのスロットレベル `asset_group_id` 宣言と組み合わさって、v1 フォーマットは v1↔v2 翻訳のため完全に自己記述的になります。セラーはこれをバイヤーごとや製品ごとではなく、カスタムフォーマットごとに一度行います。

`format_kind: "custom"` のケース（それ自体が任意の v2 正準に適合しないカスタムセラーフォーマット）には、`canonical_parameters` は通常の v2 宣言と同じ `format_kind: "custom"` + `format_shape` + `format_schema` トリプルを運びます。

### 規範的 SDK 投影ルール

SDK が v1 フォーマットをその v2 正準に投影する（または逆）ときの解決順:

1. v1 フォーマット宣言が `canonical` を運ぶ場合、それを使う（セラー宣言、最高優先度）。`canonical_parameters` も存在するとき、それを投影された ProductFormatDeclaration としてそのまま使う。
2. そうでなければ、`/schemas/registries/v1-canonical-mapping.json` の `format_id_glob` エントリーで `format_id` をルックアップ。
3. そうでなければ、レジストリの `structural` エントリーに対して構造マッチを試みる。
4. そうでなければ、**フェイルクローズ**: SDK はこのフォーマットを運ぶ製品に `format_options` を発行してはならない（MUST NOT）。セラーが明示的な `canonical` フィールドを追加するかレジストリエントリーを提出することを提案する検証警告を表示。バイヤーはこれらの製品に `format_ids` のみを見る。

逆方向（v2 セラーを読む v1 のみのバイヤーのための v2 → v1 降格）は逆投影です: 同じレジストリ、同じアルゴリズム、逆に実行。SDK は両方向を処理する単一のマッピングエンジンを出荷します。

これが「移行中に両方のワイヤー形状を公開する」を SDK 実装全体で扱いやすく一貫させるものです — すべての SDK が同じレジストリを通じて投影するため、任意のセラーからのデュアル発行製品が任意のバイヤー全体で同一に解決します。

## スロット名マッピング（v1 → 正準）

v1 フォーマットスロットが、正準語彙がカバーする作者発明の名前を使う場合、フォーマット宣言は正準エントリーを指すオプションの `asset_group_id` フィールドをスロットに運びます。既存の `asset_role` フィールドと同じですが、フリーテキストではなく [正準語彙](https://adcontextprotocol.org/schemas/v3/core/asset-group-vocabulary.json) を参照します。

```json test=false theme={null}
// v1 format with author-invented slot name
{
  "asset_id": "click_url",
  "asset_type": "url",
  "item_type": "individual",
  "required": true
}

// Same v1 format with canonical pointer (additive — backwards-compatible)
{
  "asset_id": "click_url",
  "asset_type": "url",
  "asset_group_id": "landing_page_url",
  "item_type": "individual",
  "required": true
}
```

語彙レジストリの `aliases` フィールドは、正準エントリーごとに一般的な v1 エイリアス名を捕捉します（例: `landing_page_url` エイリアスは `click_url`、`link`、`final_url`、`link_url`、`click_through_url`、`landing_url` を含む）。同じフィールドの 6 つの異なる名前が 1 つの正準に崩れます。

一般的なエイリアスマッピング（`asset-group-vocabulary.json` の監査に基づくセットから）:

| Canonical          | Common v1 aliases                                                                |
| ------------------ | -------------------------------------------------------------------------------- |
| `headlines`        | `headline`, `title`, `tagline`, `headline_text`                                  |
| `descriptions`     | `description`, `body`, `body_text`, `text`, `content`                            |
| `images_landscape` | `image`, `hero_image`, `landscape_image`, `banner_image`                         |
| `images_vertical`  | `vertical_image`, `story_image`, `portrait_image`                                |
| `images_square`    | `square_image`, `feed_image`                                                     |
| `logo`             | `brand_logo`, `logo_image`                                                       |
| `video`            | `video_file`, `hero_video`, `video_asset`, `video_main`                          |
| `audio`            | `audio_file`, `hero_audio`, `audio_asset`, `audio_main`                          |
| `landing_page_url` | `click_url`, `link`, `final_url`, `link_url`, `click_through_url`, `landing_url` |

## ディスカバリー表面移行

`list_creative_formats` は一様に非推奨です。置き換え:

| Role                | v1 path                                    | v2 path                                                                                                                |
| ------------------- | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| セールスエージェント          | `list_creative_formats` がセラーの受け入れフォーマットを返す | `get_products` — 各製品が `format` 宣言をインラインで運ぶ。オプションでフラットサマリーのため `get_adcp_capabilities` に `creative.supported_formats` も。 |
| クリエイティブエージェント（在庫なし） | `list_creative_formats` が「生成できるもの」として過負荷   | `get_adcp_capabilities` の `creative.supported_formats`。各エントリーは製品のインライン `format` と同じ `ProductFormatDeclaration` 形状を使う。  |

セラーは、既存のダッシュボードとツールが動作し続けるよう、v2 製品フォーマット宣言から v1 `list_creative_formats` 形状を導出するサーバー側フラット化ラッパーを 4.0 を通じて提供すべきです（SHOULD）。ラッパーは `get_products` を反復し、各製品の `format` 宣言を読み、v1 互換フォーマットファイルプラス `format_ids` 参照を発行します。

## 生成フォーマット — `*_generated_*` ファイルが溶ける

agentic-adapters 監査は、非生成対応物をミラーするが、アセットアップロードの代わりに `creative_brief` を受け入れる約 30 の `*_generated_*` フォーマットファイル（例: `meta_generated_reels`、`tiktok_generated_video_9x16`）を見つけました。v2 ではこれらが崩れます:

* フォーマット宣言の `slots` 配列は、マニフェストの `assets` マップでバイヤーが出荷するすべてを列挙します — 各エントリーは `asset_type` とペアになった正準 `asset_group_id`。一部のスロットはそのままレンダーされます（画像 / 動画 / オーディオ）。一部は生成のため消費されます（テキストスクリプト → ホストリードオーディオ。ブリーフ → 合成画像。video\_brief → 生成動画）。セラーはスロットごとにディスパッチします。
* セラーの内部生成が生成 AI、ホスト録音、トランスコーディング、アセットレンダリングのいずれかは **バイヤーに不可視** です。
* 単一の正準フォーマット（例: `audio_hosted`）はバイヤーアップロードオーディオとエージェント生成オーディオの両方を処理します。フォーマットの `asset_source` と `buyer_asset_acceptance` パラメーターがどのフローが受け入れられるかを記述します。

オーディオフォーマットの並列比較:

```json test=false theme={null}
// v1: separate generated format file
{
  "format_id": { "agent_url": "...", "id": "audiostack_audio_30s_generated" },
  "name": "AudioStack 30s Audio (Generated)",
  "assets": [
    {
      "asset_id": "creative_brief",
      "asset_type": "brief",
      "required": true
    },
    {
      "asset_id": "audio_output",
      "asset_type": "audio",
      "required": false
    }
  ]
}

// v2: same canonical (audio_hosted), buyer-shipped assets declared as slots
{
  "format_kind": "audio_hosted",
  "params": {
    "duration_ms_exact": 30000,
    "audio_codecs": ["mp3"],
    "loudness_lufs": -16,
    "asset_source": "agent_synthesized",
    "buyer_asset_acceptance": "rejected",
    "slots": [
      { "asset_group_id": "creative_brief", "required": true, "asset_type": "brief", "max_chars": 1000 },
      { "asset_group_id": "voice_id", "required": false, "asset_type": "text" }
    ],
    "production_window_business_days": 0
  }
}
```

v2 マニフェストには別の `inputs` マップがないことに注意 — バイヤーはブリーフと voice\_id をそれらのスロット名の下で `assets` マップに `text`/`brief` アセットとして出荷します。セラーはフォーマットのスロット宣言に従いディスパッチします: ブリーフ → 合成のため消費。レンダーされたオーディオが反対側から出てくるものです。

## ブランドアイデンティティ — スロットが消える

v1 フォーマットはときどき `brand_logo`、`brand_colors`、`brand_voice`、`brand_tagline` を明示的なスロットとして再宣言しました。v2 フォーマットはしません。マニフェストが [`BrandRef`](https://adcontextprotocol.org/schemas/v3/core/brand-ref.json)（`brand: { domain: "acme.com" }`、house-of-brands にはオプションで `brand_id` 付き）を運ぶとき、セラーはコンテキストのため `brand.json` を自動的にフェッチします。

`brand.json` が欠けているか古いケースには、BrandRef 自体がインライン `brand_kit_override` を運びます（BrandRef が `industries` と `data_subject_contestation` に既に使う同じインラインオーバーライドパターン）:

```json test=false theme={null}
{
  "format_id": { "agent_url": "...", "id": "..." },
  "assets": { ... },
  "brand": {
    "domain": "acme.example",
    "brand_kit_override": {
      "logo": { "asset_type": "image", "url": "https://cdn.acme.example/logo-2026.png", "width": 200, "height": 100 },
      "colors": { "primary": "#0066CC", "accent": "#FF6600" },
      "tagline": "Spring savings, all season"
    }
  }
}
```

オーバーライドフィールドは、この BrandRef を運ぶ呼び出しについて `brand.json` より優先します。

## ツール — 何が新しいか対変わらないか

| Tool                    | v1                    | v2                                                                                                                                        |
| ----------------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `get_products`          | `format_ids` を持つ製品を返す | `format_ids`（v1 パス）または `format`（v2 インライン）のいずれかを持つ製品を返す                                                                                    |
| `sync_creatives`        | クリエイティブマニフェストを提出      | 変わらず。セールスエージェントはフォーマットの `slots` 宣言に従いスロット名でキーされた `assets` を持つマニフェストを受け入れる。                                                                |
| `preview_creative`      | マニフェストを提出、プレビューを得る    | 同じ表面。プレビューは、スロットがレンダーされたクリエイティブ（画像/動画/オーディオ）または生成コンテンツ（スクリプト/ブリーフ/video\_brief）を出荷するかにかかわらず出力を表示。#3268 の single-render hoist は v2 と並んで到達。 |
| `validate_input`        | （存在しなかった）             | 新しいバイヤードライランプリミティブ。レンダーにコミットせずに正準フォーマットや特定の製品に対してマニフェストを検証。安価。`predicted` フィールドがプリフライト推定を運ぶ。                                              |
| `build_creative`        | クリエイティブエージェントの生成ツール   | 同じ役割。クリエイティブエージェント表面のみ。セールスエージェントは `build_creative` を露出 **しない**。クリエイティブエージェントは広告サーバーユースケースのため `sync_creatives` を **も** 露出してもよい。           |
| `list_creative_formats` | セールスとクリエイティブエージェントの両方 | 非推奨。セールスエージェントは `get_products` に、クリエイティブエージェントは `creative.supported_formats` に移行。v1 ツールは 4.x を通じて機能。                                      |

## アダプター移行パス

### セールスエージェント（DSP、SSP、リテールメディアネットワーク、ウォールドガーデン）

1. **在庫**: 既存の v1 名前付きフォーマットを列挙。各々が 12 の v2 正準の 1 つまたはカスタム形状（下の「カスタムフォーマットの出荷」を参照）にマップすることを確認。合成/協調/スポンサーシップ形状（マルチプレースメントテイクオーバー、ロードブロック、ブランデッドコンテンツ、クロススクリーンスポンサーシップ、スポンサーシップロックアップ、ニュースレター、AR レンズ、プレイアブル、ライブイベントスポンサーシップ）は、`format_shape` レジストリ分類子と `format_schema` URI+ダイジェスト参照付き `format_kind: "custom"` として出荷。
2. **翻訳**: 各名前付きフォーマットについて、プラットフォームのパラメーターで正準を絞る v2 `ProductFormatDeclaration` を書く。カスタム形状には、フォーマットの `params` と `slots` を記述する JSON Schema を作成し、サブドメインの安定した URI（またはウォールドガーデンセラーには AAO ミラー経由）でホストし、`format_schema` から参照。
3. **ランタイム準備状況に正直に**: ランタイムパスがまだ完全に配線されていない各宣言に `experimental: true` を設定。懸念が「仕様がまだ落ち着いている」（正準レベル）か「私のランタイムが移行途中」（宣言レベル）かにかかわらず同じフラグ。バイヤーはデフォルトビューから `experimental: true` をフィルターすべき（SHOULD）。フラグを落とすまで v1 フォールバック（宣言の `v1_format_ref` または親製品の `format_ids` 経由）を優先すべき（SHOULD）。ランタイムが追いついたらフラグを落とす。
4. **テスト**: 翻訳された宣言を `/schemas/core/product.json` に対して検証（`npm run test:canonical-fixtures` パターンを使う）。
5. **デュアル公開**: v1 名前付きフォーマットと `list_creative_formats` を 4.x を通じて動作させ続ける。それを持つ製品に v2 `format_options` フィールドを追加。
6. **フラット化ラッパー**: v2 製品宣言から v1 `list_creative_formats` 形状を導出するサーバー側ラッパーを実装。v1 時代のダッシュボードとツールが動作し続けられる。
7. **非推奨タイミング**: 5.0 で、製品の v1 `format_ids` 参照を削除。それまでは両パスが共存。

#### サーバー側実装の考慮事項

v2 が導入する、既存のセラー実装が今日持たない 3 つの具体的なフック:

* **`provenance_required: true` のときの `sync_creatives` プロベナンス検証。** v2 製品のフォーマット宣言が `provenance_required: true` を運ぶ（そしてバイヤーのマニフェストが合成アセット — 通常生成プラットフォームからの動画/画像 — を含む）とき、`sync_creatives` は C2PA 互換プロベナンスマニフェストが添付されていることを検証し、署名されていない合成アセットを拒否しなければなりません（MUST）。これは Creative の既存の AI プロベナンストラッキング（EU AI Act Article 50 作業）の自然な拡張です — 新しい部分は提出をゲートする検証フックです。既存のプロベナンス配管を持たないセラーは、フラグが設定された v2 製品を出荷するまでこれを必要としません。それまでは no-op です。
* **`get_products` レスポンスが拡張定義を集める。** 製品が v2 `format.params.platform_extensions` 参照を運ぶとき、レスポンスは `<uri>@sha256:<digest>` でキーされた `extensions` マップに参照された拡張定義を含むべきです（SHOULD）。実装はレスポンス内の任意の製品が参照する拡張を集め、ダイジェストで重複排除し、発行します。バイヤーは URI\@digest でキャッシュします。後続のレスポンスはバイヤーが既にキャッシュした定義を省略してもよい（MAY）。製品が v2 宣言を使わないとき自明。テナントがオプトインするときのみ発動。
* **ホストリード / エージェント生成製品の `production_window_business_days`。** 今日ほとんどのサーバー実装は Products での生成ターンアラウンドをモデル化しません — フィールドは v2 の追加です。テナントが v2 ホストリードまたは生成動画製品（`asset_source: 'publisher_host_recorded'` の audio\_hosted、または `synthesis_nondeterministic: true` の任意の製品）を出荷するときのみ重要。今日これらのフローの多くは手動トラフィックされたスポンサーシップを通じてルーティングされ、プロトコル上でターンアラウンドを表示しません。v2 はそれを宣言可能にします。

#### カスタムフォーマットの出荷

12 の正準に適合しないクリエイティブ構造（マルチプレースメントテイクオーバー、ロードブロック、ブランデッドコンテンツ、クロススクリーンスポンサーシップ、スポンサーシップロックアップ、ニュースレタースポンサーシップ、AR レンズ、プレイアブル、ライブイベントスポンサーシップ）を持つセラーは `format_kind: "custom"` 経由で出荷します。3 部:

1. [語彙レジストリ](https://adcontextprotocol.org/schemas/v3/core/format-shape-vocabulary.json) から **`format_shape` を選ぶ**。あなたの形状がそこにない場合、語彙 PR を提出 — エントリー追加はガバナンスライトで、メジャーバージョンバンプを要求せず、ワーキンググループが形状ごとの採用速度を追跡するのを助ける。
2. フォーマットの `params` と `slots` を記述する **JSON Schema を作成**。スキーマの仕事は、バイヤーエージェントにマニフェストを検証しあなたが受け入れるアセット、どうトラックするか、インプレッションコントラクトが何かを推論する十分な構造を与えることです。v1 名前付きフォーマットファイルを作成するように扱ってください — 同じレベルの厳密さ、ただ AdCP の屋根の下ではなくあなたの URI でホストされる。業界共有スキーマ（例: 複数のパブリッシャーが収束する共有 `multi_placement_takeover_v1` スキーマ）は奨励され正準昇格を加速します。
3. `Cache-Control: public, max-age=31536000, immutable` とダイジェストで **安定した URI にスキーマをホスト**。オープンエコシステムパブリッシャーは自身のサブドメイン（`https://yourpub.example/schemas/formats/your_shape_v1`）でホスト。ウォールドガーデンセラーは `https://creative.adcontextprotocol.org/translated/<vendor>/<shape>` の AAO ミラーを通じてルーティング（AAO は翻訳提出を受け入れる。同じホスティング / 不変性コントラクト）。`ProductFormatDeclaration` の `format_schema: { uri, digest }` からスキーマを参照。

バイヤーエージェントは `uri@digest` でスキーマをフェッチし、キャッシュし（不変）、マニフェストを構造的に検証します。**バイヤーエージェントがあなたのフォーマットを解釈するのに human-in-the-loop は不要です** — それが荷重を担うクレームで、custom + format\_schema が `ext` でない理由です。Ext は、`format_shape` エントリーにさえまだ適合しない真に実験的な形状のために残りますが、それは稀なケースです。

2 つ以上のアダプターが実質的に類似した `format_schema` コンテンツで同じ `format_shape` を 90 日以上出荷するとき、ワーキンググループは形状をファーストクラス正準に昇格します（`/schemas/formats/canonical/<name>.json` を作成、`canonical-format-kind.json` に値を追加、レジストリエントリーを退役）。アダプターはその時点で `format_kind: "custom"` から `format_kind: "<canonical>"` に移行します。昇格キューは [adcp#3666](https://github.com/adcontextprotocol/adcp/issues/3666) で追跡されます。

### クリエイティブエージェント（Flashtalking、AudioStack、生成プラットフォーム、AI レンダリングサービス）

仕様は歴史的にセールスエージェントファーストで読まれてきました。v2 はクリエイティブエージェントパスを、独自のウォークスルーに値するほど再形成します — 広告サーバー形状のクリエイティブエージェント（Flashtalking、Innovid、Sizmek 級）と変換形状のクリエイティブエージェント（AudioStack、Pencil、AdCreative.ai 級）の両方について。

#### v2 でクリエイティブエージェントに何が変わるか

| Concern                 | v1                                                                                                                              | v2                                                                                                                                                                                                                                                                                                                                      |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| フォーマットカタログ公開            | `list_creative_formats` があなたの生成可能なカタログを返した。セールスエージェントは自身の `list_creative_formats` の `creative_agents[]` 再帰ディスカバリーヒント経由でそれを参照できた | `get_adcp_capabilities` の `creative.supported_formats`（各エントリーは `ProductFormatDeclaration` — セールスエージェントの製品 `format_options[i]` と同じ形状）。v1 `list_creative_formats` は 4.x を通じて機能。                                                                                                                                                           |
| フォーマット作成                | `your-domain.example` の下でキーされた名前付きフォーマットを作成し公開した                                                                                | あなたが生成できる AdCP 定義の正準フォーマット（`format_kind` 判別子）をプラットフォーム固有の絞り込み（`params`）で宣言。もうフリーテキスト名前付きフォーマットを公開しない。                                                                                                                                                                                                                                   |
| ディスカバリー                 | セールスエージェントが `creative_agents[]`（再帰クエリ）経由でバイヤーをあなたに向けた。バイヤーはあなたが生成するものを学ぶためあなたの `list_creative_formats` をフェッチ                    | バイヤーはあなたに直接到達 — ブランド側関係、AAO レジストリ、直接知識を通じて。v2 のセールスエージェントは「承認されたクリエイティブエージェント」のリストを運ばない。各側は独立。                                                                                                                                                                                                                                          |
| `build_creative` コントラクト | バイヤーは `format_id` + `assets` + `inputs`（別の「生成入力」マップ）付きマニフェストを出荷                                                                 | バイヤーは同じエンベロープを出荷するが、`inputs` は `assets` に崩れる — すべてが正準 `asset_group_id` でキーされた 1 つの `assets` マップを通る。フォーマットの `slots` 宣言がどのアセットを期待するかを伝え、各々が `asset_type` で型付けされる。セラー（あなた）はスロットごとにディスパッチ — `image` / `video` / `audio` スロットはそのままレンダー。`text` / `brief` / `object` スロットは生成のため消費（例: `script` テキスト → ホスト録音オーディオ。`creative_brief` ブリーフ → 生成画像）。 |
| 生成ソース宣言                 | 暗黙（名前付きフォーマットの名前がモデルを含意した — AI 生成には `*_generated_*`）                                                                            | 正準ごとに明示的: `asset_source` enum が誰がいつレンダーするかを宣言（`buyer_uploaded` / `publisher_host_recorded` / `seller_pre_rendered_from_brief` / `seller_human_designed` / `agent_synthesized`）。プラス、合成後 QA ループセマンティクスを必要とする Veo/Sora 級フローの `synthesis_nondeterministic: true`。                                                                           |
| トラッキング統合                | プラットフォームのピクセル ID、ビューアビリティベンダー、OM-SDK パートナーが名前付きフォーマットの `tracking_events` フィールドに存在。セラーとバイヤーがあなたのフリーテキスト宣言を解析                     | 各 `supported_formats[].format` の `platform_extensions: [{uri, digest}]` 経由で宣言。各拡張はあなたがホストする（または AAO ミラーが翻訳する）、プラットフォームのトラッキング表面（ピクセル ID、コンバージョンイベント分類）のスキーマを記述する URI。拡張の `extends: "tracking"` メタデータは、バイヤーが別の `tracking_extensions` 配列なしにトラッキング関連エントリーをフィルターできるようにする。セラーとバイヤーは `uri@digest` でキャッシュ。SDK コード生成が型付き拡張ハンドラーを生成。             |
| 生成バイトのホスティング            | あなたの CDN、あなたの判断                                                                                                                 | あなたの CDN、あなたの判断。v2 分解は概念的（仕様は生成をサービングからトラッキングから分離） — 運用的には、`build_creative` から返すマニフェストの生成アセット URL は引き続きあなたの CDN を指し、あなたのトラッキング JS が引き続きインストルメントし、あなたのプラットフォーム拡張が統合を文書化。                                                                                                                                                                 |

#### 具体例: Flashtalking 形状のクリエイティブエージェント

複数のサイズと表面全体で画像 / VAST / html5 クリエイティブを生成するクリエイティブエージェント。v2 前は、30 以上の名前付きフォーマット（サイズ × 表面の組み合わせごとに 1 つ）を公開しました。v2 はより小さい `supported_formats` セットに崩れます:

```json test=false theme={null}
// GET https://flashtalking.example/.well-known/agent.json
// → get_adcp_capabilities response (excerpt)
{
  "creative": {
    "supports_generation": true,
    "supports_transformation": true,
    "has_creative_library": true,
    "supported_formats": [
      {
        "capability_id": "flashtalking_image_iab_standard",
        "format": {
          "format_kind": "image",
          "params": {
            "image_formats": ["jpg", "png", "gif"],
            "max_file_size_kb": 200,
            "ssl_required": true,
            "asset_source": "buyer_uploaded",
            "platform_extensions": [
              { "uri": "https://flashtalking.example/extensions/flashtalking_pixel_v2", "digest": "sha256:..." }
            ]
          }
        }
      },
      {
        "capability_id": "flashtalking_video_vast_42",
        "format": {
          "format_kind": "video_vast",
          "params": {
            "vast_version": "4.2",
            "duration_ms_range": [6000, 60000],
            "linear_required": true,
            "ssl_required": true,
            "platform_extensions": [
              { "uri": "https://flashtalking.example/extensions/flashtalking_vpaid_2_0", "digest": "sha256:..." }
            ]
          }
        }
      },
      {
        "capability_id": "flashtalking_html5_iab_standard",
        "format": {
          "format_kind": "html5",
          "params": {
            "max_initial_load_kb": 200,
            "om_sdk_required": true,
            "backup_image_required": true,
            "ssl_required": true
          }
        }
      }
    ]
  }
}
```

何が消えるか: 30 以上の名前付きフォーマットファイル、それぞれが自身の `tracking_events` 配列、自身のスロット語彙を持つ。何が置き換えるか: Flashtalking 固有トラッキングのため params + platform\_extensions で絞られた 3 つの正準宣言。バイヤー側の SDK コード生成は、Flashtalking 名前付きフォーマットごとの型付きハンドラーではなく `format_kind` ごとの型付きハンドラーを生成 — Flashtalking を統合するバイヤーの表面積の 10 倍の削減。

バイヤーフローは Flashtalking の視点から変わりません: `build_creative` は依然としてブリーフ / アセット / ブランド参照を受け取ります。あなたは Flashtalking の CDN のレンダーされたアセット URL でマニフェストを生成します。バイヤーはそのマニフェストを出荷先の任意のセールスエージェントに提出します。セールスエージェントは正準 `image` / `video_vast` / `html5` に対して検証 — あなたの Flashtalking 絞り込みに対してではありません。あなたの platform\_extensions はマニフェストに添付されたままなので、セールスエージェントはサーブ時に Flashtalking ピクセル ID とビューアビリティベンダーを尊重します。

#### 具体例: AudioStack 形状の変換エージェント

バイヤーのブリーフまたはスクリプトを取りレンダーされたオーディオファイルを生成する変換エージェント。v2 前は、AudioStack は `audiostack_audio_30s_generated` などを公開しました。v2 は明示的な生成ソースセマンティクスを持つ正準ごとの宣言に崩れます:

```json test=false theme={null}
// GET https://audiostack.example/.well-known/agent.json
{
  "creative": {
    "supports_generation": true,
    "supports_transformation": true,
    "supported_formats": [
      {
        "capability_id": "audiostack_audio_brief_to_30s",
        "format": {
          "format_kind": "audio_hosted",
          "params": {
            "duration_ms_exact": 30000,
            "audio_codecs": ["mp3", "aac"],
            "audio_sample_rates": [44100, 48000],
            "audio_channels": ["stereo"],
            "loudness_lufs": -16,
            "asset_source": "seller_pre_rendered_from_brief",
            "buyer_asset_acceptance": "rejected",
            "production_window_business_days": 1,
            "slots": [
              { "asset_group_id": "creative_brief", "asset_type": "brief", "required": true, "max_chars": 500 },
              { "asset_group_id": "voice_id", "asset_type": "text", "required": false },
              { "asset_group_id": "landing_page_url", "asset_type": "url", "required": false }
            ]
          }
        }
      },
      {
        "capability_id": "audiostack_audio_script_to_30s",
        "format": {
          "format_kind": "audio_hosted",
          "params": {
            "duration_ms_exact": 30000,
            "audio_codecs": ["mp3"],
            "asset_source": "agent_synthesized",
            "buyer_asset_acceptance": "rejected",
            "synthesis_nondeterministic": false,
            "production_window_business_days": 0,
            "slots": [
              { "asset_group_id": "script", "asset_type": "text", "required": true, "max_chars": 800 },
              { "asset_group_id": "voice_id", "asset_type": "text", "required": true }
            ]
          }
        }
      }
    ]
  }
}
```

2 つの別個のクリエイティブエージェントケイパビリティ — brief-to-audio（クリエイティブディレクション → 生成された広告）と script-to-audio（そのままのスクリプトからの決定的 TTS） — が `format_kind: audio_hosted` を共有するが異なる `asset_source` 値を持つ 2 つの `supported_formats` エントリーとして宣言されます。`capability_id` は、バイヤーが `build_creative` を呼ぶときどのビルドパスを呼び出しているかを曖昧性解消します。これは、購入可能な製品またはパブリッシャーカタログフォーマットオプションを選択するメディアバイ `format_option_id` とは別です。

#### クリエイティブエージェントのサーバー側フック

v2 のクリエイティブエージェント固有の 3 つの実装考慮事項:

* **`creative.supported_formats` はあなたの公開コントラクトです。** バイヤーとセールスエージェントは、あなたが何を生成するかを知るためそれを読みます。リリース全体で `capability_id` 値を安定に保つ — バイヤーは `build_creative` 呼び出しでそれらを参照します。
* **`synthesis_nondeterministic: true` は QA ループ義務を含意します。** それを宣言するとき、あなたは以下にコミットします: 各合成試行をフォーマットのパラメーター制約に対して検証。スペック内出力を生成するため最大 N 回再シード。ループが尽きた場合 `synthesis_failed` 理由で `task_failed` を返す。孤立したスペック外アーティファクトのプロトコル状態はありません — バイヤーは部分的結果を決して見ません。
* **`provenance_required: true` は C2PA 証明を要求します。** セールスエージェントの製品が `provenance_required: true` を運びバイヤーがあなたの生成アセットを出荷しているとき、あなたが返すマニフェストは、合成をあなたのエージェント（バイヤーでもセラーでもない）に帰属させる C2PA 互換プロベナンスマニフェストを含まなければなりません（MUST）。EU AI Act Article 50 アライメント。

#### クリエイティブエージェントの移行タイミング

| Item                                                       | Timing                                                                                                      |
| ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| `list_creative_formats`（v1）を露出し続ける                         | 4.x を通じて。セールスエージェントとバイヤーはまだ呼べる。                                                                             |
| `get_adcp_capabilities` に `creative.supported_formats` を追加 | 3.1+ のいつでも。追加的 — v1 呼び出し元を壊さない。                                                                             |
| 新しい v1 名前付きフォーマットの公開を停止                                    | バイヤーの 80% が `supported_formats` を読むとき（自身の分析で追跡 — `get_adcp_capabilities` を呼ぶバイヤー対 `list_creative_formats`）。 |
| `list_creative_formats` を落とす                               | v1 非推奨カレンダー（2027-Q4 フロア / 2029-Q1 シーリング）と調整 — セールスエージェントが `format_ids` を落とすのと同じウィンドウ。                       |

### バイヤー / DSP

1. 製品の `format_ids`（v1）または `format`（v2 インライン）のいずれかを読むようクライアントを更新。
2. レンダーにコミットする前に安価なドライラン検証のため `validate_input` を使う。
3. マニフェストを構築するとき正準 [`asset_group_id` 語彙](https://adcontextprotocol.org/schemas/v3/core/asset-group-vocabulary.json) を使う。レジストリの `aliases` フィールドが v1 時代のスロット名を正準同等物にマップ。
4. 以前通り `sync_creatives` 経由でクリエイティブを提出。スロットが生成コンテンツを受け入れる製品（ホストリードポッドキャストは `script` テキストアセットを出荷。生成動画は `creative_brief` と `video_brief` を出荷）には、クリエイティブエージェントの `build_creative` 経由で事前生成してレンダーされたアセット付きマニフェストを取り戻すか、生成コンテンツアセットを直接提出しセラーに内部で生成させる — 両方のフローが有効。

### パブリッシャーダイレクト（GAM/prebid パス）

1. `zip` アセットタイプ（asset-vocabulary Phase 1）が HTML5 バナーバンドルをきれいに処理。URL 配信の HTML/JS は適切な `url_type` で `url-asset.json` を通してルーティング。
2. タグベース配信（VAST、サードパーティディスプレイタグ）が `display_tag`、`video_vast`、`audio_daast` 正準フォーマットにマップ。
3. ネイティブ正準フォーマットは TemplateCreative + OpenRTB Native 1.2 監査の後 3.2 に延期。それまでネイティブフォーマットは v1 パスに留まる。

## アダプタータイプ別の現実的タイムライン

| Adopter                                             | Cost       | Realistic timeline                                 |
| --------------------------------------------------- | ---------- | -------------------------------------------------- |
| DSP バイヤーエージェント（TTD 形状）                              | 低          | 3.1-3.2                                            |
| SSP/セールスエージェント（Magnite、PubMatic、リテールメディア）           | 中〜高        | 3.3-4.0                                            |
| ウォールドガーデン（Meta、Google、Amazon、TikTok、Snap、Pinterest） | 高、低モチベーション | もしあれば 4.0-5.0（AAO が既存フォーマットドキュメントから翻訳者を提供することにゲート） |
| クリエイティブエージェント（AudioStack 形状）                        | 低、高モチベーション | 3.1-3.2                                            |
| パブリッシャーダイレクト（GAM/prebid パス）                         | 中          | ネイティブ正準事前監査でブロック                                   |

### v1 `format_ids` はいつ削除されるか?

`Product` の `oneOf(format_ids, format_options)` 形状は 4.x を通じて持続 — すべての検証者、コード生成、アダプターが両方の形状を処理しなければならない。5.0 カットは **採用駆動、カレンダーフロアとシーリング付き**:

* **フロア（最小 end-of-life）**: v1 `format_ids` は採用シグナルにかかわらず少なくとも **2027-Q4** を通じてサポート。組織の現実（レガシー広告サーバー統合、ウォールドガーデン翻訳ギャップ、遅い調達サイクル）が即座の移行を妨げるアダプターは、3.1 GA から無条件の 18 か月のランウェイを得る。
* **シーリング（最大 end-of-life）**: v1 `format_ids` は採用シグナルにかかわらず **2029-Q1** より遅くない時に削除。SDK 作者と検証者メンテナーのロングテール負債を上限とする。3.0 の v2-sunset-policy パターンに一致。
* **採用トリガー（フロア / シーリングウィンドウ内）**: AAO はキャッシュされた `get_products` ケイパビリティレスポンスから `format_options` を宣言するセールスエージェント（対 `format_ids`）の比率を計算。トリガーは分母 = `supported_protocols` に `creative` を宣言するセールスエージェント。分子 = 最新の `get_products` レスポンスがすべての製品に `format_options` を運ぶもの。比率が **80% を超えフロア/シーリングウィンドウ内で 30 連続日そこに留まる** とき、5.0 カットシーケンスが開く（非推奨警告がエスカレート。次のメジャーが `format_ids` を落とす）。そのシグナルがトリップするまで両方の形状が有効なまま。

トリガーメトリック、分母、リフレッシュ頻度、認定パスは `https://adcontextprotocol.org/registry/format-options-adoption.json` で公開されます（具体的な形状とリフレッシュ頻度は 3.1 GA 前のフォローアップ issue でコミット予定）。タイミングに影響したいアダプターは早期に移行し公開比率を見るべきです。移行しないウォールドガーデンはシーリングに吸収されます。

### v1 ↔ v2 全体の `creative_id` 安定性

v1 `format_id` に対して登録されたクリエイティブは、後で v2 フラット化パス経由で表示されるとき同じ `creative_id` を保持します。`sync_creatives` リクエストとレスポンス形状は変わりません。マニフェストエンベロープは変わりません。移行は読み取り側です: 既存のクリエイティブは動作し続け両パスを通じて同一に解決します。フラット化ラッパーを構築する SDK 作者はこの不変条件を尊重しなければなりません（MUST）。

## `product_card` と `product_card_detailed` はインラインで型付け

`Product` オブジェクトの `product_card` と `product_card_detailed` フィールドは v2 でインライン型付き構造です — `format_id` 間接なし、マニフェストなし。それらは **製品自体の UI レンダリング**（カタログブラウザー、ダッシュボード、管理インターフェースが、人間とエージェントが製品が何かを見られるよう表示するもの）を記述します。`format`（製品が受け入れる広告クリエイティブを記述）とは別。

```json test=false theme={null}
"product_card": {
  "image": { "asset_type": "image", "url": "https://...", "width": 300, "height": 400 },
  "title": "Meta Reels — United States",
  "description": "9:16 vertical short-form video on Meta Reels.",
  "price_label": "From $5.50 CPM",
  "cta_label": "View details"
}

"product_card_detailed": {
  "hero_image": { "asset_type": "image", "url": "...", "width": 1200, "height": 600 },
  "carousel_images": [ { "asset_type": "image", "url": "...", ... }, ... ],
  "title": "Meta Reels — United States",
  "description": "Full markdown-friendly product description...",
  "specifications": [
    { "label": "Aspect ratio", "value": "9:16" },
    { "label": "Duration", "value": "3-90s" }
  ],
  "price_label": "From $5.50 CPM",
  "cta_label": "Get proposal"
}
```

v1 からの移行（`product_card` が `product_card_standard` フォーマットファイルを参照する `{ format_id, manifest }` だった）: フォーマット参照を落とす。型付きフィールドを直接投入。画像、タイトル、説明は以前マニフェストだったものからフラット化されます。製品カードをレンダーしない v2 のみのアダプターは両フィールドを完全に無視できます。

## OpenRTB が与えないものを v2 が与えるもの

既存の OpenRTB Native / Display / Audio パイプラインを持つアダプターは、「動作するクリエイティブスペックモデルを既に持っているのになぜ v2 に移行するか?」と合理的に尋ねます。差分価値:

* **バイヤーはセラーの絞り込みではなく正準に対して検証する。** OpenRTB には正準層がありません。各 SSP が自身のネイティブアセットスペックを作成（Native 1.2 はプレースメント固有アセットを「実装を見よ」に残した）。各動画プレイヤーが自身の VAST 拡張を作成。各リテールメディアネットワークが自身のカタログフィールド形状を公開。バイヤーはランタイムにセラーごとのスペックを発見し検証しなければならない。v2 の canonical-as-contract は、バイヤー検証をセラーごとのスキーマディスカバリーから分離 — バイヤーは正準 `image` を満たすマニフェストを出荷し、どのセラーがオークションに勝つかを知る前に、その正準を話す任意のセラーに対して構造的に有効であることを知る。
* **ディスカバリーは暗黙ではなく運用的。** OpenRTB Display 1.x と Native 1.2 は、アダプターが仕様を読み、バージョンごとのハンドラーを書き、各セラーが要求するかもしれないもののサポートを事前焼き込みすることを期待。v2 は製品（`get_products` の `format_options[i]`）とクリエイティブエージェント（`get_adcp_capabilities` の `creative.supported_formats`）にフォーマット宣言をインラインで運ぶ。バイヤーはランタイムに受け入れられるものをフェッチ。SDK コード生成が正準の型付きハンドラーを生成。新しいセラーはバイヤー側コード変更を要求しない。
* **生成ソースはファーストクラス。** OpenRTB には「バイヤーがブリーフを出荷。セラーがレンダー」の概念がない。最も近い表現は提出後の OpenRTB Native の `nobid_reason`。v2 は生成ソースを宣言されたパラメーター（`*_source` enum）にするため、生成 DSP とホストリード製品が拒否後だけでなくディスカバリー時に可視。
* **トラッキングモデルは正準定義。** OpenRTB トラッキング（インプレッション NURL、クリック NURL、サードパーティトラッカー）は VAST には一貫だがネイティブとディスプレイには断片化。v2 はトラッキングモデルを各正準に焼き込む（image のインプレッションピクセル、html5 の MRAID + OM-SDK、video\_vast の VAST イベント、image\_carousel のカードごとピクセル） — バイヤーは正準だけからどのトラッキング形状が適用されるかを知る。

v2 はオークション層で OpenRTB を置き換えません（そこで OpenRTB Display、Video、Audio 仕様が引き続きビッドリクエスト / レスポンス形状を駆動）。v2 はオークションの上のクリエイティブペイロード層で、OpenRTB が意図的に実装固有に残したものを追加します。

## 移行の検証

翻訳された製品に対してフィクスチャ検証を実行:

```bash test=false theme={null}
npm run test:canonical-fixtures
```

`static/examples/products/canonical/` のリファレンスフィクスチャは `/schemas/core/product.json` に対して検証されます。アダプターは自身の翻訳された製品を兄弟ディレクトリにドロップし同じ検証者パターンを再利用できます。

## 関連

* [正準フォーマット概要](/docs/creative/canonical-formats)
* [RFC #3305](https://github.com/adcontextprotocol/adcp/issues/3305) — アーキテクチャ決定と根拠
* [アセットグループ語彙](https://adcontextprotocol.org/schemas/v3/core/asset-group-vocabulary.json)
* [BrandRef スキーマ](https://adcontextprotocol.org/schemas/v3/core/brand-ref.json)
* [ユニバーサルマクロ](/docs/creative/universal-macros) — 正準トラッキングから参照される置換パターン
