構造化データ完全ガイド 2026年版 — Schema.org/JSON-LD で AI検索と SERP を制する実装の教科書

構造化データは「SEOのちょっとした飾り」から、検索結果に乗るか乗らないか / AI に引用されるかされないかを決める基盤技術へと役割が変わりました。2026年5月7日には Google が長年残っていた FAQ リッチリザルトを完全終了し、HowTo も既に検索結果から消えています。一方で schema.org 本体は活発に更新が続き、最新版は v30.0（2026年3月19日リリース、823 タイプ・1,529 プロパティ）に達しました。役割が変わった 構造化データ を、現場で使える形に並べ直しました。AI検索引用とリッチリザルトの両軸で機能させるための JSON-LD コードを、Tufe Company の現場視点でまとめています。

※ 出典: Google Search Central「Changes to FAQ rich results」（取得 2026-05） / Schema.org Release listing（取得 2026-05）

Chapter 1: なぜ今、構造化データなのか — AI検索時代の引用権

「リッチリザルト目当て」だけでは投資判断を見誤る

2020〜2023 年頃まで、構造化データを実装する最大の動機は「SERP 上のリッチリザルト獲得」でした。FAQ アコーディオン、レビュー星、HowTo の手順カード、サイトリンク — これらが CTR を引き上げると信じられ、実装の ROI もそこで語られていました。

しかしこの構図は 2023 年 8 月の Google による FAQ・HowTo リッチリザルトの段階的縮小開始から崩れ始め、2026 年 5 月 7 日に FAQ リッチリザルトは権威ある政府・医療サイトを除いて完全廃止されました。2026年6月にはリッチリザルトテストからの検出も外され、Search Console API のサポートも 2026 年 8 月で終了予定です。

※ 出典: Search Engine Land「Google to no longer support FAQ rich results」（取得 2026-05） / Google Search Central Blog（2023年8月）（取得 2026-05）

つまり「FAQ schema を入れれば SERP で目立つ」という時代は終わりました。それでも構造化データの戦略的重要性はむしろ上がっています。理由は次章の二点です。

AI検索エンジンが構造化データを読み取り、引用に使っている

ChatGPT Search・Perplexity・Google AI Overview は、Web ページの本文だけでなく schema.org JSON-LD を解析してエンティティ（会社・人物・商品・場所）を識別し、引用ソースの選定にも反映しています。OpenAI 公式が公表する ChatGPT の週間アクティブユーザーは 9億人規模（2026年2月時点）であり、日本国内でも検索行動に生成 AI を使う層が約 4 割に達しています（サイバーエージェント GEOラボ調査、2025年10月）。

※ 出典: Search Engine Land「OpenAI: ChatGPT now has 900 million weekly active users」（取得 2026-05） / サイバーエージェント GEOラボ調査（2025年10月）（取得 2026-05）

Google AI Overview の表示で、上位サイトの CTR が大幅低下

Seer Interactive の調査では AI Overview 表示時に Organic CTR が約 61% 低下、Ahrefs の調査でも約 58% の低下が確認されています。「1位を取ってもクリックされない」現象が拡大する一方、AI Overview および AI 検索の引用枠に入った企業はブランド露出を一気に獲得できます。

※ 出典: Search Engine Land「Google AI Overviews drive 61% drop in organic CTR」（取得 2026-05） / Ahrefs「AI Overviews Reduce Clicks by 58%」（取得 2026-05）

結論はシンプルです。構造化データはもはや「リッチリザルト目的の装飾」ではなく、AI と検索エンジンに自社の輪郭を正しく認識させる「引用権の整備」 へと役割を変えました。詳細な戦略全体像は LLMO/GEO 完全ガイド と、AI 検索流入を伸ばす実務手順は SEO 完全ガイド 2026年版 と併読してください。

Chapter 2: schema.org の全体像と JSON-LD の基本

schema.org とは何か（最新は v30.0）

schema.org は Google / Microsoft / Yahoo / Yandex の共同イニシアチブによる構造化データ語彙です。2011 年公開、現在の最新版は v30.0（2026年3月19日リリース）で、823 タイプ・1,529 プロパティを定義しています。

※ 出典: Schema.org Release listing（取得 2026-05） / Schema.org Version 30.0（取得 2026-05）

