PDF資料がAI検索で引用されない理由と対策｜HTML化5手順【2026年版】

PDF資料がAI検索で引用されない理由と対策｜HTML化5手順【2026年版】

この記事の結論: PDFホワイトペーパーがAIに引用されないのは中身が悪いからではなく、①バイナリ形式 ②フォームゲート ③単一長大ドキュメントという3つの「形式の問題」が同時に効いているからです。PDFを廃止する必要はありません。原本PDFはゲート層に残したまま、その中身を要点HTMLとして開放する「二層設計」に組み替え、Link ヘッダーのcanonicalと X-Robots-Tag で重複を殺す。これが2026年8月時点で最も費用対効果の高い打ち手です。

最終更新日: 2026年8月30日

はじめに

BtoBマーケティングで積み上げてきたPDFホワイトペーパーは、AI検索時代において「資産」ではなく「死蔵在庫」になりかけています。株式会社Wallabeeが運営するOptyino.aiの調査（2026年7月19日発表）では、生成AIの引用25,001件のうちホワイトペーパー本体が引用されたのはわずか99件、**引用率0.4%**でした。一方で、導入事例・調査レポート・会社案内などを含む「資料型コンテンツ全体」の引用率は22.3%（5,586件）。同じ会社が作った、同じ品質の情報が、形式の違いだけで約56倍の差を生んでいます。

この記事は「PDFをやめましょう」という話ではありません。PDFは商談の場でも社内稟議でも今なお必要な形式であり、廃止はむしろ営業機能の毀損です。必要なのは、AIクローラーが到達できる層と、リード獲得のためにゲートをかける層を意図的に分けること。本記事では、その分離を5つの手順に落とし込み、実際にサーバー設定へ貼れる設定コードまで含めて解説します。

想定読者はBtoB企業のマーケティング担当者、オウンドメディア運営者、およびその実装を担う開発者です。すべての数値は本文中に出典を明記しており、当サイトの独自測定結果は含みません。実装判断のための「棚卸しシート」「線引き基準表」は雛形として提供するので、そのまま自社のPDF資産に当てはめて使えます。

PDF資料がAI検索で引用されない3つの構造的理由（Googleインデックスとは別レイヤーの話）

結論から言えば、PDFが引用されない原因は「読めない・届かない・切り出せない」の3つに分解できます。 そして重要なのは、この3つがGoogleの通常検索インデックスの話とは別レイヤーで起きているという点です。「うちのPDFはGoogle検索に出ているから大丈夫」という認識が、最も危険な誤解です。

理由①：バイナリ形式であり、AIが扱う中間表現への変換で情報が壊れる

PDFは「紙の見た目を固定するための形式」であり、意味構造を保持する形式ではありません。 HTMLには <h2> が見出しであるという意味情報が埋め込まれていますが、PDFにおける見出しは多くの場合「16ptの太字で配置された文字列」でしかありません。抽出時に本文と区別できず、フラットなテキストの塊になります。

さらに深刻なのが多段組・図表・注釈のレイアウト崩れです。2段組のPDFをテキスト抽出すると、左段の1行目と右段の1行目が連結された無意味な文字列が生成されることがあります。AI側は「引用しても意味が通らない断片」しか得られないため、回答生成の材料として選ばれません。スキャン画像をPDF化しただけの資料に至っては、テキストレイヤーが存在しないため抽出対象にすらなりません。

理由②：フォームゲートの向こう側にはクローラーが到達できない

リード獲得のためのフォームは、AIクローラーにとって完全な壁です。 クローラーは氏名やメールアドレスを入力して送信ボタンを押すことができません。したがって、ダウンロードURLがフォーム送信後にしか発行されない設計になっている限り、その資料は「Web上に存在しないファイル」と同義です。

これは推測ではなく実測でも裏付けられています。Search Engine Landが2026年8月19日に公開した41日間の統制実験（約2,400ページ、ボットリクエスト30,180件）では、GPTBot・ClaudeBot・Meta-ExternalAgent・Amazonbot はJavaScriptで注入されたリンクへの到達数が0件でした。JavaScript実行能力を持つGooglebotですら到達率は2%にとどまっています。つまり「クリック後にJSでダウンロードURLを生成する」タイプの資料DLボタンは、AIから見れば存在しないのと同じです。詳細はJavaScriptナビゲーションがAIクローラーから不可視になる問題で扱っています。

