プロジェクト概要

年商 50 億規模の中規模 EC を運営するクライアント向けに、サイト内のレコメンド機能を全面刷新したプロジェクトです。従来は「同カテゴリの売れ筋順」「閲覧した商品と同じタグの商品」といったルールベースのレコメンドで運用していましたが、改善の手が尽きて指標が頭打ちになっていました。

FIXIT は行動ログと商品マスタを統合したデータ基盤の設計から、レコメンド基盤の実装、A/B テストの設計、フロントエンドへの組み込みまでを AI 駆動開発 で一気通貫に担当し、約 10 週間で本番リリースまで到達しました。本記事では、何をどう作り、どの指標がどれだけ動いたのかを実務目線で公開します。

クライアントは取扱 SKU が約 4 万点、月間セッションが数百万規模で、扱う商品はファッションと生活雑貨が中心です。商品の入れ替わりが速く、新商品が常に投入されるため、レコメンドの鮮度をどう保つかが事業上の論点になっていました。

事業上の課題

ルールベースのレコメンドには、運用を続けるほど効果が伸びにくくなるという構造的な限界がありました。条件分岐を足すほどロジックが複雑になり、誰も全体像を把握できなくなる一方で、ユーザー 1 人ひとりの文脈にはほとんど寄り添えていません。

具体的には、次のような数字が課題として共有されていました。

  • トップページからの回遊率(2 ページ目以降の遷移率)が伸び悩み、直帰が多い
  • 商品詳細ページの関連商品からの遷移が少なく、1 セッションあたりの閲覧商品数が頭打ち
  • カートまで進んだあとのカゴ落ちが高く、再訪時に同じ商品をまた探させてしまう
  • 新商品や在庫が薄いロングテール商品が露出されず、売れ筋だけが回り続ける

「人気順に毛が生えた程度のレコメンドから抜け出したいが、データサイエンスの専任チームを抱える体力はない」という、中規模 EC によくある状況でした。レコメンドエンジンをゼロから内製するのは重く、かといって外部 SaaS のブラックボックスに丸ごと預けるのも、自社の商品理解が活かせず納得感に欠けます。そこで、自社データを軸にした基盤を短期間で立ち上げる選択肢として、FIXIT のAI 駆動開発に相談が来ました。

アプローチ 1: 行動ログと商品マスタの統合とデータ設計

レコメンドの精度は、モデルの巧拙よりもまず入力データの質で決まります。最初の 2 週間は、散らばっていたデータを一箇所に集めて扱える形に整える作業に充てました。

行動ログ(閲覧・検索・カート投入・購入)はアクセス解析と自社 DB に分散し、商品マスタは基幹システム側にあって、価格や在庫、カテゴリの粒度が揃っていませんでした。これらを BigQuery に集約し、ユーザー ID と商品 ID を軸にしたイベントテーブルと、商品の特徴量テーブルへ正規化していきます。

ここで AI 駆動開発が効いたのは、データの「読み解き」と変換クエリの量産です。既存テーブルのスキーマと数百行のサンプルを Claude Code に渡し、カラムの意味や欠損のパターンを推定させたうえで、ETL の変換 SQL とテストデータを生成しました。人間は生成された変換ロジックの妥当性をレビューし、業務的におかしい箇所(セール期間の価格をどう扱うか、返品をどう除外するか)を指摘して詰める役割に回ります。

特徴量は凝りすぎず、まず効きそうなものから整えました。ユーザー側は直近の閲覧・購入カテゴリと価格帯、訪問頻度。商品側はカテゴリ、価格帯、ブランド、投入からの経過日数、在庫水準です。データ設計の段階で「あとから評価できる形」を意識し、推薦結果とその後のクリック・購入を必ず紐づけられるよう、レコメンド表示時のコンテキストもログに残す設計にしました。

アプローチ 2: レコメンド基盤の実装と A/B テスト設計

