中途採用の選考の記録と候補者とのやり取りから、内定を出した候補者が承諾するかを見込み、辞退のおそれが高い人と理由の候補を採用担当に示す

処理の起点を決める

毎朝7時に、回答を待っている候補者をまとめて見込みます。 内定を出した日から、承諾・辞退・取り下げのどれかが記録されるまで、毎朝見込み直します。採用担当が始業してすぐ一覧を見られる時刻にします。

内定を出したその日の午後にも、1回だけ動かします。 内定の通知のあとに候補者から返ってくる最初のメッセージには、「前向きに考えます」か「少しお時間をください」か、本音が出やすいからです。 翌朝まで待つと、他社との比較の連絡が先に入ることがあります。

回答の期限の2日前の朝は、確率に関わらず一覧の先頭に載せます。 期限が近い候補者は、確率が高くても最後の連絡を入れる時期です。確率の順と期限の順は別の列にして、両方で並べ替えられるようにします。

入力データを集める

使わない項目は、読み込む段階で外します。 採用管理システムには、年齢、性別、住所、家族の状況、健康にかかわる申告などが入っていることがあります。特徴量にしないだけでなく、Python の処理に読み込みません。 読み込んだものは、いつか誰かが特徴量に足します。

質を決めるのは、過去の結果の記録です。 辞退の理由が「一身上の都合」ばかりだと、どの理由の候補が当たっていたかを確かめられません。辞退した候補者に聞けた理由を、決まった選択肢で記録する運用を先に始めます。

紹介会社とのメールは、採用管理システムに取り込まれているものだけを使います。 担当者の個人のメールボックスにだけあるやり取りは、誰が読んでよいかの取り決めがないまま処理に入れません。

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

CSV は、使ってよい項目の表にある列だけを読みます。 表にない列が CSV に増えていても、読み込まずに処理を続け、増えた列の名前を担当者に知らせます。 採用管理システムの改修で、使わない項目の列が増えることがあるからです。

メッセージは、前回の処理より後のものだけを Claude API に渡します。 前回までの手がかりは保存しておき、新しいメッセージの分だけ足します。同じメッセージを毎朝渡すと、費用が日を追って膨らみます。

AIへ渡す前に整形する

1. 列の絞り込み … 使ってよい項目の表にある列だけを残します
2. 日数の特徴量 … 最終面接から内定までの日数、内定から回答の期限までの日数、日程の調整に返事が来るまでの時間の中央値を作ります
3. 年収の差 … 提示した年収と希望年収の差を、希望年収に対する割合にします
4. メッセージの整え … 署名、引用、定型のあいさつを落とし、送り手（候補者・紹介会社・自社）を付けます
5. 取り除く話題の確認 … 家族、健康、宗教などの語が含まれるメッセージは、該当する文を落としてから渡します
6. 時点の固定 … 学習のときは、内定を出してから回答の前日までの記録だけで特徴量を作ります

6番目を守らないと、評価がよく見えすぎます。 辞退した候補者は、回答の日に「他社に決めました」と書きます。この一文が特徴量に入ると、見込みは当たって見えますが、回答の前には存在しない情報です。 学習の行は、回答の前日の時点の記録で作ります。

5番目は、AIへの指示だけに頼らないための処理です。 指示で「拾わない」と書いても、渡した文は読まれます。渡す前に落とせるものは落とし、指示はその後ろの守りにします。

AIに処理させる

Claude API にさせるのは、メッセージから決まった種類の手がかりを取り出すことだけです。 確率の計算と理由の候補の順位付けは、Python の処理で行います。

確率を出すモデルが使う特徴量は、次のとおりです。

理由の候補は、係数と特徴量の値から並べます。 候補者ごとに「係数 ×（その人の値 － 過去の内定者の平均）」を特徴量ごとに出し、確率を下げる向きに大きいものから3つを、決めておいた日本語の表現に置き換えます。 理由の文をAIに作らせないので、根拠の無い理由が一覧に載りません。

