人材派遣の会社が契約・稼働・派遣先の記録から、翌月に派遣先の都合で更新されない契約を Python で予測し、派遣先への訪問と次の仕事の準備の順番を決める

処理の起点を決める

毎月の第1営業日の朝に1回動かします。 対象は、その月の翌月から翌々月の初めまでに満了する契約です。翌月の初めに満了する契約は、その日の時点で満了まで30日ほどしかなく、訪問しても間に合わないことが多いため、上の一覧には載せつつ印を変えます。 主に見るのは、満了まで5〜9週ほどある契約です。

動かすのは、基幹システムの月の締めのあとです。 前の月の勤怠と請求が締まっていないと、直近の残業や人数の推移が欠けて出ます。締めの日が遅れた月は、締めのあとにずらして動かします。 締まる前の記録で作った一覧には、表の上に「勤怠の締め前」と印字します。

モデルの作り直しは3か月に1回にします。 派遣先の都合の終了は月に数十件なので、毎月作り直すと当たり方が揺れます。作り直す前と後で直近3か月の当たり方を比べ、悪くなっていれば前のモデルのまま使います。

入力データを集める

質を決めるのは、いちばん下から2つ目の「終わった理由の区分」です。 これが無いと、派遣先の都合と本人の都合を分けられません。多くの会社では、終わった理由は営業日報の自由な文にしか残っていません。 導入の最初の仕事は、過去2年分の終わった契約に区分を付け直すことです（第14章）。

営業日報は、自由な文をそのまま使いません。 訪問のたびに、決まった区分（担当者の交代、業務量の話、苦情、単価の話）に印を付ける欄を足し、印の数を項目にします。 文の言い回しは営業ごとに違い、そのまま使うと書き方の癖を学習します。

スタッフの年齢、性別、国籍、家族の事情は入力に入れません。 予測しているのは派遣先の都合の終了で、スタッフの属性は要らないうえに、使えば属性で扱いを分けることにつながります。

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

書き出しの様式は最初に固定し、読み込むときは列の名前で選びます。 帳票の列の並びは画面で変えられることが多いためです。

すべての記録は「いつの時点で分かっていたか」を持たせて保存します。 勤怠は後から直されることがあり、更新の管理表の回答は日々書き換わります。月ごとの書き出しをそのまま残し、学習のときは各月の書き出しを使います。 最新の台帳で過去を作り直すと、後から分かったことが過去の項目に入ります。

AIへ渡す前に整形する

1. 答えを付ける … 過去の契約ごとに、満了の時点で「派遣先の都合で終わった」を1、「更新された」を0とします。本人の都合と直接雇用への切り替えで終わった契約は、学習から外します
2. 基準の日をそろえる … 各契約について、満了日の5〜9週前に当たる月の第1営業日を基準の日とし、その日までに分かっていた記録だけで項目を作ります
3. 推移の項目を作る … 直近3か月の残業の平均と、その前の3か月との比、同じ部署の派遣の人数の3か月前との差、派遣先全体の請求の時間の前年同月との比
4. 契約の項目を作る … 更新の回数、契約期間の長さ、抵触日までの月数、満了の月が派遣先の決算の月か、職種、派遣先の業種
5. 訪問と依頼の項目を作る … 最後の訪問からの日数、直近3か月の区分ごとの印の数、直近3か月の新しい依頼と取り消しの数
6. 区分を Categorical にする … 職種、派遣先の業種、満了の月を pandas の Categorical の型にします
7. 期間で分ける … 古い順に学習・較正・確かめの3つに分けます。混ぜて分けません

1番目で本人の都合を外すのは、答えの意味をはっきりさせるためです。 本人の都合の終了を0に入れると、「本人が辞めた契約は派遣先の都合では終わらなかった」と教えることになり、本人が辞めそうな契約ほど確率が低く出ます。 本人の都合は UC-1407 のような別の見込みで扱います。

2番目がいちばん大事な前処理です。 満了の直前の記録には、派遣先がすでに終わりを告げたあとの動きが入ります。派遣先が交代の依頼を取り消した、更新の管理表に「先方検討中」と入った、といった記録を項目に入れると、当たり方は良く見えますが、使う時点では手に入りません。 基準の日より後の記録は使いません。

