データ基盤・CDP・BigQuery

CDP（Customer Data Platform、顧客データ基盤）は「社内に散らばっている顧客データを1か所に集めて、マーケティング・営業・経営の意思決定に使える形に整える」システムです。

身近な例で言うと、こんな状態を解消するためのもの: 「ECサイトで購入した顧客」と「実店舗で購入した顧客」が別の顧客として扱われている／メルマガが既購入顧客にも同じ内容で届く／営業が顧客のWeb閲覧履歴を見られない／「LTVの高い顧客層」を聞いても誰も答えられない。これらは顧客データが各システムに分散していて統合されていないことが原因です。

CDPがやることは大きく3つ: (1) データを集める(EC・店舗POS・CRM・メールマーケ・広告・コールセンター・サイトログなど複数システムから)、(2) 同じ顧客のデータを統合する(名寄せ)、(3) 使える形に整える(マーケのセグメント抽出、広告連携、レコメンドなど)。CDPは定義が曖昧でベンダーごとに提案が大きく異なる領域なので、「自社に合うか」を判断する基礎知識から押さえるのが安全です。詳しくはCDPとは何か｜発注検討者のための基本と「ベンダー提案を読み解く」ための知識を参照してください。

「箱は作ったが活用されない」状態が3つの典型パターンとして起きます。データ統合だけが目的化／マーケ部門との分断／運用継続できない、の3つです。

代表的な症状: (1) CDPの管理画面を毎日見る人がいない、(2) セグメント作成は情シスがリクエスト受付式で対応し、マーケが直接使えない、(3) 「で、これで売上はどう変わったのか?」を経営層に聞かれて答えられない、(4) 追加機能要望が出ず塩漬けシステム化していく。多くの場合、技術的な失敗ではなく組織と運用の設計不足が原因です。

回避策: (a) マーケ施策のKPIから設計する(LTVを5%上げる、離反率を10%下げる、など、CDPで何を達成するかを最初に決める)、(b) 3〜5個の具体施策を構築前に決める(休眠顧客掘り起こしメール、商品レコメンド精度向上など、CDP公開初日に動かす施策をリスト化)、(c) マーケ責任者をプロジェクトの共同オーナーに。詳しくはCDP導入で失敗する3パターンと回避策を参照してください。

選定時にほぼ必ず比較される3パターンが、Treasure Data／Salesforce CDP（Data Cloud）／自社開発です。機能・コスト・運用負荷・拡張性で見ると向き不向きが分かれます。

大まかな性質: (1) Treasure Data(国内導入実績が多い専業ベンダー製。日本のツール対応に強く、マーケ向け画面操作が前提)、(2) Salesforce CDP(SalesforceのCRMとの連携が圧倒的、業界別データモデルあり、グローバル製品)、(3) 自社開発(BigQuery／Snowflake／Databricks などを土台にCDP機能を組む。柔軟性が高い分、データ収集コネクタや名寄せロジックを自前実装する工数が大きい)。

選定の判断軸は「マーケ部門が画面操作で使うか／SQLが書けるアナリストが運用するか」「既存の社内データ基盤との親和性」「データソース・出力先の数」「リアルタイム性の要求水準」。詳細な比較表はCDP製品の選び方｜Treasure Data・Salesforce CDP・自社開発の比較と選定基準を参照してください。

CDPは要件次第で2桁以上コストが変わるシステムです。「数百万円から」と「億単位」のどちらの記述も正しい、という構造を理解した上で見積もりを取る必要があります。

費用を左右する5つの要因: (1) 顧客数とデータ量（10万件と500万件で月額利用料が大きく違う）、(2) つなぐ元データの数（ECサイト1本だけか、CRM・MAツール・POSレジ・コールセンター・Webアクセスログまで含むか）、(3) 更新頻度の要求（1日1回か秒単位か）、(4) 連携先（出力先）の数、(5) 個人情報保護の要求水準。

月額制サービス型CDP（Treasure Data／Salesforce CDPなど）の中堅企業の目安: 初期構築費用 800万〜3,000万円、月額利用料 600万〜3,000万円（年額換算）、運用保守 300万〜1,200万円（年額）。「CDPを入れるだけ」と思っていたら、最終的に2倍3倍のコストになるのが典型です。詳しくはCDP（顧客データ基盤）構築の費用と期間の目安を参照してください。

