https://error-daizenn.hatenablog.com/entry/2025/11/20/211304

2025年11月20日公開

いま何が起きているのか？「また全部落ちた」が増えた気がする問題

ここ数カ月、こんな体験していませんか。

朝スマホを開いたら
Xも、Spotifyも、ChatGPTも、ゲームも、まとめて落ちている。

つい先日は、Cloudflareの大規模障害でOpenAI・Spotify・X・Canvaなど、世界中のサービスが一気にダウンしました。

その少し前には

Google Cloud Platform（GCP）の障害で、YouTube・Google Drive・Maps・Meetなど広範囲がダウン
AWSのUS-EAST-1障害で、Reddit・Snapchat・Slack・Fortniteまで巻き込まれる
さらにMicrosoft Azureの障害で、Microsoft 365・Xbox・Minecraft・Starbucksアプリや航空会社システムまで停止

「え、最近インターネット壊れすぎじゃない？」
って感覚、かなり多くの人が持ち始めています。

でも、ネットワーク解析をしているCisco ThousandEyesによると、
“障害の件数そのもの”は、過去と比べて特別増えているわけではないそうです。

じゃあ、なぜこんなにも「世界が一斉に落ちた感」が強くなったのか。
この記事では、

直近の大規模障害を時系列で整理
なぜ「一社のこけ方」が世界中に波及するのか
企業・一般ユーザーはどう備えればいいのか

を、フォーラムで雑談するようなテンションでまとめていきます。
コメント欄で「自分の現場ではこうしてる」って話も、ぜひ聞かせてほしい。

ここ半年の「インターネット大停電」をざっくり時系列で振り返る

まずは、話題になった障害をざっくりタイムライン化してみます。

2025年6月　Google Cloud ＋ Cloudflare 障害コンボ

6月12日（現地時間）、

Google Cloud Platform（GCP）で、世界中の複数リージョンにまたがる大規模障害が発生。
Google Drive、YouTube、Maps、Meet、Nest、Geminiなどに影響し、Downdetectorには世界で約140万件以上の障害報告が集まりました。
原因は「誤ったクォータポリシー」が全世界に複製され、空欄フィールドが原因でクラッシュループを引き起こしたこと、と技術解説でまとめられています。

同じタイミングで、Cloudflare側もWorkers KVなど基盤ストレージの障害で最大2時間半ほど、複数サービスが止まるという“ダブルパンチ”。

2025年10月20日　AWS US-EAST-1 障害

10月20日には、AWSのUS-EAST-1リージョンで15時間を超える大障害。

Reddit、Snapchat、Slack、Fortnite、Coinbase、航空会社など、5万以上のサービスに影響
DNSとDynamoDBエンドポイントの不具合が重なり、「アプリがAWSの住所を引けない」状態になったと分析されています。

2025年10月29日　Microsoft Azure 障害

そのわずか9日後、今度はAzure。

Azure Front Door（AFD）の設定変更ミスが原因で、DNS/ルーティングの不具合が発生
Microsoft 365、Teams、Outlook、Xbox、Minecraftに加え、StarbucksやCostco、航空会社、政府サイトなども次々ダウン
約8時間続く世界的障害となりました。

2025年11月18日　Cloudflare 大規模障害（X・ChatGPT・Spotify など）

そして記憶に新しいのがCloudflare。

11月18日、世界中のCloudflareネットワークでトラフィック処理が失敗し、X、ChatGPT、Spotify、League of Legends、Canva、Downdetectorなどが一斉ダウン。
原因は「Bot Management向けの設定ファイル生成ロジックのバグ」。権限変更がきっかけで、設定ファイルが想定より巨大化し、各ノードのソフトウェアがクラッシュした、と公式ポストモーテムで説明されています。
Cloudflareは「サイバー攻撃ではなく、自社のソフトウェアバグと設定変更が原因」と明言。

こうやって並べると、「四天王か？」ってくらい、Google・Amazon・Microsoft・Cloudflareが順番にやらかしているのが分かります。
ただし、どれも

ゼロデイ攻撃
大規模サイバー戦争

ではなく、“設定ミス＋ソフトウェアバグ＋集中しすぎたインフラ”の組み合わせで落ちているのがポイントなんですよね。

そもそもCloudflareやAWSって何者？なぜ「一社」で世界が止まるのか

