【2026年版】AEO×「AIクローラーログ解析」実践ガイド——GPTBot・ClaudeBot・PerplexityBotがサイトのどこをいつクロールしているかをサーバーログとCloudflareで可視化し、”引用される前段階＝AIに読まれているか”を測る

はじめに——「引用されたか」の前に、「そもそも読まれているか」がある

これまでのAEO（Answer Engine Optimization）記事では、シェア・オブ・モデルの継続計測、引用劣化（Citation Decay）の監視、競合ギャップ分析、施策の因果推定といった「AIに引用されたかどうか＝出口」の測定を中心に扱ってきました。llms.txt・robots.txt・sitemap設計の記事では、AIクローラーに「どう読ませるか」の設計も整理しました。

しかし、その間には大きな欠落があります。設計した通りに、AIクローラーは本当にサイトを読みに来ているのか——という「入口」の実測です。引用は「クロールされ、取り込まれ、回答生成時に選ばれる」という因果チェーンの最終段であり、そもそもクロールされていないページは、どれだけコンテンツを磨いても引用されようがありません。

そして、この入口はChatGPTに質問を投げても、分析ツールのダッシュボードを眺めても分かりません。唯一の一次データはサーバーログです。GPTBot・ClaudeBot・PerplexityBotがいつ、どのページに、何回アクセスし、何を持ち帰り、どこで404を踏んでいるか——すべてログに残っています。

筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで長年トラフィック解析に携わってきました。本記事はその発想をAEOに持ち込み、生ログ・Cloudflare・BigQueryの3段構えでAIクローラーの実態を可視化し、「施策→クロール→引用」の因果チェーンの欠けたピースを埋める実装ガイドです。

想定読者は、AEO施策を打ちながら「効いているのか分からない」と感じているWeb担当者・マーケター、そして自社サイトのログにアクセスできる（またはCloudflareを使っている）情シス・開発者の方々です。

前提整理——AIクローラーは3タイプに分かれる

「AIボット」と一括りにされがちですが、アクセスの目的によって3タイプに分かれます。タイプによって「引用への効き方」がまったく違うため、ログ解析でも必ず分けて集計します。

  1. 学習用クローラー：基盤モデルの学習データ収集が目的。許可してもすぐ引用にはつながらないが、将来のモデルの「地の知識」に入る。例：GPTBot、ClaudeBot、CCBot、Bytespider。
  2. 検索インデックス用クローラー：AI検索の索引構築が目的。AEOの観点で最重要。ここに読まれていなければAI検索の回答候補に入らない。例：OAI-SearchBot、Claude-SearchBot、PerplexityBot。
  3. ユーザー起点フェッチ：ユーザーがAIに質問した瞬間、リアルタイムにページを取得しに来るアクセス。「実際に回答の材料として参照された」ことを示す強いシグナル。例：ChatGPT-User、Claude-User、Perplexity-User。ユーザー操作起点のため、robots.txtが適用されない場合があります。

主要ボットを運営会社別に整理すると次のようになります。

運営会社学習用検索インデックス用ユーザー起点フェッチIP範囲の公開
OpenAIGPTBotOAI-SearchBotChatGPT-Userあり（各ボットのJSONを公開）
AnthropicClaudeBotClaude-SearchBotClaude-User限定的（最新状況は公式ドキュメントで確認）
Perplexity—PerplexityBotPerplexity-Userあり
GoogleGoogle-Extended（robots.txtトークン）Googlebot（AI Overviews等と共用）—あり
Common CrawlCCBot——あり

ユーザーエージェント（UA）文字列の例を挙げます（バージョン番号は変わり得ます）。ログ解析ではこの「識別子部分」でマッチさせます。

# OpenAI（例）
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot
Mozilla/5.0 (...); compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot

1つ注意点があります。UAは自己申告であり、偽装できます。傾向分析はUAベースで十分ですが、ブロック判断や厳密な計測ではIP検証を併用します。OpenAIは各ボットのIP範囲をJSONで公開しており（例：openai.com/gptbot.json）、PerplexityやGoogleも同様の公開を行っています。公開JSONがないベンダーは逆引きDNS等での補助確認になります。

