農協・集荷場で生産者が手書きする農産物の出荷伝票を読み取り、品目・等級・数量・生産者を出荷台帳にそろえて、精算の元データを作る

処理の起点を決める

Apps Script の時間主導型トリガーで、10分おきに集荷場ごとのフォルダを確かめます。 公式のページでは、時間主導型のトリガーは毎分から月1回までの間隔で設定でき、実行の時刻はわずかにずれることがあるとされています。

10分おきにするのは、集荷場の担当がその日のうちに確認待ちを片づけられるようにするためです。 集荷は午前と夕方に集中し、夕方の荷の伝票は、担当が帰る前に確認待ちに出ていないと、確かめが翌日になります。 翌日には、荷はもう市場に向けて出ています。

処理が終わったPDFは「処理済み」のフォルダに移します。 移すのは出荷台帳への書き込みが終わったときだけで、フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、規格の読み替え表です。 「◎」「A」「秀」が同じ等級か、「大」がLか2Lかは、品目と部会で違います。読み替え表が無ければ、規格の確かめはすべて人に戻ります。

集荷の予定は、出荷日の確かめに使います。 集荷の無い日付や、その時期に出荷の無い品目が書かれた伝票を拾います。

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

Apps Script は、フォルダの新しいPDFを Form Parser のプロセッサに送ります。オンラインの処理は1回の要求で最大15ページなので、1枚の伝票を1つのPDFにしてスキャンします。 まとめて1つのPDFにすると、15ページを超えて1回で送れないうえ、伝票の区切りを後から探すことになります。

公式のページでは、Form Parser の表のセルの rowSpan と colSpan は常に1とされています。伝票の様式で「数量」の見出しの下に「出荷数」「受入数」の2列が並ぶ形だと、見出しの行が崩れて、どちらの列が受入数か分からなくなることがあります。 列の順番は様式で決まっているので、位置と見出しの文字の両方で列を決めるのが、次の生成AIの仕事の1つです。

生産者マスタ・規格表・読み替え表は、Apps Script がシートを読むだけです。生産者番号は文字列のまま読み、先頭の0が落ちないようにします。

AIへ渡す前に整形する

1. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。複合機の保存はPDFにそろえます
2. 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。複合機の既定の設定を300dpiにします
3. 原本の確認 … 複写式の伝票は、1枚目の原本をスキャンします。 2枚目以降の複写は字が薄く、数字の読み取りが落ちます
4. 集荷場の決定 … 保存されたフォルダから集荷場を決め、その集荷場の生産者と集荷の予定を引きます
5. 重複の確認 … 同じ生産者・出荷日・品目の伝票がすでにあれば、二重のスキャンか、同じ日の2回目の出荷かを確かめる印を付けます

3番目を軽く見ないでください。 複写の控えをスキャンすると、受入数の欄だけが原本にしか書かれていないことがあります。集荷場の担当が受入数を原本だけに書く運用なら、控えでは受入数が空として読まれ、生産者の出荷数がそのまま精算に回ることになります。

AIに処理させる

させるのは、読み取り結果を出荷台帳の項目に書かれたとおりに写すことと、表が崩れたときに列と行を決め直すことです。 生産者の引き当ても、規格の読み替えも、数の比較も、Apps Script の規則で行います。

5行目が、AIを使う理由です。 2段の見出しが崩れた表は、列の数と見出しの数が合いません。 位置と見出しの文字からどの列が受入数かを決めるのは、決まった規則では書きにくい作業です。

3行目が、この題材でいちばん起きやすい失敗です。 受入数の欄が空の行を、隣の出荷数で埋めると、集荷場で数え直していない数が精算に回ります。 空なら received_blank にして、集荷場の担当が確かめます。

指示内容を固定する

あなたは農協の営農経済センターの担当で、集荷場で書かれた
出荷伝票の読み取り結果を、出荷台帳の項目に写す立場です。
OCRが返した結果だけを見て、書かれていることを写してください。

【写す項目】
見出し：ship_date_text（出荷日。書かれたとおり）、grower_no_text、
grower_name、receipt_stamp（受付の印。present／absent／unclear）
品目の行：item_text、grade_text（等級。書かれたとおり）、
size_text（階級。書かれたとおり）、shipped_qty_text（出荷数）、
received_qty_text（受入数）、pack_text（入り数や重さ）

【厳守事項】
- 数字は書かれたとおりの文字列で写してください。
  読みにくい数字を、ありそうな数字に直さないでください。
  読めない桁があれば status を unreadable にしてください。
- 出荷数と受入数は別々に写してください。
  受入数の欄が空なら received_qty_text を空にし、status を
  received_blank にしてください。出荷数で埋めないでください。
- 等級と階級は、「◎」「A」「大」のような記号や書き方のまま
  写してください。「秀」「L」などに言い換えないでください。
- 見出しが崩れていてどの列が受入数か分からないときは、
  位置で決め、決められなければ table_broken を true にしてください。
