勤怠・評価・異動・面談の記録から退職の兆しがある社員を毎月見込み、上司の1on1で話す材料と理由の候補を人事に出す

処理の起点を決める

毎月第1営業日の22時に、定時で動かします。 勤怠は月末で締まり、第1営業日に前月分が確定します。人事の担当者が一覧を見るのは第2営業日の朝です。毎週回すことはしません。 1on1が月1回なので、それより細かく点数を出しても、上司が動ける回数は増えません。

書き出しの順番は、人事マスタ → 勤怠 → 人事評価 → 1on1の実施記録です。人事マスタを先にするのは、その月の在籍者と上司の対応を先に確定させるためです。4つのCSVがそろったことを確かめてから点数を出し、1つでも欠けていれば点数を出さずに止めます。 勤怠が欠けたまま出すと、全員の残業の変化が0になり、点数がそろって下がります。

モデルの学び直しは四半期に1回にします。 毎月学び直すと点数の目盛りが月ごとに動き、先月の0.4と今月の0.4が比べられなくなります。

入力データを集める

質を決めるのは、2行目の退職の区分です。 正解のラベルは「自己都合の退職」だけにします。定年や契約満了まで混ぜると、年齢と契約の種類だけで点数が決まるモデルになります。区分が付いていない過去の退職があれば、学習の前に人事部で付け直します。

休職の理由は、モデルにも生成AIにも渡しません。 休職の理由には病気のことが書かれていることがあり、慎重に扱うべき情報です。 6行目の別枠の印で休職中の社員を外し、休職の有無そのものも特徴量に入れません。

1on1の中身を残していないことは、この構成の前提です。 中身を読ませる設計にすると、部下は1on1で本音を話さなくなります。使うのは実施した日付だけです。

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

4つのシステムとも、画面からCSVを書き出す機能を使う想定です。APIを持つシステムならAPIで取りますが、最初は画面の書き出しで項目を確かめます。

年齢、性別、国籍、家族構成は特徴量に入れません。 入れると点数がそれらの属性で決まり、属性で人を見分ける一覧になります。 在籍の年数を区分にしているのも、年齢の代わりにならないよう幅を粗くするためです。偏りが出ていないかは、第13章のとおり属性ごとの上位の割合で後から確かめます。

特徴量は「直近」と「前年同期」を比べて作ります。 保守の仕事は季節で忙しさが変わり、夏や年度末に全員の残業が増えます。前の月と比べると、季節の波を変化と取り違えます。

正解のラベルは「その月末から6か月以内に自己都合で退職した」とします。 3か月にすると申し出の後の期間ばかりになり、12か月にすると記録の変化との結び付きが弱くなります。6か月は、上司が1on1で話す時間が残る長さとして決めます。 期間は人事部長と担当者で決め、変えたらモデルを学び直します。

AIへ渡す前に整形する

1. 社員IDのそろえ … 4つのシステムで社員IDの形式が違うことがあります。人事マスタを正として対応表を作ります
2. 月ごとの断面を作る … 過去3年の各月末について、在籍していた社員の特徴量とその後6か月の退職の有無を1行にします
3. 退職の申し出後の月を外す … 申し出から退職日までの月は、学習の行からも点数づけからも外します。申し出の後の記録を学ぶと、引き継ぎで残業が増えることを兆しと覚えます
4. 入社1年未満の扱い … 前年同期の記録が無いので、変化の特徴量を作れません。在籍の年数の区分だけで別に見るか、点数を出さずに別枠に入れます
5. 別枠の社員を外す … 休職中、短時間勤務、申し出済みの社員は点数の計算から外します
6. 値のそろえ … 割合、日数、年数と単位が違うので、標準化してからモデルに入れます。標準化の平均と標準偏差は学習のときの値を保存し、毎月の点数づけでも同じ値を使います

学習と検証は、時間の順で分けます。 過去3年のうち、最初の2年の断面で学習し、最後の1年の断面で検証します。ランダムに分けると、同じ社員の翌月の断面が学習と検証に分かれ、答えを見ながら学ぶことになります。 さらに、ラベルが6か月先を見ているので、学習に使う最後の断面と検証の最初の断面の間を6か月空けます。

3番目を飛ばすと、点数が当たっているように見えて役に立たないモデルになります。 申し出済みの社員は確実に辞めるので、検証の成績は上がります。しかしその社員は、人事がすでに知っている社員です。

AIに処理させる

この構成の「AI」は2段に分かれます。 点数を出すのは Python のロジスティック回帰で、生成AIは点数を出しません。生成AIにさせるのは、上司に渡す1on1の話題の案だけです。

生成AIに渡すのは、理由の上位3つ（事実の文）、部下の等級と在籍の年数の区分、最後の1on1からの日数だけです。氏名は渡さず、社員IDも仮の番号に置き換えます。

1行目がいちばん起きやすい失敗です。 「残業が前年同期の1.6倍」と渡すと、生成AIは「仕事量に不満を感じている可能性があります」と書きます。記録に無い理由を書いた話題の案は、上司の見方を1つに決めてしまいます。

指示内容を固定する

あなたは人事部で、上司が部下と行う月1回の1on1の準備を手伝う立場です。
渡された記録の事実だけを使って、上司に渡す「話題の案」を作ってください。
この案は人事の担当者が読んで直してから、上司に渡します。

【使ってよい情報】
- 記録から分かった事実（下の「事実」）
- 部下の等級と在籍の年数の区分
- 最後の1on1からの日数

【作るもの】
- 話題の案を3つまで。各話題は、上司が部下にたずねる問いかけ1文と、
  その話題を選んだ記録の事実（どの事実から作ったか）の組にする
