llms.txtは、AIエージェントにサイトの概要と参照先を案内するMarkdownファイルの提案です。llms-full.txtは本文をまとめて渡すために提供される全文ファイルで、索引とは役割が異なります。設置だけでAIが自動取得することや、検索順位が上がることは保証できません。

llms.txtの書き方と提案の範囲

公式提案では、サイト名のH1を先頭に置き、概要の引用、補足、H2で分けたリンク一覧の順で構成します。必須なのはH1だけです。リンクには短い説明を付け、可能ならHTMLより読み取りやすいMarkdown本文へ案内します。

配置例は/llms.txtや/docs/llms.txtです。v2では配置したパスの配下を対象とし、複数が当てはまる場合は最も具体的なパスのファイルを使う考え方です。変更点では、Optionalは補足リンクの慣習として残り、ツールが必ず省略する特別な制御ではないと説明しています。

自作するときは、最初に読んでほしい導入、APIリファレンス、制約の順に選ぶと整理できます。全URLを並べることより、どの資料で何が分かるかを明確にすることを優先します。

実在する公開ドキュメントを使う記述例

次はgenko.meの公開URLを使った、自作する場合の最小例です。実際に配信されているファイル全体の転載ではありません。

markdown
# genko.me docs
> Public documentation for integrating genko.me.
## SDK
- [Client](https://docs.genko.me/sdk/client.md): Configure the client.
## Optional
- [Full text](https://docs.genko.me/llms-full.txt): Read all documentation.

実際の日本語の索引には各ページへのMarkdownリンクと説明があり、末尾から全文ファイルへ進めます。英語の索引もあり、日本語は接頭辞なし、英語は/en/付きのURLです。取得方法が示す対象は公開ドキュメントです。ワークスペース内の記事やAPIキーを公開する機能ではありません。

llms-full.txtとの違い

ファイル

内容

使いどころ

llms.txt

概要、説明付きリンク

資料を選び、必要なページだけ取得する

llms-full.txt

複数ページの本文をまとめたもの

全体を一度に渡して検討する

llms-full.txtは現在の提案に含まれておらず、名前だけで収録範囲や構造が決まるわけでもありません。genko.meではドキュメントの説明に沿って全ページの本文を提供しています。別サイトの同名ファイルも同じ内容になるとは限りません。

普段は索引と個別ページを使います。全文は長くなるため、入力上限、転送量、読む必要のない情報を確認します。全文が入力上限を超える場合は、必要な章だけを取得してください。ローカルへ保存したコピーも、更新のたびに取り直す必要があります。

CMSやドキュメントからTypeScriptで生成する

CMSの製品ごとのAPIを生成処理へ直接埋め込まず、公開用データを共通形式に変換してから出力すると保守しやすくなります。次の例は、取得済みのMarkdownを静的ファイルへ変換します。API取得やHTML変換を行うコードではありません。

入力を公開用のJSONにそろえる

CMSからの取得時にページ送りを最後まで処理し、公開できる版だけを選びます。本文がHTMLやブロックJSONなら、見出し、リンク、コードを保持する変換処理を別に用意します。MDXもコンポーネントを含むまま渡さず、読めるMarkdownへ変換します。

cms-public.jsonの入力例です。架空サイトのデータで、publishedは自分で正規化する公開可否の値です。各CMSに同名のフィールドがあるという意味ではありません。

json
[  {    "slug": "guide",    "title": "Guide",    "summary": "Setup instructions",    "markdown": "## Setup\n\nInstall the SDK.",    "published": true  }]

索引・本文・全文を同時に出す

Node.js 24でgenerate-llms.mtsとして保存し、node generate-llms.mtsで実行します。型注釈を除去して実行するため、このコマンド自体は型検査をしません。Node.jsのTypeScript実行仕様も確認してください。originを自分の公開サイトに変更します。

typescript
import { mkdir, readFile, writeFile } from "node:fs/promises";
type Page = {  slug: string;  title: string;  summary: string;  markdown: string;  published: boolean;};const origin = "https://example.com";const rows = JSON.parse(await readFile("cms-public.json", "utf8")) as Page[];const pages = rows.filter((p) => p.published === true);const seen = new Set<string>();for (const p of pages) {  if (!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(p.slug) || seen.has(p.slug)) {    throw new Error("Invalid or duplicate slug");  }  seen.add(p.slug);}const line = (s: string) => s.replace(/[\r\n]+/g, " ");const label = (s: string) => line(s).replace(/[\\[\]]/g, "\\$&");const url = (p: Page) => `${origin}/docs/${p.slug}.md`;const body = (p: Page) =>  `# ${line(p.title)}\n\nSource: ${url(p)}\n\n${p.markdown.trim()}\n`;const index = [  "# Example docs", "", "> Public integration documentation.", "", "## Docs", "",  ...pages.map((p) => `- [${label(p.title)}](${url(p)}): ${line(p.summary)}`),  "", "## Optional", "",  `- [Full text](${origin}/llms-full.txt): All selected pages.`, "",].join("\n");await mkdir("public/docs", { recursive: true });for (const p of pages) await writeFile(`public/docs/${p.slug}.md`, body(p));await writeFile("public/llms.txt", index);await writeFile("public/llms-full.txt", pages.map(body).join("\n"));

入力JSONの形は検証済みという前提の短い例です。実運用ではスキーマ検証、API取得失敗時の中断、記事数の確認も追加します。下書き除外の条件だけに頼らず、取得する版自体が公開版であることを保証してください。

出力先は空のビルド用ディレクトリを前提にします。このコードは古いファイルを削除しないため、以前公開したページを取り下げる場合は、残存する.mdも配信対象から外す仕組みが必要です。

Next.jsはpublicフォルダーの静的ファイルを配信できます。このコードの出力先をpublicにして、生成処理をビルドの前に実行する構成にします。CMS更新時にはHTMLだけでなく索引・本文・全文を同じ世代に更新します。更新経路の設計はNext.jsのWebhookと再検証も参考になります。動的な再検証だけでは、この静的ファイルは書き換わりません。

robots.txt・sitemap.xmlとの役割の違い

ファイル

主な役割

llms.txtで代替できるか

robots.txt

クローラーへアクセス方針を伝える

できません

sitemap.xml

ページのURLや更新情報を伝える

できません

llms.txt

読む資料の入口をまとめる

他の2つと併用します

Googleのrobots.txt説明では、クロール制御は機密保護ではなく、拒否したURLが検索結果に出る場合もあります。サイトマップも発見を助けるもので、登録やクロールを保証しません。llms.txtに「学習禁止」と書いても認証やアクセス制御にはならず、非公開情報はファイル自体にもリンク先にも載せない設計が必要です。

分かっていることと、保証できないこと

確認できるのは提案の形式と、各サイトがファイルを公開している事実です。公開していることと、特定のAI製品が回答時に常に読むことは別です。採用状況を判断する際は、その製品自身の公式説明で利用方法まで確認します。

GoogleのAI検索機能の説明は、AI OverviewsやAI Modeに掲載されるために新しいAI用テキストファイルは不要としています。これを「すべてのAIがllms.txtを無視する」という意味にも広げません。

導入の成果は検索順位ではなく、リンク切れの有無、目的の資料にたどり着けるか、本文がHTML版と一致するかで確認します。自分のツールでURLを明示して必要な本文を読ませる検証はできますが、自動発見や外部製品での引用とは分けて評価します。運用全体で渡す情報の整理にはAIエージェントとCMSの連携も参照してください。

よくある質問

llms.txtは必須ですか?

提案への対応は任意です。公開資料を渡す入口として使えますが、通常のサイト公開やGoogleのAI検索機能への掲載に必須という意味ではありません。

llms-full.txtだけ置けば十分ですか?

全文だけでは読む範囲を絞りにくくなります。短い索引と個別Markdownを用意し、全文は必要な場合に選べる形にすると扱いやすくなります。

CMSが対応していないと生成できませんか?

公開本文を取得できれば、サイト側のビルド処理で生成できます。取得権限、公開版の選別、本文変換、更新タイミングは自分の構成に合わせて実装します。

設置すればAIの回答や検索順位に反映されますか?

設置だけで反映されるとは保証できません。ファイルを読める状態にする作業と、外部サービスが実際に採用・引用するかの確認は別です。