AIクローラーログ分析

TL;DR — AIクローラーログ分析とは、サーバーの生のアクセスログを確認し、OpenAIのGPTBotやAnthropicのClaudeBotなど、どのAIボットが実際にサイトを訪れたか、頻度、取得した内容を調べることです。これを記録する場所はログだけです。Google Search ConsoleはAIボットを表示せず、Google Analyticsはクリックして訪問する人だけを見て、ボット自体は見ません。注意点は、有名なAIボットを名乗るトラフィックの多くが本物ではないため、名前だけを信頼できないことです。

ログファイルとは

サーバーアクセスログは、ユーザーエージェント、時刻、パス、設定されていればレスポンスの詳細を含め、サーバーに到達したリクエストを記録します。 Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files クローラーのベンダー文書はユーザーエージェントを識別しますが、文字列だけではリクエスト元が本物だと証明できません。 Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

人のブラウザ、Googlebot、GPTBotなど、何かがサーバーにページを要求するたびに、サーバーはログファイルへ1行を書き込みます。各行には時刻、訪問者のIPアドレス、要求した内容、「user-agent」（訪問者が自分を識別するためのラベル。たとえばGPTBot）、そしてサーバーが返したレスポンスコード（成功の200、未検出の404など）が記録されます。

AIクローラーログ分析とは、その行を読み、AIボットだけに絞り込むことです。他の方法では文字どおり答えられない質問に答えられます。

• AIボットは実際にサイトを訪れたのか？
• どのページを取得し、重要なページのどれを無視したのか？
• 本物のボットか、それともボットを装った何かか？
• 何を取得したのか。本物のコンテンツか、エラーページか？

AIボットの全体像と、それぞれの用途（トレーニングボット、検索ボット、「今このページを取得する」ボット）を知りたいなら、それは別のテーマです。AI crawlersを参照してください。このページは方法、つまりログを取り出して読む方法を扱います。

ダッシュボードでは分からない理由

• Google Search Consoleにはクロールの統計情報レポートがありますが、対象はGooglebotだけです。GPTBot、ClaudeBot、PerplexityBotについては何も表示されません。
• **Google Analytics（GA4）**が記録するのは、リンクをクリックしてサイトに到達し、「referrer」を伴う訪問者だけです。バックグラウンドでページを取得するクローラーは、そこにまったく現れません。

つまりログがグラウンドトゥルースです。ボットを見ているものは他にありません。

初心者が見落とす1つのこと

ログにあるGPTBotというラベルは、本当にOpenAIだったことを証明しません。 リクエストには誰でも好きなユーザーエージェント文字列を付けられます。封筒に差出人住所を書くようなものです。多くのスクレーパーは、正当に見せるため有名なボット名をトラフィックに付けます。確実にする唯一の方法は、訪問者のIPアドレスをAI企業が公開する実際のアドレス一覧と照合することです。この検証が正しく行うための中心であり、Advancedタブで詳しく説明します。

TL;DR — Apache／NginxまたはCDNのアクセスログを取得し、4つを行います。検証（ユーザーエージェントを照合し、各運営者の公開リストでIPも確認。なりすまし率はHUMAN Securityの5,7%から、Duane Forresterが自分で検証した81,8%まであります）、規模でツールを選択（grep → Screaming Frog Log File Analyser → ELK/Splunk → BigQuery/Cloudflare）、ボット別のクロール頻度、アクセスされたページ、クロールとレンダリングの差、ステータスコードを測定します。そして正直に解釈します。取得は必要条件ですが十分条件ではないため、「クロールが多いほど引用が増える」という説は証明されていません。これはAI crawlers（ボットが何者かを扱う）、AI traffic attribution（クリック側）、LLM visibility（取得 → 言及 → 引用の枠組みで、ここでは最初の段階を観測する）の姉妹手法です。

この記事が扱うこと、扱わないこと

ログが示すのはリクエストであり、コンテンツがトレーニング、取得、回答のどれに使われたかではありません。 Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files 利用できる場合はプロバイダーが公開する仕組みでボットを検証し、帰属は限定された証拠として扱います。 Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

姉妹記事のAI crawlersは、ボットごとの表、3分類（トレーニング／AI検索／ユーザーが開始した取得）、Google-Extendedはボットではなくトークンだという区別、robots.txtのレシピをすでに扱っています。ここで再導出はしません。AI traffic attributionはGA4／referrer側、つまりボットが返したものを扱います。この記事はファネルの反対側、ボットが取得したものです。そしてLLM visibilityは取得 → 言及 → 引用の枠組みを扱います。ログ分析で観測できるのは取得段階だけで、その先ではありません。

これは従来のSEOログファイル分析に続く、AI時代版です。AhrefsのHow to Do an SEO Log File Analysis を確認したとき、軸はクロール頻度、クロールされたURL、ステータスコード、Googleの公開IPに対するボット検証でした。ここも骨格は同じですが、主な対象はJavaScriptをほとんどレンダリングせず、頻繁になりすまされ、一定の流れではなく不規則なバーストでクロールするボット集団です。

ステップ1 — ログを取得する

ログは次の2か所のどちらか、または両方にあります。

• originサーバーログ。 Apache（access.log）、Nginx（access.log）、またはアプリサーバーです。最低限、タイムスタンプ、クライアントIP、リクエストメソッドとパス、ステータスコード、バイト数、referrer、ユーザーエージェントが各行にあります。
• CDN／エッジログ。 Cloudflare、Fastly、Akamaiなどの背後にいる場合、ボットトラフィックの多くはエッジで応答され、originに到達しない可能性があります。そのためエッジログの方が完全な記録です。CloudflareではLogpush（およびGraphQL API）、Fastlyではリアルタイムログストリーミングで取得できます。

AIボット分析で実際に必要なフィールドは、タイムスタンプ、クライアントIP、ユーザーエージェント、リクエストパス、ステータスコード、そして可能ならバイト数とreferrerです。

実務上の問題は保持期間です。多くのホストは数日分のログしか保持しません。Lauren BusbyのSearch Engine Land記事は解決策を直接示しています。定期的な取得によって短い期間を長期分析できるようにします。SFTPジョブをスケジュールし、n8nのようなワークフローツールで構築するか、スクリプト化すれば、短い保持期間を時間をかけて分析できるデータに変えられます（Busby, SEL）。データが必要になる前に設定してください。

