Elevate 2026開催まであとわずか。シカゴ、ロンドン、シドニーのいずれかでお会いしましょう。

Register here

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

Elevate 2026開催まであとわずか。シカゴ、ロンドン、シドニーのいずれかでお会いしましょう。

Register here

ロジックモニターブログ

停電事後検証：X停電が独立監視の必要性を高めた理由

Xが24時間停止した際、独立機関による監視で数分以内に影響が確認されました。外部からの可視性を活用することで、ITチームがベンダーのアップデートに常に先んじて対応できる仕組みをご覧ください。

7〜10分
デントン千倉

ニュースレター

最新情報のメール配信を登録

最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

シェア

クイックダウンロード:

制御できないプラットフォームに障害が発生した場合、独立した監視体制があれば、影響を数分で確認できるか、何時間も手探りでトラブルシューティングを行うかの違いが生じます。

  • Xは24時間にわたり30カ国以上で繰り返しダウンし、その間、ベンダーからの情報提供はまばらだった。

  • Catchpointのインターネットソナーは、各障害発生の波をリアルタイムで検知し、世界的な広がりをマッピングし、問題が社内インフラの外部にあることを確認した。

  • トレースルートと待機時間データは、深刻なパケット損失と応答時間の低下を示しており、これは後に言及されるDDoS攻撃Xと一致するパターンであった。

  • 重要なベンダーが次にサービスを停止する前に、監視対象が自社のインフラストラクチャだけでなく、ユーザーが実際に利用するインターネット経路まで及んでいるかどうかを確認してください。

あなたのビジネスは、あなたが制御できないプラットフォームに依存しています。そうしたプラットフォームのいずれかに障害が発生した場合、重要なのは、チームがどれだけ迅速に影響を確認し、明確にコミュニケーションを取り、間違ったシステムのトラブルシューティングに時間を浪費せずに済むかということです。2025年3月10日に発生したX（旧Twitter）のグローバル障害は、まさにこの課題を世界中のITチームに突きつける事例となりました。

LogicMonitor傘下のCatchpoint社危機をリアルタイムで検知 インターネットソナーこれにより、プラットフォーム自体からの情報発信が乏しい一方で、独立した監視体制が構築されました。ITチームにとって、この教訓は単なる一件にとどまりません。独立した監視体制なしに不透明なサードパーティ製プラットフォームに依存している組織は、重大な盲点を抱えたまま運営していることになります。

何が起こったのか、監視データから何が明らかになったのか、そして外部からの可視性がなぜ重要なのかを改めて認識させられたこのインシデントからITチームが何を学ぶべきかについて説明します。

X障害の説明：何が起こったのか

2025年3月10日午前5時30分（米国東部時間）から、世界中のユーザーが突然Xから切断された。その後24時間にわたり、断続的な障害（短時間の復旧を挟みながら）が発生し、ユーザーはフィードへのアクセス、メッセージの送信、コンテンツの利用ができなくなった。この障害はアルゼンチンからアラブ首長国連邦まで30か国以上に及び、プラットフォームのグローバルな展開と、その障害の規模の大きさを浮き彫りにした。

接続タイムアウトが原因で、障害は複数の段階を経て発生した。

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

10年3月

  • 第一波：
  • 午前5時（米国東部夏時間）： Xが地表に到達したとの最初の報告。
  • 午前6時（米国東部夏時間）： ほとんどのユーザーにとって、Xは再び利用できるようになります。
  • 第二波：
  • 午前9時（米国東部夏時間）： 2度目の障害報告によると、Xは再びダウンしているようだ。
  • 第三波：
  • 午前11時（米国東部夏時間）： 3度目の障害報告が相次ぎ、Xが再びダウンした。
  • 回復フェーズ：
  • 東部夏時間午後1時15分 Xは多くのユーザーにとって復旧する。
  • 東部夏時間午後2時15分 Xは一部のユーザーには正常に動作しているものの、多くのユーザーが引き続き問題を報告している。
  • 東部夏時間午後3時25分 ほとんどの人にとって、Xは回復する。

11年3月

  • その他の報告：
  • 午前5時（米国東部夏時間）： 停電報告件数がわずかに増加した。

