30 秒で分かる結論：EC サイトの llms.txt は目次であって、フィードではない
ファイルは数千トークン以内で 3 つの問いに答えるべきです。何を誰に売っている店か、カテゴリはどこにあるか、送料・返品・サイズのルールは何か。つまり商品ではなくカテゴリを、リンクではなく 1〜2 文で書き出した規約を載せ、クロールとクロールの間に変わるものは載せません。
価格と在庫は、いちばん載せたくなり、いちばん別の場所に置くべきものです。それらは各商品ページの Product 構造化データと商品フィードにあり、どちらも商品単位でクロールのたびに読み直されます。llms.txt はアシスタントを正しいカテゴリに案内し、価格は商品ページが伝えます。
なぜカタログは収まらないのか
一度だけ計算してみます。実在するファイルで測ると、注釈つきのリンク 1 本は 150〜280 バイト程度です。5,000 商品を 1 商品 200 バイトで並べると Markdown で 1 MB、1 トークン 4 文字の目安で約 25 万トークンになります。それを読むアシスタントはありません。このサイトのバリデータは 100 KiB で警告し 512 KiB で読むのをやめますし、仕様自身も sitemap.xml が llms.txt の代替にならない理由の 1 つとして、サイトマップが扱う文書は合計するとコンテキストウィンドウに収まらないことを挙げています。
その一覧の置き場はサイトマップです。Google はサイトマップ 1 ファイルあたり 50,000 URL または 50 MB を認め、それ以上はサイトマップインデックスで束ねます。まさにカタログの形です。2 つのファイルは仕事を分けます。sitemap.xml はすべての URL があることを伝え、llms.txt はそのうちどの 20 ページが重要で、なぜかを伝えます。
llms-full.txt にも同じ論理が当てはまります。ドキュメントサイトでは全ページの本文を 1 ファイルにまとめたものですが、EC サイトで商品ページから生成すると、上で計算した 1 MB からマークアップを取り除いただけのものになります。公開するなら、ガイドと規約ページだけから作ります。サイトの中で文章として読める部分はそこだけだからです。
アシスタントが店に実際に聞くこと
ファイルを書く前に、質問を並べます。人が店についてアシスタントに打ち込む内容で繰り返し出てくるのは次のようなものです。
- 自分の地域に配送できるか、何日かかるか、送料はいくらか
- 返品できるか、何日以内か、送料はどちらが持つか
- どのサイズを注文すべきか、小さめに作られていないか
- この 2 つのモデルやシリーズは何が違うのか
- そもそも X を売っているか、だいたいいくらか
- 保証はあるか、誰にどう連絡すればよいか
特定の商品についての問いは 1 つだけで、それも答えるのは SKU ではなくカテゴリページか比較ガイドです。ファイルは各問いに答えるページへリンクし、最初の 2 つは短いので本文に答えを書きます。クローラーが規約ページを読めないこともあるからです（Shopify の既定の robots.txt は、すべてのユーザーエージェントに対して規約のパスを禁止しています）。日本の EC サイトなら、特定商取引法に基づく表記のページも同じ扱いで、送料・返品・支払い方法の要点を本文に写しておくと確実です。
構成
| セクション | リンクするもの | 注釈の書き方 |
|---|---|---|
| H1 + 引用 | リンクなし。店名 1 行と、何を誰にどこから売るかの 1〜2 文 | 通貨と配送地域をここで言う |
| カテゴリ | 大分類のカテゴリページ、10〜20 個 | 1 文：何が入っていて誰向けか |
| ガイド | サイズ表、比較ページ、選び方の記事 | そのページが答える質問を書く |
| 配送と返品 | 規約ページ。ただし本文に実際のルールを 2〜3 文書いた後に | 地域、日数、返送料の負担 |
| サポート | 問い合わせ、保証、注文追跡 | 営業時間と窓口が 1 句で収まるなら書く |
| Optional | ブランドの話、ブログ、卸売、他言語版、あれば llms-full.txt | 読み飛ばされる前提。短く |
カテゴリのセクションが、商品一覧がやるはずだった仕事を引き受けます。管理画面のツリーではなく、買い物客が口にする分類を選びます。部門ごとにカテゴリが多い店なら部門ごとに H2 を 1 つ置き、読み手がブロック単位で読み飛ばせるようにします。仕様は H2 セクションの数を制限していませんし、1 つの部門が独立したファイルに値するなら、そのサブパスの下にファイルを置くこともできます。
注釈の書き方で気をつけることが 2 つあります。カタログの言葉ではなく買い物客の言葉を使うこと。社内のシリーズ記号や SKU の接頭辞ではなく「レインウェア」と書きます。そして、名前だけで伝わらないときは誰向けかを添えること。「通勤用自転車」と読んだモデルにとって、通勤の言い換えをもう 1 つ足すより「キャリアとライトつきのアップライトな街乗り車」のほうが多くを伝えます。
価格、在庫、そのほか毎日変わるもの
ルールは単純です。書いた 1 週間後に間違いになる値は llms.txt に書かない。これで現在価格、セール価格、在庫数、配送業者の状況に左右されるお届け目安が外れます。残るのは安定した枠組みです。通貨、カテゴリの下限価格や価格帯（「フレームは 6 万円から」）、めったに変わらない送料無料の条件、返品期限。
商品単位の数字にはすでに置き場があります。各商品ページの Product 構造化データは Offer として price、priceCurrency、availability を持ち、availability には InStock や OutOfStock といった schema.org の値を使います。Google はこれを Merchant Center のフィードとあわせて読み、検索結果に価格と在庫を表示します。カテゴリのリンクをたどって商品ページに来たアシスタントも同じマークアップを読みます。そちらを正確に保ち、llms.txt は一般的な記述にとどめます。
プラットフォームから llms.txt を生成していて価格帯を入れたいなら、カタログが変わるたびにファイルを再生成し、本文に時点を書きます（「2026 年 10 月時点」）。読み手が古い写しと今の版を見分けられるようにするためです。
完成した実例
国内向けに販売する架空の自転車店です。中身はどれも数か月は変わらないもので、時点を書いた行は 1 つだけです。
# Kestrel Bikes > 神戸の自転車店。グラベルバイクと通勤用自転車、パーツ、ウェアを販売。価格は日本円（税込）。配送は国内全域、店頭受け取りも可。 ## カテゴリ - [グラベルバイク](https://kestrel.example/collections/gravel): 未舗装路も走れる完成車。入門用のアルミからカーボンのレース仕様まで。 - [通勤用自転車](https://kestrel.example/collections/commuter): キャリアとライトつきのアップライトな街乗り車。電動アシストも数モデル。 - [フレーム](https://kestrel.example/collections/frames): カスタム組み立て用のフレームセット。6 万円から（2026 年 10 月時点）。 - [パーツ](https://kestrel.example/collections/components): 駆動系、ホイール、ブレーキ、サドルやハンドルを規格別に。 - [ウェア](https://kestrel.example/collections/clothing): ジャージ、ビブ、レインウェア。注文前にサイズガイドを参照。 ## ガイド - [サイズガイド](https://kestrel.example/pages/size-guide): 身長と股下からのフレームサイズ、ブランド別のウェアのサイズ表。 - [グラベルと通勤用、どちらを選ぶか](https://kestrel.example/guides/gravel-or-commuter): 毎日乗る用途での 2 シリーズの選び方。 - [駆動系の選び方](https://kestrel.example/guides/drivetrains): フロントシングルとダブル、ギア比の幅、互換性。 ## 配送と返品 送料は 1 万円以上の注文で全国無料、それ未満は一律 800 円。完成車は組み立て済みで 3〜5 営業日に発送。未使用品は 30 日以内に返品可。返送料はお客様負担、初期不良の場合は当店負担。 - [配送について](https://kestrel.example/policies/shipping-policy): 地域別の料金と日数の全文。 - [返品と保証](https://kestrel.example/policies/refund-policy): 返品の手順とフレームの 2 年保証。 - [特定商取引法に基づく表記](https://kestrel.example/pages/tokushoho): 事業者情報、支払い方法、引き渡し時期。 ## サポート - [お問い合わせ](https://kestrel.example/pages/contact): メールと電話。火〜土 10:00〜18:00。 - [注文の追跡](https://kestrel.example/account/orders): 発送済み注文の追跡。 ## Optional - [店について](https://kestrel.example/pages/about): 運営者と工房サービス。 - [ジャーナル](https://kestrel.example/blogs/journal): ライドの記録とメンテナンス記事。 - [English](https://kestrel.example/llms.txt): このファイルの英語版。
3 KB 弱、カテゴリ 5 つ、ガイド 3 本で、上に挙げた 6 つの質問すべてに答えるかリンクしています。カタログが 10 倍の店でも、できあがるファイルはほぼ同じ長さで、カテゴリが増えてルールの数は同じ、という形になるはずです。
フィードにせずに最新に保つ
- 商品一覧ではなくカテゴリ一覧から書く。プラットフォームがファイルを生成できるなら、カテゴリのセクションだけ大分類から生成し、残りは手書きの文章のままにします。生成できなければ、ウェブルートに静的ファイルを置けば十分です。カテゴリはめったに変わりません。
- 規約が変わったら見直す。規約ページと同じチェックリストにこのファイルを載せます。送料の変更が規約ページには反映されて llms.txt には反映されない、というのがファイルが間違う最もありそうな経路です。
- まずプラットフォームの既定を確認する。Shopify のストアは、対応するエージェント向けプロトコルを説明する llms.txt をすでに配信していますが、何を売っているかは書かれていません。 Shopify の記事で、Liquid テンプレートで店固有の部分を足す方法を説明しています。ほかのプラットフォームではプラグインを探すか、手でファイルを置きます。
- 基本を一致させる。引用に書く店名、説明、通貨は、Organization の構造化データやフィードの設定と同じにします。説明が 2 通りあると、アシスタントはどちらかを選びます。あなたの意図した方とは限りません。
確認する
素の HTTP クライアントでファイルを取得し、買い物客になったつもりで読みます。何を売る店か、自分の地域に届くか、サイズが合わなかったらどうなるかが分かるか。そのうえでバリデータにかけ、構造とリンクの解決を確認します。
よくある質問
EC サイトの llms.txt には全商品を載せるべきですか？
載せません。このファイルは数千トークンの予算しかないモデルが読むもので、1,000 商品を 1 行ずつ並べただけでもはるかに超えます。載せるのは大分類のカテゴリ、選び方ガイド、送料・返品などの規約ページで、商品単位の情報は sitemap、カテゴリページ、商品ページの構造化データに任せます。
価格を llms.txt に書いてもよいですか？
変わらない価格だけです。「〜円から」の下限、価格帯、取扱通貨は書けます。セールや在庫で動く価格は、商品ページの Product 構造化データ（Offer の price、priceCurrency、availability）と商品フィードに置きます。そちらはクロールのたびに読み直されます。llms.txt の古い価格は、アシスタントが最初に読む場所にあるぶん、書かないより害があります。
在庫状況はどうしますか？
書きません。在庫は時間単位で変わり、llms.txt は読む側にキャッシュされます。仕様も、このファイルは索引されるのではなく必要時に読まれると説明していて、更新の周期をこちらで制御できません。どのカテゴリを扱っているかを書き、在庫はアシスタントが商品ページを取得したときにその構造化データから得るようにします。
送料と返品のルールはどこに書きますか？
本文に 2〜3 文で直接書き、あわせて規約ページ全文へのリンクを置きます。店舗についてアシスタントに実際に聞かれるのはこの 2 つが中心です。プラットフォームによっては規約ページが既定の robots.txt で遮られているので、ファイル内の要約がクローラーに読める唯一の版になることもあります。
カテゴリが 40 個あります。全部載せますか？
買い物客が口にするものだけを載せます。大分類 10〜20 個に「何が入っていて誰向けか」を 1 文ずつ添えるのが使いやすい分量です。細かい下位カテゴリはカテゴリページ側に任せます。それでも多ければ、部門ごとに H2 を 2〜3 個に分けて、読み手がブロック単位で読み飛ばせるようにします。
商品フィードや Product 構造化データの代わりになりますか？
なりません。それらは商品単位で機械的に検証され、検索エンジンやショッピング面が価格と在庫を表示するのに使うものです。llms.txt は、店が何でどこを見ればよいかをアシスタントが把握するための 1 ページの要約です。正確に説明されたい店は両方を持ち、店名・説明・通貨といった基本が一致するようにします。
次に読む
- → Shopify ストアの llms.txt （既定のファイルと、それを書き換える Liquid テンプレート）
- → llms.txt と robots.txt と sitemap.xml の違い （カタログを担うのはどのファイルか）
- → llms.txt の書き方
- → 解説記事の一覧へ戻る