月曜の朝、営業会議に出したダッシュボードで、先週の売上が前の週の半分になっていました。営業部長は「システムがおかしいんじゃないか」と言い、会議は数字の真偽の話で終わります。データ担当が調べると、金曜の夜にECサイトからの取り込みが途中で止まり、注文が半分しか入っていませんでした。dbt testsはすべて通っていました。原因を見つけるまでに半日、関係者に説明して回るのにもう半日かかります。そのうえ経営企画からは「この数字を使った資料がほかにもあるはずだから、一覧をください」と頼まれました。

この事故は、テストを増やしても防げません。dbt testsが確かめるのは「作った表のロジックが正しいか」で、「データが全部届いたか」は見ていないからです。データ品質ツールは、防ぎたい事故の種類で選びます。

防ぎたい事故の種類で、使う道具が決まる

事故の種類例dbt testsで防げるか向いている道具
変換ロジックの誤りJOINの誤りで行が重複した防げるdbt tests
決めた範囲を外れた値金額がマイナス、ステータスに想定外の値範囲を書けば防げるdbt tests、dbtの拡張パッケージ、Soda、Great Expectations
データが届いていない、量が足りない取り込みが途中で止まり、件数が半分ほぼ防げない鮮度と件数の監視（Soda、Elementary、Monte Carlo）
表の構造が勝手に変わったソース側で列が消えた、型が変わったほぼ防げないスキーマの検査（Soda）、自動監視（Monte Carlo）
誰も想定していなかった変化ある列の分布が、静かにずれ始めた防げない機械学習による異常検知（Elementary、Monte Carlo）
影響範囲が分からないどのダッシュボードが壊れたか追えない防げないリネージ（データの流れの追跡）を持つ製品（Monte Carlo）

冒頭の事故は3行目と6行目にあたります。件数の監視があれば金曜の夜に気づけました。リネージがあれば、経営企画への一覧はすぐに出せました。

状況から、最初に入れるものを決める早見表

自社の状況最初に入れるものこれを選ぶと後で困ること
dbtで変換を作り始めたばかりdbt testsの4つの標準テストdbtの外で起きる事故（未着、構造の変更）は見えないまま
dbtは定着したが、「数字が変だ」が月に何度も来る件数と鮮度の監視を1本ずつ（Soda、またはElementary）監視を増やしすぎると通知が鳴り続け、誰も見なくなる
Pythonでデータ処理をしていて、dbtを通らないデータが多いGreat Expectations概念が多く、最初の運用が回るまで時間がかかる
業務担当者とルールを一緒に決めたいSoda複雑な統計の検査や独自ロジックは書きにくい
データソースが数十以上あり、影響範囲が頭で追えないMonte Carlo価格が公開されておらず、予算の承認に時間がかかる

どれか1つに決める必要はありません。ただ、何本も同時に入れると、どの通知を誰が見るのかが曖昧になります。dbt testsを土台に、外側の監視を1つ足すところから始めます。

まずdbt testsを固め、拡張パッケージの保守状況を確かめる

dbtには、標準のテストが4つ入っています。値が重複しないか（unique）、空でないか（not_null）、決めた値のどれかか（accepted_values）、別の表に対応する行があるか（relationships）です。単体テストとの区別のため、設定のキーはtests:からdata_tests:に名前が変わりました。古いtests:も別名として使えます。

models:
  - name: orders
    columns:
      - name: order_id
        data_tests:
          - unique
          - not_null
      - name: order_status
        data_tests:
          - accepted_values:
              arguments:
                values: ['pending', 'paid', 'shipped', 'cancelled']

失敗の重さは、警告（warn）か停止（error）かで分けられます。失敗した行を表に保存する設定（store_failures）を入れておくと、原因の調査が速くなります。書き方の実例はdbt testsの実践にまとめています。

範囲や形式の検査を足すときに広く使われてきたdbt-expectationsは、元の公開元（calogica）のREADMEに「もう積極的には保守していない」と書かれています。Metaplaneが保守を続ける派生版があるので、新しく入れるならそちらを確かめてください。

件数と鮮度の監視を、1本ずつ入れる

冒頭の事故のような「届いていない」を見つける監視は、どの会社でも最初の1本になります。

Sodaで、業務担当者と読めるルールを書く

Sodaは、品質のルールをYAMLで宣言して検査するツールです。2026年10月時点のSoda Core v4は、「データ契約（data contract）」という形で、表が満たすべき条件を書きます。件数、鮮度、欠損、重複、決めた値以外の値を、次のように書けます。

