タクシー会社の乗務員が手書きする乗務記録（運転日報）を読み取り、営業収入・走行距離・休憩の時刻を集計表にそろえて、記入漏れと拘束時間の超過の疑いを拾う

処理の起点を決める

スキャンした PDF が保管先（Azure Blob Storage）に入ったことを起点にします。 乗務記録は、乗務員が帰庫して納金するたびに事務所に出てきます。隔日勤務の帰庫は早朝に集中するので、事務担当が朝の始業のときにまとめてスキャンし、その日の昼までに前日帰庫分の確認の一覧がそろうようにします。

起点の仕組みは Azure Functions の Blob Storage のトリガーです。公式のページでは、イベント方式とポーリング方式があり、遅れの小さいイベント方式が推奨され、ポーリング方式は従量課金のプランで最大10分の遅れが出うるとされています。昼までにそろえば足りる題材ですが、取りこぼしを避けるためにイベント方式にします。

時間の判定は、点呼の記録がそろってから動かします。 拘束時間の計算には、始業と終業の時刻が要ります。点呼の記録簿の CSV が毎朝書き出されたあとに、前日帰庫分の時間の判定をまとめて流します。

入力データを集める

質を決めるのは、乗務員の台帳です。 日勤と隔日勤務では、拘束時間と休息期間の基準がまったく違います。勤務の形態を台帳に持たせ、乗務ごとにどちらの基準で照らすかを決めます。

前の乗務の記録は、休息期間を数えるために持ちます。 休息期間は「前の乗務の終業から、次の乗務の始業まで」なので、1枚の乗務記録だけでは数えられません。

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

読み取りは、Azure Functions からカスタム ニューラル モデルを呼ぶだけです。モデルの学習には、自社様式の乗務記録で、乗車の行の数が少ないもの・多いもの・2枚目にまたがるものを混ぜた見本を使います。

時刻の読み取りは、24時を超える書き方に気をつけます。 隔日勤務では、日付をまたいだ時刻を「26:30」と書く乗務員と「2:30」と書く乗務員がいます。どちらで書くかを様式の注記で決め、読み取った時刻は日付と組にして持ちます。

点呼の記録は CSV を読むだけです。乗務記録の乗務員名は手書きなので、点呼の記録とは乗務員の番号で照らします。 様式に乗務員の番号の欄を設け、名前より番号を先に照らします。

AIへ渡す前に整形する

1. ページの対応づけ … 乗車の行が多い乗務は2枚になるので、乗務員の番号と日付で1乗務にまとめます
2. 向きと寸法の確認 … 画像は50×50〜10,000×10,000ピクセル、文字の最小の高さは1024×768の画像で12ピクセル（150dpiで約8ポイント）です。乗車の行の数字は小さいので、200dpi以上でそろえます
3. ファイルの大きさ … 有料（S0）レベルで500MB、PDF は2,000ページまでです
4. 重複の検知 … 同じ乗務員の同じ日付の乗務記録が二度読まれたら、新しい方を「二重」として人へ回します
5. 台帳との照合 … 乗務員の番号が台帳に無ければ、時間の判定をせずに人へ回します

1番目を省くと、2枚目の乗車の行が別の乗務として集計されます。 営業収入の合計が1枚目にしか書かれていなければ、1枚目は合計が合わず、2枚目は合計が無いという2件の食い違いが出ます。

AIに処理させる

読み取りのモデルにさせるのは、項目と表の行の値を信頼度付きで返すことだけです。 生成AIにさせるのは、事故・遅延の記載欄の手書きを写して要点を分けることだけです。集計と時間の判定は、プログラムの規則で行います。

記入漏れの項目は、旅客自動車運送事業運輸規則 第25条に沿って決めます。 タクシー（一般乗用旅客自動車運送事業者）は、運転者ごとに、氏名、車両の登録番号等、業務の開始・終了の地点と日時、主な経過地点、業務に従事した距離、交替した場合の地点と日時、休憩・仮眠の地点と日時、事故等の概要と原因、旅客が乗車した区間、走行距離計の業務の開始時と終了時の積算キロ数を記録させ、車両ごとに整理して1年間保存することが求められています。この項目を様式の欄と対応させ、空欄を拾います。

時間の基準は、改善基準告示のタクシーの基準を台帳の勤務の形態ごとに持ちます。

判定は「疑い」として出し、基準の判断はしません。 車庫待ち等の特例、事故や災害で遅延した時間の扱いなど、基準には例外があり、乗務記録だけでは決められないからです。

1行目がいちばん起きやすい失敗です。 1行の運賃が読めないとき、合計から他の行を引けば数字は出ます。埋めた瞬間、合計の照合は必ず合うようになり、照合の意味が無くなります。

指示内容を固定する

あなたはタクシー会社の営業所で、乗務記録の「事故・遅延・異常」の欄を整理する担当です。
渡すのは、その欄から読み取った手書きの文字列だけです。
書かれていることを写し、要点を分けてください。推測で補わないでください。

【分け方】
- accident ...... 交通事故、接触、物損の記載
- delay ......... 渋滞、通行止め、車両の故障などによる遅れの記載
- passenger ..... 乗客とのトラブル、忘れ物、料金の未収の記載
- vehicle ....... 車両の不具合の記載
- other ......... 上のどれにも当たらない記載

【厳守事項】
- 原文の文字列を original にそのまま写してください。言い換えないでください。
- 時刻・地点が書かれていれば time と place に写してください。書かれていなければ空にしてください。
- 原因が書かれていれば cause に写してください。書かれていなければ空にしてください。
  前後から原因を推測して書かないでください。
