llms.txtの公開前チェックリスト｜記載内容・URL・更新体制を確認

llms.txtは、確認日（2026-07-31）時点でコミュニティへの意見募集が続く提案であり、Google検索の掲載に必要なファイルではありません。公開前は書式だけでなく、掲載URLの正確性、公開情報の安全性、複数の言語モデルで質問に答えられるか、担当者と更新手順まで確認し、根拠が弱い場合は公開を保留します。

llms.txtの公開前チェックリスト

公開の合否は、提案どおりの記載になっているか、元ページと矛盾がないか、質問テストを通過したか、公開後も責任を持って更新できるかで決めます。

llms.txtは、Jeremy Howard氏が2024年9月3日に公開したコミュニティ提案です。確認日（2026-07-31）時点でも意見募集が続いています。一方、Googleは、Google検索とその生成AI機能に表示されるために新しい機械可読ファイルやAI向けテキストファイルを作る必要はなく、Google検索自体はそれらを使わないと説明しています。

したがって、公開目的を「Google検索での順位や表示を改善するため」としている場合は、前提から見直しが必要です。ただし、Googleはllms.txtを作ると順位が下がる、またはペナルティになるとは述べていません。公開するかどうかは、未確認の効果ではなく、サイト内の重要情報を案内する補助ファイルとして正確に保守できるかで判断します。

確認領域	合格条件	主担当	残す証跡
目的	提案の試行であり、検索表示を保証しないと共有済み	Web責任者	目的・非目的の承認記録
記載内容	H1、任意要素、リンクの形式を正しく区別	制作担当	書式チェック表
URL	正規URLへ到達し、説明が元ページと一致	ページ所有者	URL台帳と確認日
情報安全	公開可能な確定情報だけを掲載	情報管理担当	公開範囲の承認記録
実用性	展開後の内容を使い、複数の言語モデルで質問を検証	検証担当	質問、回答、判定結果
運用	更新契機、更新者、承認者、緊急時の削除手順が明確	運用責任者	更新手順と引継ぎ先

一つでも重大な不一致があれば公開を保留します。ファイルの作成から設置までの詳しい手順ではなく、ここでは公開前に誰が何を確認し、どの証跡で合否を決めるかに絞ります。

開始前の確認項目

開始前は、llms.txtで解決したい情報整理の課題と、解決できない検索課題を切り分けられていれば合格です。

まず、誰のどの質問に対して、どの公開ページを案内したいのかを一文で定めます。「AI対策をする」のような広い目標では、掲載URLの選定理由も公開後の評価方法も決まりません。たとえば「導入条件を尋ねる見込み客へ、現行の対象条件ページを案内する」のように、質問、読者、根拠ページまで具体化します。

Google検索を対象にする場合は、llms.txtとは別に検索基盤を確認します。Googleの生成AI機能で表示対象になり得るには、ページがインデックス登録され、通常の検索結果でスニペット表示の対象になり得ることが前提です。さらに、サイトがSearch Console上でGoogle検索の生成AI機能の対象に含まれている必要があります。llms.txtの公開は、これらの代わりになりません。

• 目的と対象読者を一文で説明できる
• 想定質問ごとに、現行の公式回答となるページがある
• 表示、引用、順位、流入の向上を成果として保証していない
• robots.txt、サイトマップ、クロール、インデックスの確認を別管理にしている
• Google以外のAIサービスがllms.txtを利用するとは断定していない
• 掲載候補がない質問は、llms.txtへ説明を足す前に元ページの改善対象としている

Google検索の生成AI機能に構造化データは必須ではなく、特別なschema.orgマークアップも必要ありません。ただし、構造化データはGoogle検索のリッチリザルトの対象になり得るため、通常のSEO施策の一部として継続する価値があります。llms.txtの検討を理由に削除せず、読者に見える本文との一致を保ちます。

体制と責任者の確認項目

体制は、ファイル編集者、掲載先ページの所有者、公開承認者、緊急時の対応者が特定され、代理担当まで引き継げる状態なら合格です。

専任部門がない企業では、一人が複数の役割を兼ねても構いません。ただし、役割そのものを省略すると、URLは開くが内容が古い、担当者の異動後に修正できない、といった状態を見逃します。担当者名だけでなく、何を判断する役割かを記録します。

