RudderStackとBraze CDPとMAの責務分担とデータフロー設計

この記事をシェア:
目次 クリックで開く

RudderStack×Braze 実装クイックリファレンス(SQL / API / Reverse ETL)

本記事の解説に入る前に、CDP実装で頻出する3つのコードパターンを掲載しています。公式ドキュメントには載っていない実務上のハマりどころも含めています。

① Identity Graph 名寄せ(BigQuery SQL)

-- BigQuery: Identity Graph 名寄せ(メール + LINE userId + ハッシュ電話番号)
WITH unified_id AS (
  SELECT
    COALESCE(s.user_id, b.external_id, k.line_user_id) AS canonical_id,
    s.email_sha256,
    b.line_user_id,
    k.cookie_id,
    GREATEST(s.last_seen, b.updated_at, k.event_time) AS last_seen
  FROM `prj.cdp.segment_users` s
  FULL OUTER JOIN `prj.cdp.braze_users` b
    ON SHA256(LOWER(s.email)) = b.email_sha256
  FULL OUTER JOIN `prj.cdp.karte_users` k
    ON s.user_id = k.user_id
)
SELECT canonical_id, MAX(last_seen) AS last_seen,
       COUNTIF(line_user_id IS NOT NULL) > 0 AS has_line,
       COUNTIF(cookie_id IS NOT NULL) > 0 AS has_web
FROM unified_id
GROUP BY canonical_id;

② サーバーサイドイベント送信(Track API)

# Twilio Segment: Track API(Server-Side Event)
curl -X POST https://api.segment.io/v1/track \
  -u "YOUR_WRITE_KEY:" \
  -H "Content-Type: application/json" \
  -d '{
    "userId": "user_42",
    "event": "Order Completed",
    "properties": {"order_id": "ORD-1023", "revenue": 12800, "currency": "JPY"},
    "context": {"ip": "203.0.113.42", "userAgent": "Mozilla/5.0"}
  }'

③ Reverse ETL(Hightouch → Salesforce)

# Hightouch (Reverse ETL): Salesforce Account へ毎時同期
type: salesforce
source:
  warehouse: snowflake
  query: |
    SELECT account_id, mrr, health_score, churn_risk_30d
    FROM marts.account_health
    WHERE updated_at > DATEADD('hour', -1, CURRENT_TIMESTAMP)
mappings:
  - column: account_id          # → Account.External_Id__c (Upsert key)
    field: External_Id__c
  - column: mrr                 # → Account.MRR__c
    field: MRR__c
  - column: health_score        # → Account.Health_Score__c
    field: Health_Score__c
  - column: churn_risk_30d      # → Account.Churn_Risk__c
    field: Churn_Risk__c
schedule: { cron: "5 * * * *" }

※ サンプルコードはAurant Technologiesの実案件をベースに簡略化しています。本番投入前にスキーマ・認証設定をご自身の環境に合わせて検証してください。

デジタルマーケティングの現場において、顧客データをいかに「リアルタイムに、かつ正確に」アクションへ繋げるかは、事業成長を左右する最重要課題です。しかし、多くの企業が「CDP(カスタマデータプラットフォーム)を導入したが、データの加工が追いつかない」「MA(マーケティングオートメーション)ツールに全データを送った結果、コストが肥大化した」という課題に直面しています。

本記事では、次世代のデータスタックとして注目されるRudderStack(ラダースタック)と、高度なカスタマーエンゲージメントプラットフォームであるBraze(ブレイズ)を組み合わせた際の、正しい責務分担とデータフロー設計について、IT実務者の視点から徹底解説します。

1. モダンデータスタックにおける「RudderStack」と「Braze」の役割

まず前提として、RudderStackとBrazeはどちらも「CDP」というキーワードで語られることがありますが、その本質的な役割は大きく異なります。

1.1 配信エンジンのBraze、パイプラインのRudderStack

Brazeは、プッシュ通知、メール、アプリ内メッセージ、LINEなどのマルチチャネルで顧客とコミュニケーションを取るための「配信・アクション」に特化したプラットフォームです。Braze内にも「Braze CDP」としての機能は備わっていますが、それはあくまで「配信に必要なセグメントを作成するためのプロファイル保持」を目的としています。

