構造化データJSON-LDの書き方3ステップ｜リッチリザルト＆AI検索対策【2026年版】

<!-- rewrite-v2 -->

構造化データ（JSON-LD）の書き方

この記事の結論: 構造化データはJSON-LD形式で書くのが2026年標準です。Article・FAQ・Breadcrumbの3つを最低限実装すれば、リッチリザルト獲得とAI引用率の両方が改善します。

最終更新日: 2026-05-04

はじめに

「構造化データって何？」「JSON-LDって難しそう」と感じる初心者向けに、構造化データの基本と書き方を解説します。コピペで使える実装例も含めるので、明日から自サイトに適用できます。本記事はGoogle Search Central — 構造化データ概要に準拠しています。

SEOの現場では、構造化データは「やる/やらない」の二択ではなく「どこまで深掘りするか」が論点になりつつあります。Googleが2014年にJSON-LDを正式サポートして以来、HTML本体を変更せずにメタ情報を追加できるこの仕組みは、CMSやヘッドレス構成との相性の良さも手伝って急速に普及しました。さらに2024〜2025年にかけては、AI検索(AI OverviewやPerplexity、ChatGPT Search)が回答を組み立てるときに構造化データを参照することが各社のドキュメントで明らかになり、純粋な「リッチリザルト目的」を超えた重要性を持つようになっています。

→ 詳しくはSEOとは？初心者向け完全ガイド【2026年版】も参照してください。

構造化データとは

構造化データは、ページの内容をコンピュータが理解しやすい形式で記述する仕組みです。「これは記事です」「著者は田中太郎です」「公開日は2026年5月4日です」といった情報を機械可読にします。

Googleはこれをもとに、検索結果のリッチリザルト（パンくず、FAQ、レビュー星評価など）を生成します。AI検索でも参照されるため、LLMO対策としても重要です。実際 OpenAI のクローラー仕様 や Perplexity の AI クローラー は構造化データを参照することを公表しており、生成AI時代でも有効性が裏付けられています。

JSON-LDとは

JSON-LD（JavaScript Object Notation for Linked Data）は、構造化データを記述する3つの形式の1つで、Googleが2026年現在最も推奨している形式です。

JSON-LDのメリットは「HTMLと完全分離」「メンテしやすい」「テンプレ化しやすい」ことです。

JSON-LD / Microdata / RDFa の徹底比較

3つのフォーマットは記述方法もパフォーマンス特性も大きく異なります。新規実装ではJSON-LDがほぼ唯一の選択肢ですが、既存サイトをリライトする際は「現状どの形式で書かれているか」を把握する必要があります。

JSON-LDは2014年にGoogleが正式採用してから、Schema.orgのほぼすべての語彙をカバーする形式に成長しました。AI検索エージェントもJSON-LDをパースしやすく、LLMO観点でも有利です。

→ 詳しくはLLMOとは？AI検索最適化の基本で生成AI時代の構造化データの位置づけを解説しています。

Schema.orgとは

Schema.orgは、Google、Microsoft、Yahoo!、Yandexが共同で作った構造化データの語彙集です。「Article」「Recipe」「Event」など800種類以上のタイプが定義されています。

JSON-LDはSchema.orgの語彙を使って書きます。

Schema.orgの語彙は階層構造になっており、ルートはThingという抽象タイプです。たとえばArticle → CreativeWork → Thingという継承関係があり、上位タイプのプロパティはすべて下位で利用できます。語彙を選ぶときは「より具体的なタイプ」を選ぶのが原則で、ニュース記事であればArticleよりNewsArticle、ブログ記事であればBlogPostingを使うとGoogleやAIクローラーがより正確に文脈を理解します。

実装例1：Article（記事）

最も基本的なスキーマです。ブログ記事・ニュース記事に必須です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データ（JSON-LD）の書き方",
  "datePublished": "2026-05-04",
  "dateModified": "2026-05-04",
  "author": {
    "@type": "Person",
    "name": "編集部",
    "url": "https://example.com/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "LLMO Tool",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "image": "https://example.com/og.png"
}
</script>

実装例2：FAQPage（よくある質問）

