EC サイトのレコメンド導入ガイド：設置場所・データ・効果測定

商品レコメンドは、EC において最も実績のあるパーソナライゼーション機能です。 うまく導入すれば転換率と平均注文額を押し上げ、検索では出会えなかったはずの ロングテール商品を買い物客の前に届けます。しかも導入のハードルは意外に低い — 必要なデータは、すでに手元にある購買ログだからです。

このガイドは EC レコメンド導入の「計画」レイヤです。サイトのどこに設置 するか、どんなデータが必要か、効果をどう測定するか、そして実際に 構築するまでの具体的な道筋を整理します。手を動かす段階になったら、実際の 注文ログで学習から配信までを行う実践編 購買ログからレコメンドへ進んでください。

EC サイトのどこにレコメンドを置くか

設置場所ごとに、答えるべき買い物客の問いが異なり — そして重要なことに — エンジンへのクエリの種類も異なります。

トップページ:「あなたへのおすすめ」

再訪した会員向けのパーソナライズ枠で、購買（および閲覧）履歴に基づき ます。これはユーザー → アイテムのクエリです。user_id を渡して上位 N 件 を取得し、購入済み商品は除外します。初回訪問者や匿名訪問者にはベストセラー やトレンド商品にフォールバックします — 人気順リストはコールドスタート時の 「正しい」挙動であって、失敗ではありません。

商品詳細ページ:「この商品を買った人はこんな商品も」

サイト内で最も購買意欲の高い設置場所です。買い物客は特定の商品を検討して いる最中なので、共購買の強い関連商品や代替候補を見せれば、クロスセルと 比較検討の両方の行動を捉えられます。これは表示中の商品を種にした アイテム → アイテムのクエリで、買い物客の識別が一切不要です。つまり 匿名を含む全訪問者に機能します。カバレッジが最大で意図も明確 — 商品詳細 ページのウィジェットが定番の「最初の一手」である理由です。

カート・チェックアウト:「ご注文と一緒にいかがですか」

カート内の商品を種に、付属品の同時購入を狙う枠です。カメラのケーブル、 コーヒーメーカーのフィルター。アクセサリ価格帯の数点に絞り、カートに入って いる商品は除外します。決済の最終ステップでは慎重に — そこでの離脱コストは 付属品の売上を上回りかねません。だからこそ後述の効果測定が重要です。

購入後メール・リテンション

「最近のご注文をもとにしたおすすめ」メールや休眠掘り起こしキャンペーンは、 同じエンジンをオフラインで再利用します。顧客のバッチに対してスケジュール 実行でレコメンドを生成し、メール配信基盤に渡すだけです。バッチで完結する ため、サイト改修が一切不要で、実は最も導入しやすい最初の統合先でも あります。夜間ジョブと差し込みフィールドがあれば動きます。

必要なデータ

必須の入力は行動ログ、すなわち (customer_id, product_id, timestamp) の 行の集まりです。

• 購買履歴は最も強い信号です。完了した注文 1 件 1 件が、コストを伴う 明確な興味の表明です。購買データしかなくても始めるには十分で、「あわせ 買い」モデルはまさにこのデータから作られます。
• 閲覧行動 — 商品閲覧やカート追加 — は購買の 10〜100 倍の量があり、 まだ購入していない訪問者にも届きます。GA4 のように分析基盤がすでに収集 しているなら、カバレッジを大きく広げられます。イベントから直接構築する 方法は GA4 × BigQuery を参照して ください。
• 星評価は不要です。 購買や閲覧は暗黙的フィードバックであり、現代の レコメンダーはそれを前提に設計されています。評価データがなくても障害に ならない理由は 協調フィルタリングとはで解説 しています。

実際の注文ログでの実務的な注意点: ID は安定したものを使う（会員 ID と SKU — ゲスト購入が null ID になって消えないよう注意）、同一 SKU の反復購入は 重複排除して定期購入的な商品が信号を圧倒しないようにする、タイムスタンプを 保持して「この顧客が次に何を買ったか」で評価できるようにする（ランダム 分割にしない）。数百人の顧客 × 数千件の注文があれば、非個人化ベースラインに 勝つには十分です。巨大テック企業の規模は必要ありません。

