法人の口座開設で受け取る申込書・登記事項証明書・本人確認書類を読み取り、書類どうしの食い違いと足りない確認を審査担当へ返す

処理の起点を決める

本部の受付フォルダに、1件分の書類がそろって保存されたことを起点にします。 営業店には、1件ごとにフォルダを作り、書類の種類ごとに1ファイルにしてスキャンすることを頼みます。全部を1つのPDFにまとめると、どこからどこまでが登記事項証明書かを機械が判定する段が増えるからです。

フォルダの作成時に、受け取った日と、申込みの種別（新規の法人／設立準備中の法人など）を入力してもらいます。受け取った日は、書類の作成日が6か月以内かを判定する起点です。書類のどこにも書かれていない情報なので、受け取った人に入れてもらうしかありません。

フォルダに「スキャン完了」の印が付いた時点で処理を始めます。1ファイルずつ保存されるたびに動かすと、まだ届いていない書類を「不足」と判定してしまいます。

入力データを集める

質を決めるのは、いちばん下の表記の正規化の一覧です。 これが無いと、第3章の（a）がそのまま機械の出力に移ります。一覧に載っている違いだけを「同じ」と見なし、載っていない違いはすべて食い違いとして残します。

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

読み取りは、書類ごとにレイアウトモデルを呼ぶだけです。出力はMarkdown形式（outputContentFormat=markdown）を指定します。 登記事項証明書の区画の見出しや表の構造が記号で残り、後段で「どの区画の値か」を見分けやすくなります。

単語ごとの信頼度は、突き合わせに使う項目の部分だけを見ます。 番地の数字1文字が読めていないまま突き合わせると、読み取りの誤りを「所在地の食い違い」として返すことになります。 信頼度が低い項目は、突き合わせの前に unreadable にします。

AIへ渡す前に整形する

1. 書類の種類の確認 … ファイルごとに、題名から書類の種類を確かめます。営業店の付けた種類と違えば印を付けます
2. ページ数とサイズの確認 … PDFとTIFFは最大2,000ページ、有料（S0）レベルで500MBが上限です。パスワード付きのPDFは解除してから入れます
3. 本人確認書類の表裏の確認 … 運転免許証などの写しは表と裏の両方があるかを見ます。裏面に住所の変更が書かれていることがあるためです
4. 表記の正規化 … 取り出した値に対して、一覧にある対応だけを機械的に適用します
5. 住所の分解 … 都道府県・市区町村・町名・丁目・番地・号・建物名に分け、それぞれを別に比べます
6. 日付の統一 … 和暦と西暦を西暦の日付にそろえます。元号の変わり目の日付は一覧で対応させます

5番目を軽く見ないでください。 住所を1つの文字列のまま比べると、建物名の有無だけで食い違いになります。分けて比べれば、「番地までは一致、建物名が申込書にだけある」と返せます。 審査担当が見るべきなのは、番地の違いのほうです。

AIに処理させる

させるのは、書類ごとに決まった項目を取り出し、根拠にした部分をそのまま書き出すことだけです。 書類どうしの比較はさせません。

1行目と2行目の「現在の値」が、この業務でいちばん大事な区別です。 履歴事項全部証明書には、変更前の商号や本店が履歴として並びます。OCRの文字列からは、紙の上で現在と履歴を見分けるための見た目の手がかりが落ちることがあります。 区別がつかないときは、どちらかを選ばせずに ambiguous で返させ、候補を両方残させます。

1行目がいちばん起きやすい失敗です。 書類を全部まとめて渡し「食い違いを探して」と頼むと、AIは「表記の違いはあるが同一と考えられる」と書いて済ませます。その「考えられる」の中に、本店の移転や代表者の交代が紛れ込みます。 取り出しは書類ごとに分けて頼みます。

指示内容を固定する

あなたは信用金庫の口座開設の審査で、提出された書類から項目を取り出す係です。
今から渡すのは1種類の書類の読み取り結果です。書かれていることだけを取り出してください。

【書類の種類】{document_type}
（application＝申込書／registry＝登記事項証明書／id_doc＝本人確認書類／
  business＝事業内容の書類／ubo＝実質的支配者の申告書）

【取り出す項目】
- trade_name（商号）、address（本店・所在地）、representatives（代表者の氏名と住所）、
  established（設立日・会社成立の年月日）、purposes（目的・事業内容を項目ごとに）、
  issued_on（作成日）、expires_on（有効期限）
- 書類にない項目は status を missing にしてください。

【厳守事項】
- 書かれた文字をそのまま写してください。略記を直す、旧字体を新字体にする、
  住所の書き方を変えることをしないでください。
- 登記事項証明書では、現在の値と、変更前の履歴の値を区別してください。
  区別がつかない場合は status を ambiguous にし、候補をすべて candidates に並べてください。
  どちらかを選ばないでください。
