推薦システム実践入門 ―仕事で使える導入ガイドのまとめ記事です。

TL;DR（要点）

推薦システムの基本概念、プロジェクトの進め方、UI/UX設計、代表的なアルゴリズム、運用や評価のポイントまで一通り学べる入門書。
ビジネス目線（KGI/KPI設計）と技術実装（データ設計・アルゴリズム・運用）の両面に実務で使える知見がまとまっている。
新規サービスや実装チーム向けに「何を最初にやるべきか」「評価の設計方法」を短時間で確認したいときに役立つ。

この記事で得られること

推薦システム導入の全体像を短時間で把握できる
プロジェクトの優先順位（課題定義→データ→アルゴリズム→評価）を理解できる
UI/UXや評価設計など、現場でよく直面するポイントの注意点が分かる

想定読者

データサイエンティスト、機械学習エンジニア、プロダクトマネージャー、推薦機能の導入を検討しているエンジニア

第1章推薦システム

1.1 推薦システムとは

本書での推薦システムの定義：複数の候補から価値のあるものを選び出し、意思決定を支援するシステム

「複数の候補から価値のあるものを選び出す」方法として、価値の定義の仕方によってさまざまな推薦アルゴリズムがある。単純に人気順に並べたものや、ユーザーが過去に購入した物を表示するなど。ビジネスの目的に合った手法を使用することが重要である（第2章で詳しく説明）。

「意思決定を支援する」に関しては、どのように表示すればユーザーがアクションを起こしてくれるかを考慮する必要がある。どのタイミングで、どの手段で、どのようにアイテムをユーザーに届けるかの設計が必要になる（第3章で解説）。

1.2 推薦システムの種類

推薦システムは、3つの要素（インプット、プロセス、アウトプット）に分けられる。

1.2.1 インプット（データの入力）

ユーザー・アイテムのコンテンツ情報
- ユーザーのプロフィール情報
- 会員登録時などに回答するアンケート情報
- アイテムに関する情報
- これらのような情報をコンテンツ情報と呼び、コンテンツ情報を利用した推薦は、
  内容ベースフィルタリング（content-based filtering）
  と呼ばれる。
ユーザーとアイテムのインタラクション情報
- ユーザーの行動履歴をインタラクション情報と呼び、インタラクション情報を利用した推薦は、協調フィルタリング（collaborative filtering）
  と呼ばれる。

1.2.2 プロセス（推薦の計算）

概要推薦（パーソナライズなし）
- 人気順や新着順など、全ユーザーに同じ内容を提示するもの
- 流動性が高いアイテム（ニュースなど）の推薦には効果的
- ユーザーは最新のニュースや皆が興味のある人気のニュースを見たいという要望が大きいから
関連アイテム推薦
- いわゆる、「このアイテムをチェックしている人は、このアイテムをチェックしています」機能
- 関連アイテムの計算には、アイテムの類似度を使用する
- この類似度の計算には、コンテンツ情報を基にした内容ベースフィルタリングと、インタラクション情報を基にした協調フィルタリングがある
  
  ハリーポッター問題：一時期、ハリーポッター関連のグッズが爆売れした。それによりほぼ全てのアイテムの関連アイテムとして、ハリーポッター関連のアイテムが表示された
パーソナライズ推薦
- コンテンツベースなら、ユーザーの居住地や年齢性別などの属性を基に推薦
- インタラクションベースなら、行動履歴を基に推薦
- 一度閲覧したものを再度推薦する手法は、実装コストが低い割に多くの分野で非常に効果が高い方法である

1.2.3 アウトプット（推薦の提示）

ビジネスにおいて提示の仕方は重要である。推薦アイテムは良くても、提示の仕方が良くないとCVに繋がらない。

1.3 この章のまとめ

章全体の要点
- 推薦システムは、インプット・プロセス・アウトプットに分けられる
- ユーザーやアイテムに関する情報をコンテンツ情報、行動履歴はインタラクション情報と呼ぶ
- コンテンツ情報をベースにした推薦は内容ベースフィルタリング、インタラクション情報をベースにした推薦は、協調フィルタリングと呼ぶ
実務・読後に活かせるポイント
- アルゴリズムに使用する情報の種類は意識して、選定・使用するようにする
- アルゴリズムだけでなく、アウトプットの仕方がビジネスにおいては大事

第2章推薦システムのプロジェクト

2.1 推薦システムの開発に必要なスキル

ビジネス力
- 推薦システムを導入することで期待する効果・価値を定義する力
  - KGI（ユーザーのどの行動の変容を期待するのか）
  - KPI（クリック率なのか、回遊率なのか、どの指標を向上させるのか）
- 例：Youtube
  - KPI：トータル視聴時間
    - 視聴時間を長くするために最後まで視聴される動画を推薦する
    - 以前のKPIは視聴動画数であったが、サムネが目を引くものばかりが推薦される事態が起こった
データサイエンス力
- 推薦アルゴリズムの実行
  - MVPの達成を目指す
  - いきなり理想のアルゴリズムではなく、王道の手法でどれくらいの精度が出て、理想状態からどのくらいのギャップがあるのか適宜ビジネスサイドと擦り合わせる
データエンジニアリング力
- 推薦システムのサービス要件を達成するための設計・開発を行う
  - 計算時間などのリソースを考慮したデータベースの設計やチューニング、パイプライン処理の整備など

2.2 推薦システムのプロジェクトの進め方

課題定義（KGI、KPIを決め、KPIの達成のためのギャップ（課題）を特定する）
仮説立案（各課題を解決する方法と、実現するためのコストを検討する）
データ設計・収集・加工
アルゴリズム選定
学習・パラメータチューニング
システム実装
評価・改善

2.3 この章のまとめ

章の要点
- データサイエンティストの仕事として、課題の特定、アルゴリズム開発、実装、関係者との調整などの仕事も範囲内
実務・読後に活かせるポイント
- 推薦システム経由でのCVが増えた影響で、検索経由でのCVが減り、結果全体のCV数が減ったなどの影響がないか調査が必要

第3章推薦システムのUI／UX

推薦システムの定義の「意思決定を支援する」機能として提供すべきUI/UXに関する章である。
どのような画面（UI）によって、どのような体験（UX）を提供すべきかに注目する。

3.1 サービスを利用するユーザーの目的に応じたUI/UX

ユーザーの利用目的は以下の4つに分けられる。

適合アイテム発見（find good items）
- ユーザー自身の目的を達成するのに適したアイテムを1つでいいので、サービス上で発見しようとしている場合を指す（例：東京駅で食事をする飲食店を探している）
- ユーザーの好みに合う可能性が高いアイテムから順に列挙する方法が効果的
- 列挙できるアイテムの数は限られているので、クリックして詳細画面に遷移する仕様が一般的。その際、リスト画面での情報量は多過ぎず少なすぎないという適切な量の見極めが必要になってくる
適合アイテム列挙（find all good items）
- ユーザー自身の目的を達成するのに適したアイテムをできるだけ全てサービス上で発見しようとしている場合を指す（例：引越し先の賃貸物件を探している）
- ユーザーの条件を緩和する提案（駅徒歩を5分から10分に緩和して探してみる）も効果的
アイテム系列消費
- 閲覧・消費していく中で、推薦されたアイテムの系列全体から価値を享受することを目的としている場合を指す（例：音楽ストリーミングサービスで音楽を次々と視聴している）
  - 推薦している音楽単体ではなく、次に再生される音楽の連続に価値がある
サービス内回遊（Just Browsing）
- ユーザーがただアイテムを閲覧すること自体を目的としてサービス内を回遊する場合を指す（例：今すぐ旅行する予定はないが、どのような観光地やホテルがあるか閲覧している）

3.2 サービスの提供者の目的に応じたUI/UX事例

サービス提供者の代表的なビジネス目的

新規・低利用頻度ユーザーの定着
- 大部分のユーザーにそこそこ刺さる推薦がしたい
- 悪い体験をさせないことも重要なので、概要推薦がしばしば用いられる
  - 統計情報に基づく推薦：人気ランキングなど
  - 編集者の選択に基づく推薦：映画評論家により手動で選ばれたおすすめリスト
サービスへの信頼性向上
- サービス提供者からの推薦はサービス提供者の利益を最優先しているのではないかと不審に思うケースがある
- 有効な打ち手として、利用者評価があり、これによりユーザーからの信頼を獲得する
利用頻度向上・離脱ユーザーの復帰
- メールやプッシュなどの通知サービス
同時購入（cross selling）
- ある商品の購入を検討しているユーザーに対し、別の商品をセット、もしくは単体で購入してもらうことで単価を上げる方法に、クロスセルというものがある
- クロスセルの実現に有効な手段として、関連アイテム推薦（product-associated recommendation）（ユーザーが現在注目しているアイテムと関連するアイテムをユーザーに表示する方法）があげられる
長期的なユーザーのロイヤルティ向上
- パーソナライズされた推薦を行うことは効果的な方法の1つ

3.3 関連トピック

アイテムの類似度
- 例えば映画であればジャンル、監督、俳優など、どの要素を使ってどのように類似度を定義するかの設計が必要になる
目新しさ・セレンディピティ・多様性
- 「関心」と「新規性」があるアイテムには目新しさ（novelty）があると言う
- 関心と新規性に「意外性」が加わった時の状態を、セレンディピティと言う
- 意外性はユーザーの定性的な感覚なので評価できないため、アイテム間の類似度を使った「多様性」の評価で代替する
推薦アイテムの選別
- 不適切なアイテムを推薦することでUXを損ねる恐れがあるようなアイテムなどは事前に推薦対象から除外しておく必要がある
推薦理由の提示
- 推薦理由（explanation of recommendations）（例：「この商品を買った人はこんな商品も買っています」）をユーザーに提示することで、推薦の効果、推薦の透明性（ユーザー情報などの入力情報と、出力されるアイテムとの因果関係がわかる状態）、ユーザーの満足度を向上させられることが知られている

3.4 この章のまとめ

章の要点
- ユーザーの目的 x サービス提供者の目的の組み合わせで様々なUI/UXのパターンが存在する
- 適切なUI/UXを使用することは、ユーザーにとって使いやすく、サービス提供者にとって利益を生むシステムの構築につながる
実務・読後に活かせるポイント
- 日頃から使用するサービスのUI／UXに関心を持ち、開発者の意図などを考えるようにする

第4章推薦アルゴリズムの概要

典型的な推薦アルゴリズムにどのようなものがあるのか、どのようにユーザーが好むアイテムを選ぶのか、どのような特徴があるのか、どのような場面で利用されるのかを解説する章である。

4.1 推薦アルゴリズムの分類

まず大きな分類として、内容ベースフィルタリング（content-based filtering）
と協調フィルタリング（collaborative filtering）
がある。

内容ベースフィルタリング

アイテムの情報を基に似たアイテムを推薦する
「ユーザー1はミステリーが好き」と「本Aはミステリー」→「ユーザー1は本Aが好きなはず」

協調フィルタリング

