JSON-LD/Microdata/RDFaのどれを使うべき？

2026年5月時点でJSON-LDが第一推奨です。

構造化データの仕様変更にはどう対応すれば良いですか？

半年〜1年単位で要件が更新されるため、最低半年に1度Google公式ドキュメントを再確認します。

構造化データ完全実装ガイド｜LLMO/AIO/SEOで効果を出すJSON-LD 12パターン【2026年版】

構造化データとは何か：LLMO/AIO/SEOの共通基盤

構造化データ（Structured Data）とは、Webページの意味的内容を機械可読な形式で記述する標準仕様です。Schema.orgが定義する語彙（Vocabulary）に基づき、JSON-LD・Microdata・RDFaの3形式で実装できますが、Googleと主要AI回答エンジンが推奨する2026年5月時点の標準はJSON-LDです。

構造化データの実装は、SEO（Featured Snippet / リッチリザルト）、AIO（AI Overview引用）、LLMO（LLM学習・推論への組み込み）、AEO（AI回答エンジン引用）すべての施策で共通の基盤となります。構造化データなくして2026年以降のWeb最適化は成立しません。

構造化データの3つの形式比較

形式	記述場所	2026年Google推奨度
JSON-LD	head/body内のscriptタグ	◎ 第一推奨
Microdata	HTMLタグ属性	○ 互換性あり
RDFa	HTMLタグ属性	△ 非推奨

JSON-LDが推奨される理由

HTMLマークアップから独立しており、CMSとの相性が良い
テンプレート化・自動生成が容易
Google公式ドキュメントが第一推奨形式として明示
主要AI回答エンジン（ChatGPT/Perplexity/Gemini）が共通で解釈

パターン1：Organization（運営者の根幹）

全ページのheadに必ず1つ配置する最重要タイプ。AIが「誰がこのサイトを運営しているか」を認識する基盤データです。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "株式会社サンプル",
  "alternateName": ["Sample Inc.", "サンプル"],
  "url": "https://example.com",
  "logo": "https://example.com/logo.svg",
  "sameAs": [
    "https://twitter.com/example",
    "https://www.linkedin.com/company/example",
    "https://ja.wikipedia.org/wiki/サンプル"
  ],
  "address": {
    "@type": "PostalAddress",
    "addressCountry": "JP",
    "addressRegion": "東京都",
    "addressLocality": "渋谷区"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+81-3-1234-5678",
    "contactType": "customer service"
  }
}

実装ポイント

@idは全ページで同一URLを使用（エンティティ統合の核）
sameAsにWikipedia/Wikidata/SNSを列挙してエンティティ強化
alternateNameに英語名・略称・ブランド名を網羅

パターン2：Article（記事ページ標準）

記事・ブログ・コラム全般に設置。著者と発行日・更新日をAIに伝える基本タイプ。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/articles/sample/#article",
  "headline": "記事タイトル（H1と一致）",
  "description": "記事の要約（120字以内）",
  "image": "https://example.com/og/sample.png",
  "datePublished": "2026-05-14T09:00:00+09:00",
  "dateModified": "2026-05-14T09:00:00+09:00",
  "author": {
    "@type": "Organization",
    "@id": "https://example.com/#organization"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization"
  },
  "mainEntityOfPage": "https://example.com/articles/sample/",
  "inLanguage": "ja"
}

NewsArticleとBlogPostingとの使い分け

NewsArticle：報道・ニュース記事
BlogPosting：個人/企業ブログ
Article：上記以外の一般記事（迷ったらこれ）

パターン3：Service（サービス紹介ページ）

提供サービスをAIに認識させる。料金・対応地域・対象を明示することで指名検索やAI回答での想起率が向上。

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/services/seo/#service",
  "name": "LLMO最適化コンサルティング",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization"
  },
  "serviceType": "AI最適化／SEO",
  "areaServed": {
    "@type": "Country",
    "name": "JP"
  },
  "description": "LLM時代の検索最適化を支援するコンサルティングサービス。",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "JPY",
    "price": "300000"
  }
}

パターン4：Product（EC商品ページ）

商品ページの必須タイプ。AggregateRating・Review・Offerと組み合わせて完全実装する。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/p001/#product",
  "name": "サンプル商品",
  "image": "https://example.com/img/p001.jpg",
  "description": "商品の説明文。",
  "sku": "P001",
  "brand": {
    "@type": "Brand",
    "name": "Sample"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/p001/",
    "priceCurrency": "JPY",
    "price": "9800",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "127"
  }
}

2026年版の必須プロパティ

shippingDetails（OfferShippingDetails）の追加が必須化
hasMerchantReturnPolicy（MerchantReturnPolicy）の追加が推奨
itemCondition（NewCondition／UsedCondition）の明示

パターン5：FAQPage（最強の引用獲得タイプ）

