取引モニタリングが検知した取引のアラートについて、取引履歴・顧客情報・過去の判断記録から確認の論点と検討メモの下書きを作る

処理の起点を決める

案件管理の台帳にアラートが登録されたことを起点にします。 取引モニタリングのシステムは夜間にまとめてアラートを出すので、登録も朝までにまとまって入ります。1件ずつ処理を動かし、担当者が出社した時点で、前日分のアラートに下書きが付いている状態を目標にします。

制裁対象の照合（取引フィルタリング）で止まった取引は対象にしません。 ガイドラインは取引モニタリングと取引フィルタリングを別の項目として扱っており、フィルタリングで当たったものは制裁リストとの照合を遅滞なく行う別の手順になります。アラートの種類が取引フィルタリングのものは、下書きを作らずに担当者へ回します。

入力データを集める

質を決めるのは、顧客情報の「取引を行う目的」と「申告された取引の規模」です。 ガイドラインが「顧客属性・事業に照らした取引金額・回数等の取引態様」を考慮するよう求めているのは、取引そのものではなく、申告との差を見よということです。この2つが空欄の顧客では、AIは差を示せません。空欄であること自体を確認が要る点として出させます。

シナリオの説明書きは、この構成で新しく作るものです。 「なぜこのアラートが出たのか」を担当者は頭の中で知っていますが、AIは知りません。シナリオごとに数行で、検知したいものと、誤検知になりやすい典型（給与の振込口座の変更、法人の決算期の資金移動など）を書いておきます。

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

顧客の照合は、必ず顧客番号で行います。 名前で引くと、同姓同名や法人の旧商号で別の顧客の記録を混ぜます。別人の過去の判断が混ざった検討メモは、それだけで使えなくなります。

過去の判断は直近5件までに絞り、それを超える顧客は件数だけを別に渡します。

AIへ渡す前に整形する

1. 取引の集計 … 相手先ごと、月ごと、取引の種類ごとに件数と金額を出します。検知された取引の前30日と前々30日の比較も出します
2. 申告との比較の材料 … 申告された取引の規模と、実際の月平均の件数・金額を並べます。差を割合で出します
3. 国・地域の整理 … 相手先の国・地域ごとに件数と金額を出します。国の名前は、取引データに入っている値をそのまま使います
4. 符号化 … 顧客名、口座番号、相手先の個人名を、「顧客A」「相手先03」のような内部の符号に置き換えます。対応表は Azure Functions の側だけに置き、AIには渡しません
5. 取引番号の付与 … 集計に使った取引に通し番号を振り、AIが根拠として挙げられるようにします
6. 欠けている項目の印 … 顧客情報で空欄の項目と、取引時確認から長く経っているものに印を付けます

1番目と2番目が、担当者がいちばん時間を使っていた作業です。 これをプログラムで済ませておけば、AIが計算を間違える余地がなくなり、担当者は同じ表を毎回作らなくて済みます。

4番目では、相手先の法人名は業種を読み取る手がかりなので残し、個人名だけを符号に置き換える、という線引きが現実的です。最終的には自社の情報管理の規程に合わせて決めてください。

AIに処理させる

させるのは、6つの要素ごとに「データから言える事実」「申告や過去との違い」「確認が要る点」を書き分け、それを検討メモの下書きにまとめることです。 6つの要素は、ガイドラインが疑わしい取引の該当性で考慮するよう求めている事情を並べたものです。

要素ごとに「事実」「違い」「確認が要る点」を分けるのが、この構成の中心です。 事実は取引番号や顧客情報の項目を根拠にできるもの、違いは申告や前回との比較、確認が要る点はデータからは分からないので人が調べるものです。3つを混ぜると、AIの推測が事実の顔をして並びます。

3行目が最も起きやすい失敗です。 生成AIは、取引の並びから「事業の仕入れの支払と考えられる」のような説明を作るのが得意です。その説明が正しいかどうかは、営業店に照会しないと分かりません。 推測が書かれた下書きを読むと、担当者は確かめずにその理由でクローズにしたくなります。

