0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

新人プログラマ応援 - みんなで新人を育てよう！
@yuta_yokoi_ai

AIクローラー制御はrobots.txtだけでは足りない：WAF・CIDR・ログ観測まで含めた実務メモ

0
Posted at

この記事は、Zennに投稿した完全版
AIクローラー制御の本番実装アーキテクチャ：AIO Bot Governance実践編
の要点整理です。

完全版は Zenn にあります。
完全版では、robots.txt / User-Agent / CIDR / rDNS / FCrDNS / WAF / X-Robots-Tag / Rate Limit / Nginx / Cloudflare WAF / AWS WAF / ipset / iptables / nftables / middleware / ログ観測まで含めて整理しています。

Qiita版では、業務でまず判断するためのエッセンスに絞ります。
ただし、単なるリンク誘導ではなく、Qiita単体でも「AI bot制御で何を分け、何を見て、どこから始めるべきか」が分かるように構成しています。

関連する前回の要点整理はこちらです。

AIクローラーを一括りにするな：robots.txt設計で学習・検索・ユーザーfetchを分ける

この記事で言いたいこと

AIクローラー制御は、robots.txt に数行書いて終わる話ではありません。

重要なのは、次の3点です。

  • robots.txt は 意思表示 であり、防御そのものではない
  • User-Agent は 識別子 であり、証明ではない
  • 本番では、CIDR / rDNS / WAF / Rate Limit / access log を組み合わせる必要がある

つまり、AI bot制御は以下のように考える必要があります。

やること 意味
分類する 学習系・検索系・ユーザーfetch・SNS・RAGを分ける
宣言する robots.txt / X-Robots-Tag で方針を示す
検証する User-Agent だけでなく CIDR / rDNS / ASN を見る
制御する WAF / CDN / Nginx / Rate Limit で強制する
観測する access log / WAF log / status code / request rate を見る
見直す 誤遮断・過負荷・仕様変更を定期確認する

この記事は、完全版のうち 最初に業務へ持ち込むべき判断軸 を抜き出したものです。

前提：AIクローラーは一括りにできない

前提として、AI botは「AIクローラー」と一括りにできません。

たとえば、同じOpenAI系でも以下は別物です。

bot 主な用途 扱い
GPTBot 学習・モデル改善系 止める候補
OAI-SearchBot ChatGPT検索・引用系 通す候補
ChatGPT-User ユーザー起点fetch 観測しながら通す候補
OAI-AdsBot 広告LP検証系 広告運用次第

OpenAI公式も、OpenAI Crawlers で複数のcrawler / user agentを分けて説明しています。

つまり、雑に「OpenAIを許可する」「OpenAIを拒否する」と考えると、判断を誤ります。

重要なのは、会社名ではなく 用途 です。

robots.txtは防御ではない

robots.txt は重要です。
ただし、防御そのものではありません。

robots.txt は、協調的なクローラーに対して、

このURLは読んでよい
このURLは読まないでほしい

と伝えるためのポリシー宣言です。

アクセス制御や認証ではありません。

たとえば、Google公式は user-triggered fetchers について、ユーザー要求で起動するため一般に robots.txt を無視すると説明しています。

一方で、Common Crawl公式は Common Crawl FAQ で、CCBotが robots.txt を確認してからクロールすると説明しています。

つまり、botによって robots.txt の意味が違います。

botの性質 robots.txt の効き方
協調的crawler 効く可能性が高い
公式検索crawler 効く。ただし検索露出への副作用あり
ユーザー起点fetch 別扱いの場合がある
非自己識別bot ほぼ効かない
悪意あるscraper そもそも従わない

そのため、robots.txt は必要ですが、それだけで本番のAI bot制御が完了するわけではありません。

User-Agentは証明ではない

User-Agent も重要です。
しかし、これも証明ではありません。

以下のようなUser-Agentは、誰でも名乗れます。

User-Agent: GPTBot/1.3
User-Agent: OAI-SearchBot/1.3
User-Agent: Googlebot/2.1
User-Agent: Applebot/0.1
User-Agent: ClaudeBot/1.0

そのため、本番では User-Agent だけで判断してはいけません。

見るもの 役割
User-Agent bot分類の第一手掛かり
IP / CIDR 公式レンジかどうかを見る
ASN どの事業者・ネットワーク由来かを見る
rDNS / FCrDNS 公式botの真正性確認に使う
WAF Bot Score 挙動・ヘッダ・環境情報を含めて判定する
request rate 高負荷・異常アクセスを検知する
access log 実際に何が起きているか確認する

