暗号資産交換業者のAML担当が、入出庫のモニタリングのアラートを Azure OpenAI でブロックチェーン分析の結果・アクセスの記録・顧客の申告と突き合わせ、疑わしい取引の届出の要否を検討するメモの下書きを作る

処理の起点を決める

案件管理の台帳に新しいアラートが登録されたことを起点にします。 取引モニタリングは前日の取引を夜間に流してアラートを出すことが多いので、朝の始業前に下書きがそろうよう、夜間にまとめて処理します。 ブロックチェーン分析のツールが入出庫のたびにアラートを上げる場合は、15分ごとに台帳を見て処理します。

同じ顧客に複数のアラートが同じ日に上がったときは、1つの検討メモにまとめます。 入庫のアラートと、その直後の出庫のアラートを別々に調べると、入庫直後の出庫という、参考事例でいちばん大事な形が見えなくなります。

出庫を止めて調査するアラートは、夜間を待たずにすぐ処理します。 出庫の保留をどこまで続けるかは顧客の不利益にもつながるので、下書きを早く出して担当者の判断を速くします。

入力データを集める

通知の内容は、犯収法が暗号資産交換業者に課している通知の義務に関わるものです。 犯収法は、顧客の依頼で受取顧客に暗号資産を移転するとき、依頼した顧客と受取顧客の本人特定事項などを、受取側の交換業者に通知して行うよう定めています。出庫先の受取人の情報が申告や過去の取引と合っているかは、検討の大事な材料になります。

参考事例の一覧は、更新の日付付きで持ちます。 参考事例は改訂されることがあり、どの版の項目番号でメモを書いたかが分からないと、後から読み返せません。

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

1. 台帳からアラートを取る … 顧客番号、アラートの日時、対象の取引の番号を取ります
2. 取引の履歴を取る … 取引モニタリングのシステムから、前後3か月の入出金・売買・入出庫を取ります
3. ブロックチェーン分析の結果を取る … 対象のアドレスごとに、ツールのAPIか書き出しで区分と経路を取ります
4. アクセスの記録を取る … 同じ期間のログインの記録を、IPアドレスの国と端末の識別に絞って取ります
5. 通知の内容と過去の判断を取る … 対象の入出庫に紐づく通知の記録と、同じ顧客・アドレスの過去の判断を取ります

3番目は、ツールが返す区分の名前をそのまま持ちます。 ツールによって区分の名前と基準が違います。AIに渡すときも、ツールが付けた区分を言い換えずに渡し、区分の意味の一覧を添えます。

4番目でIPアドレスの元の値をAIに渡しません。 国と、同じIPアドレスを他の顧客が使っていないかの照合結果だけを渡します。照合はプログラムで行います。

集める期間は、アラートの日時の前後3か月を基本にし、口座開設から3か月以内の顧客は開設の日からにします。 参考事例には、開設後の短期間に多額・頻繁な入出金や入出庫があり、その後に解約したアカウントの取引が挙がっています。開設直後の動きは、期間を切ると見えなくなります。 取れなかったシステムがあれば、その名前を材料の冒頭に書き、AIにも「この材料は無い」と伝えます。

AIへ渡す前に整形する

1. 時系列の作成 … 円の入出金、売買、暗号資産の入出庫、ログインを、時刻の順に1本に並べ、各行に事実の番号（E001、E002…）を振ります
2. 集計 … 期間ごとの入出金の合計、入庫から出庫までの時間、出庫先のアドレスの数などを計算します
3. 申告との比較の材料 … 申告の収入・資産の区分と、期間の入金の合計を並べます。比べるのはプログラムではなく担当者ですが、並べるのはプログラムです
4. 記号化 … 氏名・住所・連絡先を記号に置き換えます。アドレスは「アドレスA」と置き換え、ツールの区分だけを添えます
5. アクセス環境の照合 … 同じIPアドレス・端末から他の顧客がアクセスしていないかを照合し、結果だけを持ちます
6. 過去の判断の要約 … 過去のアラートの結論と理由を、日付付きの短い一覧にします

