0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Rascal

暗号資産インサイダー取引疑いを PII を保持せずに検知する設計 — 改正金商法 第171条対応の実装事例

0
Posted at

TL;DR

  • 2026 年 4 月 10 日に国会提出された 改正金融商品取引法案 で、暗号資産にもインサイダー取引規制 (第 171 条の 7 ～ 10) が新設されます (公布後 1 年以内に施行見込み)。
  • 暗号資産取引業者 (VASP) としては、役員 / 職員 / プロジェクト関係者の wallet と監視対象銘柄の取引を検知する必要があります。
  • 一方で、「誰が役員か」「誰が関係者か」という個人特定情報 (PII) を外部の分析ベンダーに渡すのは ISO27001 等の取得前には現実的でない — ここで実装が詰まりがちです。
  • 本記事では、ChainAnalyzer が PII を一切保持せず、ラベルマッチングだけでインサイダー取引疑いを検知する設計 (W15 INSIDER_TRADE_SUSPECT detector) を公開します。
  • VASP 側が「アドレス → 所属会社ラベル」「銘柄 → スコープラベル」の 2 つのタグを管理するだけで運用可能。マッチングは label 文字列の case-insensitive 完全一致のみ。
  • false positive を抑制する設計 (Whitebit 社員ケースで A/B/C/D を例示)、検知後の出力 (SAR 起票に直接使える details.sample_tx)、今後の拡張ロードマップまでを通しで解説します。

用語集 (初出語の解説)

本記事に出てくる専門用語を最初にまとめておきます。

法規制系

  • 金商法: 金融商品取引法。日本の金融商品の取引・市場運営を規律する基本法
  • 改正金商法 (第 171 条の 7 ～ 10): 2026 年 4 月 10 日国会提出案で新設される暗号資産インサイダー取引規制。施行は公布後 1 年以内見込み
  • VASP: Virtual Asset Service Provider。暗号資産交換業者を含む暗号資産関連サービス提供者
  • 電子決済手段等取引業者: 改正資金決済法で新設された区分、ステーブルコイン取扱業者
  • JAFIC: Japan Financial Intelligence Center。資金情報機関、SAR (疑わしい取引の届出) の集約先
  • FATF Travel Rule: 国際金融活動作業部会 (Financial Action Task Force) によるトラベルルール、取引情報の取引所間共有義務

AML / コンプライアンス系

  • PII: Personally Identifiable Information。個人特定情報 (氏名、社員番号、住所等)
  • インサイダー取引: 公表前の重要情報を利用して証券・暗号資産を売買する行為
  • SAR: Suspicious Activity Report。疑わしい取引の届出書
  • STR: Suspicious Transaction Report。SAR と同義で使用されることが多い
  • ISO27001: 情報セキュリティマネジメントシステム (ISMS) の国際規格。PII を扱う場合に通常必須となる

ChainAnalyzer 内部

  • W シリーズ Detector: Wallet 系検知ロジックの ID 系列。W = Wallet, E = EVM, B = Bitcoin, C = Common
  • user_address_tags テーブル: ユーザー (= 顧客 VASP 側 admin) がアドレスに付与する private なタグ。RLS (Row-Level Security) で他ユーザーには見えない
  • Detection の details: 検知結果に紐付く JSONB 形式の証拠データ。SAR 起票や監査レビューに使用

1. 背景 — 改正金商法 第 171 条の 7 ～ 10 が要求するもの

2026 年 4 月 10 日、「金融商品取引法及び資金決済に関する法律の一部を改正する法律案」が国会に提出されました。第 171 条の 7 ～ 10 で暗号資産にもインサイダー取引規制が新設されます。

公布後 1 年以内に施行される見込みのため、VASP は今から実装準備を進める必要があります。要点を抜粋すると:

条文 (案) 規制内容
第 171 条の 7 暗号資産発行者の「会社関係者」が公表前の重要情報を利用して当該暗号資産を取引することを禁止
第 171 条の 8 公表前の重要情報の第三者への伝達禁止
第 171 条の 9 取引業者の従業者・委託先関係者にも上記を準用
第 171 条の 10 違反者への課徴金 / 刑事罰

