ホテルの朝食ビュッフェの料理台を定時に撮った写真から、残りの少ない料理と空の皿を見分け、厨房への補充の連絡とピーク時の補充の遅れの記録を作る

処理の起点を決める

時間主導型トリガーを5分ごとに動かし、朝食の時間だけ処理します。 トリガー自体は終日動きますが、スクリプトの最初で時刻を見て、6時20分から10時10分の外なら何もせずに終わります。 開場前の10分は、料理を並べ終えた状態を「満杯」の基準として撮るためです。

5分を選んだのは、写真の間隔と合わせるためです。 カメラも5分ごとに撮り、スクリプトはその間に入った写真を処理します。1分ごとに動かしても、新しい写真が無ければ空振りになります。 起動の時刻は少しずれることがあるため、写真は撮影の時刻で並べ、スクリプトの起動の時刻では並べません。

1回の実行は6分までです。 2会場で島が7つなら、1回に処理する写真は7枚です。1枚ずつ呼び出しても6分には十分に収まりますが、念のため、処理しきれなかった写真は次の実行に回します。

トリガーの1日の合計の実行時間には上限があります。 Google Workspace のアカウントで1日6時間、一般のアカウントで90分です。この構成は Google Workspace のアカウントで動かします。 持ち場ごとのスペースへの受信 Webhook も、Business か Enterprise の Google Workspace のアカウントが要ります。

入力データを集める

質を決めるのは、配置表の位置の枠です。 料理の位置を枠で決めておけば、AIは「この枠の中の料理の量」だけを答えればよく、料理の名前を写真から当てる必要がありません。 枠は、カメラを据え付けたときに、開場前の写真の上で1回だけ引きます。

開場時の写真を渡すのは、「満杯」を料理ごとに示すためです。 同じ「半分」でも、大皿と深いホテルパンでは見え方が違います。その日の満杯の姿と比べさせると、区分がぶれにくくなります。

献立の差し替えは、配置表の「本日」の列に入れます。 差し替えが入っていないと、パンの位置にケーキが並んだ日に、パンの知らせが出続けます。

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

Apps Script が、島ごとのフォルダから前回の処理より後に保存された写真を取り出します。ファイルの名前に島と撮影の時刻を入れる決まりにし、名前で並べます。

写真は、処理したら「処理済み」のフォルダに移します。 移すのは、判定と記録が終わったときだけです。島ごとのフォルダに残っている写真の数が、そのまま未処理の数になります。

AIへ渡す前に整形する

1. 撮影の時刻の確認 … ファイルの名前の時刻が、今の時刻から15分以上古いものは、知らせを出さずに記録だけにします
2. 写りの確認 … 真っ暗な写真や、同じ写真が続く場合は、カメラの不具合として事務所に知らせます
3. 大きさの調整 … 長い辺を決めた大きさにそろえます。大きすぎる写真は、リクエストの大きさとトークンを増やすだけです
4. 枠の座標の変換 … 配置表の枠を、[ymin, xmin, ymax, xmax] の0〜1000の座標で持たせ、そのまま指示に入れます
5. 本日の差し替えの反映 … 配置表の「本日」の列で、料理の名前と補充の線を置き換えます
6. 客が写る場合の扱い … カメラは料理台の上だけを写す画角に据えますが、手や体が写り込む前提で、写真は朝食の終了後に決めた期間で消します

1番目で古い写真に知らせを出さないのは、補充がすでに済んでいるかもしれないからです。 カメラの保存が遅れて15分前の写真がまとめて届くと、その間に人が補充した料理まで知らせが出ます。古い写真は記録にだけ使い、知らせは新しい写真から出します。

3番目は、費用のためでもあります。 Gemini API は、縦横とも384ピクセル以下の画像を258トークンで数え、それより大きい画像は768×768の区画に分けて区画ごとに258トークンで数えます。料理の量が見分けられる範囲で小さくそろえます。

AIに処理させる

させるのは、枠ごとに、その中の料理の残りを5つの区分のどれかで答えることと、取り皿の残りを答えることだけです。

not_visible を正直に返させるのが要です。 客がトングを持って料理の前に立っている写真で、AIは見えている端だけから「少ない」と答えがちです。隠れているなら答えず、次の写真を待ちます。 5分後にはたいてい客はいなくなっています。

区分を4段階にしているのは、補充の線を料理ごとに変えるためです。 揚げ物は half で頼み、果物は low で頼む。どこで頼むかはAIではなく配置表が決めます。 残りの量を細かい割合で答えさせても、写真からの割合はぶれます。4段階なら、人の目の感覚とずれにくくなります。

指示内容を固定する

あなたはホテルの朝食ビュッフェで、料理台の残りの量を見る担当の補助です。
1枚目は今日の開場前の写真（満杯の状態）、2枚目は今の写真です。
渡した枠の中だけを見て、料理の残りを答えてください。

【枠】
枠ごとに slot_id と、[ymin, xmin, ymax, xmax] の0〜1000の座標を渡します。
枠の外にある料理や器は見ないでください。

【level の選び方】（1枚目の同じ枠の満杯の状態と比べる）
- full ......... 満杯に近い
- half ......... 半分くらい
- low .......... 底が見え始めている、または数個しか残っていない
- empty ........ 空、またはほぼ空
- not_visible .. 手・トング・人の体・湯気で隠れて判断できない
迷ったら、少ないほうの区分ではなく not_visible を選んでください。

