倉庫が棚の列を撮った写真を Gemini で見て、入庫に使える空きのロケーションと置き方の乱れの一覧を作る

処理の起点を決める

列の写真が届いたときに、列ごとに動きます。 リーダーがタブレットで列の番号を選び、3〜4枚を撮って送ると、サーバーがその列を処理します。1枚ごとに動かすと、まだ撮っていない区間の間口を「写っていない」と返し、撮り直しの知らせが無駄に出ます。 送信のボタンを押したときに、その列の写真がそろったとみなします。

朝の見回りの締めの時刻に、1日分をまとめます。 締めの時刻（例：8時30分）になったら、30列のうち写真の届いていない列を数え、リーダーに知らせます。入庫の担当が空きの表を待っている間に、見ていない列が残っていないかを先に分かるようにします。

乱れの直しが済んだら、同じ列をもう一度撮ります。 直した担当が列の番号を選んで撮り直すと、その列の乱れの候補だけを前の写真と並べます。直したことの確認も、写真で残すためです。

入力データを集める

質を決めるのは、撮る位置と間口の一覧です。 撮る位置は、列の通路の反対側の柱の前、床に貼った印の上、と決めます。1列を3〜4区間に分け、区間の左端と右端の間口の番号を写真に添えます。 番号が分かれば、AIは写真の中の間口を一覧の番号に当てはめられます。

間口の番号の表示がラックに付いていることが前提です。 梁に貼った番号の札が写真に写れば、AIは番号を読んで当てはめを確かめられます。札が欠けている間口は、乱れの一覧の「表示の欠け」として返させ、貼り直しの対象にします。

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

写真は、タブレットの画面からサーバーへ送ります。 画面では列の番号と区間を選ぶだけにし、撮った時刻と撮った人のIDを一緒に送ります。 写真のファイル名に頼ると、別の列の写真が紛れても気づけません。

間口の一覧と在庫は、倉庫管理システムから読みます。 毎朝の見回りの前に、ロケーションの一覧と在庫の一覧を書き出す機能があればそれを使い、無ければ前夜の締めの書き出しを読みます。倉庫管理システムとのつなぎ方は、使っている製品が出せる形式（CSVの書き出し、APIなど）に合わせて個別に作ります。

Gemini API へは、1列につき1回、区間の写真と間口の一覧をまとめて渡します。 写真には区間の番号と左端・右端の間口の番号を添え、段は下から1段目、2段目と数えることを指示の文に書きます。上から数えるか下から数えるかを決めないと、段の番号が入れ替わった結果が返ります。

有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し（有料の枠で55日、無料の枠で1日）、store=false で保存しない動きにできると案内されています。store=false にすると前の回のやり取りを引き継ぐ使い方はできないので、呼び出しは毎回、必要な写真と一覧をそろえて送ります。

AIへ渡す前に整形する

1. 向きの補正 … タブレットの写真の向きの情報で回転しているだけのものは、画素を回転させます
2. 縮小 … 区間の写真は長い辺を2,000ピクセル程度に縮めます。4段目の間口の札が読める大きさは残します
3. 塗りつぶし … 通路を歩いている作業者の顔、フォークリフトの運転者の顔を塗りつぶします
4. 暗さとぶれの確認 … 照明の陰になった写真や、手ぶれの大きい写真は、AIに渡さずに撮り直しの候補にします
5. 大きさの確認 … 1列分の写真と指示の文を合わせて20MBを超えないかを見ます。超えるときは区間を2回に分けます
6. 間口の一覧の付け足し … その列の段×間口の一覧と、区間ごとの左端・右端の番号を指示の文に入れます

4番目を軽く見ないでください。 倉庫の照明は通路の真上にあり、ラックの奥と4段目は暗く写りがちです。 暗い写真では空のパレットと床の見分けがつかず、AIは「空き」と返しがちです。暗い写真で「空き」と出ることが、入庫の当日にいちばん困る誤りです。

AIに処理させる

