バンダイナムコネクサス／TechBlogPublicationへの投稿
👻

Vertex AI Search for commerceを採用したレコメンドシステムのアーキテクチャ例とTips紹介

kyamano
に公開
機械学習
Google Cloud
レコメンド
Vertex AI
tech

1. はじめに

こんにちは、株式会社バンダイナムコネクサスの山野です。

昨今のECサイトにおいて、商品レコメンドや検索はユーザ体験を向上させるうえで今や欠かせない機能となっています。しかし、高精度なレコメンドシステムを最初からフルスペックで実装しようとすると、膨大な開発コストと時間がかかります。ユーザ行動のモデリング、リアルタイム処理基盤、A/Bテスト環境、多言語対応など、考慮すべき要素は多岐にわたり、リソースが限られる中ですべてを実現するのは現実的ではありません。

そこで重要になるのが、少ない工数で段階的に導入し、継続的に改善していくアプローチです。まずは基本的なレコメンド機能を素早く立ち上げ、ユーザの反応を見ながら徐々に精度を高めていく方が、ビジネス成果に早く繋がります。

私が参画したプロジェクトでも、このアプローチを採用しました。Google Cloud の Vertex AI Search for Commerce（旧Cloud Retail、Vertex AI Search for Retail。以降VAIS:C）を活用することで、強力なレコメンド機能を比較的クイックに導入することができました。今後は検索機能を拡張していく予定です。

そこで本記事では、私たちが採用したレコメンドシステムの構成概要と、導入する中で発見したTipsを中心にご紹介します。なお、導入の背景や効果、精度改善の取り組みの詳細については別途記載します（予定）ので、本記事では触れません。

※本記事の内容は、執筆時点の情報に基づいて記載しています。最新の情報もご参照ください。

2. Vertex AI Search for Commerce の特徴

※詳細は最新のGoogle公式ドキュメント参照

2-1. Google品質で小売向けに最適化されたパーソナライズ機能

VAIS:Cは、Googleの高品質な技術を活かして、小売向けに最適化されたパーソナライズ機能を提供します。以下のような特徴があります。

パーソナライズ

顧客の行動データをもとに、顧客ごとに最適な商品を推薦します。協調フィルタリングでない、埋め込みを利用した Deep Neural Network を利用しています。

複数のモデル利用

同一のデータセットから、商品軸やユーザ行動軸で複数のモデルを利用可能です。

マネージド

スクラッチで実装する場合は、顧客の行動（態度変容等）、オムニチャンネル（ページ遷移等）、商品データ（コールドスタートアイテム等）、グローバル展開（多言語対応等）等、考慮すべき事項が多岐にわたり、一つひとつ検討していると非常に負担が大きくなりがちです。やれることが多すぎてリソースや時間が限られる中、優先順位をつけるのも難しいでしょう。

VAIS:Cは、これらの課題を一括して解決するマネージドサービスを提供します。Googleのベストプラクティスに基づいて最適化されており、サービスごとにカスタマイズすべきところに注力することが可能です。具体的には、データと厳選されたパラメータを活用し、個別のチューニングを実現することで、より効率的な開発と運用をサポートします。

モデルのチューニング

CTR、CVR、収益など目的に応じてモデルの調整が可能です。また、フィルタや並び替え（特定条件のブースト、多様化など）を行うことができます。

リアルタイム連携

ユーザーイベントをリアルタイムに連携して、サイト滞在中にレコメンドを反映することが可能です。これにより、新規ユーザへのレコメンドも迅速に行えます。スクラッチで実装する場合にはこの機能だけでも非常に大きな開発コストがかかりますが、VAIS:Cでは簡単に実現できます。

2-2. フルマネージドのインフラ

