ブロックチェーンAMLの基礎 — 資金決済法・犯収法・FATFトラベルルールを一度に理解する

2025年〜2026年は、日本の暗号資産・ステーブルコイン事業者にとってAML（Anti-Money Laundering、アンチ・マネーロンダリング）対応が一気に本格化する年になりました。JPYCが金融庁承認の国内初の円建てステーブルコインとして稼働を始め、規制側でも暗号資産関連の制度対応が一段と進んでいます。

この記事では、ブロックチェーン領域でAMLに向き合う際に最初に押さえるべき 3つの法令・基準 と、それらがどう技術実装に落ちるかを整理します。

• 資金決済に関する法律（資金決済法、PFMSA）
• 犯罪による収益の移転防止に関する法律（犯収法、APTCP）
• FATF勧告16号「トラベルルール」

技術的な視点で、具体的な検知ロジックの例やクエリまで落とし込んでいきます。

TL;DR

法令・基準	対象	実装で押さえる点
資金決済法	暗号資産交換業者・電子決済手段等取扱業者	登録、KYC、分別管理、情報セキュリティ（FISC 準拠）
犯収法	特定事業者（上記含む）	取引時確認、記録7年保存、疑わしい取引の届出、トラベルルール
FATF トラベルルール	VASP 間送金	当プラットフォームでは$1,000超の送金で送金者・受取者情報を受取側VASPに共有

実装上のコア要件は次の3つ:

1. 受取アドレスのリスク評価: OFAC SDN・ダークネット市場・ミキサー・スキャム DB・グラフ近接度の合算判定
2. 閾値検知: 送金時に通貨別に $1,000 相当を自動判定、オーバーしたらトラベルルール対応を発火
3. 証跡保全: 検知の根拠と判定時刻を改竄不能な形で保存（監査対応）

1. 資金決済法（PFMSA）が求めること

資金決済法は、第二章の二「暗号資産」、第二章の三「電子決済手段」で、暗号資産交換業・電子決済手段等取扱業者を登録制にしています。

登録事業者に課される主な実務義務は次の通り:

• 金融庁・財務局への定期報告
• 取引時確認（本人確認 + 実質的支配者確認）
• 顧客財産の分別管理（信託等）
• 情報セキュリティ体制の整備（FISC 安全対策基準の準用）

2023年の改正で、電子決済手段（ステーブルコイン）が明確に規制対象となりました。JPYC のような日本円建てステーブルコインの発行・取扱いには、電子決済手段等取扱業者としての登録が必要です。

技術的な意味合い:

FISC 安全対策基準はクラウド・暗号化・アクセス制御・監査ログなど、Web アプリケーション開発者にとって馴染みのある統制要件と大きく一致します。押さえるべきは:

• データレジデンシー: 日本国内リージョンへの配置（AWS Tokyo、Azure Japan East、GCP Tokyo）
• 暗号化: 転送時TLS、保存時 AES-256
• アクセス制御: RBAC + MFA + 監査ログ（tamper-evident であることが望ましい）
• バックアップ: 定期バックアップ + 復旧手順テスト
• 外部セキュリティ監査: 年次の脆弱性診断・ペネトレーションテスト

2. 犯収法が求めること

犯収法では、特定事業者（暗号資産交換業者および電子決済手段等取扱業者を含む）に以下を義務付けます:

• 取引時確認（KYC: eKYC、本人確認、実質的支配者）
• 確認記録・取引記録の 7年間保存
• 疑わしい取引の届出（国家公安委員会）
• FATF 勧告16号 = トラベルルール対応

2024年6月の改正犯収法施行で、VASP 間送金時の「通知義務」と取引関係の継続性確認が本格運用されました。取引時確認 → 取引記録保管 → 疑わしい取引の届出 までが一気通貫で監査対象になります。

疑わしい取引の例

犯収法ガイドラインで明示されている代表的なパターン:

• 短時間での高額送金の繰り返し
• 明らかに取引実態に合わない大口送金
• 制裁対象・犯罪捜査対象アドレスとの取引
• ミキサー（Tornado Cash 等）の利用
• アドレスポイズニングの疑い（極小額 + アドレス類似偽装）
• Peel Chain（小分け送金）による資金洗浄

これらは全て オンチェーン データ と 外部 OSINT の組み合わせで機械検知できます。

Neo4j を使った検知例

たとえば、監視対象アドレス addr が、2ホップ以内にダークネット市場 or ミキサー ラベルのアドレスに到達するかどうか:

MATCH (target:Address {address: $addr})-[:TX*1..2]-(neighbor:Address)
WHERE neighbor.category IN ['darknet_market', 'mixing', 'sanctioned_entity']
RETURN DISTINCT neighbor.address, neighbor.category, neighbor.label
LIMIT 20

address.category のラベル付けは、OFAC SDN リストや、ダークネット市場のアドレス公開データセット（WalletExplorer、Chainabuse 等）から一括インポートしておきます。

OFAC 制裁照合

OFAC SDN リストは毎週更新される XML / CSV を配布しています。暗号資産アドレスだけ抜き出して PostgreSQL なり Redis なりに索引化し、受取アドレスに対して O(1) で照合 するのが定番です。

# 疑似コード
def is_sanctioned(address: str) -> bool:
    return address.lower() in OFAC_SDN_CRYPTO_ADDRESSES

取引時確認レベルでは、送金元 / 受取先それぞれを SDN チェックし、CRITICAL と判定したら送金自体を差し止めます。

3. FATF トラベルルール

FATF 勧告16号「電信送金」は、VASP 間の送金時に送金者・受取者情報を共有する義務を定めています。日本では 2023年6月の改正犯収法で閾値が ¥10万超 と明記されました。

送信すべき情報（Originator Info / Beneficiary Info）:

• 送金者の氏名、住所、本人確認番号（生年月日でも可）
• 受取者の氏名、住所（取引所口座であれば同定子）

これを IVMS 101 というメッセージフォーマットに載せて、受取側 VASP へ送ります。実装では、Sumsub、Notabene、TRP、Veriscope などのトラベルルール プロトコルを介するのが一般的です。

しきい値検知の実装

送金量を USD 相当に換算し、閾値判定を行います。

# 擬似コード
async def should_trigger_travel_rule(
    amount: float, token_symbol: str, chain: str,
) -> bool:
    usd_value = await price_oracle.to_usd(amount, token_symbol, chain)
    return usd_value is not None and usd_value > 1000.0

注意点:

• 価格オラクルのキャッシュ TTL を適切に（10分前後）
• JPYC のような通貨ペッグ型 SC は固定レート（JPY/USD）で換算
• 小額分散送金（ストラクチャリング）にも気を配る必要あり（24時間合算で閾値判定）

4. 共通の技術スタック

日本の暗号資産 AML を実装する上で、コア技術スタックはだいたい次のようになります。

レイヤー	技術
オンチェーン データ取得	Etherscan V2 API、Routescan、Blockstream、Helius、Solana RPC
グラフ分析	Neo4j（BFS・パス探索・コミュニティ検出）
ML 異常検知	Isolation Forest、AutoEncoder、GraphSAGE（GNN）
外部 OSINT	OFAC SDN、ChainAbuse、GoPlus Security、Reddit
価格オラクル	CoinGecko、Jupiter Ultra（Solana）、DeFi プール
トラベルルール連携	Sumsub、Notabene、TRP、Veriscope
ストレージ	PostgreSQL（KYC 記録）、Neo4j（グラフ）、S3 / Azure Blob（証跡）
ホスティング	Azure Japan East / AWS Tokyo / GCP Tokyo（FISC 準拠のデータレジデンシー）

5. 実務的なアーキテクチャ例

典型的な B2B 暗号資産送金サービスの AML パイプライン:

各ステップは並列化できます。典型的な応答時間目標は 500ms 以下（UX の観点から）。

リスクレベル判定のロジック

