作成：Uptech · 更新日: 2026-10-20

機械的な統一と確認が必要な修正

前後の空白や指定文字種の統一は明確な変換規則で処理します。住所不足、旧社名、部署違いなど意味の確認を伴う項目は修正候補として分けます。元データを保持し、再現できる変換番号を付けます。

重複を消す前の承認

一致キー、比較対象、統合後の主レコードを定義します。受注履歴や請求先が別管理の場合は、参照先の付替え可否も確認が必要です。判断が分かれる候補は統合せず、発注側の承認待ちとして残します。

項目定義、現行マスターの抜粋、困っている重複例、正とする参照元を用意してください。修正可能な列と閲覧だけの列、返却形式、差分だけを取り込む方法を確認して作業量と体制を評価します。

クレンジングの仕様は「表記を統一する」だけでは不足します。対象列、変更条件、処理順、例外、承認者をルール番号ごとに定めます。電話番号の文字種変換と法人の同一性判断はリスクが異なるため、機械的な変換、修正提案、統合承認を別工程にします。

元データは読み取り専用の基準版として残し、各レコードの元IDを保持します。取引履歴や請求情報が参照するキーは勝手に置換しません。住所や電話番号を外部サイトで補完する場合は、利用可能な情報源、参照権限、根拠の記録方法を発注側が先に指定します。

以下は説明用の架空の顧客マスターです。C10の空白と電話番号は承認済み規則で変換しますが、C10とC11は会社名が似ていても部署と請求先が異なるため、重複候補のまま残します。候補抽出と削除を同じ操作にしない例です。

発注側がC11をC10へ統合すると承認した場合も、残す住所、請求先、関連レコードの付替えを指定してから差分を作ります。納品には新しい一覧だけでなく、ルール番号、旧値、新値、承認記録を含め、未承認候補を完成データへ混ぜません。

一致判定は、顧客番号の完全一致、名称と住所の組合せ、類似度による候補などに分けます。一致度が高いだけで同一顧客と断定せず、支店、家族、部署、旧取引先の例外を試行へ含めます。候補ごとに比較した値と統合しない理由も返すと、承認者が判断しやすくなります。

本番反映前には件数の増減、参照先、重複キーの有無を確認します。承認後に基準データが更新されていれば、古い差分を上書きせず競合として戻します。復元方法も、元ファイルへ戻すだけで足りるのか、関連システムの更新取消しまで必要かを確認します。

受領件数、形式変換件数、重複候補件数、統合承認件数、保留件数をそれぞれ集計します。一つのレコードへ複数規則を適用した場合に、変換回数を完成レコード数として計上しないようにします。任意抽出だけでなく、高リスクの統合や重要項目の変更を確認対象にします。

検収者は、規則どおりに変わったか、変えてはいけない列が保持されたか、再実行して意図せず値が変わらないかを確認します。規則の追加が必要になった場合は版を更新し、既存の納品へ適用する範囲を再承認します。修正依頼と新しい要件を分けることで、再作業の責任も明確になります。