物流センターに荷主からFAXで届く出荷指示書を読み取って出荷データにそろえ、品番の不一致と在庫不足をその日の出荷前に拾う

処理の起点を決める

インターネットFAXのPDFが受信用の保管場所に保存されたことを起点にします。 メールに届く設定のままなら、受信用のメールボックスから添付のPDFを取り出して保管場所に置く処理を1つ挟みます。FAXが届いてから数分で確認の一覧に載ることを目標にします。

1時間ごとにまとめて処理しないのは、締め時刻があるからです。 13時50分に届いたFAXを14時の処理で見ても、在庫不足を荷主に伝える時間が残りません。1枚ずつ、届いたときに処理します。

処理が終わったPDFは処理済みの場所に移します。移すのは成功したときだけにし、受信用の場所に残った数が未処理の数になるようにします。 締め前の30分は、この数を事務所の画面に出しておきます。

入力データを集める

質を決めるのは、荷主ごとの列の対応表です。 「商品コード」「品番」「貴社コード」「JAN」と、荷主によって列の見出しが違います。一度確かめた対応を荷主ごとに持っておけば、2回目からは生成AIの対応づけを照らし合わせるだけで済みます。

旧品番を品目マスタに持たせるのは、（b）の打ち間違いと荷主の書き間違いを分けるためです。 荷主が品番を切り替えたあとも、古い様式の指示書で旧品番を書いてくることがあります。旧品番の一覧に当たれば、荷主に聞かずに新しい品番へ寄せる候補を出せます。

その日の受付済みの分を差し引くのは、同じ品番が1日に何枚もの指示書に出るからです。 引当可能な在庫が10個の品番に、午前に6個、午後に6個の指示が来れば、1枚ずつ見ればどちらも足りるのに、合わせると足りません。

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

読み取りは、Azure Functions からレイアウトモデルを呼ぶだけです。

品番のセルの信頼度は、セルではなく単語から取ります。 セルの文字は単語の並びで、品番は1つか2つの単語になります。品番を作っている単語の信頼度の最も低い値を、そのセルの信頼度とします。

品目マスタと在庫は、倉庫管理システムの書き出しを30分ごとに取り込みます。締め前の1時間だけは間隔を縮めます。在庫の数字には書き出した時刻を付けて持ち、古い数字で判定したことが後から分かるようにします。

AIへ渡す前に整形する

1. 形式の確認 … レイアウトモデルの入力はPDFと画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）などです。インターネットFAXのPDFはそのまま渡します
2. ページ数とサイズの確認 … PDFとTIFFは最大2,000ページ、ファイルの大きさは有料（S0）レベルで500MBが上限です。FAXでは届きませんが、確かめる処理は入れておきます
3. 文字の大きさの確認 … 抽出できるテキストの最小の高さは、1024×768ピクセルの画像で12ピクセルです。FAXの画像では、小さな品番や小数点がこの下限に近づきます
4. 荷主の判定 … 送信元の番号で候補を決め、指示書の見出しの社名で確かめます。食い違えば、処理を止めて担当に回します
5. 送信の重複の確認 … 同じ荷主から同じ内容のFAXが短い間隔で2回届くことがあります。明細の内容が同じなら、2通目に「重複の疑い」を付けます
6. 送付状の除外 … 1ページ目が送付状だけのFAXは、表の無いページとして外します

3番目は、荷主にお願いすることでしか直りません。 下限を下回る文字は、どの読み方をしても確かには読めません。品番のセルの信頼度が低い荷主には、送信の画質の設定を上げてもらうか、文字の大きい様式に変えてもらうよう頼みます。 その材料として、荷主ごとの信頼度を記録しておきます（保存・ログ）。

5番目を省くと、同じ指示で2回出荷します。 「届いていますか」の確認のつもりで同じFAXを送り直す荷主は珍しくありません。取り込んでしまうと、ピッキングの現場では見分けがつきません。

AIに処理させる

させるのは、表の列を出荷データの項目に対応づけ、各行を出荷データの1行の形にそろえることだけです。 品番が正しいか、在庫が足りるかの判定はさせません。それはプログラムが品目マスタと在庫で行います。

右端の列の「手書きの訂正」が、（d）への答えです。 レイアウトモデルが返す手書きの行の印を使い、印刷の「5」と手書きの「3」の両方を返させます。どちらを採るかは担当が画像で確かめて決めます。 二重線がかすれて読めないことがあるので、AIに手書きを優先させる決め打ちはしません。

1行目が、いちばん起きやすく、いちばん高くつく失敗です。 生成AIに品目マスタを渡すと、読めなかった品番を「おそらく A-1023」と直して返すことがあります。品目マスタは生成AIに渡しません。 照合はプログラムが行い、AIには読めたとおりに写すことだけをさせます。

指示内容を固定する

あなたは物流センターの出荷受付の補助として、荷主から届いた
出荷指示書の読み取り結果を出荷データの形にそろえる立場です。
OCRが返した表のセルと全文だけを見てください。推測で埋めないでください。

【そろえる項目】
ship_to（届け先：名前、郵便番号、住所、電話番号）／sku（品番）／
qty（数量）／unit（単位）／delivery_date（指定日）／notes（備考）

【列の対応】
- この荷主の列の対応表が渡されたときは、それに従ってください。
- 対応表に無い見出しの列は、column_map に推測した対応を書き、
  confidence を low にしてください。

【厳守事項】
- 品番は、読み取り結果の文字をそのまま写してください。
  空白の除去と全角・半角の統一だけを行い、文字を足したり変えたりしないでください。
