llms.txt誕生の歴史｜2024年の提案から普及までを年表で解説

llms.txtは2024年9月3日に、Answer.AI／fast.aiの共同創業者であるJeremy Howardが提案したMarkdown形式のファイルで、LLM（大規模言語モデル）が推論時に参照すべきページを案内する目的で生まれました。同年11月にドキュメントホスティングのMintlifyが一斉対応したことで数千のドキュメントに拡散し、SEO/GEO文脈への流用も進みましたが、2025年7月にGoogleが不採用を明言し評価は分裂しています。2026年にはAIエージェント向けの新たな用途として再評価が進んでいます。本記事では誕生から現在地までを年表で整理します。

llms.txtの歴史を一枚で押さえる年表とは？

llms.txtの歴史は、2024年9月のJeremy Howardによる提案、2024年11月のMintlify対応による急拡大、2025年のSEO/GEO文脈への流用とハイプ、2025年7月のGoogleによる不採用表明、2026年のエージェント用途での再評価という五つの段階で整理できます。まずは全体像を年表で把握し、その後の章で各段階の背景を掘り下げていきます。

誰がいつなぜ作ったのか（結論）

llms.txtは2024年9月3日、Answer.AI／fast.aiの共同創業者Jeremy Howardが、LLMが限られたコンテキストウィンドウの中でサイトの重要情報を効率よく読めるようにする目的で提案した仕様です（Answer.AI、llmstxt.org）。robots.txtがクローラーへの許可・禁止を伝えるファイルであるのに対し、llms.txtはLLMに「どのページを読めば理解が進むか」を案内するファイルという違いが誕生の出発点でした。この発想自体は目新しくはなく、既存の標準に敬意を払いながらAI時代に合わせて再設計したものだとHoward自身も説明しています。

早わかり年表（2024年9月〜2026年）

誕生から現在地までの主な出来事を、日付付きで一覧化すると次のようになります。細部は後続の章で解説しますので、まずは全体の流れをつかんでください。

時期	出来事	補足
2024年9月3日	Jeremy Howardがllms.txtを提案	Answer.AI／llmstxt.orgで仕様公開
2024年11月	Mintlifyが全ホスト先で一斉対応	Anthropic・Cursor等数千ページに拡散
2024年12月頃	コミュニティ主導のディレクトリ化	llmstxt.site等が導入サイトをカタログ化
2025年3月頃	開発者ツール各社が追随	LangChain等がllms-full.txtを公開
2025年7月	Googleが不採用を明言	Gary Illyes／John Muellerが発言
2026年5月	公式ガイドとLighthouse監査が同時発生	検索チームとChromeチームでスタンス相違

TechSuite株式会社の「AI検索パートナーズ」は、こうしたllms.txtをめぐる仕様やGoogle・各AIベンダーの姿勢の変化を継続的に追跡し、その時点の一次情報に基づいてクライアントごとの施策の妥当性を検証しています。ハイプに流されず、実際に何が効果を持つのかを見極めるうえで、この年表全体の把握は最初のステップになります。

そもそもllms.txtとは何か？

llms.txtとは、サイトのルート直下に置くMarkdown形式のテキストファイルで、LLMに読んでほしい重要ページのリンクと短い説明をまとめたものです。robots.txtやsitemap.xmlとは目的も歴史も異なる、AI時代に生まれた新しい提案規格という位置づけになります。

LLMに読むべきページを伝えるMarkdownファイル

llms.txtの基本フォーマットは、必須項目であるH1（プロジェクト名やサイト名）、その直下のblockquoteによる短い概要、任意の補足説明、そしてH2見出しごとにリンクと説明を列挙する構成です（GitHub仕様）。XMLではなくMarkdownが採用されたのは、人間ではなくLLMやエージェント自身に直接読まれることを前提に設計されたためです。このシンプルな構造こそが、後にさまざまなCMSやプラグインで自動生成されやすかった理由のひとつでもあります。

llms.txtとllms-full.txtの違い

Howardの提案には、案内役の「/llms.txt」と、詳細版の「/llms-full.txt」という2種類のファイルが定義されています。前者は重要ページへの目次のような役割を持ち、後者は関連コンテンツを1つのファイルにまとめて全文連結した詳細版です（reaudit.io）。用途に応じて両方を用意するサイトもありますが、規模が大きいサイトではllms-full.txtの生成や更新の運用負荷が課題になりやすい点も歴史的に指摘されています。

robots.txt・sitemap.xmlとの違い