- 1on1の時間の取り方の提案を1文（最後の1on1から日が空いている場合のみ）

【厳守事項】
- 退職の理由、不満、転職、家庭の事情、健康を推測して書かないでください。
  記録に書かれていないことは書かないでください。
- 「退職」「離職」「辞める」「リスク」「点数」「兆し」という言葉を使わないでください。
- 問いかけは、部下が答えを選べる開いた形にしてください。
  「〜で困っていませんか」のような決めつけの形にしないでください。
- 昇給、昇格、異動、手当を約束したり、ほのめかしたりしないでください。
- 健康、家族、私生活についての問いかけを作らないでください。
- 渡された情報が足りないときは、足りない項目名を missing_info に入れ、
  推測で補わないでください。

【事実】{reasons}
【等級・在籍の年数の区分】{grade}／{tenure_band}
【最後の1on1からの日数】{days_since_1on1}

「退職」「リスク」などの語を禁じるのは、上司に点数の存在を伝えないためです。 話題の案に「離職の兆しについて」と一言でも入れば、上司はその部下を辞めるおそれのある人として見ます。

問いかけを開いた形にするのは、部下が話したいことを話せるようにするためです。 「残業が多くて困っていませんか」は答えを「困っている／いない」に決めます。「この3か月の仕事の進み方はどうですか」なら、部下が話す入口になります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" を指定）で、この形に固定します。

{
  "pseudo_id": "E-0412",
  "month": "2026-10",
  "score": 0.27,
  "rank_in_hrbp": 4,
  "reasons": [
    { "feature": "overtime_ratio", "text": "直近3か月の残業が前年同期の1.6倍" },
    { "feature": "transfer_wait_months", "text": "異動の希望を出して12か月据え置き" },
    { "feature": "days_since_1on1", "text": "最後の1on1から74日" }
  ],
  "topics": [
    { "question": "", "based_on": "overtime_ratio" }
  ],
  "schedule_note": "",
  "missing_info": [],
  "hr_override": { "new_rank": null, "pass_to_manager": true, "note": "" }
}

score rank_in_hrbp reasons は Python が埋め、topics schedule_note missing_info は生成AIが埋めます。hr_override は人事の担当者が書きます。上司に渡すのは topics と schedule_note だけです。

1つ目の理由は、点数と話題の案を別の層に置けることです。 生成AIの出力に score を含めないので、生成AIが点数を書き換える経路がありません。 構造化出力では数値の範囲（minimum／maximum）や文字数の制約が使えないとされ、additionalProperties は false にする必要があります。話題の数と文字数の確認は、受け取った後に Python で行います。

2つ目は、人事の判断を記録できることです。 hr_override に順番の直しと、上司に渡したかどうかが残るので、どの理由のときに担当者が渡さなかったかを後から数えられます。

システムへ連携する

上司へ自動で送ることはしません。 話題の案をそのまま上司に送ると、どの部下が一覧の上位にいたかが上司に伝わります。どの上司に、どの部下について、どう伝えるかは担当者が決めます。

生成AIに回すのは、担当者ごとの上位10名までにします。 250名全員の案を作っても、担当者が上司と話せるのは毎月数名です。読まれない下書きは、社員の情報を外へ渡す回数を増やすだけです。

人が確認する

人事の担当者は、毎月、一覧の上位を必ず見ます。 点数の順番は提案で、確定するのは担当者です。

1. 上位10名の理由を読む … 自分の知っている事情（家族の転勤、資格の取得、本人からの相談）と照らします。合わないときは順番を直し、一言書きます
2. 一覧の下位も流し見る … 点数が低くても気になっている社員がいれば上げます。モデルは記録に残る変化しか見ません
3. 上司に伝えるかを決める … 伝える場合は話題の案を直し、点数と理由は伝えません
4. 1on1の後に結果を聞く … 異動や働き方の相談が要るかを決め、要るものを人事部長に上げます
5. 判断を記録する … 順番を直した理由と、上司に渡したかどうかを hr_override に書きます。一言でよいので、空欄にしません

3番目で伝えないと決めることも大事な判断です。 上司との関係そのものが理由に見える場合、上司経由で話すと逆効果になります。その場合は、担当者が本人と直接話す場を設けます。

目標は、上司1名をならして10分です。 上位の社員がいる上司には理由を読み話題の案を直すので数分以上、いない上司は一覧を流し見て終わります。

例外に対処する

下の2行は、人事の行事と組織の変更で起きる誤りです。 どちらも社員の側の変化ではないので、理由に出すと担当者が一覧を信用しなくなります。

6行目は、最初の数か月で必ず起きます。 1on1の実施記録は上司が自分で付ける表で、付け忘れが多いからです。同じ上司の部下全員が上位に並んだら、部下ではなく記録の付け方を疑います。

記録を残す

• 毎月の4つのCSVの元のファイルと、書き出した日時
• 作った特徴量の表と、そのとき使った標準化の平均・標準偏差とモデルの版
• 社員ごとの点数、理由の上位3つ、一覧での順番
• 生成AIに渡した内容と、返ってきた話題の案
• 人事の担当者が順番を直した記録と、上司に渡したかどうか（hr_override）
• 6か月後の在籍と退職の区分、点数の当たり外れ

2つ目でモデルの版を残すのは、四半期ごとに学び直すためです。 先月の一覧がどのモデルで作られたかが残っていないと、当たり外れの比較ができません。

5つ目の担当者の判断は、モデルを直す材料になります。 担当者が繰り返し順番を下げる理由（たとえば「残業の増加」が、資格の講習で一時的に増えたもの）が分かれば、特徴量の作り方を直します。 一覧と記録は人事部の中だけに置き、閲覧した人と日時も残します。