ブロックチェーンの匿名性と追跡可能性を整理する

概要

スマホ決済の履歴を見ると、「いつ、どこで、いくら使ったか」がきれいに並んでいます。
銀行口座の入出金履歴、交通系ICカードの乗車履歴、フリマアプリの取引履歴、レシートの束なども、普段はあまり意識しませんが、自分の行動をかなり細かく映す記録です。

たとえば、ある履歴に本名が直接書かれていなかったとしても、次のような情報が残っていたらどうでしょうか。

履歴の例	直接見える情報	そこから見えてきそうなこと
スマホ決済履歴	日時、店舗名、金額	よく行く店、生活圏、買い物の傾向
銀行口座の入出金履歴	振込先、入金元、金額	給与、家賃、サブスク、生活パターン
交通系ICカードの履歴	乗車駅、降車駅、日時	通学・通勤ルート、移動の時間帯
SNSのユーザー名	投稿、返信、フォロー関係	興味関心、人間関係、活動時間帯
フリマアプリの取引履歴	商品、評価、発送地域の一部	趣味、売買傾向、利用頻度

名前が直接見えないだけなら、一見すると匿名に感じるかもしれません。
しかし、履歴が積み重なると、その人の行動パターンや関係性が少しずつ見えてくることがあります。

ブロックチェーンの匿名性と追跡可能性も、最初はこれに近い感覚で捉えると分かりやすいです。

BitcoinやEthereumのようなパブリックブロックチェーンでは、利用者の実名そのものではなく、1A1z... や 0x... のような アドレス が取引に使われます。
アドレスは、銀行口座の名義やSNSの本名表示とは違い、見ただけで誰のものか分かるとは限りません。

そのため、ブロックチェーンは「匿名で使える」と説明されることがあります。

ただし、ここで大切なのは、名前が見えないこと と 履歴を追えないこと は同じではない、という点です。

Bitcoin.orgは、Bitcoinは匿名の決済ネットワークだと思われがちだが、実際には非常に透明性の高い決済ネットワークであり、すべてのBitcoin取引は公開され、追跡可能で、ネットワーク上に永続的に保存されると説明しています。
また、Bitcoinアドレスは残高や送金先を表す情報として使われ、アドレスが一度使われると、そのアドレスに関わる取引履歴と結びつくことも説明されています。

参考: Bitcoin.org: Protect your privacy

NISTの解説でも、ブロックチェーンでは利用者は pseudonymous、つまり実名ではなく別名・識別子で扱われる一方、アカウントは匿名ではなく、取引は公開され得ると説明されています。
ここでいう pseudonymous は、日本語では「仮名的」「仮名性」と訳すと分かりやすいです。

参考: NIST: Beyond Bitcoin: Emerging Applications for Blockchain Technology

ざっくり整理すると、次のようになります。

観点	ざっくりした意味	ブロックチェーンでのイメージ
匿名性	誰なのかが分からない性質	実名が直接出ない
仮名性	本名ではなく別の識別子で活動する性質	アドレスで取引する
透明性	記録を外部から確認できる性質	取引履歴が公開される
追跡可能性	記録の流れをたどれる性質	アドレス間の資金移動を追える場合がある

この表だけを見ると少し固く感じるかもしれません。
身近な例で言えば、SNSで本名を出さずにユーザー名だけで活動している状態に少し似ています。

ユーザー名だけでは、その人の本名はすぐには分かりません。
しかし、投稿内容、投稿時間、写真、リンク先、他のサービスで使っている同じIDなどが積み重なると、「このアカウントはこの人かもしれない」と推定できる場合があります。

ブロックチェーンでも同じように、アドレスだけを見ても、すぐに持ち主が分かるとは限りません。
一方で、取引履歴が公開されている場合、どのアドレスからどのアドレスへ、いつ、どのくらいの量が移動したのかをたどれることがあります。

もちろん、ここで注意したいのは、追跡できる可能性があること と 本人を必ず特定できること は違う、という点です。

取引履歴を分析しても、分かるのはあくまでアドレス間の動きや、資金の流れ、似た行動パターンです。
そのアドレスの持ち主が誰なのかを考えるには、取引所の本人確認情報、SNSで公開されたアドレス、Webサイトの寄付アドレス、事件資料、制裁リストなど、ブロックチェーン外の情報と結びつける必要があります。

また、分析には推定が含まれます。
同じ人物が複数のアドレスを使っていることもあれば、逆に一つのサービスが多くの利用者の取引をまとめていることもあります。
そのため、この記事では「このアドレスはこの人だ」と断定するのではなく、どのような情報が見え、どこから先は推定になるのか を分けて考えます。

この考え方は、暗号資産のAML/CFT、つまりマネーロンダリングやテロ資金供与への対策とも関係します。
FATFは、暗号資産や暗号資産サービス提供者に対するAML/CFT基準の実装状況を継続的に更新しており、2025年の更新でも、Travel Rule、VASPの登録・監督、ステーブルコインを含む不正利用リスクなどを取り上げています。

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

つまり、ブロックチェーンの追跡可能性は、単なる技術的な面白さだけではありません。
金融犯罪対策、取引所のコンプライアンス、インシデント対応、プライバシー保護、そして利用者の安全にも関わるテーマです。

一方で、透明性が高ければ高いほど、利用者のプライバシーが課題になる場面もあります。
たとえば、寄付先、給与の受け取り、NFTの購入、DeFiの利用履歴などがアドレス単位で見えてしまうと、本人の意図しない形で行動履歴が分析される可能性があります。

そのため、ブロックチェーンを理解するときは、次のどちらか一方だけで見ると少し危険です。

偏った見方	見落としやすい点
ブロックチェーンは匿名だから安全	取引履歴が公開され、後から分析される可能性がある
ブロックチェーンは追跡できるから何でも分かる	分析には推定が含まれ、本人特定には外部情報が必要になる
透明性が高いほど常に良い	監査しやすい一方で、プライバシー上の課題も出る
プライバシー技術を使えば完全に隠せる	技術や運用によって限界があり、法規制上の論点もある

本記事では、ブロックチェーンの匿名性と追跡可能性を、いきなり難しい暗号技術や事件分析から説明するのではなく、まずは身近な履歴の例から整理します。

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

• なぜブロックチェーンは匿名に見えるのか
• なぜ取引履歴を追跡できるのか
• 追跡で分かることと、分からないことは何か
• どのような外部情報と結びつくと、アドレスの意味が変わるのか
• AML/CFTやオンチェーン分析は、どのように関係するのか
• プライバシーを高める技術には、どのような考え方と注意点があるのか

この記事を読み終えるころには、次のような感覚を持てることを目指します。

ブロックチェーンは、単純に「匿名」でも「何でも追跡できる」でもありません。
実名が直接見えにくい仮名性と、取引履歴を確認しやすい透明性が同時に存在するため、どこまで見えて、どこから推定になるのかを分けて考えることが大切です。

💡 豆知識
Bitcoinは「匿名で誰にも見えない送金」というより、アドレスで動きながら取引履歴は広く確認できる という点が特徴的です。
銀行口座の履歴は通常、本人や金融機関など限られた関係者しか見られません。
一方で、Bitcoinのようなパブリックブロックチェーンでは、ブロックエクスプローラーなどを通じて取引履歴を確認できます。
この「名前は直接出ないが、履歴は見える」という組み合わせが、匿名性と追跡可能性を考える出発点になります。

この記事の立ち位置

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

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

本記事では、その中でも特に 匿名性 と 追跡可能性 に絞って深掘りします。

ブロックチェーンは、「誰が使っているか分かりにくい」と説明されることがあります。
一方で、Bitcoin.orgが説明しているように、Bitcoinの取引は公開され、追跡可能で、ネットワーク上に保存されるという特徴もあります。

参考: Bitcoin.org: Protect your privacy

つまり、ブロックチェーンは単純に「匿名で見えない仕組み」とは言い切れません。
むしろ、実名は直接見えにくいのに、取引履歴は見えやすい という、少し不思議な性質を持っています。

この性質は、情報セキュリティの観点ではとても重要です。

たとえば、取引履歴が公開されていることは、不正な資金移動の調査や監査に役立つ場合があります。
その一方で、寄付、給与、買い物、NFT、DeFiの利用履歴などがアドレス単位で見えてしまうと、利用者のプライバシーに関わる問題にもなります。

本記事では、ブロックチェーンを「匿名か、匿名ではないか」という二択で見るのではなく、次のように分けて整理します。

観点	本記事での見方
匿名性	実名や本人情報が直接見えにくい性質
仮名性	アドレスのような識別子で活動する性質
透明性	取引履歴や残高などを外部から確認できる性質
追跡可能性	公開された履歴や外部情報をもとに、資金の流れをたどれる場合がある性質
プライバシー	透明性が高い環境で、どこまで個人や行動が見えてしまうかという課題

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

派生元記事	本記事
ブロックチェーン全体の地図を整理する	匿名性と追跡可能性に絞って整理する
身近な記録からブロックチェーンを説明する	身近な履歴から「名前が見えないこと」と「行動が見えること」を説明する
ハッシュ、署名、分散、コンセンサスなどを広く扱う	アドレス、取引履歴、オンチェーン分析、AML/CFTを扱う
情報セキュリティ上の強みと限界を広く整理する	透明性のメリットとプライバシー上の注意点を整理する

ただし、本記事は個別事件の犯人特定や、実在アドレスの追跡を行う記事ではありません。
また、ミキサーやプライバシー技術についても触れますが、追跡回避や不正利用の手順を説明することは目的としていません。

あくまで、ブロックチェーンの透明性・追跡可能性・プライバシー保護の関係を、初学者向けに整理する記事です。

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

Qiitaに投稿する際は、上記の ここに派生元記事のURLを挿入 の部分を、実際に投稿済みの派生元記事URLへ置き換えてください。

派生元記事では、ブロックチェーン全体の仕組みや、情報セキュリティ上の強み・限界を広く整理しています。
本記事では、その中の セキュリティ・分析編 として、匿名性、仮名性、透明性、追跡可能性、AML/CFT、プライバシー保護の関係を深掘りする位置づけです。

この記事で分かること

この記事で分かることは、次のとおりです。

• ブロックチェーンが「完全匿名」と言い切れない理由
• 匿名性、仮名性、透明性、追跡可能性の違い
• アドレスと実名がどのような関係にあるのか
• なぜ公開された取引履歴から資金の流れを追えることがあるのか
• 追跡で分かることと、分からないこと
• 取引所、SNS、公開アドレスなど、外部情報と結びつくポイント
• AML/CFTやオンチェーン分析との関係
• ミキサー、プライバシーコイン、ゼロ知識証明などの位置づけ
• 透明性とプライバシーをどうバランスよく考えるか
• ブロックチェーンの匿名性についてよくある誤解

特にこの記事では、次の2つを混同しないことを重視します。

混同しやすいこと	分けて考えたいこと
実名が見えない	誰の行動か完全に分からないとは限らない
アドレスが分かる	そのアドレスの持ち主を必ず特定できるとは限らない
取引履歴を追える	本人の意図や犯罪関与まで断定できるとは限らない
透明性が高い	いつでも利用者にとって安全とは限らない
プライバシー技術がある	常に完全匿名になるとは限らない

たとえば、ブロックエクスプローラーを使うと、あるアドレスから別のアドレスへ資金が移動したことを確認できる場合があります。
しかし、それだけで「このアドレスはこの人だ」と断定できるわけではありません。

一方で、取引所の入出金、SNSで公開された寄付アドレス、Webサイトに掲載された支払いアドレス、過去の事件資料などと結びつくと、アドレスの意味が変わることがあります。

このように、ブロックチェーンの追跡可能性は、ブロックチェーン上の情報だけで完結するとは限りません。
公開された取引履歴と、外部の情報が組み合わさることで、見えてくる範囲が変わります。

本記事では、この「どこまで見えて、どこから推定になるのか」を、できるだけ具体例を挟みながら整理していきます。

対象読者

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

• ブロックチェーンを学び始めた人
• 「ブロックチェーンは匿名らしい」と聞いたことがある人
• 「でも、取引は追跡できるらしい」と聞いて混乱している人
• 暗号資産AMLやオンチェーン分析に興味がある人
• 情報セキュリティやプライバシーの観点からブロックチェーンを理解したい人
• ゼロ知識証明やプライバシー技術に入る前に、まず全体像をつかみたい人
• 技術的な細部に入る前に、まず言葉の整理をしておきたい人

前提知識としては、次の程度を想定しています。

前提知識	必要度
ブロックチェーンが取引や状態を記録する仕組みであること	あると読みやすい
アドレスという識別子が使われること	記事内で説明するため、なくてもよい
ハッシュやデジタル署名の詳しい数学	なくてもよい
AML/CFTや金融規制の専門知識	なくてもよい
ゼロ知識証明や暗号技術の詳細	なくてもよい
実際のオンチェーン分析経験	なくてもよい

途中で、アドレス、トランザクション、ブロックエクスプローラー、オンチェーン分析、AML/CFT、ミキサー、ゼロ知識証明といった言葉が出てきます。

ただし、最初から全部を知っている必要はありません。
それぞれの用語は、できるだけ身近な例と一緒に説明します。

たとえば、アドレスは「本名ではなく、取引に使われる識別子」として扱います。
ブロックエクスプローラーは「ブロックチェーン上の取引履歴を検索できる検索サイト」のようなものとして紹介します。
オンチェーン分析は「公開された取引履歴をもとに、資金の流れやアドレス同士の関係を調べる作業」として説明します。

このように、難しい用語をいきなり定義だけで覚えるのではなく、具体例とセットで少しずつ整理していきます。

本記事で扱わないこと

本記事は、ブロックチェーンの匿名性と追跡可能性を、初学者向けに整理する記事です。

そのため、以下は深く扱いません。

• 実在する個人・組織・アドレスの追跡
• 個別事件の犯人特定
• ミキサーやプライバシー技術を使った追跡回避手順
• 資金洗浄や制裁回避につながる具体的な方法
• 取引所の内部調査手法や非公開情報
• 特定の暗号資産やサービスの投資判断
• すべてのプライバシーコインの詳細比較
• ゼロ知識証明の数理的な証明アルゴリズム
• 法律上の助言

ミキサー、CoinJoin、プライバシーコイン、ゼロ知識証明などは、透明性とプライバシーの関係を理解するうえで重要なテーマです。
ただし、本記事ではそれらを 追跡を逃れるための手順 としては扱いません。

あくまで、次のような観点で整理します。

扱う観点	扱わない観点
透明性が高いとなぜプライバシー課題が出るのか	追跡を回避するための具体的な操作手順
ミキサーがどのような目的で議論されるのか	特定サービスの使い方や回避テクニック
ゼロ知識証明がなぜプライバシー技術として注目されるのか	証明システムの詳細な数式や実装
AML/CFTとオンチェーン分析がなぜ関係するのか	法的判断や規制対応の助言

また、AML/CFT、Travel Rule、制裁対応などの規制に関わる情報は、国や時期によって変わります。
FATFのような国際的な基準設定機関も、暗号資産や暗号資産サービス提供者に関する基準の実装状況を継続的に更新しています。

参考: FATF: Virtual Assets

そのため、本記事では規制の全体像には触れますが、最新の法的判断や実務対応については、必ず公式情報や専門家の情報を確認する前提で読んでください。

コードを試す場合の前提

本記事では、後半の章で、取引履歴のつながりをイメージするためにPythonの小さなコード例を使う可能性があります。

ただし、コードはすべて 考え方を理解するための学習用 です。
実際のオンチェーン分析、本人特定、不正検知システム、捜査、コンプライアンス業務へそのまま使うことは想定していません。

項目	内容
目的	取引履歴のつながりやアドレス同士の関係を理解するための学習用
想定環境	Python 3.x系
主に使う標準ライブラリ	collections、dataclasses、json など
外部ライブラリ	原則なし。必要になった場合はその章で説明する
注意点	実際のオンチェーン分析、本人特定、不正検知システムへそのまま流用しない

たとえば、次のような概念コードを扱う可能性があります。

• 取引履歴を「点」と「線」として見る簡易モデル
• 複数アドレスにまたがる資金の流れをたどる簡易モデル
• アドレス同士の関係を見ても、同じ人物と断定できないことを示す例
• 追跡可能性と推定の限界を説明する小さな例

ここでいう「点」と「線」は、グラフ構造の考え方です。
たとえば、アドレスを点、アドレス間の送金を線として見ると、資金の流れを図として捉えやすくなります。

ただし、この図を見ても、アドレスA、B、C、Dが誰のものかまでは分かりません。
分かるのは、あくまで「公開された履歴上では、このような送金のつながりが見える」ということです。

この区別を忘れないようにしながら、必要な章で小さなコード例を使っていきます。

全体の流れ

この記事では、次の順番で話を進めます。

最初は、スマホ決済履歴や交通系ICカードの履歴のような身近な記録から入ります。
そこで、名前が直接見えないこと と 行動がまったく見えないこと は違う、という感覚を押さえます。

次に、ブロックチェーンではなぜ匿名に見えるのかを整理します。
ここでは、実名ではなくアドレスで取引すること、アドレスが本名と直接結びついているとは限らないことを見ます。

そのあと、なぜ取引履歴を追跡できるのかを確認します。
パブリックブロックチェーンでは、取引履歴が公開されている場合があり、ブロックエクスプローラーなどを使ってアドレス間の資金移動をたどれることがあります。

ただし、追跡できるからといって、何でも分かるわけではありません。
途中の章では、取引追跡で分かることと分からないことを分けて整理します。

さらに、取引所、SNS、Webサイト、寄付アドレス、事件資料、制裁リストなど、ブロックチェーン外の情報と結びつくポイントを見ます。
この部分は、アドレスが単なる文字列から「何らかの意味を持つ識別子」に変わる重要な場面です。

そのうえで、AML/CFTやオンチェーン分析との関係を整理します。
追跡可能性は、金融犯罪対策や取引所のコンプライアンスに役立つ一方で、分析には推定が含まれるため、断定しすぎないことが大切です。

後半では、ミキサー、プライバシーコイン、ゼロ知識証明など、プライバシーを高める技術や考え方にも触れます。
ただし、これらは追跡回避の手順としてではなく、透明性が高い環境でプライバシーをどう守るかという観点で扱います。

最後に、よくある誤解と最近の動向を整理し、記事全体をまとめます。
規制、法執行、プライバシー技術は変化が大きい領域なので、投稿時点の情報を確認しながら、強すぎる断定を避ける姿勢も大切です。

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

ブロックチェーンは、実名が直接出ないため匿名に見えることがあります。
しかし、取引履歴が公開される場合、その履歴から資金の流れやアドレス同士の関係を分析できることがあります。
そのため、「完全匿名」か「完全に追跡可能」かの二択ではなく、仮名性、透明性、追跡可能性、プライバシーを分けて考えることが大切です。

次の章では、まず身近な履歴に戻って、「名前が見えない履歴」と「行動が見える履歴」は違う という考え方を整理します。
ここを押さえておくと、ブロックチェーンのアドレスや取引履歴の話に入ったときも、匿名性と追跡可能性を混同しにくくなります。

---

1. 「名前が見えない履歴」と「行動が見える履歴」は違う

この章では、身近な履歴を例にしながら、「名前が直接見えないこと」と「行動が分からないこと」は違う、という感覚を整理します。
ポイントは、識別子が実名でなくても、履歴が積み重なると見えてくる情報があるという点です。

概要では、スマホ決済や交通系ICカード、SNS、フリマアプリのような身近な履歴から、ブロックチェーンの匿名性と追跡可能性を考え始めました。

ここからは、もう少し丁寧に 「名前が見えない履歴」と「行動が見える履歴」は違う という点を見ていきます。

たとえば、ある買い物履歴に本名が書かれていなかったとします。
その履歴には、代わりに user_001 のような会員IDだけが書かれているとします。

このとき、履歴を見た人は、すぐに「これは山田さんの履歴だ」と分かるわけではありません。
その意味では、本名は隠れています。

しかし、同じ user_001 の履歴が何十件、何百件と並んでいたらどうでしょうか。

• 平日の朝に同じ駅を使っている
• 昼休みに同じエリアで買い物している
• 夜に同じジャンルの店舗をよく利用している
• 毎月同じ日に似た金額の支払いがある

このような情報が積み重なると、本名が見えなくても、生活パターンや行動の傾向が少しずつ見えてきます。

ブロックチェーンでも、これに近いことが起こります。

BitcoinやEthereumのようなパブリックブロックチェーンでは、取引に本名が直接書かれるわけではありません。
多くの場合、外から見えるのはアドレスという文字列です。

しかし、Bitcoin.orgが説明しているように、Bitcoinの取引は公開され、追跡可能で、ネットワーク上に保存されます。

参考: Bitcoin.org: Protect your privacy

つまり、名前は見えにくいけれど、履歴は見えることがある わけです。

この章では、ブロックチェーンの前に、まず身近な履歴からこの感覚を整理します。

1.1 身近な履歴は、思ったより多くのことを語る

私たちの生活には、さまざまな履歴が残っています。

普段は、スマホアプリの画面で自分だけが見るものだと思っているかもしれません。
しかし、履歴というものは、単体では小さな情報でも、つなげて見るとかなり多くのことを表します。

身近な履歴	実名は直接見えるか	履歴から見える可能性があること
スマホ決済履歴	利用者本人や事業者側では分かる	よく使う店舗、生活圏、買い物の時間帯
銀行口座の入出金履歴	口座名義と結びつく	給与、家賃、サブスク、定期的な支払い
交通系ICカード履歴	カードIDや登録情報と結びつく場合がある	通学・通勤ルート、移動時間、よく行く場所
SNSの投稿履歴	本名でない場合もある	趣味、生活リズム、交友関係の一部
フリマアプリの取引履歴	ユーザー名中心の場合がある	売買傾向、発送地域の一部、取引相手
ブロックチェーン取引履歴	アドレス中心の場合が多い	資金の流れ、取引相手アドレス、利用サービスの手がかり

ここで大切なのは、履歴が一件だけならあまり多くを語らない場合でも、複数の履歴が並ぶと意味が出てくることです。

たとえば、コンビニでの1回の支払いだけを見ても、その人の生活はほとんど分かりません。
しかし、毎朝同じ駅近くで支払いがあり、昼は大学周辺、夜は自宅近くの店舗で支払いが多いとなると、生活圏が少し見えてきます。

これは、ブロックチェーンに限った特別な話ではありません。
履歴データは、積み重なることで意味を持つ という、かなり一般的な話です。

1.2 「本名がない」ことと「同じ人の履歴を結べない」ことは違う

ここで、もう少し踏み込んで考えてみます。

履歴に本名が書かれていなくても、同じ識別子が繰り返し登場すれば、「これは同じ人、または同じアカウントに関係する履歴かもしれない」と考えられます。

たとえば、SNSで本名を出さずに dance_student_28 というユーザー名で活動している人がいるとします。

このユーザー名だけを見ても、本名は分かりません。
しかし、投稿履歴を見ると、次のようなことが分かる場合があります。

• ダンスに関心がある
• 大学生活に関する投稿が多い
• 夜に投稿することが多い
• 特定のイベントに参加している
• 他のSNSでも似たユーザー名を使っている

このように、本名が見えなくても、同じ識別子に紐づく行動 は見えることがあります。

ブロックチェーンのアドレスも、まずはこの「識別子」に近いものとして考えると分かりやすいです。

もちろん、SNSのユーザー名とブロックチェーンアドレスは同じものではありません。
SNSではプロフィールや投稿本文がありますが、ブロックチェーンでは主に取引データが見えます。

それでも、初学者向けの入口としては、次のように捉えると理解しやすくなります。

身近な識別子	本名との関係	履歴との関係
SNSのユーザー名	本名とは限らない	投稿や返信が紐づく
会員ID	外から本名は見えない場合がある	購入履歴や利用履歴が紐づく
交通系ICカードID	カード登録情報と結びつく場合がある	乗降履歴が紐づく
ブロックチェーンアドレス	実名とは限らない	送金・受取などの取引履歴が紐づく

ここで言いたいのは、アドレスを見ただけで、すぐに現実の人物が分かるという話ではありません。

むしろ逆です。

アドレスだけでは、現実の人物は分からないことが多いです。
ただし、アドレスに紐づく履歴が公開されている場合、その履歴は観察できます。

この「本名は見えにくいが、履歴は見える」という性質が、ブロックチェーンの匿名性と追跡可能性をややこしくしています。

1.3 図で見る：名前が見えない履歴から、行動の傾向が見えるまで

身近な履歴とブロックチェーン取引履歴の関係を、かなり単純化して図にすると次のようになります。

この図では、最初に「履歴が1件だけある」状態から始めています。

履歴が1件だけなら、そこから分かることは限られます。
しかし、同じ識別子の履歴が増えると、時間帯、金額、相手、利用場所、利用サービスなどの傾向が見えてきます。

さらに、その識別子が外部情報と結びつくと、識別子の意味が強くなります。

たとえば、あるWebサイトが「寄付はこちらのBitcoinアドレスへ」と公開していたとします。
その場合、そのアドレスは単なる文字列ではなく、「そのWebサイトが使っている可能性のあるアドレス」として意味を持ち始めます。

同じように、SNSプロフィールにEthereumアドレスを載せている人がいれば、そのアドレスは、そのSNSアカウントと結びついて見られる可能性があります。

このように、追跡可能性を考えるときは、ブロックチェーンの中だけを見るのではなく、外部情報とどこで接点を持つか も重要になります。

1.4 小さなコードで見る：名前がなくても、履歴の傾向は集計できる

ここで、かなり単純化したコードで考えてみます。

次のコードは、実在する決済履歴やブロックチェーン取引ではありません。
あくまで、「本名ではなく識別子だけがある履歴でも、同じ識別子の行動を集計できる」という感覚をつかむための学習用モデルです。

実際の個人データや、許可のないログ分析に使うものではありません。

# これは「本名がない履歴でも、同じ識別子ごとに行動傾向を集計できる」ことを
# 理解するための学習用コードです。
# 実在する個人データや、許可のないログ分析に使うものではありません。

from collections import defaultdict

# 架空の利用履歴を用意します。
# user_id は本名ではなく、アプリやサービス上の識別子という想定です。
# blockchain_address も実在するアドレスではなく、説明用の短い文字列です。
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():
    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()

このコードが行っていることは、とても単純です。

