llms.txtの作り方｜掲載URLの選び方と更新手順

llms.txtは、掲載目的と想定質問を決め、根拠になる公開URLを選び、仕様の順序でMarkdownを作成して設置し、複数のLLMで回答を試すところまでが一連の手順です。検索順位への効果は前提にせず、内容責任者・Web担当者・承認者を決め、元ページの変更に合わせて更新します。

llms.txtの作り方

llms.txtは「目的を決める→URLを選ぶ→Optionalへ仕分ける→作成・設置する→複数のLLMで質問する→更新する」の順で進めます。

最初にファイルを書き始めるのではなく、「誰のどの質問に答える案内を作るのか」を決めることが重要です。法人向けサービスのサイトなら、意思決定に必要な質問を起点にし、各質問に対して、現在公開され、責任者が内容を管理できるページを結び付けます。

作業は次の流れで進めます。公開して終わりにせず、複数のLLMで確かめるところまでを一続きの業務にしてください。

段階	主な入力	作業	成果物
企画	想定読者、質問、採用目的	対象範囲と非目的を決める	実施方針
選定	公開ページ一覧	質問と根拠URLを対応付ける	URL台帳
仕分け	URL台帳	中心情報と省略可能な情報を分ける	掲載判断表
作成・設置	掲載判断表	提案の構成順で記述し公開する	llms.txt
検証	展開したコンテキスト	複数のLLMへ同じ質問をする	質問テスト記録
更新	ページ変更、テスト結果	元ページと案内をそろえる	変更・承認記録

llms.txtの定義や既存ファイルとの違いを詳しく知りたい場合は「llms.txtとは？役割・書き方・運用上の注意点」、公開直前の確認項目を網羅したい場合は「llms.txtの公開前チェックリスト｜記載内容・URL・更新体制を確認」がそれぞれの役割で、いずれもAI関連記事一覧から辿れます。本記事では、実際に作る順序と判断方法に絞ります。

始める前に確認すること：提案仕様としての位置づけ

開始前には、llms.txtを検索表示の保証策ではなく、重要情報を案内して回答可能性を試すための提案として扱うと関係者で合意します。

llms.txtはJeremy Howard氏が2024年9月3日に公開した提案です。確認日（2026-07-31）時点でもコミュニティから意見を受け付ける段階であり、確立済みの規格やウェブ標準ではありません。提案元も、ファイルを各アプリケーションがどう処理するかは用途によるとしており、特定のAIサービスが自動的に読むとは定めていません。加えて、どのAIサービスが実際にllms.txtを読んでいるかを示す公式の表明も、確認日時点で確認できていません。他社サービスが読んでいる前提で期待値を置かず、自社で確認できる範囲を判断材料にしてください。

Google検索については、さらに切り分けが必要です。Googleは、Google検索とその生成AI機能に表示されるために新しい機械可読ファイルやAI向けテキストファイルを作る必要はなく、Google検索自体はそれらを使わないと説明しています。加えて、Google検索については、llms.txtのような不要なAI向けテキストファイルの作成を、無視してよい施策の例として挙げています。したがって、「llms.txtを置けばGoogleに評価される」とは言えません。一方、設置すると順位が下がる、またはペナルティになるとも述べていません。

それでも作る意味があるとすれば、自社の重要な公開情報を整理して案内し、展開したコンテキストを使って複数のLLMが想定質問へ答えられるかを自社で検証できる点です。Google検索への効果ではなく、公開情報と想定質問の対応を検証できる業務にする価値があるかを、着手判断の根拠にしてください。

Google検索の生成AI機能では、通常のSEO基盤を別に管理します。構造化データは生成AI検索のために必須ではなく、特別なschema.orgマークアップも必要ありません。ただし、Googleは、リッチリザルトの対象となるために通常のSEO施策の一部として構造化データを続ける価値があるとも説明しています。「生成AI検索に必須ではない」だけを切り出して、既存の構造化データを外さないでください。

