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

WAF・WAAP 6製品の選定条件とPoC

文書番号：2607.00002

要旨​

AWS WAF、Cloud Armor、Azure WAF、Akamai、Cloudflare、Impervaを、配置できる場所、検査範囲、Bot/API、変更管理、運用支援という条件で比較するのだ。2026年7月24日時点の資料を整理した時点記録であり、同一通信による検知性能の実測比較ではないのだ。

総合順位は付けず、保護対象と運用条件から候補を絞り、同じ正常通信・攻撃通信・変更作業を使うPoCで判断するのだ。各製品の契約、版、提供範囲は採用時に公式資料で再確認するのだ。

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

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への展開性

評価軸は仕様と適用範囲を照合するための問いなのだ。算出を再現できない点数や一律の順位へ変換せず、必要条件を満たすかとPoCの結果を分けて記録するのだ。

情報源の扱い​

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

  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インジェクションを止められるか」ではないのだ。

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

AWS WAF​

現在の位置付け​

AWS WAFはAWSの公開入口へ適用する候補として、対象サービスと検査要件から評価するのだ。

以前は、文字列一致、正規表現、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はラベルに対応しているのだ。10

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

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

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

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

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

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

L7 DDoSがWAF内へ入った​

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

これにより、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にも対応したのだ。15

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ルールは別の費用要因になるのだ。公式料金表は透明だが、高トラフィック環境の請求額が直感的とは限らないのだ。16

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

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

大きな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を解析してルールを適用できるのだ。1819

シグネチャ感度を調整し、個別シグネチャやリクエストフィールドを除外できるのだ。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を併用すれば、ログインやチェックアウトの不審な行動も別途評価できるのだ。20

弱み​

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へ入る条件もあるのだ。21

トラフィック量、バックエンド数、リージョン、ロードバランサー費用、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月リリースとして扱われているのだ。22

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

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する機能が中心とされているのだ。23

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の公式ドキュメントは、ルールセットのバージョン変更時に既存カスタマイズが新バージョンの既定値へリセットされると明記するのだ。24

更新前に、無効化、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の大規模なエッジ観測、脅威情報、攻撃パターン、自己調整を利用し、ルールと攻撃グループを更新するのだ。2526

次の運用機能が揃うのだ。

  • 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単位保護へ対応するのだ。27

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

Botとアカウント保護​

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

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

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

API Security​

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

この二層構造により、インライン遮断と、企業全体の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の実行順を意識して制御するのだ。30

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

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

DDoS​

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

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

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は評価されないのだ。30

正規利用者と正規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は既定で無効の場合があり、最初に有効化する必要があるのだ。19

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、インシデント対応を別途設計するのだ。

選定フロー​

WAF・WAAPの候補群を構成と比較PoCの観点で整理した表

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、クライアント側、データ保護をつなぐ点が独自であるのだ。弱点は、操作性、自動化、公開情報、契約の複雑さであるのだ。

条件に基づく選定の結論​

単一クラウドの公開入口を守る候補と、複数環境・高度なBot対策・専門家支援をまとめる候補を分けるのだ。公表容量、評判、機能数だけで性能や運用適性を確定せず、検査上限、誤検知、解除、変更、支援、費用を対象環境で評価するのだ。

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. 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 ↩

  11. 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 ↩

  12. 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 ↩

  13. 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 ↩

  14. 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/ ↩

  15. 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/ ↩

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

  17. 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 ↩

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

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

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

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

  22. 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 ↩

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

  24. 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 ↩

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

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

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

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

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

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

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

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

  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/ ↩