もう一つの大きな特徴は、インフラがフルマネージドであることです。

  • 低レイテンシ
    • 高速な応答時間（APIレスポンスタイム）でユーザ体験を向上させます
  • スケーラビリティ
    • インフラ管理を気にせず、必要に応じてスケールできます
    • 過去にかなりの負荷がかかるサービスで利用した際も、事前に上限緩和申請をしておけば、激しいスパイク含めて何事もなく処理できました
  • コスト最適化
    • リクエスト量に応じた従量課金制でコストを最適化できます
  • 自動化
    • トレーニングやアップデート、チューニングが自動で行われます
  • 低運用作業コスト
    • データパイプラインや権限周りさえ最初に作り込めば、エンジニアリングスキルが高くない人でも運用可能です

3. アーキテクチャ

カタログデータとユーザーイベントデータをインプットとして、レコメンド結果をアウトプットするシステムを構築しました。カタログデータはデータレイクからバッチパイプラインを通じて取得し、ユーザーイベントデータは画面からリアルタイムで連携しています。VAIS:Cをモデルの学習とAPI提供の両方に利用しています。

  • カタログデータ（商品データ）
    • カテゴリ、ブランド、価格、在庫ステータス、商品説明文などを含む
  • ユーザーイベントデータ（行動ログ）
    • 商品詳細ページ閲覧、カート投入、購入完了などの行動を時系列で記録

3-1. 構成イメージ

今回構築したシステム構成の概要は下記です。

構成イメージの補足

推論結果ファイル作成バッチは、コスト削減のため、リアルタイムに推論することが必須でないものは事前に推論しておいてその結果を返すようにしました（VAIS:Cはリクエスト量に応じた従量課金制）。BigtableやMemorystoreに格納するパターン等も検討しましたが、最もコストがかからない方法を採用しました。

パイプラインは簡略化して記載しています。厳密にはステータスを取得するポーリング処理を入れたり、推論結果は一度BigQueryに格納したりしています。

モニタリングは Cloud Monitoring、ロギングは Cloud Logging、構成管理はTerraform、CI/CDは GitHub Actions を使いました。

4. 設計/プロジェクト進行上のポイント

4-1. 更新タイミング

モデルのトレーニング

「モデルがアクティブな場合、少なくとも1週間に1回は再トレーニングが行われますが、1日に1回より多くは行われない」と公式ドキュメントに記載されています。基本的には日次でトレーニングが行われると考えてください。適切なトレーニングデータがない（24時間以内のユーザ行動データがない）などの場合、日次で実行されないことがありますが、それでも1週間に1回は再トレーニングが行われます。現状では再トレーニングのスケジュールの指定はできません。

日次の再トレーニングについては差分トレーニングになります。ただし、モデルの調整（チューニング）が行われる際にフルデータトレーニングが実行されるので、コストと時間が日次トレーニングよりもかかります。

新しい商品とユーザーイベントがレコメンデーションモデルに反映されるまでに、最長で48時間ほどかかることがあります。モデルを新規作成するとトレーニングに1～2日程度かかるとUI上で表示されるので、一般的にこの程度の時間を見込んでおくとよいです。

推論（オンライン予測）

モデルが学習済みであれば、レコメンドAPIを呼び出したタイミングで即時応答が得られます。

推論については、ユーザが訪問したセッション内での行動データをもとにMLモデルへインプットしているので、一見客のユーザにも最適化されたレコメンドアイテムが表示されます。

4-2. 非機能要件の考慮

スケーラビリティ

デフォルトでは割り当てに上限値があります。大量リクエストが想定される場合は、“Recommendation prediction requests per minute” などを事前に緩和申請しておくことができます。

コスト

ユーザーイベントやカタログ情報のインポートまたは管理には、料金はかかりません。料金が発生するオペレーションは、トレーニング、チューニング、またはpredictメソッドを呼び出しての予測リクエストです。

トレーニングにもコストがかかります。参考数値として、各モデルのトレーニングには月あたり75～300ノード時間が消費され、多くのケースではモデルあたり190ノード時間/月が想定されているそうです。料金についてはこちらに記載されています。本稿執筆時点では、1ノード、1時間あたり$2.50です。

