疑わしいアドレスを業者間で共有するには｜暗号資産AMLとトラベルルールの分け方

ある暗号資産交換業者のAML担当が、あるアドレスを「詐欺に使われた疑いがある」として、業者どうしの共有リストに登録しました。数日後、それが取り違えだったと分かります。担当は自社のデータベースから記録を消しました。

ところが、そのアドレスへの正当な顧客の送金は、ほかの交換業者で止まり続けました。各社のキャッシュや分析用の写しに、古い判定が残っていたからです。消したはずの誤りが、共有した先では生きていました。

2026年7月に金融庁が公表した実証結果では、次の情報の業者間共有が検証されました。疑わしいアドレス、トランザクション情報、リスクカテゴリ、リスクスコア、検知理由、情報源、確認日時です。同時に、アラートだけでは取引制限等の判断に足りない場合があり、追加の調査が要ることも確かめられています。

では、共有とトラベルルールの通知を、事故なく運用するにはどうすればよいか。要点は4つです。

• 送る情報を3つに分ける（個人情報／取引の記録／「怪しい」という情報）
• アドレスが一致しても自動では止めず、調査に回す
• 誤りは消すのではなく、撤回の知らせを利用するすべてのシステムに届ける
• 見せる範囲を、役割と項目で絞る

以下では、冒頭の交換業者のAML責任者とシステム設計者が決める順に、この4つを見ていきます。

この記事でわかること

• トラベルルールの通知と、疑わしいアドレスの共有を分けて扱う方法
• アドレスが一致したときの調べ方と、誤登録の撤回の届け方
• 見せる範囲の絞り方、相手の業者とつなぐときの試験

送る情報を、3つに分けて持つ

トラベルルールは、暗号資産を移すときに、送付人・受取人の情報を相手のVASPへ知らせる枠組みです。一方、アドレスの共有は、あるアドレスや取引に詐欺・制裁・不審な行動などの兆しがある、という情報を共同で使う仕組みです。

目的、更新の頻度、訂正する人、見る人が違います。同じ「ブラックリスト兼トラベルルール台帳」に詰め込むと、共有しすぎと誤判定が起きます。そこで、次の3つに分けて持ちます。

• トラベルルールの通知情報
  • 中身：送付人・受取人、相手のVASP、通知に要る識別情報
  • 渡す相手：その送付の相手のVASPだけ
  • 更新・削除の単位：送付のIDと、法律・契約で決まった保存の方針
  • 避けること：ブロックチェーン上に記録しない。参加者全体に配らない
• チェーン上の取引の記録
  • 中身：チェーン、資産、アドレス、トランザクションハッシュ、時刻、向き、ブロック
  • 渡す相手：分析や照合に必要なシステム
  • 更新・削除の単位：チェーン上の事実と、再編・確定の状態
  • 避けること：同じ名前の別の資産や、別のネットワークにある同じ文字列のアドレスと取り違えない
• リスク観測（「怪しい」という情報）
  • 中身：分類、スコア、検知の理由、根拠、情報源、確認した時刻
  • 渡す相手：契約・目的・権限の条件を満たす参加者
  • 更新・削除の単位：観測のID、版、有効期限、撤回
  • 避けること：人の変わらない属性や、自動凍結の命令として扱わない

分けるといっても、つながりを断つわけではありません。3つは互いのIDでたどれるようにしておき、権限のある担当者だけが必要なものを結びつけます。ログや分析用の置き場に全項目を写すのではなく、用途ごとに置き換えたIDで追います。

国内の暗号資産の送付に伴う通知の義務は、犯罪収益移転防止法第10条の5が定めています。JVCEAの案内は、相手の区分や使っているシステムによって、通知の経路が違うと説明しています。

法律で決まった通知事項、対象の法域、保存、利用目的は、業態・取引・最新の法令に応じて、法務・コンプライアンスの担当者が決めます。上の3つの分け方は、その判断をシステムに反映しやすくするためのものです。

「怪しい」という情報には、根拠と期限を付けて共有する

アドレスを「黒」という印だけで共有すると、大事なことが抜け落ちます。どのチェーンか、何を根拠に、いつ確かめ、どのくらい疑わしく、誰が訂正できるかです。