理由③：単一長大ドキュメントは、AIが求める「粒度」と合わない

AIは記事1本を丸ごと引用するのではなく、質問に対応する数百文字のパッセージを引用します。 40ページのホワイトペーパーは、この粒度と根本的に噛み合いません。1つのURLに40ページ分の話題が詰め込まれていると、特定の質問に対する関連度スコアが希釈され、より焦点の絞られた競合ページに負けます。

加えて、PDFにはHTMLの #section に相当するアンカーが実質的に機能しないため、AIが「この資料の12ページ目の表」を引用元として提示することができません。引用先URLを示せない情報源は、出典明示を前提とするAI検索エンジンにとって使いにくい素材です。

前提整理：Googleは「PDFをインデックスできる」——だがそれは引用の保証ではない

Googleは公式に、PDFを "encoded document" としてインデックス対象のファイル形式に含めています。 つまり「PDFはクロールされない」というのは誤りです。しかし、インデックスされることと、生成AIの回答内で引用されることは別の事象です。

さらに、OpenAIは公式ドキュメントで3種類のクローラーを明確に区別しています。この区別を理解していないと、robots.txtの1行で自社のAI露出を全部止めるという事故が起きます。

注意点として、OpenAIは ChatGPT-User についてrobots.txtが適用されない場合があると明記しています。「学習はさせたくないが検索露出は取りたい」という一般的なBtoBの要求を満たすには、GPTBotのみを拒否しOAI-SearchBotを許可する分離設計が必要です。この設計思想は学習用ボットと検索用ボットを分けるrobots.txt戦略とAIクローラーのrobots.txt・インデックス戦略で詳述しています。

引用率0.4% vs 22.3%——56倍差が示す「形式が中身を殺す」構図

この56倍という差は、コンテンツの質ではなく流通形式が引用可否を決めていることを示す、現時点で最も強い定量的証拠です。 数字の内訳を正確に押さえておきましょう。

Optyino.aiの調査概要は以下の通りです（2026年7月19日発表）。

読み解くべきポイントは3つあります。

第一に、「資料型コンテンツ全体は22.3%」という事実が、AIが資料的な情報を嫌っているわけではないことを証明しています。 導入事例、調査レポート、会社案内といった資料型の情報は、しっかり引用されています。引用されていないのは「PDFのホワイトペーパー本体」という特定の器だけです。中身の需要はある。器が悪い。この構図が読み取れることが、この調査の最大の価値です。

第二に、商用ホワイトペーパーの0.1%（27件）という数字です。 ホワイトペーパー全体の0.4%からさらに1桁落ちています。商用ホワイトペーパーほどフォームゲートが厳しく設定されている実態を考えれば、これはゲートの効果を強く示唆します。マーケティング的に「価値が高い」と判断した資料ほど固く閉じ、結果としてAIから最も遠い場所に置いてしまっている、という皮肉な逆転が起きています。

第三に、意図別の引用率です。 導入判断の意図で21.8%、動向・将来の意図で20.2%、事例活用の意図で15.0%となっており、いずれの意図においても調査レポート型のコンテンツが最も引用されやすい傾向が示されています。つまりBtoBの購買検討プロセスの中心にある「導入判断」の場面で、AIは一次データを持つ調査レポート型の情報を求めているわけです。ホワイトペーパーの中身は多くの場合まさにそれなのに、形式が理由で選ばれていない。

この調査の詳しい解説はOptyino調査：ホワイトペーパー引用率の実態にまとめています。自社のPDF資産がこの構図のどこに位置しているかを短時間で把握したい場合は、無料のLLMO診断でサイト全体のAI可読性を確認するところから始めるのが手軽です。

なお、逆のケースも押さえておく必要があります。NotebookLMのようなクローズドRAG環境では、PDFはむしろ必須の入力形式です。ユーザーが自分でPDFをアップロードして質問する用途では、PDFの構造化された1ファイルという性質が有利に働きます。この違いはNotebookLMを前提にした引用戦略で整理しています。「オープンWebのAI検索」と「クローズドRAG」で最適な形式は逆になる、という前提を持っておくと判断を誤りません。

手順①②：PDF資産を4象限で棚卸しし、HTML化パターンを選ぶ

最初にやるべきは新しい記事を書くことではなく、既存PDFの現状把握です。 全社で50本のPDFがあっても、手をつけるべきは通常3〜5本です。棚卸しをせずに着手すると、引用も流入も生まない資料の変換に工数を溶かします。

