トラックの荷台の積み込み後の写真から床と高さの空きを見分け、便ごとの推定積載率と、同じ方面の便の積み合わせの候補を出す

処理の起点を決める

Python のプログラムを15分ごとに起動し、便のフォルダを見回ります。 積み込みは早朝と昼に集中します。その日のうちに便ごとの数字がそろえば、翌朝の候補の一覧に間に合います。 写真1枚ごとに動かす仕組みにはしません。

1つの便の写真がそろってから処理します。 ウイング車は左右の側面の2枚、箱車は後ろの扉からの1枚と、扉の内側から荷台の壁を写した1枚です。決めた枚数がそろい、最後の写真から15分たった便を「そろった」とみなします。そろわないまま出発時刻を過ぎた便は、「写真の不足」として一覧に出します。

翌朝の一覧は、前日の全部の便がそろってから作ります。 夜の便の写真が遅れて届くことがあるので、朝の決まった時刻に一覧を作り、その時点で未処理の便を数として出します。 未処理の便を除いて候補を作り、除いたことを一覧の上に書きます。

入力データを集める

質を決めるのは、車両台帳の「床の枠」です。 荷台の床を、パレットを置く単位で前後の列と左右に分けた枠として持たせます。たとえば「前後8列 × 左右2」の荷台なら16枠です。枠の数が台帳にあって、はじめて「何枠中何枠」と数えられます。 荷物がパレットに載らない荷主の便でも、同じ枠を床の区切りとして使います。

積み上げの段は、荷台の高さに対して何段まで積めるかの上限です。 荷物の高さは荷主ごとに違うため、段の上限は荷主ごとの目安として台帳の別の表に持ちます。 同じ車両でも、背の高い荷物なら2段、低い荷物なら3段、と変わります。

出荷データの重量は、AIに渡しません。 AIに重量を渡すと、重い便の写真を「埋まっている」と答えやすくなります。 写真の判定と重量の計算を分け、合わせるのはプログラムです。

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

Python のプログラムが、次の順に集めます。

AIには、「この荷台は前後8列 × 左右2の枠」という枠組みを渡します。 写真だけを見せて「何％か」を聞くと、写真の構図で答えが変わります。枠の数を先に渡し、枠ごとに答えさせると、同じ荷台なら同じ基準で数えられます。

箱車の奥行きは、荷台の壁の目印で読みます。 荷台の左右の壁に、前から1列ごとに番号を書いたシールを貼っておきます。 後ろの扉から撮った写真で、荷物の最後尾がどの番号の目印の位置にあるかを答えさせれば、その手前の列は空いていると分かります。最後尾より奥の列は、埋まっていると見なさず「見えない」として扱います。

写真は base64 にしてリクエストに直接入れます。1便2枚なので、20MBの上限には通常届きません。大きすぎる写真は前処理で縮めます。呼び出しは /v1beta/interactions に、API キーを x-goog-api-key のヘッダーに入れて送ります。 画像ごとに resolution を指定でき、壁の目印を読む箱車の写真は high、側面を開けたウイング車の写真も同じく high から始め、目印が読めない車種だけ写真の撮り方を見直します。

AIへ渡す前に整形する

1. 枚数と名前の確認 … 車種ごとに決めた枚数がそろい、便の番号が配車表にあるかを見ます
2. 向きの補正 … 写真の向きの情報で、横倒しの写真を正しくします
3. 写りの確認 … 暗い荷台の中でぶれた写真、扉が半分しか開いていない写真は「撮り直し」とします
4. 大きさの調整 … 長辺が大きすぎる写真は縮めます。壁の目印の番号が潰れない大きさは残します
5. 人の写り込みの確認 … 荷台の中に人が大きく写っている写真は、AIに送りません
6. 枠組みの作成 … 車両台帳から「車種、前後の列の数、左右の数、目印の間隔」を指示に入れる形にします
7. 重複の確認 … 同じ便に同じ写真が二度送られていないかを、撮影の時刻とファイルの中身で確かめます