これにより、VASP の責務として最低でも以下 2 つが必要になります:

  1. 誰が会社関係者かを把握する — 上場銘柄 (= insider scope token) ごとに「監視対象 wallet 一覧」を維持
  2. その wallet と監視対象銘柄の取引を検知する — 公表前後の取引を流動的に追跡し、検知結果を内部審査に回す

特に 2 番目は、検知対象が「on-chain でしか見えない wallet アドレス」になるため、ブロックチェーン分析ツールとの連携が事実上必須です。

2. 既存ソリューションの問題 — PII を分析ベンダーに渡す前提

多くの海外大手 AML ツールは、顧客側のデータベース (KYC 済みユーザー情報) を取り込んで「このアドレスは誰の wallet」と紐付ける 前提で設計されています。

これ自体は強力なのですが、日本の VASP 実務上、以下のような壁があります:

  • 個人情報保護法 + 業界のセキュリティガイドライン: 顧客 PII を国外のクラウドサービスに送信するには通常、明示的な利用者同意 + 委託契約 + 安全管理措置の合意が必要
  • ISO27001 等の認証要件: 分析ベンダー側にも同等の認証が要求されるケースが多い
  • 改正金商法対応の早期化: 認証取得を待つと施行に間に合わない

つまり、「インサイダー取引監視を実装したいが PII を外部に出せない」というジレンマが発生します。

3. 提案する設計 — label-matching だけで PII を流さない

ChainAnalyzer の W15 INSIDER_TRADE_SUSPECT は、この問題を以下の発想で解きます:

ChainAnalyzer は「誰が誰か」を一切知らなくて良い。
「ある wallet」と「ある token」が 顧客の主観でつながっている という事実だけ知っていれば、両者が取引した瞬間を detect できる。

具体的には、顧客側の admin が ChainAnalyzer 管理画面で 2 種類のタグを付けます:

タグ 1: 所属会社ラベル (company_affiliation)

フィールド 値
アドレス 0xUserWallet… (役員 / 開発者 / 上場前関係者などの wallet)
カテゴリ company_affiliation
ラベル "Acme 株式会社" (= 会社の識別子。顧客が任意に定める)
アイコン 🏢 等 (任意)

タグ 2: 銘柄スコープラベル (insider_scope)

フィールド 値
アドレス 0xTokenContract… (上場銘柄の token contract)
カテゴリ insider_scope
ラベル タグ 1 と同じ会社の識別子 "Acme 株式会社"
アイコン 🎯 等 (任意)

マッチング条件

W15 は、scan 対象 wallet について以下を行います:

  1. その wallet に company_affiliation タグがあるかチェック → なければ早期 exit (= 一般ユーザーの scan は影響を受けない)
  2. その wallet が触ったすべての token contract に対して、insider_scope タグを bulk lookup
  3. ラベルが case-insensitive で完全一致 したペアのみ HIGH severity (-15) で fire

つまり ChainAnalyzer 側のデータベースには:

  • 「ある wallet にラベル "Acme 株式会社" が付いている」
  • 「ある token にラベル "Acme 株式会社" が付いている」

という事実だけしか存在せず、「Acme 株式会社の誰がその wallet を所有しているか」という情報は ChainAnalyzer には一切流入しません。

これにより、ISO27001 取得前でも安全に運用可能になります。

4. 実装の中身

4-1. DB スキーマ (Supabase / PostgreSQL)

UNIQUE 制約を外したのは、1 アドレスに複数タグを付けられるようにするため (例: ある wallet が同時に 2 社の関係者である場合や、whitelist と company_affiliation を併用するケース)。

RLS (Row-Level Security) は既存の policy が user_id = auth.uid() で効いているため、追加変更不要です。他ユーザーには 見えません。

4-2. Detector 本体 (Python / FastAPI)

ポイント:

  • early exit: company_affiliation タグがない wallet では即 return — 一般ユーザーの scan のパフォーマンスを犠牲にしない
  • bulk lookup: 触った全 contract のタグを 1 回の DB クエリで取得 (round-trip 削減)
  • case-insensitive: .strip().lower() でラベル比較
  • early dedupe: 同じ (company, contract) ペアが複数の insider_scope タグでマッチしても 1 件にまとめる

5. ユースケース — Whitebit 社員のケースで挙動を確認

ここでは、架空の例として「Whitebit という取引所の社員 wallet を監視している」前提で W15 の発火パターンを示します。

Setup

