構造化データ

構造化データとは

構造化データは、ページ内の情報が「何を意味するか」を機械に伝えるための印づけです。人間はページを見れば、ある数字が価格で、ある文字列が著者名で、ある日付が公開日だと文脈から読み取れます。だが機械にとっては、印がなければどれも同じ文字の並びにすぎません。構造化データは、各データに「これは価格（price）」「これは著者（author）」「これは公開日（datePublished）」といった意味のラベルを付け、ページを機械可読（＝プログラムが解釈できる状態）にします。

この「意味のラベル」の共通の決まり（語彙）として、世界的に使われているのが schema.org（後述の別項参照）です。そして、その語彙を実際にページへ埋め込む書き方として現在の主流が JSON-LD（JavaScript Object Notation for Linked Data＝リンクされたデータのためのJSON記法）です。JSON-LDは、ページの見た目を変えずに、HTMLの中に意味情報だけを独立して埋め込めるため、実装と保守がしやすいのが利点です。

構造化データの記法には、JSON-LD のほかに Microdata（マイクロデータ＝HTMLタグの属性に意味を書き込む方式）と RDFa（アールディーエフエー＝同じくHTML属性に埋め込む別方式）があります。かつては Microdata が使われた時期もあったが、これらはHTMLの見た目部分に意味情報を混ぜ込むため、記述が絡まりやすく保守が難しいものでした。JSON-LD はページ本文と完全に分離した独立ブロックとして書けるため、見た目を触らずに意味情報だけを足し引きでき、デザイン変更にも強いです。この扱いやすさから、現在はGoogle も推奨する主流の記法となっています。三方式はどれも schema.org という同じ語彙を使える点は共通で、違いは「どう書くか」だけです。

なぜ重要か（AI検索での位置づけ）

AI検索において構造化データが重要なのは、AIがページの内容を「誤解なく」理解する助けになるからです。生成AIは文章を読み取れますが、どの数字が価格でどの文字列が評価点かを常に正確に判別できるとは限りません。構造化データで意味が明示されていれば、AIは「この商品の価格はこれ、評価はこれ」と確度高く読み取れ、その結果として回答に引用・参照される可能性が高まります。構造化データは、AIに対する「読み間違えないための補助線」の役割を果たします。

加えて、構造化データは従来の検索でも直接の恩恵があります。正しく実装すると、検索結果にリッチリザルト（＝星評価・FAQの折りたたみ・パンくずリストなどを伴う拡張表示）が現れやすくなり、クリック率の向上につながりえます。つまり構造化データは、AI検索での引用可能性と、従来検索での見た目の強化を、同じ一つの実装で両取りできる施策です。

もう一つ、構造化データは「ナレッジグラフ（＝検索エンジンやAIが持つ、事物とその関係を結んだ巨大な知識のネットワーク）」への接続点にもなります。例えば Organization 型で自社の正式名称・ロゴ・公式SNSを明示し、sameAs（＝同一の実体を指す外部URL）で公式Wikipediaや公式SNSと結びつけると、検索エンジンやAIは「このサイトの運営者は、あの組織と同一だ」と正確に紐づけられます。人間には自明な「同じ会社だ」という結びつきを、機械に明示的に教えるわけです。これが積み重なると、AIが自社について語るときの正確さが増し、誤情報のリスクが下がります。構造化データは、単なるページ単位の飾りではなく、Web上の自社の実体をAIに正しく認識させるための地道な情報整備でもあります。

仕組み（構造化データの構成要素）

• 語彙（ボキャブラリー） — どんな意味ラベルが使えるかの共通の決まり。主流は schema.org
• 型（Type） — 対象が何かを表す分類。例: Article（記事）、Product（商品）、FAQPage（よくある質問）
• プロパティ（Property） — 型に属する個々の属性。例: name（名称）、author（著者）、price（価格）
• 記法（シンタックス） — 語彙をページに埋め込む書き方。JSON-LD（主流）／Microdata／RDFa

