飲食店の厨房を閉店後に撮った写真を本部の基準の写真と比べ、清掃の不足・床置き・食材の出しっぱなしの候補を見分けて、店舗への是正の依頼を作る

処理の起点を決める

写真がフォルダに保存されたことを起点に、1枚ずつ処理します。 Watch Files in a Folder を店舗の写真をまとめる親のフォルダに向け、新しい写真が入るたびにシナリオを動かします。店舗の遅番が保存した時刻から間を置かずに比べ終えておけば、朝には結果がそろっています。

店舗ごとのまとめは、朝6時に別のシナリオで行います。 1枚ずつの結果を店舗ごとに集め、是正の依頼の下書きを作ります。本部の担当が出社するときには、候補のある店舗だけが一覧になっています。

閉店の時刻は店舗ごとに違います。 深夜2時に閉める店もあるため、朝6時のまとめでは、前日の営業日に属する写真を日付ではなく撮影時刻と営業日の区切りで集めます。区切りは朝5時にします。

入力データを集める

質を決めるのは、基準の写真です。 本部が作る衛生の手順書の見本ではなく、その店舗のその場所を、正しく片付けた状態で撮った写真を基準にします。厨房の配置は店舗ごとに違うので、手順書の1枚では比べられません。 開店前の点検の日などに、本部の担当が店舗で撮ります。

撮影場所ごとに見る観点を絞ります。

場所ごとに観点を変えるのは、誤報を減らすためです。 冷蔵庫の中に食材があるのは正常で、作業台に食材があれば出しっぱなしです。同じ「食材が写っている」でも、場所で意味が変わります。

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

Make のシナリオが、写真1枚ごとに次の順に集めます。

ファイル名の決まりが、この構成を支えます。 例えば S023_K3_20261008_2315.jpg なら、店舗23の撮影場所K3（コンロの周り）を23時15分に撮った写真です。店舗のタブレットに、場所ごとに撮影して名前を付けるだけの簡単な画面を用意すると、名前の誤りが減ります。 その画面は、店舗のタブレットの環境に合わせて用意します。

基準の写真は、店舗・場所ごとに1枚だけを正本にし、撮り直したら古いものは別のフォルダに移します。 2枚が並んでいると、どちらと比べたかが記録から読めなくなります。

画像は、取り出したファイルを本文に入れて送ります。 2枚の写真と指示を合わせて、リクエスト全体が20MBに収まるよう、店舗のタブレットの撮影の大きさを決めておきます。

AIへ渡す前に整形する

1. ファイル名の確認 … 店舗コードと撮影場所の記号が一覧にあるかを見ます。無ければ比べずに「名前の誤り」として記録します
2. 写りの確認 … 暗すぎる写真（照明を消した後に撮ったもの）や、ぶれた写真は「撮り直し」とします
3. 重複の確認 … 同じ店舗・同じ場所・同じ夜の写真が2枚あれば、新しいほうを使い、古いほうは記録だけにします
4. 直した写真の見分け … 同じ店舗・同じ場所に未解決の依頼があり、写真が依頼の後に保存されたものなら、「直した写真」として扱います
5. 大きさのそろえ … 長い辺を決めた大きさにそろえて撮るよう、タブレットの設定で決めます
6. 人が写っている写真の扱い … 従業員が写り込まない位置で撮る決まりにし、指示でも人について書かせません

2番目は、閉店後ならではの問題です。 清掃を終えて照明を落としてから撮ると、写真が暗く、汚れが見えません。「照明を消す前に撮る」を手順に入れます。 暗い写真を比べさせると、見えないものを「きれい」と答える方向にずれます。

5番目の大きさは、費用にも効きます。 Gemini API は、縦横とも384ピクセル以下の画像を258トークンで数え、それより大きい画像は768×768の区画に分けて区画ごとに258トークンで数えます。汚れの見分けに足りる大きさに抑えます。

AIに処理させる

させるのは、1か所ごとに基準と今夜の写真を比べ、決めた3つの種類の候補があるかを答えることだけです。

基準と比べさせるのが要です。 「汚れているか」を単独で聞くと、使い込んだ厨房の床のしみや、ステンレスのくすみまで汚れとして拾います。基準の写真にも写っているものは、その店舗では「正しい状態」です。基準に無くて今夜にあるものだけを候補にさせます。

候補には位置も返させます。 box_2d で、今夜の写真の中の場所を [ymin, xmin, ymax, xmax] の0〜1000の座標で返させ、本部の担当が写真を開いたときにすぐ目を向けられるようにします。

指示内容を固定する

あなたは飲食店の本部で、閉店後の厨房の写真を確かめる担当の補助です。
1枚目は、この店舗のこの場所を正しく片付けた状態で撮った基準の写真です。
2枚目は、今夜の閉店後に同じ場所を撮った写真です。

【この場所の情報】
場所：{location_name}
この場所で見るもの：{aspects}

【候補の種類】
- cleaning ....... 1枚目に無い汚れ・食材のくず・油・洗い残しの器具
- floor_item ..... 床や棚の最下段に直接置かれた容器・段ボール・食材
- food_left_out .. 冷蔵庫・保管棚の外にある食材、覆いの無い食材

【status の選び方】（候補の種類ごとに）
- none ........ 1枚目と比べて、その種類の候補が見当たらない
- found ....... 候補がある
- uncertain ... 反射・水滴・暗さなどで、候補かどうか決められない
- not_visible . その種類を見るべき部分が写っていない
迷ったときに none を選ばないでください。

