【ITニュース解説】Yandex Bot Traffic Fell 99 Percent Overnight. Here's How to Measure and Block the AI Crawlers Hitting Your Own Server

最近、インターネット上で私たちが目にするウェブサイトの多くは、人間だけでなく、プログラムによって自動的に動く「ボット」からのアクセスで成り立っている。このボットによるトラフィックがサーバーに大きな負担をかけ、場合によっては問題を引き起こすことが増えている。ここでは、この問題の背景と、システムエンジニアを目指す初心者が知っておくべき対策について解説する。

まず、最近話題になったYandex（ロシアの検索エンジン大手）の事例を見てみよう。ウクライナからのドローン攻撃によりYandexのデータセンターが被災した際、Cloudflareのデータによると、Yandexからのボットトラフィックがほぼ一夜にして99%も減少したという。これは、普段私たちが意識していないだけで、特定のボットネットワークがいかに大量のアクセスを生成しているかを示す驚くべき例だ。特に近年、人工知能（AI）の進化に伴い、ウェブサイトの情報を収集する「AIクローラー」と呼ばれるボットの活動が爆発的に増えている。これらのAIクローラーは、ウェブサイトにアクセスして情報を集めることで、AIの学習データになったり、新しい検索エンジンやチャットボットの知識源となったりする。しかし、これらの大量のアクセスはサーバーのリソース（CPUやネットワーク帯域）を消費し、ウェブサイト運営者がそのコストを負担している。

このようなボットによるサーバーへの負担を軽減し、安定したサービスを提供するためには、まず現状を正確に把握することが重要になる。そのための一番手軽な方法は、サーバーが記録している「アクセスログ」を分析することだ。多くのウェブサーバー（NginxやCaddyなど）では、アクセスログに「User-Agent（ユーザーエージェント）」という情報が記録されている。これは、アクセスしてきたクライアント（ウェブブラウザやボット）が自分自身を識別するために送る情報で、「Googlebot」（Googleの検索エンジンクローラー）や「Mozilla」（一般的なウェブブラウザ）といった文字列が含まれている。アクセスログを分析するコマンドラインツール（awk, sort, uniq, grep, wcなど）を使えば、どのUser-Agentがどれくらいの頻度でアクセスしているかを簡単に調べることができる。例えば、awkでUser-Agentの列を抽出し、sortとuniq -cで同じUser-Agentをまとめてカウントし、sort -rnで多い順に並べ、head -20で上位20件を表示するといった具合だ。これにより、「Bytespider」や「PerplexityBot」、「meta-externalagent」といったAIクローラーの名前を見つけることができるだろう。

次に、これらのAIクローラーがどれくらいの割合を占めているかを確認する。特定のAIクローラーのUser-Agent文字列をキーワードにgrepコマンドでログを検索し、そのヒット数と全体のログ行数をwc -lで数えれば、割合を計算できる。もしAIクローラーからのリクエストが全体の5%未満であれば、簡単な対策で十分な場合が多いが、30%を超えるようなら、より積極的な対策を検討する必要がある。

さらに重要なのは、これらのAIクローラーが「どのページ」をクロールしているかだ。アクセスログを分析して、User-Agentがボットやクローラーらしき文字列を含むアクセスが、具体的にどのURLに集中しているかを確認できる。特に、データベースへの問い合わせが多いページや、複雑な計算が必要なページなど、サーバーに負担をかける「重い」ページが狙われやすい傾向にある。過去には、Amazonのクローラーが、Gitリポジトリの履歴や差分表示といった高負荷なエンドポイントを集中的にクロールし、サーバーをダウン寸前に追い込んだ事例もある。これは意図せずサービス拒否攻撃（DoS攻撃）のような状態を作り出すことになりかねない。

これらの分析結果に基づいて、段階的に対策を講じていくのが一般的なアプローチだ。

まず最も簡単な対策は「robots.txt」ファイルを設置することだ。これはウェブサイトのルートディレクトリに置かれるテキストファイルで、どのクローラーにどのページへのアクセスを許可・拒否するかを記述する。GooglebotやGPTBot、ClaudeBotなど、多くの主要なAIクローラーはrobots.txtの指示に従う。しかし、robots.txtはあくまで「お願い」であり、悪意のあるクローラーや、User-Agentを偽装するクローラーには効果がないという限界がある。

次に、「レートリミット」という対策がある。これは、同じIPアドレスからのリクエスト数に制限をかけるもので、Nginxのlimit_reqモジュールやCaddyのレートリミット機能などで設定できる。単一のIPからの大量アクセスには有効だが、多数の異なるIPアドレスから分散してアクセスしてくるAIクローラーには効果が薄いことが多い。

さらに高度な対策としては、「Web Application Firewall (WAF)」の導入や、「Cloudflare」のようなCDNサービスを利用する方法がある。Cloudflareの「Bot Fight Mode」などは強力なボット対策機能を提供しているが、すべてのトラフィックを外部サービス経由でルーティングすることに抵抗がある場合や、自社サーバーで完結させたい場合には向かない。

