// AGENT SEO · 解説
llms.txt とは：何を要求する仕様で、誰が読んでいるのか
llms.txt は、サイトの中身を Markdown で index したファイルです。仕様は llmstxt.org が公開していて、短い。ここでは三つを分けて書きます。仕様が実際に要求していること、v2（2026年8月）で静かに変わった位置づけ、そして「本当に取りに来ているのか」の実測値です。三つ目は日本語の解説記事ではあまり数字が出てこない部分で、結論から言うと Google 検索は使わないと明言しており、公開されたファイルの大半は 1 か月間ゼロ回しか取得されていません。それでも作る理由はあります。ただし順位のためではありません。
他の言語English日本語
仕様が実際に要求していること
llmstxt.org の仕様は短いものです。適合するファイルは、次のセクションをこの順で含みます。
- 任意のバイトオーダーマーク。
- プロジェクトまたはサイトの名前を書いた H1 —— これだけが必須のセクションです。
- 引用ブロック（blockquote）。以降を理解するのに必要な要点を短くまとめます。
- 見出し以外の任意の Markdown セクションを 0 個以上。プロジェクトの補足や、列挙したファイルをどう解釈すればよいかを書きます。
- H2 で区切られたセクションを 0 個以上。それぞれが URL の「ファイルリスト」を持ちます。
ファイルリストの各項目は [名前](URL) という Markdown のリンクが必須で、そのうしろに : とファイルについての注記を任意で置けます。ファイルはサイトのルートに置いても、任意のパスに置いてもよく、そのパス配下のページをカバーします。複数が該当するときはいちばん具体的なものが勝ちます。
仕様は robots.txt との線引きを自分で一文引いています。robots.txt は「入っていいかどうか」を宣言するもので、llms.txt は「中に何があるか」を宣言するものです。用途が違うので、片方がもう片方を置き換えることはありません。
v2（2026年8月）で変わった4点
v2 の改訂は全文を読む価値があります。提案全体の位置づけを静かに置き直しているからです。効いてくるのは四つ。
1. リンク関係による発見可能性。 2年運用してみて最も多かった要望が「あるページを起点に、その Markdown 版や、そのページをカバーする llms.txt を、当て推量なしでどう見つけるのか」でした。v2 はこれに標準のリンク関係で答えます —— ページの Markdown 版には type="text/markdown" を付けた alternate、そのページをカバーする llms.txt には describedby。HTML の <link> 要素でも HTTP の Link: ヘッダでも構いません。ページの Markdown 版を出しているなら、今年足せるもののうちこれが最も有用です。
2. Markdown の URL 形式は両方とも正式。 v1 はページ URL の末尾に .md を足す形（page.html.md）を規定していましたが、実際の公開ツールは拡張子を置き換える形（page.md）で出荷してしまいました。v2 は両方を認めています。
3. サブパスの意味が定義された。 ファイルはそのパス配下のページをカバーし、複数該当するときは最も具体的なものが適用されます。GitHub Pages のプロジェクトサイトのようにパスしか支配していないサイトでも参加できるのは、この規定のおかげです。
4. Optional セクションが機械的な意味を失った。 v1 には ## Optional を見て何を省くか決めるコンテキスト展開ツールが付属していました。v2 はそのツールをやめ、期待する動作を直接書いています —— エージェントはファイルを閲覧または検索し、関連するリンクをたどる、そのリンク先は LLM が扱いやすい内容であること。Optional は二次的なリンクを置く慣習としては残りますが、もう何も指示しません。
変化の向きを読んでください。著者自身の言い方が「言語モデルがウェブサイトを読むかもしれない」から「コーディングエージェントはこれを確実に使う」へ移っています。仕様は、ドキュメントを読ませるための規約に落ち着きつつあります。
正直なところ：ほとんど取りに来ていない
ここが日本語の解説記事であまり数字の出てこない部分なので、出典つきで書きます。
Google 検索は llms.txt を使いません。自社ドキュメントでそう明言しています。 検索の生成AI機能に関するガイダンス（2026年7月10日更新）は、検索の AI 機能を含めて検索に載るために、機械可読ファイル・AI 用テキストファイル・マークアップ・Markdown を新たに作る必要はない、検索自体がそれらを使わないからだ、と書いています。あわせて、他のシステム向けに llms.txt を維持しても検索での見え方に有利にも不利にもならない、とも述べています。
これは 2025 年以来の Google 社員の公開発言とも一致します。Gary Illyes は 2025 年 7 月の Search Central Live APAC で、Google に対応予定はないと述べました。John Mueller はこのファイルを keywords メタタグ —— サイト側が自由に書ける欄で、検索エンジンが 10 年以上前に信用をやめたもの —— になぞらえています。
リクエストログも同じことを言っています。 Ahrefs は 2026 年 5 月にトラフィックのあった 137,210 ドメインを調べました。うち約 38,000 が妥当な llms.txt を配信していて、採用率にすると約 28%。ただし著者自身が、読者層が技術・SEO に偏っているのでこれは上限だと断っています。そしてそれらのファイルのうち、97% はその月に 1 回もリクエストされていません。届いたリクエストの内訳は、AI ボットが 19.5%、残り 77% は AI 以外 —— SEO 監査ツール、素性の分からないクローラー、技術プロファイラーです。著者が付けている但し書きがいちばん重要です。リクエストは甘い指標であり、取得したものにボットが実際に従うかどうかは別の問題だ、と。
2026 年 8 月時点で、主要な AI 提供事業者のうち「自社のクローラーが llms.txt を取得して従う」と文書で述べているところを、私たちは見つけられていません。
では誰のためのファイルなのか
それでも作る理由は三つあります。どれも順位の話ではありません。
あなたのドキュメントを読むコーディングエージェント。 実証されている用途で、v2 が寄せていった先でもあります。開発者が Claude Code や Cursor、Codex をあなたのドキュメントに向けたとき、エージェントはレンダリング済みの HTML をスクレイピングする代わりに、整理された地図ときれいな Markdown を受け取れます。
自分たちのエージェントとスキル。 自社サイトに何があるかを知る必要がある内部エージェントは、自分たちの index の一級の消費者です。しかも両端を自分で握っています。
書くことで強制される規律。 llms.txt を書くと、自分たちが何をしているかを定義する正典となる一文と、ページごとの一行説明を作らざるを得なくなります。この二つはファイルの外でも役に立ちます —— どこかであなたを要約するとき、回答エンジンが持ち上げていくのはまさにこれです。
そうではないもの：順位、AI Overviews への掲載、ChatGPT での引用頻度。これらを裏づける公開された証拠はありませんし、一つ目は Google が明確に否定しています。
日本語圏でこの話題がどう扱われているか
2026 年 9 月 5 日時点で、llms.txt とは の日本語検索結果の上位十件を見たときの構成です。見出しと種別から読み取れる範囲だけを書きます（各記事の本文までは読んでいません）。
可動のツールはゼロ件です。 十件の内訳は解説記事・チュートリアルが大半で、そのほかに Chrome の Lighthouse ドキュメントが 1 件、Reddit のスレッドが 1 件。ブラウザで動く生成ツールや検証ツールは一件も入っていません。この検索語は「読んで理解したい」意図であって、「今すぐ作りたい」意図ではない、ということです。
そして日本語圏では、この話題は一貫して「LLMO」の枠で語られています。 上位十件のうち三件が見出しに LLMO を掲げています。英語圏の GEO ではなく LLMO が日本の実務の語であることは、この検索語でもそのまま観察できます。日本語で書くなら、その語で書いたほうが読者に届きます —— LLMO の解説はこちらにまとめてあります。
「書き方」に寄っているのは事実ですが、懐疑論に触れる記事もあります。 見出しの多くは「書き方」「設置手順」型です。ただし四位の記事は見出し自体に「意味がないと言われる理由」を含んでいます。上位が全部お行儀のいい紹介記事だ、とは言えません。
そのうえで、このページが足しているのは数字です。仕様の解説はどこでも読めます。137,210 ドメインのうち 97% がゼロ回、という実測と、Google 自身の否定を日本語で並べて置いてある場所は、この十件の見出しからは見当たりませんでした。
sitemap から生成する
llms.txt の失敗の仕方は「書けないこと」ではありません。3 か月後に静かに腐っていくことです。サイトは動くのにファイルは動かない。手で維持している index は、無いよりも悪くなります —— もう存在しないサイトを、自信満々に説明してしまうからです。
ですから生成してください。入力はサイトの在庫、つまり sitemap です。手順は三つ。
1. sitemap が仕様どおりか確かめる。 壊れた在庫から作った index は壊れています。XML サイトマップ検証ツールは、貼り付けかドラッグでファイルを渡すと行番号つきでエラーを返します。ブラウザ内で完結し、アップロードはしません。
2. URL ごとに一行の説明を書く。 ここだけは人間（またはエージェント）の仕事です。そのページに何が書いてあるかを書きます。読者がなぜ読むべきかではありません。形容詞はコンテキストを食うだけで何も買いません。
3. 生成して、公開して、検証する。 できたファイルを llms.txt バリデータに通します。公開仕様に対して行単位で検証し、修正版をそのままコピーできます。
サイトを機械に見せる作業をコマンド側で回しているなら、自分のサイトの現状はこれで読めます。
$ npm i -g @clize/clize && clize login
$ clize seo check --domain example.jp返ってくるのは、Search Console の表示回数・クリック・平均掲載順位を前の期間と比べた値、ページごとの実際の HTTP ステータスと Google 自身の言葉によるインデックス判定（Submitted and indexed、Crawled — currently not indexed）、そして AI エンジンを分けて集計した参照元別のトラフィックです。
llms.txt / robots.txt / sitemap.xml の違い
三つとも「サイトのルートに置く機械向けのファイル」ですが、答えている質問が違います。混同すると、片方をもう片方の代わりに使ってしまいます。
| ファイル | 答えている質問 | 形式 | 誰が読むか |
|---|---|---|---|
robots.txt | 入っていいか | 独自形式 | ほぼすべてのクローラー（従うかは別） |
sitemap.xml | URL は全部でどれか | XML（sitemaps.org 0.9） | 検索エンジン。Search Console で提出する |
llms.txt | 中に何があり、どう読めばよいか | Markdown | 主にコーディングエージェント。実測ではほとんど取得されていない |
実務上の順番も決まります。robots.txt が AI クローラーに 200 を返す状態を作るのが先で、sitemap が仕様どおりなのがその次、llms.txt はその上に乗る任意の層です。逆順にやると、誰も入れないサイトのきれいな目次を作ることになります。
よくある間違い
- 手で維持する。 index とサイトがずれていき、ファイルが嘘をつき始めます。生成してください。
- H1 がない、要約がない。 H1 は仕様が唯一必須としているセクションで、引用ブロックはリンク群を解釈可能にするものです。Lighthouse の監査は、見出しがない・短すぎる・リンクがないファイルを指摘します —— 「エージェントがこれから何も得られない」の手頃な代理指標です。
- sitemap をそのまま流し込む。 全 URL、説明なし、グループ分けなし。それは構文の悪い sitemap です。
- 注記に宣伝文句を書く。 一行の注記は、そのページに何が書いてあるかを言うためのものです。
/llms.txtで HTML を返す。 404 ハンドラがステータス 200 で装飾されたページを返す設定だと、エージェントは Markdown のあるべき場所でマークアップの壁を受け取ります。ステータスコードと Content-Type を確認してください。- 順位を期待する。 エージェントがドキュメントを読むから公開するのであって、掲載順位のためではありません。
最後の一つは curl で 5 秒です。
$ curl -sI https://example.jp/llms.txt | head -3公開すべきか
判断はサイトの性格で決まります。
公開する価値がある：開発者向けドキュメントや API リファレンスを持っているサイト。エージェントがあなたのドキュメントを読む場面が実際にあり、v2 が寄せているのもここです。それから、自分たちのエージェントに自社サイトの地図を渡したい場合。
急がなくてよい：数ページの企業サイトや、ドキュメントを持たないサービスサイト。生成が自動化されていないなら、腐ったファイルを置くより置かないほうがましです。
効果を誤解してはいけない：どのケースでも、これは検索順位の施策ではありません。Google は使わないと明言しており、公開されたファイルの 97% は 1 か月に 1 回も取得されていません。それでも作るなら、書くこと自体が強制する規律 —— 正典となる一文と、ページごとの一行説明 —— のほうが、ファイルそのものより価値が大きいかもしれません。
// よくある質問
llms.txt とは何ですか？
サイトの中身を Markdown で index したファイルです。llmstxt.org が公開している仕様に沿って、サイト名の H1（唯一の必須セクション）、要点をまとめた引用ブロック、そして H2 で区切ったファイルリストを置きます。各項目は [名前](URL) というリンクで、任意で注記を付けられます。robots.txt が「入っていいか」を宣言するのに対し、llms.txt は「中に何があるか」を宣言します。
llms.txt は SEO に効果がありますか？
検索順位には効きません。Google 検索は llms.txt を使わないと自社ドキュメントで明言しており、検索の生成AI機能に関するガイダンス（2026年7月10日更新）は、検索に載るために機械可読ファイルや AI 用テキストファイルを新たに作る必要はないと書いています。あわせて、他のシステム向けに維持しても検索での見え方に有利にも不利にもならない、とも述べています。Gary Illyes は 2025 年 7 月に対応予定はないと発言しています。
実際にどれくらい読まれているのですか？
Ahrefs が 2026 年 5 月にトラフィックのあった 137,210 ドメインを調べたところ、約 38,000 が妥当な llms.txt を配信していました（約 28%、著者自身が上限だと断っています）。そのうち 97% はその月に 1 回もリクエストされていません。届いたリクエストのうち AI ボットは 19.5% で、77% は SEO 監査ツールや素性不明のクローラーなど AI 以外でした。しかも著者が言うとおり、リクエストされたことと、取得した内容にボットが従うことは別の問題です。
v2 では何が変わりましたか？
2026 年 8 月の v2 で四点。ページの Markdown 版を type="text/markdown" の alternate、それをカバーする llms.txt を describedby というリンク関係で発見できるようになったこと。Markdown の URL 形式が page.html.md と page.md の両方とも正式になったこと。サブパスの意味が定義され、最も具体的なファイルが勝つと決まったこと。そして ## Optional が機械的な意味を失い、慣習として残るだけになったことです。
LLMO と llms.txt はどう関係しますか？
日本語圏では llms.txt がほぼ必ず LLMO の文脈で語られます。実際 2026 年 9 月 5 日時点で「llms.txt とは」の上位十件のうち三件が見出しに LLMO を掲げています。ただし関係は限定的です。llms.txt はエージェントにドキュメントを読ませるための任意の層であって、生成エンジンでの言及頻度を上げる施策ではありません。順番としては、AI クローラーが 200 を受け取れること、sitemap と構造化データが仕様どおりであることが先です。
llms.txt はどう作ればいいですか？
手で維持しないでください。3 か月で腐り、サイトについて嘘をつき始めます。sitemap を入力にして生成するのが基本です。まず sitemap が仕様どおりか検証し、次に URL ごとに「そのページに何が書いてあるか」の一行を書き、最後に llms.txt バリデータで公開仕様に対して行単位で検証します。どちらのツールもブラウザ内で動き、ファイルはアップロードされません。
llms.txt と sitemap.xml は両方必要ですか？
答えている質問が違うので、置き換えにはなりません。sitemap.xml は「URL は全部でどれか」を XML で答えるもので、検索エンジンが読み、Search Console で提出します。llms.txt は「中に何があり、どう読めばよいか」を Markdown で答えるもので、主にコーディングエージェント向けです。優先順位は robots.txt、sitemap.xml、llms.txt の順です。
ファイルを作る前に、まず 200 が返っているか。
1 コマンドで、ページごとの HTTP ステータス、Google 自身のインデックス判定、Search Console の表示回数と平均掲載順位、そして AI エンジンを分けた参照元の内訳が返ります。
$ npm i -g @clize/clize && clize login $ clize seo check --domain example.jp[ Agent SEO → ]