検索ブランド相談室 | 検索と評判の専門メディア
無料相談

AIクローラーをアクセスログで確認する方法｜主要ボットの識別とクロール阻害の診断

部署：マーケティング担当者レベル：実践AIO 公開日 2026.08.23　更新日 2026.08.27

監修: 菊地 将（リブランディング株式会社）

「ChatGPTやClaudeのクローラーは自社サイトに来ているのか」「robots.txtでは許可しているのに、なぜ巡回されないのか」。これらを確かめるには、GA4ではなく、CDN・WAF・Webサーバーのアクセスログを確認します。重要なのは、User-Agentを検索するだけで終わらず、送信元IP、HTTPステータス、取得URL、robots.txtの応答を順番に照合することです。本記事では、主要なAIクローラーの識別方法から、阻害箇所の切り分け、修正後の検証までを実務手順として解説します。

AIクローラーの確認では、どのログを見るべきか

最初に確認すべきなのは、AIクローラーからのHTTPリクエストが記録されるアクセスログです。一般的なAIクローラーは、人間のブラウザと違ってGA4の計測用JavaScriptを実行するとは限りません。そのため、GA4にアクセスがないことだけでは「AIクローラーが来ていない」と判断できません。

AIクローラーの確認では、どのログを見るべきかの全体像や前提から確認したい場合は、「AIOの技術対策とは？企業担当者が押さえるべき8領域の実務チェックリスト」を参照してください。

AIクローラーの確認では、どのログを見るべきかの全体像や前提から確認したい場合は、「AIOの技術対策とは？企業担当者が押さえるべき8領域の実務チェックリスト」を参照してください。

kpi measurement process

オリジンサーバーに記録がなくても、CDNやWAFまで到達し、そこで遮断されている可能性があります。

確認対象は、サイト構成に応じて次の3層に分かれます。

確認するログ分かること主な注意点
CDN・エッジログCDNまで到達したリクエスト、エッジ側の拒否オリジンサーバーへ転送されない403・429も確認できる
WAF・Bot管理ログセキュリティルール、Bot判定、チャレンジの結果User-Agentだけでなく、適用ルール名も確認する
Nginx・ApacheなどのアクセスログURL、日時、ステータス、転送量、User-AgentCDN経由では送信元IPがCDNのIPになることがある

CDNを利用している場合、オリジンサーバーのログだけでは不十分です。CDNやWAFで遮断されたリクエストは、オリジンサーバーまで届かないためです。

ログには最低限、次の項目を保存します。

  • リクエスト日時
  • クライアントIP
  • HTTPメソッド
  • ホスト名
  • リクエストURL
  • HTTPステータスコード
  • User-Agent
  • 応答時間
  • 応答サイズ
  • CDN・WAFの判定結果
  • オリジンサーバーの応答コード

主要なAIクローラーは目的別に分けて識別する

AI関連のアクセスは、学習用、検索用、ユーザー操作による取得に分けて集計します。同じ会社のボットでも用途が違うため、一括して許可・拒否すると、意図しない範囲まで制限する可能性があります。

n 0016 article visual

同じAI事業者のアクセスでも用途は異なります。検索露出の障害を調べる場合は、検索用ボットを優先して確認します。

2026年8月時点で優先的に確認したい名称は次のとおりです。

運営者ログで探す文字列主な用途診断上の扱い
OpenAIGPTBot生成AIモデルの学習候補となるコンテンツの収集検索表示用ボットと分ける
OpenAIOAI-SearchBotChatGPT検索でサイトを表示するためのクロールAI検索への露出に直接関係
OpenAIChatGPT-Userユーザー操作に応じたページ取得自動クロールではない
AnthropicClaudeBotモデル開発用の収集検索用ボットと分ける
AnthropicClaude-SearchBotClaudeの検索品質向上検索露出の診断対象
AnthropicClaude-Userユーザー操作に応じた取得件数が少なくても個別確認
PerplexityPerplexityBotPerplexity検索結果への表示・リンク検索用クローラー
PerplexityPerplexity-Userユーザー質問に応じた取得自動クロールと分離
GoogleGooglebotGoogle検索のクロールAI Overviewsを含む検索基盤の確認に使用

OpenAIは、OAI-SearchBotを検索用、GPTBotをモデル学習用、ChatGPT-Userをユーザー操作に伴う取得用と説明しています。OAI-SearchBotを拒否したサイトは、ナビゲーションリンクを除き、ChatGPT検索の回答へ表示されないとされています。

Google系では注意が必要です。Google-Extendedはrobots.txtで利用する制御用トークンであり、アクセスログに現れる独立したHTTP User-Agentではありません。GoogleのAI機能に関係するクロール状況を確認するときは、GooglebotのログとGoogle Search Consoleのクロール統計を確認します。

アクセスログからAIクローラーを抽出する

まず、対象期間のログを用意し、主要名称の部分一致で抽出します。バージョン番号は変更される可能性があるため、完全なUser-Agent文字列ではなく、GPTBotなどの識別トークンで検索します。

