メインコンテンツまでスキップ

AI駆動開発はWAFの「ポジティブセキュリティ」を実用段階へ進める

AI駆動開発はWAFの「ポジティブセキュリティ」を実用段階へ進めるの結論、主分析、判断材料、前提と限界を一枚にまとめた詳細図

先に結論​

AI駆動開発がWAFにもたらす大きな変化は、攻撃らしい文字列をAIに探させることだけではない。Application Codeから「このApplicationが受理するHTTP Request」をSecurity Contractとして抽出し、WAF Policyの候補へ継続的に変換できるようになることなのだ。

Positive Security、つまり正常と定義した通信だけを許可する考え方自体は新しくない。難しかったのは、Application固有のPath、Method、Parameter、型、長さ、形式をWAFへ正確に転写し、仕様変更のたびに同期する運用だった。AIは、この翻訳と差分確認を支援できる。

ただし、AIに本番WAFを直接変更させてはいけない。Code上の複数Evidenceから制約候補を作り、Policy Diff、Automated Test、CountまたはLog only、人間の承認を経てBlockへ進める。Application側のValidationも残す。目指すのは自律的な遮断ではなく、同じContractからApplicationとWAFの防御を同期する仕組みである。

本稿は2026年9月3日時点の製品文書に基づく時点記録である。製品機能、提供Plan、検査上限、構文は変更されうるため、導入時にはリンク先の最新仕様を再確認する必要がある。

WAFは「悪い通信」だけを探す装置ではない​

WAFは一般に、SQL Injection、XSS、既知CVEのExploitなど、悪性と判断できる通信を検知して遮断するために使われる。このNegative Securityは、既知攻撃の横断的な検知やVirtual Patchingに欠かせない。

一方、Positive Securityは判断の向きを逆にする。

Negative Security
既知の悪い通信か？ ── Yes ──> Block

Positive Security
Applicationの正常系か？ ── No ──> Block

たとえば会員登録のcustomer_nameが必須の文字列で、最大30文字と仕様で決まっているなら、31文字の値は攻撃Signatureでなくても正常系の外側にある。Applicationへ到達させる前に拒否できる候補になるのだ。

OWASPも、入力検証ではDenylistを主な防御にせず、許可する文字、型、長さ、値の集合を定義するAllowlistを推奨している。同時に、Client-side Validationは回避できるため、Server-side Validationが必要だとしている。1

現代のWAFが扱える粒度​

「WAFはBodyの中を理解できない」という説明は、現在では粗すぎる。製品と契約Planによる差はあるが、主要WAFはHost、Path、Method、Header、Cookie、Query、Bodyを検査でき、JSONやFormのFieldを個別に扱える製品もある。

ただし、「検査対象に選べる」「Rule式で参照できる」「Schemaとして完全に検証できる」「Trafficから自動学習できる」は別の能力である。単純な◎や×へ潰すと、検査上限やParserの挙動、未知Parameter、Requiredの扱いを見落とす。2026年9月3日時点の公式文書から読み取れる実装単位を、次のように整理する。

製品公式文書で確認できる主な実装単位Code-to-Policyで確認すべき点
AWS WAFMethod、Header、Cookie、Path、Query、Body、JSON BodyをField to matchとして選び、文字列、Regex、SizeなどのStatementを組み合わせる。JSONは要素Pathを選択できる。23Formや完全なJSON Schema検証を一つのProfileとして扱うのではなく、必要な制約を個別Ruleへどう分解するか。Body inspection limitとOversize handlingもPolicyに含める
Google Cloud ArmorCEL式でrequest.method、request.path、request.headers、rawのrequest.body、Query・JSON・URL-encoded FormをMap化したrequest.paramsを参照できる。Parameterの存在、値、Map走査、Nested Fieldの例もある。4利用可否、body parsing、式の上限など機能条件を確認し、生成したCELの意味とCostをTestする
Cloudflare WAFApplication ProfilesのSchema Profileを観測TrafficまたはOpenAPIから作成できる。Profileは型、値、Range、Length、Formatなどを扱い、API・Terraformによる自動化導線がある。56Learned ProfileではRequiredの存在を強制せず、新ParameterだけではViolationにならず、完全なAllowlistではない。Multipart、GraphQL、XMLも対象外である。Uploaded Schemaと学習Profileを区別する
Thales WAF GatewayWeb Application ProfilingとAPI Request Profilingの文書があり、Application固有のProfileを扱う。78Portal上で対象Version、Profile更新方法、Violation、Enforcement条件を確認する。公開ページがClient-side表示に依存するため、PoCで実挙動を確認する
Akamai API DefinitionsAPI ResourceへRequest Body Parameterや制約を設定でき、API Definition FileのImport導線がある。91011対応Schema、制約、既定値、Enforcementへ反映される範囲を対象契約と設定で確認する

