協調フィルタリングとは｜レコメンド導入前に確認する精度とデータ量

ベンダーから届いた提案書に「協調フィルタリングによる高精度なパーソナライズを実現します」と書かれていて、上司から「それは本当にうちのデータで効くのか」と聞かれたとき、即答できるでしょうか。SaaS のレコメンドツールの資料にも、受託開発の提案書にも、同じ「協調フィルタリング」という言葉が並んでいます。しかし、そこに書かれた方式が自社のデータ量で成立するのか、提示された「高精度」が何をもって高精度なのかは、資料を読むだけでは判断できません。

この判断が難しいのは、担当者の知識が足りないからではありません。協調フィルタリングは「蓄積された行動データの量と形」に性能が強く依存する仕組みであり、同じアルゴリズムでもサイトによって機能する／しないが分かれます。にもかかわらず、提案書に書かれるのはアルゴリズムの名前だけで、「どれだけのデータが前提なのか」「精度をどう測ったのか」は省略されがちです。結果として、導入後に「おすすめが出てこない」「売れ筋が並ぶだけ」という状態になっても、不具合なのか仕様なのか切り分けられません。

この状況を抜け出すために必要なのは、アルゴリズムを数式で理解することではありません。必要なのは、(1) 仕組みを社内に説明できる言葉で押さえ、(2) 自社のデータで成立するかを粗く判定する観点を持ち、(3) 精度の語られ方を見抜く質問をベンダーに投げられることです。この 3 つが揃えば、設計をベンダー任せにせず、稟議でも根拠を示して説明できます。

本記事では、協調フィルタリングの仕組みと 3 つの型、コンテンツベースフィルタリングとの違いを整理した上で、必要なデータ量を判定する 4 つの観点、推薦精度がブラックボックス化する構造的な理由、そして発注前にベンダーへ確認したい 6 つの質問を解説します。読み終えたあとに、自社のデータを棚卸しして打ち合わせの論点を自分から出せる状態になることを目指します。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

協調フィルタリングとは｜「似た人の行動」から推薦を導く仕組み

協調フィルタリングとは、ユーザーの行動履歴や評価データをもとに「似た嗜好を持つ人が選んだもの」を推薦する仕組みです。最大の特徴は、推薦するアイテム自体の中身を見ないことにあります。商品がどんな色でどんな素材なのか、動画がどんなジャンルなのかという属性情報を一切使わず、「誰がそれを選んだか」という行動の重なりだけで推薦を導きます。

EC サイトでよく見かける「この商品を買った人はこんな商品も買っています」という枠が、その代表例です。あなたがカメラを買ったとき、同じカメラを買った他の人の多くが三脚も買っていたなら、三脚が推薦されます。システムは三脚がカメラの付属品であることを知っているわけではなく、「同じ人たちが一緒に買った」という事実だけを根拠にしています。

この「中身を見ない」という性質は、長所と短所の両方を生みます。Google の機械学習コースは長所として「ドメイン知識が不要であること」と「セレンディピティ（意外な発見）が生まれること」を挙げています。商品カテゴリの設計やタグ付けをしていなくても推薦が成り立ち、さらに「本人が自覚していなかった興味」に行き当たる可能性があります。一方で短所として挙げられているのは、学習時に行動データのなかったアイテムには推薦の手がかりが作れないという点です。つまり協調フィルタリングは、原理的に「行動データの蓄積」を前提とした仕組みです。この前提が、後ほど解説するデータ量の議論に直結します。

レコメンドAIの仕組みの中で協調フィルタリングが担う役割

レコメンド AI の仕組みは、協調フィルタリング一本で成り立っているわけではありません。実際のサイトでは、次のような方式が枠ごとに使い分けられています。

提案書に「レコメンド機能を実装します」と書かれているとき、その中身がどの方式なのかで、必要なデータも検証方法もまったく変わります。人気順なら集計さえできれば動きますが、協調フィルタリングは個々のユーザーの行動が紐づいたデータがないと動きません。まず確認すべきは、「提案されている枠のうち、どこが協調フィルタリングで、どこが人気順やルールベースなのか」という切り分けです。

実務では複数方式を組み合わせた構成が一般的です。そのため「協調フィルタリングを使います」という一文だけでは、サイト全体のおすすめ枠の何割がそれで動くのかが分かりません。この粒度の確認は、後述する発注前の質問リストの出発点になります。

