llms.txt は今のところ何かの役に立っているのか。その問いに対する正直な答えはこうです。測定できる範囲ではほとんど何の役にも立っておらず、このファイルが AI 上での可視性に不可欠だと言ってくる人は、たいてい何かを売ろうとしています。それでいて「一つ用意しておいたほうがよい」と勧めるのは、かなり落ち着かない立場です。ですからこの記事では、まず数字を並べ、そのうえで推奨の理由を順に説明していきます。

ファイルそのものは筋の通ったアイデアです。サイトのルートに置くマークダウン形式の索引で、robots.txt がクローラーに「何を取得してよいか」を伝えるのと同じように、言語モデルに「何を公開していて、それがどこにあるか」を伝えます。発想そのものに問題はありません。問題は、この仕組みが想定していたはずの企業側が、実際にはほとんど使っていないという点にあります。仕様を提案することと、それを読む側が現れることは、まったく別の出来事です。

サーバーログが実際に示していること: Ahrefs が 137,000 ドメインを対象に行った分析では、2026年5月の時点で llms.txt ファイルの 97% がリクエストをまったく受け取っていません。少なかったのではなく、ゼロです。その一方で採用は1年で 8.8 倍に増えました。つまりこのファイルは、読まれる速度をはるかに上回る勢いで公開され続けているということです。

数字と、その出どころ

知っておく価値のあるデータセットが二つあります。この話題を扱う記事の大半は、そのどちらも引用していません。だからこそ、ここでは出典と測定方法から確認しておきます。

Originality.ai は 2025年6月から 2026年5月にかけて、300万を超えるウェブサイトを継続的に追跡しました。llms.txt の設置例は 4,088 件から 36,120 件へと増え、これは 8.8 倍の伸びにあたります。関連する形式のいずれかを公開しているサイトは、2026年5月の時点でおよそ 38,980 件でした。伸び自体は本物です。ただし出発点が非常に小さかったことは押さえておく必要があります。数百万規模の母集団に対して数万件という水準は、まだごく一部にすぎません。

続いて Ahrefs は 137,000 ドメインのサーバーログを解析し、そのうち 97% のファイルがリクエストをまったく受け取っていない ことを 2026年5月に確認しました。ここで重要なのは、これが推測ではなく実際のアクセス記録だという点です。ファイルは配信可能な状態で置かれていたのに、取りに来る相手がいなかったのです。実際に届いたリクエストのうち、AI の情報取得ボットが占めた割合は 1.1% にすぎませんでした。内訳を見ると、これらのファイルへのリクエストのうち GPTBot が 4.51%、ClaudeBot が 0.80%、DeepseekBot が 0.02% を占めています。

この二つの調査を並べると、発行者側が熱心に採用し、消費者側が徹底的に無視している標準、という姿がはっきり浮かび上がります。片側だけを見ていると、成長率の数字は成功の証拠のように読めてしまいます。

AI 各社が実際に言っていること

議論に決着をつけるのはこの部分です。推測ではなく、各社が公に述べた内容だけを見ていきます。

Google はサポートしていません。同社は 2025年7月にそのことを公の場で述べ、サポートする予定もないと明言しました。OpenAI はクローラー向けのドキュメントで llms.txt にまったく触れておらず、サイト運営者を robots.txt に案内しています。Anthropic は自社の llms.txt を公開し、この提案をめぐる議論にも関わってきましたが、Claude の情報取得が第三者のファイルを解析するとは述べていません。

Perplexity は目立った例外で、ページの優先順位付けに役立てるためにこのファイルを取得していると説明しています。

データの中には愉快な皮肉が埋まっています。Google も OpenAI も Anthropic も、自社ドキュメントのために llms.txt を公開しておきながら、サイト運営者には検索での可視性のためにそれを当てにするなと助言しているのです。自社のドキュメントが機械可読であることは、たしかに便利です。しかしそれは、各社のクローラーがあなたのファイルを読んでくれることとは、まったく別の話です。この二つを混同した説明が、いま出回っている宣伝文句のかなりの部分を占めています。

今日の本当の消費者は、検索エンジンではなくコーディングエージェントです。Cursor、Claude Code、Continue、Cline といった道具は、ユーザーがドメインを指定したときに llms.txt を読みに行きます。あなたの製品に開発者向けドキュメントがあるなら、それは実在する意図を持った実在の読者であり、おそらくファイルを用意しておく最も強い理由になります。

それでもなぜ公開するのか

理由は四つあります。そのどれも「検索順位が上がるから」ではありません。

ほとんどコストがかからない。 自分のコンテンツから生成する索引は半日ほどの仕事であり、サイトが自身の構造をすでに把握しているなら、それよりもさらに短く済みます。

存在している消費者は意図が強い。 Cursor をあなたのドキュメントに向けた開発者は、検索流入の大半よりもずっと製品の利用に近いところにいます。Perplexity があなたのページを優先することの効果は小さいですが、確かに実在します。

標準の普及はラチェットのように一方向にしか進まない。 情報取得システムが実際に読み始めたとき、正確で最新のファイルを持つサイトはすでに準備ができていて、持たないサイトはそうではありません。早く動く費用は半日です。遅れる費用は、遅れていること自体に気づくまでにかかる時間すべてです。

書くこと自体が監査を強制する。 正確な索引を作るには、公開しているものをすべて数え上げる必要があります。誰もリンクしていないページや、存在を忘れていたセクションが見つかるのは、まさにこの過程です。