ここで一度、「なんでCloudflareがこけるとXやChatGPTまで一緒に落ちるの？」という根本の話を整理しておきます。

Cloudflareは“インターネットの玄関ドア”

Mashableの記事で、Cisco ThousandEyesのAngelique Medina氏はCloudflareの役割を

世界中に分散したサーバーでWebコンテンツをキャッシュし
ユーザーは「各サービスのサーバー」ではなく「まずCloudflareのサーバー」にアクセスする

という“玄関ドア”にたとえています。

つまり、Cloudflareは無数のWebサイトやAPIの前面に立つ「フロントドア役」で、そのドアが閉じると中にあるサービスにたどり着けなくなる。

AWS、GCP、Azureも同じで、

実際のアプリやデータベースがクラウド上にある
そこへ行く入口として、CDNやAPIゲートウェイ、認証基盤がある

この“入口層”が落ちると、裏のサーバーが元気でもユーザーからは「全部死んでる」に見えるわけです。

「障害が増えた」のではなく「一発のパンチが重くなった」

じゃあ、最近になって障害そのものが増えたのか。

ここも、ThousandEyesの継続的な観測では

クラウドやインターネット基盤の障害件数自体は、ここ数年で特に増えているわけではない
ただし、そのサービスに依存している“下流のサイト・アプリ”の数が爆増している

という指摘がなされています。

要するに、

2000年代

ホスティング会社やオンプレがバラバラ
一社が落ちても「その会社の顧客だけ」が死ぬ

2020年代

AWS・GCP・Azure＋Cloudflareなど“ハイパースケーラー”に集約
一社がコケると、その下にぶら下がる何万というサービスが同時死亡

「障害の頻度」は大して変わっていないのに、「一発あたりのダメージ」が桁違いに増えている、というのが今のインターネットの姿です。

欧州のIPリソース管理サービスIPXOのCEOも、今回のCloudflare障害について

デジタル経済が、少数のインフラ事業者の不具合に極端に弱くなっている

とコメントしていて、「集中しすぎ問題」は世界的な課題として認識されています。

「インターネットの集中化」が生まれた3つの背景

じゃあ、なんでここまで集中してしまったのか。ざっくり3つに分解できます。

1. コスト・スピード・スケールの誘惑

自社でサーバーを立てて、世界中にCDNを張る
24時間365日監視して、DDoSからも守る

これを１社で全部やるのは、もはや現実的ではありません。

「AWSやCloudflareを使えば、数クリックで世界中に配信＋セキュリティ＋オートスケール」が手に入り、スタートアップでもグローバルサービスを作れる。
この“チート級の便利さ”が、集中化を一気に進めました。

2. セキュリティとレギュレーションの高度化

WAF、DDoS対策、ゼロトラスト、各国のデータ保護規制…。
これらにすべて自前で対応するのは、とんでもない負担です。

「大手クラウドに乗っていれば、とりあえず一定以上のセキュリティとコンプラに乗れる」という安心感は、特に企業にとって大きな動機になりました。

3. サードパーティ連携の“雪だるま式依存”

SaaSがSaaSに乗る
そのSaaSがさらにCloudflareやAWSに乗る

と、多段階の依存チェーンができてしまい、
誰か一社がくしゃみをすると、その先の何十社・何百社も一緒に風邪を引く状態になっています。

一般ユーザーができること：完全防御は無理。でも「慌てない準備」はできる

「じゃあ個人としてはどうすればいいの？」という話。
正直、インターネット全体の設計は、個人ではどうにもできません。

ただ、「落ちたときに生活を止めない工夫」はいくつかできます。

1. 重要な情報は“クラウド1社依存”にしない

パスワード管理
仕事や学校の重要ファイル
課金系アカウントの情報

これらを、特定クラウド1社だけに置くのではなく

ローカルの暗号化バックアップ
別クラウド（例：OneDriveとGoogle Driveを併用）

などで分散しておくと、「そのサービスだけ落ちたとき」のダメージを減らせます。

2. 認証アプリや2段階認証の“オフライン手段”を持つ

認証アプリが、障害中のクラウドバックエンドに依存している
SMSやメールも、その事業者の障害で届かない

みたいなケース、実は全然ありえます。