3 種の記述形式と Google の推奨

※ 出典: Google Search Central「Introduction to structured data markup in Google Search」（取得 2026-05）

Tufe Company が新規案件で実装する際は、特別な事情がなければ JSON-LD 一択です。理由は (1) HTML テンプレートと分離できるため CMS / Next.js との相性が良い、(2) 同一 @graph で複数エンティティを関連付けやすい、(3) 障害切り分けが早い（schema だけ無効化すれば本体には影響しない）の三点です。

JSON-LD の最小構造

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Tufe Company",
  "url": "https://tufecompany.co.jp",
  "logo": "https://tufecompany.co.jp/og-default.png"
}
</script>

3 つだけ覚えれば書けます。

1. @context — 必ず https://schema.org（http ではなく https）。
2. @type — schema.org のタイプ名。Organization / LocalBusiness / Article / Product など。
3. 以降のプロパティ — そのタイプに定義されているフィールドを記述。

用語整理（最低限の語彙）

紛らわしい Schema vs Plugin 自動実装 の判断軸は別途用意しています。

Chapter 3: Article / NewsArticle 実装 — 著者・日付・wordCount

Google が「必須」と呼ぶプロパティは無いが、推奨は明確

Google Search Central の Article ドキュメントは「必須プロパティは無い」と明記しつつ、以下を 強く推奨しています。

• headline（記事タイトル、最大 110 文字目安）
• image（16:9 / 4:3 / 1:1 の複数アスペクト比を推奨）
• datePublished（ISO 8601 形式）
• dateModified（ISO 8601 形式）
• author（Person または Organization、url 付き）
• publisher（Organization）

※ 出典: Google Search Central「Article structured data」（取得 2026-05）

Tufe Company が標準実装する Article テンプレート

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データ完全ガイド 2026年版",
  "description": "Schema.org/JSON-LD で AI検索とリッチリザルトを両軸で機能させる実装ガイド",
  "image": [
    "https://tufecompany.co.jp/api/og?slug=structured-data-complete-2026"
  ],
  "datePublished": "2026-05-24T09:00:00+09:00",
  "dateModified": "2026-05-24T09:00:00+09:00",
  "author": {
    "@type": "Organization",
    "name": "Tufe Company",
    "url": "https://tufecompany.co.jp/company"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tufe Company",
    "logo": {
      "@type": "ImageObject",
      "url": "https://tufecompany.co.jp/logo.png"
    }
  },
  "wordCount": 9800,
  "inLanguage": "ja",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://tufecompany.co.jp/guides/structured-data-complete-2026"
  },
  "reviewedBy": {
    "@type": "Person",
    "name": "Tufe Company 代表"
  }
}

Article / NewsArticle / BlogPosting の使い分け

よくある失敗（Article 編）

• datePublished を "2026年5月24日" と日本語で書いてしまう → 必ず ISO 8601（2026-05-24 または 2026-05-24T09:00:00+09:00）。
• image を相対パス（/og.png）で書く → 必ず絶対 URL。
• author を文字列（"author": "Tufe"）で書く → Google は Person または Organization のオブジェクトを推奨。
• dateModified を更新時に書き換え忘れる → 「鮮度」シグナルが古いままになり AI 引用率に悪影響。

※ 出典: Google Search Central「Article structured data」（取得 2026-05）

Tufe Company の現場メモ

Article schema の reviewedBy・wordCount・dateModified の 3 点は、N=12 案件で reviewedBy / wordCount 実装後に AI 引用露出が増えた感触があります（※ Tufe Company 内部観察 / 2026-05時点）。Tufe Company の pSEO ページではこれを frontmatter 必須項目化し、/app/guides/[slug]/page.tsx のメタデータ生成で漏れがないように配線しています（詳細は Article schema 必須要件メモ）。

E-E-A-T の Trustworthiness を保証する材料として、author.url から会社情報ページや個人プロフィールに辿れる状態を整えることも、AI 検索の引用判定で効きます。

Chapter 4: LocalBusiness 実装 — MEO 連携

LocalBusiness は MEO の心臓部

実店舗・士業事務所・サロン・クリニックを運営している場合、LocalBusiness schema は GBP（Google ビジネスプロフィール）と並ぶ MEO の二大基盤です。GBP が Google マップ側のデータベース、LocalBusiness schema が Web サイト側のデータベースとして、両者が一致していると Google は「同一エンティティ」と判定しやすくなります。

