ホテルのリネン室で撮ったシーツ・タオルのしみと破れの写真から、再洗い・補修・廃棄の区分を付け、品目ごとの廃棄枚数を補充の発注に使える形で集計する

処理の起点を決める

時間主導型トリガーを10分ごとに動かし、品目のフォルダに新しく入った写真を処理します。 写真の保存そのものを起点にする方法もありますが、タブレットのアップロードの遅れで写真が途中の状態のまま処理されることがあるので、保存から2分以上たった写真だけを取り出します。

トリガーは、リネン室の共有のアカウントで作ります。 インストール型トリガーは、作った人のアカウントで動くとされています。担当者個人のアカウントで作ると、その人が異動したときに止まります。時刻は少しずれることがあるとされていますが、10分ごとの処理なら問題になりません。

リネンの到着の時間帯に合わせて、処理する時間を決めます。 工場の便は朝と午後の2回です。スクリプトの最初で時刻を見て、7時から20時の外なら何もせずに終わります。 夜間のトリガーの実行時間を節約できます。

トリガーの合計の実行時間には、1日の上限があります。 公式のページでは、一般のアカウントで1日90分、Google Workspace のアカウントで1日6時間とされています。7時から20時に10分ごとに動かすと1日78回で、写真の無い回は数秒で終わりますが、写真のある回は API の応答を待つ時間がかかります。 一般のアカウントでは足りなくなることがあるので、Google Workspace のアカウントで動かす前提にします。

入力データを集める

質を決めるのは、撮影台です。 格子のマットの上に広げれば、AIは損傷の大きさを「何マスか」で答えられます。 格子が無いと「大きい」「小さい」としか言えず、基準表に当てはめられません。マットは白いリネンが映える濃い色にし、格子は10cmの線で引きます。

再洗いの札は、2回目の不良を見分けるための決まりです。 再洗いに回すとき、リネンの角に赤い洗濯ばさみを付けます。工場から戻って再び不良になったものは、札が付いたまま撮影台に載ります。AIは札の有無だけを見て、基準表が「札があってしみが残れば廃棄」と決めます。 第3章の（b）を、写真に写る印で解きます。

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

品目は、AIに見分けさせずにフォルダで決めます。 シングルとダブルのシーツは、広げて撮った写真では見分けがつきません。担当が品目ごとにまとめて撮るので、フォルダを選ぶ手間は1束に1回です。 AIには、写真の品目がフォルダの品目と食い違って見えるときだけ、印を付けさせます。

写真は、ファイルの内容を Base64 にしてリクエストに入れます。 タブレットの写真は数MBなので、20MBの上限に収まります。撮影の解像度をタブレットの既定より下げると、しみの輪郭が粗くなるので、下げずに撮ります。

返ってきた box_2d は、写真の縦横の大きさに掛け直して使います。 座標は0から1000に正規化されているので、元の写真の幅と高さを掛けて1000で割れば、ピクセルの位置になります。 判定の一覧から写真を開いたときに、その位置に枠を重ねて見せれば、担当は大きなシーツの上で小さなしみを探さずに済みます。

AIへ渡す前に整形する

1. 保存から2分以上たった写真だけを取る … アップロードの途中のファイルを処理しません
2. 処理済みの一覧と照らす … ファイルID で照らし、二度処理しません
3. ファイルの形式を確かめる … JPEG か HEIC 以外は、判定の一覧に「形式の確認が要る」と書きます
4. 画像の向きを確かめる … 公式のページでも、画像の回転が正しいかを確かめるよう勧めています。タブレットの向きの設定を固定します
5. ぶれた写真を除く … AIに写りの良し悪しを返させ、「ぶれ」「暗い」「格子が写っていない」は撮り直しに回します

5番目は、AIにさせる前処理です。 写りの悪い写真で判定させると、しみが「無い」と出て、不良のリネンが客室に戻ります。 写りの判定を先に置き、悪ければ損傷の判定をさせません。

AIに処理させる

させるのは、写真に写っている損傷の事実を、決まった選択肢で答えることだけです。

1行目が、この構成の要です。 AIに「廃棄すべきか」と聞けば答えますが、その答えの基準は誰も決めていません。 事実だけを返させ、区分は基準表で決めます。基準表の例です。

破れの形を記録するのは、第3章の（d）のためです。 直線の裂けは、機械に引っかけたときにできやすい形と現場で言われますが、それを工場の責任と決めるのは購買課と工場の話し合いです。AIは形を記録するだけで、写真付きの一覧が話し合いの材料になります。

指示内容を固定する

あなたはホテルのリネン室で、洗濯から戻った不良のリネンの写真を見て、
損傷の事実を記録する担当です。区分（再洗い・補修・廃棄）は決めないでください。

【撮影台の決まり】
- リネンは濃い色のマットの上に広げてあり、マットには10cm間隔の格子が引いてあります。
- 2回目の不良のリネンには、角に赤い洗濯ばさみ（再洗いの札）が付いています。
- この写真の品目は「{item}」です（フォルダの名前）。

【手順】
1. 最初に写りを判定してください（ok／blurred／dark／no_grid）。
   ok でなければ、損傷の判定はせず damages を空にしてください。