アクセスログからAIクローラーを抽出するに関連して次に確認したい論点は、「AIOの構造化データ実装ガイド」で詳しく解説しています。

アクセスログからAIクローラーを抽出するに関連して次に確認したい論点は、「AIOの構造化データ実装ガイド」で詳しく解説しています。

NginxやApacheの一般的なテキストログでは、次のように確認できます。

grep -iE

‘gptbot|oai-searchbot|chatgpt-user|claudebot|claude-searchbot|claude-user|perplexitybot|perplexity-user’

access.log

ローテーションされた圧縮ログも含める場合は、zgrepを使います。

zgrep -hiE

‘gptbot|oai-searchbot|chatgpt-user|claudebot|claude-searchbot|claude-user|perplexitybot|perplexity-user’

access.log*.gz

ボット別の件数を集計する

単純な来訪有無だけでなく、ボット別、日別、URL別、ステータス別に集計します。

for bot in GPTBot OAI-SearchBot ChatGPT-User ClaudeBot Claude-SearchBot Claude-User PerplexityBot Perplexity-User

do

printf ‘%-20s ‘ “$bot”

grep -ic “$bot” access.log

done

ステータスコードと取得URLを確認する

一般的なcombined形式でHTTPステータスが9列目、URLが7列目にある場合は、次のように集計できます。

grep -i ‘OAI-SearchBot’ access.log |

awk ‘{print $9}’ |

sort |

uniq -c |

sort -rn

grep -i ‘OAI-SearchBot’ access.log |

awk ‘{print $7}’ |

sort |

uniq -c |

sort -rn |

head -20

ただし、列位置はログ形式によって異なります。JSON形式のログや、空白を含む独自形式では、固定列を前提にしたawkが誤集計することがあります。最初にログの定義と実際の1行を照合してください。

User-Agentだけで正規のAIクローラーと判断しない

User-Agentは送信者が自由に設定できるため、GPTBotと記録されていてもOpenAIからのアクセスとは限りません。正規ボットとして集計するときは、公式IPレンジまたは運営者が指定する認証方法と照合します。

process 2

User-Agentは偽装できるため、送信元IPを最新の公式IPレンジと照合し、正規アクセスと未確認アクセスを分けます。

OpenAIは、GPTBot、OAI-SearchBot、ChatGPT-Userについて、それぞれ公式IPレンジのJSONを公開しています。AnthropicとPerplexityも公式の送信元IP情報を案内しています。

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

  1. ログからUser-Agentと送信元IPを抽出する
  2. 該当事業者の最新IPリストを取得する
  3. 送信元IPが公式CIDR内に含まれるか判定する
  4. 一致しないアクセスは「未確認・偽装疑い」として分ける
  5. CDN経由の場合は、CDNが付与する実IPを正しく復元できているか確認する

公式IPリストは更新されるため、WAFへ手作業で固定登録したままにせず、定期更新する仕組みが必要です。

Googlebotについては、Googleが逆引きと正引きを組み合わせる検証方法を案内しています。

host 66.249.66.1

host crawl-66-249-66-1.googlebot.com

逆引き結果が所定のGoogleドメインであり、そのホスト名を正引きした結果が元のIPへ戻ることを確認します。逆引き結果のドメイン名だけを信用してはいけません。

ステータスコードからクロール阻害を診断する

AIクローラーがログに存在しても、目的のページを正常取得できているとは限りません。ボット別・URL別にレスポンスを確認し、次の基準で原因を切り分けます。

ログの状態主な意味優先して確認する場所
200HTMLを正常に返した本文内容、canonical、内部リンク
301・302別URLへ転送したリダイレクト先、ループ、ホスト統一
304キャッシュ済み内容を再利用できる状態通常は異常ではない
401認証が必要公開対象URLへ認証が誤適用されていないか
403アクセス拒否WAF、Bot対策、IP制限、CDNルール
404・410URLが存在しない、または削除済みサイトマップ、内部リンク、旧URL
429リクエスト過多として制限レート制限、Bot管理ルール
5xxサーバー・ネットワーク側の失敗オリジン障害、タイムアウト、負荷、WAF
ログなし未訪問とは限らないCDN遮断、ログ欠損、保存期間、検索条件

200の割合だけを見るのではなく、「公開・引用してほしい重要URLが200になっているか」を確認します。画像、CSS、存在しないURLへの200が多くても、重要な記事やサービスページが403なら、目的を達成できていません。

robots.txt・CDN・WAFのどこで阻害されているか切り分ける

クロール阻害は、robots.txt、CDN・WAF、Webサーバー、アプリケーションの順に確認すると効率的です。

deletion

CDNログとオリジンログを順番に照合し、未訪問、エッジ側の遮断、正常取得、応答エラーを切り分けます。

1．robots.txtの取得とルールを確認する

対象のUser-Agentを付け、robots.txtと重要URLの応答を確認します。

curl -I -A ‘OAI-SearchBot’ https://example.com/robots.txt

curl -I -A ‘OAI-SearchBot’ https//example.com/important-page/

