商品寸法の構造化データ：誰も埋めないフィールド

商品寸法の構造化データは、目のあるものが誰も読まない部分です——そして今では、あなたの商品がそもそも回答に登場するかどうかを決める部分になりました。スペック画像に 600 × 320 × 720 mm と入れれば、買い手は読めます。しかしクローラー、ショッピングフィード、そして「奥行き 350 mm 未満の壁掛けキャビネットはどれか」に答えるアシスタントは、何も読み取れません。その数字はピクセルとしてしか存在していないからです。

商品寸法の構造化データとは、商品の物理的なサイズを機械可読な形で宣言することです。決まったフィールド名に数値を載せ、単位を明示し、商品ページ上の JSON-LD として公開するか、マーチャントフィードの列として渡します。このフィールドを定義している仕様はいま3つあり、名前は互いに食い違っていて、そしてほとんどのカタログはどれも埋めていません。

以下、このブロック全体をフィールド単位で見ていきます。コピー用のコードは最後にあります。

商品寸法の構造化データ：サイズを読む3つの仕様

最後の行は二度読んでください。ほぼすべてのカタログがはまる落とし穴がそこにあります。

Google の寸法フィールドが表すのは箱で、商品ではありません

shipping_length、shipping_width、shipping_height は任意項目で、センチメートルまたはインチを受け付け、1–400 cm または 1–150 inches の範囲に制限されています。Google はその役割を明言しています。配送業者計算の配送方法を使う場合に、送料を決める助けとして存在する、というものです。3つすべてを同じ単位でそろえて渡さないと、このデータはまったく使われません。

つまり、これが表しているのはカートンです。Merchant Center には、完成品そのものの寸法を入れる属性が存在しません。

このギャップがあるからこそ、product_detail はこのページで扱う他のどのフィールドよりも重要になります。他の属性でカバーされない技術仕様を、コロンをちょうど2つ使って区切る3部構成で載せます。

section_name : attribute_name : attribute_value

section_name は任意ですが推奨、attribute_name と attribute_value は必須です。Google 自身の例も Display:Size:13 inch や Battery:Capacity:12.5 hours という形をとっています。ということは、Google フィードで商品の実寸を置くべき正しい場所は、こうなります。

これをきれいに保つルールが2つあります。単位は attribute_value の中に入れてください——このフィールドは自由入力テキストで、「600」だけでは使えません。そして、すでに専用の属性があるものをここで言い直さないこと。Google は他でカバー済みの情報を重複させないよう求めており、価格や配送時期のデータもここでは明確に対象外です。

schema.org：4つのフィールドと、誰も使わない1つ

ページ側では、schema.org が Product に寸法プロパティを直接用意しており、それぞれ Distance または QuantitativeValue を受け付けます。

• width——「アイテムの幅。」
• height——「アイテムの高さ。」
• depth——「アイテムの奥行き。」
• weight——Mass または QuantitativeValue。

その次に size がありますが、これは種類の違うフィールドで、日常的に誤用されています。定義では XL や 32Wx34L のような素のテキスト、unitCode 付きの QuantitativeValue、あるいは完全な SizeSpecification が許されており、そのうえで、それらが合わない場合は「width、height、depth、weight の各プロパティのほうが適切な場合がある」とはっきり書かれています。アパレル以外を売る人向けに言い換えると、size は衣料のサイズ体系に使い、物理的な商品には4つの寸法プロパティを使う、そして 600x320x720 を文字列として size に入れない、ということです。

誰も使っていないフィールドが hasMeasurement です。Product に付ける QuantitativeValue で、そのアイテムの測定値を入れるためのものです——schema.org 自身の例は、パンツの股下、自転車のホイールサイズ、ネジの規格です。配列を受け付けるので、二次的な寸法はすべてここに入ります。棚板の内寸幅、座面高、固定の芯々寸法、開口寸法、ネジピッチ。買い手がメールで問い合わせてくるのは、まさにこの数字です。専用の標準フィールドがあるのに、ほぼすべてのカタログで空のまま置かれています。

単位は、unitCode に UN/CEFACT の3文字共通コードを入れます——MMT ミリメートル、CMT センチメートル、INH インチ、KGM キログラム、LBR ポンド。コードに確信が持てないときは、unitText に素の文字列を入れるのも有効で、間違ったコードよりましです。

