管理物件の共用部を巡回した写真から不具合を拾い、巡回報告書とオーナー向けの報告を作る

処理の起点を決める

毎日18時に、その日に作られた巡回のフォルダを拾います。 Apps Script のインストール型トリガーには時間主導型があり、公式には最短で1分ごとから月1回まで設定できるとされています。ドライブへのファイル追加をきっかけにするトリガーは、確認した一覧にはありませんでした。

1日1回にまとめるのは、巡回の写真が1日のうちに少しずつ入るためです。 担当者は1日に数棟を回り、戻ってからまとめてフォルダに入れます。入れている途中で動かすと、半分の写真で「未撮影」が大量に出ます。 18時に動かし、翌朝に担当者が下書きを見ます。

フォルダ名の末尾に _done を付けると処理の対象になる決まりにし、処理を終えたら _reported に変えます。_done のまま残っているフォルダの数が、未処理の数です。

入力データを集める

質を決めるのは、撮影地点の一覧の基準の写真です。 何も無いときの集合ポストの前がどう見えるかを1枚持っておけば、「いつもと違う」を比べる相手ができます。 基準の写真が無いと、ゴミ置場の分別のボックスを放置物と見ることがあります。

不具合の種類の一覧は、10〜15種類に絞ります。 種類を細かくしすぎると、同じ汚れが担当者ごとに別の種類で台帳に残ります。

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

1. フォルダ名から物件コードを取り出し、撮影地点の一覧と未解消の不具合を台帳から引く
2. 写真をドライブから読み、Files API に上げて参照を得る
3. 基準の写真と、未解消の不具合の前回の切り抜きも同じように上げる

未解消の不具合は、台帳の状態で引きます。 報告書のファイルを開いて探すのではなく、台帳の1行が1つの不具合になっているので、前回の報告書を探す作業そのものが無くなります。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のどれかであることを確かめます。それ以外は JPEG に変換します
2. 縮小 … 長辺を一定の大きさに縮めます。タイルの数が減り、費用が下がります。 ただし遠くの照明の不点灯が見えなくなるほど縮めないよう、最初は2段階で試します
3. 枚数の確認 … 撮影地点の数に対して写真が極端に少なければ、判定の前に担当者へ知らせます
4. 撮影日時の確認 … 巡回の日と違う日時の写真が混ざっていれば、別の巡回の写真として外します
5. 写り込みの確認 … 集合ポストの名札、放置自転車の防犯登録の番号、人の顔が写っている写真に印を付けます（第13章）
6. 撮影順の並べ替え … 撮影日時の順に並べ、撮影地点の一覧の順と照らします。一覧の順に撮る決まりにしておけば、地点の推定が外れたときに前後の写真から見当がつきます
7. 基準の写真の添付 … 撮影地点の一覧から、その物件の基準の写真だけを選んで添えます。他の物件の基準の写真は渡しません

2番目の縮小は、試してから決めます。 公式の料金の数え方は、768×768ピクセルのタイルごとに258トークンです。高画質の写真のままでは1枚で多くのタイルになり、180件×40枚で積み上がります。 照明の不点灯や小さなひび割れが見える最小の大きさを、過去の写真で確かめます。

AIに処理させる

させるのは、写真ごとの撮影地点の推定、不具合の候補の記録、前回の不具合の確認、そして報告書の下書きです。

possibly_resolved という名前にしてあるのは、直ったと言い切らせないためです。 照明が点いて見えても、その時間だけ点いていた可能性があります。「直った」と台帳を閉じるのは、担当者が写真と修繕の記録を見てからです。

not_captured はAIが出すものではありません。 撮影地点の一覧のうち、どの写真にも当てはまらなかった地点を、Apps Script が一覧と突き合わせて出します。 AIに「写っていない地点」を考えさせると、写っていない地点を推測で埋めます。

3行目がいちばん気をつける点です。 生成AIは、破損の写真を見ると原因を添えたがります。オーナー向けの報告に「入居者の過失と思われます」と出れば、そのまま入居者とのもめごとの種になります。

指示内容を固定する

あなたは賃貸住宅の管理会社で、共用部の巡回写真を点検する担当です。
写真に写っていることだけを記録してください。推測で補わないでください。

【やること】
1. 各写真が【撮影地点の一覧】のどの地点かを、基準の写真と見比べて決める。
   似た地点が無ければ point を unknown_point にする。
2. 各写真について、【不具合の種類の一覧】に当たるものがあれば記録する。
   種類は一覧の名前だけを使う。一覧に無いものは other にし、note に書く。
   位置を box_2d に [ymin, xmin, ymax, xmax]（0〜1000）で入れる。
3. 【未解消の不具合】の1件ずつについて、今回の写真で残っているかを見る。

【status の選び方（写真ごと）】
- ok ....... 撮影地点が分かり、不具合の種類に当たるものが写っていない
- defect ... 不具合の種類に当たるものが写っている
- unclear .. 暗い、ぶれている、物に遮られているなどで判断できない
迷ったときに ok を選ばないでください。

【前回の不具合の選び方】
- still_present ..... 前回と同じ場所に、同じ不具合が写っている
- possibly_resolved . 同じ場所が写っており、不具合が見当たらない
- not_visible ....... その場所が写っていない、または画角が違って比べられない
「直った」「修繕済み」とは書かないでください。