最初から覚えておくべき正直な限界があります。Busbyの言葉どおり、ログファイルが示すのはサイトに到達したものですが、試みたものを常に示すわけではありません（SEL）。ブロックされたリクエストや上流で応答されたリクエストは、まったく現れない可能性があります。

ステップ2 — ユーザーエージェントを信頼する前に検証する

これはAIボットのログ分析と従来版を分けるステップで、多くの競合ハウツーが省略するステップです。ユーザーエージェント文字列は簡単になりすませます。 どれほど悪いかを示す独立したデータが2つあります。

• HUMAN Securityは、16の有名AIクローラーのいずれかを名乗る2週間のトラフィックを分析し、5,7%がなりすましだと発見しました。およそ18件に1件です（SEJによる報道）。
• Duane Forresterは自分のログで同じ確認を行い、さらに悪い結果を得ました。ライブ取得名を持つ33件のリクエストのうち、ベンダーが公開するIPから来たのは6件で、27件は違いました。確認できたリクエストのなりすまし率は81,8%です（SEJ）。Googlebotの数字はさらに悪く、Googlebot名を持つ799件のうち、検証済みGoogleアドレスから来たのは107件だけでした。残りのおよそ87%はGoogleではありませんでした（SEJ）。

これらは異なるサンプルと方法から得た方向性として扱い、普遍的な1つの数字とは考えないでください。さらに重要なのは、あるプロバイダーの検証方法をすべてのボットへ一般化しないことです。アドレス範囲を公開する運営者もいれば、現在の公開範囲やDNS検証契約なしにユーザーエージェントトークンだけを文書化する運営者もいます（SEJ）。

検証方法：

1. ユーザーエージェント文字列を照合する。 GPTBotは Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.3; +https://openai.com/gptbot; OAI-SearchBotとChatGPT-Userにはそれぞれのトークンがあります (OpenAIのボット文書)。
2. 存在する場合はプロバイダーの現在の公式検証方法を使う。 OpenAIは openai.com/gptbot.json、 searchbot.json、 chatgpt-user.json を公開しています。Anthropicの現在の クローラー文書 は、公開リスト のアドレスならAnthropicのクローラーだと示しています。現在のプロバイダー固有の 方法を使い、普遍的なボット検証ルールへ一般化しないでください。
3. フォールバックを発明しない。 逆引きと正引きDNSは、プロバイダーがホスト名のパターンと検証手順を公開している場合にのみ有効です。 一般的なPTR照合で証明できるのはDNSの制御であり、主張されたボットの身元ではありません。Screaming FrogのLog File Analyserは、 利用可能な公開確認済みリストを適用できます。インポート時の検証機能は公開確認済みIPリストに照合し、本物のボットか確認します （Screaming Frog）。

検証結果は、正確なポリシーとインシデント対応に役立てます。クロールポリシーにはプロバイダーが文書化したrobotsトークンを優先し、ネットワーク制御は不正利用またはセキュリティの場合に限定して、robots準拠とは別に記録してください。

ステップ3 — ツールを選ぶ

作業の規模に合わせます。おおむね無料 → 有料、グラウンドトゥルース → 管理型の順です。

• grep／PowerShell — 1回限りの件数確認と、検証を考慮したフィルターをすばやく実行できます。AI crawlers記事に基本的なボット件数のスニペットがあります。こちらのScriptsタブでは、IP検証、ステータスコードの内訳、クロールとレンダリングの差の検出まで拡張しています。
• Screaming Frog Log File Analyser — GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot、Claude-User、PerplexityBot、Perplexity-User、CCBotのプリセットと「Verify Bots When Importing」切り替えを備えたデスクトップインポーターです。Response CodesタブはURLごとに2XX/3XX/4XX/5XXを分け、User Agentsタブはボットごとのリクエストとエラー率を示し、URLsタブはNum Events（取得数）で並べ替え、IPsタブでは疑わしい送信元を調べられます（チュートリアル）。
• ELK Stack（Elasticsearch／Logstash／Kibana）またはSplunk — 単一インポートのデスクトップツールが遅くなった場合や、定期的なエクスポートではなく継続監視を行いたい場合に、ダッシュボードとアラート付きで大規模かつ継続的に取り込みます。
• BigQuery — 長期保持と大規模なSQLクエリ向けです。Cloudflare Logpushや、CloudflareのhttpRequestsAdaptiveGroupsデータセットからのGraphQL取得をスケジュールして取り込むことが多く、フラットファイルを再インポートせずページ、日付、ステータスコード別にボット活動を検索できます。
• Cloudflare AI Crawl Control（Cloudflareの背後にあるサイト向け）— 独自のパイプラインを構築せず、クローラー活動とリクエストパターン、ボット検証、ディレクティブ遵守を管理するダッシュボードです（文書）。

ステップ4 — 測定するものと読み方

ボット別のクロール頻度。 ボット名ごとの1日／1週間のヒット数です。AIボットは一定の流れではなくバーストでクロールします。WISLRの48日間のCDNログ事例では、GPTBotは数週間現れなかった後、1週間に187件を取得し、そのうち152件が3分間のバーストで、ピークは毎分114件でした（WISLR）。頻度は合計ではなくパターンとして読みます。

アクセスされたページと、重要なのにアクセスされないページ。 リクエスト数で並べ替えます。Busbyによると、AIクローラーは浅い範囲に留まることが多く、トップページ、主要ナビゲーション、少数の上位URLに限られるのが一般的です（SEL）。引用に最も重要な深いページでも急激に減ります。ログに一度も現れない深いページは取得できません。

生HTMLへの依存 — 測定し、一般化しない。 プロバイダーの文書は、GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot、PerplexityBotなどに共通するJavaScriptレンダリング契約を示していません。観測された特徴は役立ちます。WISLRのサンプルではChatGPT-UserはHTMLだけを取得し、画像、CSS、JSファイルへのリクエストはゼロでした。一方GooglebotとOAI-SearchBotは画像も取得しました（WISLR）。ログでAIボットが、生HTMLがほぼ空のJSシェルであるページを大量取得しているなら、それは確認可能な依存リスクであり、すべてのプロバイダーが常にそう動く証拠ではありません。配信されたHTMLを結果またはプロバイダー固有の取得テストと比較してください（レンダリングの基本はJavaScript SEOを参照）。

