トラフィックが突然急増し、ページがぐるぐるし、APIがタイムアウトする——これらの症状は成功したキャンペーンの可能性もあればDDoSの可能性もあります。違いは重要です。なぜなら誤った予算を使うかどうかを決めるからです。攻撃をスケーリング問題とみなせば買った帯域幅は一瞬で吹き飛び、ピークを攻撃とみなせば本物のユーザーをブロックしコンバージョンを損ないます。ここに実践的な3軸診断があります。
軸1：トラフィックの発信元——送信元の分散
これが最も手っ取り早い切り口です。
- 通常トラフィック：実際のユーザー層に集中——同じ地域、同じネットワーク（ASN）、同じ活躍時間帯です。接続テーブルやフローデータを引けばIP分布は「見覚えのある顔ぶれ」です。
- DDoSトラフィック：数千の見知らぬネットブロックから来て、多くの国と奇妙なASNにまたがることがよくあります。少数のIPが高頻度で叩くのは分散攻撃よりもスクレイパーや単一の悪用者の可能性が高いです。
直感的な目安：『リクエスト量が急増』と『送信元IPの分散』が同時に起きれば、それはほぼ確実に人間ではありません。
軸2：トラフィックの形状——プロトコルとパケットの特徴
通常のビジネストラフィックは大半がHTTP/HTTPSで、プロトコル混合は滑らかです。以下の形状に注意してください：
- 大量のUDP / ICMP：WebサービスなのにUDPやICMPで溺れている——典型的な容量型または反射・増幅（NTP・DNS・SSDP・Memcachedなどの開放サービスが悪用されトラフィックを50倍以上に増幅）。
- SYN / ACKの不均衡：帯域幅は満杯でないのにSYN_RECVが積み上がり接続テーブルが枯渇——プロトコル攻撃です。ファイアウォールとロードバランサーが最初に倒れます。
- 「完全に正常に見える」リクエスト：すべて有効なGET/POSTなのに、1つの高負荷端点（検索・ログイン・CAPTCHA）を連打——アプリケーション層のCCで、トラフィック形状だけではほぼ見えず、コスト異常と挙動ルールでのみ捕捉されます。
軸3：ビジネスへの影響——相関
この軸がどの程度心配すべきかを決めます。以下の表と比較してください：
| 指標 | 通常の変動 | 疑わしい攻撃 |
|---|---|---|
| リクエスト量 | キャンペーンに紐づき説明可能 | 説明のつかない10倍以上の急増 |
| エラー率 | 低く安定 | 5xx / タイムアウトが急増 |
| 送信元IP | 実際のユーザー層 | 膨大な見知らぬネットブロック |
| 接続数 | ユーザー規模に一致 | 接続テーブルが限界 |
| 注文 / リクエスト | 通常の比率を維持 | リクエスト増・コンバージョン横ばい |
要点：『リクエスト急増』に『エラー増・送信元分散・コンバージョン比率低下』が伴えば、それはピークではなく攻撃です。
3つの攻撃クラス、見分け方
- 容量型：帯域幅が飽和、出口が天井近く。UDP / 反射増幅。単一の出口では吸収しきれない——最も目に付き、最も苛烈です。
- プロトコル型：帯域幅は大丈夫でも接続・セッションテーブルやファイアウォール状態がSYN / ACKフラッドで枯渇。サーバーが『オフラインではないがまったく応答しない』のはたいていこれです。
- アプリケーション層（CC）：トラフィックは正常に見えるが容赦なくデータベース・ログイン・検索を焼く。すべてのリクエストが正当なため一目で見つけるのが最も難しく、『コスト異常』と挙動ルールだけが捕捉します。
60秒で確認するチェックリスト
- 『送信元分散＋エラー増＋飽和した帯域幅または接続数』が同時に見えるか？
- 同時に、通常のユーザーが（単に遅いのではなく）完全に到達不能になっているか？
- 単一IPのレートを制限した後、全体の圧力が顕著に下がるか？（はいなら単一悪用の可能性、いいえなら分散の可能性が高い。）
- プロトコル混合に、自社の業務タイプに合わない大量のUDP / SYNが見えるか？
最初の3つに当てはまれば、基本的にそれをDDoSまたはCC攻撃と呼んでよいでしょう。確認できたら、サイトがDDoS攻撃を受けたらどうするか（15分対応プラン）へ進んでください。
なぜ「1分早く」確認するのか
確認を1分早め、洗浄の導入を1分早め、失うのは1分少なく。多くのチームは「コードが壊れたのか？」のデバッグで足止めされ、30分後にやっと攻撃だと気づきます——そしてその30分の注文とプレイヤーは戻りません。まだ防護を評価中なら、無料・自前・プロのDDoS対策——どれを選ぶべきかをご覧いただくか、無料の予備評価についてお問い合わせください。