ツール・技術

llms.txt をWordPressで実装した話。仕様の誤解と、Google非対応でも置くべき理由【実装コード公開】


公開日



最終更新

数日前、シエロデザインの自社サイト(このサイト)に /llms.txt を実装しました。同時に /llms-full.txt も配信しています。どちらも WordPressプラグイン側で動的生成 する構成です。

この記事では、実装しながら気付いた 仕様書の正確な読み方(日本語記事の多くが誤読している論点)、Googleが公式に非対応を明言している2026年現在の状況の中で それでもなぜ置くべきなのか、そして WordPressで実装するときの具体的なPHPコードとハマりどころ を、順に書いていきます。

「Website LLMs.txt」プラグインを入れて済ませる話ではなく、自前実装まで踏み込んだ理由と、その過程で見えたことの記録です。

llms.txt とは──Answer.AIが2024年9月に出した提案

llms.txt は、Answer.AI共同創業者 Jeremy Howard が 2024年9月3日 に公開した提案(Answer.AI 公式アナウンス)で、仕様書は llmstxt.org に置かれています。

ざっくり言うと、LLM(大規模言語モデル)が高い信頼度でサイトの構造・要約を把握できるように、人間向けHTMLとは別に「機械可読なマークダウン索引」をドメインルートに置きましょう、という提案です。

フォーマットの必須要素は次のとおり。

  1. # サイト名(H1/唯一の必須要素)
  2. > 概要(blockquote による一行要約/推奨)
  3. 詳細段落(任意)
  4. ## セクション名 配下に - [ページ名](URL): 説明 のリスト

配置場所はドメインルート(/llms.txt)、MIMEタイプは text/plain; charset=utf-8 です。

llms.txt / llms-full.txt / llms-ctx.txt の正確な違い(多くの記事が誤読している論点)

ここが日本語記事の8割くらいが誤読しているポイントなので、丁寧に書きます。

公式仕様書(llmstxt.org)を読むと、「full version」に相当するファイル名として 実際に定義されているのは llms-ctx.txtllms-ctx-full.txt の2つ です。これらは公式CLIツール llms_txt2ctxllms.txt から生成する派生ファイルで、XMLコンテキスト形式に変換したものです。

一方、業界でよく見かける llms-full.txt という名前は、仕様書には存在しない業界慣行 です。これは「サイト本文をMarkdownで全部インライン化した1枚ファイル」を指し、事実上のデファクト名として定着しました。WordPress用の代表的なプラグイン「Website LLMs.txt」も、llms-full.txt をオプション拡張として扱っています。

整理すると次のようになります。

ファイル名 ステータス 役割
llms.txt 公式仕様 キュレーション済みリンク索引(目次)
llms-ctx.txt 公式仕様(CLI生成物) Optionalセクションを除いたXMLコンテキスト
llms-ctx-full.txt 公式仕様(CLI生成物) Optionalセクションを含むXMLコンテキスト
llms-full.txt 業界慣行(仕様外) 本文を全部インライン化した完全版(本一冊)

私たちも llms-full.txt のほうを実装しました。「仕様書に存在しない業界慣行」であることを承知の上で、実運用として 本文を1ファイルで渡せる形は開発ツール側で有用 だと判断したためです。この「なぜ選んだか」を書ける記事は日本語圏にほぼありません。

2026年時点の対応状況:Googleは公式に非対応を明言している

llms.txt を導入するかどうかを判断する上で、絶対に押さえておくべき事実があります。

Googleは llms.txt に公式に対応していない と明言しています。2025年、Google の Gary Illyes 氏が LinkedIn で「対応するAIサービスを知らない」と発言し、John Mueller 氏は「(過去の)keywords メタタグと同じ」と評しています。Google-Extended(Gemini/AI Overview のクローラ)が llms.txt を読んでいる観測もありません。

2026年時点の対応状況を実測ベースで整理すると次のとおりです。

