ビル清掃の会社が共用部の清掃のあとに撮った写真を Gemini で見て、仕様書と照らした仕上がりの点検の記録と手直しの一覧を作る

処理の起点を決める

清掃員が「この物件の今日の清掃が終わった」と送ったときに、1棟1日分をまとめて動かします。 チャットの決まった言葉か、写真を送る画面の「終了」のボタンを合図にします。写真が1枚届くたびに動かすと、まだ撮っていない場所の作業を「写っていない」と返し、清掃員への問い合わせが無駄に飛びます。

清掃の予定の時刻を過ぎても合図の無い物件を、1日に2回数えます。 昼と夕方に、その日に清掃の予定がある物件のうち合図の届いていないものを担当に知らせます。合図の送り忘れと、清掃そのものが行われていないことを、その日のうちに分けられるようにします。

手直しの写真は、別の合図で動きます。 清掃員が候補の番号を付けて写真を送ったら、その番号の候補だけを見比べます。番号の付いていない写真は見比べに回さず、担当に「どの候補の写真か」を聞く一覧に入れます。

入力データを集める

質を決めるのは、仕様書をその日の作業の一覧に直す部分です。 仕様書に「階段：手すり拭き 週1回（水曜）」とあれば、水曜の一覧にだけ入れます。曜日が書かれていない「週1回」は、物件ごとに曜日を決めてから一覧にします。 決めないと、毎日「写っていない」が出るか、一度も出ないかのどちらかになります。

写真を送るときに場所を選ばせるのも、質を決める部分です。 場所が分かれば、AIは写真と作業を結び付けられます。場所の名前は、仕様書の書き方にそろえた選択肢から選ぶ形にします。

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

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

仕様書と物件の台帳は、サーバーがスプレッドシートから読みます。 物件の番号で仕様書の行を引き、日付から曜日と月の日を出して、その日の作業の一覧を作ります。祝日や物件の休館日に清掃を休む決まりがあれば、物件の台帳に持たせます。

Gemini API へは、1棟1日分の写真と作業の一覧をまとめて渡します。 写真には番号と選ばれた場所を添えます。写真が多い物件は、階ごとに分けて呼びます。 全体の写真と近くの写真を同じ呼び出しに入れると、近くの写真の汚れがどの場所のものかを全体の写真と結び付けて返せます。

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

AIへ渡す前に整形する

1. 向きの補正 … スマートフォンの写真の向きの情報で回転しているだけのものは、画素を回転させます
2. 縮小 … 全体の写真は長い辺を1,600ピクセル程度に縮めます。鏡や便器の近くの写真は、水あとが分かるよう大きめに残します
3. 塗りつぶし … 住人・来訪者・テナントの社員の顔、郵便受けや掲示板の名前、エレベーターの中の人を塗りつぶします
4. 暗さとぶれの確認 … 照明の落ちた階段や、手ぶれの大きい写真は、AIに渡さずに撮り直しの候補にします
5. 場所の確認 … 選ばれた場所が、その日の作業の一覧にあるかを見ます。一覧に無い場所の写真は、別に分けておきます
6. 大きさの確認 … 1回分の写真と指示の文を合わせて20MBを超えないかを見ます。超えるときは階ごとに分けます

3番目を省かないでください。 マンションのエントランスは、朝の清掃の時間が住人の出勤や通学の時間と重なります。 子どもを含む住人が写った写真が、そのままAIに渡り、作業報告に貼られる形を避けます。塗りつぶした写真だけを渡し、作業報告にも塗りつぶした写真を使います。

AIに処理させる

させるのは、作業ごとに見え方を返すこと、手直しの候補を枠で返すこと、手直しの前後を見比べることだけです。

作業ごとに finished_looking と not_visible を分けて返させるのが、この構成の要です。 写っていない作業を「仕上がって見える」と同じに扱うと、第3章の（a）がそのまま残り、作業報告に写真の無い作業が「実施」と載ります。 not_visible と partly_visible が残る物件は、サーバーが担当の確認の一覧の先頭に置きます。

