AIクローラーはJavaScriptを実行しない

結論から先に

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を取得していた——が、それを実行することは決してない。

例外は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は器にすぎない。<div id="root">が一つ、プリロードのマニフェスト、そして100キロバイトに及ぶバンドル参照だけだ。意味のある文字列は——型番、パッケージ、公差、動作温度範囲、RoHS対応状況、ライフサイクル状態、在庫、数量別価格——すべて後から、クローラーが決して発行しないAPI呼び出しによって届く。

AIクローラーが見ているのは生のHTMLだけであり、それ以外は何も見ていない。ある仕様がサーバーの返すバイト列の中になければ、モデルにとってその仕様は存在しない。

レンダリングするクライアント、しないクライアント

表中の「しない」はすべて、VercelとMERJのデータセットで実測された挙動であって、推測ではない。「する」はすべて運営者自身が文書化している。Googleは自社のレンダリングパイプラインを公開しており、Apple自身のクローラー向けドキュメントには、Applebotが「ブラウザ内でWebサイトのコンテンツをレンダリングする場合がある」と記されている。Anthropicのより新しいClaude-SearchBotおよびClaude-Userというエージェントは、この調査より後に登場したもので、個別には計測されていない。そしてその後、これらについてレンダリングパイプラインを発表した運営者はない。

その実務上の帰結は、都合の悪い形で非対称である。クロールにおいて費用がかかるのはレンダリングの部分であり、それを省いた運営者こそが、いまや自社製品と買い手のあいだに座っているのだ。

パラメトリックカタログがとりわけ深刻に失敗する理由

Adobeが2026年4月に公表した分析は、小売サイトのページを機械可読性の観点で採点し、製品詳細ページが66%——全ページ種別のなかで最低という結果を示した。ホームページ（75%）、カテゴリーページ（74%）、さらにはFAQページ（80%）をも下回っている。この順序は偶然ではない。もっとも構造化され、もっとも価値が高く、もっとも意思決定に直結するデータを担うページこそが、もっとも多くのJavaScriptで組み上げられているのだ。

被害の大半は、五つのパターンで説明がつく。

1. 01フィルターの状態がクライアント側にある。 パラメトリック検索のセレクターは、ローカルストアを読むReactコンポーネントにすぎない。「0603、100nF、X7R、50V」に対応するサーバーレンダリング済みのURLは存在しないので、クローラーが取得できるものも、引用できるものもない。
2. 02仕様表がAPIレスポンスになっている。 まずページの器が描画され、そのあとに/api/product/attributesへのリクエストが表を埋める。クローラーは器のところで止まる。
3. 03価格と在庫を意図的にクライアント側に置いている。 キャッシュの観点では理にかなっている。だが機械可視性にとっては致命的だ。在庫が見えないモデルは、その部品を推薦しないからである。
4. 04タブやアコーディオンが中身の読み込みを先送りしている。 データシート、アプリケーションノート、適合証明書、CADリンクは、クリック時に読み込まれることが多い。クローラーはクリックしない。
5. 05ページネーションを無限スクロールで置き換えている。 51件目以降の製品には、クロール可能なURLがそもそも存在しない。

Partsgraphは2026年8月、北米・欧州・アジアにわたる世界984社のディストリビューターおよびメーカーのドメインを監査した。AI可視性スコアの中央値は100点満点中50点であり、対象群の70%がDまたはFの評価だった。およそ半数は、標準的な非ブラウザクライアントに対して、読めるカタログページを1ページも提供できなかった。もっとも弱かったセグメントは電子部品流通で、中央値は34だった。

AIクローラーが自社カタログを読めるかを、どう確かめるか

これは自社のオリジンに対して実施すること。クローラーのユーザーエージェントを偽装して競合サイトを試すと、誤った陰性の結果が出る。エンタープライズ向けのボット管理製品は、ユーザーエージェント文字列ではなく送信元IPでクローラーを検証しているからだ。見知らぬアドレスから届いた偽装ヘッダーは、robots.txtに何と書かれていようとチャレンジを受ける。

1. 01生のHTMLを取得する。 自社でもっとも価値の高い製品ページを一つ選ぶ。

curl -sS --compressed -o page.html -w "status=%{http_code} bytes=%{size_download}" "https://example.com/products/part-number"

1. 01バイト列の中に型番があるか探す。 ブラウザの中ではなく、ファイルの中を見ること。

grep -c "MPN-12345" page.html

ここで0が返るなら、そのページがその部品について書かれたページであることを、どのAIクローラーも識別できない。

1. 01パラメトリック値を三つ探す。 エンジニアなら絞り込みに使うだろう、と考えられる項目を選ぶ。

