- [ ホーム ](/ja/) / - [ ブログ ](/ja/blog/) / - llms.txtのサブパス：113サイトのベンチマーク # `llms.txt`のサブパス：113サイトのベンチマーク パス単位のファイルは llms.txt V2 の中心です。再現可能なクロールで、それらがすでに存在することが分かりますが、結果は慎重に解釈する必要があります。 最終更新: 2026年8月20日 このページの内容 - [ ベンチマークで何が分かりましたか？ ](#result) - [ テストの実施方法 ](#method) - [ サブパスのファイルが有用な場合 ](#scope) - [ 制限と実装チェックリスト ](#limits) パス単位の llms.txt は、オリジン全体を対象にした単一ファイルより、小さく関連性の高いマップをエージェントに提供できます。最初のベンチマークでは、検証済みルートファイルをすでに提供していた 113 ホストのうち 21 ホストで、テストした共通サブパスに少なくとも 1 つの別ファイルが見つかりました。 **重要なポイント** - 21 ホストが、テストしたパスの少なくとも 1 つで別の H1 ファイルを返しました。 - テスト対象は 4 つの一般的なパスであり、考えられるすべての場所ではありません。 - パス配下が役立つのは、実際のコンテンツ境界を表す場合だけです。 ## ベンチマークでは何が分かりましたか？ 12 2026年8月 に、検証済みルートファイルを提供していた 113 ホストのうち 21 ホストは、次の場所の 1 つ以上でも H1 で始まる別のテキストファイルを返しました: `/docs/llms.txt`、`/documentation/llms.txt`、`/help/llms.txt`、または `/api/llms.txt`。テストでは、リダイレクト、HTML のフォールバックページ、H1 のないレスポンス、ルートファイルと本文が同一のものを除外しました。 これは世界全体の導入率ではなく、観測された件数です。分母には[検証済みディレクトリ](/ja/examples/)にすでにあるホストだけを意図的に含め、分子にはテストした 4 つのパスだけを含めています。ホストが別の場所で公開していても、このテストでは見えないままです。 ## テストの実行方法 スクリプトは固定サンプルから始め、検索エンジンのサンプルは使いませんでした。各オリジンに対して、テキスト向けの `Accept` ヘッダーを明示して 4 つのパスをリクエストし、リダイレクトに従い、レスポンスが成功して Markdown の H1 を含む場合だけ結果として数えました。 その H1 チェックによって、カスタム 404 ページや SPA のフォールバックによる誤検出は減りますが、ファイル全体を認証するものではありません。構造には[バリデーター](/ja/validator/)を使い、依存する前にレスポンスを手動で確認します。 未加工の集計は [`v2-adoption-stats.json`](/v2-adoption-stats.json) で公開されています。固定サンプルとディレクトリの方法論は公開されたままなので、後続の実行でも同じ分母を使えます。 ## サブパスのファイルが有用な場合 パス配下のコンテンツに固有の読者層、用語、リリースサイクルがある場合は、別ファイルが適しています。ドキュメント、API リファレンス、サポートセンター、コース領域が典型的な候補です。`/docs/` 内で動作する互換エージェントは、関係のない会社全体のマップを読み込まずに `/docs/llms.txt` を選べます。 提案で許可されているというだけで、パスファイルを作らないでください。重複ファイルは保守コストを増やし、説明の食い違いを生みます。所有範囲を定義し、同じコンテンツソースからリンクを生成し、ルートファイルはエージェントを専門マップへ案内できる程度に広く保ちます。 [V2 移行チェックリスト](/ja/blog/llms-txt-v2-migration/)で安全な展開手順を説明しています。[ベストプラクティスガイド](/ja/best-practices/)では、対象範囲を決めた後のキュレーションを扱います。 ## 限界と実装チェックリスト このベンチマークからは、エージェントがファイルを発見したか、利用したかは分かりません。すべてのパス、認証が必要な領域、列挙されたオリジン以外のサブドメイン、返されたマップの意味上の品質もテストしていません。パス単位のファイルに検索パフォーマンスを帰属させることもできません。 実装について: - 情報の境界が安定しているパスを選びます。 - そのパスの範囲内にファイルを置き、関連するリソースだけにリンクします。 - 対象ページに `rel="describedby"` を、可能なら追加します。 - ネストしたパスに対して、最も具体的なファイルのルールをテストします。 - 導入を仮定せず、ログでリクエストを監視します。 ### `/docs/llms.txt` だけを公開してもよいですか？ はい。V2 提案はオリジンのルート配下にあるファイルをサポートします。クライアントがそれを発見するかは、その実装と発見シグナルに左右されます。 ### パス配下のファイルはルートのリストを繰り返すべきですか？ 通常はありません。繰り返すと、コンテキスト上の利点が失われます。ルートは案内役として保ち、パスファイルは具体的な内容にします。 ### パス配下のファイルは Google にそのセクションをインデックスさせるのに役立ちますか？ Google は、検索で llms.txt を特別なシグナルとして使わないと説明しています。検索には、サイトマップ、内部リンク、クロール可能性、有用なコンテンツを使います。 ## ソース - [ llmstxt.org、パススコープのファイル ](https://llmstxt.org/) - [ llmtxt.info、v2 ベンチマークデータ ](https://llmtxt.info/v2-adoption-stats.json)