過剰リクエストを止める層の設計 — 手前で弾くかアプリで絞るか

過剰リクエストへの対処設計において最も多い失敗は、すべての判断をアプリケーション層に集中させることです。前段の防御が機能していなければ、不正なトラフィックも正規リクエストも同じ経路でバックエンドリソースを消費し続けます。どの層でどの種類の通信を止めるかを事前に決め、それぞれの役割を分離することが流量制御設計の核心です。本稿では、DDoS防御・前段WAF/CDN・アプリ側レート制限の役割分担と、閾値・除外設計・過剰遮断の境界判断を整理します。

すべてアプリまで届いてから落ちる構造

バックエンドへ到達するまでの処理コスト

リクエストがアプリケーションサーバーに届いてから拒否される場合、そのリクエストはTCPコネクション確立・TLS終端・HTTPパース・ロードバランサー転送・アプリプロセスのスレッド割り当てというすべての工程を消化しています。攻撃者が毎秒1,000リクエストを送り続ける状況で前段に防御が存在しない場合、アプリケーション側で429を返す処理だけでバックエンドリソースの30〜40%が消費されることも珍しくありません。その消費は正規ユーザーへの応答遅延として直接現れます。

前段防御が存在しない現場で起きること

前段に何も置かず、アプリのミドルウェアだけでレート制限を実装している構成では、急激なスパイクに対してアプリプロセスが枯渇してから初めて問題が顕在化します。アプリが落ちた後でログを遡ると、問題の発端は通常のビジネスアワーに正規外リクエストが増え始めており、その段階で対処できていれば障害を防げた、という流れが見えてきます。現場では、アプリサーバー5台構成の環境が特定APIへの集中アクセスにより全台CPU 100%になり、前段に何もなかったため復旧まで25分かかったという話がよく出てきます。

アーキテクチャの可視化が判断の前提になる理由

流量制御の設計判断を下す前に、自システムでリクエストが通過する全層を図示することが不可欠です。リクエストがどの経路を通り、どの層で処理を行い、どこにコストが乗るかを整理すると、「どこで弾いても同コスト」なのか「前段で弾くほど安い」のかが初めて判断できます。図式化されていない構成では、設計者ごとに「どこで制限しているか」の認識がずれ、結果として二重に制限が入る箇所と、まったく制限されない抜け穴が並存します。

前段で弾く通信とアプリ側で判断すべき通信の切り分け

前段で確実に対処できるもの

IPベースの単純な大量送信、既知の攻撃ツールのUser-Agent、地理的に自サービスと無関係なリージョンからの一括アクセス、HTTPメソッドの不正な組み合わせなどは、アプリケーションロジックを一切参照しなくても判断できます。これらはWAFやCDNエッジで処理するコストがアプリ到達コストよりはるかに低く、前段に寄せるほどシステム全体の保護効率が上がります。前段処理に適しているのは「リクエストの内容を問わず、送信元や形式だけで判断できるもの」という基準で整理できます。

アプリ側でなければ判断できないもの

ログイン済みユーザーの1時間あたりのAPI呼び出し回数、サブスクリプションプランに紐づいたレート上限、課金単位ごとのクォータ管理など、ビジネスロジックに依存する制限はアプリケーション層でなければ判断できません。これらをWAFに実装しようとすると、認証情報・プランデータ・ユーザー状態をWAFが把握する必要が生じ、設計の複雑度が急激に上がります。判断に必要なコンテキストがどこに存在するかで、実装すべき層が決まります。

切り分けの判断軸を整理する

「送信元・形式・プロトコルで判断できるか」「認証・アカウント情報・ビジネスルールが必要か」という2軸で分類すると、前段とアプリの役割が明確になります。グレーゾーンになりやすいのは、JWTやAPIキーを前段が検証する設計です。この場合、形式的な正当性（署名が有効かどうか）は前段で確認できますが、「このAPIキーの持ち主は今月のクォータを超えているか」はアプリ側のデータストアを参照しなければ判断できません。前段に持たせる責任を形式検証に限定することが、安定した設計につながります。

比較表: 事業者のDDoS防御/前段WAF・CDN/アプリ側レート制限の比較

各層の強みと引き受けられない責任

