Cloudflareの障害：暗号業界の偽りの分散化を暴く

18ヶ月で4回の重大障害、中央集権のジレンマはなぜ解決できないのか？

出典：rekt news

翻訳：Saoirse，Foresight News

2025年11月18日、米国東部時間午前6時20分。多くの人がネットワーク障害に遭遇した。

段階的な障害ではなく、警告もなかった。1秒前までスマホをいじり、取引し、AIとチャットしていたのに、次の瞬間、目に入るのはほぼすべて500エラーのページだった。

Twitterは投稿中に突然フリーズし、ChatGPTは会話の途中で応答を停止し、Claudeは完全に固まった。

Downdetector――すべてのプラットフォームがダウンしたときに障害状況を確認するサイト――さえも読み込めず、「すべてのサービスがダウンしている」と教えてくれなかった。

世界の20%のネットワークが、Cloudflareが本来インターネットを攻撃から守るはずなのに、誤って「自分自身を攻撃」したことで、突然消えた。

通常の設定変更（データベース権限の更新）が、ボット防御システム内の隠れたバグを引き起こし、瞬く間に「門番」が全員を締め出した。

10月、Amazon Web Services（AWS）がCoinbaseをダウンさせたとき、暗号通貨界隈のTwitterユーザーは「中央集権」の弊害を大いに嘲笑していた。

では、11月のCloudflare障害の時は？少なくとも最初の数時間、暗号業界は沈黙していた。

結局、Twitterが依存するインフラ自体がダウンしているとき、「インフラの脆弱性」についてTwitterで議論することはできない。

複数の重要サービスが停止（交通サイトシステムのダウン）、一部企業のウェブインターフェースが障害を起こし、ArbiscanやDeFiLlamaなどのブロックチェーンエクスプローラーも次々と500エラーを表示――しかし、ブロックチェーン自体にはコンセンサスの中断は見られなかった。

「分散化」を標榜する革命が、たった一社の設定ファイルが大きすぎるだけで機能しなくなるとき、本当に全体を支配しているのは誰なのか？

障害のタイムライン：「設定変更」から「全ネットワークダウン」まで

UTC 11:05：データベースアクセス制御の変更がデプロイ完了。

23分後、UTC 11:28、変更がユーザー環境に反映され、ユーザーのHTTPトラフィックで初めてエラーが記録された。

つまり、障害はすでに発生していたが、その時点では誰も問題の所在を知らなかった。

UTC 11:48、Cloudflare公式ステータスページがようやく「内部サービスに障害が発生」と認めた――企業の言い回しの本当の意味は「すべてが混乱し、誰の目にも明らかだ」ということだ。

連鎖反応は突然だった：今回の変更がCloudflareのボット管理層を破壊し、システムが倍のサイズの機能ファイルを読み込むと、プロキシサービスが即座に「ダウン」した。

下流システムも崩壊：Workers KV（キーバリューストレージサービス）とAccess（アクセス制御サービス）がプロキシに接続できず、全ネットワークのエラー率が急上昇、監視ツールの負荷が増大し、CPU使用率もピークを突破した。

トラフィックはCloudflareのエッジノードに流れ続けていたが、プロキシサービスは一切応答できなかった。

Cloudflareは当初、自社が攻撃を受けていると考え、しかも超大規模な分散型サービス拒否（DDoS）攻撃だと判断した。

さらに奇妙なことに、Cloudflareインフラ外に完全にホストされている公式ステータスページさえも同時にダウンし、エンジニアたちは「これはコアシステムと監視体制を狙った協調攻撃だ」と疑った。

だが事実は違った。外部からの攻撃ではなく、問題は自社にあった。

サービス復旧後間もなく、Cloudflare CTOのDane Knechtは公開謝罪声明を発表し、今回の事件は「全く容認できない」とし、障害の原因は通常の設定変更にあるとした――この変更がボット防御層の崩壊を引き起こしたのだ。

「私たちは顧客を裏切り、より広範なインターネットユーザーも裏切った」とKnechtは声明で述べ、「ボット防御機能を支えるサービスに潜在的なバグがあり、通常の設定変更後に突然崩壊し、ネットワークや他のサービスの大規模障害を引き起こした。これは外部攻撃ではない。」

