Review・AggregateRating schemaの実装手順

Review schemaは、正しく書いても星評価が出ないことがある構造化データです。プロパティの記述ミスではなく、レビューを誰が管理しているかというポリシーの側で対象外になるためです。本記事では、Review・AggregateRating両方のコピペ可能な実装テンプレートを示します。あわせて、この見落としやすいポリシーをschema.orgとGoogle公式ドキュメントから解説します。

01この記事でわかること

• Review・AggregateRating、それぞれの必須プロパティと推奨プロパティ
• 個別レビューと集計評価、それぞれのコピペ可能なJSON-LD実装テンプレート
• 自己申告レビューが星評価の対象外になるポリシーと、対象となる型
• ratingValue・bestRating・worstRatingの正しい書き方
• 実装後の検証方法とよくある失敗パターン

03Review schemaとは（基礎定義）

Review型は、schema.orgが定義する語彙の一つです。Review型固有のプロパティは、itemReviewed（対象）・reviewRating（評価）・reviewBody（本文）です（出典: schema.org公式）。author（作成者）はReview型固有ではなく、上位のCreativeWorkから継承されるプロパティです（出典: schema.org公式）。

Google公式は、Review snippetという機能名でこの構造化データを扱っています。ページ上のレビューや評価の抜粋を、検索結果に星の形で表示する仕組みです（出典: Google公式）。この機能に対応するコンテンツ型はGoogle公式ドキュメントに一覧で示されているため、着手前に自社ページの型が含まれるかを確認してください。レビュー投稿者を著者として明示する場合は、別記事『著者Person schemaの書き方とE-E-A-T効果』も参考になります。

以下、Review型・AggregateRating型の順に、必須プロパティとテンプレートを整理します。

04Review型の必須プロパティと実装テンプレート

Review型でリッチリザルトの対象になるには、次のプロパティが必須です（出典: Google公式）。JSON-LDの基本的な書き方は、別記事『JSON-LDの書き方基礎｜3つの実装例で学ぶハンズオンガイド』で解説しています。

コピペ可能なテンプレートは次の通りです。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "商品名をここに入力",
  "review": {
    "@type": "Review",
    "author": {
      "@type": "Person",
      "name": "レビュー投稿者の氏名"
    },
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "4",
      "bestRating": "5",
      "worstRating": "1"
    },
    "reviewBody": "レビュー本文をここに入力",
    "datePublished": "2026-07-28"
  }
}

itemReviewedは、上の例のようにReviewをProduct等の中にネストして書けば省略できます（出典: Google公式）。ただし省略した場合も、レビュー対象の名前（親要素のname）は必要です（出典: Google公式）。独立したReviewとして書く場合は、itemReviewedプロパティを明示してください。親要素に使ったProduct型そのものの実装は、別記事『Product schemaの書き方｜EC商品ページの構造化実装手順』で解説しています。

05AggregateRating型の必須プロパティと実装テンプレート

AggregateRatingは、複数のレビュー・評価をもとにした平均評価を表す型です。次のプロパティが必須です（出典: schema.org公式・Google公式）。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "商品名をここに入力",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.4",
    "ratingCount": "89",
    "bestRating": "5",
    "worstRating": "1"
  }
}

Google公式は、複数の個別レビューを掲載しているページでは、AggregateRatingも併記することを推奨しています（出典: Google公式）。ratingValueには、数値（4・4.4）、分数（6 / 10）、パーセンテージ（60%）のいずれかを使えます。小数点はドット記号で表記し、カンマは使いません（出典: Google公式）。

06自己申告レビュー禁止のポリシー——対象はLocalBusinessとOrganization

プロパティを正しく書いても星評価が出ない場合、原因の多くはこのポリシーにあります。Google公式は、次のように明記しています。

対象企業自身がレビューを管理している場合、LocalBusinessやOrganization型のページは星評価機能の対象外になります（出典: Google公式）。たとえば、企業Aについてのレビューが企業A自身のサイトに掲載されているケースが該当します（出典: Google公式）。このポリシーが明記されているのは、LocalBusinessとOrganization型に対してです。