手順①：ゲート有無 × テキスト有無の4象限に分類する

PDF資産は「ゲート型/オープン型」×「テキストPDF/スキャンPDF」の2軸4象限に置くと、打ち手が機械的に決まります。

分類には次の棚卸しシートを使ってください。スプレッドシートに以下の列を用意し、PDF1本につき1行で埋めていきます。

優先度のルールは単純です。 「一次データあり」かつ「対応検索意図が導入判断または動向将来」かつ「ゲートあり」の行から順に着手します。Optyino調査で引用率が高かった意図と、AIが求める一次データ性の両方を満たす資料が、変換したときに最も引用されやすいからです。逆に「DL数0・商談化0・二次情報のみ」の資料は、変換ではなく廃止候補として扱います。

手順②：HTML化の3パターンから、資料ごとに1つを選ぶ

HTML化には全文型・要点型・分割型の3パターンがあり、ページ数と一次データの有無で選び分けます。 全部を全文HTML化しようとすると破綻します。

判断フローは次の通りです。

1. ページ数が10以下なら パターンA。分割する意味がなく、1ページに集約したほうが評価も集まります。
2. ページ数が11〜29で、リード獲得（フォーム）を維持したいなら パターンB。オープン層とゲート層を分ける最小構成です。
3. ページ数が30以上で、章ごとに答えている問いが異なるなら パターンC。「市場動向」「導入手順」「コスト試算」が1本のPDFに同居しているなら、それは3本の記事です。
4. どのパターンでも、原本PDFは削除しない。営業現場と社内稟議で使われているため、URLを消すと別の実害が出ます。
5. パターンBとCを選んだ場合は、必ず次章のcanonical・X-Robots-Tag 設定までセットで実施します。ここを飛ばすと重複が発生します。

製造業のように仕様書・カタログPDFが大量にある業種では、パターンCの効果が特に大きくなります。業種別の具体像は製造業のBtoB LLMO実践を参照してください。

手順③：重複を作らない技術実装（canonical・X-Robots-Tag・sitemap・llms.txt）

HTMLとPDFが同じ内容で併存するとき、どちらを正規版とするかをサーバー側で明示する必要があります。 HTMLファイルなら <link rel="canonical"> を書けば済みますが、PDFはHTMLではないため <head> がありません。ここが実装上の最大のハマりどころです。

canonicalはHTTPレスポンスヘッダーで指定する

非HTML文書のcanonicalは、Link ヘッダー（RFC 5988）で指定します。 Googleが公式に示している記法は以下の形です。URLは絶対URLでなければなりません（相対パスは無効）。

Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"

実務では「PDFの正規版をHTMLページ側に寄せたい」ケースが多いはずです。その場合、PDFのレスポンスに対して要点HTMLページのURLを指すヘッダーを返します。

Apache（.htaccess またはVirtualHost）の設定例です。

# mod_headers が有効であること
<Files "white-paper-2026.pdf">
    Header set Link "<https://example.com/whitepapers/ai-search-2026>; rel=\"canonical\""
</Files>

nginx の設定例です。

location = /downloads/white-paper-2026.pdf {
    add_header Link '<https://example.com/whitepapers/ai-search-2026>; rel="canonical"';
}

canonicalそのものの考え方に不安がある場合はcanonical URLの用語解説を先に確認してください。なお、canonicalはあくまでヒントであり指示ではないため、HTML側の内容がPDFと大きく乖離していると無視されます。要点HTMLは原本の主要な結論と数値を必ず含めてください。

検索結果に出したくないPDFは X-Robots-Tag で止める

PDFに noindex を指定する方法は X-Robots-Tag レスポンスヘッダーしかありません。 meta robotsタグはHTMLの <head> にしか書けないため、非HTMLリソースには物理的に適用できません。これはGoogleが公式に明言している仕様です。

Apacheの設定例です。拡張子ベースで一括指定できます。

<Files ~ "\.pdf$">
    Header set X-Robots-Tag "noindex, nofollow"
</Files>

nginxの設定例です。

location ~* \.pdf$ {
    add_header X-Robots-Tag "noindex, nofollow";
}

ただし、この一括 noindex は劇薬です。 全PDFに適用すると、これまでPDF経由で獲得していた検索流入もゼロになります。適用すべきなのは次の場合に限ります。

