名寄せとは？やり方と精度を上げる実務ポイント

顧客・取引先マスタの重複や表記ゆれを放置すると、営業活動の重複、請求先の取り違え、ERP移行時のデータ不整合などにつながります。一方で、名称が似ているだけの別法人を統合すると、重複を残すより大きな業務リスクになることがあります。

名寄せは単なる重複削除ではなく、「何を同一とみなすか」を決める業務設計です。統合対象、照合キー、品質確認、実施方式を自社の条件に合わせて判断できるようになります。

名寄せは重複を消す作業ではなく、何を同一として扱うかを定め、照合・判定・確認・継続運用までつなげる取り組みです。

01Section名寄せとは何か｜まず対象単位を決める

名寄せとは、複数のレコードが同じ実体を指している可能性を照合し、統合・未統合・保留・除外の扱いを決める作業です。この記事では、国内法人の顧客・取引先マスタを主な対象として説明します。

最初に決めるべきことは、重複レコードの数ではなく「何を1件として管理するか」です。法人単位で統合するのか、拠点、請求先、契約先まで区別するのかによって、必要なキーと統合してはならない条件が変わります。

預金保険制度の名寄せとは対象が異なる

金融機関では、預金保険制度において預金者単位で預金等の債権額を把握するために名寄せが行われます。これは、企業が顧客・取引先マスタを整備し、営業・請求・契約・分析などで利用するための名寄せとは、目的と対象が異なります。制度の詳細は金融庁・預金保険機構「預金保険制度（ペイオフとは？）」で確認できます。

名寄せと周辺作業を工程・成果物・責任範囲で分ける

名寄せ、正規化、データクレンジング、重複排除、マスタ統合は、使われる場面によって重なることがあります。ここでは厳密な同義語・対義語としてではなく、対象、成果物、責任範囲を分ける実務上の整理として扱います。データ品質に関する用語を確認する際は、ISO 8000-2も参照先になります。

名寄せが必要になりやすいのは、複数システムに同じ取引先が別コードで登録されている場合、略称や記号・全角半角の違いで同一法人が分かれている場合、組織再編や所在地変更後に旧データが残る場合です。ただし、属性の最新化、必須項目の欠損、登録時の入力統制まで名寄せだけで解決するわけではありません。欠損・誤記の点検を含むデータ整備の全体はデータクレンジングの手順と進め方で、部門横断で正とするデータをそろえる考え方はマスタデータの種類と整備・管理で解説しています。

02Section名寄せのやり方｜対象・キー・判定ルールを順に設計する

照合ツールや関数を選ぶ前に、対象範囲と判定ルールを決めます。後からルールを変えると、統合済みデータの見直し、ID対応の修正、再検証が必要になるためです。

目的・対象範囲・判定単位を定義する

たとえば「法人を統合する」という方針でも、請求先が法人本体と異なる、同じ法人に複数拠点がある、契約単位で管理する必要があるといったケースでは、法人番号や法人名の一致だけで統合できません。

要件として、少なくとも次の3点を定めます。

• 主キー候補：法人番号、社内の取引先IDなど、同一性を強く判断できる項目
• 補助キー：名称、所在地、電話番号、メールアドレス、契約IDなど、主キーを補強する項目
• 統合禁止条件：同名でも所在地や契約先が異なる場合、法人は同じでも請求先が異なる場合など、統合してはならない条件

法人番号と補助キーを使い分ける

国税庁の法人番号とはによると、法人番号は法人等に指定され、法人番号、商号または名称、本店または主たる事務所所在地の基本3情報が公表されています。このため、国内法人を法人単位で照合する際の有力なキー候補になります。

ただし、法人番号の一致は「業務上も同じ管理単位である」ことまで示すものではありません。法人番号を持たない、または法人単位だけでは識別できない対象には、補助キーや例外ルールが必要です。

正規化、候補抽出、統合・保留・履歴管理をつなぐ

名称の株式会社表記、記号、全角半角、住所の丁目・番地表記などを整えると、完全一致や条件一致で見つかる候補が増えます。ただし、照合用に変換した値で原表記を上書きすると、後から判断根拠を確認できなくなります。原表記と正規化後の値を分けて保持してください。

Power Queryでは、テキスト列に対するあいまい一致結合や類似度しきい値の設定ができます。Microsoft LearnのFuzzy merge - Power Queryを使えば、候補抽出の方法を確認できます。

03Section名寄せ精度を上げるには｜誤統合と見逃しを分けて検証する

