会議のたびに売上が違い、担当者は集計表の修正に追われる。欠損を直しても翌週また壊れる。この状態でAIに質問を増やすと、答えが速くなるだけで、間違いの原因まで見えにくくなることがあります。
結論として、データ品質は『完璧にきれいなデータ』ではなく、決めた利用目的に十分適している状態です。すべてを一度に直すのではなく、重要な意思決定とデータを選び、品質ルール、担当者、検知、復旧を一つの運用として作ることが改善の近道です。
最初に結論
データ品質は、データが目的に対して正確、完全、一貫、最新、一意、妥当である度合いです。最初に売上や顧客IDなど重要データを選び、『何件まで・何時間までなら業務上許容するか』を決め、SQLやデータ品質ルールで継続監視します。
この記事のポイント
- ・品質は絶対的な完全さではなく、利用目的に対して十分かで評価する
- ・正確性・完全性・一貫性・適時性・一意性・妥当性の6軸で問題を分ける
- ・重要データにルールと許容値を設定し、検知だけでなく担当者と復旧手順を決める
- ・AIやダッシュボードの前に、入力データの定義・鮮度・欠損を見える化する
対象：数字の不一致に悩む事業担当者、データ基盤担当者、AI活用前にデータを整えたい責任者
1. データ品質とは「目的に使えること」
IBMはデータ品質の各次元を、データが意図した用途に適しているかを評価するための観点として説明しています。同じデータでも、用途によって必要品質は異なります。翌月の商品企画に使う日次売上なら数時間の遅延を許容できても、出荷指示に使う在庫数では数時間の遅延が問題になります。
品質問題を『データが汚い』という一言で済ませると、直すべき場所が分かりません。欠損なのか、重複なのか、定義の不一致なのか、更新遅延なのかへ分解します。さらに、どの意思決定へどの影響があるかを結びつけると、限られた時間で優先順位を付けられます。
| 利用目的 | 重要な品質 | 許容の考え方 |
|---|---|---|
| 顧客への出荷 | 在庫・住所の正確性と最新性 | 誤出荷を避ける厳しい基準 |
| 週次売上会議 | 金額の一貫性と更新時刻 | 会議締切までの反映を定義 |
| 広告効果の方向判断 | チャネル分類と欠損率 | 追跡不能分を明示して利用 |
| AIによる顧客分析 | 定義、権限、代表性、履歴 | 回答用途ごとに評価 |
2. データ品質を評価する6つの軸
品質の次元は組織や製品によって呼び方が異なりますが、初心者は正確性、完全性、一貫性、適時性、一意性、妥当性の6つで整理すると実務へ落とし込みやすくなります。一つの問題が複数の軸にまたがる場合もあります。分類自体より、検査可能なルールへ変えることが目的です。
たとえば注文金額が0なら、無料サンプルとして正しい可能性も、不正な値の可能性もあります。『0は異常』と決める前に商品種別と業務ルールを確認します。品質ルールは事業知識をコードにしたものです。ルール名、理由、対象、所有者、重大度を残すと、後から数字だけを直す場当たり対応を減らせます。
| 品質軸 | 意味 | ECの検査例 |
|---|---|---|
| 正確性 | 現実や正しい参照値を表す | 返金額が元の支払額を不当に超えていない |
| 完全性 | 必要な値やレコードが揃う | 確定注文に顧客区分と商品明細がある |
| 一貫性 | 場所や時点で定義が矛盾しない | BIと会計で税・返品の扱いが説明できる |
| 適時性 | 必要な締切までに更新される | 前日注文が朝会前に反映される |
| 一意性 | 同じ実体が不要に重複しない | 注文IDが一件だけ存在する |
| 妥当性 | 型・範囲・形式・関係を満たす | 通貨コードが許可値に含まれる |
3. ECで最初に作る品質チェック
ECでは、注文、注文明細、顧客、商品、返金のつながりが重要です。注文IDの重複、確定注文の注文日時NULL、存在しない注文IDを持つ明細、負の数量、将来すぎる日時、前日から急減した件数を検査します。単純な列ルールと、テーブル間の関係、時系列の異常を組み合わせます。
比率は分母と対象期間を明示します。たとえば顧客ID欠損率を『顧客IDがNULLの確定注文数÷確定注文総数』と定義します。ゲスト購入を許すなら欠損は必ずしもエラーではないため、チャネル別に許容値を変えることもあります。0件を理想と決める前に、正常な例外を確認してください。
- 一意性：count(*)とcount(distinct order_id)の差を監視する
- 完全性：必須列のNULL件数と割合を期間別に追う
- 参照整合性：注文明細のorder_idが注文テーブルに存在するか確認する
- 妥当性：数量、金額、日時、状態、通貨が許可範囲にあるか検査する
- 適時性：最新レコード時刻と現在時刻の差が許容内か確認する
- 量の異常：曜日やキャンペーンを考慮し、件数急増・急減を通知する
4. データ品質を改善する5つの手順
最初から全テーブルに数百の検査を付けると、通知が多すぎて誰も見なくなります。まず誤ると売上報告、顧客対応、法令対応へ大きく影響する重要データを選びます。その流れを取得元からダッシュボードまで確認し、壊れた場合の業務影響を言葉にします。
ルールは正常・警告・停止の境界を定め、担当者と対応期限を付けます。直した後は、原因が入力、連携、変換、定義、操作のどこにあったかを記録し、上流で再発防止します。下流の表だけを手修正すると、翌日の自動更新で再び壊れるためです。
- 重要データを選ぶ：意思決定や顧客影響の大きい指標・列・テーブルへ絞る。
- 利用目的と品質軸を定める：誰がいつ何に使い、何が壊れると困るかを書く。
- 測定可能なルールにする：条件、分母、期間、許容値、重大度を定義する。
- 自動検査と通知を置く：SQL、dbt、Dataplex、Purview等を環境に合わせて使う。
- 原因を直し継続評価する：担当者が復旧し、上流原因と再発防止を記録する。
5. SQL・dbt・品質サービスの使い分け
重要なルールが数個なら、定期実行するSQLと通知から始められます。dbtを使っている組織は、モデルの一意性、非NULL、許可値、関係をdata testとして変換コードと管理できます。Microsoft PurviewやGoogle Cloud Dataplexには、カタログやルール、スコア、監視を支援する機能があります。製品導入より先に対象と責任を決めます。
ツールが異常を見つけても、正しい値へ直す担当は自動で決まりません。データを生成する業務オーナー、連携を管理する技術オーナー、指標を使う事業オーナーの連絡経路を作ります。品質ダッシュボードにはスコアだけでなく、影響を受ける指標、最終成功時刻、未解決件数、担当者を載せます。
| 方法 | 向く状況 | 注意 |
|---|---|---|
| SQL | 重要ルールが少なく小さく始める | 実行・履歴・通知を別途管理 |
| dbt data test | SQLモデルと一緒に前提を管理 | 上流取得や業務妥当性は別確認 |
| クラウド品質機能 | 多様な資産を横断して測定 | 権限・料金・運用設計が必要 |
| 手動照合 | 新規導入や重要な金額確認 | 定例化すると負担と見落としが増える |
6. AI活用で品質問題が見えにくくなる理由
生成AIは自然な文章で回答するため、入力データが一日遅れていても、返品が二重でも、もっともらしい説明を返すことがあります。AIへ接続する前に、参照できるデータ範囲、用語定義、更新時刻、品質状態をコンテキストとして渡し、問題があるときは回答を止めるか警告する仕組みが必要です。
また学習・検索対象に偏りがあれば、品質ルールを通っていても判断が偏る可能性があります。構造的な正しさだけでなく、対象顧客を十分に表しているか、重要な期間が欠けていないか、利用目的を超えた個人情報が含まれないかを評価します。AI-readyとは大量にためることではなく、安全に意味を説明できることです。
7. 最初の30日で作る小さな品質運用
第1週は、最も重要なレポートを一つ選び、利用者、データ元、更新締切、主要指標を確認します。第2週は、過去の障害と数値差を6軸で分類し、重大な5〜10個のルールを作ります。第3週は定期実行と通知を設定し、意図的にテストデータで失敗させ、通知が担当者へ届くか確認します。
第4週は実際に発生した問題を振り返り、不要な通知、厳しすぎる閾値、対応の抜けを直します。成功指標はルール数ではなく、重大な誤りを利用者が見る前に検知できた割合、復旧時間、再発数、定義不一致による会議時間などです。改善の価値を事業影響で共有します。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- Data quality dimensions — IBM（最終確認：2026-08-07）：データ品質の主要な評価次元と目的適合性を参照。
- Data quality rules in Microsoft Purview — Microsoft Learn（最終確認：2026-08-07）：品質ルール、スコア、検査の実装例を参照。
- About automatic data quality — Google Cloud（最終確認：2026-08-07）：Dataplexによる品質ルールと評価の概念を参照。
- Data tests — dbt Labs（最終確認：2026-08-07）：SQL変換内でのデータ前提検査を参照。
よくある質問
データ品質は100%を目指すべきですか？
すべてのデータで100%を目指すと費用が価値を上回る場合があります。利用目的と影響に応じて許容値を定め、出荷・決済など重大な領域は厳しく、探索分析は不確実性を明示して使い分けます。
欠損値はすべて埋めたほうがよいですか？
いいえ。未知、対象外、取得失敗は意味が違います。推測値で埋めると事実に見えるため、欠損理由を区別し、利用目的に必要な場合だけ根拠と方法を残して補完します。
データ品質の担当はエンジニアですか？
技術担当だけでは完結しません。業務側が正しい意味と許容値を決め、技術側が検査と復旧を実装し、利用側が影響を確認する共同責任です。各ルールの最終所有者は明確にしてください。
まとめと次の一歩
データ品質は一度きりの掃除ではなく、用途ごとの許容値、検知、担当者、復旧を回す運用です。重要なデータだけに測定可能なルールを置き、利用者への影響が大きい違反から直すことで、ダッシュボードやAIの答えを継続して信頼できる状態に近づけます。