1. 架空の履歴を用意する
2. user_id ごとに履歴をまとめる
3. 利用回数、合計金額、利用カテゴリを集計する

実行すると、たとえば user_001 について、朝・昼・夜にそれぞれどのような場所で支払いをしているかが見えてきます。

ここで重要なのは、コードの中に本名が一度も出てこないことです。

本名がなくても、同じ識別子に紐づく履歴が複数あれば、利用回数や金額、カテゴリの傾向を集計できます。
これは、ブロックチェーンのアドレスにも通じる考え方です。

もちろん、ブロックチェーンの実際の取引分析は、これほど単純ではありません。
実際には、取引の形式、トークンの種類、スマートコントラクト、取引所、ブリッジ、外部サービスなど、さまざまな要素が関係します。

ただし、最初の入口としては、次の感覚を持てれば十分です。

本名が見えなくても、同じ識別子に紐づく履歴が積み重なると、行動の傾向を集計できる場合があります。

1.5 もう一歩だけアルゴリズム風に考える

先ほどのコードを、もう少し一般化すると、履歴を見るときの基本的な流れは次のようになります。

1. 履歴データを集める
2. 同じ識別子に紐づく履歴をまとめる
3. 時間順に並べる
4. 金額、相手、カテゴリ、頻度などを集計する
5. 必要に応じて外部情報と照合する
6. ただし、照合結果を本人特定として断定しない

この流れは、スマホ決済履歴やSNS投稿履歴のような身近なデータでも、ブロックチェーンの取引履歴でも、かなり抽象化すれば似ています。

ただし、最後の6番目がとても重要です。

履歴から何かの傾向が見えたとしても、それはすぐに「この人だ」と断定できることを意味しません。
特にブロックチェーンでは、1つのアドレスを複数人・複数システムで管理している場合や、取引所のように多くの利用者の資金をまとめて扱うサービスもあります。

そのため、分析結果はあくまで 手がかり として扱う必要があります。

1.6 ブロックチェーンでは「見える範囲」と「見えない範囲」を分ける

ここで、身近な履歴とブロックチェーン取引履歴を比べてみます。

観点	身近な履歴の例	ブロックチェーン取引履歴の例
識別子	会員ID、ユーザー名、カードID	アドレス、トランザクションハッシュ
履歴の内容	購入、乗降、投稿、取引	送金、受取、スマートコントラクト呼び出し
見える範囲	サービス提供者や本人に限られることが多い	パブリックチェーンでは誰でも確認できる場合がある
本名との関係	サービス内部では結びつくことがある	外からは直接分からないことが多い
外部情報との接点	SNS、会員登録、配送先など	取引所、公開アドレス、寄付ページ、事件資料など

この表を見ると、ブロックチェーンの特徴が少し見えてきます。

一般的なスマホ決済履歴や銀行口座履歴は、通常、本人やサービス提供者など限られた関係者しか見られません。
一方で、BitcoinやEthereumのようなパブリックブロックチェーンでは、ブロックエクスプローラーなどを使って、アドレスや取引履歴を外部から確認できる場合があります。

Bitcoin.orgも、すべてのBitcoin取引は公開され、追跡可能で、ネットワーク上に永続的に保存されると説明しています。

参考: Bitcoin.org: Protect your privacy

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

参考: NIST CSRC Glossary: blockchain

このように、ブロックチェーンは「誰にも見えない秘密の記録」というより、改ざんされにくく、あとから確認しやすい記録 として設計されている面があります。

だからこそ、匿名性と追跡可能性をセットで考える必要があります。

1.7 ここで注意したいこと：推定と断定は違う

この章の最後に、特に大切な注意点を置いておきます。

履歴から行動の傾向が見えることと、本人を正確に特定できることは違います。

たとえば、あるアドレスが特定のサービスと何度も取引していることが分かったとしても、それだけで現実の誰かを断定することはできません。
そのアドレスが個人のものなのか、取引所のものなのか、スマートコントラクトのものなのか、複数人で管理されているものなのかは、別途確認が必要です。

また、外部情報と結びついたとしても、その情報が古い、誤っている、別の文脈で使われている可能性もあります。

そのため、本記事では今後も次の区別を大切にします。

区別したいこと	説明
観察	ブロックチェーン上で実際に見える取引履歴やアドレスの動き
推定	複数の履歴や外部情報から「こうかもしれない」と考えること
断定	十分な根拠にもとづいて「そうである」と結論づけること

オンチェーン分析では、観察と推定の境目を意識することが重要です。
特に、本人特定や犯罪関与の判断は、技術的な分析だけで軽く断定してよいものではありません。

💡 豆知識
SNSでは本名を出していないアカウントを「匿名」と呼ぶことがあります。
ただし、同じユーザー名で投稿を続けると、投稿履歴や人間関係が積み重なり、完全な匿名というより 仮名 に近い状態になる場合があります。
ブロックチェーンのアドレスもこれに似ており、本名ではなくても、同じアドレスに履歴が積み重なると、行動の手がかりを持つ識別子になります。

1.8 この章のまとめ

この章では、身近な履歴を例にしながら、「名前が見えないこと」と「行動が見えないこと」は違う、という点を整理しました。

スマホ決済履歴、交通系ICカードの履歴、SNSの投稿履歴、フリマアプリの取引履歴などは、本名が直接見えない場合でも、同じ識別子に紐づくことで行動の傾向が見えてくることがあります。

ブロックチェーンでも、多くの場合、取引に実名が直接表示されるわけではありません。
しかし、アドレスに紐づく取引履歴が公開されている場合、資金の流れや取引相手アドレスをたどれることがあります。

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

• 本名が見えないことと、履歴が見えないことは違う
• 識別子に履歴が積み重なると、行動の傾向が見える場合がある
• ブロックチェーンのアドレスも、履歴を持つ識別子として考えると分かりやすい
• ただし、履歴の分析結果を本人特定として断定してはいけない
• 観察、推定、断定を分けて考えることが大切

次の章では、ここで出てきた アドレス に注目します。
ブロックチェーンではなぜ実名ではなくアドレスが使われるのか、そしてそれがなぜ「匿名に見える」理由になるのかを整理していきます。

---

---

2. ブロックチェーンはなぜ匿名に見えるのか

この章では、ブロックチェーンが「匿名」と言われやすい理由を整理します。
ポイントは、多くの場合、取引履歴に実名ではなく アドレス が表示されることです。

前の章では、「名前が見えない履歴」と「行動が見える履歴」は違う、という点を整理しました。

スマホ決済履歴や交通系ICカードの履歴では、本名が直接見えなくても、同じ識別子に履歴が積み重なると行動の傾向が見える場合があります。
ブロックチェーンでも、これと似たことが起きます。

ブロックチェーンの取引では、多くの場合、利用者の本名や住所がそのまま表示されるわけではありません。
代わりに、0x... のような文字列や、Bitcoinアドレスのような文字列が表示されます。

この アドレス が、ブロックチェーンを「匿名に見える」ものにしている大きな理由です。

ただし、ここで最初に押さえておきたいのは、アドレスは「何も分からない空白」ではないという点です。
アドレスは本名ではありませんが、そのアドレスに関わる取引履歴と結びついていきます。

つまり、ブロックチェーンは次のような性質を持つことがあります。

見えにくいもの	見えやすいもの
利用者の本名	アドレス
住所や連絡先	アドレス間の取引
本人確認情報	取引の時刻、金額、送信元、送信先
その人の意図	公開された履歴から見える行動パターン

この章では、アドレス、ウォレット、公開鍵、秘密鍵といった言葉を、できるだけ身近な例から整理していきます。

2.1 まずは「宛名」と「本人名」を分けて考える

荷物を送る場面を考えてみます。

普通の配送では、宛名や住所が必要です。
誰に届けるのか、どこに届けるのかが分からなければ、荷物を届けられません。

一方で、ブロックチェーンの送金では、送金先としてアドレスを指定します。

ここでのアドレスは、かなりざっくり言えば ブロックチェーン上の宛先 です。
銀行口座番号やメールアドレス、SNSのユーザー名に少し近い入口から考えると分かりやすいです。

ただし、銀行口座番号やメールアドレスとまったく同じではありません。

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

このため、ブロックチェーンの画面やブロックエクスプローラーを見ても、いきなり「山田太郎さんが送金しました」と表示されるわけではありません。

代わりに、次のような形で見えます。

0xA1...9f3 から 0xB7...42c へ 1.2 ETH を送った

この時点では、0xA1...9f3 が誰なのかは分かりません。
だからこそ、ブロックチェーンは匿名に見えます。

しかし、0xA1...9f3 というアドレスに、過去の取引履歴が積み重なっている場合、そのアドレスがどのように使われてきたかは見えてくることがあります。

2.2 アドレスは「本名」ではなく「履歴を持つ識別子」

アドレスを理解するときは、いきなり暗号技術から入るよりも、まず 履歴を持つ識別子 と考えると分かりやすいです。

たとえば、SNSのユーザー名を考えてみます。

ユーザー名が dance_student_2028 だったとしても、それだけで本名は分かりません。
しかし、そのユーザー名で何年も投稿を続けていると、投稿内容、活動時間、交流関係、リンク先などが積み重なっていきます。

この場合、ユーザー名は本名ではありません。
それでも、履歴を持つ識別子になります。

ブロックチェーンのアドレスも、これに近い面があります。

観点	SNSユーザー名	ブロックチェーンアドレス
本名か	本名とは限らない	本名ではない
履歴が積み重なるか	投稿や返信が積み重なる	取引履歴が積み重なる
外部情報と結びつくか	プロフィールや他SNSで結びつく場合がある	取引所、SNS、Webサイトなどで結びつく場合がある
完全匿名と言えるか	長く使うほど難しくなる場合がある	履歴や外部情報により推定される場合がある

つまり、アドレスは「誰なのかが絶対に分からない魔法の文字列」ではありません。
本名ではないものの、取引履歴と結びつくことで意味を持ちはじめる識別子です。

Bitcoin.orgも、BitcoinアドレスはBitcoinがどこに割り当てられ、どこへ送られるかを定義する唯一の情報であり、一度使われたアドレスは関係するすべての取引履歴と結びつくと説明しています。

参考: Bitcoin.org: Protect your privacy

2.3 ウォレット、秘密鍵、公開鍵、アドレスの関係

ここで、少し専門用語を整理します。

ブロックチェーンを使っていると、ウォレット、秘密鍵、公開鍵、アドレス という言葉が出てきます。
最初は似たような言葉に見えますが、それぞれ役割が違います。

かなり単純化して言うと、次のようになります。

用語	ざっくりした意味	身近なイメージ
ウォレット	アカウントや鍵を扱い、取引を作るためのアプリや道具	銀行アプリや鍵束に近い
秘密鍵	取引に署名するための、自分だけが持つ重要な鍵	金庫を開ける鍵、印鑑、署名用のペン
公開鍵	秘密鍵に対応する公開側の鍵	署名を確認するための材料
アドレス	外から見える送金先・識別子	口座番号、メールアドレス、宛先ID

Ethereum公式ドキュメントでは、Ethereumの外部所有アカウント、つまりEOAは秘密鍵を持つ人によって制御され、公開鍵と秘密鍵の暗号学的なペアで構成されると説明されています。
また、秘密鍵は取引に署名するために使われ、秘密鍵を持つことがアカウントに関連する資産の管理につながると説明されています。

参考: Ethereum Documentation: Ethereum accounts

ここで大切なのは、ブロックチェーン上に「この秘密鍵を持っている人の本名は誰です」と書かれているわけではない、という点です。

外から見えるのは、多くの場合、アドレスや取引履歴です。
秘密鍵そのものは絶対に他人に見せてはいけない情報であり、ウォレットの内部で管理されます。

この図のように、現実の利用者とブロックチェーン上のアドレスの間には、ウォレットや鍵の仕組みがあります。

そのため、ブロックチェーン上の取引履歴を見ても、現実の利用者の名前がそのまま表示されるとは限りません。
これが、ブロックチェーンが匿名に見える大きな理由です。

2.4 なぜ「仮名性」と呼ぶ方が近いのか

ここで、この記事で何度も出てくる 仮名性 という言葉を整理します。

仮名性とは、本名ではなく、別の名前や識別子で活動する性質です。
たとえば、SNSのユーザー名、ゲーム内のプレイヤー名、掲示板のハンドルネームなどが分かりやすい例です。

状態	例	説明
実名	山田太郎	現実の本人情報に近い
仮名	crypto_cat_01	本名ではないが、同じ名前に履歴が積み重なる
匿名	一回限りの無記名投稿	継続的な識別子が残りにくい
ブロックチェーンアドレス	0x... やBitcoinアドレス	本名ではないが、取引履歴が積み重なる

NISTIR 8202では、Bitcoinは利用者をpseudonymousにできると説明しています。
これは、利用者は匿名的であっても、アカウント識別子は匿名ではなく、さらに取引は公開される、という意味で説明されています。

参考: NISTIR 8202: Blockchain Technology Overview

この説明は、ブロックチェーンの匿名性を理解するうえでとても重要です。

ブロックチェーンでは、実名が直接表示されにくいため、匿名に見えます。
しかし、アドレスという識別子があり、そのアドレスに履歴が積み重なるため、完全に何も追えないわけではありません。

そのため、この記事では次のように整理します。

多くのパブリックブロックチェーンは、完全匿名というより、仮名性に近い性質を持ちます。
つまり、本名ではなくアドレスで活動する一方、そのアドレスに履歴が積み重なります。

2.5 同じ人が複数のアドレスを使うこともある

ここで少し話が複雑になります。

アドレスは、必ずしも「1人につき1つ」と決まっているわけではありません。

同じ人が、用途ごとに複数のアドレスを使うことがあります。
たとえば、次のような使い分けです。

アドレスの使い分け例	目的
普段使いのアドレス	少額の送金やアプリ利用
NFT用のアドレス	NFTの購入・保管
研究・検証用のアドレス	テストネットや学習用
公開用の寄付アドレス	WebサイトやSNSに掲載
長期保管用のアドレス	頻繁には動かさない資産管理

これは、メールアドレスを用途ごとに分ける感覚に少し似ています。

学校用、就活用、買い物用、趣味用でメールアドレスを分ける人もいます。
それぞれのメールアドレスだけを見ると、同じ人が使っているとは限りません。

ブロックチェーンのアドレスも同じで、複数のアドレスが同じ人に属しているかどうかは、アドレス単体からは分かりません。

このように、1人が複数のアドレスを持つことがあるため、アドレスの数と利用者の数は一致しません。

2.6 逆に、1つのアドレスが複数人の資産をまとめて扱うこともある

一方で、逆のパターンもあります。

1つのアドレスが、必ずしも1人だけのものとは限りません。
取引所やカストディサービスのように、多くの利用者の資産をサービス側がまとめて管理する場合があります。

この場合、ブロックチェーン上では1つのアドレスに見えていても、内部的には多くの利用者の残高管理が行われている可能性があります。

見え方	実際にあり得ること
1つのアドレスに大量の資金がある	取引所やサービスの管理アドレスかもしれない
1つのアドレスから多くの送金がある	多数の利用者の出金をまとめて処理しているかもしれない
1つのアドレスへ多くの入金がある	サービスの入金用アドレスかもしれない

この点は、追跡可能性を考えるうえでとても大切です。

アドレスを見ただけで、「これは1人の個人の行動だ」と決めつけるのは危険です。
実際には、サービス、スマートコントラクト、マルチシグウォレット、組織の管理アドレスなど、さまざまな可能性があります。

このように、ブロックチェーン上のアドレスと現実の利用者は、きれいに一対一対応するとは限りません。

そのため、この記事では繰り返しになりますが、アドレス = 人 と単純に置かないようにします。

2.7 概念コード：アドレスは本名ではないが、識別子として見える

ここで、アドレスが「本名ではないけれど、外から見える識別子である」ことを、簡単なPythonコードで確認してみます。

以下のコードは、実際のBitcoinやEthereumのアドレス生成ではありません。
本物のアドレス生成では、楕円曲線暗号、公開鍵、ハッシュ関数、チェックサムなど、より正確な処理が関わります。

ここではあくまで、次のイメージをつかむための学習用モデルです。

1. 利用者は秘密の値を持つ
2. その秘密の値から、外から見えるアドレス風の文字列を作る
3. 公開される履歴には、実名ではなくアドレス風の文字列だけが出る

# これはブロックチェーンアドレスの考え方を説明するための簡易モデルです。
# 実際のBitcoinやEthereumのアドレス生成方法ではありません。

import hashlib
import secrets


def create_toy_wallet(label):
    """
    学習用のウォレット情報を作る関数です。

    labelは、説明のために付ける利用者名です。
    実際のブロックチェーンでは、このような実名ラベルが
    オンチェーンに自動で公開されるわけではありません。
    """

    # 秘密鍵の代わりになるランダムな値を作ります。
    # 本物の秘密鍵ではありませんが、「外に出してはいけない値」のイメージです。
    private_key_like = secrets.token_hex(32)

    # 秘密の値から、公開鍵のような値を作ります。
    # 実際には楕円曲線暗号が使われますが、ここではハッシュで単純化します。
    public_key_like = hashlib.sha256(private_key_like.encode("utf-8")).hexdigest()

    # 公開鍵のような値から、アドレス風の短い文字列を作ります。
    # Ethereum風に見えるよう、先頭に0xを付けています。
    address_like = "0x" + hashlib.sha256(public_key_like.encode("utf-8")).hexdigest()[-40:]

    return {
        "label": label,                         # 説明用の名前。実際には公開されない想定です。
        "private_key_like": private_key_like,   # 秘密にすべき値。
        "address_like": address_like,           # 外から見える識別子。
    }


# AliceとBobの学習用ウォレットを作ります。
alice_wallet = create_toy_wallet("Alice")
bob_wallet = create_toy_wallet("Bob")

# ブロックチェーン上に公開される取引履歴のイメージです。
# ここには実名ではなく、アドレス風の文字列だけを入れています。
public_transactions = [
    {
        "from": alice_wallet["address_like"],
        "to": bob_wallet["address_like"],
        "amount": 3.5,
    }
]

print("公開される取引履歴のイメージ:")
for tx in public_transactions:
    print(tx)

print("\n説明用の対応表:")
print("Aliceのアドレス:", alice_wallet["address_like"])
print("Bobのアドレス:", bob_wallet["address_like"])

このコードで注目したいのは、public_transactions の部分です。

公開される取引履歴には、Alice や Bob という名前ではなく、アドレス風の文字列だけが入っています。
そのため、外から見ると「どのアドレスからどのアドレスへ送られたか」は分かりますが、それだけで現実の人物名まで分かるわけではありません。

ただし、説明用の対応表を持っている人から見ると、どのアドレスがAliceで、どのアドレスがBobなのか分かります。
現実のブロックチェーン分析でも、外部情報と結びつくとアドレスの意味が変わることがあります。

この例で大切なのは、次の点です。

観点	コード内での例	実際のブロックチェーンでの考え方
秘密にするもの	private_key_like	秘密鍵
外から見えるもの	address_like	アドレス
公開履歴	public_transactions	オンチェーン取引履歴
外部対応表	説明用のAlice/Bobラベル	取引所情報、SNS公開アドレス、サービス内部情報など

もちろん、このコードは実際の暗号資産を扱うものではありません。
しかし、「本名ではなくアドレスが公開される」「外部情報があると意味が変わる」という感覚をつかむには十分です。

2.8 アドレスを新しく作れることも、匿名に見える理由になる

ブロックチェーンでは、アドレスを新しく作れる場合があります。

Ethereum公式ドキュメントでも、Ethereumのアカウント作成では、多くのライブラリがランダムな秘密鍵を生成すると説明されています。
また、外部所有アカウントの作成自体にはコストがかからないと説明されています。

参考: Ethereum Documentation: Ethereum accounts

これは、アドレスが「役所で1人1つだけ発行される番号」とは違うことを意味します。

たとえば、メールアドレスを複数作れるように、ブロックチェーンアドレスも用途ごとに作られることがあります。
そのため、あるアドレスだけを見ても、その人のすべての活動が見えるとは限りません。

Bitcoin.orgも、プライバシー保護の観点から、支払いを受け取るたびに新しいBitcoinアドレスを使うことや、用途ごとに複数のウォレットを使うことに触れています。

参考: Bitcoin.org: Protect your privacy

ただし、ここでも注意があります。

アドレスを分ければ、常に完全に切り離せるわけではありません。
後から同じ取引でまとめて使ったり、同じ取引所へ入金したり、SNSなどで複数のアドレスを公開したりすると、関係を推定される場合があります。

そのため、記事としては次のように整理するのが安全です。

アドレスを複数作れることは、ブロックチェーンが匿名に見える理由の一つです。
ただし、使い方や外部情報によって、複数のアドレスが同じ主体に関係すると推定される場合があります。

2.9 「アドレスだけ見える」から匿名に見える

ここまでを整理すると、ブロックチェーンが匿名に見える理由は、主に次のようにまとめられます。

理由	説明	注意点
実名が直接表示されにくい	取引には本名ではなくアドレスが出ることが多い	外部情報と結びつくと意味が変わる
アドレスを自分で作れる場合がある	本人確認なしにアドレスを用意できる場合がある	サービス利用時にはKYCが関係する場合がある
複数アドレスを使える	用途ごとにアドレスを分けられる	後から履歴が結びつく可能性がある
アドレスと人が一対一とは限らない	1人が複数アドレスを持つことも、サービスが1つのアドレスを使うこともある	アドレスをそのまま人物として断定できない

このように見ると、ブロックチェーンが匿名に見える理由はかなり自然です。

取引履歴に本名が直接出ない。
アドレスは自分で作れる場合がある。
複数のアドレスを使える。
アドレスと現実の人物が一対一で対応しない。

これらの性質があるため、ブロックチェーンは一見すると「誰が使っているか分からない」ように見えます。

しかし、繰り返しになりますが、これは「何も追えない」という意味ではありません。
アドレスには履歴が積み重なります。
そして、その履歴は多くのパブリックブロックチェーンで外から確認できます。

この点が、次章で扱う 追跡可能性 につながります。

💡 豆知識
ウォレットという言葉から、暗号資産そのものがアプリの中に入っているように感じるかもしれません。
しかし実際には、ブロックチェーン上の台帳に「このアドレスにこれだけの残高がある」と記録され、ウォレットはそのアドレスを扱うための入口に近い存在です。
そのため、匿名性や追跡可能性を考えるときも、現金の財布より 鍵とアドレスを管理する道具 と捉える方が理解しやすくなります。

2.10 この章のまとめ

この章では、ブロックチェーンがなぜ匿名に見えるのかを整理しました。

多くのパブリックブロックチェーンでは、取引履歴に利用者の本名が直接表示されるわけではありません。
代わりに、アドレスという文字列が使われます。

アドレスは、送金先や取引主体として外から見える識別子です。
そのため、アドレスだけを見ても、すぐに現実の人物名が分かるとは限りません。

一方で、アドレスは完全に意味のない文字列ではありません。
そのアドレスに取引履歴が積み重なると、資金の動きや利用パターンが見えてくる場合があります。

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

• ブロックチェーンでは、実名ではなくアドレスが見えることが多い
• アドレスは本名ではないが、履歴を持つ識別子になる
• 秘密鍵は取引に署名するための重要な情報であり、外に出してはいけない
• ウォレットは、鍵やアカウントを扱うためのアプリやインターフェースに近い
• 1人が複数のアドレスを使うことも、1つのアドレスが複数人に関係することもある
• そのため、アドレスをそのまま人として断定してはいけない
• 多くのパブリックブロックチェーンは、完全匿名というより仮名性に近い

次の章では、ではなぜそのアドレスの履歴を追跡できるのかを整理します。
ポイントは、ブロックチェーンが「実名を隠す場合がある」一方で、「取引履歴を公開している場合がある」という点です。

匿名に見える理由を確認したうえで、次は なぜ取引履歴を追跡できるのか を、公開台帳とブロックエクスプローラーのイメージから見ていきます。

---

3. なぜ取引履歴を追跡できるのか

この章では、ブロックチェーンの取引履歴を追跡できる理由を整理します。
ポイントは、多くのパブリックブロックチェーンでは、取引が「公開された履歴」として残り、アドレス同士のつながりを後から確認できることです。

前の章では、ブロックチェーンがなぜ匿名に見えるのかを整理しました。
取引履歴に本名が直接表示されるわけではなく、アドレスという文字列が使われるため、ぱっと見ただけでは誰の取引なのか分かりにくいという話でした。

ただし、そこで終わらないのがブロックチェーンの少し不思議なところです。

実名が見えにくい一方で、多くのパブリックブロックチェーンでは、取引履歴そのものは外から確認できます。
つまり、誰なのかはすぐ分からないが、どのアドレスからどのアドレスへ動いたのかは見える場合がある ということです。

これは、SNSのユーザー名に少し似ています。

本名を出していないアカウントでも、投稿履歴、返信、フォロー関係、活動時間が積み重なると、そのアカウントの行動パターンは見えてきます。
ブロックチェーンでも、アドレスの取引履歴が積み重なることで、資金の流れや利用傾向を追える場合があります。

この章では、ブロックチェーンの取引履歴がなぜ追跡できるのかを、公開台帳、トランザクションID、ブロックエクスプローラー、グラフ構造のイメージから整理します。

3.1 まずは家計簿の履歴で考えてみる

家計簿アプリを想像してみます。

家計簿には、次のような記録が並びます。

日時	支払先	金額	メモ
2026-07-01 08:10	駅のコンビニ	320円	朝食
2026-07-01 12:30	学食	550円	昼食
2026-07-01 19:20	スーパー	1,480円	食材
2026-07-02 08:12	駅のコンビニ	300円	朝食

この表に本名が書かれていなくても、記録が積み重なると生活のリズムが見えてきます。

• 朝は駅の近くで買い物をしている
• 昼は学食を使っている
• 夜はスーパーで食材を買っている
• 同じ時間帯に似た行動が繰り返されている

この時点で分かるのは、あくまで履歴上のパターンです。
本名や住所まで自動的に分かるわけではありません。

ブロックチェーンの取引履歴も、まずはこれに近いです。

アドレスの持ち主が誰なのかは、履歴だけでは分からない場合があります。
しかし、取引の時間、送信元、送信先、金額、トークンの種類などを並べると、アドレス同士の関係や資金の流れが見えてくることがあります。

3.2 パブリックブロックチェーンでは取引履歴が公開されることがある