3行目の「一覧に無い気づき」は、清掃の点検とは別に扱います。 照明が切れている、手すりが外れかけて見える、といった所は清掃員の手直しの対象ではなく、管理会社への連絡の候補です。サーバーは清掃員への一覧に混ぜず、担当の画面の別の欄に出します。

1行目がいちばん起きやすい失敗です。 床がきれいに写っていると、AIは「清掃は適切に実施されています」と書きたがります。その言葉が作業報告に入ると、写真の1枚で作業の実施を保証することになります。 返すのは見え方までにし、作業報告に「実施」と書くかは、清掃員の報告と担当の確認で決めます。

指示内容を固定する

あなたはビルの共用部の清掃の会社で、清掃のあとの写真を見る手伝いをする係です。
物件の種類は {分譲マンション} です。
写真の番号と、清掃員が選んだ場所は次のとおりです。
{1: 1階エントランス 全体, 2: 1階エントランス 床の近く, 3: 1階エントランス 自動扉のガラス,
 4: 2階廊下 全体, 5: ごみ置き場 全体 ...}

【今日の作業の一覧】
{1階エントランス-床の拭き上げ, 1階エントランス-自動扉のガラス拭き,
 1階エントランス-郵便受けの前の掃き, 各階廊下-掃き, 階段-手すり拭き,
 ごみ置き場-床の洗い・整頓, エレベーター-床と鏡}

【やること】
1. 作業の一覧の1行ずつについて、finished_looking / candidates / not_visible /
   partly_visible のどれかを選ぶ。一覧にない作業を足さない。一覧の作業を飛ばさない。
2. 次の種類の候補を探し、写真の番号と枠を [ymin, xmin, ymax, xmax] の順で、
   0〜1000 に正規化して返す。作業と種類、見え方を短く書く。
   床の拭き残し・拭きむら、ごみ・ほこりの残り、鏡・金属の水あと、
   便器・洗面台の汚れ、ガラスの指紋・くもり、ごみ置き場の散らかり、
   備品の切れに見える所
3. 作業の一覧に無いが目に付いた所（照明の切れ、落書き、設備の破損に見える所）が
   あれば、others に書く。

【厳守事項】
- 写真に写っていない作業を finished_looking にしないでください。
  not_visible にしてください。
- 暗い写真、ぶれた写真だけで見た作業は partly_visible にしてください。
- 汚れか床の模様・反射か分からないものは、kind を unclear にしてください。
- 作業を実施した、清掃が適切だ、と書かないでください。
- 手直しが必要か、設備の故障の原因や修理の方法を書かないでください。
- におい、すべり、衛生の状態を書かないでください。
- 清掃員の腕や責任について書かないでください。
- 人、郵便受けや掲示板の名前については何も書かないでください。

「一覧の作業を飛ばさない」「写っていない作業を finished_looking にしない」を並べているのは、どちらも同じ失敗を防ぐためです。 何も言わないと、AIは候補のあった作業だけを返し、残りの作業について何も言いません。 その沈黙をサーバーが「仕上がって見える」と読むと、写真の無い手すり拭きが作業報告に「実施」と載ります。

手直しの前後の見比べは、別の指示で呼びます。 候補の番号、作業、前の写真の枠、後の写真を渡し、「前の枠の所の見え方が、後の写真で直って見えるか、まだ残って見えるか、比べられないかを選ぶ。後の写真がほかの場所を写していると思えば not_comparable にする」と指示します。

作業報告の文の下書きは、月末に別の呼び出しで作ります。 担当が確かめた点検の記録だけを渡し、「作業の名前は仕様書の言葉をそのまま使う」「確かめた範囲は写真に写った範囲と書く」「適切に実施しました、問題ありません、のような言い切りをしない」を入れます。実施の日付は記録から機械で入れ、AIには書かせません。

出力形式を固定する

