AI検索対策の議論は、「何を作るか」に集中しがちです。構造化データを整える、FAQを追加する、AIが引用しやすい文章に書き直す。どれも必要な作業です。

ただ、その前に確認しておきたいことがあります。いま自社サイトの何が、実際にAIに読まれているのか、です。

サイトマップを見れば「読んでほしいページ」の一覧はわかります。しかし「実際に読まれたページ」の一覧は、そこには載っていません。この2つのリストは一致せず、その差分にこそ、対処すべき問題が潜んでいると考えます。

本記事では、ギャプライズが国内提供するLimyが自社サイトで公開した検証をもとに、サイトマップとサーバーログを突き合わせる「差分監査」の手法を整理します。専用ツールがなくても実行できる手順と、日本のサイトでつまずきやすいポイントまでを扱います。

※ AI検索対策の用語整理や施策の全体像については、別記事「AI検索対策、結局どこから手をつける？ GEO/AIOを「3つの層」で整理する地図」で解説しています。本記事はその第1層（技術的なアクセシビリティ）を、自社サイトで実際に点検するための実務編としてお読みください。

なぜサイトマップとサーバーログを突き合わせる必要があるのか？

サイトマップは「クローラーに見つけてほしいページ」を自社が宣言したリストであり、実際に読まれた保証はありません。一方、AIボットがどのURLへアクセスしたかは、CDNやWebサーバーのログにしか記録されていません。一般的なアクセス解析ツールではAIボットを捕捉できないため、この2つを突き合わせない限り「AIに読まれている範囲」は把握できないのです。

サイトマップは「読んでほしいページ」の宣言にすぎない

sitemap.xmlの役割は、クローラーによるURL発見を補助することです。掲載したからといってクロールが保証されるわけではありません。

逆方向も成立します。サイトマップに載っていないURLがクロールされないわけでもありません。外部からのリンク、過去のクロール履歴、CMSが自動生成する内部リンクなど、ボットがURLを見つける経路は複数あります。

つまりサイトマップは、実際に読まれる範囲の上限でも下限でもありません。あくまで自社側の意図の表明です。

なぜアクセス解析ツールではAIボットが見えないのか

GA4などのアクセス解析ツールは、ページに埋め込んだJavaScriptが実行されることで計測が成立します。ところが主要なAIクローラーはJavaScriptを実行しません。計測タグが発火しないため、AIボットの訪問はレポートに一切現れないのです。

2026年6月時点の各種検証では、GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot、Claude-SearchBot、PerplexityBot、Meta-ExternalAgent、Bytespiderのいずれもレンダリングを行わないことが確認されています。例外はGoogleのGeminiで、Googlebotと同じレンダリング基盤を利用しています。

この挙動は2024年12月に公開されたVercelとMERJの共同分析でも示されていました。5億件を超えるGPTBotのリクエストを解析してJavaScriptの実行が確認されず、ClaudeBotは約23.8%のリクエストでJavaScriptファイル自体はダウンロードしながら、実行はしていませんでした。

結果として、二重の盲点が生まれます。JavaScriptで描画されるページはGoogleでは評価されうる一方、AIクローラーには中身が空に見えます。そして同じJavaScriptに依存する計測も発火しないため、「読まれていない」という事実そのものが観測できません。

AIボットのクロールと、AI経由の訪問は別物

ここで混同されやすい点を整理しておきます。「GA4ではChatGPT経由の流入が見えている」という指摘はよく出ますが、それはこの話とは別のものを見ています。

AIに関連するアクセスは、性質の異なる3つに分かれます。

 ②はブラウザを操作している人間の訪問です。JavaScriptが実行されるため、GA4に参照元として計上されます。

2026年5月13日には、GA4のデフォルトチャネルグループに「AI Assistant」チャネルが追加されました。設定不要で、ChatGPTやGemini、Claudeといった対象サービスからの流入が自動的に分類され、mediumにはai-assistantが入ります。

