WAFのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

WAFの導入は6つのフェーズで進み、要件整理から定着までの流れになります。保護対象と脅威の整理、方式と責任分界の選定、検知から段階的な遮断への移行の順に進めると、安全な運用につながります。

▼全体ガイドの記事
・WAFのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

WAFのシステム開発の全体像

WAFは、WebサイトやWeb APIの前段でHTTPやHTTPSのリクエストを検査し、SQLインジェクションやクロスサイトスクリプティングなどの攻撃を検知・遮断する仕組みです。導入では、製品の契約やルールの有効化に加えて、アプリ固有の通信を把握することが欠かせません。そのうえで、ログを確認しながら安全にブロックへ移行します。

WAFが守る対象と検査の範囲

WAFが守る範囲は、保護対象、検査対象、制御方法の3つに分けて整理できます。

• 保護対象：インターネットから到達できるWebアプリの通信（EC、会員、予約、業務ポータル、公開APIなど）
• 検査対象：URI、HTTPヘッダー、Cookie、クエリパラメータ、リクエスト本文
• 制御方法：OWASP系攻撃の検知や、IPアドレス・地域・頻度による制御

WAFは通信を検査して制御する仕組みで、脆弱なソースコードを修正するものではありません。認可漏れ、漏えい済みパスワードの悪用、内部不正、OSやミドルウェアの未更新も、単独では解決しません。

IPAの「安全なウェブサイトの作り方」が示すとおり、WAFは脆弱性を修正するまでのリスク低減策です。そのため、安全な実装、パッチ適用、脆弱性診断、認証・認可と組み合わせて使います。

クラウドWAF・SaaS型・アプライアンス型の違い

発注側は、方式ごとの特徴を押さえたうえで、自社の構成や運用体制に合うものを選びます。

• クラウドWAF：既存クラウドと統合しやすく、ログ基盤や権限管理を活用しやすい
• SaaS型WAF：ルール調整、レポート、問い合わせ対応を任せやすい
• アプライアンス型：オンプレミス要件や閉域接続、細かな責任分界に対応する候補

AWSではCloudFrontやApplication Load Balancerを、AzureではApplication GatewayやFront Doorを利用できます。Google Cloudではロードバランサーが対応例です。

クラウドWAFは、DNSやCNAMEを切り替えてWebサーバーの前段に配置でき、トラフィックの増減にも追随します。単一クラウドの企業に向いています。

たとえば、ecbeingはCloudFrontとAWS WAFで約1,000サイトを運用しています。

SaaS型は、ネットワーク前段をサービスとして提供する方式です。専任者が少ない企業や、オンプレミスとクラウドをまたいで複数サイトを守る企業にも適しています。

アプライアンス型は、機器更新や冗長化、保守契約まで含めて検討します。

方式の選定では、対象サイト数、月間リクエスト、ピーク帯域を照合します。そのうえで、API・アップロードの有無や個人情報・決済情報の扱い、既存クラウドや監視体制も合わせて確認します。

WAFのシステム開発・導入の進め方

導入は、保護対象と脅威を決めるところから始まり、稼働後の見直しまで段階を追って進みます。

1. 要件整理：保護対象と脅威を決め、運用条件を定める
2. 製品選定：方式と責任分界を比べる
3. 設計・開発：通信経路とルールを作る
4. テスト：誤検知と性能を確かめる
5. 稼働・定着：検知から限定ブロックへ移し、その後もルールと監視を見直す

なかでも、検知モードで実トラフィックを観測し、正常な業務通信を確認してから段階的に適用します。

1. 要件整理フェーズでの保護対象と脅威の決定

要件整理では、保護資産、脅威、運用条件の3点を、この順に決めます。

1. 保護資産：対象資産と配置先の洗い出し、WAFを通らない経路の確認
2. 脅威：自社で対処する攻撃や不正アクセスの範囲
3. 運用・監査条件：対応体制、ログ要件、監査証跡の要件定義書への記載

対象には、WebサイトのURL・FQDN、ログイン・管理・決済画面、公開APIを含めます。アップロードやバッチ連携の入口、オリジンIPも、漏れなく対象に入れます。

配置先は、AWSやAzure、Google Cloudのほか、オンプレミスも含めて台帳に記載します。

脅威には、SQLインジェクションやXSSに加えて、認証への大量試行を検討します。クレデンシャルスタッフィング、悪性Bot、スクレイピングも対象にします。

また、APIのレート超過や地域制限、DDoS、管理画面への不正アクセスも対象になります。OWASP Top 10の2025年版や自社の事故履歴、脆弱性診断結果も参照します。

