llms.txtはSEOには効かない。だからこそ重要だ —— エージェントに「読まれる」Webという作法

llms.txtは、SEOには効かない。これは2026年の時点で、もう議論の余地が小さくなった結論だ。にもかかわらず、私はすべての企業サイトにllms.txtを置くべきだと考えている。理由は、それがSEOの道具ではなく、B2A——Business-to-Agent、エージェントに向けたアクセス——の道具だからだ。この記事は、その一見矛盾した主張を、実際に手を動かして得た観察と、2026年5月時点の検証データから解きほぐしていく。最後まで読むと、「あなたのサイトは、エージェントに読めるのか」という問いが、思っていたよりずっと差し迫った問いだとわかるはずだ。

エージェントは、頼まないものまで読みに行った

きっかけは、ごく実務的な作業だった。

弊社では社内の情報ポータルにRAG（検索拡張生成）を実装している。ここに、自社サイト untype.jp の情報も取り込ませたい。そこで、サイトを巡回してインデックス化する同期スクリプトを、Geminiに書いてもらうことにした。私が出した指示は「サイトの内容を読み込んで、検索できる形に同期するスクリプトを作って」という、ごく大まかなものだ。データの取得元をどうするか、どのファイルを読むかといった細部は、一切指定していない。

できあがったコードを見て、私は小さな、しかし示唆に富む事実に気づいた。Geminiが、私が一言も指示していないのに、llms-full.txt を読みに行く実装をしていたのだ。

なぜGeminiがこの設計を選んだのか、本当の理由は私には分からない。llms-full.txt の存在自体は知っていたが、スクリプトでそれを読めとは指示していない。推測するなら、この「全文版を読む」というやり方が、AIが学習した膨大なコードやドキュメントの中で、効率的な定石として広く共有されているのだろう。だが、それは確かめようのない私の憶測にすぎない。確実に言えるのは、人間が指示しなくても、AIはコードを書くときに llms-full.txt を取りに行く選択をした、という事実だけだ。

そして、その設計が効率的である理由は、考えてみれば当たり前だった。整理された一枚のテキストを直接読むのと、何十ページものHTMLを一つずつ巡回し、ナビゲーションやフッターやスクリプトの混じった雑多なマークアップから本文を切り出していくのとでは、消費するトークンも、解析の手間も、桁が違う。同じ情報を渡すのでも、「人間が読む前提の構造」と「機械が読む前提の構造」とでは、機械にとってのコストがまるで変わる。

トークン消費という観点ひとつとっても、構造化されたデータを置いておくことは、これからの時代の前提になりつつあるのかもしれない——そう感じた。だがここで立ち止まる必要がある。「llms.txtを置けばAIに有利」という話は、実は2025年に一度、手ひどく否定されているからだ。私が見たこの挙動は、その否定とどう折り合うのか。通説を直視するところから始めたい。

通説の解体：llms.txtはSEOには効かない

llms.txtを「AI時代のSEO」として売り込む言説は、2024年から2025年にかけて一気に広がった。robots.txt や sitemap.xml のように、サイトのルートに置くだけでAIに優遇される——そんな期待だ。だが2026年の検証データは、その期待をほぼ完全に裏切っている。順に見ていく。

採用は広がっておらず、検索系AIは読みに来ない

まず普及率。SE Ranking が30万ドメインを調査した結果では、llms.txt の設置率は約10%、およそ10サイトに1つにとどまった。提案から1年半が経っても、この水準だ。

次に、肝心の「AIが読みに来るか」。分析企業 Limy が90日間で5億1,500万回を超えるAIボットの訪問を観測したところ、llms.txt を直接取得しに来たのはわずか408回だったという。主要な検索・回答系のクローラー——GPTBot、ClaudeBot、PerplexityBot、Google-Extended など——は、llms.txt を素通りして、結局はHTMLを直接読んでいる。

そして、プラットフォーム側の態度も明確だ。Googleの Gary Illyes は2025年7月の時点で、Googleは llms.txt をサポートしないし、その予定もないと公言している。同じくGoogleのJohn Mueller は、これを「かつて廃れた keywords メタタグ」になぞらえた。極めつけは2026年5月15日、Google検索が公開したAI機能向けの最適化ガイドで、llms.txt は「生成AI機能のために必要のないもの」として、コンテンツのチャンク分割やAI向けの書き換え、特殊なスキーマと同じ箱に分類された。検索の文脈において、Googleは「要らない」と明言したのである。

やってはいけない実装もある

さらに注意すべき落とし穴がある。「llms.txt を効かせたい」と考えた人が、サイトの全ページをMarkdownで複製し、それらをインデックス可能な状態で置いてしまうケースだ。これは検索エンジンから見ると大量の重複コンテンツとなり、クロールバジェットを浪費し、元ページの評価をかえって下げかねない。良かれと思った実装が、SEO的には逆噴射する。

ここまでをまとめれば、「llms.txtでAI検索に強くなる」という売り文句は、2026年のデータに照らして支持できない。

なお、これは自社でも確かめられる。サーバーやCDNのアクセスログを、AI系のユーザーエージェント——GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot、Google-Extended など——で絞り込み、/llms.txt や /llms-full.txt へのアクセスがどれだけあるかを見ればいい。あるいは、そのファイルの中に、人間のリンク回遊では決して踏まれない「おとり」のURLを一つ仕込んでおき、そこへの到達を監視する手もある。CloudflareのAnalyticsを使えば、生ログに触れずともユーザーエージェント別のボット流量を確認できる。「効いている気がする」を、実測に置き換えられる。

では、私が untype.jp で見たあの挙動は、いったい何だったのか。答えは、llms.txt が効く「層」が、検索とはまったく別のところにある、ということだ。

ではなぜ効いたのか：B2Aという補助線

鍵になるのが、B2A——Business-to-Agent という補助線だ。これは分析企業Limyが提唱した言い方で、「企業がエージェントに向けて自社を差し出す」層を指す。

同じ llms.txt というファイルが、ChatGPTの検索引用にはほとんど寄与しない一方で、別の層では確かに仕事をしている。それは、AIエージェントが人間の代わりに動き、文脈を取得し、ツールを選び、タスクを遂行する「エージェンティックWeb」の層だ。実際、Cursor、Windsurf、Claude Code、GitHub Copilot、Cline、Aider といったIDE系のエージェントは、ドキュメントサイトに向けられると日常的に /llms.txt と /llms-full.txt を取りに行く。冒頭で見た、Geminiが頼んでもいないのに llms-full.txt を読む実装を選んだのも、この生態系の一部だ。死んでいたのはSEO用途の llms.txt であって、エージェント用途の llms.txt ・ llms-full.txt は、地味に、しかし確実に生きていたのだ。

この対比を、Googleが奇妙な形で体現している。先述の通り、Google検索は2026年5月15日に「llms.txt は不要」と言い切った。ところがそのわずか8日前の5月7日、Google傘下のChrome向け監査ツール Lighthouse はバージョン13.3で「Agentic Browsing（エージェントによる閲覧）」という監査カテゴリを追加し、llms.txt の有無をチェックし始めていた。つまり、エージェント向けの製品が「llms.txtを見る」と表明したそのせいぜい一週間後に、検索の製品が「見ない」と表明したことになる。同じ会社が、検索という製品では「要らない」と言い、エージェントという製品では「あった方がいい」と評価する。SEO用途とエージェント用途の分裂が、これ以上ないほどはっきり現れている。

ここで誤解を解いておきたい。B2Aは、B2CやB2Bの隣に並ぶ「第三の市場」ではない。エージェントは買い手ではなく、意図を持つ主体——人間や組織——の代理人（プロキシ）だ。実際、agentic commerce の最前線にいるOpenAIですら、最近はChatGPTを取引完結の場ではなく「発見と推薦のレイヤー」と位置づけ直し、決済や税や注文管理はマーチャント側の既存基盤に残す方向へ舵を切っている（具体的には、2025年9月にStripeと共同で始めたInstant Checkoutを2026年3月に廃止して、ショッピングの体験を発見・推薦側に切り替えた）。つまりB2Aは、新しい商品を作る話ではなく、既存の自分を、エージェントが読める・扱える形に翻訳する話なのだ。

図が示すのはこうだ。意図を持つのは依然として人間・組織であり、その主体がエージェントに委任する。エージェントは代理人として、企業・サイトと発見や取引を行う。かつて人間が企業へ直接アクセスしていた経路（点線）の上に、エージェントという新しいアクセス層が重なる。B2Aとは、この重なった層に向けて、自社を機械可読に差し出すことに他ならない。

B2Aの二層モデル

B2Aを実務に落とすとき、私はこれを二つの層に分けて考えることを勧めている。性質がまるで違うからだ。

第一に、読める層（Comprehension）。エージェントが「お前は何者で、何を提供しているのか」を正確に解釈できるか。llms.txt や構造化データ、機械可読なナレッジ、そしてサイトに自然言語インターフェースを与える NLWeb（RSSやSchema.orgを生んだR.V. Guhaが手がけた仕組みだ）が、この層に属する。冒頭で、Geminiが頼まれてもいないのに llms-full.txt を取りに行った件は、まるごとこの層の話だった。

第二に、扱える層（Execution）。エージェントが実際に「あなたと取引・連携できる」か。エージェント間の相互運用を担うMCP（Anthropic。2025年12月にLinux Foundation傘下のAgentic AI Foundationに寄贈された）やA2A（Google。2025年に立ち上がり、いまは同じくAgentic AI Foundationが両者の本拠地になっている）、そして取引を司る商取引プロトコル群——UCP（GoogleとShopifyが立ち上げ、2026年4月にAmazon・Meta・Microsoft・Salesforce・StripeもTech Councilに参加）、ACP（OpenAIとStripeが2025年9月に共同開発。後にMetaも共同策定パートナーとして加わった）、AP2、Visa TAP——が、この層を構成する。なお、ここに挙げたプロトコル群は2026年5月時点の代表例であり、標準化はなお流動的に進んでいる。

ここで決定的に重要なのは、読める層が、扱える層の前提条件になっていることだ。自分を理解できないエージェントに、自分と取引させることはできない。順番が逆にはならない。

ところが世間とベンダーの関心は、派手な上の層——決済、agentic commerce——に集中している。プロトコルの覇権争いは確かに見栄えがする（この「扱える層」を業種別に深掘りしたい読者は、拙稿「AIエージェントがあなたの会社と取引する日」の連載を参照してほしい）。だが、ほとんどの企業はその手前、下の「読める層」で落ちている。自社の知識がそもそもエージェントに読めていないのに、取引の話に飛ぼうとしている。逆に言えば、この「みんなが飛ばしている読める層」こそ、いま最も手をつける価値があり、しかも他社がまだ書けていない領域なのだ。

読める層の解剖：何が「機械可読」なのか

では、「機械可読」とは具体的に何を指すのか。曖昧なまま使われがちな言葉なので、分解しておく。ここがこの記事で最も実装的で、最も多くの企業がつまずいている部分だ。

構造・メタデータ・チャンク適性

第一に構造。見出しの階層が論理的に切られ、Markdownのような明快な書式で整理されていること。人間なら視覚的なレイアウトから「ここが重要そうだ」と直感できるが、エージェントは構造そのものからしか重要度を読み取れない。

第二にメタデータ。何の文書で、いつのもので、誰の発言で、どの製品の話なのか。文脈を与える情報が、本文と一緒に機械の読める形で添えられているか。

第三にチャンク適性。RAGでは文書を「チャンク」と呼ぶ単位に分割して検索する。意味のまとまりを無視してぶつ切りにすると、検索しても文脈が断たれた断片しか返らない。文書が、意味の塊として切り出しやすい構造になっているか。チャンク設計は、現場では開発者レベルの些事と見なされがちだが、実際には精度を左右する戦略的なレバーだ。

矛盾しない一次情報を、正本として置く

機械可読性には、もう一つ見落とされがちな条件がある。情報が、サイトの中で矛盾していないことだ。

人間なら、会社概要のページと製品ページとプレスリリースで設立年や事業の説明が微妙に食い違っていても、文脈から「まあ同じことだろう」と補って読む。だがエージェントは、その食い違いをそのまま矛盾として受け取る。どちらが正しいのか判断できず、確信度を下げ、一般論に逃げるか、最悪の場合は古い方を採用する。商取引プロトコルの設計者たちが「価格情報の各所での一貫性」をエージェントが取引できるかの条件に挙げているのは、まさにこのためだ。表記が揺れ、数字がページごとに違うサイトは、エージェントから見れば「信頼できない情報源」なのである。

だからこそ、社名・数値・主張について「ここを見れば正しい」という唯一の正本（single source of truth）を定め、他はそこを参照する形に整えることが効いてくる。llms-full.txt は、その正本をエージェントに対して一枚で差し出す器でもある。散らばって矛盾した知識を、一つの整合した像にまとめること——これが「読める層」を固めることの実質だ。

「読めない知識」は、RAGでもエージェントでも落ちる

そして、これらが効いてくる理由は、RAGの現実を見るとはっきりする。

2026年の現場での定説は、「RAGはもはやモデルの問題ではなく、検索エンジニアリングの問題だ」というものだ（FloTorch）。精度が出ない原因の多くは、最新の高性能モデルを使っていないからではなく、その手前の設計と、社内文書側の整備にある。データ統制ツールの Atlan は、統制されたナレッジ基盤の上では検索精度が85〜92%に達するのに対し、未統制のソースでは45〜60%にとどまると報告している。同じモデル、同じアルゴリズムでも、土台となる知識の整い方だけで、これだけ差がつく。

規模の問題も無視できない。Microsoftが2026年5月に整理したところでは、RAGは100〜1,000件規模の文書では高精度に働くのに、数十万〜数百万件へと膨らむと、多くの実装が崩れ始める。「モデルの問題に見えるものは、たいていアーキテクチャの問題だ」というわけだ。精度の劣化は静かに進むため、誤答が数週間後に発覚することすらある。

要するに、読めない知識は、RAGでもエージェントでも落ちる。llms.txt（サイトの要点を案内するナビ）と llms-full.txt（全文を渡す本体）を置くことは、自社の知識を「読める層」に引き上げる作業の、もっとも入口にあたる。私がポータルで「スムーズに動いた」のは、最初から自社の一次情報がMarkdownで構造化され、整然としていたからだ。これはほぼベストケースの環境であって、多くの企業の実環境は、雑然としたファイルサーバーやWord・PDFの山——まさに精度が落ちる側にある。

なお、「エージェントに読まれたときに何が起きるか」を、実際に日経225から抽出した5社を四つのAIに語らせて測った記録を、拙稿「AIは会社をどう知っているか」にまとめてある。「読める層」が崩れているとAIの説明がどう一般論に逃げるか、具体例として併せて読んでほしい。

核心：最適化の目的関数が反転する

ここまでの話は、実は一点に収斂する。B2Aが本質的に新しいのは、最適化のターゲットが「説得」から「検証可能性」へ反転することだ。これがこの記事で最も伝えたいことだ。

人間向けWebでの最適化対象は、一貫して「説得」だった。SEO、コピーライティング、印象的なヒーロー画像、行動を誘導する設計——どれも、人間の注意と感情とクリックを獲得するための技術体系だ。ところがエージェントは説得されない。魅力的なビジュアルにもキャッチコピーにも反応せず、構造をパースし、主張を検証する。だからエージェント向けWebで効くのは、「魅力的に見せる」ことではなく、「正確に理解され、機械的に検証されうる」ことだ。スキルスタックが、丸ごと裏返る。

この表の最終行が、私にとっての核心だ。これまで「正直であること」は、美学や倫理の側にあった。やろうと思えば、誇張も、印象操作も、できてしまった。ところがエージェント向けWebでは、誠実さが技術仕様になる。検証されて落ちない主張だけが、エージェントの経路に乗る。盛った言葉は、検証の段階で静かに弾かれる。

私はかねて、SEO的な最適化——検索エンジンを欺く小細工——を好まなかった。それは美意識の問題だと思っていた。だがB2Aの時代には、その美意識が、比喩ではなく文字通りの競争要件になる。高インテグリティで、機械可読で、検証に耐える情報を持つ者が、エージェント経済で経路に乗る。「誠実な未確定」——確かなことだけを確かだと言い、不確かなことは不確かだと正直に示す態度が、そのまま機械可読性の質に直結する。これは、私にとって少し痛快な逆転だった。

価値はどこに溜まるか

ここで、煽らずに正直な留保を置いておきたい。「では、この層で誰が儲かるのか」は、まだ決着していない。

ある分析は、インターネットの歴史を引きながら、こう指摘する。TCP/IPというプロトコルそのものはレント（超過利潤）を生まず、その上で実装を担ったAkamaiやCloudflareやAWSが価値を取った。同じ論理で、エージェント経済でも持続的な価値はオープンなプロトコルそのものより、決済を清算するレール側に溜まるのではないか——と。これは有力な見方だが、まだ争いのある仮説だ。