報道時点では停電は収束したようだが、根本原因の調査が続くにつれて状況は変化する可能性がある。

サードパーティ製プラットフォームにこれほど明白な不具合が発生した場合、ITチームにとって最初の課題は、問題が内部にあるのか、外部にあるのか、あるいは依存関係のどこかにあるのかを判断することです。独立したインターネット監視ツールを使えば、この問題を数時間ではなく数分で解決できます。自社のインフラストラクチャが健全であることを確認し、影響を受けている外部依存関係を特定し、関係者への説明や顧客への情報提供に必要な証拠をチームに提供します。

インターネットソナーがどのようにして混乱を明らかにしたか

Internet Sonarは、障害発生時にリアルタイムでXの複数の障害を検出しました。X関連の複数のドメインがコンテンツを配信できなくなりました。これらのドメインは、他のウェブサイトにコンテンツを読み込むためによく使用されます（「子リクエスト」と呼ばれます）。多くの場所で広範囲にわたる障害が発生したことは、今回の障害がXおよびXのインフラストラクチャに依存する他のウェブサイトにどれほど大きな影響を与えたかを示しています。

Xのサービス中断の散布図

上記の散布図は、障害発生期間中にX社のドメインに対して実行された複数のテスト結果を示しています。赤い点の集まりは、テストが継続的に失敗またはタイムアウトした時点を示しています。それぞれの集まりは障害発生の波に対応しており、今回の障害発生時にX社の接続問題が繰り返し発生し、広範囲に及んでいたことを明確に示しています。

Catchpointのポータルからのウォーターフォールチャート

上記のウォーターフォール図は、X社のサーバーには当初アクセスできたものの、応答時間が著しく低下したことを示しています。最終的に、これらのリクエストは完全にタイムアウトし、サーバーは要求されたコンテンツを配信できませんでした。これは、障害発生時にユーザーが経験した遅延を示しています。

Catchpointのポータルからのトレースルートデータ

上記のtracerouteデータは、障害発生時に特にパケット損失率が高く、往復時間（RTT）が長かったという深刻な問題を示しています。パケット損失率が高いということは、Xのサーバーに送信されたデータが途中で頻繁に失われたことを意味し、RTTの増加は、Xのサーバーからの応答が大幅に遅延したことを示しています。これらのことから、障害発生時にユーザーのパフォーマンスが低下した理由が明確に分かります。

x.comの障害発生時の典型的なユーザーエクスペリエンスを示すスクリーンショット

データが示唆していたこと

CEOのイーロン・マスク氏は、停電の原因は DDoS（サービス拒否）攻撃独立した監視データは、その説明と一致するパターンを示したが、監視だけでは根本原因を決定的に確認することはできない。

3日間の待ち時間データ

X Corpのドメインについて長期間にわたって収集されたデータによると、障害発生時には平均待ち時間が著しく増加したことが示されています。これはサーバーの応答速度が低下したことを示唆しており、DDoS攻撃時に典型的に見られる現象と一致します。待ち時間の増加に加え、複数の地域で観測された深刻なパケット損失と応答速度の低下は、大量データ攻撃と整合しています。ただし、同様の症状は、インフラストラクチャの設定ミスや、予期せぬ負荷による容量不足によっても発生する可能性があります。

監視は緩和策に取って代わるものではありません。組織は、全体的なレジリエンス戦略の一環として、DDoS攻撃対策とWAFの設定についても評価する必要があります。

X障害から得られた教訓

Xの障害は、企業が自社で管理していないプラットフォームに依存している現状、そして問題が発生した際に企業の可視性がどれほど限られているかという、深刻な脆弱性を露呈させた。

インターネットは相互接続されており、それがリスクを生み出す。

今回の障害は、見落としがちな事実を改めて浮き彫りにした。インターネットは相互依存するシステムの集合体であり、一つのプラットフォームの障害が連鎖的に影響を及ぼす可能性があるのだ。Xは一度ダウンしただけではない。24時間にわたって繰り返し障害が発生し、数百万人がサービスにアクセスできなくなった。

現代のアプリケーションは、サードパーティサービス、API、クラウドプロバイダー、DNSリゾルバーなどの層を含むインターネットスタックに依存しています。各層は潜在的な障害点であり、いずれかの層に障害が発生すると、その影響は連鎖的に広がります。

