「レビューの構造化データをサイトに入れれば、検索結果に★が出る」——この理解のまま実装を進めると、多くの小規模事業者は期待した★を見ないまま終わります。理由は単純で、Googleは2019年9月から、自社の評判についての自己申告レビューをリッチリザルトの対象外にしたからです。この記事では、何が出て何が出ないのかを先に整理したうえで、実装の手順・テスト方法・やってはいけないことまでをまとめます。
私は業務効率化に特化したエンジニアとして、お客様の声を管理するサービス「Shinrai」を開発・運営しています。Wall of Love機能やウィジェット埋め込み機能を実装する過程で、Google Search Centralの構造化データガイドラインを一次情報で読み込み、実際にReview・AggregateRatingのJSON-LDを実装してリッチリザルトテストとSearch Consoleで検証してきました。この記事では、その知見をまとめます。
先に結論 — 出るケースと出ないケース
まず表で整理します。同じReview/AggregateRatingという構造化データでも、何を評価しているかによって扱いが分かれるのがポイントです。
| ケース | 星は出るか | 理由 |
|---|---|---|
| 自社サイトに「自社（会社・お店）」への感想をReview/AggregateRatingで実装 | 基本的に出ない | LocalBusiness・Organizationの自己申告レビューは2019年9月以降、対象外 |
| ECサイトで「個別の商品」へのレビューをProduct構造化データで実装 | 出る可能性がある | 商品への評価は自己申告の制限を受けない |
| 第三者の口コミ・比較サイトが、あなたの会社を評価して掲載 | 出る可能性がある | 評価している側と評価されている側が別なので自己申告に当たらない |
| Googleビジネスプロフィールの口コミ・評価 | 検索結果に出る（構造化データ不要） | そもそも構造化データではなく、Google独自の情報として表示される |
つまり、「お客様の声」を自社サイトに集めて紹介したい写真館・サロン・コーチ・士業のような読者が一番欲しい「自社への★」は、構造化データだけでは基本的に実現しません。ここを知らずに実装だけ進めると、正しくマークアップしても★が出ず、「実装が間違っているのでは」と無駄に時間を使うことになります。
なぜ2019年9月から出なくなったのか
背景を押さえておくと、実装判断がぶれなくなります。
2019年9月、Googleは構造化データガイドラインを変更し、LocalBusinessとOrganization、およびそのサブタイプに対する自己申告レビューのリッチリザルトを表示しない方針を明らかにしました。自己申告レビューとは、事業者自身が自社サイト上で、自社について書かれたレビューをReview・AggregateRatingとしてマークアップしているケースを指します。第三者のレビューウィジェットを埋め込んでいる場合も同様に対象外です。
Googleが挙げた理由は、検索結果の信頼性の担保です。自社サイトに自社への高評価だけを並べて構造化データ化すれば、事実上いくらでも星の見せ方を操作できてしまいます。実際、この変更以前は「自社サイトに★5.0の自己評価を並べて検索結果に星を出す」という手法が一部で広まっており、実態と表示が乖離するケースが問題視されていました。
なお、既存の自己申告レビューの構造化データを削除する義務はなく、これによって手動対策（ペナルティ）を受けるわけでもありません。単にリッチリザルトとして表示されなくなるだけです。この「表示されないだけで違反ではない」という線引きは、実装するかどうかの判断で誤解されやすい点なので、覚えておいてください。
一方で、Product（商品）そのものへのレビューは対象外になっていません。Googleが例に挙げているのは「Google自身がGoogle Homeという商品をレビューする」ようなケースで、これは事業者の自己申告には当たらないという整理です。評価の対象が「会社・お店」か「個別の商品」かで扱いが変わる、と覚えておくと判断が早くなります。
それでも検索結果に星を出す3つの現実的な方法
自社への★を構造化データだけで出すのが難しいなら、代わりに何ができるのか。私が実装・調査した範囲では、現実的な選択肢は3つです。
方法1: Googleビジネスプロフィールの評価を育てる
もっとも確実なのはこちらです。Googleビジネスプロフィールの口コミ件数と平均評価は、構造化データを使わずとも検索結果・マップに表示されます。これはGoogle独自の情報として扱われ、自己申告レビューの制限を受けません。Googleの口コミをどう集め、どう自社サイトにも活かすかはGoogle口コミをサイトに載せる方法3選｜手順と注意点【2026年版】で3つの方法を比較して解説しています。
方法2: ECサイトなら商品ページにProduct構造化データを実装する
商品を販売しているなら、個別の商品ページにProduct構造化データとAggregateRatingを実装する方法が残っています。前述の通り、商品へのレビューは自己申告の制限の対象外です。ただしここでも、レビューの中身は自社が集めた実在の声である必要があり、水増しは後述するスパムポリシー違反になります。
方法3: 第三者の口コミ・比較サイトに掲載してもらう
業界特化の口コミサイトや比較サイトに登録し、そちら側で評価を集めてもらう方法です。評価する側とされる側が別主体なので、自己申告に当たりません。ただし掲載先の選定や運用は自社でコントロールしにくく、即効性のある方法ではありません。
3つとも即効性は高くありませんが、共通しているのは「実在する声を、誠実な集め方で積み重ねる」という一点です。私が声の管理機能を設計するときも、構造化データで星を偽装する発想ではなく、実際の声を許諾ごと集めて資産にする方向で作りました。近道に見える実装ほど、後から表示されなくなったり、規約違反として扱われたりするリスクが高いというのが実装者としての実感です。
Review・AggregateRatingの実装方法（JSON-LD）
自己申告の制限を理解したうえで、それでも実装したい場面（商品ページ、第三者サイトからの依頼対応など）のために、書き方を整理します。Googleが推奨する記法はJSON-LDで、<script type="application/ld+json">としてページの<head>または<body>に埋め込みます。
複数のレビューの集計値を出す場合のサンプルです。
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "商品名をここに入れる",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.5",
"bestRating": "5",
"reviewCount": "48"
}
}
必須・推奨プロパティを表にまとめます。
| プロパティ | 必須/推奨 | 内容 |
|---|---|---|
| ratingValue | 必須 | 評価の平均値。ページ上の表示と完全に一致させる |
| reviewCount または ratingCount | 必須 | レビューまたは評価の総件数。実数と一致させる |
| bestRating | 推奨 | 評価の満点（5段階なら5）。省略時は5点満点として扱われる仕様 |
| itemReviewed | 実装によって必須 | 何を評価しているか（商品名・事業者名など） |
| author | 推奨（Review単体の場合） | レビューを書いた人。個人名を出す場合は本人の掲載許諾が前提 |
とくに重要なのがratingValueとreviewCountを、ページ上に実際に表示している数値と完全に一致させることです。構造化データだけに高い数値を書き、ページの表示は別の数値、という実装はガイドライン違反になります。私が実装で必ず確認するのは、この「表示と構造化データの一致」です。ここがずれていると、後述するスパム判定のリスクに直結します。
なお、掲載する感想に投稿者名を出す場合は、構造化データの実装以前に本人の許可が前提です。許諾の取り方と記録の残し方はお客様の声の掲載許諾はどう取る？同意文テンプレート付き完全ガイド【2026年版】にまとめています。
実装後の確認方法 — リッチリザルトテストとSearch Console
実装したら、必ず2つのツールで確認してください。
1つ目はリッチリザルトテストです。 search.google.com/test/rich-resultsでページのURLかコードを入力すると、構造化データが正しく認識されているか、リッチリザルトとして表示される見込みがあるかを確認できます。ログイン不要で、実装直後にすぐ使えるのが利点です。
2つ目はSearch Consoleのリッチリザルトレポートです。 こちらは「理論上どう見えるか」ではなく、Googleが実際にクロールして認識した結果を確認する場所です。エラー・警告が出ている場合は、該当ページのURLと問題点が一覧で表示されます。私の実装経験では、リッチリザルトテストで問題なしと出ても、Search Console側で数日後に警告が出るケースがあり、公開後も定期的に見に行く運用にしています。
両方を使い分ける理由は単純で、リッチリザルトテストは実装のデバッグ、Search Consoleは公開後の実態確認という役割が違うからです。実装して終わりにせず、この2つを1週間おきくらいに確認する習慣をおすすめします。
やってはいけない実装 — スパムポリシーと自作自演レビューのリスク
最後に、避けるべきパターンを整理します。Googleの構造化データガイドラインでは、ページに実際に表示されていない情報を構造化データに書くことをスパムとして扱っています。
| NGパターン | 何が問題か |
|---|---|
| 実在しない・水増しした評価をratingValueに記載 | ガイドライン違反。悪質な場合は手動対策の対象 |
| ページ上の表示より高い数値を構造化データに記載 | 「表示と構造化データの不一致」として違反扱い |
| 自社で作成した感想を第三者のレビューとして記載 | 実態を偽った表示。ステマ規制の観点でも問題になり得る |
| 都合の悪い評価だけを除外して集計 | 母集団の恣意的な操作。優良誤認のリスクにもつながる |
とくに1つ目と3つ目は、手動対策（マニュアルアクション）を受けると、リッチリザルトどころか通常の検索順位そのものに影響が及びます。「レビューが少ないから盛る」ではなく、「レビューが少ないなら、集め方を見直す」が実装者としての結論です。お客様の声の集め方そのものを見直すなら、業種別の依頼文テンプレートをお客様の声の依頼文、どう書く？業種別テンプレート7選【2026年版】にまとめています。また、レビューの見せ方全体がステマ規制の観点でどこまで許容されるかは、ステマ規制で口コミ・お客様の声はどう変わった？チェックリスト付き【2026年版】で整理しています。
よくある質問
Q. 実装して1週間経つのに★が出ません。実装ミスでしょうか？ まず「自社サイトへの自己申告レビュー」に当たっていないかを確認してください。LocalBusiness・Organizationタイプでの自己申告は、実装が完璧でも2019年9月以降のポリシーにより表示対象外です。実装ミスかどうかは、リッチリザルトテストでエラーが出ているかどうかで切り分けられます。エラーがないのに出ない場合は、ポリシー上の対象外である可能性が高いです。
Q. Googleビジネスプロフィールの★とサイトの構造化データの★は別物ですか？ 別物です。Googleビジネスプロフィールの評価は構造化データを使わずGoogle独自の情報として表示され、自己申告の制限を受けません。サイト側のReview/AggregateRatingは、評価対象が「自社」か「個別商品」かでリッチリザルトの可否が変わります。
Q. bestRatingを省略しても大丈夫ですか？ 5段階評価が一般的なため、省略時は5点満点として扱われる仕様になっています。ただし読み手にも実装にも誤解を生みやすいので、私は省略せず明記することをおすすめします。
Q. Reviewを1件だけ構造化データにするのと、AggregateRatingで集計するのはどちらが良いですか？ 件数が少ないうちはReviewを個別に、ある程度件数が集まったらAggregateRatingで集計値を出すのが実務的です。件数が少ない状態でAggregateRatingだけを前面に出すと、実態より多く見せている印象を与えかねません。
まとめ
- 自社（LocalBusiness・Organization）への自己申告レビューは、2019年9月以降リッチリザルトの対象外。実装しても基本的に★は出ない
- 商品ページのProduct構造化データ、Googleビジネスプロフィールの評価、第三者サイトでの掲載は制限を受けない
- それでも実装する場合は、ページ上の表示とratingValue・reviewCountを完全に一致させる
- 実装後はリッチリザルトテストとSearch Consoleの両方で、デバッグと公開後の実態確認を分けて行う
- 水増し・自作自演は手動対策のリスク。星を盛るのではなく、集め方を見直すのが遠回りに見えて一番確実
「★を出す」ための近道を探すより、「出なくても信頼される声を積み重ねる」ほうが、結果的に長く効きます。構造化データはあくまで正確な事実を検索エンジンに伝える手段であって、評価を作り出す手段ではない——ここを押さえておけば、実装の判断で迷うことはなくなります。