AIクローラーのログ確認方法。GPTBot来訪をgrepで実測する手順

結論：AIクローラーの来訪はアクセスログでしか確認できない

先に結論です。GPTBotやClaudeBotが自社サイトに来ているかどうかは、GA4などのアクセス解析ツールでは分かりません。確認できる場所はサーバーのアクセスログ（生ログ）だけです。

LLMO対策の効果検証は、次の3層に分けて考えると迷いません。

本記事が扱うのは第1層です。学習用・検索インデックス用のクローラーが一度も来ていないなら、第2層（引用）や第3層（流入）の改善は原理的に起きにくくなります。逆に、第1層が確認できていれば、「読まれているのに引用されない」という次の課題に絞って手を打てます。3層全体のKPI設計は「LLMOのKPI設計と計測方法」で扱っているため、本記事では第1層の実測手順に集中します。

AIクローラーとは、OpenAIのGPTBot、AnthropicのClaudeBot、PerplexityのPerplexityBotのように、AIモデルの学習・AI検索のインデックス作成・ユーザーの質問に応じたページ取得を目的としてWebサイトを自動巡回・取得するプログラムの総称である。多くはJavaScriptを実行せずHTTPリクエストでページを取得するため、GA4のような計測タグでは観測できず、来訪の有無と頻度はサーバーのアクセスログ（生ログ）でのみ確認できる。

もう1つ、最初に押さえるべき前提があります。AIクローラーは用途によって次の3種類に分かれ、種類ごとにrobots.txtの扱いも「来訪の意味」も異なります。

• 学習用クローラー（GPTBot、ClaudeBot）: AIモデルの学習データ収集が目的。将来のモデルに自社情報が反映されるかに関わる
• 検索インデックス用クローラー（OAI-SearchBot、Claude-SearchBot、PerplexityBot）: AI検索の回答で自社ページを提示するためのインデックス作成が目的。引用・出典表示に直結する
• ユーザー代理フェッチ（ChatGPT-User、Claude-User、Perplexity-User）: ユーザーが質問した瞬間に、その回答のためにページを取得するアクセス。「実際にAI経由で自社ページが参照された」ことを示す強いシグナル

ログを見るときは「来ているか」だけでなく「どの種類が来ているか」を区別することが、後の解釈の精度を決めます。

なぜGA4ではAIクローラーの来訪が見えないのか

GA4でAIクローラーが観測できない理由は2つあります。

第1に、GA4はページに埋め込んだJavaScriptタグ（gtag.js等）が発火して初めて計測される仕組みです。AIクローラーの多くはJavaScriptを実行せず、HTMLをHTTPで取得するだけなので、そもそも計測タグが動きません。

第2に、GA4は既知のボットやスパイダーからのトラフィックを自動的に除外する仕様です。仮にタグが発火するタイプの自動アクセスがあっても、既知ボットとして識別されればレポートには現れません。

ここでよくある誤解が2つあります。

• 誤解1: 「GA4でchatgpt.comからの流入が増えた＝AIクローラーに読まれている」。GA4で見えるのはAIの回答を見た人間がリンクをクリックした流入（第3層）であり、クローラーの来訪（第1層）とは別のものです
• 誤解2: 「GA4でAI経由の流入がゼロ＝AIに読まれていない」。流入がゼロでも、学習用・検索用クローラーが日々クロールしているケースは普通にあります

人間のAI経由流入をGA4で計測する方法は「GA4でAI検索経由の流入を計測する方法」で確認してください。本記事はその手前、クローラー来訪の実測を扱います。

主要AIクローラーのUA一覧（2026年7月時点・公式ドキュメント準拠）

ログ確認の前に、探すべきユーザーエージェント（UA）を確定させます。以下は各社の公式ドキュメントで2026年7月13日に確認した一覧です。

出典は各社の一次情報です。UA文字列やポリシーは更新されるため、実装・判断の前に必ず原文を確認してください。