ブロックチェーンにはさまざまな種類があります。
その中でもBitcoinやEthereumのようなパブリックブロックチェーンでは、取引履歴を外部から確認できることが大きな特徴です。

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

参考: Bitcoin.org: Protect your privacy

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

参考: Ethereum Documentation: Transactions

ここで大切なのは、ブロックチェーンの取引は、単なる「送金完了のお知らせ」ではないという点です。

取引は、誰かがネットワークに送った状態更新の記録です。
そして、その記録がブロックに含まれることで、あとから確認できる履歴になります。

見える情報	例	そこから分かること	注意点
トランザクションID	0x... や txid	特定の取引を探す入口になる	取引の意味までは自動で分からない
送信元アドレス	from	どのアドレスから送られたか	人物名とは限らない
送信先アドレス	to	どのアドレスへ送られたか	個人、サービス、コントラクトなどの場合がある
金額・数量	1 ETH、0.01 BTCなど	どれくらい移動したか	トークンの種類や小数点に注意が必要
時刻	ブロックに含まれた時刻	いつごろ記録されたか	現実世界の操作時刻と完全一致するとは限らない
手数料	gas fee、transaction fee	処理に支払われたコスト	混雑状況で変わる

このような情報が公開されるため、取引履歴をたどる入口が生まれます。

3.3 ブロックエクスプローラーは「公開台帳を見るための窓」

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

ブロックエクスプローラーは、ブロックチェーン上のブロック、取引、アドレス、トークン、スマートコントラクトなどを検索・確認するためのWebサービスです。
Ethereum公式ドキュメントでも、ブロックエクスプローラーはEthereumのデータを見るための入口であり、ブロック、トランザクション、バリデータ、アカウント、オンチェーン活動を確認できると説明されています。

参考: Ethereum Documentation: Block explorers

身近な例でいうと、ブロックエクスプローラーは「公開された台帳を読みやすく表示してくれる検索画面」に近いです。

ブロックチェーンそのものは、データ構造やノード、APIなどを通して扱われます。
しかし、初学者がいきなりノードを立てたり、RPC APIを叩いたりするのは少し大変です。

そこで、ブロックエクスプローラーを使うと、次のような情報をブラウザ上で確認できます。

検索できるもの	何を確認できるか	例
アドレス	残高、取引履歴、トークン保有状況	あるアドレスの過去の入出金
トランザクションID	取引の状態、送信元、送信先、金額、手数料	ある送金が成功したか
ブロック番号	ブロック内の取引一覧、時刻、提案者など	ある時点の取引のまとまり
トークンコントラクト	トークンの発行量、保有者、転送履歴	ERC-20やNFTの移動
スマートコントラクト	コード、呼び出し履歴、イベント	DeFiやNFTアプリの利用履歴

Ethereum公式ドキュメントでは、Ethereumは設計上透明であり、すべてが検証可能であるため、ブロックエクスプローラーがその情報へアクセスするためのインターフェースを提供すると説明されています。

参考: Ethereum Documentation: Block explorers

ただし、ブロックエクスプローラーで見える情報は、基本的にブロックチェーン上の情報です。
そこに表示されるアドレスが、現実世界の誰に対応するのかは、別の情報がなければ分からないことがあります。

この点を混同しないことが大切です。

3.4 取引は「点」ではなく「線」として見える

取引履歴を追跡できる理由を理解するには、取引を1件ずつの点として見るだけでなく、アドレス同士をつなぐ線として見ると分かりやすくなります。

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

取引ID	送信元	送信先	金額
tx001	アドレスA	アドレスB	5.0
tx002	アドレスB	アドレスC	2.0
tx003	アドレスB	アドレスD	1.5
tx004	アドレスC	アドレスE	1.0

この表を眺めるだけでも、アドレスAからアドレスBへ資金が移動し、その後BからCやDへ分かれ、さらにCからEへ流れていることが分かります。

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

このように、アドレスを点、取引を線として見ると、ブロックチェーンの履歴はグラフのように表現できます。

ここでいう グラフ は、棒グラフや円グラフではありません。
点と線で関係を表すデータ構造のことです。

グラフの要素	ブロックチェーンでのイメージ	身近な例
ノード	アドレス、サービス、コントラクト	SNSのアカウント
エッジ	取引、送金、トークン移転	フォロー、返信、送金
向き	どちらからどちらへ移動したか	AさんからBさんへ送る
重み	金額、回数、頻度	送金額、やり取りの多さ
時間	いつ起きたか	いつ投稿・送金したか

オンチェーン分析では、このようなグラフ構造をもとに、資金の流れやアドレス同士の関係を見ていくことがあります。

ただし、グラフでつながっているからといって、そのアドレスの持ち主が同じだと決まるわけではありません。
分かるのは、まず 取引としてつながっている という事実です。

3.5 BitcoinではUTXOをたどる見方がある

Bitcoinでは、Ethereumのようにアカウント残高を直接更新するというより、UTXO という考え方で取引を扱います。

UTXOは、Unspent Transaction Outputの略で、日本語では「未使用トランザクション出力」と説明されることがあります。
名前は少し難しいですが、最初は まだ使われていない受け取り分 くらいに考えると分かりやすいです。

たとえば、1,000円札で300円の買い物をすると、700円のお釣りが返ってきます。
BitcoinのUTXOも、かなり単純化すると、「前の取引で受け取った出力を、次の取引の入力として使う」という考え方に近いです。

Bitcoin Developer Guideでは、AliceがBobのアドレスへ送った取引がブロックチェーンに追加されると、ネットワークはそれをUTXOとして分類し、Bobのウォレットはそれを使える残高として表示すると説明しています。
また、BobがそのUTXOを使うときには、前の取引のtxidと出力番号を参照する入力を作ると説明されています。

参考: Bitcoin Developer Guide: Transactions

ざっくり図にすると、次のようなイメージです。

この構造では、ある出力がどの取引で作られ、どの取引で使われたのかをたどれます。
そのため、BitcoinではUTXOのつながりを見ることで、資金の流れを追いやすい場面があります。

ただし、ここでも注意があります。

UTXOのつながりから分かるのは、あくまで取引上の参照関係です。
それが誰の操作なのか、なぜ送金したのか、犯罪に関係しているのか、といったことは、ブロックチェーン上の構造だけで断定できるとは限りません。

3.6 Ethereumではアカウントと状態更新を見る

Ethereumでは、BitcoinのUTXOモデルとは違い、アカウントと状態更新の考え方が中心になります。

Ethereum公式ドキュメントでは、トランザクションはアカウントから送られる暗号学的に署名された指示であり、Ethereumネットワークの状態を更新すると説明されています。
また、もっとも単純な取引は、あるアカウントから別のアカウントへETHを移すことだと説明されています。

参考: Ethereum Documentation: Transactions

Ethereumの取引には、たとえば次のような情報が含まれます。

情報	ざっくりした意味
from	取引を送ったアドレス
to	送信先アドレス、または呼び出したスマートコントラクト
value	送ったETHの量
input data	スマートコントラクト呼び出しに使われる追加情報
nonce	そのアドレスから送られた取引番号のようなもの
gas 関連	取引処理に支払う手数料に関係する情報

Ethereumでは、単純なETH送金だけでなく、スマートコントラクトとのやり取りも多く行われます。
そのため、追跡では単に from と to を見るだけでなく、トークン移転イベント、コントラクト呼び出し、内部的な送金、NFTの移転なども関係することがあります。

ここは少し難しく見えるかもしれません。
最初の段階では、次のように押さえれば十分です。

Bitcoinでは、前の出力を次の入力として使うUTXOのつながりを見る。
Ethereumでは、アカウントから送られたトランザクションと、それによる状態更新を見る。

どちらも細かい仕組みは違いますが、公開された履歴をたどれるという点では共通しています。

3.7 簡単なPythonコードで「資金の流れ」をたどってみる

ここでは、取引履歴をグラフとして見る考え方を、架空データで確認してみます。

実在のアドレスや実際の取引データは使いません。
目的は、アドレスをノード、取引をエッジとして扱うと、何ステップ先まで資金が移動したかを追える という感覚をつかむことです。

from collections import defaultdict, deque

# 学習用の架空取引データです。
# 実在するブロックチェーンの取引やアドレスではありません。
transactions = [
    {"tx_id": "tx001", "from": "Address_A", "to": "Address_B", "amount": 5.0},
    {"tx_id": "tx002", "from": "Address_B", "to": "Address_C", "amount": 2.0},
    {"tx_id": "tx003", "from": "Address_B", "to": "Address_D", "amount": 1.5},
    {"tx_id": "tx004", "from": "Address_C", "to": "Address_E", "amount": 1.0},
    {"tx_id": "tx005", "from": "Address_D", "to": "Address_F", "amount": 0.8},
]


# 送信元アドレスごとに、どの取引が出ていったかをまとめます。
# これは「アドレスをノード、取引をエッジ」として見るための準備です。
graph = defaultdict(list)

for tx in transactions:
    graph[tx["from"]].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 graph.get(current_address, []):
            next_address = tx["to"]

            # これまでの経路に、今回の取引を追加します。
            new_path = path + [tx]
            traced_paths.append(new_path)

            # 次のアドレスからさらに先へ資金が動いていないか確認するため、queueに追加します。
            queue.append((next_address, depth + 1, new_path))

    return traced_paths


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

# 追跡結果を読みやすく表示します。
for i, path in enumerate(paths, start=1):
    print(f"経路 {i}:")
    for tx in path:
        print(f"  {tx['tx_id']}: {tx['from']} -> {tx['to']} ({tx['amount']})")

このコードでは、Address_A から出た資金が、Address_B を経由して Address_C や Address_D へ動いていることをたどれます。

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

経路 1:
  tx001: Address_A -> Address_B (5.0)
経路 2:
  tx001: Address_A -> Address_B (5.0)
  tx002: Address_B -> Address_C (2.0)
経路 3:
  tx001: Address_A -> Address_B (5.0)
  tx003: Address_B -> Address_D (1.5)

ここで見てほしいのは、難しいAIや暗号解析を使わなくても、公開された取引履歴をグラフとして整理すると、資金の流れをある程度たどれるという点です。

もちろん、実際のブロックチェーン分析はこれよりずっと複雑です。

たとえば、次のような要素が関係します。

• 取引手数料で金額が少し減る
• 複数のトークンが同じアドレスで動く
• スマートコントラクトを経由する
• 取引所やブリッジのように、多数の利用者の資金をまとめるサービスがある
• 同じ主体が複数アドレスを使う場合がある
• 逆に、1つのアドレスが多くの利用者に関係する場合もある

そのため、コードのように単純に「AからB、BからC」と追えばすべて分かるわけではありません。
それでも、公開履歴をグラフとして見る考え方は、追跡可能性を理解するための重要な入口になります。

3.8 追跡できる理由を整理する

ここまでの内容をまとめると、取引履歴を追跡できる理由は次のように整理できます。

理由	説明	注意点
取引履歴が公開される	多くのパブリックブロックチェーンでは、取引を外部から確認できる	すべてのチェーンやサービスで同じとは限らない
アドレスが履歴を持つ	同じアドレスに入出金履歴が積み重なる	アドレスと人を一対一で見ない
トランザクションIDがある	特定の取引を一意に探しやすい	取引の背景や意図までは分からない
ブロックに時系列で記録される	いつごろ、どの順序で記録されたかを確認しやすい	ブロック時刻と現実の操作時刻にはズレがあり得る
アドレス間の関係をグラフ化できる	資金の流れを点と線で表現できる	グラフ上の近さが本人関係を意味するとは限らない
ブロックエクスプローラーがある	ブラウザ上で履歴を確認しやすい	表示内容やラベルはサービスによって異なる

このように、追跡可能性は「裏口から秘密情報を盗み見る」というより、公開されている台帳を読み解くことから始まります。

もちろん、取引所の内部情報や本人確認情報のような外部データは、一般の利用者が自由に見られるものではありません。
しかし、オンチェーン上に公開された履歴だけでも、アドレス間の資金移動や取引パターンはある程度確認できます。

3.9 ただし「追跡できる」と「本人特定できる」は違う

ここで、もう一度注意したいことがあります。

ブロックチェーンの取引履歴を追えるからといって、すぐに本人が分かるわけではありません。

たとえば、次の2つはまったく別の話です。

できること	まだ分からないこと
アドレスAからアドレスBへ送金されたことを見る	アドレスAやBの持ち主が誰か
アドレスBから複数のアドレスへ資金が分かれたことを見る	それが支払い、送金、分配、内部移動のどれか
あるアドレスが取引所らしきアドレスとやり取りしていることを見る	その取引所アカウントの登録者が誰か
同じ時間帯に似た動きをするアドレス群を見る	それらが同じ人物に管理されているか

この違いを分けておかないと、取引履歴の分析結果を過大評価してしまいます。

オンチェーン分析では、公開履歴、既知アドレス、外部情報、統計的な特徴などを組み合わせることがあります。
しかし、そこには推定が含まれます。

そのため、この記事では次の3段階を意識します。

段階	例	扱い方
観察	アドレスAからBへ送金された	ブロックチェーン上で確認できる事実
推定	Bは取引所の入金アドレスかもしれない	根拠を示し、断定を避ける
特定	このアドレスは特定の人物が使っている	強い外部根拠が必要

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

追跡可能性を理解するうえで大切なのは、見えている情報を丁寧に読むことです。
そして、見えていない情報まで勝手に補って断定しないことです。

💡 豆知識
ブロックエクスプローラーは、ブロックチェーンそのものではなく、オンチェーンデータを検索・表示しやすくする入口です。
Webサイトと検索エンジンの関係に少し似ており、表示結果は便利ですが、サービスごとにラベルや見せ方、対応範囲が異なることがあります。
重要な確認では、単一の表示だけで断定せず、必要に応じて複数のデータソースや公式情報も確認することが大切です。

3.10 この章のまとめ

この章では、なぜブロックチェーンの取引履歴を追跡できるのかを整理しました。

ブロックチェーンでは、取引に実名ではなくアドレスが使われることがあります。
そのため、誰の取引なのかはすぐには分かりにくく、匿名に見える場合があります。

一方で、多くのパブリックブロックチェーンでは、取引履歴が公開されます。
アドレス、トランザクションID、送信元、送信先、金額、時刻、手数料などを確認できるため、資金の流れをたどれる場合があります。

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

• 追跡可能性は、公開された取引履歴から生まれる
• ブロックエクスプローラーは、公開台帳を見るための入口になる
• 取引は、アドレス同士をつなぐ線として見られる
• アドレスと取引をグラフとして整理すると、資金の流れを追いやすくなる
• BitcoinではUTXOのつながり、Ethereumではアカウントと状態更新を見ると理解しやすい
• ただし、追跡できることと本人特定できることは違う
• 分析では、観察、推定、特定を分けて考える必要がある

次の章では、ここから一歩進んで、追跡で分かること・分からないこと を整理します。

取引履歴を追えると、資金の移動やアドレス間の関係は見えてきます。
しかし、その取引の目的、利用者の意図、現実世界の人物名まで分かるとは限りません。

次章では、ブロックチェーン分析の便利さと限界を分けて見ていきます。

---

4. 追跡で分かること・分からないこと

この章では、ブロックチェーン分析で分かることと、分からないことを分けて整理します。
ポイントは、取引履歴を追えることと、本人や意図を断定できることは同じではないという点です。

前の章では、パブリックブロックチェーンでは取引履歴が公開され、アドレスやトランザクションIDを手がかりに資金の流れをたどれる場合があることを見ました。

ここまで読むと、次のように感じるかもしれません。

取引履歴を追えるなら、誰が何をしたかまで分かるのでは？

しかし、ここは少し丁寧に分けて考える必要があります。

ブロックチェーン上で見えるのは、基本的には アドレス間の取引履歴 です。
一方で、そのアドレスを現実世界の誰が操作したのか、どのような目的で取引したのか、法律上どのように評価されるのかは、オンチェーン情報だけでは分からない場合があります。

身近な例でいうと、レシートの束を見れば「いつ、どの店で、いくら使ったか」は分かるかもしれません。
でも、それだけで「誰が買ったのか」「なぜ買ったのか」「誰かに頼まれて買ったのか」まで必ず分かるわけではありません。

ブロックチェーン分析も、これに近いところがあります。

4.1 レシートを見ると分かること、分からないこと

まずは、レシートを例に考えてみます。

財布の中に、次のようなレシートが入っていたとします。

時刻	店舗	金額	分かること
08:10	コンビニ	320円	朝に何かを買った可能性がある
12:35	カフェ	780円	昼ごろにカフェを利用した可能性がある
18:20	駅ビル	2,400円	夕方に買い物をした可能性がある

このレシートから、行動の一部は見えます。

朝にコンビニへ行ったこと、昼にカフェを使ったこと、夕方に駅ビルで買い物をしたことは推測できます。
しかし、次のことまではすぐには分かりません。

• 本当に本人が買ったのか
• 誰かに頼まれて買ったのか
• 何を目的に買ったのか
• その支払いが良いことなのか悪いことなのか
• レシートを持っている人と購入者が同じなのか

つまり、履歴から見える情報には限界があります。

ブロックチェーンでも同じです。
取引履歴を追えることはありますが、それは 見える情報 と 推定できる情報 と まだ分からない情報 が混ざっている状態です。

4.2 ブロックチェーン上で見える可能性があること

Bitcoin.orgは、Bitcoinについて、すべての取引がネットワーク上で公開かつ永続的に保存され、誰でも任意のBitcoinアドレスの残高や取引を見られると説明しています。
ただし、そのアドレスの背後にいる利用者の身元は、購入時などに情報が明らかになるまでは分からないとも説明しています。

参考: Bitcoin.org: Some things you need to know - Bitcoin is not anonymous

Ethereum公式ドキュメントでも、ブロックエクスプローラーはEthereumのデータへの入口であり、ブロック、取引、アカウント、オンチェーン活動を確認できると説明されています。
また、トランザクションデータには、トランザクションハッシュ、状態、ブロック、タイムスタンプ、送信元、送信先などが含まれると説明されています。

参考: Ethereum.org: Block explorers

これらを踏まえると、ブロックチェーン上で見える可能性がある情報は、たとえば次のように整理できます。

見える可能性がある情報	ざっくりした意味	注意点
アドレス	取引の送信元・送信先として使われる識別子	そのまま人名ではない
トランザクションID	取引を識別するためのID	取引の入口にはなるが、目的までは示さない
金額・トークン	どの資産がどれくらい動いたか	価格換算やトークンの意味づけは別途必要
時刻	取引がブロックに含まれた時刻	現実世界の行動時刻と完全一致するとは限らない
送信元・送信先	資金やトークンの移動方向	アドレスの所有者までは直接示さない
スマートコントラクトとのやり取り	DeFi、NFT、トークン移動などの操作	コントラクトの意味を理解する必要がある
既知サービスとの接点	取引所、ブリッジ、コントラクトなどとの入出金	ラベルの正確性や更新状況に注意が必要

ここで大切なのは、ブロックチェーン上の情報はかなり細かく見える一方で、それだけで現実世界の情報がすべて分かるわけではない ということです。

4.3 「分かること」と「分からないこと」を分ける

追跡可能性を理解するときは、次の表を頭に置いておくと整理しやすいです。

分かる可能性があること	断定しにくいこと
アドレスAからアドレスBへ資金が移動したこと	アドレスAを操作した現実世界の人物
ある時刻に取引が記録されたこと	その取引を行った理由や意図
複数の取引が一定の順序で発生したこと	取引の背景にある契約や会話
資金が分散・集約された流れ	分散先が必ず同一人物に属すること
既知の取引所やサービスと接点があること	そのサービス内で誰が何をしたか
高リスクとされるアドレスと接点があること	犯罪関与の有無そのもの

たとえば、あるアドレスが取引所とやり取りしていることは、オンチェーン上で見える場合があります。
しかし、その取引所アカウントを誰が使っていたかは、通常オンチェーン情報だけでは分かりません。

また、あるアドレスが不正利用が疑われるアドレスから資金を受け取っていたとしても、それだけで「そのアドレスの利用者が犯罪者である」と断定するのは危険です。

誤送金、第三者による送付、サービスを介した入出金、スマートコントラクトの自動処理、攻撃者による資金分散など、さまざまな可能性があるからです。

4.4 観察・推定・断定を分ける

ブロックチェーン分析では、観察できること、推定できること、断定するには追加根拠が必要なこと を分けることがとても大切です。

この図で見てほしいのは、いきなり「取引がある = 本人が悪い」とはならない点です。

オンチェーン上で観察できるのは、まず取引の事実です。
そこから、アドレス間の関係や資金の流れを分析して、一定の推定を行います。
さらに、取引所の本人確認情報、公的機関の発表、SNSやWebサイトで公開されたアドレスなど、外部情報と結びつくと、現実世界の主体に近づける場合があります。

ただし、最終的な判断には、オンチェーン分析だけでなく、法的手続き、証拠保全、関係者への確認、オフチェーンの記録などが関係します。

そのため、記事内では次のような表現を使うのが安全です。

この取引履歴から、アドレスAからアドレスBへ資金が移動したことは確認できます。
一方で、アドレスBを誰が管理しているか、どのような目的で受け取ったかは、外部情報なしに断定することはできません。

逆に、次のような表現は避けた方がよいです。

このアドレスに資金が流れているので、この人物が犯人です。

ブロックチェーン分析は強力な手がかりになります。
しかし、手がかりと断定は別です。

4.5 アドレスクラスタリングも「推定」である

取引追跡では、複数のアドレスが同じ主体に関係している可能性を推定することがあります。
このような考え方は、アドレスクラスタリングと呼ばれることがあります。

たとえば、BitcoinのUTXOモデルでは、1つの取引に複数の入力が使われる場合があります。
このとき、複数の入力アドレスを操作できる人が同じである可能性がある、という推定が使われることがあります。

ただし、これはあくまでヒューリスティック、つまり経験的な見方です。
必ず正しいルールではありません。

Bitcoinの匿名性に関する初期の研究である Reid and Harrigan の論文でも、Bitcoinでは利用者が公開鍵によって識別され、外部情報と結びつけることで利用者との対応を調べる可能性があることが議論されています。
同時に、利用者は必要に応じて複数の公開鍵を生成できるため、対応関係の分析は単純ではありません。

参考: Reid and Harrigan: An Analysis of Anonymity in the Bitcoin System

ここで重要なのは、クラスタリングの結果を「確定情報」として扱わないことです。

分析の例	分かる可能性	注意点
複数入力が同じ取引に使われている	同じ主体が管理している可能性	CoinJoinやサービス処理などの例外がある
あるアドレスに少額のお釣りらしき出力がある	送信者側の変更アドレスの可能性	ウォレット実装や取引形式によって異なる
取引所らしきアドレスに入金している	取引所を利用した可能性	取引所内のユーザーまではオンチェーンだけでは見えない
同じ時刻帯に似た金額が連続して動く	自動処理や分散処理の可能性	偶然や複数主体の処理の可能性もある

このように、アドレスクラスタリングは便利ですが、分析者の仮定を含みます。

そのため、本文では次のように表現するのが自然です。

複数のアドレスが同じ主体に関係している可能性を推定できる場合があります。
ただし、ウォレットの仕様、サービスの内部処理、共同利用、プライバシー技術などによって例外もあるため、クラスタリング結果は慎重に扱う必要があります。

4.6 外部情報があると見え方が変わる

オンチェーン情報だけでは、アドレスの持ち主は分かりにくいことがあります。
しかし、外部情報と結びつくと、見え方が大きく変わることがあります。

たとえば、次のようなケースです。

• 企業やプロジェクトが公式サイトで寄付アドレスを公開している
• SNSのプロフィールに暗号資産アドレスが掲載されている
• NFTやENSのように、アドレスと名前が結びつく仕組みを使っている
• 取引所が本人確認を行っている
• 公的機関やセキュリティ企業が、特定のアドレスを公表している

研究例として、SNS上で公開された暗号資産アドレスが、個人情報を含むアカウントと結びつく可能性を調べた研究もあります。
この研究は、公開台帳そのものだけでなく、SNSのような外部情報がプライバシー漏えいのきっかけになり得ることを示しています。

参考: Social Networks are Divulging Your Identity behind Crypto Addresses

このように、追跡可能性はブロックチェーン上の情報だけで完結するとは限りません。

むしろ、オンチェーン情報と外部情報が結びついたときに、アドレスの意味が急に具体的になることがあります。

この話は、次章の「外部情報と結びつくポイント」でさらに詳しく扱います。

4.7 AML/CFTでは「手がかり」と「確認」を分けて扱う

追跡可能性は、AML/CFT、つまりマネー・ローンダリング対策やテロ資金供与対策とも関係します。

FATFは、暗号資産や暗号資産サービス提供者に対するAML/CFT基準の実装状況を継続的に確認しています。
2025年の更新では、暗号資産やVASPに関する規制、Travel Rule、オフショアVASP、詐欺や不正利用などが引き続き課題として整理されています。

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

ここで大事なのは、オンチェーン分析が「怪しい可能性のある流れ」を見つける手がかりになり得る一方で、それだけで最終判断が完結するわけではないという点です。

たとえば、あるアドレスが高リスクアドレスと接点を持っている場合、追加調査のきっかけにはなります。
しかし、その接点がどういう意味を持つのかは、取引の文脈、サービスの内部記録、本人確認情報、法的手続きなどとあわせて確認する必要があります。

段階	内容	例
検知	気になる取引やアドレスを見つける	高リスクアドレスとの接点を検出する
分析	資金の流れや関連アドレスを整理する	入出金経路、分散、集約を確認する
照合	外部情報と合わせて確認する	取引所情報、公表情報、被害届などと照合する
判断	ルールや法的手続きに基づいて対応する	追加確認、凍結、報告、捜査協力など

この記事では、法的判断や捜査手続きそのものには踏み込みません。
ただ、技術的な追跡可能性は、こうした実務の入口で使われることがある、という位置づけは押さえておくとよいです。

4.8 Pythonで「分かること」と「推定」を分けてみる

ここでは、架空の取引履歴を使って、分析結果を 観察できること と 推定にとどまること に分ける小さなコードを書いてみます。

このコードは、実際のブロックチェーン分析ツールではありません。
目的は、公開取引履歴から分かることと、外部ラベルがあって初めて言えることを区別する感覚をつかむことです。

# これはブロックチェーン分析の考え方を説明するための学習用コードです。
# 実際の捜査、本人特定、リスク判定にそのまま使うものではありません。

