運送会社で運転者が毎日書く日常点検表を読み取り、「否」や異常の記載があるまま運行した車両と記入漏れを、運行管理者と整備管理者へ出す

処理の起点を決める

1日2回の定時実行にします。 点呼が集中する早朝の便が出そろった時間帯と、夕方の帰庫が落ち着いた時間帯です。事務担当がその前にスキャンを終え、取り込みフォルダに置いておきます。

ファイル保存のたびに動かす形にしない理由は、点呼の記録との突き合わせにあります。 点検表を読んだだけでは「運行したか」が分からず、その日の点呼の記録がそろってから照らす必要があります。定時に、その時点までの点検表と点呼の記録をまとめて照らすほうが、取りこぼしが出ません。

処理を終えたファイルは処理済みフォルダへ移し、移すのは成功したときだけにします。 取り込みフォルダに残っている数が、そのまま未処理の数になります。加えて、前日分の突き合わせを翌朝にもう一度回します。 夕方以降に戻った車両や、遅れて出てきた点検表を拾うためです。

入力データを集める

質を決めるのは、項目マスタと可否判断の記録の2つです。 項目マスタが無ければ、「表の3行目の否」が何の項目かを機械が知りようがありません。可否判断の記録が無ければ、整備管理者が口頭で「このまま出してよい」と判断した車両まで、毎朝一覧に載り続けます。

点呼の記録は、運行の事実の根拠として使います。 貨物自動車運送事業輸送安全規則は、乗務前の点呼で日常点検の実施またはその確認について報告を求め、確認を行うことを定め、点呼の記録を1年間保存することを求めています。「その日にその車両が運行したか」を、点呼の記録で決めます。

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

点検表： 複合機で束ごとスキャンし、1ファイルに複数枚が入ったPDFとして保存します。ファイル名に営業所コードとスキャン日時を入れます。1ページに1枚の点検表が入る前提で、ページごとにOCRの結果を分けて扱います。

OCRの呼び出し： モデルIDは prebuilt-layout です。結果のうち、次の4つを使います。

選択マークと表を結び付けるのは span です。 選択マークは文書の全文の中での位置（offset と length）を持ち、表のセルも同じ全文の中の位置を持ちます。位置が重なるセルを探せば、その印がどの行のどの列にあるかが決まります。 行番号を項目マスタで項目コードに変えれば、「ブレーキのきき具合が否」という形になります。

点呼の記録と可否判断の記録： どちらも表から日付と車両で読み取るだけです。読み取りだけで、書き込みはしません。

AIへ渡す前に整形する

1. ページの向きの補正 … pages の angle を見て、傾いたページは結果の座標を補正して扱います
2. 様式の確認 … ページの見出しに点検表の固定の文言があるかを見ます。別の書類（運転日報、伝票）が混ざったページは、点検をせずに取り分けます
3. 画像と文字の大きさの確認 … 画像の寸法は50 × 50 ピクセルから10,000 × 10,000 ピクセルの間である必要があります。記入欄の文字が小さいので、スキャンの解像度を下げないように複合機の設定を固定します
4. 車両番号の名寄せ … 書かれた文字列から数字の並びを取り出し、車両台帳の登録番号と社内の車番の両方で引きます。候補が1台に絞れないときは確定させず、vehicle_unresolved として残します
5. 日付の解釈 … 「10/7」「7日」のような書き方を、スキャン日と営業所の稼働日から年月日に直します。スキャン日より後の日付、2日以上前の日付は確認に回します
6. 重複の検知 … 同じ車両・同じ日の点検表が2枚あれば、両方を残して確認に回します。どちらかを捨てると、書き直した理由が消えます

4番目を軽く見ないでください。 名寄せに失敗した点検表は、点呼の記録と突き合わせられず、「点検表なし」の誤報と「誰のものでもない異常の記載」の2つを同時に生みます。

AIに処理させる