可用性

APIが失敗した場合の対策は自前で実装しておく必要があります。フロントエンド側でデフォルトのおすすめ商品を表示したり、前日分の結果をキャッシュして再利用したり、ルールベースの推論をしたりすることで、UX低下を最小限に抑えましょう。

モニタリング

VAIS:Cでは推奨されるアラート項目が用意されています。例えば下記です。

  • High predict error ratio
    • 予測メソッドによって返されるエラーの数によって、エラー率が指定の閾値を5分以上超える場合にトリガーされます
  • ユーザー イベント記録の削減
    • ユーザーイベントを10分間記録しなかった場合にトリガーされます
  • 未結合のユーザー イベントの比率がしきい値を超えている
    • 有効な商品に関連付けられていないユーザーイベントの比率が1時間を超えた場合にトリガーされます

取り込みステータス「成功」とともにアクティビティステータスに描画される「X個のアイテムを統合できませんでした (X items failed to integrate)」という表示に相当する情報は Cloud Logging を通じて取得することができず、したがってアラート作成も行えません。

セキュリティ・権限管理

VAIS:CへのAPI呼び出しは、IAMのサービスアカウントを用いて権限を付与します。

リアルタイムのユーザーイベントを記録するためにJavaScriptピクセルを使用してユーザのブラウザからイベントをキャプチャする場合は、APIキーが必要です。ウェブサイトのアプリケーション制限の設定には注意が必要です。一部のユーザのプライバシー設定は、参照URLを渡さないためです。

参考：https://cloud.google.com/retail/docs/setting-up?hl=ja#create-key

4-3. プロジェクト進行上のポイント

カスタマイズの難しさを合意する

マネージドなレコメンドシステムを利用する際のカスタマイズの難しさについて、関係者全員で合意しておくことが重要です。詳細は「注意点」で後述する内容を参考にしてください。

データ連携仕様を合意する

データ連携仕様についても事前に合意することが重要です。カタログデータは、既存のデータをVAIS:C向けに加工すれば最低限問題ないケースが多いです。ただし、各データ項目の業務上の意味（例：商品カテゴリの階層構造、NULLの扱いなど）を正しく理解していないと、適切な加工ができません。ドメイン知識を持つメンバーと連携し、データの意味を確認しながら進めることが大切です。

ユーザーイベントデータは、新規にリアルタイムで連携する必要が生じるケースが多く、以下の点で調整が必要になります：

  • どのイベント（閲覧、カート追加、購入など）を連携するか
  • 各イベントの必須項目と任意項目
  • リアルタイム連携の実装方法（JavaScriptピクセルなど）

このため、特にユーザーイベントデータの連携については、フロントエンドやバックエンドの実装担当者と丁寧にすり合わせを行い、確実に連携仕様の合意を得ることがプロジェクトのスムーズな進行に繋がります。

KPI設計と効果検証の重要性

レコメンドプロジェクトの成功には、明確なKPIの設計と効果検証が欠かせません。CTRやCVRといった基本的な指標に加えて、レコメンドの多様性など、目標に応じた様々な指標を設定することになります。それらのKPIに基づいて、システムのパフォーマンスを継続的に評価すること、および評価する仕組み作りが求められます。

評価にはオフライン評価とオンライン評価の両方を取り入れ、定量・定性の両面から検証を行います。これらはVAIS:Cが対応していないため、自分たちで行わなくてはなりません。このプロセスを通じて、システムの効果を確認し、必要に応じて改善し、最大限の効果を得られるようにしましょう。

4-4. 注意点

「Vertex AI Search for Commerce の特徴」に記載した内容と表裏一体ですが、マネージドなレコメンドシステムには多くの利点がある一方で、いくつかデメリットも存在します。

まず、アルゴリズムがブラックボックスであるため、内部の処理や詳細な仕組みを理解することが困難です。これにより、サービス独自の特異なニーズや要件に対する細かい調整やカスタマイズが難しくなる場合があります。カスタマイズはデータと設定可能なパラメータの範囲内でしか行えないため、深いレベルでの調整が必要な場合には制約が生じます。

