団体保険の加入者名簿と人事の異動データを毎月突き合わせ、加入・脱退・変更の届け漏れを洗い出す

処理の起点を決める

保険会社・代理店から、その月の名簿が届いたことを起点にします。 名簿の届く日は契約ごとに違うので、3つの契約の名簿がそろった時点で、担当者が実行します。 毎月10日の朝に自動で動かし、そろっていない契約があればその契約だけを「名簿未着」として飛ばす形でも構いません。

人事システムの異動データは、その月の給与の締めの後に書き出します。 締めの前は、月末の退職や翌月1日付の入社がまだ入っていないことがあります。名簿と異動データの「いつ時点か」がずれると、正しい行まで差異として出ます。 実行の記録に、名簿の作成日と異動データの書き出し日を残します。

届け出の締切が近い月は、締切の5営業日前にもう一度動かします。 1回目で出た差異のうち、まだ届け出ていないものだけを洗い直すためです。

入力データを集める

質を決めるのは、下の3つです。 名簿と人事データは届いたものを読むだけですが、届け出の記録が無ければ pending が判定できず、対応表が無ければ毎月氏名で探し、加入資格の表が無ければ「載っているべきか」が決まりません。

加入資格の表は、契約書と事務の手引きを開いて人が作ります。 私傷病の休職の間も被保険者のままか、在籍出向の人はどちらの会社の契約に載るか、任意加入の保険は退職後も続けられるか。これらは契約ごとの取り決めで、AIに推測させるものではありません。 分からない項目は、代理店に問い合わせて埋めます。

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

名簿は、契約ごとの受け取りフォルダから読みます。シートの名前と列の並びが、保険会社によって違います。 契約ごとに「どの列が氏名のカナか」を書いた設定を持ち、読むときに列の名前をそろえます。列の並びが変わった月は、設定と合わずに止まるようにします。 黙って別の列を読むよりは、止まったほうが安全です。

在籍者の一覧は、異動データとは別に取ります。 異動データだけを見ると、異動の無かった人の名簿の誤りに気づけません。何年も前の退職者が名簿に残っている、という型は、在籍者の一覧と名簿を全件で突き合わせて初めて出ます。

AIへ渡す前に整形する

1. 表記をそろえる … 名簿と人事データの氏名のカナに unicodedata.normalize("NFKC", ...) をかけ、空白を取り除きます。半角のカナが全角になります
2. 小書きの文字と長音をそろえる … 「ァ」と「ア」、「ー」と「－」の扱いを、比べるときだけ同じにします。元の値は残します
3. 生年月日をそろえる … 和暦・西暦・区切りの記号の違いを、日付の型に直します。直せない値は空にせず、そのまま needs_human に回します
4. 社員番号を付ける … 対応表で、名簿の行に社員番号を付けます
5. 対応表で付かない行の候補を探す … 正規化した氏名のカナと生年月日が一致する在籍者・退職者を探します。1人なら仮に付けて印を残し、2人以上か0人なら人へ回します
6. 旧姓を足す … 氏名変更の異動がある人は、変更前の氏名のカナでも探します。改姓の届け出が済んでいない名簿は、旧姓のままです
7. 重複を確かめる … 名簿の中に同じ社員番号が2行ないかを、merge の validate="one_to_one" で確かめます

5番目で、氏名だけで付けないでください。 同姓同名で生年月日まで同じ人は少ないものの、2,400名と退職者を合わせると、氏名のカナだけで一致する人は必ずいます。 生年月日まで合わせ、それでも複数なら人が決めます。仮に付けたものは、担当者が一度確かめたら対応表に足し、翌月からは対応表で付くようにします。

AIに処理させる

させるのは、異動データの備考の自由記述を、決まった異動の種類に分けることだけです。 人事システムの異動の種類は「休職」「出向」のような大きな区分しかなく、私傷病の休職か、育児休業か、介護休業かは備考に書かれています。 団体保険の扱いが分かれるのは、この細かい区分です。

右端の列が、この構成でいちばん大事な区別です。 種類が決まれば、届け出が要るかは加入資格の表で機械的に決まります。決まらないものを近い種類に寄せると、その瞬間に誤った届け出の下書きが出ます。

4行目がいちばん起きやすい失敗です。 「休職」とだけ書かれた備考を渡すと、休職の大半が私傷病であることから leave_sick を選びがちです。指示で禁じ、理由が書かれていないものは unknown にします。

指示内容を固定する

あなたは人事部で、異動データの備考を読み、異動の種類を分ける立場です。
備考に書かれていることだけを根拠にしてください。推測で埋めないでください。

【分ける種類】
- leave_childcare ..... 育児休業（産前産後休業を含む場合はその旨を note に）
- leave_family_care ... 介護休業
- leave_sick .......... 私傷病による休職
- secondment_keep ..... 在籍したままの出向
- transfer_out ........ 転籍（元の会社を退職する出向）
- employment_change ... 雇用区分の変更（変更前と変更後を note に）
- name_change ......... 氏名の変更（変更後の氏名を new_name に）
- other ............... 上のどれでもない
- unknown ............. 種類を決める材料が備考に無い