サービス内の他のユーザーの行動履歴を元に推薦を行う
ユーザー1と好みが似ているユーザー2を特定し、ユーザー2がすでに購入しているが、ユーザー1はまだ購入していないアイテムを推薦する

協調フィルタリングは予測の実行方法の観点から、メモリベース法（memory-based method）
とモデルベース法（model-based method）
に分けられる。

メモリベース法：事前にモデル学習は行わずに、推薦を行うタイミングで利用可能なすべてのデータを用いて予測計算を行う
モデルベース法：あらかじめ学習したモデルを作成しておき、推薦を行うタイミングで推薦を行う対象ユーザーのデータのみを利用して計算を行う

4.2 内容ベースフィルタリング

ユーザーがどのようなアイテムを好むかのユーザープロファイル（user profile）
と、アイテムの様々な性質を表す特徴を抜き出したアイテム特徴との一致度、つまり類似度を計算することで、好みに合ったアイテムをユーザーに推薦するアルゴリズムである。ユーザーの好みが、鈴木一郎が書いた、A出版社から発行されているミステリーと判断されれば、この特徴に最も多く合致したアイテムが推薦される。

4.2.1 ユーザープロファイルの獲得

ユーザーの好みを表すユーザープロファイルの獲得には、大きく2つの方法がある。

間接指定型
- ユーザーの過去の行動履歴に基づく
  - 例：ユーザーが購入しているアイテムの特徴を利用する
直接指定型
- ユーザーに自身が好きなアイテムを特徴を明示的に指定してもらう

4.3 協調フィルタリング

協調フィルタリングはメモリベース法とモデルベース法の2つに大別されるが、
メモリベース法は、推薦を受け取るユーザーと好みが似ているユーザーに注目して推薦を行う
ユーザー間型メモリベース法（user-user memory-based method） と、
推薦を受け取るユーザーが好むアイテムと似ているアイテムに注目して推薦を行う
アイテム間型メモリベース法（item-item memory-based method）
に分けられる。

行動履歴を元にした協調フィルタリングでは、ユーザーが過去に購入したアイテムをユーザーが好むアイテム、購入しなかったアイテムを好まないアイテムとして考えて、ユーザーと好みが似ているユーザーを見つけ出す。

4.3.1 嗜好データの獲得と評価値行列

ユーザーの好みに関するデータを嗜好データと呼ぶ。嗜好データを獲得する方法には以下の2つがある。

明示的獲得
- ユーザーにアンケートを回答してもらったり、アイテムのレビューをしてもらうなど、ユーザーにアイテムの好き嫌いや関心のあるなしを回答してもらうことで嗜好データを獲得する方法
暗黙的獲得
- ユーザーのアイテム購入、お気に入り登録といったサービス内の行動履歴からアイテムに対する関心を推定して嗜好データとする方法

評価値行列（rating matrix）

ユーザーがアイテムをどれほど好むかという嗜好の度合いを定量的に評価したものを評価値（ratings）といい、評価値をユーザー x アイテムで行列表記したもの

4.3.2 モデルベース法のアルゴリズム概要

モデルベース法では、既知のアイテムの規則性を学習したモデルを事前に作成しておくことで、未知のアイテムの評価値を予測して推薦する。モデルの種類・考え方として以下のようなものがある。

回帰モデル
トピックモデル**LDA（Latent Dirichlet Allocation）**などの次元圧縮
行列分解
- その積が元の行列をできるだけ再現するような形でユーザー行列とアイテム行列に分解する
- この2つの行列の類似度計算によって、任意のアイテムへの予測評価値を計算する

4.4 内容ベースフィルタリングと協調フィルタリングの比較

観点	協調フィルタリング	内容ベースフィルタリング
多様性の向上	○	×
ドメイン知識を扱うコスト	○	×
コールドスタート問題への対応	×	△
ユーザー数が少ないサービスにおける推薦	×	○
被覆率の向上	×	○
アイテム特徴の活用	×	○
予測精度	○	△

多様性
- 協調フィルタリングなら、自身は知らなくても自身と似た他のユーザーが知っているアイテムであれば推薦対象とできる
ドメイン知識を扱う
- ドメイン知識の保持には膨大なコストがかかるため、ドメイン知識を不要としている協調フィルタリングの方が、コスト観点では優れている
コールドスタート問題
- ユーザーの過去の嗜好データがないと、協調フィルタリングは機能しない
ユーザー数が少ないサービス
- 他ユーザーの行動履歴をベースにする協調フィルタリングでは、ユーザー数が少ないと似ているユーザーや、推薦対象のユーザーが関心があるであろうアイテムを見つけられない可能性がある
被覆率の向上
- 被覆率（coverage）とは、サービスにあるすべてのアイテムのうち、推薦システムでユーザーに推薦できるアイテムの割合のこと
- 協調フィルタリングでは、似たユーザーが誰も試していないアイテムに対しては、評価されていないため推薦対象にならない
アイテム特徴の活用
- 協調フィルタリングでは、アイテムの特徴を利用しないのが一般的
予測精度（ある程度の規模のサービスで、多数派である一定以上アクティブにサービスを利用している一般的な嗜好傾向を持つユーザーへの推薦を考えたとき）
- 一般的には、協調フィルタリングの方が予測精度が高いと言われている
- ユーザーの行動履歴を考慮している協調フィルタリングの方が、より複雑なユーザーの嗜好を考慮できていると考えられるから
- さらに、ユーザーがサービスを利用するほど、推薦に活かせるデータが増えるため

4.5 推薦アルゴリズムの選択

内容ベースフィルタリング、協調フィルタリングのどちらか一方を選択するのではなく、これらを組み合わせたハイブリッドな手法をとったり、ユーザーやアイテムによって異なる手法を取ることが多い。以下にアルゴリズムの選択において考慮する観点を整理しておく。

サービス内のデータ量
- データが少ない新規サービスや、ある程度の規模でも新規ユーザー・アイテムの推薦においては、内容ベースフィルタリングを採用することが多い
- ある程度規模の大きいサービスや、データが蓄積されたユーザー・アイテムに関しては、協調フィルタリングを採用する
提供形態
- 概要推薦なら、統計データを用いた人気リストやシンプルな内容ベースフィルタリング
- 関連アイテム推薦なら、コスト観点からアイテム間型のメモリベース法の協調フィルタリング
多様性
- 多様性が低い（欲しいものが決まっている）ような場合は、直接指定型の内容ベースフィルタリング
- 多様性が高い（欲しいものが特に決まっていない）場合は、多様性の高さが大事になってくるため、新規性やセレンディピティを重視できる協調フィルタリングを採用する

4.6 嗜好データの特徴

嗜好データの獲得方法として、明示的獲得と暗黙的獲得がある。以下の表にそれぞれの方法の長所と短所をまとめる。

観点	明示的獲得	暗黙的獲得
データ量	×：少ない	○：多い
データの正確さ	○：正確	×：不正確
未評価と不支持の区別	○：明確	×：不明確
ユーザーの認知	○：認知	×：不認知

データ量
- わざわざアンケートに積極的に回答してくれるユーザーは少ないが、暗黙的獲得ならユーザーがサービスを利用する限りはそのユーザーの行動から嗜好データを取得し続けることができる
データの正確さ
- 暗黙的獲得では、誤クリックや途中離脱をした際に、誤った嗜好データが獲得される可能性がある
未評価と不支持の区別
- 未評価：あるユーザーからあるアイテムへの嗜好データがない状態
- 不支持：あるユーザーからあるアイテムに対して、嫌いや関心がないなどのようなネガティブな嗜好データが得られている状態
ユーザーの認知
- 推薦をする際、ユーザーの認知が得られている方が推薦を受け入れやすく、サービスに対して良い印象を持ってもらいやすいと性質が知られている

4.6.1 嗜好データを扱う際の注意点

データのスパース性
- ユーザーとアイテム間の評価値行列の成分では、ほとんどの項目が未評価（欠損）の状態（スパースな状態）になる
評価値の揺らぎやバイアス
- 揺らぎ：同じユーザーの同じアイテムの評価において、タイミングによって評価値が変わること
- ユーザーの嗜好性は変化するのが通常
- 嗜好データには様々なバイアスが存在する
ユーザーは気に入ったものしか評価しない
そもそもユーザーに表示されるアイテムは人気であるものがほとんどなので、嗜好データは人気アイテムに集まりやすいという人気バイアス
高い評価をつけがちなユーザーや、逆に低い評価をつけがちな人もいる

4.7 この章のまとめ

章全体の要点
- 推薦アルゴリズムは大きく内容ベースフィルタリングと協調フィルタリングに分類される
- 協調フィルタリングはさらにメモリベース法とモデルベース法に分かれる
- 内容ベースは「ユーザー × アイテム特徴」の一致度で推薦する手法
- 協調フィルタリングは「似たユーザー」または「似たアイテム」の行動履歴を利用する手法
- 嗜好データには明示的獲得と暗黙的獲得があり、それぞれ長所・短所がある
- 嗜好データはスパース性やバイアスを強く持つため、取り扱いに注意が必要
実務・読後に活かせるポイント
- 新規サービス・新規ユーザーには内容ベースを軸にする
- データが蓄積されたら協調フィルタリングを組み合わせる
- 多くの実サービスでは内容ベース × 協調フィルタリングのハイブリッド構成が現実解
- 精度だけでなく多様性・被覆率・運用コストも含めてアルゴリズムを選択する

第5章推薦アルゴリズムの詳細

具体的な推薦アルゴリズムの概要を説明する章である。

5.1 各アルゴリズムの比較

アルゴリズム名	概要	予測精度	計算速度（大規模データで計算）	コールドスタート問題への対応
ランダム推薦	ランダムにアイテムを推薦する。ベースラインとして利用されることがある	×	◎	○
統計情報や特定のルールに基づく推薦（人気度推薦など）	ベースラインとしてよく利用される	×	◎	○
アソシエーションルール	シンプルな計算方法で、SQLでも実装が可能なため、昔から幅広く活用されている	○	○	×
ユーザー間型メモリベース法協調フィルタリング	類似したユーザーの行動履歴を利用して推薦を行う	○	○	×
回帰モデル	回帰問題として推薦タスクを定式化し、種々の機械学習手法を適用する	○	○	○
SVD（特異値分解）	シンプルな行列分解手法	△	△	×
NMF（非負値行列分解）	非負という制約を加えた行列分解手法	△	△	×
MF（Matrix Factorization）	Netflixのコンペで好成績を収めた行列分解手法	○	○	×
IMF（Implicit Matrix Factorization）	暗黙的評価値に対応した行列分解手法	○	○	×
BPR（Bayesian Personalized Ranking）	暗黙的評価値に対応したランキングを考慮した行列分解手法	○	○	×
FM（Factorization Machines）	評価値以外にもアイテムやユーザーの情報を加味することが可能な手法	○	○	○
LDA（コンテンツベース）	アイテムのコンテンツ情報にトピックモデルを適用して推薦する手法	△	△	○
LDA（協調フィルタリング）	ユーザーの行動履歴にトピックモデルを適用して推薦する手法	○	△	×
word2vec（コンテンツベース）	アイテムのコンテンツ情報にword2vecを適用して推薦する手法	△	○	○
item2vec（協調フィルタリング）	ユーザーの行動履歴にword2vecを適用して推薦する手法	○	○	×
深層学習	深層学習を用いた推薦手法	○	△	○

