2025年11月18日のCloudflare障害で実際に何が起きたのか？シンプルに解説

2025年11月18日、UTC午前11時20分、世界中の何百万人もの人々が突然、インターネットで最も人気のあるウェブサイトの一部にアクセスできなくなった。ChatGPT、Spotify、X（Twitter）、Shopify、Canvaがすべてダウンした。とっさの反応は？「クラウドが落ちた！」というものだった。しかし、ここに驚くべき真実がある： クラウドは問題なかった。アプリは正常に動いていた。壊れていたのは、多くの人が聞いたことのないもの—— Cloudflareだった。

この事例は、ネットワーク障害と クラウド障害の違いを理解することがいかに重要かを完璧に示している——特にインターネットに依存するビジネスを運営している場合（つまり、今日ではほぼすべてのビジネス）はそうだ。

Cloudflareとは何で、なぜ重要なのか？

インターネットを巨大なハイウェイシステムのようなものだと考えてほしい。あなたのウェブサイトやアプリは、道の終わりにある店舗のようなものだ。Cloudflareは、顧客と店舗の間に位置するハイウェイ、交通信号、セキュリティチェックポイントのようなものだ。

具体的には、Cloudflareは次を提供する：

-速度：世界中330か所以上の拠点でウェブサイトのコンテンツをキャッシュ（コピーを保存）し、より速い読み込み時間を実現する -セキュリティ：ハッカー、ボット、DDoS攻撃がサーバーに到達する前にブロックする -ルーティング：トラフィックを効率的に振り分ける、インターネットリクエストのためのGPSのような機能 -DNS：「google.com」のようなウェブサイト名を、コンピュータが理解できる数値アドレスに変換する

重要な点はここだ：** Cloudflareはあなたのアプリの前に立っている**。それは正面玄関だ。つまりCloudflareがダウンすると、ユーザーはあなたのアプリにアクセスできなくなる——たとえアプリが裏側で完全に正常に動作していても。

年11月18日に何が起きたのか？

この障害はサイバー攻撃やハードウェア故障によって引き起こされたものではなかった。驚くほど単純なことによってトリガーされた： ファイルが大きくなりすぎたことだ。

技術的な内訳（わかりやすい言葉で）

CloudflareはBot Managementと呼ばれるシステムを使って、自動化されたボット（データをスクレイピングしたり攻撃を仕掛けたりする悪い種類のもの）を識別しブロックしている。このシステムは、新しいボットの挙動に関する情報で数分ごとに更新される特別な「フィーチャーファイル」に依存している。

ここで何が問題だったのかを説明する：

1.データベース権限の変更：Cloudflareのチームは、データを保存・分析するシステムであるClickHouseデータベースの権限を更新していた 2.重複データが出現：この変更により、データベースがボットのフィーチャーファイルに重複した行の情報を出力し始めた 3.ファイルサイズが倍増：通常は管理可能なサイズだったファイルが突然2倍の大きさになった 4.システムが処理できなくなった：Cloudflareのソフトウェアには組み込みのサイズ制限があった。ファイルがその制限を超えたとき、ソフトウェアがクラッシュした 5.世界的な伝播：このファイルは数分ごとに世界中330か所以上のCloudflareデータセンターすべてに配信されるため、問題は数分で世界的に拡散した

混乱を招いた部分 この障害の診断を特に難しくしたのは、

点滅を繰り返した ことだった。5分ごとに、システムは新しいファイルを生成した。時には良好で（クエリが古いデータベースノードで実行された場合）、時には不良だった（更新されたノードで実行された場合）。これによりCloudflareのエンジニアは最初、内部の設定エラーではなく、大規模なDDoS攻撃を受けていると考えてしまった。

タイムライン

UTC 11:05- データベースへの権限変更が適用される -UTC 11:20- 障害が発生；世界中のユーザーがエラーページを目にする -UTC 約14:30- 根本原因が特定され、修正がデプロイされる（既知の正常なファイルへロールバック） -UTC 17:06 - すべてのシステムが完全に復旧

合計影響期間：約6時間、最悪の時期は約3時間続いた。

Cloudflare障害対クラウド障害：その違いは何か？

ここが多くの人が混乱するポイントだ。ウェブサイトがダウンすると、私たちはよく「クラウドが落ちた」と言う。しかし実際には 2種類の非常に異なる障害が存在する：

項目	Cloudflare障害（ネットワーク／エッジ）	クラウド障害（AWS／Azure／GCP）
何が壊れたか	「正面玄関」——ルーティング、セキュリティ、DNS	「家そのもの」——サーバー、データベース、ストレージ
ユーザーに見えるもの	「Cloudflare Error 500/502」ページ、サイトにアクセスできない	アプリのエラー、性能の低下、データ損失、システムクラッシュ
あなたのアプリの状態	通常は健全に稼働している	劣化、オフライン、または障害発生
典型的な期間	数分から数時間	数時間から数日（データ復旧が必要な場合あり）
実世界での例え	店舗に向かうハイウェイが封鎖されている	店舗が火事になっている

