データマッチング技術とは？名寄せと類似検索の選び分け・法務要件

データマッチング技術という言葉は、顧客台帳の名寄せから商品レコメンド、マッチングアプリの相手推薦まで、まったく設計の異なる処理を一括りに指しています。同じ言葉で呼ばれているせいで、共通キーを突き合わせれば済む案件に埋め込みモデルを持ち込んだり、逆に「近い相手を探す」要件に完全一致の照合を当てて何も返らなくなったりする取り違えが起きます。この記事では3系統の判定対象の違いから選定基準を決め、精度チューニングより先に確認すべき法務とデータの前提までを扱います。

まとめ：3系統の選び分けと、実装前に潰す前提

データマッチング技術は、判定対象が「同一の実体か」か「近い実体か」かで系統が分かれます。同一実体を当てるなら共通キーの有無で決定的マッチングと確率的レコードリンケージを選び、近い実体を探すならベクトル類似検索を使います。ここを取り違えると、どれだけモデルを差し替えても精度は上がりません。

実装で効く判断は、突合前の表記正規化をどこまでやるか、近似探索の再現率を何%で握るか、属性フィルタとコールドスタートを初期設計に織り込むか、の3点に集約されます。いずれも後付けが利かず、モデル選定より先に決める必要があります。

そして精度より先に潰すべき前提があります。他社データとの突合は個人情報保護法第31条の確認義務に触れる可能性があり、面識のない異性との交際を目的とするサービスはインターネット異性紹介事業として届出と年齢確認が事業開始の条件になります。

データマッチング技術の3系統と適用条件

まず、目の前の案件がどの系統に属するかを判定対象から切り分けます。

出力の型が違う点が実務では効いてきます。上2つは真偽値または確率的な判定を返すため後段で自動統合できますが、ベクトル類似検索が返すのは順位であり、「上位何件までを採用するか」を業務側が決めない限り運用に乗りません。

決定的マッチング：共通キーが揃う場合の第一選択

会員番号、注文ID、法人番号のように両側の台帳が同じキーを持つなら、完全一致で突き合わせるのが正解です。処理はデータベースの結合1回で終わり、判定根拠が人間に説明できるため、監査対象の業務でも通ります。統計モデルを持ち込む余地はありません。

なお個人番号（マイナンバー）は、法定の事務以外で顧客の名寄せキーに転用することが認められていません。共通キーとして手元にあっても、この用途では使えない前提で設計してください。

確率的レコードリンケージ：キーの無い顧客データの突合

共通キーが存在せず、氏名・住所・生年月日といった準識別子だけで突き合わせる場合が確率的レコードリンケージの領域です。理論の土台は Fellegi と Sunter が1969年に Journal of the American Statistical Association 誌64巻1183-1210ページで示した定式化で、項目ごとの一致・不一致から尤度比を計算し、しきい値で「一致」「不一致」「保留」の3群に分けます。

この3群という出力形式が運用設計を規定します。機械が判定を放棄した保留群を人が目視する運用を前提にしているため、目視できる件数までしきい値を寄せる設計になります。全件を自動判定させようとすると誤統合が混ざり、顧客データの場合は請求先の取り違えという形で表面化します。統合後の顧客基盤をどう扱うかは、CDP（カスタマーデータプラットフォーム）とは？仕組み・DMP/CRMとの違い・導入ステップを解説で整理しています。

ベクトル類似検索：同一実体ではなく近い相手の探索

レコメンド、類似画像検索、マッチングアプリの相手推薦は、そもそも同一実体を探していません。「この人に近い人」「この商品に似た商品」という順位付けが目的で、正解が一意に決まらない点が上2系統と決定的に違います。データを埋め込みモデルで数値ベクトルに変換し、ベクトル間の距離が近いものを返します。埋め込みの次元数は用途によって数百から数千まで幅があり、次元が増えるほど1件あたりの保存量と距離計算の負荷が線形に増えます。

評価も変わります。同一実体の判定は正解ラベルに対する適合率と再現率で測れますが、類似検索の良し悪しはクリック率や継続率といった事業指標でしか確かめられません。オフライン評価だけで完成とみなさず、A/Bテストの枠を最初から確保してください。ベクトル化の仕組みそのものはベクトル化とインデックス構造から理解するベクトルデータベースの仕組みで扱っています。

確率的レコードリンケージを実務で回す条件

突合前の表記正規化で決まる精度の上限

モデルを組む前に、表記ゆれをどこまで潰したかで到達できる精度の上限が決まります。日本語の顧客データで効く順に、全角と半角の統一、法人格の位置と表記（株式会社の前置と後置、カッコ株の展開）、住所の丁目・番地のハイフンと漢数字、氏名カナの濁点と長音、旧字体の異体字を揃えます。ここを飛ばして確率モデルに任せると、機械が「別人らしさ」として学習してしまい、しきい値をいくら動かしても改善しません。

