飲食チェーンの店舗が撮った料理の盛り付けの写真を本部の基準の写真と比べ、量・配置・付け合わせの違いを指摘して、店への直しの連絡の下書きを作る

処理の起点を決める

フォームの送信を起点にし、1枚ずつその場で処理します。 1回の送信は写真1枚で、呼び出しは多くて3回です。Apps Script の1回の実行の上限6分に十分収まります。 昼の営業の初めに40店舗から集中して届いても、送信ごとに別々の実行になります。

まとめて1日1回の処理にはしません。 盛り付けの違いは、その日の昼の営業のうちに直してもらうことに意味があります。夕方にまとめて指摘しても、昼の何十食はもう出ています。

もう1つのトリガーは、確認の一覧の編集です。 担当者が「送る」の列に印を付けたことを、スプレッドシートの編集のトリガーで受け、メールを送ります。インストール型のトリガーは作った人のアカウントで動くので、品質管理部の共用のアカウントで作ります。 メールは共用のアカウントから送られることになります。

入力データを集める

質を決めるのは、確認の項目です。 基準書のPDFをそのままAIに渡すと、AIがどれを確かめるかを選ぶことになり、担当者ごとの違いが、今度はAIの呼び出しごとの違いに変わるだけです。 基準書から確かめる項目を1行ずつ抜き出し、スプレッドシートに持たせます。

「許容」の列が、品質管理部の判断を表に出す場所です。 キャベツの量は写真で数えられないので、「明らかに少なければ違い」と幅を書いておきます。 幅を書かずに渡すと、AIは少しの差でも違いと答えます。

過去の指摘はAIに渡しません。 「この店は前回唐揚げが足りなかった」と知らせると、今回も足りないと答えやすくなります。過去との比較は、スクリプトが一覧で行います。

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

フォームの送信のイベントから、アップロードされたファイルのIDと、選ばれた店舗・メニューが取れます。Apps Script で Google ドライブから店の写真を読み、メニューで基準の写真のファイルと確認の項目を引きます。

基準の写真は、メニューを変えるたびに撮り直します。 器や付け合わせを変えたのに基準の写真が古いままだと、全店が「違い」と出ます。 メニューの基準の行に、基準の写真の撮影日と有効になる日を持たせます。

枠を重ねた表示は、Apps Script のウェブアプリで作ります。 doGet で HTML を返すウェブアプリにし、店の写真の上に box_2d の位置で枠を描きます。座標は0から1000に正規化されているので、表示する画像の幅と高さに掛けて1000で割れば、そのまま枠の位置になります。 実行のユーザーは「アクセスしたユーザー」にし、写真のフォルダを見られる人だけが開けるようにします。確認の一覧の各行には、このウェブアプリへのリンクを写真のIDを付けて置きます。

基準の写真も同じ画面の左に並べます。 担当者は左右を見比べ、枠の位置の基準側を確かめます。チャットで写真と基準書のPDFを行き来していた時間の大半は、この並べた表示で消えます。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のどれかであることを確かめます
2. 大きさの確認 … 2枚と指示を合わせて20MBを超えないよう、大きすぎるものは縮めます
3. メニューの有効性の確認 … 選ばれたメニューが、その日に有効な基準を持っているかを確かめます。持っていなければ「基準なし」で止めます
4. 重複の確認 … 同じ店・同じメニュー・同じ日の写真が2枚あれば、後のものを使います

撮影の印を店に置いてもらうのが、前処理の代わりになります。 調理台の端に、皿を置く位置と向きを示すシールを貼ります。皿の向きがそろえば、「キャベツが奥」の判定がぶれません。 斜めから撮った写真を後から補正するより、撮る位置をそろえるほうが確実です。

AIに処理させる

させるのは3つの段階です。 写り具合の確認、基準の写真との比較、直しの連絡の下書きです。1つ目で止まったものは比較に進めません。

1つ目の段階

2つ目の段階

確認の項目の1行ずつについて、次を返させます。

diff と not_visible の区別が、この構成でいちばん大事です。 唐揚げの1個がキャベツの陰に隠れて見えないのか、無いのかは、写真によっては分かりません。「4個見える」とだけ書かせ、5個目が隠れている可能性があれば not_visible にします。 店に「足りない」と伝えるのは、はっきり足りないと分かるときだけです。

3つ目の段階

diff の項目だけを渡し、店長あての連絡の下書きを作らせます。下書きに入れるのは、項目、基準、写真で見えたもの、基準書のどこを見ればよいかです。 叱る言葉や、理由の推測は入れさせません。

指示内容を固定する

あなたは飲食チェーンの本部で、店舗の盛り付けを基準と比べる立場です。
1枚目は本部の基準の盛り付け、2枚目は店舗が撮った盛り付けです。
2枚の写真に写っているものだけを見て、下の確認の項目を1つずつ判定してください。

【メニュー】{menu_name}
【確認の項目】
{check_items}
（項目ID、項目、基準、許容 の順に並んでいます）

【status の選び方】
- ok .......... 基準どおり。許容の範囲内の差は ok
- diff ........ 基準と違うことが写真ではっきり分かる
- not_visible . 写真では判断できない（隠れている、写っていない、ぼけている）
迷ったときに diff を選ばないでください。迷ったら not_visible です。

