SILVEシルヴェ
無料で診断

AEO / GEO / LLMO 解説 ・ ・ 更新

llms.txt は必要か — Google は使わないのに Chrome は監査する

SILVE 編集部

矛盾して見える 2 つの事実

Google Search は llms.txt を使いません。 公式ガイドは、Google 検索（生成 AI 機能を含む）に表示されるために新しい機械可読ファイルや AI 向けテキストを作る必要はなく、Google Search 自身がそれらを使わないと明記しています。さらに、作成しても Google Search での可視性にも順位にも利も害も無いとしています。

一方、Chrome の Lighthouse は llms.txt を監査項目に持っています。 agentic browsing カテゴリで、llms.txt を次のように説明しています。

an emerging convention used to provide a machine-readable summary of a website's content, specifically designed for LLMs and AI agents

同じ Google なのに逆に見えます。しかし矛盾していません。見ている対象が違うからです。

何を見ているか llms.txt の扱い
Google Search 検索インデックスとランキング 使わない。順位にも可視性にも影響しない
Chrome Lighthouse ブラウザエージェントの操作性 任意の emerging convention として監査

「Google が llms.txt を採用した」という言い方は粗すぎます。 製品・システム・能力を分ける必要があります。

そもそも何を提案しているファイルか

llms.txt は 2024 年 9 月 3 日に Jeremy Howard が公開した提案です。提唱元自身の説明はこうです。

A proposal to standardise on using an /llms.txt file to provide information to help agents use a website.

確立した Web 標準ではなく「提案」として始まっています。 最終更新は 2026 年 8 月 10 日で、2 年間の実運用を踏まえた version 2 です。

sitemap.xml とも robots.txt とも違う

提唱元自身が違いを説明しています。

sitemap.xml との違い — これは llms.txt の提案側による対比です（2026.08.45 で限定）。 提案は、サイトマップを広範な URL の列挙、llms.txt を厳選した概要として対比し、サイトマップには LLM が読める Markdown 版が無く、内容がコンテキストウィンドウに対して多すぎることが多い、としています。

「サイトマップとは本質的に全 URL の一覧である」と一般化しないでください。 Google はサイトマップを「重要だと考えるページやファイルを伝えるもの」と説明しており、全ページの列挙を要求していません。 対比の枠組みは提案側のもので、Web の仕様上の定義ではありません。

robots.txt との違いは明確です。

robots.txt lets automated tools know what access to a site is considered acceptable, such as for search indexing bots. llms.txt information is instead used on demand, when an agent needs information about a topic.

「robots.txt の AI 版」という説明は不正確です。 robots.txt はアクセス制御、llms.txt は案内です。

したがって llms.txt に「学習禁止」と書いても、GPTBot や ClaudeBot に対する制御にはなりません。 学習の制御は robots.txt と各社のボット制御で行います（AI クローラの記事）。

全文を詰め込むものではない

v2 の提案は、llms.txt 自体を小さく保ち、エージェントがまず llms.txt を見て必要な資源を判断し、必要なリンクだけ辿る使い方を想定しています。

全コンテンツのダンプではなく、厳選された索引です。 サイトマップの 2,000 URL を Markdown へ変換しただけでは、コンテキストの負荷を下げるという趣旨と逆になります。

v2 ではさらに、エージェントが必要としそうなページについて同じ URL に .md を付けた Markdown 版（page.html.md、または拡張子を .md へ置換）を提供することや、rel="alternate" type="text/markdown" と rel="describedby" で対応関係を示すことも提案されています。

ただしこれも Google Search の要件ではありません。 Google は AI 専用の Markdown や新しい機械可読ファイルは不要と明記しています。

Chrome は何を監査しているのか — そして何を監査していないのか

ここが最も誤解されやすい部分です。

Lighthouse の llms.txt 監査は Google Search の SEO 監査ではありません。 新設された agentic browsing という別カテゴリで、対象は検索クローラではなくサイトを読み、場合によっては操作する AI エージェントです。

そして Chrome 自身が「必須ではない」と扱っています。

If the file isn't found (404 response), the audit is marked as Not Applicable (N/A), as providing the file is optional at the moment.

404 は失敗ではなく対象外です。 ただし判定はそれだけではありません。Lighthouse の実装は、取得できたファイルの中身も検査します（2026.08.45 で追記）。

現行の監査（core/audits/agentic/llms-txt.js）の判定はこうなっています。

状態 結果
取得に失敗した / ステータスが取れない 失敗（score 0）
5xx 失敗
4xx（404 を含む） 対象外（notApplicable）
2xx で取得できた 中身を検査する（下記）

取得できた場合に見るのは 3 つで、1 つでも欠けると失敗します。

  • H1 が 1 つ以上ある（# タイトル の形）
  • Markdown 形式のリンクが 1 つ以上ある（[テキスト](URL)）
  • 50 文字以上ある

