運行記録と点呼記録を突き合わせて、拘束時間と休息期間の基準に外れた運行を洗い出す

処理の起点を決める

毎朝1回のスケジュール実行を起点にします。 前日分が出そろってから動かすため、始業前に設定します。1日1回のリスクは、1回止まると1日分が丸ごと抜けることです。 処理の最後に「本日の対象は何運行だった」という行を書き出し、その行がない日を検知してください。 取り込みが遅れた日は後から再処理するので、運行番号を鍵にして上書きできる形にします。

入力データを集める

質を決めるのは、4番目と5番目です。 2人乗務とフェリーの利用は扱いが変わるのに、デジタコの記録だけでは区別が付きません。 また6番目を毎日引き継ぐことが「外れる前に気づく」の前提です。

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

運行記録： 管理サービスから前日分を取得します。APIがあればAPIで、無ければ日次のCSV出力を指定の場所に置きます。1日1回しか動かないので、リアルタイムでなくてかまいません。

点呼記録： 電子データを日付とドライバーで取得します。紙の記録簿しかない場合、突き合わせる相手がいないため、この構成は成り立ちません。 電子化が先になります。

運行日報： 荷待ちの時間と場所は、停車記録だけでは何のための停車か分かりません。運行日報の記録と停車の記録を時刻で結びつけ、結びつかない停車は「用途不明の停車」とします。

配車の割当・車両マスタ・フェリーの利用記録： スプレッドシートや運行指示書から読みます。デジタルタコグラフの側からは、フェリーに乗っている時間は「長い停車」としか見えません。

AIへ渡す前に整形する

1. 運行の単位をそろえる … デジタルタコグラフは車両単位、点呼記録はドライバー単位です。運行番号を鍵にして結びつけ、結びつかない記録は分離します
2. 時刻のずれを吸収する … 「点呼記録を優先し、無い場合のみエンジン始動時刻を使う」のように、どちらを始業とするかを先に1つに決めます
3. ずれが大きい運行を分離する … 点呼とエンジン始動が30分以上離れている運行は、既定値で埋めず、記録の矛盾として別に出します
4. 停車の用途を分類する … 運転の中断、荷待ち、荷積み・荷卸し、フェリー乗船、休息期間に分類し、当てはまらない停車には印を付けます
5. 2人乗務と長距離の印を付ける … 配車表と車両マスタで割当と設備の有無を確認します。この印であとの判定に使う基準が変わります
6. 前日までの累計を読み込む … 当月・当年の累計に、当日分を足せる状態にします

2番目を1つに決めることが重要です。 運行ごとに人が判断する限り、判定は人によって変わり続けます。ルール自体が実態に合っていないことは、例外の件数で分かります。

AIに処理させる

判定はAIにさせません。 拘束時間、休息期間、連続運転時間、1か月と1年の累計は、すべて Python で計算します。判定する内容と基準は次のとおりです。

この表の数値が、そのまま計算の条件になります。 AIに任せるのは、(1) 記録の欠けと矛盾の説明、(2) 是正の指示文の下書き、(3) 翌月の配車の注意点の要約、の3つだけです。

(1) がいちばん効きます。 記録の欠けは、機械が出すと「点呼記録なし」の1行になり、担当者は動けません。「3月14日の運行番号1024について、乗務後点呼の記録がありません。エンジン停止は18時42分、同日の乗務前点呼は6時10分です。実施時刻を点呼記録簿に追記してください」まで書ければ、そのまま連絡に使えます。(3) は月末に1回だけ動かしますが、「休息期間が9時間台になる日が続いた」の日数は Python が数えた値を渡します。

指示内容を固定する

あなたは、トラック運送事業の運行管理者を支援する立場です。
計算済みの判定結果と、記録の欠け・矛盾の一覧を渡します。これをもとに
(1) 何が起きているかの説明文、(2) 是正の指示文の下書き を作ってください。
運行管理者が読んで判断し、直したうえで使います。あなたの出力は判断材料
であり、最終判断ではありません。

【厳守事項】
- 時間、時刻、回数、日数を自分で計算しないでください。拘束時間、休息
  期間、連続運転時間、累計、残り時間は渡した値をそのまま使い、足し算、
  引き算、四捨五入、単位の変換、概算への言い換えをしないでください。
- 渡していない数値を本文に書かないでください。本文に出てくる数値は
  すべて facts_used に「項目名・使った値・出どころ」で列挙してください。
- 法令に違反しているかどうかの断定をしないでください。「違反です」と
  書かず、「計算上、1日の拘束時間が15時間を超えた記録になっています。
  記録の確認をお願いします」のように、確認を求める書き方にし、罰則や
  行政処分には触れないでください。
- 記載がない項目は不明として扱い、推測で補わないでください。
  needs_human_attention の理由に「〇〇が不足」と書きます。
- フェリー乗船、分割した休息期間、2人乗務、荷待ちの扱いを、あなたの判断
  で「この扱いでよい」と書かないでください。渡した分類結果をそのまま書き、
  分類できていない場合は「確認が必要」とします。