Product型のレビューについては、この自己申告レビュー禁止の記述は確認できた公式資料の範囲では見当たりませんでした。ただし、Google公式は虚偽レビューやインセンティブ付きレビューを一般的なガイドライン違反として禁止しています（出典: Google公式）。型を問わず、実際のレビューだけを掲載する運用が前提です。

07実装時の注意点——画面表示との一致と評価スケールの明示

Google公式の一般ガイドラインは、構造化データ全般に共通する原則も示しています。「ページの実際に表示されている情報についてだけ、構造化データを記述すること」というものです（出典: Google公式一般ガイドライン、原文の趣旨を要約）。

bestRating・worstRatingを省略した場合の既定値は、5段階評価を前提に5と1になります（出典: Google公式）。10段階評価やパーセンテージ評価を使う場合は、必ずbestRating・worstRatingを明示してください。

なお、構造化データの充実度とAI引用率の関係は、研究間でも結論が割れています。詳しくは別記事『Schema markupとAI引用の相関｜SSRN論文検証』で検証しています。EC事業者が商品ページのレビュー情報を整備する実務は、別記事『EC事業者のPerplexity対策｜商品ページ引用の条件整理』でも扱っています。

08実装後の検証手順（4ステップ）

実装したら、公開前に次の4ステップで検証します。構文が通っていることと、ポリシー上問題がないことは別々に確認してください。

1. リッチリザルトテストにかける: 公開済みならURLを、未公開ならJSON-LDのコードを貼り付けて実行します。検証ツールの詳しい使い方は、別記事『構造化データのテスト・検証ツールの使い方｜旧ツールとの違いも解説』で解説しています
2. 検出結果に対象の型が出ているか見る: Review・AggregateRatingが検出項目に現れなければ、記述場所（親要素とのネスト関係）を見直します
3. エラーと警告を分けて処理する: エラーは必須プロパティの欠落、警告は推奨プロパティの未設定を指すことが多い区分です。エラーは公開前に解消し、警告は表示の充実度に関わる改善項目として扱います
4. 画面表示と突き合わせる: 実際のページを開き、表示されている評価点・件数・レビュー本文がschemaの記述と一致しているかを目視で確認します

構造化データを実装しても、検索結果でのリッチリザルト表示が保証されるわけではありません（出典: Google公式）。検証はあくまで「表示され得る状態になっているか」の確認である点は、社内共有時にも伝えておくと期待値のずれを防げます。

09チェックリスト

• 対象ページのコンテンツ型が、Google公式のレビュー抜粋対象に含まれているか確認している
• Review型に、author・itemReviewed・reviewRating（ratingValue含む）を実装している
• AggregateRatingに、ratingValueとratingCount（またはreviewCount）を実装している
• itemReviewedをネストして省略した場合も、対象の名前（親要素のname）を書いている
• LocalBusiness・Organization型で、自己申告レビューに該当していないか確認している
• 画面に表示されているレビュー内容と、schemaの記述内容が一致している
• bestRating・worstRatingを、実際の評価スケールに合わせて明示している（5段階以外の場合）
• Rich Results Testで、エラー・警告がないことを確認している

10よくある失敗

Product型でも自己申告レビュー禁止だと思い込んでしまう。このポリシーが明記されているのはLocalBusinessとOrganization型です。ただし型を問わず、虚偽レビューや誇張された評価点は一般ガイドライン違反になります。

評価点を実際より高く見せようと数値を調整してしまう。構造化データは、ページに表示されている実際の情報と一致させる必要があります。画面に表示されていない評価点を、schemaにだけ書き足すことは避けてください。

AggregateRatingだけを実装し、個別のレビュー本文をページに掲載しない。Googleの一般ガイドラインは、ユーザーが実際に読めるレビューや評価であることを前提としています。集計値だけを示し、根拠となる個別レビューが画面に存在しない実装は避けるべきです。

11FAQ

12まとめ

Review schemaは個別のレビュー本文と評価点を、AggregateRatingは複数評価の集計値を、それぞれ機械可読な形式で記述する構造化データです。実装テンプレート自体はシンプルですが、自己申告レビュー禁止というポリシーへの理解が欠かせません。

このポリシーが明記されているのは、LocalBusinessとOrganization型です。Product型を含め、いずれの型でも画面表示の内容とschemaの記述を一致させることが、実装の大前提になります。