Webセキュリティシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Webセキュリティシステムの開発は、要件整理、選定、設計開発、テスト、稼働、定着の6つのフェーズで進めます。各フェーズで技術と運用の両方を確かめると、安全性と業務継続を両立できます。

▼全体ガイドの記事
・Webセキュリティシステム開発の完全ガイド

Webサービス開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

Webセキュリティシステムの概要

Webセキュリティシステムは、Webサイト、Webアプリ、APIを不正アクセスや脆弱性攻撃から守る仕組みです。

防御の対象には、情報漏えい、改ざん、サービス停止も含まれます。

通信を検査するWAFだけでなく、認証・認可、安全な実装、ログ監視、インシデント対応も必要です。

バックアップと復旧までを一体のものとして考えます。

守る対象と脅威の整理

まず、守る資産、想定する脅威、対策の優先度を分けて洗い出します。

• 公開面：公開サイト、管理・ログイン・決済画面、公開・社内APIの範囲。
• 情報資産：個人情報、決済情報、アップロードファイル、接続するクラウドや外部サービス。
• 利用状況：対象ごとに、利用者、停止時の影響、扱うデータ、管理者権限の有無を記録します。
• アプリへの攻撃：SQLインジェクション、XSS、認証突破、権限のないデータ参照を想定します。
• 大量・外部攻撃：Bot、DDoS、乗っ取り、サプライチェーン経由の侵入も考慮します。

資産と脅威を結びつけておくと、必要な対策の優先順位をつけやすくなります。

IPAの「安全なウェブサイトの作り方」は、SQLインジェクションやセッション管理の不備を扱います。

同ガイドは、XSS、CSRF、アクセス制御・認可制御の欠落など、11種類の脆弱性と運用対策も対象です。

WAFは攻撃を一部遮断できますが、アプリの認可不備や設計上の欠陥を自動修正しません。そのため、WAFの導入とアプリ側の対策は分けて計画します。

WAF・認証・診断・監視の役割分担

各対策は、対象とする脅威に合わせて組み合わせます。役割を整理すると、対策の重複や抜けが見えてきます。

• WAF：不審な通信や既知の攻撃、レート超過を検知・遮断します。
• CDN・DDoS対策：大量通信への耐性と可用性を高めます。
• MFA・SSO・OAuth：利用者や管理者のなりすましを抑えます。
• 診断・レビュー：SAST・DAST、依存ライブラリ検査、コードレビュー、侵入テストで弱点を探します。

WAFを導入しただけで安全と誤認したり、複数製品で同じログを収集したりすると、対策の不足や費用増加につながります。

要件定義の段階で、脅威ごとの防御策、検知後の判断者、復旧までの許容時間を決めておきます。

製品の機能だけでなく、運用時の責任も明らかにしておきます。

Webセキュリティシステム開発の進め方

開発は、要件整理、選定、設計開発、テスト、稼働、定着の6つのフェーズで進みます。各フェーズでは、技術と運用の両方を確かめます。

製品を契約しても、開発はそこで終わりません。既存アプリを止められない場合は、検知モードや限定URLから始めます。テスト環境とカナリア運用を挟んで遮断へ移ると、誤検知による業務停止を抑えられます。

フェーズ1：要件整理で守る範囲と合格条件

要件整理では、まずシステム構成図、ドメイン・API一覧、データ分類、利用者区分を集めます。

現行の認証方式や、クラウド・オンプレミスとの接続方法も確認します。

次に、機密性・完全性・可用性の優先度を決めます。許容停止時間と復旧目標時間は、数値や条件で決めておきます。ログ保存期間、脆弱性報告期限、24時間365日監視の要否も、条件として示します。

要件の抜けを防ぐため、確認事項を箇条書きで整理します。

• 対象と公開範囲：URL・API、管理画面、内部APIのうち、外に出す範囲。
• データ：個人情報や決済情報の保存場所。
• 脅威と影響：想定する攻撃と業務影響の対応づけ。
• 対応・変更責任：検知・遮断・復旧の責任者と、ルール変更の承認者。

要件が曖昧なまま製品を選ぶと、後から対象の追加や連携の改修が発生します。その結果、予算が膨らむ可能性があります。

フェーズ2：責任分界を比べる選定

選定では、候補の種類を比べたうえで、自社の運用条件に合う組み合わせを選びます。

• 候補製品・支援：クラウドWAF、マネージドWAF／WAAP、ソフトウェアWAF、アプライアンス、診断、SOC。
• 小規模・自社運用：自社で運用できる小規模サイトは、クラウドWAFが始めやすい選択肢です。
• 複数環境：AWS・Azureや複数サイトをまとめる場合は、CDN・DDoS・API・ログ監視を扱うマネージド型も候補です。
• 改修が難しい場合：WAFを暫定防御にし、根本原因の修正計画を別に用意します。
• 比較項目：対応クラウド・オンプレミス、API・Bot、レート制限、カスタムルール、誤検知時の調整を確認します。

