既存サービスにAI推薦を組み込む前の設計論点
「関連商品」「あなたへのおすすめ」欄が固定の人気順のまま何年も変わっていない、あるいは存在すらしない——ECや情報サービスの既存プロダクトでよく見る状態です。回遊率やCVRを上げたくて「AIでレコメンドを入れたい」と相談を受けますが、実際に着手する前に決めるべき論点が驚くほど多く、ここを詰めずに実装から入ると「作ったが誰も気づかない」「精度が悪くて逆に離脱を増やす」という結果になりがちです。
この記事では、既存サービスにAI推薦を後付けするときに発注者(PdM)が判断すべき論点を、技術選定・データ・効果測定の3軸で整理します。前提として、既存プロダクトの改善に共通する進め方は既存プロダクトの改善、外部チームが最初に見る観点にまとめているので、まだの方はそちらもご覧ください。
推薦手法は4種類、いきなり「AIっぽい」ものを選ばない
「AIレコメンド」と一括りにされますが、実装方式は大きく4つに分かれ、それぞれ得意不得意が違います。
ルールベースは「このカテゴリなら関連商品はこのロジック」と人間が条件を書く方式です。AIらしさはありませんが、データが少ない・特定の商品を必ず出したい(在庫処分・提携商品)といった要件がある場合はこれが最適解になることが多く、実装コストも低いです。
協調フィルタリングは「この商品を買った人は他に何を買ったか」というユーザー行動の類似性から推薦します。購買・閲覧データが十分にあれば精度が高く、人間が気づかない意外な組み合わせ(いわゆるセレンディピティ)を出せるのが強みです。ただし行動ログが少ないと機能しません(後述のコールドスタート問題)。
コンテンツベースは商品やコンテンツ自体の属性(カテゴリ・タグ・価格帯・文章の内容)の類似性で推薦します。行動ログが少ない立ち上げ初期でも動く一方、「似た属性のものしか出ない」ため回遊の幅が広がりにくい欠点があります。
ベクトル類似度(埋め込み検索)は、商品名・説明文・画像をAIで数百〜数千次元のベクトルに変換し、pgvectorなどで距離が近いものを検索する方式です。コンテンツベースの発展形で、「言葉が違っても意味が近いもの」を拾えるのが最大の利点(例: 「軽量ノートPC」で検索して「携帯性に優れたモバイルPC」がヒットする)。実装難度と運用コスト(埋め込み生成・再計算のバッチ)はこの4つの中で最も高くなります。
実務では単独ではなくハイブリッドにするケースがほとんどです。例えば「新規会員にはコンテンツベース、行動データが貯まった既存会員には協調フィルタリング、在庫処分商品はルールベースで強制的に混ぜる」といった組み合わせです。最初から高度な手法に飛びつくのではなく、手元のデータ量と運用体制で選べる範囲から始めるのが現実的です。
コールドスタート問題 — 新規ユーザー・新規商品にどう対応するか
レコメンド導入で必ずぶつかるのがコールドスタート問題です。2種類あります。
- 新規ユーザーのコールドスタート: 行動履歴がゼロなので協調フィルタリングが機能しない。初回訪問時は人気ランキングやカテゴリ別ベストセラーなど、行動データに依存しないフォールバックを必ず用意する
- 新規商品のコールドスタート: 出品直後は誰も購入・閲覧していないので協調フィルタリングに乗らない。商品説明文をベクトル化するコンテンツベース/ベクトル類似度なら、登録直後から推薦候補に入れられる
このため実務では「協調フィルタリングだけ」を選ぶことはまずなく、コンテンツベースかルールベースを土台に、行動データが貯まった対象から協調フィルタリング(またはベクトル類似度)を上乗せする設計が現実解です。この土台部分の設計を怠ると、「新商品や新規ユーザーには何も出ない」状態が本番で発覚し、後から作り直すことになります。
既存データで何ができるかを先に棚卸しする
着手前に必ず確認すべきなのが、今のDBに何が眠っているかです。多くの既存プロダクトでは、レコメンドに使える情報がすでに蓄積されているのに活用されていません。
- 購入履歴・カート投入履歴・閲覧履歴(ページビュー)はあるか。あればテーブル設計とログ保持期間を確認する
- 商品・記事の属性データ(カテゴリ、タグ、説明文)はどれだけ構造化されているか。説明文が自由入力のテキストのみなら、ベクトル類似度向きの土台がすでにある
- ユーザー属性(会員情報、検索履歴)は使ってよいデータか。個人情報の利用目的にレコメンドが含まれているか、プライバシーポリシー上の確認も必要
ここで「行動ログをそもそも取っていない」ことが判明するケースは珍しくありません。その場合、AI手法の選定より先にログ収集の実装が最初の一歩になります。これは数週間で終わる作業ですが、見落とすと「データがないのでAIモデルを作れない」という手戻りが発生します。
効果測定 — CTR・CVR・回遊の3指標を最初から仕込む
「レコメンドを入れたら回遊率が上がるはず」という期待だけで導入すると、効果があったのかなかったのかを判断できずに終わります。最低限、以下をリリース前に仕込んでおきます。
- CTR(表示に対するクリック率): 推薦枠自体が見られているか、見られているのにクリックされていないかを切り分ける最初の指標
- CVR(推薦経由の購入・成約率): クリックされた先で実際に成果に繋がっているか。人気順のCVRと比較して初めて「AIレコメンドの価値」が測れる
- 回遊(セッションあたりのページ数・滞在時間): 直接の購入に至らなくても、複数商品を見て回るようになったかは中長期のエンゲージメント指標として重要
これらを比較するには、A/Bテスト(推薦あり/なしのランダム振り分け、または新手法と旧ロジックの比較)が最も確実です。全ユーザーに一括で切り替えると、効果が悪化した場合に気づくのが遅れます。既存のGA4やGTMのイベント計測基盤に、推薦枠専用のクリックイベントを追加するだけで多くの場合は十分な計測ができます。
過剰に凝らない現実解 — MLOpsを構えない選択
「AIレコメンド」と聞くと機械学習基盤(特徴量ストア、モデル再学習パイプライン、A/Bテスト基盤)をフルセットで組みたくなりますが、既存サービスへの後付けでそこまで必要になることは稀です。
- 商品点数が数千〜数万規模なら、pgvectorでの埋め込み類似度検索は既存のRails/PostgreSQL構成に素直に乗り、専用のベクトルDBを別途構築する必要はないことが多い(具体的な組み込み方はpgvectorを既存Railsに導入する実装ノートで解説しています)
- 埋め込みの生成・更新は「商品登録・更新時にバッチで再計算」で足り、リアルタイム再学習の仕組みは初期段階では過剰投資になりがち
- 協調フィルタリングも、行列分解などの本格的な実装より先に、「この商品を買った人が他に買った上位N件」を集計するだけのシンプルなクエリで試して効果を見る方が投資回収が早い
最初から精緻なモデルを目指すより、シンプルな実装で効果測定の土台を作り、数字を見ながら手法を足していく進め方のほうが、限られた予算の中で成果に繋がりやすいというのが実感です。検索機能への同種のAI後付けについては既存プロダクトにAI検索を後付けする進め方もあわせてご覧ください。
既存サービスへの組み込み方と外注時の進め方
技術方式が決まったら、既存サービスへの組み込みは次の順序で進めるのが安全です。
- 推薦ロジックをAPI/バッチとして既存アプリから分離する。既存のコントローラに直接ロジックを書き込むと、後から手法を差し替えるたびに本体コードを触ることになり、A/Bテストもしづらくなる
- 表示箇所を1〜2箇所に絞ってリリースする(商品詳細ページの「関連商品」など)。全ページに同時展開せず、効果測定できる範囲から始める
- 効果測定の結果を見て、表示箇所の拡大か、手法の高度化(コンテンツベース→協調フィルタリング/ベクトル類似度)かを判断する
外注する場合は、初回の提案段階で「どの手法から始めるか」「コールドスタートにどう対応するか」「何をもって効果ありと判断するか」の3点が具体的に説明されているかを確認してください。「AIで全部解決します」という提案は、既存データの棚卸しをせずに話している可能性が高く注意が必要です。torcheees ではAI機能統合のサービスとして、既存のRails/React構成へのAIレコメンド後付けを、上記の設計論点を詰めた上で提案しています。
まとめ
- 推薦手法はルールベース・協調フィルタリング・コンテンツベース・ベクトル類似度の4種類があり、データ量と運用体制に応じてハイブリッドで組むのが現実的
- コールドスタート問題(新規ユーザー・新規商品)への対応は設計初期に必ず組み込む。行動データに依存しないフォールバックが土台として必須
- CTR・CVR・回遊の3指標とA/Bテストの仕組みをリリース前に仕込まないと、効果があったかどうか判断できないまま終わる
「既存サービスにAIレコメンドを入れたいが、何から手をつければいいか分からない」という段階でも構いません。torcheees では1〜4週間の「開発診断」で、既存データの棚卸しと最適な推薦手法の選定、概算費用をご提示します。お問い合わせフォームからお気軽にご相談ください。