前回、三番目の読者としてAIエージェントが現れた話をした。そして関与には深さの階段があるとも書いた。見る、問い合わせる、操作する、取引する。今回はその一段目、「見る」に降りていく。
一段目は地味だ。操作も取引もしない。エージェントがページの意味を、推測ではなく構造として読み取れるようにする。それだけの層だ。だが土台がぐらつけば、その上のすべてがぐらつく。意味を取り違えたまま操作させれば、間違ったものを、正確に実行される。だから最初に、ここを固める。
意味には、二つの粒度がある
人間は、ページを開いた瞬間に多くを判断する。この数字は価格だ、これは会社名だ、この赤いボタンが申し込みだ。レイアウトと文脈から、書かれていないことまで補って読む。
機械はそれをしない。正確には、しなくてよいように作られていない。書いていなければ推測に頼り、推測は外れる。「1,200」という数字が価格なのか在庫数なのか型番なのか、見た目の大きさや位置から人間は察するが、エージェントにとってそれは曖昧なテキストの断片でしかない。
だから「意味を伝える」という仕事が要る。そしてこの仕事には、二つの粒度がある。
一つは、個々の意味。「これは商品だ」「価格は税込1,200円だ」「これは営業時間だ」。ページの中の一つひとつの要素に、機械が読める札を付ける。これがSchema.orgと構造化データの世界だ。
もう一つは、全体像。「このサイトは何のサイトで、どこに何があるか」。個々の意味ではなく、サイトという単位の見取り図。これがllms.txtの領域だ。
一本の木に名札を付けるのがSchema.org、森全体の地図を入口に置くのがllms.txt。二つは競合しない。粒度が違うだけで、どちらも「機械に推測させない」ための自己記述だ。
Schema.org ― 個々の意味を、推測させない
Schema.orgは、GoogleとMicrosoft、Yahooが2011年に立ち上げ、まもなくYandexも加わった共通語彙だ。「これは商品」「これは記事」「これは組織」といった型（type）と、その属性（property）を、あらかじめ決められた名前で記述する。書き方はいくつかあるが、いま主流はJSON-LDで、ページの中にスクリプトとして意味の定義を埋め込む。
現在の最新版はV30.0（2026年3月19日公開）で、823の型と1,529のプロパティを持つ。商品（Product）、記事（Article）、組織（Organization）、地域ビジネス（LocalBusiness）、パンくず（BreadcrumbList）、イベント（Event）といった型を使い、価格・在庫・営業時間・所在地を構造として書く。schema.org自身の集計では、2024年時点で4,500万を超えるドメインがこの語彙でマークアップし、埋め込まれたオブジェクトは4,500億を超える。成熟した層だ。
「マークアップ＝検索のごほうび」という等式が痩せた
ここで、実務家が握っている前提を一つ更新しておく必要がある。長らくSchema.orgは、SEOの文脈で語られてきた。マークアップすればリッチリザルト（検索結果の見た目の拡張）がもらえる、という等式だ。その等式が、いま痩せている。
Googleはこの数年、リッチリザルトの対象を広げるのではなく、絞ってきた。HowTo（ハウツー）のリッチリザルトは2023年9月に消えた。そしてFAQ（よくある質問）のリッチリザルトも、2026年5月7日をもって検索結果に表示されなくなった。マークアップ自体は今も妥当なまま、検索結果での見返りだけが消えたことになる。Googleの言い方はこうだ。使われていない構造化データは、検索に問題を起こしはしないが、検索上の可視的な効果もない。
「書けばごほうびがもらえる」目当てだった投資は、この変化で足元が崩れる。だが、ここで話は終わらない。
SEOのごほうびが痩せても、機械可読性の価値は太る
同じJSON-LDが、二つの異なる価値を持っている。一つはSEOのリッチリザルトという報酬。これは痩せた。もう一つは、機械が意味を曖昧さなく読み取れるという価値。こちらは、三番目の読者が現れたことで、むしろ太っている。
エージェントがページを扱うとき、構造化データは推測を減らす。価格が税込か税抜か、在庫があるかないか、この操作は予約か購入か。人間なら文脈で補う判断を、機械には構造として渡す必要がある。そして次回扱うNLWebは、まさにこのSchema.orgのデータをベクトルに変換して、サイトを「問い合わせられる窓口」にする。意味の層は、会話の層の材料になる。
つまりSchema.orgへの投資判断は、「検索のごほうび目当て」から「機械可読な意味の土台」へと軸足を移す。リッチリザルトが出るかどうかで一喜一憂する対象ではなく、三番目の読者に意味を渡すための基礎工事として捉え直す。この捉え直しができているかどうかが、これからの数年で効いてくる。
（Eコマースの商品情報のように、いまも検索・ショッピング面で直接効くマークアップは残っている。すべてが無意味になったのではなく、「リッチリザルト目当て」という単一の動機が痩せた、という話だ。）
どこに、何を置くか
設置場所は各ページの<head>だ。<body>内でも動くが、<head>に置くのが読みやすい。<script type="application/ld+json">でJSON-LDを囲み、そのページが表す意味を書く。まず全ページに効くのが、会社を名乗るOrganizationだ。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "株式会社アンタイプ",
"url": "https://www.untype.jp/",
"logo": "https://www.untype.jp/assets/logo.png"
}
</script>次に、よくある質問のページならFAQPage。さきほど「ごほうびが痩せた」と書いた、あのFAQだ。リッチリザルトはもう出ない。だがmarkupは今も妥当で、三番目の読者はここを読む。目的が変わっただけで、書くこと自体は変わらない。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "対応エリアはどこですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "全国に対応しています。打ち合わせはオンラインでも可能です。"
}
}]
}
</script>商品ページならProduct（価格・在庫・型番）、記事ならArticle、実店舗ならLocalBusiness（営業時間・所在地）。型はページの中身に合わせる。迷ったら、Organizationを全ページに置き、あとはそのページで人間に見せている主要な情報を、同じ型で機械にも渡す。それだけで土台になる。
取り違えで多いのは、表示とJSON-LDのズレだ。画面の価格は改定したのに、JSON-LDは旧価格のまま。この食い違いは人間の目には見えず、エージェントの目にははっきり見える。書いた瞬間から、実態と一致させ続ける保守がついてくる。
llms.txt ― サイトの地図。ただし「誰のための地図か」を間違えない
個々の名札の次は、森の地図だ。llms.txtは、サイトのルート（/llms.txt）に置く、Markdown形式の要約ファイルである。このサイトは何で、重要なページはどこにあるか。それを、機械が読みやすい平文で、一枚にまとめる。
生まれは新しい。fast.aiの共同創業者でAI研究者のJeremy Howardが2024年9月3日に提案した。動機はSEOではなく、技術的な困りごとだった。LLMのコンテキスト窓は小さく、ナビゲーションや広告やJavaScriptで膨れたHTMLをそのまま渡すと、肝心の中身が溢れてしまう。ならばサイト側が、要点だけを平文で差し出せばいい。2024年11月にドキュメントホスティングのMintlifyが全ホストサイトで対応し、そこから普及が始まった。
ただし、これはW3CやIETFが承認した標準ではない。強制力も、統一された仕様もない、コミュニティ発の慣習だ。ここを誇張しないことが、この層でいちばん大事になる。
二つのGoogleチームが、逆を向いている
llms.txtをめぐって、Googleは2026年5月、一週間ほどの間に正反対に見える二つのことを言った。この矛盾に見える構図が、この層の本質を一番よく照らす。
一方で、Google検索は「効かない」と明言した。2026年5月15日に生成AI向けの最適化ガイドを公開し、6月15日には「llms.txtに関するガイダンスの明確化」という項目をわざわざ足して、こう書いた。検索（生成AI機能を含む）に表示されるために特別な機械可読ファイルは必要ない、検索はそれらを使わないからだ、と。維持するのは自由だが、Google検索の可視性やランキングを上げも下げもしない、無視するから、と。Search Relationsの担当者は、これをかつて廃れたkeywordsメタタグ――自己申告のシグナルだから信用されなくなった仕組み――になぞらえている（Search Engine Journalによる報道）。AI Overviewsも、AI Modeも、これを参照しない。SEO目的なら、llms.txtは無意味だ。
他方で、同じ月の初め、Chromeは「読む」側の仕組みにこれを組み込んだ。Lighthouse 13.3（2026年5月7日リリース）が、Agentic Browsing（エージェント的ブラウジング）という監査カテゴリを既定化し、その中でllms.txtの有無をチェックするようになった。Chromeの説明では、llms.txtは「LLMとAIエージェント向けの、機械可読なサイト要約」であり、これが無いとエージェントはサイトの全体構造を把握するために余計にクロールすることになる、という位置づけだ。
矛盾ではない。二つのチームは、違う問いに答えている。検索チームが答えているのは「検索順位に効くか」。答えはノー。ブラウザ側が答えているのは「エージェントが読みやすいか」。答えはイエス。前回書いた「対応しているか」という問いは、ここで一段深くなる。対応しているか、は、誰に対して、で答えが変わる。同じ一枚のファイルが、検索エンジンには透明で、エージェントには意味を持つ。
効く場所は、はっきりしている
llms.txtが実際に読まれているのは、検索エンジンではなく、開発とエージェントの現場だ。コーディングエージェント――Cursor、Claude Code、GitHub Copilot、Windsurf、Aiderといった道具――は、ドキュメントサイトに向かうとき/llms.txtを探しに行く。どのライブラリのどのページを読めばいいかの、routingの入口として使う。LangChainはllms.txtを読ませるためのMCPサーバー（mcpdoc）まで用意している。Anthropicは自社のエージェント向け執筆ガイドでllms.txtを推奨し、OpenAIもAgents SDKやAgentic Commerce Protocolの文脈で使っている。
裏を返せば、採用はまだ広くない。設置率は調査によって幅があるが、2026年半ばで上位1万サイトの5%台――1年で約5倍に伸びたとはいえ、robots.txtやサイトマップのような普遍的な標準にはほど遠い。しかも、置かれたファイルの多くは読まれていない。13万7千ドメインを対象にしたサーバーログ調査では、有効なllms.txtの約97%が調査期間に一度もリクエストされず、わずかに読まれたぶんも、実際の読み手はコーディングエージェントや学習クローラで、検索・回答系のAIボットではなかったと報告されている。「みんなが読んでいる」段階ではない。「読む道具が、特定の場所で、確実に増えている」段階だ。
だから実務判断はこうなる。開発者向けドキュメント、API、SaaSのように、コーディングエージェントやRAGパイプラインが読み手として現実的なサイトでは、設置する価値がある。コストは小さく、B2A（Business-to-Agent）の入口を先に押さえられる。一方、数万ページ規模のサイトでは、地図を実態と一致させ続ける保守が本物のコストになる。エージェント流入が事業の優先事項でないなら、無理に置く必要はない。そして最悪なのは、実態とずれた地図を置いて放置することだ。案内板が古ければ、無いより人を惑わせる。
置き方は、数行で足りる
置き場所はドメインの直下、https://（あなたのドメイン）/llms.txt。中身はMarkdownで、形式はllmstxt.orgの仕様が定めている。H1でサイト名、引用（>）で一文の要約、そのあとにH2でセクションを切り、重要なページへのリンクを並べる。必須はH1だけで、あとは任意だ。
# 株式会社アンタイプ
> 東京・南青山のコミュニケーションデザイン会社。Web制作と、AIエージェント対応の診断・設計を行う。
## 主要なページ
- [サービス](https://www.untype.jp/service): 提供内容の一覧
- [ブログ](https://www.untype.jp/blog): エージェンティックWeb実装に関する記事
## Optional
- [会社概要](https://www.untype.jp/about): 沿革・所在地## Optionalに置いたものは、読み手が文脈に余裕がないとき省いてよい、という合図になる。数万ページを書き写すファイルではない。「これは何のサイトで、要点はどこか」を一枚に畳む、それだけの道具だ。
llms.txtと混同されやすいもの
市場の「AI対応チェックリスト」は、AGENTS.mdをllms.txtと並べて載せがちだ。だが別物だ。AGENTS.mdはコードリポジトリのルートに置く、コーディングエージェント向けの取扱説明で、公開サイトを訪れて動くエージェントは読みに行かない。コーポレートサイトに置いても、誰も読まない。開発者向けドキュメントやSDKといった開発資産を持つ企業なら、リポジトリの側で効く。名前は似ているが、面が違う、とだけ押さえておけばいい。
二つの記述を、一枚で
二つに共通するのは、どちらも「自己申告」だという点だ。サイトが、自分について機械に語る。そして自己申告である以上、実態とずれる余地が常にある。ここが、この層のCheckが照らす場所になる。
この層で確かめること（観点だけ）
前回書いたとおり、この連載は各層を二段で書く。何を入れるか（Do）と、それが意図どおり入っているかを確かめる観点（Check）だ。意味の層でのDoは、ここまでに書いた。Schema.orgで個々の意味を、llms.txtでサイトの地図を、機械に読める形で差し出す。
では、それが意図どおりに備わっているかは、どの観点で見るか。四つ挙げる。合否をどこで切るかという判定基準は、ここには書かない。見るべき観点までを示す。
第一に、記述された意味が、実態と一致しているか。ここがこの層の急所だ。自己記述は、書いた瞬間から古びていく。価格を改定したのにJSON-LDは旧価格のまま。サービスを終了したのにllms.txtの地図には載ったまま。人間向けの表示は直したが、機械向けの記述を直し忘れる。この「表と裏のズレ」は、人間の目には見えにくく、エージェントの目にははっきり見える。誇張と陳腐化が混ざっていないか。
第二に、主要なエンティティとアクションが網羅されているか。機械に見せたい意味のうち、書き落としているものはないか。人間はナビゲーションを辿って見つけてくれるが、機械は書かれていないものを推測するか、見落とす。抜けは、存在しないことと同じになる。
第三に、llms.txtの記述が、サイトの実際の構造と食い違っていないか。地図が案内する先に、実際にその部屋があるか。
第四に、そもそも「誰のための記述か」を取り違えていないか。SEO順位を上げるつもりでllms.txtを積んでも、検索エンジンは読まない。読み手の想定を外した記述は、丁寧に作り込んでも空振りする。
この四つのうち、機械にすぐ任せられるものと、そうでないものがある。ファイルが在るか、書式が妥当か、必須の型が入っているか――こうした形式面は、Lighthouseのような道具がすでに自動でチェックする。だが「記述された意味が、実態と一致しているか」「誇張がないか」「読み手を取り違えていないか」は、サイトの中身と事業の実態を突き合わせなければ判断できない。形式が通ることと、意味が正しいことは、別のことだ。前者は機械に、後者は人に残る。この線引きが、次回以降の各層でも繰り返し出てくる。
次回
土台の「見る」を固めたら、次は動かす。第3回は「会話の層」、NLWebを扱う。静的に意味を差し出すだけだったサイトが、エージェントの問いに答える窓口になる。そしてその窓口は、今回整えたSchema.orgのデータをベクトルに変換して作られる。今回積んだ意味が、次回の会話の材料になる。名乗ったサイトが、応えるサイトになる話だ。
参考情報
この記事をシェアする
