小売店の売場の棚の写真を本部の棚割表と比べ、商品の位置・フェイス数・欠品の違いを拾って、店への直しの依頼と月次の実施率にまとめる

処理の起点を決める

フォームの送信を起点にし、1回の送信ごとにその場で処理します。 1回の送信はゴンドラ1本で、呼び出しは多くて3回です。Apps Script の1回の実行の上限6分に収まります。 棚替えの締め日に60店舗から集中して届いても、送信ごとに別々の実行になります。

まとめて1日1回の処理にはしません。 棚割の違いは、その日のうちに直してもらうことに意味があります。翌日にまとめて返すと、違う棚のまま1日売ることになります。

もう1つは、月末の集計の時間主導型トリガーです。 月の最終日の夜に、確認の一覧から店ごとの実施率と欠品の率を集計します。インストール型のトリガーは作った人のアカウントで動くので、営業企画の共用のアカウントで作ります。

入力データを集める

質を決めるのは、いちばん下から2つ目の「見分けの手がかり」です。 シャンプーの本体と詰替、同じ商品の香り違いは、パッケージの色と形がほとんど同じです。商品部が「この2つは表記のここで見分ける」と書いた表を持たせると、対応づけの段で使えます。

表に無い組でも、写真から見分けられなければ uncertain にします。 見分けられないものを棚割どおりとして数えると、実施率が実態より高く出ます。

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

フォームの送信のイベントから、アップロードされたファイルのIDと、選ばれた店・ゴンドラの番号が取れます。Apps Script で Google ドライブから写真を読み、ゴンドラの番号と撮影の日で、その日に有効な棚割表の行を引きます。

棚割表は、有効になる日で引きます。 棚替えの締め日より前の写真を新しい棚割表と比べると、全部の位置が違いと出ます。 店が早めに棚替えを終えて撮った場合に備え、新旧の両方を引いて、新しいほうで pass になるかを先に見ます。

枠を重ねた表示は、確認の一覧から開けるようにします。 写真の上に box_2d の位置で枠を描き、wrong_item は赤、uncertain は黄で示します。座標は0から1000に正規化されているので、表示する画像の幅と高さに掛けて1000で割れば、枠の位置になります。

AIへ渡す前に整形する

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

撮り方をそろえるのが、前処理の代わりになります。 ゴンドラの正面の通路の中央に立ち、上の段から下の段までが1枚に入るように撮る。斜めから撮ると、手前の商品の陰に奥の段の商品が隠れます。 1枚に収まらない高いゴンドラは、上半分と下半分の2枚にし、フォームで「上」「下」を選ばせます。

AIに処理させる

させるのは3つの段階です。 写り具合の確認、見えるままの並びの書き出し、棚割表との対応づけです。2つ目の段では棚割表を見せません。

1つ目の段階：写り具合

2つ目の段階：見えるままの並び

段ごとに、左から順に次を返させます。

3つ目の段階：棚割表との対応づけ

2つ目の結果と棚割表と見分けの手がかりを渡し、棚割表の位置ごとに次のどれかを付けさせます。この段は文字だけで、写真は渡しません。

wrong_item と uncertain の区別が、この構成でいちばん大事です。 本体と詰替を取り違えたかどうかを、写真の表記から言い切れないなら uncertain です。店に「違う商品です」と送るのは、はっきり違うと分かるときだけにします。

指示内容を固定する

2つ目の段（見えるままの並び）

あなたは小売チェーンの本部で、店の棚の写真を記録する立場です。
写真に写っている棚の商品を、見えるままに書き出してください。

【書き出し方】
- 上の段から順に、各段の左から右へ並べてください。
- 各商品について、パッケージに読める商品名や表記を observed_label に
  読めた文字のまま書いてください。読めない部分は「?」にしてください。
- 横に並んでいる正面の数を facings に入れてください。
  手前の商品やPOPで隠れて数えられない場合は、facings を空にしてください。
- 商品が無く棚板が見えている場所は、is_empty を true にしてください。
- 各商品と空きの位置を box_2d に [ymin, xmin, ymax, xmax] で
  0〜1000 に正規化して入れてください。

【厳守事項】
- 見えないものを推測で書かないでください。
- よく似た商品は、読めた表記だけで書き分けてください。
  どちらか分からないときに、どちらかに決めないでください。
- 並べ方の良し悪しや、空いている理由は書かないでください。

3つ目の段（対応づけ）

次の「見えるままの並び」と「棚割表」を、棚割表の位置ごとに対応づけてください。
写真は見ていません。並びに書かれたことだけを根拠にしてください。