障害のピーク時、Downdetectorプラットフォームには11,183件もの障害報告が寄せられた。

この「デジタル暗黒」は5時間半以上続き、UTC 17:06に完全復旧したが、14:30には正しいボット管理設定ファイルがグローバルにデプロイされ、最悪の影響は緩和された。

障害の衝撃：Web2から暗号分野まで、例外なし

Web2プラットフォームが真っ先に被害

Xプラットフォームには9,706件の障害報告が寄せられた。

ユーザーは見慣れたタイムラインの代わりに「おっと、問題が発生しました」というエラー表示を目にした。

ChatGPTは会話の途中で突然「沈黙」し、どんな指示にも応答しなくなった。

Spotifyのストリーミングサービスが中断し、Canvaのデザインプラットフォームはデザイナーを締め出し、UberやDoor Dash（フードデリバリー）も次々と機能異常を起こした。

ゲーマーも例外ではなく、『League of Legends』のプレイヤーはゲーム中に強制切断された。

マクドナルドのセルフオーダー機にもエラー画面が表示されたとの情報もあり――ランチタイムのピークとインフラ障害が重なった。

暗号通貨分野も「無傷」ではいられなかった。

暗号プラットフォームの大規模停止

Coinbaseのフロントエンドは完全に崩壊し、ユーザーは読み込めないログインページしか見られなかった。

Krakenのウェブ版とモバイルアプリも「ダウン」――これはCloudflareのグローバル障害の直接的な結果だ。

BitMEXはステータスページで「障害原因を調査中、プラットフォームのパフォーマンスは低下しているが、ユーザー資金は安全」と発表――同じシナリオ、取引所が違うだけ。

Etherscanは読み込めず、Arbiscanは完全にダウン。

DeFiLlamaのデータ分析パネルも断続的に内部サーバーエラーを表示した。

LedgerもCloudflare障害の影響で一部サービスの可用性が低下したと発表した。

唯一の「例外」：ブロックチェーンプロトコル自体

しかし、以下のシステムは影響を受けなかった：

報道によれば、Binance、OKX、Bybit、Crypto.com、KuCoinなど主要取引所はフロントエンド障害がなく、オンチェーン取引も正常に行われた――同時に、ブロックチェーン自体は完全に正常に稼働し、コンセンサスの中断は一切なかった。

ブロックチェーンプロトコルは常に独立して稼働している――問題はオンチェーンではなく、ブロックチェーンにアクセスするためのWeb2インフラにあった。

もしブロックチェーンが稼働していても、誰もアクセスできなければ、暗号通貨は本当に「オンライン」なのか？

深掘り：たった一つのデータベースクエリがなぜ20%のネットワークをダウンさせたのか？

Cloudflareはウェブサイトをホスティングしているわけでも、AWSのようにクラウドサーバーサービスを提供しているわけでもない。

その役割は「仲介者」――ユーザーとインターネットの間に立ち、2,400万のウェブサイトにサービスを提供し、120カ国・330都市に広がるノードを通じて世界の20%のネットワークトラフィックを処理している。

Cloudflareの宣伝文句はこうだ：「インターネットの盾と加速器」として、24時間365日のDDoS防御、ボット防御、トラフィックルーティング、グローバルWebアプリケーションファイアウォール（WAF）、TLS終端、Workersベースのエッジコンピューティング、DNSサービスを提供――すべてが統一された「セキュリティ-パフォーマンス」ネットワーク上で稼働している。

実際には、DDoS防御分野で82%の市場シェアを持ち、エッジノードの総帯域幅は449Tbpsに達し、世界中の主要インターネットサービスプロバイダー（ISP）やクラウドサービスプロバイダーと接続している。

問題の核心は、仲介機関が機能しなくなると、その背後のすべてのサービスが同時に「手の届かないもの」になることだ。

Cloudflare CTOのDane KnechtはXプラットフォームで率直にこう述べた：

「はっきり言おう：今朝、Cloudflareネットワークの問題により、私たちに依存する大量のトラフィックが影響を受け、顧客を裏切り、より広範なインターネットユーザーも裏切った。」

