倉庫に荷主・仕入先からFAXで届く手書きの入庫予定表を読み取り、品番・数量・入庫日を入庫予定データにそろえて、読み取れない項目を担当に返す

処理の起点を決める

Apps Script の時間主導型トリガーで、5分おきに入荷受付専用のメールアドレスを確かめます。 公式のページでは、時間主導型のトリガーは毎分から月1回までの間隔で設定でき、実行の時刻はわずかにずれることがあるとされています。インストール型トリガーの一覧にメールの受信を起点とするものは無いので、一定の間隔で新しいメールを探す形にします。

5分おきにするのは、翌日の入庫予定が夕方に集中して届くためです。 差し戻しが窓口の担当に届くのが遅れると、仕入先の担当者が退社した後に問い合わせることになり、確かめが翌朝、つまり入庫の当日になります。

メールの探し方は GmailApp.search で、転送元のアドレスと「処理済み」のラベルが無いことを条件にします。 ラベルは受付待ちのシートへの書き込みが終わったときだけ付けます。途中で止まったメールは次の実行で拾い直され、「処理済み」の付いていないメールの数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、送り主の一覧です。 予定表の送り主の欄は、手書きの社名か、ゴム印か、空欄のこともあります。送信元のFAX番号から仕入先と荷主が決まれば、品番の対応表のどの行を使うかが決まります。 番号が一覧に無い送り主は、品番の引き当てができないので、最初に差し戻します。

受付の決まりの表は、日付の確かめに使います。 休業日の入庫や、前日の締切を過ぎて届いた翌日の入庫を拾います。

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

Apps Script は、メールに付いたPDFをドライブの「受付」フォルダに保存し、Form Parser のプロセッサに送ります。オンラインの処理は1回の要求で最大15ページなので、ふつうの予定表は1回で足ります。

公式のページでは、Form Parser の表のセルの rowSpan と colSpan は常に1とされています。品名が2行にまたがって書かれた予定表は、2行目が品番と数量の空いた行として返ります。 これを前の行の続きとしてつなげるのが、次の生成AIの仕事の1つです。

品目マスタ・品番の対応表・送り主の一覧は、Apps Script がシートを読むだけです。品番は文字列のまま読み、先頭の0が落ちないようにします。

AIへ渡す前に整形する

1. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。転送はPDFにそろえます
2. 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。読めない項目の多い送り主には、高画質での送信か、PDFのメール添付をお願いします
3. 送り主の決定 … 送信元のFAX番号を送り主の一覧で引き、仕入先と荷主を決めます
4. 送り状の除外 … 1枚目の送り状は、読み取りの対象から外します
5. 重複の確認 … 同じ送り主から同じ入庫予定日の予定表が短い間隔で2通届いたら、再送か訂正かを確かめる印を付けます
6. 訂正の確認 … 「訂正」「変更」と書かれた予定表は、前の予定表と並べて担当に回します

3番目を先に行うのは、予定表の送り主の欄がいちばん読みにくい欄だからです。 ゴム印はFAXでつぶれ、社名が略称で書かれることもあります。FAX番号は送信の記録として確実に残るので、そちらで決めます。

AIに処理させる

させるのは、読み取り結果を入庫予定データの項目に書かれたとおりに写すことと、表が崩れたときに行をつなぎ直すことです。 品番の引き当ても、単位の換算も、日付の確かめも、Apps Script の規則で行います。

4行目が、AIを使う理由です。 納品書の控えを流用した予定表では、品名が2行になり、表の行の数と品目の数が合いません。 位置と全文からどの行がどの品目の続きかを決めるのは、決まった規則では書きにくい作業です。

3行目が、この題材でいちばん起きやすい失敗です。 「10」とだけ書かれた行を、他の行に合わせてケースと読むか、バラと読むかで、数量が入数の倍だけ変わります。 書かれていなければ unit_blank にして、Apps Script が品目マスタの入数と前回の入庫の単位を並べ、窓口の担当が確かめます。

指示内容を固定する

あなたは物流センターの入荷受付の担当で、FAXで届いた入庫予定表の
読み取り結果を、入庫予定データの項目に写す立場です。
OCRが返した結果だけを見て、書かれていることを写してください。

【写す項目】
見出し：shipper_text（荷主名）、arrival_date_text（入庫予定日。書かれたとおり）、
weekday_text（曜日）、time_slot（時間帯）、vehicle（車両）
明細：item_code_text（品番。書かれたとおり）、code_type（supplier／shipper／jan／unknown）、
item_name、qty_text（数量）、unit_text（単位。書かれたとおり）、lot、best_before

【厳守事項】
- 数字は書かれたとおりの文字列で写してください。
  読みにくい数字を、ありそうな数字に直さないでください。
  読めない桁があれば status を unreadable にしてください。
- 品番は書かれたとおりに写してください。ハイフンや桁を補わないでください。
- 単位が書かれていない行は unit_text を空にし、status を unit_blank に
  してください。他の行の単位に合わせないでください。
