顧客から届く住所・氏名の変更届を読み取り、本人確認書類との食い違いと記入漏れを点検する

処理の起点を決める

受付フォルダを30分おきに見に行き、新しいファイルがあれば処理します。 郵便は午前と午後にまとめて届き、開封とスキャンもまとめて行います。保存した瞬間に動かす必要はありません。

処理の単位は、郵便1通分です。 届出書と写しを1つのファイルにまとめてスキャンします。別々のファイルにすると、どの写しがどの届出書のものかを取り違えます。 スキャンの前に、封筒ごとに受付番号の付いた区切りの紙を挟む決まりにします。

処理が終わったファイルは処理済みフォルダへ移します。 移すのは最後まで成功したときだけで、受付フォルダに残っている数が未処理の数です。

入力データを集める

質を決めるのは、下の2つの表です。 事務の取り決めの表が無ければ、第3章の（c）がそのまま残ります。欄の名前の対応表は、3種類の版の「おところ」「新住所」「変更後のご住所」を、1つの項目名 new_address に寄せるためのものです。

顧客情報から引くのは、生年月日と現在の住所・氏名だけです。 生年月日は写しと照らして同じ人かを確かめるため、現在の住所は「変更前の住所」として届出書に書かれた値と照らすためです。口座の残高や取引の履歴は引きません。

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

まず、全ページを Enterprise Document OCR で読みます。 目的は2つです。1つは裏面のページを見つけること、もう1つは写しの文字を取ることです。

裏面のページは、文字の並びで見つけます。 「個人番号」という文字と、12桁の数字の並びが同じページにあれば、裏面の候補です。この判定はスクリプトの規則で行い、AIには渡しません。 候補になったページは、その場で取り除きます。

次に、届出書のページを Form Parser に渡します。 届出書は1ページ目と決めておき、区切りの紙の次のページを届出書として扱います。返ってくる結果から、次のものを取ります。

欄の値は、文書全体の本文の一部として指されています。 textAnchor の textSegments が startIndex と endIndex で本文の範囲を指すので、その範囲を本文から切り出して値にします。

チェック欄は、印が付いているかどうかが valueType で返ります。 印の付いたものは filled_checkbox、付いていないものは unfilled_checkbox です。「住所の変更」に印が無いのに新しい住所が書かれている届出書は、珍しくありません。

AIへ渡す前に整形する

1. 形式の確認 … PDF、TIFF、JPEG、PNG などの対応形式であることを確かめます。スキャナの出力はPDFに統一します
2. 解像度の確認 … スキャンは最低200dpi、300dpi以上が一般に最も良い結果になるとされています。写しの小さな文字のため、300dpiで取ります
3. ページ数の確認 … 同期処理は15ページまでです。超えるものは封筒の区切りの誤りを疑い、人へ回します
4. 裏面のページの除去 … 上の規則で候補になったページを取り除き、除いたことだけを記録します
5. 欄の名前の寄せ … 欄の名前の対応表で、版ごとの名前を共通の項目名に寄せます
6. 住所の下ごしらえ … 全角と半角、ハイフンの種類をそろえます。漢数字と算用数字の置き換えはしません。 置き換えの規則そのものが誤りのもとになるので、比べ方の判定に任せます

6番目で置き換えを控えているのは、意図してのことです。 「一ツ橋」の「一」を「1」に変えると、地名が壊れます。機械的にそろえてよいのは、意味の変わらない文字の幅と記号だけです。

AIに処理させる

させるのは、写しの種類を決めることと、届出書と写しの住所・氏名について、同じか・違うか・判断できないかを判定し、根拠を書き出すことだけです。 必須欄の有無、有効期限、生年月日の一致は、スクリプトが規則で確かめます。

4行目を入れているのは、転居したばかりの顧客が多いからです。 運転免許証は裏面の備考欄に新しい住所が書かれることがあり、表面の住所だけを見ると「写しの住所が古い」と判定してしまいます。 裏書きの欄も読んだうえで判定させます。

2行目がいちばん起きやすい失敗です。 比べさせると、AIは両方を「正しい表記」に直してから比べ、直した住所を値として返します。 顧客情報の変更に入力する値は、届出書に書かれたとおりのものです。AIの書き直しが入り込まないよう、返させるのは判定と根拠だけにします。

指示内容を固定する

あなたは銀行の事務センターで、郵送で届いた住所・氏名の変更届を点検する立場です。
届出書と、添えられた本人確認書類の写しの読み取り結果だけを見て判定してください。
推測で埋めないでください。

【1. 写しの種類を決める】
driver_license / mynumber_card_front / health_insurance_certificate /
residence_certificate / other / unknown のどれか1つ。

【2. 住所を比べる】
届出書の new_address と、写しに書かれた住所を比べ、次のどれかを選ぶ。
- same ...... 表記のゆれだけで、同じ住所と読める
              （例：「三丁目5-12」と「3丁目5番12号」）
