Googlebotはもう忘れよう。長年熱心に実行してきたクロール可能性、インデックス可能性、速度、モバイルフレンドリー、構造化データといったチェックリストは、今や遺物だ。
なぜなら、我々が知るインターネットは、もはやGoogleのインデクサーのためだけの遊び場ではないからだ。
2026年までに、あなたのウェブサイトには少なくとも十数もの『追加』非人間的コンシューマーが存在することになる。
GPTBot、ClaudeBot、PerplexityBotといったAIクローラーは、単に閲覧しているだけでなく、積極的にモデルをトレーニングし、次世代のAI検索結果を駆動している。さらに、最近発表されたGoogle-Agentや、Claude-User、ChatGPT-Userのようなその仲間のように、『特定の人間』のためにリアルタイムでブラウジングするユーザー起動型エージェントもいる。Cloudflareの2026年第1四半期分析は、厳しい現実を突きつけている。ウェブトラフィックの30.6%がボットに由来し、AIクローラーとエージェントがそのパイの着実に成長する一片を占めているのだ。あなたのテクニカル監査？それらはすべてを考慮するために、根本的な書き直しが必要だ。
旧世代 vs. 新型ボット：乖離
さて、あなたのrobots.txtファイルについて話そう。おそらく、Googlebotや、もしかしたらBingbotのような、ごく少数の既知のエンティティを念頭に置いて書かれたのだろう。しかし、AIクローラーは全く違う。これらは、あなたがすでに管理しているボットとは別に、明確なルールを必要とする。これを無視することは、玄関のドアをこじ開けっ放しにして、特定のゲストだけが入ってくることを期待するようなものだ。そんなわけがない。
ここで重要な問いがある：クローラーごとに『意図的な決定』を下しているか、それともデフォルト設定に固執しているか？なぜなら、そのデフォルト設定は？あなたが望まないボットを静かに受け入れているか、あるいは、より重大なことに、あなたが望むボットをブロックしている可能性があるからだ。
では、何をチェックすべきか？
GPTBot、ClaudeBot、PerplexityBot、Google-Extended、Bytespider、AppleBot-Extended、CCBot、ChatGPT-UserといったAI固有のユーザーエージェントを対象としたルールについてrobots.txtを確認せよ。これらが明示的にリストアップされていない場合、あなたは危険な仮定に基づいていることになる――デフォルト設定があなたの戦略目標と一致しているという仮定だ。ほぼ間違いなく、そうではない。
AIクローラーのトラフィックは、大まかに分類できる：トレーニングクローラー（AIクローラートラフィックの89.4%、Cloudflareによる）はデータコレクターであり、検索クローラー（8%）はAI回答を駆動し、ユーザー起動型エージェント（2.2%）はリアルタイムプロキシとして機能する。それぞれに合わせたアプローチが求められる。
クロール・トゥ・リファラル比率を検討せよ。例えば、AnthropicのClaudeBotは、たった1つのリファラルに対して驚異的な2万6千ページをクロールする。OpenAIの比率は1,300:1だ。Meta？リファラルはゼロ。OpenAIのOAI-SearchBotやPerplexityBotを直接ブロックすることは、ChatGPT SearchやPerplexityのAI回答でのあなたの可視性に影響を与える。逆に、CCBotやMetaのようなトレーニング中心のクローラーをブロックすることは、直接的なトラフィックメリットをもたらさないソースからのデータ抽出を防ぐ可能性がある。
クロール・トゥ・リファラル比率は、誰が『与えずに奪っている』かを示してくれる。
そして、Google-Agentだ。これは特別な注意が必要なものだ。2026年3月にGoogleの公式ユーザー起動フェッチャーリストに追加されたこのエージェントは、ユーザーに代わってブラウジングするGoogleのAIシステムからのリクエストを識別する。肝心なのは？これはrobots.txtを無視する。Googleの論理：人間がリクエストを開始したため、ユーザープロキシとして機能するということだ。Google-Agentをブロックすることは、単純なrobots.txtの調整ではなく、サーバーサイド認証が必要になる。これは、未来にとって興味深く、率直に言って重要な進展だ。
JavaScriptレンダリング：見えない障壁
ここで、多くのモダンウェブサイトにとって、事態は本当に面倒になる。
GooglebotはJavaScriptをレンダリングする。これは古いニュースだ。新しいのは？事実上、他の『すべての主要AIクローラーがそうではない』ということだ。GPTBot、ClaudeBot、PerplexityBot、CCBot――これらはすべて、静的なHTMLのみを取得する。AppleBotとGooglebotが例外だ。
これが実質的に何を意味するか？
あなたの重要なコンテンツ――商品名、価格、サービス説明――がクライアントサイドJavaScript（React、Vue、Angularで構築されたほとんどのSPAを想像してほしい）内に存在する場合、それはOpenAI、Anthropic、Perplexityのモデルのトレーニングにとって実質的に見えない。あなたは彼らに空白のページを送っているようなものだ。
主要ページで簡単なcurl -s [URL]を実行してみよう。もしその重要なコンテンツが生HTMLレスポンスに含まれていないなら、明日の検索結果を駆動するモデルをトレーニングしているAIクローラーもそれを見ることができない。これはブラウザの「要素を検証」とは異なる。これはレンダリングされたDOMを表示する。あなたはソースを確認する必要がある。
サーバーサイドレンダリング（SSR）や静的サイトジェネレーション（SSG）は、もはや単なる最適化戦術ではない。AI検索での可視性のためには、それらは今や根本的な要件だ。
クロールバジェットとAIトレーニングの未来
既存のクロールバジェットに関する議論は、これからさらに複雑になる。特にAIトレーニングクローラーは、かなりのリソースを消費する可能性がある。それらの動作を理解し、適切なrobots.txtディレクティブを設定することは、アクセスを制御し、直接的なリターンをもたらさないボットによってサーバーリソースが枯渇するのを防ぐために極めて重要だ。
これは始まりに過ぎないのだろうか？間違いなくそうだ。AIの絶え間ない進化は、これらのクローラーとその動作を変化させるだろう。先を行くためには、昨日の静的なチェックリストを超え、あなたのコンテンツとやり取りするすべての重要なデジタルエンティティのニーズを予測する、動的で多面的な監査へと移行する、プロアクティブでデータ駆動型のアプローチが必要だ。
単一目的のボットのために構築された標準的なテクニカルSEO監査は、死んだ。AIを意識したテクニカルSEO監査よ、永遠なれ。
