> ## 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 の新機能
> AdCP 3.1 の採用者向け概要 — 分散型 brand.json、依存関係影響 webhook、ホールセールフィードミラーリング、リリース精度バージョンネゴシエーション、ブランドレスポンス署名、正準クリエイティブフォーマット、ベンダー証明測定、アクションディスカバリーなど。3.0 に対して加算的。安定リリースにはワイヤーピン 3.1 を使う。
**ステータス: 3.1 はリリース済み。** 現在の安定マイナー: 3.1、ワイヤーピン `adcp_version: "3.1"`。3.0 ラインは `"3.0"` にピン留めされた既存の統合のためにサポートされたままです。
AdCP 3.1 はマイナーリリースです。すべての 3.1 変更は 3.0 に対して **加算的** です: 新しいフィールドは任意で、必須フィールドは削除されず、3.0 準拠クライアントを壊す方法で形状が変わったものはありません。**3.0 準拠エージェントに破壊的変更なし。** 3.1 を採用するには、エージェントが `supported_versions` でその値をアドバタイズすることを確認した後、本番トラフィックを `"3.1"` にピン留めしてください。実装準備には [3.0 から 3.1 への移行ガイド](/docs/reference/migration/3-0-to-3-1) を使ってください。
このページは 3.1 マイナーリリースのキュレーションされた採用者概要です。完全な 3.1 変更リスト、PR ごとの詳細、移行表が必要ですか？ 権威あるバージョン記録の [リリースノート § Version 3.1.0](/docs/reference/release-notes#version-3-1-0) と、ロールベースのアップグレードチェックリストの [3.0 から 3.1 への移行](/docs/reference/migration/3-0-to-3-1) を使ってください。長文の規範的リファレンスについては、下の各見出しのリンクをたどってください。
**代わりにメジャーな v2 → v3 の変更を探していますか？** [What's New in AdCP 3](/docs/reference/whats-new-in-v3) を参照。このページは 3.0 → 3.1 のマイナー差分のみをカバーします。
## 最終的な 3.1 機能セット
安定した 3.1 形状のみが必要なら、まずこのリストを読んでください:
* **バージョニングと検証。** リリース精度の `adcp_version` ピン、安定ワイヤー値 `"3.1"`、`supported_versions` アドバタイズ、エンベロープエコー、バージョンスコープの検証バッジ。
* **ブランド信頼。** 分散型 `brand.json`、`brand_refs[]` を通じたサブブランドの自己公開、型付きブランド制約、認可されたオペレーターのスコープ、`verify_brand_claim` / `verify_brand_claims` の必須署名レスポンス。
* **シグナルとプロダクトターゲティング。** 強化されたシグナル定義、`SignalRef`、ホールセールシグナル列挙、プロダクトスコープの `included_signals`、選択可能な `signal_targeting_options`、グループ化されたバイ時の `signal_targeting_groups`、所有対マーケットプレイスの適合性の明確化。
* **ホールセールフィードミラーリング。** 条件付きフェッチトークン、public/account の `cache_scope`、プロダクトとシグナルのホールセールフィード webhook、ストアフロント・レジストリ・連合マーケットプレイスの repair-by-read セマンティクス。
* **クリエイティブフォーマット。** 正準 `format_kind` 宣言、パブリッシャーフォーマットカタログ、`v1_format_ref` デュアル発行、ホスト音声/動画の `duration_ms_exact` と片側 `duration_ms_range`、公開済み投稿参照、動画プレースメントセマンティクス。
* **クリエイティブ生成。** `list_transformers`、アカウントスコープのトランスフォーマー選択、厳格な型付き `config`、カタログとバリアントのファンアウト、`creative-feature-result[]` 上の助言的エバリュエーターランキング、支出制御、コンテンツマクロ、自由テキストパラメーター、出力ごとの価格領収書。
* **メディアバイ操作。** 依存関係障害、バイヤー可視の `webhook_activity[]`、アクションディスカバリー、プロポーザルライフサイクルのクリーンアップ、通貨スコープのプロダクトディスカバリー、sponsored/social プレースメントフィールド、SI 可用性ステータス。
* **測定と課金。** ベンダー証明の `vendor_metric` 目標、リーチウィンドウセマンティクス、`viewability.viewed_seconds`、ウィンドウ配信リカバリー、配信と使用量の確定フラグ、帯域外クリエイティブ課金宣言。
* **ランタイム堅牢化。** すべてのタスクのリクエスト冪等性、`IDEMPOTENCY_IN_FLIGHT`、リカバリー分類を伴うオープンエラーコードデコード、auth エラー分割、ペイロード内認証情報の拒否、webhook 操作 ID エコー、フラット MCP エンベロープ許容。
* **SDK とコンプライアンスの準備。** コードジェネレーターのための名前付きスキーマ、非同期レスポンス ref、意図的にオープンなペイロードマーカー、ケイパビリティゲートのストーリーボードカバレッジ、パッケージ化されたコンプライアンスバンドルのクロージャ、リリースアーティファクトのドリフトチェック。
## なぜアップグレードするか
3.1 は本番堅牢化リリースです。3.0 はプロトコルサーフェス — ディスカバリー、バイライフサイクル、シグナル、クリエイティブライブラリ、ブランドアイデンティティ — を出荷しました。3.1 は、実際のエージェントが実際のパブリッシャーに対してバイを実行し始めたときにサーフェスした運用上のギャップを閉じます:
* **今や webhook をデバッグできる。** バイヤーエージェントは、ゲートウェイがなぜ 5xx を返したかを推測する代わりに、`get_media_buys` の `webhook_activity[]` 経由で自身の最近の配信発火 — HTTP ステータス、発火時刻、idempotency\_key — を検査します。
* **バイがなぜ障害を受けているか見える。** クリエイティブが引き下げられ、オーディエンスが停止され、カタログアイテムが撤回され、イベントソースが静かになると、バイの `health` が `impaired` に切り替わり、`impairments[]` がすべてのオフライン依存関係をその package\_ids と修復ヒントとともにリストします。`get_media_buys` のスナップショットとして、また `notification-type: impairment` 経由のプッシュ発火として。
* **帯域を消費せずにホールセールプロダクトフィードとホールセールシグナルフィードをミラーできる。** 条件付きフェッチトークン（`if_wholesale_feed_version` — ETag スタイル）、シグナルのホールセール列挙（プロダクトと対称）、アカウントレベルのホールセールフィード webhook により、ストアフロント、連合マーケットプレイス、レジストリは、すべてのポーリングで変更されていないフィードペイロードを再取得せずに、接続されたすべてのエージェントの購入可能なプロダクトとシグナルの最新ローカルレプリカを保持できます。2 層キャッシュモデル（`cache_scope: "public" | "account"`）は、ほとんどのアカウントが単一の共有キャッシュに重複排除されることを意味します。
* **メディアプロダクトにセラー提供のシグナルを合成できる。** プロダクトは、バンドル/計画されたシグナルメタデータの `included_signals`、パッケージレベルのシグナル選択の `signal_targeting_allowed`、プロダクト固有のメニューと価格の任意のインライン `signal_targeting_options`、include/exclude/グループ化制限の `signal_targeting_rules` を宣言できます。バイヤーはグループ化された `targeting_overlay.signal_targeting_groups` を通じて選択を適用し、ホールセールプロダクトはインラインオプションを省略して `get_signals` を選択可能なシグナルフィードとして使えます。
* **目標をベンダー証明の測定にバインドできる。** 最適化目標は今や、セラーが好きに解釈できるベンダー非依存の文字列ではなく、実際の測定ベンダー（DV、IAS、Adelaide、TVision、Lumen、Kantar、Upwave、Scope3 など）からの `(vendor, metric_id)` ペアを参照できます。測定ベンダーカタログディスカバリーサーフェス自体は 3.1 で実験的です（`measurement.core`）。
* **ブランド検証レスポンスがアテステーション可能。** `verify_brand_claim` と `verify_brand_claims` は今や必須の `signed_response` ペイロードエンベロープ JWS を返すため、下流のパートナーはトランスポートセッションコンテキストに依存せずにブランドの回答を保持し検証できます。
* **リリースをピン留めしてドリフトと戦うのをやめられる。** すべてのリクエストでリリース精度の `adcp_version`（安定リリースには `"3.1"`）。セラーは完全な `supported_versions` セットをアドバタイズし、実際に提供したものをエコーします。SDK コンストラクターピンが今や本物です。
* **サブブランドが自己公開する。** ブランドは、コーポレートハウスがポートフォリオポインター経由で所有権を宣言する一方で、自身のドメインで独自の正準 `brand.json` を公開できます — IAB の `ads.txt` / `sellers.json` と同じ相互パターン。
* **クリエイティブフォーマットに正準語彙がある。** 12 の正準 `format_kind` 値 + パブリッシャーカタログディスカバリーサーフェス + 投影 ref メカニズム。クリエイティブエージェントは `creative.supported_formats[]` を通じてビルド可能な正準出力もアドバタイズします。ターゲット可能なエントリは `build_creative` ルーティングのため安定した `capability_id` 値を含むべきです（SHOULD）。
* **ホスト音声/動画 duration は 1 つの範囲語彙を使う。** `duration_ms_range` は今や有界と片側範囲をカバーします（「最大 60 秒」の `[null, 60000]`、「少なくとも 15 秒」の `[15000, null]`）。固定スロットは `duration_ms_exact` を使うべき。別個の min/max duration フィールドは追加されませんでした。
* **クリエイティブトランスフォーマーを発見・選択できる。** 新しい `list_transformers` タスクが、アカウントスコープのエージェント提供ビルドユニット — ボイス、モデル、スタイル — メディアバイプロダクトのクリエイティブ版をサーフェスし、同じツールで列挙可能なオプション値（例: 設定済みのボイス）を返す `expand_params` モードを持ちます。`build_creative` は `transformer_id` で 1 つを選択し、型付き `config` バッグで設定し（厳格な検証 — 未知のキーと範囲外の値はフィールド帰属エラーで拒否。ベンダーノブは `ext` へ）、カタログアイテム（`max_creatives`）と代替（`max_variants` + `variant_axis`、`keep_mode` は助言的）にわたってファンアウトします。新しい `BuildCreativeVariantSuccess` レスポンスメンバーが、バリアントごとのマニフェスト、推奨/ランク、リーフごとの価格領収書を運びます。価格はトランスフォーマー（`pricing_options` `per_unit`）に移動し、`report_usage` 経由で決済されます。
* **動画と音声のインベントリが実行セマンティクスを宣言できる。** プロダクトとプレースメントは OpenRTB 整合の `video_placement_types` と `audio_distribution_types` を宣言できるため、バイヤーはバイヤー向けチャネルを変えずに instream/accompanying/interstitial/standalone 動画と music streaming/FM-AM broadcast/podcast/catch-up/web-radio 音声を区別できます。
* **検証バッジがバージョンスコープ。** 公開 3.1 バッジ発行はアクティブな 3.0 バッジと並行して実行でき、リリースにピン留めされたバイヤーは一致するバッジバージョンを読みます。
* **アクションディスカバリーとプロポーザルが機械的。** プロダクトは `allowed_actions[]` をアドバタイズし、メディアバイは `available_actions[]` を運び、プロポーザルは `proposal_status` を使って `create_media_buy(proposal_id)` の前に finalize がまだ必要かを言います。
* **課金に確定がある。** 配信の行レベル `is_final` + `finalized_at`。`report_usage` の一致する `final` + `finalized_at` + `measurement_window`。バイヤーは数が動かなくなるときを知り、請求書を再照合できます。
加えて、エラーコードの明確化、auth 厳格化、冪等性ルール、TMP IdentityMatch アップグレード、`adagents.json` スケーリング作業の長い裾野 — 下の見出しリストを参照。
## 一目で
| Area | 3.0 | 3.1 |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`brand.json`** | 単一のハウスドキュメント下のインライン `brands[]` | 分散型: ブランドが自身のドメインで自己公開。ハウスは `brand_refs[]` 経由で所有権を宣言。相互アサーション信頼。型付き `trademarks[]` |
| **ブランド検証** | brand.json ディスカバリーのみ | `verify_brand_claim` / `verify_brand_claims` — 必須 `signed_response` ペイロードエンベロープ JWS 証拠を伴う連合の権威ある検証 |
| **依存関係影響** | 「バイが依存するリソースがオフラインになった」のプロトコルサーフェスなし | `media_buy.health` + `impairments[]` スナップショット。`notification-type: impairment` webhook。`propagation_surfaces` ケイパビリティ。`impairment.coherence` コンプライアンス不変条件 |
| **Webhook 基盤** | 機能ごとに仕様化 | 1 つの永続チャネルコントラクト: snapshot/log 双対性、エンベロープで型付けされた `notification_id`、アカウントごと + リソースごとのサブスクリプションモデル |
| **Webhook 可観測性** | バイヤー側の配信可視性なし | `get_media_buys` の `webhook_activity[]` — バイヤーが自身の逃した発火をセルフサービスでデバッグ |
| **ホールセールフィードミラーリング** | 変更検出のためすべてのポーリングでホールセールを再取得 | `get_products` / `get_signals` の ETag スタイル `wholesale_feed_version` / `if_wholesale_feed_version` 条件付きフェッチ。2 層キャッシュ層のためすべてのレスポンスで `cache_scope`（public/account） |
| **ホールセールシグナル** | `get_signals` は `signal_spec` または非推奨 `signal_ids` を要求 — 完全な価格付きシグナルフィードを列挙するプロトコル準拠の方法なし | `get_products buying_mode: "wholesale"` と対称の `discovery_mode: "wholesale"`。`signal_ref` アイデンティティと `pricing_options[]` 投入を伴うページ分割された完全ホールセールシグナルフィード列挙 |
| **シグナルアイデンティティ** | `SignalId` / `signal_id.source`（`catalog` または `agent`）がプライマリシグナルアイデンティティ形状だった | `SignalRef` / `signal_ref.scope` が正準: プロバイダー公開の adagents.json シグナルには `data_provider`、ソースネイティブシグナルには `signal_source`、プロダクトローカルのメディアバイオプションには `product`。レガシー `signal_id` は移行ウィンドウ中受け入れられたまま |
| **プロダクトシグナルメタデータ** | `data_provider_signals` がレガシーバンドルメタデータを混合、選択可能なパッケージレベルのシグナルサーフェスなし | `data_provider_signals` は非推奨。非選択のバンドル/計画シグナルには `included_signals`、価格・アクティベーションハンドル・デフォルト・グループ化ヒントを伴う選択可能なプロダクトスコープシグナルオプションには `signal_targeting_options` を使う |
| **パッケージシグナルターゲティング** | セラー提供の名前付きシグナルのグループ化されたバイ時サーフェスなし。ストアフロントはオーディエンスフィールドやブリーフテキストを過負荷 | `targeting_overlay.signal_targeting_groups`: トップレベル `operator: "all"` と子 `any` include グループ、`none` 除外グループ。プロダクト `signal_targeting_rules` が選択モード、direct 対 seller-planned 解決、グループ制限を宣言 |
| **ホールセールフィード webhook** | なし | `sync_accounts.accounts[].notification_configs[]` 経由で登録されるアカウントレベル webhook が `applies_to.scope` を伴う `product.*` / `signal.*` / `wholesale_feed.bulk_change` 変更ペイロードを運ぶ。標準の webhook 署名と SSRF ガードが適用 |
| **クリエイティブフォーマット** | パブリッシャーごとのバリアントを伴う名前によるフォーマット | 12 の正準 `format_kind` 値 + パブリッシャーカタログディスカバリー（`adagents.json formats[]`）+ デュアル発行の `v1_format_ref` + サイズ柔軟性（固定 / マルチサイズ / レスポンシブ）。クリエイティブエージェントは `creative.supported_formats[]` でビルド可能な出力をアドバタイズし、ターゲット可能なエントリに `capability_id` を含むべき |
| **ホスト音声/動画 duration 制約** | 固定 duration または閉じた範囲のみ | 固定スロットの `duration_ms_exact`。`[null, 60000]` や `[15000, null]` のような有界と片側範囲の `duration_ms_range`。`[null, null]` は無効 |
| **クリエイティブトランスフォーマー** | `build_creative` はターゲットフォーマットにビルド。レンダーノブは暗黙。フォーマット添付の `Format.input_format_ids` / `output_format_ids` / `pricing_options` | `list_transformers` が `expand_params` オプション列挙モードでアカウントスコープのビルドユニット（ボイス/モデル/スタイル）を発見。`build_creative` が `transformer_id` で 1 つを選択、厳格検証の型付き `config` を取り、`max_creatives`（カタログアイテムごと）+ `max_variants`/`variant_axis` + 助言的 `keep_mode` でファンアウト。新しい `BuildCreativeVariantSuccess` メンバーがバリアントごとのマニフェスト、推奨/`rank`、リーフごとの価格領収書を返す。レートは `transformer.pricing_options`（`per_unit`）、`report_usage` 経由で決済。出荷済みの `BuildCreativeSuccess` / `BuildCreativeMultiSuccess` は変更なし |
| **バージョンネゴシエーション** | リクエストごとの整数 `adcp_major_version` | リリース精度 `adcp_version`（例: 安定リリースの `"3.1"`）+ `adcp.supported_versions` アドバタイズ + エンベロープエコー。整数フィールドは後方互換のレガシーとして残る |
| **最適化目標** | `event` + `metric` kind、ベンダー非依存 | 新しい `vendor_metric` kind — 目標をベンダー証明のメトリクスにバインド。プロダクトごとの `vendor_metric_optimization` ケイパビリティ。3 前提条件の拒否ルール |
| **ケイパビリティ宣言** | プロトコルごとの基本 | 新規: ホールセールプロダクトの `media_buy.buying_modes`、ホールセールシグナルの `signals.discovery_modes`、`wholesale_feed_versioning`、`wholesale_feed_webhooks`、`supported_optimization_metrics`、`supported_target_kinds`、`media_buy.frequency_capping`、`media_buy.propagation_surfaces`、`creative.bills_through_adcp`、`capabilities.idempotency.in_flight_max_seconds` |
| **動画と音声の実行ディスカバリー** | 動画と音声のプロダクトは自由テキスト説明、プレースメント名、過負荷のチャネルに依存 | OpenRTB `video.plcmt` と `audio.feed` 値に AdCP ネイティブ名を使う、プロダクト・プレースメント・`get_products.filters` の `video_placement_types` と `audio_distribution_types` |
| **通貨スコープディスカバリー** | バイヤーは予算通貨をフィルターできたが、メディアプロダクト価格で取引できる通貨はできなかった | `get_products.filters` の `pricing_currencies`。セラーはプロダクトレベルの `pricing_options` をマッチし、返されるプロダクト価格オプションを要求された通貨に刈り込み、その通貨で必須のプロダクトスコープシグナル料金が満たせないプロダクトを除外 |
| **配信レポート** | ウィンドウセマンティクスなしの `reach`。ビューアビリティはレートのみ | `reach_window`（cumulative / period / rolling）。`viewability.viewed_seconds`。`time_granularity` + `include_window_breakdown` 経由のウィンドウ付きプルリカバリー |
| **課金サーフェス** | `billing_measurement` 経由の権威。確定マーカーなし | 配信の行レベル `is_final` + `finalized_at`。`report_usage` の `final` + `finalized_at` + `measurement_window`。`creative.bills_through_adcp` ケイパビリティ + `BILLING_OUT_OF_BAND` エラー |
| **アクションディスカバリー** | バイ/プロダクトの構造化アクション語彙なし | Product の `allowed_actions[]`（助言的テンプレート）。`get_media_buys` / `create_media_buy` / `update_media_buy` の `available_actions[]`。プロポーザル実行可能性はアクションモードハックではなく `proposal_status` から来る |
| **Auth + セキュリティ** | 単一の `AUTH_REQUIRED` エラー。トランスポートチャネルルールなし | `AUTH_REQUIRED` を `AUTH_MISSING`（correctable）+ `AUTH_INVALID`（terminal）に分割。`CREDENTIAL_IN_ARGS` がリクエストペイロード内の認証情報を拒否。request-signing `protocol_methods_*` 名前空間 |
| **冪等性** | 呼び出しごとのリプレイのみ | Rule 9（並行リトライ）+ Rule 10（下流再照合）。`IDEMPOTENCY_IN_FLIGHT` エラーコード。`capabilities.idempotency.in_flight_max_seconds` |
| **非同期エンベロープ** | create スタイルタスクの 2 形状 submitted エンベロープ | `sync_audiences` に拡張された 3 形状エンベロープ |
| **TMP IdentityMatch** | 基本リクエスト/レスポンス | `serve_window_sec` frequency-cap データフロー。リクエストに `seller_agent_url` 必須。任意の `package_ids` |
| **`adagents.json`** | authoritative のみのディスカバリー | マネージドネットワークスケール（20 MB 上限 + `publisher_domains[]` コンパクト形式）。ads.txt `managerdomain` フォールバック。厳格化された `revoked_publisher_domains[]` セマンティクス |
| **スキーマ整理** | — | SDK ジェネレーターのための名前付き再利用可能スキーマ。`x-adcp-hoist` オプトインマーカー。意図的にオープンな JSON ペイロードフィールドの `x-adcp-open-payload` マーカー。オープン文字列コンプライアンスシナリオ。text-asset-requirements の `allowed_values`。`vast_tracker` + `daast_tracker` アセットタイプ。create/update レスポンスの任意 `currency`/`total_budget` |
| **コンプライアンススイート** | ツールごとのシナリオ | `frequency_cap_enforcement`、`per_creative_attribution`、`metric_mode`、ROAS、`audience_buy_flow`、`event_dedup_flow`、`performance_buy_flow`、`product_signal_targeting` のケイパビリティゲートシナリオ。ストーリーボード `requires` ランタイムゲート。`comply_test_controller` サンドボックスゲート。バージョンスコープのバッジ証拠。公開コンプライアンスバンドルのパッケージ参照検証 |
### ケイパビリティスロット移行ノート
`definePlatform` などの SDK ヘルパーを使うとき、サポートされないケイパビリティスロットを `get_adcp_capabilities` から欠如させてください。欠けているスロットは正直なスコープ境界です: そのスロットをターゲットにするストーリーボードとローカルテストベクターは、失敗ではなく `not_applicable` とグレードすべきです。
現在の回避策: プレリリース/カスタムランナーは、宣言されたスロットスコープ外のベクターに明示的なスキップゲートを追加すべきです。ランナー側のフォローアップは `adcp-client#2244` で追跡されます。
## 主要機能
### 分散型 `brand.json` — サブブランドが自己公開
ブランドは今や、コーポレートハウスがポートフォリオポインター（`brand_refs[]`）経由で所有権を宣言する一方で、自身のドメインで **独自の** 正準 `brand.json` を公開できます。階層は 1 レベルの深さのまま — ハウスのみが所有権を宣言します。信頼は相互アサーション経由で解決されます: 両側が相互に応じます。アイデンティティ属性（ロゴ、色、トーン、タグライン）はリーフの TLS のみを信頼します。関係信頼（ガバナンス伝播、課金対象の包含）は相互エントリでゲートされます。
IAB の `ads.txt` / `sellers.json` / `app-ads.txt` 相互公開パターンと同じ形状を、ブランドアイデンティティに適用。加えて: 任意の `status`、`license_type`、`licensor_domain`、`countries`、`nice_classes`（業界横断の曖昧性解消）を伴う型付き `trademarks[]`。コンプライアンスフィールドは strictest-of で解決される（ブランドレベルは厳格化でき、決して弱められない）一方、アイデンティティフィールドは brand-wins のまま。
→ 規範的仕様: [`brand.json` § 分散型公開](/docs/brand-protocol/brand-json#distributed-publishing) · PR [#4505](https://github.com/adcontextprotocol/adcp/pull/4505)
### `verify_brand_claim` / `verify_brand_claims` — 連合ブランド検証
2 つの新しいブランドプロトコルタスクにより、パートナーはクレームがそのブランドに属するかを権威あるかたちでブランドに尋ねられます: ブランド自身のドメインで公開されたブランドエージェントに、商標所有権、広告クリエイティブクレーム、アセット権利を検証する必要のある誰もがクエリします。設計上連合 — すべてのブランドエージェントは自身のブランドのみに答えます。#4505 のメールベースの自己修復 SHOULD を、より豊かなプルベースの DRM-for-brand-identity サーフェスとして再構成します。
RC4 は信頼エンベロープをロックします: 成功した `verify_brand_claim` と `verify_brand_claims` レスポンスは、正準タスクボディレスポンスに対するペイロードエンベロープ JWS の `signed_response` を要求します。署名は回答を指定タスク、解決されたブランドテナント、応答エージェント URL、呼び出し元/リクエストハッシュ、`iat`/`exp` 鮮度ウィンドウにバインドします。検証者は `adcp_use: "response-signing"` で鍵を解決し、未署名のレスポンスフィールドと `signed_response.payload.response` の不一致を拒否します。
→ 仕様: [Brand Protocol § verify\_brand\_claim](/docs/brand-protocol/tasks/verify_brand_claim) · [Security § 指定タスクレスポンス署名](/docs/building/by-layer/L1/security#designated-task-response-signing) · PR [#4540](https://github.com/adcontextprotocol/adcp/pull/4540)、[#4603](https://github.com/adcontextprotocol/adcp/pull/4603)、[#5192](https://github.com/adcontextprotocol/adcp/pull/5192)
### 依存関係影響 webhook とスナップショット整合性
メディアバイが依存するリソースがオフライン状態に遷移するとき — オーディエンス停止、承認後のクリエイティブ停止/拒否、カタログアイテム撤回、イベントソース静止、プロパティ公開停止 — バイヤーは 2 つの並行サーフェスを通じてそれを見ます:
* **スナップショット。** `media_buy.health` が `ok` から `impaired` に切り替わる。`media_buy.impairments[]` がすべてのオフラインリソースをその package\_ids、遷移、reason\_code、修復ヒントとともにリストする。次の `get_media_buys` 読み取りが現在の真実を示す。
* **ログ。** `notification-type: impairment` webhook が `notification_id = impairment_id` と同じペイロード形状で発火し、`push_notification_config` 経由で設定される。
いずれの経路も完全。プッシュとプルが不一致のとき、バイヤーはスナップショット経由で再照合します。セラーは `capabilities.media_buy.propagation_surfaces`（`["snapshot"]`、`["webhook"]`、`["snapshot", "webhook"]`、または `["out_of_band"]`）でどのサーフェスを使うかを宣言します。`impairment.coherence` コンプライアンス不変条件がコントラクトをエンドツーエンドでグレードします（forward、inverse、health-iff ルール。terminal-status バイで緩和）。
→ 仕様: [Media Buy Lifecycle § Health & impairments](/docs/media-buy/media-buys/lifecycle#health-impairments) · [スナップショットとログコントラクト](/docs/protocol/snapshot-and-log) · RFC #2853 · PR #4588、#4601、#4677、#4685、#4690
### Webhook 基盤 + バイヤー側の配信可視性
3.1 はすべてのプッシュサーフェスのための 1 つの永続チャネルコントラクトを成文化します: スナップショットが権威的、プッシュは at-least-once かつ順序なし、`idempotency_key` で重複排除、`notification_id` で状態を相関（今や `mcp-webhook-payload.json` のエンベロープレベルで型付け）、リプレイ = スナップショットを再読み取り。将来の webhook RFC は基盤を再導出する代わりにそれを参照します。サブスクリプションモデルはアカウントごとに拡張され、メディアバイがクリエイティブを直接参照していなくてもクリエイティブライブラリレベルのイベント（クリエイティブ状態変更）が発火します。
本番デバッグのため、バイヤーは `get_media_buys` の `webhook_activity[]` にオプトインできます — 見えるバイの最近の発火を、HTTP ステータス、発火時刻、`idempotency_key` とともに。「パブリッシャーが発火したがゲートウェイが 5xx を返して見えない」というブラックボックスはもうありません。純粋なセルフサービス: バイヤーはオペレーターの往復なしに自身の統合をデバッグします。
→ 仕様: [スナップショットとログコントラクト](/docs/protocol/snapshot-and-log) · [Webhooks § 永続チャネルコントラクト](/docs/building/by-layer/L3/webhooks#persistent-channel-contract) · RFC #4582 · PR #4601、#4701、#4730
### ホールセールフィードミラーリング — 条件付きフェッチ、ホールセールシグナル、webhook
3 つのコンパニオン提案により、コンシューマー（ストアフロント、連合マーケットプレイス、レジストリ、代理店ブランドスタック）は、ポーリングごとのホールセールフェッチで帯域を消費せずに、接続されたすべての AdCP エージェントの購入可能なホールセールプロダクトフィードとホールセールシグナルフィードのほぼリアルタイムのローカルミラーを維持できます。独立かつ補完的 — エージェントは任意のサブセットを採用してもよく（MAY）、コンシューマーはそうしないエージェントに対してホールセールポーリングにフォールバックします。
用語: このセクションは `get_products` / `get_signals` からのセラー側プロダクトとシグナルに **ホールセールフィード** を使います。それは、バイヤー提供のキャンペーン入力フィードをセラーアカウントにアップロードする `sync_catalogs` とは異なります。
* **条件付きフェッチ（`if_wholesale_feed_version`）。** すべての `get_products` / `get_signals` レスポンスは不透明な `wholesale_feed_version` トークンを返します。次の呼び出しでそれを戻し、セラーは `unchanged: true` で短絡してもよい（MAY） — プロダクトやシグナルのペイロードなし、ページごとの差分なし。ETag/HTTP セマンティクス。構造的メタデータと独立してレートカードを動かすセラーのための任意のコンパニオン `pricing_version`。`if_pricing_version` は `if_wholesale_feed_version` を必要とします（`dependencies` 経由でスキーマ強制）。後方互換: トークンを無視する 3.1 以前のエージェントは完全なペイロードを返すだけ。
* **ホールセールシグナル（`discovery_mode: "wholesale"`）。** 呼び出し元は `signal_spec` / `signal_refs` / 非推奨 `signal_ids` を省略し、シグナルエージェントの完全な価格付きシグナルフィードをページ分割して列挙できます。`get_products` `buying_mode: "wholesale"` と対称で、以前ストアフロントとマーケットプレイスをシグナルフィードのミラーのためのハックなプローブクエリに強いていたギャップを閉じます。
* **ホールセールフィード webhook。** `sync_accounts.accounts[].notification_configs[]` を通じて登録されるアカウントレベル webhook が `product.{created,updated,priced,removed}`、`signal.{created,updated,priced,removed}`、`wholesale_feed.bulk_change` 通知を発します。各 webhook は `core/wholesale-feed-webhook.json` を運びます: 実際に変更されたプロダクト/シグナルペイロードまたは一括変更サマリー、変更後の `wholesale_feed_version`、キャッシュ無効化のための `applies_to.scope`。ポーリングイベントタスクはありません。コンシューマーは逃したまたは信頼されないプッシュを `get_products` / `get_signals` を通じて修復します。
**キャッシュ層は負荷を担う設計判断です。** すべてのレスポンスは `cache_scope: "public" | "account"` を宣言します（スキーマ必須 — 2 層キャッシュの安全プロパティがそれに依存する）。リクエストに `account` がなかったとき、`"public"` でなければなりません（MUST）。リクエストに `account` があったとき、セラーは `"public"`（このアカウントはレートカードで価格設定 — バイヤーは未認証ビューと重複排除）または `"account"`（カスタムオーバーライド — バイヤーはアカウントキーでキャッシュ）を宣言します。ほとんどのセラーのほとんどのアカウントは public 層で価格設定するため、N 個のアカウントキャッシュを保持するコンシューマーは通常 1 つの public キャッシュ + 少数のオーバーレイに重複排除します。イベントは `applies_to.scope`（任意の `account_ids[]` 付き）を運ぶため、コンシューマーは正しいキャッシュ層を無効化します — public イベントはすべてのオーバーレイにカスケードし、account イベントは名前付きオーバーレイのみに触れます。セラーは、以前アカウントスコープだったタプルに public スコープレスポンスを返すことで、アカウントを `"account"` から `"public"` にダウングレードしてもよく（MAY）、「このアカウントはもうオーバーライドを持たない。オーバーレイをドロップせよ」を示します。
**セキュリティ姿勢は正直です。** 助言的ペイロードのフレーミングは、フィードイベントを `get_products` / `get_signals` に対して再検証することがトランスポート改ざんのみに対して防御することを明示します — 侵害されたエージェントオペレーターは自身の嘘を再確認します。オペレーター侵害防御は、支出をゲートする既存の信頼アンカー（署名付き `create_media_buy` レスポンス、マーケットプレイスシグナル来歴のための `adagents.json` ピン留め署名鍵）に存在し、フィードイベントのコンテンツ署名は 4.0 R-1 root-of-trust トラックに延期されます。イベントを安価なミラー無効化として扱い、ドルや権限をコミットする任意の決定の基礎としてはなりません。
ケイパビリティ宣言: `wholesale_feed_versioning`（条件付きフェッチ + `pricing_version_separate` + `cache_scope_account`）、`wholesale_feed_webhooks`（webhook 変更ペイロード）、`media_buy.buying_modes` と `signals.discovery_modes`（ホールセールサポート）。`product.*` webhook イベントをアドバタイズするエージェントはホールセール `get_products` もアドバタイズしなければならず、`signal.*` イベントをアドバタイズするエージェントはホールセール `get_signals` もアドバタイズしなければならず、`wholesale_feed.bulk_change` はそれらの修復パスの 1 つに裏付けられたフィードファミリーのみを名指ししなければなりません。webhook エンベロープの JSON Schema は `core/wholesale-feed-webhook.json`、`core/wholesale-feed-event.json`（event\_type で判別、9 ブランチ + `appliesTo` / `removalReason` `$defs`）をラップ。
→ 仕様: [ホールセールフィード webhook](https://github.com/adcontextprotocol/adcp/blob/main/specs/wholesale-feed-webhooks.md) · [`get_products` § ホールセールフィードバージョニング](/docs/media-buy/task-reference/get_products#wholesale-feed-versioning) · [`get_products` § キャッシュ層](/docs/media-buy/task-reference/get_products#cache-layering) · [`get_signals` § ホールセールシグナルフィード](/docs/signals/tasks/get_signals#wholesale-signals-feed) · PR [#4761](https://github.com/adcontextprotocol/adcp/pull/4761)（条件付きフェッチ）、[#4762](https://github.com/adcontextprotocol/adcp/pull/4762)（ホールセールシグナル）、[#4763](https://github.com/adcontextprotocol/adcp/pull/4763)（フィード webhook）、[#4767](https://github.com/adcontextprotocol/adcp/pull/4767)（クラスター実装）
### プロダクトスコープシグナルターゲティング — 含まれる対選択可能なシグナル
3.1 は、メディアバイのセラー提供シグナルのためのプロダクトスコープシグナルターゲティングコントラクトを追加します。これは広範なシグナルディスカバリーと実際のパッケージレベルのバイサーフェスの間のギャップを閉じます:
* **`included_signals`** は、プロダクトにすでにバンドル、包含、またはセラー計画されたシグナルを記述します。これらは記述的なプロダクトメタデータであり、バイヤーが選択可能な制御ではありません。
* **`data_provider_signals` は非推奨。** レガシーバンドルメタデータとして互換性のため残りますが、新しい実装は非選択のシグナルに `included_signals`、選択可能なものに `signal_targeting_options` を使います。
* **`signal_targeting_allowed`** は、プロダクトがパッケージレベルの `signal_targeting_groups` サーフェスを持つことをバイヤーに伝えます。デフォルトは false。
* **`signal_targeting_options`** は、プロダクトがプロダクト固有の価格、アクティベーションハンドル、デフォルト/固定選択、グループ化ヒント、または brief/refine 選択のサブセットを必要とするときのインライン選択可能メニューです。ホールセールプロダクトはこのフィールドを省略し `get_signals` を選択可能フィードとして使えます。
* **`signal_targeting_rules`** は、プロダクト固有の合成コントラクトを宣言します: direct ターゲティング対 seller-planned 解決、optional/required/fixed 選択、min/max 数、グループ化制限。単一のセラーがプロダクトを異なるアドサーバーや計画層を通じてルーティングしうるため、これはプロダクトに属します。
バイヤーは選択されたシグナルを `packages[].targeting_overlay.signal_targeting_groups` で適用します。ポータブルなベースラインは意図的にシンプルです: トップレベル `operator: "all"` と、include の子 `operator: "any"` グループ、exclude の子 `operator: "none"` グループ。バイナリシグナルについては、シグナル式は `value: true` を使います。除外は `value: false` ではなく親 `none` グループで表現されます。
シグナルアイデンティティも正規化されます。新しいペイロードは `signal_ref` を使います:
* プロバイダーの公開 adagents.json シグナルで定義されたシグナルには `scope: "data_provider"` + `data_provider_domain` + `signal_id`。
* 上流 adagents.json シグナルで公開されていないソースネイティブシグナルには `scope: "signal_source"` + `signal_source_url` + `signal_id`。
* 選択されたプロダクト/パッケージコンテキスト内でのみ意味のあるプロダクトローカルオプションには `scope: "product"` + `signal_id`。
レガシー `SignalId` / `signal_id.source` は、`get_signals`、オーディエンスセレクター、レガシーフラットシグナルターゲティング、ホールセールシグナルイベントを含め、マイナーバージョン移行ウィンドウ中受け入れられたままですが、`SignalRef` が新しいクライアントの正準形状です。レガシーフラット `targeting_overlay.signal_targeting` はスキーマ有効だが非推奨のままです。新しいパッケージレベル合成は `signal_targeting_groups` を使います。
→ 仕様: [Product discovery § Signal targeting](/docs/media-buy/product-discovery/media-products#signal-targeting) · [Targeting § signal\_targeting\_groups](/docs/media-buy/advanced-topics/targeting#signal_targeting_groups) · [`get_signals`](/docs/signals/tasks/get_signals) · PR [#5009](https://github.com/adcontextprotocol/adcp/pull/5009)
### 正準クリエイティブフォーマット — ライブ、12 正準、後方互換
* **公開済み投稿参照クリエイティブ。** 既存のソーシャル/パブリッシャー投稿は、`asset_source: "publisher_owned_reference"` と `published_post` スロットを伴う正準 `video_hosted`、`image`、`native_in_feed` フォーマットとして表現されます。プロダクトは、広告主アカウントやパブリッシャーアイデンティティ接続などの下流プラットフォーム付与のため `required_connections[]` を宣言できます。欠けているまたは期限切れの付与は `error.details.missing_connections[]` を伴う `AUTHORIZATION_REQUIRED` を使います。回復可能な依存関係の喪失は、ポリシー拒否ではなくクリエイティブを `suspended` に移します。カタログ駆動のリテールメディアは `source_catalog` を伴う `sponsored_placement` のままです。
3.1 でライブ、3.0 に対して加算的。プロダクトは `format_options[]` を運びます: 正準 enum からの `format_kind` 判別子を持つ `ProductFormatDeclaration` エントリのリスト。**12 正準:** `image`、`html5`、`display_tag`、`video_hosted`、`video_vast`、`audio_hosted`、`audio_daast`、`image_carousel`、`native_in_feed`、`responsive_creative`、`sponsored_placement`、`agent_placement`。enum は、正準に適合しない採用者定義の形状のエスケープハッチとして `custom` も含みます。3 つの正準（`sponsored_placement`、`responsive_creative`、`agent_placement`）+ `custom` はフレームワーク内で **実験的** とタグ付けされます。残りの正準は非実験的です。新しい正準の昇格キューは [#3666](https://github.com/adcontextprotocol/adcp/issues/3666) で追跡されます。
**後方互換性。** v1 `format_ids` パスは依然として機能します。`ProductFormatDeclaration` は任意の `v1_format_ref: [{agent_url, id}]` 配列を運ぶため、v2 宣言は 1 つ以上の v1 名前付きフォーマットにリンクします — セラーは移行ウィンドウ中デュアル発行できます。SDK は enum を **パース時にオープン** として扱います: 未知の将来の正準は検証に失敗しません。SDK は `declared_only` のようなローカルルーティングステータスをサーフェスしてもよいが、そのステータスは 3.1 ワイヤーフィールドではありません。
**パブリッシャーカタログ。** `list_creative_formats(publisher_domain="…")` は、`/.well-known/adagents.json formats[]` を読んでパブリッシャーの権威あるフォーマットリストを返し、AAO コミュニティミラー、次にエージェント由来にフォールバックします。レスポンスは `source: "publisher" | "aao_mirror" | "agent_derived"` を運ぶため、バイヤーはどの層がリストを生成したかを知ります。
**サイズ柔軟性。** ディスプレイ正準はサイズを 3 つのモードで宣言します: 固定（`width`+`height`）、マルチサイズ（`sizes: [{w,h}]` — OpenRTB `banner.format[]` をミラー）、またはレスポンシブ（`min_width`/`max_width`/`min_height`/`max_height`）。相互排他的。
**ホスト音声/動画 duration 範囲。** `audio_hosted` と `video_hosted` は、固定 duration スロットに `duration_ms_exact`、有界または片側範囲に `duration_ms_range` を使います。`duration_ms_range` のいずれのエンドポイントも `null` でよい（MAY）: `[null, 60000]` は「最大 60 秒」、`[15000, null]` は「少なくとも 15 秒」を意味します。`[null, null]` は無効で、両方の duration フィールドが存在する場合 `duration_ms_exact` が優先されます。
→ 仕様: [正準フォーマット](/docs/creative/canonical-formats) · PR [#3307](https://github.com/adcontextprotocol/adcp/pull/3307)、[#4770](https://github.com/adcontextprotocol/adcp/pull/4770)、[#5323](https://github.com/adcontextprotocol/adcp/pull/5323)
### クリエイティブトランスフォーマー — ビルドケイパビリティを発見、選択、ファンアウト、バリアント
3.1 は **トランスフォーマー** を導入します: メディアバイプロダクトのクリエイティブ版。トランスフォーマーは、エージェント提供の、アカウントスコープの、選択可能なビルドケイパビリティの単位 — ボイス、モデル、スタイル、ディレクター — で、型付き設定サーフェスとアカウントごとの価格を持ちます。セットはアカウント固有で動的（設定済みのボイスはグローバル enum ではない）なので、ディスカバリーは `get_products` がアカウントスコープのインベントリをサーフェスするのと同じ方法でエージェント → バイヤーに流れます。
* **`list_transformers`** は新しいディスカバリーサーフェスです。あなたのアカウントにクリエイティブエージェントが提供するトランスフォーマーを、それぞれ `input_format_ids` / `output_format_ids`、型付きパラメータースキーマ、（`include_pricing` で）`per_unit` レートカードとともに返します。その `expand_params` モードは、あなたに古いローカルリストを保持させる代わりに、同じツールでパラメーターのアカウントスコープの列挙可能なオプション値 — 例えば実際の設定済みボイス — を返します。`get_adcp_capabilities` で `creative.supports_transformers: true` を設定するエージェントのみが提供します。
* **`build_creative` がトランスフォーマーを選択・設定。** `transformer_id` を渡して 1 つを選び（ターゲットフォーマットはその `output_format_ids` のサブセットでなければならない（MUST））、トランスフォーマーのパラメーターにキー付けされた型付き `config` バッグを渡します。検証は厳格: エージェントは未知のキーと範囲外の値をフィールド帰属エラーで拒否しなければなりません（MUST）。ベンダー固有のノブは `ext` へ。
* **2 つのファンアウト軸。** `max_creatives` はアイテム/カタログ軸: N 個の異なるクリエイティブ、カタログアイテムごとに 1 つ（「150 のうち 5」サンプリング） — 1 つのクリエイティブ *内* で使われるアイテムを上限する `item_limit` とは別。`max_variants`（デフォルト 1）は `variant_axis`（`voice` | `theme` | `best_of_n` | `transformer_config` | `custom`、任意の `values[]` と `label` 付き）に沿ってクリエイティブごとの代替を生成します。`keep_mode`（`keep_all` | `keep_one` | `keep_some`）は助言的。解像度と品質レベルは **フォーマット** 軸（`target_format_ids`）であり、バリアントではありません。
* **新しい `BuildCreativeVariantSuccess` レスポンスメンバー**（6 のうち `oneOf` メンバー 3）は `creatives[]` を運び、それぞれ `{ build_creative_id, catalog_item_ref?, variants[] }`。各バリアントは、リーフごとの価格領収書（`pricing_option_id` + `vendor_cost` + `currency` + `consumption`）を伴う `{ build_variant_id, creative_manifest, variant_axis_value?, recommended, rank?, ... }`。ビルドがコストをレポートするとき（集計 `vendor_cost` が存在するとき）、生成されたすべてのリーフは独自の `vendor_cost` + `currency` を運びます（スキーマ強制）。トップレベル `items_total` / `items_returned` に加え集計 `vendor_cost`。出荷済みの `BuildCreativeSuccess` / `BuildCreativeMultiSuccess` は **変更なし**。
* **Best-of-N はバリアント + `keep_mode` + `recommended`/`rank`。** `build_variant_id` は独自の名前空間 — `preview_id`（プレビューレンダー）や配信された `variant_id`（配信）を決して再利用しない。生成されたすべてのバリアント（`per_unit` × N）を **支払う**。保持は選ばれた `build_variant_id` をトラフィックするクライアントの行為。保持されたバリアントは遅延的に `creative_id`（ライブラリに追加 / 最初にトラフィック）を得て `report_usage` に流れる。**フォーマット** ごとの生成はアトミック。**アイテム** ごと（カタログファンアウト）は非アトミック。
* **エバリュエーターランキングはクリエイティブ機能ディスカバリーを再利用。** `creative.supports_evaluator: true` を持つエージェントは、既存の `get_adcp_capabilities.governance.creative_features` カタログをエバリュエーター機能ディスカバリーサーフェスとして使います。`rank_by`、`feature_requirement`、`variants[].eval.features[]` はすべてその同じ機能語彙を参照します。`evaluator_id` は、そのカタログの ID ではなく、事前プロビジョニングされたアカウントプリセットです。`feature_agent.agent_url` は許可リストされた外部スコアリングパスを選択し、`feature_id` はセラーの accepted-verifier エントリに従って要求された機能サブジェクトを曖昧性解消します。`agent_url` 評価が `eval_budget` の下で実行されるとき、セラーは `eval.calls_used` / `eval.seconds_used` などのフィールドでリーフごとの外部判定使用をエコーすべきです（SHOULD）。
* **価格はトランスフォーマーに移動。** レートは `transformer.pricing_options`（`per_unit`）に存在し、`build_creative` でリーフごとの領収書としてインラインでエコーされ、`report_usage` 経由で決済されます。`Format.pricing_options` は `transformer.pricing_options` を優先して **非推奨** です。
**非推奨（3.1、4.0 で削除）。** `Format.input_format_ids`、`Format.output_format_ids`、`Format.pricing_options`、加えて `list_creative_formats` の `input_format_ids` / `output_format_ids` フィルターは非推奨で、すべて `list_transformers` にリダイレクトします。SDK は 3.1–3.x を通じてそれらを尊重します。4.0 で削除されます。フォーマット添付の入力/出力/価格の読み取りを `list_transformers` に移行してください。完全な移行（ディスカバリー劣化、出力ごとの価格、best-of-N 支出の危険を含む）: [Migration › クリエイティブトランスフォーマー](/docs/reference/migration/creative-transformers)。
→ 仕様: [`list_transformers`](/docs/creative/task-reference/list_transformers) · [`build_creative`](/docs/creative/task-reference/build_creative) · [`get_adcp_capabilities` § creative features / evaluator support](/docs/protocol/get_adcp_capabilities)
### リリース精度バージョンネゴシエーション — リリースをピン留め
すべてのリクエストとレスポンスは今や `adcp_version`（リリース精度: 安定リリースの `"3.1"`）を運びます。セラーは `get_adcp_capabilities` で完全な `supported_versions` セットをアドバタイズし、エンベロープルートで実際に提供したリリースをエコーします。SDK はコンストラクターオプション（JS の `adcpVersion: "3.1"`、Python の `adcp_version="3.1"`、Go の `WithAdcpVersion("3.1")`）でピン留めし、レガシーフィールドのみを読むセラーとの互換性のため新しい文字列と整数 `adcp_major_version` ミラーの両方を発します。整数は 3.x を通じて機能し続けます — 加算的出荷、3.0 準拠エージェントに必須の変更なし。`VERSION_UNSUPPORTED` は `error.data.supported_versions[]` エコー付きで型付けされ、リトライが帯域外ルックアップを必要としません。
→ 仕様: [Versioning § Version negotiation](/docs/reference/versioning#version-negotiation) · PR [#3493](https://github.com/adcontextprotocol/adcp/pull/3493)
### ベンダー証明測定 — `vendor_metric` 目標 + プロダクトごとのケイパビリティ
最適化目標は今や 3 番目の `kind: "vendor_metric"` 形状をサポートします — 目標をアテンション（DV、IAS、Adelaide、TVision、Lumen）、パネルベースのブランドリフト（Kantar、Upwave、Cint）、排出（Scope3、Good-Loop）、リテールメディアパートナーメトリクスなどのベンダー証明メトリクスにバインドします。3.0 の `attention_seconds` のようなベンダー非依存の enum 値がベンダーバインドなしには無意味だったギャップを閉じます。
セラーはプロダクトごとの `vendor_metric_optimization` を `supported_metrics[]`（ビディングスタックが向かえる `(vendor, metric_id)` ペア）とともに宣言します。目標受け入れの 3 前提条件拒否ルール — ディスカバリー、ケイパビリティ、レポート整合性 — が、目標がエンドツーエンドで steerable かつ reportable であることを保証します。加えて、ケイパビリティゲートのコンプライアンスシナリオのための `conversion_tracking` のセラーレベル `supported_optimization_metrics` と `supported_target_kinds`。
`measurement.metrics[]` を定義する測定ベンダーカタログは 3.1 で実験的です。それを実装するベンダーは `experimental_features` に `measurement.core` を宣言しなければなりません。バイヤーは、測定タスクとコンプライアンスストーリーボードが凍結されるまで、カタログディスカバリーを 3.x 実験的サーフェスとして扱うべきです。
→ 仕様: [Optimization goals § `vendor_metric` kind](/docs/media-buy/media-buys/optimization-reporting#vendor-metric-goals) · PR [#4668](https://github.com/adcontextprotocol/adcp/pull/4668)、[#4669](https://github.com/adcontextprotocol/adcp/pull/4669)、[#4649](https://github.com/adcontextprotocol/adcp/pull/4649)
### 配信レポート — `reach_window`、`viewed_seconds`、ウィンドウ付きプル
3 つの加算的サーフェスがレポートギャップを閉じます。**`reach_window`** は `reach` と `frequency` の測定ウィンドウ（cumulative / period / rolling）を宣言します — バイヤーはそれなしに行をまたいで reach を合計してはなりません（MUST NOT）。**`viewability.viewed_seconds`** は測定可能なインプレッションごとの平均インビュー duration をレポートし、`viewed_seconds` 最適化目標のレポート側の対応物です。`get_media_buy_delivery` の **ウィンドウ付きプルリカバリー** は `time_granularity` + `include_window_breakdown: true` を受け入れ、同じ粒度で `reporting_webhook` ペイロードと形状整合する `windows[]` スライスを返します — webhook 発火を逃したバイヤーはポーリングで同一データを再構成します。`reporting_capabilities.windowed_pull_granularities` 経由でケイパビリティスコープ。セラーは webhook 対プルの非対称頻度を正直に宣言できます。
→ 仕様: [配信メトリクスリファレンス](/docs/media-buy/task-reference/get_media_buy_delivery) · PR [#4618](https://github.com/adcontextprotocol/adcp/pull/4618)、[#4601](https://github.com/adcontextprotocol/adcp/pull/4601)
### 課金サーフェス — 権威、確定、帯域外
2 つの補完的な変更が課金グレードのレポートストーリーを閉じます。**権威 + 確定フラグ:** `get_media_buy_delivery` レスポンスは今や `media_buy_deliveries[*]` と各 `by_package[*]` に行レベルの `is_final` + `finalized_at` を運びます — バイヤーは数が動かなくなり請求書再照合に安全なときを知ります。`report_usage` で対称: 各使用量レコードは `final`（デフォルト `true`）、`finalized_at`、`measurement_window` を運びます。**`bills_through_adcp` + `BILLING_OUT_OF_BAND`:** クリエイティブエージェントは `capabilities.creative.bills_through_adcp` 経由でプロトコル上で課金するか帯域外で課金するか（フラットライセンス、SaaS、バンドルエンタープライズ — CM360 が正準ケース）を宣言します。バイヤーは事前フィルターします。帯域外モードのセラーは、黙って受け入れるのではなく新しい `BILLING_OUT_OF_BAND` エラーで `report_usage` 呼び出しを拒否します。
→ 仕様: [Billing measurement](/docs/media-buy/advanced-topics/accountability#billing-measurement) · [`report_usage`](/docs/accounts/tasks/report_usage) · PR [#4735](https://github.com/adcontextprotocol/adcp/pull/4735)、[#4561](https://github.com/adcontextprotocol/adcp/pull/4561)
### アクションディスカバリー — `allowed_actions` と `available_actions`
バイライフサイクル変更のための構造化アクション語彙。プロダクトは `allowed_actions[]` を助言的テンプレートとしてアドバタイズします（プロダクトが *一般的に* サポートする変更、`modes[]` と `allowed_statuses[]` 付き）。メディアバイは `get_media_buys` / `create_media_buy` / `update_media_buy` レスポンスに `available_actions[]` を運びます — 現在の状態の *この* バイの有効な変更の現在のセット。バイヤーは呼び出して `INVALID_STATE` を得る代わりに、どの変更が有効かを事前確認します。より細かい値が `media-buy-valid-action` enum に追加されます。レガシーの粗い値は後方互換のため 3.x を通じて保持（4.0 で削除）。
3.1 は GA 前の `requires_proposal` アクションモードを削除します。プロポーザルライフサイクルは今や 1 つのパスを持ちます: `proposal_status` が finalize が必要かを言い、`finalize` は確定価格/条件/ホールドへのセラーコミットメント、`create_media_buy(proposal_id)` はバイヤーの受け入れ/実行。`update_media_buy` リクエストが現在の見積もりエンベロープを超える場合、セラーは proposal-required アクションモードをモデル化する代わりに `REQUOTE_REQUIRED` を返します。`requires_proposal` を含むキャッシュされたプレリリースアクションメタデータを持つバイヤーは、それを破棄し現在のプロダクトまたはバイのアクションサーフェスを再読み取りしなければなりません。3.1 は更新の修正見積もりアーティファクトを定義しません。
→ 仕様: [Media Buy Lifecycle § Action discovery](/docs/media-buy/media-buys/lifecycle#action-discovery) · [Product discovery § Proposals](/docs/media-buy/product-discovery/media-products#proposals) · PR [#4514](https://github.com/adcontextprotocol/adcp/pull/4514)
### Auth + セキュリティ厳格化
4 つの補完的な変更: **`AUTH_REQUIRED` 分割** を `AUTH_MISSING`（correctable — 認証情報でリトライ）と `AUTH_INVALID`（terminal — 認証情報が提示され拒否。ローテートまたはエスカレート。自動リトライしない）に。リカバリー分類は今やオペレーターの現実に一致します。**`CREDENTIAL_IN_ARGS`** 新エラーコード: セラーは、トランスポート認証チャネルの代わりにタスクペイロードにバイヤープリンシパル認証情報を密輸するリクエストを拒否しなければなりません（MUST） — プロンプトインジェクション流出サーフェスを閉じます。**Request-signing `protocol_methods_*` 名前空間** — RFC 9421 署名スコープが AdCP メソッドサーフェスのみに厳格化。**`comply_test_controller` サンドボックスゲート** — すべてのコントローラー呼び出しは `account.sandbox: true` を運ばなければならず（MUST）、セラーはフィールドを信頼するのではなく永続化されたアカウントレコードに対して検証しなければなりません（MUST）。サンドボックスと本番の間の多層防御境界。
→ 仕様: [Error handling § Recovery Classification](/docs/building/by-layer/L3/error-handling#recovery-classification) · PR [#3739](https://github.com/adcontextprotocol/adcp/pull/3739)、[#4057](https://github.com/adcontextprotocol/adcp/pull/4057)、[#4326](https://github.com/adcontextprotocol/adcp/pull/4326)、[#4382](https://github.com/adcontextprotocol/adcp/pull/4382)/[#4392](https://github.com/adcontextprotocol/adcp/pull/4392)
### 冪等性 — Rules 9 + 10 + `IDEMPOTENCY_IN_FLIGHT`
2 つの新しいルールが本番エッジケースを閉じます。**Rule 9（並行リトライ）:** バイヤーが元の呼び出しがキャッシュされたレスポンスを生成する前にリトライするとき、セラーはブロックする代わりに `IDEMPOTENCY_IN_FLIGHT`（新エラーコード）を返してもよい（MAY） — 最初の呼び出しが遅い下流システム（SSP、アドサーバー、支払いプロバイダー）を呼ぶときに有用。バイヤーはそれを transient として扱わなければならず（MUST）、新しい `idempotency_key` を鋳造してはなりません（MUST NOT）。**Rule 10（下流再照合）:** `IDEMPOTENCY_EXPIRED` レスポンスが到着し元が成功した証拠があるとき、バイヤーがどう再照合するかの明示的なガイダンス — 新しいキーを生成する前に自然キーチェック（例: `context.internal_campaign_id` による `get_media_buys`）を行う。**`capabilities.idempotency.in_flight_max_seconds`** 新ケイパビリティ — セラーは、バイヤーがリトライペーシングを調整できるよう、in-flight 呼び出しがどのくらいかかりうるかを宣言。
→ 仕様: [Calling an agent § Idempotency](/docs/protocol/calling-an-agent) · PR [#4402](https://github.com/adcontextprotocol/adcp/pull/4402)、[#4409](https://github.com/adcontextprotocol/adcp/pull/4409)
### TMP IdentityMatch アップグレード
3 つの加算的変更: **`serve_window_sec`** レスポンスの新しい必須フィールド（1–300 秒） — ルーターは再クエリ前にこの秒数だけ適格性決定をキャッシュ。以前の `ttl_sec` フレーミングを frequency-cap-data-flow 認識セマンティクスに置き換え。**`seller_agent_url`** は今やリクエストで必須で、ルーターが決定を発信元セラーにルーティングし戻せる。**`package_ids`** は必須から任意に移動 — ルーターはパッケージを列挙せずに「このユーザーはそもそも適格か？」を尋ねられる。
→ 仕様: [TMP IdentityMatch implementation](/docs/trusted-match/identity-match-implementation) · PR [#4070](https://github.com/adcontextprotocol/adcp/pull/4070)、[#3687](https://github.com/adcontextprotocol/adcp/pull/3687)
### `adagents.json` — マネージドネットワークスケール、manager-domain フォールバック、失効セマンティクス
3 つの本番スケール改善。**マネージドネットワークスケール:** 権威ある `adagents.json` は今や 20 MB を上限とし、大きなエージェントネットワークを公開するマネージャーは、すべてのプロパティをインライン化せずに所有ドメインをリストするコンパクトな `publisher_domains[]` 形式に切り替えます。**Manager-domain フォールバック:** パブリッシャーの権威ある `adagents.json` が欠けているとき、クローラーは `ads.txt` で宣言された `managerdomain` にフォールバックします — 404 を直接返せない S3 / CloudFront ホストのパブリッシャーのディスカバリーギャップを閉じます。**失効セマンティクス:** `revoked_publisher_domains[]` は今や厳密に時間制限されます — 失効は黙った削除ではなく、発見可能なタイムスタンプを伴う公開された事実です。マネージドネットワークをまたいだ信頼伝播を厳格化します。
→ 仕様: [`adagents.json` リファレンス](/docs/governance/property/adagents) · PR [#4504](https://github.com/adcontextprotocol/adcp/pull/4504)、[#4173](https://github.com/adcontextprotocol/adcp/pull/4173)、[#4536](https://github.com/adcontextprotocol/adcp/pull/4536)
### コンプライアンススイート — ケイパビリティゲートシナリオ
ケイパビリティゲートのストーリーボードシナリオにより、セラーは主張するもの *のみ* を実行できます。`frequency_cap_enforcement`、`per_creative_attribution`、`metric_mode` + ROAS（`contains:` マッチャーを使用）、`audience_buy_flow`、`event_dedup_flow`、`performance_buy_flow`（ケイパビリティゲートの CPA バイ）の新しいシナリオ。加えて、宣言されたケイパビリティに実行を条件付けるストーリーボードの新しい `requires` ランタイムゲート — もう all-or-nothing シナリオはありません。完全なセットは [Compliance catalog](/docs/building/compliance-catalog) で列挙されています。
**GA 前後期のコンプライアンス更新:** money-moving セラー専門分野は今や、spend-committing フローの前にベースライン `sync_governance` 登録を実行します: `sales-guaranteed`、`sales-non-guaranteed`、`sales-broadcast-tv`、`sales-catalog-driven`、`sales-social`、`creative-generative` 下の生成セラーフロー。これはすべてのセラーをガバナンス認識にはしません。`governance-aware-seller` は `check_governance` 相談と伝播のためのオプトインクレームのままです。これらの専門分野を主張する既存の GA 前セラーは、3.1 グレーディングで準拠のままであるために `sync_governance` 登録を実装し、複数の `governance_agents` エントリを持つペイロードを拒否しなければなりません。
**コンプライアンスパッケージングクロージャ:** パッケージ化されたコンプライアンスアーティファクトは今や自己完結です。webhook レシーバーエンベロープベクターはバージョン管理されたコンプライアンスツリー下に存在し、作られたベクター/test-kit 参照がパッケージ化された `/compliance/{version}/` バンドルまたはプロトコル tarball 内で解決しないとき、リリース検証が失敗します。シグナル適合性も義務で分割されます: `signal-owned` とベースラインシグナルプロトコルはディスカバリーのみ（`get_signals`）、`signal-marketplace` は `activate_signal` を要求します。
→ 仕様: [Compliance catalog](/docs/building/compliance-catalog) · PR [#4312](https://github.com/adcontextprotocol/adcp/pull/4312)、[#4642](https://github.com/adcontextprotocol/adcp/pull/4642)、[#4664](https://github.com/adcontextprotocol/adcp/pull/4664)、[#4722](https://github.com/adcontextprotocol/adcp/pull/4722)、[#4727](https://github.com/adcontextprotocol/adcp/pull/4727)、[#4731](https://github.com/adcontextprotocol/adcp/pull/4731)、[#5187](https://github.com/adcontextprotocol/adcp/pull/5187)
### 最終仕様の明確化（WG レビューバッチ）
仕様がプレリリース検証を通じて落ち着くにつれ、規範的な厳格化が着地しました。ほとんど低リスク — すでに妥当なデフォルトを推論していた採用者は動作し続ける — が、3.1 グレーダーがそれらをチェックするので知っておく価値があります。
* **`PROPOSAL_NOT_FOUND` エラーコード**（#4043）。プロポーザルライフサイクルエラーカタログを完成（`PROPOSAL_EXPIRED` と `PROPOSAL_NOT_COMMITTED` と並んで）。セラーは、参照された `proposal_id` が認識されないとき — 誤ったテナント、キャッシュから追い出された、決して finalize されなかった — それを返さなければなりません（MUST）。リカバリー: correctable。
* **前方互換の `error.code` デコード**（#4227）。受信者は `error.code` を **オープン enum** として扱わなければなりません（MUST） — 未知のコードを拒否せずにデコードし、`error.recovery` からリカバリーを分類し、リカバリーが欠けているとき `transient` にデフォルト。3.1 以降の送信者は、すべてのエラーで `error.recovery` を投入しなければなりません（MUST）。ピン留めバージョンの受信者を壊さずに、将来の保守ラインでのエラーコードの additive-in-patch のブロックを解除。
* **すべての AdCP タスクリクエストで `idempotency_key` 必須**（#4399）。仕様が idempotency\_key で重複排除すると言うがバイヤーに送るよう要求しなかった長年のギャップを閉じます。セラーは 3.1 GA 後、キーを欠くリクエストを拒否してもよい（MAY）。
* **MCP ツールラッパーはエンベロープフィールドを許容しなければならない**（#4399）。MCP リクエストのプロトコルエンベロープ（`status`、`context_id`、`context`、`task_id`、`timestamp`、`replayed`、`adcp_error`、`governance_context`、`idempotency_key`）は今や「予期しないフィールド」として拒否される代わりにラッパー層を通ります。採用者が MCP を正常に呼ぶためにエンベロープフィールドを省略しなければならなかったラッパー層のバグを閉じます。
* **MCP シリアライゼーション正規化**（#2911）。プロトコルエンベロープスキーマから `payload.required` を落とし、エンベロープレベルに `context` フィールドを追加し、フラット兄弟 MCP ワイヤー形状を明確化（エンベロープとボディフィールドがルートに、ネストされた `payload:` キーなし）。事実上のフラット形状を実装した採用者は影響を受けません。
* **冪等性リプレイは歴史的スナップショットを返す**（#4371）。バイヤーがリプレイウィンドウ内でステートフルな create 呼び出し（例: `create_media_buy`）をリトライするとき、セラーは状態追跡フィールド（`status`、`confirmed_at` など）の **歴史的スナップショット** を返さなければなりません（MUST） — 現在の状態ではなく。そうでなければ at-most-once リトライがバイヤーの下からレスポンスを変異させます。
* **`refine[]` finalize 排他性 + マルチ finalize アトミック性**（#4107）。`get_products` `refine[]` セマンティクスの厳格化: いずれかのエントリが `action: "finalize"` を使うとき、配列のすべてのエントリは `action: "finalize"` でプロポーザルスコープでなければなりません（MUST）。セラーは finalize と非 finalize の混合を `INVALID_REQUEST` で拒否します。複数のプロポーザルにわたるマルチ finalize は、セラーがすべての名前付きプロポーザルにわたってアトミックコミットを保証できるときのみ許されます。そのアトミック性を保証できないセラーは、マルチ finalize 配列を `MULTI_FINALIZE_UNSUPPORTED`（推奨）または `INVALID_REQUEST` で拒否しなければならず（MUST）、バイヤーは緩いコミット保証を受け入れるなら単一プロポーザル finalize 呼び出しをシーケンスできます。
* **`pending_creatives` ステータスの曖昧性解消**（#4196）。説明は今やバイヤーアクションが必要と明示的に述べます — クリエイティブ同期を待つセラーは、ステータス enum 値を発するだけでなく、レスポンスメッセージで何が欠けているか（クリエイティブ数、締め切り）をサーフェスしなければなりません（MUST）。ワイヤー形状を変えずに採用者向け UX を明確化。
* **runner-output-contract の `notices` 助言チャネル**（#4418）。ストーリーボードランナーは、非失敗の助言（例: 「エージェントはまだ非推奨の専門分野をアドバタイズするが、ストーリーボードは合格した」）を実行出力の構造化された `notices[]` フィールドを通じてサーフェスします。助言テキストを運ぶ場当たり的な `skip.detail` 散文 — グレーダーとダッシュボードにパース不能 — を置き換えます。
* **ガバナンスボディレベル `status` のリネーム**（#4897）。`check_governance` レスポンス: `status` → `verdict`（enum 変更なし: `approved` / `denied` / `conditions`）。`report_plan_outcome` レスポンス: `status` → `outcome_state`（enum 変更なし: `accepted` / `findings`）。`get_plan_audit_logs` エントリがカスケード: 一貫性のため `entries[].status` → `entries[].verdict`。MCP フラットオンザワイヤーシリアライゼーション下でエンベロープタスクステータスのためにトップレベル `status` キーを解放（#4876、#2911）。移行: これら 3 つのレスポンス形状のすべてのエミッターとコンシューマーでプロパティをリネーム。値は変わらない。ガバナンスは `x-status` により実験的サーフェスなので、これは GA に先立つ認可された 3.1 ワイヤー形状調整。
* **メディアバイボディレベル `status` 衝突 — additive-deprecate**（#4895）。`create_media_buy` と `update_media_buy` の成功レスポンスが新しいトップレベル `media_buy_status` フィールドを得ます。レガシートップレベル `status: MediaBuyStatus` 形式は `deprecated: true` とマークされ **3.2**（#4906）で削除。コンプライアンスストーリーボードは既に新しいフィールドを要求します。`get-media-buys-response`、`get-media-buy-delivery-response`、`core/media-buy.json` のネストされた `status` はここではスコープ外で、**4.0** カスケード（#4905）で対処。完全な移行: [Migration › `media_buy_status`](/docs/reference/migration/media-buy-status)。
* **プロポーザルライフサイクル、シグナルプライバシーメタデータ、測定ロック。** `proposal_status` はプロポーザルごとの真実の源泉、`supports_proposals` は適合性グレーディング宣言、`finalize` はセラーコミットメント、`create_media_buy(proposal_id)` はバイヤー実行。GA 前の `requires_proposal` アクションモードは、見積もりエンベロープ外の更新のための `REQUOTE_REQUIRED` を優先して削除。`requires_proposal` を含むキャッシュされたプレリリースアクションメタデータを持つバイヤーは、それを無効化し該当するプロダクトまたはバイのサーフェスを再読み取りしなければならない。シグナル定義は Global Privacy Control サポートを宣言せず、`get_signals` 行の投影された `consent_basis` / `art9_basis` 値はプロバイダー宣言のシグナル定義姿勢のまま。測定カタログは実験的のままで、それを実装するエージェントは `experimental_features` に `measurement.core` を宣言。
→ 完全なバッチは 1 コミットとして出荷: PR [#4796](https://github.com/adcontextprotocol/adcp/pull/4796)（`4c124545f1`）。完全な散文については issue ごとのリンクを参照。
### その他のスキーマ追加
**`media_buy.frequency_capping` ケイパビリティ宣言**（#4670） — セラーがどの frequency-cap サーフェスを尊重するかを宣言。
**SDK 生成の人間工学**（#5168） — 一般的なインラインオブジェクトと配列アイテムの形状が今や安定したコアスキーマ名を持つため、SDK はローカルラッパー名を発明しません。`x-adcp-open-payload` は、オープンマップを閉じた型付きモデルに折り畳むのではなく保持する必要のあるジェネレーターのために、意図的にオープンな JSON ペイロードフィールドをマーク。
**オープンコンプライアンスシナリオ文字列**（#5168） — `comply_test_controller.scenario`、`list_scenarios.scenarios[]`、`compliance_testing.scenarios[]` は閉じた enum ではなく `string`。SDK はそれらを文字列としてパースすべきで（SHOULD）、既知値ヘルパーをローカルで重ねてもよい（MAY）。以前これらのフィールドにリテラル共用体を生成した SDK は `string` に広げ、未知のシナリオ名のデフォルト処理を保つべき。
**`x-adcp-hoist` オプトインマーカー**（#4630） — 正準に共有されるオブジェクトスキーマが、共有型に引き上げ可能として自身を宣言。**text-asset-requirements の `allowed_values`**（#4333） — 閉集合テキストアセット（CTA など）が、バイヤーが生成を制約できるよう許可される値を宣言。**`vast_tracker` + `daast_tracker` アセットタイプ**（#3051） — 動画と音声のトラッカーアセット。**`create_media_buy` / `update_media_buy` 成功レスポンスの任意 `currency` + `total_budget`**（#4417）。**`sync_audiences` への非同期エンベロープ**（#4571） — create スタイルタスクから拡張された 3 形状 submitted エンベロープ（Success / Error / Submitted）。
→ PR ごとの詳細については [リリースノート § Version 3.1.0](/docs/reference/release-notes#version-3-1-0) を参照。
## 採用者のアクション
| もしあなたが… | すべきこと |
| ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 3.0 準拠の本番エージェント | 3.0 に留まるために必要なものはなし — 3.1 変更は加算的で 3.0 クライアントは動作し続ける。3.1 を主張する準備ができたら、新しいフィールドを拾い将来のマイナーとの前方互換のため `adcp_version` を発するよう SDK ピンを `"3.1"` に上げる。 |
| 本番キャンペーンを実行するバイヤー | SDK を上げ、セラーが `supported_versions` で `"3.1"` をアドバタイズした後、構築時に `adcpVersion: "3.1"` を渡す。発火漏れを疑うとき `webhook_activity[]` 読み取りを実装。すべての `get_media_buys` ポーリングで `media_buy.health` + `impairments[]` を読む。再照合パイプラインで `impairment.coherence` 不変条件を実装。 |
| 本番バイを実行するセラー | 参照されたリソースがオフラインに遷移するたびに `media_buy.health` + `impairments[]` をサーフェス。`capabilities.media_buy.propagation_surfaces` を正直に宣言。バイヤーがオペレーターの往復なしに統合をエンドツーエンドでデバッグできるよう `webhook_activity[]` を実装 — バイヤーセルフサービスは統合摩擦の削減であり、セラーの慈善ではない。バイヤーが再照合すべきときを知るよう、すべての配信行に `is_final` をマーク。 |
| money-moving 専門分野を主張するセラー | アカウントサーフェスに `sync_governance` を実装し、brand/operator アカウント参照を使ってアカウントごとに 1 つのガバナンスエージェントを登録し、複数の `governance_agents` エントリを持つ登録を拒否。`check_governance` 呼び出しは `governance-aware-seller` も主張するときのみ依然必須。 |
| `verify_brand_claim` または `verify_brand_claims` を実装するブランドエージェント | すべての成功レスポンスで `signed_response` を返す。ブランドごとの `adcp_use: "response-signing"` JWK を公開し、未署名のレスポンスフィールドを `signed_response.payload.response` とバイト等価に保ち、元のリクエストと結果インデックスとともに一括監査証拠を保持。 |
| プロポーザルまたはアクションディスカバリーを使うセラー | プロポーザル実行を `supports_proposals` やアクションモードではなく `proposal_status` からルーティング。`requires_proposal` を発しない。更新が見積もりエンベロープを超えバイヤーが条件を再発見するか別のバイを作らなければならないとき `REQUOTE_REQUIRED` を使う。 |
| キャッシュされたプレリリース `action_mode: "requires_proposal"` 値を持つバイヤー | キャッシュされた値を未知として扱う。それを `requires_approval` にマップしない。そのモードは非同期の人間承認ゲートでプロポーザルアーティファクトを持たない。キャッシュされた値がプロポーザル実行可能性に使われた場合、`get_products` を通じてプロポーザルを再読み取りし `Proposal.proposal_status` で分岐: `draft` はまず finalize、`committed` は `create_media_buy(proposal_id)` の準備完了。プロダクト `allowed_actions[]` またはバイ `available_actions[]` から来た場合、そのキャッシュされたアクションメタデータを無効化し現在のプロダクトまたはバイのアクションサーフェスを再読み取り。 |
| 以前 `data_subject_rights.gpc_honored` を見たプレリリース 3.1 シグナル採用者 | シグナルレベルの権利ルーティングからフィールドを削除。3.1 はシグナル定義で Global Privacy Control サポートを宣言しない。GPC は配信時のパブリッシャー/ビッドストリームの関心事のまま。実装ガイダンスにはプロバイダーポリシー、レジストリ開示、`ccpa_opt_out_url` のような CCPA/州法オプトアウトルーティングを使うが、`data_subject_rights` から GPC 処理を推論しない。 |
| 自己公開権限が欲しいサブブランドチーム | 自身のドメインに Brand Canonical Document として `/.well-known/brand.json` を立てる。`house_domain: ""` を宣言。親ハウスチームに `brand_refs[]` 経由で相互に応じるよう依頼。 |
| ホールセールプロダクトフィードとホールセールシグナルフィードのミラーを維持するコンシューマー（ストアフロント、連合マーケットプレイス、レジストリ） | `get_products buying_mode: "wholesale"` および/または `get_signals discovery_mode: "wholesale"` 経由でブートストラップ。返された `wholesale_feed_version` + `cache_scope` を永続化。後続のポーリングで `if_wholesale_feed_version` を送り、セラーが `unchanged: true` で応答するとき完全ペイロードをスキップ。エージェントが `wholesale_feed_webhooks.supported` を宣言する場合、`sync_accounts.accounts[].notification_configs[]` を通じて変更 webhook を登録。webhook ペイロードをミラーに適用し `applies_to.scope` を追跡して正しいキャッシュ層（public 対 account オーバーレイ）を無効化。`wholesale_feed.bulk_change` または逃したプッシュを `get_products` / `get_signals` の再読み取りで処理。 |
| シグナルエージェント | ミラーリングのため完全な価格付きシグナルフィードを公開するよう `signals.discovery_modes: ["brief", "wholesale"]` を宣言。すべてのレスポンスで `cache_scope` を返す（必須 — スキーマ強制）。`discovery_mode` なしの 3.1 以前の呼び出し元は brief モード動作を得続ける。`signal-owned` のみを主張する場合、`get_signals` ディスカバリーで十分。`activate_signal` も実装するときのみ `signal-marketplace` を主張。 |
| スケールでホールセールフィードミラーを提供するセールス / シグナルエージェント | `wholesale_feed_webhooks.supported: true` を宣言し、標準のアカウントレベル webhook 署名、アクティベーション前のエンドポイント制御証明、SSRF ガード、アカウント/呼び出し元認可チェック、通知設定ファンアウト上限を伴い、`sync_accounts.accounts[].notification_configs[]` を通じた webhook 登録をサポート。`event_types[]` を宣言された修復読み取りと一貫させる: `product.*` はホールセール `get_products`、`signal.*` はホールセール `get_signals` を必要とする。webhook エミッターは、実際に変更されたプロダクト/シグナルペイロードまたは一括変更サマリーを含め、イベント発行時にホールセールタスクと同じ呼び出し元ごとのスコープフィルターを適用しなければならない（MUST） — プリンシパルごとに確実にイベントをスコープできないマルチテナントエージェントはケイパビリティを宣言してはならない（MUST NOT）。 |
| 測定ベンダー（アテンション、ブランドリフト、排出、リテール） | 実験的 `measurement.metrics[]` カタログを AdCP エージェントで公開し `experimental_features: ["measurement.core"]` を宣言。プロダクトごとに `vendor_metric_optimization` を宣言するセラーは今や最適化目標をあなたの `(vendor, metric_id)` ペアにバインドできる。 |
| クリエイティブエージェント | `capabilities.creative.bills_through_adcp` を正直に宣言。帯域外で課金する場合、黙って受け入れるのではなく `BILLING_OUT_OF_BAND` で `report_usage` 呼び出しを拒否。 |
| トランスフォーマーを提供するクリエイティブエージェント | `creative.supports_transformers: true` を宣言し `list_transformers`（`expand_params` オプション列挙モードを含む）を提供。`build_creative` で型付き `config` を厳格に検証 — 未知のキーと範囲外の値をフィールド帰属エラーで拒否、ベンダーノブを `ext` にルーティング、各ターゲットフォーマットがトランスフォーマーの `output_format_ids` のサブセットであることを検証。カタログアイテムやバリアントにわたってファンアウトするときリーフごとの価格領収書を伴う `BuildCreativeVariantSuccess` を返す。レートカードを `Format.pricing_options` から `transformer.pricing_options` に移し `report_usage` を通じて決済。 |
| ホスト音声/動画フォーマットを宣言するセラーまたはクリエイティブエージェント | 固定 duration スロットに `duration_ms_exact`、有界または片側範囲に `duration_ms_range` を使う。`[null, 60000]` は「最大 60 秒」、`[15000, null]` は「少なくとも 15 秒」、`[null, null]` は無効。別個の素の min/max duration フィールドを追加しない。 |
| SDK フィクスチャ、コンプライアンスミラー、リリースパッケージングを保守 | コンプライアンスベクターと test-kit 参照をパッケージ化された `/compliance/{version}/` ツリー内に保つ。欠けているバンドル相対参照をリリースブロッカーとして扱う。 |
| SDK 作者 | バンドルする公開された 3.1 アーティファクトに `published_version` をピン留め。`adcp_version`（リリース精度文字列）と `adcp_major_version`（整数ミラー）を発する。ワイヤー発行前に semver 値をリリース精度に正規化（`"3.1.0"` → `"3.1"`）。自動ダウンシフトではなく `VERSION_UNSUPPORTED` を型付きエラーとしてサーフェス。 |
## 移行
**結論: 破壊的変更なし。加算的のみ。上げるべき。**
すべての 3.1 変更は 3.0 に対して **加算的** です。新しいフィールドは任意で、必須フィールドは削除されず、3.0 準拠クライアントを壊す方法で形状が変わったものはありません。SDK をアップグレードせずに 3.1 セラーに対して実行するバイヤーは動作し続けます — 新しいフィールドが見えないだけです。3.1 バイヤーに対して 3.0 スキーマを実行するセラーは動作し続けます — バイヤーの新しいフィールドは黙って無視されます。
しかし新しいサーフェスは実際の本番問題を解決し、3.0 に留まるほど、3.1 が追加した本番堅牢化なしに運用することになります: webhook 配信デバッグ、依存関係影響の可観測性、課金確定フラグ、アクションディスカバリー、ベンダー証明測定、リリース精度ネゴシエーション。**SDK が準備でき次第上げてください。**
唯一のパブリッシャー可視の動作変更は `brand.json` `trademarks[]` にあります: 自由テキストの `status` / `countries` 値は今や型付き enum / ISO 3166-1 alpha-2 に対して検証されます — 非準拠の値はスキーマエラーとしてサーフェスします。`trademarks[]` が制限のない自由テキストを公開していた場合、3.1 を主張する前に値を正規化してください。
プレリリース 3.1 採用者はプレリリースのみの統合も更新すべきです: ブランド検証成功レスポンスは今や `signed_response` を要求。プロポーザル/アクションコードは一時的な `requires_proposal` アクションモードを削除し更新の再価格設定に `REQUOTE_REQUIRED` を使う必要がある。`requires_proposal` 値をキャッシュしたバイヤーは、それらを `requires_approval` にマップするのではなく該当するプロポーザル、プロダクト、バイのサーフェスを無効化し再読み取りしなければならない。シグナル定義は Global Privacy Control サポートを宣言しない。`signal-owned` 適合性はディスカバリーのみで `signal-marketplace` はアクティベーションクレームのまま。ホスト音声/動画宣言は別個の素の min/max フィールドではなく片側 `duration_ms_range` を使うべき。測定カタログディスカバリーは `measurement.core` の背後で実験的のまま。これらは GA 前のプレリリースクリーンアップ項目で、3.0 破壊的変更ではありません。
**3.1 SDK の検証器義務。** ホールセールフィードミラーリング作業は 3.1 内で 1 つの形状を厳格化します: `cache_scope` はすべての `get_products` / `get_signals` レスポンスでスキーマ必須です（2 層キャッシュの安全プロパティがそれに依存 — [キャッシュ層](/docs/media-buy/task-reference/get_products#cache-layering) を参照）。3.1 以前のセラーはフィールドを正しく省略し、宣言されたバージョンに準拠したままです。3.1 スキーマに対して厳格に検証する SDK は、サーバー宣言の `adcp_version`（3.1 がバージョンネゴシエーションで出荷するのと同じリリース精度メカニズム）に基づいて検証器を選択しなければなりません（MUST）: `adcp_version` が `3.0` で始まるレスポンスについては、3.1 の `cache_scope` 必須制約を緩和しなければなりません（MUST）。これは 3.1 内の厳格化であり 3.0 の破壊ではありません — が、バージョンピン留め検証なしに 3.1 スキーマをハードコードする SDK は正しい 3.0 トラフィックを拒否します。バージョンピン留め検証はすべての 3.x→3.(x+1) 厳格化の正しいパターンです。cache\_scope はそれが負荷を担う最初のケースです。
PR ごとの詳細については [リリースノート § Version 3.1.0](/docs/reference/release-notes#version-3-1-0) を参照。バージョンネゴシエーションケイデンスと 3.1 → 3.2 → 4.0 タイムラインについては [バージョニングとガバナンス § Migration timeline](/docs/reference/versioning#migration-timeline) を参照。