AdCP — AdCP 3.0

AdCP 3.0 はプロトコルをメディアバイを超えて、ブランドアイデンティティ、ガバナンス、メディアプランニング、会話型ブランド体験まで拡張します。

一覧

エリア	v2.x	v3.x
プロトコルスコープ	メディアバイ、シグナル、クリエイティブ	ブランドプロトコル、ガバナンス、スポンサードインテリジェンスを追加
ブランドアイデンティティ	標準的なメカニズムなし	`brand.json` + コミュニティブランドレジストリ
ガバナンス	ブランドスーツアビリティプロトコルなし	プロパティリスト、コンテンツスタンダード、キャンペーンガバナンス、ポリシーレジストリ、ブランドキャリブレーション
スポンサードインテリジェンス	会話型ブランドプロトコルなし	AI アシスタントでの同意優先ブランドセッション
アカウントプロトコル	正式なアカウントモデルなし	名前付きプロトコルレイヤー: `sync_accounts`、`list_accounts`、`report_usage`、ブランドレジストリに基づくアイデンティティ
カタログ	`promoted_offerings` クリエイティブアセット	13のカタログタイプを持つファーストクラスの `sync_catalogs` タスク
メディアプランニング	プロダクトのみ	予算配分 + デリバリー予測を持つプロポーザル
ブランド権利	ライセンスプロトコルなし	HMAC 認証 Webhook を持つ `get_rights`、`acquire_rights`、`update_rights`
ビジュアルガイドライン	構造化されたブランドビジュアルなし	ジェネラティブクリエイティブシステム向け `brand.json` の `visual_guidelines`
クリエイティブワークフロー	基本的なビルド / プレビュー / シンクの分離	インラインプレビュー、マルチフォーマット `build_creative`、ライブラリ取得、品質ティア、カタログ `item_limit`
クリエイティブライブラリ	メディアバイ中心のクリエイティブ読み書き	`list_creatives` / `sync_creatives` をクリエイティブプロトコル操作として、`supports_generation`、`supports_transformation`、`has_creative_library` の探索も追加
クリエイティブガバナンス	クリエイティブ評価プロトコルなし	セキュリティスキャン、品質、コンテンツ分類のための `get_creative_features`
ディスクロージャーマッチング	位置のみのディスクロージャー処理	位置 + 持続性を考慮したディスクロージャーマッチング（`continuous`、`initial`、`flexible`）
番組とエピソード	コンテンツプログラミングモデルなし	配信 ID、エピソードライフサイクル、ブレークベースのインベントリを持つプロダクトの `shows`
プランニングの利便性	`time_budget`、`preferred_delivery_types`、`exclusivity`、パッケージレベルフライトなし	`time_budget` + `incomplete`、`preferred_delivery_types`、`exclusivity`、オプションの `delivery_measurement`、パッケージレベルの `start_time` / `end_time`
チャンネルモデル	9チャンネル	20のプランニング指向チャンネル（`sponsored_intelligence` を含む）
ケイパビリティ探索	エージェントカード拡張	ランタイム `get_adcp_capabilities` タスク
サンドボックス探索	機能位置が混在	認証モデルに `require_operator_auth`、サンドボックスサポートに `account.sandbox`
クリエイティブアサインメント	シンプルな ID 配列	プレースメントターゲティング付きのウェイト付きアサインメント
ジオターゲティング	暗黙的な米国中心	明示的な名前付きシステム（グローバル）
キーワードターゲティング	キーワードサポートなし	マッチタイプと入札価格を持つ `keyword_targets`
最適化	単一の最適化目標	メトリックとイベントタイプを持つマルチゴール `optimization_goals` 配列
デリバリーレポーティング	集計デリバリーのみ	オプトインのディメンションブレークダウン（ジオ、デバイス、オーディエンス、プレースメント、キーワード）
シグナル価格	シンプルな CPM	構造化された価格モデル（CPM、メディア費用の割合、固定料金）
デバイスターゲティング	フォームファクターターゲティングなし	`device_platform`（OS）とは別の `device_type`（デスクトップ、モバイル、タブレット、ctv、dooh、unknown）
近接ターゲティング	ポイントベースのジオターゲティングなし	移動時間、半径、GeoJSON メソッドを持つ `geo_proximity`
リファインメント	`proposal_id` を持つ自由テキスト	セラーの承認付きの型指定された変更リクエスト配列
エラー処理	構造化されていないエラー	`recovery` フィールド（transient、correctable、terminal）+ 18の標準エラーコード
AI プロベナンス	プロベナンスモデルなし	IPTC ソースタイプ、C2PA 参照、規制ディスクロージャーを持つ `provenance` オブジェクト
クリエイティブコンプライアンス	ブリーフでのコンプライアンスなし	`required_disclosures`、`prohibited_claims`、ディスクロージャー位置
エージェント利便性	毎回フルペイロード	`fields` プロジェクション、オプトインブレークダウン、プリフライトケイパビリティフィルタリング
シグナルライフサイクル	アクティベートのみ	`activate_signal` での `activate` / `deactivate` アクション

