AIで欠損値・空欄を確認してデータを整える方法

欠損値をAIで整えるとき、最初から「空欄を埋めて」と頼むのは危険です。空欄には、未入力、該当なし、取得失敗、入力待ち、元Data自体に存在しない、という別の意味が混ざるからです。まず列ごとに「何がMissingとして入っているか」と「なぜ欠けたか」を確認し、削除・補完・維持を選びます。

この記事では、Missing Profile、欠損Reason、0・空文字・NA表記の区別、削除や補完の影響比較、Cleaned Copyの検算まで進めます。読後には、AIに推測で値を埋めさせず「どの欠損を何のRuleで処理したか」を説明できる状態を目指します。

最初にMissingの表現を棚卸しする

CSVやExcelでは、欠損がすべて同じ形で入っているとは限りません。

例：

• 空Cell

• 空文字 ""

• NA

• N/A

• null

• -

• 未入力

• 0

これらを一括で同じ意味にしないことが重要です。

0はMissingとは限らない

売上0円、在庫0個、問い合わせ0件のように、0自体が有効なObservationであるColumnがあります。

「空欄を0で埋める」と、未取得だった値が実績0に変わります。集計結果も変わるので、Columnの意味を確認してから変換します。

ColumnごとにMissing Profileを出す

まず列単位でMissing CountとRateを確認します。

表は横にスクロールできます

Column	Rows	Missing	Rate	Role
customer_id	1000	2	0.2%	Primary Key候補
age	1000	120	12%	分析変数
memo	1000	650	65%	任意Text
amount	1000	20	2%	金額

数字は説明用の架空例です。Missing率だけで処理を決めず、Column Roleとセットで見ます。

Primary Keyの欠損は優先して確認する

customer_id、order_idなどRecord識別に使うColumnが欠けている場合、単純補完より先にSource側で復元できるかを確認します。

他Rowの値からAIに推測させて新しいIDを作ると、別Recordへ誤結合する可能性があります。復元できなければREVIEWや除外候補として扱います。

Missing Reasonを分類する

欠損は少なくとも次のように分けて考えられます。

NOT_ENTERED：入力されていない。

NOT_APPLICABLE：そのRowには項目自体が該当しない。

COLLECTION_FAILED：取得に失敗。

NOT_YET_AVAILABLE：まだ値が確定していない。

SOURCE_MISSING：元Sourceにも存在しない。

UNKNOWN：理由不明。

Reasonが違えば処理Ruleも変わります。

架空例：同じ空欄でも意味が違う

顧客Dataにcompany_nameとretirement_dateがあるとします。個人客のcompany_name空欄はNOT_APPLICABLEかもしれません。一方、退会済み顧客のretirement_date空欄は入力漏れの可能性があります。

見た目が同じBlankでも、前者を埋める必要はなく、後者はSource確認が必要です。

Missing Value Decision Matrixを作る

表は横にスクロールできます

状況	Candidate Action	Before Action
理由不明	維持 / Review	Source確認
Key欠損	Review / 除外候補	復元可否
任意Memo	Blank維持	分析に必要か
NOT_APPLICABLE	明示Labelも候補	他Missingと分離
数値欠損	補完/除外/維持	分布・意味・影響
取得失敗	再取得	Pipeline確認

処理方法より、判断前に見る情報を決めておきます。

AIへの最初の依頼は「補完」ではなくProfile

Prompt例：

「このCSVを変更せず、ColumnごとのMissing Profileを作ってください。空Cell、空文字、NA/N/A/null/ハイフン/0を別々に数え、Sample Rowを各3件出してください。Columnの意味からMissing Reasonを推測せず、理由不明はUNKNOWNにしてください。処理案はまだ適用しないでください。」

最初はDataを変えずに観察します。

空文字とNaNを区別する

Data処理Toolでは、空文字とMissing markerが別扱いになることがあります。pandasでもNone、NaN、NaT等のMissing判定と、空文字の扱いは同一ではないケースがあります。

AIが「欠損120件」と報告したら、何をMissingとして数えたのかを確認します。

特殊文字を正規化する前に意味を確認する

-がMissingを意味するDatasetもあれば、符号やCategoryとして意味を持つDatasetもあります。

一括replaceをする前にColumn別Sampleを見ます。「全Columnの'-'をNAへ変換」のようなGlobal Ruleは、意味の違うColumnを壊す可能性があります。

削除はRow Biasを見る

Missingを含むRowを全部削除すると、特定Segmentだけ大量に消えることがあります。

たとえば地方拠点だけage欠損が多い場合、欠損Row削除後のDataは都市部へ偏るかもしれません。削除前後でSegment Countを比較します。

