保険代理店に届く紙の保険申込書を読み取り、契約者・被保険者・保障内容の項目と記入漏れを確かめて申込データに起こす

処理の起点を決める

Python のスクリプトを、代理店のサーバーで数分おきに動かします。 店舗の複合機は、スキャンした申込書を店舗ごとの共有フォルダに保存します。スクリプトは各フォルダの「受付」を見て、まだ処理の記録が無いファイルを拾います。

処理が終わったスキャンは「処理済み」へ移します。移すのは、管理表への書き込みまで終わったときだけにします。途中で止まったものは次の実行で拾い直され、「受付」に残っている数が、そのまま未処理の数になります。

保険の始まる日が近い申込から先に処理します。 募集人はスキャンのファイル名に保険の始まる日を付ける決まりにし、スクリプトはその順に並べます。始まる日まで数日しかない申込は、記入漏れに気づくのが1日遅れるだけで間に合わなくなるためです。

入力データを集める

質を決めるのは、書式の表です。 書式の版を取り違えると、告知の欄を塗りつぶさずに送ってしまうことがあります。版の判定は、申込書の隅に印刷された様式の番号で行い、番号が読めない、または表に無い書式は、OCRに送らずに事務担当へ回します。

必須の欄の表は、保険会社の手引きが改まるたびに直します。 表の各行に、根拠にした手引きの版を書いておき、どの版の決まりで記入漏れと判断したかを後から追えるようにします。

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

スクリプトは、書式の判定と塗りつぶしが済んだ画像を Form Parser のプロセッサに送ります。オンラインの処理は1回の要求で最大15ページなので、申込書と意向確認書の組は1回で足ります。

表の中の□は、formFields には出てきません。 公式のページでは、表の中のチェックボックスは✓ と ☐ の文字として表のセルに入るとされています。特約を表の形で選ぶ書式では、表のセルの文字を見ます。

署名の欄は、値ではなく「何かが書かれているか」だけを見ます。 署名の欄の位置を書式の表に持たせ、その位置に文字が検出されているかを boundingPoly で確かめます。誰の署名かをこの構成が判断することはありません。

AIへ渡す前に整形する

1. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。複合機の保存形式はPDFにそろえます
2. 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。複合機の設定を300dpiにそろえます
3. 書式の判定 … 様式の番号を読み、書式の表に無いものは事務担当へ回します
4. 告知の欄の塗りつぶし … 書式の表に告知の欄の位置があるものは、その領域を黒く塗った画像を作ってから送ります。元のスキャンは送りません
5. 告知書の混入の確認 … 告知書の様式の番号が見つかったページは、処理を止めて事務担当へ回します
6. ページの組み合わせ … 申込書と意向確認書が別ファイルで届いたら、ファイル名で1件にまとめます

4番目と5番目が、この構成の前提です。 募集人が告知書を外し忘れても、様式の番号で止まるようにします。 告知書の様式の番号は、書式の表に「送らない書式」として載せておきます。

AIに処理させる

させるのは、読み取り結果を取込データの項目に書かれたとおりに写すことと、書式ごとに違う欄の名前を共通の項目に当てることです。 必須の欄の判定も、項目どうしの照合も、Python の規則で行います。

4行目が、AIを使う理由です。 8社・数十種類の書式で、同じ意味の欄が違う名前で印刷されています。書式ごとに対応の規則を書き続けるより、共通の項目の定義を渡して当てさせるほうが、版が変わったときに崩れにくくなります。

3行目がいちばん起きやすい失敗です。 契約者と被保険者が同じ住所に住んでいそうなとき、被保険者の住所の欄が空なら、契約者の住所で埋めようとします。保険会社が「同上」を認めているかどうかは書式ごとに違い、埋めた瞬間に記入漏れが見えなくなります。

指示内容を固定する

あなたは保険代理店の業務課の担当で、募集人から届いた保険申込書の
読み取り結果を、代理店の取込データの項目に写す立場です。
OCRが返した結果だけを見て、書かれていることを写してください。
推測で埋めないでください。

【写す項目】
人：policyholder（契約者）、insured（被保険者）、beneficiary（受取人）
  それぞれ name、kana、birth_date、sex、address、phone、relation
保障：product_type、sum_insured、term、riders
払込：payment_method、payment_route
そのほか：application_date、signature_policyholder、signature_insured

【欄の名前の対応】{field_map}

【厳守事項】
- 値は書かれたとおりの文字列で写してください。
  桁を補う、和暦と西暦を直す、表記をそろえる、ということをしないでください。
- 欄が空なら status を blank、文字はあるが読めなければ unreadable に
  してください。空欄と読めない欄を混ぜないでください。
- ある人の欄が空でも、別の人の欄の値で埋めないでください。
  「同上」と書かれていれば、そのまま「同上」と写してください。
