勤怠の締め前に、打刻漏れと時間外の上限と年休の取得状況を点検する

処理の起点を決める

毎月、締め日の翌日未明に定時で実行します。 労務担当が出社したときには点検リストが出来ている状態にします。

締め日直前の点検も有効です。締め日の3営業日前に一度走らせると、修正のための時間が確保できます。 ただし、この段階では月末までの勤務予定が確定していないため、時間外の上限判定は「見込み」として扱います。

未回答の再掲は、毎日9時の定時実行で行います。この仕組みが、この構成でもっとも効果が出る部分です。

入力データを集める

「過去12か月分」を必ず取ってください。 複数月平均と年間の上限は、当月のデータだけでは計算できません。そして「店舗の業務連絡」が、この構成の効き目を決めます。 打刻漏れの理由を推し量る材料は、勤怠データの中にはありません。

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

勤怠システム： APIがあればAPIを、なければ管理画面からのCSVエクスポートを使います。多くの国産の勤怠管理システムはCSVエクスポートを備えているので、まずそこを確認してください。 APIの有無と仕様は、自社のシステムのベンダーへの確認が必要です。

店舗の業務連絡： Teams のチャネルから、当月の投稿を取得します。個人のチャットは対象にしません。 業務連絡のチャネルに限ります。

36協定の内容： 文書から手で設定表に写します。年に1回の更新で足ります。協定の内容は事業場ごとに違うことがあるため、事業場単位で設定できるようにしてください。

AIへ渡す前に整形する

1. 雇用区分ごとの分離 … 正社員、パート、管理監督者で適用される基準が違います。管理監督者は時間外労働の上限規制の対象外ですが、年次有給休暇の年5日は管理監督者も対象です。 ここを一緒に処理すると誤判定になります
2. シフトとの突合 … 打刻がない日について、シフト上の勤務予定の有無を確認します。予定がなければ異常ではありません
3. 申請との突合 … 打刻の異常について、対応する申請が出ているかを確認します。申請済みなら異常から外します
4. 年休の基準日の算出 … 入社日から基準日を求め、そこから何か月経過しているかを計算します。入社日から起算する方式と、全社一斉の基準日方式とで計算が変わるため、自社の方式を確認してください
5. 業務連絡の日付での紐付け … 店舗の業務連絡を日付と店舗で索引化し、異常のあった日と結び付けます

AIに処理させる

判定は計算で行います。 使う基準は法令で決まっています。

この6つは、しきい値で機械的に判定できます。LLMに判断させる理由がありません。 判定をLLMに任せると、根拠を追跡できなくなり、監督署の調査で説明できません。

LLMにさせること：

確認文の質が、この構成の成否を決めます。 悪い例と良い例を並べます。

• 悪い例：「3月5日の退勤打刻がありません。確認してください」
• 良い例：「3月5日の退勤打刻がありません。当日は店舗チャネルに『棚卸のため21時まで残る』という連絡が出ていました。退勤時刻は21時30分ごろでよろしいでしょうか。違う場合は実際の時刻をお知らせください」

後者なら、店長はその場で答えられます。 差し戻しが返ってこない原因の大半は、聞かれた側が思い出せないことにあります。

指示内容を固定する

あなたは、勤怠の締め前の点検を支援する担当者です。
検出された異常について、店舗の管理者が答えられる形の確認文を作ってください。

【厳守事項】
- 法令の判定をしないでください。上限に当たるかどうかの判定は
  すでに計算済みで、入力に含まれています。
  その判定を言い換えるだけにし、あなたが基準を解釈しないでください。
- 打刻の時刻を、あなたが決めないでください。
  推定した時刻は候補として示し、必ず疑問形で確認してください。
  「21時30分に修正しました」ではなく「21時30分ごろでよろしいでしょうか」と書いてください。
- 推定の根拠がない場合は、推定を書かないでください。
  「3月5日の退勤打刻がありません」とだけ書き、
  basis を null にしてください。根拠のない推測を添えないでください。
- 根拠に使った情報（シフト、申請、業務連絡）は、
  日付と出どころが分かる形で basis に書いてください。