検知・遮断条件やログ保存期間、通知先を記載します。加えて、誤検知の一次対応者と緊急解除の承認者を明記します。監視時間やSLA、障害時の切戻し時間も書き添えます。

決済を扱う場合は、PCI DSS 4.0.xの要件6.4.2も監査証跡として整理します。同要件は、公開Webアプリへの攻撃を検知・防止する自動化技術を扱います（出典: PCI Security Standards Council、2025年3月31日適用）。

2. 選定フェーズでの方式と責任分界の比較

選定では、方式、責任分界、委託先の実績を順に比較します。

• 比較軸：クラウド統合、ルール柔軟性、API・JSON検査、Bot・DDoS対策を比べます。ログ検索性、運用支援、移行性も確認します。
• 製品候補：利用クラウドや海外向けサイトなど、自社の環境に応じた絞り込み
• 責任分界：初期ルール作成者、誤検知の調査時間、更新承認者、契約終了時の設定・ログ引き渡しの確認
• 委託先実績：同業界・同規模の切替実績の確認。独自開発の場合は、ルール配布や社内申請、SIEM連携、レポートなど周辺機能に範囲を絞る

AWS中心ならAWS WAF、Azure中心ならAzure WAFが候補です。Google Cloud中心であればCloud Armorを検討します。さらに、複数クラウドや海外向けサイトでは、Cloudflareや国内SaaS型も比べます。

製品ベンダーは機能や料金を提供します。一方で、例外ルールやテスト計画、ログの業務判断、24時間の一次対応まで担うとは限りません。

WAFエンジンを自社で開発すると、検知品質やルール更新、性能を担うことになります。さらに、回避攻撃の調査と24時間対応も引き受けます。

3. 設計・開発フェーズでの通信経路とルールの作成

設計・開発では、通信経路、ルール、変更管理とログの3つを順に決めます。

1. 通信経路：構成の図示と、オリジンへの到達経路の制御
2. ルール：標準ルールを基礎にした、アプリ固有の条件と例外の設計
3. 変更管理とログ：設定変更の管理と、ログの保護・連携方法の決定

利用者からデータベースまでの経路を、WAFやロードバランサー、Webサーバー、アプリを含めて図にします。

HTTPSの終端、オリジンへ渡すヘッダー、送信元IPを確認するためのログ項目も決めます。

WAFを通らない直接アクセスを防ぐため、オリジンはWAFやロードバランサーからの通信だけを許可します。

管理画面は社内IPやVPNに限定し、ログイン・検索にはレート制限を設けます。

アップロードやJSON APIは、実データを使って、Content-TypeやURI、パラメータ形式、許容サイズを確認します。そのうえで、例外条件を絞ります。

設定は可能な範囲でIaCや変更管理の対象にします。台帳には、ルール名、目的、対象パスを記録します。さらに、アクションや作成者、承認日、解除条件も残します。

個人情報を含むログはマスキングしたうえで、閲覧権限、保管期間、削除方法を決めます。あわせて、CloudWatchやSIEMへの転送に失敗したときの扱いも設計します。

4. テストフェーズでの誤検知と性能の確認

テストでは、正常・異常通信の確認に加えて、検知と遮断、性能、合格条件を確認します。

1. 正常系：業務操作とデータの整合性の確認
2. 攻撃・性能：攻撃検知、遮断、通知と、性能への影響の試験
3. 合格条件：安全性と運用の判定基準の数値化

本番相当のステージングで、閲覧、ログイン・ログアウト、検索を実行します。さらに、カートや決済、アップロードの操作も行います。管理画面やAPIも対象にします。

レスポンスコードや画面の表示、セッション、業務データを照合します。

記号を含む検索語やJSONが、誤検知されていないかを確認します。

攻撃の試験では、SQLインジェクションやXSS、パストラバーサルを試します。さらに、OSコマンドインジェクションや異常HTTPメソッド、過剰頻度も試します。

許可した通信が通ることに加えて、検知ログや遮断画面、通知、追跡用リクエストIDを確認します。

WAF追加前後の応答時間やスループットを比較し、CPUやオリジン負荷も見ます。そのうえで、ピーク時の余裕を確保します。

合格条件には、正常通信の遮断数や重大な検知漏れを入れます。さらに、ログ欠損やアラート遅延、ルール反映時間、障害時の切戻し時間も含めます。

AWSの事例では、Sumarchが段階導入で応答時間を最大30%改善したと報告されています（出典: AWS公式ブログ、2026年1月）。

