III-B6 Product・Reviewを実装する
商品情報やレビューを検索エンジンに伝えるマークアップ
このレッスンの狙い:Product・ReviewのJSON-LDを実装できる
最終更新: 2026-07-23
この記事の要点
- Product・ReviewのJSON-LDを実装できる
- Productスキーマが伝える3つの要素
- ReviewとAggregateRatingの使い分け
ECサイトの商品ページや比較記事で「価格」「在庫状況」「評価」をAIや検索エンジンに正確に伝えるための構造化データが、ProductとReviewです。III-B2で学んだJSON-LDの基本構文(III-B2参照)を土台に、商品情報とレビュー情報を機械可読な形で渡す書き方を、自社ページにそのまま実装できるレベルまで具体的に扱います。
Productスキーマが伝える3つの要素
Productスキーマは、ページに掲載された商品やサービスの基本情報を伝える構造化データです。最低限おさえておきたいのはname(商品名)・brand(ブランド)・offers(販売条件)の3つで、特にoffersは単独の項目ではありません。price(価格)・priceCurrency(通貨、ISO 4217形式)・availability(在庫状況)の3点が揃って初めて要件を満たすという点を押さえておいてください(出典: schema.org/jsonld.com, 2026年7月確認)。この3点のどれか1つでも欠けると、機械的には不完全な商品情報として扱われます。
ReviewとAggregateRatingの使い分け
個別の口コミはReview、複数の評価をまとめた平均点・件数はAggregateRatingとして実装します。AggregateRatingはratingValue(評価値)とreviewCount(件数)を持ち、ReviewはauthorとreviewRating、reviewBody(本文)を持ちます。ここで大事なのは、実際に集まった評価・レビューだけを反映するということです。表示するだけの実データがないのに数値を埋めるのは、実装の巧拙以前の信頼性の問題になります。
実装コード例
以下は書き方の型を示すための説明用サンプルです。ブランド名・商品名は架空の「サンプル株式会社」「オンライン講座サンプル」を使用し、price・ratingValue・reviewCountの数値もすべて説明用の仮の値です。実装するときは、自社の実在するブランド名・商品名に置き換えたうえで、priceは自社の実際の販売価格、ratingValue・reviewCountは実際に集まった評価件数のみを入れてください。実データが無い段階でaggregateRatingごと省略しても問題ありません。
{
"@context": "https://schema.org",
"@type": "Product",
"name": "オンライン講座サンプル",
"brand": {"@type": "Brand", "name": "サンプル株式会社"},
"offers": {
"@type": "Offer",
"price": "98000",
"priceCurrency": "JPY",
"availability": "https://schema.org/InStock",
"url": "https://example.com/courses/sample-course"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "38"
}
}個別のReviewは、Product本体とは別に次のように実装し、itemReviewedで紐づけます(こちらも同様に、author名・reviewBodyは説明用のサンプルです)。
{
"@context": "https://schema.org",
"@type": "Review",
"itemReviewed": {"@type": "Product", "name": "オンライン講座サンプル"},
"author": {"@type": "Person", "name": "受講者A"},
"reviewRating": {"@type": "Rating", "ratingValue": "5", "bestRating": "5"},
"reviewBody": "実務にすぐ使える内容で、AI検索の仕組みが体系的に理解できました。"
}よくある実装ミス
現場でよく見るミスは、offerのprice・priceCurrency・availabilityのいずれかが抜けているケースと、brand名の表記がOrganizationスキーマ(III-B3参照)と食い違っているケースです。brand名を揃え@idで接続すると、AIにとって同一エンティティと認識されやすくなります。
実践ステップ
- 商品・サービスページを一覧化し、Productスキーマ未実装のページを洗い出す
- 各ページのofferにprice・priceCurrency・availabilityの3点が揃っているか確認する
- 実際に集まったレビュー件数と評価値がある場合のみAggregateRatingを追加する
- 個別のReviewを載せる場合は、実在するレビュー本文・投稿者名の範囲で実装する
- brand名の表記をOrganizationスキーマと統一し、可能であれば
@idで接続する - 実装したJSON-LDを本番ページに反映する(検証ツールでの確認手順はIII-B9で扱う)
まとめ
Productスキーマはname・brand・offersの3要素、なかでもoffersのprice・priceCurrency・availabilityが揃って初めて意味を持ちます。Reviewは個別の口コミ、AggregateRatingは平均点と件数という役割分担であり、どちらも実データの範囲でのみ実装するのが信頼性の土台です。本レッスンのコード例のブランド名・数値はすべて説明用のサンプルであり、実装時は自社の実名と実際の数値に置き換えてください。この実装が引用そのものを保証するわけではないという一歩踏み込んだ検証は、III-B10に譲ります。
このレッスンはテキストとスライドで学べます。スライドは上のビューアからご覧ください。
確認テスト
選択肢をクリックすると、その場で正誤と解説が表示されます。
Q1. Productスキーマのofferは、price・priceCurrency・availabilityの3点が揃って初めて要件を満たすとされている。
offersはprice・priceCurrency・availabilityの3点が揃って初めて要件を満たすと本文に明記されています。
Q2. 複数の口コミの平均点・件数をまとめて伝える型はどれか。
AggregateRatingがratingValueとreviewCountを持ち、平均点・件数をまとめて伝えます。
Q3. 実データが無い段階での対応として推奨されているのはどれか。
実データが無い段階ではaggregateRatingごと省略しても問題ないとされています。
このレッスンのFAQ
Q. レビュー実績がまだない商品ページにAggregateRatingを入れてもいいですか?
推奨されません。実際に集まった評価・レビューだけを反映するのが基本で、実データが無い段階ではaggregateRatingごと省略しても問題ないとされています。
Q. offerのpriceだけ設定すれば十分ですか?
不十分です。price・priceCurrency・availabilityの3点が揃って初めて要件を満たすとされています。
Q. brand名の表記で気をつけるべき点は何ですか?
Organizationスキーマでのbrand名表記と食い違わないよう統一し、可能であれば@idで接続することが推奨されています。