AI時代のクローリング技術検証 : LLMは実際にどのWebサイトを読み取れるのか？
〜ハイブリッド構成サイトを使った包括的アクセステスト結果〜
（2025.07.03）

はじめに

ChatGPT、Claude、Geminiなどの大規模言語モデル（LLM）が普及する中、「自分のWebサイトがAIにどこまで読まれているのか？」という疑問を持つサイト運営者の方は多いのではないでしょうか。自分もふとこの疑問を抱き、実際に検証を行ってみました。

AIの学習対象になることは、専門性の高い情報を発信する立場にとって、情報の拡散や認知度向上といったメリットと、意図しない利用や誤った情報の生成への懸念といったデメリットの両方があります。しかし、実際のLLMアクセス状況についての正確な情報は限られており、推測や憶測に基づく情報が多く流通しているのが現状です。

そこで今回、実際に自分のWebサイトを使用して、LLMが本当にアクセス可能なのかを実証的に検証しました。

検証対象サイトの構成

今回の検証対象は、自分のWebサイトです。

• 分野: セキュリティ・プライバシー・AIガバナンス

• 技術構成: ハイブリッド型（複数ドメインを持つサイト：静的ホスティング + CMSの組み合わせ）

構成（抜粋）

• ルートドメイン (静的ホスティングサービス)

  • /llms.txt (AI向けサイトマップ)

  • /robots.txt (クローラー制御)

  • /.well-known/security.txt (RFC 9116準拠)

  • リダイレクト設定

• wwwサブドメイン (ノーコードCMS)

  • / (トップページ)

  • /XXXX/ (コンテンツページ1)

  • /YYYY/ (コンテンツページ2)

  • /ZZZZ/ (コンテンツページ3)

検証方法と結果

検証実施概要

• 検証に使用したLLM: ChatGPT, Claude (Anthropic), Gemini
  ※LLMの直接的なWebクローリング能力ではなく、各LLMが提供するWebアクセス機能（Web検索プラグイン等）を用いた情報取得能力を検証

• 検証方法: 各LLMが提供するWebアクセス機能（Web検索プラグイン等）を通じた情報取得

• 検証日時: 2025年7月3日（設定作業は7月2日に実施）

アクセス成功一覧（抜粋）

以下のコンテンツへのアクセスに成功。（ただし、結果はLLMによって異なる場合あり。例：一部LLMはCMSコンテンツは見れなかった等）

ファイル: ホスティング / 結果 / 取得内容

llms.txt: 静的 / 成功 / LLMによるコンテンツ利用ポリシー

robots.txt: 静的 / 成功 / クローラー許可設定

.well-known/security.txt: 静的 / 成功 / セキュリティ連絡先

トップページ: ノーコードCMS / 成功 / 全文取得

コンテンツページ（複数）: ノーコードCMS / 成功 / 詳細情報

アクセス失敗

今回のテストでは、以下のタイプのアクセス失敗が確認されました。

• 特定のURLパターンを持つ公開ページへのアクセス不可
  一部のLLMからは、特定のURLパターンを含む公開ページへのアクセスが「不可」と報告されるケースがありました。これらのページは実際には認証不要であり、robots.txtやllms.txtでのクロール拒否設定もありません。これはLLM側の一時的なWeb情報取得失敗、またはURLに含まれる特定の文字列からAIが「非公開ページ」と誤認してしまうバイアス（Pattern-Matching Bias）によるものと考えられますが、見れたり見れなかったりしましたので明確な理由は不明。

• 一時エラー
  作業直後のDNS反映や、サーバ証明書設定遅れによると考えられるエラー、CMS側での500番台エラーなど原因が明確ではない一時エラーも発生

検証結果

今回の検証で、LLMのWebサイトアクセスに関して以下が明らかになりました。

LLMはノーコードCMSを読める（が、時々エラーになることもある）

• 実証結果: 主要なノーコードCMSで構築されたコンテンツにも、LLMはアクセス可能。

• 正確な状況: 最終的にHTMLが出力され、それが適切に構造化されていれば、LLMは問題なく情報を読み取ることができます。ただし、実際にLLMがサイトを読めた後でもエラーになるケースを複数回経験。

動的生成サイトでもAIは読める

• 実証結果: JavaScriptに依存して動的に生成されるCMSコンテンツも、LLMは正常に取得。

• 正確な状況: 現代のLLMクローラーは進化しており、多くの動的サイトに幅広く対応しています。ただし、実際にLLMがサイトを読めた後でもエラーになるケースを複数回経験。

つまずいたポイント

検証を進める中で、いくつかの技術的な課題に直面しました。

1. ドメイン構成の理解

• 課題: サブドメインとルートドメインの関係性をどのように構築するかで悩みました。特に、CMSのデザイン部分にシステムファイルを直接配置できないため、ドメインを分離する必要がありました。

• 解決: ルートドメイン側で適切なリダイレクト設定を行うことにより、両ドメインを統合的に管理・運用できるようになりました。

2. RFC準拠ファイルの配置

• 課題: .well-knownディレクトリのようなRFC（Request For Comments）に準拠した特殊なファイルを配置しようとした際、一部のホスティングサービスでは.で始まるファイルやディレクトリが非公開扱いとなる（SaaSによっては表示させない）問題に直面しました。