• 要点HTML版を公開済みで、PDFは営業配布用にのみ残す場合
• 旧版・改訂前のPDFが検索結果に残り続けている場合
• 社内向け・限定配布資料が誤って公開ディレクトリに置かれている場合

逆に、要点HTMLをまだ作っていない段階でPDFを noindex にすると、単に露出を失うだけです。順序は「HTML公開 → canonical設定 → 必要ならnoindex」であり、逆順は事故です。

なお、同じ内容をHTMLとPDFの両方で公開すること自体は、SEO上の問題にはならないとされています（鈴木謙一氏）。重複コンテンツペナルティを恐れて過剰に noindex を撒く必要はありません。canonicalで正規版を示すだけで実務上は十分です。

sitemapを分離し、llms.txt の書き方を決める

HTMLページとPDFは別のsitemapファイルに分け、sitemap indexで束ねます。 こうしておくと、Search Consoleのカバレッジをsitemap単位で切り分けて確認でき、「PDFだけインデックスが落ちた」といった異常を検知しやすくなります。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-pdf.xml</loc>
  </sitemap>
</sitemapindex>

llms.txt については、「PDFのURLを書けばAIが読んでくれる」という期待は持たないでください。 llms.txt は2026年8月時点で主要AI事業者による公式採用が確認されていない提案仕様であり、記載したからといってPDFが解析されるようになるわけではありません。書くのであれば、PDFへの直リンクではなく要点HTMLページのURLを列挙するのが妥当です。llms.txt の位置づけと限界はllms.txt完全ガイドで整理しています。

実装チェックリスト

技術実装が完了したかどうかは、次のチェックリストで確認してください。すべて curl -I <URL> で検証できます。

• 要点HTMLページが200を返し、JavaScriptなしで本文が読める
• PDFのレスポンスに Link: <...>; rel="canonical" が絶対URLで入っている
• canonical先のHTMLが、PDF本文の主要な結論と数値を含んでいる
• noindex を付けたPDFは、要点HTML版が公開済みである
• X-Robots-Tag を全PDFに一括適用していない（残すべきPDFを巻き込んでいない）
• sitemapがHTML用とPDF用に分離され、sitemap indexから参照されている
• robots.txt で OAI-SearchBot を誤ってブロックしていない
• 要点HTMLへの導線が <a href> の静的リンクであり、JS生成でない
• PDFへの内部リンクのアンカーテキストが「こちら」「ダウンロード」になっていない
• llms.txt にPDF直リンクではなく要点HTMLのURLを記載している

手順④：リード獲得を落とさない「二層設計」

二層設計とは、同じ情報資産をオープン層とゲート層に意図的に分割し、AI引用とリード獲得を両立させる構成です。 「PDFを開放したらリードが取れなくなる」という懸念は正当ですが、全部を開放する必要はありません。

何をオープンにし、何をゲートに残すか

線引きの原則は「結論はオープン、実行の材料はゲート」です。 AIが引用したいのは結論と数値であり、ユーザーが対価（個人情報）を払ってでも欲しいのは自分の業務に落とし込むための材料です。この2つは別物なので、分離しても互いを食いません。

二層設計のページ構成テンプレート

オープン層のHTMLページは、次の7ブロック構成にすると引用されやすく、かつゲート層への導線も自然になります。

1. H1と結論ブロック：資料の最も重要な結論を最初の200字以内に置く。AIはここを抜き出す
2. 調査概要の表：期間・対象・サンプル数・手法を表形式で明示。一次データ性の証明になる
3. 主要な発見（H2×3〜5）：各H2の冒頭1〜2文を結論とし、その後に根拠を書く
4. 数値の表：本文中に散らばった数値を1つの表に集約。AIが構造を掴みやすい
5. 限界と注意点：調査の適用範囲外を明記。信頼性シグナルとして機能する
6. ゲート層への導線：「全設問の集計表と業界別クロス集計は資料（PDF）に収録」と具体的に書く
7. 原本PDFへの静的リンク：<a href> で直リンク。JS生成にしない

6番の書き方が二層設計の成否を決めます。 「詳しくは資料をダウンロード」では誰も押しません。「オープン層には無い、ゲート層にしか無いもの」を具体的に名指しすることで、初めてフォーム入力の動機が生まれます。オープン層で結論を出し切っているからこそ、その先にある材料の価値が明確になる、という構造です。

