目次
企業情報データベースを扱ったことがあるエンジニアなら、**「法人データの名寄せ（Corporate Name Aggregation）」**という言葉を聞いただけで胃が痛くなるかもしれません。「株式会社ＡＢＣ」と「（株）ＡＢＣ」を同じ会社だと認識させる。人間には一瞬でできるこの判断が、コンピュータにとっては果てしなく高い壁として立ちはだかります。
しかし、ここを避けて通ることはできません。名寄せの品質こそが、そのデータベースの価値を決定づけるからです。
1. 名寄せとは何か
名寄せ（Data Matching / Identity Resolution）とは、異なるデータベースや情報ソースに散らばっているデータを、同一の主体（この場合は企業）として紐付ける処理のことです。
例えば、「株式会社ＡＢＣ」と「（株）ＡＢＣ」と「ABC Inc.」がリストにあった場合、これらが全て同じ会社であることを特定し、一つのID（法人番号など）に統合するプロセスを指します。
2. なぜ名寄せが難しいのか
企業データの名寄せには、大きく分けて2つの「揺らぎ」が立ちはだかります。
企業は変化する（Temporal Change）
企業は生き物です。時間の経過とともに属性が変わります。
- 商号変更：「松下電器産業」→「パナソニック」
- 移転：本社住所が変わる
- 合併・分割：A社とB社が合併してC社になる
「名前が違うから別の会社だ」と判断すると、実は社名変更しただけの同一企業だった、ということが頻繁に起きます。
表記が揺れる（Orthographic Variance）
同じ会社名でも、書き方は千差万別です。
- 法人格の略称：株式会社、(株)、㈱、K.K.
- 数字と漢数字：六本木１丁目、六本木一丁目
- 全角・半角：ＡＢＣ、ABC
- 拗音・促音の大小：キヤノン（キャノン）、キユーピー（キューピー）
- スペースの有無：キヤノン マーケティング、キヤノンマーケティング
これらを正規化（Normalization）し、統一されたフォーマットに変換する前処理が必要ですが、例外パターンが無限に存在するため、完全な自動化は極めて困難です。
マッチングアルゴリズムの選定
文字列の類似度を測るためのアルゴリズムは多数存在し、データ特性に合わせて使い分ける必要があります。
- Levenshtein Distance（レーベンシュタイン距離）
- 2つの文字列が「何文字の変更（挿入・削除・置換）で一致するか」を数値化したもの。
- 例：「トヨタ自動車」と「トヨタ」→ 距離3
- Jaro-Winkler Distance
- 文字列の「先頭の一致」を重視するアルゴリズム。企業名は先頭に重要なキーワード（ブランド名）が来ることが多いため、有効な場合が多いです。
- 形態素解析 + BoW (Bag of Words)
- 「株式会社」「営業所」などの一般的な単語を除外（ストップワード処理）し、固有名称部分の一致率を見る手法。
単純な完全一致（Exact Match）だけでは、表記ゆれに対応できません。上記のような「ファジーマッチング（曖昧検索）」をいかにチューニングするかが、エンジニアの腕の見せ所です。
有効なオープンソースライブラリ（GitHub）
学術的にも実務的にも実績のあるライブラリを活用することで、開発工数を大幅に削減できます。
- dedupeio/dedupe (Python)
- 機械学習を用いて、レコード間の類似性を学習・推論する名寄せライブラリのデファクトスタンダード。
- 能動学習（Active Learning）により、人間が「これは同じ」「これは違う」といくつか教えるだけで、独自のマッチングモデルを構築できます。
- moj-analytical-services/splink (Python)
- 英国司法省が開発した、確率論的レコードリンケージ（Probabilistic Record Linkage）ライブラリ。
- 数百万〜数千万件規模の大規模データを高速に処理することに特化しており、SparkやAthena（SQL）バックエンドで動作します。
- seatgeek/thefuzz (Python)
- 旧
fuzzywuzzy。レーベンシュタイン距離を用いた文字列マッチングのシンプルかつ強力なライブラリ。 - 「株式会社」などの接頭辞を除去した後の文字列比較などで威力を発揮します。
- 旧
- ikegami-yukino/neologdn (Python)
- 日本語特有の表記ゆれ（全角半角の混在、不要なスペース、長音記号など）を正規化するための必須ツール。
- 名寄せの前処理（Preprocessing）として組み込むことで、マッチング精度が劇的に向上します。
3. 名寄せが失敗する典型例
現場でよくある「名寄せ失敗」のパターンを見てみましょう。
同名別企業の誤統合（False Positive）
「日本商事」のようなありふれた社名は全国に多数存在します。
- 東京都港区の日本商事
- 大阪府大阪市の日本商事
これらを「名前が同じだから」といって同一企業として統合してしまうと、全く別の会社の売上データや不祥事情報が混ざってしまい、致命的なデータ汚染を引き起こします。住所や代表者名まで見ないと区別できません。
同一企業の分離（False Negative）
前述の通り、表記揺れや社名変更を見逃し、本来は同じ会社なのに「別の会社」として登録してしまうパターンです。ユーザーが検索したときに情報が分散してしまい、「このサイトには情報がない」と判断されてしまいます。
4. 現実的な名寄せアプローチ
100%完璧な自動名寄せは存在しませんが、精度を高めるためのアプローチはいくつかあります。
-
法人番号の活用：国税庁が付与するユニークな13桁の番号をキーにするのが最も確実です。ただし、ソースデータに法人番号が入っていない場合は、まず名称と住所から法人番号を特定する「法人番号付与」のプロセスが必要になります。
-
正規化辞書の構築：「㈱」→「株式会社」、「1丁目」→「一丁目」といった変換ルールの辞書を地道に育てていく必要があります。
-
複合キーによるマッチング：社名だけではなく、「社名 ＋ 電話番号」「社名 ＋ 住所（郵便番号）」などの組み合わせで照合を行うことで、同名別企業の誤統合を防ぎます。
-
複合キーによるマッチング：社名だけではなく、「社名 ＋ 電話番号」「社名 ＋ 住所（郵便番号）」などの組み合わせで照合を行うことで、同名別企業の誤統合を防ぎます。
標準化プロセスのフロー例
実際のシステムでは、以下のようなパイプラインを構築します。
- クレンジング：全角英数の半角化、余分なスペースの削除、Unicode正規化（NFKC）。
- 法人格の統一：「(株)」「㈱」などをすべて「株式会社」などの完全な形、あるいは除去した形に統一。
- 住所の正規化：「1-2-3」「一丁目2番3号」を、郵便番号辞書ベースで統一ID化。
- ブロッキング：全件総当たりは計算コストが高すぎるため、「郵便番号が同じ」「頭文字が同じ」などの条件で候補を絞り込む。
- 詳細スコアリング：絞り込んだ候補に対して、Levenshtein距離などで類似度スコア（0.0〜1.0）を算出。
- 判定：スコアが0.95以上なら自動統合、0.8〜0.95なら人間による確認、それ以下は非統合、といった閾値設定。
5. 名寄せ精度とサイト価値の関係
「名寄せなんて、裏側の処理だからユーザーには関係ない」と思うかもしれません。しかし、名寄せの品質は、サイトのSEO評価やユーザー体験（UX）に直結します。
- ページ評価の分散：同じ会社なのにURLが複数あると、被リンクなどのSEO評価が分散します。
- 信頼性の低下：「検索したら同じ会社が3つ出てきた」「合併前の古い社名のまま残っている」。これを見たユーザーは「このサイトのデータは管理されていない」と感じ、二度と訪れません。
名寄せは、データベース運用の根幹に関わる重要な処理です。 データ構造の整合性を保つための継続的なメンテナンス体制と、例外パターンへの組織的な対応フローの構築が、システムの信頼性向上には不可欠です。