Google検索の結果にFAQが折りたたまれて展開表示されているのを見たことはありませんか。 あのアコーディオン表示や、記事の下に星評価が出るレビュースニペット—— それらはHTML自体の見た目だけで実現しているのではなく、 ページに埋め込まれた構造化データ（JSON-LD）をGoogleが読み取って表示しています。 この記事では、JSON-LDの基本的な仕組みからSchema.orgの語彙・主要スキーマ5種の役割まで、 Webサイトのリッチリザルト獲得に必要な知識を解説します。
JSON-LDとは何か
JSON-LD（JavaScript Object Notation for Linked Data）は、Webページの意味情報を機械が読み取れる形式で記述するW3C標準の仕様です。 HTMLのマークアップはあくまで見た目の構造を表すものですが、 それだけでは「このページにFAQが書かれているのか」「これが商品レビューなのか」 といった意味をGoogleのクローラーが正確に把握することは困難です。
JSON-LDは次のように `<script>` タグの中にJSON形式で書きます。
// FAQPageスキーマの例
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "JSON-LDとは何ですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "JSON-LDとはWebページに..."
}
}
]
}
</script>
HTMLの見た目には何も影響しません。 Googleのクローラーがこのブロックを解析して「このページにはFAQがある」と認識し、 検索結果でFAQを展開表示するリッチリザルトの候補になります。
Schema.orgとは
JSON-LDに書く語彙（`"@type": "FAQPage"` の `FAQPage` などの用語）は、Schema.orgという標準化団体が定めています。 Schema.orgはGoogle・Microsoft・Yahoo!・Yandexが共同で2011年に設立した組織で、 Webの意味情報を記述するための共通語彙（スキーマ）を管理しています。
Schema.orgの語彙は `https://schema.org/` というURLで名前空間が管理されており、 JSON-LDの `"@context": "https://schema.org"` という記述がこの語彙を使うことを宣言しています。 現在800種類以上の `@type` が定義されており、Article・Product・Event・Recipeなど あらゆるコンテンツの種類をカバーしています。
なぜJSON-LDが推奨されるのか
構造化データの記述方法はMicrodata・RDFa・JSON-LDの3種類がありますが、 Googleは公式にJSON-LDを推奨しています。その理由は大きく3点です。
| フォーマット | 記述方法 | HTMLとの分離 | 保守性 | Googleの推奨 |
|---|---|---|---|---|
| JSON-LD | 独立した `<script>` ブロック | ◎ 完全分離 | ◎ 変更しやすい | ◎ 推奨 |
| Microdata | HTMLタグに属性を追記 | × 混在 | △ HTML変更と連動 | △ 対応 |
| RDFa | HTMLタグに属性を追記 | × 混在 | △ HTML変更と連動 | △ 対応 |
JSON-LDはコンテンツのHTMLに手を加えなくても構造化データを追加・変更できるため、 デザイン改修やCMSリプレースの際にも影響が少なく、テストも容易です。 Next.jsなどのモダンフレームワークとも相性がよく、 サーバーサイドでJSONを動的生成してページに埋め込むことも容易です。
主要スキーマ5種の役割
Googleのリッチリザルトに直結する代表的なスキーマを5種類まとめます。 各スキーマには必須プロパティと推奨プロパティがあり、 必須プロパティが欠けているとリッチリザルトの対象外になります。
| スキーマ | 用途 | リッチリザルトの見た目 | 主な必須プロパティ |
|---|---|---|---|
| FAQPage | FAQセクションのあるページ | 質問が折りたたみ展開で表示 | mainEntity[].name, acceptedAnswer.text |
| Article | ニュース・ブログ・ハウツー記事 | 著者名・更新日・サムネイルが表示 | headline, author, datePublished |
| BreadcrumbList | パンくずリストのあるページ | URLの代わりにパンくずが表示 | itemListElement[].name, item |
| LocalBusiness | 店舗・事業者の情報ページ | 住所・営業時間・地図が表示 | name, address |
| SoftwareApplication | Webアプリ・ソフトウェアのページ | 評価・動作OS・カテゴリが表示 | name, operatingSystem, applicationCategory |
これらのコードを手書きするのは煩雑ですが、JSON-LD構造化データ生成ツールを使えばフォームに入力するだけで正確なコードを生成できます。 5種類のスキーマすべてに対応しており、出力されたコードをそのままHTMLに貼り付けるだけです。
Googleリッチリザルトが表示される条件
JSON-LDを設置したからといって必ずリッチリザルトが表示されるわけではありません。 Googleが定める3つの条件をすべて満たす必要があります。
- 必須プロパティが揃っている——スキーマごとに必須のプロパティが決まっており、1つでも欠けると対象外になります。 FAQPageであれば `mainEntity` の各要素に `name`（質問文）と `acceptedAnswer.text`（回答文）が必要です。
- ページコンテンツとの一致——JSON-LDに書いた内容がページ本文にも存在していることが必要です。 JSON-LDにだけ情報を書いてHTMLには存在しない場合、スパムとみなされることがあります。
- Googleによる評価——技術的に正しくても、サイト全体の品質が低いと判断された場合は表示されないことがあります。 E-E-A-T（経験・専門性・権威性・信頼性）を高めることが長期的に有効です。
また、設置後にGoogleがクロール・インデックスするまで1〜4週間かかることがあります。 設置直後に表示されなくても、まずSearch ConsoleやリッチリザルトテストでJSON-LDに エラーがないことを確認することが先決です。
リッチリザルトテストツールの使い方
JSON-LDを設置したらデプロイ前に必ず検証しましょう。 主なツールは2つです。
1. Googleリッチリザルトテスト
`https://search.google.com/test/rich-results` にアクセスし、 URLまたはHTMLコードを貼り付けます。 Googleが実際に認識したスキーマとエラー・警告の一覧が表示されます。 警告は無視できますが、エラーは必須プロパティの欠落を示すため修正が必要です。 デプロイ済みのURLを直接テストすることも、 ローカルのHTMLコードを貼り付けてデプロイ前に確認することもどちらも可能です。
2. Schema Markup Validator
`https://validator.schema.org/` はSchema.org公式の検証ツールです。 Google固有のルールではなくSchema.orgの語彙に対する構文チェックができるため、 Google以外の検索エンジン（BingやYandex）への対応も確認できます。 JSON-LDの書き方に迷ったときや、複数スキーマを組み合わせたときのチェックに役立ちます。
まとめ
- JSON-LDは `<script type="application/ld+json">` タグにJSON形式で書くW3C標準の構造化データ形式で、Googleが推奨している
- Schema.orgがFAQPage・Article・BreadcrumbListなど800種類以上の語彙を管理している
- MicrodataやRDFaと異なりHTMLから完全分離できるため保守性が高く、フレームワークとの相性もよい
- 主要スキーマ5種（FAQPage・Article・BreadcrumbList・LocalBusiness・SoftwareApplication）はそれぞれ異なるリッチリザルトに対応する
- リッチリザルト表示には「必須プロパティが揃っている」「ページ本文との一致」「Googleによる評価」の3条件が必要
- 設置後はリッチリザルトテストで必ず検証し、エラーがないことを確認してからデプロイする
- JSON-LD構造化データ生成ツールを使えばフォーム入力だけでコードを生成でき、手書きミスを防げる