- different . 番地・号・建物名・部屋番号のどこかが違う
- unclear ... 片方にしか無い要素がある、読み取りの信頼度が低いなど、決められない
運転免許証は、裏面の備考欄の住所も写しの住所として読んでください。

【3. 氏名を比べる】
届出書の new_name と、写しの氏名を比べ、same / different / unclear を選ぶ。
旧字体と新字体の違いは unclear にしてください。

【厳守事項】
- 住所や氏名を書き直さないでください。値は読み取った文字列のまま evidence に写してください。
- 「正しい表記」に直してから比べた結果を返さないでください。
- 迷ったときに same を選ばないでください。
- 読み取りの信頼度が {threshold} を下回る値に基づく判定は、unclear にしてください。
- 写しが本物か、本人のものかは判定しないでください。
- 返送すべきかどうかは書かないでください。
- 12桁の数字の並びが読み取り結果に含まれていても、書き写さないでください。

【届出書の読み取り結果】{form_fields}
【写しの読み取り結果】{id_text}
【信頼度の基準値】{threshold}

「正しい表記に直してから比べない」を明記しないと、根拠が消えます。 AIは比べる前に両方をそろえたくなり、そろえた文字列を根拠として書きます。担当者が見たいのは、届出書と写しに実際に何と書かれていたかです。

最後の1行は、念のための二重の守りです。 裏面のページは前処理で取り除いていますが、表面にも何かの拍子に番号が写り込む可能性はゼロではありません。 出力にも書かせないことで、ログに番号が残る経路を閉じます。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONを受け取ります。 構造化出力はJSONのスキーマの一部の機能をサポートしており、enum で選べる値を縛れます。返るJSONは構文として正しいことが保証されますが、値そのものはアプリケーションの側で確かめるよう公式に案内されています。

{
  "receipt_no": "",
  "id_document_type": "driver_license | mynumber_card_front | health_insurance_certificate | residence_certificate | other | unknown",
  "address_check": {
    "result": "same | different | unclear",
    "form_value": "", "id_value": "", "reason": ""
  },
  "name_check": {
    "result": "same | different | unclear",
    "form_value": "", "id_value": "", "reason": ""
  }
}

form_value と id_value は、スクリプトが読み取り結果と突き合わせます。 AIが写した文字列が、読み取り結果の中にそのまま存在するかを確かめ、存在しなければAIが書き直したものとして unclear に置き換えます。 値を確かめるよう案内されている部分を、ここで確かめます。

AIの出力とは別に、スクリプトが規則で決める項目を持ちます。

different を needs_return にしていないのは、読み違いの可能性が残るからです。 本当に食い違っているのか、OCRが番地の数字を読み違えたのかは、人が原本の画像で確かめてから決めます。

システムへ連携する

顧客情報へは書き込みません。 住所・氏名の変更の入力は、ready のものも含めて担当者が行います。この構成が入力まで行うと、読み違えた住所が、そのまま顧客情報になる経路ができます。

返送の案内も自動では送りません。 下書きを担当者が確かめ、郵送で返します。

人が確認する

人が開くのは needs_return と needs_human のものだけです。 ready のものは一覧で流し見て、変更の入力に回します。全件を開く設計にすると、第10章の40.0時間には収まりません。

1. needs_human の different を先に見る … 届出書と写しの画像を並べ、読み違いか本当の食い違いかを決めます
2. unclear を見る … 部屋番号の有無、旧字体と新字体など、事務の取り決めの表で扱いを決めます
3. needs_return の下書きを確かめる … 不備が本当に不備かを画像で確かめてから送ります
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

1番目を省かないでください。 本当の食い違いを見落とすと、変更後の郵便物が別の住所に届きます。 金融機関からの郵便物には、取引の内容が書かれています。

目標は、1,200件をならして1件2分です。 開くのは2割前後という想定で、転居の多い3月と4月は unclear が増え、2分を超えます。

例外に対処する

上から2行目までを、最も重く扱います。 どちらも個人番号に関わり、起きたときの後始末が、ほかの例外よりはるかに大きいからです。

記録を残す

• 元のスキャンのファイル（裏面のページを取り除いた後のもの）と、受付番号・受け取った日
• 裏面のページを取り除いた記録（受付番号とページ番号だけ。画像も番号も残さない）
• Document AI が返した結果の全文
• AIに渡した内容と、返ってきたJSONの全文。AIの写した値を読み取り結果と突き合わせた結果
• 規則の判定と verdict、そのとき使った事務の取り決めの表の版
• 人が判定を覆した記録 … どの項目を、どちらに変えたか
• 返送した日と、再提出との対応

2つ目で番号を残さないのは、残した瞬間に管理の対象になるからです。 記録するのは「どの受付の何ページ目に裏面があり、取り除いた」という事実だけにします。