たった1つのミスで世界停止？クラウドフレア障害の真相！

2025年11月18日夜、インターネット全体が悪夢に陥りました。X（旧Twitter）やChatGPTなど主要なサービスが突如つながらなくなったのです。世界中のユーザーが「スマホが壊れたのか」「サイバーテロでネットが終わったのか」と不安に陥りました。原因は、世界的大手CDN（コンテンツ配信ネットワーク）プロバイダークラウドフレアの大規模障害です。では、このクラウドフレア障害の真相とは一体何だったのでしょうか。

結論

この記事を読むメリット

今回の障害の背景や原因を詳しく知ることで、次のポイントが理解できます：

• クラウドフレア障害の本当の原因（サイバー攻撃ではなかった）
• なぜたった一つのミスが全世界に影響する事態に発展したのか
• 障害発生中にクラウドフレア内部や各サービスで何が起きていたのか
• クラウドフレアが再発防止のために講じる具体的な対策と、この事例から学べる教訓

原因：データベース設定ミスが招いた連鎖障害

障害の直接の引き金は、データベースの権限変更に伴う設定ミスでした。

クラウドフレアは社内データベース（ClickHouse）のアクセス権限を強化する目的で、2025年11月18日11時05分（UTC）に権限変更を実施しました。

しかし、この変更によってボット管理システムの特徴ファイル生成SQLクエリに潜んでいたバグが表面化しました。

本来そのクエリではデータベース名を指定する必要がありましたが、記述が抜けていたため、権限変更後は1つのテーブル情報を二重に取得してしまったのです。

こうして生成された特徴ファイルには同じボット検知用データが大量に重複記録されていたため、ファイルサイズは通常の2倍以上に膨れ上がってしまいました。普段であれば数分おきに小さなファイルを世界中のサーバーへ更新配信しますが、このときは異常に肥大化したファイルが全サーバーにばら撒かれてしまったのです。

各サーバーではネットワークの「門番」とも言えるボット管理モジュールがその新しい特徴ファイルを読み込みましたが、想定外に大きなファイルに対応できずエラーを起こしました。

このボット管理モジュールは機械学習モデルで通過する全リクエストに『ボットスコア』（不審な通信かどうかの指標）を付ける重要な役割を担っています。

ところが今回は特徴ファイル内のデータ数が許容上限（約200項目）を超えたため、プログラムがパニック状態に陥りクラッシュしました。

結果としてこのモジュールが全サーバーで次々と異常終了し、ネットワークのコアであるトラフィック処理全体が止まってしまったのです。

一見地味な1行の設定ミスが、クラウドフレア全体の機能不全を招いたことになったのです。

具体例：障害発生中に起きていたこと

障害発生後、クラウドフレアのネットワークではHTTPエラーが急増し、しばらくすると減少してまた増えるという奇妙な増減パターンが観測されました。

実は、特徴ファイルを生成するデータベースクエリが5分ごとに実行されており、更新済みノードで動いたときだけバグった巨大ファイルが生成されていたのです。未更新ノードでクエリが走れば正常なファイルが配布されるため、ネット全体が5分おきに生き返ったり止まったりする綱渡り状態に陥っていました。

普通、内部エラーなら一度壊れたらずっと止まるはずです。しかし復旧と再崩壊を繰り返す様子から、当初クラウドフレアのエンジニアは「攻撃者が意図的に強弱をつけているのではないか」と超大規模DDoS攻撃を疑いました。追い打ちをかけるように、偶然にもクラウドフレアのステータスページまでもが同じ時間帯にエラー表示となり、攻撃説を一層裏付ける形になってしまいました（実際は無関係の設定ミスによる偶発でした）。

やがてデータベース更新が全ノードに適用されると、もはや断続的な復活もなくなりネットワークは完全停止状態に陥ったのです。エンジニアチームはようやく「これは内部バグだ」と断定し、14時30分（UTC）に問題の特徴ファイルの生成と配信を停止しました。

