3行まとめ
- 金融庁AMLガイドラインには「対応が求められる事項」（最低限）と「対応が期待される事項」（理想）の2段階がある。まず前者を確実にクリアすることが最優先
- 地銀・信金の規模（顧客数十万〜数百万、日次取引数百万件）なら、GPU自前運用は不要。クラウドAI APIの従量課金で十分に対応可能
- 個人名を送信しない匿名化パイプラインを組めば、海外AIサービス（AWS/GCP/Azure）も合法的に活用でき、コストを劇的に下げられる
はじめに
ふくろいAIラボ代表の丸尾です。
先日、あるメガバンク規模のAML（アンチマネーロンダリング）システムの企画書を作る機会があった。さくらインターネットの高火力GPUクラウドを使った構成と、AWS/GCP/Azureを使った構成の2パターン。5年間のTCO（総保有コスト）は8.9億〜13.7億円になった。
メガバンクならこの投資は回収できる。 しかし、地方銀行や信用金庫はどうか。
顧客数が数十万〜数百万人、日次取引が数百万件の金融機関に、億単位のAMLシステムは現実的ではない。しかし、金融庁のガイドラインは規模に関係なく適用される。FATF第5次相互審査（2028年8月予定）も迫っている。
「最低限、何をやれば金融庁に怒られないのか」 ── この問いに答える記事を書いた。
金融庁ガイドラインの2段階構造を理解する
金融庁の「マネー・ローンダリング及びテロ資金供与対策に関するガイドライン」（2026年3月31日最新改正）には、要件が2段階で定義されている。
| 区分 | 意味 | 対応しないと |
|---|---|---|
| 対応が求められる事項 | ミニマムスタンダード（最低基準） | 行政指導・業務改善命令のリスク |
| 対応が期待される事項 | ベストプラクティス（理想像） | すぐに罰則はないが、審査で減点 |
地銀・信金がまずクリアすべきは 「対応が求められる事項」 だ。ここを満たさないと、金融庁検査で指摘を受ける。
取引モニタリングの「対応が求められる事項」
- 疑わしい取引の検知体制の構築 ── 取引モニタリングの仕組みそのものが必要
- リスク評価に基づくシナリオ・閾値の設定 ── 自行のリスクに合ったルールを設計
- シナリオ・閾値の定期的な検証・見直し ── 設定しっぱなしはNG
- STR分析結果のリスク評価への反映 ── 届出データを次のルール改善に使う
一方、「AIや機械学習の活用」は 「対応が期待される事項」 に分類されている。つまり、AIは必須ではない。しかし、2028年のFATF審査を見据えると「やっていない」では心もとない。
ここが設計のポイントになる。 ルールベースで最低基準を確実にクリアしつつ、AIを低コストで追加する構成を考えた。
地銀・信金の規模感
メガバンクと地銀・信金では規模が桁違いに異なる。これがシステム構成に直結する。
| 指標 | メガバンク | 地方銀行（第一地銀） | 信用金庫 |
|---|---|---|---|
| 顧客数 | 約4,000万人 | 数十万〜数百万人 | 数万〜数十万人 |
| 日次取引数 | 約8,000万件 | 数百万件 | 数十万件 |
| ピークTPS | 3,000〜5,000 | 100〜500 | 10〜50 |
| 店舗数 | 500以上 | 50〜200 | 10〜100 |
| AML担当者数 | 100名以上 | 5〜20名 | 1〜5名 |
メガバンクが必要とするH100 GPU 8枚構成は、地銀・信金には明らかにオーバースペック。
信用金庫のピークTPSが50以下なら、普通のCPUサーバー1台で余裕で処理できる。地銀でも、500 TPSならCPU数台で十分だ。
最小構成の設計思想
3つの原則で設計した。
原則1: GPU不要、CPU+クラウドAI APIで構成
地銀・信金のデータ量なら、リアルタイム検出はCPU上のルールエンジン＋LightGBMで十分。詳細分析もクラウドAI APIの従量課金で済む。GPU調達のリードタイムもGPU運用エンジニアの人件費も不要。
原則2: 個人名を外に出さない匿名化パイプライン
海外AIサービスを使うために、全データは匿名化ゲートウェイを通す。
| データ項目 | 処理 | 送信されるデータ |
|---|---|---|
| 顧客名 | 完全除去 | （送信しない） |
| 口座番号 | SHA-256ハッシュ化 | a3f8c2... |
| 住所 | 都道府県に丸め | 静岡県 |
| 生年月日 | 年齢帯に変換 | 30代 |
| 取引金額 | そのまま | 3,500,000円 |
| 取引種別 | そのまま | 海外送金 |
| 宛先国 | そのまま | IRN |
個人情報保護法上の「匿名加工情報」として処理することで、海外AIサービスへの送信が可能になる。金融庁の「外部委託先管理」ガイドラインに基づくDPA（データ処理契約）も併せて締結する。
原則3: 段階導入（3フェーズ）
一度に全部入れない。フェーズごとに効果を確認しながら拡張する。
| フェーズ | 内容 | 期間 | 月額目安 |
|---|---|---|---|
| Phase 1 | ルールエンジン + 制裁リストスクリーニング | 3ヶ月 | 30万円〜 |
| Phase 2 | MLスコアリング + LLM調査支援 | 2ヶ月 | 50万円〜 |
| Phase 3 | グラフ分析 + 行動異常検出 | 2ヶ月 | 80万円〜 |
Phase 1だけで金融庁の「対応が求められる事項」はクリアできる。Phase 2以降は「対応が期待される事項」に踏み込む構成だ。
Phase 1: ルールエンジン（最小構成）
搭載ルール
犯罪収益移転防止法（犯収法）とFATF勧告に基づく10ルールを標準搭載する。
| ID | ルール名 | 根拠 |
|---|---|---|
| R001 | 大口取引検出（1,000万円/5,000万円） | 犯収法施行令 |
| R002 | 現金閾値超過（200万円） | 犯収法第8条（STR報告義務） |
| R003 | 構造化取引（ストラクチャリング） | FATF勧告16 |
| R004 | 高リスク国送金（FATF/外為法） | 外為法、FATF声明 |
| R005 | 短時間多数取引 | ガイドラインII-2(3) |
| R006 | PEP取引 | 犯収法第4条第2項 |
| R007 | 新規口座高額取引 | ガイドラインII-2(3)(ii) |
| R008 | 取引額急変（速度異常） | ガイドラインII-2(3)(ii) |
| R009 | 疑わしい摘要パターン | ガイドラインII-2(3)(iii) |
| R010 | 多数宛先送金 | ガイドラインII-2(3)(ii) |
制裁リストスクリーニング
以下のリストと自動照合する。リスト更新は日次自動取得。
- OFAC SDNリスト（米国財務省）
- EU制裁リスト
- 国連安保理制裁リスト
- 外務省告示（外為法に基づく資産凍結対象）
インフラ構成
┌─────────────────────────────────────────┐
│ 国内クラウド（AWS東京 or さくら） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ FastAPI │→│ ルール │→│ Alert │ │
│ │ API │ │ エンジン │ │ DB │ │
│ └──────────┘ └──────────┘ └────────┘ │
│ ↑ ↑ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 勘定系 │ │ 制裁 │ │
│ │ 連携 │ │ リスト │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────┘
これだけでPhase 1は動く。 GPUもKafkaもRedisも不要。PostgreSQL 1台 + APIサーバー 1台の最小構成。
Phase 1の月額コスト内訳
| 項目 | サービス | 月額 |
|---|---|---|
| APIサーバー | AWS t3.xlarge or さくらクラウド | 3万円 |
| DB | RDS PostgreSQL db.t3.large | 5万円 |
| 制裁リスト更新 | 自動取得バッチ | 0円（自前） |
| 監視 | CloudWatch or Grafana | 2万円 |
| バックアップ | S3 + スナップショット | 1万円 |
| 月額合計 | 約11万円 |
インフラだけなら月額11万円。これに初期の開発費（後述）が加わる。
Phase 2: AI追加（MLスコアリング + LLM）
Phase 1のルールエンジンだけだと、偽陽性（正常取引がアラート化する）が多くなる。ここにMLモデルとLLMを加えて精度を上げる。
MLスコアリング（LightGBM）
- 過去のSTRデータを教師データとして学習
- CPU上でONNX Runtime推論（1件あたり1ms以下）
- ルールスコアとMLスコアを統合して最終判定
追加コスト: ほぼゼロ。 同じAPIサーバー上で動作する。
LLM調査支援
ここが最大の差別化ポイント。
| 機能 | 使用AI | 送信データ | 効果 |
|---|---|---|---|
| アラート分析 | GPT-4o (Azure) | 匿名化済み取引サマリー | 調査観点を自動提案 |
| SAR下書き | Claude API | 匿名化済み検出結果 | 作成時間を75%短縮 |
| 類似事例検索 | Embedding検索 | 過去アラートのベクトル | 判断の一貫性向上 |
LLMに個人名は渡さない。 「30代男性、静岡県、口座開設3ヶ月、24時間以内に190万円x3回の現金入金」── このレベルの匿名化済みサマリーだけで、LLMは十分に有用な分析を出せる。
Phase 2の追加コスト
| 項目 | 月額 |
|---|---|
| Azure OpenAI (GPT-4o) | 10〜20万円（従量課金） |
| Anthropic Claude API | 5〜10万円（従量課金） |
| Embedding DB (pgvector) | 0円（既存DBに追加） |
| 追加合計 | 15〜30万円 |
Phase 1 + 2 = 月額約30〜40万円。
Phase 3: 高度分析（必要に応じて）
FATF審査対策として「先進的な分析手法を導入している」とアピールするためのフェーズ。
- グラフ分析: 取引ネットワークの循環送金・レイヤリング検出（GCP Vertex AI）
- 行動異常検出: Autoencoder による顧客行動の逸脱検出（AWS SageMaker）
Phase 3はFATF審査の1年前に導入すれば間に合う。焦る必要はない。
Phase 3追加コスト: 月額30〜50万円。 全フェーズ合計で月額60〜90万円。
費用サマリー: メガバンク vs 地銀 vs 信金
| メガバンク | 地銀 | 信金 | |
|---|---|---|---|
| 初期開発費 | 1.0〜1.4億円 | 1,500〜3,000万円 | 500〜1,000万円 |
| 月額インフラ | 300〜1,400万円 | 30〜90万円 | 11〜40万円 |
| 年間運用費 | 5,500万〜8,300万円 | 800〜1,500万円 | 300〜600万円 |
| 開発期間 | 11〜14ヶ月 | 4〜7ヶ月 | 3〜5ヶ月 |
| 必要体制 | 14〜17名 | 3〜5名 | 1〜2名 |
信金なら初期500万円、月額11万円から始められる。 これは「AML対応をやらない」という選択肢がなくなる価格帯だ。
なぜ今やるべきか
1. 2028年FATF第5次相互審査
2024年10月に第4次審査のフォローアップが完了し、次は2028年8月の第5次審査。金融庁は2024-2026年度の行動計画を策定しており、全金融機関に対してAML態勢の底上げを求めている。
2. 2026年3月のガイドライン改正
2026年3月31日施行の最新改正で、外部委託先の態勢検証の義務化、預貯金口座の不正利用防止対策の強化が盛り込まれた。ルールを作っただけでは不十分で、「検証・見直し」のサイクルが明確に求められるようになった。
3. 地銀・信金のAML対応は遅れている
メガバンクはSIerに億単位を投じてAMLシステムを構築済み。一方、地銀・信金はExcelベースの手作業か、高額なパッケージソフトの導入に苦しんでいる。この間を埋めるのが、クラウドAI APIを活用した軽量AMLシステムだ。
まとめ
金融庁ガイドライン準拠のAMLシステムは、地銀・信金でも現実的なコストで構築できる。
- Phase 1（月額11万円〜）: ルールエンジン + 制裁リストスクリーニングで最低基準クリア
- Phase 2（月額30万円〜）: MLスコアリング + LLM調査支援で偽陽性削減・SAR自動化
- Phase 3（月額60万円〜）: グラフ分析 + 行動異常検出でFATF審査対策
「高すぎて手が出ない」は、もう言い訳にならない。
ふくろいAIラボでは、この構成をベースにした地銀・信金向けAMLシステムの設計・開発支援を行っています。PoC（概念実証）のご相談も受け付けていますので、お気軽にお問い合わせください。
本記事で紹介した費用は概算であり、実際の導入費用は金融機関の規模・既存システムの状態・要件により変動します。
筆者はCAMS（公認AMLスペシャリスト）等のAML関連資格を保有しておりません。本記事の情報は金融庁公開資料およびAIによる調査・分析をもとに構成しています。実際の導入にあたっては、AML専門家や法務担当者への確認を推奨します。