信用金庫の渉外担当が集金のときに手書きする受領証の控えを読み取り、顧客・金額・入金先の口座を入金のデータにそろえて、記載の欠けと金額の食い違いを拾う

処理の起点を決める

共有フォルダにスキャンが保存されたことを起点にします。 渉外担当が帰店して現金の合計を合わせた後、後方事務の担当が控えをまとめて複合機の自動原稿送り装置に通します。入金処理を終えてからスキャンする順にし、照らす相手の明細がそろっている状態で動かします。

スキャンは渉外担当ごとに1ファイルにします。複合機の宛先を渉外担当ごとに登録しておけば、ファイル名に担当者コードと日付が入ります。書損の控えも同じファイルに入れます。 分けると、連番の抜けを確かめるときに書損の番号が見えません。

入金処理の明細は、同じ時刻までに決まったフォルダに置きます。Python のプログラムは、控えのファイルと明細のファイルが両方そろった担当者から順に処理します。片方しか無いあいだは待ちます。

入力データを集める

質を決めるのは、冊子の交付の記録です。 これが無いと、連番の抜けは「その日に出てきた番号の中の飛び」しか見えません。冊子の最初と最後の番号が分かっていれば、前日までに出てきた番号と合わせて、まだ戻っていない番号を毎日数えられます。

集金予定表は、予定にあって控えが無い顧客を拾うために使います。 不在で集金できなかった顧客なのか、控えを出し忘れたのかを、渉外担当に確かめる材料になります。

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

読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。オンラインの処理は1回の要求で最大15ページなので、1人分のスキャンを1枚ずつのページに分けてから送ります。 まとめて送る場合は、公式の上限が100ページのバッチ処理を使います。

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

入金処理の明細は、書き出したファイルを Python で読むだけです。金額は数値に、顧客番号と口座番号は先頭のゼロを落とさないよう文字列のまま読み込みます。

AIへ渡す前に整形する

1. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。複合機の保存は PDF にします
2. 解像度と色の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。複写の薄い数字を残すため、300dpiのグレーかカラーで保存し、白黒2値にしません
3. 1枚ずつに分ける … 1人分のスキャンをページごとに分け、ページの順を残します
4. 控え以外の紙の確認 … 顧客から預かったメモや振込用紙が混ざることがあります。控えでないものは処理せずに担当へ戻します
5. 書損の控えの確認 … 「書損」と書かれた控えは、金額の照合には使わず、連番の確認にだけ使います
6. 重複の確認 … 同じ連番の控えが2枚あれば、両方を担当に回します

2番目が、この構成の精度をいちばん左右します。 複写の控えの薄い数字は、白黒2値にすると欠けます。欠けた「8」は「3」や「6」に見え、（b）の見間違いを機械が繰り返すことになります。

5番目で書損を金額の照合から外すのは、書損の控えにも金額が書かれているからです。 書き損じた金額を入金処理の明細と照らすと、合わない行として毎日並びます。

AIに処理させる

させるのは、控えの各欄を、決まった項目に書かれたとおりに写すことと、訂正の跡と書損の印を拾うことです。 金額の照合も、連番の確認も、Python が行います。

訂正の跡を拾わせるのは、訂正された金額がいちばん確かめが要る値だからです。 二重線で消された金額と書き直された金額の両方が読み取り結果に出ることがあり、どちらを金額として写すかを機械に決めさせると、誤りが見えなくなります。 両方を写させ、訂正印の有無とあわせて人に回します。

3行目がいちばん大事です。 金額の食い違いにAIが「転記の誤りと思われる」と書き添えると、確かめる人はその見立てに引きずられます。 集金の点検は、思い込みを持たずに原本と照らすための作業です。

指示内容を固定する

あなたは信用金庫の営業店で、渉外担当が持ち帰った受領証の控えの
読み取り結果を、決まった項目に写す立場です。OCRが返した結果だけを見て、
書かれていることを写してください。推測で埋めないでください。

【写す項目】
receipt_date（受領日）、serial_no（連番）、customer_name（顧客名）、
customer_no（顧客番号）、account_no（入金先の口座番号）、
amount_text（金額）、category（種類）、staff_seal（担当印）

【厳守事項】
- 数字は書かれたとおりの文字列で写してください。
  桁を補う、薄い数字をそれらしい数字に直す、ということをしないでください。
- 金額の「￥」「,」「-」「円」は、書かれたとおりに含めて写してください。
- 欄が空欄なら status を blank、文字はあるが読めなければ unreadable に
  してください。空欄と読めない欄を混ぜないでください。
- 二重線で消された値と書き直された値があるときは、両方を写し、
  corrected を true にしてください。どちらが正しいかを決めないでください。