【厳守事項】
- 備考に理由が書かれていなければ unknown にしてください。
  「休職」とだけあるとき、私傷病と決めないでください。
- 出向は、在籍か転籍かが書かれていなければ unknown にしてください。
- 1つの備考に2つの異動が書かれていれば、2件に分けてください。
- evidence には、判断の根拠にした備考の文字列をそのまま写してください。
- 団体保険に加入すべきか、届け出が要るかは書かないでください。
- 氏名・社員番号・生年月日は、渡されていても出力に書かないでください。
- 日付が書かれていれば、書かれたとおりに effective_date に写してください。
  書かれていなければ空にしてください。発令日から推測しないでください。

【異動の種類（人事システムの区分）】{change_type}
【発令日】{effective_on}
【備考】{remarks}

「加入すべきか、届け出が要るかは書かない」を明記しないと、親切に結論まで書きます。 結論が書かれていると、担当者はそれを読んで判断を終えてしまいます。届け出の要否は、加入資格の表から出た値だけを見せます。

生成AIに渡すのは、備考と区分と発令日だけです。 氏名や社員番号は渡さず、行の番号で結果を元の行に戻します。 指示に「書かないで」とあるのは、誤って渡したときの守りです。

出力形式を固定する

生成AIからは、次の形のJSONで受け取ります。

{
  "row_id": "",
  "events": [
    { "event_type": "leave_childcare | leave_family_care | leave_sick | secondment_keep | transfer_out | employment_change | name_change | other | unknown",
      "effective_date": "", "new_name": "", "note": "", "evidence": "" }
  ]
}

Python の判定の結果は、次の表で差異の一覧に書き出します。

1つ目の理由は、AIの出力と判定を別の層に置けることです。 events はAIが埋め、verdict は Python が規則で決めます。加入資格の取り決めが変わっても、直すのは加入資格の表だけです。

2つ目は、verdict の決め方を表で見せられることです。

要は、unknown を規則の側で必ず人へ回すことです。 種類が決まらないものを add_missing や remove_missing に入れないので、AIが迷った行が、そのまま届け出の下書きになることはありません。

システムへ連携する

保険会社・代理店へは、この構成からは送りません。 届け出の下書きを作るところまでで、様式への転記と送付は人が行います。 送った後に届け出の記録へ1行足すのも人の作業で、これを忘れると翌月の pending が判定できません。届け出の下書きの最後の列に「送った日」を空けておき、そこを埋めると記録に移る形にすると、忘れにくくなります。

人が確認する

人が見るのは、差異の一覧に出た行だけです。 名簿と人事データが合っている行は一覧に出ません。全行を開く設計にすると、第10章の6.0時間には収まりません。

1. needs_human を先に見る … 社員番号が付かなかった行、異動の種類が unknown の行です。多くは、対応表への追加か、人事システムの備考の書き足しで片付きます
2. remove_missing を確かめる … 退職した人が名簿に残っている行です。退職日と、契約の取り決めで脱退がいつ付けになるかを確かめます
3. add_missing を確かめる … 加入の資格があるのに名簿に無い行です。任意加入の保険では、本人が申し込んでいないだけのことがあります
4. change_missing を確かめる … 休職・復職、改姓、保険金額の区分の食い違いです
5. pending を流し見る … 届け出から日が経っても反映されていないものは、代理店に問い合わせます
6. 判定を覆したら記録する … どの行を、どの判定に変えたかを残します

3番目を急がないでください。 任意加入の団体医療保険で「資格はあるが入っていない」のは、本人の選択であることがほとんどです。加入資格の表で、任意加入の契約には「申込の記録がある人だけを載っているべきとする」と書いておきます。

目標は、360行をならして1行1分です。 差異の一覧に出るのは全体の一部という想定で、それより多い月は、対応表か加入資格の表に抜けがあります。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、名簿と人事データをつなぐ鍵の問題です。 対応表を育てるほど、毎月の needs_human は減っていきます。

記録を残す

• 実行ごとに、読み込んだ名簿・在籍者の一覧・異動データのファイル名と作成日・書き出し日
• 前月の名簿の写し（翌月の差分のため）
• Claude API に渡した備考と返ってきたJSON（氏名・社員番号は含めない）
• 判定の結果（should_be_insured、on_roster、verdict）と、そのとき使った加入資格の表の版
• 人が判定を覆した記録 … どの行を、どちらに変えたか
• 届け出の記録（送った日、名簿への反映を確かめた日）

判定の結果に「加入資格の表の版」を残すのは、取り決めが後から変わるためです。 契約の更新で休職者の扱いが変わると、過去の判定の意味が変わります。当時の表が残っていないと、どの月の届け出をやり直すべきかが決まりません。

覆した記録は、加入資格の表を直す材料になります。 同じ種類の行で毎月同じ方向に覆しているなら、表の書き方が取り決めと合っていません。