はじめに
こんにちは。データシステム部・MA推薦ブロックの住安（@kosuke_sumiyasu）です。
私たちのチームは、ZOZOTOWNのメール・LINE・プッシュ通知といったマーケティングオートメーション（MA）の推薦システムを開発・運用しています。目指しているのは、ユーザーひとりひとりに最適な配信を届けることです。
ZOZOTOWNで本番運用されている推薦モデルは、価格・ブランド・カテゴリ・カラーといったテーブル特徴量のみを学習に用いていました。そのため、商品画像が持つ視覚情報（シルエット・質感・カラー・柄）を活用できていませんでした。「オーバーサイズシルエット」や「光沢感」「チェック柄」といった、人が画像から読み取れる「見た目の好み」を推薦に反映できていなかったのです。
下図は、四角い縁のメガネを好むユーザーを例に、画像から「見た目」を捉えることで目指した推薦の姿を示したものです。従来のモデルではカテゴリは「メガネ」で合っていても、丸縁やサングラスといった「見た目」の異なる商品が混ざってしまいます。一方、画像から「見た目」を捉えられれば、ユーザーが好みそうな四角い縁のメガネを中心に推薦できます。
そこで私たちは、商品画像から視覚的特徴を捉えた画像特徴量を生成する仕組みを構築し、既存の推薦モデルに特徴量として組み込むことで、「見た目の好み」を捉えるマルチモーダル推薦システムを実現しました。実際に、この推薦モデルをあるメール配信施策に適用しました。A/Bテストの結果、メール経由サイト流入率（CTR）・メール経由購入率（CVR）・経由売上（メール経由で発生した売上）のすべてで有意な改善が得られました。しかもこの画像特徴量は特定の施策にとどまらず、全社のどの推薦・検索モデルからでも利用できる共通の基盤として提供しています。
本記事では、この取り組みの背景にある課題、画像特徴量を生成・提供する仕組み、そして推薦モデルへの特徴量の組み込みで工夫した点を中心に紹介します。マルチモーダルな特徴量を推薦に活かしたい方の参考になれば幸いです。
目次
背景・課題
前提となる推薦システム
ZOZOTOWNのMAにおけるパーソナライズされたアイテム推薦の一部では、Two-Towerモデルを使用しています。これは、ユーザーを表現するUser Towerと商品を表現するItem Towerの2つのニューラルネットワークからなります。学習済みの各Towerを使うことで、ユーザーと商品の特徴量をそれぞれEmbeddingに変換できます。このEmbeddingは、特徴を捉えた数値ベクトルで、意味の近いものほどベクトルも近くなる性質を持ちます。両Towerの出力を同じ潜在空間上にマッピングするように学習することで、ユーザーとアイテムの近さをコサイン類似度で測れるようになります。推薦時は、任意のユーザーのEmbeddingと各商品のEmbeddingの類似度を計算し、類似度が高い商品から順に推薦します。
ZOZOでは、このEmbeddingをEmbedding基盤として一元管理し、どの部署からでも利用できるようにしています。私たちの汎用推薦システムも、この基盤を使用して配信する商品を選定しています。
課題1: 推薦モデルが「見た目」を捉えられていない
このItem Towerの特徴量は、価格・ブランド・カテゴリ・カラーなどのテーブル特徴量のみでした。そのため、ユーザーの視覚的な嗜好を推薦に反映できないという課題が残っていました。同じカテゴリ・ブランドの商品でも、ユーザーが好むシルエットや柄、質感はさまざまです。しかし従来の推薦モデルは見た目の情報を持たないため、「興味のあるカテゴリやブランドは合っているけれど、見た目の趣味は違う」という結果になりがちでした。例えば筆者は、結婚式用に無地のパステルカラーのネクタイを探していたのですが、柄物ばかりが推薦されてしまい、改善の余地を感じていました。
課題2: 画像Embeddingを全社で利用できる基盤がない
商品画像が持つ視覚情報を推薦に活かすには、それを数値ベクトルに変換した画像Embeddingとして扱うのが有効です。しかし当時は、商品画像すべてを画像Embedding化する仕組みも、それを全社で共有する基盤も存在していませんでした。そのため、各チームが検索や推薦で画像特徴量を使いたくても、それぞれが独自に実装する必要があり、開発工数の増加や品質のばらつきが生じます。そこで本プロジェクトでは、画像Embeddingを常に使える状態で組織に提供し続ける基盤を構築し、それを推薦モデルに組み込むことで「見た目の好み」を捉えられるようにすることを目指しました。
アプローチの全体像
課題を解決するために、大きく2つに取り組みました。
- 画像Embeddingを安定供給する仕組みの構築：商品画像から視覚的特徴を表す画像Embeddingを日次バッチで生成し、BigQueryのVIEWで提供する。どの推薦・検索モデルからでも、常に最新の画像特徴量を利用できる
- 推薦モデルのマルチモーダル化によるパーソナライズ精度向上：その画像Embeddingを推薦モデルのアイテム特徴量として組み込み、「見た目の好み」を捉えてパーソナライズ精度を高める
マルチモーダル推薦は、次の3つのパイプラインで実現しています。
| パイプライン | 役割 |
|---|---|
| generate-image-embedding | 商品画像から画像Embeddingを生成し、BigQueryへ保存する |
| train-product-recommendation | 画像Embeddingを特徴量に加えてTwo-Towerモデルを学習する |
| generate-product-embedding | 学習済みモデルでユーザー・商品のEmbeddingを生成する |
このうち、train-product-recommendationとgenerate-product-embeddingは、もともと運用している既存のパイプラインです。今回はそこに、画像Embeddingを生成するgenerate-image-embeddingを新たに追加しました。あわせて、train-product-recommendationのモデルアーキテクチャと入力特徴量を変更しています。
これらのパイプラインで生成したユーザー・商品のEmbeddingを使って、施策ごとに配信商品を選定します。
以降では、本記事の中心である「画像Embeddingを安定供給する仕組みの構築」と「推薦モデルのマルチモーダル化によるパーソナライズ精度向上」を詳しく紹介します。
画像Embeddingを安定供給する仕組みの構築
画像Embeddingの生成パイプラインは、Agent Platform Pipelines（旧Vertex AI Pipelines）上に実装し、日次バッチで実行しています。全体像は次のとおりです。
処理は大きく4ステップで構成されます。
- Embedding化の対象とするアイテム集合を取得する
- 商品画像を取得し、Cloud Storage（以下GCS）へ保存する
- 事前学習済みの画像モデルで画像Embeddingを生成する
- 生成したEmbeddingをBigQueryへ保存し、VIEWとして提供する
画像Embeddingの生成（ステップ3）には、Hugging Faceで公開されている事前学習済みモデル（SigLIP 2）をGPU上で利用しています。画像の保存先にはGCS、Embeddingの保存先にはBigQueryを使っています。なお、SigLIP 2を採用した理由は、のちほど「モデルの選定」で説明します。
この中で工夫した「差分更新によるコスト削減」と「全社への提供」を順に紹介します。
差分更新によるコスト削減
ZOZOTOWNで扱う商品画像は、サイト上でアクティブな商品に限っても数千万枚の規模にのぼります。これらをすべてEmbedding化すると計算コストが大きいため、各商品（商品×カラー）につき代表の1枚に絞ってEmbedding化しています。それでも対象は数百万枚あり、さらに新着商品を考えると、毎日およそ数十万枚を新たにEmbedding化する必要があります。
これらを毎日すべて計算し直すと、GCSからマシンへ画像を転送するオペレーション料金や、推論時間の増加に伴うマシン料金がかさみ、個々は小さくても積み重なると無視できないコストになります。そこで、すべての画像を毎日計算し直す全件更新ではなく、未処理分のみを計算する差分更新を採用しています。具体的には、次の2つのステップで「まだ処理していないものだけ」を対象にします。
- 画像の保存（ステップ2）：すでにGCSへダウンロード済みの画像は除外し、未取得の商品画像のみを保存する
- Embedding生成（ステップ3）：すでに計算済みのEmbeddingは除外し、未計算の商品画像のみを対象とする
これにより、新着商品だけを処理すればよくなり、ダウンロードコストと計算コストを抑えられます。また、GCSはAgent Platform Pipelinesの実行リージョンと同じRegionalバケットを使うことで、リージョン間レプリケーション費用やエグレス料金も抑えています。
モデル・バージョンを管理し、VIEWで全社へ提供する
画像Embeddingを全社の共通資産として提供するうえで重要になるのが、モデルとバージョンの管理です。精度改善のためにモデルを差し替えたり、複数のモデル・バージョンをA/Bテストで並行させたりすることがあります。そのたびに、利用者が「いまどのモデル名・バージョンが最新で有効か」を追いかけてクエリを書き換えるのは負担が大きく、更新への追従漏れも起こる可能性があります。そこで、利用者がそれらを意識しなくても、常に最新の有効なEmbeddingを取得できる仕組みを用意しました。
具体的には、次の3つのテーブル・VIEWでモデルとバージョンを管理しています。
| テーブル / VIEW | 種別 | 役割 |
|---|---|---|
| product_image_embedding_raw | テーブル | 生成したEmbeddingを、商品ID・モデル名・モデルバージョン・生成日とあわせて追記する。過去分も残すため、複数のモデル・バージョンが共存する |
| model_manifest | テーブル | 提供対象とするモデル・バージョンにアクティブフラグを立てる |
| product_image_embedding | VIEW | model_manifestのアクティブなバージョンに絞り、商品ID × モデル名ごとに最新のEmbeddingを返す |
product_image_embedding_rawテーブルを直接参照する場合は、利用者がクエリのたびにモデル名やバージョンをWHERE句で指定する必要があります。これをVIEWにまとめることで、利用者はproduct_image_embeddingのVIEWを参照するだけで、常にアクティブなモデル・バージョンの最新Embeddingを取得できます。一方でproduct_image_embedding_rawテーブルにはバージョンごとの履歴が残ります。そのため、モデルのA/BテストではTreatment用のVIEWを用意することで、特定バージョンを指定した検証にも対応できます。
この仕組みによって、追跡性と再現性を確保しつつ、A/Bテストにも対応できます。当初の施策にとどまらず、検索や他の推薦面でも安心して利用できる全社共通の資産として提供できるようになりました。
推薦モデルのマルチモーダル化によるパーソナライズ精度向上
画像特徴量を活かしてパーソナライズ精度を高めるために工夫した点を紹介します。工夫したポイントは2つあります。1つ目が「画像Embedding生成モデルの選定」、2つ目が「生成した画像Embeddingを推薦モデルに組み込む方法」です。特に後者が重要で、画像特徴量は単純に足すだけでは効果が薄く、シンプルな2つの工夫を加えることでモデルの精度を大きく改善できました。
モデルの選定
画像Embeddingの生成には、事前学習済みのSigLIP 2を採用しています。SigLIP 2は、CLIPから派生したモデルです。CLIP系のモデルは、画像を扱うImage Encoderと、説明テキストを扱うText Encoderの2つから構成されます。学習時は、対応する画像と説明テキストのペアは近づけ、対応しないペアは遠ざけます。こうした対比的な学習をcontrastive学習と呼び、これにより画像と言語が同じ空間で結びつきます。なお、CLIPがsoftmaxベースの損失を用いるのに対し、採用したSigLIP系はこれをsigmoid損失に置き換えている点が特徴です。
画像が言語の意味と対応づけて学習されるため、得られる画像Embeddingは「柄」「シルエット」「質感」といった視覚的特徴を捉えやすいと考えられます。
CLIP系のモデルの中でSigLIP 2を選んだのは、論文記載のとおり、ゼロショットの分類・検索タスクのベンチマークで良い結果が示されているためです。
事前学習済みモデルを使用した理由
ZOZOの商品画像でファインチューニングする選択肢もありましたが、今回は事前学習済みモデルをそのまま使う方針としました。理由は次の3点です。
- テキスト側の教師データがない：CLIP系の追加学習に必要な、画像とペアになる説明テキストを大規模に用意できていない
- まず有効性を検証したい：画像特徴量が推薦に効くかは未検証のため、まずは低コストに効果を確かめたい
- 基盤モデルの進化が速い：将来、高性能なモデルへ載せ替える余地を残したい
Item Towerへの組み込み
画像Embeddingは、まずItem Towerの入力としてそのまま使えるように整えます。下図のように、画像EmbeddingをItem Towerの入力特徴量の1つ（image_embedding）として追加します。User Tower側は変更せず、Item Tower側にのみ画像特徴量を加えています。
使用した画像Embeddingは768次元です。これを価格やカラーといった他のテーブル特徴量とそのまま結合すると、画像だけで次元の大部分を占めてしまい、他の特徴量の影響が埋もれてしまいます。そこで、画像Embeddingを2層の多層パーセプトロン（768 → 256 → 128）で128次元に圧縮してから、他の特徴量と結合します。これにより、画像とテーブル特徴量の次元のバランスを取りつつ、画像から推薦に効く表現を学習できるようにしています。
ただし、この「圧縮してそのまま結合する」方法だけでは、期待したほどの精度改善が得られませんでした。そこで、さらなる精度改善に向けて次の2つの機構を導入しています。
Gated Multimodal Unit（GMU）で画像の寄与度を動的に制御する
次元を揃えて結合するだけでは、画像をどれだけ重視するかが全商品で一律になってしまいます。しかし本来、画像をどれだけ重視すべきかは商品によって異なります。例えば、Tシャツは柄が選択の決め手になるため画像を重視したい一方、靴下はカラーやブランドといったテーブル特徴量で十分なことが多いです。そこで、画像特徴量の寄与度だけをアイテムごとに動的に調整できるよう、GMUを参考にしたゲート機構を導入しました。
論文の2モダリティ版GMUは2つのモダリティをゲート値で線形補間するため、片方を強調するともう片方が抑制されるトレードオフを持ちます。これに対して本実装は、他の特徴量はそのままで、画像特徴量にのみsigmoidゲートを掛ける一方向型のゲートを採用しました。これは、2モダリティ版GMUからもう片方を抑制する項を取り除いた独自の変種で、アイテムごとに画像特徴量の重みづけだけを調整できます。これにより、カテゴリやブランドなどのアイテム情報から、その商品で画像特徴量をどれだけ重視するかを動的に決められます。
一方向型にした理由は、既存のテーブル特徴量（カテゴリ・価格など）は複数のA/Bテストで有効性が実証されており、その表現力をそのまま維持した状態で、画像特徴量を追加したかったためです。
特徴量単位の Dropout（Feature/Modality Dropout）で特定特徴量への依存を抑える
もう1つの工夫が、学習のたび、入力の一部をランダムにマスクすることで、特定の特徴量への過度な依存を防ぐDropoutです。よく使われるDropoutは個々のニューロン単位でマスクしますが、今回は特徴量単位でマスクするFeature Dropoutを行います。なかでも画像Embeddingは、モダリティ全体を1単位としてマスクし、これを特にModality Dropoutと呼びます。実際には、テーブル特徴量（価格・ブランド・カテゴリ・カラーなど）は各フィールドを、画像Embeddingはモダリティをまるごと1つの塊として、それぞれ独立かつランダムにマスクします。
なぜこれが効くのかを、カラーと画像Embeddingを例に説明します。カラーからもユーザーが好む大まかな色味は学習できますが、画像Embeddingを使えば、より詳細なカラーやシルエット、柄まで捉えられる可能性があります。しかし画像Embeddingは複雑で扱いが難しいため、モデルは学習しやすいカラーにばかり頼り、画像Embeddingを十分に活用しないことがあります。そこでカラーをマスクすると、モデルは画像Embeddingからも学ばざるを得なくなり、画像Embeddingの特徴が使われない状態を防げます。逆に、画像Embeddingに偏りすぎる場合も画像Embeddingをマスクすれば、カラーなどのテーブル特徴量から学べます。こうして、どちらか一方に偏らず、画像Embeddingも含めた幅広い手がかりをバランスよく使う、堅牢なモデルになります。
定量評価（オフライン）
これらの工夫により、画像特徴量なしのベースラインと比べて、オフラインのRecall@100は段階的に改善しました。
| 構成 | Recall@100（ベースライン比） |
|---|---|
| ベースライン（画像特徴量なし） | — |
| ＋ 画像特徴量あり（単純結合のみ） | +1.06% |
| ＋ 画像特徴量あり（Feature/Modality Dropout） | +11.3% |
| ＋ 画像特徴量あり（Feature/Modality Dropout ＋ GMU） | +12.0% |
効果
「見た目の好み」の反映による主要指標の改善
構築したマルチモーダル推薦システムを、1配信あたり約700万人を対象とするメール配信施策のアイテム推薦ロジックに適用し、A/Bテストで効果を検証しました。Control（画像Embeddingなし）とTreatment（画像Embeddingあり）を比較し、CTR・CVRはz検定、経由売上はt検定を用いて有意水準5％で評価しました。
その結果、CTR・CVR・経由売上のすべてで統計的に有意な改善が確認され、TreatmentがControlを上回りました。以下はTreatmentのControlに対する相対改善率です。
| 指標 | 相対改善率 | 有意差 |
|---|---|---|
| CTR（メール経由流入数 / 配信数） | 約 9.9% | あり（勝ち） |
| CVR（メール経由購入数 / 配信数） | 約 14.3% | あり（勝ち） |
| 経由売上（メール経由の受注金額 / 配信数） | 約 10.3% | あり（勝ち） |
ユーザーの「見た目の好み」を捉えた推薦が、実際の流入・購入・売上の改善に結びつくことを確認できました。この結果を受けて本番リリースを決定し、現在は本番環境で稼働しています。
全社共通の画像Embedding基盤の整備
共通基盤の構築により、画像Embeddingを使いたいチームは、生成パイプラインを自前で用意する必要がなく、VIEWを参照するだけで常に最新のEmbeddingを利用できます。これにより、検索や他の推薦面を担当するチームも、開発工数をかけずに効果検証を始められます。さらに、基盤側でモデルを改善すれば、利用側は追加対応なしでその精度向上を受けられます。モデルの差し替えやバージョン管理を基盤の内側に閉じ込めたことで、利用者は中身を意識せずに使い続けることができます。
まとめ
本記事では、商品画像の視覚情報を推薦に活かすマルチモーダル推薦システムの構築を紹介しました。事前学習済みモデルを活用し、少ない工数で画像特徴量を追加して、その有効性まで確かめられました。さらに、生成した画像特徴量を全社で利用できる資産として提供できたことも、大きな成果だと考えています。これにより、画像特徴量を試したい部署は、自分たちで実装しなくてもすぐに効果検証を始められます。そして「画像」という新しい特徴量の軸を手に入れたことで、ここを足がかりに推薦をさらに良くしていけるはずです。
今後の展望
画像Embeddingのさらなる活用と推薦の精度向上に向けて、次のような展開を考えています。
- 画像Embeddingの活用箇所の拡大：整備した共通基盤を活かし、検索・他推薦面へも展開する
- 画像ベースの候補生成への活用：閲覧・購入した商品と視覚的に似た商品を、推薦候補とする
- モデルの高度化：事前学習済みモデルから、ZOZOのデータでファインチューニングしたモデルへ置き換え、ファッションに特化した表現の獲得を目指す
- 画像の前処理の工夫：商品領域をバウンディングボックスで検出してクロップ（切り出し）し、周辺の背景ノイズを除いて視覚的特徴をより正確に捉える
最後に
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
