Knight Capital（2012）— 45分で460億円

何が起きたか（日時・影響範囲）

2012年8月1日9時30分（米国東部時間）、米株式市場最大級のマーケットメイカーだったKnight Capitalの発注ルーターSMARSが暴走しました。45分間に数百万件の注文を送出し、154銘柄で400万件超・約4億株（3.97億株）を約定。買い越し約35億ドル（80銘柄）・売り越し約31.5億ドル（74銘柄）という意図しない建玉を抱え、同社は税引前約4.4億ドルの損失を公表しました（SEC処分文書の認定は4.6億ドル超。1ドル100円換算で約460億円）。取引の取消しが認められたのは6銘柄のみで、残りは有効に確定。自己資本を大きく毀損した同社は4億ドルの緊急増資（既存株主は約7割希薄化）で延命した後、同年12月に競合Getcoとの合併に合意し、独立企業としては実質消滅しました。

タイムライン

根本原因の技術解説

第一の欠陥はデッドコードです。Power Pegは2003年から未使用でしたが、SMARSの本番コードから削除されていませんでした。さらに2005年の改修で「累積約定数の追跡」処理がコード列の上流へ移設され、Power Pegの停止条件——親注文の充足を検知して子注文を止める——は静かに壊れました。使われていない前提のコードだったため、この破壊を検出するテストは行われていません。

第二の欠陥はフラグの再利用です。RLP対応の新コードは、かつてPower Pegの起動に使っていたフラグを「RLP対象注文の印」として転用しました。配備が8台中7台で止まった結果、同じ1ビットが7台では「RLPとして処理」、1台では「Power Pegを起動」という正反対の意味を持つ混在状態が生まれます。旧コードの1台では、RLPフラグ付きの親注文が届くたびに、約定を数えない壊れた送信ループが子注文を吐き続けました。

# 新コード（7台）
if order.flag_X:
    handle_rlp(order)        # RLP対象として処理

# 旧コード（1台）— flag_X は Power Peg の起動命令
loop:
    send_child_order()
    if parent_filled():      # 2005年の改修以降、この判定は機能しない
        break

なぜ防げなかったか

横にスクロール

配備を検証する仕組みがありませんでした。新コードは技術者の手動コピーで配られ、全台のバージョン一致を照合する手順も自動化も無く、「8台中7台」という部分配備は発火するまで誰にも見えませんでした。警報も機能していません。開場前から届いていた97通のメールはエラーを名指ししていましたが、システムアラートとして設計されておらず、対応をトリガーしませんでした。

そして緊急停止の設計がありませんでした。文書化された停止手順もkill switchも無く、担当者は本番で45分間診断を続けます。加えて、発注フロー全体を資本閾値や建玉上限で自動遮断する独立の統制が無く、66億ドル超の総建玉が積み上がってもシステムは止まりませんでした。SECが市場アクセス規則違反として問うたのは、バグそのものではなくこの統制の欠如です。

教訓（原則として一般化）

• デッドコードは削除する: 到達可能なコードは「いつか実行されるコード」です。9年間未使用でも1ビットで蘇ります。無効化や放置ではなく削除し、削除自体を通常のリリースとして検証します。
• フラグを再利用しない: フィーチャーフラグに作成→展開→掃除のライフサイクルを定め、役目を終えたフラグと分岐は撤去します。同時に稼働しうる全バージョン間で意味が一致することを配備の前提条件にします。
• 配備を自動化し検証する: 全ノードのバージョン・ハッシュ照合、部分配備の自動検知、カナリアリリースと検証済みロールバックを備えます。手動コピーと目視は統制ではありません。
• 緊急停止を先に作る: 診断より停止を優先できるkill switchと、文書化・訓練済みの手順を用意します。切り戻しにも配備と同等の検証を課します。
• アプリの外に独立の上限を置く: 発注額・建玉・レートのハードリミットを業務ロジックと別系統で強制し、コードの故障が資本を直撃しない多層防御にします。

配備自動化やカナリアの原理はDevOps、フェイルセーフと多層防御の設計はセキュリティの各トピックも参照してください。