運送会社で集荷先が手書きした送り状の控えを読み取り、届け先・個数・重量・品名を運賃計算と荷主への請求データに転記する

処理の起点を決める

毎日19時に、その日スキャンした控えをまとめて処理します。 控えはドライバーが夕方に持ち帰るので、1枚ずつ動かす必要はありません。翌朝には、前日の分の計算表と確認の一覧がそろっている形にします。

スキャンは、ドライバーごとの束を1ファイルにします。 ファイル名を「日付_ドライバー番号」にし、スクリプトがページごとに分けて、1枚の控えに日付とドライバーを付けます。 集荷の日付は控えに書かれていないことが多いので、ドライバーが持ち帰った日を集荷日とみなします。

同期の処理のページ数に合わせて分けます。 Enterprise Document OCR の同期の処理は15ページまでなので、分けた1枚ずつを渡し、束のまま渡しません。 1日分が多い日は、非同期の処理（500ページまで）にまとめる形も選べます。

入力データを集める

質を決めるのは、荷主の一覧の「重量の書き方の規則」の列です。 この列が空なら、個数が2以上の控えはすべて ambiguous_weight になります。最初の月は多く出る前提で、確認のたびに規則を埋めていきます。

荷主は、送り状に印字された荷主番号で結び付けます。 自社の様式に荷主番号を刷っておけば、手書きの荷主名を読む必要がなくなります。 番号が刷られていない白紙の様式は、荷主名を読んで照合します。

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

読み取りは、スクリプトから Document AI の処理の API を呼ぶだけです。処理のオプションで、画質の評価と言語のヒントを有効にします。

画質の評価は、8種類の不良で返ります。 公式には、書類が不良と判定されると quality/defect_blurry（ぼやけ）、quality/defect_faint（薄い）、quality/defect_text_too_small（文字が小さすぎる）、quality/defect_glare（反射）など8種類の不良の種類が返り、0.5を超える可能性が陽性の検出とされています。複写の控えで効くのは defect_faint です。公式には、この機能はスキャンや撮影した書類に向くとされ、反射（glare）の不良は局所的で、読みやすさ全体を妨げないこともあるとされています。そこで rescan に回す条件は薄さ・ぼやけ・文字の小ささに絞り、反射だけの控えは読ませて信頼度で見ます。 画質の評価は、OCRと同じ程度の処理時間が上乗せされるとされているので、夜間にまとめて動かす形と相性がよい機能です。

手書きかどうかの判定は、印字と手書きを分けるのに使います。 公式には、文字の書体の検出を有効にすると、語の単位で手書きかどうかを含む書体の属性が返ります。送り状には「重量」「個数」の欄の名前が印字されていて、手書きの語だけを値の候補にすれば、欄の名前を値として拾う誤りが減ります。

AIへ渡す前に整形する

1. 形式の確認 … Document AI の対象は PDF、TIFF、JPEG、PNG などです。複合機の設定をPDFに固定します
2. 解像度の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。複写の薄い文字を拾うため、300dpiで取ります
3. ページへの分割 … 束のファイルを1枚ずつに分け、日付とドライバー番号を付けます
4. 画質での振り分け … defect_faint や defect_blurry が陽性の控えは rescan に回し、項目に分ける処理に渡しません
5. 白紙・裏面の除去 … 文字がほとんど無いページは、裏面か白紙として外します
6. 重複の確認 … 同じ荷主番号・届け先・個数の控えが同じ日に2枚あれば、二重のスキャンの疑いとして印を付けます

4番目を省かないでください。 薄い控えでも、OCRは何かしらの文字を返します。「8」が「3」に、「15」が「16」に読まれた重量で運賃が計算されても、計算表の上では正しい形の数字に見えます。 読む前に分けるのが、いちばん確実な対策です。

AIに処理させる

させるのは、読み取り結果を送り状の項目に分けることだけです。 地域の区分、重量の解釈、運賃の計算はさせません。

重量の単位を換算しないことを、表に明記しています。 「20キロ」「20kg」「20」のように単位が無いものもあり、AIは「kg」を補いたがります。 単位が無いことも、規則の判断に使う情報です。

1行目がいちばん起きやすい失敗です。 個数が3で重量が60kgなら、AIは「1個20kg、合計60kg」と親切に両方を書きます。どちらが書き手の意図かは、控えのどこにも書かれていません。 書かれたとおりの数字だけを返させ、解釈は荷主ごとの規則か人に任せます。

指示内容を固定する

あなたは運送会社の事務員として、荷主が手書きした送り状の控えの
読み取り結果を、項目に分けて書き写す立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 次の項目を写してください。
   荷主番号、荷主名、届け先の名称・住所・電話番号、個数、重量、品名、
   支払の区分（元払い／着払い）、配達の指定
