はじめに
データ活用者にとって、データの品質は想像以上に悩みどころが多い。
データ分析で事象の把握やインサイトの抽出を行おうとしたり、モデルの精度を上げたりしようとしても、対象データの品質に問題があって思うように業務が進まないこともままあり…
MLOps的なプロダクト運用では、モデルやバッチ処理の自動化が進んでいる分、ちょっとしたデータの変化や異常が気づかれにくい。異常値やデータ欠損にすぐ気づく環境が整備されていればいいが、スピード感を求める現場ほどその辺りがおろそかになっているように感じる。
だが思っているよりも短いスパンで変化するデータ品質を蔑ろにしていると、溜まった負債に後々苦しめられることになる。
この記事では、データ分析やMLOpsの現場で直面する「データ品質」について、データ品質テストという観点から継続的にデータの品質を高く保つための管理方法について紹介する。
また、この記事を作成するうえで下記書籍を参考にした。
- [エンジニアのための］データ分析基盤入門＜基本編＞（amazon）
1. データ品質とは
データ品質とは、
「正しいデータが、正しいときに、正しいユーザに、正しい意思決定をするために存在していること」
を意味する。
「正しい」データとは単なる正確さだけでなく、ビジネス価値や業務目的に資する状態を指すと考えている。また、“品質”は一度保証すれば終わりではなく、継続的な管理・改善が不可欠だ。
データ品質の6要素
データ品質は、主に以下の6つの観点で評価できる。
| 要素 | 内容 | テスト例 |
|---|---|---|
| 正確性 | データが実態を正しく反映しているか | if-thenテスト（ロジックを満たしているか） 割合制御（件数や統計量の前日比などが異常でないか） |
| 完全性 | 必要なデータが全て揃っているか | Nullチェック（Null数は許容範囲内か） 件数チェック（データ件数が想定通りか） |
| 一貫性 | 複数データ間やシステム間で整合しているか | 内部整合性（テーブル内でフォーマットに一貫性があるか） 外部整合性（テーブル間でフォーマットに一貫性があるか） スキーマテスト（スキーマが想定と一致しているか） |
| 有効性 | データがビジネスルール・型を満たしているか | レンジテスト（数値が特定の範囲内か） 辞書（カテゴリが用意された項目に収まっているか） |
| 適時性 | 必要なタイミングで正しいデータが存在するか | タイムラインネス（想定した時間内に期待したデータが存在するか） |
| ユニーク性 | 重複していないか | 重複判定（PKが一意か） |
Tip:
これらはすべて同時に完全に満たすことが難しいため、プロジェクトやサービスの目的・リスク・コストと相談しながら、重点を絞ったり達成割合を設定して管理したりすることが現実的である。
2. データ品質管理とは
データ品質管理とは、データ品質を可視化し、適切なアクションをとり、改善するまでの一連の流れである。
データが蓄積・流通する中で、品質は自然に劣化するため、「気づいたら品質が落ちていた」を防ぐ仕組みが重要である。
データ品質管理の3原則
データ品質管理は次の3つの原則に基づきます。
-
予防（Prevention）
- 品質問題が発生しないよう未然に防ぐ
- 例）バリデーション（入力値制約）、設計段階でのデータガバナンス
-
検知（Detection）
- 品質問題を早期に見つける
- 例）定期的なデータ品質テスト、異常値の自動検出
-
修理（Correction）
- 発生した問題を速やかに修正・恒久対策する
- 例）自動リカバリ処理、修正履歴の記録、再発防止の仕組み
冒頭でも述べた通り、この記事では特に検知を実践するための品質テストについて深堀していく。
3. 品質テストの実践
品質テストは「検知」のための最重要ステップである。
現場（特に機械学習を用いたPJ）では、主に2つのアプローチを組み合わせるべきであると考えている。
| ルールベース型 | メトリクス型 | |
|---|---|---|
| 定義 | ユーザが明示的にルール（ビジネスルール、システム制約）を定義する | データの統計的特性を収集・比較する |
| 目的 | 正当性・整合性の監視 | ドリフト・異常値・トレンド監視 |
| 使用例 | レンジテスト（数値が特定の範囲内か） スキーマテスト（スキーマが想定と一致しているか） 重複判定（PKが一意か） |
統計値分布の変化（データドリフト） 外れ値の出現頻度のトレンド（異常値監視） |
| 検出方法 | 明示的なルール違反を検出 | 正常性のメトリクスに対する逸脱を検出 |
| 運用例 | 確実にNGな条件を明示できる場合 | 未知の異常や傾向変化を検知したい場合（データの異常性やモデルの説明性など） |
| メンテナンス性 | ルール数が多いと煩雑になる | メトリクス収集やアラート閾値の設計が必要 |
4. データ品質検証ツールの比較
現在はデータ品質テストを実装するうえでOSS・PaaS型・SaaS型などさまざまな選択肢がある。
ここでは代表的なツールを比較表でまとめ、特徴や向き不向きを整理した。
| サービス形態 | ツール名 | ルールベース型 | メトリクス型 | Python実装 | 可視化機能 | 対応データソース | 開発工数 |
|---|---|---|---|---|---|---|---|
| OSS | Deequ | 〇 | 〇 | △（PyDeequは限定的） | ×（外部要） | S3/Redshift/SQL | 高 |
| OSS | Great Expectations | 〇 | × | 〇 | 〇（HTML等） | SQL/S3/CSV/BigQuery等 | 中〜高 |
| PaaS | Glue Data Quality | 〇 | 〇 | △（DQDLを使用） | 〇（Glue Studio） | S3/GlueTable等 | 中 |
| PaaS | SageMaker Model Monitor | △（複雑ルール×） | 〇 | 〇（boto3やsagemakerSDKなど） | 〇（Studio） | S3/Endpoint | 中 |
| SaaS | Monte Carlo | 〇 | 〇 | △（SDK/API） | 〇（SaaS UI） | DWH/クラウドDB | 低 |
| SaaS | DataBand | △（複雑ルール×） | 〇 | 〇 | 〇（SaaS UI） | DWH/クラウドDB/パイプライン | 低 |
どのツールにも一長一短があり、「現場の運用体制や要件、スキルセット」や「今後の自動化・拡張要望」 によって選択は変わる。
5. まとめ・参考情報
データ品質管理は、価値あるデータ活用のための基盤である。ビジネスの成長やプロダクトの信頼性を支えるために、日々の運用・仕組み化を積み重ねていくことが大切。
Appendix
MonitoringとObservabilityの違い
データ品質検証ツールを調査していた時に、Data Monitoring ToolとData Observabiilty Toolという2つの言葉が登場した。似通った名前であるが、何となく使い分けされている雰囲気を感じたが、Software Design5月号にて両者の違いが明記されていたため、下記にまとめる。
-
Monitoring:
異常を“検知”することに特化。定義済みメトリクスやアラートで素早く把握する。本記事で紹介したTool群はこちらに分類されそう。 -
Observability:
“なぜ・どこで・どんなふうに”問題が起きているか、システム全体を深掘り・探索できる力。 -
Observability Tool例:
Datadog、New Relic、etc...（インフラ・アプリ・データ基盤も対応）
コラム：OpenTelemetryとは？
OpenTelemetryは、アプリやデータ基盤の動作状況を可観測性データ（メトリクス・トレース・ログ）として一元収集し、ツール横断で“見える化”できるオープン標準。複雑なシステム／パイプラインの原因分析や自動化の未来像を支えている。