Google が要求する必須プロパティ（2 つだけ）

• name
• address（PostalAddress 型）

※ 出典: Google Search Central「Local Business (LocalBusiness) structured data」（取得 2026-05）

推奨プロパティ

• aggregateRating（口コミの平均評価。ページ内に実表示が必須）
• geo（緯度経度、最小 5 桁精度）
• openingHoursSpecification（曜日別営業時間）
• priceRange（$ 〜 $$$$ または ¥1,000-3,000 など）
• telephone（+81-3-... の国際電話番号形式）
• url（店舗ページの絶対 URL）
• image
• sameAs（GBP / SNS の URL）

業種別 @type の選び方

汎用 LocalBusiness ではなく、業種特化型を使うとシグナルが強くなります。

Tufe Company の LocalBusiness テンプレ（士業向け）

{
  "@context": "https://schema.org",
  "@type": "AccountingService",
  "@id": "https://example.com/#business",
  "name": "○○税理士事務所",
  "image": "https://example.com/storefront.jpg",
  "url": "https://example.com",
  "telephone": "+81-3-1234-5678",
  "priceRange": "¥¥",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "○○1-2-3 ○○ビル4F",
    "addressLocality": "杉並区",
    "addressRegion": "東京都",
    "postalCode": "166-0001",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.69384,
    "longitude": 139.65340
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "sameAs": [
    "https://www.google.com/maps?cid=XXXXXXXX",
    "https://www.facebook.com/example"
  ]
}

MEO 連携の必須チェック（NAP 整合）

LocalBusiness schema・GBP・サイト本文・サイテーション登録先で NAP（Name / Address / Phone）の表記をすべて一致させることが、Tufe Company の現場で必ず最初にやる仕事です。住所の 1-2-3 を 1丁目2番3号 と書き分けるだけでも別エンティティとして扱われるケースがあるため、表記ゆれは絶対禁止です（NAP 一致は Google ビジネスプロフィール ヘルプ 推奨）。

詳細な業種別の運用は 杉並 MEO・歯科 MEO・整骨院 MEO・税理士 SEO コンテンツ など各業種・各エリアのページで扱っています。サイテーション・Map Pack も併せて押さえてください。

よくある失敗（LocalBusiness 編）

• priceRange を空文字や 要問合せ にする → Google は機械可読な値を期待。空ならフィールドごと削除。
• geo の小数桁が少なすぎる（35.6 など） → 最小 5 桁推奨。
• 多店舗で同一 schema を使い回す → 店舗ごとに別 @id を発行する。
• aggregateRating をページに実表示せず schema にだけ書く → ガイドライン違反。

Chapter 5: FAQ / HowTo 実装 — 廃止後の正しい付き合い方

2026 年 5 月、FAQ リッチリザルトは事実上終了

冒頭でも触れた通り、Google は 2026 年 5 月 7 日に FAQ リッチリザルトの表示を全サイトで停止しました。リッチリザルトテストでの検出は 2026 年 6 月で外れ、Search Console API のサポートは 2026 年 8 月で終了予定です。残るのは「権威ある政府・医療サイト」など限定的なケースのみです。

※ 出典: Search Engine Land「Google to no longer support FAQ rich results」（取得 2026-05）

それでも FAQ schema を残す価値はある

Google は「未使用の構造化データが検索に悪影響を与えることはない」と公式に説明しています。さらに重要なのは、FAQ schema は AI 検索エンジン側の Q&A 抽出に依然として活用されている点です。

• Perplexity・ChatGPT Search は FAQ schema の Question / Answer を引用候補として優先利用する傾向がある。
• 自社サイト内検索や音声アシスタント、内製チャットボット（Dify / LangChain / RAG）への取り込みでも活用できる。

つまり「SERP のリッチリザルト目的」ではなく、「AI 引用のための構造化情報」として FAQ schema は引き続き実装する価値があります。