dataset: prod_snowflake/PROD/SILVER/ORDERS

checks:
  - schema:
  - row_count:
      threshold:
        must_be_between:
          greater_than: 1000
          less_than: 1000000
  - freshness:
      column: ordered_at
      threshold:
        unit: hour
        must_be_less_than: 24
  - failed_rows:
      name: キャンセルした注文に売上が立っていない
      expression: order_status = 'cancelled' AND revenue > 0

columns:
  - name: order_id
    checks:
      - missing:
      - duplicate:
  - name: order_status
    checks:
      - invalid:
          valid_values: ['pending', 'paid', 'shipped', 'cancelled']
  - name: ordered_at
  - name: revenue

検査はsoda contract verify -ds ds_config.yml -c contract.ymlで実行します。schemaの検査は、ここに並べた列と実際の表を照らし合わせるので、表にあるべき列はすべてcolumnsに書きます。

ルールに日本語の名前を付けられるので、失敗の通知が業務担当者に届いた時点で何が起きたかが伝わります。「キャンセルした注文に売上が立っていない」のような業務のルールを、経理や営業と一緒にレビューできるのがSodaの持ち味です。

契約の前に確かめておくことが2つあります。1つ目はライセンスで、Soda Core v4はGitHubのLICENSEファイルにElastic License 2.0と書かれています。v3のブランチはApache License 2.0だったので、法務の確認項目に入れてください。2つ目は料金で、Soda Cloudには0ドルのFreeプランと、月750ドルのTeamプランがあります（2026年10月17日に料金ページで確認）。

dbt中心なら、Elementaryで件数の変化を学習させる

Elementaryは、dbtのパッケージとして入れる監視の道具です。件数の異常を見るテストは、日ごとの件数を過去14日分（既定）から学び、直近2日分（既定）がそこから外れていないかを確かめます。

models:
  - name: orders
    config:
      elementary:
        timestamp_column: "loaded_at"
    data_tests:
      - elementary.volume_anomalies:
          arguments:
            time_bucket:
              period: day
              count: 1

「件数が1,000件以上」のような固定の閾値を決めなくても、普段と比べて減ったことに気づけます。無償版（OSS）が見られるのは1つのdbtプロジェクトまでです。複数のプロジェクトや、dbtを通らない表まで見るなら有償のElementary Cloudになります。

Great Expectationsは、dbtを通らないデータをPythonで検査するときに選ぶ

Great Expectations（GX）は、Pythonで「データに何を期待するか」を書いて検査するフレームワークです。GX CoreはApache 2.0ライセンスで、2026年10月時点のドキュメントは1.24.0版です。1.0で書き方が大きく変わり、設定はほぼすべてPythonで書くようになりました。古い記事のコードは、そのままでは動かないことがあります。

import great_expectations as gx

context = gx.get_context()
data_source = context.data_sources.add_pandas(name="orders_source")
data_asset = data_source.add_dataframe_asset(name="orders")
batch_definition = data_asset.add_batch_definition_whole_dataframe("orders_batch")
batch = batch_definition.get_batch(batch_parameters={"dataframe": df_orders})

result = batch.validate(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="order_total", min_value=0, max_value=1000000
    )
)
print(result.success)

この書き方は対話的にルールを試すためのもので、結果は保存されません。定期的に回すときは、検査の定義をまとめた「チェックポイント」を作り、失敗したらSlackに通知する、検査結果の文書を更新する、といった後処理を付けます。

選ぶ場面は、Pythonでデータを加工していて、取り込み前のファイルや外部から受け取るデータのようにdbtを通らないデータを検査したいときです。dbtの中だけで足りるなら、dbt testsと拡張パッケージのほうが覚えることは少なく済みます。ホスティングまで任せたい場合は、無料のDeveloperプランから始められるGX Cloudもあります。

Monte Carloは、ルールを書ききれない規模になってから検討する

Monte Carloは、ルールを書かずに、表の鮮度・件数・構造・値の分布の変化を機械学習で見張る製品です。同社は、鮮度、件数、構造、分布、リネージの5つを「データオブザーバビリティの5つの柱」として説明しています。異常が起きた表から、どの下流の表やダッシュボードに影響するかまでたどれるのが特徴で、冒頭の「一覧をください」に答えるための道具です。

料金は、クレジットを購入して使った分を消費する形で、監視の数に応じて課金されます。料金ページに金額は載っておらず、問い合わせが必要です。いちばん小さいStartプランは、ユーザー10人まで、監視1,000件までです（2026年10月17日に確認）。