5.2 統計情報や特定のルールに基づく推薦（人気度推薦など）

パーソナライズせずにユーザーの年齢や性別、居住地などの人口統計学的なデータに基づいてアイテムを推薦することをデモグラフィックフィルタリング（demographic filtering）
と呼ぶ。
比較的単純な推薦方法だが、アイテムが推薦されている理由がユーザーに分かりやすく、決して侮れない効果がある。

例）

売り上げアイテム上位のアイテムや、ユーザーの評価値の平均値などを使ってアイテムを並べ替える
アイテムの価格や大きさなど特定の属性の順番に並び替える
ユーザーの年齢などの特定の情報をもとに推薦

5.3 アソシエーションルール

「アイテムAとアイテムBは同時に購入されることが多い」といった法則を見つける。有名な例にオムツとビールがある。
以下のような購入履歴データを使用して解説する。

ユーザー	アイテムA	アイテムB	アイテムC
ユーザー1	○	○
ユーザー2	○	○
ユーザー3			○
ユーザー4	○	○	○

5.3.1 支持度

あるアイテムが全体の中で出現した割合を表す
支持度(A)= (Aの出現数)/(全データ数) = 3/4
支持度(A and B) = (AとBの同時出現数)/(全データ数) = 3/4

5.3.2 確信度

アイテムAが出現した時に、アイテムBが出現する割合
確信度(A=>B) = (AとBの同時出現数)/(Aの出現数) = 3/3 = 1
このとき、Aを条件部（antecedents）、Bを帰結部（consequents）と呼ぶ。

5.3.3 リフト値

アイテムAとアイテムBの出現がどれくらい相関しているかを表すもの
リフト(A=>B) = 支持度(A and B)/(支持度(A) * 支持度(B))=0.75/(0.75*0.75)=1.333
アイテムAとアイテムBの出現が互いに一切関係ない独立した場合には、リフト値は1になる
片方のアイテムの出現ともう片方の出現に正の相関がある場合は、リフト値は1より大きくなる
片方のアイテムが出るともう片方のアイテムが出現しなくなるといった負の相関の場合は、リフト値は1より小さくなる
アイテムが3つの場合は、リフト((A and B)=>C) = 支持度(A and B and C)/(支持度(A and B) * 支持度(C))

5.3.4 アプリオリアルゴリズム

計算の高速化のため、実際は支持度がある一定以上のアイテムや、アイテムの組み合わせのみを計算対象としている
閾値を上げすぎると一部の人気アイテムのみ推薦され、下げすぎると計算が重くなりノイズが多い多様な推薦になる

5.4 ユーザー間型メモリベース法協調フィルタリング

以下の過程で実現される。

既存の映画評価値を用いてユーザー間の類似度を計算し、推薦対象ユーザーと嗜好が似ているユーザーを抽出する
- 類似度の算出にはピアソンの相関係数などを使用する
類似ユーザーの評価値を基に、推薦対象ユーザーが未評価のアイテムに対する予測評価値を算出する
予測評価値が高いアイテムを推薦対象ユーザーに提示する

5.5 回帰モデル

映画評価値を回帰問題として定式化することで、機械学習の様々な方法を試すことができる

5.6 行列分解

モデルベース型の協調フィルタリングに分類される

5.6.1 行列分解の概要

推薦システムにおける行列分解は広義の意味で、評価値行列を低次元のユーザー因子行列とアイテム因子行列のベクトルで表現し、そのベクトルの内積値をユーザーとアイテムの相性としている
行列分解の手法を実務で実施するときの注意観点
- 欠損値の取り扱い
- 評価値が明示的か暗黙的か
今回例として扱っている映画評価データのように、全ユーザー x アイテムのほとんどが欠損値になっているスパースなデータは、低次元のベクトルで表現する必要がある

5.6.2 特異値分解（SVD: Singular Value Decomposition）

欠損している箇所に0または平均値を代入する手法
ゼロの値はユーザーがそのアイテムを嫌っていることを表すが、欠損値はユーザーの好みがわからない状態を本来は示している
そのため、欠損値を0で埋める方法の推薦精度は非常に悪い

任意の $m \times n$ 行列 $\mathbf{R}$ に対して、SVD は次のように表される。

$$
\mathbf{R} = \mathbf{U} \mathbf{\Sigma} \mathbf{V}^\top
$$

$\mathbf{R}$：評価値行列（ユーザー × アイテム）
$\mathbf{U}$：ユーザー行列（ユーザー × 潜在因子）
$\mathbf{\Sigma}$：特異値を対角成分にもつ行列
$\mathbf{V}$：アイテム行列（アイテム × 潜在因子）

ここで、$\mathbf{\Sigma}$ の対角要素を 特異値 と呼び、
データの重要度を表す。

SVDには、潜在因子というパラメータがあり、これは
ユーザーやアイテムの嗜好・特徴を 明示的には観測できないが、行動データから推定される抽象的な軸 のことである。

例

映画推薦
- 潜在因子1：アクション ↔ ロマンス
- 潜在因子2：大衆向け ↔ 芸術性
書籍推薦
- 潜在因子：ジャンル、文体、難易度など

SVDでは、

$\mathbf{U}_k$：各ユーザーが潜在因子をどの程度好むか
$\mathbf{V}_k$：各アイテムが潜在因子をどの程度持つか

を数値ベクトルとして学習する。

5.6.3 非負値行列分解（NMF：Nonnegative Matrix Factorization）

行列分解後のユーザーとアイテムの各ベクトルの要素が0以上になる（前述のSVDでは、行列分解後の行列において負の値を取ることがある）
各ユーザー・アイテムベクトルの解釈性は SVDより高いが、欠損値をゼロで埋めることが多いため、精度は低い

5.6.4 明示的な評価値に対する行列分解（MF：Matrix Factorization）

欠損値を埋めるようなことはせず、観測された評価値のみを使って行列分解する手法
MF では、観測されている評価値のみを用いて、予測誤差が最小となるように行列 $\mathbf{P}, \mathbf{Q}$ を学習する

$$
\min_{\mathbf{P}, \mathbf{Q}} \sum_{(u,i)\in \mathcal{K}} \left( r_{ui} - \mathbf{p}_u^\top \mathbf{q}_i \right)^2
$$

$\mathcal{K}$：評価値が観測されているユーザーとアイテムの組
欠損している評価値は誤差計算に含めない

過学習を防ぐため、通常は L2 正則化項を加える。

この最適化問題は閉形式解を持たないため、反復的な数値最適化手法によって解く。

SGD(Stochastic Gradient Descent)：入力データをサンプリングして、そのデータ点におけるユーザー因子行列とアイテム因子行列の勾配を計算して、pとqの勾配方向に沿って更新する
ALS(Alternating Least Square)：ユーザー因子行列とアイテム因子行列を交互に目的変数を最小化するように最適化する

5.6.5 暗黙的な評価値に対する行列分解（IMF: Implicit Matrix Factorization）

明示的な評価値では、星5と星1に集まりやすいバイアスがある
そこで、あえて、星4以上なら1、それ以外なら0といったように、暗黙的な評価値として扱う手法もある
暗黙的評価値として以下のような特徴がある
- 負例がない
- クリック数など評価値が取りうる値の範囲が広い
- ノイズが多い

ユーザー $u$ がアイテム $i$ に対して行った行動量を$r_{ui}$ と表す。

例：
- 購入回数
- 再生回数
- 閲覧回数
- クリック回数

$r_{ui}$ は「どれだけ関心を示したか」を表すが、好んだかどうか（正例か負例か）を直接示すものではない。

IMF では、$r_{ui}$ を次のように 2 値変数に変換する。

\bar{r}_{ui} = \begin{cases} 1 & (r_{ui} > 0) \\ 0 & (r_{ui} = 0) \end{cases}

$\bar{r}_{ui} = 1$：ユーザーがアイテムに何らかの行動をした
$\bar{r}_{ui} = 0$：行動が観測されていない

ここで重要なのは、
$\bar{r}_{ui} = 0$ は「嫌い」ではなく 「不明（未観測）」を意味する 点である。

IMFでは、行動量 $r_{ui}$ に応じてその観測値をどれだけ信頼するかを 信頼度（confidence） として定義する。

一般的な定義は次の通りである。

$$c_{ui} = 1 + \alpha r_{ui}$$

$\alpha$：ハイパーパラメータ
行動量が多いほど、信頼度が高くなる
$r_{ui} = 0$ の場合でも $c_{ui} = 1$ として扱う

ユーザー $u$ とアイテム $i$ の予測値は、通常の Matrix Factorization と同様に内積で表される。

$$\hat{r}_{ui} = \mathbf{p}_u^\top \mathbf{q}_i$$

$\mathbf{p}_u$：ユーザー $u$ のベクトル
$\mathbf{q}_i$：アイテム $i$ のベクトル

IMF（Implicit Matrix Factorization）では、2値化された評価値 $\bar{r}_{ui}$ と信頼度

$c_{ui}$ を用いて、次の最適化問題を解く。

$$
\min_{\mathbf{P}, \mathbf{Q}} \sum_{u,i} c_{ui} \left( \bar{r}_{ui} - \mathbf{p}_u^\top \mathbf{q}_i \right)^2 + \lambda \left( \sum_u |\mathbf{p}_u|^2 + \sum_i |\mathbf{q}_i|^2 \right)
$$

観測・未観測を含む 全ユーザー × 全アイテム の組を対象
信頼度 $c_{ui}$ により、重要な行動を強く反映
$\lambda$：正則化係数

5.6.6 BPR (Bayesian Personalized Ranking)

暗黙的評価値（implicit feedback）を対象としたランキング最適化型の推薦アルゴリズム
Matrix Factorization や IMF が「評価値をどれだけ正確に再現するか」を目的とするのに対し、BPRは

ユーザーにとって好ましいアイテムが、好ましくないアイテムよりも上位にランキングされることを直接的に最適化する

基本的な考え方

BPR では、次のような 相対的な好み を仮定する。

ユーザー $u$はアイテム $i$（観測済み）をアイテム $j$（未観測）よりも好む

これを

$$i \succ_u j$$
と表す。

モデル化とスコア関数

BPR では、ユーザー $u$ とアイテム $i$ のスコアを行列分解モデルで次のように定義する。

$$\hat{x}_{ui} = \mathbf{p}_u^\top \mathbf{q}_i$$

$\mathbf{p}_u$：ユーザー $u$ の潜在ベクトル
$\mathbf{q}_i$：アイテム $i$ の潜在ベクトル

ユーザー $u$ が $i$ を $j$ より好む確率は、スコア差を用いて表現される。

\hat{x}_{uij} = \hat{x}_{ui} - \hat{x}_{uj}

最大化する目的関数

BPR は、次の対数尤度を 最大化 する。

