新しい応募が届いたときに、過去の応募者と選考の記録を氏名の表記ゆれ・メールアドレス・電話番号・経歴で探し、重複応募と過去の選考結果を採用担当に示す

処理の起点を決める

採用管理の仕組みに応募が登録されたことを起点にします。 1件ずつ届いた順に検索し、応募の画面に候補を出してから担当が開くようにします。担当が開いた時点で候補が出ていないと、これまでどおり手で検索し始めます。

過去の記録の索引は、毎晩の書き出しで更新します。 当日の応募同士の重複（同じ日に2つの求人サイトから応募した人）は毎晩の更新を待てないので、当日の応募だけを入れる小さな索引を別に持ち、応募のたびに書き足します。 検索は2つの索引に同時にかけます。

入力データを集める

索引に入れないものを先に決めます。 面談の自由記述のメモ、就業先からの評価の文章、健康や家族に関する記述は入れません。選考の経緯は「段階」「結果の区分」「日付」「支店」の4つで足ります。 理由を知る必要があれば、担当が採用管理の仕組みで元の記録を開きます。

表記の対応表は、最初は小さく始めます。 検索に当たらなかったのに同じ人だった例が出るたびに、その揺れを1行ずつ足します。

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

検索は、ハイブリッドクエリ1本で行います。 中に入れる5つの問い合わせは次のとおりです。

あいまい検索は、1文字の置き換え・挿入・削除・隣り合う2文字の入れ替えを1回の編集として数えます。 既定の AUTO では、2文字までは完全一致、3〜5文字は1回、6文字以上は2回まで許します。カナ氏名は6文字を超えることが多いので、2回の揺れまで拾います。 別人まで当たりすぎる場合は、prefix_length で先頭の文字を固定します。

電話番号やメールアドレスの一致だけで返る候補は、1件だけのことが多くなります。 正規化プロセッサーの最小最大の方式では、問い合わせの結果が1件だけなら、その文書は1.0になります。 点数が高いことは「一致の根拠が強い」ことと同じではないので、区分は点数ではなく、次の照合で決めます。

filter で、索引の保存期間を過ぎた記録を除きます。 フィルターは5つの問い合わせすべてにかかります。

検索の要求は、おおむね次の形になります。 検索パイプラインの名前を付けて呼び、正規化の方式と問い合わせごとの重みはパイプラインの側に置きます。

POST /applicants,applicants_today/_search?search_pipeline=dup-pipeline
{
  "size": 10,
  "query": {
    "hybrid": {
      "queries": [
        { "term":  { "email_norm": "[email protected]" } },
        { "term":  { "phone_norm": "09012345678" } },
        { "fuzzy": { "kana_norm": { "value": "サトウタロウ", "fuzziness": "AUTO" } } },
        { "match": { "kanji_name": "佐藤 太郎" } },
        { "match": { "career_text": "株式会社〇〇物流 〇〇高等学校" } }
      ],
      "filter": { "range": { "retention_until": { "gte": "now/d" } } }
    }
  }
}

重みは、連絡先の2つを高く、経歴を低く置きます。 経歴の文字の一致は、同じ地域の同じ会社に勤めていた別人を多く拾うためです。重みを変えても区分の規則は変わらないので、画面に並ぶ順だけを見ながら調整できます。

AIへ渡す前に整形する

1. 文字の幅と形をそろえる … 半角カナを全角に、全角英数を半角に、互換の文字を正規化します
2. カナ氏名をそろえる … ひらがなをカタカナに、空白と中黒を除きます。読みが無い求人サイトの応募は、カナの問い合わせを外します
3. 漢字氏名をそろえる … 表記の対応表で異体字を代表の字に寄せた値を、元の値と別に持たせます
4. メールアドレスをそろえる … 前後の空白を除き、小文字にします
5. 電話番号をそろえる … ハイフン・空白・括弧を除き、国番号の付いた番号を国内の形に直します
6. 生年月日をそろえる … 西暦の年月日の形にします。無い応募は、照合の項目から外します
7. カナの読みの揺れを寄せる … 「ヂ」と「ジ」、「ヅ」と「ズ」、「ヴ」と「ブ」、長音の有無を、表記の対応表で寄せた値を別に持たせます
8. 経歴の文字をそろえる … 「株式会社」「（株）」の位置と有無を除き、会社名と学校名だけを並べます

7番目を足すのは、あいまい検索の揺れの回数を節約するためです。 「ヂ」と「ジ」の違いも1回の編集に数えられるので、読みの揺れが2か所ある氏名は、打ち間違いが1つ加わるだけで当たらなくなります。 決まった揺れは先に寄せ、あいまい検索は本当の打ち間違いに残します。

元の値は、必ず残します。 そろえた値は検索と照合のためのもので、採用担当の画面には元の値を並べます。 「齋藤」を「斉藤」に寄せた結果だけを見せると、別の人と同じ表記に見えてしまいます。

AIに処理させる

検索と区分は機械が行います。AIにさせるのは、候補ごとに「何が同じで何が違うか」と「過去にどうなったか」を、記録の番号を付けて短く書くことだけです。

2行目がいちばん大事な禁止です。 過去に面談を辞退した人を「意欲が低い」と書けば、今回の応募がその言葉で読まれます。 書くのは事実の時系列だけにします。

それでもAIに書かせるのは、候補が複数あるときの読み比べが重いからです。 同姓同名の候補が3件並ぶと、担当は項目の表を3つ見比べることになります。「この候補は電話番号と生年月日が一致し、姓だけが違う」と1行で書かれていれば、どの候補から開けばよいかがすぐ分かります。過去の経緯も、段階ごとの記録を時系列の数行にまとめるだけで、読む時間が変わります。

指示内容を固定する

