飲食店の店舗から届く小口現金の出金報告とレシートの写真を読み、小口現金の台帳にそろえて、領収書の欠けと食い違いを拾う

処理の起点を決める

フォームの回答がシートに入ったことを起点にします。 スプレッドシートのインストール型のフォーム送信のトリガーを、経理課の共有のアカウントで1つ作ります。1件ずつ動くので、店長が報告した数分後には台帳に入ります。

月末の照合は、別に時間主導型のトリガーを置きます。 毎月1日の朝に、前月分の照合を走らせます。公式のページでは、時間主導型のトリガーの時刻は少しずれることがあり、9時に設定すると9時から10時のあいだで動くとされています。経理の始業に間に合えば足ります。

フォーム送信のトリガーが失敗したときに備え、1日1回の拾い直しも置きます。 回答のシートに「処理済み」の列を足し、空の行を朝にまとめて処理します。API が一時的に応答しなかった回答も、ここで拾われます。 公式のページでは、トリガーが失敗するとスクリプトの持ち主に失敗を知らせるメールが届くとされています。

入力データを集める

質を決めるのは、勘定科目の一覧の「迷いやすい品目と決め方の例」の列です。 「電球・蛍光灯の交換用 → 消耗品費」「排水管の詰まりの業者の作業代 → 修繕費」「店頭で足りなくなった食材 → 仕入高」のように、経理の2名が迷ってきた品目を、決めた答えと一緒に並べます。 例が無いと、AIもぶれます。

送信者のアカウントは、店舗の一覧と照らします。 店長・副店長として登録されたアカウント以外からの報告は、処理せずに経理へ回します。

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

写真は、回答のシートに入るアップロードのファイルの値からドライブのファイルを特定し、DriveApp で取得します。 回答の値の形（ファイルのリンクか、IDか、複数枚の区切り方）は、テストの回答を1件送ってシートの値を見て確かめ、それに合わせて取り出し方を書きます。 推測で書くと、2枚付けたときに2枚目を落とします。

API の呼び出しは UrlFetchApp で行います。 公式の割り当ての表では、URL Fetch の呼び出しは Google Workspace のアカウントで1日10万回、1回の実行の時間は6分が上限です。月600件なら、どちらにも遠く届きません。 1回の実行で1件だけを処理するので、6分を超えることもありません。

AIへ渡す前に整形する

1. 送信者の確認 … 送信者のアカウントが店舗の一覧の店長・副店長かを確かめます。違えば処理せずに経理へ回します
2. 写真の有無 … 写真が無ければAIに渡さず、「証憑の欠け」として撮り直しの依頼を送ります
3. 形式の確認 … ファイルの種類が JPEG・PNG・GIF・WebP のどれかを確かめます。iPhone の既定の HEIC で撮られた写真は、そのままでは渡せません
4. 大きさの確認 … base64 にしたときに10MBを超えないか、縦横が8000ピクセルを超えないかを確かめます
5. 金額の整え … フォームの金額の欄から「円」「,」「￥」を外して数にします。数にならなければ要確認にします
6. 重複の確認 … 同じ店舗・同じ日付・同じ金額の行が台帳に既にあれば、重複の疑いの印を付けます

3番目は、店舗への最初のお願いで減らします。 スマートフォンのカメラの設定で、保存の形式を JPEG にしてもらいます。それでも HEIC が届いたら、撮り直しの依頼を自動で送ります。 スクリプトの側で形式を変換する仕組みは作りません。

6番目は、同じ報告を2回送ってしまう場合のためです。 フォームは送信の後に「別の回答を送信」が出るので、送れたか不安になった店長が同じ内容をもう一度送ることがあります。 重複の疑いは消さずに印だけ付け、経理が決めます。

AIに処理させる

させるのは、写真から決まった項目を読み、科目の候補を一覧から選ぶことだけです。

2行目が、この構成でいちばん大事な制約です。 レシートの写真は、折れ・影・感熱紙のかすれで1桁が読めないことがよくあります。AIが前後から推し量って埋めると、フォームの金額と「一致」してしまい、誰も写真を見ないまま台帳に入ります。 読めない桁があれば、合計金額を空にして unreadable を返させます。

指示内容を固定する

あなたは飲食チェーンの本部の経理担当です。
店舗から届いた小口現金の出金の写真を読み、決められた項目を返してください。
写真に写っている文字だけを根拠にしてください。

【書類の種類 document_type】
- receipt ......... レジのレシート
- handwritten ..... 手書きの領収書
- order_or_quote .. 注文の控え、見積書、納品書など、支払の証明でないもの
- other ........... それ以外、または判断できない

【厳守事項】
- 写真から読み取れない項目は空にしてください。
- 数字が1桁でも読めない場合は、その金額を空にし、unreadable_fields に項目名を入れてください。
  前後の数字や品目の合計から推し量って埋めないでください。
- 手書きの領収書で金額の欄が空欄の場合は、total を空にし、notes に「金額の欄が空欄」と書いてください。
- 合計金額は、レシートの「合計」「お買上計」など支払額を示す行の値を写してください。
  「お預り」「お釣り」の金額と取り違えないでください。
- 税率ごとの金額が印字されていなければ空にしてください。計算しないでください。
- 登録番号は、印字された文字列をそのまま写してください。桁を補わないでください。
- 品目は印字のとおりに写し、最大10行までにしてください。
- 勘定科目は、下の一覧の account_code から1つだけ選んでください。
  一覧の「決め方の例」に当たるものがあれば、それに従ってください。
  2つ以上の科目に当たりそう、または当たるものが無い場合は undecided にしてください。
  迷ったときに近そうな科目を選ばないでください。