$$
\max_{\mathbf{P}, \mathbf{Q}} \sum_{(u,i,j) \in \mathcal{D}} \ln \sigma(\hat{x}_{uij}) - \lambda \left( |\mathbf{p}_u|^2 + |\mathbf{q}_i|^2 + |\mathbf{q}_j|^2 \right)
$$

$\sigma(x)$：シグモイド関数
$\mathcal{D}$：$(u, i, j)$ の三つ組集合
- $i$：ユーザー $u$ が行動したアイテム
- $j$：ユーザー $u$ が行動していないアイテム
第1項：正例が負例より上位になる確率を最大化
第2項：過学習を防ぐ正則化項

この目的関数により、

観測されたアイテムは、未観測のアイテムよりも高くランキングされる

という性質が学習される。

未観測アイテムのサンプリングが重要な理由

BPR では、未観測アイテムを 負例候補 として扱うが、「未観測 = 嫌いではない」。また、実務では未観測のアイテムは膨大にある。

そのため、

どの未観測アイテムを $j$ として選ぶか
どの頻度で選ぶか

が学習結果に大きく影響する。

全アイテムを対象にすると計算量が膨大になるため、サンプリングによって負例を選択する

一様サンプリング：未観測アイテムからランダムに $j$ を選ぶ
人気度に基づくサンプリング：人気アイテムほど高い確率でサンプリング
ハードネガティブサンプリング：スコアが高い未観測アイテムを優先的に選ぶ

5.6.7 FM（Factorization Machines）

評価値だけでなく、ユーザーやアイテムの属性情報を扱う方法
属性情報を使うことで、コールドスタート問題にも対応可

FMが解決したい課題

従来の手法では、

協調フィルタリング：ID情報のみ
内容ベース：特徴量のみ

という分離があった。

FM はこれらを統合し、

「どの特徴同士の相互作用が重要か」を 行列分解によって自動的に学習する。

FMで使用するデータ構造

FMでは、1サンプルを 特徴ベクトル $\mathbf{x}$ として表現する。

特徴量の例

特徴グループ	具体例	値
ユーザーID	user_123	1
アイテムID	item_45	1
ユーザー属性	gender=male	1
ユーザー属性	age=20s	1
アイテム属性	genre=action	1
アイテム属性	price	1500

One-hot / multi-hot / 数値特徴を混在可能
大部分は 0 になる（疎行列）

特徴ベクトルのイメージ

特徴インデックス	1	2	3	4	5	6	...
意味	user_123	item_45	male	20s	action	price	...
$x_i$	1	1	1	1	1	1500	...

この 1本のベクトルを FM に入力する。

Factorization Machines の数式

FM（2次まで考慮する場合）の予測値は次式で定義される。

$$
\hat{y}(\mathbf{x}) = w_0 + \sum_{i=1}^{n} w_i x_i + \sum_{i=1}^{n} \sum_{j=i+1}^{n} \langle \mathbf{v}_i, \mathbf{v}_j \rangle x_i x_j
$$

各項の意味

$w_0$：バイアス項
$\sum w_i x_i$：各特徴の線形効果
$\langle \mathbf{v}_i, \mathbf{v}_j \rangle x_i x_j$：特徴 $i$ と $j$ の 相互作用

潜在ベクトルによる相互作用

各特徴 $i$ に対して、$k$ 次元の潜在ベクトル $\mathbf{v}_i \in \mathbb{R}^k$ を割り当てる。

\langle \mathbf{v}_i, \mathbf{v}_j \rangle = \sum_{f=1}^{k} v_{i,f} v_{j,f}

これにより、

明示的に交差特徴を作らなくても
未観測な組み合わせでも

相互作用を推定できる。

5.7 自然言語処理手法の推薦システム応用

自然言語処理に使われるモデルを利用することで、商品の説明文やレビュー文を使った推薦（コンテンツベース）が可能になる
これらの手法を行動履歴に適用することで、協調フィルタリングベースの推薦も可能になる
この本では、トピックモデル（LDA）とword2vecを使った方法を解説している

5.7.1 トピックモデル

本章では、トピックモデルの基本概念を整理したうえで、実務で広く使われている LDA（Latent Dirichlet Allocation） の概要と用途、さらにLDAを用いた コンテンツベース推薦 と 協調フィルタリング推薦 について解説する。

トピックモデルにおける トピック（topic） とは、

文書集合に潜在的に存在する単語の共起パターンを表す確率分布

である。

トピックの直感的なイメージ

トピック = 単語の集合（確率分布）
文書 = 複数トピックの混合

例（映画レビュー）：

トピック1：
「アクション」「戦闘」「迫力」「スピード」
トピック2：
「恋愛」「感動」「切ない」「人間関係」

1つのレビューは、「アクション 70% + 人間ドラマ 30%」のように表現される。

LDA（Latent Dirichlet Allocation）の概要

LDA は、最も代表的なトピックモデルであり、以下の仮定に基づいて文書集合を生成する確率モデルである。

LDA の基本仮定

各文書は、複数のトピックの混合で構成される
各トピックは、単語に対する確率分布を持つ
文書ごとのトピック分布・トピックごとの単語分布はディリクレ分布に従う

LDA により推定されるもの

LDA を学習すると、主に次の2つが得られる。

文書ごとのトピック分布
$$\theta_d = (p(z_1|d), \dots, p(z_K|d))$$
トピックごとの単語分布
$$\phi_k = (p(w_1|z_k), \dots, p(w_V|z_k))$$

これにより、文書を低次元なトピック空間で表現できる。

5.7.2 LDA を用いたコンテンツベース推薦

映画のレビューテキストを用いて、

各映画を「トピック分布ベクトル」で表現
ユーザーの好みをトピック空間で表現
類似度に基づいて推薦

を行う。

処理の流れ

映画レビュー文書集合に対してLDAを学習
各映画 $i$ をトピック分布 $\theta_i$ として表現
ユーザーが高評価した映画のトピック分布を平均し、ユーザープロファイル $\theta_u$ を作成
$\theta_u$ と $\theta_i$ の類似度を計算して推薦

特徴

新規映画でもレビューがあれば推薦可能
テキスト内容に基づくため解釈性が高い
協調情報は利用しない

5.7.3 LDAを用いた協調フィルタリング推薦

LDA を ユーザーの行動履歴 に適用し、

ユーザーを「トピックの混合」として表現
アイテムを直接使わず、行動パターンの類似性を捉える

方法である。

データの見方

文書：ユーザー
単語：ユーザーが行動したアイテム（映画）
出現回数：視聴・購入・レビュー回数

このように見立てることで、LDA を協調フィルタリングに転用する。

処理の流れ

ユーザー × アイテムの行動履歴を文書として構築
LDAを適用し、ユーザーごとのトピック分布を推定
トピック分布が似ているユーザーを見つける
類似ユーザーが好むアイテムを推薦

特徴

ユーザーの嗜好傾向を低次元で表現可能
行列分解と同様に潜在構造を捉える
テキスト情報は不要

5.7.4 LDA利用時のコンテンツベースと協調フィルタリングの違い

観点	コンテンツベース	協調フィルタリング
LDA の入力	レビューテキスト	行動履歴
表現対象	アイテム	ユーザー
コールドスタート	強い	弱い
解釈性	高い	やや低い

5.7.5 word2vecを利用したコンテンツベース推薦

word2vec の概要

word2vecは、単語を低次元の連続ベクトルとして表現する手法であり、文脈が似ている単語ほど、ベクトル空間上で近くなる性質を持つ。

この「文脈の類似性」を推薦におけるアイテムやユーザーの類似性に置き換えて応用する。

5.7.6 word2vecを用いたコンテンツベース推薦

基本アイデア

書籍 EC サイトにおいて、

書籍の「あらすじ」をテキストデータとして扱い
word2vec により単語をベクトル化
書籍を単語ベクトルの集合（または平均）として表現

することで、内容が似ている書籍を推薦する。

特徴と利点

テキスト内容を直接活用できる
新刊書籍でも、あらすじがあれば推薦可能
トピックモデルより柔軟な意味表現が可能

5.7.7 word2vecを用いた協調フィルタリング推薦（item2vec）

item2vec の基本アイデア

item2vec は、

word2vecを「ユーザーの行動履歴」に適用した協調フィルタリング手法

である。

単語と文脈の置き換え

word2vec	item2vec
単語	アイテム
文	ユーザーの行動列
文脈	同一ユーザー内で近くに出現したアイテム

映画レビューに基づく推薦の例

ここでは、映画レビュー（視聴・評価履歴） を用いて
word2vec を協調フィルタリングに応用した
item2vec による推薦手法を解説する。

item2vec の基本的な考え方

item2vec は、

word2vecの「単語」と「文脈」の概念を「アイテム」と「ユーザー行動」に置き換えた手法

である。

映画推薦においては、

単語 → 映画
文 → 1人のユーザーの映画視聴（レビュー）履歴
文脈 → 同じユーザーが視聴・評価した他の映画

として扱う。

あるユーザーの映画レビュー履歴：

「マトリックス」 ★★★★★
「インセプション」 ★★★★☆
「ブレードランナー」 ★★★★☆

このユーザーの履歴を、
1つの文（シーケンス） として扱う。

マトリックスインセプションブレードランナー

すべてのユーザーについて同様の変換を行い、大量の「映画列」をコーパスとして用意する。

学習方法（Skip-gram）

item2vec では、word2vec の Skip-gram モデルがよく用いられる。

ある映画が与えられたとき
同じユーザーが視聴した他の映画を予測する

つまり、

同じユーザーに一緒に見られやすい映画ほどベクトル空間上で近くなる

ように学習される。

item2vecの特徴

観点	内容
入力	ユーザーの映画視聴・レビュー履歴
学習対象	映画の分散表現
推薦方法	類似映画推薦
強み	暗黙的評価値との相性が良い
弱み	新規映画への対応が弱い

item2vec は、

「アイテム同士の関係性」をシンプルかつ直感的に学習できる

点が特徴である。

5.8 深層学習（Deep Learning）

深層学習（Deep Learning）を用いた推薦システムは、従来の協調フィルタリングや行列分解では扱いにくかった非構造データや複雑なユーザー行動を扱える点が大きな特徴である。

5.8.1 深層学習を推薦に用いる主な目的1 非構造データからの特徴量抽出

従来の推薦システムでは、

映画ジャンル
商品カテゴリ
手動で付与されたタグ

といった人手で設計された特徴量に強く依存していた。

一方、深層学習を用いることで、

テキスト（レビュー、説明文）
画像（商品画像、サムネイル）
音声・動画

といった非構造データを、そのまま入力として扱い、

高次元・非構造なデータを低次元のベクトル表現（Embedding）に変換

することが可能になる。

これにより、

タグ設計・保守コストの削減
ドメイン依存の特徴設計からの脱却
新規アイテムへの柔軟な対応

が実現できる。

5.8.2 深層学習を推薦に用いる主な目的2 複雑なユーザー行動とアイテム関係のモデリング

現実のユーザー行動は、

非線形
文脈依存
時系列的に変化

するといった性質を持つ。

深層学習は、

