混乱の中の沈黙：Xの障害が示す、能動的な監視への警鐘

見えない障害に備えよ

2025年3月22日
著者: Ritik Sharma
翻訳: 逆井 晶子

この記事は米Catchpoint Systems社のブログ記事「Silence during chaos: Why the X outage is a call to arms for proactive monitoring」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

2025年3月10日から11日にかけて、X（旧Twitter）が世界的な障害に見舞われ、何百万人ものユーザや企業が原因を探し求めました。
CEOのElon MuskがDDoS（サービス拒否）攻撃に言及する短い投稿をした以外、公式な情報はほとんどありませんでした。
CatchpointのInternet Sonarはこの危機をリアルタイムで検知し、能動的な監視の重要性を浮き彫りにしました。

以下では、障害の経過を追いながら、脆弱なデジタル基盤に備えるために必要な知見を整理していきます。

Xの障害とは？ 何が起きたのか

2025年3月10日午前5時30分（EDT）から、世界中のユーザが突然Xから切断されました。
その後24時間にわたり、短時間の復旧を挟みつつ複数回の障害が発生し、ユーザはフィードの閲覧、メッセージの送信、コンテンツへの関与ができない状態に置かれました。
この障害はアルゼンチンからUAEまで、30か国以上にわたる影響を及ぼし、Xプラットフォームへの世界的な依存度の高さを浮き彫りにしました。

接続のタイムアウトにより、障害は段階的に発生し、それぞれに明確な特徴が見られました。

リアルタイムで追跡したXの障害

3月10日

第1波

午前5時30分（EDT）：Xがダウンしているという初期報告が上がる。
午前6時30分（EDT）：ほとんどのユーザでXが復旧。

第2波

午前9時30分（EDT）：再びXがダウンしたとの報告が増加。

第3波

午前11時15分（EDT）：3回目の障害が発生。

回復フェーズ

午後1時15分（EDT）：多くのユーザでXが復旧。
午後2時15分（EDT）：一部のユーザでは利用可能だが、多くはまだ問題を報告。
午後3時25分（EDT）：ほとんどのユーザでXが復旧。

3月11日

追加報告

午前5時00分（EDT）：障害の報告が一時的に増加する動きがありました。

報道時点では障害は収束しているようですが、根本原因の調査が続く中で再発する可能性もあります。

CatchpointのInternet Sonarが障害をどう検知したか

CatchpointのInternet Sonarは、X関連の複数のドメインがコンテンツを配信できない状況をリアルタイムで検知しました。

上記のInternet Sonarのビューは、複数のX関連ドメインがコンテンツを配信できなかった様子を示しています。
これらのドメインは他のWebサイトがコンテンツを読み込む際（いわゆる「子リクエスト」）にも利用されているため、障害はXにとどまらず、そのインフラストラクチャに依存する他のWebサイトにも深刻な影響を及ぼしたことが明らかになりました。

上記の散布図は、障害期間中にX社のドメインに対して実行された複数のテストを示しています。
赤い点のクラスターは、テストが一貫して失敗またはタイムアウトしたタイミングを示しています。
各クラスターはそれぞれの障害の波に対応しており、今回の障害におけるXの接続問題が繰り返しかつ広範囲にわたって発生したことを明確に示しています。

上記のウォーターフォールチャートは、Xのサーバには当初接続可能だったものの、応答が非常に遅かったことを示しています。
最終的に、これらのリクエストは完全にタイムアウトし、サーバから要求されたコンテンツが一切配信されませんでした。
このことは、障害発生中にユーザが体験した深刻な遅延を浮き彫りにしています。

上記のトレースルートデータは、障害発生中に重大な問題が発生していたことを示しており、特に大規模なパケットロスと高い往復時間（RTT）が確認されました。
高いパケットロスは、Xのサーバへ送信されたデータが途中で頻繁に失われたことを意味し、RTTの増加はXのサーバからの応答が著しく遅延していたことを示しています。
これらの問題は、障害中にユーザが非常に遅いパフォーマンスを体験した理由を明確に示しています。

障害の原因

CEOのElon Muskは、この障害の原因をDDoS攻撃であると述べました。

