# llms.txt 入門 — AI に「まず読むべき地図」を渡す提案
> llms.txt とは何か（Jeremy Howard が 2024 年に出したコミュニティ提案、狙いは学習ではなく推論時のキュレーション、ファイル仕様と llms-full.txt、記事ごとの .md 版）を一次情報で解説し、robots.txt / sitemap.xml との違い、採用状況、そして「本当に効くのか」という賛否——Google の否定的見解や実測データ——まで両論併記で押さえます。最後に、このサイト自身が llms.txt をどう出しているかを実例として開きます。
- 出典: SUZ-LAB（解説トピック）
- URL: https://suz-lab.co.jp/topics/llms-txt
- 公開: 2026-07-10
- 更新: 2026-07-10
- タグ: #llms.txt #AI #生成AI #SEO #機械可読 #Next.js #単一の出所
---
Web には人間向けの見た目（HTML＋CSS）と、[機械向けの意味の層](/topics/json-ld-structured-data)がある。
サイトを機械に読ませる規約は、これまで検索エンジン向けの robots.txt / sitemap.xml が中心だった。
そこへ **2024 年、「読み手が LLM ならどうあるべきか」を問い直す提案**として登場したのが **llms.txt** だ。
この記事は、llms.txt の**仕組み**（何を、誰に向けて渡すのか）と**位置づけ**（既存レイヤーとどう違うのか）を
一次情報で解説し、そのうえで **「本当に効くのか」という賛否**——強い懐疑論も含めて——をフェアに扱う。
最後に、**このサイト自身**が llms.txt をどう出しているかを開き、机上の理論ではなく動いている実装として見せる。
## llms.txt とは — 標準ではなく「提案」
llms.txt は、[fast.ai](https://www.fast.ai) / Answer.AI の共同創業者 **Jeremy Howard** が
**2024 年 9 月 3 日**に公開した提案だ。正典の仕様は [llmstxt.org](https://llmstxt.org/) にあり、
議論は GitHub の [answerdotai/llms-txt](https://github.com/answerdotai/llms-txt) で続いている。
**llms.txt は確定した公式標準ではなく、原典自らが「a proposal（提案）」と呼ぶコミュニティ規約**だ。
W3C 勧告でも IETF RFC でもない。「標準になった」と書くと事実に反する。一部で採用が進み、事実上の
慣習として扱う向きもあるが、普及度はまだ限定的だ（後述）。この段階を正しく踏まえて読んでいく。
### 狙いは「学習」ではなく「推論時」
最大の誤解しやすい点がここだ。llms.txt は **AI にサイトを学習させる／させない**を制御する仕組みでは**ない**。
仕様は逐語でこう述べている。
> `llms.txt` will mainly be useful for _inference_, i.e. at the time a user is seeking assistance,
> as opposed to for training.
> （llms.txt は主に**推論時**——ユーザーが支援を求めているその瞬間——に役立つ。学習用ではない。）
つまり狙いは、ユーザーの質問に答えようとする AI が、**その場でサイトの文脈を効率よく組み立てる**のを助けること。
学習の許可／拒否は robots.txt など別のレイヤーの仕事であり、llms.txt はそこには踏み込まない。仕様も
「学習目的のコンテンツ利用を許可・拒否するためのものではない」と明言している。
なぜ「その場で助ける」必要があるのか。人間向けの HTML はナビ・広告・装飾で本文が薄まり、
LLM の**限られた文脈窓**には収まりにくい。sitemap を全部たどれば理屈の上では全ページに届くが、
全ページ分を合わせると文脈窓に収まらず、しかも各ページに機械可読な本文版があるとは限らない。そこで
**「まず読むべき厳選リスト」を 1 枚のプレーンな Markdown で置く**、というのが llms.txt の発想だ。
## ファイル仕様 — 何を、どう書くか
`/llms.txt` はサイトのルートに置く **1 枚の Markdown ファイル**で、構造は驚くほど小さい。
| 要素 | 必須 | 役割 |
| --- | --- | --- |
| **H1** | ✅ **唯一の必須** | プロジェクト／サイト名 |
| blockquote 要約 | 任意 | サイトを一文で説明する `>` の引用 |
| Markdown 段落 | 任意 | 見出し以外の補足説明（詳細情報・注意書き） |
| **H2＋リンクリスト** | 任意 | セクションごとに `[name](url): ノート` を列挙 |
| `## Optional` 節 | 任意 | 文脈窓が厳しいとき**丸ごと省いてよい**二次情報 |
リンクリストの各項目は「必須の `[name](url)` に、任意で `:` とノートを添える」形。`## Optional`
という特別な見出しは、「本質ではないので短い文脈では飛ばしてよい」と AI に伝える逃がし弁になっている。
### llms.txt と llms-full.txt の違い
仕様は、索引だけでは足りない場合の随伴ファイルとして **`/llms-full.txt`** にも触れる。
両者の役割は明確に分かれる。
- **`/llms.txt`** … サイトの**地図・メニュー**。リンクと一行要約だけの索引。軽い。
- **`/llms-full.txt`** … 全ページの**本文を 1 ファイルに連結**した全文版。重いが、AI が
サイト全体をそのまま文脈窓へ投入できる。
「まず地図を渡し、深く要るなら全文を渡す」——この二段構えが基本形だ。
### もうひとつの提案 — ページごとの `.md` 版
見落とされがちだが、仕様は**併せて**こう提案している。
> provide a clean markdown version of those pages at the same URL as the original page,
> but with `.md` appended.
> （有用なページは、元 URL に `.md` を付けた同一 URL で、体裁を剥いだ Markdown 版を提供する。）
例えば `/topics/llms-txt` に対して `/topics/llms-txt.md` を用意する、という慣習だ。索引（llms.txt）で
「ここを読め」と指した先に、**AI がそのまま消化できる生 Markdown** が待っている状態を作る。
## robots.txt・sitemap.xml との違い — 置き換えではなく補完
「また新しいファイルか、robots.txt と何が違う」と身構えるところだが、三者は**役割が根本的に異なり、
どれも他を置き換えない**。
| ファイル | 主な読み手 | 役割 | ひとことで |
| --- | --- | --- | --- |
| **robots.txt** | クローラ全般 | アクセスの**許可／拒否** | 入場ゲート（排除） |
| **sitemap.xml** | 検索エンジン | **全ページの網羅的な発見** | 全部の住所録 |
| **llms.txt** | 推論時の LLM | **厳選した文脈への案内** | 宝の地図（キュレーション） |
ある業界ガイド（[Search Engine Land](https://searchengineland.com/llms-txt-isnt-robots-txt-its-a-treasure-map-for-ai-456586)）は
これを「llms.txt は robots.txt ではない——AI のための**宝の地図**だ」と表現した。
robots.txt が「入っていいか」を、sitemap が「どこに何があるか（全部）」を扱うのに対し、llms.txt は
「**まず何を読むべきか（厳選）**」を扱う。守備範囲が違うので、三つとも併存させるのが各ガイドの一致見解だ。
## 採用状況 — 増えているが、まだ限定的
数字は必ず**出典と時点を添えて**読むこと（この分野は月単位で動く）。
- **上位 1 万件のうち約 5.61%** が有効な llms.txt を持つ（2026 年 6 月、HTTP Archive / CrUX
ベースの [caseyrb.com 調査](https://caseyrb.com/blog/state-of-llms-txt-adoption/)。7,504 件中 421 件）。
- **上位 1,000 件のうち 8.7%**（到達可能サイトに限れば 15.8%。Tranco ベースの
[rankability.com 調査](https://www.rankability.com/data/llms-txt-adoption/)）。
- コミュニティ主導のディレクトリ [llmstxt.cloud](https://directory.llmstxt.cloud/) には
2026 年時点で約 849 サイトが登録（ただし **opt-in の自己申告**で、「AI に実際に読まれている」証拠ではない）。
llms.txt は手書きもできるが、静的サイトジェネレータのプラグインや、既存サイトを走査して
草案を吐く生成ツール（Firecrawl など）も増えている。一方で実装の落とし穴も共有されている。
- **全ページの `.md` 複製を無造作に作らない。** インデックスさせると重複コンテンツで
クロールバジェットを希釈し、本家ページの順位をむしろ下げうる。生 Markdown 版は
noindex にするか、canonical で HTML 版を指すのが定石。
- **同じ URL を複数セクションに重複列挙しない。** 1 つの意図＝1 つの canonical URL に寄せる。
- **SEO 目的のキーワード詰めは効かない。** 主要 LLM が llms.txt からキーワード密度を
抽出している証拠はなく、詰め込みは直接取得した AI に低品質と映るアンチパターン
（[llmtxt.info のベストプラクティス](https://llmtxt.info/best-practices/)）。
## 本当に効くのか — 両論併記
**llms.txt が実際に AI に読まれ、効果を上げているという証拠は、2026 年前半時点でまだ弱い。**
採用を推す声も、無意味だとする声もある。ここでは両方を、事実として並べる。
**懐疑側の主要な論拠:**
- **Google の John Mueller は否定的だ。** 「知る限りどの AI サービスも llms.txt を使うとは言っておらず、
サーバログを見ても（来ていないと）分かる」とし、現状を **「purely speculative for now（今のところ
完全に投機的）」**、廃れた keywords メタタグになぞらえた
（[Search Engine Journal](https://www.searchenginejournal.com/google-says-llms-txt-is-purely-speculative-for-now/577576/)）。
Google 系サイトに llms.txt が現れたのは社内 CMS の自動対応の副産物で、Search チームは自分たちの
ドキュメントからは削除している。Bluesky で「これは endorsement（推奨）か」と問われ、明確に
**「to be direct, no（率直に言って、ノー）」**と答えた
（[Search Engine Roundtable](https://www.seroundtable.com/google-does-not-endorse-llms-txt-40789.html)）。
- **実測でも流入はごくわずか。** GEO 監視ベンダー OtterlyAI の 90 日計測では、AI ボットからの
リクエスト 62,100 件超のうち llms.txt に来たのは **わずか 84 件（0.1%）** だった
（[OtterlyAI](https://otterly.ai/blog/the-llms-txt-experiment/)）。ただしこれは**単一サイト・
1 期間・ベンダー自己公表**の一データ点である点は割り引いて読む。
**注意して避けたい過剰主張（両方向）:**
- ❌ 「OpenAI・Anthropic・Perplexity が**クロール時に llms.txt を参照し始めている**」——
採用側でよく引かれるが、**一次的な技術証拠は確立していない**。断定して書けない。
- ❌ 「主要 AI は**どれも読んでおらず、完全に無意味**」——これも言い過ぎ。正確には
**「Google は使っていないと明言」「大規模計測でも流入はごく少数」**にとどめるべきで、
全プロバイダの挙動を否定する根拠まではない。
要するに、**「効くと確認されてはいないが、無意味と確定してもいない」**——これが 2026 年前半の
現在地だ。Mueller の見解も Google の公式ポリシー文書ではなく本人のコメントである点を添えておく。
## このサイト自身の llms.txt
ここまでの理論を、このサイト（`apps/web`）はそのまま実装している。抽象論ではなく**動いている実例**だ。
SUZ-LAB の Mission は「一次情報として発信する」こと。2026 年のいま、情報を集めるのは人間だけではなく、
Claude / ChatGPT / Perplexity のような AI も読み、要約し、引用する。ミッションを額面どおり受け取れば
**発信先には AI も含まれる**。だから「主要 AI が使うと確約したから対応する」のではなく、
**「発信先に AI がいるなら、機械可読な入口を用意しておくのが筋だ」**という順序で実装している。
賛否が定まる前に態度で先に動く——この姿勢は[ドッグフーディング](/topics/dogfooding)や、
[VMOST → Roadmap → Log を一本の線でつなぐ](/logs/connecting-vmost-roadmap-logs)ときと同じだ。
実装の全体像は実験ログ [サイトを機械可読にした](/logs/making-suz-lab-machine-readable) に残した。
**1. `/llms.txt` — 仕様に忠実な索引。** H1（サイト名）＋タグラインの blockquote に続けて、
VMOST・Roadmap（進行中のみ）・Topics・Logs・Glossary・Feeds を、各正規 URL と一行要約で列挙する。
組み立ては `lib/llms.ts` の一関数に集約。
```ts
// src/lib/llms.ts（要約）
const lines: string[] = [
`# ${SITE.name}`,
`> ${SITE.tagline}`,
``,
`このページは AI 向けの索引です。構造化データが必要なら公開 MCP サーバを推奨します:`,
`- MCP (Streamable HTTP): ${abs("/api/mcp")}`,
`- 全文版（全記事の本文を連結）: ${abs("/llms-full.txt")}`,
// …VMOST / Roadmap（進行中のみ）/ Topics / Logs / Glossary / Feeds
];
```
冒頭で **MCP と全文版へ誘導**しているのがポイント。索引で足りない AI に「構造化データなら
[公開 MCP サーバ](/logs/building-the-public-mcp-server)、全文が要るなら llms-full.txt」と次の一手を示す。
**2. `/llms-full.txt` と、記事ごとの生 Markdown。** 全文版は全記事の本文を 1 ファイルに連結し、
記事境界を罫線で区切る。さらに各記事は `/logs//llms.txt`・`/topics//llms.txt` で、
**体裁を剥いだ生 Markdown＋引用用メタ**（正規 URL・公開／更新日・柱・タグ）を返す。
> 仕様が提案する「元 URL に `.md` を付ける」形（例 `/topics/llms-txt.md`）に対し、このサイトは
> `[slug]` 配下に `llms.txt` セグメントを置く形（`/topics/llms-txt/llms.txt`）を採った。
> 「人間向けページの隣に生テキスト版がある」関係を URL で表す狙いは同じで、Next.js の
> ルーティングに素直に乗る方を選んだ——という設計判断だ。
**3. robots.txt で AI クローラを「明示的に」許可する。** 既定の `*` でも通るのに、主要な AI クローラ
（`GPTBot`・`ClaudeBot`・`PerplexityBot`・`Google-Extended`・`CCBot` …）をあえて列挙して全面許可する。
```ts
// src/app/robots.ts（要約）
const AI_CRAWLERS = [
"GPTBot", "OAI-SearchBot", "ChatGPT-User",
"ClaudeBot", "Claude-Web", "anthropic-ai",
"PerplexityBot", "Google-Extended", "CCBot", /* … */
];
```
技術的には不要な列挙をなぜするのか——それはこのサイトの方針が「AI への発信」だからだ。
**設定は挙動だけでなく態度も表す。** 将来「この学習クローラには拒否したい」と決めたとき、そのボットだけを
`disallow` に振り分ける切り替え口にもなる。llms.txt が用途許諾を扱わないぶん、その意思表示はここで行う。
**4. 値の出所は 1 か所、各レイヤーは「写すだけ」。** llms.txt・全文版・生 Markdown・JSON Feed 1.1・
RSS・[JSON-LD](/topics/json-ld-structured-data)（用語辞書を `DefinedTermSet` で公開）——出力形式は
これだけあるが、値の出所はすべて `content/*`。記事を 1 本足すと、索引も全文版も Feed も sitemap も
自動で追従する。**文言も URL 規則も最終更新日の定義も二重に持たない。** 前掲の「重複コンテンツのワナ」を
回避できるのは、この単一の出所の規律があるからだ。
**5. llms.txt と MCP は両輪。** llms.txt のような静的ファイルとは別に、AI がツールで問い合わせる
接続型の道（MCP や、ブラウザ側の [WebMCP](https://github.com/webmachinelearning/webmcp) 提案）も動いており、
AI へサイトを開く道は 1 本ではない。このサイトは
**「クロールして回る AI・URL を素朴に叩く AI」向けに llms.txt を、「接続してくる AI」向けに
[読み取り専用の MCP サーバ](/logs/building-the-public-mcp-server)を**——と両輪で用意している。
どちらが主流になっても、出所が 1 つなら両方を安く維持できる。
## これから — 効いているかを、自分で測る
この分野で唯一確かなのは「まだ誰も確実なことを言えない」ことだ。ならば SUZ-LAB にできる一次情報の発信は、
**自分のサーバログで「実際にどの AI ボットが `/llms.txt` や記事ごとの生 Markdown を取得しているか」を計測して
公開する**ことだろう。Mueller が「サーバログを見れば分かる」と言うなら、こちらもログを見て、賛否の議論に
自前のデータ点を 1 つ足せばいい。それは[アクセス解析・KPI 計測](/roadmap)を進める先の、格好の実験ログのネタになる。
---
**まとめ。** llms.txt は、AI に「まず読むべき厳選リスト」を 1 枚の Markdown で渡す**提案**だ。
狙いは学習ではなく**推論時のキュレーション**で、robots.txt（排除）や sitemap（網羅）を置き換えず**補完**する。
仕様は H1＋要約＋リンクリストと小さく、`llms-full.txt` と `.md` 版ページが随伴する。ただし
**主要 AI が実際に使う証拠は弱く、Google は否定的で、実測の流入もごくわずか**——効果は賛否が割れている。
このサイトは「効くと証明されたから」ではなく「発信先に AI がいるから」実装し、値の出所を 1 か所にまとめ、
MCP と両輪で構えている。考え方の全体像は [VMOST とは](/topics/vmost)、実装の記録は
[サイトを機械可読にした](/logs/making-suz-lab-machine-readable) にある。