はじめに
こんにちは。データシステム部・MA推薦ブロックの伊藤（@rabbit_x86）です。私たちのチームでは、メール配信などのマーケティングオートメーション（MA）に関する推薦システムを開発・運用しています。
従来、ZOZOTOWNのMA施策における推薦システムでは、開発リードタイムと推薦精度のトレードオフが課題でした。この課題を解決するため、ユーザーとアイテムをベクトルで表現したEmbeddingとBigQuery Vector Searchを活用し、施策を横断して利用可能な汎用推薦システムを開発しました。本システムにより、開発リードタイムを約1/3に短縮し、A/Bテストで配信当たりのMA経由流入数・購入数の改善を達成しました。
本記事では、このシステムの設計思想・アーキテクチャ・構築時の技術的な課題と工夫、そして実際の事例を紹介します。
目次
背景と課題
従来の推薦アプローチとそのトレードオフ
MA施策では、対象ユーザー（ユーザーセグメント）と対象アイテム（アイテムセグメント）を施策ごとに定義し、パーソナライズされた商品を提供しています。その推薦システムは、「ルールベース」と「機械学習ベース」の2つのアプローチで構築されています。ルールベースは閲覧したカテゴリの商品を推薦するなど、行動ログに基づくルールでスコアリングするアプローチです。機械学習ベースは行動ログを活用しつつ、モデルが学習した潜在的な嗜好をもとに推薦するアプローチです。
これらのアプローチには精度と開発リードタイムのトレードオフが存在し、ルールベースは高速だが推薦精度が低く、機械学習ベースは精度が高い一方で開発リードタイムが長いという課題がありました。
| ルールベース | 機械学習ベース | |
|---|---|---|
| ロジック | 閲覧履歴・お気に入りなどの行動ログに基づくヒューリスティクス | 専用の推薦モデルが学習した潜在的な嗜好に基づくスコアリング |
| 開発リードタイム | 短い | 長い |
| 精度 | 低い | 高い |
機械学習ベースの開発リードタイム
機械学習ベースの推薦にはモデルを実装する必要があり、施策ごとに以下の一連の開発工程を繰り返します。
| 工程 | 所要期間 |
|---|---|
| 探索的データ分析 | 約2週間 |
| モデルの設計・実装 | 約3週間 |
| パイプラインの設計・実装 | 約2週間 |
| 実験・評価・チューニング | 約3週間 |
この結果、1施策あたり約10週間の開発リードタイムが必要となり、仮説検証のサイクルが遅くなっていました。
ルールベースによる推薦の限界
一方、ルールベースのロジックでは、閲覧履歴やお気に入りブランドなど、ユーザーの顕在的な嗜好に基づく推薦が中心です。たとえば、「ブランドAを閲覧したユーザーにブランドAの値下げ商品を推薦する」といったルールなどです。こうしたルールは設計が容易な反面、ユーザーが触れた商品のみを推薦し、ユーザーの潜在的な嗜好を考慮した推薦ができないという課題がありました。
システム要件
そこで、高速なモデル構築と高い推薦精度を両立する仕組みが必要でした。
要件をまとめると以下のとおりです。
| 要件 | 詳細 |
|---|---|
| 高速な推薦システム構築 | 推薦システムを短期間で構築できること |
| 高い推薦精度 | ユーザーの潜在的な嗜好を捉えた推薦ができること |
アプローチ
上記の要件を満たすため、社内のEmbedding基盤とBigQuery Vector Searchを活用した汎用推薦システムを開発しました。
前提知識：EmbeddingとEmbedding基盤
Embeddingとは、データを固定長のベクトルとして表現する手法です。社内のEmbedding基盤では、ユーザーの行動履歴をもとにTwo-Towerモデルを使い、ユーザーとアイテムの類似度が意味を持つように共通の次元数の埋め込み空間へそれぞれエンコードします。ベクトル間のコサイン類似度を計算することで、ユーザーの潜在的な嗜好に近いアイテムを特定できます。
Embedding基盤については、推薦基盤ブロックで執筆した以下の記事で詳しく紹介しています。
汎用推薦システム
本システムは1つのモデルで複数の施策に対応できる汎用的な仕組みです。セグメントを定義してEmbeddingを抽出し、BigQuery Vector Searchで類似度を計算することで、パーソナライズされた推薦結果を生成します。従来必要だった特徴量作成やモデル学習が不要になるため、開発リードタイムを短縮できます。
さらに、Embeddingを利用することで、ルールベースでは捉えられなかったユーザーの潜在的な嗜好を反映した高い推薦精度を実現します。施策の目的に応じて関連スコアの調整やフィルタリングなどの後処理も適用でき、細かなチューニングにも対応できます。
全体構成
本システムは、社内のMLパイプライン基盤であるVertex AI Pipelinesで実行されます。
パイプラインの主要ステップを以下の表にまとめます。
| ステップ | 処理内容 | 実行環境 |
|---|---|---|
| 1. セグメント抽出 | ユーザーセグメント・アイテムセグメントをSQLで抽出 | BigQuery |
| 2. Embedding取得 | セグメントに対応するEmbeddingをEmbedding基盤から取得 | BigQuery |
| 3. Vector Index作成 | アイテムEmbeddingにTREE_AHインデックスを作成し、完了まで待機 | BigQuery |
| 4. Vector Search | ユーザーEmbedding × アイテムEmbeddingの関連スコアを算出 | BigQuery |
| 5. スコアブースト・フィルタリング | 関連スコアのブースト・ペナルティによるリランキング | BigQuery |
| 6. 評価・バリデーション | 定量評価（Vertex AI Experiments）、ポリシーチェック | BigQuery / Vertex AI |
1. セグメント抽出
施策ごとに定義されたSQLクエリで、対象ユーザーと対象アイテムを抽出します。たとえば、「過去30日以内にアクティブなユーザー」や「特定カテゴリの新着アイテム」などです。このSQLを差し替えるだけで、さまざまな施策へ対応できる設計です。
2. Embedding取得
Embedding基盤から、抽出したユーザー・アイテムに対応するEmbeddingを取得します。
3. Vector Index作成
Vector Searchの高速化のため、アイテムEmbeddingテーブルへCREATE VECTOR INDEXでインデックスを作成します。本システムでは大規模バッチ向けのTREE_AH（GoogleのScaNNアルゴリズムベース）を採用しています。Vector Indexの構築にまつわる課題と対処法は、後述の「技術的な課題と工夫」で説明します。
4. Vector Search
BigQueryのVECTOR_SEARCH関数を用いてユーザーEmbeddingとアイテムEmbeddingのコサイン類似度を計算し、ユーザーごとに関連スコアの高い上位N件のアイテムを取得します。
-- Vector Searchの実行例（簡略化） SELECT query.member_id, base.product_id, distance FROM VECTOR_SEARCH( (SELECT * FROM candidate_embeddings), -- アイテムEmbedding 'embedding', (SELECT * FROM query_embeddings), -- ユーザーEmbedding 'embedding', top_k => 100, distance_type => 'COSINE' )
5. スコアブースト・フィルタリング
Vector Searchで得られた関連スコアは、そのままでは施策の目的に最適化されていません。そこで、ブーストやペナルティによるリランキングとフィルタリングを行い、最終的な推薦結果を生成します。
生成された推薦結果はBigQueryのテーブルに保存され、MAの配信システムがこのテーブルを読み込むことで連携します。
6. 評価・バリデーション
パイプラインの最終ステップとして、推薦結果の品質を評価・検証します。
| 評価種別 | 内容 | 記録先 |
|---|---|---|
| 定量評価 | NDCG、Precision、Recall等の指標を記録 | Vertex AI Experiments |
| ポリシーチェック | 推薦結果がセグメント条件を満たすか、1ユーザーあたりの推薦数が閾値以上かなどを検証 | BigQuery |
技術的な課題と工夫
Vector Indexの非同期構築への対処
BigQueryのVector Indexは非同期で構築されるため、実行直後にはインデックスが利用可能になりません。インデックスが未完成の状態でVector Searchを実行すると、ブルートフォース（全件スキャン）で計算するため、実行時間とスロット消費が膨大になります。
この問題に対処するのが、全体構成図におけるIndex完了待ちのコンポーネントです。以下のクエリでINFORMATION_SCHEMA.VECTOR_INDEXESのcoverage_percentageを定期的にポーリングし、インデックス構築の完了を確認しています。
SELECT table_name, coverage_percentage FROM `{project_id}.{dataset_id}`.INFORMATION_SCHEMA.VECTOR_INDEXES WHERE table_name IN UNNEST(@expected_tables)
coverage_percentageが100％に達した後、Vector Searchステップへ進むことでブルートフォース計算を回避しています。
Vector Searchのスロット消費問題
もう1つの大きな課題は、共有スロットの大量消費による他ジョブへの影響でした。Vector Searchはユーザーとアイテムの全組み合わせに対してコサイン類似度を計算するため、1回の実行で大量のスロットを占有します。
社内ではBigQueryのジョブを共通の容量ベースプロジェクトで実行しています。そのため、Vector SearchがBigQueryの共有スロットを圧迫すると自チームの実行時間の増大やSLO超過だけでなく、他チームのクエリ遅延・タイムアウトを引き起こすリスクがありました。
また、今回のケースではBigQueryのスキャン量が少ないという特徴がありました。そこで、オンデマンド課金用の専用プロジェクトを用意してVector Searchのみをそのプロジェクトで実行するようにしました。オンデマンド課金はスキャン量に対して課金されるため、コストを抑えつつ共有スロットへの影響を回避し、十分な計算リソースを確保できました。
運用事例
上記の汎用推薦システムを実際のMA施策に適用し、開発スピードと推薦精度の両面で効果を検証しました。
開発リードタイムの短縮
施策ごとに約10週間かかっていた推薦システムの構築が約3週間で完了し、約1/3に短縮されました。以下の表に、従来と汎用推薦システムの工程比較を示します。
| 工程 | 従来 | 汎用推薦システム |
|---|---|---|
| 探索的データ分析 | 約2週間 | 不要（Embedding基盤を利用） |
| モデルの設計・実装 | 約3週間 | 不要（Embedding基盤を利用） |
| パイプラインの設計・実装 | 約2週間 | 約1週間（セグメント設定と既存パイプラインの利用） |
| 実験・評価・チューニング | 約3週間 | 約2週間（後処理によるチューニング） |
Embeddingを活用することで、探索的データ分析やモデルの設計・実装が不要になりました。また、パイプラインの設計・実装についても、セグメント抽出用のSQLを変更するだけで新しい施策に対応できるため、短期間で実装できるようになりました。さらに、実験・評価・チューニングではモデルのパラメータの調整が不要であり、過去の評価コンポーネントや実験の仕組みも再利用できるため、後処理のチューニングへ集中できるようになりました。
推薦精度の向上
従来のルールベースの推薦（Control）と汎用推薦システム（Treatment）のA/Bテストを実施し、以下の結果を得ました。
| 指標 | 有意差の有無 |
|---|---|
| 配信当たりのMA経由流入数 | 有意差ありの勝ち |
| 配信当たりのMA経由購入数 | 有意差ありの勝ち |
| 配信当たりのMA経由受注額 | 有意差なしの勝ち |
主要KPIである配信当たりのMA経由流入数・購入数で統計的に有意な改善を確認したため、汎用推薦システムの本番導入に至りました。
まとめ
本記事では、ZOZOTOWNのMA施策向けに構築した汎用推薦システムについて紹介しました。
本システムは、EmbeddingとBigQuery Vector Searchを活用し、施策を横断して利用できる汎用的な推薦システムです。従来必要だった特徴量作成やモデル学習が不要になることで開発スピードを向上させつつ、Embeddingによりユーザーの潜在的な嗜好を反映した高い推薦精度を実現しています。
実際のMA施策への適用では、開発リードタイムを約10週間から約3週間に短縮しました。さらに、A/Bテストでは配信当たりのMA経由流入数・購入数の改善を確認し、本番導入に至っています。
今後の展望
今後は以下の取り組みを予定しています。
- Rerankerの導入: 現在のスコアブースト・フィルタリングはルールベースで煩雑なため、機械学習ベースのRerankerを導入し、MA施策に最適化されたチューニングを実現する
- セグメント設定の効率化: セグメント定義をviewなどで共通管理し、パイプラインごとの再実装をなくす
最後に
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
