セグメントに合わせた“刺さる”広告画像を生成AIで自動生成

今日の広告では、単に人目を引く画像だけでは不十分です。ターゲットオーディエンスの好み、セグメント、期待に実際に合うクリエイティブが必要です。これはオーディエンスを理解した後の自然な次のステップです。セグメントの好みに関する知識を活かし、心に真に響く画像を作成します（オーディエンスに合わせてカスタマイズ）。

マルチモーダル検索拡張生成（RAG）は、これを大規模に実行するための実用的な方法を提供します。これは、ターゲットセグメント（例：「アウトドア好きの犬の飼い主」）のテキストベースの理解と、意味的に関連のある実際の画像の高速な検索および取得を組み合わせることで機能します。これらの取得された画像は、新しいクリエイティブを生成するためのコンテキストとして使用されます。これにより、顧客データと高品質なコンテンツの間のギャップが埋まり、アウトプットがターゲットオーディエンスの心に響くようになります。

このブログ記事では、最新のAIが、画像検索とマルチモーダルRAGを通じて、広告クリエイティブをより根拠のある適切なものにする方法を、すべてDatabricksを使用してエンドツーエンドで実現する様子をご紹介します。ペットをテーマにしたキャンペーンを実施する架空のペットフードブランド「Bricks」を例に、これが実際にどのように機能するかを紹介しますが、同じ手法は、パーソナライゼーションとビジュアル品質が重要となるあらゆる業界に適用できます。

ソリューションの概要

このソリューションは、Unity Catalog、Agent Framework、Model Serving、バッチ Inference、ベクトル検索、およびAppsを活用して、オーディエンスの理解を、関連性が高くブランドイメージに合ったビジュアルに変換します。下の図は、アーキテクチャの概要を示しています。

1. ストレージ&ガバナンス (Unity Catalog): すべてのソース画像と生成された広告は、Unity Catalog (UC) ボリュームに格納されます。また、バッチ処理のためにソース画像を Delta テーブルに取り込みます。
2. 独自の埋め込み: 軽量なCLIP 画像エンコーダー サービング endpointが画像をベクトルに変換します。Deltaテーブルに対してバッチ推論をランして大規模に埋め込みを生成し、UC Volumeのパスと共に保存し直します。
3. ベクトル検索による検索: 埋め込みは Databricks ベクトル検索でインデックス化され、低レイテンシのセマンティック検索のためにソースの Delta テーブルから自動的に同期されます。短いテキストプロンプトが与えられると、インデックスは上位K件のUCパスを返します。
4. RAG エージェント: ツールを使用するチャット エージェントが、テキスト入力の受け取り → ペットの説明の提案 → テキスト埋め込みのコンピュート → ベクトル検索を呼び出してシード画像を取得 → そしてシードを画像生成モデルに渡す、というワークフローを調整します。
5. Databricksアプリ: ユーザーフレンドリーなアプリがエージェントをユーザーに公開し、セグメントに合わせたパーソナライズ広告画像を生成できるようガイドします。

すべてが UC を介して流れるため、システムは default でセキュアであり、(取得と生成に関する MLflow トレースにより) 監視可能で、(モデルの スワップ、プロンプトの調整により) 進化が容易です。さらに詳しく見ていきましょう。

ストレージとガバナンス (Unity Catalog)

すべてのペット画像アセット（シードとなるペット画像、ブランド画像、最終的な広告）は、UC Volume内に存在します。例:

UC Volumesは、FUSE マウントポイントを備えた画像データ用の効率的なソリューションを提供し、単一のガバナンスプレーンを実現できるため便利です。ノートブック、サービングEndpoint、または Databricks アプリのいずれからファイルにアクセスする場合でも、同じ ACL が適用されます。これは、コード内にブロブキーが存在しないことも意味します。サービス間では、（バイトではなく）パスを渡します。

高速なインデックス作成とガバナンスのために、ボリュームを Delta テーブルにミラーリングし、メタデータと共に生の画像バイト (BINARY 列として) を読み込みます。次にこれをbase64でエンコードされた文字列に変換します（モデルサービングendpointに必要です）。これにより、後続のバッチジョブ（埋め込みなど）がシンプルかつ効率的になります。