robots.txtでは、次の点を確認します。

  • https://対象ホスト/robots.txtが取得できる
  • 200でtext/plainとして返される
  • 対象ボットにDisallow: /が設定されていない
  • ワイルドカードグループとの重複を確認した
  • wwwあり・なしやサブドメインごとに確認した
  • リダイレクトループや5xxが発生していない

IETFのRFC 9309では、robots.txtが4xxの場合、クローラーはリソースへのアクセスを許可されたものとして扱うことがあります。一方、ネットワーク障害や5xxで取得不能な場合は、原則として一時的に全面拒否として扱います。robots.txtの503を「拒否設定は書いていないから問題ない」と判断するのは危険です。

2．CDN・WAFの判定を確認する

CDNログにはリクエストがあるのにオリジンログにない場合、エッジ側で止まっています。次を確認します。

  • Bot Fight ModeなどのBot対策
  • マネージドルール
  • IPレピュテーション判定
  • 国・ASN・地域による制限
  • JavaScriptチャレンジやCAPTCHA
  • レート制限
  • User-Agentの部分一致による拒否
  • 公式IPレンジの許可設定
  • ルールの優先順位

許可ルールはUser-Agentだけで作らず、公式IPレンジとのAND条件を基本にします。これにより、正規ボットを許可しながらUser-Agent偽装を除外できます。

3．Webサーバーとアプリケーションを確認する

オリジンまで到達している場合は、Nginx・Apache・CMS・セキュリティプラグインを確認します。

特定のUser-Agentを拒否する設定、Basic認証、メンテナンス設定、IP制限、過剰なレート制限、アプリケーションエラーが代表的な原因です。ヘッドレスCMSやJavaScript中心のサイトでは、ステータス200でも初期HTMLに主要本文が含まれているか確認してください。

「ログにない」場合は5つの可能性を順番に確認する

ログ検索が0件でも、直ちに「AIサービスに無視されている」とは判断できません。

  1. 対象期間中に実際の来訪がなかった
  2. ログの保存期間が短く、過去の記録が消えている
  3. CDN・WAFで止まり、オリジンログに残っていない
  4. User-Agent検索の名称や大文字・小文字が誤っている
  5. CDN経由でIPやログ形式が変換され、抽出に失敗している

最初にログ保存期間と記録項目を確認し、次にCDN、WAF、オリジンの各層を照合します。robots.txtを変更した直後は、各事業者の反映時間や次回クロールまで待ってから再測定します。

修正の優先順位は「全体拒否・重要ページ・効率低下」の順に決める

検出した問題は、影響範囲と検索露出への近さで優先順位を付けます。

優先度状態対応
最優先robots.txtが5xx、検索用ボットを全面拒否、WAFで全件403全体障害を修正し、公式IPで再検証
高重要記事・サービスページだけ403、404、5xxURL単位のルールとアプリを修正
中429が多い、応答が遅い、リダイレクトが連続レート制限と処理性能を調整
中低価値URLばかり取得される内部リンク、サイトマップ、URL設計を改善
低一部の偽装ボットが正規ボット名を使用公式IP外をWAFで分離・制限

AI検索への掲載を重視する場合は、学習用ボットよりもOAI-SearchBot、Claude-SearchBot、PerplexityBotなど検索用途のアクセス障害を先に確認します。

修正後は同じ条件で再測定する

設定変更後は、変更前後を比較できる形で検証します。最低限、次の指標を週次または月次で記録します。

  • 正規ボット別のリクエスト数
  • 200、3xx、4xx、5xxの割合
  • 重要URLのクロール有無
  • 初回取得日と最終取得日
  • 403・429・5xxが発生したURL
  • robots.txtの取得結果
  • ユーザー操作型アクセスの対象URL
  • 設定変更日

ログで分かるのは、「どのボットが、いつ、どのURLへ来て、サーバーが何を返したか」までです。クロールされたことだけでは、AI回答への引用、モデル学習への採用、ブランドの推薦を証明できません。引用状況は、主要な質問でAI回答を定点観測し、参照URLやブランド言及を別途測定します。

まとめ

AIクローラーの来訪と阻害を確認するには、GA4ではなく、CDN・WAF・Webサーバーのアクセスログを使います。User-Agentで主要ボットを抽出した後、公式IPレンジで真正性を確認し、URL別のHTTPステータスから阻害箇所を切り分けてください。

診断は「ログの取得範囲」「正規ボットの識別」「robots.txt」「CDN・WAF」「オリジン」「修正後の再測定」の順で進めると、来訪がない状態と、来訪しているが拒否している状態を区別できます。まず直近30〜90日分のログを保存し、検索用AIクローラーが重要ページから200を受け取れているか確認することが実務上の第一歩です。

参考文献・データ元

‹ 親記事: AIOの技術対策とは？企業担当者が押さえるべき8領域の実務チェックリスト

関連記事

関連テーマ

SEO MEO 口コミ・風評対策 採用改善 集客改善

関連記事

無料相談はこちら