どーも、bubobuboです。
APIの過剰利用から学ぶBot対策
最近、とある生成AIサービスのAPIを活用して、Pythonのスクリプトを組んで生成AIを回し続けたところ、実行頻度が高すぎてアカウントに恒久的な制限（要するにBAN）がかけられてしまった、という事例を耳にしました。
これはAPIを使い倒した経験のある人なら、一度はやってしまいそうな出来事ではないかと思います。
課金して正規のAPIキーを取得したのに、想定外の制限に引っかかってしまうのは、悔しいけれどもありがちです。公式にAPIが提供されているということは、スクリプトからサービスを呼び出されることを前提としていますが、その呼び出し頻度については別途規定されているものと見るべきでしょう。何事もやり過ぎは良くありません。
これはAPIの利用規約や、サーバー資源の観点からは避けられない問題です。
APIが提供されていないサービスでは、Seleniumなどのツールでブラウザを自動操作するBot（自動化プログラム）を作成したり、ブラウザが行うHTTP(S)通信を部分的に真似するスクリプトを書くことで対処を試みる人もいますが、サービス提供側から見れば、歓迎されない行為になります。
なぜかというと、Botが使われることで、サーバーから想定以上の「資源」を引き出されてしまい、サービス全体の安定性を脅かすことにつながるからです。
しかしながら、このような動作は、Googleなどが行う検索エンジンのクローラーや、生成AIが行うデータ収集（スクレイピング）と技術的には大差がありません。
タレスのレポートによると、2024年のBotによるウェブトラフィックは、全ウェブトラフィックの51％に達しており、人力によるトラフィックを上回る結果になったようです。この変化の大きな要因はAIやLLM（大規模言語モデル）の台頭です。これらを実現するには膨大な学習データが必要であり、データ収集のためにBotを回し続ける必要があります。さらに、チャットAIは利用者との対話のなかから、必要に応じてウェブ検索を行うので、そのぶんのトラフィックも加わります。
参考：生成AIによる検知困難なボットが増加 インターネットトラフィックの過半数が自動化されたボットによるものに（PR TIMES）
では、サービス提供側はどう対応すべきでしょうか？ 今回は、こうした第三者のBot行動とその対策を、情報セキュリティの視点から記してみます。
Botはどこからが迷惑行為か
ブラウザ操作の自動化は、SeleniumやPlaywright、Cypressなどを使ったスクリプトを書くことで実現できます。
画面上部に自動化されたアクセスである旨が表記されている
URL入力欄が赤くなり、ロボットのアイコンが表示されるため自動化されたアクセスであることがわかりやすい。
ブラウザ操作の自動化は、Webアプリケーションのテストを自動化するために使われることが期待されていますが、スクレイピング目的で使われることもあります。むしろこちらのほうが一般的でしょう。また、転売屋が行っているとされる自動購入スクリプトの実行も無視できません。
そして、悪性Botが日常的に行っている、パスワードリスト攻撃（不正に入手したアカウント情報を用いて次々とログインを試みる行為）などの不正ログインについては、被害を低減させるためにログイン画面にBot検知を実装するなどの積極的な対策が求められます。
Webアプリケーションのテストの自動化が目的であれば、自身が管理するサーバーに対して行うものなので、それは問題ではありません。しかし、スクレイピングであれば第三者が管理するサーバーに対して行うものなので、高頻度でのアクセスを行わないように工夫する必要があります。しかし、取得効率を考慮するとギリギリのラインを攻めたくなります。BANはされたくはないが、効率は高めたい訳ですが、どこからが迷惑行為になるのかというと、これがわかりにくい。
この件に関連する大きな軋轢を挙げると、国内ウェブサイトにて「毎秒１リクエスト」の通信がサイバー攻撃とみなされた事件がありました。この事件の根本的な原因は、リクエストを受け付けるサーバー側の不具合にあり、攻撃の意図がないことも明白でしたが、不具合による責任を認めず、事の問題をシステム業者に丸投げする態度を取ったことに加え、警察の捜査手法にも問題があったことから、嫌疑不十分ではなく起訴猶予処分となってしまいました。
※起訴猶予とは、前科はつかないものの、嫌疑不十分とは違い「犯罪事実は認められたため検察が起訴すれば有罪にできるが、今回は大目に見てやる」といったもので、ここでは「警察の捜査には問題はなかった」という意味になります。
現在では、前述した生成AIが行うスクレイピングにおいて、著作権侵害の訴訟が増えています。
参考：読売新聞、米国の生成AI事業者を提訴 「サイトの記事を無断利用」（毎日新聞 、2025年8月7日）
参考：OpenAI、The New York Timesとの訴訟でユーザーデータ保存命令に控訴（ITmedia、2025年6月7日）
このことから、Botとスクレイピングの関係においては「技術的には同じでも、意図と規模が違えば問題になる」と考えるべきでしょう。
Bot対策の具体例
ここからは、Bot対策の技術的な対応例を挙げてみましょう。
クライアント側で行うBotツールの検知
ブラウザ側で動作するJavascriptコードの記述で、ブラウザがSeleniumなどで自動操縦されていないかを確かめる方法がいくつかあります。
例えば、BrowserScanというウェブサイトでは、ブラウザからのアクセスでわかる様々な情報を確認することができますが、Bot検出の確認を行うページがあります。そこにアクセスすると、さまざまなテクニックによる検出結果を確認することができます。
参考：browserscan.net - Best BrowserScan Fingerprint Detection Tool - Improve your online privacy security
以下のスクリーンショットは、Chrome＋Seleniumによるアクセス結果です。
スクリーンショットを見ると、Webdriver（ブラウザを外部から自動操作するための仕組み）の存在が検知されていることが確認できます。
これでbot対策は万全…なんてことはなく、Seleniumを使いながらでも回避できる方法も当然存在します。Chromeの場合はWebdriverの存在を隠すライブラリがあります（Firefoxの場合は回避方法は無いようです）。
そのため、さまざまな検出テクニックや予防策を組み合わせて多層化する必要があります。
行動分析による拒否
どのブラウザを使用しているのかを表すUser-Agentをチェックする方法があります。昔からある方法ながら、この値は自己申告なので容易に回避されてしまいますが、迂闊なBotに限ればこの検知テクニックは有効です。
IPアドレスによる制限もありますが、接続元を変えてつなぎ直す方法があるので、もう少し工夫が必要です。また、VPNユーザーを誤検知してしまうケースも発生します。日本のVPN利用率は1%に過ぎませんが、海外では20%以上いるようです。これは、海外ではプライバシー意識やエンタメ検閲回避の問題が強いことが挙げられます。
参考：2025 VPN Usage Statistics（security.org）
ブラウザ上でのマウス移動や、クリック速度、文字列の入力速度などの行動パターンを監視するテクニックもあります。Botであればこれらの行動パターンは手作業とは思えないほど高速であったり、等間隔であったり、必要最小限過ぎる動作であったりします。しかしながら、Bot側もこれらの対策を見越して、さらなる対策をかけてくるので、そうなると対応は難しくなってきます。
これらの問題を請け負うサービスとしては、Cloudflare Bot Managementが有名です。
クローラー拒否
robots.txt や、htmlにおけるmetaタグ（noindex/nofollow）にクローリング（スクレイピングを含む）を拒否するための記述を入れたり、IPアドレスが公開されているクローラを .htaccess で制限する対策もありますが、これは紳士協定のようなものでしかありません。一部の検索エンジンが行うクローリングはこの設定を無視しますし、悪意の有無に関係なく多くのBotは無視するでしょう。
ちなみに、国・自治体・独立行政法人など公益性の高い公的機関のウェブサイトは、国立国会図書館が行うクローリングに限っては拒否をすることができないため（国立国会図書館法第25条の3第2項に基づく特例）、これらのウェブサイトがクローリングの一律拒否を行っている場合は違法状態となってしまいます。
レート制限
IPアドレスやフィンガープリント（ブラウザやデバイスの設定・バージョンなどを組み合わせてユーザーを一意に識別する技術）、APIキーなどでユーザーを一意に識別してからリクエストの上限設定を行うことで、過度なアクセスを防ぐ方法があります。AWS API Gatewayのスロットリング制限が有名だと思います。
ユーザー認証の強化
CAPTCHA/ReCAPTCHA（画像認証）や２要素認証を使ってBot判別を行う方法があります。ただし、近年の生成AIの画像認識能力の向上によりCAPTCHA/ReCAPTCHAの有効性は低下しています。２要素認証は有効な手法ですが、ユーザー体験が著しく減少するので使うかどうかは悩みどころです。
監視やサーバーログの分析
アクセスログをリアルタイムでモニタリングすることで異常検知を実施して、Botユーザーを即時排除する方法があります。SplunkやElastic Stackを使ったログ監視がよく使われます。
まとめ
Botと自動化は、技術的には同じでも「意図」と「規模」によって、利便性の向上にも迷惑行為にもなり得ます。検索エンジンや生成AIのように、データを集めることで新たな価値を生み出すサービスが受容されるケースもあれば、ECサイトの自動購入スクリプトのように混乱を招くケースもあります。
不正アクセスの観点では、悪性Botが行うパスワードリスト攻撃などの不正ログインに備えて、ログイン画面にBot検知を実装するなどの積極的な対策が必要になります。
完璧なBot対策は難しいですが、多層防御を組み合わせることで、サーバー資源を守る、公平性の阻害から守る、さらに誤検知とユーザー体験のバランスを取ることが必要な世の中になってしまいました。
最後に、Bot対策は「攻撃者の排除」や「いたちごっこ」ではなく、サービスの信頼性を確保するための「設計思想」であるべきだと考えます。そう考えれば、ある程度の問題に遭遇したとしても、ユーザー体験を損なわずにサービスを継続させていくことができるはずです。