Tufe Company の FAQ schema テンプレ

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "FAQ schema を実装してもリッチリザルトは出ますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "2026年5月7日以降、Google は政府・医療など限定的なサイト以外で FAQ リッチリザルトを表示していません。ただし FAQ schema 自体は AI 検索エンジン側の Q&A 抽出に活用されており、実装する価値は残っています。"
      }
    },
    {
      "@type": "Question",
      "name": "既存サイトの FAQ schema は削除すべきですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "削除不要です。Google 公式は未使用の構造化データが検索に悪影響を与えないと説明しています。AI 検索・自社内チャットボット・社内検索などへの活用余地もあります。"
      }
    }
  ]
}

HowTo schema は既に「終わっている」

HowTo リッチリザルト機能は 2023 年から段階的に縮小され、現在は SERP 上の表示機能としては完全に終了しています。Google Search Central の「Search Gallery」からも HowTo は外れました。新規実装で HowTo schema にリソースを投じる優先度は低いと判断して問題ありません。

※ 出典: Google Search Central Blog「Changes to HowTo and FAQ rich results」（取得 2026-05）

ただし「手順を構造的に記述したい」場合は、Article の本文を順序付きリスト（<ol>）にする、または Article + 本文中の見出し階層で十分機能します。

よくある失敗（FAQ/HowTo 編）

• 「FAQ schema を入れれば CTR 大幅アップ」という古い説をそのまま社内提案する → 2026 年現在、SERP 上は出ない。AI 引用目的に文脈を更新する。
• FAQ をページに実表示せず schema にだけ書く → ガイドライン違反。
• HowTo schema を新規実装する時間で、AI 引用に効く Article の冒頭結論型書き直しに投資する方が ROI が高い。

Chapter 6: Product / Review — EC 向け

Product schema は「商品スニペット」と「マーチャントリスティング」の二系統

Google は Product 構造化データを 2 つのレールで扱っています。

※ 出典: Google Search Central「Product (Product, Review) structured data」（取得 2026-05）

EC サイトを運営しているなら、原則として Merchant listing の要件を満たす実装を選びます。

Merchant listing 用 Product テンプレ

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "オーガニックコットン T シャツ",
  "image": [
    "https://example.com/tshirt-front.jpg",
    "https://example.com/tshirt-back.jpg"
  ],
  "description": "オーガニックコットン100%のクルーネックTシャツ。",
  "sku": "TS-ORG-001",
  "brand": {
    "@type": "Brand",
    "name": "Example Apparel"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/tshirt-organic",
    "priceCurrency": "JPY",
    "price": "3800",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "500",
        "currency": "JPY"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "JP"
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 14,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "127"
  }
}

Review / AggregateRating の重要原則

• ページに実表示が無いレビューを schema に書くのは禁止（ガイドライン違反でリッチリザルト対象外）。
• 自社レビューは Review、複数レビュー集約は AggregateRating。
• 第三者レビュープラットフォーム（楽天 / 食べログ / Google）の数値を引用する場合は出典明示が必要。
• スター画像を CSS で表現していても、テキストとして実数値が表示されていれば原則 OK。

EC で押さえるべき関連 schema

EC の Product / Category ページ運用全体は EC × Product page vs Category page CVR と EC × SEO・EC × LLMO/GEO で扱っています。WordPress vs Shopify の判断軸も併読すると、構造化データの実装難度の違いまで含めて整理できます。

Chapter 7: BreadcrumbList とサイト構造

BreadcrumbList は地味だが効く

BreadcrumbList は SERP に URL の代わりとして「ホーム > カテゴリ > 記事」のようなパンくず表示を出す機能です。FAQ・HowTo と違い 2026 年現在も健在で、特にサブディレクトリ階層が深いサイトで有効です。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://tufecompany.co.jp/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "ガイド",
      "item": "https://tufecompany.co.jp/guides"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "構造化データ完全ガイド",
      "item": "https://tufecompany.co.jp/guides/structured-data-complete-2026"
    }
  ]
}

全ページ共通で配置する 3 種

Tufe Company は次の 3 種を「全ページのテンプレート層」に配置することを推奨します。

1. Organization（または LocalBusiness）
2. WebSite + SearchAction
3. BreadcrumbList

これに各ページ固有の schema（記事なら Article、商品なら Product、店舗ページなら LocalBusiness 詳細）を追加します。@graph で束ねるとエンティティ間の関係（isPartOf / mainEntityOfPage / publisher）を明示できます。

