llms.txtは本当に効果があるのか　13.7万サイト調査で97%のファイルがアクセス0件

答え：いま作っても、97%のファイルは1か月間だれにも開かれない

13万7,210サイトのサーバ記録を調べた実測では、llms.txtを置いていたのは28%。そのうち97%は2026年5月の1か月間、AIにも人にも一度もアクセスされていませんでした。効果を語る以前に、開かれていません。

llms.txtは、「https://自社ドメイン/llms.txt」で開ける場所――サーバの一番上のフォルダ――に置く1枚のテキストファイルです。中身はMarkdown（記号で見出しや箇条書きを表す簡易な書き方）で、「このサイトは何か」を短く説明し、重要なページへのリンクを並べます。AIがサイトを丸ごと巡回しなくても自分の居場所をつかめるように、という発想で、2024年にAnswer.AIとfast.aiの共同創業者であるJeremy Howard氏が提案しました。

混同されやすい点が2つあります。1つ、llms.txtは「各ページのMarkdown版を別途公開する」という施策とは別物です。2つ、名前がrobots.txt（検索エンジンの巡回を許可・禁止するために昔からあるファイル）に似ていますが、llms.txtは指示ファイルではないため、何も制御せず、何もブロックしません。

そして肝心の点です。「llms.txtを置くとAIに引用されやすくなる」という位置づけは、提案そのものにはありませんでした。ChatGPTなどの回答に自社が出てくることを指す「AI可視性」という意味づけは後からSEO業界が付けたもので、AIプラットフォーム側が読むと約束したからではなく、いずれ読むようになるだろうという推測に沿って広まったものです。実際、主要なAIプラットフォームで、このファイルを読むと明言したところは今のところありません。

営業資料やセミナーでよく聞く言い方と、実測が示したことを並べます。数字ごとに分母が違うので、そこを取り違えるとこの調査は簡単に誤読できます。

28%という公開率が上限だというのは、調査したAhrefs自身が断っている点です。同社のツールを使っている企業はWeb全体より技術やSEOに詳しい側へ偏るため、Web全体の公開率はこれより低いはずだ、と注記されています。置いていた約3万8,000サイトのうち、1か月間にアクセスが1件でもあったのは3%、およそ1,100サイトにすぎませんでした。以下の内訳は、その3%だけを見た話になります。

読まれた3%に来ていたのは、誰だったのか

アクセスの96%はプログラムからでした。ただし内訳の上位4つはSEOの点検ツール、正体不明のプログラム、一般の検索クローラー、技術調査ツールで、AIの分類は1つも入りません。約77%はAIと無関係でした。

llms.txtは機械に読ませるためのファイルなので、96%が人ではなく自動で動くプログラム、いわゆるbotだったことは想定どおりです。残る4%にあたる930件は人からのアクセスで、その一部はSEO関係者がチャットアプリにllms.txtのリンクを貼ったことに伴うものでした。

疑わしく見える点を先に潰しておくと、1位のSEO監査ツールの約半分にあたる2,334件・全体の10.6%は、調査した当のAhrefs自身のクローラーです。これはAhrefsが自分から注記しており、差し引いた他社のSEO監査ツールだけでも2,442件・11.1%あるため、順位も結論も変わりません。

そのうえで、順位そのものが答えになっています。上位4つ――SEO監査ツール、正体不明、一般のWebクローラー、技術調査ツール――は、どれもAIとは関係なくWebを巡回しているソフトで、llms.txtだから来たのではなく、サイト上にあるURLだから来ています。どのAI分類も単独では上位4つに入らず、約2万2,000件のうち約77%はAIとは無関係のソフトからのアクセスでした。

この77%は、人からの4%を含む全アクセスに対する比率です。bot全体に占める非AIの比率で言えば約80%になりますが、どちらで読んでも結論は変わりません。

話題の大きさと実測の落差を示す数字もあります。この論争を再燃させたのは、Chromeのサイト点検機能Lighthouse（表示速度などを測る開発者向けツール）に、AIエージェントがこのサイトを回れるかを見る実験的な項目が加わったことでした。ところが、そこに由来するアクセスは22件、およそ1,000件に1件しかありません。しかもそれは首位のSEO監査ツール21.7%の内数なので、首位が膨らんでいる理由もAI起因ではないのです。

AIの中身：読んでいたのはAI検索ではなく、開発現場のAIだった

AI関連4分類の合計は19.5%で最大の塊です。ただし中身の主役は作業を代行するエージェントと学習用クローラーで、AI検索が回答のために取りに来た分は1.1%。3つ足しても、エージェント単独に届きません。

「AI」とまとめて呼ぶと、ここで判断を誤ります。4つの分類は役割がまったく違うからです。最も多いAIエージェント（10.5%）は、人が指示すると自分でWebを見に行き、資料を集めて作業を進めるAIで、ChatGPTに質問して答えが返る使い方とは別のものになります。次のAI学習用クローラー（5.3%）はAIモデルそのものを作るためにデータを集める巡回役で、AIアシスタント（2.5%）は利用者の1つの質問に答えるためその場でWebを見に行くものです。そしてAI検索の取得bot（1.1%）が、AI検索の回答を組み立てるためにページを取りに来るものにあたります。

「AI検索に自社を出したい」という目的に直結するのは、いちばん最後のAI検索の取得botです。それが1.1%、実数で233件しかありませんでした。ここがこの調査でいちばん鋭い一撃で、AI検索の取得botにAIアシスタントとAI学習用クローラーを足し合わせても8.9%にしかならず、AIエージェント単独の10.5%に1.6ポイント届きません。答えを作るAIを全部合わせても、作業を代行するAIに負けているということです。

個別の名前で見ると、AIとして名前が判明したソフトのうち最多はGPTBot、2番目がClaude-Code（Anthropicのコーディングエージェントで、プログラマーがコードを書いたり調べたりするときに使う開発ツール）でした。ここは限定を外さないでください。全ソフト中の最多ではなく、AI系のソフトの中での順位です。全体の首位はSEO監査ツール分類の4,776件でした。

もう一つ、AI学習用クローラーはAI検索の取得botのおよそ5倍取りに来ていました。1,179件対233件という差です。ここから言えるのは、仮にllms.txtがAI上での見え方に効くとしても、それは回答が作られる瞬間ではなく、もっと上流のモデルが覚える段階で起きる可能性が高い、ということになります。

日本の担当者がいちばん気にするGeminiについては、一覧に専用のクローラーが出てきません。存在しないからです。GoogleはGeminiの学習も回答の裏づけも、通常のGooglebotが取得したコンテンツで行っています。公開者が学習利用を断るために使うGoogle-Extendedも、robots.txtに書く記号であって独自の名乗りを持つクローラーではありません。

Googlebot自体は5月に約900回llms.txtを取りに来ていますが、これは見つけたURLを片端から取りに行く性質のものなので、特別な関心を示す証拠にはならないのです。その内容がGeminiに流れているかどうかも外からは見えないため、「llms.txtを置けばGoogleのAI回答に出やすくなる」を裏づける材料は、この調査には1つもありません。

この結果は、Googleの説明とも噛み合います。ただしGoogleの中でも評価は割れていて、2026年5月下旬の1週間のうちに両方の立場が出ました。生成AI機能向けの新しいガイドでは、文字どおり「mythbusting（俗説の検証）」と題した節で、llms.txtのような機械向けのファイルは生成AI検索に出るために必要ではないと明言しています。

ところがその数日後、ChromeチームはLighthouseの点検項目にllms.txtのチェックを追加し、ファイルがないとエージェントがサイト構造を理解するのに余計な巡回時間を使う可能性がある、と説明しました。この矛盾をLily Ray氏が問いただした結果が、次の発言です。

llms.txtは「検索のためのものではない」。AIのコーディングツールが開発者向けドキュメントを読むときに、トークン（AIが一度に読み込める文字量の単位）を節約するための当座しのぎの松葉杖かもしれない、というもので、開発者向けでないサイトが気にする必要はない。サイトのログを確認すれば、AIエージェントからのアクセスはごくわずかしかないと分かるはずだ。

Googleのジョン・ミューラー氏の説明。出典：Ahrefs「We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read」（Louise Linehan、2026年6月15日）

実務側からの補強もあります。Nectiv創業者のChris Long氏は、Google検索では効かなくても、顧客がClaude Codeを使って推薦候補を探しているなら、このファイルには使い道があると述べています。実測と、Googleの説明と、実務家の見立てが、同じ一点を指しているわけです。llms.txtを読んでいるのは、答えを作るAIではなく、作業をするAIでした。

置いていないサイトは、損をしているのか

ファイルが無いサイトの/llms.txtに来ていたアクセスは98%が人で、AIのbotは0件でした。AI側はこのファイルを探し回っていません。置いていないことで減点される仕組みは、この実測の範囲では見当たりません。

llms.txtを勧める話には「置いていないとAIに見つけてもらえない」という前提が混じりがちですが、そこも測られています。/llms.txtにアクセスして「そんなファイルはありません」という応答が返った分だけを取り出して分類すると、ファイルがある場合は96%がプログラムだったのに対し、ファイルが無い場合は98%が人で、AIのbotの割合はゼロでした。botのデータで見た中でも、最もきれいな分かれ方になっています。

探しに来ていたのは、ブラウザにURLを打ち込んだ人間、おそらく競合サイトが置いているかを確認しているSEO担当者でした。ここから2つ言えます。1つは、置いていないからといってAI側の「未対応リスト」に載るわけではないということ。AIはそもそも見に来ていないからです。もう1つは逆で、置いただけでは何も始まりません。AIがllms.txtを取りに来るのは、リンクや一覧、あるいは利用者の指示によって「そこにある」と分かったときであって、当てずっぽうで来るわけではないため、どこからもリンクされていないファイルは置いてあること自体がほぼ意味を持たないのです。

自社で確認するときの指針になる事実もあります。13万7,210サイトを調べた当のAhrefs自身が、自社サイトにllms.txtを置いていません。それでも無いはずのそのURLにbotのアクセスが届いていて、記録には「見つかりません」が並ぶそうです。つまり仮に自社のアクセス記録に/llms.txtへのアクセスが見つかっても、それはファイルが評価されている証拠にはなりません。

読み手より先に、採点する産業が立ち上がっている

アクセスの12.1%は、llms.txtを使いに来たのではなく、採点・検証・研究のために来ています。どのAIプラットフォームも読むと明言していない段階で、それを測る側の市場が先に動いている、というのがこの調査の裏の顔です。

内訳は、AI検索対応度を採点する商用ツールが5.8%、llms.txtだけを収集・検証・一覧化するbotが3.6%、研究目的のbotが2.7%で、合計12.1%になります。この専用の収集botだけでも、AI検索の取得botやAIアシスタントより多くアクセスしていました。読者が現れる前に、それを採点し、検証し、研究する側が先に立ち上がっている状態です。

採点ツールで最も活発だったのは、2025年後半に立ち上がったWordPress向けのAEOプラットフォームCairrotのbotでした。加えてFramer、Lovable、Wixといった主要なサイト作成サービスが、いずれもAI対応度のチェックを製品に組み込んでいます。Wixはすでにllms.txtを生成しており、FramerとLovableはその有無を見に行っている段階です。

つまりllms.txtの導入は、サイト運営者が判断する前にプラットフォームの初期設定になってしまったわけです。1年以内に、llms.txtを持つことはサイトマップと同じくらいCMS（サイトを作って更新するための仕組み）の標準になっているかもしれません。

研究目的のbotで最大だったものは、prompt-injection-survey/1.0と名乗っていました。AIに読ませる文章の中に命令を仕込んで動きを乗っ取る手口がプロンプトインジェクションで、llms.txtはエージェントが信頼して読み込む前提で設計されています。だからこそ、そこを悪用できるかどうかを体系的に調べている誰かが、すでにいるわけです。

