AggregateRating スキーマ

TL;DR — AggregateRatingは、ページに追加して「この項目の平均評価は、これだけの評価のうち4,6個の星です」と示すコードです。一部の検索結果の下に表示される⭐ 星のスニペットを生みます。通常は、評価対象（商品、レシピ、事業者など）のマークアップの内側にネストします。Googleは評価対象を直接指定する単独形式も認めていますが、一般的なのはネスト形式です。また、自分の事業者を評価しただけで星が表示されるわけではありません。Googleがブロックします。

AggregateRatingスキーマとは

ページに**「4.6 ★（218件の評価）」**のような表示があると、人間なら一目で意味を理解できます。検索エンジンは通常のテキストとして読み、数字が何を表すのか推測しなければなりません。AggregateRatingは、共有語彙であるschema.org を使って、コード上でその意味を明示します。平均スコア、基になった評価数、評価の尺度をラベル付けするものです。 Evidence for this claim Schema.org AggregateRating represents a rating based on a collection of ratings or reviews and is attached to the item being rated. Scope: Schema.org vocabulary; Google feature eligibility depends on the host type and documented requirements. Confidence: high · Verified: 2026-07-14 Schema.org: AggregateRating

重要なのはaggregate（集計）という言葉です。多数の評価の平均を意味します。一人の文章による意見をマークアップするReviewスキーマとは異なります。両方を持つページでは、全体の平均を一つのAggregateRatingで示し、個別のReviewもいくつか添えることが多いです。

ほぼ常にJSON-LDで記述します。ページの表示を変えずに置ける小さなコードブロックです。

実装する価値がある理由

得られる効果は星評価のリッチリザルトです。検索結果の下に金色の星と評価数が表示されます。星のあるリストは目立ち、クリックを増やせる可能性があります。そのためにGoogleが必要とする要素は次のとおりです。

• ratingValue — 4.6のような平均スコアです。
• 少なくとも一つの件数 — ratingCount（評価の総数）またはreviewCount（星評価の有無を問わずレビューを残した人数）のどちらかです。どちらか一つが必要です。
• itemReviewed — 評価対象です。AggregateRatingを商品、レシピなどの内側にネストする場合は、そのネストで対象が示されるため省略できます。ただし、いずれの形式でも評価対象には名前が必要です。 Evidence for this claim Google supports aggregate ratings in review snippets only for eligible item types and qualifying content. Scope: Google Search review snippet requirements; stars are not guaranteed. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

必要に応じて、bestRatingとworstRatingで尺度を示します。省略するとGoogleは1〜5と仮定します。

多くの人が間違える点

自分の事業者にAggregateRatingを追加しても星は表示されません。 ローカルビジネスや企業のサイトで「お客様は私たちを4,9個の星と評価しています」とマークアップしても、Googleはその星を表示しません。これは事業者が自分自身を評価する自己提供に当たり、特にLocalBusinessとOrganizationのマークアップでブロックされます。

ただし、ここで全員が混乱しやすい点があります。これは「自分のものを評価してはいけない」という一律のルールではありません。オンラインショップは、自社の商品ページに星評価を正当に表示できます。対象外なのは事業者が事業者としての自分自身を評価する場合であり、店舗が販売商品の真正な顧客評価を表示する場合ではありません。

初心者がもう二つつまずきやすい点があります。

• 平均だけでなく、必ず件数が必要です。 「4,6個の星」のように、評価数の裏付けがない平均だけでは不十分です。
• 評価は実在する必要があります。 評価を偽造したり購入したりすることはルール違反であるだけでなく、ページからリッチリザルトを削除する手動対策につながることがあります。

必要なプロパティ、ratingCountとreviewCountの違い、自己提供レビューの正確な範囲、Search Consoleの一般的なエラーの直し方を知りたい場合は、Advancedタブへ切り替えてください。

TL;DR — AggregateRatingは通常、親タイプのaggregateRatingプロパティ（Product、LocalBusiness、Recipe、Book、Course、Event、Movie、SoftwareApplicationなど）の内側にネストします。そのため、ネスト例ではitemReviewedを省略できます。一方、Googleの仕様は評価対象をitemReviewedで直接指定する、ネストしないAggregateRatingもサポートしています。どちらの場合も、評価対象には名前が必要です。星のリッチリザルトに必要なのはratingValue、ratingCount／reviewCountの少なくとも一方、ネストしていない場合のitemReviewedです。bestRating／worstRatingは推奨され、1〜5以外の尺度では不可欠です。正確に理解すべき適格性ルールは、自己提供評価が星機能の対象外になるのは**LocalBusiness／Organizationで事業者自身を評価する場合だということです。商品、レシピ、映画など、他の多くの対応タイプは真正な評価なら対象になり得ます。ratingCount（星だけの評価を含むすべての評価）とreviewCount（評価の有無を問わずレビューを残した人）は異なる数字です。有効なマークアップが得るのは星の適格性**であってランキングではなく、偽造評価は構造化データの手動対策を招くことがあります。このトピックは構造化データとeコマースSEOの両方に関連します。評価マークアップはeコマース監査で繰り返し確認する項目だからです。