from collections import defaultdict

# 架空の取引履歴を用意します。
# from は送信元アドレス、to は送信先アドレス、amount は送金額、time は時刻を表します。
transactions = [
    {"txid": "tx001", "from": "addr_A", "to": "addr_B", "amount": 3.0, "time": "09:10"},
    {"txid": "tx002", "from": "addr_B", "to": "addr_C", "amount": 1.2, "time": "09:40"},
    {"txid": "tx003", "from": "addr_B", "to": "addr_D", "amount": 1.7, "time": "09:45"},
    {"txid": "tx004", "from": "addr_C", "to": "exchange_X", "amount": 1.1, "time": "10:20"},
]

# 外部情報として分かっているラベルを用意します。
# ここでは exchange_X が取引所らしい、という情報だけが分かっているとします。
# 実務では、このようなラベルの根拠や鮮度を確認する必要があります。
known_labels = {
    "exchange_X": "既知の取引所アドレスの可能性",
}


def summarize_observed_flows(transactions):
    """
    取引履歴から直接観察できる情報を整理します。
    ここでは、送信元ごとにどのアドレスへいくら送ったかを集計します。
    """
    flows = defaultdict(list)

    for tx in transactions:
        # 取引データに書かれている送信元・送信先・金額は、観察できる情報として扱います。
        flows[tx["from"]].append({
            "to": tx["to"],
            "amount": tx["amount"],
            "txid": tx["txid"],
            "time": tx["time"],
        })

    return flows


def make_cautious_findings(transactions, known_labels):
    """
    観察できることと、推定にとどまることを分けて文章化します。
    断定しすぎないように、表現を意識して作ります。
    """
    findings = []

    for tx in transactions:
        # これは取引データから直接確認できる内容です。
        findings.append({
            "level": "観察",
            "text": f'{tx["from"]} から {tx["to"]} へ {tx["amount"]} が移動した取引があります。',
        })

        # 送信先や送信元が既知ラベルに含まれている場合だけ、外部情報にもとづく推定として扱います。
        if tx["to"] in known_labels:
            findings.append({
                "level": "推定",
                "text": f'{tx["to"]} は「{known_labels[tx["to"]]}」として扱われる場合があります。',
            })

    return findings


# 送信元ごとの資金移動を集計します。
flows = summarize_observed_flows(transactions)

print("送信元ごとの資金移動:")
for sender, outgoing in flows.items():
    print(f"- {sender}")
    for item in outgoing:
        print(f'  -> {item["to"]}: {item["amount"]} at {item["time"]} ({item["txid"]})')

print("\n分析メモ:")
for finding in make_cautious_findings(transactions, known_labels):
    print(f'[{finding["level"]}] {finding["text"]}')

このコードでは、まず取引履歴から直接見える資金移動を整理しています。
そのうえで、exchange_X という外部ラベルがある場合だけ、「取引所アドレスの可能性」という推定を書いています。

ポイントは、次の2つです。

1. 取引履歴から直接読める内容は「観察」として扱う
2. ラベルや外部情報にもとづく内容は「推定」として扱う

この区別を入れておくと、分析結果を説明するときに断定しすぎることを避けやすくなります。

たとえば、次の2つの表現は似ていますが、意味がかなり違います。

強すぎる表現	慎重な表現
addr_C は取引所ユーザーです	addr_C から既知の取引所アドレスとされる exchange_X への送金が確認できます
addr_B は資金を隠しました	addr_B から複数アドレスへ資金が分散したように見える取引があります
この取引は犯罪です	この取引は高リスクアドレスとの接点があるため、追加確認の対象になり得ます

技術記事では、こうした表現の違いがとても重要です。

4.9 追跡可能性は便利だが、万能ではない

ここまで見ると、ブロックチェーン分析には大きな強みがあります。

公開された取引履歴をもとに、資金の流れを時系列でたどれる場合があります。
ブロックエクスプローラーやAPIを使えば、アドレス、取引、ブロック、スマートコントラクトの情報を確認できます。
外部情報と組み合わせることで、アドレスの意味を推定できる場合もあります。

一方で、限界もあります。

• アドレスは本名ではない
• 1人が複数アドレスを使う場合がある
• 1つのアドレスがサービスやコントラクトを表す場合がある
• 外部ラベルは誤りや古さを含む可能性がある
• 取引の目的や意図はオンチェーンだけでは見えにくい
• 犯罪関与や責任の判断には、技術分析以外の根拠が必要になる

つまり、ブロックチェーン分析は「何でも分かる魔法」ではありません。
公開台帳から得られる強力な手がかりを、どこまで言えるのかに注意しながら扱う必要があります。

💡 豆知識
ブロックエクスプローラーや分析サービスでは、アドレスに「取引所」「DeFiプロトコル」などのラベルが付くことがあります。
これは電話番号に名前を登録する住所録に少し似ています。
ラベルがあると読みやすくなりますが、その根拠、更新時点、誤りの可能性を確認しないまま、強い断定につなげないことが重要です。

4.10 この章のまとめ

この章では、ブロックチェーンの追跡で分かることと、分からないことを整理しました。

パブリックブロックチェーンでは、アドレス、トランザクションID、金額、時刻、送信元、送信先、スマートコントラクトとのやり取りなどを確認できる場合があります。
そのため、資金の流れやアドレス間の関係を追跡できることがあります。

一方で、取引履歴を追えることと、現実世界の本人や取引の意図を断定できることは同じではありません。

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

• ブロックチェーン上で見えるのは、まずアドレス間の取引履歴である
• 取引履歴から、資金の流れや時系列を追える場合がある
• アドレスの持ち主、取引の理由、犯罪関与の有無は、オンチェーン情報だけでは断定しにくい
• 分析では、観察、推定、断定を分けて考える必要がある
• アドレスクラスタリングやラベル付けには不確実性がある
• 外部情報と結びつくと、アドレスの意味が具体的になる場合がある
• ただし、外部情報にも誤りや古さがあり得るため、根拠確認が必要である

次の章では、ここで触れた 外部情報と結びつくポイント をもう少し詳しく見ていきます。

ブロックチェーン上では単なるアドレスに見えていたものが、取引所、SNS、Webサイト、ENS、NFT、公的機関の発表などと結びつくことで、どのように意味を持ち始めるのかを整理します。

---

5. 外部情報と結びつくポイント

この章では、ブロックチェーン上のアドレスが、現実世界の情報と結びつく場面を整理します。
ポイントは、オンチェーン情報だけで突然「誰か」が分かるのではなく、取引所、SNS、Webサイト、名前付きサービス、公的リストなどの外部情報が手がかりになることです。

前の章では、ブロックチェーン追跡で分かることと、分からないことを分けて整理しました。
取引履歴、金額、時刻、アドレス同士のつながりは見える場合があります。
一方で、それだけを見ても、アドレスの背後にいる人物や組織を必ず特定できるわけではありません。

では、なぜニュースや調査レポートでは「このアドレスは取引所に関係している」「この資金は特定の事件と関係している可能性がある」といった説明が出てくるのでしょうか。

ここで重要になるのが、外部情報との結びつきです。

ブロックチェーン上の履歴は、いわば「名前のない行動記録」です。
そこに、取引所の本人確認情報、SNSで公開されたアドレス、公式サイトに掲載された寄付アドレス、ENSのような名前付き識別子、公的機関の制裁リストなどが重なると、見え方が変わります。

ただし、ここでも大切なのは、外部情報があるからといってすぐに断定しないことです。
外部情報は強い手がかりになる場合がありますが、古い情報、誤ったラベル、第三者が勝手に掲載した情報、複数人で共有されるアドレスなどもあり得ます。

この章では、外部情報がどのようにアドレスと結びつくのかを、身近な例から順番に見ていきます。

5.1 ニックネームだけでは分からなくても、プロフィールを見ると分かることがある

まずは、SNSを例に考えてみます。

あるSNSで、dance_cat_2026 というユーザー名のアカウントを見つけたとします。
このユーザー名だけを見ても、誰なのかは分かりません。

しかし、投稿履歴やプロフィールに次のような情報があったらどうでしょうか。

• 所属している大学名を書いている
• サークル名を書いている
• イベント写真に自分が写っている
• 他のSNSアカウントへのリンクがある
• フリマアプリや決済用のIDを掲載している

この場合、ユーザー名そのものは本名ではなくても、周辺情報と結びつくことで、かなり具体的な人物像が見えてくる可能性があります。

ブロックチェーンのアドレスも、これに近いところがあります。

アドレスそのものは、通常は本名ではありません。
しかし、そのアドレスがどこかのWebサイトやSNS、取引所、アプリ、公式資料、公的機関の発表などに登場すると、アドレスに意味が付きます。

この図のように、外部情報はオンチェーン分析に文脈を与えます。
ただし、文脈が増えることと、必ず正しい答えが出ることは同じではありません。

5.2 外部情報にはどのような種類があるのか

アドレスと結びつきやすい外部情報を、ざっくり整理すると次のようになります。

外部情報の種類	例	何が分かる可能性があるか	注意点
取引所・VASPの情報	入出金履歴、本人確認、Travel Rule関連情報	取引所口座や利用者情報と結びつく可能性	一般公開情報ではないため、通常は事業者や当局の管理下で扱われる
SNS・ブログ・掲示板	自分の寄付アドレス、投げ銭アドレス、NFT購入用アドレスを掲載	アドレスとハンドルネームが結びつく可能性	本人が掲載したとは限らない場合もある
公式サイト・寄付ページ	プロジェクト、団体、開発者、支援先のアドレス	組織やプロジェクトの管理アドレスと推定できる	アドレスの更新やなりすましに注意が必要
ENSなどの名前サービス	example.eth のような人間が読みやすい名前	長いアドレスよりも用途や主体を想像しやすい	名前の所有者と実際の利用者が常に同じとは限らない
ブロックエクスプローラーのラベル	取引所、DeFiプロトコル、ブリッジ、トークンコントラクトなどの表示	アドレスの用途を理解しやすい	ラベルの根拠や更新時期を確認する必要がある
公的機関の発表・制裁リスト	OFACのSDN Listなど	特定アドレスが制裁対象者に関連すると公表される場合がある	リストは網羅的とは限らず、法的判断には専門的確認が必要
事件・インシデント資料	公式発表、裁判資料、セキュリティ企業の分析	攻撃や詐欺と関係するアドレスの手がかり	二次情報は誤りや推定を含む場合がある

ここで特に大切なのは、外部情報には 公開情報 と 非公開情報 があることです。

SNSや公式サイトに掲載されたアドレスは、誰でも確認できる公開情報です。
一方で、取引所の本人確認情報や入出金履歴は、通常は一般の利用者が自由に見られるものではありません。

そのため、記事で説明するときは、次のように分けると安全です。

分類	説明
誰でも見られる情報	ブロックチェーン上の取引履歴、公開されたアドレス、公式サイト、SNS、ブロックエクスプローラーのラベルなど
事業者や当局が扱う情報	取引所の本人確認情報、入出金履歴、Travel Rule関連情報、法執行上の照会情報など
分析による推定情報	アドレスクラスタリング、資金フロー分析、リスクスコア、外部ラベルの統合結果など

オンチェーン分析を理解するときは、この3つを混ぜないことが大切です。

5.3 取引所やVASPで本人確認情報と結びつく場合

外部情報との結びつきで、特に重要なのが取引所やVASPです。

VASPは、Virtual Asset Service Provider の略で、日本語では暗号資産サービス提供者のように説明されます。
かなりざっくり言えば、暗号資産の交換、移転、保管などに関わる事業者を指す言葉です。

たとえば、暗号資産取引所を使う場合、多くの国や地域では本人確認が求められます。
このとき、取引所の内部では、利用者のアカウント情報と、入出金に使われたアドレスやトランザクションが結びつく可能性があります。

もちろん、この情報はブロックチェーン上にそのまま公開されるわけではありません。
しかし、事業者のコンプライアンス、法執行機関からの照会、AML/CFT対応などの文脈では、取引所が持つ情報が重要になる場合があります。

FATFは、暗号資産とVASPに対してAML/CFT基準を適用する方向を示しており、2025年のTargeted Updateでも、VASPのライセンス・登録、監督、Travel Ruleの実装、越境的なリスクなどが継続課題として整理されています。

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

また、金融庁も、FATF基準を踏まえ、暗号資産移転における送付人・受取人情報、いわゆるTravel Ruleに関する通知を行っています。

参考: 金融庁: Notification of Originator and Beneficiary Information upon Crypto Assets Transfer

ここで大切なのは、ブロックチェーン上のアドレスだけで本人が分かる、という話ではないことです。

むしろ、次のように理解すると自然です。

ブロックチェーン上ではアドレスと取引履歴が見える。
取引所やVASP側では、本人確認済みアカウントと入出金情報が結びつく場合がある。
その2つが適切な権限や手続きのもとで照合されると、追跡の精度が上がることがある。

この図のように、公開されているオンチェーン情報と、取引所が持つ本人確認情報は、見える範囲が異なります。
この違いを分けておくと、「ブロックチェーンは公開されているから誰でも本人特定できる」という誤解を避けられます。

5.4 SNSやWebサイトでアドレスを公開すると、あとから履歴と結びつく

次に分かりやすいのが、SNSやWebサイトでアドレスを公開するケースです。

たとえば、ある人がSNSで次のように投稿したとします。

活動支援はこちらのアドレスへお願いします。
0x1234...abcd

この場合、その投稿を見た人は、0x1234...abcd というアドレスと、そのSNSアカウントを結びつけられます。

一度アドレスが公開されると、そのアドレスに紐づく過去の取引履歴や、今後の取引履歴が見られる可能性があります。
Bitcoin.orgも、Bitcoinの取引は公開・永続的に保存され、アドレスの残高や取引は誰でも見ることができる一方、利用者の身元は購入などの場面で情報が明らかになるまで分からないと説明しています。

参考: Bitcoin.org: Some things you need to know - Bitcoin is not anonymous

ここで注意したいのは、公開されたアドレスが必ずその人の個人用アドレスとは限らないことです。

たとえば、次のようなケースがあります。

ケース	注意点
個人が自分の寄付用アドレスを掲載した	その個人の活動と結びつきやすい
団体が寄付用アドレスを掲載した	団体管理のアドレスであり、個人アドレスとは限らない
プロジェクトが入金用アドレスを掲載した	公式かどうか、更新されていないか確認が必要
第三者が勝手にアドレスを掲載した	本人や組織のアドレスとは限らない
詐欺サイトが偽の公式アドレスを掲載した	見た目が公式でも、アドレスが本物とは限らない

つまり、SNSやWebサイトにアドレスが載っていることは重要な手がかりです。
しかし、その情報が本当に本人・団体・公式ページ由来なのかを確認する必要があります。

5.5 ENSのような名前付き識別子は便利だが、プライバシー上の手がかりにもなる

Ethereumでは、長い16進数のアドレスの代わりに、ENSのような人間が読みやすい名前を使うことがあります。

ENSは、Ethereum Name Service の略です。
ざっくり言えば、0x... で始まる長いアドレスに、example.eth のような読みやすい名前を対応づける仕組みです。

Ethereum公式ドキュメントでは、ENS名がオンチェーンに保存され、ENS resolverを通じてEthereumアドレスへ解決されることが説明されています。
スマートコントラクトにENS名を付ける場合も、名前とアドレスの対応関係を使って、利用者が長い16進数アドレスではなく分かりやすい名前を確認できるようにする考え方が示されています。

参考: Ethereum.org: Naming smart contracts

ENSはとても便利です。
たとえば、友人に送金先を伝えるときに、長いアドレスを1文字ずつ確認するより、読みやすい名前を使える方がミスを減らしやすくなります。

一方で、名前が付くということは、アドレスの意味が分かりやすくなるということでもあります。

このように、名前付き識別子は利便性とプライバシーの両面を持ちます。

観点	良い点	注意点
送金	長いアドレスの入力ミスを減らしやすい	名前を間違えると別の相手に送る可能性がある
利用者体験	人間が覚えやすい	アドレスの用途が見えやすくなる
信頼性	公式コントラクトやプロジェクトを識別しやすい	名前の所有者・管理者を確認する必要がある
プライバシー	自分の活動をブランド化しやすい	複数の取引履歴が同じ名前に集約されやすい

ここでも大切なのは、「ENS名があるから本人が完全に分かる」という話ではありません。
ENS名は、アドレスの理解を助ける外部情報の一つです。
ただし、その名前を誰が登録・管理しているのか、どのアドレスに対応しているのかを確認する必要があります。

5.6 ウォレット接続やアプリ利用も、外部情報との接点になる

Ethereum公式は、ウォレットをEthereumアカウントとやり取りするためのツールとして説明しています。
また、ウォレットは残高や取引履歴を確認したり、トランザクションを送ったり、アプリに接続したりするために使われます。

参考: Ethereum.org: Wallets, accounts, keys and addresses

ここで重要なのは、ウォレット接続が「ブロックチェーン上の取引」だけでなく、Webアプリ側のログや利用履歴とも関係する場合があることです。

たとえば、あるdAppにウォレットを接続すると、そのdAppは接続されたアドレスを認識できます。
さらに、ユーザーがそのdApp上でどのボタンを押したか、どのページを見たか、どのタイミングで取引を出したかといった情報を、Webサービス側が持つ場合もあります。

これは、通常のWebサービスでログイン履歴やアクセスログが残ることに少し似ています。

場面	ブロックチェーン上で見える可能性があるもの	Webサービス側で見える可能性があるもの
ウォレット接続	接続そのものは必ずしもオンチェーン取引ではない	接続アドレス、日時、ブラウザ情報など
トークン交換	トランザクション、送受信、コントラクト呼び出し	画面操作、見積もり確認、接続セッションなど
NFT購入	購入取引、トークンID、支払い	商品ページの閲覧、検索履歴など
投票・署名	オンチェーン投票や署名検証に関わる情報	UI上の操作履歴、IPアドレス等のログが扱われる場合

もちろん、どの情報を保存するかはサービスごとに異なります。
プライバシーポリシーや設計によっても変わります。

ただ、ブロックチェーンを使っているからといって、すべての情報がオンチェーンだけで完結するわけではありません。
実際のサービス利用では、オンチェーン情報とオフチェーン情報が組み合わさることがあります。

5.7 公的機関のリストや発表がアドレスに意味を与える場合

外部情報として、もう一つ重要なのが公的機関の発表です。

たとえば、米国財務省のOFACは、制裁対象者に関連する識別子として、デジタル通貨アドレスをSDN Listに含める場合があると説明しています。
また、OFACのSanctions List Searchでは、デジタル通貨アドレスを検索できることも説明されています。

参考: OFAC: Questions on Virtual Currency

これは、アドレスが単なる文字列ではなく、公的なリスク情報と結びつく場合があることを示しています。

ただし、OFAC自身も、デジタル通貨アドレスのリストが網羅的とは限らないと説明しています。
つまり、リストに載っているアドレスだけを見れば十分、というわけではありません。

観点	説明
リストに載っているアドレス	公的機関が特定の対象と関連すると示した識別子
リストに載っていないアドレス	安全であることを意味するわけではない
関連アドレス	直接リストにないが、資金移動上つながる可能性があるアドレス
判断の注意点	法的判断や制裁対応は専門的な確認が必要

記事で扱う場合は、制裁回避や具体的な資金移動手順ではなく、公的機関がアドレスをリスク識別子として扱うことがあるという点に留めるのが安全です。

5.8 外部ラベルは便利だが、絶対視しない

ブロックエクスプローラーや分析サービスでは、アドレスにラベルが付いていることがあります。

たとえば、次のような表示です。

• ある取引所のホットウォレット
• あるDeFiプロトコルのコントラクト
• あるブリッジのコントラクト
• ある詐欺キャンペーンに関連するとされるアドレス
• ある事件の攻撃者アドレスとされるもの

このようなラベルは、取引履歴を読むうえでとても便利です。
長いアドレスだけでは分かりにくいものに、意味を与えてくれるからです。

ただし、ラベルは必ずしも完全ではありません。

ラベルの使い方	良い読み方	避けたい読み方
取引所ラベル	このアドレスは取引所関連の可能性が高い	このアドレスに送った人は全員その取引所の本人だ
詐欺関連ラベル	過去の事件や報告と関係する可能性がある	接触しただけで犯罪者だ
DeFiコントラクトラベル	コントラクトの用途を理解する手がかりになる	そのラベルだけで安全性を保証できる
制裁関連ラベル	コンプライアンス上の重要な警告になる	リスト外ならリスクがない

ラベルは、地図の目印に近いです。
地図に「駅」「学校」「病院」と書いてあると場所を理解しやすくなります。
しかし、地図が古い場合や、目印が移転している場合もあります。

同じように、アドレスのラベルも、根拠、更新時期、情報源、文脈を確認する必要があります。

5.9 外部情報を組み合わせる流れをコードで見る

ここでは、外部情報がアドレスに意味を与える流れを、簡単なPythonコードで見てみます。

このコードは、実際のオンチェーン分析や本人特定を行うものではありません。
架空の取引データと架空のラベルを使って、外部情報を結びつけると、アドレスの見え方が変わることを確認するための学習用モデルです。

# 外部情報とオンチェーン風の取引履歴を結びつける学習用コードです。
# 実在するアドレスや個人情報は使っていません。
# 目的は「ラベルが付くと履歴の読み方が変わる」ことを理解することです。

from collections import defaultdict

# 架空のオンチェーン取引データです。
# from は送信元アドレス、to は送信先アドレス、amount は送金額を表します。
transactions = [
    {"txid": "tx001", "from": "addr_alice", "to": "addr_exchange", "amount": 1.2},
    {"txid": "tx002", "from": "addr_exchange", "to": "addr_bob", "amount": 0.9},
    {"txid": "tx003", "from": "addr_bob", "to": "addr_shop", "amount": 0.4},
    {"txid": "tx004", "from": "addr_unknown", "to": "addr_donation", "amount": 0.1},
    {"txid": "tx005", "from": "addr_unknown", "to": "addr_exchange", "amount": 0.3},
]

# 架空の外部ラベルです。
# source は、そのラベルがどこから得られた情報かを表します。
# confidence は、ラベルの確からしさを簡易的に表す値です。
external_labels = {
    "addr_exchange": {
        "label": "Example取引所の入出金アドレス",
        "source": "ブロックエクスプローラーの公開ラベル",
        "confidence": 0.8,
    },
    "addr_shop": {
        "label": "Example Shopの決済用アドレス",
        "source": "公式Webサイトに掲載されたアドレス",
        "confidence": 0.9,
    },
    "addr_donation": {
        "label": "Example Projectの寄付用アドレス",
        "source": "プロジェクト公式ページ",
        "confidence": 0.9,
    },
}


def get_label(address):
    """アドレスに外部ラベルがある場合はラベルを返します。"""
    # ラベルがない場合は、未ラベルのアドレスとして扱います。
    return external_labels.get(address, {
        "label": "未ラベルのアドレス",
        "source": "外部情報なし",
        "confidence": 0.0,
    })


# アドレスごとに、関係する取引を集計します。
address_activity = defaultdict(list)

for tx in transactions:
    # 送信元アドレスの履歴として取引を追加します。
    address_activity[tx["from"]].append({
        "direction": "send",
        "counterparty": tx["to"],
        "amount": tx["amount"],
        "txid": tx["txid"],
    })

    # 送信先アドレスの履歴として取引を追加します。
    address_activity[tx["to"]].append({
        "direction": "receive",
        "counterparty": tx["from"],
        "amount": tx["amount"],
        "txid": tx["txid"],
    })


# 外部ラベルを付けながら、アドレスごとの履歴を表示します。
for address, activities in address_activity.items():
    label_info = get_label(address)

    print(f"\nアドレス: {address}")
    print(f"ラベル: {label_info['label']}")
    print(f"情報源: {label_info['source']}")
    print(f"確からしさ: {label_info['confidence']}")

    for activity in activities:
        counterparty_label = get_label(activity["counterparty"])["label"]

        # 取引相手にもラベルを付けることで、履歴の読み方が変わります。
        print(
            f"  - {activity['txid']}: {activity['direction']} "
            f"{activity['amount']} to/from {activity['counterparty']} "
            f"({counterparty_label})"
        )

このコードでは、addr_exchange や addr_shop のような架空アドレスに、外部ラベルを付けています。
すると、同じ取引履歴でも、単なる文字列のつながりではなく、次のように読めるようになります。

• addr_exchange は取引所関連のアドレスかもしれない
• addr_shop は店舗の決済用アドレスかもしれない
• addr_donation はプロジェクトの寄付用アドレスかもしれない

ただし、コード内の confidence で表しているように、ラベルには確からしさがあります。
現実の分析でも、外部ラベルを見つけたからといって、すぐに断定するのではなく、情報源や根拠の強さを確認する必要があります。

5.10 外部情報を使うときは「根拠の強さ」を分ける

外部情報は、すべて同じ強さではありません。

たとえば、本人が公式サイトで公開しているアドレスと、誰かが掲示板に書き込んだアドレスでは、信頼性が違います。
公的機関のリストと、個人ブログの推測でも、扱い方は変わります。

そこで、外部情報を見るときは、次のように根拠の強さを分けると整理しやすいです。

根拠の強さ	例	読み方
強い	公式サイト、公的機関の発表、本人確認済み事業者の内部情報	重要な根拠。ただし文脈や更新時期を確認する
中くらい	ブロックエクスプローラーのラベル、信頼できる調査レポート、複数資料で一致する情報	手がかりとして有用。根拠の出所を確認する
弱い	SNSの噂、掲示板の書き込み、単発のスクリーンショット	補助的な参考。断定には使わない

この考え方は、セキュリティ調査にも近いです。
ログ1件だけで判断するのではなく、複数のログ、時刻、通信先、端末情報、ユーザー操作などを合わせて判断します。

ブロックチェーン分析でも、同じです。

• オンチェーン履歴
• 外部ラベル
• 取引所情報
• 公式発表
• 事件資料
• 時刻や金額の一致
• 複数チェーン間の移動

これらを組み合わせることで、推定の精度が上がる場合があります。
一方で、どれか1つだけを根拠に強く断定すると、誤った結論につながる可能性があります。

5.11 外部情報があるほどプライバシーリスクも高まる

外部情報との結びつきは、追跡や調査に役立つ一方で、プライバシーリスクにもなります。

