一番来ていたのはGPTBotではなかった。自社ログ5日間・AIクローラー23,464件の実測レポート

AIクローラーを許可するかブロックするかの判断の分かれ目は、「来ているボットが学習用か、回答生成用か」の見分けに尽きます。自社コーポレートサイトの生アクセスログ5日間（2026年8月1日〜5日）を実測したところ、総リクエスト479,212件のうちAIクローラーは23,464件（約5%）。そして最多は、学習用のGPTBotではなく、ChatGPTがユーザーの質問に答えるためにリアルタイムでページを取りに来るChatGPT-Userの13,961件でした。GPTBot（1,008件）の約14倍です。

2026年8月現在のスナップショットとして言い切ると、中規模の企業サイトに来るAIボットの主役はすでに「学習クローラー」ではなく「回答生成のためのリアルタイム取得」です。つまり、AIクローラーを一括ブロックすると、モデル学習を拒否する以上に「今まさにChatGPT上で自社が紹介されようとしている機会」を直接失います。本稿はこの実測値を一次データとしてそのまま公開し、内訳の読み方と許可・ブロックの判断基準まで示します。

なお、robots.txtの具体的な記述手順はAIクローラーごとのrobots.txt設定手順、ログ集計の分析手法そのものはAIクローラーログ分析の方法で扱っています。本稿は「実際にどれくらい来るのか」という実測値の公開と、その解釈に役割を絞ります。

AIクローラーの実測とは何か（定義）

AIクローラーの実測とは、WebサーバーのアクセスログからAI企業のボットのUser-Agent（GPTBot、ChatGPT-User、PerplexityBotなど）を抽出し、実際の訪問回数・比率・内訳を数えることです。推定ツールや外部統計ではなく、自社サーバーに残った生の記録を数えるため、「自社サイトにAIがどれくらい来ているか」に対する唯一の一次データになります。世界全体の集計値（CDN事業者のレポートなど）とは傾向が大きくずれることがあり、自社の許可・ブロック判断は自社ログで行うのが原則です。

AIボットは役割で3種類に分かれます。この区別が本稿全体の読み解きの軸です。

実測データ公開：5日間・479,212リクエストの内訳

計測条件は次のとおりです。

• 対象: 自社コーポレートサイト（uravation.com）の生アクセスログ
• 期間: 2026年8月1日〜8月5日の5日間
• 集計方法: User-Agent文字列によるAIボットの抽出・件数集計
• 総リクエスト数: 479,212件
• うちAIクローラー: 23,464件（約5%、1日平均約4,693件）

内訳は次のとおりです。構成比はAIクローラー23,464件を分母にしています。

この表から読み取れる事実は3つあります。

1. ChatGPT-Userが単独で約6割。AIボット訪問の過半は「学習」ではなく「ユーザーの質問への回答生成」のために発生している
2. OpenAI系3ボットの役割比が極端。ChatGPT-User 13,961件に対しGPTBot 1,008件。学習クローラーの約14倍の頻度でリアルタイム取得が来ている
3. ClaudeBotは154件と少数。世界全体の集計ではClaudeBotの比率が大きいとする報告もあり、個別サイトのログは全体統計と大きくずれる。だからこそ自社ログの実測に意味がある

なぜChatGPT-Userが最多なのか。3種類のボットの役割で読み解く

OpenAIは公式ドキュメント（OpenAI「Bots」、2026年8月9日参照）で、3つのボットの役割を明確に分けています。

• GPTBot: 生成AI基盤モデルの学習用。robots.txtでDisallowすると「学習に使わないでほしい」という意思表示になる
• OAI-SearchBot: ChatGPTの検索機能でサイトを検索結果に表示するためのボット。学習には使われない
• ChatGPT-User: ユーザーがChatGPTやCustom GPTでページ訪問を伴う操作をしたときに動く。公式ドキュメントは「これらの操作はユーザーが開始するため、robots.txtのルールが適用されない場合がある（robots.txt rules may not apply）」と明記

つまりChatGPT-Userの13,961件は、5日間で延べ1万回以上、「ChatGPT上の誰かの質問に答える文脈で自社サイトのページが取得された」ことを意味します。これは学習クローラーの巡回とは性質がまったく違います。学習クローラーをブロックしても失うのは「将来のモデルに入るかもしれない可能性」ですが、ChatGPT-Userを遮断すると「今この瞬間にAI回答内で自社が参照される機会」をリアルタイムで失います。