明示的評価と暗黙的評価｜自社の行動ログが推薦データになる仕組み

協調フィルタリングが学習に使うデータは、大きく 2 種類に分かれます。Wikipedia の協調フィルタリングの項目でも整理されているとおり、ユーザーが自分の意思で入力する「明示的評価」と、行動の副産物として記録される「暗黙的評価」です。

• 明示的評価（explicit feedback）: 星 5 段階のレビュー、いいね、お気に入り登録など。ユーザーが意図して好みを表明したデータ
• 暗黙的評価（implicit feedback）: 商品ページの閲覧、カートへの投入、購買、動画の視聴時間など。行動ログとして自動的に溜まるデータ

多くの EC サイトで量が確保しやすいのは後者です。レビューや評価がどれだけ投稿されるかはサイトや商材によって大きく異なるため、レビューだけで推薦を組めるかは自社の実数を見ないと判断できません。一方、閲覧や購買のログは、計測が入っていればサイトを運営しているだけで蓄積されていきます。そのため「自社が持っている推薦データ」を棚卸しするときは、まず暗黙的評価のログから数えるのが現実的です。

ただし暗黙的評価には扱いの難しさがあります。星 1 のレビューは「嫌い」という明確な情報ですが、商品ページを見なかったという事実は「嫌い」なのか「存在を知らなかった」のかを区別できません。閲覧したが買わなかった行動も、興味はあったが価格が合わなかったのか、見て失望したのか判別がつきません。この曖昧さをどう重み付けするか（購買を閲覧の何倍の信号として扱うかなど）は設計上の判断であり、ベンダーによって方針が異なります。「どの行動を、どの重みで学習に使うのか」を聞いておくと、提案の解像度が見えます。

協調フィルタリングの種類｜ユーザーベース・アイテムベース・モデルベースの違い

協調フィルタリングは一括りに語られがちですが、実際には複数の型があります。違いを整理する軸はひとつで、「何と何の類似度を計算しているか」です。人と人を比べるのか、商品と商品を比べるのか、それとも両方を同じ座標上に置くのか。この違いによって、向くサイトの条件と運用上の性質が変わります。

ユーザーベース協調フィルタリング｜嗜好が近い人の選択を借りる方式

ユーザーベース協調フィルタリングは、ユーザー同士の行動の重なりから「似た人」を探し、その人が選んでいて本人が未接触のアイテムを推薦する方式です。「あなたと購買傾向が近い人が、これも買っています」という推薦がこれに当たります。

手順は 3 段階です。まず対象ユーザーと他の全ユーザーの類似度を計算し、次に類似度の高いユーザーを一定数選んで近傍とし、最後にその近傍が高く評価しているアイテムを集計してランキングにします。近傍として何人を採用するかは設計上のパラメータで、サイトの規模やデータの密度に応じて調整されます。この流れは DATA ANALYTICS LAB の解説記事でも、類似度計算・予測計算・ランキングの手順として整理されています。

この方式の性質として押さえておきたいのは、ユーザーが増えるほど計算対象が増えることです。ユーザー数がアイテム数より圧倒的に多いサイトでは、類似度の計算量が膨らみ、かつ新規ユーザーが入るたびに計算をやり直す必要があります。Livesense の社内勉強会資料では、ユーザーベースは初回訪問者に推薦を出せないこと、そしてユーザー数がアイテム数より多い構造のため精度に必要なデータが集まるまで時間がかかることが指摘されています。会員制で来訪頻度が高く、1 人あたりの行動件数が多いサービスには向きますが、新規訪問者の比率が高い EC サイトでは単独運用は難しい方式です。

アイテムベース協調フィルタリング｜一緒に選ばれた商品を結ぶ方式

アイテムベース協調フィルタリングは、計算の対象を人からアイテムに置き換えた方式です。「この商品を買った人の集合」と「あの商品を買った人の集合」がどれだけ重なるかを見て、商品同士の類似度を事前に計算しておきます。そして、ユーザーが今見ている商品や過去に買った商品に似た商品を推薦します。

EC の「この商品を買った人はこんな商品も買っています」という枠は、この方式の代表的な応用です。gihyo.jp の情報推薦システム入門でも、Amazon の同枠が協調フィルタリングの応用であり、アイテムベース協調フィルタリングを利用していると説明されています。