- 品番の一部が読めないときは、読めた部分だけを写し、sku_status を unreadable にしてください。
  「おそらく」の品番を書かないでください。
- 手書きの行の印（is_handwritten）が付いたセルが、印刷された値の近くにあるときは、
  printed_value と handwritten_value の両方に入れ、correction を true にしてください。
  どちらが正しいかを決めないでください。
- 数量に単位が書かれていないときは、unit を空にしてください。
- 指定日は書かれたとおりに写してください。「至急」「明日」「最短」を日付に直さないでください。
- 届け先の住所を補ったり、郵便番号から住所を埋めたりしないでください。
- 送付状だけのページ、表の無いページは rows に入れないでください。
- 在庫が足りるか、品番が正しいかを書かないでください。

【荷主の列の対応表】{column_map}
【表のセル（行・列・見出し・信頼度・手書きの印）】{table_cells}
【表の外の全文】{content}

「おそらくの品番を書かない」を2か所に書いているのは、片方だけでは埋めてくるからです。 「読めた部分だけを写す」と言っても、前後の文脈から最後の1桁を補った品番が返ることがあります。禁じるのは補うという行為そのもので、正しく補えたかどうかではありません。

列の対応表を渡すのは、毎回の対応づけのぶれをなくすためです。 同じ荷主の同じ様式でも、FAXの写り方で見出しの読み取りが変わります。一度担当が確かめた対応を渡し、対応表に無い列だけを推測させます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力（response_format に json_schema を strict: true で渡す方式）を使い、形を固定します。

{
  "shipper_id": "",
  "fax_id": "",
  "column_map": [
    { "header": "", "field": "", "confidence": "high | low" }
  ],
  "rows": [
    {
      "row_index": 0,
      "ship_to": { "name": "", "zip": "", "address": "", "tel": "" },
      "sku": "", "sku_status": "ok | unreadable",
      "qty": 0, "unit": "",
      "printed_value": "", "handwritten_value": "", "correction": false,
      "delivery_date": "", "date_status": "ok | ambiguous | blank",
      "notes": ""
    }
  ]
}

公式の説明では、構造化出力ではすべての項目を必須にし、additionalProperties を false にします。 値の無い項目は空の値で返させ、項目が欠けた行と、値が空だった行を区別しなくて済むようにします。

1つ目の理由は、品番の照合をプログラムの規則で行えることです。

右下の2つを分けることが、第1章で書いた「違う」と「読めなかった」の区別の実体です。

2つ目は、在庫の判定を受付の順に積み上げられることです。 行ごとの数量を、その日の受付済みの分に足していき、引当可能な在庫を超えた行から「在庫不足」の印を付けます。 どの指示から先に引き当てるかは、届いた順を既定にし、担当が変えられるようにします。

3つ目は、correction の行を必ず確認に回せることです。 手書きの訂正がある行は、品番も数量も問題が無くても確認の一覧に出します。

システムへ連携する

倉庫管理システムへの取り込みは、担当が行います。 CSVを作るところまでを自動にし、取り込みのボタンは人が押します。 取り込んだあとで誤りが分かると、引当とピッキングの指示を取り消す手間がかかるからです。

荷主への問い合わせは送りません。 確認の一覧から、荷主ごとに「品番の確認」「在庫不足」の問い合わせの文面の下書きを作ることはできますが、送るかどうかと文面は担当が決めます。

人が確認する

担当が開くのは確認の一覧だけです。 一覧の各行から、FAXの画像の該当の行に枠を付けて開けるようにします。

1. 在庫不足を先に見る … 締め時刻までに荷主へ連絡が要るものから片づけます。欠品で出すか、出荷を待つかは荷主が決めます
2. 品番の不一致を見る … unreadable は画像を見て直し、読めたのに存在しない品番は荷主に確かめます
3. 手書きの訂正を見る … 画像で二重線と書き足しを確かめ、採る値を決めます
4. 旧品番の候補を確定する … 候補が正しければ確定します
5. 問題の無い指示書を流し見る … 件数と荷主を一覧で見て、CSVを取り込みます

1番目を先にするのは、時間の制約がいちばん強いからです。 品番の不一致は画像を見れば数十秒で済むことが多いのに対し、在庫不足は荷主の返事を待つ必要があります。

目標は、1,200枚をならして1枚2分です。 確認の一覧に出る指示書が3割前後という想定で、それより多い月は、FAXの画質の悪い荷主が増えているか、品目マスタの更新が遅れています。

例外に対処する

8行目の取り消しのFAXは、自動で処理しないことに意味があります。 取り消しの対象がどの指示かは、文面だけでは決まらないことが多く、誤って別の指示を取り消すと、その出荷が止まります。

記録を残す

• FAXのPDFと、受信日時・送信元の番号
• OCRが返したJSONの全文（表のセル、単語ごとの信頼度、手書きの行の印）
• AIが返した列の対応と行のそろえの結果
• 照合に使った品目マスタと在庫の書き出しの時刻と、照合の結果
• 担当が直した記録（項目、変更前、変更後、理由）と、取り込んだ日時
• 荷主ごとの、品番のセルの信頼度の平均と、unreadable の件数

4つ目で書き出しの時刻を残すのは、在庫不足の判定を後から説明するためです。 「在庫はあったはずだ」と言われたとき、その時点の在庫の数字で判定したことを示せます。

最後の行は、荷主に送信の画質や様式の見直しを頼む材料です。 数字で示すと、頼みやすくなります。