データマッチング技術とは？名寄せ・類似検索の3系統とツールの選び方

データマッチング技術は、2つ以上のデータの中から「同じものを指すレコード」または「近いレコード」を見つけ出す処理の総称です。顧客台帳の名寄せも商品レコメンドも同じ言葉で呼ばれますが、設計はまったく違い、共通キーで済む案件に埋め込みモデルを持ち込むといった取り違えはこのあいまいさから起きます。この記事では3系統の判定対象の違いから、Excel・連携製品・OSSのどれで実装するか、精度より先に確認すべき法務の前提までを扱います。なお、結婚相談所の「データマッチング型」は相手の紹介方式を指す別の用法で、本記事の対象ではありません（違いはよくある質問で触れます）。

まとめ：系統の選び分けと実装手段の決め方

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

実装手段は件数と判定の難しさで決まります。数万行までで共通キーがあるならExcelのXLOOKUPで足り、表記ゆれがあるならPower Queryのあいまい一致まで使えます。キーの無い顧客データを数十万件以上突き合わせるなら、確率モデルを実装したSplinkなどのOSSが現実的です。合成データ1,290件（真の重複290組）で試すと、完全一致で拾えた重複は正規化前0組・正規化後169組で、Splinkはそこへ100組を上積みして269組でした。

精度より先に潰す前提もあります。購入した外部データとの突合は個人情報保護法第31条の確認義務に触れる可能性があり、異性との交際を希望する人の情報を公開し、利用者どうしが連絡できる場を反復継続して提供するサービスは、インターネット異性紹介事業として届出が事業開始の条件になります。

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

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

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

会員番号、注文ID、法人番号のように両側の台帳が同じキーを持つなら、完全一致で突き合わせるのが正解です。処理はデータベースの結合1回で終わり、どのキーで一致したかを判定根拠としてそのまま説明できます。ただし、キー自体の入力誤りや重複がないかは別に点検が要ります。取引先の突合なら、国税庁の法人番号（13桁）は商号や所在地が変わっても番号が変わらないため、名寄せキーとして最も扱いやすい項目です。

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

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

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

この3群という出力形式が運用設計を決めます。機械が判定を放棄した保留群を人が目視する前提なので、目視できる件数までしきい値を寄せる設計になります。全件を自動判定させると誤統合が混ざり、顧客データでは請求先の取り違えとして表に出ます。統合後の顧客IDを基盤に載せる構成はBigQueryでCDPを構築する構成：ID統合・セグメント生成・広告連携と権限設計、統合したレコードを正として維持する運用はマスタ（マスターデータ）とは？トランザクションデータとの違いと管理・MDMの進め方で整理しています。

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

レコメンド、類似画像検索、マッチングアプリの相手推薦は、そもそも同一実体を探していません。「この人に近い人」「この商品に似た商品」という順位付けが目的で、正解が一意に決まらない点が上2系統と違います。データを埋め込みモデルで数値ベクトルに変換し、距離の近いものを返します。

評価も2段構えになります。正解を付けたクエリ集合があれば、類似検索もRecall@kやnDCGで検索品質をオフラインで測れます。ただしレコメンドのように正解が一意に決まらない用途では、事業への効果はクリック率や継続率など目的に合った指標で確かめる必要があります。オフライン評価だけで完成とせず、A/Bテストの枠を最初から確保してください。ベクトル化の仕組みはベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】で扱っています。

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

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

モデルを組む前に、表記ゆれをどこまで潰したかで到達できる精度の上限が決まります。日本語の顧客データで効く順に、全角と半角の統一、法人格の位置と表記（株式会社の前置と後置、カッコ株の展開）、住所の丁目・番地のハイフンと漢数字、氏名カナの濁点と長音、旧字体の異体字を揃えます。確率モデルにも編集距離などのあいまい比較はありますが、全角・半角や記号の違いのように規則で消せる差は先に消した方が、比較の重みが本来の一致・不一致を反映しやすくなります。