robots.txtは数十年来の標準規格で、ほぼ全てのサイトが導入しクローラーのアクセス制御を目的としています。一方llms.txtは2024年に登場した新しい提案規格で、AIへの内容案内が目的という点で歴史も普及度も大きく異なります（akarumi.jp）。こうした違いは、AI検索最適化（LLMOとは何か）全体の中でllms.txtがどこに位置づく施策なのかを理解するうえでも重要な前提です。

項目	robots.txt	sitemap.xml	llms.txt
登場時期	1994年頃	2005年頃	2024年9月
目的	クローラーの許可・禁止	ページ一覧の網羅的な通知	LLMへの重要ページ案内
普及度	ほぼ全サイト	ほぼ全サイト	約1割程度
公式標準か	事実上の業界標準	検索エンジン共同提案	個人発の提案規格

TechSuite株式会社の「AI検索パートナーズ」は、robots.txtやsitemap.xml、構造化データ、llms.txtといった各ファイルの役割を個別に切り分けず、サイト構造や検索導線全体の中でどこにどの施策を配置すべきかを顧客ごとに設計しています。同じllms.txtでも、事業内容やドキュメント量によって必要性は変わるため、テンプレート的な一律導入は推奨していません。

llms.txtはなぜ誕生したのか？

llms.txt誕生の背景には、LLMのコンテキストウィンドウの小ささと、HTMLをそのまま読ませるとナビゲーションや広告、JavaScriptがノイズになってしまうという技術的な課題がありました。robots.txtの発想を借りつつ、AI向けに情報を整理し直すというアイデアがllms.txtの出発点です。

コンテキストウィンドウの制約とHTMLノイズという原点の課題

提案当時のllmstxt.orgの背景説明では、LLMは限られたトークン数しか一度に処理できず、HTML全体をそのまま渡すのは非効率で不正確だと指摘されています（llmstxt.org）。特に想定されていたのは、開発環境でプログラミングドキュメントやAPI仕様に素早くアクセスするという実務的なユースケースでした。検索順位を上げるためのSEO施策として考案されたわけではなく、あくまで開発者体験の改善が最初の動機だった点は、歴史を理解するうえで欠かせないポイントです。

robots.txtから着想した発想と提案者Jeremy Howardとは何者か

Jeremy HowardはAnswer.AIとfast.aiの共同創業者で、ディープラーニング教育やPythonフレームワーク開発で知られる人物です。robots.txtという既存の「サイト直下に置く案内ファイル」という発想を土台に、AI時代向けのフォーマットとしてllms.txtを組み立てました（GitHub answerdotai/llms-txt）。リファレンス実装として使われたのは、Howard自身が開発するPythonフレームワーク「FastHTML」のドキュメントで、まさに開発ドキュメント向けという当初の想定用途そのものでした（Medium）。

単数形llm.txtと複数形llms.txtの混同というトリビア

提案とほぼ同時期には、単数形の「llm.txt」（AIクローラーへの許可・禁止ルールを宣言する案）と、複数形の「llms.txt」（推論時に読ませるコンテンツを案内する案）が混同される議論もありました（AEO Checker）。両者は名前が似ているだけで目的は異なるファイルであり、現在ネット上で見かける情報の中にも、この混同を引き継いだまま解説している記事が少なくありません。

TechSuite株式会社の「AI検索パートナーズ」は、こうした構造化データや意味的文脈、エンティティ認識、想定質問の分解といったLLMが引用・推薦する仕組みを技術的に捉え、llms.txtのような個別ファイルの是非も一次情報設計の観点から判断するようにしています。仕様や各社の対応方針は今後も変わり続けるため、その時点の研究やデータに基づいて追従する姿勢を重視しています。

2024年9月の提案から普及の転換点は何だったのか？

llms.txtは2024年9月3日の提案公開そのものでは大きな話題にはならず、転換点は同年11月のMintlifyによる一斉対応でした。ここから数千のドキュメントページに一気にllms.txtが付与され、初期採用企業のリストが形成されていきます。

2024年9月3日 answer.ai・llmstxt.orgでの提案公開

提案は、AnswerAIの公式ブログとllmstxt.orgという専用サイト、GitHubリポジトリの3か所で同時に公開されました（Answer.AI）。仕様書ではExisting standards（既存標準との関係）というセクションで、robots.txtやsitemap.xmlとの違いも明記されており、既存の仕組みを置き換えるものではないという位置づけが当初から示されていました。

2024年11月 Mintlifyの一斉対応で数千ドキュメントに拡散