BtoBのリード獲得をAI検索時代の導線設計に組み替える全体像はBtoBのAI検索リード獲得設計で扱っています。棚卸しから二層設計への組み替えまでを自社だけでやり切るのが難しい場合は、LLMOコンサルティングで既存資産の分類と実装計画づくりから伴走できます。

手順⑤：どうしてもPDFを残す場合の最適化

HTML化が間に合わないPDFにも、抽出精度を上げるための最低限の手当てがあります。 ただしこれは「HTML化の代替」ではなく「HTML化までのつなぎ」です。優先順位を誤らないでください。

テキスト埋め込みとOCR検収

まず、PDFにテキストレイヤーが存在するかを確認します。 確認方法は単純で、PDFビューアで本文をドラッグ選択してコピーし、テキストエディタに貼り付けられるかを見るだけです。貼り付けられなければ画像PDFです。

Googleは2011年の公式記事で「PDF内の画像はインデックスされない」「テキストが画像として埋め込まれている場合、OCRで抽出することがある」と説明しています。ここで重要なのは「することがある（may）」という表現です。OCRは保証された処理ではありません。 依存すべきではないので、スキャンPDFは以下の手順で作り直します。

1. 元のWord・PowerPoint・InDesignデータが残っているか確認する。あればそこから再出力するのが最も確実
2. 原本データが無い場合のみOCRをかける。日本語は縦書き・ルビ・表組みで精度が落ちる
3. OCR結果を必ず人が検収する。特に数値、単位、企業名、日付を重点確認する
4. 検収後、テキストレイヤー付きPDFとして再出力し、元のURLを維持して差し替える

タイトルメタデータとアウトライン（しおり）

検索結果に表示されるPDFのタイトルは、ファイル内部のtitleメタデータと、そのPDFへの被リンクのアンカーテキストから決まります。 本文1行目や表紙のデザイン文字ではありません。ここを放置すると、検索結果に「Microsoft Word - 最終版_v3_修正.docx」といった内部ファイル名が表示されます。実際、こうした事故は珍しくありません。

アウトライン（しおり）の設定は、抽出時の章構造の手がかりになります。 Wordから出力する場合は「見出しスタイルを使って書き、PDF出力時にブックマークを作成するオプションを有効にする」だけで生成されます。手作業ではなくスタイル運用で担保してください。

PDF内のリンクはPageRankを渡します。 これもGoogleが2011年の記事で明言している挙動です。したがって、PDF内から自社の関連HTMLページへリンクを張ることには意味があります。逆に言えば、PDF内に生のURL文字列を書いているだけの状態は、リンクとして機能していない可能性があります。リンク注釈として正しく埋め込まれているかを確認してください。

効果測定：PDF資産のAI引用を追う3系統

AI引用の測定に単一の万能ツールは存在しません。 2026年8月時点では、カバー範囲の異なる3系統を組み合わせるのが現実的です。それぞれの取得可能項目と制約を正確に把握しておかないと、「データが無い」ではなく「見る場所を間違えている」という状態に陥ります。

①Search Console 生成AIパフォーマンスレポート

Googleの生成AI体験における表示回数を、公式データとして確認できる唯一の手段です。 2026年6月に発表され、2026年8月11日にグローバル展開されました。

ただし制約が厳しく、表示回数のみが開示され、クリック数とクエリは開示されません。 さらにSearch Console APIからも取得できず、管理画面からの手動エクスポートに限られます。したがって自動レポート化はできず、月次で手動取得してスプレッドシートに蓄積する運用が現実的です。PDFのURLと要点HTMLのURLを分けて記録し、HTML化後に表示回数がHTML側へ移っているかを追ってください。

②Bing Webmaster Tools「AI Performance」

Copilot系での引用を、ページ単位で追える点が最大の価値です。 2026年2月10日にパブリックプレビューとして提供が開始されました。Citations数、実際に引用されたページ、そしてGrounding Query（AIが内部的に検索した際のクエリ）が取得できます。

Grounding Queryは特に価値が高い情報です。 ユーザーの入力そのものではなく、AIが回答を組み立てるために内部生成したクエリが見えるため、「AIは自社のどの論点を調べに来ているか」が分かります。ここに現れるクエリと、自社の要点HTMLの見出しがズレている場合、見出しの書き換え候補になります。

③エッジログでのボット別リクエスト計測

「引用されたか」は分かりませんが、「到達できているか」は自社ログで確実に分かります。 CDNやリバースプロキシのアクセスログをUser-Agentでフィルタし、次の観点で集計します。

