暗号資産AMLにおける取引解析の基本

概要

スマホ決済のアプリを開くと、「いつ、どこで、いくら使ったか」が一覧で確認できます。
銀行口座の入出金履歴、クレジットカード明細、フリマアプリの売上履歴、海外送金の控え、コンビニでもらうレシートも、普段は何気なく見ている お金の記録 です。

たとえば、クレジットカード明細に見覚えのない請求があれば、「この支払いは自分のものだろうか」と確認します。
銀行口座から急に大きな金額が送金されていれば、「振込先は正しいか」「不正利用ではないか」と気になります。

このように、お金の記録は、単にあとから家計を見返すためだけのものではありません。
支払いミス、不正利用、なりすまし、詐欺被害などに気づくための手がかりにもなります。

身近な記録	残る情報の例	そこから確認できること
スマホ決済履歴	日時、店舗名、金額	いつ・どこで・いくら支払ったか
銀行口座の入出金履歴	入金元、振込先、金額	給与、家賃、送金、定期的な支払い
クレジットカード明細	利用日、加盟店、金額	見覚えのない請求や二重決済の有無
フリマアプリの取引履歴	商品、取引相手、売上、発送状況	売買の流れや取引相手との関係
海外送金の記録	送金人、受取人、国・地域、金額	国をまたいだ資金移動の流れ
システムログ	操作時刻、ユーザー、処理内容	誰がいつ何を操作したか

ここで大切なのは、記録があるから、あとから確認できる という点です。

もちろん、変わった取引が1件あるだけで、すぐに不正だと決めつけることはできません。
旅行、引っ越し、家族への送金、イベントの集金、事業上の支払いなど、普段と違う取引にも正当な理由があるからです。

それでも、次のような動きがあれば、少し立ち止まって確認したくなります。

気になる動き	すぐに断定しない理由	追加で見たいこと
急に高額な送金がある	正当な支払いの可能性もある	送金目的、相手先、過去の取引傾向
短時間に複数の送金がある	イベント集金や業務処理の可能性もある	金額、頻度、送金先の関係
見慣れない海外送金がある	留学・家族送金・取引の可能性もある	国・地域、受取人、取引目的
高リスクな相手と接点がある	誤送金や間接的な接触の可能性もある	資金の前後の流れ、外部情報、本人確認情報

暗号資産AMLも、まずはこの感覚から考えると分かりやすいです。

暗号資産AMLという言葉だけを見ると、金融規制や法律の難しい話に見えるかもしれません。
しかし入口はかなり身近で、「お金の流れを記録から確認し、不自然な動きがあれば追加で確認する」 という考え方に近いです。

ただし、暗号資産には銀行振込やカード決済とは違う特徴があります。

BitcoinやEthereumのようなパブリックブロックチェーンでは、取引履歴が公開され、ブロックエクスプローラーなどを通じて確認できる場合があります。
Bitcoin.orgも、Bitcoinの取引は公開され、追跡可能で、ネットワーク上に永続的に保存されると説明しています。

参考: Bitcoin.org: Protect your privacy

一方で、取引履歴に銀行口座の名義のような実名がそのまま表示されるわけではありません。
多くの場合、外から見えるのは 0x... や 1A1z... のような アドレス です。

そのため、暗号資産は「匿名で使える」と言われることがあります。
しかし、ここで大切なのは、名前が直接見えないこと と 取引の流れをまったく追えないこと は別だという点です。

身近な例でいえば、SNSのユーザー名に少し似ています。
ユーザー名だけを見ても本名は分かりません。
しかし、投稿内容、投稿時間、リンク先、他のサービスで使っているIDなどが積み重なると、そのアカウントの行動パターンが見えてくることがあります。

ブロックチェーンのアドレスも同じように、アドレス単体では持ち主が分からない場合があります。
一方で、そのアドレスに紐づく取引履歴が公開されている場合、資金がどこから来て、どこへ移動したのかをたどれることがあります。

FATFは、Virtual Assets、つまり暗号資産を含む仮想資産について、デジタルに取引・移転・支払い利用できる価値のデジタル表現として説明しています。
また、暗号資産には支払いを速く・安くできる可能性がある一方で、適切な規制がなければ犯罪者やテロリストの資金移動に悪用されるリスクがあるとも説明しています。

参考: FATF: Virtual Assets

このような背景から、暗号資産交換業者などの事業者には、利用者確認、取引記録の保存、不自然な取引の確認、疑わしい取引の届出、送付人・受取人情報の通知などが求められる場合があります。

日本でも、金融庁が公表している資料では、電子決済手段および暗号資産の移転に係る通知義務、いわゆる トラベルルール に関する事項が整理されています。
トラベルルールは、暗号資産の移転時に、送付人や受取人に関する情報を関係する事業者間で伝えるための仕組みとして理解すると分かりやすいです。

参考: 金融庁: 犯罪による収益の移転防止に関する法律施行令の一部を改正する政令案等に関するパブリックコメントの結果等について

暗号資産AMLで重要なのは、オンチェーン情報だけを見ることではありません。
オンチェーン情報とは、ブロックチェーン上に記録され、外から確認できる取引履歴のことです。
そこに、取引所のKYC情報、ブロックエクスプローラーのラベル、公的機関の制裁リスト、既知の不正アドレス、顧客の取引目的などの外部情報を組み合わせることで、リスクを評価していきます。

情報の種類	例	役割
オンチェーン情報	アドレス、トランザクション、金額、時刻	資金の流れを確認する入口
外部ラベル	取引所、ミキサー、ブリッジ、既知サービス	アドレスの用途を推定する手がかり
KYC情報	氏名、本人確認、取引目的	事業者側で顧客を確認するための情報
Travel Rule情報	送付人・受取人に関する情報	事業者間で移転情報を伝えるための情報
Red Flag	不自然な取引パターン、高リスク接点	追加確認が必要なサイン

ここで、Red Flag という言葉も出てきます。
直訳すると「赤い旗」ですが、暗号資産AMLでは「すぐに犯罪と決めつける印」ではなく、立ち止まって追加確認した方がよいサイン と考えると分かりやすいです。

FATFは、Virtual Assetsに関するRed Flagとして、匿名性を高める技術的特徴、地理的リスク、不規則・不自然な取引パターン、合理的な説明がない取引規模、送付人・受取人の不自然な行動、資金源に関する情報などを挙げています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

ただし、Red Flagに当てはまったからといって、それだけで犯罪だと断定できるわけではありません。
セキュリティ監視でアラートが出ても、まずはログや通信先、端末の状態を確認するのと同じです。
暗号資産AMLでも、取引履歴はあくまで確認の入口であり、判断には文脈が必要になります。

最近は、ステーブルコイン、ブリッジ、DeFi、ミキサー、アンホステッドウォレット、オフショアVASPなど、暗号資産AMLを難しくする論点も増えています。
FATFの2025年の更新でも、暗号資産が国境を越えて使われるため、一部の法域で規制や監督が不十分だと、世界的なリスクにつながり得ることや、ステーブルコインの不正利用リスクが指摘されています。

参考: FATF: Targeted Update on Implementation of FATF Standards on Virtual Assets and VASPs, 2025

このように書くと、暗号資産AMLはかなり難しそうに見えるかもしれません。
しかし、本記事で最初に押さえたい感覚はシンプルです。

暗号資産AMLは、「ブロックチェーンを見ればすべて分かる」という話ではありません。
逆に、「匿名だから何も分からない」という話でもありません。
公開された取引履歴、外部情報、本人確認、リスク評価を組み合わせて、どこまで見えて、どこから追加確認が必要なのかを分けて考えることが大切です。

この記事では、暗号資産AMLをいきなり法律や規制の一覧として説明するのではなく、身近なお金の履歴から順番に整理します。

そのうえで、次のような問いに答えていきます。

• AML/CFTとは、何を防ぐための取り組みなのか
• 暗号資産では、どのような取引情報が見えるのか
• オンチェーン取引解析では、何をどう見ているのか
• KYC、VASP、Travel Ruleはなぜ関係するのか
• Red Flagやリスクスコアは、どのように使うべきなのか
• ミキサー、ブリッジ、ステーブルコイン、アンホステッドウォレットは、なぜ論点になるのか
• 取引解析で分かることと、分からないことは何か

この記事を読み終えるころには、暗号資産AMLを「難しい規制用語の集まり」としてではなく、取引履歴を読み解き、リスクを慎重に判断するための考え方 として捉えられるようになることを目指します。

💡 豆知識
AMLは「怪しい人を一発で見つけるツール」というより、本人確認、記録保存、取引モニタリング、必要に応じた届出などを組み合わせる運用全体に近いです。
オンチェーン分析も、その中の一つの手がかりとして見ると理解しやすくなります。

ここまでで、暗号資産AMLを考える入口として「記録からお金の流れを見る」という感覚を整理しました。
次の章では、本記事が派生元のブロックチェーン全体像記事の中でどの位置づけになるのかを確認します。

---

この記事の立ち位置

本記事は、以前作成した 「身近な記録から理解するブロックチェーンの全体像」 の派生記事です。

派生元の記事では、ブロックチェーンを「複数の参加者が同じ記録を共有し、その記録があとからこっそり書き換えられていないかを確認しやすくする仕組み」として整理しました。
そこでは、ブロック、チェーン、台帳、分散、ハッシュ、デジタル署名、コンセンサス、スマートコントラクト、情報セキュリティ上の強みと限界を広く扱いました。

本記事では、その中でも特に 暗号資産AML と 取引解析 に絞って深掘りします。

ブロックチェーンの全体像を「地図」とするなら、本記事はその中の お金の流れをどう確認するか に注目する記事です。
もう少し具体的に言うと、公開された取引履歴、アドレス、ブロックエクスプローラー、取引所のKYC、Travel Rule、Red Flag、リスクスコアリングなどがどのように関係するのかを整理します。

ただし、いきなり制度や規制の細かい話から入るのではなく、前章と同じように、身近なお金の履歴から考えていきます。

たとえば、銀行口座の入出金履歴を見れば、給与、家賃、振込、引き落としなどの流れを確認できます。
クレジットカード明細を見れば、どの加盟店で、いつ、いくら使ったかを確認できます。
システムログを見れば、誰が、いつ、どの操作をしたのかをあとから調べられます。

暗号資産AMLにおける取引解析も、最初の感覚としてはこれに近いです。

もちろん、ブロックチェーンの取引履歴は銀行明細やカード明細と同じものではありません。
銀行口座には口座名義や金融機関の本人確認が関係しますが、BitcoinやEthereumのようなパブリックブロックチェーンでは、多くの場合、取引に実名ではなくアドレスが表示されます。

一方で、Bitcoin.orgが説明しているように、Bitcoinの取引は公開され、追跡可能で、ネットワーク上に永続的に保存されます。
つまり、実名が直接見えにくいこと と 取引履歴を確認できること が同時に存在します。

参考: Bitcoin.org: Protect your privacy

この性質が、暗号資産AMLを考えるうえでとても重要になります。

FATFは、暗号資産やVASPに対するAML/CFT対策として、顧客管理、記録保存、疑わしい取引の報告、送付人・受取人情報の取得・保持・安全な送信などを求めています。
また、暗号資産サービス提供者は、金融機関と同じような予防措置を実施する必要があると説明されています。

参考: FATF: Virtual Assets

日本でも、金融庁はFATFによるトラベル・ルール監督のベストプラクティス公表について紹介しており、暗号資産に係るFATF基準の実施促進が国際的な論点であることが分かります。

参考: 金融庁: FATFによる「トラベル・ルールの監督におけるベスト・プラクティス」の公表について

ここで注意したいのは、暗号資産AMLを 「ブロックチェーン分析だけの話」 として見ないことです。

オンチェーン上では、アドレス間の資金移動、取引時刻、金額、スマートコントラクトとのやり取りなどを確認できる場合があります。
しかし、そのアドレスを誰が管理しているのか、どのような目的で取引したのか、法的にどのように評価されるのかは、オンチェーン情報だけでは分からないことがあります。

そのため、本記事では次のように分けて考えます。

観点	本記事での扱い方
オンチェーン情報	ブロックチェーン上で確認できるアドレス、取引履歴、金額、時刻、資金の流れを整理する
オフチェーン情報	KYC、取引所の内部情報、公式発表、公的リスト、SNSやWebサイト上の公開情報などを整理する
取引解析	公開履歴と外部情報を組み合わせて、追加確認が必要な流れを見つける考え方として扱う
リスク評価	Red Flagやリスクスコアを、犯罪の証明ではなく調査や確認の優先順位付けとして扱う
限界	本人特定、取引目的、犯罪関与の有無は、取引履歴だけで断定しない

このように、本記事は技術記事でありながら、単にブロックチェーンのデータ構造だけを説明する記事ではありません。
また、法律記事として細かい条文解釈を行う記事でもありません。

目指すのは、技術と制度のあいだにある 「取引履歴をどう読み、どこから先は追加確認が必要なのか」 という考え方を、初学者にも分かるように整理することです。

派生元記事との関係

派生元記事との関係を整理すると、次のようになります。

派生元記事	本記事
ブロックチェーン全体の地図を整理する	暗号資産AMLと取引解析に絞って整理する
身近な記録からブロックチェーンを説明する	身近なお金の履歴からAMLを説明する
ハッシュ、署名、分散、コンセンサスなどを広く扱う	アドレス、取引履歴、KYC、Travel Rule、Red Flag、リスク評価を扱う
情報セキュリティ上の強みと限界を整理する	取引解析の有用性と限界、誤検知、プライバシー上の注意点を整理する
ブロックチェーンを「記録を信じる仕組み」として見る	暗号資産AMLを「記録から資金の流れを確認する仕組み」として見る

関連記事: 身近な記録から理解するブロックチェーンの全体像

上記の ここに派生元記事のURLを挿入 の部分には、投稿時に派生元記事のURLを差し込む想定です。

本記事で大切にする距離感

暗号資産AMLというテーマでは、次のような極端な見方をしてしまうと、理解がずれやすくなります。

極端な見方	本記事での見方
暗号資産は匿名だから何も追えない	実名は直接見えにくいが、公開履歴から資金の流れを追える場合がある
ブロックチェーンを見れば全部分かる	アドレスの持ち主や取引目的は、外部情報なしに断定しにくい
リスクスコアが高いなら犯罪である	リスクスコアは追加確認の優先順位付けに使う材料である
Red Flagに当てはまれば不正である	Red Flagは立ち止まって確認するためのサインである
AMLは規制対応だけの話である	技術、ログ分析、本人確認、運用、プライバシーが関係する総合的な取り組みである

この距離感は、情報セキュリティのログ分析にも似ています。

たとえば、サーバーログに大量のログイン失敗が残っていたとしても、それだけで攻撃成功とは言い切れません。
しかし、通常と違うアクセス元、短時間の連続試行、権限変更、外部通信などが重なると、追加調査の優先度は上がります。

暗号資産AMLでも同じです。
不自然に見える取引があるからといって、すぐに犯罪と決めつけるのではなく、前後の資金の流れ、関係するアドレス、外部ラベル、顧客情報、取引目的などを組み合わせて慎重に見ていく必要があります。

💡 豆知識
AMLは、すべての取引を見張って自動で答えを出す「監視カメラ」というより、不自然な点を見落とさないための 防犯チェックリスト に近いです。
暗号資産AMLでは、このチェックリストにアドレス、取引履歴、外部ラベルといったオンチェーン由来の確認項目が加わります。

この章のまとめ

この章では、本記事の立ち位置を整理しました。

本記事は、ブロックチェーン全体を説明する派生元記事から一歩進み、暗号資産AMLと取引解析に焦点を当てる記事です。
ただし、実在アドレスを追跡したり、個別事件の犯人特定を行ったり、資金洗浄や追跡回避の手順を説明したりする記事ではありません。

この章で押さえたいポイントは、次の通りです。

• 本記事は、ブロックチェーン全体像記事の派生として、暗号資産AMLと取引解析を深掘りする
• 暗号資産AMLは、オンチェーン分析だけでなく、KYC、Travel Rule、外部情報、リスク評価と関係する
• 取引履歴から資金の流れを追える場合があるが、本人特定や犯罪関与を安易に断定してはいけない
• Red Flagやリスクスコアは、犯罪の証明ではなく、追加確認の手がかりとして扱う
• 技術と制度のあいだにある「どこまで見えて、どこから追加確認が必要か」を分けて考えることが大切

次の章では、この記事を読むことで具体的に何が分かるのかを整理します。
全体の見通しを先に確認しておくことで、AML/CFT、KYC、Travel Rule、オンチェーン分析といった用語が出てきても、どの話をしているのか迷いにくくなります。

---

この記事で分かること

前の章では、本記事がブロックチェーン全体像記事の派生として、暗号資産AMLと取引解析に焦点を当てる記事であることを整理しました。

ここでは、この記事を読み進めると何が分かるのかを、先にざっくり確認しておきます。

暗号資産AMLという言葉には、少し硬い印象があります。
AML/CFT、KYC、VASP、Travel Rule、Red Flag、リスクスコアリング といった英字の用語も多く出てきます。

ただ、最初からすべての用語を暗記する必要はありません。
本記事では、まず 身近なお金の履歴を見る感覚 から出発し、そこから少しずつブロックチェーン上の取引解析に近づいていきます。

たとえば、クレジットカード明細で見覚えのない請求を確認するとき、いきなり「これは不正だ」と決めつけるのではなく、利用日、店舗名、金額、家族利用の可能性、サブスク更新などを確認します。

暗号資産AMLでも、考え方は少し似ています。
取引履歴を見て、資金の流れや不自然な点を確認します。
ただし、それだけで犯罪や本人を断定するのではなく、KYC情報、外部ラベル、取引目的、既知のリスク情報などを組み合わせて慎重に判断します。

この記事では、最終的に次のような見方ができるようになることを目指します。

暗号資産AMLは、「ブロックチェーンを見れば何でも分かる」という話ではありません。
しかし、「匿名だから何も分からない」という話でもありません。
公開された取引履歴、外部情報、本人確認、リスク評価を組み合わせて、どこまで見えて、どこから追加確認が必要なのかを分けて考えることが大切です。

この記事で整理する主なテーマ

この記事で扱うテーマを、先に一覧にすると次のようになります。

テーマ	この記事での整理のしかた
AML/CFT	犯罪収益やテロ資金供与に関係するお金の流れを見つけ、不正利用を防ぐ取り組みとして整理する
KYC	取引所などが利用者を確認するための仕組みとして、銀行口座開設の本人確認に近い例から説明する
VASP	暗号資産交換業者など、暗号資産の交換・移転・保管に関わる事業者として整理する
Travel Rule	暗号資産の移転時に、送付人・受取人情報を事業者間で伝える仕組みとして整理する
オンチェーン情報	アドレス、トランザクション、金額、時刻など、ブロックチェーン上で確認できる情報として整理する
取引解析	資金の流れ、アドレス間の関係、既知サービスとの接点を確認する作業として整理する
Red Flag	犯罪の断定ではなく、追加確認が必要なサインとして整理する
リスクスコアリング	取引やアドレスを優先的に確認するための補助情報として整理する
誤検知・過検知	怪しく見える取引にも正当な理由があり得ることを整理する
プライバシー	取引履歴が見えることの便利さと、利用者の行動が見えすぎる課題を整理する

FATFは、暗号資産やVASPに対してAML/CFT上のリスクを踏まえた対応を求めており、VASPには顧客管理、記録保存、疑わしい取引の報告、送付人・受取人情報の取得・保持・送信などが求められると説明しています。

参考: FATF: Virtual Assets

また、Bitcoin.orgは、Bitcoinの取引が公開され、追跡可能で、ネットワーク上に永続的に保存されると説明しています。
この「取引履歴を確認できる」という性質が、暗号資産AMLにおけるオンチェーン分析の入口になります。

参考: Bitcoin.org: Protect your privacy

図で見る：この記事で扱う範囲

本記事で扱う範囲を、かなり単純化して図にすると次のようになります。

この図で大切なのは、暗号資産AMLを 規制だけの話 として見ないことです。

もちろん、AML/CFTには法制度や規制の話が関係します。
しかし、技術的には、ブロックチェーン上の取引履歴、アドレス、トランザクション、外部ラベル、ログ分析、リスク判定といった、情報セキュリティやデータ分析に近い要素も多く含まれます。

そのため、本記事では次の2つをつなぐ形で説明します。

観点	本記事での見方
制度・運用の観点	AML/CFT、KYC、Travel Rule、疑わしい取引の確認などを整理する
技術・分析の観点	アドレス、取引履歴、資金フロー、ラベル付け、リスクスコアを整理する

この2つを分けたうえでつなげると、暗号資産AMLがかなり見通しやすくなります。

特に分けて考えたいこと

暗号資産AMLでは、似ているようで違う概念がたくさん出てきます。

ここを混同すると、取引解析を過大評価したり、逆に必要以上に「何も分からない」と考えてしまったりします。

この記事では、特に次の違いを丁寧に分けます。

混同しやすいこと	分けて考えたいこと
アドレスが分かる	そのアドレスの持ち主が必ず分かるとは限らない
資金の流れを追える	取引の目的や意図まで分かるとは限らない
取引所らしきアドレスに入金された	取引所内部で誰が何をしたかまでは外から見えにくい
高リスクアドレスと接点がある	犯罪関与を断定できるわけではない
Red Flagに該当する	追加確認が必要なサインであり、結論ではない
リスクスコアが高い	優先的に確認する材料であり、犯罪の証明ではない
透明性が高い	利用者のプライバシー課題がないわけではない
AMLは規制の話	実際にはログ分析、データ解析、セキュリティ運用とも関係する

たとえば、FATFはVirtual Assetsに関するRed Flag Indicatorsを公表しています。
そこでは、取引パターン、匿名性を高める技術的特徴、送付人・受取人の不自然な行動、資金源、地理的リスクなどが、ML/TFの疑いを見つけるための指標として整理されています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

ただし、Red Flagは「赤信号」ではなく、どちらかというと 注意して確認するための目印 です。
1つ当てはまったからといって、すぐに犯罪だと決まるわけではありません。

この感覚は、セキュリティ監視にも近いです。
アラートが出たら確認は必要ですが、アラートが出た時点で侵害が確定するわけではありません。
ログ、通信先、端末状態、利用者の操作、過去の傾向などを見て、総合的に判断します。

暗号資産AMLでも同じように、オンチェーンの取引履歴は重要な手がかりですが、判断には文脈が必要です。

用語は「身近な例」とセットで見ていく

この記事では、専門用語をできるだけ身近な例と一緒に説明します。

専門用語	身近な例でいうと	注意したい点
アドレス	送金先IDや口座番号のような宛先	ただし銀行口座名義のように実名が直接見えるとは限らない
トランザクション	振込記録や支払い履歴の1件	送金だけでなく、スマートコントラクト操作を含む場合がある
ブロックエクスプローラー	公開された取引履歴を調べる検索サイト	表示ラベルや解釈はサービスによって異なる場合がある
KYC	口座開設時の本人確認	ブロックチェーン上に本人情報が公開されるという意味ではない
Travel Rule	送金に必要な情報を事業者間で伝える仕組み	一般利用者に全情報が公開されるわけではない
Red Flag	防犯チェックリストの注意項目	犯罪の断定ではなく、追加確認のきっかけ
リスクスコア	重点確認の優先度	スコアだけで白黒を決めるものではない

金融庁は、暗号資産の移転に係る通知義務、いわゆるトラベルルールについて、送付人・受取人に関する情報を通知する制度として整理しています。

参考: 金融庁: 暗号資産・電子決済手段の移転に係る通知義務（トラベルルール）

このような制度の話も、いきなり条文のように読むと難しく感じます。
しかし、身近な送金で考えると、「誰が、誰に、どのような目的で送っているのかを、必要な範囲で確認できるようにする仕組み」と捉えることができます。

この記事を読み終えたときのゴール

この記事を読み終えたときに、次のような状態になっていることを目指します。

• 暗号資産AMLを、単なる規制用語ではなく「取引履歴を読み解くための考え方」として説明できる
• AML/CFT、KYC、VASP、Travel Ruleの関係を、初学者向けにざっくり説明できる
• アドレスやトランザクションから見える情報と、見えない情報を分けて考えられる
• オンチェーン分析が、資金の流れを確認するための手がかりになることを理解できる
• Red Flagやリスクスコアを、犯罪の断定ではなく追加確認の材料として扱える
• ミキサー、ブリッジ、ステーブルコイン、アンホステッドウォレットがなぜAML上の論点になるのかを説明できる
• 誤検知、過検知、プライバシーへの配慮が必要な理由を理解できる

暗号資産AMLは、技術・制度・運用が重なるテーマです。
そのため、一つの用語だけを覚えても全体像はつかみにくいです。

本記事では、まず全体の地図を見ながら、少しずつ細かい道に入っていきます。

💡 豆知識
Red Flagは第6章で詳しく扱います。
ここではまず、「危険確定」ではなく 追加確認の目印 という距離感だけ押さえておけば十分です。

この章のまとめ

この章では、この記事で分かることを整理しました。

本記事では、暗号資産AMLをいきなり規制や法律の一覧として説明するのではなく、身近なお金の履歴から出発します。
そこから、AML/CFT、KYC、VASP、Travel Rule、オンチェーン分析、Red Flag、リスクスコアリング、誤検知、プライバシーといったテーマへ少しずつ進みます。

この章で押さえたいポイントは、次の通りです。

• 暗号資産AMLは、取引履歴や記録を確認する考え方と深く関係する
• オンチェーン情報だけで本人や犯罪関与を断定できるわけではない
• Red Flagやリスクスコアは、追加確認のための手がかりとして扱う
• KYCやTravel Ruleは、オンチェーンだけでは足りない情報を補う制度として理解すると分かりやすい
• 暗号資産AMLは、規制だけでなく、データ解析やセキュリティ運用とも関係する

次の章では、この記事がどのような読者を想定しているのかを整理します。
前提知識を確認しておくことで、AML/CFTやオンチェーン分析が初めてでも、どこから読めばよいか分かりやすくなります。

---

対象読者

前の章では、この記事で分かることを整理しました。
ここでは、この記事をどのような人に向けて書いているのか、またどのくらいの前提知識を想定しているのかを確認しておきます。

暗号資産AMLは、ブロックチェーン、金融犯罪対策、本人確認、規制対応、データ分析、セキュリティ運用が重なるテーマです。
そのため、最初からすべてを理解しようとすると、かなり難しく感じるかもしれません。

ただし、本記事では、いきなり専門家向けの制度解説や商用ツールの話には入りません。
まずは、銀行振込の履歴、クレジットカード明細、スマホ決済履歴、フリマアプリの取引履歴のような、身近なお金の記録から少しずつ整理していきます。

そのため、この記事は次のような人を想定しています。

想定読者	この記事で役立つこと
ブロックチェーンや暗号資産を学び始めた人	アドレスや取引履歴がAMLとどう関係するのかを整理できる
暗号資産AMLという言葉を聞いたことはあるが、全体像がつかめていない人	AML/CFT、KYC、VASP、Travel Ruleの関係をざっくり理解できる
オンチェーン分析や取引解析に興味がある人	資金フロー、ラベル付け、リスクスコアリングの入口を理解できる
情報セキュリティを学んでいる人	ログ分析やアラート確認に近い感覚で、取引解析を捉えられる
金融・決済領域のセキュリティに関心がある人	規制対応と技術分析がどのようにつながるのかを確認できる
「暗号資産は匿名なのか、追跡できるのか」で混乱している人	匿名性、仮名性、透明性、追跡可能性を分けて考えられる

たとえば、情報セキュリティを学んでいる人であれば、サーバーログや認証ログを確認する場面を思い浮かべると理解しやすいです。

ログに不自然なアクセスが1件あったとしても、それだけで侵害が確定するわけではありません。
アクセス元、時刻、ユーザー、失敗回数、権限変更、外部通信などを組み合わせて、追加確認が必要かを判断します。

暗号資産AMLでも、これに近い考え方が出てきます。
あるアドレスが高リスクとされるアドレスと接点を持っていたとしても、それだけで犯罪関与を断定するわけではありません。
前後の資金の流れ、取引所との接点、外部ラベル、KYC情報、取引目的などを組み合わせて、慎重に見ていく必要があります。

この図のように、本記事では専門用語を一気に詰め込むのではなく、段階的に理解できる流れを意識します。

前提知識はどのくらい必要か

この記事を読むうえで、暗号資産や金融規制の専門知識は必須ではありません。

ただし、次のような言葉を聞いたことがあると、少し読みやすくなります。

前提知識	必要度	補足
ブロックチェーンが取引や状態を記録する仕組みであること	あると読みやすい	派生元記事で整理した内容に近いです
アドレスという識別子が使われること	なくてもよい	記事内で、送金先IDのような例から説明します
トランザクションという言葉	なくてもよい	振込記録や支払い履歴の1件に近いものとして説明します
AML/CFTの専門知識	なくてもよい	身近な不正利用確認の例から説明します
KYCやTravel Ruleの知識	なくてもよい	銀行口座開設時の本人確認や送金情報の例から説明します
オンチェーン分析の経験	なくてもよい	架空データや図を使って考え方を説明します
法律の専門知識	なくてもよい	法的助言ではなく、技術と制度の全体像として扱います
Pythonの経験	なくてもよい	コード例を入れる場合も、概念理解用の小さな例に限定します

途中で、AML/CFT、KYC、VASP、Travel Rule、Red Flag、リスクスコアリング などの用語が出てきます。

ただし、これらは最初に全部覚える必要はありません。
本文中で出てきたタイミングで、できるだけ身近な例と一緒に説明します。

たとえば、KYCは銀行口座を開設するときの本人確認に近いものとして説明します。
Travel Ruleは、暗号資産の移転時に、送付人や受取人に関する情報を事業者間で伝える仕組みとして説明します。
Red Flagは、犯罪の断定ではなく「ここは追加確認した方がよい」という付箋のようなものとして扱います。

どのような読み方を想定しているか

この記事は、最初から最後まで順番に読むことを想定しています。

理由は、暗号資産AMLでは、用語同士がかなりつながっているからです。
たとえば、オンチェーン分析だけを先に読むと、「取引履歴を見れば全部分かるのでは」と感じるかもしれません。
一方で、KYCやTravel Ruleだけを先に読むと、「規制の話ばかりで技術とどう関係するのか」が見えにくくなります。

そのため、本記事では次の順番で理解できるようにしています。

読む順番	目的
身近なお金の履歴	記録からお金の流れを確認する感覚をつかむ
AML/CFTの基本	なぜ不正な資金移動を確認する必要があるのかを理解する
暗号資産で見える情報	アドレスやトランザクションから何が分かるのかを整理する
オンチェーン分析	資金の流れやリスク接点をどう見るのかを理解する
KYC・VASP・Travel Rule	オンチェーンだけでは足りない情報をどう補うのかを整理する
限界と注意点	誤検知、過検知、プライバシー、断定しすぎの危険を確認する

もちろん、すでにブロックチェーンの基礎を知っている人は、途中の技術説明を軽く読み流しても大丈夫です。
逆に、金融規制に詳しくない人は、AML/CFTやTravel Ruleの章を少し丁寧に読むと理解しやすくなります。

この記事が特に意識している読み手

この記事では、特に 技術を学びながら、社会でどう使われるのかも知りたい人 を意識しています。

ブロックチェーンは、ハッシュ、署名、分散台帳、スマートコントラクトなど、技術的に面白い要素が多い分野です。
一方で、暗号資産として使われる場合は、お金の流れ、本人確認、金融犯罪対策、プライバシー、法制度とも関係します。

そのため、暗号資産AMLを学ぶと、次のような視点をつなげて考えられるようになります。

技術寄りの視点	社会・運用寄りの視点
アドレスやトランザクションをどう読むか	その取引をどのように確認・判断するか
取引履歴をグラフとしてどう見るか	どの取引を優先して確認するか
リスクスコアをどう計算するか	スコアをどう説明し、誤検知をどう扱うか
公開台帳の透明性をどう活かすか	利用者のプライバシーをどう守るか
ブリッジやステーブルコインの動きをどう追うか	国境を越える資金移動をどう監督するか

このように、暗号資産AMLは「規制の暗記」だけでも、「技術だけの分析」だけでもありません。
技術、制度、運用、プライバシーのバランスを見ながら考えるテーマです。

この記事を読むときに意識してほしいこと

読み進めるときは、次の3つを意識すると理解しやすくなります。

意識したいこと	理由
見える情報と見えない情報を分ける	アドレスや取引履歴が見えても、本人や意図までは見えない場合があるため
推定と断定を分ける	ラベルやリスクスコアには不確実性が含まれるため
技術と制度を分けたうえでつなげる	オンチェーン分析、KYC、Travel Ruleはそれぞれ役割が違うため

この3つは、この記事全体で何度も出てきます。

特に、暗号資産AMLでは「見えるから分かる」と考えすぎても、「匿名だから何も分からない」と考えすぎても、どちらも極端です。
大切なのは、どこまでが公開履歴から確認できることなのか、どこからが外部情報や追加確認を必要とすることなのか を分けることです。

💡 豆知識
AMLはコンプライアンス部門だけの話に見えるかもしれませんが、エンジニアにも関係します。
ログ設計、データベース設計、アラート設計、監査ログの保存、誤検知を減らす運用などは、まさに技術設計とつながる部分です。

この章のまとめ

この章では、本記事の対象読者を整理しました。

本記事は、暗号資産AMLを初めて学ぶ人でも読めるように、身近なお金の記録から導入します。
一方で、単なる用語集ではなく、オンチェーン分析、KYC、Travel Rule、Red Flag、リスクスコアリング、誤検知、プライバシーまでつなげて整理します。

この章で押さえたいポイントは、次の通りです。

• 金融規制やオンチェーン分析の専門知識がなくても読める構成にする
• 専門用語は、身近な例とセットで説明する
• 技術だけでなく、制度・運用・プライバシーとの関係も扱う
• 読むときは、見える情報と見えない情報、推定と断定を分ける
• 暗号資産AMLは、エンジニアにとってもセキュリティ・データ分析・監査設計と関係するテーマである

次の章では、逆に 本記事で扱わないこと を整理します。
扱う範囲を先に区切っておくことで、取引解析の記事であっても、実在アドレスの追跡や不正利用の手順説明に踏み込まない方針を明確にします。

---

本記事で扱わないこと

ここまでで、本記事がどのような読者を想定しているかを整理しました。
次に、この記事で あえて扱わないこと も先に明確にしておきます。

暗号資産AMLやオンチェーン分析は、便利な分析技術である一方、扱い方を間違えると、実在する個人・組織への誤った断定や、不正利用につながる説明になってしまう可能性があります。

たとえば、ブロックエクスプローラーで取引履歴を見られるからといって、実在アドレスを使って「この人が犯人だ」と決めつけることはできません。
また、ミキサー、ブリッジ、ステーブルコイン、アンホステッドウォレットのようなテーマも、AML上の論点としては重要ですが、使い方を具体的に説明しすぎると、追跡回避や資金洗浄の手順説明に近づいてしまうおそれがあります。

そのため、本記事では 仕組みを理解するために必要な範囲 と、実務・法律・不正手順に踏み込みすぎる範囲 を分けて扱います。

扱わないことを先に決めておく理由

身近な例で考えてみます。

家計簿アプリや銀行口座の入出金履歴を見ると、いつ、どこへ、いくら支払ったかを確認できます。
しかし、その履歴を見ただけで、支払いの理由や本人の意図まで正確に分かるとは限りません。

たとえば、ある人が高額な振込をしていたとしても、それだけで不正とは言えません。
家賃、学費、家族への送金、商品の購入、立替精算など、いろいろな理由が考えられます。

暗号資産の取引履歴も同じです。

オンチェーン上で、あるアドレスから別のアドレスへ資金が移動したことを確認できる場合があります。
しかし、その取引の背景、本人の意図、法律上の評価、犯罪との関係までは、取引履歴だけで断定できるとは限りません。

この区別を忘れると、次のような危険があります。

危険な読み方	何が問題か
高リスクアドレスと接点があるから犯罪者だと決めつける	被害者、サービス経由、誤送金、二次的な受取などの可能性を無視してしまう
アドレスのラベルを絶対視する	ラベルの根拠、更新時期、誤りの可能性を見落とす
取引履歴だけで本人を特定できると考える	本人確認情報や外部情報が必要な範囲を混同してしまう
ミキサーやブリッジの具体的な使い方に踏み込む	追跡回避や不正利用に近い説明になってしまう
法制度を一度調べただけで固定的に理解する	AML/CFTや制裁関連の制度は更新される可能性がある

本記事では、このような誤解を避けるために、観察できること、推定できること、断定してはいけないこと を分けながら説明します。

この図のように、本記事では主に、オンチェーン上で見える情報をどのように読み、どこから推定になるのかを扱います。
一方で、本人確認情報、取引所内部の記録、捜査上の情報、法的判断は、本記事の中心には置きません。

本記事で扱わない内容

本記事では、以下の内容は扱いません。

扱わない内容	理由
実在する個人・組織・アドレスの追跡	誤った特定やプライバシー侵害につながる可能性があるため
個別事件の犯人特定	公開情報だけで断定できるものではなく、法的・捜査的な判断が必要になるため
資金洗浄、制裁回避、追跡回避につながる具体的な手順	不正利用を助ける内容になり得るため
ミキサーやブリッジを使った具体的な資金移動方法	AML上の論点としては扱うが、操作手順としては扱わない
取引所の内部調査手法や非公開情報	一般公開されていない情報や実務上の機密に関わる可能性があるため
特定の暗号資産やサービスの投資判断	本記事は技術・セキュリティ・AMLの理解を目的としており、投資助言ではないため
法律上の助言	法制度は国や時期で変わり、専門家による確認が必要なため
すべての国・地域の規制比較	範囲が広くなりすぎ、記事の主題から外れるため
商用AMLツールの詳細比較	ツール評価ではなく、基礎概念の理解を目的とするため
実務レベルのリスクスコアリング設計	実際の運用では多くの内部データ、規程、監督上の要件が関係するため