させるのは、間口ごとに空きの状態を返すこと、置き方の乱れの候補を枠で返すこと、間口の札の番号を読むことだけです。

empty と blocked と not_visible を分けて返させるのが、この構成の要です。 荷が見えない間口を全部 empty にすると、第1章で書いたとおり、入庫の当日に行き場の無いパレットが出ます。 not_visible が1つでも残る列は、サーバーが空きの表に「未確認」と書き、撮り直しの依頼を出します。

1行目がいちばん起きやすい失敗です。 傾いた段積みを見せると、AIは「崩れる危険があります」「すぐに撤去が必要です」と書きたがります。その言葉が作業の連絡板に載ると、リーダーが確かめる前に現場が止まります。 返すのは見え方までにし、危ないかどうかはリーダーが現地で決めます。 本当に危ない傾きを見つけたときは、AIの結果を待たずにその場で止めるのが先です。

空きの数え方は、サーバーが次のように振り分けます。

指示内容を固定する

あなたは物流倉庫で、朝の見回りの写真を見る手伝いをする係です。
この列は C07 です。段は床に近い方から 1段目、2段目、3段目、4段目と数えます。
写真の区間と、左端・右端の間口の番号は次のとおりです。
{写真1: 区間A 左端 C07-*-01 右端 C07-*-04, 写真2: 区間B 左端 C07-*-05 右端 C07-*-08 ...}

【この列の間口の一覧】
{C07-1-01, C07-1-02, ... C07-4-16}

【やること】
1. 間口の一覧の1行ずつについて、empty / occupied / partly_used / blocked /
   not_visible のどれかを選ぶ。一覧にない間口を足さない。一覧の間口を飛ばさない。
2. blocked のときは、理由を neighbor_overhang / empty_pallet / temporary_load /
   other から選ぶ。
3. 次の種類の乱れを探し、写真の番号と枠を [ymin, xmin, ymax, xmax] の順で、
   0〜1000 に正規化して返す。近くの間口の番号と、見え方を短く書く。
   梁からのはみ出し、通路への仮置き、空のパレットの置きっぱなし、
   ラップの破れ、荷の傾き、間口の番号の札の欠け
4. 写真に写った間口の札の番号を読めた分だけ返す。

【厳守事項】
- 奥が手前の荷で隠れている間口、暗くて床と荷の区別がつかない間口は、
  empty にしないでください。not_visible にしてください。
- 荷が見えなくても、空のパレットや隣の荷がかかっていれば empty にしないでください。
- 乱れか影か分からないものは、kind を unclear にして候補に入れてください。
- 危険かどうか、撤去や積み直しが必要かを書かないでください。
- はみ出しの長さや荷の重さを数字で書かないでください。
- 荷の中身、品番、荷主の名前を書かないでください。
- 人については何も書かないでください。

「一覧の間口を飛ばさない」「隠れている間口を empty にしない」を並べているのは、どちらも同じ失敗を防ぐためです。 何も言わないと、AIは目立つ空きと乱れだけを返し、残りの間口について何も言いません。 その沈黙をサーバーが「使用中」と読んでも「空き」と読んでも、空きの表がずれます。

段の数え方を指示の文の先頭に書いているのは、段の番号の取り違えを防ぐためです。 倉庫によっては上から数える決まりもあり、指示の文とロケーションの番号の付け方を必ずそろえます。 札の番号が読めた間口は、サーバーがその番号と一覧の番号を突き合わせ、合わなければ列全体を needs_check にします。

乱れの直しが済んだ後の見比べは、別の指示で呼びます。 乱れの番号、前の写真の枠、撮り直した写真を渡し、「前の枠の所の見え方が、後の写真で直って見えるか、まだ残って見えるか、比べられないかを選ぶ」と指示します。「安全になった」とは書かせず、見え方の比較だけを返させます。

出力形式を固定する

1列ごとに、次の形の JSON で受け取ります。 status、reason、kind は enum で決まった文字列に絞り、slots は間口の一覧と同じ数を minItems・maxItems で求めます。

