派遣会社の契約台帳から事業所単位と個人単位の抵触日が近い契約を毎月判定し、派遣先への確認と意見聴取の期限を営業に知らせる

処理の起点を決める

毎月1日の7時台に動く時間主導型のトリガーを起点にします。 月初に、その月に更新・新規を迎える契約と、今後6か月以内に抵触日が来る契約をまとめて点検します。公式のページでは、時間主導型の時刻は少しずれることがあるとされていますが、月に1回の点検なので、分単位の正確さは要りません。

月の途中で結ぶ新規の契約は、別に週1回の点検を置きます。 新しい派遣先や新しいスタッフの契約は、月初を待つと結んだ後に抵触日の問題が分かることがあります。毎週月曜に、前の週に台帳に足された行だけを点検します。

1回の実行は6分までです。 公式の割り当ての表では、スクリプトの1回の実行の時間は6分が上限とされています。台帳が大きい場合は、派遣先の頭文字や担当営業ごとに分けて、続けて実行する形にします。 どこまで終わったかを処理ログに書き、次の実行はその続きから始めます。

入力データを集める

質を決めるのは、正規名の対応表です。 最初は空で始め、AIの判定と人の確認を経て、毎月育ちます。対応表に載った揺れはAIに渡さないので、月を追うごとにAIの出番は減ります。

生年月日は、60歳になる日を出すためだけに使います。 AIには渡しません。

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

台帳はスプレッドシートを読むだけです。行を、スタッフID・派遣先・事業所の所在地の3つでまとめます。 事業所の名前ではなく所在地でまとめるのは、名前より所在地のほうが揺れにくいからです。

AIに渡すのは、まとめた行の中で、対応表で置き換えても名前が2つ以上残る組だけです。 「経理課」と「経理部 経理課」が同じ所在地・同じスタッフの行にあれば、その2つの名前と、それぞれの契約期間・業務内容を渡します。スタッフの氏名は渡さず、スタッフIDも渡しません。 組の判定に要らないからです。

AIへ渡す前に整形する

1. 空白・全角半角の正規化 … 「経理部　経理課」「経理部 経理課」をそろえます
2. 対応表の当て込み … すでに決まった揺れを正規名に置き換えます
3. 規則による例外の判定 … スタッフ台帳で無期雇用の区分、契約期間中に60歳以上かを計算します。これらはAIに渡さず、規則だけで決めます
4. 連続の判定 … 同じ組の契約が途切れなく続いているかを見ます。契約と契約のあいだに空白の期間がある組には「空白あり」の印を付けます
5. 事業所単位の通知の確認 … 通知された抵触日の列が空の契約に「通知なし」の印を付けます

4番目の「空白あり」は、規則で通算・リセットを決めません。 空白の期間を通算するかどうかは、期間の長さや事情によって扱いが変わりうるため、この構成では一律に人が確かめる行に回します。 機械で決めると、通算すべきものをリセットして抵触日を見落とすおそれがあるからです。

日付の計算は、前処理の段階で関数を1つにまとめて書きます。 「開始日から3年を経過した最初の日」「その1月前の日」を出す関数を、個人単位・事業所単位・意見聴取の期限のすべてで同じものを使います。場所ごとに別々に書くと、片方だけ月末の扱いが違う、ということが起きます。 スクリプトのタイムゾーンは日本の時刻に合わせ、台帳の日付は時刻を持たない日付として読みます。時刻つきで読むと、タイムゾーンの差で前日の日付に化けることがあるためです。この関数には、2月29日に始まった契約、月末日に始まった契約など、境目の例をテストとして並べておき、直すたびに全部が通ることを確かめます。 境目の例の正しい答えは、法務の担当が業務取扱要領を見て決めた日を使います。

5番目は、法の定めから来ています。 労働者派遣法第26条第4項は、新たな派遣契約を結ぶ派遣先が、あらかじめ派遣元に事業所単位の抵触日を通知しなければならないと定め、第5項は、通知が無いときは派遣元はその契約を結んではならないとしています。台帳に通知の日が無い契約は、それ自体が知らせるべき事柄です。

AIに処理させる

させるのは、2つの判定だけです。

2行目と3行目が、この構成でいちばん大事な線引きです。 AIが「当たらない」と書けば、読む人は安心して点検を止めます。AIには「同じか」「記載と合っているか」という材料だけを出させ、結論は人に残します。

指示内容を固定する

あなたは人材派遣会社の管理部で、契約台帳を点検する担当です。
渡された台帳の記載だけを根拠に、次の2つを判定してください。

【判定1：名前の組が同じ組織単位を指すか】
同じ派遣先・同じ所在地で、同じスタッフの契約に出てくる組織単位の名前の組を渡します。
- same ....... 同じ組織単位を指すと言える記載がある
               （表記の違いだけ、上位の部名の有無だけ、など）
- different .. 別の組織単位を指すと言える記載がある
               （業務内容がはっきり違う、別の課名が並んでいる、など）
- unclear .... どちらとも決められない（改称か別組織か分からない、など）
迷ったときは unclear を選んでください。
same を選ぶと期間が通算され、different を選ぶと通算されません。
どちらも誤れば影響が大きいので、記載で言い切れないときは unclear です。

【判定2：例外の区分が業務内容の記載と合っているか】
台帳の例外の区分と、その契約の業務内容・期間の記載を渡します。
- supported ...... 区分に合う記載がある（例：終了の予定がある事業の立ち上げ、
                   休業する社員の業務の代替である旨、など）
- inconsistent ... 区分と合わない記載がある（例：ふだんの定常の事務など）
- insufficient ... 判断できるだけの記載が無い

