よくある質問

このページでは、クラウドデータ取り込みに関してよくある質問への回答を提供します。

「CDI同期エラー」というメールが届いたのはなぜですか？

この種のメールは通常、CDIの設定に問題があることを意味します。一般的な問題とその解決方法を以下に示します。

CDIが認証情報を使用してデータウェアハウスまたはテーブルにアクセスできない

CDIの認証情報が正しくないか、データウェアハウス側で正しく設定されていない可能性があります。詳細については、データウェアハウス統合を参照してください。

テーブルが見つからない

正しいデータベース設定で統合を更新するか、database/tableなどの一致するリソースをデータウェアハウス上に作成してください。

カタログが見つからない

統合で設定されたカタログがBrazeカタログに存在しません。統合の設定後にカタログが削除された可能性があります。この問題を解決するには、統合を更新して別のカタログを使用するか、統合のカタログ名と一致する新しいカタログを作成してください。

「CDI同期の行エラー」というメールが届いたのはなぜですか？

このタイプのメールは、同期中に一部のデータを処理できなかったことを意味します。具体的なエラーを確認するには、BrazeでCDI > 同期ログに移動してログを確認してください。

CDI設定で「Time must be string in ISO8601 Format」エラーを修正するには？

このエラーは、CDIペイロード内のイベントtime値がサポートされている日時形式ではないことを意味します。

イベントおよび購入ペイロードの場合、timeを以下の形式でフォーマットしてください。

• ISO 8601文字列、または
• yyyy-MM-dd'T'HH:mm:ss:SSSZ

timeが省略された場合、Brazeはイベント時刻としてUPDATED_ATを使用します。

ペイロード要件の詳細については、Cloud Data Ingestionのテーブル設定を参照してください。

テスト接続やサポートメールのエラーを修正するにはどうすればよいですか？

• snowflake
• redshift
• bigquery
• databricks

CDI統合のメールアラート設定を更新するにはどうすればよいですか？

各統合には独自の通知設定があります。CDIページに移動し、更新したい統合名を選択します。通知設定セクションで、選択した統合に関するアラートの受信方法を更新できます。

将来のUPDATED_ATが統合と同期された場合はどうなりますか？

CDIはUPDATED_ATを使用して、どのデータが新しいかを判断します。将来のUPDATED_ATが同期された場合、その将来の日時より前のデータは処理されません。これを修正するには、以下の手順を実行してください。

1. UPDATED_ATを修正します。
2. Brazeと既に同期された古いデータを削除します。
3. 新しい統合を作成して、そのテーブルを再度処理します。

「同期された行数」がデータウェアハウスの数と一致しないのはなぜですか？

CDIはUPDATED_ATを使用して、同期中にどのレコードを取得するかを決定します。仕組みについてはこちらの図解をご覧ください。同期の実行開始時に、CDIはデータウェアハウスにクエリを実行し、以前に処理されたUPDATED_ATの値よりも後のUPDATED_ATを持つすべてのレコードを取得します。境界のタイムスタンプと完全に一致するレコードも、新しい行が同じタイムスタンプを共有している場合は再同期される可能性があります。クエリ実行時に取得されたレコードはすべてBrazeに同期されます。レコードが同期されない一般的なケースは以下のとおりです。

• すでに処理済みのUPDATED_AT値を持つレコードをテーブルに追加している場合。
• 同期で処理された後にレコードの値を更新しているが、UPDATED_ATを変更していない場合。
• 同期の進行中にレコードを追加または更新している場合。CDIクエリの実行タイミングによっては、レコードが取得されない競合が発生する可能性があります。

ヒント

これらの動作を今後回避するために、単調増加するUPDATED_AT値を使用し、スケジュールされた同期の実行中にテーブルを更新しないことをお勧めします。

大規模CDIインポートではUPDATED_ATの値をほぼ一意にする必要がありますか？

はい。大量のデータを処理する場合（たとえば約1,000万行を超える場合）、ソースデータのUPDATED_ATの値がほぼ一意であることを確認してください。同じタイムスタンプを共有する行が多すぎると、CDIが後続の実行で境界タイムスタンプの行を再選択する可能性が高くなります。これにより、重複同期やデータポイントの消費が増加する可能性があります。

CDIの境界動作の詳細については、重複タイムスタンプを持つ行の再同期を回避するを参照してください。

これらのSQLチェックはどこで実行しますか？

CDI統合で使用しているのと同じテーブルまたはビューに対して、データウェアハウスのSQLエディターで直接チェックを実行します。

• Snowflake: Projects > Worksheets（詳細については、Snowflake Worksheetsを参照してください）
• Redshift: Query Editor v2（詳細については、Using Amazon Redshift Query Editor v2を参照してください）
• BigQuery: BigQuery Studio SQLワークスペース（詳細については、BigQuery Studio introductionを参照してください）
• Databricks: SQLエディター（SQLウェアハウス）（詳細については、Databricks SQL editorを参照してください）
• Fabric: SQLクエリエディター