役割	判断すること	成果物	確認方法
Web責任者	試行目的、公開可否、停止判断	公開判定記録	全項目の差し戻し有無を確認
制作担当	記載順、見出し、リンク形式	llms.txt本体	書式チェック表と照合
ページ所有者	説明、条件、用語が現行か	承認済みURL台帳	元ページを目視確認
SEO担当	クロール、インデックス、スニペット適格性	検索基盤の記録	Search Console等で確認
情報管理担当	機密、個人情報、公開範囲	安全確認記録	掲載文とリンク先を確認
運用責任者	更新契機、代理担当、緊急削除	運用・引継ぎ手順	変更時の連絡経路を確認

URLの統合、ページの削除、サービス条件の変更、公開範囲の変更を誰が検知し、誰へ連絡するかも決めます。提案には更新頻度の数値基準がないため、根拠のない固定頻度を正解として採用しません。自社の変更管理に合わせて確認契機を定め、実施日と判断理由を残します。

記載内容とフォーマットの確認項目

記載内容は、唯一の必須要素であるH1と任意要素を取り違えず、定められた順序とリンク形式を確認できれば合格です。

llms.txtは通常、サイトのルートパス/llms.txtに置く提案ですが、サブパスも任意の配置先として示されています。ファイル内の要素には順序があり、必須なのはサイト名またはプロジェクト名を示すH1だけです。ブロック引用、詳細説明、H2で区切るファイル一覧を必須扱いしないよう注意します。

順序	要素	必須・任意	公開前の確認
先頭	BOM	任意	意図せず表示や処理を乱していない
次	サイト名・プロジェクト名のH1	必須	H1が存在し、名称が正しい
次	短い概要のブロック引用	任意	後続内容の理解に必要な要点だけか
次	見出し以外の詳細説明	任意	曖昧語や未説明の専門用語がない
次	H2とファイル一覧	任意	分類名と掲載URLの関係が明確か

ファイル一覧の各項目には、Markdown形式のハイパーリンク[name](url)が必要です。コロンに続く注記は任意ですが、付ける場合はリンク先の内容を簡潔かつ具体的に説明します。URLだけでは選定理由が分からず、誇張した説明では元ページと食い違うため、名称、URL、注記を一組で照合します。

「Optional」というH2には特別な意味があります。この節に置いたURLは、短いコンテキストが必要な場合に省略できる二次情報として扱われます。単に「任意」という日本語の感覚で章名を付けず、本当に省略可能な情報だけを分けます。

提案には、LLMが読む可能性のあるページについて、元のURLに.mdを付けたクリーンなMarkdown版を同じURL体系で用意する考えも併記されています。ファイル名のないURLではindex.html.mdを付ける形です。採用する場合は、HTML版とMarkdown版の内容、公開範囲、更新責任が一致するかを確認します。

掲載URLと元ページの確認項目

掲載URLは、公開中の正規URLへ到達でき、注記と元ページの本文が一致し、質問への回答箇所を特定できれば合格です。

URLを増やすこと自体は品質になりません。提案には推奨URL数やファイルサイズの数値上限がないため、独自の上限を公式要件のように扱わず、質問へ答えるために必要かどうかで選びます。外部URLを含める場合も、なぜサイトの理解に必要なのかを説明できるものに限ります。

確認項目	合格条件	不合格時の対応	証跡
到達性	URLが正常に開き、公開範囲が想定どおり	修正まで掲載しない	応答確認日
正規性	重複URLではなく管理対象の正規URL	正規URLへ統一	URL台帳
現行性	終了条件や古い説明が残っていない	元ページを更新または除外	所有者の承認
説明の一致	リンク注記が本文の範囲を超えない	注記を修正	照合箇所
回答可能性	想定質問へ自己完結して答える箇所がある	元ページを改善	見出し・段落名
更新可能性	変更元と連絡先を追跡できる	所有者を決めるまで保留	更新担当

元ページを正本とし、llms.txtだけに価格、条件、対象者などの重要事項を書き足しません。複数ページを読まなければ回答できない場合は、案内文でつなぎ合わせる前に、読者向けページの情報設計を見直します。

データ・セキュリティの確認項目

データ面は、llms.txt本体とすべてのリンク先が公開可能な確定情報だけで構成され、アクセス制御と案内機能を混同していなければ合格です。