2行目がいちばん起きやすい失敗です。 指示が緩いと、「返信が短く、熱意に欠ける印象」のような評価を書きます。評価は確率を動かさなくても、一覧に載れば読む人の見方を変えます。 取り出すのは書かれた事実の有無だけにします。

指示内容を固定する

あなたは採用グループの事務担当です。
内定を出した候補者と、その候補者を紹介した人材紹介会社とのメッセージを読み、
決まった種類の手がかりの有無だけを取り出してください。

【取り出す手がかり】
1. other_offer ... 他社の内定、最終面接、選考中への言及があるか
2. extension_request ... 回答の期限の延長を頼んでいるか。頼んだ日数
3. condition_questions ... 内定の条件への質問。salary / work_style / role / start_date から選ぶ
4. positive_action ... 入社の手続、書類、入社前の準備についての質問があるか
5. agent_note ... 紹介会社の担当が候補者の気持ちについて書いた一文（写すだけ）

【厳守事項】
- 書かれていることだけを答えてください。書かれていなければ false か空にしてください。
- 候補者の性格、意欲、熱意、人柄を評価しないでください。
  「返信が短い」「前向きに見える」のような印象を書かないでください。
- 家族、健康、宗教、思想、支持政党、出身地にかかわる内容が含まれていても、
  取り出さず、要約もせず、言及があったことも書かないでください。
- agent_note は原文の一文をそのまま写してください。言い換えないでください。
- 他社の社名は書かないでください。言及の有無と時期だけにしてください。
- evidence には、判断の根拠にした原文の一節を写してください。
  ただし上の取り出さない内容を含む一節は写さないでください。
- 辞退するかどうかを予想しないでください。

【候補者のメッセージ（前回より後のもの）】{messages}

「言及があったことも書かない」まで書くのは、有無だけでも情報になるからです。 「家族の事情に触れている：あり」という印が一覧に載れば、その印が働きかけや評価に使われるおそれがあります。 取り出さないものは、存在ごと出力から消します。

「他社の社名は書かない」のは、一覧の読み手を守るためです。 社名が載ると、競合への対抗の条件を考え始めます。この一覧の目的は働きかけの順番で、条件の競り合いではありません。

確率を出すモデルの側の設定は、次のとおりです。 こちらは生成AIへの指示ではなく、Python の処理の設定です。

【学習のデータ】
- 対象：過去24か月に内定を出し、承諾か辞退が記録された候補者
- 除く：内定の後に自社の都合で取り消した例、候補者が選考を取り下げた例
- 目的の変数：承諾=1、辞退=0
- 特徴量：回答の前日の時点の記録だけで作る

【モデル】
- LogisticRegression(l1_ratio=0, C=1.0)   ※ L2 の正則化
- 数値の特徴量は標準化してから入れる（係数を比べられるようにする）
- 評価：TimeSeriesSplit(n_splits=5)。内定の日の順に並べて分ける

【確率の確かめ方】
- 出した確率と実際の承諾の割合を、10の階級で比べる
- ずれが大きければ CalibratedClassifierCV(method="sigmoid") で較正する
  （件数が少ないので isotonic は使わない）

【理由の候補】
- 特徴量ごとに 係数 ×（標準化した値 − 0）を出す
- 確率を下げる向きの大きい順に3つ
- 決めておいた日本語の表現の一覧に置き換える。一覧にない特徴量は出さない

数値の特徴量を標準化するのは、理由の候補を比べるためです。 年収の差の割合と日数では単位が違い、標準化しないと、係数の大きさが単位の違いで決まってしまいます。

評価を内定の日の順に分けるのは、採用の市況が年によって変わるからです。 公式の説明では、TimeSeriesSplit は時間の順のデータで、未来のデータで学習して過去を評価することを避けるためのものとされています。ばらばらに分けると、翌年の辞退の傾向を学んだモデルで前年を評価することになります。