測るべき4つの指標——頻度・カバレッジ・404率・クロール予算

ログから何を集計すべきか。AEOの入口計測として意味を持つのは次の4指標です。

指標定義何が分かるか
クロール頻度ボット別・日別のリクエスト数自社サイトがAI各社にとって「定期巡回対象」になっているか。施策後の変化検知の基本線
カバレッジクロールされたユニークURL数 ÷ 重要ページ総数（sitemap照合）「読まれてほしいページ」が実際に読まれているか。稼ぎ頭の記事が未クロールなら重大問題
404率・エラー率ボット別の4xx/5xx応答比率AIクローラーが壊れたリンクや削除済みURLに予算を浪費していないか。リダイレクト整備の優先根拠
クロール予算の配分ディレクトリ（パスパターン）別のリクエスト構成比AIが「サイトのどこ」を重点的に読んでいるか。意図しない領域（タグページ・検索結果ページ等）への浪費を検出

加えてAEOならではの視点として、ユーザー起点フェッチ（ChatGPT-User等）が「どのページ」に来ているかを必ず分けて見ます。これは「AI回答の材料として実際に参照されたページ」のリストそのものであり、出口側の引用計測と突き合わせる接点になります。

手法1：生サーバーログ解析——コマンド一発から始める

Nginx/Apacheのアクセスログが手元にあるなら、コストゼロで今日から始められます。まずはボット別の出現回数です。

# アクセスログからAIクローラーの出現回数を集計（Nginx/Apache共通の発想）
grep -ciE "GPTBot" access.log
grep -oiE "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|CCBot|Bytespider" access.log \
  | sort | uniq -c | sort -rn

次に、AEOの核心である「ボット別・パス別」の集計です。awkでUAとリクエストパスを抜き出します（combinedログ形式を想定。フィールド位置は自環境に合わせて調整してください）。

# GPTBotが読んでいるページTOP20
grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

# GPTBotが踏んでいる404 TOP20（クロール予算の浪費ポイント）
grep -i "GPTBot" access.log | awk '$9 == 404 {print $7}' | sort | uniq -c | sort -rn | head -20

# 日別のクロール頻度推移（施策前後の比較用）
grep -i "OAI-SearchBot" access.log | awk -F'[' '{print substr($2,1,11)}' | sort | uniq -c

UA偽装を除外したい場合は、公開IPレンジとの照合を挟みます。

# OpenAIの公開IPレンジを取得して照合リストを作る
curl -s https://openai.com/gptbot.json | jq -r '.prefixes[].ipv4Prefix' > gptbot_ranges.txt
# ログ中のGPTBot申告IPがレンジ内かをスクリプトで検証（grepcidr等を利用）
grep -i "GPTBot" access.log | awk '{print $1}' | sort -u | grepcidr -f gptbot_ranges.txt

この段階で既に、「ClaudeBotは毎日来ているがOAI-SearchBotは月数回しか来ない」「PerplexityBotが削除済みの旧URLで404を量産している」といった、ダッシュボードでは決して見えない事実が手に入ります。

手法2：Cloudflare AI Crawl Control——ログに触れない人の最短ルート