可能なら、オフラインで動くTOTP（ワンタイムパスワード）系アプリや、バックアップコードの紙保存を用意しておくと安心です。

3. 「これは落ちても仕方ない」と割り切るサービスを決める

正直、Xや音楽ストリーミング、非必須のゲームあたりは

「落ちたら散歩でも行くか」
「オフラインゲームに切り替えるか」

くらいに“諦め枠”にしておくと、メンタルがだいぶ楽です。

企業・情シス向け：マルチクラウド以前に「単一障害点」を洗い出そう

ここからは、法人・情シス寄りの話。

「マルチクラウドにすればOKでしょ」と言いたくなりますが、現実はもう少し泥くさいです。

1. まず「どこが1社依存になっているか」を棚卸し

認証（IdP）はどこに載っているか
DNSは1社集中していないか
CDN／WAFは全部Cloudflareだけか
SaaS間連携に「単一のハブ」がいないか

このあたりを図に起こしてみると、
想像以上に「ここが落ちたら全部終わり」なポイントが見えてくるはずです。

2. いきなり“完全マルチクラウド”ではなく「代替ルート」を用意

DNSを2社に分ける
認証をフェイルオーバーできるように設計する
少なくとも基幹システムだけは別リージョン・別クラウドにDRサイトを置く

など、「全部マルチ」ではなく

“ここだけは倒れたら本当に死ぬ”ところから二重化する方が現実的です。

3. 「落ちたときにどう仕事を続けるか」の訓練

CrowdStrikeや今回の各種障害を見ても、

完全に止まるリスクをゼロにはできない
だからこそ「オフライン運用」「手作業運用」の手順書が要る

というのは、もはや常識になりつつあります。

社外からメールにアクセスできない前提の連絡手段
POSや決済が止まったときの暫定運用
役員や現場への情報共有フロー

こういう“Bプラン”を、1回でもいいから机上演習しておくと、
本番でのパニック度合いがかなり違います。

フォーラム的・みんなならどうする？

ここまで読んで、「いやいや、うちの現場はもっとカオスだよ…」と思った人も多いはず。
コメント欄がある前提で、こんな感じの話題でワイワイできそうです。

あなたの会社では、Cloudflare・AWS・GCP・Azureのどこに一番依存していますか？
直近のGCP／AWS／Azure／Cloudflare障害で、一番インパクトが大きかったのはどれ？何が止まりました？
マルチクラウドやDR構成、実際に「本番切り替え」までやってみたことありますか？
一般ユーザー視点だと、「このサービスだけは落ちたら本当に困る」って何でしょう？銀行？決済？学校のLMS？

ぜひ、自分の体験談や「こう備えてる」「ここが不安」みたいな話を投げてみてください。
他の人のやり方を見て、「うちもここまではやっとくか…」って気づきが絶対出てきます。

まとめ：障害は“増えてない”けど、ネットは昔よりずっと「割れやすい」

最後に、ポイントだけもう一度ギュッと。

直近半年だけで、GCP・AWS・Azure・Cloudflareという“インターネットの柱”が次々障害を起こし、世界中のサービスが同時多発的にダウンした。
Cisco ThousandEyesの観測では、障害の“件数”自体が激増しているわけではない。ただし、そこに依存するサイト・アプリの数が爆発的に増えた結果、1回の障害の“揺れ方”が巨大になっている。
CloudflareのようなCDNは、無数のサイトの「玄関口」になっているため、玄関が閉じると中身が元気でも“ネット全体が死んだように見える”。
一般ユーザーには「完全防御」は無理でも、

ローカルや別クラウドへのバックアップ
オフライン認証手段
“落ちたら諦めるサービス”の切り分け
でダメージを減らすことはできる。

企業・情シスには、

単一障害点の洗い出し
クリティカル部分だけでも多重化
障害発生時の運用Bプラン訓練
が、これまで以上に重要になっている。

インターネットは昔よりはるかに便利で、はるかに脆くなりました。

だからこそ、「全部を止めない」こと以上に
「止まったときにどう立ち上がるか」「止まったときに何を諦められるか」が、
これからのネットとの付き合い方のキーワードになってくるはずです。

あなたは、次にどこかが落ちたとき、
自分の生活や仕事をどこまで“オフラインモード”で回せそうですか？
その答えを、ぜひ一度ゆっくり考えてみてください。