ビジネススクールで受講した「テクノベート・シンキング」の学びを全12回でまとめるシリーズ、その6。
第3回後半の事前課題は、「ECサイトではどのようなリコメンデーションがユーザーにとって効果的か」を考えるというもの。前半でバブルソートを実装したのとは打って変わって、ビジネス課題にアルゴリズムの考え方を適用する回だ。
バブルソートでは「数字を並べ替える」という明確な正解がある。しかしリコメンド設計には唯一の正解がない。「何をもって効果的とするか」の定義自体がビジネス判断であり、技術だけでは答えが出ない。この転換が、この回の最も大きな気づきだった。
「効果的なリコメンド」の定義から始める
まず考えたのは、「効果的なリコメンド」とは何か、という定義そのもの。
漠然と「おすすめが上手い」では議論にならない。ユーザーの満足度と購買率を最大化するために必要なのは、次の3つの体験だと整理した。
- 「自分に合っている」：好みや購入履歴に基づいた、的確な提案
- 「新しい発見がある」：自分では探さなかったが、刺さる商品との出会い
- 「迷わず選べる」：選択肢の過多による疲労（チョイス・ファティーグ）を防ぐ絞り込み
この3つは互いにトレードオフの関係にある。「自分に合っている」を追求すると新しい発見がなくなるし、選択肢を減らしすぎるとパーソナライズの精度が活かせない。リコメンドの設計とは、このバランスをどう取るかという「ビジネス判断」なのだと最初に認識できたのは大きかった。
バブルソートからリコメンド設計へ──パラダイムシフトの瞬間
前半のバブルソートでは、「与えられた数字を小さい順に並べる」という明確なゴールがあった。入力も出力も定義されていて、正しいアルゴリズムを組めば正解にたどり着く。
しかしリコメンド設計では、そもそも「何を推薦すべきか」の定義から自分で決める必要がある。同じユーザーに対しても、「過去に買った商品と似たものを出す」のか、「まだ見たことのないカテゴリから提案する」のか、「今この瞬間に売りたい商品を出す」のかで、設計がまるで変わる。
この「正解のある問題」から「正解を自分で定義する問題」への移行が、まさにパラダイムシフトだった。プログラミング的な「手順をどう組むか」から、ビジネス的な「何を目指すか」への転換。バブルソートで鍛えたアルゴリズムの基礎が、ここで初めてビジネスの道具として機能する実感があった。
リコメンドの仕組みを理解する──代表的なアプローチ
課題に取り組む中で、リコメンドにはいくつかの代表的なアプローチがあることを学んだ。
協調フィルタリングは、似た行動パターンを持つユーザー同士の情報を使う手法だ。「あなたと似た人が買っている」という推薦の仕方で、自分では検索しない商品との出会いが生まれやすい。ただし、新規ユーザーや新規商品にはデータがないため推薦できない「コールドスタート問題」がある。
コンテンツベースは、商品の属性（カテゴリ、説明文、タグなど）の類似度で推薦する手法。商品の情報さえあれば新規商品も推薦できるのでコールドスタートに強いが、属性が似た商品ばかりを出すため新しい発見が生まれにくい。
ハイブリッド型は、複数の手法を組み合わせる。精度は上がるが、設計と運用の複雑さが格段に増す。
それぞれの手法に得意・不得意がある。重要なのは、「どの手法が優れているか」ではなく「自社のビジネスモデルとユーザー特性にどの手法が合うか」という判断軸だ。技術の優劣ではなく、ビジネスとの適合性で選ぶ。この視点が、テクノベート・シンキングで繰り返し強調されていたことだった。
アルゴリズム選定よりも「データの整備」が先だった
一通りアプローチを整理して、一番強く感じたのは「アルゴリズムの優劣を議論する前に、データが整備されていなければ何も始まらない」ということだった。
リコメンドを動かすには、そもそもユーザーの行動ログ、評価データ、商品属性といったデータが蓄積されている必要がある。さらに、そのデータには必ず「汚れ」がある。評価をつけていない商品による欠損値、botや不正アクセスによる異常値、同じユーザーの複数アカウントによる重複、人気商品に評価が偏るバイアス──これらを放置したままアルゴリズムを回しても、出てくる推薦はノイズだらけになる。
インフラの世界でも「まずログを取れ、話はそれからだ」と言われるが、リコメンドの世界でもまったく同じだった。どんなに優秀なアルゴリズムも、入力データが汚ければ出力もゴミになる。Garbage In, Garbage Out──これはどの領域でも変わらない真理だ。
この気づきは、IT畑にいる私にとって特に腹落ちした。運用の現場では、ツールの導入よりもまずログの設計と収集体制の整備が優先される。同じことがリコメンドにも当てはまるとわかったとき、「技術の世界の原則は、ビジネスの文脈でも同じように機能する」という確信が得られた。
フィルターバブル──精度の追求が生む「発見のない世界」
リコメンドを調べていく中で印象に残ったのが、フィルターバブルの問題だ。
ユーザーの嗜好に合わせすぎた結果、同じような商品ばかりが表示されるようになり、新しい発見がなくなってしまう現象。リコメンドの精度を上げれば上げるほど、ユーザーは自分の好みの「泡（バブル）」の中に閉じ込められる。
これはECサイトだけの問題ではない。ニュースアプリが自分の立場に合う記事ばかり表示する、SNSのタイムラインが同じ意見ばかりになる──フィルターバブルは情報の偏りを加速させ、社会の分断を助長するリスクすらある。
では、どうするか。一つの考え方は、あえて嗜好から外れた推薦を一定の割合で混ぜる「セレンディピティ設計」だ。音楽配信サービスが普段聴かないジャンルの曲をたまに混ぜてくるのがこのアプローチ。飽きずにサービスを使い続ける動機にもなるし、フィルターバブルの緩和にもなる。
ただし混ぜすぎると「関係ない商品ばかり出てくる」とユーザーが離脱する。このさじ加減こそ、技術だけでなくビジネス判断の領域だ。「精度」と「多様性」のバランスをどこに設定するかは、そのサービスが何を大事にしているかの表明でもある。
先ほどの「効果的なリコメンド」の3要素のうち、「自分に合っている」と「新しい発見がある」が本質的にトレードオフの関係にあるのは、まさにこのフィルターバブルの問題が背景にある。精度を追求すればバブルが強化され、多様性を重視すれば精度が落ちる。どちらに振るかはビジネスの意思決定であり、エンジニアだけで決められる問題ではない。
テクノベートのフレームワークで整理する──ありたい姿→テクノロジー→検証
この科目で繰り返し出てくるフレームワーク──「ありたい姿を描く → テクノロジーを選定する → 検証・改善する」の3ステップで、リコメンド設計を整理してみた。
まず「ありたい姿」から始める。どんな顧客体験を実現したいか。そのためにどんなデータが必要か。ログ収集体制の整備、データの品質管理が出発点になる。
次に「テクノロジー選定」。ユーザー行動に基づく仮説を立て、複数のアプローチの中から適切なものを選ぶ。コスト・スピード・精度のバランスも考慮する。
最後に「検証と改善」。A/Bテストで効果を定量評価し、クリック率やコンバージョン率、リピート率などのKPIを見ながらアルゴリズムを調整する。このサイクルは一度きりではなく継続的に回すもの。ユーザーの嗜好は変わるし、商品ラインナップも季節で変わる。一度作って終わりのリコメンドは、すぐに精度が落ちる。
このフレームワークを使って整理したことで、リコメンド設計は「技術選定」ではなく「ビジネス設計」であることがはっきりした。「どのアルゴリズムを使うか」は手段であり、出発点は「どんな顧客体験を提供したいか」というビジネスの問い。テクノベート・シンキングが繰り返し強調しているのは、まさにこの順番だ。
リコメンド＝ビジネス戦略──技術ではなく経営の問題
課題を通じて最も印象に残ったのは、リコメンドは技術の問題ではなく、ビジネス戦略そのものだという気づきだ。
どんなリコメンドを出すかは、「このサービスはどんな価値を提供するのか」という事業の根幹に関わる。パーソナライズの精度を追求して購買率を最大化する方向に振るのか、セレンディピティを重視してブランドの独自性を出すのか、あるいは人気ランキングの信頼感で新規ユーザーの取り込みを狙うのか──リコメンドの設計方針は、事業戦略の鏡だ。
IT畑にいると、リコメンドエンジンを「導入するかしないか」「どのツールを使うか」という技術選定の問題として捉えがちだ。しかし本質は、「何を推薦するかを通じて、どんな顧客体験を設計するか」というビジネスデザインの問題だった。
前回のTransition Diagramで「画面遷移の設計はUIの問題ではなくビジネス戦略の問題」だと学んだ。今回は「リコメンド設計はアルゴリズムの問題ではなくビジネス戦略の問題」だと学んだ。テクノロジーの裏にはビジネスの意思決定がある──テクノベート・シンキングが一貫して伝えているのは、このメッセージだと感じる。
学び：「調べる」と「設計する」は別のスキル
この課題で痛感したのは、「調べる」と「設計する」は別のスキルだということ。アルゴリズムの種類や事例を調べるのはインプットの作業で、それを「このサービスにはこのアプローチが最適」と選定し、検証のKPIまで設計するのはアウトプットの作業。後者ができて初めて、ビジネスに使える知識になる。
前半でバブルソートという純粋なアルゴリズムを体験し、後半でそれをビジネス課題に適用する──第3回はこの流れが非常によく設計されていた。バブルソートで「同じ問題をいかに少ない手順で解くか」を学び、リコメンドで「ビジネスの問題をアルゴリズムの言葉に翻訳する」練習をする。この2つがセットで来たことで、アルゴリズム思考がビジネスの道具になるという手応えが初めて掴めた回だった。
次回：レポート提出回──ここまでの学びを総動員する総合演習
第4回はいよいよレポート提出回。ここまでの学び──プログラミングの基礎、Transition Diagram、アルゴリズム思考、リコメンド設計──を全部投入する総合演習だ。次回はその話を書く。
今回参考にした書籍
