飲食店の店舗で手書きされる月末の食材の棚卸表を読み取り、本部の棚卸データにそろえて、原価率の計算と前月から大きく動いた品目を拾う

処理の起点を決める

店舗がアップロードの画面から棚卸表を送り、Cloud Storage に保存されたことを起点にします。 保存先は inventory/2026-09/store-012/ のように月と店舗で分けます。Cloud Run には、バケットでオブジェクトが作られたとき（google.cloud.storage.object.v1.finalized）に関数を呼び出す仕組みがあり、関数とバケットは同じプロジェクトに置く必要があります。

読み取りはファイルが届くたびに行い、原価率の計算は店舗の4ページがそろったときに行います。 4ページが別々の時間に届くことがあり、最初の1ページで原価率を出すと、残りの品目が0の原価率になります。 品目の一覧から店舗の業態のページ数を引き、そろったら計算に進みます。

締め切りも決めます。 月初の2営業日目の正午までにそろわない店舗は、担当者の一覧に「未提出」として出します。共有フォルダに置く運用を続けると、どの店舗が出していないかを人が数えることになります。

入力データを集める

質を決めるのは、棚卸表の様式の並び順です。 印刷された品目の行は、並び順が分かっていれば、品名を読まなくても何行目が何の品目かが決まります。 手書きの品名を読ませるのは、書き足された行だけで済みます。

品目の一覧の「別名」は、書き足された品目の当てはめに使います。 「豚バラ」「バラ（豚）」「豚ばら スライス」のように、店舗で書かれる名前を別名として持っておくと、当てはめの迷いが減ります。

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

関数から、すべてのページを先に Enterprise Document OCR に通し、そのあと Form Parser にも通します。

画像の品質の点数は、既定では返りません。 enableImageQualityScores を有効にすると、OCRの処理と同じくらいの時間が足されるとされています。月初の数日に180ページが集中するので、写真で届いたページだけで有効にし、複合機のスキャンでは切る運用にします。

言語のヒントに ja を入れます。 languageHints に言語を渡すと、推定に頼らずその言語に合わせて読み取りを調整できるとされています。

行の対応づけは、AIではなく関数で行います。 Form Parser が返した表の行の上から順に、様式の品目の並び順を当てます。行の数が様式と合わないページは、表の読み取りが崩れたとみなして印を付けます。

行の数が合っていても、ずれていることがあります。 1行目の品名が抜けて2行目以降が1つずつ上にずれると、数は合ったまま全行が隣の品目に付きます。そこで、印刷された品名の文字も照らします。 各行の品名の列をOCRの文字で読み、様式の品名と一致するかを関数で見ます。一致しない行が続けて3行以上あれば、row_shift を付けます。印刷された文字は手書きより読みやすいので、品名は位置合わせの目印として使えます。

AIへ渡す前に整形する

1. 形式の確認 … PDF、GIF、TIFF、JPEG、PNG、BMP、WebP のいずれかであることを確かめます。HEIC の写真は JPEG に変換します
2. サイズの確認 … オンライン処理は1ファイル40MBまでです。超えるものは縮小するかバッチ処理に回します
3. 解像度の確認 … スキャンは200dpi以上が最低、300dpi以上が最適とされています。店舗の複合機の設定を300dpiにそろえます
4. 画素数の確認 … 画像は1ページ4,000万画素までです。スマートフォンの写真で超えるものは縮小します
5. 向きと傾きの補正 … 斜めに撮った写真は、表の行がずれるので補正してから読ませます
6. ページの確認 … 様式のページ番号を読み、同じページが2回届いたものは新しいほうを使います

5番目を軽く見ないでください。 棚卸表は1行の高さが小さく、写真が数度傾いているだけで、数量が隣の行の品目に付きます。 行の対応づけの段で印が大量に出たら、まず撮り方を疑います。

AIに処理させる

AIの仕事は2つです。数量の書き方を数と単位に分けることと、書き足された品目を品目の一覧に当てはめることです。

4行目がいちばん起きやすい失敗です。 読めない数字を渡すと、AIは前月の数量に近い値を選びがちです。前月と同じ数字が入れば、前月との比較で印が付かず、読めなかったことが消えます。 前月の棚卸データをAIに渡さないのは、このためです。

指示内容を固定する

あなたは飲食チェーンの本部で、店舗の月末の食材の棚卸表を集計する担当です。
OCRの結果から、行ごとの数量を「数」と「単位」に分けてください。
OCRの結果に書かれていることだけを根拠にしてください。推測で埋めないでください。

【行ごとにすること】
1. 数量の文字列を、数（quantity）と単位（unit）に分ける
   例：「2と1/2」→ 2.5 と 空、「500g」→ 500 と g、
       「1ケース3本」→ 2つの組（1 と ケース、3 と 本）
2. 単位が書かれていなければ unit は空にする。品目の棚卸の単位で補わない
3. 書き足された行（印刷された品目の無い行）は、品名を品目の一覧に当てはめる

【status の選び方】
- ok ........ 数が読み取れた
- blank ..... 数量の欄に何も書かれていない
- unreadable  文字はあるが、品質の点数が0.5未満などで数として確定できない
- ambiguous . 数の候補が複数ある（「1」か「7」か決められない等）