AggregateRatingとReviewの違い — すべての基礎となる区別

競合ガイドの多くは、この二つのタイプを一つの要件リストにまとめてしまいます。しかし、両者は別物です。

• Reviewは、ある項目について一人のレビュアーが述べた意見をマークアップします。一人の人物、一つのreviewRating、レビュー本文です。
• **AggregateRating**は、多数の評価の統計的な平均をマークアップします。ratingValueと件数で表します。

実際の実装では、同じ親タイプの内側で両方を使うことが多いです。全体スコアにはaggregateRatingを使い、個別の意見にはreviewオブジェクトの配列を使います。Googleの指針は一方向です。複数の個別レビューをすでにマークアップしているなら、その横に集計評価を追加します。だからといって、AggregateRating単独のページに個別のReviewオブジェクトを創作して添える必要はありません。集計評価だけで個別レビューがないページも、通常どおり完全な実装です。一つだけ覚えるなら、Review＝一人の意見、AggregateRating＝多数の平均です。一人のレビュアー側については、姉妹記事のReviewスキーマを参照してください。

ネストと非ネスト — 取り付け方は二つ

AggregateRatingは単独のページでは独立した意味を持ちませんが、「必ずネストしなければならない」というわけでもありません。Googleは二つの形をサポートしています。

• ネスト（一般的な形式） — AggregateRatingを別のタイプのaggregateRatingプロパティ（Product、LocalBusiness、Recipe、以下の対応リストなど）の内側に置きます。親タイプがすでに項目を識別するため、ネストしたAggregateRatingではitemReviewedを省略できます。ただし、親項目にはnameが必要です。
• 非ネスト — AggregateRatingを単独で置くこともできます。その場合は評価対象を示すitemReviewedを指定します。実務では少ない形式ですが、文書化された有効な方法であり、回避策ではありません。

どちらの形でも、レビュー対象の名前はどこかに必要です。ネストなら親に、非ネストならitemReviewedの内側に置きます。Googleがレビュー／星のリッチリザルトでサポートするホストタイプは有限で、Book、Course、Event、LocalBusiness、Movie、Product、Recipe、Software Appに加え、CreativeWorkSeason、CreativeWorkSeries、Episode、Game、MediaObject、MusicPlaylist、MusicRecording、Organizationなどの追加のネストタイプがあります。

実務上の帰結は、対応していないタイプにaggregateRatingを置いても、マークアップがきれいに検証されるだけでは星は表示されないということです。検証とリッチリザルトの適格性は別の基準です。

必須プロパティと推奨プロパティ

Googleの星のリッチリザルト仕様は、素のschema.orgより厳格です。itemReviewedの扱いは、どの形を使うかで変わります。

schema.orgの利用メモには、避けられる検証エラーにつながる書式ルールが二つあります。見た目の似たUnicode記号ではなく実際の数字文字（0–9）を使い、コンマではなく小数点としてピリオドを使います。"4,6"は、小数点にコンマを使う地域でよくある誤りです。

ratingCountとreviewCount — 実際には異なる数字

多くのガイドはこの二つを同じ意味で使ったり、reviewCountを「文章によるレビュー」だけに縮めたりします。しかしGoogleの現在のプロパティ定義は、より具体的です。

• ratingCount — 評価の総数です。レビュー本文を伴わない星だけの投稿も含みます。
• reviewCount — レビューを提供した人数です。評価を伴っていてもいなくても含みます。「文章によるレビューだけ」に限定されず、数値評価を残したかどうかではなく、レビューを行った人を数えます。

実際には、ほとんどの評価／レビュープラットフォームでこの二つは異なる数字になります。星だけを残してレビューを書かない人もいれば、レビューを書いて星を付けない人もいるからです。店舗が4,6個の星をratingCount1 200件から得ている一方、340人（reviewCount）だけがレビュー本文を残していることもあります。上の定義を自分のプラットフォームが「評価済み」と「レビュー済み」をどう分けているかに当てはめ、サイトの分け方がこの例と一致すると決めつけないでください。Googleは二つのプロパティの少なくとも一方を要求します。実際に追跡している方を使い、ページが支えられない数字へ水増ししないでください。

デフォルトの尺度から外れるならbestRating／worstRatingを含める