この表だけを見ると、少し制限が多いように感じるかもしれません。
しかし、この記事の目的は、実務手順や事件分析をそのまま再現することではありません。

あくまで、暗号資産AMLを理解するための土台として、次のような問いに答えることを目指します。

• なぜ暗号資産の取引履歴はAML/CFTと関係するのか
• オンチェーン分析では、何が見えて、何が見えないのか
• KYCやTravel Ruleは、オンチェーン情報だけでは足りない部分をどう補うのか
• Red Flagやリスクスコアは、なぜ「犯罪の証明」ではなく「追加確認のきっかけ」なのか
• 誤検知やプライバシーに、なぜ注意しなければならないのか

ミキサー、ブリッジ、ステーブルコインはどう扱うか

ミキサー、ブリッジ、ステーブルコイン、アンホステッドウォレットは、暗号資産AMLを理解するうえで避けて通りにくいテーマです。

FATFのRed Flag Indicatorsでも、匿名性を高める技術やサービス、ミキサー、タンブラー、P2P取引、資金の分散・集約などは、疑わしい取引を検討する際の指標として整理されています。

参考: FATF: Virtual Assets Red Flag Indicators

また、FATFの2025年のTargeted Updateでも、暗号資産やVASPに対するAML/CFT基準の実装状況、Travel Rule、国境を越えるリスクなどが継続的な論点として扱われています。

参考: FATF: Virtual Assets: Targeted Update on Implementation of the FATF Standards on VAs and VASPs, 2025

ただし、本記事ではこれらを 使い方の説明 としては扱いません。

たとえば、ミキサーについては、次のような観点で扱います。

扱う観点	扱わない観点
なぜAML上のリスク指標として見られることがあるのか	具体的な利用手順
取引履歴のつながりが見えにくくなる場合があること	追跡を回避する方法
正当なプライバシー保護と不正利用の両方の文脈があること	特定サービスの使い方や比較
分析時に断定しすぎてはいけないこと	資金洗浄の実践的な流れ

ブリッジについても同じです。
ブリッジは、異なるブロックチェーン間で資産を移動する仕組みとして重要です。
一方で、チェーンをまたぐと分析が難しくなるため、AML上の論点にもなります。

しかし、本記事では「どのブリッジをどう使えば資金の流れを分かりにくくできるか」という話は扱いません。
あくまで、なぜクロスチェーン移動が取引解析を難しくするのか という考え方に絞って説明します。

法律や規制についての注意点

暗号資産AMLでは、FATF、金融庁、JAFIC、FinCEN、OFAC、EU当局など、さまざまな機関の資料が関係します。

ただし、本記事は法律上の助言を行うものではありません。
国や地域によって制度は異なり、同じ用語でも文脈によって意味が変わる場合があります。

たとえば、日本では金融庁が暗号資産移転に関する通知義務、いわゆるTravel Ruleについて情報を公表しています。
これは、暗号資産の移転時に送付人・受取人情報を通知する仕組みに関係するものです。

参考: 金融庁: 暗号資産・電子決済手段の移転に係る通知義務、いわゆるトラベルルールについて

また、OFACは仮想通貨業界向けの制裁コンプライアンスガイダンスを公表しており、制裁対象者や制裁対象地域との取引を避けるためのリスクベースの管理が重要であると説明しています。

参考: OFAC: Sanctions Compliance Guidance for the Virtual Currency Industry

このような情報は、暗号資産AMLを理解するうえで重要です。
しかし、実際の法令対応、届出、制裁スクリーニング、顧客対応、取引停止、凍結などの判断は、各国の法制度、社内規程、専門家の確認が関係します。

そのため、本記事では制度の考え方や背景は説明しますが、個別の法的判断は扱いません。

実在データではなく、学習用の架空データを使う

後の章では、取引履歴やリスク確認の考え方を説明するために、小さなPythonコードを使う可能性があります。

ただし、そこで使うデータはすべて架空のものにします。
実在するアドレス、実際の事件、特定サービスの内部情報、個人情報は使いません。

コード例で行うこと	コード例で行わないこと
架空の取引履歴を表として扱う	実在アドレスを追跡する
アドレスを点、取引を線として見る	実際の犯罪収益をたどる
Red Flagを追加確認のサインとして扱う	犯罪関与を自動判定する
リスクスコアの考え方を簡単に説明する	商用AMLツールの代替を作る
誤検知や過検知の注意点を示す	実務システムとして運用する

この方針にしておくことで、技術的な理解を深めながらも、実在の個人・組織・事件に不必要に踏み込まないようにします。

💡 豆知識
AMLやセキュリティに関わる記事では、何を書くか と同じくらい 何を書かないか も大切です。
仕組みやリスクは分かりやすく説明しつつ、不正利用や追跡回避に直結する手順には踏み込まない距離感を保ちます。

この章のまとめ

この章では、本記事で扱わないことを整理しました。

暗号資産AMLやオンチェーン分析は、公開された取引履歴をもとに資金の流れを理解するうえで役立ちます。
一方で、実在アドレスの追跡、犯人特定、資金洗浄や追跡回避の手順、法律上の助言、取引所の内部情報などは、本記事の範囲外です。

この章で押さえたいポイントは、次の通りです。

• 本記事は、暗号資産AMLと取引解析の基礎を理解するための記事である
• 実在する個人・組織・アドレスの追跡は扱わない
• ミキサー、ブリッジ、ステーブルコインなどは、リスク理解の観点で扱う
• 追跡回避や資金洗浄につながる具体的な手順は扱わない
• 法律や規制は紹介するが、個別の法的助言は行わない
• コード例を使う場合も、架空データによる概念理解に限定する
• 分析では、観察、推定、断定を分けて考える

次の章では、後半でコード例を扱う場合に備えて、コードを試す場合の前提 を整理します。

実際の取引監視システムを作るのではなく、架空データを使って「取引履歴をどう見るか」「どこから推定になるのか」を理解するための準備として見ていきます。

コードを試す場合の前提

本記事では、後半の章で、取引履歴のつながりやリスク確認の考え方を理解するために、Pythonの小さなコード例を使う予定です。

ただし、ここで使うコードはすべて 考え方を理解するための学習用 です。
実在する暗号資産アドレスを追跡したり、本人を特定したり、実務のAMLシステムとして使ったりすることは想定していません。

暗号資産AMLやオンチェーン分析は、言葉だけで説明すると少し抽象的になりがちです。

たとえば、次のような説明を文章だけで読むと、最初はイメージしにくいかもしれません。

• アドレスを点、取引を線として見る
• 資金の流れを数ステップ先までたどる
• 高リスクとされるアドレスとの接点を確認する
• Red Flagを追加確認のサインとして扱う
• 誤検知や過検知に注意する

そこで本記事では、実在データではなく、短い架空データを使って「こういう考え方で見るのか」とつかめるようにします。

イメージとしては、本物の監視システムを作るというより、地図を読む練習に近いです。
いきなり実際の街を歩き回るのではなく、まずは簡単な図を見ながら、道のつながりや分岐を確認するような感覚です。

コード例で扱う目的

コード例の目的は、暗号資産AMLの実務を再現することではありません。

あくまで、次のような基本的な考え方を、手を動かしながら確認することです。

目的	この記事での扱い方
取引履歴を表として見る	架空のアドレス、金額、時刻を持つ小さなデータを使う
資金の流れをたどる	アドレスを点、取引を線として簡単なグラフで考える
ラベルを付けて読む	「取引所らしきアドレス」「高リスクとされるアドレス」などの架空ラベルを使う
Red Flagを理解する	「追加確認が必要そうなサイン」として扱う
誤検知を意識する	条件に当てはまっても、すぐに不正と断定しない例を入れる

ここで大切なのは、コードの出力を「正解」として見るのではなく、判断の入口 として見ることです。

たとえば、コードが「この取引は追加確認候補です」と表示したとしても、それは「この取引は犯罪です」という意味ではありません。
あくまで、設定した条件に当てはまったため、もう少し文脈を確認した方がよい、という意味にとどめます。

想定する環境

本記事のコード例は、できるだけ軽く試せるようにします。

大きな外部ライブラリや、実際のブロックチェーンAPIへの接続は前提にしません。
まずは、Pythonの標準ライブラリだけで、取引履歴の見方を理解できるようにします。

項目	内容
想定言語	Python 3.x系
主な用途	架空の取引履歴を読み、集計し、簡単な関係を見る
主に使う標準ライブラリ	collections、dataclasses、json など
外部ライブラリ	原則なし。必要になった場合は、その章で理由を説明する
ネットワーク接続	使わない想定
使用データ	架空のアドレス・架空の取引データ

参考: Python公式ドキュメント: collections
参考: Python公式ドキュメント: dataclasses
参考: Python公式ドキュメント: json

ここで collections や dataclasses という名前が出てきましたが、最初から詳しく知っている必要はありません。

たとえば、collections は、同じアドレスごとに取引をまとめるときに便利です。
dataclasses は、取引データを「送信元、送信先、金額、時刻」のようなまとまりとして扱いやすくするために使えます。
json は、取引履歴のようなデータを読み書きする形式を理解する入口になります。

難しいライブラリを使いこなすことよりも、まずは 取引データをどのような形で見るか を重視します。

コード例で使うデータのイメージ

コード例では、次のような架空データを使います。

transactions = [
    {
        "tx_id": "tx001",
        "from": "addr_user_a",
        "to": "addr_exchange_x",
        "amount": 1.2,
        "asset": "TEST",
        "time": "2026-07-03 10:00",
    },
    {
        "tx_id": "tx002",
        "from": "addr_user_b",
        "to": "addr_high_risk_sample",
        "amount": 0.5,
        "asset": "TEST",
        "time": "2026-07-03 10:10",
    },
]

これは実在する取引ではありません。
addr_user_a や addr_exchange_x も、実際の暗号資産アドレスではありません。

ここでは、説明しやすいように短い名前を付けています。
本物のブロックチェーンでは、BitcoinアドレスやEthereumアドレスのような長い文字列が使われます。

このような架空データを使うことで、次のようなことを安全に確認できます。

データ項目	ざっくりした意味	学習で見ること
tx_id	取引を識別するID	どの取引を見ているか
from	送信元アドレス	どこから資金が出たか
to	送信先アドレス	どこへ資金が向かったか
amount	金額・数量	どのくらい動いたか
asset	資産の種類	どのトークンを扱っているか
time	取引時刻	いつごろ動いたか

ただし、この表を見ても、現実世界の本人や取引目的までは分かりません。

この点は、本記事全体で何度も意識します。

見えるのは、まず取引データです。
そこから先は、追加情報や文脈がなければ断定できません。

コード例で行うこと・行わないこと

安全に学ぶために、コード例で行うことと行わないことを、あらかじめ分けておきます。

コード例で行うこと	コード例で行わないこと
架空データを使って取引履歴を読む	実在アドレスを追跡する
アドレス間のつながりを図や表で考える	実際の犯罪収益をたどる
簡単な条件で追加確認候補を抽出する	犯罪関与を自動判定する
Red Flagを「確認のきっかけ」として扱う	追跡回避や資金洗浄の手順を説明する
誤検知・過検知の考え方を説明する	商用AMLツールや実務システムの代替を作る
観察・推定・断定を分ける	本人特定や法的判断を行う

ここで特に大切なのは、コードで何かを検出したように見えても、それは断定ではない という点です。

たとえば、架空データ上で「高リスクラベル付きアドレスと接点がある」と表示されたとしても、それは「犯罪である」とは違います。
現実の分析では、ラベルの根拠、取引の文脈、顧客情報、法令上の要件など、さらに多くの確認が必要になります。

コード例の流れ

後半でコード例を扱う場合は、おおよそ次のような流れにします。

この流れにしておくと、単に「コードが動いた」で終わらず、分析結果をどう読むべきかまで確認できます。

特に、D から F の部分が重要です。
条件に当てはまる取引を見つけることはできます。
しかし、その結果をどのように解釈するかは、別の問題です。

これは、セキュリティログのアラートに少し似ています。

ログ監視システムでアラートが出ても、それだけで「必ず侵害された」とは言えません。
通信先、端末、ユーザー操作、時刻、過去の傾向などを確認して、誤検知か、本当に調査すべき事象かを見極めます。

暗号資産AMLの取引解析でも、これに近い姿勢が必要です。

学習用コードと実務システムの違い

本記事のコード例は、実務の取引監視システムとは大きく異なります。

観点	本記事の学習用コード	実務のAML・取引監視システム
データ	架空の小さなデータ	大量の実取引データ、顧客情報、外部リストなど
目的	考え方を理解する	リスク検知、継続的モニタリング、届出判断の支援など
判定	単純な条件分岐	複数ルール、統計、機械学習、担当者確認などが組み合わさる場合がある
出力	追加確認候補の説明	アラート、ケース管理、監査ログ、エスカレーションなど
注意点	概念理解に限定	法令、社内規程、監査、プライバシー保護が関係する

この違いを明確にしておくことで、コード例を過大評価しないようにします。

本記事で扱うコードは、あくまで「考え方の模型」です。
模型を見ると建物の構造は理解しやすくなりますが、そのまま実際の建物として使えるわけではありません。

同じように、学習用コードで取引解析の考え方を理解できても、それをそのまま実務に使うことはできません。

出力では「観察」「推定」「注意」を分ける

コード例では、できるだけ出力の意味が分かるように、次の3つを分けて表示する方針にします。

区分	意味	例
観察	データ上で直接確認できること	addr_a から addr_b へ 1.0 TEST が移動した
推定	条件やラベルから考えられること	addr_b は取引所関連アドレスとして扱われる可能性がある
注意	断定を避けるための補足	ラベルの根拠や取引目的は別途確認が必要

この3つを分けることで、読み手が「どこまでがデータから見えることなのか」「どこからが推定なのか」を意識しやすくなります。

たとえば、次のような出力を目指します。

[観察] tx001: addr_user_a -> addr_exchange_x に 1.2 TEST が移動しました。
[推定] addr_exchange_x は取引所関連アドレスとして扱われる可能性があります。
[注意] 取引所内部で誰が受け取ったかは、オンチェーン情報だけでは分かりません。

このように書くと、コードの結果を読みながらも、断定しすぎない姿勢を保てます。

💡 豆知識
本記事の学習用コードは、取引を白黒判定する「裁判官」ではなく、確認すべき場所に印を付ける 付箋 のようなものです。
条件に当てはまる取引を見つけても、その意味は追加情報や文脈と合わせて考える必要があります。

この章のまとめ

この章では、本記事でコード例を扱う場合の前提を整理しました。

コード例は、暗号資産AMLやオンチェーン分析の考え方を理解するために使います。
実在アドレスの追跡、本人特定、犯罪関与の判定、実務システムの構築を目的とするものではありません。

この章で押さえたいポイントは、次の通りです。

• コード例は、すべて架空データを使った学習用である
• Pythonの標準ライブラリを中心に、できるだけ軽く試せる形にする
• 取引履歴を、表やグラフとして見る考え方を扱う
• Red Flagやリスク条件は、追加確認の手がかりとして扱う
• コードの出力を、犯罪の断定や本人特定として扱わない
• 観察、推定、注意を分けて表示する
• 学習用コードと実務システムの違いを意識する

次の章では、ここまでの前提を踏まえて、記事全体の流れを確認します。

身近なお金の記録から出発し、AML/CFT、オンチェーン情報、取引解析、KYC、Travel Rule、最近の論点、そして誤解の整理へ、どのような順番で進むのかを見ていきます。

全体の流れ

ここまでで、この記事の前提を整理してきました。

概要では、スマホ決済履歴や銀行口座の入出金履歴のような身近なお金の記録から、暗号資産AMLの入口を見ました。
この記事の立ち位置では、派生元記事で扱ったブロックチェーン全体の話から、暗号資産AMLと取引解析 に焦点を絞ることを確認しました。

また、この記事で分かること、対象読者、扱わないこと、コードを試す場合の前提も整理しました。
ここから先は、いよいよ本文の中心に入っていきます。

ただし、暗号資産AMLは、いきなり制度名や英語の略語を並べると一気に読みづらくなります。
そこで本記事では、次のように 身近な記録から少しずつ専門的な話へ進む流れ にします。

この図だけを見ると少し項目が多く感じるかもしれません。
しかし、流れはかなりシンプルです。

まず、普段見ているお金の履歴から「記録を見る」という感覚をつかみます。
次に、AML/CFTという考え方を確認します。
そのあと、暗号資産ではどのような情報が見えるのか、オンチェーン取引解析では何を見ているのかを整理します。

後半では、取引所の本人確認、Travel Rule、Red Flag、リスクスコアリング、ミキサーやブリッジなどの論点を扱います。
最後に、よくある誤解を整理しながら、暗号資産AMLを学ぶうえで意識したいことをまとめます。

各章の役割

本記事の章構成を、ざっくり整理すると次のようになります。

章	扱うテーマ	読者に持ってほしい理解
1. 身近な「お金の履歴」から考える	銀行振込、カード明細、スマホ決済履歴など	お金の流れは記録として残り、あとから確認できる
2. AML/CFTをざっくり整理する	AML、CFT、CPF、マネー・ローンダリングの基本	AMLは「犯人探し」だけではなく、確認と記録の積み重ねである
3. 暗号資産では何が見えるのか	アドレス、トランザクション、ブロックエクスプローラー	実名ではなくアドレスが見える一方、取引履歴を確認できる場合がある
4. オンチェーン取引解析の基本	資金フロー、グラフ、クラスタリング、ラベル	取引履歴から資金の流れを追えるが、本人特定とは別である
5. アドレスと外部情報が結びつく場面	KYC、SNS、公式サイト、制裁リスト、外部ラベル	オンチェーン情報とオフチェーン情報が結びつくと見え方が変わる
6. Red Flagをどう見るか	不自然な取引パターン、高リスク接点	Red Flagは犯罪の証明ではなく、追加確認のサインである
7. 取引所・VASP・KYC・Travel Ruleの関係	事業者側の確認、送付人・受取人情報	オンチェーン情報だけでは足りない部分を制度や事業者情報が補う
8. リスクスコアリングと誤検知・過検知	スコア、アラート、確認作業	点数やアラートは便利だが、過信すると誤った判断につながる
9. ミキサー・ブリッジ・ステーブルコインなどの論点	最近のAML上の重要テーマ	技術やサービス自体を単純に悪とせず、確認が難しくなる理由を理解する
10. よくある誤解	完全匿名、何でも追跡可能、スコア万能など	二択で決めつけず、見える範囲と限界を分けて考える
11. まとめ	記事全体の振り返り	暗号資産AMLを、記録・分析・確認・限界のバランスで理解する

この構成では、最初から専門用語を詰め込まないようにします。
たとえば、VASP や Travel Rule のような言葉は、いきなり出すと分かりにくいです。
そのため、まずは「取引所のような事業者が、なぜ利用者や送金先を確認する必要があるのか」という具体例から入り、そのあとで用語を紹介します。

同じように、Red Flag や リスクスコアリング も、最初から難しい判定ロジックとして扱いません。
「普段と違う取引に付箋を貼る」「あとで確認する候補を見つける」という感覚から説明します。

1. 身近な「お金の履歴」から考える

最初の章では、銀行振込、クレジットカード明細、スマホ決済履歴、フリマアプリの取引履歴などを例にします。

たとえば、クレジットカード明細に見覚えのない請求があったら、まず確認したくなります。
銀行口座から急に高額な送金があれば、「これは自分の操作だろうか」「振込先は正しいだろうか」と気になります。

この章で伝えたいのは、次のことです。

お金の流れを確認するには、まず記録が必要です。
ただし、変わった記録があるだけで、すぐに不正と決めつけることはできません。

この感覚を押さえておくと、後で出てくる取引モニタリングやRed Flagも理解しやすくなります。

2. AML/CFTをざっくり整理する

次に、AML/CFTの基本を整理します。

AMLは Anti-Money Laundering の略で、犯罪で得たお金を正当なお金のように見せかける行為への対策を指します。
CFTは Countering the Financing of Terrorism の略で、テロ活動に資金が流れることを防ぐ取り組みです。

ただし、この章でもいきなり制度の細部には入りません。
まずは、次のような身近な感覚から考えます。

身近な場面	AML/CFTにつながる考え方
口座開設時に本人確認をする	誰がサービスを使うのかを確認する
高額な送金で追加確認が入る	取引の目的や相手先を確認する
見慣れない海外送金を確認する	国や地域、相手先のリスクを見る
不自然な取引が続くと調査される	通常の利用パターンとの違いを見る

FATFは、暗号資産や暗号資産サービス提供者に対しても、顧客管理、記録保存、疑わしい取引の報告、送付人・受取人情報の取得・保持・安全な送信などを求めています。

参考: FATF: Virtual Assets

この章では、AML/CFTを「専門部署だけが扱う遠い話」ではなく、取引履歴、本人確認、ログ監査、リスク評価とつながる話として整理します。

3. 暗号資産では何が見えるのか

AML/CFTの基本を確認した後は、暗号資産の取引では何が見えるのかを整理します。

BitcoinやEthereumのようなパブリックブロックチェーンでは、アドレス、トランザクション、金額、時刻、ブロック番号などを確認できる場合があります。
Bitcoin.orgも、Bitcoinの取引は公開され、追跡可能で、ネットワーク上に保存されると説明しています。

参考: Bitcoin.org: Protect your privacy

ただし、見える情報には注意が必要です。

見える情報	例	注意点
アドレス	0x...、Bitcoinアドレス	本人名ではない
トランザクションID	0x...、txid	取引を探す入口になる
金額・トークン	ETH、BTC、USDTなど	価格換算やトークンの種類に注意が必要
時刻	ブロックに含まれた時刻	現実の操作時刻と完全一致するとは限らない
送信元・送信先	from / to	個人、取引所、スマートコントラクトなどの場合がある

この章では、見えること と まだ分からないこと を分けて考えます。
アドレスが見えるからといって、すぐに現実の人物が分かるわけではありません。
一方で、取引履歴が公開されていれば、資金の流れをたどれる場合があります。

4. オンチェーン取引解析の基本

次に、公開された取引履歴をどのように読み解くのかを見ていきます。

オンチェーン取引解析では、アドレスを点、取引を線として見ます。
そうすると、資金がどのアドレスからどのアドレスへ移動したのかを、グラフのように整理できます。

この章では、次のような考え方を扱います。

• 資金フロー追跡
• アドレスクラスタリング
• エンティティラベリング
• 取引所入出金の見方
• グラフとして取引履歴を見る考え方
• 追跡できることと本人特定できることの違い

ここでも、強く断定しすぎないことを重視します。
たとえば、「取引所らしきアドレスへ入金された」と分かっても、その取引所内部で誰が受け取ったのかは、オンチェーン情報だけでは分かりにくい場合があります。

5. アドレスと外部情報が結びつく場面

オンチェーン情報だけでは、アドレスの意味が分からない場合があります。
そこで重要になるのが、外部情報です。

たとえば、次のような情報がアドレスと結びつくことがあります。

外部情報	アドレスとの関係	注意点
取引所情報	本人確認済みアカウントと入出金が結びつく場合がある	一般公開情報ではない
SNS	自分でアドレスを公開している場合がある	本人投稿か確認が必要
公式サイト	寄付先やプロジェクトのアドレスが掲載される	なりすましや更新に注意
制裁リスト	高リスク対象として公表される場合がある	法域や更新時期に注意
分析サービスのラベル	取引所、ミキサー、ブリッジなどの推定	根拠確認が必要

この章では、オンチェーン情報とオフチェーン情報の違いを整理します。
特に、KYC情報や取引所内部情報は、ブロックチェーン上にそのまま公開されるものではない点を丁寧に説明します。

6. Red Flagをどう見るか

次に、Red Flagを扱います。

Red Flagは、直訳すると「赤い旗」です。
ただし、暗号資産AMLでは、「犯罪確定」の印ではなく、追加確認した方がよいサイン と考える方が自然です。

FATFは、Virtual Assetsに関するRed Flagとして、匿名性を高める技術的特徴、地理的リスク、不自然な取引パターン、資金源や送付人・受取人に関する情報などを整理しています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

この章では、Red Flagを次のように扱います。

Red Flagの例	すぐに断定しない理由	追加で確認したいこと
短時間に資金が分散される	正当な分配や業務処理の可能性もある	送金目的、相手先、時系列
ミキサー関連サービスと接点がある	プライバシー目的の利用もあり得る	法域、文脈、資金の前後の流れ
高リスク法域と関係がある	地域だけで判断できない	顧客情報、取引目的、相手先
顧客情報と取引内容が合わない	情報更新漏れの可能性もある	本人確認情報、取引目的、利用状況

このように、Red Flagは結論ではなく、調査の入口として扱います。

7. 取引所・VASP・KYC・Travel Ruleの関係

Red Flagを見つけても、オンチェーン情報だけで判断できるとは限りません。
そこで関係するのが、取引所やVASP、KYC、Travel Ruleです。

VASPは、Virtual Asset Service Providerの略です。
暗号資産交換業者やカストディ事業者など、暗号資産関連サービスを提供する主体を指す言葉として使われます。

KYCは、Know Your Customerの略です。
日本語では本人確認や顧客確認として説明されることが多いです。
単に身分証を提出する一回限りの作業ではなく、利用目的や取引状況を継続的に確認する考え方にもつながります。

Travel Ruleは、暗号資産などの移転時に、送付人・受取人に関する情報を関係する事業者間で伝えるためのルールです。
日本の金融庁も、暗号資産の移転に係る通知義務、いわゆるトラベルルールに関する資料を公表しています。

参考: 金融庁: 暗号資産・電子決済手段の移転に係る通知義務（トラベルルール）

この章では、次のような流れを図で整理します。

ここで大切なのは、オンチェーン情報と事業者が持つ顧客情報は、見える範囲が違うという点です。
ブロックチェーン上の履歴を誰でも確認できる場合があっても、本人確認情報が一般公開されるわけではありません。

8. リスクスコアリングと誤検知・過検知

次に、リスクスコアリングを整理します。

リスクスコアは、取引やアドレスのリスクを数値やランクで表す考え方です。
高リスクアドレスとの距離、資金の流れ、ラベル情報、顧客属性、取引目的などを組み合わせて、追加確認の優先度を決める材料になります。

ただし、スコアは分かりやすい反面、過信しやすいという注意点もあります。

状況	誤った見方	慎重な見方
高リスクアドレスと接点がある	犯罪者である	追加確認が必要な可能性がある
ミキサー関連ラベルがある	すべて違法である	文脈と法域を確認する
取引所へ入金された	換金済みと断定する	取引所内部処理は外から見えにくい
スコアが低い	安全と断定する	未知のリスクや情報不足は残る

この章では、誤検知と過検知も扱います。

誤検知は、本来問題がない取引を問題ありとして拾ってしまうことです。
過検知は、必要以上に多くの取引を疑わしいものとして扱ってしまうことです。

セキュリティアラートと同じように、アラートが多すぎると、本当に重要なものを見逃す危険があります。
そのため、リスクスコアは便利な道具ですが、最後は文脈を確認する必要があります。

9. ミキサー・ブリッジ・ステーブルコインなどの論点

後半では、最近の暗号資産AMLで重要になりやすい論点を整理します。

ここでは、次のようなテーマを扱います。

• ミキサー
• ブリッジ
• DEX
• DeFi
• ステーブルコイン
• アンホステッドウォレット
• P2P取引
• オフショアVASP
• クロスチェーン追跡

これらは、すべてを「悪いもの」として扱うべきではありません。
たとえば、ステーブルコインは価格が比較的安定するよう設計され、決済や送金に使いやすい面があります。
アンホステッドウォレットも、自分で秘密鍵を管理するというブロックチェーンらしい使い方の一つです。

一方で、FATFは2025年の更新で、ステーブルコインや国境を越えるVASP、規制・監督の実装状況などを継続的な論点として扱っています。

参考: FATF: Targeted Update on Implementation of FATF Standards on Virtual Assets and VASPs, 2025

この章では、それぞれの技術やサービスがなぜAML上の論点になるのかを、使い方の手順ではなく、確認が難しくなる理由 に注目して整理します。

10. よくある誤解

ここまでの内容を踏まえて、よくある誤解を整理します。

誤解	実際の見方
暗号資産は完全匿名である	多くの場合、実名ではなくアドレスで動く仮名性に近い
ブロックチェーンなら何でも追跡できる	追跡できる範囲と限界がある
アドレスが分かれば本人が分かる	本人特定には外部情報や正当な手続きが必要になる場合が多い
リスクスコアが高ければ犯罪である	追加確認の手がかりであり、断定ではない
ミキサーやプライバシー技術はすべて悪い	正当なプライバシー保護の文脈もある
AMLは規制だけの話で技術とは関係ない	データ解析、ログ監査、セキュリティ運用とも関係する

暗号資産AMLは、「完全に追える」か「まったく追えない」かの二択で考えると誤解しやすいです。
見える情報、見えにくい情報、推定できる情報、追加確認が必要な情報を分けて考えることが大切です。

11. まとめ

最後に、記事全体を振り返ります。

まとめでは、次の流れで整理します。

1. 身近なお金の履歴から、記録を確認する意味を振り返る
2. AML/CFT、KYC、Travel Ruleの役割を整理する
3. オンチェーン分析の有用性を確認する
4. 取引解析には推定や限界があることを整理する
5. 誤検知、過検知、プライバシーへの配慮を確認する
6. 派生元記事「身近な記録から理解するブロックチェーンの全体像」へ自然につなげる

この記事全体を通して、最終的には次の見方を持てることを目指します。

暗号資産AMLを学ぶうえで大切なのは、「追えるか、追えないか」の二択で考えないことです。
公開された取引履歴から見えること、外部情報がなければ分からないこと、追加確認が必要なことを分けて考えることで、ブロックチェーンの透明性と限界をより正確に理解できます。

💡 豆知識
暗号資産AMLは略語が多いため、最初から用語を丸暗記しようとすると疲れやすいです。
まず全体の地図を広げてから、身近な履歴、AML/CFT、オンチェーン情報、取引解析へ順番に進むと理解しやすくなります。

次の章では、いよいよ本文の第1章として、身近な「お金の履歴」から考えていきます。
スマホ決済履歴や銀行振込履歴を例にしながら、なぜ記録があることが確認や分析の出発点になるのかを整理します。

1. 身近な「お金の履歴」から考える

この章では、暗号資産AMLに入る前に、まずスマホ決済、銀行振込、カード明細、フリマアプリの取引履歴のような身近な記録から考えます。
ポイントは、記録が残っているからこそ、あとから確認できる という感覚です。

ここまでの章では、この記事全体の立ち位置や読み進め方を整理しました。
ここからは、いよいよ本文に入っていきます。

ただし、最初から「AMLとはAnti-Money Launderingの略で……」と定義から入ると、少し遠い話に感じてしまうかもしれません。
そこで、この章では暗号資産から少し離れて、普段の生活にある お金の履歴 から考えてみます。

たとえば、スマホ決済アプリを開くと、次のような情報が並んでいます。

履歴の例	見える情報	どんな確認に使えるか
スマホ決済履歴	日時、店舗名、金額	身に覚えのない支払いがないか確認する
銀行口座の入出金履歴	入金元、振込先、金額、日時	給与、家賃、振込ミス、不審な出金を確認する
クレジットカード明細	利用店舗、利用日、請求額	不正利用や二重請求がないか確認する
フリマアプリの取引履歴	売上、購入履歴、相手、発送状況	取引トラブルや未発送を確認する
海外送金の控え	送金先、通貨、金額、手数料	送金先や金額が正しいか確認する
システムログ	操作時刻、ユーザーID、操作内容	誰がいつ何をしたかを確認する

このような履歴は、普段は「あとで見返すための記録」くらいに感じるかもしれません。
しかし、問題が起きたときには、かなり重要な手がかりになります。

たとえば、カード明細に見覚えのない請求があったとします。
そのとき、確認するのは「この請求は悪いものだ」といきなり決めつけることではありません。

まずは、次のような確認をします。

• その日に本当に買い物をしていないか
• 家族カードやサブスクリプションの支払いではないか
• 店舗名が決済代行会社名で表示されていないか
• 同じ金額が二重に請求されていないか
• 過去にも同じような請求があったか

つまり、履歴を見るときに大切なのは、変わった記録を見つけること と それをすぐ不正と断定しないこと の両方です。

この考え方は、暗号資産AMLでもとても重要になります。

1.1 記録があるから、あとから確認できる

身近な履歴から分かることは、まず「記録が残っていると、あとから確認できる」ということです。

たとえば、レシートがなければ、数日前に何を買ったかを正確に思い出すのは大変です。
でも、レシートが残っていれば、日時、店舗、金額、商品名を確認できます。

同じように、銀行口座の入出金履歴があれば、いつ、どこから、いくら入金されたかを確認できます。
スマホ決済履歴があれば、どの店舗で支払いをしたかを確認できます。

これをかなり単純化すると、履歴確認の出発点は次のようになります。

この流れは、暗号資産の取引解析にもつながります。

Bitcoin.orgは、Bitcoinの取引について、すべての取引が公開され、追跡可能で、Bitcoinネットワーク上に永続的に保存されると説明しています。
また、Bitcoinアドレスは、どこにBitcoinが割り当てられ、どこへ送られるかを定義する情報として使われると説明しています。

参考: Bitcoin.org: Protect your privacy

もちろん、すべての暗号資産やすべてのサービスで、見える情報が同じというわけではありません。
ただ、BitcoinやEthereumのようなパブリックブロックチェーンでは、取引履歴を外部から確認できる場合があります。

ここが、暗号資産AMLにおける取引解析の出発点になります。

1.2 「変わった履歴」と「不正な履歴」は同じではない

ここで、かなり大切な注意点があります。

履歴を見ていて、いつもと違う動きがあったとしても、それだけで不正とは言えません。

たとえば、銀行口座で次のような入出金があったとします。

履歴	ぱっと見た印象	あり得る正当な理由
普段より大きな入金がある	何か怪しいかもしれない	奨学金、賞与、返金、家族からの送金かもしれない
同じ相手に何回も送金している	分割送金に見える	家賃、月謝、共同購入の精算かもしれない
深夜に決済がある	不自然に見える	サブスク更新、海外サービス、予約決済かもしれない
すぐ別の口座へ送金されている	資金を動かしているように見える	生活費口座への移動、貯金用口座への振替かもしれない

このように、履歴だけを見ると気になる動きでも、文脈を確認すると正当な理由があることもあります。

暗号資産でも同じです。

たとえば、あるアドレスから複数のアドレスへ資金が分かれていたとしても、それだけで資金洗浄だとは言えません。
取引所の出金処理、ウォレットの整理、事業上の支払い、スマートコントラクトの処理など、いろいろな可能性があります。

FATFのRed Flag Indicatorsでも、取引パターン、取引金額、送付人・受取人の特徴、資金源などが疑わしい取引を見つけるための指標として整理されています。
ただし、これらはあくまで 疑わしい可能性を示すサイン であり、それだけで犯罪を断定するものではありません。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

この記事では、この考え方を大切にします。

いつもと違う履歴を見つけることは大切です。
しかし、見つけた時点では「追加確認の候補」であり、「不正の証明」ではありません。

1.3 履歴を見るときの基本ステップ

身近な履歴でも暗号資産の取引履歴でも、かなり抽象化すると、確認の流れは似ています。

1. 履歴を集める
2. 時間順に並べる
3. 誰から誰へ、何が、どれくらい動いたかを見る
4. いつもと違う動きがないか確認する
5. 気になる履歴があれば、外部情報や文脈と照らし合わせる
6. それでも分からない場合は、追加確認の対象として扱う

この流れは、ログ分析にも近いです。

たとえば、セキュリティ運用でログを見るときも、いきなり「このユーザーは攻撃者だ」と決めつけるのではありません。
まず、ログイン時刻、アクセス元、操作内容、過去の傾向、権限、他のログとの関係を見ます。

暗号資産AMLの取引解析も、考え方としてはかなり近い部分があります。

ログ分析の考え方	お金の履歴での例	暗号資産取引解析での例
時系列を見る	いつ入出金があったか	いつ取引が記録されたか
主体を見る	どの口座・カードで動いたか	どのアドレスから動いたか
相手を見る	振込先や店舗を見る	送信先アドレスやサービスを見る
量を見る	金額が普段と違わないか	送金額や頻度を見る
文脈を見る	家賃、給与、サブスクか	取引所、DeFi、ブリッジ、寄付か
断定を避ける	不正利用と決めつけない	犯罪関与と決めつけない

ここでいう「解析」は、難しいAIモデルをいきなり使うことだけではありません。
まずは、履歴を整理し、集計し、気になるところに印を付けることから始まります。

1.4 小さなデータで履歴を集計してみる

ここで、身近な履歴を題材にした小さなPythonコードを見てみます。

このコードは、実在する決済履歴や暗号資産取引ではありません。
あくまで、履歴を集計すると、利用者ごとの傾向が見えてくる ことを理解するための学習用データです。

Pythonの collections.defaultdict を使うと、同じ利用者IDごとに履歴をまとめる処理を書きやすくなります。

参考: Python公式ドキュメント: collections

# 身近な支払い履歴を集計するための学習用コードです。
# 実在する個人データ、決済履歴、暗号資産アドレスは使っていません。
# 目的は「履歴を利用者ごとにまとめると、傾向が見えてくる」ことを理解することです。

