メインコンテンツまでスキップ

6大WAF総合比較 2026

先に結論​

「クラウドネイティブWAFは、最低限のシグネチャを置いただけの付属機能である」という認識は、2026年時点では古い。

AWS WAF、Google Cloud Armor、Azure Web Application Firewallはいずれも、一般的なWebアプリケーションとAPIを守るための実用水準へ達している。マネージドルール、レート制限、Bot判定、Challenge、L7 DDoS対策、ログ、IaCを組み合わせれば、単一クラウド内の多くのシステムはネイティブWAFだけで守れるようになったのだ。

ただし、Akamai、Cloudflare、Impervaが不要になったわけではない。専業3社は、次の領域で依然として明確な差を持つ。

  • 複数クラウドとオンプレミスを一つの防御基盤へ載せる
  • 高度なBot、スクレイピング、買い占め、カードテスト、アカウント乗っ取りを扱う
  • APIを発見し、スキーマや振る舞いから異常を捉える
  • L3・L4からL7までのDDoS防御と専門家対応をまとめる
  • クライアント側JavaScriptや、アプリケーション背後のデータまで保護する
  • ベンダーのSOC、SOCC、アナリストへ運用を寄せる

したがって、6製品を一列に並べて「1位だけ買う」と考えると判断を誤る。

本レポートの結論は、次のように分かれる。

判断軸第一候補理由
AWS内の標準WAFAWS WAFAWSサービスとの統合、ラベル、ルールバージョン管理、IaCが強い
Google Cloud内の標準WAFGoogle Cloud ArmorAdaptive Protection、レート制限、reCAPTCHA連携が強い
Azure内の標準WAFAzure Front Door WAFグローバルエッジ、DRS、Bot Manager、Azure統合をまとめやすい
防御性能と専門家支援を最優先AkamaiWAF、Prolexic、Bot Manager、Account Protector、SOCCの総合力が高い
運用性とプラットフォーム統合を最優先Cloudflareルールエンジン、API、Terraform、DDoS、Bot、API Shieldを扱いやすい
WAF専業性とデータ保護を重視ImpervaWAF、Bot、API、クライアント側、データセキュリティをつなげやすい

技術能力だけを総合すると、Akamaiがわずかに先頭で、Cloudflareがほぼ並び、Impervaが続く。日常の変更速度、セルフサービス、自動化、人材の見つけやすさまで含めると、Cloudflareが最も現実的な第一候補になりやすい。

クラウドネイティブ3製品では、AWS WAFの完成度が最も高い。Google Cloud Armorは純粋なシグネチャ型WAFとして見るより、Adaptive ProtectionとreCAPTCHAを含む防御系として評価すべきである。Azure WAFは実用水準へ達したが、Front Door版とApplication Gateway版の差、プレビュー機能、ルールセット更新時の扱いが選定を難しくしている。

短くまとめると、次なのだ。

  • 最も強い企業向け境界防御: Akamai
  • 最も扱いやすい統合エッジ: Cloudflare
  • 最もWAF専業らしい防御とデータ連携: Imperva
  • 最も完成したクラウドネイティブWAF: AWS WAF
  • 最も適応型DDoS防御へ寄ったネイティブWAF: Google Cloud Armor
  • Azure標準として十分だが、構成差を理解する必要があるWAF: Azure WAF

この比較で何を評価するのか​

6製品は同じ範囲の製品ではない​

AWS WAF、Cloud Armor、Azure WAFは、クラウドのロードバランサー、CDN、API公開機能へ密接に組み込まれる制御面である。

Akamai、Cloudflare、Impervaは、WAFだけでなく、CDN、DDoS、Bot、API、クライアント側保護、ネットワーク防御、マネージドサービスを組み合わせるWAAPまたはアプリケーション保護プラットフォームである。

そこで本レポートでは、単体製品名だけでなく、現実に組み合わせて使う隣接機能も次の範囲で評価する。

製品群評価に含める主な機能
AWSAWS WAF、AWS Managed Rules、Bot Control、Fraud Control、Anti-DDoS managed rule group、Shieldとの役割分担
Google CloudCloud Armor、Adaptive Protection、Cloud Armor Enterprise、reCAPTCHA連携
AzureFront Door WAF、Application Gateway WAF、DRS、Bot Manager、JavaScript Challenge、Azure DDoSとの役割分担
AkamaiApp & API Protector、Bot Manager Premier、Account Protector、API Security、Prolexic、Client-Side Protection
CloudflareWAF、DDoS Protection、Bot Management、Turnstile、API Shield、Page Shield、Magic Transit
ImpervaCloud WAF、WAF Gateway、Advanced Bot Protection、Account Takeover Protection、API Security、DDoS、Client-Side Protection、Data Security

クラウド側のAPI管理製品、たとえばAmazon API Gateway、Apigee、Azure API Managementは、WAFと併用できる。しかし、それ自体をWAFの標準機能として点数へ足してはいない。そうしないと、比較が「各クラウドで追加購入できる全サービス」と「専業WAAP製品」の競争になってしまうからだ。

評価軸​

評価軸は次の11項目とした。

  1. WAF基本防御
  2. 誤検知調整とルール更新
  3. L7 DDoS
  4. L3・L4 DDoS
  5. Bot、不正利用、アカウント保護
  6. APIセキュリティ
  7. クライアント側・データ保護
  8. ログ、API、IaC、運用性
  9. サポートとマネージドサービス
  10. 価格の柔軟性と予測可能性
  11. マルチクラウド、オンプレミス、複数CDNへの展開性

5点満点のスコアは、公開仕様、設定の粒度、適用範囲、独立検証、利用者評価をまとめた本レポート独自の相対評価である。検知率を実測した数字ではない。0.1点の差に統計的な意味はなく、製品選定の出発点として読むものなのだ。

情報源の扱い​

情報は、次の順で重み付けした。

  1. 各社の技術ドキュメント、料金表、リリースノート
  2. 独立試験、査読前を含む技術論文、標準プロジェクト
  3. Gartner Peer InsightsやPeerSpotなどの利用者レビュー
  4. Reddit、Hacker Newsなどの断片的な運用経験
  5. ベンダーの製品ページ、事例、比較広告

公式情報は「その機能が存在するか」を確認するには強いが、実際の誤検知率や運用負荷を証明しない。掲示板は現場の摩擦を知るには便利だが、契約プラン、設定、製品バージョン、利用者の力量が分からない。両者を混ぜず、同じ傾向が複数の情報源で繰り返されるかを見るのだ。

2026年のWAF市場は、もうWAFだけを売っていない​

シグネチャ型WAFからWAAPへ​

従来のWAFは、SQLインジェクション、クロスサイトスクリプティング、LFI、RFI、コマンドインジェクションなど、HTTPリクエスト中の攻撃文字列を検出する製品として理解されていた。

現在の選定では、それだけでは足りない。

実際のインターネット公開システムで問題になるのは、次のような通信である。

  • 正しい認証画面へ大量の漏えい認証情報を試す
  • 正常な商品検索APIを高速に回して価格を収集する
  • 正しい購入APIを使って限定商品を買い占める
  • 正規のHTTPクライアントで低速なL7 DDoSを行う
  • APIの正しい構文を使い、他人のオブジェクトIDを指定する
  • 正規のJavaScriptへ悪性スクリプトが混入し、ブラウザ側でカード情報を盗む
  • 大量のAIクローラーが、攻撃ではないが費用と性能を食い潰す

このため、製品カテゴリはWAFからWAAPへ広がった。WAF、Bot Management、API Security、DDoS Protectionを一つの観測点で結び、リクエスト単体だけでなく、セッション、端末、アカウント、通常時ベースライン、APIの期待形まで見る方向へ進んでいる。

クラウドネイティブWAFが成熟した​

クラウドネイティブWAFも、この流れを追っている。

AWS WAFは、マネージドルールだけでなく、ラベル、CAPTCHA、Challenge、Bot Control、Fraud Control、L7 Anti-DDoS managed rule groupを持つようになった。2025年には簡略化されたコンソールが一般提供され、2026年2月にはBot Controlの追跡対象が650超のBotとAgentへ広がった。12

Cloud Armorは、事前構成WAFルールだけでなく、トラフィックのベースラインからL7 DDoSを検出して緩和ルールを提案または自動配備するAdaptive Protection、複合キーやJA4を使えるレート制限、reCAPTCHA評価を使うBot管理を備える。345

Azure WAFは、OWASP CRSを基盤にMicrosoft独自ルールを加えたDRS 2.2、Bot Manager 1.1、JavaScript Challenge、Application Gatewayのレート制限、Front DoorのHTTP DDoS rulesetを持つ。ただし、Application GatewayのExceptionsとFront Doorの自動L7 DDoS rulesetは、2026年7月時点でプレビューである。6789

「ネイティブだから最低限」という一括評価は、もはや製品の現状を説明しないのだ。

専業WAAPの差別化は、深さと運用へ移った​

専業3社も止まってはいない。

Akamaiは、Adaptive Security Engine、Bot Manager、Account Protector、API Security、Prolexicを結び、エッジ外や複数CDNへ保護を拡張するApp & API Protector Hybridを提供する。Cloudflareは、WAFのルールエンジンとBot Score、API Shield、DDoS managed rulesets、Magic Transit、Workers、Zero Trustを共通のグローバルネットワークへ載せる。Impervaは、WAF、Advanced Bot Protection、API Security、Client-Side Protectionに加え、データの発見、分類、アクセス監視まで持つ。

差は「SQLインジェクションを止められるか」ではない。

どこまで自動発見できるか、どこまで業務不正を見られるか、複数環境へ同じポリシーを配れるか、攻撃中に誰が調整するかという、深さと運用の差なのだ。

総合評価​

11項目の相対スコア​

評価項目AWS WAFCloud ArmorAzure WAFAkamaiCloudflareImperva
WAF基本防御4.54.24.04.94.64.8
誤検知調整・更新管理4.84.44.14.74.94.5
L7 DDoS4.54.84.15.05.04.8
L3・L4 DDoSを含む総合力4.24.44.15.04.94.7
Bot・不正利用4.54.53.65.04.84.9
APIセキュリティ3.53.53.24.84.94.8
クライアント側・データ保護2.52.32.54.64.75.0
ログ・API・IaC・運用性4.84.54.44.35.03.9
サポート・マネージド運用4.24.14.15.04.04.6
価格の柔軟性・予測性4.03.83.42.64.12.8
マルチクラウド・オンプレ対応2.52.52.54.94.84.9

順位は三つに分ける​

WAF単体の完成度​

  1. Akamai
  2. Imperva
  3. Cloudflare
  4. AWS WAF
  5. Google Cloud Armor
  6. Azure WAF

