「データ品質が問題かもしれないが、具体的に何を確認すればよいかわからない」——そうした状況で、外部の診断サービスに頼る前に自分たちで現状を把握したいというニーズは多くあります。体系的なチェックリストがあれば、まず社内でどこに問題があるかを把握でき、外部に依頼する際の判断材料にもなります。
本記事では、データ品質の5次元（完全性・正確性・一意性・整合性・最新性）に「データの基本情報把握」を加えた6カテゴリ計30項目のチェックリストを提供します。BI・AI活用の前提確認、定期的な品質棚卸し、外部診断前の自己評価など、用途を問わず活用できる汎用設計です。AI・BIツール導入前に特化したチェックポイントと整備優先基準についてはAI・BIツール導入前のデータ整備：確認ポイント一覧と対処の考え方をご参照ください。
| カテゴリ | 主な確認対象 | 項目数 |
|---|---|---|
| ① 基本情報の把握 | データの存在確認・アクセス可否・管理責任者 | 5項目 |
| ② 完全性（欠損） | NULL値・空白・必須項目の欠落 | 5項目 |
| ③ 正確性・表記ゆれ | 入力ミス・全角半角・略称の不統一 | 6項目 |
| ④ 一意性（重複） | 重複レコード・重複キー・マージ未済レコード | 5項目 |
| ⑤ 整合性 | システム間のデータ不一致・外部キー不整合 | 5項目 |
| ⑥ 最新性 | データの更新日・陳腐化・廃止データの残存 | 4項目 |
6カテゴリ30項目のチェックリスト概要
カテゴリ①：データの基本情報を把握する（5項目）
品質を評価する前に、まず「どのデータが存在し、誰が管理しているか」という基礎情報を把握します。この確認ができていないと、以降のチェックを誰がどのデータに対して実施するかが曖昧になります。
- 対象データの一覧が存在するか：自社の主要データ（顧客・商品・取引先・売上等）のリストがどこかに文書化されているか確認します。「把握している人が限られる」状態は管理上のリスクです
- データの保管場所が明確か：どのシステム・サーバー・ファイルに格納されているかが担当者以外にもわかる状態になっているか確認します
- データオーナー（管理責任者）が決まっているか：データの品質維持の責任者が定まっていない場合、問題が発生しても誰も対処しない状態になります
- データへのアクセス権限が適切に設定されているか：必要な人がアクセスできる一方で、不必要な変更権限が広く開放されていないかを確認します
- データの定義・仕様書が存在するか：各カラムの意味・取りうる値・更新ルールが文書化されているか確認します。定義が口頭だけの場合、部門間でデータの解釈がずれやすくなります
カテゴリ②：完全性（欠損データ）を確認する（5項目）
完全性とは、必要なデータが揃っているかどうかを示す指標です。欠損データはBI集計の誤りやAI学習精度の低下に直結します。
- 必須項目のNULL率・空白率は許容範囲か：主要テーブルの必須カラムに対してNULL率・空白率を集計します。許容できる欠損率は項目の重要度と用途によって異なります（BFT Insightの診断では欠損率5%未満を一つの基準としていますが、重要な連絡先項目なら1%でも問題になり、任意項目なら20%でも支障がないことがあります）
- 欠損が特定の期間・部門・入力者に集中していないか：欠損率の分布を確認します。特定のタイミングや組織に集中している場合は、入力フローの問題が根本原因である可能性があります
- 関連テーブル間の対応関係に想定外の欠落がないか：マスタとトランザクションの件数は通常一致しません（顧客1,000件に対し受注50,000件など）。確認すべきは件数の一致ではなく、トランザクション側のIDがマスタに存在するか、想定される対応関係から外れていないかです
- マイグレーション・統合後に欠損が増加していないか：システム移行・統合直後は欠損が発生しやすいです。移行前後の欠損率を比較して増加がないか確認します
- 欠損補完のルールが定義されているか：欠損値をどう扱うか（補完する・削除する・そのままにする）のルールが存在するか確認します。ルールなしの補完は新たな品質問題を生むリスクがあります
カテゴリ③：正確性と表記の統一を確認する（6項目）
正確性とは、データが現実の事実を正しく反映しているかを示す指標です。正確性を損なうのは入力ミスや古い情報の残存です。一方、全角と半角の混在や法人格の略称のような表記ゆれは、値そのものが誤っているわけではないため厳密には正確性の問題ではありませんが、集計や名寄せに支障が出るため、このカテゴリでまとめて確認します。
- 全角・半角の混在がないか：文字列カラムをDISTINCT集計し、全角・半角が混在する値のパターン数を確認します。「ABC」と「ＡＢＣ」は集計上別の値として扱われます
- 法人格の略称・正式名称が混在していないか：「株式会社」「㈱」「（株）」のような略称パターンが混在していないか確認します
- スペース（前後・途中）が混入していないか：値の前後や途中に不要なスペースが入っていないかをTRIM関数や文字数チェックで確認します
- 異常値・外れ値が存在するか：数値カラムに対してMAX・MIN・平均・標準偏差を確認し、業務的にありえない値が含まれていないかチェックします
- 日付形式が統一されているか：「2026/08/01」「2026-08-01」「20260801」のように日付形式が混在していないか確認します
- コード体系が部門・システム間で統一されているか：商品コード・部門コード・取引先コードが全部門・全システムで同一の体系で管理されているか確認します
カテゴリ④：一意性（重複）を確認する（5項目）
一意性とは、同じ実体が重複して登録されていないかを示す指標です。重複データは集計値の二重カウントや、顧客への重複アプローチといった実務上の問題を引き起こします。
- 主キー・IDに重複がないか：主キーとして扱っている項目に重複値がないかをCOUNT(DISTINCT)で確認します。データベース上で主キー制約が設定されていれば通常は重複を登録できないため、実際に問題が出やすいのはCSV・Excelでの受け渡しや、取り込み前の中間データです
- 同一実体が複数のレコードとして登録されていないか：名寄せの観点で、表記が異なるだけで実質同一の顧客・取引先・商品が複数登録されていないか確認します
- 重複判定の基準が定義されているか：何をもって「同一レコード」とするかの定義があるか確認します。基準がないと名寄せ・重複削除の判断が属人的になります
- マージ（統合）ルールが存在するか：重複が見つかった際にどちらのレコードを残してどちらを廃止するか、またはどう統合するかのルールが定義されているか確認します
- 重複の発生頻度・傾向を把握しているか：新規登録のたびに重複チェックを行う仕組みがあるか、または定期的に重複率を計測しているか確認します
カテゴリ⑤：整合性を確認する（5項目）
整合性とは、複数のシステム・テーブル・部門間でデータが一致しているかを示す指標です。整合性の問題はシステム統合時やデータ連携時に顕在化しやすいです。
- 複数システム間で同じ指標の値が整合しているか：SFAの売上とERPの売上など、同一の業務指標を複数システムが持つ場合に差分をチェックします。ただし計上基準・集計期間・税込税抜が異なれば一致しないのが正常なので、まず定義が揃っているかを確認します
- 外部キー（参照先）が存在するか：トランザクションテーブルから参照しているマスタのコードが実際にマスタに存在するか確認します。孤立したレコードは結合ミスや分析エラーの原因になります
- 親子関係・階層データが正しく設定されているか：組織マスタや商品カテゴリなど、階層構造を持つデータの親子関係に矛盾がないか確認します
- データ連携のタイムラグが業務に影響していないか：連携元と連携先のデータ更新頻度に差がある場合、「最新の値が連携先に反映されていない」状態が一時的に発生します。このラグが許容範囲か確認します
- 各データの基準となるマスタが明確か：顧客マスタ・商品マスタについて、どのシステムを正とするかが決まっているかを確認します。すべてを一つのシステムに統一する必要はなく、正とするシステムと同期ルールが部門間で合意されていれば運用できます
カテゴリ⑥：最新性を確認する（4項目）
最新性とは、データが現在の状態を正しく反映しているかを示す指標です。古いデータに基づく意思決定は、方向性を誤らせるリスクがあります。
- データの最終更新日時が記録されているか：主要テーブルに更新日時（updated_at等）のカラムがあるか確認します。更新日時がなければ陳腐化の検知が困難です
- 長期間更新されていないレコードが存在するか：更新日時が一定期間以上前のレコードを抽出し、業務上まだ有効なデータか確認します。何を「長期間」とするかはデータの更新頻度によって異なります
- 廃止・退会・閉鎖済みのデータが残存していないか：廃止された商品コード・退会済み顧客・閉鎖済み取引先が有効レコードとして残っていないか確認します。退会済み顧客の残存は品質だけでなく、個人情報の取り扱い上のリスクにもなります
- データ更新フローが業務プロセスに組み込まれているか：現実の変化（引越し・社名変更・担当者交代等）がデータに反映されるプロセスが整備されているか確認します
チェックリストの使い方：問題が多い領域の優先順位
30項目を一度にすべて確認しようとすると、大きなプロジェクトになります。効果的な使い方は「まず目的を決めてから、関連するカテゴリのみを確認する」です。
- BI・AIを導入する前の確認：カテゴリ①を起点に、②〜⑥のうち利用目的に影響するものを優先します。完全性と一意性は学習・集計の精度に効きますが、BIで複数システムの数字を突き合わせる場合は整合性と最新性のほうが重大になります
- 外部データ統合・システム移行前の確認：カテゴリ①⑤が優先です。整合性の問題は統合後に発覚すると修正コストが膨大になります
- 定期的な品質棚卸し：全カテゴリを対象に、各項目の問題件数を記録します。前回との比較により品質トレンドが把握できます
- 課題の優先順位づけ：「問題あり」と判定した項目について、業務への影響度・発生件数・修正コストを並べて比較します。件数の多さだけで決めると、軽微な表記ゆれ100件が重要顧客の売上誤り1件より優先されてしまいます
よくある質問
SQLが書けなくてもチェックできますか？
30項目のうち、カテゴリ①（基本情報の把握）はSQLを使わずに確認できます。データの一覧・保管場所・管理責任者が分かっているかを関係者に確認するだけだからです。カテゴリ②〜⑥の集計はSQLがあると効率的ですが、Excelのピボットテーブルや重複チェック機能でも同じ確認ができます。ただしデータ量や列数によってはExcelでの集計が重くなるため、その場合は情報システム部門にSQLでの集計を依頼するのが現実的です。
どのくらいの頻度で実施すればよいですか？
初回は全カテゴリを一度通し、以降は年1回の棚卸しに加えて、システム変更や新しいデータ連携を始めたタイミングで関連カテゴリだけを再確認するのが現実的です。毎月すべてを確認するのは負荷に見合いません。ただし、問題が見つかった項目については、改善後に同じ方法で測り直して変化を記録しておくと、次回の判断材料になります。
まとめ
本チェックリストは「問題の有無を把握する」ためのツールであり、解決方法の設計はその後のステップです。30項目をすべて完璧にする必要はなく、「自社で最も影響の大きい問題がどこにあるか」を見つけることが目的です。一度チェックを行うだけでも、担当者が漠然と感じていた「なんとなくデータが怪しい」という感覚を、具体的な課題として整理できます。
チェックを通じて「特定のカテゴリに問題が集中している」「問題の根本原因がわからない」という状況になった場合は、より体系的な診断が有効です。BFT InsightのQuick診断では、上記の5次元指標に沿ってデータ品質を定量スコアリングし、優先度付きの改善アクションプランを提供します。自己チェックの結果を持参してご相談いただくことも可能です。