Brazeの費用は、何で決まるのか

Brazeの費用は、なぜ金額表で示されないのか

公式の価格ページに金額表はありません。ボタンは「Get pricing」と「Start a free trial」で、問い合わせて見積を出す形です。

公開されているのは、エディションの段階です。Braze Go ／ Braze Select ／ Braze Pro ／ Braze Enterprise の4つで、上位が下位を含む書き方（「Everything in ◯◯, plus:」）になっています。

出典：Braze公式 価格ページ（2026年8月19日取得）。各エディションの行は「Everything in ◯◯, plus:」、最下行は「Features included in every tier」に挙げられた項目の訳です。原文は英語。

エディションごとのMAU閾値やデータポイントの上限は、公開ページには書かれていません。金額も、枠の大きさも、公開情報からは分かりません。

ここからは私たちの読み方です。公開されていないのであれば、確認できるのは契約と見積の側です。だから見積を受けるときは、金額を先に見ないほうがいい。先に確認するのは「どのエディションか」「MAUとデータポイントの枠がいくつか」の2点です。この2つが揃っていれば、あとから他社見積と比べられます。

1つめの軸は、なぜMAUなのか

MAUとは、月間アクティブユーザー ── その月に自社のデジタル接点で実際に接点を持った利用者の数です。価格ページに、こう書かれています。

Pricing scales with your Monthly Active Users (MAU), the customers who actively interact with your brand across your digital experiences.

── Braze公式 価格ページ（2026年8月19日取得）

登録者数ではなく、実際に接点を持った人の数で動きます。ここは引用からの読み方です。休眠が多いリストでは名簿の大きさと費用が比例しないことがあり、逆に、アプリやWebの利用が活発なサービスでは、配信を止めていてもMAUは動きます。ただしBrazeがどの行動を1MAUとして数えるかの算定条件は、公開ページには書かれていません。

2つめの軸 ── Brazeのデータポイントとは、何を数えているのか

データポイントとは、Brazeの契約上の課金単位です。こちらのほうが、実務で読み違えやすい軸です。公式ドキュメントは、契約上の定義をそのまま載せています。

“Data points” shall refer to a billable unit of use of the Braze Services, measured by a session start, session end, custom event, or purchase recorded, as well as any attribute set on an end user profile.

── Braze公式ドキュメント「Data points」（2026年8月19日取得）

訳すと、課金される単位は「セッション開始」「セッション終了」「カスタムイベント」「購買の記録」、そしてユーザープロファイルに設定した属性です。ドキュメントは続けて、こう書いています。

For clarity, each one of the earlier in this section-mentioned data (such as session start, session end, custom event, or purchase recorded, as well as any attribute) set to an end user’s profile at one point in time shall each count as a single data point.

── 同ドキュメント（2026年8月19日取得）

ある時点でプロファイルに設定されたものが、それぞれ1件として数えられます。つまり課金されるのは、配信の反応ではなく、記録された行動と属性の側です。配信した通数ではありません。

この定義について、ドキュメントはもう1点案内しています。

Data points are based on information logged against user profiles. You can find a more detailed breakdown of this definition in your Braze contract.

── 同ドキュメント（2026年8月19日取得）

データポイントの定義の詳細は、契約書に書かれている ── これが公式の案内です。公開ドキュメントで読めるのは定義の骨格までで、自社に適用される細部は契約側にあります。

メール開封とプッシュのクリックは、課金対象ではない

ここは知っておくと見積の読み方が変わります。ドキュメントは、数えないものを明示しています。

Data and events collected by default by the Braze Services, including, for example, push tokens, device information, and all campaign engagement tracking events, such as email opens and push notification clicks, are not counted as data points.

── 同ドキュメント（2026年8月19日取得）

※ 右列の原文は “including, for example” で列挙しており、これは例示です。ここに挙がっていないものが必ず課金対象、という意味にはなりません。

反応を細かく見ようとしたから費用が増える、という構図ではありません。

APIについても同じ扱いが書かれています。

For API ingestion, each billable update through /users/track follows the same rules as other profile updates: for example, each custom event logged counts as a data point, and custom attributes generally count per attribute updated in that request…

── 同ドキュメント（2026年8月19日取得）

/users/track 経由の課金対象となる更新は、プロファイル更新と同じルールです。カスタム属性は「原則として（generally）、そのリクエストで更新した属性ごと」に数えられる、と書かれています。

ここからは私たちの読み方です。1回のリクエストにまとめても、更新する属性の数が減らなければ件数は減らないことになります。ただし原文は “generally” と留保しています。自社の条件は契約時に確認する前提です。

なぜ、増えたことに気づけないのか

ドキュメントには、こう書かれています。

Data point usage is cached (not real-time) every 24 hours around 2 am ET. Until the cache refreshes, different dashboard users may see the same totals even if they open the tab at different times on the same day.

── 同ドキュメント（2026年8月19日取得）

使用量の表示はリアルタイムではなく、米国東部時間の午前2時ごろに24時間ごとに更新されます。日本時間ではおおむね午後3時ごろ（米国が夏時間の期間。冬時間は午後4時ごろ）。この換算は私たちの計算で、原文は “around 2 am ET” と幅のある書き方なので目安です。確認場所は Settings → Billing の「Total Data Points Usage」タブです。