たとえば、ある人がSNSで1つのアドレスを公開したとします。
そのアドレスが、過去にも現在にも同じ用途で使われ続けている場合、そのアドレスの取引履歴全体が、SNSアカウントと結びついて見える可能性があります。

Bitcoin.orgも、プライバシー保護の観点から、Bitcoinアドレスは一度だけ使うべきだと説明しています。
これは、同じアドレスを繰り返し使うと、履歴が結びつきやすくなるためです。

参考: Bitcoin.org: Protect your privacy

ここで、追跡可能性とプライバシーの関係を整理すると次のようになります。

状況	追跡しやすさ	プライバシー上の注意点
1つのアドレスを長期間使う	履歴がつながりやすい	行動パターンが見えやすくなる
SNSでアドレスを公開する	ハンドルネームと結びつきやすい	過去・将来の履歴も見られる可能性がある
ENS名を使う	人間が認識しやすい	名前と履歴が結びつきやすい
取引所へ入出金する	事業者側の情報と結びつく可能性がある	本人確認情報は公開されないが、規制対応上重要になる
公式寄付アドレスを使う	団体・プロジェクトと結びつきやすい	入金者や出金先が見える場合がある

この章で扱っている内容は、追跡回避の手順を説明するためではありません。
むしろ、ブロックチェーンを使うときに、公開情報と外部情報が結びつくと、どのような見え方になるのかを理解するためのものです。

💡 豆知識
アドレスは、最初から本名が書かれた名札ではありません。
しかし、SNS、公式サイト、取引所、ENS、公的機関の発表などに登場すると、あとから名札が付くように意味づけされることがあります。
その瞬間以降の履歴だけでなく、過去の履歴の見え方も変わる場合があるため、将来どこかで外部情報と結びつく可能性もプライバシー上の論点になります。

5.12 この章のまとめ

この章では、ブロックチェーン上のアドレスが外部情報と結びつくポイントを整理しました。

アドレスそのものは、本名ではないことが多いです。
しかし、取引所やVASPの本人確認情報、SNSやWebサイトに掲載されたアドレス、ENSのような名前付き識別子、ブロックエクスプローラーのラベル、公的機関の制裁リストなどと結びつくと、そのアドレスの意味が見えやすくなります。

特に重要なのは、次の点です。

• オンチェーン情報だけで本人が必ず分かるわけではない
• 外部情報が加わると、アドレスの用途や主体を推定しやすくなる
• 取引所やVASPの情報は、AML/CFTやTravel Ruleの文脈で重要になる
• SNSや公式サイトに掲載されたアドレスは、履歴と結びつく可能性がある
• ENSのような名前付き識別子は便利だが、プライバシー上の手がかりにもなる
• 公的機関のリストは重要な情報源だが、網羅的とは限らない
• 外部ラベルは便利だが、根拠や更新時期を確認する必要がある

ここまでで、ブロックチェーンの追跡可能性が、オンチェーン情報だけでなく、外部情報との組み合わせで成り立つことが見えてきました。

次の章では、この追跡可能性が実務上どのような場面で使われるのかを、AML/CFT という観点から整理します。
暗号資産の不正利用を防ぐ取り組みの中で、オンチェーン分析がどのような役割を持つのか、またどこに限界があるのかを見ていきます。

6. AML/CFTとオンチェーン分析の関係

この章では、ブロックチェーンの追跡可能性がAML/CFTとどのように関係するのかを整理します。
ポイントは、オンチェーン分析は不正資金対策の重要な手がかりになる一方で、それだけで本人特定や犯罪関与を断定するものではない、という点です。

前の章では、ブロックチェーン上のアドレスが、取引所、SNS、Webサイト、ENS、公的機関のリストなどの外部情報と結びつくと、見え方が変わることを整理しました。

ここからは、その考え方をもう少し実務的な文脈に近づけます。
特に暗号資産では、AML/CFT という言葉がよく出てきます。

いきなり英字の略語が出てくると少し身構えてしまいますが、最初は次のように捉えると分かりやすいです。

AML/CFTは、犯罪やテロに関係するお金の流れを見つけ、不正利用を防ぐための取り組みです。

たとえば、銀行では、明らかに不自然な入出金があった場合、本人確認、取引目的の確認、疑わしい取引の届出などが行われることがあります。
暗号資産でも同じように、「どこから資金が来たのか」「どこへ流れているのか」「高リスクな相手と関係していないか」を確認する必要が出てきます。

ここで、ブロックチェーンの透明性が関係します。

パブリックブロックチェーンでは、取引履歴が公開されることが多いため、資金の流れを一定範囲で追うことができます。
この公開された取引履歴を分析することが、オンチェーン分析です。

ただし、ここで大切なのは、オンチェーン分析を「犯人を一発で特定する魔法」と考えないことです。

オンチェーン分析で分かるのは、基本的には アドレス間の資金移動や、既知のラベルとの接点 です。
本人確認情報、取引所内部の記録、法執行機関の情報、被害届、通信記録などとは別物です。

そのため、この章では、AML/CFTとオンチェーン分析の関係を、次の順番で整理します。

• AML/CFTとは何か
• 暗号資産でなぜAML/CFTが重要になるのか
• VASPとTravel Ruleがどのように関係するのか
• オンチェーン分析がどのような場面で役立つのか
• 分析結果を扱うときに、どのような限界や注意点があるのか

FATFは、暗号資産や暗号資産サービス提供者に対するAML/CFT基準の実装状況を継続的に更新しており、2025年のTargeted Updateでも、VASPの登録・監督、Travel Rule、ステーブルコイン、不正利用リスクなどが重要な論点として扱われています。

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

6.1 AML/CFTを身近な例で考える

まずは、普通の銀行口座で考えてみます。

たとえば、ある口座に次のような動きがあったとします。

• 短時間に多数の入金がある
• 入金後すぐに別口座へ送金される
• 海外の複数口座へ細かく分けて送金される
• 過去に不正利用が疑われた口座と何度も取引している

もちろん、これだけで「犯罪である」とは言えません。
正当な事業活動や、イベントの集金、家族間の送金など、さまざまな理由が考えられます。

ただし、金融機関の立場では、「通常の利用と比べて不自然ではないか」「追加確認が必要ではないか」を見るきっかけになります。

暗号資産でも、これに近いことが起こります。

たとえば、あるアドレスに大量の暗号資産が入ってきて、すぐに複数のアドレスへ分散される。
その一部が、過去にハッキング被害や詐欺と関連づけられたアドレスへ流れている。
あるいは、取引所へ入金され、法定通貨へ交換される可能性がある。

こうした流れを確認するために、オンチェーン分析が使われます。

この図で大事なのは、オンチェーン分析が 判断の入口 になっている点です。

ブロックチェーン上の履歴を見ることで、「どの方向に資金が流れているか」「どのアドレスと関係しているか」を確認できます。
しかし、最終的な判断には、外部情報や制度上の手続きが必要になります。

6.2 AML、CFT、VASP、Travel Ruleを整理する

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

用語	読み方	ざっくりした意味
AML	Anti-Money Laundering	犯罪で得たお金を、正当なお金に見せかける行為を防ぐ取り組み
CFT	Countering the Financing of Terrorism	テロ活動に資金が流れることを防ぐ取り組み
VA	Virtual Asset	FATF文脈で使われる暗号資産などの仮想資産
VASP	Virtual Asset Service Provider	暗号資産交換業者など、暗号資産関連サービスを提供する主体
Travel Rule	トラベルルール	暗号資産などの移転時に、送付人・受取人情報を伝えるためのルール
CDD	Customer Due Diligence	顧客確認。本人確認や取引目的の確認など
STR/SAR	Suspicious Transaction/Activity Report	疑わしい取引・活動を当局へ届け出る仕組み

FATFのVirtual Assetsページでは、各国に対して、暗号資産分野のマネーロンダリング・テロ資金供与リスクを理解し、VASPを登録・免許制にし、金融機関と同様に監督することを求めています。
また、VASPには、顧客管理、記録保存、疑わしい取引の報告、移転時の送付人・受取人情報の取得・保持・安全な送信などが求められると説明されています。

参考: FATF: Virtual Assets

これを身近な言い方にすると、次のようになります。

暗号資産だからといって、資金の流れを何も確認しなくてよいわけではありません。
取引所などの事業者には、利用者や取引のリスクを確認し、必要な情報を記録・共有する役割があります。

6.3 Travel Ruleは「取引経路を見えるようにする」ための仕組み

Travel Ruleは、暗号資産のAML/CFTを考えるうえで重要なルールです。

名前だけ見ると旅行に関係しそうですが、ここでのTravelは「情報が資金移動と一緒に移動する」というイメージです。
暗号資産がA社からB社へ移転されるとき、送付人や受取人に関する情報もあわせて伝えることで、あとから取引経路を確認しやすくします。

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

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

ざっくり図にすると、次のようなイメージです。

この図で分かるように、ブロックチェーン上の取引だけでは、実名や本人確認情報までは見えないことが多いです。
そのため、VASP間で必要な情報を通知・記録する仕組みが重要になります。

金融庁は、2025年の資料でも、日本が暗号資産・電子決済手段の取引経路を追跡可能にするため、VASPに送付人・受取人情報の通知義務を課していること、また対象法域を各国の施行状況などを踏まえて追加していることを説明しています。

参考: 金融庁: トラベルルールの対象法域について

ただし、Travel Ruleは「すべてのアドレスの本人が一般公開される」という意味ではありません。
公開ブロックチェーン上の取引履歴と、事業者が法令上扱う本人確認情報は、別のレイヤーにあります。

情報の種類	主に見える人	例
オンチェーン情報	誰でも確認できることが多い	アドレス、取引ハッシュ、金額、時刻、送受信関係
VASPが持つ顧客情報	VASPや当局など、権限を持つ主体	氏名、本人確認情報、顧客ID、取引目的
Travel Ruleで通知される情報	関係するVASPなど	送付人・受取人に関する一定の情報
一般公開ラベル	誰でも確認できることがある	取引所アドレス、制裁対象アドレス、公式寄付アドレスなど

つまり、Travel Ruleは、オンチェーンの透明性だけでは足りない部分を、事業者間の情報連携で補う仕組みとして見ると分かりやすいです。

6.4 オンチェーン分析が役立つ場面

では、オンチェーン分析はAML/CFTでどのように役立つのでしょうか。

分かりやすいのは、次のような場面です。

場面	オンチェーン分析で見ること	注意点
ハッキング後の資金移動	被害アドレスからどこへ資金が流れたか	流れを追えても、最終的な犯人特定には外部情報が必要
詐欺被害の調査	被害者から送金された先、集約先、取引所入金先	同じアドレスが複数事件で使われる場合もある
取引所の入金監視	高リスクアドレスからの入金や近い関係	近い関係だけで犯罪関与とは断定できない
制裁・高リスクアドレスの確認	公的リストや既知ラベルとの接点	リストの更新時期や法域に注意が必要
不自然な資金移動の検知	短時間の分散、集約、反復的な送金	正当な理由がある場合もあるため追加確認が必要
クロスチェーン移動の確認	ブリッジや別チェーンへの移動	チェーンをまたぐと分析が難しくなる

ここで大切なのは、オンチェーン分析を「証拠そのもの」ではなく、調査の手がかりとして扱うことです。

たとえば、あるアドレスが高リスクアドレスから資金を受け取っていたとします。
しかし、それだけでそのアドレスの持ち主が犯罪に関与しているとは限りません。

• たまたま二次的に資金を受け取っただけかもしれない
• 取引所や決済サービスの共有アドレスかもしれない
• 被害者が資金を送らされただけかもしれない
• ラベル情報が古い、または誤っているかもしれない

そのため、AML/CFTの文脈では、オンチェーン分析の結果をもとに、追加確認、リスク評価、必要な対応を考えることになります。

6.5 リスクベース・アプローチで見る

AML/CFTでは、リスクベース・アプローチ という考え方がよく使われます。

これは、すべての取引を同じ強さで見るのではなく、リスクの高さに応じて確認の深さや対応を変える考え方です。

たとえば、次の2つを比べてみます。

取引の例	考えられる対応
少額で、長年利用している顧客の通常パターンに近い入金	通常のモニタリングでよい場合がある
高リスクアドレスに近い資金が、短時間で複数回に分かれて入金	追加確認や詳しい調査が必要になる場合がある

FATFの2021年ガイダンスでは、各国やVASPが暗号資産関連のリスクを評価・軽減し、VASPを登録・免許制にして監督すること、またVASPに金融機関と同様の関連措置が求められることが説明されています。

参考: FATF: Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs, 2021

オンチェーン分析は、このリスク評価を助ける材料になります。

ここで「リスクが高そう」と書いているのは、わざと少し柔らかい表現にしています。
オンチェーン分析には推定が含まれるため、単純に 危険 = 犯罪 と決めつけるのは危険です。

6.6 簡単なPythonコードでリスク確認の考え方を見る

ここでは、AML/CFTの考え方を理解するために、かなり単純化したPythonコードを見てみます。

このコードは、実際の取引監視システムではありません。
実在のアドレスや取引を判定するものでもありません。
あくまで、オンチェーン上の手がかりをもとに、追加確認が必要な取引を拾い上げるという考え方を理解するための学習用モデルです。

# AML/CFTにおけるオンチェーン分析の考え方を説明するための簡易モデルです。
# 実際の取引監視システムやリスク判定ロジックではありません。

from collections import defaultdict

# 架空のアドレスラベルです。
# 実務では、ラベルの根拠、更新時期、情報源の信頼性を確認する必要があります。
address_labels = {
    "addr_exchange": "取引所",
    "addr_scam": "詐欺関連として報告されたアドレス",
    "addr_mixer": "ミキサー関連として知られるサービス",
    "addr_user_a": "通常利用者A",
    "addr_user_b": "通常利用者B",
    "addr_unknown": "ラベルなし",
}

# 架空の取引履歴です。
# from から to へ amount が送られた、という単純な形にしています。
transactions = [
    {"txid": "tx001", "from": "addr_user_a", "to": "addr_user_b", "amount": 1.2, "time": "09:00"},
    {"txid": "tx002", "from": "addr_scam", "to": "addr_unknown", "amount": 8.0, "time": "09:10"},
    {"txid": "tx003", "from": "addr_unknown", "to": "addr_exchange", "amount": 7.9, "time": "09:20"},
    {"txid": "tx004", "from": "addr_user_b", "to": "addr_mixer", "amount": 0.5, "time": "10:00"},
    {"txid": "tx005", "from": "addr_unknown", "to": "addr_user_a", "amount": 0.1, "time": "10:30"},
]

# リスク確認の対象になりやすいラベルを定義します。
# ここでは説明用に単純化しています。
high_risk_keywords = ["詐欺", "ミキサー"]


def get_label(address):
    """アドレスに付いているラベルを返します。ラベルがなければ「ラベルなし」とします。"""
    return address_labels.get(address, "ラベルなし")


def contains_high_risk_keyword(label):
    """ラベルに高リスクと見なすキーワードが含まれているか確認します。"""
    return any(keyword in label for keyword in high_risk_keywords)


def screen_transactions(transactions):
    """取引ごとに、追加確認が必要そうな理由を整理します。"""
    flagged = []

    for tx in transactions:
        from_label = get_label(tx["from"])
        to_label = get_label(tx["to"])
        reasons = []

        # 送付元が高リスクラベルに近い場合、追加確認の理由に入れます。
        if contains_high_risk_keyword(from_label):
            reasons.append(f"送付元が高リスクラベルに該当: {from_label}")

        # 送付先が高リスクラベルに近い場合も、追加確認の理由に入れます。
        if contains_high_risk_keyword(to_label):
            reasons.append(f"送付先が高リスクラベルに該当: {to_label}")

        # 金額が大きい取引は、ここでは説明用に追加確認の対象にします。
        # 実務では、金額だけでなく顧客属性や通常パターンとの違いも見ます。
        if tx["amount"] >= 5.0:
            reasons.append("説明用しきい値以上の金額")

        # 何らかの理由がある取引だけを抽出します。
        if reasons:
            flagged.append({
                "txid": tx["txid"],
                "from": tx["from"],
                "to": tx["to"],
                "amount": tx["amount"],
                "reasons": reasons,
            })

    return flagged


flagged_transactions = screen_transactions(transactions)

for item in flagged_transactions:
    print(f"追加確認候補: {item['txid']}")
    for reason in item["reasons"]:
        print(f"  - {reason}")

このコードでは、取引ごとに次のような点を確認しています。

• 送付元が高リスクラベルに近いか
• 送付先が高リスクラベルに近いか
• 金額が説明用のしきい値以上か

ただし、これはあくまで学習用の簡易モデルです。
実際のAML/CFTでは、もっと多くの情報を使います。

たとえば、顧客の通常取引パターン、本人確認情報、取引目的、地域、資産の種類、過去のアラート、法令上の要件、社内規程などが関係します。
また、リスク判定は自動化だけで完結するものではなく、人による確認やエスカレーションも重要です。

6.7 もう少し「資金の流れ」を見る例

先ほどのコードは、1件ずつの取引を見ていました。
しかし、オンチェーン分析では、単発の取引だけでなく、資金がどのように移動しているかを見ることもあります。

たとえば、詐欺関連として報告されたアドレスから、いったんラベルのないアドレスへ移り、その後、取引所へ入金されるような流れです。

次のコードでは、架空の取引データから、ある開始アドレスの資金が何ホップ先まで流れているかを確認します。

# 資金の流れを簡単に追うための学習用コードです。
# 実際の事件調査や取引追跡に使うものではありません。

from collections import deque, defaultdict

# このコードブロックだけでも動くように、架空のラベルと取引データを再定義します。
# 実在のアドレスや取引ではありません。
address_labels = {
    "addr_exchange": "取引所",
    "addr_scam": "詐欺関連として報告されたアドレス",
    "addr_mixer": "ミキサー関連として知られるサービス",
    "addr_user_a": "通常利用者A",
    "addr_unknown": "ラベルなし",
}

transactions = [
    {"txid": "tx002", "from": "addr_scam", "to": "addr_unknown", "amount": 8.0},
    {"txid": "tx003", "from": "addr_unknown", "to": "addr_exchange", "amount": 7.9},
    {"txid": "tx004", "from": "addr_exchange", "to": "addr_user_a", "amount": 1.0},
]


def get_label(address):
    """アドレスに付いているラベルを返します。ラベルがなければ「ラベルなし」とします。"""
    return address_labels.get(address, "ラベルなし")


# 架空取引から、送付元 -> 送付先 のつながりを作ります。
graph = defaultdict(list)
for tx in transactions:
    graph[tx["from"]].append({
        "to": tx["to"],
        "txid": tx["txid"],
        "amount": tx["amount"],
    })


def trace_funds(start_address, max_depth=2):
    """開始アドレスから、指定した深さまで資金の流れをたどります。"""
    results = []
    queue = deque([(start_address, 0)])
    visited = {start_address}

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

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

        # current_address から出ていく取引を確認します。
        for edge in graph[current_address]:
            next_address = edge["to"]
            results.append({
                "depth": depth + 1,
                "from": current_address,
                "to": next_address,
                "txid": edge["txid"],
                "amount": edge["amount"],
                "to_label": get_label(next_address),
            })

            # 同じアドレスを何度もたどらないようにします。
            if next_address not in visited:
                visited.add(next_address)
                queue.append((next_address, depth + 1))

    return results


flow = trace_funds("addr_scam", max_depth=2)

for item in flow:
    print(
        f"{item['depth']} hop: {item['from']} -> {item['to']} "
        f"({item['amount']} / {item['to_label']})"
    )

このコードを見ると、あるアドレスから資金がどこへ流れたかを、グラフとしてたどるイメージがつかめます。

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

実際のブロックチェーンでは、手数料、複数入力・複数出力、スマートコントラクト、DEX、ブリッジ、内部取引、取引所の内部台帳など、さまざまな要素が関係します。
そのため、単純に「2ホップ以内だから危険」「取引所へ行ったから換金された」と断定するのは危険です。

このコードは、あくまで 取引履歴をグラフとして見ると、資金の流れを追う発想が分かりやすい という説明用です。

6.8 オンチェーン分析の限界

オンチェーン分析は便利ですが、万能ではありません。

特に、次のような限界があります。

限界	どういうことか
アドレスと人は一対一とは限らない	1人が複数アドレスを使うことも、1つのアドレスがサービス全体を表すこともある
取引所内部の移動は外から見えにくい	ブロックチェーン上では取引所アドレスまで見えても、その内部台帳は別管理になる
ラベルは推定を含む	ブロックエクスプローラーや分析サービスのラベルが常に完全とは限らない
DeFiやブリッジで経路が複雑になる	スマートコントラクトや別チェーンをまたぐと、追跡の前提が増える
プライバシー技術で見えにくくなる場合がある	取引の関係や金額が分かりにくくなる設計もある
正当な利用と不正利用の区別は履歴だけでは難しい	高リスク接点があっても、被害者や無関係な利用者の可能性がある

このため、オンチェーン分析の結果は、次のように扱うのが安全です。

言い切りすぎる表現	より安全な表現
このアドレスは犯罪者である	このアドレスは高リスクとされる資金の流れと接点がある
この取引はマネーロンダリングである	この取引は追加確認が必要なパターンに該当する可能性がある
2ホップ以内だから危険	近い経路に既知の高リスクアドレスがあるため、文脈確認が必要
取引所へ入ったので換金された	取引所関連アドレスへ入金された可能性があるが、内部処理は外部からは断定しにくい

この姿勢は、記事全体の方針ともつながります。

ブロックチェーンは透明性が高い一方で、その透明性から読み取れる内容には限界があります。
見える情報と見えない情報、推定と断定、技術的分析と法的判断を分けて考えることが大切です。

6.9 アンホステッド・ウォレットとの関係

暗号資産では、取引所のような事業者が管理するウォレットだけでなく、利用者が自分で秘密鍵を管理するウォレットも使われます。

このようなウォレットは、一般に アンホステッド・ウォレット と呼ばれます。
「ホストされていない」、つまり事業者が管理していないウォレットという意味です。

身近な例でいうと、銀行口座ではなく、自分の手元の財布に近いイメージです。
ただし、暗号資産の場合は、手元の財布から世界中へ直接送金できるため、AML/CFTの観点では独特の難しさがあります。

金融庁資料でも、アンホステッド・ウォレットはP2P取引が可能であり、VASPが取引に関与しないため把握が困難であること、匿名性や管理者による移転制限の欠如によるリスクが存在することが説明されています。
また、アンホステッド・ウォレット等との取引についても、所有者情報の収集・保存や、取引相手の属性に関する調査・分析、マネーロンダリングリスク評価などが制度上の論点として示されています。

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

ここで大切なのは、アンホステッド・ウォレットそのものが悪いという話ではありません。

自分で秘密鍵を管理することは、ブロックチェーンの大きな特徴の一つです。
一方で、事業者の本人確認や移転制限を通らない資金移動ができるため、不正利用への対策やリスク評価が難しくなる、ということです。

💡 豆知識
オンチェーン分析は、防犯カメラの映像確認に少し似ています。
映像に手がかりが映ることはありますが、映っている人が必ず犯人とは限りません。
ブロックチェーンの取引履歴も同じで、高リスクアドレスとの近さは追加確認の入口にはなりますが、それだけで犯罪関与を断定するのは危険です。

6.10 この章のまとめ

この章では、AML/CFTとオンチェーン分析の関係を整理しました。

AML/CFTは、犯罪収益の移転やテロ資金供与を防ぐための取り組みです。
暗号資産では、取引が国境を越えやすく、アドレスが実名ではなく仮名的に使われることが多いため、VASPによる本人確認、記録保存、疑わしい取引の報告、Travel Ruleなどが重要になります。

オンチェーン分析は、ブロックチェーン上に公開された取引履歴を使って、資金の流れや高リスクアドレスとの接点を確認するために役立ちます。
一方で、分析結果には推定が含まれるため、それだけで本人特定や犯罪関与を断定してはいけません。

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

• AML/CFTは、不正なお金の流れやテロ資金供与を防ぐための取り組みである
• 暗号資産では、VASPが顧客管理、記録保存、疑わしい取引の報告などで重要な役割を持つ
• Travel Ruleは、暗号資産などの移転時に送付人・受取人情報を通知し、取引経路を見えるようにする仕組みである
• オンチェーン分析は、資金の流れや高リスクアドレスとの接点を確認する手がかりになる
• ただし、アドレスと人は一対一とは限らず、ラベルやクラスタリングには推定が含まれる
• 分析結果は、本人確認情報、内部記録、法的手続き、追加調査などと分けて考える必要がある
• アンホステッド・ウォレットは正当な自己管理の手段でもある一方、AML/CFT上のリスク評価が難しい領域でもある

ここまでで、ブロックチェーンの透明性が、AML/CFTのような不正資金対策に役立つ場面が見えてきました。

一方で、透明性が高すぎると、普通の利用者のプライバシーまで見えやすくなるという別の課題もあります。
次の章では、この課題に対して、プライバシーを高める技術や仕組みがどのように関係するのかを見ていきます。

---

7. プライバシーを高める技術と注意点

この章では、ブロックチェーンにおけるプライバシーを高める技術や考え方を整理します。
ポイントは、プライバシー保護には正当な目的がある一方で、不正利用リスクや規制上の論点もあるという点です。

前の章では、AML/CFTとオンチェーン分析の関係を見ました。

ブロックチェーン上の取引履歴は、資金の流れを追う手がかりになります。
そのため、不正資金の移動、ハッキング被害後の資金追跡、制裁対象との接点確認などでは、公開された履歴が役に立つ場面があります。

一方で、ここで少し立ち止まる必要があります。

もし、すべての支払い履歴、保有資産、取引相手、利用サービスが公開され続けるとしたらどうでしょうか。
たとえ本名が出ていなくても、日々の行動や関心、資産状況が見えすぎてしまう可能性があります。

たとえば、次のような履歴を想像してみます。

身近な履歴	見えると便利な場面	見えすぎると困る場面
家計簿	支出を管理できる	生活パターンや趣味が分かる
交通系ICカードの履歴	移動経路を確認できる	通学・通勤先や行動時間が分かる
スマホ決済履歴	支払いミスを確認できる	よく行く店や購入傾向が見える
SNSの投稿履歴	発言の流れを追える	過去の行動や関係性が残り続ける
ブロックチェーンの取引履歴	資金の流れを検証できる	アドレスに紐づく行動が見えやすい

このように、透明性は便利です。
ただし、透明性が高いほど、プライバシーへの配慮も必要になります。