そこで登場するのが、オープンソースの「Anubis（アヌビス）」というツールだ。Anubisは、自社でサーバーを運用している場合や、特定のベンダーに依存したくない場合に非常に有効な「最終手段」と位置づけられている。Anubisはウェブサーバーとアプリケーションの間に「リバースプロキシ」として配置され、すべてのリクエストを検査する。そして、設定されたポリシーファイル（YAML形式）に基づいて、リクエストを「許可 (ALLOW)」、「拒否 (DENY)」、「チャレンジ (CHALLENGE)」、「重み付け (WEIGH)」のいずれかに分類し、適切な処理を行う。

Anubisの最も特徴的な機能の一つは、「Proof-of-Work（プルーフ・オブ・ワーク）」によるチャレンジだ。ウェブブラウザからのアクセス（User-Agentに「Mozilla」が含まれるものなど）と判断された場合、Anubisはコンテンツを直接返す代わりに、一時的なページを表示する。このページにはJavaScriptコードが含まれており、アクセスしてきたブラウザに特定の計算（SHA-256ハッシュ計算）を行わせる。この計算には一定の時間がかかり、現代のデスクトップPCなら数秒、スマートフォンなら十数秒かかることもある。この計算をクリアして初めて、正規のウェブサイトコンテンツにアクセスできるという仕組みだ。通常のウェブブラウザであれば問題なくこのチャレンジをクリアできるが、JavaScriptエンジンを持たない単純なHTTPクライアント（多くのAIクローラーがこれにあたる）では計算が不可能であり、コンテンツへのアクセスが実質的に阻止される。

また、Anubisは「ai.robots.txt」プロジェクトで公開されている既知のAIクローラーのUser-Agentリストに基づいて、それらを直接拒否する設定も可能だ。多くのAIクローラーは正直に自身のUser-Agentを名乗るため、このデンジャーリスト（拒否リスト）で大量のAIトラフィックをシャットアウトできる。Proof-of-Workは、User-Agentを偽装したり、リストに載っていないボットに対する「税金」のようなものだ。

さらに面白い点として、Anubisがリクエストを拒否またはチャレンジする際に、HTTPステータスコードとして「403 Forbidden」ではなく「200 OK」を返すという工夫がある。これは、多くの攻撃的なスクレイパー（情報収集ボット）が403のようなエラーコードを一時的な問題とみなし、より積極的にリトライを繰り返す傾向があるためだ。代わりに200 OKと、本来のコンテンツとは異なるダミーのページを返せば、スクレイパーはページが正常に取得できたと誤解し、それ以上同じページにアクセスしなくなる。

ただし、Anubisの導入にはいくつかの注意点がある。 一つは、JavaScriptを実行できないクライアント（例えばRSSリーダーやSlackのリンクプレビュー、サイト監視ツールなど）からのアクセスがブロックされてしまうことだ。これらに対しては、明示的に許可するルールを設定する必要がある。 二つ目は、Anubisを複数台のサーバーで水平にスケールさせるのが難しい点だ。Anubisは起動するたびに新しいキーペアを生成するため、ロードバランサーの背後で複数台を運用すると、あるインスタンスが発行した認証クッキーが別のインスタンスでは無効とみなされてしまう。また、Anubisを再起動するたびに、既存の認証クッキーが無効になり、すべてのユーザーが再度Proof-of-Workチャレンジを受けることになる。 三つ目は、Anubisは高度な攻撃者に対しては万能ではないということだ。専門的な知識と予算を持つ攻撃者は、ヘッドレスブラウザ（GUIを持たないブラウザ）などを用いてProof-of-Workチャレンジを突破できてしまう。Anubisは、主に「小規模なサーバーを押しつぶすような、大量で怠惰なAIクローラー」を阻止するための負荷軽減ツールであり、標的型の攻撃を防ぐための認証システムではないと認識しておくべきだ。

Anubisは、Docker Composeを使えば比較的簡単に導入できる。ウェブアプリケーションの前面にAnubisを配置し、Anubisのポリシーファイルで、特定のパス（例えばrobots.txtやRSSフィード）は許可し、既知のAIクローラーは拒否し、それ以外のブラウザからのアクセスにはProof-of-Workチャレンジを課すといったルールを設定する。

システムエンジニアを目指す皆さんへのアドバイスとして、まず自分のサーバーのアクセスログを分析し、現在のボットトラフィックの状況を正確に把握することから始めるべきだ。次に、比較的低コストで導入できるrobots.txtやレートリミットから対策を始め、サーバーの負荷が本当に問題になってから、Anubisのようなより強力なツールを検討するのが賢明だ。その際も、検索エンジンクローラー（Googlebotなど）を安易にブロックすることは避けるべきだ。検索エンジンからのアクセスが失われると、ウェブサイトの可視性が大きく損なわれる可能性があるため、そのコストは非常に大きい。

今日のウェブは、人間と機械が入り混じった複雑な環境であり、小規模なサーバーを運用する個人でさえ、かつては専門のセキュリティチームが担当していたようなトラフィック管理の課題に直面している。Anubisのようなツールの登場と、それがGNOMEやkernel.orgといった重要なプロジェクトで採用されている事実は、この問題がどれほど現実的であるかを物語っている。自身のサーバーを守るためにも、まずは自分のサイトのログを分析し、ボットトラフィックの現状を理解することが第一歩となる。