「一緒に買われる商品」も伝えられる。商品ページの新しい記述ルールとは？

「この商品とよく一緒に買われるもの」「商品の注意事項」を、機械にも意味が伝わる形で書く項目が増えました。2026年9月16日公開のSchema.org 30.1で追加された、商品情報の記述ルールです。[1]

商品ページに説明は書いてあるのに、AIが別売りの部品をセット内容と間違えたら困ります。通販サイトの担当者にとって大切なのは、商品名や価格だけでなく、仕様や関連商品の意味を正確に伝えることです。

Schema.orgは、Webページの情報へ共通の名前を付けるための語彙集です。例えば「商品」「価格」「在庫」といった意味を、サイトごとの独自の呼び方に頼らず表せます。この記事では新しい項目を読み、商品ページへ何を追加できるかを、架空のデスクライトの例で説明します。

確認日は2026年9月18日です。今回の項目は公開版に含まれますが、各項目のページには、利用者からの意見を集める「new」の表示があります。GoogleやChatGPTでの採用、検索順位の上昇まで決まったという発表ではありません。[1][2][3]

商品ページの文章と、機械向けの説明をそろえる

商品の情報を、決まった項目名でページへ付けるものを「構造化データ」と呼びます。ここでは、商品説明に意味のラベルを添えるものと考えると分かりやすくなります。

例えばページに「専用クランプもよく一緒に買われています」と書くだけでなく、機械向けにも「このライトと、そのクランプはよく一緒に買われる関係」と記します。検索サービスが文章から関係を推測する手掛かりを増やせます。ただし、書いた情報をどこまで使うかは、読み取るサービスによって異なります。

Googleは、商品ページの構造化データによって、価格や在庫などを検索結果へ詳しく表示できる場合があると説明しています。購入できるページと商品紹介のページでは、必要な項目も異なります。今回の新項目を加える場合も、すでに必要な商品名・価格などの記述を消して置き換えるものではありません。[4]

新しい三つの項目で、何を伝えられる？

今回の更新のうち、商品の説明に使う三つを見てみます。英語の項目名は、実装時に使う正式な名前です。

項目	伝える意味	デスクライトならどんな情報か
isOftenBoughtWith	よく一緒に買われる商品	購入記録で組み合わせを確認できた専用クランプ
specification	商品の仕様	光源の種類、サイズなど
consumerNotice	消費者向けの注意事項	屋内専用など、使う前に必要な注意

isOftenBoughtWith は、対象商品に別の「商品」を結び付ける項目です。「おすすめ」という宣伝文を入れる欄ではありません。また「一緒に買われる」ことと「本体に付属する」ことは異なります。[2]

specification には、項目名と値を一組にした情報を入れます。例えば「光源の種類：LED」です。こうした組を PropertyValue と呼びます。難しく見えますが、仕様表の一行を表すための名前です。[3]

consumerNotice は、安全上の警告や必要な注意を伝える項目です。文章だけでなく、注意事項を掲載したページへのリンクなども指定できます。商品に関係のない宣伝や、検索に入れたい語句を足すための欄ではありません。[5]

1．先に、ページで読める説明を確かめる

導入を考える担当者は、まず自社ECの公開商品ページを一つ開きます。コードを書く前に、次の三つが今の説明で分かるかを見ます。

• 商品の仕様は、項目と値の組み合わせで読めるか。
• セット内容と別売り品を区別できるか。
• 使用上の注意を、購入前に読めるか。

例えばライトの写真にクランプが写っていても、付属するのかは写真だけでは分かりません。「クランプは別売りです」と書いてあるかを確かめます。商品ページを編集できる担当者が、管理画面の商品説明や付属品の欄で不足を補います。画面の名前はECサービスによって異なるため、ここでは共通のボタンがあるとは扱いません。

「よく一緒に買われる」と書くなら、対象期間の注文記録で、その組み合わせを確認します。単に在庫を売りたいからという理由で作る情報ではありません。記録がなければ、その項目はまだ使わず、確認できる仕様や注意事項から整えます。

以下のコードは、これらを確認したと仮定する説明用の例です。架空のライトとクランプを使っており、実際の販売記録や安全表示ではありません。

2．一つの商品を、短いデータで表す

