一覧
新機能
Trust surface: idempotency, request signing, and signed governance
3.0 は、3 つの運用規律を一級のプロトコルプリミティブに変えることで、エージェント間トランザクションを実際の資金に対して安全にします。idempotency_key はすべての変更リクエストで必須です。 バイヤーは論理操作ごとに新しいキーを生成します — スキーマは ^[A-Za-z0-9_.:-]{16,255}$ を要求し、AdCP Verified はさらに暗号学的にランダムな UUID v4 を要求します。セラーは get_adcp_capabilities で重複排除セマンティクスを adcp.idempotency = { supported: true, replay_ttl_seconds: <1h–7d、24h 推奨> } または { supported: false } として宣言します。supported: true のとき、リプレイは安全です: セラーは厳密なリプレイで replayed: true を、同じキーが異なるペイロードを伴うとき IDEMPOTENCY_CONFLICT を、TTL 後に IDEMPOTENCY_EXPIRED を返します。supported: false のとき、idempotency_key の送信は no-op です — 素朴なリトライは二重処理します — バイヤーは支出コミット操作をリトライする前に自然キーチェック（例: get_media_buys に加え context.internal_campaign_id などのリクエストコンテキストや context.buyer_ref などのパッケージコンテキスト）を使わなければなりません（MUST）。クライアントはデフォルトを想定してはなりません（MUST NOT）。このブロックを欠くセラーは非準拠です。supported: true は信頼を担うクレームであるため、適合性ランナーは意図的なペイロード変異リプレイでこれをプローブします — サポートを主張するセラーは、宣言が検証済みと見なされる前にこのプローブに合格しなければなりません（MUST）。
RFC 9421 HTTP Message Signatures は 3.0 では任意、AdCP Verified では必須です。 エージェントは、正規化されたカバードコンポーネントリスト（メソッド、ターゲット URI、content-digest、プロトコルレベルフィールド）に対して Ed25519 で変更リクエストに署名します。仕様は sf-binary エンコーディングと URL 正規化をピン留めするため、独立した実装がビット単位で同一の正規入力を生成します。15 ステップの検証チェックリストがセラーのパスを定義します: alg 許可リスト、keyid の暗号前上限（無制限検証に対する防御）、SSRF 検証済みフェッチによる JWKS 解決、jti リプレイ重複排除、オーディエンスバインディング。static/compliance/source/test-vectors/request-signing/ の公開テストベクターにより、実装者はオフラインで正しさを検証できます。
Webhook は同じ RFC 9421 プロファイルで署名され、セラーにベースライン必須です。 Webhook 認証は、リクエスト署名の対称バリアントとして AdCP 9421 プロファイルに統一されます: セラーは、jwks_uri の JWKS（brand.json の agents[] 経由で発見可能）に公開された鍵でアウトバウンド webhook リクエストに署名します。新しい署名者は webhook 配信に adcp_use: "request-signing" を使います。非推奨の adcp_use: "webhook-signing" 鍵は互換ウィンドウ中は受け入れられ続けます。webhook 専用の鍵素材を望むオペレーターは別個の request-signing kid を公開します。共有シークレットはワイヤーを越えません。バイヤーはセラーの JWKS を使って署名を検証します。14 ステップの webhook 検証者チェックリスト — セキュリティガイド で文書化 — は、信頼アンカーのスコープ、ダウングレードとインジェクションの耐性、keyid ごとのリプレイ重複排除（keyid あたり 10 万、集計 1000 万）をカバーします。検証失敗はそこで定義される型付き理由コードを返します。HMAC-SHA256 は 3.x を通じてレガシーフォールバックのままです（push_notification_config.authentication.credentials 経由でオプトイン）。authentication オブジェクト全体は 4.0 で削除されます。
すべての webhook ペイロードは必須の idempotency_key を運びます。 Webhook は at-least-once 配信を使うため、受信者は重複排除しなければなりません。すべての webhook ペイロード — MCP、コレクションリスト変更、プロパティリスト変更、コンテンツ標準アーティファクト、権利失効 — は、同じイベントのリトライ間で安定した、送信者生成の暗号学的にランダムな UUID v4 idempotency_key を運びます。リクエスト側フィールドと同じ名前と形式です。予測可能なキーは受信者の重複排除キャッシュに事前シードして正当なイベントを抑制することを許すため、セラーは暗号ソースからキーを生成しなければなりません（MUST）。
governance_context は署名付き JWS です。 ガバナンスエージェントがプランを承認するとき、不透明な文字列ではなく、ガバナンスエージェントの鍵で署名された JWS を返します。バイヤーはそれをメディアバイエンベロープでエコーします。セラーはガバナンスエージェントの JWKS（sync_governance 経由で解決）を使って署名を検証し、ラウンドトリップなしに決定を特定のバイヤー、プラン、フェーズ、時間にバインドします。古いまたは偽造された決定はトランスポート層で拒否されます。プランにガバナンスエージェントが設定されている場合、セラーは予算をコミットする前に check_governance を呼び出さなければならず（MUST）、有効な governance_context を欠く支出コミットを PERMISSION_DENIED で拒否しなければなりません（MUST）。
コンプライアンスランナーがこれらすべてを検証します。 すべてのエージェントは、主張するプロトコルや専門分野に関係なく /compliance/{version}/universal/security.yaml を実行します — 未認証の拒否、API キーの強制、RFC 9728 に従う OAuth ディスカバリー、オーディエンスバインディングをカバー。署名を宣言するエージェントは signed_requests と signed_webhooks のハーネスを実行します: 正常フロー、改ざん（ヘッダーインジェクション、ボディ変異、タイムスタンプスキュー）、リプレイ（jti 再利用）、keyid 暗号前上限パス。ランナー出力は、改ざんが検出可能になるようテストキットコーパスに対するハッシュチェーンを持つ、構造化された検証可能な runner-output.json アーティファクトです。
インスタンス間の状態永続化が仕様要件になりました。 エージェントの状態 — タスク、メディアバイ、プラン、署名付きアーティファクト、冪等性キー — は、水平スケールされたインスタンス間で永続的でなければなりません（MUST）。メモリのみの状態は本番で非準拠です。
完全な脅威モデル、プリンシパルの役割（ブランド / オペレーター / エージェント）、ステップバイステップの検証パスについては セキュリティ実装ガイド を参照。
Security implementation
脅威モデル、署名プロファイル、検証パス、ユニバーサルセキュリティストーリーボード。
Specialisms and storyboard-driven compliance
ストーリーボード — エージェントが合格しなければならないスクリプト化されたコンプライアンスシナリオ — は、スキーマとタスク定義とともに/compliance/{version}/ のプロトコル内に存在するようになりました。エージェントは get_adcp_capabilities で 2 つを宣言します。
supported_protocols— 広範なドメインクレーム（media_buy、creative、signals、governance、brand、sponsored_intelligence）。それぞれエージェントをドメインのベースラインストーリーボードにコミットします。specialisms— 6 ドメインにわたる 19 の狭い機能クレーム。例:sales-guaranteed、sales-broadcast-tv、creative-generative、property-lists、signal-marketplace、brand-rights。それぞれ 1 つの親プロトコルにロールアップします。
/protocol/{version}.tgz のバージョンごとのプロトコル tarball により、クライアントはスキーマ、ストーリーボード、例を 1 回のリクエストで一括同期できます。
AdCP Verified は 3.0 では自己証明です。 エージェントはストーリーボードスイートを実行し、テストキットコーパスに対するハッシュチェーンを持つ署名付き
runner-output.json を公開します。AAO は出力を監査せず、発行をゲートしません — Verified スタンプは「このエージェントは合格したランナー出力を公開した」を意味し、「監査人がクレームを確認した」ではありません。検証する当事者（バイヤー、インテグレーター、規制当局）は、参照されるストーリーボードに対して任意のクレームを再実行し、出力ハッシュを比較できます。コンプライアンスランナーとストーリーボード自体は 3.0 で出荷されるソフトウェアです — バグ、カバレッジのギャップがあり、いくつかの場所ではワーキンググループがまだ正確なルールを洗練している仕様の意図についての最善の推測をエンコードしています。実装者がストーリーボードの失敗を見たとき、3 つの可能性があります: エージェントにバグがある、ストーリーボードにバグがある、または仕様が曖昧である。3 つすべてが提起する正当な問題です。なぜ 3.0 で自己証明で監査ではないか: AAO が運営する参照実装 — トレーニングエージェントと @adcp/sdk / Python / Go SDK — はまだ 3.0 ストーリーボードスイートに対して完全にクリーンではありません。トレーニングエージェントは現在、適用可能な 55 のストーリーボードのうち 32 に合格しています。SDK のカバレッジも同様です。私たちは 3.0 → 3.1 のウィンドウで 4〜6 週間のケイデンスでこれらの合格率を 100% に近づけています。参照実装がクリーンに合格し、残りの仕様の曖昧さが解決されたとき、正式な AdCP Verified プログラムが 3.1 で開始します — エージェントは AAO による独立した再実行のためにランナー出力を提出でき、検証済みエージェントのパブリックレジストリを備えます。3.0 での自己証明は橋であり、最終状態ではありません。Compliance Catalog
ステータスフラグとストーリーボードソースを持つドメインと専門分野の完全なインデックス。
ブランドプロトコル
/.well-known/brand.json によるバイサイドアイデンティティ。パブリッシャーが adagents.json でプロパティと認証済みエージェントを宣言するのと同様に、ブランドは brand.json でアイデンティティ、ブランド階層、認証済みオペレーターを宣言します。
4つのバリアント: House Portfolio（完全なブランド階層をインライン）、Brand Agent（MCP 経由で動的）、House Redirect（サブブランドからハウスドメインへ）、Authoritative Location（ホストされた URL）。
任意のドメインが与えられると、プロトコルは正規ブランドに解決する:
authorized_operators を確認）、レポーティングロールアップ（キャンペーンをハウスでグループ化）。
ブランドプロトコル
brand.json バリアント、解決フロー、ブランドアイデンティティを含む完全な仕様。
ブランド権利ライフサイクル
ブランドとコンテンツオーナー間のライセンスと使用権のための3つのタスク:
権利にはジェネレーション資格情報（ライセンスされたコンテンツにアクセスするための API キーまたはトークン）、クリエイティブ承認 Webhook（クリエイティブがレビューに提出されたときの HMAC-SHA256 認証コールバック）、取り消し通知が含まれます。プロトコルは実行可能な拒否（修正して再送信）と最終的な拒否（再試行しない）を区別します。
brand.json の構造化された visual_guidelines は権利を補完し、ジェネラティブクリエイティブシステムに写真スタイル、グラフィック要素、構成、モーション、ロゴ配置、カラーウェイ、タイプスケール、制限のための構造化ルールを提供します。
ブランド権利
権利の発見、取得、管理のタスクリファレンス。
番組とエピソード
プロダクトはポッドキャスト、TV シリーズ、YouTube チャンネルなどの永続的なコンテンツプログラムをshows で参照できるようになりました。shows は publisher_properties と同じパブリッシャースコープのセレクターパターンに従う。番組はパブリッシャーの adagents.json で宣言され、プロダクトはパブリッシャードメインと番組 ID で参照します。バイヤーは adagents.json から完全な番組オブジェクトを解決します。番組にはクロスセラーマッチングのための配信識別子、エピソードライフサイクル状態（scheduled、tentative、live、postponed、cancelled、aired、published）、ブレークベースの広告インベントリ設定、brand.json へのタレントリンク、国際コンテンツレーティングシステムが含まれます。
番組は関係（スピンオフ、コンパニオン、続編、前編、クロスオーバー）と派生コンテンツ（クリップ、ハイライト、リキャップ）をサポートし、包括的なコンテンツモデリングを実現します。
番組とエピソード
番組スキーマ、エピソードライフサイクル、ブレークベースのインベントリを含む完全な仕様。
レジストリ API
AgenticAdvertising.org レジストリはブランドとプロパティの解決、エージェント探索、認証検証のためのパブリック REST API を提供します。ほとんどのエンドポイントは認証不要です。
レジストリはプロトコルを補完する: REST API でエンティティを解決し、MCP/A2A タスクでトランザクションを実行します。
レジストリ API
認証とレート制限を含む完全なエンドポイントリファレンス。
プロポーザルとデリバリー予測
パブリッシャーはプロダクトと共にプロポーザル（バイヤーがcreate_media_buy で直接実行できるパーセンテージベースの予算配分を持つ構造化メディアプラン）を返せる。プロポーザルはパブリッシャーの専門知識を体現し、アドホックなプロダクトリストを実行可能な購買戦略に置き換える。セッション継続性によりリファインメントができる — 同じセッション内での後続の get_products 呼び出しが会話履歴を引き継ぐ。
デリバリー予測はプロポーザルと配分に付属します。各予測には支出が増えるにつれてデリバリーがどのようにスケールするかを示すメトリック範囲（low/mid/high）を持つ予算ポイントが含まれます。3つの予測メソッド: estimate（大まかな近似）、modeled（予測モデル）、guaranteed（契約でコミット済み）。予測はデリバリーメトリック（インプレッション、リーチ、GRP）と成果（購入、リード、アプリインストール）を予測できます。TV とラジオの予測は GRP ベースのプランニングのために demographic_system と demographic を使用します。
プロポーザルと予測
予算カーブ、CTV、リテールメディア、放送オーディオの例を含む完全なドキュメント。
アカウント
sync_accounts によるバイヤーとセラー間の正式な請求関係。
4つのエンティティ:
2つの請求モデル:
operator（オペレーターまたはブランドが直接購買して請求されます）と agent（エージェントが請求を統合）。2つの信頼モデル: エージェント信頼（デフォルト、エージェントがブランド/オペレーターを宣言）とオペレータースコープ（セラーがオペレーターレベルの資格情報を要求）。
ワークフロー: get_adcp_capabilities -> sync_accounts -> account 付きの get_products -> account 付きの create_media_buy。
アカウントプロトコル
アカウントプロトコルの概要: アイデンティティ検証、請求モデル、決済。
カタログ
sync_catalogs によるファーストクラスのカタログライフサイクル。13のカタログタイプ: 構造的（offering、product、inventory、store、promotion）と業界垂直型（hotel、flight、job、vehicle、real_estate、education、destination、app）。垂直型には Google Ads、Meta、LinkedIn、Microsoft フィード仕様から引用した正規のアイテムスキーマがあります。
フォーマットは必要なカタログを catalog_requirements で宣言します。クリエイティブはアセットにアイテムを埋め込む代わりに、catalog_id で同期されたカタログを参照します。カタログはアトリビューション整合のために conversion_events と content_id_type を宣言します。
カタログ
カタログタイプ、同期ワークフロー、フォーマット要件、コンバージョンイベントを含む完全なドキュメント。
ケイパビリティ探索
get_adcp_capabilities は adcp-extension.json と MCP エージェントカードの両方をランタイムケイパビリティ探索に置き換える。サポートされるプロトコル、アカウント請求モデル、ポートフォリオ情報、ターゲティングシステム、ガバナンス機能を返す — すべてスキーマ検証済み。
get_adcp_capabilities
リクエスト/レスポンススキーマを含む完全なタスクリファレンス。
ガバナンスプロトコル
ブランドスーツアビリティとインベントリキュレーション。ガバナンスエージェントはプロパティリスト（ターゲティングまたは除外のためのプロパティのキュレートされたセット）とコンテンツスタンダード（カテゴリごとのブロック/許可ルールを持つブランドスーツアビリティポリシー）を管理します。バイヤーはフィルタリングされたインベントリ探索のためにget_products にプロパティリストを渡し、ブランドとガバナンスエージェント間の共同調整のために calibrate_content を使用します。ガバナンスエージェントはクリエイティブポリシーで provenance_required を強制でき、プロベナンスクレームの verification 配列を介したサードパーティ AI コンテンツ検証をサポートします。
キャンペーンガバナンスは sync_plans、check_governance、report_plan_outcome、get_plan_audit_logs によるプランレベルのポリシーと予算執行でこれを拡張します。ガバナンスエージェントは audit、advisory、enforce モードで動作でき、委譲された権限に対してセラーサイドのアクションを検証し、共有ポリシーレジストリを通じて標準化されたポリシーを解決します。
ガバナンスプロトコル
プロパティリスト、コンテンツスタンダード、キャリブレーションを含む完全な仕様。
スポンサードインテリジェンスプロトコル
AI アシスタントでの会話型ブランド体験。SI は AI アシスタントが会話の流れを断ち切ることなく、リッチなエンゲージメント（テキスト、音声、UI コンポーネント）のためにブランドエージェントをどのように呼び出すかを定義します。セッションは同意優先モデルに従う: ユーザーが興味を表明し、同意を付与すると、ブランドエージェントがオプションのトランザクション引き渡しとともに会話的にエンゲージします。SI チャットプロトコル
セッションライフサイクル、エージェントの実装、ホストの実装を含む完全な仕様。
データプロバイダーのシグナルカタログ
データプロバイダーはパブリッシャーがプロパティを宣言するのと同じパターンに従い、adagents.json でシグナルカタログを公開できます。
シグナルは型付きターゲティングを持つ明示的な
value_type（バイナリ、カテゴリ、数値）と、データプロバイダーのカタログを参照する構造化された signal_id オブジェクトを持ちます。
データプロバイダーガイド
シグナルカタログ公開のための完全な実装ガイド。
rc.1 から rc.2 のハイライト
このページは v2 → v3 の全シフトをカバーします。すでに3.0.0-rc.1 を採用している場合、アップグレード前に確認すべき最も重要な rc.2 の変更点は以下のとおり。
クリエイティブワークフローとライブラリの変更
build_creative はインラインプレビュー（include_preview）、マルチフォーマット出力（target_format_ids）、品質ティア、カタログ駆動の item_limit、オプションの concept_id、media_buy_id、package_id、macro_values を持つ creative_id を使ったライブラリ取得をサポートします。preview_creative も品質コントロールを追加します。クリエイティブライブラリ操作は明示的にクリエイティブプロトコルタスクになった: list_creatives と sync_creatives はクリエイティブライフサイクルの残りとともにあり、ケイパビリティ探索はバイヤーが意図的にリクエストをルーティングできるように supports_generation、supports_transformation、has_creative_library を追加します。
プランニング、アカウント、サンドボックスの改良
account_resolution が削除され、バイヤーは require_operator_auth を使って認証とアカウントモデルを判定します。サンドボックスサポートは account.sandbox に移動し、サンドボックスは暗黙的なアカウントフローの自然なアカウントキーに参加できます。プロダクト探索は preferred_delivery_types、exclusivity、time_budget を追加し、セラーがリクエストされた予算内で完了できない場合はレスポンスに incomplete を返します。パッケージとプロダクト配分はパッケージレベルの start_time / end_time を持てるようになり、delivery_measurement はプロダクトでオプションになりました。
コンプライアンスとガバナンスの改良
クリエイティブコンプライアンスに位置と期間に加えてディスクロージャー持続性のセマンティクスが含まれ、フォーマットが強制できる持続性モードを宣言できるようになりました。キャンペーンガバナンスも rc.2 でsync_plans、check_governance、report_plan_outcome、get_plan_audit_logs、正規のプラン抽出のための governance_context とともに追加されました。
網羅的な rc.2 の変更リストはリリースノートと CHANGELOG.md を参照。
rc.3 to 3.0 highlights
rc.3 からアップグレードしますか？ 破壊的変更の表、変更前後の例、移行ステップについては rc.3 → 3.0 プレリリースアップグレードノート を参照。
Specialisms and compliance catalog
ストーリーボードは、get_adcp_capabilities の新しい specialisms フィールドとともに /compliance/{version}/ のプロトコル内に移動します。21 の専門分野が 6 ドメインにロールアップします。4 つの 3.1 アーキタイプが status: preview で出荷されます。Compliance Catalog を参照。リネーム: broadcast-platform → sales-broadcast-tv、social-platform → sales-social。マージ: property-governance + collection-governance → inventory-lists。昇格: sponsored_intelligence 専門分野 → 完全なプロトコル。
Capabilities model simplification
機能モデルは 3.0 で合理化されます: 冗長なブールゲートが削除されます。get_adcp_capabilities に content_standards オブジェクトが存在すれば、エージェントはコンテンツ標準をサポートします — 別個のブールは不要です。
reporting_capabilities はすべてのプロダクトで必須になりました。ジオ機能フィールドは型付き形状を保ちます: geo_countries と geo_regions はブール、geo_metros と geo_postal_areas は構造化オブジェクト。
削除されたフィールドの完全なリストと移行ステップについては プレリリースアップグレードノート を参照。
Governance across purchase types
キャンペーンガバナンスはメディアバイを超えて、ブランド権利ライセンス、シグナル有効化、クリエイティブサービス — 予算やポリシールールが適用される任意の購入 — をカバーするよう拡張されます。governance_context が、キャンペーンのライフサイクル全体でガバナンスアクションを結び付ける識別子として media_buy_id を置き換えます。check_governance と report_plan_outcome の purchase_type フィールドが被管理アクティビティを区別します。
GOVERNANCE_DENIED error and schema consistency
GOVERNANCE_DENIED が、修正可能な回復を伴う標準エラーコードに追加され、ガバナンスで拒否された操作が構造化エラーを返せるようになります。ガバナンス、コレクション、プロパティ、スポンサードインテリジェンス、コンテンツ標準のプロトコルにわたるすべてのリクエスト/レスポンススキーマは、アプリケーションメタデータとプロトコル拡張のための任意の context と ext フィールドを得ます。signal_id は get_signals レスポンスのシグナルアイテムで必須になりました。comply_test_controller スキーマは、oneOf ユニオンから scenario 判別子を持つフラットオブジェクトにフラット化されます。
Per-request version declaration
すべてのリクエストスキーマにadcp_version（リリース精度、例: "3.1"）が含まれるようになり、v3 バイヤーがペイロードがどのリリースに準拠するかを宣言できます。セラーは get_adcp_capabilities のアドバタイズされた adcp.supported_versions 配列に対して検証し、すべてのレスポンスでエンベロープルートに adcp_version をエコーします。サポートされないリリースは VERSION_UNSUPPORTED を返します。省略された場合、セラーは最高のサポートバージョンにデフォルトします。
3.1 は後方互換のレガシーフィールドとして adcp_major_version（整数）も保持しますが、今後はリリース精度の adcp_version が主要なワイヤーフィールドです。ネゴシエーションコントラクト、移行タイムライン、SDK ピン留めの例については バージョンネゴシエーション を参照。
注: 両フィールドは v3 のみです — v2 クライアントはいずれも設定できません（フィールドは v2 スキーマに存在しません）。マルチバージョンセラーは、これらのフィールドではなく構造的な手がかり（buying_mode の欠如、fixed_rate 対 fixed_price、geo_postal_codes 対 geo_postal_areas など）で v2 ペイロードを検出します。
Collection lists
コレクションリストは、ブランドセーフティをプロパティからコンテンツプログラムに拡張します。プロパティリストと同様、コレクションリストは厳選されたセットですが — 番組、シリーズ、その他のコンテンツプログラムを、クロスパブリッシャーマッチングのための配信識別子（IMDb、Gracenote、EIDR）を使ってプラットフォーム横断でターゲットします。 新しいターゲティングオーバーレイフィールドcollection_list と collection_list_exclude が、包含と除外の両方のターゲティングを可能にします。新しいジャンルタクソノミー enum が、バイヤーとセラー間でジャンル分類を正規化します。
Collection lists
コレクションリストの作成と管理のタスクリファレンス。
Broadcast TV support
リニア TV セラーが完全に AdCP に参加できるようになりました。このリリースは、放送をデジタルから区別するプロトコルプリミティブを追加します。- 放送クリエイティブ識別子 — クリエイティブアセットとマニフェスト上の
industry_identifiers、creative-identifier-typeenum（ad_id、isci、clearcast_clock、idcrea）付き。放送クリエイティブは、関連するワークフローで使われるトラフィックまたはクリアランス識別子を運び、スポットをローテーション指示とトラフィックシステムに結び付けます。 - 放送スポットフォーマット — :15、:30、:60 スポットの参照フォーマット。動画ファイルのみ — VAST なし、インプレッショントラッカーなし、クリックスルー URL なし。フォーマットにトラッカーアセットスロットがないことは、サードパーティピクセル追跡がサポートされないことを示します。
- Agency Estimate Number — メディアバイとパッケージ上の
agency_estimate_number。放送オーダーをエージェンシーメディアプランと課金に結び付ける財務参照。 - 測定ウィンドウ — Live、C3、C7 の成熟のための
reporting_capabilities上のmeasurement_windows。billing_measurement上のmeasurement_windowが、保証がどのウィンドウに対して照合されるかを宣言します。 - 配信データの完全性 — パッケージごとの配信データ上の
is_finalとmeasurement_window。バイヤーは、数値が暫定か確定か、どの測定ウィンドウを表すかを知ります。成熟するデータを持つ任意のチャネル（放送、ポッドキャスト、ロングテールコンテンツ）に適用されます。
Broadcast TV
スポットフォーマット、クリエイティブ識別子、測定ウィンドウ、放送が CTV とどう異なるかをカバーするチャネルガイド。
Structured measurement terms
保証型バイは正式な交渉サーフェスを得ます:measurement_terms が課金測定ベンダー、IVT しきい値、ビューアビリティ下限を定義します。セラーはプロダクトでデフォルトを宣言し、バイヤーは create_media_buy でオーバーライドを提案し、セラーは受け入れ/拒否/調整します。cancellation_policy スキーマが保証型プロダクトの予告期間とペナルティを宣言します。
Unified vendor pricing
価格モデルはシグナルからクリエイティブ、ガバナンス、プロパティリストエージェントに拡張されます。クリエイティブエージェントはlist_creatives と build_creative レスポンスで pricing_options[] を返します。プロパティリストは pricing_options[] を運びます。すべてのベンダー価格は共有の vendor-pricing-option.json スキーマ（cpm、percent_of_media、flat_fee）を使います。
Offline reporting delivery
セラーはreporting_delivery_methods 経由で get_adcp_capabilities にオフラインレポート配信方法（SFTP、S3、GCS、Azure Blob）を宣言できます。アカウントはファイル配信用の reporting_bucket を指定します。プロダクトは reporting_capabilities で supports_offline_delivery を宣言します。ファイル形式には CSV、JSON、Parquet、Avro、ORC が含まれます。
Trusted Match Protocol extensions
TMP は、プロバイダーエンドポイント、機能、ライフサイクルステータス（active/inactive/draining）、プロバイダーごとのタイムアウト予算を形式化するプロバイダー登録スキーマ（provider-registration.json）を得ます。GET /health エンドポイントがルーター側のヘルス監視を可能にします。TMPX は、国分割されたアイデンティティ解決とマクロ接続性を伴うエクスポージャー追跡を追加します。
Identity Match リクエストは、単一の user_token + uid_type ペアの代わりに identities 配列（リクエストあたり 1〜3 トークン）を受け入れるようになりました。パブリッシャーは持っているすべてのアイデンティティトークンを送り、バイヤーは一致するグラフで解決します。ルーターはプロバイダーごとに identities をフィルターし（最小必要データ）、転送前に再署名します — 転送されるセットはパブリッシャーが送ったもののサブセットでなければなりません。RFC 8785 JCS 正規化が署名とキャッシュキー導出の両方に使われ、consent_hash が同意状態でキャッシュを分割します。rampid_derived が uid-type enum に追加されます。
TMP は 3.0 でプレリリースのままです。安定サーフェスは 3.1.0 を目標としています。
Brand schema extensions
brand.json は、ブランド関連エージェントを宣言する汎用 agents 配列、ビジュアルトークン（border_radius、elevation、spacing、拡張カラーロール）、weight、style、stretch、optical_size、usage フィールドを持つ構造化フォント定義を得ます。
Required tasks reference
新しい プロトコル別の必須タスク リファレンスページが、エージェントの役割別にすべての AdCP プロトコルにわたる必須、条件付き、任意のタスクを統合します — 実装が最小サーフェスをカバーするか検証する単一ページ。Experimental surfaces
AdCP 3.0 は、3.x 安定性保証の下で安定サーフェスのコアを出荷し、コアプロトコルの一部だがまだ凍結されていない 4 つのサーフェスを追加します。これらのサーフェスは、卒業パスを形作る本番エンゲージメントでそれらを運用するデザインパートナー — OpenAds、Scope3、Yahoo、ONX、Triton Digital — と共同開発されています。実験的サーフェスはスキーマにx-status: experimental を運び、それらを実装するセラーは get_adcp_capabilities の experimental_features で機能 id を宣言します。それらは少なくとも 6 週間の予告をもって 3.x リリース間で変更される可能性があります。
実験的ラベルは意図的にスコープされています — 3.0 の他のすべては通常の 6 か月の非推奨予告に従います。完全なコントラクト、卒業基準、クライアントガイダンスについては 実験的ステータス を参照。
Signal pricing: custom escape hatch
ベンダー価格は、cpm、percent_of_media、flat_fee、per_unit に加えて custom モデルを得ます。人間可読な description と構造化 metadata オブジェクトを要求します。バイヤーはコミットメント前にカスタム価格をオペレーターレビューに通すべきです（SHOULD）— 自動選択は推奨されません。
動機: パフォーマンスキッカー、段階的ボリューム、ハイブリッド（flat + CPM）、成果共有価格はすでに現場に現れています。今エスケープハッチを出荷することで、実際のデプロイが列挙されたモデルで表現できない構成に遭遇したときのレトロフィットの痛みを避けます。構造化メタデータは、新しいパターンごとのスキーマ変更なしにモデルを機械検査可能に保ちます。
破壊的変更
メディアチャンネルタクソノミー
v2 の 9 チャンネルが 20 のプランニング指向チャンネルに置き換えられます。5つのチャンネルはそのまま（display、social、ctv、podcast、dooh）。残りの4つは分割、削除、または名前変更されました。
v3 の新チャンネル（v2 に相当なし）:
search、linear_tv、radio、streaming_audio、ooh、print、cinema、email、gaming、retail_media、influencer、affiliate、product_placement、sponsored_intelligence。
gaming チャンネルはゲーム内インリンシック広告、リワード動画、プレイアブル広告をカバーします。ゲームアプリのリワード動画は olv に分類することもできる — インベントリがゲーミング予算から来る場合は gaming を使用します。チャンネルの詳細
各 v2 チャンネル、マルチチャンネルプロダクト、ケイパビリティ探索の例を含む完全なマッピングガイド。
価格オプションフィールドの名前変更
v3 はハード制約（パブリッシャーが適用する価格）とソフトヒント（過去のパーセンタイル）を分離します。fixed_rate は fixed_price になり、price_guidance.floor はトップレベルの floor_price に移動します。
これらのフィールドは標準的なディールタイプにマッピングされます:
fixed_price はプログラマティックギャランティード（PG）とプリファードディールに、floor_price はプライベートマーケットプレイス（PMP）オークションに対応します。オープンオークションインベントリは両方のフィールドを省略します。
価格の詳細
固定価格とオークションの例、価格ガイダンスのスキーマ、フラットレート価格、最低支出、移行期間の対応。
ウェイト付きクリエイティブアサインメント
creative_ids 文字列配列がデリバリーウェイト付けとプレースメントターゲティングをサポートする creative_assignments オブジェクトに置き換えられます。
クリエイティブの詳細
ウェイト付きアサインメント、プレースメントターゲティング、統合
assets 配列によるアセット探索、繰り返し可能なグループ、フォーマットカード。名前付きシステムによるジオターゲティング
メトロと郵便ターゲティングには明示的なシステム仕様が必要になり、グローバル市場をサポートします。値は{ "system": "...", "values": [...] } オブジェクトを使ってシステムでグループ化されます。
v3 はネガティブターゲティング（例: ニューヨーク DMA を除く米国をターゲット）のために
geo_metros_exclude と geo_postal_areas_exclude も追加します。
ジオターゲティングの詳細
メトロと郵便システムのリファレンステーブル、除外ターゲティング、ケイパビリティ探索、完全なターゲティング例。
その他のターゲティング変更
v3 はジオ以外にいくつかのターゲティングフィールドを追加します:
これらのフィールドはオプションの追加 — v2 のフィールドを置き換えるものではありません。
統合アセット探索
フォーマットはassets_required の代わりに required ブールを持つ assets 配列を使用するようになりました。クリエイティブの詳細を参照。
カタログが promoted_offerings を置き換える
promoted_offerings クリエイティブアセットタイプと promoted_offering 文字列フィールドが削除されました。カタログは独自の同期ライフサイクル（sync_catalogs）、フォーマットレベルの要件（catalog_requirements）、コンバージョンイベント整合を持つファーストクラスのプロトコルオブジェクトになりました。
カタログの詳細
変更前後の例、sync_catalogs ワークフロー、catalog_requirements の探索、移行チェックリスト。
ブランドアイデンティティの統一
インラインのbrand_manifest オブジェクトがブランド参照（BrandRef）に置き換えられます。タスクスキーマはマニフェストをインラインで渡す代わりに { domain, brand_id } でブランドを参照します。ブランドデータは実行時に brand.json またはレジストリから解決されます。
影響:
get_products、create_media_buy、build_creative、プロパティリストスキーマ。
ブランドアイデンティティの詳細
BrandRef スキーマ、解決フロー、変更前後の例、移行ステップ。
プロダクトデリバリー予測
estimated_exposures が DeliveryForecast タイプを使った構造化された forecast フィールドに置き換えられます。
バイイングモードによるプロポーザルリファインメント
proposal_id が get_products リクエストから削除されました。リファインメントは型指定された変更リクエスト配列（型指定されたリファインメント参照）を持つ buying_mode: "refine" を使用します。セッション継続性（MCP では context_id、A2A では contextId）が呼び出し間で会話履歴を引き継ぐ。
proposal_id による create_media_buy でのプロポーザル実行は変更なし。
最適化目標の再設計
optimization_goal（単一オブジェクト）が optimization_goals（配列）に置き換えられます。各目標は kind による識別子付きユニオン:
2つの目標 kind:
metric—cost_perまたはthreshold_rateターゲットを持つセラーネイティブのデリバリーメトリック（クリック、視聴、リーチ、エンゲージメントなど）event—event_sources配列とオプションのvalue_field/value_factorを持つコンバージョントラッキング
最適化目標の詳細
目標 kind、リーチ最適化、マルチゴール優先度、プロダクトケイパビリティ、移行ステップ。
シグナル価格の再構造化
シグナルのレガシーのpricing: { cpm } オブジェクトが3つの価格モデルを持つ構造化された pricing_options 配列に置き換えられます。
3つのモデル:
cpm、percent_of_media（オプションの max_cpm 付き）、flat_fee。
シグナルの詳細
価格モデル、deliver_to のフラット化、使用状況レポート、移行ステップ。
シグナル deliver_to のフラット化
get_signals リクエストのネストされた deliver_to オブジェクトが2つのトップレベルフィールドに置き換えられます。
AudienceMember external_id が必須に
external_id が uid-type 列挙値から AudienceMember の必須トップレベルフィールドに昇格します。すべてのメンバーはバイヤーが割り当てた安定した識別子と少なくとも1つのマッチング可能な識別子を持つ必要があります。
オーディエンスの詳細
変更前後の例、uid-type の変更、sync_audiences の使用、移行ステップ。
セラーの承認による型指定されたリファインメント
refine は overall/products/proposals のネストされたオブジェクトからフラットな型指定された配列に再設計されました。各エントリは scope で識別されます:
セラーは
refinement_applied で応答する — 位置でマッチする配列で、各エントリが status（applied、partial、unable）とオプションの notes を報告します。
リファインメントの詳細
変更リクエストタイプ、セラーの承認、変更前後の例。
クリエイティブアサインメントの再構造化
SyncCreativesRequest.assignments が { creative_id: package_id[] } マップから明示的なフィールドを持つ型指定された配列に変更されました。
シグナルのアカウントとフィールドの一貫性
シグナルスキーマへの2つの一貫性変更:パッケージカタログを配列に
ブランドトーンの構造化フォーマット
ブランドのtone はオブジェクト型のみになった — 文字列フォーマットが削除されました。構造化されたトーンには voice、attributes、dos、donts フィールドが含まれます。既存の文字列値は { "voice": "<previous-string>" } に移行します。
アカウント解決の削除
account_resolution ケイパビリティフィールドが削除されました。require_operator_auth が認証モデルとアカウント参照スタイルの両方を決定する: true は明示的なアカウント（list_accounts で発見し、account_id を渡す）、false は暗黙的なアカウント（sync_accounts で宣言し、自然キーを渡す）を意味します。
プライバシーと同意
AdCP は独自の同意フレームワークを定義しません。プライバシーシグナル（TCF 2.0、GPP、US Privacy String）はブリーフのext フィールドまたはトランスポートレベルのヘッダーで渡します。同意シグナルを必要とするセラーは、拡張メカニズムを使って get_adcp_capabilities でこれを宣言します。
v3 で削除されたもの
移行チェックリスト
セラーエージェント（パブリッシャー、SSP、ネットワーク）
セラーエージェント（パブリッシャー、SSP、ネットワーク）
すべてのデータ構造を v3 フォーマット（チャンネル、価格、ジオターゲティング）に更新し、新しいケイパビリティを実装します:
-
get_adcp_capabilitiesタスクを実装する（accountケイパビリティを含む） - エージェントカードから
adcp-extension.jsonを削除します - アカウントプロビジョニングのために
sync_accountsを実装します - 該当する場合は
get_productsからデリバリー予測付きプロポーザルを返す - ガバナンスエージェントと統合する場合は
get_productsでプロパティリストフィルタリングをサポートします - 承認ワークフロー付きで
sync_catalogs経由で同期されたカタログを処理します - プロダクトで
metric_optimizationケイパビリティを宣言します -
get_adcp_capabilitiesでディメンションブレークダウンのreportingケイパビリティを宣言します -
get_media_buy_deliveryでreporting_dimensionsパラメーターをサポートします -
refineリクエストを処理するときにrefinement_applied配列を返す - メディアバイで
rejectedステータスとrejection_reasonを実装します -
get_productsでfieldsプロジェクションパラメーターをサポートします -
get_adcp_capabilitiesでsupported_pricing_modelsを宣言します -
get_productsでtime_budgetをサポートし、予算内で完了できない場合はincompleteを返す -
media_buy.features.sandboxではなくaccount.sandboxでサンドボックスサポートを宣言します -
preferred_delivery_types、exclusivity、オプションのdelivery_measurement、パッケージレベルのstart_time/end_timeをサポートします
バイヤーエージェントとオーケストレーター（DSP、エージェンシー、ブランド）
バイヤーエージェントとオーケストレーター（DSP、エージェンシー、ブランド）
すべてのリクエストとレスポンス処理を v3 フォーマットに更新し、新しいケイパビリティを統合する:
- 購買を行う前に
brand.jsonでブランドを解決します - 請求関係を確立するために
sync_accountsを呼び出す - ランタイム探索のために
get_adcp_capabilitiesを呼び出すように更新します - セラーが返したプロポーザルとデリバリー予測を評価します
- ブランド/プロパティ解決とエージェント探索のためにレジストリ API を使用します
- ガバナンスエージェントと連携するときはプロパティリストを渡してインベントリをフィルタリングします
- ユーザーをブランドエージェントに接続するときは SI セッションを呼び出す
- クリエイティブを送信する前に
sync_catalogsでカタログを同期します - アトリビューショントラッキングのためにカタログに
conversion_eventsを追加します -
create_media_buyのoptimization_goalをoptimization_goals配列に更新します - 価格オプション付きでシグナルをアクティベートするときに
pricing_option_idを渡します - デリバリーレポーティングでのディメンションブレークダウンのために
reporting_dimensionsを使用します - 型指定されたリファインメントフィードバックのために
refinement_appliedレスポンスを処理します - 自動リトライ/修正のためにエラーの
recoveryフィールドを使用します - 効率的な探索のために
get_productsでfieldsプロジェクションを使用します - メディアバイの
rejectedステータスを処理します - キャンペーンクリーンアップのために
activate_signalでaction: "deactivate"を使用します - ライセンスコンテンツキャンペーンのために
get_rights/acquire_rightsを統合します - クリエイティブ生成のために
brand.jsonのvisual_guidelinesを処理します - アカウントとサンドボックスフローを選択するときに
require_operator_authとaccount.sandboxを読む - 制限されたレイテンシのプロダクト探索のために
time_budget/incompleteを処理します - ビルド対ライブラリワークフローをルーティングするためにクリエイティブケイパビリティフラグ（
supports_generation、supports_transformation、has_creative_library）を使用します - キャンペーンガバナンスが使用中の場合は
check_governanceでガバナンスエージェントにプランを送信します
シグナルエージェント（データプロバイダー、計測ベンダー）
シグナルエージェント（データプロバイダー、計測ベンダー）
スキーマ参照を v2 から v3 に更新します。シグナルプロトコルのコアモデルはメディアチャンネルを使用しません。
- スキーマ参照を v2 から v3 に更新します
-
get_adcp_capabilitiesがmajor_versions: [3]を返すことを確認します -
get_signalsレスポンスで構造化されたsignal_idオブジェクトを返す - シグナルレスポンスに
value_typeフィールドを含めます - ID ベースのルックアップのために
get_signalsリクエストでsignal_idsパラメーターをサポートします - レガシーの
pricingから構造化されたpricing_options配列に更新します - ネストされた
deliver_toの代わりにトップレベルのdestinations/countriesを処理します -
report_usageにidempotency_keyサポートを追加します -
activate_signalでaction: "deactivate"をサポートします - シグナルエントリに
categoriesとrangeメタデータを含めます -
account_idをaccount（AccountReference）に更新します -
deploymentsをdestinationsに名前変更します
データプロバイダー（v3 で新規）
データプロバイダー（v3 で新規）
adagents.json でシグナルカタログを公開します。データプロバイダーガイドを参照。-
/.well-known/adagents.jsonにシグナルカタログを作成します -
id、name、value_type、オプションのメタデータでシグナルを定義します - グループ化と効率的な認証のために
signal_tagsを追加します -
signal_idsまたはsignal_tags認証タイプを使ってシグナルエージェントを認証します - AdAgents.json Builder でカタログを検証します
クリエイティブエージェント（クリエイティブ管理、DCO プロバイダー）
クリエイティブエージェント（クリエイティブ管理、DCO プロバイダー）
新しいアセット探索をサポートし、ブランドアイデンティティを統合します。フォーマットの
type フィールド（video、display、audio）は IAB クリエイティブ分類であり、メディアチャンネルではありません。-
requiredブールを持つassets配列をサポートする（assets_requiredを置き換え） -
preview_imageをformat_cardレンダリングに置き換える - ブランドに合ったクリエイティブ生成のために
brand.jsonでブランドアイデンティティを解決します - クリエイティブマニフェストで
catalogフィールドをサポートする（promoted_offeringsアセットを置き換え） - カタログアイテムをレンダリングするフォーマットで
catalog_requirementsを宣言します - スキーマ参照を v2 から v3 に更新します
- クリエイティブマニフェストとアセットで
provenanceオブジェクトをサポートします -
assetsマップのアセットタイプとしてbriefとcatalogをサポートします - クリエイティブブリーフの
compliance.required_disclosuresを処理します - フォーマットの
supported_disclosure_positions互換性を確認します - ケイパビリティで
supports_complianceを宣言する（supports_briefを置き換え） - ブランドに合ったアセット生成のために
brand.jsonのvisual_guidelinesを処理します -
build_creativeでinclude_preview、target_format_ids、quality、item_limitをサポートします -
creative_idによるライブラリ取得をサポートし、supports_generation、supports_transformation、has_creative_libraryを宣言します -
list_creativesとsync_creativesをクリエイティブプロトコル操作として実装します -
preview_creativeでqualityパラメーターをサポートします - フォーマットの
disclosure_capabilitiesでディスクロージャー持続性サポートを宣言します
ブランド（v3 で新規）
ブランド（v3 で新規）
バイサイドアイデンティティを確立します。brand.json 仕様を参照。
- ドメインに
/.well-known/brand.jsonをホストします - ブランドポートフォリオ、プロパティ、認証済みオペレーターを宣言します
- オプションで
brand.jsonでインラインまたはブランドエージェント経由でブランドデータ（ロゴ、カラー、フォント、トーン）を提供します - ジェネラティブクリエイティブシステム向けに
brand.jsonにvisual_guidelinesを追加します - コンテンツをライセンスする場合は
get_rights/acquire_rights/update_rightsを実装します -
brand.jsonをホストしていない場合はコミュニティブランドレジストリに登録します
ガバナンスエージェント（v3 で新規）
ガバナンスエージェント（v3 で新規）
ブランドスーツアビリティケイパビリティを実装します。ガバナンスプロトコルを参照。
- プロパティリストタスク（
create_property_list、get_property_listなど）を実装します - コンテンツスタンダードタスク（
create_content_standards、calibrate_contentなど）を実装します -
supported_protocolsにgovernanceを含むget_adcp_capabilitiesを実装します - クリエイティブポリシーで
provenance_required強制を実装します - AI 検出サービスからの
verification結果をサポートします - クリエイティブ評価のために
get_creative_featuresを実装します -
get_adcp_capabilitiesでcreative_featuresを宣言します - プランレベルのガバナンスを提供するときはキャンペーンガバナンスタスク（
sync_plans、check_governance、report_plan_outcome、get_plan_audit_logs）を実装します
スポンサードインテリジェンスエージェント（v3 で新規）
スポンサードインテリジェンスエージェント（v3 で新規）
会話型ブランド体験を実装します。SI チャットプロトコルを参照。
- SI セッションタスク（
si_initiate_session、si_send_message、si_terminate_session）を実装します -
supported_protocolsにsponsored_intelligenceを含むget_adcp_capabilitiesを実装します
サポート
- コミュニティ: Slack
- イシュー: GitHub Issues
- サポート: support@adcontextprotocol.org