BigQueryでCDPを構築する構成：ID統合・セグメント生成・広告連携と権限設計

GA4のイベントとCRMの顧客マスタをBigQueryに入れた時点で、顧客データ基盤の下半分はすでに手元にあります。足りないのは、複数のIDを一人の顧客にまとめる統合層と、条件に合う顧客を抜き出して広告やMAへ戻す活性化層です。この記事では、層構造の対応関係、IDグラフのテーブル設計と名寄せの再計算、セグメント生成をSQLで運用する仕組み、広告連携の同期頻度、パッケージ型CDPとの費用の分岐点、列レベルの権限隔離と第三者提供の記録設計までを実装の粒度で扱います。数値は2026年8月17日時点の公式ドキュメントで確認したものです。

まとめ：BigQueryをCDPとして組む判断基準と構成の全体像

結論から書きます。BigQueryが担えるのは収集・統合・セグメント生成までで、広告やMAへ書き戻す活性化層と、マーケティング担当者が条件を編集するGUIは含まれません。この2つを誰がどう埋めるかが、パッケージ型CDPを買うかBigQueryで組むかの分岐点です。

費用面の差は大きく見えます。BigQueryのオンデマンド課金は1TiBあたり6.25ドル、毎月1TiBまで無料枠があり、ストレージも各区分で毎月10GiBまで無料。数TiB規模なら月数十ドルから百ドル台に収まる一方、パッケージ型CDPは年額数百万円規模のライセンスが前提です。ただしこの差は、基盤を保守する人件費を入れた瞬間に縮みます。

採用の可否は3条件で切り分けられます。連携先が2つ以下、セグメント更新が日次以下、社内にSQLを書ける担当者が1人以上いる。この3つが揃うならBigQuery側が有利です。逆にマーケティング部門だけで運用したい場合や、秒単位のリアルタイム配信が要件に入る場合は見送るべきでしょう。加えて2026年7月17日に公布された令和8年改正個人情報保護法で課徴金制度が創設されるため、広告連携の提供根拠は設計段階で台帳化しておいてください。

パッケージ型CDPの4層とBigQueryが担う範囲の対応関係と欠落点

買う場合と組む場合の違いを、層に分解します。

収集・統合・セグメント・活性化の4層で見た機能の欠落箇所と補い方

CDP製品が提供する機能は、おおむね収集・統合・セグメント生成・活性化の4層に分かれます。BigQueryが標準で持つのは前半3層に相当する部分で、しかもいずれもSQLとスケジュールクエリで書く前提です。CDP（カスタマーデータプラットフォーム）とは？仕組み・DMP/CRMとの違い・導入ステップを解説で整理しているとおり、CDPの定義上の中核は「顧客単位でデータを結合し、プロファイルを保持すること」にあります。BigQueryはその結合を実行できる場所であり、結合ルールそのものは提供しません。

欠落するのは2点です。ひとつは活性化層、つまりセグメントを広告やMAツールへ書き戻す経路。もうひとつは条件を非エンジニアが編集する画面です。前者はリバースETL製品か自前バッチで埋め、後者は定義テーブルと簡易フォームで代替します。製品としての基本仕様はBigQueryとは：サーバーレスDWHの仕組み・料金・できないことと採用判断にまとめてあります。

GA4エクスポートとData Transfer Serviceで組む収集層の実装

収集層は既製の経路で大半が埋まります。GA4のBigQueryエクスポートを有効にすればイベント単位のテーブルが日次で書き出され、Web・アプリ側の行動データは追加開発なしで揃う構成です。CRM側はBigQuery Data Transfer Serviceとは：対応ソースと転送スケジュール設計・自前バッチとの分岐で扱った転送サービスを使い、Salesforceや広告媒体のデータを定期取り込みします。