新機能

ブランドプロトコル

/.well-known/brand.json によるバイサイドアイデンティティ。パブリッシャーが adagents.json でプロパティと認証済みエージェントを宣言するのと同様に、ブランドは brand.json でアイデンティティ、ブランド階層、認証済みオペレーターを宣言します。

セルサイド	バイサイド
パブリッシャー	ハウス（企業エンティティ）
プロパティ	ブランド（広告アイデンティティ）
`adagents.json`	`brand.json`

4つのバリアント: House Portfolio（完全なブランド階層をインライン）、Brand Agent（MCP 経由で動的）、House Redirect（サブブランドからハウスドメインへ）、Authoritative Location（ホストされた URL）。任意のドメインが与えられると、プロトコルは正規ブランドに解決する:

shoes.novabrands.example.com
  -> fetch /.well-known/brand.json
  -> { "house": "novabrands.example.com" }
  -> fetch novabrands.example.com/.well-known/brand.json
  -> search brands[] for property matching "shoes.novabrands.example.com"
  -> Result: { house: "novabrands.example.com", brand_id: "nova_athletics" }

ユースケース: クリエイティブ生成（ドメインをブランドアイデンティティに解決）、ブランド検証（authorized_operators を確認）、レポーティングロールアップ（キャンペーンをハウスでグループ化）。

ブランドプロトコル

brand.json バリアント、解決フロー、ブランドアイデンティティを含む完全な仕様。

ブランド権利ライフサイクル

ブランドとコンテンツオーナー間のライセンスと使用権のための3つのタスク:

タスク	目的
`get_rights`	ブランドのコンテンツで利用可能な権利を発見する
`acquire_rights`	権利取得を要求・交渉する
`update_rights`	アクティブな権利を変更する（延長、制限、取り消し）

権利にはジェネレーション資格情報（ライセンスされたコンテンツにアクセスするための 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 を提供します。ほとんどのエンドポイントは認証不要です。

ケイパビリティ	エンドポイント	説明
ブランド解決	`/api/brands/resolve`	ドメインを正規ブランドに解決する
プロパティ解決	`/api/properties/resolve`	パブリッシャードメインをプロパティ情報に解決する
エージェント探索	`/api/registry/agents`	ケイパビリティを持つ登録エージェントをリストする
認証チェック	`/api/registry/validate/property-authorization`	リアルタイムの認証検証
検索	`/api/search`	ブランド、パブリッシャー、プロパティを横断して検索する
コミュニティブランド	`/api/brands/save`	ブランドデータを提供する（認証必要）

レジストリはプロトコルを補完する: REST API でエンティティを解決し、MCP/A2A タスクでトランザクションを実行します。

レジストリ API

認証とレート制限を含む完全なエンドポイントリファレンス。

プロポーザルとデリバリー予測

パブリッシャーはプロダクトと共にプロポーザル（バイヤーが create_media_buy で直接実行できるパーセンテージベースの予算配分を持つ構造化メディアプラン）を返せる。プロポーザルはパブリッシャーの専門知識を体現し、アドホックなプロダクトリストを実行可能な購買戦略に置き換える。セッション継続性によりリファインメントができる — 同じセッション内での後続の get_products 呼び出しが会話履歴を引き継ぐ。 デリバリー予測はプロポーザルと配分に付属します。各予測には支出が増えるにつれてデリバリーがどのようにスケールするかを示すメトリック範囲（low/mid/high）を持つ予算ポイントが含まれます。3つの予測メソッド: estimate（大まかな近似）、modeled（予測モデル）、guaranteed（契約でコミット済み）。予測はデリバリーメトリック（インプレッション、リーチ、GRP）と成果（購入、リード、アプリインストール）を予測できます。TV とラジオの予測は GRP ベースのプランニングのために demographic_system と demographic を使用します。

