【解説 note】100ミリ秒の魔法：小売のコールドスタートを克服するリアルタイムAIの仕組み

「初めて訪れたユーザーに、どう最適な商品を薦めるか」

オンライン小売の世界では、訪問者の多くが匿名の新規ユーザーです。過去の購買履歴も、クリック履歴もほとんどない状態からパーソナライズする――これが「コールドスタート問題」です。従来の協調フィルタリングでは大量の相互作用データが必要で、サードパーティCookieに依存したプロファイルづくりが一般的でした。しかしプライバシー規制が強まり、Cookieレスの時代には通用しません。

この難題に、LLM（大規模言語モデル）と同じ注意機構（Attention） を応用したのがMalachyteです。彼らは「ユーザーの一連の行動を、文章の中の単語のように扱う」ことで、少ない情報からでも精度の高い予測を実現しました。本記事では、その技術の核心と、Google CloudのリアルタイムAIスタックがどう支えているかを解説します。

1. 「次の商品」を予測する、Attentionの転用

LLMの仕組みを簡単に振り返ってみましょう。「今日はとてもいい」の後に「天気」を予測するとき、モデルは文中の離れた単語間の依存関係をTransformerの注意機構で捉えます。

Malachyteの発想は明快です。

つまり、検索クエリ → 商品クリック → カテゴリページ閲覧 → カート追加……という一連の行動シーケンスを「文章」とみなし、その文脈から次のアクション（＝表示すべき商品）を推定するのです。

これにより、従来の「類似ユーザーを探す」方式から、「いまこの瞬間の文脈」を重視する方式へとパラダイムが変わります。

2. ユーザーベクトルが、訪れた瞬間に動き出す

Malachyteのプラットフォームでは、ユーザーがサイトに到着した瞬間、次のような処理が走ります。

1. ユーザーベクトルの作成
   ブラウザ情報、流入元、時刻、デバイスなど、わずかな初期情報をベクトル化。

2. 行動のたびに即時更新
   クリック、検索、スクロールといったイベントが発生するたびに、その情報が即座にベクトルに追加される。100ミリ秒単位で更新され、次の表示ページの検索結果やレコメンドカートに反映される。

3. 商品も同じ空間に埋め込まれている
   商品カタログの各アイテムも同じベクトル空間にマッピングされているため、「いまのユーザーベクトルに最も近い商品」を高速に検索できる。

イメージとしては、ユーザーベクトルが空間内を動き回りながら、興味のない商品から遠ざかり、関心のある商品の近くに引き寄せられていくようなものです。

3. 継続学習で「みんなの知恵」がモデルを強くする

さらに面白いのは、この仕組みが複数の小売事業者をまたいでモデルを賢くするところです。

• 各ユーザーの匿名化された行動データが、Attentionベースのニューラルネットワークを継続的に訓練。

• あるサイトでの「青いスニーカーを見た後に白いスニーカーを比較する」という行動パターンが、別のサイトでの予測精度向上に寄与する。

• いわばデータ協同組合のような効果が働き、導入企業全体でレコメンド品質が底上げされます。

その結果、Malachyte導入企業の中には、売上が2倍から3倍に跳ね上がったところもあるといいます。

4. Google Cloudの「リアルタイムAI3層アーキテクチャ」

「100ミリ秒で推論から表示まで」を実現するには、強力なインフラが必要です。Malachyteが採用したGoogle Cloudの構成を見てみましょう。

第1層：イベントストリーミング層（Kafka）

• ユーザーの行動イベントはすべて Managed Service for Apache Kafka に流れ込む。

• キューイングによる遅延を排し、ほぼリアルタイムに後続処理へパス。

第2層：超高速なユーザープロファイル管理（Bigtable）

• Kafkaから流れてきたイベントは Cloud Bigtable に即反映される。

• Bigtableの読み書きは10ミリ秒台なので、ユーザーベクトルの参照・更新が高速に完了。

• Kafka→Bigtableの連携で、サイトのフロントエンドが求めるスピードに耐えうる。

第3層：商品データの継続的同期（Pub/Sub）

• 商品カタログの更新、在庫変動、小売事業者固有の属性情報など、バックエンドの変更は Cloud Pub/Sub 経由で非同期に取り込む。

• REST APIでグローバルにアクセス可能で、小売側の深いインテグレーションが不要。

推論・サービング基盤（GKE & GCE）

• 実際のAIモデル推論は Google Kubernetes Engine (GKE) 上で動作するエージェントが担当。

• 一部のモデル推論には Compute Engine も併用。

• すべてマネージドサービスで構成されているため、小さなチームでも運用負荷を抑えつつスケールできます。

このように、「Kafkaでイベント受信 → Bigtableでユーザー状態管理 → Pub/Subで外部データ連携」という3層が、リアルタイム継続学習の土台になっています。GPUやストレージだけでなく、こうしたストリーム処理とKVストアの高速連携が本番AIには不可欠なのです。

5. 小売業界にもたらす意味

このアーキテクチャが示すのは、もはや個人化は「大量の過去データ」よりも「瞬間の文脈理解」の時代に入ったということです。

• プライバシーに配慮：Cookieや長期プロファイルに依存しないため、ユーザーに透明性のある体験を提供できる。

• マルチモーダル対応：検索、カテゴリページ、カート内レコメンドなど、同じモデルで複数箇所を最適化。

• 導入のしやすさ：小売事業者はPub/Sub REST APIを通じてカタログデータを送るだけでよく、大がかりなシステム統合が不要。

まとめ：少ない手がかりを、次の一手に変える

Malachyteの事例は、AIの民主化を強く印象づけます。ほんの数年前まで、これほどのリアルタイムパーソナライゼーションは大企業の専売特許でした。しかし、Transformerの注意機構を転用するアイデアと、Google Cloudのマネージドサービスを組み合わせれば、少人数のチームでも業界に革新を起こせる。まさに「巨人の肩の上に立つ」好例です。

「$300の無料クレジットで始められる」とGoogle Cloudが言うのも頷けます。もしあなたがEコマースの責任者や、AIスタートアップの立ち上げを考えているなら、Kafka・Bigtable・Pub/Subのリアルタイムスタックは、最初に検討すべき選択肢の一つになるでしょう。

本記事は、Google Cloud Blogに掲載された「Data Analytics: How Malachyte solves retail’s cold-start problem with managed real-time AI」(2026年8月11日) を基に構成した解説ノートです。