コピー用：JSON-LD の寸法ブロック

既存の Product ノードの中に貼ってください。検証を通り、項目が揃っており、商品サイズとカートンサイズを意図的に分けてあります。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wall cabinet, 2-door, 600 mm",
  "sku": "WC-600-2D",
  "material": "Birch plywood, white melamine",
  "width":  { "@type": "QuantitativeValue", "value": 600, "unitCode": "MMT" },
  "height": { "@type": "QuantitativeValue", "value": 720, "unitCode": "MMT" },
  "depth":  { "@type": "QuantitativeValue", "value": 320, "unitCode": "MMT" },
  "weight": { "@type": "QuantitativeValue", "value": 14.2, "unitCode": "KGM" },
  "hasMeasurement": [
    { "@type": "QuantitativeValue", "name": "Internal shelf width",
      "value": 564, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Wall fixing centres",
      "value": 512, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Carton, longest side",
      "value": 760, "unitCode": "MMT" }
  ]
}

ChatGPT のフィードは同じ数字を別の名前で求めます

Agentic Commerce の商品フィード仕様——ChatGPT のショッピング面へ事業者が渡すファイルです——は寸法を2通りで受け取り、依存関係のルールが厳格です。

仕様には、物理的な特性と分類がカテゴリ分け・絞り込み・検索の関連性に役立つと書かれています。これは要するに、寸法のない商品は結果セットに絞り込まれない商品だ、という宣言です。買い手が奥行き 350 mm 未満のキャビネットを探していて、あなたの奥行きフィールドが空なら、順位が低いのではありません。存在しないのです。

正直に指摘しておく穴が1つあります。この仕様には梱包寸法用の別フィールドの定義がなく、dimensions が商品なのかカートンなのかも明記されていません。どちらを指すのかを、人とモデルの両方が読める場所で宣言し、カタログ全体で一貫させてください。

Google が表示しないのに、これらを埋める価値がある理由

ここは矛盾のように読めます。リッチリザルトの獲得条件を列挙している Google 自身の Product 構造化データのドキュメントに、width、height、depth、weight、hasMeasurement は含まれていません。サポート対象として挙がっているのは、価格、在庫状況、レビュー評価、配送、返品ポリシー、アパレルのサイズ、識別子、そして長所と短所です。

ですから、寸法のマークアップでスニペットが大きくなることはありません。もともとそういう役割ではありませんでした。

変わったのは読み手のほうです。Google は、product_detail は商品を理解し、検索の AI Mode のような AI 駆動の機能を含むさまざまな面で表示するのに役立つ構造化データを提供する、と述べています。Agentic Commerce のフィードは、チャットの中で商品が見つかり絞り込めるようにするために存在します。これらのシステムは、表示テンプレートがなくても動きます——必要なのは、条件と突き合わせられる属性です。寸法フィールドはもう検索結果の飾りではありません。検索の対象に入るための資格そのものです。

これで優先順位が変わります。これらを埋めるのは、質問に答えるエンジンのためであって、枠を描くエンジンのためではありません。

すべてを壊すルール：1つの数字が2か所にある

商品寸法の構造化データで見てきた失敗は、どれも根っこが同じです——フィードが言う数字と、画像が言う数字が食い違っているのです。

悪意なく起こります。誰かがカートンのサイズを shipping_width に入れ、別の誰かがスペック図のために組み立て後の実物を測り、3人目が product_detail で 564 mm を 56 cm に丸める。するとアシスタントは自信たっぷりに「このキャビネットは幅 640 mm です」と買い手に伝え、買い手が見ている画像には 600 と書いてある。信頼の問題と返品を、自分で1つずつ作り出したことになります。さらに悪いのは、引用されるのが機械が読んだ数字のほうだという点です。読める形になっていたのはそちらだからです。

直し方はマークアップではなく運用です。**一度測り、その同じ測定値をフィールドと画像の両方へ流す。**具体的には——