ブロックチェーンにおけるプライバシー技術は、このバランスを取るために登場してきました。

ただし、本章で扱う内容は、追跡を逃れるための実践手順ではありません。
あくまで、公開台帳の上でどのようにプライバシーを守ろうとしているのか、そして どのような注意点があるのか を理解するための整理です。

7.1 プライバシー保護は「隠す」だけではない

プライバシー技術というと、すぐに「取引を隠す技術」と考えたくなるかもしれません。

しかし、実際にはもう少し広い考え方があります。

たとえば、日常生活でも、私たちはすべてを完全に隠しているわけではありません。
お店で支払いをするとき、支払いが正しく行われたことは相手に伝える必要があります。
ただし、財布の中身をすべて見せる必要はありません。

会員証を見せるときも同じです。
「この人は会員である」という事実は確認してもらう必要があります。
しかし、住所、過去の購入履歴、残高、他サービスの利用状況まで見せる必要はありません。

ブロックチェーンでも、プライバシー保護にはいくつかの方向があります。

方向性	ざっくりした意味	身近なイメージ
履歴を結びつけにくくする	1つの識別子にすべての行動が集まらないようにする	用途ごとにメールアドレスを分ける
対応関係を分かりにくくする	入金と出金のつながりを外から見えにくくする	複数人分の会計をまとめて処理する
金額や相手を見えにくくする	取引内容の一部を公開しない	レシートの合計だけ見せて明細を隠す
正しさだけを示す	中身を全部見せずに条件を満たすことを示す	年齢を見せずに「20歳以上」と証明する
必要な相手にだけ開示する	一般公開せず、監査者などに限定して見せる	先生には提出するが全員には公開しない

ここで大切なのは、プライバシー保護は「何も見せないこと」だけではないという点です。

むしろ、ブロックチェーンでは、次のような問いが重要になります。

• どの情報を公開するのか
• どの情報を隠すのか
• 誰にだけ見せるのか
• 正しさをどう確認するのか
• 不正利用をどう防ぐのか

この章では、これらの観点から、代表的な技術や仕組みを整理していきます。

7.2 アドレス管理：1つの識別子に履歴を集めすぎない

まず、最も基本的な考え方がアドレス管理です。

ブロックチェーンでは、実名ではなくアドレスで取引することが多いです。
そのため、一見すると匿名に見えることがあります。

しかし、同じアドレスを何度も使うと、そのアドレスに履歴が積み上がります。

たとえば、次のようなイメージです。

これは、SNSで同じユーザー名をいろいろなサービスに使い回す感覚に少し似ています。

本名を書いていなくても、同じユーザー名でブログ、SNS、フリマアプリ、ゲームアカウントを使っていると、それらが同じ人の活動だと推測されやすくなります。

Bitcoin.orgのプライバシー解説でも、Bitcoinでは取引が公開・追跡可能・永続的に保存されるため、アドレスを一度だけ使うことや、複数の支払いを同じアドレスに集めないことがプライバシー上重要だと説明されています。

参考: Bitcoin.org: Protect your privacy

ただし、ここで注意したいのは、アドレスを分ければ完全に匿名になるわけではないという点です。

たとえば、別々のアドレスを使っていても、次のような情報から関係が推定されることがあります。

結びつくきっかけ	例
同じ取引で一緒に使われる	複数アドレスから同時に支払う
取引所の入出金と結びつく	本人確認済みサービスへ送る
SNSやWebサイトで公開する	寄付用アドレスをプロフィールに載せる
ENSなどの名前を使う	覚えやすい名前がアドレスと紐づく
金額や時間のパターンが似る	同じ金額が短時間で移動する

つまり、アドレス管理はプライバシーを考えるうえで大事ですが、それだけですべてが解決するわけではありません。

記事では、次のように理解すると安全です。

アドレス管理は、履歴の結びつきを減らすための基本的な考え方です。
ただし、取引パターンや外部情報によって、別々のアドレスが関係づけられる可能性は残ります。

7.3 CoinJoin：複数人の取引をまとめて対応関係を分かりにくくする

次に、CoinJoinの考え方を見てみます。

CoinJoinは、複数人の取引を1つの大きな取引にまとめることで、どの入力がどの出力に対応するのかを外から分かりにくくする考え方です。

身近な例でいうと、複数人で食事をしたあと、全員が個別に支払うのではなく、いったん代表者がまとめて会計し、あとから参加者間で精算するようなイメージに近いです。

ただし、この例は完全な対応ではありません。
実際のCoinJoinでは、暗号資産の取引構造や署名の仕組みが関係します。
ここでは、「複数人の取引をまとめると、単純な一対一対応が見えにくくなる」という直感だけ押さえます。

このように、入力と出力が1つの取引にまとまると、外部の観察者からは単純に「入力Aは出力Xへ送られた」と言いにくくなります。

ただし、CoinJoinにも限界があります。

• 参加者の数が少ないと、推定しやすくなることがある
• 金額が特徴的だと、対応関係を推測されることがある
• 前後の取引履歴から再び結びつくことがある
• 利用するソフトウェアやサービスの設計に依存する
• 法域や事業者によって扱いが異なる場合がある

Bitcoin.orgも、第三者サービスは取引を他の利用者の取引と混ぜることでプライバシーを高める場合がある一方、信頼やログ、資金の盗難、法域ごとの扱いといった注意点があると説明しています。

参考: Bitcoin.org: Protect your privacy

このため、記事ではCoinJoinを「追跡不能にする方法」とは書かない方がよいです。

より正確には、次のように表現します。

CoinJoinは、複数人の取引をまとめることで、入力と出力の対応関係を分かりにくくする考え方です。
ただし、利用状況や前後の履歴によって推定される可能性は残ります。

7.4 ミキサー：プライバシー保護と不正利用リスクの両方がある

CoinJoinと似た文脈で出てくる言葉に、ミキサーがあります。

ミキサーは、複数の利用者の資金を混ぜることで、入金元と出金先の対応関係を分かりにくくするサービスや仕組みを指します。

身近な例としては、複数人の紙幣を一度箱に入れ、あとから同じ金額分を別の紙幣で受け取るようなイメージです。
ただし、これはあくまで直感的な説明であり、実際の仕組みはサービスやプロトコルによって異なります。

ここで重要なのは、ミキサーを一面的に見ないことです。

プライバシーを守る目的で考えられる一方で、不正に得た資金の流れを分かりにくくするために悪用されるリスクもあります。
そのため、規制・法執行上の焦点になりやすい領域です。

Bitcoin.orgは、ミキシングサービスについて、利用者間の追跡可能性を混ぜることでプライバシーを高める場合がある一方、合法性は法域によって異なり、運営者に資金を盗まれないことやログを保持しないことを信頼する必要があると説明しています。

参考: Bitcoin.org: Protect your privacy

また、Tornado Cashをめぐっては、米国司法省が2023年に創設者らを資金洗浄や制裁違反などで起訴したと発表しています。
一方で、米国財務省は2025年3月21日に、Tornado Cashに対する経済制裁を解除したことも発表しています。

参考: U.S. Department of Justice: Tornado Cash Founders Charged With Money Laundering And Sanctions Violations
参考: U.S. Department of the Treasury: Tornado Cash Delisting

このように、ミキサーは技術・プライバシー・法制度が交差する難しいテーマです。

そのため、本記事では具体的な利用手順には踏み込みません。
扱うのは、あくまで次の範囲です。

• ミキサーは何を分かりにくくしようとするのか
• なぜAML/CFTや制裁対応で問題になりやすいのか
• プライバシー保護と不正利用リスクをどう分けて考えるのか

7.5 プライバシー重視の暗号資産：ZcashとMoneroの例

ブロックチェーンのプライバシーを考えるうえで、ZcashやMoneroのようなプライバシー重視の暗号資産もよく出てきます。

ここでも、詳細な内部実装に入る前に、まずは目的を整理します。

BitcoinやEthereumのような多くのパブリックチェーンでは、アドレスや取引履歴が公開されます。
一方、プライバシー重視の暗号資産では、送信者、受信者、金額などの一部を外から見えにくくする設計が取り入れられています。

ただし、ここでも「プライバシーコイン = 完全匿名」と考えるのは危険です。
実装、利用方法、外部情報、取引所との接点、過去の設計上の制約などによって、プライバシーの強さは変わります。

7.6 Zcash：透明アドレスとシールドアドレス

Zcashでは、透明アドレスとシールドアドレスという考え方が出てきます。

透明アドレスは、Bitcoinのように取引履歴が見えやすいアドレスです。
一方、シールドアドレスでは、ゼロ知識証明を使って、取引に関する情報の一部を隠しながら正しさを確認できるようにします。

Zcashのドキュメントでは、シールドアドレスを使うことでプライバシーを高められる一方、トランザクションID、金額、相手先情報などのメタデータを漏らすとリンクに使われる可能性があると説明されています。

参考: Zcash Documentation: Privacy Recommendations and Best Practices

また、Zcashの用語集では、シールドアドレスと透明アドレスを含む取引では、シールドアドレスに関係するデータだけが保護されると説明されています。

参考: Zcash Documentation: Glossary

ざっくり整理すると、次のようになります。

種類	見え方	注意点
透明アドレス	取引履歴が見えやすい	Bitcoinに近い透明性を持つ
シールドアドレス	取引情報の一部を隠せる	メタデータや使い方によってリンクされる可能性がある
透明・シールド間の移動	入口や出口が見える場合がある	前後の履歴から推定される可能性がある

つまり、Zcashは強力なプライバシー機能を持ちますが、使えば自動的にあらゆる情報が完全に隠れるわけではありません。

7.7 Monero：送信者・受信者・金額を見えにくくする設計

Moneroは、プライバシーを標準で重視する暗号資産として知られています。

Monero公式は、Moneroでは送信者、受信者、金額を隠すために、主に次の技術が使われると説明しています。

技術	ざっくりした役割
ステルスアドレス	受信者ごとに一度きりのアドレスを作り、受信者の公開アドレスと取引を結びつけにくくする
リング署名	実際に使われた出力を、複数の候補の中に紛れ込ませる
RingCT	取引金額を見えにくくする

参考: Monero: What is Monero?
参考: Moneropedia: Stealth Address
参考: Moneropedia: Ring Signature
参考: Moneropedia: Ring CT

ここでも大事なのは、「プライバシー機能があること」と「何があっても絶対に追跡できないこと」は別だという点です。

実際の匿名性は、プロトコルの設計だけでなく、利用状況、過去の仕様、ウォレットや取引所との接点、ネットワーク上の情報などにも影響されます。
そのため、記事では次のように説明するのが安全です。

Moneroは、送信者・受信者・金額を見えにくくする設計を標準で取り入れています。
ただし、どのようなプライバシー技術でも、利用環境や外部情報まで含めて考える必要があります。

7.8 ゼロ知識証明：中身を見せずに正しさを示す

プライバシー技術の中でも、ブロックチェーンで特に注目されるのがゼロ知識証明です。

ゼロ知識証明は、ざっくり言うと、ある主張が正しいことを、その中身を全部見せずに証明する技術です。

Ethereum公式ドキュメントでは、ゼロ知識証明を、主張の内容やそれをどう見つけたかを明かさずに、主張が真であることを証明できる仕組みとして説明しています。

参考: Ethereum.org: Zero-knowledge proofs

身近な例で考えると、次のような場面です。

証明したいこと	本来は見せたくない情報	ゼロ知識証明的な考え方
20歳以上である	生年月日そのもの	年齢条件を満たすことだけ示す
会員資格がある	会員番号や登録情報	会員であることだけ示す
残高が十分ある	正確な残高	支払い条件を満たすことだけ示す
計算が正しい	計算途中の詳細	正しく計算したことだけ示す

ここで注意したいのは、ゼロ知識証明は「何でも自動的に秘密にする魔法」ではないという点です。

どの情報を隠し、どの条件を証明し、どのデータを公開するのかは、システム設計によって変わります。
また、ZK Rollupのように、ゼロ知識証明が「プライバシー」よりも「計算結果の正しさの検証」に使われる場合もあります。

つまり、ZKという言葉が出てきたからといって、必ずしも取引内容が全部秘密になるわけではありません。

7.9 概念コード：見せる情報の粒度で、見え方は変わる

ここでは、プライバシー保護の考え方を、かなり単純化したPythonコードで見てみます。

このコードは、本物のゼロ知識証明や暗号プロトコルを実装するものではありません。
目的は、詳細な取引情報をそのまま公開する場合 と、必要な条件だけを公開する場合 で、外から見える情報がどう変わるかを確認することです。

# このコードは、プライバシー保護の考え方を説明するための簡易モデルです。
# 実際のブロックチェーン、ゼロ知識証明、暗号プロトコルの実装ではありません。

import hashlib
import json


# 本来は公開したくない取引情報を、架空データとして用意します。
# ここでは、送信者・受信者・金額がそのまま含まれています。
private_transaction = {
    "sender": "Alice",
    "receiver": "Bob",
    "amount": 120,
    "asset": "TOKEN",
}


def make_commitment(data):
    """
    非公開データに対応する確認用の値を作ります。

    実際の暗号コミットメントはもっと厳密な性質を持ちますが、
    ここでは説明を簡単にするため、JSON化したデータをハッシュ化しています。
    """
    encoded = json.dumps(data, sort_keys=True).encode("utf-8")
    return hashlib.sha256(encoded).hexdigest()


def make_public_record(private_data, limit):
    """
    公開する情報を最小限にしたレコードを作ります。

    ここでは、正確な金額や送受信者を公開せず、
    「金額が上限以下である」という条件だけを公開しています。
    実際のゼロ知識証明では、この条件が正しいことを暗号学的に検証できるようにします。
    """
    return {
        # commitmentは、非公開データに対応する確認用の値というイメージです。
        "commitment": make_commitment(private_data),

        # 詳細な金額ではなく、条件を満たすかどうかだけを公開します。
        "claim": f"amount <= {limit}",
        "claim_result": private_data["amount"] <= limit,
    }


# 何も工夫せずに公開すると、送信者・受信者・金額がそのまま見えます。
fully_public_record = private_transaction

# 必要な条件だけを公開する場合のレコードを作ります。
privacy_preserving_record = make_public_record(private_transaction, limit=200)

print("詳細をそのまま公開する場合:")
print(json.dumps(fully_public_record, indent=2, ensure_ascii=False))

print("\n必要な条件だけを公開する場合:")
print(json.dumps(privacy_preserving_record, indent=2, ensure_ascii=False))

このコードで見てほしいのは、暗号技術そのものではありません。

大切なのは、公開する情報の粒度です。

• 送信者、受信者、金額をそのまま公開する
• 条件を満たしていることだけを公開する
• 必要な相手にだけ詳細を開示する

このように、設計次第で「見える情報」は変わります。

実際のゼロ知識証明では、上のコードよりはるかに厳密に、条件が正しいことを暗号学的に検証できるようにします。
ただし、初学者向けには、まず 中身を全部見せずに、必要な正しさだけを確認する という感覚を持てれば十分です。

7.10 技術ごとの特徴を整理する

ここまでの内容を、表で整理します。

技術・仕組み	ざっくりした目的	何を分かりにくくするか	注意点
アドレス管理	1つの識別子に履歴を集めすぎない	同じ人・同じ用途の履歴	取引パターンや外部情報で結びつく場合がある
CoinJoin	複数人の取引をまとめる	入力と出力の単純な対応	金額・時間・前後の履歴から推定される場合がある
ミキサー	入金と出金の対応を分かりにくくする	資金の流れ	不正利用リスク、法域差、運営者への信頼が問題になる
Zcashのシールド取引	取引情報の一部を隠す	送受信者や金額など	透明領域との出入りやメタデータに注意が必要
Monero	送信者・受信者・金額を標準で見えにくくする	取引主体や金額	利用環境や外部情報まで含めて考える必要がある
ゼロ知識証明	中身を見せずに正しさを示す	条件の詳細や入力データ	何を隠すかは設計次第であり、万能ではない

この表から分かるように、プライバシー技術はそれぞれ守ろうとしている対象が違います。

「プライバシー技術」と一括りにしても、アドレスの履歴を分ける話、資金の流れを分かりにくくする話、金額を隠す話、正しさだけを証明する話は、それぞれ少しずつ違います。

7.11 プライバシー技術は「良い・悪い」だけでは分けられない

ここまで読むと、プライバシー技術には便利な面と危うい面の両方があることが見えてきます。

プライバシー保護は、個人の安全や自由にとって重要です。
たとえば、寄付、医療、政治的表現、企業間取引、給与、資産管理など、公開されすぎると困る情報はたくさんあります。

一方で、同じ技術が、不正に得た資金の流れを分かりにくくするために使われる可能性もあります。

そのため、記事では次のような単純化を避ける必要があります。

避けたい言い方	より丁寧な言い方
プライバシー技術は悪い	正当なプライバシー保護の目的があるが、不正利用リスクもある
ミキサーはすべて違法	法域や設計、運用、利用実態によって扱いが変わる
ZKを使えば完全匿名	何を隠し、何を証明するかは設計次第である
Moneroなら絶対に追跡できない	プライバシー重視の設計だが、利用環境や外部情報も考える必要がある
アドレスを変えれば安全	履歴や外部情報から結びつく可能性は残る

プライバシー技術を理解するときは、「追跡できるか、できないか」の二択ではなく、次のように見ると整理しやすいです。

• どの情報を隠しているのか
• どの情報は公開されているのか
• どの相手には開示できるのか
• どのような外部情報で結びつくのか
• どのような不正利用リスクがあるのか
• どの法域・事業者ルールが関係するのか

💡 豆知識
「ZK」という名前を見ると、すべての情報が秘密になるように感じるかもしれません。
しかし、ZK Rollupのように、主な目的が「取引内容を全部隠すこと」ではなく、Layer 2で行った状態更新が正しいことを示すこと にある場合もあります。
ZKという言葉を見たときは、何を証明し、何を隠し、何を公開しているのかを分けて確認すると理解しやすくなります。

7.12 この章のまとめ

この章では、ブロックチェーンにおけるプライバシーを高める技術と注意点を整理しました。

公開台帳では、取引履歴を検証しやすい一方で、利用者の行動や資産状況が見えすぎる可能性があります。
そのため、アドレス管理、CoinJoin、ミキサー、プライバシー重視の暗号資産、ゼロ知識証明など、さまざまなプライバシー技術が考えられてきました。

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

• プライバシー保護は「何も見せないこと」だけではない
• アドレス管理は履歴の結びつきを減らす基本的な考え方である
• CoinJoinやミキサーは、入力と出力の対応関係を分かりにくくするが、万能ではない
• ミキサーには正当なプライバシー目的があり得る一方、不正利用リスクや規制上の論点もある
• ZcashやMoneroのようなプライバシー重視の暗号資産でも、設計や利用状況によって見え方は変わる
• ゼロ知識証明は、中身を全部見せずに正しさを示す技術だが、何を隠すかは設計次第である
• プライバシー技術を「良い・悪い」だけで分けず、用途、設計、外部情報、法制度を合わせて考える必要がある

ここまでで、ブロックチェーンの透明性と、それを補うプライバシー技術の両方を見てきました。

次の章では、これらを踏まえて、透明性とプライバシーをどうバランスよく考えるか を整理します。
ブロックチェーンは、透明であればあるほどよいわけでも、完全に見えなければよいわけでもありません。
監査可能性、個人のプライバシー、不正利用対策を分けながら、セキュリティの観点で考えていきます。

8. 透明性とプライバシーをどう考えるか

この章では、ブロックチェーンの透明性とプライバシーを、どちらか一方だけでなく バランス として整理します。
ポイントは、透明性は監査や追跡に役立つ一方で、個人の行動履歴や資産状況が見えすぎるリスクもあるという点です。

前の章では、プライバシーを高める技術と注意点を見ました。

ブロックチェーンは、取引履歴を公開し、第三者が確認できるようにすることで、改ざん検知や監査可能性を高める方向の技術です。
その一方で、公開される情報が多すぎると、利用者の行動履歴や資産状況が必要以上に見えてしまうことがあります。

ここで大切なのは、次のように単純化しないことです。

• 透明性が高いほど、常に良い
• プライバシーを高める技術は、すべて怪しい
• 追跡できるなら、本人特定や不正判断も簡単
• 情報を隠せば、すべての問題が解決する

どれも、少し極端な見方です。

ブロックチェーンの匿名性と追跡可能性を理解するには、何を公開し、何を隠し、誰が、どの目的で確認できるようにするのか を分けて考える必要があります。

Bitcoin.orgも、Bitcoinは多くの人が慣れていないほど高い透明性を持ち、すべての取引が公開・追跡可能・永続的に保存されると説明しています。
同時に、アドレスが使われると、そのアドレスは関係した取引履歴によって「色が付く」ため、プライバシーに注意が必要だとも説明しています。

参考: Bitcoin.org: Protect your privacy

この章では、透明性とプライバシーを対立するものとしてではなく、用途や設計によって調整すべきものとして整理します。

---

8.1 透明性はなぜ役に立つのか

まず、透明性の良い面から見ていきます。

ブロックチェーンの大きな特徴の一つは、記録を第三者が確認しやすいことです。
たとえば、パブリックブロックチェーンでは、取引ID、アドレス、金額、時刻、ブロック番号などをブロックエクスプローラーで確認できる場合があります。

これは、身近な例でいうと、会計帳簿やレシートが後から確認できる状態に近いです。

サークルや研究室の会計で、誰かが「このお金は正しく使いました」と口頭で説明するだけでは、少し不安が残ります。
しかし、入出金記録やレシート、支払い先、日付が残っていれば、あとから確認できます。

ブロックチェーンの透明性も、これに近い役割を持ちます。

透明性が役立つ場面	具体例	何がうれしいか
監査	DAOや寄付金の資金移動を確認する	資金の使われ方を第三者が確認しやすい
不正調査	ハッキング被害後の資金移動を追う	被害資金の移動先を追う手がかりになる
説明責任	プロジェクトのトレジャリーを公開する	関係者に対して資金状況を説明しやすい
検証	スマートコントラクトの状態や取引履歴を見る	「本当に実行されたか」を確認しやすい
研究・分析	ネットワーク全体の利用状況を分析する	技術改善やリスク分析の材料になる

このように、透明性は悪いものではありません。
むしろ、ブロックチェーンが「誰か一社の内部DB」ではなく、複数の参加者が確認できる記録基盤として使われるうえで、とても重要な性質です。

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

透明性が役に立つのは、確認したい人が必要な範囲の情報を確認できる 場合です。
必要以上に細かい情報が、必要以上に広い範囲へ公開されると、今度はプライバシー上の問題になります。

---

8.2 透明性が高すぎると何が困るのか

透明性は便利ですが、すべての情報が常に公開されてよいわけではありません。

たとえば、家計簿を考えてみます。

自分が使うだけなら、家計簿はとても便利です。
毎月の支出、買い物の傾向、食費、交通費、趣味への支出などを整理できます。

しかし、その家計簿が世界中に公開されるとしたらどうでしょうか。

たとえ名前が書かれていなくても、次のようなことが見えてしまうかもしれません。

• よく行く場所
• 利用しているサービス
• 趣味や関心
• 収入や資産の規模
• 生活時間帯
• 交友関係や取引相手

ブロックチェーン上の取引履歴も、これに近い面があります。

本名が直接書かれていなくても、アドレス単位で履歴が積み上がります。
さらに、そのアドレスがSNS、Webサイト、ENS名、取引所、NFT、寄付ページなどの外部情報と結びつくと、見える情報が増える可能性があります。

見える情報	便利な場面	見えすぎると困る場面
取引履歴	資金の流れを確認できる	行動パターンが推測される
残高	資産の存在を確認できる	資産状況が第三者に見える
取引相手	関係するアドレスを調べられる	交友関係や取引関係が推測される
利用サービス	DeFiやNFTの利用実態を分析できる	趣味・関心・投資傾向が見える
時刻	取引の順序やタイミングを確認できる	活動時間帯が推測される

つまり、透明性は「確認できる安心感」を生みます。
一方で、確認できる範囲が広すぎると、「見られすぎる不安」につながります。

このバランスをどう取るかが、ブロックチェーンにおけるプライバシー設計の難しいところです。

---

8.3 透明性とプライバシーは二択ではない

ここで大切なのは、透明性とプライバシーを二択で考えないことです。

たとえば、次のように考えてしまうと、少し極端です。

極端な考え方	なぜ危ないか
すべて公開すれば安全	個人や企業の機密情報まで見えすぎる可能性がある
すべて隠せば安全	監査、説明責任、不正調査が難しくなる
追跡できるならプライバシーは不要	正当な利用者の生活や資産状況も守る必要がある
プライバシー技術はすべて不正目的	個人情報保護、企業秘密、選択的開示など正当な目的もある

実際には、用途によって求められるバランスが変わります。

たとえば、寄付金の使い道を公開する場合、透明性は大きな価値になります。
寄付した人は、自分のお金がどのように使われたのかを確認できます。

一方で、個人の日常的な支払い履歴まで世界中に公開される必要はありません。
コンビニで何を買ったか、どこへ移動したか、どのサービスを使ったかまで見えると、プライバシー上の問題が大きくなります。

また、企業がブロックチェーンを使う場合も、すべてを公開すればよいわけではありません。
サプライチェーンの透明性は大切ですが、取引価格、仕入れ先、在庫量、顧客情報などが過度に見えると、営業秘密や競争上の問題につながる可能性があります。

そのため、ブロックチェーンを設計・利用するときは、次の問いを持つことが大切です。

何を公開する必要があり、何は公開しなくても検証できるのか。

---

8.4 用途によって求めるバランスは変わる

透明性とプライバシーのバランスは、誰が、何のために使うかによって変わります。

同じブロックチェーン技術でも、個人利用、企業利用、DAO、取引所、行政、研究では、必要な公開範囲が異なります。

利用場面	透明性が求められる理由	プライバシー上の注意点
個人の送金	自分の取引が処理されたか確認できる	支払い履歴や資産状況が見えすぎる可能性
DAOの会計	資金の使途を参加者が確認できる	関係者の活動や報酬が過度に見える可能性
寄付・助成金	資金の流れを説明しやすい	受取者や支援対象の情報が見えすぎる可能性
企業間取引	監査証跡や真正性の確認に使える	価格、取引先、在庫など営業秘密が見える可能性
取引所・VASP	AML/CFTや顧客保護に必要	取得する個人情報の管理が重要になる
研究・統計分析	ネットワーク全体の傾向を分析できる	個別ユーザーの再識別に注意が必要

