AWS WAF が Web Bot Auth (WBA) をサポート。AIボットやクローラーのなりすましを「署名検証」で検出可能になりました

2025年11月21日（現地時間）、AWS WAF において Web Bot Auth (WBA) のサポートが発表されました。

https://aws.amazon.com/jp/blogs/machine-learning/reduce-captchas-for-ai-agents-browsing-the-web-with-web-bot-auth-preview-in-amazon-bedrock-agentcore-browser/

これまで、検索エンジンのクローラーやAIエージェントの識別は、IPアドレスリストやUser-Agent などに依存していましたが、今回のアップデートにより、HTTPリクエストに含まれる暗号化署名を用いた、より確実なリクエスト元の確認が可能になりました。

本記事では、Web Bot Auth (WBA) の概要とAWS WAFにおける変更点、そして実際に当ブログ（DevelopersIO）のWAFログを確認して分かった「現時点でのWBA署名の普及状況」について紹介します。

Web Bot Auth (WBA) とは？

Web Bot Auth (WBA) は、ボットの正当性を暗号技術で証明する新しい標準プロトコル（IETFドラフト）です。従来のIPやUser-Agentに依存した不確実な識別とは異なり、以下の3ステップで確実な認証を行います。

1. 署名 (Signing): AIエージェント等のボットが、自身の秘密鍵を使用してリクエストに電子署名を付与し送信します。
2. 検証 (Verification): 受け手（AWS WAF等）が公開鍵を取得して署名を検証し、改ざんやなりすましがないか確認します。
3. 許可 (Access): 署名が有効なら「正規ボット」として許可（ALLOW）。署名が無効であれば「なりすまし」として即座に排除、またはCAPTCHA等の厳格な検証を適用することが可能になります。

AWS WAF での挙動の変化

CloudFront(Global)の Bot Control マネージドルールで、バージョン4.0 の選択が可能になりました。

WBAをサポートしたバージョン4.0以降の Bot Control マネージドルールでは、次のラベルが利用可能になりました。

• awswaf:managed:aws:bot-control:bot:web_bot_auth:verified - WBA 検証済み（署名検証成功）
• awswaf:managed:aws:bot-control:bot:web_bot_auth:failed - WBA 検証失敗
• awswaf:managed:aws:bot-control:bot:web_bot_auth:expired - WBA 認証期限切れ
• awswaf:managed:aws:bot-control:bot:web_bot_auth:unknown_bot - WBA 未知のボット

このラベルを利用して、WBA検証を満たした場合に「ALLOW」とし、なりすましではない正規検証済みボットの誤検知（偽陽性：False Positive）によるブロックを回避できます。

ルールの記述例（WBA検証済みボットを許可）:

        - Name: AllowVerifiedWBABots
          Priority: 200
          Action:
            Allow: {}
          Statement:
            LabelMatchStatement:
              Scope: LABEL
              Key: awswaf:managed:aws:bot-control:bot:web_bot_auth:verified

確認してみた

当ブログ (DevelopersIO) の Bot Control ルールのバージョンを最新(4.0)に更新し、ラベルに awswaf:managed:aws:bot-control:bot:web_bot_auth を含むリクエストの発生を確認してみました。

使用した CloudWatch Logs Insights クエリ:

fields @timestamp, 
       httpRequest.clientIp as clientIp,
       httpRequest.country as country,
       httpRequest.uri as uri,
       httpRequest.httpMethod as method,
       action
| parse @message /\"name\":\"[Uu]ser-[Aa]gent\",\"value\":\"(?<userAgent>[^\"]*)\"/
| parse @message /\"name\":\"(?<label>[^\"]*web_bot_auth[^\"]*)\"/
| filter @message like /awswaf:managed:aws:bot-control:bot:web_bot_auth/
| display @timestamp, clientIp, country, uri, method, userAgent, action, label
| sort @timestamp desc
| limit 100

従来の bot:verified との比較

従来から利用可能だったラベル awswaf:managed:aws:bot-control:bot:verified（認定済みBot）として判定されたリクエストは、以下の通り多数確認できました。

しかし、2025年11月、当記事執筆時点での観測範囲では、WBA署名付き（web_bot_auth ラベル付き）のリクエストはまだ1件も確認できませんでした。

【参考】従来の検証方法による Verified Bot トップ20（WBA署名は無し）

考察：導入時の注意点

今回の調査結果からも分かる通り、現時点では主要なボットであってもWBA署名を送信してきていないケースが大半と推測されます。そのため、「WBA検証済み以外はすべてブロックする」といった厳格なルールを今すぐ適用してしまうと、WBA未対応の正規ボットまで遮断してしまうリスクがあります。

現段階では、既存の保護ルールはそのまま維持しつつ、「WBA検証に成功したリクエストは、許可（ALLOW）する」 というホワイトリスト的な利用に留めることが、副作用を回避しつつ安全に導入する上で効果的と考えられます。

まとめ

近年、生成AIの普及に伴い、様々なAIエージェントがWebサイトにアクセスするようになりました。同時に、正規のボットになりすましてデータを収集（スクレイピング）したり、攻撃を仕掛けたりする悪意のあるボットも増加しています。

従来のIPアドレスベースやフィンガープリントによる許可リスト管理は、変更頻度や管理コストの面で限界がありました。WBAのような署名ベースの標準規格が今後普及する事で、AWS WAF 利用者は 「正規のAIボットはアクセスを許可、なりすましはブロックする」 という制御を、より安全かつ運用負荷をかけずに実現しやすくなります。

今後、主要なAIプロバイダーや検索エンジンがこの仕様に準拠していくことで、Webトラフィックの健全性がより高まることが期待されます。AWS WAF をご利用の方は、Bot Control のバージョンを上げる事で、WBA 関連のラベルがWAFのログで確認できるようになりますので、ぜひお試しください。

また、WBA検証を求めるWAFが今後普及すると、Webクロールを実施するAIエージェントでも、WBAサポートが求められる事が予想されます。Amazon Bedrock AgentCore での WBAサポートについては、公式ドキュメントや2025年10月に公開されたAWSブログなどを参考に、対応をご検討ください。

参考リンク

• Reducing CAPTCHAs with Web Bot Auth - Amazon Bedrock

https://aws.amazon.com/jp/blogs/machine-learning/reduce-captchas-for-ai-agents-browsing-the-web-with-web-bot-auth-preview-in-amazon-bedrock-agentcore-browser/

https://blog.cloudflare.com/web-bot-auth/

• IETFドラフト原文: HTTP Message Signatures for automated traffic Architecture