これらを省略するとGoogleは1〜5の尺度を仮定します。1〜10、100点満点、その他のデフォルト以外の範囲で評価する場合は、bestRating／worstRatingを必ず設定してください。そうしないとGoogleが尺度を読み違える可能性があります。たとえば、10点満点の9.2を注記なしで置くと、5点満点中9,2のように解釈され、意味をなしません。

自己提供レビューのルール — 範囲を正確に限定する

このトピックで最も誤解されている点なので、正確に述べます。

Googleの文言は次のとおりです。“If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” (翻訳)「評価対象のエンティティ自身が自分についての評価を管理している場合、LocalBusinessまたはその他のOrganization構造化データを使うページは星のレビュー機能の対象外です。」範囲を正確に読むと、LocalBusinessとOrganization（およびそのサブタイプ）が対象です。つまり、事業者そのものに対する評価の話です。 Evidence for this claim Google requires ratings represented in structured data to be visible to users and prohibits misleading or fabricated review markup. Scope: Google Search structured-data and review snippet policies; violations can remove feature eligibility. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

これはProductには適用されません。オンラインショップは、自社の商品ページに正当に星評価を表示できます。販売している商品の真正な顧客評価の平均であり、事業者が自分自身を評価しているわけではないからです。Recipe、Movie、Book、SoftwareApplicationなど、対応リストの他のタイプも、評価が真正である限り対象になり得ます。

このルールは、Googleが方針を変更した2019年9月にさかのぼります。「Making Review Rich Results more helpful」で、第三者ウィジェットを通じて直接または取り込んだ自社事業者のレビューも含め、自己提供という考え方が導入されました。（ここではその告知の理由を要約しており、引用しているわけではありません。現在引用できるルールの文言は、上で引用したReview snippetの文書です。）要するに、自分のLocalBusiness／Organizationページに第三者レビューウィジェットを置いても、依然として自己提供であり、星の対象外です。

Organizationが、姉妹記事のOrganizationスキーマに意味がある理由です。自分でホストする評価が星を獲得できない二つのホストタイプの一つだからです。

真正な評価だけ — スパムと手動対策の方針

Googleの指針から、平易なルールを二つ挙げます。

• 他サイトから集約しない。 Googleの指針は、“Don’t aggregate reviews or ratings from other websites.” (翻訳)「他サイトのレビューや評価を集約しないでください。」です。他所から評価をスクレイピングして自分のマークアップに取り込むことはできません。
• 評価は実在のユーザーによるものにする。 Googleの構造化データ方針は真正な評価を強制される要件として扱います。レシピ固有の例でも、“reviews or ratings not by actual users may result in manual action.” (翻訳)「実際のユーザーによるものではないレビューや評価は、手動対策につながる可能性があります。」と説明されています。この原則は各タイプのレビュー方針に広く当てはまります。

誤解を招く、または偽の評価に対する構造化データの手動対策は、そのページのリッチリザルト適格性を取り消します。これは実際に適用される措置で、理論上の話ではありません。また、レビュー本文をページ上に本当に表示してください。Googleは、マークアップした評価が同じページのユーザーにすぐ見える状態で、カテゴリや一覧ではなく特定の項目に関するものになっていることを期待します。

AggregateRatingをより広い文脈に置く

他の構造化データと同様、AggregateRatingが影響するのはリッチリザルトの適格性であってランキングではありません。より広いSchema MarkupとStructured Dataのハブがこの点を詳しく扱うため、ここでは繰り返しません。aggregateRatingは、実務で最も一般的なホストであるProductと、バリエーション単位の評価集計に使うProductGroupで推奨されるプロパティです。どちらも次に読むとよい内容です。JSON-LDを使ってください。Googleが推奨する形式であり、この記事の例がすべて使っている形式でもあります。

Bingや他の検索エンジン： schema.orgはGoogle、Microsoft、Yahoo、Yandexが共同で使う語彙で、Bingの一般的な構造化データ文書はschema.org／JSON-LDマークアップを読むことを確認しています。ただし、GoogleのAggregateRating要件とタイプ単位で同等だという主張を、現在のMicrosoft一次資料で検証することはできません。Bingには、タイプ別の必須／推奨内訳も、Googleのような自己提供レビュー方針の文書もなく、評価のリッチリザルト面も狭く、文書化が少ないためです。Bingの適格性ルールがGoogleと一点ずつ一致すると仮定しないでください。Bing自身がAggregateRating固有のガイダンスを公開するまでは、確認済みの事実ではなく未解決の問いとして扱います。

AIサマリー

Advanced版の要点をまとめます。