この表から分かるように、「透明であること」と「プライバシーを守ること」は、どちらも必要です。

ただし、必要な透明性の範囲は場面によって違います。
DAOのトレジャリーでは資金移動を公開する価値が高い一方で、個人の医療費支払い履歴や生活支出まで公開する必要はありません。

ここで役に立つ考え方が、データ最小化 です。

データ最小化とは、目的に必要な情報だけを扱い、不要な情報をできるだけ集めない・公開しないようにする考え方です。
NISTのPrivacy Frameworkは、組織が個人のプライバシーを守りながら、プライバシーリスクを特定・管理するための自発的なツールとして説明されています。

参考: NIST: Privacy Framework

ブロックチェーンでも、同じように考えることができます。

• 検証に必要な情報は公開する
• 個人を過度に識別できる情報は公開しない
• 必要な場合だけ、正当な権限を持つ主体が確認できるようにする
• 公開する情報と、オフチェーンで管理する情報を分ける
• 中身を明かさず正しさだけを示す技術を検討する

これらは、透明性を捨てる話ではありません。
むしろ、透明性を社会やシステムにとって役立つ形で使うための工夫です。

---

8.5 設計で調整できるポイント

ブロックチェーンの透明性とプライバシーは、技術設計によってある程度調整できます。

もちろん、どの方式にもメリットと注意点があります。
ここでは、初学者向けに主な選択肢を整理します。

設計の選択肢	ざっくりした考え方	向いている場面	注意点
すべてオンチェーンに記録する	取引やデータをブロックチェーン上に直接置く	公開監査、透明性重視	個人情報や機密情報を載せると消しにくい
ハッシュだけオンチェーンに置く	データ本体は外に置き、改ざん確認用の値だけ載せる	文書の存在証明、監査証跡	元データの保管者や取得方法を別途考える必要がある
オフチェーン処理を使う	詳細データは外部DBや別システムで扱う	個人情報や企業情報を扱う場合	オフチェーン側の管理・監査が重要になる
プライベート / コンソーシアム型を使う	参加者や閲覧者を限定する	企業間取引、業界内共有	パブリックチェーンほど誰でも検証できるわけではない
ゼロ知識証明を使う	中身を明かさず、条件を満たすことを証明する	年齢確認、資格証明、残高条件の証明など	実装が複雑で、設計ミスや運用負荷に注意が必要
選択的開示を使う	必要な相手にだけ必要な情報を見せる	本人確認、資格証明、監査対応	誰に何を開示するかのルール設計が必要

たとえば、年齢確認を考えてみます。

「20歳以上であること」を確認したいだけなら、生年月日、住所、氏名、顔写真、本人確認書類番号まで毎回見せる必要はないかもしれません。
必要なのは、あくまで「20歳以上である」という事実です。

Ethereum公式のゼロ知識証明解説でも、ゼロ知識証明は、主張の中身を明かさずに正しさを証明する方法として説明されています。
また、国籍や年齢などの事実を、機微な個人情報を明かさずに証明する例が紹介されています。

参考: Ethereum.org: Zero-knowledge proofs

このような技術は、ブロックチェーンにおけるプライバシー設計を考えるうえで重要です。

ただし、ここでも注意が必要です。
ゼロ知識証明を使えば、すべてのプライバシー問題が自動的に解決するわけではありません。

何を証明するのか。
何を公開するのか。
どのデータをオフチェーンで管理するのか。
誰が証明を発行し、誰が検証するのか。

こうした設計を間違えると、せっかくの技術も十分に機能しません。

---

8.6 AML/CFTとプライバシーはどう両立するのか

前の章で見たように、AML/CFTでは、不正資金の流れを見つけるために取引情報の確認が重要になります。

一方で、AML/CFTのためなら、どんな情報でも無制限に集めてよい、というわけではありません。
正当な利用者のプライバシーや個人情報保護も重要です。

FATFの勧告では、暗号資産とVASPにAML/CFT要件を適用するためにRecommendation 15が改訂されたことが説明されています。
また、FATF Recommendation 2の改訂では、AML/CFT要件とデータ保護・プライバシールールとの互換性を確保することも説明されています。

参考: FATF: The FATF Recommendations

つまり、AML/CFTとプライバシーは、必ずしも片方を選ぶ関係ではありません。

もちろん、犯罪収益の移転やテロ資金供与を防ぐためには、リスクに応じた確認が必要です。
しかし、その確認は、目的、法令、権限、必要性、情報管理のルールにもとづいて行われるべきです。

初学者向けには、次のように整理すると分かりやすいです。

観点	AML/CFTで必要なこと	プライバシー上の注意点
顧客確認	利用者が誰かを確認する	必要以上の情報を集めすぎない
取引モニタリング	不自然な取引を検知する	自動判定だけで不利益を与えない
疑わしい取引の報告	法令に基づいて当局へ報告する	報告対象や根拠を適切に管理する
Travel Rule	送付人・受取人情報を通知する	情報の安全な送受信と保管が必要
オンチェーン分析	公開履歴からリスクの手がかりを得る	ラベルやクラスタリングを断定として扱わない

ここで大切なのは、リスクを見ること と 人を決めつけること を分けることです。

オンチェーン分析で「この取引は高リスクかもしれない」と分かることはあります。
しかし、それだけで「この人は犯罪者である」と断定するのは危険です。

追加確認、本人確認情報、サービス側のログ、法的手続き、複数情報源の照合などが必要になる場面があります。

透明性はAML/CFTに役立ちます。
ただし、透明性を使う側にも、誤判定や過剰な監視を避ける責任があります。

---

8.7 「公開する情報の粒度」をコードで考える

ここでは、透明性とプライバシーのバランスを、簡単なPythonコードで考えてみます。

このコードは、実際のブロックチェーンやプライバシー技術の実装ではありません。
目的は、同じ取引でも、どの情報を公開するかによって見え方が変わる ことをイメージすることです。

# 透明性とプライバシーのバランスを説明するための簡易モデルです。
# 実際のブロックチェーン、ゼロ知識証明、AMLシステムの実装ではありません。

from pprint import pprint


# 取引の元データを、説明用の辞書として用意します。
# 実際のパブリックブロックチェーンでは、このような「目的」や「本人名」が
# そのままオンチェーンに載るとは限りません。
transaction = {
    "tx_id": "tx_001",
    "from_user": "Alice",
    "to_user": "Bob",
    "from_address": "0xAliceAddress",
    "to_address": "0xBobAddress",
    "amount": 120,
    "purpose": "donation",
    "timestamp": "2026-07-03T10:00:00+09:00",
}


def make_public_record(tx, mode):
    """
    公開する情報の粒度を変えるための関数です。

    modeによって、同じ取引から公開する情報を変えます。
    - full: 説明用に、かなり多くの情報を公開するケース
    - pseudonymous: 実名を出さず、アドレスと金額を公開するケース
    - aggregate: 個別取引ではなく、集計結果だけを公開するケース
    - proof_only: 詳細ではなく、条件を満たしたことだけを示すケース
    """

    if mode == "full":
        # 透明性は高いですが、個人情報や目的まで見えすぎる例です。
        return {
            "tx_id": tx["tx_id"],
            "from_user": tx["from_user"],
            "to_user": tx["to_user"],
            "amount": tx["amount"],
            "purpose": tx["purpose"],
            "timestamp": tx["timestamp"],
        }

    if mode == "pseudonymous":
        # 実名は隠しますが、アドレス単位の履歴は追える例です。
        return {
            "tx_id": tx["tx_id"],
            "from_address": tx["from_address"],
            "to_address": tx["to_address"],
            "amount": tx["amount"],
            "timestamp": tx["timestamp"],
        }

    if mode == "aggregate":
        # 個別取引ではなく、集計値だけを公開する例です。
        # 監査や統計には役立つ一方、個別の資金移動は見えにくくなります。
        return {
            "date": tx["timestamp"].split("T")[0],
            "purpose": tx["purpose"],
            "total_amount": tx["amount"],
            "tx_count": 1,
        }

    if mode == "proof_only":
        # 詳細情報を出さず、「条件を満たした」という結果だけを示す例です。
        # 本物のゼロ知識証明ではありませんが、考え方の入口として扱います。
        return {
            "statement": "この取引は、承認済みの寄付ルールを満たしています",
            "verified": True,
        }

    raise ValueError("unknown mode")


# 公開粒度を変えて、同じ取引がどう見えるかを比較します。
for mode in ["full", "pseudonymous", "aggregate", "proof_only"]:
    print(f"\n--- mode: {mode} ---")
    pprint(make_public_record(transaction, mode))

このコードでは、同じ取引でも、公開する情報の粒度を変えています。

full は、透明性が高い一方で、個人名や目的まで見えすぎる例です。
pseudonymous は、実名を出さずにアドレスと取引内容を公開する例です。
aggregate は、個別取引ではなく集計値を公開する例です。
proof_only は、詳細を出さずに「条件を満たしている」ことだけを示す例です。

もちろん、実際のブロックチェーンでは、ここまで単純ではありません。
本物のゼロ知識証明、選択的開示、アクセス制御、オフチェーン管理、監査ログなどを組み合わせて設計する必要があります。

ただし、この簡易コードから分かる大事なポイントがあります。

透明性とプライバシーのバランスは、「公開するか、隠すか」の二択ではなく、「どの粒度で、誰に、何を見せるか」の設計問題です。

---

8.8 「公開しない」と「検証できない」は同じではない

ここまでの話を読むと、「プライバシーを守るには情報を隠すしかない」と感じるかもしれません。

しかし、ブロックチェーンや暗号技術の面白いところは、中身をすべて公開しなくても、正しさを検証する方法を設計できる場合がある ことです。

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

やりたいこと	全部公開する方法	プライバシーを意識した方法
年齢確認	生年月日や本人確認書類を見せる	「20歳以上である」ことだけを証明する
残高条件の確認	残高全体を見せる	「必要額以上を持っている」ことだけを証明する
文書の存在証明	文書全文をオンチェーンに載せる	文書のハッシュだけをオンチェーンに載せる
サプライチェーン確認	すべての取引先や価格を公開する	必要な条件を満たした証明だけを公開する
寄付金の監査	全支出明細を完全公開する	集計値と監査証跡を分けて公開する

このような設計では、透明性を完全に捨てるわけではありません。
むしろ、検証に必要な情報だけを公開し、必要以上の情報は守る ことを目指します。

ただし、これも万能ではありません。

公開情報を減らすほど、第三者が独立に検証できる範囲は狭くなる場合があります。
逆に、検証可能性を高めるほど、公開情報が増える場合もあります。

そのため、最終的には次の問いに戻ります。

• 何を検証したいのか
• 誰が検証するのか
• どの情報は公開してよいのか
• どの情報は守るべきなのか
• 公開しない情報を、どのように信頼・監査するのか

この問いを立てることが、ブロックチェーンの設計や利用判断ではとても大切です。

---

💡 豆知識
ブロックチェーンは、過去の記録をあとからこっそり書き換えにくくすることを目指す仕組みです。
これは監査や改ざん検知には役立ちますが、個人名、住所、メールアドレス、本人確認書類の画像などを直接載せてしまうと、あとから消したくなったときに大きな問題になります。
そのため、個人情報を直接オンチェーンに載せない、ハッシュだけを残す、オフチェーンで管理する、ゼロ知識証明で条件だけを示す、といった設計が重要になります。

8.9 この章のまとめ

この章では、ブロックチェーンの透明性とプライバシーをどう考えるかを整理しました。

透明性は、監査、不正調査、説明責任、検証可能性を支える重要な性質です。
一方で、透明性が高すぎると、個人の行動履歴、資産状況、取引相手、利用サービスなどが見えすぎる可能性があります。

そのため、透明性とプライバシーは、どちらか一方を選ぶものではありません。

大切なのは、次のような問いを持つことです。

• 何を公開する必要があるのか
• 何は公開しなくても検証できるのか
• 誰が、どの目的で、どこまで確認できるべきか
• 個人情報や機密情報をオンチェーンに載せすぎていないか
• 透明性を高めることで、誰かに過度な不利益が出ないか

ブロックチェーンの透明性は強力です。
しかし、強力だからこそ、何を見せるかを慎重に設計する必要があります。

次の章では、ここまでの内容を踏まえて、ブロックチェーンの匿名性と追跡可能性についてよくある誤解を整理します。
「完全匿名」「すべて追跡できる」「ZKなら全部秘密」といった短い表現を、より正確な言い方へ置き換えていきます。

---

9. よくある誤解

この章では、ブロックチェーンの匿名性と追跡可能性について、よくある誤解を整理します。
ポイントは、短い言葉で説明されたときに省略されやすい前提を確認することです。

前の章では、透明性とプライバシーを二択ではなく、用途に応じて調整するものとして整理しました。
ブロックチェーンでは、取引履歴が公開されることによって監査や不正検知に役立つ場面があります。
一方で、履歴が見えすぎると、個人や組織の行動が必要以上に推測されるリスクもあります。

ここまで読むと、ブロックチェーンは単純に「匿名な技術」とも「すべて追跡できる技術」とも言えないことが見えてきたと思います。

しかし、ニュースやSNS、技術紹介の記事では、どうしても短い表現が使われます。

たとえば、次のような表現です。

• ブロックチェーンは匿名である
• アドレスを見れば誰か分かる
• 取引履歴が公開されるならプライバシーはない
• ミキサーを使えば追跡できない
• ZKを使えば全部秘密になる
• 追跡できるならAML/CFTは簡単である

どれも、入口としては分かりやすい言い方かもしれません。
ただし、そのまま受け取ると、ブロックチェーンの性質を強く単純化しすぎてしまいます。

この章では、ここまでの内容を復習しながら、よくある誤解を一つずつ言い換えていきます。

9.1 まずは一覧で整理する

最初に、よくある誤解と、より正確な見方を一覧で確認します。

よくある言い方	より正確な見方
ブロックチェーンは完全匿名である	多くのパブリックブロックチェーンでは、実名ではなくアドレスが使われるため、完全匿名というより仮名性に近い
アドレスを見れば本人が分かる	アドレスだけで本人を断定できるとは限らない。外部情報と結びつくと、主体を推定できる場合がある
取引履歴が公開されるならプライバシーはない	公開される情報の範囲、設計、運用、プライバシー技術によって見え方は変わる
追跡できるならAML/CFTは簡単	オンチェーン分析は有用な手がかりだが、外部情報、事業者の確認、法的手続き、誤判定への注意が必要
ミキサーを使えば完全に追跡できなくなる	完全匿名を保証するものではなく、不正利用リスクや規制上の論点も大きい
ZKを使えばすべて秘密になる	ゼロ知識証明は中身を明かさず正しさを示す技術だが、何を隠し、何を公開するかは設計によって変わる
透明性とプライバシーはどちらかを選ぶしかない	用途に応じて、公開する情報、検証方法、アクセス権限、保存場所を調整できる

この表で大切なのは、どちらか一方に決めつけないことです。

ブロックチェーンは「完全匿名な闇の技術」でも、「すべてを簡単に追跡できる監視技術」でもありません。
実際には、アドレス、取引履歴、外部情報、分析手法、プライバシー技術、規制対応が組み合わさって、見え方が変わります。

この図のように、ブロックチェーンの匿名性や追跡可能性を理解するときは、まず強い断定を疑い、どこまでが観察で、どこからが推定なのかを分けることが大切です。

9.2 誤解1：ブロックチェーンは完全匿名である

最初の誤解は、ブロックチェーンは完全匿名である、というものです。

たしかに、BitcoinやEthereumのようなパブリックブロックチェーンでは、取引履歴に本名がそのまま書かれるわけではありません。
送信元や送信先として見えるのは、多くの場合、0x... のようなアドレスや、英数字の長い識別子です。

そのため、初めて見ると「名前が出ないなら匿名なのでは」と感じやすいです。

ただし、ここで大切なのは、名前が直接見えないことと、履歴を追えないことは違うという点です。

Bitcoin.orgは、Bitcoinの取引は公開され、追跡可能で、Bitcoinネットワーク上に永続的に保存されると説明しています。
また、Bitcoinアドレスは取引上で使われる唯一の情報ではあるものの、利用者の身元が一度でもアドレスと結びつくと、そのアドレスに関係する履歴が見えてしまう可能性があるとも説明されています。

参考: Bitcoin.org: Protect your privacy

つまり、より正確には次のように整理できます。

観点	説明
実名	多くの場合、オンチェーンに直接は出ない
アドレス	取引上の識別子として見える
取引履歴	パブリックチェーンでは公開される場合がある
本人との結びつき	外部情報がないと分からないことが多いが、結びつく場合がある

そのため、記事内では次のように表現するのが安全です。

ブロックチェーンは、完全匿名というより、実名ではなくアドレスで行動する仮名性に近い性質を持つ場合があります。

「完全匿名」と書くと、履歴が見えることや、外部情報と結びつく可能性を見落としてしまいます。
一方で、「匿名ではない」とだけ書くと、本名が直接出ない仕組みであることが伝わりにくくなります。

ここでは、完全匿名ではなく、仮名性に近いという表現が、初学者向けには一番バランスがよいと思います。

9.3 誤解2：アドレスを見れば本人が分かる

次の誤解は、アドレスを見れば本人が分かる、というものです。

これは、1つ目の誤解とは逆方向の行き過ぎです。

たしかに、ブロックチェーン上ではアドレスの履歴を追える場合があります。
また、SNSで公開されたアドレス、公式サイトに掲載された寄付アドレス、取引所の管理アドレス、公的機関のリストなどと結びつけば、アドレスの意味が見えてくる場合があります。

しかし、アドレスだけを見て、すぐに「この人だ」と断定するのは危険です。

たとえば、次のようなケースがあります。

ケース	なぜ断定できないか
1人が複数アドレスを使う	どのアドレスが同じ人のものかは推定になることがある
取引所やサービスの管理アドレス	多数の利用者の資産や取引が混ざる場合がある
共同管理ウォレット	複数人や組織が関係する場合がある
古いラベル情報	以前は正しくても、現在も同じとは限らない
第三者が掲載したアドレス	掲載者の誤りやなりすましの可能性がある

4章で整理したように、ブロックチェーン分析では、観察・推定・断定を分けることが大切です。

この流れを見ると、アドレスを見るだけで本人が分かるわけではないことが分かります。

より正確には、次のように表現できます。

アドレスは、本人名そのものではありません。  
ただし、外部情報と結びつくと、そのアドレスが特定のサービス、組織、人物と関係している可能性を推定できる場合があります。

この「可能性を推定できる場合がある」という柔らかさが大切です。

9.4 誤解3：取引履歴が公開されるなら、プライバシーはない

3つ目の誤解は、取引履歴が公開されるなら、プライバシーはない、というものです。

たしかに、取引履歴が公開されるパブリックブロックチェーンでは、プライバシー上の課題があります。
誰でもアドレスの残高や取引履歴を確認できる場合、その履歴が外部情報と結びつくことで、行動や資産の流れを推測される可能性があります。

ただし、「公開される情報がある」ことと、「プライバシーがまったくない」ことは同じではありません。

プライバシーは、次のような設計や運用によって変わります。

観点	プライバシーに関係する理由
何をオンチェーンに載せるか	個人情報や詳細な取引目的を直接載せるとリスクが高まる
アドレスをどう使うか	同じアドレスに履歴を集めると、行動パターンが見えやすくなる
外部情報をどう公開するか	SNSやWebサイトでアドレスを公開すると、履歴と結びつきやすい
どの情報を証明するか	中身を全部見せずに、条件だけを証明する設計も考えられる
誰がデータにアクセスできるか	全公開、限定公開、事業者管理などで見え方が変わる

NIST Privacy Frameworkは、プライバシーを単なる秘密保持ではなく、組織が管理すべきプライバシーリスクとして捉えるための枠組みを提供しています。
ブロックチェーンでも、どの情報を公開し、どの情報を隠し、どの情報を誰が確認できるようにするかを考えることが大切です。

参考: NIST: Privacy Framework

より正確には、次のように整理できます。

パブリックブロックチェーンでは、取引履歴が見えることによるプライバシー課題があります。  
ただし、公開する情報の粒度、外部情報との結びつき、プライバシー技術、運用設計によって、見え方は変わります。

つまり、「公開されるなら終わり」ではなく、何が、誰に、どの程度見えるのかを分けて考える必要があります。

9.5 誤解4：追跡できるならAML/CFTは簡単である

4つ目の誤解は、ブロックチェーンでは取引履歴を追跡できるのだから、AML/CFTは簡単である、というものです。

これは、ブロックチェーンの透明性を過大評価した見方です。

たしかに、オンチェーン分析はAML/CFTに役立つ場合があります。
取引の流れ、アドレス同士のつながり、既知の高リスクアドレスとの接点、不自然な分割送金などは、追加確認のきっかけになります。

しかし、AML/CFTは、単に取引グラフを見るだけで完結するものではありません。

FATFは、暗号資産やVASPに関して、リスクベース・アプローチ、顧客管理、記録保存、疑わしい取引の報告、送付人・受取人情報の取り扱いなど、幅広い対応を求めています。
つまり、オンチェーン分析は重要な材料ですが、それだけでAML/CFT全体が完結するわけではありません。

参考: FATF: Virtual Assets
参考: FATF: Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs

AML/CFTで必要になる情報や判断は、次のように分かれます。

種類	例	オンチェーンだけで分かるか
取引の流れ	AアドレスからBアドレスへ送金された	分かる場合がある
アドレスのラベル	取引所、ミキサー、制裁対象など	外部情報が必要になることが多い
顧客本人情報	氏名、住所、本人確認書類など	通常オンチェーンだけでは分からない
取引目的	投資、決済、寄付、移転、事業利用など	オンチェーンだけでは判断しにくい
疑わしい取引かどうか	リスク評価、追加確認、報告判断	事業者の確認や法令対応が必要

そのため、より正確には次のように表現できます。

オンチェーン分析は、AML/CFTにおける強力な手がかりになります。  
ただし、本人確認、取引目的、外部ラベル、法令上の報告判断などは、オンチェーン情報だけでは完結しません。

ここでも、分析結果を「犯人特定」や「犯罪関与の証明」として短絡的に扱わないことが重要です。

9.6 誤解5：ミキサーを使えば完全に追跡できなくなる

5つ目の誤解は、ミキサーを使えば完全に追跡できなくなる、というものです。

ミキサーは、複数の利用者の資金を混ぜることで、入金と出金の対応関係を分かりにくくする仕組みです。
プライバシー保護の文脈で紹介されることもあります。

ただし、ミキサーは「完全匿名を保証する魔法」ではありません。

Bitcoin.orgは、ミキシングサービスについて、プライバシー上の効果がある一方で、サービス提供者を信頼する必要があること、ログを保持される可能性、法域によって合法性が異なる可能性などを説明しています。

参考: Bitcoin.org: Protect your privacy

また、ミキサーは不正利用リスクや規制上の論点も大きい領域です。
前章までで触れたように、Tornado Cashのような事例では、プライバシー技術と不正資金移転対策のバランスが大きな論点になりました。

ここで大切なのは、次の2つを同時に見ることです。

観点	説明
プライバシー保護	取引の対応関係を見えにくくし、利用者の金融プライバシーを守る目的がある
不正利用リスク	盗難資金や制裁対象資金の移動を分かりにくくするために悪用される可能性がある

したがって、記事では次のように表現するのが安全です。

ミキサーは、入金と出金の対応関係を分かりにくくする技術・サービスです。  
ただし、完全匿名を保証するものではなく、不正利用リスクや規制上の論点も大きいため、仕組みと注意点を分けて理解する必要があります。

この章ではあくまで誤解の整理に留めます。
具体的な利用手順や追跡回避の方法には踏み込みません。

9.7 誤解6：ZKを使えばすべて秘密になる

6つ目の誤解は、ZKを使えばすべて秘密になる、というものです。

ZKは、Zero-Knowledgeの略で、日本語ではゼロ知識と訳されます。
ゼロ知識証明は、ざっくり言えば、中身を明かさずに、ある主張が正しいことを証明する技術です。

Ethereum公式ドキュメントでも、ゼロ知識証明は、ある主張が真であることを、その主張自体の詳細を明かさずに証明する方法として説明されています。
また、パブリックブロックチェーン上の取引匿名化にも応用されると説明されています。

参考: Ethereum.org: Zero-knowledge proofs
参考: Ethereum.org: Privacy on Ethereum

ただし、ZKを使えば何でも自動的に秘密になるわけではありません。

大切なのは、何を証明し、何を公開し、何を隠す設計になっているかです。

ZKで考えるポイント	例
証明したいこと	送金額が残高以下である、年齢が条件を満たす、計算結果が正しいなど
隠したいこと	実際の残高、正確な年齢、取引の詳細など
公開されること	証明結果、コミットメント、必要なメタデータなど
残る注意点	実装ミス、メタデータ、利用パターン、外部情報との結びつきなど

つまり、ZKは「全部を隠す箱」ではありません。
むしろ、見せる情報と見せない情報を設計するための強力な道具として理解する方が自然です。

より正確には、次のように表現できます。

ゼロ知識証明は、中身をすべて公開せずに正しさを示すための技術です。  
ただし、何が隠され、何が公開されるかは、具体的なプロトコルや実装設計によって変わります。

これは、Layer 2の記事で扱ったZK Rollupにも通じる考え方です。
ZKという名前が付いていても、すべての情報が秘密になるとは限りません。

9.8 誤解7：透明性とプライバシーはどちらかを選ぶしかない

7つ目の誤解は、透明性を取るならプライバシーを諦めるしかない、またはプライバシーを取るなら検証可能性を諦めるしかない、というものです。

もちろん、透明性とプライバシーには緊張関係があります。
すべての情報を公開すれば監査はしやすくなりますが、個人や組織の機微な情報まで見えてしまう可能性があります。
逆に、すべてを隠してしまうと、第三者が正しさを確認しにくくなります。

しかし、選択肢は二択だけではありません。

たとえば、次のような設計が考えられます。

設計の方向	例
全体は公開するが個人情報は載せない	アドレスと取引だけを公開し、実名はオンチェーンに載せない
条件だけを証明する	年齢そのものではなく、20歳以上であることだけを証明する
一部の情報だけを公開する	取引の存在や検証結果は公開し、詳細は限定的に扱う
アクセス権限を分ける	利用者、監査者、規制当局、一般公開で見える範囲を変える
オフチェーンとオンチェーンを分ける	個人情報はオフチェーンで管理し、オンチェーンには確認用の値だけを置く