3番目の「暗い荷台」は、箱車でよく起きます。 奥が暗く写ると、空いている奥を「見えない」ではなく「空き」と答えやすくなります。 ドライバーには、荷台の照明をつけて撮る決まりを伝えます。

撮り直しは、出発の前でなければ頼めません。 前処理で撮り直しになった便は、すぐにドライバーのアプリに知らせ、出発後なら「撮り直しできず」として記録だけ残します。

AIに処理させる

させるのは、渡した枠組みに沿って、床の枠ごとに次の3つを答えることだけです。

荷台の単位でも2つ答えさせます。 荷物が枠をまたいで斜めに置かれているか（irregular_loading）と、荷崩れや倒れた荷物が見えるか（shifted_cargo）です。後者は積載率とは別に、配車の担当に知らせます。

2行目がいちばん大事な区別です。 奥の見えない枠を「埋まっている」と答えれば積載率は高く出て、本当は空いている便が候補から消えます。 「空き」と答えれば、満載の便を積み合わせの候補に挙げてしまいます。 どちらでもない not_visible を用意し、迷ったらそれを選ばせます。

指示内容を固定する

あなたは、積み込みを終えたトラックの荷台の写真を見て、床の枠ごとの状態を書き出す立場です。
同じ便の写真を複数枚渡します。写真に見えるものだけを答えてください。

【この荷台の枠組み】
車種：{body_type}（wing または van）
床の枠：前後 {rows} 列 × 左右 {cols}。列の番号は前（運転席側）から 1, 2, 3 … とする
壁の目印：前から1列ごとに番号のシールを貼ってある

【枠ごとに答えること】
- row, col：枠の位置
- fill：full（床が埋まっている）/ partial（一部だけ）/ empty（空いている）/ not_visible（見えない）
- stack：見える積み上げの段の数。数えられなければ空
- photo_no と box_2d：その枠が写っている写真の番号と位置

【荷台の単位で答えること】
- last_marker：箱車のとき、荷物の最後尾にあたる壁の目印の番号。読めなければ空
- irregular_loading：荷物が枠をまたいで斜めに置かれているか（true / false）
- shifted_cargo：荷崩れや倒れた荷物が見えるか（true / false）と、その位置

【厳守事項】
- 積載率や「何割積んでいるか」を書かないでください。
- 手前の荷物に隠れて奥が見えない枠は not_visible にしてください。
  奥を埋まっているとも、空いているとも推測しないでください。
- 暗くて見えない枠も not_visible です。暗いことを空いていることとして扱わないでください。
- 重さ、過積載かどうか、積み付けが安全かどうかを書かないでください。
- 荷物のラベル、伝票、商品名の文字を読み取って答えないでください。
- 写真に写っている人について、何も書かないでください。

「暗いことを空いていることとして扱わない」は、箱車のために入れています。 入れないと、照明の届かない奥を empty と答えます。暗い荷台の奥は、多くの場合、積み込みの最初に置いた荷物で埋まっています。

「何割積んでいるか」を禁じるのは、言わないと書き添えるからです。 枠ごとの答えに加えて「全体で約7割」と書けば、その数字が式で計算した数字と並び、どちらを使うかで担当が迷います。

出力形式を固定する

構造化出力で、便ごとに次の形のJSONを受け取ります。

{
  "trip_id": "20261008-K031",
  "last_marker": 6,
  "irregular_loading": false,
  "shifted_cargo": { "found": false, "photo_no": null, "box_2d": null },
  "cells": [
    { "row": 1, "col": 1,
      "fill": "full | partial | empty | not_visible",
      "stack": 2,
      "photo_no": 1,
      "box_2d": [0, 0, 0, 0] }
  ]
}

fill を enum にして、決めた値以外を返させません。 Gemini API の構造化出力は、/v1beta/interactions の response_format に mime_type: "application/json" とスキーマを入れて指定し、enum、required、整数の minimum と maximum が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 プログラムで、cells の数が枠の数と合うか、stack が段の上限を超えていないかを確かめ、合わない便は「確認が要る」にします。

