llms.txtとは?意味ないと言われる理由とGoogle公式の見解
llms.txtは、サイトの概要と重要な情報へのリンクをMarkdownで示し、LLMが推論時に使いやすい入口を作る提案です。2026年7月31日時点では提案段階で、Google検索も使わないと明記しています。表示や順位を期待する施策ではなく、情報整理と検証に用途を定めて導入を判断しましょう。

llms.txtとは、サイトの重要ページを大規模言語モデル向けにMarkdownで一覧化する提案仕様です。結論から言うと、Google検索の可視性やランキングには利益も害もありません。Google公式が明確にそう記載しており、Google Searchはこのファイルを使用しません。「llms.txtは意味がない」と言われる理由もここにあります。
ただし提案仕様であることと、作る価値がないことは別です。この記事では仕様の中身、Googleとそれ以外のAI検索で確認できること・できないこと、意味がないと言われる背景、運用でつまずく原因、公開前に確認すべきことまでを、一次情報に沿って整理します。
llms.txtとは|定義と扱う範囲
llms.txtとは、サイトやプロジェクトの背景、案内、詳細なMarkdown文書へのリンクを、主に/llms.txtへまとめて提供するという提案です。
提案者はJeremy Howard、公開日は2024年9月3日です。提案元のllmstxt.orgは、llms.txtをLLMがウェブサイトの情報を推論時に使うのを助けるためのものと説明し、コミュニティから意見を受け付けています。したがって、確立済みのウェブ標準や正式な規格として扱うのは適切ではありません。本記事の確認日は2026年7月31日です。
llms.txtが意図するのは、サイト全体の代替物を作ることではありません。短い背景情報と案内を示し、必要な詳細情報へたどる入口を作ることです。どのアプリケーションが、どのようにファイルを処理するかは提案に含まれておらず、「公開すれば特定のAIが自動的に読む」という挙動も定められていません。
| 誤解しやすい点 | 確認できる位置づけ | 確認できないこと |
|---|---|---|
| 新しいウェブ標準である | コミュニティの意見を受け付けている提案 | 標準化団体による承認 |
| AI検索の表示条件である | LLM向けの情報整理を意図したMarkdownファイル | 表示・引用・順位の保証 |
| サイト本文を置き換える | 背景、案内、詳細文書へのリンクをまとめる入口 | 元ページなしで正確性を保てること |
| すべてのAIが同じ方法で処理する | 処理方法はアプリケーション次第 | 各AIサービスの対応状況 |
この記事では、定義、提案の背景、形式上の必須・任意、既存ファイルとの違い、GoogleとOpenAIの公式情報から判断できる範囲を扱います。掲載ページの詳しい選び方や更新手順、公開前の網羅的な確認表、失敗原因の分析には踏み込みません。
なぜ生まれたのか:LLMのコンテキストウィンドウという制約
llms.txtは、LLMが大規模なウェブサイト全体を一度に扱えないというコンテキストウィンドウの制約を背景に提案されました。
ウェブページには本文だけでなく、ナビゲーション、広告、JavaScriptなど、人がサイトを利用するための要素が含まれます。提案文は、複雑なHTMLをLLM向けのプレーンテキストへ変換する作業には難しさと不正確さがあり、ウェブサイト全体はコンテキストウィンドウに収まらない場合があると説明しています。
そこで、サイトの概要と重要な情報の所在を、簡潔で人にもLLMにも読めるMarkdownでまとめる考え方が示されました。想定されている主な用途は、ユーザーが支援を求める時点の「推論」です。将来の学習で使われる可能性にも触れられていますが、原文は「普及すれば将来利用されるかもしれない」という推測形であり、学習利用を約束した記述ではありません。
| 背景にある課題 | 提案されている対応 | 過大解釈しない点 |
|---|---|---|
| サイト全体がコンテキストに収まりにくい | 重要情報への入口を小さくまとめる | サイト全体を完全に理解させる仕組みではない |
| 複雑なHTMLの変換が難しい | Markdownで簡潔な情報を示す | HTMLページが不要になるわけではない |
| 必要な詳細情報の所在が分かりにくい | 説明付きリンクで案内する | リンク先の品質を自動で保証しない |
| アプリごとに利用方法が異なる | 処理方法を固定しない | 特定サービスの対応を意味しない |
ファイル形式の仕様:置き場所・構成順序・必須項目
llms.txtはルートパスの/llms.txt、または任意でサブパスへ置き、決められた順序で構成しますが、唯一の必須項目はサイト名またはプロジェクト名を示すH1です。
「H1、引用形式の要約、H2がすべて必須」と理解すると、提案内容より要件を増やしてしまいます。原文は構成順序を示す一方、必須なのはH1だけだと明記しています。BOM、要約、追加説明、H2で区切るfile listは任意です。
| 順序 | 要素 | 必須・任意 | 役割 |
|---|---|---|---|
| 1 | BOM | 任意 | 文字コードを示すために付く場合がある |
| 2 | サイト名・プロジェクト名のH1 | 必須 | ファイルが何を扱うか示す |
| 3 | 引用形式の短い要約 | 任意 | 後続情報を理解するための重要な背景を示す |
| 4 | 見出し以外のMarkdown要素 | 任意、0個以上 | 詳しい背景や解釈の手掛かりを補う |
| 5 | H2で区切ったfile list | 任意、0個以上 | 詳細情報があるURLを分類して案内する |
ルートパスが基本として示される一方、サブパスへの配置も任意で認められています。また、Markdownを採る理由は、人とLLMが読めるだけでなく、パーサーや正規表現のような通常の方法でも処理できる明確な形式を目指しているためです。
この構成は、企業情報、サービス情報、技術文書をファイル内へ大量に複製するためのものではありません。H1で対象を示し、必要に応じて短い背景を補い、詳細はリンク先で確認できるようにする「案内」の構造だと捉えると役割がぶれにくくなります。
file listの形式とリンク注記の役割
file listはH2ごとに分類したMarkdownのリストで、各項目にはMarkdownリンクが必須となり、コロンに続く短い注記は任意です。
リンク名だけでは、どの質問に答える文書なのか、何が確認できるのかを判断しにくくなります。提案元は、リソースへリンクするときに簡潔で情報量のある説明を添えるよう勧めています。注記は任意ですが、リンク先の役割を短く限定できれば、利用側が必要な情報を選びやすくなります。
| file listの要素 | 必須・任意 | 書く内容 | 判断の観点 |
|---|---|---|---|
| H2 | file listを設ける場合に区切りとして使用 | 「製品情報」「技術資料」などの分類 | 分類名だけで内容を予測できるか |
| Markdownリンク | 各リスト項目で必須 | リンク名とURL | 名前とリンク先が一致するか |
| コロン | 任意 | リンクと注記の区切り | 注記がないなら付ける必要はない |
| 注記 | 任意 | リンク先で分かることの短い説明 | 曖昧語や未説明の専門語がないか |
file listは「AIに優先順位を命令するリスト」として定義されているわけではありません。また、提案元は掲載URL数やファイルサイズの上限を示していません。件数の固定値を外部記事から借りるのではなく、用途に必要な情報を簡潔に案内できるかで判断します。
「Optional」セクションが持つ特別な意味
H2の「Optional」は単なる「任意情報」という章名ではなく、短いコンテキストが必要なときに、その節のURLをスキップできることを示す特別な名前です。
主要な情報と二次的な情報を分けたい場合に使える考え方です。たとえば、サイトやサービスを理解するために不可欠な説明は通常のH2へ置き、補足資料のように省略しても中心的な理解を損ねにくいリンクを「Optional」へ分けます。
ただし、「Optional」に置けばリンク先へのアクセスを拒否できるわけではありません。これはコンテキストを短くするときに省略できるURLを表すものであり、クロールの許可・拒否、公開範囲、学習利用を制御する指示ではありません。アクセス制御の代わりに使わないことが重要です。
| 分け方 | 通常のH2によるfile list | 「Optional」節 |
|---|---|---|
| 情報の位置づけ | 中心的な理解に使う詳細情報 | 省略可能な二次情報 |
| 短いコンテキストが必要な場合 | 必要性を見て含める | URLをスキップできる |
| アクセス制御 | できない | できない |
| 運用上の確認 | 中心情報として現行か | 省略しても主要な質問へ答えられるか |
併記されているMarkdown版ページの提案
llmstxt.orgは/llms.txtだけでなく、LLMに役立つページについて、元URLへ.mdを付けたクリーンなMarkdown版を用意する考え方も併記しています。
ファイル名のないURLでは、index.html.mdを付ける形が示されています。この考え方は、llms.txtが入口となり、リンク先に詳細なMarkdown文書があるという全体像とつながります。llms.txtの短い説明だけに重要な事実を閉じ込めず、人が読む元ページと対応する詳細情報を用意する発想です。
一方、このMarkdown版ページの用意も、Google検索の生成AI機能に出るための要件ではありません。Googleは新しい機械可読ファイル、AIテキストファイル、マークアップ、Markdownを作る必要はなく、Google検索自体はそれらを使わないと説明しています。既存ページとMarkdown版の内容がずれれば管理対象が増えるため、目的と保守責任を説明できる場合に限って検討すべきです。
robots.txt・sitemap.xmlとの役割の違い
llms.txtはrobots.txtやsitemap.xmlを置き換えるものではなく、アクセス方針、検索エンジン向けURL一覧、LLM向けの厳選した案内という別々の役割を持ちます。
提案元は、robots.txtを自動ツールにサイトへのどのアクセスが許容されるか伝えるもの、llms.txtをユーザーがある話題の情報を明示的に求めたときにオンデマンドで使われることが多いものとして区別しています。したがって、llms.txtへ独自の拒否命令を書いても、robots.txtと同じ制御になるとは確認できません。
| ファイル | 主な役割 | 情報の範囲 | llms.txtとの関係 |
|---|---|---|---|
| robots.txt | 自動ツールに許容されるアクセスを伝える | クロールに関する方針 | llms.txtは代替できない |
| sitemap.xml | 検索エンジン向けにページを一覧化する | 原則としてサイト内の対象URL | llms.txtは厳選した概要という別目的 |
| llms.txt | LLM向けに背景、案内、詳細文書へのリンクを示す提案 | 必要な情報を選んだ概要 | 既存の仕組みと共存する想定 |
提案文は、sitemap.xmlではLLM向けの読みやすい版が載らないこと、外部URLを含まないこと、文書の総量がコンテキストウィンドウに収まらず不要な情報も含み得ることを、代替にならない理由として挙げています。ただし、これはllmstxt.org側が説明する設計思想です。各検索サービスの公式な掲載条件とは分けて理解します。
Googleの公式見解:生成AI機能では使われない
Googleは、Google検索とその生成AI機能への掲載にllms.txtは必要なく、Google検索自体もllms.txtを使わないと明記しています。
Google Search Centralの英語版ガイドは、2026年7月10日UTCの最終更新表示で、不要なAIテキストファイルの作成を、Google検索では無視できるAEO/GEO施策の例に挙げています。ここから言えるのは「Google検索への掲載に必要ない」「Google検索は使わない」までです。llms.txtを置くと順位が下がる、ペナルティになるという否定的な効果は書かれていません。
Google検索の生成AI機能では、従来のSEOのベストプラクティスが引き続き基盤です。対象ページには、インデックス登録され、Google検索でスニペット表示の対象になり得ることなどの技術的な前提があります。llms.txtを作るかどうかと、公開ページをクロール・インデックス可能にし、読者に役立つ独自の内容を提供することは分けて考えます。
構造化データについても切り分けが必要です。Googleは、生成AI検索のために構造化データや特別なschema.orgマークアップを追加する必要はないとしていますが、Google検索のリッチリザルトの対象となるため、全体的なSEO施策の一部として構造化データを継続する価値があるとも説明しています。「生成AI検索に必須ではない」だけを取り出して、構造化データ全体が不要だと結論づけてはいけません。
周辺のAI検索対応やコンテンツ設計を整理したい場合は、AI導入の実務コラムも参考になります。
Google以外のAI検索で確認できること・できないこと
Google以外については、OpenAIがChatGPT検索の掲載前提を示している一方、llms.txtを実際に読むという公式表明は今回の確認資料では確認できません。
OpenAIのChatGPT検索ヘルプは、上位表示を保証する方法はないと明記しています。そのうえで、検索に含まれるためにOAI-Searchbotのクロールを許可し、ホスティング環境やCDNがOpenAIの公開IPアドレスからの通信を許可することが重要だと説明しています。これはChatGPT検索の掲載前提に関する説明であって、llms.txtの対応表明ではありません。
| サービス | 公式資料で確認できること | llms.txtについて確認できないこと |
|---|---|---|
| Google検索の生成AI機能 | llms.txtは掲載に不要で、Google検索自体は使わない | Google以外にも同じ判断が当てはまること |
| ChatGPT検索 | 上位表示は保証されず、OAI-Searchbotと公開IPからの通信許可が重要 |
ChatGPT検索がllms.txtを読むこと |
| その他のAI検索 | 今回の一次確認記録では掲載条件を確認していない | クローラ名、対応状況、引用への影響 |
AI検索ごとに掲載の前提は異なります。Googleの説明をChatGPT検索へ一般化したり、OpenAIの説明をGoogleへ当てはめたりせず、利用を想定するサービスの公式情報で確認する必要があります。対応が確認できていないサービス名を並べて「主要AIが読む」と説明するのは避けます。
提案段階でも作る意味があるかを判断する
llms.txtを作る意味があるとすれば、検索順位を上げるためではなく、重要情報を簡潔に整理し、実際のLLMで質問への回答可能性を検証できる場合です。
提案元が挙げる作成上の指針は、簡潔で明確な言葉を使う、リンク先へ短く有益な説明を添える、曖昧な用語や未説明の専門語を避ける、llms.txtをLLMコンテキストファイルへ展開するツールを使い、複数の言語モデルへ質問して答えられるか確かめる、という内容です。公開した事実ではなく、質問に答えられるかを確認する点が判断の中心になります。
| 判断軸 | 作る意味がある状態 | 優先しにくい状態 |
|---|---|---|
| 目的 | 対象のLLM利用場面と質問が定まっている | 「AI検索に効きそう」だけで始める |
| 情報 | 重要ページと説明を簡潔に整理できる | 元ページの内容が古い、または曖昧 |
| 検証 | コンテキストへ展開し、複数の言語モデルへ質問できる | ファイル公開だけを完了条件にする |
| 責任 | 内容とリンク先の整合を保つ担当者がいる | 更新責任を決められない |
| 優先順位 | 通常のクロール、インデックス、本文品質を整えている | 基盤の問題を残したまま置き換えを期待する |
検証では「ファイルが読めたか」だけでなく、自社が答えてほしい質問に対して、必要な前提と根拠ページを使った回答になるかを見ます。回答できなければ、リンク注記が曖昧なのか、元ページに答えがないのか、コンテキストへ展開した範囲が不適切なのかを切り分けます。これは検索表示の効果測定ではなく、用意した情報が想定用途で機能するかの確認です。
導入しない判断も合理的です。Google検索だけを目的とする場合、Google自身が使わないと明記しているため、llms.txtより既存のSEO基盤を優先する理由があります。ほかの用途で試す場合も、採用サイト数、普及率、引用増加、流入増加の一次データは今回の確認記録にありません。未確認の効果を前提にせず、保守と検証に使う工数に見合うかで判断します。
「llms.txtは意味ない」と言われる理由
Google検索での表示や順位を目的にllms.txtを運用すると、Google自身が使わないとする施策へ保守工数を配分することになります。
Google検索の生成AI機能は、従来の検索基盤を利用します。対象ページがインデックス登録され、通常の検索結果でスニペット表示の対象になり得ることに加え、サイトがSearch Console上でGoogle検索の生成AI機能の対象に含まれていることなど、既存の技術要件と本文品質を先に確認します。llms.txtは、この確認の代わりにはなりません。
構造化データも切り分けが必要です。Googleは生成AI検索のために構造化データや特別なschema.orgマークアップを追加する必要はないと説明する一方、Google検索のリッチリザルトの対象になり得る(適格性に役立つ)ため、通常のSEO施策として継続する価値があるとしています。「生成AI検索に必須ではない」ことを「構造化データ自体が不要」と読み替えないでください。
期待値の修正では、導入理由を次のいずれかに分けます。
- Google検索への表示や順位を期待している場合:llms.txtを成果施策として扱わず、クロール、インデックス、本文の独自性と正確性へ優先順位を戻す
- 社内や特定の検証環境で情報をまとめたい場合:利用場面、入力方法、対象質問、合格条件を明記して試行を続ける
- 利用する外部サービスの対応を期待している場合:そのサービスの公式情報で対応を確認できるまで、効果を前提にしない
設置効果を示す公開データは確認できていません。そのため、流入、引用、順位の増加をllms.txtの成果として約束せず、「指定したコンテキストと質問の条件下で、根拠どおり答えられたか」を検証可能な範囲とします。
運用でつまずく代表的な原因
llms.txtは置くだけでは機能しません。公開後に効果を判断できなくなる原因は、次の4つに集約されます。
原因1:目的と対象質問が曖昧
目的と対象質問が曖昧だと、掲載・除外・修正の判断基準がなくなり、サイトマップのような全URL一覧へ近づきます。
「AIに正しく理解してほしい」だけでは、誰の何についての理解かが決まりません。「導入責任者が対象条件を確認し、自社が対象か判断する」のように、読者、質問、判断を一文で固定します。その一文に関係しないURLは、件数に余裕があっても中心情報には置きません。
診断では、現在の各URLに「このページは何の質問へ答えるか」を付けます。具体的な質問を付けられない、注記が「詳しくはこちら」のように曖昧、複数ページを読んでも公式回答が見つからない場合は、llms.txtへ説明を足す前に元ページを改善します。価格、対象条件、提供範囲などの重要事項をllms.txtだけに書くと、元ページとの二重管理が生まれ、更新漏れを増やします。
| 診断項目 | 良い状態 | 失敗の兆候 | 修正先 |
|---|---|---|---|
| 対象読者 | 部門や判断場面が明確 | 「すべてのユーザー」 | 目的文 |
| 想定質問 | 一つの判断へつながる | 「会社について教えて」だけ | 質問一覧 |
| 根拠ページ | 回答箇所を特定できる | 複数ページを推測で接合 | 元ページ |
| リンク注記 | ページで分かる範囲を限定 | 誇張、抽象語、未説明用語 | llms.txt |
| 完了条件 | 質問テストで判定できる | 公開したこと自体が完了 | 検証記録 |
ゼロからの作成工程や掲載URLの選び方を知りたい場合は「llms.txtの作り方|掲載URLの選び方と更新手順」、公開可否を網羅的に確認したい場合は「llms.txtの公開前チェックリスト|記載内容・URL・更新体制を確認」が別の役割を担います。この記事では、すでに起きている症状から修正先を特定することに集中します。
原因2:Optional節の意味を使わず掲載しすぎる
掲載しすぎの問題は固定のURL本数ではなく、中心情報と省略可能な二次情報を分けず、すべてを同じ重みで並べることです。
提案元は掲載URL数やファイルサイズの上限を数値で示していません。外部記事の目安を公式条件のように採用せず、対象質問への必要性で判断します。llmstxt.orgでは、H2の「Optional」という節名に特別な意味があり、短いコンテキストが必要な場合、その節のURLは省略できると説明しています。
| 分類 | 置く情報 | 判定質問 | 誤った扱い |
|---|---|---|---|
| 通常のH2 | 中心的な質問へ答える根拠 | これを省くと主要な判断ができないか | 更新頻度だけで並べ替える |
| Optional節 | 省略しても中心的な理解を損ねにくい補足 | 短いコンテキストでも不要か | アクセス拒否に使う |
| 掲載しない | 重複、終了、根拠不明、対象外のページ | 具体的な質問を割り当てられるか | とりあえず残す |
| 元ページを修正 | 回答が曖昧または複数ページに分散 | 読者がページ単体で判断できるか | llms.txtだけで補足する |
Optional節はクロールや学習利用を制御する仕組みではありません。また、robots.txtの代わりにもなりません。補足情報をOptional節へ移せば、公開範囲の問題が解決するわけではないため、機密情報、認証後ページ、未承認情報は最初から掲載対象にしないでください。
修正後は、Optional節を含まない短い展開結果でも主要な質問へ答えられるかを確認します。答えられない場合は、重要なURLをOptional節へ入れた、通常のH2にある根拠が不足している、または質問自体が目的から外れている可能性があります。
原因3:LLMによる質問テストを運用に組み込んでいない
書式とURLの到達だけを確認しても、用意した情報から実際の質問へ答えられるかは分かりません。
llmstxt.orgは作成時の指針として、llms.txtをLLM用のコンテキストファイルへ展開し、複数の言語モデルにコンテンツについて質問して、答えられるかを試すことを挙げています。これは検索表示や外部サービスでの引用を保証する試験ではなく、指定した入力の中で情報設計が機能するかを確かめる試験です。
質問テストがないと、次の不具合を公開後も見逃します。
- リンク注記は正しそうに見えるが、根拠ページに回答がない
- Optional節を除いた展開結果では中心的な質問へ答えられない
- 古いページと新しいページが同時に入り、回答条件が混ざる
- 専門用語や対象範囲が曖昧で、モデルごとに異なる補完が起きる
| テスト条件 | 記録する内容 | 不合格の意味 | 主な修正先 |
|---|---|---|---|
| 同じ質問・同じ展開結果 | 質問、入力範囲、回答、確認日 | モデル差を比較できない | テスト設計 |
| Optional節なし | 主要質問への回答と根拠 | 中心情報が不足 | URL分類、元ページ |
| Optional節あり | 補足による回答の変化 | 二次情報が矛盾 | Optional節、注記 |
| 複数のLLM | 根拠外の補完、条件の欠落 | 表現や根拠が曖昧 | 元ページ、注記 |
一つのモデルが期待どおり答えたことだけで合格にせず、誤りが出たときはモデルを責める前に入力を点検します。期待する答えが元ページに明記されていないなら、llms.txtの注記を長くするのではなく、ページ所有者が読者向け本文を直します。
原因4:変更ルールと責任者がない
更新漏れは、固定の確認日を忘れたことより、元ページの変更を誰が検知し、誰がllms.txtへ反映するか決まっていないときに起きます。
提案元は推奨の更新頻度を数値で示していません。そのため、根拠のない周期を正解として転記せず、サービス条件の変更、URLの統合・削除、担当部門の変更、公開範囲の変更など、自社の変更契機へ連動させます。定期確認を置く場合も、情報の変化しやすさと運用能力に応じて決めます。
専任AI部門がない企業では、一人が複数の役割を兼ねても構いません。ただし、ページ所有者、llms.txt編集者、公開承認者、緊急時の停止判断者という役割は省略しません。担当者名だけでなく、判断内容、代理担当、成果物の保存場所まで記録します。
| 変更契機 | 検知する人 | 判断する人 | 必要な処置 |
|---|---|---|---|
| サービス条件の改定 | ページ所有者 | サービス責任者 | 本文と注記を照合し再テスト |
| URLの統合・削除 | Web担当者 | llms.txt編集者 | リンク更新または一時除外 |
| 公開範囲の変更 | 情報管理担当 | 公開承認者 | 掲載継続または緊急削除 |
| 重要ページの大幅改稿 | ページ所有者 | 検証担当 | 回答箇所と質問テストを更新 |
| 担当者の異動 | 部門責任者 | 運用責任者 | 代理担当と引継ぎ先を更新 |
リンクの応答確認は自動化できますが、説明と現行条件が意味まで一致するかは人が確認します。自動チェックの成功を承認の代わりにせず、変更理由、対象URL、確認日、承認者を残してください。
公開前に確認すること
実際のファイルの作り方とWordPressでの設置手順はllms.txtの書き方で扱います。ここでは公開前に落としてはいけない確認項目を挙げます。
記載内容は、唯一の必須要素であるH1と任意要素を取り違えず、定められた順序とリンク形式を確認できれば合格です。
llms.txtは通常、サイトのルートパス/llms.txtに置く提案ですが、サブパスも任意の配置先として示されています。ファイル内の要素には順序があり、必須なのはサイト名またはプロジェクト名を示すH1だけです。ブロック引用、詳細説明、H2で区切るファイル一覧を必須扱いしないよう注意します。
| 順序 | 要素 | 必須・任意 | 公開前の確認 |
|---|---|---|---|
| 先頭 | BOM | 任意 | 意図せず表示や処理を乱していない |
| 次 | サイト名・プロジェクト名のH1 | 必須 | H1が存在し、名称が正しい |
| 次 | 短い概要のブロック引用 | 任意 | 後続内容の理解に必要な要点だけか |
| 次 | 見出し以外の詳細説明 | 任意 | 曖昧語や未説明の専門用語がない |
| 次 | H2とファイル一覧 | 任意 | 分類名と掲載URLの関係が明確か |
ファイル一覧の各項目には、Markdown形式のハイパーリンク[name](url)が必要です。コロンに続く注記は任意ですが、付ける場合はリンク先の内容を簡潔かつ具体的に説明します。URLだけでは選定理由が分からず、誇張した説明では元ページと食い違うため、名称、URL、注記を一組で照合します。
「Optional」というH2には特別な意味があります。この節に置いたURLは、短いコンテキストが必要な場合に省略できる二次情報として扱われます。単に「任意」という日本語の感覚で章名を付けず、本当に省略可能な情報だけを分けます。
提案には、LLMが読む可能性のあるページについて、元のURLに.mdを付けたクリーンなMarkdown版を同じURL体系で用意する考えも併記されています。ファイル名のないURLではindex.html.mdを付ける形です。採用する場合は、HTML版とMarkdown版の内容、公開範囲、更新責任が一致するかを確認します。
掲載URLと元ページの確認
掲載URLは、公開中の正規URLへ到達でき、注記と元ページの本文が一致し、質問への回答箇所を特定できれば合格です。
URLを増やすこと自体は品質になりません。提案には推奨URL数やファイルサイズの数値上限がないため、独自の上限を公式要件のように扱わず、質問へ答えるために必要かどうかで選びます。外部URLを含める場合も、なぜサイトの理解に必要なのかを説明できるものに限ります。
| 確認項目 | 合格条件 | 不合格時の対応 | 証跡 |
|---|---|---|---|
| 到達性 | URLが正常に開き、公開範囲が想定どおり | 修正まで掲載しない | 応答確認日 |
| 正規性 | 重複URLではなく管理対象の正規URL | 正規URLへ統一 | URL台帳 |
| 現行性 | 終了条件や古い説明が残っていない | 元ページを更新または除外 | 所有者の承認 |
| 説明の一致 | リンク注記が本文の範囲を超えない | 注記を修正 | 照合箇所 |
| 回答可能性 | 想定質問へ自己完結して答える箇所がある | 元ページを改善 | 見出し・段落名 |
| 更新可能性 | 変更元と連絡先を追跡できる | 所有者を決めるまで保留 | 更新担当 |
元ページを正本とし、llms.txtだけに価格、条件、対象者などの重要事項を書き足しません。複数ページを読まなければ回答できない場合は、案内文でつなぎ合わせる前に、読者向けページの情報設計を見直します。
LLMに実際に質問して検証する
実行中は、llms.txtをコンテキスト用ファイルへ展開し、複数の言語モデルが想定質問へ根拠どおりに答えられるかを試せば合格判定に進めます。
llmstxt.orgの作成指針には、簡潔で明確な言葉を使うこと、リンクに短く有益な説明を付けること、曖昧語や未説明の専門用語を避けることに加え、展開ツールを実行して複数の言語モデルへ質問する検証が挙げられています。書式チェッカーでエラーがないだけでは、質問に答えられるかは分かりません。
| 記録項目 | 記載例 | 合格の見方 |
|---|---|---|
| 想定質問 | サービスの対象外条件は何か | 読者の判断に直結する具体的な質問 |
| 期待する根拠 | 対象条件ページの該当見出し | 元ページで承認済み |
| 使用した入力 | Optional節を除く/含む展開結果 | 入力範囲を再現できる |
| モデル別回答 | 回答本文と参照した箇所 | 根拠外の補完や矛盾がない |
| 判定 | 合格、修正、掲載除外 | 理由と確認者が残る |
モデルごとに回答が異なる場合は、良い回答だけを採用して合格にしません。注記が曖昧なのか、根拠ページに答えがないのか、Optional節へ重要情報を置いているのかを切り分けます。原因が元ページにあるなら元ページを修正し、再び展開して同じ質問を試します。
このテストは、外部サービスによる掲載や引用の保証ではありません。確認できるのは、指定した入力と質問の条件下で、用意した情報から回答できたかどうかです。使用環境、入力範囲、質問、回答、確認日を残し、未確認の一般効果へ広げないようにします。
よくある質問
Q1. llms.txtを設置すればGoogleの生成AI機能に表示されますか?
いいえ、表示は保証されません。Googleは、Google検索とその生成AI機能への掲載にllms.txtは必要なく、Google検索自体も使わないと説明しています。ただし、設置による順位低下やペナルティも示していません。Google向けにはクロール、インデックス、スニペット適格性に加え、サイトがSearch Console上でGoogle検索の生成AI機能の対象に含まれているかを確認し、読者に役立つ本文を優先します。
Q2. llms.txtではH1・要約・H2のすべてが必須ですか?
いいえ。提案文が唯一の必須項目としているのは、サイト名またはプロジェクト名を示すH1です。引用形式の短い要約、見出し以外の追加説明、H2で区切ったfile listは任意です。ただし、採用する要素には順序が示されているため、任意だからどこへ置いてもよいという意味ではありません。
Q3. robots.txtやsitemap.xmlの代わりになりますか?
代わりにはなりません。robots.txtは許容されるアクセスを自動ツールへ伝え、sitemap.xmlは検索エンジン向けにページを一覧化します。llms.txtは、LLM向けに厳選した背景と情報の所在を案内する提案です。llms.txtをクロール拒否やアクセス制御の手段として使わないでください。
Q4. 掲載しすぎを判断するURL数の目安はありますか?
提案元は掲載URL数の上限や推奨値を示していません。件数ではなく、各URLへ具体的な対象質問を割り当てられるか、短いコンテキストで省ける二次情報をOptional節へ分けられるかで判断します。重複、終了、根拠不明のページは掲載から外します。
Q5. 書式チェッカーで問題がなければ公開できますか?
書式確認だけでは不十分です。元ページとの一致、公開範囲、リンクの到達性、更新責任を確認したうえで、展開したコンテキストを複数の言語モデルへ与え、想定質問に根拠どおり答えられるかを試します。質問、入力範囲、回答、判定を証跡として残します。
Q6. 複数のLLMで回答が異なる場合はどう直しますか?
まず同じ展開結果と同じ質問を使ったかを確認し、根拠ページの不足、注記の曖昧さ、Optional節への誤分類、古い情報の混在を切り分けます。良い回答だけを採用して合格にせず、元ページを直したうえで再テストします。この試験は外部サービスでの表示や引用を保証するものではありません。
Q7. 作成後は何をもって有効と判断しますか?
提案元が示す検証は、llms.txtをLLMコンテキストファイルへ展開し、複数の言語モデルへ自社コンテンツに関する質問をして、答えられるか確かめることです。表示順位や引用増加を保証する試験ではありません。対象質問、期待する根拠、得られた回答、確認日を残し、情報整理という目的を果たすかで判断します。
Q8. 公開後はどのタイミングで見直しますか?
提案に固定の更新頻度は示されていません。ページの削除・統合、サービス条件の変更、担当者の異動、公開範囲の変更など、自社で定めた更新契機に合わせて見直します。確認日、変更理由、対象URL、承認者を記録し、保守できない場合は対象削減や公開停止を判断します。
まとめ
llms.txtは提案仕様であり、Google検索の可視性やランキングには利益も害もありません。Google Searchはこのファイルを使用しないと公式に明記されています。「意味ない」と言われるのは、Google検索への効果を期待して設置した場合に、その期待が満たされないためです。
それでも作る価値があるかは、Google以外のAI検索や社内向けの参照経路をどう扱うかで決まります。設置するなら、対象とする質問を先に決め、Optional節を使って掲載しすぎを避け、実際にLLMへ質問して回答が根拠へたどり着くかを確認してください。更新の責任者と変更ルールがないまま置くと、古い情報を配り続けることになります。
参考資料
本記事の記述は、次の公開資料を一次情報として確認しています。
AIで何ができるか、ではなく
どの業務から変えるか。
30分の無料相談で、現在の課題、最初に検証する業務、必要な支援の形を整理します。



