金融AIは、いつ動くかではなく、いつ止まるかまで設計されなければならない

金融AIの性能は、長い間、平時の成績で語られてきた。過去データを与え、売買ルールを検証し、損益曲線を描き、ドローダウンを測り、シャープレシオを並べる。そこでは、AIは市場を読む装置として扱われる。より早く、より細かく、より大量の情報を処理し、人間より優れた判断を下すことが期待される。

しかし、金融システムにおいて本当に危険なのは、AIが平時に負けることではない。本当に危険なのは、平時に勝っていたAIが、危機時にも同じ顔で動き続けることである。

戦争、制裁、流動性枯渇、取引所停止、API障害、ステーブルコインのペッグ乖離、ニュース誤報、クラウド障害、清算連鎖、規制変更。これらは単なる価格変動ではない。市場の意味が変わる瞬間である。過去データの中で有効だったシグナルが、別のレジームでは全く別の意味を持ちうる。

だから、金融AIの安全性は、平時にどれだけ利益を出したかだけでは測れない。むしろ問うべきなのは、次である。そのAIは、どの市場状態では動き続けてよいのか。どの市場状態では取引量を落とすべきなのか。どの市場状態では新規注文を止めるべきなのか。どの市場状態では観測だけに切り替えるべきなのか。どの市場状態では完全停止すべきなのか。そして、停止した後、何を確認すれば再開してよいのか。

これが、本稿で扱う危機時レジーム管理である。

本稿は、bitBuyer Projectの第六記事として、金融AIを“予測する知能”ではなく、“自分の行動可能性を制限できる運用システム”として扱う。前段では、ESMA、SEC、MiFID II、RTS 6、BOE、IOSCO、BIS、FSB、主要取引所、AIリスク管理、ステーブルコイン、DeFi、清算連鎖、障害対応の論点を整理した。本稿はそれを、数年後にも読みやすい構造論として再構成する。

なお、本稿は投資助言ではない。価格予測でも、特定売買戦略の推奨でも、特定取引所や特定AIモデルの評価でもない。扱うのは、危機時に金融AIがどのように止まり、どこまで動き、何を残し、どう再開するかである。

バックテストは未来の保証ではない

バックテストは必要である。しかし、バックテストは万能ではない。

それは未来の利益を保証する装置ではなく、過去に存在した市場状態の中で、ある仕組みがどのように振る舞ったかを調べる検査である。過去に存在しなかった危機、過去に充分なサンプルがない危機、市場構造が変わった後の危機、データ供給網が壊れた危機、取引所が止まった危機までは保証しない。

平時のバックテストでは、流動性が連続して存在しているように見える。スプレッドは平均化され、板の薄さは単純化され、API障害は存在しなかったものとして扱われやすい。注文拒否、約定遅延、レート制限変更、WebSocket切断、残高取得不能、入出金停止も、通常の価格系列には充分に反映されない。

取引手数料やスリッページも、単純な定数として処理されがちである。ニュース誤報、データ欠損、ステーブルコイン償還停止、清算エンジンの過負荷、オンチェーン混雑、データベンダーの誤配信は、平時の価格データからは見えにくい。

金融AIが危機時に壊れる理由は、予測力が足りないからだけではない。検査していた世界と、本番で遭遇した世界が別物になるからである。

従って、バックテストの役割は、“このAIは将来も勝てる”と証明することではない。むしろ、“通常想定される範囲ではどこまで壊れにくいか”を調べることである。そこから先は、バックテストではなく、レジーム管理、ストレステスト、シナリオ分析、停止条件、再開条件、ログ、事後レビューの領域になる。

金融AIに必要なのは、過去の市場に適応した証拠だけではない。過去の市場とは違う状態に入ったとき、自分の行動を縮退できる構造である。

レジームとは価格変動率ではない

危機時レジーム管理で最初に必要なのは、レジームの定義である。

ここで扱うレジームは、単なる価格変動率ではない。大きく上がったか、大きく下がったかだけでは、金融AIに充分な判断材料を与えない。

市場レジームとは、価格、出来高、流動性、スプレッド、板厚、約定可能性、注文拒否率、APIエラー率、データ欠損率、ニュース密度、制裁・規制発表、オンチェーン混雑、ステーブルコイン乖離、取引所入出金状態、清算量、資金調達率、クロスアセット相関の変化を含む複合状態である。

通常市場、高ボラティリティ市場、低流動性市場、急落市場、急騰市場、スプレッド拡大市場、板消失市場、ニュース集中市場、週末・祝日・時間外市場、地政学ショック市場、戦争・制裁市場、中央銀行イベント市場、ステーブルコインペッグ不安市場、取引所障害市場、API不安定市場、オンチェーン混雑市場、清算連鎖市場、相関崩壊市場、クロスアセット断絶市場、市場停止市場、データ不確実性市場。これらは、同じ“価格が動いた”という表面の下にある、別々の状態である。