- 本人の健康、私生活、勤務態度に関する記述をしないでください。
  「働きすぎです」「遅刻が多いです」と書かないでください。
  事実と、確認したい点だけを書いてください。
- 上限に近い人への連絡文では、残りの時間数を明記してください。
  「上限に近づいています」だけでは行動できません。

【従業員の情報】
氏名: {name} / 所属: {store} / 雇用区分: {employment_type}

【計算済みの判定結果】
{findings}

【当月のシフトと打刻】
{shift_and_punch}

【申請記録】
{requests}

【当日の店舗の業務連絡】
{store_notes}

「法令の判定をしないでください」の1行が、この構成の安全装置です。 これを書かないと、LLMは親切に「これは36協定違反の可能性があります」と書きます。その判断が誤っていても、読んだ担当者は気づけません。 判定はプログラムの出力を言い換えるだけにします。

「本人の健康、私生活、勤務態度に関する記述をしない」も必ず入れてください。 勤怠の指摘に評価の色がつくと、労務問題になります。

出力形式を固定する

計算部分（プログラム）の出力：

{
  "employee_id": "",
  "store": "",
  "employment_type": "regular | part_time | manager",
  "findings": [
    {
      "type": "punch_missing | shift_mismatch | break_shortage | unapproved_overtime | limit_month | limit_average | limit_year | limit_count | annual_leave_5days",
      "date": "",
      "detail": {
        "actual": 0,
        "threshold": 0,
        "remaining": 0,
        "unit": "hours | days | times"
      },
      "severity": "critical | high | medium | low"
    }
  ],
  "overtime_status": {
    "current_month_hours": 0,
    "months_over_45h_this_year": 0,
    "remaining_times_over_45h": 0,
    "annual_hours": 0,
    "remaining_annual_hours": 0,
    "rolling_average_2to6_months": []
  },
  "annual_leave_status": {
    "base_date": "",
    "months_elapsed": 0,
    "days_taken": 0,
    "days_required": 5,
    "deadline": ""
  }
}

LLM部分の出力：

{
  "employee_id": "",
  "messages": [
    {
      "finding_type": "",
      "date": "",
      "question_text": "",
      "estimated_value": "",
      "basis": "",
      "basis_source": "shift | request | store_note | none"
    }
  ],
  "store_summary": "",
  "needs_review": []
}

計算とLLMの出力を分けます。 判定の根拠は計算側のJSONだけで説明できる状態にしてください。監督署の調査で示すのはこちらです。LLMが作った文は、現場に聞くための道具にすぎません。

basis_source に none を用意しているのは、根拠のない推定と、根拠のある推定を区別するためです。none の確認文には推定を含めません。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-15時点ではベータ機能として提供）。項目が多い出力なので、利用できる場合は形の崩れを防げます。

システムへ連携する

勤怠システムへの書き込みは自動化しないでください。 勤怠データの修正は、事実に基づいて人が行うものです。推定値を自動で書き込む構成は、記録の改ざんと見なされかねません。 労務担当が店長の回答を確認したうえで、従来どおり手で修正します。

人が確認する

すべての指摘を労務担当が確認したうえで、店長へ送ります。 自動送信しません。

見る優先順位は次のとおりです。

優先度1は、点検ではなく対応です。 上限に当たってからでは手遅れなので、残り時間が一定を切った時点で通知する仕組みを、月次の締めとは別に用意してください。

例外に対処する

記録を残す

• 取り込んだ勤怠データ（取得日時つき）
• 計算による判定結果（overtime_status と annual_leave_status を含む）
• LLMが作った確認文と、その根拠
• 店長の回答
• 勤怠システムを修正した内容と、修正者・修正日時
• 上限に近づいた人への通知の記録

最後の項目は、労務管理を行っていた証跡になります。 労働時間の管理は使用者の義務であり、「把握していたか」「把握したうえで手を打ったか」が問われます。 通知した記録を残してください。

勤怠データは個人情報です。 保管場所と閲覧権限を、人事部門と当該店舗の管理者に限定してください。