VPS 上に Web アプリがあるとします。アクセスログには /wp-admin へのログイン試行、クエリ文字列に UNION SELECT を含むリクエスト、そしてあなたのサイトを訪れる理由のないデータセンター IP レンジからの継続的なトラフィックが並んでいます。明らかなゴミは、アプリケーションに届く前に落としたいはずです。
多くの人が WAF SaaS という言葉に出会うのは、たいていこの場面です。読者の多くにとって「WAF」と「Cloudflare」は同義語です。最初に触れたのが Cloudflare だったからです。しかし両者は同じではありません。WAF SaaS はカテゴリ名で、クラウドから提供され、事業者のエッジで HTTP トラフィックを検査してからオリジンへ転送する Web アプリケーションファイアウォールを指します。Cloudflare はそのカテゴリに属する製品の一つにすぎません。
この記事では、WAF SaaS の仕組み、主要ベンダーの料金、実運用でつまずく箇所、そして Linux VPS で自前の WAF を動かすほうが良い場面を順に見ていきます。
要約
- WAF SaaS はクラウドから提供される Web アプリケーションファイアウォールです。トラフィックを事業者経由にするか、WAF を対応クラウドリソースに関連付けます。保護対象のアプリケーションが処理する前に、サービス側が HTTP(S) リクエストを評価します。
- 主要ベンダーの料金体系は大きく三つに分かれます。サブスクリプションの階層（Cloudflare と Sucuri）、従量課金（AWS WAF）、そして営業経由の見積もり（Imperva と Fastly）です。従量課金は処理リクエスト数とオプション機能に応じて増えますが、サブスクリプションは一般に読みやすい費用になります。
- WAF SaaS に対する文書化された批判が存在し、後段でそれに向き合います。指摘されているのはレイテンシ、誤検知、不透明なブロック、そして第三者を経由するデータ経路です。
- VPS 上で自前運用する WAF は現実的な選択肢です。いま勢いのあるオープンソースプロジェクトは SafeLine と BunkerWeb の二つ。どちらもアプリケーションの前段でリバースプロキシとして動きます。
- アプリケーションのセキュリティが成熟し、露出が管理され、監視が行き届き、残るリスクを文書化して受け入れているなら、WAF を置かないという選択も十分に筋が通ります。
WAF SaaS の仕組み
example.com へのリクエストは、DNS がそちらを向いているため、まず事業者のエッジに届きます。エッジノードは TLS を終端し、HTTP リクエストを解析してルールエンジンにかけ、オリジンへ転送するか、ブロックするか、チャレンジ（CAPTCHA や JavaScript テスト）を出すか、送信元をレート制限します。転送される場合、アプリケーションから見るとリクエストは事業者の IP から来たように見え、元のクライアント IP は X-Forwarded-For や CF-Connecting-IP のようなヘッダーで渡されます。
多くの WAF SaaS 製品は、事業者が運用するリバースプロキシやエッジ統合を用いますが、すべてのサービスが DNS 変更で導入されるわけではありません。Cloudflare、Sucuri、Fastly は通常エッジのリクエスト経路上に置かれます。一方 AWS WAF は CloudFront や、 サポート対象の AWS リソース Application Load Balancer、API Gateway の API、AppSync の API といったサポート対象リソースに関連付けられます。いずれの場合も、保護対象のアプリケーションが処理する前に HTTP(S) リクエストが評価されます。
WAF はリクエストヘッダー、パス、クエリ文字列、メソッド、Cookie、そして設定した範囲のリクエストボディといったレイヤー 7 のデータを検査します。従来のネットワークファイアウォールは主にレイヤー 3 と 4 で、アドレス・プロトコル・ポートをもとに判断します。 ハードウェアとソフトウェアのファイアウォール比較ガイド で、より広い違いを解説しています。
マネージド WAF の防御は、通常三つのルールソースから成り立っています。
- OWASP Core Rule Set （CRS）は、ModSecurity と互換 WAF エンジン向けのオープンソースのベースラインです。SQL インジェクション、クロスサイトスクリプティング、コマンドインジェクション、ローカルファイルインクルージョンといった代表的な攻撃カテゴリをカバーします。ModSecurity をベースにした製品は CRS を同梱することが多い一方、多くのクラウド事業者は独自のマネージドルールを使っています。
- ベンダー管理のルールセットは、事業者が最新に保つ独自ルールです。Cloudflare の「Managed Rules」、AWS WAF の「AWS Managed Rules」、Imperva の脅威インテリジェンスフィードはいずれもここに含まれます。
- カスタムルールは自分で書くルールです。「この IP レンジ以外からの /admin へのリクエストをブロックする」「/api/login を IP ごとに毎分 5 回に制限する」といったものです。
SQL インジェクション用のルールは、クエリパラメータやリクエストボディに含まれる ' OR 1=1 -- のような典型的なパターンを検出できます。これで手抜きの探索は捕まりますが、難読化されたペイロード、ロジックの欠陥、通常のアプリケーショントラフィックに見える悪意あるリクエストは WAF でも取りこぼし得ます。WAF が評価するのは観測可能なリクエストのシグナルであって、業務上の意図ではありません。
これが防いでくれるもの、平たく言えば次の通りです。
- ペイロードが既知のシグネチャに一致するインジェクション攻撃
- 既知のスキャナーからのボットトラフィック
- 単純なブルートフォースのパターン
- ボリューム型 DDoS（事業者が DDoS スクラビングも提供している場合）
- 基本的な API の悪用
できないことは次の通りです。
- アプリケーションにパッチを当てること
- コード側の入力バリデーションを肩代わりすること
- 通常のトラフィックに見える攻撃を止めること
アプリケーションのセキュリティは、依然としてアプリケーション自身から生まれます。WAF は一般的・自動化された攻撃に対する床を上げますが、天井を決めるのは安全なコーディング、パッチ適用、認可、入力処理、監視、インシデント対応です。
WAF SaaS、オンプレのアプライアンス、VPS での自前運用の比較
2026 年の WAF の導入形態は大きく三つです。クラウドの WAF SaaS（Cloudflare、AWS WAF、Fastly など）、物理または仮想のアプライアンス（F5 や Imperva の製品を含む）、そして VPS や自社サーバー上で自前運用するソフトウェアです。
三つの違いは、四つの実務的な問いに集約されます。検査基盤を運用するのは誰か、キャパシティの費用を負担するのは誰か、ルールを調整するのは誰か、そして WAF が本来止めるべきでないものを止めたときどうなるか。以降はこの四つを比較の軸として使います。
クラウドの WAF SaaS
トラフィックを事業者のエッジ経由にするか、WAF を対応クラウドリソースに関連付けます。検査キャパシティとマネージド更新は事業者が運用し、あなたはルールの選択、アプリケーション固有ポリシーの作成、例外の調整を担当します。よく使われる選択肢は Cloudflare、AWS WAF、Imperva、Sucuri、Fastly です。
トレードオフはこうです。キャパシティと運用は他人の問題になりますが、その代わり HTTP リクエストのすべてが他人のインフラを通ります。あなたの HTTP トラフィックは事業者のインフラを経由し、リクエストのメタデータやルールに一致したペイロードの一部は、事業者・製品・ログ設定によっては記録されます。
オンプレのアプライアンス WAF
物理または仮想のアプライアンスをネットワーク経路上に配置します。買い手は通常、ネットワークセキュリティ運用が確立している組織、固定のキャパシティ要件がある組織、厳格な導入統制がある組織、あるいは既存のベンダー関係がある組織です。キャパシティ、アップグレード、高可用性、チューニングは引き続き顧客側の責任です。
中小規模のチームの多くにとっては、アプライアンスの調達、固定キャパシティ、運用負荷が重なり、これが最も現実味の薄い選択肢になります。それでも、ネットワーク内部に制御基盤が必要で、運用できる人員を抱える組織には合う場合があります。
自分の VPS で自前運用する WAF
Linux の VPS に WAF を入れ、DNS をその VPS に向けると、WAF はアプリケーションの前段でリバースプロキシとして動きます。運用するのはあなたです。チューニングするのもあなたです。マネージドルールの更新が正当なリクエストを止めてしまい、他に電話する相手がいない午前 2 時にログインするのもあなたです。
いま勢いのあるオープンソースプロジェクトは二つです。正規表現マッチではなく意味解析エンジンを用いるオープンソース WAF の SafeLine と、ModSecurity を同梱する NGINX ベースの WAF である BunkerWeb です。ライセンス、導入形態、リソース消費については、後半の自前運用のセクションで扱います。
トレードオフは SaaS モデルの裏返しです。検査基盤、キャパシティ、ログ、チューニングをあなたが握ります。第三者の WAF 事業者への依存は減りますが、上流ネットワークやホスティング事業者が回線を運んでいる点は変わりません。インフラの上限、帯域、パッチ適用、インシデント対応は、いまやあなたの責任です。
SaaS の WAF と、自分の VPS で自前運用する WAF の比較
下の比較表は、システム管理者が実際に運用し、予算を組む必要のある違いに絞っています。
| 基準 | クラウド SaaS の WAF | VPS で自前運用する WAF |
|---|---|---|
| 検査基盤を運用するのは誰か | 事業者（ネットワークのエッジ） | あなた（自分の VPS 上） |
| キャパシティの費用を負担するのは誰か | 事業者（サブスクリプションまたはリクエスト単位であなたに請求） | あなた（VPS の固定費） |
| ルールを調整するのは誰か | 設定はあなた、マネージドルールの更新は事業者 | あなたが最初から最後まで |
| 誤検知が起きたときの打ち手 | 事業者が用意した範囲でルールと例外を調整し、プラットフォーム側の問題はエスカレーションする | ルールを自分で書き換え、数分で再デプロイする |
| データの経路 | リクエストは事業者の検査インフラを通る | リクエストはオリジンに届く前に、あなたが管理するインフラを通る |
| トラフィック急増時のコストの動き | 従量課金の部分はリクエスト量に応じて増える可能性がある | おおむね読みやすいが、帯域とスケーリングで費用が増えることはある |
| 運用負荷 | 低い（設定とチューニングにとどまる） | VPS も WAF もあなたが運用する |
2026 年の WAF SaaS 料金
WAF SaaS の料金は通常、サブスクリプションの階層、従量課金、営業経由の見積もりを組み合わせたものです。公開価格をそのまま比較することはできません。マネージドルール、ボット対策、ログ、サポート、DDoS 機能のまとめ方が事業者ごとに違うからです。
| プロバイダー | 料金モデル | 最低料金 | エントリープランに含まれるもの | 注意事項 |
|---|---|---|---|---|
| Cloudflare | サブスクリプションの階層 | 無料。Pro は年払いで月 20 ドル、月払いで月 25 ドル。Business は年払いで月 200 ドル、月払いで月 250 ドル | Free Managed Ruleset。より広範な制御は有料プランによって異なる | 購入前に、現在のルール、上限、含まれるセキュリティ機能を確認すること |
| AWS WAF | リクエスト単位 | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | 自己管理のルール。AWS Managed Rules はマネージドルールグループとして追加可能 | 追加キャパシティ、ボディ検査、プレミアムのマネージドグループ、CAPTCHA、Challenge、Bot Control、Fraud Control は追加課金になり得る |
| Imperva | エンタープライズ見積もり | お問い合わせ | マネージドルール、脅威インテリジェンス、API セキュリティのオプション | 直接比較できる公開のセルフサービス WAF 価格はない |
| Sucuri Platform | サブスクリプションの階層 | Basic Firewall は月 9.99 ドル、Basic Platform は年 229 ドル | firewall プランは WAF/CDN。Platform バンドルはスキャンとクリーンアップを追加 | 単体のファイアウォールと年額の Platform バンドルは別製品 |
| Fastly | 営業経由 | お問い合わせ | エッジまたは分散型の検査、マネージドルール、API 保護 | 直接比較できる公開のセルフサービス WAF 価格はない |
AWS WAF はコンポーネント単位の価格を公開し、Cloudflare と Sucuri はセルフサービスのプラン価格を公開しています。Imperva と Fastly は、同等の WAF 製品について営業経由の価格設定をとっています。
2026 年 7 月 29 日時点の確認では、 Cloudflare のプラン料金ページ では Pro が年払いで月 20 ドル、月払いで 25 ドル、Business が年払いで月 200 ドル、月払いで 250 ドルと記載されています。 Sucuri のファイアウォール料金ページ lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from AWS WAF の料金 as of the same date.
Imperva と Fastly は直接比較できるセルフサービスの WAF 価格を公開していません。第三者の推定値に頼らず、どちらも営業に問い合わせる選択肢として扱ってください。
AWS WAF の料金ページ には、基本料金として web ACL 1 つあたり月 5 ドル、ルールまたはルールグループ 1 つあたり月 1 ドル、処理リクエスト 100 万件あたり 0.60 ドルが記載されています。追加キャパシティ、より大きなボディ検査、CAPTCHA や Challenge のアクション、プレミアムのマネージドグループ、不正対策やボット対策には追加料金がかかることがあります。したがって攻撃トラフィックは請求額を押し上げ得ますが、その影響は量・継続時間・有効にした機能によって変わります。レートベースのルールはアプリケーションを守りますが、すでに処理された WAF リクエストが無料になるわけではありません。
WAF SaaS が力不足になるところ
実務上の第一の限界は誤検知です。正当なファイルアップロード、API 呼び出し、フォーム送信が攻撃パターンに似てしまい、マネージドルールを踏むことがあります。運用側はそのとき、一致したルールを特定し、範囲を狭めるか例外にし、その例外がより広い抜け道を作っていないことを確認しなければなりません。
WAF はリクエストのシグナルから判断するのであって、業務上の意図から判断するわけではありません。厳しいルールは正当なトラフィックを止め得ますし、広すぎる例外は防御を弱めます。クラウドサービスはたいていイベントログ、ルールの上書き、カスタムレスポンスを提供しますが、得られる可視性やチューニング手段はプランと事業者によって差があります。
プロのコツ。 新しいルールや大きく変更したルールは、まず検知モードまたはカウントモードで動かしてください。実際に近いトラフィックを観察し、重要なワークフローと使用頻度の低いワークフローの両方をテストし、誤検知を洗い出し、範囲を絞った除外を加えてからブロックを有効にします。 現行の CRS チューニングガイダンス は 1 ～ 2 週間、あるいはピーク時のトラフィックと重要なワークフローを一通り通し終えるまでを推奨しています。
第二の限界は性能面のオーバーヘッドです。 2023 年の ModSecurity ベンチマーク では、小さなファイル 9,462 件のアップロードが CRS 有効時に 7.36 秒、無効時に 4.55 秒でした。スループットは毎秒 2,079 リクエストから 1,285 に落ち、nginx の CPU ピークは 8 % から 73 % に上がりました。これは一つの構成、一つのワークロードでの結果です。検査にコストがかかる証拠として受け取るべきで、汎用のサイジング比率として使うものではありません。
第三の限界はデータの経路です。リクエストボディを含むすべての HTTP リクエストが、事業者のインフラを通過します。個人情報、金融取引、医療データを扱うアプリケーションにとって、これは具体的なデータ主権の問題です。EU でホストしているアプリケーションが顧客のリクエストを米国の WAF 事業者経由にすると、同じ法域の VPS で自前運用するリバースプロキシを使う場合に比べ、説明すべき監査証跡は重くなり、合意すべき契約条項もいくつか増えます。
第四の限界はチューニングの負荷です。 WAF チューニングの課題 には、誤検知、限られたアプリケーション文脈、そして頻繁なコード変更に追随し続けなければならないルールが含まれます。出典はベンダー視点ですが、そこで描かれる運用パターンは現実のものです。チームは継続的なチューニングに投資するか、より多くのルールを検知のみの状態で放置するかのどちらかになります。
同じ 2023 年の批判は、チームがアプリケーションを直す代わりに WAF に頼るとき、WAF はセキュリティシアターになり得ると論じています。この主張が最も当てはまるのは、アプリケーションセキュリティが成熟したチームです。パラメータ化されたデータベースアクセス、堅い認可、定期的な依存関係スキャン、イミュータブルなデプロイ、機能する監視がそろっている場合です。一方、成熟度の低い環境では、WAF はありふれた自動探索への露出を確かに減らします。どちらも同時に正しくあり得ます。
WAF は多層防御の一つの層です。アプリケーションセキュリティの代わりにはなりませんし、セキュリティシアターでもありません。WAF の限界価値は、チームによって高くも低くもなります。決め手は、その下にあるアプリケーションがどういう状態かです。
WAF を自前運用する意味があるのはどんなときか
自前運用が有利になる場面は三つ、不利になる場面も三つあります。まず有利なほうから。
自前運用が有利になるのは、社内方針やデータ主権上の制約から外部の WAF SaaS 仲介者による検査が認められない場合、トラフィックの性質上、従量課金より専用インフラを回すほうが得な場合、そしてブロックの判断と誤検知の修正をチームが直接握りたい場合です。
自前運用が不利になるのは、運用にあてる人手がない場合、アプリケーションがマネージドプラットフォーム上にあり、そのルーティング方式のせいで外部プロキシを挟むのが面倒な場合、そして事業者のマネージド無料プランで必要な制御をより少ない複雑さで満たせてしまう場合です。
Cloudflare の無料プランは、すでに同社の DNS や CDN を使っていて、そのトラフィック検査モデルを受け入れられる中小規模のチームにとって実用的な出発点になり得ます。自前運用が優位に立つのは、データの経路、ルールの直接制御、予測しやすいインフラ費用のほうが、運用の手間を最小化することより重くなったときです。
SafeLine と BunkerWeb
自前運用できるオープンソースの WAF で、知っておく価値があるのは二つです。
SafeLine は GPL-3.0 ライセンスで、Docker Compose でデプロイし、純粋な CRS ルールセットではなく意味解析を軸に組み立てられています。 SafeLine のリポジトリ は Balance モードで検知率 71.65 %、誤検知率 0.07 %、総合精度 99.45 % を、自前の 33,669 サンプルの評価として報告しています。これはプロジェクトのメンテナーによる計測であって独立したベンチマークではなく、そのテストセットを超えて一般化すべきではありません。
BunkerWeb は AGPL-3.0 ライセンスで、内部では NGINX を使っています。ModSecurity を OWASP Core Rule Set とともに統合し、Linux、Docker、Swarm、Kubernetes を含む複数の導入形態に対応します。
どちらのプロジェクトも、実測したリクエスト量、有効にした保護機能、TLS の処理量、ログ保持期間からサイジングしてください。トラフィックの少ない SafeLine 構成なら、2 vCPU と 4 GB のメモリがインストール最低要件より余裕のある堅実な出発点になります。 現行の BunkerWeb クイックスタートガイド は、テストやごく少数のサービス向けに最低 2 vCPU と 8 GB のメモリを、多数のサービスを守る本番環境には 4 vCPU と 16 GB のメモリを推奨しています。ストレージはおおむねログの発生量と保持期間で決まるため、固定の保持月数を約束せず、実測してください。
プロのコツ。 自前運用の WAF は、可能な限りアプリケーションのオリジンと同じリージョンで動かしてください。遠いプロキシはリクエストごとにリージョン間のネットワーク往復を足し、レイテンシを静かに悪化させます。本番切り替え前に、ユーザーのいるリージョンからエンドツーエンドの応答時間を測っておきましょう。
WAF を運用するのはあなた自身なので、その下のインフラもあなたの責任になります。稼働率、セキュリティパッチ、TLS 証明書、バックアップ、ログローテーション、監視、キャパシティ、そして復旧です。WAF が単一障害点にならないよう、障害時の挙動をフィルタルールと同じくらい入念にテストしてください。
意思決定フレームワーク
道は四つあります。Cloudflare の無料プラン、有料のクラウド WAF SaaS、VPS 上の自前運用 WAF、そして WAF を置かないという選択です。どれを選ぶかを決める条件は、それぞれ違います。
利用できるマネージドルールと上限がアプリケーションのリスクに見合い、データの経路のあり方が許容でき、運用の手間を最小にすることが最優先なら、無料のクラウド WAF プランを選んでください。既定値で十分と決めつける前に、実際のワークフローをテストしましょう。
無料プランより多くのマネージドルール、ログ、独自の制御、ボットや API の保護、サポート、キャパシティが必要なら、有料の WAF SaaS を選んでください。プラン名だけでなく、機能と上限の正確な一覧を比較しましょう。AWS WAF が最も力を発揮するのは、アプリケーションがすでに対応 AWS リソースを使っていて、チームがコンポーネント単位の課金を見積もることに慣れている場合です。
先に挙げた自前運用の条件が当てはまり、チームがプロキシを安定して運用できるなら、自前運用の WAF を選んでください。まず評価すべき二つのプロジェクトは SafeLine と BunkerWeb です。
アプリケーションのセキュリティが成熟し、露出を意図的に絞り、監視が行き届き、残余リスクを文書化して受け入れているなら、WAF を置かないことは十分に筋の通った選択です。ただし、フレームワークが入力を検証しているというだけの理由で既定の選択にしてはいけません。
結論
事業者がキャパシティを持ち、運用の手間を減らしたいなら WAF SaaS を。直接の制御が欲しく、チームがプロキシを安定運用できるなら自前運用を選んでください。どちらのモデルでも、ルールは段階的に投入し、レイテンシと誤検知を計測し、アプリケーションのセキュリティを最優先に据えることです。
自前運用が要件に合うなら、まずはオリジンと同じリージョンの Linux VPS から始めてください。Cloudzy はワンクリックのマーケットプレイス配備も用意しています。対象は SafeLine と BunkerWebです。基盤スタックを手作業で組まなくても、すぐにテストを始められます。
root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。
Linuxプランを見るよくある質問
WAF as a Service とは何か
WAF as a Service は、クラウドから提供される Web アプリケーションファイアウォールです。トラフィックは DNS またはリバースプロキシによる経路指定、エッジ統合、あるいは対応クラウドリソースへの関連付けを通じてサービスに届きます。検査キャパシティとマネージド更新は事業者が運用し、ポリシーの選択、例外の調整、アプリケーション固有ルールの追加はあなたが担当します。
Cloudflare は WAF なのか
はい。Cloudflare は、DNS、CDN、DDoS 対策も含む広いエッジプラットフォームの一部として WAF 機能を提供しています。無料プランには Cloudflare Free Managed Ruleset が付きます。より広範なルールセット、各種制御、分析、ボット管理の機能は、選んだプランとアドオンによって変わります。
Cloudflare の無料 WAF で足りるのか
アプリケーションの攻撃面、必要なルール、ログと保持の要件、API やボットの制御、サポート要件、そして誤検知への許容度によります。Free Managed Ruleset は有用な土台になり得ますが、認証、決済、規制対象データがあるからといって自動的に特定の有料プランに対応づくわけではありません。現時点の機能上限を比較し、自分たちの脅威モデルに照らして検証してください。
WAF と一般的なファイアウォールの違いは何か
従来のネットワークファイアウォールは、主にレイヤー 3 と 4 の情報、つまりアドレス、プロトコル、ポートでトラフィックを選別します。WAF はレイヤー 7 の HTTP(S) リクエストを、設定したヘッダー、パス、パラメータ、ボディの内容まで含めて評価します。最近のセキュリティ製品はこの境界を曖昧にすることがありますが、両者は置き換え可能ではなく、補い合う関係のままです。
WAAP とは何か、WAF とどう違うのか
WAAP は Web Application and API Protection の略です。従来の WAF より広い概念で、ベンダーは通常、WAF ルールに API の検出や適用、ボット管理、アプリケーション層の DDoS・不正利用対策を組み合わせて提供します。実際の中身は事業者ごとに異なるため、WAAP を標準化された機能セットのように扱ってはいけません。
フレームワークが入力検証をしているなら WAF は必要か
常に必要とは限りません。フレームワークの検証はリスクを下げますが、自動化された悪用のパターンすべてを塞げるわけではありません。WAF を足すのは、そのコストとチューニングの手間に見合う、はっきり定義されたリスクに対処できるときだけにしてください。