BigQuery（ビッグクエリー）は、Google Cloud が提供する「大量のデータを保存して高速に検索・集計できるサービス」です。一言で言うと「クラウド上のデータ倉庫」です。

業務利用の代表的な用途: (1) GA4（Google アナリティクス）のサイトアクセスデータを溜めて長期分析、(2) 社内の販売データ・顧客データ・基幹システムのログを統合して横串で分析、(3) 営業・マーケ・経営の意思決定に使うレポート・ダッシュボードの土台、(4) 顧客データ基盤（CDP）の中核。BigQuery は数億〜数百億行のデータでも、SQLクエリを投げれば数秒〜数十秒で結果が返ります。

ベンダー提案で「BigQuery を土台に構築します」と出てきたら、BigQuery単体は データ倉庫 でしかなく、CDPや分析環境として機能させるには周辺ツール・運用体制を含めた総合判断が必要と理解しておくと良いです。詳しくはBigQueryとは｜データ基盤を発注検討する情シス・経営層が押さえる判断軸を参照してください。

BigQuery は「使った分だけ払う従量課金」なので、初期見積もりだけでは判断できないコスト構造です。「月数万円から始められます」と言われたが運用に入ったら月30万円の請求が来る、という事故が頻発しています。

3つの課金軸: (1) データ保管料(BigQuery に置いているデータ容量×期間／1GBあたり月3〜6円)、(2) クエリ実行料(SQLを実行したときに処理するデータ量／1TB処理あたり約1,000円)、(3) 取り込み・転送料(外部からデータを流し込む量・経路。標準取り込みは無料、リアルタイムは別途課金)。大事なのは「どれだけのデータを置くか」より「どれだけのデータを読みに行くクエリを実行するか」が圧倒的に料金を左右すること。

請求暴発の典型は、(a) フルスキャンクエリ（テーブル全体を読むSQL）が定期実行されている、(b) 開発者がうっかり大量データを処理する操作を本番環境で行った、(c) BIツールが裏で大量にクエリを発行している。料金の軸・現実的な月額目安・予算管理項目はBigQuery 料金を発注検討時に正しく見積もるを参照してください。

「すでに使っているBigQueryを発展させてCDPにする」選択は、日本の中堅企業で増えています。理由は単純で「すでに使っている／使ったことがある会社が多いから」です。

大前提として、BigQuery 単体は CDP ではありません。BigQuery は「データ倉庫」であり、CDP として機能させるには上に複数の層を組み合わせる必要があります。具体的には: データ収集（Fivetran／trocco／Embulk／自前バッチ）、顧客IDの統合（独自SQL設計／dbt 等のSQL運用ツール）、セグメント作成（Looker／Census／自前画面）、出力連携、同意管理、を BigQuery と組み合わせて構築します。

向くケース: マーケ・分析チームが GA4 のデータを BigQuery にエクスポートしている／Looker Studio でレポートを作る延長で BigQuery に直接 SQL を書く文化がある／Google Workspace を全社利用していて GCP のアカウント管理がしやすい。向かないケースは別記事で詳述しています。詳しくはBigQueryをCDPの土台にする判断｜既製CDPとの違い・費用・体制を中堅企業向けに整理を参照してください。

GA4標準UIだけでは見えない数字が見えるようになります。「ユーザー1人ごとの行動データ」「社内データとの組み合わせ分析」「サンプリングなしの正確な集計」が代表例です。

GA4 だけでは突き当たる壁: (1) 過去データが見られる期間に上限がある（標準14か月、最大50か月）、(2) ユーザーAさんがどう動いて購入に至ったかを1人単位の生データで見られない、(3) 「広告経由の新規顧客のうちSalesforce上で商談化したのはどれか」のような社内データとの組み合わせができない、(4) 標準レポートの集計軸の組み合わせに制限がある、(5) サンプリングで大規模アクセスの数字が誤差を含む。

これらは GA4 の仕様上の限界で UIをいくら触っても解決しません。GA4 から BigQuery にデータをコピーして SQL で自由に分析するのが標準アプローチです。GA4 → BigQuery のエクスポートは無料機能で、GA4 管理画面から数クリックで設定できます（BigQuery 側のクエリ実行料は別途）。詳しくはGA4×BigQuery連携を発注検討するための基礎知識を参照してください。

「ChatGPT や Claude に自然文で質問するだけで、AIがSQLを書いてBigQueryから答えを返す」が現実になりました。MCP（Model Context Protocol）と呼ばれる標準仕様が普及したためです。