非線形関係の表現
高次の特徴交互作用
行動履歴の時系列モデリング

を表現できるため、複雑な嗜好構造を直接モデル化できる。

複雑なユーザー行動を扱う代表的モデル

Neural Collaborative Filtering（NCF）

NCF は、従来の行列分解（MF）をニューラルネットワークで拡張したモデルである。

特徴

ユーザーID・アイテムIDを埋め込みベクトルに変換
内積ではなく、MLP（多層パーセプトロン）で相互作用を学習
非線形な嗜好関係を表現可能

ポイント

「ユーザー × アイテム = スコア」という単純構造を超えられる
MFの自然な拡張として理解しやすい

DeepFM

DeepFM は、

FM（Factorization Machines）
Deep Neural Network

を組み合わせたモデルである。

構成

FM 部分：
低次の特徴交互作用を効率よく学習
Deep 部分：
高次・非線形な特徴交互作用を学習

特徴

手動特徴量と学習特徴量を同時に活用
CTR予測や広告推薦で広く利用されている

Wide & Deep Learning

Wide & Deep は、

Wide 部分：線形モデル（ルールベース・記憶）
Deep 部分：ニューラルネット（一般化）

を同時に学習するモデルである。

考え方

Wide：
「この条件なら必ず出す」といった既知パターンを覚える
Deep：
未知の組み合わせを一般化して学習する

特徴

安定性と表現力のバランスが良い
実サービス（Google Play など）での利用実績がある

5.8.3 特徴量抽出器としての深層学習

深層学習は、

CNN / Transformer → 画像・テキスト埋め込み
RNN / Transformer → 行動履歴表現

といった形で、**特徴量抽出器（Encoder）**として利用されることが多い。

抽出されたベクトルは、

行列分解
kNN
ランキングモデル

など、他の推薦手法と組み合わせて利用できる。

5.8.4 予測モデルとしての深層学習

一方で、

CTR予測
スコアリング
ランキング最適化

といった最終予測モデルとして深層学習を用いるケースも多い。

特に、

大規模データ
特徴量が多様
非線形関係が強い

といった条件では、深層学習の効果が出やすい。

5.8.5 実務での活用における注意点

メリット

非構造データを直接扱える
特徴設計の柔軟性が高い
高精度が期待できる

注意点

学習・推論コストが高い
モデルがブラックボックス化しやすい
データ量が少ないと効果が出にくい

そのため実務では、

「すべてを深層学習で置き換える」のではなく特徴量抽出 or 一部モデルとして使う」

という形が多い。

5.9 バンディットアルゴリズム

バンディットアルゴリズムとは、限られた試行回数の中で報酬を最大化するための意思決定手法である。

推薦システムにおいては、

表示するアイテム（腕：arm）を選択し
ユーザーの反応（クリック・購入など）を報酬として観測し
観測結果をもとに次の選択を改善する

というオンライン学習の枠組みとして用いられる。

探索と活用のトレードオフ

バンディットアルゴリズムの本質は、

探索（exploration）
まだよく分かっていないアイテムを試す
活用（exploitation）
これまで高い報酬を得たアイテムを選ぶ

のバランスを取る点にある。

推薦システムでの役割

クリック率などの不確実性を考慮した推薦
新規アイテム（コールドスタート）への対応
オンラインでの順位調整・ABテストの自動化

に適している。

代表的な手法

ε-greedy
UCB（Upper Confidence Bound）
Thompson Sampling

位置づけ

バンディットアルゴリズムは、

オフライン学習（協調フィルタリング・深層学習）
オンライン最適化（バンデッド）

を補完する技術として、
実務の推薦システムで広く利用されている。

5.10 この章のまとめ

章全体の要点

行列分解（Matrix Factorization）の進化: 疎な評価値行列を潜在因子に分解する手法を核とし、暗黙的評価値に特化したIMFや、ランキング順位を直接最適化するBPRなど、データの性質に合わせた最適化が進んでいる
属性情報の活用: FM（Factorization Machines） はユーザー・アイテムIDだけでなく、属性情報を統合して相互作用を学習できるため、コールドスタート問題への強力な解決策となる
自然言語処理技術の転用: LDAやword2vecは、テキストを用いたコンテンツベース推薦だけでなく、行動履歴を「文脈」と見立てることで、高度な協調フィルタリング（item2vec等）としても応用可能
深層学習とオンライン最適化: 深層学習は非構造データ（画像・テキスト）の活用や複雑な非線形関係の学習を可能にし、バンディットアルゴリズムは「探索と活用」のバランスを取りながらリアルタイムな最適化を実現する

実務・読後に活かせるポイント

スモールスタートの原則: まずはSQLでも実装可能で解釈性の高い「人気度推薦」や「アソシエーションルール」をベースラインとして構築し、段階的に高度なモデルへ移行するのが定石
フィードバックの種類に応じた選択: データの性質（星評価などの明示的評価か、閲覧・購入などの暗黙的評価か）を見極め、適切な損失関数を持つアルゴリズム（MF vs IMF/BPR）を選択することが精度向上の鍵となる
ハイブリッド構成の検討: レビューや商品詳細などのテキストデータがある場合は、自然言語処理手法で特徴量化し、IDベースの手法の弱点（新規アイテムへの弱さ）を補完する構成が実務では効果的
コンテキストの統合: ユーザー属性や利用環境（デバイス、時間等）が豊富な場合、それらをモデルに組み込めるFMや深層学習（DeepFM, Wide & Deep）を採用することで、よりパーソナライズされた推薦が可能になる
継続的な改善（オンライン学習）: 静的なバッチ学習だけでなく、新規アイテムの露出やユーザーの最新の反応を即座に反映させたい場合は、バンディットアルゴリズムによる自動的なABテスト・最適化の導入を検討

第6章実システムへの組み込み

6.1 システム概要

6.1.1 バッチ推薦とリアルタイム推薦

観点	バッチ推薦	リアルタイム推薦
モデル学習	定期的にまとめて学習（例：1日1回、数時間おき）	オンライン学習、または頻繁な再学習
特徴量の抽出・更新	バッチ処理で一括生成・更新	ユーザー行動に応じてリアルタイム更新
予測の実行タイミング	事前に予測結果を計算（バッチ）	リクエスト時に即時計算（リアルタイム）

バッチ推薦：アイテムやユーザーの新追加や更新頻度が低く、フレッシュネス（情報が利用可能になった時点から推薦に活用されるまでの時間）が低くても問題ないケースに適している
リアルタイム推薦：アイテムやユーザーの新追加や更新頻度が高く、フレッシュネスが高いケースに適している

6.1.2 多段階推薦

システム負荷を低く保ちつつ、精度の良い推薦を実施するために「候補選択」「スコアリング」「リランキング」の多段階に処理を分ける工夫がある
「候補選択」「リランキング」の2つで構成される推薦システムを2段階推薦（two-stage recommendation）と呼ばれる

候補選択

膨大なアイテムから推薦候補となるアイテムを抽出する処理
Youtubeでは、数10億のアイテムをこの段階で100 ~ 10,000に削減する
処理の高速性が求められるため、単純なアルゴリズムが重宝される

スコアリング

ユーザーにアイテムを推薦するためにアイテムに対してスコアを付与する
候補選択後なので、高度な推論を使用することが多い

リランキング

スコアリングされたアイテムの並び替えを実施

6.2 この章のまとめ

章全体の要点

実システムにおける推薦システムは、モデル単体ではなくシステム全体として設計される必要がある
推薦方式は大きくバッチ推薦とリアルタイム推薦に分かれ、それぞれに適した利用シーンが存在する
バッチ推薦は計算効率と運用の容易さに優れ、リアルタイム推薦はフレッシュネスと即時性に優れる

実務・読後に活かせるポイント

推薦アルゴリズムの選択は、精度だけでなくフレッシュネス・レイテンシ・運用コストも含めて判断する必要がある
多くの実サービスでは、バッチ処理とリアルタイム処理を組み合わせたハイブリッド構成が採用されている

第7章推薦システムの評価

推薦システムの評価として

オフライン評価
オンライン評価
ユーザースタディ
があり、それぞれの長所と短所に関して解説する。

7.1 3つの評価方法の概要

オフライン評価

実際のサービス上で得られた過去のログデータを使用
メリット
- 評価のコストが低い
- データ量が豊富なので、評価値のばらつきが小さい
デメリット
- オフライン指標で良くてもリリースすると、目標のKPIが向上しないことがある

オンライン評価

新しい推薦モデルやUIを一部のユーザーに実際に提供して評価する
メリット
- オフライン評価よりも正確に評価できる
デメリット
- 実装コストが高い
- UXを損ねるリスクがある

ユーザースタディ

ユーザーへのインタビューやアンケートによって定性的な評価を得る
メリット
- サービスログからは知り得ない情報が得られる
デメリット
- 個人の嗜好によるばらつきが大きい
- データ量が限られる

7.2 オフライン評価

推薦システムは時系列データの扱いが重要になるため、学習期間で得ることができないデータを学習に含めてしまうリークに注意が必要
学習データの扱いと同様に、パラメータチューニングにおいても注意が必要で、パラメータチューニングの際は、テストデータではなく、Validデータを使用する

7.2.1 評価指標

指標の分類	利用目的	代表的な指標
予測誤差指標	学習モデルがどれほどテストデータの評価値に近い予測ができているかを測る	MAE、RMSE
集合の評価指標	推薦されたアイテム集合全体として、どれだけ正解アイテムを含んでいるかを評価する。推薦結果を集合として捉える	Precision@k、Recall@k、F1@k
ランキング評価指標	推薦リストの順位の良さを評価する。正解アイテムが上位に来ているかを重視する	MAP、NDCG@k、MRR
その他の評価指標	推薦システムの性質や体験価値を多面的に評価する。精度以外の観点を補完する	Coverage、Diversity、Novelty、Serendipity

予測誤差指標

ユーザーがアイテムに付与した評価値と、システムが評価した評価値の誤差を評価することを例として説明する。

MAE（Mean Absolute Error）

$$\mathrm{MAE} = \frac{1}{N} \sum_{(u,i)} \left| r_{ui} - \hat{r}_{ui} \right|$$

実際の評価値と予測評価値の差の絶対値の平均を取った指標であり、誤差の大きさを直感的に解釈しやすい。

MSE（Mean Squared Error）

$$\mathrm{MSE} = \frac{1}{N} \sum_{(u,i)} \left( r_{ui} - \hat{r}_{ui} \right)^2$$

誤差を二乗して平均を取ることで、大きな誤差をより強く評価する指標である。

RMSE（Root Mean Squared Error）

$$\mathrm{RMSE} = \sqrt{ \frac{1}{N} \sum_{(u,i)} \left( r_{ui} - \hat{r}_{ui} \right)^2 }$$

MSEの平方根を取った指標であり、評価値と同じスケールで誤差を解釈できるため、実務でよく用いられる。

集合の評価指標

集合の評価指標は、推薦システムが出力した予測アイテム集合と、実際にユーザーが好んだ適合アイテム集合との一致度を評価する指標である。推薦結果を「順位」ではなく「集合」として扱う点が特徴である。

