llms.txt 入門 — AI に「まず読むべき地図」を渡す提案

Web には人間向けの見た目（HTML＋CSS）と、機械向けの意味の層がある。 サイトを機械に読ませる規約は、これまで検索エンジン向けの robots.txt / sitemap.xml が中心だった。 そこへ 2024 年、「読み手が LLM ならどうあるべきか」を問い直す提案として登場したのが llms.txt だ。

この記事は、llms.txt の仕組み（何を、誰に向けて渡すのか）と位置づけ（既存レイヤーとどう違うのか）を 一次情報で解説し、そのうえで 「本当に効くのか」という賛否——強い懐疑論も含めて——をフェアに扱う。 最後に、このサイト自身が llms.txt をどう出しているかを開き、机上の理論ではなく動いている実装として見せる。

llms.txt とは — 標準ではなく「提案」

llms.txt は、fast.ai / Answer.AI の共同創業者 Jeremy Howard が 2024 年 9 月 3 日に公開した提案だ。正典の仕様は llmstxt.org にあり、 議論は GitHub の 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 ファイルで、構造は驚くほど小さい。

リンクリストの各項目は「必須の [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 と何が違う」と身構えるところだが、三者は役割が根本的に異なり、 どれも他を置き換えない。

ある業界ガイド（Search Engine Land）は これを「llms.txt は robots.txt ではない——AI のための宝の地図だ」と表現した。 robots.txt が「入っていいか」を、sitemap が「どこに何があるか（全部）」を扱うのに対し、llms.txt は 「まず何を読むべきか（厳選）」を扱う。守備範囲が違うので、三つとも併存させるのが各ガイドの一致見解だ。

採用状況 — 増えているが、まだ限定的

数字は必ず出典と時点を添えて読むこと（この分野は月単位で動く）。

• 上位 1 万件のうち約 5.61% が有効な llms.txt を持つ（2026 年 6 月、HTTP Archive / CrUX ベースの caseyrb.com 調査。7,504 件中 421 件）。
• 上位 1,000 件のうち 8.7%（到達可能サイトに限れば 15.8%。Tranco ベースの rankability.com 調査）。
• コミュニティ主導のディレクトリ 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 のベストプラクティス）。

本当に効くのか — 両論併記

llms.txt が実際に AI に読まれ、効果を上げているという証拠は、2026 年前半時点でまだ弱い。 採用を推す声も、無意味だとする声もある。ここでは両方を、事実として並べる。

懐疑側の主要な論拠:

• Google の John Mueller は否定的だ。 「知る限りどの AI サービスも llms.txt を使うとは言っておらず、 サーバログを見ても（来ていないと）分かる」とし、現状を 「purely speculative for now（今のところ 完全に投機的）」、廃れた keywords メタタグになぞらえた （Search Engine Journal）。 Google 系サイトに llms.txt が現れたのは社内 CMS の自動対応の副産物で、Search チームは自分たちの ドキュメントからは削除している。Bluesky で「これは endorsement（推奨）か」と問われ、明確に **「to be direct, no（率直に言って、ノー）」**と答えた （Search Engine Roundtable）。
• 実測でも流入はごくわずか。 GEO 監視ベンダー OtterlyAI の 90 日計測では、AI ボットからの リクエスト 62,100 件超のうち llms.txt に来たのは わずか 84 件（0.1%） だった （OtterlyAI）。ただしこれは単一サイト・ 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 がいるなら、機械可読な入口を用意しておくのが筋だ」**という順序で実装している。 賛否が定まる前に態度で先に動く——この姿勢はドッグフーディングや、 VMOST → Roadmap → Log を一本の線でつなぐときと同じだ。 実装の全体像は実験ログ サイトを機械可読にした に残した。

1. /llms.txt — 仕様に忠実な索引。 H1（サイト名）＋タグラインの blockquote に続けて、 VMOST・Roadmap（進行中のみ）・Topics・Logs・Glossary・Feeds を、各正規 URL と一行要約で列挙する。 組み立ては lib/llms.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 サーバ、全文が要るなら llms-full.txt」と次の一手を示す。

2. /llms-full.txt と、記事ごとの生 Markdown。 全文版は全記事の本文を 1 ファイルに連結し、 記事境界を罫線で区切る。さらに各記事は /logs/<slug>/llms.txt・/topics/<slug>/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 …）をあえて列挙して全面許可する。

// 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（用語辞書を DefinedTermSet で公開）——出力形式は これだけあるが、値の出所はすべて content/*。記事を 1 本足すと、索引も全文版も Feed も sitemap も 自動で追従する。文言も URL 規則も最終更新日の定義も二重に持たない。 前掲の「重複コンテンツのワナ」を 回避できるのは、この単一の出所の規律があるからだ。

5. llms.txt と MCP は両輪。 llms.txt のような静的ファイルとは別に、AI がツールで問い合わせる 接続型の道（MCP や、ブラウザ側の WebMCP 提案）も動いており、 AI へサイトを開く道は 1 本ではない。このサイトは 「クロールして回る AI・URL を素朴に叩く AI」向けに llms.txt を、「接続してくる AI」向けに 読み取り専用の MCP サーバを——と両輪で用意している。 どちらが主流になっても、出所が 1 つなら両方を安く維持できる。

これから — 効いているかを、自分で測る

この分野で唯一確かなのは「まだ誰も確実なことを言えない」ことだ。ならば SUZ-LAB にできる一次情報の発信は、 自分のサーバログで「実際にどの AI ボットが /llms.txt や記事ごとの生 Markdown を取得しているか」を計測して 公開することだろう。Mueller が「サーバログを見れば分かる」と言うなら、こちらもログを見て、賛否の議論に 自前のデータ点を 1 つ足せばいい。それはアクセス解析・KPI 計測を進める先の、格好の実験ログのネタになる。

---

まとめ。 llms.txt は、AI に「まず読むべき厳選リスト」を 1 枚の Markdown で渡す提案だ。 狙いは学習ではなく推論時のキュレーションで、robots.txt（排除）や sitemap（網羅）を置き換えず補完する。 仕様は H1＋要約＋リンクリストと小さく、llms-full.txt と .md 版ページが随伴する。ただし 主要 AI が実際に使う証拠は弱く、Google は否定的で、実測の流入もごくわずか——効果は賛否が割れている。 このサイトは「効くと証明されたから」ではなく「発信先に AI がいるから」実装し、値の出所を 1 か所にまとめ、 MCP と両輪で構えている。考え方の全体像は VMOST とは、実装の記録は サイトを機械可読にした にある。