• これは何か: schema.org/AggregateRatingのマークアップ（通常はJSON-LD）で、ある項目に対する複数の評価の平均を表します。一人のレビュアーの意見を表すReviewとは異なります。複数の個別レビューをすでにマークアップしている場合、Googleは集計評価も求めますが、その逆ではありません。
• ネストするか単独にするか: AggregateRatingは通常、親タイプのaggregateRatingプロパティ（Product、LocalBusiness、Recipe、Book、Course、Event、Movie、SoftwareApplicationなど）にネストします。そのためネスト例ではitemReviewedを省略します。一方、itemReviewedを直接指定する単独のAggregateRatingもGoogleはサポートしています。どちらの形でも、評価対象には名前が必要です。
• 星のリッチリザルトに必要なもの: ratingValue、ratingCountまたはreviewCountの少なくとも一方、そしてネストしていない場合のitemReviewed。bestRating／worstRatingは推奨で、既定の1–5以外の尺度では特に重要です。
• ratingCountとreviewCountの違い: ratingCountは星だけの投稿を含むすべての評価数、reviewCountは評価の有無を問わずレビューを残した人数です。数字は異なるため、両方ではなく実際に追跡しているものを使います。
• 自己提供ルールの範囲: 自己提供の評価が星機能の対象外になるのは、LocalBusiness／Organizationで事業者自身を評価する場合です。このルールは2019年9月に導入されました。**Product、Recipe、Movieなどは、真正な評価なら対象になり得ます。**自社事業者のレビューを第三者ウィジェットで表示しても、自己提供である点は変わりません。
• 対応ホストタイプは有限です: Book、Course、Event、LocalBusiness、Movie、Product、Recipe、SoftwareApplicationなどです。未対応タイプでは、マークアップが検証を通っても星は表示されません。
• 真正な評価だけを使う: 「他サイトのレビューや評価を集約しない」。偽の評価やインセンティブ付き評価は、ページのリッチリザルト適格性を取り消す構造化データ手動対策につながる可能性があります。
• 書式: 実際の数字（0–9）と小数点を使い、コンマは使いません。
• 適格性はランキングとは違う: 有効なマークアップは星表示の適格性を与えるだけで、ランキング要因ではありません。Bingも同じ語彙を利用しますが、同等の適格性文書はありません。

公式ドキュメント

AggregateRatingに関する一次資料です。

schema.org（語彙）

• AggregateRatingタイプ — 基本となるタイプ定義とプロパティ一覧（itemReviewed、ratingCount、reviewCount、継承されるratingValue／bestRating／worstRating）、数字と小数点の書式に関する注意を確認できます。

Google — 適格性と要件

• レビュー スニペット（Review、AggregateRating）構造化データ — 必須プロパティ、対応ホストタイプ一覧、自己提供レビューの範囲（LocalBusiness／Organization）、他サイトから集約しないルールを示す権威ある仕様です。
• 一般的な構造化データのガイドライン — スパム方針、手動対策の文言、真正な評価の要件です。
• レビュー リッチリザルトをより役立つものにする （2019年9月） — 自己提供レビュー方針の起点で、いつ、なぜ変わったかの背景に使います。
• リッチリザルトテスト — マークアップを検証し、星評価の適格性を確認します。

Bing／Microsoft

• 構造化データでサイトをマークアップする — Bingの一般的な構造化データ対応（schema.org、JSON-LD）を説明します。

出典からの引用

schema.orgとGoogleによる記録された発言です。出典ページに本文が公開されている場合、リンクは引用箇所へ直接移動します。

schema.org — タイプ定義

• “The average rating based on multiple ratings or reviews.” (翻訳)「複数の評価またはレビューに基づく平均評価です。」 引用箇所へ

Googleの文書 — 集計評価のマークアップ

• “Make sure to mark up an aggregate evaluation of an item by many people with schema.org/AggregateRating.” (翻訳)「多くの人による項目の集計評価をschema.org/AggregateRatingでマークアップしてください。」 引用箇所へ

Googleの文書 — LocalBusiness／Organizationに限定された自己提供レビューのルール

• “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” (翻訳)「評価対象のエンティティ自身が自分についての評価を管理している場合、LocalBusinessまたはその他のOrganization構造化データを使うページは星のレビュー機能の対象外です。」 引用箇所へ

Googleの文書 — 他サイトから集約しないルール

• “Don’t aggregate reviews or ratings from other websites.” (翻訳)「他サイトのレビューや評価を集約しないでください。」 引用箇所へ

Google — 構造化データ方針（欺瞞／誤解、手動対策）