主要ボットのrobots.txt準拠状況を公式ドキュメントベースで整理すると次のようになります。

補足が2点あります。第一に、ユーザー起点ボットのrobots.txt非準拠はOpenAIとPerplexityの両方が公式に明記している仕様であり、「行儀の悪いボット」ではなく設計思想です。ユーザーがブラウザでページを開く行為に近い扱いをしています。第二に、Bytespider（ByteDance）は用途・準拠方針を説明する公式の詳細ドキュメントが2026年8月時点で確認できず、本稿では挙動を断定しません。今回の実測でも165件（0.7%）と少数でした。

Google-Extendedが0件だった理由：そもそもログに現れない

今回の集計でGoogle-Extendedは0件でしたが、これは「Googleが来ていない」という意味ではありません。Google公式のクローラードキュメント（Google Search Central「Google's common crawlers」、2026年8月9日参照）は、「Google-Extendedは独自のHTTPリクエストUser-Agent文字列を持たない。クロールは既存のGoogleのUser-Agentで行われ、robots.txtのユーザーエージェントトークンは制御目的で使われる」と明記しています。

つまりGoogle-Extendedは、Geminiの学習やグラウンディング（回答の根拠付け）への利用可否をrobots.txtで指定するための「制御トークン」であり、アクセスログには通常のGooglebotとして記録されます。ログをいくら探してもGoogle-Extendedという文字列が出てこないのは仕様どおりです。同ドキュメントは、Google-Extendedの設定がGoogle検索への掲載やランキングに影響しないことも明言しています。

この仕様を知らないと「Geminiには全然クロールされていない」と誤読しがちです。ログ集計の正しい読み方はAIクローラーログ分析の方法で詳しく扱っています。

実測値から導く許可・ブロックの判断表

実測の内訳と各社の公式仕様を踏まえると、判断は「ボットの役割 × 自社の方針」の掛け合わせで決まります。自社の実測でユーザー起点ボットが約6割を占めた事実を前提に、標準的な判断を整理します。

判断で外してはいけないのは次の1点です。「AIに学習されたくない」と「AI検索に出たくない」は別の意思決定であり、robots.txtは両者を別々のUser-Agentで制御できるように設計されています。GPTBotだけをDisallowし、OAI-SearchBotとChatGPT-Userの経路は残す、という組み合わせが可能です。具体的な記述例はAIクローラーごとのrobots.txt設定手順にまとめています。

自社ログで同じ集計をする手順チェックリスト

同じ実測は、サーバーのアクセスログ（Apache/Nginxの共通フォーマット）があれば10分程度でできます。

• レンタルサーバーの管理画面またはSSHでアクセスログ（access.log）を取得する
• 集計期間を決める（曜日偏りを避けるため最低5〜7日分を推奨）
• 総リクエスト数を数える
• AIボットのUser-Agentを抽出して件数を数える
• 「AIクローラー合計 ÷ 総リクエスト」で比率を出す
• ChatGPT-User（ユーザー起点）とGPTBot（学習用）の比を確認する

コマンドは次の2つで足ります（ログファイル名は環境に合わせて変更してください）。

<pre><code># 総リクエスト数 wc -l access.log

grep -oE "GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|meta-externalagent|Bytespider|Google-Extended" access.log \ | sort | uniq -c | sort -rn</code></pre>

ログが複数ファイルに日別分割されている場合は、cat access.log.2026-08-0{1..5} > combined.log のように結合してから同じコマンドを実行します。gzip圧縮されている場合は zcat に読み替えてください。

集計したら、次の2つの数字だけはメモしておくことをおすすめします。

1. AIクローラー比率（今回の実測では約5%）: 半年後に再計測したときの変化量が、自社サイトへのAI経由の関心の推移を示す自社専用の指標になる
2. ChatGPT-User対GPTBot比(今回は約14倍): この比が大きいほど、自社サイトは「学習される対象」ではなく「回答の根拠として参照される対象」になっている

よくある失敗例

実測とその解釈の場面で、実際に起きがちな失敗を挙げます。

