SKU.md v0.8 のレイヤー構成を読み解く：自社ホストの情報とプラットフォームの承認が必要な取引

SKU.md v0.8 の構成図は、技術を初級から上級へ積み上げたものではありません。管理主体がどこで切り替わるかを示す地図です。AI エージェントは販売者のドメインから出発し、公開された発見経路と販売者が提供する商品コンテキストを通り、外部プロトコル、プラットフォーム、ID システム、取引バックエンドに依存する能力へ進みます。

色はその境界を表します。青緑は販売者が自分のドメインで公開または実装できる領域、珊瑚色はプロトコル運営者やプラットフォームなど別の主体による参加、認証、承認、実行が必要な領域です。情報を公開して発見可能にしても、その情報を使うシステムまで全員に開放されるわけではありません。

色が示すのは権限の境界

白いボックスはファイル、データ構造、仕組みの名前です。外側の色は、誰がその仕組みを実際に成立させて運用できるかを示します。

青緑のレイヤーでは、公開する権限を販売者が持ちます。robots.txt の設定、Sitemap の提供、llms.txt とルート sku.md の公開、パーティション索引や商品文書の追加、ページ実行時ツールの提供を自社ドメインで行えます。正しいホスティング、安全な解析、正確なデータは必要ですが、ファイルを置くこと自体に商用プラットフォームの事前承認は要りません。

珊瑚色は、プロトコル仕様が非公開だという意味ではありません。実際の利用に相手方が必要だという意味です。プロトコル Profile には販売者登録、本人確認、資格情報、対応サービス、プラットフォーム審査が必要な場合があります。Checkout、支払い、Order の完了には、ユーザーの承認と商取引状態を確定できる外部システムが必ず関わります。

この図は、混同されやすい二つの行為を分けています。宣言を公開することと、その宣言を実行する権限を持つことです。

ガバナンスと発見は販売者が管理する

最初のレイヤーには robots.txt、llms.txt、sitemap.xml があります。いずれも利用者によるサイト資源の発見や解釈を助けますが、役割は同じではありません。

robots.txt はクロール規則を表し、Sitemap の場所も示せますが、一般的な本人確認やアクセス認可のプロトコルではありません。Sitemap は URL の一括発見に使われ、各 URL の記述が最新、正確、信頼可能であることまでは証明しません。llms.txt は AI 向け利用者に簡潔な案内を提供できますが、公開後にモデルやエージェントが読み、採用し、引用し、順位を上げる保証はありません。

そのため、このレイヤーは「信頼」ではなく「ガバナンスと発見」です。販売者は公開内容とリンク先を管理しますが、利用者はクロール可否、応答元、内容に与えられる証拠の重みを別に判断します。

SKU-MD 文書群はルートを一定の大きさに保つ

二番目の青緑のレイヤーは SKU-MD 文書群です。

• ルート /sku.md のカタログマニフェスト。
• 大規模または分割されたカタログ向けの任意のパーティション索引。
• 商品単位の *.sku.md 文書。

図の O(1) は、カタログが増えてもルートマニフェストの大きさを一定範囲に保つという意味で、カタログ全体を定数時間で検索できるという意味ではありません。ルートは全商品を埋め込まず、カタログ入口、パーティション、商品文書の発見経路へリンクするため、短く安定させられます。

この設計はエージェントに予測可能な開始点を与えつつ、小規模な販売者に複雑な索引を強制しません。小さなカタログは既存資源へ直接リンクでき、大きなカタログは市場、言語、業務区分で階層化できます。商品文書は一つの ProductGroup とその複数の Variant に集中するため、部分的な商品情報の更新でルートを書き直す必要もありません。

これらのファイルは販売者がホストしますが、ファイル名だけで権限が生まれるわけではありません。信頼はドメイン管理、正規 URL、一貫した改訂、証拠、正しい HTTP 配信から得られます。

商品情報レイヤーは安定した知識と変動状態を分ける

三番目の青緑のレイヤーは Product JSON-LD と SKU.md Knowledge を並べ、offer_snapshot と live_verification も別に示します。安定した事実と変化しやすい商取引状態を、区別のない一つの記録に押し込めないためです。

Product JSON-LD は成熟したページ単位の商品セマンティクスを提供します。SKU.md Knowledge は事実、主張、開示事項、案内、制限とその証拠を整理できます。Knowledge は公開と監査に値する記述を保持する場所であり、短期の価格、在庫、送料、販促を長期本文へ固定する場所ではありません。

offer_snapshot は特定の市場と Variant で特定時点に観測した状態です。observed_at、refresh_after、実在する場合の offer_valid_until は鮮度判断を助けます。スナップショットが証明するのは過去の観測だけで、在庫を確保したり、判断時点でも同じ価格と在庫が続くことを保証したりはしません。