• OpenAI「Bots」: <a href="https://developers.openai.com/api/docs/bots" target="_blank" rel="noopener">developers.openai.com/api/docs/bots</a>
• Anthropic ヘルプセンター「Does Anthropic crawl data from the web」: <a href="https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler" target="_blank" rel="noopener">support.claude.com</a>
• Perplexity「Crawlers」: <a href="https://docs.perplexity.ai/guides/bots" target="_blank" rel="noopener">docs.perplexity.ai/guides/bots</a>

実際のログに記録される完全なUA文字列は、たとえばGPTBotなら次のような形式です（OpenAI公式ドキュメント記載の例）。

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot

バージョン番号（GPTBot/1.4など）は変わり得るため、ログ検索は完全一致ではなくトークン（GPTBot、ClaudeBotなど）の部分一致で行うのが実務的です。なおAnthropicのヘルプ記事は3種のボット名とポリシーを示していますが、完全なUA文字列の全量列挙はしていないため、こちらもトークンでの部分一致検索を推奨します。

ここで特に覚えておきたいのは、ユーザー代理フェッチ型（ChatGPT-User、Perplexity-User）の扱いです。これらはユーザーの質問に応じたその場のページ取得であり、OpenAIは「robots.txtのルールが適用されない場合がある」、Perplexityは「ユーザーが要求したフェッチのため原則robots.txtを無視する」と公式に説明しています。つまり「robots.txtで全部制御できているはず」という前提はこの型には成立しません。この違いは後述のrobots.txt検証で効いてきます。

Google系の注意点：AI OverviewはGooglebot、Google-Extendedはログに出ない

Google系だけは構造が異なるため、独立して整理します。

• GoogleのAI Overview（AIによる概要）やAIモードに専用のクローラーは存在せず、通常のGoogle検索と同じクロール（Googlebot）に基づきます。したがって「AI Overview用のBotがログに来ているか」を探しても見つかりません
• Google-Extendedは独立したクローラーではなく、robots.txtで指定する制御用トークンです。Google公式ドキュメントは「Google-Extendedは固有のHTTPリクエストUA文字列を持たず、クロールは既存のGoogleのUAで行われる」と明記しています。つまりGoogle-Extendedという文字列はアクセスログには現れません
• Google-Extendedが制御するのはGeminiモデルの学習およびグラウンディングへの利用であり、Google公式は「Google検索への掲載には影響せず、ランキングシグナルとしても使われない」としています

出典: <a href="https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers" target="_blank" rel="noopener">Google検索セントラル「Googleの一般的なクローラー」</a>（2026年7月13日確認）。

実務上の帰結はシンプルです。「Google系のAIに読まれているか」は、ログでGooglebotのクロールを確認するか、Search Consoleのクロール統計情報で見ます。従来のSEOで見てきたクロール監視がそのまま第1層の確認になるため、本記事の以降の手順ではOpenAI・Anthropic・Perplexity系のUAに焦点を当てます。

アクセスログ（生ログ）はどこで手に入るか

確認対象のログは、Webサーバーが全リクエストを記録している「生ログ（アクセスログ）」です。環境別の取得場所は次のとおりです。

一般的なcombined形式のログでは、1行の末尾の引用符内にUA文字列が記録されます。行の構造は「送信元IP、日時、リクエスト行（メソッドとパス）、ステータスコード、転送量、リファラ、UA」の順です。

注意点が2つあります。

• CDN（Cloudflare等）を経由している場合、UAはそのまま記録されますが、オリジンサーバーのログ上の送信元IPがCDNのIPになることがあります。後述するIPでの真正性確認をするには、実IPを復元する設定を入れるか、CDN側のログ機能を使う必要があります
• レンタルサーバーの生ログは保存期間が限られていることが多いため、月次でダウンロードして手元に蓄積する運用にしておくと、施策前後の比較ができます

grepでAIクローラーの来訪を確認する手順

ログファイルが手に入ったら、grepで確認します。以下はaccess.logという名前を前提にしたコマンド例です（レンタルサーバーのログでも、ダウンロードしたファイル名に読み替えれば同じです）。

手順1: まず特定のクローラーが来ているかを確認します。

grep -i "gptbot" access.log

1行でもヒットすれば来訪しています。ヒットしなければそのログ期間には来ていません。

手順2: 主要AIクローラーを一括で横断確認します。