開発者ドキュメントのホスティングサービスであるMintlifyが2024年11月にllms.txt対応を全ホスト先ドキュメントに展開したことで、AnthropicやCursorを含む数千のドキュメントページに一斉にllms.txtが付与されました（Medium、AEO Checker）。この一斉対応こそが、llms.txtという単語が開発者コミュニティの外にまで広まった最大の転換点だったと言われています。プラットフォーム側の対応によって導入コストがほぼゼロになったことが、拡散スピードを一気に引き上げました。

2024年12月〜 ディレクトリ化と初期採用企業

2024年12月頃からはllmstxt.siteのようなコミュニティ主導のディレクトリが登場し、導入サイトのカタログ化が始まりました。2025年3月頃にはLangChainなどの開発者ツールも自社ドキュメント用にllms.txt／llms-full.txtを公開しています（AEO Checker）。初期採用企業としては、Anthropic、Stripe、Cursor、Mintlify、Zapier、FastHTMLなどが挙げられ、いずれも開発者向けドキュメントを多く持つ企業という共通点があります（reaudit.io）。

企業/サービス	採用時期の目安	特徴
Mintlify	2024年11月	ホスト先全体に一斉対応
Anthropic	2024年11月頃	Mintlify経由で対応
Cursor	2024年11月頃	Mintlify経由で対応
Stripe	2024年後半	API/開発ドキュメントで採用
LangChain	2025年3月頃	llms-full.txtも公開

TechSuite株式会社の「AI検索パートナーズ」は、こうした急速な普及史の裏側にある検索意図や想定質問の分解ノウハウを、自社の「バクヤスAI記事代行」で培った制作エンジンとしてLLMO対策のコンテンツ設計にも転用しています。普及初期の事例を並べるだけでなく、なぜその企業が採用したのかという背景まで踏み込んで整理することが、読者やAIにとって価値のある情報になると考えています。

2025〜2026年、なぜllms.txtの評価は分裂したのか？

2025年にはSEO/GEO文脈への流用でハイプが過熱しましたが、同年7月にGoogleが不採用を明言したことで反動が起こりました。2026年に入ると、SEO用途では否定的でありながらエージェント用途では注目されるという二面性が定着しています。

SEO/GEO文脈への流用とハイプの拡大

本来は開発ドキュメント向けの提案だったllms.txtは、2025年にかけて「AI検索に効く新しいSEOファイル」という文脈で広く語られるようになりました。WordPress向けのYoastがllms.txt自動生成機能を組み込み、Webflowもルート配置手段を追加するなど、CMS側の対応がハイプ拡大を後押しした側面もあります（Symphonic Digital）。この流れはGEOとは何かという文脈で語られることが多く、本来の技術的動機とはやや異なる期待が積み重なっていきました。

2025年7月 Googleが不採用を明言

2025年7月、GoogleのGary IllyesはllmsGoogleがllms.txtをサポートしておらず、サポートする予定もないと明言し、John Muellerは廃れたメタキーワードタグになぞらえて否定的な見解を示しました（limy.ai）。この発言以降、ハイプは急速にしぼみ、実測データによる検証が相次いで公表されるようになりました。SE Rankingが30万ドメインを調査したところ採用率は10.13％にとどまり、ある90日間の計測では6万2,100件のAIボットリクエストのうちllms.txtへのアクセスはわずか84件、0.1％だったという結果も報告されています（同出典、Medium）。

2026年 エージェント用途での再評価とB2Aとしての位置づけ

2026年5月、Googleは公式ガイドで「llms.txtのような新たな機械可読ファイルを作成する必要はない」と明記し、AI Overviews／AI Modeも従来のSEOのベストプラクティスに依拠すると案内しています（akarumi.jp、cryptul.co.jp）。一方で同時期、Chrome開発チームのLighthouseにはAgentic Browsing向け監査が追加され、llms.txtの有無や取得状況を確認する項目が用意されました。検索チームとChrome開発チームでスタンスが分かれているのは、llms.txtがSEOのランキング要因ではなく、Cursor・Windsurf・Claude Code・GitHub CopilotなどのIDEエージェントが参照するB2A（Business-to-Agent）インフラとして再定義されつつあるためだと考えられています（Untype）。TechSuite株式会社の「AI検索パートナーズ」が支援する現場でも、AI検索経由の受注率は従来のSEO経由の約3倍という実績があり、露出や順位そのものではなく最終的な成果につながる施策の見極めを重視しています。

観点	Google検索チーム	Chrome開発チーム
llms.txtへの姿勢	不採用を明言	監査項目として採用
想定用途	AI Overviews/AI Mode	エージェンティックブラウジング
必須か	不要（作成の必要なし）	任意（無い場合はN/A）