事業者レベルのDDoS防御は、帯域レベルで自環境に到達する前に流量を吸収します。一方、HTTP GET/POSTを装った巧妙なL7攻撃には実質的に無力です。前段WAFはL7レベルの通信内容を検査しますが、「このユーザーは何回呼んだか」という状態管理は苦手な領域です。アプリ側レート制限はビジネスルールに従った柔軟な制御が可能な一方、リクエストがアプリに到達してから判断するため、攻撃トラフィックが多いほどコスト効率が悪化します。各層はそれぞれ引き受けられない責任を持っており、単一層への集中は設計上の弱点になります。

層	主な対象トラフィック	制御の粒度	判断材料	主な限界
事業者DDoS防御（L3/L4）	帯域飽和・SYNフラッド・大規模volumetric攻撃	IPブロック・接続数上限	送信元IP・プロトコル・パケット特性	L7アプリ層攻撃には無効・ユーザー設定の自由度低
前段WAF・CDN（L7）	既知攻撃パターン・単純大量リクエスト・ボット	IP・パス・メソッド・UA・レート	リクエストヘッダ・送信元・ルールセット	ビジネスロジック不知・誤検知調整コスト
アプリ側レート制限（L7＋ビジネス）	アカウント・APIキーごとのクォータ超過	ユーザー・プラン・エンドポイント単位	認証情報・DB・キャッシュ・セッション	アプリ到達後に判定・高トラフィック時のDB負荷増

組み合わせ設計の基本的な考え方

3層を組み合わせる設計では、各層の責任範囲を明示し、重複しても問題ない箇所と責任の空白が生じる箇所を意識的に確認します。事業者DDoS防御→前段WAF/CDN→アプリ側制限の順に、粗い網から細かい網を重ねる構造が基本です。前段WAFでIPあたり毎分200リクエストを制限しつつ、アプリでアカウントあたり毎時500リクエストを制限する設計は矛盾しません。重要なのは「どの層で何を責任として持つか」が関係者に共有されており、運用フェーズでの変更時に意図せず別層の責任まで変えてしまわないよう管理することです。

制限の単位(IP・アカウント・APIキー)と閾値の決め方

粒度の選択が制限の精度を決める

IPベースの制限は実装が簡単ですが、NAT環境や企業ネットワークでは数百人が単一IPを共有するケースも珍しくありません。その環境で厳しいIP制限をかけると、1人の過剰利用が同一IP配下の全員に影響します。アカウント単位やAPIキー単位での制限は粒度が細かく正確ですが、アプリケーション側で認証情報を処理した後でなければ判断できないため、前段では実施できません。対象サービスの利用者属性（個人か・企業NATか・パートナーAPIか）によって、どの粒度を主軸にするかが変わります。

閾値を設定するための参照材料

閾値を感覚で決める構成は、運用開始後に正規ユーザーへの影響が出てから初めて問題に気づくことが多いです。適切な閾値を設計するには、サービス本番ログから計測した「正規利用の95パーセンタイル値」を基準にするアプローチが有効です。例えば、APIログを2週間分集計した結果、正規ユーザーの95%が1時間あたり150リクエスト以下であれば、初期閾値の目安は200〜250リクエスト程度に設定し、稼働データを見ながら調整する手順が現実的です。閾値は決め打ちではなく、観測→調整のサイクルを前提に設計します。

段階的な応答設計

制限に達した瞬間に即遮断するのではなく、段階的な応答を設計する選択肢があります。警告ヘッダ（Retry-Afterや残クォータ通知）→スロットリング（応答速度の意図的な低下）→ハード遮断（429返却）という段階を踏むと、正規ユーザーがクライアント側でリトライ制御を実装しやすくなります。APIを提供するサービスでは段階的応答を設計することでクライアント側の実装品質も改善されるため、過剰リクエストそのものが減る効果も見込めます。スロットリングの実装難易度は遮断よりも高くなりますが、設計上の選択肢として初期段階から検討する価値があります。

正規利用を巻き込まないための除外設計

除外対象の洗い出し方

除外設計で最初にすべき作業は、「どのような通信を絶対に止めてはいけないか」を業務視点で列挙することです。社内監視ツールのヘルスチェック、パートナーシステムとの定時バッチ通信、決済ゲートウェイからのコールバック、CDNのオリジン確認リクエストなどは、流量としては少量でも止まると業務が止まります。これらを事前にリストアップし、除外の根拠と担当者を記録した設計書を持たずに制限を入れると、運用フェーズで「なぜこのIPが除外されているか誰も知らない」という状況に行き着きます。

ホワイトリスト管理の落とし穴

