llms.txt とは何か？

Scrapeless Agent Browser は、Web オートメーションと AI エージェント向けにクラウドブラウザを提供します。

llms.txt は、AI エージェントに対して Web サイトの簡潔な紹介と有用なリソースへのリンクを提供することを目的とした提案中の Markdown ファイルです。パブリッシャーはこのファイルを使ってドキュメントを特定し、重要なコンテキストを説明し、ページのよりクリーンな表現へクライアントを誘導できます。

このファイルはディスカバリー（発見）の補助です。これを公開しても保護されたコンテンツへのアクセスを許可したり、クローラーにリンクへ従うことを強制したり、回答エンジンが必ずサイトを引用することを保証したりするものではありません。その実務的な価値は、内容の正確さと、それを利用することを選ぶクライアントに依存します。

提案が実際に定義しているもの

llms.txt 提案は、Web サイトのコンテキスト、ガイダンス、およびリソースリンクを含む簡潔な Markdown ドキュメントについて説明しています。現在の llms.txt 提案 では、クリーンな Markdown ページ表現とディスカバリー用リンクについても議論しています。これらは、ファイル自体によって実装されるアクセス制御システムではなく、提案された慣習です。

サイトはインデックスをルートまたは関連するパス配下に配置できます。したがって、ドキュメント専用インデックスは、会社全体を要約しようとすることなくドキュメント領域を記述できます。そのスコープは読者に対して明確であるべきです。製品ドキュメント、ナレッジベース、マーケティングサイトでは、含まれる情報の種類が異なり、選定基準も異なる必要があります。

クライアントの選択に役立つように、インデックスは十分小さく保ってください。すべてのページを単一の非構造ファイルにコピーしてしまうと、この形式が意図している編集作業の価値が失われます。どのリソースがどの質問に答えるのかを短く説明する方が、ほぼ同じリンクを長く並べるよりも有用であることが多いです。

エージェントがファイルをどのように使えるか

エージェントは、個々のページを開く前に、llms.txt を利用して関連リソースを発見できます。このファイルは候補を提供するだけであり、どのページがユーザーの質問に答えるのか、取得した内容を検証するのかは、エージェント自身が判断しなければなりません。

例えば、認証について調査するエージェントは、インデックスの中に概要、鍵管理ページ、リクエスト例を見つけるかもしれません。エージェントは認証に関する資料を開き、必要なヘッダー、現在のエンドポイント、アカウントスコープを確認すべきです。「Authentication」と書かれたインデックスラベルを読むことは、認証済みリクエストを検証することと同等ではありません。

クライアントはこのファイルを無視したり、別のディスカバリーメカニズムを使ったりする場合もあります。llms.txt なしでは使い物にならないドキュメントシステムの設計は避けてください。人間によるナビゲーション、安定したカノニカルページ、通常のハイパーリンクは、提案を実装していない人間、クローラー、エージェントにとっても依然として有用です。

llms.txt、robots.txt、および Sitemaps

llms.txt はコンテキストとリソース選択を提供し、robots.txt はクローラーのルールを表現し、sitemap はディスカバリーのための URL を列挙します。これらはナビゲーションの周辺で役割が重なる部分もありますが、意味は異なります。

「 Robots Exclusion Protocol 」は、ロボット向けルールと認可を明確に分離しています。同じ実務的な境界が llms.txt にとっても重要です。公開テキストファイルを、制限エリアへの立ち入りや個人情報の開示を許可するものとして扱うべきではありません。

これらのリソースは共存できます。sitemap は広範な URL 在庫をカバーし、llms.txt は特定のオーディエンスにとって最も役立つページを選定します。可能な限り、サイトは両者を同じ基礎コンテンツ記録から維持し、ページ名変更によって矛盾するディスカバリーパスが生じないようにすべきです。

有用なインデックスに何を書くか

有用な llms.txt インデックスは、サイトの目的を説明し、閲覧者がその中から選べるように十分な文脈付きで権威あるページへ案内します。ナビゲーションを見ておらず、1つのリソースだけを取得するかもしれない人向けに記述してください。

ウェブサイトまたはドキュメントの名称と簡潔な要約から始めます。リンクは、導入、認証、リファレンス資料、制約事項といった実際のタスクごとに整理します。行き先のタイトルが似ている場合は短い説明を追加します。サイトに複数のプロダクトがある場合、「Introduction」だけではあいまいです。