ここで、

$P_u$：ユーザー $u$ に対する予測アイテム集合
$G_u$：ユーザー $u$ に対する適合アイテム集合（正解集合）
とする。

Precision（適合率）

$$\mathrm{Precision} = \frac{|P_u \cap G_u|}{|P_u|}$$

推薦したアイテムのうち、どれだけが適合アイテムであったかを表す指標である。

Recall（再現率）

$$\mathrm{Recall} = \frac{|P_u \cap G_u|}{|G_u|}$$

適合アイテムのうち、どれだけを推薦できたかを表す指標である。

F1-measure（F1スコア）

$$\mathrm{F1} = \frac{2 \cdot \mathrm{Precision} \cdot \mathrm{Recall}}{\mathrm{Precision} + \mathrm{Recall}}$$

Precision と Recall の調和平均を取った指標であり、両者のバランスを考慮して評価できる。

実際の推薦システムでは、上位 $k$ 件の推薦結果を対象とすることが多く、Precision@k や Recall@k として評価されることが一般的である。

ランキング評価指標

ランキング評価指標は、推薦されたアイテムの「順位」を考慮して評価を行う指標である。正解アイテムがリストの上位に配置されているほど高く評価される。

PR曲線（Precision-Recall Curve）

PR曲線は、Recall を横軸、Precision を縦軸に取り、閾値や推薦件数 $k$ を変化させたときの精度と再現率の関係を可視化したものである。特に正例が少ない推薦問題において有用である。

MRR@K（Mean Reciprocal Rank）

$$\mathrm{MRR@K} = \frac{1}{|U|} \sum_{u \in U} \frac{1}{\mathrm{rank}_u}$$

ただし、$\mathrm{rank}_u$ はユーザー $u$ に対する最初の適合アイテムの順位（$K$ 位以内に存在しない場合は 0 とする）である。

最初に正解アイテムが現れる順位を重視する指標であり、検索的な推薦タスクでよく用いられる。

AP@K（Average Precision）

$$\mathrm{AP@K} = \frac{1}{|G_u|} \sum_{k=1}^{K} \mathrm{Precision@k} \cdot \mathrm{rel}_k$$

ここで、$\mathrm{rel}_k$ は順位 $k$ のアイテムが適合アイテムであれば 1、そうでなければ 0 とする。

適合アイテムがランキングの上位に来ているほど高く評価される指標である。

MAP@K（Mean Average Precision）

$$\mathrm{MAP@K} = \frac{1}{|U|} \sum_{u \in U} \mathrm{AP@K}_u$$

ユーザーごとの AP@K を平均した指標であり、ランキング全体の性能を評価するために広く用いられる。

nDCG@K（Normalized Discounted Cumulative Gain）

$$\mathrm{DCG@K} = \sum_{k=1}^{K} \frac{2^{\mathrm{rel}_k} - 1}{\log_2(k + 1)}$$

$$\mathrm{nDCG@K} = \frac{\mathrm{DCG@K}}{\mathrm{IDCG@K}}$$

順位が下がるほど評価を割り引く指標であり、適合度が多値（例：★1〜5）の場合にも対応できる。

その他の指標

その他の指標は、Precision や Recall などの精度指標だけでは評価できない、推薦システムの性質やユーザー体験を評価するための指標である。

カバレッジ（Coverage）

$$\mathrm{Coverage} = \frac{|\text{推薦可能なアイテム数}|}{|\text{全アイテム数}|}$$

サービス内の全アイテムのうち、推薦システムが実際に推薦対象として扱えるアイテムの割合を表す指標である。

新規性（Novelty）

新規性は、ユーザーにとってどれだけ「未知」または「馴染みのない」アイテムを推薦できているかを評価する指標である。一般に、人気度の低いアイテムを推薦できているほど新規性は高いとされる。

多様性（Diversity）

多様性は、推薦リスト内のアイテム同士がどれだけ異なっているかを評価する指標である。類似度の低いアイテムを組み合わせて推薦できているほど、多様性が高いとされる。

セレンディピティ（Serendipity）

セレンディピティは、ユーザーの期待を超えた「意外だが好ましい」アイテムを推薦できているかを評価する指標である。単なる新規性や多様性ではなく、ユーザーにとって価値のある驚きがあることを重視する。

7.2.3 評価指標の選定方法

評価指標の選定において重要なのは、オフライン評価の数値そのものを改善することではなく、最終的なビジネス成果やユーザー体験の向上につながる指標を選ぶことである。そのためには、オンライン指標との関係性と、ユーザーの行動意図を踏まえた指標選択が必要となる。

1. KPI（オンライン指標）と相関のあるオフライン指標を選ぶ

オフライン評価指標は、CTRやCVR、滞在時間などのオンラインKPIを直接最適化するものではない。したがって、オフライン指標の改善が、オンライン指標の改善につながるかどうかを確認することが重要である。

例えば、

CTR を重視する場合は、Precision@kやMRR@k
購入・視聴完了などの行動量を重視する場合は、Recall@kやMAP@k
ユーザー満足度や継続利用を重視する場合は、nDCG@kや多様性・新規性指標

といったように、KPI に応じて適切なオフライン指標を選択する必要がある。

2. ユーザーの行動意図に基づく評価指標の選定（Broder の分類）

Broderは、ユーザーの検索行動の意図を以下の3つに分類している。この分類は、推薦システムにおける評価指標の選定にも有用である。

誘導型（Navigational）
特定のアイテムやコンテンツを明確に探している状態である。この場合、ユーザーは目的のアイテムに素早く到達することを重視するため、MRR@kや Precision@1 など、上位順位を強く評価する指標が適している。
情報収集型（Informational）
複数の候補から情報を比較・検討している状態である。この場合、推薦リスト全体の品質が重要となるため、nDCG@kやMAP@kのようなランキング全体を評価できる指標が適している。
取引型（Transactional）
購入や視聴、申込といった具体的な行動を目的としている状態である。この場合、適合アイテムを漏れなく提示することが重要であり、Recall@kやF1@kが有効な指標となる。

評価指標選定における注意点

単一の評価指標に依存せず、複数の指標を併用して総合的に判断することが重要である
オフライン指標はあくまで代理指標であり、最終的な評価は オンライン実験（A/Bテスト） によって行う必要がある
評価指標はサービスの成熟度やフェーズに応じて見直すことが望ましい

7.3 オンライン評価

システムの変更を実際にユーザーに提示して評価する方法である。

7.3.1 A/Bテスト

オンライン検証の代表的な方法で、ランダム化比較実験（RCT）と呼ばれる方法の1つ
変更を加えた結果を見せるTreatmentユーザー群と、変更を加えない結果を見せるControlユーザー群に分けられる

7.3.1.1 仮説

コンテキスト：実験の背景とは何か？
変更点：何をどう変えるのか？
対象：対象ユーザーは誰か
指標目標：変更点が指標にどのような影響を与えるのか
ビジネス目標：施策によって達成したい最終的なビジネスのゴールは何か？

観点	内容
コンテキスト	ユーザーが多数の宿泊施設の中から条件に合う宿を見つけにくく、検索・比較に時間がかかっている
変更点	既存の人気順推薦から、ユーザーの閲覧・予約履歴を考慮した新しい推薦アルゴリズムに変更する
対象	宿泊予約を検討している既存ユーザー（直近◯ヶ月以内に検索履歴のあるユーザー）
指標目標	予約率（CVR）を現行比で +1% 向上させる
ビジネス目標	予約件数の増加により、予約経由の売上を向上させる

進め方

ユーザーの割り当ては乱数によって行い、Control群とTreatment群を作成する
Treatment群はUXを損なうリスクがあるため、最初は少数ユーザーでテストを実施する
ログやエラー、異常な指標変動がないことを確認した上で、段階的に対象ユーザーを拡大する

注意点

群バイアス（片方の群のユーザーが極端にクリック数が多いなど）を避けるために、A/Aテストを実施する
集計期間が短すぎると偶然の影響を受けやすく、長すぎると季節性や曜日バイアスが混入するため注意が必要である
曜日、祝日、季節イベントなどの外部要因による影響を考慮する必要がある
モデル学習データの混合による注意点
- 本来は、Control群・Treatment群それぞれのユーザー行動ログのみを用いて、対応するモデルを学習するのが望ましい
- しかしデータ量不足などの理由から、両群の行動ログを混合して学習せざるを得ない場合がある
- この場合、A/Bテストで「モデルAがモデルBより良い」という結果が得られても、その差がモデル固有の性能差ではなく、学習データ構成の影響である可能性がある
- 特にバンディットアルゴリズムでは、表示回数が多いモデルほど行動ログが集まりやすく、学習がさらに有利に進むという自己強化バイアスが発生しやすい
- その結果、実際には一方のモデルを全ユーザーに適用した方が良いにもかかわらず、A/Bテストの勝敗が誤って判断される可能性がある

7.3.1.2 指標の役割

OEC（Overal Evaluation Criteria）指標

A/Bテストの最終的な成功/失敗を判断する指標
長期的なサービスのKPIと相関し、短期的にはチームが行動を起こすのに十分な感度を持つべき
ユーザーに焦点を当てて設計する（Focus on the user and all else will followの哲学）
ユーザー体験を測定する指標を設計するための観点として以下のHEARTフレームワークが用いられる
- Happiness：ユーザーのサービスに対する感覚
- Engagement：ユーザーのプロダクトへの関与のレベル
- Adoption：ある期間に何人の新規ユーザーが製品を使い始めたか
- Retention：ある期間のユーザーのうち何人が、その後のある期間にまだサービスの利用を継続しているか
- Task success：効率性（タスク完了までの時間など）、有効性（タスク完了率など）、エラー率など

ガードレール指標

劣化させてはいけない制約
- e.g. ページ閲覧数、サービス稼働率、レスポンス速度、アクティブユーザー数など

指標の設計方針

STEDIという5つの特性から考える方法がある

Sensitivity（指標は感度よくあるべき）
- Movement Probability：変更に対して指標がどれだけの頻度で変動するか（良い指標は大きな変動が起きる確率が小さく、安定して計測できる）
- Statistical Power（検出力）：効果の変動がある場合に、それをどれだけ正確に特定できるか。A／Bテストでは80%以上の検出力が求められる
Trustworthiness（高い信頼性があるべき）
- サーバーのトラブルで欠損しずらい
- ログの使用と実装に乖離がない
- 検索エンジンのクローラーなどのBotによるアクセス
- 「興味深かったり、違いが明確なデータは大抵誤りである」と考えるべき
Efficiency（効率の良い意思決定につながるべき）
- 体制が整ってくるとテストの数が数百、数千に及ぶため、時間・複雑性・コストを抑える必要がある
- Netflixは再生時間を1ヶ月継続率の代理変数に使用することにより時間を削減している
- アイトラッキングやアンケートなどの複雑な指標はスケールさせることが難しい
- データを得るコストも重要
Debuggability and Actionability（デバッグにつながる指標も用意する）
- テストに異常があった場合、異常の原因を追跡し、修正することにつながる指標も用意しておくべき
Interpretability and Directionality（解釈が容易であるべき）
- ユーザーの不満を集計したいとき、5段階評価の平均を取るよりも不満であると答えたユーザーの割合を集計する方が解釈が容易
- Directionalityとは、その指標が改善されたときにビジネス目標が達成されるのかを指す