金融庁のFinTech実証実験ハブの結果が挙げた共有項目を土台に、共有する情報には次のことを必ず付けます。

• どのチェーン・資産の、どのアドレスや取引か
• 疑いの種類と程度、根拠の確からしさ、検知の理由
• どの業者が、いつ確かめたか。いつまで有効か、誰が訂正したか

情報は上書きせず、版を重ねて持ちます。項目の一覧は、後半の「実装する人向けの詳細」にまとめています。

疑いの程度（スコア）と、根拠の確からしさは別のものです。高リスクでも根拠がまだ仮の観測と、制裁の対象に直接一致したものを、同じ処理に流してはいけません。

アドレスそのものをハッシュにしても、候補を並べられる場合は照合されえます。「ハッシュだから匿名」とは考えません。アドレスと顧客の対応、情報源、調査のメモを含めて、プライバシーへの影響を評価します。

アドレスが一致しても、止めずに調査に回す

金融庁の実証結果は、モニタリングのアラートだけでは足りない場合があるとしています。疑わしい取引の届出、取引制限、電子決済手段の凍結・消却等の判断です。資金の流れ、公開情報、関連アドレス等の追加の調査が要ります。

そのため、共有された観測を最終の判断にはしません。自社の顧客・取引・法的な権限にもとづく調査の案件に変えます。一致のしかたによって、確かめることが違います。

• 完全に一致：ネットワークとアドレスが一致しても、情報源、分類、版、期限、根拠の取引を確かめる。
• 近くで一致：取引を何回たどった先か（ホップ数）だけで決めない。資金の割合、時系列、サービス用のウォレット、釣り銭アドレス（送金で余った分を戻すアドレス）等の前後関係を調べる。
• 行動の型が一致：モデルの版、特徴量、しきい値、再現できる説明を残す。モデルの出力と、分析担当者の判断を分ける。
• 判定が食い違う：提供者によってスコアが違う場合、平均にまとめない。各観測と、自社が採った・採らなかった理由を残す。

緊急停止、出庫の保留、顧客への照会、取引の継続、届出の検討などをどうするかは、いくつかの要素で決まります。観測の種類、金額、顧客のリスク、法的な根拠、自社の規程です。出庫を保留・解除する判定の組み立ては、出庫制限の設計で詳しく扱います。

誤登録は消さずに、撤回を全員に届ける

冒頭の交換業者がしたように、誤登録をデータベースから消すだけでは足りません。古い判定は、キャッシュ、ログ分析の基盤（SIEM）、分析用のデータウェアハウス、参加するVASPの手元の写しに残ります。訂正は、「撤回」や「訂正」の新しい版として配り、どこまで届いたかを追います。手順は次のとおりです。

1. 異議の申し立てや社内での発見を、訂正の案件として受け付ける。元の観測と、それを使った先は消さずに残しておく。
2. 調べているあいだは「審査中」とし、自動の対応をするかどうかを分類ごとに切り替える。
3. 訂正した人、理由、根拠、承認者、効力が生じる時刻を持つ新しい版を出す。
4. イベントの配信と取得用のAPIの両方で配る。利用するシステムごとに、受け取ったという応答と、反映した版を見張る。
5. 古い版を使った未完了の案件を評価し直す。顧客への影響、保留、通知、記録の直しを、担当者に割り当てる。
6. 期限までに応答を返さないシステムは、切り離すか権限を止める。同期し直してから戻す。

監査のために古い観測を残す場合も、普段の照会には今の状態を返します。古い版が、判断に再び入り込まないようにするためです。保存期間、本人・関係者からの申し立て、共同利用・第三者提供の扱いは、最新の法令と個別の契約に沿って決めます。その結果を、システムの設定値として持ちます。

通知と送付を、別々に記録する

送る処理の中にも、別々の事実がいくつもあります。相手のVASPへ情報を渡せたこと、AMLのリスク審査を通ったこと、取引をチェーンへ送ったこと、チェーンで確定したことです。

これを1つの「成功」にまとめると、3つの事故を見逃します。

• 通知がタイムアウトした後に、もう一度送って二重に通知する
• 通知が届いていないのに、資産を送ってしまう
• チェーンで確定したのに、社内の台帳が更新されていない