FAQページや記事内のFAQを構造化すると、検索結果でアコーディオン表示される可能性があります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "JSON-LDとMicrodataはどちらがいいですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Googleが2026年現在JSON-LDを推奨しています。"
      }
    }
  ]
}
</script>

ポイント: 2023年以降、FAQリッチリザルトは政府系・健康系などごく一部のサイトのみに表示されるようになりました。それでもAI検索の引用元としては有効です。

実装例3：BreadcrumbList（パンくずリスト）

サイト構造を伝えるパンくずです。検索結果でURLの代わりにパンくずが表示されます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "SEO基礎",
      "item": "https://example.com/seo/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "構造化データの書き方"
    }
  ]
}
</script>

実装例4：Person（著者）

Personスキーマは著者情報を機械可読化します。E-E-A-T観点で「誰が書いたか」を明示することは、近年のGoogleアルゴリズムでも生成AIの引用判断でも極めて重要です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "田中太郎",
  "jobTitle": "シニアSEOコンサルタント",
  "worksFor": {
    "@type": "Organization",
    "name": "LLMO Tool"
  },
  "url": "https://example.com/authors/tanaka",
  "image": "https://example.com/authors/tanaka.jpg",
  "sameAs": [
    "https://twitter.com/tanaka",
    "https://www.linkedin.com/in/tanaka",
    "https://github.com/tanaka"
  ],
  "alumniOf": "東京大学",
  "knowsAbout": ["SEO", "LLMO", "コンテンツマーケティング"]
}
</script>

sameAsプロパティは特にAI検索が重視するシグナルで、外部の権威あるプロフィール(LinkedIn、Wikipedia、学術データベース等)へのリンクを並べておくと「この人物は実在し、複数の場で同じアイデンティティを公開している」ことの証明になります。

→ 詳しくはE-E-A-Tとは？経験・専門性・権威性・信頼性の高め方で著者情報の整え方を解説しています。

実装例5：Organization（組織）

サイト全体で1回だけ書けば良い、最もコスパの高いスキーマです。トップページの<head>に置くのが定石です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "LLMO Tool",
  "alternateName": "LLMOツール",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "description": "AI検索時代のSEO/LLMO対策ツール",
  "foundingDate": "2024-01-15",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "千代田区丸の内1-1-1",
    "addressLocality": "東京都",
    "postalCode": "100-0005",
    "addressCountry": "JP"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+81-3-1234-5678",
    "contactType": "customer support",
    "availableLanguage": ["Japanese", "English"]
  },
  "sameAs": [
    "https://twitter.com/llmotool",
    "https://www.linkedin.com/company/llmotool"
  ]
}
</script>

ブランドメンションを生成AIが拾うとき、Organizationスキーマは「同名の別組織」と区別する決定打になります。特にコーポレートサイトでは必ず実装しましょう。

実装例6：Product（商品）

ECサイトの肝となるスキーマで、価格・在庫・評価を構造化します。Google ショッピングや強調スニペット、商品リッチリザルトの土台です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "LLMO診断プレミアム",
  "image": [
    "https://example.com/products/llmo-premium-1.jpg",
    "https://example.com/products/llmo-premium-2.jpg"
  ],
  "description": "AI検索エンジンへの露出を最適化する月額診断サービス",
  "sku": "LLMO-PREM-001",
  "brand": {
    "@type": "Brand",
    "name": "LLMO Tool"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/llmo-premium",
    "priceCurrency": "JPY",
    "price": "29800",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "128"
  }
}
</script>

priceValidUntilは省略するとGoogleが警告を出します。在庫切れの場合はavailabilityをOutOfStockに切り替える運用も必須です。

→ 詳しくはGoogle Search Console基礎でリッチリザルトのモニタリング方法を解説しています。

実装例7：Review（レビュー）

商品やサービスの個別レビューを構造化します。AggregateRating(複数レビューの集計)と組み合わせて使うのが一般的です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Review",
  "itemReviewed": {
    "@type": "Product",
    "name": "LLMO診断プレミアム"
  },
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "5",
    "bestRating": "5"
  },
  "author": {
    "@type": "Person",
    "name": "山田花子"
  },
  "datePublished": "2026-04-20",
  "reviewBody": "AI検索からの流入が3倍になりました。月額の元はすぐ取れます。"
}
</script>

