サムネイル

llms.txtは作るべきか?Googleが社内で見解が割れている理由と実務判断

  • 0

こんにちは、AI集客のルイです。

llms.txtって作った方がいいんですか?」最近この質問、めちゃくちゃ増えてます。

調べれば調べるほどモヤモヤするんですよね。「Googleは不要って言ってる」という記事もあれば、「AI時代の新標準だから今すぐ作れ」という記事もある。しかもそれを発言してるのが、同じGoogleだったりするんです。

実はこのモヤモヤ、原因がハッキリしてます。2026年5月時点、Google自身が製品によって正反対のことを言ってるんです。検索の公式ガイドは「llms.txtはいらない」、Chromeの開発者ツール(Lighthouse)は「ないとエージェントが困る」と監査項目に追加した。同じGoogleなのに、です。

この記事では、その食い違いを整理した上で、「結局あなたのサイトでは作るべきか」を判断できる軸を渡します。読み終わる頃には、自分で即決できるようになってるはずです。

結論|llms.txtはマーケ担当なら「条件付きで作る」が正解

先に結論から言いますね。llms.txtが必要かどうかは、あなたの目的次第です。「全サイト作るべき」でも「全サイト不要」でもありません。

判断軸はシンプルで、こうなります。

  • 生成AI検索(AI Overviews / AIモード)で表示されたい → 作らなくていい
  • AIエージェントに自分のサイトを正確に扱ってほしい → 作る価値あり

この2つは目的が全然違うんです。なのに世の中の記事は「SEOに効くか効かないか」の一軸で語ろうとするから、答えが割れて見える。

生成AI検索(AI Overviews)対策が目的なら不要

「ChatGPTやAI Overviewsに自分の記事を引用してほしい」——マーケ担当がllms.txtに期待するのって、だいたいこれですよね。

結論から言うと、この目的なら作る必要はありません。Google自身が公式ガイドで「生成AI検索に出るためにllms.txtのような新しいファイルを作る必要はない」と明言してます。

つまり「llms.txtを置いたからAI Overviewsに載りやすくなる」という効果は、現時点では確認されていません。

AIエージェント対応が目的なら作る価値あり

一方で、用途を変えると話が変わります。

「エージェンティックブラウジング」——AIエージェント(コーディングエージェントやブラウザを操作するAI)が、人間の代わりにWebサイトを読んで作業する流れのことです。

このエージェントたちにとって、llms.txtは「サイトの案内図」として機能します。これがあると、エージェントがサイト構造を理解するのが速くなる。実際、ChromeのLighthouseはこの観点でllms.txtを監査項目に入れました(後述します)。

検索ランキング目的では不要、AIエージェント対応目的では有用。この棲み分けが全てです。

そもそもllms.txtとは何か(3分で把握する要点)

すでに知ってる人はこのセクション飛ばしてもらってOKです。

llms.txtは、fast.aiやAnswer.AIの共同創業者であるJeremy Howardさんが2024年9月に提唱した仕様です。サイトのルート(/llms.txt)に置くMarkdownファイルで、サイトの概要と主要コンテンツへのリンクを簡潔にまとめたものです。

なぜこんなものが生まれたか。LLM(大規模言語モデル)って、一度に読み込める文章量(コンテキストウィンドウ)に限界があるんですよね。広告だのナビゲーションだのJavaScriptだのが詰まったHTMLを丸ごと読ませるのは効率が悪い。だったら「このサイトの要点とリンクはここにまとめてあるよ」という案内図を用意しておこう、という発想です。

公式仕様はこちらにまとまってます。

robots.txt・sitemap.xmlとの違い

ファイル
主な役割
想定する読み手
robots.txt
クローラの巡回可否を制御する(ここは見るな/見ていい)
検索エンジンのクローラ
sitemap.xml
サイト内のURL一覧を機械可読で提供する
検索エンジンのクローラ
llms.txt
サイトの要約と主要コンテンツへの道案内を提供する
LLM・AIエージェント

robots.txtは「入っていい部屋・ダメな部屋の張り紙」、sitemap.xmlは「全部屋のリスト」、llms.txtは「初めて来た人向けの館内マップと見どころ案内」みたいなイメージです。

llms.txtrobots.txtsitemap.xmlを置き換えるものではありません。役割がかぶっていないので、「llms.txtを作ればsitemap.xmlはいらない」みたいな話ではないんです。

仕様の生い立ちとすでに設置している事例

llms.txtは2024年9月に提唱された、わりと新しい仕様です。Web標準として正式に承認されたものではなく、あくまで「提案された仕様(proposed standard)」という位置づけ。ここ、地味に大事なので覚えておいてください。

