🎯

AI時代の名寄せ：エンティティ解決とは何か？

に公開
data
er
entityresolution
idea

日本の法人や個人に関するデータをエンティティ解決することを目指してパーサーの開発を開始し、v0.1として法人パーサーをPyPiで公開しました。このパーサーに関する紹介は、次回以降で行うこととし、今回は、このライブラリを開発した背景にある、エンティティ解決について紹介できればと思います。

なおライブラリのコードは new-village/ja-entity-parser で公開しています。Pre-releaseで開発にリソースを割いているので、全てに対応はできませんが不具合等があればIssuesにお願いします。

エンティティ解決ってなに？

エンティティ解決（Entity Resolution） とは、複数のデータソースから現実世界のエンティティ（人物、企業、住所など）を識別し統合するデータ・マネジメントの一要素です。従来から、この領域は「名寄せ」と言われており、データベース内の重複レコードの排除や、キーのないデータベース間でのデータ・マッチングの取り組みとして行われてきました。これらの取り組みにより、単一の顧客の適切な活動の把握（店舗での顧客の動きと、オンラインでの顧客の動きが一貫性のある形で捉えられる、など）や、複数のアカウントを使った悪意のある動き（ハッキングされた複数の口座による単一顧客の口座への送金）を捉えることが可能となります。

世の中的には、日本政府におけるマイナンバーや、法人番号、銀行におけるCIF（Customer Information File）、日本郵政グループにおけるデジタルアドレスなど、共通的な番号を振って管理を効率化するという流れがありますが、これらの枠を超えて作成されるデータ（海外取引、システムを跨ぐ活動など）との統合や、悪意を持った統合IDの利用（シェルカンパニーなど）に対しては、引き続き名寄せが求められており、時流を超えて継続的な取り組みが求められるものとなっています。

従来の名寄せと現代的エンティティ解決の違い

従来の名寄せのアプローチでは、ロジックに基づくデータの標準化（旧字新字の統一や、生年月日のフォーマットの統一など）やデータ辞書を使った標準化（住所マスタを使った統廃合住所の変換など）と、その後のルールに基づく1:1のマッチング（姓名と生年月日が一致する、名と生年月日と性別が一致するなど）によって、データの統合を実現していました。こうしたアプローチは人間の知見をルール化した決定論的アプローチであり、実装は比較的容易ですが、新たなデータパターンへの対応力や精度の限界がありました。

エンティティ解決では、機械学習や統計的マッチング・アプローチを活用することで、手作業のルール設定に頼らずデータからマッチングロジックを学習させることで高精度な照合を実現します。具体的には、マッチングにおいて、レコードが持つ各属性の一致・不一致に確率的重み（寄与度）を与え、複数属性の比較から2レコードが同じ実体である確率を算出します。例えば氏名が一致することの寄与度や、生年月日が一致することの寄与度をデータ全体の頻度から計算し、総合的なスコアを算出することで、データのマッチングを行なっていきます。この考え方では、データソースが増えれば増えるほど、マッチングに使える要素が多くなり、精度向上が見込めるものとなっているため、特に大量のデータを扱う分野において、人手での作業を高精度かつ高い生産性を持って代替できる可能性を秘めています。

エンティティ解決の典型的な処理フロー

エンティティ解決では、①データの標準化、②組み合わせキー（コンパウンド）の作成、③組み合わせキーのマッチング、④スコアリングとマッチ判定、⑤クラスタリング（レコード群の統合）という処理フローを経て、エンティティを生成します。

1. データの標準化

照合対象のデータに対し、比較しやすい形に正規化する工程です。具体的には、全角半角や大文字小文字の統一、住所表記の正規化、不要な記号の除去、姓名の分割や読み仮名の付与などを行います。名寄せと比べて特徴的なのは、特に変数を増やしていくことです。住所における都道府県、市区町村、街区、丁目番地、建物名でのパースや、姓と名、法人種別とブランド名のパース、はたまた、音韻変換による発音情報の付与や、郵便番号情報から、正規化された住所を追加で付与するといったことがおこなれます。マッチングに使える要素を数多くエンリッチすることは、データのクレンジングに加えて、このプロセスにおいて重要な内容となります。

2. 組み合わせキー（コンパウンド）の作成

生成された変数に対して、比較対象となる組み合わせを作成する工程です。マッチングで利用する組み合わせを定義していきます。例えば、姓＋名＋生年月や法人名＋本社所在地、トリッキーなケースでは法人名（働いている法人)＋姓＋名などです。もちろん、法人番号やマイナンバーといった一意のキーも重要なコンパウンドになりえます。
統計的なマッチングでは、すべてのレコードの組み合わせを使うことができますが、2^変数の数だけ組み合わせが発生することとなり、多くのコンピューティング・リソースが必要となるため、あらかじめ使わない、意味的に重複する項目を排除していきます。また、組み合わせを事前に定義することは、マッチングした後に、何が二つのレコードを名寄せしているのかを説明するための要素にもなるため、エンティティ解決の説明性を確保する上でも重要な作業となります。

3. 組み合わせキーのマッチング

作成した組み合わせキーで作成したレコードについて、一致/不一致のマッチングを行なう工程です。ここでは、姓＋名＋生年月では不一致、名＋生年月日＋住所では一致などの比較結果が得られます。エンティティ解決のアプローチによっては、この段階で文字型をベクトル型に変換し、ベクトル距離から類似度を算出して、曖昧マッチングを実現したりするケースもあります。ただ、この工程は日本語固有の問題に大きく影響を受ける（例えば、異字体（高崎と髙﨑）、同形異音語（「すが」と「かん」）、海外法人名（トヨタ自動車株式会社とToyota Motor Corporation））ため、データの標準化処理で様々なエンリッチを施しておくことが高い精度を実現するための秘訣となります。

