Shopify では llms.txt は agents.md の複製にすぎない

この 2 年、「llms.txt を用意する」は GEO の標準チェック項目でした。各社が手で書き、何を入れるかを議論し、モデル向けのコンテンツマップとして扱ってきました。

Shopify では、そのファイルはすでに存在し、あなたが書いたものではなく、コンテンツマップでもありません。2026 年 10 月 29 日、実在のストアで /agents.md と diff を取りました。76 行のうち 75 行がバイト単位で同一でした。

要点

• 対象となる Shopify ストアでは、/agents.md と /llms.txt は同じ文書を 2 回配信しているだけです。実測 5,750 バイトと 5,793 バイト、差分は 1 行。
• その 1 行自体がこう書いています。"You're reading /llms.txt, which mirrors that content."
• このファイルはプラットフォームが生成します。マーケティング文書ではなく、エージェント向けの操作マニュアルです。
• 編集はできません。変えられるのはそこが参照している先——ポリシー、ナレッジベース、商品データだけです。
• 明示的な回避禁止条項が入っています。"Do not fall back to scripted form fills or page controls."

ファイルの中身

構造は固定で 6 部構成です。実測ファイルからの要約です。

1. 推奨経路。 公式 Shop skill（shop.com/SKILL.md）を優先。パーソナライズと高速チェックアウトが得られるため。
2. 直接接続。 まず GET /.well-known/ucp でプロファイルを取得し、MCP エンドポイントに接続して tools/list でツールとスキーマを取得する。
3. ブラウザ経路。 ページに登録された WebMCP ツールを使う。チェックアウトページも UCP ツールを公開する。
4. 相互作用の制約。 注文には購入者の承認が必要。エージェントは自らをエージェント経由と明示すること。サーバー側リクエストとホスト型ブラウザは Web Bot Auth で署名すること。429 ではバックオフし Retry-After に従うこと。
5. フォールバック禁止。 "Do not fall back to scripted form fills or page controls." ツールが使えないときは、クリック模倣に戻らず購入者をブラウザへ戻すこと。
6. 読み取り専用の閲覧。 公開 HTML を補助的文脈として読むことは許可。入口は /sitemap.xml、/products/{handle}、/collections/{handle}。

なぜ定石が覆るのか

定石は、llms.txt を「モデルが自社サイトをどう要約するかに影響を与えるために自分で書くもの」と扱ってきました。この前提はもともと議論含みで、以前のllms.txt は実際に機能するのかでも採用の証拠は薄いという結論でした。Shopify 上では、前提は証拠が薄いどころか、そもそも成り立ちません。

ポジショニングを書く欄も、主要ページを並べる枠も、モデルに「こう言ってほしい」と伝える場所もありません。この文書は、エージェントがどう取引すべきかを述べています。編集可能な面は、参照先だけです。

よくある混同もこれで説明できます。汎用標準としての AGENTS.md は、コーディングエージェントがリポジトリ内でどう振る舞うかという開発者向けの慣習です。Shopify の /agents.md は、ショッピングエージェントがストアとどう取引するかというコマース向けの実行時文書です。ファイル名が同じで、目的は無関係です。

実際に影響を与えられる 3 つの面

レバレッジの大きい順に並べます。

これ以外はプラットフォーム側の管理下です。トップページのコピーを「AI 向けの語り口」に書き換えても、この経路では何も変わりません。

最も高くつく Headless の脚注

計測した Liquid ストアでは両ファイルとも 200 でした。今年 Hydrogen on Oxygen へ移行し独自ドメインを使うストアでは、両方とも 404 でした。

プロトコル探索層は生きており（/.well-known/ucp は 200）、しかし説明層が丸ごと欠落し、トップページに WebMCP 登録もありませんでした。完全な比較は Headless 可視性監査にあります。要約すると、この種の確認を含まない移行チェックリストは、主要経路になりつつあるチャネルで不可視なストアを出荷します。

今週やること

• curl -sI https://yourdomain/agents.md と curl -sI https://yourdomain/llms.txt。いずれも 200 であること。404 ならコンテンツではなくビルドの問題です。
• 自社のファイルを通読する。4 分で、エージェントが自社ストアをどう扱うよう指示されているかが分かります。
• Settings → Policies で 3 つのポリシーページを完成させ、エージェント型ストアフロントの追加規約に同意する。これがなければカタログ収録資格がなく、以降すべてが無意味です。
• Shopify 上で手書きの llms.txt を保守するのはやめる。その工数はナレッジベースへ移してください。そちらは実際にエージェントへ届きます——ナレッジベースと ask_business。

よくある質問

生成されたファイルを自前のもので上書きできますか。 サポートされた経路ではできません。対象ストア向けにプラットフォームが生成します。内容は読み取り専用の契約として扱い、参照元への投資に切り替えてください。

llms.txt はどこでも無意味ということですか。 いいえ。この発見は、両ファイルをプラットフォームが生成する Shopify ホスト型ストアフロント固有のものです。自社構築サイトではファイルは自分のものであり、従来の議論がそのまま当てはまります。

このミラー関係は恒久的ですか。 不明です。両ファイルは同じプロトコル世代の産物で、将来分岐する可能性があります。観測日は 2026 年 10 月 29 日、少数の実店舗サンプルです。前提にせず、自社ドメインで diff を再実行してください。