正規化を通すと、共通キーが一致するようになるレコードが一定数出ます。確率モデルへ移る前に、決定的マッチングで拾える範囲を使い切ってください。振込名義のカナと請求先を突き合わせる入金消込も同じ構造で、具体的な正規化ルールは入金消込の自動化を実装する｜全銀データ取込・振込名義の名寄せ・突合ロジック【2026年】にあります。

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

Fellegi-Sunter の枠組みが使われ続けている理由は、誤って一致とする確率と見逃す確率を先に指定でき、その誤差水準を満たす判定規則の中で保留群が最小になることを示した点にあります。誤一致率と見逃し率の目標を先に決め、項目ごとの一致確率（m確率・u確率）を推定すれば、保留群に入る件数を見積もれます。その際は「非一致ペアのうち誤って一致とする割合」のように、目標の分母まで定義しておく必要があります。

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

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

全ペアを比較すると計算量で破綻します。10万件の台帳を自己突合する組み合わせは約50億ペア（4,999,950,000）、10万件どうしの相互突合なら100億ペアです。そこで郵便番号、電話番号、氏名と生年の組といった粗いキーで候補を絞り、同じブロック内だけを比較します。

ブロッキングキーを厳しくすれば計算量は落ちますが、そのキー自体が誤入力・変更されたレコードは永久に比較されません。転居で郵便番号と電話番号が両方変わった顧客はどちらのブロックにも入らないため、複数のブロッキングキーで別々に候補を作り、結果を合わせるのが定石です。

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

名寄せの成果を「重複が何%減ったか」というマッチ率で報告させると、しきい値を緩めるほど数字が良く見えるため、誤統合を増やす方向に力が働きます。正解ラベルを付けた標本を用意し、適合率と再現率で測ってください。適合率は「一致と判定したペアのうち本当に同一だった割合」、再現率は「本当に同一のペアのうち一致と判定できた割合」です。たとえば真の重複100組に対して90組を一致と判定し、そのうち81組が正解なら、適合率は81÷90＝90%、再現率は81÷100＝81%になります。

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

Splink 5で名寄せを動かした結果：合成データ1,290件

上の条件が数字でどう効くかを、OSSの Splink 5.0.0（2026年9月28日公開）で確かめました。データは乱数で作った架空の顧客1,000人に、その約3割の重複290件を足した1,290件です。重複側には、郵便番号の全角化、電話番号のハイフン抜け、氏名の全角空白を入れ、さらに4割を転居（郵便番号と電話番号が両方変わる）、2割を生年月日の誤記にしました。実在の個人データは使っていません。データは次のコードで作れます（乱数の種を7に固定しているので、同じ1,290件が再現します）。

# 合成データ：1,000人＋3割の重複（全角数字・ハイフン抜け・氏名の空白・転居・生年月日の誤記）
import csv, random
random.seed(7)
sei = ["佐藤","鈴木","高橋","田中","伊藤","渡辺","山本","中村","小林","加藤","五十嵐","長谷川"]
mei = ["太郎","花子","一郎","美咲","翔","陽子","健","由美","大輔","彩"]
zen = str.maketrans("0123456789", "０１２３４５６７８９")
def person(i):
    return dict(cluster=i, name=random.choice(sei) + random.choice(mei),
                dob=f"19{random.randint(60,99)}-{random.randint(1,12):02d}-{random.randint(1,28):02d}",
                zip=f"{random.randint(100,199)}-{random.randint(0,9999):04d}",
                tel=f"090-{random.randint(0,9999):04d}-{random.randint(0,9999):04d}")
rows, uid = [], 0
for i in range(1000):
    p = person(i); rows.append(dict(unique_id=uid, **p)); uid += 1
    if random.random() < 0.3:
        q = dict(p)
        q["zip"] = q["zip"].translate(zen)
        q["tel"] = q["tel"].replace("-", "")
        q["name"] = q["name"][:len(q["name"]) - 2] + "　" + q["name"][-2:] if random.random() < 0.5 else q["name"]
        if random.random() < 0.4:            # 転居：郵便番号と電話番号が両方変わる
            n = person(i); q["zip"], q["tel"] = n["zip"], n["tel"]
        if random.random() < 0.2:            # 生年月日の誤記（日の1桁目）
            q["dob"] = q["dob"][:-1] + str((int(q["dob"][-1]) + 1) % 10)
        rows.append(dict(unique_id=uid, **q)); uid += 1