• “Don’t use structured data to deceive or mislead users. Don’t impersonate any person or organization.” (翻訳)「構造化データを使ってユーザーを欺いたり誤解させたりしないでください。個人や組織になりすまさないでください。」 引用箇所へ
• 真正な評価について（レシピ固有の例ですが、レビュー方針全体に一般化できます）: “reviews or ratings not by actual users may result in manual action.” (翻訳)「実際のユーザーによるものではないレビューや評価は、手動対策につながる可能性があります。」 構造化データ一般ガイドライン

AggregateRatingとReview — どちらが必要？

質問に順番に答えてください。

1. 一人の意見をマークアップしますか、それとも多数の平均ですか？

• 一人のレビュアーの意見（単一の評価＋レビュー本文）なら、AggregateRatingではなくReviewスキーマを使います。
• 多数の評価の平均ならAggregateRatingです。次へ進みます。
• 全体スコアと個別の意見の両方があるなら、同じ親タイプの内側で両方を使います。aggregateRating一つと、reviewオブジェクトの配列です。

2. ネストしますか、それとも単独で置きますか？

• Product（またはProductGroup）、Recipe、Movie、Book、Course、Event、**SoftwareApplication**の内側にネストする場合 → 対応ホストです。真正な評価なら通常は星の対象になり、親がすでに項目名を示すためitemReviewedは省略できます。次へ進みます。
• LocalBusinessまたはOrganizationが自分自身を評価する場合 → 停止してください。 ここでの自己提供評価は星機能の対象外です。マークアップが検証を通っても星を期待しないでください。
• まったくネストしない場合 → それでも問題ありません。AggregateRatingに、評価対象を直接示すitemReviewedを指定します。
• Googleの対応リストにない別の親タイプの場合 → マークアップは検証を通る可能性がありますが、星は表示されません。未対応ホストだからです。

3. 必須プロパティがありますか？

• ratingValueと、ratingCount／reviewCountの少なくとも一方を確認します。ネストしていない場合はitemReviewedも設定します。どちらの形でも評価対象には名前が必要です。件数の欠落が最大の失敗原因です。
• 1〜5以外の尺度ですか？ bestRating／worstRatingを追加しないと、Googleが尺度を読み違える可能性があります。

4. 評価は真正で、ページ上にありますか？

• 実在のユーザーがこの特定の項目について行った評価で、同じページに表示されている → 良い状態です。
• 他サイトから集約した、捏造した、または報酬で誘導した評価 → 使わないでください。 リッチリザルトが表示されないだけでなく、構造化データの手動対策を招く危険があります。

覚え方： Reviewは一人の意見、AggregateRatingは多数の平均です。商品などの対応タイプは真正な星を表示できますが、事業者が自分自身を評価しても表示できません。

避けるべきAggregateRatingの神話と誤り

神話: 「Organization／LocalBusinessのスキーマにAggregateRatingを追加すれば、商品と同じように星が出る」 いいえ。Googleは、レビュー対象のエンティティ自身がレビューを管理している場合、LocalBusiness／Organizationの自己提供評価を星のレビュー機能から明示的に除外しています。“pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature” (翻訳)「LocalBusinessまたはその他のOrganization構造化データを使うページは星のレビュー機能の対象外です」。この方針は2019年9月から続いています。事業者そのものへの評価に星は付きませんが、店舗が販売する商品への真正な評価には星が表示されることがあります。

神話：「AggregateRatingとReviewは同じものだ」 Reviewは一人のレビュアーの意見をマークアップし、AggregateRatingは多数の平均をマークアップします。タイプも必須プロパティも別です。多くのページは両方をネストして使いますが、互換性があるわけではなく、集計評価を使うからといって個別のReviewオブジェクトを創作する必要もありません。

神話：「必要なのはratingValueだけで、件数は関係ない」 GoogleはratingValueと一緒に、ratingCountまたはreviewCountの少なくとも一方を要求します。サンプル数のない単なる平均は適格ではありません。

神話：「ratingCountとreviewCountは同じ数字だ」 異なります。ratingCountはレビュー本文のない星だけの投稿を含み、reviewCountは評価の有無を問わずレビューを残した人数です。「文章によるレビュー」だけに限られません。ページに1 200件の評価があっても、レビューを残した人は340人だけという場合があります。プラットフォームが実際に追跡している方を提供し、どちらも水増ししないでください。

神話：「自分の事業者ページに第三者レビューウィジェットを置けば、自動的に星の対象になる」 ウィジェットが自社の事業者／組織について表示するレビューなら、第三者プラットフォームから取得したものでも自己提供であり、LocalBusiness／Organizationの星表示の対象外です。

神話：「偽造または誘導した5つ星評価は、スニペットが表示されないだけだ」 Googleは真正な評価だけという要件を実際に適用します。捏造評価は、ページのリッチリザルト適格性を取り消す構造化データの手動対策につながる可能性があります。単にスニペットが抑制されるだけではありません。