HubSpotコネクタも同サービスに用意されています。認証に必要なのは限定公開アプリのアクセストークンで、カスタムオブジェクトは CUSTOM_OBJECT_NAME__c の形式でテーブル化されます。転送設定の作成に要るのは bigquery.transfers.update や bigquery.datasets.update などの権限、またはBigQuery管理者ロール。2026年8月時点でこのコネクタはプレビュー段階のため、本番の基幹連携に据えるなら障害時の再取り込み手順を先に決めておくべきでしょう。

取り込み方式の選択で跳ね上がる料金と、バッチ読み込みを既定にする理由

収集層でコストを壊すのは取り込み方式の選び方です。Cloud Storageからのバッチ読み込みは、default-pipeline という共有スロットプールを使う限り無料でした。対してストリーミングは有料で、gRPC版のStorage Write APIが1GiBあたり0.025ドル・毎月2TiBまで無料枠つき、REST版のストリーミング挿入は200MiBあたり0.01ドル、しかも成功した行が1行あたり最小1KBとして計算されます。1行200バイトの行動ログを1日1,000万行流せば、実データ約2GBに対し課金上は10GBぶんの扱い。リアルタイム性が要件に入らない限り、バッチ読み込みを既定にしてください。

顧客IDを統合するIDグラフのテーブル設計と名寄せの再計算手順

CDPと単なるDWHを分けるのは、この統合層の設計です。

決定論的マッチと確率的マッチの適用条件・誤結合が生む配信事故

ID統合の方式は2種類あります。決定論的マッチは、会員ID・正規化したメールアドレス・電話番号のように一意性が担保された値で結合する方法。確率的マッチは、端末情報・IPアドレス・行動パターンの類似度から同一人物と推定する方法です。

ここは言い切ります。広告配信やメール配信に使うIDグラフに、確率的マッチを混ぜてはいけません。誤結合の損害が非対称だからです。分析用途なら数%の誤りは平均に吸収されますが、配信用途では別人の購買履歴に基づくメールが届く事故になります。確率的マッチを入れるなら分析専用テーブルに隔離し、配信系のクエリから参照させない構成に。

IDグラフを2テーブルで保持する構成とパーティションの切り方

実装は2テーブルで足ります。ひとつは観測されたID対を蓄積する id_edge（列は source_id_type、source_id、target_id_type、target_id、observed_at）で、observed_at の日付でパーティションを切ります。もうひとつは統合結果を保持する id_master（列は canonical_id、id_type、id_value、merged_at）です。

id_edge を連結成分としてまとめ、各グループの代表値を canonical_id に割り当てる処理を日次で回します。パーティションを切っておけば、直近90日ぶんだけを再計算する差分運用に切り替えたときスキャン量がそのまま減る構成。全期間を毎日再計算するやり方は、データが1TiBを超えたあたりからクエリ費用の主因になります。

名寄せ結果が変わる前提で持つ統合キーの再割当ログと配信履歴の保持

名寄せは一度で確定しません。新しいID対が観測されるたび、これまで別人だった2グループが結合され canonical_id が付け替わります。ここを設計に織り込まないと、過去に配信したセグメントを再現できなくなります。

対策は単純です。canonical_id の付け替えを id_merge_log（old_canonical_id、new_canonical_id、merged_at）に追記し、セグメント配信の履歴側には配信時点の canonical_id をそのまま残します。効果測定でずれが出たとき、統合が原因か施策が原因かを切り分けられるのはこのログがある場合だけです。

セグメント生成をSQLで運用する設計と定義の散逸を防ぐ仕組み

統合層の次は、誰がどうやって条件を書くかという運用の問題です。

セグメント定義をテーブル化して属人的なSQLの散逸を止める構成

マーケティング担当者の依頼を受けてエンジニアが都度SQLを書く運用は、半年で破綻します。似た条件のクエリが個人のワークスペースに散らばり、「先月と同じ条件」を再現できなくなるためです。

代わりに segment_definition テーブルを置き、segment_id、名称、WHERE句に相当する条件式、更新頻度、作成者、有効期限を行として持ちます。生成ジョブはこれを読んで条件式を展開し、segment_member（segment_id、canonical_id、computed_at）へ書き込むだけの構成。定義が1か所に集まるため、条件の重複と不要セグメントの棚卸しがSQLで済みます。

