過去の応募者の中から新しい求人に合う人を洗い出し、再接触の優先度とスカウト文の下書きを作る

処理の起点を決める

起点は2つあります。1つは月次の入れ替え、もう1つは求人の承認です。

月次の入れ替えは、毎月初めの夜間に動かします。ATSから過去の応募者の一覧を書き出し、保存期限を過ぎた人、連絡不要を申し出た人、入社した人を OpenSearch のインデックスから消します。 新しく不合格・辞退・保留になった人はこのとき足します。検索を始める前に、検索してよい人だけが入っている状態を作ります。

求人の承認は、ATSで求人票が承認済みになったことを起点にします。新しく出た求人と、募集を再開した求人の両方が対象です。 毎月25件前後が承認され、そのたびに1件ずつ検索を回します。まとめて月末に回すことはしません。 承認から数日のうちに声をかけられる人がいれば、媒体に出す前に面接を組めるからです。

入力データを集める

質を決めるのは、下の3つです。 職務経歴は近さを決めますが、声をかけるかどうかは前回の結果と連絡の可否で決まります。

見送り理由は、自由記述ではなくコードで持たせます。 「経験年数不足」「必須技術の不足」「条件の不一致」「ポジション充足」のように、あとで求人の必須要件と突き合わせられる粒度にします。自由記述の評価コメントは、生成AIへは渡しません（第13章）。

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

ATSからの書き出しは、APIが使えればAPIで、使えなければCSVの定期書き出しで行います。 どちらが使えるかはATSの製品によって違い、この部分は利用環境に応じた個別実装になります。

インデックスは、職歴1件を1文書にします。 Titan Text Embeddings V2 は長い文書も受け取れますが、検索では段落や節などの論理的なまとまりに分けることが推奨されています。経歴を丸ごと1本にすると、10年前と直近の職歴が混ざります。

検索は、求人の要件1項目につき1回です。 「Kubernetesでの本番運用」「障害対応の一次受け」「チームの取りまとめ」は別々のベクトルにし、knn クエリで引きます。1件の求人で要件が8項目なら8回の検索を、_msearch で1回の要求にまとめます。 複数の検索をJSONで組み立て、1回の要求で送れるとされています。

k と size は両方指定します。 size を指定しないと、クエリ全体ではなくシャード（およびセグメント）ごとに k 件が返るとされています。k の上限は10,000です。

AIへ渡す前に整形する

1. 対象外の人を入れない … 保存期限を過ぎた人、連絡不要を申し出た人、利用目的に他の求人の案内を含まない人は、インデックスに入れません
2. 個人を特定する情報を外す … 氏名、連絡先、生年月日、顔写真、住所はインデックスにも生成AIにも渡しません。candidate_id だけで扱います
3. 収集すべきでない情報を落とす … 書類に本籍や出生地、思想・信条に関わる記載があれば、埋め込む前に除きます
4. 職歴ごとに分ける … 職務経歴書を会社・プロジェクトの単位で区切り、1件ずつ text にします
5. 技術名の表記をそろえる … 「k8s」と「Kubernetes」、「AWS」と「アマゾン ウェブ サービス」のように、社内の対応表で片方に寄せます
6. 求人票を要件ごとに分ける … 1項目1文にし、「〜の経験3年以上」のような年数は検索文から外して別に持ちます
7. 次元をそろえる … インデックスの dimension と埋め込みの出力を同じ1,024にします

3番目を軽く見ないでください。 選考に関係のない事項が埋め込みに入ると、その情報が似た人どうしが近くに並びます。

AIに処理させる

ベクトル検索が出すのは「近い職歴」までです。生成AIにさせるのは、その近さを人が確かめられる形に整理することです。

3行目が、この構成でいちばん大事な確認です。 2年前に「必須技術の不足」で見送った人が、今回もその技術を必須とする求人に上がってきたら、それは近いのではなく、前回と同じ書類を見ているだけです。 生成AIはこの重なりを conflict として書き出し、優先度は規則の側で下げます。

2行目がいちばん起きやすい失敗です。 経歴が2年前で止まっていても、「現在は〇〇社で活躍中の」と書きがちです。

指示内容を固定する

あなたは中途採用の担当者として、過去の応募者を新しい求人に照らして整理する立場です。
渡された職歴の本文と選考記録だけを見て書いてください。推測で補わないでください。

【求人の要件】{requirements}   … 必須／歓迎の区分と、要件ID付き
【検索で当たった職歴】{chunks}  … chunk_id、本文、類似度、職歴の終わった時期
【前回の選考結果】{previous}   … result、見送り理由のコード、応募日

【やること】
1. 要件ごとに、当たった職歴の中から根拠になる文をそのまま引用する
2. 必須要件を「根拠あり」「根拠なし」「読み取れない」に分ける
3. 前回の見送り理由のコードが、今回の必須要件に当たるかを書く
4. 応募日から今日までの月数を書く

