WEBサイトCloudflareは2026年7〜9月のDDoS報告で、ネットワーク層の攻撃の96%が10分未満で終わったと書いた ── 数分の負荷の急増が監視に映るかと、自動の緩和が効くかを確かめる13項目（2026年10月時点）
Cloudflareは2026年7〜9月のDDoS報告で、ネットワーク層の攻撃の96%が10分未満で終わったと書いた ── 数分の負荷の急増が監視に映るかと、自動の緩和が効くかを確かめる13項目（2026年10月時点）
目次
01 何が起きたか — Cloudflareは2026年7〜9月のDDoS報告で、ネットワーク層の攻撃の96%が10分未満で終わったと書いた
引用について
この記事の「" "」で囲んだ英語の文は、Cloudflare・Google・AWS・CISA・Apacheの公式の文書からの引用で、日本語訳は記事の筆者が付けたものである。各ページは2026年10月30日に開き、本文を取り直して、1文字ずつ照らした。筆者の読みは、「筆者の読み」と書いて分ける。
2026年10月29日に、Cloudflareが公式ブログで「Cloudflare DDoS Threat Report 2026 Q3: More swarms, fewer giants」（訳: Cloudflareの2026年第3四半期のDDoS脅威レポート ── より多くの群れ、より少ない巨人）を公開した。シリーズの26回目で、Cloudflareの脅威情報の部門Cloudforce Oneが書き、読む時間は6分と表示されている。7月から9月までに、Cloudflareの網で観測された攻撃をまとめた報告である。
この記事は、国別や業種別の順位ではなく、数分で終わる攻撃や負荷の急増に、人の手は間に合わないという点に絞る。数分の急増を、監視で見られるか、契約先の自動の緩和で受けられるかを、確かめる順番を決める。
3か月の数字（原文のまま）
"Across its network in the third quarter of 2026, Cloudflare autonomously mitigated 18.2 million network-layer DDoS attacks and 14.4 trillion HTTP DDoS requests."
（訳: 2026年の第3四半期に、Cloudflareは自社の網の全体で、ネットワーク層のDDoS攻撃1,820万件と、HTTPのDDoS要求14.4兆件を、自動で緩和した。）
原文は、これを1時間あたり約8,226件、約0.44秒に1件、とも書く。ネットワーク層は攻撃の件数で、HTTPは要求の数で数えており、2つの数は単位が違う。足したり、同じ棒で比べたりしない。
短く、小さい攻撃が増えた
"Short-burst, low-bandwidth attacks lasting under 10 minutes and 1 Gbps surged by 208%."
（訳: 10分未満・1 Gbps未満の、短時間で帯域の小さい攻撃は、208%増えた。）
本文は、ネットワーク層の攻撃1,820万件に続く箇条書きで、2つの割合を書く。
"96% ended in under 10 minutes"
（訳: 96%は10分未満で終わった。）
"98% stayed under 1 Gbps, more than enough to overwhelm a server or website"
（訳: 98%は1 Gbps未満にとどまったが、サーバーやウェブサイトを圧倒するには十分すぎる大きさだった。）
巨大な攻撃は減った
1 Tbpsを超えた攻撃は、4〜6月の805件から、7〜9月の251件に減った。原文の要約は、4つの大きなIoT機器のボットネットに対する年初の法執行を挙げて、「影響を映している可能性がある」（possibly a reflection）と書く。摘発と減少の因果は、原文が断定していない。この記事でも、因果として扱わない。
前の報告と並べると（期間が違う）
10分未満で終わった割合は、前の2つの報告にも書かれている。並べる。
| 報告 | 対象の期間 | 公開日 | 10分未満で終わった割合（ネットワーク層） |
|---|---|---|---|
| 2025年第3四半期（23回目） | 2025年7〜9月 | 2025年12月3日 | 89%（HTTPのDDoSは71%） |
| 2026年上半期（25回目） | 2026年1〜6月 | 2026年8月11日 | 90.60% |
| 2026年第3四半期（26回目） | 2026年7〜9月 | 2026年10月29日 | 96% |
表の数字は、各報告の本文から写した。期間が3か月と6か月で違い、小数の桁も違う。数え方が3つの報告で同じかどうかは、確かめていない。傾向とまでは言い切らない。
数え方で、分からないこと
読んだ本文から、分からないことを4つ書き出す。
- 攻撃1件の数え方。どこからどこまでを1件とするかの定義は、読んだ本文には見当たらなかった。
- 208%の指す範囲。本文には、ネットワーク層の攻撃1,820万件が、2025年の同じ四半期から+208%とある。冒頭の要約では、短時間で帯域の小さい攻撃が208%増えた、とある。同じ数なのかは、書かれていない。
- 96%と98%の母数。ネットワーク層の攻撃に続く箇条書きなので、HTTP層の割合ではない。
- Cloudflareの網の中の数字。Cloudflareが自社の網で観測した範囲で、一般のサイトに共通の割合とは言えない。
02 なぜ・背景 — 短い攻撃には、人の手が間に合わない
原文が書いた「人が見る前に終わる」
Cloudflareは、報告の終わりの節で、自社の自動の緩和について、こう書く。
"Autonomy is the point: our systems detect and mitigate attacks without human intervention."
（訳: 自動で動くことが要点である。私たちのシステムは、人が介在せずに、攻撃を検知して緩和する。）
"And they need to, because as this quarter's distributions make clear, most attacks end long before a human analyst could see the alert, and the largest attacks still regularly exceed 1 Tbps at a cadence measured in hundreds per quarter."
（訳: そうする必要がある。この四半期の分布が示すとおり、ほとんどの攻撃は、人の分析担当者が通知を見られるよりずっと前に終わり、最大級の攻撃は、四半期に数百件という頻度で、今も1 Tbpsを超えるからである。）
前の報告（2026年上半期）にも、同じ趣旨の文がある。
"Whether an attack lasts half a minute or ten minutes, there is no practical window for human intervention: by the time an alert reaches a security analyst, the attack has already completed."
（訳: 攻撃が30秒続いても10分続いても、人が介入できる現実的な時間はない。通知がセキュリティの分析担当者に届くころには、攻撃はすでに終わっている。）
筆者の読みでは、これは自動の緩和を売る側の文書で、強調に偏りがある。ただし、通知を見てから人が動く前提で足りる時間の長さを、数字で確かめるという考え方は、どの製品でも使える。
小さい攻撃でも、小さいサイトには大きい
1 Gbps未満の攻撃が98%という数字は、小さい攻撃ばかりという意味ではない。原文は、その大きさでも、サーバーやウェブサイトを圧倒するには十分、と書く。
担当サイトの契約が、1秒あたりにどれだけの通信と要求を受けられるかは、契約ごとに違う。数字は、契約先の資料で確かめる。
短い攻撃のあとに残るもの
前の報告は、短い攻撃のあとの影響を、こう書く。
"The cascading effects of even a short burst can trigger routing instability, TCP retransmissions, application timeouts, and downstream service degradation that takes hours or days to fully resolve — all while services remain down or impaired."
（訳: たとえ短い急増でも、その連鎖の影響で、経路の不安定、TCPの再送、アプリケーションの時間切れ、下流のサービスの劣化が起き、完全に解消するまで数時間から数日かかることがあり、その間、サービスは止まったままか、損なわれたままである。）
筆者の読みでは、「攻撃が終わった」と「サイトが戻った」は別の事実で、戻ったかは別に確かめる。
Cloudflareを使っていないサイトに、当てはまるか
- 当てはまらない部分:96%や98%などの割合は、Cloudflareの網で観測された数である。担当サイトの割合では、ない。
- 当てはまる部分:数分で終わる急増に、人が通知を見て動くのでは間に合わない場合がある、という設計の前提。担当サイトの契約先に、自動の緩和があるかを確かめる理由になる。
当サイトは、Cloudflareを使っていないので、Cloudflareの数字を当サイトの数字として書かない。当サイトで確かめたことは、07章に書く。
03 用語 — 出てくる言葉を、先にそろえる
DDoS（分散型のサービス妨害）
用語
多数の機器が、1つの標的に向けて、いっせいに通信や要求を送り、正規の利用者が使えない状態にする攻撃。CISAの文書は、複数の機械が協調して1つの標的を攻撃するものだと説明し、乗っ取られた機器の集まり（ボットネット）が使われることが多い、と書く。
ネットワーク層と、HTTP層
Cloudflareの文書は、DDoSの緩和を「3/4層（ネットワーク層）」と「7層（アプリケーション層）」に分ける。3/4層は通信そのものを溢れさせる攻撃、7層はHTTPの要求を大量に送る攻撃、と筆者は整理する。この記事の96%と98%は、ネットワーク層の数字である。
緩和（mitigation）
攻撃の通信を見分けて、止める、または捨てる処理。「検知」は見つけること、「緩和」は被害を小さくすることで、別の段階である。
反射と増幅
用語
送り元のアドレスを標的のものに偽った小さい問い合わせを、公開されたサーバーに送り、サーバーに大きい応答を標的へ返させる攻撃の型。今回の報告では、DNSの増幅が215%増えて、ネットワーク層の攻撃の3.43%を占めた、と書かれている。
Gbps・pps・rps
Gbpsは1秒あたりの通信量、ppsは1秒あたりのパケットの数、rpsは1秒あたりの要求の数である。同じ攻撃でも、どの単位で測るかで大きさの見え方が変わる。契約先の資料の数字が、どの単位かを、先に見る。
外形監視と、確認の間隔
サイトの外から、決まった間隔でページを開き、開けたかを確かめ続ける仕組みを、外形監視という。確認の間隔が、見える山の最小の長さを決める。間隔が5分なら、3分で終わる山は、確認の間に入る場合がある。
04 型別 — 負荷の急増を、監視の細かさで見る
この章の整理は、筆者が決めたものである。原文は、サイトの持ち主向けの手順を書いていない。原文の数字と、各社の文書に書かれた範囲を使って、順番を組んだ。
🅰 急増の見え方の3つの型
| 型 | 見え方 | 確かめる場所 |
|---|---|---|
| 数分で終わり、自動の緩和で収まる | 利用者は気づかないことがある。契約先から通知が来る場合がある | 契約先の通知、アクセスの記録の1分ごとの件数 |
| 自動の緩和が無い・足りず、数分だけ重くなる | 外形監視の一部が失敗する。応答が遅くなる。5xxが出る | 外形監視の失敗の数と間隔、サーバーの記録、応答の番号 |
| 長く続く | 長い時間、重いままになる（原文の例は49.7時間） | 契約先への連絡、通信の経路を変える判断 |
長く続く型の例は、原文にある。今回の四半期で、Mirai系の最も長く続いた攻撃は、次の文である。
"The quarter's longest sustained Mirai attack ran 49.7 hours between August 19 and August 21."
（訳: この四半期で最も長く続いたMiraiの攻撃は、8月19日から8月21日にかけて、49.7時間続いた。）
🅱 この整理が測っていないこと
3つの型の割合は書けない。96%には、緩和されたかどうかが含まれていない。担当サイトの契約先が緩和しているかは、契約先の資料で確かめるしかない。
🅲 手順 — 5つの順番
手順1 — 1分ごとの件数を、アクセスの記録から出す
アクセスの記録の時刻から、1分ごとの件数を数えて、多い順に並べる。5分や1時間の平均だけを見ない。平均は、短い山を薄めて見せる。
手順2 — 外形監視の間隔と、失敗の条件を確かめる
外形監視の設定画面で、確認の間隔と、失敗とみなす条件を読む。Googleの文書は、既定の通知の条件を、こう書く。
"By default, notifications are sent when at least two regions report uptime check failures for a duration of at least one minute."
（訳: 既定では、少なくとも2つの地域が、少なくとも1分間、稼働の確認の失敗を報告したときに、通知が送られる。）
これはGoogle Cloudの外形監視の説明で、同じ文書は、確認の場所が少なくとも3つ要る、とも書く。別の製品の既定は、その製品の文書で確かめる。「何か所で・何分続いたら失敗とみなすか」の2つが、数分の山を拾えるかを決める、と筆者は読む。
手順3 — 契約先の自動の緩和が、有効かを確かめる
ホスティング、CDN、DNSの契約先ごとに、DDoSの自動の緩和が含まれているかを、各社の資料で探す。たとえば、Cloudflareの文書は、標準の無制限のDDoS保護（3〜7層）を、無料から上のすべてのプランで「Yes」と書く。AWSの文書は、こう書く。
"Shield Standard is provided automatically and at no extra charge when you use AWS."
（訳: Shield Standardは、AWSを使うと、追加の料金なしに自動で提供される。）
契約先が上の2社でない場合は、「DDoSの自動の緩和は、契約に含まれるか。含まれるなら、どの層まで、どの大きさまでか」を、資料か問い合わせで確かめて、記録する。
手順4 — 通知の届け先と、夜間の経路を決める
Cloudflareの通知の文書は、通知の速さを、こう書く。
"Configure notifications to receive real-time alerts (within ~1 minute) about L3/4 and L7 DDoS attacks on your Internet properties, depending on your plan and services."
（訳: 通知を設定して、自分のインターネット上の資産への3/4層と7層のDDoS攻撃について、プランとサービスに応じて、リアルタイムの通知（約1分以内）を受け取る。）
同じ文書の「通知を受け取ったらすること」の欄には、「No action needed」（訳: 対応は要らない）とある。つまり、この通知は、緩和を人に頼む呼び出しではなく、起きたことの知らせである、と筆者は読む。知らせを、夜間と休日に、誰が最初に見るかを決めておく。見る人が決まっていなければ、通知が届いても、朝まで誰も見ない。
手順5 — 急増の原因を、5つの順で切り分ける
急増を見つけたら、攻撃と決める前に、次の順で確かめる。
- 自分たちの作業と重なるか。点検、公開、一括の確認、自動の巡回など、自分たちが動かしたものの時刻と、急増の時刻を並べる。
- 送り元が、少数か多数か。1つの送り元に偏るか、多数に散るかを数える。
- 要求先が、偏っているか。特定のページに集中するか、広く散るかを数える。
- 応答の番号が、変わったか。5xxや429が増えたかを見る。
- 外側の原因ではないか。当サイトの記事「Cloudflare Radarは2026年7〜9月に49件の障害を数え、政府の遮断が19件、停電が14件、自然災害が5件だった ── 外側の原因と内側の原因を分け、担当サイトが止まったときの確かめ順を決める13項目（2026年10月時点）」の6つの順番で、外側の原因を確かめる。
CISAの文書は、攻撃の症状が、ふつうの不具合に似ることを書く。
"Symptoms of a DoS attack can resemble non-malicious availability issues, such as technical problems with a particular network or a system administrator performing maintenance."
（訳: サービス妨害の症状は、特定のネットワークの技術的な問題や、管理者が保守を行っていることなど、悪意のない可用性の問題に似ることがある。）
CISAの文書は、対応中にほかの機器やサービスを見失わないよう注意し、二次的な攻撃が行われる場合があるとも書く。
注意
原因を確かめる前に、「攻撃を受けた」と連絡や報告に書かない。分からない間は、「1分あたりの件数が通常の何倍になった。原因を調べている」と、分かっている数字だけを書く。この整理は、原因を当てるためでなく、次に誰へ連絡するかを決めるためのものである。
05 明日、自社のサイトで確認できることチェックリスト
以下は、数分で終わる負荷の急増に備えて、前もって確かめる13項目である。1〜3番目は自社のアクセスの記録、4〜5番目は外形監視、6〜7番目は契約先、8〜9番目は夜間の経路、10〜12番目は戻った判断・直接の経路・Googleの画面、13番目は記録である。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。
- アクセスの記録から、直近7日の1分ごとの件数を出し、多い順に上位5分の時刻と件数を書き出す
- 1番目の上位5分それぞれについて、同じ時刻に自分たちが行った作業（点検・公開・一括の確認）が無かったかを、作業の記録と照らして書く
- 1番目の上位5分から1つを選び、5分の平均と、1分の最大の件数を並べて、差が何倍かを1行で書く
- 外形監視の確認の間隔と、失敗とみなす条件（何か所で・何分続いたら）を、設定画面で確かめて、1行で書く
- 外形監視の確認の場所が何か所あるかと、通知が届く条件を、設定画面で確かめて、1行で書く
- ホスティング・CDN・DNSの3つの契約先ごとに、DDoSの自動の緩和が契約に含まれるかを、各社の資料のページで探して、有無を書く
- 契約先のDDoSの通知を受け取る設定があるかを、設定画面で確かめて、届け先のメールアドレスを1つ書く
- 通知の届け先のうち、夜間と休日に最初に見る人を1人決めて、名前と連絡の手段を書く
- 夜間に通知が届いたとき、最初の10分に確かめることを3行以内で書き、通知の届け先に共有する
- 「サイトが戻った」と判断する基準（何回続けて開けたら戻ったとみなすか）を、数字で1つ決めて書く
- CDNなどを通らずに、サーバーへ直接つなぐ経路が閉じているかを、契約先に1通のメールで質問する
- Search Consoleの「クロールの統計情報」を開き、サーバーエラー（5xx）が出た日を、3日まで書き出す
- 確かめた日と、1〜12番目の結果の数字、次に見直す日を、担当サイトの記録に1行で書く
実務のヒント
2番目は、先に済ませる。急増の最大の山が、自分たちの作業だったという例が、07章にある。点検・公開・一括の確認の時刻を、1枚の表にしておくと、1分ごとの件数と並べて見られる。
当サイトの無料ツールで補える。アクセスの記録（access.log）を与えて、攻撃の兆候を調べるには、🔧 IPA提供の攻撃兆候検出ツールiLogScannerで、アクセスの記録を簡単に分析するツールが使える。ページによれば、IPAが提供するiLogScannerを、ブラウザから使えるようにしたもので、結果をExcelなどで受け取れる。会員限定で、自分の管理サイトだけに使う。1分ごとの件数を数えるツールではなく、DDoSの急増を見つけるものでもない。手順5の切り分けで、兆候のある要求を探す補助である。
外から状況を点検するには、🔧 WEBサイトを外から調べて、セキュリティ対策の状況を点検する、外からできるセキュリティ対策監査ツールが使える。ページによれば、外からできる限りの情報を取得し、ポートスキャンを行うかを選べる。会員限定で、自分の管理サイトだけに使う。数分の急増を見つけるものではない。
06 代替・他の選択肢 — 自動の緩和と監視を、並べて比べる
ここでは、文書に書かれた範囲だけを並べる。製品の優劣は、比べない。
CDNの自動の緩和
Cloudflareの概要のページは、「Available on all plans」（訳: すべてのプランで使える）と書き、無料のプランから、標準の無制限のDDoS保護（3〜7層）が入ることを、表で示す。管理されたルールの集まりは、HTTPのDDoSと、ネットワーク層のDDoSの2つに分かれ、設定の変更は、プランごとに範囲が違う。無料のプランでも自動の緩和が動くことと、通知や細かい設定が使えることは、別である。
クラウド事業者の標準の保護
AWSの文書は、Shield StandardとShield Advancedが、3/4層と7層の攻撃に対する保護を提供し、Standardは追加の料金なしに自動で、より高い保護は、申し込んで使うShield Advancedで受ける、と書く。標準でどこまで守られるかは、自分の使う資産が対象かどうかを、文書の一覧で確かめて読む。
ホスティングの契約先
契約先の保護は、事業者ごとに違い、この記事では調べていない。確かめるのは、3つである。DDoSの自動の緩和が契約に含まれるか。含まれるなら、どの大きさまでか。大きすぎたときに、サーバーを止める、または回線を切る扱いがあるか。約款か、問い合わせの回答で確かめて、記録に書く。
サーバーソフトの時間切れ
Apacheの文書は、要求を受け取る時間と、最低の通信速度を決める仕組みを、こう説明する。
"Usually, a server should have both header and body timeouts configured."
（訳: ふつう、サーバーには、ヘッダーと本体の両方の時間切れを設定するのがよい。）
文書の説明は、受け取る時間が長すぎる、または通信速度が低すぎる接続を、サーバーが閉じる、というものである。筆者の読みでは、遅い送信で接続を占有する負荷への備えで、大量の通信そのものを止めるものではない。設定の有無は、サーバーの担当者に聞く。
通知の種類と、届く条件
Cloudflareの通知の文書には、種類が分けて書かれている。HTTPのDDoSの通知は、1秒あたり100を超える要求の攻撃を緩和したときが対象で、すべてのプランに含まれる、と書かれている。ネットワーク層の通知は、Magic TransitやBYOIPを持つ利用者向けの種類で、5秒間の平均が1秒あたり12,000パケット以上、かつ1分以上続く攻撃が対象と書かれている。自分の契約で、どの通知を受け取れるかは、契約ごとに違う。また、原文に書かれた条件から、1分未満の攻撃は、標準のネットワーク層の通知の対象外と読める（詳しい版の通知の説明には、続いた時間の条件が書かれていない）。
07 当サイトで確かめたこと — 1分ごとのアクセスを、30日分数えた
先に書いておくこと
当サイトは、Cloudflareを使っていない。この章に書くのは、当サイトのアクセスの記録を、時刻の部分だけ取り出して、1分ごとに数えた結果である。攻撃かどうかの判定ではなく、件数の数え直しである。当サイトの防御や監視の設定は、書かない。
数えた範囲
数えたのは、2026年10月1日0時から10月30日15時31分までの、HTTPSのアクセスの記録である。約4万2,700分のうち、記録のある分は26,658分で、合計は177,132件だった。件数は、ページへの要求が中心で、画像やCSSなどの静的ファイルはほとんど記録されていない。HTTPの側の記録は、数えていない。
結果 — 記録のある分の中央値は2件
記録のある分の中央値は、1分あたり2件だった。100件以上の分は、193分ある。最大は、10月23日2時49分の2,448件で、次に多いのは、毎朝、決まった時刻にサーバー自身の点検で出る、数千件に近い山だった。
最大の山の多くは、自分たちのサーバーからだった
毎朝の山を、2日分（10月29日と30日）で調べた。どちらの日も、山の件数のほぼすべてが、サーバー自身のアドレス（127.0.0.1）からの要求だった。外から来た急増ではなく、サーバーの中から出た要求である。朝の自動の点検の時刻と重なる、と筆者は読む。2日分のほかの日は、中身を見ていない。
5分の平均では、山が薄まった
10月30日の朝の山を含む5分間は、合計3,595件で、5分の平均は1分あたり約719件になる。ところが、1分ごとに見ると、山の1分は2,439件あり、平均の約3.4倍だった。5分の区切りの平均だけを見る監視では、1分の山は、薄まって見える。
外から確かめた作業が作った、1分の山
最大の2,448件（10月23日2時49分）は、次の1分に454件、その次の分からは、数件以下に落ちた。1分で始まり、2分で終わった山である。同じ日の未明に、当方はサーバーの中から、公開の場所に残った控えのファイルを外から読めるか1本ずつ確かめる作業をしていた。アクセスの記録を照らすと、2時49分の記録の2,447件は、どれもサーバー自身からの、中身を取らない形の要求（HEAD）で、ほぼすべてが控えのファイルの名前を指し、全件が403（読めない）だった。同じ日の作業の記録と形が一致する。山は、攻撃ではなく自分たちの確かめの作業だったと見てよい。
この結果から言えること
- 1分の件数と、5分の平均で、山の高さが数倍違う例が、当サイトにもあった。
- 最大の山は、自分たちの作業が作ったものと見てよい。急増を見つけたら、先に自分たちの作業と時刻を重ねる（手順5の1番目）。
- 短い山は、1分ごとの件数を出さなければ、見えない。
確かめていないこと
当サイトの契約先で、DDoSの自動の緩和が含まれるか、通知がどこへ届くかは、この記事を書くまでに確かめていない。05章の6番目と7番目の項目に当たる。外から来る急増の送り元や要求先も、数えていない。数えた範囲のうち、朝の山の2日分のほかは、送り元を見ていない。
08 このテーマは、ここまで
DDoSの数字の読み方と、サイトが止まったあとの確かめ方は、別の記事で書いてきた。この記事は、数分で終わる急増に、軸を置いた。
止まった日の、外側の原因を確かめる
外側の原因を確かめる順番は、Cloudflare Radarは2026年7〜9月に49件の障害を数え、政府の遮断が19件、停電が14件、自然災害が5件だった ── 外側の原因と内側の原因を分け、担当サイトが止まったときの確かめ順を決める13項目（2026年10月時点）に書いた。この記事は、止まる前の、短い急増に置いた。
悪質な自動アクセスを、名乗りと発信元で分ける
急増の送り元を数えるときは、名乗りと発信元を分ける。Yandexの通信が大きく落ちた週、悪質な自動アクセスは止まらず別の業者へ移った、とCloudflareは書いた ── 総量の増減ではなく、名乗り・発信元・ふるまいで分けて数える13項目（2026年10月時点）に書いた。
当サイトのログを、数え直した記録
ブログのCloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直すは、他人の大きな数字を、自社のログで数え直す話である。Cloudflareが確認済みのボットを「行儀」で評価し始めた週、当サイトの9つの名乗りの取得（4,317行）の18.1%は、公式のIPアドレスの一覧と合わなかった ── 14日分のログで数え直したと、「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだったは、ログを日別や名乗り別に割ると、見え方が変わった記録である。
毎朝の点検が出す数字
警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かったは、毎朝の自動の点検の報告を読む話である。この記事の07章の朝の山は、同じ朝の点検の時刻に当たる。
止まった日の、当サイトの記録
ブログの圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方に、10月28日の停止の事実を書いた。
2026年10月30日 — この記事の確認日
この記事の内容は、2026年10月30日に、Cloudflareのブログ3本と文書3ページ、Google・AWS・CISA・Apacheの文書を開いて確かめた時点のものである。次の四半期の報告が出たときは、日付つきで追記する。
現在の貴方のIPアドレス
このサイトで書いている人
