管理物件の空室を定期に巡回して撮った写真から、通水・換気の跡、郵便物やチラシのたまり、汚れや設備の異常の候補を見分けて、巡回記録とオーナーへの報告を作る

処理の起点を決める

時間主導型のトリガーで、1時間ごとに巡回のフォルダを見ます。 巡回は昼間に行われ、写真は担当が部屋を出るたびに入ります。夕方には、その日の部屋の下書きがそろいます。

1つの部屋の写真がそろってから処理します。 撮り場所は「郵便受けとドアの前」「玄関」「キッチンの流し（水を流している様子）」「浴室の排水口（同）」「洗面台（同）」「トイレ」「各居室（窓を開けた様子）」「ベランダ」「給湯器のリモコン」です。ファイル名を「部屋の番号_撮影日_撮り場所」とし、同じ部屋で「郵便受けとドアの前」と「キッチンの流し」がそろった部屋から処理します。 最後の撮り場所が入ってから30分たっても足りない撮り場所は、「撮り漏れ」として下書きに出します。

その月の巡回予定と照らし、予定日を過ぎても写真が1枚も無い部屋を一覧にします。 写真の無い部屋は、巡回されていない部屋かもしれません。点検の結果より先に、この一覧を管理の担当に見せます。

台風や大雨の後には、臨時の巡回をします。 臨時の巡回の写真はファイル名に「臨時」を付け、区分を通常の巡回より先に並べます。 窓からの雨の吹き込みやベランダの排水口の詰まりを、先に見るためです。

入力データを集める

質を決めるのは、部屋の台帳の「水まわりの設備の一覧」です。 洗濯機の排水口がある部屋、浴室が2か所ある部屋、ベランダに排水口が2つある部屋。どこに水を流すべきかが台帳に無いと、撮り漏れが決まりません。 撮り場所の決まりは、この一覧から部屋ごとに作ります。

撮り場所の名前は、AIに渡します。 写真の中の何を見ればよいかが分かり、キッチンの写真で「水が流れているか」を、浴室の写真で「排水口のまわり」を見させられます。 一方、前回の答えはAIに渡しません。前回「天井にしみ」と渡せば、今回も見つけようとして、照明の影をしみと答えることがあります。

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

スクリプトが、次の順に集めます。

写真はファイルの中身を取り出して base64 にし、撮り場所の名前と合わせて本文に入れます。 1部屋で8〜12枚になるため、縮めた写真でもリクエスト全体20MBの上限に近づくことがあります。 上限を超えそうな部屋は、水まわりと居室の2回に分けて呼びます。本文の response_format に後で示すスキーマを入れ、API キーはスクリプトのプロパティに持たせて、コードには書きません。

部屋の台帳は、賃貸管理のシステムから毎晩書き出したものを写します。 スクリプトから賃貸管理のシステムへ直接は書き込みません。入居の申込みが入った部屋は、翌日の写しから巡回の予定を外します。

AIへ渡す前に整形する

1. 枚数と名前の確認 … 部屋の番号が台帳にあるか、撮り場所の名前が決まりのとおりかを見ます
2. 向きの補正 … 写真の向きの情報で、横倒しの写真を正しくします
3. 写りの確認 … 暗くて何も見えない写真、ぶれた写真は「撮り直し」とします
4. 人の写り込みの確認 … 人が写った写真は、AIに送らず担当に返します
5. 郵便物の写真の扱い … 宛名が読める大きさで写っていないかを見て、読める写真は縮めるか撮り直しにします
6. 大きさの調整 … 長辺が大きすぎる写真は縮めます。天井のしみや排水口のまわりが潰れない大きさを残します

5番目は、この題材で特に大事です。 空室の郵便受けには、前の入居者あての郵便物や、宛名のある通知が入っていることがあります。 見るのは「たまっているか」だけで、宛名は要りません。郵便受けは扉を開けて少し離れて撮る決まりにし、1通ずつ並べて撮りません。

3番目の暗さは、電気の止まった空室で起きます。 空室でも照明を使えるようにしているか、担当が携帯の照明を持つ決まりにします。暗い写真では、しみも水の流れも見えません。

AIに処理させる

させるのは、撮り場所ごとに、次の答えを返すことだけです。

found と uncertain のときは、写真の番号と box_2d を返させます。 管理の担当は、印の付いた位置を見るだけで済みます。

2行目がいちばん起きやすい失敗です。 天井のしみの写真を見せると、AIは「上の階からの漏水と考えられます」と書きます。それがオーナーへの報告に入れば、上の階の入居者を疑う文面になります。 原因は、管理の担当が現地と上の階の状況を確かめてから書きます。

指示内容を固定する

あなたは、賃貸住宅の空室を巡回して撮った写真を見て、巡回の作業の跡と、異常らしいものを書き出す立場です。
同じ部屋の写真を撮り場所の名前と一緒に渡します。写真に見えるものだけを答えてください。

【この部屋の情報】間取り：{layout}  撮り場所：{spots}

【撮り場所ごとに答えること】
- 流し・浴室・洗面：water_running（shown / not_shown / uncertain）
- 居室：window_open（shown / not_shown / uncertain）
- 郵便受けとドアの前：mail_pileup（found / none / not_visible / uncertain）
- すべての撮り場所：stain、dirt_mold_pest、damage（found / none / not_visible / uncertain）
- 給湯器のリモコン：heater_display（display_on / display_off / not_visible）
- found と uncertain のときは、photo_no と box_2d と、見えたものを短く note に
迷ったときに none を選ばないでください。

