飲食店の毎日の廃棄記録と仕込みの記録から品目ごとの廃棄を集計し、翌月の仕込み量の見直し案を店長へ返す

処理の起点を決める

時間主導型のトリガーを、毎月1日の朝6時台に1つ置きます。 前月の最終日の廃棄の記録は閉店後に出されるので、深夜0時の直後ではなく、朝まで待ちます。 遅く出された記録があっても、6時台なら入っています。

処理は店舗ごとに区切ります。 1店舗分の取り出し・理由の読み分け・集計・目安の計算・見直し案の文面までを1まとまりにし、どの店舗まで終わったかをスクリプト プロパティに残します。 1回の実行が5分を過ぎたら区切り、同じ朝の15分後と30分後に置いた続きのトリガーで、残りの店舗から再開します。

全店舗が終わったら、本部の担当に1通のメールで知らせます。 「16店舗中16店舗の見直し案ができた。記録の無い日が多い店舗は2つ」のように、終わった数と、記録に問題のある店舗の数だけを書きます。 中身は一覧のシートで見ます。

月の途中でも、手で動かせるようにします。 新メニューの導入の後などに、本部が特定の店舗だけ見直したいときがあるからです。手で動かすときは、対象の店舗と期間をシートに書いてから実行します。

入力データを集める

AIに渡すのは2種類です。 1回目の呼び出しには、理由が「その他」の廃棄とメモの付いた廃棄の行を、品目名と量とメモだけにして渡します。2回目の呼び出しには、スクリプトが計算し終えた集計と目安の数字と、翌月の予定を渡します。 生の記録をすべて渡すことはしません。

営業の記録が、目安の質を決めます。 貸切の日は仕込みも廃棄もふだんと違い、8週の中に貸切の水曜が1日混ざると、水曜の目安が大きく振れます。 営業カレンダーに貸切と休業の日が書かれていれば、その日を計算から外せます。

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

記録のスプレッドシートは、店舗ごとのタブの範囲をまとめて読みます。日付で前月分と、目安の計算に使う直近8週分を絞り込みます。 8週は前月より長いので、前々月の終わりの分も読みます。

前月の見直し案と店長の返事も読みます。 先月「減らす」と返した品目が、今月どうなったかを見直し案に書けるからです。店長が採らなかった案を、毎月同じ形で繰り返し送ることも避けられます。

Gemini API の鍵はスクリプト プロパティに置き、UrlFetchApp で呼びます。 muteHttpExceptions を true にして、失敗の状態コードでも応答を受け取り、送り直すかを決めます。

AIへ渡す前に整形する

1. 単位の換算 … 「バット」「個」「人前」で書かれた量を、品目マスタの換算で基本の単位にそろえます。換算の無い単位は「換算不能」として、その行を集計から外して数えます
2. 記録の無い日の印 … 営業日なのに仕込みの記録も廃棄の記録も無い日に「記録なし」の印を付けます。廃棄ゼロとは扱いません
3. 廃棄の記録だけが無い日 … 仕込みの記録はあるのに廃棄の記録が無い日は「廃棄の記録なし」とし、その日は使った量の計算から外します
4. 休業・貸切の日の除外 … 営業カレンダーで休業と貸切の日を外します
5. 使った量の計算 … 日ごとに、仕込んだ量から「仕込み過ぎ」と「期限切れ」の廃棄を引きます。調理の失敗と設備の不調の廃棄は、使った量に含めたままにします
6. 曜日ごとの目安 … 直近8週の同じ曜日の使った量を並べ、多いほうから2番目の量を目安とします。外した日があって4日に満たない曜日は、目安を出しません
7. 日持ちの考慮 … 日持ちが2日以上の品目は、曜日ごとではなく2日分をまとめて見ます
8. 差の大きい品目の選択 … 目安と仕込み表の差が仕込み表の15％以上で、前月の廃棄の量が多い品目から、店舗ごとに最大5品目を選びます