価格が下がったから売る。価格が上がったから買う。ボラティリティが上がったから取引を増やす。そうした単純な反応は、危機時には危うい。

価格は動いているが流動性が残っている場合と、価格は動いているが板が消えている場合では、同じ注文でも市場インパクトが違う。価格は正しそうに見えるが、実は特定取引所のデータだけが壊れている場合もある。ステーブルコイン建て価格だけが歪み、法定通貨建て価格とは別の世界を映している場合もある。

だから、金融AIは価格系列だけを見るのではなく、市場状態を読む必要がある。価格は市場の表情である。レジームは市場の身体状態である。

危機時シグナルは単独で見ない

金融AIが危機を検知するとき、単一シグナルで断定すべきではない。急落だけで危機とは限らない。出来高急増だけで危機とは限らない。スプレッド拡大だけで危機とは限らない。APIエラーだけで市場危機とは限らない。ステーブルコインの小幅乖離だけで構造的危機とは限らない。

必要なのは、複数シグナルの組み合わせである。

市場シグナルとしては、急激な価格変動、実現ボラティリティ上昇、インプライド・ボラティリティ上昇、出来高急増、出来高急減、板厚低下、スプレッド拡大、市場間価格乖離がある。レバレッジ・担保シグナルとしては、オープンインタレスト急増、オープンインタレスト急減、資金調達率の極端化、清算量急増、証拠金維持率悪化、担保価値低下がある。

配管シグナルとしては、ステーブルコイン乖離、ステーブルコイン取引所流入出、償還停止、入出金停止、オンチェーン手数料上昇、ブリッジ停止、オラクル更新遅延がある。接続シグナルとしては、APIエラー率上昇、注文拒否率上昇、約定遅延、WebSocket切断、REST API制限、レート制限変更、残高取得不能がある。情報シグナルとしては、ニュース速報密度上昇、複数情報源の不一致、公式アカウントの異常投稿、規制発表、制裁発表、報道訂正、SNS上の偽画像・偽動画拡散がある。

危機とは、価格だけの事象ではない。市場、データ、取引所、情報、担保、法域、決済、オンチェーン環境が同時に歪む状態である。金融AIのレジーム判定は、その歪みの束を見る必要がある。

市場が壊れたのか、観測器が壊れたのか

金融AIが止まる前に、まず分けなければならないものがある。市場が壊れているのか。データが壊れているのか。取引所が壊れているのか。APIが壊れているのか。ニュースが壊れているのか。それとも、本当にレジームが変わったのか。

この切り分けを誤ると、AIは逆方向に壊れる。市場が本当に崩れているのに、単なるデータ異常だと判断すれば、危険な取引を続ける。逆に、データベンダーや特定APIだけが誤った値を返しているのに、市場全体の危機だと判断すれば、不要な停止や誤ったポジション解消を行う。

危機時の金融AIは、まず診断しなければならない。価格急変か。単一取引所の異常値か。データベンダー障害か。WebSocket切断か。REST API遅延か。注文板が薄いだけか。ステーブルコイン建値だけが歪んでいるのか。指数価格が壊れているのか。現物と先物のどちらが歪んでいるのか。ニュース誤報による一時反応か。オンチェーン混雑による送金遅延か。入出金停止による会場間価格乖離か。本物のレジーム変化か。

市場危機と観測危機は違う。市場が壊れているとき、AIは取引行動を縮退する必要がある。観測器が壊れているとき、AIは判断そのものを保留する必要がある。取引所が壊れているとき、AIは会場単位の停止を検討する必要がある。ニュースが壊れているとき、AIは情報確認待ちモードへ落ちる必要がある。

危機時の第一動作は、速く売ることでも、速く買うことでもない。何が壊れているのかを分けることである。

停止か継続かではなく、縮退運転で考える

危機時の金融AIは、動くか止まるかの二択で設計すべきではない。

現実の市場は、全停止だけで処理できるほど単純ではない。新規注文は止めるべきだが、既存ポジションのヘッジは許可すべき場面がある。成行注文は危険だが、指値注文だけなら許可できる場面がある。特定取引所は止めるべきだが、別会場の観測は続けるべき場面がある。デリバティブは止めるべきだが、現物の残高確認は続けるべき場面がある。

そのため、レジーム管理は段階的でなければならない。