運用面での性質としては、商品同士の類似度は商品やその購買傾向が大きく動かない限り変わりにくいため、夜間バッチなどで事前に計算しておき、推薦時は計算済みの表を引くだけで済ませられます。応答が軽く、履歴のない訪問者でも「今見ている商品」が分かれば推薦を返せるため、実装のハードルが比較的低い方式です。なお同じ gihyo.jp の解説は、ユーザー × アイテムの行列が疎かつ巨大になると推薦精度が落ちたり計算量が増えて推薦速度が落ちたりすると指摘しています。事前計算によって応答を軽くできるとしても、元になる行列の疎密の影響そのものは避けられません。

ただし弱点もあります。Livesense の社内勉強会資料では、アイテムベースは人気アイテムや長期間掲載されているアイテムに推薦が偏る傾向が指摘されています。多くの人が買った商品はどの商品との共起も多くなるため、類似度の上位に居座りやすくなります。この偏りが、後述する「人気バイアス」の問題につながります。

モデルベース（行列分解）｜潜在的な嗜好軸を推定する方式

モデルベース協調フィルタリングは、ユーザー × アイテムの行動データ全体から統計モデルを学習し、未知の組み合わせの好みを推定する方式です。代表的な手法が行列分解（matrix factorization）で、前掲の Google の機械学習コースでも埋め込み（embedding）と行列分解を軸に解説されています。

直感的な説明をすると、こうなります。ユーザーとアイテムをそれぞれ数十次元の座標に配置し、「よく一緒に現れるユーザーとアイテムが近くに来る」ように座標を調整していきます。学習が終わると、座標軸のそれぞれが「カジュアル寄りかフォーマル寄りか」「価格重視か品質重視か」といった潜在的な嗜好の軸に相当するものになります。実際の軸に人間が解釈できる名前が付くわけではありませんが、この圧縮によって「直接の共起がないユーザーとアイテムの組み合わせ」にも推薦スコアを付けられるようになります。

モデルベースの利点は、データがまばらでも近傍法より推薦を出しやすいこと、そしてスコアの計算が軽いことです。一方の難点は、推薦理由の説明がしにくいこと、学習（再学習）にそれなりの計算資源と時間が必要なこと、そしてハイパーパラメータの調整次第で精度が変わることです。「なぜこれが推薦されたのか」を運用側が説明できる必要がある場合は、この点を事前に確認しておく価値があります。

3方式の向き不向き比較表

3 つの型を、発注検討の観点で並べると次のようになります。

この表で重要なのは、優劣ではなく条件適合です。自社のユーザー数とアイテム数の比率、商品の入れ替わり頻度、新規訪問者の比率によって、適性が変わります。提案書に「協調フィルタリング」と書かれていたら、まずどの型を前提にしているのかを確認してください。型が明示されていない提案は、この適合性の検討が行われていない可能性があります。

協調フィルタリングとコンテンツベースフィルタリングの違い

レコメンドの方式を比較する際、協調フィルタリングと必ず並べて語られるのがコンテンツベースフィルタリングです。両者の違いは一点に集約されます。推薦の判断材料として「人の行動」を見るか、「アイテムの属性」を見るかです。

判断材料の違い｜行動履歴を見るか、商品の属性を見るか

コンテンツベースフィルタリングは、アイテムの属性情報（カテゴリ、ブランド、価格帯、素材、説明文のキーワードなど）を特徴量として、ユーザーが過去に接触したアイテムと似た属性のアイテムを推薦します。「同じブランドの商品」「同じカテゴリの近い価格帯の商品」という枠がこれに当たります。

この表を自社に当てはめると、判断の方向が見えてきます。商品点数が多く入れ替わりが速いサイト（アパレルのシーズン商品、書籍・雑貨など）では、新商品が常に「行動データのない状態」で登場するため、協調フィルタリング単独では新商品が推薦に出てきません。逆に、商品マスタの属性が整備されておらず、カテゴリ分類も粗いサイトでは、コンテンツベースは思ったほど機能しません。

問うべきは「どちらが優れているか」ではなく、「自社はどちらが成立しやすい状態にあるか」です。行動ログが溜まっている一方で商品属性の整備が追いついていないなら協調フィルタリング寄り、商品マスタは整っているが行動ログが少ないならコンテンツベース寄り、という見立てになります。

