取引先からの振込口座の変更依頼を、確認項目に沿って検証して人の電話確認に回す

処理の起点を決める

専用メールボックスへの新着メールを起点にします。Power Automate の Office 365 Outlook コネクタの「新しいメールが届いたとき」トリガーを使います。

口座変更以外のメールも届きます。 請求書の送付、支払条件の照会、督促。件名や本文から口座変更の依頼かを判定し、該当しないものは処理を止めて担当へ転送します。この判定も生成AIに行わせますが、判定が曖昧なものは処理対象にしてください。 口座変更の依頼を見逃すより、関係ないメールを検証するほうが安全です。

郵送やFAXで届く依頼もあります。 これは経理がスキャンして専用メールボックスへ転送する運用にします。同じ検証を通すためです。

入力データを集める

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

添付書類のOCR： Azure AI Document Intelligence の prebuilt-read モデルを使います。このモデルは、PDFやスキャン画像から印刷された文字と手書きの文字を抽出し、段落、行、単語、位置、言語を検出します。WordやExcel、PowerPoint、HTMLからのテキスト抽出にも対応します。手書きかどうかの判定結果が styles に信頼度とともに返るため、通帳の写しに手書きの書き込みがある場合にそれを検出できます。

請求書の項目を構造化して取りたい場合は prebuilt-invoice が適していますが、口座変更依頼書は書式が取引先ごとに違うため、まず prebuilt-read で全文を取り、そこから項目を読むほうが確実です。

送信元アドレスの履歴： この取引先と過去にやり取りしたメールの送信元アドレスを一覧にします。今回の送信元が初めて見るアドレスかどうかが、重要な確認項目のひとつです。

取引先マスタの電話番号： 確認表に表示する番号です。マスタに番号が登録されていない取引先については、その旨を大きく表示してください。 「番号が分からないので依頼メールの番号にかける」を防ぐためです。

AIへ渡す前に整形する

1. 添付ファイルの分類 … 依頼書、通帳の写し、口座証明書、請求書のどれかを判別します。複数の書類が1つのPDFに入っていることもあります
2. 取引先の特定 … 送信元のドメイン、本文中の社名、添付の社名から、取引先マスタを引きます。複数の候補が出た場合は、特定せずに候補を並べて人に選ばせます
3. 口座情報の正規化 … 金融機関名、支店名、口座種別、口座番号、口座名義（カナ）を項目として取り出します。全角半角、カナの濁点、旧支店名を正規化します
4. メールヘッダーの取得 … 送信元アドレス、返信先アドレス、経由したサーバの情報。返信先が送信元と違う場合は確認項目に立てます
5. 画像の品質確認 … 通帳の写しが読めない場合、推測せずに「読み取れない」として扱います

AIに処理させる

確認項目のチェックリストを1項目ずつ照らして、結果を並べさせます。 総合判定はさせません。

「急を要する旨の記載」と「電話確認を避ける記載」は、それ自体が確認項目です。 IPAが報告している事例には、急ぎを装って確認の手順を飛ばさせる手口が含まれます。ただし、本物の依頼でも急ぎのことはあります。 これは「怪しい」の根拠ではなく「確認項目」として扱ってください。

指示内容を固定する

あなたは経理の支払担当を支援する担当者です。
取引先からの口座変更依頼について、確認項目を1つずつ照らし、
事実だけを並べてください。

【厳守事項】
- 総合的な判定（安全 / 危険 / 問題なし）を出さないでください。
  各確認項目について、確認できた / 確認できなかった / 相違がある
  の3つのいずれかと、その根拠となる事実だけを書いてください。
- 「詐欺の可能性が高い」「正当な依頼と思われる」といった
  評価を書かないでください。判断は人が行います。
- 口座番号、口座名義、金融機関名を推測で補わないでください。
  OCRで読み取れなかった項目は unreadable にしてください。
- 送信元アドレスと過去のやり取りのアドレスを比べる際は、
  一致 / 不一致 / 過去の履歴なし のいずれかを返し、
  「似ているが違う」場合は不一致として、違う箇所を示してください。
