顧客マスタの重複と表記ゆれを見つけて、名寄せの候補を出す

処理の起点を決める

トリガーは2つです。

1つ目は、新規レコードの登録時です。登録と同時に候補を出せると、担当者がその場で判断できます。

2つ目は、日次のバッチです。既存レコードどうしの重複を、夜間に洗い出します。85,000件の総当たりは現実的でないため、正規化した会社名の先頭数文字でブロック分けしてから比較します。

最初の一括クレンジングは、別に計画してください。 既存の85,000件を一度整理する作業は、日常の運用とは別のプロジェクトです。日常の運用が回るようになってから着手するほうが確実です。

入力データを集める

「名寄せの方針」が、この構成でもっとも重要な入力です。

支店・事業所を統合するかどうかは、事業の形によって答えが変わります。

この方針を決めずに始めると、出てきた候補を判断できません。 技術より先に決めてください。

データの取得方法を決める

法人番号の引き当て： 国税庁の法人番号システムには Web-API があります。REST方式で、法人番号を指定して基本3情報と変更履歴を取得する、期間を指定して差分情報を取得する、商号・名称から基本3情報を検索する、の3つの機能があります。

利用にはアプリケーションIDが必要です（発行に費用はかかりません）。 発行までに時間がかかるため、設計の初期に申請しておいてください。

商号での検索は、表記ゆれに弱い点に注意してください。正規化してから検索し、複数候補が返る場合は所在地で絞ります。 それでも1件に決まらないものは「法人番号なし」として扱います。

取引実績： 候補が同じ会社かを判断する材料になります。「同じ担当者名が両方のレコードに出ている」「同じドメインのメールアドレスが使われている」といった情報が決め手になります。

過去の判断履歴： 「この2件は別会社と判断済み」という記録があれば、再び候補として出す必要はありません。この履歴がないと、同じ判断を何度も求められます。

AIへ渡す前に整形する

1. 会社名の正規化 … 法人格の表記（(株)／㈱／株式会社）、全角と半角、スペース、括弧の種類、旧字体をそろえます。法人格の位置（前株・後株）も区別します
2. 住所の正規化 … 都道府県の有無、丁目・番地の表記（1-2-3／一丁目2番3号）、ビル名の有無をそろえます
3. 電話番号の正規化 … ハイフン、市外局番の括弧、国番号を除きます
4. ドメインの抽出 … メールアドレスからドメインを取り出します。フリーメールのドメインは除外します
5. ブロック分け … 正規化した会社名の先頭数文字、または電話番号の市外局番でグループを作り、その中だけで比較します。85,000件の総当たりは36億通りになるため、必ず必要です
6. 除外の適用 … 自社、テストレコード、退会済みを除きます

AIに処理させる

文字列の正規化と類似度の計算は、プログラムで行います。 編集距離、n-gramの一致率、読みの一致といった手法があり、しきい値で候補を絞るところまでは計算で決まります。LLMを使う理由がありません。

法人番号による突合も、プログラムで行います。 APIの結果が一致するかどうかは、比較するだけです。

LLMにさせること：

「同一である」と断定させないでください。 LLMが出すのは、同一とみなす根拠と、みなさない根拠の両方です。どちらを取るかは人が決めます。

統合を実行させないでください。 これは技術的な制約ではなく、設計上の決めごとです。統合は取り消せません。

指示内容を固定する

あなたは、顧客マスタの名寄せを支援する担当者です。
2つのレコードについて、同じ会社とみなす根拠と、みなさない根拠を並べてください。

【厳守事項】
- 同一かどうかを断定しないでください。
  「同一です」「統合してください」「別会社です」と書かないでください。
  根拠を両方向で並べるだけにしてください。
- あなたの知識にある企業情報を使わないでください。
  「この会社は〇〇業界の大手です」といった記述をしないでください。
  判断材料は、入力に含まれるレコードの内容と法人番号の照会結果だけです。
- 法人番号が両方のレコードで一致している場合は、
  その事実を evidence_same の先頭に置いてください。
  ただし、支店・事業所を分ける方針の場合、
  法人番号の一致は「同一法人」を意味しても「同一レコード」を意味しません。
  下記の名寄せ方針に従って relation_candidate を選んでください。
