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

デジタルマーケティングの現場において、顧客データをいかに「リアルタイムに、かつ正確に」アクションへ繋げるかは、事業成長を左右する最重要課題です。しかし、多くの企業が「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）

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

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. 実務におけるツール比較と選定基準

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

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内のデータロジックを再利用できるため、大幅な工数削減が可能になります。まずは自社のデータフローを整理し、リアルタイム性が本当に必要な項目を見極めることから始めましょう。