- [ ホーム ](/ja/) / - [ ブログ ](/ja/blog/) / - ある調査では、AI ボットは存在しない llms.txt ファイルを探しに行きませんでした # ある調査では、AI ボットは存在しない `llms.txt` ファイルを探しに行きませんでした Ahrefsの2026年5月ログには、有用な否定的な結果が含まれています。つまり、そのサンプルにおいて、AIボットは欠落しているllms.txtファイルをリクエストしなかったということです。これを公開する場合でも、発見経路は依然として必要です。 最終更新: 2026年8月12日 このページの内容 - [ 調査結果 ](#the-finding) - [ これによって作業が変わる理由 ](#why-it-matters) - [ エージェントをファイルへ誘導する方法 ](#how-to-route) - [ 結論してはいけないこと ](#what-not-to-conclude) ## この発見 Ahrefs は、2026年5月 にトラフィックを受けた 137,210 ドメインのサーバーログを分析し、その後 `/llms.txt` パスをリクエストしたすべてのユーザーエージェントを分類しました。中でも目立つ結果が 1 つありますが、見出しになった結果ではありません。 彼らは、**404** を返したリクエストを別に調べました。これは、存在しない `llms.txt` をクライアントが要求したという意味です。その 2026年5月 のサンプルでは、特定された AI bot からのリクエストの割合は **ゼロ** でした。存在しないファイルには人間のトラフィックが 98% 集まり、受け入れられたファイルには bot のトラフィックが 96% 集まりました。ログから、各人間がその URL を要求した理由までは分かりません。 言い換えると、この調査では、存在しないルートファイルを AI bot が調べることは観測されませんでした。これはこのサンプルと月についての証拠であり、どのシステムも発見を行わないという証明ではありません。 同じ調査の見出しになった発見を、別の形で捉え直せます。つまり、彼らが見つけたおよそ 38,000 件の有効な llms.txt ファイルのうち、**97% は、その月にクライアント、bot、人のいずれからもリクエストを一度も受けませんでした** 。 ## これによって作業が変わる理由 多くの人が暗黙に想定するモデルは `robots.txt` モデルです。ファイルをルートに置けば、Robots Exclusion Protocol を適用するクローラーは標準の場所を知っています。このプロトコルは [RFC 9309](https://www.rfc-editor.org/rfc/rfc9309.html)で正式化されていますが、アクセス制御ではなく、依然としてクローラーの慣行です。 `llms.txt` について、それは安全な仮定ではありません。[llms.txt が実際に行うこと](/ja/does-llms-txt-work/)で説明したとおり、この慣行は Answer.AI の Jeremy Howard が 2024年9月 に提案し、[関連する提案](https://www.answer.ai/posts/2024-09-03-llmstxt.html)で示されています。[V2 仕様](https://llmstxt.org/)は発見関係とパス単位のファイルを定義しますが、すべてのクライアントに取得を義務付けてはいません。Ahrefs はサンプル内で、存在しないルートファイルへの AI の推測的なリクエストを観測しませんでした。 つまり、ファイルを公開することは作業のおよそ半分であり、それだけでは 1 回の取得も発生させません。残りの半分は、ファイルの存在をエージェントに知らせる仕組みを作ることです。 ## エージェントをファイルへ案内する方法 V2 で定義された発見メカニズムから始め、役立つ場合は人に見える経路を追加します。 **関係を宣言します。** HTML ページでは、対象ファイルに ` ` を追加し、Markdown の対応ページがある場合は ` ` も追加します。同じ関係は HTTP `Link` ヘッダーでも送れます。パス配下のファイルはそのセクションを説明でき、最も具体的なパスが適用されます。 **HTML からリンクします。** フッターやドキュメントナビゲーションに通常の ` ` を置けば、URL は通常のリンクグラフに入り、人にも見える代替経路になります。 **ドキュメントから参照します。** プロダクトにドキュメントサイトがあるなら、「AI アシスタント向け」または「エージェント向け」ページで URL を明示すると、開発者が API について尋ねたときに、コーディングエージェントが実行できる手がかりになります。Ahrefs は、AI エージェントとエージェント型インフラが、これらのファイルを取得する AI カテゴリの中で最大で、リクエストの 10.5% を占めると見つけました。AI 検索ボットは 1.1% です。彼らのデータでは Claude-Code が、すべての検索ボット、すべてのアシスタント、すべての学習用クローラーより多く取得していました。これらは開発者が URL を指定して使うツールです。 **指示が置かれている場所に記載します。** README、オンボーディングページ、MCP サーバーの説明など、ユーザーや統合機能がサイトのコンテキストをエージェントに渡す場所で `llms.txt` URL を示せば、公開を発見可能な経路にできます。 これらのどれも、ファイル自体を変更する必要はありません。まだ作成していないなら、[llms.txt の作成方法](/ja/how-to-create/)で形式とスタック別のデプロイを説明し、[バリデーター](/ja/validator/)で仕様との適合を確認できます。 ## 結論してはいけないこと Ahrefs 自身が述べている、率直な注意点が 2 つあります。 彼らの母集団は自社の分析顧客から抽出されているため、技術寄りで SEO に詳しい傾向があります。28% の導入率は、Web 全体の率ではなく**上限** だとしています。注目ホストの固定リストを追跡する私たちの[導入サンプル](/ja/llms-txt-adoption/)は、異なる母集団を測る別の指標であり、直接比較すべきではありません。 「取得した」と「読んだ」は同じではありません。サーバーログのリクエストは、クライアントがバイト列を取得したことを示すだけです。その後モデルがそれを使ったかどうかは何も証明しません。したがって、この調査の数字はすべて、実際の消費量の推定ではなく、その上限です。 両方の注意点を踏まえても、実務上の結論は変わりません。関係、リンク、または別の経路を示さずに `llms.txt` を公開しても、Ahrefs のサンプルからは、エージェントが自力でそれを発見すると仮定する理由は得られません。標準に基づく発見シグナルを追加することは、小さくテスト可能な修正です。 ## ソース - [ Ahrefs、13万7千サイトを分析：llms.txt ファイルの97%は一度も読み取られない（2026年6月） ](https://ahrefs.com/blog/llmstxt-study/) - [ Chrome for Developers、Lighthouse のエージェント型ブラウジング監査：llms.txt ](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt) - [ llmstxt.org、仕様 ](https://llmstxt.org/)