損害保険の事故受付で契約者から届く手書きの事故状況報告書を読み取り、日時・場所・相手・事故の図の説明を受付の入力項目にそろえ、記載の食い違いと不足を事故担当へ返す

処理の起点を決める

報告書のファイルが取込の場所に届いたことを起点にします。 郵送の報告書は受付課がスキャンして入れ、契約者が撮った画像は受付のシステムが受け取った時点で同じ場所に置きます。経路が2つあっても、ここから先は区別しません。

Python のスクリプトを、社内のサーバーで5分ごとに定時実行します。 新しいファイルを順に処理し、確認待ちの一覧に載せるところまで成功したものだけを処理済みとして記録します。 失敗したものは次の実行で拾い直されます。

受付番号が分からないファイルは処理しません。 郵送の報告書は書式の右上に受付番号を印字して送り、画像はどの受付から届いたかがシステムで分かります。受付番号の無いファイルは、担当者に回して受付を特定してもらいます。

入力データを集める

質を決めるのは、電話受付の記録の書き方です。 電話で聞いた事故の概要が自由な文だけだと、報告書と比べる相手がありません。 電話受付の記録にも、日時・場所・相手の車両番号・自車と相手の動きの区分の欄があることが、比較の前提です。まだ無いなら、比較の前に電話受付の入力項目を足します。

動きの区分の一覧は、言い回しをそろえるために使います。 「右に曲がろうとした」「右折待ち」「右へ」を同じ「右折」として扱えるようにします。ただし、どの区分にも当たらない文を、近い区分に寄せることはしません。

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

読み取りは、Python から Document AI の処理の API を呼ぶだけです。公式のページには Python のクライアントライブラリで応答を扱う例が載っています。返ってきた Document から次のものを取ります。

電話受付の記録は、受付番号で事故受付のシステムから読みます。 書き込みは確認待ちの一覧に限り、電話受付の記録そのものには書き込みません。

チェックボックスは、書式の作り方で読める・読めないが分かれます。 公式のページでは、チェックボックスのモデルはラジオボタンに対応しないとされています。届出の有無を「○で囲む」書式だと、チェックボックスとしては返りません。書式を「□あり □なし」の四角に直します。

AIへ渡す前に整形する

1. 形式の確認 … Document AI の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。契約者が撮った画像もそのまま入れられます
2. 画質の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。契約者の撮った画像で文字が小さすぎるものは、読み取る前に撮り直しを頼む候補にします
3. 向きと傾き … 画像が横向きや逆さのものは、向きをそろえてから渡します
4. ページの確認 … 報告書が2ページ以上に分かれる書式なら、受付番号でまとめて1件にします。オンラインの処理は1回の要求で最大15ページです
5. 重複の検知 … 同じ受付番号のものが2つ届いたら、後のものを書き直しとして扱い、前のものも残します

2番目は、受付の連絡の仕方で減らせます。 書式を送るときに、「紙全体が写るように、真上から明るい場所で」と撮り方を添えます。撮り直しを頼む連絡は、契約者にとって負担です。

AIに処理させる

させるのは、報告書の値を受付の入力項目にそろえ、動きを区分に当てることだけです。 電話受付の記録との比較は Python が行います。

Python が比べる規則は次のとおりです。

動きを3つに分けて比べるのが、この設計の特徴です。 電話・文・図の説明のうち2つが同じで1つだけ違えば、事故担当はその1つから確かめ始められます。 3つとも違えば、契約者に聞き直す前に事故担当が図を見ます。

1行目がいちばん起きやすい失敗です。 相手の連絡先が空欄の報告書でも、電話受付の記録には連絡先があることがあります。AIに両方を渡すと、報告書の値として埋めて返そうとします。 そのため、AIには報告書の読み取り結果だけを渡し、電話受付の記録は渡しません。

指示内容を固定する

あなたは損害保険会社の事故受付課で、契約者が書いた
事故状況報告書を受付の入力項目に書き写す担当です。
渡すのは、報告書1件の読み取り結果です。
書かれている文字だけを使って、項目ごとに値を並べてください。
推測で埋めないでください。

【やること】
1. accident_datetime：事故の日付と時刻をそのまま写す
2. location：事故の場所の欄をそのまま写す
3. counterparty：相手の氏名、連絡先、車両番号、保険会社を項目ごとに写す
4. police_report：届出の「あり」「なし」の印と、警察署名
5. injury：けが人の有無の印と、書かれた説明をそのまま
6. own_move_text、other_move_text：
   説明の文から、自車と相手の動きを動きの区分の一覧に当てる
7. own_move_figure、other_move_figure：
   図の中と図の下に書かれた文字から、同じように区分に当てる。
   文字が無ければ none
8. 項目ごとに status を付ける
   read（読めた）／missing（欄に値が無い）／unreadable（読めない）
9. evidence に、根拠にした文字列をそのまま写す

【厳守事項】
- 欄に値が無いものは missing とし、他の欄や一般的な事故の様子から埋めないでください。
- 動きを、図の線や矢印の形から推さないでください。書かれた文字だけを使います。
- 区分の一覧に当たらない動きは unknown とし、近い区分に寄せないでください。
- どちらの車に過失があるか、事故の原因が何かは書かないでください。
- けがの程度を言い換えたり、重い・軽いと判断したりしないでください。
- 車両番号の文字や数字を補ったり、似た番号に直したりしないでください。