5番目で理由を分けるのが、この構成の分かれ目です。 冷蔵庫の不調で捨てた分は、仕込み過ぎではありません。その分まで使った量から引くと、使った量が少なく見え、仕込みを減らしすぎる案になります。 だから「その他」とメモの付いた廃棄は、AIに理由を読み分けさせてから計算します。

6番目の「多いほうから2番目」は、欠品を避ける側に寄せた決め方です。 平均で目安を出すと、8週のうち半分ほどの日に足りなくなります。店長が欠品を嫌って仕込み表を多めにしている理由は、ここにあります。 決め方は本部と店長で話し合い、設定のシートで変えられるようにします。

AIに処理させる

させるのは2つです。 1つ目は、理由が「その他」の廃棄とメモの付いた廃棄の理由を、決めた区分の中から選び直すこと。2つ目は、スクリプトが選んだ差の大きい品目について、店長への見直し案の文面を書くことです。

理由の区分に「予約の取消」を足しているのは、店舗のメモで多い型だからです。 仕込み過ぎに数えると、取消の多かった月の翌月に仕込みを減らす案が出ます。取消は仕込み表の問題ではないので、使った量の計算では仕込み過ぎと分けます。

いちばん起きやすい失敗は、1行目です。 「水曜の目安2.6kg」と渡しても、AIは「2.5kgに減らすことをお勧めします」と丸めて書くことがあります。2.5という数字はどこからも出てこない数字で、店長に聞かれても説明できません。 文面の中の数字はスクリプトが入れた値と照らし、違えばその文面を作り直します。

指示内容を固定する

1つ目の指示（理由の読み分け）は次のとおりです。

あなたは飲食チェーンの本部で、店舗の廃棄記録を整理する立場です。
各行のメモを読み、廃棄の理由を次の区分から1つ選んでください。

【区分】
- over_prep ......... 仕込み過ぎ、余った、出なかった
- expired ........... 日持ちの期限を過ぎた
- cooking_error ..... 焦がした、味付けの失敗、落とした
- equipment ......... 冷蔵庫・冷凍庫・機器の不調
- reservation_cancel  予約の取消、団体の人数の減少
- plate_waste ....... お客様の食べ残し
- unknown ........... メモから判断できない

【厳守事項】
- メモに書かれていないことを推測しないでください。
- 量を書き換えないでください。量は出力に含めません。
- evidence には、区分を決めた語句をメモからそのまま写してください。
- 入力の row_id をそのまま返し、行を増やしたり減らしたりしないでください。

【廃棄の行（row_id、品目、メモ）】{rows}

2つ目の指示（見直し案）は次のとおりです。

あなたは飲食チェーンの本部で、店長に仕込み量の見直しを提案する文面を書く立場です。
目安の量は、すでに決まった式で計算されています。
「直近8週の同じ曜日に実際に使った量のうち、多いほうから2番目の量」です。

【してほしいこと】
品目ごとに、次を2〜3行で書いてください。
1. 今の仕込み表の量、目安の量、その差（渡した数字をそのまま使う）
2. 廃棄の多かった曜日と、廃棄の理由の内訳
3. 翌月の予定に照らして、店長に確かめる点（質問の形で）
4. 先月の提案があれば、その後の廃棄の変化

【厳守事項】
- 数字は入力の値をそのまま書いてください。丸めたり、計算し直したりしないでください。
- 仕込み表をこうすべきと決めつけず、「目安は○kgです。いかがでしょうか」の形にしてください。
- 入力に無い事情（天気、近隣の催事、季節の傾向）を理由として書かないでください。
- 調理の失敗と設備の不調の廃棄は、仕込み量の話と分けて書いてください。
- 店舗や店長の良し悪しを書かないでください。
- 目安が出ていない曜日（記録が足りない）は、その旨だけを書いてください。

【店舗と品目ごとの入力】{items}
【翌月の予定】{next_month_calendar}
【先月の提案と店長の返事】{last_month}

「目安の決め方」をプロンプトの冒頭に書いておくのが要点です。 決め方を知らないと、AIは目安を「予測値」と言い換え、機械が当てた数字のように書きます。 決め方を渡せば、「8週のうち多いほうから2番目」と、店長が自分で確かめられる言い方で書きます。