開始前に決めること	決定例	避ける前提
対象読者	導入条件を確認する法人担当者	すべてのAI利用者
想定質問	対象企業、提供範囲、利用条件	「AIに評価されたい」のみ
採用目的	公開情報を整理し、複数LLMで回答可能性を検証する	順位・表示・引用の保証
非目的	Google検索の技術要件を代替しない	SEO作業の置き換え
完了条件	設置後の取得と複数LLMの質問テストまで	ファイルを置くだけ

llms.txtの作業計画には、通常のクロール、インデックス、本文品質の改善を混ぜず、別の担当・成果物として置くと判断がぶれません。

担当者と役割分担を決める

専任AI部門がない企業では、内容、制作、技術、検証、承認の役割を明文化し、兼務する場合も判断責任を分けます。

llms.txtの内容は、Web担当者だけでは正しさを判断できません。サービス条件は事業部、会社情報は管理部門、技術的な設置はWeb担当者というように、元ページを管理する人を巻き込みます。最低限、作成者と公開承認者を分け、変更時の連絡先を残してください。

役割	主な判断・作業	成果物	兼務時の注意
実施責任者	目的、対象範囲、継続・停止	実施方針	効果保証を目的にしない
内容責任者	質問と根拠ページの一致	質問・URL対応表	ページごとに所有者を特定
制作担当	Markdownの構成と注記	llms.txt原稿	元ページにない説明を足さない
Web担当者	設置、取得、変更反映	公開ファイル、取得記録	キャッシュを含めて確認
検証担当	入力の作り分けとLLM質問テスト	回答・判定記録	良い回答だけを選ばない
承認者	公開、修正、削除の決定	承認・変更ログ	作成者の自己承認にしない

担当者名だけでなく、異動や休職時の代理担当と、緊急時にファイルを差し替えられる経路も決めます。提案元は更新頻度の数値を示していないため、根拠のない固定間隔を採用せず、元ページの変更を検知できる体制を先に作ります。

手順1：掲載候補URLを洗い出す

掲載候補はサイトマップから機械的に全件選ぶのではなく、想定質問へ直接答える公開ページを質問単位で洗い出します。

まず、読者が自社について確認したい具体的な質問を一行ずつ書きます。次に、各質問の正式な回答となるページ、本文内の回答箇所、ページ所有者、最終確認日を記録します。価格、条件、対象者などの重要事項はllms.txtの注記だけに書き足さず、元ページに明記されていることを確認してください。

候補にできるのは、誰でも閲覧でき、内容が現行で、更新責任者がいるページです。認証後の資料、顧客固有の情報、未発表情報、個人情報、終了済みの条件を含むページは対象外とし、似た内容のURLは管理対象の正規URLへそろえます。

想定質問	候補ページ	回答箇所	掲載判断
どの企業が対象か	対象条件ページ	対象・対象外の説明	中心情報として候補
何を提供するか	サービス詳細	提供範囲の説明	中心情報として候補
どのような会社か	会社概要	運営主体の説明	中心情報として候補
補足資料はあるか	用語集や関連資料	補足説明	Optional候補
終了した条件は何か	古い告知	現行回答ではない	掲載しない

ページ本文に答えがなく、複数ページをつなぎ合わせないと説明できない質問は、llms.txtで取り繕わないようにします。元ページの改善候補として別に記録し、回答できるページが公開・承認されてから掲載候補へ戻します。

ラクダの業務診断・実装では、問い合わせ内容を「対象企業」「提供範囲」「導入条件」などに分類し、その分類を想定質問の台帳へ結び付けます。問い合わせがあるのに対応する公開ページがない場合も、元ページの改善候補として扱います。

手順2：Optional節の意味を使って掲載URLを仕分ける

掲載件数の独自目安ではなく、「短いコンテキストで省略しても主要質問へ答えられるか」を基準に通常のH2とOptional節へ分けます。