【厳守事項】
- 1枚目にも写っている汚れ・しみ・くすみは、候補にしないでください。
- この場所で見るもの以外は答えないでください。
- 衛生上問題があるか、店舗に何を頼むべきかを書かないでください。
- 温度、期限、におい、害虫について推測しないでください。
- 人が写っていても、人について何も書かないでください。
- found と uncertain のときは、2枚目の中の位置を box_2d で返してください。
- note には、見えたものを短く書いてください（例：「作業台の右端に覆いの無いボウル」）。

「1枚目にも写っている汚れは候補にしない」が、誤報を減らす一文です。 古い厨房の床には落ちないしみがあり、毎晩それを指摘されると、店舗は本部の依頼を読まなくなります。 落ちないしみの扱いは、基準の写真を撮り直すかどうかとして本部が決めます。

「何を頼むべきか書かない」は、依頼の言い方をそろえるためです。 AIに文を書かせると、夜ごとに言い回しが変わり、同じ汚れでも強い言い方の夜と弱い言い方の夜が出ます。

出力形式を固定する

構造化出力で、1枚ごとに次の形のJSONを受け取ります。

{
  "store_id": "S023",
  "location_id": "K3",
  "checks": [
    { "kind": "cleaning | floor_item | food_left_out",
      "status": "none | found | uncertain | not_visible",
      "box_2d": [0, 0, 0, 0],
      "note": "" }
  ]
}

kind と status を enum にして、決めた値以外を返させません。 Gemini API の構造化出力では、enum と required が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 Make のシナリオで、3つの種類がそろっているか、found なのに box_2d が空でないかを確かめ、合わないものは uncertain として書き込みます。

朝のまとめでは、店舗ごとに次の区分を付けます。

是正の依頼の下書きは、候補の種類ごとの文面を組み立てて作ります。

【閉店後の厨房の確認】S023 ○○店 2026-10-08の営業日
 K3 コンロの周り　清掃の不足：コンロの右奥に油の付着（写真あり）
 K4 床（通路）　　床置き：通路に段ボール箱（写真あり）
本日の閉店後に、上の2か所を直して同じ場所で撮り直してください。

下書きの所見の部分にだけ、AIの note を入れます。 頼む言葉は文面の決まりから入るので、店舗ごとに言い方がぶれません。

システムへ連携する

店舗への依頼は、本部の担当が送ります。 下書きはスプレッドシートの依頼の記録に入り、担当が「依頼する」を選んだものだけを送ります。AIの候補がそのまま店舗に届く形にはしません。 誤報の依頼が届けば、店舗は次から本部の依頼を疑います。

基準の写真のフォルダは、本部の品質管理部だけが書き換えられるようにします。 店舗からは読み取りもできない設定にします。店舗が基準を今の状態に合わせて撮り直すと、比べる意味がなくなります。

人が確認する

候補の出た写真は、すべて本部の担当が確かめます。

1. 「候補あり」を見る … 枠の位置で写真を見て、「依頼する」「問題なし」を選びます。note の言葉だけで決めず、写真を必ず開きます
2. 「確認が要る」を見る … 暗い・反射の写真は、店舗に撮り方を伝えます
3. 「写真の不足」を店長に伝える … 撮り忘れが続く店舗は、閉店の手順そのものを見直します
4. 3日たっても直らない依頼を電話で確かめる … resolved の付かない依頼の一覧を毎朝見ます

目標は、1,500件をならして1件1.2分です。 候補の無い店舗は一覧で数秒、候補のある店舗は写真を開いて数分かかります。候補のある店舗が毎朝1〜2割という想定でならすと1.2分です。

最初の2週間は、これまでの全枚数の確認と並べて動かします。 担当が見つけた問題に、AIが候補を出していたかを照らします。出していなかった問題は、撮影場所の観点か基準の写真を直す材料です。 逆に、担当が「問題なし」とした候補も種類ごとに数えます。どの種類で誤報が多いかが分かれば、指示のどの行を直すかが決まります。 4名の担当で「依頼する」の線がずれていないかも、同じ写真を2名で見て確かめます。

例外に対処する

「未処理」を「候補なし」と分けて一覧に出します。 どちらも候補が出ていませんが、前者は機械が見ていない写真です。 未処理の写真は、本部の担当がこれまでどおり開いて見ます。

記録を残す

• 写真ごとの比較の結果（kind、status、box_2d、note）と、比べた基準の写真の名前
• 店舗ごとの朝の区分と、本部の担当の判断（依頼する／問題なし）
• 送った依頼の文と、送った日時
• 直した写真と、resolved の付いた日時
• 店舗・場所ごとの、候補の回数と「問題なし」の回数
• 未処理・撮り直し・名前の誤りの記録

写真と比較の結果は、衛生管理の記録として決めた期間残します。 HACCPに沿った衛生管理では、実施の状況を記録して保存し、定期的に振り返ることが求められています。閉店後の清掃の状態を、毎晩同じ形で残せることは、その振り返りの材料になります。

店舗・場所ごとの集計は、月に1回、店長会で使います。

【閉店後の厨房の確認 月次】2026年9月
 依頼の多い場所（全店）
   K4 床（通路）     床置き 38件（うち 段ボール 27件）
   K3 コンロの周り   清掃の不足 31件
 直るまでの日数（平均）  1.3日
 写真の不足  S011 9晩／S037 7晩

同じ場所の同じ依頼が多いなら、店舗の努力より仕組みを疑います。 段ボールの床置きが続くなら、段ボールをたたんで置く場所が厨房に無いのかもしれません。