サーバーログでAIクローラーを解析｜なりすまし検証2段階【図解】

「うちのサイトに、AIのクローラーは来ているんでしょうか」。そう聞かれて、GA4を開いてみた。それらしい数字は、どこにも見当たらない。

ここで「来ていない」と結論を出してしまうと、実はかなり大きく外します。AIクローラーの多くは、GA4に記録が残らない仕組みで動いているからです。訪問の痕跡は、別の場所に残っています。サーバーログです。

この記事は、AIクローラーの訪問を自分の目で確かめたい方に向けて書きました。専門用語は出てきたその場で言い換えます。ログから抜き出すコマンド、名乗りが本物かを確かめる検証、そして多くのサイトがつまずく落とし穴まで、順番に置いていきます。

この記事では、あるマーケティング部の会話をはさみながら進めます。若葉さんはWeb担当で仕組みから知りたい立場、高梨課長は運用の手間と担当者を気にする立場、鈴木さんはAIO/SEOの専門家で答える役です。ご自身に近い立場の質問から読んでいただいて構いません。

01AI検索対策なのに、なぜサーバーログの解析からAIクローラーを見るんですか？

若葉さん

若葉さんの発言

GA4を見ても、AIのクローラーらしきものが見当たらないんです。まだ来ていない、ということでしょうか。

鈴木さん

鈴木さんの発言

いえ、来ていても映らないということが起こります。GA4は、ページの中で動く小さなプログラムが起動して、はじめて記録が残る仕組みなんですよ。

若葉さん

若葉さんの発言

そのプログラムが動かないと、来たこと自体が残らない…？

鈴木さん

鈴木さんの発言

はい。そして多くのAIクローラーは、そのプログラムを動かしません。だから別の場所を見にいきます。

サイトへの訪問を記録する場所は、1つではありません。GA4のようなJavaScript（ページの中で動く小さなプログラム）を前提にした計測と、サーバーがリクエストを受けた時点で自動的に書く記録では、そもそも残る条件が違います。

たとえるなら、建物の入口の記録と、館内で配ったアンケートの違いです。アンケートに答えた人しか名簿に残らないなら、答えずに通った人は「来ていない」ことになってしまいます。

02そもそもサーバーログ解析とは、AI検索最適化では何を見る作業ですか？

サーバーログ解析とは、サーバーが記録したアクセス記録からAIクローラーの訪問状況を抽出・検証する手法です。

サーバーログには、HTTPリクエスト（ブラウザやプログラムがページを取りに来るときのやり取り）の生データが並びます。記録されるのは、リクエスト元のIPアドレス、User-Agent（名乗り）、リクエストされたURL、タイムスタンプ、レスポンスコードなどです。

一方で、手間はかかります。Apache・Nginxなど標準的なWebサーバーのログは、テキスト形式で1行1リクエストずつ記録される仕様です。AIクローラーの訪問だけを取り出すには、User-Agentでの絞り込みが要ります。

03AIクローラーが来ているのに、AI検索の計測ツールに出てこないのはなぜですか？

GA4は基本的に、JavaScriptのタグが起動することを前提にした計測ツールです。GPTBot・ClaudeBot・PerplexityBotなど、AI企業が運用する多くのクローラーは、そのJavaScriptを実行しません。

そのため、AIクローラーがページにアクセスしても、GA4のタグ自体が起動しません。起動しなければ、訪問の記録も残らない。ここまでが一続きです。

Search Consoleの生成AIに関するレポートも、事情は似ています。こちらはGoogle自身が把握しているインプレッションのデータに限られます。GPTBotやClaudeBotなど、他社クローラーの直接的な訪問状況までは反映されません。

04サーバーログからAIクローラーを抜き出す解析は、AI検索対策としてどう進めるんですか？

高梨課長

高梨課長の発言

専用のツールを買わないと始められない話でしょうか。予算をすぐには取れません。

鈴木さん

鈴木さんの発言

いえ、まずはコマンドだけで始められます。 手を動かして中身を見てから、続け方を決めるほうが失敗が少ないと思います。

基本の流れは、次の4ステップです。

1. ログファイルを取得する — Webサーバー（Apache・Nginx）、またはCDN（Cloudflare等）のアクセスログをエクスポートします
2. User-Agentで絞り込む — GPTBot・ClaudeBot・PerplexityBotなど、既知のAIクローラー名を含む行を抜き出します
3. リクエスト先URL・頻度を集計する — どのページに、どれくらいの頻度で来ているかを数えます
4. IPアドレスで真贋を検証する — 抜き出した行のIPアドレスが、各社の公開IPリストに含まれるかを確かめます

