RFC 0001：SKU.md の宣言型ディスカバリー、構造化された識別子、参考価格

SKU.md 1.0.0-beta は意図的に小さく作られています。/sku.md のルートカタログ、任意の商品知識文書、そしてすべての事実に付く Source リンクです。この小ささのおかげで検証は簡単ですが、AI との対話型ショッピングで独立系ストアにとって重要な三つの隙間も残ります。RFC 0001 はそれを埋めるための草案です。

この RFC は現行仕様の一部ではありません。バリデーター、ジェネレーター、CLI、MCP ツール、Agent Skill のいずれもまだ実装しておらず、採用されたとしても 1.0.0-beta の文書はすべて有効なままです。全文は RFC 0001 にあります。

隙間その一：ホスティング型ストアはルートパスを使えない

仕様はカタログのパスが正確に /sku.md であることを求めています。プロジェクト自身の Shopify ガイド には、同プラットフォームがストアのルートを管理し、App Proxy の接頭辞を制限していることが記録されています。ほかのプラットフォームのファイルライブラリ型ホスティングは、最終パスが変わるリダイレクトに頼るのが一般的です。こうした販売者は同じ Markdown を別の同一オリジンのパスから配信できることが多いのですが、現状ではそれは適合しません。

RFC は、読み手が最初に確認する場所として /sku.md を維持します。そこにない場合、ストアは次の五つのヒントのいずれかで別の同一オリジンのカタログ URL を宣言でき、読み手は決まった順序で確認します。

1. 予約パス /.well-known/sku.md。先に IANA への登録が必要です。
2. トップページの HTTP Link ヘッダー。rel="alternate"、type="text/markdown"、title="SKU.md" を持つもの。
3. 同じ関係を表すトップページの HTML link 要素。
4. llms.txt の Product knowledge セクションにある、ラベルが SKU.md catalog のリンク。
5. agents.md の中で SKU.md catalog: から始まる行。

最後の二つは、ディスカバリー参照のガイド がいま推奨している参照と同じです。いま追加しておけば、宣言もすでに整っていることになります。

どのヒントも同一オリジンでなければならず、宣言されたファイルはルートカタログとまったく同じように検証されます。食い違う二つのヒントは衝突として報告されます。さらに RFC は、プラットフォームが再生成する可能性のあるファイル内のヒントよりも、トップページの制御を必要とするヒントを優先するよう読み手に求めます。パスの規則を緩めると、販売者が管理していない内容をカタログとして宣言してしまうリスクが高まるためです。

隙間その二：識別子が自由記述

ショッピングシステムは GTIN、MPN、ブランド、販売者の SKU を使って、二つの言及が同じ商品を指すかどうかを判断します。1.0.0-beta ではこれらを Identifiers セクションに書けますが、自由記述としてだけです。RFC は、パーサーが推測なしで読める構造化された書き方を加えます。

## Identifiers
- GTIN: 00012345678905 [Source](https://www.example-outdoor.com/products/tent)
- MPN: UL2P-24 [Source](https://www.example-outdoor.com/products/tent)
- Brand: Example Outdoor Gear [Source](https://www.example-outdoor.com/pages/about)
- SKU: TENT-UL2P-GRN [Source](https://www.example-outdoor.com/products/tent)

GTIN、MPN、Brand、SKU、ISBN は予約ラベルです。GTIN は GS1 のチェックディジットを満たす必要があり、予約ラベルで始まりながら規則を満たさない項目は、ただの文章として扱われるのではなく無効になります。バリエーションごとに識別子が異なる場合は、値の後に for とバリエーション名を付けられます。構造化された GTIN が Product JSON-LD やフィードと食い違うとき、読み手はどちらかを選ぶのではなく、衝突を報告して買い物客をライブのページへ案内するべきです。

隙間その三：価格の置き場所がまったくない

対話型ショッピングでは、価格が最初の絞り込み条件になることがよくあります。1.0.0-beta は静的ファイルにライブ価格を入れず、RFC もこの規則を維持します。追加するのは、日付と出典を持つ任意の Reference price セクションです。

## Reference price
- USD 349.00 as of 2026-08-11 [Source](https://www.example-outdoor.com/products/tent)
- USD 299.00 to 349.00 as of 2026-08-11 for all variants [Source](https://www.example-outdoor.com/products/tent)

通貨は ISO 4217 のコード、金額は小数点を使い桁区切りを付けず、as of の日付は文書の Updated より後にはできません。このセクションにはセール価格、クーポン、会員価格、送料、税、在庫を書けません。値を使う読み手は、それを日付付きの参考として示さなければならず、カートやチェックアウトに使ってはならず、90 日より古い日付は古くなったものとして扱うべきです。

草案の中で最も議論の余地がある部分です。予算で絞り込むアシスタントは価格の手がかりがまったくない商品を飛ばしてしまう一方、日付と出典が明確な参考価格なら、確認のために買い物客をライブのページへ送り出せる、というのが根拠です。

RFC が扱わないこと

同じレビューで出たいくつかの案は、後の提案に回しています。販売地域、言語、通貨を示すルートの Markets セクション、ルートカタログの任意の Brand と Categories セクション、31 文書というグラフの上限を仕様から切り離すこと、読み手向けの寛容な解析プロファイル、そして Markdown リソースと Sitemap や正規ページとの関係についてのガイダンスです。RFC がこれらを列挙しているのは、この草案への議論を焦点のあるものにするためです。

未解決の論点とコメントの方法

草案は四つの問いを明示しています。well-known の登録をいま申請すべきか、二つ目の独立した実装を待つべきか。プラットフォームが上書きしうる llms.txt と agents.md のヒントを残すべきか。価格の動きが速いカテゴリーにとって 90 日のしきい値は適切か。ルートカタログにも Brand を認めるべきか。

コメントは プロジェクトのリポジトリ で受け付けています。展開計画では、どのリリースが採用するよりも前に、バリデーターでのプレビューフラグ、新しい問題コードごとの適合フィクスチャ、宣言された URL で公開するホスティング型プラットフォームの販売者が少なくとも一社、それを読む独立した読み手が一つ、を求めています。それまでは 現行仕様 に沿って実装してください。