ドローンで撮った屋根の写真から、瓦のずれ・割れ、板金の浮き、雨どいの外れの候補を位置付きで拾い、点検報告書の下書きを作る

処理の起点を決める

点検者が案件の表で「AIで見る」に印を付けたときに動かします。 写真の取り込みは、点検者が事務所に戻ってから、まとめて行います。フォルダへの保存で自動に動かすと、取り込みの途中の写真で候補が作られます。

Python のプログラムは、案件の表を数分ごとに見て、印の付いた案件を拾います。処理が終わったら印を「処理済み」に変え、確認用の一覧の場所を同じ行に書きます。 失敗したときは「失敗」とし、理由を書きます。

台風の後のように件数が集中するときは、拾う順番を受付の順にします。 同じ点検者の案件がまとまって処理されると、その点検者の確認だけが詰まるためです。

撮り直した写真は、同じ案件のフォルダの「撮り直し」に入れ、印を付け直して動かします。 そのときは撮り直しの写真だけを処理し、点検者がすでに判断を付けた候補はそのまま残します。 全部をやり直すと、確かめ終えた候補の判断が消え、同じ写真を二度見ることになります。

入力データを集める

質を決めるのは、屋根材の種類です。 粘土瓦とスレートでは、「割れ」の見え方も、板金の付き方も違います。屋根材をAIに渡すと、スレートの重なりの段差を「ずれ」と答えるような取り違えが減ります。

前回の点検の結果は、AIに渡しません。 「前回は棟板金の浮きあり」と渡すと、AIは今回もそこに浮きを見つけようとします。前回との比較は、AIの答えが出た後に Python が部位で突き合わせ、「前回からあり」「今回新たに」を確認用の一覧に付けます。

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

写真の位置情報で、別の現場の写真が混ざっていないかを確かめます。 写真の緯度経度と案件の緯度経度の距離が一定の範囲（例：50m）を超える写真は処理せず、点検者に返します。別の家の屋根の写真が報告書に入ることは、点検商法と同じ結果を生みます。 位置情報の無い写真も、同じく点検者に返します。

照合の距離は、緯度経度の2点の距離として Python で計算します。 屋根の写真は真上や斜め上から撮るので、写真の位置は建物の位置から数十m離れることがあります。範囲を狭くしすぎると正しい写真まで返されるので、最初の1か月は点検者に返した写真の数を見て範囲を決めます。 撮影日時も見て、点検の予定日と違う日の写真が混ざっていれば同じく返します。

写真は、案件ごとにまとめて送らず、1枚またはタイルごとに送ります。 リクエスト全体20MBの上限があるうえ、1回に多くの写真を入れると、どの写真のどこかの対応が崩れやすくなるためです。

AIへ渡す前に整形する

1. 現場の照合 … 位置情報と案件の住所を照らし、範囲外・位置情報なしの写真を外します
2. 写真の分類 … 撮影の高さと向きの情報、または写真の大きさの並びから、全景・面の写真・近接の写真に分けます
3. 写りの確認 … ぶれた写真、逆光で屋根が黒くつぶれた写真を「撮り直し」にします
4. タイルの切り出し … 近接の写真を、2割ほど重なるタイルに切り出します。タイルごとに元の写真での位置を覚えておきます
5. 周囲の写り込みの扱い … 隣の家の窓や庭、人が大きく写った部分は、屋根の範囲の外を塗りつぶしてから送ります
6. 大きさの調整 … 面の写真は長辺を縮めて送ります。全景は報告書に使うだけで、AIには送りません

4番の重なりは、タイルの境目にある割れを落とさないためです。 重なった部分で同じ損傷が2回拾われるので、元の写真の座標に戻したあと、枠の重なりが大きいものを1つにまとめます。

5番は、この題材で欠かせません。 ドローンで上から撮ると、隣の家の敷地や人が写り込みます。 点検に要るのは対象の屋根だけなので、屋根の外はAIに送りません。

AIに処理させる

させるのは、写真（またはタイル）ごとに、4種類の損傷の候補を返すことだけです。

写真ごとに、4種類のうちどれが「見えていない」かも返させます。 雨どいが写っていない写真で「雨どいの外れなし」と扱うと、見ていない部位が「異常なし」として報告書に載ります。 見えていない部位は、Python が案件全体で集計し、どの写真でも見えていない部位を「未確認の部位」として点検者に示します。

4行目は、保険の請求に関わる場面で特に起きやすい失敗です。 「台風による飛散と考えられる」と書かれた報告書は、顧客がそのまま保険の請求に使います。 国民生活センターも、保険金を利用できるというトークに気をつけるよう呼びかけています。原因の判断は、AIにも報告書の定型文にも持たせません。

指示内容を固定する

あなたは、ドローンで撮った住宅の屋根の写真を見て、損傷の候補を書き出す立場です。
写真に見えるものだけを答えてください。

【この屋根の情報】屋根材：{roof_material}  写真の種類：{photo_kind}

【損傷の種類】
tile_shift（瓦のずれ。スレートの浮き・ずれを含む）
tile_crack（瓦の割れ・欠け）
flashing_lift（棟板金・谷板金の浮き、釘の浮き）
gutter_detach（雨どいの外れ・たわみ）

【答えること】
- 候補ごとに：type、box_2d、confidence（high / low）、見えたものを短く note に
- 種類ごとに、この写真で見えているか：visible / not_visible
- 影・苔・汚れ・瓦の重なりの段差と見分けられないものは、type を書いて uncertain にしてください