これでクエリ可能なテーブルが 1 つになり、人間が判読しやすくアプリで使用できるように、元のボリュームパスも保持されています。

独自の埋め込み

CLIPは、transformerテキストエンコーダーモデルを備えた軽量な画像エンコーダーです。対照学習によってトレーニングされ、ゼロショット分類と検索のために、整列された画像-テキスト埋め込みを生成します。検索を高速かつ再現可能に保つため、Databricks Model Serving endpointの背後でCLIPエンコーダーを公開します。これは、オンライン検索とオフラインバッチ推論の両方に使用できます。エンコーダーをMLflowのpyfunc関数としてパッケージ化し、UCモデルとして登録しlog記録し、カスタムモデルサービングで提供します。そして、SQLからai_queryで呼び出して、Deltaテーブルの埋め込み列を埋めます。

ステップ1: CLIPをMLflow pyfuncとしてパッケージ化する

We wrap CLIP ViT-L/14 as a small pyfunc that accepts a base64 image 文字列 and returns a normalized vector.ロギング後、サービング用にモデルを登録します。

ステップ2: モデルを登録してUCにログする

MLflow を使用してモデルをログに記録し、UC モデルレジストリに登録します。

ステップ 3: エンコーダーのサービング

登録されたモデル用にGPUサービングendpointを作成します。これにより、呼び出し可能で、低レイテンシーかつバージョン管理されたAPIが得られます。

ステップ 4: ai_query を使用したバッチ推論

Delta テーブルに格納された画像を使用して、SQL を使ってその場で埋め込みをコンピュートします。その結果、ベクトル検索 ですぐに使える image_embeddings 列を持つ新しいテーブルが作成されます。

Vector Searchによる検索

Deltaで画像埋め込みをマテリアライズした後、Databricks ベクトル検索で検索可能にします。パターンとしては、自己管理型の埋め込みでDelta Syncインデックスを作成し、次にランタイムにCLIPを使用してテキストプロンプトを埋め込み、top-K類似性検索をランします。サービスは小さく構造化された結果（パス + オプションのメタデータ）を返し、（生のバイトではなく）UC Volumeのパスを渡すことで、パイプラインの残りの部分を軽量で管理された状態に保ちます。

ステップ 1: 埋め込みテーブルのインデックス作成

ベクトルインデックスを一度作成します。埋め込みテーブルから継続的に同期し、低レイテンシーのクエリーに応答します。

インデックスは Delta と同期されているため、埋め込みの新しいテーブル行 (または更新された行) は自動的にインデックスに登録されます。テーブルとインデックスの両方へのアクセスは Unity Catalog の ACL を継承するため、個別の権限は必要ありません。

ステップ 2: ランタイムにおける上位 K 候補のクエリ

推論時には、テキストプロンプトを埋め込み、類似性検索で上位3件の結果をクエリーします。

後でエージェントに結果を渡す際は、レスポンスを最小限で実用的なものに保ちます。ランク付けされた UC パスのみを返します。これにより、エージェントは (ユーザーが最初のシード画像を拒否した場合に) インデックスに再クエリすることなく、パスを順番に試すことができます。

RAG エージェント

ステップ 1: 画像生成サービング endpoint (取得 + 生成)

ここでは、短いテキスト プロンプトを受け取り、2 つのステップを調整するendpointを作成します:

1. 検索: テキストを埋め込み、ベクトル検索 Index にクエリーを実行し、シード画像への上位 3 つの UC Volume パスを（ランク順に）返します
2. 生成: 選択されたシードを読み込み、画像生成 API を呼び出し、最終的な画像を UC ボリュームに upload して、そのパスを返します。

この 2 番目の部分はオプションで、画像生成をランするか、取得のみをランするかに応じて、トグルによって制御されます。

生成ステップでは、Kontext multi-image max モデルを使用して Replicate を呼び出します。この選択は実用的なものです:

