Braze Alloys×Salesforce連携パターン|選び方とWebhook設計の入口
目次 クリックで開く
高度なカスタマーエンゲージメントを実現するBrazeと、顧客管理の要であるSalesforceを連携させることは、現代のマーケティングスタックにおいて不可欠な工程です。しかし、いざ実装しようとすると「公式のAppExchangeパッケージで十分なのか」「独自のWebhookを組むべきか」という選択に迫られます。本記事では、Braze Alloysを活用したSalesforce連携のパターンと、実務で重要となるWebhook設計の概念を徹底的に解説します。
Braze AlloysとSalesforce連携の全体像
Braze Alloysとは、Brazeが提供するエコシステム・パートナーシップの総称です。SalesforceはこのAlloysにおける主要なパートナーであり、データの双方向連携がサポートされています。連携の目的は、大きく分けて以下の2点に集約されます。
- Salesforceの属性・行動データをBrazeへ:商談の成立、リードスコアの変動、契約更新日の接近などをトリガーとして、Brazeからパーソナライズされたメッセージを配信する。
- BrazeのエンゲージメントデータをSalesforceへ:メールの開封、プッシュ通知のクリック、アプリ内での特定アクションをSalesforceの「活動」や「リード」に記録し、営業活動に活かす。
これらを実現するための手法には、公式の統合パッケージを利用する方法と、APIやWebhookを直接叩く方法があります。まずはそれぞれの特性を比較してみましょう。
【比較表】公式パッケージ vs 自作Webhook連携
BrazeとSalesforceを接続する際、最もポピュラーな2つの手法を比較しました。
| 比較項目 | Braze Salesforce Integration (AppExchange) | Webhook / API 連携 (Braze Alloys) |
|---|---|---|
| 導入難易度 | 低い(パッケージインストール中心) | 高い(開発・設計が必要) |
| リアルタイム性 | バッチ処理が基本(同期タイミングに依存) | 即時(イベント発生の瞬間に実行) |
| 柔軟性 | 限定的(標準オブジェクト中心) | 非常に高い(自由なデータ構造) |
| API負荷 | パッケージの仕様に依存 | 設計により最適化が可能 |
| 主な用途 | 属性データの定期同期、活動履歴の記録 | 行動トリガー型メッセージ、リアルタイムステータス更新 |
このように、公式パッケージは「定常的なデータ同期」に向いており、Webhook連携は「瞬間的なアクションへの反応」に向いています。特に、複雑なデータ連携を低コストで構築したい場合は、アーキテクチャの全体設計が重要になります。
関連記事:【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』
連携パターンの選び方:4つの判断基準
自社にとって最適な連携パターンを選ぶには、以下の4つの基準で評価を行う必要があります。
1. データの鮮度(リアルタイムかバッチか)
「お客様が商談を終えた5分後にサンクスメールを送りたい」のであれば、バッチ同期では間に合いません。この場合はSalesforceのFlow(フロー)やApexからBrazeのAPIを直接叩く、あるいはWebhookを利用する「リアルタイム連携」が必要です。逆に、単に「昨日の契約ランクをBrazeに反映させたい」程度であれば、深夜のバッチ処理で十分です。
2. エンジニアリングリソースの有無
WebhookやAPIを利用した連携には、SalesforceのApex開発やBrazeのLiquidコードの理解が必要です。社内にエンジニアがいない場合や、保守性を優先したい場合は、ノーコードに近い公式パッケージ(Braze Salesforce Integration)の利用が第一候補となります。
3. Salesforce APIのガバナ制限
Salesforceには、24時間あたりに発行できるAPIリクエストの総量(API Request Limit)が存在します。大量のユーザーデータを1件ずつWebhookで送ると、あっという間に制限に達してしまいます。数万件規模の更新が発生する場合は、一括(Bulk)処理ができるアーキテクチャを検討しなければなりません。
4. トリガーの発生源
「Brazeでメールを送った結果をSalesforceに書き戻す(Braze発)」のか、「Salesforceで商談フェーズが変わったのでBrazeでメッセージを送る(Salesforce発)」のかによって、設計の難易度が変わります。BrazeからSalesforceへの書き戻しは、BrazeのWebhook機能(キャンペーンやキャンバス内)で比較的容易に実装できます。
Webhook設計の入口:概念と基本構造
Webhookとは、あるアプリケーションで特定のイベントが発生した際に、外部のアプリケーションへリアルタイムでデータを送信する仕組みです。BrazeとSalesforceの連携において、Webhookは「橋渡し」の役割を果たします。
Webhookの基本フロー
- イベント発生:Salesforceでレコードが作成・更新される。
- リクエスト送信:SalesforceがBrazeのAPIエンドポイント(User Track APIなど)に対して、JSON形式のデータをHTTP POSTで送信する。
- データ処理:Brazeが受け取ったデータに基づき、ユーザーの属性(User Profile)を更新したり、イベントを記録したりする。
- アクション:更新されたデータに基づき、Brazeのキャンバスが走りメッセージが配信される。
セキュリティの確保
Webhookの設計において最も重要なのがセキュリティです。BrazeのAPIキーを直接リクエストに含める際は、HTTPS通信が必須であることはもちろん、Braze側では特定のIPアドレスからのリクエストのみを許可するなどの制限(IPホワイトリスト)を検討してください。
関連記事:WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ
実践:SalesforceからBrazeへデータを飛ばすWebhook設計
ここでは、Salesforceで特定の条件を満たした際に、Brazeへデータを送信する基本的な実装手順を紹介します。
ステップ1:Salesforceの外部サービスまたはFlowの設定
Salesforceの「設定」から「フロー」を作成します。レコードトリガーフローを選択し、オブジェクトの更新を検知します。近年では、Salesforceの「外部サービス」機能を利用することで、Apexコードを書かずにHTTPリクエストを送信することも可能になっています。ただし、複雑なJSON構造を構築する場合は、依然としてApex(HTTP Callout)が強力な選択肢となります。
ステップ2:Braze User Track APIの利用
Brazeへのデータ送信先は、通常 https://rest.iad-01.braze.com/users/track (インスタンスによりURLは異なります)となります。公式ドキュメント(Braze User Track API)を参照し、必要な権限を持つAPIキーを発行してください。
ステップ3:JSONペイロードの構造化
Brazeが認識できる形式でデータを送る必要があります。以下は、ユーザー属性を更新する際の基本的なJSON構造の例です。
{
"attributes": [
{
"external_id": "salesforce_contact_id_123",
"salesforce_lead_status": "Qualified",
"last_meeting_date": "2023-10-27"
}
]
}
ここで非常に重要なのが external_id です。Salesforceの連絡先IDやリードIDを、Braze側の external_id と一致させておくことで、確実に同一人物としてデータを紐付けることができます。IDが不一致だと、Braze側に新しいユーザーが作成されてしまい、データが断片化する原因となります。
また、広告データやより広範なデータ基盤との統合を検討している場合は、BigQuery等のデータウェアハウスを介したアーキテクチャも視野に入ります。
関連記事:高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャ
SalesforceオブジェクトイベントXBrazeキャンバス活用シーン × Webhook連携で渡すべきデータ設計 早見表
前のセクションでSalesforceからBrazeへのWebhook設計の実装手順を説明しましたが、「どのSalesforceオブジェクトのどのイベント」をトリガーにして「どのBrazeキャンバス」を起動するかは、ビジネスプロセスによって異なります。商談成立(Opportunity Closed Won)のイベントをトリガーにするオンボーディングシナリオと、契約更新時期が近づいたイベントをトリガーにする解約防止シナリオでは、Webhookで渡すデータの設計が根本的に違います。以下の表はSalesforceオブジェクト別の連携設計をまとめたものです。
| Salesforceオブジェクト・イベント | Brazeキャンバスの活用シーン | Webhookで渡すべきデータと設計ポイント | 連携設計の注意点 |
|---|---|---|---|
| 商談(Opportunity) Closed Won(成約)イベント |
①新規顧客オンボーディングキャンバス(成約後の初期設定ガイド・担当CSの紹介・最初のマイルストーン確認)②アップセル・クロスセルのナーチャリング開始(成約製品に関連する他製品の提案シナリオ)③カスタマーサクセスチームへの引き継ぎ通知(CS担当者へのSlack/メール通知含む) | 必須データ:external_id(SF Contact ID)・プラン名(plan_name)・成約日(closed_date)・担当CSの名前・メールアドレス(cs_owner_name / cs_owner_email)・契約金額(amount)・製品/サービス名(product_name)。Brazeのキャンバスで「成約プラン別のオンボーディングステップ数」を分岐させるためにplan_nameの渡し方(Basicプラン/Proプラン/Enterpriseプラン)を統一する | SalesforceのOpportunityが「Closed Won」になっても実際の請求・サービス開始が数日後になるケースがあるため、Webhookの発火タイミングを「Opportunity Stage = Closed Won かつ Close Date = 今日以前」の条件で設定することで誤発火を防ぐ。同一顧客のOpportunityが複数ある場合のBrazeキャンバス重複起動防止設計(entry conditions)も確認する |
| 契約(Contract) 契約終了60日前イベント |
①解約防止・契約更新キャンペーンキャンバス(更新特典提示・プラン変更提案)②顧客の利用状況に基づく「活用促進メール/プッシュ通知」シリーズ③顧客満足度調査(NPS)の配信とフォローアップ④更新交渉が必要な顧客への営業担当者へのリマインドタスク作成 | 必須データ:external_id・contract_end_date(契約終了日)・plan_name・account_health_score(顧客の利用スコア・あれば)・days_until_renewal(更新まで何日か)・renewal_owner_name(更新担当営業の名前)。BrazeのLiquidタグで「あと{days_until_renewal}日で契約更新です」という個別化メッセージを生成するために日数計算をSalesforce側で行ってWebhookで渡す設計が最もシンプル | SalesforceのScheduled Flowで「Contract.EndDate = 今日+60日」の条件でバッチ処理してWebhookを発火する設計が一般的。ただしバッチ処理は深夜に実行されることが多く、Brazeのキャンバスが深夜に起動してメール・プッシュ通知が深夜に送信されないようにBraze側で「Intelligent Timing(最適配信時間)」または「サイレントアワー(24時〜8時は配信しない)」を設定する |
| ケース(Case) チケットクローズ/解決イベント |
①サポートチケット解決後の満足度調査(CSAT)キャンバス②解決済み問題に関連するヘルプドキュメント・チュートリアルの自動配信③頻繁にケースを起票するユーザーへの「プロアクティブ支援」フローの起動④チケット未解決が長期化している場合のエスカレーション通知 | 必須データ:external_id・case_type(問い合わせ種別)・resolution_time_hours(解決にかかった時間)・support_tier(サポートプラン)・case_subject(件名:CSAT送付メッセージの本文に使用)。解決したケースの種別(Bug/Feature Request/How-to等)をBrazeで参照してCAST送付メッセージを種別別に分岐させると回答率が上がる | CASATアンケートはチケット解決後30分〜2時間以内に送ると回答率が最も高い。Webhookの発火からBrazeのキャンバス起動のタイムラグ(通常1〜10分)を考慮した遅延設定(Brazeのキャンバスの「Delay Step」)でベストタイミングを実現する。BugタイプのケースのCAST送付は「バグを報告したのに評価を求められる」という心理的不快感を与える場合があるため対象外とするルールを設ける |
| リード(Lead) リードスコア閾値到達イベント |
①ホットリードへの即時フォローアップキャンバス(「担当者から30分以内に連絡します」通知)②リードナーチャリングキャンバスのステージアップ(コールドリード→ウォームリードへの昇格)③特定のコンテンツを複数回閲覧したリードへの「今すぐ相談」プッシュ通知 | 必須データ:external_id(LeadのSF ID)・lead_score(スコア値)・lead_source(流入元)・interested_product(関心製品)・company_size(会社規模)。BrazeでSalesforceのLeadとContactを同一external_idで統合管理しているかどうかの設計(Lead→Contact変換時のIDの同一性)を事前に確認しないとBrazeのユーザーデータが分裂するリスクがある | Lead→Contact変換時にSalesforceのLeadとBrazeのユーザーが正しくマージされる設計(同一メールアドレスでのexternal_id統合)を実装しないと、リード段階でBrazeに送ったデータと商談段階のデータが別ユーザーとして扱われる。Lead変換フロー設計はSalesforce×Braze連携の最も複雑なシナリオのため、初期設計段階でBrazeのIdentify User APIの仕様を確認することを推奨する |
この表でSalesforce×Braze Webhook連携の設計で最も後悔するポイントが「external_idの統一設計を後回しにしたこと」です。SalesforceのContact IDとBrazeのexternal_idが統一されていないと、Webhookで渡したデータが正しいBrazeユーザーに紐付かず「同じ顧客に2通メールが届く」「新規顧客が既存顧客向けキャンバスに入る」などの問題が発生します。Webhook連携の設計着手前に「external_idはSalesforce Contact IDかLeadのIDか、それともメールアドレスで統一するか」をBraze側のデータ設計と合わせて決定することが、Salesforce×Braze連携の長期安定運用の基盤になります。
よくあるエラーとトラブルシューティング
連携の実装中によく遭遇するエラーとその対策をまとめました。
- HTTP 401 Unauthorized: APIキーが無効、またはヘッダーの
Authorization: Bearer [API_KEY]の形式が間違っています。BrazeのダッシュボードでAPIキーの権限(users.trackが許可されているか)を確認してください。 - HTTP 429 Too Many Requests: BrazeのAPIレートリミットに達しています。Salesforceからの送信頻度を下げるか、バッチ処理に切り替えてください。Brazeのデフォルト制限はプランにより異なります。
- External ID Not Found: 指定した
external_idのユーザーがBrazeに存在せず、かつ新規作成も行われない設定になっている場合に発生します。 - Mixed DML Operation Error (Salesforce): SalesforceのフローやApexで、セットアップオブジェクトと非セットアップオブジェクトを同じトランザクションで更新しようとすると発生します。非同期処理(@futureまたはQueueable)に切り替える必要があります。
まとめ:最適なデータアーキテクチャを目指して
Braze AlloysとSalesforceの連携は、単にツールを繋ぐ作業ではありません。「どのデータを、どのタイミングで、どの向きに流すか」という、ビジネスプロセスそのものの設計です。公式パッケージの利便性と、Webhook/APIの柔軟性を天秤にかけ、自社の運用体制とエンジニアリング能力に合わせた選択をしてください。
初期段階では公式パッケージによる属性同期から始め、リアルタイム性が求められるキャンペーンにおいて部分的にWebhookを導入していく「ハイブリッド型」のアプローチも有効です。データの整合性を保ちながら、顧客一人ひとりに最適なメッセージを届けられる盤石なデータ基盤を構築しましょう。
Salesforce活用・営業DXとデータ連携のご相談
Salesforceの定着支援や営業プロセスの可視化、基幹・会計システムとのデータ連携までをまとめて支援します。現在の設定や連携方式が最適かを確認したい、という導入前後のセカンドオピニオンにも対応しています。
CRM・営業支援
Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。