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つの手法を比較しました。

このように、公式パッケージは「定常的なデータ同期」に向いており、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の基本フロー

1. イベント発生：Salesforceでレコードが作成・更新される。
2. リクエスト送信：SalesforceがBrazeのAPIエンドポイント（User Track APIなど）に対して、JSON形式のデータをHTTP POSTで送信する。
3. データ処理：Brazeが受け取ったデータに基づき、ユーザーの属性（User Profile）を更新したり、イベントを記録したりする。
4. アクション：更新されたデータに基づき、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配信」の完全アーキテクチャ

よくあるエラーとトラブルシューティング

連携の実装中によく遭遇するエラーとその対策をまとめました。

• 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を導入していく「ハイブリッド型」のアプローチも有効です。データの整合性を保ちながら、顧客一人ひとりに最適なメッセージを届けられる盤石なデータ基盤を構築しましょう。