• GPTBot/1.4 OAI-SearchBot/1.4 ChatGPT-User/1.0 ClaudeBot などのボット別リクエスト数
• そのうち .pdf へのリクエストが占める割合とステータスコード
• 要点HTMLページへのリクエスト数（HTML化後に増えているか）
• 403・404が返っていないか（WAFがAIクローラーを弾いていないか）

403が返っている場合、それは技術的な引用不能状態です。 WAFやBot管理サービスがAIクローラーを既定でブロックしている構成は珍しくなく、robots.txtを整備しても意味がありません。ログを見て初めて発覚するタイプの問題なので、測定系の中では最も先に手を付ける価値があります。

集計の頻度は月次で十分です。HTML化の前後で①②③をそれぞれ比較し、「PDFのボット到達数が減り、要点HTMLの到達数と表示回数が増えている」状態になっていれば、二層設計が意図通り機能しています。

よくある質問

PDFはそもそもGoogleにインデックスされますか？

されます。GoogleはPDFを「encoded document」として正式にインデックス対象のファイル形式に含めており、検索結果にも表示されます。

「PDFはクロールされない」というのは誤解です。ただしインデックスされることと、生成AIの回答内で引用されることは別の話です。インデックス可能であっても、抽出精度・粒度・ゲートの3要因によって引用対象からは外れます。実際、Optyino調査でホワイトペーパー本体の引用率が0.4%にとどまっているのは、インデックス可否ではなく引用適性の問題です。

スキャンしたPDFはAIに読まれますか？OCRは必須ですか？

読まれない可能性が高く、OCRは事実上必須です。GoogleはOCR抽出を「することがある」と述べるにとどまり、実行を保証していません。

さらにGoogleは「PDF内の画像はインデックスされない」とも明言しています。スキャンPDFは全ページが画像であるため、テキストレイヤーが無ければ内容はゼロ扱いです。OCRをかける場合も、日本語は縦書き・ルビ・複雑な表組みで精度が落ちるため、数値・単位・企業名・日付の人手検収を必ず挟んでください。元のWordやPowerPointが残っているなら、OCRより再出力のほうが確実で速いです。

同じ内容をHTMLとPDFの両方で公開すると重複コンテンツになりますか？

なりません。同じコンテンツをHTMLとPDFの両方で公開してもSEO上の問題はないとされており、canonicalで正規版を示せば実務上も安全です。

鈴木謙一氏も同様の見解を示しています。重複ペナルティを恐れてPDFを一律 noindex にする対応は、多くの場合やりすぎです。正しい対応は、PDFのHTTPレスポンスに Link: <正規URL>; rel="canonical" を付与して評価を集約させることです。canonicalはヒントであり指示ではないため、HTML側がPDFの主要な結論と数値を含んでいることが前提になります。

PDFを検索結果に出したくない場合はどう設定すればよいですか？

meta robotsタグは使えません。HTTPレスポンスヘッダーの X-Robots-Tag: noindex をPDFに付与するのが唯一の正攻法です。

PDFには <head> が存在しないため、HTML用のmeta robotsは物理的に書き込めません。Apacheなら <Files ~ "\.pdf$"> ブロック、nginxなら location ~* \.pdf$ ブロックで X-Robots-Tag を設定します。ただし拡張子一括での適用は、これまでPDFで獲得していた検索流入も同時に失います。要点HTML版を公開してから適用する順序を守ってください。

PDF内のリンクはSEO評価（PageRank）を渡しますか？

渡します。GoogleはPDF内のリンクをHTMLのリンクと同様に扱い、PageRankを伝達すると2011年の公式記事で説明しています。

つまりPDFは被リンクの受け手であると同時に、送り手にもなれます。ホワイトペーパー内から自社の関連HTMLページへリンクを張る設計には意味があります。ただし、本文に生のURL文字列を書いているだけではリンク注釈として認識されない可能性があります。PDF生成時にクリック可能なリンクとして埋め込まれているかを確認してください。

ホワイトペーパーは廃止してすべてHTML記事に置き換えるべきですか？

いいえ。PDFは商談・社内稟議・オフライン配布で今も必要です。廃止ではなく、オープンなHTML層を上に足す二層設計が正解です。