次のJSON-LDは、Webページに情報の意味を添えるための記述形式です。ここでは新項目の使い方が分かるよう、価格や在庫などを省略しています。Googleの商品表示に必要な項目をすべて備えた完成品ではありません。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "デスクライト L1",
  "sku": "LIGHT-L1",
  "isOftenBoughtWith": {
    "@type": "Product",
    "name": "別売り専用クランプ C1",
    "sku": "CLAMP-C1"
  },
  "specification": {
    "@type": "PropertyValue",
    "name": "光源の種類",
    "value": "LED",
    "valueGroup": "照明"
  },
  "consumerNotice": "屋内専用です。屋外では使用しないでください。"
}

読む順番は、上から「何の商品か」「一緒に買われる商品」「仕様」「注意事項」です。sku は店が商品を管理するための番号。ここでは LIGHT-L1 と CLAMP-C1 で、別の商品であることを示しています。

valueGroup の「照明」は、関連する仕様をまとめる見出しです。例えば仕様が増えたときに、寸法に関する項目と照明に関する項目を分けるために使います。Schema.orgでは、この値は文章で書くものとして定義されています。[6]

この例の isOftenBoughtWith は Product、specification は PropertyValue を受け取る定義と対応しています。[2][3] 商品の名称や注意文を変えて使う場合も、この入れ子の意味は保ちます。

実装時は、公開する前のプレビューで、商品名・仕様・別売り品・注意事項が同じ商品を指しているかを見比べます。商品データをECシステムが自動出力している場合は、ページへ別のコードを重ねて貼る前に、現在の商品データをどこで編集するか確認します。二つの異なる説明が出力されると、更新するたびに食い違いが起きるからです。

3．書き方の検査と、Googleの対応範囲を確認する

記述ができたら、最初に文法と項目の意味を確認します。Schema.orgの検査ツールで、コードを貼り付ける欄に対象データを入れるか、実装済みの公開ページを指定します。新しい語彙が検査側に反映されていない可能性もあるため、指摘が出たら、該当する公式項目ページの定義とも照合します。

次に、Google向けの表示条件はリッチリザルトテストで確認します。リッチリザルトとは、価格などの詳しい情報を含む検索結果です。ここへ自社の公開商品ページのURLを入れ、検出された商品情報と問題点を読みます。

二つの検査は目的が違います。Schema.orgの項目として書けることと、Googleが商品検索の表示に利用することを、同じ合否にまとめないようにします。Googleで表示させたい項目は、商品の構造化データの公式案内に沿って点検します。[4]

見つかった状態	次にすること
カンマや括弧の誤りがある	まず記述の文法を修正する
項目が受け取る型と違う	商品を入れる欄に文章だけを入れていないか、公式定義を読む
Googleが必要とする価格などがない	新項目とは別に、既存の商品表示の要件を満たす
検査は通るが検索で表示されない	検査の合格を掲載保証とせず、ページの登録状況や対応範囲を確認する

本文の仕様と機械向けの記述が食い違った場合は、両方を直します。例えば商品がLEDではなくなったとき、画面だけを更新して古いコードを残すと、読む相手によって異なる説明になります。更新する担当者と、どこから同じ情報を出すかも決めておくと点検しやすくなります。

AI対策として、今どこまで期待できる？

今回の変更は、商品を詳しく表す選択肢が増えたニュースです。追加するだけでGoogleのAIによる概要やChatGPTに採用される、という根拠にはなりません。

Googleは、AI機能への掲載に専用のSchema.org記述は必要ないと説明しています。ページが取得でき、重要な内容を文章で読め、構造化データと見える説明が一致することが基本です。[7]

そのため、優先順位は「必要な説明をページに書く」「今使っている商品データの誤りを直す」「新項目を試す」の順が考えられます。例えばGoogleに古い価格が出ているなら、先に価格が食い違うときの確認方法を使います。新項目を足しても、古い価格は解決しません。

関連商品や仕様をすでに正しく管理できている店舗は、一つのページで新項目を試し、表示中の内容と対応するかを確認できます。コードを足す前に商品説明そのものが足りない場合は、問い合わせから必要な答えを見つける方法から始めると、何を書くべきかが具体的になります。