あなたは人材派遣会社の登録センターで、新しい応募と、
過去の応募者の候補を見比べる材料を作る立場です。
渡すのは、新しい応募の項目、候補ごとの項目と照合の結果、
候補ごとの過去の選考の記録です。
そこに書かれたことだけを使ってください。

【書くこと】
1. 候補ごとに、一致した項目と値
2. 候補ごとに、違う項目と値
3. 違いについて考えられる事情を、「可能性」として1つまで
   （姓の変更、打ち間違い、連絡先の変更）
4. 過去の選考の経緯を、日付の古い順に、段階・結果の区分・支店で

【厳守事項】
- 同じ人である、別の人である、と結論を書かないでください。
- 過去の結果から、応募者の意欲・人柄・適性を評価しないでください。
  「辞退した」「就業を終えた」という事実だけを書いてください。
- 渡していない情報（理由、評価、メモ）を推測で補わないでください。
- 経緯の各行には、根拠にした記録の番号を付けてください。
- 年齢、性別、国籍、家族、健康に触れないでください。
- 候補が無い場合は、「候補なし」とだけ書いてください。

【新しい応募】{new_application}
【候補と照合の結果】{candidates}
【候補ごとの選考の記録】{history}

「評価しないでください」を書かないと、経緯の後ろに一言の見立てを付けます。 「辞退が2回あり、連絡がつきにくい可能性があります」のような文です。その一文は記録のどこにも無く、AIが作った評価です。

「年齢、性別、国籍…に触れない」は、生年月日を照合に使っているためです。 照合の材料に生年月日があると、要約の中で年齢に言い換えることがあります。

出力形式を固定する

区分と照合の結果はプログラムが作り、AIの出力はその隣に並べます。 Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "application_id": "",
  "candidates": [
    {
      "candidate_id": "",
      "class": "same_contact | likely_same | possible | no_match",
      "matched": [ { "field": "", "value": "" } ],
      "differed": [ { "field": "", "new": "", "past": "" } ],
      "possible_reason": "",
      "history": [
        { "date": "", "stage": "", "result": "", "branch": "", "record_id": "" }
      ]
    }
  ]
}

class はプログラムが入れ、AIには書き換えさせません。 区分の規則は次のとおりです。

history の record_id は、Python が渡した記録の番号と照らします。 渡していない番号や、日付が記録と違う行があれば、その候補の要約を出さずに照合の結果だけを見せます。

応募の画面には、たとえば次のように並べます。

【候補1】likely_same
  一致：カナの名（ハナコ）／漢字の名（花子）／生年月日／直近の勤務先
  違い：姓（過去：佐藤 → 今回：田中）／メールアドレス／電話番号
  可能性：姓の変更
  経緯：2023-04-10 応募（渋谷支店）R-208811
        2023-04-14 面談・登録（渋谷支店）R-208940
        2023-05-01〜2024-03-31 就業・就業終了（渋谷支店）R-209377
【候補2】possible
  一致：カナ氏名（揺れ1回）
  違い：生年月日／連絡先／経歴

理由の1つ目は、区分の規則を後から変えられることです。 規則を変えても、AIの出力をやり直さずに区分だけを付け直せます。 2つ目は、画面の並びを区分の順に固定できることです。

システムへ連携する

採用管理の仕組みへは書き込みません。 画面に候補を出すまでで、記録をつなぐ操作、支店への連絡、面談の案内は人が行います。

人が確認する

1. same_contact は元の値を並べて確かめる … 家族で同じメールアドレスや電話番号を使っていることがあります。氏名と生年月日の一致まで見ます
2. likely_same は違う点を読む … 姓だけが違う、連絡先が変わった、のどちらかが多くあります
3. 同じ人と決めたら、採用管理の仕組みで記録をつなぐ … どの候補とつないだかを記録します
4. 過去の担当の支店に知らせるかを決める … 就業中・就業を終えたばかりの人なら、その支店に知らせます
5. possible は、気になるときだけ開く … 同姓同名の別人が多く含まれます

1番目を省かないでください。 メールアドレスが同じでも、家族の別の人の応募のことがあります。氏名と生年月日まで一致して初めて、同じ人の候補として扱います。

4番目で知らせる先を支店に限るのは、経緯を知っているのが支店だからです。 登録センターから応募者に「以前こういうことがありましたね」と切り出すのではなく、過去の担当が経緯を踏まえて連絡するか、登録センターが初めての応募者と同じように案内するかを、支店と決めます。

目標は、1,200件をならして1件2分です。 no_match の応募は候補が無いことを確かめるだけで、時間は same_contact と likely_same の確認にかかります。

例外に対処する

3行目は、応募者から見て最も不快な形です。 同じ人に2つの支店から電話が来ると、どちらの連絡にも出てもらえなくなります。 当日の索引を作るのは、この1行のためです。

7行目で「未実施」と出すのは、「候補なし」と区別するためです。 検索が止まっていたのに候補なしと見えると、重複を見逃したまま面談を案内します。

記録を残す

• 応募の番号と、検索にかけたそろえた値
• 検索で返った候補と点数、照合の結果と区分
• AIが返したJSONと、記録の番号の照合の結果
• 人が同じ人と決めた記録（どの候補とつないだか）と、別人と決めた記録
• 検索が応答しなかった応募の一覧

区分ごとに、人が同じ人と決めた割合を毎月数えます。 same_contact で別人が多ければ家族の連絡先の共有、likely_same で別人が多ければ規則が緩すぎる、という見当がつきます。規則を直すかどうかは、この割合で決めます。

別人と決めた記録も残すのは、同じ組み合わせが繰り返し候補に出るためです。 一度別人と決めた2人は、次の応募で候補の順を下げるのに使えます。ログ自体も個人情報なので、採用管理の仕組みと同じ保存期間で消します。