Google公式も、Google crawlers and fetchersのリクエスト検証 で、Googlebot等のリクエスト確認方法を説明しています。

通すbot・止めるbot・観測するbotを分ける

AI bot制御で最初に作るべきなのは、ブロックリストではありません。
まずは、通す・止める・観測する の判断表です。

方針 代表例 理由
通す OAI-SearchBot, Amzn-SearchBot, Claude-SearchBot AI検索・引用露出を維持する
止める GPTBot, ClaudeBot, Applebot-Extended 学習・モデル改善用途を拒否する
観測する ChatGPT-User, Claude-User, Perplexity-User ユーザー起点fetchなので robots.txt だけでは不十分
分離する facebookexternalhit, bedrockbot-UUID SNSプレビューやRAGを壊さない
慎重に扱う Bytespider, xAI/Grok系 観測・WAF・Rate Limit前提で扱う

ここで大事なのは、止めることだけが制御ではない という点です。

検索・引用系のbotまで雑に止めると、AI検索や引用露出を失います。
SNSプレビュー系のbotまで止めると、SNS上でリンクカードが壊れます。
RAG / Enterprise Search系のbotを止めると、自社で使う検索・ナレッジベース連携が壊れることもあります。

最小robots.txt例

以下は考え方を示す最小例です。
そのまま本番へコピペするものではありません。

# 学習系は拒否
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Applebot-Extended
Disallow: /

# 検索・引用系は許可
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

# ユーザー起点fetchは許可しつつ観測
User-agent: ChatGPT-User
Allow: /

# SNSプレビューは壊さない
User-agent: facebookexternalhit
Allow: /

Sitemap: https://example.com/sitemap.xml

この例で示したいのは、以下です。

方針 意味
学習系は拒否 モデル学習・改善用途を避ける
検索・引用系は許可 AI検索・引用露出を維持する
ユーザーfetchは観測 ユーザー体験を壊さず監視する
SNS系は分離 OGPプレビューを壊さない
sitemapを明示 発見導線を整える

注意：robots.txt は方針宣言です。
本番では、WAF / CIDR / rDNS / Rate Limit / access log と組み合わせて確認してください。

本番制御はレイヤーで考える

AI bot制御は、1つの設定で完結しません。
以下のレイヤーで考えると整理しやすいです。

レイヤー 役割
robots.txt 方針の宣言
X-Robots-Tag レスポンス単位のindex制御
User-Agent bot分類の第一手掛かり
CIDR / ASN 送信元検証
rDNS / FCrDNS 公式bot真正性確認
WAF / CDN 強制制御
Rate Limit 高負荷抑制
middleware アプリ文脈で判断
access log 誤遮断・過負荷・効果測定

Qiita版では詳細なNginx / WAF / nftables例までは載せません。
完全版はZennにあり、Nginx、Cloudflare WAF、AWS WAF、ipset / iptables / nftables、middlewareまで扱っています。

👉 完全版（Zenn）：AIクローラー制御の本番実装アーキテクチャ

WAF / CIDR / Rate Limitは何を補うのか

robots.txt と User-Agent だけでは足りない部分を、WAF / CIDR / Rate Limitが補います。

仕組み 補うもの 注意点
CIDR allow/block 公式IPレンジ確認 動的同期しないと古くなる
rDNS / FCrDNS User-Agent偽装対策 DNS確認コストがある
WAF 強制遮断・challenge 誤検知に注意
Rate Limit 高負荷抑制 正当なfetchを潰しすぎない
access log 効果測定 見ないと改善できない

AWS公式も、AWS WAFでAI botを管理する記事 で、まずCount modeで観測してから制御へ進む考え方を示しています。

いきなりBlockするのではなく、最初は 観測 から始めるのが安全です。

ログで見るべき項目

AI bot制御は、設定して終わりではありません。
実際に何が来ているかを見ます。

見る項目 理由
User-Agent bot分類の第一情報
IP / ASN 公式botか偽装かを見る
rDNS Googlebot等の真正性確認
path robots.txt / llms.txt / sitemap.xml / API へのアクセス確認
status code 200 / 403 / 404 / 429 / 5xxの確認
request rate 高負荷botやバースト検知
referrer / query AI由来流入の兆候を見る
WAF action allow / block / challenge / count の確認
cache status SSR / ISR / サーバーレス負荷を見る

最低限、以下のような観点で見ます。

{
  "timestamp": "2026-05-01T12:00:00+09:00",
  "client_ip": "203.0.113.10",
  "method": "GET",
  "path": "/llms.txt",
  "status": 200,
  "user_agent": "OAI-SearchBot/1.0",
  "bot_family": "openai",
  "bot_type": "search",
  "waf_action": "allow",
  "rate_limited": false
}

ログがない状態でWAFだけ強くすると、何を壊したか分かりません。

誤遮断すると何が壊れるか

AI bot制御で怖いのは、不要なbotを止め損ねることだけではありません。
必要なbotを止めてしまうこと も危険です。

誤って止める対象 壊れるもの
Googlebot SEO
OAI-SearchBot ChatGPT検索・引用露出
ChatGPT-User ユーザーURL要約体験
Applebot Spotlight / Siri / Safari系露出
facebookexternalhit SNSプレビュー
bedrockbot-UUID 自社RAG取り込み
Google-CloudVertexBot Agent Search / Vertex AI連携
AmazonAdBot 広告LP検証

つまり、AI bot制御は「強くブロックすれば良い」ではありません。

業務では、以下の順序が安全です。

Phase やること
1 目的を決める
2 まずログで観測する
3 robots.txt で方針を宣言する
4 WAFはCount modeから始める
5 正規botをallowlistする
6 学習系・高負荷系・偽装系から制御する
7 403 / 429 / 5xxと検索・SNS影響を見る

業務で使う最小チェックリスト

最後に、実務で使う最小チェックリストです。

設計チェック

チェック OK
学習系・検索系・ユーザーfetchを分けた
SNS/OGP botを学習系と混同していない
RAG / Enterprise Search botを契約範囲で限定した
広告検証botの扱いを決めた
Common Crawlの収録方針を決めた

実装チェック

チェック OK
robots.txt が200で返る
sitemap.xml が正しい
User-Agent 分類ルールがある
CIDR / ASN / rDNSの扱いを決めた
WAFはCount modeから始める
Rate Limitが過剰でない
SNSプレビューを検証した

運用チェック

チェック OK
botログを保存している
403 / 429 / 5xxを監視している
WAF actionを見ている
誤遮断時のロールバック手順がある
bot仕様変更を定期確認する

完全版はこちら

この記事では、AI bot制御の要点だけを整理しました。

より詳細な実装パターン、各bot別の扱い、誤遮断リスク、業務導入ロードマップ、本番チェックリスト、参考URL集は以下の Zenn完全版 にまとめています。

AIクローラー制御の本番実装アーキテクチャ：AIO Bot Governance実践編

完全版では、以下まで扱っています。

  • OpenAI GPTBot / OAI-SearchBot / ChatGPT-User
  • Amazonbot / Amzn-SearchBot / Amzn-User / Bedrock / Kendra
  • Anthropic ClaudeBot / Claude-User / Claude-SearchBot
  • Meta ExternalAgent / facebookexternalhit
  • Googlebot / Google-Extended / Google-CloudVertexBot
  • Applebot / Applebot-Extended
  • PerplexityBot / Perplexity-User
  • Common Crawl CCBot
  • ByteDance / Bytespider
  • xAI / Grok
  • Nginx / OpenResty / Cloudflare WAF / AWS WAF
  • ipset / iptables / nftables
  • middleware / access log / Rate Limit

まとめ

AIクローラー制御は、robots.txt だけでは足りません。

robots.txt は方針の宣言です。
User-Agent は自己申告です。
本番では、CIDR / rDNS / WAF / Rate Limit / access log を組み合わせて、通すbot・止めるbot・観測するbotを分ける必要があります。

重要なのは、すべてを止めることではありません。

  • AI検索に出したいbotは通す
  • 学習に使わせたくないbotは止める
  • ユーザー起点fetchは観測する
  • SNSプレビューbotは壊さない
  • RAG / Enterprise Search botは契約範囲で限定する

この整理がないままWAFやBlockを強めると、SEO、AIO、SNS、RAGを壊します。

AI bot制御は、セキュリティだけの話ではありません。
SEO、AIO、SNS、RAG、広告、インフラ負荷を同時に扱う Web公開の運用設計 です。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?