1番目の事実の番号が、この構成の土台です。 AIは根拠を「E014、E015」のように番号で返し、プログラムはその番号が時系列に実在するかを確かめます。AIが事実を作っても、番号の照合で必ず見つかります。

時刻は、すべて日本時間にそろえてから並べます。 ブロックチェーン上の記録や海外の交換業者からの通知は協定世界時で届くことがあり、そろえないと入庫と出庫の順が入れ替わります。 元の時刻と変換後の時刻は両方とも持ちます。

AIに処理させる

いちばん効くのは、表の2行目「当たらない項目の理由」です。 当たる項目だけを書かせると、メモはいつも「当たる」方向に偏ります。当たらないと見た理由も残すと、クローズにした判断を後から説明できます。

指示内容を固定する

あなたは暗号資産交換業者のマネロン・テロ資金供与対策の担当を補助し、
アラートの検討メモの下書きを作ります。結論は書きません。

【渡すもの】
- アラートの内容
- 時系列（各行に事実の番号 E001… が付いています）と集計の結果
- 取引時確認で受けた申告
- ブロックチェーン分析のツールが付けたアドレスの区分と、その意味の一覧
- 通知の内容、過去の判断の一覧
- 金融庁「疑わしい取引の参考事例（暗号資産交換業者）」の項目一覧（版の日付付き）

【させること】
1. 項目一覧の各項目について、当たりうる事実があれば reference_matches に挙げ、
   事実の番号を evidence_ids に入れ、理由を1〜2文で書いてください。
2. アラートのシナリオに関係する項目で当たらないと見たものは、
   not_matched に理由を1行で書いてください。
3. 申告と取引の規模・頻度・相手の種類が合わない点を declaration_gaps に
   挙げてください。
4. 判断に要るのに材料に無いことを open_questions に挙げ、
   社内で確かめる記録か、顧客に求める資料の候補を書いてください。

【厳守事項】
- 疑わしい取引に当たるか、届出が要るかを書かないでください。
- 根拠は必ず事実の番号で示してください。番号の無い事実を作らないでください。
- アドレスの持ち主や資金の出所を推測しないでください。分からなければ
  open_questions に入れてください。
- 居住の国やIPアドレスの国だけを理由に項目に当てはめないでください。
  申告や過去のアクセスとの違いがあるときだけ挙げてください。
- ツールの区分の名前を言い換えないでください。
- 顧客あての文章を書かないでください。

【参考事例の版】{reference_version}
【アラート】{alert}
【時系列と集計】{timeline}
【申告】{declaration}
【アドレスの区分】{address_risk}
【通知の内容】{transfer_notice}
【過去の判断】{past_decisions}

「居住の国やIPアドレスの国だけを理由に当てはめない」を入れるのは、参考事例の書き方に合わせるためです。 参考事例の項目は「国外であることに合理性が認められない」場合を挙げていて、国外であること自体ではありません。入れないと、海外出張の多い顧客のアラートが毎回同じ項目に当てはめられます。

出力形式を固定する

{
  "alert_ids": [""],
  "reference_version": "2025-08-01",
  "reference_matches": [
    { "item": "第4-(23)", "evidence_ids": ["E014", "E015"], "reason": "" }
  ],
  "not_matched": [
    { "item": "第2-(11)", "reason": "" }
  ],
  "declaration_gaps": [
    { "declared": "", "observed": "", "evidence_ids": [""] }
  ],
  "open_questions": [
    { "question": "", "how_to_check": "internal_record | customer_document", "detail": "" }
  ],
  "relation_to_past": "same_pattern | new_pattern | no_history"
}

1つ目の理由は、evidence_ids をプログラムで照合できることです。 番号が時系列に無ければ、その対応を「根拠なし」として表示し、メモの本文から外します。

2つ目は、結論の欄が無いことです。 スキーマに結論の欄を作らなければ、AIは結論を書けません。メモの結論欄は、プログラムが空欄で作り、担当者だけが書きます。

3つ目は、検討メモの形を毎回そろえられることです。 担当者が書くメモは、次の形の下書きになります。

