火災保険の事故受付で契約者が送る住宅の被害写真から、被害の部位・損傷の種類・程度を見分けて受付票の下書きにし、撮り直しが要る写真と現地調査が要る案件を拾う

処理の起点を決める

事故受付のフォームで写真付きの受付が入ったことを起点にします。 受付システムが受付番号を発行したところで、このプログラムを呼びます。1回の呼び出しが「1件の事故の写真のまとまり」です。

写真の追加にも同じ処理を動かします。 撮り直しを頼んだ契約者が写真を追加で上げると、受付システムから同じ受付番号で呼ばれます。追加の写真は、前回の所見と合わせて部位ごとのまとめを作り直します。 追加の写真だけで所見を作ると、前回「確かめられない」だった部位が埋まったかが分かりません。

入力データを集める

質を決めるのは、下の2つです。 部位の一覧が無ければ、AIは「屋根の上のほう」「家の右側」のように、受付票の項目に合わない書き方をします。部位を一覧から選ばせると、書き方が担当者をまたいでそろいます。 撮り方の基準が無ければ、写真が足りているかを決められません。

契約の情報は、AIには渡しません。 補償の範囲を見せると、AIは「水災の補償が無いので対象外」のような、支払の判断に踏み込んだ文を書くことがあります。契約の情報は、規則で現地調査の候補を決めるときにだけ使います。 たとえば、建物の契約が無い案件で建物の所見しか無ければ、受付の担当者に契約の確認を促す印を付けます。

事故の説明は、AIに渡します。 説明に「2階の天井から雨漏り」とあれば、室内の天井の写真を探す手がかりになります。ただし、説明と写真が合っているかの判定は、AIに「合わない」と書かせるのではなく、説明にある部位が写真で確かめられたかで見ます。

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

受付システムから、受付番号、事故の内容、写真のファイルを受け取ります。写真の撮影情報（Exif）の日時は、残っていれば記録しますが判定には使いません。 端末やアプリによって消えていることが多く、残っていても書き換えられます。撮影の日時が事故の日より前に見える写真は、規則で担当者への確認の印を付けるだけにします。

写真は、リクエストに直接入れて渡します。 スマートフォンの写真は1枚数MBあるので、長い辺を決めた画素数に縮め、リクエスト全体で20MBに収まるようにします。 十数枚ある案件や、写り込みの確認と所見の作成の2回に同じ写真を使う案件では、Files API で一度上げて使い回します。Files API に上げたファイルは 48時間で自動的に削除され、上げたファイルは後から取り出せません。 写真の原本は受付システムの側に残し、Files API は呼び出しの間だけの置き場として使います。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のいずれかであることを確かめます。PDFや動画で届いたものは担当者に回します
2. 大きさの確認 … 長い辺を決めた画素数に縮め、リクエスト全体で20MBに収まるようにします
3. 枚数の確認 … 枚数が多い案件は Files API で上げ、1回の呼び出しに渡す枚数を決めておきます
4. 重複の除去 … 同じ写真が二度上げられていれば、片方だけを使います
5. 写り込みと写真の質の確認 … 人の顔、表札、車のナンバー、郵便物の宛名が写っていないか、ぼけ・暗さ・逆光で見えないかを、Gemini API に先に確かめさせます

5番目を、所見の作成と分けて先に行います。 1回の呼び出しで両方をさせると、ぼけた写真からも所見が返り、見えていない損傷が受付票に書かれます。 質の確認で unusable（使えない）とされた写真は、所見の作成に渡さず、撮り直しの依頼の材料にします。

写り込みは、写真を止めるのではなく印を付けます。 住宅の写真には、表札や家族、隣家、車が写るのが普通です。病院の写真のように撮り直しを求めると、契約者の負担が大きすぎます。 受付票に貼る写真では、写り込んだ位置にぼかしをかけた版を作り、元の写真は受付システムの中だけで扱います。

AIに処理させる

させるのは、写真ごとに、どの部位が写っていて、そこにどんな損傷が見えるかを返すことです。

右端の列がいちばん大事です。 not_visible は、その部位が写真に写っていないか、見える状態で写っていないということで、被害が無いということではありません。 地上から見上げた屋根の写真で、屋根材のずれが見えないのは当然で、それを「屋根に被害なし」と書くと、現地調査に回すべき案件が落ちます。

1行目が、いちばん起きやすい失敗です。 色あせた屋根材やさびた雨どいの写真を渡すと、AIは「経年劣化と思われる」と書きがちです。受付票にその一文が残ると、後の支払の判断に先入観を持ち込みます。 原因は見たままの事実（「さびが見える」「色あせが見える」）だけを書かせます。

指示内容を固定する

あなたは損害保険会社の事故受付で、契約者から届いた住宅の被害写真の所見を書く担当です。
渡された写真だけを見て、写っている部位と、見える損傷を書いてください。
写真に写っていないことを推測しないでください。

【写真】{images}（写真番号つき）
【事故の種類】{accident_type}
【契約者の説明】{description}
【部位の一覧】{part_list}

【写真ごとに返すこと】
- parts：写っている部位を部位の一覧から選ぶ。分からなければ unknown_part
- visibility：その部位の面が見えているか
    visible ...... 部位の面が見え、損傷の有無を判断できる
    not_visible .. 遠すぎる、角度が浅い、物に隠れている
- damages：見える損傷ごとに、種類・程度・位置の枠・根拠
    種類：break（破損・割れ）／peel（はがれ・ずれ）／deform（変形・へこみ）／
          hole（穴）／water_mark（浸水の跡）／stain（しみ・変色）／burn（焼け・すす）／uncertain
    程度：minor（軽微）／moderate（中程度）／severe（大きい）／not_assessable
    位置：box_2d に [ymin, xmin, ymax, xmax]、0〜1000 に正規化した座標