プロポーザルと予測

予算カーブ、CTV、リテールメディア、放送オーディオの例を含む完全なドキュメント。

アカウント

v2 からの移行？ アカウントは v3 で完全に新しく、移行元の v2 に相当するものはない。セットアップガイドとしてアカウントとエージェントを参照。

sync_accounts によるバイヤーとセラー間の正式な請求関係。 4つのエンティティ:

エンティティ	問い	識別方法
ブランド	誰の製品を広告するか?	`brand.json` 経由のハウスドメイン + brand_id
アカウント	誰が請求されるか?	アカウント参照 — `list_accounts` からの `account_id` または自然キー
オペレーター	誰がブランドの代わりに操作するか?	ドメイン（例: `acmeagency.example.com`）
エージェント	どのソフトウェアが購買を行うか?	認証済みセッション

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 エージェントカードの両方をランタイムケイパビリティ探索に置き換える。サポートされるプロトコル、アカウント請求モデル、ポートフォリオ情報、ターゲティングシステム、ガバナンス機能を返す — すべてスキーマ検証済み。

エージェントカードと adcp-extension.json はもはや不要です。 バイヤーは adagents.json でセラーを発見し、ランタイムに get_adcp_capabilities を呼び出す。エージェントカード拡張からケイパビリティデータを読んでいる v2 インテグレーションがある場合は、get_adcp_capabilities に切り替えること。

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 でシグナルカタログを公開できます。

パブリッシャー	データプロバイダー
プロパティを宣言する	シグナルを宣言する
`property_ids` / `property_tags` を使用	`signal_ids` / `signal_tags` を使用
バイヤーは `publisher_domain` で検証する	バイヤーは `data_provider_domain` で検証する

シグナルは型付きターゲティングを持つ明示的な 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 を参照。

破壊的変更

メディアチャンネルタクソノミー

v2 の 9 チャンネルが 20 のプランニング指向チャンネルに置き換えられます。5つのチャンネルはそのまま（display、social、ctv、podcast、dooh）。残りの4つは分割、削除、または名前変更されました。

チャンネル値を読み書きするすべてのコードを更新する必要があります。

v2 チャンネル	v3 チャンネル	注記
`display`	`display`	変更なし
`video`	`olv`、`linear_tv`、`cinema`	配信コンテキストで分割（`ctv` は v2 ですでに別）
`audio`	`radio`、`streaming_audio`	配信で分割（`podcast` は v2 ですでに別）
`native`	削除	フォーマットレベルのプロパティを使用する
`social`	`social`	変更なし
`ctv`	`ctv`	変更なし
`podcast`	`podcast`	変更なし
`dooh`	`dooh`	変更なし
`retail`	`retail_media`	明確化のために名前変更

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 に移動します。

v2 フィールド	v3 フィールド	注記
`fixed_rate`	`fixed_price`	明確化のために名前変更（レートではなく価格）
`price_guidance.floor`	`floor_price`	ハード制約としてトップレベルに移動

これらのフィールドは標準的なディールタイプにマッピングされます: fixed_price はプログラマティックギャランティード（PG）とプリファードディールに、floor_price はプライベートマーケットプレイス（PMP）オークションに対応します。オープンオークションインベントリは両方のフィールドを省略します。

価格の詳細

固定価格とオークションの例、価格ガイダンスのスキーマ、フラットレート価格、最低支出、移行期間の対応。

ウェイト付きクリエイティブアサインメント

creative_ids 文字列配列がデリバリーウェイト付けとプレースメントターゲティングをサポートする creative_assignments オブジェクトに置き換えられます。

v2 フィールド	v3 フィールド
`creative_ids`（文字列配列）	`creative_assignments`（`creative_id`、`weight`、`placement_ids` を持つオブジェクト配列）

クリエイティブの詳細

ウェイト付きアサインメント、プレースメントターゲティング、統合 assets 配列によるアセット探索、繰り返し可能なグループ、フォーマットカード。

名前付きシステムによるジオターゲティング

メトロと郵便ターゲティングには明示的なシステム仕様が必要になり、グローバル市場をサポートします。値は { "system": "...", "values": [...] } オブジェクトを使ってシステムでグループ化されます。

