AIクローラーはGooglebotの10倍来ていた｜LLMO対策の前に、自社サイトの実態を測った結果を共有します

AI検索の対策を検討されている企業様も多い中で、現在どのような状態でなにを把握できるのかについてお悩みも多く感じます。そこで今回は、自社サイトのアクセスログを1日分、通しで解析してわかったことを共有します。

結論として、AI関連のクローラーによるページ取得は、Googlebotのおよそ10倍あり、そのうち2割ほどは学習用の巡回ではなく「誰かがAIに質問した結果、その場で読みに来た」記録でした。また、AIの回答経由で実際に人が訪問した形跡も確認できましたのであわせてご紹介しています。

このデータは、AI検索向けの個別施策を実施前のデータを取得したため、通常のSEOと制作を続けてきた結果だけでこの数値が出ていたことになります。

この記事は「何をすべきか」を語るものではありません。その前に「今どうなっているか」を測る話です。

※この記事の内容は2026年8月時点での情報が中心のため、今後仕様が変更になる可能性がございます。予めご了承ください。

GA4とGoogle Search Consoleだけでは足りない

AI検索での自社の状況を知ろうとしたとき、多くの方はまずGA4かSearch Consoleを開くと思います。ただ、この2つでは見えない範囲も多くありました。

GA4でAIの動きについて見えること、見えないこと

GA4に記録されるのは、AIの回答を読んだ人が実際にリンクをクリックして訪問した分です。参照元として chatgpt.com や perplexity.ai が残るため、AI経由の流入がどれくらいあるかは把握できます。

一方で記録されないのが、クローラー自身のアクセスです。AIが自社のページを読みに来ても、そこから人間の訪問が発生しなければ、GA4上は何も起きていないことになります。

この差は無視できません。今回の調査では、AIによるページ取得の回数に対して、そこから実際に発生した訪問はごく一部でした。GA4だけを見ていると、AIに読まれている実態の大半が視界に入らないことになります。

Search Consoleで見えること、見えないこと

2026年6月、Search Consoleに生成AI機能のパフォーマンスレポートが追加されました。AI OverviewsやAI Modeに自社へのリンクが表示された回数を、ページ単位で確認できます。公式データなので信頼性は高く、まず見るべき指標です。

ただし範囲は限定的です。

対象はGoogleのAI機能のみで、ChatGPT、Perplexity、Claudeといった他社サービスのデータは一切含まれません。またクエリとクリック数も、現時点では取得できません。「どんな質問で表示されたか」「そこから何人来たか」は分からない仕様です。

サーバーログにしかないもの

これらを補うのがサーバーのアクセスログです。

どのAIが、どのページを、どれくらいの頻度で取りに来ているか。ここにはすべて記録が残っています。Googleかどうかを問わず、実際に起きたことがそのまま書かれている唯一の場所です。

ログから何が分かるのか、そしてなぜ簡単ではないのか

ログを活用してAIの動きについて分かること

1.どのAIが来ているか

ChatGPT、Perplexity、Claude、Apple、Meta。いま主要なAIサービスは、それぞれ独自のクローラーを持っています。

重要なのは、これらが同じ目的で動いているわけではないという点です。学習データの収集を目的とするもの、検索インデックスを作るもの、そしてユーザーが質問した瞬間に該当ページを取りに来るもの。性質がまったく違うので、区別して読む必要があります。

このうち事業上の意味が最も大きいのは3つ目です。誰かがAIに何かを尋ね、その回答を作るために自社のページが選ばれた、という記録だからです。

2.意図せず遮断していないか

robots.txtの設定、セキュリティ製品のボット対策、サーバー側のクローラー制御機能。これらがAIクローラーを弾いているケースがあります。

厄介なのは、遮断していても何も起きないことです。エラーも警告も出ないまま、露出の機会だけが失われます。ログを見なければ気づけません。

3.中身が空のまま配信されていないか

ステータスコードは正常なのに、実際にはほとんど何も返していないページが存在することがあります。

原因はさまざまです。テンプレートの不具合、JavaScriptに依存した描画、プラグインの挙動。いずれの場合も、クローラーからは「アクセスできるが中身のないページ」に見えます。当然、回答の材料には使われません。

今回の調査でも、カテゴリ一覧のページが該当していました。ブラウザで開けば正常に見えるページでも、こうしたことは起こります。

4.巡回の偏り

重要なページに来ていない。逆に、事業上まったく価値のないページばかり繰り返し取られている。こうした構造的な問題も、URL別に集計すると浮かび上がります。

なぜ簡単ではないのか

ここまで読むと「ログを見ればいい」と思われるかもしれません。実際にはもう少し厄介です。

まず、サーバーによってログの記録方式が違います。同じ項目に見えて、記録している内容が異なることがある。これを知らずに数値を読むと、存在しない異常を「発見」してしまいます。

当社が自社サイトを解析した際も、実際に2回、誤った結論に踏み込みかけました。いずれもログの数値だけを見て「異常が起きている」と判断したもので、実際にサーバーへリクエストを送って確認したところ、まったく問題がありませんでした。

そのため、ログから推論した異常は、必ず実際の通信で裏を取る工程が必要になります。この検証を省くと、報告書に事実でないことが載ります。クライアントに存在しない問題を伝え、不要な改修を提案することになりかねません。

ログ分析は、ツールを入れれば結果が出る類のものではありません。何を見るかを設計し、出てきた数値を解釈し、それを検証する。この一連の判断が本体です。

実際に何が読まれていたのか

取得されていたページを並べると、執筆時点の特徴としてはっきりした傾向が出ました。

よく読まれていたのは、具体的な数値、手順、比較を含む記事です。仕様が明示されているもの、選択肢が並べて比較されているもの、手順が順を追って書かれているもの。