引用の後半がもう1つの要点です。キャッシュが更新されるまでは、同じ日に別の時刻に開いた人も、同じ数字を見ます。「まだ増えていない」と、社内の全員が同時に誤認する形になります。

ここが、LINEのステップ配信と同じ構造です。配信ボタンを押す行為が無いので、増えていることに気づく機会が乏しくなります。データポイントは連携が動いているあいだ、こちらが何もしなくても増えます。

定義も確認場所も、公式ドキュメントに公開されています。連携の設計にこの2つを持ち込めているかどうかが、あとの見え方を決めます。

Braze公式が「変わるデータだけ更新する」ことを推奨している

公式ドキュメントには、注意書きとしてこう置かれています。

Don’t waste data points. Only update changing data!

To minimize data point usage, we recommend setting up a program to prevent sending the same unchanging data and only passing new and relevant data to Braze.

── 同ドキュメント（2026年8月19日取得）

変わっていないデータを送らない仕組みを、あらかじめ作ることを推奨しています。課金の対象になるデータについて、送る量を絞る設計を公式が明文で勧めている形です。私たちは、この記述を連携設計の前提として扱っています。

変わっていない属性を毎日書き戻せば、変わっていない分もすべて数えられます。属性は「設定されたこと」で数えられるからです。ここまでは、前掲の定義から導かれる読み方です。

ここからは私たちの観測です。ご相談をいただく中で、データポイントが増えている原因は、「データが足りないから足した」分ではありません。変わっていない属性を日次で書き戻しているケースが、少なくありません。生年月日、都道府県、会員ランク。生年月日は変わらず、都道府県が変わるのも稀です。会員ランクは月次で更新する設計もありますが、それでも日次ではありません。

これは運用の粗さではありません。基幹システムから日次で全件同期するのは、データ連携の作り方としては標準的です。課金の単位が「属性の数」であることが、連携を組む前段で共有されていないだけです。

では、何を先に決めるか

ここからは私たちの進め方です。3つあります（2つめは、前掲のBrazeの推奨に沿っています）。

• 更新頻度を、属性ごとに決める。日次で送るもの、変わったときだけ送るもの、初回だけ送るものに分ける。全件を同じ頻度で回すのをやめるところから始めます
• 差分だけ送る仕組みを、連携の中に入れる。Brazeが推奨している形です。あとから足すより、最初に入れておくほうが手戻りが少なく済みます
• 出し分けに使う属性を先に決めてから、連携する属性を決める。逆にすると、使わない属性を送り続けることになります

3つめが要点です。連携を組む時点では、どの属性で出し分けるかが決まっていないことが珍しくありません。だから「あとで使うかもしれないから全部入れておく」は、その時点では妥当な判断です。ただ、この判断はそのまま費用に乗ります。どの属性でセグメントを切るかが決まっていれば、送るものは自然に絞れます。

どの属性が必要かを決める作業は、配信の設計とは別の仕事です。MA用データ開発のページに、出し分けに使えるデータをどう作るかを載せています。

よくある質問

Brazeの費用は、結局いくらですか？

公式ページに金額の記載はなく、見積ベースです。公開されているのは「MAUに応じて増える」ことと、エディションが4段階（Go／Select／Pro／Enterprise）あることです。エディションごとのMAU閾値やデータポイント上限は公開されていないため、金額を推定できる情報は公になっていません。（出典：Braze公式の価格ページおよび公式ドキュメント「Data points」／2026年8月19日取得）

データポイントとは何ですか？

データポイントとは、Brazeの契約上の課金単位です。公式ドキュメントの定義では、セッション開始、セッション終了、カスタムイベント、購買の記録、そしてユーザープロファイルに設定した属性が対象で、それぞれが1データポイントとして数えられます。配信した通数ではありません。（出典：Braze公式の価格ページおよび公式ドキュメント「Data points」／2026年8月19日取得）

配信を増やすと、データポイントも増えますか？

配信そのものでは増えません。公式ドキュメントは、数えないものを明記しています。メールの開封、プッシュ通知のクリック。プッシュトークン、デバイス情報。いずれもデータポイントには数えません。増えるのは、セッション・イベント・属性として記録される側です。（出典：Braze公式の価格ページおよび公式ドキュメント「Data points」／2026年8月19日取得）

気づかないうちに増えているのを、どう防げばいいですか？

使用量の表示は24時間ごと（米国東部時間の午前2時ごろ）の更新で、リアルタイムではありません。キャッシュが更新されるまでは、同じ日に別の時刻に開いた人も同じ数字を見ます。そのため画面で気づくのは最大1日あとになります（この点は公式の記述からの導出です）。Braze自身が、変わっていないデータを送らない仕組みをあらかじめ作ることを推奨しています。属性ごとに更新頻度を決め、差分だけ送る形を連携の設計に入れるのが先です。（出典：Braze公式の価格ページおよび公式ドキュメント「Data points」／2026年8月19日取得）