WAFとは｜仕組み・種類とファイアウォールとの違い・運用のコツ

WAFとは｜アプリケーション層を守る仕組み

WAFは、Webサーバーやロードバランサーの手前に配置され、通過するHTTPリクエストとレスポンスの中身を検査します。IPアドレスやポート番号だけでなく、URLのパラメータ、POSTされた本文、Cookie、ヘッダーといった「アプリケーションに渡る値」まで見るのが特徴です。

条件としては、検査対象がHTTP/HTTPS通信であること。例外として、HTTPS通信を検査するにはWAF側でTLSを終端するか、復号した通信を渡す構成が必要になります。この点は構成設計で最初に決める論点です。

リクエストが検査される流れ

利用者のブラウザからのリクエストは、おおよそ次の順で処理されます。

1. DNSやCDN経由でWAFにリクエストが到達する

2. WAFがルールに照らしてリクエストを評価する

3. 許可・ブロック・CAPTCHA表示・レート制限などのアクションが決まる

4. 許可された通信だけがWebサーバーとアプリケーションに届く

5. 判定結果がログに記録される

4と5の順序は製品によって前後しますが、「評価してからアクションを決め、判定結果をログに記録する」という骨格は多くの製品で共通しています。

シグネチャとルールセットの関係

WAFの判定基準は、攻撃パターンを記述した「シグネチャ」の集合です。シグネチャを体系的にまとめたものがルールセットで、代表例としてOWASP Core Rule Set（CRS）があります。CRSはオープンソースで公開されており、多くの商用WAFもこれに相当するマネージドルールを用意しています。

ルールセットには「スコアリング方式」を採るものもあります。1つの条件に当たっただけでは遮断せず、複数の疑わしい要素が積み上がって閾値を超えたらブロックする方式です。誤検知を減らす狙いがあります。

攻撃カテゴリの全体像をつかみたい場合は、OWASP Top 10とは｜Webアプリの主要リスク10カテゴリ解説が参考になります。WAFのルールは、ここで整理されているリスクのうち、通信パターンとして検出できるものを主な対象にしています。

ファイアウォールやIDS/IPSとの違い

結論として、三者は競合する製品ではなく、守る層が違うため併用して考えるのが一般的です。

ファイアウォールは送信元IP・宛先IP・ポート番号を判断材料に、通信の入口を開け閉めします。IDS/IPSはOSやミドルウェアを狙った不正アクセスの検知・遮断を得意とします。WAFはその先、アプリケーションに渡る値そのものを見ます。

守備範囲の比較表

80番と443番ポートは、Webサービスである以上開けておく必要があります。そこを通ってくる攻撃はファイアウォールでは止まりません。WAFが必要になる理由はここに尽きます。

なお、境界で守る発想そのものを見直す考え方についてはゼロトラストとは｜境界型との違い・主要技術・案件動向を解説で扱っています。

ミニFAQ：ファイアウォールがあればWAFは不要ですか。

いいえ。ファイアウォールは443番ポートを開けたうえで通信を通すため、その中身にSQLインジェクションのペイロードが入っていても判断材料を持ちません。役割が重ならないため、どちらかで代替する設計にはなりません。

WAFで防げる攻撃と防げない攻撃

WAFが得意なのは、リクエストの文字列パターンとして現れる攻撃です。逆に、正規のリクエストと見分けがつかない攻撃は苦手になります。

ただし、実際にどこまで検知・遮断できるかは製品とルール設定によって変わります。以下は一般的な傾向であり、同じ攻撃名でも有効にしているルールセットやチューニングの内容で結果は変わると考えてください。

防げる攻撃の代表例

• SQLインジェクション：入力値にSQL文の断片が混ざるパターンを検出します。仕組みはSQLインジェクションとは｜仕組み・主要攻撃4種・実装対策と検知方法で詳しく解説しています

• クロスサイトスクリプティング：スクリプトタグやイベントハンドラ属性の混入を検出します。対策の全体像はXSSとは｜仕組み・3種類の攻撃・実装対策とCSP設計を参照してください

• ディレクトリトラバーサル、コマンドインジェクション

• 既知の脆弱性を狙う定型的なスキャン通信

• 同一IPからの過剰なリクエスト（レート制限ルールを使う場合）

WAFだけでは防ぎきれない領域