- 生年月日と年齢が合わなくても、どちらかを直さないでください。
- □の印が読み取れない、または複数に印がある場合は unclear にし、
  候補をすべて candidates に写してください。
- 署名の欄は、何かが書かれているかだけを present / absent / unclear で
  答えてください。誰の署名かは書かないでください。
- 二重線で消された値と書き直された値があれば、両方を写してください。
- 対応の表に無い欄の名前は、unmapped に欄の名前と値をそのまま写してください。
- 申込を受けるべきか、保障が適切かは書かないでください。
- 告知書と判断した場合は、何も写さず document_type を
  medical_disclosure にしてください。

【読み取り結果】{ocr_result}

「別の人の欄の値で埋めない」と「同上はそのまま写す」を並べているのは、どちらも保険会社ごとに扱いが違うためです。 「同上」を認める書式と認めない書式があり、判断は必須の欄の表の側で行います。 AIが「同上」を住所に置き換えると、その判断ができなくなります。

最後の指示は、塗りつぶしと様式の番号をすり抜けた告知書への最後の止めです。止まったものは、管理表に書かず事務担当へ回します。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に JSON スキーマを渡す方式）を使い、形を固定します。

{
  "document_type": "application | intention_confirmation | medical_disclosure | other",
  "insurer": "", "form_no": "",
  "persons": [
    { "role": "policyholder | insured | beneficiary",
      "fields": [
        { "item": "name | kana | birth_date | sex | address | phone | relation",
          "value": "", "status": "read | blank | unreadable | unclear",
          "corrected": false, "previous_value": "" }
      ] }
  ],
  "coverage": [
    { "item": "product_type | sum_insured | term | riders | payment_method | payment_route | application_date",
      "value": "", "status": "read | blank | unreadable | unclear", "candidates": [] }
  ],
  "signatures": { "policyholder": "present | absent | unclear", "insured": "present | absent | unclear" },
  "unmapped": [ { "label": "", "value": "" } ]
}

1つ目の理由は、人ごとに欄を持てることです。 契約者・被保険者・受取人が同じ形の要素で並ぶので、契約者と被保険者が同じ人か、別の人かで要る欄を切り替える規則を Python の側で書けます。

2つ目は、記入漏れと食い違いを Python の規則で持てることです。

check_image は、募集人に知らせる前に事務担当が片づけます。 読めない欄の多くは、スキャンを拡大すれば読めます。読めないものだけを、原本の郵送を待って確かめます。

公式のページでは、列挙の値の大文字・小文字までは保証されないとされているので、status などは Python で小文字にそろえてから使います。stop_reason が max_tokens のときは出力が途中で切れているので、切れたら管理表に書かずに呼び直します。

システムへ連携する

契約管理の仕組みには、この構成から直接書き込みません。 取込用のCSVを書き出すのは事務担当の操作で、missing や signature_missing が残っている申込は書き出せないようにします。

保険会社への送付も、この構成からは行いません。 保険会社へ送るのは、事務担当が原本とスキャンを確かめた申込だけです。募集人への知らせも、事務担当が中身を見てから送ります。

人が確認する

事務担当が見るのは、印の付いた行のある申込だけです。 印の無い申込は、保険会社と項目の数を流し見て、確定の列に印を付けます。

1. check_form を先に見る … 欄の名前が当たらない書式は、ほかの印が当てになりません。書式の表を直して読み直します
2. check_image を見る … スキャンの該当箇所を拡大して確かめます。読めないものは推測せず、原本を待ちます
3. missing・signature_missing・same_as_above を確かめる … スキャンで、本当に空いているかを目で見ます
4. age_mismatch・cross_doc_mismatch・date_order を確かめる … どちらの値が書かれているかを見て、どちらが正しいかは決めずに募集人に知らせます
5. 募集人に知らせる … 申込ごとに直す箇所をまとめ、保険の始まる日が近い順に送ります
6. 取込用のCSVを書き出す … 印が片づいた申込だけを書き出し、契約管理の仕組みに取り込みます

目標は、600件をならして1件3分です。 印の無い申込は流し見で数十秒、印の付いた申込はスキャンとの見比べと募集人への知らせで数分かかります。

例外に対処する

1行目は、この構成の前提が崩れる場面です。 告知書が混ざったことが分かったら、その店舗の募集人とスキャンの手順を確かめ直します。

記録を残す

• 元のスキャンと、塗りつぶし後に送った画像、店舗・募集人・スキャンした日時
• OCRが返したJSONの全文と、Claude API の応答の全文
• そのとき使った書式の表と必須の欄の表の版
• 付いた印と、事務担当が確かめた結果、募集人に知らせた日時、直った日時
• 取込用のCSVを書き出した日時と担当、保険会社へ送った日
• 告知書の混入で止まった件数と店舗

最後の行は、告知書を仕組みに入れないという前提が守られているかを見るためのものです。 件数が0でない店舗は、スキャンの手順を見直します。