# AIクローラーはJavaScriptを実行しない > GPTBot、ClaudeBot、PerplexityBotは、サーバーが返す生のHTMLだけを読み、スクリプトを実行することはない。自社の製品カタログがAIアシスタントから見えているかを1分で確かめる方法と、サイト全体を作り直すことなく可視性を取り戻すための四つの実務的な手順を解説する。 **Language:** ja **Published:** 2026-08-09 **Category:** Technical · **Tags:** AI crawlers, JavaScript rendering, server-side rendering, GPTBot, structured data, product data **Canonical:** https://partsgraph.ai/ja/blog/ai-crawlers-do-not-run-javascript ## 要点 **GPTBotやClaudeBotのようなAIクローラーはJavaScriptを実行するのか** 実行しない。VercelとMERJが、1か月で5億6,900万件のGPTBotリクエストを処理するネットワークを対象に実施した共同分析では、GPTBot、ClaudeBot、PerplexityBot、そしてMetaのクローラーがJavaScriptを実行している形跡は確認されなかった。いずれもサーバーが返す生のHTMLをそのまま解析し、スクリプトは破棄している。例外はGoogleである。GeminiがGooglebotのレンダリング基盤を引き継いでいるためだ。パラメトリック検索型のカタログが製品データをクライアント側で組み立てているなら、AIアシスタントには、仕様が並んでいるはずの場所に空の器しか見えていない。 --- ## 結論から先に AIクローラーはJavaScriptを実行しない。GPTBot、ClaudeBot、PerplexityBotがページを要求するとき、行っているのは素のHTTP GETであり、サーバーが返したバイト列を受け取って、それをテキストとして解析するだけである。ブラウザはなく、DOMの構築もなく、ハイドレーションもなく、XHRの解決を待つこともない。VercelとMERJが、1か月で5億6,900万件のGPTBotリクエストと3億7,000万件のClaudeBotリクエストを処理するネットワークを対象に実施した共同分析では、主要なAIクローラーがJavaScriptを実行している形跡は一切確認されなかった。スクリプトファイル自体は取得することもある——GPTBotはリクエストの11.50%で、ClaudeBotは23.84%でJavaScriptを取得していた——が、それを実行することは決してない。 > **Figure.** What a browser receives versus what an AI crawler receives for the same product page. 例外はGoogleである。そして、これほど多くのチームがこの問題に気づかずにきた理由も、そこにある。GooglebotはヘッドレスのChromiumレンダリングサービスを運用しており、Geminiはその基盤の上に接地している。だからクライアントサイドレンダリングのパラメトリックカタログが、Google検索では申し分なく上位に表示されながら、ChatGPT、Claude、Perplexityからは完全に消えている、ということが起こりうる。そして両者はもはや同じ読み手ではない。Forresterの2026年のバイヤー調査では、**法人購買担当者の94%が購買プロセスの中でAIを利用している**ことが判明し、Adobeの計測では、小売サイトへのAI経由トラフィックが**2026年第1四半期に前年同期比393%増**となった。 ## GPTBotが実際に受け取っているもの ここでは、関係する二つのドキュメントを厳密に区別しておくとよい。カタログ運用チームの多くは、二つ目のほうしか見ていないからだ。 **生のHTML**とは、オリジンサーバーがレスポンスに書き出すバイト列そのものである。`curl`が出力するもの、`view-source:`が表示するもの、そしてテキストのみを扱うHTTPクライアントが解析するものだ。 **レンダリング後のDOM**とは、ブラウザがそのHTMLを解析し、すべてのスクリプトを取得して実行し、すべての`fetch()`呼び出しを解決し、すべての変更を適用し終えたあとに、メモリ上に存在するもののことだ。ブラウザの開発者ツールのElementsパネルに表示されるのは、こちらである。 現代のSPA型カタログでは、この二つのドキュメントにはほとんど共通点がない。生のHTMLは器にすぎない。`
`が一つ、プリロードのマニフェスト、そして100キロバイトに及ぶバンドル参照だけだ。意味のある文字列は——型番、パッケージ、公差、動作温度範囲、RoHS対応状況、ライフサイクル状態、在庫、数量別価格——すべて後から、クローラーが決して発行しないAPI呼び出しによって届く。 > AIクローラーが見ているのは生のHTMLだけであり、それ以外は何も見ていない。ある仕様がサーバーの返すバイト列の中になければ、モデルにとってその仕様は存在しない。 ## レンダリングするクライアント、しないクライアント | クライアント | 運営者 | JavaScriptの実行 | 用途 | |---|---|---|---| | GPTBot | OpenAI | しない | 学習データの収集 | | OAI-SearchBot | OpenAI | しない | ChatGPT向けの検索インデックス作成 | | ChatGPT-User | OpenAI | しない | ユーザーの質問に応じたリアルタイム取得 | | ClaudeBot | Anthropic | しない | 学習データの収集 | | PerplexityBot | Perplexity | しない | 検索インデックス作成 | | Meta-ExternalAgent | Meta | しない | 学習とインデックス作成 | | Bytespider | ByteDance | しない | 学習データの収集 | | Googlebot | Google | **する**（ヘッドレスChromium） | 検索、およびGeminiのグラウンディング | | Applebot | Apple | **する**（ブラウザ内でレンダリングする場合がある） | Siri、Spotlight、Safari | 表中の「しない」はすべて、VercelとMERJのデータセットで実測された挙動であって、推測ではない。「する」はすべて運営者自身が文書化している。Googleは自社のレンダリングパイプラインを公開しており、Apple自身のクローラー向けドキュメントには、Applebotが「ブラウザ内でWebサイトのコンテンツをレンダリングする場合がある」と記されている。Anthropicのより新しいClaude-SearchBotおよびClaude-Userというエージェントは、この調査より後に登場したもので、個別には計測されていない。そしてその後、これらについてレンダリングパイプラインを発表した運営者はない。 その実務上の帰結は、都合の悪い形で非対称である。クロールにおいて費用がかかるのはレンダリングの部分であり、それを省いた運営者こそが、いまや自社製品と買い手のあいだに座っているのだ。 ## パラメトリックカタログがとりわけ深刻に失敗する理由 Adobeが2026年4月に公表した分析は、小売サイトのページを機械可読性の観点で採点し、製品詳細ページが**66%——全ページ種別のなかで最低**という結果を示した。ホームページ（75%）、カテゴリーページ（74%）、さらにはFAQページ（80%）をも下回っている。この順序は偶然ではない。もっとも構造化され、もっとも価値が高く、もっとも意思決定に直結するデータを担うページこそが、もっとも多くのJavaScriptで組み上げられているのだ。 被害の大半は、五つのパターンで説明がつく。 1. **フィルターの状態がクライアント側にある。** パラメトリック検索のセレクターは、ローカルストアを読むReactコンポーネントにすぎない。「0603、100nF、X7R、50V」に対応するサーバーレンダリング済みのURLは存在しないので、クローラーが取得できるものも、引用できるものもない。 2. **仕様表がAPIレスポンスになっている。** まずページの器が描画され、そのあとに`/api/product/attributes`へのリクエストが表を埋める。クローラーは器のところで止まる。 3. **価格と在庫を意図的にクライアント側に置いている。** キャッシュの観点では理にかなっている。だが機械可視性にとっては致命的だ。在庫が見えないモデルは、その部品を推薦しないからである。 4. **タブやアコーディオンが中身の読み込みを先送りしている。** データシート、アプリケーションノート、適合証明書、CADリンクは、クリック時に読み込まれることが多い。クローラーはクリックしない。 5. **ページネーションを無限スクロールで置き換えている。** 51件目以降の製品には、クロール可能なURLがそもそも存在しない。 Partsgraphは2026年8月、北米・欧州・アジアにわたる世界984社のディストリビューターおよびメーカーのドメインを監査した。AI可視性スコアの中央値は**100点満点中50点**であり、**対象群の70%がDまたはFの評価**だった。およそ半数は、標準的な非ブラウザクライアントに対して、読めるカタログページを1ページも提供できなかった。もっとも弱かったセグメントは電子部品流通で、中央値は34だった。 ## AIクローラーが自社カタログを読めるかを、どう確かめるか これは自社のオリジンに対して実施すること。クローラーのユーザーエージェントを偽装して競合サイトを試すと、誤った陰性の結果が出る。エンタープライズ向けのボット管理製品は、ユーザーエージェント文字列ではなく送信元IPでクローラーを検証しているからだ。見知らぬアドレスから届いた偽装ヘッダーは、robots.txtに何と書かれていようとチャレンジを受ける。 1. **生のHTMLを取得する。** 自社でもっとも価値の高い製品ページを一つ選ぶ。 ``` curl -sS --compressed -o page.html -w "status=%{http_code} bytes=%{size_download}" "https://example.com/products/part-number" ``` 2. **バイト列の中に型番があるか探す。** ブラウザの中ではなく、ファイルの中を見ること。 ``` grep -c "MPN-12345" page.html ``` ここで`0`が返るなら、そのページがその部品について書かれたページであることを、どのAIクローラーも識別できない。 3. **パラメトリック値を三つ探す。** エンジニアなら絞り込みに使うだろう、と考えられる項目を選ぶ。 ``` grep -oiE "operating temperature|tolerance|package|rohs|lifecycle" page.html | sort | uniq -c ``` 4. **構造化データのブロック数を数える。** ``` grep -c "application/ld+json" page.html ``` ゼロなら、機械可読な製品レコードは存在しない。1件以上あるなら、それを取り出したうえで、単なるパンくずリストではなく、`sku`、`mpn`、`gtin`、`brand`、`offers`、そして自社にとって重要な`additionalProperty`の項目を実際に含んでいるかを検証すべきだ。 5. **レンダリング後のページと突き合わせる。** JavaScriptを無効にしたブラウザで同じURLを開く。そこに残るものが、おおよそクローラーの受け取るものだ。それと通常のページとの差分こそが、自社の見えていない部分である。 6. **1ページではなく、経路全体を確認する。** カテゴリーページ、検索結果ページ、データシートのリンク、CADのダウンロードについても同じ手順を繰り返すこと。製品ページを読めても、クロール可能なカテゴリー一覧からそこへたどり着けないクローラーは、やはり行き詰まったままである。 合格するページでは、型番が数十回出現し、パラメトリック項目のラベルがテキストとして存在し、JSON-LDのブロックが少なくとも一つある。目安として、よくできた製品ページは完全な仕様表を含む60〜200KBのHTMLを返す。壊れたSPAの器は、バンドル参照しか含まない4〜15KBを返す。 ## サイトを作り直さずに直すには 基盤を入れ替える必要はない。必要なのは、オリジンが返すバイト列の中に事実が含まれていることだ。方法は四つあり、互いに排他ではない。 | 方法 | 工数 | 解決できること | 主なリスク | |---|---|---|---| | 製品ルートのサーバーサイドレンダリング | 大 | すべてを、恒久的に | 基盤入れ替えのコストとデグレのリスク | | プリレンダリング／ダイナミックレンダリング | 中 | 生のHTMLの中身 | 価格と在庫におけるキャッシュの陳腐化 | | サーバーサイドレンダリングのJSON-LD | 小 | 機械可読な事実 | 本文が空のままなら無視される | | Markdownミラーとオーバーレイ層 | 小 | コンテンツ、ドキュメント、エージェントからのアクセス | canonicalリンクの維持が必要 | 製品ルートとカテゴリールートの**サーバーサイドレンダリング**が、持続する答えである。すでに対応しているフレームワークを使っているなら、カタログのルートをサーバーコンポーネントや、増分再検証つきの静的生成へ移すのは、四半期単位ではなく数週間単位の作業で済むことが多い。データ層はすでに存在しており、ただ間違った側から呼ばれているだけだからだ。 **プリレンダリング**は、率直なつなぎの手段だ。各製品ページをビルド時あるいは定期実行で一度描画し、そのHTMLをエッジにキャッシュして、すべての相手に返す。人間にも機械にも同じドキュメントを返すこと。クローラーにだけ別のページを見せるクローキングは、ポリシー上のリスクであると同時に、実務上は自滅的でもある。モデルは、自分が受け取ったほうのバージョンを引用するからだ。 **サーバーサイドでレンダリングするJSON-LD**は、小さな労力でもっとも効果の大きい変更である。タグマネージャーの中ではなく、サーバーが出力するHTMLの中に置くこと。 ``` ``` **Markdownミラー**は、ページの曖昧さをなくすもっとも安価な方法だ。すべての製品ページについて、プレーンテキストの等価物を、安定した、リンクの張られたURLで提供する。仕様表はMarkdownの表として描画する。テキストのみを扱うクライアントはこれを完璧に解析でき、同じデータソースから生成するコストはほぼゼロで、しかもフロントエンドを刷新しても揺らがない、正規の機械向け接点が手に入る。なお、`llms.txt`はこれとは別物である。2026年時点で、主要なAI事業者でこれを読むと明言したところはなく、GoogleのSearch Relationsチームは支持を明確に見送っている。ミラーが機能するのは、それがリンクの張られた普通のページだからだ。 **オーバーレイ**は、以上のすべてを既存サイトの内側ではなく、その手前に置く方式である。サイドカーのサービスやエッジワーカーが、既存のPIMを参照しながら、サーバーサイドレンダリング済みのエージェント可読ページ、JSON-LD、Markdownミラー、そしてホスト型のMCPエンドポイントを、自社ドメイン上で提供する。顧客向けサイトは何も変わらない。Partsgraphが採っているのはこのアプローチであり、自社で同じものを構築するメーカーも増えている。Microchipは2025年11月に、自社製品データ向けの無償の公開MCPサーバーを公開し、ECIAのTrustedPartsは2026年6月に在庫AIエージェントサービスを開始した。 ## まず何から着手するか、その順序 1. 主力製品10点に対して、上記の6ステップのテストを実行し、バイト数を記録する。 2. 製品ページのJSON-LDをサーバーサイドでレンダリングする。変更としてはもっとも小さく、計測できる効果はもっとも大きい。 3. すべての仕様、データシートのリンク、CADのリンクを、初期HTMLの中に存在させる。インタラクティブ版はクライアント側のままでも構わない。 4. 意味のあるパラメトリックフィルターの組み合わせすべてに、実在する、クロール可能な、サーバーサイドレンダリング済みのURLを与える。 5. 製品ごとにMarkdownミラーを公開し、そのページからリンクする。 6. 順位やプロンプト、回答シェアを気にするのは、そのあとでよい。引用の前に、まず取得がある。コンテンツがレスポンスボディの中に存在しない限り、最適化すべき対象そのものが存在しない。 ここで働いている仕組みは、微妙なものでもなければ、論争の的でもない。モデルは自分が受け取ったものしか引用できない。そして受け取ったものとは、あなたの生のHTMLである。それ以外はすべて、実行されなかったレンダリングの工程にすぎない。 *自社のカタログがどの位置にあるかを知りたい方へ。無償のPartsgraph AI可視性グレーダーが、本記事のチェック項目をあなた自身のドメインに対して実行します。[/audit](/audit)からどうぞ。* ## よくある質問 ### GPTBotはJavaScriptをレンダリングするのか しない。VercelとMERJの調査によれば、GPTBotは全リクエストの約11.5%でJavaScriptファイルを取得しているが、それを実行することはない。コンテンツの抽出は、サーバーが最初のレスポンスで返すHTMLからのみ行われる。読み込み後にバンドルがDOMへ注入するものは、GPTBotからは一切見えない。 ### なぜGoogleは自社のシングルページアプリを見られるのに、ChatGPTには見えないのか GooglebotはヘッドレスのChromiumレンダリングサービスを運用しており、JavaScriptを実行したうえで、生成されたDOMをインデックスする。Geminiも同じ基盤の上に接地している。一方、OpenAI、Anthropic、Perplexityはブラウザエンジンを持たない単純なHTTPフェッチャーを運用している。だから、まったく同じページがGoogleでは問題なく上位に表示されながら、AIの回答からは完全に消えるということが起こる。 ### プリレンダリングやダイナミックレンダリングで解決できるのか できる場合がある。すぐに基盤を入れ替えられないカタログにとっては、正当なつなぎの手段でもある。リスクは二つ。価格と在庫でキャッシュが陳腐化すること、そしてユーザーが受け取るページとは実質的に異なるページをクローラーに返してしまうことだ。プリレンダリングしたHTMLはレンダリング後のページと意味的に同一に保ち、変動の激しい項目には短い再検証間隔を設定すること。 ### JSON-LDだけで十分なのか サーバーが返すHTMLの中に入っている場合に限り、意味がある。タグマネージャーやクライアント側スクリプトが注入するJSON-LDは、クローラーがすでに処理を終えたあとに届く。scriptタグはサーバーサイドでレンダリングすること。そしてJSON-LDは、読める本文の代替ではなく、あくまでその補完として扱うこと。 ### 1分以内に自分で確かめるにはどうすればよいか 製品ページのURLに対して、圧縮を有効にしたcurlを実行し、レスポンスを保存する。そのうえで、生のバイト列を型番と2〜3個のパラメトリック値でgrepする。ブラウザでは見えているのにファイルの中には存在しないなら、それはJavaScriptが組み立てているということであり、AIクローラーがそれを目にすることは永遠にない。 ### AIクローラーは自社のサイトマップを尊重するのか 使い方は一貫していない。VercelとMERJの計測では、ChatGPTによる取得の34.82%が404に着地しており、Googlebotの8.22%と比べて際立って高い。規律あるサイトマップ巡回ではなく、古い情報源からのリンク発見に頼っている様子がうかがえる。正確なlastmod値を備えたサイトマップは助けになるが、中身を返さないページを埋め合わせてはくれない。 ### CADやBIM、データシートのダウンロードにも当てはまるのか 当てはまる。しかも、より深刻な形で。ダウンロードリンクがJavaScriptで生成されていたり、インタースティシャルの背後にあったり、短命な署名付きURLを経由して解決される場合、ブラウザではないクライアントはそもそもそれをたどれない。そのドキュメントは、存在しないのと同じである。 ## 出典 1. [Vercel and MERJ, The rise of the AI crawler, December 2024](https://vercel.com/blog/the-rise-of-the-ai-crawler) 2. [Adobe Digital Insights, AI traffic and retail machine-readability, April 2026](https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable) 3. [eCommerceNews, Adobe machine-readability scores by page type, April 2026](https://e-commerce.news/story/adobe-says-ai-retail-traffic-surges-as-readability-lags) 4. [TechCrunch, AI traffic to US retailers rose 393% in Q1, April 2026](https://techcrunch.com/2026/04/16/ai-traffic-to-us-retailers-rose-393-in-q1-and-its-boosting-their-revenue-too/) 5. [Forrester, The State Of Business Buying, 2026 (January 2026)](https://www.forrester.com/blogs/state-of-business-buying-2026/) 6. [Google Search Central, Google crawlers and user agents](https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers) 7. [OpenAI, Overview of OpenAI crawlers](https://developers.openai.com/api/docs/bots) 8. [Anthropic, Does Anthropic crawl data from the web?](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler) 9. [Apple Support, About Applebot](https://support.apple.com/en-us/119829) 10. [Microchip Technology, MCP Server press release, November 2025](https://ir.microchip.com/news-events/press-releases/detail/1344/microchip-technology-unveils-model-context-protocol-mcp-server-to-power-ai-driven-product-data-access) 11. [ECIA, TrustedParts.com launches Inventory AI Agent Service, June 2026](https://www.ecianow.org/2026/06/11/trustedparts-com-launches-inventory-ai-agent-service/) 12. [Search Engine Journal, Google says llms.txt is speculative for now](https://www.searchenginejournal.com/google-says-llms-txt-is-purely-speculative-for-now/577576/) ## Other languages - English: https://partsgraph.ai/blog/ai-crawlers-do-not-run-javascript/md - Deutsch: https://partsgraph.ai/de/blog/ai-crawlers-do-not-run-javascript/md - Français: https://partsgraph.ai/fr/blog/ai-crawlers-do-not-run-javascript/md - Español: https://partsgraph.ai/es/blog/ai-crawlers-do-not-run-javascript/md - Italiano: https://partsgraph.ai/it/blog/ai-crawlers-do-not-run-javascript/md - Nederlands: https://partsgraph.ai/nl/blog/ai-crawlers-do-not-run-javascript/md - Polski: https://partsgraph.ai/pl/blog/ai-crawlers-do-not-run-javascript/md - Português: https://partsgraph.ai/pt/blog/ai-crawlers-do-not-run-javascript/md - Svenska: https://partsgraph.ai/sv/blog/ai-crawlers-do-not-run-javascript/md - Türkçe: https://partsgraph.ai/tr/blog/ai-crawlers-do-not-run-javascript/md - 한국어: https://partsgraph.ai/ko/blog/ai-crawlers-do-not-run-javascript/md - 简体中文: https://partsgraph.ai/zh/blog/ai-crawlers-do-not-run-javascript/md --- Partsgraph — the agent-ready parts data layer. Free AI-visibility grader: https://partsgraph.ai/ja/audit