【悲報】「二度と起こさない」はずが…Cloudflare、まさかの“自己責任”で世界を止める
世界を巻き込んだCloudflare大規模障害の全貌と、二度目の悲劇が示した教訓
2025年12月6日、インターネットの基盤を支える大手CDNサービス、Cloudflareで再び大規模な障害が発生しました。世界中のウェブサイトが一時的にアクセス不能となり、多くのユーザーに混乱と不便をもたらしました。これは、わずか2週間前に発生した同様の障害から間もない出来事であり、その原因と背景には、IT業界全体が直面する課題が浮き彫りになっています。
「正義の自爆」：脆弱性対策が招いた予期せぬ結果
今回の障害は、サイバー攻撃によるものではありませんでした。CloudflareのCTOによると、その発端は、リアクトサーバーコンポーネンツに見つかった「超危険な脆弱性」、通称「リアクトニチェル」への対応でした。この脆弱性が悪用されれば、サーバーが乗っ取られる可能性があったため、Cloudflareは緊急の対策を講じることになります。
彼らは、この攻撃を防ぐための新しいルールをWebアプリケーションファイアウォール（WAF）に適用しようとしました。WAFが検査できるデータのサイズを従来の128KBから1MBに増やすという変更は、段階的にロールアウトされていましたが、ここで思わぬ問題が発生します。社内のWAFテストツールが、この新しいサイズに対応していなかったのです。
エンジニアは、顧客の通信には直接関係のないこのテストツールを一時的にオフにすることを決定しました。しかし、この「一時的なオフ」こそが、パニックの連鎖を引き起こす引き金となります。本来、慎重に段階的に適用されるべき変更が、このテストツールをオフにする変更に限って、全世界のサーバーに数秒で反映されるシステムを使って実行されてしまったのです。
システム内部で何が起きたのか？：古いプロキシと「ぬる参照」の悲劇
結果として、古いバージョンのプロキシ「FL1」を使用しているサーバーで、テストツールをオフにした瞬間、内部のプログラムであるLuaスクリプトがパニックを起こしました。プログラムは実行すべきルールがないことに混乱し、無効な値（nil）を参照しようとしてエラーを吐き出してクラッシュしたのです。これはプログラミングにおける典型的な「ぬる参照」のエラーであり、結果として、Cloudflareを経由する全トラフィックの約28%が影響を受け、世界中のウェブサイトがダウンする事態となりました。
幸いにも、この影響を受けたのは、古いプロキシを使用し、かつ特定のルールセットを使っていた顧客に限られたため、全体の28%という数字に留まりました。障害は設定変更の直後に検知され、約25分後には元に戻されましたが、このわずかな時間で世界中のウェブサイトが停止するという、大きな混乱を招くことになりました。
この「ぬる参照」のバグは、何年も前から存在していましたが、実行アクションに対してキルスイッチを使うという稀な組み合わせが今回初めて発生したため、これまで発覚することがありませんでした。もし、Cloudflareが現在推進している新しい言語「Rust」でこのシステムが書かれていれば、コンパイル段階でエラーが防げていた可能性も指摘されています。古いシステムが抱える「技術的負債」が、皮肉にも今回の大規模障害の核心であったと言えるでしょう。
教訓は生かせず：対策は間に合わなかった
今回の障害で多くの人々が疑問に感じたのは、わずか2週間前に同様の障害が発生していたにもかかわらず、なぜその教訓が生かされなかったのかという点でした。公式発表によると、対策方法は分かっており、計画も進められていたものの、残念ながら実装が間に合わなかったというのが実情でした。
前回の事故後、Cloudflareは段階的な展開（世界一斉ではなく少しずつ変更を適用する仕組み）や、フェイルオープン（設定ファイルが壊れても通信を遮断せず、とりあえず通信を維持する仕組み）といった再発防止策を練っていました。しかし、システムが巨大すぎたために、これらの安全装置を取り付ける工事が完了する前に、今回の「リアクトの脆弱性」対応という次のトラブルが襲いかかってきたのです。
この事態を受け、Cloudflareは「変更のロックダウン（凍結）」という究極の手段に出ました。安全装置が完全に機能するまでは、ネットワークへの設定変更を一切禁止するという措置です。これは、もはや技術的な問題だけでなく、組織としての判断ミス、あるいは巨大なシステムを運用する上での避けられない課題を浮き彫りにしています。
ネットの反応
レイオフした分の人件費分が二回の損害でとっくに吹き飛んでそう
まさかの続編で激アツ
またしても現場猫案件か
めっちゃ公開直後見れた
結局凡ミスだったのか…ほぼ同時期に一部で障害報告が出てきたAWSは、Cloudflareのフェイルセーフに使ってたサービスが障害時に一斉に切り替わった結果、果てしない負荷が掛かって一部落ちてしまった、貰い事故みたいなことだったのかな。
また起きそう
もうほんとに運が悪かったとしか…復旧早かったのがまだ救いかな…
CF、お茶目だなぁ実質Meちゃん
「二度あることは三度ある」などと申しましてな・・・
言い訳じゃなくてこれはもう。。Cloudflare可愛そうだろ。。
誠に遺憾であります
この前の障害でクラウドフレアを外したTwitterは英断だったな
前回と今回で2人はクビになってそう
スクリプトファイル作るのに検索した構文そのままコピペの自分と同じレベルのことやってる・・・クラウドフレアの技術者は素人同然ってこと・・・？
いやこれ防ぐの無理に近い。どうせカネも人員も割いてないんだろうすし
．∧＿∧
（ ´∀｀）＜ ぬるぽ（ ・∀・） | | ｶﾞｯ
と ） | |
Ｙ /ノ 人
/ ） __Λ∩
＿/し' ／／. Ｖ｀Д´）/ ←>>1
（＿フ彡 /ﾌｧｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｗｗｗｗｗ
ぬるぽ
まさかのパート2がどうもブラックフライデーで散してしまった霊夢と1年が早すぎて怖い魔理沙ちゃんだぜ。
今回もITニュースまるよ。それで今回は何の話題かしら?今回は昨日起こったクラウドフレア大規模障害についてついに公式からことの真層が発表されたという話だ。
お待ってました。で犯人は誰なの?ハッカー。それともまた自爆。結論から言うと今回も自爆に近いが同機は正義だったは正義の自爆意味わかんないんだけど
AIの所感
今回のCloudflareの大規模障害は、一見すると単純な設定ミスや「凡ミス」として片付けられがちですが、その裏には巨大なシステムを運用する上での複雑な課題が横たわっています。最新のセキュリティ脅威に対応しようとする「正義」の行動が、皮肉にも古いシステムに残された「技術的負債」と予期せぬ形で結合し、世界規模の障害へと発展した点は、ITインフラの脆弱性を再認識させます。特に、過去の教訓が活かされず、対策の実装が間に合わなかったという事実は、技術的な解決策だけでなく、組織としての優先順位付けやリスク管理の重要性を強く示唆しています。インターネットの安定性は、常にこのような見えない努力と、時に生じる悲劇的な失敗の上に成り立っていることを、今回の件は私たちに改めて教えてくれていると言えるでしょう。また、ユーザーのコメントからは、今回の障害に対する戸惑いや皮肉、そしてシステム運用への厳しい目がうかがえ、社会インフラとしてのITサービス提供者の責任の重さを感じさせます。