手書きの口座振替依頼書を読み取って登録データにそろえ、口座番号の桁・届出印の欄・記入漏れの不備を返送の前に洗い出す

処理の起点を決める

Azure Blob Storage の受付用のコンテナーにファイルが追加されたことを起点にします。 Azure Logic Apps の Blob Storage のマネージド コネクタのトリガー「BLOB が追加または変更されたとき (プロパティのみ)」を使い、続けて「BLOB コンテンツの取得」で中身を取ります。

このトリガーには、知っておくべき性質が2つあります。 1つは、ストレージ コンテナーのルート フォルダーで起動し、設定した時点ですでにあるBLOBは無視することです。委託先ごとにフォルダーを分けると、入れ子のフォルダーでは起動しません。受付用はルートにまとめ、委託先はファイル名で区別します。 もう1つは、ポーリングする仮想フォルダー内のBLOBが30,000個までに制限されることで、超えると新しいBLOBでワークフローが起動しないことがあります。処理が終わったファイルは、必ず処理済みのコンテナーへ移します。

スキャンは、束が届いた日のうちに行います。束ごとに1つのPDFにまとめてスキャンし、ワークフローの最初で1枚ずつに分けます。 ファイル名には、委託先コードと受付日、束の番号を入れます。受付台帳の件数と、分けた枚数が一致するかを最初に確かめます。

処理済みへ移すのは、確認画面への書き込みまで成功したときだけです。 受付用に残っている数が、そのまま未処理の数です。

入力データを集める

質を決めるのは、3つ目と5つ目です。 口座番号のマス数は様式で決まっています。桁の点検は、そのマス数と記入された数字の数を突き合わせるだけです。 一般的な桁数の知識に頼らず、様式の側の決まりで見ます。

委託先ごとの取り決めは、規則の表に持たせます。 訂正印のある訂正を受け付けるか、口座名義が利用者本人と違うもの（保護者名義など）をどう扱うか。ここを人の判断に残すと、第3章の（c）が繰り返されます。

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

モデルの学習が最初の作業です。 様式ごとに、記入済みの依頼書を5枚以上用意し、Document Intelligence Studio で欄にラベルを付けて学習させます。学習の操作で buildMode を template に設定するとカスタム テンプレート モデルになります。

届出印の欄は「署名」のフィールドとしてラベルを付けます。 カスタム テンプレート モデルは署名のフィールドに対応しています。ただし、印影を署名として安定して検出できるかは、自社の様式と朱肉の色で事前に試して確かめる必要があります。 検出が不安定なら、押印欄を「領域」として切り出し、確認画面で人が見る形に落とします。

学習データには、うまく書かれていない依頼書も入れます。 マスからはみ出した数字、薄い複写、斜めのスキャン。きれいな5枚だけで学習すると、実際の束で信頼度が落ちます。 様式の小さな違い（印刷の版の違いなど）があれば、同じ学習データにそれぞれ5枚以上入れます。

AIへ渡す前に整形する

1. ページの分割 … 束のPDFを1枚ずつに分けます。両面スキャンの白紙の裏は除きます
2. 件数の照合 … 分けた枚数と受付台帳の件数が一致するかを見ます。合わなければ、束ごと止めます
3. 形式と寸法の確認 … PDFまたは画像であること、画像が50×50から10,000×10,000ピクセルの間であることを確かめます
4. 解像度の確認 … 抽出するテキストの最小の高さは、1024×768の画像で12ピクセルです。マスの中の数字は小さいので、スキャンは300dpiに固定します
5. パスワードの確認 … パスワードでロックされたPDFは、提出前に解除する必要があります（スキャナの暗号化の設定を切ります）
6. 様式の判別 … 委託先コードから様式を引き、合成したモデルで読ませます
7. 重複の検知 … 同じ委託先・同じ顧客番号の依頼書が直近にあれば、二重の受付として印を付けます

2番目を省かないでください。 束の中で2枚が重なったままスキャンされると、1件が消えます。消えた1件は、誰も気づかないまま引落しが始まらない利用者になります。

AIに処理させる

OCRのモデルにさせるのは、欄ごとの値と状態を読み取ることだけです。 点検は、読み取った値に規則を当てて行います。

判定は、次の規則で決めます。

真ん中の行が大事です。 needs_return は委託先へ書き直しを頼むもので、利用者に手間をかけさせます。 押印欄が空に見えても、それが朱肉の薄さで検出されなかっただけなら、返送は空振りです。信頼度が基準に届かないものは、返送ではなく人の確認に回します。

⑥を needs_human にしているのは、表記ゆれが多いためです。 「〇〇信金」「〇〇信用金庫」、支店名の旧称、合併前の金融機関名。マスタと合わないことが、そのまま不備とは限りません。

3行目は特に気をつけてください。 ゆうちょ銀行の口座は、記号の先頭が1か0かで口座の種類が分かれ、番号の桁数によって振込用の口座番号への変換方法が違うとされています。また、記号と番号の間に1桁の数字がある場合、その数字は振込には使わないとされています。依頼書に書かれた記号と番号をそのまま登録し、変換は基幹システムの決まった処理に任せます。

指示内容を固定する

生成AIは、返送状の下書きだけに使います。 点検の結果は規則で決まっているので、生成AIに渡すのは不備のコードと欄の名前までです。

あなたは収納代行の事務センターで、委託先に口座振替依頼書の書き直しを
お願いする文書を作る担当です。次の不備の一覧から、委託先あての返送状の下書きを作ってください。