プロバイダ 公式スタンス 実測
Google(AI Overview / Gemini) 非対応明言 Google-Extended は無反応
Anthropic(Claude) 公式アナウンスなし Anthropic自身の platform.claude.com/docs/llms.txt で実装済
OpenAI(ChatGPT) 未表明 GPTBotが約15分間隔で /llms.txt を叩くログあり
Perplexity 未表明 PerplexityBot のクロール観測あり

採用率について、SE Ranking が30万ドメインを調査した結果は 10.13%。ALLMO.ai が94,000URLで5モデルを評価した調査では 「AI引用への統計的に有意な効果は認められない」 という結論が出ています。

つまり、「llms.txt を置けばAI検索の順位が上がる」という単純な話にはなっていない、というのが2026年7月時点の正直なところです。

それでも今 llms.txt を置くべき3つの理由

Googleが非対応、統計的効果も不明──それでも私たちが自社サイトに llms.txt を置いた理由は3つあります。

1. 開発者ツール流入への実利用価値

Cursor / GitHub Copilot / Claude Code のような開発者向けAIツールは、ドキュメントを参照するとき /llms.txt を明示的に読みに行きます。Anthropic 自身が platform.claude.com/docs/llms.txt を置いているのはこの用途です。「開発者コミュニティに参照される可能性のあるサイト」なら、置いておく実利がすでにあります。

2. 先行者ポジションの獲得

採用率10%という数字は「まだ全体としては少ないが、じわじわ増えている」段階を意味します。将来 Google が方針転換したり、他プロバイダが利用を強化したりしたときに、「もう置いてある」状態から入れるか、慌てて対応するかで差が出ます。実装コストは低いので、先行しておく価値のある賭けだと判断しました。

3. サイト構造の棚卸しになる

これは副次効果ですが、llms.txt を書くために「うちのサイトの重要ページ・キュレーション対象」を明文化する作業自体が、コンテンツ設計の棚卸し になります。sitemap.xml が「全URLの機械的なリスト」なのに対し、llms.txt は「何を推すか」という編集判断が入る場所です。

WordPressで実装する2つの方法:プラグイン vs 自前実装

WordPressで llms.txt を用意する方法は大きく2つあります。

方法A:Website LLMs.txt プラグインを使う

公式ディレクトリで4万インストール以上ある Website LLMs.txt を入れれば、5分で llms.txt を配信できます。トグルひとつで llms-full.txt も出せます。手っ取り早く済ませたい場合はこれで十分 です。

方法B:自前実装する

私たちは自前実装を選びました。理由は3つ。

  • 出力内容を細かく制御したい(会社概要のセクション構成、記事の掲載順、除外ルール等)
  • 既存の自作プラグイン(cielo-blog)に統合したい(構造化データ・robots.txt処理と同居させて依存を減らす)
  • 実装記事のネタにできる(記事化して差別化)

コード量は 100行程度で済むので、自作プラグインを既に運用している制作会社であれば自前実装のほうが取り回しが良いです。

実装ステップ(WordPress・PHPコード全公開)

実装は次の5ステップで進めます。

  1. rewrite rule で /llms.txt/llms-full.txt を捕捉する
  2. query_var を追加して WordPress に認識させる
  3. template_redirect で内容を生成・出力する
  4. canonical redirect のトラップを回避する(後述のハマりどころ)
  5. transient でキャッシュし、投稿更新時に自動クリアする

ステップ1〜3:rewrite rule と出力ハンドラ

add_action( 'init', function () {
    add_rewrite_rule( '^llms\.txt$',      'index.php?cielo_llms=1',    'top' );
    add_rewrite_rule( '^llms-full\.txt$', 'index.php?cielo_llms=full', 'top' );
} );

add_filter( 'query_vars', function ( $vars ) {
    $vars[] = 'cielo_llms';
    return $vars;
} );

