850万台のPCが一斉にダウンした日——絶対に壊れないソフトウェアの作り方を、CrowdStrike障害が私に教えてくれた
私はハイデラバードのホテルのロビーに座っていたとき、携帯電話が震え始めた。いつものSlack通知のわずかな流れではない——これは洪水だった。あるクライアントのWindowsマシン群がまるごとブルースクリーンになった。それから別のクライアントも。そしてニュースが飛び込んできた。空港は欠航を出し、病院は手術を中止し、銀行は取引を凍結した。すべては、昼食を撮った写真よりも小さい、CrowdStrikeのたった一つのファイル更新が原因だった。
2024年7月19日。その日、約850万台のWindowsシステムが同時にブルースクリーン・オブ・デスに墜落した。やがて世界経済に100億ドルを超える損害をもたらすことになる日だった。そして私が、いまも夜眠れなくさせる一つの問いに取り憑かれた日だった。なぜ私たちは、人類史上最も重要なシステムを、設定ファイル一つで破壊されうる基盤の上に築いているのか?
私はAIコンサルティング会社であるVeriprajnaを経営している。私たちは、いま市場を席巻している薄っぺらなChatGPTのラッパーではなく、私が「Deep AI」と呼ぶソリューション——コアインフラと統合するシステム——を構築している。CrowdStrikeの障害が起きたとき、AI業界の半分は肩をすくめた。「セキュリティの問題だ」と彼らは言った。「私たちの領域ではない」と。だが私は違うものを見た。私が見たのは、その下で何が起きているかを理解しないままAIを自社の業務に急いで取り付けようとする、あらゆる企業を悩ませているのとまったく同じアーキテクチャ上の脆弱性だった。
障害のあと、私は何ヶ月もかけて根本原因分析を徹底的に分解し、デルタ航空の訴訟を追い、形式検証に関する新たな研究を学んだ。そこで見つけたものは、私のチームがすべてを構築する方法を変えた。分析全体を包括的にインタラクティブに分解したものをこちらに書いたが、このエッセイは研究の背後にある物語——ホワイトペーパーにきれいに収まらない部分——だ。
JPEGより小さなファイルが世界の航空を停止させた
専門用語を取り払って、実際に何が起きたのかを説明しよう。
CrowdStrikeのFalconセキュリティプラットフォームは、Windowsカーネル——オペレーティングシステムの最も深く、最も特権的な層——の内部で動作する。船の機関室だと考えてほしい。甲板の上で何か問題が起きても、修理できる。だが機関室で何か問題が起きれば、船は沈む。
新たな脅威を素早く検知するため、CrowdStrikeは「Rapid Response Content」と呼ばれるシステムを構築した。完全なソフトウェア更新(遅く、テストを要する)を配信する代わりに、小さな設定ファイル——基本的には、どんなパターンを探すべきかをセキュリティエンジンに指示する指示書——を配信する。巧妙だ。そして、私たちが学んだように、恐ろしいほど危険でもある。
その朝、特定の種類のプロセス間通信を検知するための、二つの新しい命令セットが展開された。これらの命令が参照していたのは21個の入力パラメータだった。問題は?すべてのエンドポイントで動作するエンジン——カーネル内で実際に実行されるコード——が理解していたのは、20個のパラメータだけだった。
クラウドは「21個のフィールドを読め」と言った。カーネルは20個しか知らなかった。その不一致が850万台のコンピュータをクラッシュさせた。
クラウドのバリデーターがその更新を承認したのは、自身のテンプレート定義に21個のフィールドが含まれていたからだ。それは、エンドポイントが処理できる現実ではなく、自らの期待に照らして検査していた。カーネルレベルのインタプリタがその21番目のフィールドにアクセスしようとしたとき、割り当てられたメモリの境界を越えて読み込んだ。カーネル空間では、それは回復可能なエラーではない。即座のクラッシュだ。ブルースクリーン。再起動。再びクラッシュ。再起動。再びクラッシュ。無限の死のループだ。
数週間後、私はこれを技術に詳しくない投資家に夕食の席で説明したのを覚えている。彼は私をじっと見つめて言った。「つまり、更新を受け取る側が実際にその更新を処理できるかどうかを、誰もテストしなかったと言うのか?」と。私はうなずいた。彼はフォークを置いた。「それはソフトウェアのバグじゃない。過失だ。」
彼は間違っていなかった。そしてジョージア州のある裁判官も、本質的に彼に同意することになる。
なぜ4万台のサーバーを手作業で修復しなければならなかったのか
この物語の中で十分に注目されていない部分は、復旧——いや、むしろリモート復旧の不可能性——だ。
残酷な皮肉がここにある。CrowdStrikeのエージェントは、クラウドからコマンドを受け取るものだ。「この更新をロールバックせよ。」「この修正を適用せよ。」だが、クラッシュはブートシーケンスのあまりに早い段階で起きたため、エージェントは一度も初期化されなかった。救助信号を受け取るはずだったソフトウェアこそが、溺れさせている当のものだった。
私のチームはこれを「デッド・エージェント」問題と呼び始めた。影響を受けたすべてのマシンが孤立した。本部に連絡できない。指示を受け取れない。唯一の修復方法は、各マシンを物理的にセーフモードで起動し、C:\Windows\System32\drivers\CrowdStrike\に移動して、問題のあるファイルを手動で削除することだった。
デルタ航空にとって、それは約4万台のサーバーと数千台のワークステーションに手を触れることを意味した。手作業で。一台ずつ。
私は以前にもIT復旧作業を管理したことがあるが、その規模のロジスティクスはほとんど理解不能だ。異なる都市の施錠されたサーバールームにあるかもしれないマシンへの物理的なアクセスが必要だ。セーフモードで起動する方法を知っている技術者が必要だ——そしてそれは、BitLocker暗号化の時代には、しばしば回復キーを必要とし、その回復キーは……同じくクラッシュした別のサーバーに保存されている。どこまでも亀の上に亀が乗っているようなものだ。
デルタの競合他社——アメリカン航空、ユナイテッド——は1日から3日で復旧した。デルタの混乱は5日以上続き、その結果、7,000便を超える欠航と5億5,000万ドルの損失をもたらした。違いは何か?デルタの乗員追跡システム——パイロットや客室乗務員がどこにいて、いつ稼働可能かを航空会社に伝えるソフトウェア——は、ほぼ完全にWindows上で動いていた。それらのサーバーが死んだとき、デルタは単にコンピュータを失っただけではない。自社の人員がどこにいるのかを知る能力を失ったのだ。
ソフトウェアのバグが「重過失」になるとき、何が起きるのか?
ここで物語は、サーバールームから法廷へと移る。そして私が思うに、その影響が本当に業界を変えるものになる場面だ。
デルタはCrowdStrikeを提訴した。それ自体は驚くことではない——企業は大規模な障害のあとにベンダーを訴えることなど日常茶飯事だ。驚くべきは、裁判官が審理継続を認めたものだ。
歴史的に、ソフトウェアベンダーは契約によって守られてきた。利用規約の中には必ず責任上限が埋め込まれている——通常、顧客がサブスクリプションに支払った金額に限定される。心地よい取り決めだ。顧客のインフラの最も深い層で動作するソフトウェアを販売し、それがすべてを破壊しても、最大の負担は12ヶ月分のライセンス料にすぎない。
2025年5月、フルトン郡上級裁判所のケリー・リー・エラーベ裁判官は、デルタの主張——重過失と——これこそ私を思わず居住まいを正させたものだが——コンピュータ不法侵入——の主張を棄却することを拒否した。
重過失の主張は明快だ。CrowdStrikeは850万台すべてのシステムに同時に更新を配信した。段階的なロールアウトはなし。カナリアデプロイもなし。「まず1%のマシンで試して、何が起きるか見てみよう」もなし。デルタの弁護士は、これが既知のリスクに対する意識的な軽視を示していると主張した。CrowdStrike自身のインシデント後報告書は、Content Validatorに論理エラーがあり、Content Interpreterにランタイムの境界チェックが欠けていたことを認めた。
だが、コンピュータ不法侵入の主張こそ、これを読むすべてのSaaSベンダーを震え上がらせるはずのものだ。デルタは自動更新をオプトアウトしていた——彼らの設定で、だ。それでもCrowdStrikeは、カーネルレベルのチャネルファイル機構を通じて更新を配信した。裁判官は、コンピュータ不法侵入に関する法定義務はサブスクリプション契約とは独立している——つまり契約上の責任上限は適用されない——と判断した。
ベンダーがあなたの明示的な設定を上書きして、あなたのカーネルにコードを送り込むとき、契約上の責任上限は彼らを守らないかもしれない。それが新たな法的現実だ。
この判決以降、私は3人の異なるCISOと話したが、全員が同じことを言った。「私たちはベンダー契約を書き直している。」セキュリティベンダーからの自動更新を無制限に信頼する時代は終わった。
AI業界との居心地の悪い相似
さて、ここからは率直に言おう。そして、AI分野の同業者の一部は、私が言うことを気に入らないだろう。
AI業界は、CrowdStrikeが露呈させたのと同じ脆弱な基盤の上に築いている。私たちはただ、それをより速く、より大きな誇大宣伝とともにやっているだけだ。
今の市場は、私が「LLMラッパー」と呼ぶもの——GPT-4やClaudeにAPIコールを行い、その応答を見栄えのよいUIで包み、それをAI製品と称する薄っぺらなアプリケーション層——に支配されている。技術アーキテクチャの全体が文字通り「OpenAIにプロンプトを送って結果を表示する」だけの企業のピッチデックを、私は見たことがある。それらは数千万ドルの評価額を付けられている。
昨年、私はあるカンファレンスに参加し、そこで一人の創業者が誇らしげに自社の「AI駆動のセキュリティ分析ツール」を実演していた。私は単純な質問をした。「もしOpenAIがAPIを変更したり、価格を10倍に引き上げたり、6時間ダウンしたりしたら、どうなりますか?」彼は、重力が働かなくなったらどうなるかと私が尋ねたかのような目で私を見た。「そんなことは起きません」と彼は言った。
それは起きる。いつだって起きる。CrowdStrikeの障害は、最も信頼されているインフラベンダー、あなたが全事業を賭けている相手でさえ、たった一つの不良ファイルを配信してすべてを崩壊させうることを証明した。
だからこそ私たちは、私が「Deep AI」と呼ぶものを中心にVeriprajnaを築いた——そして、この言葉が安易に使い回されているので、私が何を意味するのかを正確に述べておきたい。
Deep AIソリューションは、その知能を単一のサードパーティ・プロバイダーから借りたりはしない。ハイブリッドアーキテクチャ——特化型の小規模言語モデル、視覚言語モデル、グラフニューラルネットワーク——を使い、ユースケースが求めるときには顧客自身のインフラ上に展開する。UIレベルではなく、システムレベルで統合する。そして決定的に重要なことに、形式検証を用いて、単なる確率的な最善の推測ではなく、その挙動について数学的な保証を提供する。
この違いは重要だ。LLMラッパーは、たいてい正しいチャットボットを与える。Deep AIシステムが与えるエンジンは、それが実行するよう設計された特定のタスクに対して、証明可能なほどに正しいものだ。
なぜ私は形式検証に取り憑かれたのか
正直に言おう。CrowdStrikeの障害の前、私は形式検証を学術的な好奇心の対象だと思っていた。研究者が論文を発表しても、誰も実運用では使わないものだと。seL4マイクロカーネル——形式的に検証されたオペレーティングシステムのカーネル——は印象的だったが、何年もの博士レベルの労力を要する一度きりの成果のように思えた。
そして私がCrowdStrikeの根本原因分析を3度目に読んだとき、何かがカチッとはまった。
この大惨事のすべては、一つの意味的ギャップに行き着いた。クラウドのバリデーターは、テンプレートに21個のフィールドがあると信じていた。エンドポイントのインタプリタは、20個あると信じていた。同じシステムの二つのコンポーネントが、現実について矛盾した信念を抱いていた。そして誰もそれに気づかなかった。両方のコンポーネントが照合して検証されるべき、共有された数学的に厳密な仕様が存在しなかったからだ。
形式検証は意味的ギャップを排除する。数学的証明を用いて、ソフトウェア——実際の実装——が常にその仕様を満たすことを保証する。「たいてい」ではない。「私たちのテストでは」でもない。常に、だ。証明が通れば、ソフトウェアはその仕様に違反できない。以上。
私のチームは昨年、VeCoGenと呼ばれるフレームワークを何週間もかけて実験した。これは大規模言語モデルと形式検証エンジンを組み合わせ、検証済みのCコードを自動生成するものだ。LLMが候補となる実装を提案し、証明チェッカーが、何かがデプロイされる前に数学的に正しさを確認する。コードにバグがあれば——配列境界のオフバイワンエラーのような微妙なものであっても——証明は失敗し、コードは拒否される。
自明ではない例で初めてそれを動かせたときのことを覚えている。この試み全体に懐疑的だった私のリードエンジニアは、検証済みの出力を見てこう言った。「じゃあAIがコードを書く、そしてそのコードが正しいという証明も書くのか?」と。その通りだ。そして証明チェッカーは、AIの自信など気にかけない、独立した信頼できるシステムだ——それが気にかけるのは数学的な真実だけだ。
私たちは、AIが生成したコードが手作業で書かれたコードよりも好まれる時代に入りつつある——AIがより賢いからではなく、AIが実装とともに数学的証明を生成できるからだ。
マーティン・クレップマンは最近この予測を立てたが、私は彼がまったく正しいと思う。「証明チェッカー」が門番となる。証明がなければ、デプロイもない。それはCrowdStrikeのモデルとは正反対だ。あのモデルでは、バリデーターが本質的に、自らの前提に基づいて更新を形式的に承認していただけだった。
形式検証、予測的テレメトリ、そして主権的AIアーキテクチャがどのように連携するのか、その完全な技術的分解については、私たちの研究論文を参照してほしい。
もしシステムが自ら回復できたとしたら?
7月19日について、私を悩ませ続ける一つの詳細がある。クラッシュは世界規模で、850万台すべてのエンドポイントにわたって起きた。障害のパターンを検知し、ロールアウトをリアルタイムで停止する自動化された仕組みが存在しなかったからだ。
考えてみてほしい。数百万台のマシンが同時にクラッシュし始めた。テレメトリの信号はそこにあった——境界外メモリ読み取り、即座のカーネルパニック、ブートループ。だが、自動のキルスイッチを作動させられるような形で、それらの信号を監視しているシステムは一つもなかった。
これこそ、AI駆動のテレメトリが解決するために作られた問題だ。従来の監視は静的なルールで動く。「CPU使用率が90%を超えたら警告せよ。」それは、家がすでに炎に包まれているときにしか鳴らない煙探知機を設置するようなものだ。必要なのは、「正常」が細かい粒度でどう見えるかを理解し、逸脱の最初の数マイクロ秒を検知できるシステムだ。
私たちは、研究コミュニティがAI駆動テレメトリ分析、すなわちAITAフレームワークと呼ぶものを構築してきた。これらは教師なし機械学習——アイソレーションフォレスト、オートエンコーダ、密度ベースのクラスタリング——を用いて、システムコンポーネントの挙動のベースラインを確立する。近年の研究の結果は目覚ましい。異常検知までの平均時間の35%削減、誤検知の40%削減、そして異常検知の精度は適合率97.5%、再現率96.2%に達している。
CrowdStrikeのシナリオでは、AITAを備えたシステムなら、更新が適用された最初の数ミリ秒以内に、境界外読み取りをベースライン挙動からの逸脱として検知していただろう。クラッシュが連鎖する前に、ローカルなキルスイッチを作動させ——問題のあるドライバーを隔離し、最後に正常と分かっている構成にロールバックし——ることもできただろう。850万台のマシンがダウンしたあとではない。2台目のマシンがダウンする前に、だ。
私たちはサイエンスフィクションの話をしているのではない。すでに研究の中に存在し、実運用へと移りつつあるシステムの話をしている。問題は、企業が自己修復型アーキテクチャを採用するかどうかではない。次の世界規模の連鎖の前に採用するか、それとも後になるか、ということだ。
この未来のために、実際にどう構築すればよいのか?
人々はいつも、こんな類いの質問を私にする。「わかった、これが重要だということは納得した。でも、うちの会社はすべてをゼロから作り直すことはできない。どこから始めればいい?」
もっともな質問だ。この問題に一年取り組んだ末に、私の考えが行き着いた地点を示そう。
第一に、あなたのカーネルの中で何が動いているかを監査せよ。ほとんどの企業は、Ring 0——最も深い特権レベル——でいくつのサードパーティ・エージェントが動作しているかを把握していない。それらのエージェントの一つ一つが、潜在的なCrowdStrike型のリスクだ。カーネルレベルで動作するベンダーには、段階的なロールアウト手順、クラウドバリデーターとエンドポイントインタプリタ間のスキーマのバージョン管理、そしてブートループのシミュレーションテストの証拠を提供するよう要求せよ。もし彼らがそれを提供できないなら、それが彼らのエンジニアリングの厳密さについての答えだ。
第二に、AIをUI層として扱うのをやめよ。もしあなたの「AI戦略」が、同じ2〜3のモデルプロバイダーにすべて依存するLLMラッパーツールの寄せ集めなら、あなたはCrowdStrikeの依存性問題を映し出す集中リスクを抱えている。最も重要なワークフローのために、あなたのインフラ上で動作する特化型モデルを構築あるいは獲得し始めよ。これが実践におけるAI主権の意味だ——イデオロギーではなく、運用上のレジリエンスだ。
第三に、形式検証を研究上の願望ではなく、調達の要件とせよ。ツールはすでに存在する。VeCoGenや類似のフレームワークは、検証済みコードを大規模に生成することを可能にしつつある。あらゆる安全性が重要なコンポーネント——カーネルに触れるもの、金融取引を処理するもの、あるいは医療上の判断を下すもの——については、単なるテストカバレッジの割合ではなく、正しさの数学的証明を要求せよ。
私はこの最後の点について、ある見込み客と議論した。彼は言った。「あなたは私たちに、デプロイのパイプラインを遅くしろと言っているのですね。」私はこう言った。「CrowdStrikeのデプロイのパイプラインは非常に速かった。数分で850万台のマシンに不良な更新を配信したのですから。速度が問題だったのではありません。検証のない速度が問題だったのです。」
彼は契約書に署名した。
すべてを変える判例
デルタ対CrowdStrikeの訴訟について、テック業界のほとんどの人が見落としていると私が思うことを述べよう。
重過失の判決は、単に一つの航空会社と一つのセキュリティベンダーについてのものではない。それは新たな注意義務の基準を、自動ソフトウェア更新について確立しつつある。裁判官が、段階的なロールアウトなしに未テストのコードを数百万台のマシンに配信することが重過失を構成しうると言うとき、それは同じことをしているあらゆるベンダーに適用される。裁判官が、顧客の更新設定を上書きしてカーネルレベルのコードを配信することが、契約とは独立してコンピュータ不法侵入を構成しうると言うとき、それは自動更新機構を持つあらゆるSaaS企業のルールを書き換える。
今日の「重過失」は、明日の基本的な期待水準となるだろう。段階的なロールアウト、形式検証、ランタイムの境界チェック、自己修復型テレメトリ——これらはもはや競争上の優位性ではない。裁判所や規制当局が要求する最低限の基準だ。
そして、私を怖がらせると同時に興奮させることがここにある。AI業界は、まさに同じ清算に直面しようとしている。今、ほとんどのAIシステムは確率的に動作している——「たいてい正しい」のであり、間違ったときには、私たちは肩をすくめてそれをハルシネーションと呼ぶ。だが、AIが重要インフラの奥深くへと進むにつれ——電力網を管理し、医療上の治療を承認し、金融取引を実行する——「たいてい正しい」は、「850万台のマシンに配信する前に、その更新をテストしなかった」のと同じ法的な重みを持つことになる。
CrowdStrikeの障害による100億ドルのコストは、一つのバグの代償ではない。それは、私たちがソフトウェアをどう構築し検証するかという、世界規模のアップグレードへの頭金だ。
これを理解する企業——今、Deep AI、形式検証、そして主権的アーキテクチャに投資する企業——は、次の大惨事を避けるだけではない。それが起きたあとに他の誰もが慌てて満たそうとする基準を、彼らが定義することになる。
私は、その分かれ目のどちら側にいたいかを分かっている。問題は、あなたが次の7月19日の前に選ぶのか、それとも後に選ぶのか、だ。
