> ## 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.0 > AdCP 3.0 の新機能: ブランドアイデンティティと権利、クリエイティブワークフローのアップグレード、ガバナンス、スポンサードインテリジェンス、番組とエピソード、20のメディアチャンネル、v2 からの移行ガイド。 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` アクション | *** ## 新機能 ### 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 検証者チェックリスト — [セキュリティガイド](/docs/building/by-layer/L1/security) で文書化 — は、信頼アンカーのスコープ、ダウングレードとインジェクションの耐性、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）。メモリのみの状態は本番で非準拠です。 完全な脅威モデル、プリンシパルの役割（ブランド / オペレーター / エージェント）、ステップバイステップの検証パスについては [セキュリティ実装ガイド](/docs/building/by-layer/L1/security) を参照。 脅威モデル、署名プロファイル、検証パス、ユニバーサルセキュリティストーリーボード。 *** ### 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 つの親プロトコルにロールアップします。 コンプライアンス実行には 3 つの階層があります: すべてのエージェントが実行する**ユニバーサル**ストーリーボード（機能ディスカバリー、スキーマ検証、エラーコンプライアンス）、宣言された各プロトコルの**ドメインベースライン**、各狭いクレームの**専門分野ストーリーボード**。`/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 での自己証明は橋であり、最終状態ではありません。 ステータスフラグとストーリーボードソースを持つドメインと専門分野の完全なインデックス。 *** ### ブランドプロトコル `/.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 タスクでトランザクションを実行します。 認証とレート制限を含む完全なエンドポイントリファレンス。 *** ### プロポーザルとデリバリー予測 パブリッシャーはプロダクトと共に**プロポーザル**（バイヤーが `create_media_buy` で直接実行できるパーセンテージベースの予算配分を持つ構造化メディアプラン）を返せる。プロポーザルはパブリッシャーの専門知識を体現し、アドホックなプロダクトリストを実行可能な購買戦略に置き換える。セッション継続性によりリファインメントができる — 同じセッション内での後続の `get_products` 呼び出しが会話履歴を引き継ぐ。 **デリバリー予測**はプロポーザルと配分に付属します。各予測には支出が増えるにつれてデリバリーがどのようにスケールするかを示すメトリック範囲（low/mid/high）を持つ予算ポイントが含まれます。3つの予測メソッド: **`estimate`**（大まかな近似）、**`modeled`**（予測モデル）、**`guaranteed`**（契約でコミット済み）。予測はデリバリーメトリック（インプレッション、リーチ、GRP）と成果（購入、リード、アプリインストール）を予測できます。TV とラジオの予測は GRP ベースのプランニングのために `demographic_system` と `demographic` を使用します。 予算カーブ、CTV、リテールメディア、放送オーディオの例を含む完全なドキュメント。 *** ### アカウント **v2 からの移行？** アカウントは v3 で完全に新しく、移行元の v2 に相当するものはない。セットアップガイドとして[アカウントとエージェント](/docs/building/by-layer/L2/accounts-and-agents)を参照。 `sync_accounts` によるバイヤーとセラー間の正式な請求関係。 **4つのエンティティ:** | エンティティ | 問い | 識別方法 | | ---------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------- | | **ブランド** | 誰の製品を広告するか? | `brand.json` 経由のハウスドメイン + brand\_id | | **アカウント** | 誰が請求されるか? | [アカウント参照](/docs/building/by-layer/L2/accounts-and-agents#account-references) — `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_products` にプロパティリストを渡し、ブランドとガバナンスエージェント間の共同調整のために `calibrate_content` を使用します。ガバナンスエージェントはクリエイティブポリシーで `provenance_required` を強制でき、プロベナンスクレームの `verification` 配列を介したサードパーティ AI コンテンツ検証をサポートします。 キャンペーンガバナンスは `sync_plans`、`check_governance`、`report_plan_outcome`、`get_plan_audit_logs` によるプランレベルのポリシーと予算執行でこれを拡張します。ガバナンスエージェントは `audit`、`advisory`、`enforce` モードで動作でき、委譲された権限に対してセラーサイドのアクションを検証し、共有[ポリシーレジストリ](/docs/governance/policy-registry)を通じて標準化されたポリシーを解決します。 プロパティリスト、コンテンツスタンダード、キャリブレーションを含む完全な仕様。 *** ### スポンサードインテリジェンスプロトコル AI アシスタントでの会話型ブランド体験。SI は AI アシスタントが会話の流れを断ち切ることなく、リッチなエンゲージメント（テキスト、音声、UI コンポーネント）のためにブランドエージェントをどのように呼び出すかを定義します。セッションは同意優先モデルに従う: ユーザーが興味を表明し、同意を付与すると、ブランドエージェントがオプションのトランザクション引き渡しとともに会話的にエンゲージします。 セッションライフサイクル、エージェントの実装、ホストの実装を含む完全な仕様。 *** ### データプロバイダーのシグナルカタログ データプロバイダーはパブリッシャーがプロパティを宣言するのと同じパターンに従い、`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 の変更リストは[リリースノート](/docs/reference/release-notes#version-300-rc2)と [CHANGELOG.md](https://github.com/adcontextprotocol/adcp/blob/main/CHANGELOG.md#300-rc2) を参照。 *** ## rc.3 to 3.0 highlights **rc.3 からアップグレードしますか？** 破壊的変更の表、変更前後の例、移行ステップについては [rc.3 → 3.0 プレリリースアップグレードノート](/docs/reference/migration/prerelease-upgrades) を参照。 ### Specialisms and compliance catalog ストーリーボードは、`get_adcp_capabilities` の新しい `specialisms` フィールドとともに `/compliance/{version}/` のプロトコル内に移動します。21 の専門分野が 6 ドメインにロールアップします。4 つの 3.1 アーキタイプが `status: preview` で出荷されます。[Compliance Catalog](/docs/building/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` は構造化オブジェクト。 削除されたフィールドの完全なリストと移行ステップについては [プレリリースアップグレードノート](/docs/reference/migration/prerelease-upgrades#capabilities-model-simplification) を参照。 ### 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 ピン留めの例については [バージョンネゴシエーション](/docs/reference/versioning#version-negotiation) を参照。 注: 両フィールドは 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 が、バイヤーとセラー間でジャンル分類を正規化します。 コレクションリストの作成と管理のタスクリファレンス。 ### Broadcast TV support リニア TV セラーが完全に AdCP に参加できるようになりました。このリリースは、放送をデジタルから区別するプロトコルプリミティブを追加します。 * **放送クリエイティブ識別子** — クリエイティブアセットとマニフェスト上の `industry_identifiers`、`creative-identifier-type` enum（`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`。バイヤーは、数値が暫定か確定か、どの測定ウィンドウを表すかを知ります。成熟するデータを持つ任意のチャネル（放送、ポッドキャスト、ロングテールコンテンツ）に適用されます。 スポットフォーマット、クリエイティブ識別子、測定ウィンドウ、放送が 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 新しい [プロトコル別の必須タスク](/docs/protocol/required-tasks) リファレンスページが、エージェントの役割別にすべての AdCP プロトコルにわたる必須、条件付き、任意のタスクを統合します — 実装が最小サーフェスをカバーするか検証する単一ページ。 ### Experimental surfaces AdCP 3.0 は、[3.x 安定性保証](/docs/reference/versioning#3x-stability-guarantees)の下で安定サーフェスのコアを出荷し、コアプロトコルの一部だがまだ凍結されていない 4 つのサーフェスを追加します。これらのサーフェスは、卒業パスを形作る本番エンゲージメントでそれらを運用するデザインパートナー — **OpenAds、Scope3、Yahoo、ONX、Triton Digital** — と共同開発されています。実験的サーフェスはスキーマに `x-status: experimental` を運び、それらを実装するセラーは `get_adcp_capabilities` の `experimental_features` で機能 id を宣言します。それらは少なくとも 6 週間の予告をもって 3.x リリース間で変更される可能性があります。 | Surface | Feature id | Why experimental | | --------------------------------------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | [ブランド権利ライフサイクル](/docs/brand-protocol/tasks/get_rights) | `brand.rights_lifecycle` | 3.0 サイクルの後半に追加された法的構成サーフェス。最初のエンタープライズデプロイが、部分的権利、サブライセンス、失効、紛争解決のエッジケースを露呈する。 | | [キャンペーンガバナンス](/docs/governance/campaign/specification) | `governance.campaign` | マルチパーティガバナンスセマンティクス（承認競合、監査来歴、Embedded Human Judgment 下のタイブレーク）はまだ確定していない。 | | [Trusted Match Protocol](/docs/trusted-match/) | `trusted_match.core` | プライバシーアーキテクチャは規制当局の関与とともに進化する。TMPX エクスポージャートークン、国分割されたアイデンティティ、Offer マクロは変更が予想される。 | | [Sponsored Intelligence](/docs/sponsored-intelligence/overview) | `sponsored_intelligence.core` | 会話型ブランド体験は新しい広告モデル。セッションライフサイクル、UI コンポーネント、アイデンティティ/同意オブジェクトの形状、機能ネゴシエーションは、ファーストパーティ AI ホストとブランドエージェントが統合するにつれて進化が予想される。 | 実験的ラベルは意図的にスコープされています — 3.0 の他のすべては通常の 6 か月の非推奨予告に従います。完全なコントラクト、卒業基準、クライアントガイダンスについては [実験的ステータス](/docs/reference/experimental-status) を参照。 ### 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つは分割、削除、または名前変更されました。 チャンネル値を読み書きするすべてのコードを更新する必要があります。 | 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` 配列を使用するようになりました。[クリエイティブの詳細](/docs/reference/migration/creatives#asset-discovery)を参照。 *** ### カタログが 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": "" }` に移行します。 | 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 データを読み書きするすべての実装に影響する: * [ ] チャンネル列挙値を[新しいタクソノミー](/docs/reference/migration/channels)に更新します * [ ] [価格オプション](/docs/reference/migration/pricing)で `fixed_rate` -> `fixed_price` に名前変更します * [ ] `price_guidance.floor` -> `floor_price` に移動する（[価格の詳細](/docs/reference/migration/pricing)） * [ ] `creative_ids` を [`creative_assignments`](/docs/reference/migration/creatives) に置き換える * [ ] [メトロ/郵便ターゲティング](/docs/reference/migration/geo-targeting)にシステム仕様を追加します * [ ] `geo_postal_codes` -> `geo_postal_areas` に名前変更します * [ ] 新しい `geo_metros_exclude` と `geo_postal_areas_exclude` フィールドを処理します * [ ] [`assets` 配列](/docs/reference/migration/creatives#asset-discovery)を使うようにフォーマット解析を更新します * [ ] `preview_image` の読み取りを [`format_card`](/docs/reference/migration/creatives#format-cards-replacing-preview_image) レンダリングに置き換える * [ ] `list_authorized_properties` の呼び出しを `get_adcp_capabilities` ポートフォリオに置き換える * [ ] `promoted_offerings` をクリエイティブマニフェストアセットから削除し、[`catalogs` フィールド](/docs/reference/migration/catalogs)に置き換える * [ ] メディアバイとクリエイティブマニフェストオブジェクトから `promoted_offering` 文字列を削除します * [ ] `optimization_goal` を [`optimization_goals`](/docs/media-buy/media-buys/optimization-reporting)（識別子付きユニオンの配列）に更新します * [ ] `external_id` を AudienceMember の必須フィールドとして処理します * [ ] すべてのタスク呼び出しで `brand_manifest` を `brand` ref（`{ domain, brand_id }`）に置き換える * [ ] `estimated_exposures` の読み取りをプロダクトの `forecast`（DeliveryForecast）に置き換える * [ ] `get_products` リクエストから `proposal_id` を削除する — リファインメントにはセッション継続性を使用します * [ ] `refine` をオブジェクトから `scope` 識別子を持つ型指定された配列に更新します * [ ] リトライ/修正ロジックのためにエラーの `recovery` フィールドを処理します * [ ] パッケージの `catalog` を `catalogs`（配列）に更新します * [ ] シグナルの `account_id` を `account`（AccountReference）に更新します * [ ] シグナルの `deployments` を `destinations` に名前変更します * [ ] `get_products` で `buying_mode`（現在必須）を渡します * [ ] `creative_brief` をマニフェスト `assets` マップの `brief` アセットタイプに移動します * [ ] `kind` と `operator_id` フィールドなしの `report_usage` を処理します * [ ] `SyncCreativesRequest.assignments` をオブジェクトマップから型指定された配列に移行します * [ ] ブランドの `tone` を文字列からオブジェクトフォーマット（`{ voice, attributes, dos, donts }`）に移行します * [ ] `account_resolution` の読み取りを削除する — 代わりに `require_operator_auth` を使用します * [ ] `media_buy.features.sandbox` の代わりに `account.sandbox` からサンドボックスサポートを読む * [ ] DOOH パラメーターが提供される場合、`flat_rate.parameters` の中に `type: "dooh"` を追加します * [ ] `list_creatives` と `sync_creatives` をクリエイティブプロトコル操作として扱います * [ ] `delete_content_standards` の呼び出しを削除する — `update_content_standards` でアーカイブします * [ ] `get_property_features` の呼び出しを削除する — プロパティリストフィルターを使用します * [ ] すべてのリクエスト/レスポンスを v3 スキーマに対して検証します すべてのデータ構造を v3 フォーマット（チャンネル、価格、ジオターゲティング）に更新し、新しいケイパビリティを実装します: * [ ] `get_adcp_capabilities` タスクを実装する（`account` ケイパビリティを含む） * [ ] エージェントカードから `adcp-extension.json` を削除します * [ ] アカウントプロビジョニングのために `sync_accounts` を実装します * [ ] 該当する場合は `get_products` からデリバリー予測付きプロポーザルを返す * [ ] ガバナンスエージェントと統合する場合は `get_products` でプロパティリストフィルタリングをサポートします * [ ] 承認ワークフロー付きで [`sync_catalogs`](/docs/reference/migration/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` をサポートします すべてのリクエストとレスポンス処理を v3 フォーマットに更新し、新しいケイパビリティを統合する: * [ ] 購買を行う前に [`brand.json`](/docs/brand-protocol) でブランドを解決します * [ ] 請求関係を確立するために `sync_accounts` を呼び出す * [ ] ランタイム探索のために `get_adcp_capabilities` を呼び出すように更新します * [ ] セラーが返したプロポーザルとデリバリー予測を評価します * [ ] ブランド/プロパティ解決とエージェント探索のために[レジストリ API](/docs/registry) を使用します * [ ] ガバナンスエージェントと連携するときはプロパティリストを渡してインベントリをフィルタリングします * [ ] ユーザーをブランドエージェントに接続するときは SI セッションを呼び出す * [ ] クリエイティブを送信する前に [`sync_catalogs`](/docs/reference/migration/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` に名前変更します `adagents.json` でシグナルカタログを公開します。[データプロバイダーガイド](/docs/signals/data-providers)を参照。 * [ ] `/.well-known/adagents.json` にシグナルカタログを作成します * [ ] `id`、`name`、`value_type`、オプションのメタデータでシグナルを定義します * [ ] グループ化と効率的な認証のために `signal_tags` を追加します * [ ] `signal_ids` または `signal_tags` 認証タイプを使ってシグナルエージェントを認証します * [ ] AdAgents.json Builder でカタログを検証します 新しいアセット探索をサポートし、ブランドアイデンティティを統合します。フォーマットの `type` フィールド（video、display、audio）は IAB クリエイティブ分類であり、メディアチャンネルではありません。 * [ ] `required` ブールを持つ `assets` 配列をサポートする（`assets_required` を置き換え） * [ ] `preview_image` を `format_card` レンダリングに置き換える * [ ] ブランドに合ったクリエイティブ生成のために `brand.json` でブランドアイデンティティを解決します * [ ] クリエイティブマニフェストで `catalog` フィールドをサポートする（[`promoted_offerings`](/docs/reference/migration/catalogs) アセットを置き換え） * [ ] カタログアイテムをレンダリングするフォーマットで `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` でディスクロージャー持続性サポートを宣言します バイサイドアイデンティティを確立します。[brand.json 仕様](/docs/brand-protocol/brand-json)を参照。 * [ ] ドメインに `/.well-known/brand.json` をホストします * [ ] ブランドポートフォリオ、プロパティ、認証済みオペレーターを宣言します * [ ] オプションで `brand.json` でインラインまたはブランドエージェント経由でブランドデータ（ロゴ、カラー、フォント、トーン）を提供します * [ ] ジェネラティブクリエイティブシステム向けに `brand.json` に `visual_guidelines` を追加します * [ ] コンテンツをライセンスする場合は `get_rights` / `acquire_rights` / `update_rights` を実装します * [ ] `brand.json` をホストしていない場合は[コミュニティブランドレジストリ](/docs/registry)に登録します ブランドスーツアビリティケイパビリティを実装します。[ガバナンスプロトコル](/docs/governance/overview)を参照。 * [ ] プロパティリストタスク（`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`）を実装します 会話型ブランド体験を実装します。[SI チャットプロトコル](/docs/sponsored-intelligence/si-chat-protocol)を参照。 * [ ] SI セッションタスク（`si_initiate_session`、`si_send_message`、`si_terminate_session`）を実装します * [ ] `supported_protocols` に `sponsored_intelligence` を含む `get_adcp_capabilities` を実装します *** ## サポート * **コミュニティ**: [Slack](https://join.slack.com/t/agenticads/shared_invite/zt-3c5sxvdjk-x0rVmLB3OFHVUp~WutVWZg) * **イシュー**: [GitHub Issues](https://github.com/adcontextprotocol/adcp/issues) * **サポート**: [support@adcontextprotocol.org](mailto:support@adcontextprotocol.org)