このうち手順2と手順3は、コマンド1行ずつで実行できます。Apache・Nginxの標準的なアクセスログ（access.log）を対象にした例が、次のとおりです。

# 手順2: 主要AIクローラーの行だけを抜き出す
grep -E 'GPTBot|OAI-SearchBot|ClaudeBot|PerplexityBot|Perplexity-User' access.log > ai-crawlers.log

# 手順3: クローラー別のアクセス件数を数える
grep -oE 'GPTBot|OAI-SearchBot|ClaudeBot|PerplexityBot|Perplexity-User' ai-crawlers.log | sort | uniq -c | sort -rn

# 手順3: どのURLに何回来ているかを上位20件まで集計する（ログ形式が変わる場合は列番号を調整）
awk '{print $7}' ai-crawlers.log | sort | uniq -c | sort -rn | head -20

awkの$7は、Apacheの標準的なcombinedログ形式でリクエストURLにあたる列です。ログ形式を独自に変更している場合は、1行を目で見てから列番号を合わせてください。

05主要なAIクローラーの名前は、AI検索最適化としてどこまで押さえればいいですか？

絞り込みに使う名前と、真贋の確認に使うIPアドレスの公開先は、次のとおりです。

OpenAIのように、1社で複数のクローラーを公開しているケースがあります。それぞれの役割の違いは、別記事で比べています。

大事なのは、この表を一度写して終わりにしないことです。これらのJSONエンドポイントは各社が随時更新しています。定期的に最新のIP範囲を取得し直す運用が要ります。

06AIクローラーを名乗るだけのボットを、AI対策としてどう見分けるんですか？

若葉さん

若葉さんの発言

ここまでで、GPTBotが来ていることは分かりました。これって、本物ですよね？

鈴木さん

鈴木さんの発言

そこが、この記事のいちばん大事なところです。User-Agentは、誰でも自由に名乗れます。 名乗りだけでは、本物かどうかは判定できないんですよ。

若葉さん

若葉さんの発言

では、どうやって確かめるんでしょう。

鈴木さん

鈴木さんの発言

名前ではなく、どこから来たかを見ます。IPアドレスのほうです。

User-Agentは自己申告の文字列にすぎません。悪意のあるボットが、人気のAIクローラーを名乗ってアクセスすることもあり得ます。偽装は技術的に容易です。

Googleは自社のクローラーについて、逆引き・正引きDNSによる検証手順を公式に案内しています。同じ考え方は、他社のAIクローラーの検証にも応用できます。手順は2段階です。

1. 逆引きDNS — ログに記録されたIPアドレスに対してhostコマンドで逆引きを行い、ドメイン名を取得します
2. 正引きDNS — 取得したドメイン名をhostコマンドで正引きし、得られたIPアドレスが元のログのIPと一致するかを確かめます

実際に打つコマンドは2行です。1行目で得たドメイン名を、2行目にそのまま渡します（コマンド例はGoogle公式ドキュメントの記載に沿ったものです）。

host 66.249.66.1              # 逆引き: IPアドレス → ドメイン名
host crawl-66-249-66-1.googlebot.com   # 正引き: ドメイン名 → IPアドレス

2行目の結果が1行目に入力したIPアドレスと一致すれば本物、一致しなければなりすましと判定します。Googlebotの場合は、逆引きの結果がgooglebot.com・google.com・googleusercontent.comのいずれかであることが条件です。GoogleもIP範囲のリストを公開しており、DNS検証の代わりにIPリストとの照合で判定する方法を併記しています。

07ClaudeBotやPerplexityBotのようなAIクローラーは、AI検索対策でどう検証しますか？

事業者によって、案内されている確かめ方に違いがあります。DNSをたどる方法のほかに、公開されているIPリストと照合するだけの、より簡便な方法もあります。

ClaudeBotの場合、Anthropicは公開IPリストとの照合という方法を案内しています。同社は、クローラーの送信元IPアドレスがこのリストに含まれていれば、そのクローラーはAnthropicから来ていることを示す、と説明しています。

Perplexityも同様にIPリストを公開したうえで、公式JSONエンドポイントの最新のIP範囲を常に使い、これを信頼できる情報源とすること、と案内しています。