2 つ目の材料として有用なのが商品カタログファイル（SKU → 商品名、 カテゴリ、画像 URL、在庫状態）です。モデルのためではなく、API レスポンスに 表示用フィールドを載せるため、そして在庫切れ商品を表示前に除外するために 使います。

効果測定

レコメンドは売上に関わる機能です。売上機能として測定しましょう。

• エンゲージメント指標 — ウィジェットごとの表示 → クリック率（CTR）と、 帰属コンバージョン（レコメンドをクリックしたセッションが、その商品を含む 購入で終わったか）。設置場所別に追跡してください。商品ページの枠とトップ ページの枠では性能がまったく異なり、別々に評価すべきです。
• ビジネス指標 — レコメンドに接触したセッションの平均注文額と注文あたり 点数、レコメンドクリックに帰属する売上、露出したカタログの割合（ロング テールの露出度）。
• ベースラインとの A/B テスト。 誠実な比較は「レコメンドあり vs なし」 ではなく「パーソナライズモデル vs 売れ筋リスト」です。人気順は強力な ベースラインで、それに勝つことがモデルの存在意義を正当化します。訪問者 単位でランダム化し、枠の位置とデザインは固定、ランキングのソースだけを 変えます。
• オフライン指標は道しるべ、オンライン指標が結論。 nDCG や recall の ような学習時のスコアは、デプロイ前にモデルを選ぶためのものです。売上の リフトを保証はしません。真実は A/B テストにあります。カニバリゼーション にも注意 — カート枠の CTR が上がっても完了チェックアウトが減っていれば 純損失です。

Recotem での具体的な進め方

Recotem は、ここまでの内容をデータサイエンスチームなし・ リクエスト課金なしで実現する、オープンソース（Apache-2.0）のセルフホスト型 の選択肢です。プロジェクトの形はこうなります。

1. 注文ログをエクスポートするか、直接指す。(customer_id, sku, timestamp) の CSV エクスポートで十分です。注文が PostgreSQL / MySQL や BigQuery にあるなら、Recotem の データソースがエクスポートなしで直接読み ます。
2. レシピを書く。 1 つの YAML に、ソース、カラムマッピング、クレンジング 規則（重複排除、null ID の扱い、最小データ量のゲート）、試すアルゴリズム、 時系列の評価分割を宣言します。EC 向けの完全な注釈付きレシピは 購買ログの実践編にあります。
3. 学習して配信する。 recotem train が暗黙的フィードバック向け アルゴリズム（IALS、RP3beta など、人気順ベースラインも含む）を横断する ハイパーパラメータ探索を実行し、署名付きモデルアーティファクトを書き出し ます。recotem serve がそれを API キー認証付きの HTTP で公開します。
4. 設置場所と API を対応付ける。 API の動詞は上の設置場所に一対一で 対応します。 :recommend は トップページのパーソナライズ枠、 :recommend-related に seed_items を渡せば商品ページ・カートの枠（匿名訪問者にも機能）、 :batch-recommend は夜間のメールジョブ。exclude_items で購入済み・ カート内の商品を隠し、item_metadata ブロックで商品名・カテゴリ・画像 URL をレスポンスに結合すれば、フロントエンドはそのまま描画できます。
5. スケジュールで再学習する。 cron やお使いのスケジューラから recotem train を夜間実行すれば、配信プロセスは再起動もダウンタイムも なしに新しいモデルへホットスワップします。本番チェックリストは 運用ガイドを参照してください。

まずは商品詳細ページの「あわせ買い」ウィジェットから始めましょう（カバレッジ 最大、ログイン不要）。現行の非個人化ウィジェットと A/B テストし、数字が 正当化したらトップページの枠とメールへ広げる、という順番です。

次のステップ

• 購買ログからレコメンド — このガイドが 計画する構築の実践編。レシピ、クレンジング、学習、配信。
• GA4 × BigQuery — GA4 の閲覧イベントで 信号を広げる。
• 協調フィルタリングとは — 「この商品を買った人は」を支えるアルゴリズム。
• レコメンドエンジンは自作・SaaS・OSS どれを選ぶ？ — SaaS とセルフホストをまだ比較検討中なら。
• 予測 API — ストアフロントが呼ぶすべての エンドポイント。
• Recotem を学ぶ — ガイド一覧へ。