from collections import defaultdict

# 架空の支払い履歴を用意します。
# user_id は本名ではなく、アプリ内の識別子という想定です。
# category は支払い先の大まかな種類、amount は金額を表します。
records = [
    {"user_id": "user_001", "time": "08:10", "category": "駅前のカフェ", "amount": 420},
    {"user_id": "user_002", "time": "12:05", "category": "学食", "amount": 680},
    {"user_id": "user_001", "time": "12:20", "category": "大学近くのコンビニ", "amount": 530},
    {"user_id": "user_003", "time": "18:30", "category": "駅ビルの書店", "amount": 1500},
    {"user_id": "user_001", "time": "21:10", "category": "自宅近くのスーパー", "amount": 1200},
    {"user_id": "user_002", "time": "22:15", "category": "オンラインサービス", "amount": 980},
]

# user_id ごとに履歴をまとめるための入れ物を作ります。
# defaultdict(list) を使うと、初めて出てきた user_id に対しても
# 自動的に空のリストを用意できます。
records_by_user = defaultdict(list)

# 1件ずつ履歴を確認し、同じ user_id のリストへ追加します。
for record in records:
    records_by_user[record["user_id"]].append(record)

# user_id ごとに、利用回数、合計金額、利用カテゴリを集計します。
for user_id, user_records in records_by_user.items():
    # sum() で、その利用者の支払い金額を合計します。
    total_amount = sum(record["amount"] for record in user_records)

    # 支払い先カテゴリを一覧にします。
    categories = [record["category"] for record in user_records]

    print(f"識別子: {user_id}")
    print(f"  利用回数: {len(user_records)}")
    print(f"  合計金額: {total_amount}円")
    print(f"  利用カテゴリ: {categories}")
    print()

このコードでは、user_001 や user_002 のような識別子ごとに履歴をまとめています。

ここで大切なのは、コードの中に本名が出てこないことです。
本名がなくても、同じ識別子に履歴が積み重なると、利用回数、合計金額、利用カテゴリのような傾向は集計できます。

これは、暗号資産のアドレスにも通じる考え方です。
アドレスは本名ではありません。
しかし、同じアドレスに取引履歴が積み重なると、そのアドレスがどのように使われているかを観察できる場合があります。

ただし、ここでも注意が必要です。

user_001 の履歴が見えたからといって、その人の本名や意図まで分かるわけではありません。
同じように、暗号資産アドレスの履歴が見えても、そのアドレスを誰が管理しているのか、なぜ取引したのかまでは、追加情報なしに断定できません。

1.5 追加確認候補を見つける簡単なアルゴリズム

次に、少しだけアルゴリズムらしい処理を入れてみます。

ここでは、架空の支払い履歴から「追加確認した方がよさそうな履歴」を拾い上げます。
これはAMLシステムではなく、あくまで 履歴確認の考え方 を理解するための簡易モデルです。

考え方は単純です。

入力: 支払い履歴の一覧
処理:
  1. 金額が大きい履歴を確認する
  2. 深夜帯の履歴を確認する
  3. 普段あまり出ないカテゴリの履歴を確認する
  4. 条件に当てはまる理由を記録する
出力: 追加確認候補の一覧

このように、条件に当てはまる取引を拾い上げる方法は ルールベース と呼ばれることがあります。
ルールベースとは、あらかじめ決めた条件に沿って判定する方法です。

たとえば、「5万円以上なら確認する」「深夜の高額決済なら確認する」といった形です。
分かりやすい一方で、条件が単純すぎると誤検知も増えます。

# 支払い履歴から「追加確認候補」を見つける学習用コードです。
# このコードは実際の不正検知やAML判定に使うものではありません。
# 条件に当てはまった履歴を「不正」と断定せず、あくまで「確認候補」として扱います。

records = [
    {"tx_id": "pay001", "user_id": "user_001", "time": "08:10", "category": "カフェ", "amount": 420},
    {"tx_id": "pay002", "user_id": "user_001", "time": "12:20", "category": "コンビニ", "amount": 530},
    {"tx_id": "pay003", "user_id": "user_001", "time": "21:10", "category": "スーパー", "amount": 1200},
    {"tx_id": "pay004", "user_id": "user_001", "time": "02:15", "category": "海外オンラインサービス", "amount": 58000},
    {"tx_id": "pay005", "user_id": "user_002", "time": "12:05", "category": "学食", "amount": 680},
    {"tx_id": "pay006", "user_id": "user_002", "time": "23:50", "category": "オンラインサービス", "amount": 980},
]

# 説明用のしきい値です。
# 実務では、金額だけでなく、顧客属性、過去の利用傾向、取引目的なども見ます。
HIGH_AMOUNT_THRESHOLD = 50000

# 「普段使い」とみなすカテゴリを、説明用に定義します。
# ここにないカテゴリが出たら、追加確認の理由の一つにします。
COMMON_CATEGORIES = {"カフェ", "コンビニ", "スーパー", "学食", "オンラインサービス"}


def is_late_night(time_text):
    """
    時刻が深夜帯かどうかを判定する関数です。

    time_text は "02:15" のような文字列を想定しています。
    ここでは 0時〜4時台を深夜帯として扱います。
    """
    hour = int(time_text.split(":")[0])
    return 0 <= hour <= 4


def find_review_candidates(records):
    """
    支払い履歴から追加確認候補を探します。

    戻り値は、確認候補になった取引と、その理由の一覧です。
    条件に当てはまったからといって、不正と断定するわけではありません。
    """
    candidates = []

    for record in records:
        reasons = []

        # 金額が大きい場合は、確認理由として記録します。
        if record["amount"] >= HIGH_AMOUNT_THRESHOLD:
            reasons.append("金額が説明用しきい値以上")

        # 深夜帯の取引は、確認理由として記録します。
        if is_late_night(record["time"]):
            reasons.append("深夜帯の取引")

        # 普段使いとして定義したカテゴリにない場合、確認理由として記録します。
        if record["category"] not in COMMON_CATEGORIES:
            reasons.append("普段あまり見ないカテゴリ")

        # 何らかの理由がある場合だけ、追加確認候補に入れます。
        if reasons:
            candidates.append({
                "tx_id": record["tx_id"],
                "user_id": record["user_id"],
                "time": record["time"],
                "category": record["category"],
                "amount": record["amount"],
                "reasons": reasons,
            })

    return candidates


# 追加確認候補を抽出します。
review_candidates = find_review_candidates(records)

# 結果を表示します。
for candidate in review_candidates:
    print(f"追加確認候補: {candidate['tx_id']}")
    print(f"  利用者ID: {candidate['user_id']}")
    print(f"  時刻: {candidate['time']}")
    print(f"  カテゴリ: {candidate['category']}")
    print(f"  金額: {candidate['amount']}円")
    print(f"  理由: {', '.join(candidate['reasons'])}")
    print()

このコードでは、pay004 のような取引が追加確認候補として出てくるはずです。

ただし、ここで何度も強調しておきたいのは、追加確認候補 = 不正 ではないという点です。

たとえば、深夜に海外オンラインサービスで高額決済があったとしても、本人が正当に購入した可能性もあります。
海外サービスの年払い、航空券、オンライン講座、クラウドサービスの更新など、正当な理由はいくらでも考えられます。

つまり、このコードがやっているのは「不正を見つけること」ではなく、確認した方がよさそうな履歴に付箋を貼ること です。

この考え方は、後の章で扱うRed Flagやリスクスコアリングにもつながります。

1.6 暗号資産の取引履歴に置き換えるとどうなるか

ここまで見てきたのは、身近な支払い履歴です。
では、暗号資産の取引履歴に置き換えると、どのように見えるでしょうか。

かなり単純化すると、対応関係は次のようになります。

身近なお金の履歴	暗号資産取引履歴での対応イメージ	注意点
利用者ID	アドレス	アドレスは本名ではない
支払い先店舗	送信先アドレス、コントラクト、取引所アドレス	相手が誰かはラベルや外部情報が必要な場合がある
金額	送金額、トークン数量	トークン種類や価格換算に注意が必要
利用日時	ブロックに含まれた時刻	現実の操作時刻と完全一致するとは限らない
カード明細の店舗名	ブロックエクスプローラー上のラベル	ラベルの根拠や更新時期に注意が必要
不審利用の確認	Red Flagやリスク確認	犯罪の断定ではなく追加確認の手がかり

暗号資産の特徴は、パブリックブロックチェーンでは取引履歴を外部から確認できる場合があることです。
一方で、アドレスは本名ではありません。

そのため、暗号資産の取引解析では、次のような見方が必要になります。

この流れを見ると、身近な履歴確認と暗号資産AMLの距離が少し縮まります。

銀行口座やカード明細を見るときも、いきなり不正と決めつけず、まず履歴を確認します。
暗号資産でも、まず見える情報を整理し、そこから追加確認が必要なものを見つけます。

違うのは、暗号資産ではアドレス、トランザクション、ブロックエクスプローラー、VASP、KYC、Travel Ruleといった専門用語が出てくることです。
これらは後の章で順番に整理していきます。

1.7 履歴確認で大切なのは「比較」と「文脈」

履歴を見るときに大切なのは、単に1件の取引を見ることではありません。

大切なのは、いつもと比べてどうか、そして その取引がどのような文脈にあるか です。

たとえば、次のような見方があります。

見方	身近な例	暗号資産での例
時間の比較	普段は昼の決済が多いのに、深夜に高額決済がある	普段と違う時間帯に大きな移転がある
金額の比較	いつも数百円なのに、急に高額請求がある	普段より大きな送金がある
相手の比較	普段使わない海外サービスから請求がある	初めて見るアドレスやサービスへ送金している
頻度の比較	短時間に何度も決済がある	短時間に多数のトランザクションがある
経路の比較	入金後すぐ別口座へ移している	入金後すぐ複数アドレスへ分散している

ただし、比較だけでは不十分です。

たとえば、いつもより大きな送金があっても、引っ越し費用や学費、端末購入のような正当な理由があるかもしれません。
暗号資産でも、大きな資金移動があったからといって、すぐに不正とは言えません。

だからこそ、文脈が必要です。

• その取引は普段の利用傾向と比べてどうか
• 取引相手は既知のサービスか
• 送金の目的を説明できるか
• 外部情報と矛盾していないか
• 追加確認が必要な根拠は何か

このように考えると、暗号資産AMLは単なる「怪しい取引探し」ではなく、記録を丁寧に読み解く作業 に近いことが分かります。

💡 豆知識
家計簿で「今月は外食が多い」「サブスクが増えている」と気づく作業は、かなり身近な取引モニタリングに近いです。
暗号資産AMLでも、まずは履歴を集め、分類し、いつもと違う点を追加確認するところから始まります。

お金の流れは、記録として残ることがあります。
記録があるから、あとから確認できます。
ただし、記録を見ただけで、背景や意図まで断定できるわけではありません。

この感覚を持っておくと、次の章でAML/CFTという言葉が出てきても、かなり理解しやすくなります。

1.8 この章のまとめ

この章では、暗号資産AMLに入る前に、スマホ決済、銀行口座、カード明細、フリマアプリ、海外送金、システムログのような身近な履歴から考えました。

身近な履歴を見ると、次のことが分かります。

• 記録が残っていると、あとから確認できる
• 履歴を時系列で見ると、お金の流れや利用傾向が見える
• いつもと違う取引は、追加確認のきっかけになる
• ただし、いつもと違うことと不正であることは同じではない
• 履歴を見るときは、比較と文脈が大切になる
• 簡単なコードでも、履歴の集計や追加確認候補の抽出は考え方として説明できる

暗号資産の取引解析でも、出発点は似ています。
まず取引履歴を確認し、アドレス、金額、時刻、相手先、頻度、外部情報との接点を見ます。
そのうえで、気になる取引を追加確認の対象として扱います。

次の章では、この身近な履歴確認の考え方を土台にして、AML/CFTをざっくり整理する ことに進みます。
難しい規制用語としてではなく、「不正なお金の流れを見つけ、社会の中で悪用されにくくするための仕組み」として見ていきます。

2. AML/CFTをざっくり整理する

この章では、AML/CFTを「難しい規制用語」としてではなく、身近なお金の流れを確認する仕組みから整理します。
ポイントは、不自然な取引を見つけてもすぐに不正と決めつけるのではなく、本人確認、取引目的、相手先、過去の履歴などを組み合わせて追加確認することです。

前の章では、スマホ決済履歴、銀行口座の入出金履歴、カード明細、フリマアプリの取引履歴などを例にして、お金の流れは記録として残り、あとから確認できる という感覚を整理しました。

この章では、その延長として AML/CFT を見ていきます。

AML/CFTと聞くと、急に金融機関や規制当局だけの話に感じるかもしれません。
しかし、入口はそこまで遠いものではありません。

たとえば、銀行口座を開設するときに本人確認書類を提出します。
海外送金をするときに送金目的を聞かれることがあります。
普段と違う高額な取引があると、確認の連絡が来ることもあります。

これらは、利用者を困らせるためだけに行われているわけではありません。
金融サービスが犯罪収益の移動やテロ資金供与に悪用されないようにするための確認でもあります。

暗号資産AMLも、基本的にはこの考え方とつながっています。

違うのは、暗号資産では、銀行口座番号やカード番号の代わりに、アドレス、トランザクション、取引所、ウォレット、スマートコントラクト、ブリッジなどが出てくることです。
そのため、まずはAML/CFTの基本を、身近な例からざっくり整理しておきます。

2.1 まずは「いつもと違うお金の流れ」を確認する話として見る

たとえば、普段は近所のスーパーやコンビニで数百円から数千円の支払いが多い人のカード明細に、急に海外サービスへの高額決済が並んだとします。

このとき、カード会社や金融機関は、次のようなことを確認するかもしれません。

• 本当に本人が利用したのか
• いつもの利用傾向と大きく違わないか
• 取引先や国・地域にリスクはないか
• 不正利用や詐欺被害の可能性はないか
• 必要であれば、本人へ確認するか

もちろん、見慣れない海外決済があるからといって、すぐに不正とは限りません。
旅行、留学、海外通販、サブスクの年払い、仕事上の支払いなど、正当な理由はいくらでもあります。

ここで大切なのは、変わった取引を見つけること と 不正だと断定すること は違う、という点です。

AML/CFTでも同じです。

不自然に見える取引を見つけたら、まずは追加確認の対象として扱います。
そのうえで、本人確認情報、取引目的、相手先、過去の履歴、外部情報などを合わせて、リスクを判断していきます。

この図はかなり単純化していますが、AML/CFTを理解する入口としては十分です。

暗号資産AMLでも、いきなり「このアドレスは悪い」と決めつけるのではなく、まずは取引履歴や外部情報を確認し、追加確認が必要かどうかを考えます。

2.2 AML、CFT、CPFを一度整理する

ここで、よく出てくる略語を整理します。

用語	正式名称	ざっくりした意味	身近なイメージ
AML	Anti-Money Laundering	犯罪で得たお金を、正当なお金のように見せかける行為への対策	不自然な入出金や資金移動を確認する
CFT	Countering the Financing of Terrorism	テロ活動に資金が流れることを防ぐ取り組み	支援先や送金先のリスクを確認する
CPF	Countering Proliferation Financing	大量破壊兵器の拡散に関わる資金供与を防ぐ取り組み	制裁対象や高リスク取引を確認する
KYC	Know Your Customer	顧客が誰なのかを確認する手続き	口座開設時の本人確認
CDD	Customer Due Diligence	顧客確認・継続的な顧客管理	取引目的や利用状況を確認する
STR/SAR	Suspicious Transaction/Activity Report	疑わしい取引・活動の届出	追加確認の結果、当局へ報告する仕組み

本記事では、主に AML/CFT を中心に扱います。
ただし、近年の金融犯罪対策では、CPF、つまり拡散金融対策も含めて AML/CFT/CPF とまとめて語られることがあります。

FATFは、マネー・ローンダリング、テロ資金供与、拡散金融に対抗するための国際的な基準を策定する機関です。FATFのRecommendationsは、各国がマネー・ローンダリング、テロ資金供与、拡散金融に対応するための基礎となるものとして位置づけられています。

参考: FATF: The FATF Recommendations

ここで注意したいのは、AML/CFTは「怪しい人を探すための仕組み」だけではないということです。
むしろ、金融サービスが悪用されないように、利用者確認、取引確認、記録保存、届出、監督などを組み合わせてリスクを下げる取り組みです。

2.3 マネー・ローンダリングの3段階

AMLを理解するときによく出てくるのが、マネー・ローンダリングの3段階です。

国連薬物犯罪事務所、UNODCは、マネー・ローンダリングの流れを Placement、Layering、Integration の3段階で説明しています。

参考: UNODC: Money-Laundering Overview

日本語では、だいたい次のように整理できます。

段階	英語	ざっくりした意味	身近なたとえ
1	Placement	犯罪で得た資金を金融システムに入れる	現金を口座や決済サービスへ入れる
2	Layering	取引を重ねて資金の出所を分かりにくくする	複数の口座やサービスを経由させる
3	Integration	一見正当なお金として使える状態に戻す	事業収入や投資収益のように見せる

ここで特に暗号資産と関係しやすいのは、2つ目の Layering です。

暗号資産では、複数のアドレスに資金を分けたり、取引所、ブリッジ、DeFi、ステーブルコインなどを経由したりすることで、資金の流れが複雑になる場合があります。
もちろん、これらの仕組みには正当な利用もあります。
たとえば、ブリッジは異なるブロックチェーン間で資産を移動するために使われますし、ステーブルコインは価格変動を抑えた決済や送金に使われることがあります。

ただし、AML/CFTの観点では、複数の経路をまたいで資金が短時間に動く場合、資金の出所や目的を確認しにくくなることがあります。

この図を見ると、マネー・ローンダリングは単発の送金だけではなく、複数の取引が連なった流れとして考える必要があることが分かります。

前章で扱った「履歴を時系列で見る」「相手先や頻度を見る」という考え方は、この3段階を理解するうえでも役立ちます。

2.4 AML/CFTでよく見る確認ポイント

AML/CFTでは、いきなり難しいアルゴリズムだけを使うわけではありません。
基本には、顧客、取引、相手先、地域、金額、頻度などを確認する考え方があります。

たとえば、次のような観点です。

確認ポイント	身近な例	暗号資産での例
顧客情報	口座開設時の本人確認	取引所でのKYC
取引目的	海外送金の目的確認	取引目的や資金源の確認
金額	普段より高額な振込	大きな入出金や資金移動
頻度	短時間に何度も送金	短時間の多数トランザクション
相手先	初めて送る海外口座	未知アドレス、高リスクアドレス、取引所、ブリッジ
国・地域	高リスク国・地域との取引	規制が弱い法域やオフショアVASPとの接点
過去履歴	普段の利用傾向との違い	過去のオンチェーン履歴との違い

FATFは、暗号資産とVASPに対しても、リスクを理解し、顧客管理、記録保存、疑わしい取引の報告、送付人・受取人情報の取得・保持・安全な送信などを求めています。

参考: FATF: Virtual Assets

日本でも、金融庁は金融機関に対して、リスクに応じたマネロン・テロ資金供与・拡散金融対策の実効性確保と高度化を求めています。
また、金融機関利用者に対して、取引目的、資産・収入状況などについて、従来より詳しい確認を求められる場合があることも説明しています。

参考: 金融庁: 金融機関におけるマネロン・テロ資金供与・拡散金融対策について

このように、AML/CFTは「特定の取引だけを見る」ものではなく、顧客や取引の文脈を組み合わせて見る考え方です。

2.5 疑わしい取引は「怪しいから有罪」ではない

AML/CFTを学ぶときに、特に気をつけたい点があります。

それは、疑わしい取引 という言葉を、犯罪の確定と混同しないことです。

疑わしい取引とは、あくまで追加確認や届出の対象になり得る取引です。
その時点で、取引の当事者が犯罪者だと確定するわけではありません。

たとえば、次のような違いがあります。

見方	意味
取引に違和感がある	通常パターンと異なるため、追加確認したい
Red Flagに該当する	FATFなどが示す注意すべき指標に近い
疑わしい取引として届出対象になる可能性がある	法令や社内ルールに基づき、当局への届出を検討する
犯罪である	法的判断や証拠に基づいて判断される

この区別は、暗号資産AMLでは特に重要です。

オンチェーン分析で「高リスクアドレスと接点がある」「短時間に資金が分散している」「ミキサー関連サービスと関係している」と見えたとしても、それだけで犯罪関与を断定してはいけません。

FATFのRed Flag Indicatorsも、疑わしい取引を検出し報告するための指標として示されているものであり、特定の取引を犯罪と断定するためのものではありません。

参考: FATF: Virtual Assets Red Flag Indicators

この章では、以降も次の姿勢を大切にします。

Red Flagは「赤信号で即アウト」ではなく、「ここは確認した方がよい」という目印です。

2.6 暗号資産ではVASPが重要になる

暗号資産AMLでよく出てくる言葉に VASP があります。

VASPは Virtual Asset Service Provider の略です。
日本語では、暗号資産サービス提供者のように説明できます。

かなりざっくり言えば、暗号資産の交換、移転、保管、管理などに関わる事業者です。
暗号資産交換業者やカストディサービスなどをイメージすると分かりやすいです。

FATFは、暗号資産とVASPに対するAML/CFT基準の実装状況を継続的に更新しており、2025年のTargeted Updateでも、VASPの監督、Travel Rule、ステーブルコイン、越境リスクなどを重要な論点として整理しています。

参考: FATF: Targeted Update on Implementation of the FATF Standards on VAs and VASPs, 2025

ここで重要なのは、暗号資産は個人のウォレット同士でも移転できる一方、取引所やカストディのような事業者を通る場面も多いことです。

パブリックブロックチェーンでは、アドレス間の取引履歴を確認できる場合があります。
一方で、そのアドレスを誰が使っているのか、取引所の内部でどの顧客に対応するのかは、オンチェーン情報だけでは分からないことがあります。

そこで、VASPが行うKYC、取引記録、取引モニタリング、Travel Rule対応が重要になります。

2.7 Travel Ruleは「資金と一緒に情報も渡す」考え方

Travel Ruleも、暗号資産AMLでよく出てくる重要な言葉です。

Travel Ruleは、送金や暗号資産移転のときに、送付人・受取人に関する情報を関係する事業者間で伝えるためのルールです。
名前だけ見ると旅行に関係しそうですが、ここでのTravelは、資金移動と一緒に必要な情報も移動する というイメージです。

たとえば、A取引所からB取引所へ暗号資産を送るとき、ブロックチェーン上ではアドレス間の移転が見えるかもしれません。
しかし、それだけでは送付人や受取人の情報は直接分からない場合があります。

そこで、VASP間で必要な情報を通知する仕組みが関係します。

金融庁は、暗号資産や電子決済手段の取引経路を追跡可能にするため、暗号資産交換業者等に対して、移転時に送付人・受取人情報を通知する義務を設けていると説明しています。

参考: 金融庁: 暗号資産・電子決済手段の移転に係る通知義務（トラベルルール）

ここで注意したいのは、Travel Ruleは「すべての個人情報がブロックチェーン上に公開される」という意味ではないことです。
オンチェーン情報と、事業者間で扱う本人確認情報は別のレイヤーにあります。

情報	主に扱う場所	例
オンチェーン情報	ブロックチェーン上	アドレス、取引ハッシュ、金額、時刻
顧客情報	VASPなどの事業者内部	氏名、本人確認情報、顧客ID
Travel Rule情報	関係するVASP間	送付人・受取人に関する一定の情報
公開ラベル	ブロックエクスプローラーや公的リストなど	取引所アドレス、制裁対象アドレスなど

この区別を押さえておくと、「ブロックチェーンは公開されているから本人情報も全部見える」という誤解を避けられます。

2.8 簡単なルールベースでAML/CFTの確認の入口を見てみる

ここでは、AML/CFTの確認の入口を、かなり単純化したPythonコードで見てみます。

このコードは、実際の取引監視システムではありません。
実在する顧客、アドレス、取引、制裁リスト、リスク判定には使いません。

目的は、取引履歴を見て、追加確認が必要そうなものに目印を付ける という考え方を理解することです。

# AML/CFTの確認の入口を説明するための学習用コードです。
# 実在する取引やアドレスの判定には使いません。
# 目的は「変わった取引を見つけても、すぐに犯罪と断定しない」考え方を確認することです。

transactions = [
    {
        "tx_id": "tx001",
        "customer_id": "user_001",
        "amount": 12000,
        "country": "JP",
        "counterparty_type": "known_shop",
        "time": "2026-07-03 10:00",
    },
    {
        "tx_id": "tx002",
        "customer_id": "user_001",
        "amount": 950000,
        "country": "XX",
        "counterparty_type": "unknown_service",
        "time": "2026-07-03 23:40",
    },
    {
        "tx_id": "tx003",
        "customer_id": "user_002",
        "amount": 30000,
        "country": "JP",
        "counterparty_type": "known_exchange",
        "time": "2026-07-03 12:20",
    },
]

# 説明用のしきい値です。
# 実務では、金額だけでなく顧客属性、取引目的、過去履歴、法令、社内ルールなどを組み合わせます。
AMOUNT_THRESHOLD = 500000

# 説明用の高リスク国・地域コードです。
# 実務では、公式リストや社内ルールにもとづき、最新情報を管理する必要があります。
HIGH_RISK_COUNTRIES = {"XX", "YY"}

# 説明用の注意すべき相手先タイプです。
# 実務では、制裁リスト、既知ラベル、取引所情報、外部レポートなどを根拠に確認します。
RISKY_COUNTERPARTY_TYPES = {"unknown_service", "reported_scam"}


def check_transaction(tx):
    """
    1件の取引について、追加確認が必要そうな理由を返します。

    注意:
    - ここでは分かりやすさのために単純なルールだけを使っています。
    - reasons があるからといって、不正や犯罪を意味するわけではありません。
    - あくまで「確認候補に付箋を貼る」イメージです。
    """
    reasons = []

    # 金額が説明用しきい値以上の場合、確認理由に追加します。
    if tx["amount"] >= AMOUNT_THRESHOLD:
        reasons.append("金額が説明用しきい値以上")

    # 送金先や関係国が説明用の高リスク国・地域に含まれる場合、確認理由に追加します。
    if tx["country"] in HIGH_RISK_COUNTRIES:
        reasons.append("高リスク国・地域として扱う説明用コードに該当")

    # 相手先タイプが未知サービスや報告済み詐欺などに該当する場合、確認理由に追加します。
    if tx["counterparty_type"] in RISKY_COUNTERPARTY_TYPES:
        reasons.append("相手先タイプが追加確認対象")

    return reasons


# 取引ごとに確認し、理由があるものだけを追加確認候補として表示します。
for tx in transactions:
    reasons = check_transaction(tx)

    if reasons:
        print(f"追加確認候補: {tx['tx_id']} / 顧客: {tx['customer_id']}")
        for reason in reasons:
            print(f"  - 理由: {reason}")
        print("  - 注意: この結果だけで不正とは断定しません。")

このコードでは、金額、国・地域、相手先タイプを見て、追加確認候補を抽出しています。

ただし、ここで行っているのは非常に単純な確認です。
実際のAML/CFTでは、次のような情報も組み合わせます。

• 顧客の属性
• 口座開設時の本人確認情報
• 取引目的
• 普段の取引パターン
• 過去のアラート履歴
• 送金相手やサービスのリスク
• 制裁リストや公的機関の情報
• 法令や社内規程
• 担当者による追加確認

そのため、このコードの出力は「犯罪の判定」ではなく、あくまで「確認の入口」です。

2.9 もう少しだけアルゴリズム風に書くと

先ほどのコードを、処理の流れとして整理すると次のようになります。

1. 取引履歴を受け取る
2. 顧客ごとの通常パターンを確認する
3. 金額、頻度、相手先、国・地域、時間帯を見る
4. 既知の高リスク情報やRed Flagに近いか確認する
5. 追加確認候補に理由を付ける
6. ただし、検出結果だけで犯罪とは断定しない
7. 必要に応じて、人による確認、記録、届出、制限などにつなげる

この流れは、セキュリティログの監視にも少し似ています。

たとえば、深夜に管理者ログインがあったからといって、すぐに侵害とは限りません。
夜間メンテナンスかもしれませんし、本人の正当な作業かもしれません。

しかし、普段使わない国からのログイン、短時間の失敗ログイン連発、権限昇格、重要ファイルへのアクセスが重なると、追加確認が必要になります。

AML/CFTでも同じように、1つのサインだけでなく、複数の情報を組み合わせて文脈を見ます。

2.10 暗号資産AMLではオンチェーン情報とオフチェーン情報を組み合わせる

暗号資産AMLでは、ここまで説明したAML/CFTの考え方に、ブロックチェーン特有の情報が加わります。

情報の種類	例	役割
オンチェーン情報	アドレス、トランザクション、金額、時刻、ブロック番号	資金の流れを確認する
オフチェーン情報	KYC、取引所内部記録、利用者情報、IPログなど	誰が利用したか、目的は何かを確認する
外部公開情報	制裁リスト、公的機関の発表、ブロックエクスプローラーのラベル	リスクのある接点を確認する
分析情報	アドレスクラスタリング、リスクスコア、Red Flag	追加確認候補を見つける

オンチェーン情報だけでは、アドレスの持ち主や取引の意図までは分からないことがあります。
一方で、オフチェーン情報だけでは、ブロックチェーン上で資金がどこへ動いたのかを追いにくい場合があります。

そのため、暗号資産AMLでは、両方を分けて理解し、必要に応じて組み合わせることが大切です。

この図で見てほしいのは、オンチェーン分析が重要である一方で、それだけで完結しないことです。

暗号資産AMLは、ブロックチェーンの透明性を活かしつつ、KYCや取引所内部情報、外部のリスク情報と組み合わせて考える必要があります。

💡 豆知識
マネー・ローンダリングは「資金洗浄」と訳されますが、実際にはお金を物理的に洗う話ではありません。
初学者向けには、資金の出どころや流れを分かりにくくする、つまり 履歴をぼかす イメージで捉えると分かりやすいです。

暗号資産では、アドレスやトランザクションが公開される場合があります。
そのため、資金の流れを追えることがあります。
一方で、複数チェーン、取引所、ブリッジ、DeFi、ステーブルコインなどが関わると、流れの読み解きは複雑になります。

だからこそ、AML/CFTでは、履歴を一つひとつ丁寧に確認し、見えている情報と見えていない情報を分けることが大切になります。

2.11 この章のまとめ

この章では、AML/CFTを身近なお金の確認から整理しました。

AMLは、犯罪で得たお金を正当なお金のように見せかける行為への対策です。
CFTは、テロ活動に資金が流れることを防ぐ取り組みです。
近年は、拡散金融対策であるCPFも含めて、AML/CFT/CPFとして整理されることがあります。

この章で押さえたいポイントは、次の通りです。

• AML/CFTは、金融サービスが不正資金の移動に悪用されないようにする取り組み
• 入口は、本人確認、取引目的の確認、不自然な取引の追加確認などにある
• マネー・ローンダリングは、Placement、Layering、Integrationの3段階で説明されることが多い
• 暗号資産では、複数アドレス、取引所、ブリッジ、DeFi、ステーブルコインなどにより資金の流れが複雑になる場合がある
• 疑わしい取引やRed Flagは、犯罪の断定ではなく追加確認の手がかりとして扱う
• VASPは、暗号資産AMLにおけるKYC、取引記録、モニタリング、Travel Rule対応で重要な役割を持つ
• 暗号資産AMLでは、オンチェーン情報とオフチェーン情報を分けて考え、必要に応じて組み合わせる

次の章では、ここで出てきた オンチェーン情報 に注目します。

暗号資産では、アドレス、トランザクション、金額、時刻、ブロック番号など、ブロックチェーン上で確認できる情報があります。
ただし、それらは本人名や取引目的そのものではありません。

次章では、暗号資産では何が見えるのか を、アドレス、トランザクション、ブロックエクスプローラーのイメージから整理していきます。

3. 暗号資産では何が見えるのか

この章では、暗号資産の取引履歴を見ると、どのような情報を確認できるのかを整理します。
ポイントは、ブロックチェーン上で見える情報と、本人確認や取引目的のようにオンチェーンだけでは見えにくい情報を分けることです。

前の章では、AML/CFTを「不自然なお金の流れを見逃さないための確認」として整理しました。

銀行振込やカード明細では、金融機関やカード会社が、口座名義、利用者情報、加盟店情報、取引履歴などを持っています。
そのため、必要に応じて「誰が、いつ、どこへ、いくら動かしたのか」を確認しやすい構造があります。

一方で、暗号資産では少し見え方が変わります。

BitcoinやEthereumのようなパブリックブロックチェーンでは、取引履歴を外部から確認できる場合があります。
Bitcoin.orgは、Bitcoinの取引は公開され、追跡可能で、ネットワーク上に永続的に保存されると説明しています。

参考: Bitcoin.org: Protect your privacy

ただし、そこに銀行口座の名義のような実名がそのまま表示されるわけではありません。
多くの場合、外から見えるのは、0x... や bc1... のような アドレス、取引を識別する トランザクションID、金額、時刻、ブロック番号などです。

つまり、暗号資産の取引履歴では、次のような状態が起こります。

見えることが多い情報	見えにくい情報
アドレス	氏名・住所・本人確認情報
トランザクションID	取引の本当の目的
金額・数量	その資金の法的な意味づけ
送信元・送信先	アドレスを実際に操作した人物
ブロック番号・時刻	取引の背景にある会話や契約
スマートコントラクトとのやり取り	サービス内部の顧客情報

この章では、まず「ブロックチェーン上で見える情報」を一つずつ整理します。
そのうえで、見える情報からどこまで分かり、どこから先は外部情報が必要になるのかを見ていきます。

3.1 ブロックチェーンは「あとから確認できる記録」の集まり

身近な例として、銀行の入出金履歴を考えてみます。

銀行アプリを開くと、次のような情報が並んでいます。

日時	内容	金額	残高
2026-07-01 09:10	給与振込	+200,000円	250,000円
2026-07-01 18:20	家賃振込	-60,000円	190,000円
2026-07-02 12:10	カード引落	-15,000円	175,000円

このような履歴があると、「いつ」「どのような名目で」「いくら動いたか」をあとから確認できます。
ただし、この画面は基本的に本人や金融機関など、限られた関係者が見るものです。

一方で、パブリックブロックチェーンでは、取引履歴がより広く確認できる場合があります。

NISTは、ブロックチェーンを、暗号学的に署名された取引がブロックにまとめられ、前のブロックと暗号学的にリンクされる分散デジタル台帳として説明しています。

参考: NIST CSRC Glossary: blockchain

また、NISTの解説では、ブロックチェーンは取引記録を含む台帳であり、ブロックが暗号学的に結びつくことで改ざんが検知しやすくなると説明されています。

参考: NIST: Blockchain

ざっくり言えば、ブロックチェーンは あとから確認しやすい記録を、複数の参加者で共有する仕組み として見ることができます。

この「あとから確認できる」という性質が、暗号資産AMLにおけるオンチェーン分析の出発点になります。

3.2 アドレス：実名ではなく、取引に使われる識別子

暗号資産で最初によく見るのが アドレス です。

アドレスは、かなりざっくり言えば、暗号資産を送ったり受け取ったりするときの宛先です。
銀行口座番号やメールアドレスに少し似ていますが、同じものではありません。

身近なもの	似ている点	違う点
銀行口座番号	お金の送り先になる	通常は口座名義や本人確認情報と結びつく
メールアドレス	相手に送るための宛先になる	サービス登録情報やプロフィールと結びつきやすい
SNSのユーザー名	本名ではない識別子として使える	投稿内容やプロフィール情報がある
ブロックチェーンアドレス	送金先や取引主体として見える	アドレス単体では持ち主が分からないことが多い

Ethereum公式ドキュメントでは、Ethereumアカウントには、秘密鍵を持つ人が制御する外部所有アカウント、いわゆるEOAと、スマートコントラクトとしてデプロイされコードで制御されるコントラクトアカウントがあると説明されています。

参考: Ethereum Documentation: Ethereum accounts

ここで大切なのは、アドレスは本名ではない という点です。

たとえば、ブロックエクスプローラー上で次のような表示を見たとしても、これだけで現実世界の人物名が分かるわけではありません。

0xA1...9f3c から 0xB7...42c8 へ 1.2 ETH が送られた

この時点で確認できるのは、あくまで「あるアドレスから別のアドレスへ、一定量のETHが移動した」ということです。

ただし、アドレスに履歴が積み重なると、そのアドレスがどのように使われているかは見えてきます。
同じアドレスが何度も取引所へ入金している、特定のスマートコントラクトを何度も呼び出している、複数のアドレスから資金を集めている、といった行動パターンは確認できる場合があります。

3.3 トランザクション：ブロックチェーン上の「取引1件」

次に重要なのが トランザクション です。

トランザクションは、ブロックチェーン上で記録される取引や操作の単位です。
送金だけでなく、スマートコントラクトの呼び出し、トークンの転送、NFTの移動なども、トランザクションとして記録される場合があります。

Ethereum公式ドキュメントでは、トランザクションはアカウントから送られる暗号学的に署名された指示であり、Ethereumネットワークの状態を更新するものだと説明されています。
また、Ethereumのトランザクションには、from、to、signature、nonce、value、input data、gasLimit などの情報が含まれると説明されています。

参考: Ethereum Documentation: Transactions

初学者向けにざっくり整理すると、次のようになります。