ただし、このチャネルができても②を完全に把握できるわけではありません。判定がリファラーヘッダーに依存しているためです。リファラーを渡すかどうかはブラウザや経路によって異なり、Perplexity Cometは正しく渡す一方、ChatGPTのモバイルアプリやAtlasのアプリ内表示からリンクを開いた場合は落ちてしまい、Directや(not set)に沈みます。Google AI OverviewsやAI Modeからの流入も対象外で、引き続きOrganic Searchに分類されます。

つまりAI経由の流入は、GA4上では実際より小さく見えているのが通常です。

重要なのは、②が見えていることは①が見えていることを意味しないという点です。前者は人間の訪問、後者は機械による読み取りであり、記録される場所がそもそも違います。GA4でChatGPTからの流入が伸びていても、AIボットが自社のどのページを読んでいるかは、そこには一切現れません。

③はさらに逆方向の問題を持ち込みます。エージェント型ブラウザはChromiumベースの実ブラウザなので、JavaScriptが実行され、人間の訪問としてGA4に記録されます。ChatGPT AtlasはGA4のブラウザ項目上ではChrome 141として現れ、通常のChromeと区別できません。エージェントモードで動作している間はユーザーの環境と同じUser-Agentを送るため、サーバー側でも識別が困難です。

なお、③のセッションは「AI Assistant」チャネルには入りません。通常のブラウザからの人間の訪問として、既存のチャネルに計上されます。

つまり①では機械の行動がGA4から抜け落ち、③では機械の行動がGA4の人間の数字に混ざります。向きが逆の2つの問題であり、まとめて論じると対策を誤ります。AI Assistantチャネルの追加は②の可視化を進めたものであり、①と③のいずれも解決していません。本記事が扱うのは①です。

ボットに何を返しているかは、配信レイヤーが決めている

AIボットが受け取るのは、ブラウザが描画を終えた後の画面ではありません。サーバーやCDNが最初に返したHTMLそのものです。

したがって「本文がHTMLに含まれているか」は、コンテンツの問題ではなく配信設計の問題になります。SSR（サーバーサイドレンダリング）、静的生成、プリレンダリングといった選択が、そのままAIに読まれる範囲を決めます。

この観点は、表示速度改善の作業と大きく重なります。ファーストビューを速く描画するためにHTMLへ本文を出力する設計は、AIクローラーに読ませるための設計とほぼ同じ作業です。速度改善の投資が、AI検索対応の土台をつくっているケースは少なくありません。

自社の状況は、ブラウザの「ページのソースを表示」で確認できます。本文の一文を検索して見つかれば、AIクローラーも読めています。開発者ツールのElementsパネルはJavaScript実行後のDOMを表示するため、この確認には使えません。

差分は3つの状態に分かれる──どこを見るべきか？

サイトマップとログを突き合わせると、各URLは「両方にある」「サイトマップのみ」「ログのみ」の3つに分かれます。健全なのは1つ目です。2つ目は見つけられていないページ、3つ目は意図せず読まれているページで、実務上もっとも見落とされているのは3つ目です。

①両方にある──健全なコア

公開する意図があり、実際に読まれているページです。ここに含まれていることは目的ではなく前提であり、コンテンツの改善投資はこの領域に向けるのが基本になります。

②サイトマップのみ──「見つけられていない」リスト

公開したのに、ボットが到達していないページです。

典型的な原因は、ナビゲーションがJavaScriptで生成されていて、リンクが最初のHTMLに存在しないことです。Googleには「リンクでつながった1つのサイト」に見えていても、AIクローラーには孤立したページの集まりに見えることがあります。

AI検索では、訪問されていないページは引用も言及もされません。内容の良さは関係がなく、単に存在しないものとして扱われます。

多くのチームはこの点検を「当然通っているはず」と考えて実施していません。しかし実際には、公開してサイトマップに追加したあと、数か月経ってもボットが来ていないことに誰も気づかない、という形で静かに発生します。

