llms.txt とは — AI 向けのサイト案内ファイル
robots.txt が「入っていいか」を伝えるファイルなのに対し、llms.txt は「ここに何が書いてあるか」を AI に伝えるための提案仕様です。書式と実例、Next.js での配信方法に加えて、まだ普及途上であるという現状も含めて正直に整理します。
llms.txt とは何ですか?
サイトのドメイン直下(/llms.txt)に置く Markdown 形式のファイルで、「このサイトは何で、重要なページはどこか」を AI 向けに要約したものです。2024 年に Jeremy Howard 氏(Answer.AI)が提案した仕様で、標準化団体の規格ではありません。
発想の出発点は、LLM のコンテキスト長の制約です。AI がサイトの内容を理解しようとしても、HTML にはナビゲーション・広告・スクリプト・装飾といったノイズが大量に混ざっています。サイト全体を読ませようとすれば、限られたコンテキストがノイズで埋まります。
そこでサイト側が「重要なのはここです」と最初から Markdown で要約して置いておけば、AI は迷わず要点にたどり着けるはずだ、というのが llms.txt の主張です。Markdown を採用しているのは、人間にも LLM にも余計な前処理なしで読めるためです。
robots.txt や sitemap.xml と何が違うのですか?
役割が違います。robots.txt は「入っていいか」の可否を伝え、sitemap.xml は「URL が全部でいくつあるか」を機械に伝えます。llms.txt は「中身が何で、どれが重要か」を自然言語で伝えるものです。3 つは競合せず、置き換え関係にもありません。
| ファイル | 伝えること | 位置づけ | 強制力 |
|---|---|---|---|
/robots.txt | クロールしていいか(可否) | RFC 9309(標準) | 各社が尊重を表明。実効性あり |
/sitemap.xml | URL の一覧と更新日 | sitemaps.org(事実上の標準) | 検索エンジンが利用 |
/llms.txt | サイトの概要と重要ページ | 提案仕様(2024 年〜) | 対応は各社の任意。表明例は乏しい |
/llms-full.txt | 本文そのものを 1 ファイルに集約 | llms.txt の派生・慣習 | 同上 |
特に混同されやすいのが robots.txt との関係です。llms.txt には、クロールを許可したり拒否したりする力は一切ありません。アクセス制御をしたいなら robots.txt を使ってください。詳しくはGPTBot・ClaudeBot を許可すべきか、拒否すべきかで扱います。
llms.txt はどう書けばいいですか?
仕様上の必須要素は H1 のサイト名だけです。実務では、H1・引用ブロックによる要約・H2 で区切ったリンク一覧という 3 層構成が標準形になります。リンクは「- [タイトル](URL): 説明」の形で書きます。
提案されている書式は次のとおりです。順序に意味があります。
- H1 — サイト名・プロジェクト名。これだけが必須です
- 引用ブロック(
>) — サイト全体の要約。ここだけ読んで概要が掴める密度で書きます - 本文 — 補足説明。見出しの無い段落として書きます
- H2 セクション — 用途ごとのリンク一覧。各行は
- [タイトル](URL): 説明の形式です ## Optionalセクション — 特別な意味を持ちます。「コンテキストに余裕が無ければ飛ばしてよい」という目印です
# サイト診断(check.itlibra.com)
> URL を 1 つ入力するだけで、Web サイトの SEO・AEO・AIO(LLMO)・セキュリティ・ドメイン・
> パフォーマンス・アクセシビリティ・メール認証・技術構成を、約 109 項目まとめて診断する
> 無料ツールです。登録不要。運営: JIT株式会社(https://www.itlibra.com)。
このツールの特徴は「AI から見てそのサイトがどう見えるか」を診断できることです。
具体的には、JavaScript を実行せずに本文が何文字読めるかを実測し、GPTBot・ClaudeBot・
PerplexityBot など主要 AI クローラー 21 種の robots.txt での許否を個別に判定します。
診断は非侵襲です。対象サーバーへのリクエストは 1 診断あたり最大 12 件・同時 4 本までで、
公開 URL への通常の GET しか行いません。
## 解説記事
- [llms.txt とは — AI 向けのサイト案内ファイル](https://check.itlibra.com/guide/llms-txt): llms.txt の書き方・実例・現時点での採用状況。
- [構造化データ(JSON-LD)の書き方](https://check.itlibra.com/guide/structured-data): FAQPage・HowTo・Article・Organization の実装。
## Optional
- [このツールについて](https://check.itlibra.com/about): 診断項目の一覧、診断方法、限界、プライバシー。書くときのコツ
- 引用ブロックに全部を詰める — ここだけ読まれる前提で書きます。「何のサイトで」「誰が運営していて」「何ができるか」を 3 文以内に
- URL は絶対 URL で書く — llms.txt が単体で切り出されて読まれた場合、相対パスは解決できません
- リンクの説明を省略しない —
: 説明の部分が、AI がそのページを読むかどうかの判断材料になります - 存在しない URL を書かない — llms.txt にあるのに 404 が返るのは、単に信頼を失うだけです
- 宣伝文句を入れない — 「業界 No.1」のような検証不能な自己申告は、AI にとって何の情報でもありません
Next.js ではどこに置けばいいですか?
public/llms.txt にファイルを置くだけです。Next.js が text/plain で配信します。ページ一覧を自動で反映したい場合は、app/llms.txt/route.ts のルートハンドラで動的に生成する方法もあります。
静的ファイルで足りるならそれが一番です。ただしページが増減するサイトでは、llms.txt の更新を忘れて内容が古くなりがちです。ページの一覧をコード側で管理しているなら、そこから生成してしまう方が確実です。
import { GUIDES } from "@/lib/guides";
const BASE = process.env.NEXT_PUBLIC_BASE_URL || "https://example.com";
// 静的に生成して配信する(リクエストごとに作り直さない)
export const dynamic = "force-static";
export function GET(): Response {
const links = GUIDES.map(
(g) => "- [" + g.title + "](" + BASE + "/guide/" + g.slug + "): " + g.summary,
);
const body = [
"# Example",
"",
"> ここにサイト全体の要約を 3 文以内で書く。",
"",
"## 解説記事",
"",
...links,
"",
].join("\n");
return new Response(body, {
headers: {
// text/plain 以外を返すと「HTML を返している」と誤認されうる
"content-type": "text/plain; charset=utf-8",
"cache-control": "public, max-age=3600",
},
});
}llms-full.txt も必要ですか?
ほとんどのサイトでは不要です。llms-full.txt は本文そのものを 1 ファイルに連結したもので、API リファレンスのように「全文を一度に読ませたい」ドキュメントサイト向けの発想です。数 MB 規模になりがちで、維持コストに見合う場面は限られます。
llms.txt が目次だとすれば、llms-full.txt は全文を 1 冊にまとめた本です。ライブラリのドキュメントを AI に丸ごと読ませてコーディング支援に使う、といった用途では有効ですが、企業サイトやメディアで全文を 1 ファイルに固める必然性はまずありません。
用意する場合は、更新のたびに再生成される仕組みにしてください。手作業で維持されている llms-full.txt は必ず古くなり、古い情報を積極的に配って回ることになります。
llms.txt は実際に読まれているのですか?
正直に言えば、分かりません。主要な AI 各社は llms.txt を読んでいるともいないとも公表しておらず、効果を示す公開データもありません。開発者向けドキュメントを中心に配信するサイトは増えていますが、 読まれている証拠が出ているわけではありません。
この記事で最も重要な節です。ここを盛って書く記事が多いので、分かっていることと分かっていないことを分けます。
| 論点 | 現時点の状況 |
|---|---|
| 仕様の位置づけ | 2024 年の提案。W3C・IETF の標準ではなく、策定プロセスも存在しない |
| AI 各社の対応表明 | 主要各社からの公式な対応表明は確認できていない |
| 配信しているサイト | 開発者向けドキュメントを中心に増加。一般企業サイトへの広がりは限定的 |
| 効果の実証データ | 公開された定量データは無い。あるのは個別の体験談まで |
| 検索エンジン側の反応 | サイト側の自己申告は検証できない、という懐疑的な見方も示されている |
懐疑論の中身も理解しておく価値があります。かつて meta keywordsが廃れたのは、サイト側が自己申告した内容を検索エンジン側が検証できず、結果として濫用されたからです。llms.txt も構造的には同じ形をしています。実際のページと llms.txt の内容が食い違っていても、誰も止められません。この弱点がある限り、AI 側が llms.txt を全面的に信頼する理由は乏しい、という指摘には筋が通っています。
結局、導入する価値はありますか?
優先順位を下げた上でなら、やって損はありません。作成コストは 30 分程度で、副作用もリスクもゼロだからです。ただし本文が読めない・robots.txt が壊れているといった土台の問題を放置したまま llms.txt を置いても、得られるものはありません。
費用と効果を素直に並べると、判断はそれほど難しくありません。
- コスト — 初回 30 分、更新は年に数回。自動生成にすればほぼゼロ
- リスク — 無し。読まれなくても何も起きず、既存の SEO にも影響しません
- 期待値 — 現時点では不明。将来 AI 各社が対応した場合に、既に置いてある状態になる
つまり「宝くじだが、はずれてもマイナスにならない宝くじ」です。ただし優先順位を見誤らないでください。次の順で潰すのが合理的です。
- JavaScript なしで本文が読めるか — 読めなければ他は全て無意味です
- robots.txt が意図どおりか — 事故で全 AI を拒否しているサイトは実在します
- 構造化データがあるか — こちらは検索側の対応が確立しています
- llms.txt を置く — ここまで済んでから