倉庫の棚を撮った写真から、置き場所の乱れ・ロケーション表示との違い・欠品と過剰を見分けて、在庫データとの食い違いを棚卸の前に拾う

処理の起点を決める

フォームの送信を起点にします。 Google Apps Script のインストール型トリガーの、フォームの送信のトリガーを使います。トリガーは作った人のアカウントで動くため、在庫管理課の共用のアカウントで作り、担当者が異動しても止まらないようにします。

1区画ずつ送らせます。 ゾーンをまとめて撮ってから送ると、どの写真がどの区画かを後から合わせることになります。区画の番号を選んでから撮る順にするのは、写真と区画の対応を最初に確定させるためです。

在庫データの取り込みは、毎朝の時間主導型トリガーで行います。 倉庫管理システムの書き出しのファイルをドライブの決まったフォルダに置き、7時台に読み込んでスプレッドシートを更新します。時間主導型トリガーは、指定した時刻から1時間の幅のなかで動く時刻が決まるので、見回りの開始より余裕をもって設定します。

見回りは、入出荷の少ない時間に行います。 在庫データは朝の時点のものなので、撮影までに動いた在庫は食い違いとして出ます。 これは第7章の例外処理で扱います。

入力データを集める

質を決めるのは、下の2つです。 見本の写真が無い品目は、箱に印刷された品名や品番を読めなければ見分けられません。区画の定義が無いと、写真のどの位置がどのロケーションかを決められません。

見本の写真は、動きの多い品目から用意します。 全品目の見本を一度にそろえる必要はありません。見本の無い品目は、ラベルや箱の文字だけで見分け、読めなければ not_visible にします。

最後に動いた日時は、比較の材料ではなく、規則の側で使います。 撮影の直前に動いた品目の食い違いは、在庫データが古いだけかもしれません。

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

写真は、フォームの回答からドライブのファイルの ID を取り、スクリプトで読み込んで Gemini API に渡します。 回答のシートの行には、区画の番号と写真のファイルの場所が並びます。

撮り方は、フォームの説明欄に書いて毎回見せます。 「区画の正面、床の印の位置から」「最上段のラベルまで入れる」「1枚に入らなければ上下で2枚」の3つです。2枚に分けたときは、上の写真と下の写真のどちらにどの段が入っているかを、区画の定義の側で決めておきます。 撮る人が毎回判断すると、段の割り当てがぶれます。

在庫データは、区画のロケーションの行だけを渡します。 倉庫全体の在庫を渡すと、写真に写った箱に似た品目をほかのロケーションから探してきて、「この箱は別の棚の品目です」と、頼んでいない推定を書くことがあります。 置き場所の違いの候補は、区画の中の比較で出せば足ります。

AIへ渡す前に整形する

1. 形式とサイズの確認 … PNG、JPEG、WEBP、HEIC、HEIF のいずれかで、リクエスト全体が20MBに収まるかを確かめます。超えるものは縮小します
2. 向きの確認 … 公式の案内でも、画像が正しく回転しているかを確かめるよう挙げられています。タブレットの縦横の情報で向きをそろえます
3. 写り具合の確認（AI） … ぶれ、暗さ、区画の全体が入っているかを先に見ます
4. ラベルの読み取り（AI） … 写真に写ったロケーションのラベルの文字と位置を読み、区画の定義と照らします
5. 在庫データの絞り込み … 区画の定義から、その区画のロケーションの行だけを取り出します
6. 見本の写真の用意 … 区画に含まれる品目の見本だけを、比較の依頼に添えます

3番目と4番目を、比較の前に別の依頼として行います。 1回の依頼にまとめると、暗くて見えない写真でも比較の結果が返り、ラベルを取り違えた写真でも食い違いが返ります。 先に止める依頼を分けておくと、比較の結果が出たものは、写真とロケーションの対応が確かなものだけになります。

AIに処理させる

させるのは、ロケーションごとに「在庫データと比べてどう見えるか」に種類を付け、根拠と位置を書き出すことだけです。

empty の条件に「奥まで見えている」を入れているのが、この構成の要です。 棚の手前が空いていても、奥に箱が押し込まれていることがあります。奥の壁や棚の背板が見えていなければ、空とは言えません。 そのときは not_visible にし、見に行くかどうかを規則の側で決めます。

埋まり具合は、在庫数との矛盾だけを見ます。 「在庫数40ケースなのに、棚に2〜3ケースしか見えない」ような大きな食い違いを empty の手前の段階として evidence に書かせ、個数は数えさせません。

4行目がいちばん起きやすい失敗です。 手前に同じ箱が並んでいると、奥も同じだろうと考えて ok にします。見えている範囲だけで判断させ、それ以外は not_visible に寄せます。

overflow は、在庫データとの食い違いではなく、安全と通路の問題として扱います。 棚からはみ出した箱や通路に置かれたパレットは、在庫の数が合っていても、ピッキングの動線をふさぎ、落下の危険があります。区分では visit にせず、ゾーンのリーダーへの通知だけを出します。

指示内容を固定する

あなたは物流センターの在庫管理の担当として、棚の写真と在庫データを比べます。
写真に写っているものだけを根拠にしてください。推測で補わないでください。

