llms.txtとエージェントマニフェストページ：保守管理された機械向けサイトインデックス

llms.txtおよびエージェントマニフェストページは、AIシステムに対して、サイトが何を表しているか、どの公開ページが信頼できるか、そしてビジネスがエージェントアクションをサポートする場合には、どの検証済みの機能とポリシーが適用されるかを伝える機械向けのインデックスです。これは保守管理されたソースへの地図であり、それらのソースの代替ではなく、特定のクローラーが使用することを保証するものでもありません。

その契約はアイデンティティ → スコープ → 信頼できる宛先 → オプションの機能 → 制約 → 鮮度です。ファイルは、機械が取得し、推測なしで解釈し、ライブの正規URLをたどり、本番環境の現実と一致する事実に到達できるときに成功します。

これが答える質問

主要な質問は次のとおりです：「このサイトのどの部分をAIシステムが組織、そのコンテンツ、およびサポートされているアクションを理解するために使用すべきか？」 補足的な質問は次のとおりです：

• サイトの正式な名前、ドメイン、目的、および対象者は何か？
• どの製品、サービス、ドキュメンテーション、価格、ポリシー、およびサポートページが信頼できるか？
• どのページが、アーカイブ、キャンペーンページ、パラメータ、または重複した地域バージョンよりも優先されるべきか？
• サイトは実際のエージェント機能を公開しているか、それとも人間が読める情報のみか？
• 認証、レート制限、データ処理、商用条件、およびサポートはどこに文書化されているか？
• どの記述がアクセス制御ルールではなく、説明的なガイダンスか？
• ファイルの所有者は誰か、どのようなイベントが更新をトリガーするか、陳腐化はどのように検出されるか？

この投稿タイプを使用するタイミング

サイトに公開された耐久性のあるコンテンツが十分にあり、厳選された機械向けインデックスの恩恵を受けられ、そのメンテナンスを担当できる人物がいる場合に使用します。公開する理由は、检索システムの曖昧さを減らすためであり、単にもう一つのURLを作成するためではありません。

ガイダンスと制御を混同しないでください。robots.txt はクローラーのアクセス設定を表現し、XMLサイトマップはクローラーがURLを発見するのを助け、認証と認可はアクションが実行可能かを決定します。llms.txt は厳選されたコンテキストを提供します。llms.txtの一文は、アクセスを許可したり、取り消したり、秘密を保護したり、宛先ページの条件を上書きしたりすることはできません。

これらのビジネスタイプに最適

1. SaaS 。 最も適しています。ソフトウェア企業は通常、製品、機能、価格、統合、API、セキュリティ、ステータス、およびドキュメンテーションのソースが明確に分かれているためです。インデックスは各事実をどのページが保持しているかを解決でき、別の機能マニフェストは製品が実際にサポートするアクションのみを記述できます。
2. Eコマース 。 製品、配送、返品、在庫状況、カスタマーサービスポリシーが公開され正規である場合に適しています。変動の多いアイテムデータはフィードやAPIに保持し、インデックスはカタログをMarkdownにコピーするのではなく、それらの維持管理されたソースを指し示すために使用します。
3. マーケットプレイス 。 バイヤー、セラー、プロバイダー、およびプラットフォームのポリシーが異なる場合に価値があります。各対象者と法域をラベル付けし、エージェントがセラーのルールをバイヤーに適用したり、1つのリスティングからプラットフォームの在庫を推測したりしないようにします。
4. B2Bサービス 。 機能、業界、サービス範囲、エビデンス、調達資料、および連絡手段を明確にするのに役立ちます。交渉されたスコープやクライアント固有の約束を、普遍的な機械向けの主張に変換しないでください。
5. エージェンシー 。 企業が多くのサービス、方法論、ケーススタディ、および専門知識のページを維持している場合に有用です。クライアントポータル、資格情報、社内レポート、および内部プレイブックは公開ファイルに含めないでください。
6. 製造業および工業企業 。 システムを製品ファミリー、仕様、認証、マニュアル、販売代理店、および安全文書に誘導するのに役立ちます。インデックスは、管理された文書が権威である場合に、安全上重要な指示を決して言い換えてはいけません。

5つの安定したページを持つ小規模なブローシャーサイトは、もう一つの管理対象アーティファクトから得られる利益はほとんどありません。明確なコンテンツ所有者がいないサイトは、すぐに陳腐化するファイルを公開する前に、正規化、ナビゲーション、およびソースの品質を修正すべきです。

検索意図

