2026.09.15 開発

Brazeとは｜SDK実装とREST API設計から見た導入判断【2026年9月時点】

Brazeは、Web・iOS・AndroidのSDKでユーザー行動を集め、REST APIでサーバー側からユーザー属性の更新と配信を制御するカスタマーエンゲージメントプラットフォームです。導入の成否を分けるのは管理画面の使い勝手ではなく、実装側の3つの決めごとに集中します。接続するインスタンスの選定、users/trackの75オブジェクト上限とレート制限に合わせたバッチ設計、そしてCurrentsで出したイベントをどこに落とすかです。この記事では、Braze公式ドキュメントとGitHubの各SDKリポジトリで2026年9月15日に実測した版番号・制限値をもとに、初期化コードとcurl例つきで実装範囲を整理します。受託開発の現場で採用する条件と、見送ったほうがよい要件の線引きまで示します。

まとめ｜Braze導入で先に決めるインスタンス・イベント設計・データ出口

先に結論を3点で示します。第一に、接続先のインスタンスを最初に確定させます。BrazeはUS-01からKR-01まで複数のインスタンスを持ち、RESTエンドポイントもSDKエンドポイントもインスタンスごとに別ホストです。国内案件で個人データの所在を問われる場合はJP-01（rest.jp-01.braze.com）が選択肢になりますが、契約時に割り当てられたインスタンス以外は使えません。

第二に、カスタムイベントとカスタム属性の設計を、配信シナリオより先に固めます。Brazeの配信対象はユーザープロファイルに積まれたイベントと属性で決まるため、後から名前を変えると過去データが分断される点に注意が必要です。第三に、データの出口をCurrentsにするかAPIの定期取得にするかを決めます。分析や広告連携まで見るならCurrentsでS3などへ流し、そこから自社のデータ基盤に取り込む構成が扱いやすい形です。

逆に、メールの一斉配信しか要件がないならBrazeは過剰です。SDKを入れずに管理画面から一斉送信するだけの使い方では、MAU課金に見合うだけの機能を使い切れません。

BrazeのSDKとREST APIが担う役割の切り分けと構成要素

Brazeの実装は、クライアント側のSDKとサーバー側のREST APIという2系統に分かれます。どちらか一方だけでも動きますが、担当できる範囲が違うため、要件を最初にどちらへ寄せるかで工数が変わります。

SDKが自動で集めるセッション・デバイストークンとカスタムイベントの境界

SDKを組み込むと、セッション開始と終了、端末情報、プッシュのデバイストークン登録が自動で記録されます。ここまでは初期化コードを書くだけで動く範囲です。境界はその先にあります。「商品をカートに入れた」「見積り依頼を送信した」といったアプリ固有の行動は、開発者がlogCustomEventを呼んで明示的に送る必要があります。

BrazeのSDK統合ガイドでは、Web・Swift・Android・React Native・Flutter・Unityなど複数プラットフォーム向けの導入手順が並んでいます。共通しているのは、APIキーとエンドポイントを渡して初期化し、ユーザーを識別してからセッションを開くという流れです。アプリ内メッセージの表示やニュースフィードの描画もSDK側の機能なので、これらを使うならSDK組み込みは避けられません。

REST APIで行うサーバー側のユーザー更新と配信トリガーの分担

基幹システムやバックエンドにしかない情報は、SDKでは送れません。契約プラン、与信ステータス、店舗POSでの購買履歴といったデータは、サーバーからusers/trackで書き込みます。配信側も同様で、注文確定や解約受付のようにサーバー処理が確定した瞬間に送るメッセージは、campaigns/trigger/sendやmessages/sendを呼ぶ形が素直です。

分担の目安は単純です。クライアントで起きた行動はSDK、サーバーが真実を持つデータはREST APIに寄せます。両方から同じ属性を書くと、更新順序で値が前後するため、属性ごとに書き込み元を1つに決めておくと運用が楽になります。

インスタンスごとに変わるRESTエンドポイントとJP-01の選定条件

Brazeのエンドポイントは共通ホストではありません。公式のAPI Overviewには、US-01〜US-08とUS-10、EU-01・EU-02、AU-01、ID-01、JP-01、KR-01のインスタンスごとに、ダッシュボードURL・RESTエンドポイント・SDKエンドポイントの3つが表で並んでいます。US-01ならrest.iad-01.braze.com、JP-01ならrest.jp-01.braze.comという具合に、ホスト名自体が違います。

実装時に事故になりやすいのは、SDKエンドポイントとRESTエンドポイントの取り違えです。SDKの初期化にはsdk.jp-01.braze.comのようなSDK側のホストを渡し、サーバーからのAPI呼び出しにはrest.で始まるホストを使います。ドキュメントのサンプルはiad-01で書かれていることが多いため、コピーしたまま自社インスタンスに置き換え忘れると401や404で止まります。

