ステータス: 3.1 はリリース済み。 現在の安定マイナー: 3.1、ワイヤーピン
adcp_version: "3.1"。3.0 ラインは "3.0" にピン留めされた既存の統合のためにサポートされたままです。supported_versions でその値をアドバタイズすることを確認した後、本番トラフィックを "3.1" にピン留めしてください。実装準備には 3.0 から 3.1 への移行ガイド を使ってください。
このページは 3.1 マイナーリリースのキュレーションされた採用者概要です。完全な 3.1 変更リスト、PR ごとの詳細、移行表が必要ですか？ 権威あるバージョン記録の リリースノート § Version 3.1.0 と、ロールベースのアップグレードチェックリストの 3.0 から 3.1 への移行 を使ってください。長文の規範的リファレンスについては、下の各見出しのリンクをたどってください。
代わりにメジャーな v2 → v3 の変更を探していますか？ What’s New in AdCP 3 を参照。このページは 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_optionsper_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。バイヤーは数が動かなくなるときを知り、請求書を再照合できます。
adagents.json スケーリング作業の長い裾野 — 下の見出しリストを参照。
一目で
ケイパビリティスロット移行ノート
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 § 分散型公開 · PR #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 · Security § 指定タスクレスポンス署名 · PR #4540、#4603、#5192
依存関係影響 webhook とスナップショット整合性
メディアバイが依存するリソースがオフライン状態に遷移するとき — オーディエンス停止、承認後のクリエイティブ停止/拒否、カタログアイテム撤回、イベントソース静止、プロパティ公開停止 — バイヤーは 2 つの並行サーフェスを通じてそれを見ます:- スナップショット。
media_buy.healthがokからimpairedに切り替わる。media_buy.impairments[]がすべてのオフラインリソースをその package_ids、遷移、reason_code、修復ヒントとともにリストする。次のget_media_buys読み取りが現在の真実を示す。 - ログ。
notification-type: impairmentwebhook が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 · スナップショットとログコントラクト · 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 を返して見えない」というブラックボックスはもうありません。純粋なセルフサービス: バイヤーはオペレーターの往復なしに自身の統合をデバッグします。
→ 仕様: スナップショットとログコントラクト · Webhooks § 永続チャネルコントラクト · 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_productsbuying_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 · get_products § ホールセールフィードバージョニング · get_products § キャッシュ層 · get_signals § ホールセールシグナルフィード · PR #4761（条件付きフェッチ）、#4762（ホールセールシグナル）、#4763（フィード webhook）、#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 · Targeting § signal_targeting_groups · get_signals · PR #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のままです。
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 で追跡されます。
後方互換性。 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="…") は、<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 が優先されます。
→ 仕様: 正準フォーマット · PR #3307、#4770、#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を優先して 非推奨 です。
list_transformers · build_creative · get_adcp_capabilities § creative features / evaluator support
リリース精度バージョンネゴシエーション — リリースをピン留め
すべてのリクエストとレスポンスは今や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 · PR #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 · PR #4668、#4669、#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 対プルの非対称頻度を正直に宣言できます。
→ 仕様: 配信メトリクスリファレンス · PR #4618、#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 · report_usage · PR #4735、#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 · Product discovery § Proposals · PR #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 · PR #3739、#4057、#4326、#4382/#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 · PR #4402、#4409
TMP IdentityMatch アップグレード
3 つの加算的変更:serve_window_sec レスポンスの新しい必須フィールド（1–300 秒） — ルーターは再クエリ前にこの秒数だけ適格性決定をキャッシュ。以前の ttl_sec フレーミングを frequency-cap-data-flow 認識セマンティクスに置き換え。seller_agent_url は今やリクエストで必須で、ルーターが決定を発信元セラーにルーティングし戻せる。package_ids は必須から任意に移動 — ルーターはパッケージを列挙せずに「このユーザーはそもそも適格か？」を尋ねられる。
→ 仕様: TMP IdentityMatch implementation · PR #4070、#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 リファレンス · PR #4504、#4173、#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 で列挙されています。
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 · PR #4312、#4642、#4664、#4722、#4727、#4731、#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_productsrefine[]セマンティクスの厳格化: いずれかのエントリが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。 - プロポーザルライフサイクル、シグナルプライバシーメタデータ、測定ロック。
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を宣言。
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 を参照。
採用者のアクション
移行
結論: 破壊的変更なし。加算的のみ。上げるべき。 すべての 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 層キャッシュの安全プロパティがそれに依存 — キャッシュ層 を参照）。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 を参照。バージョンネゴシエーションケイデンスと 3.1 → 3.2 → 4.0 タイムラインについては バージョニングとガバナンス § Migration timeline を参照。