対象 category label icon
0xEmployee (役員の wallet) company_affiliation Whitebit 🏢
0xWBT_contract (Whitebit が発行する WBT トークン) insider_scope Whitebit 🎯

4 ケースでの挙動

ケース A: 社員が ETH を Whitebit 取引所に入金

  • 取引内容: 0xEmployee → 0xWhitebitHotWallet で ETH 5.0 送金
  • W15: ✕ fire しない
  • 理由: ETH (native token) には insider_scope タグが付いていない。汎用トークンの取引は誤検知抑制のため対象外
  • 含意: 社員が通常業務で自社取引所を使うだけでは騒がない

ケース B: 社員が自社銘柄 WBT を取引

  • 取引内容: 0xEmployee が 0xWBT_contract と DEX 経由でやり取り (買い or 売り)
  • W15: ● fire (HIGH)
  • description: インサイダー取引疑い: "Whitebit" 所属タグ付きウォレットがインサイダー対象トークン WBT（scope: "Whitebit"）を取引しました（N 件: 送信 X / 受信 Y）。コンプライアンスレビューを実施してください。
  • 含意: 公表前後の駆け込み売買の可能性 → 内部審査必須

ケース C: 社員が WBT を自社取引所に入金 (給与の換金目的かも)

  • 取引内容: 0xEmployee → 0xWhitebitHotWallet で WBT を送金
  • W15: ● fire (HIGH)
  • 含意: 給与換金など正当な目的の可能性もあるが、重要発表前後はレビュー必須。コンプライアンス担当者が dismiss するか SAR 起票するか判断

ケース D: タグ無しのアドレス

  • 取引内容: 任意
  • W15: ✕ fire しない — そもそも early-exit するので、未登録 wallet のスキャンには何の影響もない (パフォーマンスへの影響もゼロ)

Detection の details (ケース B の例)

{
  "detector_id": "W15",
  "detector_name": "INSIDER_TRADE_SUSPECT",
  "severity": "HIGH",
  "description": "インサイダー取引疑い: \"Whitebit\" 所属タグ付きウォレットがインサイダー対象トークン WBT（scope: \"Whitebit\"）を取引しました（5 件: 送信 3 / 受信 2）。コンプライアンスレビューを実施してください。",
  "details": {
    "company": "Whitebit",
    "company_tag_id": "uuid-1234",
    "company_icon": "🏢",
    "wallet_address": "0xEmployee…",
    "chain": "ethereum",
    "token_contract": "0xWBT…",
    "token_symbol": "WBT",
    "token_scope_label": "Whitebit",
    "token_scope_tag_id": "uuid-5678",
    "token_icon": "🎯",
    "tx_count": 5,
    "send_count": 3,
    "receive_count": 2,
    "sample_tx": [
      { "tx_hash": "0xaaa…", "timestamp": "1716651000", "role": "send", "amount": "1000", "token_symbol": "WBT" },
      { "tx_hash": "0xbbb…", "timestamp": "1716651060", "role": "receive", "amount": "500", "token_symbol": "WBT" }
      /* up to 10 */
    ]
  }
}

sample_tx 配列に最大 10 件まで TX ハッシュ / 時刻 / 送受信方向 / 金額が含まれるため、JAFIC への SAR 提出資料や内部監査の証跡としてそのまま使えます。

6. なぜ「label の一致」だけで十分なのか

「ラベル文字列だけで判定する」というと不安に感じるかもしれませんが、設計上の保証は十分にあります:

6-1. ラベルの管理権は完全に顧客 (VASP) 側にある

  • ChainAnalyzer は「ラベルが何を意味するか」を一切解釈しません
  • 顧客 admin が「Acme 株式会社」というラベルを wallet と token の両方に付けた事実だけが、W15 の根拠
  • もし顧客側でラベルが間違っていれば、それは顧客側の責任で訂正できる (タグ編集 UI で即時可能)

6-2. PII を流していないので、誤検知の被害が小さい

  • 万一 W15 が誤検知しても、ChainAnalyzer 側には「Whitebit 所属の誰か」までしか情報がない
  • 顧客側で「これは正当な取引」と判断したら dismiss するだけ
  • 一方、PII 集約型のシステムだと「○○さん (役員) がインサイダー取引した疑い」という記録が外部に残り得る → 風評リスクが大きい