- 法人番号が引けなかった場合は、その理由（候補が複数、該当なし、
  個人事業主と思われる、海外法人と思われる）を no_corporate_number_reason に書いてください。
  推測で法人番号を補わないでください。
- 過去に「別会社」と判断された組み合わせの場合は、
  past_decision にその記録を転記し、新しい情報がある場合のみ指摘してください。
- 個人名（担当者名）は、同一性の判断材料として使ってよいですが、
  その人物についての記述をしないでください。

【名寄せ方針】
{merge_policy}

【レコードA】
{record_a}

【レコードB】
{record_b}

【法人番号の照会結果】
A: {corporate_number_a}
B: {corporate_number_b}

【属性の突合結果（プログラムによる計算）】
{attribute_match}

【過去の判断履歴】
{past_decisions}

「同一かどうかを断定しない」の1行が、この構成の安全装置です。 これを書かないと「同一と判断されます。統合を推奨します」と返り、担当者が根拠を見ずに統合してしまいます。統合は取り消せません。

「あなたの知識にある企業情報を使わないでください」も必ず入れてください。 有名企業については学習内容から答え、無名の企業については推測で答えます。どちらも根拠になりません。

出力形式を固定する

計算部分（プログラム）の出力：

{
  "pair_id": "",
  "record_a_id": "",
  "record_b_id": "",
  "corporate_number_a": "",
  "corporate_number_b": "",
  "corporate_number_match": "match | mismatch | one_missing | both_missing",
  "similarity": {
    "company_name": 0.0,
    "address": 0.0,
    "phone_exact": false,
    "domain_exact": false
  },
  "shared_attributes": [],
  "block_key": ""
}

LLM部分の出力：

{
  "pair_id": "",
  "evidence_same": [],
  "evidence_different": [],
  "relation_candidate": "merge | parent_child | separate | undetermined",
  "relation_basis": "",
  "no_corporate_number_reason": "",
  "past_decision": {
    "found": false,
    "decision": "",
    "decided_at": "",
    "reason": ""
  },
  "additional_info_needed": [],
  "confidence": "high | medium | low"
}

evidence_same と evidence_different を両方出させることに意味があります。 片方だけを見せると、担当者はその方向に引きずられます。「住所は一致するが、電話番号の市外局番が違う」という両論が並んでいれば、判断の質が上がります。

relation_candidate に parent_child を用意しているのは、「統合」と「別」の二択にしないためです。実務では、親子で持つのが正解であることが多くあります。

corporate_number_match の one_missing（片方だけ法人番号が引けた）は、片方が個人事業主・屋号・海外法人である可能性を示します。 自動で「別」と判断しないでください。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-16時点ではベータ機能として提供）。件数が多く後段が機械処理なので、利用できると安全です。

システムへ連携する

「名寄せID」を新しく持つ設計にしてください。 各システムの顧客IDはそのまま残し、横断の名寄せIDを別に付けます。 レコードを物理的に統合すると、商談・請求・契約の履歴が巻き込まれます。

統合が必要な場合も、統合前の状態を必ず記録してください。 どのレコードとどのレコードを、いつ、誰が、どの根拠で統合したかを残し、取り消せるようにします。

人が確認する

すべての候補を人が判断します。自動統合しません。

判断の重さは分けます。

「慎重判断」を軽く扱わないでください。 同名の別会社を統合すると、別の会社の担当者に他社の商談情報が見える状態になります。 これは情報漏えいです。

例外に対処する

記録を残す

• 名寄せ候補と、その根拠（evidence_same / evidence_different）
• 法人番号の照会結果（照会日時つき）
• 担当者の判断と、その理由
• 統合前の各レコードの状態
• 名寄せIDの付与履歴
• 過去に「別」と判断した組み合わせ

「統合前の状態」を残さないと、誤った統合を取り消せません。 これが、この構成でもっとも重要なログです。

「担当者の判断と理由」の蓄積が、次回の判断材料になります。 「この会社は事業所ごとに契約が分かれるので親子で持つ」といった判断が貯まれば、同じ判断を繰り返さずに済みます。

法人番号の照会日時を記録してください。 商号や所在地は変わります。いつ時点の情報で判断したかが分からないと、後から検証できません。