項目	ざっくりした意味	AMLの観点での見方
トランザクションID	取引1件を識別する番号	調査や確認の入口になる
from	送信元アドレス	どこから資金や操作が出たかを見る
to	送信先アドレス	どこへ資金や操作が向かったかを見る
value	送られたETHなどの量	金額規模や分散・集約を見る
input data	コントラクト呼び出しなどの追加データ	単純送金ではない操作の手がかりになる
nonce	アカウントごとの取引順序に関わる値	同一アドレスからの取引順序を理解する補助になる
gas関連	処理手数料に関わる情報	混雑時期や処理コストを見る補助になる

ここで注意したいのは、トランザクションに多くの情報が含まれていても、取引の意図そのものが自然文で書かれているわけではない という点です。

たとえば、あるアドレスから取引所らしきアドレスへ送金があったとしても、それが換金目的なのか、保管目的なのか、別のサービス利用なのかは、オンチェーン情報だけでは分からない場合があります。

3.4 ブロックエクスプローラー：公開履歴を見るための検索画面

ブロックチェーンの取引履歴を確認するときによく使われるのが、ブロックエクスプローラー です。

Ethereum公式ドキュメントでは、ブロックエクスプローラーはEthereumのデータへの入口であり、ブロック、トランザクション、バリデータ、アカウント、その他のオンチェーン活動を確認できると説明されています。
また、Ethereumは設計上透明であり、ブロックエクスプローラーがその情報へアクセスするためのインターフェースを提供すると説明されています。

参考: Ethereum Documentation: Block explorers

身近な例で言うと、ブロックエクスプローラーは 公開された取引履歴を検索できる画面 に近いです。

検索できるもの	確認できること	注意点
アドレス	残高、入出金履歴、トークン保有状況など	そのまま本人名ではない
トランザクションID	送信元、送信先、金額、手数料、状態など	取引の意図までは分からない
ブロック番号	そのブロックに含まれる取引、時刻など	ブロック時刻と現実の操作時刻にはズレがあり得る
スマートコントラクト	コード、呼び出し履歴、イベントなど	コントラクトの意味を読むには追加知識が必要
トークン	発行量、転送履歴、保有者情報など	トークンの性質や発行主体は別途確認が必要

ブロックエクスプローラーがあるおかげで、ノードを自分で立てなくても、ブラウザから取引履歴を確認できます。
ただし、エクスプローラーの表示内容、ラベル、内部取引の見せ方、対応しているトークンなどはサービスによって異なる場合があります。

そのため、重要な確認では、1つの表示だけを見て強く断定するのではなく、必要に応じて複数の情報源や公式ドキュメントを確認する姿勢が大切です。

3.5 図で見る：アドレス・トランザクション・ブロックの関係

ここまでの関係を、かなり単純化して図にすると次のようになります。

この図で見えるのは、アドレス同士の資金移動です。

ただし、アドレスA、B、C、Dが誰なのかまでは、この図だけでは分かりません。
取引所、サービス、個人、スマートコントラクト、組織の管理アドレスなど、さまざまな可能性があります。

3.6 見える情報を「観察」として整理する

暗号資産AMLで大切なのは、見えた情報をいきなり犯罪や本人に結びつけないことです。

たとえば、次のような取引が見えたとします。

addr_A -> addr_B : 3.0 ETH
addr_B -> addr_C : 1.2 ETH
addr_B -> addr_D : 1.7 ETH
addr_C -> exchange_X : 1.1 ETH

ここから観察できるのは、まず「資金がこのように移動しているように見える」ということです。
exchange_X が取引所関連アドレスとしてラベル付けされている場合は、「取引所関連アドレスへ入金された可能性がある」と表現できます。

しかし、次のように断定するのは危険です。

addr_Cの利用者は犯罪者である
addr_Cは必ず換金した
addr_Aとaddr_Bは同じ人物である

見える情報、推定できること、断定に追加根拠が必要なことを分けると、次のようになります。

段階	例	扱い方
観察	addr_A から addr_B へ 3.0 ETH が移動した	ブロックチェーン上で確認できる事実として扱う
推定	exchange_X は取引所関連アドレスかもしれない	ラベルの根拠や情報源を確認する
追加確認	取引所内部で誰の入金かを確認する	KYCや事業者内部情報が関係する
判断	疑わしい取引として届出対象か検討する	法令、社内規程、人による確認が必要

この区別は、この後の章でも何度も出てきます。

3.7 Pythonで「見える情報」を整理してみる

ここでは、架空の暗号資産取引データを使って、ブロックチェーン上で見える情報を整理する小さなコードを書いてみます。

このコードは、実在アドレスの追跡や本人特定を行うものではありません。
目的は、取引履歴をアドレスごとに整理すると、入金・出金・取引相手が見えてくる という感覚をつかむことです。

# このコードは、暗号資産の取引履歴で「見える情報」を整理するための学習用コードです。
# 実在するアドレス、実際のブロックチェーンデータ、本人情報は扱いません。

from collections import defaultdict
from dataclasses import dataclass


@dataclass
class ToyTransaction:
    """架空の暗号資産取引1件を表すデータクラスです。"""

    tx_id: str          # トランザクションID。取引1件を識別するための値です。
    sender: str         # 送信元アドレスです。
    receiver: str       # 送信先アドレスです。
    amount: float       # 移動した数量です。ここでは説明用に小数で扱います。
    asset: str          # ETHやBTCなど、どの資産が動いたかを表します。
    block_number: int   # どのブロックに含まれたかを表します。
    timestamp: str      # 取引が記録された時刻のイメージです。


# 学習用の架空取引データです。
# アドレス名も短くしていますが、実際のアドレスではありません。
transactions = [
    ToyTransaction("tx001", "addr_A", "addr_B", 3.0, "ETH", 120001, "2026-07-03 09:10"),
    ToyTransaction("tx002", "addr_B", "addr_C", 1.2, "ETH", 120002, "2026-07-03 09:40"),
    ToyTransaction("tx003", "addr_B", "addr_D", 1.7, "ETH", 120003, "2026-07-03 09:45"),
    ToyTransaction("tx004", "addr_C", "exchange_X", 1.1, "ETH", 120010, "2026-07-03 10:20"),
]


# アドレスごとの入金・出金履歴をまとめるための辞書を用意します。
# defaultdict(list)を使うと、初めて出てきたアドレスにも自動で空リストを作れます。
address_activity = defaultdict(list)

for tx in transactions:
    # 送信元アドレスから見ると、この取引は「出金」です。
    address_activity[tx.sender].append({
        "direction": "out",
        "counterparty": tx.receiver,
        "amount": tx.amount,
        "asset": tx.asset,
        "tx_id": tx.tx_id,
        "block_number": tx.block_number,
        "timestamp": tx.timestamp,
    })

    # 送信先アドレスから見ると、この取引は「入金」です。
    address_activity[tx.receiver].append({
        "direction": "in",
        "counterparty": tx.sender,
        "amount": tx.amount,
        "asset": tx.asset,
        "tx_id": tx.tx_id,
        "block_number": tx.block_number,
        "timestamp": tx.timestamp,
    })


# アドレスごとの見え方を表示します。
# ここでは、本人名や取引目的ではなく、公開履歴として整理できる情報だけを出力します。
for address, activities in address_activity.items():
    print(f"\nアドレス: {address}")

    for item in activities:
        direction_label = "入金" if item["direction"] == "in" else "出金"
        print(
            f"  - {direction_label}: {item['amount']} {item['asset']} "
            f"/ 相手先: {item['counterparty']} "
            f"/ tx: {item['tx_id']} "
            f"/ block: {item['block_number']} "
            f"/ time: {item['timestamp']}"
        )

このコードでは、次の処理を行っています。

1. 架空の取引データを用意する
2. 取引1件を、送信元から見ると「出金」、送信先から見ると「入金」として整理する
3. アドレスごとに、入金・出金・相手先・金額・ブロック番号・時刻を表示する

このように整理すると、アドレス単位で「どのアドレスと、どのような取引をしているか」が見えてきます。

ただし、ここで表示しているのは、あくまで取引履歴として見える情報です。
addr_A が誰なのか、addr_B と addr_C が同じ人物なのか、exchange_X への送金が換金目的なのかは、このコードだけでは分かりません。

3.8 少しだけアルゴリズム風に整理する

先ほどのコードで行っていることを、もう少し一般化すると次のようになります。

1. 取引データを1件ずつ読む
2. 送信元アドレスに「出金」として記録する
3. 送信先アドレスに「入金」として記録する
4. アドレスごとに入出金履歴をまとめる
5. 金額、相手先、時刻、ブロック番号などを確認する
6. ただし、本人名や取引目的はオンチェーン情報だけで断定しない

これは、とても単純な整理です。
しかし、オンチェーン分析の入口としてはかなり重要です。

暗号資産の取引履歴は、見方を変えると、アドレスを点、取引を線とするグラフとして扱えます。
この考え方は、次章以降で資金の流れをたどるときに使います。

ここで見えるのは、アドレス同士のつながりです。
次章では、このつながりをもとに、資金の流れをどのように追うのかを整理していきます。

3.9 トークンやスマートコントラクトが入ると、見える情報が少し複雑になる

ここまでの説明では、単純な送金を中心に扱いました。

しかし、Ethereumのようなスマートコントラクトを使うブロックチェーンでは、取引は単純な送金だけではありません。

たとえば、次のような操作もあります。

操作の例	ブロックチェーン上で見える可能性がある情報	読み解くときの注意点
ETHの送金	from、to、value、手数料など	比較的読みやすいが、目的は分からない
ERC-20トークンの転送	トークンコントラクト、送信元、送信先、数量など	value だけでなくイベントログを見る必要がある場合がある
NFTの移転	トークンID、所有者の変化、マーケットプレイスとの接点など	NFTの意味や価格は別途確認が必要
DEXでの交換	入力トークン、出力トークン、コントラクト呼び出しなど	複数の内部処理が関わる場合がある
ブリッジ利用	送信元チェーン、送信先チェーン、ブリッジコントラクトなど	別チェーン側の履歴も見る必要がある

Ethereum公式ドキュメントでも、コントラクトアカウントに対する取引はコードを実行し、トークン転送や新しいコントラクト作成など、さまざまな動作につながる可能性があると説明されています。

参考: Ethereum Documentation: Ethereum accounts

つまり、暗号資産AMLで「取引を見る」といっても、単に from と to と金額だけを見るとは限りません。
トークン、イベントログ、スマートコントラクト、内部取引、複数チェーンの移動なども関係することがあります。

ただし、この記事では最初からすべてを細かく扱うのではなく、まずは次の基本を押さえます。

アドレス、トランザクション、金額、時刻、ブロック番号など、ブロックチェーン上で確認できる情報がある。
ただし、それは本人名や取引目的そのものではない。

この前提があると、次章の取引解析に入りやすくなります。

3.10 「見える」と「分かる」は同じではない

この章で一番大切なのは、見える情報と、分かったと言える情報を分けること です。

ブロックエクスプローラーでアドレスやトランザクションが見えると、つい「全部分かった」ように感じるかもしれません。
しかし、実際には次のような違いがあります。

見える情報	そこから言えること	まだ分からないこと
アドレス	そのアドレスが取引に関わった	そのアドレスを誰が管理しているか
送金額	どれくらいの数量が移動した	なぜその金額を送ったのか
時刻	いつごろブロックに記録された	現実世界でいつ操作したかの正確な時刻
取引所ラベル	取引所関連アドレスの可能性	取引所内のどの顧客か
スマートコントラクト呼び出し	何らかのコントラクト操作が行われた	利用者が何を意図していたか
高リスクアドレスとの接点	追加確認が必要な可能性	犯罪関与の有無

暗号資産AMLでは、この区別がとても重要です。

オンチェーン上で見える情報は、調査やリスク確認の強い手がかりになります。
しかし、それだけで本人特定や犯罪関与まで断定するのは危険です。

そのため、本記事では今後も、次の3つを分けて扱います。

💡 豆知識
ブロックエクスプローラーは、公開された取引履歴を見るための 虫眼鏡 に近いです。
細かい取引情報は見えますが、その取引の目的、本人、法的な意味、犯罪関与の有無まで自動で答えてくれるわけではありません。

この感覚を持っておくと、暗号資産AMLの取引解析を、過大評価せず、かといって軽視もしないバランスで理解しやすくなります。

3.11 この章のまとめ

この章では、暗号資産では何が見えるのかを整理しました。

BitcoinやEthereumのようなパブリックブロックチェーンでは、アドレス、トランザクションID、送信元、送信先、金額、時刻、ブロック番号、スマートコントラクトとのやり取りなどを確認できる場合があります。
ブロックエクスプローラーを使うと、こうした情報をブラウザ上で確認しやすくなります。

一方で、見える情報には限界があります。

アドレスは本名ではありません。
トランザクションは取引の事実を示しますが、取引の目的や背景までは直接示しません。
取引所関連アドレスとの接点が見えても、その内部でどの利用者に対応するのかは、オンチェーン情報だけでは分からない場合があります。

この章で押さえたいポイントは、次の通りです。

• ブロックチェーンでは、取引履歴を外部から確認できる場合がある
• アドレスは送金先や取引主体として見えるが、実名ではない
• トランザクションIDは、取引1件を確認するための入口になる
• ブロックエクスプローラーは、公開履歴を見るための検索画面に近い
• Ethereumでは、単純送金だけでなく、スマートコントラクト呼び出しやトークン転送も関係する
• 見える情報と、本人・目的・犯罪関与の判断は分けて考える必要がある
• オンチェーン情報は強い手がかりだが、最終判断には外部情報や人による確認が必要になる

次の章では、ここで見たアドレスやトランザクションを使って、取引解析の基本的な考え方 を整理します。

資金の流れを点と線で見ると、どのアドレスからどのアドレスへ資金が移動したのかを追いやすくなります。
ただし、そこでも「追えること」と「断定できること」は別です。

次章では、取引履歴をグラフとして見る考え方、資金フロー、アドレスクラスタリング、リスクスコアリングの入口を見ていきます。

4. オンチェーン取引解析の基本

この章では、暗号資産AMLでよく出てくる オンチェーン取引解析 の基本を整理します。
ポイントは、取引履歴を「アドレス同士をつなぐ線」として見て、資金の流れをたどることです。
ただし、資金の流れを追えることと、本人や犯罪関与を断定できることは同じではありません。

前の章では、暗号資産では何が見えるのかを整理しました。

BitcoinやEthereumのようなパブリックブロックチェーンでは、アドレス、トランザクションID、金額、時刻、ブロック番号、スマートコントラクトとのやり取りなどを確認できる場合があります。
一方で、それらは基本的に オンチェーン上で観察できる情報 であり、本人名や取引目的まで直接示すものではありません。

ここからは、その見える情報を使って、どのように資金の流れを整理するのかを見ていきます。

いきなり「取引解析」と言うと、少し専門的に聞こえるかもしれません。
しかし、最初の感覚としては、家計簿や銀行明細を見ながら「この入金はどこから来たのか」「この出金はどこへ行ったのか」をたどる作業に近いです。

たとえば、銀行口座の入出金履歴に次のような流れがあったとします。

Aさんから 10万円入金
    ↓
その日のうちに B口座へ 6万円送金
    ↓
さらに C口座へ 3万円送金

この履歴を見ると、「入ってきたお金が、その後どこへ動いたのか」を追いたくなります。
暗号資産のオンチェーン取引解析でも、基本的な発想はこれに近いです。

ただし、暗号資産の場合は、銀行口座名義の代わりにアドレスが見えます。
そのため、最初に見えるのは「誰が送ったか」ではなく、どのアドレスからどのアドレスへ、どの資産が、どれくらい移動したか です。

この章では、次の順番で整理します。

• 取引履歴をグラフとして見る考え方
• 資金の流れをたどる基本ステップ
• 何ホップ先まで見るかという考え方
• 分岐・集約・取引所・スマートコントラクトが入るときの注意点
• Pythonの架空データで資金フローをたどる簡単なアルゴリズム
• 解析結果を「観察」「推定」「注意」に分けて説明する方法

なお、この章で使うコードはすべて学習用です。
実在アドレスの追跡、本人特定、犯罪関与の判定、実務システムへの流用を目的としたものではありません。

4.1 まずは「点」と「線」で考える

取引履歴をたどるときは、アドレスを 点、取引を 線 として見ると分かりやすくなります。

たとえば、次のような架空の取引を考えます。

取引ID	送信元	送信先	金額
tx001	アドレスA	アドレスB	10.0
tx002	アドレスB	アドレスC	6.0
tx003	アドレスB	アドレスD	3.0
tx004	アドレスC	アドレスE	5.5

この表を図にすると、次のようになります。

この図では、アドレスAからアドレスBへ資金が移動し、その後、アドレスBからCとDへ分かれ、さらにCからEへ移動しています。

このように、取引履歴を点と線で表したものは、グラフ構造として考えられます。
ここでいうグラフは、棒グラフや円グラフではなく、点と線で関係を表すデータ構造のことです。

グラフの要素	暗号資産取引でのイメージ	身近な例
ノード	アドレス、コントラクト、サービス	口座、会員ID、SNSアカウント
エッジ	送金、トークン転送、コントラクト呼び出し	振込、支払い、メッセージのやり取り
向き	どちらからどちらへ動いたか	A口座からB口座へ振込
重み	金額、回数、頻度	送金額、利用回数
時間	いつ取引が記録されたか	明細の日付、ログの時刻

オンチェーン取引解析では、この点と線をたどることで、資金の移動経路を整理します。

ただし、ここで最初に注意したいのは、線でつながっていることと、同じ人物が管理していることは別 という点です。

アドレスAからアドレスBへ送金があったとしても、AとBが同じ人のアドレスなのか、別人同士の取引なのか、取引所やスマートコントラクトを介した処理なのかは、取引履歴だけでは断定できない場合があります。

4.2 取引解析でまず見ること

オンチェーン取引解析では、まず次のような情報を確認します。

確認する情報	何を見るか	注意点
開始点	どのアドレス・取引から調べ始めるか	被害報告、入金アドレス、既知ラベルなど、開始点の根拠が重要
入金	そのアドレスへ、どこから資金が来たか	送信元が個人・サービス・コントラクトのどれかは別途確認が必要
出金	そのアドレスから、どこへ資金が動いたか	出金先が取引所、別ウォレット、コントラクトなどの場合がある
金額	どれくらいの資産が移動したか	手数料やトークン小数点、価格換算に注意する
時刻	いつごろ記録されたか	ブロック時刻と現実世界の操作時刻は完全一致しない場合がある
資産種類	BTC、ETH、ERC-20トークンなど	同じ金額表示でも資産が違えば意味が変わる
ラベル	取引所、ミキサー、ブリッジ、DeFiなどの既知情報	ラベルは推定や外部情報を含むため、根拠確認が必要

Ethereum公式ドキュメントでは、トランザクションはアカウントから送られる暗号学的に署名された指示であり、from、to、value、input data、gasLimit などの情報を持つと説明されています。

参考: Ethereum Documentation: Transactions

また、Ethereum公式ドキュメントでは、ブロックエクスプローラーはEthereumデータへの入口であり、ブロック、トランザクション、バリデータ、アカウント、オンチェーン活動を確認できると説明されています。

参考: Ethereum Documentation: Block explorers

つまり、オンチェーン取引解析は、公開された履歴をもとに次のような問いを立てる作業です。

この資金は、どこから来たのか？
この資金は、その後どこへ動いたのか？
途中で分散・集約されているか？
既知のサービスや高リスクラベルと接点があるか？
どこまでが観察で、どこからが推定か？

4.3 資金の流れをたどる基本ステップ

資金の流れをたどるときは、いきなり複雑な分析をするのではなく、段階を分けると整理しやすくなります。

各ステップを、もう少し具体的に見ると次のようになります。

ステップ	内容	例
1. 開始点を決める	調べ始めるアドレスや取引IDを決める	被害報告に出てきた送金先アドレス
2. 直接の入出金を見る	そのアドレスに入った取引、出た取引を確認する	Aに10 ETH入り、Bへ8 ETH出た
3. 時間順に並べる	取引の前後関係を見る	入金後すぐ出金されたか、数日後か
4. グラフ化する	アドレス同士のつながりを点と線で整理する	A → B → C のように表す
5. 深さを決めて追う	何回先の送金まで見るか決める	1ホップ、2ホップ、3ホップ
6. ラベルと照合する	取引所、ミキサー、ブリッジなどの既知情報と照合する	Cが取引所関連アドレスとされる
7. 断定せずにまとめる	観察・推定・追加確認事項を分ける	「Cへ流れたことは確認できるが、Cの利用者は不明」

この流れは、セキュリティのログ分析にも少し似ています。

たとえば、不審なログインがあったときも、いきなり「攻撃者だ」と決めつけるのではなく、IPアドレス、時刻、ユーザー、操作内容、過去のログ、社内端末かどうかなどを確認します。
オンチェーン取引解析でも、同じように、見える情報を積み上げて、どこまで言えるのかを整理します。

4.4 「何ホップ先まで見るか」を決める

取引解析では、ホップ という考え方が出てくることがあります。

ホップは、資金が何回移動したかを数えるイメージです。
たとえば、アドレスAからBへ送金された場合、AからBは1ホップです。
BからCへさらに送金されれば、Aから見てCは2ホップ先です。

ホップ数を決める理由は、どこまでも追い続けると、関係が薄いアドレスまで大量に含まれてしまうからです。

たとえば、あるアドレスから取引所へ資金が入り、その後、取引所の管理アドレスから多数の利用者へ出金されたように見える場合があります。
このとき、単純に「取引所の先まで全部追う」と、多くの無関係な利用者を巻き込んでしまう可能性があります。

ホップ数	見える範囲	注意点
1ホップ	直接の送受信先	関係は近いが、それでも本人関係は断定できない
2ホップ	送受信先のさらに先	資金の流れを少し広く見られるが、文脈確認が必要
3ホップ以上	さらに広い範囲	関係が薄いアドレスやサービス内部処理を含みやすい

AML/CFTの文脈では、ホップ数だけでリスクを決めるのではなく、金額、時刻、相手先、既知ラベル、顧客情報、取引目的などを組み合わせて考える必要があります。

FATFのVirtual Assets Red Flag Indicatorsでも、疑わしい取引の検知には、取引の規模・頻度・パターン、送受信者の特徴、資金源、匿名性を高める技術やサービスの利用など、複数の観点が示されています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

つまり、ホップ数は便利な見方ですが、それだけで判断するものではありません。

4.5 分岐と集約を見る

資金フローを見るときに大切なのが、分岐 と 集約 です。

分岐は、1つのアドレスから複数のアドレスへ資金が分かれる動きです。
集約は、複数のアドレスから1つのアドレスへ資金が集まる動きです。

動き	ざっくりした意味	AML上の見方
分岐	1つの資金が複数先へ分かれる	資金分散、支払い、内部整理など複数の可能性
集約	複数先から1つに集まる	取引所入金、サービス管理、資金回収など複数の可能性
反復	同じような取引が繰り返される	自動処理、定期支払い、不自然な分割の可能性
短時間の連続移動	入金後すぐに別アドレスへ動く	正常なサービス処理か、資金移動を急いでいる可能性

ここでも、分岐や集約があるからといって、すぐに不正とは言えません。

たとえば、正当な取引所の出金処理でも、多数のアドレスへ分岐することがあります。
企業やプロジェクトの資金管理でも、複数アドレスから1つの管理アドレスへ集約することがあります。
一方で、不正資金の移動でも、資金を細かく分けたり、別アドレスへ集約したりすることがあります。

そのため、分岐や集約は 追加確認のきっかけ として扱います。

4.6 BitcoinとEthereumでは見方が少し違う

資金の流れをたどるとき、BitcoinとEthereumでは取引の見方が少し違います。

Bitcoinでは、UTXOという考え方が中心になります。
UTXOは、Unspent Transaction Outputの略で、ざっくり言えば まだ使われていない受け取り分 です。

Bitcoin Developer Guideでは、各入力は過去の出力に支払われたsatoshiを使用し、各出力は後続の入力が使うまでUTXOとして待つと説明されています。

参考: Bitcoin Developer Guide: Transactions

かなり単純化すると、Bitcoinでは「前に受け取った出力を、次の取引の入力として使う」という流れを見ます。

一方、Ethereumでは、アカウントと状態更新の考え方が中心です。
Ethereum公式ドキュメントでは、トランザクションはアカウントから送られる署名付きの指示であり、Ethereumネットワークの状態を更新すると説明されています。

参考: Ethereum Documentation: Transactions

観点	Bitcoinのイメージ	Ethereumのイメージ
基本モデル	UTXOモデル	アカウントモデル
追跡の入口	入力と出力のつながり	from、to、value、イベントログなど
たとえ	お釣りを含む現金支払いに近い	口座残高やアプリ操作に近い
注意点	複数入力やお釣りアドレスの推定に注意	スマートコントラクトやトークンイベントに注意

この違いは、取引解析にも影響します。

Bitcoinでは、どのUTXOがどの取引で使われたかを見ることが重要になります。
Ethereumでは、ETHの単純送金だけでなく、ERC-20トークン転送、NFT移転、DeFiコントラクト呼び出し、イベントログなども関係します。

ただし、初学者の段階では、次のように押さえておけば十分です。

チェーンによって取引の形は違います。
しかし、公開された履歴をもとに、資金やトークンの移動をたどるという基本的な考え方は共通しています。

4.7 スマートコントラクトが入ると「送金」だけではなくなる

Ethereumのようなスマートコントラクトを持つチェーンでは、取引解析が少し複雑になります。

なぜなら、取引は単なる送金だけではないからです。

たとえば、次のような操作もトランザクションとして現れます。

操作	何が起きるか	解析上の注意点
ERC-20トークンの転送	ETHではなくトークンが移動する	value だけでなくイベントログを見る必要がある
DEXでの交換	あるトークンを別のトークンに交換する	資産種類が途中で変わる
NFTの売買	NFTと支払い資産が動く	トークンIDやマーケットプレイスの処理を見る必要がある
ブリッジ利用	別チェーンへ資産が移動したように見える	元チェーンと先チェーンの対応関係が重要
コントラクト呼び出し	コードが実行される	取引の意味はコントラクトの仕様に依存する

Ethereum公式ドキュメントでは、スマートコントラクトはEthereumアカウントの一種であり、ユーザーアカウントはスマートコントラクトにトランザクションを送ることで、そのコントラクトに定義された関数を実行できると説明されています。

参考: Ethereum Documentation: Introduction to smart contracts

このため、Ethereum系の取引解析では、単に「AからBへETHが送られた」だけではなく、次のような情報を見る場合があります。

• どのコントラクトが呼び出されたか
• どの関数が実行された可能性があるか
• どのトークンイベントが発生したか
• トークンの種類が途中で変わっていないか
• DEX、ブリッジ、レンディングなどのサービスを経由していないか

ただし、本記事では最初からスマートコントラクト解析の細部には踏み込みません。
まずは、資金フローを点と線で見る基本を押さえます。

4.8 Pythonで資金の流れをたどってみる

ここからは、架空データを使って、資金の流れをたどる小さなコードを書いてみます。

このコードは、実際のブロックチェーンデータを取得するものではありません。
実在するアドレスや取引は使いません。
目的は、取引履歴をグラフとして整理し、開始アドレスから何ホップ先まで資金が動いたかを見る ことです。

# オンチェーン取引解析の基本を理解するための学習用コードです。
# 実在する暗号資産アドレス、実際の取引、本人情報は扱いません。
# 目的は「アドレスを点、取引を線として見て、資金の流れをたどる」ことを理解することです。

from collections import defaultdict, deque
from dataclasses import dataclass


@dataclass(frozen=True)
class ToyTransaction:
    """学習用の架空トランザクションを表すデータクラスです。"""

    tx_id: str       # 取引ID。実際のトランザクションハッシュではありません。
    sender: str      # 送信元アドレス。説明用の短い名前です。
    receiver: str    # 送信先アドレス。説明用の短い名前です。
    amount: float    # 移動した数量です。
    asset: str       # 資産の種類です。例: ETH、USDCなど。
    time: str        # 取引時刻です。説明用の文字列です。


# 架空の取引履歴を用意します。
# Address_A から入った資金が、Address_B を経由して複数先へ動く例にしています。
transactions = [
    ToyTransaction("tx001", "Address_A", "Address_B", 10.0, "ETH", "09:00"),
    ToyTransaction("tx002", "Address_B", "Address_C", 6.0, "ETH", "09:10"),
    ToyTransaction("tx003", "Address_B", "Address_D", 3.0, "ETH", "09:12"),
    ToyTransaction("tx004", "Address_C", "Address_E", 5.5, "ETH", "09:30"),
    ToyTransaction("tx005", "Address_D", "Exchange_X", 2.8, "ETH", "09:45"),
    ToyTransaction("tx006", "Address_E", "Bridge_Y", 5.0, "ETH", "10:00"),
]


# アドレスから出ていく取引をすぐ取り出せるように、辞書にまとめます。
# 例: outgoing_graph["Address_B"] には、Address_B から出ていく取引が入ります。
outgoing_graph = defaultdict(list)

for tx in transactions:
    outgoing_graph[tx.sender].append(tx)


def trace_flows(start_address, max_depth=2):
    """
    開始アドレスから、指定したホップ数まで資金の流れをたどります。

    start_address: 追跡を始める架空アドレス
    max_depth: 何ホップ先まで見るか

    注意:
    - これは幅優先探索の考え方を使った学習用コードです。
    - 実務では、手数料、トークン種類、スマートコントラクト、取引所内部処理、
      ブリッジ、ラベルの根拠など、さらに多くの情報を確認します。
    - このコードの結果は、犯罪関与や本人特定を示すものではありません。
    """

    # queueには「現在のアドレス」「現在の深さ」「そこまでの経路」を入れます。
    queue = deque([(start_address, 0, [])])

    # たどった経路を保存するリストです。
    traced_paths = []

    while queue:
        current_address, depth, path = queue.popleft()

        # 指定した深さに達したら、それ以上は追いません。
        if depth >= max_depth:
            continue

        # 現在のアドレスから出ていく取引を1件ずつ確認します。
        for tx in outgoing_graph.get(current_address, []):
            # これまでの経路に、今回の取引を追加します。
            new_path = path + [tx]
            traced_paths.append(new_path)

            # 送信先アドレスから、さらに先へ資金が動いていないか確認します。
            queue.append((tx.receiver, depth + 1, new_path))

    return traced_paths


# Address_A から2ホップ先までの資金の流れを確認します。
paths = trace_flows("Address_A", max_depth=2)

# 結果を読みやすく表示します。
for index, path in enumerate(paths, start=1):
    print(f"経路 {index}:")
    for tx in path:
        print(
            f"  {tx.tx_id}: {tx.sender} -> {tx.receiver} "
            f"({tx.amount} {tx.asset}, {tx.time})"
        )
    print()

このコードでは、Address_A から始めて、2ホップ先までの資金の流れをたどっています。

出力イメージは次のようになります。

経路 1:
  tx001: Address_A -> Address_B (10.0 ETH, 09:00)

経路 2:
  tx001: Address_A -> Address_B (10.0 ETH, 09:00)
  tx002: Address_B -> Address_C (6.0 ETH, 09:10)

経路 3:
  tx001: Address_A -> Address_B (10.0 ETH, 09:00)
  tx003: Address_B -> Address_D (3.0 ETH, 09:12)

ここで行っている処理は、とても単純です。

1. 取引履歴を用意する
2. 送信元アドレスごとに出ていく取引をまとめる
3. 開始アドレスから、1ホップずつ先へ進む
4. 指定した深さまで、経路を記録する
5. 経路を表示する

このような探索方法は、グラフをたどる基本的な考え方です。
上のコードでは deque を使って、近いところから順番に見る幅優先探索のような形にしています。

ただし、このコードはかなり単純化しています。
実際のオンチェーン分析では、同じアドレスを何度も通るループ、手数料、トークン交換、スマートコントラクト、取引所の内部台帳、ブリッジをまたぐ移動などが関係するため、より慎重な処理が必要になります。

4.9 経路にラベルを付けて読みやすくする

資金フローをたどるだけでは、まだ「長いアドレスの列」が見えるだけです。
実務上の分析では、既知の取引所、ミキサー、ブリッジ、DeFiコントラクトなどのラベルがあると、流れを読みやすくなります。

ただし、ラベルは外部情報や推定を含むため、絶対視してはいけません。
ここでは、架空のラベルを使って、どのように読み方が変わるかを見てみます。

# 経路にラベルを付けて読みやすくする学習用コードです。
# ラベルはすべて架空のものです。
# 実務では、ラベルの情報源、更新時期、根拠の強さを確認する必要があります。

# 架空のアドレスラベルを用意します。
# ここでは「取引所らしきアドレス」「ブリッジらしきアドレス」を説明用に置いています。
address_labels = {
    "Exchange_X": "取引所関連アドレスの可能性",
    "Bridge_Y": "ブリッジ関連コントラクトの可能性",
}


def get_label(address):
    """アドレスにラベルがあれば返し、なければ未ラベルとして扱います。"""
    return address_labels.get(address, "未ラベル")


def describe_path(path):
    """
    1つの経路を、観察・推定・注意に分けて説明します。

    観察: 取引データから直接確認できること
    推定: ラベルなど外部情報にもとづいて考えられること
    注意: 断定しないために補足すべきこと
    """
    observations = []
    assumptions = []
    cautions = []

    for tx in path:
        # 取引データに含まれる送信元、送信先、金額、時刻は「観察」として扱います。
        observations.append(
            f"{tx.time} に {tx.sender} から {tx.receiver} へ "
            f"{tx.amount} {tx.asset} が移動しています。"
        )

        # 送信先にラベルがある場合は、推定として扱います。
        receiver_label = get_label(tx.receiver)
        if receiver_label != "未ラベル":
            assumptions.append(
                f"{tx.receiver} は「{receiver_label}」として扱われる場合があります。"
            )

    # 分析結果を断定しすぎないための注意文を追加します。
    cautions.append(
        "この経路は資金移動の手がかりですが、アドレスの管理者や取引目的を直接示すものではありません。"
    )

    return {
        "observations": observations,
        "assumptions": assumptions,
        "cautions": cautions,
    }


# 先ほどの trace_flows 関数で得た経路を説明文に変換します。
for index, path in enumerate(paths, start=1):
    summary = describe_path(path)

    print(f"経路 {index} の整理")

    print("[観察]")
    for text in summary["observations"]:
        print(" -", text)

    print("[推定]")
    if summary["assumptions"]:
        for text in summary["assumptions"]:
            print(" -", text)
    else:
        print(" - ラベル付きアドレスとの接点は、この経路では確認していません。")

    print("[注意]")
    for text in summary["cautions"]:
        print(" -", text)

    print()

このコードでは、経路をそのまま表示するのではなく、次の3つに分けています。

区分	内容	例
観察	取引データから直接見えること	AからBへ10 ETHが移動した
推定	ラベルや外部情報から考えられること	Bは取引所関連アドレスの可能性がある
注意	断定を避けるための補足	管理者や取引目的はオンチェーンだけでは分からない

この分け方は、暗号資産AMLの記事を書くときにも大切です。

たとえば、次のような表現は慎重で読み手にも親切です。

Address_D から Exchange_X へ 2.8 ETH が移動したことは確認できます。
Exchange_X は取引所関連アドレスとして扱われる場合があります。
ただし、この取引だけで誰が取引所アカウントを利用したか、また資金の目的が何かまでは断定できません。

一方で、次のような表現は強すぎます。

Address_D の利用者は取引所で資金を換金しました。

オンチェーン上で取引所関連アドレスへの入金が見えたとしても、取引所内部で何が起きたかまでは外から見えない場合があります。
そのため、「可能性」「追加確認が必要」「オンチェーンだけでは断定できない」という表現を使う方が安全です。

4.10 金額だけではなく、時間も見る

資金フローを見るときは、金額だけでなく時間も重要です。

たとえば、入金から数分以内に複数アドレスへ分散している場合と、数か月後に通常の支払いとして動いている場合では、見え方が違います。

時間の見方	例	注意点
入金直後の出金	09:00に入金、09:05に出金	自動処理、通常の転送、不正資金移動など複数の可能性
短時間の連続移動	数分ごとに複数アドレスへ送金	資金分散の可能性はあるが、サービス処理かもしれない
長期間動かない	入金後、数か月動きがない	保管、忘却、凍結、長期保有など複数の可能性
一定周期の取引	毎週・毎月似た送金	定期支払い、自動処理、運用ルールの可能性

FATFのRed Flag Indicatorsでも、短期間に複数の取引が行われる、不自然な取引パターン、資金源や送受信者の特徴などがリスク指標として整理されています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

ただし、時間が短いから不正、長いから安全、という単純な話ではありません。

たとえば、取引所やDeFiプロトコルでは、自動処理によって短時間に多くの取引が発生することがあります。
逆に、長期間動かない資金でも、不正資金が保管されている可能性はあります。

そのため、時間は重要な手がかりですが、他の情報と組み合わせて見る必要があります。

4.11 取引所やサービスを経由すると、見える範囲が変わる

資金フローを追っていると、取引所やサービスの管理アドレスに到達することがあります。

ここで注意が必要です。

取引所に入金されたように見えるところまでは、オンチェーン上で確認できる場合があります。
しかし、取引所の内部で、どの利用者のアカウントに反映されたのか、その後どのように売買されたのか、法定通貨へ交換されたのかまでは、オンチェーン情報だけでは分からないことが多いです。

この図のように、オンチェーンで見える範囲と、取引所内部で管理される情報は別です。

そのため、記事では次のように表現するのが適切です。

断定しすぎた表現	より慎重な表現
取引所で換金された	取引所関連アドレスへ入金された可能性があります
この利用者が取引所で売却した	取引所内部の利用者や売買内容はオンチェーンだけでは分かりません
取引所に入ったので追跡終了	以後の確認には事業者情報や法的手続きが必要になる場合があります