【取り皿など】
plates_slot の枠の中の取り皿・ボウル・グラスの残りを enough / low / empty /
not_visible で答えてください。

【厳守事項】
- 料理の名前を答えないでください。slot_id で答えてください。
- 補充すべきかどうかを書かないでください。
- 人について何も書かないでください。
- 枠の中に、1枚目と違う料理や器が置かれていれば layout_changed を true にしてください。
- note には、判断の手がかりにした見た目を短く書いてください（例：「底の白い皿が見える」）。

【枠の一覧】{slots}

「迷ったら少ないほうではなく not_visible」が、誤報を減らす一文です。 誤って「少ない」と出ると、厨房は用意して運び、料理台の前で余ります。誤報が続くと、厨房は知らせを見なくなります。 知らせが信じられているかどうかが、この構成の生命線です。

「人について何も書かない」は、写真に客が写り込むことがあるためです。 判定の結果に客の様子が残らないようにします。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "island_id": "western_bread",
  "photo_time": "2026-10-08T07:45:00+09:00",
  "slots": [
    { "slot_id": "W1-03",
      "level": "full | half | low | empty | not_visible",
      "layout_changed": false,
      "note": "" }
  ],
  "plates": { "level": "enough | low | empty | not_visible", "note": "" }
}

level を enum にして、5つ以外を返させません。 Gemini API の構造化出力では、enum と required が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 枠の数と返った slot_id が合うかを、Apps Script で確かめます。

補充の知らせは、Apps Script が配置表の線と比べて決めます。

持ち場のスペースに届く知らせは、短くします。

【補充】洋食 パンの島　W1-03 クロワッサン　残り：low（07:45の写真）

料理の名前は配置表から入れます。 AIは slot_id しか返さないので、名前の取り違えが起きません。

システムへ連携する

Google Chat への知らせは、受信 Webhook で送ります。 受信 Webhook は登録したスペースだけで動き、会話ができない一方通行の仕組みです。 厨房の担当は知らせに返事をする必要はなく、補充済みは次の写真で自動で記録されます。 1つのスペースへの送信は、そのスペースの Webhook 全体で1秒に1件までです。持ち場ごとにスペースを分けているので、同じ持ち場に同時に何件も知らせが重なる場面は、間を置いて送ります。

訂正には、Apps Script のウェブアプリを使います。 ウェブアプリには doGet か doPost が要り、HTML を返します。責任者のタブレットで知らせの一覧を開き、誤報に「誤り」を付けられるようにします。 「誤り」の付いた枠は、その日の日報から外し、配置表の枠や線を見直す材料にします。

人が確認する

この構成は、知らせのたびに人の承認を挟みません。 補充の知らせは、遅れるほど意味が無くなるためです。その代わり、人が見るのは次の3つです。

1. 責任者の知らせ … 2枚続けて補充されなかった料理です。厨房の仕込みが間に合わないのか、知らせが見落とされたのかを確かめます
2. 誤報の訂正 … 料理台で余っている補充に気づいたら、ウェブアプリで「誤り」を付けます
3. 朝食後の日報 … 料理ごと・時間帯ごとの遅れを、翌朝の打ち合わせで見ます

目標は、1回の見回りに相当する確認を1分に収めることです。 知らせを見て、運ぶ料理を確かめ、誤りがあれば付ける。見に行く時間と、頼みに行く時間が無くなった分が、第10章の差になります。

1週目は、見回りを続けたまま並べて動かします。 見回りで見つけた少ない料理と、知らせの一覧を突き合わせ、知らせが出なかった料理と、誤って出た料理を数えます。 誤報が多い枠は、枠の引き方か補充の線を直します。

例外に対処する

1行目と5行目で「人の見回りに戻す」を決めておくのが大事です。 機械が止まった朝に、誰も料理台を見ていない状態がいちばん危険です。止まったことが分かる知らせと、戻る手順を先に決めます。

記録を残す

• 写真ごとの判定の結果（枠ごとの区分、取り皿、layout_changed）
• 知らせの一覧：枠、料理、検知の時刻、知らせの時刻、補充済みの時刻、検知から補充までの分
• 責任者への知らせと、その理由
• 誤報の訂正の記録
• カメラ・APIの不具合と、人の見回りに戻した時間
• 日ごとの朝食の予定人数

写真そのものは長く残しません。 判定の結果と時刻が残れば、日報は作れます。写真は朝食の終了後、決めた期間（たとえば7日）で消し、誤報の見直しに要るものだけを残します。

日報は、たとえば次の形にします。

【朝食の補充の日報】2026-10-08（予定人数 412名）
 洋食 パンの島
   W1-03 クロワッサン  知らせ 6回  検知→補充 平均 9分  最長 18分（07:45）
   W1-05 食パン        知らせ 3回  検知→補充 平均 5分
 洋食 温かい料理の島
   W2-02 スクランブルエッグ  知らせ 5回  平均 11分  責任者への知らせ 1回（08:05）
 時間帯別（15分ごと、全料理）
   07:30-07:45  知らせ 9回  平均 10分
   07:45-08:00  知らせ 11回 平均 12分
 誤報の訂正 2件（W3-04 ×2：湯気）

日報は、料理ごと・15分ごとの遅れを並べます。 「7時30分から8時15分に、クロワッサンの補充に平均12分かかっている」。予定人数の多い日と少ない日で比べれば、仕込みの量か、補充の線か、どちらを動かすべきかが見えてきます。