6-3. ラベル文字列を変更すれば監視を切り替えられる

  • 「Acme」ラベルを廃止して「Acme-2」に切り替えれば、過去の検知履歴と分離可能
  • 多角的監視 (M&A、社名変更、ジョイントベンチャー等) にも柔軟に対応

7. 設計上の制約と回避策

正直に書くと、W15 にも制約があります:

7-1. ラベル表記揺れに弱い

✕ "Acme 株式会社" と "ACME株式会社" は別物扱い (case-insensitive のみで、空白除去はしない)
✕ 「Acme」と「Acme Inc.」も別物

回避策: 顧客側で ラベル運用ガイドライン (1 会社 = 1 ラベル文字列) を定めて、内部統制で管理する。ChainAnalyzer 側で正規化を強制すると逆に柔軟性を損なうため、現状は意図的に「文字列そのまま」マッチにしています。

7-2. 重要発表の時刻フィルタが未実装

現状の W15 は「いつ取引したか」と「重要発表がいつあったか」を紐付けません。つまり:

  • 重要発表 1 か月後の取引も発火する (理論的にはインサイダーではない)
  • 給与の月次換金タイミングも fire する可能性

回避策 (拡張ロードマップ): company_announcement テーブルを将来導入し、発表時刻 ±N 日のフィルタを追加予定。これにより駆け込み売買のみに絞り込めるようになります。

7-3. counterparty 検知は未対応

「社員が自社取引所に WBT を入金する」というケース C は fire しますが、「複数の社員が同時期に同じ取引所に集中送金する」という meta-pattern は未対応です。

回避策 (拡張ロードマップ): W15b counterparty 検知で対応予定。

8. 拡張ロードマップ

優先度順に:

  1. company_announcement テーブル (中優先度)
    • 重要発表の時刻を顧客 admin が登録 → ±N 日のフィルタを W15 に追加
    • 駆け込み売買だけに絞り込み、ノイズ削減
  2. W15b INSIDER_TRADE_COUNTERPARTY (中優先度)
    • 社員 wallet が自社取引所に異常な頻度で送金する場合に fire
    • 集団インサイダー検知の入り口に
  3. 監査ログ自動 PDF 出力 (低優先度)
    • 月次 / 四半期で W15 fire 一覧を PDF レポート化
    • コンプライアンス監査のエビデンスパッケージ化
  4. ラベル正規化オプション (低優先度)
    • 「空白除去」「半角全角統一」を opt-in で提供 (デフォルトは現状の strict マッチ)

9. まとめ

項目 内容
検知 ID W15 INSIDER_TRADE_SUSPECT
Severity HIGH (-15)
対象 EVM (Ethereum / Polygon / BSC / Base / Arbitrum / Optimism / Avalanche) + Solana
設計の核 ChainAnalyzer 側は PII を一切保持しない
マッチング company_affiliation × insider_scope の label 完全一致 (case-insensitive)
出力 description + details (会社名 / wallet / token contract / symbol / 取引数 / 最大 10 件の sample TX)
改正金商法対応 第 171 条の 7 ～ 10 に直接対応
運用要件 ISO27001 取得前でも安全に運用可能
提供開始 2026-05-25、Pro 以上のプランで利用可 (chain-analyzer.com)

本記事のオリジナルな貢献:

  1. 改正金商法 第 171 条対応のインサイダー検知を、PII 集約に頼らずに実装する設計 を公開
  2. label match だけで十分な根拠を得られる ことを Whitebit 風 ケース A/B/C/D で例示
  3. 既存の AML 分析ツールの「PII 渡し前提」設計に対する代替案 を提示
  4. 拡張ロードマップ (company_announcement, W15b) を明示し、運用フィードバックの受け皿を整備

VASP / 暗号資産取引業者の皆様で、改正金商法対応のインサイダー検知システムをご検討中の場合は、ぜひ実トランザクションでの検証 (有償トライアル) をご相談ください。

参考リンク

免責: 本記事は改正金融商品取引法案 (2026 年 4 月 10 日国会提出) に関する一般的な情報に基づく技術的解説であり、特定の法的助言ではありません。実際の規制対応にあたっては、最終的な施行内容・関連政省令・所管当局のガイドラインを確認のうえ、必要に応じて法律専門家にご相談ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?