自動車保険の事故で契約者が送る車の損傷写真から部位と程度を見分け、修理見積書の明細と食い違う箇所と撮り直しが要る写真を調査担当へ出す

処理の起点を決める

写真の送信画面で、契約者が「送信を完了する」を押したことを起点にします。 1枚ずつのアップロードを起点にすると、全体の写真が届く前に接写だけで部位を判定してしまいます。部位の見分けは全体の写真があって初めて確かになるので、1件分がそろってから動かします。

ただし、写り具合の判定は送信の完了を待たずに1枚ずつ行ってかまいません。 送信画面の上で「この写真は暗いので撮り直してください」と出せれば、契約者はその場で撮り直せます。この記事では、送信の完了で写り具合と部位をまとめて判定し、撮り直しの案内を数分以内に送る形で説明します。

見積書の明細は、写真より後に届くことが多いです。 照合の処理は、写真の判定が終わった時点と、損害調査システムに明細が入った時点の両方で動かし、両方がそろった時点で照合の結果を出します。 明細の取り込みの時刻を毎時見に行き、写真の判定が済んでいて照合がまだの案件を拾います。

入力データを集める

質を決めるのは、いちばん下の部位の対応表です。 見積書では「Fバンパー」「フロントバンパカバー」「バンパーフェイス」と、工場や見積の仕組みによって同じ部位の書き方が違います。AIに返させる部位の区分と、見積書の部位の表記を1つの表で結んでおかないと、照合ができません。

ボディの形を渡すのは、部位の候補を絞るためです。 軽トラックに「リアドア」はありません。ボディの形ごとに候補の部位の一覧を渡すと、存在しない部位を答える誤りが減ります。

受付記録の損傷の箇所は、照合に使いますが、AIには渡しません。 申告を渡すと、写真にそれらしいものを探しにいき、見えないものを見えたと答えやすくなります。AIには写真と車両の情報だけを渡し、申告との照らし合わせは照合の処理で行います。

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

写真は、送信画面が保存した保管庫から案件番号で取り出します。元の写真はそのまま残し、AIに渡すのは前処理で整えた写しです。

撮影の日時は、写真の付帯情報から取ります。 事故の日より前の日時が入っている写真は、照合の結果に印を付けて担当者に見せます。判断はしません。 スマートフォンの設定や送り方によって付帯情報が消えていることも多く、日時が無いこと自体は異常として扱いません。

画像の渡し方は、1件分の写真の合計の大きさで決めます。合計がリクエストの20MBに収まるなら直接入れ、収まらないなら File API でアップロードします。 File API のファイルは48時間保存されて自動で消えるので、案件の記録として残す写真は自社の保管庫の側に置きます。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のどれかであることを確かめ、それ以外は JPEG に変換します
2. 向きの補正 … 付帯情報の向きに合わせて画像を回転させます。公式の案内でも、画像が正しく回転しているかを確かめることが勧められています
3. 大きさの調整 … 長い辺を一定の大きさに縮めた写しを作ります。接写は細部を残すため縮める幅を小さくします
4. 重複の除去 … 同じ写真が二度送られたものは、画像の特徴の一致で1枚にまとめます
5. 写真の種類の仮分け … 全体の写真と接写を、画像の大きさの比ではなく、次の写り具合の判定でAIに区分させます
6. 個人の情報の扱い … 人の顔や他人の車のナンバーが写り込んだ写真は、照合には使いますが、担当者以外への共有の前に隠します

2番目を軽く見ないでください。 スマートフォンの写真は、付帯情報の向きを読まない仕組みに渡すと横倒しになります。横倒しの車では、右と左、前と後ろの取り違えが起きます。 部位の左右を答えさせる構成なので、向きの補正は欠かせません。

AIに処理させる

させるのは2つです。写真ごとの写り具合の判定と、写っている部位と損傷の程度の見分けです。 1回目と2回目の呼び出しを分け、1回目で retake になった写真は2回目に渡しません。

部位の欄の unknown が、この構成でいちばん大事な値です。 接写だけでは「どこかのパネルのへこみ」までしか分かりません。そこで部位を推測させると、右と左、フロントフェンダーとフロントドアの取り違えがそのまま照合に入ります。 決められない接写は unknown とし、照合の処理が同じ案件の全体の写真の所見と合わせて扱います。

「損傷が見えない」と「写っていない」は別の値です。 部位が写っていて損傷が見えないなら程度を「損傷が見えない」に、部位そのものが写っていなければ、その部位はどの写真の所見にも出てきません。照合の処理は、出てこなかった部位を「写っていない」として扱います。

3行目を明記しておく理由は、AIが聞かれなくても書くからです。 古い傷とも見える、と書かせると、その一言が案件の記録に残ります。根拠の弱い一言が、契約者との関係を長く損ねます。

指示内容を固定する

1回目（写り具合）と2回目（部位と程度）のうち、2回目の指示の例です。

あなたは自動車保険の損害調査で、契約者が送った車の写真を見て、
写っている部位と損傷の程度を記録する立場です。
写真に見えるものだけを答えてください。推測で埋めないでください。

【車両】ボディの形：{body_type}
【部位の候補】次の一覧からだけ選んでください：{part_list}

【答えること】写真ごとに
1. 写真の種類（全体の前・後・左・右・斜め／接写／ナンバー／車内／その他）
2. 写っている部位と、その部位ごとの損傷の程度
3. 損傷ごとの位置（box_2d：[ymin, xmin, ymax, xmax]、0〜1000）