1. 図面でもカートンでもなく完成品を測り、それぞれの数字が何を指しているかを記録します。
2. 各数字は、それが説明している箇所のすぐそばに——商品の実際のエッジにスナップさせ、近くに浮かせずに——画像上へ置き、各プラットフォームのスペック図サイズで書き出します。寸法注記のために作られたソフトはこれを決定論的に行います。矢印を手で置く汎用の画像編集ソフト、あるいは測ってもいない寸法を平然と描く画像生成モデル（それが最適化しているのは「もっともらしさ」です）との決定的な違いがここにあります。
3. 同じ数字を width/height/depth、product_detail、そしてフィードの寸法フィールドに写します。同じ出所、同じ丸め、同じ単位で。
4. 数字が変わったら、同じコミットで両方を変えます。ずれたペアは、欠けているよりたちが悪いです。

この対応の画像側について、実例は商品サイズ表示のケーススタディにあります。輸出事業者の半分がつまずく単位の問題は、商品寸法は cm かインチかで扱っています。

公開前チェックリスト

• Product ノードに width、height、depth があり、それぞれ unitCode または unitText 付きの QuantitativeValue になっている
• weight が単位付きで入っている
• 買い手が実際に聞いてくる二次的な寸法はすべて、説明的な name を付けて hasMeasurement に入っている
• size は衣料のサイズ体系にのみ使用——600x320x720 のような文字列はない
• フィード：shipping_length / shipping_width / shipping_height が3つそろい、単位が同じで、カートンを表している
• フィード：組み立て後の商品寸法は product_detail に入れ、単位は値の中、1件あたりコロンはちょうど2つ
• フィード：専用属性があるデータを重複させていない。product_detail に価格や配送時期を入れていない
• Agentic フィード：dimensions を単位付きで、または length+width+height に加えて dimensions_unit
• Agentic フィード：weight を item_weight_unit なしで送っていない
• 商品寸法とカートン寸法が、登場するすべての場所で区別できるようラベル付けされている
• マークアップ内のすべての数字が、スペック画像に印字された数字とミリ単位まで一致している
• その一致に責任を持つ担当者が1人決まっていて、片側だけを誰かが直すことがない

FAQ

商品寸法を構造化データに追加するにはどうしますか？

JSON-LD の Product ノードに width、height、depth、weight を置き、それぞれ数値の value と unitCode を持つ QuantitativeValue にします。それ以外の測れる特徴は、説明的な name を付けて hasMeasurement の項目として追加します。Google フィードでは、組み立て後のサイズは shipping_* ではなく product_detail に入れます。

Product schema の width、height、depth は Google に使われますか？

リッチリザルトには使われません。Google がサポートする商品プロパティは価格、在庫状況、レビュー、配送、返品ポリシー、アパレルのサイズ、識別子、長所と短所で、物理寸法はその一覧にありません。それでも AI 駆動の面での検索対象化と比較には効きます。役割が別で、いまはそちらのほうが大きくなっています。

shipping_length と商品の実寸は何が違いますか？

shipping_length、shipping_width、shipping_height は配送用の梱包を表し、配送業者計算の料率を出せるようにするために存在します。商品の完成寸法ではないので、そこに入れるべきではありません。Merchant Center には組み立て後サイズ専用の属性がなく、だからこそ product_detail が正しい置き場所になります。

JSON-LD の寸法にはどの単位コードを使いますか？

unitCode には UN/CEFACT の3文字共通コードを入れます——MMT はミリメートル、CMT センチメートル、INH インチ、KGM キログラム、LBR ポンド。ある単位のコードに確信が持てないときは、代わりに unitText に素の文字列を入れてください。読めば分かる unitText は、間違った unitCode に勝ります。

フィードに入れてあれば、商品画像に寸法は不要ですか？

必要です。理由は対称的です。機械はフィールドを読み、あなたの画像は読めません。買い手は画像を読み、あなたのフィードを開くことは一生ありません。寸法図は画像であり、あなたの商品が回答に出るかを決めるシステムはどれもテキストを読みます——だから両方を出し、ミリ単位まで一致させてください。買い手が動くように画像側をどう書くかは商品寸法を買い手に伝えるで扱っています。間違えたときのコストを金額で知りたい場合は、返品コスト計算ツールがその計算をします。

出典・参考資料

• schema.org Product —— width、height、depth、weight、size、hasMeasurement
• schema.org QuantitativeValue —— value、unitCode、unitText
• Google Merchant Center —— 配送寸法の属性とその上限
• Google Merchant Center —— product detail [product_detail] 属性
• Google Search Central —— Product 構造化データとサポート対象プロパティ
• Agentic Commerce —— 商品フィード仕様