仕入先から紙・PDFで戻ってくる注文請書を読み取り、品番・数量・単価・納期を発注データと照らして、食い違いと請書が戻っていない発注を購買担当へ返す

処理の起点を決める

Google Apps Script の時間主導型トリガーで、数分おきに取込フォルダを見ます。 時間主導型のトリガーは、毎分から月1回までの間隔で動かせるとされています。請書は届いた日のうちに照合します。 納期の書き直しは、早く見つけるほど生産の計画を直す余地が残ります。

未返送の洗い出しは、別のトリガーで毎朝1回動かします。 発注残の CSV が置かれた後の時刻に合わせ、発注日から決めた営業日数を過ぎても照合結果に請書の無い発注を拾います。

1回の実行で処理する件数に上限を置きます。 Apps Script の1回の実行は6分までとされています。1回に8件までとし、残りは次の実行に回します。 処理済みフォルダへ移すのは、照合結果のシートへの書き込みまで成功したときだけにします。

入力データを集める

質を決めるのは、発注残の一覧に行の番号と購買担当が入っていることです。 行の番号が無いと、同じ注文番号に同じ品番が2行あるときに比べる相手が決まりません。購買担当が無いと、食い違いを誰に返すかが決まりません。

返送の期日は、仕入先の区分で変えます。 材料の商社は翌日に戻り、小さな加工外注は1週間かかります。一律の日数にすると、未返送の一覧が毎朝同じ仕入先で埋まります。

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

読み取りは、Apps Script から Document AI の処理のAPIを呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。

納期と数量は、信頼度とあわせて取ります。 FAX で戻った「10/28」と「10/23」の違いは、生産の計画を5日動かします。信頼度の低い日付や数量は、その行を needs_review にして人に回します。

発注残の一覧は CSV を読むだけで足ります。 引く順は注文番号と行の番号が先で、行の番号が無い請書は注文番号と品番で引きます。候補が2つ以上あれば選ばず、needs_review にします。

AIへ渡す前に整形する

1. 形式の確認 … Form Parser の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP です。それ以外は PDF にします
2. ページ数の確認 … 同期処理は15ページまでです。超えるものはバッチ処理に回します
3. 解像度の確認 … 公式には、OCRの精度のためにスキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。FAX の受信の解像度を、複合機の設定でいちばん細かいものにします
4. 圧縮の確認 … JPEG のような非可逆の形式は、ファイルを小さくすると精度が落ちることがあるとされています。保存形式は PDF にします
5. 仕入先の推定 … FAX の送信元の番号、メールの差出人、1ページ目の会社名から仕入先を推定し、書式メモを引きます
6. 複数の請書の分割 … 1回の FAX で数社分が続けて届いたものは、ページで分けます
7. 重複の検知 … 同じ注文番号の請書が FAX と PDF の両方で届いたものは、後のほうに既処理の印を付けます

3番目を軽く見ないでください。 二重線と手書きの日付は、粗い FAX ではいちばん先につぶれます。書き直しが読めないと、印字の納期だけが拾われ、照合は「一致」になります。

AIに処理させる

させるのは、請書に書かれた値を、決まった項目と明細の行に写すことだけです。 比べることはさせません。

右端の列が、この構成でいちばん大事な区別です。 書かれていない項目を、発注の値や計算で埋めさせません。特に納期の書き直しは、どちらか一方に決めさせず、両方を残します。

1行目と2行目は、同じ理由でつながっています。 AIに発注の値を渡すと、かすれた「23」を「28」と読むかどうかに発注の値が影響します。 発注の値は Apps Script だけが持ち、AIには請書の読み取り結果だけを渡します。

指示内容を固定する

あなたは購買部門で、仕入先から戻ってきた注文請書を読み、
発注データと照合するための下書きを作る立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 書類が注文請書（自社の注文書の請書欄を返したものを含む）かを判断してください。
   見積書、納品書、請求書など別の書類なら、写さずに document_type を other にしてください。
2. 注文番号、請書の日付、仕入先名、引き受けの区分を写してください。
   引き受けの区分は、チェックボックスの印で決めてください。
3. 明細を1行ずつ lines に入れてください。
   品番、品名、数量、単位、単価、金額、納期、条件・備考を写します。

【厳守事項】
- 値は書類に書かれたものをそのまま入れてください。値を変えないでください。
- 計算をしないでください。単価が書かれていないときに、金額を数量で割って埋めないでください。
- 同じ欄に印字の値と、二重線で消した跡や手書きの別の値があるときは、
  printed と handwritten の両方に写し、revised を true にしてください。
  どちらが正しいかを決めないでください。
