人材派遣会社で、新しく登録したスタッフが就業につながるかを登録内容・希望条件・連絡への反応から見込み、コーディネーターが先に連絡する順番を毎週出す

処理の起点を決める

毎週月曜の朝6時に動かします。 コーディネーターが週の連絡の段取りを決めるのが月曜の朝なので、それより前に一覧ができていればよく、登録のたびに動かす必要はありません。

ただし、週の途中の登録者を1週間待たせないための仕組みを1つ足します。 木曜の朝6時にも同じ処理を動かし、月曜以降に登録した人だけの短い一覧を出します。登録から数日で連絡がつかなくなる人がいるため、ここは週1回にしません。

学び直しは月の第1月曜に、予測の前に行います。学習と予測を同じ日に回すことで、一覧のモデルの版と学習の日付が必ずそろいます。

入力データを集める

質を決めるのは、いちばん下の2つです。 返信までの時間と、電話に出たかどうかは、登録内容よりもずっと強く就業に効く、と現場のコーディネーターは感じています。それを確かめるのが、この構成で最初にやることです。

入れないものも先に決めます。 生年月日・年齢、性別、国籍、住所の番地、家族、健康の記載は特徴量に入れません。勤務地は「通勤圏の区分」まで丸めて使います。 精度のためにこれらを足すと、属性で連絡の順番が決まる仕組みになります。

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

派遣管理システムと配信サービスから、前の週の日曜までの記録を CSV で書き出し、共有フォルダに置きます。多くの派遣管理システムには書き出しの機能があり、定時の書き出しを設定できない場合は、月曜の朝に担当者が書き出す運用でも始められます。

予測の対象を「直近30日」に絞るのは、それより古い登録者には別の連絡のしかたが合うからです。 30日を過ぎて就業していない人は、月1回の近況確認のSMSに回し、この一覧には載せません。

学習の材料は、登録から45日を過ぎた人だけにします。 45日たっていない人は「まだ就業していない」だけで、就業しなかったと決まったわけではありません。 ここを混ぜると、最近の登録者がすべて「就業せず」として学ばれ、見込みが一様に低く出ます。

AIへ渡す前に整形する

1. 登録者の重複をまとめる … 同じ人が別の経路で登録し直していることがあります。電話番号とメールアドレスで照合し、古いほうの番号に寄せます
2. 受注との合い方を数える … 職種の区分が同じで、勤務地の区分が通勤圏に入り、時給が希望を下回らない受注を数えます
3. 反応の時間をそろえる … 初回のSMSから返信までの時間を時間単位にします。返信が無い人は、欠けたままにします
4. 区分の値を category 型にする … 登録経路、希望職種、通勤圏の区分
5. 時点をそろえる … 学習の材料では、特徴をすべて「登録から7日目の時点」で作ります
6. 配信停止の人を外す … 連絡を断った人は予測の対象にしません
7. 受注の時点もそろえる … 学習の材料の「合う受注の件数」は、登録7日目の時点で募集中だった受注で数えます

5番目がいちばん間違えやすいところです。 学習の材料を「いまの時点」の記録で作ると、就業した人には面談の記録や返信が必ずあり、就業の結果そのものを特徴として学んでしまいます。 評価では驚くほど当たり、実際の一覧ではまったく当たりません。

7番目も同じ問題の別の形です。 いま募集中の受注で過去の登録者の件数を数えると、その人が就業した仕事がすでに充足になっていて、就業した人ほど「合う受注が少ない」と出ます。 受注の募集開始日と充足日を使い、当時の一覧を作り直してから数えます。

3番目で返信の無い人を0時間にしないのも同じ考えです。 0時間は「すぐ返信した」と区別がつきません。LightGBM は欠けた値をそのまま扱えるので、埋めずに渡します。

AIに処理させる

させるのは、登録者ごとに「45日以内に初回就業する確率」を出すことと、その確率を押し上げた要因・下げた要因を寄与の大きい順に返すことだけです。

