> ## 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 3.1 に存在する。セラーの製品はそれをインラインで絞り、未成熟な正準と製品宣言に experimental フラグを付ける。

# 正準フォーマット

> **冷静に読むアダプター向け TL;DR:**
>
> * **12 の正準フォーマットのうち 9 が 3.1 GA で非実験的に出荷**（`image`、`html5`、`display_tag`、`image_carousel`、`video_hosted`、`video_vast`、`audio_hosted`、`audio_daast`、`native_in_feed`）。3 つの正準は GA を過ぎても実験的のまま（`sponsored_placement`、`responsive_creative`、`agent_placement`）。`custom` エスケープハッチ `format_kind` は形状が昇格されるまで本質的に実験的。
> * **v1 名前付きフォーマットはファーストクラスのまま** 4.x を通じて、5.0 サンセットフロア付き。デュアル発行が移行モード。SDK はどちらの方向にも翻訳する。現実的な v2 のみバイヤーエージェントのタイミングは最速で 4.x。
> * **GA で 15 の v1→v2 マッピングレジストリエントリー、監査された v1 フォーマットの 71+ が最初は v1 のみ**（v2 に投影するにはセラー `canonical` フィールドまたはレジストリ PR が必要）。v2 対応バイヤーは 3.x を通じて v1 対応バイヤーより意味あるほど薄い在庫を見る。デュアル読み取りコードパスは 3.3 を通じて現実的。
> * **SDK コード生成が人間工学的アダプター消費のゲートとなる依存関係。** スキーマは今日出荷可能。この設計が得る型付きタグ付き union の人間工学はコード生成でのみ完全に到達する。ランタイム Ajv 検証者が荷重を担うゲート — 生成された TS/Pydantic 型は `format_kind: "custom"` と `result_kind` で `if/then` 絞り込みを失う。