統合済み候補だけを確認しても、未統合のまま残った重複は把握できません。誤統合と見逃しを分けて確認します。

名寄せの品質は、統合件数の多さでは判断できません。別の会社を同一としてしまう誤統合と、同一実体を別のまま残す見逃しは、確認すべき母集団が異なるためです。

データルールやデータプロファイリングを通じて、データの完全性・信頼性に関わる要件を整理する考え方は、ISO/TS 8000-82でも確認できます。ただし、この規格が名寄せの合格率やサンプル数を一律に定めるわけではありません。

誤統合と見逃しでは確認対象が異なる

誤統合を確認するには、すでに統合したレコードを見ます。一方、見逃しを確認するには、未統合・保留・除外のレコードと、過去の旧新ID対応や業務部門が把握している重複など、既知の同一実体リストを確認します。統合済み候補だけを確認しても、見逃しは把握できません。

判定区分・データソース・業務リスク別に確認する

通常候補を一括で抽出すると、特定のデータソースやルールに偏った誤りを見落としやすくなります。少なくとも「判定区分×データソース×業務リスク」で確認母集団を分けます。必要に応じて、使用キー、ルール版、対象期間も分けてください。

特に、類似度しきい値の近傍、名称変更直後、法人番号未取得、住所や電話番号だけが一致する候補、ルール改定直後の候補は、重点的に確認する対象です。

基準未達時は受入保留から再検証へ進む

受入時には、母集団、抽出方法、確認件数、誤統合・見逃しの有無、根拠とID対応を追跡できるか、確認者とルール版を残します。一律の精度目標ではなく、業務リスク、確認できる正解情報、抽出方法、測定時点を踏まえて受入条件を決めるためです。

基準に達しない場合は、次の順に扱うと影響範囲を見落としにくくなります。

1. 1該当区分または本番反映を保留する
2. 2元データ、正規化、候補抽出、判定ルール、業務判断のどこに原因があるか分類する
3. 3同じキー・ルール・データソース・対象期間に影響する候補を再抽出する
4. 4データ補正またはルール改定後に再判定し、ID対応表を更新する
5. 5修正範囲と改定ルールの適用範囲を再検証し、承認する

04Section名寄せはExcelでできる？｜試行結果で実施方式を選ぶ

実施方式はレコード数だけでなく、保留・例外、更新頻度、履歴や権限管理、確認体制を含めて選びます。

ExcelやPower Queryは、限定されたデータソースの整形、完全一致・条件一致候補の抽出、照合リストの作成、目視確認の管理を試す用途に向いています。ただし、本番方式は件数だけでなく、例外処理、更新頻度、履歴、権限、監査性、情報管理、確認体制を踏まえて選ぶ必要があります。

サンプル試行から本番方式を決める判断フロー

本番方式は件数だけで決めず、限定試行で例外処理や確認体制まで確かめます。

1. 1対象単位と業務リスクを確認する：法人・拠点・請求先・契約先のどれを対象にするかを定め、誤統合した場合に請求・支払・契約・与信へ影響するかを整理します。
2. 2限定サンプルで候補の内訳を可視化する：完全一致、条件一致、あいまい一致、保留の件数と内容を確認します。
3. 3試行結果を記録する：保留率、例外の種類、業務部門への照会・目視確認工数、再実行性、情報管理上の課題を残します。
4. 4分岐条件で本番方式を選ぶ：限定的なデータソースで明確な一致が中心ならExcel等での試行を継続し、定期更新や履歴・権限管理が必要なら自社での仕組み化を検討します。複数部門・複数システム、複雑な例外、移行期限、社内体制不足が重なる場合は、外部支援を検討します。

初回整備と継続運用を分けて考える

初回の重複整理が完了しても、新規登録、名称変更、組織再編、他システム連携によって重複は再発します。そのため、初回整理を誰が行うかと、更新時に誰が候補を確認するかは別に設計します。

最小限でも、利用目的と統合禁止条件を決める業務責任者、ルールと証跡を管理するデータ管理担当、保留候補を判断する業務確認者が必要です。移行や連携を伴う場合は、抽出、変換、ID連携、権限設定を担うシステム担当と、本番反映を承認する担当者も加わります。

05SectionERP・システム統合では移行前後の運用まで設計する

ERP・CRMの導入やシステム統合では、名寄せを移行直前の重複削除として扱うと、旧IDとの対応が失われたり、移行後に再び重複が増えたりします。データ移行は、現行システム・業務のデータを新しいシステム・業務で利用可能にするための一連の作業です。移行の対象、方法、体制、役割、準備・実施作業、整合性確認を整理する考え方は、デジタル庁の標準ガイドライン解説書も参考になります。

