2012年8月、米国の大手証券会社「ナイト・キャピタル・グループ（Knight Capital Group）」で起きた株式取引システム障害は、わずか45分間で約4億6000万ドル（当時のレートで約360億円以上）、単純計算で「1分あたり1000万ドル」もの資金を失うという前代未聞の事態を引き起こしました。そして、原因は高度なサイバー攻撃でも、複雑な数式のエラーでもなく、初歩的ともいえる「あるエラー」だったのです。この事件は、現代のDevOpsやSREの前提ともいえる自動化等の重要性を世界に知らしめた「教科書的な失敗事例」とされています。そこで今回は、この伝説的な事件の経緯を追って教訓をまとめてみたいと思います。
- もくじ
1. 45分で会社が消滅寸前？ 伝説の「ナイト・キャピタル事件」とは
1-1. 1分あたり100万ドル（約1億円）が消えていく恐怖
2012年8月1日。ニューヨーク証券取引所（NYSE）の取引開始と同時に、ウォール街はパニックに陥りました。米国株式市場の取引シェア約17％を担う大手証券会社ナイト・キャピタル（Knight Capital）のシステムが、突如として制御不能となり、狂ったように注文を市場へ送り始めたからです。
暴走は凄まじいペースで、45分の間にシステムは150以上の銘柄で合計400万件を超える取引を成立させ、約3億9700万株を売買してしまいました。本来であれば数日かけて行う取引量とされています。システムが停止されたとき、ナイト・キャピタルは4億6000万ドル（約460億円）を損失していました。同社の前年の純利益の4倍近くに相当する額で、分単位で見れば「1分あたり1000万ドル」が会社の口座から蒸発していった計算になります。
1-2. 市場をパニックに陥らせた「謎の大量誤発注」の正体
パニックの原因はナイト・キャピタルのアルゴリズムが「高く買って安く売る」という商売の基本とは真逆の行為を高速で繰り返したことにありました。このため市場では特定の銘柄の株価が乱高下していました。
本来、同社のシステムは市場の「買気配」と「売気配」の差（スプレッド）を取りに行くよう設計されていたとされています。しかし、この日はシステムが暴走し、市場価格よりも高い値段で買い注文を出し、安い値段で売り注文を出し続けてしまいました。当然、他の自動取引業者のアルゴリズムはこの「カモ」ともいえる注文に即座に反応したため、ナイト・キャピタルの損失は雪だるま式に膨れ上がることになりました。
この異常な挙動が発生した理由は、同社がニューヨーク証券取引所の新プログラム「Retail Liquidity Program（RLP）」に対応するために行ったシステム更新が失敗していたためでした。
1-3. なぜ、ナイト・キャピタル・グループは破綻の危機に陥ったのか？
45分間のシステム暴走が、70年以上の歴史を持つ企業を即日破綻の危機に追い込むことになりました。これは、同社のビジネスモデルの特性に加え、抱え込んでしまった在庫リスクが致命的だったからだと指摘されています。
まず、システムは安値で大量の株式を購入してしまいました。この損失を確定させ、事態を収拾するためには、膨れ上がりすぎた在庫、つまり株式を市場で売却しなければなりません。しかし、誤発注によって株価はすでに乱高下しており、同社は安値で買い付けてしまっています。そこにさらに大量の売りを出せばさらに価格は下がってしまいます。結果として、買い集めた株を安値で処分せざるを得なくなり、その差額がすべて損失となってしまったのです。
4億6000万ドルといわれる損失額は、ナイト・キャピタルの自己資本の40％近くを吹き飛ばしてしまうものでした。信用は失墜し、同社の株価も2日間で75％も暴落。自力での再建は不可能となり、最終的には競合他社であったGetcoを中心とする投資家グループによる救済合併を受け入れ、会社は実質的に消滅することになりました。
2. 巨額損失を生んだ「意外に単純な」原因
2-1. 犯人は「8台のうち1台」の手動デプロイ漏れ
調査が進むと、この大惨事を引き起こした原因が驚くほどアナログで単純なミスだったことがわかり、衝撃が広がりました。
その背景から説明します。当時、ナイト・キャピタルの取引システム「SMARS」は8台のサーバーで稼働していました。新機能（RLP）をリリースするため、担当のエンジニアはこれらのサーバーにあるプログラムを更新する必要がありました。しかし、この更新作業は「手動」でした。
エンジニアは8台のうち7台には新しいコードを正しくコピーしましたが、1台だけ更新を忘れてしまったのです。これが事件の原因でした。
翌朝、市場が開くと、システムは顧客からの注文を8台のサーバーに分散して送信し始めました。更新済みの7台は正常に動作しましたが、古いコードが残ったままの「8台目のサーバー」に注文が回ってきた瞬間、悲劇のスイッチが押されてしまいます。自動化されたデプロイの仕組みがあれば防げたであろう「コピー漏れ」が、すべての発端でした。
2-2. 新旧コードの混在が生んだ「デッドコード（ゾンビ・アルゴリズム）」の暴走
なぜ「更新し忘れた」だけで異常取引が始まったのでしょうか。そこには「デッドコード（使われていないコード）」と「フラグの再利用」という2つの問題が絡み合っていたとされます。
ナイト・キャピタルのシステムには、2003年頃にテスト目的で使用されていた「Power Peg（パワー・ペグ）」という古い機能が残されていました。これは株価を意図的に動かすテストのために「ひたすら買って売る」という、本番環境では絶対に使ってはいけない危険な機能でした。このコードは長年使われていない「死んだコード」として放置されていました。
事件の原因となったアップデートでは、新しいプログラム（RLP）を起動するためのスイッチ（フラグ）として、かつてPower Pegを起動するために使っていたフラグを再利用していました。「古いコードはもう使わないから、同じスイッチを別の用途に使っても大丈夫だろう」といった判断がされていたのでしょう。
しかし、更新されなかった「8台目のサーバー」には、古いコードが生きていました。
新システムが、新しいRLP機能を動かす指令を全サーバーに送ったとき、「8台目のサーバー」だけはそれを古いPower Peg機能（＝全力売買テストを動かす）と解釈します。こうして、8年ぶりに目覚めたゾンビ・アルゴリズムが、本番市場で暴れ回ることになったのでした。
2-3. なぜテストで防げなかったのか？
事故をさらに深刻化させたのは、発生後の対応ミスにもあったとされています。取引開始直後、異常に気づいたエンジニアたちは、原因を「新しく入れたプログラムのバグ」だと考えしました。そこで彼らは「新しいコードを削除して、昨日の状態（古いバージョン）に戻す（ロールバックする）」判断を下しました。しかし、これは火に油を注ぐ最悪の選択でした。
なぜなら、暴走の原因は「古いコード（Power Peg）」だったからです。彼らが正常に動いていた7台のサーバーから新しいコードを削除し、古いコードに戻した結果、7台すべてのサーバーが「古いコード」に戻り、一斉に「Power Peg」を起動し始めてしまったのです。
当初は8台のうち1台だけの暴走だったものが、ロールバック作業によって「全台暴走」へと拡大することになりました。これが、損失額を天文学的な数字へと押し上げた理由です。本番環境と同じ構成でテストが行われていなかったこと、そして「何が起きているか」を正確に把握できないまま手動で介入してしまったことで取り返しのつかない事態となってしまいました。
3. 事件からの「学び」を考える
3-1. 「ヒューマンエラーは防げない」と考える
この事件から得られる最大の教訓は、「人間は必ずミスをする」という前提に立ってシステムを設計すべきだということでしょう。
デプロイを忘れたエンジニア個人の責任にするのは簡単ですが、それでは問題は解決しません。疲労や勘違い、連絡ミスなどもありますし、人間が関与する限り、どんなシステムであってもエラーをゼロにすることはかなり難しいか不可能に近いことです。
「もっと気をつける」「ダブルチェックする」といった精神論では、極限のプレッシャーがかかる現場では役に立たないことが多いです。人の手による操作を信頼の基盤に置くこと自体が最大のリスク要因であることをナイト・キャピタル事件は証明しています。
3-2. 「デプロイ自動化」と「CI/CD」はなぜ不可欠になったか
もし当時のナイト・キャピタルが、構成管理ツールや自動デプロイパイプラインを使用していれば、プログラムは全サーバーへ機械的に一律適用され、「1台だけ古いまま」という状況は物理的に起こり得なかったでしょう。現代のDevOpsにおいてデプロイの自動化（CI/CD）が必須とされる理由はここにあります。
自動化ツールは疲れることもなければ、手順を飛ばすこともありません。この事件は、自動化への投資が単なる効率化のためではなく、企業の存続を守るための「保険」であることを教えてくれているといってよいでしょう。
3-3. 現代に活かす学び
現代では、万が一ミスが起きても被害を最小限に抑える仕組みが標準化されています。例えば「カナリアリリース」が挙げられます。一気に全台更新するのではなく、まず1台（または少数のユーザー）だけに新機能を公開して様子を見る手法です。また、異常な損失やエラーを検知したら、人間が判断する前にシステムを自動停止させる「サーキットブレーカー（キルスイッチ）」の導入も重要とされています。
ナイト・キャピタルは、異常を検知した後に自動停止をする仕組みを持っていませんでした。コードを書く力だけでなく、「失敗したときにシステムをどう守るか」を設計する力が、現代のエンジニアには求められていることをこの事件は教えてくれています。
4. まとめ
わずか45分で4億6000万ドルを失ったナイト・キャピタル事件。その原因は高度な攻撃ではなく、手動デプロイのミス、デッドコードの放置、そして誤ったロールバック判断という、人間的なエラーの連鎖でした。この事例は、手動作業の排除、デプロイの自動化、そして「失敗」を前提としたシステム設計がいかに重要かを痛烈に伝えています。技術の進化とともに風化させてはならない、IT史に残る重要な教訓となりました。