grep -iE "gptbot|oai-searchbot|chatgpt-user|claudebot|claude-user|claude-searchbot|perplexitybot|perplexity-user" access.log

手順3: クローラー別の件数を数えます。

• grep -ic "gptbot" access.log
• grep -ic "claudebot" access.log
• grep -ic "perplexitybot" access.log

手順4: 日別の推移を見ます（combined形式で日時が4列目にある前提）。

grep -i "gptbot" access.log | awk '{print substr($4, 2, 11)}' | sort | uniq -c

手順5: ステータスコードの分布を確認します（9列目がステータスコードの前提）。

grep -i "gptbot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

ここが重要な分岐点です。200が並んでいれば正常に取得されています。403や503が多い場合、WAFやセキュリティプラグインがAIクローラーをブロックしている可能性が高く、「来ているのに読めていない」状態です。robots.txtを整備していても、サーバー側のセキュリティ設定が別レイヤーで拒否しているケースは実際によくあります。

手順6: どのページがクロールされているかを確認します（7列目がリクエストパスの前提）。

grep -i "claudebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

上位に来るURLが、AIクローラーから見た自社サイトの「よく取得されるページ」です。重要な商材ページやピラー記事がここに入っているか、逆にパラメータ付きURLや低価値ページばかりクロールされていないかを見ます。

なお、列番号（$4、$7、$9）はログフォーマットに依存します。コマンドが期待どおり動かない場合は、まず手順1の生の行を目視して、自分のログの列構造を確認してください。

ログから読み取れること・読み取れないこと

ログ分析の限界を正しく理解しておくことが、誤った意思決定を防ぎます。

最も注意すべき点は「クロール＝引用ではない」ことです。GPTBotが毎日来ていても、ChatGPTの回答で自社が引用される保証はありません。クロールは引用の必要条件に近いものであって、十分条件ではありません。ログで確認できるのはあくまで「AIが読める状態になっており、実際に読みに来ている」ことまでです。

一方で、ユーザー代理フェッチ型のヒットは質的に別物です。ChatGPT-UserやPerplexity-Userのアクセスは「誰かがAIに質問し、その回答生成のために自社ページが取得された」ことを意味するため、件数が少なくてもLLMO観点では価値の高いシグナルです。このUA群の対象URLは個別に確認する価値があります。

偽装Botの見分け方：公式IPレンジと逆引きで真正性を確認する

UA文字列は自己申告にすぎず、誰でも偽装できます。実際、GPTBotを名乗る無関係のスクレイパーは存在します。ログのUAだけを信じて「OpenAIが大量に来ている」と判断するのは危険です。真正性は送信元IPで確認します。

OpenAI・Anthropic・Perplexityはいずれも公式にIPレンジを公開しています。

• curl -s https://openai.com/gptbot.json
• curl -s https://openai.com/searchbot.json
• curl -s https://www.perplexity.com/perplexitybot.json
• curl -s https://claude.com/crawling/bots.json

確認手順は次のとおりです。

1. ログから該当UAの送信元IPを抽出する（awkで1列目を取り出し、uniq -cで集計する）
2. 上記の公式JSONに記載されたCIDRレンジに含まれるかを突き合わせる
3. レンジ外のIPからのアクセスは偽装とみなす

Googlebotの場合は、逆引きと正引きの一致確認という公式の検証方法があります。

host 66.249.66.1

逆引き結果がgooglebot.comまたはgoogle.comドメインで、その名前を正引きして元のIPに戻れば本物です。Googleは検証用のIPリストも公開しています。

偽装Botを見つけた場合の扱いも整理しておきます。偽装スクレイパーはrobots.txtを無視するため、対処はWAFやIP単位の拒否になります。このとき、公式レンジからの正規AIクローラーを巻き込んでブロックしないよう、拒否条件は「UAがGPTBotかつIPが公式レンジ外」のように真正性ベースで設計してください。UA文字列だけで一律ブロックすると、正規クローラーごと遮断してLLMO施策が自滅します。

robots.txt設定が効いているかをログで突き合わせる

robots.txtでAIクローラーを許可・拒否する設定方法は「robots.txtでのAIクローラー設定方法」で説明しています。本記事で扱うのは、その設定が実際に機能しているかのログ検証です。