この区別は、AML/CFTでとても重要です。
ブロックチェーンの透明性は強力ですが、すべての情報がオンチェーンに出るわけではありません。

4.12 アドレスクラスタリングは便利だが、断定ではない

取引解析では、複数のアドレスが同じ主体に関係している可能性を推定することがあります。
これを アドレスクラスタリング と呼ぶことがあります。

たとえば、BitcoinのUTXOモデルでは、1つの取引に複数の入力が使われる場合があります。
このとき、それらの入力を使うには対応する鍵が必要になるため、複数入力が同じ主体に関係している可能性がある、と考える場合があります。

ただし、これはあくまで推定です。

CoinJoinのように複数利用者が1つの取引に参加する仕組みや、取引所・ウォレットサービスの内部処理などがあるため、単純に「同じ取引に出たから同一人物」とは言えません。

クラスタリングの手がかり	推定できる可能性	注意点
複数入力が同じ取引で使われる	同じ主体が管理している可能性	共同取引やサービス処理の可能性がある
お釣りらしき出力がある	送信者側の変更アドレスの可能性	ウォレット仕様によって異なる
同じサービスと繰り返し取引する	利用サービスの傾向	サービスの共有アドレスの場合がある
似た時間・似た金額の取引が続く	自動処理や分割の可能性	偶然や正当な業務処理の可能性もある

本記事では、アドレスクラスタリングを「本人を特定する手段」としてではなく、取引履歴を整理するための推定手法 として扱います。

4.13 取引解析の結果は「調査メモ」としてまとめる

取引解析では、結果をどう書くかも大切です。

分析結果を説明するときは、次の3つを分けて書くと、断定しすぎを避けやすくなります。

たとえば、架空の分析メモとしては、次のような書き方ができます。

区分	記述例
観察	tx005 で Address_D から Exchange_X へ 2.8 ETH が移動している
推定	Exchange_X は取引所関連アドレスとして扱われる場合がある
追加確認	取引所内部でどの利用者に反映されたかは、事業者情報なしには確認できない
注意点	この取引だけで換金、本人、犯罪関与を断定することはできない

このように書くと、読者に対して「どこまでがデータで、どこからが推定なのか」が伝わりやすくなります。

暗号資産AMLでは、技術的な分析力だけでなく、分析結果を慎重に説明する力 も重要です。

💡 豆知識
取引解析は、1本の糸をたどる作業だけではありません。
資金は途中で分岐したり、集約されたり、トークン交換やブリッジによって見え方が変わったりします。
そのため、「どこへ動いたか」だけでなく「なぜ読みにくくなっているのか」を整理することも重要です。

この考え方を持っておくと、次章で扱う アドレスと外部情報の結びつき も理解しやすくなります。

4.14 この章のまとめ

この章では、オンチェーン取引解析の基本を整理しました。

暗号資産の取引履歴は、アドレスを点、取引を線として見ると、資金の流れをグラフとして捉えやすくなります。
開始アドレスや取引IDを決め、直接の入出金を確認し、時間順に並べ、必要なホップ数までたどることで、資金の移動経路を整理できます。

一方で、取引解析には限界があります。

アドレスと人は一対一とは限りません。
取引所やサービスの内部処理は、オンチェーンだけでは見えにくい場合があります。
スマートコントラクト、トークン交換、ブリッジ、アドレスクラスタリングが入ると、分析には推定が含まれます。

この章で押さえたいポイントは、次の通りです。

• オンチェーン取引解析では、アドレスを点、取引を線として見ると分かりやすい
• 資金フローは、開始点、入出金、時刻、金額、ラベルを確認しながら整理する
• ホップ数を決めることで、見る範囲を制御できる
• 分岐や集約は重要な手がかりだが、それだけで不正とは言えない
• BitcoinのUTXOモデルとEthereumのアカウントモデルでは、取引の見方が少し違う
• スマートコントラクトが入ると、単純な送金だけでなく、トークン交換やイベントログも関係する
• アドレスクラスタリングは便利だが、確定情報ではなく推定として扱う
• 解析結果は、観察、推定、追加確認、注意点に分けて書くと誤解を避けやすい

次の章では、今回見たアドレスや取引履歴が、どのように外部情報と結びつくのかを整理します。

オンチェーン上では単なる文字列に見えるアドレスでも、取引所のラベル、SNSで公開されたアドレス、公式サイトの寄付先、制裁リスト、事件資料などと結びつくと、見え方が変わります。
第5章では、この アドレスと外部情報が結びつく場面 を詳しく見ていきます。

5. アドレスと外部情報が結びつく場面

この章では、オンチェーン上ではただの文字列に見えるアドレスが、どのように外部情報と結びついて意味を持つのかを整理します。
ポイントは、ブロックチェーンだけを見て突然本人が分かるのではなく、取引所、SNS、公式サイト、名前サービス、公的リストなどの情報が重なることで、見え方が変わるという点です。

前の章では、アドレスを点、取引を線として見ながら、資金の流れをたどる考え方を整理しました。

ただし、そこまでで分かるのは、基本的には アドレス間の動き です。
Address_A から Address_B へ送金されたことや、あるアドレスから複数のアドレスへ資金が分かれたことは確認できても、それだけで「誰が操作したのか」「なぜ送金したのか」までは分からない場合があります。

ここで大切になるのが、外部情報 です。

身近な例でいうと、SNSのユーザー名に少し似ています。

music_cat_2026 というユーザー名だけを見ても、現実の人物名は分かりません。
しかし、そのプロフィールに大学名、所属サークル、ブログURL、他SNSへのリンク、イベント参加履歴などが載っていたらどうでしょうか。

ユーザー名そのものは本名ではなくても、周辺情報と結びつくことで、そのアカウントの意味がかなり具体的になります。

ブロックチェーンのアドレスも、これに近いところがあります。

アドレス単体では本名が見えなくても、次のような情報と結びつくと、見え方が変わります。

• 取引所やVASPの入出金情報
• SNSやブログに掲載された寄付アドレス
• 公式サイトに載っている決済用アドレス
• ENSのような名前付き識別子
• ブロックエクスプローラーのラベル
• OFACなど公的機関が公表する制裁関連情報
• セキュリティ企業や公的機関の事件レポート

ただし、ここでも大切なのは、結びつく可能性があること と 本人や犯罪関与を断定できること は違う、という点です。

この章では、外部情報がどのようにアドレスの意味を補うのか、そしてその情報をどう慎重に扱うべきかを整理します。

5.1 まずは「ニックネーム」と「プロフィール」の関係で考える

SNSのユーザー名だけでは、その人の本名は分からないことが多いです。

しかし、プロフィールや投稿履歴に情報が増えると、そのユーザー名は単なる文字列ではなく、文脈を持った識別子になります。

情報	それだけで分かること	結びつくと見えてくること
ユーザー名	本名ではない識別子	継続的な投稿履歴や活動傾向
プロフィール	趣味、所属、リンクなど	他サービスとのつながり
投稿履歴	時間帯、話題、交流先	生活リズムや関心分野
外部リンク	ブログ、GitHub、SNSなど	同じ人が使っている可能性がある別アカウント

ブロックチェーンのアドレスでも、似たことが起きます。

アドレスだけでは、現実世界の誰かは分かりにくいです。
しかし、そのアドレスが公式サイトやSNSに掲載されていたり、取引所関連アドレスとしてラベル付けされていたり、公的機関のリストに載っていたりすると、アドレスに文脈が付きます。

この図のように、外部情報はオンチェーン情報に文脈を与えます。

ただし、外部情報にも誤り、古さ、なりすまし、誤ラベルがあり得ます。
そのため、外部情報を見つけたときほど、情報源と根拠の強さを確認する姿勢が大切です。

5.2 オンチェーン情報と外部情報はレイヤーが違う

ここで、オンチェーン情報と外部情報を分けて整理します。

種類	例	見える範囲	注意点
オンチェーン情報	アドレス、トランザクションID、金額、時刻、送信元、送信先	パブリックチェーンでは誰でも確認できる場合がある	本人名や取引目的は直接出ないことが多い
公開された外部情報	SNS、公式サイト、寄付ページ、公開レポート	誰でも確認できる	本当に本人・公式が出した情報か確認が必要
事業者内部情報	取引所のKYC情報、入出金履歴、顧客ID	一般には見えない	事業者や当局など、権限を持つ主体が扱う
公的機関の情報	制裁リスト、注意喚起、捜査機関の発表	公開される場合がある	法域や更新時期、対象範囲を確認する必要がある
分析サービスの情報	アドレスラベル、リスクスコア、クラスタ情報	サービスにより異なる	推定や独自基準が含まれる

ブロックチェーン分析では、この複数のレイヤーを混ぜないことが重要です。

たとえば、オンチェーン上で「あるアドレスが取引所関連アドレスへ送金した」ことは確認できる場合があります。
しかし、その取引所内部でどの利用者に反映されたか、売却されたか、現金化されたかまでは、オンチェーンだけでは分からない場合があります。

FATFは、VASPに対して、顧客管理、記録保存、疑わしい取引の報告、移転時の送付人・受取人情報の取得・保持・安全な送信などを求めています。

参考: FATF: Virtual Assets

つまり、暗号資産AMLでは、オンチェーンの公開情報だけでなく、VASP側の本人確認や記録管理も重要になります。

5.3 取引所やVASPと結びつく場面

外部情報との結びつきで、特に重要なのが 取引所やVASP です。

VASPは、Virtual Asset Service Provider の略で、暗号資産の交換、移転、保管などに関わるサービス提供者を指す言葉です。
身近な例では、暗号資産取引所をイメージすると分かりやすいです。

暗号資産取引所を使う場合、多くの国や地域では、口座開設時に本人確認が求められます。
この本人確認は、KYCやCDDと呼ばれる取り組みと関係します。

オンチェーン上では、取引所の入金アドレスや出金アドレスのようなものが見える場合があります。
一方で、取引所の内部では、利用者アカウント、本人確認情報、入出金履歴、売買履歴などが管理されます。

この図のように、オンチェーンで見える範囲と、取引所内部で管理される情報は異なります。

そのため、次のような表現の違いを意識する必要があります。

断定しすぎた表現	より慎重な表現
この人が取引所で売却した	取引所関連アドレスへ入金された可能性があります
取引所に入ったので現金化された	取引所内部の売買や出金はオンチェーンだけでは分かりません
この取引所ユーザーが不正資金を受け取った	どの利用者に反映されたかは、事業者情報なしには確認できません

日本でも、暗号資産移転時に送付人・受取人情報を通知する、いわゆるトラベルルールに関する制度整備が行われています。金融庁は、暗号資産移転における送付人・受取人情報の通知について情報を公表しています。

参考: 金融庁: Notification of Originator and Beneficiary Information upon Crypto Assets Transfer

トラベルルールは、ブロックチェーン上の取引履歴だけでは足りない部分を、VASP間の情報連携で補う仕組みとして理解すると分かりやすいです。

5.4 SNSや公式サイトに載ったアドレス

次に分かりやすいのが、SNSや公式サイトでアドレスが公開されるケースです。

たとえば、次のような場面があります。

• 個人がSNSプロフィールに暗号資産アドレスを載せる
• OSSプロジェクトが寄付用アドレスを公式サイトに掲載する
• NFTプロジェクトが公式コントラクトアドレスを案内する
• 企業や団体が決済用アドレスを公開する
• ブログ記事で検証用アドレスやサンプルアドレスを紹介する

アドレスが公開されると、そのアドレスは単なる文字列ではなく、「その人・団体・プロジェクトと関係する可能性がある識別子」として見られるようになります。

ここで注意したいのは、アドレスの公開は、過去と未来の履歴にも影響することです。

ブロックチェーンの履歴は、あとから確認できる場合があります。
そのため、今日SNSで公開したアドレスが、過去にどのような取引をしていたのかまで見られる可能性があります。

Bitcoin.orgも、Bitcoinは匿名の決済ネットワークではなく、すべての取引は公開され、追跡可能で、ネットワーク上に永続的に保存されると説明しています。
また、プライバシー保護の観点から、支払いを受け取るたびに新しいBitcoinアドレスを使うことにも触れています。

参考: Bitcoin.org: Protect your privacy

ただし、SNSや公式サイトに掲載されているからといって、常に本人や公式が管理しているアドレスとは限りません。

掲載場所	手がかりとしての意味	注意点
本人のSNSプロフィール	本人の利用アドレスの可能性	アカウント乗っ取りや古い情報の可能性がある
公式サイト	団体やプロジェクトのアドレスの可能性	偽サイトや更新漏れに注意が必要
ブログ記事	検証用・学習用・寄付用などの可能性	実運用中のアドレスとは限らない
掲示板やコメント欄	参考情報になる場合がある	なりすましや誤情報の可能性が高い

外部情報を見るときは、「どこに書かれていたか」だけでなく、「誰が、いつ、どの文脈で公開したのか」を確認する必要があります。

5.5 ENSのような名前付き識別子

Ethereumでは、長い 0x... のアドレスの代わりに、人間が読みやすい名前を使う仕組みがあります。
代表例が ENS、Ethereum Name Service です。

ENSは、alice.eth のような人間が読みやすい名前を、Ethereumアドレスなどの機械が扱いやすい識別子に対応づける仕組みです。ENS公式ドキュメントでも、ENSは人間が読める名前をEthereumアドレスなどの機械可読な識別子に対応づけるものとして説明されています。

参考: ENS Documentation: What is the Ethereum Name Service?

これはとても便利です。

長いアドレスをコピーして確認するより、読みやすい名前を使える方が、人間にとって扱いやすいからです。
DNSで example.com のような名前を使う感覚に少し似ています。

観点	ENSの便利な点	注意点
送金	長いアドレスより扱いやすい	名前の入力ミスや偽名に注意が必要
表示	アドレスの用途や主体を想像しやすい	名前が本人確認済みとは限らない
開発	コントラクトやサービスを人間に分かりやすく案内できる	名前と実際の管理主体を確認する必要がある
プライバシー	自分の活動を分かりやすく整理できる	名前と履歴が結びつきやすくなる

ENSのような名前付き識別子は、利便性とプライバシーの両面を持ちます。

ここでも、名前が付いているからといって、本人や組織を完全に確認できるわけではありません。
しかし、アドレスの意味を推定する手がかりにはなります。

5.6 ブロックエクスプローラーや分析サービスのラベル

ブロックエクスプローラーやオンチェーン分析サービスでは、アドレスにラベルが付いていることがあります。

たとえば、次のような表示です。

• 取引所のホットウォレット
• DeFiプロトコルのコントラクト
• ブリッジのコントラクト
• NFTマーケットプレイス
• 詐欺関連として報告されたアドレス
• 制裁対象として公表されたアドレス

ラベルがあると、長いアドレスだけを見るよりも、取引の意味を理解しやすくなります。

ただし、ラベルはブロックチェーンそのものに最初から刻まれている「絶対的な答え」ではありません。
誰かが調査し、情報源や推定にもとづいて付けた説明です。

ラベル	便利な点	注意点
取引所ラベル	入出金先の候補を理解しやすい	内部利用者までは分からない
DeFiコントラクトラベル	コントラクトの用途を把握しやすい	コントラクトの安全性を保証するものではない
詐欺関連ラベル	追加確認のきっかけになる	接点があるだけで犯罪関与とは限らない
制裁関連ラベル	コンプライアンス上の重要な手がかりになる	最新情報や対象範囲の確認が必要

ラベルは、地図の目印に近いです。

地図に「駅」「学校」「病院」と書いてあると、場所を理解しやすくなります。
しかし、地図が古かったり、建物が移転していたりすると、実際とは違う場合があります。

アドレスラベルも同じです。
便利な手がかりですが、根拠、更新時期、情報源、文脈を確認する必要があります。

5.7 公的リストや制裁情報と結びつく場合

暗号資産AMLでは、公的機関の情報も重要です。

たとえば、米国財務省のOFACは、制裁リスト検索でデジタル通貨アドレスを検索できることを説明しています。
また、OFACのFAQでは、Sanctions List Searchを使ってデジタル通貨アドレスを検索できるとされています。

参考: OFAC: Questions on Virtual Currency

これは、アドレスが制裁対応上の識別子として扱われる場合があることを示しています。

ただし、ここでも注意が必要です。

• リストに載っているアドレスは重要な警告情報になる
• リストに載っていないから安全、とは言えない
• リストは更新されるため、投稿時点・利用時点の確認が必要
• 法的な制裁対応は専門的な確認が必要

状況	読み方
公的リストにアドレスが掲載されている	重要なリスク情報として扱う
リストに掲載されたアドレスと直接取引がある	追加確認や対応判断が必要になる可能性がある
リストにないアドレスと取引している	それだけで低リスクとは言えない
過去のリスト情報を見ている	更新状況を確認する必要がある

記事内では、制裁回避や資金移動手順を説明するのではなく、公的機関がアドレスをリスク識別子として扱う場合がある という観点に留めます。

5.8 外部情報の根拠の強さを分ける

外部情報は、すべて同じ強さではありません。

公式サイトに掲載されたアドレス、本人確認済み事業者の内部情報、公的機関のリスト、SNSの投稿、掲示板の噂では、信頼性が大きく違います。

そのため、アドレスと外部情報を結びつけるときは、根拠の強さを分けて考えると安全です。

根拠の強さ	例	扱い方
強い	公的機関の発表、公式サイト、事業者が権限を持って管理する内部情報	重要な根拠。ただし日付と対象範囲を確認する
中くらい	ブロックエクスプローラーのラベル、信頼できる調査レポート、複数資料で一致する情報	有用な手がかり。根拠や更新時期を確認する
弱い	SNSの噂、掲示板、単発のスクリーンショット	補助的な参考。断定には使わない

この考え方は、セキュリティのログ分析にも似ています。

ログ1件だけで判断するのではなく、複数のログ、時刻、通信先、端末情報、ユーザー操作、既知の攻撃情報などを組み合わせて判断します。
ブロックチェーン分析でも、オンチェーン履歴、外部ラベル、公式情報、取引所情報、時刻や金額の一致などを組み合わせて、慎重に見ていく必要があります。

5.9 Pythonで外部ラベルを付けてみる

ここでは、架空の取引データと架空の外部ラベルを使って、アドレスにラベルが付くと取引履歴の読み方が変わることを確認します。

このコードは、実在アドレスの追跡や本人特定を行うものではありません。
あくまで、オンチェーン風の履歴に外部情報を付けると、分析メモがどう変わるか を理解するための学習用コードです。

from dataclasses import dataclass
from typing import Dict, List


@dataclass
class Transaction:
    """架空のオンチェーン取引を表すデータクラスです。"""

    tx_id: str
    sender: str
    receiver: str
    amount: float
    asset: str
    time: str


@dataclass
class AddressLabel:
    """アドレスに付ける外部ラベルを表すデータクラスです。"""

    label: str
    source: str
    strength: str  # strong / medium / weak のように根拠の強さを表します。


# 架空の取引データです。
# 実在するアドレスや取引ではなく、説明のために短い名前を使っています。
transactions: List[Transaction] = [
    Transaction("tx001", "addr_user_a", "addr_exchange", 1.2, "ETH", "09:10"),
    Transaction("tx002", "addr_unknown", "addr_donation", 0.3, "ETH", "10:05"),
    Transaction("tx003", "addr_unknown", "addr_shop", 0.8, "ETH", "10:40"),
    Transaction("tx004", "addr_user_b", "addr_unknown", 0.4, "ETH", "11:20"),
]

# 架空の外部ラベルです。
# sourceには、どのような情報源から得られたラベルなのかを書いています。
# strengthは、この記事内で説明した「根拠の強さ」の簡易表現です。
address_labels: Dict[str, AddressLabel] = {
    "addr_exchange": AddressLabel(
        label="Example取引所の入出金アドレスの可能性",
        source="ブロックエクスプローラーの公開ラベル",
        strength="medium",
    ),
    "addr_donation": AddressLabel(
        label="Example Projectの寄付用アドレスの可能性",
        source="プロジェクト公式サイトに掲載されたアドレス",
        strength="strong",
    ),
    "addr_shop": AddressLabel(
        label="Example Shopの決済用アドレスの可能性",
        source="公式サイトの決済案内ページ",
        strength="strong",
    ),
}


def get_label(address: str) -> AddressLabel:
    """
    アドレスに外部ラベルがある場合はそのラベルを返します。
    ラベルがない場合は、未ラベルのアドレスとして扱います。
    """

    return address_labels.get(
        address,
        AddressLabel(
            label="未ラベルのアドレス",
            source="外部情報なし",
            strength="unknown",
        ),
    )


def build_analysis_notes(transactions: List[Transaction]) -> List[str]:
    """
    取引ごとに、観察できることと外部ラベルにもとづく推定を分けて文章化します。
    断定しすぎない表現にすることを意識しています。
    """

    notes: List[str] = []

    for tx in transactions:
        receiver_label = get_label(tx.receiver)

        # まず、取引データから直接確認できる内容を「観察」として書きます。
        notes.append(
            f"[観察] {tx.tx_id}: {tx.sender} から {tx.receiver} へ "
            f"{tx.amount} {tx.asset} が移動した記録があります。"
        )

        # 次に、外部ラベルがある場合だけ「推定」として補足します。
        if receiver_label.strength != "unknown":
            notes.append(
                f"[推定] 送信先 {tx.receiver} は「{receiver_label.label}」として扱われる場合があります。"
                f" 情報源: {receiver_label.source} / 根拠の強さ: {receiver_label.strength}。"
            )

        # 最後に、断定できない範囲を明記します。
        notes.append(
            "[注意] この情報だけで、本人、取引目的、犯罪関与を断定することはできません。"
        )

    return notes


for note in build_analysis_notes(transactions):
    print(note)

このコードでは、次の流れを確認しています。

1. 架空の取引データを用意する
2. アドレスに外部ラベルを付ける
3. 取引から直接分かることを「観察」として書く
4. ラベルから考えられることを「推定」として書く
5. 断定できないことを「注意」として書く

ポイントは、ラベルが付いたからといって、いきなり断定しないことです。

たとえば、addr_exchange に取引所関連ラベルが付いていたとしても、それは「取引所関連アドレスの可能性」を示す手がかりです。
その取引所内で誰のアカウントに反映されたのか、売買されたのか、出金されたのかまでは、このコードやオンチェーン情報だけでは分かりません。

5.10 もう少し実務メモ風に整理する

先ほどのコードで出したような結果は、実際の記事やレポートでは、次のように整理すると読みやすくなります。

区分	記述例
観察	tx001 で addr_user_a から addr_exchange へ 1.2 ETH が移動している
外部情報	addr_exchange はブロックエクスプローラー上で取引所関連アドレスとしてラベル付けされている
推定	取引所関連アドレスへ入金された可能性がある
追加確認	取引所内部の利用者、売買、出金履歴は事業者情報なしには確認できない
注意点	この取引だけで換金、本人、犯罪関与を断定しない

この書き方にしておくと、読者が「どこまでがデータで、どこからが推定なのか」を追いやすくなります。

暗号資産AMLでは、技術的に追えることも大切ですが、追えた結果をどう表現するか も同じくらい大切です。

5.11 外部情報と結びつくほど、プライバシーリスクも上がる

外部情報は、調査やAML/CFTに役立ちます。
一方で、利用者のプライバシーという観点では注意も必要です。

たとえば、ある人がSNSで自分のアドレスを公開したとします。
そのアドレスを長く使っていた場合、過去の取引履歴や今後の入出金が、そのSNSアカウントと結びついて見られる可能性があります。

行動	便利な点	プライバシー上の注意点
SNSにアドレスを載せる	支援や送金を受け取りやすい	過去・将来の履歴と結びつく可能性がある
ENS名を使う	人に伝えやすい	名前と取引履歴が結びつきやすい
1つのアドレスを長く使う	管理が楽	行動パターンが見えやすくなる
公式寄付アドレスを公開する	支援を受けやすい	入金者や出金先が見える場合がある

ここで誤解しないようにしたいのは、プライバシーへの配慮と不正利用は同じではない、という点です。

利用者が自分のプライバシーを守りたいと考えることは自然です。
一方で、AML/CFTでは、不正資金の流れや制裁対象との接点を確認する必要があります。

この2つのバランスが、暗号資産AMLを難しくしている部分です。

💡 豆知識
アドレスは、最初から本名が書かれた名札ではありません。
しかし、SNS、公式サイト、取引所ラベル、ENS、公的リストなどに登場すると、あとから名札が付くことがあります。
名札が付くと、現在の取引だけでなく過去の履歴の見え方まで変わる場合があります。

ブロックチェーンの透明性は、不正資金の追跡に役立つ一方で、利用者のプライバシーにも影響します。
この両面を意識することが、暗号資産AMLでは大切です。

5.12 この章のまとめ

この章では、アドレスと外部情報が結びつく場面を整理しました。

オンチェーン上では、アドレスは本名ではなく文字列として見えます。
しかし、そのアドレスが取引所、SNS、公式サイト、ENS、ブロックエクスプローラーのラベル、公的リストなどと結びつくと、アドレスの意味が具体的になる場合があります。

この章で押さえたいポイントは、次の通りです。

• オンチェーン情報だけで本人が必ず分かるわけではない
• 外部情報が加わると、アドレスの用途や主体を推定しやすくなる
• 取引所やVASPの情報は、KYCやTravel Ruleの文脈で重要になる
• SNSや公式サイトに掲載されたアドレスは、過去・将来の履歴と結びつく可能性がある
• ENSのような名前付き識別子は便利だが、プライバシー上の手がかりにもなる
• ブロックエクスプローラーや分析サービスのラベルは便利だが、根拠や更新時期を確認する必要がある
• 公的リストや制裁情報は重要なリスク情報だが、法的判断には専門的な確認が必要になる
• 外部情報は、根拠の強さを分けて扱うと断定しすぎを避けやすい

次の章では、ここまで整理したオンチェーン情報と外部情報をもとに、AML/CFTでよく使われる Red Flag を見ていきます。

Red Flagは、直訳すると「赤い旗」ですが、暗号資産AMLでは「この取引は少し詳しく確認した方がよいかもしれない」という目印のようなものです。
第6章では、Red Flagを犯罪の断定ではなく、追加確認のサインとして整理していきます。

---

6. Red Flagをどう見るか

この章では、暗号資産AMLでよく出てくる Red Flag を整理します。
ポイントは、Red Flagを「犯罪の証明」ではなく、追加確認が必要かもしれないサイン として扱うことです。

前の章では、アドレスが外部情報と結びつく場面を見ました。

オンチェーン上ではただの文字列に見えていたアドレスも、取引所ラベル、SNSで公開された情報、公式サイト、ENS、公的リストなどと結びつくことで、少しずつ意味を持ち始めます。

では、その情報を使ってAML/CFTでは何を見るのでしょうか。

ここで出てくるのが Red Flag です。

Red Flagを直訳すると「赤い旗」です。
ただ、暗号資産AMLでのRed Flagは、「この取引は不正確定です」という印ではありません。

どちらかというと、カード明細を見ていて「この支払い、少し確認した方がよさそう」と感じる目印に近いです。

たとえば、普段は国内で少額の買い物しかしていないカードで、急に海外の高額決済が連続したら、カード会社から確認が入ることがあります。
このとき、海外決済があるからといって、すぐに不正とは限りません。旅行中かもしれませんし、本人が正しく使っただけかもしれません。

しかし、普段と違う動きなので、いったん確認した方が安全です。

暗号資産AMLのRed Flagも、まずはこの感覚で捉えると分かりやすいです。

この図で大切なのは、Red Flagの後にすぐ「犯罪」とは進んでいない点です。

Red Flagは、あくまで 確認の入口 です。
その先で、取引目的、顧客情報、資金源、サービスの利用状況、法令や社内ルールなどと照らし合わせて判断します。

FATFは、Virtual Assetsに関するRed Flag Indicatorsを公表しており、100件を超えるケーススタディをもとに、疑わしい取引の検知に役立つ指標を整理しています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

また、金融庁もマネロン等対策の一環として、金融機関の利用時に取引目的や資産・収入の状況などについて確認を求められる場合があると説明しています。
これは、利用者を疑うためだけではなく、マネー・ローンダリングやテロ資金供与を防ぎ、利用者の預金や資産を守るための取り組みとして位置づけられています。

参考: 金融庁: 金融機関におけるマネロン・テロ資金供与・拡散金融対策について

6.1 Red Flagは「1つ見つかったらアウト」ではない

まず押さえたいのは、Red Flagは単独で結論を出すものではない、という点です。

身近な例で考えてみます。

身近な場面	Red Flagに近いサイン	すぐに断定しない理由
カード明細	普段より高額な支払いがある	旅行、家電購入、引っ越し準備かもしれない
銀行振込	短期間に複数の送金がある	家族への送金、イベント集金、事業上の支払いかもしれない
フリマアプリ	同じ相手と何度も取引している	常連取引やまとめ買いの可能性がある
システムログ	深夜にログインがある	夜間作業、保守対応、時差のある利用かもしれない
暗号資産取引	短時間に複数アドレスへ資金が分かれる	正当な分配、ウォレット整理、サービス内部処理の可能性がある

ここでのポイントは、普段と違うこと と 不正であること は同じではない、ということです。

AML/CFTでは、不自然に見える取引をきっかけに追加確認を行います。
しかし、その確認の結果、正当な理由が分かることもあります。

そのため、本記事ではRed Flagを次のように扱います。

扱い方	説明
観察	取引履歴や外部情報から確認できる特徴
Red Flag	追加確認が必要かもしれないサイン
推定	複数の情報から考えられる可能性
判断	顧客情報、取引目的、社内規程、法令なども踏まえた対応

この4つを分けておくと、オンチェーン分析の結果を過大評価しにくくなります。

6.2 FATFが示すRed Flagの主な観点

FATFのRed Flag Indicatorsでは、暗号資産に関する疑わしい取引を検知するための観点として、匿名性を高める技術的特徴、地理的リスク、不自然な取引パターン、取引規模、送付人・受取人の特徴、資金源・富の源泉などが挙げられています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

初学者向けに整理すると、次のようになります。

FATFが挙げる観点	暗号資産でのイメージ	読むときの注意点
匿名性を高める技術的特徴	ミキサー、タンブラー、匿名性を高めるサービスや暗号資産との接点	プライバシー保護の正当な目的もあるため、利用だけで犯罪と断定しない
地理的リスク	規制や監督が弱い国・地域のVASPとの接点	国・地域だけで一律に判断せず、事業者や取引文脈も見る
取引パターン	短時間の連続送金、資金の分散・集約、不自然な反復	サービス内部処理や正当な資金移動でも似た形になる場合がある
取引規模・頻度	合理的な説明が難しい大きな金額や頻度	顧客属性や普段の取引傾向と比べて見る必要がある
送付人・受取人の特徴	顧客情報と取引内容が合わない、説明が一貫しない	本人確認情報や取引目的の確認が必要になる
資金源・富の源泉	資金の出所が説明しにくい、既知の高リスク資金と接点がある	オンチェーンだけでは分からないため、外部情報との照合が必要

この表を見ると、Red Flagは「アドレスだけを見る」ものではないことが分かります。

金額、頻度、時間、取引相手、利用サービス、顧客属性、資金源、国・地域、外部ラベルなど、複数の情報を合わせて見ます。

このように、Red Flagは単独の判定ルールというより、複数の観点を重ねて「どこを詳しく見るべきか」を決めるための道具です。

6.3 取引パターンを見る：分散・集約・短時間の連続取引

暗号資産のRed Flagで分かりやすいのが、取引パターンです。

たとえば、あるアドレスに資金が入った直後、すぐに多数のアドレスへ分かれて送金される場合があります。
また、逆に、多数のアドレスから1つのアドレスへ資金が集まる場合もあります。

このような分散や集約は、追加確認のきっかけになる場合があります。

ただし、これだけで不正とは言えません。

パターン	追加確認したくなる理由	正当な理由の例
1つのアドレスから多数のアドレスへ分散	資金の流れを細かく分けているように見える	報酬支払い、エアドロップ、ウォレット整理、サービスの出金処理
多数のアドレスから1つに集約	資金をまとめているように見える	取引所入金、事業売上の集約、ガス代節約のための整理
短時間に連続取引がある	自動化や急いだ資金移動に見える	ボット運用、DeFi利用、マーケットメイク、システム処理
金額が少しずつ分かれている	閾値回避のように見える場合がある	少額決済、分割支払い、手数料・残高調整

ここで重要なのは、形だけを見るのではなく、文脈を見る ことです。

オンチェーン上で分散・集約が見えても、それがサービスの通常処理なのか、利用者の正当な操作なのか、不正資金の移転なのかは、追加情報がないと判断しにくい場合があります。

6.4 匿名性を高めるサービスや機能との接点を見る

FATFのRed Flagでは、匿名性を高める技術的特徴も重要な観点として挙げられています。
たとえば、ミキサーやタンブラー、P2P交換、匿名性を高める暗号資産などが例として示されています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

ここは、説明の仕方に注意が必要です。

プライバシーを守りたいという考え自体は、必ずしも不正ではありません。
寄付、給与、事業上の取引、個人の資産管理など、公開されすぎると困る情報はたくさんあります。

一方で、犯罪収益の出所を見えにくくする目的で匿名性を高めるサービスが悪用されることもあります。

そのため、本記事では次のように整理します。

観点	説明
正当なプライバシー保護	自分の資産状況や行動履歴をむやみに公開したくないという自然なニーズ
AML上のリスク	不正資金の流れや制裁対象との接点を見えにくくする目的で悪用される可能性
この記事での扱い	仕組みや利用手順ではなく、AML上の論点として扱う

つまり、「プライバシー技術 = 悪」とは書きません。
しかし、AML/CFTの観点では、資金の流れを確認しにくくする要素として注意が必要になる場合があります。

このバランスを崩さないことが、暗号資産AMLの記事ではとても大切です。

6.5 地理的リスクとVASPの監督状況を見る

暗号資産は国境を越えて移転しやすいという特徴があります。

FATFは2025年のTargeted Updateで、Virtual Assetsは本質的に国境を越える性質を持つため、ある法域で規制が不十分だと世界的な影響が生じ得ると説明しています。
また、VASPのライセンス・登録、監督、オフショアVASPリスクへの対応などが継続課題であることも示しています。

参考: FATF: Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs, 2025

ここでいう地理的リスクは、「特定の国や地域だから必ず危険」という単純な話ではありません。

見るべきなのは、次のような点です。

観点	確認したいこと
VASPの登録・監督	その事業者がどの法域で登録・監督されているか
AML/CFT体制	顧客確認、取引モニタリング、疑わしい取引報告の体制があるか
Travel Rule対応	送付人・受取人情報の通知・取得に対応しているか
オフショア利用	どの国の利用者に、どの国の事業者がサービスを提供しているか
制裁・公的リストとの接点	OFACなどの公的リストと関係する情報があるか

金融庁も、FATFによるトラベル・ルール監督のベストプラクティス公表について紹介しており、トラベル・ルールを含む暗号資産に係るFATF基準のグローバルな実施促進が重要な論点であることを示しています。

参考: 金融庁: FATFによる「トラベル・ルールの監督におけるベスト・プラクティス」の公表について

6.6 Red Flagは組み合わせて見る

Red Flagは、1つだけを見るよりも、複数のサインが重なっているかを見る方が自然です。

たとえば、次の2つを比べてみます。

ケース	見方
少額の送金が1回だけある	それだけで追加確認が必要とは限らない
高リスクラベル付きアドレスから資金を受け取り、すぐに複数アドレスへ分散し、その一部が取引所関連アドレスへ入金されている	複数の観点が重なるため、詳しく確認したくなる

このように、Red Flagは 足し算 に近いです。

1つだけなら弱い手がかりでも、複数の観点が同じ方向を示すと、追加確認の優先度が上がることがあります。

ただし、ここでも「スコアが高い = 犯罪」とは言えません。
あくまで、確認の優先順位が上がるという話です。

6.7 PythonでRed Flagの見方を簡単に試す

ここでは、架空の取引データを使って、Red Flagに近い特徴を抽出する簡単なコードを書いてみます。

このコードは、実際の取引監視システムではありません。
実在アドレスの追跡、本人特定、犯罪判定、制裁対応には使えません。

目的は、Red Flagは複数の観点を組み合わせて追加確認候補を出すもの という感覚をつかむことです。

# Red Flagの考え方を学ぶための簡易コードです。
# 実在する暗号資産取引、アドレス、個人、組織とは関係ありません。
# 犯罪判定や実務のAMLシステムにそのまま使うものではありません。

from dataclasses import dataclass
from typing import List


@dataclass
class ToyTransaction:
    """学習用の架空取引データを表すクラスです。"""

    tx_id: str
    sender: str
    receiver: str
    amount: float
    asset: str
    minutes_after_previous: int
    receiver_label: str
    source_of_funds: str


# 架空の取引データを用意します。
# receiver_label は、外部ラベルのイメージです。
# source_of_funds は、資金源に関する説明があるかどうかを単純化しています。
transactions = [
    ToyTransaction(
        tx_id="tx001",
        sender="addr_user_1",
        receiver="addr_friend",
        amount=0.05,
        asset="BTC",
        minutes_after_previous=1440,
        receiver_label="通常の個人アドレスとして扱う",
        source_of_funds="給与から購入したと説明あり",
    ),
    ToyTransaction(
        tx_id="tx002",
        sender="addr_user_2",
        receiver="addr_high_risk_service",
        amount=8.0,
        asset="ETH",
        minutes_after_previous=3,
        receiver_label="高リスクサービス関連の可能性",
        source_of_funds="説明なし",
    ),
    ToyTransaction(
        tx_id="tx003",
        sender="addr_user_2",
        receiver="addr_exchange",
        amount=7.8,
        asset="ETH",
        minutes_after_previous=4,
        receiver_label="取引所関連アドレスの可能性",
        source_of_funds="説明なし",
    ),
    ToyTransaction(
        tx_id="tx004",
        sender="addr_business",
        receiver="addr_supplier",
        amount=3.2,
        asset="USDC",
        minutes_after_previous=10080,
        receiver_label="取引先支払い用アドレスとして説明あり",
        source_of_funds="事業売上として説明あり",
    ),
]


