llms.txtだけでは足りない理由。SEJ論考が説く「知識設計」の要点

結論

llms.txtやMCPなど新しいAI向けプロトコルを追加しても、商品比較や条件判断に必要な情報が元々欠けていれば解決しません。

Search Engine JournalのBill Hunt氏は、AI検索対応の議論が「どの形式で公開するか」に偏りすぎていると指摘します。 llms.txt（AIクローラーにサイト構造を伝えるテキストファイル）もMCP（AIエージェントとシステムを接続する規格）も、 情報を運ぶ手段にすぎず、元の情報が不完全なら同じ欠落を別の形式で公開するだけだと述べています。 日本のサイト運営者にとっては、新しい規格が出るたびに反応するより、商品・サービス情報の一元管理を先に整える方が効果的です。

影響を受けるページ・クエリ

影響を受けやすいのは、比較や条件判断を伴う商品ページ・サービスページです。 「ベスト」「おすすめ」「〜向け」といった、複数条件を満たすかどうかで結論が変わるクエリが該当します。 元記事は「家族向けの海辺のリゾートでベストな物件」という例を挙げ、 ビーチアクセス・家族向け設備・部屋タイプ・価格・口コミなど複数条件をAIが総合判断すると説明しています。

逆に、単純な事実確認クエリ（営業時間、価格、在庫の有無など）は影響が小さいと考えられます。 1つの事実で答えが決まるページは、情報が1か所にあれば十分で、知識の分断が問題になりにくいためです。

Figure

影響を受けやすいページ・受けにくいページ

影響を受けやすい

比較・条件判断クエリ

• 商品比較ページ
• 料金プラン比較
• 『〜向け』を含むLPやFAQ

影響が小さい

単純な事実確認クエリ

• 営業時間・所在地
• 単品の価格表示
• 在庫の有無

比較・条件判断が絡むページほど、複数部署に散らばった情報の統合漏れが表面化しやすくなります。 単純な事実ページは、情報源が1つで完結するため、この問題の影響を受けにくいと言えます。

やること／やらなくていいこと

Figure

AIプロトコル対応の前にやること

やること

• ✓商品比較で使う判断基準（価格・対象者・トレードオフ）が全ページに揃っているか棚卸しする
• ✓営業資料・ECカタログ・FAQで同じ商品の説明が食い違っていないか確認する
• ✓情報が欠けている条件を特定し、担当部署に追記を依頼する

やらなくていいこと

• ✕AI視認性チェックツールの指摘だけを理由にllms.txtを急いで設置する
• ✕スキーマ・markdown版・MCPエンドポイントを内容の精査なしに横展開する
• ✕新しい略語（プロトコル名）が出るたびに個別プロジェクトを立ち上げる

元記事は、100件以上の「エージェント対応度」監査でllms.txtの有無だけがチェックされ、 中身の質を評価した例がなかったと指摘しています。 ファイルを置くこと自体は数時間の作業ですが、中身が空疎なら効果はありません。 まず情報の欠落を埋める作業に工数を使う方が費用対効果は高くなります。

「I have seen over 100 agentic readiness audits all flagging the presence of an llms.txt file, but none of them critique the depth or quality of the file for those that had them.」

100件以上の監査でllms.txtの有無は確認されても、中身の質は誰も見ていなかったという指摘です。 形式の有無を確認するだけの監査は、実質的な改善につながらないことを示しています。

知識を「1か所で作り、どこにでも出す」

元記事は「canonical base（正典となる情報源）を1つ作り、あらゆる場所に配信する」という原則を提示しています。 商品の事実・関係性・ポリシー・判断基準を1つの管理場所にまとめ、 そこからWebページ、スキーマ、フィード、markdown、MCP、llms.txtなど各形式に出力する考え方です。

Figure

知識を1か所に作り各形式へ出す流れ

1. 1

   顧客の判断基準を洗い出す

   価格・対象者・比較条件・トレードオフなど

2. 2

   根拠となる情報の欠落を埋める

   部署ごとに分断された情報を統合する

3. 3

   一元管理された情報源を整備する

   CMSやデータベースなど正典となる置き場所を決める

4. 4

   各形式へ出力する

   Webページ、スキーマ、フィード、llms.txt、MCPなど

出力先を後から追加・入れ替えても、正典となる情報源が1つなら更新作業は1回で済みます。 形式ごとに情報を作り直していると、更新のたびに矛盾や更新漏れが発生しやすくなります。

日本の運営者にとっての具体例

例えばBtoBのSaaS企業サイトで、料金プランページには価格と機能一覧はあるものの、 「従業員50名未満の企業にはどのプランが向くか」という比較条件が記載されていないケースがあります。 営業資料には条件別の推奨プランが書かれているのに、公開ページには反映されていないことがよくあります。 llms.txtを設置しても、公開ページに条件別の推奨情報がなければAIは比較の根拠を得られません。

もう一つの例として、複数店舗を展開する飲食チェーンのサイトでは、 店舗ごとにアレルギー対応や座席数、駐車場の有無といった条件がバラバラに管理されがちです。 本部サイトと各店舗ページで情報が食い違っていると、AIがどちらを信頼してよいか判断できません。 店舗情報を1つのデータベースで管理し、そこから各ページへ出力する体制の方が優先度は高くなります。

判断基準：自社は対応すべきか

すべてのサイトが今すぐ知識の統合作業に着手する必要はありません。 比較・条件判断を伴う商品やサービスを扱っているか、社内で情報が部署ごとに分断されているかで判断します。

Figure

対応の優先度を判断する目安

3部署以上

商品情報が分散している場合は優先度が高い

営業・EC・カスタマーサポートなど

1商品

単一商品・単一料金のサイトは優先度が低い

比較条件がほぼ発生しないため

商品ラインナップが複数あり、価格・対象者・機能で比較されるビジネスほど優先度は高くなります。 単一商品や単一サービスで比較の余地が少ないサイトは、この作業への投資対効果は限定的です。 着手する際は、ECサイトなら商品マスタと商品ページの記載、BtoBサイトなら営業資料とFAQの内容突合から始めます。

よくある質問

llms.txtは設置しない方がよいのですか

設置自体は問題ありませんが、商品比較や条件判断に必要な情報が既にページ上で揃っていることが前提です。 情報が欠けたままllms.txtだけ設置しても、AIが参照できる根拠は増えません。

MCP対応は日本のサイトにも必要ですか

MCPはAIエージェントが複数のシステムにアクセスするための接続規格で、対応自体は技術的な選択肢の一つです。 ただし接続先の情報が不完全であれば、MCPに対応してもエージェントが得られる回答の質は変わりません。

知識の一元管理はどこから始めればよいですか

商品ページ・FAQ・営業資料など、同じ商品について複数の場所にある情報の食い違いを洗い出す作業から始めます。 食い違いや欠落を解消した後で、どの形式（スキーマ、llms.txt、MCP等)に出力するかを検討する順番が適切です。