Recommendations AI

Recommendations AI（現在は Vertex AI Search for commerce / Retail API の一機能）は、EC サイト向けのパーソナライズされた商品レコメンドを、機械学習の専門知識やモデル構築なしで導入できるマネージドサービスです。商品カタログとユーザーの行動イベント（閲覧・カート追加・購入など）を送ると、Google が推薦モデルを自動で学習・運用し、状況に応じたおすすめ商品を返します。

解決する課題

• EC サイトにパーソナライズされた商品レコメンドを入れたいが、推薦システムを自前で設計・学習・運用する余力がない
• 「あなたへのおすすめ」「この商品を見た人はこちらも」のような枠を作りたいが、協調フィルタリングなどの実装が重い
• カートや商品詳細でのクロスセル・アップセルを強化して、コンバージョン率や客単価を上げたい
• レコメンドの精度を継続的に改善したいが、モデルの再学習やチューニングの運用負荷を抱えたくない

主要概念と用語

• 商品カタログ (Product Catalog): レコメンド対象となる商品の情報（ID・名称・カテゴリ・価格・在庫など）。Merchant Center 連携や API 取り込みで登録する
• ユーザーイベント (User Event): 閲覧・検索・カート追加・購入などのユーザー行動。モデルの学習と推論の入力になり、量と質が精度を大きく左右する
• 配置 (Placement / Serving Config): レコメンドを表示する場所（ホーム・商品詳細・カートなど）に対応する設定。どのモデルでどう返すかを束ねる
• 推薦タイプ (Recommendation Type): 「あなたへのおすすめ」「関連商品」「よく一緒に買われる商品」など、目的別のモデルの種類
• 最適化目標 (Optimization Objective): クリック率（CTR）・コンバージョン率（CVR）・収益などのうち、何を最大化するようモデルを最適化するか
• モデルの学習・チューニング: 蓄積されたイベントとカタログから Google が自動でモデルを学習・更新する。利用者はアルゴリズムを直接実装しない
• A/B テスト / 実験: レコメンドあり・なしや配置の違いを比較し、効果を定量評価する仕組み

仕様・制限・クォータ

• 入力は大きく商品カタログとユーザーイベントの2系統。カタログは API での取り込みや Merchant Center / Cloud Storage / BigQuery からのインポートに対応する
• ユーザーイベントはリアルタイム送信と過去ログの一括インポートの両方が可能。一定量以上の履歴がモデル学習に必要で、データが少ないと精度が出にくい
• モデルの学習・更新には一定の時間がかかり、登録直後に高精度の結果が出るわけではない。十分なイベント蓄積期間を見込む
• 商品数・イベント数・リクエストレートには**プロジェクト単位の上限（クォータ）**があり、大規模利用では引き上げ申請を行う
• 具体的な必要イベント数・学習時間・レート上限・対応リージョンは変動するため、利用前に公式ドキュメントで最新値を確認する

内部の仕組み

利用者から見ると、このサービスはカタログとイベントを入れると推論エンドポイントが生えてくるマネージド基盤です。蓄積された商品カタログとユーザーイベントをもとに、Google 側が推薦モデルを自動で学習し、配置（Serving Config）ごとに「次に表示すべき商品」を返します。協調フィルタリングや系列モデルといったアルゴリズムの選択・チューニング・スケーリングはすべて Google が管理し、利用者はデータ供給と配置設計に集中します。

推論時には、リクエストに含まれる現在のユーザー・閲覧中の商品・コンテキストと、これまでのイベント履歴を組み合わせて、最適化目標（CTR / CVR / 収益など）に沿った並びで商品を返します。モデルは新しいイベントを取り込みながら継続的に更新されるため、季節性やトレンドの変化にも追従します。

設計パターン / ベストプラクティス

