派遣スタッフの勤怠とフォロー面談の記録から、翌月に就業の終了を申し出そうなスタッフを見込み、営業がフォローする順番を決める

処理の起点を決める

毎月15日の夜に、社内のサーバーで1回動かします。 更新の意向確認は翌月の契約の1か月前から始まるので、その前の週に一覧が担当者の手元にあるようにします。毎日動かす形にはしません。 毎日見込みが動くと、担当者は数字の上下に振り回されます。

処理は次の順に1本のプログラムで流します。途中で止まったら、そこまでの結果は一覧に出さず、担当者には「今月の一覧は遅れる」とだけ知らせます。 半分だけの一覧が出ると、載っていない人を「見込みが低い」と読まれるからです。

3番目だけが外部のAPIを呼ぶので、失敗したら3番目だけをやり直せるようにします。 タグ付けの結果はスタッフ番号と面談の日付ごとに保存し、前の月にタグを付けた記録は付け直しません。 毎月新しく増えた面談の記録だけを渡すので、2か月目からは呼び出しの量が減ります。

モデルの学習し直しは、3か月に1回です。 毎月の結果（実際に申し出があったか）がたまるのを待ち、四半期ごとに過去2年分で学び直します。学び直したモデルは、前のモデルと同じ過去の月で成績を比べ、良くなったときだけ入れ替えます。

入力データを集める

質を決めるのは、終了の区分です。 学習の答え（翌月に本人都合の終了を申し出たか）は、ここから作ります。区分が「その他」ばかりなら、まず過去2年分の終了の記録に区分を付け直すところから始めます。 付け直しは担当者の記憶に頼る部分があり、時間がかかります。

面談の記録は、体調や家庭の事情が書かれていることがあります。 これらは予測には使いません（前処理の4番）。

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

派遣管理システムから、スタッフ番号をキーにしたCSVを6種類書き出します。書き出しの画面か機能がシステムにあるかを先に確かめます。 無い場合は、システムの提供元に定期の書き出しを相談します。この部分は利用中のシステムに応じた個別の対応が要ります。

年齢は10歳刻みの区分だけにします。 生年月日そのものは予測に要りません。性別と国籍は書き出しません。 見込みの根拠に属性が入り込むと、属性で話す順番が決まることになるからです。

学習用のデータは、「その月の15日時点で分かっていたこと」だけで作ります。 たとえば2025年4月15日の行には、4月15日までの勤怠と面談の記録だけを入れ、答えは「5月中に本人都合の終了を申し出たか」にします。15日より後の記録を混ぜると、本番では手に入らない情報で学ぶことになり、成績が見かけだけ良くなります。

期間制限の判定は、組織単位での就業開始日から機械的に計算します。 労働者派遣法は、派遣元が同じ組織単位の業務に3年を超えて同じ派遣労働者を派遣してはならないと定めています（第35条の3。法令に定める例外を除く）。翌月中に3年に達するスタッフは、見込みの一覧から外して別の一覧へ回します。

AIへ渡す前に整形する

1. 対象者の絞り込み … 翌月に更新を迎える就業中のスタッフだけにします
2. 別の一覧への振り分け … 期間制限に当たる人、派遣先から終了の連絡があった人を外します
3. 勤怠の集計 … 直近1か月と、その前の3か月の平均を出し、差（増えたか減ったか）を特徴量にします。欠勤の絶対数より、増え方のほうが効きます
4. 面談の記録の下ごしらえ … 氏名・電話番号・派遣先の担当者名を記号に置き換えてから生成AIに渡します。体調・病気・家族の介護などの話題は、タグにしても予測には使いません
5. 就業期間の節目 … 就業開始から何か月目かを入れます。節目（3か月・6か月・1年）で申し出が増えるかは、自社のデータで確かめます
6. 答えの作成（学習時のみ） … 翌月中に本人都合の終了を申し出たら1、それ以外は0にします

前処理で作る特徴量は、最初は次の10個に絞ります。

職種を Categorical 型で渡すのは、HistGradientBoostingClassifier の categorical_features の既定値が "from_dtype" で、Categorical 型の列をカテゴリとして扱うからです。 数字の番号に置き換えると、職種の番号の大小に意味があるものとして学んでしまいます。

4番目の「予測に使わない」は、仕組みで守ります。 タグの一覧に health（体調）を持たせ、特徴量を作るプログラムで health を読まないようにします。体調の話題があったスタッフは、予測とは別に、コーディネーターが気にかける一覧に載せます。

AIに処理させる

生成AI（Claude API）にさせるのは、面談の記録を決まったタグに置き換え、根拠の一文を写すことだけです。

予測（scikit-learn）にさせるのは、特徴量から翌月の申し出の確率を出すことです。 出した確率に、どの手がかりが効いたかの候補を付けます。候補は、そのスタッフの特徴量のうち、過去の申し出者で多かった状態に当てはまるもの（欠勤が直近で増えた、overtime のタグがある、など）を規則で拾います。

1行目が、この構成でいちばん守るべきことです。 見込みの高いスタッフを更新しない側に回せば、困りごとを抱えた人ほど仕事を失います。一覧の冒頭に使い道を書き、営業部の取り決めとして文書にします。

指示内容を固定する

あなたは人材派遣会社のコーディネーターの補助として、
派遣スタッフとのフォロー面談の記録を読み、話題のタグを付ける役割です。
記録に書かれていることだけを根拠にしてください。推測で付けないでください。