grep -oiE "operating temperature|tolerance|package|rohs|lifecycle" page.html | sort | uniq -c

1. 01構造化データのブロック数を数える。

grep -c "application/ld+json" page.html

ゼロなら、機械可読な製品レコードは存在しない。1件以上あるなら、それを取り出したうえで、単なるパンくずリストではなく、sku、mpn、gtin、brand、offers、そして自社にとって重要なadditionalPropertyの項目を実際に含んでいるかを検証すべきだ。

1. 01レンダリング後のページと突き合わせる。 JavaScriptを無効にしたブラウザで同じURLを開く。そこに残るものが、おおよそクローラーの受け取るものだ。それと通常のページとの差分こそが、自社の見えていない部分である。

1. 011ページではなく、経路全体を確認する。 カテゴリーページ、検索結果ページ、データシートのリンク、CADのダウンロードについても同じ手順を繰り返すこと。製品ページを読めても、クロール可能なカテゴリー一覧からそこへたどり着けないクローラーは、やはり行き詰まったままである。

合格するページでは、型番が数十回出現し、パラメトリック項目のラベルがテキストとして存在し、JSON-LDのブロックが少なくとも一つある。目安として、よくできた製品ページは完全な仕様表を含む60〜200KBのHTMLを返す。壊れたSPAの器は、バンドル参照しか含まない4〜15KBを返す。

サイトを作り直さずに直すには

基盤を入れ替える必要はない。必要なのは、オリジンが返すバイト列の中に事実が含まれていることだ。方法は四つあり、互いに排他ではない。

製品ルートとカテゴリールートのサーバーサイドレンダリングが、持続する答えである。すでに対応しているフレームワークを使っているなら、カタログのルートをサーバーコンポーネントや、増分再検証つきの静的生成へ移すのは、四半期単位ではなく数週間単位の作業で済むことが多い。データ層はすでに存在しており、ただ間違った側から呼ばれているだけだからだ。

プリレンダリングは、率直なつなぎの手段だ。各製品ページをビルド時あるいは定期実行で一度描画し、そのHTMLをエッジにキャッシュして、すべての相手に返す。人間にも機械にも同じドキュメントを返すこと。クローラーにだけ別のページを見せるクローキングは、ポリシー上のリスクであると同時に、実務上は自滅的でもある。モデルは、自分が受け取ったほうのバージョンを引用するからだ。

サーバーサイドでレンダリングするJSON-LDは、小さな労力でもっとも効果の大きい変更である。タグマネージャーの中ではなく、サーバーが出力するHTMLの中に置くこと。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "sku": "MPN-12345",
  "mpn": "MPN-12345",
  "name": "100 nF 50 V X7R 0603 ceramic capacitor",
  "brand": { "@type": "Brand", "name": "Example Components" },
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Capacitance", "value": "100 nF" },
    { "@type": "PropertyValue", "name": "Voltage rating", "value": "50 V" },
    { "@type": "PropertyValue", "name": "Dielectric", "value": "X7R" },
    { "@type": "PropertyValue", "name": "Operating temperature", "value": "-55 to +125 C" }
  ],
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "0.042",
    "availability": "https://schema.org/InStock"
  }
}
</script>

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. 01主力製品10点に対して、上記の6ステップのテストを実行し、バイト数を記録する。
2. 02製品ページのJSON-LDをサーバーサイドでレンダリングする。変更としてはもっとも小さく、計測できる効果はもっとも大きい。
3. 03すべての仕様、データシートのリンク、CADのリンクを、初期HTMLの中に存在させる。インタラクティブ版はクライアント側のままでも構わない。
4. 04意味のあるパラメトリックフィルターの組み合わせすべてに、実在する、クロール可能な、サーバーサイドレンダリング済みのURLを与える。
5. 05製品ごとにMarkdownミラーを公開し、そのページからリンクする。
6. 06順位やプロンプト、回答シェアを気にするのは、そのあとでよい。引用の前に、まず取得がある。コンテンツがレスポンスボディの中に存在しない限り、最適化すべき対象そのものが存在しない。

ここで働いている仕組みは、微妙なものでもなければ、論争の的でもない。モデルは自分が受け取ったものしか引用できない。そして受け取ったものとは、あなたの生のHTMLである。それ以外はすべて、実行されなかったレンダリングの工程にすぎない。

自社のカタログがどの位置にあるかを知りたい方へ。無償のPartsgraph AI可視性グレーダーが、本記事のチェック項目をあなた自身のドメインに対して実行します。[/audit](/audit)からどうぞ。