フレームワーク活用ガイドひとことで言うと#
データの品質を「正確性」「完全性」「一貫性」「適時性」「一意性」「妥当性」の6つの軸で評価し、どの品質が不足しているかを特定して改善するフレームワーク。
押さえておきたい用語#
- 正確性（Accuracy）
- データが現実の値と一致しているかを示す次元。住所の誤記、金額の入力ミスなどが正確性の問題にあたる。
- 完全性（Completeness）
- 必要なデータが欠損なく揃っているかを示す次元。NULL値や空欄の割合で測定する。
- 一貫性（Consistency）
- 複数のシステムやテーブルで同じ事実が同じ値で記録されているかを指す。顧客マスタと注文テーブルで住所が異なるケースが一貫性の問題。
- 適時性（Timeliness）
- データが必要なタイミングで利用可能になっているかを評価する次元。リアルタイム性が求められる場面で1日遅れのデータでは品質が低い。
データ品質の6次元の全体像#
こんな悩みに効く#
- 分析結果の数字が部門ごとに違い、どれが正しいかわからない
- データの欠損や重複が多く、分析前のクレンジングに時間を取られる
- 「データ品質が悪い」と言われるが、具体的に何が悪いのか整理できていない
基本の使い方#
各次元について、データセットごとにスコアを算出する。
| 次元 | 測定方法の例 |
|---|---|
| 正確性 | サンプル検査で原本と照合し、一致率を算出 |
| 完全性 | 各カラムのNULL率・空欄率 |
| 一貫性 | 複数テーブル間のキー結合率、値の不一致件数 |
| 適時性 | データ更新のSLA達成率、最大遅延時間 |
| 一意性 | 主キーの重複率 |
| 妥当性 | バリデーションルール違反率（型、範囲、フォーマット） |
スコアが低い次元について「なぜ品質が低いのか」を掘り下げる。
- 完全性が低ければ入力フォームの必須設定漏れや外部連携の欠落を疑う
- 一貫性が低ければマスタの二重管理かシステム間の同期遅延が原因が多い
- 正確性が低ければ手入力のミスか変換ロジックのバグ
- 技術的な問題と運用的な問題を切り分けて対処する
原因に応じた改善策を打ち、定期的にスコアの推移を追う。
- 型・範囲・フォーマットチェックをフォームやAPIに組み込む（入力時バリデーション）
- 重複排除は名寄せロジックと一意制約の追加で対処
- データ更新のSLAを設定して遅延をアラート化する
- 月次でスコアカードを更新し、関係者にレポートする
具体例#
顧客数45万件のECサイト。セグメントメールの不達率が 12% と高く、データ品質を6次元で監査した。
| 次元 | スコア | 主な問題 |
|---|---|---|
| 正確性 | 82% | 住所の旧表記が18%残存 |
| 完全性 | 91% | 電話番号の欠損9% |
| 一貫性 | 74% | ECと実店舗の顧客マスタで住所が不一致26% |
| 適時性 | 95% | 日次バッチで更新、問題なし |
| 一意性 | 88% | 同一顧客の重複登録が12%（メアド違い） |
| 妥当性 | 96% | 郵便番号フォーマット違反4% |
一貫性 74% と一意性 88% がボトルネック。顧客マスタの名寄せを実施し、重複を解消したところ、セグメントメールの到達率が 88% → 95% に改善。メール経由の月間売上が約380万円増加した。
工場のIoTセンサーから取得する温度・振動データ（日次50万レコード）の品質を評価した精密機器メーカー（従業員500名）。
適時性のスコアが 68% と低く、データの到着遅延が平均 45分。リアルタイム異常検知のSLA（5分以内）を大幅に超過していた。原因はセンサーからのデータ転送にバッチ処理を使っていたこと。
ストリーム処理（Apache Kafka）に切り替え、転送遅延を 3秒以内 に短縮。適時性スコアは 68% → 97% に改善。リアルタイム異常検知が機能するようになり、設備故障の予兆検知で月間ダウンタイムが 18時間 → 4時間 に削減された。
人口15万人の自治体。住民基本台帳の完全性に問題があり、防災通知の未到達が毎年 約2,000世帯 発生していた。
6次元の監査結果は以下の通り。
| 次元 | スコア | 問題 |
|---|---|---|
| 完全性 | 87% | メールアドレス未登録13% |
| 正確性 | 93% | 転居後の住所未更新7% |
| 適時性 | 78% | 転入届から台帳反映まで最大5営業日 |
完全性と適時性を重点改善。転入届のオンライン受付を開始し、台帳反映を即日処理に変更。メールアドレスは転入手続き時の登録フローに組み込んだ。1年後、完全性は 87% → 94%、適時性は 78% → 96% に改善。防災通知の未到達世帯は 2,000世帯 → 600世帯 に減少した。
やりがちな失敗パターン#
- 「データ品質が悪い」を具体化しない — 「品質が低い」では対処できない。6次元のどこが低いのかを数値で特定することで初めて改善策が打てる
- 完全性だけに注目する — NULL率の改善にばかり注力して、入力された値の正確性やシステム間の一貫性を見落とすケースが多い
- 一度の監査で終わる — データ品質は時間とともに劣化する。定期モニタリングの仕組みを入れないと、半年後には元に戻る
- 品質基準をビジネス要件と紐づけない — すべての次元を100%にする必要はない。「メール配信には完全性95%以上が必要」のように、ビジネス要件から逆算して目標を設定する
まとめ#
データ品質の6次元は「データが汚い」を6つの軸に分解するフレームワーク。「品質が悪い」だけでは直しようがないが、「一貫性スコアが74%で原因はマスタの二重管理」まで落とせれば動ける。実際に運用してみると、正確性より一貫性のほうが厄介なことが多い。スコアカードは作っても更新を止めると半年で形骸化するので、月次レポートとセットで回すのが現実的。