• 解決: .well-knownディレクトリの配置に適切に対応しているホスティングサービスへ移行することで、標準準拠を実現しました。

3. SSL証明書の自動発行

• 課題: SSL証明書の自動発行時に、DNS伝播の遅延により発行がすぐに反映されない問題がありました。リロードやクリックを繰り返しても状況は変わりませんでした。

• 解決: 時間が経過する（最大で24時間程度）ことで、DNSの伝播・自動SSL証明書発行がされ、問題は解消されました。

• 注意点：ただし、実際にLLMがサイトを読めた後でもエラーになるケースを複数回起こったため切り分けは困難な場合もあり。

LLM学習対象化の制御

Webサイト運営者として、LLMにコンテンツを見せたい場合と見せたくない場合があるでしょう。ここでは、それぞれのケースでの対策を解説します。
（実際に学習対象になったかどうかの確認は時間がかかるはずなので本記事では理論のみ記載）

LLMに見せたい場合

• robots.txtでの明示的な許可: クローラーに対してサイト全体の、または特定のパスへのアクセスを許可します。これがLLMがコンテンツを見つけるための基本的な指示になります。

• 整理されたHTML/URL構造: LLMがコンテンツの構造を理解しやすいように、セマンティックなHTMLと論理的なURL構造を心がけます。

• コンテンツの質: 専門性や信頼性の高い、質の良いコンテンツを提供することが最も重要です。

• llms.txtによる将来的なAI最適化の準備: llms.txtファイルを使用して、LLMに対する学習許可の意思を明示的に示します。これはrobots.txtを補完し、より細かな意図を伝えるためのものです。（注：現在は提案段階の標準で、主要LLMでの公式サポートはない）

LLMに見せたくない場合

• robots.txtでのBot明示的拒否: 特定のLLMクローラー、または全てのクローラーに対して、サイト全体や特定のパスへのアクセスを拒否します。

• 認証による制限: 会員制コンテンツなど、ログインが必要なページはLLMにクロールされません。

• 完全にJavaScriptなどの難読化（未検証）: JavaScriptを極度に利用した難読化されたコンテンツは、クロールが困難になる可能性があります。（ただし、これは未検証であり、現代のクローラーはJavaScriptの解析能力が高いため、確実な方法ではありません。）

学習を促進したい場合の設定例

robots.txt設定例: 

User-agent: GPTBot Allow: /
User-agent: ClaudeBot Allow: /
User-agent: Google-Extended Allow: /
User-agent: * Allow: /

llms.txt で詳細ガイダンス提供 （例：学習許可の旨、クレジット表示の要請、引用のルールなどを記述）

学習を防止したい場合の設定例

robots.txt設定例: 

User-agent: GPTBot Disallow: /
User-agent: ClaudeBot Disallow: /
User-agent: Google-Extended Disallow: /
User-agent: * Disallow: /

各ページに noindex メタタグ: <meta name="robots" content="noindex"> （検索エンジンやLLMにそのページをインデックスさせない）

今回の検証から得られた発見

今回の検証から、LLMとWebサイトの関係性について以下の重要な知見が得られました。

• 現代のLLMは進化している: 多様なホスティング形態やCMS技術に柔軟に対応し、多くのWebサイトをクロールできる能力を持っています。

• robots.txtの重要性: LLMへのアクセスを制御する上で、robots.txtが最も確実で標準的な手段であることが改めて確認されました。

• ハイブリッド構成の有効性: 静的ホスティングとCMSを組み合わせたハイブリッド構成でも、技術的な問題なくLLMからアクセス可能であることが分かりました。

• LLMへの「意図の明示」: llms.txtを利用して、LLMにコンテンツの学習許可や拒否の意思を明確に伝えることも検討はしておくと良いが実効性は今後要確認。

• AI時代への対応: LLMへの適切な対応は、これからのSEO（検索エンジン最適化）だけでなく、GEO（Generative Engine Optimization：生成AI最適化）といった新しい概念にもつながると考えられます。

まとめ

今回の実証検証により、以下の点が明確になりました。

• 現代のLLMは想像以上に多様なWebサイト技術にアクセス可能。（ただし、そのアクセス能力や結果はLLMによって異なる場合あり）

• 技術的な制約よりも、サイト運営者の意図的な設定による制御が重要。

• 適切な設計を行うことで、AIとの関係性を戦略的にコントロールすることが可能。

• ブラウザからのアクセスは問題なくても、LLMからのアクセスでは200でアクセス可能を確認した後に500エラーなどが発生する場合があったので確認時はそれも念頭に。

AI時代のWeb戦略として、「学習される前提」での情報設計と「制御可能な公開方針」の両立が、今後ますます重要になってきていると強く感じています。

検証データについて

本記事は実際のアクセステスト結果に基づいて記述しています。

免責

本記事は特定の時点での特定のサービスを用いた検証結果であり、その内容の正確性や網羅性、特定の状況への適用可能性について、いかなる責任も負いません。
また、本記事の執筆プロセスにはAIの活用が含まれますが、記載内容の最終的な妥当性や適用性については、利用者の判断と責任においてご活用ください。