AkamaiとImpervaは、検知、自己調整、Bot、API、専門家支援まで含めたWAF専業の厚みを持つ。Cloudflareは検知能力も高いが、最大の強みは表現力と運用性である。AWS WAFは専業3社の直後まで来ている。

Google Cloud Armorは、シグネチャ型WAF単体の種類よりも、L7 DDoS、複合レート制限、reCAPTCHAとの結合が強い。Azure WAFはDRS 2.2で改善したが、製品面の一貫性と高度Bot対策で差が残る。

DDoS、Bot、APIまで含む技術総合力​

  1. Akamai
  2. Cloudflare
  3. Imperva
  4. AWS
  5. Google Cloud
  6. Azure

AkamaiはProlexicとSOCC、Bot ManagerとAccount Protector、API Securityを含む重要システム向けの厚みが強い。Cloudflareは500 Tbpsの外部接続容量を公表する巨大ネットワーク、自律的DDoS緩和、Bot Score、API Shieldを共通基盤で扱える。1011

ImpervaはWAFとBot、API、データ保護が強い。AWSとGoogle Cloudは単一クラウドの標準防御としては十分だが、マルチクラウド統制、クライアント側保護、API発見では専業製品に及ばない。Azureは改善中の機能がまだプレビューに残る。

導入、変更、自動化を含む運用実用性​

  1. Cloudflare
  2. AWS WAF
  3. Google Cloud Armor
  4. Azure WAF
  5. Imperva
  6. Akamai

Cloudflareは、管理画面、ルール式、API、Terraform、ログ連携を自社チームで回しやすい。AWS WAFはCloudFormation、CDK、Terraform、Firewall Manager、ログ基盤との統合が強い。Cloud ArmorとAzure WAFもクラウド標準のIaCへ載せやすい。

ImpervaとAkamaiは能力が低いのではない。製品概念、契約モジュール、導入支援、チューニングの専門性が高く、能力を引き出すまでの組織負荷が大きいという意味なのだ。

AWS WAF​

現在の位置付け​

AWS WAFは、6製品の中で専業製品に最も近いクラウドネイティブWAFである。

以前は、文字列一致、正規表現、IP Set、SQLi、XSSの条件を利用者が組み立てる部品という印象が強かった。現在は、AWS Managed Rules、Bot Control、Fraud Control、CAPTCHA、Challenge、ラベル、複合キーのレートベースルール、L7 Anti-DDoS managed rule groupが揃っている。

AWS内の一般的なWebアプリケーション、EC、ログインサイト、APIでは、最初から専業WAFを前提にする必要はない。

強み​

ラベルで検知と遮断を分離できる​

AWS WAFの差別化要素はラベルである。

マネージドルールを直ちにBlockにせずCountで動かし、検知結果へ攻撃種別、Bot分類、トークン状態、DDoS疑いなどのラベルを付けられる。後続ルールでは、そのラベルをURI、国、IP、HTTP属性、別のラベルと組み合わせて、Block、Challenge、CAPTCHA、レート制限を選べる。

これにより、マネージドルールをブラックボックスのまま有効化するのではなく、「検知器」と「意思決定」を分離できる。すべてのAWS Managed Rulesはラベルに対応している。12

マネージドルールの更新管理が強い​

バージョン対応ルールグループは、静的バージョンを固定するか、推奨されるデフォルトバージョンへ追随するかを選べる。新バージョンをCountで検証し、通知と有効期限メトリクスを見ながら切り替えられる。13

専業製品の自動更新より手作業は増えるが、変更管理を厳格に行う組織には説明しやすい。

Botと不正ログイン対策が別モジュールとして育った​

Bot Controlは、既知Bot分類だけでなく、Targeted inspectionで機械学習、トークン再利用、協調活動、セッション挙動を見る。2026年2月には650超のBotとAgentを追跡するAI Activity Dashboardが追加された。2025年11月からはWeb Bot Authenticationを使い、署名された正規Botを暗号学的に検証する方向も入っている。214

Fraud Control ATPはログインエンドポイントを検査し、漏えい認証情報、異常ログイン、IPとセッション単位の不審な試行を扱う。CloudFrontではレスポンスからログイン成功と失敗も追跡できる。15

L7 DDoSがWAF内へ入った​

2025年に提供されたAnti-DDoS managed rule groupは、保護対象ごとの通常トラフィックを学習し、DDoSイベント、攻撃参加が疑われるリクエスト、疑わしさの段階をラベル化する。ChallengeまたはBlockを感度別に適用できる。16

これにより、AWS WAFは固定レート制限だけのL7 DDoS対策から一段進んだ。

ただし、L3・L4、費用保護、DDoS Response TeamなどはShield Advancedの領域である。AWS WAF単体をAkamai ProlexicやCloudflare Magic Transitと同じネットワークDDoS製品として扱ってはいけない。

AWS統合とIaC​

CloudFront、Application Load Balancer、API Gateway、AppSync、Cognito、App Runner、Verified Accessなどへ関連付けられる。2026年6月にはAmazon Bedrock AgentCore Gatewayにも対応した。17

Firewall Managerで組織横断ポリシーを配り、CloudWatch、Firehose、S3、Security Lake、SIEMへログを流し、CloudFormation、CDK、Terraformで構成を管理できる。AWS内で閉じるなら、変更管理と証跡を最も作りやすい製品の一つである。

弱み​

WCU、優先順位、料金が複雑になる​

ルールグループ、個別ルール、ラベル依存、Scope-down statement、WCU、追加課金対象を組み合わせると、設計は急に難しくなる。

基本料金はWeb ACL数、ルール数、リクエスト数で増える。Bot Control、Fraud Control、CAPTCHA、Challenge、追加ボディ検査、Marketplaceルールは別の費用要因になる。公式料金表は透明だが、高トラフィック環境の請求額が直感的とは限らない。18

ボディ検査には統合先ごとの上限がある​

Application Load BalancerとAppSyncは8 KB固定である。CloudFront、API Gateway、Cognito、App Runner、Verified Accessなどは16 KBが既定で、追加料金を伴い最大64 KBまで拡張できる。gRPCのリクエストボディ検査は対応しない。19

大きなJSON、GraphQL、multipart、ファイルアップロードを扱う場合、WAFが「何を見ていないか」をPoCで確認する必要がある。

高度なAPIセキュリティは別物である​

API GatewayへWAFを付け、JSON body、レート制限、Bot、認証前後の制御はできる。しかし、API Discovery、OpenAPIスキーマ学習、シャドーAPI、ゾンビAPI、BOLAなどの業務ロジック分析は、AWS WAFの中心機能ではない。

向いている環境​

  • AWS上のWebアプリケーションとAPI
  • CloudFrontまたはALBを標準入口にしている
  • IaC、アカウント分離、組織ポリシーを重視する
  • CountからBlockへ段階移行できる
  • ログ分析とチューニングを自社で行える
  • ログイン、会員登録、Botの課題をAWS内で解決したい

向いていない環境​

  • 複数クラウドとオンプレミスを一つの画面で統制したい
  • 高度な買い占め、スクレイピング、業務不正が主要課題である
  • API Discoveryと業務ロジック分析をWAF製品へ求める
  • ベンダーの専門家へ24時間のチューニングを任せたい

判定​

AWS内では第一候補でよい。

専業WAAPを前段へ置く場合でも、AWS WAFを完全に外すのではなく、CloudFrontやALBに近い第二層として残す構成はあり得る。ただし二重WAFは、同じシグネチャを二回動かすためではなく、外側を企業共通Bot・DDoS・API防御、内側をAWS固有の制御とログへ分けるのだ。

Google Cloud Armor​

現在の位置付け​

Google Cloud Armorは、純粋なWAFルールカタログではAWS WAFより地味に見える。

しかし、Googleのグローバルロードバランサー、Adaptive Protection、複合レート制限、reCAPTCHAを一体で見ると評価が変わる。Cloud Armorは、WAFというより、アプリケーション前段の適応型トラフィック防御として完成度が高い。

強み​

Adaptive Protection​

Adaptive Protectionは、通常時のトラフィックを基準にモデルを構築し、L7 DDoSや異常トラフィックを検出する。攻撃の特徴を表すWAFルールを提案し、evaluateAdaptiveProtectionAutoDeploy()を使って自動配備することもできる。3

静的なIPリストや固定しきい値では捉えにくいHTTP Floodに対し、アプリケーション固有の通常状態から外れた通信を見る点が強い。

自動配備は便利だが、正規の急増、イベント、販売開始、バッチ、モバイルアプリ更新を攻撃と誤る可能性がある。重要な正常トラフィックを上位Allowへ置き、信頼度、影響を受けるベースライン、適用期限を設計する必要がある。

レート制限のキーが豊富である​

IP、X-Forwarded-For、HTTP Header、Cookie、Path、SNI、地域、JA3、JA4、上流プロキシが渡すUser IPをキーにできる。最大三つのキーを組み合わせ、ThrottleとRate-based banを選べる。4

IPだけでは同一NAT配下の利用者を巻き込む。Cookie、パス、TLS fingerprintなどを組み合わせられる点は、大規模API、ゲーム、メディア、ECで有効なのだ。

JSONとGraphQL over HTTPを解析できる​

事前構成WAFルールは、最大64 KBまでのリクエストボディを検査する。JSON解析を有効にすると、JSON構造と、適切に構成されたGraphQL over HTTPを解析してルールを適用できる。2021

シグネチャ感度を調整し、個別シグネチャやリクエストフィールドを除外できる。CEL式によるカスタムルールも表現力が高い。

reCAPTCHA連携​

Cloud ArmorはreCAPTCHAのAction token、Session token、Exemption cookie、リスクスコアをルール条件へ使える。手動Challengeへリダイレクトするだけでなく、摩擦の少ない評価結果を使ってAllow、Deny、Rate limitを決められる。5

Web、iOS、Androidまでアプリケーション側へ統合できれば、単純なUser-AgentやIP評判より深いBot対策になる。Fraud DefenseのAccount defenseを併用すれば、ログインやチェックアウトの不審な行動も別途評価できる。22

弱み​

reCAPTCHA統合なしではBot対策の強みが薄くなる​

Cloud Armor単体にAkamai Bot ManagerやImperva Advanced Bot Protectionと同じ形の巨大な高度Bot製品が内蔵されているわけではない。最大限の効果には、フロントエンドやモバイルアプリへreCAPTCHA tokenを組み込む必要がある。

非ブラウザAPI、サーバー間通信、CLI、WebhookへChallengeを適用することはできない。認証、APIキー、署名、mTLS、利用者単位レート制限を別に設計する必要がある。