歴史を踏まえてllms.txtは設置すべきか？

これまでの歴史を踏まえると、llms.txtを設置しても検索順位が直接上がる根拠はありませんが、情報整理やエージェント対応としての価値は残っており、リスクを理解したうえでの導入は選択肢になります。誤情報や非公開URLの記載など、逆効果になり得る点にも注意が必要です。

順位は上がらないが情報整理として損はないという評価の妥当性

実測データが示す通り、主要なAI検索クローラーがllms.txtを積極的に読みに来ている状況ではなく、Googleも明確に不要と表明しています。それでも、サイトの重要ページと概要を一枚に整理する作業自体は、社内のドキュメント管理やAIエージェントとの連携整理にも転用できるという意味で無駄にはなりにくいと考えられます。ただし、順位上昇を目的に導入するのであれば、期待値は誕生時の技術的動機からかけ離れていることを理解しておく必要があります。

誤情報・非公開URL掲載などの逆効果リスク

llms.txtに古い情報や誤った説明を書いてしまうと、それをそのままLLMが参照してしまう可能性があります。また、社内向けや非公開のURLを誤って記載してしまうリスクも指摘されており、公開前のレビュー体制は欠かせません。運用を始める前に、最低限のチェック観点を確認しておくと安心です。

導入する場合の最小手順（歴史を踏まえた現実的な運用）

導入する場合は、まずサイト名をH1、概要をblockquote、重要ページをH2セクションごとにリンクと説明で並べるという基本フォーマットに沿って作成し、ルート直下に配置します。その後は定期的な棚卸しと更新を続け、過度な期待をせずに情報整理の一環として位置づけることが、歴史的な経緯を踏まえた現実的な運用姿勢だと言えます。TechSuite株式会社の「AI検索パートナーズ」は、コンサルティングという性質上、業種や規模、商材、既存の検索導線ごとに異なる課題を捉え、llms.txtのような個別施策が本当に必要かどうかの見極めから、構造化データや一次情報設計まで含めた解決策の提示と実行支援まで伴走しています。テンプレートをそのまま当てはめるのではなく、サイトごとのボトルネックに応じた個別設計を重視している点が特徴です。より具体的な対策の進め方はLLMO対策の具体的なやり方でも整理しています。

よくある質問

llms.txtはいつ誰が作った？

2024年9月3日に、Answer.AI／fast.ai共同創業者のJeremy Howardが提案しました。LLMのコンテキストウィンドウ制約という技術的課題を解決するためのMarkdownファイルとして、llmstxt.orgとGitHubで仕様が公開されています。

なぜ歴史的な転換点と語られるのか

2024年11月にMintlifyが対応したことで、AnthropicやCursorを含む数千のドキュメントに一斉にllms.txtが付与され、開発者コミュニティ外にも広まったためです。この一斉対応が普及の最大の転換点とされています。

robots.txtがあればllms.txtは不要ですか

役割が異なるため一概に不要とは言えませんが、Googleは検索面では作成の必要はないと案内しています。一方でAIエージェント向けの監査項目に採用される動きもあり、目的次第で判断が分かれます。

llms-full.txtも作る必要がありますか

必須ではありません。llms-full.txtは関連コンテンツを1ファイルに連結した詳細版で、ドキュメント量が多いサイトの一部で採用されていますが、更新負荷が大きいため必要性を個別に判断することが望ましいです。

まとめ

llms.txtは2024年9月3日にJeremy Howardが、LLMのコンテキストウィンドウ制約という技術的課題への対処として提案した仕様です。2024年11月のMintlify対応で急拡大し、2025年にSEO/GEO文脈でハイプ化したのち、同年7月にGoogleが不採用を明言して評価は分裂しました。

2026年時点では、検索面では不要とされる一方、AIエージェント向けの監査項目として注目されるという二面性が定着しています。歴史的な経緯を踏まえれば、順位向上を目的にせず、情報整理やエージェント対応の一環として現実的に付き合っていく姿勢が現状では妥当だと考えられます。

参考にした情報源

• Answer.AI「The /llms.txt file」
• llmstxt.org 公式サイト
• GitHub answerdotai/llms-txt
• Medium「The llms.txt is dead」
• reaudit.io「llms.txt guide」
• AEO Checker「Should you use llms.txt」
• limy.ai「llms.txt in 2026」
• akarumi.jp「llms.txtとは」
• Untype「llms.txt and agent readability」