食材の納品書を読み取って、店舗別の仕入原価の台帳と、単価が動いた品目の記録にする

処理の起点を決める

店長が納品書を撮って店舗ごとの受付フォルダに保存したことを、15分ごとに見に行きます。 Apps Script の時間主導型トリガーは、毎分から月1回までの間隔で動かせます。15分ごとにしているのは、昼の仕込みと夜の営業の前に、その日の分が台帳に入っていれば足りるからです。

フォルダは店舗ごとに分けます。 ファイル名に店舗名を入れさせる運用は崩れます。どのフォルダに入ったかで店舗を決めれば、店長が決めることは「撮って保存する」だけです。

処理したファイルは、店舗ごとの処理済みフォルダへ移します。移すのは、台帳への書き込みまで成功したときだけです。 受付フォルダに残っている数が、そのまま未処理の数になります。

時間主導型トリガーは、作成した人のアカウントで動きます。作成は、購買の業務用のアカウントで行います。 担当者の個人のアカウントで作ると、その人が異動したときに止まります。

入力データを集める

質を決めるのは、食材の一覧の「言い換え」と「入数」の列です。 「新玉ねぎ」「玉葱」「オニオン」を同じ食材に当てはめられるのは、言い換えが書かれているからです。「1箱」を何kgと読むかも、入数が書かれていなければ決められません。

仕入先の一覧に「列の並びの癖」を持たせるのも効きます。 精肉店は「数量」の列に重さを、酒販店は「入数×ケース数」を書く、といった癖です。この一言を Gemini API への指示に添えるだけで、列の見分けの誤りが減ります。

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

Apps Script から Document Intelligence の REST API を呼びます。 受付フォルダのファイルを取り出し、prebuilt-layout に features=keyValuePairs を付けて分析を依頼し、結果のJSONを受け取ります。

信頼度は、セルではなく単語に付いています。 セルの spans と単語の位置を突き合わせ、セルに含まれる単語の信頼度のうち、いちばん低いものをそのセルの信頼度とします。平均にすると、1文字だけ読み違えた単価が埋もれます。

手書きの印も、同じく位置で突き合わせます。 styles が指す範囲に明細のセルが含まれていれば、その行を「手書きの書き込みあり」とします。Gemini API に渡す前に、この印を行に付けておきます。

食材の一覧と前回の単価は、スプレッドシートから読むだけです。 前回の単価は、店舗・仕入先・食材コードの3つで引きます。店舗を条件から外すと、別の店舗の単価と比べてしまいます。 同じ食材でも、店舗の規模で仕入の単価が違うことがあるからです。

AIへ渡す前に整形する

1. 形式と寸法の確認 … PDFまたは画像で、50×50から10,000×10,000ピクセルの間であることを確かめます
2. 向きの補正 … 横向きに撮った写真は回転させます。表の文字が傾いていると、表として認識されにくくなります
3. 1枚に複数の納品書が写っていないかの確認 … 並べて撮ったものは撮り直してもらいます
4. 重複の検知 … 同じ店舗・同じ仕入先・同じ伝票番号のものがあれば、2回目を処理しません
5. 写りの確認 … 影やピンぼけで文字が読めない写真は、読み取りの信頼度が全体に低く出ます。平均が基準を下回ったら、店長へ撮り直しを求めます
6. 仕入先の特定 … 仕入先名の項目を仕入先の一覧と照らし、列の並びの癖を取り出します

5番目を軽く見ないでください。 店舗のバックヤードは暗く、納品書は折れていることが多いです。写りが悪いまま読み取った台帳を人が直すより、その場で撮り直してもらうほうが早く終わります。 撮り直しの依頼は、処理の直後に店舗へ返すので、納品書がまだ手元にあるうちに届きます。

4番目の伝票番号は、写真を2回撮って保存したときの二重計上を止めます。

AIに処理させる

Gemini API にさせるのは3つです。表の列の役割を見分けること、品名を食材の一覧に当てはめること、訂正の書き込みがある行を見つけることです。

いちばん大事なのは、4行目の訂正の書き込みです。 印刷された数量と手書きの数量が同じ行にあるとき、どちらを採るかをAIに決めさせません。 印を付けて人に回し、担当者が画像を見て決めます。欠品や返品は、原価の数字にそのまま効くからです。

3行目がいちばん起きやすい失敗です。 単価が「1,28O」のように読み取られていると、AIは「1,280」に直して返そうとします。直した値が正しくても、読み取りの誤りがあったという事実が消え、同じ仕入先で次に起きたときに気づけません。 数字は読み取ったとおりに返させ、直すのは人です。

指示内容を固定する

あなたは飲食チェーンの本部で、仕入の台帳を作る担当です。
OCRが読み取った納品書の表を、台帳の形にそろえてください。
読み取り結果に書かれていることだけを使ってください。推測で埋めないでください。

【やること】
1. 表の各列の役割を決めてください：
   item_name / spec / quantity / unit / unit_price / amount / unknown
2. 明細の各行について、品名を下の食材の一覧から当てはめてください。
   候補を最大3つ、一致の根拠（正式名・言い換えのどれと一致したか）とともに返してください。
   当てはまらなければ no_match にしてください。
3. 数量の文字を、数値と単位に分けてください。
4. 行の種類を、item / subtotal / tax / discount / delivery_fee / unknown_row から選んでください。

【厳守事項】
- 数字は読み取り結果のとおりに返してください。
  桁を直す、「O」を「0」に直す、それらしい値に近づけることをしないでください。
  読み取りが数字として解釈できなければ、raw にそのまま入れ、value は null にしてください。
