店舗の巡回チェックを写真で行い、基準との差と是正依頼を作る

処理の起点を決める

フォームが送信されたことを起点にします。Apps Script のインストール可能なトリガーには「フォーム送信時」があり、回答が入るたびに関数を実行できます。

巡回中に項目ごとに送信する形にしてください。1店舗分をまとめて最後に送る形にすると、その場で気づいた指摘を店長に伝えられません。項目ごとに送れば、店を出る前に判定結果が返ります。

月次の傾向集計は、毎月1日の時間主導型トリガーで動かします。Apps Script の時間主導型トリガーは最短1分ごと、最長月1回まで設定できます。

なお、インストール可能なトリガーは作成した人のアカウントで動きます。 担当者の異動で止まらないよう、部門の共用アカウントで作成してください。

入力データを集める

「基準写真」がこの構成の核です。 「掲示物が正しく掲示されている状態」を写真で示せば、判定は「この写真と比べてどう違うか」になります。言葉で「適切に掲示されていること」と書くより、はるかに判定がぶれません。

基準写真は、店舗タイプごとに1組用意します。120店舗が3タイプなら、42項目×3タイプ＝126枚です。撮影に2日ほどかかりますが、1度作れば当面使えます。

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

撮影： フォームの各項目に、撮影位置と向きの指示を付けます。「レジカウンターから入口に向かって全景」「冷蔵庫の中段を正面から」といった指示です。同じ位置から撮られていないと、基準写真との比較が成立しません。

指示の書き方だけでは伝わらないので、基準写真をフォームの項目に表示します。 「この写真と同じ位置から撮ってください」とすれば、撮影位置がそろいます。

画像の渡し方： Gemini API には、画像をURLで渡す方法と、Base64エンコードした文字列として埋め込む方法があります。ファイルが大きい場合や複数のリクエストで同じ画像を使い回す場合は、File API でアップロードする方法が推奨されています。

トークン数の目安： 縦横とも384ピクセル以下の画像は258トークン、それより大きい画像は768×768ピクセルのタイルに分割され、各タイルが258トークンになります。巡回写真を高解像度のまま送ると、トークン数が大きくなります。 判定に必要な解像度に落としてから送ってください。

AIへ渡す前に整形する

1. 項目との紐づけ … フォームの項目から、どのチェック項目の写真かを特定します
2. 人物の写り込みの検出 … 客や従業員が写っている写真を検出します（後述）
3. 解像度の調整 … 判定に必要な範囲まで縮小します。文字（日付ラベル、POPの文言）を読む項目は解像度を落としすぎないでください
4. 撮影位置のずれの判定 … 基準写真と構図が大きく違う場合、判定せず「撮り直し」とします
5. 明るさの判定 … 暗すぎる写真、逆光の写真を弾きます
6. 前回の指摘の読み込み … 同じ店舗の前回の指摘事項を用意します

2番目を必ず入れてください。 店舗の写真には、客と従業員が写り込みます。顔が写った写真を外部のAIサービスに送ることは、個人情報の取り扱いとして慎重な判断が要ります。

AIに処理させる

判定させる項目と、させない項目を明確に分けます。

右側の項目は、従来どおりスーパーバイザーが見ます。 AIに判定させないことで、むしろそこに時間をかけられるようになります。

LLMにさせること：

「清潔かどうか」を聞かないでください。 聞けば答えは返りますが、根拠がありません。基準が言語化できない項目は、AIに判定させる対象ではありません。

指示内容を固定する

あなたは、店舗の巡回点検を支援する担当者です。
基準写真と今回の写真を比べ、決められた項目について差を報告してください。

【厳守事項】
- 判定するのは、下記のチェック項目に書かれたことだけです。
  「清潔感」「雰囲気」「印象」といった主観的な評価をしないでください。
  聞かれていない点について良し悪しを書かないでください。
- 写真に対象が写っていない、不鮮明で判断できない、
  基準写真と構図が大きく違う場合は、
  result を "cannot_judge" とし、理由を書いてください。
  推測で判定しないでください。