正規化を通した結果、共通キーが一致するようになるレコードも一定数あります。確率モデルへ移る前に、決定的マッチングで拾える範囲を使い切ってください。

Fellegi-Sunterモデルによるしきい値の置き方

Fellegi と Sunter の枠組みが実務で使われ続けている理由は、偽陽性率と偽陰性率を先に指定でき、同じ誤差水準を持つ判定規則の中で保留群が最小になることを証明した点にあります。つまり「誤って統合する確率を0.1%以下、見逃す確率を1%以下」という業務要件を先に決めれば、目視すべき件数が計算で出ます。

実装で外しやすいのは、項目ごとの一致確率を全件共通の定数で置いてしまうことです。氏名が「佐藤」で一致した場合と「五十嵐」で一致した場合では同一人物である可能性がまったく違うため、値の出現頻度で重みを変えないと、ありふれた姓の誤統合が増えます。

ブロッキングによる比較ペアの削減

確率的リンケージは全ペアの比較を前提にすると計算量で破綻します。10万件の台帳を自己突合する場合の組み合わせは約50億ペア（4,999,950,000）、10万件どうしの相互突合なら約100億ペア（10,000,000,000）です。1ペアあたり1マイクロ秒という楽観的な前提を置いても後者は約2.8時間かかり、実際の比較関数は文字列の編集距離を含むため桁が上がります。

そこで郵便番号の上3桁、生年月日の年、氏名の先頭カナといった粗いキーで候補を絞り込み、同じブロック内だけを比較します。ブロッキングキーを厳しくすれば計算量は落ちますが、そのキー自体が誤入力されているレコードは永久に照合されません。複数のブロッキングキーで別々に走らせて結果を統合するのが、取りこぼしと計算量の折り合いをつける定石です。

マッチ率ではなく適合率と再現率で測る評価

名寄せの成果を「重複が何%減ったか」というマッチ率で報告させると、しきい値を緩めるほど数字が良く見えるため、誤統合を増やす方向に力が働きます。正解ラベルを付けた標本を用意し、適合率と再現率、その調和平均で測ってください。

どちらを優先するかは業務で決まります。請求や与信のように誤統合の被害が大きい処理は適合率を優先し、キャンペーンの重複配信抑止のように取りこぼしが問題になる処理は再現率を優先します。両方を同時に上げる方法はしきい値の調整ではなく、前段の正規化と項目追加にしかありません。

ベクトル類似マッチングで検索品質を決める設計判断

距離尺度と埋め込みの正規化状態の整合

コサイン類似度とユークリッド距離のどちらを選ぶべきかという問いは、埋め込みを正規化しているかどうかで答えが変わります。単位ベクトルどうしなら「距離の2乗＝2−2×ドット積」が成り立つため、ドット積・コサイン類似度・ユークリッド距離が返す順位は必ず一致します。64次元・2000件の乱数ベクトルで確かめても全件一致しました。正規化していれば、この3つの選択に意味はありません。

逆に正規化していない場合、同じデータでドット積とコサイン類似度の順位は一致しませんでした。ドット積はベクトルの長さに引きずられるため、文書が長いというだけで上位に来る現象が起きます。使う埋め込みモデルが正規化済みベクトルを返す仕様かどうかを先に確認し、それに合わせて尺度を決めてください。計算式そのものはコサイン類似度とは？計算式・仕組みと類似検索での実装を実装目線で解説で扱っています。

再現率とレイテンシのトレードオフ

件数が増えると全ベクトルとの総当たりは現実的でなくなり、近似最近傍探索に切り替えます。近似である以上、本来の上位k件のうち何件を返せたかという再現率が100%を下回り、探索範囲を広げれば再現率は上がりますが応答時間も伸びます。この交換関係がベクトル類似マッチングの中心的な設計判断です。

Google Research が2020年7月28日に公開した ScaNN は、この曲線そのものを押し上げた実装として知られます。anisotropic vector quantization という量子化手法を導入し、ann-benchmarks の glove-100-angular データセットで、調整済みの他11ライブラリを上回り、同一精度で次点のライブラリのおよそ2倍のクエリ毎秒を処理したと報告されています。

実務では再現率の目標値を業務側と握るところから始めてください。レコメンドの候補生成なら90%前後でも体感差は出ませんが、法令上の照合や重複検知に近似探索を使うなら、そもそも近似で許容できる要件かを疑う必要があります。

属性フィルタとコールドスタートへの対処