v2 フィールド	v3 フィールド
`geo_metros`（文字列配列）	`geo_metros`（system/values オブジェクト）
`geo_postal_codes`（文字列配列）	`geo_postal_areas`（system/values オブジェクト）

v3 はネガティブターゲティング（例: ニューヨーク DMA を除く米国をターゲット）のために geo_metros_exclude と geo_postal_areas_exclude も追加します。

ジオターゲティングの詳細

メトロと郵便システムのリファレンステーブル、除外ターゲティング、ケイパビリティ探索、完全なターゲティング例。

その他のターゲティング変更

v3 はジオ以外にいくつかのターゲティングフィールドを追加します:

フィールド	説明
`daypart_targets`	時間帯と曜日のターゲティングウィンドウ
`age_restriction`	制限コンテンツの年齢ゲーティング
`device_platform`	OS ターゲティング（iOS、Android、Windows、tvOS など）
`device_type`	デバイスフォームファクターターゲティング（desktop、mobile、tablet、ctv、dooh、unknown）
`language`	コンテンツ言語ターゲティング
`keyword_targets` / `negative_keywords`	マッチタイプ（broad、phrase、exact）とキーワードごとの入札価格を持つ検索とリテールメディア向けキーワードターゲティング
`device_type_exclude`	ネガティブデバイスフォームファクターターゲティング
`geo_proximity`	移動時間アイソクロン、半径、GeoJSON ジオメトリによるポイントベースの近接ターゲティング

これらのフィールドはオプションの追加 — v2 のフィールドを置き換えるものではありません。

統合アセット探索

フォーマットは assets_required の代わりに required ブールを持つ assets 配列を使用するようになりました。クリエイティブの詳細を参照。

カタログが promoted_offerings を置き換える

promoted_offerings クリエイティブアセットタイプと promoted_offering 文字列フィールドが削除されました。カタログは独自の同期ライフサイクル（sync_catalogs）、フォーマットレベルの要件（catalog_requirements）、コンバージョンイベント整合を持つファーストクラスのプロトコルオブジェクトになりました。

v2 フィールド	v3 代替
`promoted_offerings`（クリエイティブアセット）	クリエイティブマニフェストの `catalogs` フィールド
`promoted_offering`（メディアバイの文字列）	削除 — `brand` + `brief` を使用する
`promoted_offering`（クリエイティブマニフェストの文字列）	削除 — `catalogs` フィールドを使用する

カタログの詳細

変更前後の例、sync_catalogs ワークフロー、catalog_requirements の探索、移行チェックリスト。

ブランドアイデンティティの統一

インラインの brand_manifest オブジェクトがブランド参照（BrandRef）に置き換えられます。タスクスキーマはマニフェストをインラインで渡す代わりに { domain, brand_id } でブランドを参照します。ブランドデータは実行時に brand.json またはレジストリから解決されます。

v2/beta フィールド	v3 rc.1 フィールド
`brand_manifest`（インラインオブジェクト）	`brand`（`{ domain, brand_id }`）

影響: get_products、create_media_buy、build_creative、プロパティリストスキーマ。

ブランドアイデンティティの詳細

BrandRef スキーマ、解決フロー、変更前後の例、移行ステップ。

プロダクトデリバリー予測

estimated_exposures が DeliveryForecast タイプを使った構造化された forecast フィールドに置き換えられます。

v2/beta フィールド	v3 rc.1 フィールド
`estimated_exposures`（整数）	`forecast`（期間、メトリック範囲、方法論を持つ DeliveryForecast）

バイイングモードによるプロポーザルリファインメント

proposal_id が get_products リクエストから削除されました。リファインメントは型指定された変更リクエスト配列（型指定されたリファインメント参照）を持つ buying_mode: "refine" を使用します。セッション継続性（MCP では context_id、A2A では contextId）が呼び出し間で会話履歴を引き継ぐ。 proposal_id による create_media_buy でのプロポーザル実行は変更なし。

v2/beta フィールド	v3 rc.1 フィールド
`get_products` リクエストの `proposal_id`	削除 — `buying_mode: "refine"` を使用する

最適化目標の再設計

optimization_goal（単一オブジェクト）が optimization_goals（配列）に置き換えられます。各目標は kind による識別子付きユニオン:

