> For the complete documentation index, see [llms.txt](https://docs.wantedly.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wantedly.dev/fields/data/recommendation.md).

# レコメンデーション

ここでは、ウォンテッドリーのプロダクトにおける推薦システムについて紹介します。

## 推薦システムってなに？

推薦システムは、ユーザーの好みや行動傾向に基づいてどのコンテンツを提示するかを制御する技術を指し、オンラインショッピングや映画・音楽のストリーミングサービスなど、さまざまなサービスで使われています。例えば、Amazon の「お客様におすすめの商品」や Netflix の映画推薦などがイメージしやすいと思います。

[推薦システム実践入門(オライリー・ジャパン、2022年)](https://www.oreilly.co.jp/books/9784873119663/)によると、推薦システムは「複数の候補から価値のあるものを選び出し、意思決定を支援するシステム」と定義されています。複数の候補から価値のあるものを選び出すだけでなく、それをユーザーに適切に提示するところまでが推薦システムになるため、データ基盤や機械学習、バックエンド、フロントエンドなど多くの技術領域によって成り立っています。

## なぜ推薦システムが必要なのか

サービスにたくさんの魅力的なコンテンツがあっても、ユーザーがそのコンテンツに出会うことがなければ決して価値は生まれません。ユーザーが成功体験を得られるよう、次のような課題を解消するために推薦システムが必要となります。

* 膨大な選択肢: サービス内に存在するアイテムは膨大な量にのぼり、ユーザーがその中から自身のニーズに合致したものを見つけ出すことは困難である
* 自己理解の難しさ: ユーザーは自身のニーズを完全に理解できておらず、それはコンテキストや時間によっても変動する

## Wantedly Visit で使われている推薦システムの一例

* ユーザーへの募集の推薦（例：募集一覧の募集の並び順）
* 採用担当者への候補者の推薦（例：スカウト一覧の候補者の並び順）
* ユーザーへのユーザーの推薦（例：ユーザープロフィールの「あなたの知り合いかも」枠）
* ユーザーへのタイムライン投稿の推薦（例：タイムラインのフィードの並び順）
* ユーザーへの福利厚生の推薦（例：Perk 一覧の並び順）

## Wantedly Visit の推薦システムの概略

Wantedly Visit における推薦システムの概略図を以下に示します。

![](/files/oVf4fdtgcIobcAYywCwF)

## ユーザーへの募集推薦のロジック

募集一覧における推薦アーキテクチャの概略を以下に示します。

![](/files/sZXbxPWV1gcgaf7kwkAc)

この推薦は、全ての募集から候補を絞り込む「候補生成」と、候補集合を並べ替える「ランキング」の 2 段階で構成されています。 図中の「相互推薦」では、ユーザーが募集に応募する見込みと、応募後に企業側とマッチする見込みを合わせて扱います。このように双方の見込みを扱う理由は、採用マッチングが他の推薦とは異なる性質を持つためです。

## 採用マッチングと他の推薦の違い

採用マッチングは、EC の商品推薦や動画配信のコンテンツ推薦、SNS のユーザー間推薦などとは異なるいくつかの特性を持っています。これらの特性は、推薦アルゴリズムの設計だけでなく、評価指標の選び方、ログ設計、運用プロセスにも影響します。

### 両面性

採用マッチングは、求職ユーザーと採用担当者の双方にとって価値のある出会いを成立させて初めて意味を持ちます。企業側から見れば採用候補者の経験やスキル、ビジョンやカルチャーへの共感などが重要な要素になりますし、採用候補者側から見れば、その企業でやりたいことが出来るか、経験を活かせるだけでなく成長の機会があるか、労働条件は自分に合っているか、就職・転職活動を通じて新たな自分に出会えるか、なども重要な要素になります。そのため、片側のクリック率や閲覧数、応募/スカウトなどの上流の指標だけで最適化するのではなく、返信・マッチなど双方の合意を伴うより下流の指標も用いてパイプラインを設計・評価することが求められます。一部の人気募集に推薦が集中しすぎないよう対処したり、露出の偏りを観察し続けることも欠かせません。

### 意思決定の重さとインタラクションのスパース性

ECサイトや音楽・動画配信サービスなどでは、ユーザーが何度も利用する中で大量のインタラクションログが蓄積し、ユーザーの好みや嗜好を学習していくことが出来ます。一方で、採用マッチングでは、他のドメインほど頻繁にインタラクションが起こるわけではありません。これは、転職や採用が、求職者の人生や会社の業績に関わる大きな意思決定となるためです。

### フィードバックの遅延

最終的なマッチングの成功を示す指標は、ユーザーの行動ログからはすぐには観測できず、数週間から数ヶ月後にようやく観測できるようになります。一方で、長期的な指標のみを見ていると改善のサイクルが回しにくくなるため、中間指標を設定して短期的な利益に偏らないようにしつつも、中長期での利益を最大化するように推薦システムの設計や評価を工夫する必要があります。

### 流動性

推薦対象である募集には採用枠があり、採用が決まればクローズされます。求職ユーザー側にも転職活動の期間があり、活動を終えた後は推薦の対象として適切でなくなります。コンテンツ推薦のように「同じアイテムを多くのユーザーに何度でも推薦する」モデルが必ずしも当てはまらない領域だといえます。

また、新しい求職ユーザーや新しい募集が継続的に発生し、過去のログがほとんど存在しない状態の対象を扱うことも多いです。このため、行動ログが乏しい対象にも推薦できる仕組みを用意することが求められます。場合によってはデータの分布が継続的に変わることを前提として、再学習やモデル更新の運用フローを設計しておく必要があります。

### 公平性

採用は雇用機会に関わるため、属性（性別・年齢・国籍など）に基づく不当な差別が起きないよう配慮が求められます。そのため、入力特徴量や学習データに、雇用差別につながりうる属性が直接的・間接的に含まれていないかを意識して設計する必要があります。さらに、推薦結果の偏りを継続的に観測する仕組みを備え、問題が見つかった際に振り返れるよう判断根拠を残しておくことも求められます。

### Wantedly Visit の相互推薦システム開発の取り組み

このような背景から ウォンテッドリーでは相互推薦システムの開発に注力しています。詳しくは以下のブログにも書かれているので、ぜひご覧ください。

* [相互推薦システムを活用したユーザーと企業の双方の嗜好を考慮した推薦](https://www.wantedly.com/companies/wantedly/post_articles/903172)
* [Wantedly Visit における相互推薦システムの活用事例](https://speakerdeck.com/chimuichimu/wantedly-visit-niokeruxiang-hu-tui-jian-sisutemunohuo-yong-shi-li)
* [マッチング推薦におけるオフ方策評価・学習](https://www.wantedly.com/companies/wantedly/post_articles/1015424)
* [相互推薦の集約をマルチタスク学習でパーソナライズする](https://www.wantedly.com/companies/wantedly/post_articles/1041103)

## ウォンテッドリーの推薦チームは何に取り組んでいるのか

ウォンテッドリーの推薦チームは、「人と会社のよりよい出会いを、データと機械学習で支えるチーム」ですが、取り組みの範囲は機械学習モデルの精度向上だけにとどまりません。どの画面で・どのタイミングで・どう見せるか、リリース前後の安全性とユーザー体験の検証までを扱います。推薦を単なるアルゴリズムではなく、ユーザーの意思決定を助けるプロダクト体験として捉えている点が特徴です。

### 推薦チームの仕事の流れ

推薦チームは、問題発見・原因分析・解決策の立案・評価・リリース・運用までを一気通貫で扱います。

まずは問題の特定です。例えばある画面で募集が表示されているのに反応が薄い場合、推薦精度の問題以外にも、特定のセグメントに対する推薦内容が合っていない、推薦タイミングが適切でないなど、複数の原因が考えられます。

次に仮説を立てます。行動ログから離脱画面や閲覧傾向を集計したり、過去施策の振り返り、簡易的な事前検証などをもとに、なるべく妥当性の高い仮説を立てていきます。

仮説が立ったら解決策を考えます。既存のアルゴリズムの改善や新しいランキングの導入、前処理・後処理の追加などを検討します。

実装した変更はすぐに全ユーザーへ出さず、まず評価します。「このユーザーにはこの募集が正解」と事前に決めるのが難しいため、評価設計が特に重要です。過去ログによるオフライン評価、人による定性評価、ユーザーテスト、本番環境でのオンラインテストを組み合わせます。

オンラインテストでは A/B テストや Interleaving を用います。A/B テストはユーザーをグループに分けて従来/新規の推薦を比較する方法、Interleaving は複数の推薦結果を混ぜて同じ画面に出し、効率よく比較する方法です。オンラインテストでの評価が良好であれば、正式にリリースします。

新しいプロダクト機能に対して推薦ロジックを導入する際は、他チームのエンジニアと協業して、推薦のためのデータ収集やログ・APIの設計、画面への表示方法などを検討します。リリース後は、推薦結果の偏りやユーザー行動の変化をモニタリングし、必要に応じて改善を行います。

### 実験を速く、正しく回すための仕組み

推薦チームが大事にしているのは実験主義です。最終的な答えはユーザーの反応からしか分からないという前提に立ち、仮説を言語化し、必要最小限の実験で結果から学び、次の改善につなげる姿勢を指します。

実現には、実験を速く回せることと結果が信頼できることの両立が必要です。速くても評価が雑だと誤った学びを得てしまい、評価が厳密でも準備に時間がかかれば改善スピードが落ちます。

そのため ウォンテッドリーではオフライン評価用の内製ライブラリを整備しています。以前は施策ごとに評価コードを個別実装していましたが、現在は共通処理をまとめ、設定ファイルで評価内容を指定できるようにして準備の負担を下げています。

また、モデル出力だけでなく、実際にユーザーが見る推薦結果に近い形を再現して評価することも重視しています。モデルの並び順は検索条件・フィルタ・後処理を経て画面に表示されるため、モデル単体では良くてもユーザーに届く形では期待と違うことがあります。そこでユーザーが見る状態を可能な限り再現し、オフラインとオンライン評価のずれを小さくする工夫をしています。

デプロイのプロセスも改善されています。以前はデータサイエンティストの実装後に推薦基盤エンジニアが推論サーバー側の実装を行う必要があり、リードタイムが長くなりがちでしたが、現在はランキングの条件分岐やテスト形式をスキーマファイルに書くと必要なプログラムが自動生成される仕組みが整っているため、データサイエンティスト単独でも安全にデプロイしやすくなっています。

### MLOps の取り組み

推薦システムは作って終わりではありません。ユーザー行動・募集内容・企業の活動・画面構成は日々変わり、過去にうまく機能していたモデルも時間が経つと性能が落ちます。機械学習モデルを安定して開発・運用するための仕組みが MLOps で、開発・デプロイ・監視・運用の仕組み全体を指します。

推薦チームでは MLOps を「特徴量管理」「モデル学習と評価」「デプロイとサービング」「モニタリングと運用」の観点で整備しています。

**特徴量管理**: 特徴量は機械学習モデルの判断材料となるデータ(過去に見た募集、スキル、業種、職種、過去の接点など)です。複数の推薦システムで再利用できるよう Feature Store を内製しています。

**モデル学習と評価**: 多くの推薦モデルはバッチジョブとして自動学習されており、人手をかけずに新しいデータを反映した推薦を提供できます。

**デプロイとサービング**: サービングでは、新しいロジックを素早くオンライン検証してからリリースする流れが整っています。現在はバッチ推論が中心ですが、ユーザーの現在の状況を即時に反映するオンライン推論への移行が課題です。

**モニタリングと運用**: モデルの性能指標とビジネス指標を定期的に確認する文化があります。入力データの分布が変わるドリフトも課題で、ユーザー行動や募集内容が変わると過去データで学習したモデルの前提が崩れ精度が落ちます。また、ドリフト以外にも様々な要因でランキングが想定通りに表示されないことがあり、そのような異常にすぐに気付いて対処出来るよう、アラート通知やログの可視化などの仕組みを整えています。

### 今後取り組もうとしている課題

推薦チームは、これまで Wantedly Visit における推薦を中心に開発してきましたが、今後は Wantedly Visit の推薦をさらに深めることと、そこで培った技術を他プロダクトや業務にも広げることに取り組みます。

* **最適挑戦につながる推薦**: 簡単すぎず難しすぎない、その人の成長や前向きな変化につながる仕事との出会いを実現するため、スキル・性格・志向性・仕事上の特性をより深く理解する。
* **非構造データの活用**: 表形式に整理しづらいテキスト・画像・つながり情報などを、自然言語処理や深層学習で理解し、ユーザーの価値観や企業の魅力を推薦に活かす。
* **LLM と推薦の組み合わせ**: 大規模言語モデルを用いて、例えば自由記述プロフィールからのスキル抽出、リランキング、生成的推薦などに取り組む。
* **生成 AI によるコンテンツ作成支援**: マッチングの出発点となるプロフィールや募集文の作成負担を下げ、より多くの人や企業が魅力を伝えやすくする。
* **Wantedly Visit 以外のプロダクトへの展開**: Wantedly Hire や Perk など、他のプロダクトでの推薦・検索体験に Wantedly Visit の知見を横展開する。
* **社内業務の最適化**: 営業・マーケティング・スパム検知・コンテンツモデレーション・社内ナレッジ活用などに応用し、組織全体の生産性向上に貢献する。

### 話を聞きに行きたい

* Slack: [#visit\_recommendation (internal)](https://wantedly.slack.com/archives/CA0PVDX98)

### もっと知りたい

* <https://github.com/wantedly/visit-recommendation> (internal)
* [ウォンテッドリーにおける推薦システム開発の流れ (Wantedly Engineer Blog)](https://www.wantedly.com/companies/wantedly/post_articles/864502)
* [相互推薦システムを活用したユーザーと企業の双方の嗜好を考慮した推薦 (Wantedly Engineer Blog)](https://www.wantedly.com/companies/wantedly/post_articles/903172)
* [Feature Storeを活用して最新のデータを学習時に取り込むことによる推薦システムの改善 (Wantedly Engineer Blog)](https://www.wantedly.com/companies/wantedly/post_articles/897815)
* [ウォンテッドリーのデータサイエンティストが今後取り組む主要課題 (Wantedly Engineer Blog)](https://www.wantedly.com/companies/wantedly/post_articles/973103)
* [ウォンテッドリーの推薦システムを支えるMLOps -現状の取り組みと課題- (Wantedly Engineer Blog)](https://www.wantedly.com/companies/wantedly/post_articles/1047307)