Brazeのデータ連携で省略できるのは、データポイントではない

Cloud Data Ingestionとは、何をする機能なのか

Cloud Data Ingestionとは、Snowflake・Google BigQuery・Amazon RedshiftなどのデータウェアハウスやAmazon S3からBrazeへ、ユーザーデータおよびユーザー以外のデータを直接同期する接続を設定する機能です（出典：Braze公式ドキュメント「Cloud Data Ingestion」／2026年8月26日取得。この1文は、同ページの定義の記述と「Supported data sources」の記述を私たちが1文にまとめたものです。原文はこの下に引用しました）。

Braze Cloud Data Ingestion (CDI) allows you to set up a direct connection from your data storage solution to sync relevant user data and other non-user data to Braze.

── Braze公式ドキュメント「Cloud Data Ingestion」（2026年8月26日取得。訳：Braze Cloud Data Ingestion (CDI) を使うと、自社のデータ保管環境からBrazeへ、関連するユーザーデータおよびユーザー以外のデータを同期する直接の接続を設定できます）

「direct connection（直接の接続）」が要点です。間にアプリケーションを置かず、保管環境から直接つなぎます。つなげる先として、公式ドキュメントは6つを挙げています。Amazon Redshift、Databricks、Google BigQuery、Microsoft Fabric、Snowflake、Amazon S3です（出典：同ページ「Supported data sources」）。

扱えるデータの型も列挙されています。ユーザー属性（ネストしたカスタム属性、オブジェクトの配列、購読状態を含む）／カスタムイベント／購買イベント／ユーザー削除要求／カタログアイテムの5つです（出典：同ページ）。

カスタムイベントが名指しで入っている点は、押さえる価値があります。Brazeの離脱予測（Predictive Churn）は、公式ドキュメントに「カスタム属性ではなくカスタムイベントで動く」と明記されています（この1点だけは出典が別ページです。Braze公式ドキュメント「Troubleshooting – Predictive Churn」／2026年8月25日取得。詳しくはBrazeを使いこなせないのは、機能の問題ではないで扱いました）。イベントを入れる経路として、この機能が使えるということになります。

Cloud Data Ingestionにすると、何が省略できるのか

自社でAPIを叩く場合、送る側の仕組みを自分で持つことになります。どのテーブルから読むか、どう整形するか、いつ送るか、失敗したらどうするか。この部分がCloud Data Ingestionでは接続の設定に置き換わります。

ここからは私たちの整理です。省略できるものと、できないものを分けると次のようになります。

データポイントは、連携方式を変えれば減るのか

減りません。公式ドキュメントはこう書いています。

For customers on data points-based billing, data point billing for Cloud Data Ingestion is equivalent to billing for updates through the /users/track endpoint.

── Braze公式ドキュメント「Cloud Data Ingestion」（2026年8月26日取得。訳：データポイント課金のお客様の場合、Cloud Data Ingestionのデータポイント課金は、/users/track エンドポイント経由の更新に対する課金と同等です）

「equivalent（同等）」と書かれています。APIで送っていたものをCloud Data Ingestionに移しても、データポイントの数え方は変わりません。原文が「For customers on data points-based billing（データポイント課金のお客様の場合）」という条件を置いている点も、そのまま押さえておきます。契約の形によって当てはまり方が変わる書き方になっています。

送信量の上限（レートリミット）についても記述があります。

Braze Cloud Data Ingestion counts toward the available rate limit, so if you’re sending data using another method, the rate limit is combined between the Braze API and Cloud Data Ingestion.

── Braze公式ドキュメント「Cloud Data Ingestion」（2026年8月26日取得。訳：Braze Cloud Data Ingestionは利用可能なレートリミットに算入されるため、別の方法でもデータを送っている場合、レートリミットはBraze APIとCloud Data Ingestionで合算されます）

原文は「別の方法でも送っている場合」という条件つきです。APIとCloud Data Ingestionを併用しても、枠が2つになるわけではありません。

ここから先は私たちの読み方です。「連携方式を変えてデータポイントを下げる」という筋は、この記述からは出てきません。下げるなら、送る内容そのものを変えることになります。変わらないデータを送り続けないという考え方は出し分けとデータの記事で、費用の仕組みはBrazeの費用の記事で扱いました。ただし、変わらない行を送らないための仕組みについては、Cloud Data Ingestionのページには書かれていません。