検証手順は4段階です。

1. robots.txtの変更日を記録する。以後の比較の基準点になる
2. クローラーがrobots.txt自体を読みに来ているかを確認する

grep "robots.txt" access.log | grep -iE "gptbot|claudebot|perplexitybot"

robots.txtへのアクセスが確認できれば、少なくとも設定が読まれる経路は生きています。

1. 変更前後で該当UAのヒット件数と対象URLを比較する。Disallowを追加した場合、即日ゼロにはなりません。クローラー側がrobots.txtを再取得して反映するまでのタイムラグがあるためです。数日単位で減衰していれば設定は機能しています
2. 変更後もアクセスが残る場合は、UA種別で解釈を分ける

残るアクセスの解釈がこの検証の核心です。

• ChatGPT-UserやPerplexity-Userが残るのは仕様の範囲内です。前述のとおり、ユーザー起点のフェッチはrobots.txtに従わない場合があると各社が公式に説明しています。これは設定ミスではありません
• 学習用のGPTBotやClaudeBotが、公式IPレンジ内から、Disallow設定後も長期間アクセスし続ける場合は、robots.txtの記述ミスを疑います。User-agent行のスペル、Disallow行のパス指定、設定ファイルが実際に公開URLで配信されているか（CDNやキャッシュで古いrobots.txtが返っていないか）を確認してください

逆方向の事故にも注意が必要です。過去にスクレイピング対策として全Bot拒否を入れたままLLMO対策を始めているケースでは、robots.txtやWAFが学習用・検索用クローラーを全部弾いていて、施策の前提が崩れていることがあります。LLMOに取り組むなら、最初にこの突き合わせを一度行う価値があります。

確認結果の解釈と次のアクション

ログ確認の結果は、大きく2つのケースに分かれます。

ケースA: AIクローラーが来ていない（該当UAのヒットがゼロ、または403/503ばかり）

なお、llms.txtの設置はサイト情報をAI向けに整理する施策であり、それ自体がクローラーを呼び込む仕組みではありません。役割と限界は「llms.txtとは何か。書き方と設置方法」で確認してください。

ケースB: 来ているのに引用されない

第1層は合格しており、課題は第2層（引用層）にあります。クローラーが取得したページが「引用しやすい構造」になっているか——冒頭の結論提示、単独で意味が通る定義ブロック、運営者・著者情報の明確さ、一次情報の裏付け——を点検する段階です。あわせて、どのAIにどんなクエリで自社が言及されるかの観測を定点化し、第1層のログ数値と並べて月次で記録すると、施策と結果の対応が追えるようになります。

最後に、継続運用の型を示します。

1. 月次で生ログをダウンロードし、AIクローラー別のヒット件数・ステータス分布・上位クロールURLを記録する
2. robots.txt・WAF・コンテンツの変更履歴と突き合わせ、変化の要因を特定できる状態を保つ
3. ユーザー代理フェッチ（ChatGPT-User等）の対象URLは毎回確認し、実際に参照されているテーマを把握する

ここまでの手順で「AIに読まれているか」は自社で実測できます。そのうえで、引用のされ方・競合との比較・改善優先度まで含めた全体像を把握したい場合は、まず<a href="https://uravation.com/llmo/#diagnosis">AI検索攻略のセルフ診断</a>で現状を確認し、体系的な診断が必要であれば<a href="https://uravation.com/contact/?ref=llmo_diagnosis&cta_type=llmo_audit">LLMO診断の相談窓口</a>からご相談ください。

本記事に記載した各AIクローラーのUA・用途区分・robots.txtポリシー・IPレンジ公開状況は、OpenAI・Anthropic・Perplexity・Googleの公式ドキュメントで2026年7月13日に確認した内容に基づきます。各社のポリシーは変更され得るため、実装前に必ず一次情報を確認してください。

EDITORIAL REVIEW AI検索攻略編集部（株式会社Uravation）

生成AI・AI検索・SEOの公開情報を確認しながら、企業サイトの情報設計として実務で扱える形に整理しています。仕様変更が多い領域のため、公開前後に公式情報と本文の整合性を確認します。