外資系SEOスペシャリスト
Takuma Oka (岡 拓馬)
こんにちは、岡 拓馬（おか たくま）です。
このブログでは、海外ノマド×SEO×ストック収入をテーマに、自分の経験や学びを発信しています。
高校卒業後は料理人としてスタートし、その後、航空自衛隊での勤務を経て、2016年からWebライター・SEOコンサルタントとして独立。現在は、海外の外資系企業と契約しながら、フルリモートで働いています。拠点はアジア各国を転々としており、最近はベトナムやタイ、マレーシア、フィリピンなどでノマド生活をしています。
「Googleでは上位なのに、ChatGPTやPerplexityに聞くと、うちの会社がまったく出てこない」
最近、こういう相談が明確に増えています。
そして多くの場合、原因はコンテンツの質ではありません。
そもそもAIに、あなたのページの中身が”見えていない”のです。
AI検索で引用・参照されるためのサイト最適化を、LLMO（LLM最適化／生成エンジン最適化）と呼びます。
そしてLLMO対策の出発点にして最大の盲点が、この「AIクローラーがJavaScriptを読めない」というレンダリングの問題です。
しかも厄介なことに、Googleと違って、AIクローラーには「ちゃんと読めていますか？」を確認する公式の手段がほとんどありません。
Takuma本記事では、このLLMOの盲点を、前半は経営者・マーケ責任者向けにやさしく、後半は実務家向けに技術的な深掘りまで、2部構成で解説します。
LLMOの前提：なぜAIクローラーにサイトが見えないのか
Googleには”答え合わせ”がある。AIクローラーにはない
Googleには Search Console（サチコ）という強力なツールがあります。
URL検査を使えば、GoogleがJavaScriptを実行した後の、レンダリング済みのページをどう認識しているかを、スクリーンショット付きで目視確認できます。
いわば「Googleからの答え合わせ」ができるわけです。
ところが、主要なAIクローラー（OpenAIのGPTBotなど）には、これに相当する公式ツールが現状存在しません。
AI検索ツールのライブラリ「daydream」も、OpenAIはSearch Console的なツールをまだ提供しておらず、サーバーログの監視が現状のベスト手段だと指摘しています（2025年）。
つまり、あなたのサイトがAIにどう見えているかは、完全なブラックボックスになっている。これがすべての出発点です。
AIクローラーはJavaScript実行後の画面を見ていない
ではなぜ「見えない」ことが起きるのか。理由はシンプルで、多くのAIクローラーは、Googleのようにブラウザでページを描画（レンダリング）しないからです。
Googlebotは10年以上かけてヘッドレスChromeの描画エンジンを育て、JavaScriptを実行してから内容を理解します。一方、GPTBotやClaudeBot、PerplexityBotといったAIクローラーは、ヘッドレスブラウザを持ちません。
HTTPリクエストを投げて、返ってきた生のHTML（＝JS実行前のソースコード）をそのまま読むだけです。
Vercelの大規模調査「The rise of the AI crawler」は、この実態を数字で示しています。
同調査によると、主要なAIクローラーはいずれもJavaScriptを実行しません。
興味深いのは、ChatGPTはリクエストの11.5%、Claudeは23.8%でJavaScriptファイル自体は取得しているのに、それを実行はしていないという点です。
Takumaコードを「テキストとして拾う」けれど「動かして中身を見る」ことはしない。ここに決定的なギャップがあります。
具体例：CSRサイトがAIに「空っぽ」に見える瞬間
これが実害になるのは、いわゆるクライアントサイドレンダリング（CSR）のサイトです。
たとえばReactやVueで作られた、JavaScriptが動いて初めて中身が表示されるタイプのサイト。AIクローラーがアクセスした瞬間に受け取るのは、こんなHTMLです。
<html>
<head></head>
<body>
<div id="app"></div>
<script src="app.js"></script>
</body>
</html>商品説明も、料金表も、導入事例も、すべて app.js が動いた後に表示される設計だと、AIにはこの「空っぽの箱」しか見えません。
Takuma人間のユーザーには美しく表示されているのに、AIにとっては中身ゼロのページ。これでは引用も推薦もされようがありません。
経営者がいま確認すべき、たった1つの問い
技術用語を一旦すべて忘れて構いません。
経営者・マーケ責任者の方に持ち帰っていただきたいのは、次の問いだけです。
「うちのサイトは、JavaScriptをオフにしても、肝心のテキストが読める状態になっているか？」
もし自社サイトをブラウザで開き、JavaScriptを無効化したときに中身が消えてしまうなら、AI検索時代において、それは「存在しないページ」とほぼ同義です。
Google順位がどれだけ良くても、です。
ここまでが入門編。「AIに見えていないかもしれない」という危機感を共有できたら、後半でその確認方法と対策を、実務レベルまで掘り下げます。
LLMO実務：AIクローラー対策とSSRの全体像
「AIクローラー」は1種類ではない、GPTBotら3分類を区別する
ここからが、X（旧Twitter）の短い投稿では書ききれない核心です。
多くの解説が「AIボット」を一括りにしていますが、これは実務上、危険な単純化です。
OpenAI一社をとっても、役割の違う複数のクローラーが動いています。大きく分けると3種類です。
- 学習用クローラー（GPTBot / ClaudeBot など）：モデルの学習データを集める
- 検索用クローラー（OAI-SearchBot / Claude-SearchBot / PerplexityBot など）：AI検索の回答にサイトを引用・表示するために巡回する
- ユーザー駆動フェッチ（ChatGPT-User など）：ユーザーが質問した瞬間に、リアルタイムでページを取りに行くエージェント
この区別が効いてくるのは戦略設計の場面です。
たとえば「学習データには使われたくないが、AI検索の回答には引用されたい」という意向は、十分に成立します。
学習用のGPTBot・ClaudeBotはrobots.txtで弾きつつ、検索用のOAI-SearchBot・Claude-SearchBotは通す。こうした出し分けが可能なのです。
Takuma「AIに全部ブロック」か「全部許可」かの二択で考えている時点で、機会損失が始まっています。
robots.txtの出し分けという新常識
具体的には、こういう構成になります。
# AI検索の引用は許可（可視性を確保）
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
# 学習クロールはブロック
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /注意点として、ユーザーエージェント名は詐称が容易なので、本気で検証するならUA（ユーザーエージェント）に加えてIPアドレスを各社の公開レンジと照合する必要があります。
OpenAIもAnthropicも、自社クローラーのIPレンジを公開しています。
例外はGemini 、「AI検索」と一括りにしてはいけない
もう一つ、絶対に押さえておくべき例外があります。
Google Gemini（およびAI Overviews）だけは、JavaScriptをレンダリングできるという点です。
GeminiはGooglebotのWeb Rendering Service（WRS）基盤をそのまま使っているため、従来のSEOの延長で評価されます。一方、ChatGPTやPerplexityは生HTMLしか見ない。
ここから導けるのは、私がかねて主張している「ChatGPT対策とGemini対策は別物」という結論です。
Gemini/AI Overviewsでの可視性は既存のSEO・技術最適化の延長で取りに行ける（比較的速い）一方、ChatGPT系での可視性は生HTMLの最適化と第三者からの言及の蓄積が効く（比較的遅い）。
「AI検索」とひとまとめにした瞬間に、打ち手の優先順位を見誤ります。
なお、AIクローラーが生HTMLしか見ない状況がいつまで続くかですが、AI検索コンサルティングのLantern（2026年3月時点）は、2026年6月時点でも主要なAIクローラー（GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot、Claude-SearchBot、PerplexityBot、Meta-ExternalAgentなど）はいずれもJavaScriptをレンダリングせず、例外はGeminiのみだと整理しています。
つまり、「いずれAIも賢くレンダリングしてくれる」に賭けるのは、当面は危険ということです。
自社サイトがAIクローラーにどう見えるかを”確認”する4つの方法
公式ツールがない以上、現場でできるのは「近似検証」です。
ここはXの投稿で触れた3手法を、実コマンドつきで実務レベルに落とし込みます。
① curl で生HTMLを直接見る
最も手軽で確実。AIクローラーが最初に受け取る生HTMLそのものが返ってきます。
curl -s https://your-domain.com/your-page | lessここに主要なテキスト（見出し、本文、価格など）が含まれていればOK。空のdivしかなければ、AIにも空に見えています。
※ターミナルで実行してください。
② ブラウザのDevToolsでJavaScriptを無効化する
Chromeで Cmd/Ctrl + Shift + P → 「Disable JavaScript」を実行してリロード。残った表示が、ほぼAIクローラーの見ている世界です。
非エンジニアでもできる検証なので、社内で一度やってみることを強くおすすめします。
▼具体的な確認方法はこちら
キーボードの F12 キー（Macの場合は Cmd + Option + I）を押します。
画面の右側、または下側に英語やコードが書かれたパネル（デベロッパーツール）が表示されます。
デベロッパーツールが開いた状態のまま、以下のショートカットキーを押します。
- Windows:
Ctrl + Shift + P - Mac:
Cmd + Shift + P
画面上部に小さな入力欄（コマンドメニュー）が現れます。
入力欄に disable と入力すると、候補に Disable JavaScript（JavaScriptを無効にする）が表示されるので、それを選択して Enter を押します。
(※元に戻したいときは、同じ手順で Enable JavaScript を実行すればOKです)
ブラウザの更新ボタンを押すか、Ctrl + R（Macは Cmd + R）でページをリロードします。
▼主な確認実行
①テキストコンテンツがしっかり残っている
「台湾・夜市のおすすめ有名屋台グルメ！」「マレーシアでのキャッシング方法」といった記事タイトルや、プロフィールの紹介文などが、JavaScriptがなくてもごっそり消えることなく、綺麗に読み取れる形で残っています。
②リンク構造（ナビゲーション）が生きている
各記事へのリンクや「お問い合わせフォーム」などのテキストリンクがしっかり露出しているため、AIクローラーは迷子にならずにサイト内を巡回（クロール）できます。
③ サーバーログで”本物の”AIボットの挙動を監視する
ここはXの投稿時に私が一度間違えて修正した部分です。「自分のUAを偽装してログを見る」のは循環していて意味がありません（映るのは自分の偽装リクエストだけ）。
正しくは、本物のGPTBotやOAI-SearchBotの挙動を、UA＋IP照合で監視し、どのページを叩いているか・ステータスコードは何かを観察します。
④ LLMに読み込ませて「何が読めたか」を答えさせる
ChatGPTなどにURLを渡し、「このページから何が読み取れるか要約して」と頼む。「動的に読み込まれていて読めない」と返ってくれば、JS依存のサインです。ただし注意点が2つ。
LLMはHTMLを逐語で正確に再現するのが苦手で、再構成してしまうこと。
そしてブラウジング用エージェント（ChatGPT-User）と、インデックス用クローラー（GPTBot/OAI-SearchBot）は別物なので、これはあくまで「方向性の確認」にとどめてください。
根本対策はSSR/SSG、日本のSMBがむしろ有利な理由
検証で問題が見つかったときの本質的な解決策は、ほぼ一つに集約されます。
最初からサーバー側で完成済みのHTMLを返すことです。
- SSR（サーバーサイドレンダリング）：Next.js、Nuxt、SvelteKit などのフレームワークで、初回リクエスト時点から構造化済みのHTMLを返す
- SSG（静的サイト生成）：ビルド時にHTMLを生成しておく
- プレレンダリング：クローラーを検知したときだけ、描画済みのHTMLスナップショットを返す中間策
ここで日本のSMB（中小企業）にとって朗報があります。日本のWebサイトの多くを支えるWordPressは、そもそもサーバー側でHTMLを生成するSSR型です。
つまり、凝ったCSRのSPAを組んでいない限り、多くの日本企業サイトはAIクローラーから「中身が見える」状態にあります。
テクニカルSEOの土台がある分、むしろ有利なポジションにいるのです。
Takuma問題が起きやすいのは、モダンなJSフレームワークでフルCSR構成を選んでしまったケースです。
一歩先の論点：「取得される」と「引用される」は別物
最後に、中級者向けに踏み込みます。
生HTMLが読める状態は必要条件であって、十分条件ではありません。
iPullRank（2026年5月）は、AI検索には「取得（fetch）」という前段の関門があると指摘しています。
ChatGPTやPerplexityはリアルタイムで何百もの候補ページを並行取得しており、応答が遅いページは、評価される前に切り捨てられる。同記事が紹介するProfoundの分析では、AIクローラーに対する失敗率が75%を超えるページは、安定したページに比べて引用イベントが平均で約18分の1にまで激減したといいます。
これは順位の問題ではなく、そもそも候補に入れるかどうかの”参加資格”の問題です。
もう一点、よく誤解されるのが構造化データ（JSON-LD）の効果です。
「AIに引用されるためにスキーマを入れろ」という主張は広く出回っていますが、Ahrefsの大規模テスト（2026年）では、構造化データを追加してもAI Mode・ChatGPTでの引用増加は確認できませんでした。
私の見解としては、JSON-LDは「入れれば引用が増える魔法」ではなく、エンティティの曖昧さを減らす補助線と捉えるのが妥当です。
Takuma優先順位としては、まず生HTMLに中身があること、次に取得が速いこと。スキーマはその後です。
まとめ：LLMO時代の最強の防御は、基本のテクニカルSEO
ここまでの内容をわかりやすく整理します。
- AIクローラーの多く（Gemini除く）はJS実行前の生HTMLしか見ない
- Googleと違い、見え方を確認する公式ツールがない
- だから、curl・DevTools・ログ監視で近似検証するしかない
- 根本対策はSSR/SSGで最初から完成HTMLを返すこと
- ただし「取得できる」と「引用される」は別。速度と中身の質が次の関門
派手なAIテクニックを追う前に、「AIにそもそも中身が届いているか」という最も基本的なテクニカルSEOを固める。これが、AI検索時代における最大かつ最強の防御です。
とはいえ、「curlやDevToolsで自分で確認するのはハードルが高い」という方も多いはずです。
そこで私が開発したのが、AI検索最適化の診断ツール SEGO（sego.jp） です。自社サイトがAIクローラーから見て、どの程度「読める・引用される」状態になっているかを診断できます。
本記事で解説した「レンダリングの不透明性」を、まずは自分の目で確かめるところから始めてみてください。
＼ まずは気になるページを診断してみよう ／
- Vercel「The rise of the AI crawler」（2025年）
- Lantern「AI crawlers do not render JavaScript」（2026年3月）
- iPullRank「How Page Speed Impacts ChatGPT and Perplexity Visibility」（2026年5月）
- Ahrefs 構造化データ検証（2026年）
- daydream「How OpenAI Crawls and Indexes Your Website」（2025年）