【厳守事項】
- 暗い・反射・画角の外で見えない部分は not_visible にしてください。見えない部分を none にしないでください。
- しみや汚れの原因、漏水の有無を推測しないでください。
- 修繕が要るかどうかを書かないでください。
- 郵便物の宛名、差出人、内容を書かないでください。たまっているかどうかだけを答えてください。
- 給湯器のリモコンの表示の意味を書かないでください。何か表示されているかだけを答えてください。
- 写真に写っている人について、何も書かないでください。

「郵便物の宛名を書かない」を明記しないと、AIは宛名を読み上げます。 写真に文字があれば、それを書き出すのが自然だからです。巡回記録に前の入居者の名前が残れば、それだけで個人の情報を不要に持つことになります。

「表示の意味を書かない」を入れているのは、誤った案内を防ぐためです。 リモコンの数字を見て、AIがもっともらしい故障の説明を書くことがあります。意味は型式ごとの取扱説明で、管理の担当が確かめます。

出力形式を固定する

構造化出力で、部屋ごとに次の形のJSONを受け取ります。

{
  "room_id": "B021-0203",
  "spots": [
    { "spot": "kitchen_sink",
      "checks": [
        { "item": "water_running | window_open | mail_pileup | stain | dirt_mold_pest | damage | heater_display",
          "status": "shown | not_shown | found | none | not_visible | uncertain | display_on | display_off",
          "photo_no": 3,
          "box_2d": [0, 0, 0, 0],
          "note": "" }
      ] }
  ],
  "retake_needed": false
}

項目と状態を enum にして、決めた値以外を返させません。 Gemini API の構造化出力は、/v1beta/interactions の response_format に mime_type: "application/json" とスキーマを入れて指定し、enum と required が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 スクリプトで、撮り場所ごとに決めた項目がそろっているか、water_running に found のような組み合わせの合わない値が入っていないかを確かめ、合わなければ「確認が要る」にします。

区分は、スクリプトが前回の答えと比べて決めます。

しみと破損を前回からの変化で「至急」にしているのは、空室では変化そのものが知らせだからです。 前回から写っているしみは、すでに相談した記録があるかを確かめるだけで済みます。規則の中身は管理部が決め、表として持ちます。

システムへ連携する

巡回記録には、下書きの列だけに書きます。 確定の列は管理の担当が埋めます。修繕の手配も、工事業者への依頼は管理の担当が確定してから出します。 スクリプトから外へは何も送りません。

処理が終わった写真は、部屋ごとの保管のフォルダへ移します。 移すのは、答えを巡回記録に書けたときだけにします。巡回のフォルダに残っている写真の数が、そのまま未処理の数になります。

人が確認する

すべての部屋で、管理の担当の確定を通します。 写真を開く部屋は区分で絞ります。

1. 「要確認（至急）」を最初に見る … 印の付いた位置を写真で確かめ、前回の写真と並べます。新しいしみなら、上の階や隣の部屋の状況を確かめる手配までを1つの手順にします
2. 「撮り漏れ」を見る … 水を流していない撮り場所があれば、次の巡回を前倒しにするか、担当に確かめます
3. 「要確認」と「郵便物」を見る … 清掃や回収の手配を決めます
4. 「異常なし」は一覧で確定する … 下書きを流し見て、まとめて確定します

1番目を省かないでください。 空室のしみは、誰も住んでいないあいだに広がり続けます。 写真で確かめた時点で、現地の確認の手配まで進めます。

目標は、1,200件をならして1件1.5分です。 「異常なし」の部屋は一覧で数秒、「要確認（至急）」の部屋は写真を開いて数分かかります。月末のオーナーへの報告の確認も、この時間に含めています。

最初の1か月は、事務の担当がこれまでどおり写真を見て、AIの区分と並べます。 担当が異常と見た部屋に、AIが候補を出していたかを照らします。出していなかった部屋は、撮り場所か指示の書き方を直す材料です。

例外に対処する

「未処理」と「撮り漏れ」を「異常なし」に混ぜないでください。 混ぜると、巡回されていない部屋が巡回された部屋と同じ記録になり、（c）の問題がそのまま残ります。

記録を残す

• 部屋ごとの写真と、撮影日時、撮った担当
• AIの答え（撮り場所ごとの状態・位置・メモ）
• 区分と、そのとき使った規則の版
• 管理の担当が直した区分と、確定した日
• 手配した修繕・清掃と、その結果
• オーナーへ送った報告の版と、送った日

オーナーへの報告の下書きは、たとえば次の形にします。

【空室の巡回のご報告】2026年10月分　○○様
 B021-0203（1K） 巡回 10/03・10/17 通水・換気を実施
   10/17 浴室の天井に小さなしみを確認。原因を確認中です（写真2枚添付）
 B021-0305（1LDK） 巡回 10/03・10/17 通水・換気を実施　異常はありませんでした
 チラシの投函が多く、10/17 に回収しました

最後の行の報告の版は、管理業務報告書の材料になります。 賃貸住宅管理業法の施行規則は、管理受託契約を結んだ日から1年を超えない期間ごとに、報告の対象となる期間、管理業務の実施状況、入居者からの苦情の発生状況と対応状況を記載した管理業務報告書を交付して説明することを求めています。月次の報告を残しておけば、1年分の実施状況をそこから組めます。