• イベント計測を先に固める: 閲覧・カート追加・購入などを漏れなく正確に送る計測基盤を最初に整える。後からの補正は難しい
• 過去ログを一括インポートして初速を出す: 既存のアクセスログ・購買履歴を取り込むと、ゼロから貯めるより早く実用精度に届く
• 配置ごとに推薦タイプと目標を選ぶ: ホームは「あなたへのおすすめ」、商品詳細は「関連商品」、カートは「よく一緒に買われる商品」など、枠の目的に合わせて使い分ける
• A/B テストで効果を定量化: レコメンドあり・なしや配置違いを比較し、CTR や収益で効果を検証してから全面展開する
• カタログを最新に保つ: 在庫切れ・廃番・価格変更を反映し、表示できない商品を出さないようカタログ同期を自動化する

運用・監視

• Cloud Monitoring でレコメンド API のリクエスト数・エラー率・レイテンシを可視化し、表示遅延や障害を早期に検知する
• 推薦の効果指標（CTR・CVR・収益貢献など）はコンソールの分析機能や BigQuery へのエクスポートで継続的に追跡する
• ユーザーイベントの取り込み状況・欠損・形式エラーを監視し、計測の不具合を放置しない
• レート上限超過に備え、クライアント側は指数バックオフによる再試行とタイムアウトを実装する
• カタログ同期やイベント送信のパイプライン障害を検知できるよう、アラートを設定する

コスト

• 課金は概ね予測（レコメンド取得）のリクエスト量を中心に決まり、データの取り込みや学習の扱いはプランにより異なる
• 大量のイベントを送ること自体はモデル精度の前提であり、送信を惜しんで精度を落とさないバランスが重要
• 無料枠の有無や単価は変動するため、見積もりは公式の料金ページで確認する
• 効果の薄い配置を見直す、不要な大量取得を避ける、A/B テストで投資対効果（売上向上分とコスト）を見ながら拡大する、といった運用でコスト効率を保つ

セキュリティ

• アクセスはサービスアカウントと IAM で認可し、API キーや鍵のハードコードを避ける。プリンシパルには利用に必要な最小権限だけを付与する
• ユーザーイベントには行動履歴が含まれるため、個人を特定しうる情報の扱いに注意し、識別子は必要最小限・仮名化を検討する
• ネットワーク境界を固めたい場合は VPC Service Controls でデータの流出経路を制限する
• 監査ログを有効化し、誰がカタログやイベントを操作・取得したかを追跡可能にする
• 取り込むデータの保持期間やアクセス範囲をプライバシーポリシー・規制に沿って定める

関連サービス・比較

• 同じ Google Cloud では、商品検索の関連機能である Vertex AI Search for commerce（Retail Search） と同じ基盤に属し、検索とレコメンドを併用できる
• 汎用の機械学習でレコメンド以外も含めて柔軟に作りたい場合は Vertex AI でカスタムモデルを構築する選択肢があるが、定型の EC レコメンドはこのサービスの方が導入・運用コストを抑えやすい
• イベントの蓄積・分析基盤として BigQuery、計測データの中継に Pub/Sub を組み合わせるのが定番

ハンズオン / CLI例

# 1) Retail API を有効化（プロジェクトで一度だけ）
gcloud services enable retail.googleapis.com

# 2) 認証用のアクセストークンを取得して REST を直接呼ぶ
ACCESS_TOKEN=$(gcloud auth print-access-token)
PROJECT_ID=$(gcloud config get-value project)

# 3) レコメンド（予測）を取得する：商品詳細ページ向けの配置に対し、
#    現在のユーザーと閲覧中商品のコンテキストを渡す
cat > predict.json <<'EOF'
{
  "userEvent": {
    "eventType": "detail-page-view",
    "visitorId": "visitor-001",
    "productDetails": [
      { "product": { "id": "product-123" } }
    ]
  }
}
EOF

curl -s -X POST \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  "https://retail.googleapis.com/v2/projects/${PROJECT_ID}/locations/global/catalogs/default_catalog/placements/recently_viewed_default:predict" \
  -d @predict.json