提案上、「Optional」というH2には特別な意味があります。この節に含めたURLは、短いコンテキストが必要な場合に省略できる二次情報として扱われます。Optionalは「読んでほしくない」「クロールを拒否する」という指定ではありません。アクセス制御や公開範囲の設定には使えないため、機密ページをOptionalへ移して公開することはできません。

仕分けでは、Optionalを除いた状態で中心質問に答えられるかを確認します。対象条件や提供範囲など回答に不可欠なページは通常のH2へ、事例の補足や周辺用語など省略しても中心的な理解を損ねにくいものはOptionalへ置きます。

判断質問	通常のH2へ置く	Optionalへ置く	掲載しない
主要な質問への回答に必要か	必要	なくても回答可能	回答に関係しない
現在の正式情報か	正式かつ現行	正式かつ現行	古い・根拠が弱い
短いコンテキストで省略できるか	省略しにくい	省略できる	そもそも不要
公開範囲に問題がないか	公開可能	公開可能	非公開・要認証
更新責任者がいるか	いる	いる	不在

提案元には、掲載URL数やファイルサイズの数値上限は示されていません。「何件まで」を先に決めるのではなく、質問と根拠の対応、Optionalを除いたときの回答可能性、更新可能性で絞り込んでください。

手順3：仕様の構成要素に沿ってファイルを作成する

ファイルは、任意のBOM、必須のH1、任意の要約・詳細、任意のH2別file listという順序で、簡潔なMarkdownとして作成します。

提案上、唯一の必須要素はサイト名またはプロジェクト名を示すH1で、ほかの要素は任意ですが、採用する場合は示された順序に従います。file listの各項目ではMarkdownリンクが必須で、コロンに続く注記は任意です。

順序	要素	必須・任意	書き方
1	BOM	任意	使用環境の方針に従う
2	H1	必須	サイト名またはプロジェクト名
3	blockquote	任意	後続理解に必要な短い要約
4	見出し以外の詳細	任意	解釈に必要な補足
5	H2別のfile list	任意	分類ごとの説明付きリンク

原稿は次の要領で組み立てます。最初の行に# サイト名を置き、必要なら次に> サイトの対象者と提供内容の短い要約を置きます。その後、必要な補足を見出しなしで記載し、## サービスなどのH2の下へ- [ページ名](https://example.com/page/): このページで確認できる内容という形式でリンクを並べます。省略可能な二次情報は## Optionalの下へ分けます。

文章は短く明確にし、リンクには内容が分かる簡潔な説明を付け、曖昧語や未説明の専門用語を避けます。注記は元ページの範囲内に限定し、「業界最高」「必ず成果が出る」など、ページで裏付けられない表現を追加しないでください。

提案には、LLMが読むのに役立つページについて、元のURLへ.mdを付けたクリーンなMarkdown版を用意する考えも併記されています。ファイル名のないURLはindex.html.mdを付ける形です。ただし、これも任意の提案であり、Google検索への掲載要件ではありません。採用するならHTML版と同じ正本から生成し、更新差分が生じない方法を決めます。

手順4：ルートに設置して取得できることを確認する

完成したファイルは基本となるルートパス/llms.txtへ設置し、外部から取得でき、内容とリンク先が原稿どおりであることを確認します。

提案はルートパス/llms.txtを基本とし、サブパスへの配置も任意で認めています。CMSの固定ページで似たURLを作るだけではなく、意図したパスでファイルを返せるかをWeb担当者が確認します。

設置後は、ブラウザとHTTP取得の両方で確かめ、公開環境の内容と承認済み原稿に差分がないことを記録します。

