ユニフォームのレンタル会社が返却品を検品台で撮った写真を Gemini で見て、汚れ・破れ・名札の欠けの候補を拾い、補修と請求の候補の一覧を作る

処理の起点を決める

品物の番号を読み取ったあと、担当が足元のボタンを押したときに撮ります。 表を置いて1回、裏返して1回押し、2枚がそろったところで1着分としてAIに渡します。 番号を読まずにボタンを押した写真は、どの服のものか分からないので撮っても渡しません。

連続で撮って動画のように流す形にはしません。 広げる途中の写真や、手のかかった写真が混ざり、同じ破れが2回数えられたり、手の影が汚れとして出たりします。

袋の区切りは、回収袋の札で決めます。 次の袋の札を読んだときに、前の袋の一覧を閉じます。札を読まずに次の袋の服を置いた場合は、品物の番号の取引先が前の袋と違うことでサーバーが気づき、担当に札の読み忘れを知らせます。

入力データを集める

質を決めるのは、台帳の「名札の位置」と「色」です。 名札が左胸にあるはずの服で、左胸に何も写っていなければ「名札が無い」と言えます。位置が分からないと、AIは服全体から名札を探し、ポケットの縫い目や刺しゅうを名札と取り違えます。 色は、紺の作業服の油じみと、白い調理衣の油じみで見え方が違うので添えます。

取引先の業種を添えるのは、汚れの見え方のためです。 工場の作業服の油は洗えば落ちることが多く、塗料は落ちにくい。業種が分かれば、AIは同じ黒いしみを「油に見える」「塗料に見える」と分けて返しやすくなります。 ただし、落ちるかどうかはAIに言わせません。

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

写真は、固定カメラからサーバーが直接受け取ります。 カメラの製品によって受け取り方が違うので、使うカメラの連携の機能に合わせて作ります。番号の読み取りと足元のボタンは、同じ端末からサーバーへ送ります。 番号と写真が同じ端末から届くので、取り違えが起きにくくなります。

品物の情報は、番号で台帳から引きます。 取引先・着用者の番号・品目・色・名札の位置を取り出し、着用者の名前はAIに渡しません。 名前は台帳の中にあれば足り、写真の判定には要らないからです。

Gemini API へは、1着の表と裏の写真と品物の情報をまとめて渡します。 「1枚目が表、2枚目が裏」「名札は表の左胸」のように、写真と位置の関係を添えます。

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

AIへ渡す前に整形する

1. 枠の切り出し … 検品台の枠の印を手がかりに、服の部分だけを切り出します
2. 明るさと色の確認 … 台の隅の灰色の板の色を見て、照明の切れや色のずれを見ます。白い調理衣の黄ばみは色で見るので、ずれた写真は渡しません
3. 手の写り込みの確認 … 服の上に手や腕がかかっていれば、撮り直しにします
4. 広がり方の確認 … 袖や裾が折れて大きく隠れている写真は、置き直しにします
5. 縮小 … 長い辺を1,800ピクセル程度にします。ほつれやボタンの欠けが見える大きさを残します
6. 名札の位置の印 … 台帳の位置から、写真のおおよその範囲をサーバーが計算して添えます

4番目を省かないでください。 袖が折れたまま撮ると、袖口のほつれと肘の破れが写らず、AIは何も返しません。 返さなかったことを「傷みが無い」と読むと、補修の要る服がそのまま着用者に戻ります。

6番目の範囲は、品目ごとに置き方を決めてはじめて効きます。 襟を台の上の端の印に合わせ、身頃の中心を台の中心の線に合わせる、と決めておけば、左胸の名札は毎回ほぼ同じ所に写ります。 置き方がばらつく品目は、範囲を広めに取り、not_visible が増えないかを1週間見てから狭めます。

AIに処理させる

させるのは、候補の種類と枠を返すこと、名札の有無を返すこと、写っていない所を返すことだけです。

名札を「位置を指定して、3つのどれか」で返させるのが、この構成の要です。 「名札がありますか」とだけ聞くと、AIは胸のポケットの縁や会社のロゴの刺しゅうを名札と答えます。台帳の位置を渡し、そこに付いて見えるかだけを答えさせれば、取り違えが減ります。 peeling を分けるのは、はがれかけが洗濯の途中で取れるからです。

大きさの目安を返させるのは、請求の候補の材料にするためです。 契約書に「通常の使用を超える」としか書かれていなくても、主任が「手のひらより大きい焼け焦げは候補にする」と決めておけば、サーバーがその目安で一覧に振り分けられます。

1行目がいちばん起きやすい失敗です。 大きな焼け焦げがあると、AIは「通常の使用を超える損傷のため、請求の対象です」と書きたがります。その言葉が一覧に入ると、営業の担当は契約書を確かめる前に請求の前提で話してしまいます。 返すのは見え方と大きさの目安までにします。

指示内容を固定する

あなたはユニフォームのレンタル会社で、洗濯の前の返却品の写真を見る手伝いをする係です。
品目は {作業服の上着}、色は {紺}、取引先の業種は {金属加工の工場} です。
1枚目が表、2枚目が裏です。名札は {表の左胸} に付いているはずで、
写真のおおよその範囲は {1枚目の [120, 520, 260, 760]} です。