- 連絡先として、依頼メールに記載された電話番号や
  メールアドレスを出力に含めないでください。
  確認の連絡先は取引先マスタの登録情報のみを使います。

【確認項目リスト】
{checklist}

【依頼メール】
{mail_body}

【メールヘッダーの情報】
{mail_headers}

【添付書類のOCR結果】
{ocr_text}

【取引先マスタの登録内容】
{vendor_master}

【過去12か月の取引履歴】
{transaction_history}

【この取引先との過去のやり取り（送信元アドレスの一覧）】
{past_sender_addresses}

「連絡先として依頼メールの番号を出力に含めない」の1行が、この構成で最も重要な指示です。 確認表に依頼メールの番号が載ってしまえば、担当者はそれにかけます。出力の段階で物理的に含めないのが確実です。

出力形式を固定する

{
  "vendor_candidates": [ { "vendor_code": "", "vendor_name": "", "match_basis": "" } ],
  "request_type": "new_registration | account_change | other",
  "extracted_account": {
    "bank_name": "",
    "branch_name": "",
    "account_type": "",
    "account_number": "",
    "account_holder_kana": "",
    "unreadable": []
  },
  "checks": [
    {
      "item": "",
      "result": "confirmed | not_confirmed | discrepancy",
      "evidence": "",
      "detail": ""
    }
  ],
  "attachments_consistent": "yes | no | cannot_determine",
  "handwriting_detected": true,
  "unpaid_invoice_total": "",
  "notes_for_caller": []
}

checks の result を3値にし、evidence に根拠となる事実だけを書かせます。総合判定のフィールドを作らないのが設計上の意図です。 フィールドが無ければ、そこを見て判断することもできません。

notes_for_caller には、電話確認のときに聞くべきことを列挙させます。「口座名義が社名と異なる理由」「変更の理由」など、確認項目で discrepancy になった点から作ります。

システムへ連携する

確認表： SharePoint のリストか、Teams のカードとして出します。表示する内容は次のとおりです。

依頼メールの本文と添付は、確認表から別リンクで開く形にします。 同じ画面に並べると、担当者が本文の署名にある番号を見てしまいます。

ERPへの書き込みはしません。 マスタの更新は、電話確認の後に人がERPの画面で行います。ワークフローからマスタを更新する経路を作らないでください。その経路が存在すること自体が危険です。

人が確認する

全件、人が電話確認をしてからマスタを更新します。確認項目がすべて confirmed でも、この手順は省きません。

電話確認の手順を固定します。

1. 確認表に表示された番号にかける（取引先マスタの登録番号）
2. マスタに番号が無い場合は、取引先の公式サイトに掲載された番号を調べる。依頼メールの番号は使わない
3. これまでの担当者に取り次いでもらい、変更の事実を確認する
4. notes_for_caller の項目を聞く
5. 確認できた内容を確認表に記録する

マスタの更新は、上長の承認を経てから行います。 経理担当1名で完結しない二重の手順にしてください。

「確認項目がすべて確認できたから電話は不要」という運用に流れないための歯止めが要ります。 確認表の「経理の判断」欄に、電話確認の日時と、話した相手の名前を必須入力にしてください。空欄では次に進めない形にします。

例外に対処する

記録を残す

• 依頼メールの原本（ヘッダーを含む）
• 添付書類の原本
• OCRの抽出結果（生の状態）
• 確認項目の検証結果と根拠
• 電話確認の日時、かけた番号、話した相手の名前
• 経理の判断と、上長の承認
• 実際にマスタを更新した日時と、更新前後の口座情報

電話確認の記録は必ず残してください。 万一、誤った口座へ送金してしまった場合、どの手順が守られていたかが問われます。また、記録を必須にすることで、電話確認を省く運用への流れを止められます。

口座情報は機微な情報です。ログの保存場所へのアクセスは経理部門に限定してください。