CEOのMatthew Princeの表現はさらに直接的だった：

「今日は2019年以来、Cloudflareで最も深刻な障害だった……過去6年以上、コアトラフィックの大部分が私たちのネットワークを通過できなくなるような障害は一度もなかった。」

障害の技術的根本原因

すべては通常のデータベース権限更新から始まった。UTC 11:05、CloudflareはClickHouseデータベースクラスターに変更を加え、セキュリティと信頼性を向上させる目的で――本来「暗黙のアクセス権」を持つユーザーが「明示的」にテーブルメタデータを見られるようにした。

問題はどこか？Cloudflareボット防御サービスの設定ファイルを生成するデータベースクエリが「データベース名」でフィルタリングしていなかった。

脅威トラフィックを管理するクエリが重複エントリを返し始めた――一つはデフォルトデータベースから、もう一つは基盤となるr0ストレージデータベースから。これにより機能ファイルのサイズが倍増し、元々約60の特徴から200以上の特徴に増えた。

Cloudflareはメモリ事前割り当てのハードコード上限を200特徴に設定し、「現在約60特徴しか使っていないので十分余裕がある」と考えていた。これは典型的なエンジニア思考：「十分広い安全マージンを設定した」と思い込むが、予想外が起きる。

サイズ超過のファイルがこの上限を引き起こし、Rustコードが即座にクラッシュ、「thread fl2_worker_thread panicked: called Result::unwrap () on an Err value」（fl2_worker_threadスレッドがクラッシュ：エラー値でResult::unwrap ()を呼び出した）というエラーが出た。

ボット防御システムはCloudflare制御層のコアコンポーネントだ。これがクラッシュすると、ロードバランサーに「どのサーバーが正常稼働しているか」を伝えるヘルスチェックシステムも「機能不全」になる。

さらに悪いことに、この設定ファイルは5分ごとに再生成される。

クエリが「更新済みクラスターのノード」で実行された場合のみ、エラーのあるデータが生成される。そのため、5分ごとにCloudflareのネットワークは「正常」と「障害」の間を行き来し――正しいファイルが読み込まれることもあれば、エラーのあるファイルが読み込まれることもあった。

この「行ったり来たり」により、エンジニアたちはDDoS攻撃を受けていると誤認した――内部エラーが「復旧とクラッシュの繰り返し」を引き起こすことは通常ないからだ。

最終的に、すべてのClickHouseノードが更新を完了し、毎回生成されるファイルがすべてエラーとなった。「行ったり来たり」は止まり、「完全かつ安定した障害」に変わった。

正確なシステムシグナルがなければ、システムは「保守モード」に入り、大半のサーバーを「不健康」と判定する。トラフィックは流入し続けるが、正しくルーティングできない。

Cloudflareのエッジノードはユーザーのリクエストを受け取れるが、何の処理もできない。

「これは外部攻撃ではない」とKnechtは繰り返し強調した。「悪意のある行為でもDDoS攻撃でもない。単にデータベースクエリがフィルタ条件を欠き、権限更新と重なったことで障害が発生しただけだ。」

Cloudflareは「99.99%の可用性」を約束していた――だが今回はその約束は果たされなかった。

事実、その通りだった。

歴史は繰り返す：18ヶ月で4回の重大障害、中央集権のジレンマはなぜ解決できない？

2025年10月20日――AWS障害が15時間続いた。米国東部1リージョンのDynamoDBデータベースのDNS解決が失敗し、Coinbaseがフリーズ、Robinhoodが遅延、Infuraサービスが中断（これによりMetaMaskにも影響）、Base、Polygon、Optimism、Arbitrum、Linea、Scrollなどのブロックチェーンネットワークがすべてダウン。ユーザー資金はオンチェーンで安全だったが、多くの人が見た残高は「ゼロ」だった。

2025年10月29日――Microsoft Azure障害。Azure Front Door（フロントエンドゲートウェイ）の設定同期問題でMicrosoft 365オフィススイートがダウン、Xbox Liveサービスが停止、企業サービスが中断。

