---
title: "データクレンジングとは？表記ゆれ・欠損・重複を直す手順と移行前に決めるルール"
url: "https://www.issoh.co.jp/column/details/19711/"
published: 2026-11-13
updated: 2026-11-13
categories: ["DX"]
publisher: "株式会社一創"
---

# データクレンジングとは？表記ゆれ・欠損・重複を直す手順と移行前に決めるルール

「株式会社一創」「㈱一創」「一創株式会社」が同じ顧客台帳に3件並んでいる。データクレンジングは、こうした表記ゆれや欠損、重複、誤った値を見つけて直し、業務と分析で使える状態にする作業です。この記事では、データクリーニングや名寄せとの違い、汚れの6つの型、6段階の手順、Unicode正規化や法人番号を使った表記の統一方法を整理しました。後半では、Excel・ETLツール・外注の選び分けと、システム移行やデータ基盤構築の前工程としてルールを決める進め方まで扱います。

## まとめ：データクレンジングは一度の掃除で終えず移行や基盤構築の前にルールを決める

データクレンジングで最初に作るのは、きれいなデータではなく「何をどう直すか」のルール表です。ルールが文書になっていないと、作業者ごとに直し方が変わり、次の移行や連携のたびに同じ作業を一から繰り返すことになります。

手順は、目的と品質基準の決定、現状の測定、ルールの設計、実行、名寄せ、検証の6段階です。全角半角や㈱のような文字の揺れはUnicode正規化で機械的にそろえ、社名と住所は法人番号やアドレス・ベース・レジストリといった公的データを基準にします。

手段の目安はこうです。数千件で一度きりならExcelとPower Queryで足ります。移行や定期連携で繰り返すならETLかスクリプトにルールを組み込みます。システム移行の前なら、全件を直そうとせず、新システムで必須になる項目から順に直してください。

## データクレンジングの定義とデータクリーニング・名寄せ・ETLとの守備範囲の違い

### 誤り・表記ゆれ・欠損・重複を直し業務と分析で使える状態にする作業範囲

データクレンジング（data cleansing）は、データベースやファイルに含まれる不備を検出し、修正・補完・削除によって品質をそろえる作業を指します。対象は顧客台帳、商品マスタ、取引履歴など、業務で参照される構造化データが中心です。