- 差を報告するときは、写真のどこを見てそう判断したかを
  location に書いてください（「カウンター右端の掲示スペース」など）。
- 日付ラベルの日付は、読み取れた文字をそのまま date_read に入れてください。
  読めない桁がある場合は、その旨を書き、期限の判定をしないでください。
- 人物が写っている場合は、person_detected を true にし、
  人物の外見、服装、行動について一切記述しないでください。
- 是正依頼文は、店長が何をすればよいかが1文で分かるように書いてください。
  「改善してください」ではなく
  「カウンター右端に今月のPOP（〇〇キャンペーン）を掲示してください」と書いてください。
- 前回の指摘については、写真上で直っているかだけを判断し、
  直っていない理由を推測しないでください。

【チェック項目】
項目名: {item_name}
判定基準: {criteria}
撮影位置: {camera_position}

【今月掲示すべき掲示物】
{promotion_list}

【前回の指摘事項】
{previous_findings}

【基準写真】
（画像）

【今回の写真】
（画像）

「聞かれていない点について良し悪しを書かないでください」の1行が重要です。 これを書かないと、POPの有無を聞いているのに「床に汚れが見られます」といった記述が付きます。基準のない指摘が報告書に並ぶと、店舗側の不信を招きます。

「人物の外見、服装、行動について一切記述しない」も必ず入れてください。 従業員や客について記述が残ると、個人に関する記録になります。

出力形式を固定する

{
  "store_code": "",
  "visit_date": "",
  "item_id": "",
  "item_name": "",
  "result": "ok | deviation | cannot_judge",
  "findings": [
    {
      "type": "missing | misplaced | unauthorized_item | label_issue | obstruction",
      "description": "",
      "location": "",
      "severity": "safety | compliance | operation | appearance"
    }
  ],
  "text_read": {
    "date_read": "",
    "label_content": "",
    "readable": true
  },
  "previous_finding_status": "resolved | not_resolved | not_applicable",
  "person_detected": false,
  "photo_quality": "ok | too_dark | blurry | wrong_angle | subject_not_visible",
  "correction_request": "",
  "cannot_judge_reason": ""
}

severity の4区分が、報告書の使いやすさを決めます。

すべてを同じ重さで並べると、店長は安全に関わる指摘を見落とします。

photo_quality は、判定できなかった理由を分けるために持ちます。「撮り直しが必要」なのか「本当に対象がない」のかは、まったく違う意味です。

システムへ連携する

是正依頼の自動送信はしません。 severity: safety の指摘はその場で口頭で伝えるべきものであり、メールで済ませる性質のものではありません。スーパーバイザーが判定結果を確認したうえで送ります。

是正後の写真の再判定は自動化できます。 店長が同じフォームから是正後の写真を送り、自動で判定して完了を記録する流れです。これが「前回の指摘が確認されない」問題を解きます。

人が確認する

全店舗の判定結果を、スーパーバイザーが確認します。

見る優先順位は次のとおりです。

主観が入る項目の評価は、AIが判定した項目の確認が減る分、じっくり行えます。 それがこの構成の狙いでもあります。「接客の様子」「客席の使われ方」といった、その場でしか分からないことに時間を回せます。

例外に対処する

記録を残す

• 巡回写真（人物が写ったものを除く）と、撮影日・店舗・項目
• 判定結果と、location（どこを見て判断したか）
• スーパーバイザーが判定を変更した内容と、その理由
• 是正依頼と、店長の対応状況
• 是正後の写真と再判定の結果
• 月次の全店集計

「判定を変更した内容と理由」が資産になります。 「この項目は毎回判定が外れる」が見えれば、基準写真か判定基準の書き方に問題があると分かります。

人物が写った写真は、判定後に破棄するか、人物部分を処理してから保存してください。 店舗の点検記録として必要なのは、什器や掲示物の状態であって、そこにいた人ではありません。