データ基盤を運用し始めると、最初はdbt testsで「主キーが一意か」「値が想定範囲か」を見ていれば足ります。けれども半年〜1年経つと、データソースが増え、利用者からの「数字が変だ」という指摘が出始めます。dbt testsは通っているのに、現場では数字が合わない。テストの外側に、見えていない品質問題があったわけです。
ここで登場するのが、データ品質ツールです。代表的な3つ、Great Expectations・Soda・Monte Carloは、それぞれ違う角度から品質を支えます。3者を整理し、自社の規模と運用に合った選び方を考えていきます。
なぜdbt testsだけでは足りないのか
dbt testsは、変換ロジックの隣にテストを置く仕組みです。dbtで作っていないテーブル、BIで集計された数値、外部から提供されたファイル、これらは射程外です。実際に現場で発生する品質問題は、こうした「dbtの外側」に多くあります。
| 問題のタイプ | 例 | dbt testsで防げるか |
|---|---|---|
| 変換ロジックのバグ | JOINミスで重複が発生 | ○ |
| ソースデータの異常 | 取り込みが半量になった | △（テスト次第） |
| パイプラインの停止 | 昨日のデータが届いていない | × |
| 異常値の検知 | 売上が突然10倍 | ×（範囲指定があれば一部） |
| スキーマの突然の変更 | カラムが消えた・型が変わった | × |
| downstream影響の追跡 | どのダッシュボードが影響を受けたか | × |
dbt testsは「ロジックが正しいか」を守るためのもので、「データが届いているか」「データの形が崩れていないか」「異常な値が来ていないか」を継続監視する役割は別のツールが必要です。dbt testsの基本はdbt tests 実践にまとめています。
3つのツールの位置づけ
| Great Expectations | Soda | Monte Carlo | |
|---|---|---|---|
| カテゴリー | データ検証フレームワーク | データ品質プラットフォーム | データオブザーバビリティ |
| 主な使い方 | コードで検証ルールを書く | YAMLでチェックを記述 | 機械学習で異常を自動検知 |
| OSS/SaaS | OSS中心、SaaS（GX Cloud）あり | OSS（Core）＋SaaS（Cloud） | SaaSのみ（商用） |
| 得意領域 | 明示的なバリデーション | シンプルな宣言と運用 | 未知の異常検知・影響追跡 |
| 学習コスト | 高め（Python・概念多め） | 低め（YAMLで書ける） | 低（SaaSで自動） |
| 導入規模感 | 個別パイプライン | チーム・全社 | 全社・データプラットフォーム |
3者は競合というより、レイヤーが違います。「ルールを明示的に書きたい」のがGreat ExpectationsとSoda。「ルールを書かなくても異常を見つけたい」のがMonte Carloです。こう覚えると整理しやすいでしょう。
それぞれの強みと弱み
Great Expectations
OSSのデータ検証フレームワークとして広く普及しています。「Expectation」と呼ばれる検証単位（「このカラムは0〜100の範囲」「行数は10万〜100万」など）をPythonで書いて、データに対して実行します。バリエーション豊富で、「期待値」をプロファイルから自動生成できる機能も備えます。
強みは、明示的に検証ルールを書ける表現力です。弱みは、概念が多く学習コストが高いこと、PythonとYAMLの両方を行き来する運用が必要なことです。詳細はGreat Expectations とはで扱います。
Soda
「SodaCL」というYAMLベースのDSLで品質チェックを記述する、運用しやすさを重視したツールです。Soda Coreは無料のOSS、Soda CloudはSaaSで通知・コラボ機能が加わります。dbtのプロジェクトに併設して動かす運用がよく見られます。
強みは、宣言的で読みやすいチェック記述と、軽量な導入感です。弱みは、Great Expectationsほどの細かい表現力はなく、複雑なロジックには向かないことです。詳細はSoda とはで扱います。
Monte Carlo
カテゴリーが違う、商用のデータオブザーバビリティ製品です。ルールを書かなくても、機械学習でテーブルの行数・更新頻度・スキーマ・分布の異常を自動検知します。さらに、データリネージ（どの上流から流れてきて、どの下流に影響するか）を追跡できるのが特徴です。
強みは、未知の問題を見つけ、影響範囲を即座に把握できることです。弱みは、商用SaaSのみで、規模に応じた費用がかかること、組織のデータ基盤全体に導入する前提のスケール感であることです。詳細はMonte Carlo とはで扱います。
選定の判断軸
3つの中から、自社に合うものをどう選ぶか。判断軸は4つあります。
| 判断軸 | 選び方 |
|---|---|
| 規模・予算 | 小〜中規模・OSS中心：Soda、明示検証が必要：Great Expectations、全社規模・予算あり：Monte Carlo |
| 記述スタイル | YAMLで運用したい：Soda、Pythonで細かく書きたい：Great Expectations、書きたくない：Monte Carlo |
| 検知の方向性 | 「想定どおりか」を確認したい：GE/Soda、「未知の異常」を見つけたい：Monte Carlo |
| 影響範囲の可視化 | 不要：GE/Soda、必要：Monte Carlo |
1つに絞れない場合、組み合わせも普通にあります。「dbt testsで基本検証＋Sodaで宣言的なチェック＋Monte Carloで未知の異常監視」のように、レイヤーで使い分ける構成は実務で見かけます。
どこから始めるか
いきなり全社展開すると、運用が回りません。まずは1つのパイプラインから始め、効果を確かめてから広げましょう。
- ステップ1：dbt testsで基本的な検証（unique, not_null, accepted_values）を入れる
- ステップ2：dbt-expectationsで範囲・フォーマット・行数の検査を足す
- ステップ3：dbtの外側で監視したいテーブルが出てきたら、SodaかGreat Expectationsを導入する
- ステップ4：影響範囲が読めない事故が増えてきたら、Monte Carloのようなオブザーバビリティを検討
順番が大事で、土台のdbt testsを飛ばして高機能ツールから入ると、運用が複雑なまま品質も上がりません。dbt testsの基本はdbt tests 実践、dbtでの層分けはdbt実装ガイドを踏まえてから上に積む構成が現実的です。
まとめ
- dbt testsは変換ロジックの検証。「dbtの外側」の品質問題には別のツールが必要。
- Great Expectationsはコードで明示的な検証を書きたい場面に。表現力は高いが学習コストも高い。
- Sodaは宣言的YAMLで運用したい場面に。導入が軽くチーム展開しやすい。
- Monte Carloはルールを書かずに異常を見つけ、影響範囲も追える商用オブザーバビリティ。
- 順番はdbt testsから始め、必要に応じて上に積む。一気に全社導入はしない。
各ツールの詳細はGreat Expectations とは・Soda とは・Monte Carlo とはにまとめています。データ品質の設計やツール選定の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. dbt-expectationsとGreat Expectationsは何が違いますか？
A. 名前は似ていますが別物です。Great Expectationsは独立したデータ検証フレームワーク（Pythonで動作）です。dbt-expectationsはGreat Expectationsの「期待値の表現」をdbtで使えるように移植したパッケージです。dbt中心の運用なら、まずdbt-expectationsで足ります。dbtの外側でも検証したくなったら、本家Great Expectationsの導入を検討する流れになります。
Q. Monte Carloは高そうですが、無料代替はありますか？
A. オブザーバビリティ領域には、OSSの選択肢としてElementaryやre_dataがあります。dbtプロジェクトに組み込んで、ジョブ実行・テスト結果・統計を可視化できます。Monte Carlo・Bigeye・Anomaloのような商用製品ほどの自動異常検知や影響追跡は限定的ですが、まず雰囲気を掴むには十分です。導入のステップとしては、無料OSSで価値を確認してから商用への投資判断をするのが現実的です。
Q. 3つとも導入する必要はありますか？
A. 必要ありません。むしろ複数導入すると運用が重くなり、誰がどのツールの結果を見るのかが曖昧になります。dbt testsを土台に、外側の品質監視として1つ追加する構成で十分なケースが多いです。組織の規模が大きく、データソースが多数あり、影響追跡まで必要な段階になって、はじめてオブザーバビリティ製品の導入を検討します。
Q. データ品質の責任は、誰が持つべきですか？
A. ツールだけでは品質は守れず、責任者を決めることが重要です。データプロデューサー（ソースを生成する側）、データエンジニア（変換を担う側）、データコンシューマー（使う側）で、何をどこまで責任を持つかを明確にします。ツールは、各責任者が役割を果たすための道具と位置づけてください。「ツールを入れたから品質が上がる」のではなく、「責任の所在に合わせてツールを当てる」のが順序となります。