Web SDKの組み込み手順とアプリ内メッセージ表示までの実装範囲

ここからは実際に動かす部分です。Web SDKはnpmパッケージとして配布されており、バンドラを使うプロジェクトならインストールから初期化まで数行で済みます。

npmで入れるWeb SDK 6.13.0の初期化とセッション開始のコード

npm registryの@braze/web-sdkは、2026年9月15日時点でlatestが6.13.0でした。ソースと変更履歴はbraze-web-sdkのリポジトリで追えます。最小構成のコードは次の形です。

import * as braze from "@braze/web-sdk";

braze.initialize("YOUR_WEB_SDK_API_KEY", {
  baseUrl: "sdk.jp-01.braze.com",
  enableLogging: true,
});

braze.automaticallyShowInAppMessages();
braze.changeUser("user-1234");
braze.openSession();

順番に意味があります。initializeより前にイベントを送っても記録されません。changeUserはopenSessionの前に呼び、ログイン後の識別子を渡します。未ログイン時にchangeUserを呼ばずにおくと匿名プロファイルが作られ、ログイン後の識別子と自動では結合されない点に注意が必要です。automaticallyShowInAppMessagesを呼ばない限り、アプリ内メッセージは配信されても画面に出ません。

iOS 18.2.1系とAndroid 43.1.1系で確認するSDK更新の影響範囲

モバイル側の版番号も実測しておきます。braze-swift-sdkは2026年9月8日公開の18.2.1系、braze-android-sdkは2026年8月20日公開のv43.1.1系が最新でした。Android側のこのリリースには、公開AARのメタデータが利用側アプリにAPI 37でのコンパイルを強いていた不具合の修正が含まれています。

SDKの更新頻度は月に複数回のペースで、メジャー番号も年単位で大きく進む傾向です。バージョンを固定したまま2年放置すると、OSの通知仕様変更に追随できず、上げ幅が大きくなって回帰試験のコストが跳ね上がります。四半期に一度は差分を確認し、マイナー更新は積み残さない運用のほうが結果として安く付きます。

プッシュ通知の配信に必要なFCM資格情報とAPNsの.p8設定

Brazeはプッシュの配信経路を自前で持っているわけではありません。公式のプッシュ通知ガイドによると、Androidではgoogle-services.jsonを配置したうえでFirebaseのサービスアカウントJSONをBrazeダッシュボードにアップロードし、Firebase Sender IDをSDK設定に書きます。iOSはApple Developerアカウントで発行した.p8ファイルとBundle ID・Key ID・Team IDの登録、Xcode側でのプッシュ通知capability追加が前提です。

つまりAndroidの配信はFCMの上に乗っています。トークンの仕組みや配信の流れはFCM（Firebase Cloud Messaging）の仕組みと使い方で整理しているので、資格情報の準備でつまずいたときはそちらから逆算すると原因を絞りやすくなります。Webプッシュの場合は、サービスワーカーをContent-Type: application/javascriptで返すこととHTTPS配信が条件です。

users/trackのリクエスト設計とレート制限に合わせたバッチ分割

サーバー連携で最初に書くのがusers/trackです。1件ずつ呼ぶ実装でも動きますが、既存DBからの初回同期で数十万件を流すと、制限に当たって止まります。

1リクエスト75オブジェクト上限を前提にしたバッチ処理の組み方

Create and update usersのリファレンスでは、1リクエストに含められるのはattributes・events・purchasesを合計して最大75オブジェクトと定義されています。各オブジェクトにはexternal_id・user_alias・braze_id・email・phoneのいずれかの識別子が必要です。実際のリクエストはこの形になります。

curl -X POST https://rest.jp-01.braze.com/users/track \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_REST_API_KEY" \
  -d '{
    "attributes": [
      { "external_id": "user-1234", "plan": "business", "contract_start": "2026-09-01" }
    ],
    "events": [
      { "external_id": "user-1234", "name": "quote_requested", "time": "2026-09-15T10:00:00+09:00" }
    ]
  }'

成功時は{"message": "success"}に加えてattributes_processedなどの処理件数が返ります。ここで見落としやすいのが部分成功です。一部のオブジェクトだけ不正だった場合もmessageはsuccessのままで、errors配列にだけ理由が入ります。レスポンスのステータスコードだけを見て成功判定すると、投入漏れに気づけません。ペイロードの上限は多くのエンドポイントで4MB、users/track/bulkでは2MBです。

429応答とX-Ratelimit-Retry-Afterを見た再送制御の実装

