llms.txt v2 で既存のファイルは壊れますか？

いいえ。ファイル形式は変わっていません。v1 準拠の llms.txt は v2 準拠です。変更点は発見性（リンクリレーション）、サブパスの意味、ツールへの期待であり、Markdown の構造ではありません。

llms.txt v2 の rel="describedby" は何のためですか？

ページから、そのページをカバーする llms.txt ファイルを指すためのもので、エージェントが URL を推測しなくて済みます。HTML の要素でも HTTP の Link: レスポンスヘッダーでもよく、ヘッダー形式は HTML 以外のファイルでも機能します。

llms.txt をサイトのルート以外に置けますか？

置けます。v2 はその意味も定義しています。ファイルは自身のパス配下のページをカバーし、複数が該当する場合はエージェントは最も具体的なものを使います。つまり /docs/llms.txt は /docs/ 配下のすべてをカバーします。

llms_txt2ctx はまだ仕様の一部ですか？

いいえ。v2 はコンテキスト展開ツールを削除し、それに伴い「Optional」セクションの機械的な意味も削除しました。Optional セクションは副次的なリンクの慣習として今も許容されています。

llms-full.txt は仕様にありますか？

ありません。どちらのバージョンにもありませんでした。大規模なドキュメント群に対する一般的な業界慣行で、有用ですが必須ではありません。

ガイド

llms.txt v2 の変更点

公開日: 2026-08-31

llms.txt の提案が、初版から約2年を経て2026年8月に改訂されました。ファイル形式そのものは変わっていません。v1 のファイルは今も有効な v2 のファイルです。変わったのはファイルを取り巻くすべて、つまりエージェントがどうやってそれを見つけるか、そして仕様がどんなツールを前提とするかです。

形式は変わらない

要求される構造は以前とまったく同じです。任意の BOM、プロジェクト名を書いた H1（今も唯一の必須要素）、ブロック引用による要約、見出しを含まない任意の本文、そして Markdown のリンクリストを含む0個以上の H2 セクション。v1 で100点だったファイルは、今も100点です。

1. エージェントが URL を推測しなくて済むリンクリレーション

これが実質的な追加であり、2年間の普及を通じて最も多かった要望への回答です。あるページが与えられたとき、エージェントはその Markdown 版や、そのページをカバーする llms.txt を、URL を推測せずにどう見つけるのか？

v2 はこれに2つの標準的なリンクリレーションで答えます。

rel="describedby" — このページをカバーする llms.txt を指す。
rel="alternate" type="text/markdown" — このページの Markdown 版を指す。

どちらも HTML の <link> 要素として書けます。

<link rel="describedby" href="/llms.txt">
<link rel="alternate" type="text/markdown" href="/docs/page.html.md">

…あるいは HTTP レスポンスヘッダーとしても書けます。Markdown ファイル自体のような HTML ではないリソースではこれが唯一の手段で、ページを1つも触らずに Web サーバーや CDN の設定で付与できます。

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

これまで rel="alternate" type="text/plain" でファイルを告知するという助言に従っていた場合（当サイトの以前のガイドも含みます）、rel="describedby" に置き換えてください。仕様に定めがなかった間は妥当な慣習でしたが、今は定めがあります。

2. .md の URL 形式は2つとも許容

v1 はページの Markdown 版の URL 形式を1つに定めていました。ページの完全な URL に .md を付けるので、page.html は page.html.md になります。しかし実際には、拡張子を置き換えて page.md を出力する公開ツールがいくつもありました。v2 は両方を認めます。ファイル名を含まない URL には index.html.md または index.md を付けます。

ここに移行作業はありません。すでに出力している形式が、そのまま正しい形式になりました。

3. サブパスのファイルが正式に定義された

v1 はルート以外の llms.txt を許容していましたが、その意味を語っていませんでした。v2 は定義します。ファイルは自身のパス配下のページをカバーし、複数が該当する場合はエージェントは最も具体的なものを使う。つまり /docs/llms.txt は /docs/ 配下のすべてをカバーし、ドキュメントページを読むエージェントはルートのファイルよりそれを優先します。

これはホストではなくパスだけを管理している人にとって重要です。GitHub Pages のプロジェクトサイト、共有ドメイン上のドキュメント区画などです。仕様が /.well-known/ ではなく従来どおりのファイル名を採る理由もここにあります。well-known はオリジンのルートにしか存在できません。

実務上の帰結として、エージェントにとって価値があるのがドキュメントなのであれば、それ専用の /docs/llms.txt はもうグレーゾーンではなく、正当な選択肢です。

4. コンテキスト展開ツールは廃止（「Optional」も機構を失った）

v1 は llms.txt を1つの LLM コンテキストへ展開する llms_txt2ctx を紹介していました。v2 はこれを取り下げ、代わりに期待を直接述べます。エージェントは llms.txt を閲覧または検索し、必要なリンクをたどる。したがってリンクは LLM が扱いやすいコンテンツを指すべきであり、ファイル自体はコンテキストに収まる小ささを保ちます。

そのツールが消えたことで、## Optional セクションの機械的な意味も消えました。この意味は、そうしたツールに何を省くか伝えるために存在していたものです。Optional セクションは今も許容され、エージェントが省略できる副次的なリンクの慣習として今も有用です。ただ、自動的な処理を駆動することはもうありません。

なお llms-full.txt は、どちらのバージョンでも仕様の一部ではありませんでした。広く採用されている業界慣行で、大規模なドキュメント群には有効ですが、要件として扱わないでください。

今週やるべきこと

llms.txt を指す rel="describedby" を追加する — レイアウトに1行、あるいは CDN のヘッダールール1つ。
Markdown 版を公開しているなら、rel="alternate" type="text/markdown" で告知する。
rel="alternate" type="text/plain" による告知はすべて rel="describedby" に置き換える。
価値のある部分がドキュメントなら、専用の /docs/llms.txt を検討する。
バリデータを再実行する — ページが v2 のリレーションを告知しているかを報告し、サブパスのファイルも v2 がエージェントに求めるとおりにたどります。

なぜ改訂されたのか

前提が推測でなくなったからです。2024年9月に llms.txt が提案された当時、「エージェントがあなたのサイトを読む」は予測でした。今ではドキュメントプラットフォームがこのファイルを自動生成し、Chrome の Lighthouse は agentic browsing のチェックの一部としてサイトにこのファイルがあるか監査し、AI ラボ自身が自社の開発者ドキュメント向けに llms.txt を公開しています。v2 は、提案の前提が現実の普及によって検証されたあとの姿です。

続きを読む

あなたの llms.txt を検証する →