ステータスコード／ブロックの内訳。 200（成功）、304（変更なし。効率的な再クロール）、404（ボットがたどった壊れたリンク）、403／429（ブロック／レート制限）を確認します。Busbyは、ログファイルがクローラーの問題箇所、403（ブロックされたリクエスト）と429（レート制限）を明らかにすると特に説明しています（SEL）。そのブロックが意図的か事故かを確認してください。

robots.txtとllms.txtのリクエストを独立したシグナルとして扱う。 クロール前にどのボットが/robots.txtを要求するかを照合します。WISLRのサンプルではGPTBotとMeta-WebIndexerは48日間一度も確認しませんでした。また、禁止されたパスがそれでも取得されているか確認します。WISLRでは48日間、AIボットから/llms.txtへのリクエストもゼロでした（WISLR）。AI crawlers記事で扱う約97%が未読という発見とも一致します。llms.txtのリクエストを「機能している」証拠として期待しないでください。

クロールが多いほど引用が増えるのか？正直に答える。

「クロールが多いほど引用が増える」という確立したデータはありません。取得は引用の必要条件ですが、十分条件にはほど遠いものです。クライアント側レンダリング、ペイウォール、薄いまたは重複コンテンツ、モデルの取得／ランキング段階でより良いソースに負けることなどにより、ページは常にクロールされても引用されません。重要な枠組みはLLM visibility記事の取得 → 言及 → 引用で、ログ分析が観測するのは最初の段階だけです。

正直にループを閉じるには、クロール入力側（自分のログ）と引用出力側を組み合わせます。BingのAI Performanceレポート（2026年2月のパブリックプレビュー）は、引用データをgrounding queriesとともに公開する初の公式ツールです。grounding queriesとは、AI生成回答で参照されたコンテンツを取得するときにAIが使った重要なフレーズです（Bing Webmaster Blog）。ログは何が取得されたかを示し、grounding queriesと引用数はその結果を示します。どちらだけでも全体像にはなりません。これらのレイヤーの積み重ねは測定とレポートのハブを参照してください。

ステルスクロールの注意点

検証は一度だけの監査ではありません。Seer InteractiveのClint Spauldingによると、ブロックされたステルスクローラーは一般的なブラウザヘッダーと無関係なIPで再出現することがあります。ログ上は人間に見えるため、セッション数が水増しされ、ボットトラフィックが過小計上され、GEOのセグメントが信頼しにくくなります（Seer）。同氏の率直な要約は、ステルスクローラーが見えなければ影響を測定できないということです。だからこそログ分析には、単一の実行ではなく定期的な再検証とベースラインの再設定が必要です。

AIによる要約

Advanced版を短くまとめます。

• AIクローラーログ分析 = AIボットのリクエストについて生のサーバー／CDNログを読むこと。 ファーストパーティデータで、どのボットがアクセスしたか、本物か、何を取得したかを検証します。GSC（Googlebotのみ）とGA4（referrerのみ）では見えません。
• 範囲： この記事は方法を扱います。ボットの正体はAI crawlers、クリック側はAI traffic attribution、取得 → 言及 → 引用の枠組みはLLM visibilityが扱います（ログが観測するのは取得だけです）。
• 検証済みの身元と主張されたユーザーエージェントを分ける。 ユーザーエージェントはなりすまされます。HUMAN Securityは16ボットで5,7%、Duane Forresterはライブ取得リクエストで81,8%の偽装（Googlebotでは87%）を測定しました。UAを照合し、存在する場合は運営者の現在の公式リスト（例：openai.com/gptbot.jsonまたはAnthropicのclaude.com/crawling/bots.json）で送信元IPも確認します。一般的な逆引きDNSのフォールバックを発明しないでください。
• 規模別のツール： grep → Screaming Frog LFA（AIプリセット＋インポート時検証）→ ELK/Splunk → BigQuery／Cloudflare AI Crawl Control。
• 測定： ボット別のクロール頻度（バースト型。例：WISLRのGPTBotは3分で152件）、アクセスされたページ、生HTMLへの依存（WISLRのChatGPT-Userサンプルは画像／CSS／JSをゼロ件取得）、ステータスコード（403/429）、robots.txt／llms.txtのリクエスト（WISLRは48日でllms.txtをゼロ件記録）です。
• クロール ≠ 引用。 取得は必要ですが十分ではありません。「クロールが多いほど引用が増える」は証明されていません。ログをBingのgrounding queriesと組み合わせてループを閉じます。
• 定期的に再検証する。 ブロックされたステルスクローラーは人間に見える形で再出現します。

公式ドキュメント

一次資料です。ボット運営者自身の検証ファイルとプラットフォーム文書を確認します。

OpenAI

• OpenAIのボット／クローラー文書 — GPTBot、OAI-SearchBot、ChatGPT-User、OAI-AdsBotのユーザーエージェント文字列と挙動。
• 検証用の公開IPリスト： gptbot.json、searchbot.json、chatgpt-user.json、adsbot.json。

Anthropic

• AnthropicはWebのデータをクロールするか — 現在のボット名、用途、robots制御、公開リストのアドレスがAnthropicクローラーを示すという説明。
• AnthropicクローラーIPリスト — ClaudeBot、Claude-SearchBot、Claude-Userの現在の共有検証ソース。

Google

• クロールの統計情報レポート — Google独自のクロール活動ビュー（Googlebotのみ。第三者AIボットは対象外なので、生ログが必要です）。

Cloudflare

• AI Crawl Control — AIクローラー活動、ボット検証、ディレクティブ遵守を管理するダッシュボード。

Bing／Microsoft

• Bing Webmaster ToolsでAI Performanceを導入（パブリックプレビュー） — ログ分析に対応する引用結果のビュー。Total Citations、Average Cited Pages、Grounding Queries、ページ単位の引用活動を表示します。

ソースからの引用

運営者と名前の明らかな実務者による、記録に残る発言です。

Anthropic — 現在の範囲

• Anthropicの現在のサポートページはClaudeBot、Claude-SearchBot、Claude-Userを区別し、robots制御の適用方法を説明しています。また、公開リスト のアドレスはAnthropicクローラーを示すとしています。 ソース

Lauren Busby、Trebletree共同創業者 — Search Engine Land

