社有車の運転日報と給油伝票を読み取って、車両別の費用と点検期限の台帳にする

処理の起点を決める

共有フォルダへのファイル追加を起点にします。 スキャンしたPDFが置かれた時点で処理が始まり、週1回の運用を想定します。

月末の一括処理にしない理由は2つあります。1つ目は（a）の集中をなくすためで、週ごとなら確認待ちは1回20枚から30枚です。2つ目は、距離計の検算が「前回の値」を必要とするためです。 同じ車両の日報を日付順に処理するので、取り込み時に車両番号と日付で並べ替えてから検算に回してください。取り込み・登録・確認待ちの枚数を毎回記録し、合計が合わない回を検知します。

入力データを集める

この構成の質を決めるのは、車両マスタの整備です。 車両番号だけでは足りず、燃料の種類と想定燃費の範囲を車種ごとに持つことが前提で、無いと燃費の検算ができません。期限の設定表も、運行管理や整備の担当者が先に記入します。 AIに埋めさせると、法令の解釈を機械に肩代わりさせます。

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

日報と伝票： 拠点のスキャナで、1運行につき1枚のPDFとして出力します。ホチキスで留まった伝票は、別ページとして同じPDFに入れてかまいません。ファイル名に拠点コードとスキャン日を入れ、元のファイルは処理後も残します。 確認待ちの一覧から画像を開くためです。

マスタ類： 表計算ソフトの別シートから読みます。車両の入れ替えは年に何度も起きるので、スクリプトに車両の一覧を書かないでください。

前月までの実績： 台帳から、車両ごとの最終の距離計の値と最終運行日を取ります。これが検算の基準になるので、1枚処理するごとに更新してください。 なお車検の満了日は車検証の日付を人が入力します。日報に車検の情報は無いので、OCRからは取りません。

AIへ渡す前に整形する

1. 帳票の種類の判別 … 1つのPDFに日報と伝票が混ざるので、ページごとに分けます。段落のロール（title、sectionHeading など）と様式の固定文言の有無で判別できます。 判別できないページは確認待ちに回します
2. 向きとサイズの確認 … pages の回転角で補正します。 寸法とファイルサイズが条件を外れたファイルはOCRに投げず、拠点にやり直しを依頼します
3. 車両番号と運転者名の照合 … 1文字違いの候補が複数あるときは確定させずに確認待ちにします。台帳に書き込むのは社員番号で、氏名を台帳の行に持たなければ外部に渡る範囲を絞れます
4. 前回の基準値の取得 … その車両の最終の距離計の値を台帳から取ります。値が無い車両（新車、初回）は検算をせず、全項目を確認待ちにします

AIに処理させる

この構成には性質の違う2つのAI処理が入ります。混ぜないでください。1つ目はOCRで、画像から項目と値と信頼度を取ります。読むことだけをさせ、値の正しさは判断させません。2つ目は生成AIで、「異常」欄の自由記述を部位・症状・緊急度に整理し、整備依頼の下書きと申し送り文を作ります。検算はどちらにもさせず、集計側で行います。

表の4行目が「AIに法定の期限を判断させない」です。 点検の間隔は車両の用途と使われ方で決まります。AIに聞けばもっともらしい月数が返りますが、自社の車両に当てはまるかは別です。 設定表に無い区分が出たら、計算せずに止めて人に聞いてください。なお緊急度の区分（即時／今週中／次回点検時／記録のみ）は整備の可否判断ではなく、人が読む順番を決める印です。

指示内容を固定する

あなたは社有車の運転日報を読む車両管理担当者を支援する立場です。
日報の「異常」欄に書かれた記述と、その車両の情報を渡します。
記述を整理し、整備工場へ出す依頼文の下書きを作ってください。
この下書きは担当者が読んで、出すかどうかを判断したうえで送信します。

【厳守事項】
- 記述に書かれていない症状、部位、原因を足さないでください。
  「エンジン音が大きい」から「エンジンオイルの不足の可能性」を導かないでください。
  原因の推定は、整備工場が現物を見て行うことです。
- quoted_text には日報の記述をそのまま引いてください。
  言い換え、要約、誤字の修正をせず、読めない文字は □ で残してください。
- 渡した数値以外の数を書かないでください。
  走行距離、車両番号、日付は、渡した値をそのまま使ってください。
- urgency は、記述に書かれた内容だけから決めてください。
  走行に直接かかわる記述（走行中に異音、ブレーキの効きが悪い）は即時、
  断定されていない記述（気がする、たまに）は今週中、
  走行にかかわらない記述（外装の傷、内装の汚れ）は次回点検時、
  「特になし」と同等の記述は記録のみ としてください。
  迷う場合は、緊急度を下げずに needs_human_attention を true にしてください。
- 整備の要否、部品の交換の要否、費用の見込み、車検や点検の時期を書かないでください。
  依頼文は「この記述があったので見てほしい」までにとどめてください。
