KnownByLLM

解説 · 読了 8 分

llms.txt は何 KB まで？

リンク数とトークン予算の考え方を、実在するファイルの数字で。

仕様は答えていません。llms.txt の形は定めていますが長さは 発行者に委ねているので、実務上の答えは「読み手にいくら かかるか」と「公開しているサイトが実際に何を出しているか」 から導くしかありません。

この記事ではその両方を示します。2026 年 9 月に保存した実在 ファイルのサイズとリンク数、その背後にあるトークンの計算、 ツールが線を引いている場所、そして削るときの短い基準です。

30 秒で分かる結論：llms.txt のサイズ上限は仕様にはなく、数 KB が妥当な桁

目安は 2 KB から 20 KB 程度、リンクは 10 本から 80 本程度で、 それぞれに一文を添えます。今回測った実在ファイルの半分は 15 KB 未満で、読みやすいものは 1 桁 KB に収まっています。50 KB を超えたら索引をセクション別のファイルに分けるか内容を llms-full.txt に移す目安、100 KB はツールが文句を言い始める 目安と考えてください。

理由はコストです。アシスタントはサイトの他のどのページより先に llms.txt を読み、索引の 1 KB はそのままページに使えない予算に なります。短いファイルは全文が読まれ、書いた順番と注釈が そのままモデルに届きます。長いファイルは流し読みか切り詰めに なり、Optional のあるファイルの末尾から先に消えます。

仕様とツールが言っていること

  • 仕様：最大サイズも最大リンク数も、その指針も ありません。書かれているのは「リンクごとに短い一文を添えた、 選び抜かれた索引」という形であって、数字ではありません。
  • このサイトのバリデータ：100 KiB までは合格、それを超えると警告、512 KiB で読むのをやめて「全体を検査できなかった」として失敗を 報告します。
  • Mintlify の生成ツール：生成する索引を 100,000 文字までに抑えます。超えた場合、ルートの llms.txt は /_llms/ 配下のグループ別ファイルを指す目次に なります。何千ものファイルを生成しているプラットフォームが、 索引 1 つの天井を 100 KB と決めたということです。

実在するファイルの重さ

実例記事のために 2026 年 9 月 19 日に保存した公開ファイル 28 本のうち、Markdown として読めたのは 24 本でした（2 本は取得 失敗、2 本は HTML が返りました）。その一部をサイズ順に 並べます。

サイトサイズリンク数1 リンクあたりのバイト数
Svelte1.7 KB7約 240
Supabase2.7 KB32約 85
Vercel docs4.7 KB24約 200
FastHTML4.8 KB21約 230
Docker docs5.4 KB33約 160
Hono5.7 KB90約 65
Next.js12.7 KB45約 280
Cloudflare 開発者ドキュメント16 KB107約 150
Mintlify docs22 KB112約 195
Bun34 KB321約 105
Anthropic docs68 KB629約 110
Stripe docs92 KB453約 205
ElevenLabs docs208 KB761約 275

目立つ点が 2 つあります。1 リンクあたりのバイト数は、すべての リンクに一文がついていれば 150〜280 前後に集まり、ほとんど ついていなければ 65〜110 まで下がります。Hono と Anthropic は 注釈のないリンクの羅列です。そして 30 KB を超えるファイルは どれもページ一覧からの自動生成に見え、最も小さいものは 手書きに見えます。サイズは、誰かが載せるものを選んだか どうかの症状です。

トークンの計算

英語の文章では 1 トークンあたりおよそ 4 文字が実務上の目安です。 すると 5 KB のファイルは 1,200 トークン前後、20 KB は 5,000 前後、100 KB は 25,000 前後になります。日本語をはじめラテン 文字以外の文字は 1 文字あたりのトークン数が多いので、同じ バイト数の日本語の索引は読むコストが上がります。

比べるべき相手は、2026 年時点で十分に大きいモデルのコンテキスト ウィンドウではなく、アシスタントがあなたのページを 1 枚も 見ないうちに、取得した 1 ファイルに使ってよいと考える分量です。 25,000 トークンの索引は、一般的なドキュメントページを 10 枚 読むのと同じコストです。サイトに割かれる予算があるなら、 ページの一覧ではなく、質問に答えるページにその大半を使って ほしいはずです。

