Amazon Web Services ブログ
株式会社Diverse が Amazon SageMaker で実現した「温度感」ベースのマッチング体験
はじめに
本ブログは 株式会社Diverse 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。
みなさん、こんにちは。アマゾンウェブサービスジャパンの古山（アカウントマネージャー）、大松（ソリューションアーキテクト）です。
株式会社Diverse 様（以下、Diverse 様）は、「すべての人に、運命の出会いを届ける」をミッションに掲げ、恋愛マッチングサービス「YYC」をはじめとした出会いのプラットフォームを運営するテクノロジー企業です。YYC は数百万規模のユーザーが利用する国内有数のマッチングサービスであり、多様な目的を持つユーザー同士を適切に結びつけることが、サービスの根幹を成しています。
本記事では、Diverse 様が YYC において、ユーザーの「温度感」を Amazon SageMaker 上の Two-Tower Model で学習し、Apache Solr の K-Nearest Neighbors (KNN) 検索でリアルタイムに配信する仕組みを、既存のルールベース導線と併用しながら構築した取り組みを紹介します。
ビジネス課題と背景
YYC ではこれまで、ユーザーのライフサイクルに応じたルールベースの行動導線でマッチング機会を設計してきました。新規登録直後の「チャンスタイム」では時間制限つきでプロフィール閲覧やメッセージ送信を無料にし、初動のアクションを後押しすることで最初の 1 通までの距離を縮めます。継続期には「デイリーミッション」として、一定条件で抽出された相手へのあいさつが無料で送れる仕組みを提供し、日々の行動を後押しして継続利用につなげていました。
これらのルールベース設計は数年にわたって YYC を支えてきた土台であり、説明可能性の高さ、即効性、数値設計の容易さ、障害耐性の高さ、運用知見の蓄積しやすさといった明確な強みがありました。新しい施策を思いついてから数日で本番に出せること、壊れても原因特定と切り戻しが容易であることなど、プロダクト運営において頼りになる基盤です。
しかし、ユーザー層と目的の多様性が広がるにつれて、いくつかの課題が見えてきました。第一に、ユーザー多様性への追従が遅いことです。新しい利用目的や層が出てくるたびに、ルールを増やすか既存ルールを改修するしかなく、対応速度に限界がありました。第二に、全員一律のルールでは個別最適ができず、同じ「温度感」を持つ人同士をピンポイントで繋ぐことが困難でした。第三に、ブロックや通報があってもルール側に自動で反映されるわけではなく、改善のたびに人間が仮説を立てて手を動かす必要がありました。さらに、チャンスタイム（新規）とデイリーミッション（継続）の接続がロジックとしても体験としても連続しない点、そしてルールの例外が例外を呼んで複雑化していく構造的課題も顕在化していました。
こうした背景から、ルールベースの行動導線を置き換えるのではなく、ML ベースの検索を並行して動かし、「自分と温度感が近い相手」を返せる仕組みを追加することが必要だと判断しました。
解決アプローチと「温度感」の定義
Diverse 様は、まず「温度感」という概念を決定論的に定義することから始めました。具体的には、ユーザーの出会いに対する姿勢を「じっくり（0.0）」から「カジュアル（1.0）」までの 1 次元スコアとして設計し、さらにユーザーごとに「希望する相手の温度感レンジ」を設定できるようにしました。このスコアの算出には、プロフィールの記載内容、メッセージ頻度、マッチング後の行動パターンなどを入力として用いています。
さらに、それぞれのユーザーには「自分のスコア位置」だけでなく「どの範囲の相手なら噛み合うか」という希望レンジもあります。
Amazon SageMaker の採用理由
モデルの学習基盤として Amazon SageMaker を採用した理由は複数あります。まず、Two-Tower Model のようなカスタムアーキテクチャを柔軟にトレーニングできる環境が必要でした。Amazon SageMaker のトレーニングジョブは、必要なときに必要なだけ GPU インスタンスを立ち上げて学習を回し、終了後に自動でシャットダウンされるため、コスト効率が高く、実験のイテレーションを素早く回すことができます。また、学習の実験記録が自動保存され、ハイパーパラメータやモデル格納場所の紛失リスクが解消される点も、継続的な改善サイクルを回すうえで重要でした。
ソリューションの概要
本ソリューションは、ユーザーの「温度感」を表現する Embedding を Amazon SageMaker で学習し、その Embedding を Apache Solr に投入して KNN 検索でリアルタイムに配信する構成です。既存のルールベース導線を維持したまま、検索結果の一部を ML 側から差し込む形で併用します。全体は「学習パイプライン（Amazon SageMaker）」「Embedding ストア兼検索エンジン（Apache Solr）」「既存のルールベース導線との統合レイヤー」の 3 つで構成されます。
ソリューションの構成
Two-Tower Model のアーキテクチャ
学習には Two-Tower（二塔）構造のニューラルネットワークを採用しました。User Tower と Partner Tower がそれぞれ独立してユーザーの特徴量を 64 次元の Embedding に変換し、2 つの Embedding 間の類似度でマッチングの相性を測ります。
入力特徴量としては、user_id、性別（sex）、温度感スコア（score）、希望マッチセンター（match_center）を使用しています。ここで特筆すべき技術的工夫として、64 次元の Embedding のうち先頭 2 次元を score と match_center にピン留めし、残り 62 次元で行動データからの汎化を学習する設計を採用しています。これにより、Embedding 空間の一部が人間にとって解釈可能な軸となり、モデルの説明可能性を維持しながら、データドリブンな表現学習の恩恵も得られる構成となっています。
損失関数の設計
損失関数は InfoNCE（対照学習）と MSE（平均二乗誤差）を組み合わせたものを採用しています。InfoNCE で「マッチした相手の Embedding を近づけ、そうでない相手を遠ざける」という対照学習を行いつつ、MSE で先頭 2 次元が score / match_center に近づくよう誘導します。さらに、直近 90 日間のブロックデータを負例として weight=-1.0 で活用し、ユーザーが明示的に拒否した相手との距離が広がるようモデルにフィードバックしています。
Amazon SageMaker による学習パイプライン
学習は Amazon SageMaker 上のトレーニングジョブとして実行されます。データの前処理からモデルの学習、Embedding の推論までを Amazon SageMaker のマネージド環境で一気通貫に処理することで、インフラ管理の手間を最小限に抑えながら、再現性の高い実験サイクルを実現しています。
Solr KNN による配信
学習済みモデルから生成されたユーザー Embedding は、Apache Solr の Dense Vector フィールドに投入されます。検索時には KNN アルゴリズムで「温度感の近い相手」を高速に返します。
ここで重要な設計判断として、Graph Pre-Filter を活用したハイブリッド検索を採用しています。性別、年齢、エリア、ブロック除外といった絶対条件は Pre-Filter でまず候補を絞り込み、その中から KNN でベクトル類似度の高い相手を返す構成です。これにより、ビジネスルールとして譲れない条件を確実に満たしつつ、ML による温度感マッチングの恩恵を得ることができます。
既存導線との併用
この ML ベースの検索は、既存のルールベース導線を置き換えるものではなく、検索結果の一部を ML 側から差し込む形で併用運用しています。既存の安定した仕組みを維持しながら、段階的に ML の効果を検証できる体制を実現しています。
導入効果
温度感という軸を ML で表現することにより、従来のルールベースでは実現できなかった「個別最適化されたマッチング体験」が可能になりました。全員一律の導線ではなく、ユーザーそれぞれの出会いに対するスタンスに寄り添った相手が提示されることで、マッチング後のコミュニケーションの質の向上が期待されます。効果の定量的な検証は現在も継続しており、確定した数値は「今後の展開」で共有していく予定です。
また、ブロックデータを負例として学習に組み込むことで、トラブルの事後学習が自動化され、従来のように人間が個別に仮説を立ててルールを改修する必要がなくなりました。これはサービス運営チームの運用負荷の軽減に直結しています。
さらに、先頭 2 次元のピン留め設計により、Embedding 空間の可視化が容易になり、エンジニアだけでなくプロダクトマネージャーや CS チームもモデルの振る舞いを直感的に理解できるようになりました。これは ML モデルの社内浸透における利点となっています。
“導入後の A/B テストでは、メッセージの返信率や返信までの時間といった指標で、従来のルールベース導線に対して統計的に有意な改善が確認できています。
開発着手から約 1 ヶ月で本番環境での A/B テストを開始でき、SageMaker の学習パイプラインはトラブルなく日次で安定稼働しており、導入から運用まで想像以上にスムーズでした。”
（株式会社Diverse 取締役CTO 須藤 将史 様）
今後の展開
現在は ML 側の検索結果比率を慎重に調整しながら効果計測を続けており、数字が安定した段階で ML 側の比率を段階的に引き上げていく計画です。
今後取り組むべき技術的課題として、コールドスタート問題（新規ユーザーの Embedding をどう生成するか）と、再学習サイクルの最適化が挙げられています。新規ユーザーは行動データが蓄積されていないため、初期段階では温度感スコアの推定精度が低くなる傾向があります。この課題に対しては、プロフィール情報や登録直後の行動パターンから暫定的な Embedding を生成するアプローチを検討しています。
導入のポイントと教訓
本プロジェクトで特に工夫した点は、「説明可能性と表現力の両立」です。ML モデルはしばしばブラックボックスと見なされますが、Embedding の先頭次元をピン留めすることで、モデルの出力に対して「なぜこの相手が提示されたのか」を部分的に説明できる設計を実現しました。これは、運営チームや CS からの問い合わせに迅速に対応するうえで不可欠な設計判断でした。
ルールベースと ML の関係は「置き換え」ではなく「併用」から始めることを強くお勧めします。既存のルールベースには数年にわたる運用知見が詰まっており、それを一気に捨てるのはリスクが大きすぎます。まずは検索結果の一部を ML から差し込む形で効果を検証し、数字に確信が持てた段階で比率を上げていくアプローチが、プロダクトの安定性を維持しながら進化を実現する鍵となります。
「温度感」という抽象的な概念を、まず決定論的にスコアとして定義し、それを教師情報として Embedding 学習に活用するという段階的なアプローチが成功の鍵でした。いきなり End-to-End で学習するのではなく、人間が理解できる中間表現を挟むことで、モデルのデバッグや改善の方向性が明確になります。
まとめ
Diverse 様は、マッチングサービス「YYC」において、ユーザーの「温度感」を表現する 64 次元の Embedding を Amazon SageMaker 上の Two-Tower Model で学習し、Solr KNN によるベクトル検索でリアルタイムに配信する仕組みを構築しました。既存のルールベース導線と ML ベース検索を併用することで、サービスの安定性を維持しながら、個別最適化されたマッチング体験の提供を進めています。
今後は、効果計測の結果を踏まえた ML 比率の段階的な引き上げ、コールドスタート問題への対応、再学習サイクルの最適化を通じて、さらなるマッチング体験の向上を目指していきます。
本事例で紹介した仕組みの詳細や、Amazon SageMaker を用いた機械学習の導入にご興味のある方は、以下もあわせてご覧ください。
Amazon SageMaker 製品ページ
Amazon SageMaker 開発者ガイド
採用した AWS サービス
Amazon SageMaker – Two-Tower Model の学習および Embedding 推論
（左から）株式会社Diverse : 藤田 雄大様、須藤 将史様、 アマゾン ウェブ サービス ジャパン合同会社 ： アカウントマネージャー 古山 玄弥、ソリューションアーキテクト 大松 宏之