「やらせレビュー」を疑われるとガイドライン違反で手動対策の対象になるため、実在するレビューのみ構造化することが重要です。

実装例8：HowTo（手順解説）

2024年以降、Googleの一般リッチリザルトからは外れましたが、レシピ系のRecipe内で間接的に使われたり、AI検索の手順回答の根拠として参照されたりするため、依然として有用です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "JSON-LDをWordPressに実装する手順",
  "totalTime": "PT15M",
  "estimatedCost": {
    "@type": "MonetaryAmount",
    "currency": "JPY",
    "value": "0"
  },
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "プラグインをインストール",
      "text": "Yoast SEOまたはRank Mathをインストールします。"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "サイト情報を入力",
      "text": "Organization情報を設定画面で入力します。"
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "リッチリザルトテストで検証",
      "text": "公開後、リッチリザルトテストで構造化データが正しく出力されているか確認します。"
    }
  ]
}
</script>

その他の主要スキーマ

検証ツール

実装したJSON-LDは必ず検証します。

1. リッチリザルトテスト: Google公式、リッチリザルト対象スキーマの検証
2. Schema Markup Validator: Schema.org公式、構文と語彙のチェック
3. Search Consoleの拡張レポート: 実装後の本番モニタリング
4. Yandex 構造化データ検証: ロシア圏もカバーしたい場合

エラー・警告がゼロになるまで修正しましょう。リッチリザルトテストでは「コードを取得」ボタンから実際のレンダリング後 HTML を確認できるため、JavaScript で動的に挿入される構造化データが本当にクローラーから見えるかの最終確認に使えます。

SEO/LLMOへの効果

構造化データを実装すると次の効果が期待できます。

• CTR向上: リッチリザルトで目立つ（Search Engine Land の事例 では平均 30% の改善報告あり）
• クリックされやすい検索結果: 評価星、画像、FAQなど
• AI引用率の向上: ChatGPTやPerplexityがメタ情報を参照
• 音声検索対応: Google AssistantやAlexaが利用

実装の優先順位

すべてのスキーマを一度に実装する必要はありません。サイトの種類に応じて優先度を変えるのが効率的です。

特に Organization スキーマはサイト全体で1回だけ書けば済むため、「最低限の構造化データ」として最初に取り組むのが推奨されます。Article と組み合わせると、生成AIが「誰が書いたか」「どの組織が運営しているか」を正確に認識できるようになり、E-E-A-T シグナルの強化につながります。

やってはいけないNGパターン

• ページ本文と矛盾する内容を構造化データに書く
• 表示していないFAQをFAQPageに書く（ガイドライン違反）
• 同じスキーマを複数記述
• 不適切なスキーマタイプの選択

これらはガイドライン違反として手動対策の対象になります。

よくある質問

Q1. WordPressで簡単に構造化データを実装するには？

A. Yoast SEO、Rank Math、SEO SIMPLE PACKなどのプラグインが自動で生成します。手動実装は記事ごとに大変なので、プラグイン推奨です。

Q2. 構造化データだけで順位は上がりますか？

A. 直接的にはほぼ上がりません。ただしリッチリザルト経由でCTRが上がり、間接的に評価が改善する可能性があります。

Q3. 全ページに構造化データは必要ですか？

A. 重要ページから優先的に。特にトップページ（Organization）、記事ページ（Article）、商品ページ（Product）は必須です。タグページや古いアーカイブページなど、検索流入の少ないページまで無理に実装する必要はありません。

Q4. JSON-LDをbody内に書いても大丈夫ですか？

A. はい、Googleは<head>内・<body>内のどちらでも認識します。SPAやヘッドレスCMSではコンポーネント単位で出力したい場合があるため、body内のscript出力が便利です。ただしクローラーがJavaScript実行前のHTMLを参照する場面もあるため、SSR(サーバーサイドレンダリング)で初期HTMLに含めることを推奨します。

Q5. 同じページに複数のJSON-LDブロックを書いても良いですか？

