2026.05.22 コラム
【テックコラム】AI Commerce Search 導入方法 第2回 ~データ準備・設計編~
AI Commerce Search（旧Vertex AI Search for Commerce）とは
こんにちは、DataCurrent の不破です。
今回は、Google Cloud が ECサイト向けに提供するAIサービス「AI Commerce Search」についてご紹介したいと思います。旧サービス名は「Vertex AI Search for Commerce（略して「VAIS:C」）」でしたが、ちょうど本記事を執筆していた2026年4月下旬に「AI Commerce Search」に変更されました。
ECサイトにおいて、ユーザーが迷わずお目当ての商品を見つけられる環境を整えることは、ショップのファンを増やし、売上を伸ばしていくための第一歩です。昨今の生成AIの普及によって検索の精度が劇的に進化しました。単なる言葉の照合ではなく、検索の背景にあるユーザーの意図や行動履歴を深く理解することで、まさに「いま欲しかった商品」をピンポイントで届けられるようになってきました。
Google Cloud の AI Commerce Search は、長年 Google が培ってきた検索技術と最先端のAI技術を駆使して、まさに上記のようなリッチなEC体験を提供することを可能にします。個々のユーザーにパーソナライズされた、より精度の高い検索体験を提供することで、ECサイトのクリック率やコンバージョン率の向上に貢献することができます。また検索だけでなく、同様に生成AIに下支えされた高度なレコメンデーションの提示も可能です。
本記事では、AI Commerce Search の公式ドキュメント、および弊社の導入ご支援経験に基づいて、AI Commerce Search の検索機能の概要と具体的な実装方法についてご紹介します。
本連載は全5回にわたって解説します。
- 第2回：データ準備・設計編（★本記事）
※この記事は、2026年4月時点に執筆したものであることをご留意ください。
目次
- 商品カタログのインポート
a. 商品カタログとは
b. 商品カタログの構造
c. プライマリ-バリエーション構造の注意点
d. プライマリのみ構造の注意点
e. 商品カタログのインポート方法
f. ブランチの概念
- ユーザーイベントのインポート
a. ユーザーイベントの種類
b. ユーザーイベントの要件
c. ユーザーイベントの計測に必要なその他の要素
d. 過去のユーザーイベントのインポート方法
e. リアルタイムのユーザーイベントの計測方法
f. GTMでのリアルタイムユーザーイベントの計測方法
AI Commerce Search を始めるために必要なデータ
AI Commerce Search を利用開始するために必要となるデータは大きく2種類で、「商品カタログ」データと「ユーザーイベント」データです。AI Commerce Search の「検索機能」も「レコメンデーション機能」も利用するデータは同じであるため、各機能でそれぞれインポートを行う必要はありません。
商品カタログのインポート
AI Commerce Search の「検索機能」「レコメンデーション機能」共に、商品カタログの準備が必須となります。商品カタログには、商品のIDや名前、カテゴリ情報、在庫情報、価格情報等が含まれ、常に最新の状態に更新し続ける必要があります。「商品カタログ」を AI Commerce Search にインポートすると、検索機能が利用できるようになります。ただしその場合、検索結果の精度は検索キーワードと商品の関連性に基づくものに留まります。ユーザーの行動データに基づいてパーソナライズされた検索結果を表示したい場合や、レコメンデーション機能を実装したい場合は、「商品カタログ」に加えて「ユーザーイベント」のインポートが必要不可欠です。
商品カタログとは
サイトで販売している商品の詳細情報です。AIが「何が売られているか」を理解し、適切な商品情報をAPIで返却するための基盤となります。商品カタログのデータは、AI Commerce Search が定義するスキーマに則って用意する必要があります。
– 必須項目
- id：商品ID（カタログ全体でユニークなID）
- title：UI上に表示する商品名
- categories：商品カテゴリ名（例：[“ファッション>トップス>ブラウス”]）
- name：商品リソース名（※インポート時に自動生成されるため指定は不要）
– 推奨項目
- brands：ブランド名
- description：商品の説明文
- attributes：キーバリュー形式のカスタム属性情報
- priceInfo：価格情報
- uri：商品詳細ページURL
- images：商品画像情報（画像URL等）
- sizes：サイズ
- materials：素材
- availability：在庫情報
- etc…
必須項目以外にも推奨項目に記載のような、より具体的かつ正確な商品情報を多く提供すればするほど、モデルの品質が高くなります。また AI Commerce Search は、商品カタログに登録された商品詳細ページURL（uri）に自動的にアクセスしクロールすることで、商品の理解を深め検索の品質を向上させているため、こうした情報を提供することも重要です
商品カタログの構造
AI Commerce Search で商品カタログを管理する際は、商品データ毎に商品タイプを指定します。
– 3つの商品タイプ
- プライマリ（PRIMARY）
親アイテム。検索結果やレコメンデーションで、代表として表示されるメインの商品データ
- バリエーション（VARIANT）
子アイテム。親アイテムに紐づく、具体的な「色・サイズ」違いのデータ
- コレクション（COLLECTION）
関連商品のセット。複数の商品を一つのグループとしてまとめたもの
商品タイプを使い分けることで、商品データを親子構造で管理したり、商品データを単体で個別に管理したりすることができます。どの商品タイプでどのようなカタログ構造にするかによって、APIのレスポンス構造やモデル学習の精度が変わるため、既存のサイトの仕様に合わせて慎重に検討する必要があります。
– 組み合わせパターン
- プライマリ-バリエーション
親子構造。「商品の型（親）」と「サイズ or 色単位（子）」を分けて管理するパターン
- プライマリのみ
全ての商品をプライマリとして並列で管理するパターン
- コレクション-プライマリ
「寝室セット（シーツ・枕・ライト）」等、複数のプライマリ商品を任意のセットで管理するパターン
プライマリ-バリエーション構造の注意点
商品データに親子関係がある場合は、「プライマリ-バリエーション」構造を採用することが第一候補として考えられます。商品カタログを親子構造にすることで、AI Commerce Search は親子の商品群を一つの商品グループとして認識できるようになり、各バリエーション（子）で発生した購入などの実績をプライマリ（親）に集約して学習できるため、商品グループ全体としての評価を効率的に高められるというメリットがあります。
ただし、注意が必要なのは「検索APIで取得可能なバリエーションの個数が、1つのプライマリにつき最大5個まで」という制限があることです。検索APIは基本的に親のプライマリ（親）単位で返却されます。「プライマリ-バリエーション」構造の場合、バリエーション（子）の情報はプライマリ（親）にぶら下がる形でネスト形式で返却されますが、検索APIからは上位5件のバリエーションしか返却されないため、バリエーションを全件取得することはできません。また、検索APIによってサポートされるページネーションやヒット件数といった機能も基本的に返却されたプライマリ（親）の個数に基づくため、バリエーションの個数に基づいたページネーションやヒット件数の管理が難しくなります。全てのバリエーション商品を並列で検索結果に表示するようなUIの場合、「プライマリ-バリエーション」構造を採用すると、既存のUIの維持が難しくなる可能性がありますのでご注意ください。逆に言えば、検索結果ではプライマリ（親）のみを表示し、商品詳細ページでバリエーション（子）を展開するようなUIの場合に、「プライマリ-バリエーション」構造の採用が向いているとも言えます。
プライマリのみ構造の注意点
全ての商品データを並列に管理する「プライマリのみ」構造の場合は、「プライマリ-バリエーション」構造で挙げたようなAPIの制限は無くなるため、柔軟なUI設計が可能になります。ただし、もし実態として商品データに親子関係があり、それを「プライマリのみ」構造で管理する場合には注意が必要です。上述の通り「プライマリ-バリエーション」構造の場合は、各商品に溜まった実績が親子全体でシェアされるため、商品の評価をより正しく効率的に高められますが、「プライマリのみ」構造の場合、各商品はあくまで独立した関係性となるため、親子関係による学習の波及効果が望めないというデメリットがあります。
いずれの構造のパターンもメリット・デメリットがありますので、それぞれを理解した上で、商品カタログの構造を検討されることをお勧めします。
商品カタログのインポート方法
商品カタログをインポートする方法としては、以下の選択肢があります。商品カタログはコンソール画面上で手動でインポートすることもできますが、本番環境では前述の通り最新の情報に更新し続ける必要があるため、それを考慮したワークフローの設計が必要です。
- BigQuery
- Cloud Storage
- API（Product.import メソッド）
商品カタログをインポートすると、AI Commerce Search の管理画面上で実際にインポートした商品データの一覧を確認することができます。
（※イメージはサンプルです）
ブランチの概念
AI Commerce Search には商品カタログを入れる「箱」として「ブランチ」という概念があり、1つのプロジェクトにつき3つ（ブランチ0〜2）まで利用することができます。3つのブランチのうち1つを「デフォルトブランチ」として指定し、そのブランチがAPIの対象ブランチになります。開発環境で複数パターンの商品カタログを試したい場合、複数のブランチに分けて商品カタログをインポートし、デフォルトブランチを切り替えて検証することができます。ただし、本番環境において、特にレコメンデーションなどモデル学習に基づく機能を利用する場合は、ブランチの切り替えを行うことでモデルの学習に悪影響を与える可能性があるため、複数ブランチの利用が推奨されていません。本番環境では単一のブランチをデフォルトブランチとして利用し、ブランチの切り替えを行わない運用が推奨されます。
・参考：
https://docs.cloud.google.com/retail/docs/catalog?hl=ja
https://docs.cloud.google.com/retail/docs/attribute-config?hl=ja
https://docs.cloud.google.com/retail/docs/upload-catalog?hl=ja
https://docs.cloud.google.com/retail/docs/manage-catalog?hl=ja
ユーザーイベントのインポート
関連性のみの検索機能は「商品カタログデータ」のみでも動作しますが、検索精度を向上させたい場合や、レコメンデーション機能、絞り込み条件のサジェスト機能（タイルナビゲーション）、検索キーワードのサジェスト機能（予測入力）など、モデル学習に基づく AI Commerce Search の機能を利用したい場合は、「ユーザーイベント」のインポートが必要です。ユーザーイベントの取得については、「過去」に蓄積されたイベントデータを一括インポートするタスクと、現在進行形でサイト上で発生しているイベントデータをリアルタイムに計測するタスクの2種類があることにご注意ください。
ユーザーイベントの種類
AI Commerce Search で計測可能なユーザーイベントには、次の種類があります。既にGA4でeコマースイベントを計測している場合は、そのデータを流用できるケースがあります。AI Commerce Search の各イベント名の概要と、それに対応する GA4 のeコマースイベント名は以下の通りです。注意点として、表内の GA4 対応イベントは標準イベントではないため、別途カスタム実装が必要となりますのでご注意ください。
| AI Commerce Search イベント名 | ユーザーの操作 | GA4 対応イベント名 |
|---|---|---|
| search | 商品カタログの検索とブラウジング | view_item_list + [searchQuery または pageCategories + filter] |
| home-page-view | ホームページの表示 | view_homepage |
| detail-page-view | 商品詳細ページの表示 | view_item |
| add-to-cart | 商品をカートに追加 | add_to_cart |
| purchase-complete | 商品の購入手続きを完了 | purchase |
| category-page-view | セールページやプロモーションページなどの特別なページの表示 | view_item_list + pageCategories |
| shopping-cart-page-view | ショッピングカートの表示 | view_cart |
ユーザーイベントの要件
ユーザーイベントには、満たすべき一般的な要件や、検索固有の要件、レコメンデーション固有の要件、レコメンデーションモデル固有の要件など、細かな要件が定義されています。イベントデータの要件が満たせていないと、以下のようなことが想定されます。
- イベントデータ取り込み時にエラーとなる
- 検索の精度が上がらない
- レコメンデーションモデルが作成できない
- 予測入力APIの自動学習データセットが生成されない
- 検索APIの動的ファセット機能やタイルナビゲーション機能が利用できない
イベントデータの取得を進める際には、事前に公式ドキュメントに目を通し、要件や仕様を把握した上で実施することをお勧めします。
ユーザーイベントの計測に必要なその他の要素
– アトリビューショントークン
- 検索APIから返却されたアトリビューショントークンを、ユーザーイベントに含める必要があります。これにより、検索結果に表示された商品に対するユーザーの後続のインタラクションを AI Commerce Search が追跡することができます。
– ビジターID
- 一意のユーザーをトラッキングするためのセッションIDの計測が必要です。GA4を使用している場合は、GA4のCookie「_ga」の値を訪問者IDとして計測することもできます。
– ユーザーID（任意）
- ユーザーIDは必須ではありませんが、ログインユーザーのIDを追加で計測することにより、AI Commerce Search によるパーソナライズの精度を高めることができます。
過去のユーザーイベントのインポート方法
過去のユーザーイベントを一括インポートする方法としては、以下の選択肢があります。
- BigQuery
- Cloud Storage
- API（userEvents.import メソッド）
GA4やGA360で既に「eコマースイベント」を計測している場合は、GA4のアクセスログをBigQueryにエクスポートし、GA4スキーマのままBQテーブルのデータを AI Commerce Search に取り込むことができます。過去データの一括インポートは基本的に一度だけ行います。
リアルタイムのユーザーイベントの計測方法
リアルタイムのユーザーイベントを計測する方法としては、以下の選択肢があります。ブラウザで発生するイベントについてはGTM経由、アプリで発生するイベントについてはAPI経由で計測する等、ケースバイケースで計測方法を分けることも考えられます。
- JavaScriptピクセル
- Google タグマネージャー（GTM）
- API（userEvents.write メソッド）
GTMでのリアルタイムユーザーイベントの計測方法
– dataLayer 変数の実装
GTMでユーザーイベントを計測する場合は、事前にサイトのフロントエンド側で GTM の dataLayer 変数を実装する必要があります。dataLayer 変数の実装方法については、「GA4 の eコマース」のスキーマで実装するパターンと、「Cloud Retail（AI Commerce Search）」のスキーマで実装するパターンの 2 通りがあります。既に「GA4 の eコマース」のスキーマで dataLayer 変数が実装されている場合は、その内容を流用できるケースもあります。
– Cloud 小売（Cloud Retail）タグの設定
GTMには「Cloud 小売」タグという AI Commerce Search 計測用のタグテンプレートが用意されており、このタグをGTMに追加設定することで、AI Commerce Search へのイベント計測が比較的容易に実装できます。「Cloud 小売」タグには、計測先のプロジェクト番号と、そのプロジェクトから発行したAPIキーを設定します。APIキーはGCPコンソール画面の「API とサービス > 認証情報」から新規APIキーを作成することができます。APIキーの作成時には、アクセス可能なAPIとして「Google Analytics Data API」と「Vertex AI Search for commerce API」を選択し、指定したサイトからしかリクエストを受け付けないようウェブサイトの制限を設定することをお勧めします。（認証情報の画面上部には「OAuth同意画面を構成してください」という旨のアラートが表示されますが、今回の用途ではOAuth認証を使用しないため、対応は必要ありません。）
・参考：
https://docs.cloud.google.com/retail/docs/user-events?hl=ja
https://docs.cloud.google.com/retail/docs/import-user-events?hl=ja
https://docs.cloud.google.com/retail/docs/record-events?hl=ja
https://docs.cloud.google.com/retail/docs/implement-user-events?hl=ja
https://docs.cloud.google.com/retail/docs/attribution-tokens?hl=ja
https://docs.cloud.google.com/retail/docs/manage-user-events?hl=ja
データインポートに関するTips
データインポート時の注意点
– 商品カタログとイベントデータのインポートの順序に注意
AI Commerce Search は、ユーザーイベントをインポートすると、ユーザーイベントに含まれる商品IDと、既に AI Commerce Search にインポートされている商品カタログ内の商品IDを結合しようとします。商品カタログに存在しない商品IDがイベントに含まれる場合、そのイベントは正しく商品カタログに関連付けられません。このため、順番としては AI Commerce Search に①商品カタログをインポートしてから→②ユーザーイベントをインポートする必要があります。また、ユーザーイベントに含める商品IDは、商品カタログ内の商品IDと一致させる必要があります。
・参考：https://docs.cloud.google.com/retail/docs/record-events?hl=ja#bps
– 過去ユーザーイベントのインポートは必須ではない
過去のユーザーイベントをインポートすることで、AI Commerce Search の学習スピードを早められるというメリットがあります。一方で、もし過去データに AI Commerce Search 対象のイベントデータ（search、detail-page-viewなど）が計測できていない場合は、必ずしも過去データをインポートする必要はありません。その場合は新たに AI Commerce Search 向けのイベントデータが計測できるように、リアルタイムのユーザーイベントの計測実装を進めます。
– 検索イベントと後続イベントの紐づけには一貫したIDの受け渡しが必要
検索精度を高めるためには、同じユーザーが「検索→詳細閲覧→カート追加→購入」とカスタマージャーニーをたどった際に、検索イベントで計測したものと同じビジターID・商品IDを、後続のイベント（商品閲覧・カート追加・ショッピングカート閲覧・購入）にも受け渡す必要があります。これによって、AI Commerce Search は同一ユーザーによって発生した検索イベントと後続のイベントを紐づけることができ、AI Commerce Search の検索から後続のアクションに繋がった商品に対して実績が溜まっていきます。
データインポートの全体構成イメージ例
各データを下記構成でインポートする場合の全体構成イメージ例をご紹介します。インポート手法によって全体構成は変わりますが、一例としてご参考ください。
（例）
- 商品カタログ
- 基幹DB→BigQuery→AI Commerce Search
- 過去のイベントデータ
- GA4→BigQuery→AI Commerce Search
- リアルタイムのイベントデータ
- GTM→AI Commerce Search
まとめ
商品データとユーザー行動ログをどのように紐づけるか、その設計がAIの精度やモデルの品質を左右します。データの準備が整ったら次は最終ステップです。第3回では、AI Commerce Search のパフォーマンス指標となる「Tier」の考え方と、実際のAPI実装例をご紹介します。
▶ [第3回：実装編（パフォーマンス階層やコンソール画面の設定、検索APIの実用ケース）はこちら]
最後に
自社に専門人材がいない、リソースが足りない等の課題をお持ちの方に、エンジニア領域の支援サービス（Data Engineer Hub）をご提供しています。 お困りごとございましたら是非お気軽にご相談ください。
本件に関するお問い合わせは下記にて承ります。
株式会社DataCurrent
info@datacurrent.co.jp