Amazonの売上の35%が、AIによるレコメンドエンジンから生まれている。
これは巨大な数字だ。2024年のAmazon年間売上は約6,000億ドル
その35%は2,100億ドル（約30兆円）だ。地球上で最も洗練されたレコメンドシステムが、この数字を毎年生み出し続けている。
しかしAmazonのレコメンドシステムの真の凄みは「35%」という数字ではない。その設計思想にある。
Netflixが「あなたが見たいと思うコンテンツを届ける」なら、Amazonが解いた問いはより一歩踏み込んでいる。
「あなたがまだ欲しいと気づいていない商品を、欲しいと気づく前に届ける。」
「チェックアウトレコメンド」誕生の物語
1998年、Amazonのエンジニア、グレッグ・リンデンはあるアイデアを持っていた。
「カートの中身を見て、チェックアウト（決済）画面で追加商品を提案したらどうか」
今では当たり前のこのアイデアは、当時のAmazonの上層部から猛烈に反対された。「決済中に別の商品を見せたら、購買が中断されてしまう」という懸念だ。
しかしリンデンは黙っていなかった。勝手にA/Bテストを実装して結果を示した。
「チェックアウト画面にレコメンドを追加すると、売上が大幅に増加した。」
このデータがあれば反論できない。上層部は折れた。
チェックアウトレコメンドは全サイトに展開された。
データが「正しさ」を証明し、組織の「なんとなくの懸念」を打ち破った。
これはAmazonのDNA「データで判断する文化」の原点の一つだ。
「Customers Who Bought X Also Bought Y」の革命
Amazonが1990年代後半に実装した「この商品を買った方はこんな商品も買っています」
これが通販の歴史を変えた一行だ。
技術的には「アイテムベース協調フィルタリング（Item-to-Item Collaborative Filtering）」と呼ばれる。しかしその本質は単純だ。
「人間の購買行動には、文脈のある連鎖がある。」
カメラを買った人はメモリーカードを必要とする。ヨガマットを買った人はヨガブロックや水筒も必要になる。
ビジネス書を買った人は関連するビジネス書をもう一冊買う可能性が高い。
これらは「教えなくてもデータが教えてくれるパターン」だ。
Amazonはこのパターンを3億1,000万人の顧客データから抽出し、6億点を超える商品に対してリアルタイムで計算している。
あなたの会社のECサイトに、「この商品を買った方はこんな商品も買っています」は実装されているか。
そのレコメンドは「バイヤーが手作業で設定した関連商品」ではなく、「実際の購買データが示す連鎖」に基づいているか。
「Frequently Bought Together」と「Add-on Effect」
Amazonのレコメンドには大きく二つの目的がある。
①クロスセル（Cross-sell）： 関連する別の商品を提案する。カメラ → メモリーカード。
②アップセル（Upsell）： より上位・上位グレードの商品を提案する。ベーシックモデル → プレミアムモデル。
「Frequently Bought Together（一緒に買われることが多い商品）」機能は特に強力で、Amazonはこれをチェックアウト直前に集中的に表示する。
決済の直前というのは心理的に最も「追加購買」が起きやすいタイミングだ。
この効果を示す数字
- レコメンドに関与したセッションは平均注文金額が20〜40%高い
- パーソナライズされたカートレコメンドはコンバージョン率を70%改善する
Amazonの「バウンス率」は約35%で、競合のWalmart（50%）やTarget（45%）より大幅に低い。レコメンドがユーザーをサイト内に引き止め、購買機会を増やしている証拠だ。
SQLで実装する「Frequently Bought Together」
-- 同一注文で一緒に買われた商品のペアを抽出する
-- ※「Frequently Bought Together」の基礎データ
WITH order_pairs AS (
SELECT
a.product_id AS product_a_id,
a.product_name AS product_a_name,
b.product_id AS product_b_id,
b.product_name AS product_b_name,
a.order_id
FROM order_items a
JOIN order_items b
ON a.order_id = b.order_id
AND a.product_id < b.product_id -- 重複を防ぐ（A-BとB-Aを1組にする）
JOIN orders o ON a.order_id = o.order_id
WHERE o.status = 'completed'
AND o.order_date >= DATE_ADD('day', -90, CURRENT_DATE)
)
SELECT
product_a_id,
product_a_name,
product_b_id,
product_b_name,
COUNT(DISTINCT order_id) AS co_purchase_count,
-- 商品Aが登場する注文のうち、商品Bも一緒に購買されている割合
ROUND(
100.0 * COUNT(DISTINCT order_id)
/ COUNT(DISTINCT order_id)
OVER (PARTITION BY product_a_id)
, 1) AS co_purchase_rate_pct
FROM order_pairs
GROUP BY product_a_id, product_a_name, product_b_id, product_b_name
HAVING COUNT(DISTINCT order_id) >= 5 -- 最低5件以上の同時購買
ORDER BY product_a_id, co_purchase_count DESCAmazonが学んだ「パーソナライゼーションの限界」
Amazonのレコメンドには「失敗事例」もある。
最も有名なのは「尿漏れパッドをおすすめしたら炎上した」ケースだ（実話かどうかは諸説あるが）。
子ども向け商品を購買した後に「あなたにはこれもおすすめ」と尿漏れパッドが表示されたことで、ユーザーが「これはどういう意味か」と怒ったというものだ。
これが示すのは「相関関係は因果関係ではない」という事実だ。
「一緒に買われた」からといって「レコメンドすべき」とは限らない。
文脈・タイミング・感情への配慮が伴わないレコメンドは、「不気味さ」や「不快感」を生む。
「パーソナライゼーションは、賢くやると愛される。下手にやると気持ち悪い。」
このバランス感覚こそが、「データの正確さ」と同じくらい重要なスキルだ。
以前「パーソナライゼーションのほとんどはなぜ気持ち悪いのか」で詳述した通りだ。
100ミリ秒以内の判断
Amazonのレコメンドエンジンは100ミリ秒以内でレコメンドを更新する。あなたがある商品ページを閲覧した瞬間に、「この人はこれを見ている」というシグナルが即座に処理され、ページ下部のレコメンドが書き換わる。
この「セッション内リアルタイム最適化」は、Amazonの最も強力な特徴の一つだ。
「今日の訪問」の中で起きた行動をリアルタイムで反映することで、レコメンドは「この人の過去の購買履歴」だけでなく「今日この人が何を探しているか」も組み込んだ提案になる。
過去のデータ（長期的な好み）× 今日の行動（短期的な文脈） = 最適なレコメンド
「このセッション中にこの商品を見た人は、このセッション中にこれも見ている」というリアルタイムシグナルを活用したレコメンドは、バッチ処理のレコメンドより圧倒的にリアルタイム性が高く、転換率への影響が大きい。