A. はい、複数書いても問題ありません。ただし可読性とメンテ性を考えると@graph構文で1つにまとめるのが推奨されます。同じエンティティを複数ブロックで定義する場合は@idで同一性を明示しないと、クローラーが重複と誤認します。

Q6. 構造化データのエラーをGSCで発見しました。すぐに直すべき？

A. エラー(赤色表示)はリッチリザルト対象外になるため、優先度高で修正。警告(黄色)は推奨プロパティの欠落で、リッチリザルト表示には影響しないため、リソースに余裕があるときに対応すれば十分です。エラーの「該当URL」リストから直接修正対象が分かるので、月1回はチェックする運用が理想です。

Q7. AI検索(ChatGPT/Perplexity)向けには構造化データの書き方を変えるべき？

A. 基本は同じJSON-LD/Schema.orgで問題ありません。ただしAI検索はauthor、publisher、sameAs、datePublishedを特に重視するため、これらのプロパティを欠落させないよう注意します。AI向けの追加施策としてはllms.txtの併用が効果的です。

→ 詳しくはGoogle AI Overview対策も参照してください。

Q8. 構造化データの実装はSEO/LLMOどちらに効きますか？

A. 両方に効きますが、効き方が異なります。SEOではリッチリザルト経由のCTR改善が主な効果で、ランキングへの直接効果は限定的です。LLMOでは「AI検索が引用するページ」になる確率が上がり、回答内のブランド露出が増えます。2026年現在、特にLLMO効果が見直されており、AI検索からの流入を狙うサイトでは構造化データの優先度が一段高くなっています。

→ 詳しくはSEOとLLMOのハイブリッド戦略で両者の使い分けを解説しています。

<!-- thicken-v1 -->

構造化データ実装の段階別ロードマップ

すべて一度に実装しようとせず、段階的に展開するのが現実的です。

段階1: 基本3スキーマ（1週間）

• Organization（サイト全体で1回）
• Article（全記事で実装）
• BreadcrumbList（全ページで実装）

段階2: コンテンツ拡張（1ヶ月）

• FAQPage（FAQ がある記事）
• Person（著者ページ）
• WebSite + SearchAction（サイト内検索を構造化）

段階3: 業界特化（継続）

業界に応じて以下を追加：

• EC: Product, Review, Offer, AggregateRating
• イベント: Event
• レシピ: Recipe
• 求人: JobPosting
• ローカル: LocalBusiness

構造化データ運用の落とし穴

JSON-LD のテスト戦略

開発時の検証

Schema Markup Validator で構文と語彙のチェック。@context や @type の typo もここで発見します。

本番反映前

リッチリザルトテスト でリッチリザルト対象スキーマ（Article, FAQPage, Product 等）を確認。Google が認識する範囲のみ表示される点に注意。

本番モニタリング

Search Console の「拡張」レポートで、サイト全体のスキーマ実装状況とエラーを継続監視。週次で確認するのが推奨。

CI 自動化

pa11y や jsdom ベースのスクリプトで、PR 時に構造化データの破損を自動検出するパイプラインを組むと、リグレッションを防げます。

業界別の構造化データ戦略

サイトの種別ごとに、優先実装するスキーマと実装の深さは異なります。代表的な業界の戦略をまとめます。

メディア・出版

NewsArticleまたはArticleを全記事で実装し、authorにPerson、publisherにOrganizationをネストするのが基本パターンです。Google Newsの掲載基準を満たしたい場合はisAccessibleForFreeやhasPartなどの追加プロパティも検討します。AI検索が引用しやすいよう、speakableプロパティ(下記2026年新スキーマ参照)で読み上げ可能箇所を明示するのも有効です。

→ 詳しくはE-E-A-Tとは？経験・専門性・権威性・信頼性の高め方でメディア向けの著者情報設計を解説しています。

EC・物販

Productを全商品ページに、AggregateRatingとReviewをレビューセクションに、BreadcrumbListをカテゴリ階層に実装します。在庫状況をavailabilityで正確に同期させる仕組み(管理画面と連動するJSON-LD出力)が不可欠で、ここを怠ると「在庫切れなのに『在庫あり』と表示される」という深刻なUX問題に直結します。