ハイブリッド方式｜弱点を補い合う組み合わせの考え方

実務で採用されることが多いのは、両者を組み合わせたハイブリッド方式です。協調フィルタリングは「行動が溜まってから強い」、コンテンツベースは「最初から出せるが幅が狭い」という性質を持つため、時間軸と対象で役割を分けると弱点を補えます。

よく取られる設計は次のようなものです。

• 新規ユーザー: 初回訪問時はコンテンツベースや人気順で推薦を出し、行動が一定件数溜まった段階で協調フィルタリングへ切り替える
• 新商品: 属性情報をもとにコンテンツベースで露出させ、行動データが付いた段階で協調フィルタリングの対象に入れる
• 枠ごとの使い分け: 「関連商品」枠はコンテンツベース、「あなたへのおすすめ」枠は協調フィルタリング、と枠単位で方式を固定する

ハイブリッドを前提にすると、確認すべき論点が「どちらの方式か」から「切り替えの条件は何か」に変わります。何件の行動が溜まったら協調フィルタリングに切り替わるのか、新商品はどのくらいの期間コンテンツベースで扱われるのか。この閾値の設計が、導入直後の体験の良し悪しを決めます。

協調フィルタリングに必要なデータ量の目安｜発注前に見誤りやすい前提

ここからが、発注検討で最もつまずきやすい部分です。「データが多ければ精度が上がる」という理解は正しいのですが、そのままでは自社に当てはめた判断ができません。必要なのは、自社のデータを 4 つの観点に分解して見ることです。(a) 行動の種類、(b) 総インタラクション件数、(c) 1 ユーザーあたり／1 アイテムあたりの平均行動件数、(d) データの疎密（スパース性）。順に見ていきます。

必要なデータの種類｜購買だけでなく閲覧・カート投入が効く理由

まず確認すべきは、学習に使える行動の種類です。購買データしか取れていないサイトと、閲覧・カート投入・購買の 3 層が取れているサイトでは、学習に使えるデータ量が大きく変わります。

商品ページの閲覧件数と購買件数の比率はサイトや商材によって大きく異なりますが、閲覧のほうが多くなるのが通常です。購買だけを学習データにすると、1 ユーザーあたりの行動件数は購買回数そのものになるため、リピート購入が少ない商材では 1 人あたり数件にとどまることもあります。これでは「似たユーザー」を特定する手がかりが足りません。閲覧やカート投入を含めれば、同じトラフィックからより多くのインタラクションを取り出せます。実際の比率は自社の数値で確認してください。

前掲の DATA ANALYTICS LAB の解説記事も、協調フィルタリングに必要なデータの条件として「種類」「詳細さ」「量」の 3 点を挙げています。発注前に自社で確認すべきは、次の点です。

• 商品ページの閲覧ログが、ユーザー ID（または安定した識別子）に紐づいて記録されているか
• カート投入・お気に入り登録・検索などの中間行動が取得できているか
• ログイン前の行動とログイン後の行動が、同一ユーザーとして突合できるか
• ログの保持期間はどれだけか（学習に使える期間が 1 ヶ月分しかない、というケースもあります）

このうち「ログイン前後の突合」は見落としやすい論点です。突合できていないと、同じ人の行動が別人として記録され、1 ユーザーあたりの行動件数が実態より小さく見積もられます。

量より疎密が効く｜スパース性が推薦精度を決める仕組み

総件数だけを見ると判断を誤ります。協調フィルタリングが扱うのは「ユーザー × アイテム」の表であり、重要なのはその表のうちどれだけのマスが埋まっているか（密度）です。これをスパース性（まばらさ）と呼びます。

以下は説明用の仮想例です（実在するサイトの数値ではありません）。次の 3 つのケースは、いずれも行動件数が 10 万件ですが、推薦の成立しやすさは大きく異なります。

ケース A は、1 アイテムあたりの行動がわずか 10 件です。これでは「このアイテムを選んだ人の集合」が小さすぎて、他のアイテムとの共起を安定して計算できません。ケース B はカタログを絞ることで密度が 10 倍になり、ケース C は閲覧を含めることで同じ効果を得ています。

