AI×データ品質｜成果を左右するデータ設計の考え方

空欄を埋め、表記をそろえ、重複を削除した。表はきれいになったのに、AIの判断は改善しない。処理の途中で、返品という重要な例や、同じ顧客の別の注文まで消してしまうこともあります。

品質管理の出発点は、この記録は何を表し、どの判断に使うのかを決めることです。この記事では、品質を一つの点数にする前に、データの意味、測れること、まだ確認できていないことを分けて考えます。

30秒で要点

• 一行が人・注文・出来事のどれを表すかを決める。同じ値でも別の観測は重複とは限らない。
• 欠損、形式、現実との一致を別々に測り、分母と対象を示す。
• 原データを保存し、修正・補完・保留・除外の理由へ戻れるようにする。
• モデル学習では、評価用を先に分ける。補完や標準化に評価用の情報を混ぜない。
• データ品質の検査と、実際の対象業務でのモデル性能の評価を両方行う。

どこから読むか — 自分の状況から選ぶ

この記事はデータ品質を業務成果から逆算して設計する考え方を扱います。仕組みの各部はそれぞれ別の記事にあります。

社内資料をAIに参照させたい。 構成の全体像はRAG（検索拡張生成）とは？、その基盤になる仕組みはベクトルデータベースとは？。

どのモデルを使うか決めたい。 課題の型から選ぶ手順はAIモデル選択ガイド。

一行の意味を決めないと、正しく直せない

顧客の一覧では、一人につき一行が必要かもしれません。注文の一覧では、同じ人が同じ商品を二度買えば二行あることが自然です。名前・商品・金額が同じだからといって、後者を消すと、実際の取引が失われます。

まず次の問いを、データを作った人と使う人で共有します。ファイルの説明だけで分からなければ、処理を始める前に確認します。

表が収まらない場合は、横にスクロールできます

この情報は、データを使うための説明書になります。列の名前が同じでも、意味が同じとは限りません。 別のシステムを結合するときは、同じ名前の列をそのままつなぐ前に定義を照合してください。

品質の六つの観点を、用途に合わせて使う

英国政府のデータ品質の枠組みは、用途に合うデータを目標とし、完全性、一意性、一貫性、適時性、妥当性、正確性を区別しています。これはAIの精度保証や、すべての業務に同じ合格率を求める基準ではありません。

表が収まらない場合は、横にスクロールできます

空欄を仮の値で埋めると、形式上は完全に見えても正確さは増えません。形式が正しい電話番号でも、連絡先本人のものとは限らないのと同じです。利用目的が昨日の売上の集計なら、今日時点の別の値へ更新すればよいわけでもありません。

ここに、対象者・時期・条件の偏りという観点も加えます。入力が整った常連客だけのデータで、新規客の問い合わせを評価できるとは限りません。何が含まれ、何が抜けているかを説明する必要があります。

指標の名前より、数えるものを先に決める

「正確性99%」と書く前に、何を何件照合したかを定義します。誤り率を使うなら分子は誤りの件数で、低いほどよい指標です。一致率なら一致した件数を使います。名前と数値の方向を合わせてください。

表が収まらない場合は、横にスクロールできます

一つの記録が欠損と形式違反の両方に入る場合があります。理由の件数を足して「問題のある記録数」とすると二重に数えるので、記録単位の集合と理由別の件数を分けます。月ごとの比較では、分母の対象や入力経路が変わっていないかも確認します。

架空の100記録：検査通過と正確さは別

必須値がない8件、形式・範囲違反5件、同じ記録の追加取込みと確認できた2件があり、この例では互いに重ならないとします。自動検査を通るのは 100−8−5−2＝85件です。

その85件のうち20件だけ原資料と照合し、19件が一致したなら、その20件での一致率は95%です。残り65件はまだ照合していません。どの20件を選んだか、確認資料が信頼できるかによっても解釈は変わります。

少ない標本での95%を、全体の保証や固定の合格目標として使わないでください。重要な少数ケースを別に確認し、判断に必要な精度で追加の照合が必要かを決めます。

欠損・外れ値・重複を処理する前の問い

英国政府の実務ガイダンスは、欠損の理由や加工の変更、重複排除の方法、残る留保を利用者へ伝えることを説明しています。一律の削除手順より、処理で意味が変わる条件を考えるために使えます。

欠損は、未回答、取得失敗、非該当を分けます。非該当を0で埋めると、実際に0だった記録と見分けがつかなくなる場合があります。補完するなら、なぜその値を置くか、補完したことを利用者が識別できるかを確認します。

外れ値は、入力ミスかもしれませんし、本当に大きな注文や、見落としたくない異常かもしれません。分布から離れているという理由だけで消す前に、原資料、単位、対象業務を確認します。返品を含む表の負の金額を、通常売上の規則で除くような処理も避けます。

重複は、同じ出来事の二重取込みか、別の出来事かを識別します。同じIDの二行に違う値があれば、片方を無条件に残すより保留して原記録へ戻る方が適切なことがあります。理由が未確認のまま削除することは、情報を減らす判断です。

原データを残す、固定ルールの検査例

