DDoS攻撃（分散型サービス妨害攻撃）は、2026年現在、企業・公共機関・金融機関を問わず最も頻繁に発生するサイバー攻撃の一形態となっている。攻撃規模は年々拡大しており、国内でも一瞬でサービスが停止し、数千万円規模の損失が発生したケースが相次いでいる。
本記事では、DDoS攻撃の基本的な仕組みとDoSとの違いから始まり、攻撃手法の分類、2026年の国内被害事例、企業への具体的な影響、そして実践的な防御策と攻撃発生時の対応手順まで体系的に解説する。
DDoS攻撃とは？DoSとの違いと2026年の動向
DDoSとDoSの違い
DoS攻撃（Denial of Service attack）は、単一の発信元から標的サーバに大量のリクエストやパケットを送りつけ、サービスを停止させる攻撃手法である。発信元が一つであるため、そのIPアドレスをブロックするだけで比較的容易に防御できる。
DDoS攻撃（Distributed Denial of Service attack）は、その分散版である。世界中に散らばる数万〜数百万台の感染端末（ボットネット）を一斉に動員し、標的に対して同時に攻撃を仕掛ける。発信元が膨大な数のIPアドレスに分散しているため、単純なIPブロックが通用しない点が最大の特徴であり、防御が格段に難しい。
項目 | DoS攻撃 | DDoS攻撃 |
|---|---|---|
発信元 | 単一のホスト | 分散した多数のボット |
規模 | 小〜中規模 | 大規模（Tbpsクラスも） |
防御の難易度 | 比較的容易（IPブロック等） | 高い（発信元が無数に分散） |
攻撃者の特定 | 比較的可能 | ほぼ困難 |
主な目的 | テスト・嫌がらせ | 業務妨害・身代金・示威行動 |
ボットネットの仕組み
DDoS攻撃の基盤となるボットネットは、マルウェアに感染した一般家庭のPC・スマートフォン・IoTデバイス（監視カメラ・ルーター・スマート家電など）から構成される。感染した端末のユーザーは自分の機器が攻撃に加担していることを知らないまま、攻撃者（C2サーバー：Command and Control Server）の指令に従って標的へ一斉に通信を送り続ける。
2026年現在、IoTデバイスの急増に伴いボットネット構築のコストが低下しており、攻撃規模の大型化が続いている。
2026年の動向
攻撃規模の記録更新 2025年末から2026年前半にかけて、グローバルで過去最大規模のDDoS攻撃が相次いで観測されている。最大攻撃帯域が数Tbpsを超えるケースも報告されており、一般的な企業の上流回線容量では到底吸収できない規模に達している。
ハクティビストによる標的型攻撃 政治的な動機を持つハクティビスト集団によるDDoS攻撃が増加しており、日本の政府機関・金融機関・インフラ企業が意図的に標的とされるケースが顕在化している。
身代金型DDoS（RDoS）の増加 攻撃を実行する前に「支払わなければ大規模DDoS攻撃を行う」と脅迫するRansom DoS（RDoS）が国内企業にも届くようになっている。実際の攻撃能力を持たない脅迫も混在しているが、放置することで実被害につながる事例も存在する。
マルチベクター攻撃の標準化 単一の攻撃手法ではなく、ボリューム型・プロトコル型・アプリケーション層型を組み合わせたマルチベクター攻撃が標準的な手口となっており、防御側の対応を複雑化している。
攻撃の種類
DDoS攻撃は大きく3つのカテゴリに分類される。それぞれ攻撃対象のOSI参照モデルの層が異なり、有効な対策も異なる。
攻撃種別比較表
攻撃カテゴリ | 主な手法 | 攻撃対象の層 | 単位 | 防御の難易度 |
|---|---|---|---|---|
ボリューム型 | UDPフラッド、ICMPフラッド、DNSリフレクション、NTPリフレクション | ネットワーク層（L3）、トランスポート層（L4） | bps（帯域幅） | 中（上流でフィルタリング） |
プロトコル型 | SYNフラッド、ACKフラッド、Pingフラッド、Smurf攻撃 | トランスポート層（L4）、セッション層（L5） | pps（パケット数）/ CPS | 中〜高 |
アプリケーション層型 | HTTPフラッド、Slowloris、RUDY、DNS Query Flood | アプリケーション層（L7） | rps（リクエスト数） | 高（正規通信との区別が必要） |
ボリューム型攻撃
ネットワーク回線そのものを飽和させることを目的とする。攻撃者は少ない通信量で大きな増幅効果を得られる「反射・増幅攻撃」を多用する。
DNSリフレクション攻撃 送信元IPを標的のIPに詐称した上で、オープンリゾルバ（設定の緩いDNSサーバー）に対してDNSクエリを送信する。DNSレスポンスは元のクエリより数十倍大きいため、少ないリソースで標的に大量のトラフィックを集中させられる。増幅率は最大で50〜70倍程度に達する。
NTPリフレクション攻撃 NTP（Network Time Protocol）サーバーのmonlistコマンドを悪用し、最大で約556倍の増幅率で標的に大量トラフィックを送り込む手法である。適切に設定されたNTPサーバーが減少しているため頻度は落ちているが、古い機器が多い環境では依然として有効な攻撃となる。
UDPフラッド UDP（User Datagram Protocol）はコネクションレス型のため、発信元を偽造したパケットを大量に送付しやすい。標的のポートにランダムなUDPパケットを送り続け、ポートが存在しない場合はICMP "Destination Unreachable"の返信が発生し、さらにリソースを消費させる。
プロトコル型攻撃
TCPの接続確立プロセス（スリーウェイハンドシェイク）の脆弱性を突き、サーバーのコネクションテーブルやファイアウォールのセッション管理リソースを枯渇させる。
SYNフラッド TCPはSYN → SYN-ACK → ACKの3ステップで接続を確立する。攻撃者は送信元IPを詐称した大量のSYNパケットを送りつける。サーバーはSYN-ACKを返して接続待機状態（半開セッション）に入るが、ACKが返ってこないため一定時間待機し続ける。この半開セッションがサーバーのリソースを圧迫し、正規ユーザーの接続を受け付けられなくなる。
ACKフラッド 確立されていないセッションへのACKパケットを大量に送信し、ファイアウォールやロードバランサーのセッション追跡テーブルを枯渇させる手法である。ステートフル型ファイアウォールが存在する環境で特に有効とされる。
アプリケーション層型攻撃（L7攻撃）
HTTPリクエストなど正規の通信に見えるパケットを悪用するため、ボリューム型・プロトコル型と比べて少ないトラフィックで大きな被害をもたらすことができる。通常のWebアクセスとの区別が難しく、防御が最も難しいカテゴリである。
HTTPフラッド 正規のHTTP GETまたはPOSTリクエストを大量に送信し、Webサーバーやアプリケーションサーバーのリソース（CPU・メモリ・DBコネクション）を枯渇させる。CDNのキャッシュを回避するため、クエリパラメータをランダムに変化させる手法も見られる。
Slowloris HTTPリクエストのヘッダーを意図的に断片化し、非常にゆっくりと送信し続けることでWebサーバーのコネクションを占有する攻撃である。サーバーはリクエスト完了を待ち続けるため、比較的少ないリソースで多数のコネクションを枯渇させられる。
RUDY（R-U-Dead-Yet?） POSTリクエストのボディを極めてゆっくりと送信し、サーバーの入力待機状態を維持し続ける。Slowlorisのボディ版であり、フォーム送信を受け付けるWebアプリケーションに対して有効となる。
2026年国内被害事例
金融機関：大手ネット銀行へのDDoS攻撃（2025年秋）
2025年9月、国内大手ネット銀行のインターネットバンキングサービスが大規模なDDoS攻撃を受け、約6時間にわたってログインページへのアクセスが著しく低下した。攻撃はマルチベクター型で、ボリューム型と同時にHTTPフラッドが実行されたとされている。利用者への振込・残高確認機能が長時間停止し、金融庁への報告義務が生じた。月末の資金決済需要が集中する時期を狙った攻撃であり、攻撃者の業務知識の高さが指摘された。
ECサイト：大規模セールス期間中の標的型攻撃（2025年冬）
2025年12月、複数の国内大手ECサイトがブラックフライデー〜クリスマスシーズンにかけて断続的なDDoS攻撃を受けた。アプリケーション層への攻撃を中心に、カート機能・決済ページへの負荷が集中した。一部サイトでは数時間の購入不能状態が発生し、機会損失は億円規模に上ったと報告されている。攻撃者は繁忙期のダメージが最大化されることを計算した上でタイミングを選択していた。
公共機関：地方自治体の行政ポータルへの攻撃（2026年春）
2026年3月、ハクティビスト集団を名乗るグループが複数の地方自治体Webサイトに対してDDoS攻撃を宣言し実行した。オンライン住民サービス（マイナンバー関連手続き・各種申請）が半日〜1日程度アクセス不能となった。自治体のインターネット接続回線容量が民間企業と比べて小さいため、比較的小規模の攻撃でも影響が長時間に及んだ。事前の脅迫予告があったにもかかわらず対応が間に合わなかった点が問題とされた。
通信インフラ：ISPへのBGPハイジャックと組み合わせた攻撃（2026年春）
2026年4月、国内ISPの一部ルーターを標的としたDDoS攻撃が、BGPルーティングの不正操作と組み合わせて実行された。特定の通信経路が一時的に切断状態となり、その傘下の法人顧客数十社がインターネット接続を失った。インフラ事業者を経由した間接被害の典型例として、業界内で広く共有されている。
企業への影響
売上損失・機会損失
ECサイトや予約システムを運営する企業にとって、サービス停止は直接的な売上損失に直結する。特に繁忙期・キャンペーン期間中の攻撃は損失額が大きく、数時間の停止でも数千万円〜億円規模のインパクトが生じるケースがある。また、攻撃中にアクセスできなかったユーザーが競合他社に流れ、継続的な顧客離れを招くことも見落とされがちな影響である。
ブランド・信頼性の失墜
金融機関・医療機関・公共サービスでは、サービス停止そのものが深刻な信頼失墜につながる。特に報道で取り上げられた場合、「あの会社はサイバー攻撃に弱い」という印象が固定化されやすい。株式上場企業では株価への影響も無視できない。
復旧・対応費用
攻撃を受けた後の復旧作業には、ITエンジニアの緊急対応コスト・外部セキュリティベンダーの調査費用・システム増強費用・ログ解析費用などが発生する。大規模インシデントでは、復旧のための費用だけで数百万〜数千万円に達することも珍しくない。
法的・規制対応コスト
金融業・通信業・医療業では、主管省庁へのインシデント報告義務が法定されている。報告書の作成・対外説明・再発防止策の提出といった規制対応にも相当のリソースが必要であり、担当部門の通常業務が長期間にわたって圧迫される。
二次攻撃のカモフラージュとして悪用
DDoS攻撃は、セキュリティ担当者の注意をそらしている間に別の攻撃（不正アクセス・マルウェア設置・データ窃取）を行うためのカモフラージュとして使われることがある。ログが大量に生成されて解析が困難になることも悪用される要因の一つである。
防御策
CDN（コンテンツデリバリーネットワーク）の活用
CDNは世界中に分散したエッジサーバーを通じてコンテンツを配信する仕組みであり、DDoS防御においても有効な手段である。攻撃トラフィックはオリジンサーバーではなくCDNエッジに到達するため、大量の攻撃でも吸収・分散できる。
CDNをDDoS対策として活用する際のポイントは以下のとおり。
- IPアドレスの隠蔽：オリジンサーバーのIPを公開しないことで、CDNを迂回した直接攻撃を防ぐ
- キャッシュの最大化：静的コンテンツをエッジでキャッシュすることで、オリジンへの負荷を最小化する
- リアルタイムトラフィック分析：CDN事業者のDDoS緩和機能（CloudflareのUnder Attack Mode等）を有効活用する
- 帯域吸収能力の確認：CDN事業者全体のネットワーク容量がTbpsクラスであることを確認する
主要サービス：Cloudflare Magic Transit、AWS CloudFront + Shield、Akamai Prolexic など
WAF（Webアプリケーションファイアウォール）
WAFはL7（アプリケーション層）で動作し、HTTPリクエストの内容を解析して悪意ある通信をブロックする。DDoS対策においては、特にアプリケーション層型のHTTPフラッド・Slowloris対策として有効である。
WAFによるDDoS防御の具体的な機能を以下に示す。
- レートリミット：単一IPや特定のUser-Agentからの過剰なリクエストをスロットリング・ブロックする
- ボット検知：人間のブラウザとBotの違いをJavaScriptチャレンジ・CAPTCHA・ヘッダー解析で識別する
- 地理情報フィルタリング：攻撃元が特定の国・地域に集中している場合にジオブロッキングを適用する
- シグネチャマッチング：既知のDDoSツール（LOIC、HOIC等）の特徴を持つリクエストをブロックする
WAFは正規ユーザーへの誤検知（False Positive）がゼロになることはなく、ルールチューニングが継続的に必要であることに注意が必要である。
専用DDoS緩和サービス（スクラビングセンター）
ISP・専門ベンダーが提供するDDoS緩和サービスは、大規模攻撃に対して最も確実な防御効果を発揮する。攻撃トラフィックをスクラビングセンター（洗浄施設）へ誘導し、悪意ある通信を除去した後に正規トラフィックだけを自社に戻す仕組みである。
代表的な提供形態は以下のとおり。
- 常時型（always-on）：通常時から通信をスクラビングセンター経由にルーティングする。発動までの遅延がなく、高いサービスレベルが求められる金融機関等に適している
- オンデマンド型：攻撃検知後にルーティングを切り替えてスクラビングを開始する。コストは常時型より低いが、切り替えまでの数分〜十数分間は無防備になる
- クラウド型ハイブリッド：CDN・WAFとスクラビングを組み合わせ、攻撃規模に応じて自動でエスカレーションする構成
国内・国際のサービス例：NTTコミュニケーションズ、IIJ、Cloudflare Magic Transit、Akamai Prolexic、Radware Cloud DDoS Protection
帯域設計とネットワーク冗長化
スクラビングサービスなどの外部防御を利用する場合でも、自社ネットワークの設計が重要である。
- 上流帯域の余裕確保：通常時のトラフィックに対して最低でも3〜5倍の帯域マージンを持つことが推奨される。帯域がすぐに飽和すると防御サービスへの切り替え時間すら確保できなくなる
- 複数ISPによる回線冗長化：単一ISPへの依存を排除し、攻撃・障害時に別経路へ切り替えられる構成にする
- Anycastルーティング：同じIPアドレスを複数拠点でアドバタイズし、攻撃トラフィックを自動的に分散させる手法（主にDNS・CDN事業者が活用）
ファイアウォール・ACLによる基本設定
大規模な専用サービスを導入する前提として、ネットワーク機器の基本設定で防御できる事項は徹底する必要がある。
- 不要なポート・プロトコルの閉鎖：使用していないUDPポートを全閉し、反射・増幅攻撃の踏み台となるリスクを排除する
- SYN Cookie有効化：OSレベルでSYN Cookieを有効にし、SYNフラッドによる半開セッション枯渇を軽減する
- ブラックホールルーティング（RTBH）：BGPを使い攻撃対象となっているIPアドレス宛の通信をルーター上で廃棄する手法（サービスも落ちるが周辺への影響を遮断できる）
- レートリミット設定：ICMPレート制限・コネクションレート制限をファイアウォール・ルーターで設定する
攻撃発生時の対応手順
DDoS攻撃が発生した際に、組織として取るべき行動を段階別に示す。事前にこの手順をインシデント対応計画書（IRP）として文書化し、関係者に周知しておくことが不可欠である。
ステップ1：検知と初期確認（0〜15分）
異常の検知
- ネットワーク監視ツール（SNMP・NetFlow解析・クラウドプロバイダーのメトリクス）でトラフィック急増を確認する
- ユーザー・顧客からの「つながらない」報告・問い合わせの急増も初期検知のシグナルとなる
DoS攻撃か否かの判断 以下を確認して、DDoS攻撃によるサービス停止か、通常の障害かを切り分ける。
- 上流ルーター・スイッチのトラフィック量が急増しているか
- ログに大量の特定パターン（同一ポートへのSYN・特定User-Agentのリクエスト等）が含まれているか
- ISPから攻撃通知が届いていないか
エスカレーションと関係者への連絡
- セキュリティ担当者・IT責任者への即時報告
- サービス状態を社内・ユーザー向けに公式に通知できる体制を整える
ステップ2：初動対応（15分〜1時間）
攻撃種別の特定 パケットキャプチャ・フローログ・WAFログを分析し、以下を特定する。
- 攻撃種別（ボリューム型・プロトコル型・L7型）
- 主な発信元IP・ASN・地域の分布
- 標的となっているIPアドレス・ポート・URL
即時的な緩和措置
- 攻撃元IPレンジのACL適用（発信元が偽装されていないケースに有効）
- ジオブロッキング（攻撃元地域が特定できている場合）
- レートリミットの強化
- CDN・WAFのDDoS緩和モードの有効化（Cloudflare Under Attack Mode等）
DDoS緩和サービスへの切り替え
- 契約済みのスクラビングサービスへ緊急連絡し、トラフィックの誘導を依頼する
- BGPによるルーティング変更に要する時間（数分〜十数分）を考慮した上で判断する
ステップ3：攻撃継続中の対応（1時間〜攻撃終了まで）
- サービス状況のモニタリング継続：緩和措置の効果を定期的に確認し、有効でなければ対応を切り替える
- ステークホルダーへの定期報告：経営層・事業部門・カスタマーサポートへの状況報告を定期的に行う
- ログの保全：攻撃のログは後の分析・報告・場合によっては法的手続きのために保全する
- 二次攻撃の監視：DDoSをカモフラージュとした不正アクセス・データ窃取が並行して行われていないか確認する
ステップ4：攻撃収束後の対応
- 根本原因分析（RCA）の実施：攻撃がどのように到達したか、どの防御レイヤーが機能したか・しなかったかを分析する
- タイムラインの記録：検知から復旧までの経緯を詳細に文書化する
- 規制当局への報告：金融機関・医療機関・通信事業者は、主管省庁への報告義務を確認し期限内に報告する
- 再発防止策の実装：分析結果に基づき、ネットワーク設定・防御サービスの設定を見直す
- DRPおよびIRPの更新：実際の攻撃で明らかになった課題を、ディザスタリカバリープラン・インシデント対応計画書に反映する
AEVUSのDDoS対策支援
DDoS攻撃は、攻撃の多様化・大規模化が進み、一般的な国内回線や標準的なファイアウォールだけで対応することがほぼ不可能になっている。防御には、自社のネットワーク構成・サービスの重要度・予算に応じた適切な対策の組み合わせが必要である。
AEVUSでは、DDoS攻撃を含むネットワーク脅威への対策として、以下の支援を提供している。
脆弱性診断・ペネトレーションテスト DDoS攻撃の踏み台となるリスク（オープンリゾルバ設定・増幅攻撃に悪用されやすいサービス設定）や、DDoSを囮とした二次攻撃経路を事前に特定する診断を実施する。実際の攻撃シナリオに基づいた検証により、見落としがちな弱点を洗い出す。
インシデント対応計画書の策定支援 DDoS攻撃発生時に組織として迷わず動けるよう、検知・初動・エスカレーション・復旧・報告の各フェーズを網羅したインシデント対応計画書の策定を支援する。
DDoS対策アーキテクチャのレビュー 現在のネットワーク構成・CDN・WAF・スクラビングサービスの組み合わせが、想定される攻撃シナリオに対して十分な防御力を持っているかを第三者視点で評価する。
DDoS攻撃への対策状況に不安がある場合、または現在の防御構成の妥当性を確認したい場合は、AEVUSへの問い合わせを検討してほしい。
まとめ
DDoS攻撃は、その規模・手法・目的において急速に進化しており、2026年現在も企業・公共機関にとって最も現実的なサイバー脅威の一つである。
本記事のポイントを以下に整理する。
- DDoS攻撃は単一発信元のDoS攻撃と異なり、ボットネットを使った分散攻撃であるため単純なIPブロックが通用しない
- 攻撃はボリューム型（帯域飽和）・プロトコル型（リソース枯渇）・アプリケーション層型（正規通信に偽装）の3カテゴリに分類され、それぞれ有効な防御策が異なる
- 2026年の国内被害は金融・EC・公共機関にわたり、特に繁忙期・政治的なタイミングを狙った攻撃が増加している
- 防御の基本はCDN・WAF・専用スクラビングサービスの組み合わせであり、攻撃規模に応じて段階的にエスカレーションできる構成が望ましい
- 攻撃発生時の初動15分間の行動が被害の大小を左右するため、インシデント対応計画書の事前策定と関係者への周知が不可欠である
DDoS攻撃への備えは、特定製品の導入だけで完結するものではなく、ネットワーク設計・運用体制・インシデント対応計画の三つが揃って初めて機能する。定期的な見直しと実効性の検証が、企業のサービス継続性を守る上で重要な投資となる。
