1．そもそも「構造化データ」「スキーママークアップ」とは？
一言でいうと
人間向けの本文とは別に、「機械が読みやすい自己紹介シート」をページに付けること
● 通常のHTML：
人間が読むための文章や見出し、画像、ボタン
● 構造化データ：
「このページは記事です」「著者は○○です」「これは商品で、価格は△△円です」といった情報を、
検索エンジンやAIが理解しやすい形式で書いたデータ
この「自己紹介シート」の“語彙（ボキャブラリ）”を提供しているのが schema.org。
現在、schema.orgには800種類以上のタイプ（Article, Product, LocalBusiness など）と1500以上のプロパティが定義されています。schema.org
→ これが「深化／多様化」の大きな背景です。
代表的なフォーマット
Googleなどがサポートしている構造化データの書き方（フォーマット）は3つ
- JSON-LD（推奨）
- Microdata
- RDFa
現在は JSON-LD が事実上の標準 です。
理由：
- HTML本体と分離できる（
<script type="application/ld+json">内に書くだけ） - テーマやデザインを崩さない
- 後からの追加・修正・自動生成がしやすい
Googleも「可能ならJSON-LDを使って」と明記しています。
2．構造化データが“今”重要になっている理由
(1) 検索結果の「リッチ化」を支えているから
Googleは、構造化データを使ってページの内容を理解し、
リッチリザルト（リッチスニペット） と呼ばれる、視覚的にリッチな検索結果を表示します。
例：
- レビューの★評価つき結果
- レシピカード（調理時間・カロリーなど）
- FAQが折りたたみで表示
- HowToのステップが表示
- 商品の価格・在庫状況付きスニペット
- イベントの開催日時・会場 など
「構造化データ → リッチリザルトの候補になる」
という関係です（保証ではない点は後述）。
(2) AI検索（AI Overviews）との相性が良いから
2024〜2025年にかけて、Googleの AI Overviews / AI検索 が世界的に拡大しました。
Googleは「AI検索でも、これまでの構造化データのベストプラクティスは有効」と明言しています。
Google 検索の Google AI エクスペリエンスでコンテンツのパフォーマンスを高めるための主な方法
また、実務レベルでも構造化データをしっかり実装したページがAI Overviews に採用されやすい という検証記事も出ています。
AIは“曖昧さ”が苦手なので、
「これは誰(どの組織)が作った、どんな種類のコンテンツで、どんな属性があるのか」
をはっきり書いておく構造化データは、“AIに好かれるデータ” になりつつあります。
(3) schema.org 自体が巨大な「エンティティ辞書」になっている
schema.orgは
「ウェブ上のあらゆる“モノ”や“コト”を、型（Type）と属性（Property）で表現する共通語彙」
です。
- Person / Organization / LocalBusiness / Product / Event / Course などの“実体 (Entity)”
- name / description / url / image / sameAs / identifier …といった“属性”
このエンティティベースの理解は、検索エンジンのナレッジグラフやAIの世界モデルとも相性が良く、
「ページ単位」→「エンティティ単位」 の理解へとシフトしている流れを支えています。
3．代表的なスキーマタイプと“深化／多様化”の例
3-1. まず押さえるべき基本タイプ
WebSite / Organization / Person
サイト全体＆運営者を説明するための“土台”となるスキーマです。
- WebSite
- そのドメイン全体を表す
- 検索ボックス（サイト内検索）の拡張などに利用
- Organization / LocalBusiness
- 企業や店舗の正式名称・住所・電話・ロゴ・SNSなど
- Person
- 著者や代表者など、人物情報
→ E-E-A-T（経験・専門性・権威性・信頼性）を示すうえでも重要。
Article / BlogPosting / NewsArticle
ブログやコラム、ニュース記事を表現するためのスキーマ。
主なプロパティ：
- headline（タイトル）
- description（要約）
- author（著者）
- datePublished / dateModified（公開日・更新日）
- image（代表画像）
- mainEntityOfPage（この記事がページの主役であること）
→ 「誰が・いつ・何を書いたか」をAIや検索エンジンに伝える根幹 になります。
Product / Offer
ECや商品ページなら必須レベル。
- Product
- name, description, image, brand, sku, gtin など
- Offer
- price, priceCurrency, availability（在庫状況） など
Google Merchant Center のフィードとしても構造化データを利用可能で、ECの広告・ショッピングタブ・AI検索の土台 になります。
FAQPage / HowTo
- FAQPage：Q&A形式のページ
- HowTo：手順を説明するページ（DIY、設定方法など）
AI要約やリッチリザルトに採用されやすく、
「質問→答え」「手順→ステップ」の構造が明快なため、AIとの相性が非常に良い タイプです。
3-2. 多様化している分野別スキーマの例
schema.orgは、さまざまな業界に特化したタイプも拡充してきました。
● LocalBusiness / Restaurant / MedicalClinic / AutoRepair などローカルビジネス系
→ ローカルSEO、Googleマップ表示に強く関係
● Event / MusicEvent / SportsEvent
→ 開催日時、場所、チケット情報など
● Course / JobPosting / Recipe / Review / AggregateRating
→ 教育、求人、レシピ、レビュー評価などの分野
これらを 組み合わせてネスト できるのが“深化”のポイントです。
例：
- LocalBusiness の中に
- AggregateRating（総合評価）
- OpeningHoursSpecification（営業時間）
- Service系のサブエンティティ
- Product の中に
- Offer（価格・在庫）
- AggregateRating（レビュー）
- Brand（ブランド情報）
→ 1ページ内で複数のエンティティを「グラフ」として表現する 方向に進化しています。
4．実装フロー：構造化データをどう設計・導入するか
ステップ1：ページの「役割」と「主役エンティティ」を決める
- これは何のページか？
- 会社紹介？ → Organization / LocalBusiness
- ブログ記事？ → Article / BlogPosting
- 商品？ → Product
- 店舗案内？ → LocalBusiness + WebPage
- Q&A集？ → FAQPage
「何のページかわからない＝AIにもわからない」 ので、まず人間の言葉で定義してからスキーマを選びます。
ステップ2：schema.org でタイプと必須プロパティを確認
- schema.org で該当タイプを検索（HowTo, Product など）
- required / recommended プロパティ を中心に埋める
GoogleのサポートページやSearch Galleryにも要件一覧があります。
ステップ3：JSON-LDでマークアップを書く
<script type="application/ld+json"> 内に
ページの内容を反映したJSONを書くイメージです。
ポイント：
@contextはほぼ"https://schema.org"@typeにタイプ名（Article, Product など）name, description, url, imageなど基本的なプロパティから埋める
ステップ4：「見えている内容と合っているか」 を必ず確認
Googleの公式ガイドラインで非常に強調されているのが：
構造化データに書いた内容は、ページ上にも実際に表示されていること
- ページに書いてない★5レビューを構造化データにだけ書く
- 実際は在庫切れなのに
InStockとマークする - 実際より高い評価・誇張した情報を書く
→ スパム判定・手動対応のリスク があり、長期的なSEOに悪影響です。
ステップ5：テストツールで検証する
- Rich Results Test（リッチリザルトテスト）
- Googleが公式提供
- 対応しているリッチリザルトタイプについて、エラー／警告をチェック
https://search.google.com/test/rich-results
- Search Console
- 対応タイプごとのレポート（パンくずリスト、FAQ、商品など）
- 検出されたエラー／改善点を一覧で確認
テストで「リッチリザルトに対応している」と出ても、必ずしも実際の検索結果に表示されるとは限らない ことに注意（後述）。
5．“深化／多様化”に伴うよくある誤解と落とし穴
誤解①：構造化データを書けば“必ず”リッチリザルトになる
これはよくある誤解で、
構造化データは「リッチリザルトの権利」ではなく、「資格」を与えるもの
と理解するのが正しいです。
実際、構造化データ専門のツール提供会社も、「構造化データはあくまで“可能性を開く”ものであり、表示するかどうかはGoogle次第」と明言しています。
品質、信頼性、検索クエリとの関連性など、他の要素も含めて総合的に判断されます。
誤解②：AIがあるから構造化データはいらなくなる？
むしろ逆で、AIが「どの情報を使うか」を判断するために構造化データの重要性は増しています。
- AI Overviews の実験で、「しっかりした構造化データ」を入れたページだけが採用されたケース
- AIは曖昧さが苦手で、構造化データのような“はっきりした事実情報”を好むという解説
AIに読んでもらうためのHTMLの補助線” として、構造化データの役割はむしろ拡大しています。
誤解③：AIにスキーマを書かせればOK（ノーチェック）
最近多いのが、
「ChatGPTや生成AIにスキーマを書かせて、そのまま貼る」
というパターンで、Googleのリッチリザルトテストで「アイテムが検出されない」「フォーマットエラー」 になる例も増えています。
AIに書かせるのは良いとしても：
- schema.org上でタイプとプロパティを確認
- リッチリザルトテストで検証
- 表示内容と矛盾していないかチェック
という “人間の最終チェック” は必須です。
6．実務でどう使い分けるか（ざっくり設計方針）
コーポレートサイト・制作会社サイトなど
- 全ページ共通で
- WebSite
- Organization（会社情報）
- 代表的な記事・ブログで
- Article / BlogPosting
- BreadcrumbList（パンくず）
E-E-A-Tとブランドの信頼性を高める方向。
ブログ・メディアサイト
- 各記事
- Article / BlogPosting
- Author（Person）
- BreadcrumbList
- Q&A記事
- FAQPage
- HowTo記事
- HowTo
「質問→答え」「手順→ステップ」系を増やすとAI要約に使われやすい。
ECサイト・ショップ
- 各商品ページ
- Product + Offer + AggregateRating
- 店舗情報ページ
- LocalBusiness + Organization
- キャンペーン記事
- Article / BlogPosting
Merchant Center やショッピング枠、AI検索での情報提示に直結。
ローカルビジネス（店舗・クリニックなど）
- 店舗ページ
- LocalBusiness / MedicalClinic など業種別タイプ
- OpeningHoursSpecification / AggregateRating / Review
- アクセス・問い合わせページ
- LocalBusiness + WebPage
Googleビジネスプロフィールと整合性を取りつつ、ローカルSEO・ハイパーローカル検索に強くする。
まとめ：構造化データは「ページの翻訳」から「エンティティのモデリング」へ
これまでの構造化データは、
「このページは◯◯ページです」と伝える“翻訳レイヤー”
というイメージが強かったですが、今はそれが進化して、
「このページには、こういうエンティティ（人・組織・商品・イベント）がいて、
それぞれがこういう関係性で結びついています」
という “世界モデル（ナレッジグラフ）の一部をサイト側から提供する” 役割になってきています。
- スキーマの種類は増え続け
- 組み合わせ・ネストも自由度が高まり
- 利用先はSEOだけでなく、AI検索・ナレッジグラフ・ショッピング・ローカル検索へと多様化
しているのが、「構造化データ・スキーママークアップの深化／多様化」の実像です。
