配送先から戻る紙の受領書を読み取り、伝票番号・受領日・受領印の有無を配達実績と突き合わせて、未回収と受領印の欠けを拾う

処理の起点を決める

スキャンした PDF が保管先（Azure Blob Storage）に入ったことを起点にします。 乗務員の帰着は夕方の1〜2時間に集中するので、事務担当はトレーにたまった受領書を数回に分けてまとめてスキャンします。スキャンのたびに処理が動き、点呼の前には前日分の結果がそろうようにします。

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

夜間に一度、その日の配達実績の CSV を取り込む処理も動かします。 受領書の読み取りは帰着した順に進みますが、未回収の判定は「その日に配達した伝票のうち、受領書が戻っていないもの」なので、配達実績がそろってからでないと出せません。 未回収の一覧は、翌朝の点呼の前の時刻にまとめて作ります。

入力データを集める

質を決めるのは、いちばん下の台帳です。 受領日の欄が無い様式の荷主に「受領日が無い」と出し続けると、事務担当は一覧を信用しなくなります。荷主ごとに「何がそろっていればよいか」を台帳に持たせ、判定はその台帳を見て行います。

配達実績は、乗務員と車両まで持たせます。 欠けと未回収の一覧を乗務員ごとに分けて出すためで、伝票番号だけでは「誰に伝えればよいか」が分かりません。

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

読み取りは、Azure Functions からカスタム ニューラル モデルを呼ぶだけです。モデルは荷主の様式をまとめて1つにし、様式の判別もさせます。 返ってきた結果から、次のものを取り出します。

信頼度は2層で見ます。 公式のページでは、カスタム モデルの項目の信頼度は「取り出した値の位置」についての確からしさで、文字の読み取り（OCR）の信頼度もあわせて見て総合するよう書かれています。伝票番号なら、項目の位置は合っていても、数字の1文字を読み違えていることがあります。項目の信頼度と単語の信頼度の両方が基準を超えたときだけ「読めた」とします。

配達実績の CSV は、配送管理システムが毎晩出すものを保管先に置き、突合の処理が読みます。照らす範囲は、配達日から7日前までにします。 受領書は配達の翌日以降に戻ることがあり、当日分だけで照らすと、遅れて戻った受領書が「該当なし」になります。

AIへ渡す前に整形する

1. ページの分割 … 1つの PDF に数十枚の受領書が入るので、1ページ1枚に分けます。複写式の伝票で2枚が重なって読み込まれたものは、寸法で見つけて人へ回します
2. 向きの確認 … 上下逆に差し込まれたページを直します
3. 寸法と解像度の確認 … 画像は50×50〜10,000×10,000ピクセル、文字の最小の高さは1024×768の画像で12ピクセル（150dpiで約8ポイント）です。複合機の既定の解像度のままにせず、200dpi以上でそろえます
4. ファイルの大きさ … 有料（S0）レベルで500MB、PDF は2,000ページまでです。夕方のスキャンはこの範囲に十分収まります
5. 白紙と裏面の除外 … 両面スキャンで出る裏面の白紙を除きます
6. 重複の検知 … 同じ伝票番号の受領書が二度読まれたら、新しい方を「二重」と印を付けて人へ回します

3番目を軽く見ないでください。 受領印は朱肉がかすれていることが多く、解像度が低いと「欄が空いている」と区別がつきません。

AIに処理させる

読み取りのモデルにさせるのは、4つの項目の値と、受領印の欄に署名（印影・サイン）があるかの検出です。 生成AIにさせるのは、備考欄の手書きを区分に分けて写すことだけです。

受領印の欄の判定は、規則で決めます。 署名の項目が高い信頼度で検出されれば present、何も検出されず、その欄の周りに文字も無ければ absent、検出はされたが信頼度が中間なら uncertain です。どこで線を引くかは、第8章の試しで決めます。

生成AIに受領印の有無を判断させない理由は、根拠を数値に置くためです。 信頼度という数値で線を引けば、線を動かしたときに何件が入れ替わるかを数えられます。

2行目がいちばん起きやすい失敗です。 伝票番号の1文字が読めないとき、配達実績に近い番号があれば「たぶんこれ」と寄せたくなります。寄せた瞬間、本当に戻っていない伝票が回収済みになり、未回収の一覧から消えます。

指示内容を固定する

あなたは運送会社の営業所で、配送先から戻った受領書の備考欄を整理する担当です。
渡すのは、受領書の備考欄から読み取った手書きの文字列だけです。
書かれていることを区分に分けて写してください。推測で補わないでください。

【区分】
- shortage ..... 数量が足りない、個数が違う、欠品の記載
- damage ....... 破損、へこみ、濡れ、汚れの記載
- refusal ...... 受け取りを断った、持ち帰りの記載
- time ......... 時間の指定、遅れ、早着の記載
- other ........ 上のどれにも当たらない記載
1つの備考に複数の記載があれば、記載ごとに分けてください。

【厳守事項】
- 原文の文字列を original にそのまま写してください。言い換えないでください。
- 数量が書かれていれば quantity に数字と単位をそのまま入れてください。
  書かれていなければ空にしてください。計算しないでください。
- 品名が書かれていれば item に写してください。書かれていなければ空にしてください。
- 読めない文字は「■」に置き換え、unreadable を true にしてください。
  前後から推測して埋めないでください。
- 受領印の有無、配達の成否、責任の所在については書かないでください。
- 備考欄が空、または印刷された文字だけの場合は、notes を空の配列にしてください。