- 訂正印の有無を correction_seal に写してください。
- 「書損」と書かれていれば void を true にしてください。
- 種類の印が2つ以上あるときは category を multiple にしてください。
- 金額が正しいか、入金処理と合っているか、食い違いの理由を書かないでください。
- 受領証の控えでない書類と判断した場合は、document_type に種類を書いてください。

【読み取り結果】{ocr_result}

AIに入金処理の明細を渡していないことが、このプロンプトのいちばんの工夫です。 明細を見せると、薄い「8」を明細の「3」に合わせて写します。照らす相手を見せなければ、合わせることもできません。 照合は Python が、AIの写した値と明細を並べて行います。

「どちらが正しいかを決めない」を訂正の欄に書いているのも同じ理由です。 訂正の前後の値のうち、明細と合うほうを選べば、点検はいつも「合っていた」で終わります。

出力形式を固定する

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

{
  "document_type": "collection_receipt_copy",
  "page_no": 0,
  "void": false,
  "fields": [
    {
      "item": "receipt_date | serial_no | customer_name | customer_no | account_no | amount_text | category | staff_seal",
      "value": "",
      "status": "read | blank | unreadable | missing",
      "corrected": false,
      "previous_value": "",
      "correction_seal": "present | absent | unclear"
    }
  ]
}

1つ目の理由は、項目ごとに status を持てることです。 記載の欠けは blank と missing、薄い数字は unreadable で、同じ空白に見える欄を2つに分けて扱えます。 blank は渉外担当への指摘、unreadable は原本の確かめです。

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

not_posted と serial_gap は、他の印より先に役席に出します。 どちらも、預かったお金の記録が入金処理につながっていないことを示します。理由の多くは処理の遅れや書損の持ち帰り忘れですが、それを確かめるのは人で、その日のうちに行います。

3つ目は、previous_value で訂正の前の値を残せることです。 訂正が多い渉外担当や、訂正印の無い訂正が続く担当は、件数として見えるようになります。 （d）の失敗はここで解消します。

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

システムへ連携する

勘定系にも営業店端末にも書き込みません。 この構成は書き出された明細を読むだけで、入金処理の訂正は、これまでどおり後方事務が端末の手順で行います。 照合の結果から自動で訂正の取引を起こす経路は作りません。

点検の一覧は、役席の確かめの記録を兼ねます。 一覧の各行に、確かめた担当、渉外担当の説明、役席の確認の欄を持たせ、紙の点検簿に押していた印を、この一覧の記録に置き換えるかどうかは金庫の事務の規程で決めます。

人が確認する

後方事務の担当が見るのは、印の付いた控えだけです。 印の無い控えは、件数と合計金額を一覧で流し見ます。

1. not_posted と serial_gap を先に見る … 控えの原本と冊子の3枚目を見て、渉外担当にその場で確かめます
2. amount_mismatch を見る … 控えの写しの金額欄に枠が出ます。原本で数字を確かめ、控えと入金処理のどちらが違っているかを決めます
3. uncertified_correction と check_original を見る … 原本で訂正の跡と薄い数字を確かめます
4. incomplete を記録する … 記載の欠けを渉外担当に伝え、件数を残します
5. 役席が一覧を確かめる … すべての行に確かめの結果が入っていることを見てから、締めに進みます

1番目を締めの前に必ず終えてください。 翌日に回すと、渉外担当の記憶も、集金先との連絡の機会も1日遠くなります。 説明のつかないものは、金庫の規程に沿って報告します。

目標は、3,000枚をならして1枚0.6分です。 印の無い控えは流し見で数秒、印の付いた控えは原本を見て渉外担当に確かめるので数分かかります。

例外に対処する

最後の行で目視に戻すのは、集金の点検を翌日に持ち越さないためです。 システムが止まった日も、締めの前の点検は行います。仕組みに頼りきらず、従来の手順に戻れることを確かめておきます。

記録を残す

• 元のスキャンと、スキャン日時・店舗・渉外担当・スキャンした担当
• OCRが返したJSONの全文と、Claude API の応答の全文
• 照合に使った入金処理の明細のファイルと、その書き出し日時
• 照合と連番の確認の結果（印の種類）と、確かめた担当・渉外担当の説明・役席の確認
• 冊子の交付の記録と、番号ごとの戻った日
• 渉外担当ごとの incomplete と uncertified_correction の件数

4つ目が、この構成で最も大事な記録です。 後から点検のやり方そのものを確かめられるとき、どの食い違いを、誰が、どう確かめて、何と説明されたかをたどれる必要があります。

最後の行は、渉外担当への指導の材料になります。 欠けや訂正印の無い訂正が続く担当には、件数を見せて書き方を一緒に見直します。