実際のマッチングは類似度だけでは決まりません。マッチングアプリなら年齢帯と居住地、求人なら勤務地と雇用形態といった条件を必ず併用します。近似最近傍探索でこの絞り込みを後段に置くと、上位100件を取ってから条件で削った結果0件という事態が起きるため、インデックス側でフィルタを併用できる構成を前提に基盤を選んでください。

もう一つの制約がコールドスタートです。行動履歴のない新規ユーザーや新商品はベクトルが作れず、類似検索の対象になりません。プロフィール入力値やカテゴリなど登録時点で得られる属性から暫定ベクトルを組み、履歴が溜まった時点で差し替える二段構えが現実解です。キーワード側の検索と組み合わせる方法はハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードで解説しています。

系統ごとに分かれる実装基盤の分岐点

確率的リンケージ側：Splinkで賄える規模

確率的レコードリンケージは自前実装すると尤度比の推定で詰まりますが、既製の実装があります。英国司法省の分析チーム発の Splink は Fellegi-Sunter モデルとEMアルゴリズムを実装し、DuckDB や Spark など複数のSQLバックエンドを選べます。2026年3月11日公開の v4.0.16 が最新で、直近も更新が続いています。数十万から数百万件なら DuckDB バックエンドで単一ノードのまま回るため、分散基盤の調達を先に検討する必要はありません。

逆に、判定根拠を監査で説明する必要がある場合は、既製ライブラリの推定値をそのまま採用せず、項目ごとの重みを出力して業務側のレビューを通す運用を組んでください。

ベクトル側：自前運用とマネージド基盤の境目

基盤選定で最初に押さえるべきは製品名の変更です。Google の Vertex AI Matching Engine は2023年8月29日に Vertex AI Vector Search へ改称されており、現在この名前の製品はありません。ただし SDK のクラス名には Matching Engine の表記が残っているため、旧名で書かれた記事のコードがそのまま動く場合があり、名前だけで情報の新旧を判断できない点に注意してください。同サービスは前述の ScaNN を基盤としており、公式ドキュメントは中規模用途向けの最小構成を月100ドル未満と記載しています（2026年8月時点の定性的な記述）。

既に PostgreSQL を運用していて、ベクトルが数十万件規模にとどまり、既存テーブルの属性で絞り込みたいなら、専用基盤を立てる前に拡張機能で足りるか試すべきです。同一トランザクションで属性とベクトルを扱えるため、前述のフィルタ問題が構成上消えます。導入手順はpgvectorの基本概要とPostgreSQLにおけるベクトル検索の重要性にまとめています。

マネージド基盤へ倒すべきなのは、ベクトル件数が数千万を超える、更新頻度が高くインデックス再構築の運用を持ちたくない、といった場合です。関係性そのものを辿る要件が混ざるならグラフ側の選択肢も検討対象になり、ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】で比較しています。

精度改善より先に潰すデータと法務の前提

他社データとの突合に効く個人関連情報の規制

自社の顧客データに外部から購入したデータを突き合わせる構成は、個人情報保護法第31条の対象になり得ます。同法第2条第7項は個人関連情報を「生存する個人に関する情報であって、個人情報、仮名加工情報及び匿名加工情報のいずれにも該当しないもの」と定義し、個人情報保護委員会は具体例として性別・年齢・職業等の属性情報、ウェブサイトの閲覧履歴、位置情報を挙げています。逆に、その情報だけで本人を識別できるなら個人情報そのものなので、個人関連情報には当たりません。

条文の発動条件は「第三者が個人関連情報を個人データとして取得することが想定されるとき」です。照合できる可能性があるかどうかではなく、提供先が自社の個人データに紐づけて個人データとして扱うことが想定されるかで判断します。この場合、提供元は本人の同意が得られていることをあらかじめ確認しなければなりません。「渡す側は個人情報を渡していない」という説明は成り立たないため、データマッチングの企画がデータ購入から始まる場合、契約前にこの確認プロセスの有無を詰めてください。

サードパーティCookie廃止撤回後の広告マッチングの前提

広告ターゲティングを想定してマッチング基盤を設計するなら、前提条件が二度変わっています。Google は Chrome でのサードパーティ Cookie 一律廃止を撤回し、その後 Privacy Sandbox 側の主要APIについても廃止を発表しました。理由としてエコシステムからのフィードバックと導入率の低さが挙げられています。廃止が発表されたのは次のAPIです。

• Topics
• Protected Audience
• Attribution Reporting
• Private Aggregation（Shared Storage を含む）
• IP Protection
• On-Device Personalization
• Protected App Signals
• Related Website Sets
• SelectURL
• SDK Runtime