llms.txtは公開ファイルとして扱います。社内資料の要約、個人情報、顧客別情報、認証後のページ、未発表の計画、推測を含む将来情報は掲載しません。公開URLであっても、クエリ文字列やファイル名から機密情報が推測できないか、ページ内に期限切れ条件がないかまで確認します。

対象	確認するリスク	合格条件	問題がある場合
llms.txt本文	非公開情報の要約、未承認表現	公開済み事実と一致	該当記述を削除
掲載URL	認証、限定公開、個人情報	誰でも閲覧できる承認済みページ	掲載対象から外す
注記	元ページを超える断定	本文で確認できる範囲	表現を限定
.md版	HTML版との不一致、更新漏れ	同じ正本から再生成・照合可能	公開を保留
削除手順	緊急時に担当不明	連絡先と反映方法が明確	責任者を設定

robots.txtは自動化ツールに許容するアクセスを伝える用途があり、llms.txtはその代替となるアクセス制御手段ではありません。掲載してよい情報かどうかは、別途の公開承認で判断します。

実行中の確認項目：LLMに実際に質問して検証する

実行中は、llms.txtをコンテキスト用ファイルへ展開し、複数の言語モデルが想定質問へ根拠どおりに答えられるかを試せば合格判定に進めます。

llmstxt.orgの作成指針には、簡潔で明確な言葉を使うこと、リンクに短く有益な説明を付けること、曖昧語や未説明の専門用語を避けることに加え、展開ツールを実行して複数の言語モデルへ質問する検証が挙げられています。書式チェッカーでエラーがないだけでは、質問に答えられるかは分かりません。

記録項目	記載例	合格の見方
想定質問	サービスの対象外条件は何か	読者の判断に直結する具体的な質問
期待する根拠	対象条件ページの該当見出し	元ページで承認済み
使用した入力	Optional節を除く／含む展開結果	入力範囲を再現できる
モデル別回答	回答本文と参照した箇所	根拠外の補完や矛盾がない
判定	合格、修正、掲載除外	理由と確認者が残る

モデルごとに回答が異なる場合は、良い回答だけを採用して合格にしません。注記が曖昧なのか、根拠ページに答えがないのか、Optional節へ重要情報を置いているのかを切り分けます。原因が元ページにあるなら元ページを修正し、再び展開して同じ質問を試します。

このテストは、外部サービスによる掲載や引用の保証ではありません。確認できるのは、指定した入力と質問の条件下で、用意した情報から回答できたかどうかです。使用環境、入力範囲、質問、回答、確認日を残し、未確認の一般効果へ広げないようにします。

成果物と公開可否の確認項目

成果物は、ファイル本体だけでなく、URL台帳、質問テスト、承認記録、更新手順がそろい、重大な未解決事項がなければ公開可能です。

最終レビューでは、制作担当者の自己確認だけで終わらせません。ページ所有者が内容を、情報管理担当が公開範囲を、Web責任者が目的と運用可能性を確認します。Google検索への表示保証や、未確認の他社AIサービスの対応状況が残っていれば差し戻します。

• llms.txt本体：H1、任意要素、順序、リンク形式を確認済み
• 掲載URL台帳：質問、URL、注記、所有者、確認日を記録済み
• 内容照合記録：元ページ内の回答箇所と承認者を特定済み
• 質問テスト記録：展開条件、複数モデルの回答、判定を保存済み
• 安全確認記録：機密、個人情報、未発表情報がないことを確認済み
• 更新手順：変更契機、担当者、代理担当、緊急削除の経路が明確
• 公開判定：合格、条件付き保留、保留のいずれかと理由を記録済み

条件付き保留は、修正内容と再確認者が明確な場合に限ります。責任者不在、根拠ページなし、公開範囲の疑義、重大な内容不一致は、そのまま公開せず保留とします。

ラクダ式：質問・根拠・問い合わせの対応表で合否を決める

ラクダ式では、検索質問、根拠ページ、引用候補箇所、実際の問い合わせを一行で結び、情報不足と更新の優先順位を判断します。

単なるURL一覧では、なぜ掲載したのか、どの質問に答えるのかが残りません。営業やサポートに届いた問い合わせは個人を特定できない形で論点だけを整理し、根拠ページの不足を見つける材料にします。「引用候補箇所」は外部の引用を指定するものではなく、自社が回答の自己完結性を点検するための欄です。

