顧客データの「同一人物判定」は、マーケティングや分析の土台ですが、実務ではかなりやっかいです。入力ミスや引っ越し、名寄せの失敗が重なると、1人のはずの顧客が別人に分かれたり、逆に複数人が1人にまとめられたりします。Hightouchはこの判定結果をLLMで採点できないかを試し、しかも安く速く回せるなら運用が楽になるのではないかと考えました。今回の記事は、その検証の話です。
Hightouchが扱っているのは、identity resolution、つまり複数の記録を「実在の同一人物」に結びつける処理です。たとえば、同じ人の購入履歴、住所、メールアドレス、会員記録が別々のテーブルに散らばっていても、それを1つの人物像にまとめられれば、顧客のLTVや施策の効果を正しく見られます。逆にここで間違えると、全体の分析が崩れます。特に厄介なのは over-merging で、これは本当は別人なのに1人にまとめてしまう誤りです。
問題は、実データには正解ラベルがないことです。名寄せ後の1件1件について「これは1人か、複数人か」を後から機械的に答えることはできないので、実務では人がサンプルを開いて目視確認します。ただ、この手作業は遅く、1時間に50 identity ほどしか見られません。しかも、珍しい誤りを正確に測るにはかなり多くのサンプルが必要です。そこでHightouchは、Jev と GPT-6 Luna のような、0〜1の confidence score を返す新しい decision model なら、人間の代わりに監査できるのではないかと考えました。
検証には、University of Washington の Institute for Health Metrics and Evaluation が作った pseudopeople を使い、架空の米国の町を再現して住民データを生成しました。そこに現実的なエラーを加え、1,000件の identity を作成しています。その半分は1人分のノイズ混じりの記録、残り半分は over-merge です。まずは素朴なプロンプトで、与えられた records が本当に同一人物のものかを判断させ、over-merged ならその根拠も書かせました。さらに、タイポ、文字の誤読、ニックネーム、日付の月日入れ替え、空欄、家族からの誤転記といった「1人でも起こりうる揺れ」を説明し、どんなズレなら別人と見なすべきかも補足しました。
結果を見ると、Claude Opus が99.0%、Gemini 3.1 Pro が98.3%、GPT-6 Sol が98.3%で、Jev と GPT-6 Luna もかなり健闘しました。最初の条件では Luna が97.3%、Jev が95.6%です。ただしコストは別世界で、前線級モデルが1,000 identities あたり $2.50〜$4.48 かかるのに対し、Luna は $0.10、Jev は $0.05 です。処理時間も前線級モデルは2秒前後かかる一方、Jev は0.15秒、Luna は0.17秒でした。
Hightouchはさらに confidence threshold を調整しました。Jev は50%ではなく60%、Luna は70%のほうがよく、少し精度が上がります。それでも前線級モデルとの差はまだ残ります。そこで次に、より難しいケースを増やしたテストへ進めています。記事の途中は省略されていますが、少なくともここまでで言えるのは、安いモデルは速いが、難問ではまだ前線級に届かない、ということです。一方で、Jev のようなモデルは「自分の不確実さを分かっている」傾向があり、そこに価値があると記事は示しています。
この記事で面白いのは、単純に「安いモデルでも十分でした」と言っていない点です。むしろ逆で、Jev 単体では前線級に届かないことを認めたうえで、Jev と Claude Opus を組み合わせると精度をほぼ保ったまま 4x 以上安くできる、と持ってきています。ここで重要なのは、安価なモデルを主役にして、難しいケースだけ高性能モデルに回す構成です。実運用では、この考え方のほうがずっと現実的だと思います。
理由はシンプルで、identity resolution の監査は「全部を高精度に見たい」仕事ではないからです。大量の記録のうち、本当に人間が注意すべきなのは危ないケースだけです。だから、まず安いモデルに広く判定させ、信頼度が低いものだけ Opus に流すのは筋が通っています。Hightouchの実験が示しているのは、LLMを人間の代替として丸ごと置く話ではなく、判定の振り分け役にする話です。この発想は、コスト削減だけでなく、レビュー対象を絞れるという意味でも強いと思います。
もうひとつ引っかかったのは、Jev と Luna の違いです。記事によると、Luna は素の精度では Jev より良いものの、難しいケースでは差が縮まり、Jev のほうが confidence の校正がうまい。要するに、Jev は間違えるときに「これは怪しい」と低い確信度を出しやすい。逆に Luna は誤りなのに高い自信を持つことが多い。これは地味ですが、運用ではかなり大きい差です。
なぜなら、監査で怖いのは、間違った答えそのものより「間違っているのに強く断言すること」だからです。人手レビューや後段の自動処理に渡すとき、過信したモデルはミスを隠します。Jev のように自分の不確実さをある程度見せるモデルなら、そこを人間や上位モデルが拾えます。精度が少し低くても、信頼度の出し方が良いほうが総合設計では勝つ場面がある。この記事はその典型を示していると思います。
Hightouch自身も触れている通り、最初のテストでは Luna がかなり強く見えたので、より難しいケースを足して差がつくかを見ようとしました。これは正直でよい姿勢です。ただ、それでもなお、ベンチマークは現場の全部ではありません。実際の顧客データは、単なるタイポや住所変更だけではなく、部署ごとに入力ルールが違ったり、国や業務システムをまたいで表記が崩れたり、そもそもデータの欠損パターンが偏っていたりします。そうした癖は、合成データでは拾いにくい。
だから、この結果を「LLMは名寄せ監査に使える」とそのまま一般化するのは危ないと思います。より正確には、「名寄せの品質チェックを完全自動化するにはまだ不安だが、補助判定としては十分有望」という位置づけでしょう。特に、初期導入時の検証や、運用中のサンプリング監査には向いていそうです。逆に、法務や請求に直結するような場面で、低コストモデルだけに任せ切るのはまだ早いはずです。
この記事を読んで感じるのは、LLMの価値が「最終答えを出すこと」から少しずつずれてきている、ということです。ここでLLMがやっているのは、顧客が何者かを断定することではなく、どのプロフィールが危険そうかを見分けることです。これは検索順位の評価、ログの異常検知、内容審査、テストケースの採点にもつながる発想です。全部をAIに決めさせるのではなく、AIに大量処理させて、人間や高性能モデルが本当に必要なところに集中する。
その意味で、Hightouchの実験はかなり実務的です。派手なデモではないけれど、コスト、速度、信頼度のバランスをどう取るかがはっきり見えます。AIの導入が進むほど、こういう「安い層」と「高い層」を組み合わせる設計が増えるのではないかと思います。単体の賢さより、どこで止めてどこで回すか。その設計力が、これからの実装の差になりそうです。
参考: LLM Judges for Identity Resolution at 4x Lower Cost | Hightouch
