保険会社に郵送で届く手書きの住所・氏名の変更届を読み取り、証券番号・新しい住所・届出日を事務の入力項目にそろえて、記入漏れと印の欠けを拾う

処理の起点を決める

Python のプログラムを15分おきに動かし、複合機の保存先の共有フォルダに新しいPDFがあるかを確かめます。 動かすのは社内のサーバーの定時実行の仕組みで、事務センターの開いている時間だけにします。

15分おきにするのは、午前の郵便で届いた届の確認待ちを、その日のうちに片づけるためです。 夜間にまとめると、3月・4月の繁忙期には確認待ちが数日分たまります。

処理が終わったPDFは「処理済み」のフォルダに移します。 移すのは一覧への書き込みが終わったときだけで、保存先のフォルダに残っている数が、そのまま未処理の数になります。 スキャンは1枚の届を1つのPDFにし、2人分の届が1件にまとまらないようにします。

入力データを集める

質を決めるのは、照合用の写しです。 写しに無い証券番号は引き当てられず、前日に別の手続きで住所が変わった契約は、写しの登録住所がすでに新しくなっています。

郵便番号データは、日本郵便が公開している1レコード1行・UTF-8形式のCSVを使います。 手元に置いて照合するので、届の住所を外部の検索サービスに送らずに済みます。

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

Python は、Document AI のクライアントライブラリで Form Parser のプロセッサに届のPDFを送ります。オンラインの処理は1回の要求で最大15ページなので、1枚の届は1回で足ります。

印の欄は、Form Parser のキーと値に頼りません。 公式のページでは、値の入っていないキーと値の組は確実には読み取れないとされています。印の欄はもともと文字の無い欄なので、押されていないのか、読み取りから落ちたのかを区別できません。 自社の様式で印の欄の位置は決まっているので、Python が届の画像からその範囲を切り出し、Claude API に画像として渡します。

公式のページでは、Claude API の画像は JPEG、PNG、GIF、WebP に対応し、最大8000×8000ピクセル、APIを直接使うときは1枚10MB（base64エンコード後）までとされています。切り出しはPNGにして小さく保ちます。証券番号と郵便番号は文字列のまま扱い、先頭の0を落としません。

AIへ渡す前に整形する

1. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。複合機の保存はPDFにそろえます
2. 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。複合機の既定の設定を300dpiにしておきます
3. 様式の確認 … 1ページ目の様式番号の位置に、自社の様式番号が読めるかを見ます。読めなければ、他社の書類か古い様式として確認待ちに回します
4. 印の欄の切り出し … 様式で決まった位置から、印の欄と記入者の氏名の欄を切り出します
5. 重複の確認 … 同じ証券番号で、受付日の近い届がすでにあれば、再送か訂正かを確かめる印を付けます
6. 同封物の確認 … 2ページ目以降の別の書類は読み取りから外し、確認待ちに添えます

3番目を先に行うのは、印の欄の切り出しが様式の位置に頼っているからです。 古い様式では位置が違い、別の欄を切り出して「印なし」と答えることになります。

AIに処理させる

させるのは、読み取り結果を契約管理の入力項目に書かれたとおりに写すことと、印の欄の画像に印があるかを答えることです。 証券番号の引き当ても、旧住所の照合も、郵便番号の照合も、Python の規則で行います。

5行目が、AIを使う理由の1つです。 手書きの住所は「〇〇市△△町1-2-3 □□マンション405」と1行に続けて書かれることも、番地と建物名を2行に分けて書かれることもあります。どこまでが町域でどこからが番地かを決めるのは、決まった規則では書きにくい作業です。

6行目は、印があるかだけを答えさせます。 届出印との照合は既存の仕組みと担当者が行います。

1行目が、この題材でいちばん重い失敗です。 補った番号がたまたま別の契約の番号だと、別の契約者への通知がすべて他人の住所に届きます。 読めない桁は読めないまま返させ、引き当てられなければ確認待ちにします。

指示内容を固定する

あなたは保険会社の契約サービスの事務担当で、郵送で届いた
住所・氏名の変更届の読み取り結果を、入力項目に写す立場です。
OCRが返した結果と、添付の印の欄の画像だけを見て答えてください。

【写す項目】
見出し：filing_date_text（届出日。書かれたとおり）、writer_name、
phone_text、new_name（改姓のときの新しい氏名）
証券番号：policy_numbers（書かれたものをすべて、書かれた順に）
変更の対象：target_policyholder、target_insured、target_beneficiary
（チェックの状態。checked／unchecked／unclear）
住所：old_address_text、new_address_text、new_postal_code_text
住所の分割：prefecture、city、town、block、building
印の欄：seal（present／absent／unclear）

