仕組み
セールスエージェントはget_adcp_capabilities でクリエイティブプロトコルのサポートを宣言する:
inline_creative_management（購入時にパッケージにクリエイティブを付与するメディアバイ機能）、クリエイティブプロトコルサポート、creative.has_creative_library は別個の宣言であることに注意。セールスエージェントは、クリエイティブライブラリなしでインラインのパッケージクリエイティブを受け入れる、インラインのパッケージアップロードなしでライブラリをホストする、または両方のパスをサポートする、のいずれもできます。
inline_creative_management は create_media_buy と update_media_buy でクリエイティブをパッケージに直接付与することを許可する — クリエイティブは購入またはパッケージ更新とともに移動します。クリエイティブプロトコルサポート（supported_protocols の "creative"）は、エージェントがそのクリエイティブケイパビリティフラグに応じて build_creative、list_creative_formats、sync_creatives などのクリエイティブタスクを実装することを意味します。再利用可能なクリエイティブライブラリは、creative.has_creative_library: true によって明確に表明されます。セールスエージェントは、ライブラリを実装せずにインラインクリエイティブ管理をサポートする（バイヤーがメディアバイのリクエストとともにパッケージスコープのクリエイティブ本体を供給する）、またはインライン管理なしでライブラリをホストする（クリエイティブはパッケージに割り当てる前に sync_creatives で別途同期される）、のいずれもできます。
バイヤーはすべてのタスク — メディアバイとクリエイティブ — を同じエージェント URL で呼び出す。タスクが属するプロトコルがスキーマを決定し、エージェントのタイプは関係ありません。
バイヤーのクリエイティブパスの選択
バイヤーは、メディアバイのインラインフラグとクリエイティブプロトコルのライブラリケイパビリティから、クリエイティブ配信のパスを選びます:inline_creative_management が true で creative.has_creative_library が不在または false の場合、packages[].creatives が表明されたクリエイティブサーフェスです。セラーはそれらのアセットをメディアバイまたはパッケージの一部としてのみ保存するかもしれません。バイヤーは list_creatives、sync_creatives、後の creative_assignments の再利用が機能することを期待すべきではありません。
インライン専用の承認状態の読み戻しはパッケージスコープです。get_media_buys は、パッケージに現在割り当てられているインラインクリエイティブの承認を packages[].creative_approvals[]（creative_id、approval_status、任意の rejection_reason）を通じて表面化しますが、完全なクリエイティブ本体、プレースメントのルーティング、ウェイト、過去のリビジョンは返しません。インライン専用のセラーを使うバイヤーは、後で検査または再提出する必要がある場合、送信したクリエイティブマニフェストまたはアセットペイロードを自分の側で保持すべきです。
利用可能なクリエイティブタスク
セールスエージェントがsupported_protocols に "creative" を宣言すると、任意のクリエイティブプロトコルタスクを実装できる:
これらはスタンドアロンのクリエイティブエージェントが実装するのと同じタスクです。違いは運用上のものであり、プロトコルレベルではない: バイヤーは別のサービスを発見して接続する必要がない。
メディアバイの accounts プロトコルをすでに実装しているセールスエージェントは、クリエイティブタスクのために追加のアカウント設定は必要ない — 同じアカウントが両方のプロトコルをカバーします。
保存クリエイティブのアダプター引き渡し
バイヤーがsync_creatives を通じてクリエイティブをアップロードし、その後 create_media_buy または update_media_buy の creative_assignments を使ってそれをパッケージに付与するとき、AdCP のプロトコルサーフェスが運ぶ識別子は一つだけです: creative_id。バイヤーはクリエイティブの作成または同期時にそれを選び、後でアセットのバイトを再送せずに、その同じ値を再利用して保存したクリエイティブを割り当てます。
下記の例の id フィールドは、二つ目のバイヤー提供の AdCP 識別子ではありません。それは、すでに汎用のアセット id を使う実装層のために、creative_id からコピーされたセラー側のアダプターエイリアスです。AdCP は、上流のアドサーバー、リテールメディアプラットフォーム、セラーの記録システムがこのオブジェクトを使うことを要求しません。この形状は、AdCP の保存クリエイティブを内部のアセットペイロードに変換することを選ぶセラーの SDK、フィクスチャ、アダプター向けの実装ガイダンスです。
実装が URL 裏付けの保存クリエイティブをアダプター層に公開するとき、アダプター向けのオブジェクトは、両方の識別子の綴りに加えて、アセットをトラフィックするのに必要なポータブルなメタデータを保持すべきです（SHOULD）。
アダプター向けの内部オブジェクト（AdCP のリクエストまたはレスポンスの形状ではない）:
test=false
creative_id は正準的な AdCP 保存クリエイティブ識別子です。id は、id フィールドを期待する汎用のアセット契約のためのアダプター互換性エイリアスです。実装は、保存クリエイティブをアダプターアセットに変換するとき、両方を同じ値で埋めるべきです（SHOULD）。アダプターは、両方が存在する場合は creative_id を優先すべきです。AdCP のワイヤー上では、バイヤーは creative_assignments[] に creative_id のみを送ります。アダプター専用の id エイリアスは内部の互換性データであって、二つ目のバイヤー提供の識別子ではありません。セラーは、入力に存在する場合はそれを無視しなければなりません（MUST）。
上記の URL 裏付けのパスがポータブルなアダプターの引き渡しです。スニペット裏付けまたはインラインコンテンツ裏付けの保存クリエイティブ（HTML スニペット、サードパーティタグ、セラーがレンダリングするブリーフコンテンツなど）は、変換がそのアダプターのトラフィッキングモデルに依存するため、明示的なアダプターサポートを必要とします。ドキュメントと SDK のスキャフォールドは、そのアダプターの契約が実際に snippet、content、media_url などのフィールドを宣言し扱わない限り、すべてのアダプターがそれらを受け取ると示唆すべきではありません（SHOULD NOT）。
クリエイティブレビュー
クリエイティブを受け取るセールスエージェント —create_media_buy のインライン付与または sync_creatives 経由 — は、配信前にクリエイティブレビューを実施する場合があります。これは、クリエイティブがポリシーコンプライアンス、マルウェア、またはブランドセーフティ違反のためにスキャンされる実際のパブリッシャーおよび SSP ワークフローを反映しています。
クリエイティブレビューの状態は2つのレベルでサーフェスされます:
- クリエイティブライブラリ:
creative.has_creative_library: trueを表明するセラーでは、list_creativesの各クリエイティブのstatusフィールドはクリエイティブステータス列挙型を使用します:processing、pending_review、approved、rejected、archived。 - パッケージレベル:
get_media_buysレスポンスの各クリエイティブのapproval_statusフィールドはクリエイティブ承認ステータス列挙型を使用します:pending_review、approved、または人間が読める説明付きのrejected。却下されたクリエイティブにはrejection_reasonが含まれます。
approved でも、プレースメント固有のポリシーに違反する場合はパッケージレベルで rejected になる可能性がある（例: オーディオのみのプレースメントでのビデオクリエイティブ）。
バイヤーは、特に厳格なクリエイティブポリシーを持つパブリッシャーの場合、新しいクリエイティブを含むメディアバイを同期または提出した後、list_creatives または get_media_buys をポーリングすべきです。インライン専用のセラーでは、get_media_buys が承認状態の読み戻しサーフェスです。
配信時にセラーが生成する生成フォーマットの場合、クリエイティブレビューは個々のクリエイティブではなくブリーフとブランドアイデンティティに適用されます。セラーはブリーフの制約とブランドアセットが生成が始まる前にポリシーを満たしているかを検証します。
プラットフォームとコミュニティガイドライン: ソーシャルプラットフォーム、UGC サイト、コミュニティ主導のパブリッシャーは、標準的な広告ポリシーを超えたコンテンツポリシー（例: コミュニティスタンダード、プロモートコンテンツガイドライン、カテゴリ固有の制限）を執行することが多い。これらのプラットフォーム固有のポリシーは同じ rejection_reason フィールドを通じてサーフェスされる — バイヤーはそれらを処理するために別のメカニズムを必要としません。コミュニティガイドライン違反でクリエイティブが却下された場合、rejection_reason はどのポリシーが違反されたかを説明し、バイヤーが修正して再提出できるようにします。
生成クリエイティブの実装チェックリスト
生成クリエイティブを提供するセールスエージェントは以下を行うべきだ:-
ケイパビリティを宣言する
get_adcp_capabilitiesで:- クリエイティブケイパビリティの
supports_generation: true supported_protocolsの"creative"- クリエイティブがメディアバイとともに移動する場合は
inline_creative_management: true
- クリエイティブケイパビリティの
-
list_creative_formatsを通じて生成フォーマットを定義する —format_id.agent_urlが自分のエージェントを指します。記述的なフォーマット名とアセット要件（最低限briefアセット）を含めます。 -
preview_creativeを実装する — フライト前レビューのための代表的なプレビューを返します。バイヤーが異なる配信時の条件をシミュレートできるようcontext_descriptionインプットをサポートします。会話型フォーマットの場合、サンドボックステスト用のinteractive_urlを含めます。 -
get_creative_deliveryを実装する — 何が生成され配信されたかを示すバリアントマニフェストを返します。バリアントごとのgeneration_context（context_type、topic、device_class）と配信メトリクスを含めます。バリアント保持を計画する: フライト後の監査のために少なくとも 90 日間のバリアントデータを保持します。 -
購入時にブリーフを検証する — バイヤーが
create_media_buyでブリーフを提出する際、ブリーフの制約（ブランドアイデンティティ、ガードレール、必須開示）が生成ケイパビリティと互換性があることを検証します。そうでない場合は明確なエラーで拒否します。 -
ブリーフのクリエイティブレビューを処理する — 生成フォーマットでは、レビューは個々のクリエイティブではなくブリーフとブランドアイデンティティに適用されます。
get_media_buysのパッケージのapproval_statusを通じてレビュー状態を伝える。
セールスエージェントの生成フォーマット
配信時にクリエイティブを生成するセラー — コンテキスト広告、ページマッチドディスプレイ、AI 生成ネイティブ — は独自の生成フォーマットをホストします。format_id.agent_url はセールスエージェント自体を指す:
list_creative_formats を通じてこのフォーマットを発見し、メディアバイ作成時にブリーフを提供します:
build_creative 呼び出しは不要 — ブリーフはメディアバイとともに移動します。
規制対象カテゴリ（金融サービス、製薬）の場合、エージェントのクリエイティブケイパビリティで supports_compliance: true を確認します。コンプライアンス対応エージェントは生成中に必須開示と規制要素を検証する — エージェントが執行できるよう、ブリーフにコンプライアンス要件を含めます。
生成出力のプレビュー
生成フォーマットでは、preview_creative は2つの目的を果たす:
キャンペーン前 — ブリーフマニフェストと context_description インプットを渡して、エージェントが生成できるものの代表的なサンプルを確認します:
quality: "draft" を使用し、ステークホルダーレビューには quality: "production" を使用します。これらのプレビューは例示的なもの — 実際の出力は配信時のライブシグナルに依存します。プレビューはアクティブなメディアバイを必要としない — create_media_buy を呼び出す前にプレビューできます。
キャンペーン後 — get_creative_delivery の variant_id を渡して、実際に配信されたものを再生する:
配信レポート
両プロトコルを実装するセールスエージェントは、配信データの2つの補完的なビューを提供します:
両タスクは同じエージェント URL で呼び出されます。
media_buy_id と creative_id を結合キーとして使用して、両レスポンスのデータを関連付ける。
生成フォーマットでは、get_creative_delivery がバイヤーが実際に生成されたものを見る場所です。各バリアントにはマニフェスト（実際のレンダリングされたクリエイティブ — ヘッドラインテキスト、画像 URL、フォーマット）と生成コンテキスト（ページトピックやデバイスクラスなど、生成をトリガーしたシグナル）が含まれます。get_media_buy_delivery は支出、ペーシング、次元ブレークダウンを含む集計ビューを提供します。
例: セールスエージェントのバリアントレベルレポート
別のクリエイティブエージェントを使う場合
以下の場合、別のクリエイティブエージェントが適している:- クリエイティブサービスがセラーから独立している — クリエイティブ管理プラットフォーム、広告サーバー、フォーマット変換サービス
- 複数のセラーが同じクリエイティブを配信する必要がある — バイヤーが1か所でクリエイティブを管理して配布します
- バイヤーがセラー間で集中型クリエイティブアナリティクスを望む
ケイパビリティの発見
バイヤーはget_adcp_capabilities を確認して、セールスエージェントがサポートしているものを理解する:
関連ドキュメント
- クリエイティブ仕様 — クリエイティブエージェントのプロトコル要件
- クリエイティブエージェントの実装 — スタンドアロンクリエイティブエージェントの実装ガイド
- 生成クリエイティブ — AI 駆動生成のための
build_creativeの使用 - get_creative_delivery — バリアントレベルの配信レポート
- get_media_buy_delivery — メディアバイ配信レポート
- メディアバイライフサイクル — 状態機械、順序立てられたフロー、保証付きディールの IO パス、クリエイティブ同期のタイミング