with open("customers.csv", "w", newline="") as f:
    w = csv.DictWriter(f, fieldnames=rows[0].keys()); w.writeheader(); w.writerows(rows)
print(len(rows))

出力される customers.csv の列は unique_id・cluster・name・dob・zip・tel で、dob は YYYY-MM-DD 形式です。cluster は同一人物に同じ番号を振った評価用の正解ラベルで、Splinkの判定には使いません。これを正規化してSplinkに渡すのが次のコードです。

import csv, re, unicodedata
import duckdb
import splink.comparison_library as cl
from splink import DuckDBAPI, Linker, SettingsCreator, block_on

def norm(s):  # 全角→半角（NFKC）と、ハイフン・空白の除去
    return re.sub(r"[-\s]", "", unicodedata.normalize("NFKC", s))

with open("customers.csv") as f, open("normalized.csv", "w", newline="") as g:
    rd = csv.DictReader(f)
    wr = csv.DictWriter(g, fieldnames=rd.fieldnames)
    wr.writeheader()
    for r in rd:
        for k in ("name", "zip", "tel"):
            r[k] = norm(r[k])
        wr.writerow(r)

con = duckdb.connect()
con.execute("CREATE TABLE customers AS SELECT * FROM read_csv('normalized.csv', all_varchar=true)")
db_api = DuckDBAPI(connection=con)
sdf = db_api.register("customers")          # Splink 5 は登録してから Linker に渡す

settings = SettingsCreator(
    link_type="dedupe_only",
    additional_columns_to_retain=["cluster"],  # 正解ラベル（評価用）
    blocking_rules_to_generate_predictions=[
        block_on("zip"), block_on("tel"), block_on("name", "substr(dob, 1, 4)"),
    ],
    comparisons=[
        cl.ExactMatch("name").configure(term_frequency_adjustments=True),
        cl.LevenshteinAtThresholds("dob", 1),
        cl.ExactMatch("zip"),
        cl.ExactMatch("tel"),
    ],
)
linker = Linker(sdf, settings)
linker.training.estimate_probability_two_random_records_match([block_on("name", "dob")], recall=0.7)
linker.training.estimate_u_using_random_sampling(max_pairs=1e6)
linker.training.estimate_parameters_using_expectation_maximisation(block_on("zip"))
linker.training.estimate_parameters_using_expectation_maximisation(block_on("dob"))

pairs = linker.inference.predict().as_record_list()
print("比較したペア", len(pairs))
for t in (0.9, 0.5):
    hit = [p for p in pairs if p["match_probability"] >= t]
    ok = sum(p["cluster_l"] == p["cluster_r"] for p in hit)
    print(f"しきい値{t}: 一致判定 {len(hit)} 組 / うち正解 {ok} 組")

動作確認はPython 3.12.13で、pip install splink==5.0.0（依存としてDuckDB 2.0.0が入ります）のあと、生成コード、正規化とSplinkのコードの順に実行しました。結果を同じデータの完全一致と並べます。

読み取れることは3つあります。1つ目に、正規化前は電話番号のハイフンの有無だけで完全一致が全滅し、正規化を入れると同じ完全一致が169組を拾いました。2つ目に、ブロッキングで比較ペアは全組み合わせの831,405組から466組まで減りました。3つ目に、Splinkが取りこぼした21組はすべて「転居で郵便番号と電話番号が変わり、生年月日も誤記」の組で、一致確率は0.209〜0.465でした。しきい値を0.5へ下げても21組は戻らず、同じ氏名で生年月日が1文字違いの別人が1組混ざっただけです。