AIに処理させる

させるのは、契約ごとに「派遣先の都合で更新されない」確率を出すことだけです。 機械学習のモデルを1本作り、その確率を較正します。

目立つ変化は、モデルの判断の理由ではありません。 「同じ部署の人数が3か月で2人減った」「残業が前の3か月の半分以下」「最後の訪問から60日以上」のような、決まった規則に当たった記録を書き出すだけです。営業が派遣先を訪ねたときに、何を聞くかの手がかりにします。モデルがなぜその確率を出したかの説明として使わないでください。

30％と15％の線は、 営業が月に訪ねられる数と釣り合うよう、課長と営業が最初の3か月で決めます。

2行目は、とくに気を付けてください。 厚生労働省の告示では、3回以上更新した、または雇入れから1年を超えて続けて働いている人の有期労働契約を更新しないときは、少なくとも満了の日の30日前までに予告するとされています。予告は会社としての判断で行うもので、確率が高いことを理由に予告を出すものではありません。 派遣先の都合の終了が決まったら、予告の要否と時期を、契約の更新の回数と勤続から担当が確かめます。

指示内容を固定する

生成AIを使わないので、プロンプトはありません。 かわりに、学習と較正の中身を示します。

from sklearn.ensemble import HistGradientBoostingClassifier
from sklearn.calibration import CalibratedClassifierCV
from sklearn.frozen import FrozenEstimator

FEATURES = ["renewal_count", "term_months", "months_to_conflict_site",
            "months_to_conflict_person", "is_client_fiscal_month",
            "job_type", "client_industry",
            "ot_recent3_mean", "ot_ratio_prev3", "dept_headcount_diff3",
            "client_hours_yoy", "days_since_visit", "visit_flag_staff_change",
            "visit_flag_workload", "new_orders3", "cancel_orders3"]
# job_type・client_industry は pandas の Categorical にしておく

# 期間で3つに分ける（古い順に 学習 / 較正 / 確かめ）
train = df[df["base_date"] <  "2025-10-01"]
calib = df[(df["base_date"] >= "2025-10-01") & (df["base_date"] < "2026-04-01")]
test  = df[df["base_date"] >= "2026-04-01"]

base = HistGradientBoostingClassifier(
    max_iter=500, learning_rate=0.05, class_weight="balanced",
    early_stopping=True, validation_fraction=0.15, random_state=0)
base.fit(train[FEATURES], train["client_end"])

cal = CalibratedClassifierCV(FrozenEstimator(base), method="sigmoid")
cal.fit(calib[FEATURES], calib["client_end"])

test = test.assign(p=cal.predict_proba(test[FEATURES])[:, 1])

class_weight="balanced" を使うのは、派遣先の都合の終了が少ないからです。 600件のうち数十件しか無い答えをそのまま学習すると、ほとんどの契約に低い確率を出すモデルになります。「balanced」はクラスの数に反比例する重みを付けるとされています。そのかわり生の確率は実際より高く出るので、較正で数字どおりの割合に戻します。

較正の方法に sigmoid を選んでいるのは、較正に使う件数が多くないからです。 公式のページでは、isotonic は較正のデータが1,000件をはるかに下回るときは過学習しやすいため勧めないとされ、大きく偏ったデータでは sigmoid のほうが向くことがあるとされています。6か月分の較正の期間でも、派遣先の都合の終了は数百件に届きません。

early_stopping を明示的に有効にしているのは、既定の 'auto' では学習の行が10,000を超えるときにしか有効にならないからです。 2年分の契約でも、本人の都合を外すと超えないことがあります。

確かめの期間では、月ごとに上位60件（営業12名が1人5件ずつ先に訪ねられる数）の当たりの割合を出し、営業がこれまで付けていた印と比べます。

出力形式を固定する

営業に渡すのは、次の一覧です。 営業ごとに自分の担当の契約だけを並べたものと、課全体のものの2つを作ります。

