新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編

2025/2/20に開催したRecruit Tech Conference 2025の吉鷹の資料です

Transcript

1. 新規検索基盤でマッチング精度向上に挑む！ ～『ホットペッパーグルメ』の開発事例 RECRUIT TECH CONFERENCE 2025 ビジネス編 吉鷹　伸太朗 株式会社リクルート プロダクトディベロップメント室　グループマネジャー
2. 吉鷹 伸太朗 最近犬をお迎えして日々悪戦苦闘中 経歴 / Career 2019年にリクルートに新卒入社。 『ホットペッパーグルメ』や『じゃらん』のレコメンド 施策等を多数推進。 2024年より飲食データサイエンスGのグループマネ ジャーに任用。 趣味 / Hobbies データ推進室 販促領域データソリューション３ユニット （飲食・ビューティー） 飲食・ビューティーデータソリューション部 飲食データサイエンスG
3. • ビジネス編 ◦ 『ホットペッパーグルメ』におけるレコメンド・検索施策がどのように 進展していったか？ 本日お話しすること
4. 『ホットペッパーグルメ』は、国内最大級の飲食店情 報サイト 毎日多くの飲食店利用ユーザーが訪問・利用している 弊グループでは、膨大な店舗とユーザーのデータを活 かして、『ホットペッパーグルメ』におけるレコメン ドと検索の改善を取り組んできた ホットペッパーグルメ
5. レコメンドと検索における課題 レコメンド • Impression量の少ない一部画面にのみレコメンドが存在していた • 既存レコメンドには以下のような課題が存在していた ◦ 高々日次バッチの事前推論のみ ◦ 機械学習アルゴリズムが非導入 検索 • ビジネス的なリスクが内包されるため検索システムへの介入には慎重だった • そのため、既存検索アルゴリズムのチューニングは停止しており、 古いまま運用されていた
6. データ施策導入の壁 レコメンドや検索等のデータ施策の導入や改善には3つの壁が存在した • データ施策の実績が少なく、データ組織への信頼残高が少なかった → 他施策との兼ね合いで優先度が下がりがち • 改修する際の関係部署が多く、前述の優先度もあり工数取得が難航 • 開発期間が長く、仮説検証の試行が回せない 工数取得が難航して、計画が進まない 開発期間が長く、なかなかABテストへ進めない
7. 打ち手①：小さい成果から信頼を蓄積 2019年〜2021年 検索ワード入力画面でのレコメンド 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった
8. 打ち手①：小さい成果から信頼を蓄積 2019年〜2021年 検索ワード入力画面でのレコメンド 2022年 アプリトップ下部でのレコメンド 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった
9. 打ち手①：小さい成果から信頼を蓄積 2023年 アプリトップ画面の刷新 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった
10. 打ち手①：小さい成果から信頼を蓄積 2023年 アプリトップ画面の刷新 2024年 検索アルゴリズム改善 （*SIGIR-AP 2024 ポスター発表より） 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった
11. 打ち手①：小さい成果から信頼を蓄積 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった 当初 データ組織 2名 ↓ 小さなレコメンド施策1つ データ組織 20名以上 ↓ レコメンド施策複数 検索アルゴリズム サジェスト … 現在
12. 打ち手②：密結合→疎結合なアーキテクチャへ 疎結合なアーキテクチャを採用することで関係部署/工数を減少 Storage 環境① API 環境② BATCH 組織A 組織B 組織C データ組織
13. 打ち手②：密結合→疎結合なアーキテクチャへ 疎結合なアーキテクチャを採用することで関係部署/工数を減少 Storage 環境① API 環境② BATCH 環境① API 環境② BATCH API 組織A 組織B 組織C データ組織 組織A 組織B データ組織 データ組織
14. 打ち手②：密結合→疎結合なアーキテクチャへ 疎結合なアーキテクチャを採用することで関係部署/工数を減少 Storage 環境① API 環境② BATCH 環境① API 環境② BATCH API 組織A 組織B 組織C データ組織 組織A 組織B データ組織 データ組織 データ組織で APIを用意 → 組織Cの介 在が不要に
15. 打ち手②：密結合→疎結合なアーキテクチャへ 疎結合なアーキテクチャを採用することで関係部署/工数を減少 Storage 環境① API 環境② BATCH 環境① API 環境② BATCH API 組織A 組織B 組織C データ組織 組織A 組織B データ組織 データ組織 自由度をもたせた通信に設計 　↓ データ組織側の改修だけで一 定の試行が可能に データ組織で APIを用意 → 組織Cの介 在が不要に
16. 打ち手③：開発方式/体制の変更 • ウォーターフォール開発 → アジャイル開発へ変更 • レコメンド/検索改善施策において、 一定のスコープ内でデータ組織の人員をPM/PLへ設定 柔軟な開発の実施が可能に → 仮説検証の試行が早く回せるように PO=Producer PM=DATA PL=DATA Team Team ⋯ 体制の一例 Team ⋯ ⋯
17. データ施策導入の壁が解消！ レコメンドや検索等のデータ施策の導入や改善には3つの壁が存在した • データ施策の実績が少なく、データ組織への信頼残高が少なかった → 他施策との兼ね合いで優先度が下がりがち • 改修する際の関係部署が多く、前述の優先度もあり工数取得が難航 • 開発期間が長く、仮説検証の試行が回せない 小さい成果から信頼を蓄積 密結合→疎結合なアーキテクチャへ 開発方式/体制の変更 ✔ ✔ ✔
18. レコメンドと検索における課題も解消！ レコメンド • Impression量の少ない一部画面にのみレコメンドが存在していた • 既存レコメンドには以下のような課題が存在していた ◦ 高々日次バッチの事前推論のみ ◦ 機械学習アルゴリズムが非導入 検索 • ビジネス的なリスクが内包されるため検索システムへの介入には慎重だった • そのため、既存検索アルゴリズムのチューニングは停止しており、 古いまま運用されていた APPのTOP画面に大きな枠を設置 ✔ オンライン推論の 機械学習アルゴリズムも導入 ✔ 検索アルゴリズムの改善も実施（後ほど詳述） ✔
19. 『ホットペッパーグルメ』におけるレコメンドや検索等のデータ施策の導入や改 善は複数の要因によって進んでいなかった 以下の打ち手を実施することで、改善が進むようになった • 小さい成果から信頼を蓄積 • 密結合→疎結合なアーキテクチャへ • 開発方式/体制の変更 最初は非常に少ないメンバーでスタートでしたが、今では多くの仲間たちととも に日々改善に取り組んでいます！ 一緒に働いてくださる仲間も募集しています！！ 興味があれば是非ご連絡ください！！ まとめ