5. 稼働フェーズでの検知から限定ブロックへの移行

本番切替では、まず観測を行い、限定ブロックへ進みます。そのうえで、当日の確認と緊急時対応を行います。

1. 検知またはカウントモードで1〜2週間程度観測し、ログで反応ルール、URI、パラメータを確認したうえで、正常業務に必要な例外だけを加えます。
2. 影響の小さいルールや明らかな悪性IPから限定ブロックし、問題がなければ対象を広げます。
3. 切替前に確認事項を点検し、停止時の解除・連絡・切戻しに備えます。

切替当日は、DNSのTTLや証明書、ヘルスチェックを確認します。加えて、キャッシュとオリジン許可リストも見ておきます。

送信元IPの見え方が変わる場合は、アプリ側のログも確認します。

決済やログインが止まった場合に備えて、解除ルールと承認者を定めます。さらに、連絡先と切戻し方法も決めておきます。

6. 定着フェーズでのルールと監視の継続的な改善

定着運用では、監視指標やルール更新を継続して見直します。新しい脅威への対応や手順書も、継続的に改善します。

1. 監視指標：防御状況と運用品質の定期的な確認
2. ルール更新：例外や新たな脅威に応じたルールの見直し
3. 運用手順：対応手順と責任分界を自社に残すこと

月次または週次で、ブロック・検知・誤検知の件数や、上位の送信元・URIを確認します。さらに、応答時間やオリジン負荷、ルール変更数も見ます。

正常通信を何件止めたか、重大アラートを何分で確認できたかも、KPIとして扱います。

例外が増えたときは、アプリ仕様やルール粒度から見直します。脆弱性情報や新しい攻撃手法を受けたときは、ルールを更新し、アプリのリリース前にも影響を確認します。

Botや乗っ取り、API濫用は、従来のシグネチャで判断しにくい場合があります。加えて、AIエージェントの大量アクセスも、従来のシグネチャでは判断しにくい場合があります。

手順書には、通常変更、緊急ブロック、誤検知解除の手順を記載します。さらに、WAFやオリジンの障害、証明書更新を書き加えます。ログ保管やインシデント報告も含めます。

AI検知では、検知理由やログ保存、誤検知の修正を確認します。加えて、追加料金と最終判断者も確かめます。ルールの意図と責任分界を自社に残しておけば、担当者が異動したり委託先が撤退したりしても、防御を続けられます。

WAFのシステム開発にかかる費用相場とコストの内訳

費用は、製品利用料やクラウド基盤・通信料、初期導入の人件費に分けて見ます。さらに、ログ保管やルール調整、監視・障害対応も、費用の内訳に含めます。なお、WAF専用の市場平均は公開されていません。

導入費は、人月単価と一般的なセキュリティ導入工数から整理した推定です。サイト数やリクエスト数、APIの有無で費用は変わります。複数クラウドや24時間監視の有無も影響します。

初期導入費の目安（30万〜200万円程度）

導入範囲は、単一サイトの基本設定から複数クラウドや独自開発まで幅があり、範囲ごとに費用も変わります。

• 1サイトの基本導入：DNS、ロードバランサー、TLS、標準ルール、ログ、疎通確認なら30万〜100万円程度
• 通常導入：検知観測、画面・API例外、誤検知調整、攻撃・負荷テスト、手順作成まで含め50万〜200万円程度
• 複雑な構成：複数サイト・クラウド、SIEM、IaC、権限分離、BCP、移行・切戻しを含み200万〜500万円程度になる可能性
• 追加開発：ルール申請・配布基盤は300万〜1,000万円超、WAFエンジンのフルスクラッチは1,000万円以上かつ6〜12か月以上
• 人月単価の参考値：フリーランス50万〜80万円、中小開発会社80万〜120万円、大手SIer150万〜200万円

これらは、体制や責任範囲で変わる参考値です。WAF専用の統計ではありません。通常のWebサイト防御では、既存製品を活用するのが現実的です。

人月単価に加えて、要件整理からテスト、運用引き継ぎまでに何人日を含むかも確認します。

月額費用の幅（数千円から50万円超）

月額は、製品や運用範囲によって幅があります。そのため、料金例と予算帯を分けて確認します。

• セルフ設定型：製品利用料は月数千円〜数万円程度
• 運用支援付き：SaaS・運用支援込みで月4万〜20万円超
• 広範な運用：SOC、DDoS対策、複数サイト、24時間対応込みで月10万〜50万円超

