工務店が現場に届いた建材と納品書の写真を Gemini で見て、品番・数量の表示と破損の候補を読み、発注と照らした検収の記録を作る

処理の起点を決める

受け取った人が、チャットの現場の部屋で「納品終わり」を押したときに、1回の納品分をまとめて動かします。 写真が1枚届くたびに動かすと、まだ撮っていない品目を「写真が無い」と返し、撮り直しの依頼が無駄に飛びます。 「納品終わり」はチャットの決まった言葉か、写真を送る画面のボタンにします。

届く予定の日の夕方に、写真の届いていない納品を数えます。 発注の明細で今日届く予定の行のうち、写真が来ていないものを購買の担当に知らせます。納品が遅れているのか、写真の送り忘れなのかを、その日のうちに分けられるようにします。

違いや破損の知らせは、検収の記録を待たずにすぐ送ります。 建材店への連絡が早いほど、取り寄せ直しが工程に食い込みません。

入力データを集める

質を決めるのは、発注の明細の「入数」と「単位」です。 発注が「石膏ボード 40枚」で、ラベルが「入数 4枚」なら、束が10あれば合います。明細に入数が無いと、写真の束の数から枚数を出せず、比べる数がそろいません。 単位が「枚」「束」「ケース」「坪」でばらばらな明細は、品目ごとに枚数へ直せる列を足してから使います。

届く予定の品目だけをAIに渡すのも、質を決める部分です。 現場の発注の全部を渡すと、写真のラベルと似た品番の、別の日に届く品目にAIが寄せて答えます。 その日の予定の行に絞れば、写真の品目と予定の行の結び付けが速くなります。

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

写真は、チャットの現場の部屋からサーバーが受け取ります。 写真と一緒に、送った人、送った時刻を受け取ります。チャットの製品によって写真の受け取り方が違うので、使っている製品の連携の機能（ボットやWebhookなど）に合わせて個別に作ります。

発注の明細と現場の台帳は、サーバーが表計算から読みます。 現場の番号で明細を引き、届く予定の日が今日と前後1日の行を取り出します。納品の日がずれることがあるので、前後の日も入れます。

Gemini API へは、1回の納品分の写真と届く予定の品目の一覧をまとめて渡します。 写真には番号を振り、どの写真が荷姿・ラベル・納品書かは、AIに分けさせます。 撮る順を決めていても、守られない日があるからです。

有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し（有料の枠で55日、無料の枠で1日）、store=false で保存しない動きにできると案内されています。store=false では前のやり取りを引き継げないので、撮り直しの写真が届いたら、最初の写真と合わせて送り直します。

AIへ渡す前に整形する

1. 向きの補正 … スマートフォンの写真の向きの情報で回転しているだけのものは、画素を回転させます
2. ぶれと暗さの確認 … ラベルや納品書の写真がぶれているもの、夕方の暗い現場で撮ったものは、AIに渡さずに撮り直しの候補にします
3. 縮小 … 荷姿の写真は長い辺を1,600ピクセル程度に縮めます。ラベルと納品書の写真は、品番の文字が読める大きさを残します
4. 塗りつぶし … 運転手や職人の顔、隣の家や通りの人を塗りつぶします
5. 大きさの確認 … 1回分の写真と指示の文が20MBを超えないかを見て、超えるときは品目ごとに分けて呼びます
6. 重複の確認 … 同じ写真が二度送られていれば、1枚にします

3番目を軽く見ないでください。 品番の末尾の1文字で色や左右が変わる建材では、縮めすぎた写真は「読めない」と「違う文字」の区別がつきません。 ラベルの写真は縮めないか、ラベルの部分だけを切り出して大きく渡します。

AIに処理させる

させるのは、ラベルと納品書の文字をそのまま写すこと、梱包の数を返すこと、破損の候補を返すことだけです。

ラベルの文字を「印刷されたとおりに」写させるのが、この構成の要です。 AIは読めなかった文字を、届く予定の品目の品番で埋めたがります。埋めた瞬間、色違いの品番が「発注どおり」に見えます。 読めない文字は ? のまま返させ、? の入った品番はサーバーが突き合わせに使いません。

梱包の数の countable を分けるのは、数の誤りを数字の形で出さないためです。 重なった束を「おそらく10」と返させると、それが検収の記録に「10」と残ります。数えられないなら数えられないと返させ、現場の人に聞きます。

3行目は、ラベルの等級の表示を読ませることと混ぜないでください。 建築基準法には居室の化学物質の発散に対する衛生上の措置があり、施行令にホルムアルデヒドに関する建築材料の技術的基準があります。この構成が返すのは、ラベルに印刷された等級の表示の文字までです。 その表示が設計の仕様に合っているかは、発注の明細に設計の担当が書いた等級と文字列で比べ、合わなければ設計の担当に回します。

指示内容を固定する

あなたは工務店の購買で、現場に届いた建材の写真を見る手伝いをする係です。
現場は {K-0318 の新築}、今日届く予定の品目は次のとおりです。
{1: 石膏ボード 9.5mm 910×1820（入数4枚）, 2: 構造用合板 12mm 910×1820（入数20枚）,
 3: 住宅用断熱材 グラスウール（入数6枚）}
写真の番号は 1〜12 です。

【やること】
1. 写真ごとに、overview / label / delivery_note / other のどれかを選ぶ。
2. label の写真から、品番、品名、色・柄、寸法、入数、ロット、等級などの表示を、
   印刷されたとおりに写す。どの予定の品目のラベルかを番号で示す。