トラベルルールのAPIがタイムアウトしても、相手はすでに受け取っているかもしれません。通知を作り直さず、まず相手に状態を問い合わせます。チェーンへの送付がタイムアウトしたときも同じです。送った取引を確かめてから、同じ取引を送り直します。新しい取引を作るには、別の承認を要るようにします。段階の分け方と再送の方法は、後半にまとめています。

見せる範囲を、用途と項目まで絞る

同じ会社の中でも、役割によって要る情報は違います。スクリーニングの仕組みに、トラベルルールの個人情報は要りません。そこで権限は、組織の名前ではなく、何の用途で、どの項目まで見せるかで絞ります。役割ごとの例は次のとおりです。

通信中と保存時の暗号化に加えて、次のものを見張ります。

• 相手のVASPの識別情報、証明書・鍵の入れ替え
• サービスアカウント、データの出力、一括の照会

監査ログには、平文の個人情報や認証トークンを写しません。誰が、何の目的で、どの記録のどの版に、何をしたかを残します。運用担当者が同じ権限でログを消せない場所へ送ります。

相手の交換業者とつなぐとき、何を確かめるか

トラベルルールの製品が同じでも、相手のVASPとは次の点が合わないことがあります。プロトコルの版、必須の項目、資産の見分け方、手動の代わりの手順、応答の時間です。逆に通信のしかたが違っても、共通の意味の形に変えられれば、変換用の部品（アダプター）でつなげます。試すのは、次の3つの層です。

• データの意味：IVMS101等を共通のデータの形の基準にする。氏名・住所・法人・識別子を、情報を失わずに変換できるかを確かめる。
• 通信：Travel Rule Protocol（TRP）等の送信、暗号化、相手の発見、受け取りの応答、再試行、版の取り決めを、アダプターとして切り出す。
• 業務のルール：対象の法域、相手の区分、通知の時点、必須の項目、アンホステッド・ウォレットへの対応、リスクへの対応。これらはコードに書き込まず、承認済みのルールの版で管理する。

FATFは2025年6月に勧告16（Recommendation 16）を改訂しました。決済の流れの中での責任と、情報の要件の標準化、詐欺・誤りを防ぐ道具をはっきりさせています。ただし、国・地域ごとの実施の時期や、国内法への反映は同じではありません。FATFの標準、国内法、相手の法域、業界の規則は、別々のルールの出どころとして版で管理します。

本番の前に、訂正・タイムアウト・相手との違いを試す

• 同じアドレスの文字列を別のネットワークで入れても、間違った観測に一致しない。
• トラベルルールの通知を送った後にタイムアウトさせても、状態の照会と同じ依頼番号で二重の通知を防げる。
• 通知の受け取りの応答の後に宛先・数量・資産を変えると、承認と通知が無効になる。
• 有効な観測を撤回に訂正したとき、キャッシュ、イベントの配信、データウェアハウス、参加するVASPのすべてのシステムが新しい版を受け取ったと応答する。
• リスク情報の提供者ごとにスコアの尺度が違っても、元のスコアと自社の対応づけを再現できる。
• 相手のVASPが対応していない項目、古いプロトコル、止まっている接続先を返したとき、手動の代わりの手順か保留へ安全に移る。
• トラベルルールの窓口、リスク判定のサービス、主に使うRPCのどれかを止めても、資産の状態と通知の状態をそれぞれ確定できる。
• 一括の出力、目的の外の照会、失効したサービスアカウントを止め、監査のアラートが担当者に届く。

合格の条件は、APIがHTTP 200を返すことではありません。次のことがすべてできることです。

• 通知の中身と受け取った相手を説明できる
• 採ったリスク観測の版と、人の判断を再現できる
• 訂正をすべての利用先に反映でき、タイムアウトの後も二重の通知・二重の送付を起こさない

よくある実装上の質問

トラベルルールの個人情報をブロックチェーンへ書き込むのですか？

通常、トラベルルールの送付人・受取人の情報はブロックチェーンに書きません。相手のVASPとの、守られたチェーンの外の通信で交換します。チェーン上には資産の移転の取引が残りますが、通知情報は別のシステムで管理します。アクセス制御、暗号化、保存・削除の方針をかけられるシステムです。両者は、送付のID等で結びつけます。

共有リストにアドレスが一致したら自動的に送付を拒否できますか？