すでに設置している事例で多いのは、開発者向けドキュメントを持つサービスです。APIドキュメントやライブラリのドキュメントを公開している企業が、「AIにうちのドキュメントを正確に読んでもらいたい」という動機で導入しているケースが目立ちます。逆に言うと、一般的なオウンドメディアやコーポレートサイトで「全社が当たり前に置いてる」という段階ではまだありません。

llms.txtへのGoogleの見解が「製品によって正反対」になっている問題

Google検索セントラルとChrome Lighthouseのllms.txtへの見解を比較したインフォグラフィック

同じGoogleの中で、2つの製品がllms.txtについて正反対のシグナルを出してるんです。

  • Google検索セントラル(AI最適化ガイド)→「作る必要はない」
  • Chrome Lighthouse 13.3.0 →「ないとエージェントが困る」と監査項目に追加

「Googleは不要と言ってる」で止まっている日本語解説記事が多いんですが、実際はもっと込み入ってます。

Google検索セントラル:「作る必要はない」と明言

まず検索側。Googleは2026年に「生成AI検索のための最適化ガイド(AI optimization guide)」を公開しました。その中で、こうハッキリ書いてます。

  • 生成AI検索に表示されるために、新しい機械可読ファイル・AIテキストファイル・Markdownを作る必要はないllms.txtもここに含まれます)
  • 構造化データも生成AI検索には不要(ただしリッチリザルト用としては従来どおり有効)
  • 最重要なのは「サイト訪問者にとって満足のいく、独自で人間ファーストなコンテンツか」という従来型の原則

Google検索の立場を一言でまとめると「llms.txtに時間を使うくらいなら、良いコンテンツを書け」です。コンテンツを無理にチャンク化したり、キーワードを不自然に詰め込んだりする必要もない、とまで言ってます。

一次ソースはこちらです。マーケ担当なら一度は目を通しておくべきガイドです。

Chrome Lighthouse 13.3.0:「ないとエージェントが困る」と判定

ところがです。同じGoogleのChromeチームは、真逆とも取れる動きをしました。

2026年5月7日にリリースされたLighthouse 13.3.0で、「Agentic Browsing(エージェンティックブラウジング)」というカテゴリを、実験版から標準構成(デフォルト)に移行させたんです。

Lighthouseって、サイトのパフォーマンスやSEO、アクセシビリティを診断するあのツールですね。この新カテゴリが監査するのは、llms.txtの有無、WebMCP(AIエージェント向けにサイトの操作コマンドを提供する仕組み)の登録、アクセシビリティツリーの品質、レイアウトの安定性(CLSなど)です。

公式ドキュメントには、llms.txtについて「このファイルがないと、エージェントはサイトの全体構造と主要コンテンツを理解するのに、より多くの時間をかけてクロールすることになる」と書かれています。

一次ソースはこちらです。

ただし、超重要な注意点があります。この「Agentic Browsing」カテゴリは、他のLighthouseカテゴリと違って0〜100の加重スコアを出しません

各項目の合否シグナルが出るだけ。エージェンティックWebの基準自体がまだ発展途上だから、正解がない。だからデータ収集と実用的なシグナル提供が目的だと明言してます。llms.txtが404(未設置)でも「該当なし(N/A)」扱いで、減点ではありません。

なぜ同じGoogleで答えが割れるのか(用途の違い)

「結局Googleはどっちなの?」という問いの立て方自体が、実はズレてるんです。答えはシンプルで、見ている用途が違うだけ

Google検索セントラル
Chrome Lighthouse 13.3.0
見ている世界
生成AI検索(AI Overviews / AIモード)
AIエージェントによるサイト操作
llms.txtの扱い
不要(ランキングに使わない)
あった方がよい(クロール効率が上がる)
目的
検索結果に出すこと
エージェントがサイトを扱えること
スコア
(検索ランキングの話)
加重スコアなし・合否シグナルのみ

あなたが相手にしたいのは検索エンジンか、AIエージェントか」で答えが決まる。これが本質です。

llms.txtのSEO効果は実際どうなのか(生成AI検索で効くか)

「で、ぶっちゃけSEO効果あるの?」——投資対効果が読めないものに工数は割けない。正直に書きます。

生成AI検索のランキングを目的にするなら、llms.txtのSEO効果は現時点で確認されていません。「効果ゼロと証明された」わけではないですが、「効果あり」と断言できる根拠もない、というのが正確なところです。

Googleが「不要」と言う根拠

生成AI検索(AI Overviewsなど)は、通常の検索と同じランキングシステムの上に乗ってるんです。だから検索でちゃんと評価されるコンテンツは、生成AI検索でも拾われやすい。逆に言えば、llms.txtという別ファイルを用意しても、ランキングの入力にはなっていない。

元広告運用者の私からしても、これは正論だと思います。近道っぽいテクニックに飛びつくより、土台を固める方が結局リターンが大きい。