• “Log files are the closest thing to that missing layer. They don’t summarize or interpret activity. They record it — every request, every URL, every crawler.” (翻訳)「ログファイルは、その欠けているレイヤーに最も近いものです。活動を要約したり解釈したりしません。すべてのリクエスト、すべてのURL、すべてのクローラーを記録します。」
• “Tools like Screaming Frog Log File Analyzer make it possible to process that data quickly.” (翻訳)「Screaming Frog Log File Analyzerのようなツールを使えば、そのデータをすばやく処理できます。」
• AIクローラーの深さについて：“It’s common to see them limited to top-level pages – the homepage, primary navigation, and a small number of high-level URLs.” (翻訳)「トップレベルのページ、つまりホームページ、主要ナビゲーション、少数の上位URLに限られるのは一般的です。」
• 何が明らかになるかについて：“Log files also surface where crawlers encounter issues. This includes: 403 responses (blocked requests). 429 responses (rate limiting).” (翻訳)「ログファイルはクローラーが問題に遭遇する場所も明らかにします。403レスポンス（ブロックされたリクエスト）や429レスポンス（レート制限）が含まれます。」
• 保持について：“A scheduled SFTP job – whether built in a workflow tool like n8n, or scripted – is enough to turn a short retention window into something you can actually analyze over time.” (翻訳)「n8nのようなワークフローツールで構築するかスクリプト化するかにかかわらず、スケジュールしたSFTPジョブがあれば、短い保持期間を時間をかけて実際に分析できるものへ変えられます。」
• 正直な限界：“Log files show you what reached your site. They don’t always show you what tried to.” (翻訳)「ログファイルが示すのはサイトに到達したものです。試みたものを常に示すわけではありません。」 ソース

Duane Forrester — Search Engine Journal

• “Of 33 requests carrying one of those live-fetch names. Six came from an IP the vendor publishes. Twenty-seven did not. That is an 81.8% spoof rate among the requests I could check.” (翻訳)「ライブ取得名のいずれかを持つ33件のリクエストのうち、ベンダーが公開するIPから来たのは6件でした。27件は違いました。確認できたリクエストのなりすまし率は81.8%です。」
• “The real check is not complicated. The major operators publish the actual IP addresses their bots use, as plain files you can open right now, and a request is legitimate only if the name matches and the address sits inside the published list.” (翻訳)「本当の確認は複雑ではありません。主要な運営者は、ボットが使う実際のIPアドレスを、今すぐ開けるプレーンファイルで公開しています。リクエストが正当なのは、名前が一致し、アドレスが公開リスト内にある場合だけです。」
• Googlebotについて規模を示すと：“Of 799 requests carrying the Googlebot name, only 107 came from a verified Google address. The other 692, roughly 87%, were not Google.” (翻訳)「Googlebot名を持つ799件のリクエストのうち、検証済みGoogleアドレスから来たのは107件だけでした。残り692件、およそ87%はGoogleではありませんでした。」
• 行動の呼びかけ：“Do not take my numbers; take the method… Pull a date range, match the names, verify the IPs against the published lists, and find your real fraction.” (翻訳)「私の数字をそのまま受け取らず、方法を使ってください。期間を取り、名前を照合し、公開リストでIPを検証して、自分の実際の割合を見つけてください。」 ソース

Clint Spaulding、シニアマネージャー（Technical SEO）、Seer Interactive

• “Once blocked, stealth crawlers can reappear under generic browser headers and unrelated IPs.” (翻訳)「一度ブロックされると、ステルスクローラーは一般的なブラウザヘッダーと無関係なIPで再出現する可能性があります。」
• “These sessions look human in logs. That means session counts get inflated, bot traffic gets undercounted, and GEO segmentation becomes less trustworthy.” (翻訳)「これらのセッションはログ上で人間に見えます。そのためセッション数が水増しされ、ボットトラフィックが過小計上され、GEOセグメントの信頼性が下がります。」
• “If you can’t see these stealth crawlers, you can’t measure their impact.” (翻訳)「これらのステルスクローラーが見えなければ、影響を測定できません。」 ソース

Screaming Frog — Log File Analyserチュートリアル（製品文書）

• インポート時検証について：“Search engine bots are often spoofed, and this performs a lookup against publicly confirmed IP lists to confirm they are genuine.” (翻訳)「検索エンジンのボットはしばしばなりすまされます。この機能は公開確認済みIPリストに照合し、本物か確認します。」
• “If you see high request volumes from IPs that don’t verify, you’re likely dealing with fake bot traffic that should be blocked at server level.” (翻訳)「検証できないIPから大量のリクエストが見られるなら、サーバーレベルでブロックすべき偽ボットトラフィックを扱っている可能性が高いです。」 ソース

Bing Webmaster Tools — AI Performanceレポート（2026年2月のパブリックプレビュー）

• Grounding Queries：“Shows the key phrases the AI used when retrieving content that was referenced in AI-generated answers.” (翻訳)「AI生成回答で参照されたコンテンツを取得するときにAIが使った重要なフレーズを示します。」
• Total Citations：“Shows the total number of citations that are displayed as sources in AI-generated answers during the selected time frame.” (翻訳)「選択した期間中にAI生成回答のソースとして表示された引用の総数を示します。」 ソース

「これは本物のAIボットリクエストか。どう対処するか？」

疑わしいログの1行、またはボット全体のトラフィックをこの手順で確認します。ステップ2の検証ロジックをフローにしたものです。

AIクローラーログ分析チェックリスト

ログの取得から読み取りまで、繰り返し使える確認です。

