観測された短時間の攻撃
サイトが一時的に開けなくなったとき、自然に戻ったからといって、原因まで分かったことにはなりません。短い異常でも、発生時刻と影響したページを残しておくと、後から通信やサーバーの記録と照合できます。
Cloudflareが2026年10月29日に公表した報告では、7～9月に同社ネットワークで緩和したネットワーク層のDDoS攻撃は1,820万件でした。その96％は10分未満で終了しています。DDoSは、多数の機器などから通信を送り、サービスを使いにくくする攻撃です。
これは同社が観測した攻撃の件数で、被害企業数や日本のサイトの被害率ではありません。攻撃の継続時間も、利用者がサイトを使えなかった時間とは別です。「大半は10分待てば復旧する」という意味ではありません。
アクセス増加と攻撃を決めつけない
同じ報告には、ウェブのやり取りに当たるHTTPの攻撃リクエスト14.4兆件という値もあります。こちらは一つ一つの要求の数で、先ほどの攻撃件数とは単位が違います。二つの値を合計して攻撃数を増やしたり、自社のアクセス数と直接比べたりはできません。
サイトが遅くなる原因には、正規の利用者の集中、アプリケーションの不具合、外部サービスの停止などもあります。画面の遅さだけでDDoSと判断せず、発生時刻、ページ、エラー表示、決済や受付まで進めたかを記録します。これは観測結果を踏まえた運用上の提案で、原因を自動判定する方法ではありません。
運用担当者は、外部から見た表示と、サーバーや防御サービスの記録を合わせて調べます。トップページは開けても問い合わせフォームだけ失敗する場合と、複数のページが開けない場合では、調べる範囲が変わります。別の端末や回線で試した結果も残すと、利用者側だけの問題かを切り分ける材料になります。
保守会社へ伝える時刻にはタイムゾーンも添え、監視側の記録と取り違えないようにします。
連絡先と受付の代替を用意する
平常時には、サイトの管理者、保守会社、通信や防御サービスの窓口を整理します。緊急時に誰が連絡し、誰が顧客への案内を決めるかも合わせて決めます。防御サービスを使っていても、契約や構成によって確認できる記録や対応範囲は異なります。
問い合わせや注文の入口が止まる業務では、使える別の受付方法と、その案内を出す場所を用意します。代替先を設ける際は、個人情報を扱ってよい窓口か、担当者が通常業務へ引き継げるかも点検します。
復旧後は、停止していた間の送信や注文を確認し、利用者に何度も再操作させたことで重複が生じていないかを照合します。短い異常も記録に残すと、同じ時刻や操作で繰り返していないか、次の対処で何を調べるかを具体的にできます。
参考資料：Cloudflare DDoS Threat Report 2026 Q3。確認日：2026年11月2日。