AWS WAFの料金は、Web ACLが月5ドル、原則1ルールが月1ドル、リクエストが100万件あたり0.60ドルです。たとえば、Web ACL 1個、ルール19個、月間1,000万件ならWAF部分は月30ドル（出典: AWS WAF公式料金表、2026年8月確認）です。

1ドル150円であれば約4,500円ですが、この金額にはCloudFrontやALB、ログ、追加ルールは含まれていません。さらに、基盤やCDN・ロードバランサーの利用料が別料金の場合もあります。マネージドルール、Bot対策、監視も別料金になることがあります。

WafCharmは初期費用とサポート費用が0円で、Liteは月額46,000円からです。Businessは月額112,000円から、Enterpriseは月額192,000円からです。

各プランには、AWS WAF、Azure WAF、Google Cloud Armorの利用料が別途必要です。また、Scutumは初期費用110,000円、月額32,780円からです。

Scutumの月額は、ピーク時トラフィックに応じて、65,780円、140,800円、162,800円、217,800円、327,800円などです（出典: WafCharm公式料金表・Scutum公式料金表、2026年8月確認）。

これらは、公開価格と導入条件から整理した推定です。最終額は、トラフィックやFQDN数、為替によって変わります。さらに、ログ量やSLA、監視範囲によっても変わります。

保守費と運用費の分け方

運用費と見積もりの範囲は、初期費用と分けて、作業内容ごとに確認します。

• 運用作業：ログ分析、誤検知調査、ルール更新、脆弱性確認。加えて、証明書更新、月次報告、通知、緊急時のブロック・解除も含みます
• 見積条件：FQDN数、月間リクエスト、ピーク帯域、ログ保存期間。監視時間、調査時間、報告有無、変更回数、切戻しも条件に含めます
• 費目分け：製品、クラウド、導入、運用、追加オプションの各費目。24時間365日のSOCや緊急連絡は、通常保守とは別に扱います

業務システム全般の保守費は、初期開発費の年間15〜25%程度という目安があります。ただし、WAFはログ量や監視時間で変わるため、この割合に頼らず見積もります。

「WAF運用一式」と書かれていても、必要な作業が含まれない可能性があります。そのため、各費目と作業範囲を見積書で確認します。

WAFの見積もりを取る際のポイント

製品名や月額に加えて、対象資産、通信量、アプリ仕様を、同じ条件で提示します。さらに、セキュリティ要件や運用体制もそろえて提示します。

初期費用と継続費用を分けて比べます。RFPやヒアリングシートに項目を含めておくと、提案の差が見えてきます。

要件明確化のために事前にそろえる情報

見積もりの前には、保護範囲と構成、通信量を整理します。業務データや既存対策も、あわせてそろえます。

• 保護対象：FQDN、サイト・API、主要URI、アップロードの有無
• 構成と通信量：クラウド・オンプレミス、月間リクエスト、ピーク帯域
• 業務・セキュリティ：個人情報や決済、海外アクセス、管理画面の接続元
• 既存対策：HTTPS終端、オリジンIP、CDN・DDoS対策、脆弱性診断結果

運用者や夜間・休日の連絡要否、誤検知の調査時間、ログ保存日数も決めておきます。PCI DSSや取引先監査がある場合は、変更履歴、検知・遮断ログ、インシデント記録の提示可否を確認します。

未確定の事項も隠さず「要調査」として一覧にしておくと、後からの追加費用を抑えやすくなります。

複数社比較での価格以外の運用力

各社に同じ質問を同じ順番で確認します。確認するのは、標準・カスタムルールの範囲、検知からブロックへの手順、誤検知の調査者です。さらに、更新頻度や24時間対応、通知方法を比べます。月次報告やログ保管先も確認します。

機能一覧に加えて、障害時に誰が何分以内に動くかも確認します。AWS専用の自動化、マルチクラウドや海外アクセス、国内SaaS型のように、シナリオ別に適合度を見ます。

WafCharmのような複数クラウドの運用支援でも、基盤WAFの利用料が別にかかる場合があります。Scutumは、ピークトラフィックとFQDN数で料金が変わるため、実測値を渡して見積もります。

誤検知・切替失敗・ベンダー依存のリスク対策

誤検知、切替失敗、委託先依存を避けるには、対策を組み合わせることが欠かせません。