API Securityは別製品と組み合わせる​

Cloud ArmorはAPIを検査できるが、企業全体のAPI Discovery、OpenAPIスキーマ管理、開発者ポータル、APIライフサイクルはApigeeなどの領域である。Cloud Armor単体をCloudflare API Shield、Akamai API Security、Imperva API Securityと同じ範囲で評価しないほうがよい。

ロードバランサーとの結合が前提になる​

事前構成WAFルールは、対応するGoogle Cloudロードバランサー背後のバックエンドサービスで使う。クラウド外を守る構成も可能だが、専業WAAPほど自然なマルチクラウド統制ではない。

料金と機能階層​

Standardはポリシー、ルール、リクエスト課金である。Enterprise PaygoとAnnualは保護リソース数とサブスクリプションを軸にし、含まれるリクエスト費用やDDoS機能が変わる。階層ポリシーを作るとEnterprise Paygoへ入る条件もある。23

トラフィック量、バックエンド数、リージョン、ロードバランサー費用、reCAPTCHA費用を合わせて試算する必要がある。

向いている環境​

  • Google Cloudのグローバルロードバランサーを使う
  • L7 DDoS、HTTP Flood、急激な異常トラフィックを重視する
  • 大規模API、ゲーム、メディア、ECを運用する
  • reCAPTCHAをWebやモバイルアプリへ統合できる
  • CEL、Cloud Logging、Terraformで制御したい

向いていない環境​

  • WAFルールグループの種類と更新版管理を最優先する
  • アプリ改修なしで高度Bot対策を完成させたい
  • 複数クラウドのAPIを自動発見したい
  • オンプレミスと複数CDNへ共通ポリシーを配りたい

判定​

Google Cloud上の第一候補でよい。

Cloud Armorは「AWS WAFよりルールが少ない」という一点で下位に置くと見誤る。Adaptive Protection、複合レート制限、reCAPTCHAまでを一つの設計として評価する製品なのだ。

Azure Web Application Firewall​

現在の位置付け​

Azure WAFは、以前より明確に改善している。

DRS 2.2はOWASP CRS 3.3.4を基盤とし、Microsoft Threat Intelligence由来のSQLi、XSS、CVE、Web shellなどの独自ルールを加える。新しいエンジン、Java injection、初期的なファイルアップロード検査、旧世代より少ない誤検知が説明されている。6

一般的なWebアプリケーションを守るWAFとしては、十分に採用できる水準である。

一つの製品として見ない​

Azure WAFには、少なくとも次の二つがある。

項目Azure Front Door WAFApplication Gateway WAF
配置グローバルエッジAzureリージョン内
主用途インターネット公開、グローバル配信、CDNリージョン内L7ロードバランサー、内部・外部公開
WAF SKUFront Door Premium中心Application Gateway WAF v2
DDoSFront Door基盤のL3・L4・L7保護、HTTP DDoS rulesetはプレビューAzure DDoS ProtectionやFront Doorとの併用を検討
BotBot Manager 1.x、JavaScript ChallengeBot Manager、JavaScript Challenge。機能にプレビュー制約あり
ポリシー適用ドメイン、パス、Front Door構成Gateway、Listener、Path単位

同じ「Azure WAF Policy」でも、機能、制約、料金、ログ、適用位置は完全には共通しない。

強み​

DRSとMicrosoft Threat Intelligence​

DRSは、SQLi、XSS、RCE、LFI、RFI、Java、PHP、Node.js、プロトコル攻撃などを扱い、Microsoft独自のCVE、Web shell、AppSecルールを含む。

DetectionとPreventionを切り替え、ルール、ルールグループ、ルールセット単位でActionを調整できる。JSON body、XML body、リクエスト属性の除外にも対応する。

ルールセットのサポート方針が明確になった​

2026年2月から、最新N、N-1、N-2の3世代を通常サポートし、N-3は12か月の最終サポートへ移る方針が導入された。DRS 2.2は2026年2月リリースとして扱われている。24

更新計画を立てやすくなったことは改善である。

JavaScript Challenge​

Front DoorとApplication Gatewayは、ブラウザへ不可視のJavaScript Challengeを出し、成功Cookieを使って正規ブラウザを通す。CAPTCHAより利用者負荷を下げやすい。7

ただし、AJAXとAPIは対象外で、非HTMLリソースやPOST bodyにも制約がある。Application GatewayのRate Limit custom ruleではJS Challengeを使えないプレビュー制約がある。万能なBot対策ではない。

Azure運用基盤との統合​

Log Analytics、Azure Monitor、Microsoft Sentinel、Bicep、ARM、Terraform、Azure Policyへ載せやすい。Microsoft中心のSOCにとって、検知、ログ、インシデント管理を同じ基盤へ寄せやすい。

弱み​

Bot Managerの中心は既知情報である​

Bot Manager 1.1は、Good、Bad、Unknownを分類し、悪性IP、偽装Bot、高リスクBot、Tor、各種クローラー、HTTPクライアントを扱う。Application Gatewayの公式説明では、Microsoft Threat Intelligence feedの既知悪性IPをBlockまたはLogする機能が中心とされている。25

Akamai、Cloudflare、Impervaのような行動分析型Bot製品や、AWS Targeted Bot Control、Cloud ArmorとreCAPTCHAの組み合わせと比べると、高度な買い占め、カードテスト、端末指紋、アカウント単位の不正対策は薄い。

自動L7 DDoSはまだプレビューである​

Front Door PremiumのHTTP DDoS rulesetは、7日間のトラフィックからベースラインを作り、全体とIP単位のしきい値を学習する。静的レート制限より進んだ機能だが、2026年7月時点ではプレビューである。十分なトラフィックがないと学習できず、監視機能にも制限がある。9

ルールセット更新でカスタマイズを失う可能性がある​

Front Doorの公式ドキュメントは、ルールセットのバージョン変更時に既存カスタマイズが新バージョンの既定値へリセットされると明記する。26

更新前に、無効化、Action override、Exclusion、Exception、Custom ruleをエクスポートし、差分を再適用する手順が必要である。

改善機能がプレビューに残る​

Application Gateway Exceptionsは、URI、IP、Headerを条件に特定ルール、ルールグループ、ルールセットだけを迂回できる。Exclusionより意図を分けやすいが、2026年7月時点でプレビューである。8

向いている環境​

  • Azure中心のWebシステム
  • Front Door Premiumを企業標準の公開入口にする
  • Sentinel、Log Analytics、Azure Policyへ統合する
  • Microsoft製品の契約と運用を集約したい
  • 一般的なOWASP Top 10対策が中心である

向いていない環境​

  • 高度Bot、不正ログイン、買い占め対策が主要要件である
  • Front DoorとApplication Gatewayの差を吸収したくない
  • プレビュー機能を本番の必須統制にできない
  • マルチクラウドのWAFを一つに統一したい

判定​

Azureの一般公開システムでは、原則としてFront Door Premiumを第一候補にする。リージョン内完結、内部向け、細かなL7ルーティングではApplication Gateway WAFを使う。

二つを重ねる場合、外側でDDoS、Bot、地理制御、企業共通ポリシー、内側でアプリ固有ルールと内部セグメント保護という役割を決める。同じDRSを二重にBlockさせるだけの構成は、誤検知と調査箇所を増やすのだ。

Akamai​

現在の位置付け​

Akamaiは、6製品の中で最も強い大企業向けインターネット境界防御である。

App & API Protectorを中心に、Adaptive Security Engine、Bot Manager Premier、Account Protector、API Security、Prolexic、Client-Side Protection & Complianceを組み合わせる。製品単体というより、重要なデジタルサービスを止めないためのプラットフォームとして評価するものなのだ。

WAFの強み​

Adaptive Security Engineは、従来のKona Rule SetやAutomated Attack Groupsを置き換える新しい防御エンジンである。Akamaiの大規模なエッジ観測、脅威情報、攻撃パターン、自己調整を利用し、ルールと攻撃グループを更新する。2728

次の運用機能が揃う。

  • Attack Group単位と個別ルール単位のAction
  • Alert、Deny、Evaluation
  • 新ルールを本番遮断前に比較するEvaluation mode
  • 誤検知を減らすTuning recommendation
  • Hostname、Path、API、Match targetごとのポリシー
  • API、CLI、Terraform、CI/CD
  • エッジ外、オンプレミス、ハイブリッド、複数CDNへ広げるHybrid構成

自動更新と自己調整に寄せることも、厳格な変更管理を行うこともできる。専門家支援を含めると、重要システムで防御精度を詰めやすい。

DDoS​

L7はApp & API ProtectorのBehavioral DDoS Engineで扱う。L3・L4はProlexicが担う。

Prolexicは、20 Tbps超の専用防御容量、32超のスクラビングセンター、ゼロ秒緩和SLA、100%プラットフォーム可用性SLA、225人超のSOCC担当者を公表する。クラウド、オンプレミス、ハイブリッド、IP単位保護へ対応する。29

Cloudflareの自律的な巨大Anycastと比べると、Akamaiは専用スクラビング、事前調整された防御制御、SOCCの人間支援を前面に出す。

Botとアカウント保護​

Bot Manager Premierは、既知Bot一覧だけでなく、端末、ブラウザ、JavaScript、行動、評判、機械学習を組み合わせる。スクレイピング、買い占め、カードテスト、在庫枯渇、クレデンシャルスタッフィングなど、業務機能の悪用を対象にする。

Account Protectorはさらに、正当な人間かどうかではなく、正当なアカウント所有者らしい行動かを見る。ログイン、セッション、過去行動、不正な認証後活動を評価する。AkamaiはAccount ProtectorがBot Managerの能力を含むと説明している。30

大規模EC、金融、チケット、ゲーム、航空など、Botが直接売上と顧客被害へつながる環境で強い。

API Security​

App & API ProtectorにもAPI Discoveryと基本的なAPI保護がある。別製品のAkamai API Securityは、Akamai配下であることを前提としないベンダーニュートラルなAPI発見、インベントリ、振る舞い分析、リスク評価を提供する。31

この二層構造により、インライン遮断と、企業全体のAPI可視化を分けられる。

弱み​

  • 製品概念、契約、管理画面、設定対象が多い
  • 専門家、導入支援、プロフェッショナルサービスへの依存が強くなりやすい
  • 変更の承認とActivationを含む運用が、Cloudflareほど軽快ではない
  • 価格は個別見積もりが中心で、小規模サイトには過剰になりやすい
  • Bot対策は強いが、アプリ固有の調整に時間と支援が必要になる
  • App & API Protector、Prolexic、API Securityなどを揃えると、単一製品の購入ではなくなる

