AIクローラーのログ分析｜OAI-SearchBotとGooglebotを見分ける
AIクローラー ログ 分析では、User-Agentだけで断定せず、IP検証、HTTP状態、取得先を照合します。OAI-SearchBotとGooglebotを偽装ボットから見分け、引用確認と分離する手順を解説します。
この記事の目次を開く
AIクローラー ログ 分析の結論は、User-Agentに OAI-SearchBot や Googlebot が含まれるだけでは本物と判定せず、送信元IPを公式情報で検証し、HTTPステータスとクロール先を照合することです。訪問回数は「来た」という記録であって、検索掲載やAI回答での引用という成果ではありません。
OAI-SearchBotとGooglebotは、どちらも検索に関わるクローラーですが、運営主体も用途も検証方法も異なります。ログを同じ「bot」集計へ丸めると、OpenAI向けだけWAFに拒否されている、偽装Googlebotが負荷を生んでいる、といった問題が隠れます。
では、IP検証を通ったアクセスが 200 なら正常といえるでしょうか。まだ断定できません。必要なページへ到達したのか、リダイレクトやエラーページを取得していないかまで見て、初めて診断材料になります。以下は2026年8月8日に確認した各社の公式情報を基準にした手順です。
OAI-SearchBotとGooglebotは目的から分ける
OpenAIの公式クローラー文書では、OAI-SearchBot はChatGPTの検索機能でWebサイトを検索結果に表示するためのボットです。同じOpenAIでも、基盤モデルの学習に利用される可能性があるコンテンツを収集する GPTBot、ユーザー操作を起点にページへアクセスする ChatGPT-User とは役割が分かれています。三者を「ChatGPTのアクセス」として合算すると、検索向けクロールの診断ができません。
一方、Googleの公式説明では、Googlebot はGoogle検索の一般的なクローラーです。OpenAIの検索用ボットとGoogle検索用ボットは、次のように別系列で記録します。
| ログ上の識別対象 | 主な役割 | 確認すべき公式情報 |
|---|---|---|
OAI-SearchBot | ChatGPT検索でWebサイトを表示するための検索クロール | OpenAIのクローラー文書と公開IP範囲 |
Googlebot | Google検索のクロール | Googleの公開IP範囲、または正引き・逆引き |
GPTBot | OpenAIの基盤モデル改善・学習に関わるクロール | OAI-SearchBotとは別に集計 |
ChatGPT-User | ユーザー操作に伴うページ取得 | 検索用クローラーとは別に集計 |
この区別は名前の整理ではありません。robots.txt やWAFの方針、障害の影響範囲を用途ごとに判断するための前提です。設定側の違いは、公開済みのAIクローラーのrobots.txt設定で確認できます。
AIクローラーのログ分析は5項目を残す
調査用の最小データは、時刻、送信元IP、User-Agent、リクエスト先、HTTPステータスです。可能ならレスポンスサイズ、処理時間、ホスト名、CDN・WAFの判定も同じイベントへ結び付けます。CDNを利用している場合、オリジンサーバーの接続元がCDNのIPになる構成もあるため、信頼するプロキシを限定したうえで元のクライアントIPを記録しなければなりません。
最初の抽出は、たとえば次のようにUser-Agentで候補を絞ります。ログ形式や圧縮・ローテーション方式に合わせて読み替えてください。
grep -iE 'OAI-SearchBot|Googlebot|GPTBot|ChatGPT-User' access.log
これは本人確認ではなく候補抽出です。User-Agentは第三者も同じ文字列を送れます。「Googlebotと書いてあるから許可する」というWAFルールは、偽装アクセスにも許可を与えかねません。
集計時は少なくとも verified_provider、user_agent_family、status_class、path を別列にします。日別件数だけの表では、同じ100件でも、公開記事を正常取得したアクセスと、存在しないURLへ連続した偽装アクセスを区別できないからです。
User-Agentの次にIPを検証する
OAI-SearchBotは、OpenAIの公式クローラー文書から案内される公開IP範囲と送信元IPを照合します。表示例のUser-Agentにはバージョン番号が含まれ、robots.txt の取得時には識別用のマーカーが加わる場合もあります。公式文書もバージョン番号が変わり得ると明記しているため、完全な文字列の固定一致より、公式のエージェント名を抽出し、その後にIP範囲を検証する設計が安全です。
IPリストは転記して固定せず、公式URLから定期取得し、取得日時を残します。公式範囲に含まれない OAI-SearchBot 名義の通信は、検証済みOpenAIクローラーとして集計しません。
Googlebotは、Googleの公式検証手順に二つの方法があります。大量処理では公開JSONのIP範囲と照合し、個別調査ではDNSを使います。
- ログの送信元IPを逆引きする
- 得られたホスト名が
googlebot.com、google.com、またはgoogleusercontent.comの正規ドメインか確認する - そのホスト名を正引きする
- 正引き結果が元の送信元IPと一致するか確認する
逆引きでGoogleらしい名前が返るだけでは足りません。正引きで元のIPへ戻ることまで確かめるのが、偽装名を排除する要点です。Googleは一般クローラー、特殊クローラー、ユーザー起点のフェッチャーで公開IPリストを分けているため、Googlebot の診断では対象カテゴリを混ぜないようにします。
HTTP状態とクロール先から問題を診断する
本人確認の後は、HTTPステータスをクローラー別・URL別に見ます。判断の目安は次の通りです。
2xx: 取得には成功しているが、目的の本文が返ったかをレスポンスサイズや実URLで確認する3xx: 転送先とチェーンを確認し、HTTPS化やURL正規化による意図した転送かを分ける401/403: 認証、CDN、WAF、Bot対策が拒否していないか確認する404/410: 古いURL、誤った内部リンク、削除済みURLへのアクセスかを確認する429: レート制限の対象、しきい値、Retry-Afterの有無を確認する5xx: アプリケーション、オリジン、CDNのどの層で失敗したかを時刻で突き合わせる
200 が多いというだけでは正常判定になりません。ソフト404、共通エラー画面、ログインページが 200 を返す構成もあるため、重要URLは実際のレスポンス本文と最終URLを別途確認します。
クロール先は、トップページ、記事、サービスページ、robots.txt、サイトマップ、画像・CSS・JavaScript、存在しないURLなどに分類します。公開した記事へOAI-SearchBotが来ない一方、robots.txt にだけ来ているなら、サイト全体の「訪問あり」表示は問題を覆い隠します。反対に、Googlebotだけが多くても、OAI-SearchBot向けの到達性を示す証拠にはなりません。
対象URLへ到達しても本文がJavaScript実行後にしか現れない場合は、ログの200だけで取得成功としません。JavaScriptサイトのLLMO対策で、初期HTMLとレンダリング後の本文・リンクを分けて検証できます。
診断の順序は、UA候補の抽出、IP検証、状態コード、取得URL、設定確認です。403 なら最初にアクセスを許可するのではなく、本物のIPかを確かめてから、robots.txt、CDN、WAF、アプリケーションの各層を調べます。無条件の許可は偽装ボットへの防御まで外す可能性があります。
アクセス頻度と引用を同じ成果にしない
クロール回数が増えると、対策が効いたように見えます。しかし、公式情報が示すのはクローラーの用途と制御方法であり、訪問回数から引用や順位を約束する関係ではありません。OpenAIはOAI-SearchBotの許可を検索結果へ現れるための入口として案内していますが、許可は掲載・引用の保証ではありません。
測定は四つの帳票へ分けます。
- クロール: 検証済みボットの日時、URL、HTTP状態、件数
- 検索: Google Search Consoleなどで確認できる表示、クリック、掲載URL
- 引用: 対象の質問、確認日時、回答内の引用URL、回答条件
- 流入・成果: AIサービスからの参照流入と、その後の問い合わせ
この分離によって、「OAI-SearchBotは正常に取得したが引用は未確認」「Googlebotは取得できるが特定URLで5xxが増えた」と事実の粒度を保てます。KPI全体の設計はLLMOの効果測定、ChatGPT上で見つからない場合の切り分けはChatGPTで自社が出てこないときに確認する7項目も参考になります。
誤判定を防ぐ運用チェック
一度の調査で終わらせず、公式IPリストの更新、ログ保存期間、タイムゾーン、CDNとオリジンの時刻差を管理します。
定例確認では、次を同じ期間で比較します。
- 公式IP検証を通過したクローラー別の件数
- URL分類ごとの
2xx、3xx、4xx、5xx robots.txt、CDN、WAF、デプロイの変更履歴- 重要ページの最終URLと実レスポンス
- AI回答の引用URL、検索表示、参照流入
変更履歴を重ねると、アクセス減少が需要の変化なのか、WAF変更後の拒否なのかを追いやすくなります。ただし相関だけで原因を断定せず、該当時刻のリクエストと設定で再確認します。
ログで分かることを限定すれば、診断は正確になる
AIクローラーのログ分析で確定できるのは、検証済みの送信元が、いつ、どのURLへ来て、サーバーが何を返したかです。OAI-SearchBotとGooglebotは別々に抽出し、UAを入口、IPを本人確認、HTTP状態とクロール先を到達性の証拠として扱います。
冒頭に残した「IP検証済みで 200 なら正常か」という問いへの答えは、対象ページの実コンテンツまで返っていれば、クロール到達性については正常と判断できる、です。それでも引用や順位、流入までは証明しません。アクセス頻度、技術的な取得、検索表示、AI回答での引用、流入を分けて記録することが、偽装ボットを除外しながら本当の問題だけを直す最短の運用です。