移行前に決める対象・属性・ID・受入条件

移行前には、統合後に正とするレコードと属性の優先順位、統合禁止条件、保留の回答者、旧IDと新IDの対応保持方針を決めます。現行システムごとに入力ルールやコード体系が異なる場合は、どの属性を採用するかをデータオーナーが決める必要があります。

また、受入条件には件数整合だけでなく、判定区分別の確認方法、重要取引先の確認、未解消保留の扱いを含めます。

移行時のリハーサルと判定区分別の確認

リハーサルでは、抽出から正規化、候補抽出、統合、ID変換、連携先への反映までを同じルールで試します。受領件数、変換件数、統合件数、未統合件数、保留件数の整合に加え、誤統合と見逃しの確認を行います。

高リスク対象の全件確認、例外処理の反映、旧新ID対応の参照、切戻しの判断条件を、本番前に確認しておくことが重要です。切戻し方法や停止可能時間は、対象システムと連携構成によって異なるため、個別の移行要件として定めます。

移行後の登録統制、更新権限、定期点検

移行後は、新規登録時に既存マスタを検索する手順、重複候補の確認者、更新権限、組織変更・名称変更時の扱いを運用に組み込みます。保留候補を期限なく残さず、定期的な候補抽出と例外点検の担当を決めることも必要です。

ERP導入とデータ移行の全体工程は、ERP導入の進め方もあわせて確認すると、名寄せをどの工程で設計・検証するか整理しやすくなります。

06Section外部に依頼する場合の見積比較・検収・情報管理

外部依頼では、対象件数に加えて判定条件、確認範囲、ID対応、納品物、情報管理の条件をそろえて比較します。

外部支援を検討する場合、レコード数だけで見積を比較すると、目視確認、業務照会、ID対応、移行支援、検収支援などの範囲差を見落とします。公開情報だけでは同じ条件での価格比較が難しいため、対象範囲と成果物をそろえた個別見積で確認してください。

比較可能な見積にするために前提条件をそろえる

レコード数だけでなく、判定・確認・納品・情報管理の範囲をそろえて比較します。

候補比較と検収で確認する品質・成果物

統合件数が多いことは、品質の高さを意味しません。候補比較では、統合・未統合・保留・除外の判定条件、業務確認の範囲、判定根拠と処理手順を引き継げるかを確認します。

検収では、処理対象件数と判定区分別の内訳に加え、重要対象の全件確認、誤統合・見逃しの確認結果、旧新ID対応と根拠の追跡可否、未解消保留の扱いを確認します。

個人データを含む場合の委託先監督

名寄せ対象に担当者情報などの個人データが含まれる場合は、通常の品質・納品条件に加え、委託先管理が必要です。個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」では、委託先における安全管理措置について必要かつ適切な監督を行う考え方が示されています。

委託先の選定時には、扱うデータの性質・量、漏えい時の影響、委託業務の規模・性質に応じて、安全管理措置を確認します。契約では、アクセス権、保管、持出し、返却・削除、事故時連絡、取扱状況の報告方法を定めます。再委託を認める場合は、対象業務、取扱データ、事前報告または承認、監督方法も確認対象にします。

07Section名寄せを始める前に決める3つのこと

名寄せの着手前に、すべてのデータを一度に整備しようとする必要はありません。まずは業務影響を確認しやすく、データソースを限定できる範囲で試行し、ルールと確認体制が機能するかを確かめます。

最初の検討では、次の3点を決めると、試行範囲と本番方式を具体化しやすくなります。

1. 1何を1件として統合するか：法人、拠点、請求先、契約先を混同せず、対象単位と統合禁止条件を決めます。
2. 2誤統合を避けるべき業務は何か：請求・支払・契約・与信など、高リスク用途と重要取引先を特定し、全件確認の対象にします。
3. 3誰が確認し、誰が更新するか：保留候補の回答者、データオーナー、更新権限、本番反映の承認者を定めます。

試行後は、保留率、例外の種類、業務確認工数、再実行性を振り返ります。その結果をもとに、限定試行を継続するか、自社で継続運用を仕組み化するか、外部支援を含めて進めるかを判断してください。

ERP移行を伴う名寄せの進め方を相談したい場合

複数システムの統合、旧新ID対応、受入条件の設計を伴う場合は、対象範囲、判定ルール、確認体制、移行後の運用まで整理したうえで支援先を比較できます。

ERP導入564社掲載

ERP導入の相談先を探す