取引先から届く振込先の変更届を読み取り、支払先マスタと照らして、口座名義の食い違いや押印・連絡先の不一致など、なりすましの疑いを支払の前に拾う

処理の起点を決める

受付フォルダに届出が保存されたことを起点にします。 Python のプログラムを数分おきに動かし、新しいファイルを探します。変更届は1件ずつ処理し、支払の締めの前にまとめて処理する形にはしません。届いた日に確認票ができていれば、確かめの電話に使える日が増えます。

FAXとPDFは、受け取った経路をファイル名に入れて保存します。 メールで届いたPDFは、送ってきたメールアドレスも記録しておきます。 送信元のアドレスがマスタの取引先の担当者と違うことも、確かめの材料になります。

支払の締めの3営業日前からは、未処理の届出を1時間ごとに数えて担当に知らせます。 締めの直前に届いた届出が、確かめが済まないまま埋もれないようにします。

入力データを集める

質を決めるのは、支払先マスタの電話番号です。 確かめの電話は、マスタに登録済みの番号にかけます。この番号が古いと、確かめそのものができません。 マスタの電話番号の最終の確認日も、あわせて書き出します。

過去の変更の履歴は、短い間隔での変更を拾うために使います。 数か月前に変わったばかりの口座が、また変わるという届出は、正当な理由があることもありますが、確かめる理由になります。

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

読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。オンラインの処理は1回の要求で最大15ページなので、変更届と通帳の写しは1回で足ります。

空欄の見分けは、キーと値のペアだけに頼りません。 「変更前の口座番号」という項目名があって値が取れないとき、全文の中で項目名の近くに数字が検出されているかを見ます。何も検出されていなければ空欄、検出されていて信頼度が低ければ読めない欄です。

支払先マスタは、口座番号と取引先コードを文字列のまま読みます。 先頭のゼロを落とすと、照合が合わなくなります。

AIへ渡す前に整形する

1. 形式の確認 … PDFか画像であることを確かめます。複合機の保存はPDFにします
2. ページの分け方の確認 … 変更届のページと通帳の写しのページを分けます
3. 送り状の除外 … FAXの送り状は読み取りの対象から外します
4. 名義の正規化の準備 … マスタの名称のカナを、全角・半角、法人の略称（「カ）」「（カ」など）をそろえた形にしておきます
5. 重複の確認 … 同じ取引先の届出が短い間隔で2通あれば、両方を担当に回します

4番目は、AIではなく Python で行います。 名義の略称の付け方には決まった形があるので、規則で書けるものは規則で書きます。 AIに読み替えさせると、「似ている」を「同じ」として扱うことになります。

5番目は、なりすましの届出の後に本物の取引先から問い合わせが来る、という順にも備えるためです。 2通が並ぶと、どちらかが本物でないことがすぐに分かります。

AIに処理させる

させるのは、届出と通帳の写しの欄を、決まった項目に書かれたとおりに写すことと、押印の欄に印影があるかを拾うことです。 マスタとの照合は、Python の規則で行います。

押印は「あるかどうか」だけを拾います。 届出印が登録の印と同じかどうかは、画像の見た目で判断できることではありません。 印影の比べ合わせは、担当が過去の届出の原本と並べて行います。

4行目を、AIにさせないことの表にわざわざ書いています。 確認票を作るときに、届出の電話番号が「連絡先」として目立つ場所に出ると、担当はその番号にかけてしまいます。 確認票の連絡先の欄には、マスタの番号だけを出します。 届出の番号は照合の結果の欄に、食い違いとして出します。

指示内容を固定する

あなたは経理部で、取引先から届いた振込先の変更届と通帳の写しの
読み取り結果を、決まった項目に写す立場です。OCRが返した結果だけを見て、
書かれていることを写してください。推測で埋めないでください。

【写す項目】
取引先：vendor_name、vendor_code、address、representative、
contact_person、phone、email
変更前の口座：old_bank、old_branch、old_type、old_number、old_holder_kana
変更後の口座：new_bank、new_branch、new_type、new_number、new_holder_kana
通帳の写し：passbook_bank、passbook_branch、passbook_number、passbook_holder
その他：filed_date（届出日）、effective_date（適用の開始日）、
seal（届出印の欄の印影の有無）、form_type（自社の様式か）

【厳守事項】
- 口座番号・電話番号は書かれたとおりの文字列で写してください。
  桁を補う、読めない桁をそれらしい数字にする、ということをしないでください。
- 名義は書かれたとおりに写してください。漢字に直したり、
  略称を補ったりしないでください。
- 欄が空欄なら status を blank、文字はあるが読めなければ unreadable に
  してください。空欄と読めない欄を混ぜないでください。