- 「下旬」「中旬」「○日頃」のような幅のある納期は、日付に直さず
  date_text に原文のまま写し、date は空にしてください。
- 品番は読み取った文字列をそのまま入れてください。
  桁を補う、似た品番に直すことをしないでください。読めなければ空にします。
- 引き受けの印がどの欄にも付いていなければ、acceptance を unknown にしてください。
- 発注の内容と合っているかどうかについて書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。

【読み取り結果（キーと値の組、表、チェックボックス、全文）】{ocr_result}
【この仕入先の書式メモ】{supplier_note}

「どちらが正しいかを決めない」を明記しないと、AIは手書きの値を採ります。 多くの場合はそれで正しいのですが、書き直しがあったという事実が消えます。 購買担当が知りたいのは、新しい日付そのものより、仕入先が日付を変えてきたことです。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、Interactions の response_format に JSON スキーマを渡すと、そのスキーマに従う応答を生成させられるとされ、enum で値の候補を限り、required で必須の項目を決められます。

{
  "document_type": "acknowledgment | other",
  "po_number": "",
  "ack_date": "",
  "supplier_name": "",
  "acceptance": "accepted | conditional | unknown",
  "lines": [
    { "line_no": "", "part_no": "", "description": "", "quantity": null, "unit": "",
      "unit_price": null, "amount": null,
      "delivery": { "printed": "", "handwritten": "", "date": "", "date_text": "", "revised": false },
      "remarks": "" }
  ],
  "evidence": [{ "field": "", "text": "", "confidence": 0 }]
}

1つ目の理由は、AIの仕事と照合の仕事を別の層に置けることです。 JSONはAIが埋め、比較と判定は Apps Script が発注残の一覧で行います。

2つ目の理由は、1行に複数の状態を持てることです。 納期も単価も違う行には、date_diff と price_diff の両方を付けます。担当者は状態の組み合わせで、仕入先に何を確かめるかが一目で分かります。 公式にも、構文として正しいJSONでも値はアプリケーションの側で検証するよう書かれています。数量×単価が金額と合わない行は needs_review にします。

システムへ連携する

生産管理システムには書き込みません。 照合の結果を受けて受領の印を付けるのも、納期を直すのも人です。未返送の催促も、仕入先へ自動では送りません。 通知は社内の購買担当にだけ送り、催促の文面と送る相手は担当者が決めます。

人が確認する

人が開くのは match 以外の行と、未返送の一覧だけです。 match のものは件数を流し見ます。全件を開く設計にすると、第10章の10.0時間には収まりません。

1. date_diff を先に見る … revised の行は請書の画像で書き直しを確かめ、生産管理の担当へその日のうちに知らせます
2. needs_review を見る … 数量・単価・日付を画像で確かめて直します
3. price_diff を見る … 単価の改定を仕入先と合意済みか確かめ、合意前なら仕入先に問い合わせます
4. 未返送の一覧を見る … 催促するか、仕入先の事情を聞くかを決めます
5. 受領の印を付ける … 確かめ終えた発注にだけ、生産管理システムで印を付けます

1番目を省かないでください。 納期の書き直しは、部品が来ない日まで誰も気づかない種類の食い違いです。

目標は、600件をならして1件1分です。 開くのは1割前後という想定で、それより多い月は、書式メモの無い仕入先が増えているか、FAX の解像度が足りていません。

例外に対処する

3行目は、自社の書式を直すだけで消える例外です。 請書欄を自社で作っているなら、○で囲む形をやめ、□に印を付ける形にします。

記録を残す

• 元の請書のファイルと、受け取った日時・経路（FAX／PDF／郵送）
• Document AI が返した Document のJSONの全文
• Gemini API に渡した書式メモの版と、返ってきたJSON
• Apps Script が付けた状態と、そのとき照合した発注残の行
• 人が状態を覆した記録と、生産管理へ知らせた日時
• 未返送の一覧に載った日と、催促した日、請書が戻った日

4つ目で「そのときの発注残」を残すのは、発注が後から変わるためです。 発注を直した後に照合結果を見直すと、当時の食い違いが無かったことになります。

最後の行は、仕入先との話し合いの材料になります。 請書が毎回遅れる仕入先が分かれば、返送の期日の決まりを変えるか、仕入先に請書の返し方を相談できます。