Detector の検知結果を減点方式で集計するのが一般的:

UI に出すスコアは 100 - 内部スコア に反転して「高いほど危険」の直感に合わせると、エンドユーザーの認知負荷が下がります。

6. ありがちな落とし穴

実装していてハマりやすい箇所:

1. アドレスの正規化: EVM はチェックサム大文字小文字混在問題、Bitcoin は P2PKH / P2SH / Bech32 の形式差、Solana は Base58 の大文字小文字区別。必ず比較前に正規化する
2. OFAC SDN の更新頻度: OFAC は毎週水曜に更新されることが多い。週次の自動取込バッチ必須
3. トラベルルールの閾値計算: 価格オラクルのレートで判定するが、送金実行の瞬間のレート と 受取瞬間のレート にずれがある。どちらを取るかは仕様で明確化
4. ブリッジ経由の資金移動: 同一エンティティがチェーンを跨いでも、オンチェーン上は別アドレス。ブリッジ イベントのインデックスを別途持つと辿りやすい
5. ガス節約アドレスポイズニング: CRITICAL として扱うが、誤検知（legitimate airdrop 等）も発生するので 金額 × 類似度 × 送信頻度 で信頼度スコアを併記

7. 国産ツールという選択肢

日本の暗号資産 AML 分野は、Chainalysis・Elliptic・TRM Labs といった海外大手が圧倒的なシェアを占めています。JPYC も Elliptic と提携してAML体制を整備しています。

ただし、中小規模の事業者・ユースケース事業者（JPYC を使う側） にとっては、海外ツールは高額で、日本語コンプライアンス文脈（FISC、資金決済法、犯収法）との相性が十分ではないケースもあります。

筆者は株式会社refinancier として、ChainAnalyzer というマルチチェーン AML プラットフォームを開発・運営しています:

• 9チェーン対応（Bitcoin・Ethereum・Polygon・Base・Arbitrum・Optimism・Avalanche・Solana の 8 チェーン即時対応 + BNB Smart Chain は Enterprise ロールアウト中）
• ステーブルコイン特化 AML（JPYC・USDT・USDC・PYUSD・FDUSD）
• FATF トラベルルール対応のしきい値検知
• 日本語ネイティブ UI・ドキュメント
• FISC 準拠のセキュリティ統制（ISMS フェーズ1 対応中）
• Azure Japan East ホスティング
• 月額 $4.99 〜 Enterprise 個別見積

→ ChainAnalyzer 公式サイト

無料プランで Free tier の体感もできます。JPYC エコシステムや国内暗号資産事業者のコンプライアンスご担当者の方はぜひお試しください。

まとめ

• 日本の暗号資産 AML は 資金決済法 + 犯収法 + FATF トラベルルール の3層構造
• 実装の肝は 受取アドレスのリスク評価 + しきい値検知 + 証跡保全
• 技術的には Neo4j + OSINT + ML + 価格オラクル + トラベルルール プロトコルの組み合わせ
• 国産ツールが空白のポジションなので、中堅事業者はここにビジネスチャンスもある

次回は実際に Neo4j と OFAC SDN を使ってアドレスのリスク評価を実装する 具体コードを深掘りします。

お役に立てたら LGTM / ストックお願いします。質問・ツッコミコメントも大歓迎です。

---

参考リンク:

• 金融庁: 暗号資産・電子決済手段関係
• FATF: R.16 Wire Transfers (英語)
• FISC: 金融機関等コンピュータシステムの安全対策基準
• ChainAnalyzer — 日本語ネイティブのマルチチェーン AML

---

ChainAnalyzer では、Solana / EVM / Bitcoin を含むマルチチェーンの
AMLリスクスコアリング、制裁リスト照合、ウォレットドレイナー検知、
トランザクション追跡を提供しています。

• 公式サイト: https://chain-analyzer.com/ja
• MCP Server: https://github.com/rascal-3/chainanalyzer-mcp
• 技術ドキュメント: https://chain-analyzer.com/ja/docs