ビュー実装とテーブル実体化で分かれるスキャン量と月額費用の差

セグメントをビューで定義すると、参照のたびに基礎テーブル全体をスキャンします。行動ログ500GiBに対し20本のセグメントビューを日次で参照する構成なら、単純計算で月10TiB近くをスキャンし、無料枠を差し引いても月60ドル前後に達します。

実体化したテーブルに日次で書き出す構成なら、スキャンは生成時の1回に収まります。判断基準は参照回数で、1日に2回以上読まれるセグメントは実体化してください。課金方式そのものの分岐点、つまりオンデマンドとEditionsのどちらを選ぶかはBigQueryの料金：オンデマンドとEditionsの分岐点・ストレージ課金・コスト監視で数式込みに整理しています。

広告プラットフォームへ配信する活性化層の経路と同期頻度の設計

ここがBigQuery側に用意されていない層で、構成の自由度と手間が同時に発生します。

リバースETL製品と自前APIバッチを分ける連携先数と頻度の基準

選択肢は2つです。HightouchのようなリバースETL製品を挟むか、Cloud Runなどで自前のAPIバッチを書くか。分岐は連携先の数と更新頻度で決まります。

連携先が3つ以上、または日次より短い同期が要るならリバースETL製品を入れます。各媒体のAPI仕様変更・レート制限・差分検出を自前で保守し続けるコストが、ライセンス費を上回るためです。連携先がGoogle Ads1つだけで日次更新なら自前バッチで足ります。実装は前日ぶんとの差分を抽出してAPIへ送るだけで、200行程度に収まる規模です。

Google Adsカスタマーマッチ連携で先に決める同意の取り扱い

顧客リストを広告媒体へ送る場合、メールアドレスや電話番号はハッシュ化して送信します。技術的な難所はそこではなく、送ってよい顧客をどう判定するかです。

個人情報保護法第31条は、個人関連情報を第三者へ提供する際、提供先で個人データとして取得されることが想定されるときは本人の同意が得られていることの確認を求めています。広告連携はこの条文に触れる典型的な経路。実装としては、同意取得の状態を consent_event（canonical_id、consent_type、granted、recorded_at）として保持し、配信対象を抽出するクエリのWHERE句に必ず結合させます。同意の判定をリバースETL製品側の画面設定に委ねると、設定変更の履歴が追えなくなります。

HubSpotとの双方向同期で壊れやすい箇所と書き戻しの範囲

CRM側への書き戻しは、広告媒体より事故が起きやすい領域です。HubSpotは2026年6月のアップデートで、BigQueryアプリから取り込みと書き出しの双方向連携を1回の設定で扱えるようになりましたが、ベータ提供です。

壊れやすいのは3か所です。BigQuery側の値でCRMのプロパティを上書きし、営業の手入力を消すケース。BigQuery側で削除された行がCRMに残り続けるケース。同期頻度を上げた結果、APIのレート制限に当たって一部だけが反映されるケース。書き戻す対象は、スコアやセグメント所属のように「基盤側が唯一の正」と言える項目に限定し、営業が編集する項目には触れない方針を最初に決めてください。

パッケージ型CDPとの費用比較：BigQuery側の実額と人的コストの内訳

ここからは判断に必要な数字を並べます。

BigQuery側で実際に発生する費用の内訳と会員規模別の目安

発生する費用はストレージ、クエリ、取り込み、活性化層のライセンスの4つです。公式の換算例では、us-central1のアクティブ論理ストレージで1TiBを1か月保存すると23.552ドル。ここに前掲のクエリ課金が乗ります。

この表はストレージとオンデマンドクエリだけの概算で、リバースETL製品を入れる場合は別途ライセンスが乗ります。スロットを確保するEditionsへ切り替えても、ストレージとストリーミング挿入の費用は別建ての請求です。

パッケージ型CDPのライセンスと比べたときの実質的な分岐点と人件費