7.3.2 インターリービング

複数のランキング手法を同一ユーザー・同一セッション内で比較評価するための手法
A/B テストのようにユーザーを群分割するのではなく、複数のランキング結果を1つのランキングに混ぜて提示し、その中でのユーザー行動（主にクリック）を用いて、元のランキング手法の優劣を推定する
3つ以上のランキングを混ぜて評価する方法はマルチリービングと呼ばれる

この手法には以下の特徴がある。

同一ユーザーに対して複数手法を評価するため、ユーザー間のばらつきの影響を受けにくい
少ないトラフィックでも差を検出しやすく、評価効率が高い
検索結果や推薦順位など、ランキングの微差を比較する用途に適している

一方で、ランキングの混ぜ方によってはユーザー体験を損なったり、評価が歪む可能性があるため、インターリービング手法の選択が重要となる。

※ 画像出典：
James Rubinstein, "A/B Testing Search: Thinking Like a Scientist"
https://jamesrubinstein.medium.com/a-b-testing-search-thinking-like-a-scientist-1cc34b88392e

代表的なインターリービング手法

Team Draft Interleaving（TDM）

各ランキング手法を「チーム」とみなし、交互にアイテムをドラフト形式で選択してランキングを構成する
クリックされたアイテムを提供した手法にスコアを付与する

特徴

実装が比較的容易
各手法の露出が公平になりやすい
主に2手法比較で広く利用される

Probabilistic Interleaving（PM）

各順位において、確率的にどのランキング手法からアイテムを選択するかを決定する
上位にランクされているアイテムほど選ばれやすい確率設計を行う

特徴

ランキングスコアの情報を自然に反映できる
理論的な忠実性（fidelity）が高い
実装はTDMよりやや複雑

Optimized Interleaving（OM）

ユーザーのクリック行動モデルを仮定し、バイアスを最小化するように最適化されたインターリービング手法
より正確なランキング手法の優劣推定を目指す

特徴

高精度な評価が可能
実装・運用コストが高い
主に研究用途や大規模検索システムで利用される

Probabilistic Pairwise Interleaving（PPM）

PMを拡張し、手法間のペアワイズ比較をより明確に推定する手法
クリック位置や順位バイアスを考慮した設計

特徴

ランキング間の比較精度が高い
実装難易度は比較的高め

インターリービング手法の比較

手法	Considerateness（UX配慮）	Fidelity（評価忠実性）	実装の容易さ
TDM	中	中	高
PM	中	高	中
OM	高	非常に高	低
PPM	中	高	低

Considerateness：ユーザー体験をどれだけ損なわずに評価できるか
Fidelity：真のランキング性能差をどれだけ正確に反映できるか

A/Bテストとインターリービングの比較

観点	A/Bテスト	インターリービング
評価対象	システム全体・UX	ランキング手法の優劣
評価効率	低（多くのトラフィックが必要）	高（少量トラフィックで可能）
実施コスト	高（群分割・長期間）	低〜中
ユーザー分割	必要	不要
UXへの影響	比較的安定	手法によっては影響あり

インターリービングは、ランキング手法の改善を高速に回したい場合の補助的評価手法として有効であり、最終的な意思決定やUX全体の評価にはA/Bテストと併用されることが多い。

7.4 ユーザースタディによる評価

ユーザースタディは、推薦システムがユーザーの主観的な満足度・理解度・信頼感・楽しさなどにどのような影響を与えるかを定性的に評価する方法である。
クリック率や購入率などの定量指標では捉えきれない、「なぜその推薦が良い／悪いと感じたのか」を明らかにできる点が特徴である。

推薦結果の納得感・説明可能性
新規性や意外性に対する印象
サービス全体の使いやすさ・満足度

といった観点の評価に適している。

7.4.1 調査の設計

ユーザースタディでは、調査設計の良し悪しが結果の信頼性に大きく影響するため、以下の点を慎重に検討する必要がある。

参加者の選定

評価結果を妥当に解釈するために、参加者の特性を明確にする。

テスト対象の専門知識レベル
- 一般ユーザーか、ドメイン知識を持つ専門家か
サービスの利用頻度
- 新規ユーザー、ライトユーザー、ヘビーユーザー
ユーザー属性情報
- 年齢、性別、居住地域、職業など（必要に応じて）

これにより、「誰にとって有効な推薦なのか」を明確にできる。

サンプルの抽出方法

参加者の選び方によって、結果の一般化可能性（外的妥当性）が変わる。

単純無作為抽出法
- 母集団からランダムに抽出
- バイアスが少ないが、実施コストが高い
系統的抽出法
- 一定間隔で抽出（例：10人に1人）
層化抽出法
- 年齢層や利用頻度などで層を分け、各層から抽出
- 属性ごとの偏りを抑えられる
便宜的抽出法
- 協力が得やすい参加者を対象
- 実務では多いが、バイアスに注意が必要

参加者の数

調査の目的
許容できる誤差やばらつき
定性的分析か、統計的検定を行うか

によって決定する。

一般に、

インタビューや自由回答中心：少人数（5〜20人程度）
アンケート中心：数十〜数百人

が目安となる。

調査のタイミング

新機能や推薦ロジックの大幅変更時
定期的なUX確認

として実施する。

成熟したサービスであっても、少なくとも年1回程度のユーザースタディを行い、ユーザー認知の変化を把握することが望ましい。

被験者内測定 / 被験者間測定

評価方法として、以下の2つがある。

被験者内測定（Within-subjects design）
- 同一参加者が複数の推薦手法を体験して比較
- 個人差の影響が小さく、少人数でも差を検出しやすい
- 学習効果・順序効果に注意が必要
被験者間測定（Between-subjects design）
- 参加者を分けて、それぞれ異なる推薦手法を評価
- 実運用に近いUXを評価できる
- 個人差の影響を受けやすく、参加者数が多く必要

調査目的や制約に応じて、適切な設計を選択することが重要である。

ユーザースタディは、オフライン評価・オンライン評価を補完し、推薦システムの「人にとっての価値」を検証する重要な手法である。

7.5 この章のまとめ

章全体の要点

3つの評価アプローチ: 推薦システムの評価には、オフライン評価（過去ログによるシミュレーション）、オンライン評価（A/Bテスト等の実戦投入）、ユーザースタディ（定性調査）があり、それぞれコスト・正確性・定性面のトレードオフが存在する
オフライン評価指標の多様性:
- 予測誤差指標（MAE, RMSE）：評価値の予測精度を測る
- 集合指標（Precision, Recall）：適合アイテムを含んでいるかを測る
- ランキング指標（MAP, nDCG）：正解が上位に来ているかを重視する
- その他の指標（Diversity, Serendipity）：精度以外の「体験の質」を測る
指標選定の重要性: オフライン指標はあくまで代理変数。ビジネスKPI（CTR, CVR等）と相関があるものや、ユーザーの検索意図（誘導型・情報収集型・取引型）に合致した指標（MRR vs Recallなど）を選ぶ必要がある
オンライン評価（A/Bテスト）の設計: ランダム化比較実験が基本だが、OEC（総合評価指標）とガードレール指標（制約条件）を明確に定義し、STEDI（感度・信頼性・効率性など）の観点で指標設計を行うことが成功の鍵
インターリービング: A/Bテストよりも少ないトラフィックで、複数のランキングアルゴリズムの優劣を高速に判定する手法
定性評価の価値: 数値では測れない「納得感」や「意外性」を評価するためには、適切なサンプリング設計に基づいたユーザースタディが不可欠

実務・読後に活かせるポイント

リークへの厳重な注意: オフライン評価では、時系列を無視した分割による未来情報のリーク（本来知り得ないデータを使った学習）が致命的。必ず時系列に沿った分割を行う。
目的に応じた指標の使い分け:
- ユーザーが「特定の商品」を探しているなら MRR や Precision@1 を重視
- 「何か良いもの」を探しているなら nDCG や Diversity を重視
- 購買漏れを防ぎたいなら Recall を重視
- これらを単一で追わず、複数の指標で多角的にモニタリングするのが定石
A/Bテストの落とし穴回避:
- フィードバックループ: 過去のA/Bテストで勝利したモデルのログばかりが蓄積され、学習データが偏ることで、真の性能差が見えなくなる現象に注意が必要
- A/Aテストの実施: 群バイアスがないかを確認するため、変更を加えないテストを挟むのが安全
インターリービングの活用: 検索順位やリランキングロジックの微調整など、「どちらが上位にあるべきか」を競わせる場合は、A/Bテストよりもインターリービングの方が効率的に勝敗を決せられます。
「なぜ」を問う: 数字（KPI）が改善してもユーザー体験が悪化している可能性があります（例：クリックは増えたが、釣りタイトルで不満が増加）。定期的なユーザースタディで定性的な健全性をチェックするようにする

第8章発展的なトピック

8.1 バイアス

セレクションバイアス（Selection Bias）
- 概要：
  観測されるデータが、ユーザーが実際に選択・閲覧した一部のアイテムに偏っており、未表示・未選択のアイテムに関する情報が欠落している状態。
- 対策：
  - ランダム表示や探索（exploration）を一部に取り入れる
  - 未観測データを考慮した学習手法（Implicit Feedback, IPS など）を用いる
同調バイアス（Conformity Bias）
- 概要：
  他者の評価（レビュー数、いいね数、ランキング表示）に影響され、ユーザーが自分の嗜好とは異なる行動を取ってしまう現象。
- 対策：
  - 社会的シグナル（人気度、評価数）の表示を制御する
  - 個人嗜好に基づく推薦を強調するUI設計
表示バイアス（Exposure Bias）
- 概要：
  システムによって表示されたアイテムのみが評価・クリックされるため、表示されなかったアイテムが学習に使われない偏り。
- 対策：
  - ランダムサンプリングや多様性制約を導入
  - 表示確率を考慮した学習（重み付け）
ポジションバイアス（Position Bias）
- 概要：
  ランキングの上位に表示されたアイテムほどクリックされやすく、実際の嗜好以上に高く評価されてしまう偏り。
- 対策：
  - インターリービングやシャッフルによる評価
  - クリックモデルを用いた順位補正
人気バイアス（Popularity Bias）
- 概要：
  人気のあるアイテムがさらに推薦されやすくなり、ロングテールのアイテムが露出されにくくなる現象。
- 対策：
  - 多様性・新規性制約を導入
  - 人気度に対する正則化や重み調整
不公平性（Unfairness / Bias against groups）
- 概要：
  特定のユーザー属性やアイテム属性が不利・有利になるような推薦結果が生じる問題。
- 対策：
  - 公平性指標の導入（Exposure Fairness など）
  - 属性制約やフェアネス正則化を組み込んだ学習