リンクの検査は Markdown の記法を要求します。 裸の URL を並べただけでは、リンクが 1 つも無いと判定されます。 内容として正しくても落ちるので、ここは実務で引っかかりやすい点です。

Chrome の公開ドキュメントには、この中身の検査までは書かれていません。 「404 は対象外、サーバエラーは失敗」という説明だけを読むと、取得できさえすれば通ると誤解します。 判定の実体は実装側にあります。

つまり Chrome の立場は、

  • 存在すればエージェント向けの補助情報として使える可能性がある
  • 存在しないこと自体は失敗ではない

です。

agentic browsing カテゴリ自体が experimental

さらに Chrome は、agentic browsing カテゴリと WebMCP サポートについて experimental であり提案段階の標準に基づくと明記しています。テストには Chrome 150 以降が必要です。

そして 0〜100 の加重平均スコアを持ちません。 エージェント的な Web の標準がまだ形成途上であるため、決定的な順位付けではなくデータ収集と実行可能なシグナルの提供に主眼を置くとされています。

Chrome 自身が順位を付けない領域で、第三者の診断ツールが「llms.txt なし = −10 点」と大きく減点するのは、根拠より強い評価になります。

Lighthouse にあることをランキング要因に変換しない

これは SEO で起きやすい誤解です。

Lighthouse に項目があるからといって、Google のランキング要因とは限りません。 Lighthouse は Web ページの品質を監査する開発者向けツールです。しかも今回の llms.txt は experimental な agentic browsing カテゴリにあります。

Google Search とは別の製品・別の能力です。

大手 AI 企業が置いていることは何の証拠になるか

OpenAI と Anthropic は、開発者向けドキュメントの llms.txt を実際に公開しています（2026 年 8 月 11 日時点で両方とも取得できます）。

しかしここで区別が必要です。

何が確認できるか
公開している側（Publisher Adoption） llms.txt という公開の慣習が実際に使われている
読む側（Consumer Support） 特定の AI が任意のサイトの llms.txt を認識・利用する

「OpenAI が llms.txt を公開している」から「ChatGPT が全サイトの llms.txt を読む」は導けません。 前者はドキュメント提供者としての振る舞い、後者は検索製品の仕様です。

公開の広がりと、利用側の対応は同じ速度で進むとは限りません。

SILVE はどう扱うか — そして自分の誤りを直しました

この記事を書くために整理した結果、SILVE 自身の分類が間違っていたことが分かりました。

llms.txt の検出項目は crawlability.llms_txt という ID で、クロール可能性（検索側）のカテゴリに置かれていました。配点はしていませんでしたが、診断画面では検索対策の文脈で表示されていました。

Google が「Google Search は使わない。可視性にも順位にも影響しない」と明記しているものを、検索対策の並びに置いていたということです。 これでは「これが無いから AI 検索に出ない」と読まれます。

2026.08.18 で agent.llms_txt へ移しました。

前 後
ID crawlability.llms_txt（廃止・ID は残す） agent.llms_txt
カテゴリ クロール可能性 エージェント対応
採用状態 provisional（配点なし） provisional（配点なし）
実効重み 91 91（変化なし）

判定ロジックも重みも他の項目も変えていません。 どちらも配点対象外なので、実走スコアも 42 点のまま変わりません（cybozu.co.jp）。変わったのは、どの文脈で表示されるかだけです。

旧 ID を消していないのは、過去の診断がその ID を参照しているためです。

配点しない理由

  • 提唱元自身が「提案」と呼んでおり、Web 標準として確立していません
  • Chrome も emerging convention と呼び、提供を任意としています
  • Lighthouse は 404 を対象外として扱い、失敗にしていません
  • agentic browsing カテゴリ自体が experimental です

提供元が「任意」としているものを、こちらが減点対象にはできません。

何を報告するか

決定論的に検査できるのは、存在の有無・HTTP ステータス・見出しとリンクの数です。404 は失敗として扱いません。 Chrome の扱いに合わせます。

導入すべきかの判断

「AI 時代だから作る」ではありません。判断材料は次です。

優先度が低い — 一般的な企業サイト、ページ数が少ない、エージェントの利用場面が不明、そもそもクロール可能性やコンテンツに問題がある。この場合は先に基礎を直すべきです。

検討価値が高い — 開発者向けドキュメントが大規模、API リファレンスが多い、ナレッジベースが巨大、サイト構造が複雑、Markdown 版を既に管理できている。

OpenAI の llms.txt が開発者ドキュメントの索引として使われているのは、この用途と整合します。

作ったら維持する義務が生まれる

機械可読なファイルを追加すると、正確に維持する責任が生まれます。llms.txt が「最新 API は v3」と案内しているのにドキュメントが v4 なら、エージェントを古い情報へ誘導することになります。