一致しただけで、一律に自動で拒否する作りは避けます。ネットワーク、情報源、分類、根拠、観測の版、期限、顧客と資金の流れを確かめます。そのうえで、自社の規程と法的な権限にもとづいて、追加の調査・保留・承認に分けます。金融庁の実証結果も、アラートだけでは取引制限等の判断に足りない場合があるとしています。

アンホステッド・ウォレット宛ならトラベルルール対応は不要ですか？

相手のVASPへの法定の通知と、顧客・宛先の情報の収集やリスク評価は、分けて確かめます。JVCEAの案内では、アンホステッド・ウォレット等への送付は、相手の交換業者への通知とは区分されています。一方で、属性の調査・分析とリスク評価等が説明されています。対象の資産や取引の形で扱いが変わるため、宛先の種類ごとに処理を分けておきます。

実装する人向けの詳細

ここからは、冒頭の交換業者でシステムを作る設計者向けの詳細です。

3つの情報を結びつけるID

case_id、transfer_id、observation_idを相互参照し、権限のある担当者だけが必要な面を結合します。ログや分析用データレイクへ全項目を複製せず、用途別にトークン化したIDで追跡します。

共有するリスク観測の項目

アドレスをblack=trueだけで共有せず、版を管理できる観測レコードにします。

scoreは脅威の大きさ、confidenceは根拠の確からしさです。

撤回の手順で使う状態

訂正は新版のWITHDRAWNまたはCORRECTEDイベントとして配信します。異議申立て・内部検知はcorrection_case_idで受け付け、調査中はUNDER_REVIEWとします。

トラベルルール連携を含む送付の状態

トラベルルール APIのタイムアウトでは、ペイロードを作り直さず、transfer_id + recipient_vasp_id + payload_hashを冪等キー（何度送っても1回分だけ処理させるキー）として、まず状態を照会します。チェーン送付APIのタイムアウトも同様に、トランザクションハッシュ、nonce（連番）またはUTXO、署名済みの生トランザクションを確かめてから、同じトランザクションを再送します。新しいトランザクションを作る操作は別承認にします。

役割ごとに残す監査イベント

関連する記事

• 共有された観測を受けて、出庫をどう止め、どう解除するか：暗号資産交換所の出庫制限設計
• 侵害や障害の後に、機能ごとにサービスを戻す判断：暗号資産交換所のサービス再開設計
• ハードフォーク時の入出庫の止め方と再開：ハードフォーク時の取引所対応
• 制度改正に合わせたシステム側の準備：暗号資産の金商法改正と事業者の実装準備
• ウォレットと送付処理の基礎：ブロックチェーンウォレットの導入・開発と運用設計のポイント

XTELAができること

私たちは、VASP間連携の共通データモデル、トラベルルールのプロトコルとの接続部分、リスク観測のAPI、調査ケースの管理、訂正を全利用先へ届けるイベント配信、権限と監査ログを、PoCと障害試験を含めて設計・実装します。貴社の法務・コンプライアンス担当者が決めた通知事項や保存方針を、そのままシステムの設定値として持てる形に落とすのが私たちの役割で、法的な判断は弁護士と連携して進めます。データの流れと責任の分け方を具体化したい場合はお問い合わせください。

主要参考資料

• 金融庁「FinTech実証実験ハブ」支援決定案件の実験結果について（2026年7月24日）
• e-Gov「犯罪による収益の移転防止に関する法律」第10条の5
• JVCEA「犯罪収益移転防止法令の施行に伴うトラベルルール対応」
• FATF “FATF updates Standards on Recommendation 16 on Payment Transparency”（2025年6月）
• FATF “Virtual Assets: Targeted Update on Implementation of the FATF Standards”（2025年）
• interVASP Messaging Standard IVMS101
• OpenVASP Association “Travel Rule Protocol”

資料の確認日と注意

法令・仕様の一次資料は2026年8月12日に確認し、金融庁の実証結果の中身は2026年9月24日に確かめ直しました。ここに書いたのは、その資料にもとづく技術・業務の設計の整理です。法令や相手のVASPの対応状況は変わりえます。個別の判断は、最新の公式資料をもとに、社内のコンプライアンス担当者や弁護士と確かめてください。