サイトがCloudflareを経由しているなら、AI Crawl Control（旧AI Audit）が最短ルートです。生ログにアクセスできないマーケターでも、ダッシュボードでAIクローラーの実態を確認できます。ダッシュボードは「Overview」「Crawlers」「Metrics」の3タブ構成です。

  • Overviewタブ：総リクエスト数・増減・最頻ステータスコード・最多アクセスパスのサマリと、運営会社（OpenAI・Anthropic・Google・ByteDance等）別のクローラー活動一覧。
  • Crawlersタブ：クローラー別のリクエスト数・データ転送量と、個別のAllow/Block制御。クローラーごとのUA文字列コピーやメトリクスへのドリルダウンも可能。
  • Metricsタブ：時系列のリクエスト推移（クローラー別・運営会社別・カテゴリ別）、ステータスコード分布（2xx/3xx/4xx/5xx）、人気パスランキング。Patternsタブでは「/blog/*」のようなURIパターン単位で集計され、AIがサイトのどの領域を重点的に読んでいるかが一目で分かります。

本記事の4指標との対応はこうなります。クロール頻度は「Requests over time」、404率は「Status code distribution」、クロール予算の配分は「Patterns」、カバレッジは「Most popular paths」のCSVエクスポートとsitemapの照合で算出します。データはCSVダウンロードとGraphQL Analytics APIの両方で取り出せるため、後述のBigQuery解析にもつなげられます。

さらに、有料プランではReferrals（AI経由の参照流入）も見られます。「クロールされた量」と「AIからの流入」を同じ画面で比較できるため、クロールばかりされて流入が返ってこないボットの特定——ブロックやPay Per Crawl（クロール課金・ベータ）の判断材料——にもなります。

注意点として、AI Crawl Controlが識別するのはCloudflareが検証済みのボットです。網羅性・自由度では生ログに劣るため、「まずCloudflareで全体像→深掘りは生ログ／BigQuery」という併用が現実解です。

手法3：BigQueryで本格解析——カバレッジと施策効果を数字にする

週次・月次でレポートを回し、施策効果まで測るなら、ログをBigQueryに取り込みます。取り込み経路は、(1) 生ログをCloud Storage経由でロード、(2) Cloudflare Logpushで直接転送、(3) GraphQL APIで集計済みデータを定期取得、のいずれでも構いません。以下はログテーブル（timestamp、ip、path、status、user_agentカラム）を想定したクエリ例です。

まず、ボット別・日別のクロール頻度です。

-- ボット別・日別クロール頻度
SELECT
  DATE(timestamp) AS day,
  CASE
    WHEN user_agent LIKE '%OAI-SearchBot%' THEN 'OAI-SearchBot'
    WHEN user_agent LIKE '%ChatGPT-User%' THEN 'ChatGPT-User'
    WHEN user_agent LIKE '%GPTBot%' THEN 'GPTBot'
    WHEN user_agent LIKE '%Claude-SearchBot%' THEN 'Claude-SearchBot'
    WHEN user_agent LIKE '%Claude-User%' THEN 'Claude-User'
    WHEN user_agent LIKE '%ClaudeBot%' THEN 'ClaudeBot'
    WHEN user_agent LIKE '%Perplexity-User%' THEN 'Perplexity-User'
    WHEN user_agent LIKE '%PerplexityBot%' THEN 'PerplexityBot'
  END AS bot,
  COUNT(*) AS requests,
  COUNTIF(status = 404) / COUNT(*) AS error_rate_404
FROM `project.dataset.access_logs`
WHERE user_agent LIKE '%Bot%' OR user_agent LIKE '%-User%'
GROUP BY day, bot
HAVING bot IS NOT NULL
ORDER BY day DESC, requests DESC;

判定順序に注意してください。GPTBotより先にOAI-SearchBotを判定しないと（部分一致のため）誤分類しませんが、ClaudeBotとClaude-SearchBotのように包含関係のある名前は「長い方から」判定するのが安全です。

次が本命のカバレッジです。sitemapのURL一覧をテーブル化し、クロール実績と突き合わせます。

-- 重要ページのAIクロールカバレッジ（sitemap照合）
WITH crawled AS (
  SELECT DISTINCT path
  FROM `project.dataset.access_logs`
  WHERE user_agent LIKE '%OAI-SearchBot%'
    AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
)
SELECT
  COUNT(s.url) AS total_pages,
  COUNTIF(c.path IS NOT NULL) AS crawled_pages,
  ROUND(COUNTIF(c.path IS NOT NULL) / COUNT(s.url) * 100, 1) AS coverage_pct
FROM `project.dataset.sitemap_urls` s
LEFT JOIN crawled c ON s.url = c.path;

このクエリをボット別に回すと、「Googlebotはカバレッジ95%だがOAI-SearchBotは40%」のようなエンジン間のクロール格差が数字になります。逆方向のLEFT JOIN（クロール済みだがsitemapにないURL）を取れば、404浪費や意図しないパラメータURLへのクロールも洗い出せます。

最後に、施策効果の実測です。llms.txt設置やsitemap更新の前後でクロール指標を比較します。

-- 施策日（例: 2026-06-15）前後30日のボット別比較
SELECT
  bot,
  COUNTIF(DATE(timestamp) <  '2026-06-15') AS before_requests,
  COUNTIF(DATE(timestamp) >= '2026-06-15') AS after_requests,
  COUNT(DISTINCT IF(DATE(timestamp) >= '2026-06-15', path, NULL)) AS after_unique_urls
FROM bot_requests  -- 前掲のボット判定済みビュー
GROUP BY bot;

単純な前後比較はノイズを含むため、確度を上げたい場合は効果検証・因果推定の記事で扱った差分の差分（DiD）等の設計を適用してください。ここでのポイントは、入口指標（クロール）は出口指標（引用）より施策への反応が速く、ノイズも小さいということです。robots.txt/sitemapの施策が効いたかどうかは、引用を待たずクロールログで先に検証できます。

「施策→クロール→引用」——因果チェーンを1本につなぐ

入口の計測ができると、AEOの診断が一気に立体的になります。引用されないページの原因を、次の分岐で切り分けられるようになるからです。

観測結果診断打ち手
クロールされていない入口の問題。コンテンツを磨いても無駄robots.txt・sitemap・内部リンク・サーバー応答（403/429/CDN設定）の点検
クロールされているが引用されない中身の問題。読まれた上で選ばれていないパッセージ最適化・構造化・権威性強化（既存AEO施策の出番）
ユーザー起点フェッチが来ている回答材料として参照されている。引用の一歩手前または引用済み該当ページを起点にトピッククラスターを拡張
クロール激減（それまで定常的だった）ブロック誤設定・sitemap破損・サイト移転処理漏れ等の事故の疑いアラート発報→変更履歴の確認

特に3行目が重要です。ChatGPT-UserやPerplexity-Userのアクセスログは、「AIが回答を作るために今このページを読んだ」というリアルタイムの需要データです。どのページに、どんな時間帯に、どのくらいの頻度で来ているか——これはシェア・オブ・モデル計測（出口）と突き合わせることで、「参照されたのに引用に至らなかったページ」というAEO改善の最優先ターゲットを特定できます。

運用設計——週次15分のレビューとアラート

計測は続けてこそ意味があります。最小の運用としては次の形を推奨します。

  • 週次（15分）：ボット別クロール頻度の推移、404率、ユーザー起点フェッチのTOPページを確認。前週比で大きな変動があれば深掘り。
  • 月次：カバレッジ算出（sitemap照合）、クロール予算配分（Patterns）のレビュー、引用計測データとの突合。
  • アラート：「主要ボットのクロールが7日間ゼロ」「404率が30%超」の2条件だけでも自動監視を設定（BigQuery scheduled query＋通知、またはCloudflareのデータをAPIで定期取得）。

チェックリストとしてまとめます。

段階項目手段
準備ボット3タイプ（学習/検索/ユーザー起点）の区別を集計設計に反映UA判定リスト（長い名前から判定）
準備UA偽装対策としてIP検証の手段を確保公開IPレンジJSON／逆引きDNS
計測クロール頻度・カバレッジ・404率・予算配分の4指標を集計生ログ／Cloudflare／BigQuery
計測ユーザー起点フェッチのページ別ログを分離して保存ログ解析／AI Crawl Control
分析sitemap照合でエンジン別カバレッジ格差を算出BigQuery LEFT JOIN
分析施策前後のクロール変化を比較（可能ならDiD設計）BigQuery
運用週次レビュー＋クロール停止/404急増アラートscheduled query＋通知
接続入口データ（クロール）と出口データ(引用計測)の突合既存のシェア・オブ・モデル計測と統合

よくある質問（Q&A）

Q1. Google Search Consoleのクロール統計ではだめですか？

Search Consoleで見えるのはGooglebot系のみです。GPTBot・ClaudeBot・PerplexityBotなどOpenAI・Anthropic・Perplexity各社のクローラーは一切表示されません。AEOの入口計測には、サーバーログまたはCloudflareのようなCDNレイヤーの計測が必須です。

Q2. AIクローラーがまったく来ていません。何を疑うべきですか？

順番に、(1) robots.txtでの明示的・包括的なDisallow、(2) CDN/WAFのボット対策によるブロック（既定でAIボットを止める設定のCDNもあります）、(3) 403/429を返している応答設定、(4) サイトの被リンク・言及不足（そもそも発見されていない）を確認してください。(1)〜(3)はログとCDN設定で即日切り分けられます。

Q3. 学習用クローラー（GPTBot等）はブロックすべきですか？

AEO観点では「検索インデックス用とユーザー起点は許可、学習用は方針次第」が基本形です。OpenAIは各ボットを独立に制御できると明言しており、GPTBotを拒否しつつOAI-SearchBotを許可する（＝学習は拒否、ChatGPT検索には出る）設定が可能です。コンテンツ保護と引用獲得はトレードオフではなく、ボット別制御で両立できます。

Q4. UAだけで判定して大丈夫ですか？偽装ボットが心配です。

傾向分析（頻度の推移・カバレッジ）はUAベースで実用上問題ありません。ただしブロック判断・課金判断・厳密なレポートでは、公開IPレンジJSONとの照合や検証済みボット判定（Cloudflare等）を併用してください。偽装が疑われるアクセスは「AIクローラー統計」から除外しないと数字が歪みます。

Q5. クロールが増えれば引用も増えますか？

クロールは引用の必要条件であって十分条件ではありません。クロールされていないページは引用されませんが、クロールされたからといって引用されるとは限りません。だからこそ本記事の入口計測と、既存記事で扱った出口計測（シェア・オブ・モデル・引用劣化監視）を突き合わせ、「どの段階で落ちているか」を診断することに価値があります。

まとめ——ログは「AIとの関係」を映す唯一の一次データ

要点は3つです。

1. 引用の手前に「読まれているか」がある。AEOの因果チェーンは「施策→クロール→取り込み→引用」であり、入口のクロールはサーバーログでしか測れません。出口の引用計測だけでは、施策が効かない原因が入口なのか中身なのか永遠に切り分けられません。

2. 3段構えで始める。今日ログにgrepを打つ（コストゼロ）→Cloudflare AI Crawl Controlで常時可視化→BigQueryでカバレッジと施策効果を定量化。どの段階からでも、ボット3タイプ（学習・検索・ユーザー起点）の区別だけは最初から守ってください。

3. ユーザー起点フェッチは宝の山。ChatGPT-UserやPerplexity-Userのアクセスは「AIが回答材料として今読んだ」需要データです。ここと引用計測の突合が、次に磨くべきページを教えてくれます。

robots.txtやllms.txtを整備した方は、その設計が実際にクローラーの挙動を変えたか、ぜひ今週のログで確かめてみてください。「施策→クロール→引用」が1本の数字でつながったとき、AEOは推測の施策から計測可能な運用に変わります。

参考リンク

免責事項：本記事は2026年7月時点の公開情報に基づく一般的な情報提供です。各AIクローラーのユーザーエージェント文字列・IP範囲・robots.txtの解釈、およびCloudflare等の製品仕様は変更されることがあります。実装の際は必ず各社の最新公式ドキュメントをご確認ください。ログの取り扱いにあたっては、IPアドレス等の個人関連情報に関する自社のプライバシーポリシーおよび関連法令に従ってください。

コメント

タイトルとURLをコピーしました