1棟1日分ごとに、次の形の JSON で受け取ります。 status、kind は enum で決まった文字列に絞り、tasks は作業の一覧と同じ数を minItems・maxItems で求めます。

{
  "site_id": "M-012",
  "date": "2026-10-28",
  "tasks": [
    { "task": "1階エントランス-自動扉のガラス拭き",
      "status": "finished_looking | candidates | not_visible | partly_visible", "photos": [3] }
  ],
  "findings": [
    { "photo": 3, "box_2d": [420, 300, 560, 410], "task": "1階エントランス-自動扉のガラス拭き",
      "kind": "floor_streak | debris_left | water_spot | toilet_stain | glass_fingerprint | waste_area_mess | supply_empty_looking | unclear",
      "note": "左の扉の取っ手の下に、手のあとのようなくもりが見える" }
  ],
  "others": [ { "photo": 4, "note": "廊下の奥の天井の照明が1つ消えて見える" } ]
}

1つ目の理由は、tasks をそのまま「その日の点検の記録」にできることです。 作業の数がそろっていなければサーバーが呼び直し、not_visible の作業は清掃員への確かめの一覧に自動で入ります。 清掃員がまだ現場にいる時間に届けば、撮り直しで済みます。

2つ目は、findings に番号を振れば、手直しの依頼と前後の見比べの鍵になることです。 サーバーは候補に「M-012-1028-02」のような番号を振り、清掃員への依頼と後の写真の受け取りに同じ番号を使います。

3つ目は、1か月分の記録から作業報告の表をそのまま組み立てられることです。

2行目の備考のように、写真が無い日を隠さずに書きます。 作業報告の中で「写真で確かめた日」と「実施の報告」を分けておけば、管理会社が帳簿に何を書き写すかを、管理会社の側で判断できます。

システムへ連携する

清掃員への依頼は、担当が「手直しする」にした候補だけを送ります。 AIの候補をそのまま送ると、床の模様や照明の反射まで手直しとして届き、清掃員の時間と担当への信頼が両方減ります。

管理会社への作業報告は、下書きまでにします。 担当と上長が読み直してから送ります。「一覧に無い気づき」も、担当が写真で確かめたものだけを、事実として書き添えます。

人が確認する

1. not_visible と partly_visible を先に見る … 清掃員に、撮り忘れか、作業をしていないかを確かめます
2. 候補を写真で確かめる … 印の所を見て「手直しする」「該当なし」を選びます
3. 一覧に無い気づきを確かめる … 管理会社に知らせるものを選びます
4. 手直しの前後を確かめる … fixed_looking も含めて前後の組を見ます
5. 月末に作業報告を読み直す … 写真で確かめた日と実施の報告が分けて書かれているかを見て、上長に回します

1番目を省かないでください。 not_visible は撮り忘れのことが多いのですが、作業そのものが抜けていることもあります。 清掃員が現場にいるうちに確かめれば、その日のうちに作業を足せます。

目標は、360件をならして1件3分です。 候補の少ないオフィスビルは1分ほどで済み、住人の多いマンションやごみ置き場の散らかりやすい物件は5分を超えます。

例外に対処する

上から2行目までが大半を占めます。 どれもAIの精度の問題ではなく、撮り方と仕様書の書き方の問題です。 7行目は、note に「実施」「適切」「修理」の言葉が入っていないかをサーバーで見ます。

記録を残す

• 1棟1日分の元の写真と、塗りつぶして AI に渡した写真
• 渡した作業の一覧と、Gemini API が返した JSON
• 候補ごとに担当が付けた「手直しする」「該当なし」と、not_visible について清掃員が答えた内容
• 手直しの前後の写真の組と、見比べの結果
• そのときの仕様書の版と社内の手直しの基準の版、送った作業報告

3つ目が、仕様書と撮り方を直す材料になります。 同じ作業で not_visible が続くなら、撮り方の決まりにその作業の写真が入っていません。物件ごとの手直しの件数も出せますが、清掃員の評価に使うかは、別に話し合って決めます。