神話：「AggregateRatingスキーマはランキングを改善する」 すべてのスキーママークアップと同じく、影響するのはリッチリザルトの適格性であり、ランキングではありません。星評価の適格性は得られても順位は得られません。（Structured Dataハブがこの点を詳しく説明しています。）

誤り: 他サイトの評価を集約する。 Googleの指針は明確です。“Don’t aggregate reviews or ratings from other websites.” (翻訳)「他サイトのレビューや評価を集約しないでください。」自分のページが実際に集めた評価だけを使います。

誤り：不正なratingValue。 実際の数字と小数点を使います（4.6であり、4,6や見た目の似たUnicode記号ではありません）。コンマの小数は、避けられる検証エラーのよくある原因です。

誤り：対応していないホストタイプにaggregateRatingを置く。 itemReviewedを指定してAggregateRatingを単独で置くことも、対応タイプの内側にネストすることも有効です。ただし、いずれの場合も項目タイプはGoogleの対応リストに含まれていなければなりません。未対応タイプに置くと検証は通っても星は表示されません。

正常なAggregateRating JSON-LDと壊れた例

正常な、ネストされた集計評価

AggregateRatingをProductの内側に正しくネストし、有効な平均、件数、尺度を明示し、一般的な実装どおり個別のreviewも一つ添えた例です。

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "image": "https://example.com/img/backpack.jpg",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "1200",
    "reviewCount": "340"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "James Smith" },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "reviewBody": "Comfortable on long days, great ventilation."
    }
  ]
}

ratingCount（評価総数1 200件）とreviewCount（レビューを残した人340人）は異なる数字です。実際にも通常は異なります。

非ネスト形式

ネストが一般的ですが、AggregateRatingをProduct（または他のホスト）の内側に置く必要はありません。評価対象を示すitemReviewedを指定すれば、単独で置けます。これは文書化された有効な形であり、回避策ではありません。

{
  "@context": "https://schema.org/",
  "@type": "AggregateRating",
  "itemReviewed": {
    "@type": "Product",
    "name": "Trailhead 30L Hiking Backpack"
  },
  "ratingValue": "4.6",
  "bestRating": "5",
  "worstRating": "1",
  "ratingCount": "1200",
  "reviewCount": "340"
}

同じプロパティと同じ適格性ルールが適用されます。違いはitemReviewedの置き場所だけです。ネスト形式では親から意味が分かるため通常は省略し、非ネスト形式では明示します。

同じ集計評価が壊れた例

以下で示す各行は、実際によくある検証エラーです。

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4,6"
  }
}

問題点：

• ratingCountまたはreviewCountがない — 典型的な「Either ‘ratingCount’ or ‘reviewCount’ should be specified（ratingCountまたはreviewCountのいずれかを指定してください）」エラーになります。集計にはサンプル数が必要です。
• ratingValue: "4,6" — コンマの小数点です。ピリオドの"4.6"を使います。
• bestRating／worstRatingがない — 1–5の既定尺度なら許容されますが、既定以外の尺度で省略するとGoogleが誤読します。

検証は通るのに星が表示されない誤りもあります。この正確なaggregateRatingを**LocalBusinessまたはOrganizationに置き、事業者が自分自身**を評価する場合です。正常なマークアップでも自己提供であり、星機能の対象外です。

一般的なSearch Console／リッチリザルトテストのエラーと修正

AggregateRatingマークアップを作成・確認するツール

JSON-LDを書いたら、まず私のスキーママークアップバリデーターを使います。ブロック（またはページ全体）を貼り付けると、schema.orgのAggregateRating語彙とGoogleのリッチリザルト要件に対して重大度別に検証します。件数欠落エラー、コンマ小数の誤り、bestRating／worstRatingの尺度問題を見つけ、修正済みでコピー＆ペーストできるJSON-LDブロックを返します。

私のリッチリザルト適格性チェッカーは、別の問いに答えます。「有効なJSON-LDか」ではなく、「この特定のページがGoogleの星のリッチリザルトに適格か」です。JSON-LD、HTMLページ、またはライブURLを渡すと、タイプごとに必須フィールド（itemReviewed、ratingValue、ratingCount／reviewCount）の有無と、デフォルトの尺度から外したときに省略している推奨フィールド（bestRating、worstRating）を示します。

空のページから始めて既存マークアップを直す場合は、私のスキーママークアップジェネレーターが、JSON-LDを手書きせずにProduct（または他の対応ホストタイプ）の内側にaggregateRatingを組み立てるフォームを提供します。入力中に各プロパティがGoogle必須、Google推奨、schema.orgのみのどれかも示します。