ここを誤解すると、導入後の事故につながります。

認可設計の不備は、WAFでは検出が困難です。ログイン済みの利用者が、他人のIDを指定して自分の権限外のデータを取得する。このリクエストは文法上まったく正常で、攻撃パターンとして記述できません。

同様に、業務ロジックの悪用（割引の重複適用、在庫の不正確保など）もWAFの範囲外です。ID/パスワードリスト攻撃も、1回ごとのリクエストは正常な形をしているため、レート制限やデバイス情報と組み合わせた判定が必要になります。

そもそもWAFは、アプリケーション側の脆弱性を修正する製品ではありません。修正パッチの適用までブロックで時間を稼ぐ、いわば仮の包帯です。IPAのWeb Application Firewall 読本でも、WAFは脆弱性対策の代替ではなく補完として位置づけられています。

検出した脆弱性にどう優先順位をつけるかは、CVSSとは｜脆弱性の深刻度評価と対応優先度の決め方で整理しています。

WAFの種類3つと選び方

導入形態は大きく3つに分かれます。どれを選ぶかで、初期費用・運用負荷・カスタマイズ性のバランスが変わります。

クラウド型（サービス型）

事業者が提供するWAFをサービスとして利用する形態です。DNSを切り替えるか、CDNの機能として有効化するだけで使い始められます。シグネチャ更新は提供側が担当するため、運用負荷は比較的軽くなります。

一方、通信が事業者を経由するため、金融・公共系など通信経路に制約がある案件では採用できないことがあります。

アプライアンス型

専用のハードウェアを自社ネットワーク内に設置します。通信が外部を経由せず、処理性能も見積もりやすい形態です。大規模なオンプレミス環境や、通信要件が厳しい環境で選ばれます。

初期費用と設置・保守の手間は3つの中で大きくなります。

ソフトウェア型（ホスト型）

WebサーバーにモジュールとしてWAFを組み込みます。代表例はApacheやNginxで動作するModSecurityで、OWASP CRSと組み合わせて使う構成が知られています。サーバー単位で細かく設定できる反面、台数が増えるとルール管理の手間も増えます。

選び方の判断軸

ミニFAQ：CDNのWAF機能と専用WAF製品は何が違いますか。

CDNに付属するWAFは配信経路上で検査するため追加の構成変更が少なく済みます。専用製品はルールの記述自由度やレポート機能が厚い傾向があります。要件がマネージドルールの範囲で足りるならCDN付属、独自ルールを多数書くなら専用製品、という切り分けが実務的です。

主要WAF製品・サービスの特徴

ここでは代表的な選択肢を挙げます。仕様と料金は改定されるため、採用前に各公式ページで最新の内容を確認してください。

AWS WAF

CloudFront、Application Load Balancer、API Gatewayなどに関連付けて使うクラウド型です。AWSが提供するマネージドルールのほか、サードパーティのルールも利用できます。詳細な仕様はAWS WAF 開発者ガイドにまとまっています。

料金は従量課金です。AWS WAFの料金ページに記載されている構成は、執筆時点（2026年10月）で確認した範囲ではWeb ACL 1つあたり月5.00 USD、ルール1つあたり月1.00 USD、リクエスト100万件あたり0.60 USDとなっています。料金体系とリージョンごとの条件は改定されるため、試算の前に公式料金ページで現在の金額を確認してください。

コスト面で見落とされやすいのがWCU（Web ACL Capacity Unit）です。同じく執筆時点の公式料金ページでは1,500 WCUがデフォルト枠とされ、これを超える分について500 WCUごとにリクエスト100万件あたり0.20 USDが加算される旨が記載されています。マネージドルールを何種類も有効にするとWCUが積み上がるため、ルールを追加するときは課金への影響もあわせて確認しておくと安全です。

Cloudflare WAF

CDNと一体で提供される形態です。マネージドルールセットとレート制限を組み合わせて使う構成が一般的で、Cloudflare WAFの公式ドキュメントに設定手順が公開されています。プランによって利用できるルールの範囲が変わる点には注意が必要です。

CDNとしての特徴や案件動向はCloudflareとは｜CDN・セキュリティ・Workersの特徴と案件動向で扱っています。AWS側のCDNについてはCloudFrontとは｜AWSのCDNの仕組み・料金・案件単価をエンジニア向けに解説が参考になります。

