客室清掃の仕上がりを点検写真で確かめて、やり直しが要る部屋を拾う

処理の起点を決める

Google フォームの送信を起点にします。 Apps Script のインストール型トリガーには、Google フォームとスプレッドシートの両方で使えるフォーム送信のトリガーがあります。1部屋分の写真が送られた時点で、その部屋だけを判定します。 まとめて処理すると、チェックイン時刻に間に合いません。

インストール型トリガーは、作成した人のアカウントで動きます。 個人のアカウントで作ると、異動したときに止まります。フォームもスクリプトも業務用アカウントで作ります。

取りこぼしを拾うため、時間主導型のトリガーも置きます。 毎分から月1回までの間隔で動かせますが、時刻は少しずらされることがあり、午前9時の繰り返しなら9時から10時の間のどこかで動くとされています。未完了の部屋の再処理だけに使い、正規の経路はフォーム送信にします。

入力データを集める

質を決めるのは点検基準の表です。 項目名だけだと、AIはやり直しの境目を自分で決めてしまいます。「ベッドスローはベッドの中央にあり、左右の垂れが同じ長さ」のように、写真で判断できる文にします。

画角は客室タイプに関係なく、① 入口からの全景 ② 枕元とナイトテーブル ③ 洗面台とアメニティ ④ 浴室 ⑤ トイレ ⑥ デスク周りとゴミ箱の6つに固定します。

表には項目ごとに「判定の方法」の列を持たせます。 値は photo（写真で見る）と on_site（現地で見る）の2つです。

on_site の項目はプロンプトにも入れません。 渡すと、写っていないものにも何か答えようとします。渡さないことが、判定させないいちばん確かな方法です。

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

スクリプトは送信のたびに、6つの質問の回答からドライブ上のファイルを特定して読み込みます。

部屋番号は自由入力にせず、プルダウンで選ばせます。 打ち間違えると、別の部屋の写真で別の部屋を販売可にすることになります。 その日のチェックアウト予定の部屋だけを選択肢に出せれば、さらに減ります。

点検基準の表は判定のたびに読みます。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のどれかか。フォームの質問でも形式を画像に絞ります
2. 枚数の確認 … 6つの画角がそろっているか。欠けた画角は「撮り直し」で返します
3. 大きさの確認 … 合計が20MBを超えそうなら、写真を Files API に置いて参照します
4. 向きの確認 … 公式のベストプラクティスに画像が正しく回転しているかを確かめることが挙がっています。端末の向きを画角ごとに手順書で決めます
5. 解像度の扱い … 縦横とも384ピクセル以下なら258トークン、それより大きい画像は縦横768ピクセルのタイルに分けられ1タイルごとに258トークンです。カメラの解像度を下げるか、media_resolution で1枚あたりのトークンの上限を決めます
6. 重複の確認 … 同じ部屋の送信が2回あれば、後の送信だけを判定し、前の送信は記録に残します

5番目は、解像度を上げても費用が膨らむだけのことがあります。 見たいのは「タオルが2枚あるか」の水準で、細部は現地で見る項目に回してあります。

AIに処理させる

Gemini API は2回呼びます。1回目は写真の確認、2回目は点検の判定です。 1回にまとめると、暗い写真に「ゴミ箱は空」と答えつつ「暗い」とも書く結果が返ります。

1回目（写真の確認）で見るもの

いちばん下の行は別扱いです。 人が写れば削除して撮り直し、私物は忘れ物かもしれないので忘れ物の手順に回します。

2回目（点検の判定）で見るもの

させるのは、photo の項目それぞれについて、見本の写真と比べて基準どおりかを判定し、根拠を書くことだけです。

4行目を許すと、第3章の（b）に戻ります。 気になる点は表に項目として足します。

指示内容を固定する

1回目（写真の確認）

あなたはホテルの客室点検の担当として、清掃後の客室写真が点検に使えるかを確かめます。
点検はまだ行いません。ベッドやアメニティが基準どおりかは判断しないでください。

【この写真の画角】{angle_name}（{angle_description}）
【この画角の見本の写真】（この後に添付）
【確認する写真】（この後に添付）

【確かめること】
1. 見本と同じ画角か（match ／ mismatch）
2. 明るさ（ok ／ too_dark ／ too_bright）
3. ぶれ・ピント（ok ／ blurry）
4. 写すべき範囲が入っているか（ok ／ partial）
5. 人・私物・書類が写っていないか（none ／ person ／ belongings ／ document）

【厳守事項】
- 迷ったときは ok や match を選ばないでください。撮り直しのほうが安全です。
- 客室の備品（タオル、アメニティ、リモコン、案内の冊子など）は私物ではありません。
  それ以外の、かばん・衣類・スマートフォン・飲みかけの容器などは belongings です。
- 鏡や窓に人が映っている場合も person です。
- 写り込んだ書類の文字や画面の表示を読み取って書かないでください。
- reason には、撮り直しの理由を清掃スタッフが分かる短い日本語で書いてください。

2回目（点検の判定）

あなたはホテルの客室点検の担当です。清掃後の客室写真を、見本の写真と点検基準に照らして、
項目ごとに判定してください。写真に写っているものだけを根拠にしてください。