データソースが数十以上ある、ダッシュボードの数字の誤りが経営判断に直結する、品質の責任者が決まっている。この3つがそろうまでは、SodaやElementaryで件数と鮮度を見るほうが、費用に対する効果は出やすくなります。

通知を受ける人を、事故の種類ごとに決める

ツールを入れても、通知を誰も見なければ事故は防げません。通知の種類ごとに、最初に見る人と、その人が決めることを1行ずつ書いておきます。

通知の種類最初に見る人その人が決めること
件数・鮮度の異常データエンジニア（当番制）取り込みを再実行するか、ソース側に問い合わせるか
構造の変更データエンジニア変換を直すか、ソース側に戻してもらうか
業務ルールの違反（キャンセル注文の売上など）そのルールを決めた業務担当者データの誤りか、業務の例外かを判断する
経営向けダッシュボードの数字に影響する異常データ責任者ダッシュボードに「確認中」の表示を出すか

4行目を決めておくと、月曜の会議の前に「この数字は確認中です」と伝えられます。数字の真偽で会議が終わる事態は、それだけで避けられます。

調査にかかっている時間で、導入の順番を説明する

経営企画にツールの費用を説明するときは、いま調査に使っている時間を金額にします。たとえば月給45万円の担当者なら、会社の総コストは給与の約3倍で年1,620万円です。年1,900時間で割ると、時給は約8,500円になります。「数字が変だ」の調査に2人が週3時間ずつ使っていれば、年50週で300時間、約256万円です。金額は説明のための例です。

月やること終わったと言える目安
1か月目主要な表にdbtの4つの標準テストを入れ、失敗時の通知先を決めるテストの失敗が、決めた人に届いている
2か月目経営向けダッシュボードの元になる表に、件数と鮮度の監視を1本ずつ入れる取り込みの停止に、翌朝の会議より前に気づける
3か月目通知を受ける人の表を作り、業務ルールの検査を3つ足す業務担当者が、自分のルールの通知に対応している
4か月目以降調査にかかった時間を、導入前と比べる影響範囲の調査に時間がかかるなら、リネージを持つ製品を検討する

検査が失敗したときに後続の処理を止める仕組みは、オーケストレーションツールの選び方で扱っています。

よくある質問（FAQ）

dbt testsが全部通っているのに、数字が合わないのはなぜですか?

dbt testsが確かめるのは、作った表のロジックが正しいかどうかです。取り込みが途中で止まって件数が足りない、ソース側で列の意味が変わった、といった事故は、テストを書いていなければ通ってしまいます。件数と鮮度の監視を1本ずつ足すと、こうした「届いていない」事故に気づけるようになります。

dbt-expectationsとGreat Expectationsは、何が違いますか?

Great Expectationsは、Pythonで動く独立した検査のフレームワークです。dbt-expectationsは、その考え方をdbtのテストとして使えるようにしたパッケージです。dbtの中だけで検査するなら後者で足ります。ただし元の公開元は積極的な保守をやめているので、Metaplaneが保守する派生版を確かめてから入れてください。

Monte Carloは高そうですが、無料で近いことはできますか?

dbtを使っているなら、ElementaryのOSS版で、件数や鮮度の異常を過去の推移から見つけるテストを入れられます。見られるのは1つのdbtプロジェクトまでで、影響範囲の追跡はMonte Carloほど広くありません。まずOSSで件数と鮮度を見て、影響範囲の調査に時間がかかるようになったら、商用製品を比べます。

データ品質ツールは、いくつ入れればよいですか?

dbt testsに加えて、外側の監視を1つ入れるところから始めます。複数を同時に入れると、通知が重なり、どれを誰が見るのかが曖昧になります。データソースが増えて影響範囲が追えなくなった段階で、リネージを持つ製品を足すかを判断します。

データ品質の責任は、誰が持てばよいですか?

通知の種類ごとに、最初に見る人を決めます。件数や構造の異常はデータエンジニア、業務ルールの違反はそのルールを決めた業務担当者、経営向けの数字に影響する異常はデータ責任者、という分け方が出発点になります。ツールを入れる前に、この表を1枚作っておくと、通知が放置されにくくなります。

出典

「テストは通っているのに数字が変だ」が続いているなら、どの表に件数と鮮度の監視を最初に置くかの洗い出しから一緒に進めます。初回相談（30分・無料）で一緒に整理できます。