確認対象	確認方法	合格条件	問題時の対応
配置URL	/llms.txtへ直接アクセス	意図したファイルを取得できる	配置・配信設定を修正
本文	承認済み原稿と照合	見出し、説明、URLが一致	正しい版へ差し替え
文字	複数環境で表示	文字化けがない	文字コード・配信を確認
リンク	各URLへアクセス	正規の公開ページへ到達	修正または掲載除外
キャッシュ	更新後に再取得	最新版が返る	キャッシュを更新

llms.txtはrobots.txtの代わりではなく、クロールの許可・拒否を制御する手段ではありません。設置確認をもってGoogle検索や他社AIサービスへの掲載確認としないようにします。

手順5：ツールで展開し複数のLLMに質問して検証する

設置後はllms.txtをコンテキスト用ファイルへ展開し、Optionalを除く版と含む版を使って複数のLLMへ同じ質問を行います。

llmstxt.orgは作成時の指針として、llms.txtをLLMコンテキストファイルへ展開するツールを実行し、複数の言語モデルへ質問して、自社コンテンツについて答えられるか確認することを挙げています。ファイルが表示できたことや、Markdownの構文に問題がないことだけでは、想定用途で答えられるかは分かりません。

提案の指針として書かれているのはこの検証までで、入力を2種類作る点は提案元が実例として挙げるFastHTMLの実装に倣ったものです。FastHTMLはllms_txt2ctxというコマンドラインツールで、optionalのURLを含まないllms-ctx.txtと、含むllms-ctx-full.txtの2ファイルへ展開しています。

検証担当者は、URL選定時に作った想定質問をそのまま使います。各質問について、期待する根拠ページと回答箇所を先に固定し、Optionalを除いた入力と含めた入力をそれぞれ作ります。複数のLLMへ同じ条件で質問し、回答が根拠内に収まるか、必要な条件を落としていないか、存在しない内容を補っていないかを比べます。

記録項目	記録する内容	判定の観点
質問	読者の判断に直結する具体的な問い	URL選定時の質問と同じか
期待する根拠	ページ名と回答箇所	承認済み本文に存在するか
入力範囲	使用ツール、Optionalを除く版・含む版	再現できるか
使用環境	モデル名、実行日、設定	比較条件を説明できるか
回答	モデルごとの全文と参照箇所	根拠外の補完がないか
判定	合格、修正、掲載除外	理由と確認者が明確か

一つのLLMだけが正しく答えた場合や、Optionalを含めないと中心質問へ答えられない場合は、そのまま合格にしません。リンク注記が曖昧なのか、重要ページをOptionalへ誤分類したのか、元ページの回答が不足しているのかを切り分けます。修正後はコンテキストを再展開し、同じ質問を再実行します。

このテストで確認できるのは、指定した入力と質問の条件下で回答できたかどうかです。外部のAI検索に掲載されること、引用や流入が増えること、上位表示されることを実証する試験ではありません。

手順6：公開後の確認と更新体制を決める

公開後は固定頻度を正解とせず、元ページ、URL、担当者、展開方法が変わる契機に合わせて更新と再テストを行います。

更新の正本は元ページです。価格や条件などが変わったら、llms.txtの説明だけを先に直すのではなく、元ページの更新と承認を完了してから案内をそろえます。

更新契機	主担当	実施すること	残す記録
元ページの内容変更	ページ所有者	注記と回答箇所を照合	変更日、対象URL
URLの統合・削除	Web担当者	リンクを差し替え・削除	旧URL、新URL
新しい重要質問	内容責任者	根拠ページを確認して追加判断	質問、選定理由
担当者の変更	実施責任者	所有者と代理担当を更新	引継ぎ記録
掲載範囲の変更	情報管理担当	公開可否を再承認	承認者、判断理由
展開方法・入力の変更	検証担当	複数LLMで再テスト	入力、回答、判定

保守できないURLは減らし、責任者が不在になった場合や公開範囲を確認できない場合は、対象削減または公開停止を判断します。提案元に更新頻度の数値指定はないため、自社の変更管理と連動する運用を文書化してください。

成果物と実施計画をまとめる

