本日のゴールとアジェンダ

ゴール: (よりブランドを広めたい日用消費財領域メーカーに)
「市場の中のブランド価値」を可視化する
基盤を Google Cloud で構築する

1. 背景/issue
2. ビジネス価値
3. ソリューション・アーキテクチャ
4. 実装計画と次アクション

1. 背景/issue

課題: メーカーは「市場での価値」を知りたい

• メーカーは 自社の売上データは潤沢 に持つ
• しかし 市場相対のビュー が無い
  • カテゴリ内シェア / 競合との差
  • どの購買文脈（CEP）を取れているか
  • マーケティングの成功/失敗の評価

→ 結果マーケ投資が勘と経験に依存し、「どこで伸ばせるか」を数字で言えない

なぜ解けていないか

• データ獲得: メーカー単独ではデータの収集が難しい
  • 市場データ(実店舗ID-POS)は小売・データベンダーが保有
  • 特にIDが紐づく形で定性データは集まらない
• データ理解: データの解釈が難しい
  • 多面的・構造的にデータを活用しきれていない

エビデンス・マーケティング by バイロンシャープ

• ブランド成長は「Physical Availability（買いやすさ）」と「Mental Availability（想起のされやすさ）」が重要
• 成長は「浸透（買う人を増やす）」で決まる
  • ダブルジョパディの法則
• CEP（Category Entry Points） による購買想起の評価
  • 真の競合の発見・理解

参考: ダブルジョパディの法則

大きいブランドほど「買う人が多く」かつ「離反も少ない」— 小さいブランドは二重に不利

目指したい状態: ブランドヘルスレポート

目指したい状態: CEPによる真の競合比較

ブランド比較・真の競合発見のためのHowとしてのCEP

2. ビジネス価値

• 自社データと市場データを統合し、AI readyな基盤を構築
  • 社内の誰でも正しく市場を理解し、商談精度向上
• バイヤーと同等レベルに市場を理解し有利な交渉へ
  • 小売と対等な立場=パートナーとして売上を作る構造
• 浸透率/認知率/購買率 などの指標に変え、マーケの勘を科学する
  • 目標を数値で追う構造構築
  • fact-basedで正しい認知により本質的な改善PDCAへ

3. ソリューション/アーキテクチャ

• Data & Analytics - Cloud Composer/BigQuery
  • 市場可視化
• ML — 購買予測 - Vertex AI/BigQuery ML
  • CEP分類 / 購買予測 / 広告接触
• GenAI — Gemini
  • ブランドヘルス・レポート生成＆自然言語QA

アーキテクチャ1: 処理の流れ（論理ビュー）

アーキテクチャ2: システム構成（物理ビュー）

proof of value: PoCで実証すること

1. カテゴリの市場データを 自社内で統合
2. CEPを定義し、CEPごとの売上上位10＋自社の順位を評価
3. 単独ブランドの 強み/弱みCEP を可視化 → 次に打つCEP を提示
4. 浸透率/認知率などのKPIに定量化、改善サイクルを設計
5. GenAI が 要約レポート を自動生成(+補助予測)

CEO 向け: 成長と差別化

CTO 向け: 運用・リスク・拡張

開発チームをどこにbetするか？会社資産になりうる基盤は？

→ まずは基盤の設計から小さく始める

4. 実装計画と次アクション

対象=1ブランド / CEP約10 / 競合=各CEPで売上上位約10

最小構成・ロールバック可能・低コスト。次に打つCEPを実データで選べる状態に

松竹梅: スコープと優先順位

不確実性の高い順に潰し、効くか → 回るか → 広げるの順にスコープを広げる

コスト試算

• BigQuery は スキャン量課金
  • オンデマンド $7.5/TiB(東京)・月初1TiB無料・時間課金なし
• 梅(PoC)規模＝極小: 小mart+キャッシュでサービングはほぼ$0
• 全社利用の参照値(10TB/高頻度/全社): mart+キャッシュで 月 ≈ $1,000〜1,800
  • 周辺(Dataflow/Composer/Vertex/Gemini/Looker)込みで上振れ
• 守りの設計: パーティション/クラスタリング

次アクション(お願い)

1. PoC（〜8週）の Go を ◯月◯日までに
2. 合否は 3指標 で合意
   • CEP約10 × 各CEP競合上位10 を市場感と整合的に再現
   • 自社の 強み/弱みを1画面で説明できる
   • 次に打つ方針をマーケが意思決定できる
3. 来週、半日の技術ディスカバリ・ワークショップ
   • 参加: データ / マーケ / セキュリティ ＋ 当方CE

Q&A: パネルデータを買えば済むのでは？

• 市場に存在する多くのパネルデータは小規模人数の購買データを拡大推計したものです
  • 特に新商品や成長中のSKU/ブランド単位のデータは見たいものが見られない可能性が高いです
  • 一次情報を正確に把握するためにも、基盤となるデータは自前整備を推奨します

Q&A: 予測は本当に当たる？

• 「必ず当たる」ことは保証できません。だから小さく試しましょう
  • 必ず簡単な予測で手応えを確認 → 必要なら高度化
• 予測はあくまで補助: 主役は「市場内自ブランド評価」の見える化

Q&A: なぜ Google Cloud か

• データ→ML→GenAI が1枚のサーバーレス基盤
• BigQuery ML=SQLだけで簡易予測が即日
  • PoC立ち上がりが最速
• リテールメディア直結の武器
  • Analytics Hub / ADH（広告のクリーンルーム計測）
• 活用の補助機能が揃う — Looker / BigQuery MCP

重心が データ×AI×広告計測 だからGoogle Cloudが素直

Q&A: なぜ BigQuery?(Snowflake?)

判断軸はコスト管理と他のコンポーネント連携が中心

• Snowflakeは時間課金、BigQuery(オンデマンド)はスキャン量課金
  • 使いたい人が使いたいときに使う環境ではBigQueryがコスト有利
• 他機能との連携
  • 広告接触可否の分析などの場合、ネイティブ統合されたGoogle Cloudに閉じて実装ができるのは大きな利点
• 本件は データ集計/ML/広告を一気通貫がbetter → BQが素直

Appendix: CEP データ処理ワークフロー

「小さく始める」MVPの処理系（Composer DAG 相当）

取込    : 市場ID-POS / 自社EC / アンケート / レビュー / 商品マスタ → raw
整形    : 名寄せ・正規化（JAN統一・ブランド・buyer id）→ core
CEP定義 : レビュー→Gemini抽出→約10CEP →(アンケートでサイズ&想起=Mental)
CEP→SKU : 各SKUをCEPに分類（Gemini＋商品属性）= bridge sku_cep
集計    : purchase × sku_cep → CEP×ブランド売上 → 各CEP上位10＋自社順位
出力    : 強み/弱み → 次アクション（大×弱CEP）→ Gemini要約 ＋ 予測(補助)

CEPは2系統で測る: Physical＝購買×(CEP→SKU) ／ Mental＝アンケート(CEP→ブランド想起)