検索質問	根拠ページ	引用候補箇所	問い合わせとの照合	判断
誰が利用対象か	対象条件ページ	対象・対象外の段落	対象外からの相談があるか	維持・修正
導入前に何が必要か	準備事項ページ	必要情報の一覧	準備不足の質問があるか	追加・修正
変更時は何を確認するか	更新案内ページ	変更点と適用条件	古い条件への質問があるか	差し替え・削除

問い合わせが繰り返されるのに根拠ページがなければ、llms.txtの注記だけで回答を作らず、読者向けページの新設または更新を検討します。根拠ページがあるのに回答箇所が曖昧なら、ページ所有者へ改善を依頼します。こうしてファイルの整備を、元ページの品質管理へつなげます。

継続判断の確認項目

継続は、掲載URLを現行に保ち、質問テストと承認を変更時に再実施できる場合に選び、保守できない場合は対象削減または公開停止を選びます。

提案には更新頻度の数値指定がありません。サービス条件の変更、URLの統合・削除、組織変更、公開範囲の変更、元ページの大幅改稿など、自社の変更契機に連動させます。定期確認を設ける場合も、全社共通の固定値を正解とせず、更新リスクと運用能力に応じて決めます。

• 維持：URL、注記、回答箇所、担当者が現行
• 修正：元ページと注記に不一致がある
• 追加：重要な質問に答える承認済みページができた
• 削除：終了ページ、重複ページ、根拠として弱いページがある
• 再テスト：展開方法、掲載範囲、重要ページの内容が変わった
• 公開停止：更新責任者が不在、または安全性を確認できない

Google検索については、llms.txtの有無より、クロール可能性、インデックス、スニペット適格性、独自で役立つ本文を優先します。構造化データを使っている場合は、生成AI検索のための必須要件ではなくても、リッチリザルトを含む通常のSEO施策として本文との一致を保ちます。周辺施策を整理する際は、AI関連記事一覧も参照できます。

よくある質問

llms.txtの公開前に生じやすい疑問へ、判断基準と必要な証跡を簡潔に答えます。

Q1. llms.txtはGoogle検索の生成AI機能に表示されるために必須ですか？

必須ではありません。Googleは、新しい機械可読ファイルやAI向けテキストファイルを作る必要はなく、Google検索自体はそれらを使わないと説明しています。対象ページのインデックスとスニペット適格性などを別に確認し、検索基盤の記録を残してください。

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

提案上の必須要素は、サイト名またはプロジェクト名を記すH1だけです。ブロック引用、詳細説明、H2で区切るファイル一覧は任意です。ファイル一覧を設ける場合は各項目に[name](url)形式のリンクが必要で、コロン以降の注記は任意です。

Q3. 書式チェッカーで問題がなければ公開できますか？

書式確認だけでは不十分です。元ページとの一致、公開範囲、リンクの到達性、更新責任を確認したうえで、展開したコンテキストを複数の言語モデルへ与え、想定質問に根拠どおり答えられるかを試します。質問、入力範囲、回答、判定を証跡として残します。

Q4. 公開後はどのタイミングで見直しますか？

提案に固定の更新頻度は示されていません。ページの削除・統合、サービス条件の変更、担当者の異動、公開範囲の変更など、自社で定めた更新契機に合わせて見直します。確認日、変更理由、対象URL、承認者を記録し、保守できない場合は対象削減や公開停止を判断します。

まとめ

llms.txtは、Jeremy Howard氏が2024年9月3日に公開し、確認日（2026-07-31）時点でも意見募集が続くコミュニティ提案です。Google検索とその生成AI機能への表示に必要なファイルではなく、Google検索自体は使わないと説明されています。一方で、作成による順位低下やペナルティが示されているわけでもありません。

公開するなら、必須のH1と任意要素を正しく区別し、[name](url)形式、Optional節の意味、掲載URLと元ページの一致、公開情報の安全性を確認します。さらに、展開したコンテキストを使って複数の言語モデルへ想定質問を行い、根拠どおり答えられるかを検証します。ファイル本体、URL台帳、質問テスト、承認記録、更新手順がそろわない場合は公開を保留し、読者向けページと検索基盤の整備を優先してください。

参考資料

• llmstxt.org「The /llms.txt file」
• Google Search Central「Google検索の生成AI機能向け最適化ガイド」