銀行に届く外国送金の依頼を、送金の目的・相手国・取引の履歴と社内の基準に照らして、追加で確かめる事項のある依頼を判定し、担当者の確認に回す

処理の起点を決める

外為の事務のシステムで、依頼が「受付済み」になったことを起点にします。 窓口の入力でもインターネットバンキングでも、受付済みになった時点で依頼の内容はそろっています。入力の途中の依頼を判定しないために、状態の変化を起点にします。

起動のしかたは、外為の事務のシステムが何を出せるかで決まります。状態の変化を通知できるなら、その通知で Azure Functions を呼びます。 通知が無いシステムなら、受付済みの依頼の一覧を数分おきに読み出し、まだ判定していないものだけを処理します。どちらでも、依頼番号で一度だけ判定するように、判定済みの依頼番号を記録します。

依頼の内容が後から訂正されたときは、判定をやり直します。 金額や受取人が変わると、当てはまる項目が変わるからです。訂正の前の判定は消さず、版を上げて残します。

入力データを集める

質を決めるのは、社内の確認基準の「判定の材料」の列です。 「送金の目的が事業内容に照らして合理的か」とだけ書かれた項目は、AIにも担当者にも判断の幅が残ります。「顧客情報の事業内容に無い品目の代金」「取引目的に無い種類の送金」のように、何と何を比べるかまで書くと、判定がそろいます。 金融庁のガイドラインも、顧客の営業内容や所在地が取引目的・取引態様に照らして合理的でないなどのリスクが高い取引について、追加的な措置を講ずることを求めています。

フィルタリングの結果は、判定の材料ではなく入口の条件です。 ヒットのある依頼は、この構成の対象から外して既存の手順に回します。制裁リストとの照合をAIにさせることはしません。

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

送金の履歴は、AIに丸ごと渡しません。 過去12か月で数百件の送金がある法人もあります。Functions の中で受取人ごとの件数・金額の平均と最大、初回かどうかを計算し、その要約だけを渡します。 AIに数百行を読ませて「普段と違うか」を判断させると、計算を言葉で行うことになり、数が合わなくなります。

確認基準と国・地域の区分には版の番号を付けます。 区分は国際的な動向や当局の公表に応じて更新されます。どの版で判定したかが分からないと、後から判定の理由を説明できません。

AIへ渡す前に整形する

1. フィルタリングの結果の確認 … ヒットがあれば、ここで処理を止めて既存の手順に回します
2. 添付資料の文字の読み取り … 請求書や契約書の写しから文字を取り出します。読み取れないものは「添付読取不可」の印を付けます
3. 履歴の要約 … 同じ受取人への過去の送金の件数、金額の平均と最大、初回の日付を計算します
4. 規則で決まる項目の判定 … 受取人の所在国の区分、金額が過去の最大を大きく超えるか、初めての受取人か、を計算と一覧の照合で決めます
5. 顧客情報の鮮度の確認 … 顧客情報の更新日が社内の定める期間より古ければ、「顧客情報の更新が必要」の印を付けます
6. 文章を読む項目の選び出し … 確認基準のうち、送金の目的と事業内容の整合のように文章を読まないと決められない項目だけを選びます
7. 渡す情報の絞り込み … 個人の顧客の生年月日や住所など、判定に要らない項目を外します

4番目と5番目をAIにさせないのは、数と一覧で決まるものは規則のほうが確実だからです。 国の区分は一覧と照らせば決まり、金額の比較は数の大小です。AIに任せるのは、6番目で選んだ、文章を読まないと決められない項目だけです。

2番目の「添付読取不可」は、確認に回す理由として残します。 添付の請求書が読めないまま、目的の欄の「代金」だけで整合を判定すると、事業内容と合っているかを確かめないまま standard になります。

AIに処理させる

させるのは、文章を読む確認項目について、1項目ずつ当てはまりを判定し、根拠の記載を写し、顧客に確かめる事項の案を書くことです。

各項目の判定は3つのうちから選ばせます。not_applicable（当てはまらない）、applicable（当てはまる）、insufficient（材料が足りず決められない）です。insufficient を用意するのが大事です。 これが無いと、材料の無い項目をAIはどちらかに寄せて答えます。

最後の行は、指示と照合の両方で守ります。 根拠の引用を「依頼・添付・顧客情報の記載」に限ると決めておけば、記載に無い属性で判定した項目は、引用ができずに照合で落ちます。

1行目と3行目を外すのは、法令の求める確認の主体が銀行だからです。 外為法第17条は、銀行等が顧客の支払等について許可等を要しないこと、または要件を備えていることを確認した後でなければ、為替取引を行ってはならないとしています。AIの判定はその確認の材料の1つで、確認そのものではありません。

指示内容を固定する

あなたは銀行の外為事務センターで、外国送金の依頼を受け付けたときに、
社内の確認基準に照らして追加で確かめる事項がないかを洗い出す担当者を手伝います。
渡された情報だけを見て、確認項目ごとに判定してください。

【やること】
1. 渡された確認項目それぞれについて、status を次の3つから選ぶ。
   not_applicable … 当てはまらない
   applicable …… 当てはまる
   insufficient … 渡された情報だけでは決められない