2024年7月――CrowdStrike（セキュリティ企業）のWindowsアップデートパッケージにバグ。これによりフライトが欠航、病院の医療プロセスが遅延、金融サービスが凍結、完全復旧まで数日かかった。

2022年6月――Cloudflareの前回の重大障害。複数の暗号取引所がサービス停止を余儀なくされた――同じパターン、年が違うだけ。

2019年7月――Cloudflareのさらに前の障害。Coinbaseがダウンし、CoinMarketCapがアクセス不能――これが最初に無視された「警告サイン」だった。

わずか18ヶ月で4回の重大インフラ障害が発生した。

4回の障害が示す教訓は一つ：中央集権インフラは「中央集権障害」を必然的に引き起こす。

4回の障害は、暗号業界が分散化へ加速するきっかけになり得た――だが今も3社のインフラに依存している。

いくつの警告を経て、業界は「障害が起こりうる」という仮定から、「障害は必ず起こる」という前提でシステムを構築するようになるのか？

分散化の「嘘」：プロトコルが分散化されても、アクセスは分散化されていない

彼らはかつて、こんな青写真を描いた：

「分散型金融、検閲耐性通貨、信頼不要のシステム、単一障害点なし、『あなたの秘密鍵でなければあなたのコインではない』、コードは法。」

しかし11月18日の現実は痛烈だった：Cloudflareの半日の障害で、暗号業界の一部サービスが数時間停止した。

技術的な真実：

どのブロックチェーンプロトコルも障害が報告されていない。BitcoinネットワークもEthereumネットワークも正常稼働――チェーン自体には何の問題もなかった。

実際の利用現場の現実：

取引所のインターフェースが崩壊し、ブロックチェーンエクスプローラーがダウンし、ウォレットインターフェースが機能せず、データ分析プラットフォームがダウン、取引画面に500エラーが表示された。

ユーザーは本来「所有」しているはずの「分散化」ブロックチェーンにアクセスできなかった。プロトコル自体は正常稼働――ただし「アクセスできれば」の話だ。

以下の発言は、多くの人にとって耳障りかもしれない……

SovereignAI COOのDavid Schwedは容赦なく指摘した：

「今のCloudflare障害、数週間前のAWS障害は、インフラの『耐障害性』を単一ベンダーに外部委託できないことを十分に示している。24時間365日稼働が必要な組織なら、『障害は必ず起きる』という前提でインフラを構築しなければならない。事業継続計画が『ベンダーの復旧を待つ』だけなら、それは純粋な怠慢だ。」

「純粋な怠慢」――偶然でも見落としでもなく、怠慢だ。

Jameson Loppの評価は的を射ている：

「私たちは素晴らしい分散化技術を持っているのに、ほとんどのサービスを少数のベンダーに集中させてしまい、極めて脆弱にしている。」

Ben SchillerがAWSの前回障害時に言った言葉は、今も当てはまる：

「もしあなたのブロックチェーンがAWS障害でダウンするなら、それは十分に分散化されていない。」

「AWS」を「Cloudflare」に置き換えても、本質は全く同じ――業界は教訓を得ていない。

なぜ「原則」より「利便性」を選ぶのか？

自前でインフラを構築するには、高価なハードウェアの購入、安定した電源の確保、専用帯域の維持、セキュリティ専門家の雇用、地理的冗長性の実現、災害復旧システムの構築、24時間監視――すべてに多大なリソースが必要だ。

Cloudflareを使えば、ボタンをクリックし、クレジットカード情報を入力し、数分でデプロイが完了する。

DDoS防御は他人任せ、可用性も他人任せ、スケーリングも他人任せ。

スタートアップは「迅速な市場投入」を追求し、VCは「資本効率」を要求――誰もが「利便性」を選び、「耐障害性」は後回しにした。

「利便性」が利便性でなくなるその瞬間まで。

10月のAWS障害は、Twitter上で「分散化」について終わりなき議論を巻き起こした。

11月のCloudflare障害は？沈黙だった。

「哲学的な沈黙」でも「熟考の静けさ」でもない。

単に、文句を言いたくても、普段使っている文句用プラットフォーム（Twitter）もインフラ障害でダウンしていたからだ。

