自動販売機の補充員が撮った前面と庫内の写真を Gemini で読み、売切れの表示と見本の並びを補充の記録にして、次の積込の品目の案を作る

処理の起点を決める

巡回の時間帯（朝8時から夕方5時）だけ、5分おきに動くプログラムが共有のフォルダを見ます。 Google Apps Script のインストール型の時間主導のトリガーは毎分から月1回までの間隔で動かせ、公式の案内では実行の時刻がわずかにずれることがあるとされています。「撮ってから数分で下書きが返る」くらいの設計にし、補充の作業の数分のあいだに結果が届くようにします。

1台の処理は、補充後の写真が入ったところで始めます。 到着時の写真だけで先に動かすと、売切れの表示が消えたかを見られません。機械番号ごとに arrive と after がそろったかをファイル名で数え、そろったものから処理します。 庫内の写真は、棚割りの表で「庫内が見える機種」とされた機械だけで待ちます。

到着時の写真が入ってから30分たっても補充後の写真が来なければ、補充員のスマートフォンに「補充後の前面が未撮影」と返します。 撮り忘れはそのまま確認の抜けになるからです。処理が終わった写真は日付のフォルダに移し、共有のフォルダに残る枚数を処理待ちの数にします。

入力データを集める

質を決めるのは、棚割りの表の正しさです。 表が古ければ、AIが正しく読んでも「食い違い」が出続けます。季節の切り替えのたびに棚割りの表を先に直し、表を直した日付を持たせます。 表の日付が写真の日付より後なら、比べる前に止めます。

品目の見本の一覧は、似た缶を見分けるために渡します。 同じメーカーの無糖と加糖、同じ茶の小さい容量と大きい容量は、見本の小さな写真では見分けにくい組み合わせです。 一覧に「見分ける手がかり（キャップの色、ラベルの帯の色）」を書いておき、AIに渡します。

販売の数は渡しません。 販売の数を通信で取れる機械では、その数は別に記録に入ります。写真から売れた本数を推し量らせると、測っていない数字が記録に紛れます。 写真から分かるのは、表示と見本の見え方だけです。

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

写真の機械番号と種類は、ファイル名から読みます。 補充員は機械の側面に貼った機械番号のコードをスマートフォンで読み取ってから撮り、「日付_機械番号_種類」の名前で保存されるようにします。決まりを外れた名前の写真は処理せず、補充員の画面に「機械番号が読めない」と返します。

棚割りの表と価格の台帳は、機械番号で1行ずつ引きます。 棚割りの表に無い機械番号は処理を止め、営業所の担当に知らせます。新しく設置した機械の表を足し忘れていると、ここで分かります。

Gemini API へは、1台につき1回、3枚の写真と棚割りの行をまとめて渡します。 写真の順番は「到着時の前面、庫内、補充後の前面」に固定し、指示の文で順番を説明します。ボタンの番号は、機械の前面に左上から振った番号を棚割りの表と合わせておきます。 番号の振り方が機種で違うと、AIが正しく読んでも突き合わせがずれます。

有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し（有料の枠で55日）、保存しないときは store=false を付けると案内されています。store=false にすると前のやり取りを引き継ぐ使い方はできませんが、この構成は1台ごとに1回で完結するので困りません。

AIへ渡す前に整形する

1. ファイル名の確認 … 機械番号・種類がそろっているか。そろわないものは補充員に返します
2. 写真の向きと大きさの確認 … 縦横を直し、長い辺を一定の大きさに縮めます。20MBを超えないよう3枚の合計を見ます
3. 明るさの確認 … 夜間・逆光で前面が白く飛んでいる写真は、ボタンの表示が読めません。明るさの平均が極端なものは「撮り直し」と返します
4. 棚割りの行の取り出し … その機械のボタンの数、ボタンごとの品目、温冷の区分、価格を、AIに渡す短い表にします
5. 見本の一覧の絞り込み … 品目の見本の一覧から、その機械の棚割りに出てくる品目と、よく取り違える品目だけを渡します
6. 人が写り込んだ写真の確認 … 機械の前を通る人が大きく写った写真は、撮り直しを求めます。顔が写るほど引いて撮らない決まりにします

3番目を軽く見ないでください。 売切れの表示は小さな光の表示で、屋外の昼の逆光では点いているのか消えているのか、人の目でも迷います。 読めない写真を AI に「読ませる」と、点いていない表示を点いていると返すことがあります。撮り直しを求めるほうが早く済みます。

6番目は、設置場所の写真を扱う以上、最初から決めておきます。 駅や商業施設の前では人が写り込みます。機械の前面に近づいて撮れば、通行人は写りにくくなります。

AIに処理させる

させるのは、写真に見えるものを、ボタンの番号ごとに書き出すことだけです。 食い違いかどうかは、プログラムが棚割りの表と比べて決めます。

右端の列がいちばん大事です。 unclear と not_visible を off や「問題なし」と区別して返させます。「消えている」と「見えなかった」を混ぜると、補充後の表示の消え残りを見落とします。

1行目がいちばん起きやすい失敗です。 庫内の写真を渡すと、コラムの上部に見える缶の数から「残り5本」と書きたがります。コラムの奥は見えず、その数字は当て推量です。

指示内容を固定する

あなたは飲料の自動販売機の補充の記録を手伝う立場です。
渡された3枚の写真に見えるものだけを、ボタンの番号ごとに書き出してください。
推測で埋めないでください。

【写真の順番】
1枚目：到着したときの前面
2枚目：扉を開けたときの庫内のコラムの上部（無い場合があります）
3枚目：補充を終えて扉を閉めた後の前面