向いている環境​

  • 金融、通信、社会インフラ、大規模EC
  • DDoS、Bot、アカウント不正が現実的な事業リスクである
  • 24時間365日の専門家支援が必要である
  • オンプレミス、複数クラウド、複数CDNを持つ
  • 費用より防御力、可用性、支援体制を優先する

向いていない環境​

  • 小規模なWebサイトを少人数で運用する
  • 自社だけで即時に細かな変更を回したい
  • 公開価格と簡単なセルフサービスを重視する
  • WAFのための専任運用者を確保できない

判定​

最も強い製品を選ぶならAkamaiである。

ただし、最も強いことと、最も適することは同じではない。Akamaiを選ぶ判断には、製品費用だけでなく、専門要員、変更管理、ベンダー支援を含む運用モデルが必要なのだ。

Cloudflare​

現在の位置付け​

Cloudflareは、6製品の中で最も現代的で、最も自社運用しやすい統合エッジである。

WAF、DDoS、Bot Management、API Shield、Rate Limiting、Turnstile、Page Shield、Magic Transit、DNS、CDN、Load Balancer、Workers、Zero Trustを、共通のグローバルネットワークとルール基盤へ載せる。

WAFの強み​

Cloudflare Managed RulesetとCloudflare OWASP Core Rulesetを使える。OWASP rulesetは累積スコア型で、ルール、タグ、スコアしきい値、Actionを調整できる。Skip式で例外を作り、Custom Rules、Rate Limiting、Managed Rulesの実行順を意識して制御する。32

ルール式では、IP、ASN、国、URI、Header、Cookie、TLS属性、Bot Score、JA3、JA4、API情報などを組み合わせられる。

最大の強みは、検知器の数ではなく、検知結果を他の制御へつなぐ扱いやすさである。

DDoS​

Cloudflareは、L3・L4・L7の標準DDoS保護を全プランへ従量上限なしで提供すると説明する。DDoS managed rulesetsは自動的に動き、Enterpriseでは感度とActionをより細かく調整できる。11

2026年4月には、330超の都市で合計500 Tbpsの外部接続容量を公表した。この数字はピークトラフィックではなく、トランジット、ピアリング、IX、CNIの外部ポート容量の合計である。防御専用容量と同じ定義ではない点に注意が必要だが、巨大なAnycast基盤であることは確かである。10

HTTPはDDoS managed rulesets、ネットワークはMagic Transit、DNSは権威DNS、独自UDPはProgrammable Flow Protectionなどへ分かれる。

Bot Management​

Bot Managementは各リクエストへ1から99のBot Scoreを付ける。1は自動化の確度が高く、99は人間の確度が高い。Heuristics、機械学習、JavaScript Detections、Verified Botsを組み合わせ、WAF custom ruleやWorkersでスコアを使える。33

Bot ScoreとURI、認証状態、国、Cookie、レートを一つの式へ書けるため、運用の自由度が高い。

一方、自由度は設定責任でもある。単純に「低スコアを全部Block」とすると、RSS、監視、独自クローラー、アクセシビリティ支援、VPN、特殊ブラウザ、正規のAPIクライアントを止める。

API Shield​

API Shieldは、今回の6製品で最も開発者が扱いやすいAPIセキュリティの一つである。

  • API DiscoveryとEndpoint Management
  • OpenAPI 3.0のSchema Validation
  • 観測トラフィックからのSchema Learning
  • mTLS
  • JWT Validation
  • Rate limit recommendation
  • Sequence AnalyticsとSequence mitigation
  • GraphQL queryの深さと大きさの制限
  • Sensitive Data Detection

Schema Validation 2.0は、Host、Method、PathでEndpointを管理し、違反をLogまたはBlockできる。本文検査上限はプランにより異なり、Enterpriseの既定は128 KBである。3435

API Discoveryは「見つけた」だけで終わらず、スキーマ、JWT、mTLS、レート制限、通信順序へつなげられる点が強い。

運用性​

Cloudflareの管理画面、API、Terraform、Ruleset Engine、Logpushは、開発者とプラットフォームチームが自分で回しやすい。

DNS変更を中心に短期間で導入し、少数サイトから始めてアカウント共通ルールへ広げられる。無料、Pro、Business、Enterpriseへ段階があり、小規模な学習環境から大企業まで利用者層が広い。

弱み​

プラン差が大きい​

「Cloudflareでできる」と「現在の契約でできる」は別である。

粒度の高いBot Score、長期ログ、API Shieldの高度機能、Account-level rules、専任支援、Advanced DDoSなどはEnterpriseまたは追加契約になりやすい。無料版の使いやすさからEnterpriseの費用を推測しないほうがよい。

実行フェーズが複雑である​

DDoS、Custom Rules、Rate Limiting、Managed Rules、Transform、Workersなどの実行順を理解しないと、後段ルールが評価されない、Skipが効かない、ログが想定と違うという事象が起きる。

Managed Rulesは、DDoS、Custom Rules、Rate Limitingより後に動く。前段で終端Actionが出れば、Managed Rulesは評価されない。32

正規利用者と正規Botの誤遮断が表面化しやすい​

Cloudflareは利用者母数が大きく、ChallengeとBot判定への批判が最も可視化されている。

Hacker Newsでは、RSS reader、Linux上のカスタマイズブラウザ、VPN利用者、マイナーブラウザ、第三者連携がBot扱いされる経験が繰り返し報告されている。363738

これはCloudflareだけが誤判定する証拠ではない。Cloudflareが広く使われ、Challengeが利用者の目に見え、設定が容易なため、過剰な一括設定も増えやすいという側面がある。それでも、機械利用を想定したPathへブラウザChallengeを置かない設計は必須である。

サポート評価が契約で割れる​

セルフサービスで解決できる間は高く評価される。問題が製品内部、Botモデル、アカウント制限、ネットワークへ入ると、低価格契約のサポートへ不満が出やすい。Enterpriseでも評価は一様ではない。

向いている環境​

  • SaaS、API、開発者中心の企業
  • 多数のWebサイトを短期間で統一したい
  • TerraformとAPIで変更を自動化したい
  • CDN、DNS、WAF、DDoS、Zero Trustを一つのベンダーへ寄せたい
  • 自社でログを見て誤検知を調整できる
  • 小規模から始め、段階的に拡張したい

向いていない環境​

  • すべてのチューニングをベンダー専門家へ任せたい
  • Bot誤判定が許されず、自社でPath別設計を行えない
  • DNS、CDN、WAF、Zero Trustの集中障害を受け入れられない
  • Enterprise契約の価格と機能差を事前に固定できない

判定​

一般企業で、防御力、導入速度、変更容易性、API、IaC、費用対効果のバランスを取るなら、Cloudflareが最も現実的な選択になりやすい。

ただし、簡単に有効化できることは、簡単に正しく運用できることと同じではない。特にBot、Challenge、Skip、実行フェーズは、Pathとクライアント種別を分けて設計するのだ。

Imperva​

現在の位置付け​

Impervaは、WAFを中心にアプリケーションとデータを守る専業プラットフォームである。

Cloud WAFだけでなく、オンプレミスまたは仮想アプライアンスのWAF Gateway、Elastic WAF、API Security、Advanced Bot Protection、Account Takeover Protection、Client-Side Protection、DDoS、Attack Analytics、Data Securityを持つ。3940

WAFの強み​

Impervaは、シグネチャ、プロトコル検査、評判情報、動的プロファイリング、機械学習、専門家のルール更新を組み合わせる。

Cloud WAFとWAF Gatewayを持つため、クラウドへ移せないレガシー、データ主権、オンプレミスを含む環境でも候補になる。金融や規制産業で「本格的なWAF」として認識されてきた理由なのだ。

Botとアカウント保護​

Advanced Bot Protectionは、評判モデル、クライアント分類、独自Challenge、端末とブラウザの特徴、行動分析、サイト固有の異常、機械学習を重ねる。

Block、Allow、CAPTCHA、Challenge、Monitor、Rate limit、Delay、Tarpitなど複数の応答を使い分ける。スクレイピング、カードテスト、アカウント作成、クレデンシャルスタッフィング、API abuseを対象にする。41

Account Takeover Protectionは、漏えい認証情報、ログインページ、利用者行動、アカウント単位の不審な活動を扱う。単なるIPレート制限より深い。42

API Security​

Imperva API Securityは、Public、Private、Shadow APIを継続的に発見し、機密データ、リスク、BOLA、BOPLA、Broken Authentication、業務ロジック悪用を評価する。APIのリスク分類からAdvanced Bot Protectionへつなげられる。43

Cloud WAFのDiscovery-only add-onから始め、全APIをいきなり課金対象の強制モードへ載せず、可視化から進める選択肢も示されている。44

DDoS​

ImpervaはWeb、Network、DNS、Individual IPのDDoS保護を持つ。13 Tbpsのスクラビング容量と、L3・L4で3秒以内の緩和SLAを公表する。Always-onとOn-demand、GRE、Cross Connect、個別IP保護へ対応する。45

AkamaiとCloudflareほどDDoSブランドが先に立たないが、企業向け製品として十分に強い。

データセキュリティとの接続​

Impervaの独自性は、アプリケーションの背後へ続く。

Data Securityは、100超のデータリポジトリを対象に、機密データの発見、分類、利用者、アクセス、異常、コンプライアンスを扱う。WAFイベントとデータアクセスを自動的に一つの因果として解決するわけではないが、同一ベンダーでアプリケーションからデータまで観測範囲を広げられる。46

弱み​

  • 管理画面、ポリシー、集約イベント、個別ログの関係に慣れが必要である
  • APIとTerraform中心の運用はCloudflareやAWSほど洗練されていない
  • ログ取得、保持、通常アクセスの可視性は契約と構成を確認する必要がある
  • 製品情報と詳細技術資料が公開Webだけでは見つけにくい場合がある
  • Cloud WAF、WAF Gateway、Bot、API、Dataを揃えると契約が複雑になる
  • 価格は個別見積もりが中心である
  • Thales傘下で製品統合や名称が変わる可能性を追う必要がある

向いている環境​

  • WAF検知と誤検知抑制を中心に評価する
  • 金融、公共、規制産業
  • オンプレミスWAFを維持する
  • 高度Bot、アカウント不正、API Securityが必要である
  • データベースと機密データの保護も同じベンダーで扱いたい

向いていない環境​

  • 開発者がTerraformだけで高速にセルフサービスしたい
  • 無料または低価格から段階的に始めたい
  • DDoSの最大規模とSOCCを最優先する
  • 公開情報だけで機能と価格を比較したい