【やること】
1. 次の種類の候補を探し、表か裏か、枠を [ymin, xmin, ymax, xmax] の順で、
   0〜1000 に正規化して返す。見え方を短く書き、大きさの目安を選ぶ。
   paint_like（塗料に見える汚れ）、oil_like（油に見える汚れ）、ink_like（インクに見える汚れ）、
   scorch（焼け焦げ）、tear_hole（破れ・穴）、fraying（ほつれ）、
   button_missing（ボタンの欠け）、zipper_fault（ファスナーの不良）
   大きさの目安は coin / palm / larger のどれかにする。
2. 名札の位置に、present / peeling / missing / not_visible のどれかを選ぶ。
3. 服に付いたままに見える物があれば、attached_items に位置だけを書く。
4. 折れて隠れている所があれば、hidden_parts に書く。

【厳守事項】
- 名札の名前を読まないでください。文字について何も書かないでください。
- 名札の位置の範囲の外にある刺しゅうやロゴを、名札として扱わないでください。
- 汚れか、生地の柄・影・しわか分からないものは unclear にしてください。
- 請求するか、廃棄するか、洗えば落ちるかを書かないでください。
- 汚れの原因や、着用者の使い方について書かないでください。
- 衛生上の扱いが要るかについて書かないでください。
- 候補が無いとき、傷みが無い、問題ない、と書かないでください。

「名札の名前を読まない」を最初に置くのは、要らない個人情報を作らないためです。 何も言わないと、AIは親切に「名札には『田中』と書かれています」と返し、その文字が一覧とログに残ります。 名前は台帳にあれば足ります。

「位置の範囲の外の刺しゅうを名札として扱わない」は、取り違えを防ぐ線です。 作業服には会社のロゴや部署の刺しゅうがあり、範囲を渡さないと、名札が無い服を present と答えます。

請求の候補の説明の文は、別の呼び出しで作ります。 担当が確かめた候補と写真の番号だけを渡し、「見え方と大きさだけを書く」「請求の対象だ、通常の使用を超える、と書かない」「着用者について書かない」を入れます。営業の担当が取引先に見せる材料なので、判断の言葉を混ぜません。

出力形式を固定する

1着ごとに、次の形の JSON で受け取ります。 kind、size、name_tag は enum で決まった文字列に絞ります。

{
  "item_no": "U-0482-117",
  "findings": [
    { "side": "front | back", "box_2d": [610, 300, 720, 455],
      "kind": "paint_like | oil_like | ink_like | scorch | tear_hole | fraying | button_missing | zipper_fault | unclear",
      "size": "coin | palm | larger",
      "note": "右の裾の上に、灰色の固まったような汚れが手のひらほどの広さで見える" }
  ],
  "name_tag": "present | peeling | missing | not_visible",
  "attached_items": [ { "side": "front", "box_2d": [140, 300, 210, 360] } ],
  "hidden_parts": ["左の袖口が折れて見えない"]
}

1つ目の理由は、品物の番号と候補が1つの記録になることです。 紙の控えから打ち込む工程が無くなり、番号の打ち違いで別の着用者の服に補修が付く誤りが消えます。

2つ目は、サーバーが規則で一覧に振り分けられることです。

要は、AIの答えを一覧の都合で書き換えないことです。 請求の目安を変えても、JSON を読み直すだけで一覧を作り直せます。

3つ目は、請求の候補に表と裏の写真がそのまま付くことです。 洗濯の前の写真が番号と一緒に残るので、洗ったあとで証拠が消える（d）がなくなります。

システムへ連携する

台帳と契約書へは書き込みません。 廃棄や品物の入れ替えを台帳に反映するのは主任で、請求の結果を書くのは営業の担当です。

人が確認する

1. 印の所を手で確かめる … 赤の印から順に、触れて確かめ、補修の箱か取り分けの棚に入れます
2. 印の無い所も従来どおり見る … ポケットの中、袖の内側、襟の裏を見て、写らなかった傷みは画面で足します
3. unclear・not_visible・取り外し忘れの物を必ず見る … 取り外し忘れの物は取引先に返す箱へ入れます
4. 主任が請求の候補を選ぶ … 1日の終わりに写真を見て、営業の担当へ回すものを選びます
5. 営業の担当が契約書と照らす … 取引先と話してから請求するかを決めます

2番目を省かないでください。 ポケットの中のペンのインク漏れや、襟の裏のほつれは、手に取ったときにしか分かりません。 印の無い所を見ない運用にすると、一覧は速く出ても、着用者に戻る服の質が下がります。

目標は、900袋をならして1袋2分です。 不良の少ない事務服の袋は1分ほどで済み、工場の作業服の袋は汚れの候補が多く、数分かかります。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの精度の問題ではなく、タグと置き方と照明の問題です。 6行目は、note に「請求」「通常の使用」の言葉や、名札の範囲の文字が入っていないかをサーバーで見ます。

記録を残す

• 1着ごとの表と裏の元の写真と、AIに渡した写真
• 渡した品物の情報（着用者の名前は含めない）と、Gemini API が返した JSON
• 担当が直した内容（外した印・足した傷み・名札の判定の直し）
• 補修の指示と、請求の候補として主任が選んだもの、営業の担当の結論
• 名札の作り直しの指示と、作り直した名札が付いた日

3つ目が、請求の目安と撮り方を直す材料になります。 unclear が特定の品目の柄で続くなら、その品目の見本を足します。取引先ごとの請求の候補の数も出せますが、営業の担当が取引先と話す前の数であることを、表に書いておきます。