実務上、この表から読み取れる示唆は 2 つあります。ひとつは、商品点数が多いことは協調フィルタリングにとって不利な条件になりうること。もうひとつは、取得する行動の種類を増やすことが、ユーザー数を増やすより早く密度を改善する手段になりうることです。カタログ全体を推薦対象にするのではなく、まず行動が集中している上位カテゴリに限定して導入する、という設計も検討に値します。

なお、具体的な最低ラインの目安としては、商用サービスの要件が参考になります。AWS の Amazon Personalize のドキュメントでは、学習の最低要件として「1,000 件以上のインタラクションデータ」と「2 件以上のインタラクションを持つユニークユーザー 25 人以上」が示されています。さらに同ドキュメントは品質確保のための推奨値として「2 件以上のインタラクションを持つユーザー 1,000 人以上から、合計 50,000 件以上のインタラクション」を挙げています。この「最低要件」と「推奨値」の間に 50 倍の開きがあることが、データ量を語るときの難しさを端的に示しています。動くための最低ラインと、実用的な精度が出るラインは別物です。

これらは特定サービスの要件であり、あらゆる実装に当てはまる普遍的な基準ではありません。ただし、自社の数値がこの推奨値からどの程度離れているかを把握しておくと、ベンダーの説明を評価する足場になります。

自社データを4観点で棚卸しする手順

ここまでの内容を、手を動かせる形に落とします。ベンダーとの打ち合わせ前に、次の 4 つの数値を出してみてください。GA4 や自社 DB から集計できる範囲で構いません。期間は、学習に使える想定期間（直近 3〜12 ヶ月など）に揃えます。

1. 行動の種類の棚卸し: 購買／カート投入／閲覧／お気に入りのうち、ユーザー識別子に紐づいて記録されているものを列挙する。あわせてログの保持期間を確認する
2. 総インタラクション件数: 対象期間の「ユーザー ID × アイテム ID」のユニークな組み合わせ数を数える。同一ユーザーが同じ商品を何度も見た場合は 1 件として数えると、密度の見積もりに近くなります
3. 1 ユーザーあたり／1 アイテムあたりの平均件数: 総インタラクション件数をユーザー数・アイテム数でそれぞれ割る。あわせて「2 件以上の行動があるユーザーの人数と比率」も出す（前節の最低要件がこの指標で定義されているため）
4. 密度の計算: 総インタラクション件数 ÷（ユーザー数 × アイテム数）を計算する。パーセント表記にして、前節の表と比べる

この 4 つが揃えば、「当社は 1 ユーザーあたり平均 2.3 件、2 件以上の行動があるユーザーは 1,800 人、密度は 0.04% です。この条件で成立する設計を提案してください」という形でベンダーに投げられます。数値を添えた問いは、一般論の回答を防ぎます。

棚卸しの結果、「そもそもログが取れていない」「ユーザー識別子が分断されている」と判明することもあります。その場合はレコメンドの検討より前に、データ収集の設計が課題になります。進め方の整理にはAI導入前のデータ整備が参考になります。

構造上避けられないコールドスタート問題

4 観点の棚卸しを済ませても、協調フィルタリングには構造上どうしても残る問題があります。行動データのないユーザーとアイテムには推薦の手がかりが作れないという問題で、コールドスタート問題と呼ばれます。

これは実装の不備ではなく、「誰がそれを選んだか」だけを根拠にする仕組みの必然的な帰結です。前掲の Google の機械学習コースも、学習時に観測されなかったアイテムには埋め込みを作れないことを協調フィルタリングの短所として明記しています。具体的には、次の 3 つの場面で現れます。

• 新規ユーザー: 初回訪問者には履歴がないため、「似た人」を特定できない
• 新商品: 入荷直後の商品は誰にも選ばれていないため、推薦に出てこない
• サービス立ち上げ期: サイト全体の行動データが少なく、どの推薦も安定しない

導入直後に「おすすめが出ない」「同じ商品ばかり出る」という状態になるのは、多くの場合この問題が原因です。仕様として理解していれば、新商品はコンテンツベースや特集枠で露出させる、立ち上げ期は人気順を併用する、といった対策を事前に設計に織り込めます。発生の類型と具体的な対策についてはコールドスタート問題で詳しく整理しています。

発注前の確認としては、「新規ユーザーと新商品が出たときに何が表示される設計になっているのか」を聞いておくことが重要です。この問いに即答できないベンダーは、導入初期の体験設計を検討していない可能性があります。