具体例（Slackで質問するだけで完結）: (1) 「先月の有料広告経由のCV、業界別で分けて見せて」→ AIがSQLを組み立ててBigQueryで実行、結果を返す、(2) 「LTVが上位20%の顧客が、最初にサイトに来たキーワード上位10は?」→ AIが過去ログから集計、(3) 「製品Aの先月売上を、地域別×顧客セグメント別で出して」→ AIが多次元集計。

これまで「マーケがSQL書けない問題」を解くために Looker のダッシュボードを延々と作っていた工数が、大きく減らせる可能性があります。注意点としては、権限設計（誰がどのデータを見られるか）と監査ログを最初に設計しないと、社外秘データへのアクセスが制御不能になります。詳しくはBigQuery × MCPで生成AIから業務データを直接見るを参照してください。

「データ統合そのものを目的化しない」ことです。CDP やデータ基盤は、マーケティング施策を実行するための手段であり、データ統合は中間成果でしかありません。

失敗パターンの根本原因は、情シス部門主導でデータ基盤を構築すると「いかに整理された美しいデータモデルを作るか」が目的化しがちなこと。結果、公開時点で「目的を達成した」ことになり、その後マーケから利用要望が出ず塩漬けシステム化します。

回避策: (1) マーケ施策のKPIから設計する(LTVを5%上げる／離反率を10%下げる、など、データ基盤で何を達成するかを最初に決める)、(2) 3〜5個の具体施策を構築前に決める(公開初日に動かす施策をリスト化)、(3) マーケ責任者をプロジェクトの共同オーナーに(情シス単独でなく、マーケ部門責任者をプロジェクトオーナーに据える)。詳しくはCDP導入で失敗する3パターンと回避策を参照してください。

中堅企業（年商50億〜500億円規模、顧客数10万〜500万件、社員数100〜2000名程度）の場合、月額制サービス型CDPと自社開発型のどちらが現実的かは、社内の運用体制とSQL人材の有無で分かれます。

判断軸: (a) マーケ部門が画面操作で使いたい → 月額制サービス型（Treasure Data／Salesforce CDPなど）、(b) SQLが書けるアナリスト・データエンジニアがいる／既にBigQueryを使っている → BigQuery などを土台にした自社開発、(c) SalesforceのCRMをすでに全社で使っている → Salesforce CDP の連携優位性が大きい。

月額制サービス型は初期構築費用 800万〜3,000万円、月額利用料 600万〜3,000万円（年額換算）が中堅企業の目安。自社開発はソフトウェア利用料は抑えられますが、データ収集コネクタや名寄せロジックを自前実装する工数が大きく、運用継続できる体制が前提です。詳しくはCDP構築の費用と期間の目安｜中堅企業向けの現実解を参照してください。

BigQuery で「月数万円のはずが月30万円の請求」になる事故は実際に頻発しています。3つの予算管理項目を設計に組み込めば大半は防げます。

請求暴発の典型: (1) フルスキャンクエリの定期実行(テーブル全体を読むSQLが裏で毎日実行されている)、(2) 開発者の操作ミス(本番環境で大量データを処理する操作をうっかり実行)、(3) BIツールの裏側(LookerやTableauなどが想定外に大量クエリを発行)。

防御策: (a) クエリごとの最大処理データ量制限を設定、(b) ユーザー／プロジェクトごとの月間予算アラートを設定、(c) パーティション分割(日付列でテーブルを分け、必要な日付だけ読むクエリを書く運用に)。ベンダー提案を受けたらこれらの設計が含まれているかを必ず確認してください。詳しくはBigQuery 料金を発注検討時に正しく見積もる｜中堅企業の月額目安と請求暴発を防ぐ条件を参照してください。

「マーケ部門が画面操作で完結させたい」なら既製CDP、「SQL人材がいて柔軟な業務ロジックを組みたい／既存のデータ基盤を活かしたい」なら自社開発、が大まかな分かれ目です。

既製CDP（Treasure Data／Salesforce CDPなど）の強み: (1) マーケ向けの画面操作が最初から揃っている、(2) 標準コネクタで多数のSaaSにそのまま繋がる、(3) 顧客IDの統合・名寄せ機能が標準実装。一方で月額利用料が高めで、独自の業務ロジックには製品仕様の制約があります。

