- [ ホーム ](/ja/) / - [ ブログ ](/ja/blog/) / - llms.txt のベストプラクティス # `llms.txt`のベストプラクティス：明確で保守しやすいファイルを作る llms.txtの実践ガイド。絶対URL、事実に基づく説明、明確なセクション、定期的な更新を扱います。ファイルの公開だけでは、AIシステムによる利用は証明できません。 最終更新: 2026年9月6日 このページの内容 - [ 優れたllms.txtの条件とは？ ](#overview) - [ すべきこと ](#dos) - [ してはいけないこと ](#donts) - [ セクションの命名と構成 ](#sections) - [ 優れたリンク説明を書く ](#descriptions) - [ Optional セクション ](#optional-section) - [ 最新の状態を維持する ](#maintenance) ## 優れたllms.txtの条件とは？ 優れたllms.txtファイルが行うことは一つです。サイトで最も重要なページへの、信頼できる厳選された近道をAIシステムに提供します。 エージェントフレームワークやRAGパイプラインがファイルを読むと、サイトの内容、文脈として読み込むべきページ、 それらの重要度の順序をすぐに把握できるはずです。 マーケティング文句、相対URL、サイト内の全ページで埋め尽くされた質の低いファイルには、sitemap.xmlをクロールする以上の利点がありません。llms.txtの価値は、選別と明瞭さにあります。 ## すべきこと ### 絶対URLを使用すること llms.txt内のすべてのリンクは完全な絶対URLでなければなりません。ファイルを取得するクライアントが事前にドメインを知らない可能性があるため、相対パスは機能しません。 ``` # Correct - [API reference](https://example.com/docs/api/): complete endpoint documentation. # Incorrect, relative URL - [API reference](/docs/api/): complete endpoint documentation. ``` ### 事実に基づく引用文を書く H1タイトルの直後に置く任意のブロック引用は、強く推奨されており、AIシステムが最初に読む部分です。サイトや製品が何であるかを、平易な1〜3文で定義してください。宣伝文句ではなく、機械可読な説明と考えましょう。 ``` # Acme > Acme is an open-source inventory management platform for small manufacturers. > It provides real-time stock tracking, supplier integration, and demand forecasting. > Documentation covers setup, configuration, and the REST API. ``` ### 最も重要なページを5～15件含める キュレーションこそが目的です。ほとんどのサイトでは、5～15件のリンクが最適です。小規模なドキュメントサイトなら、さらに少なくても構いません。多数の異なる製品領域を持つ大規模プラットフォームなら増やせますが、30件を超えるとシグナルが薄まり始めます。 クイックスタート、中心概念、APIリファレンス、認証、ユーザーが製品についてAIアシスタントによく尋ねる質問に答えるページを優先してください。 ### ファイルサイズは妥当な範囲内に収めてください 仕様書ではファイルサイズの最大値は規定されていませんが、実用上の制限は重要です。 100 KBを大幅に下回るファイルであれば、効率的に取得・解析できます。llms.txtのサイズが非常に大きくなる場合は、 一部のコンテンツを [llms-full.txt](/ja/llms-full-txt/) 代わりに。 ### APIドキュメントがあれば含めてください 製品にAPIがある場合、APIリファレンスはほぼ間違いなく最も価値の高いリンク先です。開発者はAPI呼び出しについてAIアシスタントに頻繁に質問するため、存在しないエンドポイントやパラメーターの生成は特に厄介なAIエラーです。正式なAPIリファレンスを示すことで、そのリスクを減らせます。 ### 機械可読性を維持すること 仕様では標準のMarkdownリンク構文を使用します： `- [Link text](URL): description.` HTML、フロントマター、非標準の書式を追加しないでください。どのMarkdownパーサーでも正しく処理できるよう、構造を簡潔に保ってください。 例 公開前に検証 以下の llmtxt.infoバリデーター を使用して、公開前にファイルが仕様に準拠しているか確認してください。よくある問題は、H1タイトルの欠落、相対URL、不正なリンク構文です。 ## してはいけないこと ### 認証が必要なページを含めない ログインが必要なページへのリンクは、AI クローラーやエージェントが取得しようとすると失敗します。 公開アクセス可能な URL のみを含めてください。重要なドキュメントがログイン画面の背後にある場合は、 それ自体を個別に修正すべきです。認証で保護されたドキュメントは、人間にとっても見つけにくくなります。 ### 引用ブロックにマーケティング文を入れない ブロック引用は、人間を説得するためではなく、AI システムが事実に基づく文脈を把握するために読み取ります。 マーケティング表現（「業界をリードするソリューション...」など）は、AI が製品を理解する助けになりません。 役立つのは、事実に基づく具体的な表現です。 ### 相対URLを使用しない 次のような相対 URL： `/docs/api/` は llms.txt では無効です。プロトコルとドメインを含む完全な絶対 URL を必ず使用してください。 ### サイト内のすべてのページにリンクしない llms.txtはサイトマップではありません。数百件のリンクを含むファイルでは、キュレーションのシグナルがほとんど得られません。AIクライアントが全ページを発見する必要があるなら、そのためのsitemap.xmlがあります。llms.txtは「このサイトを理解するために10ページしか読めないとしたら、どの10ページか？」という問いに答えるべきです。 ### 公開して放置しないこと llms.txtは古くなります。リンク先ページを削除した場合、セクション名を変更した場合、または重要な新規ドキュメントを公開した場合は、その変更を反映するようllms.txtを更新してください。壊れたリンクや古い説明だらけのファイルは、AIシステムにコンテンツについて誤った情報を与えます。 ### ステージングURLやリダイレクトURLを含めない 正規の本番URLだけにリンクしてください。ステージングURLはパスワードで保護されている場合があり、リダイレクトチェーンは遅延を増やします。また、URLを識別子として扱う取得システムでは、非正規URLが混乱を招きます。 ## セクションの命名と構成 仕様では、セクションをMarkdownのH2見出し（`##`）にリンク一覧を含めます。セクション名は標準化されていないため、コンテンツの構成を反映する名前を選びます。一般的なパターン： - **ドキュメント** または **ドキュメント**、ドキュメントサイト向け。 - **APIリファレンス**、公開 API を持つ製品向け。 - **はじめに**、オンボーディングを重視する製品向け。 - **ガイド**、チュートリアル形式のコンテンツ向け。 - **ブログ**、編集コンテンツ向け（補助的な場合はOptionalと記載）。 - **任意**、クライアントが省略できる、仕様で定義された優先度の低いリンク用セクションです。 セクション名はSEOキーワードではなく、コンテンツの整理方法を反映するものを選ぶ。ファイルを読むAIクライアントは 自然言語を理解するため、構造が明確になる名前を使う。 ## 優れたリンク説明を書く llms.txtの各リンクには、URLとコロンで区切った任意の説明を付けられます。 ``` - [Page title](https://example.com/page/): what this page contains. ``` 優れた説明は短く（20語未満）、事実に基づき、ページの対象内容を具体的に示します。宣伝文句ではなく、短い要旨として扱ってください。 - 適切な例： *「認証、レート制限、エラーコードを含む、すべてのREST APIエンドポイントの完全なリファレンス。」* - 悪い例： *「優れた連携をすばやく構築するのに役立つ、世界最高水準のAPIドキュメント。」* - 適切な例： *「アカウント作成から最初の API 呼び出しまでを説明する、新規ユーザー向けの手順別クイックスタート。」* - 悪い例： *「Acme の力を体験するために、今すぐ始めましょう。」* ## Optionalセクション `## Optional` は編集上のラベルであり、v2における特別な処理命令ではありません。別グループにすることで、人や互換性のあるクライアントが補助的リソースを理解しやすくなる場合に使用します。適切な例： - ブログ記事や編集コンテンツは、文脈を提供しますが技術的には必須ではありません。 - 変更履歴またはリリースノートのページ。 - 主要ページの別言語版。 - FAQと用語集ページ。有用ですが、主要なリファレンス資料ではありません。 クライアントがこのセクションをスキップする、優先度を下げる、または別の方法で扱うと想定しないでください。ワークフローで優先順位が重要なら、見出しから推測せず、クライアント側でその動作を文書化してください。 ## 最新の状態に保つ 簡単な保守習慣として、主要ページを公開または廃止するたびに、llms.txtを更新すべきか確認してください。大規模サイトでは、次の方法も検討できます: - ビルド時に、ナビゲーション構造やCMSからllms.txtを自動生成する。 - コンテンツ公開チェックリストに llms.txt のレビューを追加すること。 - 定期的に実行する [バリデーター](/ja/validator/) リンク切れを検出するため。 サイトの変更頻度が低ければ、通常は四半期ごとのllms.txtレビューで十分です。頻繁に公開する場合は、デプロイパイプラインと連動させてください。 ## 続きを読む - [ベストプラクティス（完全ガイド）](/ja/best-practices/)、仕様に適合した有用なファイルを作るための 10のルール。 - [形式リファレンス](/ja/llms-txt-format/)、構文例を含む完全な仕様。 - [ジェネレーター](/ja/generator/)、数分でフォームから有効なファイルを作成します。 - [実際の例](/ja/examples/)、Anthropic、Cloudflare、Stripeが ファイルをどのように構成しているかを確認してください。 ## ソース - [ llmstxt.org、コミュニティによる提案 ](https://llmstxt.org/) - [ llms.txt フォーマットリファレンス、llmtxt.info ](https://llmtxt.info/ja/llms-txt-format/) - [ ベストプラクティス、llmtxt.info ](https://llmtxt.info/ja/best-practices/)