- 通帳の写しが無ければ、通帳の項目の status を absent にしてください。
- 届出印の欄は、印影があれば present、無ければ absent、
  判断できなければ unclear にしてください。印が正しいかは判断しないでください。
- 届出が本物か、怪しいか、支払ってよいかは書かないでください。
- 変更届でない書類と判断した場合は、document_type に種類を書いてください。

【読み取り結果】{ocr_result}

AIに支払先マスタを渡していないことが、このプロンプトのいちばんの工夫です。 マスタを見せると、読めない桁をマスタの番号に合わせて写します。変更前の口座がマスタと合うかどうかは、この構成でいちばん大事な照合の1つです。 照らす相手を見せなければ、合わせることもできません。

「怪しいかを書かない」と明記しているのは、AIの見立てが担当の判断に影響するためです。 「問題なさそうです」と書かれた確認票を見ると、電話で聞く中身が浅くなります。

出力形式を固定する

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

{
  "document_type": "payee_change_form",
  "form_type": "own | other | unclear",
  "seal": "present | absent | unclear",
  "fields": [
    { "item": "vendor_name | vendor_code | address | representative | phone | email | old_bank | old_branch | old_type | old_number | old_holder_kana | new_bank | new_branch | new_type | new_number | new_holder_kana | filed_date | effective_date",
      "value": "", "status": "read | blank | unreadable" }
  ],
  "passbook": {
    "status": "read | absent | unreadable",
    "bank": "", "branch": "", "number": "", "holder": ""
  }
}

1つ目の理由は、項目ごとに status を持てることです。 変更前の口座が blank なのか unreadable なのかで、確かめの電話で聞く中身が変わります。

2つ目は、照合を Python の規則で持てることです。

payment_due は、他の印と組み合わせて並べ方を決めます。 適用の開始日が近く、old_account_mismatch や contact_mismatch も付いている届出を、確認票の一覧の一番上に出します。 確かめに使える時間が少ないものから見ます。

contact_mismatch を「疑いの印」と呼ばないのは、正当な移転もあるからです。 本社が移転して届出の住所が新しい、というのはよくあることです。印は事実を示すだけで、意味づけは確かめの電話の後に担当が行います。

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

システムへ連携する

会計システムには書き込みません。 支払先マスタの書き換えは、確かめと上長の承認の後に、担当が会計システムの画面で行います。この構成から書き込めるようにすると、確かめを飛ばす近道ができてしまいます。

確認票は、確かめの記録を兼ねます。 確かめた日時、かけた番号（マスタの番号であること）、話した相手、確かめた内容、上長の承認の欄を持たせます。

人が確認する

担当は、全件について確認票を見て、マスタに登録済みの電話番号で取引先に確かめます。 印の有無で変わるのは、電話で聞く中身と、確かめの順番です。

1. payment_due の付いたものから見る … 支払日までに確かめが済むよう、先に電話します
2. 印の付いた項目を、電話で具体的に聞く … 「変更前の口座の番号の末尾を教えてください」のように、届出に書かれていない情報で確かめます
3. seal_check は原本と過去の届出を並べる … 届出印の印影を担当が見比べます
4. 確かめが済まないものは、支払を保留するかを上長と決める … 古い口座で支払うか、支払そのものを待つかは、取引先に確かめたうえで決めます
5. 確認票に記録し、上長の承認を受けてマスタを書き換える

2番目の聞き方が、確かめの質を決めます。 「変更届を出されましたか」と聞くだけでは、なりすましの相手に確かめていても「はい」と返ってきます。マスタの番号にかけ、届出に書かれていないことを聞くのが基本です。

目標は、120件をならして1件6分です。 電話の時間は含みません。見比べと記録の時間が減り、電話で何を聞くかが確認票に並んでいる状態を目指します。

例外に対処する

6行目は、この構成の弱点です。 マスタの電話番号が古いと、確かめの電話がかけられません。届出の番号を代わりに使うことはしません。 営業の担当が持つ名刺や過去の取引の書類など、登録済みの別の連絡先を使います。

記録を残す

• 元の変更届と通帳の写し、受付日、経路、メールの送信元
• OCRが返したJSONの全文と、Claude API の応答の全文
• 照合に使った支払先マスタと支払予定の書き出し日時
• 確認票の内容と、確かめた日時・かけた番号・話した相手・聞いた内容・上長の承認
• 支払先マスタを書き換えた日時と担当
• 確かめの結果、届出が本物でなかった件数と、そのとき付いていた印

4つ目が、この構成で最も大事な記録です。 後から支払の誤りが分かったとき、どの届出を、誰が、どの番号に電話して、何を確かめたかをたどれる必要があります。

最後の行は、規則を見直す材料になります。 本物でなかった届出に、どの印が付いていたかを数えておくと、確認票の並べ方を見直す根拠になります。