def find_red_flags(tx: ToyTransaction) -> List[str]:
    """
    1件の取引について、追加確認したい特徴を探します。

    注意:
    - ここで返すのは「犯罪の判定」ではありません。
    - あくまで、追加確認候補にするための学習用ルールです。
    - 実務では、顧客属性、過去取引、法令、社内規程、最新のリスク情報などを合わせて判断します。
    """
    flags = []

    # 金額が大きい取引は、利用者の通常パターンと合っているか確認したくなります。
    # ここでは説明用に 5.0 以上を目安にしています。
    if tx.amount >= 5.0:
        flags.append("金額が説明用しきい値以上")

    # 直前の取引から短時間で連続している場合、資金移動の流れを確認したくなります。
    # ただし、自動処理や正当なサービス利用でも短時間の取引は起こり得ます。
    if tx.minutes_after_previous <= 5:
        flags.append("短時間に連続した取引")

    # 外部ラベルに高リスクを示す言葉が含まれる場合、追加確認の対象になり得ます。
    # ラベルの正確性や更新時期も別途確認が必要です。
    if "高リスク" in tx.receiver_label:
        flags.append("高リスクラベルとの接点")

    # 資金源の説明がない場合、顧客情報や取引目的と照らして確認が必要になる場合があります。
    if tx.source_of_funds == "説明なし":
        flags.append("資金源の説明が不足")

    return flags


def build_review_notes(transactions: List[ToyTransaction]) -> List[str]:
    """
    取引ごとに、Red Flagに近い特徴を人間が読めるメモにします。
    """
    notes = []

    for tx in transactions:
        flags = find_red_flags(tx)

        # まず、取引から観察できる内容を出します。
        notes.append(
            f"[観察] {tx.tx_id}: {tx.sender} から {tx.receiver} へ "
            f"{tx.amount} {tx.asset} が移動した記録があります。"
        )

        # Red Flagがある場合は、犯罪判定ではなく追加確認候補として書きます。
        if flags:
            notes.append(
                f"[追加確認候補] {tx.tx_id}: " + "、".join(flags)
            )
            notes.append(
                "[注意] これらの特徴だけで不正や犯罪関与を断定することはできません。"
            )
        else:
            notes.append(
                f"[通常確認] {tx.tx_id}: この簡易ルールでは大きな追加確認サインは見つかりません。"
            )

    return notes


for note in build_review_notes(transactions):
    print(note)

このコードでは、次の4つの観点で架空取引を見ています。

1. 金額が大きいか
2. 短時間に連続しているか
3. 高リスクラベルと接点があるか
4. 資金源の説明が不足しているか

ただし、コード内にも書いたように、これはあくまで学習用です。

実務では、顧客の通常取引パターン、本人確認情報、取引目的、資金源、取引相手、利用サービス、国・地域、制裁情報、過去のアラート、社内規程など、多くの情報を合わせて判断します。

この章で見てほしいのは、スコアやフラグを出す処理そのものではなく、出力結果を断定として扱わない書き方 です。

6.8 出力結果は「観察・追加確認・注意」に分ける

上のコードのように、Red Flagを扱うときは、出力を次のように分けると分かりやすくなります。

区分	書き方の例	意味
観察	addr_A から addr_B へ 8.0 ETH が移動している	取引履歴から確認できる事実
追加確認候補	高額、短時間の連続取引、高リスクラベルとの接点がある	詳しく見るべきサイン
注意	この情報だけで不正や犯罪関与は断定できない	分析の限界を明記する

この書き方は、Qiita記事としても大切です。

「このアドレスは怪しいです」と書いてしまうと、読者は犯罪の断定のように受け取ってしまうかもしれません。
一方で、「この取引には追加確認したい特徴があります」と書けば、分析結果の位置づけがかなり明確になります。

断定しすぎた表現	より安全な表現
この取引はマネーロンダリングです	この取引はRed Flagに近い特徴があり、追加確認の対象になり得ます
このアドレスは犯罪者です	このアドレスは高リスクラベルと接点があるため、文脈確認が必要です
ミキサーを使っているので不正です	匿名性を高めるサービスとの接点は、AML上の確認ポイントになり得ます
取引所へ入ったので換金されました	取引所関連アドレスへ入金された可能性がありますが、内部処理は外部から断定しにくいです

このように、Red Flagの章では、技術的な検出だけでなく、表現の慎重さ も重要になります。

6.9 誤検知と見逃しもある

Red Flagを使うときには、誤検知と見逃しの両方に注意が必要です。

誤検知は、本当は問題のない取引を、追加確認が必要そうだと判定してしまうことです。
見逃しは、本当は注意が必要な取引を、通常の取引として見逃してしまうことです。

種類	例	問題
誤検知	正当な事業支払いなのに高額という理由だけで強く疑う	利用者に過度な負担をかける可能性がある
見逃し	少額に分かれた不自然な連続取引を通常取引として見逃す	不正資金の流れを見落とす可能性がある

このバランスはとても難しいです。

Red Flagを厳しくしすぎると、正当な利用者まで止めてしまう可能性があります。
逆に、ゆるくしすぎると、不正な取引を見逃す可能性があります。

そのため、AML/CFTでは、Red Flagだけでなく、リスクベース・アプローチ、継続的な顧客管理、取引モニタリング、社内レビューなどが組み合わされます。

FATFの2025年Targeted Updateでも、Virtual AssetsとVASPに対するAML/CFT措置の実装、監督、Travel Rule、国境を越えたリスクへの対応が引き続き課題として扱われています。

参考: FATF: Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs, 2025

💡 豆知識
Red Flagは「ここで危険確定」という赤信号ではなく、確認した方がよい箇所に貼る 付箋 と考えると分かりやすいです。
付箋があるから間違いとは限りませんが、「あとでここをもう一度確認しよう」という目印になります。

6.10 この章のまとめ

この章では、暗号資産AMLにおけるRed Flagの見方を整理しました。

Red Flagは、犯罪の証明ではありません。
オンチェーン情報、外部ラベル、取引パターン、顧客情報、資金源などを見たときに、「ここは追加確認した方がよいかもしれない」と気づくためのサインです。

この章で押さえたいポイントは、次の通りです。

• Red Flagは「不正確定」ではなく、追加確認の入口である
• FATFは、匿名性を高める技術的特徴、地理的リスク、取引パターン、取引規模、送付人・受取人の特徴、資金源などを主な観点として整理している
• 分散・集約・短時間の連続取引は確認ポイントになり得るが、正当な理由がある場合もある
• ミキサーや匿名性を高める技術は、プライバシー保護とAML上のリスクの両面から見る必要がある
• Red Flagは1つだけで判断せず、複数の観点が重なっているかを見る
• Pythonコードでフラグを出せても、それは犯罪判定ではなく追加確認候補である
• 誤検知と見逃しの両方に注意する必要がある
• 分析結果は「観察」「追加確認候補」「注意」に分けて書くと、断定しすぎを避けやすい

次の章では、Red Flagを見つけた後に重要になる 取引所・VASP・KYC・Travel Ruleの関係 を整理します。

オンチェーン上で見えるのは、主にアドレスや取引履歴です。
しかし、AML/CFTでは、それだけでは足りない場面があります。

第7章では、取引所などのVASPがどのように本人確認や情報通知に関わるのかを、KYCとTravel Ruleの観点から見ていきます。

---

7. 取引所・VASP・KYC・Travel Ruleの関係

この章では、Red Flagを見つけた後に重要になる、取引所・VASP・KYC・Travel Ruleの関係を整理します。
ポイントは、オンチェーン上の取引履歴だけでは見えない本人確認情報や送付人・受取人情報を、事業者側の確認や制度が補う場面があるという点です。

前の章では、Red Flagを 犯罪の断定ではなく、追加確認が必要かもしれないサイン として整理しました。

たとえば、短時間に資金が分散されている、既知の高リスクアドレスと接点がある、取引の規模や頻度が普段と大きく違う、といった動きは、追加確認のきっかけになります。

ただし、ここで大きな問題があります。

オンチェーン上で見えるのは、基本的にはアドレス、トランザクションID、金額、時刻、トークンの種類、スマートコントラクトとのやり取りなどです。
一方で、そのアドレスを誰が使っているのか、どのような目的で送金したのか、取引所の内部でどの利用者に紐づいているのかは、ブロックチェーン上の情報だけでは分からないことがあります。

身近な例でいうと、レシートを見れば「いつ、どの店で、いくら支払ったか」は分かります。
しかし、それだけで「誰が買ったのか」「なぜ買ったのか」「本人が使ったのか、誰かに頼まれたのか」までは分かりません。

暗号資産AMLでも同じです。

オンチェーン分析は、資金の流れを見るための強力な手がかりになります。
しかし、本人確認や取引目的の確認、事業者間の情報連携が必要になる場面では、取引所やVASP、KYC、Travel Ruleの考え方が重要になります。

この章では、次の流れで整理します。

この図で見てほしいのは、オンチェーン分析がすべてを完結させるわけではないことです。
ブロックチェーン上で見える情報と、取引所などの事業者が持つ情報は、役割が違います。

7.1 VASPとは何か

まず、VASPという言葉から整理します。

VASPは、Virtual Asset Service Provider の略です。
日本語では「暗号資産サービス提供者」のように説明されることがあります。

かなりざっくり言えば、暗号資産の交換、移転、保管、管理などに関わる事業者を指す言葉です。
日本の文脈では、暗号資産交換業者をイメージすると入口として分かりやすいです。

FATFは、Virtual Assetsのページで、暗号資産をデジタルに取引・移転・支払い利用できる価値のデジタル表現として説明し、各国に対してVASPの登録・免許、監督、顧客管理、記録保存、疑わしい取引報告、送付人・受取人情報の取得・保持・安全な送信などを求めています。

参考: FATF: Virtual Assets

VASPの例を、かなり単純化して整理すると次のようになります。

種類	ざっくりした役割	AML/CFTで関係すること
暗号資産交換業者	暗号資産の売買や交換を提供する	口座開設時の本人確認、入出金監視、疑わしい取引の確認
カストディ事業者	利用者の暗号資産や秘密鍵管理を支援する	利用者資産の管理、本人確認、送付先確認
暗号資産の移転サービス	暗号資産の送付や受取を支援する	送付人・受取人情報の確認、Travel Rule対応
一部の仲介・管理サービス	暗号資産取引を仲介・管理する	サービス内容に応じた顧客管理やリスク管理

ここで注意したいのは、暗号資産に関係するものすべてが自動的にVASPになるわけではない という点です。

たとえば、自分で秘密鍵を管理するウォレットアプリ、単なるブロックチェーン閲覧ツール、技術的なノード運用などは、事業内容や法域によって扱いが変わります。
そのため、この記事では法的な該当性を細かく判断するのではなく、AML/CFT上の役割を理解するために、取引所などの事業者を中心に考えます。

7.2 KYCは「身分証を出す作業」だけではない

次に、KYCです。

KYCは、Know Your Customer の略です。
日本語では「本人確認」や「顧客確認」と説明されることが多いです。

暗号資産取引所で口座を開設するときに、氏名、住所、生年月日、本人確認書類、取引目的などを入力した経験がある人もいるかもしれません。
このような確認は、KYCの一部として考えると分かりやすいです。

ただし、KYCは「最初に身分証を提出して終わり」というものではありません。
AML/CFTの文脈では、顧客がどのような目的でサービスを使うのか、通常どのくらいの取引をするのか、普段の利用状況と大きく違う動きがないか、といった継続的な確認にもつながります。

金融庁のマネロン等対策ページでも、金融機関等が取引目的や職業、事業内容、資産・収入状況などについて確認する場合があることが説明されています。

参考: 金融庁: 金融機関におけるマネロン・テロ資金供与・拡散金融対策について

KYCや顧客管理を、身近な場面に置き換えると次のようになります。

身近な場面	何を確認しているか	暗号資産AMLでのイメージ
銀行口座を開設する	氏名、住所、本人確認書類、利用目的	取引所口座の開設時確認
高額送金を行う	送金目的、送金相手、資金の性質	普段と違う大口出金の追加確認
クレジットカードで不自然な利用がある	本人利用か、不正利用か	顧客の通常パターンと違う取引の確認
法人取引を始める	事業内容、実質的支配者、資金の流れ	法人顧客のリスク確認

ここで大切なのは、KYCは「利用者を疑うためだけの手続き」ではないという点です。

不正利用やなりすまし、詐欺、犯罪収益の移転を防ぐためには、誰がどのような目的で取引しているのかを確認する必要があります。
利用者側から見ると少し面倒に感じることもありますが、サービス全体の安全性や、被害拡大の防止にも関係する仕組みです。

7.3 オンチェーン情報とKYC情報は見える範囲が違う

ここで、オンチェーン情報とKYC情報の違いを整理しておきます。

ブロックチェーン上の取引履歴は、パブリックチェーンであれば誰でも確認できる場合があります。
一方で、取引所が持つ本人確認情報は、一般公開されるものではありません。

情報の種類	主に誰が見られるか	例	注意点
オンチェーン情報	誰でも確認できる場合がある	アドレス、取引ハッシュ、金額、時刻、ブロック番号	本人名や取引目的は直接見えにくい
取引所のKYC情報	取引所などの事業者、権限を持つ当局など	氏名、住所、生年月日、本人確認書類、顧客ID	一般公開情報ではない
取引所内部の入出金情報	取引所などの事業者	どの顧客口座からどのアドレスへ出金したか	オンチェーンだけでは内部利用者まで見えにくい
Travel Rule関連情報	関係するVASPなど	送付人・受取人に関する一定の情報	法域や制度により要件が異なる

たとえば、オンチェーン上で次のような取引が見えたとします。

0xAAA...111 から 0xEXC...999 へ 2.5 ETH が送られた

このとき、0xEXC...999 が取引所関連アドレスだと分かる場合があります。
しかし、オンチェーン情報だけでは、その取引所の内部でどの利用者アカウントに紐づいたのかまでは分かりません。

この図のように、オンチェーン上では取引所関連アドレスまで見えても、取引所の内部台帳は別のレイヤーにあります。

そのため、オンチェーン分析では「取引所関連アドレスへ入金された可能性がある」とまでは言えても、「誰が換金した」とまでは一般に断定できません。
この違いを分けておくことが、暗号資産AMLを正確に理解するうえで重要です。

7.4 Travel Ruleは「送金に情報を添える」考え方

次に、Travel Ruleを見ていきます。

Travel Ruleは、暗号資産などの移転時に、送付人・受取人に関する情報を関係する事業者間で通知するためのルールです。
名前だけ見ると旅行に関係しそうですが、ここでのTravelは「情報が資金移動と一緒に移動する」というイメージで考えると分かりやすいです。

金融庁は、FATF基準が暗号資産の移転に伴う送付人・受取人情報の取得・通知を求めていることを踏まえ、暗号資産交換業者に対するトラベルルール対応を公表しています。

参考: 金融庁: Notification of Originator and Beneficiary Information upon Crypto Assets Transfer

また、金融庁の資料では、暗号資産・電子決済手段の取引経路を追跡可能にするため、移転時に送付人・受取人情報を通知する義務が整理されています。

参考: 金融庁: 暗号資産・電子決済手段の移転に係る通知義務（トラベルルール）

身近な例でいうと、Travel Ruleは荷物の送り状に少し似ています。

荷物を送るときには、送り主、受取人、住所、連絡先などを書きます。
荷物そのものだけが移動するのではなく、誰から誰へ送ったのかという情報も一緒に扱われます。

暗号資産でも、オンチェーン上ではアドレス間の移転が見える場合があります。
しかし、それだけでは送付人や受取人の本人情報までは分かりにくいです。
そこで、VASP間で必要な情報を通知・保持することで、取引経路の確認をしやすくする考え方がTravel Ruleです。

この図で重要なのは、オンチェーン移転と、VASP間の情報通知は別のレイヤーにあるという点です。

ブロックチェーン上では、アドレスからアドレスへ資金が移動します。
一方で、Travel Ruleでは、送付人・受取人に関する情報をVASP間で扱います。

つまり、Travel Ruleは「ブロックチェーン上に全員の個人情報を書き込む仕組み」ではありません。
むしろ、プライバシーや情報管理に配慮しながら、必要な事業者間で情報を連携する仕組みとして理解する方が自然です。

7.5 VASP間送金とアンホステッドウォレットの違い

Travel Ruleを理解するときに、もう一つ重要なのが、相手先がVASPなのか、アンホステッドウォレットなのかという違いです。

アンホステッドウォレットは、ざっくり言えば、取引所などの事業者ではなく、利用者自身が秘密鍵を管理するウォレットです。
自己管理ウォレット、セルフカストディウォレットと呼ばれることもあります。

このようなウォレットは、ブロックチェーンの基本的な使い方の一つでもあります。
そのため、アンホステッドウォレットを使うこと自体を悪いものとして扱うのは適切ではありません。

一方で、AML/CFTの観点では、取引相手がVASPでない場合、事業者間で送付人・受取人情報を通知する仕組みがそのまま使いにくいことがあります。

金融庁のトラベルルール関連資料でも、アンホステッド・ウォレット等との取引について、所有者情報の収集・保存やマネロンリスク評価が論点として整理されています。

参考: 金融庁: 暗号資産・電子決済手段の移転に係る通知義務（トラベルルール）

違いを表にすると、次のようになります。

送付先の種類	イメージ	AML/CFT上の見方	注意点
VASP管理の口座・アドレス	取引所などの事業者を通じた送受信	事業者間で情報通知や確認が行われる場合がある	法域や対応状況によって異なる
アンホステッドウォレット	利用者自身が秘密鍵を管理するウォレット	事業者間通知がそのまま使いにくい場合がある	利用自体を不正と決めつけない
無登録業者・対応外法域のサービス	規制や通知義務の対象外の可能性があるサービス	リスク評価上の確認ポイントになる場合がある	実態確認が難しいことがある
スマートコントラクト	DeFiやブリッジなどのコントラクト	相手が人ではなくコードの場合がある	管理主体や利用者を単純に判断しにくい

ここでも大切なのは、単純化しすぎないことです。

アンホステッドウォレットだから危険、VASPだから安全、という二択ではありません。
どのような取引相手なのか、どのような資金の流れなのか、顧客の通常パターンと合っているのかを合わせて見る必要があります。

7.6 KYCとTravel Ruleはオンチェーン分析を補う

ここまでを整理すると、KYCとTravel Ruleは、オンチェーン分析の弱点を補う役割を持つと考えられます。

オンチェーン分析では、アドレス間の資金移動を確認できます。
しかし、アドレスの背後にいる人、取引目的、事業者内部の顧客情報までは見えにくいです。

KYCは、利用者が誰なのか、どのような目的でサービスを使うのかを確認するための仕組みです。
Travel Ruleは、暗号資産の移転時に、送付人・受取人情報を関係するVASP間で連携するための仕組みです。

このように、暗号資産AMLでは、オンチェーン分析、KYC、Travel Ruleを別々に見るのではなく、組み合わせて考えることが大切です。

ただし、組み合わせるといっても、すべての情報が誰にでも見えるわけではありません。
オンチェーン情報は公開される場合がありますが、KYC情報やTravel Rule情報は、個人情報や機微な情報を含むため、適切な権限と管理のもとで扱われます。

7.7 学習用コード：オンチェーン情報とKYC確認状況を分けて扱う

ここで、オンチェーン情報とKYC確認状況を分けて扱う考え方を、架空データで見てみます。

次のコードは、実際の取引所システムやTravel Rule対応システムではありません。
実在するアドレス、個人情報、取引所情報は使っていません。
あくまで、オンチェーンで見える取引情報 と 事業者側で管理する確認情報 を分けて考えるための学習用コードです。

# このコードは、暗号資産AMLにおける情報のレイヤーを理解するための学習用です。
# 実在するアドレス、本人確認情報、取引所情報は使っていません。
# 実務システム、本人特定、犯罪判定にそのまま使うものではありません。

from dataclasses import dataclass
from typing import Optional


@dataclass
class OnChainTransfer:
    """オンチェーン上で見える架空の移転情報を表すデータクラスです。"""
    tx_id: str
    from_address: str
    to_address: str
    asset: str
    amount: float


@dataclass
class CustomerProfile:
    """VASP側で管理している架空の顧客確認情報を表すデータクラスです。"""
    customer_id: str
    kyc_status: str          # 例: verified / pending / rejected
    expected_purpose: str    # 例: investment / payment / business
    usual_amount_limit: float


@dataclass
class TransferReview:
    """取引確認の結果を、観察・確認情報・注意点に分けて表すデータクラスです。"""
    tx_id: str
    observation: str
    kyc_context: str
    notes: list[str]


# 架空のオンチェーン移転データです。
# ここに含まれるのは、ブロックチェーン上で確認できる想定の情報だけです。
transfer = OnChainTransfer(
    tx_id="tx_001",
    from_address="addr_user_001",
    to_address="addr_vasp_B",
    asset="ETH",
    amount=12.5,
)

# 架空の顧客確認情報です。
# 実際の氏名や住所などは扱わず、確認状況や通常想定される取引規模だけを置いています。
customer = CustomerProfile(
    customer_id="customer_001",
    kyc_status="verified",
    expected_purpose="investment",
    usual_amount_limit=5.0,
)


def review_transfer(transfer: OnChainTransfer, customer: Optional[CustomerProfile]) -> TransferReview:
    """
    オンチェーン情報とKYC確認状況を分けて、追加確認の観点を整理します。

    注意:
    - この関数は、犯罪判定を行うものではありません。
    - 金額しきい値も説明用の仮の値です。
    - 実務では、法令、社内規程、顧客属性、過去取引、リスクスコアなどを総合的に確認します。
    """
    notes = []

    # まず、オンチェーン上で観察できる内容を文章化します。
    observation = (
        f"{transfer.from_address} から {transfer.to_address} へ "
        f"{transfer.amount} {transfer.asset} が移転されています。"
    )

    if customer is None:
        # KYC情報がない場合、誰の通常取引かを判断しにくいため、追加確認候補にします。
        kyc_context = "対応する顧客確認情報が見つかりません。"
        notes.append("顧客確認情報との照合が必要です。")
    else:
        # KYCの確認状況を確認します。
        kyc_context = (
            f"顧客ID {customer.customer_id} は KYC 状態が {customer.kyc_status}、"
            f"想定目的は {customer.expected_purpose} です。"
        )

        # KYCが完了していない場合は、追加確認の対象にします。
        if customer.kyc_status != "verified":
            notes.append("KYCが完了していないため、追加確認が必要です。")

        # 通常想定される金額を超える場合は、取引目的や資金源の確認候補にします。
        if transfer.amount > customer.usual_amount_limit:
            notes.append("通常想定される金額を超えているため、取引目的や資金源の確認候補です。")

    # 注意点がない場合でも、「問題なし」と断定せず、現時点の簡易確認では大きな注意点なしと表現します。
    if not notes:
        notes.append("この簡易確認では大きな注意点は見つかっていません。")

    return TransferReview(
        tx_id=transfer.tx_id,
        observation=observation,
        kyc_context=kyc_context,
        notes=notes,
    )


review = review_transfer(transfer, customer)

print(f"取引ID: {review.tx_id}")
print("観察:", review.observation)
print("KYC確認:", review.kyc_context)
print("注意点:")
for note in review.notes:
    print("-", note)

このコードで行っていることは、とても単純です。

1. オンチェーン上で見える架空の移転情報を用意する
2. 事業者側にある架空の顧客確認情報を用意する
3. 取引金額が通常想定を超えていないかを確認する
4. KYCが完了しているかを確認する
5. 結果を「観察」「KYC確認」「注意点」に分けて表示する

ここで重要なのは、オンチェーン情報とKYC情報を混ぜて扱わないことです。

オンチェーン上では、アドレス間の移転が見えます。
一方で、KYC情報は事業者側の管理情報です。
この2つを照合できる場面では、より文脈を持って取引を確認できますが、一般公開されたブロックチェーン情報だけで本人確認までできるわけではありません。

また、コード内でも「犯罪である」といった判定はしていません。
あくまで、追加確認の候補を整理しているだけです。

7.8 学習用コード：Travel Rule用の情報がそろっているか確認する

次に、Travel Ruleの考え方を、さらに単純な架空データで見てみます。

繰り返しになりますが、これは実際のTravel Rule対応システムではありません。
実在の個人情報や事業者情報は使いません。
目的は、送付人・受取人に関する情報が、オンチェーン取引とは別レイヤーで扱われることを理解することです。

# このコードは、Travel Ruleの考え方を説明するための学習用です。
# 実際のTravel Rule対応、本人確認、法令対応に使うものではありません。
# 実在の個人情報を扱わないよう、すべて架空のIDで表現しています。

from dataclasses import dataclass


@dataclass
class TravelRuleInfo:
    """送付人・受取人に関する架空の通知情報を表します。"""
    originator_id: str       # 送付人を表す架空ID
    beneficiary_id: str      # 受取人を表す架空ID
    originator_vasp: str     # 送付元VASP
    beneficiary_vasp: str    # 送付先VASP
    purpose: str             # 送付目的の説明


@dataclass
class ValidationResult:
    """Travel Rule情報の簡易確認結果を表します。"""
    is_complete: bool
    missing_fields: list[str]
    message: str


def validate_travel_rule_info(info: TravelRuleInfo) -> ValidationResult:
    """
    Travel Ruleに関係する架空情報が空欄になっていないか確認します。

    注意:
    - 実際の必要項目は法域、制度、取引内容、事業者の規程などによって異なります。
    - この関数は、必須項目の形式確認をイメージするための簡易モデルです。
    - 個人情報を扱う実装では、暗号化、アクセス制御、監査ログ、保存期間などの設計も重要になります。
    """
    missing_fields = []

    # 各項目が空文字列でないかを確認します。
    if not info.originator_id:
        missing_fields.append("originator_id")
    if not info.beneficiary_id:
        missing_fields.append("beneficiary_id")
    if not info.originator_vasp:
        missing_fields.append("originator_vasp")
    if not info.beneficiary_vasp:
        missing_fields.append("beneficiary_vasp")
    if not info.purpose:
        missing_fields.append("purpose")

    # 足りない項目がなければ、形式上はそろっているとします。
    if not missing_fields:
        return ValidationResult(
            is_complete=True,
            missing_fields=[],
            message="説明用の必須項目はそろっています。",
        )

    # 足りない項目がある場合は、追加確認が必要であることを返します。
    return ValidationResult(
        is_complete=False,
        missing_fields=missing_fields,
        message="不足している項目があるため、追加確認が必要です。",
    )


# 架空のTravel Rule関連情報です。
# 実際の氏名や住所ではなく、説明用のIDだけを使っています。
info = TravelRuleInfo(
    originator_id="originator_001",
    beneficiary_id="beneficiary_002",
    originator_vasp="VASP_A",
    beneficiary_vasp="VASP_B",
    purpose="example_payment",
)

result = validate_travel_rule_info(info)

print("確認結果:", result.message)
print("項目はそろっているか:", result.is_complete)
print("不足項目:", result.missing_fields)

このコードでは、送付人ID、受取人ID、送付元VASP、送付先VASP、送付目的といった架空項目が空欄になっていないかを確認しています。

もちろん、実際のTravel Rule対応はこれほど単純ではありません。
実務では、法域ごとの要件、本人確認情報の正確性、通知方式、データ保護、アクセス制御、保存期間、監査ログ、エラー時の対応など、より多くの論点があります。

ただし、初学者向けには、まず次の理解ができれば十分です。

Travel Ruleでは、オンチェーン上のアドレスやトランザクションだけでなく、送付人・受取人に関する情報を、VASP間で別レイヤーとして扱う必要があります。

7.9 よくある誤解

ここで、取引所・VASP・KYC・Travel Ruleについて、よくある誤解を整理しておきます。

誤解	実際には
ブロックチェーンは公開されているので、本人情報も誰でも見える	公開されるのは主にオンチェーン情報であり、KYC情報は一般公開されない
KYCがあるので、オンチェーン分析は不要	KYCは顧客情報の確認、オンチェーン分析は資金の流れの確認であり、役割が違う
Travel Ruleは個人情報をブロックチェーンに書き込む仕組み	送付人・受取人情報を関係するVASP間で扱う仕組みとして理解する方が自然
VASPを通れば常に安全	VASPの監督状況、法域、内部管理、取引内容によってリスクは変わる
アンホステッドウォレットは必ず危険	自己管理ウォレットは正当な利用も多い。ただしAML上は確認が難しい場面がある
Red Flagがあれば即座に取引停止すべき	ルールや状況による。Red Flagは追加確認の入口として扱う

暗号資産AMLでは、どれか一つの仕組みだけで安全性を保証するわけではありません。
オンチェーン分析、KYC、Travel Rule、リスク評価、内部管理、法令対応が組み合わさって、全体として不正利用を防ぐ仕組みになります。

💡 豆知識
Travel Ruleは荷物の送り状に少し似ています。
ただし、暗号資産のTravel Rule情報は、ブロックチェーン上にそのまま個人情報を貼り付ける仕組みではありません。
関係するVASP間で、送付人・受取人に関する情報を適切に扱うためのルールとして理解すると誤解しにくくなります。

7.10 この章のまとめ

この章では、取引所・VASP・KYC・Travel Ruleの関係を整理しました。

オンチェーン分析では、アドレス間の資金移動や取引履歴を確認できます。
しかし、アドレスの背後にいる利用者、取引目的、取引所内部の顧客情報までは、オンチェーン情報だけでは分からないことがあります。

そこで重要になるのが、取引所などのVASP、KYC、Travel Ruleです。

この章で押さえたいポイントは、次の通りです。

• VASPは、暗号資産の交換、移転、保管などに関わる事業者を指す言葉として使われる
• KYCは、本人確認や顧客確認の考え方であり、口座開設時だけでなく継続的な確認にも関係する
• オンチェーン情報とKYC情報は、見える範囲と扱う主体が違う
• Travel Ruleは、暗号資産移転時に送付人・受取人情報をVASP間で扱うための仕組み
• Travel Ruleは、個人情報をブロックチェーン上に公開する仕組みではない
• アンホステッドウォレットは正当な利用もあるが、AML/CFT上は確認が難しい場面がある
• オンチェーン分析、KYC、Travel Ruleは、それぞれ役割が違い、組み合わせて考える必要がある

次の章では、ここまで出てきたRed Flag、KYC、Travel Ruleの考え方を受けて、リスクスコアリングと誤検知・過検知 を整理します。

暗号資産AMLでは、取引やアドレスに点数を付けるような考え方が使われることがあります。
しかし、その点数は「犯罪度」ではなく、追加確認の優先順位を考えるための材料です。

第8章では、リスクスコアをどう見ればよいのか、そして誤検知や過検知をどう考えるべきかを見ていきます。

---

8. リスクスコアリングと誤検知・過検知

この章では、暗号資産AMLで出てくる リスクスコアリング の考え方を整理します。
ポイントは、リスクスコアは「犯罪度」ではなく、追加確認の優先順位を考えるための材料だという点です。

前の章では、取引所・VASP・KYC・Travel Ruleの関係を整理しました。

オンチェーン分析では、アドレス間の資金移動や既知ラベルとの接点を確認できます。
一方で、KYCやTravel Ruleは、アドレスの背後にある顧客情報や送付人・受取人情報を、事業者側で適切に扱うための仕組みでした。

ここまで来ると、次のような疑問が出てきます。

取引履歴、Red Flag、KYC情報、外部ラベルなどがあるとして、実際にはどの取引から確認すればよいのか？

暗号資産AMLでは、確認すべき取引やアドレスが大量になることがあります。
すべての取引を人が1件ずつ同じ深さで見るのは、現実的ではありません。

そこで出てくるのが リスクスコアリング です。

リスクスコアリングとは、取引やアドレス、顧客、送金先などについて、さまざまな観点からリスクの高さを点数化し、追加確認の優先順位を付ける考え方です。

ただし、ここで最初に強調しておきたいことがあります。

リスクスコアが高いことは、犯罪であることの証明ではありません。

たとえば、クレジットカード会社から「普段と違う利用があったため確認してください」と通知が来ることがあります。
その通知が来たからといって、必ず不正利用とは限りません。
本人が旅行先で使っただけかもしれませんし、いつもより高額な買い物をしただけかもしれません。

暗号資産AMLのリスクスコアも、これに近い感覚で捉えると分かりやすいです。

スコアは、取引を止めるための絶対的な判定ではなく、「この取引は少し丁寧に確認した方がよさそう」という付箋 に近いものです。

8.1 身近な例：カード明細の「いつもと違う利用」

まずは、クレジットカード明細を例にして考えてみます。

普段は、近所のスーパーやコンビニで少額決済をしている人が、ある日突然、深夜に海外サイトで高額な買い物をしたとします。

このとき、カード会社のシステムは次のような点を見ているかもしれません。

見るポイント	例	追加確認が必要になりやすい理由
金額	普段は数百円〜数千円なのに、急に高額決済がある	いつもの利用パターンから外れているため
時間帯	深夜や早朝に利用されている	本人の通常利用と違う可能性があるため
場所	普段使わない国・地域の加盟店で利用されている	不正利用やアカウント乗っ取りの可能性を確認するため
頻度	短時間に何度も決済されている	自動化された不正利用の可能性を確認するため
利用先	過去に不正利用が多い加盟店と似ている	既知リスクとの接点があるため

もちろん、これらに当てはまったからといって、必ず不正とは限りません。

本人が海外旅行中かもしれません。
急ぎで高額なPCを買っただけかもしれません。
いつもと違う時間に買い物をしただけかもしれません。

それでも、普段と違う動きが重なれば、追加確認の優先順位は上がります。

暗号資産AMLのリスクスコアリングも、基本的な考え方は似ています。

8.2 リスクスコアリングで見る主な観点

暗号資産AMLでリスクスコアを考えるときは、単に「金額が大きいか」だけを見るわけではありません。

前の章までで整理したように、オンチェーン情報、外部ラベル、KYC情報、Travel Rule情報、顧客属性など、複数の情報を組み合わせて見ます。

たとえば、次のような観点です。

観点	具体例	注意点
取引金額	高額な送金、通常より大きい入出金	高額だから不正とは限らない
取引頻度	短時間に多数の送金	自動処理や正当なサービス運用の場合もある
送金パターン	分散、集約、短時間の反復	ビジネス上の支払い処理と似ることもある
既知ラベルとの接点	高リスクアドレス、制裁対象、詐欺関連アドレスとの接点	ラベルの根拠と更新時期を確認する必要がある
ホップ数	高リスクアドレスから何段階離れているか	近いから即不正とは限らない
利用サービス	ミキサー、ブリッジ、DEX、取引所などとの接点	正当な利用と不正利用の両方があり得る
顧客属性	取引目的、職業、事業内容、過去の利用傾向	オンチェーンだけでは分からない
地理的リスク	監督が弱い法域、制裁対象地域との関係	法域や時期によって変わる
Travel Rule情報	送付人・受取人情報の不足、不整合	情報不足だけで不正と断定しない

FATFは、Virtual AssetsとVASPに関するリスクベース・アプローチのガイダンスで、各国や事業者がリスクを特定・評価・低減することの重要性を整理しています。
参考: FATF: Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs

また、FATFのRed Flag Indicatorsでは、取引パターン、匿名性を高める技術、地理的リスク、送付人・受取人の特徴、資金源などが、疑わしい取引を検討するための観点として整理されています。
参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

ここで大切なのは、これらの観点を 単独で機械的に判定しないこと です。

たとえば、「ブリッジを使ったから高リスク」とだけ見ると、正当なクロスチェーン利用まで過剰に拾ってしまいます。
一方で、「金額が少ないから問題ない」とだけ見ると、少額分散のようなパターンを見逃す可能性があります。

そのため、リスクスコアリングでは、複数の観点を組み合わせて、追加確認の優先順位を考えます。

8.3 スコアは「点数」よりも「説明できること」が大切

リスクスコアというと、つい 0点〜100点 のような数字を想像するかもしれません。

もちろん、実際のシステムでも数値スコアが使われることはあります。
しかし、暗号資産AMLでは、単に点数が出ることよりも、なぜその点数になったのかを説明できること が大切です。

たとえば、次の2つを比べてみます。

出力例	読みやすさ	問題点
risk_score = 87	数字としては分かりやすい	なぜ87点なのか分からない
高リスクラベルとの接点 + 短時間の分散 + 取引目的未確認	理由が分かる	数字より少し長い

AMLの現場では、後から「なぜこの取引を追加確認したのか」「なぜこの取引は通常モニタリングにしたのか」を説明できることが重要になります。

これは、セキュリティ監視のアラートにも似ています。

アラートに 危険度: 高 とだけ書かれていても、対応者は困ります。
どのIPアドレスから、どの端末へ、どの通信があり、どのルールに一致したのかが分かると、調査しやすくなります。

暗号資産AMLでも同じです。

ここでいう特徴量とは、分析に使うために取り出した情報のことです。
たとえば、金額、時間帯、送金回数、既知ラベルとの距離、取引所への入金有無などが特徴量になります。

