飲食店の店舗で手書きされるレジ締めの報告書を読み取り、本部の売上日報に転記して、POSの実績との差と過不足の多い店舗を拾う

処理の起点を決める

Google Apps Script の時間主導型トリガーで、夜間と早朝に店舗のフォルダを見ます。 時間主導型のトリガーは、毎分から月1回までの間隔で動かせるとされています。閉店の時刻は店舗で違うため、深夜から朝まで30分おきに見て、届いたものから処理します。

朝の決まった時刻に、別のトリガーで未着の一覧を作ります。 POSの日次の CSV が置かれた後、前日の報告書が届いていない店舗を拾います。経理の担当が出社したときには、催促の対象がそろっています。

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

入力データを集める

質を決めるのは、店舗マスタの釣銭準備金の額です。 報告書に書かれた釣銭準備金が決まった額と違えば、それだけで過不足の計算がずれます。読み取りの誤りか、店舗が準備金を崩したのかを分けるために、決まった額を持っておきます。

営業日の区切りの時刻も要ります。 深夜まで営業する店舗では、POSの営業日と報告書の日付が1日ずれることがあります。

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

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

手書きの数字は、信頼度とあわせて取ります。 「17,400」と「11,400」の違いは、そのまま過不足の額になります。信頼度の低い金額は、その報告書を needs_review にして人に回します。

POSの CSV は読むだけで足ります。 店舗コードと営業日で行を引きます。店舗のフォルダから店舗を決めるので、報告書に書かれた店舗名は確かめに使うだけです。

AIへ渡す前に整形する

1. 形式の確認 … Form Parser の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP です。タブレットの写真が HEIC などで保存される設定なら、JPEG で保存する設定に変えます
2. 圧縮の確認 … JPEG のような非可逆の形式は、ファイルを小さくすると精度が落ちることがあるとされています。写真を共有するときに縮小しない設定にします
3. 解像度の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。写真では、用紙が画面いっぱいに入るように撮るよう店舗に伝えます
4. 向きと傾きの確認 … 横向きや逆さの写真は、画像の縦横から向きを直してから渡します
5. 日付の確認 … 撮影の日時と、店舗の営業日の区切りの時刻から、どの営業日の報告書かの候補を決めます
6. 重複の検知 … 同じ店舗・同じ営業日の写真が2枚あれば、後のものを採り、前のものに「撮り直し」の印を付けます

2番目を軽く見ないでください。 チャットや共有の機能によっては、写真を送るときに自動で縮小します。縮小された手書きの数字は、「1」と「7」の区別からつぶれます。

AIに処理させる

させるのは、報告書に書かれた数字を、決まった項目に写すことだけです。 計算はさせません。

右端の列が、この構成でいちばん大事な区別です。 書かれていない項目を、ほかの欄やマスタの値で埋めさせません。特に実在高と過不足は、書かれていなければ空のままにします。

2行目がいちばん起きやすい失敗です。 現金の実在高の一桁がかすれた報告書を渡すと、AIは過不足が「0」になる数字を選びがちです。その瞬間、本当にあった不足が「一致」にすり替わります。 プロンプトで、ほかの欄から推し量ることを禁じます。

指示内容を固定する

あなたは飲食チェーンの本部の経理で、店舗から届いたレジ締めの報告書を読み、
売上日報に写すための下書きを作る立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 書類がレジ締めの報告書かを判断してください。
   POSのレシート、納品書、シフト表など別の書類なら、
   写さずに document_type を other にしてください。
2. 店舗名、営業日、総売上、支払方法別の額（現金、クレジット、電子マネー、
   QRコード決済、商品券）、釣銭準備金、現金の実在高、過不足、本部への入金額を写してください。
3. 金種の表を1行ずつ denominations に入れてください。
4. チェックボックスの印と、余白の書き込みを写してください。

【厳守事項】
- 数字は書かれたものをそのまま入れてください。値を変えないでください。
- 計算をしないでください。合計や差が合うかどうかを考えないでください。
- 読みにくい数字を、ほかの欄の数字から推し量って決めないでください。
  読みにくい数字は、読めた文字のまま value に入れ、unclear を true にしてください。