最後の点は理屈の上だけの話ではありません。今月、自分たちのファイルを点検したところ、ファイルそのものよりはるかに価値のある問題が出てきました。

古い llms.txt は、ない方がましだ

私たちの llms.txt は 29 本の記事を列挙していました。サイトには 166 本ありました。さらに悪いことに、すべての URL から言語プレフィックスが抜け落ちていたため、実際のページが mecanik.dev/en/posts/<slug>/ にあるのに mecanik.dev/posts/<slug>/ は 404 を返していました。ファイルに含まれていた 243 本のサイト URL のうち、実際に応答したのは 7 本 だけでした。

そのファイルを実際に読んだものは、存在しないサイトの地図を渡されたことになります。これは何も公開しないより明確に悪い状態です。何もなければ、少なくとも正直に失敗するからです。誤った索引は、読み手に「調べた結果ここには何もなかった」と結論させてしまいます。

教訓はこのファイル一つの話にとどまりません。索引とはサイトについての約束であり、手入れされない約束は静かに嘘へと変わっていきます。公開するなら、サイトマップとまったく同じリリース工程に組み込み、生成器が正しく作ってくれたはずだと決めつけずに、URL が実際に応答するかどうかを毎回試してください。コンテンツの中にスラッグが存在することと、サーバー上でその URL が応答することは、同じではありません。

正しい公開のしかた

独自の形式を考え出すのではなく、llmstxt.org の仕様 に従ってください。必須要素はサイト名を書いた H1 だけで、引用ブロックによる概要と、注釈付きリンクを並べた H2 セクションが慣例になっています。慣例としてもう一つ、コンテキストの余裕が足りないときにエージェントが飛ばしてよいリンクをまとめる Optional セクションがあります。

仕様の外側に、実務的な規則が三つあります。第一に、手で管理するのではなく、コンテンツからファイルを生成すること。手で管理する索引は二か月もあれば古くなります。第二に、すべての URL を実際のリクエストで検証すること。生成できたことと、届くことは別です。第三に、サイトが多言語なら、ロケールを一つずつ並べるのではなく、言語の規則を一度だけ書くこと。そうすれば読み手は、その規則からどの URL でも自分で組み立てられます。

生成エンジン最適化のガイド では、AI 上の可視性のうち測定可能な効果があるものを扱っています。またAI 検索エンジンが構造化データをどう読むか ではスキーマを扱っています。スキーマは llms.txt と違い、それを読んでいると公に文書化しているシステムによって、実際に消費されています。

結論としての推奨

公開してください。そして正確に保ってください。今年は何も期待せず、誰かがこれを AI 可視性サービスとして請求してくることは許さないでください。

AI による引用を実際に動かすものが何かといえば、それはドメインのルートに置かれた一つのファイルではありません。引用されるだけの完全さで問いに答えているコンテンツと、その答えを情報取得システムが信頼するだけの権威です。Mecanik はテクニカル SEO 監査 でその両方を扱い、機械可読な索引がサイトについて本当のことを述べているかどうかも合わせて確認します。

関連記事: コンテンツが上位表示されても引用されない理由 、AI クローラーをブロックするか許可するか: ビジネス上の判断 、Google AI モードがサイトのトラフィックに与える影響 、法律事務所向け SEO 会社: コンプライアンスとコンテンツ、費用 。

よくある質問

llms.txt は 2026年に実際に機能しているのですか？ ほとんど機能していません。Ahrefs が 137,000 ドメインを分析したところ、2026年5月の時点で llms.txt ファイルの 97% がリクエストをまったく受け取っておらず、実際に届いたリクエストのうち AI の情報取得ボットは 1.1% にとどまりました。採用は1年で 8.8 倍に増えており、このファイルは何かに読まれる速度をはるかに超える勢いで公開されています。

Google、OpenAI、Anthropic は llms.txt をサポートしていますか？ いいえ。Google は 2025年7月に llms.txt をサポートしておらず、その予定もないと公に述べました。OpenAI はクローラー向けドキュメントで触れておらず、サイト運営者を robots.txt に案内しています。Anthropic は自社のファイルを公開していますが、Claude の情報取得が第三者のファイルを解析するとは述べていません。Perplexity が例外で、ページの優先順位付けのためにファイルを取得すると説明しています。

llms.txt は robots.txt と同じものですか？ 違います。robots.txt はクローラーに何を取得してよいかを伝えるもので、行儀のよいボットには広く尊重されています。llms.txt は言語モデルに何をどこで公開しているかを伝えるコンテンツ索引で、尊重している相手はごくわずかです。AI クローラーのアクセスを制御したいのであれば、実際に効くのは robots.txt と CDN のクローラー制御機能です。

今 llms.txt を実際に読んでいるのは誰ですか？ 検索エンジンよりもコーディングエージェントが中心です。Cursor、Claude Code、Continue、Cline は、ユーザーがドメインを指定したときにファイルを読み、Perplexity はページの優先順位付けに使っていると述べています。開発者向けドキュメントを公開しているなら、規模は小さくても意図が非常に強い読者層です。

llms.txt ファイルは公開すべきですか？ はい、ただし正しい理由でです。かかる時間は半日、存在する消費者は意図が強く、採用が進んだときにすぐ対応できます。順位面の利益は期待しないでください。何より大切なのは正確に保つことです。もう応答しない URL を並べた古いファイルは、何も公開しないよりも悪い結果になります。読んだ相手に、存在しないサイトの地図を渡してしまうからです。