除外対象をIPホワイトリストで管理する設計はシンプルですが、担当者交代・システム移行・クラウドの動的IP変更のたびにリストが腐敗していきます。半年後に確認すると、リストの20〜30%が既に使われていないIPになっているという状況は珍しくありません。ホワイトリストには必ず有効期限と管理者を付与し、定期的なレビューを運用手順に組み込む設計を最初から意図する必要があります。また、APIキーやトークンベースの除外はキーが漏洩した際に攻撃者に除外ルートを与えるリスクがあるため、除外用クレデンシャルは通常のAPIキーとは別に管理します。

除外設計が形骸化するパターン

除外ルールは「入れたら終わり」と認識されがちですが、サービスの成長やシステム変更に伴い本来の意図から外れていきます。例えば、開発・検証環境のIPを本番WAFの除外に含めたまま、その環境を外部に貸し出した場合、意図せず制限を迂回できる経路が残ります。除外設計は「何のために除外するか」という理由を起点に、その前提が変わったタイミングで見直せる仕組みが必要です。構築フェーズで設計した除外ルールの棚卸しを、四半期ないし半年ごとの定期レビューとして運用に組み込む判断が重要です。

前段に寄せすぎて正常な業務通信まで落ちる境界

前段の制限を強くしすぎると起きること

前段WAFの感度を高めると、正規の業務通信が誤って遮断されるケースが増えます。大容量のJSONペイロードを送るAPI、ループ状のリクエストが正常なバッチ処理、同一IPから高頻度で動く監視エージェントなどは、攻撃パターンと外見上の特徴が似ているため誤検知の対象になりやすいです。前段の制限を強化した直後に「特定の業務機能が使えなくなった」という問い合わせが来る現場は少なくなく、原因究明にWAFのルール変更ログを掘り起こす工数が発生します。構築を任されたある担当者が導入直後に全社向けAPIを止めてしまい、ルール変更の履歴を追うだけで半日かかったという事例もあります。

ビジネスロジックを前段に持ち込まない

前段WAFに「この経路は認証済みユーザーだから制限を緩める」という判断を持たせようとすると、設計の複雑度が跳ね上がります。WAFがJWTを検証してユーザー種別を判断するためには、署名検証・クレーム解析・外部データ参照など、アプリケーションが本来担う処理を前段に移植する必要が生じます。これは「前段でできる判断」の範囲を超えており、いざ問題が起きたときの調査コストが高くなります。前段はあくまで形式的判断の層として機能させ、意味的・ビジネス的判断はアプリ層に残すという原則が、長期的な保守性を担保します。

運用フェーズで境界がずれていく原因

構築時点では明確だった「前段の責任範囲」が、運用フェーズで少しずつ崩れていくパターンがあります。急ぎの対応でWAFに暫定ルールを追加し続けた結果、半年後には100件以上の個別ルールが積み上がり、どのルールが何のために存在するかを把握している人がいなくなる状況です。流量制御の設計書とWAFルールの実体を定期的に突き合わせ、意図せず追加されたルールを削除または正式化するプロセスを設けることが、境界の維持につながります。

流量制御設計チェックフレーム

以下のチェック項目を設計フェーズと定期レビュー時に活用することで、流量制御設計の主要な抜けを検出できます。構築フェーズで一度確認するだけでなく、システム変更・担当者交代・スケールアップのタイミングで再確認することが重要です。

• 自システムのリクエスト経路（DNS→CDN→LB→アプリ→DB）を図示し、各層のコスト構造を把握しているか
• 前段で弾く通信（形式・送信元判断）とアプリで弾く通信（ビジネスロジック判断）を分類し、文書として残しているか
• 制限の粒度（IP・アカウント・APIキー・エンドポイント）を利用者属性に基づいて選択しているか
• 閾値を感覚ではなく本番ログの計測値（95パーセンタイル値など）から設定しているか
• 段階的な制限応答（警告ヘッダ→スロットリング→遮断）を設計しているか、または即遮断の理由を明示しているか
• 除外対象（監視エージェント・バッチ通信・決済コールバック・CDNオリジン確認）をリストアップし、有効期限と管理者を紐づけているか
• ホワイトリストの定期棚卸し手順を運用フローに組み込んでいるか
• 前段WAFにビジネスロジック依存の判断を持たせていないか
• 除外用クレデンシャルを通常のAPIキーと分離して管理しているか
• 制限強化後に正規の業務通信（監視・バッチ・パートナー連携）への影響がないか確認する手順が存在するか
• WAFルールと設計書の突き合わせを四半期または半年ごとの定期レビューのスコープに含めているか