v2/beta フィールド	v3 rc.1 フィールド
`optimization_goal`（単一オブジェクト）	`optimization_goals`（配列）
暗黙的な単一目標	マルチゴール順序付けのための `priority` フィールド

2つの目標 kind:

metric — cost_per または threshold_rate ターゲットを持つセラーネイティブのデリバリーメトリック（クリック、視聴、リーチ、エンゲージメントなど）
event — event_sources 配列とオプションの value_field/value_factor を持つコンバージョントラッキング

最適化目標の詳細

目標 kind、リーチ最適化、マルチゴール優先度、プロダクトケイパビリティ、移行ステップ。

シグナル価格の再構造化

シグナルのレガシーの pricing: { cpm } オブジェクトが3つの価格モデルを持つ構造化された pricing_options 配列に置き換えられます。

v2/beta フィールド	v3 rc.1 フィールド
`pricing.cpm`（数値）	`pricing_options[]`（価格モデルオブジェクトの配列）

3つのモデル: cpm、percent_of_media（オプションの max_cpm 付き）、flat_fee。

シグナルの詳細

価格モデル、deliver_to のフラット化、使用状況レポート、移行ステップ。

シグナル deliver_to のフラット化

get_signals リクエストのネストされた deliver_to オブジェクトが2つのトップレベルフィールドに置き換えられます。

v2/beta フィールド	v3 rc.1 フィールド
`deliver_to.destinations`	`destinations`（トップレベル）
`deliver_to.countries`	`countries`（トップレベル）

AudienceMember external_id が必須に

external_id が uid-type 列挙値から AudienceMember の必須トップレベルフィールドに昇格します。すべてのメンバーはバイヤーが割り当てた安定した識別子と少なくとも1つのマッチング可能な識別子を持つ必要があります。

オーディエンスの詳細

変更前後の例、uid-type の変更、sync_audiences の使用、移行ステップ。

セラーの承認による型指定されたリファインメント

refine は overall/products/proposals のネストされたオブジェクトからフラットな型指定された配列に再設計されました。各エントリは scope で識別されます:

v2/beta フィールド	v3 rc.1 フィールド
`refine.overall`（文字列）	`{ "scope": "request", "ask": "..." }` 配列エントリ
`refine.products[].product_id`	`{ "scope": "product", "id": "..." }`
`refine.products[].notes`	`ask` フィールド

セラーは refinement_applied で応答する — 位置でマッチする配列で、各エントリが status（applied、partial、unable）とオプションの notes を報告します。

リファインメントの詳細

変更リクエストタイプ、セラーの承認、変更前後の例。

クリエイティブアサインメントの再構造化

SyncCreativesRequest.assignments が { creative_id: package_id[] } マップから明示的なフィールドを持つ型指定された配列に変更されました。

v2/beta フィールド	v3 rc.1 フィールド
`assignments`（オブジェクトマップ）	`assignments`（`{ creative_id, package_id, weight, placement_ids }` の配列）

シグナルのアカウントとフィールドの一貫性

シグナルスキーマへの2つの一貫性変更:

v2/beta フィールド	v3 rc.1 フィールド
`get_signals` と `activate_signal` の `account_id`（文字列）	`account`（AccountReference オブジェクト）
`activate_signal` の `deployments`	`destinations`（`get_signals` との一貫性のために名前変更）

パッケージカタログを配列に

v2/beta フィールド	v3 rc.1 フィールド
パッケージの `catalog`（単一の Catalog オブジェクト）	`catalogs`（Catalog refs の配列）

ブランドトーンの構造化フォーマット

ブランドの tone はオブジェクト型のみになった — 文字列フォーマットが削除されました。構造化されたトーンには voice、attributes、dos、donts フィールドが含まれます。既存の文字列値は { "voice": "<previous-string>" } に移行します。

v2/beta フィールド	v3 rc.2 フィールド
`tone`（文字列またはオブジェクト）	`tone`（オブジェクト: `{ voice, attributes, dos, donts }`）

アカウント解決の削除

account_resolution ケイパビリティフィールドが削除されました。require_operator_auth が認証モデルとアカウント参照スタイルの両方を決定する: true は明示的なアカウント（list_accounts で発見し、account_id を渡す）、false は暗黙的なアカウント（sync_accounts で宣言し、自然キーを渡す）を意味します。