削るときの基準

  • リンクごとに一文、段落にしない。注釈は そのページが何に答えるかを言います。15 語もあれば十分で、 表のファイルは URL を含めても 1 リンクあたり平均 300 バイト 未満です。
  • ページではなくセクションを。ガイドの小節を 全部ではなく、ガイドそのものをリンクします。サイトのある セクションに 10 ページ以上あるなら、その索引ページを リンクして、そこから先はアシスタントに任せます。
  • sitemap がすでに持っているものは落とす。タグページ、ページ送り、法務ページ、旧バージョン、ブログの ロングテールは sitemap.xml の仕事で、ここには要りません。
  • 50 KB で分ける。ルートはセクション別の索引 へのリンクを 1 本ずつ並べた短い目次にし、各索引は 20 KB 未満に保ちます。Mintlify が上限超過時に自動でやっている ことで、手でやっても成り立ちます。
  • 本文は llms-full.txt へ。索引が膨らんで いる理由が「内容を貼り込んでいるから」なら、やめます。 全文の置き場は束で、索引は地図です。

これらの上に 1 つ構造の規則があります。最初の 2 KB だけで成り立つようにすること。H1、引用ブロック、最初の セクションまでで、途中でやめた読み手がサイトを正しく説明 できるようにします。それより先は、余裕のある読み手への おまけです。

確認の仕方

curl -s https://example.com/llms.txt | wc -c
curl -s https://example.com/llms.txt | grep -c '^- \['
curl -s https://example.com/llms.txt | head -c 2048

1 つ目がバイト数、2 つ目がリンク数、3 つ目は 2 KB の予算しかない読み手に見えるものです。そのあとバリデータに 通せば、サイズを閾値と比べた結果と、見つかったリンクの一覧が 出るので、重さがどこにあるかが分かります。

llms.txt を検証する

サイトの URL を貼ると、/llms.txt を取得してサイズを報告し、仕様に沿った構造かを確認し、見つかったリンクをすべて一覧にします。

バリデータを開く →

よくある質問

llms.txt に公式のサイズ上限はありますか？

ありません。llmstxt.org の仕様は最大サイズも最大リンク数も定めていません。存在する上限はツール側のものです。このサイトのバリデータは 100 KiB を超えると警告し、512 KiB で読むのをやめます。Mintlify は生成する索引を 100,000 文字までに抑え、残りをサブ索引のファイルに分割します。仕様が黙っているのは大きくしてよいという意味ではなく、小さく保つ理由だと考えてください。

リンクは何本までなら多すぎませんか？

仕様に数字はありませんが、今回のサンプルで読みやすかったファイルは 7 本から 110 本程度で、リンクごとに一文が添えられていました。数百本を超えると、それはもう選び抜かれた索引ではなく Markdown で書かれた sitemap で、アシスタントには何が重要かの手がかりがありません。数百本が必要なら、セクションごとのファイルにまとめ、ルートは短い目次にします。

自分のファイルのトークン量はどう見積もればよいですか？

英語の文章なら 1 トークンあたりおよそ 4 文字が目安で、10 KB のファイルは 2,500 トークン前後、100 KB なら 25,000 トークン前後になります。日本語をはじめラテン文字以外の文字は 1 文字あたりのトークン数が多いので、同じバイト数でもコストは上がります。比べる相手はモデルのコンテキストウィンドウではなく、アシスタントがあなたのページを 1 枚も読む前に、取得した 1 ファイルに使ってよいと考える分量です。

llms.txt を大きくするより llms-full.txt に移すべきですか？

はい。増えているのが索引ではなくページの内容なら、そうすべきです。llms.txt は目次で、全文を読み切れる大きさに保ちます。llms-full.txt は全文ページの束で、数百 KB になってもかまいません。長い説明や本文を索引に詰め込むのがよくある失敗で、直し方はリンクごとの短い注釈と、別ファイルの束です。

ファイルのサイズで AI ツールが llms.txt を読むかどうかが変わりますか？

そう文書化している事業者はありません。あるアシスタントがファイルを取得するかどうかは事業者次第で、サイズでは決まりません。サイズが左右するのは取得したあとです。短いファイルは全文が読まれ、書いた優先順位が伝わります。とても長いファイルは切り詰められたり流し読みされたりしやすく、最後のほうのセクション、つまり Optional が真っ先に失われます。

次に読む