通常運転、取引量縮小、新規ポジション停止、ポジション追加停止、レバレッジ削減、成行注文停止、指値注文のみ許可、低流動性ペア停止、特定取引所停止、特定資産停止、デリバティブ停止、ステーブルコイン建て取引停止、ヘッジのみ許可、ポジション解消のみ許可、観測のみモード、人間承認必須モード、完全停止、再開待機。この階段を持たないAIは、危機時に両極端へ振れる。危険なまま動き続けるか、必要な監視まで止めてしまうかである。

危機時の金融AIに必要なのは、停止ボタンだけではない。縮退運転の設計図である。

Pre-trade controls：注文前に止める

危機時レジーム管理の中核は、注文が市場へ出る前に止めることである。

注文後のキャンセルでは遅い場合がある。高速な市場では、誤った注文はすでに約定し、板を動かし、他者のアルゴリズムを反応させる。だから、pre-trade controlsは危機時の防火扉になる。

必要なのは、注文サイズ上限、価格乖離上限、注文頻度上限、レバレッジ上限、ポジション上限、損失上限、資産別エクスポージャー上限、取引所別エクスポージャー上限、ステーブルコイン別エクスポージャー上限、流動性に対する注文サイズ制限、スプレッド拡大時の注文禁止、板厚不足時の注文禁止、急変時の注文禁止、データ信頼度低下時の注文禁止、規制・制裁対象確認、銘柄誤認防止、価格単位誤認防止、小数点誤り防止、重複注文防止である。

暗号資産市場では、この考え方はさらに重要になる。暗号市場は24時間365日動き、複数会場に分散し、API仕様が取引所ごとに異なる。ステーブルコイン建て価格が市場配管として組み込まれ、入出金停止やオンチェーン混雑が価格乖離を作る。さらに、法定通貨建て市場、ステーブルコイン建て市場、先物市場、DeFi市場が同時に歪む場合もある。

注文前制御は、金融AIの安全帯である。それは収益機会を削るためではない。AIが自分の誤作動を市場へ輸出しないためにある。

Hard blockとsoft block

全ての異常を同じように止める必要はない。危機時制御には、hard blockとsoft blockの区別が要る。

hard blockは、条件を満たした場合に自動的に注文を拒否する制御である。AIや人間が気分で突破してよいものではない。例えば、法令違反、制裁対象、銘柄誤認、価格単位誤り、注文サイズ上限超過、資本上限超過、データ不整合、重複注文、異常な成行注文、API応答欠落時の注文送信などはhard blockに向いている。

soft blockは、完全停止の前段階である。警告、確認、追加承認、取引量縮小、人間確認、再入力要求などを通じて、危険の接近を知らせる。例えば、スプレッド拡大、出来高急減、ニュース密度上昇、ステーブルコイン小幅乖離、APIエラー率上昇、注文拒否率増加、複数データソースの軽微な不一致などはsoft blockに向いている。

ここで重要なのは、hard blockを増やせば安全になるとは限らないことである。hard blockが厳しすぎると、必要なヘッジまで止まる。soft blockが多すぎると、人間の監督者が疲弊する。警告が鳴り続ける環境では、警告は背景音になる。

だから、block条件は単に多ければよいのではない。どの条件は絶対に止めるのか。どの条件は警告に留めるのか。どの条件は取引量を落とすのか。どの条件は人間承認へ渡すのか。どの条件はログだけ残すのか。ここを決めることが、金融AIの危機時人格ではなく、危機時運用設計である。

Kill switchは全停止ボタンではない

kill switchという言葉は、しばしば“全部止めるボタン”として理解される。しかし、金融AIにおけるkill switchは、それほど雑な装置であってはならない。危機時に止めるべきものと、残すべきものがあるからである。

止めるべきものは、新規注文、成行注文、レバレッジ追加、低流動性ペア、異常な取引所、デリバティブ、ステーブルコイン建て取引、モデル推論、APIキー、戦略単位の注文生成かもしれない。残すべきものは、価格観測、残高確認、未約定注文確認、約定ログ取得、ポジション監視、リスク計算、通知、ログ保存、ダッシュボード更新かもしれない。

危機時に全てを止めると、AIは安全になるどころか盲目になる。注文を止めても、観測は続けなければならない。モデル推論を止めても、ポジションは監視しなければならない。取引所APIの注文権限を止めても、残高取得権限は残すべき場合がある。未約定注文は取消すべきかもしれないが、ヘッジ注文だけは残すべき場合もある。

kill switchは、単一のボタンではなく、停止範囲のマトリクスである。取引所単位、資産単位、戦略単位、注文種別単位、APIキー単位、新規注文停止、未約定注文取消、成行停止、指値のみ、ヘッジのみ、解消のみ、観測継続、ログ継続、再開待機。金融AIのkill switchは、消灯スイッチではない。暗闇の中で、どの計器だけは光らせておくかを決める配電盤である。