• 複数画像の条件付け: Kontextは、シードとなるペットの写真とブランド画像を取り込み、リアルな広告を合成できます。
• 写実性+背景の維持: Kontextは、ペットの元のポーズや環境を維持しつつ、製品を自然に配置する傾向があります。
• 品質 vs レイテンシー: Kontextは、品質とレイテンシーの優れたバランスを提供します。約7～10秒で、比較的高品質な画像を生成します。私たちがテストした gpt-image-1 API 経由の gpt-4o など、他の高品質な画像生成モデルは、約50秒から1分でより高品質な画像を生成します。

生成呼び出し:

UC ボリュームへの書き戻し - ジェネレーターから base64 をデコードし、Files API で書き込み:

必要に応じて、Kontext/Replicateを任意の外部画像API（例: ）で簡単に置き換えることができます。OpenAI）またはDatabricks上で提供される内部モデルを、パイプラインの他の部分を変更することなく使用できます。_replicate_image_generation メソッドの内部を置き換え、入力コントラクト（ペットのシードバイト+ブランドバイト）と出力（PNGバイト → UC upload）を同一に保つだけです。チャットエージェント、リトリーバル、アプリは、画像のペイロードではなくUCパスで動作するため、変更の必要がありません。

ステップ2: チャットエージェント

チャットエージェントは、会話ポリシーを保持する最終的なサービングendpointであり、ツールとして画像生成endpointを呼び出します。ペットの種類を提案し、画像のシード候補を取得し、ユーザーの確認があった場合にのみ最終的な広告画像を生成します。

ツール スキーマは最小限に抑えられています:

次に、エージェントが画像生成 endpoint を呼び出すためのツール実行関数を作成します。この endpoint は、構造化された JSON レスポンスを返します。

replicate_toogle パラメータが画像生成を制御します。

なぜEndpointを分割するのか？

画像生成とチャット エージェントのEndpointを分離しているのには、いくつかの理由があります:

• 関心の分離: 画像生成endpointは決定論的なサービスです (上位 K 件を取得 → オプションで 1 つ生成 → UC パスを返す)。チャット エージェント endpoint が、ポリシーとユーザー エクスペリエンスを担当します。両方とも小規模で、テストや置き換えが容易な状態を維持します。
• モジュール式の拡張性: 画像生成サービスを変更することなく、後から同じインターフェースにツール（例: コピーやCTAの提案、構造化データ取得）を追加してエージェントを拡張できます。

上記はすべてDatabricks Agent Framework上に構築されており、検索と生成を、信頼性が高く管理されたエージェントに変えるためのツールを提供します。まず、このフレームワークでは、画像生成サービス（ベクトル検索を含む）をツールとして登録し、ポリシー/プロンプトから決定論的に呼び出すことができます。また、本番運用用のスキャフォールディングも標準で提供します。チャットループにはResponsesAgentインターフェースを使用し、各ステップでMLflowトレーシングを行います。これにより、本番運用での複数ステップのワークフローのデバッグと運用において、完全な可観測性が得られます。MLflowトレーシングUIでは、これを視覚的に確認できます。

Databricks Apps

Streamlit アプリは、ユーザーがチャットエージェントと会話し、画像をレンダリングできる、単一の会話型エクスペリエンスを提供します。これにより、私たちが構築したすべての要素が、単一の統制された製品エクスペリエンスに統合されます。

全体の仕組み:

• ガバナンスと権限: アプリはDatabricks workspace内で実行され、チャットエージェントのendpointと直接通信します。on-behalf-of（代理）認証情報を使用すると、アプリは閲覧者の権限に基づき、Files API経由でUCパスによってシード画像や最終画像をdownloadできます。ユーザーごとのアクセス制御と明確な監査証跡
• Config as Code: アプリの設定（例: AGENT_ENDPOINT）は、環境変数/シークレット経由で渡されます。
• 明確なインターフェース: チャットサーフェスは、コンパクトなResponsesペイロードをエージェントに送信し、UC Volumeのパスを含む小さなJSONポインターを返されます。その後、UIが画像をdownloadしてユーザーに表示します