【厳守事項】
- 根拠の文は、職歴の本文からそのまま写してください。言い換えないでください。
- 本文に書かれていない経験を、関連がありそうだという理由で補わないでください。
- 類似度が高いことを、要件を満たす根拠として扱わないでください。
- 現在の勤務先・役職・状況を推測して書かないでください。
- 合否の見込みや、採用すべきかどうかを書かないでください。
- 年齢、性別、国籍、家族構成に触れないでください。
- 見送り理由が今回の必須要件に当たる場合は conflict とし、理由を1文で書いてください。
- 見送り理由のコードが無い場合は unknown としてください。

【スカウト文の下書き（priority が A または B のときだけ）】
- 冒頭で、以前ご応募いただいたことへのお礼を書く
- 「ご応募いただいた当時の経歴を拝見し」と時点を明記する
- 根拠の職歴を1つだけ具体的に引く。求人票を貼り付けない
- 前回の選考結果や見送り理由には触れない

「類似度を根拠として扱わない」を明記しないと、類似度の数字をそのまま理由にします。 0.8と書かれた職歴を「要件を満たす」と言い換え、根拠の文を引かないまま A の候補ができあがります。 近さは検索の都合で、要件を満たすかは本文で決まります。

「前回の選考結果に触れない」は、下書きの側だけに書いています。 整理では見送り理由を読ませ、文面には出させません。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "job_id": "",
  "candidate_id": "",
  "matches": [
    { "requirement_id": "", "type": "must | nice",
      "status": "evidenced | not_found | unknown",
      "chunk_id": "", "quote": "", "similarity": 0 }
  ],
  "previous": {
    "result": "rejected | declined | on_hold",
    "reason_code": "",
    "reason_conflict": "none | conflict | unknown",
    "conflict_note": "",
    "months_since_applied": 0
  },
  "priority": "A | B | C | hold",
  "scout_draft": ""
}

1つ目の理由は、matches と priority を別の層に置けることです。 matches と previous は生成AIが埋め、priority はワークフローが規則で決めます。優先度の考え方が変わっても、直すのは規則だけです。

要は、辞退した人と不合格だった人を同じ扱いにしないことです。 辞退した人は自社が「来てほしい」と判断した人で、時期や条件が変われば、いちばん話が早い相手です。 12か月は例で、自社の運用で決めてください。

2つ目は、quote と chunk_id で確認が速くなることです。 quote が空の evidenced は、規則の側で unknown に落とします。

システムへ連携する

ATSへの書き戻しは、候補一覧の添付までにします。 選考のステータスをこの構成から変えると、過去の記録が再接触のたびに上書きされます。

埋め込みは、月次の入れ替えでまとめて呼びます。 Titan Text Embeddings はスループット重視のバッチでも提供されているとされます。Bedrock の埋め込みモデルはトークン数ではなく1分あたりの要求数で制限されるとされ、月初に全件を入れ直すときは先にこの上限を確かめます。

人が確認する

人が見るのは、A と B の全員と、hold の一覧です。 C は件数だけを見て、歓迎要件の当たりが多い人がいれば開きます。

1. hold を先に見る … conflict の人は、見送り理由と今回の要件の関係を記録で確かめます。面接官に一言聞けば解けることが多い項目です
2. A と B の根拠を確かめる … quote を読み、職務経歴書の該当箇所を開きます。類似度ではなく、本文で要件に当たるかを見ます
3. 声をかける人を決める … 1件の求人につき数名に絞ります
4. 下書きを直して送る … 送信は人が行います。時点の書き方と、前回の結果に触れていないかを最後に見ます
5. 判断を覆したら記録する … A を送らなかった理由、hold から送った理由を残します

2番目を省かないでください。 ベクトル検索は、同じ言葉が多く出てくる職歴を近いと判定しがちです。 「Kubernetes の勉強会に参加」と「Kubernetes で本番を3年運用」は、文としては近くに並びます。

目標は、1件の求人で60分です。 それより長い月は、要件の書き方が粗いか、見送り理由のコードが抜けています。

例外に対処する

3行目は仕組みの性質です。 OpenSearch Service の説明では、post_filter で2件が1件に減る例が示されています。「連絡不可」を検索のときに外すと候補が理由なく減るのも、対象外の人をインデックスに入れない理由です。

記録を残す

• 検索に使った求人の要件と、そのときの要件ID
• 要件ごとの検索結果（chunk_id、類似度、順位）
• 生成AIが返したJSONの全文（matches、previous、priority、scout_draft）
• そのとき検索の対象に入っていた人数と、月次の入れ替えで外した人数
• 人が判断を覆した記録 … A を送らなかった理由、hold から送った理由
• 送ったスカウト文の最終版と、返事の有無

4つ目を残すのは、保存期限を過ぎた人に送っていないことを示すためです。

ログにも保存期限を付けます。 検索結果のログには candidate_id と職歴の本文が残ります。応募者の保存期限を過ぎた人は、ログからも同じ時期に消します。 インデックスだけ消してログに残すと、消したことになりません。