はじめに
こんにちは、データシステム部MA推薦ブロックの佐藤（@rayuron）です。私たちは、主にZOZOTOWNのメール配信のパーソナライズなど、マーケティングオートメーションに関するレコメンドシステムを開発・運用しています。
早速ですが、先日ZOZOマッチというサービスをリリースしました。
新規サービスのアルゴリズム開発では、既存サービスと異なり、ユーザー行動データが存在しない状態からスタートします。本記事では、ZOZOマッチのレコメンドアルゴリズム開発において、リリース前のモデル性能やシステム負荷に関する不確実性にどう向き合い、リリースまでたどり着いたかを紹介します。
背景
ZOZOマッチは、ファッションジャンル診断などの情報をもとに、ZOZO独自のAIが「好みの雰囲気」の相手を紹介するマッチングアプリです。登録時に年齢や性別などの基本情報に加え、複数のコーディネート画像の中から好みのファッションを選択することで、「好みの雰囲気」の相手を導き出します。さらに、プロフィールに登録された全身写真からユーザー自身の雰囲気も分析することで、一人ひとりにおすすめの相手を紹介します。
MA推薦ブロックでは、このサービスのコアとなるレコメンドアルゴリズムの開発を担当しました。しかし、新規サービスのため、ユーザーのプロフィール情報や行動履歴が一切存在しない状態からのスタートとなりました。
課題
新規サービスのアルゴリズム開発を進める上で、主に以下の2つの大きな課題に直面しました。
1. モデルの評価とリリース判断が困難
通常のレコメンドシステム開発では、過去のユーザー行動データを使ってモデルの精度をオフライン環境で評価します。しかし、新規サービスではそのデータが存在しないため、定量的な評価が困難でした。また「このアルゴリズムで十分な品質か」を客観的に示せず、関係者との合意形成も困難でした。
このような相互的な好みを考慮する仕組みは「相互レコメンドシステム（Reciprocal Recommendation System）」と呼ばれ、ユーザー間の双方向の関係性をモデリングします。そのため、これまで私たちが携わってきた、ユーザーに商品を推薦する片方向のレコメンドシステムとは異なります。実際、「どのくらいの精度があればユーザーが満足するのか」「片方向の精度と双方向の精度のバランスはどうあるべきか」といった根本的な問いに対する答えを、初期の調査段階で見つけられませんでした。
2. ユーザー数とシステム負荷の予測が困難
サービスリリース後にどれくらいのユーザーが登録し、どの程度の頻度で利用するかは未知です。ユーザー数に依存する処理時間や必要なリソースが分からないため、処理の長時間化やOOMなどにより、レコメンドのサービングが遅れ、サービス全体に影響を与えるリスクがありました。
これらの課題を解決しないまま開発を進めると、リリース後に大きな問題を引き起こすリスクがありました。
課題を解決したアプローチ
上記の課題に対して、以下3つのアプローチで解決を図りました。
1. ドメインと技術の調査
効果的な解決策を設計するため、マッチングアプリのドメインと技術を調査しました。上記の課題に対する直接的な解決策ではないものの、ドメインと技術の理解を深めることで、課題の本質を捉えられます。
ドメイン調査
まずは、一般的なマッチングアプリについて、さまざまな観点で調査しました。ターゲットとなるユーザー層や、使用目的による行動の違い、人気ユーザーへのいいね集中や新規ユーザーの不利といったバイアス、メッセージ疲れや友人発見のリスクなどを洗い出しました。
次に、ZOZOマッチ固有のサービスの特性やバイアスを分析しました。特に、初期リリース時には検索機能を持たずレコメンドのみでマッチングする設計のため、レコメンド精度が特に重要となります。また、性別、年齢、会いたいエリアだけではなく、ファッションでのマッチングがコンセプトであることやその他のビジネスロジックを整理しました。
ファッションでマッチングを行うために、基本的なプロフィール情報やファッション関連データに加え、ファッションジャンルの診断結果を活用します。将来的には、WEARの投稿・閲覧データやZOZOTOWNの購買データとの連携も視野に入れ、他のマッチングアプリにはないZOZOならではのデータ活用方針を定めました。
マッチングアプリのレコメンドにおけるKPIは「マッチ率」であるため、ドメイン調査の結果を踏まえ、レコメンドモデルでは次の2つの指標の向上を目指す必要があります。
- レコメンドとして表示された相手にユーザーが「いいね」を送る回数
- ユーザーが「いいね」を送った相手から、「いいね」を返してもらえる回数
しかし、リリース前の初期フェーズでは、いいねやマッチのデータが取得できないため、これらを直接の目的変数として最適化できません。そこで、マッチングアプリの先行研究やユーザー行動の知見を踏まえ、「ユーザーが登録した条件と相手に求める条件が互いに一致するユーザーをレコメンドすることで、マッチ数が増加する」という仮説を立てました。条件には、性別や年齢、会いたいエリアといった基本的なプロフィール情報に加え、ファッションジャンルの相性を使用します。
技術調査
ドメイン調査と並行して、相互レコメンドの研究動向を調査し、ZOZOマッチに適用可能な手法を検討しました。
ZOZOTOWNのようなECサイトでは、商品をユーザーにレコメンドする片方向のレコメンドシステムが一般的です。一方、マッチングアプリは、相互レコメンドと呼ばれる双方向のレコメンドが必要です。つまり、ユーザーAのユーザーBへの嗜好と、ユーザーBのユーザーAへの嗜好の両方を考慮します。相互レコメンドシステムでは、以下の3つのコンポーネントを持つアーキテクチャが主流です。
- ユーザーA → ユーザーBへの嗜好スコア予測
- ユーザーB → ユーザーAへの嗜好スコア予測
- 2つのスコアを集約する関数
最終的に、ZOZOマッチでもこの基本構成を採用しました。まず初回リリース時点ではユーザーの行動データがないため、ユーザーが事前に登録した情報を使い、コンテンツベースのレコメンドから始めます。その後、データが蓄積された段階で協調フィルタリングを組み合わせたモデルに移行する方針を決定しました。
2. プロトタイプを使った評価
モデルの評価とリリース判断が困難という課題に対しては、モデルの品質を確認するためにプロトタイプを作成し、関係者からフィードバックを得ることで、リリース判断の合意形成を図りました。
ZOZOが運営する別サービスであるWEARには、既にファッションに関する画像とそれに紐づくジャンルのデータが蓄積されています。このデータを活用して、プロトタイプを作成しました。ただし、WEARはファッションコーディネート投稿がメインであり、マッチングとは目的が異なります。このため、WEARでの傾向が必ずしもZOZOマッチに当てはまるとは限らないというバイアスを関係者間で共有しました。
プロトタイプには、性別や年齢、会いたいエリアといった基本的な情報を表示する機能を実装しました。さらに、サービスの核となる、自分が相手に求めるファッションジャンルと相手が自分に求めるファッションジャンルの両方を確認できるようにしました。
プロトタイプにはWEARデータだけでなく、社員のプロフィール画像や好みのコーディネート画像を任意で登録できる機能も実装しました。これにより、実際のZOZOマッチに近い形でレコメンド結果を評価できるようになり、よりリアルなフィードバックを得ることができました。また、自分自身を起点にしたレコメンドを確認できるため、「この人はタイプだけど、自分には似合わなさそう」といった双方向性を考慮した評価も可能になりました。
アプリのターゲットユーザーとなり得る社内メンバーにレコメンド結果を見てもらい、フィードバックを収集しました。プロトタイプを素早く作成し、ビジネスサイドや社内メンバーからフィードバックを得て改善するというサイクルを回すことで、リリース判断の合意形成を図りました。完全な双方向でのフィードバック検証は実現できなかったものの、多くの具体的な改善案を得ることができました。
モデル開発初期は定性評価を中心に行い、リリース直前には定量評価も実施しました。具体的には、社内ベータテストとして約30名のターゲット層に該当する社員が実際にアプリを使用し、複数のレコメンドモデルを比較評価しました。評価指標は「レコメンドされた相手に対するいいね率」とし、最も高いスコアを示したモデルを最終的に採用する判断に至りました。
具体的には以下のようなフィードバックを得られました。他にも多数の意見がありましたが、ここでは一部を紹介します。
- 相手に希望する年齢以外のユーザーが上位に出てくるので、表示の優先度付けを改善できないか
- ジャンルの中で一番強い要素がマッチしていると「お、タイプだな」と思うので、全体のジャンルの距離の中でも、ジャンルの中で一番強い要素の距離が近いともっと加点されてもいいのでは
- 好みでなくても写真のクオリティが高いといいねを押したくなったので、写真のクオリティ度を表示の優先度に加味できるといいねが飛び交い、マッチ数が増えそう
- タイプな人が1人いるだけでテンションが上がる
3. モックデータを使った負荷試験
ユーザー数とシステム負荷の予測が困難という課題に対しては、LLMを活用したモックデータの作成というアプローチを採用しました。
負荷試験を行うため、ドメインと技術の調査で言語化したドキュメントをもとに、モックデータを作成しました。具体的には、実在の統計データ（都道府県別の人口分布など）とZOZOマッチのサービス仕様をLLMに入力し、現実的なユーザー属性分布の設計を支援してもらいました。その後、設計した分布に基づいてユーザーデータを生成するSQLクエリを作成し、マッチングアプリの一般的なユーザー行動パターンを反映したモックデータを生成しました。アクティブユーザー数を可変として、10万人、20万人、30万人などといった規模でシミュレーションを実施しました。
今回、レコメンドを作成するためのバッチシステムとして、Google Cloudの機械学習ワークフロー管理サービスであるVertex AI Pipelinesを採用しました。負荷試験を行う場合であっても本番同等のパイプラインの最初にサンプルデータ作成コンポーネントを追加するだけで、負荷試験を実施できる構成を取っています。
- 設計したユーザー属性分布に基づいてSQLクエリでDDLを作成。この時ユーザー数は可変なパラメータとして指定
- 年齢、性別、会いたいエリアなどのユーザー属性といいねやマッチといった行動データをデータベースに挿入
- 本番相当のレコメンドパイプラインを実行し、実行時間やリソース使用量を計測
以下は、ユーザーの会いたいエリアを決められた割合に基づいてランダムに割り当てるSQLクエリの例です。
WITH user_rand AS ( SELECT user_id, RAND() AS r FROM users ), user_meeting_areas AS ( SELECT user_id, CASE WHEN r 0.1275 THEN 'TOKYO' WHEN r 0.2113 THEN 'KANAGAWA' WHEN r 0.2911 THEN 'OSAKA' ... END AS area_name FROM user_rand ) ...
生成したデータが妥当かどうかはデータ分布を可視化し直感や統計と大きく乖離していないことを確認しました。また、生成したデータはあくまで負荷試験用であり、モデル学習には使用していません。実装済みのビジネスロジックを用いて、システムの処理時間やリソース使用量を計測することが目的です。
得られた効果
これらの取り組みにより、以下の成果が得られました。
1. 関係者間での合意形成
ユーザー行動データがないため、モデルの評価やリリース判断が困難でしたが、プロトタイプによる評価を経て、レコメンド結果に対して多くの具体的な改善案を得ることができました。それらの改善を繰り返し、最終的には関係者間でのリリース判断の合意形成を実現し、リリースに至りました。
2. 安定したシステム稼働
リリース前のシミュレーションを通じてユーザー数に対する負荷を予測できたので、必要十分なアーキテクチャ設計とリソースの適用が可能になりました。シミュレーションでは、想定ユーザー数に対してレコメンド生成バッチが十分な時間内で完了することを確認し、必要なコンピューティングリソースを見積もることができました。リリース後も、レコメンドパイプラインは想定通りの処理時間内で完了し、執筆時点でのシステム稼働率は100％を維持しており、安定したサービス提供ができています。
今後の展望
レコメンドの精度向上
ZOZOマッチ内のデータが蓄積され次第、以下のような改善を段階的に進めていきます。
- ユーザーの行動ログに基づく協調フィルタリングの導入
- ユーザーのプロフィール画像や自己紹介文といったマルチモーダルなデータの活用
- ZOZOTOWNやWEARのデータを活用したクロスプラットフォームなレコメンドの実現
おわりに
本記事では、ユーザーのプロフィール情報や行動履歴がない新規サービスにおけるアルゴリズム開発の不確実性に対して、どのようにアプローチして課題を解決したかを紹介しました。
新規サービスの開発では、既存サービスとは異なる難しさがあります。しかし、ドメインと技術調査、プロトタイプによる検証、そしてモックデータを使った負荷試験など、工夫次第で不確実性を軽減できました。
ZOZOマッチはまだスタート地点に立ったばかりです。今後もユーザーに価値を提供できるよう、継続的な改善を続けていきます。
ZOZOでは一緒にサービスを作り上げてくれる方を募集しています。ご興味がある方は以下のリンクからぜひご応募ください！
元の記事を確認する
