Great Expectationsとは？GX Core 1.xの部品構成・実装手順と採用判断を解説【2026年版】

Great Expectations（GX）は、データがこうあるべきという条件をPythonのコードとして書き、実行時にその条件を満たすかを検査するオープンソースのライブラリです。行数・値域・欠損の有無といった約束事を「Expectation」という単位で宣言し、違反を検知した時点で後続処理を止められます。扱うのは、GX Core 1.x の部品構成と連結順序、実装手順、0.18系からの移行で壊れる箇所、dbt testやDatabricks DQXとの使い分けの4点。バージョンは 1.19.1（2026年7月24日リリース）を前提に記述します。

まとめ：Great Expectationsの採用可否を分ける判断軸

GXが工数に見合うのは、データの不備が下流の意思決定や顧客への出力へ直接波及する場合です。判断の軸は2つ。壊れたデータが混入したときに気づく仕組みが今あるか、検知したあとに誰が何をするかまで決められるか。後者が空白のまま導入すると、誰も見ないダッシュボードだけが増えます。

データの入力元が自社の管理下にあり、スキーマも値域も変わらないなら、テーブル定義の制約とdbt testで足ります。GXが効くのは、外部から届くファイルやAPIレスポンスのように送り手の都合で中身が変わる入力を抱えた構成。以降の章では、この判断軸を部品構成・実装手順・他ツール比較に照らして検証します。

Great Expectationsの定義とデータをテストする発想

まず製品の輪郭を、似た目的を持つ他の仕組みとの差から押さえます。

データに対する期待値をコードで書いて実行のたびに検証する仕組み

GXは、データセットに対する検証可能な表明を「Expectation」として定義し、実データへ突き合わせるPython製のライブラリです。公式ドキュメント（2026年8月時点）は、Expectationをユニットテストのアサーションになぞらえて説明しています。ExpectColumnValuesToNotBeNullのように、検査したい内容がそのままクラス名になっている点が特徴。

検証は実行のたびに走ります。期待値の集合をバッチデータへ適用し、各Expectationの成否と、失敗時は何行が条件を外れたかを返す。結果はJSONとして扱えるため、後続の分岐にも通知の材料にもできます。経路そのものの設計はデータパイプラインの構成要素と冪等性から考える設計判断で整理しています。

ユニットテストとの違いはコードではなくデータそのものを対象にする点

ユニットテストが検査するのは実装したロジックであり、入力を固定して出力の正しさを確かめます。GXが検査するのは流れてくるデータのほうで、ロジックが正しくても入力が壊れていれば失敗する。この違いが実行タイミングの差になります。

ロジックのテストはコード変更時に走らせれば足ります。データの検証はコードが変わらなくても毎回走らせる必要があり、CIで一度通ればよいものではない。パイプラインの各実行に紐づく常時の検査として組み込むことになります。

Apache 2.0のOSS版とGX Cloudで分かれる守備範囲

GX CoreはApache License 2.0で公開されており、pipで導入すればライセンス費用なしで本番運用まで持ち込めます。定義したExpectationも検証結果も自分の環境に置かれるため、データを外部へ出せない案件でも構成が成立する。GX Cloudは同社が提供するSaaSで、設定の共有や結果の閲覧をブラウザ側で担います。

選び分けは、検証定義を誰が書き誰が読むかで決まります。データエンジニアだけで完結するならOSS版で足り、業務部門の担当者が期待値をレビューする運用ならCloud側のUIを持つ意味が出ます。

GX Core 1.xを構成する部品とValidationまでの連結

1.x系は部品の役割分担がはっきりしており、実装は連結の順序をなぞる作業になります。

Data Contextの3形態と設定をどこへ永続化するかの選択

すべての操作の起点はData Contextです。設定・メタデータ・実行の入口をまとめて保持する部品で、gx.get_context()で取得します。公式ドキュメント（2026年8月時点）が挙げる形態は、設定をYAMLとしてファイルシステムへ保存するFile、メモリ上にのみ保持してセッション終了とともに消えるEphemeral、認証情報を通じてGX Cloud側へ保存する形態の3つ。

コンテナ実行やCIのように毎回作り直される環境ではEphemeralが素直です。Suiteをリポジトリで管理して再利用したいならFileを選ぶ。ここを曖昧にすると、検証定義が実行のたびに消える構成になります。

Data SourceからBatch Definitionまでのデータ接続の階層

データへの接続は3階層で表現されます。Data Sourceが接続先そのもの、Data Assetがその中のレコードの集まり（テーブルに相当）、Batch Definitionが検証対象として切り出す単位。pandasやSparkのほか、主要なSQLデータベースとオブジェクトストレージが並びます。