【備考欄の読み取り結果】{remarks_text}
【読み取りの信頼度】{remarks_confidence}
【荷主の名前】{shipper_name}

「言い換えない」を明記しないと、短くまとめます。 「外箱1ケースへこみ有、中身未確認」を「破損あり」と書かれると、荷主へ返すときに中身を確かめたかどうかが分かりません。区分は付けさせても、原文は必ず残させます。

「計算しない」も同じ理由です。 「10ケース中2ケース不足」から「8ケース受領」と書き換えさせると、配送先が書いた事実ではなく、AIの計算が残ります。数量は書かれたとおりに写させ、計算が要るなら突合の処理の側で行います。

出力形式を固定する

読み取りと突合と生成AIの結果を、受領書1枚ごとに次の形のJSONにまとめます。 生成AIの部分は、Azure OpenAI の構造化出力で受け取ります。公式のページでは、response_format に json_schema を指定して strict: true にし、すべての項目を必須にして、オブジェクトに additionalProperties: false を付ける必要があるとされています。

{
  "receipt_id": "2026-10-13_A営業所_0042",
  "shipper_form": "shipper_07",
  "form_confidence": 0.93,
  "slip_no": { "value": "", "confidence": 0, "word_min_confidence": 0 },
  "delivery_match": "matched | not_found | duplicate",
  "received_date": { "status": "present | absent | uncertain | not_required", "value": "" },
  "receipt_seal": { "status": "present | absent | uncertain", "confidence": 0 },
  "notes": [
    { "category": "shortage | damage | refusal | time | other",
      "original": "", "quantity": "", "item": "", "unreadable": false }
  ],
  "verdict": "complete | missing | review",
  "driver": "",
  "delivered_on": ""
}

1つ目の理由は、status と verdict を別の層に置けることです。 receipt_seal と received_date の status は読み取りの結果をそのまま写したもので、verdict は突合の処理が荷主の様式の台帳を見て決めます。荷主との取り決めが変わっても、直すのは台帳と規則だけです。

2つ目は、乗務員ごとに分けられることです。 driver と delivered_on を持たせておけば、翌朝の一覧を乗務員ごとに並べ替えるだけで、「Aさん：昨日の3件、受領印なし」という形で渡せます。

3つ目は、未回収をこのJSONの外で出すことです。 未回収は「戻ってこなかった伝票」なので、配達実績から matched の付かなかった伝票を引き算して別の一覧にします。

【未回収の一覧（2026-10-14 朝）】
乗務員 / 配達日 / 伝票番号 / 荷主 / 配送先 / 配達からの日数

システムへ連携する

配送管理システムへは書き込みません。 回収済みの印を自動で書き戻すと、読み取りの誤りがそのまま配送管理システムの記録になります。最初の数か月は、営業所の一覧で事務担当が確かめたものだけを、これまでどおり手で入れます。

荷主へも自動では送りません。 月末の回収の一覧は書き出しまでにし、受領書の束と一緒に事務担当が返します。

人が確認する

人が開くのは missing と review のものだけです。 complete のものは、件数と乗務員ごとの内訳を一覧で見るだけにします。全件を開く設計にすると、第10章の30.0時間には収まりません。

1. review を先に見る … 伝票番号が該当なし、受領印か受領日が迷い、様式の判別が低いもの。多くは画像を見れば数秒で決まります
2. missing の根拠を画像で確かめる … 受領印の欄が本当に空いているか、受領日が本当に無いかを目で見ます。朱肉のかすれで absent になっていないかを見ます
3. 乗務員への一覧を確定する … 確かめた欠けだけを、点呼の前に乗務員ごとの一覧に載せます
4. 未回収を乗務員に確かめる … 一覧の伝票について、トレーに出し忘れていないか、車に残っていないかを聞きます
5. 判定を覆したら記録する … absent を present に直した、などを残します

2番目を省かないでください。 missing と出た受領書は、乗務員を配送先へもらい直しに行かせる理由になります。

開くのが2割を超える月は、解像度か見本が足りていません。

例外に対処する

5行目と6行目は、荷主との取り決めで決まる運用の決めごとです。

最後の行は、Azure Functions の仕組みで受けます。 公式のページでは、Blob Storage のトリガーの関数が失敗すると既定で合計5回やり直し、すべて失敗すると webjobs-blobtrigger-poison という名前のキューにメッセージが入るとされています。このキューを朝の一覧の「未処理」に出せば、読まれなかった受領書が黙って消えることはありません。 また、同じファイルを二度処理しないための受領記録（blob receipts）を持つとされているので、再処理したいときはその記録を消してやり直します。

記録を残す

• 受領書の画像（1ページ1枚に分けたもの）と、スキャンした営業所・日時
• 読み取りの結果の JSON の全文（項目・署名の項目・信頼度・単語の信頼度）
• 突合の結果（delivery_match）と、そのとき照らした配達実績の CSV の日付
• 判定（verdict）と、そのとき使った荷主の様式の台帳の版
• 人が判定を覆した記録 … どの項目を、どちらに変えたか
• 乗務員がもらい直した日と、もらい直した受領書との対応
• 荷主ごとの uncertain と absent の発生率

4つ目で「台帳の版」を残すのは、荷主との取り決めが後から変わるためです。 受領日の欄を必須にする荷主が増えると、同じ受領書の判定が変わります。当時の台帳が残っていないと、過去の判定が正しかったかを確かめられません。

最後の行は、見本を足す順番を決める材料になります。