パッケージ型CDPは収集から施策実行までを一体で提供する代わりに、年額数百万円規模の定額ライセンスが基本です。上の表と並べるとBigQuery側が圧倒的に安く見えますが、この比較は不完全でしょう。

抜けているのは人件費です。IDグラフの再計算、セグメント定義の棚卸し、連携先APIの仕様変更対応を合わせると、運用が安定した後でも月0.3人月から0.5人月程度の保守工数が継続します。エンジニア単価を月100万円とすれば年間360万円から600万円で、パッケージ型のライセンス費とほぼ同じ水準。費用だけで選ぶなら差はつきません。分岐点は自由度の側にあり、独自の指標でセグメントを切りたい、既存の分析基盤と同じ場所にデータを置きたい、という要件があるときにBigQuery側の構成が効きます。

個人データの権限分離と令和8年改正を見据えた第三者提供の記録設計

社内で最も機微なデータが1か所に集まる以上、権限設計の後付けは作り直しを招きます。

ポリシータグによる列レベルの隔離と、検証時に見落とす24時間キャッシュ

BigQueryの列レベルのセキュリティは、ポリシータグを列に付けて参照可否を制御する仕組みです。ポリシータグはリーフフィールドにのみ適用でき、テーブル列には1つだけ割り当てられます。分類とタグの作成管理には「Data Catalog ポリシータグ管理者」、保護された列を読む側には「Data Catalog きめ細かい読み取り」のロールが必要。GoogleSQLのみが対象で、レガシーSQLでは動作しません。

落とし穴はキャッシュです。ポリシータグを適用した直後でも、クエリ結果キャッシュにより古い結果が24時間保持されます。タグを付けてすぐ検証クエリを流し「制限がかかっていない」と誤判定する事故が起きるため、検証時はキャッシュを無効化してください。値そのものを隠すなら、null・デフォルト値・ハッシュ化された内容で置換する動的データマスキングを併用します。

令和8年改正個人情報保護法の課徴金制度と提供記録テーブルの設計

制度側の前提が2026年に変わりました。個人情報の保護に関する法律等の一部を改正する法律は2026年7月10日に成立し、同年7月17日に公布されています。個人情報保護委員会は政令・委員会規則・ガイドライン等の整備を進めるとしており、2026年8月17日時点で施行日は未確定です。

改正の柱は課徴金制度の創設で、違法な第三者提供が対象行為として挙げられています。顧客データ基盤にとって、これは広告連携の設計そのものに関わる話。施行までに手を付けるべきは、連携先ごとに提供の法的根拠を書き出した台帳を作り、根拠が説明できない経路を止めることです。記録は配信ジョブ側に持たせ、activation_log（segment_id、destination、record_count、executed_at、consent_basis）の consent_basis に根拠を残して最低3年は保持してください。監査で問われるのは実装ではなく記録です。

BigQueryでCDPを組むべき条件と、採用を見送るべき場面の切り分け

最後に、着手前に判断できる条件へ落とします。

採用してよい3つの条件と、着手前に確認する体制と権限設計の前提

採用してよいのは次の3つが揃う場合です。連携先が2つ以下で当面増える見込みがない。セグメントの更新頻度が日次以下で足りる。SQLを書いてスケジュールクエリを保守できる担当者が社内に1人以上いる。この条件下なら、パッケージ型と同等の機能を数分の1の基盤費用で構成でき、独自の指標を条件式に入れる自由も残ります。

既存のBigQueryをそのまま基盤にできるかは、データセットの切り方と権限の付け方に左右されます。層別の分割や権限分離が済んでいないなら、そこを先に整理してください。設計から実装までを外部に任せる選択肢もあり、一創ではデータ分析基盤構築・MLOps構築支援として、収集経路の設計からID統合・権限設計までを含む構築を請け負っています。

見送るべき3つの場面と、PoCで止まる構成に共通する失敗パターン