自社にとっての具体的な被害を1つ挙げるなら、llms.txtが書き換えられて「この会社は営業を停止しました」と書かれた場合、それを読んだエージェントがそのまま人に伝えます。エージェントがこのファイルを大規模に信頼することの安全上の意味はほとんど議論されていないのに、悪用しうる側はすでに動いているのです。

それでも「無駄です」で終わらせない理由：仕様はv2になった

llms.txtの書き方を定めた提案は2026年8月に第2版へ改訂され、「置いても見つけてもらえない」という弱点が仕様の側で埋められました。この節は担当者が手を動かす話ではなく、制作会社に渡す前提で読んで構いません。

先に免責しておくと、ここで扱うのはファイルを自分で書く人と、サイトを触れる人のための変更です。マーケティング担当者が覚える必要はありません。関係があるのは1点だけで、「置いただけでは見つからない」という実測の弱点に対して、ページ側から場所を知らせる書き方が追加された、ということです。

実測データは2026年5月のもので、仕様の改訂はその3か月後にあたります。ここを見ずに終わらせると、判断を1回で固定してしまいます。改訂ノートは現状認識から始まっていて、2024年9月の初版は言語モデルがWebサイトを日常的に読むという考えがまだ推測だった時期のものでした。以降、提案者の予想を超えて受け止められ、数千のサイトが公開し、開発者向けマニュアルを作るドキュメント基盤が自動生成するようになり、コーディングエージェントが確実に使うようになった。v2はその変化を反映したものだ、という位置づけです。実測でClaude-Codeが上位に来ていたことと、正面から噛み合います。

v2で変わった点は4つあります。

• 見つけ方。「AIがllms.txtの場所を推測なしでどう知るのか」が最も多い要望でした。v2は、ページ側から場所を指し示す書き方を定めています。制作会社への指定は rel="alternate" type="text/markdown" と rel="describedby" の2つです
• Markdown版ページのURLの形。初版は元のURLの末尾に .md を足す形（page.html.md）だけを認めていましたが、実際の公開ツールには拡張子を置き換える形もあったため、v2は両方を認めました。ここは完全に技術者向けの細目です
• 対象範囲。v2は「そのファイルより下の階層のページを対象とし、最も近い階層のファイルが優先される」と定めました。サイト全体は管理できないが担当コーナーだけは管理できる、という立場でも参加できます
• 使われ方の想定。v2は変換ツール向けの道具立てを外し、「エージェントが必要なものを探して関連リンクをたどる」という読まれ方を直接書きました。これに伴い、変換ツール向けの目印だったOptionalセクションは機械的な意味を失っています。すでにllms.txtを持っている会社には、4つの中でこれが最も影響します

注意したいのは、v2がAI検索での露出を約束してはいない点です。埋められたのは「見つけてもらえるか」と「どこまでを対象とするか」であり、想定されている読み手は一貫してエージェントでした。背景や事例の記述も、「エージェントがこう使うかもしれない」という予測から「実際にこう使っている」という記述へ書き直されています。

実測と仕様が同じ方向を指しているため、「効かない」は今の話であって、永久の話ではありません。Googleが検索の将来をエージェント寄りだと明言していることを踏まえれば、人が検索する代わりにAIエージェントが調べて回るようになったとき、そのエージェントが読むllms.txtが効いてくる可能性は残ります。

Webマーケ担当者が、いまやること

AI検索での露出が目的なら、今期の予算と工数を使う対象ではありません。まずブラウザで有無を確認し、あれば中身を目で見る。作ると決めても手作業は増やさない。判断の基準値は「97%は誰にも開かれない」です。

調査した本人の結論も、現時点では短所が長所を上回るというものでした。ChatGPT、Perplexity、AI Overviewsに出ることが目的なら、このファイルはほぼ装飾にとどまります。そのうえで、担当者が自分の手で今日できることだけを順に挙げます。