- 書かれていない欄は空にしてください。0と書かれているときだけ0にします。
- 現金の実在高が書かれていないときに、金種の表の和で埋めないでください。
- 釣銭準備金が書かれていないときに、決まった額で埋めないでください。
- 過不足の符号は原文の記号のまま sign_text に写してください（+、-、△、▲など）。
- 過不足の原因について書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。

【読み取り結果（キーと値の組、表、チェックボックス、全文）】{ocr_result}
【この用紙の版のメモ】{form_note}

「合計や差が合うかどうかを考えない」を書くのは、AIが自分から合わせにいくからです。 計算を禁じるだけでは、「合計に合うのはこちらの読み方」と考えて数字を選びます。読みにくいときは unclear を立てさせ、決めるのは人にします。

出力形式を固定する

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

{
  "document_type": "cash_closing | other",
  "store_name": "",
  "business_date": "",
  "sales_total": { "value": null, "unclear": false },
  "payments": {
    "cash": null, "credit": null, "e_money": null, "qr": null, "voucher": null
  },
  "float": { "value": null, "unclear": false },
  "denominations": [{ "face": 10000, "count": null, "amount": null }],
  "cash_on_hand": { "value": null, "unclear": false },
  "over_short": { "value": null, "sign_text": "", "unclear": false },
  "deposit": null,
  "checks": { "reason_written": false, "manager_checked": false },
  "notes": "",
  "evidence": [{ "field": "", "text": "", "confidence": 0 }]
}

1つ目の理由は、AIの仕事と計算の仕事を別の層に置けることです。 JSONはAIが埋め、検算と判定は Apps Script が行います。

2つ目の理由は、internal_ng と pos_diff を分けられることです。 前者は店長の計算か記入の誤り、後者はレジの操作か POS の締めの誤りで、確かめる相手が違います。公式にも、構文として正しいJSONでも値はアプリケーションの側で検証するよう書かれています。

過不足の傾向は、別のシートで集計します。 Apps Script が店舗ごとに直近30日の over_short の回数と額、曜日の偏りを毎朝出し、回数の多い順に並べます。

システムへ連携する

売上日報の確定の列と、会計システムには書き込みません。 書き込むのは下書きの列と照合結果だけです。店長への問い合わせも、自動では送りません。 未着の催促も含め、店舗への連絡は経理の担当が行います。

人が確認する

人が開くのは match 以外の行と、未着の一覧だけです。 match のものは件数を流し見て、まとめて確定の列に移します。全件を開く設計にすると、第10章の20.0時間には収まりません。

1. needs_review を先に見る … unclear の欄を写真で確かめて直します。読めなければ店長に聞きます
2. pos_diff を見る … 返品・取消がPOSに入っているか、レジの締めの時刻がずれていないかを確かめます
3. internal_ng を見る … 店長の計算違いなら、正しい値に直して店舗へ知らせます
4. over_short と過不足の集計を見る … 回数の多い店舗を、エリアの責任者へ知らせます
5. 未着の店舗に催促する

4番目で店舗の誰かを責める材料にしないでください。 この構成が出すのは回数と額の偏りだけで、原因ではありません。

目標は、1,200件をならして1件1分です。 開くのは1割前後という想定で、それより多い月は、写真の撮り方か用紙の版に問題があります。

例外に対処する

1行目がいちばん多い例外です。 撮り方の見本を1枚作って店舗のタブレットに入れておくだけで、翌月から目に見えて減ります。

記録を残す

• 元の写真と、撮影の日時・店舗のフォルダ
• Document AI が返した Document のJSONの全文
• Gemini API に渡した用紙の版のメモと、返ってきたJSON
• Apps Script が付けた状態と差の額、そのとき比べたPOSの行
• 人が値を直した記録と、店舗に問い合わせた日時と回答
• 店舗ごとの過不足の回数と額の推移

4つ目で「そのとき比べたPOSの行」を残すのは、POSの実績が後から直るためです。 締めた後の取消や会計を POS 側で直すと、翌日の CSV の数字が変わり、前日の照合の結果を説明できなくなります。

5つ目は、読み取りの弱い欄を見つける材料になります。 直した欄が毎回同じなら、その欄の升目の大きさか位置を、次の用紙の版で直します。