本文へ移動
SKU.md
メニュー
日本語

BLOG / sku-md-v0-9-interoperability-conformance.mdx

SKU.md v0.9：相互運用性、範囲を明示した適合性、安全な利用

v0.9 の変更点、ワイヤ形式を変えない移行方法、検証者・利用者・発行者が証拠に基づく契約を共有する方法を解説します。

公開日

元の仕様バージョン: v0.9

SKU.md v0.9 は相互運用性と一貫性のためのリリースです。Shopify 固有のフィールド、ランキングスコア、別のチェックアウトシステムを追加するものではありません。発行者が検査内容をどう示し、利用者がその証拠をどう解釈し、双方がどこで稼働中のコマースシステムに戻るべきかを定義します。

ワイヤ形式は変わりません

v0.9 Schema は v0.8 の文書種別、複数の Profile、フィールド、必須プロパティ、列挙値、拡張規則、安全境界を維持します。そのためデータ層の移行は意図的に小さくなっています。

  1. schema_version を sku.md/0.9-draft に変更します。
  2. Schema URL を https://sku.md/schema/sku-md/0.9/schema.json に変更します。
  3. 主張する適合範囲に必要な検査をすべて実行します。

利用者は互換性のために v0.8 文書を引き続き読めますが、それを v0.9 適合と表示してはいけません。バージョンの同一性と適合性の証拠は別の主張です。

完全な英語版 v0.9 仕様 だけが規範文書です。公開されている v0.9 JSON Schema は構造を検査しますが、それだけで完全な適合判定にはなりません。

3 つの適合範囲

v0.9 は検証者が実際に調べた対象を明示します。

範囲 確認できること 確認できないこと
offline_document 安全なフロントマターと YAML、Schema、単一文書の意味、Markdown の一致 HTTP 配信、リソース到達性、親グラフの整合性
published_resource HTTP ステータス、リダイレクト、MIME、正規 URL、ソフトフォールバック、到達性を含む 1 つの公開 URL 文書ファミリー全体の一貫性
document_graph 親チェーン、表現、外部 Profile、参照リソース、文書間の一貫性 購入、支払い、コマース状態変更の権限

レポートでは構文、Schema、意味、オンライン検査を別々の層として記録します。必須検査が失敗すれば全体は failed です。必須検査が未実施で失敗もない場合は incomplete であり、passed にはなりません。

持ち運べる検証レポート

レポートは文書に関する証拠であり、SKU-MD のフロントマターの一部ではありません。正常に生成されたルート文書では次のようになります。

{
  "spec_version": "sku.md/0.9-draft",
  "validator": { "name": "sku-md-generator", "version": "0.2.0" },
  "target": {
    "url": "https://example.com/sku.md",
    "document_type": "catalog_manifest"
  },
  "scope": "offline_document",
  "status": "passed",
  "checked_at": "2026-08-01T00:00:00Z",
  "layers": {
    "syntax": "passed",
    "schema": "passed",
    "semantics": "passed",
    "online": "not_applicable"
  },
  "issues": []
}

安定した問題コードにより結果をツール間で扱えます。例は YAML_DUPLICATE_KEY、SCHEMA_VALIDATION_FAILED、CANONICAL_MISMATCH、GTIN_CHECK_DIGIT_INVALID、KNOWLEDGE_DYNAMIC_STATE_FORBIDDEN、BODY_PARITY_INVALID です。ネットワークのタイムアウトを成功に変換してはいけません。

サイトのジェネレーターが作るのは offline_document レポートだけです。アップロード後も、発行者は HTTP ステータス、text/markdown、ソフトフォールバック、正規 URL、親リンク、表現形式、外部 Profile 参照のオンライン検査を行う必要があります。

Reference Consumer の動作

Reference Consumer は読者のための動作契約であり、新しいワイヤ形式ではありません。安全な手順を示します。

  1. 販売者がホストするルートを発見し、オリジンと表現形式を確認します。
  2. 隠れた商品を推測せず、宣言されたカタログ入口とパーティションをたどります。
  3. 安定した識別子、選択肢、市場、言語、正規の Variant URL から正確な Variant を選びます。
  4. 事実、主張、開示事項、案内、制限、互換性、出典 URL、検証日を区別します。
  5. offer_snapshot は観測として扱い、現在の価格、在庫、配送、税、合計には live_lookup または live_verification を使います。
  6. カート、Checkout、支払い、注文は、明示的なユーザー確認とともに、宣言されたリアルタイムの権威ある情報源へ戻します。

同一性、証拠、鮮度、権限が不足する場合、利用者はモデルの推論で穴を埋めず、安全側に失敗しなければなりません。

出典のガバナンスはツール層に置きます

発行者には利用者へ渡すべきでない状態も必要です。非公開の出典マップは各値の出典と、それが Detected、Derived、Verified のどれかを記録できます。監査・計画・適用の流れでは HTML、Product JSON-LD、販売者フィード、プラットフォーム Catalog、既存の SKU-MD を比較し、確認可能な差分を用意して、人の承認後にだけ公開できます。

出典マップ、レビュー記録、ドラフト状態、リリース差分、問題ログ、チャネル指標は公開 Schema に入りません。差分再構築やオンライン検証に失敗した場合、配信システムは部分的な出力で置き換えず、最後の有効版を維持すべきです。

複製ではなくプラットフォームとの協調

SKU-MD は安定した知識と明示的な出典境界を記述します。プラットフォーム Catalog は現在の配信、価格、在庫に対する権威ある情報源のままです。リアルタイム API または UCP/MCP が現在の問い合わせを扱い、Checkout は購入者認証、合計、支払い、注文作成を担います。

2026-08-01 時点で、Shopify は Shopify Catalog と UCP 準拠の Catalog、Cart、Checkout、Order インターフェースを文書化しています。Shopify は、それらのシステム、ChatGPT、その他の Shopify チャネルが SKU-MD を読んだり信頼したりするとは説明していません。したがって連携ガイドは支払い・注文状態を複製せず、参照と権限の境界を使います。

成果を約束せずに SEO、GEO、AEO を測る

有用な問いは、静的ファイルが AI 検索での順位を上げるかどうかではありません。管理された実験では次を測れます。

  • 正確な Variant 解決率
  • 販促文ではなく出典付きの事実の引用
  • 開示事項と制限の再現
  • 時間依存の回答前にリアルタイム検証を使うこと
  • HTML、Product JSON-LD、販売者フィード、プラットフォーム Catalog、SKU-MD 間の一貫性

これらは公開契約が曖昧さや古い回答を減らすかを示せますが、クローラーが文書を取得することや、プラットフォームが商品を順位付け、引用、推奨し、コンバージョンにつなげることは証明しません。

実用的な移行手順

まずバージョン識別子を更新し、オフラインレポートを生成します。人のレビュー後にだけ公開し、その後、公開リソースと文書グラフを検証します。変動する商取引状態は Knowledge の外に置き、自動化に失敗したら最後の有効な改訂版を維持し、根拠のない採用主張ではなく管理されたテストで結果を比較します。

関連資料

現行v0.10の配信手順は、最初のSKU.mdを公開するで確認できます。

← すべての記事