【不備の一覧】{issues}
  例: [{"form_id": "A-0123", "code": "seal_missing", "field": "届出印"},
       {"form_id": "A-0124", "code": "account_digits", "field": "口座番号"}]
【委託先の名称】{client_name}
【返送の期日】{due_date}

【厳守事項】
- 不備の一覧に無い不備を書き足さないでください。
- 依頼書の番号（form_id）ごとに、どの欄をどう直してほしいかを1行で書いてください。
- 口座番号、金融機関名、氏名などの値を本文に書かないでください。
  依頼書は同封するので、番号と欄の名前だけで足ります。
- 「印鑑が違う」「口座が存在しない」など、事務センターで確かめていないことを書かないでください。
  届出印は「押印が確認できませんでした」と書いてください。
- 利用者の落ち度を責める書き方をしないでください。
- 書き直しの依頼書は新しい用紙に書いてもらう必要がある場合、その旨を書いてください。
  訂正の扱いは {correction_rule} に従ってください。
- 出力は次のJSONで返してください。

「値を本文に書かない」を入れるのは、返送状が委託先の担当者を経由するためです。 口座番号は返送状に要りません。依頼書の番号と欄の名前があれば、同封した依頼書で場所が分かります。

「確かめていないことを書かない」も同じくらい大事です。 押印欄が空に見えたことと、印鑑が違うことは別の話です。後者は金融機関の判断で、事務センターが書けば誤りになります。

出力形式を固定する

OCRのモデルの結果から、規則の層で次の形のJSONを作ります。

{
  "form_id": "",
  "client_code": "",
  "form_type": "",
  "fields": [
    { "name": "account_number", "value": "", "confidence": 0,
      "status": "ok | blank | unreadable", "crop_ref": "" }
  ],
  "deposit_type": { "selected": ["普通"], "confidence": 0 },
  "seal": { "detected": true, "confidence": 0 },
  "checks": [ { "code": "account_digits", "field": "account_number", "detail": "" } ],
  "verdict": "ready | needs_return | needs_human",
  "duplicate_of": null
}

crop_ref が、7番目の見比べのための項目です。 欄の位置の情報から画像を切り抜き、その場所を持たせておきます。確認画面では、切り抜きと値を横に並べて、1枚ずつ見比べます。

1つ目の理由は、checks と verdict を別の層に置けることです。 委託先の取り決めが変わっても、直すのは規則だけです。2つ目は、返送状の下書きに渡すのが checks だけで済むことです。 生成AIに口座番号や氏名を渡さずに済みます。

返送状の下書きは、Azure OpenAI の構造化出力で受け取ります。 構造化出力は、指定した JSON スキーマに従った応答を返させる仕組みで、すべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する決まりです。依頼書の番号ごとの行と、本文の段落を固定の項目にしておくと、返送状の書式に流し込めます。

システムへ連携する

基幹システムへは、確定したものだけを渡します。 口座番号の見比べが済んでいないものは、ready でも書き出しません。読み取りの直後に登録すると、1桁の読み違いがそのまま引落し先になります。

金融機関・支店のマスタは読むだけです。 合わなかった金融機関名をマスタに書き足しません。合併や支店の統廃合はマスタ側の更新で扱います。

人が確認する

人が見るのは2種類です。 全件の口座番号と金融機関・支店の欄、そして needs_return と needs_human の依頼書です。

1. 口座番号の見比べ … 切り抜きと読み取った値を並べ、1桁ずつ合っているかを見ます。合っていれば確定、違っていれば値を直して確定します
2. 金融機関・支店の見比べ … 名称とコードの切り抜きを見て確定します
3. needs_human を確かめる … 信頼度が低い欄を画像で見て、不備か読めなかっただけかを決めます
4. needs_return を確かめる … 該当の欄を画像で見て、本当に空欄か、本当に桁が違うかを確かめます
5. 判定を覆したら記録する … どの欄を、どちらに変えたかを残します

1番目は、二重の入力の代わりです。 二重の入力は「2人が別々に打って一致すれば正しい」という考え方でした。見比べは「画像と値を同じ画面で照らす」考え方で、1人で済みます。 見比べで直した件数は、毎週数えておきます。読み取りの癖が見えてきます。

目標は、1,800枚をならして1枚2分です。 見比べに1分、needs_return と needs_human の確認をならして1分という想定です。不備の多い委託先の束では2分を超えます。

例外に対処する

上から2行目が、運用で最も起きやすい例外です。 委託先は様式を断りなく変えることがあります。テンプレートは様式の変更で精度が落ちるので、 委託先コードと様式の組を一覧で持ち、知らない様式は読み取りに進ませません。

記録を残す

• 依頼書の画像と、委託先コード、受付日、束の番号
• OCRが返したJSONの全文（欄ごとの値、選択マーク、署名、信頼度）と、使ったモデルの番号
• 規則による点検の結果（checks、verdict）と、そのときの規則の表と委託先の取り決め
• 見比べで人が直した記録 … どの欄を、何から何に直したか、誰が確定したか
• 返送状の下書きと、送った版、送った日
• 基幹システムへ書き出した日時と件数、金融機関へ送った束の記録
• 金融機関から返却された依頼書と、その理由

最後の行が、この仕組みを育てる材料です。 金融機関から返却された依頼書のうち、事務センターの点検で止められたはずのものを数えます。押印欄の空きで返ってきたものが減らないなら、署名の検出の基準を見直します。