逆に拾われにくかったのは、抽象的な考察や、結論を提示するタイプの記事でした。読み物としての完成度とは別の軸で選ばれている印象です。従来型のコンテンツSEO対策との違いもここにあると言えます。

興味深いのは、この傾向がSearch Consoleの生成AIレポートでも一致した点です。Googleの AI Overviews で表示回数が多いページと、ChatGPTやPerplexityが取得しているページが、ほぼ同じ性質を持っていました。

プラットフォームが違っても、選ばれる条件は近い。そう考えると、AI最適化の実体は「検証可能な具体性を持たせること」に集約されそうです。

なお当社の場合、表示回数の6割ほどが、事業と直接つながらない過去の記事に集中していました。狙って作ったコンテンツではない記事が上位を占めている状態です。この点については別の記事で扱います。

同時に見つかった技術的な問題

AI対応を目的に調べ始めたのですが、副産物として通常のサイト運用上の問題もいくつか見つかりました。

• 正常に応答しているのに、実質的な中身が返っていないカテゴリページ
• 多くのページで発生していた、不要なファイルの読み込みエラー
• URL正規化の対応漏れによって、評価が2つに分裂していたページ

いずれも、一般的なSEOツールの巡回では検出されにくい種類のものです。ログとSearch Consoleを突き合わせて初めて見えてきました。

AI対応の調査は、結果として通常のテクニカルSEOの健康診断にもなります。

LLMO対策とは結局何なのか

冒頭で触れたとおり、調査時点ではあえてAI向けの個別施策は行っていない時期を選びました。それでも相応に読まれていたことになります。

なぜかを分解すると、当社の見解としては以下です。

• サーバー側でHTMLを生成しており、JavaScriptに依存していない（サーバーサイドレンダリング）
• 見出し構造と内部リンクが整理されている（テクニカルSEOの土台がしっかりしている）
• 具体的な数値や手順を含む記事が一定数ある
• クローラーを遮断していない（サーバー設定の最適化）

並べてみると、どれも従来のSEOで語られてきたことばかりです。目新しい要素がありません。

海外のSEOカンファレンスでも同様の指摘が出ています。GEO（生成エンジン最適化）として販売されている手法の多くは、枠組みを外せば堅実な基礎SEOであり、AI回答で引用されるサイトは従来の検索でも上位に表示されていたのと同じ理由で引用されている、という趣旨です。

もちろん、AI特有の論点がないわけではありません。ただ優先順位として、基礎が整っていない状態でAI専用の施策だけを足しても機能しない、というのは確かだと考えています。

新しい何かを導入する前に、まず現状を測る。それが最初の一歩です。

測定を継続するための3つの層

ここまでの内容を整理すると、AI検索での可視性は3つの層に分けて測ることになります。

1. 取りに来ているか（サーバーログ）

すべてのAIクローラーの挙動。技術的な問題の有無がここで分かります。

2. 表示されているか（Search Console 生成AIレポート）

Google圏でのAI表示回数。公式データで、ページ単位。

3. 引用・推奨されているか（専用ツール）

実際にAIの回答内で言及されたかどうか。競合との比較。

この3層に分けると、問題の切り分けができます。

そもそも取りに来ていないなら、技術かクロール設定の問題。取りに来ているのに引用されないなら、コンテンツと構造の問題。どちらに手を打つべきかが判別できるようになります。

逆にこの切り分けなしに施策を打つと、効果が出ない原因が分からないまま手数だけが増えていきます。

実行するために必要なスキル

ここまでの内容を実際に回すには、横断的なスキルが必要になります。

1.分析する側に必要なもの

ログを読んで異常を切り分ける。Search Consoleやツールのデータを解釈する。そのうえで、どのページから手を付けるべきかを事業視点で判断するスキルが必要となります。

2.実装する側に必要なもの

構造化データを設計して正しく実装する。テンプレートやレンダリングの構造に手を入れる。検出された技術課題を修正するスキルが必要となります。

この1と2は、どちらが欠けても止まります。分析だけできて実装が外注なら、指摘が実装まで届かないまま時間が過ぎます。実装だけできて分析ができないなら、その結果が企業の方針にあっているのかが分かりません。

そして両者の土台にあるのはテクニカルSEOの理解です。ここまで見てきたとおり、AI対応として語られていることの多くは、クロール、レンダリング、構造化データ、内部リンク設計といった、従来から扱われてきた領域と重なります。この基礎が弱いまま、AI対策だけを追加しても機能しません。

さらにもう一点、この領域は前提が短期間で変わります。Search Consoleに生成AIレポートが追加されたのは2026年6月ですし、主要なAIクローラーの顔ぶれやアルゴリズムもわずか1年前とは大きく異なっています。今回見た指標も、来年には別のものを見ている可能性の方が高いと感じています。つまり。一度設計して終わりにできる施策ではなく、定期的に測り直して判断を更新し続ける前提のものだと考えたほうが現実的です。

当社は分析から実装までを社内で一貫して行っており、月次の継続支援という形でこうした調査と改善実行を回しています。今回の調査も、自社サイトで実際に実施したものです。

おわりに

AI検索への対応は、いま多くの情報が飛び交っている領域です。新しい用語も次々と出てきます。

ただ実際に自社サイトを測ってみた結論としては、AI向けの個別施策を始める前の段階でも相応に読まれていました。そして読まれている記事には、明確な共通点がありました。

まず測る。何が起きているかを把握する。そのうえで、優先順位をつけて手を入れる。

順番としては、これが確実だと考えています。

本記事の数値は2026年8月時点の調査によるものです。ここで見つかった課題への対応と、その後の変化については、あらためて発信を行う予定です。