判定​

Impervaは、WAF専業性が必要な組織で依然としてトップクラスである。

総合プラットフォームの広さと開発者体験ではCloudflare、DDoSと専門家支援ではAkamaiが先に見える。一方、WAF、Bot、API、クライアント側、データを一つのセキュリティ思想でつなぐ点は、Impervaの独自性なのだ。

機能横断比較​

WAF検知とマネージドルール​

製品中心となる防御ルール更新調整の特徴
AWS WAFAWS Managed Rules、Marketplace、カスタムルール静的版固定とDefault追随、通知、有効期限個別Action override、Scope-down、ラベル連携
Cloud Armor事前構成WAFルール、CELGoogle管理Sensitivity、Signature、Field exclusion、Preview
Azure WAFOWASP CRSベースのDRS＋Microsoft独自ルールN/N-1/N-2、バージョン更新Rule/Group action、Exclusion、Exception、Custom rule
AkamaiAdaptive Security Engine、Attack Group、Rule自動更新または管理更新Evaluation、Tuning recommendation、Match target
CloudflareCloudflare Managed、OWASP CRS、Custom Rules自動更新、VersionとoverrideRuleset Engine、Skip、Tag、Score、Phase
ImpervaSignature、Protocol、Profile、Reputation、MLベンダー管理自動ポリシー、プロファイリング、例外、Attack Analytics

WAFの強さは、ルール数だけでは決まらない。

同じOWASP CRSを使っていても、HTTP正規化、JSON/XML/multipartの解析、ルールの組み合わせ、スコア、脅威情報、通常トラフィック学習、更新速度、誤検知チューニングで結果が変わる。

独立研究のWAFFLEDは、AWS WAF、Azure WAF、Cloud Armor、Cloudflare、ModSecurityを対象に、JSON、XML、multipartのパース差を利用した1,207件のバイパスを確認したと報告した。すべてのベンダーが報告を受領し、一部はBug bountyを支払った。47

この研究から得るべき結論は「特定製品が弱い」ではない。WAFとアプリケーションフレームワークが同じHTTPを違って解釈すれば、どの製品にも回避余地が生まれるということなのだ。

ボディ検査上限​

リクエストボディ検査の上限は、製品比較で見落とされやすい。

製品公開仕様から確認できる例運用上の注意
AWS WAFALB/AppSync 8 KB固定。CloudFront等は16 KB既定、最大64 KB超過時のContinue/Match/No matchを設計。gRPC bodyは非対応
Cloud Armor8/16/32/48/64 KBから設定、最大64 KBJSON/GraphQL解析も設定上限まで
Azure WAF統合先、エンジン、設定で異なるFront DoorとApplication Gatewayを別々に確認
Cloudflare WAFプラン依存。Enterprise Managed Rulesは128 KBが基準Schema Validationの上限はWAF上限と別
Akamai契約、機能、Content-Typeで確認が必要API constraintとWAF検査を分けて確認
Imperva契約とデプロイ方式で確認が必要Cloud WAFとGatewayを分けて確認

数字が大きいほど単純に強いわけではない。

検査量を増やすと、より多くの攻撃文字列を見つけられる一方、正常な大容量JSONやアップロードで誤検知が増える。上限超過を自動Blockにすると業務停止になり、無条件Passにすると回避経路になる。

PoCでは、本文先頭にダミーデータを置く、multipart boundaryを変える、重複パラメータを使う、JSONのネストと配列を変える、Content-Typeと実体をずらす試験が必要なのだ。

誤検知チューニング​

AWS WAF​

最も細かく、説明可能に組み立てやすい。Count、Rule action override、Label、Scope-down、Regex、Custom responseを組み合わせる。ただし、設計者の力量へ依存する。

Cloud Armor​

Sensitivity、個別Signature、Field exclusion、Preview、CELで調整する。レート制限もPreviewできる。比較的明快だが、CELと事前構成ルールの知識が必要である。

Azure WAF​

Exclusion、Exception、Custom Allowを使い分ける。細かくなってきたが、Front DoorとApplication Gatewayの差、プレビュー状態、ルールセット更新が運用リスクになる。

Akamai​

EvaluationとTuning recommendation、専門家支援が強い。自動化と人間の調整を組み合わせられるが、製品固有知識が必要である。

Cloudflare​

式の表現力が最も高く、SkipとOverrideをPathや条件へ限定しやすい。反面、実行フェーズと終端Actionを誤ると、意図せず検査全体を飛ばす。

Imperva​

プロファイリングと自動ポリシーで誤検知を抑える思想が強い。細かなログ追跡と自動化の使い勝手は、PoCで確認する必要がある。

DDoS​

製品L7 DDoSL3・L4/DNS特徴
AWSWAF Anti-DDoS、Rate rule、CloudFront、Shield AdvancedShield Standard/AdvancedAWSリソースとの統合、DRT、費用保護
Google CloudAdaptive ProtectionCloud Armor Enterprise、Google Cloud基盤ベースライン学習と緩和ルール提案・自動配備
AzureFront Door基盤、Rate limit、HTTP DDoS ruleset PreviewAzure DDoS ProtectionMicrosoftネットワークとFront Door統合
AkamaiBehavioral DDoS EngineProlexic20+ Tbps専用防御、32+拠点、ゼロ秒SLA、SOCC
CloudflareHTTP DDoS managed rulesets、Adaptive DDoSMagic Transit、DNS、Advanced TCP/DNS500 Tbps外部接続容量、自律緩和、Anycast
ImpervaCloud WAFとAdaptive L7防御Network、DNS、Individual IP13 Tbps、L3・L4 3秒SLA

能力の順位は、何を守るかで変わる。

  • WebサイトとAPIだけなら、Cloudflare、Akamai、Cloud Armorが強い
  • データセンター、BGP Prefix、全プロトコルなら、Akamai Prolexic、Cloudflare Magic Transit、Imperva Network Protectionを比較する
  • AWS内の費用保護と支援ならShield Advancedを含める
  • Azureの公開WebならFront Doorを前段に置く

公表容量は、定義が違う。Akamaiの20+ TbpsはProlexicの専用防御容量、Cloudflareの500 Tbpsは全世界の外部接続ポート容量、Impervaの13 Tbpsはスクラビング容量である。単純な棒グラフにしてはいけないのだ。

Botと不正利用​

製品既知Bot行動・MLChallengeアカウント不正
AWS WAFBot Control、650+ Bot/AgentTargeted ML、Token reuse、Coordinated activityCAPTCHA、ChallengeATP、ACFP
Cloud ArmorreCAPTCHA評価とルールreCAPTCHA score、token、JA4、ratereCAPTCHA redirectFraud Defense Account defenseは別機能
Azure WAFBot Manager、Threat Intelligence限定的。HTTP DDoS学習は別JavaScript Challenge専用ATO機能は弱い
AkamaiBot Manager Premier端末、行動、ML、暗号化検知Challenge、Delay、Deny等Account Protector
CloudflareVerified Bots、Bot catalogBot Score、ML、Heuristics、JSDManaged Challenge、Turnstileルール連携。専用Account Abuse機能は契約確認
ImpervaBot classification端末、行動、サイト固有MLCAPTCHA、Challenge、Delay、Tarpit等Account Takeover Protection

Bot対策には、少なくとも四つの問題が混ざる。

  1. 検索エンジンや監視など、許可したい正規Bot
  2. 既知の悪性Bot、スキャナー、ツール
  3. 人間に似せたヘッドレスブラウザと住宅プロキシ
  4. 正規APIと正規アカウントを使う業務不正

Azure Bot Managerは1と2へ強く、CloudflareとAWSは3へ踏み込み、AkamaiとImpervaは4を含む業務不正へ最も深く入る。Cloud ArmorはreCAPTCHAとアプリ統合によって3と4へ広げる。

どの製品も完全ではない。商用CAPTCHA解決、住宅プロキシ、実ブラウザ自動化、低速分散、LLMエージェントにより、Challengeと指紋は回避されうる。2026年の研究でも、Challenge型と信頼型のBot防御を、CAPTCHA解決サービスとLLMブラウザAgentに対して再評価する必要が示されている。48

APIセキュリティ​

機能AWS WAFCloud ArmorAzure WAFAkamaiCloudflareImperva
APIへのWAF適用強い強い強い強い強い強い
API Discovery限定的限定的限定的強い強い強い
OpenAPI Schema ValidationWAF単体では弱いWAF単体では弱いWAF単体では弱い対応範囲を契約確認強い強い
Schema Learning弱い弱い弱い強い強い強い
mTLS/JWT周辺サービスで対応周辺サービスで対応周辺サービスで対応API Security構成で確認API Shieldで強い構成と統合先で確認
行動・業務ロジック分析限定的限定的限定的強いSequence Analytics強い
Shadow/Zombie API弱い弱い弱い強い強い強い

ネイティブWAFは「APIへWAFを付ける」ことには強い。

専業WAAPは「企業内にどのAPIがあり、何を返し、どの順序で使われ、どのAPIが古く、どこに機密データがあるか」を発見する方向へ広がっている。

API中心企業では、WAF比較とAPI Security比較を分けるべきなのだ。

クライアント側とデータ保護​

WAFは、サーバーへ入るHTTPリクエストを見る。ブラウザで実行される第三者JavaScriptや、WAFの背後にあるデータベースの不正利用は直接の主対象ではない。

Akamai Client-Side Protection & Compliance、Cloudflare Page Shield、Imperva Client-Side Protectionは、JavaScript、依存先、外部送信、Magecart、PCI DSS 4.xの要件を扱う。

ImpervaはさらにData Securityを持ち、データの発見、分類、アクセス監視、異常、コンプライアンスへ広げる。

クラウドネイティブ側にもCSP、ブラウザ監視、クラウドデータセキュリティの別サービスはある。しかし、それらはWAF製品内の統合機能ではないため、本比較では専業3社が優位となる。

ログと観測​

AWS​

CloudWatch metrics、Sampled requests、WAF logs、Firehose、S3、CloudWatch Logs、Security Lakeを組み合わせる。情報量と連携先は多いが、ログ費用とクエリ設計が必要である。

Google Cloud​

Cloud Loggingへルール名、Action、Preview、Adaptive Protection情報を出せる。ただし、バックエンドサービスのHTTP(S) loggingは既定で無効の場合があり、最初に有効化する必要がある。21

Azure​

Azure Monitor、Log Analytics、Sentinelへ集約できる。Front DoorとApplication Gatewayでログスキーマ、Rule ID、Action、診断設定を揃える作業が必要である。

Akamai​