不正確な llms.txt は、無いより悪い場合があります。 ただしこれは実験で確かめられた事実ではなく、SILVE の運用上の推論です（2026.08.45 で明示）。

根拠にしているのは提案側の利用モデルです。llms.txt 自体は小さく保ち、エージェントが必要なリンクをたどるという設計なので、古いリンクや誤った説明はエージェントを古い情報へ誘導し得ます。 そこから構造化データの記事で整理した Correct before complete を適用しています。

「無いより悪い」ことが測定されたわけではありません。 利用モデルから導いた運用方針です。

自動生成でも中身を確認する

CMS が自動生成できる場合、導入コストは下がります。しかし「自動生成された = 内容が適切」ではありません。 全 URL の列挙になっているなら、厳選された概要という本来の目的が薄れます。

セキュリティ制御には使えない

llms.txt に「購入は禁止」と書いてもエージェントの制御にはなりません。エージェント側のシステム指示・ツールのポリシー・権限・ユーザーの指示のほうが優先され得ます。

llms.txt に安全性の責任を持たせません。 権限は robots.txt・認証・認可・プロトコル側の問題です。

エージェント対応の中心でもない

Chrome の agentic browsing 監査は llms.txt だけを見ているわけではありません。アクセシビリティツリー・名前とラベル・可視性・レイアウトの安定性・WebMCP も対象です。

サイト構造を llms.txt で完璧に説明していても、予約フォームにラベルが無くエージェントが操作できなければタスクは完了しません。 llms.txt は補助的なシグナルの一つです。

そして llms.txt と WebMCP は役割が違います。 llms.txt は「どこに何があるか」、WebMCP は「何を実行できるか」です。まとめて「AI 用の構造化データ」と呼ぶと再び混乱します。

まとめ

  • Google Search は llms.txt を使いません。 可視性にも順位にも利も害も無いと明記されています
  • したがって「GEO 対策として llms.txt は必須」は、少なくとも Google Search については成立しません
  • 一方 Chrome の Lighthouse は emerging convention として監査します。 ただし提供は任意で、404 は対象外です
  • 矛盾ではありません。 見ているシステムが違います。「Google が採用した」とまとめないこと
  • robots.txt の AI 版ではありません。 あちらはアクセス制御、こちらは案内です
  • 大手が公開していることは、その検索製品が読む証拠にはなりません
  • 作るなら維持が必要です。 古い llms.txt は無いより悪い場合があります
  • SILVE は配点しません。 提供元が任意としているものを減点対象にできないためです

最適化すべきなのは「AI 向けと書かれた新しいファイル」ではなく、実際のシステムが利用するインターフェースです。

Framework Record

この記事の判断を、あとから検証できる形で記録したものです。本文の結論（Core Rules）と、SILVE が内部で持つ記録の項目、参照した一次資料が入っています。

Technology: llms.txt Category: Agent Discoverability / Documentation Interface Origin: 2024 年 9 月 3 日、Jeremy Howard による提案。v2 は 2026 年 8 月 10 日更新 Status: Emerging Convention（提唱元は proposal、Chrome は emerging convention と表現） Version: Methodology 2026.08.45 Last Verified: 2026-08-13 実装: src/lib/metrics/agent-readiness.ts の agent.llms_txt（provisional / 配点なし）

各システムでの扱い

システム 扱い 配点
Google Search 使用しない。可視性・順位に影響しない 0
Google AI Overviews / AI Mode 専用要件ではない（通常の検索要件が適用。加えて、利用できるサイトでは Search Console の生成 AI 掲載設定も掲載資格に関係する） 0
Chrome Agentic Browsing experimental な監査あり。提供は任意、404 は N/A 0（報告のみ）
ChatGPT / Gemini の引用 未検証 0

Core Rules

  1. llms.txt ≠ robots.txt（アクセス制御ではない）
  2. llms.txt ≠ sitemap.xml（列挙ではなく厳選）
  3. llms.txt ≠ Schema.org ≠ WebMCP
  4. Publisher adoption ≠ Consumer support
  5. Chrome の監査 ≠ Google Search のランキングシグナル
  6. Agent discoverability ≠ Search visibility
  7. ファイルの存在 ≠ 引用が増える証拠
  8. Emerging convention ≠ 確立した Web 標準
  9. 提供元が任意としているものを減点対象にしない

再検証

30〜60 日。 提唱は 2026 年 8 月 10 日に v2 へ更新されており、Chrome 側も experimental。 robots.txt のような安定した標準より変化が速い。

一次資料

llms.txtrobots.txtエージェントLighthouseGoogle Search

関連する記事

更新のお知らせを受け取る

評価基準の更新（毎月 15 日）と、新しい記事のお知らせをお送りします。

無料です。アカウントは要りません。配信はまだ始めていません。始めるときにこのお知らせからご案内します。いつでも解除できます。保存するのはメールアドレスだけで、他の用途には使いません。