- 二重線で消された数と書き直された数があるときは、両方を写し、
  corrected を true にしてください。
- 生産者番号と氏名が合わないように見えても、どちらも直さないでください。
- 出荷伝票でない書類と判断した場合は、document_type に種類を書いてください。

【読み取り結果】{ocr_result}

生産者マスタと規格表をAIに渡していないことが、このプロンプトのいちばんの工夫です。 マスタを見せると、読みにくい生産者番号をマスタにある番号に寄せて写します。隣の番号は、同じ部会の別の生産者であることが多いので、寄せた瞬間に別の人の出荷になります。

等級と階級を言い換えさせないのも同じ理由です。 「大」をLと言い換えるか2Lと言い換えるかは品目で違い、AIが一般的な意味で言い換えると、その品目の規格とずれます。

出力形式を固定する

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

{
  "document_type": "shipping_slip",
  "table_broken": false,
  "header": [
    { "item": "ship_date_text | grower_no_text | grower_name | receipt_stamp",
      "value": "", "status": "read | blank | unreadable" }
  ],
  "lines": [
    {
      "item_text": "", "grade_text": "", "size_text": "",
      "shipped_qty_text": "", "received_qty_text": "", "pack_text": "",
      "status": "read | unreadable | received_blank",
      "corrected": false, "previous_qty": ""
    }
  ]
}

公式のページでは、構造化出力ではすべての項目を required にする必要があるとされ、省略してよい項目は null との組み合わせで表すとされています。空欄を空文字で返させ、status で「空」と「読めない」を分けます。

1つ目の理由は、出荷台帳の列と1対1にできることです。 Apps Script は lines を規格の読み替え表で引き当て、システムの規格コードと受入数の列を足すだけで、取り込みのCSVの形になります。

2つ目は、確認待ちに回す理由を規則で持てることです。

grower_check と qty_check は、他の印より先に集荷場の担当に出します。 どちらも、誰にいくら払うかに直結するからです。出荷数と受入数が違うこと自体は珍しくなく、傷みで受け入れを減らした行もあります。印は「違う」という事実だけを示し、どちらが正しいかは集荷場の担当が決めます。

公式のページでは、拒否の応答は refusal の要素として返り、出力の上限で切れたときは status が incomplete になるとされています。どちらのときも出荷台帳に書かず、check_image で人に回すか呼び直します。

システムへ連携する

販売・精算のシステムには、この構成から書き込みません。 取り込むCSVを出すのは販売の担当で、取り込むのも販売の担当の操作です。 読み取りの誤りが、そのまま精算の数になることはありません。

生産者への問い合わせも、この構成からは送りません。 生産者に確かめるのは、顔を知っている集荷場の担当です。数の食い違いを機械の文面で知らせると、受け入れの判断を疑われていると受け取られかねません。

人が確認する

集荷場の担当が見るのは、自分の集荷場の確認待ちだけです。 販売の担当は、印の無い行と確かめの済んだ行を流し見て、取り込みのCSVを出します。

1. qty_check を先に見る … 受付の控えと荷の記憶で受入数を確かめます。傷みで受け入れを減らした行は、減らした理由も書きます
2. grower_check を見る … 伝票の画像で番号と氏名を見て、生産者に確かめます
3. spec_check を見る … 新しい書き方なら、読み替え表に足します
4. qty_unreadable と date_check を見る … 画像を開き、読めない数字は生産者か控えで確かめます
5. 確かめた値をシートに書く … 書いた行は、販売の担当の次のCSVに入ります

販売の担当の流し見では、集荷場ごと・品目ごとの受入数の合計を、集荷場の日計と比べます。 1枚ずつは合っていても、伝票のスキャン漏れがあれば合計が合いません。 合わない日は、集荷場に伝票の枚数を確かめます。

目標は、3,000件をならして1件0.6分です。 印の無い伝票は流し見で十数秒、印の付いた伝票は控えや生産者に確かめるので数分かかります。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、スキャンのしかたと伝票の様式の問題です。見出しが崩れやすいなら、伝票の様式を1段の見出しに変えることを検討します。

記録を残す

• 元の伝票のPDFと、集荷場・スキャンした日時
• OCRが返したJSONの全文と、OpenAI API の応答の全文
• 引き当てに使った生産者マスタ・規格表・読み替え表の版
• 付いた印と、集荷場の担当が確かめた結果・理由・確かめた日時
• 読み替え表に足した行と、足した日
• 集荷場ごと・生産者ごとの qty_check と unreadable の件数

3つ目で表の版を残すのは、読み替え表が新しい書き方のたびに育つためです。 精算の後で生産者から問い合わせがあったとき、どの版の読み替えで規格を決めたかが分からないと、説明ができません。

最後の行は、生産者と集荷場への相談の材料になります。 特定の生産者だけ読めない数字が多いなら、書き方の相談をします。