店舗・ローカルビジネス

LocalBusiness(または飲食ならばRestaurant、医療ならMedicalClinic等の派生型)を実装し、住所、営業時間、電話番号、地図座標を網羅します。Googleビジネスプロフィールと整合性をとることで、ローカルSERPでの露出が安定します。

イベント・チケット

Eventスキーマに加え、オンライン開催であればeventAttendanceModeをOnlineEventAttendanceModeに設定します。コロナ禍以降、Googleはオンライン/オフラインの区別を厳格に求めるようになりました。

求人・採用

JobPostingは職種、給与レンジ、勤務地、雇用形態などを構造化します。Google for Jobsへの掲載要件として実質的に必須で、未実装だと求人検索のリッチパネルにまったく現れません。

レシピ・料理

Recipeスキーマは画像、調理時間、材料、栄養情報、手順を含めます。AIレシピ提案ツール(ChatGPTのレシピ生成等)はこの構造化データを直接読み取るため、AIが引用するレシピメディアを目指すなら必須です。

構造化データの効果測定

実装したら必ず効果を測定します。「やったつもり」で放置するのは最悪のパターンです。

Google Search Consoleの「拡張」レポート

GSCの「拡張」セクションには、実装している構造化データのタイプ別レポートが並びます。

CTRの比較分析

GSCの「検索パフォーマンス」を「ページ別」「クエリ別」に分解し、リッチリザルト対象ページとそうでないページのCTRを比較します。リッチリザルト導入後にCTRが顕著に上がっていれば、構造化データの貢献が定量的に見えます。

AI検索での引用追跡

ChatGPT、Perplexity、Google AI Overview、Claude.aiなどで自社ブランド名や主要キーワードを検索し、引用されているかを定期的にチェックします。引用されたページに共通する構造化データの特徴(Article+Organization+Personの3点セットが揃っているか等)を分析すると、AI検索向けの最適化方針が見えてきます。

→ 詳しくはGoogle AI Overview対策でAI検索からの引用獲得を解説しています。

A/Bテスト的な検証方法

サイト全体で一気に実装するのではなく、一部カテゴリだけ先行実装して2〜4週間後に流入を比較する方法も有効です。ただし構造化データはサイト構造シグナルでもあるため、長期的にはサイト全体実装が望ましく、A/Bテストはあくまで「効果の見える化」の手段と位置づけます。

失敗事例とアンチパターン

実装現場でよくある失敗を、原因と対策のセットでまとめます。

事例1：FAQの過剰実装でペナルティ

ECサイトが商品ページに大量の「よくある質問」をFAQPageマークアップ付きで掲載した結果、Googleから「マークアップが悪用されている」と判断され、サイト全体のリッチリザルトが2ヶ月停止した事例があります。対策：本文に視覚的に表示しているFAQのみマークアップする、商品仕様はFAQではなくProductのプロパティで記述する。

事例2：dateModifiedを毎日自動更新

CMSが「アクセスがあるたびにdateModifiedを現在時刻で書き換える」設定になっていたため、Googleから「鮮度を偽装している」と認識され、ランキングが下落した事例があります。対策：dateModifiedは実質的なコンテンツ更新があったときのみ書き換える。タイポ修正レベルでは更新しない。

事例3：型違いの@type指定

ニュースサイトがArticleではなく単にCreativeWorkを使ったため、Google Newsの掲載対象外となった事例があります。対策：可能な限り具体的な型(NewsArticle、BlogPosting、ScholarlyArticle等)を使う。

事例4：HTMLとJSON-LDの内容が一致しない

ホテル予約サイトが「JSON-LDでは1泊5,000円、表示価格は10,000円」という乖離を起こし、ガイドライン違反として手動対策を受けた事例。対策：CMSのテンプレートで、表示価格と構造化データを同じソース変数から出力する。

事例5：複数の@typeが衝突

トップページにOrganizationとLocalBusinessとWebSiteが別々のJSON-LDブロックで重複定義され、@idもないために「どのエンティティが正解か」をクローラーが判定できなくなった事例。対策：@id(URLベースの識別子)で同一エンティティであることを明示し、@graph構文で複数エンティティを1つのJSON-LDにまとめる。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "LLMO Tool"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}
</script>