【厳守事項】
- 緊急度、修繕の要否、費用、原因を書かないでください。
- 誰がやったか、入居者の過失かを書かないでください。
- 人の顔、郵便受けの名前、自転車の防犯登録の番号、車のナンバーは読み取らず、
  写っている場合は privacy_flag を true にしてください。
- evidence には、何が写っているかを1文で書いてください（例：「3階廊下の天井照明が消えている」）。
- 撮影地点の一覧に無い地点を、写っていないからといって記録しないでください。

【撮影地点の一覧（地点名と基準の写真）】{points}
【未解消の不具合】{open_issues}
【不具合の種類の一覧】{defect_types}
【今回の写真】{photos}

「迷ったときに ok を選ばない」は、この構成でいちばん効く1行です。 暗い写真や半分遮られた写真を、生成AIは「異常は見当たりません」と書きがちです。判断できない写真は unclear として人に回します。

「直った」と書かせないのも同じ理由です。 possibly_resolved を担当者が確かめてから台帳を閉じます。

出力形式を固定する

写真の判定は、次の形のJSONで受け取ります。 公式には、JSON Schema を渡すとそれに従う応答を返すよう設定でき、出力は構文として正しいJSONになるとされています。同時に、値が意味として正しいかはアプリの側で確かめるよう勧められています。

{
  "property_code": "",
  "patrol_date": "",
  "photos": [
    { "file": "", "point": "", "status": "ok | defect | unclear",
      "defects": [ { "type": "", "box_2d": [0, 0, 0, 0], "evidence": "", "note": "" } ],
      "privacy_flag": false }
  ],
  "open_issues": [
    { "issue_id": "", "result": "still_present | possibly_resolved | not_visible",
      "file": "", "evidence": "" }
  ]
}

1つ目の理由は、type を種類の一覧から選ばせられることです。 公式には、文字列に enum を使えるとされています。不具合の種類を一覧の名前に固定すれば、台帳の集計が担当者ごとに割れません。 box_2d の各値も minimum 0、maximum 1000 で縛れます。

2つ目は、not_captured と緊急度を後から足せることです。 Apps Script が撮影地点の一覧と photos の point を突き合わせて、どの写真にも当たらなかった地点を not_captured として足し、type から緊急度を表で引きます。

3つ目は、box_2d で写真を切り抜けることです。 報告書には全体の写真と不具合の部分の拡大を並べます。座標は0から1000の正規化なので、写真の幅と高さを掛けて元の画素に戻してから切り抜きます。

システムへ連携する

不具合台帳へは「確認待ち」の状態で書きます。 担当者が確かめて初めて「未解消」になります。AIの候補がそのまま未解消の不具合として台帳に残ると、誤検知が次の巡回の確認項目になります。

台帳の行を閉じる（解消にする）操作は、人だけが行います。 possibly_resolved が出ても、Apps Script は状態を変えません。賃貸管理システムへも書き込みません。 修繕の手配は、確定した巡回報告書から人が起こします。

報告書の下書きは、ひな形のドキュメントを複製して作ります。 社内の巡回報告書は「前回からの不具合」「今回の不具合」「未撮影・判断できず」「異常なし」の4つの見出しを持ち、オーナー向けの報告は前の2つだけを載せます。見出しの並びをひな形で固定しておけば、担当者が替わっても報告の形が変わりません。

人が確認する

人が見るのは、defect、unclear、not_captured、前回の不具合の4つです。

1. 前回の不具合を先に見る … still_present は修繕の手配の状況を確かめ、possibly_resolved は写真と修繕の記録を見て台帳を閉じるかを決めます
2. defect を写真で確かめる … 切り抜きの写真を見て、不具合の種類が合っているかを確かめます。誤検知は候補を消します
3. unclear と not_captured を扱う … 次の巡回で撮り直すか、臨時で見に行くかを決めます
4. 下書きを直す … 社内の巡回報告書とオーナー向けの報告を読み、表現を直します
5. 判定を覆したら記録する … どの写真の、どの種類を、どう変えたか

not_captured が多い物件は、撮影地点の一覧か撮り方を見直します。 毎月同じ地点が未撮影なら、地点の決め方に無理があります。

オーナー向けの下書きでは、3つを確かめます。 不具合の説明に原因や過失が混じっていないか、写り込みのある写真が使われていないか、「対応予定」の欄に担当者がまだ決めていない予定が書かれていないかです。下書きは対応予定を空欄で出す決まりにし、担当者が埋めます。

目標は、180件をならして1件9分です。 不具合の少ない棟は一覧を流し見て下書きを確かめるだけで数分、不具合の多い棟は写真を1枚ずつ確かめるので長くかかります。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの問題ではなく、写真の撮り方と入れ方の問題です。 撮影地点の一覧を印刷して巡回に持っていくほうが、判定を直すより効きます。

記録を残す

• 巡回の写真の元ファイルと、撮影日時・担当者
• Gemini API に渡した撮影地点の一覧と未解消の不具合、返ってきたJSONの全文
• 撮影地点ごとの結果（ok ／ defect ／ unclear ／ not_captured）と、そのとき使った緊急度の表の版
• 人が判定を覆した記録 … どの写真の、どの種類を、どう変えたか
• 不具合台帳の状態の変化（確認待ち → 未解消 → 解消）と、変えた人・日時
• 物件ごとの not_captured と unclear の発生率

5つ目は、オーナーへの説明の根拠になります。 「先月の件はどうなりましたか」と聞かれたとき、いつ見つけ、いつ手配し、いつ解消を確かめたかが台帳の1行で答えられます。