この四つの関係を一文で言えば、「語彙（schema.org）が定めた型とプロパティを、記法（JSON-LD）でページに書き込む」ということになります。料理に例えれば、schema.org が「食材と調味料の名前の一覧（共通言語）」、型が「作る料理の種類」、プロパティが「各料理に必要な具体的な材料」、記法が「レシピを紙に書き出す書式」にあたります。どれか一つでも欠けると機械可読なデータにはならず、四つが噛み合って初めて検索エンジンやAIが意味を読み取れます。実装ではまず対象に合う型を選び、その型が持つプロパティのうち重要なものを埋め、それをJSON-LDで書き出す、という順序をたどります。

ここで、必須プロパティと推奨プロパティの区別も知っておくとよいでしょう。検索エンジンは型ごとに「これが無いとリッチ表示の対象にならない必須項目」と「あるとより良い推奨項目」を定めていることが多いです。例えば記事なら見出しと画像、公開日などが重視されます。最低限の必須項目だけを埋めるより、推奨項目まで丁寧に埋めたほうが、機械に渡せる情報が増え、理解と表示の精度が上がります。ただし、ページに存在しない情報を埋めるのは禁物で、あくまで本文に実在する情報の範囲で、できるだけ豊かに記述するのが正しい姿勢です。

これらを組み合わせて「このページはArticle型で、著者（author）は◯◯、公開日（datePublished）は◯◯」といった情報を機械可読に記述します。JSON-LD では、この情報をHTMLの本文とは分離した独立したブロックとして埋め込むため、デザインを崩さずに意味情報だけを追加できます。Google をはじめ主要な検索エンジンは、この三者（語彙×型×記法）が正しく揃っているページを機械的に読み取り、リッチリザルトの判定などに用います。

具体例・データ

例えばレシピサイトが Recipe 型の構造化データを付けると、検索結果に調理時間・カロリー・星評価が表示されやすくなります。FAQPage 型を付ければ、質問と回答の対応が機械可読になり、AIが「この質問への答えはこれ」と抜き出しやすくなる——これはAEO（回答エンジン最適化）とも直結します。構造化データは、単なる技術的な飾りではなく、検索・AI双方への情報提供のインフラです。

注意したいのは、リッチリザルトとして表示される型は検索エンジン側が定めており、schema.org に定義があるからといって何でも表示されるわけではない点です。Google の場合、公式ドキュメントで「対応している型」と「各型に必須・推奨のプロパティ」が明記されています。例えば FAQ の表示要件は時期によって変わったこともあり、どの型が今どう表示されるかは公式の一次情報で都度確認するのが正しいです。構造化データの実装は「schema.org で書けること」と「検索エンジンが表示に使うこと」を分けて考える必要があります。

よくある誤解・注意点

構造化データはあくまで「意味を伝える補助線」であり、本文そのものの代わりにはならない点を、まず押さえておきましょう。中身の薄いページに構造化データだけを丁寧に付けても、検索やAIから高く評価されるわけではありません。順序としては、まずユーザーにとって価値ある正確な本文があり、その理解を助けるために構造化データを添える、という関係になります。この前後関係を取り違え、「構造化データさえ付ければよい」と考えると、労力の割に成果が出ません。

実装の現場では、構造化データを手で一つずつ書くのではなく、コンテンツ管理の仕組み（＝ページを生成する土台のシステム）に組み込んで自動生成させるのが定石です。記事の著者・公開日・見出しといった情報は、ページを作る時点でシステムが持っています。その情報から構造化データを機械的に組み立てるようにしておけば、本文と構造化データが食い違うリスクが構造的に減り、更新漏れも起きにくいです。個別ページごとに手作業で貼り付ける運用は、規模が大きくなるほど破綻しやすいです。構造化データは「書く」対象というより「本文と同じ元データから自動で生成させる」対象として設計するのが、保守性の高い実務のかたちです。

実務での扱い方

1. 対象の型を選ぶ — ページの中身に合うschema.orgの型（Article・FAQPage・Productなど）を決めます。
2. JSON-LDで記述する — 主流のJSON-LD形式で、必要なプロパティ（著者・日付・価格など）を埋め込みます。
3. ページ内容と一致させる — 構造化データの記述は、ユーザーに見える内容と必ず揃えます。
4. 検証する — Google の構造化データテストツール等で、記述にエラーがないか確認します。
5. リッチリザルトを監視する — 検索での拡張表示が出ているか、パフォーマンスを追います。
6. AI引用を意識する — FAQ型など、AIが答えを抜き出しやすい型を活用し、引用可能性を高めます。