出力形式を固定する

理由の読み分けは次の形で受け取ります。 reason は7つの区分を enum で列挙します。

{
  "results": [
    { "row_id": "S07-2026-09-17-012", "reason": "reservation_cancel",
      "evidence": "宴会10名キャンセル" }
  ]
}

見直し案は次の形で受け取ります。

{
  "store_code": "S07",
  "items": [
    {
      "item_code": "V012",
      "weekday": "水",
      "current_qty": 3.0,
      "target_qty": 2.6,
      "unit": "kg",
      "message": "",
      "question_for_manager": "",
      "has_target": true
    }
  ]
}

1つ目の理由は、current_qty と target_qty をスクリプトが照合できることです。 AIに数字を返させるのは、文面の中の数字と並べて確かめるためです。返ってきた値がスクリプトの計算と1つでも違えば、その品目の文面は使いません。 message の中に出てくる数字も、正規表現で取り出して同じ照合をします。

2つ目は、has_target で「目安が出せない」を正式な答えにできることです。 記録の無い日が多い曜日は、無理に目安を作らず、「水曜は記録が4日に満たないため目安を出していません」と書いて返します。 記録を続けてもらう理由として、店長にも伝わります。

3つ目は、理由の読み分けの row_id で入力と出力を突き合わせられることです。 送った行と返った行の数が合わなければ、まとまりごと送り直します。

一覧のシートには、店舗・品目・曜日ごとに次の列を並べます。

システムへ連携する

仕込み表には書き込みません。 目安が正しくても、翌月に団体の予約が入っていれば、店長は多めに仕込みます。仕込み表は店長が自分で直し、直した量は翌月の「今の量」として読まれます。

店長宛てのメールは下書きまでにします。 本部の担当が案を読み、送らない品目を消してから送ります。店長の返事は、一覧のシートの返事の欄に本部が書き写すか、店長に直接書いてもらいます。

人が確認する

1. 記録に問題のある店舗を先に見る … 「記録なし」「換算不能」の多い店舗は、見直し案より先に記録のつけ方を店長と話します
2. 理由が unknown の廃棄を見る … 量が多いものだけ、店舗にメモの意味を聞きます
3. 見直し案を読む … 数字の照合を通った案でも、翌月の予定と合わないものは送る前に消します
4. 送る … 店舗ごとに、下書きを確かめてから送ります
5. 店長の返事を残す … 採る・採らないと理由を、一覧のシートに書きます

1番目を省かないでください。 記録が欠けた店舗の目安は、欠けていない日だけから計算されています。その目安を送ると、店長は「記録をつけなくても本部が量を決めてくれる」と受け取ります。 記録が先です。

目標は、480行をならして1行1分です。 本部が見るのは差の大きい品目に絞った案と、記録に問題のある店舗で、残りの行は一覧を流し見るだけ、という想定です。

例外に対処する

3行目は、記録のつけ方の食い違いから起きます。 前日の残りを翌日の廃棄として書く店舗と、前日の廃棄として書く店舗があります。どちらに寄せるかを決めて、フォームの案内に書いておきます。

記録を残す

• 処理した月、店舗ごとの処理の結果、「記録なし」「換算不能」の件数
• 理由の読み分けの結果（row_id、reason、evidence）
• 店舗・品目・曜日ごとの集計と目安と、そのとき使った目安の決め方（「多いほうから2番目」など）
• 見直し案の文面と、送った日時
• 店長の返事（採る／採らない／一部採る）と、その理由
• 翌月の同じ品目の廃棄量

最後の2行を並べて残すのが、この構成を育てる材料です。 採った案の品目で翌月の廃棄が減ったか、欠品は起きなかったか。採られなかった案の理由が「宴会が多い時期」なら、営業カレンダーに書いてもらう事情が1つ増えます。

目安の決め方を変えたら、変えた月を記録します。 「多いほうから2番目」を「平均の1.2倍」に変えると、同じ記録から違う目安が出ます。どの月がどの決め方だったかが残っていないと、廃棄の増減の理由が追えません。