この21組は正解ラベルを使って特定した見逃しで、正解の分からない本番では同じ方法で抽出できません。運用では一致確率の上限と下限を決めて保留群を作ります。今回のデータで0.9以上を自動統合、0.2以上0.9未満を目視とすると、目視は30組（うち正解21組）になり、見逃しは全件が目視に回ります。目視の件数を減らしたいなら、しきい値ではなく住所履歴やメールアドレスといった比較項目を足します。

実行すると、学習の途中では氏名・電話番号・生年月日の「その他（不一致）」レベルのm確率が観測されなかったという警告が出ます。最後の推論の時点でも生年月日の一部のm確率は未学習のままで、その部分は既定値が使われます。表の数字はその状態での結果です。また合成データは誤りの入り方が単純なので、適合率100%は実データの期待値になりません。実データでは同じ手順で数百組の正解ラベルを作り、表と同じ形で測ってから運用のしきい値を決めてください。

データマッチングソフトウェアの選び分け

データマッチングソフトウェアは、表計算の機能、データ連携製品のマッチング機能、名寄せ用のOSSや商用製品に分かれ、件数と共通キーの有無で選びます。

Excelでの突合：XLOOKUPとPower Queryのあいまい一致

共通キーがあり件数が数万行に収まるなら、Excelで足ります。XLOOKUP関数は一致モードの既定が0（完全一致）で、見つからない場合は#N/Aを返すので、フィルターで#N/Aの行を絞れば突合できなかった行の一覧になります。複数行に一致しても最初の1件しか返さないため、照合前にキー列の重複をCOUNTIFなどで確かめておきます。全角と半角が混ざる列は、照合前にASC関数で半角に揃えておきます。

表記ゆれがある列はPower Queryの「あいまい一致」を使います。Microsoftのドキュメントによれば、類似度はJaccard係数で測り、類似性のしきい値は0.00〜1.00で既定は0.80です。対象はテキスト列のマージに限られ、「Grapes」と「Raisins」のように文字が似ていない同義語は変換テーブル（From列とTo列の対応表）で指定します。ここで紹介した関数とPower Queryだけでは、項目ごとに重みを変える確率的な判定や保留群の管理までは完結しません。

データ連携製品のマッチング機能

ETL・データ連携製品が「マッチング」と呼ぶ機能の多くは決定的マッチングです。たとえば HULFT DataMagic のデータマッチングは、指定したマッチング条件に従って入力ファイルとマッチングファイルのレコードを結合する機能で、マッチングファイルは最大3階層まで指定できます。商品番号で商品名を引くような結合を定期実行するには向いていますが、表記ゆれの吸収は前段の変換処理で行う前提です。連携処理全体の設計はETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説で扱っています。

顧客や取引先の重複排除そのものを目的にした商用製品（MDM・データ品質製品）は、リアルタイムの重複検知や名寄せ結果の承認画面まで持っています。既製の機能で要件を満たせる範囲と、OSSで組む場合の追加開発の工数を比べて選びます。

名寄せ用OSSライブラリの比較

Pythonで使える主なOSSを、2026年10月26日時点のPyPIの最新版で並べます。

正解ラベルが無い状態から始めるならSplinkが第一候補です。EMアルゴリズムで重みを推定するため、ラベル付けは評価用の標本だけで済みます。Splink 5ではPython 3.10以上が必須になり、Amazon Athenaの対応が外れ、入力は db_api.register() で登録してから Linker に渡す形に変わりました。出力列の接頭辞も bf_ から mw_ に変わったため、Splink 4のコードはそのままでは動きません（Splink 4で保存したモデルのJSONは読み込めます）。単一マシンで回るかどうかは件数より比較ペア数と計算資源で決まり、Splink 5の公式発表では10億行・100億比較の推論を192 vCPUのEC2インスタンスで8.5分で処理しています。ブロッキング後の比較ペア数を見積もってから、DuckDBのままにするかSparkへ移すかを決めてください。