過去の正常なファイルを手動で配信キューに投入し、全サーバーのコアプロキシ（フロントライン）プロセスを強制再起動しました。これにより主要なトラフィックはほぼ正常に戻ったのです。その後、残っていた不安定な周辺サービスも順次再起動され、全システムが完全復旧したのは17時06分でした。

では、この障害で具体的にどんな影響が出たのでしょうか。

まず、クラウドフレア経由で配信されている多くのサイトでHTTP 502/504エラーが表示され、ユーザーはページが見られない状況に陥りました。

次に、クラウドフレア提供の新しい認証システム「Turnstile」も障害で読み込みに失敗しています。その影響で、クラウドフレアの管理者用ダッシュボード自体は稼働していたものの、ログインページでTurnstileを使っていたせいで管理者がダッシュボードに入れない事態となりました。建物の中は無事なのに玄関の鍵が壊れて締め出されたようなものです。

さらに、企業向けゼロトラストサービスCloudflare Accessでも認証エラーが発生しました。インシデント開始から13時過ぎまで大半のログイン試行が失敗し、社内アプリやリソースにアクセスできない状態が続きます。この間に実施されたアクセス権設定の変更は全て失敗するか大幅に遅延し、最終的に一旦元に戻されました。

また、サーバーレス環境用データストアWorkers KVもコアプロキシ停止の影響で大量のエラーを返しました。クラウドフレアは13時04分に緊急パッチを適用し、Workers KVがコアプロキシを経由せず動作するよう変更したため、KVおよびそれに依存するAccessのエラー率は徐々に改善したのです。

メールセキュリティ機能も一時的に影響を受けました。メールの配送自体は止まりませんでしたが、スパム対策で参照しているIPレピュテーションデータにアクセスできなくなり、短時間迷惑メール検知の精度が低下した可能性があったのです。幸い重大な問題は確認されず、こちらもまもなく復旧しました。

皮肉なことに、障害発生中はエラーが多すぎて、それを記録・分析する監視システムがCPUパワーを消費し過ぎ、全体の応答をさらに遅くするという悪循環も発生していました。

まとめ：再発防止策と今後への教訓

クラウドフレアは今回の障害について「2019年以来最悪の事態」と表現し、重要インフラとしていかなる停止も許容できないと強く述べています。そして再発防止に向けて、主に次のような対策を講じると発表しました：

• 自社が生成する設定ファイルであっても、外部入力データと同様に厳格な検証を行う（サイズ上限や内容チェックを強化）
• ネットワーク全体で機能単位の非常停止スイッチを拡充する（一部の機能に不具合が起きても即座に切り離し、影響範囲を最小化）
• 障害発生時にエラーログ収集やダンプ出力などデバッグ機能が暴走しないようリソース使用に上限を設ける

今回のクラウドフレア障害は、たった1行のミスが世界のインターネットに大打撃を与えるという衝撃的な事件でした。悪意ある攻撃ではなく内部の手違いだった点は、ある意味ハッカーの攻撃以上に恐ろしい教訓です。

とはいえ、クラウドフレアの迅速な復旧対応と詳細な説明は評価できます。この失敗から得られた知見は今後のインフラ強化に活かされるでしょう。

私たちユーザーも、インターネットを支える巨大サービスであっても絶対ではないことを改めて思い知らされました。

今回の痛みを糧に、クラウドフレアがより強固で信頼できるネットワークへと進化してくれることを期待したいと思います。

おじゃ

ブログ育成中/SNS準備中

XInstagram

こんにちは！「ちょっとしあわせブログ」を開設して100記事を突破しました。おかげさまで訪問者やページビューも着実に増え、ブログの成長を日々実感しています。これまで培った経験や学びのヒントを、分かりやすく丁寧にお届けすることが私のモットー。これからも読者の皆さんとともに成長し、役立つ情報やアイデアを発信していきますので、どうぞよろしくお願いします！