【厳守事項】
- 損傷かどうかはっきりしないものを、high にしないでください。
- 補修が要るか、急ぐかを書かないでください。
- 原因（台風、経年など）を推測して書かないでください。
- 写真に写っていない部位について、「異常なし」と書かないでください。not_visible にしてください。
- 隣の家、庭、人について何も書かないでください。
- 「危険」「早急」「深刻」などの言葉を使わないでください。

「影・苔・汚れと見分けられないものは uncertain」を明記しないと、AIはどちらかに寄せます。 屋根の写真では、瓦の重なりの影が割れの線に、苔の筋がずれの段差に見えることがあります。見分けられないことを答えにできる欄を作り、点検者の確認に回します。

「危険」「早急」を禁じる行は、（c）への答えです。 AIの note は確認用の一覧にしか出ませんが、点検者が所見を書くときに、そのまま写すことがあります。 強い言葉が入口で入らないようにしておきます。

出力形式を固定する

構造化出力で、写真（タイル）ごとに次の形のJSONを受け取ります。

{
  "photo_id": "R0412-037",
  "tile": { "x": 0, "y": 0, "w": 0, "h": 0 },
  "visibility": { "tile_shift": "visible", "tile_crack": "visible",
                  "flashing_lift": "visible", "gutter_detach": "not_visible" },
  "findings": [
    { "type": "tile_shift | tile_crack | flashing_lift | gutter_detach",
      "box_2d": [0, 0, 0, 0],
      "confidence": "high | low | uncertain",
      "note": "" }
  ]
}

種類と確からしさを enum にして、決めた値以外を返させません。 Gemini API の構造化出力は、/v1beta/interactions の response_format に mime_type: "application/json" とスキーマを入れて指定し、enum と required が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 Python で、box_2d が0〜1000の範囲にあり、ymin が ymax より小さいか、4種類の visibility がそろっているかを確かめ、外れたものは「確認が要る」にします。

tile は Python の側で付けます。 タイルの位置と box_2d から、元の写真のピクセルの座標を計算します。計算は次のとおりです。

縮めてから送った面の写真は、縮める前の大きさで戻します。 縮小の倍率を覚えておかないと、枠が写真の左上に寄って描かれます。枠を描いたら、確からしさが high の枠は太い線、low と uncertain は点線にし、点検者が見る順番の目安にします。

確認用の一覧は、候補ごとに次のように並べます。

報告書の下書きは、点検者が「あり」としたものだけで作ります。 所見は種類ごとの定型文から入れます。例えば板金の浮きなら「写真の枠内に、棟板金の浮きが見られます」とし、原因や緊急度の言葉は定型文に入れません。

システムへ連携する

顧客には、この構成から何も送りません。 報告書は下書きとして案件のフォルダに置き、点検者と上長の確認の後に、営業担当が渡します。

元の写真は書き換えません。 枠を描いた写真は別のファイルとして保存し、報告書には枠付きの写真と、枠の無い同じ写真の両方を載せられるようにします。 顧客が自分の目で同じ場所を見られることが、報告書の信頼につながります。

APIキーは、プログラムの外の設定に置き、コードに書きません。

人が確認する

すべての候補と報告書を、点検者が確かめます。 見る順番を決めておきます。

1. 「未確認の部位」を最初に見る … 撮り直すか、次の訪問で現地を見るかを決めます。報告書に「異常なし」と書かれないようにするためです
2. 確からしさが high の候補を見る … 枠の位置を拡大して確かめ、「あり／なし」を付けます
3. uncertain と low の候補を見る … 写真で決められないものは「現地で確認」にします
4. 面ごとの縮小の一覧に目を通す … AIが拾っていない損傷があれば、枠を描いて足します
5. 上長が報告書の写真と所見を照らす … 所見の言葉が写真で確かめられる範囲を超えていないかを見ます

4番を省かないでください。 AIの候補だけを見る運用にすると、AIが拾えない種類の損傷は、報告書から消えます。 縮小の一覧は、1面あたり数十秒で見られる大きさにしておきます。

目標は、1件をならして20分です。 候補が数個の屋根は10分ほどで終わります。「なし」を付ける候補が半分を超える案件が続くなら、屋根材の補足か撮り方の決まりが合っていません。 そのときは、どの種類の候補で「なし」が多いかを数えてから直します。

点検者が「なし」とした候補も記録に残します。 どの種類で、どんな写り方のときにAIが誤るかが分かり、撮り方の決まりと指示の見直しの材料になります。

例外に対処する

1行目がいちばん大事です。 写真の取り込みの取り違えは、AIの精度とは関係なく起きます。別の家の損傷が報告書に載ることは、どの誤りより重いので、最初の照合で止めます。

記録を残す

• 案件ごとの元の写真、枠付きの写真、確認用の一覧
• AIに送ったタイルの位置と、返ってきたJSON
• 現場の照合で外した写真と、その理由
• 点検者の判断（あり／なし／現地で確認）と、点検者が足した損傷
• 報告書の下書きと、上長が直した点
• 前回の点検との比較の結果（前回からあり・今回新たに）

点検者の判断とAIの候補を並べて残すことで、AIの癖が見えます。 「スレートの屋根では、ずれの候補の多くが『なし』になる」のような傾向は、屋根材ごとの指示の書き分けに使えます。

写真と報告書を残す期間は、顧客との約束と社内の規程で決めます。 次回の点検で前回と比べるためには、「あり」とした損傷の写真が残っている必要があります。前回との比較に使う写真と、使わない写真を分けて、使わない写真から先に消すと、保管の量を抑えられます。