市場そのものではなく、市場について配信された記録を判断する機械
金融AIについて語るとき、人はまずモデルを見る。
予測精度はどれほど高いのか。どのアルゴリズムを採用しているのか。どれだけ多くの変数を学習できるのか。急変相場へ適応できるのか。
しかし、モデルがどれほど高度でも、その前にあるデータ供給網が壊れていれば、金融AIは正しく判断できない。
金融AIの眼球はモデルではない。価格、約定、注文板、ニュース、統計、オンチェーン記録を運んでくるデータ供給網である。モデルは、その眼球が作った像を解釈する脳に過ぎない。
市場で何かが起こり、取引所や行政機関が記録し、APIやニュースフィードが配信し、収集システムが受信する。そこで時刻、通貨、銘柄、単位、スキーマが統一され、欠損や重複が処理され、特徴量へ変換された後、ようやくモデルへ届く。
現実の事象からモデルの判断までは、一本の直線ではない。
現実事象 → 一次記録 → 外部配信 → 受信 → 正規化 → 品質処理 → 特徴量化 → モデル判断 → 注文または警報 → 保存と再現
この連鎖のどこか一つが壊れれば、モデルが正常でも判断は壊れる。
金融AIの問題は、賢さだけではない。
何を、いつ、どこから、どの意味で、どの程度の確度をもって観測できているかという問題である。
金融AIは市場を直接見ていない
人間もAIも、市場そのものへ触れることはできない。
金融AIが見ている価格は、市場そのものではない。ある取引所のマッチングエンジンが成立させた約定を、その取引所の配信システムが外部向け形式へ変換し、ネットワークを経由して利用者のシステムへ届けた記録である。
金融AIが読むニュースも、出来事そのものではない。企業、政府、中央銀行、取材者、通信社、転載媒体、翻訳システム、要約AIなどを経由した記述である。
オンチェーンデータも同じだ。
ブロックチェーンには、あるアドレスから別のアドレスへ資産が移動したことは記録される。しかし、その移動が売却準備なのか、取引所内部の資金整理なのか、カストディ移管なのか、担保差し替えなのかまでは書かれていない。
金融AIが受け取るものは、事実そのものではない。
生成主体、配信経路、変換履歴、観測時刻、不確実性を持つ記録である。
この区別が失われると、AIは配信された数値を現実そのものとして扱い始める。
2026年6月までに公表された国際機関、監督当局、市場インフラ事業者の資料では、AI利用に伴うデータ品質、データ来歴、第三者依存、市場集中、説明責任への関心が明確になっている。モデルの検証だけでなく、そのモデルが依存する入力、外部サービス、データ加工経路まで監督対象として捉える方向が強まっている。
これは新しい流行ではない。
金融AIが市場へ近付くほど、モデルの内側よりも、モデルへ現実を運ぶ外側の構造が重要になるという必然である。
全てのデータは同じ種類の「事実」ではない
金融AIへ渡される情報は、数値や文章という形式だけを見れば似ている。しかし、その成立過程は大きく異なる。少なくとも、次の六つを区別しなければならない。
観測値は、約定価格、取引数量、ブロック高、公開された文書など、特定のシステム上で直接記録された値である。
集計値は、出来高加重平均価格、指数、マーク価格、資金調達率、インプライド・ボラティリティなど、複数の観測値を一定の計算規則でまとめた値である。
推計値は、ナウキャスト、推定残高、流動性推計、需要予測など、観測できない対象をモデルや仮定によって近似した値である。
訂正可能な速報値は、経済統計、企業業績、災害情報など、迅速性を優先して公表され、後から改定される可能性を持つ値である。
法的に公表された値は、規制文書、制裁指定、ライセンス、行政処分、企業開示など、一定の手続きと法的効果を伴う情報である。
第三者が推論した分類値は、ウォレットラベル、犯罪関連スコア、ニュースセンチメント、企業分類、人物同定、ボット判定など、観測事実へ第三者が意味を付与した情報である。
この六つは、同じ確度でも、同じ鮮度でも、同じ訂正可能性でもない。
約定価格とウォレットラベルを同じ「入力値」として扱う設計は、数値処理としては成立しても、認識論として壊れている。
AIは、値だけを受け取ってはならない。
その値が観測なのか、集計なのか、推計なのか、法的確定なのか、第三者推論なのかを同時に受け取る必要がある。
原典と配信元は別物である
データの出所を確認するとき、多くのシステムは「どのAPIから取得したか」を記録する。しかし、それだけでは足りない。
APIの提供者は、データの生成者とは限らない。
ある価格指数をデータベンダーのAPIから取得したとしても、その指数を構成する価格は複数の取引所から取得されているかもしれない。あるニュースサイトの記事を取得しても、その本文は通信社の配信を転載したものかもしれない。あるウォレットラベルを複数サービスから取得しても、各社が同じ分析会社のデータを再利用している可能性がある。
従って、金融AIが記録すべきなのは配信元だけではない。
原典、一次記録者、再配信者、加工者、集計者、取得経路を分けて保存する必要がある。
あるデータについて、少なくとも次の問いへ答えられなければならない。
誰が最初に生成したのか。誰が外部へ配信したのか。途中で誰が加工したのか。どの計算規則が使われたのか。元データまで遡れるのか。途中の処理は監査可能なのか。
複数の情報源が同じ結果を返したとしても、同じ上流データを共有しているなら、それは独立した確認ではない。
五つの画面に同じ数字が表示されていても、背後の蛇口が一つなら、情報源は一つである。
金融データには複数の時計がある
金融AIにとって、時刻は一つではない。
ニュースが午前10時に起きた、と記録するだけでは不充分である。
現実の事象が発生した時刻。発表主体が公表した時刻。報道機関が配信した時刻。APIがレコードを生成した時刻。利用者のシステムが受信した時刻。データベースへ保存した時刻。モデルが読み込んだ時刻。注文を生成した時刻。取引所が注文を受理した時刻。約定した時刻。
これらは一致しない。
例えば企業が情報を公表してから、通信社が速報を出し、ニュースAPIへ反映され、金融AIが取得するまでには遅延がある。その遅延が数秒であっても、短期売買では因果関係を変える。
価格データにも、取引所のイベント時刻と利用者側の受信時刻がある。
通信遅延や処理詰まりが発生すれば、古いイベントが新しいイベントの後に届くことがある。システムが受信順に並べるだけなら、市場の時間を誤って再構成する。
日次データでも問題は消えない。
国や市場によってタイムゾーン、夏時間、営業日の区切り、日次集計の終了時刻が異なる。同じ「6月1日の出来高」でも、集計窓が同じとは限らない。
時計がずれれば、データが正しくても因果が壊れる。
ニュースによって価格が動いたのか、価格が動いた後にニュースが配信されたのか。AIが注文を出した後に市場が変化したのか、古いデータを読んで注文したのか。
この違いを判断するには、金融AIの全経路に複数の時刻を残す必要がある。
リアルタイムとは、正しいという意味ではない
データの鮮度は、「リアルタイムか遅延配信か」という二択では測れない。実際の遅延は、複数の区間に分かれている。
現実の事象が記録可能になるまでの生成遅延。記録から外部配信までの配信遅延。インターネットを通過するネットワーク遅延。収集システム内部の処理遅延。データベースへ書き込む保存遅延。モデルが入力を読み、判断する推論遅延。注文を送信する遅延。取引所が注文を処理する遅延。
最初のデータが速くても、後段が詰まれば判断は古くなる。反対に、慎重な検証を経たデータは正確でも、取引判断には間に合わないことがある。このため、必要な鮮度は利用目的によって変わる。
マーケットメイクと日次リバランスでは許容できる遅延が違う。秒単位の売買と規制対象確認でも違う。危機監視では、正確性だけでなく、データが途切れたという事実を早く把握することが重要になる。
金融AIは「最新値」を要求するのではなく、目的ごとに許容できる最大遅延を定義しなければならない。さらに、その遅延は平常時の平均値ではなく、急変時の分布として監視する必要がある。
市場が静かなときに20ミリ秒で届くデータが、市場急変時にも20ミリ秒で届く保証はない。必要な瞬間ほど供給網が混雑する。金融データの鮮度は、平常時ではなく負荷時に試される。
届いたデータは、完全なデータとは限らない
リアルタイムデータでは、パケット欠損、重複受信、順序逆転、一時切断、再接続後の取りこぼしが起こる。
注文板は特に壊れやすい。
多くの取引所は、ある時点のスナップショットと、その後の差分更新を組み合わせて配信する。差分が一件欠ければ、利用者側で構築している板は、以後ずっと実際の板と異なる状態になる。
通信自体は続いている。新しい更新も届いている。システムはエラーを出していない。
それでも板は壊れている。
これが、単なる接続監視だけではデータ品質を保証できない理由である。
連番、更新ID、チェックサム、スナップショットとの整合、再同期の履歴が必要になる。取引所の公式仕様が、板の再構築に連番確認やチェックサムを要求していること自体、到着したメッセージを並べるだけでは正しい市場状態を再現できないことを示している。
ゼロ値と欠損値の混同も危険である。
出来高がゼロなのか、出来高を取得できなかったのか。注文が存在しないのか、板データの一部が欠けているのか。取引停止によって価格が固定されているのか、配信が停止して古い価格が残っているのか。
数値だけを見れば同じでも、意味は異なる。
欠損を補完する場合には、どこから補完したかを記録しなければならない。前回値を維持したのか、別市場から取得したのか、補間したのか、モデルが推定したのか。
補完値を観測値として保存した瞬間、補完は捏造へ変わる。補完と捏造の境界は、値がもっともらしいかどうかではない。
推定された値を推定値として識別できるかどうかである。
APIが応答していても、意味は壊れうる
API障害は分かりやすい。
接続できない。認証に失敗する。タイムアウトする。エラーコードが返る。
より危険なのは、正常なレスポンスが返り続けているのに、中身の意味が変わっている状態である。
フィールド名が変更される。単位が変わる。小数精度が変わる。タイムスタンプが秒からミリ秒になる。シンボル表現が変わる。ページネーション方式が変わる。レート制限の計算方法が変わる。ある日付フィールドが満期日ではなく上場廃止日を示すようになる。
JSONとしては正しい。必須フィールドも存在する。型も合っている。
それでも金融AIは誤った意味を読み取る。
これがスキーマドリフトと意味ドリフトの違いである。
スキーマドリフトは、列、型、名前、構造の変化である。意味ドリフトは、形式が同じまま、値の定義や計算方法が変わることである。従って必要なのは、スキーマ検証だけではない。
契約テスト、値域監視、単位検証、時系列連続性、既知サンプルとの比較、ドキュメント差分、サンドボックス検証、シンボル定義の照合が必要になる。
APIの死活監視が確認するのは、データが届くかどうかだけである。
金融AIに必要なのは、昨日と同じ意味のデータが今日も届いているかという監視である。
銘柄コードは資産そのものではない
金融AIはシンボルを文字列として処理する。しかし、同じ文字列が同じ経済的対象を意味するとは限らない。
現物と先物。無期限先物と期限付き先物。米ドル建てとステーブルコイン建て。最終約定価格と指数価格。マーク価格と清算価格。ネイティブ資産とラップド資産。異なるチェーン上の同名トークン。移行前と移行後のトークン。
株式であっても、銘柄コード変更、株式分割、企業再編、上場廃止、再上場がある。先物には限月とロールがある。暗号資産にはチェーン分岐、ブリッジ、コントラクト移行がある。
二つのデータベースで同じシンボルが使われていても、経済的同一性は保証されない。
必要なのは、文字列の一致ではなく、資産同一性の管理である。
発行体、契約アドレス、チェーンID、市場区分、商品種別、建値資産、満期、決済方式、コントラクトサイズなどを含めた識別が必要になる。
銘柄マッピングの誤りは、派手な異常値を生むとは限らない。
別の商品であっても、価格帯が近ければ数値は自然に見える。だからこそ検知が難しい。AIは異常な数字には警戒できる。もっと危険なのは、正常に見える別の数字である。
「市場価格」という一つの値は存在しない
暗号資産市場では、取引所ごとに価格が異なる。
参加者、法域、流動性、入出金状態、決済資産、資本規制、取引手数料、信用リスクが異なるためである。
最終約定価格は、最後に成立した一件の取引価格でしかない。流動性が低ければ、市場全体を代表しない。
出来高加重平均価格は、取引量の多い市場を強く反映する。しかし、その出来高が自己取引や無料取引によって膨張していれば、重みそのものが歪む。
中央値は異常値へ強いが、流動性の差を捨てる。指数価格は複数市場を統合するが、採用市場、除外規則、更新頻度、異常値判定に依存する。マーク価格は清算の安定化を目的として設計され、実際に取引可能な価格とは限らない。オラクル価格も、参照市場、集計方式、更新閾値、ハートビートによって作られた判断用価格である。
どれが正しい価格なのか、という問いには答えがない。
先に定めるべきなのは、何のための価格かである。
評価用なのか。執行可能性を測るのか。証拠金計算なのか。清算判定なのか。市場全体の方向を測るのか。
金融AIは、価格という一つのフィールドを持つのではなく、価格の役割を持たなければならない。
単一取引所の最終約定価格を「市場価格」と呼んだ瞬間、AIは市場ではなく、その取引所の局所状態を全体だと誤認する。
注文板は流動性の約束ではない
注文板は、買いたい人と売りたい人の意思を可視化しているように見える。しかし、注文は約定ではない。
注文は取り消せる。瞬間的に出して消せる。見せ玉やスプーフィングによって、存在しない需給を演出できる。アイスバーグ注文や隠れ注文は板へ全量を表示しない。取引所によって配信する板の深さ、集約単位、内部注文の扱いも異なる。
板に大量の買い注文が見えても、その価格へ近付いた瞬間に消えるかもしれない。反対に、板が薄く見えても、隠れ流動性や即時に補充される注文が存在するかもしれない。従って注文板から推定できるのは、確定した執行可能流動性ではない。
その瞬間に外部へ表示された注文状態である。
板を流動性指標として利用するなら、注文の滞在時間、取消率、約定率、価格接近時の消失、更新頻度、板の復元完全性まで見る必要がある。
一枚のスナップショットは、意図の写真ではない。
高速で書き換えられる舞台装置の一コマである。
出来高が多くても、流動性が高いとは限らない
出来高は市場活動の代表的な指標として使われる。しかし、取引量の大きさと、実際に資金を動かせる能力は同じではない。
自己取引、ウォッシュトレード、マーケットメーカー内部の往復、無料取引キャンペーン、インセンティブ獲得を目的とした取引によって、出来高は膨張する。
現物とデリバティブを合算すれば、同じ経済的ポジションが重複して見えることもある。ドル換算レート、日次区切り、丸め処理が違えば、ベンダー間で集計値も変わる。
オンチェーン移動量と取引所出来高も別物である。
取引所内部の約定は、全てがブロックチェーン上へ記録されるわけではない。一方、オンチェーン上の大規模移動が、市場取引を意味するとも限らない。
流動性を測るなら、出来高だけでなく、スプレッド、板厚、価格インパクト、約定率、注文取消し、入出金状態、市場間裁定可能性を合わせて見る必要がある。
出来高は市場の鼓動に見える。だが、機械的に作られた振動まで脈拍として数えれば、診断は狂う。
オンチェーンで公開されるのは移動であり、意味ではない
ブロックチェーンは、取引履歴を公開する。その透明性は強力である。しかし、透明なのは記録であって、意図ではない。
外部所有アカウント、スマートコントラクト、取引所ホットウォレット、コールドウォレット、カストディ口座、ブリッジ、ミキサー、バッチ送金、ステーキングコントラクトは、それぞれ異なる意味を持つ。
一つの送金に見えても、内部では多数の顧客残高をまとめた処理かもしれない。大口送金が取引所へ向かったように見えても、同じ事業者の内部移動かもしれない。資産がバーンアドレスへ送られても、別チェーン上で同量が発行されるブリッジ処理かもしれない。
「大口送金が発生した。売却圧力が高まる」
この推論には、送金先が取引所であるというラベル、そのラベルが現在も正しいという前提、その送金が内部振替ではないという推定、実際に売却されるという行動予測が含まれている。
一つの観測値に、複数段階の推論が折り畳まれている。
金融AIは、オンチェーン生データ、アドレス分類、経済的解釈を分離しなければならない。
生データは比較的強い事実である。ウォレットラベルは第三者推論である。
その移動が市場へ与える意味は、さらにその上に置かれた仮説である。
ウォレットラベルは、チェーン上に刻まれていない
ブロックチェーン分析会社は、アドレスへ「取引所」「機関」「発行体」「犯罪関連」などのラベルを付与する。
その根拠には、公開情報、既知の入出金、クラスタリング、複数入力ヒューリスティック、取引パターン、事業者から提供された情報などが使われる。
だが、ラベルはブロックチェーンのコンセンサスによって確定した事実ではない。
新しい情報によって更新される。共有アドレスやカストディ構造によって誤分類される。プライバシー技術、チェーン間移動、スマートコントラクトによって帰属が曖昧になる。
「犯罪関連」という分析上のラベルと、裁判所や行政機関による法的認定も同じではない。
金融AIがラベルを利用する場合、ラベル名だけでなく、付与主体、根拠、作成時刻、更新時刻、確信度、法的状態を持たせる必要がある。
現在のラベルを過去の取引へ遡及適用すれば、バックテストに未来の知識が混入する。
後から判明した取引所アドレスを、当時から識別できていたものとして扱うなら、そのAIは過去を予測しているのではない。
現在の知識で書き換えられた過去を読んでいる。
ニュースは同じURLのまま変化する
金融AIがニュースを利用するとき、見出し、本文、配信時刻、更新時刻、訂正状態を分ける必要がある。
速報記事は、最初の配信後に更新される。見出しが変わる。本文へ背景説明が追加される。誤りが訂正される。匿名情報源の表現が確定情報へ変わることもある。
同じURLだから、同じ記事とは限らない。
金融AIが午前10時に読んだ文章と、人間が午後3時に同じURLを開いて読む文章が違う可能性がある。このとき、URLだけを保存しても判断は再現できない。必要なのは、AIが実際に読んだ本文、見出し、メタデータ、取得時刻、コンテンツハッシュである。
翻訳や要約も独立した加工として保存すべきである。原文が正しくても翻訳が誤ることがある。否定、条件、皮肉、仮定、引用関係が要約によって失われることもある。
市場向けヘッドラインは速度を優先する。詳細記事は文脈を補う。公式発表は法的に慎重だが読解に時間がかかる。
最も速い情報と、最も正確な情報は一致しない。
金融AIは、その不一致を一つのスコアへ潰すのではなく、速報性と確度を別々に扱う必要がある。
SNSの投稿数は事実の票数ではない
SNSでは、同じ情報が短時間に大量複製される。しかし、投稿数が多いことは、独立した確認が多いことを意味しない。
一つの未確認投稿を、ボット、まとめアカウント、自動翻訳、生成AI、ニュース転載サイトが複製すれば、検索結果には多数の情報源が存在するように見える。
そこへ生成AIの要約が加わる。
最初の誤情報をAIが要約し、その要約を別サイトが掲載し、別のAIが二次情報を参照する。複数の文章が生まれるため、表面的には独立した情報に見える。
だが、情報系統を遡れば根は一つである。
複数ソースの一致を評価するときは、文章の数ではなく、原典の数を数えなければならない。
SNSデータでは、投稿者の本人性、アカウント作成時期、過去の挙動、公式性、削除履歴、引用関係、元映像の撮影時刻、再利用の有無も重要になる。
公式アカウントであっても、乗っ取られる可能性はある。動画であっても、現在の出来事とは限らない。音声であっても、本人の発言とは限らない。
AI時代に増えるのは、情報量だけではない。
同じ誤りが独立した多数意見へ擬態する能力である。
公的統計は正確だが、最初から完成しているわけではない
政府、中央銀行、統計機関のデータは、一般に高い信頼性を持つ。しかし、速報値、改定値、確報値を区別しなければならない。
経済統計は、限られたサンプルや初期報告を使って早期に公表され、その後に情報が増えることで改定される。季節調整方法、基準年、分類、サンプル、推計手法が変更されることもある。
現在取得できる履歴系列には、過去の改定が反映されている。その系列をそのままバックテストへ使えば、当時の市場参加者が知り得なかった確報値を、過去のAIへ与えることになる。
リアルタイムデータセットが重要なのは、このためである。
必要なのは「2020年4月の値」だけではない。
「2020年5月1日時点で公表されていた、2020年4月の値」である。
データには対象期間だけでなく、知識として利用可能になった時点がある。金融AIのバックテストは、過去の経済を再現するだけでは足りない。過去の情報環境を再現しなければならない。
規制・制裁情報は文字列一致では処理できない
規制遵守に利用されるデータには、制裁対象者、法人、関連会社、実質的支配者、ウォレットアドレス、法域、ライセンス、例外、期限、執行措置、KYC情報などがある。
これらは単純な名前検索では処理できない。
人物名には別名、旧名、通称、翻字差がある。法人は再編され、子会社や持株会社を持つ。直接掲載されていない企業でも、制裁対象者による所有や支配のため規制対象となる場合がある。
同じ名前を持つ別人もいる。ウォレットアドレスが追加されることもあれば、法的状態が変更されることもある。従って金融AIは、どの時点の、どの法域の、どの版のリストを使ったかを保存しなければならない。
後から更新された制裁リストで過去の判断を再評価することはできる。しかし、その更新後の情報で過去の判断履歴を上書きしてはならない。当時のAIが何を知っていたかと、現在ならどう判断するかは別の記録である。
複数ソース照合は多数決ではない
三つのソースが同じ値を返し、一つだけ異なる値を返したとする。多数決なら、三つの値を採用する。しかし、三つのソースが同じデータベンダーから再配信を受け、残る一つだけが独自に取得した一次データである可能性がある。
その場合、多数派は一つの誤りを三回数えているだけである。複数ソース照合では、ソース数より独立性が重要になる。
価格データなら、別の取引所、別の法域、別の決済資産、別の収集経路を持つか。ニュースなら、独自取材なのか、同じ公式発表の転載なのか。オンチェーンなら、別々のノードから生データを取得しているのか、同じラベリングサービスを共有しているのか。
規制情報なら、公的原典と、その再配信サイトを独立した二票として数えてはならない。
評価すべき属性は、原典までの距離、更新頻度、過去の誤り率、訂正速度、生成方法、法的責任、タイムスタンプ精度、障害相関、上流依存である。
複数契約を持つことと、複数の独立した観測経路を持つことは同じではない。
冗長性は、会社名の数ではなく、故障原因の共有範囲で測らなければならない。
バックテストは、清掃された過去を見ている
履歴データは、本番データより美しい。
欠損が補完されている。重複が除去されている。異常値が修正されている。銘柄コードが統一されている。訂正後の統計が反映されている。後から判明したウォレットラベルが付与されている。
破綻した取引所や上場廃止銘柄がデータセットから消えている場合もある。板情報は保存されず、約定データだけが残る。ニュースは更新後の本文へ置き換わる。API障害期間は別ソースで補完される。
この履歴で学習したモデルは、実運用時には存在しない世界を経験している。
本番では、データは遅れる。抜ける。順序が変わる。訂正される。API制限に達する。取引所が停止する。板の一部しか取得できない。ニュースの真偽が確定しない。
バックテストと本番の差は、スリッページや手数料だけではない。
情報が完成しているかどうかという差である。
高性能なバックテスト結果は、モデルが市場を理解した証拠とは限らない。過去データの編集工程を学習した結果かもしれない。
金融AIの評価には、当時取得可能だったデータ、当時のAPI制限、当時の銘柄定義、当時のニュース本文、当時のラベル、当時の統計値を再現するpoint-in-timeデータが必要になる。
データリーケージは、未来の日付だけから来るのではない
ルックアヘッド・バイアスは、未来の価格を訓練データへ混ぜるような露骨な形だけではない。
訂正済み統計を使う。将来判明したウォレットラベルを使う。最終的な企業分類を過去へ適用する。生存銘柄だけを残す。全期間の平均と標準偏差で過去データを正規化する。記事の初回公開時刻ではなく更新時刻を使う。日次終値を、その日の取引時間中から利用できたものとして扱う。
これらも未来情報である。
データセットの列に未来という名前が書かれていなくても、構築工程に未来の知識が入っていればリーケージになる。
金融AIの性能は、モデルの学習段階より前に、データセットを作る段階で過大評価され得る。
モデル評価を疑うなら、モデルのコードだけでなく、データがいつ、どの版から、どの処理で作られたかを監査する必要がある。
異常値を消すと、本物の危機まで消える
データ品質処理では、外れ値除去が行われる。通常のセンサーや業務データなら、極端な値は測定ミスであることが多い。金融市場では、極端な値が本物の出来事である場合がある。
価格急落、流動性消失、スプレッド拡大、出来高急増は、誤配信かもしれない。しかし、市場危機そのものかもしれない。
過去分布から離れているという理由だけで削除すれば、金融AIは最も重要な局面を失う。一方、全てを本物として受け入れれば、誤配信や市場操作に反応する。従って異常値処理は、削除ではなく分類であるべきだ。
値域異常、ソース間乖離、板との不整合、出来高不足、配信遅延、他市場への伝播、ニュースとの時間関係を使い、観測へ異常度と確信度を付与する。
「正常値」と「削除値」の二択では足りない。
金融AIには、異常だが本物かもしれない観測を保持する能力が必要になる。
データポイズニングは、モデルの外側から始まる
金融AIを誤作動させるために、モデル自体へ侵入する必要はない。
入力を歪めればよい。
低流動性市場で価格を動かす。見せ玉で注文板を厚く見せる。自己取引で出来高を膨らませる。SNSボットでセンチメントを作る。偽ニュースを複数サイトへ複製する。偽トークンを正規資産に見せる。オラクルの参照市場を操作する。
さらに、DNS改ざん、偽エンドポイント、中間者攻撃、レスポンス改ざん、時刻サーバー攻撃、ログ改ざん、内部不正、依存ライブラリへの侵入によって、データ経路そのものを変えることもできる。
金融データでは、機密性より完全性と真正性が重要になる場面がある。
価格が第三者に見られても、それだけで判断が壊れるとは限らない。価格が一桁書き換えられれば、判断は壊れる。
攻撃と偶発障害を即時に完全判別することは難しい。だから設計上は、原因が不明でも、異常な供給経路から来たデータの信頼度を下げられる必要がある。
「攻撃だと証明できるまで通常値として扱う」という設計は、証明が終わる前に注文を出す。
代替データが届いても、観測は継続していないかもしれない
主要データソースが停止した場合、別取引所、別ベンダー、指数価格、先物価格、オンチェーン価格、直近値、推定値などへ切り替えることができる。しかし、可用性が回復したことと、同じ観測が継続できたことは別である。
現物価格の代わりに先物価格を使えば、金利、期限、需給、資金調達率の影響が加わる。米ドル建ての代わりにステーブルコイン建てを使えば、ステーブルコイン自体の信用と価格差が入る。
取引所価格の代わりに指数価格を使えば、局所市場の状態ではなく複数市場の集計になる。一次発表の代わりに報道要約を使えば、情報の粒度と法的表現が変わる。生のオンチェーン記録の代わりに分析会社の推定値を使えば、第三者の分類ロジックが加わる。
値が途切れなかったからといって、同じ時系列とは限らない。
フォールバックには、「代替先へ切り替えた」という状態だけでなく、観測対象がどう変わったかを記録する必要がある。
連続したグラフの内部で意味が切り替わっているなら、そのグラフは数値として連続でも、概念として不連続である。
保存できなければ、説明も再現もできない
金融AIの説明可能性は、モデルがどの特徴量を重視したかだけでは成立しない。その特徴量が、どのデータから作られたかを説明できなければならない。
保存すべきものには、生のAPIレスポンス、正規化後データ、特徴量、注文板スナップショット、ニュース本文、設定、モデルバージョン、コードバージョン、依存ライブラリ、時刻同期状態、品質フラグ、判断結果、注文、約定、エラー、人間介入が含まれる。
特に重要なのは、その瞬間に実際に見えていたデータである。後から取得した同じ時刻のデータではない。後から訂正された値でもない。
モデルのバージョンとコードが残っていても、入力スナップショットがなければ判断は再現できない。入力が残っていても、正規化ルールやシンボル対応表が残っていなければ同じ特徴量を作れない。
保存にはコストがかかる。
注文板やニュース本文を長期間保存すれば容量が増える。個人情報、著作権、契約上の保持制限もある。市場データには、リアルタイム利用、履歴保存、再配布、派生データ、モデル学習、監査用保存を別々に制限する契約が存在する。
技術的に取得できることと、法的に保存・学習・再配布できることは同じではない。
オープンソースのコードが公開されていても、入力データを共有できなければ、実行結果まで完全に再現できるとは限らない。
金融AIの再現可能性は、コードライセンスだけでなく、データライセンスによっても制限される。
訂正された事実で、過去の判断を上書きしてはならない
ニュース、経済統計、企業開示、ウォレットラベルは後から訂正される。そのとき、データベースの古い値を新しい値へ置き換えるだけでは、監査履歴が失われる。必要なのは、初回値、訂正値、訂正時刻、訂正理由を別々に保存することである。
AIが初回値を見て判断したなら、その判断は当時の情報環境では合理的だった可能性がある。訂正後の情報を用いて再評価すれば、異なる判断になるかもしれない。
二つの判断は矛盾しない。知識状態が違うからである。
過去判断の検証では、「現在の正しい情報ならどう判断するか」ではなく、「当時利用可能だった情報から、どのように判断したか」を再現する必要がある。
訂正は過去を消す作業ではない。情報が変化した履歴を追加する作業である。
金融AIは値ではなく、観測オブジェクトを受け取るべきである
一般的なモデル入力では、価格、出来高、センチメント、統計値が数値配列として渡される。この形式では、データの出所も、鮮度も、確度も失われる。
金融AIが受け取る単位は、単なる値ではなく、次のような属性を持つ観測オブジェクトであるべきだ。
Value は値そのもの。
Origin は最初の生成主体。
Distributor は実際に取得した配信元。
EventTime は対象事象の発生時刻。
PublishTime は外部公表時刻。
IngestTime は受信時刻。
ProcessTime は変換や正規化を終えた時刻。
SchemaVersion はデータ仕様。
CorrectionState は速報、訂正、確報などの状態。
Freshness は現在時刻から見た鮮度。
Confidence は内容の信頼度。
Independence は他ソースからの独立性。
MissingState は欠損や補完の状態。
LicenseClass は保存・学習・再配布の利用条件。
FallbackState は通常ソースか代替ソースか。
この属性を持たせれば、AIは「価格が100である」とだけ認識するのではなく、「三秒前に生成され、二つの独立市場で確認され、現在は速報状態で、代替ソースではなく、欠損補完もされていない価格が100である」と認識できる。
市場は不確実なのだから、入力から不確実性を消すべきではない。不確実性を消してからモデルへ渡すと、モデルは確信に満ちた誤判断を行う。
データ品質は一つの点数では測れない
データ品質には複数の軸がある。
完全性は、必要なデータが欠けずに存在するか。
正確性は、現実または原典と一致するか。
一貫性は、別システムや別時点と矛盾しないか。
一意性は、同じレコードが重複していないか。
鮮度は、生成からどれほど時間が経過しているか。
適時性は、利用目的へ間に合っているか。
妥当性は、型、範囲、単位、業務規則を満たすか。
来歴完全性は、生成から利用までの経路を追跡できるか。
再現可能性は、後から同じ入力と処理を再構成できるか。
可用性は、必要な時点で取得できるか。
これらは互いに代替できない。
完全だが古いデータ。新しいが誤っているデータ。正確だが保存できないデータ。複数ソースで一致するが上流が同じデータ。一つの総合点へまとめれば、どこが壊れているか分からなくなる。
運用では、欠損率、重複率、異常値率、訂正回数、配信遅延、スキーマ変更回数、ソース間乖離、板の不整合、データ到着率、フォールバック回数、再現成功率、ベンダー集中度などを個別に監視する必要がある。
データ品質は成績表ではない。故障箇所を特定する計器盤である。
モデル性能の低下とデータ品質の低下を分離する
金融AIの成績が悪化したとき、すぐにモデルを再学習するのは危険である。入力データが壊れているなら、壊れたデータへ適応することになる。まず、モデル劣化とデータ劣化を分離しなければならない。
データ品質モニタリングでは、欠損、遅延、分布変化、ソース別障害率、スキーマ変化を監視する。
モデル性能モニタリングでは、予測誤差、判断精度、キャリブレーション、損失分布を監視する。
同じ入力を固定して旧モデルと新モデルへ与える入力固定テスト。別のデータ経路を並行取得するシャドーフィード。単純な規則型モデルとの比較。履歴スナップショットによる再現テスト。
これらを使えば、入力が同じなのに判断が変わったのか、モデルは同じなのに入力が変わったのかを切り分けられる。
市場環境の変化も区別が必要である。
入力分布が変わるデータドリフト。入力と結果の関係が変わる概念ドリフト。API形式が変わるスキーマドリフト。
三つは別の問題であり、同じ再学習では解決できない。
取引時間、規制、手数料、ETF、ステーブルコイン構成、参加者、ボット比率、裁定経路が変われば、同じ特徴量でも意味が変わる。
モデルが忘れたのではない。市場の文法が変わった可能性がある。
データ起因障害のフォールトツリー
金融AIが誤った注文、誤った停止、誤った危機判定を行うという上位事象を置く。その下には、少なくとも次の経路がある。
元データ自体が誤っている。元データの意味を誤認している。データが古い。一部が欠けている。重複している。順序が逆転している。複数ソースが同じ原因で障害を起こしている。API仕様変更を検知していない。タイムスタンプがずれている。通貨換算、小数点、銘柄対応、集計窓の変換を誤っている。
第三者推論を一次事実として扱っている。訂正前と訂正後を混同している。バックテストと本番で異なるデータを使っている。悪意ある操作を受けている。代替データへの切り替えによって観測対象が変わっている。
これらは単独でも起こるが、連鎖もする。
API仕様が変わり、単位を誤認し、異常値除去が働き、欠損補完によって自然な系列へ修正され、モデルが正常な入力として受け取る。
最初の変化は小さくても、品質処理が誤りを隠すことで、最終判断は強い確信を持つ。
フォールトツリーの目的は、全ての障害を予測することではない。モデルが壊れた状態と、市場を観測できなくなった状態を区別することである。
データ供給網には信頼境界がある
金融AIの全経路を一つの信頼領域として扱ってはならない。
取引所内部、公開API、データベンダー、インターネット経路、収集サーバー、正規化処理、データベース、特徴量生成、モデル、注文生成、注文API、監査ログ。
各地点で、検証できるものと検証できないものが違う。
利用者は、取引所内部のマッチングエンジンが正しく動作したかを直接検証できない。公開APIの連番や署名は検証できても、内部記録との完全一致までは確認できない。
インターネット経路では、TLS証明書や署名を確認できる。収集サーバーでは、受信時刻、ハッシュ、重複を確認できる。正規化処理では、変換規則と入力出力の対応を検証できる。
監査ログを保存しても、そのログを書き換えられる権限が同じ管理者へ集中していれば、完全な証明にはならない。
各境界では、「信頼している」という事実そのものを明示する必要がある。
検証できないものを、検証済みとして扱わない。金融AIの安全性は、全てを信用しないことではない。
どこから先を、何を根拠に信用しているかを記録することである。
小規模なOSSプロジェクトでも、最低限の防衛線は引ける
大規模金融機関は、複数データセンター、複数ベンダー、専用回線、監査部門、コンプライアンス部門を持てる。個人開発や小規模OSSプロジェクトが、同じ冗長性を構築することは現実的ではない。しかし、規模が小さいことは、データ来歴を放棄する理由にはならない。
最低限必要なのは、生レスポンスの保存、受信時刻の記録、スキーマバージョン管理、銘柄対応表の履歴、欠損・重複・遅延フラグ、正規化前後の対応、モデル判断との紐付けである。
複数ソースを持てない場合でも、単一ソースであることを明示できる。完全な板を保存できない場合でも、保存していないことを判断ログへ残せる。ニュース本文を契約上保存できない場合でも、取得時刻、見出し、ハッシュ、配信元、記事IDを残せる可能性がある。
重要なのは、存在しない冗長性を装わないことだ。
個人開発で維持できない高度な仕組みを形式だけ導入し、監視されない設定や壊れた代替経路を増やせば、複雑性が新しい障害源になる。
冗長性は多いほどよいのではない。保守でき、独立性を説明でき、障害時の意味変化を追跡できる範囲で持つべきである。
bitBuyerが学習すべきなのは、市場だけではない
bitBuyerのように自律的に学習し、判断する金融AIにとって、データ供給網は周辺機能ではない。
学習対象の一部である。
取引所ごとに価格、板、出来高の性質が違う。取得時刻と市場時刻が違う。ニュースには確度があり、オンチェーンラベルには推論が含まれる。APIは変化し、フォールバックは観測対象を変える。
この状態で、全ての入力を同じ確度の事実として学習させれば、AIは市場構造だけでなく、データ供給網の癖や誤りまで学習する。
ある取引所の遅延を価格予兆として覚えるかもしれない。特定ベンダーの訂正傾向を市場変化として覚えるかもしれない。欠損補完によって生じた滑らかな系列を、現実の価格形成だと理解するかもしれない。
bitBuyerへ必要なのは、「信頼できるデータだけを使う」という単純な選別ではない。どの程度信頼できるのかを、学習と判断へ組み込む構造である。
信頼度が低いデータから強く学習しない。補完値を観測値と同じ重みで扱わない。独立性の低い複数ソースを多数決へ使わない。データ障害と市場急変を、値の大きさだけで区別しない。
判断ログには、モデルバージョンだけでなく、その瞬間に使ったデータ、品質状態、フォールバック状態、時刻同期状態を残す。
観測品質が低下したなら、「価格は取得できている」と表示するのではなく、「価格は取得できているが、市場を通常時と同じ精度では観測できていない」と表現する。
金融AIの自律性とは、常に判断を出す能力ではない。自分が何を見られていないかを、判断へ含める能力である。
説明可能性は、モデルの内側だけには存在しない
金融AIが「なぜこの注文を出したのか」と問われたとき、モデルは特徴量や重みを説明できるかもしれない。しかし、特徴量の元になった価格が三秒遅れていたならどうか。
注文板が一件欠けた状態で再構築されていたならどうか。ニュース本文が後から訂正されていたならどうか。ウォレットラベルが当時は未確認だったならどうか。三つの情報源が同じ上流データを共有していたならどうか。
この場合、モデルの説明だけでは判断を説明したことにならない。必要なのは、データ来歴の説明である。どの原典から、どの配信元を通り、いつ取得され、どの変換を受け、どの欠損処理が行われ、どの版のモデルへ渡されたのか。
説明可能性は、モデルの内部構造から始まるのではない。現実がデータへ変換された地点から始まる。
市場が見えなくなったとき、壊れているのは誰か
金融AIは、市場より速く判断するために作られる。しかし、その速さが増すほど、データ供給網の小さな歪みは大きな意味を持つ。
遅延した価格。欠けた板。訂正前の統計。古いニュース。誤った銘柄対応。独立していない複数ソース。推論を事実へ変えたウォレットラベル。意味の変わったAPI。観測対象を変えてしまったフォールバック。
モデルは、これらを与えられた通りに処理する。
入力が壊れていることを知らなければ、誤った判断を、正常な計算として出力する。だから金融AIの信頼性を問うとき、最初に見るべきものはモデルの精度ではない。
そのAIが何を市場だと思っているかである。
金融AIが見ているものは、市場そのものなのか。それとも、市場について誰かが生成し、加工し、配信した記録なのか。データが届いたというだけで、その記録を事実と呼んでよいのか。
そして、モデルが壊れていなくても、市場を正しく観測できなくなったとき、その金融AIはまだ正常に動いていると言えるのだろうか。