【status の選び方】
- ok .......... 棚割表の商品が、その位置に、指定のフェイス数で並んでいる
- wrong_item .. その位置に、棚割表と違う商品がはっきり並んでいる
- facing_diff . 商品は合っているが、フェイス数が違う
- empty ....... その位置が空いている
- uncertain ... 見分けの手がかりに当たる表記が読めない、または並びと棚割表の
                位置がずれていて1対1に決められない
迷ったときに ok も wrong_item も選ばないでください。迷ったら uncertain です。

【見えるままの並び】{observed}
【棚割表】{planogram}
【見分けの手がかり】{lookalikes}

2つ目の段に棚割表を入れないのが、この指示のいちばんの工夫です。 棚割表を見せると、「つめか?」と半分読めた表記を棚割表の「詰替」に合わせて書きます。見えるままを先に固定してから比べるので、取り違えが取り違えのまま残ります。

3つ目の段で「迷ったら uncertain」を明記しないと、ok が増えます。 対応づけを頼まれると、AIは棚割表に合う方向に寄ります。uncertain は実施率の分母から外し、別に数えます。

出力形式を固定する

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

{
  "gondola": "G-12",
  "positions": [
    { "shelf": 2, "slot": 3, "planned_jan": "", "planned_name": "",
      "planned_facings": 3, "observed_label": "", "observed_facings": 2,
      "status": "ok | wrong_item | facing_diff | empty | uncertain",
      "box_2d": [0, 0, 0, 0] }
  ]
}

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

2つ目は、実施率と欠品を別に数えられることです。 実施率は ok ÷（ok ＋ wrong_item ＋ facing_diff）、欠品の率は empty ÷ 位置の数です。empty を実施率の分母に入れないので、売れて空いた棚が実施の失敗に数えられません。

3つ目は、スクリプトで検証できることです。 返ってきた位置が棚割表と1対1で対応しているか、box_2d が0から1000の範囲か、planned_jan が棚割表にあるかを確かめます。1つでも合わなければ review にします。

システムへ連携する

直しの依頼は表で送ります。 段、左からの位置、棚割表の商品名とフェイス数、写真で見えた表記とフェイス数の4列です。店は売場でその表を見ながら直せます。

メールの送信には1日の上限があります。 Google Workspace のアカウントで1日あたり1,500名の受信者まで、とされています。1日に数十店に送る程度なら収まりますが、棚替えの締め日は店ごとに1通にまとめて送ります。

人が確認する

営業企画の担当は、review の行だけを開きます。 fix は店にそのまま送られ、pass は一覧で流し見ます。

1. uncertain を見る … 写真の枠で、似た商品のどちらかを確かめます。分からなければ店に確認します
2. 位置の数が合わないものを見る … 棚割表の版が違うか、撮り方が悪いかを確かめます
3. fix に直して送るか決める … 確かめた結果を一覧に書き、店に送ります
4. 判定を覆したら記録する … uncertain をどちらに決めたか、理由を残します

fix で送った依頼にも、店から「違わない」と返ってくることがあります。 その返事は確認の一覧に記録し、同じ取り違えが続く商品の組は、見分けの手がかりの表に足します。

pass の写真も、週に1回は店ごとに数枚を抜き取って見ます。 AIが見逃した違いは review の確認だけでは見つからないので、抜き取りが見逃しを知る唯一の手がかりです。

月末の実施率は、担当者が数字を見てから会議に出します。 uncertain の多い店は、実施率の数字が実態からずれている可能性があります。

例外に対処する

上から2行目までが大半を占めます。 どちらもAIの問題ではなく、撮る時刻と撮り方の問題です。 撮影の手本の写真を店に配ると、retake が減ります。

記録を残す

• 棚の写真と、そのとき対応づけた棚割表の版
• 2つ目の段の見えるままの並びと、3つ目の段の対応づけのJSONの全文
• verdict と、担当者が覆した位置とその理由
• 店に送った依頼と、店からの返事
• 店ごと・カテゴリーごとの実施率と欠品の率の推移

見えるままの並びを残すのは、対応づけをやり直せるからです。 見分けの手がかりの表を直した後に、写真を読み直さずに3つ目の段だけを回し直せます。 費用もかからず、過去の月の実施率を同じ基準で出し直せます。

覆した理由は、短い選択肢で残します。 「似た商品」「棚割表の版」「代替あり」「撮り方」の4つ程度にしておくと、月末に数えられます。「似た商品」が多ければ見分けの手がかりの表、「撮り方」が多ければ撮影の手本を直します。