3.1 の正準フォーマット: 正準フォーマットのパスでは、クリエイティブエージェントは本ガイドは、クリエイティブフォーマットを定義・管理するクリエイティブエージェントの実装方法を解説します。get_adcp_capabilitiesのcreative.supported_formatsを介して何を生成できるかを宣言します(クリエイティブエージェント向けの v1 のlist_creative_formatsのオーバーロードを置き換えます)。各エントリは、プロダクトのインラインformat_options[i]と同じProductFormatDeclarationの形状を使います。canonical-formats を参照。
クリエイティブエージェントとは
クリエイティブエージェントは次を行うサービスです。- フォーマットを定義 - 必要なアセットとその構造を指定
- マニフェストを検証 - クリエイティブマニフェストがフォーマット要件を満たすか確認
- プレビューを生成 - クリエイティブのレンダリング結果を表示
- クリエイティブを構築(任意) - 自然言語ブリーフからマニフェストを生成、既存マニフェストを別フォーマットへ変換、またはライブラリから配信可能なマニフェストとして取得
- クリエイティブライブラリをホスト(任意) - バイヤーが既存クリエイティブをブラウズ・フィルタリングできるようにします
三つのインタラクションモデル
クリエイティブエージェントは、アセットがどのように届くか、出力が何かに基づいて三つの異なるカテゴリに分かれます。自分のエージェントがどのモデルに従うかを特定することが、どのタスクを実装するか、バイヤーがどうやり取りするかを決めます。ステートレス: テンプレートと変換エージェント
例: Celtra、フォーマット変換サービス、リッチメディアテンプレートプラットフォーム バイヤーは呼び出しごとにすべてのアセットをインラインで渡します。あなたのエージェントはテンプレートまたは変換を適用し、結果を返します。永続的なクリエイティブライブラリはありません——すべての呼び出しは自己完結しています。
ケイパビリティ:
supports_transformation: true
バイヤーのワークフロー: あなたのフォーマットを発見 → 実際のアセットでプレビュー → トラフィッキングのためにビルドされたクリエイティブを要求。
ステートフル(事前ロード): アドサーバー
例: Innovid、Flashtalking、CM360 クリエイティブは、プラットフォームの UI または API を通じてロードされ、すでにシステム内に存在します。バイヤーは接続してライブラリを閲覧し、メディアバイの配信タグを要求します。バイヤーはアセットをあなたにプッシュしません——すでにそこにあるクリエイティブを参照します。
ケイパビリティ:
has_creative_library: true
バイヤーのワークフロー: あなたのクリエイティブライブラリを閲覧 → メディアバイごとにタグを要求 → 配信を追跡。
ステートフル(プッシュ): クリエイティブを持つセールスエージェント
例: パブリッシャープラットフォーム、リテールメディアネットワーク、ネイティブ広告プラットフォーム バイヤーはクリエイティブアセットまたはカタログアイテムをあなたのプラットフォームにプッシュします。あなたはそれらを検証、保存し、自分の環境でレンダリングします。カタログ駆動のクリエイティブが面白くなるのはここです——バイヤーはプロダクトフィード、フライトのリスティング、ホテルのインベントリをプッシュし、あなたがそれらをネイティブ広告としてレンダリングするかもしれません。
ケイパビリティ:
has_creative_library: true
バイヤーのワークフロー: あなたの受け入れるフォーマットを発見 → アセットをプッシュ → あなたの環境でプレビュー。
モデルの選び方
鍵となる問いは: アセットはどこから来るか?- バイヤーが呼び出しごとにアセットを送る → ステートレス(テンプレート/変換)
- クリエイティブがすでにシステム内に存在する → ステートフル(アドサーバー)
- バイヤーがホスティングのためにアセットをあなたにプッシュする → ステートフル(セールスエージェント)
get_adcp_capabilities で適切なケイパビリティフラグを宣言してください。
価格とステートフルネス
サービスに課金するクリエイティブエージェントは、アカウント関係を必要とします。価格の追加には次が必要です:- Accounts プロトコルを実装する — バイヤーがレートカードでアカウントを確立
- 発見で
pricing_optionsを公開する —list_creative_formats(変換/生成エージェント)またはlist_creatives(アドサーバー/ライブラリエージェント)で build_creativeのレスポンスで価格を返す —pricing_option_id、vendor_cost、currency、consumptionreport_usageを受け入れる — オーケストレーターが配信された内容をレポートし、収益を追跡できるようにする
エージェントタイプ別の価格発見
変換および生成エージェントは、価格のために
list_creatives を実装する必要はありません——フォーマットがプロダクトなので、list_creative_formats が自然な面です。
価格のウォークスルー
フォーマット適応ごとに課金する変換エージェントの完全なラウンドトリップを示します。 ステップ 1: バイヤーがlist_creative_formats を介して価格を発見する
バイヤーは include_pricing: true と自身の account を指定して list_creative_formats を呼びます。あなたのエージェントはアカウントのレートカードを検索し、各フォーマットに pricing_options を返します:
pricing_options のパターンが代わりに list_creatives に現れます。
ステップ 2: バイヤーがクリエイティブをビルドする
バイヤーは自身の account を指定して build_creative を呼びます。あなたのエージェントは作業を実行し、(アカウントのコミットメントレベル、実行された作業などに基づいて)適用可能な価格オプションをサーバー側で選択し、コストを返します:
pricing_option_id は、どのレートが適用されたかをバイヤーに伝えます。consumption オブジェクトはバイヤーが検証できるようにします: 1 レンダー × 2.00 の vendor_cost。
CPM 価格のクリエイティブ(アドサーバー)では、vendor_cost はビルド時に 0 です——インプレッションが配信されたときにコストが発生します:
report_usage を介して使用量をレポートします。この例は、コストがビルド時ではなく配信中に発生した CPM レポートを示します。pricing_option_id と creative_id が照合のために流れます:
pricing_option_id がアカウントのレートカードと一致することを検証し、レコードを受け入れます。
誰が価格オプションを選ぶのか?
ベンダーエージェントが価格オプションを選びます。バイヤーではありません。バイヤーはbuild_creative に account を渡します——エージェントは、アカウントのレートカード、実行された作業、コミットメントティアに基づいてどの価格オプションが適用されるかを決定します。レスポンスが、何が適用されたかをバイヤーに伝えます。
バイヤーは build_creative リクエストに pricing_option_id を渡しません。バイヤーは list_creatives でオプションを見て、build_creative のレスポンスで適用されたオプションを受け取ります。
エージェントタイプ別の消費フィールド
consumption オブジェクトは情報提供です——バイヤーが vendor_cost がレートカードと整合していることを検証できるようにします。vendor_cost が請求の信頼できる情報源です。
主要要件
1. フォーマット ID の名前空間化
定義するすべてのフォーマットで、競合を避けるために agent URL 付きの構造化フォーマット ID を使用します。agent_urlはエージェントの URL と一致させるidは名前空間内で説明的かつ一意にします- 一貫性のため小文字とアンダースコアを使用します
2. フォーマットの検証
フォーマットがあなたの agent_url を参照する場合、あなたが次の権威となります。- フォーマット仕様
- アセットの検証ルール
- 技術要件
- プレビュー生成
必須タスク
クリエイティブエージェントは次の 2 つのタスクを実装しなければなりません。list_creative_formats
エージェントが定義するすべてのフォーマットを返します。バイヤーはこれによってサポートするクリエイティブフォーマットを発見します。 主な責務:- 必須・任意を含むすべての
assetsを備えた完全なフォーマット定義を返す - 各フォーマットに自分の
agent_urlを含めます format_id値に適切な名前空間を使用します
preview_creative
マニフェストがあなたのフォーマットでどのように描画されるかを示すビジュアルプレビューを生成します。 主な責務:- マニフェストをフォーマット要件に照らして検証します
- マニフェストが無効な場合は検証エラーを返す
- ビジュアル表現(URL、画像、または HTML)を生成します
- プレビューは少なくとも 24 時間アクセス可能にします
任意タスク
build_creative
自然言語ブリーフからクリエイティブマニフェストを生成、既存マニフェストを別フォーマットへ変換、またはライブラリクリエイティブを配信可能なマニフェストとして取得します。 主な責務:- 自然言語ブリーフを解析するか、ライブラリの
creative_idを解決します - 適切なアセットを生成または調達します
- ターゲットフォーマットに有効なマニフェストを返す
- 提供された場合は
macro_valuesをサービングタグに代入します - 任意でプレビュー URL を返す
list_creatives
ライブラリ内のクリエイティブをブラウズ・フィルタリングします。クリエイティブライブラリをホストしており、バイヤーがクエリする必要がある場合に実装します。 主な責務:- 認証済みアカウントからアクセス可能なクリエイティブを返す
- フォーマット、ステータス、タグ、日付範囲によるフィルタリングをサポートします
- 大規模ライブラリのページネーションをサポートします
- 任意でクリエイティブごとの動的クリエイティブ最適化(DCO)変数定義を含めます
sync_creatives
クリエイティブアセットのアップロードをライブラリに受け入れます。プラットフォームがバイヤーによるアセットのプッシュを許可する場合に実装します。 主な責務:- フォーマット仕様に対してクリエイティブを検証します
- プラットフォームが割り当てた ID を含むクリエイティブごとの結果を返す
- アップサートセマンティクスをサポートする(
creative_idで作成または更新) - 任意で一括パッケージアサインメントをサポートする(メディアバイも管理するエージェント向け)
- 任意でブランドセーフティレビューのための非同期承認ワークフローをサポートします
検証のベストプラクティス
マニフェストの検証
マニフェストを検証する際は次を行います。- format_id を確認 - あなたのエージェントを参照しているか
- 必須アセットを検証 - 必須アセットがすべて存在するか
- アセットタイプを確認 - 指定されたタイプと一致するか
- 要件を検証 - 寸法、ファイルタイプ、サイズなど
- URL の到達性 - アセット URL にアクセスできるか(任意だが推奨)
ディスクロージャー要件
クリエイティブブリーフにcompliance.required_disclosures が含まれる場合、クリエイティブエージェントは各ディスクロージャーが生成されたクリエイティブに確実に表示されるようにしなければなりません。ワークフローは次の通り:
-
フォーマットのサポートを確認 — 各
required_disclosures[].positionをフォーマットのsupported_disclosure_positionsまたはdisclosure_capabilitiesと照合します。必要なポジションがフォーマットでサポートされていない場合、暗黙に省略するのではなくバリデーションエラーを返します。disclosure_capabilitiesが存在する場合はそれを使って永続性を考慮したマッチングを行い、フォーマットが必要なポジションと必要な永続性モードの両方をサポートするか確認します。 -
永続性を尊重する — ブリーフが必要なディスクロージャーに
persistenceを指定している場合、クリエイティブエージェントはフォーマットのdisclosure_capabilitiesでその永続性モードをサポートするポジションを使用してこれを満たさなければなりません。たとえば EU AI Act のディスクロージャーに"continuous"永続性が必要な場合、フォーマットはそのポジションをdisclosure_capabilitiesで"continuous"を持つと宣言していなければなりません。ブリーフがpersistenceを省略した場合、フォーマットがそのポジションでサポートする最も厳格な永続性モードを使用します。 -
ディスクロージャーを描画する — サポートするポジションに対して:
footer,overlay,end_card,prominent: ディスクロージャーのtextをクリエイティブ内の指定ポジションに描画しますaudio,pre_roll: 音声として読み上げる。min_duration_msが指定されていれば尊重しますsubtitle: 動画クリエイティブ内にテキストトラックとして含めますcompanion: プライマリクリエイティブと併せてコンパニオン広告ユニットで配信します
-
管轄の範囲を尊重する —
jurisdictions: ["US"]が指定されたディスクロージャーは米国でのみ法的に必要です。ブリーフごとに単一のクリエイティブを生成するエージェントはすべての管轄のディスクロージャーを含めるべきです。管轄ごとのバリアントを生成できるエージェントは、jurisdictionsフィールドでディスクロージャーをフィルタリングします。 -
出所情報に伝播させる — ブリーフが必要なディスクロージャーに
persistenceとpositionを指定している場合、これらをクリエイティブマニフェストのprovenance.disclosure.jurisdictions[].render_guidanceに伝播させる。ブリーフは生成時のドキュメントであり、配信時にパブリッシャーが持つのはブリーフではなくクリエイティブとその出所情報です。クリエイティブエージェントが永続性を出所情報に伝播させない場合、パブリッシャーは規制が要求する永続性を知る方法がない。 -
再生成時も保持する — クリエイティブを再生成またはリサイズする際は、マニフェストに添付された
BriefAssetからすべてのディスクロージャーを引き継ぐ。BriefAssetとはフォーマットのassets配列のbriefタイプのアセットであり、フォーマット変換を経てもディスクロージャーが残存するようクリエイティブブリーフをマニフェスト内に保持します。
overlay ポジションに persistence: "continuous" を指定した "KI-generiert" ディスクロージャー(eu_ai_act_article_50 向け)を要求しています。フォーマットは disclosure_capabilities: [{ "position": "overlay", "persistence": ["continuous", "initial"] }] を宣言しています。フォーマットは continuous overlay をサポートしているため、クリエイティブエージェントはコンテンツ全体を通じて表示される持続的なオーバーレイとしてディスクロージャーを描画します。またエージェントは provenance.disclosure.jurisdictions[] の EU 管轄エントリに render_guidance: { "persistence": "continuous", "positions": ["overlay"] } を伝播させる。
フォーマットの進化
フォーマット定義を更新する際は次を考慮します。- 追加的な変更(
assetsへのrequired: falseな新しい任意アセット)は安全 - 破壊的変更(アセット削除や要件変更)は新しい format_id が必要
youragency.com:format_name_v2のようなバージョニングを検討- 可能な限り後方互換性を維持
デプロイチェックリスト
クリエイティブエージェントを公開する前に確認してください。- MCP および/または A2A エンドポイントにアクセスできます
- すべての format_id が適切に名前空間化されている (
domain:id) - format_id のドメインが
agent_urlのドメインと一致しています -
list_creative_formatsが全フォーマットを返す -
preview_creativeがマニフェストを検証しプレビューを生成します - フォーマット定義に完全なアセット要件が含まれています
- カスタムフォーマットのドキュメントを用意しています
インテグレーションパターン
パターン 1: クリエイティブエージェンシー
ブランド向けにカスタムフォーマットを構築するクリエイティブエージェンシーの場合:パターン 2: プラットフォーム固有フォーマット
専門フォーマットを定義するプラットフォームの場合:パターン 3: フォーマット拡張サービス
標準フォーマットの拡張版を提供する場合:パターン 4: フィードネイティブ/ソーシャルフォーマットエージェント
プラットフォームのフィード内にネイティブコンテンツとして描画する広告フォーマットをホストする場合:preview_creative を呼び出すと、プレビューはバイヤーのアセットをプラットフォームの UI(アバター、エンゲージメントボタン、コミュニティバッジなど)内に描画します。
preview_creative を実装すべき理由です。プラットフォームのクロームが差別化要素となるからです。
プラットフォームのマッピング
既存の広告サーバーやクリエイティブ管理プラットフォームをラップする場合、このセクションでは一般的なプラットフォームの概念がクリエイティブプロトコルにどう対応するかを示します。概念のマッピング
タグ生成モデル
広告サーバーによってサービングタグの生成方法は異なります。クリエイティブプロトコルのbuild_creative は creative_id、target_format_id、オプションの media_buy_id/package_id の組み合わせにより、一般的なモデルすべてに対応します。
ユニバーサルタグ(Celtra、Flashtalking)— 複数の環境(Web、アプリ内)に適応する単一タグ。プレースメントコンテキスト不要 — build_creative(creative_id, target_format_id) でトラフィック先を問わず動作するタグを生成。最終的なトラフィック先が予測しにくいエージェンシー/プログラマティック用途に最適で、トラフィッキングエラーを削減。
シングルプレースメントタグ(Celtra、Flashtalking、CM360)— 特定のサイズとプレースメントにスコープされたタグ。target_format_id で正確な寸法(例: 300x250 Web)を指定。トラフィック先が既知のパブリッシャーテンプレートのユースケースで最も一般的。
マルチプレースメントタグ(Celtra)— 1 つの環境で複数のサイズをカバーするタグ。target_format_id はサポートするサイズを renders 配列で定義するフォーマットを参照。複数のサイズ(例: 300x250 + 320x50 + 728x90 Web)が必要だが単一タグでトラフィックしたいパブリッシャーテンプレートに便利。
プレースメントレベルタグ(CM360)— プラットフォームがクリエイティブではなくプレースメントごとにタグを生成。呼び出し元は media_buy_id とオプションの package_id でトラフィッキングコンテキストを提供。CM360 アダプターはメディアバイコンテキストを使用してターゲットフォーマットにスコープされたタグを生成。
モデルの選択はキャンペーンコンテキストの判断であることが多く、プラットフォームの制約ではありません。同じクリエイティブエージェントが呼び出し元のニーズに応じて異なるタグタイプを生成する場合があります。
すべてのケースで出力は同じです:
html または javascript アセットにサービングコードを持つクリエイティブマニフェスト。
変数モデル
プラットフォームによって動的コンテンツの表現方法は異なります。クリエイティブプロトコルのvariables 配列は一般的なパターンに対応します。
名前付き変数スロット(Flashtalking)— 各クリエイティブは ID、名前、型を持つ明示的な変数を持ちます。creative-variable.json に直接マッピング。
テンプレートオブジェクトプロパティ(Celtra)— テンプレートは特定のコンポーネントとサイズバリアントにスコープされた型付き properties(text, color, image, video, percentage, hidden)を持つ templateObjects を定義します。Celtra アダプターはこれらを variables 配列にフラット化し、テンプレートオブジェクトラベルとプロパティラベルを使って variable_id と name を構築します。
ルールベースのアセット選択(CM360)— 動的クリエイティブはデータフィードから供給されるターゲティングルールを持つ dynamicAssetSelection を使用します。このモデルは変数ベースではなく — CM360 アダプターは通常 variables 配列を持たず、has_variables フィルタリングは適用されない。
マクロ処理
プラットフォームは内部で独自のマクロ構文を使用します。build_creative の macro_values パラメータにより、呼び出し元はユニバーサルマクロ値(例: CLICK_URL)を渡し、クリエイティブエージェントがプラットフォームのネイティブ構文に変換して出力タグに代入します。
クリエイティブエージェントが変換を処理するため、呼び出し元は常にユニバーサルマクロを使用します。
拒否後の再提出
sync_creatives またはクリエイティブレビューで拒否が発生した場合、修正と再提出のフローはアップサートセマンティクスを使用します。
list_creatives(ライブラリのstatus: "rejected")またはget_media_buys(パッケージのapproval_status: "rejected"とrejection_reason)で拒否理由を確認します- クリエイティブを修正する(アセットの更新、コピーの調整、メディアの差し替え)
- 同じ
creative_idでsync_creativesを再提出 — エージェントは既存のクリエイティブを更新してレビューを再トリガーします statusがpending_reviewからapprovedまたはrejectedに変わるまでlist_creativesをポーリングします
実装するタスクの選択
次の表は、各インタラクションモデルを実装すべきタスクにマップします。詳細な説明については上記の三つのインタラクションモデルを参照してください。
バイヤーエージェントが試行錯誤なしに正しいインタラクションモデルを判断できるよう、
get_adcp_capabilities でこれらの機能を宣言してください。仕様のインタラクションモデルを参照。
クリエイティブライブラリを持つプラットフォームは、バイヤーがクエリ前にアクセスを確立できるよう accounts protocol も実装すべきです。これはセールスエージェントがメディアバイで使用するのと同じ accounts protocol です。
関連ドキュメント
- Creative Formats - フォーマット構造の理解
- Creative Manifests - マニフェストの仕組み
- Asset Types - アセット仕様
- list_creative_formats task - フォーマット探索 API リファレンス
- list_creatives task - クリエイティブライブラリ API リファレンス
- build_creative task - マニフェスト生成 API リファレンス
- preview_creative task - プレビュー描画 API リファレンス