Post-trade monitoring：注文後こそ危険になる

注文前に制御しても、危機時の仕事は終わらない。むしろ、注文後に何が起きたかを監視できないAIは危険である。

約定価格が想定外ではないか。部分約定が残っていないか。未約定注文が宙に浮いていないか。同じ注文が重複していないか。想定外ポジションができていないか。手数料が異常ではないか。スリッページが許容範囲を超えていないか。担保不足になっていないか。証拠金維持率が悪化していないか。清算価格へ接近していないか。CEX残高と内部帳簿が一致しているか。オンチェーン入出金が反映されているか。ヘッジが崩れていないか。注文ログ、約定ログ、キャンセルログ、残高ログが整合しているか。

危機時には、注文を出した瞬間より、その注文がどのように市場へ吸収されたかの方が重要になる。金融AIは、注文を出す機械ではない。注文が現実に何を起こしたかを追跡する機械でなければならない。

ポジション管理は全決済ではない

危機時には、ポジションをどう扱うかが難しい。新規建てを止めることは比較的簡単である。だが、既存ポジションを維持するのか、縮小するのか、即時解消するのか、ヘッジするのかは簡単ではない。

危機時に全決済すれば安全に見える。しかし、流動性が消えた市場で全決済を行えば、自分自身の売買が価格を悪化させる。板が薄いときに急いで逃げると、逃げ道そのものを壊す。担保不足を避けるための売却が、さらなる価格下落と追加清算を呼ぶ場合もある。

従って、ポジション管理には段階が必要である。新規建て停止、追加停止、レバレッジ削減、集中ポジション制限、ヘッジ追加、デルタ調整、段階的縮小、流動性回復待ち、解消のみ許可、即時解消、担保追加、法定通貨待避、別ステーブルコイン待避、取引所間移動停止、清算回避優先。

ここで最も危険なのは、“理論上の価格”と“実際に執行できる価格”を混同することである。流動性が低いとき、市場価格は存在しているように見える。しかし、その価格で充分な数量を約定できるとは限らない。板の一段目だけを見て、ポジション全体の出口があると誤認すれば、AIは自分のサイズを市場へ押し付けることになる。

危機時のポジション管理は、逃げる技術ではない。逃げることで危機を増幅しない技術である。

流動性レジームを分ける

流動性は、あるかないかではない。

充分な流動性、低下した流動性、スプレッドが拡大した流動性、板が薄くなった流動性、板が消えた市場、一部取引所だけ流動性が落ちた市場、特定ペアだけ流動性が落ちた市場、ステーブルコインペアだけ歪んだ市場、法定通貨ペアだけ歪んだ市場、入出金停止によって価格乖離が発生した市場、DeFi流動性プールが枯渇した市場、オラクル更新が遅れている市場、ブリッジ停止で資産移動ができない市場。これらは全て別のレジームである。

流動性が低いときに、理論上の価格は存在しても、実際には執行できない場合がある。大量注文は価格を動かす。成行注文は想定外の価格で約定する。指値注文は置けても、誰も取らない。ヘッジしたくても反対側の市場が閉じている。別会場へ移したくても入出金が止まっている。

流動性レジームを見ないAIは、地図上の道路だけを見て、渋滞、崩落、通行止めを見ない運転手に近い。

ステーブルコインは待避先でも震源でもある

暗号資産市場では、ステーブルコインはしばしば待避先として扱われる。しかし、危機時には、その待避先自体が震源になることがある。

ステーブルコインが1ドルから乖離したとき、単純に“別のステーブルコインへ逃げる”という設計は危険である。なぜなら、乖離は価格だけの問題ではなく、発行体、償還、準備資産、オンチェーン流動性、DeFi担保、取引所入出金、二次市場の信認が絡むからである。

重要なのは、ステーブルコインの価格が0.99か0.98かだけではない。その乖離が一時的なスプレッドなのか。償還停止を伴う構造的な不安なのか。発行体へのアクセスはあるのか。個人保有者は一次償還できるのか。取引所価格と償還価値が分離していないか。オンチェーン流動性は残っているか。DeFi担保として組み込まれていないか。清算エンジンがそのステーブルコインを1ドルとして扱い続けていないか。別ステーブルコインへの自動乗り換えが、別の集中リスクを生まないか。

ステーブルコインを危機時の避難所として使うなら、その避難所の耐震性を見なければならない。ステーブルコインは、待避先である前に、市場配管である。配管が歪んだとき、そこへ逃げ込むことは避難ではなく、破損した管へ資金を流し込む行為になりうる。