インターネットスタックのレイヤー

波及効果を考えてみてください。中小企業はリアルタイムの顧客エンゲージメントを失い、ジャーナリストは速報ニュースを共有できず、時間的制約のあるコミュニケーションにプラットフォームを利用していた組織は、オーディエンスへの情報伝達に遅延が生じる可能性に直面しました。規模の大小を問わず、どのプラットフォームも混乱から免れることはできません。備えは、まずそのリスクを認識することから始まります。

ベンダーによるアップデートだけでは不十分：独立した可視性が重要

障害発生中、ユーザーはX社のCEOからの短い声明以外には限られた情報しか得られなかった。このような状況は珍しいことではない。ベンダーのステータスページは、急速に変化する事態に追いつくのに苦労することが多く、情報伝達の遅れは混乱を招き、影響を受けた企業の対応を遅らせる。

独立したプロアクティブな監視ツールは、組織に明確なリアルタイムの情報を提供します。これにより、ベンダーとのコミュニケーションのタイミングに関わらず、より迅速な対応と円滑な業務運営が可能になります。

独立監視活動の実践

Xの障害は、なぜプロアクティブで独立した監視が重要なのかをまさに示しました。 インターネットソナー (NAIST) と インターネットスタックマップ イベント中に特に役立った2つの機能を備えていた。

Internet Sonarは、ベンダーに依存しないリアルタイムの検出機能を提供しました。障害の最初の兆候を捉え、その世界的な広がりをマッピングし、影響を定量化しました。ITチームにとって、これは迅速な対応を可能にする時間となりました。ユーザーからの苦情に対応したり、ベンダーのステータスページ更新を待ったりする代わりに、チームは独自に問題を確認し、最初の障害発生から数分以内に関係者とのコミュニケーションを開始することができました。

インターネットソナー

上記のインターネットソナーの地図表示は、障害がどれほど広範囲に及んだかを示しており、世界中の複数の場所で通信障害が報告されている。

このような事態が発生した場合、独立した監視はチームにいくつかの具体的な面で役立ちます。

  • 影響範囲の確認： ソーシャルメディア上の噂話やベンダーの発表に頼るのではなく、チームは障害の地理的範囲と機能的範囲を直接確認することができる。
  • 社内関係者への説明： どのサービスがどの程度影響を受けているかを示す実際のデータがあれば、チームは「調査中です」という曖昧な表現ではなく、具体的で信頼できる最新情報を経営陣に提供できる。
  • 顧客への情報提供： 外部との通信は、独立したテレメトリによって支えられることで、より高速かつ正確になる。
  • 無駄なトラブルシューティングを避ける： 監視によって問題が外部要因によるものであることが確認されれば、チームは自社のインフラストラクチャの調査を中止し、回避策や緊急時対応計画に集中することができる。

Internet Stack Mapは、Xの依存関係を可視化することで、この状況を補完しました。プラットフォームがダウンした際、チームは相互接続されたサービス（API、認証レイヤー、コンテンツ配信ネットワークなど）がどのように影響を受けたかを正確に把握できました。この依存関係の可視化により、漠然とした障害情報が、影響を受けたサービスを特定するための具体的なマップへと変わりました。ベンダーによる事後分析を待つと数日かかることが多かった根本原因分析も、独立したデータを用いることでわずか数分で完了するようになりました。

重要なサードパーティプラットフォームが障害を起こした場合に監視すべき事項

主要なプラットフォームがダウンした場合、監視対象はユーザーと影響を受けるサービス間の経路全体を網羅する必要があります。

  • DNS解決と伝播
  • CDNとエッジ配信
  • BGPルーティングとパスの変更
  • APIの依存関係と応答時間
  • 複数の地域における合成テストの性能
  • 実際のユーザーへの影響を示す指標（エラー率、ページ読み込み失敗など）

外部視点からの可視性が監視戦略に不可欠な理由

Xの障害は、従来のインフラ監視だけではファイアウォールの外側で何が起こっているかを把握できないことを改めて示す事例となった。Xのようなプラットフォームがダウンした場合、その原因はDNS、BGPルーティング、CDNレイヤー、あるいは内部ツールでは見えないサードパーティサービスにある可能性がある。