特徴は10個前後に抑えます。 増やすほど評価の数字は上がりやすくなりますが、コーディネーターが理由の文を読んで納得できる要因でなければ、一覧は使われません。 足すときは、入れ替えの記録に何度も出てくる要因から足します。

帯の分け方は規則で決めます。 モデルに帯を決めさせず、確率と登録からの日数から次のように決めます。

Aに「登録から3日以内で未接触」を入れているのは、まだ反応の記録が無い人を不利にしないためです。 登録した直後の人は返信の特徴が欠けているので、確率は控えめに出ます。最初の電話の前に、この人を後ろへ回すことはしません。

指示内容を固定する

この構成でAIに与える指示は、文章のプロンプトではなく学習・較正・予測の設定です。

import lightgbm as lgb
from sklearn.calibration import CalibratedClassifierCV
from sklearn.frozen import FrozenEstimator

FEATURES = [
    "matched_orders", "wage_gap_nearest", "days_to_available",
    "hours_to_first_reply",      # 返信が無ければ欠けたまま
    "missed_calls_d7", "interview_booked_d7",
    "profile_fill_rate", "channel", "job_category",   # 区分は category 型
    "past_assignments",
]
# 入れないもの：生年月日、年齢、性別、国籍、住所の番地、家族、健康

# 学習の材料：登録から45日を過ぎた人。特徴は登録7日目の時点で作る
hist = regs[regs["days_since_reg"] >= 45]
train = hist[hist["reg_month"] <= cutoff_train]          # 古い期間で学習
calib = hist[(hist["reg_month"] > cutoff_train) & (hist["reg_month"] <= cutoff_calib)]

model = lgb.LGBMClassifier(
    n_estimators=300, learning_rate=0.05, num_leaves=15,
    random_state=0,              # is_unbalance は使わない（確率が崩れる）
)
model.fit(train[FEATURES], train["placed_45d"], categorical_feature="auto")

# 較正は学習に使っていない期間で行う
cal = CalibratedClassifierCV(FrozenEstimator(model), method="sigmoid")
cal.fit(calib[FEATURES], calib["placed_45d"])

prob = cal.predict_proba(week[FEATURES])[:, 1]
contrib = model.predict(week[FEATURES], pred_contrib=True)   # 最後の列は期待値
up, down = split_reasons(contrib[:, :-1], FEATURES, k=3)

較正に sigmoid を選ぶのは、件数が少ないためです。 scikit-learn の説明では、較正に使う件数が1,000を大きく下回るときは isotonic は過学習しやすく推奨されないとされています。月600人の登録で、45日を過ぎた2か月分を較正に使っても1,000人前後です。

FrozenEstimator で包むのは、学習済みのモデルを較正のときに学び直させないためです。 この場合は渡したデータがすべて較正に使われ、学習と較正のデータが重ならないようにするのは使う側の責任とされています。上のコードで期間を分けているのはそのためです。

評価も期間で分けます。 直近の登録月を検証用に取っておき、「Aの帯に入った人のうち、45日以内に就業した割合」が全体の割合をどれだけ上回るかを見ます。正解率は見ません。帯の中の順番が当たっているかが、コーディネーターにとっての価値だからです。

出力形式を固定する

登録者1人ごとに、次の形で一覧に書き出します。

{
  "registrant_no": "",
  "branch": "",
  "registered_on": "2026-10-02",
  "prob_placed_45d": 0.0,
  "band": "A | B | C",
  "random_check": false,
  "reasons_up": [
    { "feature": "matched_orders", "value": 4, "text": "希望条件に合う募集中の仕事が 4 件ある" }
  ],
  "reasons_down": [
    { "feature": "missed_calls_d7", "value": 2, "text": "電話に 2 回出ていない" }
  ],
  "matched_order_nos": ["", ""],
  "model_version": "2026-10"
}