範囲は「直す」までです。どの値を正とするかを全社で管理し続ける体制づくりはマスターデータ管理の領域になります。一度直したデータを複数システムで正しく保ち続ける方法は[マスターデータ管理（MDM）とは？4つの実装方式と導入を見送る条件を解説](https://www.issoh.co.jp/column/details/19536/)で扱っています。

### データクリーニング・名寄せ・プレパレーションと比べた役割と順序の切り分け

似た言葉は多いものの、違いは作業の範囲と順序で整理できます。

| 用語          | 主な作業        | クレンジングとの関係    |
| ----------- | ----------- | ------------- |
| データクリーニング   | 誤り・不備の修正    | ほぼ同義として使われる   |
| 名寄せ         | 同一の実体の特定と統合 | クレンジングの後に行う   |
| データプレパレーション | 分析用の結合・加工全般 | クレンジングを含む上位概念 |
| ETL         | 抽出・変換・格納の処理 | 変換工程の中で実行する   |

順序で迷いやすいのは名寄せです。「㈱一創」と「株式会社一創」を同じ文字列にそろえてからでないと、照合の精度が上がりません。表記をそろえるのが先、同一判定はその後です。照合アルゴリズムの種類は[データマッチング技術とは？名寄せ・類似検索の3系統とツールの選び方](https://www.issoh.co.jp/column/details/2377/)に、ETLの変換工程の中身は[ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説](https://www.issoh.co.jp/column/details/13364/)にまとめています。

## 汚れたデータの6つの型と発生原因・放置したときに業務で起きる損失

### 表記ゆれ・欠損・重複・形式不統一・異常値・陳腐化の6型と具体例の一覧

汚れは型ごとに直し方が違います。最初に型を見分けておくと、ルール表の行がそのまま決まります。

| 型     | 具体例                      | 主な直し方       |
| ----- | ------------------------ | ----------- |
| 表記ゆれ  | ㈱と株式会社、全角と半角             | 正規化と置換表     |
| 欠損    | 電話番号や郵便番号が空欄             | 補完か要確認へ振り分け |
| 重複    | 同じ取引先が3件登録               | 名寄せで統合      |
| 形式不統一 | 日付が2026/11/13と令和8年11月13日 | 型と書式の統一     |
| 異常値   | 単価がマイナス、生年が1900年         | 範囲チェックと差し戻し |
| 陳腐化   | 移転前の住所、合併前の社名            | 外部データとの照合   |

実務で件数が多いのは表記ゆれと重複です。一方、請求書の誤送付のような実害に直結するのは陳腐化のほうで、件数が少なくても優先度を上げる理由になります。

### 自由記述の入力欄と複数台帳の並行運用が汚れを生み続ける発生の仕組み

汚れの発生源はおおむね2か所に絞られます。1つは入力画面です。社名や住所が自由記述で、全角半角や法人格の書き方を制約していなければ、入力者の数だけ表記が生まれます。

もう1つは、販売管理・会計・CRMが別々に台帳を持つ構成です。同じ取引先が各システムで別々に登録され、移転や社名変更が一部にしか反映されません。BIの集計で顧客数が合わない、ダイレクトメールが同じ会社に2通届く、AIの学習データに同じ顧客が別人として混ざる、といった損失はここから生まれます。

後者の構成では、クレンジングだけでは再発を止められません。統合の方式から見直す場合は[データ統合とは？種類・方式の違いと名寄せの壁から導入判断まで解説](https://www.issoh.co.jp/column/details/18977/)が判断の材料になります。

## データクレンジングの手順6段階と各段階で作る成果物と次へ進む判断基準

### 目的と品質基準を決め現状の汚れを件数で数える最初の2段階の進め方

最初に決めるのは「何のためにきれいにするか」です。請求の誤送付を止めたいのか、BIの顧客数を合わせたいのか、新システムへ移行したいのかで、直すべき項目が変わります。目的が決まったら、項目ごとに合格の基準を置きます。たとえば「電話番号は数字10桁か11桁」「法人番号は13桁」のように、機械で判定できる形にしてください。

次に現状を測ります。項目ごとの空欄率、値の種類数、桁数の分布、重複の候補件数を数える作業で、データプロファイリングと呼ばれます。この段階の成果物は「項目×汚れの件数」の一覧表です。件数が出ていないと、どこから直すかの優先順位も、外注する場合の見積もりも決まりません。

### 正規化・補完・削除のルールを表に起こし業務部門の承認を得る設計段階

3段階目では、直し方をルール表に起こします。1行に「対象項目・検出条件・処理・例外の扱い」を書く形式が扱いやすいでしょう。

- 社名：NFKCで正規化し、法人格の表記は置換表で統一する
- 電話番号：数字以外を除き、桁数が合わないものは要確認へ回す
- 郵便番号：7桁にそろえ、住所と食い違うものは住所側を確認する
- 単価：0以下は削除せず、入力元の部署へ差し戻す

ルール表は情報システム部門だけで決めず、データを使う業務部門の承認を取ります。「支店を別の取引先として扱うか」「個人事業主の屋号をどう書くか」は業務の判断で、技術側が勝手に決めると後で統合をやり直すことになります。

### 実行・名寄せ・検証の3段階で元データを残し修正前後の差分を確かめる手順

後半の3段階は次の順で進めます。

1. 実行：元データを複製し、複製側にルールを適用する。元データは上書きしない
2. 名寄せ：正規化した値をキーに同一候補を抽出し、確度の高いものだけ自動で統合する
3. 検証：ルールごとの修正件数と、要確認に回った件数を一覧にして基準と照らす

元データと修正後の対応を残しておくのは、誤った修正を取り消すためです。検証では全件を目視せず、ルールごとに数十件を抜き出して確認すれば足ります。修正件数が想定より極端に多いルールは、検出条件が広すぎる疑いがあります。

## Unicode正規化と公的データで社名・住所・電話番号の表記ゆれをそろえる方法

### NFKC正規化で全角英数・半角カナ・㈱をそろえるPythonの処理例と結果

全角と半角の揺れをまとめて直す方法が、Unicode正規化です。Pythonでは標準ライブラリの[unicodedata.normalize()](https://docs.python.org/ja/3/library/unicodedata.html)に正規化形式NFKCを指定します。NFKCは[Unicode標準のUAX #15](https://unicode.org/reports/tr15/)で定義された形式で、互換文字を標準的な文字へ分解してから合成し直します。

```
# 社名と電話番号を正規化して重複候補を出す例（Python 3.14.10で動作確認）
import csv, io, re, unicodedata

SRC = """id,company,tel
1,株式会社 一創,03-1234-5678
2,㈱一創,０３（１２３４）５６７８
3,一創株式会社,0312345678
4,ＡＢＣ商事,
"""

def company_key(name):
    s = unicodedata.normalize("NFKC", name)   # ㈱→(株)、全角英数→半角
    s = re.sub(r"\s+", "", s)                 # 空白を除く
    return re.sub(r"\(株\)|株式会社", "", s)   # 法人格の位置の違いを無視

def tel_key(tel):
    return re.sub(r"\D", "", unicodedata.normalize("NFKC", tel))

seen = {}
for row in csv.DictReader(io.StringIO(SRC)):
    key = (company_key(row["company"]), tel_key(row["tel"]))
    if not key[1]:
        print("要確認(電話欠損):", row["id"], row["company"])
    elif key in seen:
        print("重複候補:", row["id"], "→", seen[key])
    else:
        seen[key] = row["id"]
```

実行すると、id 2と3がid 1の重複候補として出力され、電話番号が空のid 4は要確認に回ります。「㈱」は「(株)」に、「０３（１２３４）」は「03(1234)」に、半角カナの「ｶﾌﾞｼｷｶﾞｲｼｬ」は全角の「カブシキガイシャ」に変わりました。重複候補は自動で消さず、一覧にして人が確認する前提の処理です。

### NFKCで直らないハイフン・長音記号と法人格の揺れを置換表で補う理由

NFKCだけでは片付かない揺れがあります。同じ環境で確かめると、全角の「－」は半角の「-」になる一方、長音記号の「ー」とハイフンの「‐」（U+2010）はそのまま残りました。住所の「1ー2ー3」と「1-2-3」は、正規化後も別の文字列です。

そのため、ハイフンに見える文字を1つにまとめる置換表を別に用意します。法人格も同じで、「(株)」「株式会社」「(有)」「有限会社」「(同)」「合同会社」をどう扱うかは置換表で明示しなければ統一できません。置換表はコードの中に埋め込まず、業務部門が読めるCSVで管理すると、ルール表との対応を保ちやすくなります。

### 法人番号の公表データとアドレス・ベース・レジストリを照合の基準に使う方法

社名と住所は、自社の台帳同士を比べるより、公的データを基準にしたほうが確実です。国税庁の[法人番号公表サイトの基本３情報ダウンロード](https://www.houjin-bangou.nta.go.jp/download/)では、法人番号・商号・所在地をCSVかXMLで取得できます。全件データは前月末時点の内容、商号変更などの差分データは日別の提供です。法人番号を台帳に持たせれば、社名の表記ゆれや旧社名の問題をキーの一致で解決できます。

住所はデジタル庁の[アドレス・ベース・レジストリ](https://www.digital.go.jp/policies/base%5Fregistry%5Faddress)が基準になります。町字データがCSVで公開され、住所の正規化とジオコーディングを行う[ABRジオコーダー](https://github.com/digital-go-jp/abr-geocoder)もオープンソースで提供されています。なお、2026年11月13日時点のデジタル庁の案内では、2027年1月下旬のシステム更改に合わせて町字データのCSVフォーマットが変わる予定です。取り込み処理を作るなら、列の定義を固定せず読み替えられる形にしておきます。顧客データに限った名寄せキーの決め方は[顧客データ統合の進め方｜名寄せのキー設計とCDPを入れずに済む条件](https://www.issoh.co.jp/column/details/18983/)が詳しく扱っています。

## Excel・ETLツール・外注を件数と繰り返しの頻度で選び分ける判断基準

### Excel関数とPower Queryで足りる件数と手作業が破綻し始める条件の目安

数千件で一度きりの作業ならExcelで十分です。TRIM関数で余分な空白を、ASC関数で全角英数を半角に、SUBSTITUTE関数で「㈱」を「株式会社」に置き換え、COUNTIFで重複候補に印を付けます。手順を記録して繰り返したい場合は、Excelに組み込まれた[Power Query](https://learn.microsoft.com/ja-jp/power-query/)で、値の置換や重複の削除を処理として保存できます。

破綻の兆しは3つです。ワークシートの上限である約104万行に近づくとき、毎月同じ作業を繰り返しているとき、そして担当者が異動すると直し方が分からなくなるときです。どれかに当てはまったら、ルールをツールかコードへ移す時期と判断してください。

### 外注の見積もり前に社内で決める項目と一度きりの代行で終わる発注の失敗

外注先には大きく2種類あります。企業データベースを持ち、社名や住所の補完まで請け負うデータ事業者と、ルールをETLや業務システムに組み込む開発会社です。前者は営業リストの整備に、後者は移行や定期連携に向きます。

どちらに頼む場合も、見積もり前に次の3点を社内で決めておきます。

- 対象：どのシステムのどの項目を、何件直すか
- 基準：手順の1段階目で決めた項目ごとの合格条件
- 判断者：要確認に回った候補を誰が判定するか

避けたいのは、汚れたファイルを渡して「きれいにしてほしい」とだけ依頼する発注です。納品時はきれいでも、ルールが自社に残らず、入力画面も変わらないため、1年後には元に戻ります。

## システム移行とデータ基盤構築の前工程として失敗しないクレンジングの設計

### 移行リハーサルで不合格件数を数え本番切替の判定基準に使う設計の考え方

システム移行では、新システムの入力チェックが旧システムより厳しくなるのが普通です。旧システムでは空欄が許されていた項目が必須になる、文字数の上限が短くなる、コードの体系が変わる。こうした差が、移行の当日に取り込みエラーとして一斉に表面化します。

そこで、移行リハーサルのたびにクレンジングのルールを適用し、新システムの取り込みで不合格になった件数を項目ごとに数えます。「必須項目の不合格が0件、それ以外は100件以下」のような基準を事前に決め、本番切替の判定に使ってください。移行方式の選び方や全体の進め方は[システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準を解説](https://www.issoh.co.jp/column/details/15261/)で整理しています。

### 入口で防ぐ入力制約と出口で直すバッチを組み合わせ再発を止める運用設計

移行が終わっても、汚れは入力のたびに入り込みます。再発を止めるには、入口と出口の両方に手を打つ必要があります。

入口では、郵便番号の桁数や電話番号の形式を入力時に検査し、社名は法人番号の検索結果から選ばせます。出口では、データ基盤へ取り込む処理の中でルール表を毎回適用し、違反件数を記録します。入口だけでは過去のデータとCSVの一括取込が残り、出口だけでは業務画面の表示が汚れたままです。

違反件数の推移を監視する仕組みまで作るなら、[データオブザーバビリティとは？五つの柱とデータ品質監視の導入判断](https://www.issoh.co.jp/column/details/16504/)の考え方が参考になります。ルールを取り込み処理に組み込む設計から相談したい場合は、一創の[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)で支援範囲を確認できます。

### 全件をきれいにしようとして移行が遅れる失敗パターンと対象を絞る判断

よくある失敗は、移行を機に全データを完璧にしようとすることです。10年分の取引履歴まで表記をそろえようとすると、要確認の件数が業務部門の処理能力を超え、移行日が延びます。

対象は次の順で絞ります。新システムで必須になる項目、請求や出荷など実害につながる項目、分析で集計キーになる項目の順です。過去の取引履歴は直さずに移行し、参照用として残す判断で構いません。直すのは、これから業務で使い続けるマスタと、未完了の取引に限るのが現実的な線引きです。

## よくある質問

データクレンジングを検討する担当者から挙がりやすい質問にお答えします。

### データクレンジングとデータクリーニングに違いはありますか？

実務ではほぼ同じ意味で使われています。どちらも誤りや不備を見つけて直す作業を指し、ツールの説明でも区別なく使われることが多い言葉です。文脈によっては、クリーニングを誤りの修正、クレンジングを表記の統一や補完まで含む広い作業として使い分ける例もあります。社内で使う場合は、言葉の違いよりも、どの項目をどの基準で直すのかをルール表で定めておくほうが混乱を防げます。

### データクレンジングと名寄せはどちらを先に行うべきですか？

クレンジングが先です。名寄せは同じ会社や人物を特定して一つにまとめる作業で、表記がそろっていない場合は、照合の精度が落ちるためです。「㈱一創」と「株式会社一創」を同じ文字列にしてから照合すれば、類似度の計算に頼らず完全一致で拾える件数が増えます。手順としては、正規化と置換でそろえる、完全一致で統合する、残りを類似度で判定して人が確認する、の順に進めます。

### データクレンジングはどのくらいの頻度で実施すればよいですか？

データの変化の速さで決めます。取引先の移転や社名変更は日々発生するため、法人番号の差分データを取り込む処理を月次か週次で回すのが一つの目安です。新規登録が多い顧客台帳は、取り込みのたびにルールを適用する形にすれば、まとめて直す作業そのものが不要になります。年1回の一斉整備だけに頼ると、整備の直後から品質が下がり始める点に注意してください。

### 生成AIにデータクレンジングを任せることはできますか？

表記の揺れを見つける、置換表の候補を作るといった補助には使えます。ただし、全件の修正をそのまま任せる運用は勧めません。同じ入力でも出力が変わることがあり、どのルールで直したのかを後から説明できないためです。生成AIはルール表の下書きや要確認候補の判定補助に使い、実際の修正は記録の残るルールとコードで行う分担が安全です。

### データクレンジングの費用は何で決まりますか？

件数、汚れの割合、要確認になった候補を誰が判定するかの3点で大きく変わります。外部の企業データで補完する場合は、照合する件数に応じた従量課金が加わる形が一般的です。見積もりの精度を上げるには、手順の2段階目で数えた項目ごとの汚れの件数を提示することです。件数が分からないまま依頼すると、見積もりの幅が広がり、各社の金額を同じ条件で比べられません。

## 関連記事

- [ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説](https://www.issoh.co.jp/column/details/13364/)：クレンジングを組み込む変換工程の仕組みです。
- [マスターデータ管理（MDM）とは？4つの実装方式と導入を見送る条件を解説](https://www.issoh.co.jp/column/details/19536/)：直したデータを正しく保ち続ける体制づくりです。
- [データマッチング技術とは？名寄せ・類似検索の3系統とツールの選び方](https://www.issoh.co.jp/column/details/2377/)：クレンジングの次に行う照合の技術を扱います。
- [顧客データ統合の進め方｜名寄せのキー設計とCDPを入れずに済む条件](https://www.issoh.co.jp/column/details/18983/)：顧客台帳に絞った名寄せキーの決め方です。
- [データ統合とは？種類・方式の違いと名寄せの壁から導入判断まで解説](https://www.issoh.co.jp/column/details/18977/)：複数台帳を一つにまとめる方式の比較です。

---

出典: [データクレンジングとは？表記ゆれ・欠損・重複を直す手順と移行前に決めるルール](<https://www.issoh.co.jp/column/details/19711/>)（株式会社一創）