2. applicable と insufficient の項目には、根拠にした記載を quote に写す。
   quote の出典を source に書く（request ／ attachment ／ customer_profile ／ history_summary）。
3. applicable の項目には、確認基準の「顧客に確かめる事項」をもとに、
   この依頼に合わせた確認事項の案を customer_questions に書く。

【厳守事項】
- 送金を受けてよいか、断るべきか、疑わしいかを書かないでください。
  「問題ありません」「不正です」「疑わしい」という言葉を使わないでください。
- 制裁の対象かどうかを判断しないでください。名前が似ているかを考えないでください。
- 国籍、名前の響き、性別、年齢から当てはまりを決めないでください。
  根拠は、渡された記載に書かれていることだけにしてください。
- quote は原文の文字を1字も変えずに写してください。要約や言い換えをしないでください。
- 金額の比較や国の区分は、渡された計算の結果をそのまま使ってください。
  自分で計算し直さないでください。
- 材料が足りないときは insufficient を選んでください。
  not_applicable に寄せないでください。
- 確認事項の案は、確認基準に書かれた事項と資料から作ってください。
  確認基準に無い資料を求める案を作らないでください。

【確認項目（版：{rule_version}）】{rule_items}
【依頼の内容】{request}
【添付資料の文字】{attachment_text}
【顧客の情報】{customer_profile}
【送金の履歴の要約】{history_summary}
【規則で判定した項目の結果】{rule_results}

「疑わしい」という言葉を名指しで禁じないと、出てきます。 確認基準にマネロン対策の考え方が書かれているので、AIは自然に結論まで書こうとします。結論の言葉を禁じ、項目の番号と引用だけを返させます。

「not_applicable に寄せない」を書くのは、見落としのほうが重いからです。 余計な確認は担当者が1つ外せば終わりますが、当てはまらないとされた項目は誰の目にも止まりません。

出力形式を固定する

次の形の JSON を、構造化出力で受け取ります。

{
  "request_id": "",
  "rule_version": "",
  "items": [
    {
      "item_id": "P-03",
      "status": "not_applicable | applicable | insufficient",
      "quote": "",
      "source": "request | attachment | customer_profile | history_summary",
      "customer_questions": ""
    }
  ],
  "attachment_readable": true
}

構造化出力を使う理由は、後段で規則を当てるためです。 item_id と status が決まった形で返るので、「この項目が applicable なら顧客に確かめる」「この項目なら所管部署へ」という振り分けを Functions の側で書けます。公式の説明では、すべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する必要があるとされています。引用の無い項目も、空文字で返させます。

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

quote の照合は必ず行います。 原文に無い引用が返ったら、その項目の判定はAIの思い込みかもしれません。照合に落ちた項目は消さず、「引用不一致」の印を付けて担当者に見せます。

システムへ連携する

外為の事務のシステムの送金の状態には触れません。 判定は画面の表示と記録までで、保留や取消の操作は担当者が行います。 自動で保留をかける作りもできますが、誰の判断で止めたのかが記録に残らない形になります。

人が確認する

外為の担当者が全件を確かめます。 開き方を判定で変えます。

1. escalate を先に見る … 当たった項目と引用を読み、所管部署へ回します。回すときは、引用と規則の判定の結果を添えます
2. confirm_with_customer の根拠を確かめる … 引用の箇所を依頼や添付の原文で見て、当てはまりが正しいかを判断します
3. 顧客に確かめるかを決める … 確認事項の案を直し、店舗の担当者か顧客に連絡します。連絡そのものは人が行います
4. standard を一覧で流し見る … 受取人、国、金額、目的を並べて見て、送金の手続きに進めます
5. 判定を覆したら理由を残す … 「過去に同じ取引を確認済み」「顧客情報が古かった」など、選択肢から選びます

4番目を省かないでください。 standard は「確かめる事項が見つからなかった」というだけで、送金してよいという判断ではありません。 外為法上の確認も、いまと同じく担当者が行います。

目標は、1,200件をならして1件3分です。 confirm_with_customer と escalate が2割前後という想定で、それを大きく超える月は、確認基準の判定の材料が曖昧になっているか、顧客情報の更新が遅れています。

例外に対処する

7行目は設計の最初に入れておきます。 判定が出ないことを理由に送金が止まると、顧客の支払が遅れます。判定が出なければ、いまと同じ目視の確認で進められるようにしておきます。

記録を残す

• 判定にかけた依頼の版（依頼番号、訂正の回数、受付の日時）
• 規則で判定した項目の結果と、使った国・地域の区分の版
• Azure OpenAI に渡した入力と、返った JSON の全文
• 使った確認基準の版の番号
• 判定、担当者の確認の結果、覆した理由、顧客への確認の内容と回答
• 所管部署へ回した依頼と、所管部署の判断の結果

確認基準の版を残すのは、基準が直るからです。 検査や監査で「この依頼でなぜ顧客に確かめなかったのか」と聞かれたときに、当時の基準と当時の判定の根拠を並べて示せるようにしておきます。ガイドラインも記録の保存を求める事項に挙げています。

覆した理由の記録は、確認基準を直す材料になります。 同じ項目で「過去に確認済み」が続くなら、その顧客や取引の型について、確認の頻度を変えるかを所管部署が検討する時期です。