この表は性能順位ではない。製品ごとに、Rule Language、Schema、Profile、API Definitionという抽象化の置き場所が異なる。AIが生成すべき成果物も、製品名だけでは決まらないのだ。

「最大30文字」をWAFへ同期する​

会員登録画面に次の制約があるとする。

POST /customer/register
Content-Type: application/x-www-form-urlencoded

customer_name
  required  = true
  type      = string
  maxLength = 30

country
  required  = true
  enum      = JP, US, GB

通常のBrowser UIにはmaxlength="30"があり、Server-side ValidatorとDTOにも同じ制約があり、31文字を拒否するTestがある。DB Schemaもvarchar(30)なら、複数のEvidenceが同じConstraintを支持している。

このときWAFへ移せるのは、Request単体から判定できる部分である。

Path、Method、Content-Type
Parameter名、Required、型
Length、Range、enum、Format
        ↓
WAFで観測または拒否できる候補

これに対して、利用者がその顧客データの所有者か、現在の残高で購入できるか、承認Workflowを完了したかは、Request単体では判断できない。認証・認可、DB状態、在庫、残高、業務上の操作順はApplication側の責任である。

制約主な判定場所
Path、Method、Content-Type、Request SizeWAFとApplication
Parameter名、Required、型、Length、Range、enum、FormatWAFで早期拒否し、Applicationでも再検証
利用者の権限、データ所有者Applicationの認可Policy
DBの現在状態、在庫、残高ApplicationとDatabase Transaction
業務Workflow、操作順、価値移転ApplicationのDomain Logic

WAFを第二のApplicationにしてはいけない。入口で確定できる形だけをWAFへ寄せ、業務上の意味はApplicationに残すのだ。

なぜPositive Securityは主流になりにくかったのか​

技術的なPrimitiveがあることと、継続運用できることは違う。Web Applicationには多数のRoute、Method、Header、Cookie、Form、JSON、Client-side Validation、Server-side Validationがある。人間がすべてを調査してWAF Ruleへ変換し、Application変更のたびに追随するのは重い。

Application変更
    ↓
開発者からSecurity担当へ連携
    ↓
WAF Ruleを手作業で変更
    ↓
Test、Deploy

連携が遅れれば、Applicationは40文字を受け付けるのにWAFは30文字でBlockする。反対に、Applicationは30文字までなのにWAFは50文字を通す。Positive Securityを難しくする中心問題は、Ruleを一度作ることではなく、Policy Driftを防ぎ続けることなのだ。

Traffic Learningだけでは仕様にならない​

Traffic Learningは、実通信からEndpoint、Parameter、型、Lengthなどを学び、人手による初期作成を減らせる。しかし、観測されたTrafficはApplication仕様そのものではない。

  • Learning期間中に使われなかった正常機能は学習できない
  • 低頻度の値や経路は十分に観測できない
  • 異常通信を正常例へ取り込む可能性がある
  • 仕様変更をTraffic発生後に知ることになる
  • 観測範囲と本来の許容範囲を区別できない場合がある

最大100文字のFieldへ学習期間中に10文字以下しか入力されなければ、観測値だけからmaxLength: 10と結論づけるのは危険である。Traffic Learningは差分発見と初期候補作成に有効だが、Code、Schema、Test、承認済み仕様と突き合わせる必要がある。

AIはCodeからSecurity Contractを抽出する​

AI支援が有効なのは、Route、Controller、DTO、Validator、HTML、JavaScript、ORM、Database Schema、Testを横断し、同じConstraintを示すEvidenceを集められる点である。

Application Code
  ├─ Route / Controller
  ├─ DTO / Validator
  ├─ HTML / JavaScript
  ├─ ORM / Database Schema
  └─ Test
        ↓ AI-assisted analysis
Security Contract
        ↓
  ┌─────┴─────┐
  ↓           ↓
Application   WAF Policy候補
Validation

Codeを正本にするとは、AIの推論結果を正本にすることではない。責任者が承認したSecurity Contractを変更単位にし、Code、Test、WAF Policyがそこから逸脱していないかを検査することなのだ。Code内に矛盾がある場合は、自動決定せずConflictとして止める。

たとえばHTMLだけが30文字、Server-side Validatorが100文字なら、どちらが正しいかをAIに決めさせない。次のようにEvidenceとConfidenceを出力させる。

Evidence観測したConstraint扱い
HTML maxlength30UX上のEvidence。単独では強制Ruleにしない
DTO / Validator30Server-sideの強いEvidence
境界値Test30文字Accept、31文字Reject実装意図を支えるEvidence
DB Schemavarchar(30)保存上限のEvidence。ただし文字単位・Byte単位を確認
OpenAPI / JSON SchemamaxLength: 30契約上のEvidence

