Google が「AI 検索に llms.txt は不要」と発表した件を冷静に読み解く
2026-05-15 公開の Google Search Central『AI optimization guide』を一次資料として読み込み、llms.txt や JSON-LD は本当に不要なのか、他の AI 製品との関係はどうなのかを整理します。
2026 年 5 月 15 日、Google Search Central が「Generative AI search optimization guide」というドキュメントを公開した。読んでみると、業界で「これは効くのでは」と注目されてきた llms.txt や AI 向け JSON-LD について、けっこうきっぱりと一刀両断している。曰く、「生成 AI 検索に表示されるために、新しい機械可読ファイルや AI 用テキスト、専用マークアップ、Markdown は不要」だと。構造化データに関しても「生成 AI 検索には必須ではなく、追加すべき特別な schema.org マークアップもない」と書いてある。
YomuScore は llms.txt や JSON-LD を含む 47 項目で AIエージェント対応度を診断するサービスなので、当然「あれ、YomuScore って意味あるんだっけ」という反応があった。本記事では、Google の文書を一次資料として読み込みつつ、何が変わって何が変わらないのかを整理したい。先に立場を明らかにしておくと、Google の主張それ自体は技術的に正確で、しかしそれは Google というプラットフォームの特殊な立ち位置を反映したものでしかなく、業界全体に拡張できる話ではない、というのが筆者の見立てだ。
Google が言ったこと
不要だと明示的に書かれたのは、llms.txt や AI 用 Markdown ファイル、生成 AI 検索向けの特別な schema.org マークアップ、コンテンツの "chunking" (段落単位での細かい区切り)、AI を意識したコンテンツのリライト、そして不自然な「言及」を獲得しに行く施策、といったあたりだ。逆に推奨されているのは、独自視点を持つ高品質コンテンツ、技術的な SEO の基礎 (クロール、モバイル、ページ体験)、Google Business Profile や Merchant Center の整備、Search でインデックスされていること、という極めて伝統的なリストである。
要するに「我々のクローラーは優秀なので、特別なヒントを付けてくれなくても本文は理解できる」と言っている。これは技術的に妥当な主張だと思う。Googlebot は 25 年以上のクロール経験を持ち、PaLM や Gemini をベースにした NLP 基盤の上で動いている。HTML の構造をパースして装飾的な要素を除外し、本文を抽出する能力は他社が容易に追いつけるものではない。Google が「我々は llms.txt を必要としない」と言うのは、自信過剰というよりも、たぶん事実に近い。
それは Google だけの事情
問題はここから先で、Web サイト所有者が AI 経由で獲得したいユーザーは、Google Search の生成 AI 機能だけから来るわけではない、という現実がある。
2026 年現在、実際にサイトを「読みに来る」AI 製品をいくつか挙げてみる。
| 製品 | llms.txt / AGENTS.md の扱い |
|---|---|
| ChatGPT (OpenAI) | Browse 機能でクロール時に参照、サイト構造のヒントとして活用 |
| Claude (Anthropic) | Claude Code が AGENTS.md / CLAUDE.md を最優先で読む。Web 検索も llms.txt を見る |
| Perplexity | 引用ソース選定時に llms.txt と JSON-LD を強く考慮 |
| Cursor | リポジトリ内の AGENTS.md や .cursor/rules を IDE コンテキストとして使う |
| GitHub Copilot Workspace | workspace コンテキストで AGENTS.md を優先的に読み込む |
| Continue.dev / Cline 等 | プロジェクトの AGENTS.md を自動スキャン |
これらの製品に共通している事情は、Google 規模のクロール基盤を持っていないということ。リクエストごとに対象サイトをフェッチし、限られた時間で本文を抽出しなければならない。Markdown 化された目次が用意されているサイトとそうでないサイトでは、AI 側の処理コストと精度が桁で違ってくる。
そして個人的に一番興味深かったのは、AI を作っている当事者たちが自社のサイトでどう振る舞っているか、だった。Anthropic の公式ドキュメントサイトは docs.anthropic.com/llms.txt と llms-full.txt を実際に配信している。Stripe、Cloudflare、Vercel、Resend、Linear、Liveblocks — いずれも Markdown ミラーや構造化された AI 向けインデックスをきちんと整備している。Google が「不要」と公言した仕様を、AI 業界のフロントランナーたちが自社サイトで実装している。これは結構強いシグナルだと思う。
筆者の解釈はこうだ。Google は「サイト側の協力が不要なほど強力なクローラーを持っている」という、業界でほぼ唯一のプレイヤーであり、その特殊な立場からの発言をしている。それ以外の AI プロバイダや AI を使う開発者ツール側から見れば、サイトが llms.txt や AGENTS.md を提供してくれた方が圧倒的に処理が楽で、引用やコンテキスト化の精度が上がる。両者は矛盾していなくて、同じ事実の異なる側面を見ているだけ、という気がする。
では実務的にどうすればいいのか
判断はわりと単純で、自社のユーザーがどこから来ているかで決まる。
Google Search からの流入だけが事実上のチャネルなら、Google の言う通りでいい。高品質なコンテンツを書き、技術的 SEO の基礎を整え、Business Profile を最適化する。llms.txt の準備は工数がかかる割に Google からのリターンはほぼゼロ、と Google 公式が言っているのだから、それを信じればいい。
一方で ChatGPT、Claude、Perplexity、あるいは Cursor や Copilot などのコーディング AI からも見つけてもらいたいなら、話は逆になる。これらの製品にとって llms.txt や AGENTS.md は引き続き有効で、むしろ Google が「不要」と言ったことで他社との差別化要因にもなりうる。「Google には不要、他 AI には有効」という二極構造の中で、自社がどちらに比重を置くかを決める、という判断だ。
YomuScore のスコアリングは、後者 (マルチ AI エコシステム) の側を見ている。Vercel の Agent Readability Spec と llmstxt.org の合計 47 項目は、Google Search の一社の都合ではなく、業界全体が向かっている方向を反映したものだ。なので今回の Google 発表で診断ロジックを変更する予定はない。
これからの業界
おそらく Google は今後も「うちは追加ヒント不要、純粋にコンテンツ品質と独自視点で勝負」という方針を続けると思う。一方で OpenAI、Anthropic、Perplexity といった他の AI プロバイダは、Google 規模のインフラに到達しないまま当面進む。そしてその間にコーディング AI を含む新しい AI ツールが続々と登場する。
業界の収束点は、おそらく「llms.txt をベースに、製品ごとの方言が周辺にある」という状態に向かうのではないかと思う。Cursor の .cursor/rules、Claude Code の CLAUDE.md、その他のツールが採用する細かい仕様 — それらすべての共通基盤として llms.txt と AGENTS.md がある、という構図だ。Vercel が Agent Readability Spec で試みているのも、まさにこの共通基盤化である。
「Google が不要と言ったから llms.txt は死んだ」と書く記事はこれからもしばらく出続けると思う。逆に「Google に逆らって全力で llms.txt を整備しよう」と煽る記事も出るかもしれない。どちらも極端で、現実はその間にある。サイトの作り手として一番大事なのは、こうした業界の声明や記事を一次資料に当たって読み解いて、自社のユーザーの動線に基づいて判断することだろう。
補足: YomuScore の今後
今回の発表を受けて、いくつか機能調整を考えている。スキャン結果ページに「Google Search 向け / マルチ AI 向け」の 2 軸スコア表示を加える、改善ヒントに「Google Search 必須 / ChatGPT 向け / Claude 向け」の分類タグを付ける、あとは業界動向を一次資料ベースで追跡する記事 (本記事のような) を継続発信する、といったあたりだ。仕様変動が速い領域なので拙速に実装するつもりはないけれど、「事実関係を整理して提示する」のは YomuScore の責務だと思っている。
参照リソース