Batch Definitionの粒度が実務では効いてきます。テーブル全体を1バッチとするか、日付列で区切って当日分だけを検証するかで、実行時間も失敗時の切り分けやすさも変わる。日次で追記されるテーブルなら、区切るほうが運用が楽です。

ExpectationとSuiteをValidation Definitionが束ねる

個々のExpectationは単体でも実行できますが、実運用では複数をExpectation Suiteとしてまとめます。そのSuiteとBatch Definitionを明示的に結びつけるのがValidation Definitionで、どのデータをどの期待値の集合で検証するかがここで確定する。この分離により、同じSuiteを複数のテーブルへ使い回せます。

設計としては、Suiteを再利用可能な検査項目のセットとして育て、Validation Definitionを対象ごとに増やす形が扱いやすい。共通の必須列チェックと、テーブル固有の値域チェックを別Suiteへ分けると、項目の追加が特定の対象だけに閉じます。

Checkpointが本番実行を担いActionsで通知や連携へ繋ぐ

本番でValidationを走らせる主役はCheckpointです。複数のValidation Definitionを共通のパラメータでまとめて実行し、結果に応じてActionsを起動する。Actionsは通知の送信や結果の転送を担う処理で、チャットツールへの通知やData Docsの更新をここへ寄せます。

実装上の要点は、Checkpointを呼び出す場所をパイプラインのどこに置くかです。取り込み直後なら壊れたデータが下流へ流れる前に止められ、変換後なら加工ロジックの副作用まで検査できる。まずは下流への影響が大きい地点を1つ選んでください。

インストールからCheckpoint実行までの実装手順を順に追う

導入は検証用の小さなDataFrameから始めると、部品の連結を短時間で把握できます。

pipでの導入とPython 3.10から3.13までの対応範囲

導入はpip install great_expectationsだけで済みます。PyPIの配布情報（2026年8月時点）では最新版は 1.19.1 で2026年7月24日の公開、対応するPythonは3.10以上3.14未満。公式の互換性ページも3.10から3.13という範囲を示し、Pythonのリリースサイクルに追随する方針を明記しています。

接続先ごとの追加パッケージはextrasで分かれており、基本パッケージだけでは接続できない先がある点は先に押さえておいてください。Python 3.14系の環境なら、対応が入るまで3.13系のイメージを別に持つ判断が要ります。

DataFrameを検証する最小コードとBatchの取得までの流れ

公式のクイックスタート（2026年8月時点）は、pandasのDataFrameを対象にした最小構成を示しています。gx.get_context()でContextを取り、context.data_sources.add_pandasでData Sourceを追加し、add_dataframe_assetでAssetを、add_batch_definition_whole_dataframeでBatch Definitionを作る。そのうえでget_batchにDataFrameを渡してBatchを得ます。

検証そのものはbatch.validateにExpectationを渡すだけで、この時点ではSuiteもCheckpointも不要です。まずここまでを動かし、書きたい検査がExpectationとして表現できるかを確かめるのが最初の分岐点になります。

Suiteを組みCheckpointとActionsで定期実行に載せる手順

単発の検証が通ったら、運用形へ組み替えます。手順は4段階です。

1. Expectation Suiteを作り、検査したいExpectationを追加する
2. Batch DefinitionとSuiteをValidation Definitionで結び、Contextへ登録する
3. Validation Definitionを含むCheckpointを作り、必要なActionsを設定する
4. Checkpointの実行をスケジューラやパイプラインの処理へ組み込む

4段階目の組み込み先は既存のワークフロー基盤に合わせます。タスクの依存関係で処理順を制御しているなら、Apache Airflowの仕組みと使い方のタスクとしてCheckpoint実行を挟み、失敗時に後続タスクを止める形が扱いやすい。独立したcronで回すと、検証が通らないのに下流が動く状態を作り込みます。

Data Docsで検証結果を共有し関係者との合意形成に使う

Data Docsは、Expectation Suiteと検証結果から人間が読めるHTMLを生成する機能です。どの列にどんな期待値が設定され、直近の実行で何が失敗したかが一覧になるため、提供側との認識合わせに使えます。生成先はローカルのほか、オブジェクトストレージへ置く構成も取れます。

実務で効くのは、検証定義を仕様書の代わりとして見せられる点です。ただし更新はActionsで明示的に走らせる必要があり、放置すると古い結果が残ります。

0.18系から1.x系への移行で壊れる箇所と現行バージョンの前提