レート制限の数値はRate limitsのページに一覧があります。全体の既定値は1時間あたり250,000リクエスト、users/trackはデータポイント課金の契約で3秒あたり3,000リクエストというバースト制限です。MAU課金の契約では想定取得量に応じて個別に設定されるため、自社の値は契約書かサポート経由で確認します。

すべてのレスポンスにX-RateLimit-Limit・X-RateLimit-Remaining・X-RateLimit-Resetが付くので、残数を見て投入速度を落とす実装にします。429が返ったときはX-Ratelimit-Retry-Afterの秒数だけ待ってから再送する手順です。固定待ち時間の指数バックオフだけで組むと、待ちすぎて夜間バッチが朝までに終わらないか、待たなすぎて429を繰り返すかのどちらかになります。ヘッダーの値を素直に使うほうが安定します。

配信APIの250リクエスト毎分制限とトリガー配信への振り分け

配信系は数字の桁が違います。messages/send・campaigns/trigger/send・canvas/trigger/sendのブロードキャスト配信は全体で毎分250リクエスト、同一オーディエンスに対しては毎分10リクエストという制限です。sends/id/createに至っては1日100リクエストしかありません。

エンドポイント	制限（2026年9月時点）	設計上の含意
既定値（共有）	250,000リクエスト／時	全エンドポイントの総量として見る
users/track	3,000リクエスト／3秒（データポイント課金）	初回同期は75件ずつまとめて投入
messages/send 等	全体250件／分・同一オーディエンス10件／分	大量配信はAPIループでなくセグメント配信へ
users/export/ids	250リクエスト／分	全件エクスポート用途には向かない
イベント一覧・購入商品一覧	1,000リクエスト／時（共有）	定義一覧はキャッシュして参照

表の件数はリクエスト数です。イベント一覧はevents/list、購入商品一覧はpurchases/product_listを指します。この数字から導ける設計方針は1つです。数万人への配信をAPIのループで回してはいけません。セグメントを条件で定義し、1回のキャンペーン配信としてBraze側に処理させます。APIを叩くのは、個別のトランザクションメールのように1ユーザー単位で理由がある場合に限ります。

Currentsで書き出したイベントを自社データ基盤へ取り込む構成

Brazeの中に閉じてしまうと、広告配信やBIレポートと数字が合わなくなります。配信結果と行動ログを外へ出す仕組みがCurrentsです。

S3・GCSなど出力先パートナーの選び方とAvroファイルの扱い

Currentsのドキュメントによると、出力はAvro形式のファイルで、メッセージエンゲージメントイベント、カスタマービヘイビアイベント、ユーザープロファイルの3系統が対象です。連携先パートナーの一覧には、ストレージとしてAmazon S3・Google Cloud Storage・Microsoft Azure Blob Storage、CDPとしてmParticle・Segment・Tealium・Treasure Data・RudderStack・Adobe・Amperity、分析としてAmplitude・Mixpanel・Heap、そしてCustom HTTP Connectorが並びます。

選び方は単純で、自社の分析基盤があるクラウドに合わせます。BigQueryで集計しているならGCS、Redshiftや Athena ならS3が素直です。Avroはスキーマ同梱のバイナリ形式なので、テキストのつもりでパースすると読めません。BigQueryは外部テーブルとしてAvroを直接読めるため、変換処理を挟まずに済む場面があります。

BigQuery側でのID統合とセグメント再生成につなぐ権限設計

Currentsで落ちてくるイベントにはexternal_user_idやbraze_idが入ります。自社の会員IDと突き合わせる鍵はここで、SDKのchangeUserに渡した識別子と基幹側のIDがずれていると、後段のすべてが合いません。識別子の設計はSDK実装の最初の1行で決まると考えたほうが実態に近いです。

取り込み先での構成は、BigQueryでCDPを構築する構成：ID統合・セグメント生成・広告連携と権限設計で扱っている形がそのまま使えます。ストレージのバケットにはCurrents用のサービスアカウントだけ書き込み権限を与え、分析側に与えるのは読み取り専用の権限です。書き込みと読み取りを同じ権限で回すと、集計ジョブの不具合で元データを消す事故が起こり得ます。

受託開発の現場でBrazeを採用する条件と見送るべき要件の線引き

ここからは判断の話です。ツールとしての機能が多いことと、案件に合うことは別の問題なので、条件を分けて言い切ります。

採用する条件：複数チャネルの出し分けとリアルタイム判定の要件

採用が妥当なのは、プッシュ・アプリ内メッセージ・メール・LINEなど複数チャネルを、ユーザーの状態に応じて出し分ける要件があるときです。ここにリアルタイム性が加わるなら、さらに向いています。カート放棄から30分後、閲覧から24時間以内といった条件分岐を、アプリのリリースを挟まずに変更できることがBrazeの本体価値です。

