2025年11月18日、インターネットの約20％がオフラインになった—サイバー攻撃によるものではなく、定期的なデータベースのアクセス権更新が引き金となり、Cloudflareに隠されたバグが発生したためだ。同社は「インターネットをこの種の障害から守る」役割を担っている。数分以内に連鎖が始まった：Twitterはツイート途中でクラッシュ、ChatGPTはフリーズ、Spotifyはストリーミング停止。そして暗号通貨の世界では？取引プラットフォームがダウン、ブロックチェーンエクスプローラーが故障、ウォレットインターフェースは500エラーを返した。5時間半にわたり、検閲耐性と止まらないと謳った業界は完全に停止した。皮肉なことに？ブロックチェーン自体は正常に動作し続けた。ビットコインはブロックを採掘し、イーサリアムは取引を処理した。合意の失敗も、プロトコルの崩壊もなかった。ユーザーは「所有しているはず」のものにアクセスできなくなっただけだ。## 実際に何が起きたのか：技術的なつまずきと壊滅的な影響Cloudflareは他の大手クラウドプロバイダーのようにウェブサイトをホスティングしたり、コンピューティングパワーを販売したりしているわけではない。代わりに、インターネットのトラフィックコントローラーとして機能し、120か国以上のユーザーとサービスの間に立っている。同社は世界のインターネットトラフィックの約20％をグローバルネットワークを通じて処理している。2025年11月18日UTC11:05、CloudflareはClickHouseデータベースクラスターに対して一見すると定型的な変更を行った。目的は合理的で：セキュリティと信頼性を向上させるためにアクセス制御を更新することだった。しかし、ここで現代インフラの擬似的な耐性が崩壊した。ボット保護設定を生成したデータベースクエリには、データベース名のフィルターが含まれていなかった。これにより、クエリは重複エントリを返し始めた—一つはデフォルトのデータベースから、もう一つは基盤となるストレージ層から。設定ファイルは突然、約60の機能から200以上に倍増した。Cloudflareのエンジニアは、実際の使用量を十分に超えると考え、200の機能にハードコードされた制限を設けていた。古典的なエンジニアリングの論理：余裕を持たせた安全マージンを設定し、それを超えることはないと想定していた。だが、それは間違いだった。この過剰なファイルは、Cloudflareの制御層の中核であるボット保護システムをクラッシュさせた。システムが一つ崩れると、依存している他のシステムも連鎖的に崩壊する。負荷分散装置に「どのサーバーが稼働中か」を伝えるヘルスモニタリングも失敗した。トラフィックはCloudflareのエッジノードに届き続けたが、ルーティングする手段がなかった。最初の数時間、Cloudflareのエンジニアは大規模な分散型サービス拒否攻撃（DDoS）に見舞われていると思い込んだ。問題の設定が再生成されるたびに、「動作中」と「完全に壊れている」の間をシステムが行き来した。しかし、攻撃はなかった—ただのデータベースフィルターの欠落と、それを補うための誤った前提だけだった。UTC17:06までに、正しい設定が全体に展開され、サービスは復旧した。危機は回避された。## 暗号業界は祝えない—むしろ曝露されたWeb2プラットフォームが最初に、そして最も顕著に被害を受けた—Spotifyのストリーミング中断、ゲームセッションの切断、フードデリバリーシステムのクラッシュ—一方、暗号の世界はもっと不快な真実に直面した。複数の取引所プラットフォームはロードできず、ブロックチェーンエクスプローラーはオフラインになり、ウォレットサービスは失敗し、取引インターフェースはエラーメッセージを表示した。そして、業界全体はTwitterに投稿しようとしたが、Twitterもダウンしていることに気づいた。これにより奇妙な沈黙が生まれた。AWSの10月の障害時、暗号Twitterは「インフラの脆弱性」や「中央集権リスク」を嘲笑するのに何時間も費やした。今回は？誰も何も嘲笑えなかった。単一障害点を批判するために使うプラットフォーム自体が、またもや単一障害点だったのだ。ここで不快な事実：**ブロックチェーンのプロトコル自体は影響を受けていなかった。**取引はオンチェーンで処理され続け、合意も継続した。「信頼レス、検閲耐性のある金融」の技術的基盤は、設計通りに動いていた。しかし、それは意味をなさない。アクセスできなければ、機能するブロックチェーンは単なる歴史的記録に過ぎない。## 誰も破っていないパターン：4つの大規模障害、同じ根本問題- **2019年7月**：Cloudflareの障害。Coinbaseがオフライン、マーケットデータもアクセス不能。- **2022年6月**：再びCloudflareの障害。複数の暗号プラットフォームがサービス停止。- **2025年10月20日**：AWSの障害、15時間続く。DynamoDBのデータベース障害が依存サービスに連鎖。- **2025年11月18日**：再びCloudflare。5時間半にわたる広範な混乱。約18か月で4つの主要インフラ障害。教訓は明白だ：中央集権的インフラは中央集権的な故障を生む。しかし、業界はそれを学んでいない。## なぜ「分散化」はマーケティング用語にとどまるのか暗号業界は、その哲学を一つの前提に築いてきた：仲介者を排除し、単一障害点をなくし、止まらないシステムを作る。しかし、現実は異なる。暗号の現状の「インフラ依存チェーン」は、誰かが言うのを恐れているジョークのようだ：- 主要取引所はAmazon Web Servicesに依存- DNSやコンテンツ配信はCloudflareに依存- ブロックチェーンエクスプローラーはCloudflareに依存- アナリティクスプラットフォームはCloudflareに依存- ウォレットインターフェースも同様に集中インフラに依存だから、Cloudflareがデータベース設定を更新し、ボット保護を破壊すると、業界全体—この状況を防ぐために構築されたはずのもの—がオフラインになる。擬似的な分散化は明白だ：**プロトコル層は本当に分散しているが、アクセス層は約60％のクラウドインフラを支配する3社によってボトルネックになっている** (Amazon Web Services 30%、Microsoft Azure 20%、Google Cloud 13%)。3社。うち2社は同じ月に障害を経験。これは冗長性ではなく、集中した脆弱性だ。## 不注意の経済学なぜこれが繰り返されるのか？なぜ暗号プラットフォームは、障害が起きることを前提にインフラを構築しないのか？答えはあまりにも単純だ：コストが高く、複雑だからだ。自前のインフラを構築するには、ハードウェアの購入、電力の安定供給、専用帯域の確保、セキュリティ専門家の雇用、地理的冗長性の確立、災害復旧の設計、24時間体制の監視など、多大な資本と運用コストが必要だ。Cloudflareを使うのは、クレジットカード番号を入力し、数分で展開できる。スタートアップは市場投入のスピードを優先し、投資家は資本効率を求める。誰もが便利さを耐久性より優先している。しかし、便利さが深刻な不便さに変わる瞬間—そして、4つの大規模障害が18か月以内に起きても、その行動を変えるには不十分だ。分散型の代替手段は存在する：Arweave（ストレージ）、IPFS（分散ファイル転送）、Akash（コンピューティングリソース）、Filecoin（分散ホスティング）。しかし、これらは遅く、複雑で、しばしばコストも高いため、広く採用されていない。業界は表面上は分散化を謳いながら、原則と便利さの間のトレードオフが生じるたびに、中央集権的な解決策を選び続けている。## 規制当局が見ているもの—そしてなぜ関心を高めているのか30日間に3回の大規模障害は、政策立案者の注意を引いた。彼らは今、明らかにすべきことを見ている：少数のテクノロジー企業が重要なインフラを無効化できる。問いはこうだ：- 世界のインターネットトラフィックの20％を制御する企業は、「システム的重要な機関」と呼べるのか？- インターネットインフラは公共事業として規制されるべきか？- 「潰せない」巨大企業に「破綻寸前」の規制は適用されるのか？- 障害が連鎖的に広がるとき、冗長性はどこにあるのか？過去のインフラ障害時、政策専門家は明言していた：**単一のベンダーが失敗すると、メディアはアクセス不能になり、安全な通信は停止し、デジタル社会を支えるインフラは崩壊する。**政府は、インターネットインフラの集中がシステムリスクを生むことを認識し始めている。しかし、規制だけでは解決しない。本当の解決策は、業界自身が自主的に分散型インフラを採用すること—それには、中央集権的な失敗の痛みが、中央集権的解決策の便利さを上回る必要がある。## 誰も答えたくない質問暗号業界は11月18日に「失敗」したわけではない。ブロックチェーンのプロトコルは動き続け、ノードは合意を維持し、取引は有効だった。業界の自己欺瞞は崩れた。その欺瞞とは：- 「止まらない」インフラ上に「止まらない」アプリを構築できると信じること- 「検閲耐性」が何かを意味するのは、3社がアクセスチャネルを支配しているときだけ- 「分散化」が本物だと信じるのは、1つのCloudflare設定ファイルが何百万もの取引を決定しているときだけ- 「信頼レスシステム」が機能するのは、信頼を中央集権的仲介者に委ねているときだけブロックチェーンがブロックを生成し続けているが、ユーザーが取引を送信できなければ、それは実際に機能していると言えるのか？技術的にはYes。実用的にはNo。インフラが間違った瞬間に故障したときのための緊急対応策はない—市場の崩壊時や、本人確認システムが同時にオフラインになったときなど。今の業界の「災害復旧戦略」は単純だ：Cloudflareが問題を解決するのを待つ。AWSがサービスを復旧するのを待つ。Microsoftがパッチを展開するのを待つ。障害が重要な市場の瞬間と重ならないことを祈る。これは計画ではない。ビジネス継続性を装った麻痺状態だ。## 次回の確実性11月18日の障害は、また別のインフラ故障につながるだろう。それはAWS、Azure、Google Cloud、あるいは別のCloudflareの設定変更から起きるかもしれない。来月起きるかもしれないし、来週かもしれない。根底にあるインフラは変わっていない。依存関係も変わっていない。業界のインセンティブも変わっていない—集中型ソリューションは、分散型よりも安価で速く、便利だからだ。次の故障を防ぐための構造的な対策は何もない。なぜなら、それを防ぐには、必要になるまで見えない利益をもたらす複雑さと冗長性に投資する必要があるからだ。その瞬間—障害が重要な市場イベントや本人確認システムの停止、最大の金融ダメージが発生する瞬間—に備えることはできない。業界は再び、「分散化」が哲学であり、アーキテクチャではないことを痛感するだろう。そして、インフラが常に利用可能だと仮定してアプリケーションを構築した者たちは、その仮定が砂の上に築かれていたことを痛い目で学ぶことになる。
分散化の幻想：単一企業のデータベースエラーが暗号のインフラの脆弱性を露呈
2025年11月18日、インターネットの約20％がオフラインになった—サイバー攻撃によるものではなく、定期的なデータベースのアクセス権更新が引き金となり、Cloudflareに隠されたバグが発生したためだ。同社は「インターネットをこの種の障害から守る」役割を担っている。
数分以内に連鎖が始まった：Twitterはツイート途中でクラッシュ、ChatGPTはフリーズ、Spotifyはストリーミング停止。そして暗号通貨の世界では？取引プラットフォームがダウン、ブロックチェーンエクスプローラーが故障、ウォレットインターフェースは500エラーを返した。5時間半にわたり、検閲耐性と止まらないと謳った業界は完全に停止した。
皮肉なことに？ブロックチェーン自体は正常に動作し続けた。ビットコインはブロックを採掘し、イーサリアムは取引を処理した。合意の失敗も、プロトコルの崩壊もなかった。ユーザーは「所有しているはず」のものにアクセスできなくなっただけだ。
実際に何が起きたのか：技術的なつまずきと壊滅的な影響
Cloudflareは他の大手クラウドプロバイダーのようにウェブサイトをホスティングしたり、コンピューティングパワーを販売したりしているわけではない。代わりに、インターネットのトラフィックコントローラーとして機能し、120か国以上のユーザーとサービスの間に立っている。同社は世界のインターネットトラフィックの約20％をグローバルネットワークを通じて処理している。
2025年11月18日UTC11:05、CloudflareはClickHouseデータベースクラスターに対して一見すると定型的な変更を行った。目的は合理的で：セキュリティと信頼性を向上させるためにアクセス制御を更新することだった。しかし、ここで現代インフラの擬似的な耐性が崩壊した。
ボット保護設定を生成したデータベースクエリには、データベース名のフィルターが含まれていなかった。これにより、クエリは重複エントリを返し始めた—一つはデフォルトのデータベースから、もう一つは基盤となるストレージ層から。設定ファイルは突然、約60の機能から200以上に倍増した。
Cloudflareのエンジニアは、実際の使用量を十分に超えると考え、200の機能にハードコードされた制限を設けていた。古典的なエンジニアリングの論理：余裕を持たせた安全マージンを設定し、それを超えることはないと想定していた。だが、それは間違いだった。
この過剰なファイルは、Cloudflareの制御層の中核であるボット保護システムをクラッシュさせた。システムが一つ崩れると、依存している他のシステムも連鎖的に崩壊する。負荷分散装置に「どのサーバーが稼働中か」を伝えるヘルスモニタリングも失敗した。トラフィックはCloudflareのエッジノードに届き続けたが、ルーティングする手段がなかった。
最初の数時間、Cloudflareのエンジニアは大規模な分散型サービス拒否攻撃（DDoS）に見舞われていると思い込んだ。問題の設定が再生成されるたびに、「動作中」と「完全に壊れている」の間をシステムが行き来した。しかし、攻撃はなかった—ただのデータベースフィルターの欠落と、それを補うための誤った前提だけだった。
UTC17:06までに、正しい設定が全体に展開され、サービスは復旧した。危機は回避された。
暗号業界は祝えない—むしろ曝露された
Web2プラットフォームが最初に、そして最も顕著に被害を受けた—Spotifyのストリーミング中断、ゲームセッションの切断、フードデリバリーシステムのクラッシュ—一方、暗号の世界はもっと不快な真実に直面した。
複数の取引所プラットフォームはロードできず、ブロックチェーンエクスプローラーはオフラインになり、ウォレットサービスは失敗し、取引インターフェースはエラーメッセージを表示した。そして、業界全体はTwitterに投稿しようとしたが、Twitterもダウンしていることに気づいた。
これにより奇妙な沈黙が生まれた。AWSの10月の障害時、暗号Twitterは「インフラの脆弱性」や「中央集権リスク」を嘲笑するのに何時間も費やした。今回は？誰も何も嘲笑えなかった。単一障害点を批判するために使うプラットフォーム自体が、またもや単一障害点だったのだ。
ここで不快な事実：**ブロックチェーンのプロトコル自体は影響を受けていなかった。**取引はオンチェーンで処理され続け、合意も継続した。「信頼レス、検閲耐性のある金融」の技術的基盤は、設計通りに動いていた。
しかし、それは意味をなさない。アクセスできなければ、機能するブロックチェーンは単なる歴史的記録に過ぎない。
誰も破っていないパターン：4つの大規模障害、同じ根本問題
約18か月で4つの主要インフラ障害。教訓は明白だ：中央集権的インフラは中央集権的な故障を生む。
しかし、業界はそれを学んでいない。
なぜ「分散化」はマーケティング用語にとどまるのか
暗号業界は、その哲学を一つの前提に築いてきた：仲介者を排除し、単一障害点をなくし、止まらないシステムを作る。
しかし、現実は異なる。
暗号の現状の「インフラ依存チェーン」は、誰かが言うのを恐れているジョークのようだ：
だから、Cloudflareがデータベース設定を更新し、ボット保護を破壊すると、業界全体—この状況を防ぐために構築されたはずのもの—がオフラインになる。
擬似的な分散化は明白だ：プロトコル層は本当に分散しているが、アクセス層は約60％のクラウドインフラを支配する3社によってボトルネックになっている (Amazon Web Services 30%、Microsoft Azure 20%、Google Cloud 13%)。
3社。うち2社は同じ月に障害を経験。これは冗長性ではなく、集中した脆弱性だ。
不注意の経済学
なぜこれが繰り返されるのか？なぜ暗号プラットフォームは、障害が起きることを前提にインフラを構築しないのか？
答えはあまりにも単純だ：コストが高く、複雑だからだ。
自前のインフラを構築するには、ハードウェアの購入、電力の安定供給、専用帯域の確保、セキュリティ専門家の雇用、地理的冗長性の確立、災害復旧の設計、24時間体制の監視など、多大な資本と運用コストが必要だ。
Cloudflareを使うのは、クレジットカード番号を入力し、数分で展開できる。
スタートアップは市場投入のスピードを優先し、投資家は資本効率を求める。誰もが便利さを耐久性より優先している。
しかし、便利さが深刻な不便さに変わる瞬間—そして、4つの大規模障害が18か月以内に起きても、その行動を変えるには不十分だ。
分散型の代替手段は存在する：Arweave（ストレージ）、IPFS（分散ファイル転送）、Akash（コンピューティングリソース）、Filecoin（分散ホスティング）。しかし、これらは遅く、複雑で、しばしばコストも高いため、広く採用されていない。
業界は表面上は分散化を謳いながら、原則と便利さの間のトレードオフが生じるたびに、中央集権的な解決策を選び続けている。
規制当局が見ているもの—そしてなぜ関心を高めているのか
30日間に3回の大規模障害は、政策立案者の注意を引いた。彼らは今、明らかにすべきことを見ている：少数のテクノロジー企業が重要なインフラを無効化できる。
問いはこうだ：
過去のインフラ障害時、政策専門家は明言していた：単一のベンダーが失敗すると、メディアはアクセス不能になり、安全な通信は停止し、デジタル社会を支えるインフラは崩壊する。
政府は、インターネットインフラの集中がシステムリスクを生むことを認識し始めている。
しかし、規制だけでは解決しない。本当の解決策は、業界自身が自主的に分散型インフラを採用すること—それには、中央集権的な失敗の痛みが、中央集権的解決策の便利さを上回る必要がある。
誰も答えたくない質問
暗号業界は11月18日に「失敗」したわけではない。ブロックチェーンのプロトコルは動き続け、ノードは合意を維持し、取引は有効だった。
業界の自己欺瞞は崩れた。
その欺瞞とは：
ブロックチェーンがブロックを生成し続けているが、ユーザーが取引を送信できなければ、それは実際に機能していると言えるのか？技術的にはYes。実用的にはNo。
インフラが間違った瞬間に故障したときのための緊急対応策はない—市場の崩壊時や、本人確認システムが同時にオフラインになったときなど。
今の業界の「災害復旧戦略」は単純だ：Cloudflareが問題を解決するのを待つ。AWSがサービスを復旧するのを待つ。Microsoftがパッチを展開するのを待つ。障害が重要な市場の瞬間と重ならないことを祈る。
これは計画ではない。ビジネス継続性を装った麻痺状態だ。
次回の確実性
11月18日の障害は、また別のインフラ故障につながるだろう。それはAWS、Azure、Google Cloud、あるいは別のCloudflareの設定変更から起きるかもしれない。
来月起きるかもしれないし、来週かもしれない。
根底にあるインフラは変わっていない。依存関係も変わっていない。業界のインセンティブも変わっていない—集中型ソリューションは、分散型よりも安価で速く、便利だからだ。
次の故障を防ぐための構造的な対策は何もない。なぜなら、それを防ぐには、必要になるまで見えない利益をもたらす複雑さと冗長性に投資する必要があるからだ。
その瞬間—障害が重要な市場イベントや本人確認システムの停止、最大の金融ダメージが発生する瞬間—に備えることはできない。業界は再び、「分散化」が哲学であり、アーキテクチャではないことを痛感するだろう。
そして、インフラが常に利用可能だと仮定してアプリケーションを構築した者たちは、その仮定が砂の上に築かれていたことを痛い目で学ぶことになる。