- 店長の入力（参考）は、科目を選ぶときの用途の手がかりにだけ使ってください。
  写真から読む日付・金額・支払先を、店長の入力に合わせて書き換えないでください。
- 複数枚の写真がある場合は、同じ1枚のレシートを分けて撮ったものか、
  別のレシートかを multiple_receipts に書いてください。

【勘定科目の一覧】{account_list}
【店長の入力（参考）】日付 {form_date}／支払先 {form_payee}／金額 {form_amount}／用途 {form_purpose}／メモ {form_memo}

「店長の入力に合わせて書き換えない」を明記するのは、フォームの入力を渡しているからです。 用途は科目を選ぶ手がかりとして要りますが、金額まで見えていると、読みにくい数字をフォームの金額に寄せて読むことが起きます。突き合わせの意味が無くなるので、禁止を書いておきます。

金額をAIに渡さない設計もできます。 その場合は用途とメモだけを渡します。最初の試しでは両方を比べ、寄せて読む傾向が見えたら金額を外します。

出力形式を固定する

構造化出力のスキーマで、次の形を返させます。document_type と account_code は enum にして、一覧の外の値を返せないようにします。

{
  "document_type": "receipt | handwritten | order_or_quote | other",
  "receipt_date": "",
  "payee": "",
  "total": "",
  "amount_10": "",
  "amount_8": "",
  "registration_no": "",
  "has_registration_no": false,
  "items": [""],
  "account_code": "5110 | 5210 | 5320 | ... | undecided",
  "account_reason": "",
  "unreadable_fields": [""],
  "multiple_receipts": "single | same_receipt | different_receipts",
  "notes": ""
}

金額は文字列で受け取り、スクリプトの側で数にします。空と0を取り違えないためです。

1つ目の理由は、突き合わせを規則で書けることです。 スクリプトは次の順で行の区分を決めます。

金額の一致は1円の違いも許しません。 店長の打ち間違いか、AIの読み違いか、どちらかが起きているからです。日付は数日のずれを許します。 店長が報告をまとめて送る日があるためです。

2つ目の理由は、科目の候補を enum で閉じ込められることです。 公式のページでは、構造化出力のスキーマで enum が使えるとされています。一覧に無い科目名が返ってくることが、構造の側で起きなくなります。

システムへ連携する

台帳には、AIが読んだ値とフォームの入力の両方を列で残します。 「金額（店長）」「金額（写真）」「科目（候補）」「科目（確定）」のように分け、確定の列は経理だけが埋めます。 一致の行は、日に1回の流し見の後に経理が確定の列へまとめて写します。

撮り直しの依頼のメールには、何が欠けているかだけを書きます。 「写真が付いていません」「写っているのが注文の控えで、レシートではありません」「領収書の金額の欄が空欄です」。依頼のメールはフォームの回答の編集のリンクを付けず、新しく報告し直してもらいます。 元の回答は「撮り直し依頼済み」として残し、新しい回答と紐づけます。

会計ソフトへは書き込みません。 月末に台帳の確定の列から仕訳を起こすのは、これまでどおり人が行います。

人が確認する

1. 経理が毎朝「要確認」の行を見る … 写真を開き、フォームの金額と写真の金額のどちらが正しいかを見ます。写真が正しければ台帳を直し、店長に打ち間違いを伝えます
2. undecided の科目を決める … 決めた結果のうち、また出そうな品目は勘定科目の一覧の「決め方の例」に足します
3. 重複の疑いを決める … 同じレシートの写真なら片方を取り消し、別の支出なら両方を残します
4. 一致の行を流し見る … 店舗と金額と科目の候補を一覧で見て、確定の列へ写します
5. 月末の照合で合わない店舗を見る … 出金の合計と残高の報告の差を、台帳の行から探します

2番目が、この構成を育てる作業です。 決め方の例が増えるほど undecided は減り、2名の付け方のぶれも、例の側で吸収されます。 決めた結果を例に戻さないと、毎月同じ品目で迷います。

例外に対処する

上から3行は、店舗への最初の案内で大半が防げます。 撮り方の例（レシート全体が入る、影が落ちない、平らに置く）を1枚の画像にして店舗に配ります。AIの読み取りを強くするより、写真の質をそろえるほうが効きます。

記録を残す

• フォームの回答の行の位置、送信日時、送信者
• 写真のファイルのID（写真そのものはドライブに残す）
• AIに渡した指示の版と、返ってきた JSON の全文
• 突き合わせの区分と、どの条件で要確認になったか
• 経理が直した内容 … どの項目を、何から何へ。科目の候補と確定の違い
• 撮り直しの依頼を送った日時と、新しい回答との紐づけ

科目の候補と確定の違いは、月に1回数えます。 候補が外れた品目が多い科目は、一覧の説明が足りていません。外れた品目を例に足すと、翌月の undecided と外れが減ります。

写真はドライブのフォームのフォルダに残り、経理課だけが見られるようにします。 フォームのオーナーのドライブに新しいフォルダができる仕組みなので、オーナーのアカウントを経理課の共有のアカウントにしておきます。 個人のアカウントで作ると、異動のときに写真ごと持ち主が変わります。