【この機械の棚割り】{planogram}
ボタンの番号は、前面の左上から右へ、上の段から下の段へ数えます。

【見分ける手がかりの一覧】{sample_guide}

【書き出すもの】
- sold_out_arrive / sold_out_after：ボタンごとの売切れの表示
  lit（点いている）／off（消えている）／unclear（反射や逆光で判断できない）
- sample_item：見本が一覧のどの品目に見えるか。迷うときは候補を2つまで
- price_label：ラベルに見える数字をそのまま。読めなければ unclear
- inside_columns：庫内の写真で、コラムの上部に見える品目
- recycle_box：回収箱から空き容器があふれているか（yes／no／not_visible）
- damage：前面の割れ・落書き・表示の剥がれに見えるもの

【厳守事項】
- 迷ったときに off を選ばないでください。判断できなければ unclear です。
- 写っていないボタンやコラムは not_visible とし、棚割りから補わないでください。
- 価格の数字を補ったり、台帳の値に合わせて直したりしないでください。
- 売れた本数・残りの本数を書かないでください。写真からは数えられません。
- 見本と棚割りが合っているか、補充が正しかったかの判定は書かないでください。
- 人が写っている場合も、その人について何も書かないでください。
- evidence には、その判断の手がかりにした見え方を短く書いてください。

「迷ったときに off を選ばない」を明記しないと、補充後の表示はほとんど off になります。 売切れの表示は点いていない時間のほうが長く、写真の多くも off です。その傾向に引きずられて、判断できない表示まで off と返すのを止めます。

「棚割りから補わない」を書くのは、棚割りを渡しているからです。 渡した表は突き合わせのための手がかりで、見本が隠れているボタンに表の品目を書き入れられると、食い違いの検出が働かなくなります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "machine_id": "",
  "photos": { "arrive": true, "inside": false, "after": true },
  "buttons": [
    { "button_no": 1,
      "sold_out_arrive": "lit | off | unclear | not_visible",
      "sold_out_after": "lit | off | unclear | not_visible",
      "sample_item": ["", ""],
      "price_label": "",
      "evidence": "" }
  ],
  "inside_columns": [
    { "column_no": 1, "item": "", "evidence": "" }
  ],
  "recycle_box": "yes | no | not_visible",
  "damage": [ { "where": "", "what": "" } ],
  "photo_quality": "ok | retake"
}

1つ目の理由は、ボタンの番号で棚割りの表とそのまま突き合わせられることです。 プログラムが button_no で表を引き、次のように食い違いを決めます。

2つ目は、AIの出した値を enum で絞れることです。 表示の状態を決まった4つの値に絞っておけば、「たぶん点いている」のような自由な言葉が記録に入りません。 button_no は minimum と maximum でボタンの数の範囲に絞れます。それでも公式の案内どおり、ボタンの数と返ってきた行の数が合うかはプログラムで確かめます。

3つ目は、記録の下書きと積込の案に同じデータを使えることです。 sold_out_arrive が lit のボタンを記録の「売切れ」に入れ、その回数を機械とボタンごとに数えれば、積込の案の材料になります。

システムへ連携する

積込の品目の案は、次の決まりでプログラムが作ります。

棚割りの表と価格の台帳には書き込みません。 食い違いが見つかっても、正しいのが表か見本かは人が確かめるまで分からないからです。表を直すのは営業所の担当です。

人が確認する

補充員は、機械の前で下書きの注意だけを見ます。 全ボタンの行を読む必要はありません。

1. 「補充後も売切れの表示が残っている」を最初に見る … 扉を開け直し、入れたコラムを確かめます。この注意は機械を離れる前に片づけます
2. 見本・価格の食い違いの候補を見る … 目の前の見本と棚割りを見比べ、見本の差し替えか、表の誤りかを書き残します
3. 補充した数を足して確定する … 写真からは数えないので、補充した本数は補充員が入れます
4. AIの読み違いを直したら、そのボタンに印を付ける … どの表示をどちらに直したかを残します

営業所の担当は、夕方に積込の案と食い違いの一覧を見ます。 積込の案はそのまま使わず、翌日の天気と在庫を見て決めます。棚割りの見直しの候補は、設置先との約束（置く品目の取り決め）があるかを確かめてから扱います。

1番目を省かないでください。 消え残りは、次の巡回まで数日その品目が売れないことを意味します。 削減した時間のどこよりも、ここで取り返すものが大きい確認です。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題ではなく、撮り方の問題です。 撮る位置と立つ向きを機械ごとに決め、機械の側面に目印を貼るほうが、指示の文を直すより効きます。

Gemini API が止まっても、補充の仕事は止めません。 下書きが返らないときは、これまでどおり手で記録を付ける画面に切り替わるようにしておきます。

記録を残す

• 3枚の写真と、撮った日時・補充員・機械番号
• Gemini API に渡した棚割りの行と、返ってきたJSONの全文
• プログラムが出した注意と、そのとき参照した棚割りの表と価格の台帳の版
• 補充員が確定した記録と、AIの読みを直した箇所
• 積込の品目の案と、営業所の担当が実際に決めた積込
• 機械ごとの unclear と retake の発生率

3つ目の「そのときの表の版」を残すのは、季節の切り替えで表が変わるからです。 後から食い違いの記録を見たとき、当時の表と比べた結果なのかが分からないと、誤りの元をたどれません。

最後の行は、撮り方を見直す材料になります。 特定の機械だけ retake が続くなら、設置場所の光の向きに理由があります。写真は90日で消し、JSONと確定した記録だけを残す、のように期間を決めておきます。