二つの確認を通過したら、ページをGoogle自身のリッチリザルトテスト にかけます。Googleが適格性の判断に実際に使うツールなので、公開前の最終確認になります。

AggregateRatingの一般的な問題と修正方法

マークアップは正常に検証されるのに、検索結果に星が表示されない

最も可能性が高い原因は自己提供レビューのルールです。aggregateRatingがLocalBusinessまたはOrganizationの内側にネストされ、事業者が自分自身を評価しています。GoogleはJSON-LDがどれほどきれいでも、この組み合わせを星機能から完全に除外します。まず親タイプを確認し、LocalBusinessまたはOrganizationなら、真正な商品レベルのレビューへ話を移してください。事業者は自分自身を評価して星を得られませんが、店舗は商品を評価できます。次に多い原因は未対応ホストタイプです。Googleの対応リスト（Book、Course、Event、LocalBusiness、Movie、Product、Recipe、SoftwareApplicationと少数の追加タイプ）外のタイプにaggregateRatingをネストすると、検証は通っても星は表示されません。

リッチリザルトテストまたはSearch Consoleが「Either ‘ratingCount’ or ‘reviewCount’ should be specified」と報告する

aggregateRatingオブジェクトにサンプル数のプロパティがありません。ratingValueだけでは不十分です。Googleはそれと一緒にratingCountまたはreviewCountの少なくとも一方を要求します。プラットフォームが実際に追跡している方（星だけの評価を含む総評価数、またはレビューを残した人数）を追加し、再テストしてください。

数字が正しく見えるのにratingValueが検証に失敗する

コンマの小数点（"4,6"を"4.6"の代わりに使う）、見た目の似たUnicode数字、実際の0–9数字ではない文字がないか確認します。小数点にコンマを使う地域でよくある誤りで、バリデーターが指摘するまで見えにくい問題です。

バリデーターエラー：最良評価値は最悪評価値より大きくなければならない

bestRatingとworstRatingの順序が逆か、worstRatingが欠落していてGoogleの1〜5のデフォルトが実際の尺度と合っていません。1〜10や100点満点の評価を注記なしで置くと、1〜5のデフォルトに対して読み違えられます。デフォルト以外の尺度なら、たとえばworstRating: 1、bestRating: 5のように両方を明示してください。

Search Consoleでは有効と表示されるのに、ライブSERPに星が表示されない

検証に通り、Search Consoleが「有効」と報告することは、ページが星のリッチリザルトに適格だという意味にすぎません。Googleが実際に表示する保証ではありません。これは想定された挙動で、追いかけるべきバグではありません。適格性はリッチリザルトの適格性を示すだけで、表示やランキングの約束ではないからです。マークアップが真正に有効で適格なら、マークアップ側でさらに直すことはありません。

以前は表示されていたリッチリザルトが消えた

捏造した評価や他サイトから集約した評価に対する構造化データの手動対策は、ページのリッチリザルト適格性を取り消します。まずSearch Consoleの手動対策レポートを確認してください。手動対策がなければ現在のマークアップを再検証します。テンプレートやCMSの変更で、以前は正しかったプロパティ（件数の欠落、尺度の書き換えなど）が気付かないうちに壊れている可能性があります。

AggregateRatingの変更が機能したことを証明する

テスト1：JSON-LDの構文と必須プロパティの検証

実行するテスト： 更新したJSON-LDを私のスキーママークアップバリデーターに貼り付けるか、ライブページをGoogleのリッチリザルトテスト にかけます。 期待する結果： AggregateRatingブロックにエラーがなく、実際の数字と小数点形式のratingValueがあり、ratingCountまたはreviewCountの少なくとも一方がある。 失敗の解釈： 欠落プロパティが指摘されたなら、公開したマークアップに本当にそのプロパティがないという意味です。キャッシュやレンダリングの問題だと決めつけず、JSON-LDのソースを再確認します。 監視期間： 即時。両方のツールがマークアップを直接読み、クロール待ちがないためです。 ロールバックのきっかけ： 直接修正しても検証に失敗する場合は、テンプレート変更を戻し、最後に正常だったJSON-LDとの差分を再確認します。

テスト2：特定のホストタイプでのリッチリザルト適格性

実行するテスト： ライブURLに対して私のリッチリザルト適格性チェッカーを実行します。 期待する結果： ページの親タイプ（例：Product）がレビュー／星のリッチリザルトに適格と表示され、itemReviewedが正しく解決される。 失敗の解釈： 親タイプがLocalBusinessまたはOrganizationなら、「不適格」は自己提供ルールによる期待された挙動であり、バグではありません。失敗と扱う前にホストタイプを確認します。 監視期間： 即時。 ロールバックのきっかけ： 対応タイプ（Product、Recipeなど）のページで修正後も必須フィールド欠落エラーが出るなら、デプロイがGoogleの見るマークアップを更新していません。キャッシュや変更を上書きするビルド手順を確認します。

