「llms.txtがありません」とAIに指摘された話
先日、ある企業サイトの構造化データを整備し、お客様へ納品しました。
JSON-LDを使い、企業情報やWebサイト、提供サービスの内容を検索エンジンなどが機械的に理解しやすい形へ整理する作業です。
実装後の検証も終え、ひとまず納品完了。
ところが、その後お客様から思いがけない連絡が入りました。
「Claudeでファクトチェックしたら、llms.txtがないと指摘されたんですが……」
なるほど。今度はお客様がAIを使って、こちらの納品物をチェックしてきたわけです。
これは面白い時代になったものです。
そもそもllms.txtは必要なのか？
llms.txtとは、AIエージェントなどがWebサイトの情報を参照する際に、主要なコンテンツや参照先を把握しやすくするために提案されているMarkdown形式のファイルです。
今回納品したJSON-LDとは、そもそも役割が異なります。
- JSON-LD：Webページに含まれる情報の意味や関係性を構造化して伝える
- llms.txt：Webサイト内の主要な情報や参照先を案内する
両者に直接的な依存関係はなく、llms.txtが存在しないからといってJSON-LDが正常に機能しなくなるわけではありません。
また、llms.txtはすべての検索エンジンやAIサービスが共通して利用する必須規格でもありません。
Googleも2026年6月の公式ドキュメント更新で、Google検索ではllms.txtを利用しておらず、設置の有無が検索結果の表示やランキングに影響しないことを明確にしています。
つまり、llms.txtがないことと、構造化データの実装が不完全であることは別問題なのです。
もっとも、AIエージェントがWebサイトを参照する仕組みは発展途上です。
将来的な利用や、対応するシステムへの情報提供を考えれば、llms.txtを用意すること自体に意味がないわけではありません。
「そこまでやらないと中途半端では？」
お客様との電話で、こんなお話になりました。
「気持ちとしては、そこまで対応しないと中途半端ではないか」
技術的に必須かどうかという話と、お客様が期待する完成形は必ずしも一致しません。
今回のご依頼は、Webサイトの情報を機械にも正しく伝わるように整備すること。
であれば、llms.txtも整備しておきたいという意向は理解できます。
そこで、既存のJSON-LDと情報の整合性を保ちながら、llms.txtも追加する方針にしました。
ただし、ファイルを一つ増やせば終わり、という話でもありません。
AI向けの情報が増えるほど、情報の整合性が重要になる
今回の対応で重視したのは、JSON-LDとllms.txtの間で矛盾する情報を出さないことでした。
例えば、同じ製品について、JSON-LDにはある説明が記載され、llms.txtには別の説明が記載されていたらどうでしょう。
人間なら前後の文脈から解釈できるかもしれませんが、機械がそれぞれの情報を参照したとき、どちらを正しい情報として扱うべきか判断が難しくなる可能性があります。
そこで今回は、製品名、サービス区分、説明文、URLなどを整理し、両方の出力で共通の情報を使用する設計にしました。
また、製品の実績を示す「No.1」といった広告表現についても、調査条件や根拠を伴わない形で機械向けの基本情報に含めることは避けました。
Webページ上の訴求表現は維持しながら、構造化データには確認可能な事実を優先して記述する。
人間向けの広告表現と、機械向けの情報整理を分けて考えたわけです。
llms.txtはWordPressから自動生成することに
今回のサイトはWordPressで運用されています。
単純にllms.txtを作成してサーバーへアップロードする方法もありますが、それでは新しいページが増えるたびにファイルの更新が必要になります。
そこで既存の独自プラグインを拡張し、WordPressからllms.txtを動的に生成する仕組みを追加しました。
主要ページや製品情報だけでなく、公開中の導入事例、ニュース、セミナー情報なども参照できる構成です。
さらに、テスト環境と本番環境のURLを自動的に切り替え、JSON-LDとllms.txtが共通の製品説明を使用するようにしました。
これなら、コンテンツの追加に応じて参照先の一覧も更新できます。
もちろん、llms.txtが自動生成されることと、AIが実際にそのファイルを利用することは別の話です。
重要なのは、必要な情報を一貫した形で管理できる仕組みにしておくことだと考えています。
そして、AI自身の説明にも勘違いがあった
実装後の本番確認では、もう一つ興味深い出来事がありました。
外部の検証環境からllms.txtを取得しようとしたところ、正常に内容を取得できませんでした。
さらにブラウザ操作を試した際、AIからはブラウザ機能が無効になっているという説明が返ってきました。
ところが実際の設定画面では有効になっています。
結果的には、ブラウザ接続サービスへの設定反映に一時的な問題があったようで、再読み込みとアプリの再起動後に正常に接続できました。
つまり、AIが返したエラーメッセージの解釈も、必ずしも正確ではなかったということです。
最終的には実際のブラウザから本番環境を確認し、llms.txtとJSON-LDの出力内容、URL、説明文の整合性まで検証できました。
AIが「取得できない」と返したからといって、Webサイト側に問題があるとは限りません。
これもAIを使った制作や検証で、気をつけたいところです。
AIが作り、AIがチェックし、AIが修正する
今回、最も興味深かったのは技術的な実装内容そのものではありません。
制作側がAIを活用して構造化データを整備する。
お客様が別のAIを使って納品物をチェックする。
そこで提示された改善案を制作側が再検討し、AIを活用して追加実装する。
さらに、AIを使って検証し、そのAIの判断まで人間が確認する。
そんな一連のやり取りが、特別なことではなくなりつつあります。
以前なら、お客様が構造化データの中身まで確認する機会は、それほど多くなかったかもしれません。
しかし今は、専門知識がなくてもAIに質問すれば、技術的な改善案を得られます。
これは発注側にとって大きな変化です。
一方で、AIが提示した改善案のすべてが、必須の対応とは限りません。
推奨事項、任意の仕様、将来への備え、単なる提案。
それらが同じような重みで提示されることもあります。
だからこそ制作側には、AIの回答をそのまま受け入れるのではなく、必要性や優先順位、実際の効果を判断する力が求められます。
これからの制作会社に必要なのは「AIに従うこと」ではない
AIの普及によって、Web制作における発注側と制作側の情報格差は確実に縮まりつつあります。
お客様が制作物の技術的な内容をAIで調べ、改善を求める。
そうしたやり取りは今後さらに増えるでしょう。
ただし、AIによる指摘をすべて実装することが、優れたWebサイト制作につながるとは限りません。
何を実装すべきか。
何を実装しなくてもよいのか。
何を将来への備えとして用意するのか。
その判断には、仕様の理解だけでなく、運用負荷や費用対効果、Webサイト本来の目的を見据えた設計が必要です。
AIは制作側だけの道具ではなくなりました。
お客様もAIを使う。
そして、お互いのAIが違うことを言い始める。
そんな場面で最後に必要になるのは、やはり人間の判断なのだと思います。
AIの回答を増やすことよりも、判断の質を高めること。
これからのWeb制作では、そんな役割がますます重要になるのかもしれません。
それにしても、自分たちがAIで作ったものを、お客様のAIにチェックされるとは。
なかなか面白い時代になりましたね。