【厳守事項】
- 空欄を0にしないでください。blank にしてください。
- 読めない数字を、他の行や常識から推測して埋めないでください。
- 単位の換算、金額の計算をしないでください。
- 書き足された品名に当てはまる品目が複数あれば、すべて candidates に並べ、
  1つに決めないでください。
- 根拠にしたOCRの文字列を evidence にそのまま写してください。

【店舗・業態・ページ】{store} / {format} / {page}
【様式の品目の並び（このページの分）】{template_rows}
【品目の一覧（品名・別名・棚卸の単位）】{item_master}
【OCRの結果（行ごと、品質の点数付き）】{ocr_rows}

「単位を品目の棚卸の単位で補わない」は、書いておかないと起きます。 単位の書かれていない「500」を、品目の単位が kg なら 500kg として返します。単位が空なら、プログラムが「棚卸の単位で書かれた」とみなす規則を持てばよく、AIが補う必要はありません。 補われると、500gのつもりの500が500kgになったことに後から気づけません。

出力形式を固定する

次の形のJSONで受け取ります。 Claude の構造化出力（output_config.format に json_schema を指定）を使い、項目の名前と型を固定します。

{
  "store_id": "012",
  "format": "family",
  "page": 2,
  "rows": [
    { "row_no": 14, "item_code": "M-0231", "printed": true,
      "parts": [ { "quantity": "2.5", "unit": "" } ],
      "status": "ok | blank | unreadable | ambiguous",
      "quality_score": 0.81, "evidence": "2と1/2" },
    { "row_no": 36, "item_code": "", "printed": false,
      "written_name": "豚ばら スライス",
      "candidates": ["M-0118", "M-0120"],
      "parts": [ { "quantity": "3", "unit": "kg" } ],
      "status": "ok", "quality_score": 0.77, "evidence": "豚ばら スライス 3kg" }
  ]
}

1つ目の理由は、parts で「1ケース3本」を分けて持てることです。 換算はプログラムが品目の一覧の係数で行い、1ケースが何本かは品目の一覧の側で決めます。

2つ目は、status で空欄と読めないものを分けられることです。 プログラムは blank を「数え忘れの確認」、unreadable と ambiguous を「数字の確認」として店舗への確認の一覧に分けて載せます。

3つ目は、数量を文字列で受けることです。 公式の説明では、構造化出力では数値の範囲や文字数の制約は使えないとされています。数への変換と範囲の確認はプログラムで行います。

プログラムが規則で付ける印は、次のとおりです。

システムへ連携する

原価率の集計表へは、担当者が確定した店舗の分だけを流します。 案の段階の数字が集計表に出ると、店長や経営への報告に未確認の原価率が混ざります。

人が確認する

1. row_shift を先に見る … 表の読み取りが崩れたページは、そのページの全行が疑わしいので画像を開いて確かめます
2. unreadable と ambiguous を見る … 画像で読めるものは担当者が入れ、読めないものは店舗に確認します
3. blank を店舗に確かめる … 在庫が0だったのか、数え忘れかを聞きます
4. item_jump と ratio_jump を見る … 読み取りの誤りでなければ、店舗に理由を確かめます
5. 確定する … 店舗ごとに確定の印を付け、原価率の集計表に流します

1ページあたり4分を目安にします。 印の少ないページは流し見で1〜2分、row_shift のページは全行を見直すので10分近くかかります。ならして4分です。

店舗への確認は、店舗ごとに1通にまとめます。 行ごとに連絡すると、店長は同じ日に何通も受け取ります。確認の一覧を店舗ごとに並べ、数字の確認、数え忘れの確認、大きく動いた理由の確認の3つに分けて送ると、店長は冷蔵庫の前で一度に答えられます。文面は定型で足り、AIで作る必要はありません。

3番目は、毎月の運用で減らせます。 様式に「在庫なし」のチェックボックスを設けて、在庫が0なら0を書くか印を付ける、と店舗に決めてもらうと、空欄は数え忘れだけになります。

例外に対処する

4行目は、季節の限定メニューのたびに起きます。 新しい食材は、本部が品目の一覧に登録する前に店舗で使われ始めます。棚卸表に書き足されたものが、品目の一覧の登録漏れを知る機会にもなります。

記録を残す

• 届いた棚卸表の画像と、アップロードの日時・店舗・ページ
• Document AI が返した結果の全文（文字、手書きの情報、品質の点数、表）
• Claude が返したJSONと、使った指示の版
• プログラムが付けた印と、そのとき使った品目の一覧・換算の係数・単価の版
• 担当者が案を直した記録 … どの行を、何から何に変えたか
• 店舗への確認の内容と、店舗からの回答

5つ目は、店舗ごとの書き方の癖を見る材料になります。 同じ店舗で「1」と「7」の直しが続くなら、書き方を店長と話すほうが、読み取りの調整より効きます。

4つ目で単価の版を残すのは、原価率を後から説明するためです。 最終の仕入単価は月の途中でも変わり、同じ数量でも、どの時点の単価を掛けたかで在庫の金額が変わります。 店長から「先月より原価率が上がった理由」を聞かれたとき、数量の変化か単価の変化かを分けて答えられるようにしておきます。