- 計算をしないでください。数量×単価や合計を求めないでください。
- 単位を読み替えないでください。「1箱」は 1 と 箱 のまま返してください。
- 手書きの印（handwritten）が付いた行、同じ行に数字が2つある行、「欠」「返」の文字がある行は、
  correction_suspected を true にし、見つかった文字をすべて correction_text に入れてください。
  どちらの数字が正しいかを選ばないでください。
- 単価が高い・安いといった評価を書かないでください。
- 納品書でない書類と判断した場合は、document_type に種類を書き、処理をしないでください。

【仕入先】{supplier_name}（系統：{supplier_category}）
【この仕入先の列の癖】{supplier_layout_note}
【食材の一覧（この系統のもの）】{item_master}
【読み取り結果の表】{table_cells}
【読み取りの信頼度と手書きの印（行ごと）】{row_flags}

「Oを0に直さない」まで具体的に書くのは、書かないと必ず直すからです。 AIは読み取りの誤りを親切に正そうとします。正しく直っても、誤りがあったことが台帳から消えるのが問題です。

食材の一覧を「この系統のもの」に絞って渡すのも意図してのことです。 全食材を渡すと、鮮魚の納品書の「かます」を乾物の「かますご」に当てはめる、といった取り違えが増えます。仕入先の系統で候補を先に絞ります。

出力形式を固定する

Gemini API の構造化出力で、スキーマを渡してJSONで受け取ります。 構文上正しいJSONが返り、スキーマでは enum で値の選択肢を縛れます。

{
  "document_type": "delivery_note",
  "columns": [ { "index": 0, "role": "item_name" } ],
  "rows": [
    {
      "row_index": 0,
      "row_type": "item | subtotal | tax | discount | delivery_fee | unknown_row",
      "item_name_raw": "",
      "item_candidates": [ { "item_code": "", "matched_by": "name | alias", "rank": 1 } ],
      "quantity": { "raw": "", "value": null, "unit": "" },
      "unit_price": { "raw": "", "value": null },
      "amount": { "raw": "", "value": null },
      "correction_suspected": false,
      "correction_text": ""
    }
  ]
}

1つ目の理由は、raw と value を分けて持てることです。 読み取った文字は raw に残り、数値として解釈できたときだけ value に入ります。value が null の行は、そのまま確認が要る行になります。 人が画像を見るときも、何と読み取られたかが分かります。

2つ目は、row_type で明細以外の行を外せることです。 小計・消費税・値引き・配送料の行を明細として台帳に入れると、原価が二重に数えられます。 値引きと配送料は、台帳の別の列に入れます。

受け取った後、Apps Script が次の規則で確認の要否を決めます。 Gemini API のドキュメントでも、構文が正しくても値はアプリケーションの側で確かめるよう書かれています。

2行目の検算を、AIではなくここで行うのが要です。 検算が合わない行は、読み取りの誤りか納品書の誤りのどちらかで、どちらも人が見るべき行です。

システムへ連携する

単価の比較の幅は、食材の一覧の区分で変えます。 時価の品目は前回との差が大きいのが普通なので、直近4週の平均との差で見ます。 定価の品目は前回と1円でも違えば記録します。乾物や調味料の少しの値上げは、この「1円でも」で拾えます。

会計システムへは書き込みません。 月末に請求書が届いたら、台帳の仕入先ごとの合計と突き合わせてから、担当者が計上します。納品書と請求書の差は、返品や値引きの処理漏れが見つかる場所です。

人が確認する

本部の担当者が見るのは、第7章「出力形式」の規則で確認に回った行だけです。 台帳の行は、確認の要らないものから順に「確定」になります。

1. 訂正の印がある行を先に見る … 画像を開き、印刷された数字と手書きの数字のどちらを採るかを決めます。迷ったら店長に電話で確かめます
2. 検算が合わない行を見る … 読み取りの誤りなら直し、納品書の誤りなら仕入先への確認の欄に印を付けます
3. 当てはまらなかった品名を見る … 新しい食材なら食材の一覧に足し、言い換えなら言い換えの列に足します
4. 単価の変動の記録を週に1回見る … 定価の品目の値上げは、仕入先に通知の有無を確かめます

3番目は、この構成が月を追って楽になる理由です。 言い換えを足すほど、次から同じ品名は当てはまるようになります。最初の1か月は no_match が多く出ますが、それは食材の一覧が育っていく途中です。

目標は、1,200枚をならして1枚1.5分です。 確認に回るのが全行の1〜2割という想定で、それを大きく超える月は、写りの悪い店舗があるか、食材の一覧の言い換えが足りていません。

例外に対処する

上の3行が、運用の最初の月に集中します。 どれもAIの問題ではなく、撮り方と納品書の書式の問題です。 手書きの納品書しか出さない仕入先は、無理に読ませずに人の入力に残すほうが早く終わります。

記録を残す

• 元の画像と、撮った店舗・保存した日時
• Document Intelligence が返したJSONの全文
• Gemini API が返したJSONと、そのとき渡した食材の一覧の版
• 確認に回った理由と、担当者が直した内容
• 訂正のどちらを採ったかと、その根拠（画像を見た／店長に確かめた）
• 単価の変動の記録と、仕入先に確かめた結果

3つ目の「食材の一覧の版」を残すのは、言い換えを足すと当てはめの結果が変わるためです。 過去の台帳の当てはめを見直すとき、当時の一覧で何が選べたかが分からないと、誤りなのか一覧の不足なのかを切り分けられません。