なぜAIは自社のデータシートを読めないのか

結論から先に

データシートがAIから見えなくなる経路は四つあり、そのいずれもごくありふれたものだ。ボットルール、ログイン、インタースティシャルによって、取得される前にファイルが遮断される。ファイルがテキスト層を持たないスキャン画像で、抽出しても文字数がゼロになる。直接のURLがなく、JavaScriptビューア経由でしか文書に到達できない。あるいはPDFが別のドキュメント配信ホスト——docs.、media.、DAM、CDN——に置かれており、メインサイトがどれほど寛容であろうと、そのホスト自身のrobots.txtやWAFが拒否している。

どれも特殊な話ではない。四つとも一般的であり、そのうち一つでも該当すれば十分である。その帰結は、はっきり述べておく価値がある。

データシートこそが正式な仕様書であり、製品ページはその要約にすぎない。AIが要約は読めても原典を読めないとき、AIは要約に基づいて技術的な問いに答える——そして間違える。

ここでWebページよりデータシートが重要になる理由

製品ページが載せている属性は、せいぜい8〜20項目だろう。パッケージ、主要定格、ライフサイクル表示、価格、在庫といったところである。対してデータシートは数百の項目を担う。絶対最大定格、温度全域にわたる電気的特性、タイミングチャート、端子説明、熱抵抗値、推奨フットプリント、耐湿性レベル、発注型番のデコーダ。エンジニアがアシスタントに実際に投げかける問い——5.5 Vで動作させられるか、85度における静止電流はいくらか、置き換える部品とピン配置に互換性があるか——は、そのほとんどがデータシートにしか答えを持たない。

この点の重要性は、以前より増している。問いが自社サイトの検索窓に入力されるのではなく、アシスタントに向けられるようになったからだ。Forresterは2026年1月に、法人バイヤーの94%がすでに購買プロセスでAIを利用していることを明らかにした。しかも、技術的な深さを最も多く抱えるページこそが、最も成績が悪い。Adobeが2026年4月に公表した小売サイトの機械可読性の分析では、製品詳細ページのスコアは66%と、あらゆるページ種別の中で最下位であり、ホームページの75%やFAQページの80%を下回った。

元となるデータに到達できないとき、起きるのは沈黙ではなく、自信に満ちた誤りである。OpenAIは2026年3月、稼働中の加盟店が約30社という段階でChatGPTのInstant Checkoutを縮小したが、その中心的な理由が製品データの不正確さだった。OpenAIは製品情報を得るために小売サイトをスクレイピングしており、在庫、配送、価格のデータが頻繁に誤っていたのである。これは最大定格を取り違えるのとまったく同じ故障モードであり、ただ賭け金が小さいだけだ。

データシートが読めなくなる五つの経路

五つ目は、最も自業自得の度合いが高い。短命な署名付きURL、「登録してダウンロード」のゲート、ワンタイムトークンは、いずれも目に見えない壁である。クローラーはセッションもCookieも持たず、フォームに入力する振る舞いもしない。さらにAIクローラーはJavaScriptを実行しないため、スクリプトによってDOMに書き込まれるダウンロードリンクは、通信の向こう側からは端的に存在しないのと同じである。

自社のデータシートが読めるかどうかを、どう確かめるか

三つのコマンドで決着がつく。自社の文書に対して実行してほしい。

1. 01取得を確かめる。 そのURLは、ブラウザではない素のクライアントに対してPDFを返すか。

curl -sSIL "https://example.com/datasheets/part-12345.pdf" | grep -iE "^HTTP|content-type|content-length"

最終的に 200 と content-type: application/pdf が返るのが正解である。content-type: text/html であれば、渡されたのはダウンロードを装ったチャレンジページかログインページだ。

1. 01ダウンロードして、本当にPDFかを確かめる。

curl -sSL -o ds.pdf "https://example.com/datasheets/part-12345.pdf" -w "status=%{http_code} type=%{content_type} bytes=%{size_download}"
head -c 5 ds.pdf

先頭5バイトは必ず %PDF- でなければならない。<!DOC であれば、ダウンロードしたのはエラーページである。

1. 01テキスト層を検査する。 これは、誰も実行していない一手である。

pdftotext -q ds.pdf - | tr -d '[:space:]' | wc -c
pdffonts ds.pdf

PDFにテキスト層があるかどうかを、どう見分けるか

見るべきは二つの数字であり、その差は紛れようがない。私たちは、実在するメーカーの現行データシート——Texas InstrumentsのLM358、4.15 MBのPDF——と、同じ文書をラスタライズした複製の両方に対して、この二つのテストを実行した。後者は、スキャンされた旧世代のデータシートが機械からどう見えるかを、そのまま再現したものである。

診断はこれで全部である。抽出できる文字数がゼロ、埋め込みフォントもゼロなら、そのファイルにテキストは存在しない。あるのはテキストの絵だけだ。 その文書は人間には完璧に表示されるが、モデルには文字どおり何も与えない。いまも生産が続く部品について、1990年代にスキャンされたデータシートは、インターネット上のあらゆるAIシステムにとって白紙である。

知っておく価値のある補足が二つある。文字数がゼロではないものの極端に少ない場合——たとえば40ページの文書で数百文字——は、たいてい本文がスキャン画像で、ヘッダーだけがテキストになっている状態であり、これも同じく使い物にならない。もう一つ、pdffonts の出力では uni 列が重要である。ToUnicodeマップを持たないサブセットフォントは、技術的には文字が存在していても、抽出すると文字化けになることがある。文字数だけを信用せず、抽出したテキストの先頭200文字を実際に目視で確かめてほしい。