協調フィルタリングのデメリットと精度がブラックボックス化する理由

データ量の見通しが立ったら、次は精度の話です。提案書の「高精度」という表現が何を意味するのかを評価するには、協調フィルタリングのデメリットと、精度の測り方の構造を知っておく必要があります。

協調フィルタリングの主なデメリット5つ

協調フィルタリングのデメリットは、大きく 5 つに整理できます。

1. コールドスタート問題: 行動データのない新規ユーザー・新商品に推薦を出せない（前述）
2. スパースネス（データのまばらさ）: ユーザー × アイテムの表が埋まらず、類似度が安定しない。アイテム数が多いサイトで顕著になります
3. 人気バイアス: 多くの人が接触した人気商品が推薦の上位を占めやすく、ロングテール商品が埋もれる
4. 計算コスト: ユーザー数・アイテム数の増加に伴い、類似度計算や再学習の負荷が増える。更新頻度とインフラ費用のトレードオフが生じます
5. 推薦理由の説明しにくさ: 特にモデルベースでは「なぜこの商品が出たのか」を人の言葉で説明しにくい。運用側が結果を解釈できず、改善の打ち手が立てられない状態につながります

これらは「できの悪い実装の症状」ではなく、仕組みに内在する性質です。したがって対策は「起きないようにする」ではなく「起きることを前提に設計する」方向になります。発注時には、各項目に対してどう対処する設計なのかを確認する形が有効です。

このうち、発注検討で最も厄介なのが 3 と 5 の組み合わせです。人気バイアスによって「売れ筋を並べているだけ」の状態になっていても、推薦理由が説明されないため、見分けがつかなくなります。

オフライン評価とオンライン評価が乖離する理由

「精度 90%」「従来比で精度が大幅に向上」という説明を受けたとき、何を確認すればよいのか。出発点は、レコメンドの精度評価に 2 つの別物があると知ることです。

オフライン評価は、過去の行動ログを学習用と検証用に分割し、「隠した行動を当てられたか」を測る方法です。Recall@K（上位 K 件の推薦に正解が含まれた割合）、Precision@K、nDCG（順位を考慮した指標）などが使われます。実サイトに出さずに評価できるため、開発中の手法比較に使われます。

オンライン評価は、実際にユーザーに推薦を出し、A/B テストなどで事業指標を比べる方法です。推薦枠のクリック率（CTR）、推薦経由の購買率（CVR）、客単価、回遊率などが対象になります。

問題は、この 2 つがしばしば一致しないことです。RecSys 2018 の REVEAL ワークショップで発表されたComparing Offline and Online Evaluation Results of Recommen…（Rehorek ら、2018 年）は、2 つのオフライン評価手法を実際のサービスで検証し、広く使われている妥当に見える手法の結果がバイアスを含み、オンライン評価とは逆の方向を示す場合があったと報告しています。同論文は、オンライン結果と相関する新たなオフライン評価手法として Jaccard 係数に基づく指標を提案しており、オフラインとオンラインの対応づけ自体が研究対象になっている状況が読み取れます。推薦システムの評価手法の全体像は、サーベイ論文「Recommender Systems: A Primer」（Castells & Jannach、2023 年）が評価方法と近年の論点（推薦システムにおけるバイアス、実務での影響と価値）を含めて整理しています。

なぜ乖離するのか。理由は構造的です。オフライン評価は「過去に実際に起きた行動」を正解とみなしますが、過去の行動は当時のサイト上の露出（どの商品が目立つ位置にあったか）に強く影響されています。目立つ場所にあった商品を当てるのが上手いモデルは、オフラインでは高得点を取ります。しかしそれは「ユーザーが放っておいても買った商品」を当てているだけで、推薦枠を置いたことによる上乗せ効果とは別物です。また、推薦枠が実際にどう見られ、クリックされるかというユーザー体験の要素は、過去ログからは測れません。

さらに、オフライン評価の比較対象の選び方にも問題が生じやすいことが知られています。RecSys 2019 で発表されたDacrema らの検証研究は、主要国際会議で発表された 18 の推薦アルゴリズムのうち再現できた 7 つについて、その 6 つが近傍法やグラフベースの比較的単純な手法に上回られる場合があったと報告しています。高度な手法が、適切に調整された単純な手法に勝てないことがあるという指摘です。