特徴量の例	ざっくりした意味
amount	送金額
tx_count_1h	1時間以内の取引回数
risk_label_distance	高リスクラベルから何ホップ離れているか
uses_mixer_like_service	ミキサー関連とされるサービスとの接点があるか
kyc_status	顧客確認が完了しているか
travel_rule_info_complete	Travel Ruleに必要な情報がそろっているか

ただし、特徴量を増やせばよいというものでもありません。
根拠が弱いラベルや、偏ったデータにもとづく特徴量を入れると、誤った判断につながる可能性があります。

8.4 誤検知・過検知とは何か

リスクスコアリングでは、誤検知 や 過検知 が必ず問題になります。

誤検知とは、本来は問題がない取引を、問題があるかもしれないものとして拾ってしまうことです。
過検知は、広めに拾いすぎて、追加確認候補が大量に出てしまう状態として使われることがあります。

身近な例でいうと、メールの迷惑メールフィルタが分かりやすいです。

フィルタの結果	例	問題
正しく検知	本当に迷惑メールを迷惑メールフォルダへ入れる	問題ない
誤検知	大事な企業メールを迷惑メール扱いしてしまう	必要な連絡を見落とす
見逃し	迷惑メールが受信箱に入ってしまう	危険なリンクを開く可能性がある
過検知	少し怪しいだけのメールまで大量に隔離する	確認作業が増えすぎる

暗号資産AMLでも同じです。

リスクを広く拾おうとすると、誤検知が増えやすくなります。
逆に、誤検知を減らそうとして条件を厳しくしすぎると、本当に確認すべき取引を見逃す可能性があります。

金融庁は、2024年の「マネー・ローンダリング等対策の取組と課題」で、日本の金融機関等における取引モニタリング等システムの誤検知率が非常に高く、大量の誤検知を手作業で確認することが経営資源の活用に制約を加えていると整理しています。
参考: 金融庁: マネー・ローンダリング等対策の取組と課題（2024年6月）

これは、暗号資産AMLでも重要な視点です。

アラートをたくさん出せば安心、というわけではありません。
確認できないほど大量のアラートが出ると、本当に重要なものが埋もれてしまいます。

8.5 誤検知と見逃しを表で整理する

リスク判定を考えるときは、次の4パターンで整理すると分かりやすいです。

実際の状態	システムの判定	呼び方	何が起きるか
確認が必要	確認候補にする	正しく検知	追加確認につながる
確認が必要	通常扱いにする	見逃し	リスクを見落とす可能性がある
通常の取引	確認候補にする	誤検知	利用者や担当者の負担が増える
通常の取引	通常扱いにする	正しく除外	不要な確認を減らせる

この4パターンは、機械学習やセキュリティ検知でもよく出てくる考え方です。

ただし、暗号資産AMLでは、「実際の状態」がすぐに分からないことがあります。
取引の背景や目的は、オンチェーン情報だけでは見えにくいからです。

そのため、誤検知や見逃しを評価するときも、あとから得られた追加情報、担当者の確認結果、届出判断、顧客説明、外部情報などを組み合わせる必要があります。

8.6 しきい値を変えると、見え方が変わる

リスクスコアリングでは、よく しきい値 が使われます。

しきい値とは、「この点数以上なら追加確認する」と決める境目のことです。

たとえば、リスクスコアが0〜100点で表されるとして、70点以上を追加確認候補にするとします。

0点 ───────────── 70点 ───────────── 100点
低リスク              追加確認候補

この70点という線をどこに置くかで、アラートの数は大きく変わります。

しきい値	起きやすいこと	注意点
低めに設定	多くの取引を拾える	誤検知・過検知が増えやすい
高めに設定	確認件数を減らせる	見逃しが増える可能性がある
固定しすぎる	運用は簡単	犯罪手口や利用状況の変化に弱い
定期的に見直す	実態に合わせやすい	検証と記録が必要

金融庁のマネロン等対策ガイドラインFAQでも、取引モニタリングは過去の取引パターン等との比較により異常取引の検知・調査・判断を行い、リスク低減措置や疑わしい取引の届出につなげる考え方として整理されています。
参考: 金融庁: マネロン・テロ資金供与対策ガイドラインに関するよくあるご質問（FAQ）

つまり、しきい値は一度決めたら終わりではありません。
取引の傾向、顧客層、法規制、犯罪手口、誤検知の状況に応じて見直していく必要があります。

8.7 学習用コード：簡単なリスクスコアを作ってみる

ここでは、架空の取引データを使って、簡単なリスクスコアリングを作ってみます。

このコードは、実務で使えるAMLシステムではありません。
実在アドレスの追跡や、犯罪関与の判定に使うものでもありません。

目的は、次の考え方を理解することです。

1. 取引ごとに複数の観点を見る
2. 観点ごとに点数を足す
3. 点数だけでなく、理由も出す
4. スコアが高くても、犯罪ではなく追加確認候補として扱う

# これはリスクスコアリングの考え方を理解するための学習用コードです。
# 実在するアドレス、取引、顧客情報は使っていません。
# 実務のAML判定や犯罪関与の判断にそのまま使うものではありません。

from dataclasses import dataclass
from typing import List


@dataclass
class Transaction:
    """架空の暗号資産取引を表すデータクラスです。"""
    tx_id: str
    sender: str
    receiver: str
    amount: float
    asset: str
    hour: int
    receiver_label: str
    hop_from_high_risk: int | None
    kyc_status: str
    travel_rule_complete: bool


@dataclass
class RiskResult:
    """リスクスコアと、その理由をまとめるためのデータクラスです。"""
    tx_id: str
    score: int
    level: str
    reasons: List[str]


# 架空の取引データです。
# receiver_label は、送金先アドレスに付いている外部ラベルのイメージです。
# hop_from_high_risk は、高リスクラベル付きアドレスから何ホップ離れているかを表す簡易情報です。
transactions = [
    Transaction(
        tx_id="tx001",
        sender="addr_user_a",
        receiver="addr_exchange",
        amount=0.8,
        asset="ETH",
        hour=14,
        receiver_label="取引所",
        hop_from_high_risk=None,
        kyc_status="verified",
        travel_rule_complete=True,
    ),
    Transaction(
        tx_id="tx002",
        sender="addr_user_b",
        receiver="addr_mixer_like",
        amount=12.5,
        asset="USDT",
        hour=2,
        receiver_label="ミキサー関連とされるサービス",
        hop_from_high_risk=1,
        kyc_status="basic",
        travel_rule_complete=False,
    ),
    Transaction(
        tx_id="tx003",
        sender="addr_user_c",
        receiver="addr_bridge",
        amount=3.2,
        asset="USDC",
        hour=23,
        receiver_label="ブリッジ",
        hop_from_high_risk=3,
        kyc_status="verified",
        travel_rule_complete=True,
    ),
]


def score_transaction(tx: Transaction) -> RiskResult:
    """1件の架空取引に対して、簡易的なリスクスコアを計算します。"""
    score = 0
    reasons: List[str] = []

    # 金額が大きい場合は、追加確認の候補になりやすいと考えます。
    # ここでは説明用に 10.0 以上を高額として扱っています。
    if tx.amount >= 10.0:
        score += 25
        reasons.append("説明用しきい値以上の金額")

    # 深夜帯の取引は、通常パターンとの違いを確認する材料にします。
    # 実務では、顧客ごとの通常利用時間帯と比較する必要があります。
    if tx.hour <= 5 or tx.hour >= 23:
        score += 10
        reasons.append("深夜帯の取引")

    # ミキサー関連など、匿名性を高めるサービスとの接点がある場合は点数を加えます。
    # ただし、ラベルの根拠や正確性は別途確認が必要です。
    if "ミキサー" in tx.receiver_label:
        score += 35
        reasons.append("匿名性を高めるサービスとの接点")

    # ブリッジは正当利用も多いため、ミキサーより低い点数にしています。
    # ここでは「クロスチェーン移動なので文脈確認が必要」という意味で点数を加えます。
    if "ブリッジ" in tx.receiver_label:
        score += 10
        reasons.append("ブリッジを経由する取引")

    # 高リスクラベル付きアドレスに近い場合は、追加確認の理由にします。
    # 近いほど点数を高くしていますが、ホップ数だけで不正とは判断できません。
    if tx.hop_from_high_risk == 1:
        score += 30
        reasons.append("高リスクラベル付きアドレスに近い")
    elif tx.hop_from_high_risk is not None and tx.hop_from_high_risk <= 3:
        score += 10
        reasons.append("高リスクラベル付きアドレスから数ホップ以内")

    # KYCが簡易的な状態であれば、必要に応じて追加確認の対象にします。
    # ここでは説明用に basic を点数加算の対象にしています。
    if tx.kyc_status != "verified":
        score += 15
        reasons.append("KYC確認状況が限定的")

    # Travel Ruleに必要な情報が不足している場合、情報確認の必要性が高まります。
    if not tx.travel_rule_complete:
        score += 15
        reasons.append("Travel Rule関連情報が不足")

    # スコアに応じて、確認優先度を3段階に分けます。
    # これは説明用の分類であり、実務ルールではありません。
    if score >= 70:
        level = "高: 追加確認を優先"
    elif score >= 30:
        level = "中: 文脈を確認"
    else:
        level = "低: 通常モニタリング"

    return RiskResult(tx_id=tx.tx_id, score=score, level=level, reasons=reasons)


# 各取引についてスコアを計算し、理由と一緒に表示します。
for tx in transactions:
    result = score_transaction(tx)
    print(f"{result.tx_id}: score={result.score}, level={result.level}")
    for reason in result.reasons:
        print(f"  - {reason}")
    print()

このコードでは、金額、時間帯、外部ラベル、高リスクアドレスからの距離、KYC状況、Travel Rule情報の有無をもとに、簡易的なスコアを計算しています。

ただし、重要なのは点数そのものではありません。

むしろ、出力される 理由 の方が大切です。

たとえば、tx002 のスコアが高くなったとしても、そこから言えるのは次のようなことです。

tx002は、説明用しきい値以上の金額、深夜帯の取引、匿名性を高めるサービスとの接点、高リスクラベル付きアドレスに近いこと、KYC確認状況、Travel Rule情報不足などの理由により、追加確認の優先度が高い。

これは、次のように言うこととは違います。

tx002は犯罪である。

この違いを分けることが、暗号資産AMLの記事ではとても重要です。

8.8 学習用コード：誤検知と見逃しを数えてみる

次に、しきい値によって誤検知や見逃しが変わることを、簡単なコードで見てみます。

ここでは、架空の取引について、あとから人が確認した結果を actual_needs_review として持っているとします。

もちろん、実務ではこの「正解ラベル」を作ること自体が難しい場合があります。
ここでは、考え方を理解するために単純化しています。

# しきい値を変えると、誤検知や見逃しがどう変わるかを見る学習用コードです。
# 実務では、正解ラベルの作成や評価方法を慎重に設計する必要があります。

from dataclasses import dataclass


@dataclass
class ReviewedTransaction:
    """スコアと、後から確認した結果を持つ架空取引です。"""
    tx_id: str
    score: int
    actual_needs_review: bool  # 実際に追加確認が必要だったかどうか


reviewed_transactions = [
    ReviewedTransaction("tx001", 20, False),
    ReviewedTransaction("tx002", 85, True),
    ReviewedTransaction("tx003", 45, False),
    ReviewedTransaction("tx004", 60, True),
    ReviewedTransaction("tx005", 75, False),
    ReviewedTransaction("tx006", 35, True),
]


def evaluate_threshold(items: list[ReviewedTransaction], threshold: int) -> dict[str, int]:
    """指定したしきい値で、検知結果を4分類して数えます。"""
    counts = {
        "正しく検知": 0,
        "見逃し": 0,
        "誤検知": 0,
        "正しく除外": 0,
    }

    for item in items:
        # スコアがしきい値以上なら、システムは追加確認候補にします。
        predicted_review = item.score >= threshold

        # 実際に確認が必要で、システムも確認候補にした場合です。
        if item.actual_needs_review and predicted_review:
            counts["正しく検知"] += 1

        # 実際には確認が必要なのに、システムが通常扱いにした場合です。
        elif item.actual_needs_review and not predicted_review:
            counts["見逃し"] += 1

        # 実際には通常取引なのに、システムが確認候補にした場合です。
        elif not item.actual_needs_review and predicted_review:
            counts["誤検知"] += 1

        # 実際に通常取引で、システムも通常扱いにした場合です。
        else:
            counts["正しく除外"] += 1

    return counts


# しきい値を変えながら、検知結果を比較します。
for threshold in [40, 60, 80]:
    result = evaluate_threshold(reviewed_transactions, threshold)
    print(f"しきい値: {threshold}")
    for label, count in result.items():
        print(f"  {label}: {count}")
    print()

このコードでは、しきい値を 40、60、80 に変えて、誤検知や見逃しの数を比べています。

しきい値を低くすると、多くの取引を確認候補にしやすくなります。
その分、見逃しは減るかもしれませんが、誤検知が増えやすくなります。

逆に、しきい値を高くすると、確認件数は減ります。
ただし、本当に確認が必要な取引を見逃す可能性があります。

このバランスをどう取るかが、取引モニタリングの難しいところです。

8.9 リスクスコアは「顧客の文脈」とセットで見る

暗号資産AMLのスコアリングでは、取引単体だけでなく、顧客の文脈も重要です。

たとえば、同じ100万円相当の暗号資産移転でも、次のように意味が変わる可能性があります。

文脈	見え方
普段から大口取引を行う法人顧客	通常の事業活動の範囲かもしれない
少額取引が中心だった個人顧客	急な高額取引として追加確認が必要かもしれない
取引目的を事前に説明している顧客	説明内容と一致しているか確認する
取引目的が不明確な顧客	資金源や目的の追加確認が必要かもしれない

金融庁のFAQでも、取引モニタリングは過去の取引パターン等との比較を含むものとして整理されています。
つまり、単発の金額やラベルだけでなく、顧客ごとの通常パターンと比べてどうかを見る必要があります。
参考: 金融庁: マネロン・テロ資金供与対策ガイドラインに関するよくあるご質問（FAQ）

これは、セキュリティログ分析にも似ています。

あるユーザーが深夜にサーバへログインしたとしても、それだけで不正とは限りません。
夜間保守の担当者なら通常業務かもしれません。
一方で、普段は国内からしかアクセスしないユーザーが、急に海外IPから深夜にログインし、大量のファイルをダウンロードした場合は、追加確認の必要性が高まります。

暗号資産AMLでも、取引の意味は文脈で変わります。

8.10 AIや機械学習を使えば解決するのか

リスクスコアリングというと、AIや機械学習を使えばすべて解決できるように感じるかもしれません。

たしかに、大量の取引データからパターンを見つけたり、過去のアラート対応結果をもとに優先順位を付けたりする場面では、機械学習が役立つ可能性があります。

しかし、AIや機械学習を使う場合でも、次のような課題があります。

課題	説明
教師データの偏り	過去の対応結果に偏りがあると、モデルも偏る可能性がある
説明可能性	なぜ高リスクと判定したのか説明できないと、運用しにくい
データの鮮度	犯罪手口やサービス構造が変わると、古いモデルが合わなくなる
誤検知の管理	モデルが大量のアラートを出すと、担当者が対応しきれない
法令・社内規程との整合	モデルの出力だけで実務判断を完結できるとは限らない
プライバシー	必要以上の個人情報や行動履歴を扱わない設計が必要

つまり、AIは便利な道具になり得ますが、AML判断を丸投げできるものではありません。

特に、暗号資産AMLでは、オンチェーン情報、KYC情報、外部ラベル、法令対応、利用者保護が関係します。
モデルの精度だけでなく、説明可能性、監査可能性、データ管理も重要です。

EBAは、暗号資産サービス提供者向けにML/TFリスク要因と低減措置を考慮する必要があることを示しており、CASPが金融犯罪リスクを適切に管理することを求めています。
参考: EBA: Guidance to crypto-asset service providers to effectively manage ML/TF risks

この点からも、リスクスコアリングは単なる技術実装ではなく、運用・監査・説明責任を含む仕組みとして考える必要があります。

8.11 リスクスコアを書くときの安全な表現

記事やレポートでリスクスコアリングについて書くときは、表現に注意が必要です。

特に、スコアを犯罪の断定のように書かないことが大切です。

避けたい表現	より安全な表現
このアドレスは危険である	このアドレスは高リスクラベルとの接点があるため、追加確認候補になり得る
スコアが高いので犯罪である	スコアが高いため、取引目的や資金源の確認が必要になる可能性がある
AIが不正と判定した	モデル上は高リスクと評価されたが、最終判断には文脈確認が必要である
低スコアなので安全である	現時点の観測範囲では低リスクと評価されたが、リスクがないことを保証するものではない
ラベルが付いているので確定	ラベルの根拠や更新時期を確認する必要がある

この表現の違いは、細かいようでかなり重要です。

リスクスコアは、調査を効率化するための材料です。
断定ではなく、追加確認の優先順位付けとして扱うことで、誤解を減らしやすくなります。

💡 豆知識
リスクスコアは、学校の成績表というより 体温計 に近いです。
体温が高いだけで病名が確定しないように、スコアが高いだけで犯罪だと決まるわけではありません。
ただし、追加確認を考えるきっかけにはなります。

8.12 この章のまとめ

この章では、暗号資産AMLにおけるリスクスコアリングと、誤検知・過検知の考え方を整理しました。

リスクスコアリングは、取引やアドレス、顧客、送金先などについて、追加確認の優先順位を付けるための考え方です。
ただし、スコアは犯罪の証明ではありません。

この章で押さえたいポイントは、次の通りです。

• リスクスコアは「犯罪度」ではなく、追加確認の優先順位を考えるための材料である
• 金額、頻度、既知ラベル、ホップ数、利用サービス、KYC状況、Travel Rule情報などを組み合わせて見る
• スコアだけでなく、なぜそのスコアになったのかを説明できることが大切である
• 誤検知が多すぎると、担当者の確認負担が増え、本当に重要なアラートが埋もれる可能性がある
• しきい値を低くすると広く拾えるが、過検知になりやすい
• しきい値を高くすると確認件数は減るが、見逃しが増える可能性がある
• AIや機械学習は役立つ可能性があるが、説明可能性、監査可能性、データの鮮度が重要である
• リスクスコアの結果は、観察・推定・追加確認候補として慎重に表現する必要がある

次の章では、ここまで扱ってきたオンチェーン分析、外部情報、Red Flag、リスクスコアリングの考え方をもとに、暗号資産AMLを難しくしている最近の論点を整理します。

特に、ステーブルコイン、ミキサー、ブリッジ、DeFi、アンホステッドウォレット、オフショアVASPのようなテーマは、単純な「アドレス間の送金」だけでは説明しきれない部分があります。

第9章では、これらを不正利用手順としてではなく、AML上どのような確認ポイントになるのか という観点から見ていきます。

---

9. 最近の論点：ステーブルコイン・ミキサー・ブリッジ・DeFi・アンホステッドウォレット

この章では、ここまで整理してきたオンチェーン分析、外部情報、Red Flag、リスクスコアリングをもとに、暗号資産AMLで近年よく論点になるテーマを整理します。
ポイントは、これらを「危ないもの」と一括りにするのではなく、どのような便利さがあり、どこがAML上の確認ポイントになるのか を分けて見ることです。

前の章では、リスクスコアリングと誤検知・過検知について整理しました。

リスクスコアは、取引を「犯罪」と決めつけるための点数ではありません。
金額、頻度、取引相手、既知ラベル、ホップ数、KYC状況、Travel Rule情報などを組み合わせ、追加確認の優先順位を考えるための材料でした。

この章では、その考え方を使って、暗号資産AMLを少し難しくしている最近の論点を見ていきます。

具体的には、次のようなテーマです。

論点	ざっくりした意味	AML上の確認ポイント
ステーブルコイン	法定通貨などに価値を連動させることを目指す暗号資産	送金しやすさ、流動性、国境を越える利用、発行体・償還・規制
ミキサー	複数の取引を混ぜ、資金のつながりを見えにくくする仕組み	プライバシー保護と不正資金隠しの両面、制裁・規制上の扱い
ブリッジ	異なるブロックチェーン間で資産を移す仕組み	チェーンをまたぐ追跡、ラップド資産、ハッキング被害資金の移動
DeFi	スマートコントラクトを使う金融サービス群	取引所を通らない利用、流動性プール、DEX、レンディングなどの複雑さ
アンホステッドウォレット	利用者自身が秘密鍵を管理するウォレット	KYC情報が直接付かない場合があること、P2P取引、所有者確認
オフショアVASP	ある法域で設立され、別の法域の顧客へサービスを提供するVASP	登録・監督の隙間、越境サービス、実効的な規制監督

これらは、どれも暗号資産の世界で重要な仕組みです。
正当な利用も多くあります。

たとえば、ステーブルコインは価格変動の大きい暗号資産よりも決済や送金に使いやすい場面があります。
ブリッジは、異なるブロックチェーン上のアプリをつなぐために使われます。
アンホステッドウォレットは、利用者が自分で鍵を管理するというブロックチェーンらしい使い方でもあります。

一方で、AMLの観点では、便利な仕組みほど確認ポイントが増えることがあります。

• 速く動かせる
• 国境を越えやすい
• 複数のサービスをまたぎやすい
• 取引所を通らずに動かせる
• 取引の意味を読むにはスマートコントラクトの理解が必要になる

このような特徴があるため、単純に「アドレスAからアドレスBへ送金された」と見るだけでは、資金の流れを十分に理解できない場合があります。

FATFは2026年に公表したステーブルコインとアンホステッドウォレットに関する報告書で、ステーブルコインの急速な拡大、アンホステッドウォレット、P2P取引、複雑なロンダリング手法がリスク論点になることを整理しています。

参考: FATF: Targeted Report on Stablecoins and Unhosted Wallets

また、FATFはオフショアVASPについても、設立地・運営地・顧客所在地・監督主体がずれることで、監督上の隙間が生まれ得ることを整理しています。

参考: FATF: Understanding and Mitigating the Risks of Offshore Virtual Asset Service Providers

この章では、こうしたテーマを不正利用の手順としてではなく、AML上どこを慎重に見る必要があるのか という観点で整理します。

9.1 まずは「乗り換えが多い移動」で考える

いきなりステーブルコインやブリッジから入ると難しく感じるため、まずは電車の乗り換えで考えてみます。

たとえば、ある人が次のように移動したとします。

A駅 → B駅 → C駅 → D駅

このくらいであれば、移動経路は比較的追いやすいです。

しかし、次のようになるとどうでしょうか。

A駅 → B駅 → バス → C駅 → 新幹線 → D駅 → タクシー → E地点

移動自体は正当なものかもしれません。
旅行、出張、帰省、イベント参加など、理由はいくらでもあります。

ただし、記録を確認する側から見ると、乗り換えが多いほど、次のような確認が必要になります。

• どこで交通手段が変わったのか
• 途中で別のチケットや決済手段を使っていないか
• 同じ人の移動としてつながるのか
• 途中の記録が欠けていないか
• 目的地はどこなのか

暗号資産でも、少し似たことが起こります。

同じチェーン上で単純に送金されるだけなら、資金の流れは比較的追いやすい場合があります。
しかし、途中でブリッジ、DEX、ミキサー、ステーブルコイン、取引所、アンホステッドウォレットなどが関わると、確認すべきポイントが増えます。

ここで大切なのは、乗り換えが多いこと自体を悪いと決めつけないことです。

正当な理由で複数サービスを使うこともあります。
一方で、AMLの観点では、経路が複雑になるほど、資金の出どころ、移動目的、最終的な到達先を慎重に確認する必要があります。

9.2 ステーブルコイン：便利だからこそ利用範囲が広がる

ステーブルコインは、米ドルや円などの法定通貨、または他の資産に価値を連動させることを目指す暗号資産です。

暗号資産と聞くと、価格が大きく上下するイメージがあるかもしれません。
ステーブルコインは、その価格変動を抑え、決済や送金に使いやすくすることを目的に設計されることがあります。

身近な例で言えば、海外旅行で現地通貨へ両替する場面に少し似ています。

ビットコインやイーサリアムのように価格が大きく動く資産で支払うと、「送った時点」と「受け取った時点」で価値が変わることがあります。
一方で、法定通貨に連動することを目指すステーブルコインであれば、送金や決済の単位として使いやすい場面があります。

ただし、AMLの観点では、便利さがそのまま確認ポイントにもなります。

ステーブルコインの特徴	便利な点	AML上の確認ポイント
価格の安定を目指す	送金・決済・清算に使いやすい	不正資金の移動にも使われやすい可能性
流動性が高いものがある	多くのサービスで扱いやすい	複数サービスをまたぐ移動が増えやすい
国境を越えて使いやすい	海外送金やグローバル決済に向く	法域ごとの規制・監督差が問題になる
DeFiでも使われる	DEXやレンディングで利用される	スマートコントラクトを経由した経路確認が必要

FATFの2026年報告書では、ステーブルコインが急速に拡大しており、不正な暗号資産取引量の中でステーブルコインが大きな割合を占めるとする分析にも触れられています。

参考: FATF: Targeted Report on Stablecoins and Unhosted Wallets

ここで重要なのは、ステーブルコインそのものを悪いものとして扱わないことです。

むしろ、ステーブルコインは正当な決済・送金・清算のためにも使われます。
ただし、広く使われるからこそ、不正資金の移動にも使われ得るため、発行体、償還、準備資産、取引経路、利用サービス、法域などを合わせて見る必要があります。

9.3 ミキサー：プライバシー保護と不正利用リスクの両面がある

ミキサーは、複数の利用者の資金を混ぜることで、入金元と出金先のつながりを見えにくくする仕組みです。

名前だけ聞くと怪しく感じるかもしれませんが、まず押さえたいのは、ミキサーには プライバシー保護 という文脈もあることです。

パブリックブロックチェーンでは、取引履歴が公開される場合があります。
そのため、給与、寄付、買い物、NFT購入、DeFi利用などがアドレス単位で見えてしまうことがあります。

こうした透明性の高さは、監査や不正調査に役立つ一方で、利用者のプライバシー上の課題にもなります。

一方で、FATFのRed Flag資料では、ミキサーやタンブラー、匿名性を高める技術が、資金の出どころや流れを見えにくくする要素として取り上げられています。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

つまり、ミキサーは次の両面で見た方がよいです。

観点	内容
プライバシー保護の観点	公開台帳上で資金履歴が丸見えになることを避けたい利用者がいる
AML上の観点	不正資金の出どころや移動経路を見えにくくするために悪用される可能性がある
実務上の注意	利用履歴だけで犯罪と断定せず、前後の取引、金額、相手先、法域、既知ラベルなどを確認する

米国OFACは、Tornado Cashを2022年に制裁対象に指定しましたが、2025年3月にはTornado Cashに対する経済制裁を解除したことを公表しています。

参考: U.S. Treasury: Tornado Cash Delisting

この例から分かるように、ミキサーやプライバシーツールの法的・規制上の扱いは変化し得ます。
そのため、記事や実務で触れる場合は、古い情報をそのまま使わず、投稿時点の公式情報を確認する必要があります。

なお、本記事ではミキサーの利用手順や追跡回避の具体的な方法は扱いません。
あくまで、AML上「なぜ確認ポイントになるのか」を理解する範囲に留めます。

9.4 ブリッジ：チェーンをまたぐと、履歴の読み方が変わる

ブリッジは、異なるブロックチェーン間で資産を移動させるための仕組みです。

たとえば、Ethereum上の資産を別のチェーンで使いたい場合、ブリッジを使って、元のチェーン上で資産をロックし、移動先チェーンで対応する資産を発行するような仕組みがあります。

身近な例で言えば、海外旅行で円をドルに両替する感覚に少し近いです。

円そのものを海外のお店でそのまま使うのではなく、別の通貨に替えて使う。
ブリッジも、チェーンA上の資産をチェーンB上で使えるようにするための接続点として考えると分かりやすいです。

ただし、AMLの観点では、ブリッジをまたぐと次のような確認が必要になります。

確認ポイント	内容
移動元チェーン	どのチェーンから資金が来たのか
移動先チェーン	どのチェーンへ移ったのか
ブリッジコントラクト	どのブリッジを使ったのか
ラップド資産	元の資産と移動先の資産がどう対応しているか
時刻・金額の対応	ロック・発行・焼却・解放などのイベントが対応しているか
既知事件との関係	ハッキングや詐欺と関連する資金が移動していないか

ブリッジは便利ですが、追跡では「同じチェーン上の送金」よりも確認が難しくなります。

• チェーンごとにデータ構造が違う
• ブロックエクスプローラーが分かれる
• トークンの名称やコントラクトが変わる
• ブリッジの仕組みによってイベントの読み方が違う
• 複数のブリッジやDEXを連続して使う場合がある

そのため、ブリッジを含む取引解析では、単に from と to を見るだけでなく、チェーンをまたいだ対応関係を確認する必要があります。

ここでも、ブリッジ利用そのものを不正と見なすべきではありません。
DeFi利用、NFT利用、手数料の安いチェーンへの移動など、正当な理由も多くあります。

一方で、ハッキング被害資金や詐欺資金がチェーンをまたいで移動する場合もあるため、AMLでは重要な確認ポイントになります。

9.5 DeFi：スマートコントラクトが入ると「誰に送ったか」だけでは読めない

DeFiは、Decentralized Financeの略で、スマートコントラクトを使って提供される金融サービス群を指す言葉です。

たとえば、次のようなものがあります。

DeFiの例	ざっくりした内容	AML上の確認ポイント
DEX	中央集権的な取引所ではなく、スマートコントラクト上でトークン交換を行う仕組み	どのトークンを何と交換したか、流動性プールとの関係
レンディング	暗号資産を貸し借りする仕組み	担保、借入、清算、金利などの取引文脈
流動性プール	利用者が資産を預け、交換や運用に使われるプール	入金・出金・LPトークンの移動
イールド関連サービス	収益獲得を目的に複数プロトコルを使う仕組み	複数コントラクトをまたぐ経路

通常の送金では、「AからBへ送った」と読めることがあります。
しかし、DeFiでは送信先が人ではなくスマートコントラクトである場合があります。

たとえば、あるアドレスがDEXのコントラクトへ資金を送った場合、それは単なる送金ではなく、トークン交換、流動性追加、スワップ、手数料支払いなど、さまざまな意味を持つ可能性があります。

Ethereum公式ドキュメントでは、スマートコントラクトはEthereum上で実行されるプログラムであり、トランザクションによって呼び出されると処理が実行されることが説明されています。

参考: Ethereum Documentation: Introduction to smart contracts

DeFiを含むAMLでは、次のような点を意識する必要があります。

• コントラクトの種類を確認する
• 単なる送金なのか、スワップなのかを分ける
• 入金と出金がどのトークンで行われたかを見る
• イベントログを確認する
• 関連するプロトコルやブリッジを確認する
• スマートコントラクトの自動処理と、人の意思による操作を混同しない

DeFiは透明性の高い部分もありますが、仕組みが複雑です。
そのため、見えている取引をどう解釈するかには注意が必要です。

9.6 アンホステッドウォレット：自己管理は基本機能でもあり、確認が難しい領域でもある

アンホステッドウォレットは、取引所やカストディ事業者ではなく、利用者自身が秘密鍵を管理するウォレットです。

日本語では、自己管理型ウォレット、ノンカストディアルウォレットのように説明されることもあります。

これは、ブロックチェーンの基本的な使い方の一つです。
自分で秘密鍵を管理し、自分で取引に署名する。
この考え方は、中央の事業者に依存しないというブロックチェーンの特徴とも関係します。

一方で、AMLの観点では、アンホステッドウォレットは確認が難しい場面があります。

観点	VASP口座	アンホステッドウォレット
秘密鍵の管理	事業者が管理する場合がある	利用者自身が管理する
KYC情報	事業者が顧客情報を持つ	ウォレット自体には本人確認情報が付かないことが多い
Travel Rule	VASP間移転では情報通知の対象になる	P2P取引では事業者間通知が働きにくい場合がある
オンチェーン上の見え方	アドレス・取引履歴が見える	アドレス・取引履歴が見える
本人確認	事業者内部情報と結びつく場合がある	外部情報なしでは難しい場合がある

金融庁は、FATF報告書の紹介において、アンホステッドウォレットを「VASPではなく利用者自身が秘密鍵を管理するウォレット」と説明し、アンホステッドウォレット同士の取引をP2P取引として説明しています。

参考: 金融庁: FATFによる「ステーブルコイン及びアンホステッド・ウォレット（P2P）に関する報告書」の公表について

ここで大切なのは、アンホステッドウォレットを単純に「悪いもの」と見ないことです。

自己管理は、利用者が自分の資産を管理するための正当な方法です。
一方で、VASPを通らないP2P取引では、本人確認やTravel Ruleの情報連携が届きにくくなる場合があります。

そのため、AMLでは次のように整理すると自然です。

アンホステッドウォレットは、ブロックチェーンの基本的な利用形態の一つです。
ただし、VASPのKYC情報やTravel Rule情報と直接結びつかない場合があるため、資金の流れ、外部情報、取引パターンを慎重に確認する必要があります。

9.7 オフショアVASP：サービス提供地と監督地がずれる問題

オフショアVASPは、ある法域で設立されながら、別の法域の顧客に暗号資産サービスを提供するVASPを指します。

たとえば、次のような状況を考えてみます。

• 事業者の登録地は国A
• サーバーや運営チームは国B
• 利用者の多くは国C
• 実際の取引は複数チェーン上で行われる

この場合、どの国の当局がどのように監督するのかが難しくなります。

FATFは、オフショアVASPについて、規制・監督の隙間が、詐欺、マネーロンダリング、テロ資金供与などに悪用される可能性があると整理しています。

参考: FATF: Understanding and Mitigating the Risks of Offshore Virtual Asset Service Providers

暗号資産は国境を越えて使いやすいため、国内の登録済み事業者だけを見ていれば十分とは限りません。
利用者が海外サービスを使ったり、海外サービスを経由して国内取引所へ入金したりすることもあり得ます。

そのため、AMLでは次のような点が確認ポイントになります。

確認ポイント	内容
登録・免許	どの法域で登録・監督されているか
顧客管理	KYCや継続的顧客管理が適切に行われているか
Travel Rule対応	送付人・受取人情報の通知に対応しているか
疑わしい取引対応	疑わしい取引の検知・報告体制があるか
制裁対応	制裁対象者・地域との取引を防ぐ仕組みがあるか
越境リスク	サービス提供地と顧客所在地がずれることで監督が難しくなっていないか

ここでも、海外サービスだからすべて危険、という話ではありません。
重要なのは、どの法域でどのような監督を受け、どのようなAML/CFT態勢を整えているかを見ることです。

9.8 これらの論点は単独ではなく、組み合わさる

ここまで、ステーブルコイン、ミキサー、ブリッジ、DeFi、アンホステッドウォレット、オフショアVASPを別々に見てきました。

しかし、実際の取引では、これらが組み合わさることがあります。

たとえば、次のような流れです。

アンホステッドウォレット
  → DEXでステーブルコインへ交換
  → ブリッジで別チェーンへ移動
  → 別チェーン上のDeFiを利用
  → 海外VASPへ入金

この流れ自体が不正だという意味ではありません。
正当なDeFi利用や資産管理でも、似たような経路になることがあります。

ただし、AMLの観点では、確認ポイントが増えます。

このように、暗号資産AMLでは、一つのRed Flagだけを見るのではなく、複数のサインを組み合わせて見る必要があります。

第6章で整理したように、Red Flagは犯罪の断定ではありません。
第8章で整理したように、リスクスコアも正解ラベルではありません。

最近の論点を扱うときも、同じ姿勢が重要です。

複雑な経路があるから危険、と短絡的に判断するのではなく、どの仕組みが関わり、どの情報が見えて、どこから先に追加確認が必要なのかを分けて考える。

9.9 Pythonで最近の論点を「確認メモ」として整理する

ここでは、ステーブルコイン、ブリッジ、DeFi、アンホステッドウォレットなどが関わる架空取引を、確認メモとして整理するコードを書いてみます。

このコードは、実際のAML判定システムではありません。
実在アドレスの追跡や、犯罪関与の判定に使うものでもありません。

目的は、複数の論点が重なったときに、何を追加確認ポイントとしてメモするか を学ぶことです。

# 最近の暗号資産AML論点を、架空取引データで整理する学習用コードです。
# 実在するアドレス、取引、サービス、人物を判定するものではありません。
# 目的は「どの要素が追加確認ポイントになり得るか」を確認メモとして出すことです。

from dataclasses import dataclass
from typing import List


@dataclass
class TransferCase:
    """架空の取引ケースを表すデータクラスです。"""
    case_id: str
    asset_type: str                  # 例: BTC, ETH, stablecoin
    uses_bridge: bool                # ブリッジを使っているか
    uses_defi: bool                  # DeFiプロトコルを使っているか
    uses_mixer_like_service: bool    # ミキサーのように経路を見えにくくするサービスと接点があるか
    wallet_type: str                 # hosted または unhosted など
    vasp_type: str                   # domestic_vasp, offshore_vasp, no_vasp など
    amount_usd: float
    notes: str