2. 印字された欄の名前（「重量」「個数」など）は値として写さないでください。
   手書きの語だけを値にしてください。
3. 1枚に複数の届け先が書かれている場合は、届け先ごとに分けてください。

【厳守事項】
- 数字は書かれたものをそのまま入れてください。読めない数字を補わないでください。
- 重量は、数字と単位を書かれたとおりに写してください。
  単位が書かれていなければ、単位は空にしてください。換算しないでください。
- 重量が1個あたりか合計かについて、判断を書かないでください。計算もしないでください。
- 住所は書かれた表記のまま写してください。地域や区分に直さないでください。
- 支払の区分は、印が付いているほうを写してください。
  両方に印がある、またはどちらにも無い場合は unclear としてください。
- 運賃や料金について、何も書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。

【読み取り結果（全文と、手書きの語の一覧）】{ocr_result}

「1個あたりか合計かについて判断を書かない」を入れるのは、AIが計算を手伝うからです。 何も言わなければ、重量の欄に「60kg（20kg×3個）」のように書きます。括弧の中の掛け算が書き手の意図と違えば、運賃が3倍か3分の1になります。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、output_config.format に json_schema の形でスキーマを渡すと、制約付きのデコードでスキーマに従う応答を返すとされています。enum と required を使え、オブジェクトの additionalProperties は false にする必要があります。

{
  "shipper_no": "",
  "shipper_name": "",
  "consignments": [
    {
      "consignee_name": "",
      "consignee_address": "",
      "consignee_phone": "",
      "pieces": "",
      "weight_value": "",
      "weight_unit": "",
      "item": "",
      "payment": "prepaid | collect | unclear",
      "delivery_note": ""
    }
  ],
  "evidence": [{ "field": "", "text": "" }]
}

金額の欄は、このJSONにありません。 運賃は Python が荷主の運賃料金表で計算し、計算に使った重量の区分・地域の区分・料金表の版を、計算表の同じ行に残します。

payment_unclear を独立させたのは、第3章の（c）のためです。 着払いを荷主に請求する誤りは、支払の区分の見落としから起きます。区分が決まらない控えは、請求データに入れる前に必ず人に見せます。

システムへ連携する

請求書の作成ソフトには、事務員が取り込みます。 スクリプトが出すのは請求データのファイルまでで、取り込む前に荷主ごとの合計を前月と並べて見る手順を置きます。前月から大きく増えた荷主は、重量の解釈の誤りを先に疑います。

着払いの分は、別の一覧に出します。 届け先から集金する分として、配達の担当に渡す一覧にし、荷主への請求データには入れません。

人が確認する

事務員が見るのは、確認の一覧に出た控えだけです。 ok の行は計算表で件数を流し見るだけにします。全件を控えと見比べる設計にすると、第10章の30.0時間には収まりません。

1. rescan を先に処理する … 濃さを上げて取り直し、それでも読めなければ荷主かドライバーに確かめます
2. payment_unclear を確かめる … 元払いか着払いかが決まらないまま請求データに入れません
3. ambiguous_weight を控えと見比べる … 荷主に確かめた結果を、荷主の一覧の重量の書き方の規則に書き足します
4. low_confidence の数字を控えと見比べる

3番目の書き足しが、この構成を育てます。 1つの荷主について規則が決まれば、その荷主の控えは次の日から ok になります。最初の月に多く出る ambiguous_weight は、規則を埋めるための材料です。

目標は、1,800件をならして1件1分です。 確認の一覧に出るのが1割台という想定で、それより多い月は、規則の未記入の荷主か、スキャンの濃さを疑います。

例外に対処する

7行目は、運賃に混ぜないでください。 2024年の改正で、運送以外の業務の対価は運賃と分けて扱う形になっています。控えの余白の「荷待ち1時間」のような書き込みは、料金の列の候補として人に見せます。

記録を残す

• 元の控えの画像と、日付・ドライバー番号・ページ番号
• Document AI が返した Document のJSONの全文（画質の評価を含む）
• Claude API に渡した読み取り結果と、返ってきたJSON
• 計算表の行ごとの、運賃の計算に使った重量の区分・地域の区分・料金表の版
• 事務員が直した値と、直した理由（重量の解釈、読み違い、支払の区分）
• 荷主の一覧の重量の書き方の規則を書き足した日と、根拠にした確認

• rescan に回した控えの割合（ドライバーごと・荷主ごと）

4つ目で料金表の版を残すのは、料金表が契約の更新で変わるからです。 月の途中で運賃が改定された荷主について、どの控えにどちらの表を当てたかを後から示せないと、請求の問い合わせに答えられません。

最後の行は、複写の紙と書き方を見直す材料になります。 特定の荷主の控えだけが薄いなら、筆圧の弱い筆記具か複写の枚数の多い様式が理由のことがあります。荷主に様式の変更をお願いするときの根拠として使えます。