求人ごとの職種・勤務地・年収・応募の推移から、採用決定までの日数を予測し、遅れそうな求人を早めに知らせる

処理の起点を決める

毎週日曜の夜22時に動かします。 月曜の朝の週次の会議に、一覧が間に合う時刻です。金曜の夕方以降に記録された推薦と選考の結果まで入るよう、週末の最後に書き出します。 祝日で会議が火曜に動く週も、実行の日時は変えません。毎週同じ曜日の時点で見込むほうが、先週との比べ方がそろいます。

モデルの学ばせ直しは、月に一度、別に動かします。 毎週の見込みは、その月に決めた版のモデルで出します。学ばせ直した版は、直近の3か月に決まった・取り下げた求人で前の版と比べ、良くなっていたときだけ切り替えます。 毎週学ばせ直すと、見込みが下がった理由が求人の変化なのかモデルの変化なのか分からなくなります。

入力データを集める

質を決めるのは、受注日・決定日・取り下げ日の3つです。 この3つがそろわないと、決まるまでの日数も、打ち切りの日数も作れません。取り下げ日が空のまま「募集中」になっている古い求人が混ざっていると、決まりにくい求人がいつまでも打ち切られずに残り、 見込みが長めにずれます。

希望の入社時期は、受注のときに日付で入れてもらいます。 「なるべく早く」のような書き方では、間に合うかを計算できません。決まっていない企業は「受注から90日」のような既定の値を置き、既定の値であることを印で残します。

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

求人管理の仕組みの帳票の機能で、求人・推薦・選考の記録を表の形で書き出します。API を持つ仕組みなら定時に取りに行き、持たないものは定時の書き出しを共有フォルダに置かせて読みます。 製品によって書き出せる項目が違うので、上の入力データの列がそろうかを最初に確かめます。

年収の中央値は、決まった求人だけから作ります。 募集中の求人の年収を混ぜると、決まりにくい条件の求人が相場を引き下げます。ただし、件数が10件に満たない職種・地域は大分類にまとめて出します。

AIへ渡す前に整形する

1. 状態をそろえる … 決定日があれば「決定」、取り下げ日があれば「取り下げ」、どちらも無ければ「募集中」にします。最終の更新から180日以上動きの無い募集中の求人は、担当者に状態を確かめる一覧に回し、確かめるまで学ばせる記録から外します
2. 日数を作る … 決定・取り下げは受注日からその日まで、募集中は受注日から書き出しの日までを日数にします
3. 時点ごとの記録を作る … 受注後14日・30日・60日・90日の時点ごとに、その時点でまだ決まっていなかった求人だけを集めます。日数は、その時点からの残りにします
4. 時点までの推移を特徴にする … その時点までの推薦の数、書類の通過の数と率、最初の面接までの日数、最後の推薦からの日数です。その時点より後の記録は使いません
5. 条件の特徴を足す … 年収の上限と職種・地域の中央値の差、必須の要件の数、勤務地の区分、企業の書類の返答の日数
6. 取り下げの理由を確かめる … 「他社で決定」で取り下げた求人は、決まらなかったのではなく別の経路で決まった求人です。決まりやすさの点では決定に近いので、割合を別に見ます

4番目で、その時点より後の記録を使わないでください。 受注後30日の時点の特徴に、40日目の面接の記録が入ると、決まった求人ほど面接が多いのは当たり前なので、モデルが当たりすぎて見えます。 本番では、その先の記録はまだありません。

3番目の時点ごとの記録は、例で見ると分かりやすくなります。 受注から45日目に決まった求人は、14日と30日の時点の記録には「残り31日で決定」「残り15日で決定」として入り、60日と90日の時点の記録には入りません。受注から100日経っていまも募集中の求人は、4つの時点すべてに「少なくとも残り86日・70日・40日・10日は決まらなかった」として入ります。 同じ求人が複数の時点に入りますが、時点ごとに別のモデルで学ばせるので重なりません。

6番目は、この構成の弱いところです。 「他社で決定」も「企業の都合」も、ここでは同じ打ち切りとして扱います。他社で決定の割合が多い職種は、見込みが長めに出ていると読み、その割合を一覧に並べて出します。

AIに処理させる

させるのは、募集中の求人ごとに、いまの経過を条件にした残りの日数の分布を見込むことだけです。 そこから中央値と、希望の時期までに決まる見込みを計算します。

左上の「当面決まりにくい」が、この構成で大事な区別です。 predict_median は、生存曲線が0.5を下回らないとき無限大を返します。 これを大きな数字としてそのまま一覧に出すと、意味の分からない「残り9999日」が並びます。無限大は「当面決まりにくい」という区分に置き換え、条件の見直しを相談する候補として先頭に並べます。

3行目を最初に決めておいてください。 見込みの低い求人を多く持つ担当者は、成績が悪いのではなく、決まりにくい求人を預かっているだけのことがあります。 一覧を評価に使うと、担当者が決まりにくい求人を受けなくなります。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、モデルの設定と印の規則を書いておきます。

【モデル】
- 時点ごと（受注後 14 / 30 / 60 / 90 日）に CoxPHFitter を1つずつ
- fit(df, duration_col="days_remaining", event_col="filled", strata=["job_family"])
- penalizer = 0.1（相関の強い特徴を安定させる。学ばせ直しのたびに見直す）
- 募集中の求人には、受注からの日数が過ぎた直近の時点のモデルを使う
- conditional_after = 受注からの日数 − その時点の日数