対してRudderStackは、Webサイトやアプリ、バックエンドサーバー、SaaSからデータを収集し、任意のデスティネーション(DWHやBraze、広告媒体など)へ配送する「データパイプライン」です。自社で保有するBigQueryやSnowflakeといったクラウドデータウェアハウス(DWH)を、CDPの「核」として機能させるためのインフラ層を担います。

1.2 従来のパッケージ型CDPと「Composable CDP」の違い

従来のパッケージ型CDP(例:Treasure DataやSalesforce Data Cloud)は、データの収集・加工・保存・連携を一つのシステムで完結させます。しかし、このモデルはデータのブラックボックス化や、ベンダーロックインによる高コスト構造を招きがちです。

一方、RudderStackとBrazeを組み合わせる手法は「Composable CDP(コンポーザブルCDP)」と呼ばれます。データの保存は自社のDWHで行い、配送にRudderStackを使い、配信にBrazeを使うという「最高峰のツールを組み合わせる」アプローチです。これにより、データの一貫性を保ちつつ、必要最小限のコストで柔軟なデータ運用が可能になります。

特に、高額なMAツールを導入する前に、データ連携の全体設計を見直すことは、将来的なコスト増大を防ぐために不可欠です。詳細な設計思想については、以下の記事も参考になります。

【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

2. 各コンポーネントの責務分担(Responsibility Matrix)

設計において最も重要なのが「どこで、どのデータ処理を行うか」という責務の明確化です。

工程 担当ツール 主な処理内容
データ収集 (Collection) RudderStack SDK Web/Appでのページビュー、クリック、購入イベントのリアルタイムトラッキング。
データの永続保存 (Storage) DWH (BigQuery 等) 全履歴データの保存、長期的な分析、機械学習モデルの構築。
ID統合 (Identity Resolution) DWH + RudderStack 匿名IDと会員IDの紐付け。DWHでのバッチ処理と、RudderStackによるリアルタイム名寄せ。
属性加工 (Enrichment) DWH (dbt等) 「過去30日の購入金額合計」など、計算が必要な指標(計算済み属性)の算出。
プロファイル管理 (Profile) Braze 最新のユーザー属性(LTV、最終ログイン日等)の保持とセグメント作成。
配信実行 (Activation) Braze セグメントに対するメッセージ配信、A/Bテスト、ジャーニー(キャンバス)制御。

2.1 データ収集:RudderStack SDKの役割

Webやアプリからの行動ログ収集は、RudderStackのSDKに一本化します。これにより、BrazeだけでなくGoogle Analytics 4(GA4)や広告管理画面(CAPI)へも、同一のコードベースからデータを同時配信できます。これを「1つ書いて、どこへでも送る(Write once, send anywhere)」と呼びます。

2.2 データ加工・統合:DWH vs Braze

複雑な計算や名寄せはBraze内で行ってはいけません。Brazeは「受信したデータに基づいて即座に動く」ことには長けていますが、数億レコードをスキャンして集計する処理には向いていません。集計処理はBigQuery等のDWHで行い、その結果(例:優良顧客フラグ)だけをRudderStack経由でBrazeに同期するのが定石です。

例えば、LINEの行動データを基盤から直接駆動させる設計などは、この考え方の延長線上にあります。

LINE データ基盤から直接駆動する「動的リッチメニューとキャンペーンモジュール」のアーキテクチャ

3. 推奨されるデータフロー設計とアーキテクチャ

実務で採用すべきデータフローは、主に2つのルートに分かれます。

3.1 イベントストリーム(リアルタイム)

「ユーザーが商品をカートに入れた」というイベントが発生した瞬間、数秒以内にBrazeへ送信するルートです。

  • フロー: Web/App → RudderStack SDK → Braze (Users Track API)
  • 用途: カート落ちメール、リアルタイムのプッシュ通知。
  • 注意点: このルートで全ての属性(名前や住所など)を送ると、トラフィック量に応じてBrazeのデータポイント課金が跳ね上がります。

3.2 リバースETL(DWHからの同期)

DWHに蓄積された「過去の購入履歴」や「SFA(Salesforce等)から取得した商談ステータス」を定期的にBrazeに同期するルートです。

  • フロー: BigQuery → RudderStack Reverse ETL → Braze
  • 用途: 会員ランクの更新、スコアリングに基づくセグメント更新。
  • メリット: サーバーサイドで処理されるため、ブラウザのITP制限を受けず、正確なデータをBrazeに届けることができます。