2. 写っている損傷をすべて挙げてください。1枚に複数の損傷があれば、それぞれ1件にします。
3. 損傷ごとに、種類、格子のマス数での大きさ、位置（縁から5cm以内なら hem）、
   しみなら色、破れなら形を選んでください。
4. 再洗いの札の有無を答えてください。

【厳守事項】
- 選択肢にないものは選ばず、分からなければ unknown にしてください。
- 損傷が見当たらないとき、写りが ok であれば none を1件だけ返してください。
  写りが悪いのに none を返さないでください。
- しみの成分（血液、油、化粧品など）を推し量って書かないでください。
- 誰の責任か、工場の扱いによるものかを書かないでください。
- 写真の品目が「{item}」と違って見えるときは item_mismatch を true にしてください。
- note には、判断に迷った理由だけを短く書いてください。

「区分を決めないでください」を冒頭に書いているのは、何も言わなければ区分を答えるからです。 写真を見せて損傷を聞けば、AIは親切に「廃棄をおすすめします」と付け足します。その一言が判定の一覧に紛れ込むと、基準表の区分と食い違う答えが2つ並びます。

「写りが悪いのに none を返さない」も同じくらい大事です。 ぶれた写真の中のしみは、見えないだけで、無いわけではありません。写りの悪い写真が1日に何枚あったかを数えておくと、撮影台の照明や担当の撮り方を直す目安になります。

出力形式を固定する

次の形のJSONで受け取ります。 スキーマは response_format に入れ、選択肢は enum で決めます。

{
  "photo_quality": "ok | blurred | dark | no_grid",
  "damages": [
    {
      "type": "stain | tear | fray | burn | yellowing | none",
      "size": "under_1 | 1_to_3 | over_3 | unknown",
      "position": "hem | body | unknown",
      "stain_color": "light | colored | unknown",
      "tear_shape": "straight | irregular | unknown",
      "box_2d": [0, 0, 0, 0]
    }
  ],
  "rewash_tag": "present | absent | unknown",
  "item_mismatch": false,
  "note": ""
}

1つ目の理由は、選択肢を enum で縛れることです。 公式のページでは、スキーマに合ったJSONでも値が意味の上で誤っていることがあり、アプリケーションの側で値を確かめるよう案内されています。選択肢が決まっていれば、基準表との突き合わせは文字列の一致で済み、想定外の値は Apps Script の側で「判断できない」に落とせます。

2つ目は、damages を配列にして複数の損傷を持てることです。 縁のほつれと中央のしみが同じシーツにあれば、基準表はいちばん重い区分を採ります。 1件にまとめさせると、どちらかが落ちます。

3つ目は、box_2d で損傷の位置を写真の上に示せることです。 判定の一覧で写真を開いたとき、枠の付いた写真なら担当は損傷を探さずに済みます。

システムへ連携する

在庫表は、この構成からは書き換えません。 廃棄の枚数を在庫から引くのは、担当が廃棄を確かめて袋に入れた後です。判定の一覧で「廃棄（確認済み）」になった枚数だけを、購買課が週に1回在庫表に反映します。

リネン工場には、この構成から何も送りません。 工場への申し入れは、購買課が写真付きの一覧を見て決め、話し合いの場で見せます。

人が確認する

人が必ず確かめるのは、廃棄と「判断できない」です。 再洗いと補修は、一覧で区分を見て仕分けます。

1. 廃棄は写真と実物の両方を見る … 写真の枠の位置を実物で確かめ、廃棄の袋に入れたら一覧で「確認済み」にします
2. 「判断できない」は課長の棚に置く … 課長が夕方にまとめて見て、区分を決めます。決めた区分は一覧に書き、基準表に足すかを週に1回考えます
3. 撮り直しは、その場で撮る … 写りが悪いと出たものは、すぐに撮り直します
4. 品目の食い違いは、フォルダを確かめる … 別の品目のフォルダで撮っていれば、ファイルを移します
5. 再洗いと補修で違うと思ったら直す … 直した区分と理由を一覧に残します

2番目の「基準表に足すか」が、この構成を育てる部分です。 課長が「判断できない」に下した区分は、基準表に書かれていない組み合わせです。同じ組み合わせが続けば、基準表に1行足します。

タブレットで見る判定の一覧は、確認の要るものが上に来る並びにします。 「判断できない」「撮り直し」「廃棄（未確認）」を先頭に、再洗いと補修をその下に並べます。担当は上から順に片付ければ、確認の漏れが一覧の上に残って見えます。

目標は、2,400枚をならして1枚1分です。 撮影に数十秒、廃棄の確認に1分前後、再洗いと補修は一覧を見て仕分けるだけです。

例外に対処する

上から3行目は、写真の限界です。 色の薄いしみは、照明によって見え方が変わります。それを写真で決めきろうとせず、再洗いの札で2回目に拾う設計にしています。

記録を残す

• 写真（品目のフォルダ）と、処理済みの一覧（ファイルID、処理の日時）
• Gemini API が返したJSONの全文と、そのときの基準表の版
• 区分と、人が直した区分と理由
• 廃棄を確かめた担当と日時
• 日次・月次の品目×区分の枚数
• 直線の裂けの件数と写真の一覧

基準表の版を残すのは、基準を変えたときに過去の集計の意味が変わるからです。 「札ありのしみは廃棄」を後から変えると、変える前の月の廃棄の枚数と比べられなくなります。