自社開発（BigQuery／Snowflake などを土台）の強み: (1) ソフトウェア利用料を抑えられる（クラウドの利用料のみ）、(2) 業務ロジックを柔軟に組める、(3) 既存のGoogle Workspace／GCP環境と一体運用できる。一方で、データ収集コネクタや名寄せ・マーケ向け画面はすべて自前実装で、運用継続できる体制が前提です。詳しくはBigQueryをCDPの土台にする判断｜既製CDPとの違い・費用・体制とCDP製品の選び方を参照してください。

属人的な勘や経験だけに頼った判断から、具体的な数字で裏付けされた判断ができるようになります。データは不確実性を完全に排除するものではありませんが、判断の根拠を可視化し、間違えた場合に「なぜ間違えたか」を振り返れるようになる点が最大のメリットです。

クラウドを活用すれば低コストで始められる時代です。中小企業は意思決定が早いため、データに基づく改善サイクルを高速で回しやすく、むしろ大企業よりデータ活用の恩恵を受けやすい面があります。全社統合から始める必要はなく、売上データの分析など小さな領域からスタートできます。

いきなり全社のデータを統合しようとせず、ビジネスへのインパクトが大きく、かつ手元にあるデータですぐ分析できる「クイックウィン」の領域から始めてください。たとえば「売れ筋商品の在庫切れを減らす」「問い合わせ対応時間を短縮する」など、成果が見えやすいテーマが最初の成功体験につながります。

データの抽出や集計はプログラミング知識がなくてもAIで容易にできるようになりました。その結果、「どのような課題を解くべきか」という人間による問いを立てる力の重要性が一層増しています。AIはデータから答えを出せますが、何を問うべきかは経営判断です。

BigQueryなどのクラウド基盤のストレージ・クエリ費用は月額数千円〜1万円程度に抑えられます。ただし、CDPを実際に稼働させるにはデータの取り込みパイプライン、品質監視、BIツール接続などの構築・運用コストが別途かかります。インフラ自体は安くても、使える状態にするまでの作業費が主なコストです。

社内の元データが汚い（形式がバラバラ、重複あり、欠損あり）場合、分析できる状態に整えるデータクレンジング作業に大きな工数がかかるためです。データの品質が良ければ構築コストは下がりますが、多くの企業では「データはあるが使える状態ではない」のが現実です。

最初は外部の専門家に支援を依頼しつつ、完全に丸投げするのではなく、分析の考え方やツールの使い方を社内に移転してもらってください。将来的に自社で運用できる体制を目指すことで、外部依存のコストを段階的に減らせます。

倉庫や店舗レベルで「いつ・何が売れるか」を予測できれば、過剰在庫の維持コスト削減と、欠品による販売機会損失の両方を防げます。在庫コストは売上の見えにくい費用であるため、経営者が想定している以上にインパクトが大きいケースが多いです。

BtoC小売・EC系では、直近の購入日（Recency）・購入頻度（Frequency）・購入金額（Monetary）の3軸で顧客を評価するRFM分析が実績のある手法です。ただし、サブスクリプション型ビジネスではFrequency軸が機能しないなど業種による限界もあるため、自社のビジネスモデルに合った分析手法を選ぶ必要があります。

必ずしもそうではありません。顧客は入れ替わるものであり、一部のヘビーユーザーを囲い込むだけでは成長に限界があります。優良顧客を分析する真の目的は「なぜ支持されているのか」のインサイトを得て、プロダクトやサービス全体の価値向上に活かすことです。

金額だけでは判断できません。「数年前に一度高額購入しただけ」「購入頻度が極端に低い」場合もあります。直近いつ買ったか（Recency）、どのくらいの頻度で買っているか（Frequency）もあわせて評価するRFM分析が要ります。

一人の顧客が長期的に自社にいくら利益をもたらすかの目安がわかるため、新規顧客獲得に使える広告費の上限や、どの顧客層に投資すべきかの経営判断基準になります。LTVが見えないと、獲得コストが回収できない顧客に過剰投資する失敗が起きます。

確率的に解約予兆を検出することは可能です。ただし、無理に引き留めるよりも「なぜ特定の属性の顧客が離脱しているのか」を理由として分析し、サービス自体の改善につなげることが重要です。解約予測は防御策ではなく、事業改善のための分析ツールとして使うのが効果的です。

ヘビーユーザーであっても競合の商品を併用していることが多く、囲い込みには限界があります。またヘビーユーザーに最適化しすぎると、より大きな市場であるライトユーザーや中間層のニーズとズレが生じ、長期的な成長が止まります。