• 誤検知対策：検知・観測・限定ブロック・全体適用を契約範囲にし、例外の期限と見直し日を定める
• 切替対策：入力仕様や安全な実装を開発側と確認し、負荷・切戻し試験を行う。障害時の停止・限定迂回と、オリジンの送信元制限・緊急制御を決める
• 依存対策：設定、台帳、IaC、ログ、手順、変更履歴を自社で管理する。契約には、所有権や終了時の引き渡し、サポート時間、SLA、再委託先、脆弱性通知を盛り込む

これらを整えることで、担当者の経験に頼らず、別の会社へ移れる状態を目指します。

WAFのシステム開発でよくある質問

導入の前によくある疑問を、料金、開発会社、脆弱性対策の役割分担に分けて取り上げます。

WAFはすべてのWebサイトに必要ですか？

すべてのサイトに同じ構成が必要とは限りません。公開Webアプリや会員機能、決済などがあれば、導入を前向きに検討します。個人情報や公開APIを扱うサイトも、検討の対象になります。

改修に時間がかかる旧システム、攻撃ログを監視する担当者がいないシステム、取引先や決済事業者から自動防御を求められるシステムも候補になります。

導入しない場合は、代替策を説明できるようにしておきます。脆弱性診断やレート制限、ネットワーク制御、監視体制などが、その代替策に当たります。

WAFのシステムは自社開発できますか？

WAFエンジンの自社開発は技術的に可能ですが、通常は既存のクラウドWAFやSaaS型を導入する方が安全で合理的です。

自社開発では、攻撃パターンの更新や誤検知調査、回避攻撃対応を担います。さらに、性能試験や24時間監視も継続して担います。開発する場合でも、対象はルール申請や配布、ログ分析、レポートなどの周辺機能に限ります。

WAFの導入にはどのくらいの期間がかかりますか？

標準ルール、DNS、TLS、ログ出力、疎通確認だけなら1〜2週間程度が目安です。一方、次の作業まで含むと1〜3か月程度です。

• 業務画面やAPIの例外：正常な業務操作が止まらないよう、例外条件を調整する
• 検知観測：検知モードで実際の通信を見て、ルールの反応を確認する
• 誤検知調整：観測で見つかった誤検知を、例外として整理する
• 攻撃・負荷テスト：攻撃を想定した試験と、負荷時の性能の確認
• 運用手順：通常変更や緊急時の対応を、手順書にまとめる

複数サイト、複数クラウド、SIEM連携、BCP、権限分離がある場合は、2〜6か月程度になる可能性があります。

WAFを導入すれば脆弱性診断は不要になりますか？

不要にはなりません。WAFは通信を検査する防御層で、脆弱なコードや認可漏れを直接修正しません。設定ミスや古いライブラリ、漏えい済み認証情報も、WAFでは直接解消できません。

脆弱性診断やパッチ適用、安全なコーディング、認証・認可は、WAFとは別の役割として整理します。バックアップやインシデント対応も含めて、役割を分けます。診断結果は、WAFによる一時的な緩和策と、アプリの修正の両方に反映します。

まとめ

導入の段階は、保護対象の決定から定着までが一続きです。

1. 要件整理：保護対象と脅威を決め、運用条件を定める
2. 製品選定：方式と責任分界を比べる
3. 設計・開発：通信経路とルールを作る
4. テスト：誤検知と性能を確かめる
5. 稼働・定着：検知から限定ブロックへ移し、その後もルールと監視を見直す

導入の前に、保護対象のFQDNやAPI、月間リクエスト、ピーク帯域を整理します。加えて、個人情報・決済と監視時間も確かめておきます。

検知モードで実通信を観測し、限定ブロックから全体適用へ移ることが安全な進め方です。

まず確認するチェックリスト

初回の打ち合わせでは、保護するサイト・API・管理画面を確認します。加えて、次の2点も押さえます。

• 構成：クラウドとオリジンの構成を確認する
• 通信量：月間リクエストとピーク帯域を確認する

ログイン・決済・アップロードの扱いや、脅威と監査要件も確認します。さらに、誤検知時の連絡先、ログ保存期間、切戻し方法も押さえます。

見積もりは、製品料金や基盤料金、導入費を分けて比べます。さらに、ルール調整やテスト、監視、保守も、項目ごとに比べます。

製品選定から運用設計までの一貫した進め方

WAFは導入後も、ルール更新や誤検知対応、脆弱性情報への対応を続けて、効果を発揮します。ログ分析やインシデント対応も欠かせません。

方式や運用体制が決まっていない場合は、現在の構成と守る業務を整理し、PoCや段階導入から始めます。そうすると、過剰な投資と切替リスクを抑えられます。

▼全体ガイドの記事
・WAFのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。