ChatGPT・Perplexityなど他のAIはどう扱うか

「Googleはそうでも、ChatGPTやPerplexityには効くのでは?」という期待もありますよね。

ただ、ここも冷静に。ChatGPT・Perplexity・Claudeといった他のAIサービスが、llms.txtを公式に「ランキングや参照に使う」と明言した事実は、現時点で確認されていません

混同しがちな点を補足します。AnthropicやPerplexityなどが自社の開発者ドキュメント向けにllms.txtを"置いている"のは事実です。でもそれは「自社docsをAIに読みやすくする」ための公開であって、「自社のAIが他サイトのllms.txtを読みに行く」という話とは別。公開する側と消費する側を混同しないようにしてください。

SEO担当がやるべきことは従来と変わらない

llms.txtは、この土台ができた上での「+α」でしかありません。

  • 検索意図に応える、独自性のある人間ファーストなコンテンツを作る
  • タイトル・見出し・内部構造といった基本的なテクニカルSEOを整える
  • sitemap.xmlrobots.txtをちゃんと運用する
  • E-E-A-T(経験・専門性・権威性・信頼性)を意識する

順番を間違えないでほしいんですよね。

llms.txtがAIエージェント・エージェンティックブラウジングで効く理由

llms.txtがAIエージェントのサイト巡回を効率化する案内図の概念図(あり・なしの比較)

ここからが、llms.txtが本当に意味を持つ領域です。検索の話とはきっぱり分けて考えてください。

「AIエージェント」というのは、人間の代わりにWebを読んで作業するAIのことです。コードを書くエージェント、ブラウザを操作して情報を集めるエージェント、業務を自動化するエージェント。2026年に入って、この分野が一気に動いてます。

こういうエージェントにとってllms.txtは「サイトの案内図」として機能します。

Lighthouseが監査項目に追加した背景

Chromeチームの問題意識はこうです。「これからWebを訪れるのは人間だけじゃない。AIエージェントも来る。じゃあサイトはエージェントにとっても扱いやすい状態になってるか?それを測れるようにしよう」。

だから監査するのがllms.txt(サイトの案内図)、WebMCP(操作コマンドの提供)、アクセシビリティツリー(構造の読みやすさ)、レイアウト安定性。どれも「エージェントがサイトを正確かつ効率的に扱えるか」という観点で選ばれてます。これは検索ランキングの話じゃなく、「エージェント対応の準備度チェック」です。

コーディングエージェントや自社サイトへの影響

あなたの会社がAPIやSDKのドキュメントサイトを公開しているとします。そこに開発者がClaude Codeのようなコーディングエージェントを使ってアクセスし、「このAPIの使い方を調べて実装して」と指示する。このときllms.txtがあれば、エージェントは「主要なドキュメントはここ」という案内をもとに、効率よく必要な情報にたどり着けます。

逆にllms.txtがないと、エージェントはサイト全体をクロールして構造を推測することになる。

llms.txtが効くのは「AIエージェントに読まれる前提のサイト」です。開発者向けドキュメント、技術ナレッジベース、APIリファレンスが代表例。一般的な商品紹介LPやキャンペーンページでは、効果は限定的です。

「Lighthouseスコアを気にする立場か」で判断が変わる

  • クライアントや上司にLighthouseのレポートを提出している立場 → エージェンティックブラウジングの項目に「未対応」が並ぶのは説明コストになる。先回りしてllms.txtを置く価値はある
  • Lighthouseを社内の品質基準にしていない立場 → 慌てて対応する必要はない。加重スコアにも影響しないので、放置しても「点数が下がる」わけではない

エージェンティックブラウジングは加重スコアに含まれません。あくまで「エージェント対応の準備度を見せる項目」です。

実際にllms.txtを作る場合の手順(最小工数版)

「よし、うちは作る側だな」と判断した人向けです。テンプレートをそのまま使えば、10分で終わります。

基本フォーマットと書き方