テスト3：Search Consoleの拡張レポートに修正が反映される

実行するテスト： Search Console → 該当する拡張レポート（ホストタイプに応じて商品スニペット／Merchant listings）で対象URLを確認します。 期待する結果： ページが「無効」または「不適格」から「有効」バケットへ移り、そのURLのレポート上のエラー件数がゼロになります。 失敗の解釈： Googleの再クロール後も指摘されるなら、修正がライブページに出ていないか、別の必須プロパティも欠けています。ステージングではなくライブURLでテスト1を再実行します。 監視期間： Googleが再クロールしてレポートを更新するまで数日からおよそ1週間です。Search Consoleのデータはライブページより遅れます。 ロールバックのきっかけ： テンプレート展開後に無効項目数が減らず増えるなら、同じテンプレートを使う他ページのマークアップを壊したサインです。展開を一時停止します。

テスト4：ライブSERPに星のスニペットが実際に表示される

実行するテスト： ページが順位を得ているクエリを手動検索し、リストの下に星評価が表示されるか確認します。個人化の偏りを避けるには、プライベート／シークレットウィンドウを使います。 期待する結果： 結果の下に星と評価数が表示されます。 失敗の解釈： Search Consoleが「有効」でも星がない場合、それだけで修正すべき失敗ではありません。表示はGoogleの裁量であり、適格性から保証されるものではありません。「不適格」や手動対策の状態と組み合わさる場合は、テスト1または3に戻ります。 監視期間： Googleは表示までの固定期間を示していません。検証に通った直後を期待せず、数週間にわたり定期的に確認します。 ロールバックのきっかけ： マークアップ側ではありません。Googleが管理する表示判断を戻すものはなく、手動対策がページを指摘した場合だけ戻します。

AggregateRatingマークアップの継続的なKPI

指標：有効項目数（Search Console拡張レポート） 何が分かるか：現在、エラーのないAggregateRatingマークアップを持つ適格ページが何ページあるか。KPIのカバレッジ側です。 取得方法：Search Console → 拡張機能 → サイトに該当するレポート（商品スニペット／Merchant listings）。 ベンチマーク／現実的な範囲：普遍的な目標はありません。マークアップを持つべきページ（適格タイプのページ総数）から自分の基準値を作り、有効項目数がそこへ近づくか追跡します。 頻度：毎月、またはレビューのマークアップに触れるテンプレート／CMS変更の直後。

指標：無効／エラー項目数（同じレポート） 何が分かるか：必須プロパティが壊れたページ数。カバレッジとは別の品質側KPIです。 取得方法：同じ拡張レポートのエラー／無効バケット。 ベンチマーク／現実的な範囲：正直な目標はゼロだけです。ゼロ以外は統計的なノイズではなく、実際に壊れたページです。 頻度：毎月、またマークアップテンプレートに触れるデプロイの後は必ず。

指標：星の適格性を得たページのCTR変化 何が分かるか：星のスニペットが、適格性だけでなく実際にクリック増加へつながったかです。 取得方法：Search Consoleのパフォーマンスレポートで対象ページに絞り、マークアップ公開前後の週のCTRを比較します。Search Consoleは「星のスニペットからのクリックだけ」をきれいに分離できないため、これは正確な帰属ではなく前後比較の代理指標です。 ベンチマーク／現実的な範囲：引用できる固定の上昇率はありません。同じページの公開前CTRを基準にして差分を追跡します。クエリ、順位、競合のリッチリザルトに大きく左右されるためです。 頻度：公開後の最初の四半期は毎月、その後は四半期ごと。

指標：ratingCount／reviewCountの経時的な増加 何が分かるか：平均の裏付けとなるサンプル数が本当に増えているかです。アクティブなレビュー基盤を主張するページで件数が横ばいまたは減少しているなら、マークアップする前に調べる価値があります。 取得方法：自分のレビュープラットフォーム、CMS、データベースなど、マークアップが真実の源として参照するシステムです。 ベンチマーク／現実的な範囲：自分の履歴と比較して実数の増加を追跡します。「ページに何件の評価が必要か」という外部ベンチマークはありません。 頻度：毎月。

AggregateRatingスキーマの理解度を確認する

schema.org／AggregateRating、必須プロパティ、自己提供レビューのルールについての5問です。それぞれ答えを選んでから確認してください。

変更履歴