さらに、これらの調整が実際に効果を発揮するかどうかを事前に確信することは難しく、都度オフライン評価やオンライン評価を通じて効果を検証する必要があります。このプロセスは時間とリソースを消費し、即時的なフィードバックも得にくいことがあります。

5. その他Tips

5-1. レコメンドモデル

  • ステータス確認
    • 「クエリの準備完了」が緑で表示されていれば、モデルは利用可能です（トレーニング完了）
    • 自動トレーニングを停止するには、モデルを “Pause” 状態にする必要があります。画面に表示される「モデルは継続的にトレーニング中です」は、モデルがPause状態になっていないという意味です
  • モデルの差し替え
    • サービス構成に紐づくモデルの差し替えは、現時点ではコンソールからは実施できませんが、APIで変更することができます
  • フィルタ等

    • モデル側ではなくサービス構成側で、後処理としてリランキングや多様性の設定ができます

    • データにカラムとして入れておけば、APIのリクエストでフィルタ条件に含めることで、属性やカテゴリでフィルタリングできます

      curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json" \
     -d '  {
             "filter": "availability: ANY(\"IN_STOCK\")",
              "validateOnly": false,
              "userEvent": {
　　　　　"eventTime": "${eventTime}",
                  "eventType": "home-page-view",
                  "visitorId": ${visitor_Id}
                  "userInfo": {
                      "userId": "${user_id}"
                  }},
                 "params": {
                     "returnScore": true,
                     "filterSyntaxV2": true,
                     "strictFiltering": false,
                     "returnProduct": false
                 }
            }' \
     https://retail.googleapis.com/v2/projects/XXXXXXXXXXXXX/locations/global/catalogs/default_catalog/servingConfigs/for-you-recommend:predict

    • expire time などを設定し、アイテムの期限切れの挙動を制御できます

5-2. データセット

  • プロジェクトごとに1つ作成できます。ブランチでデータセットのバージョン管理も可能です（主に検索時に利用か）
  • 複数のソースからのVAIS:Cのイベントデータ連携（BigQueryのGA4から+JavaScriptピクセルを使用してユーザのブラウザから等）
    • イベントの要件として重複データを含めないことが明示されています。そのため、2つの方法で連携する場合には、双方から重複するイベントのインポートが行われないようにする必要があります
  • ユーザーイベントの取り込みについて、公式ドキュメントにあるとおり、eventTime, eventType, visiterID（またはuserID）が同一の場合はイベントがすでに存在すると判定されてスキップされます
  • データ削除は、現状は期間指定でまとめてAPIリクエストで消すしかないようです。データ量が多い場合は時間がかなりかかるので注意が必要です

5-3. ダッシュボード

  • VAIS:Cの管理コンソールには、データインポートの状況やモデル学習ステータス、推奨KPIのトラッキング機能が備わっています
  • A/Bテストの詳細などは自前で管理したほうが柔軟性が高く、BigQueryやLooker Studio、外部ツールを組み合わせてダッシュボードを作ると便利です

6. おわりに

以上が、VAIS:Cを採用したレコメンドシステムの構成概要とTipsです。今回まずはレコメンドをクイックに導入したので、ユーザー行動データを継続的に分析・フィードバックしながら少しずつデータやパラメータを改善し、より高いコンバージョンやエンゲージメントを目指していきます。

今後は検索機能を拡張していく予定です。同じ商品カタログやイベントデータを活用してレコメンドと連携させることで、ユーザに対して一貫性のあるパーソナライズ体験を提供できるようになります。レコメンドと検索の両輪でECサイト全体のUXを底上げし、ビジネス成果に繋げていきたいと思います。

バンダイナムコネクサス／TechBlog
バンダイナムコネクサス／TechBlogPublication

Discussion