ライブラリ全体を一括で検査するには、ループさせる。

while read -r url; do
  code=$(curl -sSL -o /tmp/d.pdf -w "%{http_code}" --max-time 30 "$url")
  chars=$(pdftotext -q /tmp/d.pdf - 2>/dev/null | tr -d '[:space:]' | wc -c)
  echo "$code $chars $url"
done < datasheet-urls.txt

出力を文字数の昇順で並べ替える。そのリストの上位にあるものはすべて、自社の製品データに空いた穴である。

別ホストという落とし穴

これは大企業をほぼ例外なく捕らえる。物事を正しく進めた結果として生じるからだ。文書はDAM、ドキュメント用サブドメイン、あるいはCDNへと移されるが、そのいずれもが独自の設定を持つ別個のオリジンであり、多くの場合は所管する部門すら別である。

RFC 9309において、robots.txtの適用範囲は単一のオリジン、すなわちスキーム、ホスト、ポートの組に限定される。https://www.example.com/robots.txt は https://docs.example.com/ にも https://cdn.example-media.net/ にも、一切の効力を持たない。メインサイトがAIクローラーを歓迎していても、文書を配信するホストが一律の Disallow: / を含むデフォルトのテンプレートから立ち上げられていたり、人間以外のすべてにチャレンジを課す設定のボットマネージャーの背後にあったりすれば、マーケティングサイトが全開である一方で、技術文書ライブラリは丸ごと暗闇の中にある。

文書を配信しているオリジンは、そのすべてを確認すること。

for h in www.example.com docs.example.com cdn.example-media.net; do
  echo "--- $h"
  curl -sS --max-time 15 "https://$h/robots.txt" | head -30
done

正しく公開されている状態とは

正しく公開されたデータシートは、まったく面白みがない。そこが肝心である。Texas Instrumentsは、LM358のデータシートを /lit/ds/ 配下の安定した、推測もできるURLで配信している。robots.txtはそのパスに何の制限も課していない。ファイルは、GPTBotを名乗るブラウザ以外のクライアントに対して、content-type: application/pdf とともに 200 を返す。そしてPDFには、Unicodeマッピング済みの埋め込みフォントを備えた完全なテキスト層がある。ログインもビューアも署名付きURLもインタースティシャルもない。世界中のどの抽出パイプラインでも読み取れる。

電子部品業界の流れは、これをさらに容易にする方向へ向かっている。Microchipは2025年11月、仕様、データシート、在庫、価格、リードタイムといった自社の製品データ向けに、認証不要かつ無料のMCPサーバーを公開した。ECIAのTrustedPartsは2026年6月、正規代理店の在庫状況をCopilot、ChatGPT、Claudeへ公開する在庫AIエージェントサービスを開始した。どちらも同じ認識に立っている。機械が読むために戦わなければならない文書は、負ける文書だということだ。

どう直せばよいのか

労力に対する効果が大きい順に挙げる。

1. 01文書のパスの遮断を解除する。 /datasheets/*、/lit/*、/documents/* およびそれに相当するパスで、robots.txtだけでなくWAFでもAIクローラーを許可する。この二つは別々のスイッチであり、両方を設定しなければならない。
2. 02公開している技術文書からダウンロードゲートを外す。 データシートが公開サイトに置かれている時点で、それはすでに公開情報である。登録フォームが止めるのは、自社を推薦してくれたはずの機械だけだ。
3. 03画像のみのPDFはすべてOCRし、テキスト層を付けて再公開する。 優先順位は文書の古さではなく、部品の売上高で決める。300 dpiのきれいなスキャンであれば、現代のOCRは本文についてはほぼ無損失である。パラメータ表だけは人手で検証すること。
4. 04すべての文書に、安定した、直接リンクできるURLを与える。 blobもビューアも、期限切れするトークンも、?token= のクエリ文字列も使わない。
5. 05各データシートのHTMLまたはmarkdown版の双子を公開する。 仕様表は本物の表として記述する。これは単独で最も効果の大きい変更である。PDFのレイアウト推測への依存を完全に取り除き、しかも正確性を監視できるページが手に入るからだ。
6. 06サーバーレンダリングされたHTMLの中で、製品ページから文書へ相互リンクを張る。 そうすれば、ページに到達したクローラーは、何も実行することなく文書へ到達できる。
7. 07抽出したパラメータを構造化データとして公開する。 ページ上のJSON-LD、できればクエリ可能なエンドポイントも用意する。そうすればエージェントは、毎回PDFを解析し直す代わりに、それらの値で絞り込める。

Partsgraphは2026年8月、北米、欧州、アジアにまたがる世界984の代理店・メーカードメインを監査した。AI可視性スコアの中央値は100点満点中50点で、対象の70%がD評価またはF評価だった。スコアの構成要素の中で一貫して最も弱かったのが、文書の層である。38%は、標準的なブラウザ以外のクライアントに対して、読み取れるカタログページを一枚も配信できなかった。文書へのアクセスは、ページへのアクセスよりも高い頻度で失敗していた。

厄介なのは、これらが一つとしてアクセス解析に現れないことだ。遮断されたクローラーはバグ報告を出さないし、質の悪いOCRは例外を投げない。データシートを読めなかったモデルも、読めなかったという事実をバイヤーに伝えない。ただ、PDFが開いた競合他社を推薦するだけである。

これらのテストに照らして自社の文書ライブラリを確かめたい場合は、[/audit](/audit) にある無料のPartsgraph AI可視性グレーダーを利用してほしい。