【区画の番号】{bay_id}
【区画の中のロケーションの並び】{location_layout}
（例：上段 左から A-12-1-1、A-12-1-2 ／ 中段 左から A-12-2-1 …）
【ロケーションごとの在庫データ】{stock_rows}
（ロケーション、品目コード、品名、品番、在庫数、ケースの入り数）
【品目の見本の写真】{sample_images}
【区画の写真】{bay_photo}

【ロケーションごとに付ける種類（status）】
ok / empty / unexpected / other_item / mixed / overflow / not_visible

【厳守事項】
- empty は、棚の奥（背板や奥の壁）まで見えていて、物が無いときだけです。
  奥が見えなければ not_visible にしてください。
- 手前に見える品目が奥にもあるとは考えないでください。
- 品目は、箱の品番・品名の文字か、見本の写真との見た目の一致で見分けてください。
  どちらでも見分けられなければ not_visible にしてください。
- 個数を数えないでください。在庫数と大きく矛盾する見え方のときだけ、
  evidence にその様子を書いてください。
- この区画の外の在庫について、推定を書かないでください。
- 迷ったときに ok を選ばないでください。
- 各ロケーションについて、根拠にした箇所を box_2d（[ymin, xmin, ymax, xmax]、
  0〜1000に正規化）で示してください。
- 見に行くべきかどうかは書かないでください。

「迷ったときに ok を選ばない」を入れないと、問題なしに寄ります。 比較を頼まれると、在庫データの品目名に引っ張られて、似た箱を同じ品目と読みます。見落としは ok の側にだけ起きるので、迷いは not_visible に逃がします。

ロケーションの並びを文章で渡すのも意図してのことです。 写真のどの位置がどのロケーションかを推定させると、段を1つずらしただけで、全部のロケーションの比較がずれます。 並びを先に渡し、ラベルの読み取りの結果と合っているものだけを比較に進めます。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力で、status を列挙型にしたスキーマを渡します。公式の案内では、出力はJSONとして正しくても、値はアプリケーションの側で必ず検証するようにとされているので、スクリプトの側で検証します。

{
  "bay_id": "",
  "photo_quality": "good | retake",
  "label_check": "match | mismatch | unreadable",
  "locations": [
    { "location": "", "expected_item": "", "status": "ok | empty | unexpected | other_item | mixed | overflow | not_visible",
      "evidence": "", "box_2d": [0, 0, 0, 0] }
  ]
}

1つ目の理由は、status と区画の区分を別の層に置けることです。 locations はAIが埋め、区分はスクリプトが規則で決めます。

2つ目は、スクリプトで検証できることです。 返ってきた location が区画の定義にあるか、box_2d が0から1000の範囲か、ロケーションの数が区画の定義と同じかを確かめます。数が合わなければ、その区画は retake にします。 AIが1つのロケーションを読み飛ばしたまま pass になるのを防ぎます。

3つ目は、box_2d で確認が速くなることです。 一覧で写真に枠を重ね、在庫管理課は枠の付いた箇所だけを見ます。

システムへ連携する

倉庫管理システムへの書き込みは、最後まで作りません。 写真から在庫を直すと、奥が見えなかった棚の在庫を0にするような誤りが、そのまま出荷の引当てに効きます。

人が確認する

1. retake を撮り直す … 判定一覧の「撮り直し」を見回りの最後にまとめて撮ります
2. visit の写真を見る … 在庫管理課が枠の付いた箇所を見て、明らかに写真の誤読なら pass に直します
3. 現場で確かめる … 残ったものを現場に頼みます。置き間違いなら移動し、数の違いが疑われるものはハンディ端末で数え直します
4. 結果を記録する … 現場で確かめた結果（置き間違い／移動の記録漏れ／誤読）を一覧に残します

2番目で、visit を pass に直すのは、写真で明らかなときだけにします。 迷うものは現場で見ます。画面で判断を重ねると、写真が見落としたものを人も見落とします。

4番目の記録が、規則を育てる材料になります。 「誤読」が特定の品目に偏っていれば見本の写真を足し、「移動の記録漏れ」が特定の時間帯に偏っていれば、入荷の手順の側を直します。写真の判定の精度を上げるより、食い違いの出どころを減らすほうが効きます。

目標は、900区画をならして1区画2分です。 撮影に1分ほど、残りが visit の確認と現場への依頼です。visit が多すぎる月は、見本の写真が足りないか、在庫データが古いかです。

例外に対処する

最後の行を省かないでください。 前日の在庫データで比べると、その日に入荷した棚がすべて unexpected になります。 取り込みに失敗した日は、写真だけを受け取って判定を翌朝に回します。

記録を残す

• 区画の写真、区画の番号、撮った人、日時
• 比較に使った在庫データの行（そのときの在庫数と最後に動いた日時）
• Gemini API が返したJSONの全文（写り具合、ラベル、比較）
• スクリプトが決めた区分と、その理由になった status
• 人が区分を直した記録 … どの区画を、どちらに直したか
• 現場で確かめた結果（置き間違い／移動の記録漏れ／誤読）
• 区画ごとの、前回見回った日

判定一覧は、区画を行、月を列にした表でも見られるようにします。 同じ区画が毎月 visit になるなら、その棚の使い方（似た品目の隣り合わせ、入荷の仮置き）に理由があります。

最後の行が、第3章の（d）への答えです。 棚卸で差異が出たとき、その棚を前回いつ見て、何が写っていたかを写真で遡れます。