【見込み】
- 残りの日数の中央値 = predict_median（無限大は "hard_to_fill"）
- 希望の時期までに決まる見込み = 1 − S(希望の時期までの残りの日数)
- 要因 = 係数 × （その求人の値 − 学ばせた記録の平均）の小さい順に3つ

【印を付ける条件】
- late_risk：希望の時期までに決まる見込みが 0.4 未満、または hard_to_fill
- low_history：その職種の小分類で学ばせた求人が 30 未満
- drop：先週より、決まる見込みが 0.15 以上下がった
- 印の無い求人は一覧に出さない

conditional_after を渡し忘れるのが、いちばん起きやすい誤りです。 渡さないと、その時点に入ったばかりの求人として見込まれ、受注後50日の求人も30日の求人も、同じ30日のモデルで同じ見込みになります。 経過の日数の差が、見込みに出なくなります。

penalizer の値は、学ばせ直すたびに比べて決めます。 年収の上限と相場との差、必須の要件の数のように、互いに関係の強い特徴があると、係数が不安定になります。係数の向きが学ばせ直しのたびに入れ替わるなら、penalizer を強めるか、特徴を減らします。

出力形式を固定する

募集中の求人ごとに、次の形のJSONを作り、担当者ごとの一覧にします。

{
  "job_id": "",
  "owner": "",
  "days_open": 0,
  "landmark_model": "d14 | d30 | d60 | d90",
  "median_remaining_days": 0,
  "hard_to_fill": false,
  "target_date": "",
  "target_is_default": false,
  "prob_filled_by_target": 0.0,
  "prob_change_from_last_week": 0.0,
  "top_factors": [
    { "feature": "", "value": "", "direction": "lowers | raises" }
  ],
  "flags": ["late_risk | low_history | drop"],
  "model_version": ""
}

1つ目の理由は、prob_filled_by_target と median_remaining_days を並べて持てることです。 担当者が見たいのは「あと何日か」ですが、企業と話すときに要るのは「希望の時期に間に合う見込みはどれくらいか」です。同じ分布から出した2つを並べ、どちらで話すかを担当者が選べます。

2つ目は、top_factors で打ち手の手がかりを渡せることです。 例えば {"feature": "年収の上限と相場の差", "value": "−80万円", "direction": "lowers"} が並べば、相談の中身は年収の幅です。 書類の通過が無いことが並べば、必須の要件の見直しか、推薦する候補者の選び方の見直しです。

3つ目は、target_is_default で見込みの前提が分かることです。 希望の時期が既定の値の求人は、見込みが低くても急ぐ必要が無いことがあります。

システムへ連携する

担当者ごとの一覧は、印の重い順に並べます。 hard_to_fill、late_risk のうち希望の時期が近いもの、drop、low_history の順です。1人に届く件数が毎週十件を超えるなら、印の条件の値を見直します。 一覧が長いと、上から数件しか読まれなくなります。

一覧は、担当者本人と上長にだけ届けます。 部全体の会議の資料には、担当者ごとの件数ではなく、職種ごとの件数を出します。 第7章の「させないこと」の3行目と同じ理由です。

人が確認する

人が見るのは、印の付いた求人だけです。 印の無い求人は一覧に出ません。全件を毎週読む設計にすると、第10章の10.0時間には収まりません。

1. late_risk の hard_to_fill を先に見る … 当面決まりにくい求人です。企業に条件の見直しを相談するか、取り下げを含めて話すかを決めます
2. late_risk の残りを見る … 要因の上位3つを読み、打ち手の案を一行で書きます
3. drop を見る … 先週から見込みが下がった求人です。面接の辞退や書類の不通過が続いていないかを、選考の記録で確かめます
4. low_history を見る … 記録の少ない職種です。モデルの見込みより、似た求人を持った担当者の経験を聞きます
5. 見込みと違う判断をしたら記録する … 「見込みは低いが、来週面接が3件あるので待つ」のように理由を残します

4番目で、モデルの見込みを無理に使わないでください。 学ばせた求人が少ない職種では、見込みの幅が大きく、当たっているように見えても偶然のことがあります。

目標は、600件をならして1件1分です。 印が付くのは一部の求人という想定で、それより多い週は、希望の時期の既定の値が短すぎるか、相場の集計がずれています。

例外に対処する

上から2行目と3行目が、最初の数か月でいちばん起きます。 求人管理の仕組みに、状態の更新が漏れた古い求人が残っていることは珍しくありません。ここを片付けるだけで、見込みが長めにずれる原因の多くが消えます。

記録を残す

• 実行ごとに、書き出したファイルの名前と書き出し日時
• モデルの版（学ばせた期間、時点、特徴の列、penalizer、strata の列）
• 版ごとの成績（一致の指標（c-index）と、時点ごとの外れ方）
• 求人ごとの出力のJSON（prob_filled_by_target、top_factors、flags）
• 担当者が見込みと違う判断をした記録と、その後の結果
• 決定・取り下げになった求人の、各週の見込みの推移

成績は、打ち切りを考えた一致の指標で測ります。 lifelines は、生存時間の予測の順位が実際の順と合っているかを測る一致の指標（c-index）を持ち、打ち切りのある記録でも使えます。 学ばせた記録での値に加え、k_fold_cross_validation で記録を分け、学ばせていない側での値も見ます。

学ばせ直しのたびに、比例ハザードの仮定も確かめます。 CoxPHFitter には仮定に合わない列を知らせる check_assumptions() があり、合わない列が出たら、その列を strata に回すか、特徴の作り方を変えます。 確かめた結果も、版の記録に残します。

最後の行は、この構成の答え合わせです。 決まった求人について、受注後30日の時点での見込みと実際の日数を並べると、どの職種で見込みがずれているかが分かります。