• タイムスタンプ、クライアントIP、ユーザーエージェント、リクエストパス、ステータスコード（バイト数とreferrerも有用）を含む必要なフィールドを記録している。
• 正しいレイヤーから取得している。Cloudflare／Fastlyの背後ならCDN／エッジログを使う（ボットトラフィックの多くはoriginに到達しない）。
• SFTP／n8n／スクリプトによる定期取得が保持期間を超え、直近数日だけでなく履歴を持てる。
• すべてのAIボットリクエストを検証済みにしている。ユーザーエージェントが一致し、かつ送信元IPを運営者の公開リスト（予備として逆引きDNS）で確認している。
• なりすまし／未検証リクエストをAIクロール指標から除外し、名前どおりのボットとして数えていない。
• ボットごとのクロール頻度をベースライン化している（バースト型と定常型のパターンに注意）。
• 最も取得されたページを特定し、重要な深いページも実際にクロールされているか確認している。
• クロールとレンダリングの差を確認している。JSでレンダリングされるページをAIボットがHTMLだけ取得していないか（生HTML依存テストとして記録。プロバイダーごとの挙動で、文書化されていない可能性がある）。
• ステータスコードを確認している。200／304は健全、404は壊れたリンク、403／429は意図どおりか修正済み。
• robots.txtリクエストの有無を確認している（クロール前にボットが取得するか）。禁止パスへの予想外のアクセスがない。
• 「機能しているか」という結論を出す前に、引用側のデータ（Bingのgrounding queries／GSCのAI機能）と組み合わせている。
• 再検証をスケジュールしている。これは一度だけの監査ではない（ステルスクローラーは人間に見える形で再出現する）。

AIクローラーログ分析チートシート

検証ファイル（ブックマークしておく）

確認するステータスコード

信頼せず、検証する

• ユーザーエージェントだけなら未検証です。UAを照合し、利用できる場合はプロバイダー公開の検証データを使い、それ以外では不確実性を残します。
• 実際に見られたなりすまし率：5,7%（HUMAN、16ボット）→ 81,8%（Forresterのライブ取得ログ）。同じ監査でGooglebotの**87%**が偽装でした。

生HTML依存の手がかり

• .js／.css／画像のリクエストがゼロで、ボットがHTMLだけを取得するのは、観測された取得パターンです。JS依存ページではリスクシグナルであり、普遍的な能力の証明ではありません。

すぐ使える事実

• クロール頻度 ≠ 引用される可能性。取得は必要ですが十分ではありません。
• クロールポリシーには文書化されたrobotsトークンを使い、ネットワークブロックは別の不正利用／セキュリティ制御として扱います。

AIクローラーログ分析のスクリプト

AI crawlers記事には、基本的な「ボットのヒット数を数える」スニペットがあります。ここではさらに、抽出、検証、ステータスコードの内訳、クロールとレンダリングの差の検出まで行います。

1. AIボットの行をすべて抽出する（grep＋正規表現）

macOS／Linux — よく使われるAIユーザーエージェントを1つの選択肢で検索します。

# Pull all AI-bot requests from a combined-format access log
grep -Ei 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Applebot|Amazonbot|Bytespider|CCBot|Meta-ExternalAgent' \
  access.log > ai-bots.log

# Count requests per bot (which token, how many hits)
grep -Eoi 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Perplexity-User|CCBot|Bytespider' \
  access.log | sort | uniq -c | sort -rn

Windows PowerShell：

Select-String -Path .\access.log -Pattern 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider' |
  ForEach-Object { ($_ -match '(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider)') | Out-Null; $Matches[1] } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

2. 主張されたGPTBotのIPをOpenAIの公開リストで検証する

ユーザーエージェントだけでは何も証明できません。IPを確認してください。次のコマンドはOpenAIのリストを取得し、ログのIPが公開されたCIDRのいずれかに含まれるかをテストします。

# Requires jq and (for CIDR math) grepcidr — brew/apt install both
IP="203.0.113.45"   # the IP from your log line
curl -s https://openai.com/gptbot.json \
  | jq -r '.prefixes[].ipv4Prefix // .prefixes[].ipv6Prefix' \
  | while read -r cidr; do
      echo "$IP" | grepcidr "$cidr" >/dev/null 2>&1 && echo "VERIFIED in $cidr"
    done
# No output = the IP is NOT in OpenAI's published range → treat as spoofed.

Anthropicの場合は、現在のhttps://claude.com/crawling/bots.json リストを取得し、文書化された形式に合わせてjqのパスを調整します。別の運営者が現在の検証フィードを公開していない場合、結果は主張されたユーザーエージェントとして残してください。

3. 逆引き＋正引きDNSのフォールバック（リスト外IP）

これは、名前の付いたプロバイダーが期待されるホスト名のサフィックスと、逆引きと正引きによる検証手順を公開している場合だけ使います。ボットの身元を一般的に証明する方法ではありません。

IP="203.0.113.45"
HOST=$(host "$IP" | awk '/pointer/ {print $NF}' | sed 's/\.$//')
echo "PTR: $HOST"
host "$HOST" | grep -q "$IP" && echo "FORWARD-CONFIRMED" || echo "MISMATCH → suspect"

4. ボット別のステータスコード内訳

403／429のブロックを見つけます。

# For GPTBot: tally status codes (combined log format; $9 is the status)
grep -i 'GPTBot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# → e.g. "812 200 / 47 404 / 15 403" — the 403s are worth investigating

5. 生HTML依存シグナル — ボットが取得しているファイル種別は？

主張されたボットが.html／/だけを取得し、.js／.css／画像を一度も取得せず、コンテンツがJSでレンダリングされるなら、確認すべき依存シグナルです。

# What extensions is ChatGPT-User actually requesting?
grep -i 'ChatGPT-User' access.log \
  | awk '{print $7}' \
  | grep -oE '\.(html?|js|css|png|jpe?g|webp|svg|woff2?)(\?|$)' \
  | sort | uniq -c | sort -rn
# All HTML, zero subresources = compare the raw body with provider-specific outcomes.

6. Chrome DevTools Console — 実際のページでAIフェッチャーを見つける

ログクエリではありませんが、ページが生HTMLとJS実行後に何を配信するか（AIボットが見るもの、見ないもの）をすばやく確認できます。Consoleに貼り付けます。

// Compare rendered text length to what's in the initial HTML source.
// A big gap means most content depends on JS; provider behavior must be verified separately.
(async () => {
  const raw = await (await fetch(location.href, { cache: "no-store" })).text();
  const rawText = new DOMParser().parseFromString(raw, "text/html").body.innerText.trim().length;
  const renderedText = document.body.innerText.trim().length;
  console.log({ rawText, renderedText, jsDependentRatio: +(1 - rawText / renderedText).toFixed(2) });
})();
// jsDependentRatio near 1 = almost all content is JS-injected; flag dependency, not invisibility.

7. ブックマークレット — すべてのボットのIPリストを一度に開く

すばやく確認できるよう、これをブックマークとして登録すると検証ファイルをタブで開けます。

