WEBサイトCloudflare Radarは2026年7〜9月に49件の障害を数え、政府の遮断が19件、停電が14件、自然災害が5件だった ── 外側の原因と内側の原因を分け、担当サイトが止まったときの確かめ順を決める13項目（2026年10月時点）
Cloudflare Radarは2026年7〜9月に49件の障害を数え、政府の遮断が19件、停電が14件、自然災害が5件だった ── 外側の原因と内側の原因を分け、担当サイトが止まったときの確かめ順を決める13項目（2026年10月時点）
目次
01 何が起きたか — Cloudflare Radarは、2026年7〜9月に49件の障害を数え、政府の遮断が19件、停電が14件、自然災害が5件だった
引用について
この記事の「" "」で囲んだ英語の文は、Cloudflareのブログと文書、Googleの文書からの引用で、日本語訳は記事の筆者が付けたものである。各ページは2026年10月29日に開き、本文を取り直して、1文字ずつ照らして確かめた。出典に書かれていない筆者の読みは、「筆者の読み」と書いて分ける。
2026年10月27日に、Cloudflareが公式ブログで「What took the Internet offline in Q3 2026」（訳: 2026年の第3四半期に、何がインターネットを止めたか）を公開した。書いたのはLai Yi Ohlsenで、読む時間は8分と表示されている。Cloudflareの通信の観測サービス「Cloudflare Radar」が、7月から9月までに検出して注記した障害を、四半期ごとにまとめた記事である。
この記事は、障害のニュースの解説ではない。止まった原因の分け方を、担当サイトに引き寄せて、止まったときの確かめる順番を決めることに絞る。原因を当てるのは担当者の仕事ではなく、外側の原因か、内側の原因かを、先に切り分けるための順番を作る。
3か月の数字（原文のまま）
"In total, Cloudflare Radar recorded 49 disruptions during the quarter."
（訳: この四半期に、Cloudflare Radarは、合計49件の障害を記録した。）
内訳は、原文の次の文に書かれている。
"Government-directed shutdowns accounted for 19 incidents, including 18 exam shutdowns in Iraq. Power outages followed with 14 incidents, while natural disasters accounted for five."
（訳: 政府の指示による遮断は19件で、うち18件はイラクの試験に伴う遮断だった。停電が14件で続き、自然災害は5件だった。）
残りの11件は、原文が分類を書いていない
3つの分類が重ならないとして、足すと38件で、49件との差は11件になる。この11件は、筆者の計算である。原文は、ネットワーク1つの中の障害として、ガイアナの事業者のケーブル切断、ポルトガルの事業者の「大規模な攻撃」の報告などを挙げるが、11件の分類と件数は、数字としては書いていない。
回復までの時間
"Many disruptions were brief: 14 saw traffic return to typical levels in under an hour, and 16 recovered in less than three hours."
（訳: 多くの障害は短かった。14件は1時間以内に通信が通常の水準に戻り、16件は3時間以内に回復した。）
筆者の読みでは、14件と16件の関係は、原文からは分からない。16件が14件を含むのか、別の16件なのかは、書かれていない。一方で、長く続いた例も書かれている。グアムの台風では、通信が通常に戻るまで数日、コロンビアの地震では4日半、エチオピアのティグライ地方の遮断では10日、キューバの停電のうち1回は3日だった。
02 なぜ・背景 — 原因が分かれると、確かめる場所が変わる
外側の原因と、内側の原因（筆者の整理）
止まった原因を、筆者は2つに分ける。この分け方は出典に書かれたものではなく、確かめる場所を決めるための整理である。
- 外側の原因:電力、回線、地域の遮断、災害、契約先の設備など、自社のサーバーの外にあるもの。
- 内側の原因:自社のサーバーの設定、アプリ、更新、証明書の期限など、自社の側にあるもの。
原文が原因を書いた範囲は、電力・回線・災害・政府の指示など、いずれもサイトの持ち主から見て外側にある。担当サイトが止まったとき、最初に分けるのは、この2つのどちらかである。
| 比べる点 | 外側の原因 | 内側の原因 |
|---|---|---|
| 見え方 | 一部の地域や回線、端末で開かない。同じ事業者の他のサイトも開かない | どこからも開かない、または特定のページだけ開かない。更新や設定の変更の直後に起きる |
| 確かめ方 | 別の回線、別の地域の外形監視、事業者のステータス、Radar | 自社のログと監視、直前の変更の履歴、エラーの応答の番号 |
| 連絡する先 | 契約先（ホスティング・回線・CDN・DNS） | サーバーや制作の担当者、直前に更新した人 |
表は、筆者の整理である。見え方だけでは、どちらかを決めきれないので、確かめ方を順に当てる。
Radarが、1件ごとに付ける情報
RadarのOutage Centerが1件ごとに付ける情報（場所・ネットワーク・種類・範囲・原因・開始と終了の時刻）は、当サイトの記事「Cloudflare Radarの新しいトップは、障害と通信量の地図になった ── アクセスが急に減った日、原因が自社の外にあるかを確かめる13項目（2026年10月時点）」に書いた。ここでは、原因の欄は「ありそうな原因」であって、確定ではないとだけ書く。担当サイトの切り分けでも、原因の欄を確定として扱わない。
同じ見え方で、層の違う原因
1つ前の四半期のまとめ（2026年第2四半期）には、DNSの署名の誤りで、.deのサイトが一斉に開けなくなった例がある。原文は、利用者の目からは、こう見えた、と書く。
"From a user's perspective, the incident was experienced not as a DNS or cryptographic failure but simply as a wave of .de websites and services suddenly becoming unreachable."
（訳: 利用者の目から見ると、この出来事は、DNSや暗号の失敗としてではなく、.deのサイトとサービスが突然つながらなくなる波として経験された。）
画面の症状は同じでも、層は違う。「開けない」という症状だけでは、サーバーの故障か、DNSか、回線かは分からない。
物理の設備が、サイトを止める
今回の原文は、設備の故障を2つ挙げる。1つは、9月10日のホンジュラスで、相互接続の設備の停電が、少なくとも11の主要な事業者に影響した例である。
"The outage lasted approximately three hours, during which HTTP traffic across the country fell by 63%."
（訳: 障害は約3時間続き、その間、国全体のHTTPの通信は63%減った。）
もう1つは、8月13日の、アメリカのフェニックスにあるデータセンターの冷却の故障である。原文は、Namecheap（AS22612）からの通信が、ほぼ完全に落ちた、と書く。ホスティングの契約先の設備の故障は、サイトの持ち主からは見えない場所で起きる。
一部のネットワークだけ、影響を受けない
同じホンジュラスの例で、原文は、影響を受けなかったネットワークも挙げる。
"Two notable exceptions were the cross-border provider Telecomunicaciones de Guatemala (AS14754) and mobile carrier Celtel (AS52262), which were unaffected."
（訳: 特に目立つ例外は、国境をまたぐ事業者のTelecomunicaciones de Guatemala（AS14754）と、携帯の事業者のCeltel（AS52262）で、この2つは影響を受けなかった。）
日本の例もある。熊本の地震（規模7.1）では、影響が主にパソコンの通信に出て、携帯の通信は、ほとんど影響を受けなかった、と原文は書く。1つの回線、1つの端末で見て「開く」と言っても、全員に開くとは限らない。
止まったあとの、検索への影響
Googleの文書は、サーバーのエラーについて、こう書く。
"5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling."
（訳: 5xxと429のサーバーのエラーは、Googleのクローラーに、巡回を一時的に遅くさせる。）
同じ文書は、すでに登録されたURLは残るが、やがて外れる、と書く。サーバーが2xxの応答に戻ると、巡回の頻度は、少しずつ上がる。止まった時間が短ければ、影響も小さい、と筆者は読む。ただし、短いと言える長さは、文書には書かれていない。
03 用語 — 出てくる言葉を、先にそろえる
ASN（自律システム番号）
用語
インターネットの中で、1つの事業者や組織が管理するネットワークに付く番号。原文の「AS14754」などは、この番号である。回線事業者や、ホスティングの会社が、それぞれ持つ。
外形監視
サイトの外から、決まった間隔でページを開いて、開けるかを確かめ続ける仕組み。サーバーの中の記録とは違い、読者と同じ側から見た結果が残る。
ステータスのページ
用語
サービスの提供元が、障害や保守の状況を知らせるために公開しているページ。メールやRSSで知らせを受け取れるものが多い。事業者ごとに、場所が違う。
切り分け
用語
止まった原因が、自社の側か、外側かを、確かめる順番を決めて絞り込むこと。原因を当てることではなく、次に誰へ連絡するかを決めるための作業である。
回復までの時間
障害が始まってから、通信が通常の水準に戻るまでの時間。原文は、この時間で障害を並べ、1時間以内と3時間以内の件数を書く。
5xxと503
サーバーが、要求に答えられないときに返す、HTTPの応答の番号の仲間。500番台は、サーバーの側の問題を示す。503は、一時的に使えない、という意味で使われる。
04 型別 — 止まったとき、外側か内側かを切り分ける順番
順番は、筆者が決めた整理である。原文は、事業者の助言を書いていない。原文の数字と、Radarと検索の文書に書かれた範囲を使って、順番を組んだ。
🅰 見え方の3つの型
止まったときの見え方は、大きく3つに分けられる。見え方で、最初に疑う側が変わる。
| 見え方 | 最初に疑う側 | 最初に見る場所 |
|---|---|---|
| 自分の手元だけ開かない | 手元の回線、手元のDNS | 別の回線（スマホの回線）で開く |
| 一部の地域や回線で開かない | 外側（地域・事業者のネットワーク） | Radar、事業者のステータスのページ |
| どこからも開かない | 自社のサーバー、契約先の設備 | 契約先のステータスのページ、自社の記録 |
🅱 この順番が測っていないこと
この順番は、原因を確定するものではない。Radarの数字は、Cloudflareの網を通った通信に見えた範囲で、サイトの外側の状況を知る手がかりになる。ただし、自社のサイトの停止が、Radarに載る規模とは限らない。載らなくても、止まったことは事実である。
🅲 手順 — 6つの順番
手順1 — 手元の回線を変える
Wi-Fiを切り、スマホの回線で開く。会社の回線と家の回線でも比べる。自分の手元の問題を、最初に外す。当サイトも、10月28日に止まったとき、手元の回線とDNSが正常かを、最初に確かめた。
手順2 — 別のサイトを開く
同じサーバーに載っている別のサイトと、同じ事業者の別のサーバーのサイトと、まったく別の事業者のサイトを開く。結果は、次のように読む。
- 同じサーバーの別のサイトも開かない → そのサーバー（または契約先の設備）が疑わしい。
- 同じ事業者の別のサーバーは開く → 事業者全体ではなく、1台の問題の可能性が高い。
- 別の事業者のサイトは開くのに、担当サイトだけ開かない → 担当サイトか、その契約先の側が疑わしい。
手順3 — 外形監視を、2か所以上で見る
外形監視の結果を、監視の場所ごとに見る。1か所だけが赤なら、その場所と担当サイトの間の問題の可能性がある。複数の場所が赤なら、担当サイトの側である可能性が高い。ホンジュラスの例のように、同じ障害でも、影響を受けない回線があるからである。
手順4 — 事業者のステータスを見る
ホスティング、CDN、DNS、ドメインの登録の4つの契約先のステータスのページを、順に開く。お知らせが出ていなければ、「出ていない」と記録する。出ていないことは、止まっていないことの証明ではない。
手順5 — Radarで、地域・ネットワーク・期間を見る
RadarのOutage Centerで、サイトの設置国と、回線事業者のASNと、止まった期間を合わせて見る。見るのは、期間と場所が重なるかだけである。当サイトの記事「Cloudflare Radarの新しいトップは、障害と通信量の地図になった ── アクセスが急に減った日、原因が自社の外にあるかを確かめる13項目（2026年10月時点）」に、画面の見方を書いた。
手順6 — 自社の記録を、2種類以上読む
サーバーのログ、監視の記録、システムの記録のうち、2種類以上を開く。1つの記録の途切れは、その記録を書く仕組みの都合かもしれない。最後に、止まった時刻と、戻った時刻を、日本時間で書き留める。
この順番を使う場面
- 夜間に「開かない」と連絡が来たとき。手順1〜3の結果を、そのまま担当者への連絡に書ける。
- 制作会社や契約先に、調査を頼むとき。手順の結果（どこまで確かめたか）を添えると、相手が最初から調べ直さずに済む。
- 止まったあとの報告書を書くとき。手順4〜6の結果が、「分かっていること」と「まだ分からないこと」の分け方になる。
注意
止まった原因を、確かめる前に連絡文面に書かない。「サーバーの故障」「回線の障害」は、手順5まで済んでから書く。分からない間は、「原因を調べています」と、分かっていることだけを書く。
05 明日、自社のサイトで確認できることチェックリスト
以下は、担当サイトが止まったときに、外側か内側かを先に切り分けられるよう、前もって準備しておく13項目である。1番目は契約先の整理、2〜5番目は連絡先と比べる先と記録の決め方、6〜7番目は外形監視と手元の確認、8〜9番目は過去の記録と戻った判断、10〜13番目はGoogleの画面、連絡文面、記録である。Radar Alertsや巡回の統計の見方は、当サイトの記事「Cloudflare Radarの新しいトップは、障害と通信量の地図になった ── アクセスが急に減った日、原因が自社の外にあるかを確かめる13項目（2026年10月時点）」に任せる。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。
- 担当サイトごとに、ホスティング、CDN、DNS、ドメインの登録の4つの契約先を書き出し、各社のステータスのページのアドレスを1行ずつ書き添える
- 4つの契約先それぞれの緊急連絡先（電話・問い合わせの窓口）と、サポートの受付時間を、1番目の一覧に書き足す
- サイトが置かれているサーバーの設置場所（国・地域）を、契約先の画面か問い合わせで確かめ、1行で書く
- 手順2で使う比較用のアドレスを、「同じ事業者の別のサーバーのサイト」と「別の事業者のサイト」で2つずつ決めて書く
- 止まったときの時刻の書き方（日本時間・秒まで・どの機器の時計か）を決め、記録の表の1行目に書く
- 外形監視の場所が1か所だけなら、別の地域か別の事業者の監視を足せるかを、担当者に1通のメールで聞く
- Wi-Fiを切ったスマホの回線と、会社の回線の両方で、担当サイトのトップページを開き、開けたかを1行ずつ書く
- 過去に止まった日があれば、その日の記録（ログ・監視・連絡）が残っている場所を調べ、保存先を3つまで書く
- 止まったあとに「戻った」と判断する基準（何回続けて開けたら戻ったとみなすか）を、数字で1つ決めて書く
- Google Search Status Dashboardを開いて、直近の表示で障害が出ていないかを確かめ、RSSの受け取り方があることも確かめる
- サイトが止まったときの連絡文面を、「いつから・どこで・何が見えないか・分かっていること・次の連絡の時刻」の5行で1つ書いておく
- 止まったときに記録する項目（確認した時刻・確認した場所・応答の番号・画面の写し・連絡した相手）を、1枚の表に書き、保存先を決める
- 確かめた日と、1〜12番目の結果の数字、次に見直す日を、担当サイトの記録に1行で書く
実務のヒント
2番目の購読は、止まる前に済ませる。止まったあとにステータスのページを探すと、探している間に時間が過ぎる。11番目の連絡文面も、止まる前に書いておくと、止まった当日は、空欄を埋めるだけで済む。
当サイトの無料ツールで補えることもある。外から見える情報を集めて、DNSの記録や証明書の状況を確かめるには、🔧 WEBサイトを外から調べて、セキュリティ対策の状況を点検する、外からできるセキュリティ対策監査ツールが使える。ツールのページによれば、DNSの解析、SSL/TLSの分析、ポートの確認が入る。会員限定で、管理しているサイトだけに使う、とページに書かれている。止まっている間の原因を判定するツールではない。
止まったあとの画面を記録に残したいときは、🔧 WEBサイトのスクリーンショットを、まとめて撮るツールが使える。ページによれば、URLを指定して、PCとスマホの画面を、ある程度まとめて撮れる。戻ったあとの画面の確認に使う道具で、止まっている最中の記録には向かない。
06 代替・他の選択肢 — 止まったときの情報源を、並べて比べる
次の表は、止まったときに見られる情報源を、公式の文書に書かれた範囲で並べたものである。各ページは、2026年10月29日に開いて確かめた。
| 情報源 | 分かること | 分からないこと |
|---|---|---|
| Cloudflare Radar | 地域やネットワークごとの障害と、ありそうな原因、開始と終了の時刻 | 自社のサイトが止まった理由。Cloudflareの網を通った通信に見えた範囲だけ |
| 事業者のステータス | その事業者が公表した障害と保守の状況 | 公表されていない問題。公表の遅れ |
| Googleの状況の一覧 | Googleの検索の巡回・登録・順位・表示の障害 | 担当サイト自身の停止 |
| クロールの統計情報 | Googleが巡回したときの、サーバー接続やDNSの失敗の割合 | Googleが巡回していない時間の状況 |
| 自分で置く外形監視 | 読者と同じ側から見た結果。自分で決めた間隔と場所の範囲 | 間隔の間に起きて戻った停止。監視の場所以外の見え方 |
外形監視の間隔と場所（筆者の読み）
外形監視の間隔と場所は、出典に決まりが書かれていない。筆者の読みでは、原文の数字から、次のことが言える。回復まで1時間以内の障害が14件あったので、間隔が1時間より長い監視は、止まって戻った障害を、取りこぼす可能性がある。そして、同じ障害でも影響を受けない回線があるので、場所が1か所だけの監視は、「開く」と答えて見逃すことがある。ただし、Radarの数字は国やネットワーク単位のもので、個別のサイトの停止の長さを示さない。ここでは、目安としてだけ読む。
Radar Alertsと、巡回の統計
Radar Alertsの設定と、Search Consoleの数字の見方は、当サイトの記事「Cloudflare Radarの新しいトップは、障害と通信量の地図になった ── アクセスが急に減った日、原因が自社の外にあるかを確かめる13項目（2026年10月時点）」に書いた。Cloudflareのアカウントが無ければ、Radar Alertsは使えないので、事業者のステータスの購読が代わりになる。Search Consoleのクロールの統計情報は、止まったあとに、Googleの側から止まった事実を確かめる材料になる。止まっている最中の通知には向かない。
止まったあとの、検索の落ち込みの見方
止まったあとにアクセスが減った場合、原因が停止だけとは限らない。Googleの文書は、技術的な問題として、サーバーの状態を挙げ、次のように書く。
"the issues can be site-wide (for example, your website is down)"
（訳: 問題は、サイト全体のこと（たとえば、サイトが止まっている）もある。）
文書は、技術的な問題のほかに、セキュリティの問題、スパム、季節の変動なども並べる。止まった日と減った日が重なっても、他の原因を見落とさない。
07 当サイトで確かめたこと — 10月28日に、サーバーが約20分止まった
当サイトは、Cloudflareを使っていない。したがって、Cloudflareの数字は、当サイトのものではない。止まったときの確かめ順は、ブログの圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方に書いた事実の範囲で、書く。
止まった日の事実
10月28日の11時43分ごろから、サーバーに外から届かなくなった。pingも、SSHも、Webも届かず、同じサーバーに載っている別のサイトも止まった。こちらの回線とDNSは正常で、同じ事業者の別のサーバーは開いた。12時02分には、サーバーが起動し直されていた。ナミオさんは何もしておらず、事業者からのお知らせも無かった。
手順1と手順2に当たる切り分けが、ここで効いた。こちらの回線を疑い、同じ事業者の別のサーバーで確かめて、「事業者全体ではなく、1台の問題」と分けた。
記録を、2種類読んだ
サーバーのログは、11時43分01秒で途切れていた。それを見て、最初は「突然止まった」と読んだ。別の記録を開くと、システムの監査の記録には、11時43分07秒から、サービスが順に44個止まり、10秒にシステムが停止した、という記録があった。ログを書く仕組みが先に止まったので、ログが早めに途切れて見えただけだった。
手順6の「記録を2種類以上読む」は、この経験から入れた。記録の途切れた時刻を、止まり方の証拠にしない。止める合図の出どころは、ブログの公開時点では、まだ確かめていない。
確かめていないこと
当サイトは、Cloudflare Radarの障害の一覧に、10月28日の停止が載っているかを確かめていない。当サイトの停止は、載る規模ではないと筆者は考えるが、確かめていない。停止の原因は、事業者の側の記録で確かめる必要があり、その結果は、まだ出ていない。
08 このテーマは、ここまで
止まったあとの確かめ方と、アクセスが減ったときの確かめ方は、別の記事で書いてきた。
アクセスが減った日に、外側の原因を確かめる
Cloudflare Radarの新しいトップは、障害と通信量の地図になった ── アクセスが急に減った日、原因が自社の外にあるかを確かめる13項目（2026年10月時点）は、Radarの画面の見方と、減った日を同じ曜日と比べる手順を書いた。今回の記事は、サイトが止まった側に、軸を置いた。
止まった日の、当サイトの記録
ブログの圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方に、止まった事実と、起動し直されたあとに確かめた5つを書いた。
外へつなぐ先を、数えておく
ブログの認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録は、サーバーから外へつなぐ先の一覧を作る話である。止まったときに、契約先を数えておく話と、同じ向きにある。
2026年10月29日 — この記事の確認日
この記事の内容は、2026年10月29日に、Cloudflareのブログ3本と、Radarの文書2本、Googleの文書3本、Cloudflareのステータスのページを開いて確かめた時点のものである。次の四半期のまとめが出たときは、日付つきで追記する。
現在の貴方のIPアドレス
このサイトで書いている人