同期は、どれくらいの間隔で走らせられるのか

Syncs can run as frequently as every 15 minutes or as infrequently as once per month.

── Braze公式ドキュメント「Cloud Data Ingestion」（2026年8月26日取得。訳：同期は最短で15分ごと、最長で月1回まで動かせます）

15分より短くしたい場合について、公式ドキュメントは「If you need syncs to occur more frequently than 15 minutes, contact your customer success manager or consider using REST API calls.」（15分より短い間隔での同期が必要な場合は、カスタマーサクセスマネージャーに連絡するか、REST APIの利用を検討してください）と書いています（出典：同ページ）。相談の余地がある書き方で、できないとは書かれていません。

ただしAmazon S3だけは挙動が違います。公式ドキュメントは「Amazon S3 file storage integrations are event-driven.」（Amazon S3のファイルストレージ連携はイベント駆動です）と書いています（出典：同ページ）。「15分〜月1回」は、S3以外の連携についての記述として読むことになります（これは私たちの読み方で、公式ドキュメントがそう書き分けているわけではありません）。

本稿で確認できた制限は4つです。

どの行が誰なのかは、どう決まるのか

もう1つ、連携を組む前に決めることがあります。行に載せる識別子です。公式ドキュメントは5種類を挙げています。EXTERNAL_ID（自社側で持っているユーザーID）／ALIAS_NAME と ALIAS_LABEL（この2列で1種類。別名とその種別の組み合わせ）／BRAZE_ID（Braze側で払い出されるID）／EMAIL（メールアドレス）／PHONE（電話番号）です（出典：同ページ。かっこ内の説明は私たちのもので、このページに書かれているものではありません）。

持たせ方に決まりがあります。公式ドキュメントは「Each row in your source table should contain a value for only one identifier type at a time, but your table can include columns for one, two, three, four, or all five identifier types.」（ソーステーブルの各行には、一度に1種類の識別子の値だけを含めるものとされています。ただしテーブル自体は、1つ・2つ・3つ・4つ、あるいは5種類すべての識別子の列を持てます）と書いています（出典：同ページ）。行は1種類だけとされ、テーブルは複数種類の列を持てます。この2つは揃っていません。

メールや電話番号をキーにするときは、もう1つ読んでおく記述があります。

If multiple profiles with the same email address exist, the most recently updated profile is prioritized for updates. If you include both email and phone, email is used as the primary identifier.

── Braze公式ドキュメント「Cloud Data Ingestion」（2026年8月26日取得。訳：同じメールアドレスを持つプロフィールが複数存在する場合、最後に更新されたプロフィールが更新の対象として優先されます。メールと電話番号の両方を含めた場合、メールが主たる識別子として使われます）

ここからは私たちの読み方です。同じメールアドレスのプロフィールが複数ある状態は、チャネルやシステムをまたいで顧客データを集めていれば残るもので、珍しいことではありません。その状態でメールをキーに連携すると、どのプロフィールが更新されるかは「最後に更新されたもの」で決まります。メールをキーにするかどうかは、その状態のまま連携すると何が起きるかを見てから決める論点になります。すでに組んである場合も、いま何をキーにしているかを確認するところから見られます。

電話番号についても同じく「If multiple profiles with the same phone number exist, the most recently updated profile is prioritized for updates.」（同じ電話番号を持つプロフィールが複数存在する場合、最後に更新されたプロフィールが更新の対象として優先されます）とされています（出典：同ページ）。

新規作成についても記述があります。「New users cannot be created using a Braze ID through Cloud Data Ingestion. To create new users, specify an external user ID or user alias.」（Cloud Data Ingestion経由では、Braze IDを使って新規ユーザーを作成することはできません。新規ユーザーを作成するには、外部ユーザーID（external user ID）またはユーザーエイリアス（user alias）を指定してください）と書かれています（出典：同ページ）。

Brazeのデータ連携は、どこから決めればよいのか

ここからは私たちの進め方です。組んだあとでも、決め直せます。3つあります。