【厳守事項】
- 部位が見えていないときに「損傷なし」と書かない。visibility を not_visible にする。
- 損傷の原因（台風、雪、経年劣化、施工の不良など）を書かない。
  さび、色あせ、こけなどは、見えたままを evidence に書くだけにする。
- 補償の対象になるか、保険金が出るかを書かない。
- 損害額や修理の費用を書かない。
- 契約者の説明が正しいか、うそかを評価しない。
- 説明にある部位が写真に見つからないときは、missing_from_photos にその部位を入れる。
- 損傷か汚れか影かを区別できないときは uncertain にする。迷ったら uncertain。
- 程度は、近くから撮った写真が無いときは not_assessable にする。
- evidence には、写真のどこに何が見えるかを短く書く。

「損傷の原因を書かない」を明記しないと、ほぼ必ず書きます。 住宅の被害写真は「台風の被害」として送られてくるので、AIは説明に引きずられて「強風による破損と考えられる」と書きます。原因の言葉が1つでも入った所見は、受付票の記録として残すべきではありません。

「見えていないときに損傷なしと書かない」も同じです。 屋根の写真が全景の1枚しかないとき、AIは見える範囲で「目立った損傷は見られない」と書きます。この一文が、現地調査の要らない案件に見せてしまいます。

写り込みと写真の質の確認は、別の短い指示で先に行います。 「この写真に、人の顔、表札の文字、車のナンバー、郵便物の宛名が写っているか。写っていれば位置を枠で返す。ぼけ・暗さ・逆光で写真の内容が判断できなければ unusable」と指示し、迷ったら unusable の側に倒します。 撮り直しを頼むほうが、見えない写真から所見を書くより害が小さいためです。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "claim_no": "",
  "photos": [
    { "photo_no": 1, "quality": "ok | unusable",
      "parts": ["roof"], "visibility": "visible | not_visible",
      "damages": [
        { "part": "roof", "type": "break | peel | deform | hole | water_mark | stain | burn | uncertain",
          "severity": "minor | moderate | severe | not_assessable",
          "box_2d": [0, 0, 0, 0], "evidence": "" }
      ] }
  ],
  "missing_from_photos": [""],
  "privacy_marks": [ { "photo_no": 1, "kind": "face | nameplate | license_plate | address", "box_2d": [0, 0, 0, 0] } ]
}

スキーマでは type・severity・visibility を enum にし、damages の各要素の additionalProperties を false にします。

1つ目の理由は、部位ごとのまとめを規則で作れることです。 Python は写真ごとの結果を部位でまとめ、部位ごとに「確かめられた写真があるか」「いちばん重い程度は何か」を出します。

2行目の書き方が要です。 写真で見えた範囲に損傷が無いことと、部位に被害が無いことは違います。受付票の文言を最初から固定しておけば、担当者ごとに書き方が分かれません。

2つ目は、現地調査の候補を規則で決められることです。 たとえば次のような規則を、会社の基準に合わせて持ちます。

3つ目は、撮り直しの依頼を具体的に書けることです。 missing_from_photos と not_visible の部位、unusable の写真の番号から、「2階の天井のしみを、部屋全体が入るように1枚と、しみに近づいて1枚」のように、何をどう撮ってほしいかを部位ごとに書いた依頼の下書きを作ります。

システムへ連携する

受付票の確定と、契約者への送信は人が行います。 このプログラムは、受付システムの「下書き」の欄に書き込むだけで、確定の操作をしません。撮り直しの依頼も、担当者が文面を確かめてから送ります。 被害を受けた直後の契約者に送る連絡で、言葉の選び方を人が決めるためです。

人が確認する

下書きは全件を受付の担当者が確かめます。 受付票は、その後の損害サービスの担当者、鑑定人、契約者への説明のすべての出発点になるためです。

1. 現地調査の候補と撮り直しの要る案件を先に見る … 一覧の上に出ます。調査の手配と撮り直しの依頼は、早いほど被害の状態が残ります
2. 枠を見て、所見が合っているかを選ぶ … 写真に重ねた枠を見て、部位・種類・程度を確かめます。違えば直します
3. uncertain と not_assessable を決める … 写真を拡大して見るか、撮り直しの依頼に入れます
4. 撮り直しの依頼の文面を確かめて送る … 契約者の状況（高齢、避難中など）に合わせて言葉を直します
5. 現地調査に回すかを決める … 規則の候補を見て、手配の状況も踏まえて決めます

目標は、1件をならして8分です。 写真が足りていて損傷の少ない案件は枠を流し見て数分、写真の多い案件や撮り直しの要る案件は10分を超えます。それを大きく超える月は、unusable の写真が増えているか、部位の一覧が実際の住宅に合っていないかのどちらかです。

2番目で直した内容を記録します。 部位の取り違え、損傷の見落とし、汚れを損傷と読んだもの、のどれかを選ばせると、多い型から指示と部位の一覧を直せます。

例外に対処する

記録を残す

• 元の写真と、受付票に貼るぼかしをかけた版（どちらも受付システムの中）
• 写り込みと写真の質の確認の結果
• 写真ごとの所見のJSONの全文と、呼び出した日時、使ったモデルの名前
• 部位ごとのまとめと、適用した規則（どの規則で現地調査の候補にしたか）
• 担当者が直した所見と、直した理由の区分
• 撮り直しを頼んだ日時と、追加の写真が届いた日時

4つ目で「適用した規則」を残すのは、規則が後から変わるためです。 災害の規模によって現地調査の基準を変えると、過去の案件がなぜ調査に回ったのかが分からなくなります。規則の版を一緒に残せば、後から説明できます。