「うちのデータ、見るたびに少し違う気がする」。データを使い込むほど、こうした言葉が現場で増えていきます。テストを書こうにも、何をどこまで検証すれば安心と言えるか、判断が難しい。Great Expectationsは、この問いに「Expectation（期待）」という単位で答えるOSSのデータ検証フレームワークです。
名称のとおり、Great Expectationsは「データに何を期待するか」を明示的に書く道具です。dbt testsより表現の幅が広く、dbtの外側のデータも検証できます。基本概念から運用設計までを整理します。
中核概念：Expectation・Suite・Checkpoint
Great Expectationsの中核は3つの概念です。
| 概念 | 意味 |
|---|---|
| Expectation | 「この属性は0〜100の範囲」のような期待を1つ表す検証単位 |
| Expectation Suite | Expectationを束ねた、1つのデータセットに対する期待集合 |
| Checkpoint | 「このSuiteをこのデータに対して実行する」という運用単位 |
Expectationを書き、Suiteにまとめ、Checkpointとして繰り返し実行する、というのが基本の流れです。結果はData Docsという自動生成ドキュメントに残り、誰がいつ何を検証して何が失敗したかを後追いできます。
最小のExpectation
PythonでExpectationを直接書く例です。
import great_expectations as gx
# データソース接続を取得
context = gx.get_context()
data_source = context.data_sources.add_pandas("orders")
data_asset = data_source.add_dataframe_asset("orders")
batch = data_asset.add_batch_definition_whole_dataframe("orders").get_batch(
batch_parameters={"dataframe": df_orders}
)
# Expectationを書く
batch.validate(
gx.expectations.ExpectColumnValuesToBeBetween(
column="order_total", min_value=0, max_value=1000000
)
)
batch.validate(
gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id")
)
batch.validate(
gx.expectations.ExpectColumnValuesToBeInSet(
column="order_status",
value_set=["pending", "paid", "shipped", "cancelled"]
)
)標準で200以上のExpectationが用意されており、範囲・分布・正規表現・行数・一意性・参照整合性などをカバーします。dbt testsの基本（unique/not_null）に加えて、「分布が想定の範囲内か」「外れ値が一定以下か」のような統計的な検査が標準で書けるのが強みです。
プロファイリングから期待を自動生成する
「最初のExpectationを何にすればよいか分からない」という壁を、Great Expectationsはプロファイラ機能で乗り越えます。データを読み込ませると、統計的な特徴から「期待として書きそうな項目」を自動生成してくれます。
from great_expectations.experimental.rule_based_profiler import RuleBasedProfiler
profiler = RuleBasedProfiler(name="auto_orders_suite", config_version=1.0)
profiler.run(batch=batch)
suite = profiler.get_expectation_suite("auto_orders_suite")生成されたSuiteをそのまま使うのではなく、「業務的に正しいか」を人が見て調整するのが運用の現実です。自動生成は「叩き台を作る」ためのものと位置づけます。
Checkpointで運用する
Checkpointは、Suiteを定期実行する単位です。1つのCheckpointに、複数のSuiteと複数のデータセットを束ねられます。失敗時の通知（Slack、Email等）もここで設定します。
checkpoint = context.checkpoints.add(
gx.Checkpoint(
name="daily_orders_checkpoint",
validation_definitions=[validation_definition],
actions=[
gx.checkpoint.UpdateDataDocsAction(name="update_docs"),
gx.checkpoint.SlackNotificationAction(
name="notify_slack",
slack_webhook="${SLACK_WEBHOOK}",
notify_on="failure"
),
],
)
)
checkpoint.run()dbtとの組み合わせ
dbtと併用するパターンは2つあります。
| 使い分け | 使う場面 |
|---|---|
| dbt-expectations（dbt内） | dbtで作るモデルの基本検証。schema.ymlに宣言的に書ける |
| Great Expectations本家 | dbtの外側（取り込み前のソース、BI出力等）の検証や、高度な統計的検査 |
dbt-expectationsはGreat Expectationsの「期待表現」をdbtに移植したもので、dbt中心の運用なら、まずdbt-expectationsで足ります。dbt-expectationsとdbt testsの使い分けはdbt tests 実践にまとめています。dbtの外側でも検証したくなったら、本家Great Expectationsの導入を検討する流れです。
運用上のハマりどころ
- Expectationが増えすぎて遅くなる：全カラムに統計検査を入れると、検証時間が爆発します。「業務上重要な列だけ深い検査、他は基本検査」と濃淡をつけます。
- 偽陽性が増える：自動生成の期待は厳しすぎることがあり、運用初期は警告ばかり出ます。閾値を業務的に妥当な範囲に調整するレビューが必要です。
- 誰がSuiteを管理するか：データプロデューサー（ソースを生成する側）と相談せずに「期待」を一方的に固めると、ソース側の正当な変更が常にエラー扱いになります。所有者を明確にします。
- 結果の見方が定まらない：Data Docsを生成しても、誰が見て対応するかが決まっていないと意味がありません。失敗時の通知先と対応フローを最初に決めます。
向く・向かない場面
- 向く：Pythonでデータ処理しているチーム、dbtの外側の検証も必要、明示的に「期待」を書きたい、統計的な検査が欲しい
- 向かない：YAMLで完結させたい（→Soda）、書きたくない・自動で異常を見つけたい（→Monte Carlo）、小規模でdbt testsで足りる
まとめ
- Great Expectationsは「期待を明示的にコードで書く」OSSのデータ検証フレームワーク。
- Expectation→Suite→Checkpoint→Data Docs、の流れで構築・実行・記録する。
- プロファイラで叩き台を自動生成。人が業務的に調整する。
- dbt中心ならdbt-expectationsで足り、外側の検証が必要になったら本家を入れる。
- 運用は所有者と閾値の調整、通知と対応フローをセットで設計する。
全体像はデータ品質ツール選定ガイド、隣接の選択肢はSoda とは・Monte Carlo とはにあります。データ品質の設計やツール導入の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. Great Expectationsの学習コストは、現実的にどのくらい？
A. 初めて触る人なら、最初の使えるCheckpointを動かすまで1〜2週間が目安です。Suite・Checkpoint・Data Docsという独自概念の理解と、PythonとYAMLの両方を行き来する運用に慣れる必要があります。dbt-expectationsから入ると、概念に触れずに使えるので学習コストが下がります。本家GEはdbtの外側の検証が必要になったタイミングで導入するのが、コスト効率が良いです。
Q. GX Cloudは使うべきですか？
A. 用途と予算次第です。GX CloudはGreat Expectations社が提供するマネージドSaaSで、ホスティング・通知・コラボ機能が付いて運用が楽になります。OSS版で十分回るチームならわざわざ移行は不要です。OSS版の運用負荷が重く感じる、複数チームで結果を共有したい、SLAが必要、といった段階で検討します。
Q. CI/CDで実行する場合、何に気をつけますか？
A. 大きく3点です。第1に、検証時間がパイプライン全体の中で許容範囲か。重い統計検査は本番ジョブから外し、夜間バッチに回します。第2に、失敗時に止めるかWarningで続行するかの設計。「止めると業務影響、間違ったデータが流れるともっと影響」を天秤にかけます。第3に、検証結果のアーティファクト保存。Data Docsを成果物として残し、後から追跡できるようにします。
Q. Great Expectationsで「未知の異常」も見つけられますか？
A. 限定的にしか見つけられません。Great Expectationsは「明示的に書いた期待に対する違反」を検出する道具で、書いていない種類の異常は気づきません。「未知の異常」も見つけたいなら、Monte Carloのような機械学習ベースのオブザーバビリティ製品が向きます。GEは「想定どおりか」、Monte Carloは「想定外が起きていないか」と役割を切り分けると整理しやすいです。