【2026年11月 第1営業日 作成（モデル作成 2026-10-01）／対象：12月〜1月初めに満了】
印 | 確率 | 契約番号 | 派遣先・部署 | 職種 | 満了日 | 更新回数 | 目立つ変化
赤 | 0.42 | K-20431 | 〇〇工業 第2製造課 | 製造補助 | 12/31 | 5 | 部署の人数 3か月で -3／残業 前3か月の0.4倍
赤 | 0.33 | K-19877 | △△物流 入荷センター | 軽作業 | 12/15 | 2 | 新しい依頼 3か月0件／最後の訪問から74日
橙 | 0.21 | K-20102 | □□商事 経理部 | 一般事務 | 1/5 | 7 | 満了の月が派遣先の決算の月／訪問で「担当者の交代」
－ | 0.06 | K-20518 | ◇◇電機 品質保証課 | 検査 | 12/31 | 3 | －

「更新回数」の列を並べているのは、予告の要否を確かめる手がかりにするためです。 3回以上更新した契約が派遣先の都合で終わると決まったときは、満了の30日前までの予告が要るかを担当が確かめます。 一覧が予告の要否を判断するわけではありません。

機械で読む用には、同じ内容を CSV でも残します。 列は、契約番号、基準の日、生の確率、較正した確率、印、目立つ変化の規則の番号、モデルの作成日です。翌々月に実際の結果と並べて当たり方を見るのは、この CSV です。

確率を較正した値で出すので、 営業は「0.42」を「このような契約が10件あれば4件ほど終わる」と読めます。目立つ変化が添えてあれば、「部署の人数が3か月で3人減った」から「来期の人員の計画は」と聞けます。

システムへ連携する

基幹システムには書き込みません。 確率を契約の台帳の欄に入れると、請求や勤怠の画面を見る他の担当者の目にも入り、スタッフへの接し方に影響しかねません。 一覧は営業課の中だけで使います。

営業ごとの一覧のフォルダは、担当の営業と課長だけが開けるようにします。 課全体の一覧は課長だけが見ます。

人が確認する

1. 作った日時とモデルの作成日を見る … 一覧の上の日付が当月の第1営業日であることを確かめます
2. 赤の契約の目立つ変化を確かめる … 自分が知っている派遣先の事情（期末の人員計画、新しい設備の導入）と合うかを見ます
3. 訪問の予定を入れる … 赤の契約は2週間以内に訪ねる予定を入れ、橙は次の定期の訪問で聞く項目に加えます
4. 訪問の結果を更新の管理表に入れる … 派遣先が話した見通しを、決まった区分で残します
5. 次の仕事の準備を始める … 赤の契約のスタッフの希望を聞き直し、次の候補を手元に用意します

2番目で確率が低すぎると思った契約は、営業の判断で赤に上げてかまいません。 上げた契約と理由は記録に残します。

目標は、600件をならして1件2分です。 印の無い契約は一覧で流し見るだけで、時間を使うのは赤と橙の契約の目立つ変化を確かめ、訪問の予定を入れるところです。

例外に対処する

4行目と6行目は、モデルが知りようのない契約です。 営業の耳のほうが早い場面に備え、営業が上げられる作りにしておきます。

記録を残す

• 実行の日時、使ったモデルの作成日、読み込んだ書き出しの月
• 契約ごとの生の確率、較正した確率、印、目立つ変化
• 営業が上げ下げした契約と、その理由
• 訪問の日付と、派遣先が話した見通し（決まった区分）
• 実際の結果（更新・派遣先の都合の終了・本人の都合の終了）と、派遣先が終わりを告げた日
• 月ごとの当たり方（上位60件の当たりの割合、終わった契約のうち上位60件に入った割合、較正した確率の帯ごとの実際の割合）

5つ目の「派遣先が終わりを告げた日」が、この構成の効き目を測る物差しです。 一覧を使う前と後で、告げられた日が満了の何日前だったかを比べます。早く分かるようになっていれば、スタッフの次の仕事を探す時間が増えたということです。

最後の行の「確率の帯ごとの実際の割合」で、較正が効いているかを見ます。 0.3〜0.4の帯の契約のうち、実際に終わったのが3〜4割なら較正は合っています。大きくずれていれば、較正の期間を新しくします。