Skip to main content
3.1 の正準フォーマット: 正準フォーマットのパスでは、クリエイティブエージェントは get_adcp_capabilitiescreative.supported_formats を介して何を生成できるかを宣言します(クリエイティブエージェント向けの v1 の list_creative_formats のオーバーロードを置き換えます)。各エントリは、プロダクトのインライン format_options[i] と同じ ProductFormatDeclaration の形状を使います。canonical-formats を参照。
本ガイドは、クリエイティブフォーマットを定義・管理するクリエイティブエージェントの実装方法を解説します。

クリエイティブエージェントとは

クリエイティブエージェントは次を行うサービスです。
  • フォーマットを定義 - 必要なアセットとその構造を指定
  • マニフェストを検証 - クリエイティブマニフェストがフォーマット要件を満たすか確認
  • プレビューを生成 - クリエイティブのレンダリング結果を表示
  • クリエイティブを構築(任意) - 自然言語ブリーフからマニフェストを生成、既存マニフェストを別フォーマットへ変換、またはライブラリから配信可能なマニフェストとして取得
  • クリエイティブライブラリをホスト(任意) - バイヤーが既存クリエイティブをブラウズ・フィルタリングできるようにします
広告サーバー(CM360、Flashtalking)、クリエイティブ管理プラットフォーム、クリエイティブエージェンシー、パブリッシャー、セールスエージェントがクリエイティブエージェントを実装できます。Media Buy Protocol と Creative Protocol を両方実装するセールスエージェントは、単一エンドポイントから双方の役割を担います — セールスエージェントのクリエイティブ機能 を参照してください。

三つのインタラクションモデル

クリエイティブエージェントは、アセットがどのように届くか、出力が何かに基づいて三つの異なるカテゴリに分かれます。自分のエージェントがどのモデルに従うかを特定することが、どのタスクを実装するか、バイヤーがどうやり取りするかを決めます。

ステートレス: テンプレートと変換エージェント

例: Celtra、フォーマット変換サービス、リッチメディアテンプレートプラットフォーム バイヤーは呼び出しごとにすべてのアセットをインラインで渡します。あなたのエージェントはテンプレートまたは変換を適用し、結果を返します。永続的なクリエイティブライブラリはありません——すべての呼び出しは自己完結しています。 ケイパビリティ: supports_transformation: true バイヤーのワークフロー: あなたのフォーマットを発見 → 実際のアセットでプレビュー → トラフィッキングのためにビルドされたクリエイティブを要求。

ステートフル(事前ロード): アドサーバー

例: Innovid、Flashtalking、CM360 クリエイティブは、プラットフォームの UI または API を通じてロードされ、すでにシステム内に存在します。バイヤーは接続してライブラリを閲覧し、メディアバイの配信タグを要求します。バイヤーはアセットをあなたにプッシュしません——すでにそこにあるクリエイティブを参照します。 ケイパビリティ: has_creative_library: true バイヤーのワークフロー: あなたのクリエイティブライブラリを閲覧 → メディアバイごとにタグを要求 → 配信を追跡。

ステートフル(プッシュ): クリエイティブを持つセールスエージェント

例: パブリッシャープラットフォーム、リテールメディアネットワーク、ネイティブ広告プラットフォーム バイヤーはクリエイティブアセットまたはカタログアイテムをあなたのプラットフォームにプッシュします。あなたはそれらを検証、保存し、自分の環境でレンダリングします。カタログ駆動のクリエイティブが面白くなるのはここです——バイヤーはプロダクトフィード、フライトのリスティング、ホテルのインベントリをプッシュし、あなたがそれらをネイティブ広告としてレンダリングするかもしれません。 ケイパビリティ: has_creative_library: true バイヤーのワークフロー: あなたの受け入れるフォーマットを発見 → アセットをプッシュ → あなたの環境でプレビュー。

モデルの選び方

鍵となる問いは: アセットはどこから来るか?
  • バイヤーが呼び出しごとにアセットを送る → ステートレス(テンプレート/変換)
  • クリエイティブがすでにシステム内に存在する → ステートフル(アドサーバー)
  • バイヤーがホスティングのためにアセットをあなたにプッシュする → ステートフル(セールスエージェント)
一部のエージェントはモデルを組み合わせます。クリエイティブ管理プラットフォームは、テンプレートエンジン(ステートレス変換)とライブラリホスト(ステートフル)の両方かもしれません。バイヤーが正しいインタラクションモデルを判断できるよう、get_adcp_capabilities で適切なケイパビリティフラグを宣言してください。

価格とステートフルネス

サービスに課金するクリエイティブエージェントは、アカウント関係を必要とします。価格の追加には次が必要です:
  1. Accounts プロトコルを実装する — バイヤーがレートカードでアカウントを確立
  2. 発見で pricing_options を公開するlist_creative_formats(変換/生成エージェント)または list_creatives(アドサーバー/ライブラリエージェント)で
  3. build_creative のレスポンスで価格を返すpricing_option_idvendor_costcurrencyconsumption
  4. report_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/フォーマット=2.00/フォーマット = 2.00 の vendor_cost CPM 価格のクリエイティブ(アドサーバー)では、vendor_cost はビルド時に 0 です——インプレッションが配信されたときにコストが発生します:
ステップ 3: バイヤーが使用量をレポートする キャンペーンが配信された後、バイヤーは report_usage を介して使用量をレポートします。この例は、コストがビルド時ではなく配信中に発生した CPM レポートを示します。pricing_option_idcreative_id が照合のために流れます:
あなたのエージェントは、pricing_option_id がアカウントのレートカードと一致することを検証し、レコードを受け入れます。

誰が価格オプションを選ぶのか?

ベンダーエージェントが価格オプションを選びます。バイヤーではありません。バイヤーは build_creativeaccount を渡します——エージェントは、アカウントのレートカード、実行された作業、コミットメントティアに基づいてどの価格オプションが適用されるかを決定します。レスポンスが、何が適用されたかをバイヤーに伝えます。 バイヤーは 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 値に適切な名前空間を使用します
完全な API 仕様は list_creative_formats task reference を参照してください。

preview_creative

マニフェストがあなたのフォーマットでどのように描画されるかを示すビジュアルプレビューを生成します。 主な責務:
  • マニフェストをフォーマット要件に照らして検証します
  • マニフェストが無効な場合は検証エラーを返す
  • ビジュアル表現(URL、画像、または HTML)を生成します
  • プレビューは少なくとも 24 時間アクセス可能にします
完全な API 仕様は preview_creative task reference を参照してください。

任意タスク

build_creative

自然言語ブリーフからクリエイティブマニフェストを生成、既存マニフェストを別フォーマットへ変換、またはライブラリクリエイティブを配信可能なマニフェストとして取得します。 主な責務:
  • 自然言語ブリーフを解析するか、ライブラリの creative_id を解決します
  • 適切なアセットを生成または調達します
  • ターゲットフォーマットに有効なマニフェストを返す
  • 提供された場合は macro_values をサービングタグに代入します
  • 任意でプレビュー URL を返す
完全な API 仕様は build_creative task reference を参照してください。

list_creatives

ライブラリ内のクリエイティブをブラウズ・フィルタリングします。クリエイティブライブラリをホストしており、バイヤーがクエリする必要がある場合に実装します。 主な責務:
  • 認証済みアカウントからアクセス可能なクリエイティブを返す
  • フォーマット、ステータス、タグ、日付範囲によるフィルタリングをサポートします
  • 大規模ライブラリのページネーションをサポートします
  • 任意でクリエイティブごとの動的クリエイティブ最適化(DCO)変数定義を含めます
完全な API 仕様は list_creatives task reference を参照してください。

sync_creatives

クリエイティブアセットのアップロードをライブラリに受け入れます。プラットフォームがバイヤーによるアセットのプッシュを許可する場合に実装します。 主な責務:
  • フォーマット仕様に対してクリエイティブを検証します
  • プラットフォームが割り当てた ID を含むクリエイティブごとの結果を返す
  • アップサートセマンティクスをサポートする(creative_id で作成または更新)
  • 任意で一括パッケージアサインメントをサポートする(メディアバイも管理するエージェント向け)
  • 任意でブランドセーフティレビューのための非同期承認ワークフローをサポートします
完全な API 仕様は sync_creatives task reference を参照してください。

検証のベストプラクティス

マニフェストの検証

マニフェストを検証する際は次を行います。
  1. format_id を確認 - あなたのエージェントを参照しているか
  2. 必須アセットを検証 - 必須アセットがすべて存在するか
  3. アセットタイプを確認 - 指定されたタイプと一致するか
  4. 要件を検証 - 寸法、ファイルタイプ、サイズなど
  5. URL の到達性 - アセット URL にアクセスできるか(任意だが推奨)
検証エラーの例:

ディスクロージャー要件