- 日付は書かれたとおりに写し、曜日が書かれていれば weekday_text に写して
  ください。日付と曜日が合わなくても、どちらも直さないでください。
- 「来週火曜」のように日付が書かれていない場合も、書かれたとおり写してください。
- 品名が2行に分かれ、2行目の品番と数量が空のときは、前の行の続きとして
  つなげてください。つなげられなければ table_broken を true にしてください。
- 二重線で消された数量と書き直された数量があるときは、両方を写し、
  corrected を true にしてください。
- 入庫予定表でない書類と判断した場合は、document_type に種類を書いてください。

【読み取り結果】{ocr_result}

品目マスタをAIに渡していないことが、このプロンプトのいちばんの工夫です。 マスタを見せると、読みにくい品番をマスタにある品番に寄せて写します。似た品番は、色違いやサイズ違いの別の商品であることが多いので、寄せた瞬間に別の商品の入庫予定になります。

日付と曜日を別々に写させているのも同じ理由です。 片方だけを写させると、AIは合わないほうを黙って捨てます。両方を残しておけば、Apps Script が暦で照らして食い違いを拾えます。

出力形式を固定する

次の形のJSONで受け取ります。 OpenAI API の構造化出力（Responses API の text.format に type: "json_schema" と strict: true を指定する方式）を使い、形を固定します。

{
  "document_type": "inbound_schedule",
  "revision": false,
  "table_broken": false,
  "header": [
    { "item": "shipper_text | arrival_date_text | weekday_text | time_slot | vehicle",
      "value": "", "status": "read | blank | unreadable" }
  ],
  "lines": [
    {
      "item_code_text": "", "code_type": "supplier | shipper | jan | unknown",
      "item_name": "", "qty_text": "", "unit_text": "",
      "status": "read | unreadable | unit_blank",
      "lot": "", "best_before": "", "corrected": false, "previous_qty": ""
    }
  ]
}

1つ目の理由は、倉庫管理システムに取り込むCSVの列と1対1にできることです。 Apps Script は lines を品目マスタで引き当て、荷主の品番とバラの数量に直した列を足すだけで、取り込みのCSVの形になります。

2つ目は、差し戻しの理由を規則で持てることです。

date_conflict と slot_check は、他の印より先に窓口の担当に出します。 日付が決まらない予定表は、バースと人員の段取りに入れられず、トラックが予定外の日に着く原因になります。

公式のページでは、拒否の応答はスキーマに従うとは限らず、そのときは output_text ではなく refusal の要素が返るとされています。応答の要素の種類を見て、refusal なら受付待ちに書かずに check_image で人に回します。 status が incomplete（出力の上限で切れた）のときも、シートに書かずに呼び直します。

システムへ連携する

倉庫管理システムには、この構成から書き込みません。 取り込むCSVを出すのは受付の担当で、取り込むのも受付の担当の操作です。 読み取りの誤りが、そのまま検品の予定になることはありません。

仕入先への問い合わせも、この構成からは送りません。 窓口の担当が文面を使いたいときは、GmailApp.createDraft で下書きを作るところまでにします。

人が確認する

受付の担当が見るのは、印の無い予定表の流し見だけです。 件数・品目数・合計数量を見て、取り込みのCSVを出します。印の付いた行は、窓口の担当の差し戻しの一覧に移っています。

1. date_conflict と slot_check を先に見る … 送り主に日付と時間帯を確かめます。曜日と日付のどちらが正しいかは、推測で決めません
2. qty_unreadable を見る … 写しの該当箇所を開き、読めない数字は仕入先に聞き直します
3. unit_check を見る … 品目マスタの入数と前回の入庫の単位を見比べ、ケースかバラかを送り主に確かめます
4. item_unknown と sender_unknown を見る … 新しい品目か新しい送り主かを荷主に確かめ、対応表と送り主の一覧に足します
5. 確かめた値を受付待ちのシートに書く … 書いた行は、受付の担当の次のCSVに入ります

目標は、600件をならして1件1.5分です。 印の無い予定表は流し見で数十秒、印の付いた予定表は仕入先に確かめるので数分かかります。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題ではなく、FAXの画質と、仕入先ごとの書式の問題です。

記録を残す

• 元の予定表のPDFと、受信日時・送信元のFAX番号
• OCRが返したJSONの全文と、OpenAI API の応答の全文
• 引き当てに使った品目マスタと対応表の版
• 付いた印と、窓口の担当が確かめた結果・送り主とのやり取り・確かめた日時
• 対応表と送り主の一覧に足した行と、足した日
• 送り主ごとの qty_unreadable と unit_check の件数

3つ目で品目マスタの版を残すのは、マスタが荷主の新商品のたびに変わるためです。 どの版で「見つからない」と判断したかが残っていないと、検品で予定に無い品番が出たとき、マスタの遅れか読み取りの誤りかを区別できません。

最後の行は、仕入先との相談の材料になります。 特定の仕入先だけ読めない数字が多いなら、FAXの画質か書式に理由があります。