ModSecurity＋OWASP CRS

オープンソースの組み合わせです。ライセンス費用がかからない反面、ルールの適用とチューニング、シグネチャの追従をすべて自前で担当します。ModSecurity本体はメンテナンス体制が変遷してきた経緯があるため、採用時は公式リポジトリでサポート状況を確認しておくと安全です。

国産のクラウド型サービス

日本語のサポートとレポートを重視する現場では、国内事業者が提供するクラウド型WAFが選ばれることもあります。管理画面やレポートが日本語で、誤検知の問い合わせ対応を日本語で行える点が採用理由になりやすい領域です。

WAF導入の進め方｜検知モードから始める5ステップ

いきなり遮断モードで本番に入れると、正常なリクエストまで止まります。管理画面のリッチテキスト入力やファイルアップロードは、シグネチャに引っかかりやすい代表例です。

実務では次の手順がよく採られます。所要期間はサービスの規模・リリース頻度・トラフィックの季節変動によって変わるため、下記はあくまで目安です。

1. 保護対象の洗い出し（1〜3日）：対象ドメイン、API、管理画面を一覧化します。管理画面は誤検知が出やすいため、別ルールにするか除外するかを最初に決めます

2. 検知のみモードで適用（初日）：AWS WAFならアクションをCount、他製品でも「検知のみ」に相当する設定でルールを有効にします。この段階では、検知のみに設定したルールによる遮断は行われません

3. ログの観察（2〜4週間）：どのルールがどれだけ反応したかを確認します。月初・月末のバッチ処理やキャンペーンなど、通常と違う通信が発生する時期を1周できる長さが目安です

4. 誤検知ルールの調整（1〜2週間）：反応が多いルールについて、特定パスの除外やパラメータ単位の除外を設定します

5. 段階的にブロックへ切り替え（1〜2週間）：全ルールを一度に切り替えず、誤検知の少ないルールから遮断を有効にします

着手から本番ブロックまで、おおむね1〜2か月を見込んでおくと無理がありません。短縮したい場合でも、ステップ3を1週間未満にするのは避けたほうが安全です。週次バッチのような頻度の低い処理を観測し損ねます。

Countモードから始めて誤検知を回避する進め方は、DMM Developers Blogの導入事例でも実践例として公開されています。

誤検知対策と運用の落とし穴

WAF運用でもっとも時間を使うのは、誤検知（フォールスポジティブ）の調整です。

誤検知が起きる理由

シグネチャは「攻撃に見える文字列パターン」で判定します。したがって、正常な業務データがたまたまそのパターンに一致すると遮断されます。

よくあるのは次のような場面です。CMSの記事本文にHTMLタグやスクリプトの説明を書いた。問い合わせフォームにシングルクォートを含む氏名が入力された。技術系サービスで、ユーザーがSQLの質問文をそのまま投稿した。いずれも攻撃ではありませんが、ルールは反応します。

チューニングの基本手順

調整は、広く緩めるのではなく狭く除外するのが原則です。

• まずブロックログから、反応したルールIDと対象URL、パラメータ名を特定します

• 該当するパスとパラメータに限定して除外ルールを作成します

• ルールセット全体を無効化する対応は避けます（他の攻撃も素通りします）

• 除外を追加したら、意図した通信だけが通るかを検知モードで再確認します

ルールを緩めすぎると、本来止めるべき通信を見逃します。セキュリティ強度と誤検知率はトレードオフの関係にあるため、「どこまで許容するか」を運用開始前にチームで決めておくと判断が早くなります。

運用で詰まりやすい3つの落とし穴

入れただけで終わる。導入直後はログを見ていても、数か月後には誰も確認していない状態になりがちです。最低でも週1回、ブロックログの件数推移を見る習慣を決めておきます。

コストが読めない。前述のWCUのように、ルールを足すほど課金が増える仕組みがあります。マネージドルールを「とりあえず全部有効」にすると、保護範囲と請求額の両方が膨らみます。

インシデント時の手順がない。攻撃を検知したとき、誰がどの権限でルールを変更するのかを決めていないと、対応が遅れます。緊急時に特定IPを遮断する手順は、平時に一度試しておくと安心です。

ミニFAQ：誤検知が出たら、そのルールを無効にしてよいですか。