- 運転者名を依頼文に書かないでください。渡していませんし、伝える必要もありません。

【車両情報】{vehicle}
【運行情報（日付・走行距離）】{trip}
【異常欄の記述（OCRの結果）】{defect_text}
【記述の読み取りの信頼度】{defect_confidence}

「原因を導かない」がいちばん効く制約です。 原因の推定が入ると、整備工場がそこから見始めます。ドライバーが書いたのは症状であって診断ではありません。 「読めない文字を □ で残す」も必要で、欠けた部分を生成AIが補うと、書かれていない症状が依頼文に載ります。

出力形式を固定する

生成AIの出力は構造化出力で固定します。Claude API では output_config の format に type: "json_schema" とスキーマを指定します。

{ "type": "object", "additionalProperties": false,
  "required": ["report_id","vehicle_no","trip_date","defect_items",
               "request_draft","needs_human_attention"],
  "properties": {
    "report_id":   { "type": "string" },
    "vehicle_no":  { "type": "string" },
    "trip_date":   { "type": "string", "format": "date" },
    "defect_items": { "type": "array", "minItems": 0,
      "items": { "type": "object", "additionalProperties": false,
        "required": ["part","symptom","quoted_text","urgency"],
        "properties": {
          "part":    { "type": "string",
            "enum": ["タイヤ","ブレーキ","エンジン","電装","車体","内装","その他"] },
          "symptom": { "type": "string" },
          "quoted_text": { "type": "string" },
          "urgency": { "type": "string", "enum": ["即時","今週中","次回点検時","記録のみ"] } } } },
    "request_draft": { "type": "string" },
    "needs_human_attention": { "type": "object", "additionalProperties": false,
      "required": ["flag","reason"],
      "properties": { "flag": {"type":"boolean"}, "reason": {"type":"string"} } } } }

返るJSONがスキーマに一致するため、スキーマ違反による再実行が要りません。 また enum で語彙を固定できるので、「右前タイヤ」「フロントタイヤ」「前輪」が混ざらず、部位ごとの件数が数えられます。

ただし、スキーマで書けないことがあります。 数値の制約（minimum、maximum、multipleOf）と文字列の長さの制約はサポートされていません。配列の minItems は0か1だけ、再帰的なスキーマと外部の $ref も使えません。この制限は、この構成にはむしろ好都合です。 「距離計の値は前回以上であること」をスキーマに書けないということは、検算をスキーマに任せられないということで、集計側で行うという設計がそのまま正解になります。

なお、文法のコンパイルは最初の要求で時間がかかり、24時間キャッシュされます。 構造を変えると無効になるので、スキーマを毎回作り直す組み方をしないでください。

OCRの側は fields（項目名・値・confidence・手書きの判定）と checks（ルール名と pass / fail / skip）を分けて持ち、確認待ちの一覧では2つを並べます。 「信頼度0.98だが検算に落ちた」と「信頼度0.42で検算していない」では、直し方が変わるためです。

システムへ連携する

台帳に書き込むのは、検算を通った行だけです。 確認待ちを先に入れると直し忘れが集計に混ざります。

人が確認する

人が見るのは、検算に落ちた行と、信頼度が低い項目だけです。 全600枚を見るなら手入力と変わりません。確認待ちに回す条件は次の3つです。

1. 検算のいずれかが fail になった行
2. 項目の信頼度が、決めたしきい値を下回った項目
3. 車両番号または運転者名がマスタと照合できなかった行、帳票の種類を判別できなかったページ

確認は、距離計の検算に落ちた行、給油伝票と合わない行、信頼度が低い項目、needs_human_attention が真のもの、の順です。作業は元の画像を開いて、その項目だけを読み直すことです。レイアウトモデルは項目ごとに境界のポリゴン座標を返すので、その座標で切り出した画像を確認画面に出せます。しきい値は最初の1か月の実測で引き直してください。

例外に対処する

最初の2行がいちばん大事です。 距離計の値が読めなかったとき前後から埋めたくなりますが、埋めた瞬間に「検算を通った正しい値」として台帳に入ります。 給油伝票の行も先に決めておく必要があります。伝票は機械が印字したもの、日報は人が手で書いたもので、どちらを正とするかが決まっていないと月ごとに扱いが変わります。

記録を残す

• 取り込んだPDFの原本（確認待ちから開ける）
• OCRが返した項目・値・信頼度・手書きの判定と、検算の結果（pass / fail / skip）
• 人が直した項目と、直す前の値と直した後の値
• 生成AIに渡した記述と下書き。実際に送った整備依頼と、送らなかったもの
• 月ごとの枚数（取り込み、登録、確認待ち、未処理）

4つ目が、この構成を良くしていく記録です。 「帰着時の距離計だけが直されている」なら、直すのは紙です。