「単一障害点」を嘲笑するためのプラットフォーム自体が「単一障害点」だったとき、文句の言いようがない。

アクセス層が3社のインフラに依存し、そのうち2社が同じ月に障害を起こしたとき、「プロトコルレベルの分散化」には何の意味もない。

ユーザーがブロックチェーンにアクセスできないなら、私たちの「分散化」は一体何を「分散化」しているのか？

独占のジレンマ：3社がクラウド市場の60%を支配、暗号業界の行方は？

AWSは世界のクラウドインフラ市場の約30%を支配し、Microsoft Azureは20%、Google Cloudは13%を占める。

3社で現代インターネットを支えるクラウドインフラの60%以上を支配している。

暗号業界は本来「中央集権」の解決策であるはずが、今や世界で最も中央集権的なインフラに依存している。

暗号業界の「中央集権依存リスト」

• Coinbase――AWSに依存；
• Binance、BitMEX、Huobi、Crypto.com――すべてAWSに依存；
• KrakenはAWSベースでインフラを構築しているが、CloudflareのCDN（コンテンツ配信ネットワーク）障害の影響も受けた。

多くの「分散化」を標榜する取引所も、実際は中央集権インフラ上で稼働している。

10月と11月の障害には、もう一つ重要な違いがある：

AWS障害時、Xプラットフォーム（旧Twitter）は正常稼働しており、暗号界隈のTwitterユーザーは「インフラの脆弱性」を大いに嘲笑できた。

だがCloudflare障害時、Xプラットフォームも同時にダウンした。

「単一障害点」を嘲笑するためのプラットフォーム自体が「単一障害点」だったとき、笑うことはできない。

この皮肉が、業界議論を最初から停滞させた。

30日間で3回の重大障害、規制当局はすでに高い関心を示している。

規制当局が直視すべき核心問題

• これらの企業は「システム上重要な機関」に該当するのか？
• インターネット基幹サービスは「公益事業型規制」の対象とすべきか？
• 「大きすぎて潰せない」属性とテックインフラが結びつくと、どんなリスクが生じるのか？
• Cloudflareが世界の20%のネットワークトラフィックを支配しているなら、これは独占問題ではないか？

第19条組織のCorinne Cath-Spethは、AWSの前回障害時に率直にこう述べた：「一社がダウンすれば、重要サービスもダウンする――メディアがアクセス不能になり、Signalなどの安全通信アプリも停止し、デジタル社会を支えるインフラが崩壊する。クラウドコンピューティングの多様化が急務だ。」

言い換えれば、各国政府は少数の企業だけでインターネットが停止し得ることに気づき始めている。

実際、分散化の代替案はすでに存在するが、誰も使いたがらない。

例えばストレージ用のArweave、分散型ファイル転送のIPFS、計算用のAkash、分散型ホスティングのFilecoinなど。

分散化案が「評価されても普及しない」理由は？

パフォーマンスが中央集権案に劣り、遅延はユーザーが直接体感する。

普及率が極めて低く、「AWSにデプロイ」ボタンの利便性と比べると、分散化案のユーザー操作は煩雑で複雑に見える。

コストも「三巨頭」（AWS、Azure、Google Cloud）からインフラを借りるより高い場合が多い。

現実は：

本当の分散化インフラを構築するのは、想像以上に難しい。

ほとんどのプロジェクトは「分散化」を口にするだけで、実際に実現することはほとんどない。中央集権案を選ぶ方が常に簡単で安価――18ヶ月で4回の障害が起きて初めて、「簡単で安価」の裏に巨大な代償が隠れていることに気づく。

OORT CEOのMax Li博士は最近のCoinDeskコラムで、業界の偽善をこう指摘した：

「『分散化』を誇り、利点を強調する業界が、脆弱な中央集権クラウドプラットフォームにインフラを大きく依存しているのは、それ自体が偽善だ。」

彼の解決策は、ハイブリッドクラウド戦略を採用し、取引所が重要システムを分散型ネットワークに分散配置することだ。