この構造を踏まえると、確認すべきことがはっきりします。提示された数値がオフライン評価なのかオンライン評価なのか、そして何と比較した数値なのかです。

人気バイアス｜「売れている商品を推薦しているだけ」を見分ける

精度の評価で最も見逃しやすいのが人気バイアスです。前述のとおり、協調フィルタリングは多くの人が接触したアイテムを推薦の上位に出しやすい性質を持ちます。アイテムベースでは、人気商品がどの商品との共起も多くなるため、類似度の上位に居座ります。

ここで何が起きるか。人気商品を並べた推薦枠は、オフライン評価でもオンライン指標でも、それなりに良い数字を出します。人気商品はもともとクリックされやすく買われやすいからです。つまり「個人に合わせた推薦」が機能していなくても、指標上は成功しているように見えてしまいます。

見分ける観点は次のとおりです。

• 推薦結果の多様性: 異なるユーザーに出る推薦リストが、どの程度違っているか。全員にほぼ同じ商品が並ぶなら、パーソナライズは効いていません
• カタログカバレッジ: 推薦に登場する商品が、全商品のうち何割を占めているか。上位数%の商品だけが推薦に出ている状態なら、ロングテールは埋もれています
• 新商品の露出: 入荷から一定期間内の商品が、推薦枠にどの程度出ているか
• 人気順との重なり: 推薦リストの上位 10 件のうち、サイト全体の売上ランキング上位 10 件と重複している件数

これらは「精度」とは別の軸の指標ですが、推薦枠が本当に個人化されているかを判断する材料になります。ベンダーに「多様性とカタログカバレッジはどう測り、どの水準を目標にするのか」と聞ける状態になっておくと、議論の質が変わります。

比較対象を決める｜人気順ベースラインとの差で精度を見る

ここまでの整理から導かれる結論はシンプルです。レコメンドエンジンの精度は、単独の数値では評価できません。「何と比べて、どれだけ良いのか」という比較の形でしか意味を持ちません。

発注前に決めておくべき比較対象（ベースライン）は、次の 3 つです。

このうち実質的に重要なのは「人気順との比較」です。人気順は実装が容易で、データ量の制約も受けません。協調フィルタリングを採用する判断は、「人気順を有意に上回る」という条件を満たすかどうかにかかっています。この比較を含まない精度報告は、導入判断の根拠にはなりません。

加えて、測定の設計も事前に決めておく価値があります。何を主要指標にするか（推薦枠経由の CVR か、サイト全体の客単価か）、どの期間で測るか、どれだけの差が出れば採用とみなすか。導入後に「効果があったのか分からない」という状態を避けるには、この合意が先に必要です。

ECサイトでレコメンドの導入を発注する前に確認したい6つの質問

ここまでの内容を、そのまま打ち合わせで使える質問の形に変換します。各質問には「この回答が返ってきたら掘り下げが必要」という観点を添えています。

方式とデータ要件を確認する3つの質問

質問1: どの方式を前提にした提案ですか。ユーザーベース、アイテムベース、モデルベース、またはそれらのハイブリッドのどれに当たりますか

掘り下げが必要な回答: 「協調フィルタリングです」で止まる、「AI が自動で最適化します」と方式に触れない。前述のとおり型によって必要データと運用負荷が変わるため、型が示されない提案は適合性の検討が行われていない可能性があります。あわせて「サイト内のどの枠が協調フィルタリングで、どの枠が人気順やルールベースなのか」を枠単位で確認します。

質問2: 学習に使う行動データの種類と、最低限必要な件数の想定を教えてください

掘り下げが必要な回答: 「データが多いほど精度が上がります」という一般論のみ。確認したいのは、購買のみか閲覧・カート投入も使うのか、ログイン前後の行動を突合するのか、学習期間は何ヶ月分かという具体です。あわせて「2 件以上の行動があるユーザー数」という単位で要件を聞くと、前述の商用サービスの要件と比較できます。

質問3: 当社の現在のデータ量で成立するかの試算をいただけますか

掘り下げが必要な回答: 「導入してみないと分かりません」。棚卸しで出した 4 つの数値（行動の種類、総インタラクション件数、1 ユーザー／1 アイテムあたりの平均、密度）を提示して試算を依頼します。データが足りない場合に「どの程度の期間でどの水準まで溜まる見込みか」「その間はどの方式で代替するか」まで答えが返ってくれば、設計が検討されている証拠になります。