> **ステータス:** AdCP 3.1 で出荷。エージェントが `supported_versions` でそれをアドバタイズすることを確認した後、ワイヤーピン `"3.1"` を使う。3 つの正準プラス `custom` は、アダプター証拠が昇格をサポートするまで `experimental` とマークされたまま。歴史的な設計コンテキストは [RFC #3305](https://github.com/adcontextprotocol/adcp/issues/3305) と [#3307](https://github.com/adcontextprotocol/adcp/pull/3307) に存在する。
>
> *命名ノート*: この作業は元々「クリエイティブフォーマット v2」としてドラフトされた — v1↔v2 対比は 2 つのフォーマット作成モデル（レガシー名前付きフォーマットレジストリ対製品上の新しい正準フォーマット）を記述する。AdCP プロトコル自体のバージョン番号付け（現在 3.x）との衝突を避けるため、ファイルパス、識別子、この文書の本文は **正準フォーマット** 用語を使う。v1↔v2 対比は、`Product.format_ids` 対 `Product.format_options` の 2 つの作成パスを曖昧性解消するスキーマ記述の略記として予約される。

正準フォーマットは、今日の別々のフォーマットレジストリを製品バインド宣言に崩します。AdCP は小さな **正準フォーマット** のセット（ユニバーサルビルディングブロック）を定義します。セラーの製品は、プラットフォーム固有のパラメーターで正準を絞るインライン `ProductFormatDeclaration` を運びます。クリエイティブエージェントは、正準フォーマットをターゲットする `build_creative` ケイパビリティを宣言する変換サービスになります。ほとんどの既存概念（CTA、デスティネーション、トラッキング、ブランドアイデンティティ）は再利用されるか現在の居場所に留まります — 正準フォーマットはそれらのための新しい語彙層を作りません。

実践的な作成練習には、これを複製する代わりにこのリファレンスにリンクする [S2 クリエイティブスペシャリストモジュール](/docs/learning/specialist/creative) を使ってください。

## 用語集

| Term                                             | One-line definition                                                                                                                                                                                                                                                                                                                                                                                                              |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **正準フォーマット**                                     | 製品が絞る 12 の AdCP 定義フォーマットアーキタイプの 1 つ（例: `image`、`video_vast`、`audio_hosted`、`native_in_feed`）。バイヤーの安定した検証ターゲット。                                                                                                                                                                                                                                                                                                                   |
| **`format_kind`**                                | 正準フォーマットを名指す判別子値（例: `"image"`）。どの正準のパラメータースキーマが適用されるかを選択。                                                                                                                                                                                                                                                                                                                                                                        |
| **`format_options`**                             | 製品上の、完全な `ProductFormatDeclaration` の配列。90% のケースは単一要素。複数要素は「いずれかを受け入れる」を宣言。製品エントリーは宣言で、素の参照ではない。                                                                                                                                                                                                                                                                                                                                 |
| **`ProductFormatDeclaration`**                   | インラインフォーマット宣言: 必須 `format_kind` + 必須 `params` + オプション `format_option_id`（エントリーが `format_kind` を共有するとき必須。3.1 に従いすべてのエントリーに設定すべき（SHOULD）で、V2 バイヤーが `PackageRequest.format_option_refs[]` 経由で製品に対して作成できる）+ パブリッシャーカタログバックのオプションのためのオプション `publisher_domain` + オプション `applies_to_channels` + オプション `experimental` + オプション `v1_format_ref`（常に配列 — 下記参照）。カタログバックのときでも、製品は依然として完全な宣言を運ぶ。                                                |
| **`v1_format_ref`**                              | v2 宣言を 1 つ以上の v1 名前付きフォーマットにリンクする `{agent_url, id}` 参照の配列。常に配列。単一参照は `[{...}]`。マルチサイズ宣言はサイズごとに 1 参照を運ぶ（下の「マルチサイズファンアウト」を参照）。                                                                                                                                                                                                                                                                                                     |
| **`canonical:` アノテーション**                         | v1 カタログエントリーの投影アノテーション。常にオブジェクト形式 — `{ kind: "image" }` 最小、v1 形状が正準のデフォルトに従わないエントリー（生成、ブリーフ駆動）には `{ kind, asset_source, slots_override }` リッチ形式。決して素の文字列でない。                                                                                                                                                                                                                                                                     |
| **兄弟絞り込み原則**                                     | 新しい正準に手を伸ばす前に、`asset_source` + `slots_override` + `applies_to_channels` + event\_log 表面がケースをカバーするかチェック。適用: 生成（image + asset\_source: agent\_synthesized）、公開投稿参照（video\_hosted/image/native\_in\_feed + asset\_source: publisher\_owned\_reference + published\_post スロット）、放送 TV（video\_hosted + applies\_to\_channels: \["tv"]）、DOOH（image + applies\_to\_channels: \["dooh"]）、ネイティブ（image + slots\_override）。それらのいずれにも新しい正準なし。  |
| **`format_option_id`**                           | その名前空間内のフォーマット宣言の安定した識別子。`format_options` が同じ `format_kind` を共有する複数の宣言を運ぶとき必須（曖昧性解消のため）。すべての `format_options[]` エントリーに設定すべき（SHOULD） — 衝突で強制されるときだけでなく — V2 メンタルモデルバイヤーが `PackageRequest.format_option_refs[]` と `creative-manifest.format_option_ref` 経由で製品に対して作成できるように。パブリッシャーカタログバック宣言は `publisher_domain` を運ぶ。製品ローカル宣言はそれを省略。選択可能な `format_option_id` 値なしでは、製品は依然として 3.1 適合だが V2 作成パスは到達不可能でバイヤーは v1 `format_ids[]` にフォールバック。 |
| **`FormatOptionRef`**                            | 製品フォーマットオプションの判別されたバイヤー向けセレクター、`PackageRequest.format_option_refs[]` やマニフェストのようなリクエストで使う。パブリッシャーカタログバックのオプションには `{scope: "publisher", publisher_domain, format_option_id}` を使う。製品ローカルオプションには `{scope: "product", format_option_id}` を使う。製品スコープの参照はターゲット製品/パッケージ内でのみ解決し、セラー全体、製品横断、パブリッシャー横断の名前空間ではない。これはリクエスト側の参照形状で、製品宣言形状ではない。                                                                                                 |
| **`applies_to_channels`**                        | このフォーマット宣言が適用される製品の宣言されたチャネルのサブセット。マルチチャネル製品がチャネルごとのフォーマットオプションを運べるようにする。                                                                                                                                                                                                                                                                                                                                                        |
| **`experimental`**                               | 正準（`_base.json`）と `ProductFormatDeclaration` 上のブール。`true` = 宣言通りに動作しないかも。v1 フォールバックを準備。以前の `status` + `runtime_status` enum を置き換える（2 つの安定性軸ではなく単一のバイナリフラグ）。                                                                                                                                                                                                                                                                      |
| **`slots`**                                      | マニフェストが投入しなければならない（またはしてもよい）`asset_group_id` スロットのフォーマット上のプログラマティック宣言、各々が `asset_type` とペア。                                                                                                                                                                                                                                                                                                                                      |
| **`asset_group_id`**                             | 正準スロット名語彙（例: `image_main`、`script`、`landing_page_url`）。v1 のフリーテキスト `asset_role` を置き換える。                                                                                                                                                                                                                                                                                                                                          |
| **`composition_model`**                          | 表面がインプレッションごとにどう合成するか: `deterministic`（バイヤー予測可能スロットごと）対 `algorithmic`（表面がプールから組み合わせを選ぶ）。                                                                                                                                                                                                                                                                                                                                         |
| **`synthesis_nondeterministic`**                 | true のとき、生成パイプラインはスペック内出力を保証できない（Veo/Sora 級）。QA ループ + リトライセマンティクスを含意。                                                                                                                                                                                                                                                                                                                                                            |
| **`provenance_required`**                        | true のとき、製品は署名されていない合成アセットを拒否。ビルダーは C2PA 互換プロベナンスマニフェストを添付。                                                                                                                                                                                                                                                                                                                                                                      |
| **`platform_extensions`**                        | 正準を絞るプラットフォーム固有拡張への URI+ダイジェスト参照（ピクセル ID 形状、コンバージョンイベント分類）。                                                                                                                                                                                                                                                                                                                                                                      |
| **`asset_source`**                               | 生成ソース宣言: 誰がソースアセットをレンダーまたは所有するか。`image` / `video_hosted` / `audio_hosted` 全体の共有 enum は `buyer_uploaded`、`publisher_host_recorded`、`seller_pre_rendered_from_brief`、`seller_human_designed`、`agent_synthesized`、`publisher_owned_reference` を含む。`sponsored_placement` の `item_production_model` は同じ軸を 4 値サブセットでカバー（host-recorded と published-post 参照セマンティクスを落とす）。                                                                 |
| **正準成熟度**                                        | 3.1 は別の `stable` / `preview` ステータス軸の代わりに `experimental` ブールを使う。非実験的正準はデフォルト本番パス。実験的正準と `custom` は予算をルーティングする前に追加検証が必要。                                                                                                                                                                                                                                                                                                           |
| **`since_version` / `migration_target_version`** | 正準上のリリース精度ライフサイクルメタデータ — いつ導入されたか、いつ安定化または破壊的改訂が期待されるか。                                                                                                                                                                                                                                                                                                                                                                          |
| **`validate_input`**                             | 仕様定義ドライランプリミティブ — バイヤーはレンダーにコミットせずに正準/製品に対してマニフェストを検証。                                                                                                                                                                                                                                                                                                                                                                           |
| **`build_creative`**                             | 入力（ブリーフ、video\_brief、ブランド）からマニフェストを生成するクリエイティブエージェント表面。セールスエージェントは `build_creative` を露出 **しない**。                                                                                                                                                                                                                                                                                                                                 |
| **`creative.supported_formats`**                 | `build_creative` 経由で生成できる正準を宣言するクリエイティブエージェントのケイパビリティレスポンスフィールド。                                                                                                                                                                                                                                                                                                                                                                 |
| **`BrandRef`**                                   | `{domain, brand_id?}` 参照。`brand.json` からブランドコンテキスト（ロゴ、カラー、ボイス）を自動的に解決。                                                                                                                                                                                                                                                                                                                                                           |
| **`brand_kit_override`**                         | `brand.json` が欠けている、古い、または不適切な場合の呼び出しごとブランドキット微調整（ロゴ、カラー、ボイス、タグライン）のための `BrandRef` 上のインラインオーバーライド。BrandRef の `industries` と `data_subject_contestation` と同じパターン。                                                                                                                                                                                                                                                                 |
| **`fanout_mode`**                                | `sponsored_placement` 上: アイテムが配信にどうマップするか — `per_item`、`multi_item_in_creative`、`single_item`。                                                                                                                                                                                                                                                                                                                                   |
| **`item_production_model`**                      | `sponsored_placement` 上: 各アイテムごとクリエイティブがどう生成されるか。マルチ出力生成を捕捉（1 ブリーフ × N アイテム → N クリエイティブ）。                                                                                                                                                                                                                                                                                                                                        |
| **`format_kind: "custom"`**                      | 12 の正準に適合しないアダプター定義形状（マルチプレースメントテイクオーバー、ブランデッドコンテンツ、AR レンズなど）。`format_shape`（レジストリ分類子）と `format_schema`（フェッチ可能なスキーマへの URI+ダイジェスト参照）を要求。                                                                                                                                                                                                                                                                                          |
| **`format_shape`**                               | [format-shape 語彙レジストリ](https://adcontextprotocol.org/schemas/v3/core/format-shape-vocabulary.json) からの認識されたグローバルパターン。`format_kind: "custom"` のとき必須。                                                                                                                                                                                                                                                                              |
| **`format_schema`**                              | カスタム形状の `params` と `slots` を記述するフェッチ可能なスキーマへの URI+ダイジェスト参照。`format_kind: "custom"` のとき必須。`platform_extensions` と同じホスティングモデル。                                                                                                                                                                                                                                                                                                     |

## アーキテクチャシフト

| Concept        | v1                                                                                                            | v2                                                                                                                                                                                                                                                                                                                                                 |
| -------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| フォーマットアイデンティティ | 別途定義されたフォーマットファイルを参照する複合 `{ agent_url, id }`                                                                  | 製品の `format` 下でキーされた正準名（例: `image`）、インラインで絞られる                                                                                                                                                                                                                                                                                                     |
| フォーマット作成       | 各プラットフォームが自身の名前付きフォーマットファイルを作成                                                                                | プラットフォームが AdCP 定義の正準を絞る。正準がバイヤーが検証するコントラクト                                                                                                                                                                                                                                                                                                         |
| フォーマット提出コントラクト | 各プラットフォームがアセットアップロード版と並んで AI 生成クリエイティブのため `*_generated_*` フォーマットファイルの並行セットを公開（agentic-adapters に約 30 の重複ファイル） | フォーマットは、マニフェストの `assets` マップでバイヤーが出荷するすべてを列挙する単一の `slots` 配列を宣言、各エントリーは `asset_type` とペアの正準 `asset_group_id`（直接レンダリングには image / video / audio。セラーが生成のため消費するコンテンツには text / brief / object / url）。バイヤーメンタルモデルは一様 — 1 つの `assets` マップ、別の「inputs」概念なし。**セラーの内部生成が生成 AI、ホスト録音、トランスコーディング、アセットレンダリングのいずれかはバイヤーに不可視。** プロトコルレベルで「生成」カテゴリーなし。生成メカニズムは実装詳細。 |
| ディスカバリー        | `list_creative_formats`（過負荷 — セールスとクリエイティブエージェントの両方が使う）                                                       | `get_adcp_capabilities` の `creative.supported_formats`（一様な置き換え、エージェントロールにかかわらず同じ `ProductFormatDeclaration` 形状）。セールスエージェントは加えて製品レベル詳細のため `format` インラインで `get_products` を露出                                                                                                                                                                        |
| トラッキング         | アセットタイプとフォーマット定義全体で混合                                                                                         | 各正準フォーマットに焼き込まれる（`video_vast` の VAST イベント、`html5` の MRAID+OM-SDK、`image` のインプレッションピクセル）                                                                                                                                                                                                                                                            |
| ブランドアイデンティティ   | ときどきフォーマットスロットとして再宣言                                                                                          | brand.json を解決する `brand`（[`BrandRef`](https://adcontextprotocol.org/schemas/v3/core/brand-ref.json) — `domain` プラス house-of-brands のオプション `brand_id`）経由で暗黙。BrandRef 自体の `brand_kit_override` インライン経由で明示的オーバーライド                                                                                                                                    |

## 12 の正準フォーマット

各正準は `/schemas/formats/canonical/<name>.json` に存在します。トラッキングモデルは **フォーマット固有** です（トラッキングモデルによる分割が、例えば 5 ではなく 12 を持つ理由）。

| Canonical             | What it is                                                                                                                                       | Tracking                                            |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------- |
| `image`               | 静的画像、ファイルまたはホスト URL リダイレクト                                                                                                                       | `universal_macros` 経由のインプレッションピクセル + クリック URL       |
| `html5`               | インタラクティブ HTML5 バナー（zip アセット）                                                                                                                     | MRAID + OM-SDK + click-tag マクロ + バックアップ画像           |
| `display_tag`         | サードパーティ JS/iframe タグ URL                                                                                                                         | セラーに不透明                                             |
| `image_carousel`      | マルチカードスワイプ（ポリモーフィック image/video アイテム）                                                                                                            | カードごとピクセル + カルーセルエンゲージメント                           |
| `video_hosted`        | 直接動画ファイル、orientation パラメーター                                                                                                                      | OM-SDK + 外部インプレッション/クリック/quartile トラッカー             |
| `video_vast`          | VAST タグ（URL またはインライン XML）、VAST 2-4.x                                                                                                             | 固有 VAST イベント                                        |
| `audio_hosted`        | 直接オーディオファイル（または build\_creative 経由で生成されたホストリード）                                                                                                  | 標準オーディオインプレッション/完了                                  |
| `audio_daast`         | DAAST タグ                                                                                                                                         | 固有 DAAST イベント                                       |
| `sponsored_placement` | リテールメディアカタログ駆動（Amazon SP、Criteo SP、CitrusAd SP） — `source_catalog` スロットを要求。IAB in-feed ネイティブ、コンテンツレコメンデーション、PMax スタイルのアルゴリズム表面には使わない。            | アイテムごとカタログキーイベント                                    |
| `native_in_feed`      | IAB 形状の in-feed ネイティブとコンテンツレコメンデーションウィジェット（Taboola、Outbrain、Yahoo Native、AdMob Native、in-feed スポンサードカード）。スロットは IAB OpenRTB Native 1.2 に 1:1 マップ。 | レンダラー発火 `pixel_tracker`（インプレッション / ビューアビリティ / クリック） |
| `responsive_creative` | バイヤーアセットプール、表面が組み合わせを合成（Google Responsive Display/Search Ads、Performance Max、Demand Gen。Meta Advantage+ クリエイティブ）                                 | アセットごとのパフォーマンス内訳                                    |
| `agent_placement`     | ユーザークエリに応答して AI 表面が合成するスポンサードプレースメント（ChatGPT、Perplexity、音声アシスタント、スポンサード検索スニペット）。`si_chat`（ブランド所有会話。ユーザー → ブランドのエージェント）と区別。                       | メンションレベルインプレッション + アトリビューション                        |

### `experimental` — one field, both axes

正準（またはセラーの特定製品宣言）は単一の `experimental: boolean` フラグを運びます。プロトコルの `experimental` と同じセマンティクス: 「これは出荷しているが壊れる、進化する、または失敗するかも。」`experimental: true` を読むバイヤーは v1 フォールバックを準備すべきで（SHOULD）、本番予算をルーティングする前に `validate_input` またはサンドボックス経由で検証すべきです（SHOULD）。これは以前の 2 軸設計（`status` + `runtime_status` enum）を置き換えます — バイヤーが実際に気にすることがバイナリだから崩された: これを本番安定として扱うか、自己責任使用として扱うか。

`experimental: true` は 3.1 GA で 3 つの正準プラス `custom` エスケープハッチに設定されます:

| Format kind           | Why experimental                                                                                                                                                                                                    | Promotion gated on              |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------- |
| `sponsored_placement` | 1 つの正準の下の 4 つの意味あるほど異なるリテールメディアアダプターコントラクト（Amazon SP、Criteo SP / CitrusAd SP、Pinterest Collection、generative-per-SKU） — [Sponsored Placement アダプターコントラクト](/docs/creative/sponsored-placement-adapter-contracts) を参照 | `format_schema` 証拠を持つ 2 つのアダプター |
| `responsive_creative` | アルゴリズム合成（表面が組み合わせを選ぶ）。クリーンな v1 翻訳可能同等物なし                                                                                                                                                                            | アダプター証拠 + 表面ごと適合性               |
| `agent_placement`     | トラッキングマクロ語彙 / ポストバック形状 / 表面横断 dedup が 3.1 に意図的に未仕様化                                                                                                                                                                 | 3.2 トラッキングコントラクト仕様              |
| `custom`              | 本質的に実験的 — ファーストクラス `format_kind` に昇格されるまでアダプター定義形状                                                                                                                                                                  | #3666 キュー経由の形状ごと昇格              |

7 つの IAB / VAST / DAAST / IAB-Native 再エンコード（`image`、`display_tag`、`video_hosted`、`video_vast`、`audio_hosted`、`audio_daast`、`native_in_feed`）プラス `html5` と `image_carousel` は非実験的に出荷します — それらは正準フォーマット語彙で再エンコードされる落ち着いた業界標準です。

セラーは、基盤正準が非実験的でも製品宣言レベル（特定の `ProductFormatDeclaration` 上）で `experimental: true` を設定してもよい（MAY） — ベータランタイムパスやセラーがまだ配線していない前方指向カタログ宣言に有用。バイヤー SDK は `experimental: true` の製品をデフォルトビューからフィルターし、それらを表示するオプトインを提供すべきです（SHOULD）。

セラーが製品を `experimental: true` とマークするとき、バイヤーの最小抵抗パスは v1 フォールバックです: v2 宣言が v1 名前付きフォーマットにリンクする `v1_format_ref` を運ぶ場合、セラーが実験的フラグを落とすまで v1 に対して出荷します。v1 が安全なパス。v2 はセラーがまだテストしている表面です。

## 2 つの軸: 合成（インプレッションごと）対 生成（誰がレンダーするか）

2 つの直交パターンが、クリエイティブがどう生成されどうサーブされるかを統制します。それらを混同することは最も一般的な作成の間違いです。

**合成モデル** — フォーマット宣言の `composition_model: deterministic | algorithmic`。**表面がインプレッションごとにどう合成するか** を記述:

* `deterministic` — バイヤーはスロットごとのレンダリングを予測できる。表面は受け取ったものをサーブ。（`image`、`video_hosted`、`audio_hosted`、`video_vast`、`audio_daast`、`sponsored_placement`。）
* `algorithmic` — 表面がバイヤー供給のアセットプールからインプレッションごとに組み合わせを選ぶ。バイヤーはプールを出荷。表面が合成。（Google PMax / Meta Advantage+ の `responsive_creative`。AI 表面合成の `agent_placement`。）

**生成ソース** — `asset_source` は **誰がソースアセットをレンダーまたは所有するか、いつか** を記述:

* `image`、`video_hosted`、`audio_hosted` の `asset_source` — 共有 enum: `buyer_uploaded | publisher_host_recorded | seller_pre_rendered_from_brief | seller_human_designed | agent_synthesized | publisher_owned_reference`。`publisher_host_recorded` はオーディオ固有（ポッドキャストホストリードパターン）で `audio_hosted` でのみ意味がある。`publisher_owned_reference` は製品のスロットが `published_post` のような参照アセットを受け入れるとき意味がある。
* 任意の正準宣言の `required_connections` — 単一の AdCP 呼び出し元認証情報に加えてセラーが必要とする下流プラットフォーム接続または付与。公開投稿参照のための advertiser account プラス publisher identity のような複数のプラットフォーム側接続を要求する製品に使う。
* `sponsored_placement` の `item_production_model` — 同じ軸、4 値サブセット（`publisher_host_recorded` を落とす）、カタログアイテムごとに適用（マルチ出力生成ケース: 1 ブリーフ × N カタログアイテム → N レンダーされたクリエイティブ）

2 つの軸は崩れません。ブリーフから 1 つのレンダーされた画像を生成する生成 DSP は `composition_model: deterministic`（表面は受け取ったものをサーブ）+ `asset_source: seller_pre_rendered_from_brief`（セラーが sync\_creatives 時に入力から生成）。カタログアイテムごとに AI 合成パイプラインを実行するリテールメディア表面は `composition_model: deterministic` + `item_production_model: agent_synthesized`。Google PMax は `composition_model: algorithmic` +（生成ソース未指定 — バイヤーが事前レンダーアセットのプールを出荷するため生成ソースの質問はフォーマットレベルで適用されない）。

生成ソース enum は情報的で、バインディングコントラクトではありません。フォーマットの `slots` 宣言がコントラクトです — バイヤーが何を、どの形状で出荷するか。`asset_source` フィールドはバイヤーに「この製品がレンダーされたクリエイティブをどう生成または解決するか」を伝え、彼らが生成モデルがワークフローに合う製品を選べるようにします（インハウス事前レンダー対アップストリームクリエイティブエージェント対セラー駆動生成対既存投稿参照）。

下流プラットフォーム認可は生成ソースとは別です。フォーマットがプラットフォーム側接続を要求する場合、`required_connections[]` で宣言します。例えば、公開投稿参照製品は `advertiser_account` と `publisher_identity` の両方を要求できます。バイヤーは依然としてセラーに一度認証し、セラーがそれらの下流付与を管理します。欠けている付与は、新しいフォーマットファミリーやアイデンティティディスカバリータスクとしてではなく、`error.details.missing_connections[]` を伴う `AUTHORIZATION_REQUIRED` として表示されます。

### セラーレンダーソース下のトラッカー組み立て

`asset_source` が `buyer_uploaded` のとき、バイヤーはレンダーされたアセットを出荷し、それらのアセットに添付された任意のトラッカー URL はバイヤー制御です（インプレッション/クリックには universal\_macros。分解された VAST/DAAST トラッカーには `vast_tracker` / `daast_tracker` アセット）。`asset_source` がセラーレンダー値のいずれか（`seller_pre_rendered_from_brief`、`seller_human_designed`、`agent_synthesized`）または `publisher_host_recorded` のとき、バイヤーはレンダーされたアーティファクトを直接決して見ません。2 つの規範的パスが適用されます:

* **マクロ置換トラッキング（デフォルト）。** セラーはインプレッション時に AdCP universal\_macros を尊重し — `{IMPRESSION_TRACKER}`、`{CLICK_TRACKER}` など — バイヤー供給のトラッカー URL（マニフェストのオプション `landing_page_url` とフォーマットの `platform_extensions` 経由で宣言され `extensions[uri].extends === "tracking"` でフィルターされたバイヤーの測定ベンダーピクセル上で宣言）をレンダーされたクリエイティブのサービングテンプレートに置換します。バイヤーは測定ピクセルをクライアント側で登録。セラーはサーブ時にそれらを呼びます。これはサービングとトラッキングが分離される image / video / audio 生成の支配的パスです。
* **Sync-creatives トラッカーブロック。** セラーがトラッカー URL を直接埋め込むサービングアーティファクト（例: 生成された VAST タグまたはステッチされたコンパニオンバナー）を生成する製品には、セラーの `sync_creatives` レスポンスはインプレッション URL パターンとクリック URL パターンをリストする `tracker_block` フィールドを含むべきです（SHOULD）。バイヤーは同期時にそれらを測定ベンダーに登録します。このパスは、サービングアーティファクトとトラッキング形状が一緒に生成される生成 DSP パターンをカバーします。

`vast_tracker` と `daast_tracker` 分解トラッカーアセットは `buyer_uploaded` とセラーレンダーソースの両方に機能します — セラーがレンダーするとき、それらのトラッカーアセットはレンダーされたタグへの入力で、生成時に適切な VAST/DAAST `<TrackingEvents>` ブロックに添付されます。バイヤーが完全な `vast` または `daast` タグを出荷するとき、トラッカーはタグ内を移動します。

## `format_kind` が何のためでないか

`format_kind` はクリエイティブアセット形状を名指します — バイヤーが何を出荷するか、表面が何を受け入れるか。配信媒体、測定モデル、ターゲティングコンテキストのためではありません。これらを混同することは 3.2 コントリビューターが誘惑される最も一般的なアーキテクチャの間違いです。3 つの具体例:

| Tempting (wrong)                      | Right answer                                                                                                                         | Why                                                                                        |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
| `format_kind: "broadcast_video"`      | `format_kind: "video_hosted"` + `applies_to_channels: ["tv"]`                                                                        | 動画アセットは同じ形状。放送対ストリーミングは配信 / 測定の違いで、クリエイティブ形状の違いではない。                                       |
| `format_kind: "dooh_image"`           | `format_kind: "image"` + `applies_to_channels: ["dooh"]`                                                                             | 画像アセットは同じ形状。DOOH の位置キー測定とノークリックモデルはフォーマットではなく `sync_event_sources` / `event_log` に存在。      |
| `format_kind: "image_generative"`     | `format_kind: "image"` + `asset_source: "agent_synthesized"` + `slots_override: [{ generation_prompt: text }]`                       | 同じ正準 TYPE。異なる生成 SOURCE。2 軸モデルが既にそれらを分離。                                                    |
| `format_kind: "published_post_video"` | `format_kind: "video_hosted"` + `asset_source: "publisher_owned_reference"` + `slots_override: [{ published_post: published_post }]` | 同じ正準 TYPE。バイヤーはアップロードされたバイトの代わりに既存投稿への参照を出荷。認可/レビュー状態は新しいフォーマットファミリーではなくクリエイティブライフサイクルに存在。 |

**経験則。** 新しい `format_kind` に手を伸ばす前に、違いが以下かをチェック:

1. **クリエイティブタイプ**（image 対 video 対 audio 対 html5 対 3p-tag） → `format_kind`、それが制御する唯一のノブ。
2. **生成モデル**（誰がいつレンダーするか） → フォーマット宣言の `asset_source`。
3. **スロット形状**（バイヤーが何のアセットを出荷するか） → 投影参照（カタログ側）または v2 製品の `format_options[]` 宣言の `slots_override`。
4. **配信媒体 / チャネル**（TV 対ストリーミング対 DOOH 対ソーシャル） → v2 製品の `applies_to_channels`。
5. **測定 / トラッキング / イベントモデル。** 2 通りに分割:
   * **レンダラー発火トラッカー**（レンダラーがサーブ / 表示 / クリック時に URL にヒット） → `pixel_tracker` アセット（またはそれらのフォーマットの `vast_tracker` / `daast_tracker`）。型付きスロットとしてクリエイティブマニフェストに存在。セラーのレンダラーがサーブ時に発火するバイヤーの測定ベンダー URL。`docs/creative/asset-types.mdx#pixel-tracker-asset` を参照。
   * **コンバージョンピクセル**（クリック後にアドバタイザーのサイトで発火 — Meta Pixel、GA4 サーバー側、カスタムポストバック） → `sync_event_sources` / `event_log`。キャンペーンスコープ、クリエイティブアセットスコープではない。同じピクセルがキャンペーンのすべての広告に発火。
6. **ターゲティングコンテキスト**（オーディエンス対 geo 対デイパート） → フォーマットではなくメディアバイターゲティングオーバーレイ。

クリエイティブアセット自体が構造的に異なるときのみ新しい `format_kind`（例: DAI の広告ステッチ連続オーディオストリームは `audio_hosted` のインプレッションごとファイルと構造的に異なる）。GA での v1 カタログの 50 の広告フォーマットすべてがこのルール経由で正準に投影されます。放送 TV、DOOH、生成はすべて既存の正準に留まります（`applies_to_channels` / `asset_source` / `slots_override` 経由の兄弟絞り込み）。1 つの例外は `native_in_feed` です: IAB OpenRTB Native 1.2 in-feed とコンテンツレコメンデーションユニットは、`image` や `responsive_creative` の兄弟絞り込みとして表現できず `sponsored_placement` のようにカタログキーでないアセットバンドル合成形状（レンダラーが組み立てる title + image + body + CTA）を持ちます — バイヤーエージェントは正しい組み立てロジックにルーティングするため `format_kind` 判別子を必要とします。12 正準ラインは native\_in\_feed がこのバーをクリアした *から* 保たれます。それはすべてのチャネルが自身の正準を求める前例ではありません。

## `slots_override` をいつ使うか（そしていつ省くか）

`slots_override`（カタログの `canonical:` 投影参照上または v2 製品の `format_options[]` 宣言上）は、正準のデフォルトスロットセットをカスタムリストで置き換えます。控えめに使ってください — ほとんどのフォーマットはデフォルトをきれいに継承します。

**決定ルール。** クリエイティブマニフェストを構成するバイヤーが、このケースで正準のデフォルトと **異なるアセット** をリストするか? はいなら `slots_override`。いいえなら省く。

| Case                                                        | Default vs Override                                                                                                                        |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| 300×250 IAB MREC                                            | **デフォルト。** 正準 `image` デフォルトは既に `image_main: image, required` + headline/body/cta/landing を運ぶ — バイヤーのマニフェストアセットが正準のデフォルト。                   |
| ネイティブ標準（title + description + image + icon + sponsored\_by） | **オーバーライド。** `brand_name`（`sponsored_by` エイリアス）を required として追加、`headline` を required に、`cta` を enum 値に絞る。マニフェストアセットが正準デフォルトから分岐。          |
| DOOH ビルボード（画像のみ、クリックなし）                                     | **デフォルト。** 正準 `image` デフォルトがカバー（image\_main required、他の required スロットなし）。ノークリックモデルはスロットではなく event\_log に存在。                                |
| 放送 TV スポット（動画ファイル + キャプション URL）                             | **デフォルト。** 正準 `video_hosted` デフォルトがカバー（video\_main required、captions optional）。放送トラフィッキングは `applies_to_channels: ["tv"]` に存在。              |
| 生成画像（画像の代わりにテキストプロンプト）                                      | **オーバーライド。** `image_main: image, required` を `generation_prompt: text, required` で置き換え。マニフェストアセットが正準デフォルトと構造的に異なる。                         |
| ポッドキャストホストリード（オーディオの代わりにスクリプトテキスト）                          | **オーバーライド。** `audio_main: audio, required` を `script: text, required` + `asset_source: publisher_host_recorded` で置き換え。                     |
| 公開投稿参照（アップロードされた動画の代わりに既存のソーシャル/パブリッシャー投稿）                  | **オーバーライド。** `video_main: video, required` を `published_post: published_post, required` + `asset_source: publisher_owned_reference` で置き換え。 |

ルールは対称的に適用されます: 測定ピクセル、配信媒体フラグ、ターゲティングコンテキストを宣言するためだけに `slots_override` を追加する誘惑にかられたら、それは間違った使い方です — それらはスロットにまったく属しません（上の「`format_kind` が何のためでないか」を参照）。

## カスタムフォーマット — 12 の正準がカバーしない形状

12 の正準は原子的クリエイティブ形状（1 つの画像、1 つの動画、1 つのディスプレイタグ、1 つのカルーセル、1 つのネイティブ in-feed ユニット、1 つのカタログプレースメント、1 つの AI 表面メンション）をカバーします。それらは、ハイエンドパブリッシャーと放送ネットワークがヘッドライン製品として販売する合成 / 協調 / スポンサーシップ形状をカバーしません: マルチプレースメントテイクオーバー、ロードブロック、ブランデッドコンテンツ、クロススクリーンスポンサーシップ、スポンサーシップロックアップ、ニュースレタースポンサーシップ、AR レンズ、プレイアブル、ライブイベントスポンサーシップ。

これらの形状は実際の広告業界製品タイプです — しかしそれらはマルチ正準合成（テイクオーバー = image + video + display\_tag + lockup、ユニットとして販売）か真に新規の構造（ブランデッドコンテンツの編集スポンサーシップ生成モデルは 12 の合成ではない）のいずれかです。v2 は、フリーフォーム `ext` 経由ではなく、バイヤーエージェントが推論できる構造化カスタムメカニズム経由でそれらを処理します。

### メカニズム

```json test=false theme={null}
{
  "format_options": [
    {
      "format_kind": "custom",
      "canonical_formats_only": true,
      "format_shape": "multi_placement_takeover",
      "format_schema": {
        "uri": "https://nytimes.example/schemas/formats/homepage_takeover_v3",
        "digest": "sha256:e1d4f6a9c2b5e8d1f4a7c0b3e6d9f2a5c8b1e4d7f0a3c6b9e2d5f8a1c4b7e0a3"
      },
      "format_option_id": "nytimes_homepage_takeover_premium",
      "applies_to_channels": ["display", "olv"],
      "params": {
        "components": [
          { "placement_type": "homepage_skin", "required": true },
          { "placement_type": "preroll_video", "required": true },
          { "placement_type": "sponsorship_lockup", "required": true }
        ],
        "exclusivity_window_hours": 24
      }
    }
  ]
}
```

`format_kind: "custom"` のとき 3 つの必須部分:

1. **`format_shape`** — [format-shape 語彙レジストリ](https://adcontextprotocol.org/schemas/v3/core/format-shape-vocabulary.json) からの認識されたグローバルパターン。バイヤーエージェントに彼らが見ているパターンの種類を伝える（`multi_placement_takeover`、`branded_content`、`ar_lens` など）。レジストリは現在 9 の形状をリスト。非正準値は有効（検証者はソフト警告してもよい（MAY））のでアダプターはまだレジストリにない形状を出荷 **できる** — エントリー追加は語彙 PR で、メジャーバージョンバンプではない。
2. **`format_schema`** — 形状の実際の `params` と `slots` を記述するフェッチ可能なスキーマへの URI+ダイジェスト参照。**`platform_extensions` と同じホスティングモデル**: オープンエコシステムパブリッシャーはサブドメインの正準 URI でアーティファクトをホスト。クローズドプラットフォーム / ウォールドガーデン形状は `https://creative.adcontextprotocol.org/translated/...` の AAO ミラー経由で解決。バイヤーエージェントは `uri@digest`（ダイジェストごとに不変、積極的キャッシング）でフェッチし、`params` と `slots` をフェッチされたスキーマに対して検証し、マニフェストを構造的に推論。
3. **`params`** — `format_schema.uri` からフェッチされたスキーマが統制する実際の構造。AdCP は params 形状を焼き込まない。セラーのスキーマが行う。

### `format_schema` フェッチコントラクト（規範的）

`format_schema` は検証をゲートします — スキーマなしでは、バイヤーはカスタム形状について推論できません。下の **トランスポート** ルールは `format_schema` と `platform_extensions` の **両方** に同一に適用されます（`platform-extension-ref.json` URI をフェッチする任意の SDK は同じルールを適用します — 最も弱いバーに落ちる共有フェッチパスは `format_schema` のハードニングを損なう）。**消費** 区別（`format_schema` は荷重を担う、`platform_extensions` は情報的）は *ボディが何を意味するか* についてで、どうフェッチされるかではありません。

* **トランスポート**: `https://` のみ。`http://`、`file://`、`data:`、その他のスキームは拒否されなければならない（MUST）。
* **SSRF 保護**: 解決されたホスト名は RFC 1918（10/8、172.16/12、192.168/16）、ループバック（127/8、::1）、リンクローカル（169.254/16、fe80::/10）、CGNAT（100.64/10）、RFC 6761 特殊用途名（`.local`、`.localhost`、`.internal`、`.test`、`.example`、`.invalid`）に着地してはならない（MUST NOT）。クラウドメタデータエンドポイント（`169.254.169.254`、`metadata.google.internal`、`kubernetes.default.svc`）は明示的に禁止 — これらは認証情報リークプリミティブ。接続は DNS リバインディングを破るため解決された IP にピン留めされなければならない（MUST）（またはリクエストごとに再解決 & 再検証）。
* **リダイレクトなし。** これらのフェッチで HTTP リダイレクトは無効化されなければならない（MUST）。同一オリジンパスのオープンリダイレクトはそうでなければ無料の SSRF プリミティブ。
* **1 MiB レスポンス上限。** ストリーミング中に強制。上限超過 = ハード失敗。
* **ダイジェスト不一致はハード失敗。** ボディの SHA-256 は `format_schema.digest`（`sha256:` + 64 小文字 hex）に等しくなければならない（MUST）。不一致時、バイヤーは宣言を解決不可能として扱わなければならない（MUST）。未検証ボディへのフォールバックなし。持続的な不一致（ネットワークフラップ対）はテレメトリーで区別可能でなければならない（MUST） — それは置換攻撃シグナル。
* **タイムアウト** ≤5s 推奨。タイムアウトは 5xx として扱われる（一時的 — リトライまたはスキップ）。
* **`$ref` サンドボックス化**: フェッチされたスキーマは `$ref` を使ってもよい（MAY）が、(a) RFC 3986 §6 正規化後の同一オリジン URI（小文字スキーム + ホスト、デフォルトポート除去、userinfo なし）、(b) AAO カタログドメイン（`https://creative.adcontextprotocol.org/...`）、(c) 親ドキュメントに境界された文書内 JSON Pointer 参照のみ。任意 URI へのクロスオリジン `$ref` は拒否されなければならない（MUST）。`$ref: file://...` は拒否されなければならない（MUST）。推移的 `$ref` 深度 ≤8 かつ解決されたツリー全体で総 `$ref` 数 ≤256（深度だけでは不十分 — 深度 8 × 幅 100 = 10^16 ノード）。
* **スキーマコンパイル境界（DoS 保護）**: 検証者は CPU/メモリを境界しなければならない（MUST）。推奨: コンパイルされたスキーマキーワード数 ≤10,000、`pattern` 正規表現は `re2` で評価 または パターンごとタイムアウト下、マニフェストごと検証予算 ≤250 ms（超過 → 無効 + テレメトリーシグナル）。これらなしでは、破滅的な正規表現バックトラッキングを持つ「有効な」スキーマが CPU を永久にピン。
* **キャッシュ** by `uri@digest`、不変。404 / パーティション / 持続的失敗時: このセッションで宣言をスキップ、`errors[]` 経由で表示、`get_products` レスポンス全体を失敗させない。
* **スキーマ妥当性**: フェッチされたボディは有効な JSON Schema（Draft 07 または 2020-12）でなければならない。無効なスキーマ → ダイジェスト不一致と同じ（解決不可能、`errors[]` 経由で表示、スキップ）。
* **AAO カタログドメイン**: `https://creative.adcontextprotocol.org/*` は allowlist の単一トラストアンカー。カタログドメインまたはその CA の侵害はすべてのバイヤーエージェントを侵害。カタログサーブのボディはオリジンフェッチと同一にダイジェストピン留めされる。署名付きボディ + 透明性ログハードニングは 3.2 フォローアップとして追跡。

### なぜ `ext` の代わりに custom + format\_schema か

`get_products` を呼び `ext` に埋められた興味深い構造を持つフォーマットを見るバイヤーエージェントは、推論する仕様レベル定義を持ちません。スキーマなし、必須フィールドなし、定義されたセマンティクスなし — エージェントは blob を見られるが確実に解釈できません。人間が介入して、フォーマットがキャンペーンブリーフに合うか、どのアセットが必要か、どうトラックするか、インプレッションコントラクトが何か、価格が理にかなうかを評価しなければなりません。

それは v2 の荷重を担うクレームを壊します: **バイヤーエージェントはセラーごとの統合コードなしに構造的に推論できる。** ext のみは興味深い構造をフリーフォームバッグに入れ、human-in-the-loop に退行します。Custom + `format_shape` + `format_schema` はエージェンティックファーストコントラクトを保ちます: 形状は登録された分類子を持ち、構造はフェッチ可能なスキーマを持ち、バイヤーエージェントは両方に対して推論。バイヤーエージェントが `platform_extensions` に既に持つのと同じキャッシングメカニクス。

`ext` は、`format_shape` エントリーにさえまだ適合しない真に実験的な形状のために残りますが — それは稀なケースで、デフォルトではありません。新規形状の支配的パスは custom + format\_shape + format\_schema です。

### 正準への昇格

`format_shape` エントリーは以下のときファーストクラス `format_kind` に昇格されます:

1. 少なくとも 2 つの本番アダプターが custom + format\_schema 経由でそれを出荷
2. アダプターが収束した形状への破壊的変更なしの 90 連続日
3. 形状が定義されたトラッキングモデル（どのシグナルが発火するか、どのトラッカーが添付するか、インプレッションコントラクトが何か）を持つ
4. ワーキンググループが正準ごと昇格 issue を開き、正準スキーマ（`/schemas/formats/canonical/<name>.json`）をドラフトし、フィクスチャを着地させ、次のマイナーリリースで出荷

v1 監査から 12 の正準を生んだのと同じガバナンスパターン。昇格キューは [adcp#3666](https://github.com/adcontextprotocol/adcp/issues/3666) に存在。現在の候補は format-shape レジストリの 9 エントリー。

**昇格は消費者コードのワイヤー形状変更です。** `format_kind == "custom"` で分岐する任意のクライアントは、昇格された形状を出荷するパブリッシャーへのマッチを黙って停止します — セラーの製品が今や `format_kind: "<promoted_name>"` として到着。規範的移行コントラクト（`format-shape-vocabulary.json` の description 内）:

1. **移行ウィンドウ**（≥90 日）: セラーは両方の形状を同時に発行してもよい（MAY） — `format_options[]` が 1 つの `format_kind: "custom"` + `format_shape: "<name>"` 宣言 かつ 1 つの `format_kind: "<promoted_name>"` 宣言を運ぶ。
2. **消費者 SDK 非推奨警告**: SDK は、昇格された `format_shape` を持つ `format_kind: "custom"` を見るとき、lint チャネル経由で構造化非推奨警告を発行すべき（SHOULD）（`FORMAT_PROJECTION_FAILED` と同じ表面）。ペイロード: `{ format_shape, promoted_to, promotion_release, transition_end }`。
3. **`promotion_status` ライフサイクル**: ワーキンググループが昇格をスケジュールするとき、レジストリエントリーの `promotion_status` が `tracking — see adcp#3666` から `promoted to <format_kind> in <version>; transition ends <date>` に更新。SDK はこれをコード生成 / ランタイムで読んでもよい（MAY）。
4. **移行後**: セラーはレガシー `format_kind: "custom"` 宣言を落とすべき（SHOULD）。バイヤーは次に `format_kind == "custom"` がロングテール / 非昇格形状と仮定してもよい（MAY）。

このコントラクトなしでは、すべての昇格イベントが黙ってアダプターコードを壊します。それありで、非推奨警告が移行ウィンドウ中の早期シグナルです。

## アセットグループ語彙

フォーマット `slots` は [語彙レジストリ](https://adcontextprotocol.org/schemas/v3/core/asset-group-vocabulary.json) から正準 `asset_group_id` 値を参照します。現在の正準エントリー:

| asset\_group\_id                                       | asset\_type | Common aliases (v1 → v2)                                     |
| ------------------------------------------------------ | ----------- | ------------------------------------------------------------ |
| `headlines`                                            | text        | headline, title, tagline, headline\_text                     |
| `long_headlines`                                       | text        | long\_headline\_pool, extended\_headlines                    |
| `descriptions`                                         | text        | description, body, body\_text, text, content                 |
| `images_landscape`                                     | image       | image, hero\_image, landscape\_image, banner\_image          |
| `images_vertical`                                      | image       | vertical\_image, story\_image, portrait\_image               |
| `images_square`                                        | image       | square\_image, feed\_image                                   |
| `image_main`                                           | image       | (`image` の正準ごとデフォルト)                                         |
| `logo`                                                 | image       | brand\_logo, logo\_image                                     |
| `video`                                                | video       | video\_file, hero\_video, video\_asset, video\_main          |
| `video_main`                                           | video       | (`video_hosted` の正準ごとデフォルト)                                  |
| `video_vertical` / `video_horizontal`                  | video       | —                                                            |
| `audio` / `audio_main`                                 | audio       | audio\_file, hero\_audio, audio\_asset                       |
| `companion_image` / `companion_banner`                 | image       | —                                                            |
| `brand_name` / `body_text`                             | text        | —                                                            |
| `cards`                                                | object      | carousel\_cards, slides, carousel\_items, carousel\_slides   |
| `cta`                                                  | text        | cta\_text, call\_to\_action, action\_text, button\_text      |
| `price` / `phone_number` / `promo_code` / `disclaimer` | text        | (各種)                                                         |
| `subtitle_file`                                        | url         | caption\_file, captions, subtitles                           |
| `landing_page_url`                                     | url         | click\_url, link, final\_url, link\_url, click\_through\_url |
| `privacy_policy_url`                                   | url         | —                                                            |
| `source_catalog`                                       | catalog     | (sponsored\_placement)                                       |
| `hero_asset`                                           | image       | hero\_banner, collection\_hero                               |
| `script`                                               | text        | script\_text, host\_script, voiceover\_script                |
| `creative_brief`                                       | brief       | brief, creative\_direction, talking\_points                  |
| `video_brief`                                          | object      | scenes, storyboard, shot\_brief                              |
| `voice_id` / `offering_ref`                            | text        | —                                                            |
| `style_reference`                                      | image       | reference\_image, style\_image, inspiration\_image           |
| `starter_assets`                                       | object      | —                                                            |
| `vast_tag`                                             | vast        | (video\_vast デフォルト)                                          |
| `daast_tag`                                            | daast       | (audio\_daast デフォルト)                                         |
| `tag_url`                                              | url         | (display\_tag デフォルト)                                         |
| `html5_bundle`                                         | zip         | (html5 デフォルト)                                                |
| `backup_image`                                         | image       | (html5 / display\_tag デフォルト)                                 |

非正準 `asset_group_id` 値はプラットフォーム固有拡張に有効なまま。検証者は収束を促すため非正準 ID にソフト警告を発行してもよい（MAY）。エイリアスは移行時に一方向（v1 エイリアス → v2 正準）で認識される。新しいマニフェストは正準 ID を使うべき（SHOULD）。

## 実例 — Meta Reels

Meta Reels は正準フォーマットカバレッジの有用なテストです: AdCP を採用していないベンダーからのプラットフォーム固有フォーマットで、縦動画の上にレンダリング詳細（CTA enum、primary text、headline 制限、brand name オーバーレイ）を持つ。各 Reels 機能はどこかに着地します — 正準 `params`、継承またはオーバーライドされたスロット、ブランド層、キャンペーン層 — そして正準は成長する必要がありません。

### 各 Reels 機能がどこに存在するか

| Reels feature                       | Where it lives                                                                                                                                      | Notes                                                                                                                   |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| 縦 9:16、3-90s、1080×1920、h264/aac、mp4 | `video_hosted` の `params`                                                                                                                           | 標準正準パラメーター。                                                                                                             |
| Headline（40ch）、Primary text（125ch）  | `params.headline_max_chars`、`params.primary_text_max_chars` + 継承された `headline` / `primary_text` スロット                                                | バイヤーはスロット経由でテキストコンテンツを出荷。param が制約を絞る。                                                                                  |
| 固定 enum からの CTA                     | `params.cta_values[]` + 継承された `cta` スロット                                                                                                            | バイヤーは `assets.cta.text` を出荷。検証者が enum に対してチェック。                                                                         |
| ランディングページ URL                       | `video_hosted` の継承された `landing_page_url` スロット                                                                                                       | 特別な処理なし。                                                                                                                |
| Brand name オーバーレイ                   | フォーマットに **ない**。リンクされたページから Meta が自動適用（AdCP 外の認証コンテキスト）。                                                                                             | 継承された `brand_name` スロットが正準に存在。明示的コンテンツを必要とする製品（パブリッシャーダイレクト動画、CTV）が投入。Meta は Reels でそれを消費しない。                           |
| Logo オーバーレイ                         | フォーマットに **ない**。リンクされたページから Meta が自動適用。                                                                                                              | `BrandRef.brand_kit_override.logo` は、セラー側レンダラーがロゴをオーバーレイするフォーマット（ホストリードポッドキャスト、CTV バンパー、パブリッシャーダイレクト）に存在。Meta はそれを使わない。 |
| Music オーバーレイ（Reels music library）   | この宣言に **ない**。追加されれば フォーマットの `platform_extension` になる。**3.1 に存在しない** — 2+ アダプターなしにスキーマ席の価値があるにはプラットフォーム固有すぎる。                                        | セラーはその間マニフェストの `ext` 経由で層化できる。                                                                                          |
| ピクセル / コンバージョントラッキング                | フォーマットに **ない**。コンバージョントラッキングは `sync_event_sources` / `event_log` の領域 — キャンペーンスコープ、クリエイティブスコープではない。                                                  | クリエイティブにかかわらず同じピクセルがキャンペーンのすべての広告に発火。`event_log` の 1 宣言がキャンペーンをカバー。                                                     |
| プレースメント選択（Feed 対 Reels 対 Stories）   | フォーマットに **ない**。プレースメントはメディアバイ時に選択（`Placement.format_options[].format_option_id`） — Reels を買うには `meta_reels`、Stories を買うには `meta_stories_video` を選ぶ。 | それらはパブリッシャーカタログの別々のフォーマットオプション。ランタイム拡張パラメーターではない。                                                                       |

### フォーマットをどこで宣言するか

3 つの場所。誰がアサーションを所有するかで選ぶ。

| Surface                                                                       | Authority                      | When to use                                                                                                                                                                                          |
| ----------------------------------------------------------------------------- | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `adagents.json` トップレベル `formats[]`（パブリッシャーカタログ）                               | パブリッシャー（または代理する AAO コミュニティミラー） | パブリッシャーの在庫のすべてのセラー全体で共有 — パブリッシャー権威形状を一度宣言。ファイルの `properties[]` のサブセットにスコープするには `applies_to_property_ids` / `applies_to_property_tags` を使う。                                                          |
| `Product.format_options[]`（製品上インライン）                                          | セラー、特定製品上                      | セラー固有絞り込み、カスタムフォーマット、または 1 回限りの価格バリアント。各エントリーは `format_kind` + `params` を持つ完全な `ProductFormatDeclaration`。パブリッシャーカタログエントリーにバックされるとき、カタログ名前空間を兄弟フィールドとして含める: `{publisher_domain, format_option_id}`。  |
| `adagents.json` の `Placement.format_options[]`（format\_option\_id 参照またはインライン） | パブリッシャー（またはプレースメントを公開するセラー）    | プレースメントを 1 つ以上の受け入れフォーマットに結びつける。プレースメントは素の `{format_option_id}` 参照（推奨。同じファイルのトップレベル `formats[]` に対して解決）またはプレースメントローカル絞り込みのためのインライン宣言を使ってもよい。同一ファイルスコープ — クロスファイル `format_option_id` ルックアップはサポートされない。 |

製品宣言、バイヤーセレクター、プレースメント参照は意図的に異なる形状です:

* `Product.format_options[]`: 完全な宣言。決して素の `{format_option_id}` 参照でない。
* `PackageRequest.format_option_refs[]` / `creative-manifest.format_option_ref`: `FormatOptionRef` を使うバイヤーセレクター。
* `adagents.json` `placements[].format_options[]`: 同一ファイルプレースメント参照は素の `{format_option_id}` でよい。

`applies_to_property_ids` と `Placement.format_options[]` は異なる質問に答えます: 前者はフォーマットをプロパティのサブセットにスコープ（「Reels は Instagram + Facebook に適用されるが WhatsApp には適用されない」）。後者はプレースメントを 1 つ以上のフォーマットに結びつける（「Instagram Reels は `meta_reels` フォーマットオプションを受け入れる」）。プロパティレベルフォーマットサポート → `applies_to_property_ids`。プレースメントレベルバインディング → `placements[].format_options[]`。

**命名境界:** `format_option_id` は購入可能な製品またはパブリッシャーカタログフォーマットコントラクトを選択します。クリエイティブエージェント `capability_id` は別のまま: `build_creative` を呼ぶとき `creative.supported_formats` のビルドパスを選択します。メディアバイ製品、プレースメント、パッケージリクエスト、クリエイティブマニフェスト、クリエイティブアセットに `capability_id` を使わないでください。

### フォーマットディスカバリー（解決順）

バイヤーエージェントは `list_creative_formats(publisher_domain="<domain>", property_id?="<id>")` 経由で「このパブリッシャーはどのフォーマットを受け入れるか?」に答えます。3 層解決:

1. **パブリッシャーホスト**: `https://<publisher_domain>/.well-known/adagents.json` をフェッチ。存在し `formats[]` を運ぶ場合、それを返す。レスポンス `source: "publisher"`。
2. **AAO コミュニティミラー**: 404 または formats\[] の不在時、`https://creative.adcontextprotocol.org/translated/<platform>/adagents.json` にフォールバック。その `formats[]` を返す。レスポンス `source: "aao_mirror"`。
3. **エージェント導出**: どちらの層もカタログを返さない場合、エージェントはパブリッシャーの在庫を販売する製品の自身の `Product.format_options[]` の union から合成。レスポンス `source: "agent_derived"`。最低権威 — エージェントが販売するものの見方で、パブリッシャーのカタログではない。構造化カタログのないロングテール IAB パブリッシャーはここに存在。

**すべてのフェッチは `format_schema` と同じトランスポートコントラクトに従わなければならない（MUST）** — https のみ、SSRF ガード（RFC 1918 / ループバック / リンクローカル / メタデータエンドポイント denylist。ホスト名を解決し DNS リバインディングを破るため接続をピン留め）、≤5s タイムアウト、1 MiB 上限、リダイレクトなし。完全な規範的コントラクトについては `static/schemas/source/core/product-format-declaration.json#format_schema` を参照。Adagents.json ファイルは認可クレーム + 署名鍵を運ぶ。SSRF リークは攻撃者にとって format\_schema リークより高価値。

**コミュニティミラーガバナンス**（3.1 ステータス）。AAO は `creative.adcontextprotocol.org/translated/<platform>/` で未採用プラットフォームの adagents.json ファイルを公開します。**保守は今日誰も所有しない** — エントリーはベストエフォートで、公に文書化されたプラットフォーム仕様から導出される。コミュニティミラー名前空間は `format_schema` ミラーと同じ単一トラストアンカー懸念を継承: `creative.adcontextprotocol.org` またはその CA の侵害はミラーを読むすべてのバイヤーエージェントを侵害。署名付きボディ + 透明性ログハードニングは 3.2 フォローアップとして追跡。それまで、バイヤー SDK はミラーサーブコンテンツを助言的として扱い（`source: "aao_mirror"` でラベル）、利用可能なときパブリッシャーホスト tier 1 を優先し、鮮度チェックを適用すべき（SHOULD）（プラットフォームごと `OWNERS` + 古さしきい値は別途追跡 — ミラーエントリーがしきい値内でリフレッシュされていないとき、SDK はその権威を `agent_derived` に降格してもよい（MAY））。

**アイデンティティ混同ノート（規範的）。** `v1_format_ref[].agent_url` のミラー URL は *フォーマット形状プロベナンス* を宣言し、セラーアイデンティティではありません。`v1_format_ref[].agent_url` にマッチするバイヤー allowlist は形状名前空間にマッチしています。在庫認可は常に `authorized_agents[]` + パブリッシャー署名鍵から流れます。`v1_format_ref` を `creative.adcontextprotocol.org/translated/meta` に向けるセラーは「このフォーマットは AAO ミラーの Meta Reels 形状に従う」を主張しており、「私は Meta である」ではありません。

**プラットフォーム採用カットオーバー。** プラットフォームが AdCP を採用し自身の `adagents.json` を公開するとき、AAO ミラーファイルは `superseded_by: "<platform-domain>/.well-known/adagents.json"` を設定すべき（SHOULD）。`superseded_by` に遭遇するバイヤー SDK は、古いミラーコンテンツをサーブするのではなく短絡し名指しされた URL から再フェッチしなければならない（MUST）。ミラーは、ミラー URL でキーされたキャッシュが黙った破損ではなく明示的な移行シグナルを得るよう `superseded_by` 設定で ≥1 マイナーリリースサーブし続けるべき（SHOULD）。セラーは同じマイナーリリースで `v1_format_ref[].agent_url` をプラットフォームの採用された agent\_url にも更新。

### エンドツーエンドフェッチフロー — バイヤーの視点

`publisher_properties[].publisher_domain = "meta.example"` を持つ `Product` を見て「このパブリッシャーはどのフォーマットを受け入れるか、プロパティ ID `instagram` にスコープして?」を知る必要があるバイヤーエージェントは、以下の解決を歩きます。部分は上で別々に文書化されています。このセクションはそれらを順に歩き、アダプターがフラグメントから旅を組み立てる必要がないようにします。`publisher_properties[].publisher_domain` はカタログホストを名指す。`property_id` はそのファイル内のプロパティを識別。

```
buyer holds: Product { publisher_properties: [{publisher_domain: "meta.example"}],
                       format_options: [
                         {publisher_domain: "meta.example", format_option_id: "meta_reels",
                          format_kind: "video_hosted", params: {...}},
                         ...
                       ] }
buyer wants: full ProductFormatDeclaration for each format_options entry,
             scoped to meta.example's instagram property
```

**ステップ 1 — パブリッシャーカタログを解決。** バイヤー SDK が `https://meta.example/.well-known/adagents.json` をフェッチ。`format_schema` トランスポートコントラクトを適用（https のみ、SSRF ガード、≤5s タイムアウト、1 MiB 上限、リダイレクトなし — `product-format-declaration.json#format_schema` を参照）。プラットフォームは今日 AdCP を採用していない — フェッチは 404 を返す。

**ステップ 2 — AAO コミュニティミラーにフォールバック。** ステップ 1 の 404（または `formats[]` なしの 200）時、バイヤーは `https://creative.adcontextprotocol.org/translated/meta/adagents.json` をフェッチ。同じトランスポートコントラクト。レスポンスはパブリッシャー権威宣言を伴う `formats[]` を運ぶ。バイヤー SDK はテレメトリーのため結果を `source: "aao_mirror"` とラベル。

**ステップ 3 — 置き換えをチェック。** レスポンスが `superseded_by` を運ぶ場合、短絡: 名指しされた URL（通常プラットフォームの採用された adagents.json）から再フェッチし代わりにそのレスポンスを使う。今日ミラーの `superseded_by` は未設定。将来 Meta が採用するとき、`https://meta.example/.well-known/adagents.json` を指す。

**ステップ 4 — property\_id でスコープ。** ファイルの `formats[]` から、`applies_to_property_ids` が `"instagram"`（プロパティ ID。`publisher_domain` と同じでない）を含むエントリーにフィルター。プロパティ ID はファイルのトップレベル `properties[]` ブロックで宣言される。`applies_to_property_ids` / `applies_to_property_tags` スコーピングなしの `formats[]` エントリーはファイルのすべてのプロパティに適用。Meta には:

* `meta_reels` → applies\_to\_property\_ids: \["instagram", "facebook"] → 一致
* `meta_feed_image` → applies\_to\_property\_ids: \["instagram", "facebook"] → 一致
* `meta_stories_video` → applies\_to\_property\_ids: \["instagram", "facebook"] → 一致
* `meta_feed_carousel` → applies\_to\_property\_ids: \["instagram", "facebook"] → 一致

手元の Product は `publisher_domain: "meta.example"` と `format_option_id: "meta_reels"` でタグ付けされた完全な宣言（例えば `format_kind: "video_hosted"` プラス `params`）を運ぶ。`{publisher_domain, format_option_id}` ペアはバイヤーがその製品宣言をカタログ宣言に一致させられるようにする。製品エントリーは素の参照ではない。

**ステップ 5 — プレースメント参照を解決（あれば）。** パブリッシャーカタログが `placements[]` を含みプレースメントが `format_options: [{ format_option_id: "meta_reels" }]` を運ぶ場合、バイヤーは format\_option\_id を同じファイルのトップレベル `formats[]` に対して解決。クロスファイルルックアップは設計上サポートされない。なぜなら同一ファイル解決が検証者を境界し 1 つのファイルが別のパブリッシャーの `format_option_id` を占有するのを防ぐから。参照が壊れているとき — format\_option\_id が `formats[]` に存在しない — SDK はレスポンス `errors[]` に `FORMAT_OPTION_UNRESOLVED` を表示しそのプレースメントにフェイルクローズしなければならない（MUST）。

**ステップ 6 — マルチ層ディスカバリーキャッシュ。** バイヤー SDK は、存在するとき解決された URL プラス `catalog_etag` でファイルをキャッシュし、HTTP 検証者（`ETag`/`Last-Modified`）、次に境界された TTL にフォールバック。同じパブリッシャーからの後続製品は、カタログトークンまたは HTTP 検証者が変わるまでキャッシュされたファイルを再利用し、次にプレースメントとフォーマット参照を再解決。

**具体的ペイロードシーケンス**（Meta Reels、Instagram にスコープ）:

```
GET https://meta.example/.well-known/adagents.json
→ 404

GET https://creative.adcontextprotocol.org/translated/meta/adagents.json
→ 200 application/json
{
  "properties": [{"property_id": "instagram", ...}, ...],
  "formats": [
    { "format_option_id": "meta_reels", "format_kind": "video_hosted",
      "applies_to_property_ids": ["instagram", "facebook"],
      "params": { ... } },
    ...
  ],
  "placements": [...]
}

(no superseded_by present — use as authoritative for unadopted platform)

filter formats[] by applies_to_property_ids ∋ "instagram":
→ 4 declarations match

product's format_options carries a full declaration tagged with:
  { publisher_domain: "meta.example", format_option_id: "meta_reels" }
→ match FormatOptionRef { scope: "publisher", publisher_domain: "meta.example", format_option_id: "meta_reels" }
  against the product declaration and publisher catalog entry

result: SDK knows the full ProductFormatDeclaration for the product,
        scoped to the right property, with the right v1 dual-emission
        format_ids[] from v1_format_ref[].
```

**レスポンス `source` フィールドが層をレポート**: ステップ 1 が formats\[] を返したなら `"publisher"`、ステップ 2 が返したなら `"aao_mirror"`、どちらも返さず SDK が製品自身の `format_options[]` から合成したなら `"agent_derived"`。同じパブリッシャーの同じエージェントにヒットする 2 つの SDK は、どの層がリストを生成したかにかかわらず一貫したラベリングを得る。

### コミュニティレジストリホスティング

Meta は AdCP を採用していないので、その `adagents.json` は AAO コミュニティレジストリミラー `https://creative.adcontextprotocol.org/translated/meta/adagents.json` に存在します。ミラーファイルはパブリッシャーカタログレベルで `formats[]` を宣言 — Meta Reels の 1 宣言、Instagram + Facebook（WhatsApp でない）にスコープ、すべてのセラーの製品全体で再利用。Meta が後で自身の `adagents.json` を `meta.example/.well-known/adagents.json` で公開するとき、プラットフォームホストファイルが優先しミラーエントリーは非推奨（上で文書化された `superseded_by` シグナル経由）。

```json test=false theme={null}
// https://creative.adcontextprotocol.org/translated/meta/adagents.json (excerpt)
{
  "contact": { "name": "AdCP Community Registry — Meta translation", "domain": "adcontextprotocol.org" },
  "properties": [
    { "property_id": "instagram", "property_type": "mobile_app", "name": "Instagram", ... },
    { "property_id": "facebook",  "property_type": "mobile_app", "name": "Facebook",  ... },
    { "property_id": "whatsapp",  "property_type": "mobile_app", "name": "WhatsApp",  ... }
  ],
  "formats": [
    {
      "format_option_id": "meta_reels",
      "display_name": "Meta Reels (Instagram + Facebook)",
      "format_kind": "video_hosted",
      "applies_to_property_ids": ["instagram", "facebook"],
      "v1_format_ref": [
        { "agent_url": "https://creative.adcontextprotocol.org/translated/meta", "id": "meta_reels" }
      ],
      "params": {
        "orientation": "vertical",
        "aspect_ratio": "9:16",
        "duration_ms_range": [3000, 90000],
        "min_width": 1080,
        "min_height": 1920,
        "video_codecs": ["h264"],
        "audio_codecs": ["aac"],
        "containers": ["mp4"],
        "headline_max_chars": 40,
        "primary_text_max_chars": 125,
        "cta_values": ["LEARN_MORE", "SHOP_NOW", "DOWNLOAD", "SIGN_UP", "CONTACT_US", "BOOK_NOW"],
        "composition_model": "deterministic"
      }
    }
  ],
  "placements": [
    {
      "placement_id": "instagram_reels",
      "name": "Instagram Reels",
      "property_ids": ["instagram"],
      "format_options": [{ "format_option_id": "meta_reels" }]
    },
    {
      "placement_id": "facebook_reels",
      "name": "Facebook Reels",
      "property_ids": ["facebook"],
      "format_options": [{ "format_option_id": "meta_reels" }]
    }
  ]
}
```

バイヤー SDK は、このファイル（または最初に `meta.example/.well-known/adagents.json`。ミラーがフォールバック）をフェッチし `formats[]` を返すことで `list_creative_formats(publisher_domain="meta.example")` に答えます。「Meta はどのフォーマットをサポートするか」という質問全体が製品ごとのトラバーサルなしに 1 ラウンドトリップで解決します。

### 製品がカタログ宣言を再利用

セラーの `meta_reels_us` 製品は、`{publisher_domain, format_option_id}` でタグ付けされた完全な製品宣言を運ぶことでパブリッシャーカタログ宣言を再利用します。製品はその製品に固有の部分（地理、価格設定、より厳格な params）を絞ってもよいが、依然として `format_kind` と `params` をインラインで発行します。`{publisher_domain, format_option_id}` はマッチングキーで、スタンドアロン参照ペイロードではありません。Meta が自身の AdCP カタログを公開するまで、バイヤー SDK は `creative.adcontextprotocol.org/translated/meta` の AAO ミラー経由でカタログを解決します:

```json test=false theme={null}
{
  "product_id": "meta_reels_us",
  "name": "Meta Reels — United States",
  "publisher_properties": [
    { "publisher_domain": "meta.example", "selection_type": "all" }
  ],
  "channels": ["social"],
  "format_options": [
    {
      "format_kind": "video_hosted",
      "publisher_domain": "meta.example",
      "format_option_id": "meta_reels",
      "v1_format_ref": [
        { "agent_url": "https://creative.adcontextprotocol.org/translated/meta", "id": "meta_reels" }
      ],
      "params": {
        "orientation": "vertical",
        "aspect_ratio": "9:16",
        "duration_ms_range": [3000, 90000],
        "min_width": 1080,
        "min_height": 1920,
        "video_codecs": ["h264"],
        "audio_codecs": ["aac"],
        "headline_max_chars": 40,
        "primary_text_max_chars": 125,
        "cta_values": ["LEARN_MORE", "SHOP_NOW", "DOWNLOAD", "SIGN_UP", "CONTACT_US", "BOOK_NOW"],
        "composition_model": "deterministic"
      }
    }
  ],
  "pricing_options": [
    { "pricing_option_id": "cpm_floor", "pricing_model": "cpm", "currency": "USD", "fixed_price": 5.50 }
  ]
}
```

`{publisher_domain, format_option_id}` ペアはバイヤーエージェントがこれをパブリッシャーカタログから読んだのと同じ Meta Reels フォーマットオプションとして認識できるようにします — セラーはフォーマットを再発明せず、カタログ宣言に対して在庫を販売しています。バイヤーは `FormatOptionRef`（例えば `{ "scope": "publisher", "publisher_domain": "meta.example", "format_option_id": "meta_reels" }`）でそれを選択します。バイヤーのマニフェストはまず正準 `video_hosted` に対して検証（その正準を話す任意のセラーが受け入れるコントラクトを満たすか?）、次にこの製品の特定パラメーターに対して絞ります。

### 何がどこに存在するか（そしてなぜ）

* **正準 params** — 正準が既に定義するフィールド（寸法、期間、コーデック、CTA enum、char 制限）。セラーが値を絞る。SDK が検証。タイト、コード生成クリーン。
* **正準 slots** — マニフェストが運ぶコンテンツ。`video_hosted` は `video_main`、`headline`、`primary_text`、`cta`、`brand_name`、`companion_banner`、`landing_page_url` を継承。製品はオーバーライドできる（表面が使わないスロットを削除。required とマーク。値を絞る）。
* **`platform_extensions`** — 正準が認識しない新規フィールド、1 つのプラットフォームのレンダラーにスコープ（例: track\_id + ライセンシングフラグを運ぶ仮想的な Reels music オーバーレイ）。バイヤーが一度フェッチしキャッシュするよう `get_products` で URI+ダイジェストでバンドル。
* **`BrandRef` + `brand_kit_override`** — **セラー側レンダラー** がブランドをオーバーレイするフォーマットが消費するブランドコンテキスト（ロゴ、カラー、ボイス、タグライン）。ホストリードポッドキャスト、CTV バンパー、パブリッシャーダイレクトディスプレイはそれを消費する。Meta はリンクされたページから自動オーバーレイ（AdCP 外の認証コンテキスト）ので、brand\_kit\_override は Meta Reels に効果がない — それは消費する **ケースには依然として正しいスキーマ位置**。
* **キャンペーン / event-log 表面** — コンバージョントラッキング（Meta Pixel、GA4、サーバー側イベント）。これらは `sync_event_sources` / `event_log` に属する（キャンペーンスコープ、クリエイティブにかかわらずインプレッションごとに発火）。フォーマット宣言はクリエイティブ形状を運ぶ。event-log 宣言はトラッキング構成を運ぶ。クリエイティブフォーマットの `platform_extensions` に `pixel_id` を入れない。
* **メディアバイ表面** — プレースメント選択（Feed 対 Reels 対 Stories）。パブリッシャーカタログで正しいフォーマットを選ぶ（`meta_reels` 対 `meta_stories_video` 対 `meta_feed_image`）。クリエイティブごとの拡張ノブではない。

この分離 — 正準 params + 正準 slots + 新規フィールドのみの拡張 + ブランドコンテキストの BrandRef + トラッキングの event\_log — が、12 の正準がプラットフォームごとフィールドを蓄積するのを防ぎます。`tests/canonical-format-conventions.test.cjs` の lint が `v1_format_ref.agent_url` AAO ホスト規約とスロット/param 一貫性ルールを強制します。

## 実例 — IAB ディスプレイ（柔軟なマルチフォーマット、マルチサイズ）

実際の IAB ディスプレイプレースメントは単一の 300×250 画像スロットではありません — 複数の **サイズ**（300×250 MREC、728×90 leaderboard、970×250 billboard、レスポンシブ）で複数の **クリエイティブタイプ**（image、HTML5、サードパーティタグ、ときどきネイティブや video-in-banner）を受け入れる柔軟なスロットです。正準フォーマット語彙は 2 つの直交メカニズムでこれをモデル化します:

* **`format_kind`** はクリエイティブ TYPE — `image`、`html5`、`display_tag`、`native`、`video_hosted` の 1 つ — で決して寸法アイデンティティを運ばない。
* **サイズは `params` に存在** 3 つのモードの 1 つとして（相互排他的）:
  * **固定**: `width` + `height` 整数 — 単一の受け入れサイズ（例: 300×250 のみのレガシースロット）。
  * **マルチサイズ**: `sizes: [{width, height}, ...]` — 柔軟なスロットの受け入れサイズのリスト。OpenRTB `banner.format[]` をミラー。
  * **レスポンシブ**: `min_width`/`max_width` + `min_height`/`max_height` — ビューポートに適応するスロットの受け入れ寸法範囲。

柔軟なパブリッシャースロットは **N format\_options を持つ 1 つの製品** になります — クリエイティブタイプごとに 1 つ — 各々が適切なサイズ宣言を運ぶ。バイヤーは出荷するクリエイティブタイプを選ぶ。サイズはリストされたペアの 1 つに一致（またはレスポンシブ範囲内に収まる）。

下の例は NYTimes ホームページ above-the-fold スロット: 3 つの IAB サイズのいずれかで image、HTML5、またはサードパーティタグを受け入れる。3 つの format\_options、1 つの製品、1 つの価格。

```json test=false theme={null}
{
  "product_id": "nytimes_homepage_flex_display",
  "name": "NYTimes.com Homepage Above-the-Fold Display",
  "publisher_properties": [
    { "publisher_domain": "nytimes.com", "selection_type": "all" }
  ],
  "channels": ["display"],
  "format_options": [
    {
      "format_kind": "image",
      "format_option_id": "nytimes_homepage_image",
      "params": {
        "sizes": [
          { "width": 300, "height": 250 },
          { "width": 728, "height": 90 },
          { "width": 970, "height": 250 }
        ],
        "max_file_size_kb": 200,
        "image_formats": ["jpg", "png", "gif"],
        "ssl_required": true,
        "cta_values": ["LEARN_MORE", "SHOP_NOW", "GET_OFFER"]
      }
    },
    {
      "format_kind": "html5",
      "format_option_id": "nytimes_homepage_html5",
      "params": {
        "sizes": [
          { "width": 300, "height": 250 },
          { "width": 728, "height": 90 },
          { "width": 970, "height": 250 }
        ],
        "max_initial_load_kb": 200,
        "max_polite_load_kb": 500,
        "backup_image_required": true,
        "om_sdk_required": true
      }
    },
    {
      "format_kind": "display_tag",
      "format_option_id": "nytimes_homepage_3p_tag",
      "params": {
        "sizes": [
          { "width": 300, "height": 250 },
          { "width": 728, "height": 90 },
          { "width": 970, "height": 250 }
        ],
        "supported_tag_types": ["javascript", "iframe"],
        "ssl_required": true,
        "om_sdk_required": true
      }
    }
  ],
  "pricing_options": [
    { "pricing_option_id": "cpm_homepage", "pricing_model": "cpm", "currency": "USD", "fixed_price": 22.00 }
  ]
}
```

**何が起きているか:** 1 つの製品、3 つの `format_options` エントリー（クリエイティブタイプごとに 1 つ）、各々が 3 つの受け入れ IAB サイズを運ぶ `sizes[]` を持つ。バイヤーエージェントはこれを「スロットは `300×250` / `728×90` / `970×250` のいずれかで `image` または `html5` または `display_tag` を受け入れる」と読む。バイヤーは 1 つのクリエイティブを出荷 — どのタイプとどのサイズを選ぶ — し、検証は選ばれた format\_kind の適切な `sizes[]` リストに対してマニフェストのスロット `width`/`height` をチェック。

**レスポンシブバリアント。** レスポンシブスロットは `sizes[]` を min/max 範囲で置き換え — `min_width: 300, max_width: 970, min_height: 50, max_height: 250` — ボックス内の任意の寸法を受け入れる。同じマルチフォーマットパターン。異なるサイズ宣言。format\_options エントリーごとにちょうど 1 つのサイズモード（固定 `width`+`height` / マルチサイズ `sizes[]` / レスポンシブ範囲）、スキーマ層で強制。

**セラー選好。** マルチフォーマット製品が同じ価格で複数の `format_options` を持つとき、セラーは各エントリーに `seller_preference: "preferred" | "accepted" | "discouraged"` を設定してセラーがバイヤーに出荷してほしいものをヒントしてもよい（MAY）（しばしばビューアビリティ / 測定 / レンダー品質の違いのため）。ソフトルーティングシグナル — バイヤーエージェントは自身の制約が上書きしないとき尊重する。

## 実例 — ポッドキャスト 30s ホストリード

ホストリードは host-recorded-from-buyer-script パターンです。製品は、バイヤーが出荷するもの（`script` テキストアセット。パブリッシャーのホストがそれからオーディオを録音）を記述する `slots` で publisher-host-recorded モードに絞られた `audio_hosted` を宣言します:

```json test=false theme={null}
{
  "product_id": "the_daily_30s_host_read_us",
  "name": "The Daily — 30s Host-Read Pre-roll (US)",
  "publisher_properties": [
    { "publisher_domain": "thedailypod.example", "selection_type": "all" }
  ],
  "channels": ["podcast"],
  "format_options": [
    {
      "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": "publisher_host_recorded",
        "buyer_asset_acceptance": "rejected",
        "composition_model": "deterministic",
        "slots": [
          {
            "asset_group_id": "script",
            "required": true,
            "asset_type": "text",
            "max_chars": 800,
            "description": "Verbatim script the host reads."
          },
          {
            "asset_group_id": "offering_ref",
            "required": false,
            "asset_type": "text"
          }
        ],
        "production_window_business_days": 7
      }
    }
  ],
  "pricing_options": [
    { "pricing_option_id": "cpm_host_read", "pricing_model": "cpm", "currency": "USD", "fixed_price": 35.00 }
  ]
}
```

フォーマット宣言はバイヤーが知る必要のあるすべてを伝えます — 追加のケイパビリティルックアップなし。バイヤーはマニフェストの `assets` マップのそのスロットの下に `script` テキストアセットを出荷。ブランドコンテキストはマニフェストのトップレベル `brand` BrandRef から来る。別の「inputs」マップはない — バイヤーが出荷するすべては `assets` に存在。バイヤーは、セラーがクリエイティブエージェントを兼ねるかとバイヤーが外部で事前生成したいかに応じて 2 つのフローを持つ。

### フロー 1 — バイヤーが事前生成（アップストリームクリエイティブエージェント）

バイヤーはクリエイティブエージェントの `build_creative` を独立に呼び、レンダーされたマニフェストを取り戻し、それをセラーに提出。バイヤーが好みの生成パートナー（インハウススタジオ、AudioStack スタイルサービス）を持つとき、またはセラーが自身をクリエイティブエージェントとして露出するときに有用。

1. バイヤーが The Daily の製品フォーマットを読む → `slots: [{ asset_group_id: "script", asset_type: "text", required: true }]` が宣言されているのを見る
2. バイヤーがクリエイティブエージェントで `build_creative({ format: <The Daily's audio_hosted narrowing>, assets: { script: { asset_type: "text", content: "..." } }, brand: { domain: "..." } })` を呼ぶ — これは The Daily 自身のクリエイティブエージェント表面（露出すれば）、または `get_adcp_capabilities` の `creative.supported_formats` 経由でこのフォーマットを生成できると宣言する他の任意のエージェント
3. オーディオアセット付きのレンダーされたマニフェストを受け取る
4. `sync_creatives` 経由でレンダーされたマニフェストを The Daily のセールスエージェントに提出

### フロー 2 — セラーが内部で生成

バイヤーはアセットを直接セラーに提出。セラーは内部で生成（自身のクリエイティブチームまたはアップストリームクリエイティブエージェントを裏で呼ぶ）し登録されたクリエイティブを返す。

1. バイヤーが同じ製品フォーマットを読む
2. バイヤーがマニフェストのアセット（例: `assets` マップのそのスロットの下の `script` テキストアセット）で `sync_creatives` 経由で提出
3. セラーが内部で生成。どうやってかはバイヤーに不可視
4. 非同期ステータスを返す。バイヤーがポーリングまたは完了を待つ

フォーマットの `asset_source: "publisher_host_recorded"` + `buyer_asset_acceptance: "rejected"` はバイヤーにどのフローが受け入れられるかを伝える。The Daily のホストリードには、パブリッシャーのホストがどちらのケースでも生成者である必要があるため両フローが有効 — 違いはバイヤーがビルド呼び出しを駆動するかセラーが駆動するか。他の製品はフロー 1 のみ（バイヤーが事前生成しなければならない）またはフロー 2 のみを受け入れるかもしれない。

ブリーフ駆動（talking-points スタイル）ホストリードには、`script` スロットの代わりに `creative_brief` スロット（asset\_type `brief`）で同じ形状が適用。同じターゲットフォーマット（`audio_hosted`）。異なるスロット宣言。

## 実例 — サードパーティクリエイティブエージェント（Flashtalking + NYTimes ディスプレイ）

上のホストリード例は必然的に単一アクター: パブリッシャーのホストが生成者でなければならない。反対のケースはマルチアクターディスプレイパスで、バイヤーが独立にサードパーティクリエイティブエージェントを選び生成されたマニフェストをセラーに出荷。セラーはクリエイティブを合成 **しません** — 正準適合マニフェストを受け入れるだけ。

3 アクター:

* **バイヤー**（Acme DSP） — 製品を発見、クリエイティブエージェントを選ぶ（帯域外: ブランド側関係、AAO レジストリ、直接知識）、マニフェストを提出
* **セールスエージェント**（NYTimes） — プレースメントを販売、製品が絞る正準に対してマニフェストを検証、クリエイティブを合成しない、v2 で「承認されたクリエイティブエージェント」のリストを保守しない
* **クリエイティブエージェント**（Flashtalking） — `build_creative` 経由でクリエイティブを生成、自身の `get_adcp_capabilities` の `creative.supported_formats` 経由で自身の生成可能なカタログを宣言

バイヤーはセラーから独立にクリエイティブエージェントを選びます。セラーは v2 でクリエイティブエージェントのリストを宣言しません — `list_creative_formats` の v1 `creative_agents[]` 再帰ディスカバリーヒントは非推奨 v1 表面の一部。バイヤーはクリエイティブエージェント ↔ セラー製品互換性をクライアント側で推論: 「Flashtalking は `image` 300×250 ≤200KB を生成できる。NYTimes は `image` 300×250 ≤200KB を受け入れる。互換。」

### 1. バイヤーが NYTimes 製品を読む

バイヤーが NYTimes で `get_products` を呼ぶ。MREC 製品が正準 `image` を絞る:

```json test=false theme={null}
{
  "product_id": "nytimes_homepage_mrec",
  "format_options": [
    {
      "format_kind": "image",
      "params": { "width": 300, "height": 250, "max_file_size_kb": 200, "ssl_required": true }
    }
  ]
}
```

製品が正準を絞る。正準が NYTimes が検証にコミットするもの。NYTimes は Flashtalking の絞り込みに対して検証 **しません** — バイヤーはどのクリエイティブエージェントがマニフェストを生成したか知る必要がなく、Flashtalking 固有パラメーター（例: Flashtalking プレースメント ID）はあるとしても Flashtalking のプラットフォーム拡張に存在。

### 2. バイヤーが Flashtalking の `build_creative` を呼ぶ

```json test=false theme={null}
// POST https://flashtalking.example/build_creative
{
  "format": {
    "format_kind": "image",
    "params": { "width": 300, "height": 250 }
  },
  "brand": { "domain": "acme.example" },
  "assets": {
    "creative_brief": { "asset_type": "brief", "content": "Spring sale, 50% off, blue background, urgent CTA." },
    "landing_page_url": { "asset_type": "url", "url": "https://acme.example/spring" }
  }
}
```

Flashtalking が MREC PNG をレンダーし、生成されたアセット付きのマニフェストを返す:

```json test=false theme={null}
{
  "creative_id": "ft_mrec_88299",
  "manifest": {
    "format_id": { "agent_url": "https://flashtalking.example", "id": "image_300x250" },
    "assets": {
      "image": { "asset_type": "image", "url": "https://cdn.flashtalking.com/ft_mrec_88299.png", "width": 300, "height": 250 }
    }
  }
}
```

### 3. バイヤーが NYTimes に出荷

バイヤーが Flashtalking からのマニフェストで NYTimes の `sync_creatives` を呼ぶ。NYTimes:

1. マニフェストを正準 `image`（300×250、≤200KB、SSL）に対して検証。
2. 製品の絞り込みに対して検証（一致 — 同じ params）。
3. Flashtalking の絞り込みに対して検証 **しない** — それはクリエイティブエージェントのバイヤーとのコントラクトで、セラーのコントラクトではない。
4. 有効なら → クリエイティブ登録。そうでなければ → 正準違反を返す（`width` 不一致、`max_file_size_kb` 超過）。

セラーの検証コントラクトは正準で、クリエイティブエージェントではない。これがサードパーティパスを結合ではなく追加的にするもの: バイヤーはセラー向けフローを変えずにクリエイティブエージェントを交換できる。

## 実例 — 生成 DSP（universalads 級、asset\_source: seller\_pre\_rendered\_from\_brief）

生成 DSP（universalads、Pencil、AdCreative.ai 形状ツール）は、`sync_creatives` 時にインラインでクリエイティブをも レンダーするセールスエージェントです — バイヤーが別途呼ぶクリエイティブエージェントでは **ありません**。バイヤーはブリーフプラス構造化コピーを出荷。セラーは 1 つの画像をレンダーし任意の決定的クリエイティブのようにサーブ。

```json test=false theme={null}
{
  "product_id": "universalads_brief_driven_display_300x250",
  "name": "Universal Ads — Brief-Driven Display (300×250)",
  "publisher_properties": [
    { "publisher_domain": "universalads.example", "selection_type": "all" }
  ],
  "channels": ["display"],
  "format_options": [
    {
      "format_kind": "image",
      "params": {
        "width": 300,
        "height": 250,
        "max_file_size_kb": 200,
        "image_formats": ["jpg", "png"],
        "ssl_required": true,
        "composition_model": "deterministic",
        "asset_source": "seller_pre_rendered_from_brief",
        "buyer_asset_acceptance": "rejected",
        "production_window_business_days": 0,
        "slots": [
          { "asset_group_id": "creative_brief", "asset_type": "brief", "required": true, "max_chars": 500 },
          { "asset_group_id": "headline", "asset_type": "text", "required": true, "max_chars": 30 },
          { "asset_group_id": "landing_page_url", "asset_type": "url", "required": true }
        ]
      }
    }
  ],
  "delivery_type": "non_guaranteed",
  "pricing_options": [
    { "pricing_option_id": "cpm_brief", "pricing_model": "cpm", "currency": "USD", "floor_price": 8.00 }
  ]
}
```

バイヤーのマニフェストはブリーフ、headline、クリックスルー URL を運ぶ — レンダーされた画像アセットなし。セラーの `sync_creatives` がレンダーされた MREC PNG を生成し登録。2 軸: `composition_model: deterministic`（表面は受け取ったものをサーブ）、`asset_source: seller_pre_rendered_from_brief`（セラーが同期時に入力からレンダー）。`buyer_asset_acceptance: "rejected"` はバイヤーが事前レンダーされた画像を直接出荷できないことを明示 — 生成モデルはブリーフ駆動のみ。

## 実例 — マルチフォーマット製品（サードパーティ html5 または内部 display\_tag）

サードパーティホストクリエイティブ または 内部タグ のいずれかを受け入れるプレースメント — バイヤーは sync\_creatives 時にマニフェストの `format_kind` と、必要なとき `format_option_ref` を一致する宣言に揃えることで選ぶ:

```json test=false theme={null}
{
  "product_id": "regional_news_homepage_300x250",
  "channels": ["display"],
  "format_options": [
    {
      "publisher_domain": "regional-news.example",
      "format_option_id": "html5_third_party_hosted",
      "format_kind": "html5",
      "params": {
        "width": 300,
        "height": 250,
        "max_initial_load_kb": 200,
        "ssl_required": true,
        "composition_model": "deterministic"
      }
    },
    {
      "publisher_domain": "regional-news.example",
      "format_option_id": "display_tag_internal",
      "format_kind": "display_tag",
      "params": {
        "width": 300,
        "height": 250,
        "ssl_required": true,
        "composition_model": "deterministic"
      }
    }
  ]
}
```

html5 オプションをターゲットするバイヤーのマニフェスト:

```json test=false theme={null}
{
  "format_kind": "html5",
  "format_option_ref": {
    "scope": "publisher",
    "publisher_domain": "regional-news.example",
    "format_option_id": "html5_third_party_hosted"
  },
  "assets": { "html5_bundle": { /* ... */ }, "backup_image": { /* ... */ } }
}
```

**複数要素 `format_options` のルーティングルール**（規範的）:

* `format_kind` が正準とそのスロット語彙を選択。
* `format_option_ref` は、ターゲット製品の `format_options` が同じ `format_kind` を共有する 2 つ以上の宣言を含むときマニフェストで **必須** — それなしでは、セラーはバイヤーがどのオプションに対して出荷しているかを曖昧性解消できない。
* `format_option_ref` は、製品の `format_options` の各 `format_kind` が一意のとき **オプション**（上の例: 1 つの html5 エントリー、1 つの display\_tag エントリー） — `format_kind` だけがマニフェストをルーティング。バイヤーは明確化ヒントとして `format_option_ref` を依然として送ってもよい（MAY）。

この例では各オプションが別個の `format_kind` を運ぶので、`format_option_ref` はオプション。それを含めること（示された通り）は推奨される習慣 — ログ、リプレイ、下流ツールにマニフェストを曖昧でなくし、セラーの製品が種類を共有する 1 つまたは多くのオプションを持つかにかかわらずバイヤー側コードパスを同一に保つ。

## 実例 — item\_production\_model を持つ sponsored\_placement

カタログ参照プラスブリーフを受け入れ、同期時にカタログアイテムごとに 1 つのクリエイティブをレンダーするリテールメディア製品:

```json test=false theme={null}
{
  "product_id": "regional_retailer_generative_offerings",
  "channels": ["display"],
  "catalog_types": ["product"],
  "format_options": [
    {
      "format_kind": "sponsored_placement",
      "params": {
        "supported_catalog_types": ["product"],
        "min_items": 5,
        "max_items": 200,
        "fanout_mode": "per_item",
        "supported_id_types": ["sku", "gtin"],
        "item_production_model": "seller_pre_rendered_from_brief",
        "composition_model": "deterministic",
        "slots": [
          { "asset_group_id": "source_catalog", "asset_type": "catalog", "required": true },
          { "asset_group_id": "creative_brief", "asset_type": "brief", "required": true, "max_chars": 500 }
        ]
      }
    }
  ]
}
```

`item_production_model: seller_pre_rendered_from_brief` は言う: 各カタログアイテムについて、セラーはブリーフプラスカタログアイテムの構造化フィールド（title、image、price）を使って 1 つのクリエイティブをレンダー。`fanout_mode: per_item` は各アイテムが配信で自身の広告を得ると言う。一緒に、既存の `sponsored_placement` 正準の下でマルチ出力生成パターン（1 ブリーフ × N アイテム → N 広告）を捕捉。

## 実例 — Pinterest: どの正準?

Pinterest は正準曖昧性解消例です。なぜなら単一のプラットフォームが 2 つの構造的に異なる形状の下で在庫を販売するから。これらの製品を読むバイヤーエージェントは一致する正準にルーティングしなければ、マニフェストがレンダーしません。

| Pinterest product                                         | Canonical                                            | Why                                                                                                                                                                          |
| --------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Promoted Pin**（ホーム/検索フィードのスポンサード単一 Pin）                 | `native_in_feed`                                     | アセットバンドル合成 — バイヤーは title + image + body + landing URL を出荷。Pinterest のレンダラーがフィードルックアンドフィールに合わせて Pin を組み立てる。カタログフィードなし。バイヤー供給のバンドルがクリエイティブ。                                    |
| **Pinterest Collection**（カタログから取得された単一ヒーロー画像 + 3 製品サムネイル） | `sponsored_placement`                                | カタログキー — バイヤーは `source_catalog` 参照（とオプションの `hero_asset`）を出荷。Pinterest が製品カタログ行を読んでアイテムごとサムネイルを合成。`fanout_mode: multi_item_in_creative` が Collection をアイテムごとリテールメディア SP から区別。 |
| **Pinterest Idea Pin**（マルチページスワイプ可能ネイティブユニット。ページは画像または動画） | `image_carousel`                                     | マルチカードスワイプ形状 — カルーセル正準のカードごとスロットはポリモーフィック画像 or 動画で、1 つの Pin 内で 2 つを混ぜる Idea Pin ページに一致。                                                                                      |
| **Pinterest Shopping Pin**（カタログ行にキーされた単一製品 Pin）           | `fanout_mode: single_item` を持つ `sponsored_placement` | 1 つのカタログアイテムから引かれた単一のレンダーされたクリエイティブ — 依然としてカタログキー合成、ただ広告ごとに 1 アイテム。                                                                                                          |

分割は **アセットバンドル対カタログ行合成** で、「Pinterest かどうか」ではありません。同じロジックが Snap Story Ad（native\_in\_feed）対 Snap Collection（sponsored\_placement）、TikTok TopView（`applies_to_channels: ["social"]` 経由の native\_in\_feed）対 TikTok Collection（sponsored\_placement）などに適用。バイヤーエージェントは合成形状でルーティング。表面のパブリッシャーのブランドは付随的。

上の `fanout_mode: single_item` ケースは独自のファミリー: プラットフォームがマルチアイテムコレクションではなく **インプレッションごとに 1 SKU** を合成するカタログ駆動レンダー。Meta Dynamic Product Ads（単一製品レンダー）、single-item モードの Snap Collection、TikTok Shopping single-SKU はすべて `fanout_mode: single_item` を持つ `sponsored_placement` にマップ — バイヤーはカタログ参照を出荷しセラーが広告ごとに 1 アイテムをレンダー、プラットフォームがどのアイテムを選択。これは依然としてカタログ行合成。`multi_item_in_creative` とは 1 つのクリエイティブに何アイテム着地するかだけが異なる。アダプターごとランタイムコントラクトについては [Sponsored Placement アダプターコントラクト](/docs/creative/sponsored-placement-adapter-contracts) を参照（§3 の Collection-layout ファミリーが Pinterest/Snap Collection をカバー）。

`format_kind: native_in_feed` 製品を読むバイヤーエージェントは、自身のクリエイティブプールから title/image/body/CTA バンドルを組み立てることを知る。`format_kind: sponsored_placement` を読むと、カタログフィードを添付しセラーにアイテムごと合成させることを知る。判別子が決定を運ぶ。プラットフォームごとの分岐は不要。

## 検証フロー — `validate_input`

バイヤーはレンダーにコミットせずに正準や特定の製品に対してマニフェストをドライランできます。下のバイヤーのマニフェストは v2 マニフェスト（`format_kind: "video_hosted"`）。スロットキーは正準の `asset_group_id`（`video_main`）。アセット値は `asset_type` 判別子を運ぶ。バイヤーは `validate_input` に正準コントラクト かつ セラーの特定製品絞り込みの両方を単一ラウンドトリップでチェックするよう頼む:

```json test=false theme={null}
{
  "manifest": {
    "format_kind": "video_hosted",
    "assets": {
      "video_main": {
        "asset_type": "video",
        "url": "https://cdn.acme.example/spring-95s.mp4",
        "duration_ms": 95000,
        "width": 1080,
        "height": 1920
      }
    },
    "brand": { "domain": "acme.example" }
  },
  "targets": [
    { "kind": "canonical", "id": "video_hosted" },
    { "kind": "product", "id": "meta_reels_us" }
  ]
}
```

レスポンスはターゲットごとの結果を運ぶ。正準は期間を受け入れる（正準 `video_hosted` は期間を制約しない — 製品が絞る）。Meta Reels 製品は期間を `[3000, 90000]` ms に絞るので、95000 は範囲外で製品ターゲットは失敗:

```json test=false theme={null}
{
  "results": [
    {
      "target": { "kind": "canonical", "id": "video_hosted" },
      "result_kind": "validated_pass"
    },
    {
      "target": { "kind": "product", "id": "meta_reels_us" },
      "result_kind": "validated_fail",
      "violations": [
        {
          "rule": "duration_ms_range",
          "expected": "3000-90000",
          "predicted": 95000,
          "field": "assets.video_main.duration_ms"
        }
      ]
    }
  ]
}
```

`validate_input` は予測可能ケースプリミティブです。真に非決定的な合成（Veo / Sora / Runway 級）には、予測検証は不可能でプラットフォーム自身の合成後 QA ループが適用 — QA ループが有効なアーティファクトを生成せずに尽きると提出は `synthesis_failed` 理由で `task_failed` を返す。**孤立したスペック外アーティファクトのプロトコル状態はありません**。

### `validate_input` をいつ使うか

決定ルール、ワンサイズプリミティブではない:

* **高価な `build_creative` 呼び出しの前のプリフライト。** マニフェストが正準に対してさえ絞れない場合、バイヤーは合成コストを節約。各リトライが実 GPU コストを持つ非決定的合成製品に特に関連。
* **製品選択中のマルチターゲットドライラン。** 10 の候補製品を比較するバイヤーは、すべての 10 product\_id で `validate_input` を一度頼み、ターゲットごとの結果を取り戻す。10 の別々の `sync_creatives` ラウンドトリップより安い。
* **拒否されたマニフェストのデバッグ。** `sync_creatives` が違反を返すとき、正準単独に対して `validate_input` を呼ぶことは質問を「私のマニフェストが根本的に壊れているか対製品の絞り込みがゲート制約か」に絞る。
* **プレビューレンダーゲート**（`composition_model: algorithmic` または `synthesis_nondeterministic: true` のフォーマット）。プラットフォームのプレビュー表面はよりリッチな後続。`validate_input` はプレビューが試みる価値さえあるかをゲートする安価なプリフライト。

`validate_input` を使わないとき:

* とにかく提出しようとするマニフェストには。`sync_creatives` が同じ違反を返し成功時に登録 — `validate_input` は総作業を減らさずにラウンドトリップを追加。
* セラーの絞り込みが拡張をフェッチせずにクライアント側で不明な製品には。`validate_input` は `sync_creatives` と同じく拡張を引く — ディスカバリーショートカットなし。
* 高ボリュームのインプレッションごと決定には。`validate_input` はターゲットごとで、インプレッションごとではない。運用規模（数百製品 × N format\_options）はキャッシュされた `get_products` レスポンスに対するクライアント側フィルタリングに属す。

### `validate_input` 対 `build_creative` 対 `sync_creatives`

| Tool             | Who calls              | What it does                                                                                      | Side effects                                                                                                    |
| ---------------- | ---------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| `validate_input` | バイヤー                   | 正準や製品に対するドライラン検証。ターゲットごとに `validated_pass`、`validated_fail`、`unvalidatable_nondeterministic` を返す。 | なし（クリエイティブ登録なし、合成トリガーなし）。                                                                                       |
| `build_creative` | バイヤー（クリエイティブエージェントを呼ぶ） | 入力（ブリーフ、video\_brief、ブランド）からクリエイティブマニフェストを生成。決定的フロー: 1 ラウンドトリップ。非決定的フロー: QA ループセマンティクスを持つタスクを返す。  | 合成が起こる。出力マニフェストが返される。エージェントが `has_creative_library` をサポートすればクリエイティブエージェントのライブラリにクリエイティブを登録するかも。セラーには登録 **しない**。 |
| `sync_creatives` | バイヤー（セラーを呼ぶ）           | マニフェストをセールスエージェントに提出しセラーが製品に対して登録。                                                                | 正準 + 製品絞り込みに対して検証。成功時にセラーのライブラリにクリエイティブを登録。失敗時に違反を返す。                                                           |

サードパーティクリエイティブエージェントフローには: `validate_input` 最初（安価なプリフライト） → クリエイティブエージェントの `build_creative` → セールスエージェントの `sync_creatives`。インハウス事前レンダーフローには: `build_creative` をスキップ。`validate_input` 次に `sync_creatives`。ブリーフからセラーがレンダーするフロー（universalads 級）には: `build_creative` をスキップ（セラーが `sync_creatives` 時にレンダリング）。`validate_input` 次に `sync_creatives` を直接。

完全なリクエスト/レスポンス形状については [`build_creative` タスクリファレンス](/docs/creative/task-reference/build_creative) を参照。

### 期間制約の優先順位

ホスト動画とホストオーディオ製品は 2 つのモードで期間制約を表現できます:

1. 固定必須期間の `duration_ms_exact`
2. 境界または片側範囲の `duration_ms_range`

別の min-only または max-only 期間フィールドはありません。片側 `duration_ms_range` が 3 番目の期間語彙を追加せずにそれらのケースをカバー。

`duration_ms_range` はミリ秒の `[min, max]`。どちらの端点も無制限側を表現するため `null` でよい（MAY）: `[null, 60000]` は「最大 60 秒」を意味し、`[15000, null]` は「少なくとも 15 秒」を意味。`[null, null]` は少なくとも 1 つの端点が境界されなければならないため無効。

両モードが同じ宣言に現れるとき、`duration_ms_exact` が `duration_ms_range` に勝つ。プロデューサーは 1 つのモードのみを発行すべき（SHOULD）。SDK は両モードが出荷されるとき警告を lint すべき（SHOULD）だが、消費者は依然として優先ルールを適用しなければならない（MUST）。固定 60 秒スポットは `duration_ms_exact: 60000` または同等の閉じた範囲 `[60000, 60000]` を使える。製品が真に 1 つの期間を要求するとき `duration_ms_exact` を優先。

### Format matching vs product satisfaction

セラーと SDK は、レガシー名前付きフォーマットを正準宣言と比較する前に正規化しなければなりません（MUST）。`{ "agent_url": "https://creative.adcontextprotocol.org", "id": "display_300x250" }` のようなレガシー `format_id` は、明示的な `canonical` アノテーション、`v1_format_ref`、または正準マッピングレジストリを通じて `params.width: 300` と `params.height: 250` を持つ `format_kind: "image"` のような正準宣言に解決されます。その投影の後、実装は生の `(agent_url, id)` ペアではなく正準形状とパラメーターを比較します。

2 つの関連チェックが異なる方向性を使います:

* **等価マッチング** は、正規化後に 2 つの宣言が同じ基盤クリエイティブ形状を識別するかに答えます。`display_300x250` と `width: 300` かつ `height: 250` を持つ `format_kind: "image"` は、ワイヤー識別子が異なっても等価です。
* **製品満足** は、提出または要求されたクリエイティブが製品の受け入れフォーマット宣言に十分具体的かに答えます。製品が固定 `width`、`height`、`duration_ms_exact`、`duration_ms_range` を宣言するとき、要求されたクリエイティブまたはパッケージセレクターはその制約を宣言し一致しなければなりません（MUST）。過小指定リクエストは製品ゲートのワイルドカードではありません。

範囲制約は重複ではなく包含を使います。範囲ベースリクエストは、リクエストが許可するすべての値が製品の受け入れ範囲内に収まるときのみ製品を満たします。重複だけでは不十分。`duration_ms_exact` のような正確な値は、その正確な値が受け入れ区間内に収まるとき範囲を満たします。

具体例:

| Product declaration                       | Buyer request / creative                   | Result                       |
| ----------------------------------------- | ------------------------------------------ | ---------------------------- |
| `image`、`width: 300`、`height: 250`        | レガシー `display_300x250`、`image` 300x250 に投影 | 一致                           |
| `image`、`width: 300`、`height: 250`        | width/height なしの `image`                   | この製品には拒否 — リクエストが過小指定        |
| width/height 制約なしの `image`                | `image` 300x250                            | 一致 — 広い製品が特定のクリエイティブを受け入れられる |
| `video_hosted`、`duration_ms_exact: 30000` | 期間なしの `video_hosted`                       | この製品には拒否 — 期間が過小指定           |

この非対称性は 2 つの失敗モードを防ぎます: 互換性のあるレガシー/正準ペアを拒否する完全 ID 比較、過小指定リクエストが固定サイズまたは固定期間製品を満たすことを許す過度に広いマッチング。

### 規模でのディスカバリー + 検証

高製品数バイヤー（get\_products レスポンスごとに数百製品を持つ TTD 級）は、ラウンドごとに `validate_input` 経由ですべての製品をプリフライトできません — N 製品 × M format\_options × ターゲットごとラウンドトリップは運用的に高価になります。2 つのパターンがこれに対処:

* **キャッシュされた `get_products` レスポンスに対するクライアント側フィルタリング。** マニフェストの `format_kind` とパラメーターバケット（正準、寸法、期間）を知るバイヤーは、検証前に製品リストをクライアント側でフィルター。フォーマット宣言は既に各製品にインライン — バイヤーはフィルターするため別のフェッチを必要としない。これは「私のクリエイティブを受け入れうる製品に対して検証」の支配的パターンで、validate\_input セットを 1 桁減らす。
* **マルチターゲット `validate_input`。** フィルターされたセットがまだ広い（5-50 製品）とき、すべての候補 product\_id を `targets[]` に入れて `validate_input` を一度呼ぶ。レスポンスはターゲットごとの結果を単一ラウンドトリップで運ぶ。製品ごと呼び出しより安く、スキーマと構造的に揃う（1 リクエスト、多くの結果）。

真に高ボリュームシナリオ（数百の候補製品、リアルタイムビディングプリフライト）には、バイヤーはキャッシュされた `get_products` レスポンス + クライアント側フィルタリングを主要パスとして依存すべき。`validate_input` は絞られた候補セットまたは予期しない拒否のデバッグに予約。各 format\_options 要素の `applies_to_channels` フィールドは、製品が複数のチャネルにまたがるときさらに絞る。

## 「これが何を生成するか」のユニバーサル表面としてのプレビュー

バイヤーはフォーマットの `slots` 宣言に従いアセットを出荷。`preview_creative` が出力が何としてレンダーするかを表示。クリエイティブ提出へのセラーのレスポンスもプレビュー URL を含められる — バイヤーは提出が意図した出力を生成したことを検証するため別のプレビュー呼び出しを必要としない。同じ表面、2 つの生成パス:

* **直接レンダリング**: バイヤーが完成したクリエイティブアセット（image、video、audio）を出荷 → セラーがプレースメントでそれらをレンダー → プレビューがレンダーされた出力を表示（セラー側合成、オーバーレイ、CTA ボタン適用）。
* **セラー側生成**: バイヤーがセラーが消費するコンテンツ（script text、creative\_brief、voice\_id 選択）を出荷 → セラーがレンダーされたアセットを内部で生成（ホスト録音、生成 AI 合成、トランスコーディング — 不可視） → プレビューが生成された出力を表示。

バイヤーは出荷したアセットで反復しバイにコミットする前にプレビューを検査できる。異なるセラーは内部で異なる生成をするかも。プレビュー表面は一様。これが「生成メカニズムはバイヤーに不可視」を実践で機能させるもの — バイヤーは出力がどう生成されたか知る必要がない、なぜなら何が生成されたかを見られるから。

## brand.json 経由のブランドアイデンティティ（オーバーライド付き）

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

brand.json が欠けているか古いケースには、BrandRef 自体がインライン `brand_kit_override` を運びます:

```json test=false theme={null}
{
  "format_kind": "image",
  "assets": {
    "image_main": { "asset_type": "image", "url": "https://cdn.acme.example/banner.jpg", "width": 300, "height": 250 }
  },
  "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` より優先します。パターンは BrandRef の既存インラインオーバーライド（`industries`、`data_subject_contestation`）に一致 — brand.json が正準。インラインオーバーライドは呼び出しごと。このサブセット外のブランドキットフィールド（`voice_attributes`、`prohibited_terms`）をオーバーライドする必要のあるアダプターは、異なる brand.json を公開し異なる `domain` 経由で参照しなければなりません（MUST）。

## プラットフォーム拡張 — 配布

プラットフォーム拡張は狭く、真にプラットフォーム固有の追加（ピクセル ID 形状、コンバージョンイベント分類、プラットフォーム固有 CTA/デスティネーション）です。それらは所有エージェントの well-known パスに存在します:

```
https://creative.adcontextprotocol.org/translated/meta/extensions/meta_pixel
https://tiktok.example/extensions/tiktok_pixel
https://nytimes.example/extensions/nytimes_om_strict
```

各拡張のレスポンスはスキーマ、それが拡張する正準パターンまたはスロット、バージョン、コンテンツダイジェストを運びます。

**ホスティングパス — 2 つの別々のフロー。** v2 は 2 つのホスティングモデルをサポート、正準 URI の所有者がオープン AdCP エコシステムに参加するか AAO がその代理で翻訳するクローズドプラットフォームとして運用するかに応じて。

*オープンエコシステムパス（パブリッシャーホスト）*。URI サブドメインを所有するパブリッシャーが AdCP に直接参加するとき使う — 独立パブリッシャー、SSP、自身の正準拡張を実行するリテールメディアネットワーク。パブリッシャーはサブドメインの正準 URI でアーティファクトをホスト。URI はダイジェストピン留めされる（`uri@sha256:…`）ので、レスポンスはダイジェストごとに不変 — パブリッシャーは `Cache-Control: public, max-age=31536000, immutable` でサーブし ≥99.9% / 30 日可用性を目標とすべき（SHOULD）。SDK は `uri@digest` で積極的にキャッシュ。ヒットは常に正しい。404 または解決失敗時、バイヤーは優雅に劣化しなければならない（MUST）（利用不可として扱い、プラットフォーム固有絞り込みをスキップ、バイを失敗させない）。

*クローズドプラットフォームパス（AAO 翻訳）*。ウォールドガーデン（Meta、Google、Amazon、TikTok、Snap、Pinterest）に使う。これらのプラットフォームは自身のサブドメインで AdCP 形状拡張アーティファクトをホストする可能性が低い（収益モデルを保護するネイティブ SDK と API を持つ。不変拡張 CDN をサーブしても彼らに利益がない）。代わりに、AAO はクローズドプラットフォームフォーマットドキュメントを AdCP 拡張アーティファクトにマップし、AAO ミラー名前空間の下でホストする翻訳者を実行（例: `https://creative.adcontextprotocol.org/translated/<platform>/<artifact>@<digest>`）。このリポジトリの `https://creative.adcontextprotocol.org/translated/meta/extensions/...` を参照する実例フィクスチャは説明的 — それらの拡張の本番使用は Meta が直接参加するまで/しない限り AAO ミラー経由で解決すべき。AAO は同じダイジェストピン留め + 不変性コントラクトにコミット。リフレッシュ頻度と翻訳方法論は `https://adcontextprotocol.org/registry/translated-extensions` で文書化。バイヤーは両パス全体で同一にキャッシュし解決 — `uri@digest` がキャッシュキー、誰がホストするかにかかわらず。

2 つのパスはダイジェストピン留めキャッシュと優雅劣化セマンティクスを共有。解決権威のみが異なる。ミラーはクローズドプラットフォーム拡張に規範的（「ベストエフォート」でない）、なぜなら他のパスがないから。オープンエコシステム拡張には、ミラーはオプトインフォールバック。

**配布パス: `get_products` でバンドル。** セールスエージェントのレスポンスは、レスポンス内の任意の製品が参照するすべての拡張の定義を `uri@digest` でキーして含む:

```json test=false theme={null}
{
  "products": [ { "...": "..." } ],
  "extensions": {
    "https://creative.adcontextprotocol.org/translated/meta/extensions/meta_pixel@sha256:a3f5...": {
      "extends": "tracking",
      "fields": {
        "pixel_id": { "type": "string", "required": true },
        "conversion_event": { "type": "string", "enum": ["PURCHASE", "LEAD"] }
      },
      "version": "2.1.0"
    }
  }
}
```

バイヤーの SDK は URI\@digest でキャッシュ。後続の `get_products` レスポンスは、バイヤーが拡張をキャッシュ済みなら digest だけで参照できる。直接 URI フェッチはツールのためサポートされるが、主要パスはバンドル済み `get_products`。

## デュアル発行と v2↔v1 投影（規範的）

製品は移行ウィンドウ中に `format_ids`（v1）と `format_options`（v2）の両方を運べます（MAY）。両方が出荷されるとき、2 つは同じ基盤フォーマット宣言を参照しなければならない（MUST） — 分岐する形状はコントラクト違反。

### プロデューサールール

* 単一のソースから両方の形状を導出する SDK は不変条件を保証。手作成製品は合意のためレビューされなければならない（MUST）。
* 合意を保証できないプロデューサーは 1 つの形状のみを発行しなければならない（MUST）。
* `format_kind: "custom"` 宣言には、プロデューサーは `canonical_formats_only: true` を設定しなければならず（MUST）、v1 `format_id` を合成してはならない（MUST NOT）。プロトコルは合成 format\_id を作らない（`aao-synth/*` 名前空間が検討され拒否された — アダプターが安定したアイデンティティのない識別子でインデックスする）。
* 正準/パラメーター形状にクリーンな v1 名前付きフォーマット同等物がない `format_options` 宣言（例: `v1-canonical-mapping.json` になく任意の v1 ファイルで宣言されていない構造形状）には、プロデューサーは 2 つの形状の 1 つだけを黙って発行するのではなく `canonical_formats_only: true` を設定すべき（SHOULD）。

### 消費者ルール（v1→v2）

v1 パスで製品を読むとき、SDK は `v1-canonical-mapping.json` の解決順を使って `format_ids` を `format_options` に投影:

1. **権威的 v2 → v1 リンク**: 同じ製品の任意の v2 `ProductFormatDeclaration` がこの v1 `format_id` を指す `v1_format_ref` を運ぶ場合、その v2 宣言を直接使う。最高優先度 — セラーがリンクを主張。
2. **v1 ファイルでセラー主張**: v1 フォーマット宣言の明示的 `canonical` フィールド。
3. **レジストリ glob**: `format_id_glob` マッチ。
4. **構造マッチ**: レジストリ構造形状マッチ。
5. **フェイルクローズ**: SDK は `format_options` エントリーを合成してはならない（MUST NOT）。SDK はレスポンスの `errors[]` 配列に `source: "sdk"`、`sdk_id`、`code: FORMAT_PROJECTION_FAILED`、フィールド+詳細を運ぶエントリーを追加しなければならない（MUST）（error-code.json を参照）。単一の義務付けられた表面 — lint 出力チャネルは受け入れられない。マルチホップエージェントネットワークは警告がワイヤーレスポンス経由で SDK 境界を越えて伝播することを必要とする。助言は非致命的: レスポンスは 200/成功のまま、製品は v1 パスで依然として有効、v2 `format_options` 投影のみが不在。

### 消費者ルール（分岐検出）

製品が `format_ids` と `format_options` の両方を運び 2 つが不一致（異なる正準、異なる寸法、異なる orientation など）のとき:

* SDK はこれをプロデューサーコントラクト違反として扱わなければならない（MUST）。
* SDK は `format_options` を優先しなければならず（MUST）（正準フォーマットがよりリッチな表面）、`source: "sdk"`、`sdk_id`、`code: FORMAT_DECLARATION_DIVERGENT` 付き `errors[]` 追加経由で分岐製品を表示しなければならない（MUST）。単一の義務付けられた表面 — lint 出力チャネルは受け入れられない。`get_products` レスポンス全体をハード失敗させることは推奨されない — プロデューサーのバグで下流バイヤーを罰する。
* SDK は分岐を呼び出しエージェントに表示せずに 1 つの形状を黙って選び他を破棄してはならない（MUST NOT）。

スキーマは合意を強制できない（「`format_ids[i]` の v1 マップ形式は `format_options[j]` に等しくなければならない」を表現するクロスフィールド制約がない）。消費者側検出が唯一の防御線。SDK 適合性スイートは分岐フィクスチャを含むべき（SHOULD）。

### 「絞る」 — 形式的定義（規範的）

仕様が v2 `format_options` エントリーが同じ製品の v1 `format_ids` エントリーと同じ基盤宣言を参照しなければならない（MUST）（デュアル発行不変条件）と言うとき、または SDK が作成された v2 宣言をレジストリ投影されたものと比較して分岐を検出するとき、比較はこの定義に従わなければならない（MUST）:

**v2.params がレジストリ拡張後に v1 投影ベースラインを *絞る***のは、v2.params に存在するすべてのパラメーターが構造的に同等 v1 要件のサブセットのとき。具体的には:

* **スカラー制約**: v2 スカラー値が v1 範囲内に含まれるとき、v2 スカラー値は v1 範囲を `絞る`。`v2.width: 300` は `v1.width_range: [200, 400]` を絞る。`v2.duration_ms_exact: 30000` は `v1.min_duration_ms: 3000` を絞る。
* **Enum 制約**: v2.enum\_value は v1.allowed\_values に現れれば（または v1.allowed\_values が不在 — オープン enum）`絞り込み`。`v2.image_formats: ["jpg", "png"]` は `v1.image_formats: ["jpg", "png", "gif", "webp"]` を絞る。
* **範囲制約**: v2.range は v2 の下限 ≥ v1 の下限 かつ v2 の上限 ≤ v1 の上限のとき v1.range を絞る。`v2.duration_ms_range: [5000, 30000]` は `v1.duration_ms_range: [3000, 90000]` を絞る。
* **不在の v2 パラメーター**: v2.params が v1 が指定したパラメーターを省略するとき、v2 は v1 の値を継承（絞り込み制約は追加されない）。プロデューサーは v1 デフォルトを再述するのではなく省略すべき（SHOULD）。
* **非対称絞り込み**: v1 がパラメーターについて何も言わず v2 が 1 つを指定するとき（例: v1 に `image_formats` 制約なし、v2 が `image_formats: ["jpg"]` を宣言）、v2 は暗黙の「任意の値」v1 ベースラインに対して `絞り込み`。これは期待される v2-tightens-v1 パターン。
* **コンフリクト**: 対応する v1 制約外に落ちる任意の v2 パラメーター値は *コンフリクト* で、絞り込みではない。SDK はデュアル発行形状間のコンフリクトを分岐として扱い `FORMAT_DECLARATION_DIVERGENT` 経由で表示しなければならない（MUST）。

絞る関係は一方向: v2 が v1 を絞る（v2 がより厳格な形状）。逆（v1 が v2 を絞る）はデュアル発行コントラクトがチェックされる方法では **ない**。

絞り込みチェックを実装する SDK 作者は、上のルールに従いパラメーターごとの包摂を適用すべき（SHOULD）。エッジケース（複合パラメーター、platform\_extensions、スロット語彙変更）はまだ未仕様。SDK は 3.1 でそれらを「不明 — pass」として扱い構造化警告を表示してもよく（MAY）、ワーキンググループが 3.x を通じてアダプターフィードバックに従いそれらを引き締める。

### `canonical:` アノテーション経由の v1 → v2 投影（オブジェクト形状）

v1 カタログの `canonical:` アノテーションは文字列ではなく OBJECT です。最小形式は正準 kind だけを運ぶ。リッチ形式は、形状が正準のデフォルトに従わない v1 エントリーのため `asset_source` と `slots_override` を追加。

**なぜオブジェクトか。** 素の文字列アノテーション `canonical: "image"` は暗黙的に正準のデフォルトスロットセット（`image_main: image, required`）とデフォルト asset\_source（`buyer_uploaded`）を運ぶ。それらのデフォルトに従う v1 エントリー — 300×250 画像アップロード — にはそれが正しい。従わない v1 エントリー（生成、ブリーフ駆動、ホスト録音）には、素のアノテーションはロッシー: 素の `canonical: "image"` で `display_300x250_generative` を投影する SDK は buyer-uploaded 画像バイトを主張する v2 宣言を生成するが、v1 エントリーは実際には `generation_prompt: text` 入力を望む。投影を読む v2 対応バイヤーは誤ルーティング。オブジェクト形式がこれを修正。

**2 つのケース。** デフォルトスロットケース（ほとんどの v1 エントリー）:

```json theme={null}
"canonical": { "kind": "image" }
```

オーバーライドケース（生成エントリー、ブリーフ駆動ホストリード、v1 アセット形状が正準のデフォルトでないもの）:

```json theme={null}
"canonical": {
  "kind": "image",
  "asset_source": "agent_synthesized",
  "slots_override": [
    { "asset_group_id": "generation_prompt", "asset_type": "text", "required": true }
  ]
}
```

**投影ルール**（`canonical-projection-ref.json` に従い）:

1. `kind` → 投影された v2 ProductFormatDeclaration の `format_kind`。
2. `asset_source`（設定されていれば） → `params.asset_source`。不在なら、投影は正準のデフォルト（通常 `buyer_uploaded`）を使う。
3. `slots_override`（設定されていれば）投影された宣言の正準のデフォルト `slots[]` を REPLACE。不在なら、投影は正準のデフォルトを継承。
4. v1 エントリーの `requirements`（寸法、期間、コーデック） → 正準のパラメータースキーマに従う `params` フィールド。
5. v1 エントリーの `assets[*]` は結果の `slots[]` と一貫していなければならない（MUST） — `asset_id` ↔ `asset_group_id`（asset-group-vocabulary がエイリアスを解決）。

**カタログの生成フォーマット。** 8 つの `display_*_generative` エントリーは `asset_source: agent_synthesized` と `generation_prompt: text` スロットオーバーライドを持つリッチ形式を運ぶ。これらを投影する v2 対応バイヤーは「これは 300×250 画像フォーマットで、エージェント合成で生成され、バイヤーが入力としてテキストプロンプトを出荷する」と正しく言う v2 宣言を得る。画像バイトを持つバイヤーはそのコントラクトを満たせない。生成プロンプトを持つバイヤーは満たせる。同じ正準 kind（`image`）が両方をサポート、なぜなら `asset_source` + `slots_override` が生成モデルで判別するから。

**「セラーはどう『生成をしない』と言うか?」** 彼らは既に — デフォルトスロットで `format_kind: image` を宣言することで（`asset_source` オーバーライドなし）。正準の必須 `image_main: image` スロットが生成バイヤーを自動的に除外。生成に OPT INTO するには、セラーは製品の format\_options エントリーで `asset_source: agent_synthesized` を宣言し `slots[]` をオーバーライド。デフォルト動作は保守的なもの。

### `v1_format_ref` 経由の v2 → v1 リンク

セラーが同じ基盤製品/在庫の公開された v1 名前付きフォーマット AND v2 宣言の両方を持つとき、v2 宣言は 1 つ以上の v1 識別子にリンクバックする `v1_format_ref: [{ agent_url, id }]`（常に配列）を運ぶ。v2 宣言が形状の真実の源泉。v1 フォーマットファイルは純粋な v1 形状のまま — ミラーされた宣言なし。

#### マルチサイズファンアウト（規範的）

N エントリーの `params.sizes: [{w,h}, ...]` を持つマルチサイズ v2 宣言は、サイズごとに 1 つの `v1_format_ref[]` エントリー — N サイズをカバーする N v1 名前付きフォーマット — を運ぶべき（SHOULD）。v1 のみのバイヤーは次にデュアル発行された `format_ids[]` 経由ですべてのサイズで製品を見る。

セラーがサイズより少ない参照を主張するとき（`v1_format_ref[].length < sizes[].length`）、2 つのケース:

* **SDK はファンアウトしない（デフォルト規範的動作）。** セラー主張の参照のみを運ぶ `format_ids[]` を発行（サイズ損失は実だが境界される）。v1 対応下流エージェントがどのカバレッジが失われたか見られるよう、`error.details: { product_id, declared_sizes, covered_sizes, dropped_sizes }` 付きレスポンス `errors[]` に `FORMAT_DECLARATION_V1_LOSSY_MULTI_SIZE` も発行しなければならない（MUST）。ロッシー発行は **保守的なワイヤー形状** — セラーが主張した正確なもの、合成なし。
* **SDK はファンアウトする（MAY-do、非規範的）。** 対応する `v1_format_ref` を欠く `sizes[]` の各エントリーについて、SDK は AAO カタログを参照しサイズごと v1 名前付きフォーマットをルックアップしてもよい（MAY）（例: `{width: 728, height: 90}` → `display_728x90_image`）。ルックアップが成功するとき、SDK はセラー主張参照と並んでカタログ解決参照を `format_ids[]` の下で発行してもよい（MAY）。ファンアウトする SDK は、下流消費者がどの `format_ids[]` エントリーがセラー主張対カタログ解決かを知るよう透明性助言として `FORMAT_DECLARATION_V1_LOSSY_MULTI_SIZE` を依然として発行しなければならない（MUST）。助言の `error.details` は `synthesized_refs: [<list of catalog-resolved ids>]` を含むべき（SHOULD）。

**なぜ MAY-do で MUST-do でも MUST-NOT-do でもないか。** カタログアクセスのない SDK はファンアウトできない。MUST にすることは SDK 機能依存を作る。MUST-NOT にすることは実価値を破棄（3 つの IAB サイズすべてを持つカタログはマルチサイズ宣言をロスレスに拡張できる）。必須助言付き MAY-do は SDK の選択を保持しつつワイヤー形状を透明に保つ — 下流消費者は助言の `synthesized_refs` 経由で常に合成参照をセラー主張から区別できる。

**SDK 間収束ルール。** 同じ入力を処理する 2 つの SDK は異なる `format_ids[]` を生成してもよい（MAY）（一方はファンアウト、一方はしない）が、両方とも一貫した `declared_sizes` / `covered_sizes` / `dropped_sizes` で `FORMAT_DECLARATION_V1_LOSSY_MULTI_SIZE` を発行しなければならない（MUST）。レスポンスストリームを読むバイヤーエージェントは分岐する `format_ids[]` を助言に対して照合できる。

```json test=false theme={null}
{
  "format_kind": "custom",
  "format_shape": "multi_placement_takeover",
  "format_schema": { "uri": "https://nytimes.example/schemas/formats/homepage_takeover_v3", "digest": "sha256:..." },
  "v1_format_ref": [{ "agent_url": "https://nytimes.example", "id": "homepage_takeover" }],
  "params": { ... }
}
```

これは v1 `format.json` ファイルの以前の `canonical_parameters` フィールド（3.1 で非推奨、4.0 で削除）を置き換えます。v2 → v1 からの方向リンクは、並行形状ドリフト表面なしで同じ事実を捕捉 — v1 ファイルはもう v2 形状をミラーしない。

`v1_format_ref` は `canonical_formats_only: true` と相互排他的 — 宣言は v1 の居場所を持つ（`v1_format_ref` 経由でリンク）か持たない（`canonical_formats_only: true` 経由で主張）かのいずれか。`format_kind: "custom"` 宣言には、2 つのうちちょうど 1 つが設定されなければならない（MUST）。

### ワイヤー上の v2 のみ宣言

v1 ワイヤーパスで製品を読むバイヤーは、`format_ids` から不在の `canonical_formats_only: true` を持つ `format_options` エントリーを見ます。これは意図的でプロデューサーエラーではない。`format_options` を読む v2 対応バイヤーはそれらを見る。v1 のみのバイヤーは、同じ製品に対して v2 対応バイヤーが `format_options` で見るより少ないオプションを `format_ids` で見る — v1 表面はこれらの製品で v1 サンセット（5.0）まで厳格なサブセット。

### v1 バイヤーに発行する v2 ネイティブセラー

製品が既存の v1 名前付きフォーマットを運ばない v2 ネイティブセラー（例: 正準フォーマットが安定した後に登場し `format_options` のみを作成したセラー）には、v1 のみのバイヤーのため `format_ids` に何を入れるかの質問は 2 つの許容可能な答えを持つ:

1. **デフォルト — `canonical_formats_only: true` を設定、`format_ids` から省略。** v1 バイヤーはこれらの宣言の `format_ids` エントリーを見ない。製品は v1 のみのバイヤーに機能的に不可視だが、v1 表面はクリーンなまま（合成識別子がバイヤー側 allowlist を汚染しない）。
2. **セラースコープ ID を合成。** セラーが v1 のみのバイヤーリーチを望むとき、`<seller_domain>/canonical_<format_kind>_<param_summary>` のような `format_ids` を作ってもよい（MAY）（例: `acme.example/canonical_image_300x250`）。合成時:
   * ID はセラースコープ（セラー自身の `agent_url` の下）でなければならず（MUST）、決して `aao-synth/*` や任意のクロスセラー名前空間の下でない — AAO ミラースタイル合成名前空間が検討され拒否された、なぜならアダプターが安定したアイデンティティのない識別子でインデックスするから。
   * ID はセラーの公開されたフォーマットカタログ（adcp-resource マニフェストが参照する静的フォーマットファイル、`list_creative_formats` が読むのと同じ場所）で宣言されなければならない（MUST）ので、v1 バイヤーは `Product.format_ids` とセラーのフォーマットディレクトリの間で一貫した識別子を見る。
   * `format_kind_<param_summary>` 規約は推奨で規範的要件ではない — セラーは自身の `agent_url` 名前空間にスコープされた任意の命名規約を使ってもよい（MAY）。バイヤーはルーティングのため規約にパターンマッチしてはならない（MUST NOT）（セラーのカタログが権威的）。
   * 合成 `format_ids` エントリーと対応する `format_options` エントリーは、他の任意のデュアル発行製品と同じデュアル発行絞り込みコントラクトを満たさなければならない（MUST）（上の投影ルールを参照）。

セラーはデフォルトとしてオプション (1) を選び、保持する具体的な v1 バイヤー関係があるときのみ (2) にオプトインすべき（SHOULD）。オプション (2) はカタログ同期負担を無期限に運ぶ。オプション (1) はクリーンな表面のコストとしてより薄い v1 リーチを受け入れる。

## v2 に何がないか

設計上、v2 は AdCP が既に処理するか別の場所に属するもののため新しい語彙を導入しません:

* **ブランドセーフティ語彙** — それはメディアバイ/キャンペーンレベル（`creative-policy.json` とより広範なキャンペーン設定）で、クリエイティブフォーマットレベルではない。フォーマット宣言はブランドセーフティを再宣言しない。
* **新しいスキーマとしてのユニバーサルマクロ** — 既に [`/docs/creative/universal-macros`](/docs/creative/universal-macros) で文書化。正準フォーマットは名前でそれらを参照。
* **新しいスキーマとしての `destination_kinds`** — `url-asset.json` は既に URL kind 曖昧性解消をカバーする `url_type` を持つ。プラットフォーム固有デスティネーション（Meta `messenger_thread` など）はプラットフォーム拡張。
* **正準パターンとしての `cta_vocabulary`** — CTA は表面全体で意味あるほど変わる。クロスプラットフォーム需要が出るまで製品に `cta_values` 配列をインラインで宣言させる。
* **別のツールとしての `list_build_capabilities`** — `creative.supported_formats` の下で `get_adcp_capabilities` に折りたたまれる。
* **別のビルド時フォーマットオプションフィールドと `inputs` マップ** — フォーマット宣言の正準 `slots` モデルに崩される。フォーマットがスロット（正準 `asset_group_id` + `asset_type` + 制約）を宣言。マニフェストはスロット名でキーされた単一の `assets` マップを持つ。セラーはフォーマットごとにディスパッチ（アセットをそのままレンダーまたは生成のため消費）。フォーマット自体がバイヤーに何を要求するかを伝える。生成がどう起こるかは実装詳細。

### 兄弟絞り込みでカバーされるチャネル（新しい正準なし）

12 の正準はディスプレイ、動画、オーディオ、ネイティブ in-feed、リテールメディア、AI 表面、レスポンシブクリエイティブアーキタイプをカバー。いくつかのチャネルは自身の正準を望むように見えるが望まない — それらは **兄弟絞り込み** でカバーされる: 同じ正準の `asset_source`、`slots_override`、`applies_to_channels` 軸が違いを処理。

* **リニア / アドレッサブル TV** — `video_hosted` + `applies_to_channels: ["tv"]`。アセットは依然としてサイズ/コーデック/期間制約を持つ動画ファイル。GRP/スポットトランザクションモデルとアドレッサブル世帯ターゲティングはメディアバイ + 測定の関心事で、クリエイティブフォーマットの関心事ではない。
* **OOH / DOOH** — `image`（または `video_hosted`）+ `applies_to_channels: ["dooh"]`。アセットは依然としてサイズ制約を持つ静止画像（または短い動画）。位置キー測定（Geopath、COMMB）はフォーマットではなく `sync_event_sources` / `event_log` に属す。
* **プロンプトから生成** — バイヤーアップロード同等物（image、video\_hosted、audio\_hosted）と同じ `format_kind` + `asset_source: agent_synthesized` + 入力形状を宣言する `slots_override`（`generation_prompt: text`、`creative_brief: brief`、`video_brief: object`）。v2 対応バイヤーは「このフォーマットは画像バイトではなくテキストプロンプトまたは構造化ブリーフを望む」を見る。
* **動画ネイティブ** — `video_hosted` + `applies_to_channels: ["native"]`。アセットは依然としてホスト動画ファイル。違いはレンダラープレースメント（in-feed）でチャネル軸で捕捉。（非動画 in-feed ネイティブユニット — レンダラーが組み立てる title + image + body — には、意味あるほど異なる組み立て形状を持つ専用 `native_in_feed` 正準を使う。）

自身の正準を **必要とする** チャネル（真に異なる形状、延期）:

* **オーディオダイナミック広告挿入（DAI）** — ミッドストリーム挿入を伴う広告ステッチオーディオは `audio_hosted` や `audio_daast` と異なるトラッキング形状を持つ。パターンが安定するとき専門正準または `audio_daast` 拡張パラメーターの可能性。
* **In-game** — プレイアブル / in-game 広告は SDK 固有の合成モデルを持つ。クロスエンジン標準が到達するまで範囲外。
* **ライブストリーミング** — ライブリニア動画（Twitch / YouTube Live / mid-roll を伴うスポーツストリーミング）は並行インプレッションとストリーム状態トラッキングを必要とする。`video_vast` 正準は今日 VAST タグ駆動ライブ挿入を処理。よりリッチなライブパターンは延期。

**経験則（「正準増殖前の兄弟絞り込み」原則）。** 新しい正準に手を伸ばす前に、違いが (a) 生成モデル — `asset_source` でカバー、(b) スロット形状 — `slots_override` でカバー、(c) チャネル — `applies_to_channels` でカバー、(d) 測定 / トラッキング — `sync_event_sources` / `event_log` でカバー、のいずれかにあるかチェック。クリエイティブアセット自体が構造的に異なるときのみ新しい正準（例: DAI の広告ステッチ連続オーディオストリームは `audio_hosted` のインプレッションごとファイルと構造的に異なる）。v1 カタログの 50/50 広告フォーマットが今このパターン経由で正準に投影される。放送 / DOOH / ネイティブ / 生成のためにゼロの新しい正準が追加された。

### 生成 DSP とマルチ出力パターンは前方指向

`asset_source` enum（`seller_pre_rendered_from_brief` と `agent_synthesized` を含む）と `sponsored_placement` の `item_production_model` は、出現しつつあるが 2026 年にプログラマティック支出の大きなシェアではない生成 DSP と AI レンダーリテールメディアパターンのために設計されています。Universalads 形状ツール、Pencil、AdCreative.ai、GenStudio 形状ツール — これらは実際のアダプターだが、ボリュームは退屈な 90%（バイヤーが MREC PNG を出荷。表面がそれをサーブ）に比べて小さい。スキーマの幅に読み込みすぎることは間違い。フィールドは生成 DSP アダプターがクリーンな v2 の居場所を持つよう存在。実例はアダプターがそのアダプターをクリーンにマップできるようそれらを含む。それらは v2 ナラティブが AI ファーストというシグナルではない。3.1 の支配的フローは依然として決定的表面を通るバイヤーアップロードアセット。

### クリエイティブエージェントビジネスモデル

サードパーティクリエイティブエージェント実例は、Flashtalking 形状ツールが `build_creative` 経由でバイヤーにサーブしバイヤーに生成されたマニフェストをセラーに出荷させることを仮定。これを読むオペレーターは、v2 がクリエイティブエージェントからホスティング / サービング / トラッキング収益を剥がすと推論すべきでない。生成は `build_creative` で起こる。生成されたマニフェストはクリエイティブエージェントの CDN のホストアセット URL（例では Flashtalking ホストアセット URL）を含められ、プラットフォーム拡張はセラーがサーブ時に尊重するクリエイティブエージェント固有トラッキング（Flashtalking ピクセル ID、ビューアビリティベンダー構成）を添付できる。v2 分解は概念的（仕様は生成をサービングからトラッキングから分離） — 運用統合パスはクリエイティブエージェントが生成したクリエイティブをホストしインストルメントし続けさせる。v2 はアセットバイトがどこに存在するか誰のトラッキング JS が動くかを指示しない。既に暗黙に存在する生成対サービング境界を形式化するだけ。

## コード生成対ランタイム: 検証者がゲート

`product-format-declaration.json` は、`format_kind === "custom"` のときのみ条件付きで `format_shape`、`format_schema`、`canonical_formats_only` を要求する `allOf/if/then/else` を運ぶ。同じパターンが条件付き `violations` を持つ `validate-input-result.json` の `result_kind` 判別子に適用。JSON Schema はこれらの条件をきれいに捕捉するが、ほとんどのコード生成パイプライン（`json-schema-to-typescript`、`datamodel-codegen`）は、条件付き絞り込みが TypeScript の構造型システムや Pydantic のクラスモデルにマップしないため、型を発行する前に `if/then/else` を剥がす。生成された型はしたがってスキーマより厳密に許容的:

* 生成された TS / Python 型は `format_shape` または `format_schema` を省略する `format_kind: "custom"` 宣言を受け入れる — 型システムは判別子で絞り条件付きフィールドを要求する方法を持たない。
* Ajv（または同等）ランタイム検証者がゲート。SDK はワイヤーから解析された `ProductFormatDeclaration` を信頼する前に JSON Schema 検証者を実行しなければならない（MUST）。コード生成された型は便宜層で、コントラクトではない。
* TypeScript で v2 を書くバイヤーエージェント作者は、生成された型を出発点として扱い自身のランタイム検証ステップを追加すべき（SHOULD） — アダプターが任意の JSON-Schema 検証 API に既に使うのと同じパターン。ランタイム検証をスキップするアダプターは、スキーマが拒否する宣言で型システム成功を得て、厳格な下流検証者にヒットするときのみギャップを発見する。

これは doc 懸念で、スキーマ懸念ではない。スキーマはコード生成された型より厳格。ランタイム検証がギャップを閉じる。

## 移行

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

**v1 はファーストクラスのまま。** v1 名前付きフォーマットはサポートされたまま。セラーは v2 製品フォーマット宣言から v1 `list_creative_formats` 形状を導出するサーバー側フラット化ラッパーを 4.0 を通じて提供すべき（SHOULD）。v2 は *新しい* パスで、唯一のパスではない。

### 現実的な 3.1 カバレッジ

`v1-canonical-mapping.json` は 3.1 で約 15 の曖昧でないエントリー（IAB ディスプレイサイズ、VAST 4.x、DAAST 1.x）で出荷。完全な v1 監査は 12 プラットフォーム全体で 86 フォーマットをカタログ化。そのうち約 76%（≈65 フォーマット）は既存正準に構造的に適合するが、**(a) セラーが自身の v1 フォーマットファイルに明示的な `canonical` フィールドを追加するか、(b) 誰かが `format_id_glob` または構造マッチを追加するレジストリ PR を提出するときのみ自動的に投影する。** 3.1 の最初、監査されたフォーマットの 71+ が v1 のみ — サポートを失わないが、v2 のみのバイヤーエージェントは、セラーまたは AAO コントリビューターがギャップを閉じるまで `format_options` でそれらを見ない。3.x を通じて、ほとんどの製品トラフィックはアーリーアダプターセラー（Meta、NYTimes、AudioStack、生成 DSP、リテールメディア）からのオプトイン `format_options` で v1 ワイヤー形状のままと期待。3.x で v2 のみ消費を計画するバイヤーエージェントは v1 対応エージェントより意味あるほど薄い在庫を見る。少なくとも 3.3 を通じてコードパスをデュアル読み取りとして計画することが現実的。v1 の 5.0 サンセットはデュアル発行のフロアで、期待される切り替え日ではない — v2 のみを計画する誰もがそれを最速で 4.x に書き入れるべき。

## フェーズステータス

| Phase   | Status       | What's in it                                                                                                                                                                                                                                                                                                                                                     |
| ------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Phase 1 | ✅ in #3307   | `asset_group_id` 語彙レジストリ（正準エントリー + 監査に基づくエイリアス）、`video_brief` スキーマ（以前の `scenes` からリネーム）、`zip` アセットタイプ、video/audio ドキュメント修正                                                                                                                                                                                                                                       |
| Phase 2 | ✅ in #3307   | 構造化 `slots` 宣言を持つ 12 正準フォーマット定義、`ProductFormatDeclaration`（format\_kind 判別子 + params）、`validate_input` プリミティブ、get\_adcp\_capabilities の `creative.supported_formats`、`BrandRef` 上の `brand_kit_override` インライン、`platform-extension-ref`、型付きインライン `product_card` / `product_card_detailed`、Product の `format_ids` + `format_options` `anyOf`（#3765 に従い移行中デュアル発行合法） |
| Phase 3 | ✅ in #3307   | v1↔canonical-formats 移行ガイド、12 の完全に検証されたリファレンス Product フィクスチャ + バンドル拡張を伴う 1 get\_products レスポンスフィクスチャ、フィクスチャ検証テストスイート（`npm run test:canonical-fixtures`）                                                                                                                                                                                                          |
| Phase 4 | ✅ 3.1 GA で出荷 | リファレンス SDK コード生成（TypeScript 最初、次に Python）、サーバー側フラット化ラッパーリファレンス実装、platform\_extensions URI+ダイジェスト fetch+cache ヘルパー、`production_window_business_days` と他のスロットレベルスケジューリングヒントのファーストクラス型付きアクセサー。これらは、生成された SDK から正準フォーマットを使用可能にし v1↔v2 移行人間工学を保つアダプター消費部分。                                                                                                            |

## 経験的投影カバレッジ

`creative.adcontextprotocol.org` の AAO カタログ（`server/src/creative-agent/reference-formats.json` の公開された v1 フォーマットライブラリ）は、**57 エントリーのうち 33**（58%）が `canonical: <format_kind>` でアノテーションされている — 直接 v1→v2 投影、SDK 推測なし。残りの 24 は、カバレッジ不足ではなく仕様が明示的な意図的ギャップに入る:

**最終 3.1 カバレッジ: v1 カタログの 50/50 広告フォーマットがアノテーションされている**、投影参照オブジェクト形式（`canonical: { kind, asset_source?, slots_override? }`）経由。プラス、広告フォーマットではないため `server/src/creative-agent/ui-element-formats.json` に分割された 7 UI スキャフォールディングカードエントリー（`product_card_*`、`format_card_*`、`proposal_card_*`、`native_product_card`） — それらは広告正準に決して投影しないエージェントインターフェース表示ウィジェット。

以前アノテーションされていなかった各グループがどう着地したか:

* **8 生成エントリー**（`display_generative`、`display_300x250_generative`、`display_728x90_generative`、`display_320x50_generative`、`display_160x600_generative`、`display_336x280_generative`、`display_300x600_generative`、`display_970x250_generative`） — `{ kind: "image", asset_source: "agent_synthesized", slots_override: [{ generation_prompt: text, required }] }` としてアノテーション。投影する v2 対応バイヤーは「このフォーマットは画像バイトではなくテキストプロンプトを望む」を見る。`asset_source` + `slots_override` の兄弟絞り込み。`image_generative` 正準は不要。
* **3 放送**（`broadcast_spot_15s/30s/60s`） — `{ kind: "video_hosted" }`。セラーは v2 製品の `applies_to_channels: ["tv"]` 経由で絞る。同じアセット形状（動画ファイル + 期間 + コーデック）。
* **4 DOOH**（`dooh_billboard_*`、`dooh_transit_screen`） — `{ kind: "image" }`。セラーは `applies_to_channels: ["dooh"]` 経由で絞る。位置キー測定の違いはフォーマットではなく `sync_event_sources` に存在。
* **2 ネイティブ**（`native_standard`、`native_content`） — ネイティブ固有スロット（icon、disclosure、sponsored\_by）を持つ `{ kind: "image", asset_source: "buyer_uploaded", slots_override: [...] }`。

SDK 側の v1→v2 投影（[adcp-client #1815](https://github.com/adcontextprotocol/adcp-client/pull/1815) で検証）は 50 すべて全体でクリーンに投影。v2→v1 の同じアーキテクチャ対称性: クリーンな投影プラス、仕様が v1 形式を持たないと明示的な正準の `v1_translatable: false` / `canonical_formats_only: true` 経由の正直なフェイルクローズ。

**「新しい正準なし」パターン（将来の貢献に規範的）。** 生成、放送、DOOH、ネイティブはすべて新しい正準を望むように見えた。どれも得なかった。パターン: `asset_source` + `slots_override` + `applies_to_channels` 経由で既存正準を絞り、測定/トラッキングの違いを `sync_event_sources` / `event_log` にルーティングし、クリエイティブアセット自体が構造的に異なるときのみ新しい正準を作る（それは稀）。「セラーはどう『生成をしない』と言うか?」の質問はこの原則で解決 — 自動、デフォルト `asset_source: buyer_uploaded` と必須 `image_main: image` スロット経由。

## 関連

* [S2 クリエイティブスペシャリストモジュール](/docs/learning/specialist/creative) — 製品 `format_options[]` を読み、`format_kind` を選択し、`asset_source` をマップするトレーニングラボ
* [v1 → canonical-formats 移行ガイド](/docs/creative/canonical-formats-migration) — セラー、クリエイティブエージェント、バイヤー、パブリッシャーダイレクト統合の具体的な移行パス
* [RFC #3305](https://github.com/adcontextprotocol/adcp/issues/3305) — v2 アーキテクチャ決定と根拠
* [PR #3307](https://github.com/adcontextprotocol/adcp/pull/3307) — Phase 1 + Phase 2 実装
* [アセットグループ語彙](https://adcontextprotocol.org/schemas/v3/core/asset-group-vocabulary.json) — 正準スロット名レジストリ
* [Video Brief スキーマ](https://adcontextprotocol.org/schemas/v3/creative/video-brief.json) — build\_creative のためのセグメントごと型付き生成ブリーフ（以前の `scenes` からリネーム）
* [ユニバーサルマクロ](/docs/creative/universal-macros) — 正準トラッキングから参照される置換パターン
