構造化データとは｜リッチリザルトを出す設定方法【JSON-LD】

「構造化データを入れるとSEOに効くと聞くが、何をどう設定すればいいのか分からない」——そんな悩みは、仕組みと手順を押さえれば必ず解消できます。この記事を読めば、構造化データとは何か・リッチリザルトの出し方・JSON-LDでの書き方までが一気通貫でつかめます。SEO全体の進め方はSEO対策とはもあわせてご覧ください。

構造化データとは｜検索エンジンに「意味」を伝える仕組み

構造化データとは、Webページの情報が「何を指しているのか」を、検索エンジンが理解できる形式で明示的に伝えるためのデータです。人間は「4.5」という数字と星マークが並べば「レビューの評価」だと自然に読み取れますが、検索エンジンのプログラムは、それが評価なのか価格なのか在庫数なのかを見た目だけでは判断できません。そこで「この4.5はレビューの評価点です」というように、情報の意味を機械が読める形で注釈として添えるのが構造化データの役割です。

検索エンジンは言葉の意味を人間のようには理解せず、HTMLを文字列として処理しているにすぎません。放っておくと「この文字の並びが何を意味するのか」を推測に頼ることになります。構造化データは、この推測の余地をなくし、ページの内容を検索エンジンに正確に翻訳して伝える「翻訳シート」のような存在です。会社概要ページなら「これは組織情報で、名前・住所・電話番号はこれ」と一つひとつラベルを貼るイメージです。

この「ラベルを貼る」作業のことを構造化マークアップと呼びます。マークアップとは、HTMLのタグなどを使って文書に意味づけをすること。つまり「構造化データ」はデータそのものを指し、「構造化マークアップ」はそのデータをページに実装する行為を指す、という関係です。実務では両者はほぼ同義で使われることも多いのですが、厳密には「データ（もの）」と「マークアップ（行為）」の違いがあると理解しておくと、他の解説を読むときにも迷いません。

語彙は「schema.org」という共通ルールで決まっている

では、どんなラベルを使えばいいのか。ここで登場するのがschema.org（スキーマ・オルグ）です。schema.orgは、GoogleやMicrosoftなどの主要検索エンジンが共同で策定した、構造化データの「語彙（ボキャブラリー）」の共通規格です。「組織はOrganization」「記事はArticle」「よくある質問はFAQPage」「商品はProduct」というように、あらかじめ何百種類もの型（タイプ）とその中で使えるプロパティ（項目）が定義されています。

この共通のルールがあるおかげで、サイト側は決められた語彙に沿って書くだけでよく、検索エンジン側も統一された形式で情報を受け取れます。いわば、世界中のサイトと検索エンジンが使う共通言語の辞書がschema.orgだと考えるとイメージしやすいでしょう。構造化データを設定するとは、突き詰めれば「schema.orgの辞書に従って、ページの内容に正しくラベルを貼る」ことに他なりません。

リッチリザルトとの関係

構造化データとセットで語られるのがリッチリザルトです。リッチリザルトとは、検索結果の通常の「タイトル＋説明文＋URL」に、追加の視覚的な情報が加わった検索結果を指します。たとえば、商品の価格や星評価、レシピの調理時間や画像、パンくずリストなどです（かつては「よくある質問」の折りたたみ表示も代表例でしたが、現在は表示が縮小しています）。かつては「リッチスニペット」と呼ばれましたが、表現の幅が広がり、現在は「リッチリザルト」という呼称が使われています。

両者の関係はシンプルで、構造化データは「原因」、リッチリザルトは「結果」です。ページに適切な構造化データを設定し、検索エンジンがその内容を認識すると、対応する種類であればリッチリザルトとして表示される可能性が生まれます。逆に言えば、構造化データを設定していなければ、リッチリザルトが表示されることはまずありません。リッチリザルトを出したいなら、その入口として構造化データの実装が必須になる、という関係です。

ただし重要な注意点として、構造化データを設定すれば必ずリッチリザルトが表示されるわけではないという点があります。表示するかどうかの最終判断は検索エンジン側にあり、内容の品質やガイドライン適合、検索クエリとの関連性などを踏まえて決定されます。構造化データは「リッチリザルト表示の必要条件ではあるが、十分条件ではない」と理解しておきましょう。