ログの保存先と期間、24時間365日監視、障害時の一次窓口も比べます。

設計書・設定情報の引き渡しと解約時のデータ返却も確かめます。

製品会社、SIer、運用会社が別々の場合は、攻撃検知からアプリ改修までの責任分界を図で示します。

フェーズ3：設計開発でのセキュリティ組み込み

通信経路とアプリ内の制御を設計書にまとめ、開発工程とテストにセキュリティを組み込みます。

• 通信経路：利用者からCDN、WAF、ロードバランサー、Webサーバー、アプリ、DBまでを描き、オリジンの直接公開を避けます。
• ログイン・管理画面：MFA、SSO、IP制限、権限分離を適用します。
• API：認証方式、スコープ、レート制限、入力検証、エラー応答の情報量。
• 通信・データ：CookieのSecure・HttpOnly・SameSite、TLS、秘密情報の保管場所、アップロード検査を設計書に記します。
• 開発・ルール：CI/CDにSAST・DAST等を組み込み、認可テストとWAF例外の期限も管理します。

CI/CDでは、依存ライブラリ検査、SBOM管理、コードレビューも行います。

テストでは、他人のIDでのデータ取得や管理者APIへの到達を確かめます。

自作WAFルールには、正規の利用者を遮断しない条件を組み込みます。

フェーズ4：防御性能と業務継続性のテスト

テストでは、攻撃の遮断だけでなく、正常な利用、検知、業務継続までを一連で確かめます。

• 正常系：ログイン、検索、購入、ファイル登録、API連携、バッチ処理で誤遮断を確認します。
• 攻撃系：SQLインジェクション、XSS、認証回避、権限昇格、パストラバーサル、Bot、レート超過、DDoSを検証します。
• 検知・連絡：ログ、遮断結果、アラート、担当者へのエスカレーションが設計どおりか確認します。
• 継続・復旧：負荷、障害時の迂回、バックアップ復旧、WAF・認証停止時の代替手順を試します。
• 合格条件：主要画面のエラー率が許容値以内、重要APIの応答時間が基準以内、重大な未修正脆弱性がない状態です。

アラートが営業時間外にも届き、担当者が復旧手順を実行できるかも確かめます。

フェーズ5：検知モードから段階的に遮断へ移す稼働

誤検知による停止を避けるため、検知モードから遮断へ段階的に移行します。稼働後も、状況を見ながら進めます。

1. 全URLをすぐ遮断せず、検知またはカウントモードで通信を観察します。
2. ログイン、決済、検索、管理画面、公開APIを優先し、正規・海外アクセス、クローラー、外部連携、アプリ通信を確認します。
3. 誤検知時はURL、パラメータ、送信元、期限、承認者を限定し、広い例外を避けます。
4. 変更凍結の時間、ロールバック条件、緊急連絡網、障害告知文、代替サーバー、メンテナンス画面を準備します。
5. 稼働後1週間は、遮断件数、誤検知率、5xx、ログイン失敗、APIレート超過、オリジン負荷を毎日追います。

稼働後の数値は、導入前の基準値と比べます。売上や問い合わせ数だけでなく、安全性と利用者体験の両面から稼働を判定します。

フェーズ6：ルール更新と訓練を業務に組み込む定着

設定は一度決めて固定せず、脅威やシステム変更に合わせて、点検と訓練を定期業務にします。

• 定期点検：月次または四半期ごとに、脆弱性、WAFルール、依存ライブラリ、アカウント、ログ保存、バックアップ復元を見直します。
• 機能追加：新APIや機能の追加時に脅威モデリング、レビュー、DAST、リリース後監視を行い、開発・運用チケットを連携します。
• 脅威情報：公表される脅威動向を定期運用に反映します。
• インシデント訓練：年1回以上、検知から封じ込め、経営報告、顧客告知、復旧、再発防止までを実地で確かめます。

IPAが2026年に公表した「情報セキュリティ10大脅威2026」では、組織向けの順位を示しています。

組織向けでは、システムの脆弱性を悪用した攻撃が4位、DDoS攻撃が9位です。さらに、サプライチェーンや委託先を狙った攻撃は2位です（出典：IPA「情報セキュリティ10大脅威2026」、2026年）。

こうした脅威の変化を受けて、脆弱性情報や委託先の変更を定期的に取り込みます。

導入時の設定だけでなく、運用を通じて対策を保つ必要があります。

Webセキュリティシステムの費用相場とコストの内訳

費用は、保護ドメイン数、月間リクエスト数、API数で変わります。ルール数やログ保存期間も関わります。また、診断対象の画面数、既存環境との連携、サポート時間も影響します。

