リクルートのデータ推進室にて、飲食領域のデータサイエンティストを統括するグループのマネジャー（取材当時。2026年10月

リクルートのデータ推進室長 野村が自ら聞き手となり、現場の最前線で試行錯誤を続けるスペシャリストたちの「手の内」を紐解く連

G-gen の奥田です。当記事は、Google Cloud Next 26 Tokyo の1日目に行われたカスタマーセッション「 CDP だけで顧客理解は不十分？Google Cloud と生活者データで実現する「Why 分析」最前線 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 データはあるのに顧客が見えない データの量ではなく種類が足りない 再発する 5 つの症状 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 勘と経験がもつ 3 つの限界 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは ID 突合ではなく確率的な意味マッチング 処理の 4 ステップ 既存テーブルを変更せずに列が増える Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH 発見 2: Gemini による出力品質の独立検査 発見 3: 承認済みルーティンによる双方の資産保護 Why 分析の先にあるもの AI の均質化とブランドらしさ 業種を越えた共通フレームワークへ 関連記事 セッションの概要 当セッションでは、株式会社博報堂による発表が行われました。CDP（Customer Data Platform、顧客データを個人単位で統合管理する基盤）だけでは捉えられない「顧客が行動した理由（Why）」を、生活者データと BigQuery の機能を組み合わせて補完する手法が紹介されました。 セッションは以下の 5 章で構成されていました。 データはあるのに顧客が見えない Why を補ってきた「勘と経験」の正体 生活者データという「Why の辞書」と Why 分析の方法 Google Cloud だから実現できた 3 つの発見 Why 分析の先にあるもの 当記事では BigQuery の基礎的な説明は割愛します。BigQuery そのものについては、以下の記事を参照してください。 blog.g-gen.co.jp データはあるのに顧客が見えない データの量ではなく種類が足りない セッション前半では、多くの企業が直面する課題として「データ量は十分にあるが、データの種類が足りていない」という点が提示されました。 CDP に記録されるのは、会員属性、購買履歴、行動ログ、解約記録といった「What（結果）」のデータです。一方、価値観、生活文脈、意思決定の傾向、不安や願望といった「Why（原因）」は、CDP のどこにも記録されません。登壇者はこれを氷山にたとえ、水面上に見えるのが What、水面下に隠れているのが Why であると説明しました。 たとえば「妥協して選んだ」という本音は、購買履歴という結果データからは読み取れません。同じ商品を買った顧客でも、買った理由は三者三様です。 再発する 5 つの症状 この構造的な欠落が原因となり、データを精緻化しても再発する症状として、以下の 5 つが挙げられました。 セグメントの画一化 メッセージの一律化 LTV（Life Time Value、顧客生涯価値）向上の頭打ち 静かな離反の見落とし 新規獲得の非効率 登壇者は、CDP や CRM（Customer Relationship Management、顧客関係管理システム）の整備自体は不可欠な土台であり、ID 統合、行動ログの蓄積、施策の自動化という期待された役割は果たしていると強調しました。問題は、CDP だけではカバーできない領域（なぜ買ったのか、なぜ離れたのか、なぜ選んだのか）が存在することです。 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 これまで Why の欠落を埋めてきたのは、マーケターの「勘と経験」でした。セッションでは、その正体は「5W1H を同時に読む力」であると定義されました。 ベテランマーケターは、Who（どんな生活状況か）、When（いま何が起きそうか）、Where（どこで接点を持つか）、Why（なぜその選択か）、How（どう情報収集し選ぶか）を、過去事例の蓄積による暗黙のパターンマッチで同時に推論しています。たとえば「40 代男性が SUV を購入した」という購買データから、「家族の安全を重視する層である」と言い当てる、といった推論です。 勘と経験がもつ 3 つの限界 一方で、この勘と経験には 3 つの構造的な限界があると指摘されました。 スケールしない: 顧客一人ひとりに勘と経験を働かせるのは物理的に不可能 引き継げない: ベテランの退職は「顧客理解資産」の消失を意味する 共有できない: 「なんとなく刺さる」という判断では合意形成が属人的になる 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは この課題に対する解決策として、博報堂が保有する生活者データを「Why の辞書」として使用し、マーケターの脳内プロセスを機械化する手法が紹介されました。材料となるのは、圧倒的な量の Why の語彙と、生活者インサイト（購買行動の背後にある価値観や動機）を推論する技術の 2 つです。 博報堂独自の観点として、価値観、動機、幸福感といった軸（たとえば購入時の価値観として、価格、幸せ、機能性など）が生活者データの中で 5W1H により体系化されています。 ID 突合ではなく確率的な意味マッチング 特徴的なのは、顧客データと生活者データを ID 突合（異なるデータベース間で共通の ID をキーにレコードを結合すること）ではなく「確率的な意味マッチング」で接続する点です。これにより以下の 3 点が実現されます。 個人を特定しない 既存の CDP をそのまま使用できる Cookie 規制（サードパーティ Cookie によるトラッキングの制限）の影響を受けにくい 処理の 4 ステップ 処理は以下の 4 ステップで構成されます。 翻訳: 企業ごとに異なる顧客 CDP の項目を、生活者データの共通言語にマッピングする 数値化: 顧客データと生活者データを「意味の座標」上に配置し、意味の近さを距離として比較できるようにする 検索: 生活者データの中から、意味的に最も近い人を選ぶ 特徴付与: 生活者データに近い特徴を顧客データにも付与する 既存テーブルを変更せずに列が増える この手法の利点は、既存の顧客テーブルを変更する必要がないことです。顧客 ID、属性、購買金額といった従来の列はそのままに、以下のような生活者インサイトの列が追加されます。 価値観（なぜ買うのか。指名買い、コスパ重視など） 意思決定傾向（どう選ぶのか。SNS 影響、即決型など） ライフスタイル（どう生きるのか。都市型ライフ、子育て重視など） 既存の顧客データ基盤が、そのまま顧客理解基盤へ進化するという表現が用いられました。 Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 博報堂独自の生活者データを AI 時代に使用するには 3 つの条件が必要であり、Google Cloud はそのすべてを満たすと説明されました。 意味の近さを計算できる BigQuery が標準機能としてベクトル検索（テキストなどを数値ベクトルに変換し、意味の近さで検索する仕組み）を備えています。 マーケターが直接触れる SQL やダッシュボードで完結し、ノーコードまたはローコードで操作できるため、マーケター自身が仮説をすぐ検証できます。 データを動かさない 顧客データは企業環境から一切出さず、顧客環境内で処理が完結します。 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH セッション後半では、実運用から得られた発見として次の3点が紹介されました。1 つ目は、マーケターの直感を SQL で再現できたことです。「この人は、こんな価値観の人と似ているな」というベテランマーケターの頭の中の処理は、これまで言語化も再現もできない暗黙知でした。この処理を、BigQuery の標準機能である VECTOR_SEARCH 関数への変換（SQL Translation）によって再現しています。 これにより「意味の近さ」が可視化され、感覚でしかなかった判断を数字として表現できるようになりました。 参考 : ベクトル検索の概要 発見 2: Gemini による出力品質の独立検査 2 つ目は、出力品質を Gemini で独立検査する仕組みです。付与されたインサイトが施策の判断材料になる以上、品質に責任を持つ必要があります。人間による品質検査には量的な限界があるため、Gemini による5観点の独立評価を、品質保証レイヤーとして組み込んでいます。これは LLM ジャッジ（Large Language Model による評価）と呼ばれる、大規模言語モデルに出力の良し悪しを判定させる手法です。5 観点は以下のとおりです。 一貫性: 矛盾するタグがないか 妥当性: その人らしいか 網羅性: 必要な観点があるか 不足検出: タグの抜けはないか 実用性: マーケティング施策に使えるか 発見 3: 承認済みルーティンによる双方の資産保護 3 つ目は、データを守りながらロジックも守る仕組みです。顧客データは企業環境から一切出さない一方で、博報堂の推論ロジックも公開しません。この双方の資産保護を、BigQuery の承認済みルーティン（Authorized Routine）で実現しています。承認済みルーティンは、呼び出し元に定義内容を開示せず、実行権限のみを付与できる機能です。 参考 : 承認済みルーティン Why 分析の先にあるもの AI の均質化とブランドらしさ 最終章では、AI エージェントが購買の意思決定を担う時代の展望が語られました。購買が AI エージェント経由になるほど、効率最適化により「どのブランドも同じ答え」に収束するリスク（AI の均質化）があります。 エージェントが最適解を出す時代では、生活者の「なぜ（Why）」への深い理解こそがブランドらしさの源泉であり、ブランドに求められるのは最適化ではなく「選ばれる理由」を持ち続けることである、と締めくくられました。 業種を越えた共通フレームワークへ また、この設計様式は博報堂だけの話ではない、という点も強調されました。ID 突合に依存しないポストクッキー時代（サードパーティ Cookie が使えなくなる時代）のマーケティング手法として、また「データを動かさず、処理を動かす」という厳格なデータガバナンス下で AI 利用を進めるための共通フレームワークとして、規制業界を含むデータを持つすべての企業に波及していくという展望が示されました。対象業種の例として、小売、金融、通信、旅行、メディアが挙げられました。 関連記事 blog.g-gen.co.jp 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh