AI ボットがクロールバジェットを圧迫している？GPTBot などの管理方法

AIのクロールバジェットは今や現実的な課題です。分かりやすく説明します。

AIクローラーとGoogleの違い：

クロール量と紹介比率の問題：

ClaudeBotは何万ページとクロールしても、訪問者はほぼ送らない。

GPTBotも同様 ― 膨大なクロール、即時トラフィックは最小。

単純なブロックを勧めない理由：

AIクローラーをブロックすれば、あなたのコンテンツはAI回答に載らなくなります。クロールを許可した競合がその可視性を得ます。

戦略：ブロックせずに選択的に管理する。

AIクローラー負荷のインフラ視点です。

14日間の測定結果：

AIボットはリクエスト数は少ないのに、ほぼ同じ帯域を消費。

リソース計算：

AIクローラーは1リクエストあたり2.5倍多くデータを要求。効率的なインクリメンタルクロールではなく、フルHTMLをモデル学習用に取得しています。

サーバーへの影響：

• AIクロール波のたびにCPUスパイク
• 同時リクエストでメモリ圧迫
• 動的コンテンツならDBクエリも発生
• 実ユーザーへの影響の可能性

我々の対策：

1. キャッシュレイヤー - CDNでAIボット対応、オリジン保護
2. レート制限 - AIクローラーごとに2リクエスト/秒
3. キュー優先度 - 実ユーザーを最優先、ボットは後回し
4. モニタリング - AIクロール急増時にアラート

制御導入後、サーバーヘルスが40%改善しました。

可視性トレードオフの観点です。

ジレンマ：

AIクローラーをブロック＝サーバー負荷なし、AIでの可視性なし
AIクローラーを許可＝サーバー負荷、AIでの可視性あり

ブロック時に起こること：

あるクライアントサイトでGPTBotを3ヶ月ブロックしてみました：

• サーバー負荷22%減少
• AIによる引用85%減少
• ChatGPTでの競合言及増加
• 2ヶ月で方針撤回

より良いアプローチ：

ブロックしない、管理する。

管理の階層：

1. CDN/キャッシュ - エッジでボット対応
2. レート制限 - 遅くする、止めない
3. 選択的ブロック - 低価値領域のみブロック
4. コンテンツ最適化 - クロール対象を価値あるものに

ROI計算例：

AIトラフィックがオーガニックの5倍コンバージョンするなら、わずかなAIトラフィック増でもサーバー投資に見合う。

サーバーコスト：月$200増
AIトラフィック価値：月$2,000
結論：クロール許可

JavaScriptレンダリングについての重要な指摘。

問題点：

ほとんどのAIクローラーはJavaScriptを実行しません。

つまり：

あなたのコンテンツがJavaScriptレンダリング（React, Vue, Angular SPA）なら、AIクローラーには何も見えません。

我々の発見：

AIクローラーが何千回もサイトにアクセスしていたのに、空ページしか取得できていませんでした。全コンテンツがクライアントサイドで読み込まれていたためです。

対策：

重要コンテンツをサーバーサイドレンダリング（SSR）に。

結果：

同じクロールバジェットで引用23倍。

JavaScriptフレームワーク運用中なら、引用してほしいページはSSRを。そうでなければ空ページへのクロールバジェット浪費です。

サーバーログ分析のコツ。

AIクローラー識別方法：

注目すべきユーザーエージェント文字列：

• GPTBot
• ChatGPT-User（リアルタイムクエリ）
• OAI-SearchBot
• ClaudeBot
• PerplexityBot
• Amazonbot
• anthropic-ai

分析アプローチ：

1. 30日分のログをエクスポート
2. AIユーザーエージェントでフィルタ
3. URLパターン分析
4. クロール浪費を計算

発見：

AIクロールバジェットの60%が以下に浪費されていた：

• 内部検索結果
• 5ページ目以降のページネーション
• 2018年のアーカイブページ
• テスト/ステージングURL

対策：

robots.txtでこれらをDisallow。

AIクローラーの有効クロール率が40%→85%に向上。

継続的な監視：

ダッシュボードで以下を追跡：

• ボットごとのAIクローラーボリューム
• 最も頻繁にクロールされるURL
• クロール時のレスポンス時間
• クロール浪費率

ブロックすべき正当なケース。

AIクローラーをブロックすべき合理的理由：

1. 法的コンテンツ ― 古い法律情報など、引用されると問題なもの
2. コンプライアンス関連 ― 責任が発生する規制対象の情報
3. 機密データ ― 企業秘密、研究内容
4. センシティブコンテンツ ― ユーザー生成や個人情報

例：

2019年の法律アーカイブを持つ法律事務所。AIがこれを現行法として引用すればクライアント被害も。/archive/legislation/ をAIからブロック推奨。

選択的ブロックの例：

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: PerplexityBot
Disallow: /archived-legal/
Disallow: /user-generated/
Disallow: /internal/
Allow: /

ブロックすべきでないもの：

価値あるコンテンツ、ブログ、商品ページ、サービス説明。AIに引用してほしいものです。

基本方針：

特別な理由がない限り、許可が基本。

llms.txtという新しい標準について。

llms.txtとは？

robots.txtに似ていますが、AIクローラー専用。LLMにどのコンテンツを使ってよいか伝えます。

現状：

導入初期。まだすべてのAIプロバイダが遵守していません。

llms.txt例：

# llms.txt
name: 会社名
description: 事業内容
contact: ai@company.com

allow: /products/
allow: /services/
allow: /blog/

disallow: /internal/
disallow: /user-content/

今導入すべき？

はい ― 先進的な姿勢を示せ、近い将来AIシステムに尊重される可能性。

今後：

AIクロールが成熟すれば、より高度な制御が可能に。今のうちから備えを。

現状ツール：robots.txt
新興：llms.txt
将来：より細かなAIクローラー制御

素晴らしい議論です。自分のAIクロールバジェット管理プラン：

即時（今週）：

1. サーバーログでAIクローラーパターンを分析
2. クロール浪費（アーカイブ、ページネーション、内部検索）を特定
3. robots.txtを選択的ブロックで更新
4. CDNレベルでレート制限導入

短期（今月）：

1. AIボットトラフィック用のCDNキャッシュ設定
2. 監視ダッシュボード導入
3. JavaScriptコンテンツのSSRテスト
4. llms.txtファイル作成

継続：

1. 毎週クロール効率をレビュー
2. AIによる引用率を監視
3. サーバー容量に応じてレート制限調整
4. AIリファラートラフィックとクロール量を追跡

主な決定：

• AIクローラーを全面ブロック『しない』―可視性が大事
• 2リクエスト/秒にレート制限
• 低価値領域のみ選択的ブロック
• CDNでオリジンサーバーを保護

バランス感覚：

サーバーヘルスもAI可視性も重要。ブロックではなく管理。

皆さん、ありがとうございました ― 実用的です。