自社サービスのアクセスログを見て、ボットからのリクエスト比率に驚いた経験はないでしょうか。Cloudflare（Webサイトの前段に立ってトラフィックを中継・保護するCDNおよびセキュリティサービス）は2025年6月時点で、インターネット全体のトラフィックの半分以上がボットによるものだと公表しています。AIモデルの学習データ収集や、ユーザーの代わりにWebを操作するAIエージェントが増えたことが背景にあります。
この記事は、自社サイトやAPIにAIクローラー（Webページを自動巡回してデータを収集するプログラム）がどれだけアクセスしているか気になっているエンジニア、あるいはCloudflareのようなリバースプロキシ層でボット制御の設定を任されたインフラ担当者に向けたものです。ブロックするか許可するか、あるいは条件付きで許可するか、判断の材料を整理しました。
なぜ「全部ブロック」では済まなくなったか
少し前まで、ボット対策といえば「悪意のあるスクレイピングを止める」というシンプルな話でした。
しかし今のAIクローラーには、少なくとも3種類の目的が混在しています。学習データ収集のためのクローラー、検索やチャット回答の裏で参照するためのクローラー、そしてユーザーに代わって予約や購入を実行するAIエージェントです。
Cloudflare CEOのMatthew Prince氏がPodcast「Decoder」で語ったように、Cloudflareはサイト運営者とAIツールの間に立つ立場を利用して、単純な「許可／拒否」だけでなく、アクセスに対価を求める仕組みの検討も進めています。つまり判断はもう二択ではなく、「誰に」「何の目的で」「対価を取るかどうか」まで踏み込む必要が出てきています。
判断軸1: トラフィックの正体を可視化できているか
最初に確認すべきは、自分たちのアクセスログがボットとAIエージェントを区別できているかどうかです。
User-Agent（リクエスト元のソフトウェアを識別する文字列）だけを見て「これはGooglebotだから許可」「知らない文字列だから拒否」と判断している場合、実態を見誤ります。悪質なクローラーほどUser-Agentを偽装するためです。
CloudflareのようなCDN層を使っている場合は、ボット判定スコアやJA3/JA4フィンガープリント（TLSハンドシェイクの特徴からクライアントの種類を推定する技術）といった、User-Agent以外のシグナルを使った可視化機能が提供されています。まずはダッシュボードでボットカテゴリ別のリクエスト数を1週間分見てみるのが出発点です。
判断軸2: そのボットは自社に利益をもたらすか
次に考えるべきは、そのクローラーが自社のビジネスにとってプラスかマイナスかです。
検索エンジンのクローラーはインデックスされることで流入を生みます。一方でAI学習用クローラーは、コンテンツを取り込むだけで、直接的な参照トラフィックを返さないことが多いという指摘があります。いわゆる「Google Zero」問題、つまり検索結果でAIの要約が表示され、元サイトへのクリックが減っていく懸念です。
コンテンツが広告収益やサブスクリプションで成り立っているメディアやSaaSのドキュメントサイトであれば、この軸の重みは大きくなります。逆に社内向けAPIやB2Bの技術ドキュメントで、AIに参照されること自体が営業チャネルになる場合は、許可側に倒す判断もあり得ます。
判断軸3: エージェントによる「実行」を許すか
閲覧目的のクローラーと違い、AIエージェントは予約・購入・フォーム送信などの「実行」を伴います。
これはセキュリティとビジネスロジックの両方に関わる判断です。ECサイトであれば、AIエージェント経由の購入を許可するのか、それとも人間のチェックアウトフローだけを想定するのか、事前に決めておく必要があります。
認証やレート制限、CAPTCHA（人間かどうかを判定する仕組み）の設計は、この判断によって大きく変わります。エージェントを想定しない設計のままだと、意図しない大量リクエストやカート放棄の増加につながる可能性があります。
判断軸4: 対価を求める運用に耐えられるか
最後の軸は、ボット制御の仕組みそのものの運用負荷です。
Cloudflareが検討しているような「アクセスに課金する」モデルは魅力的に見えますが、実装・請求・例外対応の運用コストが発生します。個人開発者や小規模チームであれば、単純な許可・拒否ルールに留めた方が現実的です。
選択肢の比較
判断軸を踏まえたうえで、実際に取り得る対応を整理します。
| 選択肢 | 向いているケース | 運用負荷 |
|---|---|---|
| 全面ブロック | コンテンツが収益源そのもの、学習データ流用を強く避けたい | 低い |
| クローラー種別ごとに許可 | 検索流入は欲しいがAI学習は避けたい | 中程度 |
| 全面許可 | ドキュメントやOSSなど拡散が価値になるコンテンツ | 低い |
| 課金・対価モデル | 大量のAI企業からアクセスされる規模のメディア | 高い |
ケース別の推奨
自社のドキュメントサイトやAPIリファレンスで、AIツールに参照されることが認知拡大につながる場合は、全面許可に近い設定を選ぶのが自然です。robots.txtでAI関連クローラーを個別に許可し、あえて制限しない選択です。
広告収益やサブスクリプションが主な収益源のメディアサイトであれば、検索エンジンのクローラーだけを許可し、AI学習用クローラーは種別ごとにブロックする設定が現実的です。CloudflareのAI Botsマネージドルールのような、クローラーカテゴリ単位で制御できる機能を使うと、User-Agentを1つずつ管理する手間を避けられます。
ECサイトやログイン必須のSaaSであれば、閲覧系クローラーの制御に加えて、AIエージェントによる自動操作を許すかどうかを個別に決める必要があります。決済や個人情報を扱うフローでは、まずエージェント経由のアクセスを制限し、必要になった時点で段階的に開放する方が安全です。
あえて見送るべき条件
一方で、次のような場合は課金モデルや細かいクローラー種別制御に手を出さない方が無難です。
- チームの人数が少なく、ボット制御ルールの継続的なメンテナンスに割ける工数がない
- サイトのトラフィック規模が小さく、AIクローラーによる負荷や収益影響がまだ計測できていない
- ボット判定の可視化すら行っていない段階で、いきなり複雑な許可・拒否ルールを組もうとしている
こうした条件に当てはまる場合は、まずログの可視化と基本的なレート制限だけを整えて、実態を数週間観察してから細かいルールを検討する順番が合理的です。
まとめ
AIクローラーへの対応は、もはや「ブロックするかしないか」の二択ではありません。
可視化・利益判定・エージェント対応・運用負荷という4つの判断軸で、自社サイトの立ち位置を整理することが出発点になります。
次の一歩としては、CDNやWAFのダッシュボードでボットカテゴリ別のアクセス比率を確認し、robots.txtと実際のブロックルールが一致しているかを見直すところから始めてみてください。数字を見てから決めても遅くはありません。