live_verification は保守的なリアルタイム確認手段です。公開商品ページを開き直し、同じ Variant の現在表示を調べます。構造化された Catalog Lookup API ではなく、購入を直接実行するものでもありません。利用可能な構造化 live_lookup を識別できればそちらを優先し、なければ販売者が管理する公開ページで再確認します。

capabilities[] と protocol_profiles[] は別の経路

商品情報レイヤーの後で構成は二つに分かれます。新旧技術の違いではなく、誰が能力を運用し、利用者が使用前にどの条件を満たす必要があるかの違いです。

capabilities[]：販売者が公開する実行時能力

外部プロトコルの権威ある Profile がない場合や、能力がページ実行時に存在する場合、capabilities[] は WebMCP ページツールのような汎用機能を説明できます。販売者は店舗ページでツールを実装し、対象範囲、状態、発見方法、アクセス方法を宣言できます。

ページ実行時ツールはページの状況に制約されます。ユーザーの同席を要求し、商品やカートだけを対象とする場合があり、マニフェストへ書いてもリモート呼び出し URL が自動で生まれるわけではありません。「自社管理」は「無制限に呼べる」という意味ではなく、ブラウザー、サイトポリシー、現在のセッション、ツール Schema、アプリケーションコードが実際の動作を制限します。

さらに、能力宣言は入口が存在することを説明するだけです。エージェントがユーザーの同意、支払い権限、取り消せない操作の許可を得たことまでは証明しません。

protocol_profiles[]：外部の信頼システムへの参照

外部プロトコルが権威ある発見 Profile を定義している場合、protocol_profiles[] はその Profile へリンクします。プロトコルのバージョン、サービス、転送、エンドポイント、Schema をカタログマニフェストへ複製するためのものではありません。

図では UCP と ACP をこの経路の例にしています。Profile は販売者ドメインで公開できても、実際の参加にはプロトコル対応、販売者登録、プラットフォーム審査、資格情報、商業契約が必要な場合があります。構文が正しい Profile だけで他の参加者の受け入れを作ることはできません。

ここが重要です。公開された発見文書は、承認が必要な実行環境を正直に説明できます。参入条件が存在しないように装う必要はありません。

二つの経路は取引境界で合流する

最下部の珊瑚色レイヤーには Checkout、支払い、Order があります。エージェントがページ能力とプロトコル Profile のどちらを通っても、実際の取引には資金、在庫、税、履行、リスク、ユーザー認可を管理するシステムが必要です。

SKU.md はそれらのシステムの場所と、各フィールドでどの情報源を権威とするかを示せますが、Checkout バックエンドは代替できません。最終金額、支払い状態、注文状態は、変更を実行して記録できるシステムから得る必要があります。利用可能な情報源がなければ、安全な結果は静的文書から取引を推測することではなく「不明」とすることです。

二つの経路がここで合流するため、自社ホストのページツールをプラットフォームやプロトコルの管理を迂回する手段にはできません。ツールはカートの準備やユーザー案内を行えても、商取引状態が拘束力を持つ前に認可済みバックエンドへ移る必要があります。

この構成が避ける五つの分類誤り

1. 発見は採用ではありません。 ファイルへアクセスできても、エージェントが利用し、信頼し、推奨するとは限りません。
2. 宣言は承認ではありません。 能力宣言またはプロトコル Profile を記載しても、外部システムが有効にした証拠にはなりません。
3. スナップショットは現在状態ではありません。 価格と在庫は観測時刻とともに評価し、判断時に再確認します。
4. ページツールは支払い権限ではありません。 実行時能力はユーザーの同席、アプリケーションポリシー、Checkout の制約を受けます。
5. 公開仕様は公開取引ではありません。 本人確認、資格情報、同意、リスク管理、商業契約が必要な場合があります。

小さな文書でも境界を正直に表せる

この構成は入口を単純に保ちながら、すべての下流依存関係を曖昧な「AI コマース」という一語へ押し込みません。販売者は自社ドメインで発見、文書、証拠、ページ実行時レイヤーを管理し、外部プロトコルと取引システムは現実の承認・認可要件を維持します。

これがレイヤー設計の中心です。SKU.md は商品コンテキストと実行可能な商取引の境界を消そうとはしません。販売者が管理範囲を理解し、プラットフォームが必要な承認を維持し、利用者が証拠を読む段階から操作を要求する段階へ移った時点を判断できるよう、境界を明確にします。

関連資料

現在の責任分担は、llms.txt・agents.md・SKU.mdの比較で整理しています。