自動化する場合は、これらのIPリストを定期的に取得し、ログ解析のルールへ反映させる運用が実務的です。

08CDNの下では、AI検索対策のサーバーログ解析はどこでつまずくんですか？

ここで多くのサイトがつまずきます。CDNやリバースプロキシ（サイトの前に立って通信を中継する仕組み）を経由している場合、オリジンサーバーのログに記録されるのは、クローラーのIPアドレスではないことがあるためです。

記録されるのは、CDN側のIPアドレスです。この状態で公開IPリストと照合すると、どのクローラーも「なりすまし」と判定されてしまいます。検証の手順は正しいのに、答えだけが全部ひっくり返る。 いちばん気づきにくい形の失敗です。

対処は2つあります。

• CDN側が提供するログを一次データとして使う — ログ配信の機能やダッシュボードから、CDNが受け取った時点の記録を取ります
• 転送元IPを伝えるヘッダーを、ログ形式に含める — オリジン側でも、本来のリクエスト元IPを記録できるようにします

09ログが増えたとき、AIクローラーの解析はAI検索最適化としてどう続けますか？

高梨課長

高梨課長の発言

一度やってみるのは分かりました。これを続けるとなると、どこかで手作業では回らなくなりますよね。

鈴木さん

鈴木さんの発言

はい。判断の軸はログの量です。量と体制で、向いているやり方が変わります。

一度手を動かしたうえで、続け方を決めます。目安は次のとおりです。

ツールを検討するときは、次の3点を確かめてください。①User-Agentのフィルタを自分で追加できるか、②IPアドレスの検証を自動化できるか、③CDN経由のログを取り込めるか。

とくに①が効きます。新しいAIクローラーは継続的に登場するため、運用担当者が自力で名前を足せない製品は、半年後には使えなくなる可能性があります。

10AIクローラーの記録を残す運用は、AI対策として何を決めておくんですか？

運用として回すために、決めておくことがあります。

• サーバーまたはCDNから、アクセスログを定期的に取得できる状態にしている
• ログに記録されているIPが、CDNのものかリクエスト元のものかを確認した
• 主要なAIクローラーのUser-Agent文字列で、ログを絞り込める
• 各社が公開するIPアドレスのリストを、定期的に取得し直す運用がある
• 逆引き・正引きDNSでの検証手順を、最低1回は実施したことがある
• User-Agentだけでなく、IPアドレスでの検証も組み合わせている
• ログ解析の結果を、GA4・Search Consoleのデータと区別して記録している

最後の項目が、意外と抜けます。ログで分かるのは「クローラーが来た」ことであって、「人が来た」ことではありません。

11LLMOの数字として、AIクローラーのサーバーログ解析はどこまで言えますか？

高梨課長

高梨課長の発言

数字が出たら、社内には何と報告するのがよいでしょうか。

鈴木さん

鈴木さんの発言

「訪問があった」までです。 そこから先の成果につながっているかどうかは、この記録だけでは分かりません。そこは正直に線を引いておくほうが、後で困りません。

同じ形の誤りが、繰り返し起きています。先に挙げておきます。

User-Agentだけで本物と判定してしまう。 偽装は技術的に容易です。重要な判断をするときは、IPアドレスでの検証もあわせて行ってください。

IPアドレスのリストを、一度取得したきり更新しない。 各社のIP範囲は随時更新されるため、古いリストのままでは、正当なクローラーを誤って除外してしまう可能性があります。

サーバーログの存在自体を忘れてしまう。 GA4やSearch Consoleの数字だけを見て「AI経由のアクセスがない」と判断してしまう例があります。JavaScriptを実行しないクローラーは、そもそもGA4に記録されない構造です。

報告できる範囲にも、線を引いておきます。サーバーログで分かるのは、AIクローラーがアクセスしたという事実です。実際の成果につながっているかどうかは、別記事で扱った指標とあわせて確かめる必要があります。

12よくある質問

13まとめ｜今日やる3つのこと

AIクローラーの訪問は、GA4ではなくサーバーログに残ります。専用のツールを買う前に、コマンドだけで着手できます。ただしUser-Agentでの抽出は入口にすぎず、IPアドレスでの検証を省略すると、なりすましを含んだ数字で意思決定することになります。

着手の順序としては、CDN配下かどうかの確認を最初に置いてください。ここを飛ばすと、すべて「なりすまし」と判定される結果になります。この1点さえ先に潰しておけば、残りの手順はこの記事のコマンドをそのまま流用できます。