## この記事でわかること

- 構造化データ（schema.org / JSON-LD）とは何か、なぜ AI 検索や回答エンジンが情報を正確に取り込むのに役立つのか
- 実務で効く型（Organization・FAQPage・HowTo・Article・BreadcrumbList・DefinedTerm）と最小のコード例
- 「曖昧な文章より構造化」で引用精度が上がる考え方と、一次情報・出典明記との合わせ技
- 構造化データは取り込みを保証しないという前提と、公式仕様に従う重要性

## AI に引用される時代の「機械可読化」

ChatGPT や生成 AI の回答エンジンが、人の代わりに Web 上の情報を集めて要約・引用する場面が増えています。このとき問題になるのが、**人間向けに書かれた文章は、AI にとっては必ずしも意味が明確ではない**という点です。

たとえば「弊社は東京で2015年から事業を行っています」という一文は、人間には読めても、機械にとっては「どれが会社名で、どれが設立年で、どれが所在地か」が曖昧です。ここで役立つのが **構造化データ（structured data、ページの内容を機械が理解できる形式で補足する印）** です。

構造化データの代表的な記法が **JSON-LD（ジェイソン エルディー、JSON 形式で意味づけを書く方式）** で、語彙の標準として **schema.org（スキーマ ドット オルグ）** が広く使われています。Google も「ページの内容や、Web と世界全体に関する情報を理解するために、Web 上で見つけた構造化データを利用する」と説明しており、JSON-LD については「サイト所有者にとって最も実装・運用しやすい方式」だと推奨しています（[Google 検索セントラル: 構造化データの仕組み](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)）。

![曖昧な文章が構造化データを介してAIに正確に取り込まれる流れ](/blog/structured-data-for-ai-citation/citation-flow.svg)

AI 検索や回答エンジンが情報を引用するとき、文章をそのまま解釈するより、**意味づけ済みのデータを読むほうが誤りが起きにくい**のは直感的に理解できます。「会社名はこれ」「これは質問でこれが答え」と明示されていれば、AI は要素を取り違えずに取り込めます。

ポイントは、これが特別な新技術ではなく、SEO で長く使われてきた仕組みの延長だということです。検索エンジンに正しく読ませる基盤（構造化データ）は、そのまま AI への正確な伝達にも効きます。この考え方は[AI エージェント対応とは](/blog/agent-readiness-toha)で整理した「機械に正しく読ませる」基盤の一部にあたります。

ただし、構造化データだけで万全ではありません。引用精度を本当に上げたいなら、次の合わせ技が効果的です。

- **一次情報を書く**: 推測や伝聞ではなく、自社が確認した事実を載せる
- **出典を明記する**: 数値や主張の根拠 URL を添える
- **構造化で補強する**: その事実を schema.org の型で機械可読にする

文章で正確に書き、その正確さを構造化データで機械にも伝える。この二段構えが「曖昧な文章より構造化」の実体です。

## 実務で効く schema.org の型

すべての型を覚える必要はありません。中小企業のサイトで効果が出やすいのは次の型です。

![主要な構造化データの型 早見表](/blog/structured-data-for-ai-citation/schema-types.svg)

- **Organization**: 会社名・URL・ロゴ・公式 SNS などの組織情報
- **Article**: 記事のタイトル・著者・公開日
- **BreadcrumbList**: パンくず（サイト内の階層位置）
- **FAQPage**: 質問と回答のペア
- **HowTo**: 手順を順序立てて示す
- **DefinedTerm**: 用語とその定義（用語集向け）

### Organization の最小例

組織情報を機械可読にする最小の JSON-LD です。`name`・`url`・`logo`・`sameAs`（公式 SNS など同一性を示す URL）は、いずれも schema.org の正規プロパティです。

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://x.com/example",
    "https://www.linkedin.com/company/example"
  ]
}
```

### FAQPage の最小例

質問と回答を機械可読にする型です。`mainEntity` に `Question` を並べ、各質問に `acceptedAnswer`（`Answer.text`）を持たせます。

```json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化データは必須ですか",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "必須ではありませんが、機械可読化によって情報が正確に伝わりやすくなります。"
      }
    }
  ]
}
```

### 用語集には DefinedTerm が効く

`DefinedTerm`（定義された用語）は、用語とその定義を機械可読にする型です。複数の用語を `DefinedTermSet`（用語集）でまとめられます。本サイトの[用語集](/glossary)も、この `DefinedTermSet` の考え方で用語を整理しています。用語の定義を明示しておくと、AI が「この語は何を指すか」を取り違えにくくなります。

## 構造化データは「保証」ではない

ここは正確に押さえてください。**構造化データを付けても、リッチリザルト表示や AI への取り込みが保証されるわけではありません。**

Google も、推奨プロパティを多く満たすほど「強調表示で表示される可能性が高まる」とし、あくまで確実性ではなく確率の問題だと説明しています。さらに、ガイドラインに従わない構造化データは表示対象外になり得ると注意しています（[Google 検索セントラル: 構造化データの仕組み](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)）。

実務上、特に注意したい点が 2 つあります。

- **必須プロパティを満たす**: 各型には必須プロパティがあり、欠けると無効になります。「不正確な多数」より「正確で完全な少数」のほうがよい、というのが Google の指針です
- **Google の表示仕様は変わる**: たとえば FAQ のリッチリザルトは 2026 年 5 月以降、Google 検索で表示されなくなりました。リッチリザルト目当ての設計は前提が崩れやすく、**「機械可読化そのものの価値」を軸に据える**ほうが堅実です

つまり構造化データは、検索の見た目を飾るためというより、**AI を含む機械に情報を正確に伝えるための基盤**と捉えるのが、これからの実務に合った見方です。各型の必須・推奨プロパティは、必ず schema.org 公式と Google 検索セントラルの最新仕様で確認してください。

## よくある質問

### 構造化データを書けば必ず AI に引用されますか

いいえ。構造化データは情報を機械可読にして正確に伝わりやすくする手段で、引用や表示を保証するものではありません。一次情報を書き、出典を明記したうえで、それを構造化データで補強する合わせ技が現実的です。

### どの型から始めればよいですか

まず Organization で会社情報を、Article で記事情報を機械可読にするのが手堅い出発点です。FAQ や用語集を持つサイトは FAQPage・DefinedTerm を追加すると、Q&A や用語の意味が明確に伝わります。

### JSON-LD と他の記法は何が違いますか

意味づけには JSON-LD・Microdata・RDFa などがありますが、Google は JSON-LD を最も実装・運用しやすい方式として推奨しています。HTML 本文とは独立して `script` タグにまとめて書けるため、保守もしやすくなります。

## まとめと次の一歩

要点を整理します。

- 構造化データ（schema.org / JSON-LD）は、ページ内容を機械可読にし、AI 検索や回答エンジンに情報を正確に伝える基盤
- Organization・Article・FAQPage・HowTo・BreadcrumbList・DefinedTerm が実務で効きやすい
- 「曖昧な文章より構造化」は、一次情報・出典明記と組み合わせて初めて引用精度が上がる
- 構造化データは取り込みを保証しない。必須プロパティを満たし、公式仕様に従うことが前提

構造化データの土台は、サイトが機械に正しく読まれる状態になっていることです。robots.txt・sitemap・[llms.txt](/blog/llms-txt-toha)・[`/.well-known/api-catalog`](/blog/well-known-api-catalog-toha) なども含めた対応状況は、URL を入れるだけで点検できる[AI エージェント対応チェック](/tools/agent-ready-check)で無料で確認できます。