お客様の声のページに星を出したくて、Review schemaを書いた。テストツールもエラーなしで通った。それなのに、検索結果には星が出てこない。
そういうところで止まったまま、この記事にたどり着いた方が多いのではないかと思います。この現象の原因は、たいていコードの中にありません。どの型に、誰が書いたレビューを載せているかという、コードの外側にあります。
この記事は、Review schemaをこれから書く方と、書いたのに星が出なくて止まっている方の両方に向けて書きました。必須プロパティとコピペ用のテンプレート、そして出ないときに何から疑うかまで、図解と会話をはさみながら進めます。
こんなふうに調べていませんか
- 「Review schema 実装方法」で検索して、そのままコピペできるテンプレートを探している
- 生成AIに聞いてみたが、ReviewとAggregateRatingの使い分けが分からなかった
- 実装してテストも通ったのに、検索結果に星が出てこない理由が分からない
この記事を読み終えたときに手に入るもの
- ReviewとAggregateRatingの役割の違いを、自分の言葉で説明できるようになります
- 自社の情報に置き換えるだけで試せるJSON-LDが、手元に残ります
- 星が出ないときに何から疑えばいいかが、順番で分かります
結論30秒でわかる、この記事の結論
- Review schemaとは、画面に出ているレビュー本文と評価点を、機械が読める形で書き写す構造化データです。
- 平均点を表すAggregateRatingとは役割が別です。同じページで組み合わせて使われることの多い関係にあります。
- 星が出ないときは、①ページの型 ②レビューの持ち主 ③プロパティの欠けの順に疑うと絞り込めます。
この記事では、ある会社のマーケティング部の2人と、専門家の会話をはさみながら進めます。あなたに近い立場の人の質問から読んでいただいて構いません。
- 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
- 高梨課長（マーケ課長）— 「誰が、どれくらいの手間でやるんですか？」を聞く役
- 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役
01そもそもReview schemaの実装方法は、AI対策として何のためにあるんですか？
若葉さんあの、そもそもなんですが「Review schema」って、何のために書くものなんでしょうか。うちにもお客様の声のページはあるんですけど…。
鈴木さんいい入口ですね。ひとことで言うと、そこに出ている声を、機械が読み違えない形で書き写しておくものなんですよ。新しく評価を作る道具ではありません。
Review型は、schema.orgが定義している語彙のひとつです。Review型そのものが持つプロパティは、itemReviewed（レビューの対象）・reviewRating（評価）・reviewBody（本文）です。author（誰が書いたか）はReview型固有ではなく、上位のCreativeWorkから受け継いでいます。
Google公式は、この構造化データをReview snippetという機能名で扱っています。ページ上のレビューや評価の抜粋を、検索結果に星の形で表示する仕組みです。どのコンテンツ型がこの機能に対応するかは公式ドキュメントに一覧があります。着手する前に、自社ページの型が含まれているかを見ておいてください。
たとえで言うと、Review型は店先に1枚ずつ貼られた口コミカードです。あとで出てくるAggregateRatingは、入口に掲げた平均点の看板にあたります。カードが1枚もないのに看板だけを掲げる、という順序にならないようにしてください。
この章のまとめ
Review型は1件ずつの声、AggregateRatingは全体の平均点。どちらも画面にあるものを写す道具で、新しく作る道具ではありません。
02Review型の必須プロパティは、AI検索対策として何から書けばいいんですか？
Review型でリッチリザルトの対象になるには、次のプロパティが要ります。JSON-LDそのものの書き方に不安がある方は、別記事『JSON-LDの書き方入門｜3つのコピペ例で今日から書ける【図解つき】』を先に読むと迷いません。
| プロパティ | 必須/推奨 | 内容 |
|---|---|---|
| author | 必須 | レビュー作成者（Person または Organization） |
| itemReviewed | 必須 | レビュー対象（ネストされている場合は省略可） |
| itemReviewed.name または親要素のname | 必須 | レビュー対象の名称。ネストして省略する場合も必要 |
| reviewRating | 必須 | 評価を表すRating型 |
| ratingValue | 必須（reviewRating内） | 評価の値。数値・分数・パーセンテージのいずれか |
| datePublished | 推奨 | レビューの公開日（ISO 8601形式） |
| bestRating / worstRating | 推奨 | 評価スケールの上限・下限（既定値は5・1） |
覚え方のこつは、名前を丸暗記しないことです。必須の3つは、レビューについて聞かれる素朴な問いに、ひとつずつ答えています。誰が書いたのか。何についての声なのか。どれくらいの評価なのか。この3つが埋まっていれば、機械の側は困りません。
この章のまとめ
Review型の必須は、author・itemReviewed・reviewRating（中のratingValue含む）。3つの素朴な問いに答えていると考えると、思い出しやすくなります。
03Review schemaの実装方法のテンプレートは、AIOでそのまま貼って大丈夫ですか？
そのまま貼って試せるテンプレートは、次のとおりです。商品名や氏名など、囲みの中の日本語を自社の情報に置き換えれば動きます。
{
"@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等の中に入れて書けば省略できます。ただし省略した場合も、レビュー対象の名前（親要素のname）は要ります。独立したReviewとして書くなら、itemReviewedを自分で書いてください。
親要素にProduct型を使うときの書き方は、別記事『Product schemaの書き方｜価格・在庫がズレる3つの落とし穴【図解つき】』にまとめています。レビュー投稿者を著者として厚く見せたい場合は、別記事『Person schemaとは？コピペで使える実装テンプレ2種と効果の実態』が参考になります。
この章のまとめ
省略できるかどうかは、親要素に何を置いたかで決まります。省いた場合も、対象の名前だけはどこかに残しておいてください。
04AggregateRatingの実装方法は、AI検索最適化でReview型と何が違うんですか？
若葉さんReviewとAggregateRating、名前が似ていて混ざってしまいます。両方書かないといけないものなんでしょうか。
鈴木さん両方が要るとは限りません。声が1件だけならReview型で足ります。まとめて平均を見せたくなった時点で、AggregateRatingの出番になります。
AggregateRatingは、複数の評価をもとにした平均を表す型です。次のプロパティが要ります。
| プロパティ | 必須/推奨 | 内容 |
|---|---|---|
| ratingValue | 必須 | 平均評価の値 |
| ratingCount または reviewCount | 必須（いずれか） | 評価またはレビューの総数 |
| itemReviewed | 必須 | 評価対象（ネストされている場合は省略可） |
| itemReviewed.name または親要素のname | 必須 | 評価対象の名称。ネストして省略する場合も必要 |
| bestRating / worstRating | 推奨 | 評価スケールの上限・下限 |
{
"@context": "https://schema.org",
"@type": "Product",
"name": "商品名をここに入力",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.4",
"ratingCount": "89",
"bestRating": "5",
"worstRating": "1"
}
}Google公式は、個別のレビューをいくつも載せているページでは、AggregateRatingも併記することを推奨しています。看板の平均点は、店先のカードがあってこそ意味を持つ、という関係だと考えると分かりやすいはずです。
この章のまとめ
Review型は1件ずつ、AggregateRatingはその集計。個別を載せているページなら、平均も併記しておくと親切です。
05Review schemaのratingValueの書き方は、AIOでは小数や分数でも大丈夫なんですか？
ratingValueには、数値（4・4.4）、分数（6 / 10）、パーセンテージ（60%）のいずれかを使えます。小数点はドット記号で書き、カンマは使いません。ここは表記の細かい話に見えますが、読み違いが起きると評価点そのものがずれます。
もうひとつ、値とセットで考えたいのがスケールです。bestRating・worstRatingを省略した場合の既定値は、5段階評価を前提に5と1になります。つまり、書かなければ「5段階の評価だ」と読まれます。10段階評価やパーセンテージ評価を使うなら、bestRating・worstRatingを明示しておいてください。
この章のまとめ
値の形は3通りから選べます。ただし5段階以外を使うなら、上限と下限を添えるところまでが1セットです。
06自社サイトに載せたReview schemaの自己申告レビューは、LLMOやAI検索でどう扱われますか？
高梨課長鈴木さん、うちのサイトの「お客様の声」も、この書き方で星が出るようになりますか。実装はできそうなんですが。
鈴木さんそこが、この記事でいちばんお伝えしたいところです。書き方が正しくても、載せている場所と持ち主によっては対象から外れます。
プロパティを正しく書いても星が出ないとき、原因の多くはここにあります。Google公式は、この点をはっきり書いています。対象企業自身がレビューを管理している場合、LocalBusinessやOrganization型のページは星評価機能の対象外になります。企業Aについてのレビューが、企業A自身のサイトに載っているケースが該当します。
大事なのは、この記述がLocalBusinessとOrganization型に向けて書かれているという点です。Product型のレビューについて同じ禁止が書かれているかは、確認できた公式資料の範囲では見当たりませんでした。
ただし、型が違えば何でも書けるという話ではありません。Google公式は、虚偽のレビューや見返り付きのレビューを、一般ガイドライン違反として禁じています。型を問わず、実際にあった声だけを載せる運用が前提になります。
この章のまとめ
明記されているのはLocalBusinessとOrganization型です。とはいえ型を問わず、実在しない声を書かないという前提は変わりません。
07画面表示とschemaの記述は、AI検索最適化でどこまで一致させるんですか？
Google公式の一般ガイドラインは、構造化データ全般に共通する原則を示しています。ページに実際に表示されている情報についてだけ、構造化データを記述すること。この一文が、実装の土台になります。
守るこつは、直す向きを決めておくことです。画面を先に直し、その内容をコードへ写す。この順番にしておくと、画面に無いものがコードにだけ残る状態は起こりません。逆にコードから触り始めると、構文チェックは通るのに中身が食い違う、という気づきにくいずれ方をします。
なお、構造化データの充実度とAI引用率の関係は、研究の間でも結論が割れています。詳しくは別記事『構造化データとAI引用の相関｜論文を読んで分かった3つの事実【図解で解説】』で検証しています。商品ページ側の実務は、別記事にもまとめました。『EC事業者のPerplexity対策｜商品ページが引用される2つの条件【図解つき】』もあわせてご覧ください。
この章のまとめ
画面にあるものだけを書く。直す向きは、画面が先でコードが後です。この順番だけで、食い違いの多くは防げます。
08正しく書いたのにReviewの星が出ないとき、AI検索の何から疑えばいいですか？
高梨課長実装は終わりました。それでも出ない場合、どこから見ればいいでしょうか。若葉さんに任せるにも、手順が決まっていないと動きにくくて。
鈴木さん順番を決めておくと迷いません。コードを疑うのは、実はいちばん最後です。上の2つで外れていることのほうが多いんですよ。
まず、そのページの型がレビュー抜粋の対象に含まれているかを見ます。次に、レビューを自社で管理しているLocalBusiness・Organization型に当てはまっていないかを見ます。この2つが問題なければ、そこで初めてリッチリザルトテストでエラーを探します。
そして、ここまで全部を満たしても、表示そのものは約束されていません。構造化データを実装しても、リッチリザルト表示が保証されるわけではないと、Google公式が述べています。社内で共有するときも、ここまで伝えておくと期待値がずれません。
この章のまとめ
疑う順番は、型・持ち主・プロパティ。コードは最後です。そして全部そろっても、表示自体は約束されていません。
09Review schemaの実装方法を確かめる順番は、AI検索対策でどう決めるんですか？
実装したら、公開の前に手を動かして確かめます。構文が通っていることと、ポリシー上ひっかからないことは別なので、分けて見ていきます。検証ツールの詳しい使い方は、別記事『構造化データのテストツール入門｜今使うべき2つの使い分け方【図解つき】』で解説しています。
- リッチリザルトテストにかける — 公開済みならURLを、未公開ならコードを貼り付けて実行します
- 検出結果に対象の型が出ているか見る — Review・AggregateRatingが現れなければ、親要素とのネスト関係を見直します
- エラーと警告を分けて処理する — エラーは必須プロパティの欠落、警告は推奨プロパティの未設定を指すことが多い区分です
- 画面表示と突き合わせる — 実際のページを開き、評価点・件数・本文がコードの記述と合っているかを目で見ます
大事なのは、この4つを通しても分かるのは「ここまで」だという線引きです。テストが緑になったことを、星が出る約束だと受け取ってしまうと、社内の期待だけが先に進んでしまいます。
この章のまとめ
確かめる順番は、構文が先でポリシーが後ではありません。両方を別々に見て、最後に画面と突き合わせます。
10公開前のReview schema実装チェックリストは、AI検索最適化の運用でどこまで見ておくんですか？
公開直前に見る項目は、次のとおりです。全部を一度に埋めなくても構いません。
- 対象ページのコンテンツ型が、Google公式のレビュー抜粋対象に含まれているか確認している
- Review型に、author・itemReviewed・reviewRating（ratingValue含む）を実装している
- AggregateRatingに、ratingValueとratingCount（またはreviewCount）を実装している
- itemReviewedをネストして省略した場合も、対象の名前（親要素のname）を書いている
- LocalBusiness・Organization型で、自己申告レビューに当てはまっていないか確認している
- 画面に表示されているレビュー内容と、コードの記述内容が一致している
- bestRating・worstRatingを、実際の評価スケールに合わせて明示している（5段階以外の場合）
- リッチリザルトテストで、エラー・警告がないことを確認している
この章のまとめ
チェックは並列ではなく、重みが違います。型と持ち主が先、コードの細部は後で構いません。
11Review schemaを実装すれば、AIOやAI検索で引用されやすくなりますか？
高梨課長ここまでの作業、そこそこの手間になりそうです。やれば、AI検索に引用されやすくなるという理解でいいですか。
鈴木さんそこは正直に言うと、そう言い切れる根拠は手元にありません。構造化データとAI引用の関係は、研究の間でも結論が割れているところです。
Review schemaを実装すれば引用が増える、と断定できる材料は見当たりません。この実装はAI検索最適化（LLMOとも呼ばれます）の文脈で語られることがありますが、確認できた範囲では、効果を約束する根拠ではありません。
一方で、今日確かめられることははっきりしています。画面に出ている評価点と件数が、コードの記述と合っているかどうか。これは証明を待たずに、その場で見に行けます。AI対策として先に手をつけるなら、こちらからです。
この章のまとめ
引用が増えるかどうかの証明は待たなくて構いません。画面とコードが合っているかは、今日その場で確かめられます。
12よくある質問
ReviewとAggregateRatingは、両方とも実装する必要がありますか？
必須ではありません。レビューが1件だけであれば、Review型だけで足ります。複数の評価をまとめて平均として見せたい場合に、AggregateRatingを併用します。個別のレビューを載せているページでは、Google公式が両方の併記を推奨しています。
自分の会社が、自社の商品について書いたレビューは使えますか？
LocalBusinessやOrganization型では、レビュー対象の企業自身が管理するレビューは星評価の対象外です。第三者による実際のレビューを載せることが前提になります。型を問わず、虚偽のレビューや見返り付きのレビューは一般ガイドライン違反にあたります。
ratingValueは整数でないといけませんか？
整数である必要はありません。Google公式は、数値（4.4のような小数を含む）・分数・パーセンテージのいずれの形式も認めています。小数点はドット記号で書き、カンマは使わない点だけ気をつけてください。
実装したのに星評価が表示されません。何を疑えばいいですか？
まず自社ページの型が、レビュー抜粋の対象になっているかを見ます。次に、レビューを自社で管理しているLocalBusiness・Organization型に当てはまっていないかを見ます。この2つが問題なければリッチリザルトテストでエラーを探しますが、構造化データを実装しても表示自体は保証されない点も、前提として押さえてください。
AggregateRatingだけを書いて、個別のレビューは載せなくてもいいですか？
おすすめしません。Google公式の一般ガイドラインは、利用者が実際に読めるレビューや評価であることを前提としています。平均点だけを示して、根拠になる個別の声が画面に無い状態は避けてください。
13まとめ｜今日やる3つのこと
Review schemaは1件ずつのレビュー本文と評価点を、AggregateRatingは複数評価の集計値を、それぞれ機械が読める形で書く構造化データです。テンプレート自体はシンプルですが、実装の成否を分けるのはコードの外側にあります。
自己申告レビューのポリシーが明記されているのは、LocalBusinessとOrganization型です。そしてどの型であっても、画面表示の内容とコードの記述を合わせることが大前提になります。
今日この順でやります
ページの型を確かめる
レビュー抜粋の対象一覧に、自社ページの型が入っているかを見ます
レビューの持ち主を確かめる
自社で管理している声を、LocalBusiness・Organization型に書いていないかを見ます
画面とコードを突き合わせる
評価点・件数・本文が、画面に出ているものと合っているかを目で見ます
AI検索では、こう聞かれています
Review schemaはどう書けばいいですか？必須プロパティは何ですか？
「Review型の必須プロパティは、AI検索対策として何から書けばいいんですか？」の章に、表と覚え方があります
ReviewとAggregateRatingは、両方書く必要がありますか？
「AggregateRatingの実装方法は、AI検索最適化でReview型と何が違うんですか？」の章で、役割の違いを図解で説明しています
実装してテストも通ったのに、星評価が出ません。何を疑えばいいですか？
「正しく書いたのにReviewの星が出ないとき、AI検索の何から疑えばいいですか？」の章に、疑う順番の図解があります
自社サイトに載せた自社へのレビューでも、星評価は出ますか？
「自社サイトに載せたReview schemaの自己申告レビューは、LLMOやAI検索でどう扱われますか？」の章で、対象外になる組み合わせを整理しています
次に読むなら、この記事です