③ログのみ──「意図せず読まれている」リスト

サイトマップに載せていないのに、ボットが読んでいるページです。Limyの検証では、次のような類型に分かれました。

• • ヘルプセンターやドキュメント領域。実務的な文書もあるが、テンプレートの初期状態が残り、自社と無関係な説明文がそのまま読まれているものも含まれていた
  • 公開前・制作中のページ。完成していない状態でボットに読まれている
  • 旧トップページ、中身のないイベントページ、採用ページなど、更新が止まったまま残っているページ
  • robots.txtやsitemap.xmlといったシステムファイル。これは想定どおりの挙動

サイトマップは自社が言いたいことの一覧、ログはAIが実際に読んでいるものの一覧です。この差分がそのままリスクになります。

なぜ③がAI検索では従来のSEOより重いのか

従来の検索エンジンは、品質の低いページをインデックスしても順位を下げることで処理していました。ユーザーの目に触れなければ実害は限定的でした。

生成AIは順位をつけません。読んだものを材料に、1つの回答を書きます。

この違いが効いてきます。古いヘルプページや作りかけの下書きは、検索結果の下位に埋もれるのではなく、AIが自社を説明する文章の材料そのものに混ざります。公開する意図がなかったページが、ブランドの説明に影響を与えうるということです。

公開されている検証結果はどう読めばよいのか？

Limyは2026年7月、自社サイトで差分監査を実施した結果を公開しました。合計924件のURLのうち、両方に存在したのが110件、ログにのみ存在したのが814件、サイトマップにのみ存在したものは0件でした。ただしこれは1サイトの結果であり、比率をそのまま自社の目標値や業界水準として扱うべきではありません。

Limyの検証（2026年7月）の内容

手法は単純です。サイトマップに含まれる全URLと、CDNログ上でボットがアクセスした全URLを並べ、各URLを3分類に振り分けています。

あわせて同社は、外部データとしてVercelとMERJの分析（2024年12月）を参照しています。AIクローラーのリクエストのうち34%超が404で終わっており、Googlebotの約8%と比べて大きく高い、という内容です。古いサイトマップの残骸、リンク切れ、URL変更後も古いURLへアクセスを続けるボットの挙動が原因とされています。

この比率を自社の目標値にしてはいけない理由

814件という数字は、そのままベンチマークにはできません。理由は3つあります。

• • robots.txtやsitemap.xmlが含まれている。これらはそもそも「ページ」ではない
  • ドキュメント領域のように、別サブシステムとして運用されている領域が混在している
  • 対象サイトの公開ページが110件規模で、母数が小さい

Limy自身も、重要なのは自社の814件という数字ではなく比較という手法そのものだと述べています。つまり輸入すべきは3分類の手法であって、比率ではありません。自社サイトで実行して初めて意味のある数字が出ます。

「クロールされているのに送客がない」は本当か？──数値の読み方

AIクローラーが多くのページを読む一方で送客はほとんど返さない、という傾向は複数のデータで示されています。ただし具体的な数値は出典によって桁が変わります。だからこそ、公開されている平均値ではなく自社のログを見る必要があります。

クロール対送客比は、出典によって桁が変わる

1件の送客を得るまでに何ページがクロールされるかを示す「クロール対送客比」は、AIクローラーの経済性を語るときによく使われます。Anthropic系クローラーの数値を出典別に並べると、次のようになります。

データ参照元：
https://www.medianama.com/
https://www.alphamatch.ai/
https://technologychecker.io/

いずれもCloudflare Radarを出典としながら、集計期間と算出方法の違いで桁が変わっています。参考までに、従来型の検索エンジンはGoogleが約5対1、DuckDuckGoが約1.5対1という水準が報告されています。

ここから読み取るべきは「学習目的のクローラーは送客をほとんど返さない」という構造であり、特定の数値を自社の前提に据えることはできません。この幅の大きさ自体が、自社ログを見る必要性を裏づけています。