4. スコアリングとマッチ判定

組み合わせキーのマッチング結果を統合し、組み合わせキーにマッチ度スコアを付ける工程です。ルールベースであれば「複数の組み合わせキーを満たせばマッチ」といったスコア算出不要の場合もあります。一方、機械学習や確率モデルでは前述のように重み付きの総合スコアや確率値を計算し、しきい値以上ならマッチと判定します。ユーザはこのスコアに基づき閾値を調整してPrecision（精度）とRecall（再現率）のバランスを最適化できます。スコアリング後、しきい値を超えたペアはマッチ（同一エンティティ）、それ未満は別エンティティと分類されます。ルールベースと比べ、スコアリング方式は微妙な類似も反映でき柔軟ですが、最終的なしきい値設定は業務要件に応じて調整が必要です。

5. クラスタリング（レコード群の統合）

判定されたレコードのペア集合を元に、同一エンティティのレコード集合（クラスター）を構築する工程です。例えば、データソースAのレコード1とデータソースBのレコード1がマッチ、データソースBのレコード1とデータソースCのレコード1がマッチしたのであれば、A/B/Cのそれぞれのレコードを同一クラスターにまとめます（推移的にグループ化）。クラスタリングにはグラフ・アルゴリズムや、階層的クラスタリング（スコアに基づきレコードを段階的にマージ）などが使われます。最終的に、クラスタリングされたレコードに対して統一IDを付与したり、ゴールデンレコード（マスターとなる代表レコード）の生成を行って、その後のデータ活用に利用できる形にしていきます。

エンティティ解決に使えるOSS

これらを実現するソフトウェア、ライブラリは既にOSSとして存在しており、試すことが可能です。どのソフトウェアも機械学習をベースとしたマッチング機能を提供しているため、おそらく日本語でもある程度は機能するものと思いますが、1. データの標準化については相変わらず別途手当が必要かと思われます。

Splinkは英国の司法省（Ministry of Justice）が開発したオープンソースのエンティティ解決ツールです。Pythonで作られたエンティティ解決エンジンで、2025年現在も活発にコミットが行われているソフトウェアです。

SplinkのコアはFellegi-Sunterの確率的レコードリンケージモデルに基づいています。このモデルはペアの変数比較からマッチ確率を推定する統計的手法で、学習用の事前ラベルがなくても教師なし学習でパラメータ推定することが可能です。Splinkではこの古典的手法を拡張し、頻度調整（値の出現頻度に応じたスコア補正）やユーザー定義のあいまい比較関数を組み込む柔軟性があります。

Zingg

Zinggはエンティティ解決を行うオープンソースツールで、インド発のスタートアップであるZingg.AIのチームによって開発・メンテナンスされています。最新バージョン0.5.0が2025年7月にリリースされており、積極的な機能拡張とコミュニティ主導の改善が続けられています。

Zingg最大の特徴は機械学習（ML）ベースのアプローチにより、高精度なエンティティ解決モデルを構築できる点です。Fellegi-Sunterのような事前確率モデルではなく、レコードペアをマッチ/非マッチに分類する教師ありモデルを学習します。ただし大量の教師データを用意する必要はなく、Zinggはアクティブラーニングによるインタラクティブなトレーニング機能を備えています。ユーザーはコマンドライン上で提示される候補ペアに対し「同一」「異なる」「不明」をラベル付けしていくだけで、モデルが徐々に学習されます。この訓練データビルダーによって、ごく少量のラベルでも高精度のモデルを得られることを目指しています。また、Zinggは多言語対応が考慮されており、人名や住所のマッチングで英語以外（中国語・タイ語・日本語・ヒンディー語等）もサポートしています。これはUnicode正規化や言語別トークナイザを内部に持つことで実現しており、グローバル企業でのデータ統合にも有用です。

Dedupe

DedupeはPython向けの古典的かつ実績豊富なエンティティ解決ライブラリです。2014年頃に米国シカゴのデータサイエンス企業DataMade社によって開発されています。プロジェクト開始から約10年が経過していますが、2024年まで継続的にコミットやバージョンアップが行われています。

Dedupeは名前の通り重複排除に焦点を当てたライブラリで、レコード同士が同一か否かを判定する機械学習モデルを用います。特徴的なのは、人間の教示を取り入れたアクティブラーニングのアプローチです。ユーザーがいくつかのレコードペアについて「同一」「異なる」をラベル付けすると、ライブラリはその情報を元に類似度計算のための最良のルール組み合わせ（例えば「姓のJaro-Winkler距離が0.9以上且つ郵便番号が完全一致ならマッチ」といった条件）を機械学習で自動発見します。

DeepMatcher

DeepMatcherはウィスコンシン大学マディソン校の研究グループが開発した、深層学習を用いたエンティティ解決ライブラリです。

Python（PyTorch）で実装され、教師あり学習によりテキスト属性を埋め込み表現に変換してペアを分類します。特徴量設計を最小限に抑え、RNNやAttentionといったニューラルアーキテクチャで高精度なマッチングを実現します。ブロッキングやクラスタリングは別ツールと組み合わせる前提ですが、研究ベンチマークで高い精度を示しており、ディープラーニング・アプローチを試す際の有力な選択肢です。

ここまでOSSを紹介してきましたが、エンタープライズで利用する場合は AWS Entitiy Resolution, BigQuery entity resolution framework など大手クラウドベンダーや、Quantexa、Senzing といったスタートアップがソリューションを提供しているようです。

Discussion