本番Blockまでの安全なPipeline​

AIの役割は、Firewallを自由に操作することではない。Application CodeをSecurity Policy候補へ翻訳し、人がReviewできる差分とEvidenceを作ることにある。

Code Change
    ↓
Constraint抽出 + Evidence / Confidence
    ↓
Security Contract Diff
    ↓
製品別WAF Policy生成
    ↓
構文Test + 境界値Test + 正常系Regression Test
    ↓
Count / Log only
    ↓
実Trafficとの差分確認
    ↓
人間の承認
    ↓
限定ScopeでBlock
    ↓
拒否理由、誤検知、Policy Driftを継続監視

最低限、次の停止条件が必要である。

  • Evidence同士が矛盾している
  • 対応するServer-side ValidationまたはTestがない
  • WAF製品が同じ意味を表現できない
  • Body inspection limitやParser failure時の動作が未定義
  • 正常系Regression Testが失敗する
  • Count / Log onlyで未説明のViolationが残る
  • Policy Diffを承認するOwnerがいない

Blockへの移行は、全体一括ではなくEndpoint単位、Client単位、Traffic割合単位などで限定する。Rollback条件と旧Policyも残す。AIで作成速度が上がっても、変更の責任までAIへ渡るわけではない。

Application側のValidationは削除しない​

WAFにcustomer_name.length <= 30を設定しても、Application側のValidationは残す。WAFは異常なRequestを手前で減らし、Applicationは自分が受理する入力の安全性を保証する。別経路、設定ミス、検査上限、Parser差、WAF障害を考えれば、これは無駄な二重チェックではなくDefense in Depthである。

同期元をそろえることが重要なのだ。

承認済みSecurity Contract
        ↓
  ┌─────┴─────┐
  ↓           ↓
Application   WAF Policy
Validation

同じContractから生成し、それぞれをTestすれば、「Applicationは40文字、WAFは30文字」のようなDriftをCI/CDで検出できる。手作業の二重管理を減らしながら、防御層は二重のまま維持する。

製品選定で見るべきこと​

どのWAFが最も優れているかを、機能表の丸印だけで決めることはできない。AI駆動Positive Securityでは、次の問いの方が実務的である。

  1. 自社ApplicationのHTTP Contractを、製品のRule、Schema、Profileへ損失なく表現できるか
  2. API、Terraform、CLIなどで再現可能に変更できるか
  3. Policy DiffとVersionを保存し、承認とRollbackを行えるか
  4. 構文、境界値、正常系、Oversize、Parser errorを自動Testできるか
  5. Count / Log onlyから限定Blockへ段階移行できるか
  6. ViolationをEndpoint、Field、Constraint、Policy Versionへ紐づけられるか
  7. 価格、Plan、Rule上限、Body inspection limitが対象Trafficに合うか

AWS WAFのStatement生成、Cloud ArmorのCEL生成、CloudflareのUploaded SchemaまたはProfile、ThalesのApplication Profile、AkamaiのAPI Definitionは、同じ成果物ではない。自社のContractを各製品のPrimitiveへどうCompileするかをPoCで確認する必要がある。

WAFはApplication-awareな防御層へ進む​

Negative Securityは今後も必要である。SQL Injection、XSS、RCE、既知CVE、Bot、Scannerを共通の入口で検知する価値は失われない。その上に、Path、Method、Parameter、Type、Length、Range、Format、Request StructureというPositive Securityを重ねる。

AI駆動開発が解消しうるボトルネックは、WAFの検知Algorithmではなく、Application固有Policyの作成と追随である。Application Codeと契約から正常通信を抽出し、製品別Policyへ変換し、Testと観測と人間の承認を通して同期する。その結果、WAFは「既知の悪いものを探す装置」だけでなく、「そのApplicationに存在しない通信を中へ入れない装置」へ近づくのだ。

関連する全体像は、AI時代にWAFはどう変わるべきかとAPI化の次に来る問題で整理している。本稿は、その中でもCodeからWAF Policyを生成・同期する運用へ焦点を当てた。

参考資料​

Footnotes​

  1. OWASP Cheat Sheet Series, Input Validation Cheat Sheet ↩

  2. AWS, Request components in AWS WAF ↩

  3. AWS, JsonBody - AWS WAFV2 API Reference ↩

  4. Google Cloud, Configure custom rules language attributes ↩

  5. Cloudflare, Application Profiles ↩

  6. Cloudflare, Schema Profiles ↩

  7. Thales, WAF Gateway User Guide - Web Application Profiling ↩

  8. Thales, WAF Gateway User Guide - API Request Profiling ↩

  9. Akamai, Set API constraints ↩

  10. Akamai, Add API resources ↩

  11. Akamai, Import API definition file ↩