予測市場のインサイダー取引をAIで検知する、という記事を読んだ。米国のCFTC（商品先物取引委員会）が、PolymarketみたいなオフショアのクリプトプラットフォームへVPN経由で入り込んでいるトレーダーをAIで追いかけるという話だ。
CFTCの委員長がWIREDに語った言葉がリアルだった。「データをAIに食わせると、本当に良い情報が出てくる。どこを調査すべきか、どのトレーダーにサブポエナを送るべきか、見えてくる」と。ChanalysisやNasdaq Smartsみたいなサードパーティのツールも使いつつ、トレーディングパターンを分析して異常を検知している。
これを読んで最初に思ったのは、「このAIの使い方、自分たちのモニタリング系の実装と本質的に同じ構造だな」ということ。時系列データを流して、ベースラインからの逸脱を検知して、フラグを立てる。やっていることは異常検知の王道だ。
規制機関がこういう使い方をしているのを見ると、LLMを異常検知のラベリングや説明生成に噛ませるのは、もうフィクションじゃないと感じる。自分がいま触っているアプリケーションログの監視基盤にも、似たような構造が作れるはずだ。
ただ、ちょっと立ち止まって考えたのが、AIのアウトプットをどこまで信頼して意思決定に使うかという問題だ。「AIが怪しいと言ったからサブポエナを送る」という判断フローは、FPを踏んだときのコストが桁違いに高い。
自分のコードで言うと、アラートの閾値設定に近い感覚がある。感度を上げればFPが増えて、担当者が疲弊する。下げれば見逃しが増える。CFTCも同じトレードオフの中にいるはずで、「hundreds, if not thousands」のインサイダー取引のタレコミを処理しているという話も、そのコスト感がリアルに伝わってくる。
このトレードオフをシステムに落とし込むとき、自分ならどう設計するか。たぶんこんな感じを考える。
これ、実はいま自分が関わっているサービスの監視基盤でも完全にできていない部分だ。アラートは飛ぶけど、なぜそのアラートが発火したかの説明が薄い。
PolymarketがChainalysisと組んだのも、CFTCがChainalysisを使っているのも、結局「同じデータを同じツールで見ている」という状況になっている。Chainalysisの広報担当者が「両クライアントに同じデータ分析を提供している」と明言しているくらいだ。
規制する側と規制される側が同じSaaSを使う、という構図はけっこう示唆深い。インフラやツールが共通化されれば、差別化は「何を検知対象にするか」と「検知結果をどう使うか」のポリシーの部分にシフトする。これはセキュリティ系のSaaS選定と同じ話で、ツールよりもオペレーション設計のほうが重要になる。
自分の直近のタスクに引きつけると、ログ監視の異常検知にLLMを組み込む実験を来週やってみるつもりだ。まずCloudWatch Logsから取ったエラーパターンをベクトル化して、コサイン類似度でクラスタリングするところから始める。CFTCほどの規模感ではないけど、「AIに食わせたら見えてきた」という感覚を自分でも体験してみたい。
「AIに食わせたらすごい情報が出てきた」という現場感
CFTCの委員長がWIREDに語った言葉がリアルだった。「データをAIに食わせると、本当に良い情報が出てくる。どこを調査すべきか、どのトレーダーにサブポエナを送るべきか、見えてくる」と。ChanalysisやNasdaq Smartsみたいなサードパーティのツールも使いつつ、トレーディングパターンを分析して異常を検知している。
これを読んで最初に思ったのは、「このAIの使い方、自分たちのモニタリング系の実装と本質的に同じ構造だな」ということ。時系列データを流して、ベースラインからの逸脱を検知して、フラグを立てる。やっていることは異常検知の王道だ。
規制機関がこういう使い方をしているのを見ると、LLMを異常検知のラベリングや説明生成に噛ませるのは、もうフィクションじゃないと感じる。自分がいま触っているアプリケーションログの監視基盤にも、似たような構造が作れるはずだ。
「サブポエナを自動化する」という発想の怖さ
ただ、ちょっと立ち止まって考えたのが、AIのアウトプットをどこまで信頼して意思決定に使うかという問題だ。「AIが怪しいと言ったからサブポエナを送る」という判断フローは、FPを踏んだときのコストが桁違いに高い。
自分のコードで言うと、アラートの閾値設定に近い感覚がある。感度を上げればFPが増えて、担当者が疲弊する。下げれば見逃しが増える。CFTCも同じトレードオフの中にいるはずで、「hundreds, if not thousands」のインサイダー取引のタレコミを処理しているという話も、そのコスト感がリアルに伝わってくる。
このトレードオフをシステムに落とし込むとき、自分ならどう設計するか。たぶんこんな感じを考える。
- AIはフラグを立てるだけで、アクション自体は人間が判断するレイヤーを必ず挟む
- フラグの根拠（どの特徴量が効いたか）をLLMで自然言語化してレビュアーに渡す
- FP/FNのフィードバックをラベルとして蓄積して、継続的にモデルを更新できる仕組みを持つ
これ、実はいま自分が関わっているサービスの監視基盤でも完全にできていない部分だ。アラートは飛ぶけど、なぜそのアラートが発火したかの説明が薄い。
規制機関がやっていることをプロダクトに引きつける
PolymarketがChainalysisと組んだのも、CFTCがChainalysisを使っているのも、結局「同じデータを同じツールで見ている」という状況になっている。Chainalysisの広報担当者が「両クライアントに同じデータ分析を提供している」と明言しているくらいだ。
規制する側と規制される側が同じSaaSを使う、という構図はけっこう示唆深い。インフラやツールが共通化されれば、差別化は「何を検知対象にするか」と「検知結果をどう使うか」のポリシーの部分にシフトする。これはセキュリティ系のSaaS選定と同じ話で、ツールよりもオペレーション設計のほうが重要になる。
自分の直近のタスクに引きつけると、ログ監視の異常検知にLLMを組み込む実験を来週やってみるつもりだ。まずCloudWatch Logsから取ったエラーパターンをベクトル化して、コサイン類似度でクラスタリングするところから始める。CFTCほどの規模感ではないけど、「AIに食わせたら見えてきた」という感覚を自分でも体験してみたい。