javascript:(function(){["https://openai.com/gptbot.json","https://openai.com/searchbot.json","https://openai.com/chatgpt-user.json","https://claude.com/crawling/bots.json"].forEach(u=>window.open(u,"_blank"));})();

SOP：AIクローラーログの月次レビュー

定期的に実行する手順です（多くのサイトでは月次、AIトラフィックが重要なら週次）。毎回比較可能なベースラインを作ります。

準備

1. 前回のレビュー以降のログ期間を正しいレイヤーから取得します。CDNの背後ならCDN／エッジログ、それ以外ならoriginログです。スケジュールしたSFTP／n8n取得が実際に実行されたか確認します。ここに欠落があると傾向線がひそかに壊れます。
2. 記録のためのツールに読み込みます。定期インポートならScreaming Frog LFA、パイプラインならBigQuery／ELKを使います。

検証（絶対に省略しない） 3. 各プロバイダーが現在公開している検証ソース（gptbot.json、searchbot.json、chatgpt-user.json、adsbot.json、Anthropicのclaude.com/crawling/bots.json）を更新します。これらは変わります。 4. Screaming Frogのインポート時検証を有効にするか、ScriptsタブのIP-in-CIDRチェックをすべてのAIボットリクエストに実行します。 5. トラフィックを検証済みと未検証に分けます。未検証の割合を報告します。これはその期間のなりすまし率です。増加自体が発見事項です。

測定（検証済みトラフィックのみ） 6. 前期間と比較したボット別クロール頻度。新しいボット、消えたボット、バーストを記録します。 7. 最も取得されたページ。重要なページや深いページが実際にクロールされているか確認します。 8. JSが重いテンプレートを2〜3個、生HTML依存についてスポットチェックします（ボットがHTMLだけを取得していないか）。 9. ボット別のステータスコード内訳。新しい403／429／404の集まりを調べます。 10. robots.txt／llms.txtリクエストの有無と、禁止パスへのアクセスを確認します。

報告して対応する 11. 期間の数字（ボット別の検証済みヒット、なりすまし率、上位ページ、エラーの集まり）を継続シートに記録し、スナップショットではなく傾向を持てるようにします。 12. 可視性について結論を出す前に、引用側のデータ（Bingのgrounding queries／GSCのAI機能）と組み合わせます。 13. 具体的な修正を登録します。意図したブロックと事故によるブロック、JSレンダリングの欠落、壊れたリンク、確認済みのなりすましに対する正確なユーザーエージェントルールです。

頻度に関する注意： 毎回検証をやり直してください。「問題ないと分かっている」IPリストをキャッシュしないでください。ステルスクローラーは新しいIPと一般的なブラウザUAで再出現します。

プレイブック：「GPTBot（またはClaudeBot）が403／429を返している。意図したものか分からない」

ログ上で検証済みAIボットがエラーに遭う、よくあるインシデントの手順です。順番どおりに進めます。

ステップ1 — まず本物のボットか確認する。 最初に、名前の付いたプロバイダーの現在の公式検証方法を使います。方法がなければ身元は未検証のままです。黙って本物としたり、なりすましとしたりしないでください。403はWAFが正常に働いた結果かもしれません。

ステップ2 — 正確なレスポンスと発生場所を特定する。 そのボットのステータスコード内訳（Scriptsタブ）を取得します。403（ブロック）、429（レート制限）、503のどれですか。ブロックがCDN／WAF、サーバー設定、robots.txtに隣接するルールのどこで起きているか記録します。

ステップ3 — ブロックが意図的か決める。

• このボットをブロックするつもりだった（例：オプトアウトしたトレーニングクローラー）→403は設計どおりに機能しています。文書化したrobotsポリシーとネットワークレベルの不正利用／セキュリティルールは分けます。完了です。
• ブロックするつもりはなかった（例：AI検索の可視性を得たいOAI-SearchBot／PerplexityBot）→続けます。

ステップ4 — 事故によるルールを探す。 よくある原因は、広すぎるWAFの「bot」ルール、バーストするクローラーには低すぎるレート制限のしきい値（WISLRのGPTBotは毎分114件の急増があり、毎分上限に達しても正当なバーストかもしれません）、忘れていた robots.txt のdisallow、運営者の範囲に当たる地域／ASNブロックです。

ステップ5 — 正確に修正する。 検証済みボットをユーザーエージェント＋公開IP範囲で許可するか、その検証済みボットだけレート制限の上限を引き上げます。全員の保護を緩めないでください。

ステップ6 — ログで修正を検証する。 デプロイ後、そのボットのログを再取得します。気にしているページで403／429の集まりが200／304に変わることを確認します。

ステップ7 — 再ベースライン化して監視する。 継続シートに変更を記録します。次の期間に再確認し、ブロックする意図があった場合は、ボットが別UAで再出現するステルスクロールにも注意します。

間違った結論を生むログ分析のミス

それぞれ、世間で見られる思い込み、なぜ間違っているか、代わりに何をするかを説明します。

神話：「robots.txtでボットをブロックすれば、ログに現れない／問題ではない。」 なぜ間違いか： robots.txtはリクエストであり、強制装置ではありません。ユーザーが開始するフェッチャーは明示的に対象外とし、一部のクローラーはブロックを回避すると報告されています（Perplexityのステルスクロール、Cloudflare 2025年8月）。ブロックが完全に無視される可能性があります。 代わりに： ログを使い、ルールが守られているか確認します。禁止パスへのアクセスと、ボットがそもそも/robots.txtを要求しているかを見ます。

神話：「ログのGPTBot／ClaudeBotユーザーエージェントは、本当にOpenAI／Anthropicだという意味だ。」 なぜ間違いか： ユーザーエージェントは簡単になりすませます。HUMAN Securityは16ボットで5,7%の偽装を測定し、Duane Forresterは自分のライブ取得リクエストで81,8%の偽装を見つけました。 代わりに： ユーザーエージェントを照合し、存在する場合は運営者の現在の公式検証方法を使います。それ以外では身元を未検証と表示します。

神話：「AIクローラーのヒットが多いほど、引用されやすい。」 なぜ間違いか： 確立した因果または相関データはありません。取得は必要ですが十分ではなく、頻繁にクロールされるページも常に引用されるわけではありません。 代わりに： ログは取得段階だけを可視化すると考え、引用側のデータ（Bingのgrounding queries、GSCのAI機能）と組み合わせます。

