preview_creative に渡します。3 つのモードをサポートします。
- 生成（Generation）: ブリーフまたはシードアセットからマニフェストを作成する（
message+creative_manifest） - 変換（Transformation）: 既存のマニフェストを別のフォーマットに適応させる（
creative_manifest+target_format_id） - ライブラリ取得（Library retrieval）: エージェントのライブラリから
creative_idを解決し、広告配信アセット付きのマニフェストを生成します
build_creative はクリエイティブマニフェストを入力として受け取り、クリエイティブマニフェストを出力します。ライブラリ取得では、list_creatives で取得した creative_id を指定すると、エージェントがライブラリから解決します。
フォーマット ID とフォーマットの参照方法については、クリエイティブフォーマット - フォーマットの参照を参照。
リクエストパラメーター
価格レスポンスフィールド
クリエイティブエージェントが課金しaccount が提供された場合、レスポンスには価格フィールドが含まれます:
非同期ビルド（
context_id ポーリングを伴う status: "working"）では、価格フィールドは最終的な完了レスポンスにのみ現れます。
レシピのアイデンティティ
エージェントは、シングルフォーマットの成功レスポンスでトップレベルのrecipe_hash を返してもよく（MAY）、多重度/リファインメントのリーフで variants[].recipe_hash を返してもよい（MAY）。マルチフォーマットの creative_manifests[] レスポンスは、このリビジョンでは recipe_hash を運びません。出力ごとのレシピアイデンティティが必要な場合はバリアント形（max_variants）を要求してください。この値は、ビルドを決定する入力に対する ETag スタイルのアイデンティティです: エージェントが計算し、不透明で、そのエージェントにスコープされます。バイヤーは同じエージェントからのレスポンス間でのみ比較できます。
recipe_hash は、出力バイトや法的/開示のエンベロープではなく、入力レシピを識別します。非決定的なビルドは、同じ recipe_hash で異なるピクセル、タグ、バリアントを返すことがあります。この値は「同じクリエイティブ」ではなく「同じ指示」を意味します。ファンアウトのレスポンスでは、同じレシピから生成された best-of-N リーフは同じ値を共有すべきです（SHOULD）。クライアントが共有ソースで代替をグループ化できるようにするためです。recipe_hash と build_variant_id の両方が現れる場合、build_variant_id が出力リーフとリネージを識別し、recipe_hash は入力レシピを識別します。どちらも他方を含意しません。ビルドからデリバリーへのパフォーマンスの結合には、依然として recipe_hash 単独ではなく、トラフィッキングを生き延びるリネージ識別子を使います。
重要: 必須の入力アセットは、個別のタスクパラメーターとしてではなく、creative_manifest.assets オブジェクトに含めること。フォーマット定義が必要なアセットを指定します。ダイナミッククリエイティブのカタログコンテキストは creative_manifest.assets マップ経由で提供すること。
評価器の認証
build_creative.evaluator は評価器を選択または校正します。評価器の呼び出しを認証するものではありません。評価器の API キー、ベアラートークン、クライアントシークレット、Authorization の値、JWK、JWKS ドキュメント、JWKS URI を、evaluator、context、ext、その他のペイロードフィールドに入れないでください。クレデンシャルまたは信頼素材のペイロードキーは非準拠であり、CREDENTIAL_IN_ARGSで拒否されるべきです。
evaluator.agent_url または evaluator.feature_agent.agent_url が外部の評価器を指す場合、生成を行うクリエイティブエージェントは、通常の AdCP トランスポート認証チャネルを使って、その評価器の get_creative_features エンドポイントを呼びます。評価器は、RFC 9421 のリクエスト署名と JWKS ディスカバリー、mTLS、または事前プロビジョニングされた Bearer/API キークレデンシャルを介して、呼び出し元としてのクリエイティブ/セラーエージェントを認証します。agent_url、account、context、ext のようなペイロードフィールドはアイデンティティの主張ではなく、クレデンシャルとして扱ってはなりません。
許可リストのチェックが依然として最初に行われます: creative_policy.accepted_verifiers[] にない外部評価器の URL は、いかなるアウトバウンド呼び出しの前に EVALUATOR_AGENT_NOT_ACCEPTED で拒否されます。バイヤーは、メディアバイ/プロダクトのコンテキストが公開する場合はセラーの公開する creative_policy.accepted_verifiers[] から、スタンドアロンのクリエイティブエージェント統合ではアカウントのプロビジョニングから、受理される評価器の URL を知ります。URL がリストにあるが評価器に到達できない、またはクリエイティブエージェントのトランスポート認証を拒否する場合、ビルドはビルド全体を失敗させるのではなく、助言的な errors[] の注記とともにセラーデフォルトのランキングに劣化します。
生成コントロール
ジェネレーティブフォーマットでは、生成プロセスを制御する 2 つのオプションパラメーターがあります。-
quality: 生成の忠実度を制御します。高速反復（レイアウト・コピー・構成のレビュー）には"draft"を、最終レンダーには"production"を使用します。ドラフト出力では低解像度の画像、単純化されたエフェクト、またはプレースホルダー要素が使用される場合があります。気に入ったドラフトのプロダクション版を作成するには、そのドラフトの出力マニフェストをcreative_manifestとしてquality: "production"と共に渡します。注意:preview_creativeもqualityを受け取るが、レンダーの忠実度を独立して制御します。ジェネレーティブクリエイティブのプレビューを参照。 -
item_limit: カタログ駆動フォーマットで、生成時に使用するカタログアイテム数を上限設定します。カタログに 1,000 商品あっても、必要なヒーロー画像は 4 枚だけかもしれない。クリエイティブエージェントは関連性またはカタログの順序に基づいて上位アイテムを選択します。item_limitがカタログ要件のmax_items（フォーマットの catalog requirements から）を超える場合、クリエイティブエージェントは小さい方を使用すること。省略した場合、クリエイティブエージェントはカタログサイズとフォーマット要件に基づいて決定します。
ユースケース
純粋な生成（スクラッチからの作成）
純粋な生成では、フォーマットで定義された必須入力アセットを含む最小限のソースマニフェストを提供します。変換（既存クリエイティブの適応）
変換では、完全なソースマニフェストを提供します。フォーマットリサイズ
既存のクリエイティブを別のサイズに変換します。ライブラリ取得
エージェントのライブラリからクリエイティブを取得し、広告配信アセット付きのマニフェストに解決します。list_creatives で creative_id を把握していて、クリエイティブエージェントにタグ（HTML、JavaScript、VAST）付きの配信対応マニフェストを生成させたい場合に使用します。
CLICK_URL マクロは指定した値に置換されました。CACHEBUSTER はセールスエージェントが配信時に解決するためのプレースホルダーとして残っています。
recipe_hash を、広告タグの重複排除、法的/開示の等価性の証明、またはビルド結果と配信されたデリバリーデータの結合に使わないでください。リネージとレポートには build_variant_id とプロモートされた creative_id を使います。
クロスエージェントワークフロー: クリエイティブ生成とメディアバイを異なるエージェントが処理する場合、クリエイティブエージェントの
build_creative でタグ付きマニフェストを生成し、次にセールスエージェントの sync_creatives でアップロードします。セールスエージェントが両方のプロトコルを実装している場合、単一のエンドポイントで行われる。セールスエージェントのクリエイティブ機能を参照。マルチフォーマット生成
target_format_ids を使用して 1 回の呼び出しで複数のフォーマット向けにクリエイティブを生成します。エージェントは同じソースアセットとブリーフからフォーマットごとに 1 つのマニフェストを生成します。
creative_manifest（単数）の代わりに creative_manifests（配列）を使用します。各マニフェストは独自の format_id を持つ完全なクリエイティブマニフェストで、sync_creatives または preview_creative にそのまま使用できます。
FORMAT_NOT_SUPPORTED）、リクエスト全体がエラーレスポンスで失敗します。レスポンス配列の順序は target_format_ids リクエストの順序に対応します。配列の位置または各マニフェストの format_id を比較してマニフェストをリクエストされたフォーマットに対応付ける。
マルチフォーマットワークフロー
マルチフォーマットビルド後、preview_creative バッチモードを使用してすべての結果をプレビューします。ビルドレスポンスの creative_manifests の各要素が、バッチプレビューリクエストの creative_manifest となります。
target_format_id（単数）で build_creative を再度呼び出し、そのフォーマットのマニフェストを渡します。すべてのフォーマットを再ビルドする必要はなく、修正が必要な 1 つだけ反復すれば良い。
include_preview: true を使ったマルチフォーマットリクエストは、フォーマットごとに 1 つのデフォルトプレビューを生成します。カスタム preview_inputs はシングルフォーマットリクエストでのみサポートされます。デバイスバリアント・異なるコンテキストなど、コンテキスト固有のプレビューが必要なマルチフォーマットビルドでは、ビルド後に別途 preview_creative バッチ呼び出しを使用すること。トランスフォーマーとバリアント
transformer_id でトランスフォーマーを選択し（list_transformers で発見）、その params にキー付けした型付き config を与え、max_variants で代替を要求します。エージェントはバリアントレスポンスを返します: creatives[] で、それぞれが variants[] 配列を持ちます。エージェントの best-of-N の選択を表面化するには recommended / rank を読み、望むバリアントを build_variant_id でトラフィックします。
解像度と品質ティアは variant_axis ではなく target_format_ids（または quality）に載せます——バリアントは同じフォーマットに対する代替です。
per_unit × 3）。keep_mode は助言的です。保持は選択した build_variant_id に対する別のトラフィッキングステップです——生成されたマニフェストを sync_creatives を通じてプロモートする際に、その id を creative_id として使います。保持されたバリアントはその後、creative_id がビルドリーフ id である creative レコードを遅延的に得て、report_usage とデリバリーレポートへ流れます。
価格付きの有料ビルド
クリエイティブエージェントが課金しaccount が提供された場合、レスポンスには価格フィールドが含まれます。エージェントは、アカウントのレートカードと実行された作業に基づいてサーバー側で適用可能な価格オプションを選択します——バイヤーはリクエストで pricing_option_id を渡しません。
単位あたりの価格（変換エージェント）:
pricing_option_id は list_creatives のオプションの 1 つに対応します。バイヤーは照合のために report_usage でそれを渡します。
CPM 価格（アドサーバー） — インプレッションが配信されたときにコストが発生するため、ビルド時の vendor_cost は 0 です:
レスポンスフォーマット
シングルフォーマットレスポンス
リクエストでtarget_format_id を使用した場合、レスポンスには単一のクリエイティブマニフェストが含まれます。
マルチフォーマットレスポンス
リクエストでtarget_format_ids を使用した場合、レスポンスにはクリエイティブマニフェストの配列が含まれます。
バリアントレスポンス
リクエストがmax_creatives、max_variants > 1、variant_axis、または refine_from_build_variant_id を使う場合、エージェントは BuildCreativeVariantSuccess 形を返します——シングルフォーマットおよびマルチフォーマットレスポンス（これらは変更されず、1 つのバリアントで 1 つのクリエイティブをビルドするときに引き続き使われます）と並ぶ 3 番目の成功形（oneOf の 6 のうちのメンバー 3）です。
creatives[] 配列は、返された 5 グループのうちの 1 つに省略されています。集計の vendor_cost 0.40 をカバーします——これは表示されたリーフだけでなく、生成されたすべてのリーフの vendor_cost の合計に等しくなります。
- creatives[]: ビルドされたクリエイティブグループごとに 1 エントリ。
max_creativesを使うと、サンプリングされたカタログアイテムごとに 1 エントリになります（catalog_item_refがどのアイテムかを識別）。カタログのファンアウトがない場合は単一のエントリです。これを生成されたグループの集合として扱い、各グループのvariants[]内で代替から選びます。 - creatives[].build_creative_id: このレスポンス内でビルドされたクリエイティブを識別します。
- creatives[].catalog_item_ref: カタログのファンアウトで存在——
item_id（と任意のcatalog_type）でソースカタログアイテムを識別するオブジェクト。 - creatives[].signal_condition: シグナルのファンアウトで存在——このクリエイティブグループが対象とする SignalTargeting 条件（例: weather=rain）。セールス側のパッケージターゲティングと
signal_refのアイデンティティを共有するため、セールスエージェントが互換性のない割り当てを照合・拒否できます。 - creatives[].errors[]: 失敗したカタログアイテムでのみ存在——カタログのファンアウトは非アトミックなので、失敗したアイテムは
errors[]を運びvariants[]を持たないcreatives[]エントリとして返され、バッチを失敗させません。 - creatives[].variants[]: このクリエイティブグループに対して生成された、選ぶための代替。長さは最大でも
max_variants。各バリアントは独自の完全なcreative_manifestを運びます。 - variants[].build_variant_id: 単一のバリアントを識別——リーフレベルのリネージアンカー。これは独自の名前空間です——
preview_id（preview_creativeのレンダー）や配信されたvariant_id（デリバリー時の識別子）をここで再利用しないでください。選択したビルドは、そのbuild_variant_idを渡してトラフィックします。 - variants[].recipe_hash: リーフを生成したビルド決定入力に対する、任意の ETag スタイルのアイデンティティ。エージェントが計算し、不透明で、同じエージェント内でのみ比較可能。同じソースレシピからの best-of-N リーフは値を共有すべきです（SHOULD）。キャッシュの透明性、コスト回避のヒント、レシピレベルのグルーピングに有用ですが、出力の同一性でも、法的/開示の等価性でも、ビルドからデリバリーへの結合でもありません。
- variants[].parent_build_variant_id: リファインされたバリアントでのみ存在（リファインメント）——リファイン元のソースの
build_variant_id。第一世代のビルドでは不在。 - variants[].variant_axis_value: このバリアントが表す
variant_axis次元の値（例: 声、テーマ）。 - variants[].recommended / rank: エージェントの best-of-N の順序付け。
recommended: trueが最上位の選択を、rankが順序を示します。 - variants[].eval:
evaluatorが提供された場合に存在——ゲート後にランク付けするパイプラインからのリーフごとの評価ブロック。評価器のfeature_idにキー付けされたfeatures[]を含みます。 - items_total / items_returned: カタログのファンアウトのカーディナリティ。
items_returned<items_totalは、max_creativesまたはmax_creatives_limitによるサンプリング/クランプを示します。 - vendor_cost（トップレベル）: 生成されたすべてのリーフにわたる集計コスト。個々の
variants[].vendor_costの合計。
build_variant_id は、生成した代替に対する配信前のハンドルです。これは、get_creative_delivery の配信された variant_id（配信されたクリエイティブの実行を識別）とは異なる名前空間です。ビルド時のバリアントは、保持してトラフィックした時点で初めてデリバリーのバリアントになります。
解像度と品質ティアはバリアントではありません。 複数のサイズや品質レベルはフォーマット軸に属します——variant_axis の値としてではなく、target_format_ids（または quality）として渡します。バリアントは同じフォーマットに対する代替です（異なる声、テーマ、または best-of-N のテイク）。
リファインメント
会話的なリファインメントは、以前のバリアントを自由形式の指示で再ビルドします——「もっと暖かく」「CTA を引き締めて」。型付きconfig の面は設計上閉じているので、自由形式の意図は、すでに存在する開かれた面に乗ります: message フィールド（その説明はすでに*「リファインメント時は変更内容を記述します」*）。したがってリファインメントは新しいタスクではなく——1 つ追加の入力を伴う build_creative です:
refine_from_build_variant_id（以前のリーフのbuild_variant_id）に加えて、messageに指示、任意のconfigデルタを渡します。- エージェントはそのリーフから再ビルドし、それぞれ
parent_build_variant_idをソースに設定した新しいバリアントを返します。リファインメントは決して変更ではありません——親リーフは変更されず、新しいリーフは独自のbuild_variant_id（およびトラフィッキング時に独自のcreative_id）を得ます。 transformer_idとターゲットフォーマットは親から継承され、繰り返しません。親と異なるtransformer_idやターゲットフォーマットを渡すことはINVALID_REQUESTです。configは親の config に対するデルタとして適用されます。max_variants/variant_axisと合成されますが（例: 「もっと暖かい 3 テイク」→ 3 つのリファインされたリーフ）、max_creatives/ カタログのファンアウトとは合成されません——カタログではなく、生成された 1 つのクリエイティブをリファインします。- エージェントが
creative.supports_refinement: trueを表明する必要があります（エージェントが定めた期間、生成されたリーフを保持します）。何も保持しないエージェントはUNSUPPORTED_FEATUREを返します。代わりに変換パス（creative_manifest+message）を通じてバイヤー保持のマニフェストをリファインしてください。未知の、または保持されなくなった参照は、error.fieldをrefine_from_build_variant_idに設定したREFERENCE_NOT_FOUNDを返します。
BuildCreativeSuccess は、任意の build_variant_id（エージェントがリファインメントをサポートするときに存在）を運び、それを refine_from_build_variant_id として渡します。出力ごとにリファイン可能なリーフが必要なマルチフォーマットビルドは、素の creative_manifests[] 配列がリーフ id を運ばないため、バリアント形（max_variants）を要求すべきです。
AI 派生物のアトリビューションはマニフェストの既存の provenance に乗ります。parent_build_variant_id はリネージのエッジのみを運びます（リファインメントはツリーへ連鎖します）。
test=false
支出コントロール
ファンアウトとリファインメントは、独立して課金される多くのリーフ（max_creatives × max_variants）を生成でき、per_unit 価格はレートを与えますが事前に単位数を与えません（6 秒のボイスオーバーと 60 秒のものは、同じレートで 10 倍のコストになります）。creative.supports_spend_controls でゲートされた 2 つのオプトインコントロール:
- まず見積もる（
mode: "estimate"）。 ドライラン: エージェントは何も生成せず課金もせず、cost_low/cost_highの帯（およびbasis:fixed= 正確、estimated_units= 生成的な予測、cpm_deferred= 配信時にコストが発生）を持つBuildCreativeEstimateを返します。帯が要となる部分です——セラーがあなたの実際の入力から導出するので、単位数を推測する必要がありません。 - 呼び出しを上限する（
max_spend: { amount, currency }）。 ハードストップ: エージェントは、次のリーフが集計vendor_costをamount超に押し上げるまでリーフを生成し、その後budget_status: "capped"とerrors[]の助言的なBUDGET_CAP_REACHEDを伴う部分的なBuildCreativeVariantSuccessを返します——返されたすべてのリーフは実在し課金され、生成されたものは何も破棄されません。リーフ粒度の不足はleaves_returned<leaves_totalです（items_returned/items_totalではありません。これらはカタログアイテムを数え、バリアントのみやアイテム途中の上限を捉えません）。BUDGET_CAP_REACHEDの助言が権威ある上限シグナルです。最初のリーフでさえ上限を超える場合、呼び出しは終端のBUDGET_CAP_REACHEDで失敗します。currencyはレートカードと一致しなければならず（FX なし）、さもなければリクエストはINVALID_REQUEST（error.field: max_spend.currency）で拒否されます。max_spendはビルド時のvendor_costのみを制限します——CPM 価格のビルド（basis: cpm_deferred）はビルド時に 0 で配信時に発生するので、上限は決して働きません。CPM のファンアウトは代わりにmax_creativesで制限してください。
cost_high を得て、その後 max_spend = cost_high × 安全マージンで実行します（CPM ビルドは例外——ビルド時の cost_high は 0）。max_spend は単一の呼び出しを上限とします。自律的なリファインメントループを制限するには、呼び出しをまたいで集計 vendor_cost を追跡し、発行を止めます（このリビジョンではバイヤーの責任——プロトコルレベルのセッション予算はワーキンググループに先送り）。
見積もりレスポンス
mode: "estimate" のリクエストは、BuildCreativeEstimate 形（oneOf の 6 のうちのメンバー 4）を返します——何も生成せず課金もせず、予測されたコスト帯だけ:
test=false
- estimate.leaves_total =
items_to_produce×variants_per_item（signal_conditionsが送られた場合は ×conditions_total）——mode: "execute"が生成する課金対象リーフの数。 - estimate.cost_low / cost_high / cost_expected: 予測された集計コスト帯。セラーがあなたの実際の入力から導出します。
- estimate.basis:
fixed（フォーマットあたりのフラット——cost_low == cost_high、正確）、estimated_units（生成的なper_unit。帯は単位数の不確実性を反映）、またはcpm_deferred（CPM——ビルド時コストは 0、配信時に発生するので帯は 0）。 - estimate.per_leaf（任意）: リーフごとの内訳。
- 見積もりはこのリビジョンでは助言的/非拘束です（拘束力のある見積もりはワーキンググループに先送り）。
フィールド説明
- creative_manifest: （シングルフォーマット）
sync_creativesまたはpreview_creativeで使用できる完全なクリエイティブマニフェスト - creative_manifests: （マルチフォーマット）リクエストされたフォーマットごとの完全なクリエイティブマニフェストの配列。各要素が独自の
format_idを持ちます。 - format_id: ターゲットフォーマット（リクエストされたフォーマットと一致します）
- assets: アセットキーからアセットコンテンツへのマップ — クリエイティブコンテンツ（画像・テキスト・URL）、カタログ、ブリーフ、フォーマットが必要とするその他すべてを含みます
- expires_at: オプション。マニフェスト内の生成されたアセット URL の有効期限を示す ISO 8601 タイムスタンプ。すべての生成済みアセットの中で最も早い有効期限に設定されます。この時刻を過ぎたら新しい URL を取得するためにクリエイティブを再ビルドすること。マニフェストに有効期限のある URL が含まれない場合（例: 純粋なテキスト生成やアセンブリのみの変換）は存在しません。
- preview: オプション。リクエストで
include_previewが true で、エージェントがインラインプレビューをサポートしている場合に存在します。preview_creativeのシングルレスポンスと同じコンテンツフィールド（previews、interactive_url、expires_at）を含むが、response_typeディスクリミネーターは除く。クライアントが同じプレビューレンダリングロジックを再利用できます。プレビュー URL はpreview_creativeと同じ耐久性契約に従います:expires_atまで、または有効期限が存在しない場合は明示的な帯域外の失効まで、参照解決可能なままです。シングルフォーマットレスポンスでは、previews[]の各エントリがpreview_inputsの入力セットに対応します。マルチフォーマットレスポンスでは、各エントリにformat_idが含まれ、リクエストされたフォーマットの 1 つに対応する（フォーマットごとに 1 つのデフォルトプレビュー。preview_inputsは無視されます）。 - preview_error: オプション。
include_previewが true だったがプレビュー生成が失敗した場合に存在する標準エラーオブジェクト（code、message、recovery）。recoveryフィールドは失敗がtransient（後でリトライ）、correctable、またはterminalのいずれかを示します。「エージェントがインラインプレビューをサポートしない」（フィールドが存在しない、エラーなし）と「プレビュー生成が失敗した」（フィールドが存在し、構造化エラーあり）を区別します。
コンプライアンスエラー
マニフェストにcompliance 要件を持つ brief アセットが含まれており、クリエイティブエージェントがその要件を満たせない場合、エージェントは部分的な成功ではなくエラーを返さなければなりません（MUST）。未充足のディスクロージャーはハードな失敗です。
required_disclosures をターゲットフォーマットで満たせることをバリデートしなければなりません（MUST）。いずれかのディスクロージャーを指定通りに配置できない場合、リクエスト全体が失敗します。これにより、規制対象のクリエイティブが必要な法的テキストなしに配信されることを防ぐ。
レスポンスのタイミング
クリエイティブエージェントがどう応答するかは、操作にどれだけ時間がかかるかによります:
クリエイティブエージェントは、関与する作業に基づいてどの経路を取るかを決めます。ライブラリ取得は即時。単純な変換は数秒。AI 生成はさまざま——手早いバナーは 10 秒で完了するかもしれず、複雑な動画コンポジションは数分かかるかもしれません。
working はポーリングのトリガーではなく進捗シグナル
サーバーが 30 秒超かかると想定するが能動的に処理している場合、帯域外の MCP ステータス更新として working を送ります。これは、呼び出し元をポーリングやウェブフックのパターンに切り替えさせることなく、クライアントに情報を伝え続けます（「取り組んでいます」）。接続は開いたままで、結果は準備ができたときに届きます。
非同期にするとき
submitted は、操作がサーバーの制御外の何かでブロックされていることを意味します:
- 人によるクリエイティブレビュー — ブランドガイドラインが返却前に承認を要求
- 外部の承認ワークフロー — サードパーティのコンプライアンスまたは法的レビュー
push_notification_config でウェブフックを設定します。非同期オペレーションとプッシュ通知を参照してください。
ヒューマンインザループ
エージェントは、人間の入力が必要なときにstatus: "input-required" を返す場合があります——例えば、ブランドガイドラインがクリエイティブ承認を要求する場合や、エージェントがクリエイティブ方向性の明確化を必要とする場合などです。
APPROVAL_REQUIRED— クリエイティブを確定する前に人間の承認が必要CREATIVE_DIRECTION_NEEDED— クリエイティブブリーフまたは方向性について明確化が必要ASSET_SELECTION_NEEDED— アセットの選択肢の中から呼び出し元に選択させる必要があります
ライブラリ取得モード（
creative_id を使用）は通常同期的です。クリエイティブがすでに存在しており、タグ生成のみが必要なためです。非同期が最も一般的なのは生成および変換モードです。ワークフロー統合
一般的な生成ワークフロー
- ビルド:
build_creativeを使用してマニフェストを生成・変換します - プレビュー:
preview_creativeを使用してレンダリングを確認する（preview_creative を参照） - シンク:
sync_creativesを使用して確定したクリエイティブをトラフィッキングします
include_preview: true を設定することで、ステップ 1 と 2 を組み合わせることができます。エージェントがサポートしている場合、レスポンスにはマニフェストと共に preview オブジェクトが含まれ、余分なラウンドトリップが不要になります。エージェントがインラインプレビューをサポートしない場合、フィールドは単純に省略され、別途 preview_creative 呼び出しにフォールバックします。リクエストした際に preview が存在すると仮定するのではなく、常にその存在を確認すること。
preview_quality を使用してビルド品質から独立してレンダーの忠実度を制御します。例えば、quality: "draft"（高速なコンセプト生成）でビルドしながら、preview_quality: "production"（ステークホルダーにレイアウトを見せるためのフルフィデリティレンダー）でプレビューします。preview_quality を省略した場合、エージェントが独自のデフォルトを使用します。
例
例 1: 純粋な生成（ジェネレーティブフォーマット）
ジェネレーティブフォーマットを使用してスクラッチからクリエイティブを生成します。例 2: フォーマット変換
既存の 728x90 リーダーボードを 300x250 バナーに変換します。例 3: 特定の指示を含む変換
特定のデザイン変更を伴うモバイル向けへの変換。例 4: クリエイティブブリーフを使った生成
brand とマニフェストの brief アセットを通じて構造化されたキャンペーンコンテキストを使用してクリエイティブを生成します。
例 5: コンプライアンス要件を含む生成
規制上のディスクロージャーと禁止クレームを含む金融サービスのクリエイティブを生成します。jurisdictions なし）はグローバルに適用されます。prohibited_claims 配列は、生成されたコピーで避けるべきクレームをクリエイティブエージェントに伝える。
例 6: ブリーフと商品カタログを使ったコマースメディア
キャンペーンコンテキスト・コンプライアンスディスクロージャー・同期された商品カタログを含むスポンサー商品カルーセルを生成します。assets マップに一緒に存在します。フォーマットは brief と catalog の両方のアセットタイプを宣言します。バイイングエージェントは list_creative_formats でこれを検出し、送信前に必要なカタログを同期します。
例 7: インラインプレビュー付きビルド
クリエイティブをビルドし、同一レスポンスでプレビューレンダリングを取得します。preview オブジェクトには preview_creative のシングルレスポンスと同じコンテンツフィールド（previews、interactive_url、expires_at）が含まれます。エージェントがインラインプレビューをサポートしない場合、このフィールドは存在しません。バイヤーエージェントは別途 preview_creative 呼び出しにフォールバックします。プレビュー生成が失敗した場合、レスポンスには標準エラーオブジェクト（code、message、recovery）を持つ preview_error が含まれます。
例 8: アイテム制限付きドラフト生成
大規模カタログからドラフト品質のクリエイティブを生成し、アイテム数を上限設定します。item_limit: 4 により生成されるヒーロー画像は 4 枚のみとなります。quality: "draft" はレビュー用の高速・低忠実度の出力を生成します。
レスポンス:
expires_at フィールドは生成された CDN URL の有効期限を示します。この時刻を過ぎたら新しい URL を取得するために再ビルドすること。方向性が承認されたら、最終レンダーのために出力マニフェストを quality: "production" で再送信します。
主要コンセプト
ブランドとクリエイティブブリーフの違い
どちらもオプションです。
brand はドメインの /.well-known/brand.json 経由で解決される安定したブランドアイデンティティ（カラー・ロゴ・トーン）を提供します。ブリーフはマニフェストのアセット（assets.brief）であるため、再生成・リサイズ・監査を通じてクリエイティブと共に移動します。message フィールドはリクエストごとの自然言語の指示を提供します。
優先順位: brand パラメーターはクリエイティブレンダリングコンテキスト（カラー・ロゴ・トーン）の権威あるソースです。
レイヤリング: マニフェストの brief アセットは構造化された方向性を提供し、リクエストの message はリクエストごとの自然言語のオーバーライドを提供します。両方が競合する方向性を提供する場合、message が最も具体的な指示として優先されます。
変換モデル
build_creative はマニフェストイン、マニフェストアウトのモデルに従う。
- 入力: クリエイティブマニフェスト（最小限または完全 — すべてがアセットに存在します）
- 処理:
messageとマニフェストコンテンツに基づいて変換・生成します - 出力: プレビューまたは同期に使用できるターゲットクリエイティブマニフェスト（ブリーフが引き継がれる）
純粋な生成と変換の違い
- 純粋な生成: format_id だけを持つ最小限の
creative_manifest、カタログアセット（フォーマットがカタログアイテムをレンダーする場合）、および必要なシードアセットを提供します。クリエイティブエージェントはmessageをガイドとして使用してスクラッチから出力アセットを生成します。 - 変換: すべての既存アセットを含む完全な
creative_manifestを提供します。クリエイティブエージェントは既存アセットをターゲットフォーマットに適応させ、オプションでmessageのガイダンスに従う。
他のタスクとの統合
- build_creative → マニフェストを生成する（オプションで
include_preview経由のインラインプレビュー付き） - preview_creative → マニフェストを個別にレンダーする（preview_creative を参照）
- sync_creatives → 確定したマニフェストをトラフィッキングします
include_preview: true を使用してビルドとプレビューを 1 回の呼び出しに組み合わせます。エージェントがサポートしない場合、レスポンスは単純に preview フィールドを省略します。別途 preview_creative 呼び出しにフォールバックします。どちらの場合も、プレビューコンテンツフィールド（previews、interactive_url、expires_at）は同一です。
この分離により以下が可能になります。
- 一度ビルドして、異なるコンテキストで複数回プレビューします
- 再同期せずにビルドを反復します
- トラフィッキングにコミットする前にプレビューします
反復的なリファインメント
build_creative はモードフラグなしでマルチターンの反復をサポートします。フィールドの存在と組み合わせがオペレーションを決定します。
- 生成:
message+ 最小限のcreative_manifest（空またはシードアセット）+target_format_id - 変換: 完全な
creative_manifest+message+target_format_id - ライブラリ取得:
creative_id+target_format_id+ オプションのmacro_values - リファインメント: 前の出力を
creative_manifestとして + 変更内容を示す新しいmessage
creative_manifest を新しい message と共に入力として渡します。または、brief アセット（assets.brief）を更新してクリエイティブ方向性を変更します。ブリーフはクリエイティブがどうあるべきかについてのバイヤーが所有する信頼のソースです。