指示内容を固定する

あなたは銀行のマネロン対策室で、取引モニタリングのアラートの一次調査を補助する立場です。
渡されたデータだけを使い、担当者が疑わしい取引の該当性を判断するための材料を整理してください。
判断はしません。

【整理する6つの要素】
1. 外国PEPs該当性
2. 顧客属性（個人・法人、職業、口座開設日、顧客リスク評価）
3. 事業（申告された事業の内容と取引の目的）
4. 属性・事業に照らした取引態様（件数・金額、申告された規模との差、前後30日の変化）
5. 取引に係る国・地域
6. その他の事情（過去の判断との違い、シナリオの誤検知の典型に当たるか）

【要素ごとに書くこと】
- facts ......... データから言えること。必ず根拠（取引番号または顧客情報の項目名）を付ける
- differences ... 申告された内容や過去の判断との違い。比較の相手を明記する
- open_points ... データからは分からず、人が確かめる必要があること

【厳守事項】
- 疑わしいかどうか、届出が必要かどうかを書かないでください。
  「疑わしい」「問題ない」「クローズが妥当」などの評価の言葉を使わないでください。
- 取引の目的や背景を推測しないでください。データに書かれていない理由は、
  facts にも differences にも書かず、open_points に「確認が要る」として書いてください。
- 件数・金額・割合は、渡された集計結果の値をそのまま使ってください。
  自分で足し算や割り算をしないでください。
- 顧客情報で空欄の項目は「記載なし」とし、open_points に挙げてください。
  他の項目から補わないでください。
- 根拠のない facts を書かないでください。根拠を示せないものは書かないでください。
- 顧客や営業店に送る文面は作らないでください。確かめる項目だけを挙げてください。
- 符号（顧客A、相手先03 など）はそのまま使い、元の名前を推測しないでください。
- memo_draft は、6つの要素の順に、事実・違い・確認が要る点をまとめた文章にしてください。
  末尾の「結論」と「理由」は空欄のまま残してください。

【アラート】{alert}
【シナリオの説明書き】{scenario_note}
【取引の集計結果】{txn_summary}
【顧客情報】{customer_profile}
【同じ顧客の過去の判断（直近5件まで）】{past_dispositions}

「評価の言葉を使わない」を例示つきで書くのは、書かないと必ず出てくるからです。 「総合的に見て疑わしい点は少ない」のような一文が、下書きの最後に付け加えられます。担当者がその一文に引きずられないよう、言葉の段階で止めます。

「推測しない」と「open_points に回す」をセットで書くのも同じ理由です。 推測を禁じるだけだと、その項目が黙って消えます。消えるのではなく、確認が要る点として残すように指示すると、担当者が次に何を調べればよいかが下書きに出てきます。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONを受け取ります。 構造化出力は、API呼び出しのときに渡したJSON Schemaの定義にモデルを従わせる機能で、Chat Completions API では response_format、Responses API では text.format にスキーマを置きます。

{
  "alert_id": "",
  "scenario_id": "",
  "factors": [
    {
      "factor": "foreign_peps | customer_attribute | business | transaction_pattern | country_region | other",
      "facts": [ { "text": "", "evidence": [""] } ],
      "differences": [ { "text": "", "compared_with": "declared | past_disposition | previous_30_days" } ],
      "open_points": [""]
    }
  ],
  "missing_profile_items": [""],
  "past_dispositions_used": [""],
  "memo_draft": "",
  "conclusion": "",
  "reason": ""
}

1つ目の理由は、conclusion と reason を空欄のまま型で持てることです。 欄があるので、人が書き込む場所が決まります。Functions の側で、AIの応答のこの2つが空でなければ下書きを破棄して作り直します。 評価の言葉が紛れ込んだかどうかを、人が読む前に機械で止められます。

2つ目は、evidence を照合できることです。 facts の根拠に挙げられた取引番号と顧客情報の項目名が、前処理で渡したものの中にあるかを機械的に確かめます。存在しない取引番号を挙げた下書きは、担当者に渡しません。