Security reports、SIEM Integration、APIを持つ。攻撃グループと個別イベントを追えるが、Akamai固有の設定オブジェクトとActivationに慣れる必要がある。

Cloudflare​

Security Events、Security Analytics、GraphQL Analytics、Logpushを使う。セルフサービス性は高い。プランごとの保持期間、サンプリング、フィールド、ログ配送を確認する。

Imperva​

Attack Analyticsは大量のイベントを攻撃キャンペーンへ集約する。一方、通常アクセスログ、セキュリティイベント、集約攻撃、個別リクエストの関係と保持条件をPoCで確認したほうがよい。

公式仕様の外側にある市場評価​

Gartner Peer Insights​

2026年7月時点で検索可能なCloud WAAP関連ページでは、次の値が表示されていた。

製品評価件数読み方
Akamai App & API Protector4.8約500大企業利用者が多く、製品能力と支援が評価される
Imperva Application Security Platform4.7約550WAF、防御安定性、可視性が評価される
Cloudflare Application Services4.5約480操作性と統合性が評価される一方、支援評価は割れやすい
AWS WAF4.4約380AWS統合と柔軟性が評価され、初期学習と誤検知が不満になりやすい
Google Cloud WAAP4.33件数が少なすぎ、順位判断には使えない
Azure WAF単純比較を避ける－取得時点の表示だけで同じ母集団を作れない

Gartner Peer InsightsのAkamaiページは4.8、504件、Cloud WAAP市場ページはCloudflare 4.5、476件、Impervaは4.7、AWS WAFページは4.4、378件を示している。49505152

この数字だけで製品性能を順位付けしてはいけない。

  • 利用者層と契約規模が違う
  • 同じ機能範囲を評価していない
  • 導入支援や担当者が評価へ混ざる
  • レビュー依頼と公開審査による偏りがある
  • 0.1から0.3点の差に決定的な意味はない

それでも、AkamaiとImpervaが大企業向けで高く評価され、CloudflareとAWSが使いやすさと統合性で支持される傾向は、他の情報源とも一致する。

SecureIQLabの独立検証​

SecureIQLabの2024 Cloud WAAP比較は、3,500超の攻撃と6,500超の正常通信テストを使ったと説明する。公表された総合Security Efficacyは、Imperva 98.8%、Azure 87.7%、AWS 83.1%、Cloudflare 81.8%、Google 80.3%であった。Akamaiの値は非公開扱いである。Operational EfficiencyはImperva 99.1%、Azure 90.6%、Cloudflare 88.9%、Google 88.0%、AWS 83.8%であった。53

2025年のImperva個別検証は、ImpervaのComplete Security Score 87.94%、Operational Efficiency 95.7%、Bot Score 100%、L7 DoS 100%、False Positive avoidance 100%を報告した。WebSocketsや一部APIテストは低い結果も含まれ、すべてが100%ではない。54

この試験は貴重だが、次の理由で絶対順位にはできない。

  • テスト時点の製品バージョンと設定に依存する
  • 各社の推奨設定とチューニング条件が完全に同じとは限らない
  • 本番固有の正常通信を再現しない
  • 製品モジュールと契約範囲が異なる
  • 個別レポートはベンダーサイトで配布される場合がある

それでも、「ネイティブWAFも一定の防御結果を出すが、専業WAFの一部は検知と運用効率で上回る」という方向性を裏付ける材料にはなる。

RedditとHacker Newsで繰り返される傾向​

Akamai​

  • 防御力、DDoS、Bot、サポートは高く評価される
  • 導入、設定、文書、変更反映、価格が重い
  • Bot Managerは強いが、アプリ固有のfine-tuningに支援と時間が必要
  • 大企業と金融には合うが、小規模には過剰

CloudflareとAkamaiの両方を扱った投稿には、CloudflareをTerraformで数時間以内に立ち上げられた一方、Akamaiの導入は難しかったという経験がある。これは一件の投稿であり一般化できないが、「Cloudflareは軽く、Akamaiは重い」という反復傾向と一致する。55

Cloudflare​

  • 導入、DNS、証明書、API、Terraform、ルール変更が扱いやすい
  • 安価または無料から学べるため、人材と公開情報が多い
  • DDoSと基本WAFの費用対効果が高い
  • Enterpriseの価格、契約、サポートは評価が割れる
  • BotとChallengeによる正規利用者、RSS、独自ツールの遮断が目立つ

Cloudflareへの批判には、製品の誤判定と、サイト運営者が全Pathへ強すぎる設定を入れた問題の両方が混ざる。RSSやAPIのように機械アクセスを前提とするPathへ、人間証明を要求すること自体が設計ミスなのだ。

Imperva​

  • 「本格的なWAF」として信頼される
  • 金融、規制産業、オンプレミスで実績がある
  • 誤検知を抑えた防御が評価される
  • 管理、ログ、チューニング、サポート品質は評価が割れる
  • Cloudflareほど利用者コミュニティの情報量が多くない

2026年のReddit比較でも、Impervaは防御自体を高く評価されながら、証明書制約とカスタマーサービスが移行検討の理由として挙げられている。一方、Cloudflare利用者からは、サポートが弱い場合があるが、長年ほぼ問い合わせず運用できたという意見も出ている。56

世間評価を一言で表す​

製品世間で繰り返される短い評価
AWS WAFAWS内では十分強い。柔軟だが、ルールと費用の設計が必要
Cloud ArmorDDoSとレート制限は強い。WAF単体の話題と利用者情報が少ない
Azure WAFAzure標準として使える。Front DoorとApp Gatewayの違いが面倒
Akamai最強級だが、重くて高い
Cloudflare十分強く、圧倒的に扱いやすい。Challengeとサポートは揉めやすい
Imperva本格WAF。強いが、運用体験は伝統的

クラウドネイティブWAFと専業WAAPの境界​

ネイティブWAFだけでよい条件​

  • システムが単一クラウド内にある
  • 主な要件がOWASP Top 10、CVE仮想パッチ、IP、国、レート制限である
  • クラウドのCDN、LB、API入口へ自然に関連付けられる
  • ログをクラウド標準の監視基盤へ集約する
  • IaCとアカウント・サブスクリプション統制を重視する
  • Bot対策が既知Bot、基本Challenge、ログイン試行制御で足りる
  • 数日から数週間のCount・Detection期間を取れる
  • 自社で誤検知とルール更新を管理できる

この条件なら、専業WAAPを必須にする理由は薄い。

専業WAAPが有利な条件​

  • 複数クラウド、オンプレミス、複数CDNを一つのポリシーで守る
  • 高度なBot、買い占め、スクレイピング、カードテスト、ATOがある
  • L3・L4 DDoSとWeb DDoSを一つの契約と支援体制へ寄せる
  • API Discovery、Schema Learning、Shadow API、業務ロジック分析が必要
  • JavaScript supply chainとクライアント側情報窃取を監視する
  • 専門家が24時間攻撃対応とチューニングを行う
  • ゼロデイ時にベンダーの緊急ルールと調査支援を求める
  • 企業共通のインターネット境界基盤を作る

専業WAAPを全システムへ置く必要はない​

企業内のすべてのWebシステムが、同じ脅威と価値を持つわけではない。

合理的な構成は、たとえば次である。

システム区分候補
一般的な社外Web、単一クラウドネイティブWAF
重要な会員サイト、決済、EC専業WAAPまたはネイティブ＋高度Bot
企業共通API基盤専業API Security＋API Gateway＋WAF
大規模DDoS対象専業Network DDoSまたはクラウドの上位DDoS契約
内部管理画面WAFだけでなくZero Trust Access、VPN、Private connectivity
レガシー・オンプレミスAkamai Hybrid、Imperva WAF Gatewayなど

製品標準化は目的ではない。運用能力と責任分界を標準化し、システムリスクに応じて防御を変えるのだ。

システム特性別の推奨​

AWS上の一般WebとAPI​

第一候補はAWS WAFである。

AWS Managed RulesをCountで導入し、静的バージョン、ラベル、Scope-down、レート制限を使う。Bot ControlとFraud Controlは、全通信ではなく対象Pathへ絞る。L7 DDoSが重要ならAnti-DDoS managed rule group、ネットワークと費用保護まで必要ならShield Advancedを検討する。

Google Cloud上の大規模サービス​

第一候補はCloud Armorである。

事前構成WAFルールを低い感度から始め、JSON/GraphQL parsing、複合レート制限、JA4、Adaptive Protectionを有効化する。WebとモバイルのBot問題にはreCAPTCHA tokenを統合する。

Azure上の公開サービス​

第一候補はFront Door Premium WAFである。

DRS 2.2をDetectionから始め、Bot Manager、Rate limit、Private LinkでOriginを閉じる。HTTP DDoS rulesetはプレビュー条件を確認する。リージョン内の細かなL7制御が必要ならApplication Gatewayを追加するが、二重WAFの役割を分ける。

大規模金融機関​

第一候補はAkamai、次点はImpervaである。

AkamaiはProlexic、SOCC、Bot Manager、Account Protectorが強い。ImpervaはWAF、Bot、API、データ保護、オンプレミスをまとめやすい。

最終判断は、既存CDN、データ主権、SOC、サポートSLA、海外拠点、API構成で変わる。

大規模EC、チケット、航空、ゲーム​

高度BotとDDoSが中心ならAkamaiを優先する。自社で高速にルールを回し、APIとエッジ処理を統合するならCloudflareも強い。ImpervaはBotとATO、WAF精度を重視する場合に有力である。

SaaS企業​

Cloudflareが第一候補になりやすい。

API Shield、Terraform、Logpush、Workers、Zero Trustを同じ基盤へ載せやすい。AWSだけで完結するSaaSなら、AWS WAFとAPI Gateway、CloudFrontの組み合わせでも十分である。

多数の小中規模Webサイト​

Cloudflareが最も始めやすい。

ただし、すべてのサイトへBot FightやChallengeを一括適用せず、RSS、Webhook、API、監視、管理用ツールを分類する。単一クラウドに統一されているなら、ネイティブWAFを組織ポリシーで配る選択もある。

オンプレミス併存​

Akamai App & API Protector HybridまたはImperva WAF Gatewayを優先して比較する。

CloudflareもTunnel、Magic Transit、Load Balancerなどを使ってクラウド外を守れるが、インラインWAF Gatewayや既存データセンター要件との適合をPoCする。

データ保護を最優先​

Impervaが独自の候補になる。

ただし、WAFとData Securityを同一ベンダーにしただけで、アプリケーション攻撃とデータアクセスの責任分界が自動的に解決するわけではない。データ分類、DB監視、権限管理、SIEM、インシデント対応を別途設計する。

