「その403、本当にWAFのせい？」Geminiに7件のログを渡して見えてきた、AI時代のセキュリティ運用
たった1つの403エラーが、こんなにも難しい理由
「システムにアクセスできません！」
ある日、利用者からこんな問い合わせが入ったとします。
画面には403 Forbidden。
同じ画面を開いている別の社員は、問題なく利用できています。
運用担当者はWAFの設定を確認します。
開発担当者はアプリケーションログを調べます。
ネットワーク担当者はIPアドレス制限を疑います。
どれも間違っていません。
でも、これが厄介なんです。
403という同じ結果でも、そこに至る理由は1つではないからです。
その通信は攻撃なのか。
正常な業務なのにブロックされたのか。
そもそもWAFとは関係ないのか。
こうした原因調査を、生成AIはどこまで支援できるのでしょうか。
今回はGeminiを使って、WAFログ分析と403エラーの原因調査を支援するプロンプトをご紹介します。
なぜこのテーマを取り上げたのか？
こんにちは。
株式会社GROWTH JAPAN TECHNOLOGIESの我妻裕太です。
生成AIブログ「ほぼテク」を運営しています。
私が大切にしているのは、AIを使うこと自体を目的にしないことです。
AIを使って、これまで人間が時間をかけていた作業を整理し、もっと創造的な仕事へ進めること。
今回のテーマには、その考え方が詰まっています。
WAFログを読む作業には、専門知識が必要です。
しかも、単にログの内容を理解するだけでは不十分。
Web通信、セキュリティルール、アプリケーションの権限、ネットワーク構成まで横断的に考えなければなりません。
こんな複雑な作業こそ、AIに調査の下準備を手伝ってもらう価値があるのではないか。
その発想から、今回のプロンプトを紹介したいと考えました。
そもそもWAFとは何なのか？
WAFはWeb Application Firewallの略です。
WebサイトやWebアプリケーションへの通信を調べ、不審なリクエストを検知・遮断する仕組みです。
例えば、SQLインジェクション。
データベースへの不正な命令を入力欄に紛れ込ませようとする攻撃です。
あるいは、クロスサイトスクリプティング、通称XSS。
悪意のあるスクリプトをWebページなどに混入させる攻撃です。
WAFは、こうした攻撃からWebアプリケーションを守る重要な仕組みです。
ただし、検知ルールに一致したからといって、その通信が必ずしも悪意のある攻撃とは限りません。
業務上必要な文字列が、攻撃らしいパターンと一致する可能性もあります。
これを「誤検知」と呼びます。
一方、WAFを通過した後に、アプリケーションが権限不足で403を返すこともあります。
だからこそ、WAFのログだけではなく、通信全体を見る必要があるのです。
Geminiに何をお願いするのか？
今回使うプロンプトの名前は、
「WAFログ分析・403原因調査AI」。
Geminiに、サイバーセキュリティやAzure Application Gatewayに詳しいアナリストとして、ログ分析を行うよう指示します。
具体的には、アクセスログ、WAFログ、アプリケーションログ、利用者情報を組み合わせて調査します。
重要な工夫は、すべてのリクエストにTransactionIdという識別子を用意していること。
これは、異なるログに記録された情報を同じ通信として結び付けるための手掛かりです。
例えば、アクセスログでは403。
WAFログにはルールへの一致とブロック。
アプリケーションログには対応する処理記録がない。
このような情報を総合的に見ることで、WAFによってバックエンド到達前に拒否された可能性を評価できます。
ただし、アプリケーションログがないことだけを根拠に、WAFブロックと断定してはいけません。
この慎重さも、今回のプロンプトの重要なポイントです。
架空の7件のアクセスログから何が分かるのか？
今回のデモ環境は、Azure Application Gateway WAF_v2です。
2026年10月21日17時30分から5分間に発生した、架空の7件のリクエストを調べます。
そのうち、403エラーは4件。
さて、何が起こったのでしょうか。
① 正常な業務レポートが登録できない
USER-Aは、業務レポートの説明欄にHTMLタグを入力しました。
すると403エラー。
WAFログには、XSS関連ルール941160の検知と、最終判定ルール949110によるブロックが残っています。
一方、同じユーザーがHTMLタグを外して再登録すると成功しました。
同じAPIで、権限も変わっていません。
つまり、入力内容の違いが重要な手掛かりになります。
このケースは、正常な業務データに対するWAF誤検知が疑われます。
ただし、WAFで許可したとしても、HTMLを安全に処理できるアプリケーション設計は必要です。
② 顧客検索APIに不審な文字列が送られる
別のアクセスでは、検索パラメータに' OR 1=1--という文字列が含まれています。
これはSQLインジェクションで見られる構文に似ています。
WAFの942100ルールが一致し、通信はブロックされました。
攻撃の可能性が高い通信です。
しかし、ブロックされたという記録から、攻撃が成功したとは言えません。
攻撃らしい試行が確認されたことと、情報が盗まれたことは別問題です。
③ 注文データの閲覧だけ403になる
USER-Cは、特定の注文を表示しようとして403になりました。
しかし、WAFによるブロック記録はありません。
アプリケーションログには、必要な権限がOrderManager、本人の権限がViewerと記録されています。
原因はアプリケーション側の認可処理です。
必要ならアクセス申請の業務フローを確認します。
セキュリティを弱めて全員に閲覧権限を付与するべきではありません。
④ 正規の従業員なのにダッシュボードが表示できない
USER-Dは社外ネットワークからアクセスしました。
ダッシュボードは、特定のIPアドレス範囲のみ許可されています。
そのため、カスタムWAFルールで拒否されました。
本人が正規の社員でも、ネットワーク条件を満たさなければブロックされます。
これは誤検知とは異なります。
VPNや認証済みの安全なアクセス経路を提供するなど、働き方に合わせた設計を検討するケースです。
このプロンプトの本当の価値は何か？
私は、今回のプロンプトの価値は「AIがセキュリティの専門家のように回答すること」だけではないと思います。
注目したいのは、AIが間違えやすい部分を先回りして制御していることです。
例えば、WAFログのMatchedというアクション。
これはルールに一致したことを意味します。
必ずしもブロックを意味しません。
Microsoftの公式資料によると、OWASP CRSのアノマリースコア方式では、複数の検知結果からスコアを計算し、しきい値に達するとブロックする仕組みがあります。
そして、949110は最終的なブロック判定に使われます。
そのため、949110だけを見て原因を説明するのは不十分です。
今回のプロンプトは、この違いを理解した分析を要求します。
さらに、事実、推測、追加調査事項を区別させます。
AIの回答をそれらしく見せるのではなく、人間が検証できる形にする。
ここが重要なのです。
Azure Log Analyticsとの組み合わせはどう役立つのか？
もう1つ注目してほしいのがKQLです。
KQLは、Azure Log Analyticsなどでログを検索・分析するための問い合わせ言語です。
今回のプロンプトでは、403発生IPの集計、WAFルール別の検知件数、TransactionIdによる相関分析など、7種類の調査クエリを作成するよう指示しています。
例えば、403エラーの件数をIPアドレスごとに確認するなら、次のような考え方です。
AGWAccessLogsから過去24時間の403を抽出し、ClientIpごとに集計します。
これにより、特定のアクセス元でエラーが集中していないか調べられます。
ただし、Geminiが生成したKQLは、実際のAzure環境で検証が必要です。
列名、データ型、ログ収集設定、保存期間によって利用できるクエリが変わる場合があります。
Geminiでどんな未来が実現できるのか？
私が面白いと思うのは、調査手順を共有しやすくなることです。
経験豊富な担当者だけが知っている確認項目を、プロンプトに落とし込めます。
すると、経験の浅い担当者も、必要なログ、比較項目、追加確認事項を整理しやすくなります。
もちろん、AIが正しい結論を保証するわけではありません。
それでも、最初の情報整理を支援してくれるだけで、専門家はより重要な仕事へ集中できます。
本当に危険な攻撃を見極めること。
利用者の業務を止めないこと。
安全性を維持しながら、システムを改善すること。
AIは、そうした判断のための道具になれると思います。
なお、時間短縮や費用削減は、実際に導入して測定しなければ効果を断定できません。
どんな人におすすめなのか？
今回のプロンプトは、次のような方に向いています。
● Azure環境を運用している情報システム担当者
● WAFの誤検知対応に悩むセキュリティ担当者
● APIの403エラーを調査する開発者
● インシデント対応を標準化したいDX担当者
● 生成AIを技術業務へ応用したいエンジニア
一方で、AzureやHTTPの基本知識を確認せず、AIの回答だけで本番のセキュリティ設定を変更したい人にはおすすめしません。
AIによる提案と、本番環境への変更判断は分離するべきです。
実際に使うとき、何に注意すればいいのか？
特に気を付けてほしいことは3つあります。
1つ目は機密情報の保護です。
実際のアクセスログには、個人情報や認証情報が含まれる場合があります。
Geminiに渡す前にマスキングし、組織の情報管理ルールを確認してください。
2つ目はWAFの安易な無効化を避けることです。
誤検知を解消したいからといって、保護全体を解除すれば、新たな攻撃リスクが生じます。
特定のルールやパラメータに限定した除外を検討してください。
3つ目は検証できる根拠を残すことです。
どのログから、どのような判断をしたのか。
判断に必要な情報が足りない場合は、何が不足しているのか。
そこまで整理して初めて、運用現場で役立つレポートに近づきます。
まずは架空のログから試してみよう
Geminiを開き、今回紹介した「WAFログ分析・403原因調査AI」プロンプトを入力してみてください。
最初は架空の7件だけで構いません。
診断結果が妥当か、同じTransactionIdを重複して数えていないか、WAFとアプリケーション側の拒否を区別できているか。
そんな視点で、AIの回答を評価してみてください。
生成AIの面白さは、文章を作れることだけではありません。
複雑な情報を整理し、人間が考えるための材料を増やせることです。
仕事の進め方そのものを、少しずつ変えていける可能性があります。
そして、その先にあるのは、単なる効率化だけではありません。
人が創造し、挑戦し、情熱を注げる時間を増やすこと。
そんな未来を実現するために、AIをもっと面白く使っていきたいと思います。
Gemini用のプロンプト詳細や技術的な解説は、生成AIブログ「ほぼテク」で紹介しています。
「Gemini WAFログ分析 403原因調査」の記事をチェックしてみてください。
執筆：我妻裕太
株式会社GROWTH JAPAN TECHNOLOGIES
IBM DXチャレンジ最優秀賞・経済産業大臣賞・その他多数受賞
生成AIブログ「ほぼテク」運営
👉「ほぼテクブログ」で紹介中！
#Gemini #生成AI #WAF #Azure #サイバーセキュリティ #403エラー #DX #業務効率化 #ほぼテク