実施計画はllms.txt本体だけでなく、URL選定、質問テスト、公開承認、更新方法を再現できる一組の成果物としてまとめます。

経営者や導入責任者が承認する際は、「ファイルを作ったか」だけでなく、「何のために、誰が、どの情報を選び、何をもって検証したか」を確認します。これにより、担当者が変わっても、掲載理由と更新判断を追跡できます。

成果物	含める内容	完了条件
実施方針	対象読者、質問、目的、非目的	承認者が前提を確認済み
URL台帳	質問、正規URL、回答箇所、所有者	全掲載URLに根拠がある
掲載判断表	通常H2、Optional、除外の理由	仕分けを再現できる
llms.txt本体	H1、任意要素、file list	承認版と公開版が一致
取得記録	配置URL、確認日、リンク結果	外部から最新版を取得可能
質問テスト	入力範囲、複数LLMの回答、判定	中心質問を根拠内で回答
変更・承認ログ	変更理由、担当者、承認者	更新経路が明確

まず対象質問と担当者を決め、次にURL台帳と掲載判断表を作り、その後に制作・設置へ進みます。技術作業だけを先行させないことで、掲載URLの根拠と公開後の責任を残せます。

よくある質問

llms.txtの作成時に迷いやすい位置づけ、掲載URL、必須要素、検証方法について簡潔に答えます。

Q1. llms.txtはGoogle検索のために作る必要がありますか？

必要ありません。Googleは、Google検索とその生成AI機能への掲載に新しいAI向けテキストファイルは不要で、Google検索自体も使わないと説明し、その作成を無視してよい施策の例に挙げています。ただし、作成が順位低下やペナルティにつながるとも述べていません。Google向けには、クロール、インデックス、本文品質を別の作業として管理します。

Q2. 掲載URLは何件までに絞ればよいですか？

提案元は掲載URL数やファイルサイズの数値上限を示していません。想定質問へ答えるために必要か、正式で現行のページか、更新責任者がいるかで選びます。短いコンテキストで省略しても中心質問へ答えられるページはOptionalへ分けます。

Q3. llms.txtで必須の記載要素は何ですか？

唯一の必須要素は、サイト名またはプロジェクト名を示すH1です。BOM、ブロック引用の要約、見出し以外の詳細、H2で区切ったfile listは任意です。file listを設ける場合、各項目のMarkdownリンクは必須で、コロンに続く注記は任意です。

Q4. 作成後はどのように検証しますか？

llms.txtをツールでコンテキスト用ファイルへ展開し、Optionalを除く版と含む版を用意して、複数のLLMへ同じ想定質問をします。根拠どおり答えられるかを比較し、入力範囲、モデル、質問、回答、判定、確認日を残します。この試験は検索表示や引用増加の保証ではありません。

まとめ

llms.txtの作成は、検索質問と根拠ページを結び付け、Optionalの意味で情報を仕分け、仕様の順序でMarkdownを作り、設置後に複数のLLMへ質問するところまでを一つの業務として進めます。

確認日（2026-07-31）時点で、llms.txtはJeremy Howard氏が公開した提案であり、確立済みの規格ではありません。Google検索はllms.txtを使わないと明記しているため、検索順位や表示の効果を前提にせず、通常のSEO基盤と分けて扱います。どのAIサービスが読んでいるかを示す公式表明も確認できていないため、期待値ではなく自社の検証結果で判断します。

専任AI部門がない企業では、内容責任者、Web担当者、検証担当者、承認者を決め、URL台帳、掲載判断表、取得記録、質問テスト、変更ログを残してください。元ページの変更を起点に案内を更新し、保守できない場合はURLの削減または公開停止を選ぶことが、実行可能な運用につながります。

参考資料

• llmstxt.org「The /llms.txt file」
• Google 検索セントラルのAI機能向け最適化ガイド（英語版・Last updated 2026-07-10 UTC）