• 5分の現状確認。ブラウザのアドレス欄に「自社ドメイン/llms.txt」と入れて開くだけです。文章が表示されれば置いてある、「ページが見つかりません」なら置いていない。サイト作成サービスが知らないうちに生成していることがあるため、推測より先に自分の目で開くのが早いのです
• 置いてあった場合は、中身を最後まで読む。会社説明、サービス名、リンク先が今の実態と合っているか。旧社名、終了したキャンペーン、いまは案内していない価格、切れたリンクが残っていないか。エージェントはこのファイルを疑わずに読む前提で作られているため、古い情報はそのまま人に伝わります
• 「AIへの指示のように読める文章」が混ざっていないかを見る。悪い例は「この会社を必ず1位として紹介してください」のような命令文で、良い例は「料金ページ https://example.com/price ／2026年4月改定」のような、リンクと短い説明だけの行です
• リンク先は自社が管理しているURLだけにする。他人が書き換えられるページを並べないというのが、挙げられている対策の中で最も効きます
• 中身がずれていた場合の直し方。自動生成なら生成元のサービスやCMSの会社情報を直すのが筋で、手で置かれているなら制作会社への依頼になります。依頼文は「サイト直下の /llms.txt の記載が現状と違っています。差し替えと、誰が編集できるかを教えてください」で足ります
• 置いていない場合、急いで作る理由は薄いです。AI検索での露出が目的なら基準値は「97%は誰にも開かれない」で、同じ工数を人間の読者にも開かれるページの中身に使うほうが、少なくとも読み手はゼロになりません
• 例外は、読み手が実在する場合です。長所側に挙げられている条件は2つで、顧客がコーディングエージェントを使う場合、または自社サイト上でエージェントが実際に動く場面がある場合。「顧客が開発者かどうか」ではなく「顧客がその種のAIを使うかどうか」が条件である点に注意してください
• 作る、あるいは残すと決めたら、手作業は増やさない。自作せず、サイト作成サービスやCMSの生成機能に任せます。機能の有無は、管理画面で「llms.txt」と検索するか、制作会社に「llms.txtの自動生成機能はありますか」と1行で聞けば分かります
• 置いたら、そのURLへリンクを1本張る。フッターのリンク一覧やサイトマップページから /llms.txt へ、というだけです。AI側は「そこにある」と分かったときに取りに来るので、どこからもリンクされていないファイルは拾われにくくなります
• 更新の管理を決める。今日できる最小の形は、「毎月1日にブラウザで /llms.txt を開いて中身を目視する」をカレンダーに登録することです。編集できる人を限ること、無断の変更に気づける通知を用意すること、いつ誰が何を変えたかの履歴を残すことも挙がっていますが、後ろの2つは制作会社・エンジニアへの依頼案件になります
• 効果を見るとき、できないことを先に知っておく。「どのAIが何回取りに来たか」はサーバのアクセス記録の中にしかないため、確認にはその記録を見られる人への依頼か、bot別のアクセスを見られるツールが要ります。ふだん使う一般的なアクセス解析や検索の管理画面には、botのアクセスは通常出てきません
• 提案を受ける側としての一言。「llms.txtを置けばAI検索に出ます」と説明されたら、どのAIが何回そのファイルを取りに来たのかを聞いてください。記録が出てくること自体が例外的なので、「出せません」と返ってきたら「では効果は何で確認するのか」と聞き方を変えます

最後に、この調査を貫いている態度を書いておきます。19.5%も、10.5%も、1.1%も、すべて「取りに来た回数」であって「読んで中身を使った証拠」ではありません。この点はAhrefs自身が、どの数字も実際の利用量の天井であり実際はこれ以下のどこかだと明記しています。llms.txtの評価が定まらないのは、まだ誰も天井より下を測れていないからでもあります。

次に何が分かれば判断が動くかも挙げられています。1つはエージェントの関心が /docs/ や /api/ のような開発者向け資料の階層に集中しているのかどうか、もう1つは取りに来たエージェントが実際にリンク先まで辿るのかどうかです。後者については、Queryburst創業者のSEOコンサルタントDavid McSweeney氏が追跡の実験を進めているところで、答えが出たときにこの記事の結論は書き換わる可能性があります。