架空例：Row削除の影響を確認する

Before：1000 Row、東日本600 / 西日本400。

age欠損120 Rowの内訳：東日本20 / 西日本100。

欠損Rowを全削除すると、Afterは東日本580 / 西日本300。

この場合、単に12%減っただけでなく地域構成が変わっています。数字は架空例ですが、削除前後のDistributionを見る理由はここにあります。

平均値補完を万能にしない

数値ColumnのMissingを平均で埋めると、Dataset全体の平均値自体は扱いやすくなる一方、実在しない値を生成します。

年齢、売上、回数などColumnの意味によっては平均補完が不自然です。分析目的、分布、Missing Reasonを確認し、根拠がないならUnknownのまま維持する選択もあります。

Categoryを最頻値で埋める前に考える

CategoryのBlankへ最も多い値を自動入力すると、存在しない回答を作ることになります。

「未回答」を独立Categoryとして扱う方がReader Jobに合う場合もあります。AIには、補完値を提案する前にBusiness Meaningを確認させます。

NOT_APPLICABLEはUnknownと分ける

該当しない項目をBlankのままにすると、集計時に「欠損」と「非該当」が混ざります。

Dataset設計が許すならNOT_APPLICABLE等の明示Valueへ分けることで、未入力と区別しやすくなります。ただし既存SystemのAllowed Valueを壊さないか確認します。

取得失敗は補完より再取得を優先する

APIやImportの失敗で値が欠けたと分かっているなら、推定値で埋めるよりSourceから再取得できるか確認します。

Pipeline ErrorをData Cleaningで隠すと、次回も同じ欠損が発生します。COLLECTION_FAILEDはData処理だけでなく上流の修正対象です。

補完するならOriginal Valueを残す

cleaned Dataへ直接値を書き換えるだけでは、元がMissingだったか分からなくなります。

必要に応じてamount_original、amount_cleaned、amount_imputed=trueのように、Originalと処理後を区別できる形にします。

AIへ処理Ruleを渡す

「ageは理由不明のMissingを補完せず維持。customer_id欠損はREVIEW。memoはBlank維持。region='N/A'は元Source確認。amountは0とBlankを分離し、Blankを勝手に0へしない。処理後にColumn別Missing CountとSegment CountをBefore/Afterで比較してください。」

ColumnごとのRuleを明示し、一括補完を避けます。

Before / Afterの影響を比較する

少なくともRow Count、Missing Count、平均/合計等の重要指標、Category Distributionを処理前後で比較します。

数値が変わること自体は問題ではありません。意図したRuleによる変化かを確認します。

Reconciliation Table

表は横にスクロールできます

Metric	Before	After	Expected
Rows	1000	995	Key欠損5件除外なら一致
amount missing	20	20	維持Ruleなら同じ
id missing	5	0	Review後除外
Region A	400	398	除外内訳と一致

値は説明用です。処理RuleとCount差が一致することを確認します。

Cleaned CopyとRule Logを分けて保存する

Raw CSVを残し、cleaned CSVとCleaning Rule Logを別に保存します。

Logにはrun_at、Column、Missing Definition、Action、Affected Rows、Reason、Reviewerを残すと、後で再現しやすくなります。

Stop条件

次の場合は自動補完を止めます。

• Missing Reasonが不明

• Keyを推測する必要がある

• 補完でSegment構成が大きく変わる

• 重要指標が想定以上に変わる

• Allowed Valueが不明

• Sourceから再取得できる可能性がある

• Before/After件数がRuleと一致しない

全部埋めることが品質ではありません。Unknownを正しく残す方が安全な場合があります。

最終Checklist

• Missing表現を棚卸しした

• 0とBlankを分けた

• Column別Count/Rateを出した

• Missing Reasonを分類した

• Key欠損を優先確認した

• 削除前後のSegmentを比較した

• 補完Valueに根拠がある

• Original Valueを保持した

• Reconciliationが一致した

• Raw FileとRule Logを残した

AIものさしの判断

欠損処理は「空欄をなくす」作業ではなく、「空欄が何を意味するかを確認し、分析や業務に必要な形へ扱いを決める」作業です。0、未入力、非該当、取得失敗を同じMissingへ潰さないことが重要です。

まずCSVを変更せず、Column別のMissing ProfileとSample Rowを出してください。ReasonをUNKNOWNのまま残せる状態でRuleを決め、小さなCopyに処理してBefore / Afterを比較する。その順なら、AIにきれいなDataを作らせることより、意味を壊さないCleaningへ進めます。