帰納バイアス（Inductive Bias）
- 概要：
  モデル設計や仮定（線形性、独立性など）により、学習結果が特定のパターンに偏ること。
- 対策：
  - 問題に適したモデル選択
  - 複数モデルの比較・アンサンブル
フィードバックループ（Feedback Loop）
- 概要：
  推薦結果がユーザー行動を変え、その行動ログで再学習することで、偏りが自己強化される現象。
- 対策：
  - 探索と活用のバランス（バンディット手法）
  - ログの分離、オフポリシー評価の導入

8.2 相互推薦システム

相互推薦システム（Reciprocal Recommendation System）とは、推薦を受ける側と推薦される側の双方がユーザーであり、両者の嗜好や条件が同時に満たされることを目的とした推薦システムである。
一般的な「アイテム → ユーザー」の一方向の推薦とは異なり、「ユーザー ↔ ユーザー」のマッチングを最適化する点が特徴である。

代表的な例としては、マッチングアプリ、求人・求職サービス、C2Cマーケットプレイス、スキルマッチングサービスなどが挙げられる。

8.2.1 従来の推薦システムと相互推薦システムの違い

サービス内におけるユーザーの役割

従来の推薦システム
- ユーザーは「推薦を受け取る主体」
- 推薦対象は商品・映画・記事などのアイテム
- ユーザーの満足度のみを最大化する一方向の最適化問題
相互推薦システム
- ユーザーは「推薦を受ける側」と「推薦される側」の両方の役割を持つ
- 両者の合意が成立して初めて価値が生まれる
- 双方向の満足度を考慮した最適化が必要

サービス上でのユーザーのプロフィールや好みについての情報

従来の推薦システム
- ユーザーの嗜好情報は主に「消費行動」（閲覧・購入・評価）から推定
- アイテム側の属性は固定的であることが多い
相互推薦システム
- ユーザーは以下の2種類の情報を持つ
  - 自身の属性・嗜好（年齢、興味、スキル、条件など）
  - 相手に求める条件・好み
- プロフィール情報の重要性が高く、明示的入力データが中心となることが多い
- 条件の非対称性（例：AはBを好むが、BはAを好まない）を考慮する必要がある

性能評価と成功基準

従来の推薦システム
- 成功指標は主に以下のような単方向の指標
  - CTR（クリック率）
  - CVR（購買率）
  - RMSE や Precision@K などのオフライン指標
- ユーザーの行動変化が直接的に評価につながる
相互推薦システム
- 成功は「マッチ成立」によって初めて測定される
- 評価は、好意の送信 → 応答 → マッチ成立という段階的なプロセスとして捉えられる
- 代表的な評価指標
  - 推薦されたユーザーの中に、実際に好意を送ったユーザーの割合（好意送信率）
  - 好意を受けたユーザーが、送り手に好意を返した割合（応答率）
  - 双方の好意が一致し、実際にマッチした割合（マッチ率）
- 短期指標（いいね・スワイプ）と長期指標（継続的関係、満足度）の両立が重要

相互推薦システムは、単なる関連度予測ではなく、利害の異なる二者の満足度を同時に最大化する難しさを持つ。
そのため、推薦アルゴリズムだけでなく、UI設計、制約条件の扱い、公平性の考慮なども含めた総合的な設計が求められる。

8.3 Uplift Modeling

従来の推薦システムは、「推薦した結果として購入されたか」を最大化するように設計されてきた。
しかし、水や日用品のように推薦しなくても購入される商品に対しては、推薦による効果（因果効果）が小さく、推薦の意味が薄い。

そこで、「推薦によってどれだけ行動が変化したか」という**因果効果（Uplift）**に注目するUplift Modelingの考え方が導入される。

購入パターンの4分類（Upliftの基本概念）

Upliftの枠組みでは、推薦（介入）の有無と購入結果の組み合わせにより、ユーザーは以下の4パターンに分類される。

TU（True Uplift）
- 推薦した場合にのみ購入するユーザー
- 推薦によって購入が促進された理想的なユーザー
FU（False Uplift）
- 推薦しなくても購入するユーザー
- 推薦してもしなくても結果が変わらず、推薦の価値が低い
TD（True Downgrade）
- 推薦しなければ購入したが、推薦すると購入しないユーザー
- 推薦によって逆効果が生じたユーザー
FD（False Downgrade）
- 推薦してもしなくても購入しないユーザー
- 推薦の影響を受けないユーザー

Uplift Modeling の目的は、TUの割合を最大化することである。

Uplift Score の考え方

Uplift Scoreは、推薦（介入）を行った場合と行わなかった場合の購入確率の差として定義される。

推薦ありの購入確率 − 推薦なしの購入確率

ただし、実際には同一ユーザーに対して「推薦した場合」と「推薦しなかった場合」を同時に観測できないため、単純な平均との差は 真の平均確率から乖離する可能性がある。

傾向スコアによる補正

この問題への対策として、**傾向スコア（propensity score）**を用いた補正が行われる。

傾向スコア：あるユーザーが推薦を受ける確率
推薦されやすいユーザーとされにくいユーザーの偏りを補正し、観測データから因果効果を推定する

これにより、Uplift Scoreのバイアスを抑えた評価が可能となる。

観測可能データへの分解

TU / FU / TD / FD は理論上の分類であり、直接観測することはできない。
そのため、実際には以下の2軸によってデータを分解する。

推薦を行ったか（R / NR）
購入が起きたか（P / NP）

これにより、観測可能なデータは次の4クラスに分類される。

R-P
- 推薦あり・購入あり
R-NP
- 推薦あり・購入なし
NR-P
- 推薦なし・購入あり
NR-NP
- 推薦なし・購入なし

これらの観測データをもとに、TU が多く含まれるユーザーを推定する。

学習時の注意点

NR-NP（非推薦・非購入） のデータは他のクラスに比べて圧倒的に多くなりやすい
そのまま学習に用いるとクラス不均衡が発生するため、
- サンプリング確率を下げる
- 重み付けを行う
  といった工夫が必要となる

Uplift Modeling は、「誰に推薦すべきか」を購入確率ではなく因果効果の観点から最適化する点に特徴がある。

8.4 ドメインに応じた特徴と課題

楽曲推薦

エンドレス再生
- 1回の推薦結果が次の推薦に影響し、連続的な満足度の最適化が求められる
カタログの問題
- 楽曲数が膨大で、ロングテールの扱いが重要
ユーザーの好みの反映
- 気分や時間帯によって嗜好が変化しやすい
繰り返される消費
- 同じ楽曲が何度も消費されるため、新規性とのバランスが必要
ニッチな楽曲の需要
- 少数ユーザー向け楽曲でも高い満足度を生む可能性がある
コンテキスト依存性
- 作業中、運動中など利用シーンが推薦に強く影響する
社会的な影響
- トレンドや他者の視聴・再生が嗜好形成に影響を与える

ファッション推薦

インフルエンサー経由の購入
- SNSや著名人の着用情報が購買行動に大きく影響する
類似商品の購入
- 色・形・素材などの類似性が重要な推薦軸となる
サイズやフィット感の考慮
- 見た目だけでなく、個人差の大きい身体特性を考慮する必要がある

ニュース推薦

コールドスタート問題
- 新記事が常に追加され、履歴が存在しない状態での推薦が頻発する
適時性
- 情報の鮮度が極めて重要
構造化されていない文書
- テキストデータの理解・要約が必要
重複排除
- 内容が似通った記事を過剰に表示しない工夫が必要
フェイクニュースやクリックベイト
- 品質や信頼性を考慮した推薦が求められる

動画推薦

グループ視聴
- 複数人の嗜好が混在する視聴シーンが存在する
説明の重要性
- なぜ推薦されたかの説明が満足度に影響する
パーソナライズ
- サムネイル画像：同じ動画でもユーザーごとに異なる表現が有効
- 検索：検索意図と推薦の組み合わせが重要

食の推薦

暮らしの背景の影響
- 家族構成、生活リズム、健康意識などが強く影響する
事前の準備
- 食材の有無や調理時間など、実行コストを考慮する必要がある
画像活用の難しさ
- 見た目と実際の満足度の乖離が生じやすい

仕事の推薦

相互推薦システム
- 企業と求職者の双方の合意が必要
公平性
- 属性バイアスや差別につながらない配慮が不可欠
ユーザーの嗜好データの獲得
- 明示的な希望条件が少なく、暗黙的データの活用が重要

8.5 この章のまとめ

章全体の要点

バイアスとの戦い: 推薦システムの学習データは、ユーザーが「選択した」結果のみに偏るセレクションバイアスや、上位表示されたものをクリックしやすいポジションバイアス、人気商品ばかりが推薦される人気バイアスなど、多くの歪みを含んでいる。これらを放置すると、システムは偏りを強化するフィードバックループに陥る
相互推薦（Reciprocal Recommendation）の特殊性: マッチングアプリや求人サービスのように、「推薦する側」と「される側」の双方がユーザーである場合、単方向の「好き」ではなく、双方向のマッチング成立を目的関数とする必要がある。ここでは明示的なプロフィール条件や「好意の返報性」が重要になる。
Uplift Modeling（因果推論）:「推薦しなくても買う人」への無駄な介入や、「推薦すると逆に買わなくなる人」への悪影響を防ぐため、純粋に推薦によって行動が変わる層（True Uplift）を特定し、介入効果（因果効果）を最大化する手法。
ドメイン固有の課題: 推薦システムは万能ではなく、ドメインごとに重視すべき制約が異なる。
- 音楽: 繰り返し視聴（Re-consumption）やコンテキスト（作業中など）の考慮
- ニュース: 新鮮さ（Freshness）とコールドスタート対応
- ファッション: サイズ適合やインフルエンサーの影響

実務・読後に活かせるポイント

ログデータの「汚れ」を疑う: 蓄積されたログは「ユーザーの純粋な嗜好」ではなく、「過去のアルゴリズムによって歪められた結果」であることを前提にモデルを設計します。ランダム表示枠を設けて探索（Exploration）を行ったり、**IPS（Inverse Propensity Scoring）**などの手法でバイアスを除去することが推奨される
KPIの再定義（相互推薦）: C2Cやマッチングサービスを開発する場合、単なるCTR/CVRではなく、「好意送信率」「応答率」「マッチング率」といったファネル全体の指標を設計し、双方向の満足度を計測する必要がある。
マーケティングコストの最適化（Uplift）: クーポン配布やプッシュ通知など、コストやユーザーの嫌悪感を伴う施策では、Uplift Modelingを導入して「説得可能なユーザー（True Uplift）」のみにターゲットを絞ることで、ROIを劇的に改善できる
「納得感」の演出: 動画やニュースなどの領域では、単に当てるだけでなく「なぜ推薦されたか（Because you watched...）」の説明や、サムネイルのパーソナライズがユーザーのクリック率に大きく寄与する
公平性（Fairness）への配慮: 求人や金融などのセンシティブな領域では、特定の属性が不利にならないよう、アルゴリズムレベルで公平性制約を組み込むことが、コンプライアンスおよび社会的信用の観点から必須となる