Zinggは社内で使う分には問題になりにくいものの、AGPL-3.0なので、改変して外部向けのサービスとして提供する設計なら法務確認を先に通してください。dedupeとrecordlinkageは最新版がそれぞれ2024年、2023年で止まっており、新規採用では更新状況を確認してからにします。

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

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

コサイン類似度とユークリッド距離のどちらを選ぶかは、埋め込みを正規化しているかどうかで答えが変わります。単位ベクトルどうしなら「距離の2乗＝2−2×内積」が成り立つため、内積・コサイン類似度・ユークリッド距離が返す順位は一致します。違いが出るのは計算の速さで、pgvectorのREADMEは長さ1に正規化したベクトルには内積を使うよう勧めています。正規化していない場合、内積はベクトルのノルム（長さ）に引きずられ、ノルムの大きいアイテムが上位に来やすくなります。Googleの推薦システムの解説は、学習データに頻繁に出てくる人気アイテムほどノルムが大きくなる傾向を挙げています。使う埋め込みモデルが正規化済みベクトルを返す仕様かを先に確認してください。計算式はコサイン類似度とは？計算式・仕組みと類似検索での実装を実装目線で解説で扱っています。

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

件数が増えると総当たりは現実的でなくなり、近似最近傍探索に切り替えます。近似探索は本来の上位k件をすべて返すことを保証しないため、返せた割合（再現率）を測って管理します。探索範囲を広げれば再現率は上がり、応答時間は伸びます。Google Researchが2020年7月28日に公開した ScaNN は、ann-benchmarksのglove-100-angularで調整済みの他11ライブラリを上回り、同じ精度で次点のおよそ2倍のクエリ毎秒を処理したと報告しています。

実務では再現率の目標値を業務側と握るところから始めます。後段で並べ替えるレコメンドの候補生成なら多少の取りこぼしを許容できますが、法令上の照合や重複検知に近似探索を使うなら、近似で許容できる要件なのかを先に疑ってください。

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

実際のマッチングは類似度だけでは決まりません。マッチングサービスなら年齢帯と居住地、求人なら勤務地と雇用形態を必ず併用します。近似探索で上位の候補を取ってから条件で削ると0件になることがあるため、フィルタと併用したときの挙動を基盤ごとに確かめてください。行動履歴のない新規ユーザーや新商品は、登録時の属性から暫定ベクトルを組み、履歴が溜まったら差し替えます。キーワード検索と組み合わせる方法はハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードで解説しています。

自前運用とマネージド基盤の境目

既にPostgreSQLを運用していて、ベクトルが数十万件規模にとどまり、既存テーブルの属性で絞り込みたいなら、専用基盤の前に拡張機能で足りるかを試します。属性条件とベクトル検索を同じSQLに書けますが、近似インデックスでは走査の後に絞り込みが掛かる点は変わりません。pgvectorのREADMEは、条件が全体の10%に一致する場合、HNSWの既定（hnsw.ef_search=40）では平均4行しか残らないと説明しており、0.8.0以降は反復インデックススキャン（hnsw.iterative_scan）で足りるまで走査を広げられます。導入手順はpgvectorとは？インストール手順（Windows・Ubuntu・Docker）と使い方【0.8.7対応】にまとめています。

マネージド基盤へ寄せるのは、ベクトル件数が数千万を超える、インデックス再構築を自分で持ちたくない、といった場合です。Googleの基盤は名前が二度変わっており、Vertex AI Matching Engine は2023年に Vector Search へ、Vertex AI 自体は2026年4月に Gemini Enterprise Agent Platform へ改称されました（現行のVector Searchのドキュメント）。SDKのクラス名にはMatching Engineの表記が残るため、名前だけで情報の新旧を判断しないでください。関係性そのものを辿る要件が混ざるなら、ベクトルデータベースとグラフデータベースの違い｜比較表・ナレッジグラフとの関係・3つのDBで実測【2026年版】も比較対象に入ります。

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

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

自社の顧客データに外部から購入したデータを突き合わせる構成は、個人情報の保護に関する法律第31条の対象になり得ます。同法第2条第7項は個人関連情報を「生存する個人に関する情報であって、個人情報、仮名加工情報及び匿名加工情報のいずれにも該当しないもの」と定義しており、Cookieで集めた閲覧履歴や属性情報が典型です。