ITP対策や名寄せの高度な設計については、以下のガイドが非常に役立ちます。

WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ

4. 実務におけるツール比較と選定基準

自社でどのレイヤーに投資すべきかを判断するための比較表です。

評価項目 RudderStack Braze 汎用ETL (Fivetran等)
主な目的 データ配送・変換 顧客エンゲージメント DWHへのデータ集約
リアルタイム性 極めて高い (ミリ秒) 高い (配信に特化) 低い (分単位〜)
ID統合能力 Identity Graph機能あり エイリアス管理のみ 基本なし
課金体系 MTUまたはイベント数 データポイント + MAU 行数 (MAR)
公式ドキュメント RudderStack Docs Braze Docs Fivetran Docs

5. ステップバイステップ:RudderStackからBrazeへの連携手順

ここでは、最も一般的な「Webサイトの行動データをRudderStack経由でBrazeに送る」設定手順を解説します。

Step 1:Braze側の準備

  1. Braze管理画面の Settings > API Settings から「Rest API Key」を作成します。
  2. この際、権限(Scopes)として users.track, users.identify, users.alias.new を含める必要があります。
  3. 自社の「Rest Endpoint」を確認します(例:https://rest.iad-03.braze.com)。これはデータ送信先URLとして使用します。

Step 2:RudderStackでのDestination設定

  1. RudderStackダッシュボードで Add Destination を選択し、「Braze」を検索します。
  2. Step 1で取得した「API Key」と「App Group ID」、「Endpoint」を入力します。
  3. Connection Mode を選択します。
    • Cloud-mode: RudderStackのサーバーからBraze APIへ送信。バックエンドデータの送信や変換(Transformations)に適しています。
    • Device-mode: ブラウザ上でBraze SDKを直接読み込む方式。特定のBraze内機能(インアプリメッセージの即時表示等)が必要な場合に使います。

Step 3:トラッキングコードの実装

RudderStackの identify メソッドを呼び出すことで、Braze上の external_id と自動的にマッピングされます。


rudderanalytics.identify("user_12345", {

  email: "example@test.com",

  plan: "premium"

});

6. よくあるエラーと運用上の注意点

6.1 Brazeのレート制限(Rate Limits)

RudderStackのReverse ETLを使ってDWHから数十万件のユーザー情報を一括同期する場合、BrazeのAPI制限に抵触し、429 Too Many Requests エラーが発生することがあります。

  • 対処法: RudderStackのデスティネーション設定で、バッチサイズを調整するか、Braze側でレート制限の緩和(Rate Limit Increase)を申請します。通常、Brazeのデフォルト制限は 250,000 リクエスト/分 です。

6.2 匿名ユーザーのデータ消失

ログイン前のユーザー行動(anonymous_id)とログイン後の external_id が正しく紐付けられないと、Braze上で「同一人物だが別々のプロフィール」が作成され、データポイントが無駄に消費されます。

  • 対処法: RudderStackの Identity Resolution 機能を利用し、DWH側で名寄せされた結果を元にBrazeへ identify を実行する設計にします。

7. まとめ:拡張性とコストのバランスを最適化するために

RudderStackとBrazeの連携は、単なるツール接続ではなく「データのオーナーシップをどこに置くか」という戦略的決定です。すべてのデータをBrazeに抱え込ませるのではなく、「全データはDWHに、アクションに必要なデータだけをRudderStackでBrazeに届ける」という責務分離を徹底してください。

このアーキテクチャを構築できれば、将来的に配信ツールをBrazeから別のSaaSへ切り替える際も、DWH内のデータロジックを再利用できるため、大幅な工数削減が可能になります。まずは自社のデータフローを整理し、リアルタイム性が本当に必要な項目を見極めることから始めましょう。

ご相談・お問い合わせ

本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。

お問い合わせフォームへ

3. **追記するHTMLだけ**(通常は `

` で囲むとよい)。中に h2/h3、段落、リスト、table を使用可。

4. 次の1行を**そのまま**出力:

【2026年版】RudderStack vs 主要 Customer Data Pipeline

ツール 月額目安 特徴
RudderStack 無料〜従量課金 OSS・ウェアハウスファースト
Segment 月12万円〜 SDK豊富・実績
Snowplow セルフホスト無料 / Cloud有料 スキーマ厳格・OSS
mParticle 要問合せ モバイル・エンタープライズ

CDP × MA 責務分担

  • CDP(RudderStack):データ収集・統合・配信
  • MA(Braze):チャネル配信・パーソナライズ・効果測定
  • DWH(Snowflake/BigQuery):履歴蓄積・予測モデル

FAQ

Q1. RudderStack vs Segment 選定基準は?
A. 「コスト最適化重視=RudderStack、サポート重視=Segment」
Q2. セルフホスト構築コスト?
A. 初期200-500万円+月額数万円のインフラ。詳細は 顧客データ分析の最終稿

関連記事

  • 【Reverse ETL】(ID 441)
  • 【モダンデータスタック】(ID 12398)
  • 【Segment×Braze×Salesforce】(ID 16071)

※ 2026年5月時点の市場動向を反映。

📚 関連資料

このトピックについて、より詳しく学びたい方は以下の無料資料をご参照ください:

システム導入・失敗回避チェックリスト PDF

DX推進・システム導入で陥りがちな落とし穴を徹底解説。選定から運用まで安全に進めるためのチェックリスト付き。

📥 資料をダウンロード →

CDP・顧客データ基盤の関連完全ガイド

本記事のテーマに関連するCDP/顧客データ基盤の徹底解説記事を以下にまとめています。ツール選定・アーキテクチャ設計の参考にどうぞ。

レガシーシステム刷新・モダナイゼーションの関連完全ガイド

本記事のテーマに関連する旧基幹/旧SaaSからのモダナイゼーション完全ガイド一覧です。移行戦略・選定軸の参考にどうぞ。

Salesforce Agentforce 完全攻略シリーズ

Salesforce Agentforce の事前準備・データ接続・KPI・プロンプト設計までフェーズ別に深掘りした完全ガイドです。

関連ピラー:【ピラー】LINE × 業務システム統合 完全ガイド:LINE公式アカウント / LINE WORKS / LIFF / Messaging API の使い分けと CRM 連携設計

本記事のテーマを上位概念から体系的に学ぶには、こちらのピラーガイドをご覧ください。

関連ピラー:【ピラー】BigQuery/モダンデータスタック完全ガイド:dbt・Hightouch・Looker・BIエンジンの統合設計とコスト最適化

本記事のテーマを上位概念から体系的に学ぶには、こちらのピラーガイドをご覧ください。

関連ピラー:【ピラー】Salesforce 完全ガイド:CRM/SFA/MA/CDP/Agentforce の使い分けと統合設計、業界別実装パターン

本記事のテーマを上位概念から体系的に学ぶには、こちらのピラーガイドをご覧ください。

関連ピラー:【ピラー】広告運用統合 完全ガイド:Google/Meta/LINE/TikTok の CAPI 設計と BigQuery 統合分析でROAS最大化

本記事のテーマを上位概念から体系的に学ぶには、こちらのピラーガイドをご覧ください。





参考:Aurant Technologies 実プロジェクトのLooker Studio実装

本記事のテーマを実装段階まで進める際の参考として、Aurant Technologies が支援した複数の実案件で構築した Looker Studio ダッシュボードの一例をご紹介します。数値・社名・部門名はマスキングしていますが、実際に運用されている可視化です。

Aurant Technologies 実プロジェクトの売上・コスト・利益・部門別ダッシュボード(Looker Studio実装、数値マスキング済)
Aurant Technologies 実プロジェクトの売上・コスト・利益・部門別ダッシュボード(Looker Studio実装、数値マスキング済)

マーケティングDX

HubSpotのMA機能を活用したリードナーチャリング、Web広告の自動化・最適化、SEOコンテンツ戦略まで一貫対応。マーケティングROIを最大化します。

AT
aurant technologies 編集

上場企業からスタートアップまで、数多くのデータ分析基盤構築・AI導入プロジェクトを主導。単なる技術提供にとどまらず、MA/CRM(Salesforce, Hubspot, kintone, LINE)導入によるマーケティング最適化やバックオフィス業務の自動化など、常に「事業数値(売上・利益)」に直結する改善実績多数。

この記事が役に立ったらシェア: