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 | エージェント向けWeb | |
|---|---|---|---|
| 最適化の目的 | 説得・注意の獲得 | 正確な理解・検証可能性 | |
| 主な手法 | コピー、ヒーロー画像、SEO、演出 | 構造化、メタデータ、機械可読ナレッジ | |
| 評価する主体 | 人間の感情・直感 | エージェントのパースと検証 | |
| 勝ち筋 | 魅力的に「見せる」 | 正確で、検証して「落ちない」 | |
| 誠実さの位置づけ | 美学・倫理（任意） | 技術仕様（必須） |
この表の最終行が、私にとっての核心だ。これまで「正直であること」は、美学や倫理の側にあった。やろうと思えば、誇張も、印象操作も、できてしまった。ところがエージェント向け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と知識の構造化までを承ります。
参考情報
Google検索セントラル「Optimizing your website for generative AI features（AI機能向けの最適化ガイド）」（2026年5月15日公開。llms.txtを「不要」と明記）
Chrome for Developers「llms.txt | Lighthouse」（Lighthouse 13.3の Agentic Browsing 監査。検索ガイドより8日早い、5月7日リリース）
Search Engine Journal「Google's llms.txt Guidance Depends On Which Product You Ask」（2026年5月。検索とLighthouseで方針が分かれる件）
Search Engine Journal「LLMs.txt Does Not Boost AI Citations, New Analysis Finds」（SE Rankingによる30万ドメイン調査、設置率10.13%）
Search Engine Journal「Google Says LLMs.txt Comparable To Keywords Meta Tag」（John Muellerの発言）
Search Engine Land「Google says normal SEO works for ranking in AI Overviews and llms.txt won't be used」（Gary Illyesの2025年7月の発言）
Limy「llms.txt in 2026: The Full Guide」（5億5,000万超のボットイベントの観測、B2Aの提唱）
OpenAI「Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol」（ACPをStripeと共同開発したとの発表、決済はマーチャント側に残す方針）
Stripe「Developing an open standard for agentic commerce」（ACPの共同開発、Instant Checkout、2025年9月）
ACP公式仕様サイト：Agentic Commerce Protocol
Shopify「Universal Commerce Protocol」（UCPをGoogleと共同開発）
Gigazine「AIとアプリをつなげる技術「MCP」の開発プロジェクトがLinux Foundationに寄贈」（MCPのAAIF移管）
Visa「Visa and Partners Complete Secure AI Transactions」（Trusted Agent Protocolの発表）
CodeZine「「NLWeb」をOSSで発表、自然言語でWeb検索・Q&Aを実装可能に」（NLWebとR.V. Guha）
FloTorch「The 2026 RAG Performance Landscape」（RAGはモデルではなく検索エンジニアリングの問題）
Atlan「RAG Accuracy Problems」（統制済み85〜92%、未統制45〜60%）
Microsoft Tech Community「When RAG Hits the Wall」（2026年5月。規模とアーキテクチャの問題）
McKinsey「The agentic commerce opportunity」（2030年までに3〜5兆ドルの試算）
「AIエージェントがあなたの会社と取引する日」（A2Aプロトコルを論じた連載。「扱える層」を深掘りしたい読者へ）
「AIは会社をどう知っているか」（日経225から抽出した5社をAIに語らせた実測。「読める層」の検証例として）
この記事をシェアする