見送るべき場面を3つ挙げます。マーケティング部門だけで運用したい場合。秒単位のリアルタイム配信が要件に含まれる場合。そして統合対象のデータが数十GiB以下にとどまる場合です。1つ目はGUIの不在が直撃し、依頼と実装の往復で施策の速度が落ちます。2つ目はストリーミング取り込みの課金構造と噛み合いません。3つ目はCDPの構成自体が過剰で、CRMの標準機能で足ります。

PoCで止まる失敗には共通点があります。ID統合まで作り込んだ時点で、活性化層を誰が保守するか決まっていないパターンです。データは統合されたのに配信経路がなく、SQLの実行結果をCSVで手動アップロードする運用に落ちて、半年後には誰も触らなくなる。着手時に決めるべきは統合ロジックではなく、書き戻し先と保守担当でしょう。

よくある質問

検討段階で問い合わせの多い点をまとめました。

BigQueryだけでCDPは完結しますか？

完結しません。収集・統合・セグメント生成まではSQLとスケジュールクエリで実装できますが、セグメントを広告プラットフォームやMAツールへ書き戻す活性化層と、非エンジニアが条件を編集する画面は含まれていません。前者はリバースETL製品か自前のAPIバッチ、後者は定義テーブルと簡易フォームで埋める前提になります。この2つの担当者を決めずに着手すると、統合済みのデータが使われないまま残ります。

パッケージ型CDPとBigQueryではどちらが安く済みますか？

基盤の利用料だけなら会員100万人規模でも月200ドル前後で、BigQuery側が安く見えます。ただし運用が安定した後も月0.3人月から0.5人月の保守工数が続くため、人件費を含めた総額ではパッケージ型のライセンス費とほぼ並びます。判断材料になるのは費用差ではなく、独自の指標でセグメントを切れる自由度と、既存の分析基盤と同じ場所にデータを置ける一貫性です。

GA4のデータだけで顧客データ基盤として成立しますか？

行動データの収集経路としては成立しますが、それだけではCDPになりません。GA4のBigQueryエクスポートで得られるのはWeb・アプリ上の行動イベントで、顧客の属性・購買履歴・問い合わせ履歴は別系統から取り込む必要があります。CDPの中核はこれらを顧客単位で結合する点にあり、CRMや基幹システムのデータを揃えて初めて統合層が意味を持ちます。

HubSpotのデータはBigQueryへどう取り込めばよいですか？

経路は2つあります。BigQuery Data Transfer ServiceのHubSpotコネクタを使う方法と、HubSpot側のアプリマーケットプレイスにあるBigQueryアプリを使う方法です。前者は限定公開アプリのアクセストークンで認証し、カスタムオブジェクトは CUSTOM_OBJECT_NAME__c の形式でテーブル化されます。後者は取り込みと書き出しの双方向を1回の設定で扱えます。2026年8月時点でいずれもプレビューまたはベータ提供です。

個人情報の扱いとして最初に決めるべきことは何ですか？

連携先ごとの提供根拠を書き出した台帳です。広告媒体への顧客リスト送信は個人情報保護法第31条が関わる経路にあたり、同意取得の状態を consent_event のようなテーブルで保持し、配信クエリの結合条件に入れる構成が前提になります。加えて2026年7月17日公布の令和8年改正法で課徴金制度が創設され、違法な第三者提供が対象行為に挙げられました。施行日は政令待ちですが、設計段階で経路を絞るほうが手戻りは小さく済みます。

関連記事

• BigQueryのデータセット設計：ロケーション不可逆・層別分割・権限分離の実装指針：顧客データを置くコンテナの切り方と権限分離を先に決めるための記事です
• データクリーンルームとは？仕組み・種類・CDPとの違いをわかりやすく解説：自社データと外部データを個人を識別せずに突合する選択肢を扱っています
• Looker Studioとは｜無料BIツールの機能・料金・BigQuery連携と企業導入の判断：セグメントの内訳や施策効果を可視化する側の構成を解説しています
• データウェアハウス（DWH）とは？仕組み・製品比較・選び方をわかりやすく解説：CDPとDWHの位置づけの違いを概念の側から整理しています