has_creative_library: true を宣言するエージェントがホストする: 広告サーバー（CM360、Flashtalking）、クリエイティブ管理プラットフォーム（Celtra）、またはクリエイティブプロトコルも公開するセールスエージェント。
モデル
クリエイティブライブラリは、安定したcreative_id、観測可能なライフサイクル状態、そして任意の一つのメディアバイやパッケージとは別個の割り当て関係を持つ、アカウントスコープのクリエイティブリソースのコレクションです。実装は、完全なアドサーバーライブラリでも、セラーのストレージ上の薄いビューでもかまいませんが、プロトコルのコミットメントは同じです: バイヤーは list_creatives を通じてクリエイティブリソースを読み、sync_creatives を通じて更新し、セラーがそれを保持している間、割り当てをまたいで creative_id で参照できます。
クリエイティブライブラリを表明しないセラーからのインラインパッケージクリエイティブは、ライブラリクリエイティブではありません。それらはパッケージスコープのクリエイティブ添付です: セラーはそれらをメディアバイの一部として受け入れ配信しますが、独立したライブラリ管理やバイをまたぐ再利用は表明しません。
クリエイティブライブラリは3つのレベルでアセットを整理する:
コンセプトはサイズとフォーマットをまたいで関連するクリエイティブをグループ化します。“Holiday 2026” コンセプトは 300x250 バナー、728x90 リーダーボード、30 秒ビデオを含む場合がある — すべて同じキャンペーンアイデアを表現しています。
concept_id を使用してグループとしてフィルタリングと管理を行います。
クリエイティブの状態と割り当ての状態は別物
ライブラリが独立して追跡する二つのもの:- クリエイティブの状態 — クリエイティブ自体のレビューステータス:
processing、pending_review、approved、rejected、archived。クリエイティブエージェントのレビューワークフローが設定します。どこで使われるかに関わらず、ライブラリアセットとしてのクリエイティブに適用されます。 - 割り当ての状態 — クリエイティブと特定のメディアバイ上のパッケージとの関係。バイヤーがクリエイティブを割り当てたとき（
sync_creatives、creative_assignments、またはcreate_media_buyのインラインクリエイティブを介して）に作成されます。メディアバイまたはパッケージが拒否、キャンセル、完了されたとき、またはバイヤーが割り当てを削除したときに解放されます。
- ライブラリ内のクリエイティブは、任意の時点でゼロ個以上のアクティブな割り当てを持ちます。
- メディアバイを拒否、キャンセル、完了すると、その割り当てが解放されます。それはクリエイティブのレビュー状態を変えず、クリエイティブをライブラリから削除せず、他のメディアバイでのクリエイティブの使用にも影響しません。
- 割り当てが存在した後にクリエイティブのレビュー状態が変わったとき（例: セラーが承認を取り消す、または以前に拒否されたクリエイティブを承認する）、セラーは新しい状態に基づいて実行中の配信を続行または停止してもよい（MAY）。バイヤーは、クリエイティブの状態変更後に割り当てレベルの影響を検出するために、
get_media_buysを介してパッケージごとにapproval_statusを再取得すべきです（SHOULD）。クリエイティブレビューを参照。
クリエイティブはキャンペーンより長生きする
クリエイティブは、それを参照するバイとは独立してライブラリに永続化しなければなりません（MUST）。バイの拒否、キャンセル、完了は割り当てのみを解放します——クリエイティブは現在のstatus のままライブラリに残り、後続のバイで再利用できます。これは、クリエイティブがどのようにライブラリに入ったかに関わらず成立します: 明示的な sync_creatives、create_media_buy 上のライブラリ裏付けインラインクリエイティブ、または AdCP を通じて公開されるプラットフォームネイティブなアップロード。基盤となるアドサーバーがバイごとの添付とは別のライブラリオブジェクトを持たないセラーは、バイの存続期間中は list_creatives を通じてバイヤーが同期したクリエイティブを公開し、テアダウン後もその終端状態（archived を含む）を公開し続けることで、このルールを満たします——ライブラリはバイごとのストレージ上の薄いビューでよく、別個のストアである必要はありません。
アクティブな割り当てを超える保持はセラーが定義します。エージェントは、非アクティブ、フライト後の期限切れ、またはストレージポリシーのために未割り当てのクリエイティブをアーカイブしてもよく（MAY、クリエイティブステータスのライフサイクルを参照）、公開済み投稿の認可の期限切れのような回復可能な依存関係の喪失のために approved → suspended へ遷移してもよく（MAY）、ポリシーの失効、テイクダウン、コンテンツドリフトのために approved → rejected へ遷移してもよい（MAY）。バイヤーが同期した後にクリエイティブの状態が変わるときは常に、バイヤーが再利用の前に再同期、置換、またはそのアセットへの依存の停止ができるよう、セラーは新しい状態を観測可能にしなければなりません（MUST）:
- アクティブなメディアバイに影響する状態変更（例: ライブな割り当てを持つクリエイティブの
approved→suspendedまたはapproved→rejected）については、セラーはバイに対応するimpairmentを表面化しなければなりません（MUST）。メディアバイの健全性を参照。 - アクティブな割り当てのないクリエイティブの状態変更（例: セラーが非アクティブのために未割り当てのクリエイティブをアーカイブする）については、セラーは次の
list_creativesの読み取りで新しいstatusを反映しなければなりません（MUST）——snapshot-and-log 契約に従い、そのスナップショットが今日の準拠シグナルです。アカウントスコープのクリエイティブ状態変更のためのプッシュチャネルはクリエイティブライフサイクルウェブフックの RFC の下で定義中です。そのチャネルが出荷されたら、セラーはそれでも追加で発火すべきです（SHOULD）。
list_creatives を介して可用性を確認すべきです（SHOULD）。ライブラリクリエイティブは、バイヤーが供給した入力のバンドル——アップロードされたアセット、ブリーフ、ブランドとカタログのポインタ、またはそれらの組み合わせ——です。保持はバンドルに適用されます。フォーマットのレンダリングされた出力が個別にアドレス可能かどうかはフォーマットレベルの関心事であり、ライブラリの保持とは独立しています。
ライブラリへの接続
クエリ前にアカウントアクセスを確立する:クリエイティブの参照
list_creatives を使用してライブラリを参照します。コンセプト、フォーマット、ステータス、タグ、または日付範囲でフィルタリングする:
status フィールドはライブラリ内のクリエイティブの現在の状態を反映する: processing、pending_review、approved、rejected、archived。ステータス遷移の仕組みについてはクリエイティブレビューを参照。
クリエイティブのアップロード
sync_creatives を使用して新しいクリエイティブをアップロードするか既存のものを更新します。この操作は upsert セマンティクスを使用する — creative_id がすでに存在する場合は更新し、そうでなければ作成します。
list_creatives を確認して pending_review から approved への遷移を確認します。
アサインメント付きアップロード
同じ呼び出しでクリエイティブをパッケージに割り当てる:ライブラリクリエイティブからのタグ生成
ライブラリのクリエイティブに配信タグが必要な場合は、マニフェストの代わりにcreative_id を使って build_creative を使用します:
creative_id を解決し、配信タグを含むマニフェストを返します。タグフォーマットはプラットフォームによって異なる:
- Flashtalking、Celtra: どんな環境にも適応するユニバーサルタグ。プレースメントコンテキスト不要。
- CM360: トラフィッキングコンテキストが必要なプレースメントレベルのタグ。
media_buy_idとpackage_idを渡す:
クリエイティブのキャンペーンへの割り当て
ライブラリクリエイティブをメディアバイに付与するには2つのパスがある:パス 1: パッケージのクリエイティブアサインメント
メディアバイ作成時に ID でライブラリクリエイティブを参照する:sync_creatives またはプラットフォーム独自のアップロードフローを経由して）に機能します。
パス 2: パッケージのインラインクリエイティブ
メディアバイと一緒にクリエイティブを直接アップロードする — 別途同期ステップ不要:creative.has_creative_library: true も表明するセラーでは、エージェントはクリエイティブをライブラリに追加し、1つの操作でパッケージに割り当てます。クリエイティブライブラリを表明しないインライン専用のセラーでは、同じ creatives ペイロードは、再利用可能なライブラリエントリを作成せずにパッケージスコープのアセットを割り当てます。詳細はインラインクリエイティブ管理を参照。
ライブラリ裏付けのインラインクリエイティブは、sync_creatives のアップロードと同じライブラリライフサイクルに従います。 セラーが creative.has_creative_library: true を表明する場合、インライン形式は「1 回の呼び出しで同期して割り当てる」という利便性であって、別個のライフサイクルではありません。提出されると、クリエイティブは sync_creatives の下で持つのと同じレビューフロー、保持、識別子でライブラリに入ります。create_media_buy タスクが pending_manual として解決されバイが決してアクティブにならない場合、またはバイが拒否またはキャンセルされる場合、解放されるのはパッケージの割り当てのみです。クリエイティブはライブラリに残り、後続の create_media_buy 呼び出しで creative_id により参照できます。この割り当て解放の動作はメディアバイ側で規範的です——メディアバイの状態遷移のルールを参照。
インライン専用のセラーでは、バイヤーはクリエイティブ本体をメディアバイのパッケージに添付されたものとして扱うべきです。セラーは、バイをレビュー、配信、置換、監査するのに十分なパッケージスコープのクリエイティブ状態を保持するかもしれませんが、list_creatives、sync_creatives、後の creative_assignments の再利用のような再利用可能なライブラリ操作は表明していません。
クリエイティブレビューはメディアバイの結果とは独立して進みます。セラーは、バイがアクティブにならなかったという理由だけでレビューをスキップしてはなりません（MUST NOT）。バイの拒否はそれ自体では提出されたクリエイティブの拒否を意味しません——クリエイティブの拒否は、含まれるバイのステータスから暗黙的にではなく、それ自身の rejection_reason を持つ意図的なレビューの判断でなければなりません（MUST）。セラーは、将来の割り当てがアクティブになる前にレビューが完了する限り、現在アクティブな割り当てのないクリエイティブのレビューを後回しにしてもよい（MAY）。
ケイパビリティフラグのスコープ。 inline_creative_management: true は、セールスエージェントが create_media_buy と update_media_buy でインラインクリエイティブを受け入れることを表明します。それ自体ではクリエイティブライブラリを表明しません。分離されたライブラリライフサイクルは、セラーが creative.has_creative_library: true も表明する場合に適用されます。
マルチセラー配布
複数のセラーと作業する場合、クリエイティブを一度ビルドして配布する:- クリエイティブエージェントでビルドする:
- 各セラーのライブラリに同期する:
sync_creatives を個別に呼び出す。セラー間で同じ creative_id と concept_id を使用して、メディアバイ全体で同じクリエイティブとキャンペーンコンセプトを関連付けられるようにします。完全なパターンはマルチエージェントクリエイティブオーケストレーションを参照。
- セラーごとに承認状態を追跡する — 各セラーは独立してレビューします。各エージェントで
list_creativesをポーリングしてステータスを確認します。クリエイティブはポリシーに基づいて、あるセラーではapproved、別のセラーではrejectedになる場合があります。
承認状態の追跡
クリエイティブの承認は2つのレベルで動作する: ライブラリレベル:list_creatives の各クリエイティブの status フィールド — processing、pending_review、approved、rejected、archived。
パッケージレベル: get_media_buys の各クリエイティブの approval_status — pending_review、approved、または rejection_reason 付きの rejected。
クリエイティブはライブラリでは approved でも、プレースメント固有のポリシーに違反する場合はパッケージレベルで rejected になる可能性があります。新しいクリエイティブを同期またはメディアバイに提出した後は、両方をポーリングします。
ダイナミッククリエイティブ最適化（DCO）
動的コンテンツ変数を持つクリエイティブは、include: { variables: true } を要求するとライブラリに variables 配列付きで表示されます。各変数は広告サーバーが配信時に埋める槽を定義します:
list_creatives フィルターで has_variables: true を使用して DCO クリエイティブを見つける。変数タイプは一般的なプラットフォームパターンと一致する: text、color、image、video、number、boolean。
広告サーバーが配信時にこれらの変数をどのように使用するか（データフィード、ターゲティングルール、最適化アルゴリズム）は AdCP のスコープ外です。AdCP は変数のスロットをモデル化し、最適化ロジックはモデル化しません。
次のステップ
- 生成クリエイティブ — AI 駆動のクリエイティブ生成とメディアバイ内のブリーフワークフロー
- セールスエージェントのクリエイティブ機能 — セラーがメディアとクリエイティブの両方を管理する場合
- クリエイティブエージェントの実装 — プラットフォームを中心に AdCP クリエイティブエージェントを構築します
- sync_creatives リファレンス — アップロード API の詳細
- list_creatives リファレンス — 完全なフィルタリングオプションを含むクエリ API の詳細