ここに示すのは税別の企画用の目安で、公的な市場統計ではありません。

費用は、クラウド利用料と、初期設定・改修・監視・再診断などの作業費を分けて捉えます。

導入パターン別の費用相場の幅

以下の目安は企画用の費用と期間です。比べる際は、利用規模や依頼する支援範囲をそろえておきます。

• クラウドWAFを自社設定：初期費用0〜30万円程度、継続費用0〜10万円程度、期間は即日から1か月程度。
• 初期設定・調整を依頼：初期30〜150万円程度、月額5〜30万円程度、期間2週間〜2か月程度。
• マネージドWAF／WAAP・監視：初期30〜200万円程度、月額10〜80万円程度、期間1〜3か月程度。
• 脆弱性診断・改善支援：30〜150万円程度、期間2週間〜2か月程度。
• WAF・認証・API保護・ログ／SIEMの統合とアプリ改修：初期300〜1,500万円程度、月額10〜100万円程度、期間3〜9か月程度。

ドメインやリクエスト量が少ないサイトは、公開料金だけでより小さく始められる場合があります。一方で、複数サイトや大規模業務システムの統合・スクラッチ連携では、1,500〜5,000万円以上、6〜12か月以上になる可能性があります。

利用料だけでなく設定・改修・監視・再診断を含むTCO

費用は、クラウド利用料だけでなく、導入作業と継続運用を含むTCO（総保有コスト）で比べます。

• クラウド利用料：Web ACL、ルール、リクエスト、Bot対策、ログ、CDN、ロードバランサー、APIゲートウェイ。
• AWS WAFの例：公式料金の内訳と適用上の留意点。
• 初期作業費：診断、要件定義、構成設計、DNS・証明書切替、ルール・認証・ログ連携、テスト、移行支援。
• 継続作業費：ルール更新、誤検知・脆弱性対応、アラート一次対応、報告、ログ保管、再診断、訓練。
• 総額比較：1年目・3年目のTCO、障害時の追加費用、解約・移行費用を並べます。

AWS WAFの公式料金例では、Web ACLが月5ドル、ルール19個が月19ドル、月間1,000万リクエストが6ドルで、WAF部分の合計は月30ドルです（出典：AWS「AWS WAF Pricing」、確認日2026年8月）。

実際の請求は、接続先サービスやマネージドルールで変わります。ログや為替、追加機能によっても変わります。そのため、この例を国内案件の月額費用としてそのまま当てはめることはできません。

Webセキュリティシステムの見積もりを取る際のポイント

相見積もりでは、各社が含める範囲が異なります。たとえば、WAF契約費だけの会社と、診断・アプリ改修・監視まで含む会社は、単純には比べられません。

範囲をそろえないまま進めると、後から追加請求が発生します。依頼書では、対象システムと前提条件、成果物、検収条件をそろえます。運用体制と除外事項も、併せて書きます。

見積依頼前の対象・成果物・前提条件の書き出し

依頼の前に、対象と前提条件を決め、成果物と検収条件も書き添えます。そのうえで、各社へ同じ情報を渡します。

• 対象規模：ドメイン・環境、月間・ピーク時リクエスト、保護URL・API、ログイン・決済の有無。
• 既存環境：個人情報やカード情報の扱い、CDN・WAF・SIEM、クラウドアカウントの管理者、希望時期。
• 利用条件：停止不可時間、海外利用者、アプリ、外部連携の有無を伝えます。
• 設計・検証成果物：診断報告、要件定義、構成図、脅威モデル、WAFルール、認証・認可設計、テスト計画・結果。
• 運用・検収成果物：手順書、事故対応フロー、教育資料、設定引き渡し一覧と納品・完了条件。

「導入支援一式」とだけ書いたのでは検収できません。そのため、納品物と完了状態を具体的に明記します。

複数社の価格・技術力・運用体制の比較

価格に加えて、技術力、運用実績、契約終了時の引き継ぎやすさも比べます。

• 技術・体制：同規模・同業種の経験、アプリ改修、クラウド・オンプレミス、診断、API・Bot、監視時間、資格。
• 実績の確認：課題、構成、改善指標を聞き、匿名の構成図、報告書例、障害連絡フローを見ます。
• 権利・事故対応：設計書・ソースコード・WAFルール・ログ・診断結果の所有権、再委託先、脆弱性通知期限、秘密保持、事故時の役割を確かめます。
• 契約・個人情報：SLA、損害賠償、終了時のデータ返却、ベンダー変更時の引き継ぎ、委託先の安全管理・アクセス権・保管・削除方法を確認します。

これらは、法務・情報システム部門と一緒に確認します。

誤検知・停止・二重投資のリスク確認

安い見積もりでは支援範囲を、構成が過剰な見積もりでは継続負担を確かめます。