取引所障害とAPI障害

取引所やAPIの障害は、市場価格とは別の危機である。

APIエラー率上昇、注文送信不能、約定確認不能、残高取得不能、価格取得不能、WebSocket切断、REST API制限、レート制限変更、入出金停止、注文キャンセル不能、ステータスページと実態の不一致、取引所メンテナンス、複数取引所への障害波及。このとき、“別取引所へ切り替える”という単純設計は危険である。

資産はすぐ移動できるとは限らない。入出金停止中なら、そもそも会場を移れない。取引所ごとに注文仕様、価格制限、手数料、最小注文単位、レート制限、KYC、法域、APIエラー体系、ポジション管理、清算ルールが違う。別取引所へ移ることは、単なるバックアップではなく、別の市場構造へ入ることを意味する。

だから、金融AIは障害時に次を判断する必要がある。この取引所だけ止めるのか。この資産だけ止めるのか。注文送信だけ止めて、残高取得は続けるのか。未約定注文を取り消すのか。キャンセル不能なら人間へ渡すのか。別会場は観測だけにするのか。小額テスト注文まで待つのか。全会場のデータが一致するまで再開しないのか。

取引所障害は、単に接続が切れることではない。AIが自分の現在地を見失うことである。

ニュース誤報と情報不確実性

金融AIはニュースを読む。しかし、ニュースを読むAIは、誤報にも反応する。

速報、通信社記事、SNS、公式アカウント、生成AIによる偽画像、古い映像の再拡散、見出しだけの誤読、記事更新、訂正、ハッキングされた公式アカウント。危機時には、情報の速度が上がるほど、情報の信頼度は下がることがある。

金融AIがこの種の情報を即座に売買へ接続すると、AIは市場を読むのではなく、誤報の増幅器になる。

情報不確実性レジームでは、必要なのは最速反応ではない。一次情報確認待ち、独立した複数情報源の一致確認、公式アカウント乗っ取り疑義、見出しと本文の差分確認、訂正・更新の監視、取引量縮小、新規注文停止、人間承認必須、観測のみモード。速報を読むAIは、速報を疑うAIでなければならない。

情報の速さは、情報の正しさではない。

地政学ショックと制裁

戦争や制裁は、価格材料ではなく市場接続性の変更である。

軍事衝突、主要航路不安、エネルギー供給不安、制裁発表、資本規制、特定国・企業・ウォレットの制裁指定、取引所の法域制限、ステーブルコイン凍結リスク、ドル調達不安、週末や時間外の重大発表、安全資産の同時売却、クロスアセット相関崩壊。ここでAIが見るべきものは、政治的評価ではない。

どの資産が取引できなくなるのか。どのウォレットが凍結されうるのか。どの取引所が法域制限を受けるのか。どの通貨建て市場の流動性が落ちるのか。入出金は止まるのか。制裁対象確認が注文前に可能か。既存ポジションの解消は法令上問題ないか。週末にヘッジ市場が開いているか。市場間価格乖離は裁定機会なのか、資本移動不能の印なのか。

地政学ショック時、AIの問題は“当てること”ではない。取引してよい市場と、触ってはいけない市場を分けることである。

DeFiとオンチェーン危機

DeFiの危機は、CEXの危機とは違う形で現れる。

CEXは取引所が止まる。APIが落ちる。入出金が止まる。注文が返ってこない。DeFiは、接続できるまま壊れることがある。

スマートコントラクト脆弱性、ハッキング、オラクル異常、フラッシュローン攻撃、ブリッジ停止、チェーン停止、チェーン混雑、ガス代急騰、担保価格急落、清算連鎖、流動性プール枯渇、L2停止、ステーキング解除待ち、プロトコルガバナンス攻撃。

CEXでは“注文が通らない”ことが危機になる。DeFiでは“注文が通ってしまう”ことが危機になる場合がある。壊れたオラクル、枯れたプール、攻撃中のコントラクト、急騰したガス代、停止したブリッジに対して、取引そのものは実行可能に見えるからである。

DeFiでは、観測すべきものが価格だけではない。オラクル更新時刻、プール深度、ガス代、ブリッジ状態、コントラクト停止権限、清算ボット活動、担保構成、ガバナンス提案、L2シーケンサー状態、ステーブルコインペッグ、チェーン再編リスク。

オンチェーン危機時の金融AIは、“コードは動いている”という事実に安心してはいけない。コードが動くからこそ、間違いも自動で進む。

清算連鎖とmargin spiral

危機時の市場では、価格下落は単独で終わらない。