構造化データのSEOへの影響

もっとも誤解されやすいのが、SEOへの効果です。結論から言うと、構造化データは、それ自体が検索順位を直接引き上げる要因ではありません。検索エンジンも「構造化データを追加しただけで順位が上がるわけではない」という趣旨の見解を明確に示しています。「構造化データを入れれば順位が上がる」という期待は、残念ながら正確ではないのです。

では意味がないのかというと、そんなことはありません。構造化データの効果は、順位そのものではなく「検索結果での視認性」と「クリック率（CTR）」の向上という形で現れます。リッチリザルトで目立てば、同じ順位でもユーザーの目に留まり、クリックされる確率が高まります。ただし、かつて人気だった「よくある質問（FAQ）」のリッチリザルトは、Googleが2023年に表示を政府・医療系など一部の権威あるサイトへ限定したため、現在は一般的な企業サイトではほぼ表示されません。パンくずや商品、レビューなど現在も表示される型であれば、順位は変わらなくても、そこから得られる流入が増えるわけです。

加えて、構造化データは検索エンジンがページ内容を正確に理解する助けになります。ページの内容や構成を機械に明示できるため、間接的にコンテンツの評価やインデックスの精度に寄与すると考えられています。近年はAIによる検索結果の生成でも、意味が整理された構造化データが参照されやすく、重要性はむしろ高まっています。「順位を直接上げる魔法」ではなく「正しく伝わり、選ばれやすくする土台」と捉えるのが正解です。内部対策での位置づけは内部SEO対策で整理しています。

代表的な構造化データの種類と効果

schema.orgには膨大な数の型がありますが、Webサイトのリッチリザルトに関わる代表的なものは限られています。ここでは、多くのサイトで実装される主要な種類と、それぞれがどんな効果をもたらすかを整理します。自社のページにどの型が当てはまるかを考えながら読んでみてください。

種類（schema.orgの型）	対象となるコンテンツ	検索結果での効果
よくある質問（FAQPage）	1ページ内のQ&A形式のコンテンツ	以前は質問と回答が折りたたみ表示され占有面積が広がったが、Googleが2023年に表示を一部の権威あるサイトへ限定したため、現在は一般的なサイトではほぼ表示されない
パンくずリスト（BreadcrumbList）	サイト内での階層・現在地	URLの代わりにサイト構造が表示され、ページの位置づけが分かりやすくなる。ほぼ全ページで実装可能
記事（Article）	ニュース・ブログなどの記事	見出し・著者・公開日・画像などが検索エンジンに正確に伝わり、記事系リッチリザルトの土台になる
商品（Product）	ECサイトなどの商品ページ	価格・在庫・評価が検索結果に表示され、購買意欲を喚起。比較検討段階のクリックを取りやすい
レビュー・評価（Review／AggregateRating）	商品やサービスの評価情報	星評価や点数が表示され、信頼性の訴求に直結。クリック率の押し上げ効果が大きい
組織（Organization）	会社概要・運営者情報	会社名・ロゴ・所在地などが正確に伝わり、ブランド情報の表示やナレッジパネルの土台になる

実装の優先順位に迷ったら、まずはほぼすべてのサイトで無理なく入れられる「パンくずリスト」と「組織」から着手するのがおすすめです。この2つは種類を問わず実装でき、サイト全体の構造と運営者情報を正確に伝えられます。そのうえで、記事メディアなら「記事」と「よくある質問」、ECサイトなら「商品」と「レビュー」と、主力コンテンツに合った型を足すと無駄がありません。強調スニペットとの相性は強調スニペットとはも参考にしてください。

構造化データの記述方式｜JSON-LDが推奨される理由

構造化データの記述方式には、実は複数の形式があります。代表的なのがJSON-LD・Microdata・RDFaの3つです。このうち、現在の実装ではJSON-LD（ジェイソン・エルディー）が事実上の標準であり、検索エンジンも公式に推奨しています。実際の利用状況を見ても、構造化データを実装しているサイトのうち約7割がJSON-LDを採用しているという調査もあり、迷ったらJSON-LD一択で問題ありません。