【厳守事項】
- 確認の項目にない点については書かないでください。見栄えの評価もしないでください。
- 個数は、見えている数を observed にそのまま書いてください。
  隠れている可能性がある場合は、見えない分を足したり引いたりせず、not_visible にしてください。
- 量を重さ（グラム）で見込まないでください。基準の写真との見た目の差だけを書いてください。
- 味、温度、鮮度、衛生については書かないでください。
- diff のときは、違いのある箇所の位置を box_2d に [ymin, xmin, ymax, xmax] で
  0〜1000 に正規化して入れてください。
- evidence には、判断の根拠にした見た目を短く書いてください。
- 違いが生じた理由は書かないでください。

「迷ったら not_visible」を明記しないと、diff が増えます。 違いを探すように頼まれると、AIは小さな差を違いとして挙げる方向に寄ります。店に誤って直しを頼むほうが、見逃すより店との関係に響くので、迷いを not_visible に寄せます。

「確認の項目にない点については書かない」も同じ理由です。 「ご飯の盛り方がやや平たい」のような指摘は、基準書に書かれていない限り、担当者が書いていた個人の好みと同じです。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力では、response_format に mime_type: "application/json" と JSON Schema を渡し、status を enum で3つに限ります。公式の案内では、出力はJSONとして正しくても、値はアプリケーションの側で必ず検証するようにとされています。

{
  "photo_quality": "good | retake | wrong_menu",
  "checks": [
    { "item_id": "K02", "status": "ok | diff | not_visible",
      "observed": "", "evidence": "", "box_2d": [0, 0, 0, 0] }
  ]
}

1つ目の理由は、項目ごとの結果と、店への判断を別の層に置けることです。 checks はAIが埋め、verdict はスクリプトが規則で決めます。

2つ目は、スクリプトで検証できることです。 返ってきた item_id が確認の項目と1対1で対応しているか、box_2d が0から1000の範囲か、diff に box_2d があるかを確かめます。項目の数が合わなければ review にします。 AIが1つの項目を読み飛ばしたまま pass になるのを防ぎます。

3つ目は、集計に使えることです。 item_id ごとの diff の数を店舗とメニューで数えれば、どの店でどの項目が繰り返し違うかが、月末を待たずに分かります。

システムへ連携する

pass の「確認しました」は自動で返します。 店にとっては、写真を送ったことが本部に届いたという合図です。review の連絡は、担当者が印を付けるまで送りません。

メールの送信には1日の上限があります。 Google Workspace のアカウントで1日あたり1,500名の受信者まで、とされています。1日120枚に対して、確認済みの返信、撮り直し、直しの連絡を合わせても収まります。店舗ごとに1日1通にまとめると、さらに余裕が出ます。

人が確認する

品質管理の担当は、review の行だけを開きます。 確認の一覧には写真に box_2d の枠を重ねた画像へのリンクと、項目ごとの結果、下書きが並びます。

1. 枠を見る … 違いと出た箇所が本当に違うかを、写真で確かめます
2. not_visible を見る … 店に撮り直しを頼むか、見送るかを決めます
3. 下書きを直す … 店の事情を知っている場合は、言い方を整えます
4. 「送る」に印を付ける … 印を付けると、その行の連絡が店に送られます
5. 判定を覆したら記録する … diff を ok に直したら、その理由を一言残します

5番目を省かないでください。 担当者が覆した項目が多ければ、確認の項目の基準か許容の幅が実態と合っていません。 メニューの基準を直す材料になります。

pass の写真も、週に1回は抜き取りで見ます。 店舗ごとに数枚を選び、AIが見逃した違いが無いかを確かめます。見逃しは review の確認だけでは見つからないので、抜き取りが唯一の手がかりです。見逃しが見つかった項目は、許容の幅を狭めるか、指示の書き方を直します。

スーパーバイザーは、店舗ごとの diff の推移を巡回の前に見ます。 同じ項目が2週続けて出ている店は、写真での指摘では直らない理由（器の在庫、仕込みの量、新人の配置）がある可能性が高く、巡回で話を聞く対象になります。

例外に対処する

4行目と5行目は、AIの問題ではなく基準の問題です。 季節で付け合わせが変わる時期、食材が届かず代替した日は、基準どおりでないことが正しい状態です。 その情報がどこから来るかを、先に決めておきます。

記録を残す

• 店の写真と基準の写真（そのときに有効だった基準の写真のファイル）
• 指示の全文と、返ってきたJSONの全文
• verdict と、担当者が覆した項目とその理由
• 店に送った連絡の本文と、送った日時
• 店舗・メニュー・項目IDごとの diff の数の推移

「そのときに有効だった基準の写真」を残すのは、基準が変わるからです。 付け合わせを変えた後に過去の指摘を見直すと、当時の基準が分からなければ、その指摘が正しかったかを判断できません。

覆した理由は、短い選択肢で残します。 「隠れていた」「許容の範囲」「代替あり」「基準が古い」の4つ程度にしておくと、月末に数えられます。「隠れていた」が多ければ撮り方、「許容の範囲」が多ければ許容の幅、「基準が古い」が多ければ基準の写真の更新の手順を直します。 覆した理由が、そのまま次に直す場所を教えてくれます。