v2/beta/rc.1 フィールド	v3 rc.2 フィールド
`account_resolution` ケイパビリティ	削除 — `require_operator_auth` を使用する

プライバシーと同意

AdCP は独自の同意フレームワークを定義しません。プライバシーシグナル（TCF 2.0、GPP、US Privacy String）はブリーフの ext フィールドまたはトランスポートレベルのヘッダーで渡します。同意シグナルを必要とするセラーは、拡張メカニズムを使って get_adcp_capabilities でこれを宣言します。

v3 で削除されたもの

削除されたもの	代替
`adcp-extension.json` エージェントカード	`get_adcp_capabilities` タスク
`list_authorized_properties` タスク	`get_adcp_capabilities` ポートフォリオセクション
フォーマットの `assets_required`	`required` ブールを持つ `assets` 配列
フォーマットの `preview_image`	`format_card` オブジェクト
パッケージの `creative_ids`	`creative_assignments` 配列
`geo_postal_codes`	`geo_postal_areas`
価格の `fixed_rate`	`fixed_price`
`price_guidance.floor`	`floor_price`（トップレベル）
`promoted_offerings` アセットタイプ	クリエイティブマニフェストの `catalogs` フィールド
メディアバイの `promoted_offering`	削除 — `brand` + `brief` を使用する
クリエイティブマニフェストの `promoted_offering`	`catalogs` フィールド
`brand_manifest`（インラインオブジェクト）	`brand` ref（`{ domain, brand_id }`）
プロダクトの `estimated_exposures`	`forecast`（DeliveryForecast）
`get_products` リクエストの `proposal_id`	セッション継続性（`context_id` / `contextId`）
`overall`/`products`/`proposals` を持つ `refine` オブジェクト	型指定された変更リクエストの `refine` 配列
`build_creative` リクエストの `creative_brief`	マニフェスト `assets` マップの `brief` アセットタイプ
`supports_brief` ケイパビリティ	`supports_compliance`
`creative-brief-ref.json` スキーマ	削除 — ブリーフはアセットタイプになった
`activate_signal` の `deployments`	`destinations`
シグナルタスクの `account_id`（文字列）	`account`（AccountReference）
`report_usage.kind` と `report_usage.operator_id`	削除
パッケージの `catalog`（単数）	`catalogs`（配列）
`account_resolution` ケイパビリティ	`require_operator_auth` がアカウントモデルを決定する
`delete_content_standards` タスク	`update_content_standards` でアーカイブする
`get_property_features` タスク	プロパティリストフィルター + 機能探索のための `get_adcp_capabilities`
`brand.json` の文字列としての `tone`	オブジェクトのみ: `{ voice, attributes, dos, donts }`

移行チェックリスト

すべての実装

これらの破壊的変更は AdCP データを読み書きするすべての実装に影響する:

セラーエージェント（パブリッシャー、SSP、ネットワーク）

すべてのデータ構造を v3 フォーマット（チャンネル、価格、ジオターゲティング）に更新し、新しいケイパビリティを実装します:

バイヤーエージェントとオーケストレーター（DSP、エージェンシー、ブランド）

すべてのリクエストとレスポンス処理を v3 フォーマットに更新し、新しいケイパビリティを統合する:

シグナルエージェント（データプロバイダー、計測ベンダー）

スキーマ参照を v2 から v3 に更新します。シグナルプロトコルのコアモデルはメディアチャンネルを使用しません。

データプロバイダー（v3 で新規）

adagents.json でシグナルカタログを公開します。データプロバイダーガイドを参照。

/.well-known/adagents.json にシグナルカタログを作成します
id、name、value_type、オプションのメタデータでシグナルを定義します
グループ化と効率的な認証のために signal_tags を追加します
signal_ids または signal_tags 認証タイプを使ってシグナルエージェントを認証します
AdAgents.json Builder でカタログを検証します

クリエイティブエージェント（クリエイティブ管理、DCO プロバイダー）

新しいアセット探索をサポートし、ブランドアイデンティティを統合します。フォーマットの type フィールド（video、display、audio）は IAB クリエイティブ分類であり、メディアチャンネルではありません。

ブランド（v3 で新規）

バイサイドアイデンティティを確立します。brand.json 仕様を参照。