- 日付は書かれたまま写してください。和暦を西暦に直さないでください。
- 読み取り結果の信頼度が低い文字を含む項目は、status を unreadable にしてください。
- ほかの書類と合っているか、口座を開設してよいかは書かないでください。
- evidence には、各項目の根拠にした部分を読み取り結果からそのまま写してください。

【読み取り結果（Markdown）】{layout_markdown}
【信頼度の低い単語の一覧】{low_confidence_words}

「書き方を変えない」を明記しないと、AIは親切に表記をそろえて返します。 そろえた結果が正しくても、どの書類にどう書かれていたかという情報が消えます。 照会の文面に「申込書には『(株)山田商会』、登記には『株式会社山田商會』」と書けなくなります。

書類の種類を最初に渡し、1種類ずつ頼んでいるのも同じ理由です。 複数の書類を一度に渡すと、ある書類の値で別の書類の空欄を埋めます。

出力形式を固定する

Azure OpenAI の構造化出力で、書類ごとに次の形のJSONを受け取ります。 構造化出力は、呼び出しのときに渡したJSONスキーマに出力を従わせる機能で、すべての項目を必須にし、additionalProperties を false にする必要があります。書類の種類が違っても同じ形で返るので、突き合わせの規則を1つにできます。

{
  "document_type": "application | registry | id_doc | business | ubo",
  "fields": [
    { "name": "trade_name | address | representative | established | purpose | issued_on | expires_on",
      "value": "",
      "status": "ok | missing | unreadable | ambiguous",
      "candidates": [""],
      "evidence": "" }
  ]
}

突き合わせは Azure Functions が規則で行います。 書類ごとのJSONを集め、正規化の一覧を適用してから、項目ごとに比べます。

どれか一方が unreadable か ambiguous なら、その突き合わせは mismatch にしません。 読み取りの問題を、書類の食い違いとして記録しないためです。審査担当には「読めなかった」と「違っていた」を別の色で返します。

作成日の6か月の判定は、法令の書きぶりに合わせます。 犯罪収益移転防止法の施行規則では、法人の本人確認書類のうち登記事項証明書などは、提示又は送付を受ける日前6か月以内に作成されたものに限るとされています。起点は受け取った日で、審査の日ではありません。 審査が遅れても、受け取った日が6か月以内なら期限切れにはしません。

確認事項ごとの裏付けの一覧も、同じ規則の層で作ります。

この一覧は「裏付けの書類があるか」までです。 書類があることと、確認が済んだことは違います。確認の完了は、審査担当が判断して記録します。

システムへ連携する

照会の下書きは、確認事項ごとに書きます。 「代表者の住所が違う」ではなく、「登記事項証明書の代表取締役の住所は○○、運転免許証の住所は△△です。住所の変更の有無をお客さまにご確認ください」のように、どの書類のどこが違うかと、顧客に何を聞けばよいかを並べます。営業店が本部へ聞き返す往復を、文面の段階で減らします。

人が確認する

審査担当が開くのは、match 以外の項目だけです。 match の項目は一覧で流し見ます。

1. 作成日と有効期限を最初に見る … 期限切れがあれば、ほかの項目を見る前に照会を決めます
2. unreadable と ambiguous を見る … 原本の画像で読み、値を入れ直します。履歴の行と現在の行の取り違えは、ここで見つけます
3. mismatch を見る … 違う要素が何かを確かめ、本店の移転や代表者の交代など、理由のある違いかを判断します
4. 確認事項の一覧を見る … 裏付けの書類があるかと、内容が足りているかを判断します
5. 照会の要否を決め、下書きを直して送る
6. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

1番目を先にするのは、第3章の（c）を逆にするためです。 期限切れが最後に分かると、それまでの確認がやり直しになります。最初に分かれば、新しい証明書が届いてから一度だけ見ればよくなります。

目標は、1件8分です。 書類がそろっていて食い違いが無い案件は2〜3分、本店の移転や代表者の交代がある案件は15分を超えます。開設の可否を判断する時間は、この8分に含めていません。

例外に対処する

8行目の「一覧に足す」は、審査担当の判断で行います。 機械が「同じと見なしてよさそう」と学んで広げることはしません。同じと見なす範囲は、人が決めて一覧に書いたものだけです。

記録を残す

• 書類ごとのスキャン、受け取った日、営業店、申込みの種別
• 読み取り結果の全文と、書類ごとに取り出した項目のJSON
• 正規化した値と、そのときに使った正規化の一覧の版
• 突き合わせの結果、確認事項の一覧、照会の下書き
• 審査担当が覆した判定と、直した照会の文面
• 営業店への照会の回数と、照会の理由の内訳

3つ目で一覧の版を残すのは、一覧が後から増えるからです。 一覧に足した表記の違いは、過去の案件の判定の意味を変えます。どの版で「同じ」と見なしたかが残っていないと、後から判定を説明できません。

最後の行は、営業店への頼み方を見直す材料になります。 作成日の古い証明書が多い店舗には、受付の時点で作成日を見てもらうよう伝えます。