茨城で震度5弱、直後にDowndetectorが「全面障害」を表示した理由
地震が揺らしたのは地面だけではなかった。障害情報サイトに並んだ赤いグラフの正体を読み解く。
地震が揺らしたのは地面だけではなかった。障害情報サイトに並んだ赤いグラフの正体を読み解く。
茨城県南部でM5.0、緊急地震速報が関東を駆け抜けた
2026年4月1日10時06分、茨城県南部を震源とするマグニチュード5.0の地震が発生している。震源の深さは50km、最大震度は5弱。気象庁は緊急地震速報を発表し、関東一円で一斉にスマートフォンの警報音が鳴り響いた。
津波の心配はない。震源の座標は北緯36.1度、東経140.0度。この地域は太平洋プレートとフィリピン海プレートが複雑に沈み込む「地震の巣」として知られ、過去にも繰り返しM5〜6クラスの揺れを起こしてきた。
茨城県南部で震度5弱以上を観測した地震は、2024年3月21日のM5.3以来、約2年ぶりとなる。
だが今回、地震そのものとは別の現象が注目を集めている。揺れの直後、障害情報サイトDowndetector（ダウンディテクター）が異常な状態を示したのだ。
Downdetectorが映し出した「全面障害」の異様な光景
地震発生から数分後、Downdetectorのトップページに異様な光景が広がっている。X（旧Twitter）、NTTドコモ、Microsoft 365、Claude AI、Gmail、Microsoft Teams、YouTube、ポケモンGO、NTT東日本、Amazon Web Services、OCN、Google、Microsoft Outlook、Yahoo、NTT西日本、Grok、Instagram、Amazon、SoftBank、au by KDDI——。
画面に並ぶサービスのほぼすべてで、障害報告のグラフが急上昇していた。まるでインターネット全体が崩壊したかのような表示だ。
通信キャリアからクラウド基盤、SNS、AIサービス、さらにはゲームまで。これほど多くのプラットフォームが同時に障害を起こすことは、技術的にほぼありえない。では、何が起きていたのか。
「障害」ではなく「不安」がグラフを押し上げる構造
答えはDowndetectorの仕組みそのものにある。このサービスはSNSの書き込みやユーザーからの直接報告を収集・分析し、障害の発生有無を推定している。つまり、表示されるグラフは実際の障害規模ではなく、「困惑しているユーザーの数」を可視化したものだ。
地震が起きると、人は真っ先にスマートフォンに手を伸ばす。安否確認、情報収集、そして「自分の回線は大丈夫か」の確認。このとき一斉にアクセスが集中し、わずかな遅延やタイムアウトが発生する。ユーザーはSNSに「繋がらない」「重い」と投稿する。
Downdetectorはその投稿を拾い上げ、障害報告としてカウントする。実際にはサービスが正常に動作していても、ユーザーの不安がグラフを押し上げる。これが「全面障害」の正体だ。
Downdetectorを運営するOokla社も免責事項で「ツイートの内容の正確性は保証できない」「誤判定や誤検出を表示しないとは保証できない」と明記している。
2018年ソフトバンク障害で証明された「連鎖誤検知」の構造
この現象には前例がある。2018年12月、ソフトバンクで大規模な通信障害が発生した際、Downdetector上ではNTTドコモやauでも障害が発生しているかのように表示された。Gmailや当時のTwitterなど、まったく問題のなかったサービスまで巻き込まれた。
ウィキメディアプロジェクトへの貢献者
原因は単純だ。ユーザーが「ソフトバンクが障害だけど、ドコモは大丈夫」とSNSに書くと、Downdetectorのアルゴリズムは文脈を無視して「ドコモ」というキーワードだけを拾い、ドコモの障害報告としてカウントしてしまう。
今回の地震でも同じメカニズムが働いている。「地震でドコモ繋がらない？」「Claude使えない？」「YouTube重い？」——これらの疑問形の投稿すら、障害報告として処理される。不安が不安を呼び、グラフが雪だるま式に膨れ上がる構造だ。
本当に障害が起きているサービスを見極める方法
では、Downdetectorの情報は無意味なのか。そうではない。ただし、正しい読み方を知っておく必要がある。
地震直後にDowndetectorを確認する場合、ほぼすべてのサービスで報告が急増しているなら、それは地震による集団心理の反映であり、個別のサービス障害ではない可能性が高い。見るべきは、時間が経過した後もグラフが高止まりしているサービスだ。他が落ち着いても特定のサービスだけ報告が増え続けていれば、そこに本当の問題がある。
では「本当の障害」をどう確認すればいいのか。答えはシンプルだ。
公式の障害情報を確認するのが最も確実な手段だ。Google Workspace Status Dashboard、AWS Service Health Dashboard、各通信キャリアの障害情報ページなど、サービス提供者が直接公開している情報を優先すべきだろう。
また、NTTドコモ、KDDI、ソフトバンク、楽天モバイルの4社は2026年4月1日から災害時の事業者間ローミング（ジャパンローミング）を開始している。基地局の被災で特定キャリアが使えなくなった場合でも、他社の回線に自動接続できる仕組みだ。奇しくもこの地震は、制度開始の当日に発生したことになる。
私たちが「障害」と感じるものの正体
正直なところ、Downdetectorの画面を見て不安にならない人は少ないだろう。あれだけのサービスが赤く染まれば、誰でも「大規模障害だ」と思う。
だがその赤は、サーバーの悲鳴ではなく、人間の不安の色だ。地震という制御不能な事態に直面したとき、人はまず「情報」を求め、次に「共有」を求める。そのプロセス自体がDowndetectorに障害として記録される。皮肉と言えば皮肉だが、見方を変えれば、あのグラフはインフラの脆弱性ではなく、人間の情報への渇望を映し出している。
Downdetectorは便利なツールだ。しかし、あくまでも「困っている人の数」を示すものであり、「壊れているサービスの数」を示すものではない。その違いを知っているかどうかで、次の地震のとき、あなたの行動は変わるかもしれない。
参照元
他参照