【動きの区分の一覧】{move_codes}
【読み取り結果】{ocr_result}

「過失や原因を書かない」を明記しないと、AIは説明の文を読んでまとめに書き添えます。 「相手の一時不停止が原因と考えられる」といった一文は、事故担当が読む下書きに入った時点で、判断の先入観になります。

図の説明を文と分けて当てさせるのは、契約者が両方に違うことを書くからです。 文では「相手が右折」、図の下には「相手 直進」と書かれている報告書は、それだけで事故担当が最初に確かめるべき点です。

出力形式を固定する

Claude API の構造化出力を使い、次の形のJSONで受け取ります。 output_config.format に JSON スキーマを渡すと、応答がそのスキーマに沿った形になります。

{
  "receipt_no": "J2610-04512",
  "fields": [
    { "name": "accident_datetime", "value": "2026/10/3 18:20", "status": "read",
      "confidence": 0.91, "evidence": "10月3日 午後6時20分頃" },
    { "name": "counterparty_plate", "value": "", "status": "unreadable",
      "confidence": 0.38, "evidence": "品川 3?? ほ 12-?4" },
    { "name": "police_report", "value": "あり", "status": "read",
      "confidence": 0.95, "evidence": "☑あり ○○警察署" }
  ],
  "moves": {
    "own_move_text": "go_straight", "other_move_text": "turn_right",
    "own_move_figure": "go_straight", "other_move_figure": "go_straight",
    "evidence_text": "相手が右折してきた", "evidence_figure": "相 直進"
  }
}

1つ目の理由は、比較をAIの外に出せることです。 上の例では、文と図の説明で相手の動きが違うので、Python が different の印を付けます。電話受付の記録との比較も同じ形で行い、区分の一覧を直しても AI を呼び直さずにやり直せます。

2つ目は、unreadable の値を空のまま返すことです。 相手の車両番号が一部しか読めないとき、読めた部分を evidence に残し、value は空にします。 担当者は画像を見て、読めた部分を手がかりに埋められます。

3つ目は、evidence に原文を残すことです。 「午後6時20分頃」の「頃」は、時刻の比較で差があっても印を軽く扱う手がかりになります。

公式のページでは、列挙の値の大文字・小文字までは保証されないとされているので、区分と status は Python で正規化してから使います。stop_reason が max_tokens のときは出力が途中で切れているので、一覧に載せずに呼び直します。

システムへ連携する

受付のシステムの入力項目そのものには書き込みません。 書くのは確認待ちの一覧の下書きまでで、担当者が確定したときに初めて入力項目に入ります。 誤った読み取りが、事故担当の見る正式な記録に直接入る経路を作らないためです。

事故受付のシステムとの受け渡しの方法は、システムごとに違います。 連携の口が無いシステムなら、確認待ちの一覧を別の表として作り、担当者が確定した値を手で入れる形から始めます。

人が確認する

1. 届出の印を先に見る … 届出の欄が missing か「なし」の報告書は、契約者に電話で確かめます。交通事故証明書の要否に関わるため、受付の段階で確かめます
2. 読み取った値を画像と見比べて確定する … unreadable の項目は画像から埋めます。read の項目も、相手の車両番号と連絡先は必ず画像で確かめます
3. 食い違いの印を事故担当への申し送りに書く … どの項目が、電話・文・図の説明のどれとどれで違うかを、両方の値と一緒に書きます
4. 確定して事故担当に回す … 確かめた担当者の名前を残します

2番目で、相手の車両番号と連絡先を必ず見るのは、誤りの影響が大きいからです。 1字違いの車両番号や電話番号は、相手方への連絡が届かない、別の人に届くことにつながります。

1番目の電話では、契約者を責める聞き方をしません。 届出の欄が空なのは、届け出たのに書き忘れただけのことも多いからです。「届け出た警察署を教えてください」と事実だけを聞き、届け出ていなければ届け出るよう案内します。

目標は、900件をならして1件2.8分です。 印の無い報告書でも値の確定に1〜2分はかかり、印の付いた報告書は数分かかります。印の付く報告書が3割前後という想定です。

例外に対処する

6行目は、件数は少なくても手のかかる例外です。 玉突きの事故は相手が2台以上になり、報告書の欄に収まりません。欄外に書き足された相手の情報は、項目名と値の組として返らないことが多いので、全文のテキストから人が拾います。

記録を残す

• 届いた報告書のファイルと、届いた日時と経路（郵送／画像）
• Document AI が返したJSONの全文
• Claude API に渡した入力と、返ってきたJSON
• Python の比較の結果と、そのときの動きの区分の一覧の版
• 担当者が確定した値と、下書きから直した項目
• 契約者に確かめた内容と日時

下書きから直した項目を残すのは、読み取りの弱いところを知るためです。 相手の車両番号ばかり直しているなら、書式の欄の大きさか、撮り方の案内に問題があります。保存したものは、社内の規程で決めた期間を過ぎたら消します。 事故の記録には個人の情報が多く含まれます。