条文の発動条件は「第三者が個人関連情報を個人データとして取得することが想定されるとき」です。照合できる可能性があるかではなく、提供先が自社の個人データに紐づけて扱うことが想定されるかで判断し、その場合、提供先が本人から同意を得ていること（提供元が同意の取得を代行する場合を含む）を、提供元があらかじめ確認しなければなりません。「渡す側は個人情報を渡していない」という説明は通らないため、データ購入から始まる企画では契約前にこの確認の手順を詰めてください。

広告配信向けにマッチング基盤を組む場合は、ブラウザ側の前提も変わり続けています。GoogleはChromeのサードパーティCookie一律廃止を撤回した後、Cookie代替のAPIも畳んでおり、Privacy Sandboxの公式ステータス表（2026年8月14日更新）ではTopics・Protected Audience・Attribution Reportingが「Deprecate and remove」です。ブラウザのAPIに依存せず、自社で同意を得て取得した会員データを軸にする設計が、この揺れの影響を最も受けにくい選択です。

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

面識のない異性との交際を希望する人の情報を公衆が閲覧できる状態に置き、利用者どうしが電子メール等で連絡できるようにするサービスを反復継続して提供する場合は、インターネット異性紹介事業に該当します。ビジネスマッチングや求人マッチングは含まれません。該当する場合は、事業を開始しようとする日の前日までに、事務所の所在地を管轄する警察署長を経由して都道府県公安委員会へ届け出る必要があります。利用者が児童でないことの確認方法も施行規則第5条で定められているため、年齢確認の設計は届出と同時に詰めてください。

マッチング事業そのものの構築論点は求人サイト・マッチングサイトの構築とは？開発手法・費用とIndeed連携、法規制を解説で扱っています。マッチングの判定ロジックを含めた実装のご相談はCtoCマッチングシステム開発で承っています。

よくある質問

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

名寄せはデータマッチングの一部です。データマッチングは複数のレコードが同じ実体を指すか（または近いか）を判定する処理全般を指し、名寄せはその判定結果を使って顧客台帳や取引先マスタを1件に統合する業務を指します。判定して終わりが前者、統合まで含むのが後者です。

結婚相談所の「データマッチング型」とは何が違いますか？

指しているものが違います。結婚相談所の「データマッチング型」は、仲人が相手を紹介する「仲人型」に対して、会員が登録した年齢・年収・居住地などの条件で検索・紹介を受ける方式の呼び名です。これは相手の探し方の名前で、内部でどんな照合技術を使うかは事業者ごとに異なり、条件検索だけでも成り立ちます。技術用語としてのデータマッチングは、名寄せや重複排除まで含むより広い言葉です。

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

本記事の3系統には含めていません。傾向スコアとは？マッチング・IPTWの使い分けとLove plot・SMDの読み方で扱っているとおり、傾向スコアマッチングは施策の効果を測るために属性の似た処置群と対照群を組む統計的因果推論の手法で、同一レコードを見つける名寄せとも、近い相手を推薦する類似検索とも目的が違います。

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

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

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

併用できます。固有名詞や型番の完全一致はキーワード検索が強く、言い換えや意味の近さはベクトル検索が強いため、両方の結果を順位で統合する構成が一般的です。統合にはReciprocal Rank Fusion（RRF）が広く使われ、各検索結果の順位に定数を足した値の逆数を合算して並べ替えます。両者の包含関係はベクトル検索とセマンティック検索の違い：目的と手段の関係・仕組みと日本語での実測で整理しています。

関連記事

• マスタ（マスターデータ）とは？トランザクションデータとの違いと管理・MDMの進め方
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説
• BigQueryでCDPを構築する構成：ID統合・セグメント生成・広告連携と権限設計
• ベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】
• 求人サイト・マッチングサイトの構築とは？開発手法・費用とIndeed連携、法規制を解説