担保価値が下がる。証拠金維持率が悪化する。追証が発生する。強制清算が起きる。売り圧力が増える。価格がさらに下がる。追加清算が起きる。流動性が消える。スプレッドが広がる。また清算が起きる。これがmargin spiralである。

金融AIがこの連鎖に巻き込まれないためには、単に価格下落を見るだけでは不充分である。オープンインタレスト、資金調達率、清算量、担保構成、証拠金維持率、先物と現物の乖離、ステーブルコイン担保の再評価、オラクル価格遅延、DeFi清算ボットの活動まで見る必要がある。

さらに、AI自身の注文が連鎖を加速しうることも考えなければならない。危機時に多くのAIが同じようにレバレッジを落とし、同じようにポジションを解消し、同じように流動性の薄い出口へ向かえば、市場は安全になるどころか、薄い橋に全員が殺到する。

危機時のAIは、清算連鎖を利用する前に、自分が清算連鎖の部品になっていないかを問うべきである。

Human-in-the-loopは責任論ではなく運用機能である

危機時に人間を入れるべきか。この問いは、法的責任論とは別である。ここで扱うのは、責任の所在ではなく、運用機能としての人間介入である。

どのレジームで人間承認が必要か。承認待ちの期間に市場が動くリスクをどう扱うか。人間が眠っている時間帯はどうするか。週末・祝日はどうするか。通知疲れをどう避けるか。誤警報をどう減らすか。アラートの優先度をどう分けるか。人間が理解できる説明をどう出すか。誰が再開承認を持つか。承認不能時は観測のみへ落ちるのか。人間の介入もログに残すのか。

これは、“人間が最後に責任を取る”という精神論ではない。AIから、どの状態で自律性を剥奪するかという運用設計である。

AIに全てを任せるのではない。人間に全てを投げるのでもない。どの状態でAIから自律性を剥奪し、どの状態で人間へ渡すかを決める。

Human-in-the-loopは、危機時のハンドルである。ただし、そのハンドルは常に握らせればよいものではない。人間承認が多すぎれば、システムは鈍くなる。通知が多すぎれば、監督者は疲弊する。夜間に承認できなければ、ポジションは放置される。

従って、人間介入は、レジームごとの限定機能として設計されるべきである。

監視ダッシュボードは、止まった理由を表示する

金融AIが止まるだけでは不充分である。人間が、なぜ止まったのかを理解できなければならない。

監視ダッシュボードには、少なくとも次の状態が必要である。市場状態、データ状態、注文状態、ポジション状態、取引所状態、API状態、資金状態、担保状態、ステーブルコイン状態、ニュース状態、法域・規制状態、モデル状態、ログ状態、block発動履歴、kill switch状態、人間承認待ち状態、再開条件充足状態。

重要なのは、赤いランプを出すことではない。どの条件で止まったのか。どの条件が解除されれば再開できるのか。どの取引所だけが止まっているのか。どの資産だけが止まっているのか。注文は止まっているが観測は続いているのか。ログは保存されているのか。未約定注文は残っているのか。人間承認が必要なのか。自動再開は禁止されているのか。

これが見えなければ、停止は安全装置ではなくブラックボックスになる。金融AIの監視盤は、損益表示だけでは足りない。AIがなぜ動き、なぜ止まり、何を確認すれば再開できるのかを示す必要がある。

ストレステストとシナリオ分析

平時バックテストが過去の市場での検査だとすれば、ストレステストは壊れる状況を意図的に作る検査である。

ここで重要なのは、単発シナリオだけでは足りないことだ。BTC急落、ETH急落、ステーブルコインデペッグ、主要取引所停止、APIエラー急増、注文キャンセル不能、ニュース誤報、戦争速報、制裁発表、ドル急騰、原油急騰、株式急落、金利急変、DeFi清算連鎖、オンチェーン混雑、ブリッジ停止、クラウド障害、複数データソース同時障害、取引所間価格乖離、人間承認不能。

危機は、単品料理で来るとは限らない。むしろ、危機は盛り合わせで来る。

ステーブルコインが乖離しているときに、取引所APIが遅延する。戦争速報が出た直後に、ニュースソースが不一致になる。清算連鎖が起きているときに、オンチェーン手数料が急騰する。取引所が止まったまま、別会場では価格が乖離する。人間承認が必要なときに、人間が眠っている。

金融AIの危機時安全性は、“平時データで勝ったか”ではなく、“複合障害を与えたときにどう縮退するか”で検査されるべきである。

カオスエンジニアリングは本番売買で試してはならない