【アラート】出庫 2件（シナリオ：入庫後短時間の出庫）
【時系列の要点】E012 円入金 → E014 購入 → E015 出庫（入金から38分）
【参考事例との対応】第4-(23)：E015 の出庫先がツールの区分「オンラインカジノ」
【当たらないと見た項目】第2-(11)：入庫元・出庫先に追跡を困難にするツールの区分なし
【申告との違い】申告「会社員・投資目的」に対し、30日で入出庫が往復12回
【未確認の事項】出庫先の受取人の通知の内容が申告の相手と合うか
【結論】（担当者が記入）

システムへ連携する

どのシステムにも、判断の結果を書き込みません。 出庫の保留や口座の制限、届出の操作は、すべて担当者と所管の部署が既存の手順で行います。

下書きのメモは、マネロン対策のグループだけが見られる場所に置きます。 犯収法は、疑わしい取引の届出を行おうとすること又は行ったことを、その顧客や関係者に漏らしてはならないと定めています。カスタマーサポートの画面から見える場所には置きません。

人が確認する

1. 根拠の事実を元の画面で確かめる … evidence_ids の事実を、取引モニタリングやブロックチェーン分析のツールの画面で確かめます
2. 未確認の事項のうち必要なものを確かめる … 社内の記録で分かるものは確かめ、顧客に資料を求めるものは、届出の検討を顧客に悟らせない聞き方を所管の部署と決めた手順で行います
3. 結論を書く … クローズか届出の検討かと、その理由を書きます。参考事例との対応は材料で、結論は顧客の属性・取引時の状況など全体を勘案して担当者が出します
4. 上長が確かめる … 結論と理由が材料と合っているかを見ます

3番目で、AIが挙げた対応をそのまま結論の理由にしないでください。 参考事例は、個別の取引が疑わしい取引に当たるかは、顧客の属性、取引時の状況その他の具体的な情報を総合的に勘案して判断する必要があるとしています。

目標は、450件をならして1件12分です。 対応の項目が無く、過去と同じ形のアラートは数分、未確認の事項の多いアラートは30分以上かかります。

経験の浅い担当者には、最初の1か月は上長が全件の結論を見る運用にします。 下書きの形がそろうと、経験の浅い担当者でも材料は早く読めますが、どの未確認の事項を確かめずに済ませてよいかの勘所は、メモの形だけでは身に付きません。 上長が直した箇所を担当者に返すと、その差が教材になります。

例外に対処する

| 出庫を保留したまま判断が遅れる | 保留中のアラートを台帳で別に数え、期限を決めて上長に上げる |

| 公的機関から照会があった顧客 | 照会の有無だけを材料に入れ、照会の中身はAIに渡さない |

1行目がいちばん起きやすい見落としです。 ツールが対応していない銘柄やチェーンでは区分が空になりますが、空は「分からない」で、「問題ない」ではありません。

最後の行の照会の中身を渡さないのは、扱える人を絞るためです。 捜査機関などからの照会の内容は、社内でも知る人を限っている情報です。参考事例には、公的機関など外部から犯罪収益に関係している可能性があるとして照会や通報があった取引が挙がっているので、「照会あり」という事実だけを時系列に入れれば、対応づけには足ります。

記録を残す

• 集めた材料の全文（記号化の前後）と、記号の対応表
• AIの出力のJSONと、根拠の番号の照合結果
• 使った参考事例の一覧の版
• 担当者が書いた結論と理由、確かめた未確認の事項
• 上長の確認と、所管の部署への引き継ぎの記録

参考事例の版を残すのは、改訂の後に過去のメモを読み返すためです。 項目番号は改訂で変わることがあります。

not_matched の理由と、担当者がクローズにした理由は、別々に残します。 AIが当たらないと見た項目を担当者が「当たる」と判断し直したなら、その差が、指示や区分の一覧を直す材料になります。月に一度、AIの対応づけと担当者の結論が分かれたアラートを並べて見ると、どの項目の当てはめが苦手かが分かります。 シナリオごとのクローズの割合も、ここから数えられます。