8章で整理したように、透明性とプライバシーは「どちらが正しいか」ではなく、用途に応じてバランスを設計するものです。

より正確には、次のように表現できます。

透明性とプライバシーは、必ずしも片方を選んだら片方を捨てる関係ではありません。  
どの情報を公開し、どの情報を隠し、誰がどの範囲で確認できるようにするかを設計することが重要です。

9.9 概念コード：強すぎる表現を見つけて言い換える

ここまで、よくある誤解を表や文章で整理してきました。

最後に、記事を書くときや調査メモを作るときに、強すぎる表現を見つけるための簡単なPythonコードを見てみます。

このコードは、自然言語を正確に理解するAIではありません。
ただし、完全、必ず、絶対、すべて のような言葉が含まれる文を見つけ、注意して読み直すための学習用ツールとしては使えます。

# これは記事作成時に「強すぎる断定表現」を見つけるための学習用コードです。
# 実際の文章校正AIや法的判断ツールではありません。
# 目的は、ブロックチェーンの匿名性・追跡可能性を説明するときに、
# 「完全」「必ず」「絶対」などの表現を不用意に使っていないか確認することです。

# 確認したい文章の例を用意します。
# あえて強すぎる表現を含む文も入れています。
statements = [
    "ブロックチェーンは完全匿名である。",
    "アドレスを見れば必ず本人を特定できる。",
    "Bitcoinの取引は公開され、追跡可能な場合がある。",
    "ゼロ知識証明を使えばすべての情報が秘密になる。",
    "オンチェーン分析はAML/CFTに役立つ手がかりになる。",
]

# 強すぎる断定になりやすい語を定義します。
# ここにある語が必ず悪いわけではありませんが、使う場合は根拠と範囲を確認します。
strong_words = ["完全", "必ず", "絶対", "すべて", "誰でも", "不可能"]

# 各文章について、強い表現が含まれるか確認します。
for sentence in statements:
    # 文の中に strong_words のどれかが含まれているかを調べます。
    matched_words = [word for word in strong_words if word in sentence]

    # 強い表現が見つかった場合は、読み直し対象として表示します。
    if matched_words:
        print("要確認:", sentence)
        print("  含まれる強い表現:", ", ".join(matched_words))
        print("  -> 根拠、例外、条件を確認して、必要なら表現を弱めます。")
    else:
        print("比較的慎重な表現:", sentence)

このコードのポイントは、文章の正誤を自動判定することではありません。

大切なのは、強い言葉を見つけたときに、次のように立ち止まることです。

確認したい問い	例
どのブロックチェーンについて言っているのか	Bitcoinなのか、Ethereumなのか、プライベートチェーンなのか
どの時点の情報か	仕様や規制は変わっていないか
どの範囲で正しいのか	一般論なのか、特定条件の話なのか
例外はないか	取引所アドレス、複数人管理、プライバシー技術など
根拠はあるか	公式ドキュメント、標準化団体、信頼できる研究資料など

たとえば、次のように言い換えるだけで、かなり安全な表現になります。

強すぎる表現	言い換え例
ブロックチェーンは完全匿名である	多くのパブリックブロックチェーンでは、実名ではなくアドレスで取引するため、仮名性に近い性質がある
アドレスを見れば必ず本人が分かる	アドレスが外部情報と結びつくと、主体を推定できる場合がある
ミキサーを使えば追跡できない	ミキサーは対応関係を分かりにくくするが、完全匿名を保証するものではない
ZKなら全部秘密になる	ZKは中身を明かさず正しさを示せるが、何が隠れるかは設計による
追跡できるのでAMLは簡単	オンチェーン分析は有用だが、AML/CFTには本人確認、外部情報、法令上の判断も必要

このような言い換えを意識すると、記事全体の技術表現がかなり安定します。

9.10 よくある誤解を見抜くためのチェックリスト

ここまでの内容を、最後にチェックリストとしてまとめます。

ブロックチェーンの匿名性や追跡可能性について説明を読むときは、次の点を確認すると理解しやすくなります。

チェック項目	確認したいこと
完全・必ず・絶対という表現がないか	強すぎる断定になっていないか
実名とアドレスを分けているか	アドレスは本人名そのものではない
観察・推定・断定を分けているか	取引履歴の観察と本人特定を混同していないか
外部情報の根拠を確認しているか	ラベルや公的リストの情報源・更新時期を見ているか
プライバシー技術を魔法のように扱っていないか	仕組み、限界、不正利用リスクを分けているか
AML/CFTを単純化していないか	オンチェーン分析だけでなく、本人確認や法令対応も見ているか
透明性とプライバシーを二択にしていないか	公開粒度や検証方法を設計する余地を見ているか

このチェックリストは、この記事だけでなく、今後ブロックチェーン関連の記事やニュースを読むときにも使えます。

💡 豆知識
「匿名」と「仮名」は似ていますが、日常生活でも少し違います。
名前を書かないアンケートは匿名に近い一方、SNSのニックネームは本名でなくても、投稿履歴や交友関係が積み上がります。
ブロックチェーンアドレスも同じように、本名ではなくても履歴が公開され、外部情報と結びつくことで意味を持つ場合があります。

9.11 この章のまとめ

この章では、ブロックチェーンの匿名性と追跡可能性について、よくある誤解を整理しました。

特に重要なのは、次の点です。

• ブロックチェーンは、完全匿名というより仮名性に近い場合が多い
• アドレスだけで本人を断定できるわけではない
• 取引履歴が公開されることと、プライバシーがまったくないことは同じではない
• オンチェーン分析はAML/CFTに役立つが、それだけで判断が完結するわけではない
• ミキサーやプライバシー技術は完全匿名を保証する魔法ではない
• ZKは強力な技術だが、何が隠れるかは設計による
• 透明性とプライバシーは、用途に応じてバランスを考える必要がある

ここまでで、匿名性、仮名性、透明性、追跡可能性、外部情報、AML/CFT、プライバシー技術、よくある誤解までを整理してきました。

次の章では、最近の動向を確認します。
暗号資産のAML/CFT、ミキサーをめぐる法執行、ゼロ知識証明などのプライバシー技術は、制度・技術・社会的な見方が変わりやすい領域です。
そのため、記事の最後に入る前に、どのような方向で議論が進んでいるのかをざっくり確認します。

---

10. 最近の動向

この章では、ブロックチェーンの匿名性と追跡可能性をめぐる最近の動向を整理します。
ポイントは、オンチェーン分析、AML/CFT、プライバシー技術、法執行の動きが、それぞれ別々ではなく関係しながら進んでいることです。

前の章では、ブロックチェーンの匿名性と追跡可能性について、よくある誤解を整理しました。

ここまで見てきたように、ブロックチェーンは「完全匿名」でも「何でも自動で本人特定できる仕組み」でもありません。
実名ではなくアドレスで取引する仮名性、取引履歴が公開される透明性、外部情報と結びついたときの追跡可能性、そしてプライバシー保護の必要性が重なっています。

この領域は、技術だけでなく、規制、法執行、金融機関の実務、利用者保護とも関係します。
そのため、2026年時点でも動きが続いており、記事を投稿する直前にも一次情報を確認した方がよいテーマです。

本章では、最近の動向を次の4つに分けて整理します。

観点	最近の見方	なぜ重要か
AML/CFT	VASP、Travel Rule、ステーブルコイン、不正利用リスクへの対応が続いている	取引所やサービス提供者の運用に直結するため
プライバシー技術	ゼロ知識証明など、必要な情報を隠しつつ検証する技術が注目されている	透明性とプライバシーを両立する選択肢になるため
ミキサー・法執行	プライバシー保護と不正利用対策の境界が議論されている	技術そのものと悪用リスクを分けて考える必要があるため
利用者保護	アドレス履歴や外部ラベルの扱いに慎重さが求められる	誤ったラベル付けや過剰な可視化が不利益につながる可能性があるため

10.1 AML/CFTでは、VASPとTravel Ruleが引き続き重要になる

暗号資産のAML/CFTでは、VASP、つまり暗号資産サービス提供者の登録・監督、本人確認、疑わしい取引報告、Travel Ruleなどが引き続き重要な論点です。

FATFは、2025年6月にVirtual AssetsとVASPに関する基準実装の第6回Targeted Updateを公表し、VASPの登録・監督、Travel Rule、ステーブルコインの不正利用リスクなどを引き続き課題として整理しています。

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

ここで重要なのは、ブロックチェーン上の履歴だけでAML/CFTが完結するわけではないことです。

オンチェーン分析は、資金の流れやリスクの高いアドレスとの関係を見るうえで役立ちます。
しかし、本人確認、送付人・受取人情報、取引目的、顧客属性、法令上の判断は、ブロックチェーン外の情報や事業者の運用と組み合わせて考える必要があります。

つまり、AML/CFTの文脈では、追跡可能性を「犯人を一発で特定する魔法」として見るのではなく、リスク評価や追加確認のための材料として見るのが自然です。

10.2 プライバシー技術は、透明性を否定するためだけのものではない

一方で、公開台帳の透明性が高まるほど、利用者のプライバシーも課題になります。

たとえば、給与、寄付、取引先、NFTの購入、DeFiの利用履歴などがアドレス単位で見え続けると、本人が意図しない形で行動履歴が分析される可能性があります。
これは、単なる「隠したいから隠す」という話ではなく、個人や組織の安全にも関係します。

この文脈で注目される技術の一つが、ゼロ知識証明です。

Ethereum公式は、ゼロ知識証明を、ある主張が正しいことを、その主張の中身を明かさずに証明する方法として説明しています。

参考: Ethereum.org: Zero-knowledge proofs

この考え方は、公開台帳と相性がよい場面があります。

たとえば、すべての取引内容や個人情報を公開するのではなく、「条件を満たしていること」だけを証明できれば、プライバシーを守りながら検証可能性を保てる可能性があります。

ただし、ゼロ知識証明を使えば自動的にすべてが秘密になるわけではありません。
何を隠し、何を公開し、どの相手に何を証明するのかは、設計によって変わります。

10.3 ミキサーをめぐる議論は、技術と悪用リスクを分けて見る必要がある

ミキサーやプライバシー強化サービスは、プライバシー保護に使われる可能性がある一方、不正資金の流れを分かりにくくする目的で悪用されるリスクもあります。

この領域では、技術そのもの、利用者のプライバシー、法執行、制裁、開発者責任などが絡み合います。

たとえば、Tornado Cashについては、米国財務省が2025年3月に経済制裁を解除したと公表しています。
ただし、同じ発表の中で、北朝鮮などによる悪意あるサイバー活動やデジタル資産の悪用への懸念は引き続き示されています。

参考: U.S. Department of the Treasury: Tornado Cash Delisting

この事例から分かるのは、次の点です。

プライバシー技術を扱うときは、「技術としての役割」と「不正利用リスク」と「法制度上の扱い」を分けて見る必要があります。

そのため、本記事ではミキサーやプライバシー強化技術について、具体的な追跡回避手順としては扱いません。
あくまで、公開台帳の世界でプライバシーをどう考えるか、そして不正利用リスクをどう見ればよいかという観点で整理します。

10.4 最近の動向を分類してみる

ここで、最近の動向を簡単な分類として見てみます。

以下のコードは、ニュースや公式資料を自動で判定するものではありません。
あくまで、匿名性・追跡可能性に関する動向を読むときに、どの観点の話なのかを整理するための学習用サンプルです。

# 匿名性・追跡可能性に関する動向を整理するための簡易分類です。
# 実際のリスク評価や法的判断を行うものではありません。

topics = [
    {
        "topic": "FATFによるVirtual Assets / VASP基準の更新",
        "category": "AML/CFT",
        "check_points": ["VASPの監督", "Travel Rule", "ステーブルコインの不正利用リスク"],
    },
    {
        "topic": "ゼロ知識証明を使ったプライバシー保護",
        "category": "privacy_technology",
        "check_points": ["何を隠すか", "何を証明するか", "検証者に何が見えるか"],
    },
    {
        "topic": "ミキサーをめぐる制裁・法執行上の議論",
        "category": "enforcement_policy",
        "check_points": ["正当なプライバシー保護", "不正利用リスク", "法域ごとの扱い"],
    },
    {
        "topic": "ブロックエクスプローラーや分析サービスのラベル",
        "category": "onchain_analysis",
        "check_points": ["情報源", "更新時期", "推定と断定の区別"],
    },
]

for item in topics:
    print(f"\n論点: {item['topic']}")
    print(f"分類: {item['category']}")
    print("確認したいこと:")
    for point in item["check_points"]:
        print(f"- {point}")

このコードで大切なのは、話題を一つの軸だけで見ないことです。

たとえば、ミキサーの話題は、プライバシー技術の話でもあり、AML/CFTの話でもあり、法執行の話でもあります。
ゼロ知識証明も、暗号技術の話であると同時に、公開しすぎない設計やコンプライアンスとの両立に関係します。

💡 豆知識
プライバシーは「何も見せないこと」だけではありません。
個人にとっては給与や購買履歴を必要以上に知られないこと、企業にとっては取引先や事業計画を不用意に公開しないことが重要になる場合があります。
一方で、金融犯罪対策では必要な範囲で本人確認や取引モニタリングも求められるため、誰に、何を、どこまで見せるのかを設計する視点が大切です。

10.5 最近の動向から見えること

最近の動向を整理すると、ブロックチェーンの匿名性と追跡可能性は、次の方向へ進んでいると考えられます。

方向性	内容
追跡・監督の高度化	AML/CFT、Travel Rule、オンチェーン分析、制裁対応が進む
プライバシー保護の必要性	公開台帳上で利用者情報が見えすぎるリスクが意識される
技術と制度の組み合わせ	ゼロ知識証明などの技術と、本人確認・監査・法制度を組み合わせる方向
断定しすぎない分析	ラベル付けやクラスタリングには推定が含まれるため、根拠確認が重要になる

このように見ると、ブロックチェーンの匿名性と追跡可能性は、単なる技術論ではありません。
プライバシー、コンプライアンス、法執行、利用者保護をどう両立するかという、かなり実務的なテーマでもあります。

10.6 この章のまとめ

この章では、ブロックチェーンの匿名性と追跡可能性をめぐる最近の動向を整理しました。

FATFの更新から分かるように、暗号資産のAML/CFTでは、VASP、Travel Rule、ステーブルコイン、不正利用リスクへの対応が引き続き重要です。
一方で、公開台帳の透明性が高いほど、利用者の行動履歴が見えすぎるというプライバシー課題も強くなります。

ゼロ知識証明のような技術は、必要な情報をすべて公開しなくても、正しさを検証できる可能性を持ちます。
ただし、何が隠れ、何が証明されるかは設計によって変わるため、魔法のように扱うのは危険です。

また、ミキサーやプライバシー強化技術をめぐる議論では、正当なプライバシー保護と不正利用リスクの両方を見る必要があります。

次の章では、記事全体を振り返りながら、ブロックチェーンの匿名性と追跡可能性をどのように理解すればよいかをまとめます。
最後に、派生元記事である「身近な記録から理解するブロックチェーンの全体像」とのつながりも整理します。

---

11. まとめ

最後に、本記事で見てきたブロックチェーンの匿名性と追跡可能性を振り返ります。
細かい分析手法や個別事例を覚える前に、まずは 「何が見えて、何が推定で、どこから先は外部情報や追加確認が必要なのか」 という視点を持つことが大切です。

この記事では、スマホ決済の履歴、銀行口座の入出金履歴、交通系ICカードの乗車履歴、SNSの投稿履歴のような身近な記録から出発して、ブロックチェーンの匿名性と追跡可能性を整理しました。

最初に見た身近な履歴の例では、本名が直接表示されていなくても、同じ識別子に行動履歴が積み重なることで、利用パターンや行動の流れが見えてくる場合がありました。

ブロックチェーンでも、これに近いことが起こります。

多くのパブリックブロックチェーンでは、取引に本名がそのまま書かれるわけではありません。
そのため、ぱっと見ただけでは「誰の取引なのか」は分かりにくいです。

一方で、アドレス、取引履歴、送金額、時刻、スマートコントラクトとのやり取りなどが公開される場合があります。
その履歴をたどることで、資金の流れやアドレス間の関係を分析できることがあります。

Bitcoin.orgでも、Bitcoin取引は公開・追跡可能・永続的に保存されるため、すべての人が任意のBitcoinアドレスの残高や取引を確認できると説明されています。

参考: Bitcoin.org: Protect your privacy

つまり、ブロックチェーンの匿名性を理解するときは、次のように見るのが大切です。

名前が見えないことと、履歴を追えないことは同じではありません。
また、履歴を追えることと、本人を必ず特定できることも同じではありません。

この2つを分けて考えるだけで、「ブロックチェーンは完全匿名なのか」「取引は全部追跡できるのか」という問いを、かなり落ち着いて整理できるようになります。

---

11.1 本記事で整理したこと

本記事では、ブロックチェーンの匿名性と追跡可能性を、次の流れで整理しました。

最初は、スマホ決済や交通系ICカードのような身近な履歴から入りました。
そこから、ブロックチェーン上のアドレス、公開された取引履歴、ブロックエクスプローラー、取引グラフ、外部ラベル、AML/CFT、プライバシー技術へと話を広げました。

この流れで一貫して大切にしたのは、見える情報と見えない情報を分けることです。

ブロックチェーン上に見えている情報だけで分かることもあります。
一方で、本人確認情報、取引所の記録、SNSで公開されたアドレス、公的機関のリスト、調査資料など、外部情報と結びついて初めて見えてくることもあります。

そして、外部情報と結びついたとしても、分析結果には推定が含まれる場合があります。

そのため、技術的な分析を行うときほど、次の3つを分ける姿勢が重要になります。

段階	意味	例
観察	ブロックチェーン上で直接確認できること	あるアドレスから別のアドレスへ送金された
推定	履歴やパターンから可能性として考えられること	複数アドレスが同じ主体に関係しているかもしれない
断定	十分な根拠をもとに言えること	本人確認済みの情報や正式な調査結果と照合できた

この区別を忘れると、ブロックチェーン分析は危うくなります。

「同じような動きだから同一人物だ」と決めつけたり、「高リスクとされるアドレスと近いから犯罪関与だ」と断定したりすると、誤った判断につながる可能性があります。

オンチェーン分析は便利ですが、それだけで世界のすべてが分かるわけではありません。
あくまで、追加確認やリスク評価のための手がかりとして扱うことが大切です。

---

11.2 透明性とプライバシーを二択にしない

ブロックチェーンの透明性は、情報セキュリティの観点では大きな強みにもなります。

たとえば、取引履歴が公開されていれば、第三者が記録を確認し、不自然な資金移動やスマートコントラクトの動きを分析できる場合があります。
これは、監査、インシデント調査、AML/CFT、利用者保護の観点で役立ちます。

FATFも、暗号資産やVASPに関するAML/CFT対応として、リスクベース・アプローチ、顧客管理、記録保存、疑わしい取引報告、Travel Ruleなどを重視しています。

参考: FATF: Virtual Assets
参考: FATF: Targeted Update on Implementation of FATF Standards on Virtual Assets and Virtual Asset Service Providers

一方で、透明性が高いほど、利用者の行動履歴が見えやすくなるという課題もあります。

たとえば、あるアドレスが給与、寄付、NFT購入、DeFi利用、送金先などと結びつくと、その人や組織の活動が必要以上に見えてしまう可能性があります。
これは、単なる技術の問題ではなく、プライバシーリスクの問題でもあります。

NIST Privacy Frameworkでは、プライバシーを組織が管理すべきリスクとして捉え、データ処理によって個人にどのような影響が生じるかを考える枠組みを示しています。

参考: NIST Privacy Framework

そのため、ブロックチェーンの透明性は、単純に「良い」か「悪い」かで決めるものではありません。

大切なのは、用途に応じて、どの情報を公開し、どの情報を隠し、どの情報を必要な相手だけが検証できるようにするかを考えることです。

プライバシー技術も、「追跡を逃れるためのもの」とだけ見ると、かなり狭い理解になってしまいます。

プライバシー技術は、正当な利用者の行動履歴を必要以上に公開しないためにも重要です。
たとえば、寄付先、給与、購買履歴、取引先、組織の資金移動などがすべて公開されると、個人や企業にとって大きなリスクになる場合があります。

一方で、ミキサーや一部のプライバシー強化技術は、不正資金の移動を分かりにくくする目的で悪用されることもあります。
そのため、プライバシー保護とAML/CFTの両方を考える必要があります。

Ethereum公式は、ゼロ知識証明を、ある主張が正しいことを、その主張の中身を明かさずに証明する方法として説明しています。

参考: Ethereum.org: Zero-knowledge proofs

この考え方は、公開台帳の世界でとても重要です。

すべてを公開しなければ検証できない、というわけではありません。
設計によっては、必要な情報を隠しながら、正しさだけを検証できる可能性があります。

もちろん、ゼロ知識証明を使えば何でも完全匿名になる、というわけではありません。
何を隠し、何を証明し、どの情報を公開するのかは、具体的な設計によって変わります。

---

11.3 匿名性と追跡可能性を学ぶときに意識したいこと

ブロックチェーンの匿名性と追跡可能性を学ぶときは、最初から個別事件や高度な分析ツールに入ると、少し迷いやすくなります。

そのため、まずは次の順番で理解すると進めやすいです。

順番	意識したいこと
1	身近な履歴から、名前が見えないことと行動が見えないことの違いを考える
2	アドレスが実名ではなく、履歴を持つ識別子であることを理解する
3	公開台帳では、取引履歴をあとから確認できる場合があることを見る
4	追跡で分かることと、分からないことを分ける
5	外部情報と結びついたときに、アドレスの意味が変わることを理解する
6	AML/CFTでは、オンチェーン分析を手がかりとして使うことを確認する
7	プライバシー技術は、正当なプライバシー保護と不正利用リスクの両方から見る
8	透明性とプライバシーを二択にせず、用途に応じて公開粒度を考える

特に大切なのは、見える範囲 と 言える範囲 を分けることです。

ブロックチェーン上で見えている情報は、取引時刻、送金額、アドレス、スマートコントラクトとのやり取りなどです。
しかし、その取引の意図、本人性、犯罪関与、法的な評価までは、オンチェーン情報だけで断定できるとは限りません。

そのため、ニュースや分析レポートを読むときも、次の問いを持つと理解しやすくなります。

• それはブロックチェーン上で直接観察できる情報なのか
• 外部情報と照合した結果なのか
• 分析手法による推定なのか
• 公的機関や事業者の確認に基づく情報なのか
• どの時点の情報で、今も同じ状態なのか
• プライバシー保護とAML/CFTのどちらの文脈で語られているのか

この問いを持つことで、匿名性と追跡可能性を、過大評価も過小評価もしにくくなります。

ブロックチェーン分析についても、次のような姿勢が大切です。

• 取引履歴が見えることと、本人を断定できることを分ける
• アドレスのラベルやクラスタリング結果を、根拠なく断定しない
• オンチェーン情報とオフチェーン情報を分けて考える
• AML/CFTの文脈では、分析結果を追加確認の手がかりとして扱う
• プライバシー技術を、正当な保護と不正利用リスクの両面から見る
• 技術、制度、運用のどこで何を支えているのかを確認する

ブロックチェーンの匿名性と追跡可能性は、「安全か危険か」の二択で見るものではありません。

何がオンチェーンで見えて、何が外部情報に依存し、どこから先が推定なのか。

この問いを持つことで、匿名性と追跡可能性をより正確に理解しやすくなります。

---

11.4 今後深掘りしたいテーマ

本記事では、ブロックチェーンの匿名性と追跡可能性の全体像を初学者向けに整理しました。
ただし、このテーマはかなり広く、この記事だけでは扱いきれない論点も多くあります。

今後さらに理解を深めるなら、次のようなテーマを順番に学ぶとよさそうです。

テーマ	深掘りすると分かること
アドレスクラスタリング	複数のアドレスが同一主体に関係している可能性をどう推定するか
UTXOモデルとアカウントモデル	Bitcoin系とEthereum系で追跡の見方がどう変わるか
ブロックエクスプローラーの読み方	取引、イベントログ、トークン移転、コントラクト呼び出しをどう確認するか
オンチェーン分析とAML/CFT	分析結果をリスク評価や追加確認にどうつなげるか
プライバシーコイン	透明性の高いチェーンと比べて、どの情報を隠す設計なのか
ゼロ知識証明	内容を明かさずに正しさを証明する考え方
Travel Rule	VASP間で送付人・受取人情報を扱う制度的な背景
データ保護・プライバシーリスク	公開台帳の透明性が個人や組織に与える影響

特に、暗号資産に関する規制、AML/CFT、プライバシー技術、分析ツールは変化が大きい領域です。
そのため、記事公開後も、Bitcoin.org、Ethereum公式、FATF、金融庁、NISTなどの一次情報・公的資料を確認しながら学ぶ姿勢が大切です。

---

11.5 最後に

ブロックチェーンの匿名性と追跡可能性は、最初は少しつかみにくいテーマです。

「匿名」「仮名性」「透明性」「オンチェーン分析」「AML/CFT」「プライバシー技術」「ゼロ知識証明」など、似ているようで役割の違う言葉が一気に出てくるため、学び始めの段階では混乱しやすいと思います。

しかし、最初の入口としては、すべての技術や制度を一気に覚える必要はありません。

まずは、次の一文を押さえておくと十分です。

ブロックチェーンは、完全匿名でも、何でも自動的に本人特定できる仕組みでもありません。
実名が直接見えない仮名性、履歴を確認できる透明性、外部情報と結びついたときの追跡可能性、そしてプライバシー保護の必要性を分けて考えることが大切です。

この考え方を持っておくと、ブロックチェーンを「なんとなく匿名で危ない技術」と見るのではなく、公開された記録をどう活かし、どこにプライバシー上の注意があるのかを、少し落ち着いて考えられるようになります。

これからブロックチェーンや暗号資産、オンチェーン分析を学ぶうえでは、「見える情報」「推定できる情報」「追加確認が必要な情報」を分けて考えることが重要になります。

匿名性と追跡可能性は、その視点を身につけるためのよい題材です。

この記事が、ブロックチェーンの匿名性と追跡可能性を学び始めるためのきっかけになればうれしいです。