日本語の解説記事には0.18系を前提としたコードが多く残っており、そのまま写すと動きません。

1.0でCLIとYAML設定が廃止されPython記述へ一本化

1.0は互換性を切る形の変更でした。開発元の告知によると、YAMLとCLIによる設定はFluent APIへ置き換えられ、認証情報を除くすべての設定がPythonコード側へ移っています。2023年に非推奨となっていたblock-style Data Sourceも除去。CheckpointのValidationsリストも、Batch DefinitionとValidation Definitionを結ぶ形へ組み替えられています。

great_expectations initのようなCLI操作を前提にした手順書は、この時点で使えません。Data Contextの取得から設定の追加までをコードで書くのが現行の作法です。

1.17系で旧Batch引数が除去され0.x互換コードが停止

移行の猶予も段階的に閉じられています。2026年5月の1.17.0では、レガシーなBatch引数が除去されました。data_context、datasource_name、batch_kwargsといった旧来の引数をBatch APIへ渡していたコードは、現行版では動作しません。

0.18系そのもののサポートは2025年10月1日に終了しています。選択肢は1.x系へ書き直すか、バージョンを固定して更新を止めるかの二択。後者はセキュリティ修正も届かなくなるため、期限を切った移行計画を立てるほうが安全です。

現行は1.19系であり対応バックエンドは公式一覧で先に確認する

2026年8月時点の最新は 1.19.1 で、直近では1.18系から1.19系へ月内で複数のリリースが出ています。固定せずに運用すると挙動が変わる可能性があるため、requirements側で範囲を指定し、更新は検証環境で確かめてから適用する形が現実的です。

接続先の対応状況も版によって変わります。公式の互換性ページは、Athena、AWS Glue、Clickhouse、MySQLなどを「以前は動作していたが継続的な互換性は保証しない」という位置づけで示しています。これらへ繋ぐ構成なら、採用前に自環境で疎通と検証を通してください。

dbt testやDatabricks DQXとの使い分けと併用の線引き

データ品質を扱うツールは層ごとに分かれており、競合というより担当範囲の違いで整理できます。

dbt testとの違いはSQL層に閉じるか外側の入力まで見るか

dbt testはDWH内部のモデルに対する検査で、SQLで表現できる範囲を対象にします。変換の中で作られたテーブルが期待どおりかを確かめる用途では、追加のライブラリを入れずに済むぶん軽い。一方でDWHへ入る前のファイルやAPIレスポンスはdbtの管轄外です。

GXはPythonから扱えるものであれば対象にできます。pandasやSparkのデータフレーム、オブジェクトストレージ上のファイルまで届くため、取り込み前の検査を担わせられる。両方を導入している現場では、取り込み前をGX、変換後をdbt testという分担が素直です。

Databricks DQXとはPySpark前提かどうかで住み分ける

Databricks DQXは、PySparkのデータフレームを対象にした品質検証フレームワークです。Databricks Labsが開発しており、レイクハウスとの統合を前提にした作りです。実行基盤がDatabricksに固定されているなら、環境との噛み合わせで有利。

選び分けは、検証したいデータがどの実行環境に載っているかで決まります。処理がDatabricks上で完結するならDatabricks DQXの機能と使い方のほうが導入の摩擦が小さい。実行環境が複数にまたがる、あるいはpandasやSQLデータベースを直接検証したいならGXを選びます。

データ契約との関係は宣言する場と実行時に検査する場の役割分担

データ契約は、提供側と利用側の間でスキーマや品質の約束を明文化する取り組みです。約束を定義する場所であって、それ自体がデータを検査するわけではありません。GXは実行時に検査する側であり、契約で定めた条件をExpectationとして表現すれば、宣言と検査が繋がります。

両者を組み合わせる場合、契約側を単一の情報源に置き、Expectationをそこから導出する構成が崩れにくい。別々に手で書くと片方だけ更新されて乖離します。契約の定義形式や運用はデータ契約でスキーマ破壊を止める実装で扱っています。

Great Expectationsを採用しない条件と見合う業務要件

ここは判断を言い切ります。導入の是非はデータ量ではなく、壊れたデータが誰にいくらの損害を与えるかで決まります。

Great Expectationsを採用しない3条件と代替の置き方

次のいずれかに当てはまるなら採用しません。

• データの入力元が自社の管理下にあり、スキーマも値域も自分たちの変更でしか変わらない
• 検査したい内容がSQLで書ける範囲に収まり、対象がDWH内のテーブルだけで完結する
• 検知したあとの対応を誰が担うか決まっておらず、通知先だけが決まっている