神話：「すべてのAIクローラーは同じレンダリング挙動をする。」 なぜ間違いか： プロバイダーは共通のJavaScript／サブリソース契約を公開しておらず、観測された挙動はエージェントとサンプルで異なります。 代わりに： 生レスポンスとレンダリング済みページを比較し、名前付きボットごとのサブリソースリクエストを確認し、結果を普遍的ではなく観測結果として表示します。

神話：「AIボットは少なくともllms.txtを確認している。」 なぜ間違いか： WISLRの48日間のサンプルでは、AIボットから/llms.txtへのリクエストはゼロでした。AI crawlers記事の約97%が未読という発見とも一致します。 代わりに： llms.txtのリクエストを期待される検証とは扱わず、ボットが実際に取得したものを測定します。

神話：「ネットワークブロックとrobotsポリシーは同じ制御だ。」 なぜ間違いか： robotsはクロールの希望を伝え、ファイアウォールはネットワークアクセスを強制するため、無関係なトラフィックにも影響します。 代わりに： ポリシーには文書化したユーザーエージェントルールを使い、ネットワークブロックは別途正当化された不正利用／セキュリティ対応に限定します。

実例

Duane Forrester — 自分のログで検証したなりすまし率。 Forresterはこの方法を自分のサイトで実行し、数字を公開しました。ライブ取得リクエスト33件のうち、ベンダー公開IPから来たのは6件だけで、なりすまし率は81,8%でした。Googlebot名を持つ799件では、検証できたのは107件だけで、およそ87%が偽装でした（SEJ）。前： ユーザーエージェントを信頼し、「AIアシスタント」トラフィックは本物に見えました。後： 名前を公開IPリストと照合すると、その大半がなりすましでした。要点： 重要なのは彼の具体的な数字より方法です。彼の言うとおり、自分の期間を取り、実際の割合を調べてください。

WISLR — 48日間のCDNログに見るクロールとレンダリングの特徴。 Tony Castilloは48日間にわたる288 566行のCDNログ（AI／ボットリクエスト12 099件）を分析しました（WISLR）。具体的には、GPTBotは数週間不在の後、3分間に152件（ピーク毎分114件）のバーストを起こしました。ChatGPT-Userは画像、CSS、JSをゼロ件取得し、純粋なHTML抽出でした。期間全体で/llms.txtへのリクエストもゼロでした。前： 定常的なクロールとJS対応ボットを想定するでしょう。後： ログはバースト型でHTMLのみの挙動を示しました。n=1、1サイトのデータですが、実際の分析で何が見えるかを鮮明に示します。要点： ゼロJS取得パターンがクロールとレンダリングの差を確認する直接的な証拠です。

Cloudflare — ネットワーク規模で見るクロールとreferralの比率。 Cloudflareの集計データは、クロールがどれほどわずかしかトラフィックに変わらないかを示します。Anthropicがサイトへ送り返す訪問者1人あたり、クローラーはすでに数万ページを訪問しています（Cloudflare）。前： 激しいクロールはエンゲージメントを意味するという直感。後： ネットワーク規模では比率は偏っており、現在はトレーニングがAIボット活動の大半を占めます。トレーニングボットはそもそもトラフィックを送り返すためのものではありません（Cloudflare）。要点： referralがゼロでも頻繁にクロールされるページは普通で、成功の証拠ではありません。だからこそクロール頻度は引用の予測因子ではありません。

すぐ使えるAIプロンプト

AIクローラーログ分析をLLMで高速化するための、コピーして使えるプロンプトです。LLMは幻覚を起こすため、生ログに対して必ず出力を常識確認してください。幻覚したIP照合を信頼する検証パイプラインは、検証しないものより悪い結果になります。

検証を考慮したログパーサーを作成する

Write a Python script that parses combined-format Nginx access logs and, for each
request whose user-agent matches a known AI bot (GPTBot, OAI-SearchBot,
ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot,
Bytespider), does the following:

1. Extract timestamp, client IP, request path, status code, user-agent.
2. Fetch and cache OpenAI's current IP lists (gptbot.json, searchbot.json,
   chatgpt-user.json, adsbot.json) and Anthropic's current bots.json list.
3. Mark an OpenAI or Anthropic request VERIFIED only if the user-agent matches AND
   the client IP falls inside the matching provider-published ranges; mark providers
   without an official method UNVERIFIED, not spoofed.
4. Output two CSVs: verified requests and unverified ("spoofed") requests.
5. Print a summary: verified vs. unverified count per bot, and the top 20 fetched
   paths (verified only).

Do NOT count unverified requests in any per-bot metric. Add clear comments.

ステータスコード＋クロールとレンダリングのレポートを要約する

I'll paste a table of AI-bot log data (columns: bot, path, status_code,
file_extension). Produce:
- A per-bot status-code breakdown, flagging any 403/429/404 clusters.
- A raw-HTML dependency read: for each bot, the ratio of HTML requests to
  JS/CSS/image requests, and a note on whether the bot appears to fetch only HTML
  in this sample. Treat HTML-only on a JS-rendered page as a dependency risk, not
  proof of a universal no-JavaScript capability.
Keep every conclusion tied to a number from the data — do not infer beyond it.

DATA:
[paste]

疑わしいIPをトリアージする

A request in my logs claims to be [BOT NAME] from IP [IP ADDRESS]. Walk me through
verifying it: which operator IP-list file to check, how to test whether the IP is
in range, and the reverse+forward DNS fallback if it's not on a published list.
Tell me explicitly what result means "verified" vs. "treat as spoofed." Do not
guess whether this specific IP is legitimate — give me the steps to check.

AIクローラーログ分析のツール

おおむね無料／グラウンドトゥルース → 有料／管理型の順です。