レコメンド基盤は、いきなり高度なモデルに飛びつかず、協調フィルタリングとコンテンツベースを組み合わせたハイブリッド構成から始めました。「この商品を見た人が次に見た・買った商品」という共起ベースのスコアに、商品特徴量の類似度と新商品ブースト、在庫やカテゴリのビジネスルールを重み付けで合成する方式です。

実装は API サービスとして切り出し、フロントエンドからは商品 ID とユーザーコンテキストを渡すと推薦リストが返る、シンプルなインターフェースに統一しました。スコア計算のロジックや重み付けのパラメータは設定ファイルで外出しし、運用しながら調整できるようにしています。この実装フェーズでは、Claude Code と Cursor を使ったテスト駆動の進め方が効きました。期待する推薦結果をテストとして先に固定し、実装を AI に任せてレビューに集中するフローです。考え方の詳細はAI 駆動 TDD の記事で扱っています。

同じくらい重視したのが A/B テストの設計です。レコメンドは「変えた気になって満足する」ことが起きやすい領域なので、効果を後から疑われないテスト設計を最初に固めました。

  • ユーザー単位で安定して振り分け(同じユーザーが訪問のたびに群を行き来しない)
  • 主要指標を事前に 1 つに決める(本案件は購入完了の CVR)。回遊率や客単価は副指標として併記
  • 必要なサンプルサイズと検出したい効果量を事前に見積もり、いつ判定するかを先に決める
  • セール期間や特定キャンペーンの影響を後から切り分けられるよう、セグメントを残す

このテスト設計を最初に決めておくことで、リリース後に「数字が動いた・動かない」を感覚で語らず、合意済みのルールで判定できるようになります。

アプローチ 3: フロントエンドへの組み込みと表示速度の担保

レコメンドは見せ方と速さで成果が大きく変わります。どれだけ推薦の中身が良くても、表示が遅ければユーザーは待たずに離脱し、レイアウトがずれれば誤クリックを誘発します。FIXIT はフロントエンド基盤の設計が専門領域なので、ここは特に丁寧に作りました。

組み込みは、トップページ・商品詳細ページの関連商品・カート画面の 3 箇所から始めました。推薦 API の呼び出しは商品本体の描画をブロックしないよう非同期にし、推薦枠は読み込み中もレイアウトが動かないようプレースホルダーで領域を先に確保します。これにより、レコメンドの取得が遅れても本文の表示や CLS(レイアウトのずれ)に影響しません。

表示速度の担保では、推薦結果のキャッシュ設計が肝でした。ユーザー個別の推薦はパーソナライズの度合いとキャッシュ効率がトレードオフになるため、商品 ID とユーザーセグメント単位で短時間キャッシュし、計算負荷とリアルタイム性のバランスを取りました。フロントエンドのコンポーネントは Claude Code でたたき台を量産し、表示パターン(在庫切れ時の差し替え、推薦が空のときのフォールバック)を網羅しながら、デザインシステムに沿う形へ人間が整えています。

計測タグも同時に仕込み、推薦枠の表示・クリック・そこからの購入を一連で追えるようにしました。これがアプローチ 1 のログ設計とつながり、運用しながら推薦ロジックを改善できる土台になります。

成果の実数値

A/B テストは主要指標である CVR を判定基準に、事前に決めた期間まで回しきってから評価しました。導入した 3 箇所を合わせた結果、レコメンド経由のユーザーで次の改善が確認できています。数値は先方の合意のうえで、レンジで公開します。

  • CVR(購入完了率) が対照群比でおよそ 1.1〜1.2 倍
  • 回遊率(1 セッションあたりの閲覧商品数) が数割の改善
  • 客単価 が微増(関連商品からのついで買いが増加)
  • ロングテール商品の露出と売上が増え、売れ筋への偏りが緩和

特に効果が大きかったのは商品詳細ページの関連商品枠で、共起ベースの推薦が「次に見たい商品」とよく噛み合いました。一方トップページは、訪問直後で文脈が薄いユーザーが多く、改善幅は相対的に小さめです。場所ごとに効きやすさが違うこと自体が、運用の打ち手を考えるうえで有益な学びになりました。