ただ、「読める層」に限れば、私の見立ては比較的はっきりしている。価値が溜まるのは、プロトコルでも決済でもなく、機械可読なナレッジ面を設計し、キュレーションし、正確に表現する判断そのものだ。プロトコルは標準化され、いずれコモディティ化する。だが「自社の知識の、何を、どう構造化し、どう正確に表現するか」という判断は、業種にも組織にも文脈にも依存し、容易には汎用化できない。ここにこそ、模倣されにくい堀（moat）が残る。

地殻変動の規模だけ添えておく。McKinseyは agentic commerce の機会を2030年までに3〜5兆ドルと見積もり、オープンWeb上のエージェント駆動トラフィックは直近で爆発的に伸びている。土台となる「読める層」を今のうちに固めておくことの時間的価値は、決して小さくない。

適用：なぜIRが最初の楔なのか

抽象論を、具体に落とす。「読める層」を最初に固めるべき領域はどこか。私は、IR（投資家向け広報）だと考えている。

理由は三つある。第一に、IR文書は数値の正確性が決定的に重要で、誤読が許されない。第二に、その主張は常に裏取りを求められ、検証可能性のステークが極めて高い。第三に、すでに機関投資家の側がエージェントを使って情報を収集・比較し始めている。つまりIRにとって、エージェントに正しく読まれることは「将来の話」ではなく、もう始まっている話なのだ。

IR担当者にとって、自社の有価証券報告書や決算説明資料、ファクトブックが「エージェントに正確に読めるか」は、そのまま「自社が機関投資家のエージェントに正しく理解されるか」を意味する。ここで読める層が崩れていれば、人手で磨いた開示も、エージェントの要約段階で歪む。逆に、ここを機械可読に整えておくことは、これからのIRの基礎体力になる。

もちろんIRに限らない。製造業の品質・技術ナレッジ、専門性の高いBtoBの製品情報——「人間には有名でも、エージェントには読めていない」知識を抱える領域は広い。だが最初の楔としては、精度要求も検証可能性のステークも最も高いIRが、筋がいい。

では、何をするか

最後に、実務の第一歩を示す。いきなり大掛かりな構築に走るのではなく、まず「自社は、そもそも読めるのか」を点検することから始めるべきだ。

第一フェーズは診断。問いは「自社の何が、エージェントに読めていないのか」。サイト、開示文書、社内ナレッジを対象に、現状の機械可読性を点検する。

第二フェーズはPoC。問いは「自社データで、検索精度は実際どれくらい出るのか」。ここで重要なのは、前述のRAGの教訓だ。あらゆる技術的失敗の共通の上流原因は、「発見（discovery）とPoCを分けずに、いきなり本番を作ろうとしたこと」にある。まず小さく実測し、自社データの素の精度を数値で掴む。これを飛ばすと、後で必ず手戻りする。

第三フェーズが構造化。実測で見えた弱点を踏まえ、知識を機械可読な土台へと作り替えていく。llms.txt / llms-full.txt の整備も、構造化データの設計も、ここに含まれる。一度きりの作業ではなく、継続的に維持される基盤として作る。

弊社が提供している「AIエージェント互換性診断Pro」は、まさにこの第一フェーズ——自社が「読めるか」を測ること——を入口に置いている。RAGの実装やナレッジの構造化は、その診断の自然な帰結として続く。順番を守ること。それが、精度が出ない45〜60%の側に落ちないための、いちばん地味で確実な道だ。

結び：両端を、同時に誠実にする

我々はいま、二人の読者に向けて書いている。一人は人間で、もう一人はエージェントだ。

人間向けの最適化は「説得」を、エージェント向けの最適化は「検証可能性」を要求する。一見、相反するように見える。だが突き詰めると、両者が求めているものは案外近い。誇張のない、構造の明快な、検証に耐える情報——それは、人間にとっても結局のところ、信頼できる良い情報なのだ。

llms.txtはSEOには効かない。だが、それを置くという小さな作法は、「自分の知識を、機械が読める形に整える」という、もっと大きな構えの入口にある。そしてその構えは、人間向けと機械向け、Webの両端を同時に誠実にしようとする態度に他ならない。次のWebに乗るのは、この両端を同時に誠実にできる者だ——私はそう考えている。

株式会社アンタイプは、企業のAIエージェント互換性を測定する診断サービス「AIエージェント互換性診断Pro」を提供しています。自社サイトや社内ナレッジが「エージェントに読めるか」の点検、RAG導入のためのPoCと知識の構造化までを承ります。