def build_review_notes(case: TransferCase) -> List[str]:
    """架空ケースから、追加確認ポイントを文章として作ります。"""
    review_notes = []

    # ステーブルコインは決済・送金に便利な一方、利用範囲が広いため確認ポイントになります。
    if case.asset_type == "stablecoin":
        review_notes.append(
            "ステーブルコインが使われています。発行体、償還、利用サービス、移動経路を確認します。"
        )

    # ブリッジを使っている場合、チェーンをまたいだ対応関係を確認する必要があります。
    if case.uses_bridge:
        review_notes.append(
            "ブリッジ利用があります。移動元チェーン、移動先チェーン、対応するイベントを確認します。"
        )

    # DeFiでは、単なる送金ではなくスマートコントラクトの処理内容を読む必要があります。
    if case.uses_defi:
        review_notes.append(
            "DeFiプロトコルとの接点があります。スワップ、流動性追加、借入など処理内容を確認します。"
        )

    # ミキサーのようなサービスとの接点は、FATFのRed Flagでも匿名性に関わる観点として扱われます。
    # ただし、この接点だけで犯罪と断定しないことが重要です。
    if case.uses_mixer_like_service:
        review_notes.append(
            "匿名性を高めるサービスとの接点があります。前後の資金フローと外部ラベルを慎重に確認します。"
        )

    # アンホステッドウォレットでは、ウォレット自体にKYC情報が直接付かない場合があります。
    if case.wallet_type == "unhosted":
        review_notes.append(
            "アンホステッドウォレットが関係しています。VASPのKYC情報と直接結びつかない可能性があります。"
        )

    # オフショアVASPでは、どの法域で登録・監督されているかが重要になります。
    if case.vasp_type == "offshore_vasp":
        review_notes.append(
            "オフショアVASPとの接点があります。登録・監督法域やTravel Rule対応状況を確認します。"
        )

    # 金額が大きい場合は、金額だけで断定せず、取引目的や顧客属性と合わせて確認します。
    if case.amount_usd >= 10000:
        review_notes.append(
            "説明用しきい値以上の金額です。通常取引パターンや取引目的との整合性を確認します。"
        )

    # 何も該当しない場合でも、確認不要と断定するのではなく、通常モニタリングの対象として扱います。
    if not review_notes:
        review_notes.append(
            "大きな追加確認ポイントはありませんが、通常のモニタリング対象として扱います。"
        )

    return review_notes


# 架空のケースを用意します。
# 実在する事件やアドレスではなく、学習用のサンプルです。
cases = [
    TransferCase(
        case_id="case_001",
        asset_type="stablecoin",
        uses_bridge=True,
        uses_defi=True,
        uses_mixer_like_service=False,
        wallet_type="unhosted",
        vasp_type="no_vasp",
        amount_usd=2500,
        notes="自己管理ウォレットからDeFi経由で別チェーンへ移動した架空例",
    ),
    TransferCase(
        case_id="case_002",
        asset_type="ETH",
        uses_bridge=False,
        uses_defi=False,
        uses_mixer_like_service=True,
        wallet_type="unhosted",
        vasp_type="offshore_vasp",
        amount_usd=18000,
        notes="匿名性を高めるサービスと海外VASPの接点がある架空例",
    ),
]


for case in cases:
    print(f"\n{case.case_id}: {case.notes}")
    for note in build_review_notes(case):
        print(f"- {note}")

このコードでは、各ケースについて「犯罪かどうか」を判定していません。

行っているのは、あくまで確認メモの作成です。

• ステーブルコインが使われている
• ブリッジを使っている
• DeFiと接点がある
• アンホステッドウォレットが関係している
• オフショアVASPと接点がある
• 金額が大きい

このような要素を見つけたら、なぜ追加確認が必要になり得るのかを文章で残します。

実務では、これに顧客情報、過去の取引パターン、取引目的、法域、制裁リスト、社内ルール、法令上の要件などが加わります。
そのため、このコードはあくまで概念理解用です。

9.10 まとめて見ると、最近の論点は「見え方を変える要素」

この章で扱ったテーマは、一見すると別々の話に見えます。

ステーブルコインは資産の種類の話。
ミキサーはプライバシーの話。
ブリッジはチェーン間移動の話。
DeFiはスマートコントラクトの話。
アンホステッドウォレットは鍵管理の話。
オフショアVASPは規制・監督の話。

しかし、AMLの観点から見ると、共通点があります。

それは、資金の流れの見え方を変える要素 だということです。

論点	見え方がどう変わるか
ステーブルコイン	価格変動を抑えた資金移動として使われ、利用範囲が広がる
ミキサー	入金元と出金先のつながりが見えにくくなる場合がある
ブリッジ	チェーンをまたぐため、複数台帳をつなげて見る必要がある
DeFi	スマートコントラクト処理を読まないと取引の意味が分かりにくい
アンホステッドウォレット	KYC情報と直接結びつかない場合がある
オフショアVASP	どの法域で誰が監督するのかが複雑になる

このように整理すると、最近の論点も少し見通しがよくなります。

💡 豆知識
暗号資産AMLは、単に資金の矢印を追うだけではありません。
ステーブルコイン、ブリッジ、DeFi、アンホステッドウォレット、オフショアVASPなどの文脈を読み、取引履歴を意味のある説明へ変える 翻訳 に近い面があります。

この感覚を持っておくと、暗号資産AMLを「規制の話」だけでなく、情報セキュリティやログ分析に近いテーマとして理解しやすくなります。

9.11 この章のまとめ

この章では、暗号資産AMLにおける最近の論点として、ステーブルコイン、ミキサー、ブリッジ、DeFi、アンホステッドウォレット、オフショアVASPを整理しました。

どれも正当な利用がある一方で、AML上は確認ポイントになり得ます。

この章で押さえたいポイントは、次の通りです。

• ステーブルコインは、送金・決済に便利な一方で、広く使われるためAML上の確認対象になりやすい
• ミキサーは、プライバシー保護と不正利用リスクの両面から見る必要がある
• ブリッジを使うと、チェーンをまたいだ資金移動の対応関係を確認する必要がある
• DeFiでは、スマートコントラクトの処理内容を読まないと取引の意味が分かりにくい
• アンホステッドウォレットは自己管理の基本的な形だが、KYC情報と直接結びつかない場合がある
• オフショアVASPでは、登録・監督法域やTravel Rule対応などが確認ポイントになる
• これらの論点は単独ではなく、組み合わさって現れることがある
• 複雑な経路があるから不正と決めつけるのではなく、観察、推定、追加確認を分けて考えることが大切

ここまでで、暗号資産AMLの基本、オンチェーンで見える情報、取引解析、外部情報、Red Flag、KYC・Travel Rule、リスクスコアリング、最近の論点まで整理してきました。

次の章では、ここまでの内容を踏まえて、暗号資産AMLでよくある誤解を整理します。
特に、「暗号資産は完全匿名」「オンチェーン分析なら全部分かる」「リスクスコアが高ければ犯罪」 といった極端な見方を、少しずつほどいていきます。

---

10. よくある誤解

この章では、ここまで整理してきた内容をもとに、暗号資産AMLでよくある誤解を確認します。
ポイントは、暗号資産AMLを「完全匿名か、全部追跡できるか」の二択で見ないことです。

ここまで、暗号資産AMLについて、身近なお金の履歴から始めて、AML/CFT、オンチェーンで見える情報、取引解析、外部情報、Red Flag、KYC・Travel Rule、リスクスコアリング、最近の論点まで整理してきました。

ここまで来ると、暗号資産AMLはかなり広いテーマだと分かります。

技術だけでもありません。
法律だけでもありません。
取引所だけの話でもありません。
そして、ブロックチェーンを見ればすべて分かる、という単純な話でもありません。

暗号資産AMLでは、次のような情報を組み合わせて考えます。

情報の種類	例	役割
オンチェーン情報	アドレス、トランザクション、金額、時刻、コントラクト呼び出し	公開履歴から資金の流れを確認する
外部情報	取引所ラベル、公式サイト、SNS、公的リスト、調査レポート	アドレスに文脈を与える
事業者側の情報	KYC、入出金履歴、顧客リスク評価、Travel Rule情報	本人確認や取引目的の確認に関係する
分析結果	Red Flag、リスクスコア、クラスタリング、資金フロー	追加確認の優先順位づけに使う
実務判断	疑わしい取引届出、取引制限、法執行機関との連携など	ルールや手続きにもとづいて対応する

このように、暗号資産AMLは複数の情報を重ねて考える領域です。

そのため、極端な理解をしてしまうと、技術的にも実務的にも誤解が生まれやすくなります。

この章では、特に混同しやすい考え方を整理していきます。

10.1 誤解1：暗号資産は完全匿名である

最初に多い誤解は、暗号資産は完全匿名である というものです。

たしかに、BitcoinやEthereumのようなパブリックブロックチェーンでは、取引履歴に利用者の本名がそのまま表示されるわけではありません。
外から見えるのは、0x... のようなアドレスや、Bitcoinアドレスのような文字列です。

そのため、銀行口座の名義を見るように、すぐに「この人の取引だ」と分かるわけではありません。

ただし、これは 完全匿名 という意味ではありません。

Bitcoin.orgは、Bitcoinは匿名の決済ネットワークだと思われがちだが、実際にはすべてのBitcoin取引が公開され、追跡可能で、ネットワーク上に永続的に保存されると説明しています。

参考: Bitcoin.org: Protect your privacy

つまり、Bitcoinのようなパブリックブロックチェーンでは、実名は直接見えにくい一方で、取引履歴は見える場合があります。

誤解	より正確な見方
暗号資産は完全匿名である	多くの場合、実名ではなくアドレスで見えるため、仮名性に近い
名前が見えないなら追跡できない	名前が見えなくても、アドレス間の資金移動を追える場合がある
アドレスだけなら何も分からない	取引履歴や外部情報と結びつくと、意味を持つ場合がある

身近な例でいえば、SNSのユーザー名に少し似ています。

ユーザー名だけを見ても本名は分かりません。
しかし、投稿履歴、投稿時間、リンク先、他のサービスで使っている同じIDなどが積み重なると、そのアカウントの行動パターンが見える場合があります。

ブロックチェーンのアドレスも、これに近い面があります。

アドレスだけでは誰か分からない。
でも、そのアドレスの履歴は見えることがある。
そして、外部情報と結びつくと、アドレスの意味が変わることがあります。

そのため、この記事では暗号資産を 完全匿名 とは表現せず、必要に応じて 仮名性 という言葉で整理しています。

10.2 誤解2：オンチェーン分析をすれば何でも分かる

次の誤解は、反対方向の極端な見方です。

取引履歴が公開されているなら、オンチェーン分析をすれば全部分かるのでは？

これも注意が必要です。

オンチェーン分析で分かるのは、基本的には ブロックチェーン上に記録された情報 です。

たとえば、次のようなことは確認できる場合があります。

• どのアドレスから、どのアドレスへ送られたか
• どのくらいの金額・数量が移動したか
• いつごろブロックに記録されたか
• どのスマートコントラクトが呼び出されたか
• 既知の取引所、ブリッジ、DeFi、制裁対象アドレスなどと接点があるか

一方で、次のようなことはオンチェーン情報だけでは分からない場合があります。

• アドレスを実際に操作した人物
• 取引の目的や背景
• 取引所内部で誰の口座に反映されたか
• その取引が法的にどう評価されるか
• その人が意図して資金を受け取ったのか、巻き込まれたのか

オンチェーンで見えること	それだけでは分からないこと
アドレスAからBへ資金が移動した	AやBを誰が管理しているか
取引所関連アドレスへ入金された	取引所内部でどの利用者に紐づくか
高リスクラベルのアドレスと接点がある	犯罪関与があるか
複数アドレスへ資金が分散した	隠蔽目的なのか、通常の業務処理なのか
ブリッジを経由した	どのチェーン上のどの活動と正確に対応するか

オンチェーン分析は強力な手がかりになります。
しかし、万能ではありません。

公開履歴から資金の流れを確認し、外部情報と照合し、必要に応じてKYCやTravel Ruleの情報、取引所内部の記録、法執行上の情報などと組み合わせることで、少しずつ見える範囲が広がります。

ここで大切なのは、観察できること と 推定できること と 断定できること を分けることです。

たとえば、次の表現はかなり意味が違います。

断定しすぎた表現	より慎重な表現
この人が犯人です	このアドレスは、問題となっている資金移動と接点があります
この取引はマネロンです	この取引は、追加確認が必要なパターンに該当する可能性があります
取引所へ入ったので換金されました	取引所関連アドレスへ入金された可能性がありますが、内部処理は外部から断定しにくいです

暗号資産AMLでは、この表現の差がとても重要です。

10.3 誤解3：リスクスコアが高いなら犯罪である

第8章では、リスクスコアリングを扱いました。

リスクスコアは、取引やアドレスを確認するときに便利です。
たとえば、高リスクラベルとの接点、短時間の連続取引、複数アドレスへの分散、Travel Rule情報の不足などをもとに、追加確認の優先順位を考えることができます。

ただし、リスクスコアが高いことは、犯罪の証明ではありません。

FATFのRed Flag Indicatorsも、暗号資産が犯罪活動に使われているかを検知する助けになる指標として整理されていますが、Red Flagはあくまで疑わしい可能性を示すものであり、それだけで犯罪関与を断定するものではありません。

参考: FATF: Virtual Assets Red Flag Indicators

身近な例でいうと、クレジットカード会社から「普段と違う利用がありました」と通知が来ることがあります。

この通知は、必ず不正利用があったという意味ではありません。
旅行中の買い物、引っ越しに伴う大きな支払い、家族へのプレゼントなど、正当な理由がある場合もあります。

リスクスコアも同じです。

状態	意味	注意点
スコアが低い	現時点のルールでは目立つリスクが少ない	安全を保証するわけではない
スコアが中程度	いくつか確認したい点がある	文脈確認が必要
スコアが高い	追加確認の優先度が高い	犯罪と断定するものではない
スコアが変化した	新しい情報やラベル更新の影響があるかもしれない	根拠を確認する必要がある

そのため、記事内では次のような考え方を使います。

リスクスコアは、取引やアドレスを確認するための 優先順位づけの材料 です。
点数そのものよりも、「なぜその点数になったのか」を説明できることが大切です。

10.4 誤解4：Red Flagに当てはまったら不正である

Red Flagは、直訳すると「赤い旗」です。
ただし、第6章でも整理したように、暗号資産AMLでは 危険を断定する赤信号 というより、追加確認を促す付箋 に近いものとして考えると分かりやすいです。

たとえば、次のような取引があったとします。

• 短時間に複数アドレスへ資金が分かれる
• 高リスクとされるサービスと接点がある
• 取引目的と金額の説明が合わない
• 監督が十分でない可能性のあるVASPと接点がある
• 匿名性を高めるサービスを経由している可能性がある

これらは確認ポイントになります。

しかし、それだけで不正とは言えません。

Red Flagの例	追加確認したいこと	断定してはいけないこと
短時間に多数の取引	業務処理、分配、攻撃後の資金移動などの文脈	多数取引だから不正
高リスクアドレスとの接点	直接接点か、何ホップ離れているか、被害者側か	接点があるから犯罪者
ミキサー関連サービスとの接点	正当なプライバシー目的か、不正資金隠しの可能性か	ミキサー関連なら全員不正
海外VASPとの接点	登録・監督状況、Travel Rule対応、顧客所在	海外なら危険

Red Flagは、確認を始めるための目印 です。
判断を終えるための答えではありません。

10.5 誤解5：KYCやTravel Ruleがあれば、オンチェーン分析は不要である

KYCやTravel Ruleは、暗号資産AMLでとても重要です。

KYCは、本人確認や顧客確認に関係します。
Travel Ruleは、暗号資産の移転時に送付人・受取人に関する情報を関係する事業者間で通知する仕組みです。

FATFは、VASPに対して顧客管理、記録保存、疑わしい取引報告、送付人・受取人情報の取得・保持・安全な送信などを求めています。

参考: FATF: Virtual Assets

また、日本の金融庁も、暗号資産移転における送付人・受取人情報の通知、いわゆるTravel Ruleに関する情報を公表しています。

参考: 金融庁: Notification of Originator and Beneficiary Information upon Crypto Assets Transfer

ただし、KYCやTravel Ruleがあるからといって、オンチェーン分析が不要になるわけではありません。

理由は、見ている情報のレイヤーが違うからです。

観点	主に扱う情報	役割
オンチェーン分析	アドレス、取引、金額、時刻、コントラクト、資金フロー	公開履歴から資金の流れを確認する
KYC	氏名、本人確認書類、住所、取引目的など	顧客が誰かを確認する
Travel Rule	送付人・受取人に関する情報	VASP間の移転情報をつなげる
取引モニタリング	顧客属性、取引履歴、通常パターンとの差分	不自然な取引を検知する

オンチェーン分析は、公開履歴を見るための道具です。
KYCやTravel Ruleは、オンチェーンだけでは見えない本人情報や送受信者情報を補う仕組みです。

どちらか一方だけで十分というより、役割が違います。

10.6 誤解6：KYCがあれば、すべての本人が分かる

逆に、KYCを過大評価する誤解もあります。

取引所などのVASPで本人確認が行われている場合、そのVASPの内部では、利用者アカウントと入出金履歴が結びつくことがあります。

しかし、それは一般の人が自由に見られる情報ではありません。
また、すべての暗号資産取引がVASPを通るわけでもありません。

たとえば、次のような場面があります。

• アンホステッドウォレット同士の取引
• DeFiスマートコントラクトとのやり取り
• ブリッジを使ったチェーン間移動
• 海外VASPやオフショアVASPとの接点
• 取引所内部での台帳処理

このような場面では、オンチェーン情報、外部情報、事業者情報、法域ごとの制度を組み合わせて見る必要があります。

誤解	実際には
KYCがあれば、すべてのアドレスの本人が分かる	KYC情報は主に事業者が管理する情報であり、すべてのアドレスに直接付くわけではない
取引所に入金したら、外から利用者名まで分かる	取引所内部情報は通常オンチェーンでは見えない
Travel Ruleがあれば、P2P取引もすべて同じように追える	VASPを介さない取引では別の課題がある

ここでも、見える情報と見えない情報を分けることが大切です。

10.7 誤解7：ミキサーやプライバシー技術はすべて悪い

第9章では、ミキサーやプライバシー技術についても触れました。

ここで注意したいのは、プライバシーを高める技術 = すべて悪い と短絡しないことです。

ブロックチェーンは透明性が高い一方で、利用者の行動履歴が見えやすくなる場合があります。
寄付、給与、NFT購入、DeFi利用、個人間送金などがアドレス単位で見えると、プライバシー上の課題が出ることがあります。

そのため、プライバシーを高める技術には正当な目的もあります。

一方で、不正資金の流れを分かりにくくするために悪用される可能性もあります。

観点	正当な目的の例	AML上の注意点
プライバシー保護	寄付者や利用者の行動履歴を過度に公開しない	資金の出所や移動経路が見えにくくなる場合がある
企業利用	取引先や支払い情報を競合に見せたくない	透明性と監査可能性のバランスが必要
個人利用	保有資産や支払い先を公開したくない	不正資金隠しと区別するための文脈確認が必要
不正利用	犯罪収益の移動経路をぼかす	Red Flagや追加確認の対象になり得る

したがって、この記事ではミキサーやプライバシー技術を、追跡回避の手順としては扱いません。
あくまで、透明性とプライバシーのバランス、そしてAML上の確認ポイントとして扱います。

10.8 誤解8：ブリッジやDeFiを通ると追跡できない

ブリッジやDeFiを通ると、資金の流れはたしかに複雑になります。

チェーンをまたぐ。
スマートコントラクトを呼び出す。
トークンが別の形になる。
イベントログを読む必要がある。
内部的な処理や流動性プールを考慮する必要がある。

このように、単純な A -> B の送金より難しくなります。

ただし、難しくなることと、完全に追えなくなることは同じではありません。

経路	難しくなる理由	それでも確認できる場合があること
ブリッジ	チェーンをまたぐため対応関係を確認する必要がある	ロック、ミント、バーン、リリースなどのイベント
DeFi	コントラクト処理が複雑	呼び出したコントラクト、イベントログ、トークン移動
DEX	相手方が個別ユーザーではなく流動性プールになる	スワップの入力・出力、プール、ルート
ステーブルコイン	複数チェーンで使われることがある	発行体、コントラクト、移転履歴、凍結・管理機能の有無

つまり、ブリッジやDeFiは「追跡不能になる魔法」ではありません。
ただし、解析の前提が増えるため、より慎重に読む必要があります。

10.9 誤解9：規制情報は一度調べればずっと同じ

暗号資産AMLでは、技術だけでなく規制情報も重要です。

しかし、規制や制裁情報は変わります。

たとえば、FATFは2025年のTargeted Updateで、VASPの登録・監督、Travel Rule、ステーブルコイン、オフショアVASP、不正利用リスクなどを継続課題として整理しています。

参考: FATF: Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs, 2025

また、制裁対象や公的リストも更新されることがあります。

そのため、記事やレポートを書くときは、次のような姿勢が必要です。

• 投稿前に一次情報を確認する
• 参照日や検証日を残す
• 法域による違いを断定しすぎない
• 古い情報をそのまま使わない
• 公的機関や規制当局の最新情報を優先する

Qiita記事として公開する場合も、規制や制裁に関する記述は特に注意が必要です。

技術的な説明なら比較的長く使える内容もありますが、制度や制裁は更新される可能性があります。
そのため、本文では「投稿時点では」「公式情報を確認する必要があります」のような表現を適切に使うと安全です。

10.10 誤解10：暗号資産AMLは金融機関だけの話である

最後に、暗号資産AMLは金融機関や取引所だけの話だと思われることがあります。

もちろん、VASP、金融機関、規制当局、法執行機関にとって重要なテーマです。
しかし、エンジニアやセキュリティを学ぶ人にとっても関係があります。

理由は、暗号資産AMLが次のような技術テーマとつながるからです。

技術テーマ	暗号資産AMLとの関係
ログ分析	取引履歴やイベントログを読み、異常な動きを確認する
グラフ解析	アドレスを点、取引を線として資金の流れを見る
データ前処理	複数チェーン、複数トークン、外部ラベルを整理する
リスクスコアリング	追加確認の優先順位を数値化する
説明可能性	なぜアラートが出たのか説明できるようにする
プライバシー保護	透明性と利用者保護のバランスを考える
セキュリティ運用	不正利用、詐欺、ハッキング後の資金移動を調査する

暗号資産AMLは、単なる規制用語ではありません。
公開履歴、外部情報、ルール、データ分析、セキュリティ運用が重なるテーマです。

その意味では、情報セキュリティやデータ分析を学ぶ人にとっても、十分に学ぶ価値があります。

10.11 小さなコードで見る：断定しすぎた表現をチェックする

ここまで、暗号資産AMLでは断定しすぎないことが大切だと繰り返し説明してきました。

そこで最後に、学習用の小さなコードで、分析メモに含まれる 断定しすぎた表現 を簡単にチェックしてみます。

これは実務の文章校正ツールではありません。
あくまで、記事やレポートを書くときに「断定しすぎていないか」を意識するための簡易モデルです。

# これは、暗号資産AMLの分析メモで「断定しすぎた表現」がないかを
# 確認するための学習用コードです。
# 実務の法的判断やコンプライアンス判断を自動化するものではありません。

from dataclasses import dataclass


@dataclass
class Finding:
    """分析メモ1件分を表す学習用データ構造です。"""
    text: str
    source: str


# 架空の分析メモを用意します。
# わざと断定しすぎた表現と、慎重な表現を混ぜています。
findings = [
    Finding(
        text="このアドレスは犯罪者のものです。",
        source="オンチェーン取引履歴",
    ),
    Finding(
        text="このアドレスは高リスクラベルの付いたアドレスと接点があります。",
        source="オンチェーン取引履歴 + 外部ラベル",
    ),
    Finding(
        text="取引所関連アドレスへ入金されたため、換金されたと断定できます。",
        source="ブロックエクスプローラーのラベル",
    ),
    Finding(
        text="取引所関連アドレスへ入金された可能性がありますが、内部処理までは外部から断定できません。",
        source="ブロックエクスプローラーのラベル",
    ),
]


# 断定が強すぎる可能性があるキーワードを用意します。
# 実務では文脈も見る必要がありますが、ここでは学習用に単純化しています。
strong_words = [
    "犯罪者",
    "断定できます",
    "必ず",
    "完全匿名",
    "全部分かる",
    "不正です",
]


# 慎重な表現に使いやすいキーワードも用意します。
# これらが含まれていれば常に正しいわけではありませんが、
# 推定や限界を示す表現として参考になります。
cautious_words = [
    "可能性",
    "接点",
    "追加確認",
    "断定できません",
    "推定",
    "確認が必要",
]


def review_finding(finding):
    """分析メモの表現が強すぎないかを簡易的に確認します。"""
    warnings = []

    # 強すぎる可能性がある語が含まれているか確認します。
    for word in strong_words:
        if word in finding.text:
            warnings.append(f"断定しすぎた表現の可能性: {word}")

    # 慎重な表現が含まれているか確認します。
    has_cautious_word = any(word in finding.text for word in cautious_words)

    if not has_cautious_word:
        warnings.append("推定や限界を示す表現が不足している可能性があります")

    return warnings


# 各メモを確認し、注意点を表示します。
for finding in findings:
    print("分析メモ:", finding.text)
    print("情報源:", finding.source)

    warnings = review_finding(finding)

    if warnings:
        print("確認ポイント:")
        for warning in warnings:
            print(" -", warning)
    else:
        print("確認ポイント: 目立つ断定表現はありません")

    print()

このコードでは、犯罪者、断定できます、完全匿名 のような強い表現が含まれているかを簡単に確認しています。

もちろん、実際の文章では文脈が重要です。
単語が含まれているだけで必ず悪いわけではありません。

ただ、暗号資産AMLの記事やレポートでは、次のような表現を意識すると安全です。

書き方の観点	避けたい書き方	より安全な書き方
本人特定	この人のアドレスです	このアドレスは、公開情報Aと結びつく可能性があります
犯罪関与	犯罪者です	高リスクアドレスとの接点が確認できます
取引目的	資金洗浄です	資金移動の意図はオンチェーン情報だけでは断定できません
換金	換金されました	取引所関連アドレスへ入金された可能性があります
安全性	リスクはありません	現時点の確認範囲では目立つリスクは確認できません

技術記事では、正確な用語説明だけでなく、言い切れる範囲を守ること も大切です。

10.12 図で整理：極端な見方を避ける

暗号資産AMLで避けたい極端な見方を、図で整理すると次のようになります。

この記事全体で何度も出てきたように、暗号資産AMLでは「見える」と「分かる」を分けることが大切です。

• 見える情報
• 推定できる情報
• 追加確認が必要な情報
• 法的・実務的な判断が必要な情報

これらを一つずつ分けることで、過度に怖がりすぎず、逆に過信しすぎず、暗号資産AMLを理解しやすくなります。

💡 豆知識
AMLの記事では、「ここまでは確認できる」「ここから先は推定である」と分けて書くことが大切です。
これは弱い書き方ではなく、見えている情報と見えていない情報を区別するための正確な書き方です。

10.13 この章のまとめ

この章では、暗号資産AMLでよくある誤解を整理しました。

暗号資産AMLは、完全匿名か完全追跡可能か、という二択ではありません。
オンチェーン情報、外部情報、KYC、Travel Rule、Red Flag、リスクスコアリングなどを組み合わせながら、見えることと見えないことを分けて考える必要があります。

この章で押さえたいポイントは、次の通りです。

• 暗号資産は完全匿名とは限らず、多くのパブリックチェーンでは仮名性と透明性が同時に存在する
• オンチェーン分析は強力な手がかりになるが、本人や意図まですべて分かるわけではない
• リスクスコアが高いことは、犯罪の証明ではなく追加確認の目印である
• Red Flagは不正の断定ではなく、調査や確認を始めるためのサインである
• KYCやTravel Ruleは重要だが、それだけですべての取引や本人が分かるわけではない
• プライバシー技術には正当な目的もあり、悪用リスクと分けて考える必要がある
• ブリッジやDeFiは追跡を難しくすることがあるが、必ず追跡不能になるわけではない
• 規制や制裁情報は変化するため、投稿前に一次情報を確認する必要がある
• 暗号資産AMLは、金融機関だけでなく、ログ分析、グラフ解析、リスク評価、セキュリティ運用とも関係する

ここまでで、暗号資産AMLに関する主要な考え方を一通り整理できました。

次の章では、記事全体を振り返りながら、暗号資産AMLを学ぶときに意識したいことをまとめます。
最後に、派生元記事である 「身近な記録から理解するブロックチェーンの全体像」 とのつながりも確認し、ブロックチェーン全体の中で本記事がどの位置にあるのかを整理します。

---

11. まとめ

ここまで、暗号資産AMLにおける取引解析の基本を、身近なお金の履歴から順番に整理してきました。

最初は、スマホ決済履歴、銀行口座の入出金履歴、クレジットカード明細、フリマアプリの取引履歴のような、普段の生活にある記録から考えました。
そこから、AML/CFT、オンチェーン情報、アドレス、外部ラベル、Red Flag、VASP、KYC、Travel Rule、リスクスコアリング、最近の論点へと少しずつ広げてきました。

暗号資産AMLという言葉だけを見ると、かなり専門的で、金融機関や規制当局だけの話に見えるかもしれません。
しかし、この記事で見てきたように、その入口には 「記録を見て、お金の流れを確認する」 という、とても基本的な考え方があります。

ただし、暗号資産では、その記録の見え方が少し独特です。

銀行口座やカード明細のように、サービス提供者の内部で本人情報と結びつく記録もあります。
一方で、BitcoinやEthereumのようなパブリックブロックチェーンでは、実名ではなくアドレスを中心に、取引履歴が公開される場合があります。

Bitcoin.orgは、Bitcoinの取引は公開され、追跡可能で、ネットワーク上に永続的に保存されると説明しています。

参考: Bitcoin.org: Protect your privacy

この特徴により、暗号資産では、アドレス間の資金移動をあとから確認できる場合があります。
その一方で、アドレスだけを見ても、現実世界の誰が管理しているのか、なぜその取引を行ったのか、犯罪に関係しているのかまでは、すぐには分かりません。

つまり、暗号資産AMLを理解するときに大切なのは、次のように分けて考えることです。

観点	何を意味するか	注意点
見えること	アドレス、取引ID、金額、時刻、送受信関係など	公開履歴として確認できる情報に限られる
推定できること	資金の流れ、アドレス同士の関係、既知ラベルとの接点など	分析手法や外部情報に依存する
追加確認が必要なこと	本人、取引目的、資金源、取引所内部の利用者など	KYC情報、内部記録、正当な手続きが必要になる場合がある
断定してはいけないこと	犯罪関与、制裁回避、資金洗浄の成立など	技術的な観察だけで軽く言い切らない

この「見えること」と「言い切れること」を分ける姿勢が、本記事全体の大きなテーマでした。

11.1 本記事で整理したこと

本記事では、暗号資産AMLをいきなり規制用語から説明するのではなく、身近なお金の記録から出発しました。

記事全体を振り返ると、次のような流れになります。

第1章では、スマホ決済やカード明細のような身近な履歴から、記録を確認する意味を見ました。
変わった履歴があるからといって、すぐに不正とは言えません。
しかし、気になる点があれば追加確認のきっかけになります。

第2章では、AML/CFTをざっくり整理しました。
AMLはマネー・ローンダリング対策、CFTはテロ資金供与対策です。
UNODCが説明するように、マネー・ローンダリングは一般に Placement、Layering、Integration の流れで説明されることがあります。

参考: UNODC: Money-Laundering Overview

第3章では、暗号資産では何が見えるのかを整理しました。
アドレス、トランザクションID、金額、時刻、ブロック番号などは確認できる場合があります。
一方で、本人名、取引目的、取引所内部の利用者情報は、オンチェーン情報だけでは見えにくいことも確認しました。

第4章では、アドレスを点、取引を線として見ることで、資金の流れをグラフのように整理できることを見ました。
ただし、グラフ上でつながっていることと、同じ人物・組織が関係していることは同じではありません。

第5章では、アドレスと外部情報が結びつく場面を整理しました。
取引所、SNS、公式サイト、ENS、ブロックエクスプローラーのラベル、公的リストなどにより、アドレスの意味が強くなる場合があります。
ただし、外部ラベルにも根拠の強さや更新時期があるため、絶対視しないことが大切です。

第6章では、Red Flagを「不正の証明」ではなく、「追加確認が必要かもしれないサイン」として整理しました。
FATFのRed Flag Indicatorsは、暗号資産の疑わしい取引を検知するための観点を整理していますが、個別の犯罪関与を自動的に断定するものではありません。

参考: FATF: Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing

第7章では、VASP、KYC、Travel Ruleの関係を整理しました。
オンチェーン情報だけでは見えない本人確認情報や送付人・受取人情報を、事業者側の確認や制度が補う場面があります。
FATFは、VASPに対して顧客管理、記録保存、疑わしい取引報告、送付人・受取人情報の取得・保持・安全な送信などを求めています。

参考: FATF: Virtual Assets

第8章では、リスクスコアリングと誤検知・過検知を整理しました。
リスクスコアは、犯罪を証明する点数ではありません。
追加確認の優先順位を考えるための材料です。
そのため、なぜスコアが上がったのか、どの要素が理由になっているのかを説明できることが重要です。

第9章では、ステーブルコイン、ミキサー、ブリッジ、DeFi、アンホステッドウォレット、オフショアVASPなど、最近の論点を整理しました。
これらは便利な仕組みでもありますが、AML上は資金の流れや本人確認情報との接点が複雑になりやすいテーマです。
FATFも、ステーブルコインやアンホステッドウォレット、オフショアVASPなどを継続的な論点として取り上げています。

参考: FATF: Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs, 2025

第10章では、よくある誤解を整理しました。
「暗号資産は完全匿名」「オンチェーン分析で全部分かる」「リスクスコアが高いから犯罪」「KYCがあればすべて分かる」といった極端な理解を避けることが重要です。

11.2 暗号資産AMLを学ぶときに意識したいこと

暗号資産AMLを学ぶときは、技術、制度、運用、プライバシーを分けながら見ると理解しやすくなります。

見る観点	主な内容	学ぶときの注意点
技術	ブロックチェーン、アドレス、トランザクション、スマートコントラクト	見える情報と見えない情報を分ける
解析	資金フロー、グラフ構造、ラベル付け、スコアリング	推定を断定として扱わない
制度	AML/CFT、KYC、VASP、Travel Rule、制裁対応	国や時期で変わるため一次情報を確認する
運用	取引モニタリング、アラート確認、疑わしい取引届出	誤検知・過検知・見逃しのバランスを考える
プライバシー	仮名性、透明性、外部情報との結合	正当なプライバシー保護と悪用リスクを分ける

特に、暗号資産AMLでは 技術だけでも、制度だけでも不十分 です。

ブロックチェーンの取引履歴を読む力は重要です。
しかし、それだけで本人や意図が分かるわけではありません。

一方で、KYCやTravel Ruleの制度を知っていても、オンチェーン上で何が見えるのかを知らなければ、資金の流れを具体的にイメージしにくくなります。

そのため、次のような見方が大切になります。

この図のように、暗号資産AMLは、オンチェーン情報、オフチェーン情報、運用上の判断が重なる領域です。

どれか一つだけを見て「全部分かった」と考えるのではなく、それぞれの役割と限界を意識することが大切です。

11.3 今後深掘りしたいテーマ

本記事では、暗号資産AMLにおける取引解析の基本を広く整理しました。
ただし、この分野には、さらに深掘りできるテーマがたくさんあります。

たとえば、次のようなテーマです。

深掘りテーマ	内容の例
ブロックチェーンの匿名性と追跡可能性	仮名性、透明性、外部情報との結合、プライバシー課題
ステーブルコインとAML	送金・決済で使いやすい一方、規制・監督上どのような論点があるか
ブリッジとクロスチェーン解析	異なるチェーン間で資金移動をどのように対応づけるか
DeFiと取引解析	スマートコントラクト、DEX、流動性プール、イベントログの読み方
リスクスコアリングの設計	説明可能性、しきい値、誤検知・見逃し、評価指標
Travel Ruleの実装課題	VASP間連携、アンホステッドウォレット、法域差、データ保護
プライバシー保護技術	ゼロ知識証明、プライバシーコイン、正当な匿名性と悪用リスク
インシデント対応と資金追跡	ハッキング後の初動、資金フロー整理、証拠保全、関係機関との連携

これらは、どれも一つの記事だけで説明し切るには大きなテーマです。
本記事は、その入口として、暗号資産AMLでよく出てくる言葉や考え方をつなぐ役割を目指しました。

11.4 最後に

暗号資産AMLを学ぶとき、最初に出てくる略語や規制用語の多さに戸惑うかもしれません。

AML、CFT、KYC、VASP、Travel Rule、Red Flag、リスクスコアリング。
どれも最初は固く見える言葉です。

しかし、この記事で繰り返し見てきたように、入口はそれほど遠いものではありません。

スマホ決済履歴を確認する。
カード明細に見覚えのない請求がないかを見る。
銀行振込の相手先や金額を確認する。
システムログから、誰がいつ何をしたかを追う。

このような「記録を見て、流れを確認する」考え方の延長線上に、暗号資産AMLの取引解析があります。

もちろん、実際の暗号資産AMLはもっと複雑です。
複数チェーン、スマートコントラクト、ステーブルコイン、DeFi、ブリッジ、取引所内部情報、国際的な規制、制裁対応など、多くの要素が関係します。

それでも、最初に持っておきたい姿勢はシンプルです。

見える情報を丁寧に整理する。
推定と断定を分ける。
追加確認が必要なところを見極める。
技術・制度・プライバシーのバランスを意識する。

暗号資産AMLは、「すべてを疑うための技術」ではありません。
また、「ブロックチェーンなら何でも分かる」と過信するためのものでもありません。

公開された記録を正しく読み、必要な確認につなげ、不正利用の防止と利用者保護の両方を考えるための分野です。

この記事が、暗号資産AMLやオンチェーン取引解析を学び始めるときの、最初の地図になれば幸いです。