サイト全体の @graph 例

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://tufecompany.co.jp/#org",
      "name": "Tufe Company",
      "url": "https://tufecompany.co.jp/",
      "logo": "https://tufecompany.co.jp/logo.png",
      "sameAs": ["https://x.com/tufecompany"]
    },
    {
      "@type": "WebSite",
      "@id": "https://tufecompany.co.jp/#site",
      "url": "https://tufecompany.co.jp/",
      "name": "Tufe Company",
      "publisher": {"@id": "https://tufecompany.co.jp/#org"}
    }
  ]
}

詳細な内部リンク設計と階層化は 内部リンク と サイトアーキテクチャ の章を参考にしてください。

Chapter 8: テストツールと検証方法

二大ツールの使い分け

Google が認識するのは Rich Results Test の方ですが、Schema Markup Validator は AI 検索クローラーや非 Google 検索エンジン（Bing 等）が見る可能性のある全プロパティを検証できます。両方かけるのが鉄則です。

Search Console の「拡張」レポート

本番デプロイ後の継続監視は Google Search Console の「拡張」セクション。以下のレポートが構造化データ別に出ます。

• Articles
• Products
• Breadcrumbs
• Local Business
• Sitelinks searchbox
• Videos
• など（FAQ・HowTo は 2026年6月以降縮小：Search Engine Land）

警告（Warning）は表示はされるが推奨プロパティ不足、エラー（Error）はリッチリザルト対象外。エラーは必ず潰します。

CLI / CI 組み込み（応用）

@scaffoldly/schema-org-validator・structured-data-testing-tool 等の OSS で CI に組み込めます。Tufe Company の Next.js 案件では、next build のあとに主要ルートをクロールして JSON-LD を抽出 → schema.org の JSON Schema で構文検証 → 主要プロパティの欠落チェックという 3 段階を CI で回しています。デプロイ時に新規記事の Article schema 必須項目（author / dateModified / wordCount）を強制する設計です。

推奨ワークフロー

1. ローカルで JSON-LD を作る
2. Schema Markup Validator で構文チェック
3. Rich Results Test でリッチリザルト適合チェック
4. ステージング環境にデプロイ
5. 再度 Rich Results Test で URL モードチェック
6. 本番デプロイ
7. Search Console 拡張レポートを 2 週間後にモニタ

検証は手間がかかるように見えますが、JSON-LD を一度テンプレ化すれば 1 ページ当たりの実装時間は十分短縮できます。

Chapter 9: よくある失敗 10 パターン

ここまでに散りばめた失敗を、再現性の高いチェック用に 10 個に集約します。

1. ページに無い情報を schema に書く — 最重大違反。AggregateRating・Review・FAQ・営業時間など、HTML 本文に表示されていない情報を JSON-LD に書くのはガイドライン違反で、リッチリザルト対象外＋手動対策のリスクあり。
2. 日付を日本語表記で書く — "datePublished": "2026年5月24日" は無効。必ず ISO 8601 (2026-05-24 または 2026-05-24T09:00:00+09:00)（Google Search Central「Article」）。
3. 画像・URL を相対パスで書く — /og.png・/about は不可。必ず絶対 URL（https://...）。
4. @type のスペルミス / 大文字小文字違い — localbusiness・Article（小文字）等は無効。@type は CamelCase で厳密に。
5. 必須プロパティの欠落 — Product の offers、Article の image、LocalBusiness の address 等。タイプごとに Google 公式ドキュメントで必須を確認。
6. @context が http — http://schema.org は古い表記。現在は https://schema.org 必須。
7. 複数 schema が衝突 / 重複 — 同一 URL に複数の LocalBusiness を書く、Article と NewsArticle を両方付ける等。原則 1 ページ 1 主体 schema。
8. 過去のリッチリザルトに依存した投資判断 — 「FAQ schema を入れれば CTR が大幅に上がる」は 2026 年現在通用しない。SERP リッチリザルト目的ではなく AI 引用目的に文脈を更新する。
9. 古い数字をそのまま使う — 例えば「Map Pack の CTR は 20-30%」「Featured Snippet は 1 位の 2-3 倍 CTR」「LP は最初の 3 秒で判断される」等は実証済の最新値（Backlinko の Map Pack CTR は約 17.6%、NN/g の判断時間は約 10 秒）と乖離する俗説。クライアント提案で使うと信用を失う。
10. dateModified を更新時に書き換え忘れる — 記事を改稿しても dateModified が古いままだと、AI 検索エンジンの「鮮度」シグナルが上がらず引用率に悪影響。リライト時の更新フローに dateModified の自動書き換えを組み込む。