【付けるタグ】
overtime（残業・業務量）／relationship（派遣先の人間関係）／
job_content（契約と違う業務・業務の内容）／commute（通勤）／
pay（時給・待遇）／next_job（他の仕事・次の仕事への言及）／
positive（仕事に満足している発言）／health（体調・病気・通院）／
family（家族の介護・育児など）

【厳守事項】
- タグごとに、根拠になった一文を記録からそのまま quote に写してください。
  言い換えたり、まとめたりしないでください。
- 記録に書かれていない気持ちを推測しないでください。
  「元気がなかった」とだけある場合、どのタグも付けないでください。
- 面談者の感想（「辞めそうな印象」など）は、スタッフの発言ではないので
  タグを付けず、interviewer_note に写してください。
- 1つの記録に当てはまるタグが無ければ、tags を空にしてください。
- 辞めそうかどうか、更新すべきかどうかは書かないでください。
- 氏名や派遣先名は記号に置き換えてあります。元に戻そうとしないでください。

【面談の記録】{interview_notes}

「面談者の感想はタグにしない」を入れているのは、面談者の印象が予測に入り込むのを防ぐためです。 「辞めそうな印象」と書く面談者と書かない面談者がいると、モデルは面談者の書き癖を学びます。 感想は別の欄に写し、予測には使いません。

出力形式を固定する

生成AIからは、次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に JSON スキーマ）を使います。

{
  "staff_id": "S-04821",
  "notes": [
    {
      "note_date": "2026-09-12",
      "tags": [
        { "tag": "overtime", "quote": "" }
      ],
      "interviewer_note": ""
    }
  ]
}

構造化出力を使う理由は、タグの名前が一覧の外に出ないようにするためです。 tag を列挙型にすると、overwork のような似た名前が混ざらず、特徴量を作るプログラムが読み落としません。 構造化出力ではオブジェクトの additionalProperties を false にする必要があり、数値や文字数の制約は使えないとされています。

予測の部分は、次のような流れのプログラムになります。 学習は過去の月で行い、成績は学習に使っていない後の月で測ります。

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

# 行＝「スタッフ×月」。各月15日時点の特徴量と、翌月の申し出の有無（y）
train = rows[rows.month < "2026-01"]      # 学習に使う月
test  = rows[rows.month >= "2026-01"]     # 成績を測る月（学習に使わない）

base = HistGradientBoostingClassifier(max_iter=300, learning_rate=0.05)
model = CalibratedClassifierCV(base, method="sigmoid", cv=5)
model.fit(train[FEATURES], train.y)

test["p"] = model.predict_proba(test[FEATURES])[:, 1]
# 月ごとに上位50人を取り、実際に申し出た人数を数える
hits = test.sort_values("p", ascending=False).groupby("month").head(50)
print(hits.groupby("month").y.sum())

較正の方法を sigmoid にしているのは、本人都合の申し出が月に数十件で、答えが1の行が少ないからです。 scikit-learn の解説では、isotonic は約1,000件を超えるデータで sigmoid と同等以上になる一方、小さいデータでは過学習しやすいとされています。申し出の件数が十分にたまったら、isotonic と比べます。

予測の結果は、担当者ごとに次の形の一覧（CSV）にします。

見込みの列に、確率の読み方を添えます。 数字だけを載せると、0.34を「低い」と読む人がいます。全体の申し出の割合が数％の中では、0.34はかなり高い値です。

システムへ連携する

派遣管理システムには書き込みません。 見込みの数字をスタッフの画面に載せると、営業以外の部署の人の目にも触れ、更新や紹介の判断に使われる経路ができます。 一覧は営業部の共有フォルダだけに置き、閲覧できる人を絞ります。

人が確認する

人が確かめるのは、一覧の上位と、別の一覧です。 600人を全員読む必要はありません。

1. 別の一覧を先に見る … 期間制限に当たる人には、雇用安定措置の手続きとして別に連絡します。体調・家族の話題があった人は、コーディネーターが気にかけます
2. 上位から根拠の候補を読む … 根拠が担当者の知っていることと合うかを見ます。合わなければ、担当者の判断で順番を下げてよい
3. 話す順番を決めて予定を入れる … 上位の30人前後を目安に、今週と来週に分けます
4. 話した結果を残す … 申し出があったか、困りごとは何かを記録します。次の学び直しの答えになります

4番目を省かないでください。 話した結果が残らないと、「話したから申し出が出なかった」のか「もともと出なかった」のかが分からず、モデルの成績を測れません。

目標は、600人をならして1人2分です。 上位の人は根拠を読んで数分、下位の人は一覧で流し見るだけです。

例外に対処する

5行目の照合は必ず入れます。 生成AIは、記録に無い文を「それらしく」写すことがあります。写した文がそのまま一覧に載ると、スタッフが言っていないことを担当者が信じることになります。

記録を残す

• 毎月の対象者の一覧と、使った特徴量の値
• 生成AIに渡した面談の記録（記号に置き換えた後）と、返ってきたJSON
• モデルの版と、出した見込み・根拠の候補
• 担当者が順番を入れ替えた記録と、話した結果
• 翌月に実際に申し出があったか（答え合わせ）
• 一覧を開いた人と日時

4つ目と5つ目は、モデルの成績を測るために残します。 毎月、上位50人のうち実際に申し出た人が何人いたかを数え、担当者の印の50人とも比べます。担当者が入れ替えた人の結果も見ると、モデルより担当者が正しかった場面が分かります。