検索意図 とは、クエリから期待される結果です。このタイプには、異なる意図を持つ2つの対象者がいます。機械は予測可能なルートパスを取得し、簡潔なMarkdown、安定した見出し、正規リンク、および装飾的なノイズがないことを期待します。人間の検索者は通常、実装ガイダンスを求めます：「llms.txtの例」「llms.txtに含めるべきもの」「エージェントマニフェストの形式」などです。公開された説明ページはこれらの質問に答えることができ、デプロイされた/llms.txtは機械による取得に最適化されたままです。

ファイル自体はキーワードのランディングページではありません。「ランキング」を上げるために、一般的な定義、繰り返されるカテゴリ用語、または数百のブログリンクを追加しないでください。余分な行はすべて注意を消費し、新たなメンテナンス義務を生み出します。1万のURLをダンプするよりも、明確な説明を持つ10の意図的なリンクを優先してください。

慣習や消費者のサポートは変更される可能性があるため、実装が何に基づいているかを明記し、普遍的な採用を主張しないでください。成功したフェッチは、ファイルがアクセス可能で解析可能であることのみを証明し、特定のAI製品がランキング、検索、トレーニング、または引用にそれを使用することを証明するものではありません。

ページ構造

ワード帯域は編集上の制約であり、目標ではありません。デプロイされたファイルは、1行1行監査できるほど簡潔に保つ必要があります。人間向けの実装ノートはより長くても構いませんが、機械ファイルにコピーしてはいけません。

典型的な厳選ファイルは約200〜700ワードです。長さは品質のシグナルではありません。適切なサイズとは、アイデンティティを確立し、消費者を維持管理されたソースに導き、重要な区別を隠さない最小のインデックスです。

必須要素

インデックスは最高の意味で退屈であるべきです：予測可能で、明示的で、差分を取りやすいこと。重要な解釈はオプションのリンクの前に配置し、部分的な読み取りで誤った結論に至らないようにします。

フロントマター

フロントマター仕様 に従ってください。この投稿タイプ仕様では、entity = "post-type-llms-txt-page" と schemaType = "Article" を使用します。特定の組織向けの人間向け実装ページでは、キャンペーン用語や日付ではなく、acme-ai-access-index のような安定した識別子を使用します。

Webページが実装を説明するため、Article を使用します。スキーママークアップ は可視コンテンツを記述し、生のテキストファイルを認識されたエージェントプロトコルに変えるものではありません。ページの可視コンテンツとテンプレートが関連要件を独立して満たさない限り、SoftwareApplication、Dataset、または HowTo としてマークしないでください。

生の /llms.txt ファイルには通常フロントマターがありません。フロントマターが公開出力に漏れてはいけないためです。運用メタデータはCMS、ジェネレーター設定、またはリポジトリレコードに保存します：正規ドメイン、ロケール範囲、所有者、ソースコレクション、生成モード、最終検証日、次回レビュールール、バリデーター結果、およびアラート送信先。ローカライズされたファイルが存在する場合は、選択ルールを文書化し、1つの明確な正規ルート応答を維持します。

完全な例

この架空のファイルは、SaaSプラットフォームの簡潔なインデックスを示しています。URL、製品、および機能は例であり、パターンが仕様です。

# Northstar Analytics

> Northstar Analyticsは運用チーム向けのレポートプラットフォームです。このインデックスは、製品、プラン、ドキュメンテーション、ポリシー、およびサポートされているエージェント機能を定義する公開ページを指し示します。

アクセス許可はrobots.txt、認証、および以下にリンクされたポリシーによって制御されます。このファイルはアクセスやコンテンツの再利用許可を付与するものではありません。

## 製品