@graph構文は2026年現在の推奨パターンで、Yoast SEOやRank Mathも内部的にこの形式で出力しています。

AI/LLMOにおける構造化データの役割

生成AIが回答を組み立てるとき、構造化データは「事実確認の最短パス」として使われます。AI検索エンジンの内部動作を整理すると以下のようになります。

特に2025年以降は、AI検索が「Wikipedia的なエンティティ知識ベース」を内部に持つようになり、Schema.orgはその更新源の一つとして使われています。Organizationスキーマを実装したサイトは、AIが「実在する組織」と認識する確率が体感で2〜3倍高まる、という実務報告も出始めています。

→ 詳しくはLLMが好む文章構造｜結論先出し・FAQ・箇条書きの効果でAI向けコンテンツ設計を解説しています。

llms.txtとの併用戦略

2024年に登場したllms.txtは、AIクローラー向けにサイトの主要コンテンツの索引を提供する新標準です。llms.txtで「重要ページの一覧」を示し、各ページにJSON-LDで詳細メタ情報を載せる、という二段構えがLLMO最適化の現時点でのベストプラクティスです。

構造化データのメンテナンス

構造化データは「一度書いて終わり」ではなく、継続的なメンテナンスが必要です。

月次メンテナンス

大規模リライト時の注意

サイトをリニューアルしたり、CMSを移行したりする際、構造化データが消失するのが最も多い事故です。リニューアル前後でリッチリザルトテストの結果を比較する、本番反映前にステージングでGSCのURL検査ツールで確認する、といったチェックを必ず組み込みましょう。

廃止予定スキーマへの対応

Googleは定期的に特定のスキーマのリッチリザルト対応を縮小・終了します。直近ではHowTo(2024年に一般検索から除外)、FAQPage(2023年に大半のサイトで非表示化)が代表例です。廃止されてもJSON-LD自体は残しておくべき(AI検索は依然参照する)ですが、リッチリザルト目当ての過剰実装はやめる、という判断が必要になります。

2026年の新スキーマ・新機能

Schema.orgとGoogleは継続的に新しいスキーマや機能を追加しています。2025〜2026年にかけて注目すべきものを整理します。

Speakable

ニュース記事の中で「音声アシスタントが読み上げるべき箇所」をCSSセレクタやXPathで指定するプロパティです。Google Assistantが日本語ニュースの読み上げに利用する一方、AI音声アシスタントの増加で再注目されています。

{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "○○のニュース",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".article-headline", ".article-summary"]
  }
}

ImageObject拡張

画像のライセンス情報、撮影者、撮影地、AI生成かどうか(creditText、creator、copyrightNotice、license)を構造化できるようになりました。Google画像検索のライセンス表示や、AI生成画像の識別に使われます。

LearningResource / Course

教育系コンテンツ向けにCourse、LearningResourceスキーマが拡充され、対象学年、所要時間、前提スキルなどを構造化できます。AI学習プラットフォームが推薦アルゴリズムで利用しています。

MedicalEntity / Drug

医療系サイト向けの専門スキーマで、薬剤情報、症状、診断、治療方法を構造化します。YMYL領域のE-E-A-Tシグナルとして特に重要です。

Dataset

オープンデータや統計情報を構造化するスキーマで、Google Dataset Searchの掲載要件です。研究機関、政府サイト、データジャーナリズム系メディアで活用されています。

2026年に検討すべき新規実装の優先順位

関連用語

• 構造化データ
• JSON-LD
• Schema.org
• SERP

関連記事

• SEOとは？初心者向け完全ガイド【2026年版】
• LLMが好む文章構造｜結論先出し・FAQ・箇条書きの効果
• llms.txtとは？AIクローラー向け新標準
• E-E-A-Tとは？経験・専門性・権威性・信頼性の高め方

参考文献・出典

• Google Search Central — 構造化データ — 公式ガイド
• Schema.org — 構造化データ語彙の公式サイト
• Google リッチリザルトテスト — 検証ツール
• json-ld.org — JSON-LD仕様