出力形式を固定する

Claude API からは、スキーマで決めた次の形で受け取ります。

{
  "candidate_id": "",
  "other_offer": { "mentioned": false, "timing": "" },
  "extension_request": { "requested": false, "days": 0 },
  "condition_questions": ["salary"],
  "positive_action": false,
  "agent_note": null,
  "evidence": [""]
}

一覧には、Python の処理が次の形で書き出します。

{
  "run_id": "",
  "as_of": "YYYY-MM-DD",
  "candidate_id": "",
  "job_family": "",
  "offer_date": "",
  "deadline": "",
  "p_accept": 0.0,
  "p_accept_prev": 0.0,
  "reasons": ["希望年収との差が大きい", "他社の選考に触れている", "期限の延長を頼まれた"],
  "flags": ["drop_since_yesterday", "deadline_in_2days"],
  "evidence_refs": [""]
}

1つ目の理由は、手がかりと確率を別の層に置けることです。 手がかりはAIが埋め、確率と理由の候補は Python の処理が決めます。手がかりの取り出しに誤りがあれば、evidence で原文に戻って確かめられます。

2つ目は、p_accept_prev で前の日との差が見えることです。 確率そのものより、下がったことのほうが働きかけのきっかけになります。 drop_since_yesterday は、前の日から10ポイント以上下がった候補者に付けます。

3つ目は、reasons が決まった表現だけになることです。 表現の一覧は人事部が決め、一覧にない言い回しは出てきません。

システムへ連携する

採用管理システムには書き込みません。 確率や理由の候補が候補者の記録に残ると、次に同じ候補者が応募したとき、あるいは入社した後に、誰かの目に触れます。 一覧は採用グループだけが見られる場所に置き、回答が出たら見込みの欄を閉じます。

面接官と配属先には一覧を見せません。 確率を知った面接官や配属先の部長が候補者と話すと、話し方が変わり、それ自体が回答に影響します。 働きかけを頼むときは、「この点の説明をお願いしたい」と、理由の候補を言い換えて伝えます。

人が確認する

人が見るのは、一覧の上位と、確率が下がった候補者です。

1. drop_since_yesterday を先に見る … 前の日から確率が下がった候補者。新しく届いたメッセージの evidence を読みます
2. 確率の低い順に上位を見る … 理由の候補が、記録とメッセージに照らして当たっているかを確かめます
3. 働きかけの手を決める … 現場の社員との面談、条件の説明のし直し、配属先からの連絡などから選びます
4. 条件の見直しが要りそうなら人事部長に上げる … 採用担当の判断で条件を変えません
5. 回答を記録する … 承諾か辞退かと、辞退なら聞けた理由を決まった選択肢で記録します

2番目で理由の候補が外れていたら、それを記録します。 「年収の差」と出たのに、実際は入社の時期が合わないことが気がかりだった、という具合です。外れの記録がたまると、特徴量に足すべき手がかりが分かります。

目標は、30件をならして1件10分です。 上位の数人は記録とメッセージを読み直すので20分ほど、それ以外は一覧で流し見て数分です。

例外に対処する

上から3行目は、紹介会社の経由の候補者の半分で起きます。 紹介会社の担当の一文が、候補者の本音にいちばん近いことが多いので、紹介会社とのメールを採用管理システムに取り込む運用が、この構成の精度を決めます。

記録を残す

• 処理を動かした日時、読み込んだ列の一覧、使ってよい項目の表の版
• Claude API に渡したメッセージの範囲と、返った手がかりの JSON
• モデルの版、係数、較正の結果、評価の成績
• 候補者ごとの確率、理由の候補、前の日との差
• 採用担当が理由の候補を外れと判断した記録
• 回答の結果と、聞けた辞退の理由

1つ目で「使ってよい項目の表の版」を残すのは、何を使って見込んだかを後から説明するためです。 候補者から自分の情報の扱いを問われたときに、その日にどの項目を使ったかを示せます。