【客室タイプ】{room_type}
【点検項目】（item_id、画角、基準文の一覧）
{photo_items}
【写真】画角ごとに「画角名 → 見本の写真 → 確認する写真」の順で添付します。

【status の選び方】
- ok ............... 写真から基準どおりと判断できる
- redo_candidate ... 写真から基準と違うと判断できる
- cannot_judge ..... 項目が写っていない、隠れている、小さすぎて判断できない
迷ったときに ok を選ばないでください。

【厳守事項】
- 一覧にある点検項目だけを判定してください。一覧に無いことを指摘しないでください。
- 写真の外や、物の陰になっている部分を推測しないでください。cannot_judge です。
- 髪の毛、細かなほこり、小さなしみ、におい、備品が動くかは判定しないでください。
  一覧に入っていても、これらに当たる場合は cannot_judge にしてください。
- 数を数える項目（タオル、枕、アメニティ）は、数えた数を count に書いてください。
  重なっていて数えられないときは cannot_judge です。
- redo_candidate のときは、基準と何がどう違うかを evidence に具体的に書き、
  その箇所の位置を box_2d に入れてください。
- ok のときも、何を見て判断したかを evidence に短く書いてください。
- 清掃した人の丁寧さや手際について書かないでください。
- 部屋を販売してよいかは書かないでください。

「迷ったときに ok を選ばない」を両方に書くのは、何も言わなければ誤りの見えない写真に ok が付くからです。

「一覧に入っていても、微細なものは cannot_judge」と重ねるのは、表の作り間違いに備えるためです。 「洗面台に髪の毛が無い」のような項目が photo に紛れ込んでも、「無い」と答えさせない二重の止めです。

出力形式を固定する

Gemini API の構造化出力で、JSONを受け取ります。 出力形式にJSONを指定してスキーマを渡し、enum と required で status を3つの値に固定します。

1回目の出力

{
  "angle": "A3_washbasin",
  "angle_match": "match | mismatch",
  "brightness": "ok | too_dark | too_bright",
  "sharpness": "ok | blurry",
  "coverage": "ok | partial",
  "intrusion": "none | person | belongings | document",
  "reason": ""
}

2回目の出力

{
  "room_no": "",
  "room_type": "",
  "checks": [
    { "item_id": "BED-03", "angle": "A1_overview",
      "status": "ok | redo_candidate | cannot_judge",
      "count": null, "evidence": "", "box_2d": [0, 0, 0, 0] }
  ]
}

checks にはその客室タイプの photo の項目を並べます。box_2d は redo_candidate のときだけ入れます。

この形にする1つ目の理由は、AIの判定と部屋の区分を別の層に置けることです。 区分はスクリプトが規則で決めます。

抜き取りは、pass が本当に基準どおりかを確かめ続けるために置きます。 抜き取った部屋でやり直しになった件数が、見落としの目安です。

2つ目は、値をスクリプトで確かめることです。 公式にも、出力は構文上正しいJSONになるが、値はアプリケーションの側で検証するよう書かれています。item_id の抜けや重複があれば、部屋ごと inspect にします。

3つ目は、evidence と box_2d で、入室前に何をどこで見るかが分かることです。

システムへ連携する

判定一覧はフロア別・区分別に並べ、 回る部屋を上に出します。同じフロアをまとめて回れば移動が減ります。

撮り直しの画角は、清掃スタッフが端末で見る別のシートに書き出します。 判定一覧そのものは見せません。

人が確認する

インスペクターが回るのは redo、inspect、抜き取りの部屋だけです。 全室を回ると、第10章の50.0時間には収まりません。

1. redo を先に回る … 枠の付いた写真を見てから入室し、やり直しが要るかは現地で決めます
2. inspect と抜き取りを回る … 写真で判断できなかった項目を見ます
3. 入室した部屋では、on_site の項目も見る … におい、髪の毛、備品の動作です
4. 確かめた結果を記録する … AIの判定と違った項目と、その向きを残します
5. pass の部屋を販売可にする … 写真を流し見て、違和感があれば回る部屋に足します

3番目を忘れないでください。 回らなかった部屋の on_site の項目は、清掃スタッフがフォームのチェック欄で自分で確かめた扱いになります。 以前より弱くなる部分で、抜き取りで補います。

例外に対処する

5行目が安全装置です。 判定が出ないことを pass と扱うと、止まっているあいだの部屋がすべて見ずに販売されます。

記録を残す

• 受け取った写真と、送信した時刻・部屋番号・スタッフの ID
• 1回目と2回目に Gemini API へ渡した指示と、返ってきたJSONの全文
• そのとき参照した点検基準の表の版 … 項目や基準文を変えた日付が分かるように
• 部屋の区分と、抜き取りに当たったかどうか
• インスペクターが確かめた結果 … AIの判定と違った項目と、その向き
• 撮り直しになった画角と理由の件数（画角別・客室タイプ別）

3つ目で基準の版を残すのは、 判定が良くなったのか基準が緩くなったのかを見分けるためです。

5つ目は表を直す材料になります。 同じ項目で候補を覆す件数が多ければ、基準文か見本の写真に問題があります。