• 不足範囲：アプリ診断なし、WAF調整が別料金、平日日中のみの監視では運用できない場合があります。
• 過剰機能：不要なログ・監視費が続き、担当者がアラートを処理できない懸念があります。
• 段階分け：機能を必須・将来拡張・不要に分け、初期構成と追加オプションを別見積もりにします。
• 運用リスク：誤遮断、脆弱性放置、未監視ログ、責任不明、設定の属人化。
• 契約条件：遮断移行条件、例外期限、月次レビュー、緊急時の追加単価を契約前に確かめます。

Webセキュリティシステムに関するよくある質問

導入前によく質問される論点を、ここにまとめます。

正解は、自社の規模や扱うデータによって変わります。そのため、判断の順番を確かめてください。

WebセキュリティシステムはWAFだけで十分ですか？

まず対象と脅威を整理し、WAFで守れる範囲と補完策を分けて考えます。

• WAFの役割：通信検査と遮断に強い仕組みです。
• アプリの弱点：認証・認可の設計不備や脆弱なコードは解決しません。
• WAFの対象外：漏えい後の対応、バックアップ復旧、内部不正には対応できません。
• 補完策：必要に応じてMFA、診断、ログ監視、DDoS対策、アプリ改修を組み合わせます。

既存のWebアプリを改修できない場合でも導入できますか？

アプリを改修できない場合も導入できます。その際は、導入後の対応を順に決めておきます。

1. WAFは暫定防御とし、アプリ改修の計画を別に用意します。
2. 検知モードで実通信と誤検知を調べ、影響の小さいURLから遮断します。
3. 重大な脆弱性は修正し、再診断まで行います。
4. 例外ルールで問題を隠し続けると攻撃経路が残るため、期限と責任者を必ず設定します。

Webセキュリティシステムの開発期間はどのくらいですか？

導入形態ごとの期間の目安と、期間が前後する条件を示します。

• クラウドWAFを自社設定：即日から1か月程度です。
• 初期設定・調整を依頼：2週間〜2か月程度が目安です。
• マネージドWAFと監視：1〜3か月程度です。
• システム統合：認証・API・ログ基盤・アプリ改修を含めると3〜9か月程度です。
• 変動要因：脆弱性の修正範囲、環境の複雑さ、停止可能時間で前後します。選定前に現状調査の期間を確保します。

個人情報保護法やPCI DSSへの対応をWAFで証明できますか？

WAFだけでは、法令や基準への適合は証明できません。そのため、対象データに応じた管理と評価が必要です。

• 個人情報：安全管理措置、委託先管理、アクセス制御、ログ、事故対応を整えます。
• カード情報：PCI DSS v4.0.1の適用範囲と評価方法を確認します。
• 証跡と評価：WAF、認証、脆弱性管理、運用記録を整理し、必要に応じて専門家の確認を受けます。

PCI Security Standards Councilの文書ライブラリには、PCI DSS v4.0.1と関連資料が公開されています（出典：PCI Security Standards Council Document Library、2026年確認）。

クラウドWAFとスクラッチ開発はどちらがよいですか？

標準的な防御を短期間で始めたいなら、クラウドWAFが向きます。一方で、独自認証や監査ログ、社内ワークフローを統合する場合は、製品とアプリ開発を組み合わせます。

WAFエンジンをスクラッチ開発すると、ルール更新、検知精度、障害対応の負担が大きくなります。そのため、独自開発は業務固有の画面や連携に絞り、既存サービスと役割を分ける方法が現実的です。

まとめ

開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで進めます。

WAFだけを先に契約せず、保護対象と脅威を確かめてから構成を選びます。

まず、公開サイト、管理画面、API、データを洗い出します。さらに、許容停止時間や復旧方法、監視体制、責任分界を定めます。そのうえで、技術対策と運用の両面から準備します。

資産の洗い出しと現状診断の着手

最初に、URL、API、データの一覧を作ります。認証方式やクラウド構成、担当者も、あわせて一覧にします。

診断や構成レビューで、WAFで対応できる問題と、アプリ改修が必要な問題を分けます。

検知モードで実通信を観察し、正常利用を守る条件をルールに組み込みます。そのうえで、限定範囲、カナリア、本番全体の順に遮断へ移します。

運用と復旧を含めた見積もりの比較

費用は、クラウド利用料だけでなく、設定、チューニング、アプリ改修まで含めて比べます。さらに、診断やログ保管も総額に含めます。監視、再診断、訓練、障害時対応は、運用の費用として併せて比べます。

候補会社には、成果物と検収条件、責任分界を確かめます。設定情報の引き渡しと、例外ルールの期限、契約終了時の移行条件も確かめたうえで、必要な範囲から段階的に始めます。

▼全体ガイドの記事
・Webセキュリティシステム開発の完全ガイド

▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【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を創業。