「ボットが35%」と「57.5%」はなぜ違うのか

もう1つ、社内共有の場で混乱しやすい数値があります。

2026年6月、CloudflareのCEOが「自動化されたリクエストが57.5%、人間が42.5%」というRadarのデータを公表しました。機械が人間を上回った初めての記録として広く報じられました。

一方、同じCloudflare Radarを参照した別の集計では、2026年6月時点でボットは全トラフィックの35.2%とされています。

差の原因は集計基準です。57.5%はHTMLリクエストを対象とし、動画配信・メール・ゲームを除いた数値です。35.2%は「検証済み＋自動と推定される」トラフィックの全体シェアです。どちらも誤りではありません。

「ボットが半分を超えた」という見出しだけが流通していますが、どの分母の話かで数字は変わります。社内で共有するときは、必ず基準を添えてください。

自社で差分監査を行う手順は？

手順は5つです。①サイトマップ側のURL一覧を取得する ②ログからAIボットのアクセスを抽出する ③両方のリストを正規化する ④3分類に振り分ける ⑤「ログのみ」の各ページを残す・直す・閉じるで判定する。専用ツールがなくても、表計算ソフトで実行できます。

Step1 サイトマップ側のURL一覧を取得する

sitemap.xmlからURLを抽出します。サイトマップインデックスを使っている場合は、配下のすべてのサイトマップを対象にしてください。

同時に、サイトマップ自体が最新かを確認します。生成が止まっていれば、以降の比較はすべて意味を失います。

Step2 ログからAIボットのアクセスを抽出する

対象期間を決めます。最低7日、可能であれば30日を推奨します。期間が短いと、巡回頻度の低いページが「ログのみ」から漏れてしまいます。

抽出はUser-Agentを起点に行いますが、User-Agent文字列は誰でも名乗れるため、それだけの判定では不正確です。主要な事業者は検証用のIPレンジや逆引きの手順を公開しており、検証を通ったものだけを本物として扱ってください。

もう1点、ボットの役割を分けて集計することが重要です。学習目的のクローラー、検索インデックス用のクローラー、ユーザーの指示で即時に取得するエージェントは、目的がまったく違います。GPTBotとOAI-SearchBot、ClaudeBotとClaude-SearchBotを合算してしまうと、あとの判断を誤ります。

Step3 両方のリストを正規化する

突き合わせの精度は、ここでほぼ決まります。

• • ドメイン部分を落として、パスに揃える
  • 末尾スラッシュの有無を統一する
  • パーセントエンコードをデコードする（日本語URLを使っている場合は特に重要）
  • クエリパラメータの扱いを決める（原則は除去し、内容が変わるパラメータのみ残す）
  • システムファイルと静的アセットを除外する（robots.txt、sitemap.xml、画像、CSS、JavaScript、フィードなど）

最後の除外を省くと、「ログのみ」が実態より大きく膨らみます。Limyの814件にシステムファイルが含まれていたのも同じ理由です。

Step4 3分類に振り分ける

表計算ソフトのVLOOKUPやCOUNTIFで突き合わせ、両方にある・サイトマップのみ・ログのみの列を作ります。

件数を数えるだけで終わらせず、ディレクトリ単位で集計してください。「/help/ 配下がまとめてログのみ」といった形で並ぶと、原因の見当がつきます。

Step5 「残す・直す・閉じる」で判定する

分類したあと、1件ずつではなくディレクトリ単位で方針を決めます。判断の目安は次のとおりです。

 「閉じる」を選ぶときは副作用に注意してください。学習用クローラーだけを止めるのであれば、検索用クローラー経由の引用は残ります。しかし検索用まで一律に止めると、AIの回答に登場する経路そのものが消えます。ブロックはページ単位・ボット単位で設計する必要があります。

CDNログが手に入らない場合はどうすればよいのか？