PDFを消すと、営業が客先で配る資料、稟議書に添付する資料、展示会で配布する資料がすべて失われます。これはAI引用の獲得と引き換えにするには大きすぎるコストです。原本PDFはゲート層に残したまま、結論と主要数値だけをオープンなHTMLとして切り出す。この分離であれば、失うものはありません。

フォーム入力を求めるダウンロード資料は、本当にAIに引用されないのですか？

はい、原則として引用されません。クローラーはフォームを送信できず、ゲートの先の本文に到達する手段が存在しないためです。

補強証拠として、Search Engine Landの41日間・30,180件のボットリクエストを対象とした実験では、GPTBot・ClaudeBot・Meta-ExternalAgent・AmazonbotはJavaScriptで注入されたリンクへの到達数が0件でした。JS実行能力を持つGooglebotでも2%です。フォーム送信はJSリンククリックよりさらに高いハードルなので、到達は期待できません。商用ホワイトペーパーの引用率が0.1%と全体よりさらに低いのも、この構造で説明がつきます。

検索結果に出るPDFのタイトルはどこから決まりますか？

ファイル内部のtitleメタデータと、そのPDFへの被リンクのアンカーテキストから決まります。表紙のデザイン文字や本文1行目ではありません。

Wordから変換したPDFでは、titleメタデータに変換元のファイル名がそのまま残っていることがあります。この状態だと検索結果に社内の作業ファイル名が露出します。PDFの文書プロパティで正式名称に修正し、あわせて自社サイト内からPDFへリンクする際のアンカーテキストを「こちら」ではなく資料名を含む文言に変更してください。この2箇所の修正だけで表示品質が変わります。

llms.txt にPDFのURLを書けばAIに引用されますか？

引用されません。llms.txt は2026年8月時点で主要AI事業者に公式採用されておらず、記載しただけでPDFが解析されるようにはなりません。

llms.txt は提案仕様であり、対応を公表しているAI事業者は限定的です。仮に読まれたとしても、そこに書かれたPDFの中身が抽出可能になるわけではないため、バイナリ形式の問題は何も解決しません。llms.txt を運用するのであれば、PDF直リンクではなく要点HTMLページのURLを列挙し、各行に何が書かれているかの短い説明を添える構成が妥当です。

自社のPDF資料がAIに引用されているかを確認する方法はありますか？

あります。Search Consoleの生成AIレポート、Bing WMTのAI Performance、エッジログのボット解析の3系統です。

Search Consoleは表示回数のみでクリックとクエリは開示されず、APIからも取得できないため手動エクスポート運用になります。Bing Webmaster ToolsのAI PerformanceはCitations数・引用ページ・Grounding Queryが取得でき、ページ単位の把握に向きます。エッジログは引用の有無こそ分かりませんが、GPTBotやOAI-SearchBotが自社PDFに到達できているか、403で弾かれていないかを確実に確認できます。

PDFをHTML化する工数はどれくらいで、何本から着手すべきですか？

作業を分解すると1本あたり半日〜2日が目安です。着手は問い合わせに近い上位3〜5本に絞り、効果を測ってから広げてください。

工数の内訳は、原稿の抽出と整形、要点への再構成、表のHTML化、canonicalと X-Robots-Tag の設定、内部リンクの追加です。パターンB（要点HTML＋PDF併載）なら半日程度、パターンC（章分割）は章数に比例して伸びます。最初から全資料に着手すると、引用も流入も生まない資料に工数を溶かします。棚卸しシートで「一次データあり」「導入判断または動向・将来の意図に対応」「ゲートあり」の3条件を満たす行から順に処理するのが最短経路です。

まとめ

PDFホワイトペーパーがAI検索で引用されないのは品質の問題ではなく、形式・到達性・粒度という3つの構造的な問題です。 そしてこの3つは、いずれも技術的に解決可能です。

本記事の要点を再掲します。

Optyino調査が示した0.4%対22.3%という約56倍の差は、裏を返せば**「器を替えるだけで引用可能性が跳ね上がる余地がある」**ということです。資料型コンテンツ全体が22.3%引用されている以上、AIは資料的な情報を求めています。求められているのに届いていない状態を解消するのが、二層設計の本質です。

2026年8月時点で、PDF専用の公式SEOガイダンスはGoogleの2011年の記事がほぼ唯一という状況が続いています。15年近く更新されていない領域に、AI検索という新しい変数が乗った。だからこそ、正確な仕様理解に基づいて手を打った企業とそうでない企業の差が開きます。まずは棚卸しシートを埋めるところから始めてください。