Amazon Web Services ブログ
AWS WAF で AI ボットを管理し、セキュリティを強化する方法
本稿は、2025 年 8 月 1 日に公開された “How to manage AI Bots with AWS WAF and enhance security” を翻訳したものです。
最初の Web クローラーは 1993 年に Web のサイズを測定する目的で作成されましたが、現在ではエージェント型 AI を搭載した最新のボットへと進化しています。今日のインターネットは、AI 関連タスクをサポートするためにアプリケーションと対話する自動化された AI ボットによって、ますます占有され支配されるようになっています。
私たちは AI ボットを 3 つのタイプに分類しました：
- AI スクレイパー: AI モデルをトレーニングするために、アプリケーションから体系的にデータを収集します。
- AI ツール : 関数呼び出しを使用して、AI アプリケーション内でアプリケーションのデータを表示します。
- AI エージェント : 複雑なタスクを実行するために、アプリケーションを自律的にナビゲートし、動的に対話できます。
AI ボットの中には、面倒なタスクを自動化するといった価値あるサービスを提供するものもありますが、悪意のあるボットは Web アプリケーションの所有者や運用者にとって深刻な問題となる可能性があります。悪意のあるボットは過剰なトラフィックでサーバーを圧倒し、パフォーマンスの低下やシステム停止を引き起こします。こうしたボットを野放しにすると、セキュリティが侵害されるだけでなく、ユーザーからの信頼を失い、ブランドイメージを損なうことにもつながります。
この記事では、AI ボットが引き起こすさまざまな問題について考察し、Amazon Web Services (AWS) WAF を使用して AI ボットを検出・管理するさまざまな手法について学びます。
前提条件
本記事では、アプリケーションへの AI ボットのアクティビティを監視・管理する最前線の防御として、AWS WAF に焦点を当てています。AWS WAF による保護をまだ有効化していない場合は、まず AWS Shield network security director を使って脅威の全体像を可視化することから始めましょう。これにより、AWS WAF で保護されていないリソースを特定できます。
その後、ワンクリックセキュリティ統合機能を使用して、初期セキュリティ体制を構築できます。この機能は、最も一般的な脅威からアプリケーションを保護するルールを含む保護パックまたは Web ACL を自動的に作成します。詳細については、以下のリファレンスを参照してください：
- Amazon CloudFront を使用してアプリケーションをホストしている場合は、CloudFront ワンクリック AWS WAF 統合を使用して保護を有効にします。
- Application Load Balancer (ALB) を使用してアプリケーションをホストしている場合は、ALB ワンクリック AWS WAF 統合を使用して保護を有効にします。
AI ボットによって引き起こされる問題
ボットは Web 上の新しい脅威ではありません。ただし、大規模言語モデル (LLM) が必要とする大量のデータや、AI エージェントが可能にした新たな対話パターンにより、多くのアプリケーションでボットの挙動がより問題視されるようになりました。Web アプリケーションは、AI ボットにより次のような問題に直面する可能性があります：
- 独自データをモデルのトレーニングに使用される : 組織のデータが無許可で AI モデルのトレーニングに使用されると、知的財産に関する懸念が生じます。たとえば、あなたのコンテンツが対価なしに競合サービスの作成に利用され、コンテンツの独自の市場価値が低下する可能性があります。
- パフォーマンスの低下とコストの増加 : アプリケーションのコンテンツを積極的に収集する AI ボットは、膨大なトラフィックを発生させ、正規ユーザーのパフォーマンスを低下させる可能性があります。これにより、データ転送送信 (DTO) 料金が発生し、コンピューティングリソースが浪費されるほか、スクレイピングのピーク時にはサービス停止が発生する可能性もあります。
- 望ましくない自動/エージェント動作 : AI ボットは、人間が介在することなくアプリケーションと自動的に対話できます。AI が結果を要約できるため、アプリケーションへの貴重な人間のトラフィックを奪う可能性があります。また、AI ボットは、限定在庫の購入など、高価値で時間的制約のあるワークフローを完了するために、正規の人間のトラフィックと競合する可能性もあります。これらのボットは通常、以下の手法を使ってアプリケーションと対話します：
-
- 関数呼び出しと AI 検索 : AI アプリケーションはツールを使って、アプリケーションから直接データを検索し、単発のリクエストを実行します。
- ブラウザ自動化フレームワークによる対話 : Amazon Nova Act などの AI エージェントは Playwright を使用して実際のブラウザを制御します。複数ステップのタスクを完了し、人間のような方法でアプリケーションと対話できます。これらのエージェントは JavaScript を実行し、複雑な UI 要素を効果的に処理することが可能です。
- VM ベースの対話 : Anthropic の Computer Use のようなシステムは、仮想マシン (VM) 環境内で動作します。より人間に近い方法でアプリケーションと対話し、Playwright の自動化ブラウザとは異なり、標準にインストールされたブラウザを使用します。そのため、その動作は実際の人間ユーザーとほぼ区別できません。
AI ボットアクティビティの規模を把握する
まず、AI ボットがどのようにアプリケーションに影響を与えているか、またその規模を理解する必要があります。最初のステップとして、検査レベル Commonで AWS WAF Bot Control ルールグループをリソース保護パックに追加しましょう。初期段階では Count モードを使ってトラフィックパターンを監視します。このアプローチにより、本番環境のトラフィックに影響を与える可能性のある変更を行う前に、ボットアクティビティを分析できます。
Bot Control の Common ルールグループは、署名検証によって自己申告ボットを検証します。このルールグループには、検証済み AI ボットを検出する CategoryAI ルールが含まれています。図 1 に示すように、必ず最新バージョンでルールグループを設定してください。
図 1: 検査レベル Common およびバージョン 3.2 の AWS WAF Bot Control ルールグループ
マネージドルールグループを数日間実行した後、収集したデータを分析できます。インサイトを表示するには、AWS WAF および AWS Shield コンソールを開き、AWS リージョンを選択します。保護パックを選択してダッシュボードを表示を選択します。 概要セクションに移動し、ボットオプションを選択すると、ボットアクティビティ、検出、カテゴリ、シグナルを確認できます。このダッシュボードでは、アプリケーション上のボットアクティビティに関するインサイトが得られます。
図 2 は、Bot categories セクションの例を示しています。ai - AllowedRequests としてマークされた大量のリクエストが表示されています。これらは CategoryAI ルールによって検出されたものの、ブロックはされていない AI ボットです。また、他のボットも大量のリクエストを送信している様子が確認できる場合があります。
図 2: AWS WAF が検出した CategoryAI ルールのトラフィック概要
AI ボットによって引き起こされる問題の管理
以下のセクションでは、AI ボットによって引き起こされる問題を管理するためのさまざまな方法について説明します。
robots.txt で AI ボットを早期に停止する
シナリオ 1 : ルール準拠AIボットの早期遮断
robots.txt ファイルを使用すると、アプリケーションに対するボットのアクセスを制御できます。このシンプルなテキストファイルをアプリケーションのルートディレクトリ（/robots.txt）に配置し、標準形式でルール準拠ボットに対してアクセス可能範囲を指示します。すべてのボットがこれらのルールに従うわけではありませんが、信頼できるボット事業者は適切に構成された robots.txt ファイルを尊重します。ai.robots.txt などのオープンソースプロジェクトでは、最新のAI関連クローラーを含む robots.txt が提供されており、アプリケーションのクロール開始前にこれらのボットを停止できます。
AWS WAF で特定のボットからの大量リクエストが検出された場合、robots.txt を使用して、過剰ながらもルールに従うスクレイピングボットを停止できます。これにより、DTO およびアプリケーションパフォーマンスへの影響を防止できます。
次の例は、Amazon Amazonbot に /public URL のクロールを許可し、/private URL のクロールを禁止する設定です。
User-agent: Amazonbot
Disallow: /private/
Allow: /public/
シナリオ2:AIボットのデータ使用方法を管理
主要なテクノロジー企業のボットは二重の目的で動作します。アプリケーションを一度スクレイピングし、取得したデータを検索インデックス化とAIモデルのトレーニングに利用します。これらのボットに対して、検索インデックス作成を目的としたアプリケーションのクロールは許可しつつ、LLMトレーニングへのデータ使用は拒否するよう指定できます。次に示すのは、主要なボット運用事業者がLLMのトレーニングにデータを使用することを防止する3つの例です。
- Amazonbot : HTTP レスポンスヘッダー
X-Robots-Tag: noarchiveを使って、このレスポンスを LLM の学習に使用しないよう指示します。CloudFront のレスポンスヘッダーポリシーを利用することで、アプリケーションから返されるすべてのレスポンスにこのヘッダーを付与できます。HTTP/1.1 200 OK
Date: Tue, 15 Oct 2024 08:09:00 GMT
X-Robots-Tag: noarchive - Applebot :
robots.txtに User-agent Applebot-Extended という項目を追加することで、Apple の機械学習（ML）モデルの学習にアプリケーションのデータを使わせないよう要請できます。この設定でも、検索用のコンテンツインデックス作成は引き続き Apple に許可されます。以下は、アプリケーション全体で Applebot-Extended のアクセスを拒否する記述例です。User-agent: Applebot-Extended
Disallow: /robots.txtにおけるUser-agentディレクティブは、特定の目的を持ちます。このディレクティブは、ボットが宣言するアイデンティティに対してパターンマッチングを実行しますが、これは HTTP User-Agent ヘッダーとは異なるものです。 - Googlebot : 同じように、Google も
robots.txtに User-agent Google-Extended を追加することで、Google の ML モデル学習へのデータ使用を拒否できます。User-agent: Google-Extended
Disallow: /
robots.txt ファイルを尊重しないボット運用者も存在するため、そうしたボットは AWS WAF で管理する必要があります。
AWS WAF を使用した対策
シナリオ 3 :パフォーマンス低下と高コストの原因となる AI ボットの管理
過度にデータをスクレイピングする AI ボットは、アプリケーションの性能を悪化させ、DTO やコンピューティングの費用を大幅に増加させる恐れがあります。以下に紹介する AWS WAF を使った手法で、robots.txt のルールを守らないボットからアプリケーションを守ることができます。
1 . AWS WAF Bot Control ルールグループ(検査レベル Common)を使った自己識別 AI ボットの管理
検査レベル Common の AWS WAF Bot Control ルールグループにおいて、以前「Count」としていたすべてのルールアクションをオーバーライドを解除することで、AI ボットからの大量アクセスを防ぐことが可能です。CategoryAI ルールにより、これらの AI ボットリクエストは標準でブロックされるようになっています。
CategoryAI ルール配下の AI ボットを除き、AWS WAF は一般的かつ検証可能なボットをブロックしません。大量のトラフィックを生成している検証済みボットやボットカテゴリを特定した場合は、図 3 に示すように、AWS WAF Bot Control ルールグループの後方に、特定のボット（またはラベル名前空間で表現されるボットクラス）をブロックするルールを明示的に追加する必要があります。
図 3：ラベルを活用し yandexbot をブロックするための AWS WAF のカスタムルール設定
2. 検知回避を試みるスクレイパーの速度抑制
ボットは、有名なボットや正当なユーザークライアントになりすますため、HTTP ユーザーエージェントヘッダーを偽造します。AWS WAF の拡張されたアプリケーション層（L7）DDoS 保護と AWS WAF レートベースルールを利用することで、これらのボットによるアプリケーションへの過剰な負荷を防ぐことができます。DDoS ルールとレート制限ルールにより、ボットを含む大量リクエストを行うすべてのソースからアプリケーションを守ることができます。レートベースルールのしきい値の設定方法や最適な作成方法については、AWS WAF の主要な 3 つのレートベースルールに関する記事をご覧ください。
3. 検知回避を試みるスクレイパーに負荷をかける
AWS WAF の Challenge アクションは、ユーザーの介入なしでクライアント環境においてサイレントチャレンジを実行します。これはユーザー体験に認識可能な影響を与えないよう設計されています。このチャレンジでは、クライアントに計算コストの高い作業（プルーフオブワーク）の実行を要求します。この方式により、正当なユーザーに対しては環境検証のためのシームレスな仕組みを提供する一方で、アプリケーションにアクセスを試みるボット運用者のコストを上昇させることを意図しています。
図 4 では、AWS WAF Bot Control ルールグループの後方にカスタムルールを追加する方法を示しています。このルールでは、許可済み/検証済みボットを除き、ユーザーが処理を継続する前にチャレンジの完了を必要とします。検証済みボットは、awswaf:managed:aws:bot-control:bot という名前空間内のラベルにより識別されます。
図 4：未検証のボットトラフィックに対してチャレンジを強制する AWS WAF ルール
4 . 巧妙なボットの捕捉にハニーポットを活用
Security Automations for AWS WAF には、ハニーポットエンドポイントが組み込まれています。このエンドポイントは、正当なユーザーや適切な振る舞いをするボットがアクセスしないように設計されており、アプリケーションをクロールするボットを誘い込む仕組みとなっています。アプリケーションへのスクレイピングの影響を抑制するため、検知した IP アドレスをブロックします。
シナリオ 4：不要な自律型/エージェント型 AI ボットへの対処
自律型 AI ボットへの対処には、次の技術を活用できます：
1 . AWS WAF Bot Control ルールグループ（検査レベル Common）：CategoryAI ルールには、Amazon Nova Act などの広く認識された AI エージェントへの対応ルールが含まれています。また、SignalNonBrowserUserAgent と SignalAutomatedBrowser の各ルールにより、Playwright タイプのブラウザ自動化エージェントをブロックすることができます。
2 . AWS WAF Bot Control ルールグループ（検査レベル Target）：このレベルの検査では、トラフィックパターンの知的ベースラインを構築します。人間をシミュレートするエージェント型ボットからアプリケーションを守るため、フィンガープリンティング手法を活用します。設定手順の詳細については、高度なボットトラフィックの検知・ブロックに関する投稿をご確認ください。
3 . AWS WAF CAPTCHA アクション：主要プロバイダーが提供する LLM は、CAPTCHA を解決しないよう学習されています。これにより、多くのエージェントによる要求された操作の完了を防ぐことができます。前述の チャレンジ 技術と同様に、特定のリクエストに対して CAPTCHA の完了を要求するルールを設定できます。設定手順の詳細については、「Use AWS WAF CAPTCHA to protect your application against common bot traffic」の投稿をご確認ください。
4 . 認証（生体認証を含む）：ボットは継続的に進化し、対策を回避するようになっていきます。人間による操作を厳密に要求する場合は、やり取りを継続する前に、生体認証を含む認証の使用を検討してください。ボットトラフィックの可能性を示す動作が確認された際の適応的なユーザー認証の実装方法については、「How to use AWS WAF Bot Control for targeted bots signals and mitigate evasive bots with adaptive user experience」の記事を参照してください。
まとめ
AI ボットは、パフォーマンスを低下させコストを増加させる過剰なスクレイピング、AI トレーニングのための不正なコンテンツ使用、迷惑なものから悪意のあるものまで様々な自動化された操作を通じて、重大な課題を引き起こします。本記事で説明した基本的な robots.txt の設定から、高度な AWS WAF Bot Control ルール、レート制限、CAPTCHA チャレンジまでの戦略を実装することで、不正なデータスクレイピングから保護し、パフォーマンスの低下を防ぎ、AI ボットによるコンテンツの使用方法を制御することができます。
さらに、AWS WAF の最新情報については、AWS WAF Security Blog および AWS Security, Identity, and Compliance の新着情報をご参照ください。
本記事をお読みいただき、ありがとうございます。本記事に関するご質問がある場合は、AWS WAF re:Post で新しいスレッドを開始するか、AWS サポートまでお問い合わせください。
著者
翻訳は Solutions Architect の長谷川 純也が担当しました。