選定フロー​

PoCで確認すること​

機能一覧ではなく、同じ通信で比べる​

ベンダーデモは、各製品が得意な設定で行われる。比較PoCでは、同じ正常通信、同じ攻撃通信、同じ運用課題を6製品または短縮候補へ当てる必要がある。

正常通信​

  • ログイン、ログアウト、パスワード再設定
  • 会員登録、購入、検索、CSV、ファイルアップロード
  • 長いJSON、GraphQL、XML、multipart
  • モバイルアプリ、SPA、AJAX、Webhook
  • RSS、監視、検索クローラー、決済・物流などの第三者連携
  • VPN、共有IP、IPv6、モバイル回線、海外拠点
  • ピークイベント、販売開始、バッチ、キャンペーン

攻撃通信​

  • SQLi、XSS、RCE、LFI、RFI、Path traversal
  • 既知CVE相当のペイロード
  • Encoding、重複Parameter、Content-Type不一致
  • JSON、XML、multipartのParser discrepancy
  • 大きなBodyの後半へ置いた攻撃文字列
  • Credential stuffing、Password spray、Account creation abuse
  • Scraping、Card testing、Inventory hoarding
  • 低速分散L7 DDoS、単一IP flood、住宅プロキシ分散
  • APIのBOLA、BOPLA、過剰データ、異常な呼び出し順

測定指標​

領域測定するもの
検知True Positive、False Negative、検知理由、Rule ID
業務影響False Positive、正規Bot誤遮断、Challenge失敗、解除時間
性能追加Latency、Peak時の挙動、Origin負荷
回避耐性Encoding、Body上限、Parser差、Header変形
Bot検知率、Challenge回避、人間誤判定、APIクライアント影響
DDoS検知開始、緩和開始、Origin到達量、正規急増との差別
APIDiscovery精度、Schema差分、Shadow API、機密データ
ログ欠落、遅延、Sampling、保持、SIEM連携、検索時間
変更Policy反映時間、Rollback、Version更新、承認手順
運用1件の誤検知を調査・修正する工数
サポート初動、技術回答、緊急変更、責任分界
費用平常時、ピーク時、攻撃時、ログ、追加モジュール、人件費

合否基準​

合否は「攻撃を何%止めたか」だけにしない。

たとえば次のように定義する。

  • Criticalな攻撃テストは100%遮断または補完対策で説明できる
  • 正常な決済、ログイン、API、Bot連携の誤遮断は0件
  • 高リスクPathのFalse Positiveを、30分以内に原因特定できる
  • ルール変更とRollbackを、承認込み60分以内に完了できる
  • 攻撃中もログが欠落せず、10分以内にSIEMで検索できる
  • 契約上の支援窓口と、顧客・ベンダーの変更権限が明確である

数値はシステムごとに変える。重要なのは、製品を触る前に合格条件を決めることなのだ。

導入と運用の推奨モデル​

1. 入口を閉じる​

WAFを経由せずOriginへ直接到達できれば、どれほど高価なWAFでも迂回される。

  • Origin IPを公開しない
  • CDN/WAFの送信元だけを許可する
  • Private Link、Tunnel、mTLS、署名Headerを使う
  • DNS履歴、証明書透明性、メールHeader、古いSubdomainからOriginを特定できないか確認する
  • 緊急時のBypass手順を管理し、常時開放しない

2. DetectionまたはCountで始める​

最初から全Managed RulesをBlockにしない。

正常通信を一定期間観測し、Rule、Path、Parameter、Client、国、Bot、レスポンスを分解する。高確度のIP reputation、Known bad input、明らかなProtocol違反からBlockへ上げる。

3. 例外を狭くする​

Rule全体を無効化する前に、次の順で狭い例外を検討する。

  1. 特定Rule
  2. 特定Path
  3. 特定ParameterまたはHeader
  4. 認証済みClientまたはmTLS
  5. 特定Botまたは連携先
  6. 一時的なCount

「このPathをAllow」は、その後のWAF検査をすべて飛ばす場合がある。製品の実行順を確認する。

4. Managed Rule更新をリリースとして扱う​

  • 新版の通知を受ける
  • 旧版と新版を並行評価する
  • 影響Ruleと正常通信を確認する
  • 例外とAction overrideを差分管理する
  • Rollbackできる状態で切り替える
  • 期限切れと自動追随を監視する

AWSはStatic version、AkamaiはEvaluation、Azureは更新時のカスタマイズ再確認、CloudflareはRuleset versionとOverrideというように製品差はあるが、考え方は同じである。

5. BotをPath別に設計する​

Path種別推奨する考え方
人間向けHTMLBot score、JS Challenge、CAPTCHAを利用可能
SPA/AJAXInterstitialが壊す可能性を確認し、token統合を優先
モバイルAPIApp attestation、Action token、認証、端末情報、rateを組み合わせる
サーバー間APImTLS、署名、API key、JWT、利用者単位rateを中心にする
RSS・Webhook人間Challengeを使わず、送信元認証と専用rateを使う
検索・監視Bot署名、Reverse DNS、IP list、Verified Bot、Path制限を使う
ログイン・購入Account risk、失敗率、Session、Device、Credential intelligenceを使う

6. WAFを脆弱性管理の代わりにしない​

WAFの仮想パッチは、修正までの時間を稼ぐ。

WAFが攻撃を止めているから、脆弱なライブラリ、認可不備、危険なAPI、古い認証を放置してよいわけではない。Parser差、暗号化されたアプリ内データ、業務ロジック、内部通信、Origin直アクセスでは防御できない。

コストの見方​

クラウドネイティブは安いとは限らない​

ネイティブWAFは初期費用が小さく、従量課金で始めやすい。しかし、高リクエスト、Bot検査、Fraud、ログ、ロードバランサー、DDoS上位契約を足すと費用は増える。

AWSでは、Web ACL、Rule、Request、Bot、Fraud、CAPTCHA、Challenge、Body inspection、Logが費用要因になる。Cloud ArmorはStandardとEnterpriseで、Policy、Rule、Request、Protected resource、Subscriptionが変わる。AzureはFront Door PremiumまたはApplication Gateway WAF v2の基盤費用、処理量、WAF Request、Data transferを含めて見る。

専業WAAPは見積もりだけで比較できない​

Akamai、Cloudflare Enterprise、Impervaは個別見積もりが中心である。

見積もり条件を揃える。

  • 対象FQDN、Application、API、Account、Tenant
  • 月間・ピークRequest、帯域、転送量
  • 地域、PoP、Origin
  • WAF、Bot、ATO、API、Client-side、DDoS、DNS、CDNの範囲
  • L3・L4 Prefix、IP、Always-on/On-demand
  • Log保持、Logpush、SIEM
  • Support、TAM、SOC/SOCC、Managed service
  • 導入支援、移行、PoC、Professional service
  • 超過料金、攻撃時課金、更新時の価格上昇
  • 契約期間、最低利用額、解約とデータ返却

総保有コスト​

製品費用だけでなく、次を含める。

TCO =
  製品・リクエスト・帯域・追加モジュール
  + ログ保存・SIEM
  + 導入・移行
  + チューニングと日常変更
  + 24時間対応
  + 誤遮断による売上・業務影響
  + 攻撃時のクラウド費用
  + ベンダー管理と契約更新

Akamaiは製品費用が高くても、SOCCへ運用を寄せて社内要員を減らせる場合がある。Cloudflareは自社運用しやすいが、Enterprise supportと高度Botを加えると安価とは限らない。ネイティブWAFは従量課金が合理的でも、誤検知対応を各システムチームへ分散すると人件費が膨らむ。

最終評価​

AWS WAF​

「そこそこのクラウド付属WAF」ではない。

マネージドルール、ラベル、Bot、Fraud、Challenge、L7 DDoS、バージョン管理、IaCが揃い、AWS内ではかなり強い第一候補である。弱点は、WCU、優先順位、追加課金、Body上限、API Securityの範囲である。

Google Cloud Armor​

シグネチャ型WAFだけで評価すると過小評価になる。

Adaptive Protection、複合レート制限、JA4、reCAPTCHAを含めると、大規模なL7 DDoSとBotへ強い。弱点は、reCAPTCHA統合の必要性、API Securityの別製品化、ロードバランサー依存である。

Azure WAF​

基本防御は実用水準へ達した。

DRS 2.2、Bot Manager、JS Challenge、レート制限、Azure統合は十分使える。弱点は、Front DoorとApplication Gatewayの差、Botの深さ、ルールセット更新、プレビュー機能である。

Akamai​

重要システムを最高水準で守るなら最有力である。

WAF、Prolexic、Bot Manager、Account Protector、API Security、SOCCの厚みが強い。弱点は、費用、複雑さ、専門家依存、変更速度である。

Cloudflare​

最も使いやすく、最も広く展開しやすい。

防御力、DDoS、Bot、API、IaC、ログ、エッジ処理のバランスがよい。弱点は、プラン差、実行フェーズ、Bot誤判定、サポート、プラットフォーム集中である。

Imperva​

WAF専業として依然として強い。

WAF、Bot、API、クライアント側、データ保護をつなぐ点が独自である。弱点は、操作性、自動化、公開情報、契約の複雑さである。

最終順位​

順位WAF単体技術総合力運用実用性
1AkamaiAkamaiCloudflare
2ImpervaCloudflareAWS WAF
3CloudflareImpervaGoogle Cloud Armor
4AWS WAFAWSAzure WAF
5Google Cloud ArmorGoogle CloudImperva
6Azure WAFAzureAkamai

この表の最下位は「使えない」を意味しない。評価軸が変われば順位も変わる。

単一クラウドの一般システムなら、各クラウドのネイティブWAFが最も合理的である。大規模Bot、API abuse、マルチクラウド、ネットワークDDoS、専門家支援が必要になったところで、Akamai、Cloudflare、Impervaを比較する。

最終的な理解は、次なのだ。

  • クラウドネイティブWAFは、最初に除外する製品群ではなく、最初に評価する製品群になった
  • 専業WAAPの価値は、基本シグネチャではなく、Bot、API、DDoS、クライアント側、データ、運用支援に残る
  • Akamaiは防御力、Cloudflareは運用性、ImpervaはWAFとデータの深さで選ぶ
  • 人気投票、機能一覧、公表容量だけで選ばない
  • 同じ正常通信と攻撃通信を使い、誤検知、回避、ログ、変更、支援、費用をPoCで測る

WAFは、置いた瞬間に完成する防御ではない。

どの製品を選んでも、見えていないBody、Origin直アクセス、正規APIの業務不正、認可不備、アプリケーションの脆弱性は残る。製品名より、検査範囲、例外、更新、観測、責任分界を継続的に管理できるかが最後の差になるのだ。