【程度の選び方】
- scratch ........ 塗装の表面の擦り傷
- dent_small ..... 手のひらに収まる程度のへこみ
- dent_large ..... 手のひらを超えるへこみ
- crack .......... 割れ・欠け（灯火類やバンパーなど）
- deform_suspect . パネルのすき間のずれや、形のゆがみが見える
- no_damage ...... 部位は写っているが、損傷は見えない
- unclear ........ 光の反射や影で、損傷の有無を決められない

【厳守事項】
- 部位の候補の一覧にない部位を答えないでください。
- 接写で、どの部位かを写真から決められない場合は part を unknown にしてください。
  ほかの写真から推測して部位を埋めないでください。
- 左右と前後は、車の運転席に座った向きで答えてください。
  決められない場合は side を unknown にしてください。
- 写っていない部位について、損傷が無いと答えないでください。
  部位が写っていなければ、その部位を答えに含めないでください。
- 損傷が今回の事故によるものか、古い傷かを書かないでください。
- 修理の方法（交換・板金など）や金額を書かないでください。
- 不正や虚偽の疑いについて書かないでください。
- 人の顔、他人の車のナンバーについて記述しないでください。
- 車の写真でないと判断した場合は、photo_type を other にして部位を答えないでください。

「写っていない部位について、損傷が無いと答えない」を明記しないと、写っていない部位まで no_damage で埋めます。 部位の候補の一覧を渡すと、一覧のすべてに答えようとするためです。no_damage は「写っていて損傷が見えない」ときだけの値に限ります。

左右の基準を書いているのは、写真の向きで答えが変わるからです。 車の正面から撮った写真では、見る人の左が車の右になります。基準を決めないと、正面の写真だけ左右が逆に記録されます。

出力形式を固定する

構造化出力で、次の形のJSONを返させます。 Gemini API では /v1beta/interactions の response_format に mime_type: "application/json" とスキーマを入れて指定し、enum と required で値を区分に縛ります。

{
  "claim_id": "",
  "photos": [
    {
      "photo_id": "",
      "photo_type": "overall_front | overall_rear | overall_left | overall_right | overall_diagonal | closeup | plate | interior | other",
      "findings": [
        { "part": "", "side": "left | right | center | unknown",
          "severity": "scratch | dent_small | dent_large | crack | deform_suspect | no_damage | unclear",
          "box_2d": [0, 0, 0, 0] }
      ]
    }
  ]
}

照合の処理は、このJSONと見積書の明細から、部位ごとに次の区分を付けます。

この表の2行目と3行目を分けるのが、第1章で書いた区別です。 not_photographed は契約者への撮り直しの依頼、no_visible_damage は修理工場への確認に回します。同じ「写真で確認できない」でも、連絡する先が違います。

JSONを使う理由は、AIの答えと照合の規則を別の層に置けるからです。 severity_gap をどこから出すかは、技術アジャスターと決める取り決めで、後から変わります。規則を変えても、AIの答えを取り直す必要がありません。 公式の案内でも、出力がJSONとして正しくても値はアプリケーションの側で確かめるよう書かれています。部位の候補の一覧にない値が来たら、照合に入れずに needs_human にします。

システムへ連携する

損害調査システムへの書き込みは、担当者が確かめた後だけです。 AIの区分をそのまま所見の欄に入れると、確かめていない所見が査定の記録として残ります。確認の一覧で担当者が「確定」を押したものだけを書き込みます。

撮り直しの案内は1件につき1回にまとめます。 写真ごとに送ると、契約者に何通も届きます。1件分の判定が終わってから、撮り直しが要る写真と理由をまとめて1通にします。

人が確認する

担当者は、全件の確認の一覧を開きます。 ただし、見る順番と深さは照合の区分で変えます。

1. match だけの案件は、枠を重ねた写真を流し見て確定する … 部位と程度が見積書と合っているかを目で確かめます
2. not_photographed の案件は、撮り直しの依頼が出ているかを確かめる … 自動の案内に返事が無ければ、電話で頼みます
3. no_visible_damage と severity_gap は、写真を拡大して見る … 枠の位置と元の写真を見比べ、修理工場に確認するかを決めます
4. needs_human は、全体の写真と接写を見比べて部位を決める … 決めた部位を記録します
5. 技術アジャスターへ回すかを決める … 区分にかかわらず、担当者が決めます

3番目を省かないでください。 severity_gap は、AIの程度の見分けが誤っていても出ます。光の加減で浅く見えたへこみを scratch と答えれば、交換の明細が食い違いとして出ます。 修理工場に確認する前に、元の写真で程度を見直します。

担当者が直した所見は、すべて記録します。 どの写真のどの部位を、どの区分からどの区分に変えたかが、部位の候補の一覧と指示を直す材料になります。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの精度の問題ではなく、撮り方の問題です。 写真の送信画面に撮影の見本を出すほうが、判定を磨くより効きます。

記録を残す

• 元の写真と、AIに渡した写し（向きの補正・大きさの調整の後）
• 1回目と2回目の Gemini API の入力と出力の全文、呼び出しの日時、モデルの名前
• 照合の区分と、そのとき参照した見積書の明細と部位の対応表の版
• 撮り直しの案内を送った日時、選んだ定型文、写真が届いた日時
• 担当者が所見を直した記録 … 写真、部位、直す前と後の区分
• 部位ごと・写真の種類ごとの unknown と unclear の割合

3つ目で「そのときの対応表の版」を残すのは、対応表が後から変わるためです。 見積書の表記を足すと照合の結果が変わり、当時の版が残っていないと、過去の照合をたどれません。