【厳守事項】
- 台帳に書かれていない派遣先の組織や事情を補わないでください。
- 期間制限に当たるか当たらないかの結論を書かないでください。
- 日付の計算をしないでください。
- 根拠 evidence には、判定に使った台帳の記載をそのまま写してください。
- 業務内容の記載が短すぎる場合は、insufficient または unclear にしてください。

【名前の組と各行】{name_groups}
【例外の区分の付いた契約】{exception_rows}

「same を選ぶと通算され…」を指示に書くのは、判定の重みをAIに伝えるためです。 名前が似ているだけで same にすると、後ろの計算で起点の日が早まり、実際より早い抵触日が営業に届きます。 逆に different にしすぎると、見落としになります。どちらにも倒さず unclear を選ばせるために、影響をそのまま書きます。

出力形式を固定する

構造化出力のスキーマで、次の形を返させます。strict: true では全項目を required に並べる必要があるため、値が無いときは空文字を返させます。

{
  "name_judgments": [
    {
      "group_id": "",
      "names": [""],
      "result": "same | different | unclear",
      "evidence": ""
    }
  ],
  "exception_judgments": [
    {
      "contract_id": "",
      "exception_type": "project | limited_days | leave_substitute",
      "result": "supported | inconsistent | insufficient",
      "evidence": ""
    }
  ]
}

1つ目の理由は、判定と計算を分けられることです。 スクリプトは same の組だけを1つの組織単位としてまとめ、その中の最初の開始日から個人単位の抵触日を計算します。unclear の組は、まとめた場合とまとめない場合の両方の抵触日を一覧に並べ、早いほうを仮の日として扱います。

2つ目の理由は、期限の一覧を規則で組み立てられることです。 一覧の列は次のとおりです。

意見聴取の期限は、法の定めをそのまま規則にしています。 労働者派遣法第40条の2第3項・第4項は、派遣先が派遣可能期間を延長するときは、抵触することとなる最初の日の1月前の日までの間に、過半数労働組合等の意見を聴かなければならないとしています。意見を聴くのは派遣先ですが、派遣元の営業がその時期を知っていれば、延長の意向を早めに確かめられます。

システムへ連携する

メールは、受け取る人ごとに中身を変えます。 営業には担当する派遣先の事業所単位の期限と意見聴取の期限の目安、コーディネーターには担当するスタッフの個人単位の抵触日、管理部には印の付いた行の一覧を送ります。全員に全件を送ると、自分の行を探す手間が増え、読まれなくなります。

延長の通知を受けたときの段取りも、一覧に載せます。 派遣先が派遣可能期間を延長したときは、労働者派遣法第40条の2第7項で、派遣先は速やかに派遣元へ延長後の抵触日を通知しなければならないとされ、第34条第2項で、派遣元はその通知を受けたら遅滞なく、その事業所で働く派遣スタッフに延長後の抵触日を明示しなければならないとされています。台帳の「延長後の抵触日」の列が埋まった月に、明示が済んだかの確認の行を管理部の一覧に足します。

個人単位の抵触日が近いスタッフは、コーディネーターへの一覧に載せます。 労働者派遣法第30条は、同じ組織単位で継続して3年間働く見込みがある有期雇用の派遣スタッフについて、派遣先への直接雇用の依頼などの雇用安定措置を講じなければならないと定めています。次の就業先の相談に間に合うよう、抵触日の6か月前から一覧に出します。

人が確認する

1. 管理部が unclear の組を決める … 営業に派遣先の組織図や改称の有無を確かめてもらい、同じか違うかを決めて正規名の対応表に書きます
2. 管理部が inconsistent と insufficient の例外の区分を確かめる … 個別契約書を開き、区分が誤っていれば台帳を直し、期間制限の対象として点検し直します
3. 「通知なし」の契約を営業に確かめる … 派遣先から事業所単位の抵触日の通知を受けているかを確かめ、受けていなければ契約の手続きを止めます
4. 「空白あり」の組の扱いを決める … 空白の期間の長さと事情を見て、通算するかを法務の担当が決めます
5. 営業が派遣先と話す … 延長の意向と意見聴取の予定を確かめ、結果を台帳に書きます

3番目を飛ばさないでください。 通知の無い契約を結ぶことは、第26条第5項が禁じていることです。一覧の上に必ず置き、営業から返事が来るまで印を消しません。

human_check を「必須」にしているのは、AIの判定が期間の通算に直結するためです。 same と出た組も、最初の数か月は管理部が全部確かめます。確かめた組は対応表に載るので、翌月からは確認の対象から外れます。

例外に対処する

いちばん上の行の扱いが、この構成の安全側の考え方です。 AIが使えないときは、名前の揺れをすべて「不明」として扱い、早いほうの抵触日を仮に使います。 知らせが多めに出ますが、見落としは起きません。

記録を残す

• 点検の実行日、対象にした契約の範囲、どこまで終わったか
• AIに渡した名前の組と例外の区分の記載、返ってきた JSON の全文
• 計算した抵触日と期限、付いた印
• 人が決めた結果 … どの組を同じ・違うと決めたか、誰がいつ、何を根拠に
• 送ったメールの宛先と日時

人が決めた結果は、正規名の対応表と処理ログの両方に残します。 対応表は次の月の計算に使うためのもの、ログはなぜその日を起点にしたかを後から説明するためのものです。期間制限について労働局から聞かれたときに、台帳と一緒に出せる形にしておきます。

AIの判定と人の決定が違った組は、月に1回数えます。 same を人が different に直した組が続くなら、渡している業務内容の記載が短すぎるか、指示の例が足りていません。直しの多い派遣先から、台帳の業務内容の書き方を見直します。