JSON-LDは「JSON for Linked Data」の略で、2014年にW3Cによって標準仕様として勧告された形式です。最大の特長は、HTMLの本文とは分離して記述できる点にあります。MicrodataやRDFaが本文のHTMLタグに直接属性を書き込んでいくのに対し、JSON-LDは本文とは独立したひとかたまりのコードとして書けます。これにより、次のようなメリットが生まれます。

比較項目	JSON-LD（推奨）	Microdata／RDFa
記述場所	本文と分離して1か所にまとめて書ける	本文のHTMLタグ内に属性を埋め込む
可読性・管理のしやすさ	コードが独立し、追加・修正・削除が容易	本文と混ざり、修正時にレイアウトを崩すリスク
実装のしやすさ	テンプレートやプラグインで一括生成しやすい	要素ごとに手作業で属性を付与する必要がある
検索エンジンの推奨度	公式に推奨。採用率も最多	対応はされるが積極推奨ではない

本文と分離できるということは、デザインやレイアウトに一切影響を与えずに構造化データだけを増やしたり直したりできるということです。運用の負担を考えても、JSON-LDを選ばない理由はほとんどありません。以降の解説も、すべてJSON-LDを前提に進めます。

JSON-LDの基本の書き方

JSON-LDは、<script type="application/ld+json"> というタグの中に、決められた形式で情報を書いていきます。難しそうに見えますが、基本の骨格はいつも同じです。まず必ず書くのが、@context（どの語彙を使うかの宣言）と@type（何の型かの指定）の2つ。@contextには常に schema.org を指定し、@typeにOrganizationやFAQPageといった型名を入れます。あとは、その型で決められたプロパティ（項目）を埋めていくだけです。

もっとも基本的な例として、会社情報（組織）をマークアップする場合は、次のようになります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "サンプル株式会社",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "address": {
    "@type": "PostalAddress",
    "addressCountry": "JP",
    "addressRegion": "東京都",
    "postalCode": "100-0001"
  },
  "telephone": "+81-3-0000-0000"
}
</script>

読み解いてみましょう。@contextで「schema.orgの語彙を使います」と宣言し、@typeで「これは組織情報です」と指定しています。あとは name（会社名）、url（URL）、logo（ロゴ画像）、address（住所）という項目に値を入れているだけです。addressのように入れ子（ネスト）になっている部分は、その中でさらに @type を指定して詳細を記述します。中括弧 {} で情報のまとまりを、角括弧 [] で複数の要素の並びを表す——このルールさえ押さえれば、他の型も同じ要領で書けます。

次に、schema.orgの型としてよく知られるよくある質問（FAQPage）の例を見てみましょう（かつてはリッチリザルトで人気の型でしたが、現在は表示が縮小しています）。質問と回答のペアを、mainEntityという項目の中に配列として並べる形になります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化データとは何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "ページの情報が何を指すかを検索エンジンが理解できる形式で伝えるデータです。"
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LDとは何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "構造化データの記述方式の一つで、本文と分離して書けるため検索エンジンに推奨されています。"
      }
    }
  ]
}
</script>

Question（質問）とacceptedAnswer（回答）が1セットになり、それが mainEntity の配列に並んでいるのが分かります。質問を増やしたいときは、この {} のセットをカンマで区切って追加していくだけです。ここで絶対に守るべきなのは、構造化データに書く質問と回答が、ページ本文に実際に表示されている内容と一致していること。この原則は後述の「よくある失敗」でも改めて触れますが、非常に重要なので頭に入れておいてください。

WordPressでの構造化データの設定方法

ここまでで書き方の基本は分かりましたが、「すべてのページに手でコードを書くのは大変そう」と感じた方も多いはずです。WordPressで運用しているサイトなら、プラグイン・テーマ・手動の3つの方法があり、多くの場合は手書きせずに実装できます。それぞれの特徴を整理します。

方法	向いているケース	メリット／注意点
①プラグインで自動出力	手軽に、広い範囲を一括で対応したい	設定するだけでパンくず・記事・組織などを自動生成。専門知識が不要。反面、細かなカスタマイズには限界がある場合も
②テーマに組み込む	デザインと一体で最適化したい	テーマのテンプレートに直接記述。サイト構造に合った出力が可能。テーマ更新時に上書きされない工夫が必要
③手動で個別に記述	特定ページだけ細かく制御したい	最も自由度が高く正確。ただし各ページで管理が必要で、規模が大きいと運用負荷が上がる