- ドライバー個人の勤務態度、能力、健康状態への評価を書かないでください。
- 是正の指示文には、誰が、何を、いつまでに行うかを入れてください。

【運行の情報】{run_info}
【計算済みの判定結果】{calculated_results}
【記録の欠け・矛盾の一覧】{record_issues}
【当月の累計と着地見込み（計算済み）】{monthly_totals}
【この運行に付いている印（2人乗務・長距離・フェリー利用など）】{flags}

「自分で計算しない」が、いちばん効く制約です。 労働時間の数値は、ドライバー本人も配車担当も自分の記憶と照らして読みます。1つずれるだけで、その一覧全体が信用されなくなります。

「違反かどうかの断定をしない」も必要です。 記録そのものが誤っていることがあり、例外の扱いが認められる場合もあります。機械が「違反」と書いた文面がそのまま使われると、事実でないことを会社が通知したことになります。 また、労働時間の記録は書き方によって人事評価の文書に読めるため、個人への評価も書かせません。 月末の要約を作る指示でも、「渡した数値以外の数を書かない」「配車の組み方の注意点として書く」を同じ形で縛ります。

出力形式を固定する

{
  "run_id": "", "driver_id": "", "run_date": "",
  "finding_type": "record_missing | record_mismatch | threshold_exceeded | threshold_approaching | no_finding",
  "explanation": "", "correction_request": "",
  "missing_items": [{ "item": "", "where": "", "why_it_matters": "" }],
  "facts_used": [{ "item": "", "value": "", "source": "" }],
  "needs_human_attention": { "flag": false, "reason": "" }
}

月末の要約は month driver_id watch_points（point と based_on）facts_used の形にします。構造化する理由は3つです。

1つ目は、確認を速くするためです。 facts_used に「本文で使った数値とその出どころ」を列挙させると、運行管理者は説明文を読みながら、その数字がデジタコの値か点呼記録の値かを一目で確かめられます。

2つ目は、一覧の並べ替えのためです。朝の一覧で最初に読むのは threshold_approaching です。 これだけが、今日の配車を変えれば間に合うからです。なお threshold_exceeded は「違反があった」印ではなく、計算の結果が基準の数値を超えた記録になっているという意味です。

3つ目は、書き出し先で機械的に扱うためです。 構造化出力を使うと応答が常に有効な JSON になり、スキーマ違反による再試行が要りません。 ただし additionalProperties は false にする必要があり、minItems は 0 か 1 しか指定できません。数値や文字列の長さの制約も使えませんが、数値をAIに返させないので問題になりません。

システムへ連携する

書き出し先は専用の画面にせず、スプレッドシートにします。 普段使う道具の中に出るほうが毎朝開かれます。点呼記録簿への書き戻しは行いません。 法令上の記録を機械が書き換えると正しさを担保できないためで、訂正は人が正規の手順で行います。

人が確認する

印の付いた運行は全件、運行管理者が確認します。 順番は、threshold_approaching の人（今日の配車を変えれば間に合う）、threshold_exceeded、record_missing、record_mismatch、needs_human_attention が真の運行です。過去の報告より先に、まだ変えられるものを読みます。

• facts_used の数値が、デジタルタコグラフと点呼記録の値と合っているか
• 記録の欠けが、本当の欠けなのか取り込みの失敗なのかの見分け
• 計算の前提（どの時刻を始業としたか、停車をどう分類したか）が実態と合っているか
• 是正の指示文が、その相手に送ってよい内容か

3番目は機械にできません。 フェリーに乗っていた時間、荷待ちの時間、休息として過ごした時間は、車両の動きが同じでも意味が違います。

そして、基準に外れているかどうかの最終的な判断は、必ず人が行います。 記録の誤り、例外の扱い、就業規則との関係を踏まえて判断するのは運行管理者で、迷う事案は労務担当や労働基準監督署に確認してください。確認の目標は1件10分です。

例外に対処する

最後の行は仕組みで持ってください。 説明文の数値を機械で拾い、facts_used と照合するだけの処理です。7行目を自動化しないことも重要です。 「遅れたから除く」を機械が行うと、客観的な記録の確認を飛ばすことになります。除外の判断と根拠の確認は人が行い、誰がいつ承認したかを残してください。

記録を残す

• 取り込んだ運行記録・点呼記録の件数と、取り込めなかった件数
• 計算に使った前提（どの時刻を始業としたか、停車をどう分類したか）
• 計算した拘束時間・休息期間・連続運転時間と、判定の結果
• AIに渡した材料と、返ってきた説明文・指示文・facts_used
• 人が直した箇所と、直した内容
• 運行管理者の判断（記録の訂正、是正の指示、配車の組み替え）と日時
• 予期し得ない事態による除外の根拠とした記録と、承認者

2番目と7番目を必ず残してください。 「どの時刻を始業としたか」は判定の結果を左右し、除外は結果を変えるものです。残っていないと、同じ計算を再現できず、誰が何をもとに承認したかも説明できません。 5番目からは弱点が見えます。 「毎回、荷待ちの扱いを直している」なら、運行日報の様式に問題があります。