# なぜAIは自社のデータシートを読めないのか > ボットによる遮断、テキスト層のない画像スキャン、ビューア専用の文書、別ホストでの配信——データシートがAIから見えなくなる原因はこの四つである。実際のPDFと画像スキャンの実測値を示しながら、三つのコマンドで自社の文書を検査する方法と、効果の大きい順に並べた七つの修正手順を解説する。 **Language:** ja **Published:** 2026-08-09 **Category:** Technical · **Tags:** datasheets, PDF, AI crawlers, product data, technical documentation, OCR **Canonical:** https://partsgraph.ai/ja/blog/why-ai-cannot-read-your-datasheets ## 要点 **AIアシスタントが自社製品のデータシートを読めないのはなぜか** AIにとってデータシートを壊す要因は四つある。クローラーが取得する前に、PDFがボット遮断やログインによって阻まれている。ファイルがテキスト層を持たない画像のみのスキャンで、抽出しても文字数がゼロになる。文書がJavaScriptビューアに閉じ込められ、ファイルへの直接URLが存在しない。あるいは、robots.txtが拒否している別のドキュメント配信ホストに置かれている。このうち一つでも当てはまれば、その部品について確定的な仕様には到達できなくなる。そして仕様が実際に記されているのはデータシートであり、Webページが載せているのは常にその要約にすぎない。 --- ## 結論から先に データシートがAIから見えなくなる経路は四つあり、そのいずれもごくありふれたものだ。ボットルール、ログイン、インタースティシャルによって、取得される前にファイルが遮断される。ファイルがテキスト層を持たないスキャン画像で、抽出しても文字数がゼロになる。直接のURLがなく、JavaScriptビューア経由でしか文書に到達できない。あるいはPDFが別のドキュメント配信ホスト——`docs.`、`media.`、DAM、CDN——に置かれており、メインサイトがどれほど寛容であろうと、そのホスト自身のrobots.txtやWAFが拒否している。 > **Figure.** The four ways a datasheet becomes invisible to AI: blocked before fetch, scanned with no text layer, viewer-only with no direct URL, or on a separate host that refuses. どれも特殊な話ではない。四つとも一般的であり、そのうち一つでも該当すれば十分である。その帰結は、はっきり述べておく価値がある。 > データシートこそが正式な仕様書であり、製品ページはその要約にすぎない。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は製品情報を得るために小売サイトをスクレイピングしており、在庫、配送、価格のデータが頻繁に誤っていたのである。これは最大定格を取り違えるのとまったく同じ故障モードであり、ただ賭け金が小さいだけだ。 ## データシートが読めなくなる五つの経路 | 障害 | クローラーに見えるもの | 見分け方 | |---|---|---| | ボット遮断 | PDFではなく403、429、またはHTMLのチャレンジページ | レスポンスの `content-type` が `application/pdf` ではなく `text/html` | | 画像のみのスキャン | 抽出できるテキストを一切含まない、形式上は正常なPDF | テキスト抽出の文字数が0、埋め込みフォントもなし | | ビューア専用の文書 | ファイルのURLを持たないJavaScriptだらけのページ | PDFがblobまたは認証付きストリームから読み込まれる | | 別ホストのポリシー | 製品ページは正常な200、文書は遮断 | 文書を配信するホストが独自のrobots.txtとWAFを持つ | | 一時的URL・ゲート付きURL | 期限切れする署名付きリンク、またはフォームによるゲート | ブラウザでは開けるのに `curl` からは403が返る | 五つ目は、最も自業自得の度合いが高い。短命な署名付きURL、「登録してダウンロード」のゲート、ワンタイムトークンは、いずれも目に見えない壁である。クローラーはセッションもCookieも持たず、フォームに入力する振る舞いもしない。さらにAIクローラーはJavaScriptを実行しないため、スクリプトによってDOMに書き込まれるダウンロードリンクは、通信の向こう側からは端的に存在しないのと同じである。 ## 自社のデータシートが読めるかどうかを、どう確かめるか 三つのコマンドで決着がつく。自社の文書に対して実行してほしい。 1. **取得を確かめる。** その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` であれば、渡されたのはダウンロードを装ったチャレンジページかログインページだ。 2. **ダウンロードして、本当に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-` でなければならない。`/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. **文書のパスの遮断を解除する。** `/datasheets/*`、`/lit/*`、`/documents/*` およびそれに相当するパスで、robots.txtだけでなくWAFでもAIクローラーを許可する。この二つは別々のスイッチであり、両方を設定しなければならない。 2. **公開している技術文書からダウンロードゲートを外す。** データシートが公開サイトに置かれている時点で、それはすでに公開情報である。登録フォームが止めるのは、自社を推薦してくれたはずの機械だけだ。 3. **画像のみのPDFはすべてOCRし、テキスト層を付けて再公開する。** 優先順位は文書の古さではなく、部品の売上高で決める。300 dpiのきれいなスキャンであれば、現代のOCRは本文についてはほぼ無損失である。パラメータ表だけは人手で検証すること。 4. **すべての文書に、安定した、直接リンクできるURLを与える。** blobもビューアも、期限切れするトークンも、`?token=` のクエリ文字列も使わない。 5. **各データシートのHTMLまたはmarkdown版の双子を公開する。** 仕様表は本物の表として記述する。これは単独で最も効果の大きい変更である。PDFのレイアウト推測への依存を完全に取り除き、しかも正確性を監視できるページが手に入るからだ。 6. **サーバーレンダリングされたHTMLの中で、製品ページから文書へ相互リンクを張る。** そうすれば、ページに到達したクローラーは、何も実行することなく文書へ到達できる。 7. **抽出したパラメータを構造化データとして公開する。** ページ上のJSON-LD、できればクエリ可能なエンドポイントも用意する。そうすればエージェントは、毎回PDFを解析し直す代わりに、それらの値で絞り込める。 Partsgraphは2026年8月、北米、欧州、アジアにまたがる世界984の代理店・メーカードメインを監査した。AI可視性スコアの中央値は100点満点中50点で、対象の70%がD評価またはF評価だった。スコアの構成要素の中で一貫して最も弱かったのが、文書の層である。38%は、標準的なブラウザ以外のクライアントに対して、読み取れるカタログページを一枚も配信できなかった。文書へのアクセスは、ページへのアクセスよりも高い頻度で失敗していた。 厄介なのは、これらが一つとしてアクセス解析に現れないことだ。遮断されたクローラーはバグ報告を出さないし、質の悪いOCRは例外を投げない。データシートを読めなかったモデルも、読めなかったという事実をバイヤーに伝えない。ただ、PDFが開いた競合他社を推薦するだけである。 *これらのテストに照らして自社の文書ライブラリを確かめたい場合は、[/audit](/audit) にある無料のPartsgraph AI可視性グレーダーを利用してほしい。* ## よくある質問 ### そもそもAIクローラーはPDFを読めるのか 取得はできるし、PDFのテキスト抽出は取り込みパイプラインの標準的な工程である。できないのは、ファイルに存在しないテキストを作り出すことだ。抽出処理が読むのはテキスト層である。PDFがテキスト層を持たないスキャン画像であれば、抽出結果は空になり、その文書は何も寄与しない。 ### PDFにテキスト層があるかどうかは、どう判別するのか そのファイルに対してpdftotextを実行して返ってきた文字数を数え、次にpdffontsを実行して行数を数える。健全なデータシートなら数万文字と、長い埋め込みフォントの一覧が返る。画像のみのスキャンでは、文字数もフォント数もゼロである。 ### 自社のデータシートは別のドキュメント用サブドメインにあるが、それは問題になるのか なる。RFC 9309において、robots.txtの適用範囲はスキーム、ホスト、ポートからなる単一のオリジンに限定される。www.example.com に置かれた寛容なrobots.txtは、docs.example.com にもCDNのホスト名にも、何ら許可を与えない。文書を配信するオリジンにはそれぞれ独自のポリシーが必要であり、そのそれぞれが個別にWAFのルールの適用対象にもなる。 ### データシートの内容をHTMLとしてWebページに載せるべきか 載せるべきであり、たいていの場合これが最も費用対効果の高い対策である。各データシートのHTMLまたはmarkdown版の双子——仕様表、絶対最大定格、端子説明、発注情報——は、解析もキャッシュも引用も容易だ。しかも、PDFの抽出処理が自社のレイアウトをどれだけうまく扱えるかという不確実性を、完全に取り除ける。 ### 文書を配信するホストでボットを遮断すれば、自社の知的財産を守れるのか 守れるのは、たいていの場合「推薦されること」からである。データシートはすでにアグリゲーター各社にミラーリングされているため、クローラーを遮断しても学習コーパスから内容が消えることはめったにない。モデルが目にするのが、自社の最新リビジョンではなく第三者の古い複製になるだけである。統制が目的であれば、正本となる文書を配信し、その正確性を監視することだ。 ### 多段組みのレイアウトや表は、抽出後も保たれるのか 完全には保たれない。二段組みのデータシートのレイアウトは、線形に抽出すると本文が交互に入り混じりがちであり、セルを結合したパラメータ表は行の構造を失う。正しい読み上げ順序を持つタグ付きPDFはかなり助けになるが、同じ表をHTMLまたはmarkdownでミラーすれば、曖昧さは完全になくなる。 ### データシートは何点テストすべきか まずトラフィック上位20点をテストし、その後スクリプトでライブラリ全体を一括検査する。私たちの経験では、不具合は製造年代ごと、そして作成ツールごとに固まって現れる。そのため、最近の部品だけを対象にしたサンプルでは、ライブラリの実態よりもはるかに健全に見えてしまう。 ## 出典 1. [Adobe Digital Insights, AI traffic and retail machine-readability, April 2026](https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable) 2. [eCommerceNews, Adobe machine-readability scores by page type, April 2026](https://e-commerce.news/story/adobe-says-ai-retail-traffic-surges-as-readability-lags) 3. [CNBC, OpenAI revamps shopping in ChatGPT after Instant Checkout, March 2026](https://www.cnbc.com/2026/03/24/openai-revamps-shopping-experience-in-chatgpt-after-instant-checkout.html) 4. [Forrester, The State Of Business Buying, 2026 (January 2026)](https://www.forrester.com/blogs/state-of-business-buying-2026/) 5. [Vercel and MERJ, The rise of the AI crawler, December 2024](https://vercel.com/blog/the-rise-of-the-ai-crawler) 6. [RFC 9309, Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html) 7. [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) 8. [ECIA, TrustedParts.com launches Inventory AI Agent Service, June 2026](https://www.ecianow.org/2026/06/11/trustedparts-com-launches-inventory-ai-agent-service/) 9. [Texas Instruments, LM358 datasheet (used as a worked example)](https://www.ti.com/lit/ds/symlink/lm358.pdf) ## Other languages - English: https://partsgraph.ai/blog/why-ai-cannot-read-your-datasheets/md - Deutsch: https://partsgraph.ai/de/blog/why-ai-cannot-read-your-datasheets/md - Français: https://partsgraph.ai/fr/blog/why-ai-cannot-read-your-datasheets/md - Español: https://partsgraph.ai/es/blog/why-ai-cannot-read-your-datasheets/md - Italiano: https://partsgraph.ai/it/blog/why-ai-cannot-read-your-datasheets/md - Nederlands: https://partsgraph.ai/nl/blog/why-ai-cannot-read-your-datasheets/md - Polski: https://partsgraph.ai/pl/blog/why-ai-cannot-read-your-datasheets/md - Português: https://partsgraph.ai/pt/blog/why-ai-cannot-read-your-datasheets/md - Svenska: https://partsgraph.ai/sv/blog/why-ai-cannot-read-your-datasheets/md - Türkçe: https://partsgraph.ai/tr/blog/why-ai-cannot-read-your-datasheets/md - 한국어: https://partsgraph.ai/ko/blog/why-ai-cannot-read-your-datasheets/md - 简体中文: https://partsgraph.ai/zh/blog/why-ai-cannot-read-your-datasheets/md --- Partsgraph — the agent-ready parts data layer. Free AI-visibility grader: https://partsgraph.ai/ja/audit