llms.txtとは？WordPress・Laravel・Railsの実装方法とLLMOでの有効性

llms.txtは、LLMやエージェントがサイト内の重要な情報へ進みやすいよう、短い説明と厳選リンクをMarkdownで渡すコミュニティ提案仕様です。この記事では2026年8月10日更新のv2を前提に、LLMO対策として期待できる範囲を整理し、WordPress、PHP、Laravel、Ruby on Rails、Sinatraへ設置する方法を解説します。

対象は、AI検索・エージェント向けの情報整理を試したいサイト運営者とWeb開発者です。読了後は、静的ファイルと動的ルートのどちらが自分のサイトに合うかを選び、HTTP応答、リンク、アクセスログまで検証できます。LLMO全体のコンテンツ設計は関連記事へつなぎ、本記事ではllms.txtの採用判断・実装・測定に集中します。

情報確認日：2026年8月17日（日本時間）／確認対象：llms.txt v2（2026年8月10日更新）

案内役として小さく設置し、目的に合わせて効果を測る

ドキュメント、API、製品情報など、エージェントにたどってほしい入口が明確なサイトでは、厳選したllms.txtを用意するのがおすすめです。GoogleのAI検索での露出を高めたい場合は、クロール可能なHTML、独自情報、内部リンク、通常のSEOを整えながら、対応サービス向けの補助としてllms.txtを併用するのがおすすめです。

llms.txtとは何を提案するファイル？

llms.txt v2は、サイトまたは特定パスの概要、解釈上の注意、詳細ページへのリンクをMarkdownで提供する案です。エージェントは小さなllms.txtから必要なリンクを選び、詳細を必要なときだけ取得する想定です。

提案仕様は2024年に公開され、2026年8月10日にv2へ更新されました。v2も「提案仕様」と明記され、コミュニティからの意見を受ける段階です。インターネット標準や検索エンジンの順位仕様ではなく、対応するエージェントへの案内を試す提案として扱うのがおすすめです。

v2で何が提案されている？

• サイトルートの/llms.txtだけでなく、/docs/llms.txtのようなサブパスにも置ける
• ファイルは置かれたパス以下を対象とし、複数ある場合はより具体的なパスを使う想定
• 通常ページと同じ内容の簡潔なMarkdown版を、.mdを付けたURLなどで提供する案
• rel="alternate" type="text/markdown"でMarkdown版を示す案
• rel="describedby"で対象パスのllms.txtを示す案

最初の試験導入で、すべてのページへMarkdown版を用意する必要はありません。まず小さなllms.txtだけを置き、通常HTMLの正規ページへリンクします。簡潔なMarkdown版を増やす段階では、HTMLとの更新ずれ、重複URL、キャッシュ、アクセシビリティを別に検証します。

必須形式は何？

v2ではH1のサイト・プロジェクト名だけが必須です。ただし、実用的なファイルは次の順で作ります。

1. 任意のBOM
2. 一つのH1
3. サイトを短く説明する引用ブロック
4. 見出しを含まない補足文・一覧
5. H2ごとのファイル一覧

ファイル一覧は、Markdownリンクを必須とし、その後ろへ任意の説明を付けます。URLだけを裸で並べるより、ページ名と「何が分かるか」を簡潔に書きます。

最小のllms.txt テンプレート

# Example Media

> Example Mediaは、WordPress運営とWeb開発の実務手順を公開する日本語サイトです。

Primary language: Japanese.
Prefer canonical URLs and check each page's published and modified dates.

## Start here