もう1つの条件は、配信内容を変える主体がマーケティング側にあることです。シナリオ変更のたびに開発チームへ依頼が来る体制なら、SaaSに払う費用の大半は無駄になります。管理画面で条件を組み替える運用が定着する見込みがあるかどうかが、投資回収の分かれ目です。

見送る条件：メール一斉配信だけの運用とイベント設計を持てない体制

逆に見送るべき場面も明確です。第一に、月数回のメール一斉配信しか予定がない場合。SDK組み込みの工数とMAU課金に対して、使う機能が釣り合いません。第二に、アプリやWebに計測イベントを仕込める体制がない場合。Brazeの判定材料はイベントと属性なので、送るデータがなければセグメントは作れず、結局は全員一斉配信に戻ります。

第三に、個人データの所在について厳しい制約があり、割り当てインスタンスの変更が契約上難しい場合です。この3つのいずれかに当たるなら、既存のメール配信基盤を強化するほうが費用対効果は高くなります。判断の前に、いま何が送れていないのかを洗い出す作業を挟んでください。

見積り依頼の前に確定させるMAU・チャネル・実装工数の3項目

Brazeの料金ページには、Braze Go・Braze Select・Braze Pro・Braze Enterpriseの4区分が示されていますが、定価の数値は掲示されていません。課金はMonthly Active Users（MAU）を軸に、メールやSMSなどの利用に充てるAction Creditsを組み合わせる形です。見積りを取る前に、想定MAU、使うチャネル、月間配信通数の3つを自社で確定させておかないと、提示額の比較ができません。

実装工数の見積りも同時に必要です。SDK組み込みだけなら小さく収まりますが、基幹システムからの属性同期、Currentsの取り込みパイプライン、既存の会員IDとの突き合わせまで含めると、規模はまったく変わります。SDK組み込みと並行して走るサーバー側の連携実装や、データ基盤への取り込み部分を外部に任せる前提で考えるなら、API開発・システム連携のページに対応範囲をまとめています。

よくある質問

Brazeの実装と選定で、判断が必要になりやすい論点を5つ挙げます。

BrazeとFirebaseのBlazeプランは何が違いますか？

名前が似ているだけで、まったく別の製品です。Brazeはニューヨーク発の企業が提供するカスタマーエンゲージメントプラットフォームで、配信シナリオの構築とメッセージ配信が守備範囲です。一方のBlazeはGoogleのFirebaseにおける従量課金プランの名称で、FirestoreやCloud Functionsの利用量に応じて課金される料金体系を指します。検索時に混ざりやすいため、費用を調べているならFirebaseの料金と無料枠・Blaze超過単価のほうが目的の情報です。

Brazeの料金はいくらになりますか？

公式の料金ページにプラン区分は載っていますが、金額は掲示されていません。MAUを軸にした個別見積りのため、公開されている「月額◯万円」という数字は第三者サイトの推計と考えてください。比較検討の実務としては、想定MAUと使うチャネル、月間配信通数を確定させたうえで複数社に見積りを依頼する形になります。SDK実装と連携開発の費用は別に見積もる必要があります。

SDKを入れずREST APIだけで運用できますか？

できますが、機能は限定されます。ユーザー属性の更新やメール配信はAPIだけで完結します。ただしアプリ内メッセージ、プッシュのトークン登録、セッションや画面遷移の自動計測はSDKがなければ成立しません。既存のWebサイトに手を入れられない事情がある場合、まずはメール配信とAPI連携だけで始め、後からSDKを追加する段階導入も可能です。その場合も識別子の設計だけは最初に固めておきます。

プッシュ通知はFCMの設定なしで配信できますか？

Androidへのプッシュは配信できません。公式ガイドが示すとおり、Firebaseのサービスアカウント資格情報をBrazeに登録し、アプリ側にgoogle-services.jsonを配置する手順が前提になります。iOSはFCMではなくAPNsの.p8ファイルとBundle ID・Key ID・Team IDの登録が必要です。Webプッシュはサービスワーカーの設置とHTTPS配信が条件で、Content-Type: application/javascriptで返す設定を落とすと登録に失敗します。

SendGridなどのメール配信基盤から乗り換えるべきですか？

トランザクションメールだけを送っているなら、乗り換える理由は薄いと考えます。パスワード再設定や注文確認のような1対1のメールは、配信専用サービスのほうが安く、到達率の運用も枯れています。Brazeが効くのは、行動データを条件にして複数チャネルへ出し分けるマーケティング配信です。両方を並走させ、トランザクション系は既存基盤、シナリオ配信はBrazeという分担にする構成も現実的です。イベント取り込みの実装はSendGrid API Event Webhookの実装手順と同じ考え方で設計できます。