精度と運用を確認する3つの質問

質問4: 精度はどの指標で、どのベースラインと比較して提示されますか

掘り下げが必要な回答: 「精度 90%」のような単独の数値、オフライン／オンラインの区別がない説明。前述のとおり、オフライン評価の数値がオンラインの事業指標に直結するとは限りません。「人気順ベースラインと比較した CVR の差」という形まで具体化されているかを確認します。あわせて、推薦結果の多様性・カタログカバレッジをどう測るのかも聞いておきます。

質問5: 新規ユーザー・新商品が出たときの推薦はどう設計されますか

掘り下げが必要な回答: 「学習が進めば改善されます」。コールドスタート問題は構造上必ず発生するため、初回訪問者に何を表示するのか、新商品をいつから推薦対象に入れるのか、切り替えの閾値は何件なのかという設計が示されるべき箇所です。この回答が具体的なベンダーは、導入初期の体験まで考えています。

質問6: 公開後の再学習頻度と、改善の運用を誰が担いますか

掘り下げが必要な回答: 運用主体が曖昧なまま。確認したいのは、再学習の頻度（日次／週次／月次）とその実行主体、推薦結果を確認するダッシュボードの有無、精度低下に気づく仕組み、改善を依頼する場合の体制と費用です。社内にデータを見る担当がいない場合、この点が導入後の最大のリスクになります。

SaaSと受託開発で回答の見方がどう変わるか

同じ 6 つの質問でも、SaaS ツールと受託開発では回答の性質が変わります。見方を整理しておきます。

判断の目安としては、標準的な EC の推薦枠で足りるなら SaaS が合理的です。一方、自社固有の在庫制約や価格ロジックを推薦に織り込みたい場合、既存システムとの連携が複雑な場合、推薦ロジックを自社の資産として持ちたい場合は、受託開発の検討対象になります。受託開発の場合に設計・検証がどう進むかはECサイトAIレコメンド導入事例で具体的な進行を確認できます。

どちらを選ぶ場合でも、6 つの質問に対する回答を比較可能な形で揃えておくと、稟議での説明がしやすくなります。

まとめ｜協調フィルタリングは「自社のデータが語れるか」で決まる

本記事の要点を整理します。

• 協調フィルタリングとは、アイテムの中身を見ず「誰がそれを選んだか」という行動の重なりだけで推薦を導く仕組みです。ユーザーベース・アイテムベース・モデルベースの 3 つの型があり、自社のユーザー数とアイテム数の比率、商品の入れ替わり頻度によって適性が変わります
• 必要なデータ量は総件数だけでは判断できません。行動の種類、総インタラクション件数、1 ユーザー／1 アイテムあたりの平均件数、そして密度（スパース性）の 4 観点で見ることで、自社で成立するかの見通しが立ちます
• 「高精度」という説明は、オフライン評価とオンライン評価のどちらなのか、何と比較した数値なのかが示されないと評価できません。特に人気順ベースラインとの比較は、パーソナライズを導入する意味そのものを問う論点です
• 発注前の 6 つの質問（方式・データ要件・試算・精度の比較対象・コールドスタート対応・運用体制）に具体的な回答が返ってくるかどうかが、提案の成熟度を測る材料になります

最初の一歩として、ベンダーとの次の打ち合わせまでに 2 つの数値を出してみてください。対象期間における「ユーザー ID × アイテム ID のユニークな組み合わせ数（総インタラクション件数）」と「2 件以上の行動があるユーザーの人数」です。この 2 つが手元にあるだけで、一般論の提案を自社の条件に引き戻すことができます。協調フィルタリングが機能するかどうかは、アルゴリズムの優劣よりも、自社のデータが何を語れる状態にあるかで決まります。

関連情報

AI を使った機能の導入検討にあたって、社内で論点を整理するための資料をお役立ち資料としてまとめています。検討の進め方を体系的に確認したい場合は、お役立ち資料一覧をご覧ください。

自社のデータ状況に合わせたレコメンド機能の設計や、既存システムとの連携をご検討中の場合は、お問い合わせフォームからご相談いただけます。要件が固まっていない段階でのデータ要件の整理からご相談いただけます。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。