クリエイティブブリーフに compliance.required_disclosures が含まれる場合、クリエイティブエージェントは各ディスクロージャーが生成されたクリエイティブに確実に表示されるようにしなければなりません。ワークフローは次の通り:
  1. フォーマットのサポートを確認 — 各 required_disclosures[].position をフォーマットの supported_disclosure_positions または disclosure_capabilities と照合します。必要なポジションがフォーマットでサポートされていない場合、暗黙に省略するのではなくバリデーションエラーを返します。disclosure_capabilities が存在する場合はそれを使って永続性を考慮したマッチングを行い、フォーマットが必要なポジションと必要な永続性モードの両方をサポートするか確認します。
  2. 永続性を尊重する — ブリーフが必要なディスクロージャーに persistence を指定している場合、クリエイティブエージェントはフォーマットの disclosure_capabilities でその永続性モードをサポートするポジションを使用してこれを満たさなければなりません。たとえば EU AI Act のディスクロージャーに "continuous" 永続性が必要な場合、フォーマットはそのポジションを disclosure_capabilities"continuous" を持つと宣言していなければなりません。ブリーフが persistence を省略した場合、フォーマットがそのポジションでサポートする最も厳格な永続性モードを使用します。
  3. ディスクロージャーを描画する — サポートするポジションに対して:
    • footer, overlay, end_card, prominent: ディスクロージャーの text をクリエイティブ内の指定ポジションに描画します
    • audio, pre_roll: 音声として読み上げる。min_duration_ms が指定されていれば尊重します
    • subtitle: 動画クリエイティブ内にテキストトラックとして含めます
    • companion: プライマリクリエイティブと併せてコンパニオン広告ユニットで配信します
  4. 管轄の範囲を尊重するjurisdictions: ["US"] が指定されたディスクロージャーは米国でのみ法的に必要です。ブリーフごとに単一のクリエイティブを生成するエージェントはすべての管轄のディスクロージャーを含めるべきです。管轄ごとのバリアントを生成できるエージェントは、jurisdictions フィールドでディスクロージャーをフィルタリングします。
  5. 出所情報に伝播させる — ブリーフが必要なディスクロージャーに persistenceposition を指定している場合、これらをクリエイティブマニフェストの provenance.disclosure.jurisdictions[].render_guidance に伝播させる。ブリーフは生成時のドキュメントであり、配信時にパブリッシャーが持つのはブリーフではなくクリエイティブとその出所情報です。クリエイティブエージェントが永続性を出所情報に伝播させない場合、パブリッシャーは規制が要求する永続性を知る方法がない。
  6. 再生成時も保持する — クリエイティブを再生成またはリサイズする際は、マニフェストに添付された 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: フィードネイティブ/ソーシャルフォーマットエージェント

プラットフォームのフィード内にネイティブコンテンツとして描画する広告フォーマットをホストする場合:
プラットフォーム固有の描画(ダークモード、コミュニティコンテキスト、エンゲージメント UI)はエージェントがプレビューと配信時に処理します。フォーマット定義で指定するのはバイヤーが提供するアセットのみです。エージェントはこれらのアセットをプラットフォームのネイティブクロームでラップします。 バイヤーがフィードネイティブフォーマットに対して preview_creative を呼び出すと、プレビューはバイヤーのアセットをプラットフォームの UI(アバター、エンゲージメントボタン、コミュニティバッジなど)内に描画します。
プレビューレスポンスは各コンテキストでの広告の見え方を示します。バイヤーが他の場所ではプレビューできないコミュニティ固有のクロームも含まれます。これがプラットフォームがシンプルなフォーマットでも preview_creative を実装すべき理由です。プラットフォームのクロームが差別化要素となるからです。

プラットフォームのマッピング

既存の広告サーバーやクリエイティブ管理プラットフォームをラップする場合、このセクションでは一般的なプラットフォームの概念がクリエイティブプロトコルにどう対応するかを示します。

概念のマッピング

タグ生成モデル

広告サーバーによってサービングタグの生成方法は異なります。クリエイティブプロトコルの build_creativecreative_idtarget_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_idname を構築します。 ルールベースのアセット選択(CM360)— 動的クリエイティブはデータフィードから供給されるターゲティングルールを持つ dynamicAssetSelection を使用します。このモデルは変数ベースではなく — CM360 アダプターは通常 variables 配列を持たず、has_variables フィルタリングは適用されない。

マクロ処理

プラットフォームは内部で独自のマクロ構文を使用します。build_creativemacro_values パラメータにより、呼び出し元はユニバーサルマクロ値(例: CLICK_URL)を渡し、クリエイティブエージェントがプラットフォームのネイティブ構文に変換して出力タグに代入します。 クリエイティブエージェントが変換を処理するため、呼び出し元は常にユニバーサルマクロを使用します。

拒否後の再提出

sync_creatives またはクリエイティブレビューで拒否が発生した場合、修正と再提出のフローはアップサートセマンティクスを使用します。
  1. list_creatives(ライブラリの status: "rejected")または get_media_buys(パッケージの approval_status: "rejected"rejection_reason)で拒否理由を確認します
  2. クリエイティブを修正する(アセットの更新、コピーの調整、メディアの差し替え)
  3. 同じ creative_idsync_creatives を再提出 — エージェントは既存のクリエイティブを更新してレビューを再トリガーします
  4. statuspending_review から approved または rejected に変わるまで list_creatives をポーリングします
再提出はレビュークロックをリセットします。エージェントは更新されたクリエイティブをレビュー目的の新しい提出として扱います。

実装するタスクの選択

次の表は、各インタラクションモデルを実装すべきタスクにマップします。詳細な説明については上記の三つのインタラクションモデルを参照してください。 バイヤーエージェントが試行錯誤なしに正しいインタラクションモデルを判断できるよう、get_adcp_capabilities でこれらの機能を宣言してください。仕様のインタラクションモデルを参照。 クリエイティブライブラリを持つプラットフォームは、バイヤーがクエリ前にアクセスを確立できるよう accounts protocol も実装すべきです。これはセールスエージェントがメディアバイで使用するのと同じ accounts protocol です。

関連ドキュメント