ルールセット単位での無効化は避けてください。誤検知が起きているのは特定のURLとパラメータであることがほとんどです。対象を絞った除外にとどめるほうが、他の攻撃経路を開けずに済みます。

フリーランスエンジニアとWAF案件

WAFの設定だけを切り出した案件は多くありません。実務では、クラウドインフラ構築やセキュリティ基盤整備の一部として含まれるケースが中心です。

どんな案件でWAFのスキルが求められるか

公開されている募集要項を見る限り、次のような文脈でWAFが要件に登場します。

• AWS／Google Cloud上のインフラ構築案件で、CDNとWAFの設定が作業範囲に含まれる

• 金融・公共系の案件で、セキュリティ要件への対応としてWAF導入と運用設計が求められる

• ECサイトやSaaSの運用案件で、既存WAFのチューニングとログ分析を担当する

• 脆弱性診断の後工程として、検出項目をWAFで緩和する作業が発生する

診断側の仕事についてはペネトレーションテスト案件の実情｜フリーランスで多い診断案件と単価・資格で詳しく扱っています。職種としての全体像はセキュリティエンジニアとは？年収・将来性・キャリアパス・スキルまで徹底解説が参考になります。

単価の目安と、それを満たせる人の像

以下は、2026年10月時点で確認した、首都圏案件を中心に扱う主要フリーランスエージェント3〜5社の公開案件ページ（求人票に相当する募集要項）のうち、WAFまたはクラウドセキュリティ基盤に言及する数十件程度の募集を観測ベースで整理した目安です。統計調査ではなく公開募集の読み取りであり、WAF単独の募集は件数が多くない領域のため、確定したレンジではなく傾向として読んでください。

まず公開案件ベースでは、クラウドインフラ構築にWAF設定を含む週4〜5日の準委任案件は、月60万〜100万円台で募集されているものが見られます。このレンジで募集される案件は、AWSまたはGoogle Cloudでの構築経験3年以上に加えて、IaCでの構成管理経験や、セキュリティ要件を顧客と調整した経験を求めるものが目立ちます。

非公開で打診される案件については、個別の条件で上振れすることがあります。公開案件の相場とは分けて考えてください。

セキュリティ領域の単価レンジをより詳しく知りたい場合は、セキュリティエンジニアのフリーランス単価相場｜案件動向とスキル別レンジで整理しています。単価を体系的に上げる考え方は『【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？』にまとめています。

自分の経験でどのくらいの単価を狙えるか確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。実際の募集条件を見たい場合はフリコンの案件一覧から確認してください。

WAF導入・運用チェックリスト

着手前と運用開始後に確認したい項目を1枚にまとめました。

まとめ

WAFはHTTPリクエストの中身を検査してアプリケーション層の攻撃を検知・遮断する製品であり、ファイアウォールやIDS/IPSとは守る層が違うため、併用して考えるのが一般的です。

要点を整理します。

• 守備範囲は第7層。IPとポートで制御するファイアウォールでは止まらない攻撃を担当します

• 形態はクラウド型・アプライアンス型・ソフトウェア型の3つ。通信経路の制約と運用体制で選びます

• SQLインジェクションやXSSは得意、認可設計の不備や業務ロジックの悪用は苦手です

• 導入は検知のみモードから。ログ観察に2〜4週間、本番ブロックまで1〜2か月が目安です

• 誤検知の調整はパス・パラメータ単位で。ルールセット全体の無効化は避けます

• WAFは脆弱性修正の代替ではなく、修正までの時間を稼ぐ緩和策です

次のステップとしては、まず保護対象の洗い出しから着手してください。対象ドメインと管理画面を一覧化するだけで、どの形態が合うかの判断材料がそろいます。

なお、金融・公共系の案件や、個人情報・決済情報を扱うサービスでは、クラウド型WAFの採用可否やログの保存期間が社内規程・業界ガイドライン・契約条件に左右されます。技術選定と並行して、セキュリティ責任者や法務・監査部門の要件もあわせて確認してください。

参照した一次情報は次のとおりです。

• IPA｜Web Application Firewall 読本

• AWS WAF 開発者ガイド

• AWS WAF 料金

• OWASP Core Rule Set

• Cloudflare WAF ドキュメント

• IPA｜情報セキュリティ10大脅威 2026