この構成には性質の違う2つのAI処理が入ります。1つ目はOCRで、選択マークの状態と手書きの文字を読みます。2つ目は生成AIで、異常の内容欄の自由記述を部位と区分に整理します。良／否の判定と、点呼の記録との突き合わせは、どちらのAIにもさせず、スクリプトで行います。

右端の列が、この構成でいちばん大事な区別です。 未記入 は運転者に確かめること、読取不可 はスキャンをやり直すか紙を見ることで、どちらも 否 とは扱いが違います。 何も検出されていなければ 未記入、検出されていて信頼度が低ければ 読取不可。根拠をOCRが返した状態と信頼度に置きます。

チェック欄と記入欄が食い違うものは、両方を残します。 全項目が 良 で、異常の内容欄に記述がある点検表は、checks は 良 のまま、free_text_present を真にして一覧に載せます。どちらかを正として書き換えると、第3章の（b）が機械の中で再現されます。

3行目がいちばん起きやすい失敗です。 他の項目がすべて「良」だと、印の無い1行も「良」と読みたくなります。埋めた瞬間に、点検の記入漏れが記録から消えます。

指示内容を固定する

生成AIに渡すのは、異常の内容欄の記述と、その点検表の車両の区分だけです。運転者名は渡しません。

あなたは運送会社の整備管理者を補佐する立場です。
日常点検表の「異常の内容」欄に運転者が手書きした記述（OCRの結果）を渡します。
記述を整理し、整備管理者が読む順番を決めるための区分を付けてください。
運行させてよいかの判断は整備管理者が行います。あなたは判断をしません。

【やること】
1. 記述を、部位ごとの項目に分けてください（1つの記述に複数の部位があれば分ける）
2. 部位は次の中から選んでください：
   ブレーキ／タイヤ・ホイール／かじ取り／灯火装置／原動機／
   バッテリー・電気／ワイパー・ウォッシャ／エアタンク／車体・その他
3. 各項目に、区分を次の中から付けてください：
   走行関係 … ブレーキ、タイヤ、かじ取り、灯火装置など、走行や合図にかかわる記述
   その他   … 外装の傷、室内の汚れなど、走行にかかわらない記述
   要確認   … どちらか決められない記述
4. 記述の原文を quoted_text にそのまま写してください

【厳守事項】
- 記述に書かれていない症状、部位、原因を足さないでください。
  「ブレーキが少し甘い」から「ブレーキ液の不足」を導かないでください。
- 「運行可」「運行不可」「整備が必要」「様子見でよい」に当たることを書かないでください。
- 読めない文字は □ のまま残してください。補って言い換えないでください。
- 「特になし」「異常なし」と同じ意味の記述は、items を空にして
  no_defect_statement を true にしてください。
- 迷った場合は区分を「要確認」にしてください。
  「その他」に寄せて目立たなくすることはしないでください。
- 数値（空気圧、距離など）は、記述にある値をそのまま写してください。

【車両の区分】{vehicle_class}
【異常の内容欄の記述（OCRの結果）】{free_text}
【記述の読み取りの信頼度】{free_text_confidence}

「迷ったら要確認、その他に寄せない」を書くのは、区分が一覧の並び順になるためです。 「その他」に入った記述は一覧の下に回り、読まれるのが遅れます。 判断に迷う記述ほど上に出すほうが、取り違えたときの害が小さくなります。

「整備が必要」と書かせない制約も外さないでください。 生成AIは親切に「点検を推奨します」と書き足します。それが一覧に載ると、整備管理者の判断の前に結論があるように読めてしまいます。

出力形式を固定する

点検表1枚ごとに、次の形のJSONを作ります。 checks はOCRの結果からスクリプトが作り、defects は生成AIが返し、flags は突き合わせのあとにスクリプトが付けます。