- [製品概要](https://www.northstar.example/product): 現在の製品範囲とサポートされているレポートワークフロー。
- [プランと価格](https://www.northstar.example/pricing): 現在の公開プラン、含まれる機能、および請求条件。
- [統合](https://www.northstar.example/integrations): サポートされているデータソースと出力先システム。

## ドキュメンテーション

- [ドキュメンテーショントップ](https://docs.northstar.example/): 現在のユーザーおよび管理者向けドキュメンテーション。
- [APIリファレンス](https://docs.northstar.example/api/): 公開エンドポイント、スキーマ、認証、エラー、およびレート制限。
- [リリースノート](https://docs.northstar.example/releases/): 製品およびAPI動作の日付付き変更。

## 信頼とサポート

- [セキュリティ](https://www.northstar.example/security): セキュリティプログラムと現在の保証文書。
- [プライバシーポリシー](https://www.northstar.example/privacy): データ処理、保持、およびユーザーの権利。
- [サポート](https://www.northstar.example/support): サポートされている連絡手段とサービスステータスリンク。

## エージェント機能

- [レポートエクスポートアクション](https://docs.northstar.example/agents/export-report): 認証済みアクション契約、受け入れ可能な入力、出力形式、レート制限、およびエラー処理。利用可能性はユーザーのプランとロールに依存します。

## オプション

- [研究ライブラリ](https://www.northstar.example/research): 方法論と公開日付を含む独自のベンチマークレポート。

2026年8月27日にドキュメンテーション運用チームにより確認済み。正規の公開リソースレジストリから生成。製品、プラン、ポリシー、API、またはURLの変更後に検証してください。

この例では、実際の文書化されたアクション契約が存在する場合にのみ、1つの機能を宣言しています。製品にサポートされているエージェントアクションがない場合は、そのセクションを省略してください。検索ボックス、フォーム、または文書化されていないエンドポイントの存在から、トランザクション機能を推測しないでください。

/llms.txt とは別に保存されるエージェントマニフェストについても、同じ規律を守ってください。バージョン管理された形式、正規の識別子、本番エンドポイント、認証方法、許可された操作、入出力スキーマ、レート制限、同意の境界、エラー状態、およびポリシーURLを指定します。それを実際のシステムに対して検証してください。構文的に有効でも、無効化されたアクションを宣伝する宣言は依然として間違っています。

デザインギャラリー

生ファイルは意図的に視覚的デザインがほとんどありません。ギャラリーのバリエーションは、情報アーキテクチャ、スキャン順序、人間向け実装ページのモバイル読みやすさ、および運用エビデンスをテストすべきであり、装飾ではありません。

品質チェックリスト

以下のすべての該当するステートメントが真である場合にのみ公開してください：

• ファイルは、認証、リダイレクトループ、同意壁、またはレンダリングされたアプリケーションシェルなしで、意図されたルートURLで解決される。
• 応答は読み取り可能なプレーンテキストまたはMarkdownであり、UTF-8を使用し、コンテンツを表示するためにJavaScriptに依存しない。
• H1は正規の組織またはサイト名を示し、説明はスローガンなしで目的、対象者、および範囲を述べる。
• リンクされたすべてのURLは正規で、公開され、ポリシーによりインデックス可能で、到達可能であり、組織が所有するか、外部として明確にラベル付けされている。
• リンクの説明は宛先が保持する権限を述べる。「詳細を見る」などの一般的なアンカーテキストを繰り返さない。
• 主要な製品、価格、ドキュメンテーション、ポリシー、およびサポートソースがインデックスと一致する。
• アーカイブページ、検索結果、トラッキングパラメータ、重複ロケール、キャンペーンページ、および低価値のタグページは除外されている。
• 機能の主張は、ライブでサポートされ、認証された契約と一致し、関連する制約を含む。
• 秘密、トークン、プライベートエンドポイント、個人データ、クライアント文書、未公開のロードマップ項目、またはセキュリティ上重要な実装詳細は一切表示されない。
• アクセス、許可、ライセンス、およびポリシーに関する文言は、制御するソースを指し示し、インデックスによって矛盾しない。
• ファイルは、保証されたランキング、引用、トレーニング除外、または普遍的な消費者サポートを主張しない。
• ロケールと地域範囲は、価格、ポリシー、在庫状況、またはドキュメンテーションが異なる場合には明示的である。
• 所有者、ソースレジストリ、生成プロセス、および検証方法は、ファイルの外部または末尾に記録される。
• 壊れたリンク、予期しないリダイレクト、応答ステータス、コンテンツハッシュ、および必須セクションのチェックは、関連するデプロイ後に実行される。
• 検証日は、宛先、説明、機能、およびポリシーが実質的に確認された後にのみ変更される。

よくある間違い

ファイルをサイトマップとして扱うこと。 URLの完全なインベントリは優先順位付けを破壊し、レビューが困難です。XMLサイトマップは発見用に保持し、llms.txtは信頼できるソースと意味のあるグループを中心に厳選してください。

アクセス制御として扱うこと。 Markdownでのリクエストは実施レイヤーではありません。クロールルールはrobots.txtで表現し、プライベートリソースは認証で保護し、拘束力のある要件は関連するポリシーとシステム制御に配置してください。

宛先コンテンツをインデックスにコピーすること。 繰り返される価格、製品仕様、およびポリシーは乖離します。権威を特定するのに十分なだけ要約し、その後、維持管理されたソースにリンクしてください。

投機的な機能を公開すること。 文書化されていないフォームやAPIルートは、サイトをエージェント対応にするものではありません。認証、スキーマ、制約、エラー、および所有者がいる、本番でサポートされているアクションのみを宣言してください。

「念のため」すべてを含めること。 より多くのリンクは、より多くの曖昧さとより多くの障害点を生み出します。オプションのコンテンツは、主要セクションがカバーしない可能性のある検索ニーズに答えることで、含まれる価値を示すべきです。

プライベートな資料を露出させること。 公開された機械可読ファイルは公開です。ステージングホスト、内部API、認証情報、顧客エクスポート、未公開文書、または公開用に意図的に承認されていないセキュリティ詳細を決してリストしないでください。

ガバナンスなしで生成すること。 自動化は不良なソースデータを高速で複製できます。ジェネレーターには、承認されたソースレジストリ、除外ルール、決定論的な順序付け、検証、レビュー所有権、およびデプロイアラートが必要です。

生成されたファイルを手動で編集すること。 次回の生成で修正が上書きされます。ソースレコードまたはジェネレーターを修正し、再生成し、実質的な変更を記録してください。

サポートされていない成果を主張すること。 「これでAIからの引用が保証される」は、不確かな実装慣行を誤解を招く約束に変えます。アクセシビリティと検索のエビデンスは、可視性と引用の結果とは別に報告してください。

現実を確認せずに日付を更新すること。 新しいタイムスタンプは、死んだドキュメンテーションURL、名前変更されたプラン、または無効化されたアクションを修復できません。検証とは、すべての重要な宣言をその本番ソースと比較することを意味します。

内部リンク

人間向け実装ページは、作成者が機械インデックスをディレクトリ、ドキュメンテーションページ、またはポリシーと区別する必要がある場合に、SEO投稿タイプ へ上位リンクします。各運用上の主張は、その制御ソースにリンクします：製品範囲は製品ページへ、現在の価格は価格ページへ、動作はドキュメンテーションへ、許可はアクセス制御へ、義務はポリシーへ。

生ファイルは正規の絶対URLを使用すべきです。通常のサイトナビゲーションの外部で取得される可能性があるためです。事実ごとに1つの信頼できる宛先を優先してください。2つのページが重複する場合は、両方をリストする前に所有権を解決してください。インデックスはソース階層を公開すべきであり、内部の意見の相違を永続化すべきではありません。

Product、Documentation、Policies、Agent capabilities のような短く安定したセクション名を使用してください。ロケールバリアントは、実質的に異なる場合にのみ、明確にラベル付けされたグループに保持してください。すべてのブログ記事にリンクする必要はありません。耐久性のある研究やガイドのみを、システムがサイトの主題とエビデンスを理解するのに役立つ場合に選択してください。

インバウンドリンクも運用上重要です。ドキュメンテーション、開発者ポータル、およびAIアクセシビリティガイダンスは、メンテナーを実装記録へ導き、実装記録はライブファイルとバリデーターへ導くべきです。これにより、機械インデックスを乱雑にすることなく、人間向けのレビューパスが作成されます。

結果の測定方法

ファイルをまずインフラストラクチャとして測定し、次に可視性へのインプットとして測定してください。引用の増加は、公開後に両方が発生したという理由だけでllms.txtに帰属することはできません。

4つのレイヤーを追跡します：

• 可用性： ルートURLの応答ステータス、リダイレクト動作、コンテンツタイプ、エンコーディング、レイテンシ、レンダリング独立性、およびアップタイム。
• 整合性： 解析成功、必須セクション、重複URL、壊れたリンク、リダイレクト先、正規ミスマッチ、許可されていないドメイン、露出した秘密、およびコンテンツハッシュの変更。
• 鮮度： 実質的な検証からの経過日数、検証以降の宛先変更、ソースレジストリのカバレッジ、所有者の確認、および陳腐化修復までの時間。
• 成果： 法的および技術的に適切な場合の、特定可能なエージェントによるサーバーログフェッチ、インデックスされた宛先への訪問、AIによる優先正規ページの引用、および追跡対象のブランドまたは製品質問に対する回答精度。

デプロイ前にベースラインを確立します：どのURLが引用されているか、どの事実が誤って述べられているか、ルートファイルが存在するか、どのクローラーがそれをリクエストしているか。公開およびすべての重要な更新に注釈を付けます。1回のフェッチや引用をトレンドとして読み取らないように十分に長い観測期間を比較し、相関と因果関係の区別を保持します。

障害モードを直接テストします。リストされたURLのステージングコピーの名前を変更し、バリデーターが破損を検出することを確認します。正規マッピングを変更し、ジェネレーターがインデックスを更新することを確認します。管理されたテスト環境で機能を無効にし、マニフェストチェックが失敗することを確認します。これらのテストは、外部での採用ではなく、メンテナンスシステムを証明します。

結果の測定方法 を使用して、技術的可用性、機械表現、発見、引用、エンゲージメント、およびビジネス成果を分離します。AmICitedでは、エージェントアクセシビリティの下でライブファイルをレビューし、Cockpitレポート を使用して、デプロイ注釈とともに引用されたURLとAI可視性を観察します。信頼できる成功の主張は「ファイルは有効で最新であり、システムを意図されたソースに誘導する」であり、下流の可視性の変更には別個のエビデンスが必要です。

FAQ

よくある質問