日本のサイトでは、CDN未導入、共有サーバーでアクセスログが取得できない、ログの保持期間が数日しかないといった理由で、この監査に入れないケースが少なくありません。その場合は取得できる範囲から段階的に始めます。もっとも重要なのは、まず記録を残し始めることです。

手元にあるログの候補

まず、すでに取得できているログを確認します。

• • Webサーバー（Apache、nginx）のアクセスログ。CDNがなくても、オリジンサーバーにはリクエストが届いています。ただしCDNを使っている場合、キャッシュから返された応答はオリジンに来ないため、オリジンログだけでは取りこぼしが出ます
  • CDN側のログ出力機能。提供条件はプランによって異なります。たとえばCloudflareでHTTPリクエストの生ログを外部に出力する機能（Logpush）は、Enterpriseプラン向けです
  • リバースプロキシや高速化レイヤーを前段に置いている場合、そこにリクエストの記録が残っていることがあります

Cloudflareを利用している場合は、もう1つ現実的な選択肢があります。AI Crawl Control（旧AI Audit）は全プランで設定不要で利用でき、Metricsタブから日付・クローラー・事業者・ステータスコード・ホスト名・パス別の内訳を確認できます。

つまり生ログを出力できないプランでも、「どのパスにどのAIボットが来たか」は把握できます。ただし無料プランでは検出がUser-Agent文字列ベースになり、分析できる期間は直近24時間までという制約があります。24時間ごとに書き出して蓄積すれば、差分監査の材料になります。

ログがまったくない場合の暫定策

ログに到達できない場合でも、点検できることは残っています。

• • Search Consoleのクロール統計を見る。対象はGooglebotであり、AIクローラーの記録ではありません。ただしHTMLの到達性や404の傾向を推測する材料にはなります
  • 主要ページを「ページのソースを表示」で開き、本文が最初のHTMLに含まれているかを確認する。②のサイトマップのみに該当するページを減らす作業に直結します
  • サイトマップに載っているURLを機械的にリクエストし、ステータスコードとタイトルを一覧化する。サイトマップ側の健全性だけであれば、ログなしで点検できます
  • robots.txtとサイトマップの整合を確認する。サイトマップに載せているのにrobots.txtで弾いている、という矛盾は実際に起こります

まず保持期間を設計する

差分監査は、過去のログがなければ実行できません。必要になってから遡って取得することはできないため、多くの企業にとって最初の作業は「保存を始めること」になります。

30日程度を保持できる状態をつくり、四半期ごとに突き合わせる。この運用に乗せてしまえば、以降は差分の推移で異常に気づけるようになります。

棚卸しの次に来る打ち手は何か？──「見る」と「読ませる」の順序

差分監査は「いま何が読まれているかを見る」施策です。その次に来るのが「読ませたいものを整える」施策で、この2つは対立するものではなく順序です。どちらから着手すべきかは、自社がどの段階でつまずいているかによって決まります。

見る側のアプローチ

ログ上のAIエージェントの行動を継続的に観測し、どのボットがどのコンテンツに到達し、何が推薦につながっているかを追う方向です。

ギャプライズが2026年3月から国内提供しているLimyは、この領域のプラットフォームです。AI検索対策のツールはプロンプトを模擬してブランドの表示状況を推定するものが多いのに対し、Limyはサイト上の実際のAIエージェントの行動をトラッキングします。

本記事で紹介した手作業の差分監査は、年に数回のスナップショットです。継続的な観測が必要になった段階で、ツール化を検討するという順序が自然です。

読ませる側のアプローチ

AIボットが読める形で情報を用意する方向です。具体的には次のような作業になります。

• • 本文を最初のHTMLに出力する（SSR、静的生成、プリレンダリング）
  • 構造化データを整える
  • 質問と回答の形で情報を整理し、機械可読な面を用意する

