【夏休みの自由研究リレー】Claudeと一緒にAWS WAF運用をやってみてる話
こんにちは、クラウド事業統括本部@福岡オフィスのべこみん（@beco_minn）です。
当記事はクラスメソッドの有志による 『夏休みの自由研究リレー』 第2回 のエントリです。
このブログリレーの企画は、普段からクラウドやAIを追いかけているメンバーによって、「やってみた」だけではなく「作ってみた」や「調査/研究してみた」もアウトプットしてみようという企画です。
新たな知見になることは勿論、アイデアを自社やコミュニティの発展に寄与できればと考えておりますので、お付き合い頂けますと幸いです。
では、さっそくいってみましょう。今回の記事は『Claudeと一緒にAWS WAF運用をやってみてる話』です。
さて、本記事ではタイトルの通り、Claudeを使ったAWS WAFのログ分析と運用の取り組みについてお話しします。
「それって夏休みの自由研究なの？」ってツッコミが入りそうですが、「やってみた」のその先、「やってみてる」という趣旨には沿っているということで一つご容赦ください...
どこかでアウトプットしたいなと考えていた内容だったので、備忘録も兼ねて本記事にまとめたいと思います。
そういえば皆さん、AWS WAFもといWAFのログって活用出来てますか？なんとなくWAFを有効化してそのまま放置しちゃってませんか？
実は私も1年ほど前から社内サービスのAWS WAF運用を引き継いで担当しているのですが、他の業務が忙しくなかなかログの活用が出来ていませんでした。そこで「何かいい感じに運用できないかな」と思い、Claude Codeのカスタムスキルを使ったログ分析の仕組みを構築し、現在2〜3ヶ月ほど運用しています。
そもそも私はなぜClaudeを使うことにしたのでしょうか？
解決したかった課題
AWS WAFのコンソールは年々充実してきており、ダッシュボードからリクエストの概況を確認したり、サンプルリクエストを確認したりすることが出来ます。
特に昨年のAWS re:Inforce 2025でリリースされたアップデートは大きかったですよね。皆さんも大興奮したんじゃないでしょうか？
私たちのサービスではセキュリティに関する定例会を隔週で開催しているのですが、そこでの定期チェックとしてAWS WAFのダッシュボードで「異変がないか」を確認していました。すごく便利ですよね。
ただ、これにはいくつか課題がありました。
COUNTモードのルールをBLOCKに切り替えたいが、判断材料が足りない
運用中のWebACLにはAWSマネージドルールをCOUNTモード（検知のみ）で設定しているものがいくつかあります。正規のトラフィックをブロックしたくないため、アタッチしているルールの内の比率でいえばCOUNTにしているルールの方が多いほどです。もちろんクリティカルな攻撃を検知するルールはBLOCKにしてますけどね。
これらのルールで偽陽性の無いものは本番のBLOCKに切り替えたいのですが、正規のトラフィックへの影響を判断するための情報が十分に得られていませんでした。
個々のルールの深掘りに時間がかかる
AWS WAFコンソールもリッチになり、簡単に全体のトレンドなどを見ることが出来るようになりました。全体的なトレンドは見えるのですが、個々のルールについて「どのURIに対するリクエストがマッチしているのか」「そのリクエストは本当に悪性なのか」を確認するにはドリルダウンが必要で、定例の時間ではとても足りないというのがネックでした。
つまり、効率的にログを分析して、効果的なルール運用をしたい というのが本取組の出発点です。
どういう仕組みで解決を試みたか
構築したシステムの全体像は以下の通りです。
AWS WAF (WebACL)
↓ S3にログ出力（全件保存、5分間隔で配信）
S3 (AWS WAFログバケット)
↓ EventBridgeで毎週定期実行
Lambda (前段集計スクリプト)
↓ summary.json / blocked_requests.csv / count_mode_details.csv
S3 (レポートバケット)
↓ ダウンロード
Claude Code + カスタムスキル で分析・レポート生成
↓
分析結果HTMLレポート（Chart.jsグラフ付き）
↓
定例会でチーム共有（WAFに対するアクションを検討）
ざっくり言うと、「Lambdaでログを集計 → Claudeで分析・レポート化 → チームで確認」という流れです。
なぜこの構成にしたか
この構成にする上での個人的な工夫したことや考えを以下にまとめました。
AWS WAFの生ログを全てClaudeに渡すのは現実的ではない
これはログ分析など大容量のデータの処理にLLMを使おうとしたことがある方なら共感していただけると思います。AWS WAFのログはリクエストごとに1レコードなので、トラフィックの多いサービスではあっという間に膨大な量になります。
そこで、定型的な前処理をLambdaスクリプトで行い、Claudeが分析しやすい形に複数の結果ファイルとしてまとめることにしました。ここでは後続のClaudeによる分析に必要な情報をノイズとして落としてしまわないように注意しました。
なぜS3にログを出力しているか
元々このサービスのWAFログはCloudWatchに保存していました。しかし、そこまで厳密なリアルタイムでの分析を行なっていなかったことや、今回の構成上大量のログをS3に保管したかったため、S3保存に切り替えました。障害が発生した場合にはAWS WAFコンソールのサンプルリクエスト機能やAthenaで直接S3をクエリして対応出来ますし、S3出力でも5分間隔で配信されるのでニアリアルタイムな分析は可能です。
なぜAthenaではなくClaudeで分析するのか
これは冒頭でも書いたように運用の効率を良くするためという理由も大きいのですが、Claudeを使えばグラフ付きのHTMLレポートを簡単に生成出来ます。さらにそこにはルールに対する推奨コメントという「第三者の視点」も含まれます。AIエージェントの意見や判断が絶対正しいとは言えませんし誤っていることもあるかもしれません。しかし自分と違う観点での意見というのは視野を広げてくれます。これは単なるスクリプトでは得られない価値です。
IaC（CloudFormation）でデプロイ
これはあまりシステム構成に影響しないのですが、Lambda、S3バケット、EventBridgeルール、IAMロールをCloudFormationテンプレートで一括デプロイ出来るようにしています。環境変数でバケット名・WebACL名・分析日数などをパラメータ化しており、後々の横展開を見据えた設計です。
集計スクリプトについて
集計用のLambdaが出力するファイルは以下の3つです。コード全文は割愛しますが、それぞれの役割を説明します。
- summary.json
- blocked_requests.csv
- count_mode_details.csv
summary.json（集計サマリ）
メインの集計結果です。このファイルには以下の情報が含まれます。
- 分析期間と総リクエスト数（除外分・分析対象分の内訳つき）
- アクション別内訳（ALLOW / BLOCK / COUNT）とブロック率
- terminatingRule別ヒット数（どのルールが最終判断を下したか）
- BLOCKを発生させたルールグループ内のルール別ヒット数
- COUNTモードでマッチしたルール別マッチ数
- URI、IPアドレス、国、User-Agentのそれぞれについて、全体Top50とBLOCK分Top30
- 時間帯別リクエスト数（全体とBLOCK）
- AWS WAFラベル別集計（Bot Control等の検知状況）
- COUNTモード影響シミュレーション
特に最後の COUNTモード影響シミュレーション は意識して設計した部分です。「このCOUNTルールをBLOCKにしたら、どのURIへのリクエストが影響を受けるか」をルール×URIの組み合わせで算出しており、Claudeが移行判定する際の具体的な判断材料になります。
blocked_requests.csv と count_mode_details.csv
それぞれBLOCKされたリクエストとCOUNTモードでマッチしたリクエストの詳細を最大500件ずつサンプリングしたものです。タイムスタンプ、ルール名、IP、国、URI、メソッド、User-Agentなどが含まれます。
統計データだけでは「本当にそのリクエストは悪性なのか？」の判断が出来ないことがあります。そのため、CSVの個々のレコードをClaudeが確認出来るようにしました。Claudeで処理するデータは多くなるものの、より精度の高い分析が可能になっています。
その他、除外ルール機能（特定のルールによるブロックをレポートから除外する環境変数）や、S3ログのライフサイクル設定（30日後にIA、90日後にGlacier、365日後に削除）なども設定しています。
Claude Code カスタムスキルについて
ここが今回の仕組みの要です。
Claude Codeのカスタムスキル（Agent Skills）とは、特定のタスクを実行する際にClaudeが読み込む「指示書」のようなものです。SKILL.md というファイルに分析手順やドメイン知識を記述しておくと、Claudeが必要に応じてそれを読み込んで分析を行います。
Agent Skillsについてご興味のある方は、手前味噌で恐縮ですが下記ブログをご参照ください。
Agent Skills 元年なのでオープンスタンダードになった Agent Skills について調べて使ってみた | DevelopersIO
さて、今回のスキルには、大きく分けて2つのことを埋め込んでいます。
ドメイン知識
まず、AWS WAF構成の前提知識です。BLOCKモード・COUNTモード・ALLOWモードのルール一覧と、それぞれの役割をスキルに記載しています。これにより、Claudeは「このルールはBLOCKで運用中」「このルールはCOUNTで評価中」といった文脈を理解した上で分析を行えます。
次に、正規トラフィックのパターンです。例えば、社内サービスの内部APIではUser-Agentが特定の値になるリクエストが流れており、これがAWS WAFのBot Controlルールにマッチします。このリクエストをBLOCKしてしまうとサービス障害になるため、「このパターンは正規トラフィックなのでBLOCK判定から除外すること」とスキルに明記しています。
また、詳細な内容が分からないサードパーティ製マネージドルールを利用しているため、そのルールに関しては「このルールは不要」と断定せず、「ヒットが少ないため、サービス提供元に確認を推奨」程度の表現に留めるようにしています。
他にも細かいドメイン知識を盛り込んでいますが、詳細は割愛します。
分析ステップ
スキルには以下の7ステップの分析手順を定義しています。
- レポート読み込み — summary.json と CSVファイルを読み込む
- 全体概要の可視化 — Chart.jsでドーナツチャート、折れ線グラフ、横棒グラフを生成
- ルール有効性評価 — BLOCK/COUNT/ALLOWそれぞれの観点でルールを評価し、日本語のコメント付きテーブルを作成
- 脅威分析 — 攻撃種別、攻撃元の国/IP帯域、狙われるURI、時間帯傾向を分析
- COUNTモード移行判定 — 後述する2軸マトリクスによる構造的な判定
- 推奨アクション — High/Medium/Lowの優先度付きでアクションを提示
- HTMLレポート出力 — 上記を全てまとめたスタンドアローンHTMLファイルを生成
COUNTモード移行判定の2軸マトリクス
COUNTモードからBLOCKへの切り替え判断は、以下の2軸で構造化しています。
軸1: 正規トラフィック影響リスク
- 低: マッチしたリクエストが全て明らかに悪性
- 中: 一部判断が難しいリクエストがある
- 高: 正規トラフィック（内部API等）がマッチに含まれる
軸2: セキュリティ効果
- 高: 既存のBLOCKルールでカバーされていない攻撃パターンを検知している
- 中: 既存ルールと一部重複するが追加の検知もある
- 低: ほぼ既存ルールと重複、または検知数が極端に少ない
| 影響リスク低 | 影響リスク中 | 影響リスク高 | |
|---|---|---|---|
| 効果高 | BLOCK推奨 | 慎重にBLOCK（除外ルール付き） | COUNT継続+ホワイトリスト検討 |
| 効果中 | BLOCK推奨 | COUNT継続して様子見 | COUNT継続 |
| 効果低 | BLOCK可（優先度低） | COUNT継続 | ルール削除も検討 |
このマトリクスをスキルに埋め込むことで、Claudeは各ルールを感覚ではなく構造的に判定出来るようになります。
スキルを使う効果
定期的に実施する一連の分析動作とカスタムスキルは非常に相性が良いです。スキルがあることで指示ミスがなくなり、毎回同じ品質のレポートが出力されるため、チームメンバーも確認がしやすくなります。
「WAFレポートを分析して」と一言伝えるだけで、上記の7ステップが全て実行されるのは非常に体験が良いです。
運用しながらスキルを育てていく楽しさ
ここまでの説明を読むと、スキルは最初から完成していたように見えるかもしれませんが、実際にはそんなことはありません。運用しながら少しずつ育てていきました。
実際にあった改善の例をいくつか紹介します。
ALLOWルールがBLOCKとして表示されてしまった
今回のWebACLにはホワイトリスト的に使うALLOWルールがあるのですが、Claudeがこれをグラフ上でBLOCKとして扱ってしまうことがありました。AWS WAFではALLOWもBLOCKと同じく終端アクション（terminating action）としてログに記録されるため、区別がつかなかったのだと思います。スキルにモード別の表示ルールを明記することで解消しました。
レポートが英語で出力されがちだった
ログの内容に引っ張られたのか英語で出力しようとする傾向がありました。自分だけが見るなら英語でも良いのですが、チームメンバーに共有する際にはやはり日本語のほうがスムーズです。テーブルヘッダー、グラフの凡例、評価コメントなど、日本語化すべき箇所を具体的にスキルに定義しました。
こうした改善は大きなコストがかかるものではありません。定例会で「ここちょっと気になるね」という意見が上がれば、それをClaudeに伝えてスキルに反映するだけです。とはいえ、たまに「ベストプラクティスに沿ってスキル全体を見直して」と伝えて、メンテナンスをすることも大事ですね。
分析結果から見えてきた改善すべきAWS WAF運用
2〜3ヶ月運用してきた結果、実際に改善すべきポイントが見えてきました。
まずは直近のレポートをお見せします。
実際のレポート
以下、一部情報はマスクしていますが実際のレポートです。
個人的な好みでダークテーマを採用しています。実際にはHTMLなのでAWS WAFコンソールよろしく、マウスホバーで詳細が表示されるような少しリッチなUIになっています。
全体概要では、1週間の総リクエスト数が約155万件、そのうちブロックされたのは約2,300件（ブロック率0.15%）であることが分かります。
ルール評価テーブルでは、各ルールに対してClaudeが日本語の評価コメントを付けています。例えば、COUNTモードのBotControlルールに対して「BLOCKにするとサービス障害を引き起こす」といった評価が自動的に記載されます。これはスキルに埋め込んだ正規トラフィックの知識が効いている部分です。
COUNTモード移行判定では、例えばKnownBadInputsRuleSetは「影響リスク低・効果高 → BLOCK推奨」、BotControlRuleSetは「影響リスク高 → COUNT維持必須」という判定が出ています。
推奨アクションでは、「KnownBadInputsRuleSetのBLOCK化」がHIGHとして挙がっています。マッチ数がゼロ、つまり正規トラフィックへの影響リスクがゼロでありながら、Log4Shell等のカバー範囲を追加出来るためです。
上記のようなレポートを定期的に確認してきた結果、以下のことが明確になりました。
- 不要なルールや、BLOCKに切り替えるべきルールが特定出来た
- レートベースルールの最適な閾値も見えてきた
ルール管理のガバナンス改善
分析の仕組みを作って終わりではありません。分析結果をもとに実際にルールを変更するためのガバナンスも整備しています。
以前はルールの管理をドキュメントサービス上で行っていたのですが、ルールアクションの変更はほとんど行われておらず、「問題が起きたら変える」という運用になっていました。
そこで、開発者も見えるGitHubリポジトリでルールを管理することにしました。このWAFが保護している対象のサービスは開発者と運用者が密に連携しています。そのため、開発者の方々にもルールを把握しておいてもらえるように、ルールアクションの変更はPRで申請する運用に切り替えました。
現在はその建て付けの最終フェーズで、来月ごろから本格的にルール切り替えに着手する予定です。
AIをセキュリティ運用に組み込んで感じたこと
効率化の実感
スクリプトだけでレポートを作ることも出来ます。ただ、Claudeによる対応推奨コメント、つまり「第三者のアドバイス」がレポートに含まれるのは別の観点として面白い部分です。自分とは違う視点からの意見を取り入れながら運用出来るのは、AIの活用方法としてありだと改めて感じました。
AIの限界と人間の役割
一方で、先述したようにClaudeが100%正しいとは限りません。やはり最終判断は人間が行うべきです。
私たちの場合、その判断・責任を定例会とPRレビューで担っています。AIに言われたことを鵜呑みにするのではなく、運用する人間にも一定の知識が必要です。
また、AIはどうしても最新の脅威情報には対応出来ません。新しい攻撃パターンや悪性のUser-Agentなどは、人間が常日頃キャッチアップしてルールとして追加してあげる必要があります。実際に私も、特定のUser-Agentをブロックするカスタムルールを手動で追加しています。
モデル性能への依存
このシステムの効果は、利用するAIエージェントのモデル性能に強く依存すると感じています。モデルが劣化すれば途端に破綻してしまうシステムです。実際に私は本記事執筆時点で分析の際は必ずOpus4.6を利用するようにしています。
ただし、モデル性能はこれからもどんどん上がっていくはずです。今の仕組みをベースに、モデルが賢くなれば分析の精度も上がっていくと考えています。
最後に
今後の展望としては、来月以降にレポートの分析結果をもとにCOUNTルールのBLOCK切り替えに本格着手する予定です。また、この仕組みは年内に社内の他サービスへの横展開も予定しています。その際はClaudeのカスタムスキルなど各サービス固有のドメイン知識（ルール構成、正規トラフィックパターン）に合わせてカスタマイズする必要がありますね。
取り留めのもない内容だったかもしれませんが、ここまで読んでいただきありがとうございました。また運用に関するノウハウが溜まったらこういう場所でアウトプットしていきたいと考えています。
本記事がどなたかのお役に立てば幸いです。
以上、べこみんでした。
以上、『夏休みの自由研究リレー』の第2回のエントリ『Claudeと一緒にAWS WAF運用をやってみてる話』でした。
次回は tmorio (まると) | DevelopersIO さんの「セルフレジ端末を手に入れたのでイベントのチェックインシステムを作った」の予定です。お楽しみに！！