※ Map Pack CTR の参考: Backlinko「Google Local Pack & Maps Click-Through Rate」 / NN/g の判断時間: Nielsen Norman Group「How Long Do Users Stay on Web Pages?」（取得 2026-05）

よくある質問

Q. 構造化データを実装すると検索順位は上がりますか？

構造化データ自体は直接的なランキング要因ではない、と Google は公式に説明しています。期待できるのはリッチリザルト経由の CTR 向上と、AI 検索エンジンが正しくエンティティを理解することによる引用機会の拡大です。詳しくは Chapter 1（AI検索時代の引用権）と Chapter 8（テストツールと検証）を参照してください。

Q. JSON-LD と Microdata、どちらを選ぶべきですか？

新規実装なら JSON-LD 一択です。Google も推奨形式として明示しており、HTML テンプレートと分離できるため CMS・Next.js との相性も良く、@graph で複数エンティティを一括記述できます。Microdata・RDFa は既存サイトの保守時のみ。詳しくは Chapter 2（schema.org の全体像と JSON-LD の基本）を参照してください。

Q. FAQ schema は今でも有効ですか？

2026年5月7日に Google は FAQ リッチリザルトを政府・医療など限定的なケースを除き完全停止し、6月にはリッチリザルトテストからも検出が外れ、Search Console API のサポートも 8月で終了予定です。ただし FAQ schema 自体は AI 検索エンジンの Q&A 抽出に依然として使われており、削除する必要はありません。詳しくは Chapter 5（FAQ / HowTo 実装）を参照してください。

※ 出典: Search Engine Land「Google to no longer support FAQ rich results」（取得 2026-05）

Q. リッチリザルトが表示されない場合の確認手順は？

(1) Rich Results Test で URL モードのチェック、(2) Schema Markup Validator で構文チェック、(3) Search Console「拡張」レポートでエラー・警告の確認、(4) ページに実表示されていない情報を schema に書いていないかの再点検、の順で潰します。詳しくは Chapter 8（テストツールと検証方法）を参照してください。

Q. AI 検索引用率を上げる構造化データはありますか？

特に効くのは Article の reviewedBy / wordCount / dateModified の 3 点、Organization の sameAs、FAQPage の Question / Answer、BreadcrumbList の階層情報です。AI 検索エンジンはエンティティ識別と鮮度判定に schema を活用しており、これらの欠落は引用機会を逃します。詳しくは Chapter 3（Article 実装）と Chapter 7（BreadcrumbList とサイト構造）を参照してください。

Chapter 10: Tufe Company の支援領域

ここまで自分で実装できるなら、本章は読み飛ばして大丈夫です。実装はわかったが手を動かす時間が無い・既存サイトに穴があるか棚卸ししたい、という場合の窓口だけ用意しておきます。

段階別の選択肢

「いきなりサービスを契約する」必要は無いように設計しています。まずは Rich Results Test で自社サイトを 1 ページ調べる、それでわからなければ AI Search Health Check で書面のレポートを取る、という順番で十分です。

実装すべき Schema 20 種チェックリスト

公開前と改修前に、この50項目を1つずつ潰してください。

サイト全体（全ページ共通テンプレに入れる）

• Organization（または LocalBusiness）— name / url / logo / sameAs
• WebSite — name / url / publisher
• SearchAction（サイト内検索があれば）— potentialAction
• BreadcrumbList — 各ページ階層を反映

コンテンツ系ページ

• Article（記事 / ガイド）— headline / image / datePublished / dateModified / author / publisher / wordCount / mainEntityOfPage
• BlogPosting（ブログ）— Article で代替可
• NewsArticle（報道機関のみ）— Google News 別要件あり
• VideoObject（動画記事）— name / thumbnailUrl / uploadDate / description
• FAQPage（AI 引用目的、SERP 表示は限定的）— mainEntity / Question / Answer
• DefinedTermSet（用語集）— 用語定義の構造化

EC 系ページ