ドメインに /.well-known/brand.json をホストします
ブランドポートフォリオ、プロパティ、認証済みオペレーターを宣言します
オプションで brand.json でインラインまたはブランドエージェント経由でブランドデータ（ロゴ、カラー、フォント、トーン）を提供します
ジェネラティブクリエイティブシステム向けに brand.json に visual_guidelines を追加します
コンテンツをライセンスする場合は get_rights / acquire_rights / update_rights を実装します
brand.json をホストしていない場合はコミュニティブランドレジストリに登録します

ガバナンスエージェント（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 で新規）

会話型ブランド体験を実装します。SI チャットプロトコルを参照。

SI セッションタスク（si_initiate_session、si_send_message、si_terminate_session）を実装します
supported_protocols に sponsored_intelligence を含む get_adcp_capabilities を実装します

サポート

コミュニティ: Slack
イシュー: GitHub Issues
サポート: support@adcontextprotocol.org

Getting Started

Building with AdCP

Governance Protocol

Signals Protocol

Curation Protocol

Sponsored Intelligence Protocol

Media Buy Protocol

Creative

Reference

Community

​一覧

​新機能

​ブランドプロトコル

ブランドプロトコル

​ブランド権利ライフサイクル

ブランド権利

​番組とエピソード

番組とエピソード

​レジストリ API

レジストリ API

​プロポーザルとデリバリー予測

プロポーザルと予測

​アカウント

アカウントプロトコル

​カタログ

カタログ

​ケイパビリティ探索

get_adcp_capabilities

​ガバナンスプロトコル

ガバナンスプロトコル

​スポンサードインテリジェンスプロトコル

SI チャットプロトコル

​データプロバイダーのシグナルカタログ

データプロバイダーガイド

​rc.1 から rc.2 のハイライト

​クリエイティブワークフローとライブラリの変更

​プランニング、アカウント、サンドボックスの改良

​コンプライアンスとガバナンスの改良

​破壊的変更

​メディアチャンネルタクソノミー

チャンネルの詳細

​価格オプションフィールドの名前変更

価格の詳細

​ウェイト付きクリエイティブアサインメント

クリエイティブの詳細

​名前付きシステムによるジオターゲティング

ジオターゲティングの詳細

​その他のターゲティング変更

​統合アセット探索

​カタログが promoted_offerings を置き換える

カタログの詳細

​ブランドアイデンティティの統一

ブランドアイデンティティの詳細

​プロダクトデリバリー予測

​バイイングモードによるプロポーザルリファインメント

​最適化目標の再設計

最適化目標の詳細

​シグナル価格の再構造化

シグナルの詳細

​シグナル deliver_to のフラット化

​AudienceMember external_id が必須に

オーディエンスの詳細

​セラーの承認による型指定されたリファインメント

リファインメントの詳細

​クリエイティブアサインメントの再構造化

​シグナルのアカウントとフィールドの一貫性

​パッケージカタログを配列に

​ブランドトーンの構造化フォーマット

​アカウント解決の削除

​プライバシーと同意

​v3 で削除されたもの

​移行チェックリスト

​サポート

一覧

新機能

ブランドプロトコル

ブランド権利ライフサイクル

番組とエピソード

レジストリ API

プロポーザルとデリバリー予測

アカウント

カタログ

ケイパビリティ探索

ガバナンスプロトコル

スポンサードインテリジェンスプロトコル

データプロバイダーのシグナルカタログ

rc.1 から rc.2 のハイライト

クリエイティブワークフローとライブラリの変更

プランニング、アカウント、サンドボックスの改良

コンプライアンスとガバナンスの改良

破壊的変更

メディアチャンネルタクソノミー

価格オプションフィールドの名前変更

ウェイト付きクリエイティブアサインメント

名前付きシステムによるジオターゲティング

その他のターゲティング変更

統合アセット探索

カタログが promoted_offerings を置き換える

ブランドアイデンティティの統一

プロダクトデリバリー予測

バイイングモードによるプロポーザルリファインメント

最適化目標の再設計

シグナル価格の再構造化

シグナル deliver_to のフラット化

AudienceMember external_id が必須に

セラーの承認による型指定されたリファインメント

クリエイティブアサインメントの再構造化

シグナルのアカウントとフィールドの一貫性

パッケージカタログを配列に

ブランドトーンの構造化フォーマット

アカウント解決の削除

プライバシーと同意

v3 で削除されたもの

移行チェックリスト

サポート