- 読めない文字は「■」に置き換え、unreadable を true にしてください。
- 責任の所在、違反の有無、乗務員の評価については書かないでください。
- 欄が空の場合は、items を空の配列にしてください。

【欄の読み取り結果】{incident_text}
【読み取りの信頼度】{incident_confidence}

「原因を推測しない」を明記しないと、もっともらしい原因を書き足します。 「○○交差点で接触」とだけ書かれた記載に「右折時の確認不足」と足されると、運行管理者が乗務員から聞く前に、原因が決まったように見えます。 第25条は事故等の「概要及び原因」の記録を求めていますが、原因を書くのは乗務員と運行管理者です。

「責任や違反を書かない」も同じ理由です。 この欄の整理は、運行管理者が事故の報告を見落とさないためのもので、評価のためではありません。

出力形式を固定する

乗務1件ごとに、読み取り・集計・判定・生成AIの結果を次の形の JSON にまとめます。 生成AIの部分は Azure OpenAI の構造化出力で受け取り、response_format に json_schema を指定して strict: true、すべての項目を必須にして additionalProperties: false を付けます。

{
  "trip_id": "2026-10-12_D1043",
  "driver_no": "D1043",
  "shift_type": "day | alternate",
  "vehicle": "",
  "depart": { "time": "2026-10-12T07:05", "odometer": 0, "place": "" },
  "return": { "time": "2026-10-13T02:40", "odometer": 0, "place": "" },
  "distance_km": 0,
  "rides": { "count": 0, "fare_sum": 0, "table_confidence": 0, "low_rows": [] },
  "revenue_written": 0,
  "revenue_match": "match | mismatch | unreadable",
  "missing_items": [],
  "binding_hours": { "value": 0, "basis": "roll_call | trip_record", "flag": "ok | suspect" },
  "rest_hours": { "value": 0, "flag": "ok | suspect | unknown" },
  "incidents": [
    { "category": "accident | delay | passenger | vehicle | other",
      "original": "", "time": "", "place": "", "cause": "", "unreadable": false }
  ],
  "verdict": "ok | check"
}

1つ目の理由は、basis で時間の根拠が分かることです。 拘束時間を点呼の時刻から数えたのか、点呼の記録が無くて乗務記録の出庫・帰庫から数えたのかで、疑いの重みが違います。 運行管理者は trip_record のものから先に点呼の記録を確かめます。

2つ目は、low_rows で見る行が絞れることです。 営業収入が合わないとき、信頼度の低い行の番号が分かれば、40行を見直さずに2〜3行を見るだけで済みます。

確認の一覧は、事務担当向けと運行管理者向けに分けます。

【事務担当向け（2026-10-13 帰庫分）】
乗務員 / 車両 / 理由（記入漏れ・合計の食い違い・読み取りの迷い） / 見る行 / 画像

【運行管理者向け（2026-10-13 帰庫分）】
乗務員 / 勤務の形態 / 拘束時間 / 根拠 / 休息期間 / 今月の拘束時間の累計 / 事故・遅延の記載

システムへ連携する

給与計算のシステムへは書き込みません。 営業収入は乗務員の給与に直結するので、集計表は事務担当が確かめたものだけを月末に回します。

人が確認する

事務担当が開くのは check の乗務だけです。 ok の乗務は、件数と営業収入の合計を日ごとに見るだけにします。

1. 合計の食い違いを見る … low_rows の行を画像で確かめ、読み違いなら直します。乗務員の計算違いなら、乗務員に確かめてから直します
2. 記入漏れを乗務員に聞く … 次の出庫の点呼のときに聞き、乗務員に書き足してもらいます。事務担当が推測で埋めません
3. 運行管理者が時間の疑いを判断する … 点呼の記録、車庫待ち等の扱い、事故や遅延の記載を見て、基準の超過に当たるかを判断します
4. 判断と対応を記録する … 超過と判断したら、次の勤務の組み直しや乗務員への説明を記録します

3番目を事務担当で閉じないでください。 時間の判断は、勤務の組み方を決める運行管理者の仕事です。 確認の一覧はその材料です。

例外に対処する

6行目は、帰庫の順番がばらばらなので必ず起きます。 前の乗務の乗務記録が後から出てきたら、今回の休息期間を数え直す処理を、毎朝の判定のなかで回します。 数え直しで suspect に変わった乗務は、すでに運行管理者が見た一覧とは別に「数え直しで変わった乗務」として出し、一度 ok で流れた乗務が黙って疑いに変わることのないようにします。

最後の行の poison キューは、公式のページに書かれた Azure Functions の仕組みです。 同じファイルを二度処理しないための受領記録（blob receipts）も持つとされているので、読み直したい乗務記録は、その記録を消してやり直します。

記録を残す

• 乗務記録の画像と、提出された日時・営業所
• 読み取りの結果の JSON の全文（項目・表・行・セルの信頼度）
• 集計と判定の結果と、そのとき使った基準の表と乗務員の台帳の版
• 人が値を直した記録 … 読み取りの値、直した値、直した人、理由
• 運行管理者の判断と対応の記録
• 乗務員ごとの記入漏れの発生率

紙の乗務記録そのものは、これまでどおり保存します。 第25条は記録を車両ごとに整理して1年間保存することを求めています。どの形で保存するかは、営業所の決めごとと所管の運輸局の扱いを確かめてから決めてください。 この構成の画像は、確認のための写しとして扱います。