参考資料​

Footnotes​

  1. AWS, AWS WAF reduces web application security configuration steps and provides expert-level protection（2025-06-17）。https://aws.amazon.com/about-aws/whats-new/2025/06/aws-waf-web-application-security-configuration-steps-expert-level-protection/ ↩

  2. AWS, AWS WAF announces AI activity dashboard for visibility into AI bot and agent traffic（2026-02-24）。650超のBotとAgent追跡を説明。https://aws.amazon.com/about-aws/whats-new/2026/02/aws-waf-ai-activity-dashboard/ ↩ ↩2

  3. Google Cloud, Automatically deploy Adaptive Protection suggested rules。https://docs.cloud.google.com/armor/docs/adaptive-protection-auto-deploy ↩ ↩2

  4. Google Cloud, Rate limiting overview。IP、Header、Cookie、Path、JA3/JA4、User IPなどのキーを説明。https://docs.cloud.google.com/armor/docs/rate-limiting-overview ↩ ↩2

  5. Google Cloud, Bot management overview。Cloud ArmorとreCAPTCHAのAction token、Session token、Exemption cookie連携を説明。https://docs.cloud.google.com/armor/docs/bot-management ↩ ↩2

  6. Microsoft Learn, CRS and DRS rule groups and rules。Application Gateway DRS 2.2がOWASP CRS 3.3.4を基盤とすることを説明。https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules ↩ ↩2

  7. Microsoft Learn, Azure Web Application Firewall JavaScript challenge。Front Door/Application Gatewayの動作とAPI、AJAX、POST等の制約を説明。https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-javascript-challenge ↩ ↩2

  8. Microsoft Learn, Azure Application Gateway WAF exceptions list (preview)。https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-exceptions ↩ ↩2

  9. Microsoft Learn, HTTP DDoS Ruleset in Azure Front Door WAF (preview)。https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/http-ddos-ruleset ↩ ↩2

  10. Cloudflare, 500 Tbps of capacity: 16 years of scaling our global network（2026-04-10）。https://blog.cloudflare.com/500-tbps-of-capacity/ ↩ ↩2

  11. Cloudflare Developers, DDoS Protection overview。全プランの標準L3-L7 DDoS保護とManaged rulesetsを説明。https://developers.cloudflare.com/ddos-protection/ ↩ ↩2

  12. AWS WAF Developer Guide, AWS Managed Rules rule groups list。すべてのAWS Managed Rulesがラベルに対応することを説明。https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html ↩

  13. AWS WAF Developer Guide, Best practices for handling managed rule group versions。https://docs.aws.amazon.com/waf/latest/developerguide/waf-managed-rule-groups-best-practice.html ↩

  14. AWS WAF Developer Guide, AWS WAF Bot Control rule group。Bot分類、Targeted ML、Token reuse、Challenge/CAPTCHA、Web Bot Authenticationのラベルを説明。https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-bot.html ↩

  15. AWS WAF Developer Guide, AWS WAF Fraud Control account takeover prevention (ATP) rule group。https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-atp.html ↩

  16. AWS, Introducing new application layer (L7) DDoS protections for AWS WAF and AWS Shield Advanced customers（2025-06-12）。https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-the-aws-waf-application-layer-ddos-protection/ ↩

  17. AWS, AWS WAF adds support for Amazon Bedrock AgentCore Gateway（2026-06-29）。https://aws.amazon.com/about-aws/whats-new/2026/06/aws-waf-amazon-bedrock-agentcore/ ↩

  18. AWS, AWS WAF Pricing。https://aws.amazon.com/waf/pricing/ ↩

  19. AWS WAF Developer Guide, Considerations for managing body inspection in AWS WAF。統合先ごとの8 KB、16 KB、最大64 KB、gRPC制約を説明。https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-setting-body-inspection-limit.html ↩

  20. Google Cloud, Preconfigured WAF rules overview。最大64 KBの本文検査と制約を説明。https://docs.cloud.google.com/armor/docs/waf-rules ↩

  21. Google Cloud, Request body content parsing。JSONとGraphQL over HTTP解析を説明。https://docs.cloud.google.com/armor/docs/content-parsing ↩ ↩2

  22. Google Cloud, Detect and prevent account-related fraudulent activities on websites。https://docs.cloud.google.com/recaptcha/docs/account-defender ↩

  23. Google Cloud, Cloud Armor pricing。https://cloud.google.com/armor/pricing ↩

  24. Microsoft Learn, Azure Web Application Firewall managed ruleset support policy。2026年2月からのN/N-1/N-2方針を説明。https://learn.microsoft.com/en-us/azure/web-application-firewall/ruleset-support-policy ↩

  25. Microsoft Learn, Configure bot protection for Azure WAF on Application Gateway。https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/bot-protection ↩

  26. Microsoft Learn, Azure Web Application Firewall DRS rule groups and rules。ルールセット版変更時のカスタマイズ再設定に関する注意を記載。https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-drs ↩

  27. Akamai TechDocs, Application Security API。Adaptive Security Engine、Configuration version、API操作を説明。https://techdocs.akamai.com/application-security/reference/api ↩

  28. Akamai, App & API Protector。Adaptive Security Engine、Hybrid、DDoS、API discovery、Terraformを説明。https://www.akamai.com/products/app-and-api-protector ↩

  29. Akamai, Prolexic DDoS Protection。20+ Tbps、32+ Scrubbing center、Zero-second SLA、SOCCを説明。https://www.akamai.com/products/prolexic-solutions ↩

  30. Akamai, Account Protector。https://www.akamai.com/products/account-protector ↩

  31. Akamai, API Security。App & API Protectorとの違いとベンダーニュートラルなAPI可視化を説明。https://www.akamai.com/products/api-security ↩

  32. Cloudflare Developers, WAF Managed Rules。OWASP Score、Body上限、Execution order、Skipを説明。https://developers.cloudflare.com/waf/managed-rules/ ↩ ↩2

  33. Cloudflare Developers, Bot scores。1から99のBot Score、ML、Heuristics、JavaScript Detectionsを説明。https://developers.cloudflare.com/bots/concepts/bot-score/ ↩

  34. Cloudflare Developers, Schema validation。OpenAPI 3.0、Body上限、Schema Validation 2.0を説明。https://developers.cloudflare.com/api-shield/security/schema-validation/ ↩

  35. Cloudflare Developers, Get started with API Shield。Discovery、Schema、JWT、mTLS、Sequence Analytics、GraphQLを説明。https://developers.cloudflare.com/api-shield/get-started/ ↩

  36. Hacker News, Using Cloudflare on your website could be blocking RSS users（2024-10-16）。https://news.ycombinator.com/item?id=41864632 ↩

  37. Hacker News, Tell HN: Impassable Cloudflare challenges are ruining my browsing experience（2025-01-02）。https://news.ycombinator.com/item?id=42577076 ↩

  38. Hacker News, Block AI bots, scrapers and crawlers with a single click（2024-07-03）。第三者連携の誤遮断に関する利用者コメントを含む。https://news.ycombinator.com/item?id=40865627 ↩

  39. Imperva, Web Application Firewall (WAF)。Cloud WAF、WAF Gateway、Elastic WAFを説明。https://www.imperva.com/products/web-application-firewall-waf/ ↩

  40. Imperva, Imperva Application Security Datasheet。https://www.imperva.com/resources/datasheets/Imperva_ApplicationSecurity_Datasheet_2024.pdf ↩

  41. Imperva, Advanced Bot Protection Datasheet。https://www.imperva.com/resources/datasheets/Advanced-Bot-Protection.pdf ↩

  42. Imperva, Account Takeover Protection Datasheet。https://www.imperva.com/resources/datasheets/Account-Takeover-Protection.pdf ↩

  43. Imperva, Imperva API Security Datasheet。https://www.imperva.com/resources/datasheets/Imperva-API-Security-DS_V5.pdf ↩

  44. Imperva, Discover First, Defend Fully（2025-06-03）。https://www.imperva.com/blog/discover-first-defend-fully-the-essential-first-step-on-your-api-security-journey/ ↩

  45. Imperva, DDoS Protection。13 Tbps、L3/L4 3秒SLA、Web/Network/Individual IPを説明。https://www.imperva.com/products/ddos-protection-services/ ↩

  46. Imperva, Data Security。https://www.imperva.com/products/data-security/ ↩

  47. Akhavani et al., WAFFLED: Exploiting Parsing Discrepancies to Bypass Web Application Firewalls（2025）。https://arxiv.org/abs/2503.10846 ↩

  48. Broken Gates: Re-evaluating Web Bot Defenses in the Age of LLM Agents（2026）。Challenge型とTrust型のBot防御をCAPTCHA解決サービスとLLM Agentに対して評価。https://arxiv.org/abs/2607.18659 ↩

  49. Gartner Peer Insights, App & API Protector Reviews and Ratings。2026年7月参照。https://www.gartner.com/reviews/product/app-and-api-protector ↩

  50. Gartner Peer Insights, Cloud Web Application and API Protection Reviews and Ratings。2026年7月参照。https://www.gartner.com/reviews/market/cloud-web-application-and-api-protection ↩

  51. Gartner Peer Insights, AWS WAF Reviews and Ratings。2026年7月参照。https://www.gartner.com/reviews/product/aws-waf ↩

  52. Gartner Peer Insights, Imperva Application Security Platform Reviews and Ratings。2026年7月参照。https://www.gartner.com/reviews/product/imperva-application-security-platform ↩

  53. SecureIQLab, 2024 Cloud WAAP CyberRisk Comparative Validation Report v3.0。https://www.imperva.com/resources/reports/SecureIQLab-2024-Cloud-WAAP-CyberRisk-Comparative-Validation-Report.pdf ↩

  54. SecureIQLab, 2025 Cloud WAAP CyberRisk Validation Report – Imperva Web Application and API Protection。https://www.imperva.com/resources/reports/2025-Cloud-WAAP-CyberRisk-Validation-Report-Imperva.pdf ↩

  55. Reddit r/networking, Seeking Recommendations Best WAF Solution in 2023。CloudflareとAkamaiの導入経験を含む。https://www.reddit.com/r/networking/comments/16zijb7/seeking_recommendations_best_waf_solution_in_2023/ ↩

  56. Reddit r/sysadmin, WAF suggestions - Cloudflare WAF vs Thales Imperva（2026-01-08）。https://www.reddit.com/r/sysadmin/comments/1q7iyha/waf_suggestions_cloud_flare_waf_vs_thales_imperva/ ↩