2025年11月18日、Cloudflareのグローバルネットワークにおいて広範なサービス障害が発生し、世界中の利用者がHTTP 5xxエラーや各種サービスの不安定さに直面しました。
本障害はCDNトラフィックの処理失敗、Workers KVの高エラー率、Turnstileを用いたログイン機能の停止、Accessにおける認証障害など、多岐にわたるサービスへ影響を及ぼしました。Cloudflareは発生直後の公式アナウンスにおいて、外部からの攻撃ではなく内部要因による障害であることを明確にしています。障害の根本原因は、Bot Management機能で利用される構成情報が誤って生成され、エッジネットワーク全体に配布されたことにより、プロキシ層が想定外の入力を処理できずに異常終了した点にあります。
本記事では、Cloudflareが公開した公式ポストモーテムの内容を基に、障害の発生経緯と技術的背景、影響範囲、対応措置、再発防止策について体系的に整理します。合わせて、分散システムにおけるコントロールプレーンの脆弱性や、想定外の入力に対する設計上の課題など、今回の障害が示唆する構造的な問題についても解説します。
障害の概要
2025年11月18日11時20分（UTC）頃、Cloudflareのグローバルネットワークにおいて、HTTPリクエストの処理が広範に失敗する大規模障害が発生しました。障害は短時間で世界中のエッジネットワークに波及し、多数のサービス利用者がHTTP 5xxエラーを受け取る状態となりました。Cloudflareは初期段階で「外部からの攻撃ではなく内部要因による障害」であることを明確にし、影響が全社的かつ多面的であることを早期に認識しています。
本障害は、Bot Managementに関連する内部コンポーネントが生成する構成ファイル（feature file）の異常が契機となり、これが全エッジに一斉配布されたことで、プロキシ層が想定外のデータを処理できず異常終了したことにより発生しました。この構成ファイルは、本来ボット判定に使用する特徴量を定義するもので、通常はネットワーク全体で安定的に利用されています。しかし今回は、内部データベースアクセス制御の変更を契機として内容に重複行が混入し、結果として構成ファイルが異常に肥大化しました。
異常な構成ファイルを受け取ったエッジサーバーは、特徴量読み込み処理において例外を発生させ、HTTPトラフィックの処理を継続できなくなりました。その結果、CDNサービスを中心に大量のHTTP 5xxが発生し、Workers KVやAccessなどCloudflareの中核サービスにも連鎖的な影響が及びました。障害は断片的なものではなく、Cloudflareが提供するサービスの幅広い分野に影響が広がり、同社が「ここ6年で最も深刻な障害」と評価する規模となりました。
発生メカニズム
今回の障害は、単一の不具合によって引き起こされたものではなく、内部構成変更・データ生成ロジック・エッジ側処理の三つが連鎖的に作用した結果として発生しています。Cloudflareが公開したポストモーテムによれば、問題の起点はBot Management機能で利用される特徴量定義ファイル（feature file）の異常生成にあり、これがエッジネットワーク全体に配布されたことで、各サーバーが想定外の入力を処理できずに例外を発生させました。さらに、この異常ファイルが生成される背景には、社内データベース環境に対するアクセス制御の変更があり、複数の要因が重なって構成データに重複行が混入したことが確認されています。
以下では、障害に至った主要要因を順を追って整理し、どのようなプロセスを経て広域障害へと拡大したのかを詳細に説明します。
1. feature file の異常生成
Cloudflareのポストモーテムによれば、本障害の直接的な契機となったのは、Bot Management機能が利用する「feature file」と呼ばれる特徴量定義ファイルの異常生成です。このファイルは、ボット判定モデルが使用する特徴量の一覧を含むもので、通常は安定的かつ一貫した形式で生成され、世界中のエッジネットワークへ配布されています。
しかし今回、ファイル内部に大量の重複エントリが混入する異常が発生しました。本来この feature file は、特徴量の名前を一意に列挙する設計となっており、Cloudflareによると通常の特徴量数は60程度で推移していました。一方、内部コードでは特徴量の上限を200個とするハードリミットが定義されていたものの、実際にはこの上限が超過し得る場合のバリデーションが実装されておらず、異常なファイルサイズがそのまま配布対象となってしまいました。
この異常生成は、内部データベースの参照動作に影響を与える構成変更が間接的な要因となっています。具体的には、ClickHouseデータベースへのアクセス制御を変更した結果、特徴量を生成するクエリが default スキーマ以外のテーブルも列挙するようになり、その結果として重複した特徴量名が多数生成されました。このように、feature file の異常は単独で発生したものではなく、データソースの仕様変更と生成ロジックの設計上の前提が食い違ったことにより誘発されたものです。
その後、この異常ファイルが自動的にエッジサーバーへ配布されたことで、後続の処理モジュールが想定外のデータを受け取り、各エッジにおける特徴量読み込み処理が例外を発生させる結果につながりました。
2. コントロールプレーン上での構成変更が誘発
feature file の異常生成の背景には、Cloudflare内部で実施されたデータベースアクセス制御に関する変更が存在していました。Cloudflareのポストモーテムによれば、この構成変更はClickHouseデータベースに対するアクセス許可設定を見直すもので、特定のクエリが参照可能とするスキーマの範囲に影響を与えるものでした。本来、Bot Managementの特徴量生成処理は default スキーマに存在するデータのみを前提として実装されていましたが、この変更によって、意図せず他スキーマに存在するテーブルやデータが列挙されるようになりました。
この動作変更により、特徴量生成プロセスが複数のスキーマから重複した名前のエントリを取り込んでしまい、結果としてfeature file内部に多数の重複が発生しました。本来であれば、このような異常を検知・除外するロジックが必要ですが、生成側が「参照されるスキーマは単一である」という前提で設計されていたため、重複データの存在を想定した検証処理は実装されていませんでした。
さらに、Cloudflareのアーキテクチャでは、コントロールプレーンが生成した構成データが自動的かつ迅速にグローバルエッジへ配布される仕組みが採用されています。これは通常、高速な機能更新や一貫した動作の確保に寄与しますが、今回のように誤った構成が生成された場合、短時間で全世界のネットワークに展開されるという副作用も持っています。今回も例外ではなく、異常なfeature fileはコントロールプレーンから迅速に配布され、広域障害へ直結する結果となりました。
このように、コントロールプレーン側の構成変更が想定外のデータ参照を引き起こし、それがfeature fileの異常に直結した点は、本障害の中心的な誘因であり、複数の内部要素が連鎖的に動作した典型的な事例といえます。
3. Rust 実装側の “unwrap()” による panic
異常な feature file がエッジサーバーに配布されたことで、本来の設計前提を満たさない入力がプロキシ層の処理モジュールに到達しました。Cloudflare が公開したコード断片によると、Bot Management の特徴量読み込み処理では append_with_names() を呼び出した後に unwrap() を用いて結果を即時に取得する実装が行われていました。unwrap() は結果が正常であることを前提とした操作であり、失敗時には例外（panic）を発生させます。
この処理には、特徴量の数が想定の上限（200件）を超える可能性を考慮したバリデーションが存在していませんでした。Cloudflare の説明では、通常の特徴量数はおよそ60件で推移しており、200件という値は実質的に「到達しない前提のハードリミット」として扱われていました。しかし今回、feature file に大量の重複エントリが混入したことにより、上限値を超過した異常データがそのまま処理対象となり、unwrap() による例外が発生しました。
Rust はメモリ安全性を重視する言語ですが、今回のように想定外の入力がバリデーションなしで処理される場合、ロジックレベルの例外を防ぐことはできません。Cloudflare もポストモーテムの中で、構成ファイルのような外部入力に対して unwrap() を使用していた点を反省点として挙げています。Result のエラーパスを考慮した明示的なハンドリングや、上限チェックを含む堅牢な入力検証が行われていれば、エッジサーバーのプロキシ層が停止する事態には至らなかった可能性があります。
この例外は、各エッジサーバーのリクエスト処理を直接停止させる効果を持っており、結果としてHTTP 5xxエラーの急増につながりました。異常構成が全世界へ短時間で配布されたことにより、同一の例外が各地で連続的に発生し、広域障害として顕在化したことが今回の特徴です。
影響範囲
今回の障害は、Cloudflare が提供する複数の中核サービスに広範な影響を及ぼしました。影響は単一サービスにとどまらず、エッジネットワーク全体のHTTP処理系統、アイデンティティ関連サービス、サーバレス実行環境など多方面に波及し、Cloudflare 自身が「ここ6年で最も深刻な停止」と表現する規模となりました。
まず、最も顕著な影響はHTTPトラフィック処理の失敗です。異常な feature file を読み込んだエッジサーバーは、プロキシ層が想定外のデータを処理できずに panic を起こしたため、全世界でHTTP 5xxエラーが急増しました。これにより、Cloudflare の CDN を利用する多数のWebサイト・APIが応答不能または著しく不安定な状態となりました。
また、Workers KV に関しては、フロントエンドゲートウェイが一部正常に動作できない状況となり、高いエラー率を記録しました。Workers KV はCloudflare Workers のデータストアとして広く利用されていることから、サーバレスアプリケーション全般にも影響が及びました。
認証基盤である Cloudflare Access も影響を受けました。具体的には、新規の認証リクエストやセッション更新処理が失敗し、一部のユーザーが保護されたアプリケーションにアクセスできない状態となりました。既に確立されていたセッションは比較的正常に維持されましたが、管理操作や設定変更には支障が出ています。
さらに、Cloudflare Dashboard においては、Turnstile を利用したログイン処理が障害に巻き込まれ、多くのユーザーが管理画面にアクセスできない状態が発生しました。Turnstile 自体がCloudflareのリバースプロキシの正常動作に依存する構造であるため、今回の障害の影響を直接受ける形となりました。
加えて、エッジサーバーのプロキシ層ではCPU負荷が異常に上昇し、リクエスト処理の遅延が発生しました。これは障害の二次的影響であり、ネットワーク全体のレイテンシ増大という形で利用者が体感するサービス品質にも影響を与えました。
このように、今回の障害はCloudflareの基盤サービスの多くが連鎖的に影響を受ける結果となり、コントロールプレーン由来の構成異常がどれほど広範囲に影響を与えるかを示す典型的な事例となりました。
対応と復旧プロセス
Cloudflare は障害発生後、段階的に影響範囲を限定しながら復旧措置を進めました。公式ポストモーテムには、主要な対応のタイムラインが明確に記載されており、特に問題の構成ファイル（feature file）の停止と正常版の再配布が復旧の中心的な要素となっています。以下では、事実に基づき時系列で対応内容を整理し、時刻はUTCとJSTで併記します。
13:05 UTC（22:05 JST）
Cloudflare はまず、影響が大きかった Workers KV および Cloudflare Access に対し、プロキシ層を迂回するバイパス処理を導入しました。これにより、コントロールプレーン由来の異常構成に依存する部分を極力排除し、一部サービスのエラー率を早期に低減することに成功しています。完全な復旧ではありませんが、サービス全体の不安定さを抑制する重要な措置となりました。
14:24 UTC（23:24 JST）
次に、問題の原因となっていた feature file の生成・配布プロセスを完全に停止しました。異常ファイルを解析したうえで、最新でありながら構造的に正常であるバージョンを安全に利用できることを確認し、その正常版を再度配布できるよう準備を進めました。この段階は、障害の根本原因に対する直接的な対応として位置付けられています。
14:30 UTC（23:30 JST）
検証済みの正常な feature file がエッジネットワーク全体に向けて再配布されました。エッジサーバーが正常構成を受け取ったことで、HTTP 5xxエラーの発生率が徐々に減少し、主要サービスの機能回復が開始されました。データプレーン側のプロキシ処理が正常化したことにより、CDN トラフィックの復旧が進み、利用者が体感する障害も時間とともに改善しています。
17:06 UTC（翌日 02:06 JST）
すべての関連コンポーネントの再起動と動作確認が完了し、Cloudflare は全サービスが正常な状態に復帰したと発表しました。プロキシ層・Workers KV・Access・Dashboard の動作は安定し、異常構成や高負荷状態は完全に解消されています。障害発生から完全復旧までの所要時間は約6時間弱となりました。
以上の通り、Cloudflare は障害発生直後から影響の切り分けと暫定的バイパス、根本原因となる構成ファイルの停止と再配布、さらに全コンポーネントの再起動と全体整合性の確認を段階的に実施し、グローバル規模の障害に対する復旧を完了しています。
再発防止策
Cloudflare は本障害の再発を防ぐため、構成データの生成プロセス、プロキシ層のエラーハンドリング、そしてネットワーク全体への構成配布方法について包括的な改善を実施すると発表しています。公式ポストモーテムでは、今回の障害が単一の不具合ではなく、複数の前提条件が重なって発生した点を踏まえ、個別の修正にとどまらず、コントロールプレーンとデータプレーンの双方に対して構造的な改善を行う必要性が強調されています。
具体的には、feature file のような外部入力相当の構成データに対する検証強化、誤った構成を即時に遮断するキルスイッチ機構の整備、そしてプロキシモジュールにおける例外発生時の挙動を見直す方針が示されています。これらの取り組みは、分散システムにおける構成配布の信頼性向上を目的としており、将来的に同様の構造的障害が発生するリスクを低減するための重要な対策と位置付けられています。
1. 設定ファイルの取り込み処理をより堅牢化
Cloudflare は、feature file を含む構成データの取り込み処理を外部入力と同等の扱いに引き上げ、検証プロセスを強化する方針を示しています。今回の障害では、内部生成された構成ファイルであるにもかかわらず、内容が異常である可能性を前提にしたチェックが十分に行われていなかった点が問題の一因となりました。特に、特徴量名の重複検出や項目数の上限チェック、スキーマ整合性の確認といった基本的なバリデーションが行われていなかったため、想定を超える異常データがそのままエッジサーバーに配布され、panic の発生につながりました。
Cloudflare のポストモーテムによれば、今後は構成ファイルの生成段階において、重複や不整合を検出する仕組みを追加し、問題が見つかった場合には配布プロセスを自動的に停止する仕組みを導入するとしています。また、データサイズや項目数が想定を超えていないかを機械的に検証し、閾値を超えるケースについては安全に失敗させる動作を標準化する方針も示されています。これにより、今回のようにコントロールプレーン側の構成異常がデータプレーン全域に波及するリスクを低減する狙いがあります。
この強化策は、内部生成データであっても信頼しすぎず、予期しない入力として扱うべきという教訓に基づいており、構成管理の堅牢性を高めるうえで不可欠な改善といえます。
2. グローバルキルスイッチの実装
Cloudflare は、誤った構成データや問題のある機能を即時に無効化できる「グローバルキルスイッチ」を実装する方針を示しています。今回の障害では、異常な feature file が生成されてからエッジネットワーク全体に配布されるまでのプロセスを止める手段が十分に整備されておらず、誤った構成が短時間で全世界に広がる結果となりました。この点について、Cloudflare 自身が「異常検知後に構成配布を即座に停止できる仕組みが不足していた」と明確に指摘しています。
グローバルキルスイッチは、特定の構成ファイルやモジュールをグローバルに無効化し、機能を強制的にオフライン化するための仕組みです。これにより、コントロールプレーンで生成された構成に異常があった場合でも、配布を停止しつつ既存の安定版構成へ即時に切り替えることが可能になります。Cloudflare は、今回の障害対応で feature file の生成停止やバイパス処理を手動で行いましたが、将来的にはこれらを自動的かつ瞬時に実行できる仕組みを整備するとしています。
この改善策は、コントロールプレーンが分散システム全体に与える影響を最小限に抑えるために不可欠であり、異常構成が瞬時に全世界へ伝搬するリスクを軽減する役割を果たします。特に Cloudflare のように構成更新が高速自動化されている環境では、誤配布を防ぐ「最後の防壁」としてキルスイッチの重要性が非常に高いといえます。
3. プロキシモジュール全体の失敗モードの再点検
Cloudflare は、エッジにおけるプロキシモジュールの失敗モードを全面的に再点検する方針を示しています。今回の障害では、特徴量読み込み処理において unwrap() を使用する実装が存在し、想定外のデータが入力された際に即座に panic を引き起こす構造となっていました。Cloudflareはポストモーテムで、このような実装が外部由来の構成データを扱う際には不適切であると明確に指摘し、今後は例外発生時の挙動をより堅牢に設計する必要があると述べています。
再点検の対象となるのは、単一の関数やモジュールにとどまりません。プロキシ全体の処理系統が、異常な構成データやフォーマット不整合に対してどのように振る舞うべきかを網羅的に見直すことが求められています。特に、構成データの読み込み時に安全に失敗させる「フェイルオープン」または「フェイルセーフ」の選択基準、過去の正常データへのロールバック戦略、異常検知後の影響範囲の限定など、多層的な防御策が検討されています。
Cloudflare は、構成データを信頼しすぎる実装が広域障害を引き起こすリスクを再認識したとしており、プロキシモジュールの例外処理や防御ロジックの改善を優先的な取り組みとして位置づけています。これにより、将来的に同様の異常構成が配布されたとしても、エッジサーバー全体が一斉に停止するような事態を回避できることが期待されています。
今回の障害が示した構造的課題
今回の障害は、単なる実装上の不具合にとどまらず、Cloudflare のような大規模分散システムが本質的に抱える構造的課題を改めて浮き彫りにしました。最大の特徴は、障害の起点がデータプレーンではなくコントロールプレーンに存在していた点です。コントロールプレーンは、サービス全体の設定・メタデータ・機能の有効化状態などを一元的に管理し、世界中のエッジノードへ迅速に配布する役割を担っています。この集中管理の利便性は、機能更新やセキュリティ対策の高速化に寄与する一方、誤った構成が配布された場合には短時間で全世界に影響が波及するという性質を持っています。
Cloudflare の今回の事例は、まさにその典型例です。feature file の異常生成は単一の内部変更に起因していましたが、その構成がグローバルに配布されたことで、各エッジサーバーが同一の異常データを処理し、同じ失敗モードに陥りました。これは、コントロールプレーンが論理的に「単一障害点（Single Point of Failure）」として機能していたことを示しています。物理的には多重化されていても、構成配布経路や生成ロジックが一つに集約されている限り、論理的な一本化は避けられません。
この構造的課題は Cloudflare に限ったものではなく、AWS、Azure、GCP など他のクラウドベンダーでも度々指摘されています。たとえば、AWS のIAM障害やRoute 53の設定誤配布、Azure Active Directory の大規模ログイン障害など、いずれもコントロールプレーンの異常が広域障害に直結しています。今回の事例は、分散システムがどれだけ広く構築されていても、管理プレーンに存在する「弁慶の泣きどころ」が依然としてリスクの源泉であることを裏付けています。
また、設定データの取り扱いにおける前提依存の危うさも明らかになりました。内部生成データであるにもかかわらず、検証を省略したまま使用していた点は、設計上の思い込みが危険性を増幅させる典型例といえます。特徴量が上限に達する可能性は低いという過去の経験に依存した判断が、予期せぬ障害として顕在化しました。このような「起こらないはず」という前提が継続している限り、同種の障害は将来的にも発生し得ます。
以上のことから、本障害は大規模分散システムの設計において、コントロールプレーンの安全性・検証プロセス・ロールバック戦略をいかに強化するかが極めて重要であることを示しており、システム全体の健全性を保つ上で避けられない課題であることが明確になりました。
おわりに
今回の障害は、Cloudflare の高度に分散されたインフラストラクチャであっても、内部の前提や設計思想が揺らいだ瞬間に広域障害へと直結することを示す象徴的な事例でした。Rust のような安全志向の言語を採用していても、想定外の入力を考慮しない実装や、ハードリミットを前提としたロジックが残存している場合、重大な障害を防ぐことはできませんでした。内部データであっても「常に正常である」という前提を置かないこと、そして極端なケースであっても安全に処理できる設計が不可欠であることが改めて浮き彫りになったといえます。
また、今回の障害は、コントロールプレーンが論理的な単一障害点として機能してしまう構造的課題を強く印象付けました。物理的な多重化が存在していても、設定生成・構成配布・メタデータ管理が特定の経路やロジックに集中している限り、誤った構成が短時間で全世界に波及するリスクは避けられません。この問題は Cloudflare に限らず、AWS や Azure を含む大規模クラウドに共通する根源的な課題であり、「どこが止まると全体が止まるのか」という弁慶の泣きどころを常に把握し、そのリスクを抑え込む設計と運用が求められます。
分散システムは拡大するほど複雑化し、単一障害点の影響は増幅されます。その中で、入力検証の徹底、異常構成の即時遮断、ロールバックの簡易化、そして前提条件を定期的に点検する文化は、可用性を維持するための基盤となります。今回の障害は、技術的な改善だけでなく、前提に依存しない設計と運用の重要性を再認識する契機となったといえるでしょう。
参考文献
- Cloudflare outage on November 18, 2025
https://blog.cloudflare.com/18-november-2025-outage/