• つなぐ前に、送るものを決める。すでに組んである場合は、いま送っている列を一度並べる。属性で足りるものと、イベントとして残す必要があるものを分ける。データポイントは連携方式では下がらないので、下げるなら送る内容の側で決めることになります
• 用途ごとにビューを分けて用意する。1テーブル1連携という制約があるため、すでに1つのテーブルにまとめてある場合、そのテーブルには2つめの連携を設定できません。用途を足すときは、そのテーブルからビューを分けて出すことになります
• 必要な間隔と、キーにする識別子を先に出す。15分で足りるのか、日次で足りるのか。15分より短い間隔が要る用途は、Cloud Data IngestionではなくAPIの検討対象になります（公式ドキュメントもREST APIの検討を挙げています）。識別子は、重複のないものを選べるかを見ます。選べない場合に何が起きるかも、同じ場で確認できます

つなぎ方より、送るものの側に判断が寄ります。Cloud Data Ingestionは実装を省くための機能で、このページには、データポイントを下げるための機能としては書かれていません。何を資産と呼ぶかを先に決める順序については顧客資産化の設計順序で扱いました。

よくある質問

Cloud Data Ingestionにすると、Brazeのデータポイントは減りますか？

減りません。公式ドキュメントは「For customers on data points-based billing, data point billing for Cloud Data Ingestion is equivalent to billing for updates through the /users/track endpoint」（データポイント課金のお客様の場合、Cloud Data Ingestionのデータポイント課金は、/users/track エンドポイント経由の更新に対する課金と同等です）と書いています。原文は「データポイント課金のお客様の場合」という条件つきです。送信量の上限についても「if you’re sending data using another method, the rate limit is combined between the Braze API and Cloud Data Ingestion」（別の方法でもデータを送っている場合、レートリミットはBraze APIとCloud Data Ingestionで合算されます）とあり、こちらは「別の方法でも送っている場合」という条件つきです。減らすなら送る内容の側を変えることになる、というのは私たちの読み方です。（出典：Braze公式ドキュメント「Cloud Data Ingestion」／2026年8月26日取得）

BrazeはSnowflakeやBigQueryと直接連携できますか？

できます。公式ドキュメントは対応するデータソースとして6つを挙げています。Amazon Redshift、Databricks、Google BigQuery、Microsoft Fabric、Snowflake、Amazon S3です。このうちAmazon S3はデータウェアハウスではなくオブジェクトストレージで、公式ドキュメントも挙動が異なると書いています。「Amazon S3のファイルストレージ連携はイベント駆動です」とされ、通知が届いたときに新しいファイルを取り込む形になります。（出典：Braze公式ドキュメント「Cloud Data Ingestion」／2026年8月26日取得）

同期は、どれくらいの頻度で走らせられますか？

公式ドキュメントは「Syncs can run as frequently as every 15 minutes or as infrequently as once per month」（同期は最短で15分ごと、最長で月1回まで動かせます）としています。15分より短い間隔が必要な場合については「カスタマーサクセスマネージャーに連絡するか、REST APIの利用を検討してください」と書かれています。できないとは書かれていません。（出典：Braze公式ドキュメント「Cloud Data Ingestion」／2026年8月26日取得）

Cloud Data Ingestionで、カスタムイベントも入れられますか？

入れられます。公式ドキュメントは対応するデータ型としてユーザー属性（ネストしたカスタム属性、オブジェクトの配列、購読状態を含む）／カスタムイベント／購買イベント／ユーザー削除要求／カタログアイテムを挙げています。なお、Brazeの離脱予測（Predictive Churn）は公式ドキュメントで「カスタム属性ではなくカスタムイベントで動く」と明記されています（この記述の出典は別ページです。Braze公式ドキュメント「Troubleshooting – Predictive Churn」／2026年8月25日取得）。イベントを入れる経路として使えるということになります。（データ型の出典：Braze公式ドキュメント「Cloud Data Ingestion」／2026年8月26日取得）

1つのテーブルに全部まとめて入れておけば足りますか？

足りない場面があります。公式ドキュメントは「You can set up only one integration per table or view」（1つのテーブルまたはビューにつき、設定できる連携は1つだけです）と書いています。すでに1つのテーブルにまとめてある場合、そのテーブルには2つめの連携を設定できません。用途を足すときは、そのテーブルからビューを分けて出すことになります。また「Each row should contain a single user ID and a JSON object with up to 250 attributes」（各行は1つのユーザーIDと、最大250個の属性を持つJSONオブジェクトを含むものとされています）という制限もあります。用途ごとにビューを分けるという進め方は、私たちのものです。（出典：Braze公式ドキュメント「Cloud Data Ingestion」／2026年8月26日取得）