スキーマの書き方には、Azure の決まりがあります。 Microsoft Learn によると、構造化出力ではすべての項目を required に入れる必要があり、任意にしたい項目は null との共用型で表します。オブジェクトには必ず additionalProperties: false を付けます。オブジェクトの項目は全体で100個まで、入れ子は5段までです。文字列の maxLength や pattern、配列の minItems などは使えないとされているので、件数や長さの制限はスキーマではなく Functions の側で確かめます。

システムへ連携する

案件管理の台帳へは、下書きを添付するだけです。 区分の欄や結論の欄には書き込みません。台帳上の区分を変えられるのは担当者と室長だけにしておきます。

顧客管理のシステムには書き込みません。 顧客リスク評価を見直すべきだと担当者が判断した場合も、その更新は既存の手順で人が行います。ガイドラインは、届出を契機にリスクが高いと判断した顧客について顧客リスク評価を見直すことを求めていますが、見直すかどうかの判断と更新は、この構成の外に置きます。

人が確認する

下書きが付いたアラートも、全件を担当者が開きます。 疑わしい取引の該当性の判断は、犯収法上の義務として特定事業者が行うものです。AIの下書きだけでクローズにする経路は作りません。

1. 数字と根拠を確かめる … facts の数字が集計表と合っているか、根拠の取引番号を開いて確かめます。照合で不一致が出たものは、下書きを使わずに最初から調べます
2. 確認が要る点を調べる … open_points に挙がったものを、営業店への照会や追加の資料で確かめます
3. 結論と理由を書く … 区分を選び、理由を自分の言葉で書きます。下書きの文章をそのまま理由に写さないことを運用のルールにします
4. 室長が確かめる … 届出の検討に回すもの、継続監視にするもの、クローズのうち抜き取りで選んだもの

3番目を省かないでください。 下書きは材料の整理であって、判断の理由ではありません。理由欄に下書きを貼ると、後から読んだ人には、誰が何を確かめて判断したのかが分からなくなります。

営業店への照会では、届出を検討していることを伝えない言い方にします。 犯収法第8条第4項は、特定事業者（役員と使用人を含む）が疑わしい取引の届出を行おうとすることや行ったことを、その届出に係る顧客等やその関係者に漏らしてはならないと定めています。営業店から顧客へ確認する場面を見越して、照会の書き方は室で決めておきます。

例外に対処する

ガードレールの行は、マネロン対策ならではです。 Microsoft Learn のページによると、プロンプトと応答は有害な内容の種類についてリアルタイムで評価され、設定した基準に基づいてフィルターされます。犯罪の収益や不正利用に関わる文章を扱うので、設定によっては応答が止まることがあります。 止まったときは下書きなしで人が調べ、どのアラートで止まったかを記録して、設定の見直しの材料にします。

記録を残す

• アラート番号と、下書きを作ったときに渡した入力の写し（集計結果、顧客情報、過去の判断、シナリオの説明書き）
• 使ったデプロイの名前とモデルのバージョン、指示文の版
• AIの応答の全文と、数値・根拠の照合の結果
• 担当者が書いた結論と理由、下書きから直した箇所
• 室長の確認の記録
• シナリオごとの、クローズ・継続監視・届出の検討の件数

1行目で入力の写しを残すのは、顧客情報が後から変わるためです。 取引時確認をやり直すと、取引の目的や申告された規模が書き換わります。当時の下書きが何を見て作られたのかを、後から再現できなければなりません。 ガイドラインも、取引記録などの記録の保存を、届出の要否の判断に必須の情報として位置付けています。

最後の行は、シナリオの見直しの材料になります。 ガイドラインは、検知結果や届出の状況を踏まえて、シナリオ・敷居値等の有効性を分析し改善を図ることを求めています。クローズばかりが続くシナリオと、その理由の傾向が、下書きと判断の記録から集計できます。