金融AIにも、意図的な異常注入は有効である。価格フィード遅延、API切断、注文拒否、部分約定、取引所停止、データ欠損、ニュース誤報、スプレッド急拡大、板消失、ステーブルコインデペッグ、レート制限、ログ保存失敗、通知失敗、人間承認不能、バックアップ系切替失敗。

こうした異常を、検証環境、リプレイ環境、ペーパートレード、サンドボックスで試すことは有効である。むしろ、試していない安全装置は、飾りの消火器に近い。

ただし、本番市場で実弾を使って試すべきではない。本番で価格フィードを意図的に改竄する。注文拒否を強制する。キャンセル不能を再現する。誤ったデータを流す。こうした試験は、市場や利用者に影響を与えうる。

本番で試してよいのは、read-onlyな観測系、通知系、ログ系、ダッシュボード系、注文を出さないフェイルオーバー確認などに限定されるべきである。

金融AIのカオスエンジニアリングは、壊して強くするためのものではない。壊してはいけない場所を明確にするためのものである。

停止より再開の方が危険である

危機時レジーム管理では、停止条件が注目されやすい。しかし、本当に難しいのは再開条件である。

停止は、防御的にできる。疑わしければ止める、という判断は比較的作りやすい。しかし、再開は攻撃的である。市場へ戻る行為だからである。再開が早すぎれば、まだ壊れている市場へ入る。遅すぎれば、必要なヘッジや正常な取引ができない。

再開条件には、複数の確認が必要である。市場ボラティリティ低下、スプレッド正常化、板厚回復、APIエラー率低下、データソース一致、取引所公式復旧確認、入出金再開、ステーブルコインペッグ回復、清算量正常化、ニュース確認、制裁・規制影響確認、ログ整合確認、未約定注文確認、残高確認、ポジション確認、小額テスト注文、人間承認、段階的再開。

再開は、いきなり通常運転へ戻すべきではない。観測再開、小額テスト注文、限定資産、限定取引所、低レバレッジ、指値のみ、通常サイズ復帰、フル稼働。この階段を踏む必要がある。

停止はブレーキである。再開は再発進である。ブレーキを踏める車でも、坂道発進が下手なら事故を起こす。

ログは責任追及だけのものではない

危機時ログは、後から誰が悪かったかを調べるためだけのものではない。次の危機へ進化するための材料である。

保存すべきログは多い。レジーム判定、使用データ、データ品質フラグ、危機シグナル、制御発動条件、soft block、hard block、kill switch、人間承認、注文、約定、未約定、キャンセル、エラー、通知、設定変更、モデルバージョン、コードバージョン、再開判断、事後レビュー。

危機時ログは、次の問いへ答えるためにある。どの条件で止まったか。止まるのが早すぎたか。遅すぎたか。誤警報だったか。見逃しがあったか。どのデータが役に立ったか。どのシグナルがノイズだったか。人間介入は有効だったか。再開条件は適切だったか。ログは充分だったか。次回、閾値を変えるべきか。バックテストへ何を追加すべきか。

危機は、ただ耐えるものではない。次の安全装置を作るために記録するものである。

小規模OSS型金融AIに必要な最小フェイルセーフ

大手機関と同じ統制を、個人開発・OSS型金融AIに要求するのは現実的ではない。しかし、何もしないことは危険である。

bitBuyerのような小規模OSS型金融AIに必要なのは、巨大な監督部門ではなく、最小限のフェイルセーフである。低頻度でもよい市場状態監視、取引所API状態確認、注文サイズ上限、損失上限、スプレッド上限、板厚不足時の注文停止、データ欠損検知、ステーブルコイン乖離検知、手動kill switch、観測のみモード、設定ファイルによる取引停止、注文・約定・エラーの永続ログ、簡易アラート、再開前チェックリスト、ペーパートレード検証、本番環境と検証環境の分離、モデル更新時の安全確認、APIキー権限の分離、read-only keyとtrading keyの分離、出金権限の制限、異常時の学習停止。

特に重要なのは、売買停止と観測継続を分けることである。危機時に売買を止めることはあってよい。しかし、観測まで止めると、AIは危機の記録を失う。記録がなければ、次の危機に強くなれない。

bitBuyerが自律学習型であるなら、もう一つ重要な論点がある。異常レジームを通常学習へ混ぜてよいのか、である。

危機時データは貴重である。しかし、それを平時と同じ重みで学習へ混ぜれば、AIは危機の歪みを通常状態として覚える可能性がある。従って、危機時には、売買停止だけでなく、学習停止、学習隔離、異常レジームラベル付けが必要になる。

自律性とは、常時稼働の許可ではない。どの状態で自律性を失うべきかまで含めて、自律性である。

