試験の概要と形式
CCAS（Certified Cryptoasset AFC Specialist）は、クリプトアセットやデジタル資産に関連する金融犯罪リスク、AML/CFTコントロール、リスク評価、規制対応に関する能力を扱うACAMSの専門資格です。このガイドは、コンプライアンス、調査、リスク管理などに携わる実務者の学習を支援します。
現行プログラムについてACAMSが公表している試験形式は100問・175分で、試験は現在英語のみと案内されています。本ガイドは日本語での独立した学習資料であり、日本語受験が可能という意味ではありません。受験予約、費用、言語、運用ルールは申込前にACAMSへ確認してください。
バージョンに関する注意：2026年10月11日時点で、ACAMSは2026年11月19日から改訂版のCCAS教材・コース・試験を提供すると告知しています。現行プログラムの学習範囲を土台にしつつ、改訂後の試験形式や出題構成を先取りして断定していません。受験時期に合わせて最新情報をご確認ください。
このガイドの使い方
- まず取引の仕組みを理解する：オンチェーンの観察から、すぐに犯罪や制裁違反を断定しないための基礎を固めます。
- 次に基準と法域を分ける：FATFの国際基準と、具体的な義務を定める各法域の法令・規則を混同しないようにします。
- 最後に証拠を統合する：オンチェーン情報と顧客・取引の背景を照合し、リスクに応じた調査や管理策を選びます。
試験情報はACAMSのCCAS公式ページでご確認ください。
学習範囲と優先順位
| 公式学習領域 | 主な対象範囲 | このガイドでの学習優先事項 |
|---|---|---|
| クリプトアセットとブロックチェーン | ブロックチェーン取引、ウォレット、アドレス、取引所、ステーブルコイン、DeFi、NFT、スマートコントラクト、カストディ、オンチェーンでの価値移動 | AML上の結論を出す前に、取引の仕組みとデータの限界を見極める |
| クリプトアセット・ブロックチェーンのAML基礎 | FATF基準、VASPの役割、Travel Rule、制裁、前提犯罪、法域ごとの規制差 | 基準、国内法、事業者の役割、個別の取引事実を切り分ける |
| クリプトアセット・ブロックチェーンのリスク管理プログラム | リスク評価、顧客受入れ、ウォレット審査、分析、モニタリング、調査、疑わしい取引の報告、ガバナンス、記録、コントロール検証 | オンチェーン・オフチェーン情報を統合し、リスクに見合う対応を選ぶ |
押さえておきたい60の概念 1–10
1. ブロックチェーンは共有台帳である
クリプトアセットとブロックチェーン
ブロックチェーンは、参加者が取引記録を共有し、所定の合意手続で更新する台帳です。公開型チェーンでは記録を広く閲覧できる場合がありますが、台帳に見えるのはアドレスや取引データであり、実際の人物や取引目的が自動的に分かるわけではありません。
実務例: 調査担当者は、顧客の入金が記録された時刻と金額を確認し、台帳の記録だけでは送金者の身元を確定できない点も報告に明記します。
よくある誤解: 公開台帳の記録を見られることと、取引当事者が特定できることは別です。透明性を本人確認済みの情報と取り違えないようにします。
2. 取引、アドレス、利用者を区別する
クリプトアセットとブロックチェーン
取引は、資産移転やスマートコントラクトの呼び出しなど、チェーン上の処理を指示するデータです。アドレスは支払先やアカウントなどを識別する情報であり、人の身元を表すものではありません。ひとりの利用者が複数アドレスを使うことも、複数人がサービスを通じて同じアドレスに関係することもあります。処理内容と利用者への帰属は、それぞれの根拠に基づいて判断します。
実務例: 顧客のEthereum取引について、ETHの送金額がゼロでも、トークンの使用許可を設定する取引であることを確認しました。担当者は操作内容と手数料を確認し、そのアドレスを顧客本人に結び付ける根拠を別途記録します。
よくある誤解: 送金表示がないことを「操作がない」と理解したり、アドレスをそのまま利用者本人とみなしたりするのは誤りです。処理内容と帰属情報は分けて確認します。
3. UTXOモデルの基本
クリプトアセットとブロックチェーン
UTXO型のチェーンでは、取引の入力に指定した未使用の取引出力（UTXO）を丸ごと消費し、新たな出力を作成します。通常の支払いでは、受取人への出力に加えて、送金者へのお釣り出力が作られることがあります。通常のBitcoin取引では、入力合計と出力合計の差が取引手数料になります。入力・出力の構造を把握してから、誰にいくら支払ったかを解釈します。
実務例: Bitcoinで、1 BTCの入力に対して0.3 BTCと0.6999 BTCの出力がある取引を確認しました。担当者は差額の0.0001 BTCを手数料として把握し、二つの出力を別々の相手への支払いと決めつけず、どちらがお釣りかを判断する根拠を確認します。
よくある誤解: 複数の入力が同じ取引に使われたことだけで、同一所有者だと断定できません。CoinJoinのように複数の参加者が共同で取引を作る場合もあるため、入力の共通管理は取引形式を踏まえた推定として扱います。
4. アカウント型台帳の読み方
クリプトアセットとブロックチェーン
アカウント型のチェーンでは、アドレスごとの残高と状態変化を記録し、取引によってそれらを更新します。スマートコントラクトの実行が同じ取引に含まれることもあります。表示された送金額だけでなく、取引の実行内容や関連イベントを確認することが重要です。
実務例: 顧客の取引履歴にトークン移転が表示されたため、担当者は取引詳細を開き、契約の実行による交換なのか単純な送金なのかを調べます。
よくある誤解: 画面上の取引一覧だけで、すべての価値移動や契約動作が理解できるとは限りません。チェーン上の記録と利用サービスの説明を照合します。
5. 秘密鍵とウォレットの役割
クリプトアセットとブロックチェーン
秘密鍵は、取引の承認などに使う電子署名を作成するための暗号鍵です。通常の鍵管理型アドレスでは対応する鍵による署名が操作権限に関わりますが、スマートコントラクト型のアカウントはコードで定めた条件に従います。ウォレットは鍵管理や取引の作成・署名などを支援する仕組みであり、資産の記録自体はチェーン上にあります。
実務例: 顧客が複数の署名を要するスマートコントラクト型ウォレットを利用している場合、調査担当者は承認条件と署名者を確認します。アプリを操作する人だけで送金を承認できるとは想定せず、実際の権限分担を記録します。
よくある誤解: すべてのアドレスに一つの秘密鍵が直接対応するわけではありません。アプリの利用者、署名者、操作を承認できる主体を同一視せず、実際の承認条件を確認します。
6. カストディ型とセルフカストディ型
クリプトアセットとブロックチェーン
カストディ型サービスでは、事業者が顧客に代わって秘密鍵や資産の管理に関与します。セルフカストディ型では、利用者自身が鍵を管理する形が一般的です。ただし、製品の実態は一様ではありません。誰が鍵を管理し、誰が送金を承認できるかを確認して役割を判断します。
実務例: 顧客が外部ウォレットへの送金を申告したとき、事業者は送金先の管理者や顧客との関係を、適用される手順に沿って確認します。
よくある誤解: 「セルフカストディ」という呼称だけで法的扱いやリスクを決めつけることはできません。具体的な機能と適用法域を確認します。
7. 取引所の機能と事業者の役割
クリプトアセットとブロックチェーン
取引所は売買の仲介、顧客資産の保管、送金処理など、複数の機能を提供する場合があります。AML上の評価では、サービス名だけでなく、実際に何を行い、誰のために行い、どの法域で事業をしているかを確かめます。機能ごとに適用される規制上の役割が異なることがあります。
実務例: あるアプリが暗号資産の交換と保管の両方を提供している場合、コンプライアンス担当者は各機能の流れと関係する事業体を個別に整理します。
よくある誤解: 「取引所」という名称だけで、すべての機能や法的義務が同じだと決めつけないようにします。
8. 確認回数と取引の確定性
クリプトアセットとブロックチェーン
取引が台帳に取り込まれた後も、チェーンの仕組みによっては追加の確認が積み重なることで、記録が覆る可能性が小さくなります。確認数の意味や確定性の考え方はチェーンごとに異なります。調査では、観察時点と利用したチェーンの仕組みを記録します。
実務例: 入金直後のアラートを調べる担当者は、取引がどの状態にあるかを確認し、未確定の情報と確定後の情報を分けて記録します。
よくある誤解: すべてのチェーンに共通する確認回数や確定基準があるわけではありません。特定のチェーンの慣行を一般化しないことが大切です。
9. 仮名性と身元特定の限界
クリプトアセットとブロックチェーン
多くの公開型チェーンでは、取引は実名ではなくアドレスを通じて記録されます。このため、取引履歴が公開されていても、実際の利用者の身元は別の情報なしには判明しない場合があります。顧客確認情報、サービス記録、取引の文脈を組み合わせて、帰属の根拠を評価します。
実務例: 分析担当者がアドレスの過去履歴を確認して高リスクの接点を見つけた場合、顧客本人との関係をKYC情報や入出金記録で確かめます。
よくある誤解: 仮名性は完全な匿名性を意味せず、公開台帳も自動的な本人確認を意味しません。両方の限界を踏まえて判断します。
10. 資金追跡における経路とホップ
クリプトアセットとブロックチェーン
追跡でいうホップは、取引グラフ上で資金が移動した段階を示す便宜的な表現です。経路が長くなると追加の解釈が必要になることがありますが、信頼度が機械的に一定割合で下がるわけではありません。サービスの構造、取引の直接性、分析手法を踏まえて接続の意味を説明します。
実務例: 顧客入金が過去に高リスクと評価された先と複数段階でつながるとき、担当者は直接関係と間接関係を分けて追加確認の必要性を判断します。
よくある誤解: 「何ホップ離れているか」だけで制裁適用や顧客リスクを決めるのは不適切です。経路の性質と他の事実を見ます。
押さえておきたい60の概念 11–20
11. アドレスのクラスタリングは推定である
クリプトアセットとブロックチェーン
分析では、共通の取引パターンなどを手掛かりに複数アドレスを同一主体の管理下にあると推定することがあります。これは有用な分析手法ですが、チェーンや取引形式、サービスの実装に左右されます。クラスタの根拠、適用条件、例外を理解し、確定事実と推定を区別します。
実務例: ツールが複数アドレスを同じサービスに関連付けた場合、調査担当者はその根拠と既知のサービス運用を確認してから報告に用います。
よくある誤解: クラスタ表示は法的な所有者情報ではありません。分析上の推定を、そのまま本人や事業者の確定的な帰属として書かないようにします。
12. ブロックチェーン分析の限界を理解する
クリプトアセットとブロックチェーン
分析ツールは取引経路の可視化や既知のサービスとの照合に役立ちますが、入力データ、ラベルの品質、チェーンの対応範囲に依存します。ツールの出力は判断材料であり、顧客の身元、取引目的、犯罪の成立を単独で証明するものではありません。重要な所見は根拠と不確実性を確認します。
実務例: ツールがアドレスを不正市場に関連付けたと表示した場合、担当者はラベルの情報源と時点を調べ、顧客の説明や取引経路と照合します。
よくある誤解: 分析ツールの結果を無条件に正確と扱うのは誤りです。ツールの限界を理解し、必要に応じて別の情報で裏付けます。
13. ステーブルコインの価値と発行の仕組み
クリプトアセットとブロックチェーン
ステーブルコインは、法定通貨などの価値への連動を目指すデジタル資産です。発行、償還、準備資産、凍結機能、流通経路は商品ごとに異なります。名称や価値連動の目標だけでリスクを評価せず、誰が発行・管理し、どのチェーンやサービスで流通するかを確認します。
実務例: 顧客が複数チェーン上で同じ銘柄のトークンを受け取った場合、事業者は発行体と流通ネットワーク、交換経路をそれぞれ特定します。
よくある誤解: 価値が安定していることは、資金源や取引相手のリスクが低いことを意味しません。個別の商品と利用状況を評価します。
14. ブリッジによるチェーン間移動
クリプトアセットとブロックチェーン
ブリッジは、異なるブロックチェーン間で資産やその表現を移すための仕組みです。ロックと発行、バーンと解放など、実装によって価値の移動方法は異なります。追跡では、送信元と送信先の取引を対応付け、ブリッジの仕組みや関連する事業者も考慮します。
実務例: 顧客の送金がブリッジを通過した後に別チェーンで出金された場合、調査担当者は両側の記録と対応関係を確認します。
よくある誤解: 片方のチェーンだけを調べて、資金が消えた、または別人に移ったと結論付けてはいけません。ブリッジを介した移動を追います。
15. DeFiとスマートコントラクトの動作
クリプトアセットとブロックチェーン
DeFiサービスでは、スマートコントラクトが交換、貸付、担保管理などの処理を実行することがあります。利用者のウォレットと契約アドレスの間に複数の処理が起きるため、単純な送金として解釈できない場合があります。実際の呼び出し内容、資産の流れ、関与する管理主体を確認します。
実務例: 顧客の取引が高リスクとラベル付けされた契約に触れた場合、担当者はスワップや貸付などの処理内容と、資金がその後どこへ移ったかを調べます。
よくある誤解: 契約アドレスのラベルだけで、顧客の行為や意図を断定することはできません。取引メカニズムと顧客の文脈を確認します。
16. 分散型取引所（DEX）の交換経路
クリプトアセットとブロックチェーン
分散型取引所（DEX）では、スマートコントラクトを利用して資産を交換する仕組みが一般的です。自動マーケットメーカー（AMM）型では、流動性プールから交換相手の資産が払い出され、ルーターが複数のプールを経由させることもあります。注文板型など別の方式もあるため、画面の名称ではなく、実際の交換方式と経路を確認します。
実務例: 顧客のスワップが二つの流動性プールを経由していた場合、調査担当者は入力資産、中間資産、受取資産を対応付けます。プールのアドレスをそのまま顧客の実際の売買相手の身元とみなさず、DEXの交換処理として資金の流れを説明します。
よくある誤解: DEXの一回の交換で複数のアドレスやトークン移転が現れても、それだけで資金の隠蔽を示すわけではありません。また、AMM型の動作をすべてのDEXに当てはめることもできません。交換方式と実際の経路を確認します。
17. ミキシング機能とプライバシー
クリプトアセットとブロックチェーン
ミキシングやプライバシー強化の仕組みは、資金の経路と元の取引との結び付きを追いにくくすることがあります。一方、プライバシーを重視する理由は一様ではありません。利用状況、資金源、取引規模、顧客の説明、その他の兆候を合わせて評価し、単一の接点を不正行為の証明にしないことが重要です。
実務例: 顧客の送金がミキシング機能に関連した場合、担当者は経路と顧客の取引目的を調べ、疑念が残る場合には所定の内部手続に沿って対応します。
よくある誤解: ミキサーとの接点だけで資金洗浄と断定したり、顧客関係を自動的に終了したりするのは適切ではありません。文脈に基づいて判断します。
18. NFTの所有と取引を分けて見る
クリプトアセットとブロックチェーン
NFT（非代替性トークン）は、同一種類の他のトークンと一律に置き換えられることを前提としないトークンです。一般的なNFT規格では、チェーン、コントラクトアドレス、トークンIDの組合せで個々のトークンを識別します。トークンの保有・移転と、関連コンテンツの著作権や利用権は別であり、どの権利が移るかは関連する契約や適用法に基づいて確認します。
実務例: 同じNFTが短期間に高値で売買され、売り手と買い手のアドレスに関連が疑われる場合、担当者は決済記録、入手可能な顧客情報、資金源を照合します。関連があるように見えることだけで仮装売買と断定せず、売買の経済的合理性と当事者の関係を確認します。
よくある誤解: NFTの移転記録だけで、作品の著作権や実際の市場価値まで確認できたとは限りません。記録の意味を分けて扱います。
19. ネイティブ資産とトークン
クリプトアセットとブロックチェーン
ネイティブ資産は特定チェーンの基盤機能と結び付く一方、トークンはそのチェーン上の規格や契約を通じて発行されることがあります。同じような名称の資産でも、チェーンや契約が異なる場合があります。送金先を確認するときは、銘柄名だけでなくネットワークとトークン識別情報を確認します。
実務例: 顧客が同一銘柄名のトークンを別ネットワークへ送ったとき、運用担当者は両方のネットワーク記録と事業者の対応状況を照合します。
よくある誤解: 銘柄名が一致すれば同一資産・同一経路だと思い込むのは危険です。チェーンや契約の違いを確認します。
20. オンチェーンとオフチェーンの活動
クリプトアセットとブロックチェーン
オンチェーン活動はブロックチェーンに記録される操作を指し、オフチェーン活動には取引所内部の帳簿処理や顧客との連絡などが含まれます。オフチェーンの売買は個別の公開チェーン取引として見えない場合があります。全体像を把握するには、事業者の記録と台帳情報を組み合わせます。
実務例: 顧客が取引所内で複数回売買した後に一度だけ出金した場合、担当者は公開台帳だけでなく取引所の内部履歴も確認します。
よくある誤解: ブロックチェーン上の記録だけで顧客の全取引が分かるとは限りません。サービス内部の記録が必要な場面を見落とさないようにします。
押さえておきたい60の概念 21–30
21. FATF基準と国内法を区別する
クリプトアセット・ブロックチェーンのAML基礎
FATFはマネーロンダリング対策などの国際基準を示しますが、その基準がそのまま各国の事業者に適用される法律になるわけではありません。具体的な義務は各法域の法令・規則や監督上の枠組みによって定まります。基準上の期待と、対象組織に適用される法的義務を区別します。
実務例: 国際基準に基づく社内方針を確認するとき、担当者は自社が営業する法域の実施規則を別途調べ、必要な手順を対応付けます。
よくある誤解: 「FATFが求めるから、世界中で同じ法的義務がある」と考えるのは誤りです。法域と国内実装を確認します。
22. VASP該当性は機能から検討する
クリプトアセット・ブロックチェーンのAML基礎
FATFのVASP定義では、他者のために業として行う仮想資産の交換、移転、保管・管理などの対象機能に着目します。ただし、FATF上の分類がそのまま国内法上の登録・免許義務を決めるわけではありません。名称だけでなく、実際のサービス、顧客との関係、資産移転への関与を整理し、対象法域の定義に照らして判断します。
実務例: 秘密鍵を保有しない会社が、顧客から交換注文を継続的に受け、提携先への取次ぎと決済の手配を行っています。担当者は「技術会社」という名称だけで対象外とせず、契約と取引フローから各機能を整理して、法域別の該当性を検討します。
よくある誤解: 「ソフトウェア会社だから対象外」とも、「暗号資産関連ソフトウェアを提供するから必ずVASP」とも判断できません。単なる技術提供と、業として対象サービスを提供する行為を区別します。
23. 事業者の役割と規制上の責任
クリプトアセット・ブロックチェーンのAML基礎
同じ取引に複数の事業者が関与しても、各社の役割や顧客との関係は同じとは限りません。送金を指示する主体、保管を行う主体、仲介する主体を特定し、どの義務がどの組織にかかるかを適用法域に照らして整理します。取引の見た目だけで責任を推定しないことが重要です。
実務例: 顧客の送金に複数のサービスが関わるとき、担当者は自社が実行した機能と委託先の役割を契約・運用記録から確認します。
よくある誤解: 取引に名前が表示された組織が、すべての規制責任を負うとは限りません。実際の役割と法的枠組みを見ます。
24. Travel Ruleの目的と適用差
クリプトアセット・ブロックチェーンのAML基礎
Travel Ruleは、対象となる資産移転について、必要な送金人・受取人情報を取得・保持し、関係する事業者に安全に伝達することで、移転の透明性と追跡可能性を支える枠組みです。送付側・受領側などの役割に応じて対応を整理します。対象取引、情報項目、閾値、伝達の時期や方法は、適用法域の実施規則に従って確認します。
実務例: Travel Ruleの対象となる出金を処理する事業者の担当者が、必要な顧客情報と受取人情報を確認し、相手方VASPを特定して安全な伝達経路を確認します。情報に不備があれば、適用法令と社内手続に従って補完やエスカレーションを行います。
よくある誤解: 世界共通の一律な閾値や実装方法があるわけではありません。また、情報の伝達が必要だからといって、顧客の個人情報を公開ブロックチェーンに記録しなければならないわけでもありません。
25. セルフカストディ先への送金を個別に評価する
クリプトアセット・ブロックチェーンのAML基礎
セルフカストディ型ウォレットへの送金では、受取人が顧客本人か第三者か、送金目的は何か、どの情報取得や確認が必要かを、適用法令とリスクに照らして整理します。相手方VASPがいなくても、自社側の情報取得・保存などの義務がなくなるとは限りません。アドレスの操作権限を確認する方法と、受取人の身元を確認する方法は区別します。
実務例: 顧客が本人管理のウォレットへの出金を申請し、そのウォレットはメッセージ署名に対応しています。社内手続で署名による確認を行う場合、担当者は署名を操作権限の裏付けとして扱い、顧客情報や送金目的も照合します。署名だけで受取人の身元や資金の適法性が確認できたとは判断しません。
よくある誤解: セルフカストディ先への送金をすべて禁止する普遍的なルールはありません。一方、相手方VASPがいないことを理由に、必要な情報取得やリスク評価を省略してよいわけでもありません。
26. 法域差を判断の前提に置く
クリプトアセット・ブロックチェーンのAML基礎
暗号資産規制、報告義務、制裁の実施方法は国や地域で異なり、国際的な事業者には複数の制度が関係する場合があります。まず顧客、事業体、取引、サービスの所在地と適用規則を特定し、どのルールが関係するかを整理します。法域が不明なまま細かな法的結論を出さないことが大切です。
実務例: 複数国の顧客を受け入れるサービスは、各市場で適用される顧客確認・報告の要件を整理し、手順を整合させます。
よくある誤解: ある国の閾値や報告期限を世界共通のルールとして扱ってはいけません。判断に必要な法域を先に特定します。
27. リスクベース・アプローチの基本
クリプトアセット・ブロックチェーンのAML基礎
リスクベース・アプローチでは、組織は自らの顧客、商品、地域、取引に伴うリスクを把握し、その大きさや性質に応じて管理策を設計します。全顧客に同じ強度の措置を機械的に適用するのではなく、根拠あるリスク評価と定期的な見直しを通じて資源を配分します。
実務例: 複雑な資金経路が確認された顧客には追加確認を行い、取引が一貫して低リスクと評価される顧客には適用ルール内で相応の手続きを設計します。
よくある誤解: リスクベースとは、規則を任意に省略できるという意味ではありません。必要な法的義務を満たしたうえで、管理策の強度を調整します。
28. 制裁リスクと制裁義務を切り分ける
クリプトアセット・ブロックチェーンのAML基礎
制裁対象との直接的な取引や関係は重大な確認事項になり得ますが、対応義務は適用される制裁制度、法域、関係者の役割、所有・管理の事実によって異なります。アドレス分析の接点だけで法的な結論を出さず、該当する規則と確かな帰属情報を確認し、社内手続に従います。
実務例: 顧客の入金元が制裁対象に関連するとのアラートを受け、担当者は帰属の根拠と直接性を調べ、法務・制裁担当へ所定の手順で相談します。
よくある誤解: すべての制裁制度に同じ凍結・遮断・報告ルールがあるわけではありません。対象法域の制度と事実関係を確認します。
29. OFACの50パーセント所有ルールの範囲
クリプトアセット・ブロックチェーンのAML基礎
米国OFACの50 Percent Ruleでは、資産凍結対象者が直接又は間接に、単独又は合算で50％以上を所有する事業体は、その名称が制裁リストに掲載されていなくても資産凍結対象として扱われます。所有が50％未満で支配のみの場合、このルールだけで自動的に凍結対象になるわけではありませんが、別の指定や禁止規定などは確認が必要です。EU・英国などの所有・支配の基準とは区別します。
実務例: 米国の暗号資産サービス事業者が法人顧客を審査しています。OFACの資産凍結対象者AとBが、それぞれ異なる持分を直接30％と25％所有していると確認されました。担当者は合計55％となるため、法人名がリストにないことだけで審査を通過させず、資産凍結対象としての対応を制裁担当に確認します。
よくある誤解: 各所有者の持分がそれぞれ50％未満でも、合算により対象となる場合があります。また、すべての制裁対象者を資産凍結対象者と同一視したり、OFACの所有基準をEU・英国へそのまま適用したりしてはいけません。
30. 前提犯罪と資金洗浄リスク
クリプトアセット・ブロックチェーンのAML基礎
資金洗浄の調査では、詐欺、窃盗、ランサムウェアなど、違法収益を生み得る前提犯罪を考慮します。暗号資産は犯罪収益の受取りや移転に使われることがありますが、特定の取引パターンだけで前提犯罪を確定することはできません。資金の発生源、移動経路、被害情報などを照合します。
実務例: 顧客の入金が公表された詐欺被害に関連する可能性を示した場合、担当者はアドレスの一致と取引時系列を確認し、追加情報を収集します。
よくある誤解: 疑わしい取引があるだけで、具体的な前提犯罪や顧客の犯罪関与まで証明されたとは限りません。事実と仮説を分けます。
押さえておきたい60の概念 31–40
31. 兆候は犯罪の証明ではない
クリプトアセット・ブロックチェーンのAML基礎
複雑な経路、高頻度の移転、既知の高リスクサービスとの接点などは、追加確認を始める手掛かりになり得ます。しかし、正当な説明が存在する場合もあり、兆候の意味は顧客や取引の状況に左右されます。観察事実、リスク仮説、確認後の判断を分けて記録します。
実務例: 短時間に複数のアドレスへ資産を移した顧客について、担当者は資金の流れと顧客の通常の行動を比べ、説明を確認します。
よくある誤解: レッドフラグを見つけたら犯罪と決めつけるのは誤りです。兆候は調査やレビューの理由であって、結論そのものではありません。
32. 顧客確認と実質的支配者の把握
クリプトアセット・ブロックチェーンのAML基礎
顧客確認では、顧客の身元、事業の実態、必要な所有・支配関係を適用制度に沿って把握します。法人の実質的支配者は、最終的にその法人を所有・支配する自然人など、制度上の定義に該当する者です。代表者と同一とは限らず、中間の法人株主の名称を確認するだけで十分とも限りません。確認方法、例外、特定できない場合の代替措置は、適用法令と手順に従います。
実務例: 法人顧客の株主が持株会社で、その持株会社にも法人株主が存在しています。担当者は登記情報、株主名簿、支配権に関する資料を確認し、適用制度に沿って最終的な自然人の所有・支配関係を調べます。必要な情報が得られない場合は、定められた追加確認やエスカレーションを行います。
よくある誤解: 代表者の本人確認や法人株主の名称確認だけで、実質的支配者の確認が常に完了するわけではありません。また、実質的支配者の判定基準にOFACの50％所有ルールをそのまま転用してはいけません。
33. 顧客デューデリジェンスと追加確認
クリプトアセット・ブロックチェーンのAML基礎
顧客デューデリジェンスは、顧客の身元、関係の目的、取引の見込みなどを把握し、継続的な管理につなげる活動です。リスクや適用ルールに応じて追加情報を求めることがあります。確認の深度は具体的な懸念や取引状況に対応させ、必要な情報と判断根拠を記録します。
実務例: 顧客の取引規模が申告した事業活動と大きく異なる場合、担当者は資金源や取引目的を追加確認し、既存のリスク評価を更新します。
よくある誤解: 高リスクの兆候が一つあれば、常に同じ追加措置を課すという考え方ではありません。懸念と適用ルールに沿って対応を選びます。
34. PEPはリスク要因であって有罪の証明ではない
クリプトアセット・ブロックチェーンのAML基礎
PEPは、重要な公的職務を担う、又は担っていた者を指し、汚職などのリスクを評価するうえで考慮されます。外国PEP、国内PEP、国際機関のPEPや、その家族・密接な関係者の扱いは適用制度により異なります。必要な承認、資金源・資産形成の背景の確認、継続的な監視などを適用法令と社内手順に従って行いますが、PEP該当だけで犯罪関与を認定したり、自動的に拒否したりするものではありません。
実務例: 外国PEPと確認された新規顧客が、長年保有していた暗号資産の売却を希望しています。担当者は、社内規程で求められる経営陣の承認に向けて、保有資産の取得経緯、資産形成の背景、売却目的を裏付ける情報を確認し、必要なモニタリングとともに審査結果を記録します。
よくある誤解: PEPだから自動的に拒否すべきという考えも、犯罪の証拠がないから通常の確認だけでよいという考えも適切ではありません。所定の措置を満たすことと、顧客関係を拒否・終了することは別の判断です。
35. FATFのグレーリストと個別リスク
クリプトアセット・ブロックチェーンのAML基礎
FATFのモニタリング強化対象国・地域、いわゆるグレーリストへの指定は、国レベルのAML/CFT上の課題を評価する情報です。FATFは、この指定だけを理由とする一律の強化デューデリジェンスを求めておらず、取引関係の一律解消を意味するものでもありません。顧客、取引、具体的な国別の課題に基づきリスクに見合った対応を選びます。行動要請の対象となる高リスク国・地域の声明や、国内法上の義務は別途確認します。
実務例: グレーリスト掲載国に居住する顧客が、申告した勤務先から得た収入で暗号資産を購入しています。担当者は、指定の背景、勤務先、資金源、取引経路を確認します。国の指定だけで自動的に拒否せず、個別の懸念があればそれに対応した追加確認や監視を行います。
よくある誤解: グレーリストと、対抗措置や強化デューデリジェンスに関する行動要請の対象を同一視してはいけません。また、グレーリスト指定だけで一律の強化措置が必要になるわけではなくても、適用法令で別途要求される措置は満たす必要があります。
36. 記録保存は判断を再現できるようにする
クリプトアセット・ブロックチェーンのAML基礎
記録は、誰が、どの情報を基に、どの判断をしたかを後から確認できる状態にするために重要です。顧客確認、取引、アラート、調査、承認などの記録について、保存内容や期間、アクセス管理は適用法域と組織のルールに従います。分析結果の時点や根拠も残します。
実務例: 調査担当者はアドレスの帰属ラベルを使った際、情報源、確認日、関連する取引、判断理由をケース記録に記載します。
よくある誤解: スクリーンショットやツールの結論だけを保存すれば十分とは限りません。判断を追跡・再確認できる根拠と文脈も記録します。
37. 疑わしい取引の報告は法域別に行う
クリプトアセット・ブロックチェーンのAML基礎
疑わしい取引の報告基準、提出先、期限、期限の起算点は法域によって異なります。報告に犯罪の証明が必要とは限らず、適用法令の報告基準を満たした場合は、調査の完了を待つことで報告を遅らせないようにします。担当者は観察事実と疑いの根拠を整理して、社内の報告担当者へ適時に上申します。秘密保持や顧客への告知制限は、報告前を含めて該当するルールを確認します。
実務例: 繰り返される入金と直後の出金について、顧客の説明と確認資料に重大な不一致が見つかりました。調査担当者は、確認済みの事実、疑いの理由、未確認事項を報告担当者に速やかに上申します。報告担当者は適用法令の基準と期限を判断し、必要な報告を調査完了まで先延ばしにせず、追加情報の取扱いも所定の手続で検討します。
よくある誤解: レッドフラグが一つあるだけで必ず報告義務が成立するわけではありませんが、犯罪を確証できるまで報告しなくてよいわけでもありません。報告予定や調査内容を顧客に伝えてよいかも、事前に確認が必要です。
38. 国境を越える取引と情報連携
クリプトアセット・ブロックチェーンのAML基礎
暗号資産の取引は複数の国・地域や事業者を経由することがあり、調査・規制対応にも国境を越える情報が関係します。情報共有や当局対応には、適用されるプライバシー、守秘、データ移転、法執行上の手続を考慮します。必要な情報を適切な相手へ、適切な根拠に基づいて連携します。
実務例: 海外事業者が関係する資金移動を調べる際、担当者は社内の法務・プライバシー部門と連携し、適切な情報取得経路を確認します。
よくある誤解: ブロックチェーンが国境を越えているからといって、顧客情報を制約なく共有してよいわけではありません。適用される法的根拠と手続きを確認します。
39. 組織全体のリスク評価
クリプトアセット・ブロックチェーンのリスク管理プログラム
組織のリスク評価では、顧客、商品・サービス、地域、取引経路、提供方法など、事業に関係する要素をまとめて検討します。暗号資産では、チェーンやカストディの形態、外部サービスとの接続も考慮対象になり得ます。評価結果は管理策と資源配分に結び付け、変化に応じて見直します。
実務例: 新しいチェーンとブリッジ対応を追加する前に、チームは顧客層、取引経路、監視可能性、外部事業者への依存を評価します。
よくある誤解: 一つの顧客やアラートだけを見て、組織全体のリスク評価が完了したと考えるのは誤りです。事業全体のリスク要因を確認します。
40. 固有リスクと残存リスク
クリプトアセット・ブロックチェーンのリスク管理プログラム
固有リスクは管理策を考慮する前に存在するリスク、残存リスクは管理策を踏まえた後に残るリスクです。高い固有リスクがあっても、適切な管理で残存リスクが下がる可能性があります。一方、管理策が不十分なら残存リスクは高いままです。両者を区別して評価を記録します。
実務例: 新しいチェーンの対応で固有リスクが上がった場合、チームは監視範囲や顧客確認を検討したうえで、残るリスクを改めて評価します。
よくある誤解: コントロールが存在するだけで残存リスクが低いとは限りません。管理策の適切さと実際の運用を確認します。
押さえておきたい60の概念 41–50
41. 顧客受入れ時のリスク分類
クリプトアセット・ブロックチェーンのリスク管理プログラム
オンボーディングでは、顧客の身元や目的を確認するとともに、予定する商品、取引、資金源、地域などを評価します。初期のリスク分類は、その後の確認やモニタリングの出発点であり、顧客の行動や新しい情報に応じて見直す必要があります。分類の理由を説明できる形で残します。
実務例: 新規顧客が高頻度の国際送金を予定している場合、担当者は申告された事業モデルと想定取引を照合して受入れ時の評価を行います。
よくある誤解: 登録時に付与したリスク分類を永久に固定するのは適切ではありません。取引や顧客情報の変化を受けて再評価します。
42. 資金源と資産形成の背景を確認する
クリプトアセット・ブロックチェーンのリスク管理プログラム
資金源の確認は、特定の資金がどこから来たかを理解することです。資産形成の背景を確認する場合は、顧客が全体としてどのように資産を得たかを把握します。必要な確認の深度は顧客、取引、リスク、適用ルールに応じて決め、申告内容と利用可能な証拠を照合します。
実務例: 顧客の入金額が申告収入と比べて大きい場合、担当者は資金の由来を示す資料を求め、取引の背景と整合するか評価します。
よくある誤解: 口座へ送られた直前のアドレスを確認するだけで、資金源の理解が常に完了するわけではありません。必要な背景の深さを見極めます。
43. ウォレット審査の目的と限界
クリプトアセット・ブロックチェーンのリスク管理プログラム
ウォレット審査は、アドレスや取引履歴を既知のリスク情報と照合し、追加確認が必要な接点を見つける管理策です。適切な設定には、対象チェーン、データ更新、アラート閾値、確認手順が関係します。結果は個別の事実確認へつなげ、単独で顧客の行為を確定しないようにします。制裁関連の警告については、ツールのラベルやリスクスコアと、適用される制裁制度上の該当性・対応義務を区別します。
実務例: 暗号資産交換サービスで、顧客への残高反映前のEthereum上のトークン入金について、分析ツールが移転元アドレスに制裁関連ラベルを表示しました。担当者は実際の移転記録とラベルの出典・更新日を確認し、適用される制裁制度との一致や必要な対応を制裁担当者へ至急確認します。残高反映の可否は、適用法令と承認済み手順に従って判断します。
よくある誤解: ウォレット審査ツールを導入しただけで、制裁・AMLリスクを十分に管理できているとは限りません。設定と運用の両方を検証します。
44. アドレス帰属の確度を記録する
クリプトアセット・ブロックチェーンのリスク管理プログラム
アドレスの帰属情報には、確認済みの情報から分析上の推定まで、さまざまな確度があります。判断ではラベルの出所、確認時点、根拠、取引との関係を見て、確定事実と暫定的な推定を分けて記載します。事業者の保管アドレスへの帰属と、そのサービスを利用する顧客の特定も別の確認事項です。帰属の不確実性が重要な場合は、結論に与える影響も明らかにします。
実務例: Ethereumの出金先が、分析ツールで取引所の保管アドレスと表示されました。顧客は自分名義の取引所口座への送金と説明しています。担当者はラベルの根拠・更新日を記録し、必要に応じて口座情報と送金記録を照合します。取引所への帰属情報だけで、その口座の名義人や顧客による秘密鍵の管理まで確認できたとは扱いません。
よくある誤解: ラベルの表示を確認しただけで帰属が確定したと扱わないようにします。根拠と不確実性を示すことが判断の質を高めます。
45. 取引モニタリングの設計
クリプトアセット・ブロックチェーンのリスク管理プログラム
取引モニタリングは、顧客や取引のリスクに応じて、不自然な活動を検出し、確認につなげる仕組みです。ルールやモデルは、対象商品、取引の性質、利用可能なデータを踏まえて設計します。検出件数だけで有効性を判断せず、見逃しや誤検知、運用上の処理能力も検討します。
実務例: 顧客の通常パターンから大きく外れた入出金を検出するルールを導入し、実際のアラートと調査結果を見て調整します。
よくある誤解: ルールを増やせば自動的に検出力が上がるわけではありません。無関係なアラートが増え、重要な兆候が埋もれる可能性も評価します。
46. 顧客の通常パターンと取引文脈
クリプトアセット・ブロックチェーンのリスク管理プログラム
取引の意味を評価するときは、金額や回数だけでなく、顧客の職業・事業、申告した目的、過去の行動、利用する商品などと比べます。通常のパターンから外れることは確認の手掛かりになりますが、直ちに不正を意味しません。変化の理由を調べ、説明と記録を残します。
実務例: 季節的な事業増加に伴って入金が増えた顧客について、担当者は売上資料と取引時期を確認し、通常パターンとの差を説明できるか検討します。
よくある誤解: 他の顧客との比較だけで異常と判断するのは不十分です。本人の取引目的や過去の行動との関係を評価します。
47. アラートの優先順位付け
クリプトアセット・ブロックチェーンのリスク管理プログラム
アラートの優先順位は、想定される影響、取引の直接性、情報の確度、時間的な切迫性、顧客リスクなどを考慮して定めます。優先順位付けは調査資源を配分するためのもので、最終的な犯罪判断ではありません。緊急対応が必要な場合の社内連絡経路も明確にしておきます。
実務例: 複数の兆候が重なる入金アラートは早期レビューに回し、情報が限られる低影響の警告は定めた手順で追加情報を確認します。
よくある誤解: アラートの点数や色分けを結論そのものと扱うのは誤りです。分類はレビューの順序を決める補助であり、調査の代わりではありません。
48. 調査を段階的に進める
クリプトアセット・ブロックチェーンのリスク管理プログラム
調査では、最初に検知された事実を確認し、次に取引経路や顧客の背景を調べ、仮説を裏付ける情報と反証する情報の両方を評価します。そのうえで、追加確認、エスカレーション、クローズなどの対応を選びます。各段階の判断と未解決事項を記録して、再検証できるようにします。
実務例: 高リスクサービスへの送金アラートを受けた担当者は、取引の詳細、顧客プロフィール、資金の前後の動きを順に調べ、結果をケースに残します。
よくある誤解: 最初の疑いに合う情報だけを集めると、偏った結論になり得ます。別の説明や反証となる情報も確認します。
49. オンチェーン・オフチェーン情報を統合する
クリプトアセット・ブロックチェーンのリスク管理プログラム
オンチェーン情報は資産移動や契約とのやり取りを示し、オフチェーン情報は顧客確認、事業記録、連絡、内部台帳などを補います。片方だけでは取引の全体像が見えない場合があります。両方の情報を同じ時系列に置き、食い違いがあれば理由を確認して判断の根拠を明確にします。
実務例: 暗号資産取引所の顧客台帳にはUSDCの出金先としてアドレスAが記録されていますが、Ethereumのトランザクションのto欄（呼び出し先）にはUSDCのコントラクトが表示されています。担当者はトランザクションハッシュ、対象コントラクト、Transferイベントの受取先・数量を照合し、顧客台帳の出金記録と対応しているか確認します。
よくある誤解: 公開台帳があるからオフチェーン記録は不要だと考えるのは誤りです。顧客やサービスの情報が結論を補うことがあります。
50. 分析結果の証拠価値と判断の基準
クリプトアセット・ブロックチェーンのリスク管理プログラム
分析ツールの出力も、根拠や取得方法、再現性に応じて、判断を支える証拠資料になり得ます。ただし、チェーン上で観察した移転、ラベルに基づく帰属推定、顧客の説明、調査担当者の評価は区別して扱います。資料の証拠価値は情報源、裏付け、用途、適用手続によって異なります。犯罪の立証と疑わしい取引の報告に同じ水準を求めるのではなく、報告要否は適用法令の基準に従って判断します。
実務例: 入金後の資金が短時間で複数の受取先へ移った事実は取引ハッシュで示し、受取先を高リスクサービスとする情報は、ツールの出典・確認日とともに分析上の推定として記録します。犯罪関与を確定できていなくても、担当者はこれらの情報と顧客背景を基に、適用法令の報告基準を満たすかを検討します。
よくある誤解: 分析結果はすべて証拠にならない、または証拠と呼べば犯罪が証明された、という理解はいずれも誤りです。資料の種類と証拠価値を評価し、用途に応じた判断基準を適用します。
押さえておきたい60の概念 51–60
51. 疑わしい活動の報告内容を明確にする
クリプトアセット・ブロックチェーンのリスク管理プログラム
社内・当局向けの報告では、何が起きたか、なぜ懸念するのか、どの情報を確認したか、何が未確認かを分かりやすく説明します。オンチェーンの取引識別情報と、顧客や資金源に関する情報を関連付け、推測を事実のように書かないことが重要です。報告手順と内容は適用法域の要件に従います。
実務例: 担当者は入金の取引識別情報、顧客の申告、調査で確認した不一致を時系列にまとめ、疑念の根拠と未確認事項を分けて記述します。
よくある誤解: 疑わしいという結論だけを書いても、読み手が根拠を評価できません。具体的な事実とその解釈を分けて示します。
52. エスカレーションと顧客対応を分ける
クリプトアセット・ブロックチェーンのリスク管理プログラム
社内エスカレーションは、適切な担当者が追加調査や判断を行えるようにする手続です。顧客への照会、取引の保留、関係の見直しなどは別の判断であり、事実、社内方針、法的義務を踏まえて選択します。顧客への連絡が調査や報告を損なわないかも、適用ルールに沿って確認します。
実務例: 調査で重要な不一致が見つかった担当者は、まず所定の社内窓口へ報告し、顧客への追加質問は承認された手順に沿って行います。
よくある誤解: エスカレーションしたから顧客への拒否や解約が自動的に決まるわけではありません。各対応を根拠と手続に基づいて判断します。
53. 顧客関係の判断はリスクに応じて行う
クリプトアセット・ブロックチェーンのリスク管理プログラム
取引開始、継続、制限、終了の判断では、確認できた事実、残るリスク、適用法令、組織の許容度、利用可能な管理策を合わせて考えます。疑わしい兆候やPEP該当だけで自動的に拒否・解約するのではなく、適切な審査と承認を経て比例した決定を行い、理由を記録します。
実務例: 顧客の取引に説明できない不一致が残る場合、担当者は追加確認や管理策の変更が可能かを検討し、権限ある担当者へ判断を上申します。
よくある誤解: リスクの兆候を見つけたら必ず拒否する、あるいは何があっても継続する、という二択ではありません。個別の根拠と管理可能性を評価します。
54. ガバナンスと責任分担
クリプトアセット・ブロックチェーンのリスク管理プログラム
有効なプログラムには、経営層、コンプライアンス、事業部門、技術部門、監査などの役割と責任が明確に定められている必要があります。重要な判断を誰が行い、例外を誰が承認し、問題を誰へ報告するかを設計します。責任分担は文書上だけでなく、実際の運用と権限に合っているか確認します。
実務例: 新しいウォレット審査の導入では、技術部門がデータ接続を担い、コンプライアンスが閾値と対応手順を承認する役割を明確にします。
よくある誤解: 方針が存在すれば責任分担も機能しているとは限りません。担当者に必要な権限・資源があり、実際に責任を果たしているかを確認します。
55. 方針を具体的な手順に落とし込む
クリプトアセット・ブロックチェーンのリスク管理プログラム
方針は組織が守る原則や期待を定め、手順は担当者が実際に行う確認、判断、記録の流れを示します。暗号資産の取引やツールが変化したときに備え、対象チェーン、例外処理、判断権限、記録方法を実務に合わせて整備し、定期的に更新します。
実務例: ウォレット審査方針を受けて、チームはアラート確認、根拠の記録、上申先、誤検知の処理を手順書にまとめます。
よくある誤解: 一般的な方針文書だけで、現場の担当者が一貫して対応できるとは限りません。実行可能な手順と教育を整えます。
56. 外部ツールと委託先を管理する
クリプトアセット・ブロックチェーンのリスク管理プログラム
ブロックチェーン分析、顧客確認、取引監視を外部サービスに頼る場合でも、組織は自らの管理責任を保ちます。データの出所、更新頻度、対象範囲、障害時の対応、アクセス管理、契約上の条件を確認し、サービスの変更がリスク評価や業務に与える影響を監視します。
実務例: 分析ベンダーが新たなチェーンへの対応を追加したとき、担当者は対象範囲とデータ品質を検証し、社内ルールや利用者向け説明への影響を確認します。
よくある誤解: 外部ベンダーを利用すれば、リスク管理の責任もベンダーへ移ると考えるのは誤りです。利用者側の監督と検証が必要です。
57. 設計有効性と運用有効性
クリプトアセット・ブロックチェーンのリスク管理プログラム
設計有効性は、管理策が特定のリスクを抑える仕組みとして適切に構成されているかを問います。運用有効性は、その管理策が担当者やシステムによって一貫して実行され、意図した結果を出しているかを問います。文書の存在だけでは運用を証明できず、実際の記録やサンプルを検証します。
実務例: ウォレット審査の設計評価では、受け入れるERC-20トークンの移転元を取得して審査できる仕様かを確認し、通常送金とコントラクト経由送金のテストケースで確かめます。運用評価では、監査担当者が実際の入金記録とアラートを突合し、審査が省略されず、社内基準どおりに確認・記録されたかを検証します。
よくある誤解: 適切な設計があれば運用も有効だとみなすのは誤りです。両方を別々の証拠で評価します。
58. 管理策を継続的にテストする
クリプトアセット・ブロックチェーンのリスク管理プログラム
管理策の検証では、設計だけでなく、実際のアラート、例外、処理遅延、データ更新などを対象にテストします。サンプルの選び方と評価基準を明確にし、見つかった不備の原因、影響範囲、是正の完了を追跡します。変更後に再テストすることで、改善が機能したかを確かめます。
実務例: 顧客スクリーニングの定期点検で未処理アラートを発見した場合、担当チームは原因を調べ、是正後に同じ種類の記録を再確認します。
よくある誤解: 点検を実施したという記録だけで、管理策が有効と結論付けるのは不十分です。結果と是正の有効性まで確かめます。
59. 担当者の能力と教育
クリプトアセット・ブロックチェーンのリスク管理プログラム
暗号資産関連の管理を担う担当者は、取引の仕組み、社内手順、ツールの限界、エスカレーション経路を理解する必要があります。教育は職務に応じた内容とし、業務やリスクが変わった際に更新します。受講記録だけでなく、実務で正しく判断・処理できているかも確認します。
実務例: 新しいブリッジを取り扱うチームに、担当者が取引経路の見方と誤解しやすい表示、必要な記録方法を説明します。
よくある誤解: 全員に同じ一般研修を一度実施すれば十分とは限りません。役割ごとの知識と実務上の理解を確認します。
60. 指標、例外、改善をつなげる
クリプトアセット・ブロックチェーンのリスク管理プログラム
プログラムの監督では、処理量だけでなく、未処理アラート、誤検知、処理の遅れ、例外、品質テストの結果など、目的に合った指標を組み合わせます。数値の変化を原因調査や管理策の見直しにつなげ、対応後に効果を確かめます。指標はリスクを理解する補助であり、単独で有効性を証明しません。
実務例: アラート件数が急減した場合、管理者はリスク低下と決めつけず、データ接続、ルール変更、処理漏れの可能性を調べます。
よくある誤解: 処理件数や平均時間が目標を満たせば、プログラム全体が有効とは限りません。質的な確認と是正結果も評価します。
6段階の学習プラン
公式情報と確認事項
資格の目的、現行の学習領域、試験情報、改訂時期に関する基準情報は、2026年10月11日時点で確認したACAMSのCCAS公式ページに基づいています。試験形式・提供言語は改訂前の現行プログラムについての記載であり、改訂後の詳細や法域別の義務を推測していません。個別の法令判断には、該当法域の最新の一次資料を確認してください。https://www.acams.org/en/certifications/certified-cryptoasset-anti-financial-crime-specialist-certification-ccas