Cloudflare大西洋光ファイバー切断が示す「設定ミスではない障害」の教訓

2026年6月22日、CDN大手Cloudflareのネットワークが劣化し、X、Reddit、Microsoft Teams、Zoomなど数多くのサービスで遅延やタイムアウトが発生した[1][2]。原因は設定変更のミスではなく、北米東部で発生した光ファイバー回線の物理的な切断だった[1][3]。Cloudflareの障害というと、2025年11月の設定ファイル肥大化による大規模停止のように、社内の変更作業が引き金になるケースが目立ってきた。今回は自社の変更が原因ではなく、外部の物理インフラという制御できない要因だった点が異なる。CDNやDNSをCloudflareに委ねている運用担当者にとって、これは設定レビューや変更管理を徹底しても防げない障害があるという事実を突きつける。本稿では、当日の経緯と過去の設定ミス型障害との違いを整理したうえで、マルチCDN設計やフェイルオーバー設計が物理層の障害にどこまで有効かを運用視点で検討する。

予備知識

• CDN（コンテンツ配信ネットワーク）: 世界各地のサーバーからウェブコンテンツを配信し、表示を高速化・安定化する中間層サービス
• オリジンサーバー: コンテンツの大元を保持するサーバー。CDNはここから取得した内容を利用者の近くで配信する
• HTTP 522: エッジ（CDN側）がオリジンサーバーへの接続を確立できないときに返るエラーコード
• トラフィックエンジニアリング: 通信の経路を動的に切り替え、混雑や障害を避けて流す運用技術

クラウド／障害

クラウドアカウント停止という盲点：Railway全面障害に学ぶ隠れ依存

2026年5月19日、PaaS（アプリケーションの実行環境を丸ごと提供するクラウドサービス）大手のRailwayが約8時間の全面障害を起こした。原因はソフトウェアのバグでも攻撃でもない。Google Cloud（GCP）の自動システムが、[…]

2026年6月22日に何が起きたのか

Cloudflareのエンジニアは6月22日13時35分（UTC）ごろ、エラー率とレイテンシの上昇を検知した[1][3]。14時37分には原因を北米東部の光ファイバー切断と特定した[3]。発生時点はニューヨーク時間の午前10時前後にあたる。

症状はサイトが完全に落ちる形ではなく、HTTP 522エラーや接続タイムアウトとして現れた[2][3]。エッジ側の応答はあるのに、その先のオリジンサーバーへの経路が安定しないという状態だった。DownDetectorにはXだけで3万5000件を超える障害報告が寄せられ、Reddit、Microsoft Teams、Zoom、Discord、Canva、Robinhookなどでも報告が急増した[2]。AWSについても影響が報じられたが、AWS側は自社サービスは正常稼働していたと説明しており、この点は情報源によって記述が割れている[1][2]。

なお同日はCloudflareのニューアーク（EWR）データセンターで計画メンテナンスも実施されていたが、これは光ファイバー切断とは無関係の別事象だったとされる[3]。時期が重なった別要因を根本原因と誤認しないことも、障害調査では重要な視点になる。

クラウド／障害

Coinbase障害報告で読み解くAWS単一AZ熱障害とMSKサイレント障害

2026年5月7日、米暗号資産取引所のCoinbaseが約8時間にわたり取引停止に陥った。原因はAWS（Amazon Web Services）の米バージニア北部リージョンus-east-1で起きた、1つのアベイラビリティゾーン（AZ、独[…]

原因は設定ミスではなく物理層の切断だった

Cloudflareの過去の主要障害は、多くが設定変更に起因していた。今回の光ファイバー切断は、その系譜とは原因の性質が根本的に異なる。

設定ミス型は、原因を特定できれば設定を戻すだけで比較的短時間に復旧できる。物理障害型は、原因特定後も現場への到達や修理作業という時間のかかる工程が残る点が大きく異なる[3]。今回はトラフィックエンジニアリングによる迂回で当日中に混雑とパケットロスの大部分を緩和できたが、これは代替経路が存在したためであり、経路そのものが限られる地域では同じ対応が取れるとは限らない。

障害

交渉最大の障害は「信頼の欠如」――プロスポーツ労使紛争に学ぶ克服法｜MBAファシリテーション＆ネゴシエーション Day6

MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]

なぜCloudflareの障害はここまで波及するのか

Cloudflareは全世界のウェブサイトの2割以上でCDNやDNS、リバースプロキシとして使われており、多数のサービスにとって唯一の入り口になっている[2][3]。この集中度の高さが、単一の物理障害でも影響範囲が広がる理由になる。

XやReddit、Teams、Zoomは、それぞれ独立したサービスに見えるが、Cloudflareという共通の中間層を経由する点で運用上はつながっている。中間層が劣化すると、オリジン側のサーバーやアプリケーションに問題がなくても、ユーザーからは「サイトが落ちている」ように見える。この構造は便利さと引き換えに、障害の波及範囲を広げるという性質を持つ。

マルチCDN設計とフェイルオーバー設計の限界

マルチCDN構成は、CDN事業者の障害に備える代表的な設計だが、物理層の共有までは解消できない場合がある。DNSやロードバランサーでCDN事業者を切り替えても、その先の伝送路が同じ地域の限られた光ファイバー網を経由していれば、迂回先でも同様の混雑が起きうる。

今回のケースでは、Cloudflare自身のトラフィックエンジニアリングによる迂回が有効に機能し、当日中に大半の影響を緩和できた[3]。これは裏を返せば、代替経路の確保はCDN事業者側の設計に依存する部分が大きく、利用側が契約するCDNを増やすだけでは制御しきれない領域があるということでもある。フェイルオーバー設計を検討する際は、切り替え先のプロバイダーが物理的に別経路を持つかどうかまで踏み込んで確認する必要がある。

よくある質問（FAQ）

Q1. Cloudflareの障害はなぜ多くのサービスに同時に影響するのか。
Cloudflareは全世界のウェブサイトの2割以上でCDNやDNSとして利用される中間層であり、そこが劣化すると個々のサービスに問題がなくても接続不良として現れるためである[2][3]。

Q2. 物理ファイバー切断による障害と設定ミスによる障害はどう違うのか。
設定ミス型は原因特定後にロールバックで比較的短時間に復旧できるのに対し、物理障害型は原因特定後も現地での修理作業という時間のかかる工程が残る[3]。

Q3. マルチCDNを導入すれば今回のような障害を防げるのか。
CDN事業者を複数契約しても、伝送路の物理経路が共有されていれば同時に影響を受ける可能性があり、切り替え先が物理的に独立した経路を持つかまで確認する必要がある[3]。

まとめ

2026年6月22日のCloudflare障害は、設定変更のミスではなく、北米東部の光ファイバー回線の物理切断が原因だった。過去の設定ミス型障害と比べ、原因特定後も現地修理という時間のかかる工程が残る点が実務上の違いになる。CDNを含む重要な依存先については、契約するCDN事業者の数だけでなく、その先の物理経路がどこまで独立しているかを一度点検しておく価値がある。あわせて、外部要因による障害を前提にしたBCPと初動対応手順を、平時のうちに見直しておくことを勧めたい。

出典