もっとも現実的なのは、①プラグインで土台を自動化しつつ、細かく制御したいページだけ③手動で補うという組み合わせです。SEO系のプラグインの多くは、パンくずリストや記事、組織といった基本的な構造化データを自動で出力する機能を備えています。まずはプラグインで全体をカバーし、キャンペーンページやFAQページなど特別な対応が必要な箇所だけ手動で追加する。この役割分担が、手間と精度のバランスが取れた進め方です。

注意したいのは、プラグインとテーマの両方が同じ構造化データを出力し、二重になってしまうケースです。同じ型の構造化データが1ページに複数存在すると、検索エンジンが混乱したり警告が出たりする原因になります。プラグインを導入する際は、テーマ側ですでに同種の出力がないかを確認し、重複を避けるようにしましょう。WordPress特有のSEO実装全般はWordPressのSEO対策で詳しく解説しています。

構造化データ設定後の確認方法

構造化データは「設定して終わり」ではありません。正しく記述できているか、エラーがないかを必ず検証する工程が欠かせません。書式が少しでも間違っていると、検索エンジンに認識されず、リッチリザルトも表示されないからです。確認には、主に次の3つのツールを使います。

確認ツール	できること	使いどころ
リッチリザルトテスト	URLまたはコードを入力し、リッチリザルトの対象になるか・エラーや警告がないかを判定	実装直後の検証。リッチリザルトを狙う際の必須チェック
スキーマ検証ツール（Schema Markup Validator）	schema.orgの文法に沿って構造化データ全般を検証	リッチリザルト対象外の型も含め、記述の正しさを広く確認したいとき
サーチコンソールの拡張レポート	サイト全体で認識された構造化データの状態・エラー件数を継続監視	公開後の運用フェーズ。エラーの発生や増加を定点で監視する

おすすめの使い分けは、実装直後は「リッチリザルトテスト」で個別ページを検証し、公開後は「サーチコンソール」で全体を継続監視する流れです。まずリッチリザルトテストにURLを入力し、「リッチリザルトが検出されました」と表示され、エラーがゼロであることを確認します。警告（推奨項目の未入力など）は必須ではありませんが、対応できるものは埋めるとより充実した表示につながります。公開後はサーチコンソールの拡張レポートを定期的にチェックし、エラー発生を見張ります。テンプレート変更などで突然エラーが増えることもあるため、この定点監視が地味に効きます。

構造化データでやりがちな失敗

構造化データは仕組みがシンプルなだけに、いくつかの「やりがちな失敗」がほぼ決まっています。先回りして知っておけば、無駄なやり直しを避けられます。特に多い失敗を整理しました。

よくある失敗	何が起きるか	対策
本文と内容が一致しない	ページに表示されていない情報を構造化データに書く。ガイドライン違反となり、表示されないどころか手動対策の対象になる恐れ	構造化データの内容は、必ずページ本文に実際に表示されている情報だけにする
未対応・非推奨のタイプを狙う	すでにリッチリザルト対象外になった型に工数をかけ、いくら実装しても表示されない	実装前に、狙う型が現在もリッチリザルトの対象かを公式情報で確認する
必須プロパティの記述漏れ	型ごとに定められた必須項目が欠け、エラーで認識されない	リッチリザルトテストでエラーがゼロになるまで、必須項目を埋める
構造化データの重複	プラグインとテーマが同じ型を二重出力し、検索エンジンが混乱・警告が出る	出力元を一本化し、同じ型が複数存在しないようにする
設定して放置する	テンプレート変更などでエラーが発生しても気づかず、リッチリザルトが消える	サーチコンソールでエラーを継続監視し、変更時は再検証する

これらを一言でまとめると、「本文にない情報を書かない」「対応する型を、必須項目を満たし、重複なく実装し、継続監視する」という当たり前を守ることに尽きます。最重要は「本文との一致」です。実際には載っていない評価や質問を構造化データにだけ書くのは、もっとも避けるべき行為。短期的に表示されても、ガイドライン違反として評価を落とすリスクが高く割に合いません。構造化データは「ページの正直な要約」であるべきと覚えておいてください。

【ワークスルー】構造化データを実装し検証するまで

