データ品質テストの選定は「どこを守るか」で決まります。dbtモデル内部のカラムはdbt tests、ソースやパイプライン横断の契約はGreat Expectations(GE)またはSoda、というのが2026年時点の現実解です。本記事では、これら3ツールの守備範囲と特性を整理し、コード例とともに選定判断をお伝えします。

データ品質テストツールの必要性

データ品質の問題は、ダッシュボードに数字が並んで初めて発覚するケースが多いものです。「昨日の売上がゼロですよ」と役員から指摘されてから調査を始めるのでは遅く、業務とデータチームの信頼関係が音を立てて崩れていきます。こうした事故を未然に防ぐためのメカニズムがデータ品質テストツールです。

類似の仕組みとしてはdbt testsが広く普及していますが、dbt testsは「モデルとして取り込んだ後のカラム品質」に特化しており、ソースデータが届いた時点の検証や、複数のパイプラインを跨いだ一貫性検証にはやや力不足です。Great ExpectationsとSodaは、この守備範囲のギャップを埋める存在として位置付けられます。詳細はデータオブザーバビリティ入門記事(A-15)もあわせてご覧ください。

Great Expectationsの特徴

Great Expectations(以下GE)はPythonベースのデータ品質フレームワークで、2018年ごろから急速にコミュニティを拡大してきました。中核概念は「Expectation(期待値)」と呼ばれる宣言的な品質ルールで、例えば「このカラムは非NULLで、値は0〜100の範囲に収まる」といった条件をPythonまたはJSONで定義します。

特筆すべきは「Data Docs」と呼ばれる自動ドキュメント生成機能で、実行結果をHTMLレポートとして出力し、誰が・いつ・どの期待値を満たしたかをチームで共有できます。高い柔軟性の裏返しとして設定ファイルの階層が深く、初学者にはとっつきにくい一面があるのも事実です。

import great_expectations as gx

context = gx.get_context()
batch = context.sources.pandas_default.read_csv("orders.csv")

# カラムの非NULL・値範囲・一意性を宣言
batch.expect_column_values_to_not_be_null("order_id")
batch.expect_column_values_to_be_unique("order_id")
batch.expect_column_values_to_be_between("amount", min_value=0, max_value=1000000)

result = batch.validate()
print(result.success)

Soda(soda-core)の特徴

SodaはYAMLベースで品質チェックを定義する後発ツールで、SodaCLという専用DSLにより読みやすい記述を実現しています。「最小5,000件以上あること」「NULL率は1%未満であること」といったチェックを自然言語に近い形で書けるため、データエンジニア以外のメンバーもレビューに参加しやすい設計です。

OSSのsoda-coreとSaaSのSoda Cloudが提供されており、後者ではダッシュボード、インシデント管理、データコントラクト機能が利用できます。GEと比較して学習コストは低く、最初の一歩を踏み出しやすい点が強みです。

checks for orders:
  - row_count > 1000
  - missing_count(order_id) = 0
  - duplicate_count(order_id) = 0
  - invalid_percent(amount) < 1%:
      valid min: 0
      valid max: 1000000
  - freshness(created_at) < 1d

dbt testsとの比較

dbt testsはdbtモデルに紐づく品質テストで、schema.ymlに宣言するだけで実行できる手軽さが魅力です。unique、not_null、accepted_values、relationshipsといった組み込みテストに加えて、dbt-utilsなどのパッケージで補強できます。dbtプロジェクト内のモデルに対する最初の防衛線としては十分に機能します。

ただし、ソースデータが到着する前段のファイルや、dbtで管理していない外部システムとの整合性検証には向きません。ここでGEやSodaを併用することで、パイプライン全体の品質ゲートを構築できます。下表に3ツールの守備範囲を整理しました。

version: 2
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
観点dbt testsGreat ExpectationsSoda
主な守備範囲dbtモデルのカラムソース〜変換全般ソース〜変換全般
定義形式schema.ymlPython / JSONYAML(SodaCL)
学習コスト低中〜高低〜中
ドキュメント生成dbt docsData Docs(HTML)Soda Cloud UI
向く用途モデル内品質複雑な検証ロジック軽量な契約検証

徹底比較

ここからはGEとSodaの2ツールに絞って、運用上のポイントを掘り下げます。言語仕様、DWH対応、CI/CDとの相性、ドキュメント生成、商用版の有無など、選定で効いてくる項目を一覧で整理しました。

比較項目Great ExpectationsSoda(soda-core)
主要言語PythonYAML(SodaCL) + Python実行
定義方式Expectation SuiteSodaCLチェック
対応DWHSnowflake / BigQuery / Redshift / Databricks / Postgres 他Snowflake / BigQuery / Redshift / Databricks / Postgres 他
CI/CD統合CLI + Airflow / Prefect / GitHub ActionsCLI + Airflow / dbt / GitHub Actions
ドキュメント生成Data Docs(静的HTML)Soda Cloud(SaaS)
学習コストやや高い(概念階層が深い)低い(YAMLで書ける)
商用版GX CloudSoda Cloud
コミュニティGitHub Star 9000+ 規模で歴史あり比較的新しいが成長中
向くチーム規模中〜大規模、検証ロジック多め小〜中規模、導入スピード重視

GEはPythonの柔軟性を活かしてカスタム検証ロジックを組み込めるため、金融・医療のように業界固有のバリデーションが多い領域で重宝されます。一方のSodaは、YAMLで完結する軽量さが武器となり、立ち上げ期のチームや非エンジニアも触れる環境での採用が進んでいます。

選定判断

以下の推奨表は、よくある状況ごとに適した組み合わせを示したものです。絶対解ではなく出発点として活用してください。

状況推奨組み合わせ理由
dbt中心のスタートアップdbt tests + Soda軽量に契約検証を追加できる
規制業界で複雑な検証が必要dbt tests + Great ExpectationsPython実装で柔軟に対応可能
非エンジニアもレビューに参加SodaYAMLが読みやすい
既にAirflow中心の運用Great ExpectationsOperatorでDAG統合が成熟
dbt未導入のパイプラインGreat ExpectationsまたはSoda単独スタンドアロンでも実用十分

まとめ

データ品質テストは「事故ってから対応」ではなく「事故らないための仕組み」へと重心が移りつつあります。dbt testsで内部を守り、GEまたはSodaでソースや境界を守る――この二段構えが、壊れにくいデータ基盤の基本戦略です。チームの規模と守りたい領域から逆算して、ツールを選定してください。

よくある質問

dbt testsだけでは不十分ですか?

dbt testsはモデル内のカラム品質チェックには優秀ですが、ソースデータの品質検証やパイプライン横断のテストにはGreat ExpectationsやSodaの併用が効果的です。dbtで扱わない外部ファイルやAPIからの取り込みデータの検証もカバーできます。

Great ExpectationsとSodaのどちらが簡単ですか?

SodaはYAML定義でシンプルに始められるため導入のハードルが低いです。Great ExpectationsはPythonベースで柔軟性が高いですが、概念階層が深く学習コストはやや高めです。導入スピードを重視するならSodaが先手となります。

データ品質テストをCI/CDに組み込めますか?

はい。いずれのツールもCLIベースで実行でき、GitHub ActionsやAirflowのタスクに組み込んでCI/CDパイプラインの一部として自動実行できます。PRマージ前のチェックや日次バッチ後の検証で活用されています。