積載率は、プログラムが次の式で計算します。

partial を0.5と置くのは、半分埋まっているという意味ではなく、「埋まっても空いてもいない」を1つの値にまとめるための約束です。 値は配車課で決め、変えたら変えた日を記録します。途中で値を変えると、前後の月の数字が比べられなくなるからです。

見えない枠は、分母からも分子からも外します。 そのうえで見えない枠の割合を必ず並べて出します。 割合が大きい便の容積の積載率は、当てにならない数字です。3割を超える便は、候補の組から外します。

積み合わせの候補は、次の条件をすべて満たす便の組です。 同じ日、届け先の方面が同じ、届ける時間帯が重ならない、2便の容積の積載率の合計と重量の積載率の合計がどちらも1を下回る、見えない枠の割合がどちらも3割以下。条件は配車課が決め、プログラムの設定として持ちます。

システムへ連携する

配車表は読み取りだけです。 積み合わせの候補が出ても、配車を自動で組み替えません。 荷主との約束の時間、ドライバーの拘束時間、車両の点検の予定は、配車の担当が見て決めます。

運行台帳には、これまでの目測の列の隣に「推定」の列を足して書きます。 最初の数か月は両方を並べ、目測と推定の差の大きい便から、撮り方か枠組みを見直します。

人が確認する

配車の担当が見るのは、次の3つだけです。

1. 「確認が要る」と「写真の不足」の便 … 見えない枠が多い便、枠の数が合わない便、写真が来ていない便。撮り方の問題か、車両台帳の誤りかを見分けます
2. 積み合わせの候補の組 … 写真で両方の便の積み方を確かめ、荷主の条件と時間帯を見て、配車の見直しに使うかを決めます
3. 荷崩れが見えた便 … shifted_cargo の便は、運行管理の担当にすぐ回します

そのほかの便は、推定積載率の一覧で流し見て確定します。 全部の写真を開く設計にすると、①の時間は減りません。

最初の1か月は、これまでの目測と並べて動かします。 担当が付けた「7割」「半分」と、推定積載率を便ごとに並べます。差の大きい便を10便ほど写真で見直すと、撮り方、枠組み、段の上限のどれがずれているかが分かります。 差の原因が担当の目測の側にあることも少なくありません。

目標は、1,800件をならして1便0.8分です。 一覧で流す便は数秒、候補の組や確認が要る便は写真を開いて数分かかります。候補の組が多すぎる日は、条件の設定が緩すぎます。 配車課で条件を締めます。

例外に対処する

「未処理」と「写真の不足」を推定積載率の平均に混ぜないでください。 混ぜると、写真の撮り方がそろっていない方面ほど積載率が高く見えることがあります。一覧には件数として別に出します。

記録を残す

• 便ごとの写真と、撮影の時刻、撮ったドライバー
• AIの答え（枠ごとの fill・stack・box_2d、last_marker、荷台の単位の答え）
• 計算した推定積載率と、そのとき使った車両台帳の枠の数と段の上限
• 出荷データの重量と、重量の積載率
• 出した積み合わせの候補の組と、配車の担当が使ったか・使わなかったか
• 方面ごと・荷主ごとの見えない枠の割合

候補の一覧は、たとえば次の形にします。

【積み合わせの候補】2026-10-07 分（未処理 3便を除く）
 方面：県北  K031（容積 0.42／重量 0.35／見えない 0.06）＋ K044（容積 0.38／重量 0.30／見えない 0.13）
             時間帯 午前／午後  → 候補
 方面：県南  K052（容積 0.51／重量 0.72）＋ K058（容積 0.36／重量 0.41） → 重量で不可
 荷崩れ     K067（写真2 右奥）→ 運行管理へ

「使わなかった理由」を残すと、条件の見直しの材料になります。 時間帯、荷主の指定、荷物の混載の不可など、同じ理由で使われない候補が続くなら、その条件を設定に足します。