ここまでの流れを、1本のワークスルーで実演します。すでに公開済みのある解説記事に、よくある質問（FAQ）の構造化データを追加し、リッチリザルトテストで検証するまでを追ってみましょう。手順を追体験することで、全体像がぐっと具体的になります。なお、FAQのリッチリザルト自体は2023年以降ほぼ表示されなくなったため、ここで身につくのは「本文に実在させる→正確に構造化する→検証する」という、どの型にも共通する実装プロセスです。

ステップ	やること	ポイント
①本文にQ&Aを用意	記事内に「よくある質問」の見出しを作り、5問前後の質問と回答を本文として掲載する	まず本文に実在させることが大前提。構造化はその後の「注釈」にすぎない
②FAQPageのJSON-LDを作成	本文の質問・回答をそのまま転記し、FAQPage型のコードを組み立てる	本文と一字一句ずれないよう、内容を完全に一致させる
③ページに設置	プラグインのFAQ機能、または手動でページの<head>や本文末に設置する	既存の構造化データと型が重複しないか確認する
④リッチリザルトテストで検証	ページURLを入力し、FAQが検出されエラーがゼロであることを確認	警告があれば内容を見直し、必須項目の漏れをつぶす
⑤インデックスと表示を待つ	再クロールを待ち、サーチコンソールで認識状況と表示を確認する	表示は検索エンジンの判断。すぐ出なくても品質を保って待つ

この流れで効いているのは、「本文にQ&Aを実在させる→正確に構造化する→検証する」という順番を絶対に崩さないことです。逆に、本文にない質問を構造化データにだけ書く、検証せず公開するといったショートカットは、いずれも先の「やりがちな失敗」に直結します。地味ですが、この順番どおりに一つずつ潰すのが、正しく認識される構造化データの実装法です。パンくずや記事など表示対象の型では、再クロールの時間がかかるためすぐ出なくても慌てず、エラーゼロを保って待つのがコツです。

AI×人で構造化データを「正確に」実装する

ここまで読んで、「仕組みは分かったが、全ページ・全種類を正確に実装し、継続的に監視するのは骨が折れそうだ」と感じた方も多いのではないでしょうか。実際、構造化データは「型ごとのルールが細かい」「本文との一致を常に保つ必要がある」「公開後もエラー監視が続く」という、手順は決まっているが手数が多い作業の典型です。ここで力を発揮するのが、AIと人の役割分担です。

当社は、自社で運営するメディア事業において、構造化データの実装にもAI活用を組み込んできました。具体的には、JSON-LDコードの生成、本文とデータの突き合わせチェック、複数ページの型の棚卸しといった「量が多く手順が決まった工程」をAIが下処理し、どのページにどの型を当てるかの設計判断、本文との整合性の最終確認、ガイドラインに沿った品質担保といった「判断が問われる工程を人が担う——この分担を業務フローとして設計しています。その結果、自社メディア運営全体で月686時間分の業務削減を実現しました。

重要なのは、構造化データこそAIに丸投げしてはいけない領域だという点です。AIはコードの生成や整形を高速にこなしますが、「本文に実在しない情報を、それらしく生成してしまう」リスクがあります。前述のとおり、本文と一致しない構造化データはガイドライン違反となり、評価を落とす原因になります。だからこそ、コード生成はAIで効率化しつつ、本文との一致確認と実装方針は人が握るという設計が欠かせません。当社では、この自社で磨いた「AIで効率化しつつ、正確さと戦略は人が担保する」ノウハウを、そのままクライアントのサイト改善・内部SEO対策支援に応用しています。「構造化データを正しく入れてリッチリザルトを狙いたいが、実装や監視に手が回らない」という方は、お気軽にご相談ください。

まとめ

構造化データとは、ページの情報が何を意味するかをschema.orgの語彙に沿って検索エンジンに正確に伝える仕組みで、リッチリザルト表示の入口になります。順位を直接上げるものではありませんが、検索結果での視認性とクリック率を高め、内容の理解を助ける確かな土台です。記述はJSON-LDで本文と一致させ、確認と継続監視まで丁寧に回すことが成果への近道になります。当社は自社メディアで月686時間の削減を実現したAI×人の設計で、構造化データの実装からリッチリザルト獲得まで正確に伴走します。実装や監視に手が回らない方は、お気軽にご相談ください。