判定にあたっては、副指標が悪化していないかも必ず確認しています。CVR だけ上がって客単価が下がる、回遊は増えたが直帰も増える、といった「片側だけ良く見える」状態を避けるためです。

学びと再利用可能なナレッジ

このプロジェクトで再利用できるナレッジは、技術そのものよりも進め方にあります。

まず、評価指標は実装より先に置くこと。主要指標を 1 つに絞り、副指標を併記する形を最初に決めておくと、リリース後の議論が「数字を増やす方法」に集中します。次に、段階リリースを徹底すること。3 箇所を同時に出さず、効きやすい商品詳細ページから出して学びを得てから横展開した方が、リスクも調整コストも小さく済みます。

AI 駆動開発の観点では、データ変換・テスト・フロントのたたき台といった「量が出る作業」を AI に寄せ、人間はデータの意味づけ・評価設計・ビジネスルールの判断に集中する分担が、短期間での品質担保に直結しました。レコメンドのロジックを設定ファイルで外出ししておいたことも、運用フェーズで効いています。

ありがちな落とし穴

コールドスタートを甘く見ない

行動データが少ない新規ユーザーと、投入直後の新商品には、協調フィルタリングがほぼ効きません。ここをルールベースのフォールバック(人気順・新着・カテゴリ内のおすすめ)で確実に埋めておかないと、「肝心なところで推薦が空」という体験を生みます。本案件では、データが溜まるまではコンテンツベースとルールで支え、徐々に協調フィルタリングの比重を上げる設計にしました。

指標のチェリーピックを避ける

レコメンドは見せ方によって、都合の良い数字をいくらでも拾えてしまう領域です。テスト期間を切り取る、好調なセグメントだけ抜き出す、効いた指標だけ報告する、といったチェリーピックは、短期的には良く見えても運用判断を誤らせます。だからこそ、判定指標・期間・セグメントを事前に固定し、副指標までセットで見る運用を最初から決めておくことが重要でした。

速度とパーソナライズのトレードオフを設計で吸収する

ユーザー個別の推薦をすべて毎回リアルタイム計算すると、負荷も表示遅延も増えます。セグメント単位の短時間キャッシュで「十分パーソナルだが十分速い」着地点を探るのが現実的です。速度を犠牲にしたパーソナライズは、CVR にはむしろ逆効果になりかねません。

よくある質問

Q. 同じ規模のレコメンド刷新を頼むと費用感はどのくらいですか？

A. 要件によりますが、本案件相当(データ統合・基盤実装・A/B テスト設計・主要画面への組み込み)で 400 万〜600 万円が目安です。既存のデータ基盤がどこまで整っているか、対象画面の数、運用フェーズをどこまで含めるかで変動します。要件メモをお問い合わせから共有いただければ、概算と進め方をご返答します。

Q. 既存のカートや EC プラットフォームと連携できますか？

A. できます。レコメンドは独立した API サービスとして切り出すため、フロントエンドから推薦結果を取得して表示できれば、カートや決済の仕組みには手を入れずに導入できます。既存プラットフォームのテーマ・コンポーネントに合わせた組み込みも対応範囲です。

Q. リリース後の運用体制はどうなりますか？

A. 推薦ロジックの重み付けやフォールバックの条件は設定ファイルで外出ししているため、エンジニアでなくても運用しながら調整できる部分があります。推薦の表示・クリック・購入を追える計測も仕込んでおり、改善サイクルを自走できる状態で引き継ぎます。引き継ぎ後の伴走や改善支援も、別途ご相談いただけます。

関連リソース

EC・小売のレコメンド刷新や、自社データを活かしたパーソナライズ基盤の構築をご検討でしたら、まずはお気軽にご相談ください。現状の課題と手元のデータをうかがえれば、効果が出やすい打ち手と進め方をご提案します。プロダクト開発の無料相談はお問い合わせフォームから、AI 駆動開発のサービス概要とあわせてご覧ください。