大規模な同期を有効化またはスケールする前に、以下のプロセスを使用してください。

1. 検証したいCDIソーステーブルまたはビューと同期ウィンドウを特定します。
2. ウェアハウスのSQLエディターを開き、CDIで使用しているのと同じデータベースとスキーマを選択し、ソーステーブルまたはビューへの読み取りアクセス権を持つロールを使用します。
3. 一意のタイムスタンプ数クエリを実行して、そのウィンドウ内に存在するUPDATED_ATの一意の値の数を測定します。
4. UPDATED_ATでグループ化して行数をカウントするクエリを実行し、異常に多い行数を持つタイムスタンプを見つけます。
5. 同一のタイムスタンプを共有する行が多い場合は、連続するバッチが段階的に新しいUPDATED_ATの値を使用するように取り込みプロセスを調整するか、タイムスタンプの精度を上げて行がより分散されるようにします。
6. 集中が軽減されるまで両方のクエリを再実行し、その後同期を起動またはスケールします。
7. 起動後、CDI > Sync Logで境界タイムスタンプにおける予期しない再同期ボリュームを監視します。

ウェアハウスで以下のようなチェックを使用してください。

1
2
3
4
5
6
7
SELECT
  COUNT(*) AS total_rows,
  COUNT(DISTINCT UPDATED_AT) AS distinct_timestamps,
  ROUND(COUNT(*) * 1.0 / NULLIF(COUNT(DISTINCT UPDATED_AT), 0), 2) AS avg_rows_per_timestamp
FROM YOUR_CDI_SOURCE_TABLE
WHERE UPDATED_AT >= CAST('2026-04-01 00:00:00' AS TIMESTAMP)
  AND UPDATED_AT < CAST('2026-04-02 00:00:00' AS TIMESTAMP);

1
2
3
4
5
6
7
8
9
SELECT
  UPDATED_AT,
  COUNT(*) AS rows_at_timestamp
FROM YOUR_CDI_SOURCE_TABLE
WHERE UPDATED_AT >= CAST('2026-04-01 00:00:00' AS TIMESTAMP)
  AND UPDATED_AT < CAST('2026-04-02 00:00:00' AS TIMESTAMP)
GROUP BY UPDATED_AT
ORDER BY rows_at_timestamp DESC
LIMIT 20;

ウェアハウスがLIMITをサポートしていない場合（たとえばFabric）、TOPなどの同等の構文を使用してください。

少数の行のCDI同期でも数分かかることがあるのはなぜですか？

CDI同期には、行の処理が開始される前に固定の起動時間が含まれます。この起動時間は同期のサイズに関係なくほぼ同じであるため、少数の行の同期でも数分かかることがあり、1分あたりの行数で見ると遅く感じられる場合があります。同期の合計時間は、ソースクエリの複雑さ、データの形状、およびデータウェアハウスの利用可能な容量によって異なります。詳細については、データウェアハウス統合を参照してください。

同期中に複数のレコードが同じIDを共有している場合、順序は保持されますか？

処理順序は100%予測可能ではありません。たとえば、同期中にテーブル内に同じ EXTERNAL_ID を持つ複数の行がある場合、最終的なプロファイルにどの値が反映されるかは保証できません。ペイロード列で同じ EXTERNAL_ID に対して異なる属性を更新している場合、同期が完了した時点ですべての変更が反映されます。

CDI同期から新しいユーザーが作成されないのはなぜですか？

CDI統合で既存のユーザーのみを更新オプションが有効になっている場合、Brazeにすでに存在するユーザーのみが更新され、新しいユーザーは作成されません。つまり、同期テーブルの行が既存のBrazeユーザーと一致しないEXTERNAL_IDを参照している場合、その行はスキップされます。

CDIを通じて新しいユーザーを作成するには、統合設定で既存のユーザーのみを更新トグルをオフにします。Data Settings > Cloud Data Ingestionに移動し、統合を選択します。

CDIのセキュリティ対策とは？

Braze側の対策

Brazeでは、CDIに対して以下の対策を講じています。

• すべての認証情報はデータベース内で暗号化されており、認証されたアクセス権を持つ特定の従業員のみがアクセスできます。
• 顧客のデータウェアハウスへのデータ転送には暗号化された接続を使用しています。
• Braze APIエンドポイントへのリクエストには、お客様にも推奨しているものと同じAPIキーおよびTLS接続を使用しています。
• ライブラリを定期的に更新し、セキュリティパッチを適用しています。

お客様側の対策

お客様およびチームの皆様には、以下のセキュリティ対策を設定することをお勧めします。

• 認証情報のアクセスを、CDIの運用に必要な最小限に制限してください。これは、特定のテーブルやビューに対してselect（およびcount）を実行できる必要があるためです。
• テーブルにアクセスできるIPを、公式に公開されているBraze IPに制限してください。