LightSite AIはこの方向のアプローチで、AIボットが読みやすいサーフェスを生成・提供します。同社が約500万件のAIボットリクエストを解析した実証研究については、別記事「GEO時代の”AI可視性”、構造化データで本当に変わるのか」で扱っています。

どちらから着手すべきかは、つまずいている層で決まる

差分監査の結果は、次に何をすべきかの指標になります。

ギャプライズではGEO領域でLimy、LightSite AI、AthenaHQと複数のツールを取り扱っています。特定のツールを前提に構成を決めるのではなく、どのデータを見たいのか、どのフェーズで詰まっているのかから逆算することを重視しています。差分監査は、その逆算の出発点として使えます。

まとめ

• • サイトマップは「読んでほしいページ」の一覧、サーバーログは「実際に読まれたページ」の一覧であり、両者は一致しない
  • 差分は3分類になる。見落とされやすいのは「ログのみ」＝意図せず読まれているページ
  • 生成AIは順位をつけず、読んだものから1つの回答を書く。そのため古いページや作りかけのページが、ブランドの説明そのものに混ざる
  • 主要なAIクローラーはJavaScriptを実行しないため、アクセス解析ツールではAIボットの訪問を捕捉できない
  • 公開データの平均値は出典によって桁が変わる。自社のログを見ることに代替はない
  • ログが取れない環境であれば、まず記録を残し始めることが最初の作業になる

よくある質問

Q：サイトマップとサーバーログの違いは何ですか？

サイトマップは、クローラーに見つけてほしいページを自社が宣言したリストです。サーバーログやCDNログは、ボットが実際にアクセスしたURLの記録です。前者は意図、後者は事実であり、両者は一致しません。

Q：なぜアクセス解析ツールではAIボットが見えないのですか？

アクセス解析ツールはJavaScriptの実行によって計測が成立しますが、GPTBotやClaudeBot、PerplexityBotといった主要なAIクローラーはJavaScriptを実行しないため、計測タグが発火しません。AIボットの訪問を確認するには、サーバーログやCDNログ、あるいはCDN事業者が提供するAIクローラー向けの分析機能が必要です。

Q：GA4でChatGPT経由の流入は見えていますが、それでもログを見る必要がありますか？

必要です。GA4に現れるのは、AIの回答内のリンクを人間がクリックした訪問であり、AIボットがサイトを読んだ記録ではありません。両者は記録される場所が異なります。2026年5月に追加された「AI Assistant」チャネルも、リファラーヘッダーを前提とした人間の流入の分類であり、AIボットのクロールは対象外です。またChatGPT Atlasのようなエージェント型ブラウザはGA4上で通常のChromeと区別できないため、GA4の数字だけでAIとの接触状況を把握することはできません。

Q：ログにあってサイトマップにないページは、何が問題なのですか？

公開する意図がなかったページがAIに読まれている状態です。古いヘルプページ、更新の止まった旧ページ、制作中のページなどが該当します。生成AIは順位をつけず、読んだものを材料に回答を書くため、これらのページがブランドの説明に混ざる可能性があります。

Q：CDNを使っていない場合でも差分監査はできますか？

できます。WebサーバーのアクセスログにもAIボットのリクエストは記録されています。ただしCDNを併用している場合は、キャッシュから返された応答がオリジンに届かないため取りこぼしが出ます。まずログの保持期間を確認し、30日程度を保存できる状態をつくることから始めてください。

Q：AIクローラーはブロックしたほうがよいのでしょうか？

一律のブロックは推奨できません。学習目的のクローラーと、AI検索の回答に引用されるための検索用クローラーは役割が異なります。検索用クローラーまで止めると、AIの回答に登場する経路そのものが失われます。ページ単位・ボット単位で判断してください。

Q：差分監査はどのくらいの頻度で実施すべきですか？

四半期ごとを目安にすると運用に乗りやすくなります。サイト構造の変更、URLの一括変更、CMSの移行を行った直後は、そのタイミングで追加実施することを推奨します。

施することを推奨します。