2025年11月18日（日本時間20:20頃）、インターネットインフラの中核を担うCloudflareで大規模なネットワーク障害が発生し、世界中のウェブサイト・サービスが一時的にアクセス不能となりました。ユーザーにはCloudflare由来のエラーページが表示され、多くのプラットフォームでHTTP 5xxエラーが急増する事態に発展しました。
CEOのMatthew Prince氏が同日中に公開した詳細なポストモーテムによると、この障害はサイバー攻撃ではなく、純粋に内部の構成変更に起因するものでした。ClickHouseデータベースの権限管理を改善するための変更が、Bot Managementシステムのフィーチャーファイルに大量の重複行を生み、ファイルサイズが想定の2倍に膨れ上がったことが発端です。この巨大化したファイルがネットワーク全体に配信されると、プロキシソフトウェアのメモリ制限（200フィーチャ）を大幅に超え、プロキシがパニック状態に陥り、コアトラフィックの処理が停止しました。
当初チームは「超大規模DDoS攻撃」を疑いましたが、約3時間後の日本時間23:30までに正しい原因を特定し、過去の正常ファイルを強制適用することで主要サービスを復旧。翌19日2:06には完全に正常化しました。この事件は、Cloudflareが「2019年以来最悪の障害」と位置づけるほど深刻で、インターネット全体の脆弱性を改めて浮き彫りにしました。本記事では、公式発表に基づき、技術的背景から復旧プロセス、今後の再発防止策までを客観的に解説します。
障害の概要と特徴的な挙動
障害は日本時間11月18日20:20に突然開始され、Cloudflareネットワーク全体で5xxエラーが急増しました。通常は極めて低い5xxエラー率が、数分で異常値に達したのです。
特徴的だったのは「断続的な回復と再発」を繰り返した点です。システムが一度回復したかに見えても、数分後に再びダウンする波状的な挙動は、過去の典型的な攻撃や障害とは異なり、原因特定を難しくしました。
この理由は、フィーチャーファイルが5分ごとにClickHouseクラスタから生成・配信されていたことにあります。クラスタの一部ノードだけが新しい権限設定に更新されていたため、生成されるファイルが「正常」と「異常」を交互に出力していました。最終的に全ノードが更新されると、異常ファイルのみが配信されるようになり、エラーは安定して継続状態となりました。このような「断続回復」は、攻撃を疑わせる要因の一つだったとPrince氏は記しています。
詳細タイムライン（すべて日本時間）
| 時間 (JST) | 状況 | 内容 |
|---|---|---|
| 11月18日 20:05 | 変更適用 | ClickHouseの権限管理変更を段階的に展開開始 |
| 11月18日 20:20 | 障害開始 | 異常フィーチャーファイル配信開始、5xxエラー急増 |
| 11月18日 20:32～22:05 | 調査・初期対応 | Workers KV高負荷と誤認、DDoS対策を試みるも効果なし |
| 11月18日 22:05 | 一部緩和 | Workers KV・Accessを旧プロキシにバイパス、影響軽減 |
| 11月18日 22:37 | 原因絞り込み | Bot Managementフィーチャーファイルが原因とほぼ確信 |
| 11月18日 23:24 | 異常ファイル生成停止 | 新規ファイル生成・配信を緊急停止 |
| 11月18日 23:30 | 主要復旧 | 過去の正常ファイルを強制適用、コアトラフィックがほぼ正常化 |
| 11月19日 2:06 | 完全復旧 | 全サービス再起動・確認完了 |
影響を受けたサービスと実際の被害範囲
障害はCloudflareのコアプロキシ（Frontline）を経由するほぼ全てのトラフィックに波及しました。主な影響は以下の通りです。
| サービス・製品 | 影響内容 |
|---|---|
| Core CDN / WAF / DDoS保護 | HTTP 5xxエラー多発、キャッシュなしオリジンリクエストはほぼ全滅 |
| Turnstile | 読み込み失敗、ダッシュボードログイン不能 |
| Workers KV | 高頻度5xxエラー |
| Dashboard / API | ログイン不可（既存セッションは維持）、設定変更遅延や失敗 |
| Cloudflare Access | 新規認証ほぼ全失敗（既存セッションは影響なし） |
| Email Security | 一部IPレピュテーション参照失敗、新規ドメイン検知停止（重大被害はなし） |
外部報道では、X（旧Twitter）、ChatGPT、Discord、Crunchyroll、League of Legendsなど多数の人気サービスが同時ダウンしたと報じられており、インターネット全体の約20％のトラフィックを扱うCloudflareの影響力の大きさを物語っています。
Bot Managementシステムとフィーチャーファイルの役割
CloudflareのBot Managementは、毎リクエストに機械学習モデルで「ボットスコア」を付与し、悪性ボットをブロックする重要なセキュリティ機能です。
モデルは数百の「フィーチャ」（特徴量）を入力に使い、リアルタイムで進化するボット攻撃に対応するため、数分ごとに更新されるフィーチャーファイルを全世界のエッジサーバに配信しています。このファイルは従来は固定サイズ近かったのですが、今回の障害で突然2倍以上に膨張しました。
根本原因：ClickHouse権限変更が引き起こした連鎖
問題の起点は、ClickHouseクラスタの分散クエリをより安全にするための権限変更でした。
- 従来：分散テーブル（defaultデータベース）経由のクエリは共有システムアカウントで実行
- 変更後：初期ユーザーアカウントで実行するよう段階展開 → より細かい権限管理が可能に
この変更により、system.columns などのメタデータクエリが、従来見えていなかった下層シャード（r0データベース）のテーブル情報も返すようになりました。Bot Managementのフィーチャ生成クエリはデータベース名を明示的に指定していなかったため、重複行が大量発生し、結果としてフィーチャ数が60→200超に急増しました。
プロキシ側ではパフォーマンス最適化のため、フィーチャ用メモリを最大200で事前割り当てしていました。200超のフィーチャが来るとRustコードでunwrap()パニック → ワーカースレッド全滅 → 5xxエラー連鎖が発生しました。
旧プロキシ（FL）と新プロキシ（FL2）の挙動差
Cloudflareは現在、旧世代（FL）と新世代Rust製（FL2）プロキシへの移行中です。今回の障害では両者に異なる症状が出ました。
| プロキシ | 主な言語 | 障害時の挙動 | 顧客への実際の影響 |
|---|---|---|---|
| FL（旧） | C++ | パニックせずファイル読込成功→全ボットスコア0 | ボットブロックルール使用顧客で良性トラフィックまでブロック（偽陽性急増） |
| FL2（新） | Rust | unwrap()パニックでワーカー全滅 |
直5xxエラー、トラフィックほぼ停止 |
結果、新プロキシ移行済み顧客の方が体感被害が大きかったと推測されます。
復旧プロセスと対応の評価
良い点
- 原因特定まで約3時間と比較的迅速（最初はDDoSと誤認したが、粘り強く追跡）
- Workers KV・Accessを旧プロキシに緊急バイパスし、影響範囲を即座に縮小
- 同日中に極めて詳細なポストモーテムを公開（コード片・内部チャットまで開示）
- 影響を受けた顧客への直接謝罪と透明性
改善が必要な点
- 内部生成ファイルに対しても「外部入力同等のバリデーション」がなかった
- メモリ事前割り当て上限が硬直的で、超過時のフェールオープン設計ではなかった
- クエリが「データベース名省略」に依存していた脆弱な仮定
- グローバルキルスイッチが機能・モジュール単位で不足
今後の再発防止策（公式発表より）
Cloudflareは既に以下の対策に着手しています。
- Cloudflare自身が生成する設定ファイルも「外部入力と同等にサニタイズ
- 主要機能ごとにグローバルキルスイッチを追加実装
- エラー時のコアダンプ等によるリソース枯渇を防止
- 全コアプロキシモジュールでエラー条件のフェイルセーフを再検証
Prince氏は「2019年以来最悪の障害であり、到底許容できない」と述べ、システムのレジリエンシーをさらに高める決意を示しています。
結論：インターネット集中化のリスクと教訓
2025年11月18日のCloudflare障害は、たった一つの権限変更が、想定外の連鎖で世界規模の停止を引き起こし得ることを改めて示しました。
Cloudflareの対応は透明性が高く評価できますが、同時にCDN・セキュリティベンダーへの過度な集中がもたらすリスクも浮き彫りにしました。単一障害点（SPOF）を避けるマルチベンダー構成や、重要なサービスでのフェイルオーバー設計の重要性が再認識されています。
Cloudflareは過去の障害からも毎回学び続けており、今回の対策が確実に実行されれば、再び信頼を回復するでしょう。しかしインターネット全体で見ると、こうした「一社依存」の構造自体を問い直すきっかけとなる事件だったと言えます。