• Product（商品ページ）— name / image / offers / brand / sku
• Offer / AggregateOffer — 価格・在庫
• AggregateRating / Review — ページ実表示必須
• MerchantReturnPolicy — 返品ポリシー
• OfferShippingDetails — 配送ポリシー
• CollectionPage + ItemList（カテゴリページ）

店舗・拠点系ページ

• LocalBusiness または業種特化型（Dentist / Restaurant / LegalService 等）— name / address / geo / openingHoursSpecification / priceRange / telephone
• Service — 提供サービスを個別構造化
• Event — セミナー / キャンペーンがあれば

補助

• Person（経営者・著者プロフィールページ）— name / jobTitle / worksFor / sameAs

コピペで使える JSON-LD テンプレ集

Organization（全ページ共通）

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "Example株式会社",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://x.com/example",
    "https://www.facebook.com/example"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "url": "https://example.com/contact",
    "availableLanguage": ["Japanese"]
  }
}

WebSite + SearchAction

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://example.com/#site",
  "url": "https://example.com",
  "name": "Example",
  "publisher": {"@id": "https://example.com/#org"},
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://example.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}

Article（pSEO / ガイド / ブログ共通）

Chapter 3 のテンプレを利用。

LocalBusiness（士業）

Chapter 4 のテンプレを利用。

FAQPage（AI 引用用途）

Chapter 5 のテンプレを利用。

Product（EC Merchant listing）

Chapter 6 のテンプレを利用。

BreadcrumbList

Chapter 7 のテンプレを利用。

公的・一次情報リソース集

実装中に必ず参照したい一次情報を集約しました。社内 Slack に貼って共有してください。

Google 公式

• Google Search Central Documentation（構造化データトップ）
• Search Gallery（リッチリザルト対応一覧）
• Article 構造化データ
• LocalBusiness 構造化データ
• Product 構造化データ
• General Structured Data Guidelines（ガイドライン全般）
• Rich Results Test
• Latest Google Search Documentation Updates

schema.org 公式

• schema.org トップ
• 全タイプ一覧
• Schema Markup Validator
• Release listing（バージョン履歴）

業界調査・実証データ

• Search Engine Land
• Search Engine Journal
• Backlinko（オリジナル調査）
• Ahrefs Blog
• Semrush Blog

まとめ — 5 つの要点

1. 2026 年 5 月、FAQ リッチリザルトは終了 — それでも FAQ schema は AI 検索引用目的で残す価値あり。
2. 構造化データの主役は SERP 装飾から AI 引用基盤へ — Article / LocalBusiness / Product / Breadcrumb / Organization を堅実に。
3. JSON-LD 一択 — Microdata・RDFa は新規実装不要。@context は必ず https://schema.org。
4. 「ページに実表示されていない情報を schema に書かない」が最大の禁則 — AggregateRating・Review・FAQ で特に厳禁。
5. Rich Results Test と Schema Markup Validator の二刀流 — 本番デプロイ前後で必ずかける。Search Console 拡張レポートで継続監視。

関連ガイド

シリーズの他のガイドも併読してください（各ガイドは Google Search Central / schema.org の同じ一次情報を共有しています）。

• LLMO/GEO 完全ガイド 2026年版
• SEO 完全ガイド 2026年版
• MEO 完全ガイド 2026年版
• AI自動化 完全ガイド 2026年版

※ 出典: Google Search Central（取得 2026-05）

関連用語集

• 構造化データ / Schema.org / JSON-LD / リッチリザルト
• Article schema / FAQPage / HowTo / BreadcrumbList
• LocalBusiness / Organization / Product / Review
• E-E-A-T / LLMO / AI Overview / GSC

まずは現状把握から

構造化データは「やる気になれば自社でやれる」領域です。Tufe Company に依頼する必要は必ずしもありません。以下は段階別の選択肢です。

1. 無料で試す — JSON-LD ジェネレーター（無料）で基本テンプレを即生成
2. 無料で診る — LLMO 無料診断で AI 検索適合度を 5 軸 100 点で可視化
3. 書面で診る — AI Search Health Check（¥14,800）で Schema 含む 5 軸の改善方針書を取得
4. 継続支援が必要なら — LLMO/GEO サービス（月次契約・要見積）
5. 個別相談 — 無料相談（45 分・オンライン・契約前提ではない）で実装ロードマップをすり合わせ