3. delivery_note の写真から、行ごとに品番、品名、数、単位を写す。
4. overview の写真から、予定の品目ごとに見えている束・箱の数を返す。
   束の位置を [ymin, xmin, ymax, xmax] の順で、0〜1000 に正規化して返す。
5. 角の欠け、割れ、濡れ・しみ、梱包の破れ、曲がりの候補を探し、写真の番号と枠と
   種類を返す。見え方を短く書く。

【厳守事項】
- 読めない文字は ? にしてください。予定の品目の品番で埋めないでください。
- 印刷された文字を、より正しそうな表記に直さないでください。
- 束が重なって数えられないときは countable を no にし、数を書かないでください。
- 予定の品目に無いラベルが写っていたら、予定の品目に当てはめずに other_items に写してください。
- 発注どおりか、検収してよいか、施工に差し支えるかを書かないでください。
- 等級の表示が仕様に合っているかを書かないでください。
- 人について何も書かないでください。

「予定の品目の品番で埋めない」と「より正しそうな表記に直さない」を並べているのは、どちらも同じ失敗を防ぐためです。 何も言わないと、AIは予定の一覧を手がかりにラベルを読み、末尾の1文字が違う色違いの品番を、予定の品番に直して返します。 直された品番は突き合わせを通り、施工の当日まで気づかれません。

「予定に無いラベルを当てはめない」は、届いてはいけない物を拾うための線です。 別の現場の建材が紛れて届くことがあり、当てはめさせると、別の現場の品目が今日の品目として数えられます。

建材店への連絡の下書きは、別の呼び出しで作ります。 購買の担当が確かめた違いと写真の番号だけを渡し、「違いは品番・数・見え方の事実だけを書く」「返品や値引きを求める言葉を書かない」「施工の日は渡した日付を写すだけにする」を入れます。

出力形式を固定する

1回の納品ごとに、次の形の JSON で受け取ります。 type、legible、kind は enum で決まった文字列に絞り、photos は渡した写真の数を minItems・maxItems で求めます。

{
  "site": "K-0318",
  "photos": [ { "no": 4, "type": "overview | label | delivery_note | other" } ],
  "labels": [
    { "photo": 5, "planned_item": 1, "product_code": "GB-R95-91?8", "name": "石膏ボード",
      "size": "9.5×910×1820", "pieces_per_pack": "4", "grade_mark": "F☆☆☆☆", "legible": "yes | partly | no" }
  ],
  "note_lines": [ { "photo": 11, "product_code": "", "name": "", "qty": "", "unit": "" } ],
  "packs": [ { "planned_item": 1, "visible_packs": 10, "countable": "yes | no" } ],
  "damage": [
    { "photo": 4, "box_2d": [520, 140, 610, 300],
      "kind": "corner_chip | crack | wet_stain | wrap_torn | bent | unclear",
      "note": "手前の束の右下の角が欠けて、白い芯が見える" }
  ],
  "other_items": []
}

1つ目の理由は、product_code を文字列のまま突き合わせに使えることです。 サーバーは、ラベルと納品書と発注の明細の品番を3つ並べ、1文字でも違えば「品番の違い」、? が入れば「読めない」として担当に回します。

2つ目は、grade_mark を明細の等級と文字列で比べられることです。 合わなければ設計の担当に回し、合っているかの結論はAIにもサーバーにも出させません。

3つ目は、other_items で紛れた荷物が分かることです。 予定に無いラベルが写っていれば、別の現場の建材が届いていないかを、担当が建材店に確かめます。

システムへ連携する

発注の明細へは書き込みません。 取り寄せ直しや発注の変更を明細に反映するのは購買の担当です。自動で書き換えると、読み違いが発注そのものを動かします。

建材店への連絡は、下書きまでにします。 担当が写真を確かめ、言葉を直してから送ります。

人が確認する

1. 品番の違いと破損の候補を先に見る … 写真を開き、ラベルの文字と破損の見え方を確かめ、監督と施工に使えるかを話します
2. 数の違いを確かめる … 現場の人に数を聞き、納品書の数と比べます
3. 一致の納品を流し見る … 一覧で品目と数を見て、検収の記録に入れます
4. 建材店への連絡を直して送る … 下書きの事実と写真の番号を確かめます
5. 月末に請求と突き合わせる … 検収の記録の無い請求の行を探します

3番目の流し見を省かないでください。 一致と出た納品でも、ラベルが別の束のものを撮っていたことがあります。荷姿の写真とラベルの写真が同じ束を写しているかを、一覧の縮小写真で見ます。

目標は、360件をならして1件3分です。 一致の納品は1分ほどで済み、違いや破損のある納品は、建材店への連絡まで含めて10分近くかかります。

例外に対処する

上から2行目までが大半を占めます。 どれもAIの精度の問題ではなく、撮り方と積み方の問題です。 6行目は、ラベルの品番が予定の品番と完全に一致しているのに、legible が partly になっているものをサーバーが疑わしいとして担当に回します。

記録を残す

• 1回の納品分の元の写真と、塗りつぶして AI に渡した写真
• 渡した届く予定の品目の一覧と、Gemini API が返した JSON
• 突き合わせの結果と、担当が確かめた後の結論（一致・違い・破損と、その対応）
• 現場の人に聞いた数と、撮り直しの依頼と応答
• 建材店への連絡と返事、取り寄せ直しの日

3つ目が、撮り方の決まりと発注の明細を直す材料になります。 同じ品目で countable が no になり続けるなら、その建材の積み方では束が数えられません。建材店ごとの違いの件数も出せますが、建材店との話し合いに使うかは、担当が決めます。