• 失敗例1: 「AIクローラー」をひとくくりにして全部ブロックする。学習拒否のつもりで、ChatGPT検索の表示機会（OAI-SearchBot）とAI回答での参照機会（ChatGPT-User）まで巻き込んで失う。役割別に分けて制御するのが原則
• 失敗例2: Google-Extendedがログにないので「対応不要」と結論する。Google-ExtendedはログにUser-Agentとして現れない制御トークン。学習利用を拒否したいならログではなくrobots.txt側で指定する
• 失敗例3: robots.txtに書けばChatGPT-Userも止まると思い込む。公式仕様上、ユーザー起点の取得にはrobots.txtが適用されない場合がある。確実に遮断したいならWAFやUser-Agentベースのサーバー側制御が必要（ただし前述のとおり参照機会を失う）
• 失敗例4: 1〜2日分のログで結論を出す。ChatGPT-Userはユーザーの質問に連動するため日次変動が大きい。最低5〜7日分で集計する
• 失敗例5: 世界全体の統計を自社に当てはめる。CDN事業者などの全体集計と個別サイトのログは順位も比率も大きくずれる。今回の実測でもClaudeBotは0.7%と、全体統計の印象とはまったく違う結果だった

FAQ：AIクローラーの実測についてよくある質問

AIクローラーは実際、1日にどれくらい来ますか？

今回の実測（中規模コーポレートサイト・2026年8月1日〜5日）では、1日平均約4,693件のAIボットアクセスがあり、総トラフィックの約5%でした。ただしこの数字はサイトの規模・知名度・コンテンツ量で大きく変わります。自社の数字は上記のコマンド2つで10分程度で確認できるので、外部の統計より自社ログの実測を優先してください。

AIクローラーを全部拒否（遮断）しても大丈夫ですか？

技術的には可能ですが、失うものを理解した上で判断すべきです。今回の実測ではAIボット訪問の約6割がChatGPT-User、つまり「AI回答の根拠として参照される瞬間」のアクセスでした。全遮断は学習拒否と同時にAI検索・AI回答での紹介機会を失う選択です。学習用（GPTBot等）だけをDisallowし、検索・参照系は許可する分離制御を推奨します。

robots.txtでChatGPT-Userをブロックできますか？

確実にはできません。OpenAIの公式ドキュメントは、ChatGPT-Userによる取得はユーザーが開始する操作のため「robots.txtのルールが適用されない場合がある」と明記しています。Perplexityも同様に、Perplexity-Userは原則robots.txtを無視すると公式に説明しています。どうしても遮断したい場合はWAFなどサーバー側での制御が必要です。

CloudflareなどのCDNでAIクローラーをブロックすべきですか？

CDNのボット管理機能を使えばrobots.txtに従わないボットも遮断できますが、一括の「AIボットブロック」を有効にするとChatGPT-UserやOAI-SearchBotまで止まり、AI検索経由の流入・参照機会を失います。使う場合も、学習用クローラーと検索・ユーザー起点ボットを分けて設定できるかを確認してから有効化してください。

Google-Extendedがアクセスログに1件もないのはなぜですか？

仕様どおりです。Google公式ドキュメントによると、Google-Extendedは独自のUser-Agent文字列を持たず、クロール自体は既存のGoogleのUser-Agent（Googlebot等）で行われます。Google-Extendedはrobots.txtに書いて「Geminiの学習・グラウンディングに使わないで」と指定するための制御トークンであり、ログに現れないのが正常です。

結論と次の一歩

5日間・479,212リクエストの実測から得られた結論は明快です。自社サイトに来るAIボットの主役はChatGPT-User（59.5%）であり、学習用GPTBot（4.3%）ではありませんでした。AIクローラー対応の議論は「学習させるか否か」に偏りがちですが、実測が示すのは、企業サイトがすでに「AI回答の参照元」として毎日数千回単位で読まれているという現実です。ブロック判断はこの参照機会の価値を織り込んで行う必要があります。

次の一歩は3つです。

1. 自社のアクセスログで同じ集計をする（本稿のコマンド2つ・10分程度）
2. 役割別の制御方針を決め、robots.txtの設定手順に沿って学習用と検索・参照用を分離する
3. 継続的な傾向把握にはAIクローラーログ分析の方法で定点観測の型を作る

「自社サイトがAIにどう読まれ、どう説明されているか」をログの外側（実際のAI回答側）から確認したい場合は、LLMO診断で現状把握から始められます。まずは自社ログの5%が何をしに来ているのか、数えるところからで十分です。

計測情報: 本記事の実測値は、Uravation運営サイトの生アクセスログ（2026年8月1日〜5日・総479,212リクエスト）をUser-Agent文字列で集計した一次データです。各ボットの仕様は2026年8月9日時点の各社公式ドキュメントを参照しています。仕様は変更されることがあるため、最新の公式情報も併せてご確認ください。