中央集権クラウドプラットフォームのパフォーマンスとスケールの優位性は否定できない――だが数十億ドルの資金や毎秒の取引が重要な場合、耐障害性は分散型案の方がはるかに高い。

「利便性」の代償が業界の行動様式を変えるほど大きくなって初めて、「理念」が「利便性」に勝る。

明らかに、11月18日の障害はまだ十分に深刻ではなく、10月20日のAWS障害も、2024年7月のCrowdStrike障害も同様だ。

どれほどの事態になれば、「分散化インフラ」が「話題」から「必須要件」に変わるのか？

11月18日、暗号業界は「失敗」していない――ブロックチェーン自体は完璧に稼働していた。

本当に「失敗」したのは、業界全体の自己欺瞞の嘘だった：「ダウンし得るインフラ上に止められないアプリを構築できる」と思い込んだこと、「3社が『アクセスゲート』を握っていても検閲耐性に意味がある」と思い込んだこと、Cloudflareの設定ファイル一つで数百万人の取引可否が決まるのに「分散化」と呼ぶこと。

もしブロックチェーンがブロックを生成し続けても、誰も取引を送信できなければ、それは本当に「オンライン」と言えるのか？

業界には何の緊急対策もない。

障害が起きたら、Cloudflareの修復を待ち、AWSの復旧を待ち、Azureのパッチ配布を待つしかない。

これが今の業界の「災害復旧戦略」だ。

もしデジタルIDとブロックチェーンが深く結びついたら、どうなるか想像してみてほしい。

米国財務省は、ID証明をスマートコントラクトに組み込み、すべてのDeFi取引にKYC認証を義務付けようとしている。

次にインフラ障害が起きたとき、ユーザーが失うのは取引権限だけでなく、金融システムで「自分の身元を証明する」能力も失うことになる。

本来3時間の障害が、3時間「人間認証画面が読み込めない」事態になる――認証サービスがダウンしたインフラ上で動いているだけで。

規制当局が作ろうとする「安全ガードレール」は、「インフラが常にオンラインである」ことが前提だ。だが11月18日の障害は、その前提が成り立たないことを証明した。

「過度な監視」が明らかになれば、テック業界は「プライバシー保護」に向かう。

今こそ「インフラの耐障害性」もその範疇に加えるべき時かもしれない。

それは「オプションの加点項目」ではなく、「すべてを支える基本要件」であるべきだ――それがなければ他のすべての機能は語れない。

次の障害はすでに進行中――AWSかもしれないし、Azureかもしれないし、Google Cloudかもしれないし、Cloudflareの再障害かもしれない。

来月かもしれないし、来週かもしれない。インフラも依存関係も業界インセンティブも変わっていない。

中央集権案を選ぶのは、今もより安価で、より速く、より便利な選択肢――それがそうでなくなるまで。

Cloudflareが次に通常の設定変更を行い、次の重要サービスで隠れたバグを引き起こしたとき、私たちはまた見慣れた「シナリオ」を目撃するだろう：500エラーのページだらけ、取引は全面停止、ブロックチェーンは正常稼働しているのに誰もアクセスできず、「分散化」を議論しようとツイートしようとしてもTwitterがダウン、企業は「次はもっと良くする」と約束するが決して実現しない。

何も変わらない、「利便性」が「リスク管理」に勝る限り――その「利便性」の代償が無視できないほど大きくなるその日まで。

今回は「門番」が3時間半ダウンした。

次は、障害がもっと長引くかもしれない；次は「毎秒の取引が生死を分ける」市場暴落時に発生するかもしれない；次は認証システムも障害に巻き込まれるかもしれない。

あなたが生き残るために頼るインフラが、最も負けられない瞬間にダウンしたとき、それは一体誰の責任なのか？

データ出典：The Guardian、ジョニー・ボポフ、PC Magazine、IT Professional、CNBC、Cloudflare、TechCrunch、AP News、CoinDesk、Tom's Hardware、Dane Knecht、Tom's Guide、Surya、Sheep Esports、TheBlock、Kraken、BitMEX、Ledger、Blockchain News、Statista、Screaming Computer、Jameson Lopp、Ben Schiller、Article 19、CoinTelegraph