llms.txtは、ルートディレクトリ(https://example.com/llms.txt)に置くMarkdownファイルです。構造はシンプルで、必須なのは「H1のタイトル」だけ。入れておくと親切な要素がこれです。

  • H1のタイトル(必須・サイトやプロジェクトの名前)
  • 概要を1〜2行で書く引用ブロック(任意だけど推奨)
  • 主要コンテンツへのリンク一覧(任意だけど推奨)

ポイントは「LLMが読む前提で、簡潔に・要点だけ」書くこと。装飾もマーケ的な煽り文句もいりません。

10分で設置できる最小テンプレート

これをベースに自社の情報へ書き換えれば、ほぼそのまま使えます。

# サービス名(サイト名)

> このサイトが何を提供しているかを1〜2文で簡潔に。誰向けの、何のサイトかが分かるように書く。

## 主要コンテンツ

- [サービス概要](https://example.com/about): どんなサービスかの説明ページ
- [料金プラン](https://example.com/pricing): 価格と各プランの内容
- [導入ガイド](https://example.com/docs/getting-started): 使い始めるための手順
- [よくある質問](https://example.com/faq): 問い合わせの多い質問と回答

## その他

- [ブログ](https://example.com/blog): 最新の更新情報やノウハウ記事
- [お問い合わせ](https://example.com/contact): 連絡先

書くときのコツは2つ。リンクには必ず一言の説明を添えること(エージェントが中身を推測しやすくなる)、そして本当に重要なページだけ載せること(全ページ載せると案内図の意味がなくなる)。

設置自体は、このファイルをサイトのルートにアップロードするだけです。WordPressなど一部のCMSではプラグインで対応できる場合もありますが、基本は「ルートにllms.txtを1枚置く」と覚えておけばOKです。

設置後の確認チェックリスト

  • https://あなたのドメイン/llms.txt にブラウザでアクセスして、ファイルが表示されるか
  • ステータスコードが200で返っているか(404になっていないか)
  • リンク先のURLがすべて正しく開けるか(リンク切れがないか)
  • Markdownとして崩れず、見出しとリストが正しく表示されているか
  • 内容が最新か(料金やサービス名が古くないか)

特に大事なのが「リンク切れがないこと」と「内容が最新であること」。案内図が間違ってたら、エージェントを誤った場所に案内してしまいます。作って終わりじゃなく、サイト更新時に一緒にメンテする前提で持っておきましょう。

マーケ担当向け|llms.txtは必要か:優先度判断の基準

llms.txtを作るべきか後回しにすべきかを判断するフローチャート

ここまでの話を「自分のサイトはどうすべきか」に落とし込みます。迷ったらこの基準で即決してください。

大前提として、もう一度言います。llms.txt生成AI検索のランキング施策ではありません。「これを置けば検索流入が増える」と期待しているなら、優先度はゼロでいいです。そこは良質なコンテンツとテクニカルSEOで戦うべき領域です。

今すぐ作るべきサイトの条件

以下に当てはまるなら、作っておく価値が高いです。

  • 開発者向けドキュメントやAPIリファレンスを公開している(エージェントに読まれる前提のサイト)
  • AIエージェントやコーディングエージェントのユーザーが、自社サイトを参照する場面がある
  • クライアントや社内にLighthouseレポートを提出していて、エージェンティックブラウジング項目の「未対応」が気になる
  • 技術ナレッジベースやヘルプセンターを運用していて、AIに正確に読んでほしい

要は「AIエージェントが読みに来る理由があるサイト」ですね。工数も小さいので、サッと作ってしまった方が早いです。

後回しでよいサイトの条件

逆に、こういうサイトは慌てなくて大丈夫です。

  • 目的が「AI Overviewsや生成AI検索での露出」だけである
  • 一般的なコーポレートサイト・商品LP・キャンペーンページが中心で、エージェントが読みに来る動機が薄い
  • そもそもオーガニック検索の土台(コンテンツ品質・テクニカルSEO)がまだ固まっていない
  • Lighthouseを品質基準に使っておらず、提出する場面もない

特に「土台が固まってない」ケース。llms.txtに手を出す前に、やることが他にあります。

作る場合のコスト感と工数目安

初回設置は1時間もかかりません。小規模なサイトなら、テンプレートを埋めて確認まで含めて30分〜1時間くらいの感覚です。運用はsitemap.xmlのメンテと同じレベルの軽さなので、負荷は小さいです。

私の実務的な結論はこうです。コストが小さいぶん、「エージェントに読まれる前提のサイト」なら作っておいて損はない。でも生成AI検索のランキングを期待しての設置なら、今は不要。この線引きで判断すれば、まず外しません。

最後にこの記事の要点を、3行でまとめておきます。

  • llms.txtへのGoogleの見解は製品で正反対。検索セントラルは「不要」、Chrome Lighthouse 13.3.0は「あった方がよい」と監査項目に追加した
  • これは矛盾ではなく用途の違い。生成AI検索のランキング目的なら不要、AIエージェント対応目的なら有用
  • 判断軸は「自分のサイトはAIエージェントに読まれる前提か」。YESなら低コストで作る、NOなら後回しでOK

新しいファイル形式が出るたびに「乗り遅れたら終わる」と煽る情報が出回りますが、大事なのは流行語に振り回されず、自分の目的で要否を判断することです。この記事が、その判断のものさしになれば嬉しいです。

会員登録して機能を使おう

この機能を利用するには、無料の会員登録が必要です。
お気に入りの記事を保存して、あとで読み返しましょう!