{
  "sheet_id": "S01-20261007-0612-p14",
  "inspection_date": "2026-10-07",
  "vehicle": { "written": "12-34", "vehicle_code": "T-031", "resolved": true },
  "checks": [
    { "item_code": "BRK-01", "item_name": "ブレーキのきき具合",
      "status": "良 | 否 | 未記入 | 読取不可",
      "mark_confidence": 0.98, "page_polygon": [] }
  ],
  "free_text_present": true,
  "defects": {
    "no_defect_statement": false,
    "items": [
      { "part": "タイヤ・ホイール", "category": "走行関係 | その他 | 要確認",
        "quoted_text": "左後輪 空気圧 低め" }
    ]
  },
  "flags": {
    "operated": true,
    "decision_recorded": false,
    "result": "operated_with_defect | missing_sheet | unreadable | ok"
  }
}

生成AIの部分は構造化出力で受け取ります。Claude API では output_config の format に type: "json_schema" とスキーマを指定し、part と category を enum で固定します。 返るJSONはスキーマに沿うことが保証され、部位の書き方がそろうので、車両ごと・部位ごとの件数を数えられます。

ただし、スキーマで書けないことがあります。 数値の範囲（minimum、maximum）と文字列の長さの制約は使えません。走行距離計の値の妥当性は、スキーマではなくスクリプトの側で確かめます。

status と result を別の層に置くのが要です。 status は読み取りの事実、result は運行の事実と組み合わせた結果です。可否判断の記録が後から入れば、status を触らずに result だけが変わります。

システムへ連携する

点呼の記録にも車両台帳にも書き込みません。 この構成が出すのは確認の一覧までで、点呼の記録は運行管理者が、可否判断の記録は整備管理者が、それぞれの責任で書くものです。 機械が書き足すと、誰が確かめたのかが記録から分からなくなります。

通知は2系統に分けます。operated_with_defect は整備管理者と運行管理者の両方へ、missing_sheet は運行管理者へ。 同じ一覧を全員に送ると、互いに相手が見たと思って誰も開きません。

人が確認する

人が開くのは、result が ok 以外の点検表だけです。

1. operated_with_defect を最初に見る（整備管理者） … 一覧の quoted_text と、点検表の画像の該当行を見ます。車両の状態を現物で確かめ、判断を記録します
2. unreadable を見る（事務担当） … 紙の原本を見て、良 ／ 否 ／ 未記入 を人が付け直します。付け直したら、もう一度突き合わせに回します
3. missing_sheet を見る（運行管理者） … 運転者に確かめ、出し忘れなら回収します。点検をしていなかったのか、紙を出し忘れたのかを分けて記録します
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

1番目で整備管理者が見るのは、AIの結論ではなく、印と記述の原文です。 一覧の上の段には画像の切り抜きを置き、整理した区分は横に添えるだけにします。選択マークと単語には多角形の座標が付いて返るので、その行だけを切り出して並べられます。

目標は、1,200枚をならして1枚0.5分です。 一覧に載るのは1割前後という想定で、それより多い月は、unreadable が増えているか、名寄せに失敗しています。

例外に対処する

上の4行が大半を占めます。 どれもAIの精度の問題ではなく、紙の書き方と、台帳の整い方の問題です。 車両番号の書き方を様式で固定する（あらかじめ印字した点検表を車両ごとに置く）ほうが、名寄せの工夫より効きます。

記録を残す

• スキャンした原本のPDFと、取り込んだ日時・営業所
• OCRが返したJSONの全文（選択マーク、表、単語、手書きの判定）
• 項目ごとの判定（checks）と、そのとき使った項目マスタの版
• 生成AIに渡した記述と返った整理（defects）
• 突き合わせの結果（flags）と、そのとき参照した点呼の記録と可否判断の記録の内容
• 人が判定を覆した記録 … どの項目を、どちらに変えたか
• 一覧を送った日時と、誰が開いて何を記録したか

5つ目で参照した記録の中身を残すのは、記録が後から足されるためです。 整備管理者が判断を後から書き足すと、過去の一覧の意味が変わります。当時なにが見えていたかが残っていないと、確認が遅れたのか記録が遅れたのかを区別できません。