• grep／PowerShell — 生のアクセスログからボットヒット数と、検証を考慮したフィルターへ最速で到達できます。設定不要です。Scriptsタブを参照してください。
• Screaming Frog Log File Analyser — AIボットのプリセットと、公開確認済みIPリストで検証する「Verify Bots When Importing」切り替えを備えたデスクトップインポーターです。Response Codes、User Agents、URLs（Num Eventsで並べ替え）、IPsタブがあります。定期インポートに最適です。
• ELK Stack（Elasticsearch／Logstash／Kibana）またはSplunk — デスクトップインポートが遅くなった場合や継続監視が必要な場合の、継続取り込み、ダッシュボード、アラートです。
• BigQuery — 長期保持と大規模SQL向けで、通常はCloudflare LogpushまたはhttpRequestsAdaptiveGroupsからのスケジュール済みGraphQL取得で供給します。
• Cloudflare AI Crawl Control — Cloudflareの背後にあるサイト向けです。独自パイプラインなしで、管理型のクローラー活動、ボット検証、ディレクティブ遵守ビューを提供します。
• Google Search Console — クロールの統計情報 — AIボット向けではありません（Googlebotのみ）が、生ログからAIボット向けに再構築する、クローラー別＋レスポンス別コード内訳のモデルになります。
• Bing Webmaster Tools — AI Performance — 引用結果側です。grounding queriesと引用数をクロール入力ログと組み合わせてループを閉じます。

AIボットを名乗るトラフィックが一晩で急増した

症状： 有名なクローラーのユーザーエージェントを持つリクエストが突然増える。考えられる原因： なりすまし、監視トラフィック、実際のクロール変化。対処： トラフィックを帰属させる前に、運営者の現在の公開方法で送信元IPを検証し、ASN、パス、ステータス、時刻で分けます。

ログではクロールされているのにコンテンツが引用されない

症状： 検証済みボットがページを取得しているのに、目に見える引用の増加がない。考えられる原因： クロールは適格性の証拠にすぎず、取得と回答選択は別です。対処： ボットが実質的なHTMLを受け取ったことを確認し、インデックス登録可能性、パッセージ品質、クエリ適合性、外部の裏付けを評価します。クロール数を順位とみなさないでください。

すべてのリクエストが200を返しているように見える

症状： 欠落URLとブロックされたコンテンツが成功として記録される。考えられる原因： アプリシェル、CDNルール、カスタムエラーページがソフト404を返している。対処： レスポンス本文と最終ヘッダーをサンプリングし、ステータスだけを信頼せず処理を修正します。

検証済みボットに空のシェルが返る

症状： ブラウザではコンテンツがレンダリングされるのに、ログに一致した取得では有用なHTMLがほとんど返らない。考えられる原因： ページが、クローラーが実行しないクライアント側JavaScriptに依存している。対処： 生出力とレンダリング済み出力を比較し、SSR、静的レンダリング、その他の信頼できる配信戦略で重要なコンテンツとリンクをHTMLとして提供します。

AIクローラーログの指標

時間を使う価値のあるリソース

私の関連著作

• SEOログファイル分析の方法 （Ahrefs、Patrick StoxとMichal Pecánekのレビュー）— この記事がAI特化版として続く、AI以前のテンプレート。測定項目、ツール、ボット検証を扱います。
• ログファイル分析とは？ （Ahrefs用語集）— 定義の補足資料。
• 新しいWebクローラーに出会う：AIボットが検索エンジンボットに迫る — AIボットのクロールシェアに関するCloudflare Radar分析。
• 約1億4,000万サイトが最も多くブロックするAIボット — オープンWeb全体のrobots.txtブロック率データ。
• AI検索トラフィックの80%はホームページ、製品ページ、無料ツールへ向かう — AI活動をページ種別で分析した記事。「どのページがクロールされるか」に対応します。

私の講演

• How Search Works （SlideShare）— クロール、レンダリング、インデックス登録、ランキングの解説で、ログ上のボットの行動を読む背景になります。（恒例の免責事項が適用されます。システムについての私の理解であり、100%完全または正確だという保証ではありません。）

業界の資料

• AIクローラーと検索可視性にログファイル分析が重要な理由 — Lauren Busby（Trebletree）、Search Engine Land。「ログは欠けているレイヤー」という説明、保持期間、403／429の整理。
• 私の「AIアシスタント」トラフィックの81.8%は偽物だった。Googlebotの数字はさらに悪かった — Duane Forrester、Search Engine Journalによる、目立った一次検証事例と方法。
• PerplexityのステルスAIクロールとGEO・ログファイル分析への影響 — Clint Spaulding、Seer Interactive。ブロックされたボットが人間に見える形で再出現する理由。
• Log File AnalyserでAIボットを監視する方法 — Screaming Frog。インポート時検証を含む実務ツール解説。
• クロールからクリックまでの差：AIボット、トレーニング、参照元に関するCloudflareデータ — Cloudflare。ネットワークレベルのクロールと参照元の比率、トレーニングと検索の分離。
• AnthropicはWebのデータをクロールするか — Anthropicの現在のボット用途とrobots制御の文書。
• OpenAIのボット／クローラー文書 — 検証用のユーザーエージェント文字列と公開IPファイル。

引用する価値のある統計

• なりすまし率 — 16 AIクローラーで5,7%。 HUMAN Securityが16の有名AIクローラーのいずれかを名乗るトラフィックを2週間分析し、およそ18件に1件がなりすましだと発見しました（ベンダー提供の数字。 SEJ 経由）。
• なりすまし率 — 実務者1人のログで81,8%。 Duane Forresterの自分で行った監査では、ライブ取得リクエスト33件のうち27件がベンダーの公開しないIPから来ていました。Googlebotの数字は約87%が偽装でした（SEJ）。
• クロールとreferral — ClaudeBot対OpenAI。 Cloudflareのデータ（2026年5月25日〜6月1日の週）では、1件のreferralあたりのクロールページ数はClaudeBotが約11 1122、OpenAIが約857で、Googlebotは約5でした（Cloudflare）。
• AIボット活動の大半はトレーニングが生む。 Cloudflareによると、トレーニングは現在AIボット活動の約80%を占め、前年の72%から増えています。大量クロールでreferralゼロが普通である理由です（Cloudflare）。
• 実際のログ期間の1例：288 566行、ボットリクエスト12 099件、48日。 WISLRの事例です。GPTBotが3分で152件取得したバーストと、ChatGPT-Userが画像／CSS／JSをゼロ件取得した結果を含みます（WISLR。

自分で確認する：AI Crawler Log Analysis

AIボットのログを取得して読むことについての簡単な5問です。それぞれ回答を選んでから、答えを確認してください。

変更履歴