llms.txtを導入して90日：我々にとってやれたこと、やれなかったこと

6月、私たちはaat.ee全体にllms.txtを導入しました — 1つのルートファイル、サイトの主要コンテンツのマークダウンマップをaat.ee/llms.txtで配信するものです。所要時間は約1時間でした。90日後、これが何をして何をしなかったかについて正直に記録します。というのも、llms.txtについて読むことのほとんどは、仕様の焼き直しかセールストークであり、その中間 — 実際の本番サイトから得られた測定結果 — はほとんど存在しないからです。

llms.txtとは何か、1段落で

llms.txtは提案された慣習です（標準ではありません — これについては後述します）：ドメインのルートに置かれたマークダウンファイルで、言語モデルにあなたのサイトのキュレーションされたマップを提供します。sitemap.xmlがクローラー向けのURLの網羅的なリストであるのに対し、llms.txtはアシスタント向けの短く優先順位付けされた_読書リスト_です — 何が重要で、何と呼ばれ、どこにあるのか。エージェントは盲目的にクロールするよりもキュレーションされた要約を好むだろう、という賭けです。

私たちが導入したもの

実装は意図的に退屈なものです：単一の動的ルートが3つのものを組み合わせます — 静的なクロールポリシーの前文、最新15件のローンチ、最新10件の公開記事、そしてカテゴリリスト — をマークダウンに変換し、ユーザー制御のあらゆるものをラップする1つのエスケープ関数を備えています。

// User text (project names, article titles) must not break out of the
// markdown link or inject headings into an agent-facing file.
function mdSafe(text: string): string {
  return text
    .replace(/[\r\n]+/g, " ")
    .replace(/[[\]()]/g, "")
    .trim()
}

const projectLinks = recentProjects
  .map((p) => `- [${mdSafe(p.name)}](${baseUrl}/projects/${p.slug})`)
  .join("\n")

// User text (project names, article titles) must not break out of the
// markdown link or inject headings into an agent-facing file.
function mdSafe(text: string): string {
  return text
    .replace(/[\r\n]+/g, " ")
    .replace(/[[\]()]/g, "")
    .trim()
}

const projectLinks = recentProjects
  .map((p) => `- [${mdSafe(p.name)}](${baseUrl}/projects/${p.slug})`)
  .join("\n")

このサニタイズのステップだけが唯一の繊細な部分です。プロジェクト名やタイトルはユーザーやLLMパイプラインから来ます；埋め込まれた改行や括弧は、リスティングがアシスタントにマップとして信頼するよう促されているファイルに見出しや偽のリンクを注入することを可能にしてしまいます。

ログが示したもの

90日間のサーバーログとリファラーデータからの3つの観察。

エージェントは実際に取得する。 既知のアシスタントクローラーのユーザーエージェントから/llms.txtへの定期的な取得が見られます。頻度はrobots.txtよりずっと低いですが、一貫して存在しています。仕様のステータスがどうであれ、取得行動は現実です。

測定可能な紹介の奇跡はない。 aat.eeへのAIアシスタントからの紹介は四半期を通じて増加しました — しかしその成長はllms.txtの導入ではなく、私たちの公開ペースに沿っています。エージェントがファイルを読んだことに起因する単一のセッションすら特定できず、ここで厳密なアトリビューションを主張する人には疑いの目を向けています：アシスタントは取得し、それから複数のソースのブレンドから回答し、引用がllms.txt型のリファラーを伴うことはほとんどありません。

有用な棚卸しを強制した。 予想外の利点：キュレーションされたマップを書くということは、あなたのサイトの_トップ_が実際に何であるかを決めることを意味します。私たちのルートはライブデータをレンダリングするので、ファイルは最新の状態に保たれます — しかし「読書リストに何が属するか」という規律は、ファイル自体よりもカテゴリ構造を改善しました。

居心地の悪い部分：それはまだ提案にすぎない

llms.txtには批准された標準がありません。MIMEタイプは議論の的で（text/markdown対text/plain）、アシスタントがそれを読むと文書化されておらず、持っていなくても何も壊れません。2026年にそれが「AI SEOに必須」だと言う記事は、証拠より先を行っています。

90日後の私たちの立場：コストが非常に低いので期待値は正のままであり、よく整理されたロビーがオフィスビルにとってプラスであるのと同じです。それ自体が結果を左右することはありませんが、エージェントが方向性を探しに行くとき、壁ではなくキュレーションされたマップを見つけてほしいはずです。

作るべきか？

正直な判断表：

サイトが約50ページ未満でタイトルが明確な場合 — 限界的。あなたのサイトマップとナビゲーションがすでに物語を語っています。
データ駆動型のサイトの場合（ローンチ、リスティング、記事、ドキュメント — 毎週変わるコンテンツ） — はい。生成されたllms.txtは1つのルートファイルで、自動的に最新の状態を保ち、サイトマップにはできないスパムのない要約をアシスタントに提供します。
AIランキングを押し上げると言われた場合 — いいえ。それはマップであり、メタタグではありません。

上記の実装パターン — 構成、サニタイズ、配信 — はルーティング層を持つあらゆるフレームワークに適合します。手書きではなく生成されたままにし、ユーザーテキストをサニタイズしたままにし、期待値を調整したままにしておきましょう。

llms.txt、90日後：正直な振り返り

llms.txtとは何か、1段落で

私たちが導入したもの

ログが示したもの

居心地の悪い部分：それはまだ提案にすぎない

作るべきか？

新しいプロダクトをお持ちですか？