AI回答エンジンが最も直接引用する構造化データ。1ページあたり3〜10問のQ&Aを推奨。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化データを実装すると順位は上がりますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "直接の順位要因ではありませんが、リッチリザルト表示・CTR向上・AI Overview引用率向上を通じて間接的に流入と認知度を高めます。"
      }
    }
  ]
}

FAQPageの注意点

2023年8月以降、Googleのリッチリザルト表示は権威機関のみに制限
しかしAI Overview/ChatGPT/Perplexityでは引き続き強力に機能
本文のFAQセクションと構造化データの内容を一致させる
同一質問を複数ページに分散させない

パターン6：HowTo（手順解説ページ）

料理レシピ・DIY・設定手順等のページに有効。ステップ数・所要時間・必要道具を構造化。

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "JSON-LDを実装する方法",
  "totalTime": "PT30M",
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Schema.orgからタイプを選定",
      "text": "対象ページの内容に合うタイプを選びます。"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "JSON-LDをhead内に配置",
      "text": "scriptタグでJSON-LDを記述します。"
    }
  ]
}

パターン7：BreadcrumbList（サイト構造の明示）

パンくずリストを構造化。AIにサイト階層を伝え、エンティティ理解を強化。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "LLMO",
      "item": "https://example.com/llmo/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "構造化データ",
      "item": "https://example.com/llmo/kouzouka-data/"
    }
  ]
}

パターン8〜12：その他重要タイプ

パターン8：Review（個別レビュー）

商品・サービス・場所への単一レビュー。reviewRatingとauthorを必須化。

パターン9：Event（イベント・セミナー）

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "LLMOカンファレンス2026",
  "startDate": "2026-07-15T10:00:00+09:00",
  "endDate": "2026-07-15T18:00:00+09:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "location": {
    "@type": "Place",
    "name": "東京国際フォーラム",
    "address": "東京都千代田区丸の内3-5-1"
  }
}

パターン10：JobPosting（求人）

Googleしごと検索の出稿要件。title description datePosted hiringOrganization jobLocation baseSalary等を網羅。

パターン11：LocalBusiness（店舗・施設）

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "サンプル店舗",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "渋谷1-2-3",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都",
    "postalCode": "150-0002",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": "35.6580",
    "longitude": "139.7016"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "10:00",
      "closes": "20:00"
    }
  ]
}

パターン12：Course（オンライン講座・スクール）

2026年版で要件強化。hasCourseInstance（CourseInstance）とoffersが必須プロパティに昇格。

検証ツールと実装フロー

構造化データは「実装＝完了」ではなく、検証ツールで合格を取って初めて効果を発揮します。

必須検証ツール

ツール	用途	URL
Rich Results Test	Googleリッチリザルト対応確認	search.google.com/test/rich-results
Schema Markup Validator	Schema.org準拠の構文検証	validator.schema.org
Search Console	本番サイトの構造化データ状態監視	search.google.com/search-console

実装フロー（5ステップ）

対象ページの種別を選定（記事／商品／サービス／FAQ）
該当パターンのJSON-LDテンプレートを作成
Schema Markup Validatorで構文検証
Rich Results Testでリッチリザルト適格性確認
本番デプロイ後、Search Consoleで監視

構造化データ実装で陥りやすい落とし穴

落とし穴1：本文と乖離した記述

構造化データに記述した内容が本文に存在しないと、Googleはスパム判定する場合があります。「FAQ構造化データに10問あるが本文には3問しかない」等は危険。

落とし穴2：複数Organization設置

サイト内で異なる@idのOrganizationを複数設置すると、エンティティが分散します。@idは全ページで同一URLに統一。

落とし穴3：dateModified自動更新の罠

テンプレートで「ページ表示時の日付」を出力すると、毎日dateModifiedが変動しスパム判定の原因に。実際の更新時のみ書き換える運用に統一。

落とし穴4：Person構造化データの権威性不足

著者Personを実装しても、その人物のSNS・著書・経歴がWebに存在しないと「実在性不明」と判定されます。Person実装時は必ずsameAs・jobTitle・worksForを揃える。

落とし穴5：仕様変更の追従漏れ

Google公式仕様は半年〜1年単位で更新されます。2026年5月時点でProduct/Event/Course/JobPostingが要件強化済み。最低半年に1度はGoogle公式ドキュメントを再確認。

12パターンの実装テンプレート・検証・本番デプロイ・継続監視までを一括支援するサービスは、Koukoku.aiが提供しています。サイト全体の構造化データ網羅率を90%以上に引き上げる「構造化データ完全実装パック」をご活用ください。

よくある質問

構造化データを実装すると検索順位は上がりますか？: 直接の順位要因ではありませんが、リッチリザルト表示・CTR向上・AI Overview引用率向上を通じて間接的に流入と認知度を高めます。
JSON-LD/Microdata/RDFaのどれを使うべき？: 2026年5月時点でJSON-LDが第一推奨です。
構造化データの仕様変更にはどう対応すれば良いですか？: 半年〜1年単位で要件が更新されるため、最低半年に1度Google公式ドキュメントを再確認します。