対象は Chrome 側と Android 側の双方にまたがりますが、どちらのプラットフォームが対象かはAPIごとに異なります。一方で CHIPS、FedCM、Private State Token は継続します。

結論として、Cookie 代替APIを前提に組んだターゲティング設計はやり直しになりました。かといって Safari と Firefox はサードパーティ Cookie を制限し続けているため、Chrome で温存されたからといって Cookie 依存へ戻すのも安全ではありません。自社で取得した会員データを軸にマッチングを組む方針が、この揺れの影響を最も受けにくい選択です。

異性紹介事業に該当するサービスの届出と年齢確認

面識のない異性との交際を目的とし、交際情報を公衆が閲覧できる状態に置き、閲覧者どうしが電子メール等で連絡でき、それを反復継続して提供するサービスは、インターネット異性紹介事業に該当します。4要件をすべて満たす場合が対象で、ビジネスマッチングや求人マッチングは含まれません。該当する場合、施行規則第1条第2項により、事務所所在地を管轄する警察署長を経由して、事業を開始しようとする日の前日までに開始届出書を都道府県公安委員会へ提出する必要があります。マッチング精度の検証より前に、この届出が事業開始の条件です。

年齢確認も方法が定められています。施行規則第5条第1項は、運転免許証その他の年齢または生年月日を証する書面について該当部分の提示・写しの送付・画像の送信を受ける方法のほか、マイナンバーカードの公的個人認証による生年月日情報の送信、クレジットカードのように児童が通常利用できない方法で料金を支払う旨の同意を受ける方法などを挙げています。自己申告のみで済ませる設計は要件を満たしません。名義貸しには六月以下の拘禁刑または百万円以下の罰金が定められています（2025年6月施行の刑法改正で懲役から拘禁刑に置き換わっており、旧表記の解説記事が残っている点に注意してください）。

マッチング事業そのものの構築論点はマッチングサイト・求人ポータルの構築とは？開発手法・費用・必須機能と、法規制の壁を解説で扱っています。当社の実装支援はCtoCマッチングシステム開発でご相談いただけます。

よくある質問

データマッチングと名寄せは同じ意味ですか？

名寄せはデータマッチングの一部です。データマッチングは複数のレコードが同じ実体を指すかを判定する処理全般を指し、名寄せはその判定結果を使って自社の顧客台帳を一意に統合する業務を指します。判定して終わりが前者、統合まで含むのが後者と考えると整理できます。

傾向スコアマッチングもデータマッチング技術に含まれますか？

含まれません。傾向スコアとは何か？その概念と基本的な考え方で扱っているとおり、傾向スコアマッチングは施策の効果を測るために属性の似た対象群と対照群を組む統計的因果推論の手法で、レコードの同定を目的とする本記事の系統とは別物です。名称が似ているだけなので、要件定義の段階で用語の指す内容を確認してください。

あいまい検索とベクトル類似検索は何が違いますか？

照合している対象が違います。あいまい検索は編集距離やn-gramで文字列の見た目の近さを測るため、打ち間違いや送り仮名の揺れに強い一方、表記が全く違う同義語は拾えません。ベクトル類似検索は意味の近さを測るため同義語を拾えますが、型番のように一字違うと別物になる文字列では誤って近いと判定します。名寄せの前処理には前者、レコメンドには後者が向きます。

ベクトル検索とキーワード検索は併用できますか？

併用できます。表記が完全一致する固有名詞や型番はキーワード検索が強く、言い換えや意味の近さはベクトル検索が強いため、両方の結果を順位で統合する構成が一般的です。統合方法としては Reciprocal Rank Fusion（RRF）が広く使われ、順位に定数を足した値の逆数を各検索結果について合算して並べ替えます。実装はハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードにあります。

マッチングアプリの画像検索は何で実装しますか？

画像を埋め込みモデルでベクトル化し、近似最近傍探索で近いものを返す構成です。ただしプロフィール写真を対象にする場合、本人の同意なく顔特徴量を検索キーにすると個人情報の取扱いとして問題になります。実装可否は技術ではなく、取得時の同意範囲と利用目的の記載で決まります。

関連記事

• ベクトル検索とセマンティック検索の違い｜包含関係・仕組み・使い分けを実装目線で整理
• コサイン類似度とは？計算式・仕組みと類似検索での実装を実装目線で解説
• ベクトル化とインデックス構造から理解するベクトルデータベースの仕組み
• マッチングサイト・求人ポータルの構築とは？開発手法・費用・必須機能と、法規制の壁を解説
• CDP（カスタマーデータプラットフォーム）とは？仕組み・DMP/CRMとの違い・導入ステップを解説