11月18日の障害中、AWS、Azure、Google Cloudはすべて完璧に稼働していた。ChatGPTのサーバーは正常だった。Spotifyのデータベースは健全だった。しかしユーザーはそれらにアクセスできなかった—— 経路が遮断されていたからだ。

どのサービスが影響を受けたのか？

この障害は複数のCloudflareサービスに影響を与えた：

コアCDNとセキュリティ：主要な問題——ウェブサイトがHTTP 500エラーを返した -Turnstile（CloudflareのCAPTCHA代替）：読み込みに失敗し、ログインが妨げられた -Workers KV（エッジストレージ）：ゲートウェイにリクエストが到達できず、エラーを返した -ダッシュボード：Turnstileがダウンしていたため、ほとんどのユーザーがログインできなかった -Access（ゼロトラスト認証）：ほとんどのユーザーで認証失敗 -メールセキュリティ：IPレピュテーションデータが一時的に失われ、スパム検知の精度が低下した

企業への重要な教訓

インターネットには単一障害点が存在する

Cloudflareはインターネットの巨大な部分を支えている。それがダウンすると、影響は莫大だ。この事例は、最高のエンジニアリングチームとインフラを備えていても、どのシステムも障害から免れないことを示している。

マルチCDNアーキテクチャはもはや選択肢ではない

この障害を最小限の混乱で乗り切った企業は、 マルチCDN戦略を使用していた：

プライマリCDN：Cloudflare（通常運用向け）
セカンダリCDN：Fastly、Akamai、またはAWS CloudFront（フェイルオーバー向け）
ヘルスチェック：プライマリが失敗した際にトラフィックを切り替える自動モニタリング -DNSフェイルオーバー：健全なエンドポイントにユーザーをリダイレクトするインテリジェントなルーティング

このアプローチは、重要な業務構成要素に複数のサプライヤーを持つことと似ている——一つのベンダーに完全に依存することは避けたいものだ。

回避策は存在する（しかしユーザーフレンドリーではない）

障害中、一部のユーザーは問題を回避する方法を見つけた：

-モバイルアプリ：多くはCloudflareのプロキシを迂回するため動作を継続した -直接のAPIアクセス：開発者はAPIを直接呼び出すことができた（例えば、OpenAIのAPIは正常に動作した） -直接のIPアクセス：IPアドレスを知っている技術的なユーザーはオリジンサーバーに直接接続できた

しかし、これらは一般ユーザーにとって実用的な解決策ではない。だからこそアーキテクチャ上のレジリエンスが非常に重要なのだ。

小さな変更が大きな影響をもたらすことがある

単純なデータベース権限の変更が、何百万人にも影響する世界的な障害を引き起こした。これは、次のことの重要性を強調している：

設定変更の徹底的なテスト
即時のグローバル展開ではない段階的な展開
重要なファイルや設定におけるサイズ制限と検証
異常が伝播する前に検知するための より良いモニタリング

Cloudflareが再発防止のために取っている対策

事後報告書の中で、Cloudflareは失敗を認め、いくつかの改善策を示した：

より良いファイルサイズの検証：設定ファイルを伝播する前にチェックを実施する -段階的な展開：グローバル展開前に、サーバーの小さなサブセットで変更をテストする -モニタリングの強化：設定ファイルのサイズの異常をより早く検知する -エラー処理の改善：システムが完全にクラッシュするのではなく、優雅に劣化するようにする

最後に：レジリエントなシステムを構築する

2025年11月18日のCloudflare障害は、インターネットが本質的に脆弱であることを再認識させるものだった。それは相互に接続されたシステムの連鎖であり、たった一つの弱いつながりが広範な混乱を引き起こす可能性がある。

企業にとって、教訓は明確だ：

-インフラを多様化する：単一のCDN、クラウドプロバイダー、DNSサービスに依存しない -フェイルオーバー戦略を実装する：プライマリシステムが失敗した際、バックアップシステムへの切り替えを自動化する -すべてのレイヤーでモニタリングする：エッジ、ネットワーク、アプリケーションのレベルで性能を追跡する -災害復旧をテストする：フェイルオーバーが実際に機能することを確認するため、定期的に障害をシミュレートする -明確にコミュニケーションする：サードパーティサービスが失敗した際に顧客に伝える計画を持つ

良いニュースは？適切なアーキテクチャと計画があれば、これらの避けられない障害の影響を最小限に抑えられるということだ。11月18日を無傷で乗り切った企業は、単に幸運だったわけではない——彼らは準備していたのだ。