以下に、アプリコード内の2つの主要なタッチポイントを示します。まず、エージェントのendpointを呼び出します:

そして、UC Volumeのパスで表示します:

エンドツーエンドの例

システム全体を結び付ける単一のフローを順を追って見ていきましょう。マーケティング担当者が、「都会の若い専門職」向けのカスタマイズされたペット広告画像を生成したいとします。

1. 提案

チャット エージェントがセグメントを解釈し、ペットの種類 (フレンチブルドッグなど) を提案します。

2. 取得 (ツール呼び出し、生成なし)

「はい」の場合、エージェントは検索モードで画像生成endpointを呼び出し、ベクトル検索から類似度でランク付けされた上位 3 つの画像（ボリュームパス）を返します。アプリは候補 #0 をシード画像として表示します。

3. 確認（または反復）

ユーザーが「問題なさそうです」といった趣旨の発言をした場合、処理を続行します。ユーザーが「もう少し」と答えた場合、エージェントはseed_indexを1（次に2）にインクリメントし、同じ上位3件のセットを（追加のベクトルクエリーなしで）再利用して次の選択肢を表示します。3 枚の画像を見てもユーザーがまだ満足しない場合、エージェントは新しいペットの説明を提案し、別の ベクトル検索 呼び出しを trigger します。これにより、軽快で 결정론적인 UXが維持されます。

4. 生成とレンダリング

確認すると、エージェントは replicate_toggle=true と同じ seed_index を使用して endpoint を再度呼び出します。endpointは、UC から選択されたシード画像を読み込み、ブランド画像と組み合わせ、Replicate で Kontext multi-image-max ジェネレータをランし、最終的な PNG を UC Volume にuploadします。UC パスのみが返されます。その後、アプリが画像をdownloadし、ユーザーにレンダリングします。

まとめ

このブログでは、マルチモーダルRAGが高度な広告パーソナライゼーションをいかに実現するかを実証しました。実際の画像検索で生成をグラウンディングすることが、一般的なビジュアルと、特定のオーディエンスの心に響くクリエイティブとの違いを生み出します。これにより、次のことが可能になります。

• より高いビジュアル品質: 写真のシードは、テキストのみのプロンプトでは再現が難しい、より細かいディテールを保持します。
• コンテキスト アライメント: 検索がシーンとペットをオーディエンスのコンテキストに固定することで、メッセージと画像の一貫性を向上させます。
• より予測可能な生成: 複数画像のコンディショニング（シード + ブランド画像）がモデルを制約し、ハルシネーションを削減してブランドセーフティを向上させます。
• 迅速なイテレーション: 上位 3 つのシードを返すことで、広告代理店は再クエリなしで試行を繰り返すことができます。マーケティング担当者は常に状況を把握し、最終的な広告画像の方向性を決定します。

Databricks は、スケーラブルで統制のとれた、高性能なアプリケーションを実現します。このアーキテクチャは、すべてのステップがプラットフォーム内でエンドツーエンドに実行されるため、本番運用に常に対応しています：

• Unity Catalog は、ソース画像と生成画像、テーブル、エージェントなど、すべてを管理します。アクセス、監査、リネージに一貫性があります。
• Delta tables と ベクトル検索 により、埋め込みのトランザクション性が維持され、クエリーは低レイテンシーになります。ダウンストリームに何も変更を加えることなく、メタデータによる再埋め込み、再インデックス、フィルタリングが可能です。
• Model Serving + Mosaic AI Agent Frameworkによって関心が分離されます。画像生成endpointは決定論的なサービスで、チャットエージェントがポリシーとツールをオーケストレーションします。それぞれが独立してスケーリング、バージョン管理、ロールバックを実行します。
• Databricks Appsは UI をデータとサービスの隣に配置し、MLflow tracingはターンごとの可観測性を提供します。

その結果、オーディエンスの知見を、高品質でブランドイメージに合ったクリエイティブに大規模に変換する、モジュール化され管理されたRAGエージェントが実現します。