add_action( 'template_redirect', function () {
    $type = get_query_var( 'cielo_llms' );
    if ( ! $type ) return;

    $is_full   = ( $type === 'full' );
    $cache_key = $is_full ? 'cielo_llms_full_v2' : 'cielo_llms_index_v2';
    $body      = get_transient( $cache_key );
    if ( false === $body ) {
        $body = cielo_blog_render_llms_txt( $is_full );
        set_transient( $cache_key, $body, HOUR_IN_SECONDS );
    }

    header( 'Content-Type: text/plain; charset=utf-8' );
    header( 'Cache-Control: public, max-age=3600' );
    header( 'X-Robots-Tag: index, follow' );
    echo $body;
    exit;
} );

ステップ4:canonical redirect のトラップを回避

WordPressの redirect_canonical() は、trailing slash のない URL を trailing slash 付きに 301 リダイレクトする挙動があります。これが最大のハマりどころです。 対策なしだと /llms.txt/llms.txt/ にリダイレクトされ、LLMクローラは正しくコンテンツを取れません。

add_filter( 'redirect_canonical', function ( $redirect_url, $requested_url ) {
    if ( preg_match( '#/llms(-full)?\.txt/?$#', $requested_url ) ) return false;
    return $redirect_url;
}, 10, 2 );

ステップ5:投稿追加・更新でキャッシュを自動クリア

add_action( 'save_post_blog', 'cielo_blog_llms_cache_clear' );
add_action( 'deleted_post',   'cielo_blog_llms_cache_clear' );
function cielo_blog_llms_cache_clear() {
    delete_transient( 'cielo_llms_index_v2' );
    delete_transient( 'cielo_llms_full_v2' );
}

コード全体は 姉妹記事「AI OverviewにWordPress記事を載せるために…」 と同じ cielo-blog プラグインに統合しています。

実装時のハマりどころ4選(一次情報)

1. Trailing slash canonical redirect(既述)

これは Website LLMs.txt プラグインも v8.1.2 で対応した既知の落とし穴です。自前実装するなら redirect_canonical フィルタは必須 だと覚えておいてください。

2. Cloudflare / サーバーキャッシュが .txt を静的扱いする

Cloudflare 標準設定や WP Super Cache は、拡張子 .txt のリクエストを静的ファイル扱いして CDN でキャッシュします。動的生成にした意味がなくなるので、llms.txt / llms-full.txt をキャッシュ対象から除外するルール をCDN側にも入れる必要があります。私たちはヘッダで Cache-Control: public, max-age=3600 と1時間TTLで抑えつつ、投稿更新時に transient は即クリアする構成にしています。

3. WP-Cron が動かない環境での再生成沈黙

Website LLMs.txt プラグインは以前、WP-Cron 経由で再生成を予約する仕組みでした。しかし WP-Cron を無効化している環境(DISABLE_WP_CRON = true)では再生成が沈黙する事象があり、v8.5.3 で「即時再生成」に変更された経緯があります。自前実装なら transient + save_post フックの組み合わせが素直 です。

4. Xserver 等の opcache による反映遅延

これは実装中に実際に踏みました。Xserver は opcache(PHP のバイトコードキャッシュ)を持っていて、通常 60 秒ごとに再検証します。プラグイン更新直後は最大1分程度、旧コードが動く可能性がある ので、動作確認は少し時間を置いてから行うのが安全です。

cielo-design.com の llms.txt 実物を見てみる

実装結果は次の2つのURLで実際に読めます。

あわせて、robots.txt からも参照させています。Sitemap: ディレクティブに llms.txt を追記することで、クローラがサイトマップと同じレベルで発見できるようにしています。

sitemap.xml / robots.txt との棲み分け

「sitemap.xml があるなら llms.txt はいらないのでは?」という質問がありそうなので整理します。

  • sitemap.xml:機械可読、全URL網羅、優先度は数値、SEOクローラ向け
  • robots.txt:クロールの許可・拒否ルール、User-Agent 別
  • llms.txt:LLM向けキュレーション済み案内板、Markdownで人間も読める、優先度は「編集判断」

