目次
国内の名寄せですら心が折れそうなのに、海外法人が混ざった瞬間、難易度は「指数関数的」に跳ね上がります。
「グローバル統一の顧客管理システム（CRM）を作ろう」 そう意気込んでスタートしたプロジェクトが、半年後に「データのゴミ捨て場」と化して頓挫する。私はそんな光景を何度も見てきました。
何がそんなに難しいのでしょうか？ 言語の壁？ いいえ、もっと根本的な**「構造の壁」**があるのです。
1. 文字と表記のバベルの塔
「アルファベットなら世界共通だろう」というのは幻想です。
Case 1: 半角・全角の呪い（The Byte Width Curse）
日本企業特融の問題ですが、社内のSFAにこんなデータが混在していませんか？
ＡＰＰＬＥ ＩＮＣ．（全角英数）APPLE INC.（半角英数）Apple Inc.（キャメルケース）
「これくらいプログラムで正規化（Normalize）できるだろ」 おっしゃる通りです。しかし、これが非ラテン圏に行くとどうでしょう。
Case 2: 現地語 vs 英語（The Script Barrier）
中国企業のデータを扱うとき、あなたは以下の2つを同一企業としてマッチングできますか？
Tencent Holdings Ltd腾讯控股有限公司
人間が見ればなんとなく分かりますが、文字列一致ロジックでは類似度ゼロです。 「名寄せ」をするためには、全データに対して「英語正式名称（Official English Name）」というカラムを付与する必要がありますが、そもそも英語登記を持っていない現地ローカル企業も山ほど存在します。
2. 法人格（Legal Entity）の多様性
日本なら「株式会社」「合同会社」くらいですが、世界には星の数ほどの「会社の種類」があります。
頻出するサフィックス（接尾辞）
- Inc. / Corp. / Ltd. / LLC (アメリカ・イギリス系)
- GmbH / AG (ドイツ系: ゲーエムベーハー / アーゲー)
- S.A. / S.A.S. / S.R.L. (フランス・スペイン・イタリア系)
- Pte. Ltd. (シンガポールなど英連邦系)
- K.K. (日本の株式会社を海外表記する場合)
ノイズ除去の難しさ
名寄せの第一歩は「法人格の除去」です（Apple Inc. → Apple）。
しかし、ドイツの GmbH は文末に来るとは限りません。
時折、入力ミスで住所の一部 ...Street, GmbH building 3F... が社名欄に混入していると、単純な置換ロジックでは必要な情報まで消し飛ばしてしまいます。
3. 「支店」と「現地法人」の致命的な違い
これが実務上、最もリスクが高い罠です。
あるグローバル企業「Global Corp」と取引をするとします。
- A:
Global Corp Japan Branch（日本支店） - B:
Global Corp Japan K.K.（日本法人・子会社）
名前は似ていますが、法律上の扱いは天と地ほど違います。
- 支店 (Branch): 本社と同一人格です。支店が倒産したら、本社に借金を請求できます。
- 現地法人 (Subsidiary): 本社とは別人格です。現地法人が倒産しても、原則として本社に請求権はありません（有限責任）。
与信管理（Credit Risk Management）の観点では、この2つを混同して「同じGlobal Corpグループだから」と合算して与信枠を設定するのは自殺行為です。 しかし、現場の営業マンは「あー、全部グローバルコープさんですね」と名寄せして登録してきます。システム担当者はこれを機械的に分離しなければなりません。
4. 救世主：標準IDの活用（DUNSナンバー）
結論を言います。海外法人の名寄せを自社独自のID体系でやろうとするのは諦めてください。 コストが青天井になり、品質は維持できません。
世界標準の識別コードを使うのが、唯一の正解です。
D-U-N-S Number (ダンズナンバー)
米Dun & Bradstreet社が管理する、世界9桁の企業識別コード。 事実上の世界標準です。GoogleもAppleも米国政府も使っています。
- メリット: 親子関係（Family Tree）が紐付いている。「A社はB社の親会社」という系列データが手に入ります。
- デメリット: 有償です。そこそこ高いです。しかし、自前で名寄せ工数をかけるよりは確実に安いです。
LEI (Legal Entity Identifier)
リーマンショックの反省から金融危機管理のために生まれた国際的な法人識別子。
- メリット: 金融取引をするような大手企業はほぼ持っています。オープンデータとして公開されています。
- デメリット: 中小企業のカバー率は低いです。
まとめ：餅は餅屋に
海外データの名寄せは、**「どれだけ自前主義を捨てられるか」**の勝負です。 表記揺れの正規化ロジックを自社開発するくらいなら、D&BのAPIを叩くか、名寄せ専門のベンダーツール（TrilliumやInformaticaなど）を導入すべきです。
「データ整備にお金をかけたくない」という経営層にはこう伝えてください。 「取引先の法的実態（支店か子会社か）を間違えたまま契約書を結んで、代金回収不能になったら、誰が責任を取るんですか？」
これが、システム担当者が切れる最強のカードです。