ダッシュボードの数字が合わないとき、何から調べるべきか。SnowflakeのDMFで測れる項目と業務独自の照合を分け、検知条件・通知後の対応・受入テストまで整理します。
ダッシュボードの売上が、元の業務システムと合わない。更新処理は成功しているのに、昨日の注文が一部載っていない。こうした問題は、処理の成功・失敗だけを見ていても見つかりません。Snowflakeでデータ品質を確認するなら、まず「いつまでに、何が、どの状態で揃えば業務に使えるか」を決めます。
最初に確認したいのは、必須項目の欠損、業務上のキーの重複、必要なデータの到着、元システムとの照合です。すべてのテーブルを同じ頻度で監視するより、毎朝の報告や請求など、誤りが判断に影響する集計から始めると、対応する担当者と優先順位も決めやすくなります。
データ品質チェックとは？処理監視との違い
処理監視は「取込ジョブが完了したか」、データ品質チェックは「取り込んだ内容を使ってよいか」を確認します。エラーなく取り込めても、注文番号が空欄だったり、同じ注文が二重に入ったりする可能性があります。逆に、件数が少ないという理由だけでは異常とは限りません。休業日や締め日など、業務の条件と一緒に判断します。
監視の単位も重要です。全社の合計件数が変わらなくても、ある店舗のデータが欠け、別の店舗の重複が増えれば相殺されます。会社・拠点・対象日など、業務担当者が異常を判断できる単位で確認項目を整理しましょう。
最初に決める4つの確認項目
| 観点 | 確認する内容 | 先に決める条件 |
|---|---|---|
| 欠損 | 必須項目が揃うか | 空文字・NULL・未設定コードの扱い |
| 重複 | 同じ業務データが二重に入っていないか | 注文番号だけか、明細番号も含むか |
| 更新遅延 | 必要な対象日のデータが期限までに揃うか | 業務日・取込時刻・休業日・訂正データ |
| 照合 | 元システムと件数・金額が整合するか | 取消・返品・税・丸め・集計対象の定義 |
たとえば「注文番号が重複したら異常」という条件は、注文ごとに1行のテーブルなら使えても、商品明細ごとに1行あるテーブルには合いません。先に1行が何を表すかを決め、複数の列で一意になる場合は、その組み合わせを確認します。NULLを0に置き換えて集計する前に、未入力と実際のゼロを区別することも必要です。
SnowflakeのDMFで測るものと、業務側で決めるもの
Snowflakeの公式ドキュメントでは、DMF（Data Metric Function）をデータの状態を測る部品として説明しています。測定値と、合否を判定する条件は別です。DMFが欠損件数を返しても、何件なら業務を止めるかまでは自動的に決まりません。
代表的な関数には、NULLの件数を確認するNULL_COUNT、重複を確認するDUPLICATE_COUNT、データの鮮度を確認するFRESHNESSがあります。ただし、単一列の重複検出だけで複合キーの正しさを保証したり、取込時刻だけで全拠点のデータ到着を保証したりはできません。業務独自の照合も別に設計します。
公式資料では、Data Quality MonitoringはEnterprise Editionが必要とされ、スケジュール実行するDMFにはサーバーレスの計算費用が発生します。導入前に利用中のエディション、必要な権限、対象テーブルと実行間隔を確認してください。監視項目を増やす前に、少数の重要な集計で検知の有効性と運用費用を確かめる進め方を勧めます。
架空の売上レポートで、検知から対応まで決める
以下は実績値ではなく、運用設計を考えるための架空の例です。「営業日の朝9時に、前営業日分の売上を全拠点で確認する」レポートを想定します。8時30分の時点で対象拠点がすべて揃っているかを照合し、未到着の拠点があれば担当者へ通知します。時刻や猶予は例示であり、自社の取込時間と利用時刻に合わせて調整します。
このレポートでは、直近の更新時刻を見るだけでは不十分です。対象拠点の一覧と実際に届いた一覧を比べ、前営業日の定義、タイムゾーン、遅れて届く訂正・返品の扱いを揃えます。取り込みが完了していても、必須項目の欠損や元システムとの金額差が残っていれば、正常として配信しない条件を検討します。
通知には、対象データ、業務日、検知した条件、確認先、対応期限を含めます。個人情報をそのままチャットへ流すのではなく、権限のある確認画面へ誘導します。担当者が確認するまで配信を止めるのか、暫定値と明示して使うのかは、業務責任者が事前に決めておきます。
開発会社へ依頼する前のチェックリスト
- 対象のレポートと利用者、数字を使う判断、必要になる時刻を整理する。
- 正しいデータの例と、欠損・重複・遅延・金額差の例を用意する。テスト用には匿名化したデータを使う。
- 項目ごとに、測定方法、合否条件、例外、通知先、対応責任者を記録する。
- 休日やデータが来ない日を含め、不要な通知と見逃しを受入テストで確認する。
- 再取込や修正後にチェックを再実行し、レポート再配信まで確認する。監視費用と設定変更の担当も決める。
受入テストでは、通知が届くことだけで完了にしません。意図的に欠損や二重取込を入れたテストデータで、検知・担当者の判断・修正・再確認まで実施します。集計の定義が変わった場合に、監視ルールも更新する手順を残すと、運用開始後のずれを防ぎやすくなります。
更新処理そのものの監視は、次の記事でも整理しています。品質チェックと組み合わせ、処理と内容の両方を確認してください。
よくある質問
すべての列で欠損をゼロにする必要がありますか？
必須項目と任意項目を分けて判断します。欠損が許される列まで一律にエラーにすると、通知の処理が追いつかなくなります。業務に影響する項目から、未入力・未確定・対象外の意味を整理してください。
件数が一致すれば、データは正しいと考えてよいですか？
件数の一致だけでは判断できません。別のレコードへの置き換わり、重複と欠落の相殺、金額や日付の変換誤りが残る場合があります。キー、対象期間、主要な金額、元データとの対応を組み合わせて確認します。
最初からすべて自動化するべきですか？
まず少数の重要なレポートで確認方法と対応手順を試し、意味のある通知かどうかを確かめてから広げる方法があります。ルールを測れることと、現場が異常に対応できることをセットで検証しましょう。
For fへのご相談では、対象レポート、元データ、困っている不一致の例を共有いただくと、確認範囲を整理しやすくなります。要件が固まる前でも、業務の整理からご相談いただけます。
参照した公式資料と確認日
仕様確認日：2026年11月3日。製品仕様は以下の公式資料を参照し、チェックリスト・運用例は当記事の提案として整理しています。提供条件や画面は変更されるため、導入時に最新の公式情報と自社環境を確認してください。
