llms.txt を6サイトに置いた。
isLog、moss、taupe、ojicra、monoomoi、monoerabiの6サイトです。
やってみて思ったのは、これは「AIに読まれる魔法のファイル」ではないということ。
少なくとも、llms.txt を置いたからAI検索で急に引用される、という話ではありません。
ただ、試す価値はある。
AI agentやAIブラウザがサイトの全体像をつかむための、簡単な案内板にはなりそうです。
でも、本命はそこだけではなかった。
大事なのは、公開ページそのものがAIに誤読されにくい状態になっているか。
ここをチェック項目として見た方が、かなり実務に落としやすいです。
この記事では、llms.txt を6サイトに置いたあと、自分のサイトをAI-readableの観点でどう確認するかを整理します。
2026年7月2日時点の、自分の運用ログです。
llms.txtだけでAIに読まれるわけではない
まず、llms.txt については期待しすぎない方がいいです。
Chrome Lighthouseのagentic browsing auditでは、llms.txt はLLMやAI agent向けにサイト内容を機械が読み取りやすくまとめるための emerging convention と説明されています。
同時に、現時点ではoptionalとも扱われています。
つまり、ないからダメというものではない。
置いたら検索評価が上がる、というものでもない。
llms.txt の提案元でも、基本はMarkdownでサイト概要や重要リンクをまとめる考え方です。
robots.txtやsitemapの代わりではなく、AIがサイトを理解するための補助線として見るのが自然です。
ここを間違えると、「AI向けSEOの新しい必須ファイル」みたいな話になってしまう。
それは少し違うと思っています。
それでも6サイトに置いてみた
とはいえ、試さないと分からない。
そこで、自分が運営している6サイトに /llms.txt を置きました。
2026年7月2日時点で、6サイトとも 200 OK で公開確認済みです。
Content-Typeも text/plain 系で返っています。
中身は全記事一覧ではありません。
サイトの説明、主要カテゴリ、代表記事、運営者・公式導線、AIが要約する時の注意点を絞って入れています。
ここで大事なのは、AIにだけ別の説明を見せないこと。
公開ページと矛盾することを書かないこと。
llms.txt は、公開サイトの正本ではなく案内板です。
正本はあくまで公開HTML、記事本文、構造化データ、内部リンクです。
本命は、llms.txtより公開ページの読みやすさだった
Googleの生成AI検索向けガイドを読むと、生成AI検索でも基本的なSEOは引き続き重要だと説明されています。
GoogleのAI機能は検索インデックスやクロール可能な公開ページを土台にしているため、ページが見つかること、技術構造が明確であること、読者に役立つことが前提になります。
OpenAIのcrawler docsも、OAI-SearchBot、GPTBot、ChatGPT-User を分けて説明しています。
Searchに出るためのbot、学習利用に関係するbot、ユーザー操作でアクセスするagentは同じではない。
ここを全部「AIクローラー」とまとめてしまうと、判断を間違えやすい。
だから、自分のサイトで見るべきなのは「AIに読ませる裏技」ではありません。
公開URLがちゃんと返るか。
canonicalが正しいか。
記事の主題がH1と導入で分かるか。
Article JSON-LDが本文とズレていないか。
パンくずでカテゴリ階層が分かるか。
内部リンクのアンカーが具体的か。
変わる情報に確認日があるか。
こういう普通の公開品質を、AIが読む前提でもう一度見る。
そこが本命でした。
AIに誤読されにくいかをチェック項目にする
自分用には、次のようなmini-checkにしています。
AI-readable mini-check - URLは200 OKか - canonicalとog:urlは意図したURLを指しているか - noindexになっていないか - ArticleまたはBlogPostingのJSON-LDがあるか - BreadcrumbListがあるか - 著者、公開日、更新日が分かるか - H1と冒頭で、何の記事か分かるか - 体験談と確認済み事実が混ざりすぎていないか - 変わる情報に確認日があるか - 内部リンクのアンカーが具体的か - llms.txtを置くなら、公開ページと矛盾していないか
これは、特別なAI対策というより公開前チェックです。
人間が読んでも分かりやすい。
検索エンジンにも伝わりやすい。
AI agentが要約しても過剰に一般化しにくい。
この3つは、かなり重なっています。
taupeの記事で実際に見てみた
実際に、taupeの記事でもチェックしました。
対象にしたのは、Mac miniをCodexの母艦にする運用を書いた記事です。
Mac miniをCodexの母艦にしたら、外出先でもAIチームの仕事が回るようになった
この記事は、記事単体としてはかなり読み取りやすい状態でした。
canonicalと og:url は一致。
ArticleとBreadcrumbListのJSON-LDあり。
H1とtitleも一致。
H2も「母艦」「公式docs」「iPhoneから判断」「Codex Cloudとの違い」「試す順番」に分かれていて、AIが要約した時にも文脈を拾いやすい。
一方で、小さな改善候補も見つかりました。
Pochippや計測系画像のaltに、記事タイトルが流用されている箇所がある。
これは読者体験を壊すほどではありません。
ただ、AI-readableの観点では、本文画像、商品画像、装飾画像、計測画像は分けて扱った方がいい。
こういう細かいところは、通常のSEOチェックだけだと見逃しがちです。
外部GEOツールの前に、自分の基準を持つ
最近は、AI-readableやGEOをチェックするツールも出てきています。
サイトがAI agentに読みやすいかをスコア化するもの、Codex skillとして監査するもの、ページをAI向けにextractするもの。
流れとしては面白いです。
でも、自分はすぐに本番ChromeやCodex環境へ入れるより、まず自分のチェックリストに翻訳する方がいいと考えています。
理由は単純です。
外部ツールの点数だけ見ても、何を直すべきか分からないことがあるから。
逆に、自分の基準があれば、外部ツールの結果も判断しやすくなります。
これは本当に直すべき問題なのか。
今すぐではなく、テンプレート改善で見ればいいのか。
記事単体の問題なのか、サイト全体の問題なのか。
こう分けられるだけで、かなり運用しやすくなります。
公開前に見るなら、この順番がよさそう
記事公開前に全部を重く見る必要はありません。
毎回サイト全体を監査していたら、記事が出せなくなる。
なので、自分は記事単位とサイト単位を分けています。
記事公開時に見るものは、このくらい。
記事単位 - title / H1 / descriptionが記事内容と合っている - canonical / og:urlが正しい - noindexになっていない - Article JSON-LDがある - BreadcrumbListがある - 著者、公開日、更新日が分かる - 内部リンクが1〜2本以上ある - 変わる情報に確認日がある - 参考にした公式・一次情報がある
サイト単位で見るものは、月1回か大きな変更時でよさそうです。
サイト単位 - robots.txt - sitemap - feed - llms.txt - About / author / profile - 主要カテゴリと入口記事 - AI crawler policy - 公式hubや問い合わせへの導線
この分け方にすると、記事公開の手は止まりにくい。
でも、AI-readableの観点も置き去りにしにくい。
まとめ。AI-readableは公開品質の延長
llms.txt は面白いです。
6サイトに置いてみたことで、サイトをAIにどう説明するかを考えるきっかけにもなりました。
ただ、そこで終わりではない。
AIに誤読されにくいサイトにするなら、公開ページそのものを見た方がいい。
canonical、JSON-LD、パンくず、内部リンク、著者、更新日、確認日。
どれも昔からある要素です。
でも、AI検索やAI agentが読む前提になると、見え方が少し変わります。
検索エンジンに見つけてもらう。
読者に伝わる。
AIが要約してもズレにくい。
この3つを、別々の話にしない。
llms.txt を置くかどうかよりも、まずは公開ページが読めること。
辿れること。
誤読されにくいこと。
AI-readableなサイトづくりは、新しい魔法ではなく、公開品質のチェック項目を少し増やす話だと思っています。
関連して読みたい本
AIに読まれるサイトを考える時は、AIエージェント側の動きと、検索に強いサイトづくりの基本を分けて見ておくと整理しやすいです。
今回の記事に近い本を置いておきます。
ポチップ