次はPythonの標準ライブラリだけを使う説明例です。対象は返品を含まない、円単位の確定注文一件につき一行と仮定し、ID、日付、非負の整数金額を必須にします。モデルの学習、平均補完、外れ値判定は行いません。

from collections import Counter
from datetime import date

def inspect_orders(rows):
    ids = Counter(r.get("record_id") for r in rows
                  if isinstance(r.get("record_id"), str)
                  and r["record_id"].strip())
    report = []
    for position, row in enumerate(rows):
        reasons = []
        key = row.get("record_id")
        if not isinstance(key, str) or not key.strip():
            reasons.append("missing_id")
        elif ids[key] > 1:
            reasons.append("repeated_id_review")
        stamp = row.get("observed_date")
        try:
            valid_date = (isinstance(stamp, str)
                          and date.fromisoformat(stamp).isoformat() == stamp)
        except ValueError:
            valid_date = False
        if not valid_date:
            reasons.append("invalid_date")
        amount = row.get("amount_yen")
        if type(amount) is not int or amount < 0:
            reasons.append("invalid_amount")
        report.append({"position": position, "reasons": reasons,
                       "status": "hold" if reasons else "pass"})
    return report

同じIDが二度現れたら、両方を確認待ちにします。どちらを残すかを、この検査だけでは決めません。元の行を書き換えず、行位置と理由を返すので、後から原データへ戻れます。

このコードが通っても、金額が本当か、日付が注文日を意味するか、必要な注文が全部あるかは分かりません。観測単位や返品の扱いが違うデータには、そのまま適用しないでください。利用時は原データの版と検査ルールの版を記録し、合格・保留件数と理由別件数を残します。

学習用と評価用を先に分ける

モデルを学習させる場合、全データの平均で欠損を埋めてから評価用を分けると、評価側の情報が処理の設計へ入り込みます。scikit-learnの公式ガイドは、前処理の値を学習用だけで求め、評価用へ同じ変換を適用する考え方を説明しています。

学習用で処理を決め、改善のための検証用で比較し、最後の評価用は判断に混ぜないようにします。評価で失敗した案件を見て改善したら、その評価はすでに改善の情報として使われています。次の独立した評価をどう用意するか考えてください。

グループと時系列の公式説明では、同一主体の複数記録や時間の近い観測が、単純に独立したデータとは扱えないことも示されています。未知の顧客へ使うモデルなら、同じ顧客の記録が学習と評価にまたがらない設計を検討します。既存顧客の未来を予測するなら、未来の情報を過去の学習に入れない境界が必要です。分割方法は、実際に何へ一般化したいかで選びます。

前の検査コードは固定ルールであり、平均などを学習しません。ただし、評価案件を見ながらルールを何度も合わせ込む場合には、同じ独立評価の問題が生じます。

顧客・画像・文書で、確認する問題が変わる

表が収まらない場合は、横にスクロールできます

ここで挙げたものは編集部の確認例で、改善率を測った企業事例ではありません。文書を参照して回答するRAGの構成でも、古い資料を新しくしたり、適用外の条項を正しくしたりする責任がなくなるわけではありません。利用する資料が、対象の問いに使えるかを確かめます。

データの検査に合格しても、モデルが対象業務を正しく処理するとは限りません。モデル性能は、対象の入力、正解の定義、重要な失敗、保留と人の確認まで含めて別に評価します。多数の簡単な案件の平均値だけで、少数の重大な誤りを隠さないことが必要です。

最小の点検を、継続して回せる形にする

最初の点検では、一つの業務と入力元に絞って、観測単位、必須項目、出所、期間を一枚に書きます。元の記録を確認できる範囲で検査と照合を行い、正常な記録だけでなく、欠損や矛盾を含む記録がどう扱われるかも確かめてください。

その結果から、直せる問題、確認が必要な問題、今回使わない範囲を分けます。修正する場合は、原データの版、変更前後、理由、確認した人や規則を残します。自動処理の採用は、その処理が意味を壊さないと判断できた範囲から始めます。

運用では、合格率だけでなく、件数、入力元、保留理由、項目の意味の変更を監視します。突然欠損が減ったなら、入力が改善したのか、仮の値で埋める処理が始まったのかを確認する必要があります。

責任者と確認先を決め、出所不明の入力や重大な意味の変更が出たら利用を保留します。データを直して再検査すること、モデルを再評価すること、業務へ戻す判断は別の作業です。品質管理の価値は、見栄えのよい表を作ることだけでなく、分からない範囲を残しながら、安全に判断できる状態を保つことにあります。

業務への取り込みはAIでデータ分析を加速、実行までの確認はAIワークフロー設計、費用への影響はAI活用のコスト最適化で続けて考えられます。

参考資料・引用元

本記事は2026年10月8日に以下の一次資料を再読し、記述を確認しています。

• UK Government Data Quality Framework / guidance — データ品質は利用者と用途に対して fit for purpose かを継続的に測るもの
• scikit-learn common pitfalls / cross-validation — 学習・前処理では train/test を先に分けて leakage を避け、評価では時間・グループ・クラス構造に合う分割を選ぶ

欠損・重複・形式の検査だけで、モデル品質や業務成果が自動的に保証されるわけではありません。