【厳守事項】
- 証券番号と郵便番号は、書かれたとおりの文字列で写してください。
  読みにくい桁を、ありそうな数字に直さないでください。
  読めない桁があれば、その項目の status を unreadable にしてください。
- 郵便番号を住所から補ったり、住所に合わせて直したりしないでください。
- 届出日が空欄なら filing_date_text を空にし、status を blank に
  してください。他の日付（受付日の印など）で埋めないでください。
- 新しい住所を分けるときは、書かれた文字だけを使ってください。
  丁目・番地の書き方を「1-2-3」や「1丁目2番3号」にそろえないでください。
  分けられなければ split_failed を true にしてください。
- 旧住所と新しい住所が同じに見えても、そのまま写してください。
- 印の欄の画像は、朱色の印の跡があれば present、何も無ければ absent、
  かすれや汚れで判断できなければ unclear と答えてください。
  届出印と同じ印かどうかは答えないでください。
- 変更届でない書類と判断した場合は、document_type に種類を書いてください。

【読み取り結果】{ocr_result}
【印の欄の画像】（画像として添付）

照合用の写しをAIに渡していないことが、このプロンプトのいちばんの工夫です。 登録住所や契約者名を見せると、読みにくい字を登録されている住所に寄せて写します。寄せた瞬間に、旧住所が登録と合っているかという確かめが意味を失います。 番地の書き方をそろえさせないのも、元の書き方を残して、そろえ方の誤りを後から見つけるためです。

出力形式を固定する

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

{
  "document_type": "address_change",
  "header": [
    { "item": "filing_date_text | writer_name | phone_text | new_name",
      "value": "", "status": "read | blank | unreadable" }
  ],
  "policy_numbers": [
    { "value": "", "status": "read | unreadable" }
  ],
  "targets": {
    "policyholder": "checked | unchecked | unclear",
    "insured": "checked | unchecked | unclear",
    "beneficiary": "checked | unchecked | unclear"
  },
  "address": {
    "old_address_text": "", "new_address_text": "", "new_postal_code_text": "",
    "prefecture": "", "city": "", "town": "", "block": "", "building": "",
    "split_failed": false, "status": "read | unreadable"
  },
  "seal": "present | absent | unclear"
}

1つ目の理由は、届を「証券番号×変更の対象」の行に機械的に展開できることです。 Python は policy_numbers と targets の checked を掛け合わせて入力行を作り、照合用の写しから役割ごとの登録住所を引いて並べます。

2つ目は、確認待ちに回す理由を規則で持てることです。

policy_not_found と old_address_mismatch は、他の印より先に担当者に出します。 別の人の契約を引き当てている可能性と、本人以外からの届の可能性があるためです。

公式のページでは、minimum・maximum などの数値の制約や文字列の長さの制約は使えないとされています。証券番号の桁数は Python の照合で確かめます。 拒否は stop_reason が refusal、出力の上限で切れたときは max_tokens になり、スキーマに合わないことがあります。どちらも一覧に書かず、人に回すか呼び直します。

システムへ連携する

契約管理システムには、この構成から直接は書き込みません。 一括取込に回すのは担当者で、回すのは印の無い届の行と、確認が済んだ行だけです。読み取りの誤りが、そのまま登録住所になることはありません。

返送の案内も送りません。 不備の箇所を差し込んだ下書きまでにし、送るかは担当者が決めます。

人が確認する

担当者が見るのは、印の無い届の流し見と、確認待ちの届です。 印の無い届は、展開された行の数と、新しい住所・郵便番号を一覧で見て、一括取込に回します。

1. policy_not_found と old_address_mismatch を先に見る … 画像で確かめ、旧住所が登録と合わない届は上席に回します
2. name_mismatch を見る … 改姓の届か、家族が代わりに書いたのかを確かめます
3. postal_mismatch を見る … どちらが正しいかは推測で決めず、本人に確かめるか返送します
4. date_check・target_check・seal_check を見る … 受付の決まりに照らして決めます
5. 決めた結果と理由を記録する

目標は、1,200件をならして1件2分です。

例外に対処する

上の3行が大半を占めます。 どれもスキャンの設定と様式の問題です。公式のページでもラジオボタンには対応しないとされており、「○で囲む」欄が多ければ様式の改定の材料になります。

記録を残す

• 元の届のPDFと、受付日・スキャンした日時
• OCRが返したJSONの全文と、Claude API の応答の全文
• 印の欄の切り出し画像
• 照合に使った照合用の写しの出力日時と、郵便番号データの版
• 付いた印と、担当者が決めた結果（返送・補って入力・上席へ）と理由
• 一括取込に回した行と、回した担当者・日時
• 様式ごとの unreadable と check_image の件数

4つ目を残すのは、登録住所が日々変わるためです。 どの時点の写しで判断したかが無いと、届の誤りか写しの古さかを区別できません。