3者は競合しません。私たちの構成では、この3つ全部を配信し、robots.txt から sitemap.xml と llms.txt の両方を参照させています。

よくある質問(FAQ)

Q. llms.txt はどこに置けばいいですか?

A. ドメインルート(例:https://example.com/llms.txt)に置きます。サブディレクトリでは仕様外です。WordPressで動的生成する場合も、URL上はルート直下として振る舞う必要があります。

Q. llms.txt と llms-full.txt の違いは何ですか?

A. llms.txt は「キュレーション済みリンク索引」(目次)、llms-full.txt は「本文を全部インライン化した完全版」(本一冊)です。ただし llms-full.txt は仕様書に定義されていない業界慣行の名称で、公式には llms-ctx.txt / llms-ctx-full.txt が別途定義されています。

Q. Googleは llms.txt を読んでくれますか?

A. 読みません。 Googleは公式に対応していないと明言しています(Gary Illyes 氏、John Mueller 氏の発言)。AI Overview に llms.txt が影響することはありません。

Q. それでも置く価値はありますか?

A. あります。Cursor / GitHub Copilot / Claude Code などの開発者ツールが実際に参照する、GPTBot / PerplexityBot が定期的にクロールしている、将来の対応拡大に備えた先行者ポジション、サイト構造の棚卸し効果──この4点が現在の実利です。

Q. WordPressで実装するならプラグインと自前実装どっちがいいですか?

A. 手っ取り早く済ませたいなら Website LLMs.txt プラグイン(4万インストール以上、実績あり)で十分です。既に自作プラグインを運用していて、出力内容を細かく制御したい場合は自前実装(100行程度)のほうが取り回しが良いです。

Q. sitemap.xml と併存して大丈夫ですか?

A. 大丈夫です。用途が違います(sitemap.xml=全URL網羅/llms.txt=LLM向けキュレーション案内)。robots.txt の Sitemap: ディレクティブ に両方書けます。

Q. 実装コストはどのくらいですか?

A. プラグイン利用なら10分程度、自前実装でも半日以内に本番稼働まで持って行けます。ただし本記事で挙げた trailing slash canonical redirect / CDNキャッシュ / opcache反映遅延 の3つのハマりどころは事前に押さえておいたほうが安全です。

Q. 効果測定はどうすればいいですか?

A. 現時点で確実に測れるのは アクセスログでのAIクローラのアクセス回数 だけです。GPTBot / ClaudeBot / PerplexityBot の User-Agent 別のクロール頻度と、llms.txt / llms-full.txt へのヒット数を追うのがミニマムな観測です。

まとめ:仕様を正しく理解して、実利ベースで判断する

llms.txt をめぐる状況は、2026年7月時点ではまだ「バズワードと実利の中間」にあります。Googleが非対応を明言している以上、SEO文脈で語るのは正確ではありません。

ただし、開発者ツールでの実利用は既にあり先行者としての導入コストは低く実装過程で得られるサイト構造の棚卸し価値 もあります。仕様書を正確に読んだ上で、この3点を実利として拾いに行けるなら、置く価値のある技術だと考えています。

この記事が、これから llms.txt を導入検討している方の判断材料になれば嬉しいです。実装コードは AI Overview 対応の実装記事 と同じプラグインに統合してあります。実装のご相談は お問い合わせフォーム からどうぞ。

参考文献(一次ソース)

この記事を書いた人

佐藤 広樹

WEBディレクター

佐藤 広樹 Sato

仕事を通じて出会った方から「人から学ぶ」ことを大切に、AIやWEBから得られない知見を吸収するよう意識しています。

シエロデザインのサービス

サービス一覧を見る →

お問い合わせ

Webサイト制作・保守・広告運用・Web戦略チーム支援など、私たちシエロデザインが伴走できる領域はさまざまです。
「うちの場合どうすれば?」というご相談も、まずはお気軽にお声がけください。

お問い合わせフォームへ →

llms.txt をWordPressで実装した話。仕様の誤解と、Google非対応でも置くべき理由【実装コード公開】