{
  "aisle": "C07",
  "slots": [
    { "location": "C07-3-12", "status": "empty | occupied | partly_used | blocked | not_visible",
      "reason": "neighbor_overhang | empty_pallet | temporary_load | other | none", "photo": 3 }
  ],
  "issues": [
    { "photo": 3, "box_2d": [380, 610, 520, 720], "near_location": "C07-3-12",
      "kind": "beam_overhang | aisle_temporary | empty_pallet_left | wrap_torn | load_tilt | label_missing | unclear",
      "note": "右隣の荷の手前の角が、梁の前に出て見える" }
  ],
  "labels_read": [ { "photo": 3, "text": "C07-3-12" } ]
}

1つ目の理由は、slots をそのまま空きの表にできることです。 間口の数がそろっていなければサーバーが呼び直し、not_visible の間口は「未確認」として入庫の担当に見えるようにします。 第3章の（d）の「見なかった間口が空欄に紛れる」が、ここでなくなります。

2つ目は、倉庫管理システムの在庫と並べられることです。 サーバーは間口ごとに在庫の有無を横に置き、次の4つに分けて印を付けます。

3行目を空きの表に入れないのは、意図してのことです。 在庫があるはずの間口が空に見える理由は、写真の見え方か在庫の登録の漏れか、ここでは分かりません。入庫に使うと、登録の漏れた荷の上にパレットを重ねる割付になります。

3つ目は、issues に番号を振れば、直しの依頼と後の見比べの鍵になることです。 サーバーは乱れに「C07-1028-03」のような番号を振り、作業の連絡板と撮り直しの写真に同じ番号を使います。

システムへ連携する

倉庫管理システムへは書き込みません。 この構成が出すのは空きの表までで、ロケーションの状態を書き換えるのは入庫の担当の操作です。 AIの結果をそのまま書き込むと、見え方の誤りが在庫の記録にまで入ります。

作業の連絡板へは、リーダーが選んだ乱れだけを出します。 影や梁の色の違いまで乱れとして出ると、現場がその一覧を読まなくなります。

人が確認する

1. not_visible と blocked を先に見る … 撮り直しで済むか、片付けで空くかを写真で決めます
2. empty を写真でなぞる … 空きと出た間口に、空のパレットや床置きの荷が無いかを見ます
3. partly_used を数え方の決まりに当てる … 荷主を混ぜてよい間口かを確かめ、使うかを決めます
4. 乱れの直しの担当を選ぶ … 今日直すもの、入庫の前に直すもの、様子を見るものに分けます
5. 空きの表を入庫の担当に渡す … 未確認の間口の数を一緒に伝えます

2番目を省かないでください。 empty の誤りは、入庫の当日にフォークリフトの運転者が見つけることになります。 その時点ではパレットを持ったまま別の空きを探すことになり、朝の書き取りよりずっと時間がかかります。

目標は、660件をならして1件2分です。 撮る作業に1分、確かめる作業に1分という想定です。not_visible の多い列が続くなら、撮る位置か照明を見直します。

例外に対処する

上から2行目までが大半を占めます。 どれもAIの精度の問題ではなく、撮る位置と照明、間口の一覧の作り方の問題です。 6行目は、note に「危険」「撤去」「必要」の言葉や重さの数字が入っていないかをサーバーで見ます。

記録を残す

• 列ごとの元の写真と、塗りつぶして AI に渡した写真、撮った時刻と人のID
• 渡した間口の一覧と、Gemini API が返した JSON
• リーダーが直した間口の状態と、直した理由
• 乱れの番号ごとの直しの担当、直した日、前後の写真の組
• そのときの空きの数え方の決まりの版と、入庫の担当に渡した空きの表

3つ目が、数え方の決まりを直す材料になります。 リーダーが empty を blocked に直した間口を数えると、AIが空のパレットを床と見分けられていない列が分かります。列ごとの乱れの件数も出せますが、荷主ごとの片付けの依頼に使うか、作業者の評価に使うかは、別に話し合って決めます。