開発会社から届いた見積書に「WAF導入費用」「WAF月額保守」という行が並んでいます。金額は決して小さくないのに、その項目が本当に必要なのか、提示された金額が妥当なのかを自分で判断する手がかりがありません。逆に、別の会社の見積にはWAFの項目が見当たらず、どちらが正しいのかも分かりません。社内にセキュリティの専任者がいなければ、相談できる相手もいません。
この状態で決裁を通すと、どちらに転んでも不安が残ります。言われたとおりに入れれば「過剰な投資だったのではないか」という疑念が残り、削れば「公開後に何か起きたら誰が責任を取るのか」という不安が残ります。しかも多くの発注現場では、この判断が要件定義の終盤やリリース直前に持ち込まれるため、落ち着いて比較する時間がありません。
判断できない原因は、WAFの技術知識が足りないことではありません。本来は発注者が決めるべき「必要性」「費用の妥当性」「運用の担い手」という3つの論点が、技術の話として開発会社側に預けられてしまっていることが原因です。この3つは、製品の仕組みを深く理解していなくても、自社の事情から逆算すれば判断できます。
結論から申し上げると、WAFの要否は「扱うデータ」「外部要件」「公開範囲」「脆弱性修正にかかる時間」の4点で評価でき、見積は「初期費用」「月額」「運用保守」「チューニング」の4内訳に分解すれば比較できます。そして運用については、誤検知が起きたときに誰が一次対応するのかを契約前に決めておけば、公開後に宙に浮くことはありません。
本記事では、システム開発を発注する立場からWAFを扱います。WAFが何を守り何を守らないのかという線引きから始め、判断が必要になる場面、必要性を評価する4つの基準、見積の読み方と費用相場、脆弱性診断やセキュアコーディングとの役割分担、開発会社へ確認すべき項目、そしてRFP・要件定義書への記載例までを順に整理します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
WAFとは？発注者が押さえておきたい定義と防御範囲
WAF（Web Application Firewall）とは、Webアプリケーションに向かうHTTP／HTTPS通信の中身を検査し、攻撃と判断した通信をアプリケーションに届く前に遮断する仕組みです。社内で説明するときは「Webサイトやシステムの入口に立って、通信の内容を読んでから通す・通さないを判断する門番」と表現すると伝わりやすくなります。
独立行政法人情報処理推進機構（IPA）は、Webアプリケーションの脆弱性対策としてWAFを位置づけた解説資料「Web Application Firewall 読本 改訂第2版」および「Web Application Firewallの導入に向けた検討項目」を公開しています（IPA「Web Application Firewall 読本」）。後者は導入を検討する立場の人が、製品・サービスの種別と必要な運用体制を整理するための資料として作られており、発注判断の前提知識として目を通しておく価値があります。
WAFが守るのはアプリケーション層の通信
WAFの守備範囲を理解する鍵は、「通信のどの階層を見ているか」です。
通信は複数の階層に分かれており、下位の階層では「どのIPアドレスからどのポートに向かっているか」といった宛先の情報を扱います。上位のアプリケーション層では、「ログインフォームに何という文字列が入力されたか」「URLのパラメータにどんな値が付いているか」といった中身の情報を扱います。
WAFが検査するのは、この上位のアプリケーション層です。たとえば問い合わせフォームの入力欄にデータベースを操作する命令文が混ぜ込まれていた場合、宛先だけを見ている仕組みでは「正常な通信」に見えてしまいます。WAFは入力された文字列そのものを読み、攻撃パターンに合致すれば遮断します。
検知の考え方には大きく2つの方式があります。
方式 | 考え方 | 発注者が知っておくべき性質 |
|---|---|---|
ブラックリスト型（ネガティブセキュリティモデル） | 既知の攻撃パターンに合致する通信を遮断する | 導入直後から広く適用しやすい。未知の攻撃には弱い |
ホワイトリスト型（ポジティブセキュリティモデル） | 正常と定義した通信だけを通し、それ以外を遮断する | 防御は強いが、正常パターンの定義作業が必要で、定義漏れが誤検知になりやすい |
技術的な選択の話に見えますが、発注者にとっては「誤検知の起きやすさと、導入後に必要な調整作業の量が方式によって変わる」という点が重要です。この違いは、後述する運用体制と誤検知時の責任分界に直結します。
ファイアウォール・IPS/IDSとの違いを守備範囲で整理する
「すでにファイアウォールが入っているのにWAFも必要なのか」という疑問は、発注現場でよく出てきます。これは守備範囲が異なるため、どちらかで代替できる関係にはありません。
仕組み | 主に見ている対象 | 代表的に防ぐもの | WAFとの関係 |
|---|---|---|---|
ファイアウォール | 通信の宛先・送信元・ポート番号 | 許可していない経路からの接続 | 入口の経路を絞る。通信の中身は見ない |
IPS／IDS | ネットワーク全体の通信パターン、OS・ミドルウェアへの既知攻撃 | OSやサーバーソフトの既知の脆弱性を狙う攻撃 | サーバー基盤層を守る。アプリ固有の入力は対象外 |
WAF | HTTP／HTTPS通信の中身（入力値・URL・ヘッダ） | SQLインジェクション、クロスサイトスクリプティング等 | アプリケーション層を守る |
整理すると、ファイアウォールは「どの経路を通すか」、IPS／IDSは「基盤ソフトへの既知攻撃」、WAFは「アプリケーションへの入力内容」を担当します。自社開発したアプリケーション固有の入力処理を狙う攻撃は、WAF以外の仕組みでは検知できません。
WAFで防げる攻撃と、WAFでは防げない領域
WAFを検討するうえで、防げる範囲と防げない範囲を対で把握しておくことが重要です。片方しか知らないと、必要性の判断も費用の妥当性の判断もぶれます。
WAFが代表的に防ぐ攻撃には、次のようなものがあります。
- SQLインジェクション（入力欄からデータベースを不正に操作する攻撃）
- クロスサイトスクリプティング（XSS／悪意あるスクリプトを他の利用者のブラウザで実行させる攻撃）
- クロスサイトリクエストフォージェリ（CSRF／利用者に意図しない操作を実行させる攻撃）
- OSコマンドインジェクション（サーバー上でコマンドを不正に実行させる攻撃）
- ディレクトリトラバーサル（公開を想定していないファイルを参照させる攻撃）
- 不正ログインの試行（同一アカウントへの機械的な試行の遮断など、製品によって対応範囲は異なります）
一方で、WAFでは防げない、あるいは防ぎにくい領域もあります。
- アクセス権限の設計不備（他人のデータが見えてしまう設計になっている場合、通信自体は正常なためWAFは異常と判断できません）
- 認証・認可ロジックの欠陥（正しい手順の通信として成立するため検知が困難です）
- 内部関係者による正規の権限を使った持ち出し
- 設定ミスによる情報公開（公開設定を誤ったストレージ・管理画面の露出など）
- サーバーOSやミドルウェア自体の脆弱性（基盤層の対策が別途必要です）
ここから導かれる結論は明快です。WAFは「アプリケーションの入力を狙う既知の攻撃を入口で止める仕組み」であり、設計上の欠陥そのものを直すものではありません。この線引きを持っておくと、「WAFを入れたので診断は不要」という判断が成り立たない理由も自然に理解できます。
システム開発の発注でWAFの判断が必要になる3つの場面
WAFの判断が発注者の前に現れるタイミングは、実は限られています。どの場面で判断するかによって、選べる選択肢とかかるコストが大きく変わります。
提案・見積の比較時｜WAF項目の有無が各社で揃わない
複数社に見積を依頼すると、WAFの扱いが各社で揃わないことがよくあります。A社は「クラウド型WAF導入費用」と「月額保守」を明記し、B社はセキュリティ項目に触れず、C社は「セキュリティ対策一式」とまとめています。この状態では金額の総額を並べても比較になりません。
原因は、発注側が提示した要件にWAFの記述がないか、あっても粒度が粗いことです。要件が曖昧なとき、各社は自社の標準構成や想定リスクに基づいて見積を作るため、前提条件がそれぞれ異なります。比較できない見積が並んだ時点で、発注者は判断材料を失い、結果として「一番安い会社」か「一番丁寧に説明してくれた会社」を選ぶことになります。
この場面でやるべきことは、金額の比較ではなく前提条件を揃えることです。後述する確認項目を各社に同じ形で投げて、回答を横に並べると比較可能になります。
要件定義時｜非機能要件としてWAFを確定させる
WAFは、画面や帳票のような機能要件ではなく、性能・可用性・セキュリティといった非機能要件に属します。非機能要件は「仕様書に書かれていなくても当然やってくれるだろう」と期待されがちな領域ですが、書かれていないものは見積にも作業計画にも入りません。
要件定義の段階で確定させておくべきことは、WAFを入れるか入れないかの判断だけではありません。どの範囲を守るのか、誰が運用するのか、誤検知が起きたときにどう対応するのかまで含めて文書に落ちていなければ、「導入したが運用されていない」状態に陥ります。
要件定義はWAFの判断に最も適したタイミングです。この段階なら、構成の選択肢が残っており、テスト計画にも組み込めます。
リリース直前・公開後｜後出しほどコストが膨らむ理由
一方、リリース直前や公開後にWAFを追加しようとすると、同じ製品を入れるだけでも必要な作業が増えます。
追加するタイミング | 必要になる主な作業 | 発注者側の負担 |
|---|---|---|
要件定義時 | 構成設計に組み込み、テスト計画に含める | 要件の検討・判断のみ |
開発終盤 | 既存構成への後付け、通信経路の変更、再テスト | 追加見積の承認、スケジュール調整 |
リリース直前 | 上記に加え、短期間での調整。誤検知の洗い出しが不十分になりやすい | 公開延期か、リスクを抱えた公開かの選択 |
公開後 | 稼働中システムへの適用、DNS・証明書の切り替え、業務時間を避けた作業 | 一時的なサービス影響の受容、追加費用 |
とくに公開後の追加は、クラウド型WAFの場合に通信の経路そのものを変更することになり、ドメインの設定や証明書の扱いを伴います。稼働中のサービスで実施するため、作業時間帯の調整や切り戻し手順の準備も必要になります。
同じ結果を得るために後からコストを払うことになるため、WAFは「要件定義の段階で握る論点」と位置づけるのが合理的です。
WAFの必要性を発注者が判断する4つの基準
WAFの必要性は、開発会社に聞く前に自社で評価できます。ここでは4つの基準を提示します。該当数が多いほど必要性が高いと判断してください。
なお、Webアプリケーションの脆弱性を狙う攻撃は継続的な脅威として扱われています。IPAの「情報セキュリティ10大脅威 2026」では、組織向けの脅威として「システムの脆弱性を悪用した攻撃」が6年連続で選出され第4位に位置づけられています（IPA「情報セキュリティ10大脅威 2026」）。自社システムが攻撃対象になり得るという前提で、以下の基準を当てはめてください。
扱うデータの種類で判断する
最初に確認すべきは、そのシステムが何を預かるのかです。
扱うデータ | WAFの必要性 | 理由 |
|---|---|---|
クレジットカード情報・決済情報 | 非常に高い | 漏えい時の被害が直接的な金銭被害になり、業界基準の対象にもなります |
会員情報・個人情報（氏名・連絡先・住所） | 高い | 漏えい時の通知・報告義務と信用低下の影響が大きくなります |
医療・雇用・信条などの機微な情報 | 非常に高い | 取り扱いに特別な配慮が必要な情報であり、漏えい時の影響が重大です |
社内の業務データ（顧客企業名・取引条件等） | 中程度 | 取引先との守秘義務違反につながる可能性があります |
公開前提の情報のみ（会社案内・公開資料） | 低い | 改ざんリスクは残るものの、漏えいによる直接被害は限定的です |
判断の目安として、「漏えいしたときに、取引先や利用者へ個別に連絡しなければならないデータが入っているか」を自問してみてください。答えがはいであれば、必要性は高い側に寄ります。
外部要件・業界基準の有無で判断する
自社の意向とは別に、外部の要件によってWAFの導入が事実上の必須になる場合があります。
とくに明確なのがクレジットカード情報を扱う場合です。クレジットカード業界のセキュリティ基準であるPCI DSSは、バージョン4.0の要件6.4.2において、一般公開されているWebアプリケーションに対して、Webベースの攻撃を継続的に検知・防止する自動化された技術的ソリューションを導入することを求めています。この要件はバージョン3.2.1では推奨扱いでしたが、4.0では必須要件となり、2025年3月31日の移行期間終了をもって適用されています（基準本文はPCI Security Standards Council の資料ライブラリ、要件6.4.2の変更点の解説はFastly「PCI DSS 4.0 の要点」を参照）。基準の条文はWAFという製品名を指定するものではありませんが、この要件を満たす代表的な実装手段がWAFです。
このほか、次のような外部要件が該当します。
- 取引先から提示されるセキュリティチェックシート（WAFの導入有無が設問に含まれることがあります）
- 業界団体や官公庁のガイドライン（調達要件に記載される場合があります）
- 加入しているサイバー保険の付保条件
- 親会社・グループ会社の情報セキュリティ規程
これらに該当する場合、WAFの要否は社内の費用対効果ではなく外部要件として決まります。発注前に、自社が受けている外部要件を棚卸ししておいてください。該当があれば、見積の削減対象から外す判断材料になります。
公開範囲と入力フォームの有無で判断する
攻撃が届く経路があるかどうかも判断基準になります。
条件 | 必要性への影響 |
|---|---|
インターネットに公開され、誰でもアクセスできる | 高める |
不特定多数が入力できるフォームがある（会員登録・問い合わせ・検索・ファイルアップロード） | 高める |
ログイン機能がある | 高める |
社内ネットワークからのみアクセスでき、接続元を制限している | 下げる |
利用者が限定され、接続元のIPアドレスを限定できる | 下げる |
とくに注意したいのが、「社内向けシステム」として発注されたものが、実際にはインターネット経由で利用される設計になっているケースです。在宅勤務や外出先からの利用を前提にしていれば、公開システムと同じ扱いが必要になります。要件定義の段階で、どこからアクセスできる設計なのかを明確にしておいてください。
脆弱性修正までのリードタイムで判断する
4つ目の基準は見落とされやすいものですが、実務上はもっとも効いてきます。脆弱性が公表されたとき、自社のシステムに修正を適用し終えるまでに何日かかるかを見積もってください。
WAFの本質的な役割のひとつは、修正が適用されるまでの時間を稼ぐことです。使用しているフレームワークやライブラリに重大な脆弱性が公表された場合、修正版への差し替えと動作確認、本番反映には一定の日数がかかります。保守契約の内容や開発会社の体制によっては、数週間を要することもあります。その期間、攻撃パターンを入口で遮断できるかどうかで被害の有無が分かれます。
次の条件に当てはまる場合、WAFの必要性は高くなります。
- 保守契約が「問い合わせ対応のみ」で、緊急修正の対応時間が定められていない
- システムの改修が月次・四半期のリリースサイクルでしか行われない
- 社内に動作確認を行える人員がおらず、検証に時間がかかる
- 使用している技術の構成が古く、修正版への差し替えに影響範囲の調査が必要
逆に、継続的に改修できる体制があり、緊急時の修正を数日以内に反映できる契約になっている場合は、優先順位を相対的に下げて検討できます。
4基準の判定目安
4つの基準の該当数から、おおまかな方針を立てられます。
該当状況 | 方針の目安 |
|---|---|
外部要件に該当がある | 必須。要否の議論ではなく、形態と運用の議論に進む |
外部要件はないが、該当が3つ以上 | 必須に近い。要件定義に含めて見積を取る |
該当が2つ程度 | 推奨。費用と運用負荷を見て判断する。導入しない場合は代替策を明文化する |
該当が1つ以下、かつ公開範囲が限定的 | 必須とはしない。公開範囲が広がる時点で再検討する前提を残す |
導入しないと判断した場合は、その判断理由と、代わりに何で担保するのか（接続元の制限、脆弱性診断の実施、修正の緊急対応時間の確約など）を記録に残してください。判断の経緯が残っていれば、後から見直すときにも、社内で説明するときにも使えます。
WAFの種類と費用相場｜発注時の見積で確認すべき内訳
WAFには複数の提供形態があります。技術的な違いを細かく理解する必要はありませんが、形態によって「初期費用の大きさ」「契約の相手」「運用する人」「構成を変えやすいか」が変わります。発注者にとってはここが本質です。
クラウド型・ソフトウェア型・アプライアンス型の違いを発注者視点で比較する
項目 | クラウド型 | ソフトウェア型 | アプライアンス型 |
|---|---|---|---|
設置の考え方 | 事業者のサービスを通信経路に挟む | サーバーにソフトウェアを導入する | 専用機器をネットワークに設置する |
初期費用 | 小さい | 中程度（構築工数が中心） | 大きい（機器購入） |
月額・年額の負担 | 継続的に発生する | 保守・ライセンス費用が発生する | 保守費用が発生する |
契約の相手 | WAF事業者、または開発会社経由 | ライセンス提供元と開発会社 | 機器販売元と開発会社 |
運用の担い手 | 事業者側が基盤を運用し、設定は利用者または開発会社 | 開発会社または自社 | 開発会社または自社 |
構成変更の自由度 | 事業者の提供範囲内に限られる | 比較的高い | 高い |
発注者から見た注意点 | 通信経路が事業者を経由するため、障害時の影響と連絡経路を確認する | サーバー性能への影響と、導入後の設定変更の担い手を確認する | 機器の保守期限・更新時期と、更新費用の負担者を確認する |
中小規模のWeb システム開発では、初期費用が小さく導入までの期間が短いクラウド型が選ばれることが多くなっています。ただしクラウド型は継続費用が積み上がる性質があるため、長期の総額で見る視点が必要です。この点については、初期費用の低いクラウド型に対し、アプライアンス型は初期費用が高くてもハードウェアの耐用年数にわたる総保有コストで比較すると同等以下になる場合があるという整理も示されています（IT trend「WAF導入にかかる追加コスト」）。見積を受け取ったら、提示された形態で5年間の総額を試算してみてください。
費用の目安については、クラウド型の場合、初期費用が5万〜7万円程度、月額が9,000円〜45,000円程度という価格帯が紹介されています（アイミツ「WAFの費用相場」）。また、クラウド事業者が提供するサービスでは従量課金の体系が採られており、たとえばAWS WAFはウェブACLごとに月額5米ドル、ルールごとに月額1米ドル、処理したリクエスト100万件ごとに0.60米ドルという料金体系が公開されています（AWS WAF の料金）。
ただし、これらは製品・サービス本体の価格です。実際の見積額はトラフィック量、保護するドメイン数、サポート範囲、そして開発会社が担う作業量によって変動します。公開されている価格帯は「桁が大きく外れていないか」を確認する目安として使い、金額そのものの正解として扱わないでください。発注者が本当に確認すべきなのは、次に述べる内訳の構造です。
見積は4つの内訳（初期費用／月額／運用保守／チューニング）に分解する
「WAF一式 ○○円」という見積は比較できません。次の4つに分解して提示を求めてください。
内訳 | 何の費用か | 確認するポイント |
|---|---|---|
初期費用 | WAF製品・サービスの初期契約費、導入設計、設定作業、動作確認 | 開発会社の作業工数と、製品側の初期費用が分かれているか。検証環境での事前テストが含まれるか |
月額ランニング | WAFサービスの利用料、ライセンス料 | 課金の基準は何か（トラフィック量・リクエスト数・ドメイン数）。上限超過時の追加料金はどうなるか |
運用保守 | 稼働監視、シグネチャ更新の確認、定期レポート、問い合わせ対応 | 作業内容と頻度が具体的に書かれているか。対応時間帯と連絡手段はどうなっているか |
チューニング | 誤検知が起きた際の調査と設定修正、ルールの追加・調整 | 月あたり何回まで含まれるか。超過分は時間単価か、別見積か |
この4つのうち、見落とされやすいのがチューニングの扱いです。WAFは導入直後に正常な通信を誤って遮断することがあり、その都度調査と設定修正が必要になります。この作業が運用保守の範囲に含まれているのか、都度の追加見積になるのかで、年間の総額は変わります。
見積に4つの区分がなければ、「この4区分に分けて再提示してください」と依頼してください。この依頼は技術的な知識を必要とせず、各社の前提条件を揃える効果があります。分けた結果、同じ総額でも運用保守の範囲が大きく違うことが見えてきます。
契約主体は開発会社か自社か｜開発終了後の継続を見据える
もうひとつ、見積の金額に現れにくい論点があります。WAFサービスの契約を誰の名義で結ぶのかです。
契約形態 | 発注者から見た利点 | 注意点 |
|---|---|---|
開発会社経由（再販・取次） | 窓口が一本化され、技術的なやり取りを任せられる | 開発会社との取引が終了したときに契約も終わる可能性がある。価格改定の内訳が見えにくい |
自社で直接契約 | 開発会社を変更しても契約が継続する。価格と契約条件を直接確認できる | 障害時の一次切り分けを自社で行う必要が生じる場合がある。管理画面の操作主体を決めておく必要がある |
重要なのは、どちらが優れているかではなく、どちらであるかを把握しておくことです。開発会社経由の契約になっている場合は、「開発が完了した後も同じ条件で継続できるか」「保守契約を他社に切り替える場合、WAFの契約はどうなるか」「管理画面のアカウントは誰が保有するか」を発注前に確認してください。
公開後の運用が別の会社に移る可能性がある場合、この確認を飛ばすと、引き継ぎの段階でWAFだけが前任の開発会社に紐づいたまま残ります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
WAFと脆弱性診断・セキュアコーディングの役割分担
限られた予算の中で判断するとき、「WAFを入れるなら脆弱性診断は省けるのか」「診断をやるならWAFは不要なのか」という二択の疑問が出てきます。結論として、この3つは目的が異なるため代替関係にありません。
WAF・セキュアコーディング・脆弱性診断の守備範囲を切り分ける
対策 | 目的 | 作用するタイミング | 守る範囲 | 守らない範囲 |
|---|---|---|---|---|
セキュアコーディング | 脆弱性を作り込まない | 開発中（設計・実装） | 新規に作る部分のアプリケーション | 既存コード、使用している外部ライブラリの脆弱性 |
脆弱性診断 | 作り込まれた欠陥を見つける | リリース前、および定期的に | 診断した時点の実装全体（権限設計の不備も検出対象） | 診断後に追加・変更した箇所、診断範囲外の機能 |
WAF | 攻撃を入口で遮断し、修正までの時間を稼ぐ | 稼働中（常時） | 既知の攻撃パターンに合致する通信 | 設計上の権限不備、認証ロジックの欠陥、内部不正 |
この表から見えるのは、3つの関係が「源流で作らない（セキュアコーディング）」「作ってしまったものを見つける（脆弱性診断）」「見つかったものを直し終えるまで守る（WAF）」という時間軸の分担になっていることです。守備範囲が重なる部分はありますが、WAFだけでは検出も修正もできない領域が確実に残ります。
とくに注意が必要なのは、権限設計の不備です。ログイン済みの利用者が、URLのパラメータを書き換えて他人のデータを参照できてしまう場合、通信そのものは正当な手順で成立しているため、WAFは異常と判断できません。この種の問題は脆弱性診断で検出し、実装を直すしかありません。脆弱性診断の費用相場や発注時の進め方については脆弱性診断とはで詳しく整理しています。
予算が限られる場合の優先順位
3つすべてに十分な予算を割けない場合、次の順序で検討してください。
- セキュアコーディングを開発プロセスに組み込む — 追加費用が最も小さく、効果が構造的です。コーディング規約への明記、脆弱性を生みやすい処理のレビュー実施、フレームワークの標準機能の活用などは、開発プロセスの中で実施できます。要件に含めておけば、後から対策を積み増すより安く済みます。
- 公開前の脆弱性診断を1回は実施する — 設計上の欠陥は、見つけなければ直せません。全機能の網羅が難しい場合でも、認証・決済・個人情報を扱う画面に絞って実施する選択肢があります。
- WAFを導入する — 診断で見つかった問題を直し終えた後も、新たな脆弱性は公表され続けます。修正までの時間を稼ぐ手段として導入します。
- 運用体制を整える — 導入した仕組みを動かし続けるための体制です。優先順位としては最後に見えますが、ここが抜けると上の3つの効果が目減りします。
ただし、外部要件によってWAFの導入が必須になっている場合は、この優先順位より外部要件が先に立ちます。その場合は、WAFの費用を前提として他の項目の配分を考えてください。
発注時に開発会社へ確認すべきWAFのチェックリスト
ここからは、打ち合わせにそのまま持ち込める確認項目です。各項目には、なぜ確認するのかと、回答が曖昧だった場合に何が起きるのかを添えています。
導入形態・検知方式・チューニング方針を確認する
# | 確認項目 | 確認する理由 | 回答が曖昧な場合のリスク |
|---|---|---|---|
1 | 導入形態と製品・サービス名は何か | 形態によって初期費用・契約主体・運用の担い手が変わります | 他社の見積と比較できず、総額の妥当性が検証できません |
2 | 検知方式はどちらか（既知パターンの遮断型／正常通信の許可型） | 誤検知の起きやすさと、導入後に必要な調整作業の量が変わります | 公開後に正常な申込が遮断され、対応工数が想定外に発生します |
3 | 導入時はどのモードから始めるか（検知のみで開始するか、最初から遮断するか） | 段階的に適用するほど誤検知の影響を抑えられます | 公開初日から正常な利用者が遮断される可能性があります |
4 | 検知のみのモードで運用する期間はどれくらいか | ログを確認して遮断対象を見極める期間が必要です | 期間が確保されないまま遮断を有効化し、調整が後追いになります |
項目2と3は技術的に見えますが、聞くべきことは単純です。「最初は様子を見る運用から始めますか、それともいきなり遮断しますか」「様子を見る期間はどのくらい取りますか」と尋ねれば足ります。回答が「導入後すぐ遮断で問題ありません」であれば、その根拠（過去の類似構成での実績、事前テストの内容）を確認してください。
誤検知時の一次対応窓口と責任分界を確認する
WAFの運用でもっとも実務的な論点が誤検知です。正常な通信が遮断されると、利用者から「申し込みができない」「エラーになる」という連絡が入ります。このとき、誰が何分以内に何をするのかが決まっていないと、原因の切り分けだけで時間が過ぎます。
# | 確認項目 | 確認する理由 | 回答が曖昧な場合のリスク |
|---|---|---|---|
5 | 誤検知が疑われるとき、最初の連絡先はどこか | 連絡先が複数あると、たらい回しの時間が発生します | 障害の切り分けが始まるまでに数時間を失います |
6 | 対応時間帯と、初動までの目標時間はどうなっているか | 営業時間外に発生した場合の扱いが変わります | 夜間・休日の障害が翌営業日まで放置されます |
7 | 誤検知による機会損失（申込の取りこぼし等）の扱いはどうなるか | 責任の所在が契約に書かれていなければ、事後の協議になります | 損害の負担をめぐって開発会社との関係が悪化します |
8 | 遮断を一時的に解除する判断は誰が行うか | 緊急時に判断者が不在だと復旧が止まります | 復旧の意思決定を待つ間、サービスが使えない状態が続きます |
項目7については、誤検知による損失の全額補償を求めることが現実的でない場合もあります。重要なのは、補償を取り付けることではなく、「どこまでが開発会社の責任で、どこからが自社の受容範囲か」を契約前に合意しておくことです。この合意がないまま公開すると、問題が起きた時点で初めて交渉が始まります。
なお、こうした責任分界や対応時間の取り決めは、WAFに限らず外注契約の情報セキュリティ条項全体で整理すべき論点です。契約条項に落とすべき項目の全体像は外注契約の情報セキュリティ条項チェックリストにまとめています。
運用（シグネチャ更新・ログ・引き継ぎ）の担い手を確認する
WAFは導入したら終わりではなく、新たな攻撃パターンに対応するための更新と、検知状況の確認が継続的に必要です。
# | 確認項目 | 確認する理由 | 回答が曖昧な場合のリスク |
|---|---|---|---|
9 | 攻撃パターン（シグネチャ）の更新は誰が、どの頻度で行うか | 自動更新か手動作業かで運用負荷が変わります | 更新が止まり、新しい攻撃に対応できないまま稼働します |
10 | 検知・遮断のログは誰が確認し、どう報告されるか | 確認されないログは、問題の発見を遅らせます | 攻撃の兆候や誤検知の蓄積に気づけません |
11 | ログの保管期間と提供形式、自社の閲覧権限はどうなるか | 事後調査や報告義務への対応で必要になります | 問題発生時に、何が起きたのか証跡が残っていません |
12 | 検証環境での事前テストは実施するか、範囲はどこまでか | 本番適用前に誤検知を洗い出す工程です | 本番で初めて誤検知が発覚し、公開中の影響が出ます |
13 | 開発完了後の運用保守は誰が担うか。範囲と期間はどこまでか | 開発と運用で担当が変わる場合、空白期間が生じます | 開発完了と同時にWAFの運用が宙に浮きます |
14 | 保守会社を変更する場合、設定内容と運用手順はどう引き継がれるか | 設定が属人化していると移行できません | 引き継ぎ時に設定を一から作り直すことになります |
項目11のログについては、個人情報の漏えいが疑われる事態が発生した場合、何がいつ起きたのかを示す証跡が報告や調査の基礎資料になります。「ログは取得していますが、お客様には提供していません」という回答であれば、必要になったときに提供を受けられるのか、どの程度の期間保管されるのかまで確認してください。
これら14項目をすべて埋める必要はありません。自社のシステムに照らして該当するものを選び、同じ質問を各社に投げて回答を並べてください。回答の具体性そのものが、各社の運用体制を判断する材料になります。
RFP・要件定義書へのWAF要件の書き方
判断した内容は、文書に落として初めて見積と契約に反映されます。ここでは、ベンダーが見積に反映できる粒度の記載例を示します。
悪い記載例と、各社の見積が揃わなくなる理由
次のような記載は、発注現場でよく見られますが、各社の見積を揃える役には立ちません。
【悪い例】 ・セキュリティ対策としてWAFを導入すること。 ・十分なセキュリティを確保すること。
この記述には、形態も運用範囲も求める水準も含まれていません。受け取った各社は、それぞれの標準構成で見積を作ります。ある会社は最小構成のクラウド型を検知モードのみで提案し、別の会社は運用保守とチューニングを年間契約で含めた構成を提案します。前提が違う見積が並ぶため、総額の差が構成の差なのか単価の差なのか判別できません。
また、「十分な」「適切な」といった形容詞は、合意の基準になりません。公開後に誤検知が起きたとき、何が約束の範囲だったのかを示す根拠がなくなります。
そのまま使えるWAF要件の記載例
次の要素を含めると、各社が同じ前提で見積を作れるようになります。
【記載例】Webアプリケーションファイアウォール（WAF）に関する要件
1. 対象範囲 本システムのうち、インターネットに公開するすべての画面およびAPIを保護対象とする。とくに会員登録画面、ログイン画面、問い合わせフォーム、決済関連画面を必須の保護対象とする。
2. 求める防御範囲 SQLインジェクション、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ、OSコマンドインジェクション、ディレクトリトラバーサルを含む、Webアプリケーションを対象とした既知の攻撃を検知・遮断できること。
3. 導入形態 形態は提案に委ねる。提案時に、形態（クラウド型／ソフトウェア型／アプライアンス型）、製品・サービス名、選定理由を明示すること。
4. 導入時の進め方 本番適用前に、検証環境で主要な業務シナリオ（会員登録、ログイン、問い合わせ送信、決済）を通し、誤検知の有無を確認すること。本番では検知のみのモードで運用する期間を設け、ログを確認した上で遮断を有効化する手順とすること。当該期間の目安を提案に含めること。
5. 運用要件 ・攻撃パターンの更新主体と頻度を明記すること ・検知・遮断状況の報告を月次で提出すること（報告書の様式案を提案に含めること） ・ログの保管期間は○か月以上とし、当社が内容を確認できる手段を提供すること
6. 誤検知時の対応 ・誤検知が疑われる事象の一次連絡先、受付時間帯、初動までの目標時間を明記すること ・設定修正の対応回数が運用保守費用に含まれる範囲と、超過時の費用算定方法を明記すること
7. 契約・引き継ぎ ・WAFサービスの契約主体（当社直契約／貴社経由）を明記すること ・開発完了後の運用保守の範囲・期間・費用を明記すること ・保守体制を変更する場合に引き継ぐ設定内容および運用手順書の提供範囲を明記すること
8. 見積の提示方法 費用は、初期費用（製品初期費用・導入作業費を区分）、月額ランニング費用、運用保守費用、チューニング費用の4区分に分けて提示すること。
○の部分は自社の事情に合わせて埋めてください。このうちとくに効くのは、項目8の見積提示方法です。区分を指定しておけば、各社の見積が同じ構造で返ってくるため、比較の手間が大幅に減ります。
WAF以外のセキュリティ要件も含めて仕様書を整えたい場合は、セキュリティ要件の書き方で発注者が仕様書に入れるべき項目とフォーマット例を整理しています。
製品を指定するか、要求水準だけ示して提案を募るか
要件の書き方には、製品を指定する方法と、要求水準だけを示して提案を募る方法があります。
方針 | 向いている場合 | 注意点 |
|---|---|---|
製品・サービスを指定する | 社内に既存の契約がある。グループ会社の標準製品が決まっている。外部要件で指定されている | 開発会社に経験がない場合、構築・運用の品質が読めません。経験の有無を確認してください |
形態まで指定し、製品は提案に委ねる | 運用体制や契約主体の方針が固まっている | 形態を絞った理由を伝えておくと、適切な提案が集まりやすくなります |
要求水準のみ示して提案を募る | 技術的な判断材料が社内にない。複数の構成を比較したい | 提案が揃わない可能性があるため、提案時に明示すべき項目（形態・製品名・選定理由・費用区分）を指定してください |
社内に判断材料がない場合は、3つ目の方針が現実的です。その際も、何を提案書に書くべきかを指定しておけば、比較可能な提案が集まります。「提案は自由です」と伝えるのではなく、「提案の自由度は認めるが、提示する項目は揃えてください」という伝え方が有効です。
WAF導入でよくある失敗と発注者側の回避策
最後に、発注者側の判断が原因で起きやすい失敗を整理します。いずれも、ここまでの確認項目を押さえておけば防げるものです。
WAFを入れたから安全と考えてしまう
もっとも多い誤解です。WAFは既知の攻撃パターンを入口で遮断する仕組みであり、アプリケーション側の欠陥そのものを直すものではありません。権限設計の不備や認証ロジックの欠陥は、通信としては正当に見えるため検知されません。
この誤解が実務上の問題になるのは、脆弱性が公表されたときに「WAFがあるから急がなくてよい」と判断してしまう場面です。WAFは修正までの時間を稼ぐ仕組みであって、修正を不要にするものではありません。
回避策: 要件定義の段階で、脆弱性が公表された場合の修正対応について、連絡から修正適用までの目標時間を保守契約に含めてください。WAFの導入と、脆弱性修正の体制は別の論点として扱います。
検証環境でのテストを省いて本番適用する
スケジュールが押している局面で省略されやすいのが、検証環境での事前テストです。省略した結果として起きるのが、公開後に正常な申込が遮断される事象です。
遮断されやすいのは、長文の入力欄（問い合わせ内容・自由記述）、特殊な記号を含む入力（氏名の記号、URLを含むテキスト）、ファイルのアップロード、外部サービスとの連携通信などです。これらは業務上必要な正常な通信ですが、攻撃パターンに似た文字列を含むことがあります。
回避策: 検証環境での事前テストを要件に明記し、実施する業務シナリオを発注者側から指定してください。日常業務で実際に使われる入力パターン（記号を含む顧客名、長文の問い合わせ、添付ファイルの送信など）を洗い出して渡せば、テストの網羅性が上がります。さらに、本番では検知のみのモードで運用する期間を設け、ログを確認した上で遮断を有効化する手順にしておくと、影響を抑えられます。
導入後のチューニング担当・契約継続が決まっていない
WAFが「導入されたが機能していない」状態に陥る典型的な経路が2つあります。
ひとつは、誤検知が起きた際に調整する担当が決まっておらず、遮断を全面的に解除してしまう、あるいは検知のみのモードのまま放置されるケースです。遮断していなければ誤検知は起きませんが、同時に防御もしていません。導入費用と月額費用だけが発生し続けます。
もうひとつは、開発完了と同時にWAFの契約と運用が宙に浮くケースです。開発契約には含まれていたものの、保守契約の範囲に明記されていなかったために、更新作業もログ確認も誰も行わない状態になります。開発会社経由の契約だった場合、保守会社を変更した時点で契約の扱いも不明確になります。
回避策: 契約前に次の3点を文書で確定させてください。
- 誤検知が起きた際の調査・設定修正を行う担当と、運用保守費用に含まれる対応回数
- 開発完了後の運用保守の範囲・期間・費用（開発契約とは別に明記する）
- WAFサービスの契約主体と、保守体制を変更する場合の設定・手順の引き継ぎ範囲
いずれも、先ほどのチェックリストで確認した内容を契約書・仕様書に落とす作業です。打ち合わせでの口頭合意にとどめず、文書に残してください。
まとめ｜WAFの要否は発注者が決められる
WAFは、Webアプリケーションに向かう通信の中身を検査し、攻撃と判断した通信を入口で遮断する仕組みです。守るのはアプリケーション層の既知の攻撃であり、権限設計の不備や認証ロジックの欠陥、内部不正は守備範囲外です。この線引きが、必要性と費用の判断の土台になります。
本記事で整理した判断の流れは次のとおりです。
- 必要性を4つの基準で評価する — 扱うデータの種類、外部要件・業界基準の有無、公開範囲と入力フォームの有無、脆弱性修正までのリードタイム。外部要件に該当があれば、要否ではなく形態と運用の議論に進みます
- 見積を4つの内訳に分解する — 初期費用、月額ランニング、運用保守、チューニング。区分を指定して再提示を求めれば、各社の前提が揃います
- 確認項目を各社に同じ形で投げる — 導入形態と検知方式、誤検知時の一次対応窓口と責任分界、シグネチャ更新・ログ・引き継ぎの担い手
- 判断結果をRFP・要件定義書に書く — 対象範囲、求める防御範囲、導入時の進め方、運用要件、誤検知時の対応、契約・引き継ぎ、見積の提示方法
次に取るアクションは3つです。第一に、発注しようとしているシステムが何のデータを預かるのかを棚卸しし、外部要件に該当があるかを確認してください。第二に、手元の見積を4つの内訳に分解して再提示を依頼してください。第三に、誤検知が起きたときの一次対応窓口と、開発完了後の運用保守の範囲を、契約前に文書で確定させてください。
WAFの要否は、製品に詳しくなければ判断できないものではありません。自社が何を預かり、どんな外部要件を受け、修正にどれだけ時間がかかるのかは、発注者にしか分からない情報です。その情報から逆算すれば、判断の主導権は発注者の側にあります。
システム開発の発注時に押さえるべき要件整理に使えるお役立ち資料をご用意しています。セキュリティ要件の棚卸しや稟議書のたたき台としてご活用いただけます。詳しくはお役立ち資料一覧をご覧ください。
システム開発のセキュリティ要件の整理でお困りの方は、お問い合わせフォームからご相談ください。WAFの要否や運用体制が固まっていない要件定義の段階からのご相談にも対応しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 社内向けのシステムでもWAFは必要ですか？
接続元をIPアドレスや閉域網で限定できるなら必須ではありませんが、在宅勤務などでインターネット経由の利用を想定するなら公開システムと同様に検討してください。導入しない場合は、その理由と代替策を記録に残しておきましょう。
- 見積にWAFの項目が入っていないとき、追加を依頼すべきですか？
個人情報や決済情報を扱うなら、要件定義の段階で追加を依頼するのが安全です。公開後の追加は通信経路の変更や再テストで費用が膨らむため、初期費用・月額・運用保守・チューニングの4区分で再提示を求めましょう。
- WAFを導入すれば、脆弱性診断は省略できますか？
省略できません。WAFが止めるのは既知の攻撃で、権限設計の不備のように通信としては正常に見える欠陥は検知できないため、予算が限られる場合も認証や個人情報を扱う画面だけは公開前に診断しましょう。
- WAFは導入初日から遮断モードで運用して問題ありませんか？
おすすめしません。検証環境でのテストと検知のみの運用期間を省くと正常な申込まで遮断される恐れがあるため、まず検知のみで始めてログを確認し、問題がなければ遮断へ切り替える手順を開発会社に求めてください。
- 開発会社との契約が終わった後、WAFの運用はどうなりますか？
開発会社経由の契約だと、保守の終了とともにWAFの契約や運用が止まる場合があります。契約名義、管理画面のアカウント保有者、設定内容と運用手順書の引き継ぎ範囲を、保守会社を変更する場合も含めて契約前に文書で確認しておきましょう。