1つ目の理由は、reasons_down を出すことです。 下げた要因は、そのまま電話の話題になります。「電話に出ていない」ならSMSで時間を聞く、「合う仕事が0件」なら希望の勤務地を広げられるかを聞く。下げた要因が、何を話せばよいかを教えてくれます。

2つ目は、matched_order_nos で受注の番号を並べることです。 電話の前に紹介できる仕事を開けるので、第4章の②の見比べがここで終わります。

3つ目は、random_check を帯と別に持つことです。 抽出確認の人はCの帯のまま印が付き、コーディネーターは「なぜこの人に電話するのか」を区別できます。 学び直しの担当は、この印の人だけを使ってCの帯の当たり方を確かめます。

システムへ連携する

派遣管理システムへは書き込みません。 帯の印を登録者の画面に入れたくなりますが、入れた時点で、派遣先への紹介を決める画面にも見込みが見えるようになります。 一覧は、連絡の順番を決める人だけが開く場所に置きます。

書き出しのファイルは、日付を名前に入れて残します。 一覧のどの行がどの日の書き出しから作られたかを、後から追えるようにするためです。同じ名前で上書きすると、先週の一覧の根拠が消えます。

Teams には一覧そのものを貼りません。 チャネルには「今週の一覧ができた」ことと置き場所だけを投稿します。登録者の名前と見込みが並んだ表を、支店をまたいで見える場所に流さないためです。

人が確認する

一覧の順番は提案です。電話の順番を決めるのはコーディネーターです。

1. Aの帯の理由を読む … reasons_up に「合う仕事がある」が無いのにAに入っている人は、登録直後の未接触でAに入った人です。最初の電話で希望を聞き直します
2. 入れ替えたら一言残す … 順番を変えた理由（「本人から来週と言われた」など）を対応履歴に書きます
3. 抽出確認の人に電話する … 印の付いた人を後回しにしません。ここを省くと、翌月の学び直しが偏ります
4. 見込みの数字を登録者に伝えない … 電話の目的は仕事の紹介です

3番目を毎週守れるかで、この構成が半年後も使えるかが決まります。 忙しい週ほど、Cの帯の電話は真っ先に省かれます。抽出確認の人数は支店ごとに週数人に収まるように、1割という割合を決めています。

月に1回、主任が帯ごとの結果を見ます。 Aの帯の就業の割合が全体と変わらなくなっていたら、受注の傾向が変わったか、登録経路の構成が変わったかを確かめてから学び直します。

例外に対処する

4行目は、受注が少ない時期に起きます。 合う受注の件数が強い特徴なので、受注が減ると全員の確率が下がり、本来は電話すべき人までCに落ちます。 帯の境目を確率の値ではなく順位で決めているのは、このためでもあります。

6行目で前の週の一覧を使わないのは、古い一覧で電話すると、すでに就業した人に仕事を紹介してしまうからです。

記録を残す

• 毎週の一覧（登録者番号、確率、帯、理由、抽出確認の印、モデルの版）
• 予測に使った特徴量の表と、書き出しのファイルの日付
• 学習と較正に使った期間、件数、評価の結果（帯ごとの就業の割合）
• コーディネーターが順番を入れ替えた記録と理由
• 登録者ごとの、その後の就業の有無と開始日
• 特徴量から外した項目の一覧と、外した理由
• 抽出確認の印を付けた人と、実際に電話したかどうか

4つ目は、モデルの見直しの材料になります。 入れ替えの理由に同じ言葉が何度も出てくるなら（「夜しか電話に出ない」など）、それはまだ特徴量にしていない要因です。

最後から2行目は、抽出確認が守られているかを数えるために残します。 印を付けた人のうち電話した割合が下がっていれば、Cの帯の当たり方はもう確かめられていません。

外した項目の記録を残すのは、学び直しの担当が替わったときのためです。 「年齢を入れたら当たりがよくなった」という理由で項目が足されることを防ぎます。外した理由が書いてあれば、足す前に誰かが止められます。