正規の行き先を優先します。レガシーなドキュメントパスが汎用的な概要ページにリダイレクトされている場合は、適切な現在のタスクページに置き換えます。ステータスがクリーンであることだけでは、その行き先が有用である証拠にはなりません。とくにドキュメント移行後は、リダイレクト先の見出しと関連コンテンツを確認してください。

資格情報や内部向け手順を公開ファイルに含めないでください。API 例は、実際のキーをさらすことなく認証の仕組みを説明できます。有用だからといって、プライベートな顧客事例をエージェントのための文脈として公開するのは避けてください。公開ドキュメントの選定は、ウェブサイトと同じコンテンツ境界に従うべきです。

Markdown コピーは意味を保持しなければならない

Markdown 表現は、対応するページの技術的な意味を保持しなければなりません。ナビゲーションを削除すると散らかりは減りますが、前提条件、警告文、表のヘッダー、コードの注釈を失うと、クライアントがドキュメントから許可されていると理解する内容が変わってしまうことがあります。

表を含む変換を確認してください。パラメータ値が列ヘッダーと切り離されると、本当は例であるものがデフォルト値のように見えることがあります。コードサンプルは、言語コンテキストと明確なプレースホルダーを保持する必要があります。元のページが異なるバージョンを説明している場合、Markdown 表現でもその境界が見えるようにしておかなければなりません。

表現間で一貫した正規の同一性を維持してください。 HTTP 表現とコンテンツネゴシエーションモデル は、1つのリソースに異なる表現が存在しうる理由を説明するのに役立ちます。よりクリーンな表現であっても、解析しやすいという理由だけで無関係なページではなく、意図されたリソースを記述すべきです。

保守と受け入れチェック

llms.txt の保守とは、ファイルの存在だけでなく、コンテンツ変更後に有用性を確認することを意味します。基盤となるドキュメントを担当するチームに所有権を持たせ、ページの移動やインターフェースの変更があった際には、リリースレビューにインデックスを含めてください。

1. インデックスが意図したパスで読み出せること、そのレスポンスがアプリケーションエラーページではなくテキストを含んでいることを確認します。
2. 各リンク先を開き、最終的な URL、見出し、主題を確認します。
3. 技術的な手順のサンプルを、人間向けドキュメントと比較します。
4. 廃止されたリソースが特定・削除されていること、新しい正規ページが発見可能であることを確認します。
5. 範囲を絞ったリサーチクエリをテストし、取得された資料が結果の回答を裏付けているか検証します。

成果は別々に測定します。サーバーログからはファイルへのリクエストが確認できますが、リクエストがあったからといって、そのクライアントが回答に利用したことにはなりません。リファラートラフィックがあっても、そのファイルが訪問の原因であるとは限りません。観測は厳密に区別してください: 発見、取得、回答の裏付け、引用は異なる出来事です。

提案されているファイル構造の理解

提案されている構造は、サイトまたはプロジェクト名の H1 見出しから始まります。短い引用ブロックの要約、説明テキスト、そしてリソースリンクのリスト（説明文は任意）を含む H2 セクションを持つことができます。「Optional」セクションは、より少ない文脈でよいクライアントが省略できる二次的な資料のための慣例です。

セクション名は、内部の部署構成を再現するのではなく、リソースの内容を説明するものを選んでください。認証について質問している人が、概念的な概要とリクエストヘッダーのリファレンスを区別できるようにします。構造的なマーカーはインデックスを処理しやすくしますが、有用なラベルと保守されたリンク先が、それを読む価値あるものにします。

キュレーションされたコンテキストとブラウザ取得の併用

ドキュメントインデックスに回答が含まれていない場合や、そのタスクにレンダリングされたページ状態が必要な場合でも、ブラウザ取得は依然として有用です。 Scrapeless Agent Browser は、そのワークフローのブラウザ部分を提供できますが、サードパーティのエージェントが llms.txt を尊重するかどうかを決定するものではありません。

この Agent Browser ドキュメント はプロダクトのコンテキストを提供します。 AI エージェントのための Web コンテキストエンジニアリング は、有用なウェブ上の証拠を選定するという、より広いタスクを扱います。ブラウザのワークロードに照らして Scrapeless 料金 を検討し、インデックス形式をインフラを追加する理由として扱わないでください。

結論

llms.txt は、エージェントが現在の関連ドキュメントを、より少ないあいまいさで見つけるのに役立つときに有用です。ファイルをキュレーションし、代替表現でも意味を保持し、変更後にリンク先を検証してください。取得と回答の質を直接評価し、テキストファイルが存在すること自体を裏付けの根拠にしないでください。