過剰制御もまたリスクである

ここまで停止と縮退の話をしてきた。しかし、止めすぎることも危険である。

誤警報による取引機会喪失、必要なヘッジ不能、停止中のリスク拡大、再開遅延、アラート疲れ、人間承認待ちによる機会喪失、過剰なhard blockによる柔軟性喪失、危機時に全システムが同時停止して流動性がさらに低下するリスク。安全装置は、強ければ強いほどよいわけではない。

強すぎる安全装置は、必要な操作まで封じる。危機時に新規注文を止めるのは妥当でも、ヘッジまで止めるとリスクが増える。成行注文を止めるのは妥当でも、流動性が充分な限定的な指値解消まで止めると、ポジションが閉じられない。

金融AIのレジーム管理は、臆病であればよいのではない。危険なときには臆病に、必要なときには限定的に動けることが重要である。

同質的AIは危機を増幅するかもしれない

もし多くのAIが、同じデータベンダーを使い、同じモデルを使い、同じニュース分類を使い、同じリスク指標を使い、同じ停止条件を持ったらどうなるか。

それは市場を安定させるかもしれない。しかし、逆に市場を脆くするかもしれない。

多くのAIが同時に売る。多くのAIが同時にレバレッジを落とす。多くのAIが同時に新規注文を止める。多くのAIが同時に流動性の薄い出口へ向かう。多くのAIが同じニュースを同じ分類で解釈する。多くのAIが同じデータベンダー障害へ同時反応する。多くのAIが同じrisk modelに従ってポジションを解消する。

これは、危機時レジーム管理にとって難しい問題である。各AIにとって合理的な停止が、市場全体では非合理な同時停止になる可能性がある。各AIにとって合理的なレバレッジ削減が、市場全体では同時売却になる可能性がある。各AIにとって合理的なニュース反応が、市場全体では誤報への同時反応になる可能性がある。

安全装置は、個別システムを守る。しかし、同じ安全装置が市場全体で同時に作動したとき、それは別の危機装置になるかもしれない。

金融AIの時代には、“安全性”すら群集行動を起こす。

bitBuyer Projectへの接続

bitBuyer Projectにとって、この論点の中心は、AI人格論ではない。文明OSでもない。労働解放でもない。OSS一般論でもない。

ここでの中心は一つである。自律的な金融AIは、自分の行動可能性を制限できるか。

固定ルールを持たず、ゼロ知識学習型で、市場から学び続けるシステムであっても、停止条件まで内部学習に委ねてよいとは限らない。むしろ、停止条件、縮退条件、観測のみ条件、再開条件は、AIの外側に置かれるべきかもしれない。

なぜなら、危機時に一番危険なのは、AIが“この状態でも学習すればよい”と判断することだからである。

危機時データは、学習材料である前に、隔離対象である。危機時売買は、収益機会である前に、制限対象である。API障害は、代替会場探索の前に、観測信頼性低下である。ステーブルコイン乖離は、裁定機会である前に、配管異常である。清算連鎖は、ボラティリティである前に、自分も市場を壊しうる状態である。

bitBuyerに必要なのは、万能の予測力ではない。最低限の停止権限、最低限の縮退運転、最低限の観測継続、最低限のログ保存、最低限の再開チェック、最低限の人間介入権限である。

小規模OSS型金融AIが大手機関と同じ統制を持つ必要はない。しかし、危機時に何もしないAIであってはならない。

自律性は、無制限に動くことではない。自律性とは、自分が動いてよい状態と、動いてはいけない状態を区別することである。

金融AIの強さとは何か

金融AIの強さは、平時に利益を出すことなのか。それとも、危機時に壊れ方を制御できることなのか。この問いは、金融AIの評価軸を変える。

平時バックテストで勝てるシステムは、魅力的に見える。だが、危機時に止まれないシステムは、損失を出すだけでなく、市場へ誤作動を流し込む。取引所が止まり、データが欠け、ステーブルコインが歪み、ニュースが錯綜し、清算が連鎖し、人間が眠っているとき、それでも同じロジックで動くAIは、知的なのではない。環境の変化を理解していないだけである。

金融AIに必要なのは、予測する知性だけではない。停止する知性である。縮退する知性である。観測だけを残す知性である。再開を急がない知性である。ログを残す知性である。自分の行動が市場を壊しうると知る知性である。

平時バックテストは、金融AIの入口である。危機時レジーム管理は、金融AIが市場に出るための出口審査である。

AIが市場を読む時代には、AIが自分自身を止める設計もまた、市場の一部になる。そして、金融AIの本当の強さは、勝つことだけではなく、壊れるべきときに、壊れ方を選べることにある。