Schemaは有効でも公開準備未完了：SKU.md配信の10の誤り

Schema検証に合格した文書でも、公開時に失敗することがあります。ローカルの解析器からは、公開配信で加わるHTTP、識別、本文、リンク、バージョン、文書グラフの契約が見えません。

SKU.md は、販売者が自らホストする商品発見と安定した商品知識のレイヤーです。Agent が商品を見つけ、出典のある事実を理解し、リアルタイムの商取引情報をどこで再確認すべきか把握できるようにします。新しい Checkout プロトコルではありません。

配信で起きる10種類の誤り

#	障害	再現可能な検査
1	HTTPステータスが誤っている	正確なHTTP 200を必須にする
2	リダイレクトされる	リダイレクト無効で取得し、要求URLを必須にする
3	MIMEが誤っている	有効な任意パラメーター付きtext/markdownを必須にする
4	ソフトフォールバック	成功扱いで返る汎用HTMLやホームページのバイト列を拒否する
5	canonicalが誤りまたは欠落	フロントマターのcanonicalを要求URLと照合する
6	本文または派生内容が不一致	受理済みバイト列と本文・フロントマターの整合を比べる
7	リンク切れ	必須のリンク先リソースを安全に取得する
8	親文書への連鎖または発見経路が破損	/sku.mdから走査しparent関係を検証する
9	バージョンが誤っている	意図したsku.md/0.10-draft契約とSchemaを必須にする
10	オンライン検証を省略	offline_documentだけでなくpublished_resourceとdocument_graphを実行する

区分は正確に10個です。タイムアウト、リダイレクト回数、最大バイト数、プライベートネットワークの遮断、走査の深さなどの安全制限は検査方法の一部であり、区分をまとめたり省いたりする理由にはなりません。

トラブルシューティングの流れ

1. リダイレクトを無効にして正確なURLを要求し、200以外なら停止します。
2. Content-Typeを調べ、HTMLフォールバックと不正UTF-8を拒否します。
3. 安全なフロントマターを解析し、canonical、言語、文書種別、バージョンを比較します。
4. 公開応答を受理済みバイト列と派生本文に照合します。
5. 制限付きで同じオリジンのリンクをたどり、parent、canonical、発見経路を検証します。
6. オンライン検査レポートを保存し、経路、CDN、公開変更後に再実行します。

通信層の障害を文書Schemaの緩和で直してはいけません。失敗した層を修正します。

一般的なローカル検査が見落とす理由

エディターはHTTP要求なしでYAMLとJSON Schemaを検証できます。静的ビルドが正しいバイト列を生成しても、本番の/sku.mdがHTTP 200付きのブランド化404ページへ振り分けられる場合があります。ブラウザーは301応答を見せないまま追跡し、CDNはリポジトリの新版ではなく古い受理済みファイルを返すことがあります。

ローカルの手掛かり	隠れたオンラインリスク
Schema合格	URL、HTTPステータス、MIME、canonicalが誤り
読みやすく表示	リダイレクトまたはHTML互換表示
1つの商品URLが動く	ルートの親文書または同階層の文書グラフが破損
配備完了	キャッシュ済み・変換済みのバイト列

最後の有効版を失わずに修復する

公開前に生成・検証し、受理済みバイト列を不可分に置き換えます。新しい文書または経路が失敗したら、最後に正常と確認できたリソースを維持します。不明なリソースはソフトフォールバックではなく正確な404を返すべきです。v0.10の適合性範囲はオフライン文書、公開リソース、文書グラフの証拠を分離し、部分結果を完全と誤表示できないようにします。

関連資料

全体手順は最初のSKU.mdを公開するで、オファーの対応付け前の分類は安定した知識とライブデータで確認できます。

次のステップ

適合性テストを実行する