X社のドメインに対する継続的な測定において、障害発生時に平均待機時間が明らかに増加していたことが確認されました。
これは、サーバの応答が遅くなっていたことを示しており、DDoS攻撃時に典型的に発生する現象と一致しています。

教訓：明確さと備えで障害を乗り越える

Xの障害は、単なる一時的な混乱ではなく、デジタル時代における脆弱性を示す実地の教材となりました。
以下に、企業、ITチーム、そしてユーザにとっての重要な教訓を整理し、ノイズを排しつつ警戒と対策ツールの必要性を強調します。

1. インターネットは相互に接続されており、そして脆弱である

この障害は、我々が見落としがちな事実を明らかにしました。
つまり、一見広大に見えるインターネットも、実際には相互に依存する複雑で繊細な構造の上に成り立っているということです。
Xほど影響力のあるプラットフォームですら、24時間内に繰り返しダウンし、多くのユーザがアクセスできない状態となりました。
この脆弱性は、ソーシャルメディアだけに見られるものではありません。
モダンアプリケーションはInternet Stack、すなわちAPI、クラウドプロバイダ、DNSリゾルバなど、複数のサードパーティサービスの層に依存しています。
このうちのひとつでも崩れれば、全体がほころびる可能性があるのです。

Xの障害による波及効果を考えてみてください。
リアルタイム対応を必要とする小規模ビジネスは顧客との接点を失い、ジャーナリストは速報の発信が困難となり、さらに一部地域では緊急サービスが通信の遅れに苦しめられました。
明らかに言えるのは、どれほど支配的なプラットフォームであっても、障害からは免れないということです。
備えは、この脆弱性を認識することから始まります。

2. ベンダーの情報だけでは不十分 — 独立した可視性が重要

障害の間、ユーザが得られた情報は、XのCEOによる短い声明だけでした。
これは珍しいことではなく、多くのベンダーのステータスページは、急速に進行する障害に追いつけないことがあります。
しかしこうした遅延は、混乱を招き、影響を受ける企業やユーザの対応を遅らせる要因となります。

ここでの教訓は、責任追及ではなく「備え」にあります。
独立した能動的な監視ツールを導入することで、自社の状況を明確かつリアルタイムで把握でき、ベンダーの情報更新を待たずに迅速な対応と安定した運用が可能になります。

3. より良い対策：独立した能動的監視の活用

Xの障害は、能動的かつ独立した監視ツールの必要性を浮き彫りにしました。
当社のユーザは、ポータルの2つの重要なソリューション「Internet Sonar」と「Internet Stack Map」を活用し、大きな効果を得ました。

Internet Sonarは、まさに嵐の中の灯台のように機能しました。
リアルタイムかつベンダーに依存しないインサイトを提供し、障害の最初の兆候を検知し、その世界的な広がりをマッピングし、影響範囲を定量化しました。
これによりITチームは、ユーザからの苦情に反応するのではなく、ワークフローを迅速に切り替えたり、関係者に早期に通知したりすることが可能となり、重要な「時間」を確保できました。

Internet Sonarのマップビューでは、世界各地で報告された障害の範囲がいかに広範であったかが示されています。

Internet Stack Mapはこれを補完し、Xが依存しているサービスを可視化しました。
プラットフォームが停止した際、Stack Mapのユーザは、API、認証レイヤー、コンテンツ配信ネットワークなど、どの相互接続サービスが影響を受けたかを正確に把握できました。
これにより、「ブラックボックス化」された事象が、分析可能な課題へと変わり、通常であれば数日かかる根本原因の特定が、わずか数分で可能になりました。

4. 見落とされがちだが重要：堅牢なWAFソリューションの導入

DDoS攻撃から保護するためには、Webアプリケーションファイアウォール（WAF）を導入し、適切に構成することが重要です。
堅牢なWAFは、悪意あるトラフィックをサービスに影響を与える前に特定して緩和し、独立した監視と連携することで、リアルタイムの可視性とともに能動的なセキュリティを提供します。
Xの障害は、今日のデジタル世界において、独立した可視性が単なる便利な機能ではなく、 レジリエンス、備え、そして混乱時の信頼維持に不可欠であることを痛感させる厳しい教訓となりました。
Internet Sonarによるライブインターネット障害マップをご覧ください。