- [WordPress運営ガイド](https://example.com/wordpress/): 初期設定、更新、保守の入口
- [Web開発ガイド](https://example.com/web-development/): HTML、CSS、JavaScriptの実装記事

## Trust and policies

- [運営者・編集方針](https://example.com/about/): 発行主体、編集・更新方法
- [プライバシーポリシー](https://example.com/privacy/): data、広告、問い合わせの扱い
- [問い合わせ](https://example.com/contact/): 訂正依頼と連絡先

## Optional

- [全記事のXML sitemap](https://example.com/wp-sitemap.xml): 網羅的なURL一覧が必要な場合

Example Media、説明、URLを自サイトへ置き換えます。自社だけが使う略語は避け、リンク説明は一件一文にします。Optionalは、コンテキストを短くしたいクライアントが省略できる補助情報としてv2で使われる慣例です。

robots.txt・sitemap・構造化データとの違い

Google Search Centralは、robots.txtをクローラーがリクエストできるページ・ファイルの制御、sitemapを新規・更新URLの通知として説明しています。sitemapでさえ取得・インデックス・順位を保証するものではありません。llms.txtも順位保証ではなく、対応するエージェントへの案内として評価するのがおすすめです。

llms.txtはクローラーを許可・拒否できる？

できません。v2の提案仕様自身も、robots.txtとは目的が異なると説明しています。クローラーのアクセス方針はrobots.txt、ページのインデックス方針は対応するmetaタグ・HTTPヘッダー、非公開情報は認証・認可で守ります。

llms.txtに「学習禁止」「引用必須」と書いても、法的・技術的な制御が自動で成立するわけではありません。利用条件が必要なら正式な利用規約、ライセンス、クローラー別の公式な制御方法と専門家の助言を使います。

SEO効果をなぜ断定できない？

2026年8月17日に確認したGoogle Searchの公式ガイドは、llms.txtをGoogle検索（生成AI機能を含む）では使用せず、設置しても検索順位や可視性に正負の影響はないと明記しています。したがって、Google向けSEO施策としてではなく、利用する他サービスやエージェントを確認したうえで試験導入する位置づけが適切です。

llms.txtを取得するエージェントが存在しても、その事実からGoogle順位やAI回答への引用増加は導けません。クローラー、推論、学習、検索順位は別のプロセスだからです。

LLMO対策としてllms.txtはどこまで有効？

LLMOでの有効性は、「どのサービスへ、何をしてほしいか」で変わります。llms.txtは検索順位を直接操作するファイルではなく、対応するエージェントへサイトの概要と正規の入口を渡す案内役です。目的を次のように分けると、採用するか判断しやすくなります。

OpenAIは開発者向けドキュメントのllms.txtと各ページのMarkdown版を公開しています。一方、ChatGPT検索への掲載を管理する公式資料は、robots.txtでOAI-SearchBotを許可する方法を案内しており、llms.txtによる順位や引用の効果は説明していません。自社で採用している事実と、外部サービスが検索・回答へ使う事実は分けて判断します。

Google向けの対策を優先するなら、llms.txtより先にAI生成コンテンツの扱いとGoogle公式方針を確認しておくほうが効きます。詳細はAI生成コンテンツはSEOで不利？Google公式方針と公開前の確認点にまとめています。

実装と更新の負担が小さく、案内したいページが明確なら、llms.txtを追加してログと回答を測るのがおすすめです。更新担当者が決まっていない場合は、まず10〜20件程度の小さなファイルを運用するか、公開データからビルド時に生成して人が差分を確認する方法がおすすめです。

何を載せるページとして選ぶ？

XML sitemapの全URLを複製せず、エージェントがサイトの目的を理解し、代表的な質問へ答えるための入口を選びます。

公開済み正規URLだけを使い、リダイレクト、パラメーター URL、タグの重複、検索結果ページを避けます。AI検索全体の施策はAI検索時代のSEO・GEOで扱い、本記事ではファイルの試験導入だけに限定します。

llms.txtへ載せない情報

• 非公開・下書き・ステージング・管理画面・プレビューURL
• パスワード、APIキー、内部プロンプト、データベース・サーバー情報
• 個人情報、顧客別ページ、契約で非公開の資料
• 正規でない重複URL、期限切れキャンペーン
• 自分が内容を確認していない外部サイト
• 「必ず正しい」「公式が推奨」など根拠のない優先指示

llms.txtは公開URLです。robots.txtでクロールを止めても機密情報にはなりません。外部へ出せない内容は、ファイルへ書かず認証の内側へ置きます。

実装方法は静的配置と動的配信のどちらを選ぶ？

内容が少なく更新頻度も低い場合は、公開ルートへ静的なllms.txtを置く方法がおすすめです。データベースや設定から内容を生成したい場合は、アプリケーションの専用ルートでtext/plainを返す方法がおすすめです。

WordPressへ設置する3つの方法

実ファイル、SEOプラグイン、テーマ・MUプラグイン、CDNルールが同じパスを奪い合うと、編集した場所と実際のレスポンスがずれます。既存の出力元を確認し、管理方法を一つにそろえるのがおすすめです。

方法1：静的ファイルをWebルートへ置く

1. ステージングでUTF-8のllms.txtを作る
2. WordPressが公開されるドキュメントルートへ配置する
3. https://example.com/llms.txtが200を返すことを確認する
4. CDN・ページキャッシュをパージし、オリジンと公開レスポンスを比較する
5. Git外で配置する場合は、正本と更新担当者を台帳に残す

テーマディレクトリへ置いてもサイトルートの/llms.txtにはなりません。共有ホスティングでドキュメントルートの変更権限がない場合は、既存プラグインまたはサイト固有のコードを検討します。

方法2：既存プラグインの出力を使う

すでに利用中のSEOプラグインがllms.txtを生成する場合は、追加プラグインより先にその機能を確認します。次の項目をステージングでテストします。

• v2 形式と更新日が明示されているか
• 下書き、noindex、非公開、リダイレクトURLが混ざらないか
• 全記事の自動dumpではなく編集者がリンクを選べるか
• 停止・削除時に古いキャッシュや実ファイルが残らないか
• 同じパスをほかのプラグイン・CDNが処理していないか

プラグインが「AI SEO向上」をうたっていても、順位や引用の保証とは分けて判断します。採用前に更新履歴、サポート、権限、脆弱性対応、データ送信を確認してください。

方法3：MUプラグインで小さく配信する

WordPress公式資料では、MUプラグインは既定のwp-content/mu-plugins直下へ置くと自動的に有効になります。通常のプラグイン画面から誤って停止されにくい一方、更新通知やactivation hookがなく、自分で保守する必要があります。

次の例は、実ファイルを作らず、サイトルートのリクエストだけへ厳選したMarkdownを返します。テーマ変更に依存させないため、サイト固有のMUプラグインとして置きます。

<?php
/**
 * Plugin Name: Site llms.txt
 * Description: Serve a small, editor-reviewed llms.txt response.
 */

function example_is_llms_request() {
    $request_path = wp_parse_url(
        wp_unslash($_SERVER['REQUEST_URI'] ?? ''),
        PHP_URL_PATH
    );
    $home_path = wp_parse_url(home_url('/'), PHP_URL_PATH);
    $expected = trailingslashit($home_path ? $home_path : '/') . 'llms.txt';

    return untrailingslashit((string) $request_path)
        === untrailingslashit($expected);
}

function example_render_llms_txt() {
    if (is_admin() || ! example_is_llms_request()) {
        return;
    }

    $lines = array(
        '# Example Media',
        '',
        '> WordPress運営とWeb開発の実務手順を公開する日本語サイトです。',
        '',
        'Primary language: Japanese.',
        'Prefer canonical URLs and check each page\'s modified date.',
        '',
        '## Start here',
        '',
        '- [WordPress運営ガイド](' . home_url('/wordpress/') . '): 初期設定と保守の入口',
        '- [Web開発ガイド](' . home_url('/web-development/') . '): 実装記事の入口',
        '',
        '## Trust and policies',
        '',
        '- [運営者・編集方針](' . home_url('/about/') . '): 発行主体と更新方法',
        '- [プライバシーポリシー](' . home_url('/privacy/') . '): dataと広告の扱い',
        '- [問い合わせ](' . home_url('/contact/') . '): 訂正依頼と連絡先',
        '',
        '## Optional',
        '',
        '- [XML sitemap](' . home_url('/wp-sitemap.xml') . '): 網羅的なURL一覧',
    );

    status_header(200);
    nocache_headers();
    header('Content-Type: text/plain; charset=UTF-8');
    header('X-Content-Type-Options: nosniff');
    echo implode("\n", $lines) . "\n";
    exit;
}
add_action('template_redirect', 'example_render_llms_txt', 0);

例のURLと説明を自サイトへ置き換え、ステージングでPHP syntaxとレスポンスを確認します。記事一覧をget_posts()で毎回自動dumpせず、編集者が選んだリンクをコード レビューできる形にしています。

PHP・Ruby系サイトへ実装する方法

PHPサイトへ実装する方法

通常のPHPサイトでも、更新が少ないならドキュメントルートへ静的なllms.txtを置く方法がおすすめです。既存のフロントコントローラーで配信する場合は、HTMLを出力する前に/llms.txtだけを判定し、テキストとして返します。

<?php
$path = parse_url($_SERVER['REQUEST_URI'] ?? '/', PHP_URL_PATH);

if ($path === '/llms.txt') {
    $file = dirname(__DIR__) . '/resources/llms.txt';

    if (! is_file($file)) {
        http_response_code(404);
        exit;
    }

    header('Content-Type: text/plain; charset=UTF-8');
    header('X-Content-Type-Options: nosniff');
    readfile($file);
    exit;
}

// 既存アプリケーションのbootstrap処理を続ける

PHPのheader()は本文出力より前に呼ぶ必要があります。コードをpublic/index.phpへ組み込む場合は、既存のルーティング、サブディレクトリ設置、CDNキャッシュを確認します。サーバーから直接静的ファイルを配信できるなら、PHPを起動しない静的配置のほうが構成を単純にできます。

Laravelへ実装する方法

Laravelでも、内容をGitで固定管理するならpublic/llms.txtへ置く方法がおすすめです。公開中の記事や設定から内容を組み立てる場合は、専用controllerでレスポンスとheaderを明示します。

<?php
// routes/web.php
use App\Http\Controllers\LlmsTxtController;

Route::get('/llms.txt', LlmsTxtController::class)
    ->name('llms.txt');

<?php
// app/Http/Controllers/LlmsTxtController.php
namespace App\Http\Controllers;

use Illuminate\Http\Response;

class LlmsTxtController extends Controller
{
    public function __invoke(): Response
    {
        $file = resource_path('llms/site.md');
        abort_unless(is_file($file), 404);

        return response(file_get_contents($file), 200)
            ->withHeaders([
                'Content-Type' => 'text/plain; charset=UTF-8',
                'X-Content-Type-Options' => 'nosniff',
            ]);
    }
}

Laravelのresponse objectはstatusとheaderを指定できます。routeを追加したら、php artisan route:list --path=llms.txtで競合を確認し、route cacheを使う環境では再構築後の本番レスポンスも確認するのがおすすめです。

<?php
// tests/Feature/LlmsTxtTest.php の確認例
$this->get('/llms.txt')
    ->assertOk()
    ->assertHeader('Content-Type', 'text/plain; charset=UTF-8')
    ->assertSee('# Example Media', false);

Ruby on Railsへ実装する方法

Railsではpublic/llms.txtへ置く静的配置が最も小さな構成です。本番でpublic配下をWebサーバーやCDNから配信しているか確認します。内容をアプリ側で生成・更新する場合は、専用routeとcontrollerを使います。

# config/routes.rb
get '/llms.txt', to: 'llms_txt#show'

# app/controllers/llms_txt_controller.rb
class LlmsTxtController < ApplicationController
  def show
    file = Rails.root.join('config/llms.txt')

    render plain: file.read,
           content_type: 'text/plain; charset=utf-8'
  end
end

Rails公式ガイドのrender plain:は、レイアウトを付けずテキストを返します。公開後はresponse.media_typeがtext/plainになることと、通常のHTML layoutやエラーページが混ざらないことをrequest testで確認するのがおすすめです。

SinatraなどRuby系アプリへ実装する方法

Sinatraは既定のpublicディレクトリから静的ファイルを配信できます。動的に返す場合は、ほかのwildcard routeより前に/llms.txtのGET routeを置き、MIME typeを明示します。

get '/llms.txt' do
  content_type 'text/plain', charset: 'utf-8'
  headers 'X-Content-Type-Options' => 'nosniff'

  File.read(
    File.join(settings.root, 'config', 'llms.txt'),
    encoding: 'UTF-8'
  )
end

Rack系フレームワークでも考え方は同じです。専用のGET routeで200とtext/plainを返し、静的ファイル・Webサーバー・CDNと同じパスが競合していないか確認します。

公開前後のHTTP応答と競合をどう検証する？

設置前に競合をどう確認する？

curl -sS -D - https://example.com/llms.txt -o /tmp/example-llms.txt
sed -n '1,120p' /tmp/example-llms.txt

変更前に200、リダイレクト、404のどれか、レスポンスヘッダーと本文を保存します。200なら、実ファイル、プラグイン、テーマ、MUプラグイン、Webサーバー、CDNのどれが返しているかを特定してから編集します。

知らないHTTP 200レスポンスがある場合は、既存機能を管理している担当者、デプロイ経路、ロールバック方法を特定してから変更するのがおすすめです。

公開後のHTTPレスポンスを確認する

curl -sS -I https://example.com/llms.txt
curl -sS https://example.com/llms.txt | sed -n '1,120p'

Markdown版とリンク関係は必要？

v2は、通常ページの簡潔なMarkdown版と、HTMLのrel="alternate" type="text/markdown"、対象llms.txtへのrel="describedby"を提案しています。ただし、最小試験導入の必須条件ではありません。

<link rel="alternate" type="text/markdown" href="https://example.com/docs/start.md">
<link rel="describedby" href="https://example.com/llms.txt">

Markdown版を提供する場合は、HTMLと同じ正本から生成し、更新日、正規の扱い、内部リンク、アクセシビリティ、キャッシュをテストします。手作業で二重管理して内容がずれるなら、通常HTMLへリンクする小さな試験導入に留めます。

llms-full.txtも必要？

v2の提案仕様の中核 形式はllms.txtです。サイト全文を連結したllms-full.txtを提供する実装もありますが、すべてのサイトで必須ではありません。

巨大ファイルはコンテキスト、帯域、更新ずれ、削除漏れ、権限混在のリスクを増やします。まず厳選したllms.txtから必要ページへ進める構造を使い、全文ファイルは明確なクライアント要件、生成・削除・更新テストがある場合だけ検討します。

アクセスログとAI回答で効果をどう検証する？

アクセスログで何を確認する？

サーバー・CDN・ホスティングのアクセスログで、対象パスへのリクエストを抽出します。WordPressのアクセス解析だけではボット リクエストが除外される場合があります。検索流入側の変化は別系統のデータなので、Search ConsoleをAIで分析する方法の手順で設置前後を比べ、ログの取得件数と混同しないようにします。

ユーザーエージェント名だけで公式ボットと断定せず、サービスが公開する検証方法がある場合はIP・DNS等を照合します。ログの保存と分析はプライバシーポリシー・社内ルールに従ってください。

取得ログの記録表

ハッシュは配信内容のバージョン識別に使います。リクエスト本文やIPを記事へ公開せず、集計値と検証方法を残します。

リクエストがあれば効果ありと言える？

言えません。アクセスログが示すのは、あるクライアントがファイルをリクエストしたことまでです。次の段階を分けて記録します。

1. 配信できた      → HTTP 200・正しい本文
2. 取得された      → access log
3. linkをたどった  → linked pageの連続request（推測を含む）
4. 回答に使われた  → service側のcitation・再現test
5. 成果が出た      → qualified visit・conversion・support削減
6. 順位へ影響した  → 他施策を分けた長期検証が必要

2から4、4から6へ飛躍しません。クローラーが取得しても、インデックス、推論、順位に採用したかは外部から分からない場合があります。

AI回答でどう検証する？

同じ質問セット、同じサービス・モード、同じ地域・言語、同じ期間で、設置前後の回答を保存します。ただしAIサービスはモデル・検索インデックス・順位が同時に変わるため、llms.txtだけの因果を証明しにくいテストです。

• サイト名を含む事実質問
• 運営者・編集方針・更新日の質問
• 主要ガイドへのナビゲーション質問
• サイト名を含まない一般質問
• 存在しない情報を尋ねるnegative質問

回答、引用URL、取得日、サービス・モード、クエリを保存し、正確性を人が確認します。引用が増えても正確性や成果が悪化していないかを見ます。

更新と停止をどう運用する？

更新頻度はどう決める？

毎日自動で全記事を追加するより、代表ページやポリシーが変わったときに編集者がレビューします。月次または四半期の定期確認と、重大変更時の臨時更新を組み合わせます。

試験導入をやめる判断も用意する

• 更新担当者がおらず、古いURLや説明が残る
• 生成プラグインが非公開・下書き URLを除外できない
• 既存キャッシュ・プラグインとの競合を解消できない
• 保守コストが高く、HTML、sitemap、内部リンクの改善を圧迫する
• 一定期間のログと利用テストで、目的に対応する取得が確認できない

止める場合は、生成元を停止し、キャッシュをパージし、404または意図した代替レスポンスを確認します。llms.txtを止めても、正本のHTML、XML sitemap、内部リンク、構造化データ、編集・更新体制は継続します。

公開前チェックリスト

よくある質問

llms.txtは小さく置き、目的別に効果を測る

llms.txt v2は、サイトや特定パスの説明と厳選リンクをMarkdownで渡し、エージェントが必要な詳細へ進む入口を作る提案仕様です。robots.txt、XML sitemap、構造化データ、認証を置き換えません。

WordPressでは静的ファイル、既存プラグイン、MUプラグインから一つを選び、PHP、Laravel、Ruby on Rails、Sinatraでは静的配置または専用routeを選びます。HTTP 200、text/plain、正規URL、キャッシュを検証し、取得、回答利用、引用、成果を分けて記録するのがおすすめです。

公式・一次資料

• llms-txt: The /llms.txt file, v2
• AnswerDotAI/llms-txt GitHub repository
• Google Search Central：生成AI機能向け最適化ガイド（llms.txtの扱い）
• Google Search Central: Crawling and indexing
• Google Search Central: Build and submit a sitemap
• WordPress Developer Resources: Must Use Plugins
• PHP Manual: header
• PHP Manual: readfile
• Laravel Documentation: HTTP Responses
• Laravel Documentation: Routing
• Ruby on Rails Guides: Layouts and Rendering
• Ruby on Rails Guides: Getting Started
• Sinatra: README
• OpenAI Developers: llms.txt
• OpenAI Developers: Overview of OpenAI Crawlers