3つ目で止まる案件が目立ちます。検証の仕組みは、失敗を受け取って動く人がいて初めて意味を持つ。当番も判断基準も決めずに導入すると、通知が無視される状態へ落ち着きます。1つ目と2つ目に当てはまるなら、テーブル制約とdbt testで足ります。

検証の失敗をどう扱うかを先に決めてから導入する運用設計の要点

導入前に決めておく項目は3つです。どのExpectationを失敗扱いにして処理を止めるか、止めない場合に結果をどこへ記録するか、失敗が続いたときに定義側と入力側のどちらを直すかの判断基準。この3点が決まっていれば、あとは実装の作業になります。

特に3つ目が運用の分かれ目です。値域の逸脱が続いたとき、業務の実態が変わったなら期待値のほうを直し、入力側の不具合なら送り手へ差し戻す。切り分ける人を決めずに始めると、失敗を消すために期待値を緩める運びになります。

ライセンス費用は無償でも維持工数が要る点をどう見積もるかの判断

GX CoreはApache License 2.0で、製品としての費用はかかりません。かかるのは、Expectationを書く工数、パイプラインへ組み込む工数、そして業務の変化に合わせて期待値を見直す継続的な工数。3つ目は導入後にずっと続くもので、見積もりから漏れやすい項目です。

費用に見合うのは、データの不備が金額へ変わる経路を持つ業務です。請求データの欠損、在庫数の異常値、機械学習モデルへ入る特徴量の分布ずれ、外部提供するレポートの数値。いずれも気づくのが遅れるほど手戻りが大きくなります。検証をどの層へ置くかの設計や既存パイプラインへの組み込みは、データ分析基盤構築・MLOps構築支援で実装まで含めて対応しています。

よくある質問

検討の場で繰り返し挙がる論点をまとめます。

Great Expectationsは無料で本番運用できますか？

GX CoreはApache License 2.0で公開されているため、製品ライセンスの費用なしで本番運用まで持ち込めます。検証定義も結果も自分の環境に置かれるので、データを外部へ送れない案件でも成立する。かかるのはExpectationを書く工数と、見直しの継続的な工数です。GX Cloudは別途の商用サービスで、ブラウザでの共有が必要な場合の選択肢になります。

0.18系のコードはそのまま1.x系で動きますか？

動きません。1.0でYAMLとCLIによる設定がPython記述へ一本化され、block-style Data Sourceも除去されています。さらに2026年5月の1.17.0でbatch_kwargsなどのレガシーなBatch引数が除去されたため、0.x系の書き方が残るコードは動作しない。0.18系のサポートは2025年10月1日に終了しており、公式の移行ガイドで対応関係を確認しながら書き直す形になります。

どのデータベースやファイル形式に対応していますか？

公式の互換性一覧（2026年8月時点）では、pandasとSparkに加えてPostgreSQL、Snowflake、BigQuery、Redshift、Databricks SQL、Microsoft SQL Server、Trinoなどが挙がっています。ストレージはAmazon S3、Google Cloud Storage、Azure Blob Storageに対応。AthenaやMySQLなど一部は継続的な互換性を保証しない位置づけです。

dbtを使っていてもGreat Expectationsを入れる意味はありますか？

入力データがDWHへ入る前の段階で壊れる可能性があるなら意味があります。dbt testが見るのはDWH内部のモデルであり、取り込み前のファイルやAPIレスポンスは対象外。外部から届くデータを扱う構成では、取り込み前をGX、変換後をdbt testという分担にすると検査の空白が埋まります。

検証に失敗したときパイプラインは自動で止まりますか？

止め方は設定で決めます。Expectationごとに重大度を指定でき、警告として記録するだけの項目と、失敗としてCheckpointの結果を不合格にする項目を分けられる。実際に後続処理を止めるのはワークフロー側の制御です。スケジューラのタスクとして実行し、不合格時に後続タスクを走らせない構成を組む形になります。

関連記事

• Databricks DQXとは？PySparkデータ品質検証フレームワークの機能と使い方【2026年最新】：Databricks上で完結する構成の検証を確認できます
• データ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説【2026年版】：期待値を宣言する側の仕組みを整理しています
• スキーマレジストリとは？互換性モードとスキーマ進化の実装・採用判断を解説【2026年版】：ストリーム経路でのスキーマ変更の制御を押さえられます
• データパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説【2026年版】：検証を組み込む土台の設計を確認できます
• Apache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説：Checkpoint実行を組み込む先の基盤を整理しています