これはどこですか？ インターネットパフォーマンス監視 適合します。世界中の実際のユーザーの視点から、外部インターネット経路を独立して監視することで、ITチームは、依存しているものの制御できない依存関係を可視化できます。

LogicMonitorのプラットフォームは、この外部からの可視性を実現し、 完全自動化された (NAIST) と エドウィン AI 単一のシステム内で管理できるため、チームは外部のインターネット障害と内部サービスへの影響を関連付け、調査時間を短縮し、問題が自社の環境内、外部、あるいはその中間にある場合でも、自信を持って対応できます。

複雑な分散システムを管理するITチームにとって、次のステップは具体的です。現在の監視体制が自社のインフラストラクチャだけでなく、ユーザーが実際に利用するインターネット経路まで網羅しているかどうかを評価してください。サードパーティの依存関係の監視範囲を見直してください。次に重要なベンダーがサービスを停止した際に、チームがステータスページを更新するだけでなく、独立したデータに基づいて対応できることを確認してください。

外部からの可視性が、重要なベンダーの障害発生時にどのようにチームを守るのかをご覧ください。

LogicMonitorは、外部インターネット監視とインフラストラクチャに関する洞察を組み合わせることで、あらゆる障害発生時に影響を正確に特定し、自信を持って対応できるようにします。

よくあるご質問

DNSキャッシュのエントリはどのくらいの期間有効ですか？

各DNSレコードには、権威ネームサーバーによって秒単位で設定されたTTL（有効期限）値が含まれています。レコードはキャッシュされると、そのTTL値からカウントダウンを開始します。TTL値がゼロになると、エントリは削除され、次のクエリで新たなルックアップが実行されます。

NSキャッシュトラップとは何ですか？また、それを回避するにはどうすればよいですか？

NSキャッシュトラップは、ネームサーバーのNSレコードと対応するA/AAAAレコードのTTLが一致しない場合に発生します。どちらか一方が先に期限切れになるため、余分なルックアップや完全な再帰処理が発生します。これを回避するには、DNSゾーン設定でNSレコードとA/AAAAレコードのTTLが一致していることを確認してください。

ブラウザはDNSサーバーとどのように異なる方法でDNSをキャッシュするのでしょうか？

ブラウザやアプリケーションは、OSの「getaddrinfo()」関数を使用します。この関数はIPアドレスを返しますが、TTLデータは返しません。アプリケーションにTTLが渡されないため、各ブラウザは独自のキャッシュ期間とレコード制限を設定します。これらの値はブラウザやバージョンによって大きく異なるため、最新の動作については、ブラウザの開発者ツールまたは内部情報ページ（例：chrome://net-internals/#dns）を確認してください。

デントン千倉著

テクニカルライター

デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。

関連ブログ

可観測性ROI：実際の導入による真のコスト削減
Blog

可観測性ROI：実際の導入による真のコスト削減

可観測性を高めることで、アラートのノイズを減らし、インシデント対応を迅速化し、ダウンタイムを削減し、エンジニアが計画的な作業に費やす時間を増やすことができます。LogicMonitorの顧客は、これらのメリットを活用してコストを削減し、より適切なインフラストラクチャの意思決定を行っています。
2026 年 9 月 9 日
さらに詳しく
HTTPSは中間者攻撃への解決策となるのか？
Blog

HTTPSは中間者攻撃への解決策となるのか？

合成監視によって隠れたHTTPリダイレクト攻撃がどのように明らかになったか、そしてHTTPS、HSTS、配信経路の可視化がユーザーを傍受から守る理由をご覧ください。
2026 年 9 月 9 日
さらに詳しく
古いDNSグルーレコード：親レコードと権威レコードの不一致を診断する方法
Blog

古いDNSグルーレコード：親レコードと権威レコードの不一致を診断する方法

権威サーバーは正しいIPアドレスを返しているにもかかわらず、ユーザーが古いIPアドレスにアクセスしてしまうケースがあります。ここでは、古いグルーレコードを見つけて、親ゾーンのリファラルを修正する方法をご紹介します。
2026 年 9 月 9 日
さらに詳しく