構造化データとは？JSON-LDの書き方とAI検索との関係

この記事の要点：

構造化データは、Googleの説明では、ページに関する情報をさまざまなサイトで活用できるように標準化したデータ形式です。形式はJSON-LDが推奨です。
リッチリザルトの対象になりえますが、表示は約束されず、順位を直接上げるものでもありません。FAQとHowToのリッチリザルトは表示を終えています。
AIによる概要やAIモードのための特別なマークアップは不要です。会社や記事の主題を取り違えずに伝える手段として整えます。
迷ったら、ページの主な内容を表す型を1つと、サイト共通のOrganization・BreadcrumbListから始めます。
公開前にリッチリザルトテストと検証ツールで確かめ、公開後はSearch Consoleでエラーを見ます。

構造化データとは

構造化データとは、ページに関する情報をさまざまなサイトで活用できるように標準化したデータ形式です（Google 検索セントラル：構造化データの仕組みについて）。Googleは、構造化データでページの意図を伝えるとページをより正確に理解できるとし、形式は多くの場合JSON-LDを推奨しています。

具体的には、記事の題名・公開日・運営会社・商品の価格などを、schema.orgの語彙でHTMLの中に書きます。本文の「株式会社〇〇」が運営者か取引先か題材かを明示できます。

schema.orgとは

schema.orgとは、構造化データで使う型（Organization、Article、Productなど）とプロパティ（name、priceなど）を定めた共通の語彙です。2011年にGoogle・Microsoft・Yahoo・Yandexが共同で始めました（schema.org：About）。Googleのリッチリザルトに使われるのはその一部です。

3つの書き方（形式）

構造化データの書き方（形式）はJSON-LD・Microdata・RDFaの3つで、GoogleはJSON-LDを推奨しています。

形式	書く場所	特徴
JSON-LD	`<script type="application/ld+json">` の中	本文のHTMLと切り離して書ける。Googleが推奨する形式
Microdata	本文のHTMLタグの属性（itemscope、itemprop など）	見えている文字に直接印を付ける
RDFa	本文のHTMLタグの属性（vocab、property など）	Microdataと同じく属性で書く

構造化データと非構造化データの違い

構造化データと非構造化データの違いは、項目と値の決まった形で整理されているかどうかです。構造化データは「題名＝〇〇、公開日＝〇〇」のように項目ごとに値が入り、非構造化データ（文章・画像・音声・動画など）は決まった形を持ちません。

用語	意味	例
構造化データ（SEO）	ページの内容を、schema.orgの型とプロパティで検索エンジン向けに書いた記述	記事の題名・公開日・著者をJSON-LDで書いたもの
構造化データ（データ分析）	表の行と列のように、決まった項目で整理されたデータ	顧客の一覧表、売上の表
半構造化データ	項目名は付いているが、表ほど形が決まっていないデータ	JSONやXMLのファイル
非構造化データ	決まった形を持たないデータ	ウェブページの本文、画像、音声、動画

SEOでは、人が読む本文が非構造化データにあたります。検索エンジンは本文から内容を推測しますが、構造化データを添えると題名・日付・運営者などを明示できます。データ分析の意味と区別するには「構造化データマークアップ」「schema.org」と合わせて調べます。

構造化データでできること・できないこと

構造化データでできるのは、リッチリザルトの対象になることと、ページの内容を検索エンジンに正確に伝えることで、順位を直接上げるものではありません。

リッチリザルトの対象になる：商品の価格、レビューの星、イベントの日時、パンくずリストなどが検索結果に表示される場合があります。
内容を正確に伝える：ページの種類、運営する組織、記事の主題などを、推測ではなく宣言として伝えられます。

構造化データを入れても、リッチリザルトを表示するかどうかはGoogleが判断します。

終わったリッチリザルト：FAQとHowTo

よくある質問（FAQPage）のリッチリザルトは、2023年8月に、よく知られた信頼性の高い政府・保健医療系のサイトに限られ、2026年5月7日以降はすべてのサイトで表示されなくなりました。HowTo（手順）のリッチリザルトも2023年に表示を終えています。FAQPageのマークアップは残しても問題ありません。

AI検索と構造化データの関係

構造化データは、AIによる概要やAIモードに表示されるための条件ではなく、入れればAIに引用されるものでもありません。よく見る主張を、公式の説明に照らすと次のとおりです。

よく見る主張	公式の説明から言えること
AIによる概要に出るには専用のマークアップが必要	Googleは、AIによる概要やAIモードに表示されるために、特別なマークアップや追加の要件は必要ないと説明しています（AI 機能とウェブサイト）
構造化データを入れればAIに引用される	引用されるかどうかは検索エンジン側が決めます。構造化データは引用を約束するものではありません
構造化データはAI検索には関係ない	ページの内容をプログラムに正確に伝える手段であることは、通常の検索でもAI検索でも変わりません

Google以外のAIサービスでの使われ方は、公開されている説明が限られます。役立つ可能性があるのは、エンティティ（会社・人物・製品など、ほかと区別できる事柄）を取り違えずに伝える場面です。例：同名の会社がある場合、Organizationの sameAs で公式SNSやWikidataを結ぶと、どの会社かを特定する手がかりが増えます。

JSON-LDの書き方

JSON-LDは、<script type="application/ld+json"> の中に、@context（使う語彙。schema.orgなら "https://schema.org"）、@type（型）、その型のプロパティ（name、urlなど）を書く形式です。値に別の型を入れ子にでき、HTMLの head 内でも body 内でも構いません。以下のコードはすべて説明用の例です。

Organization：運営組織と sameAs

Organizationは、トップページや会社概要のページに置き、運営組織を宣言する型です。sameAsには、公式SNSやWikidataのページなど、その組織を指すことが確かなURLだけを書きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "株式会社サンプル工務店",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png",
  "sameAs": ["https://www.wikidata.org/wiki/Q（確認したID）",
    "https://www.youtube.com/@（公式チャンネル）"]
}
</script>

@id は、ほかの構造化データから同じ組織を参照するための識別子です。記事の author や publisher から同じ @id で参照すれば、組織の情報を何度も書かずに済みます。1ページの複数の型は、scriptを分けても "@graph": [ ... ] にまとめても構いません。

BlogPosting：記事と about・mentions・mainEntity

記事ページには、ArticleまたはBlogPosting（ニュースならNewsArticle）を使い、Googleが推奨する headline、image、datePublished、dateModified、author などを書きます。記事の主題は、schema.orgの about（主な題材）、mentions（触れているが主題ではない事柄）、mainEntity（中心として説明している事柄）で示せます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "キッチンリフォームの費用と工期の目安",
  "datePublished": "2026-09-01T09:00:00+09:00",
  "dateModified": "2026-10-05T10:30:00+09:00",
  "author": { "@id": "https://example.com/#organization" },
  "publisher": { "@id": "https://example.com/#organization" },
  "mainEntity": { "@type": "Thing", "name": "キッチンリフォーム" },
  "about": [{ "@type": "Thing", "name": "リフォーム",
    "sameAs": "https://www.wikidata.org/wiki/Q（確認したID）" }],
  "mentions": [{ "@type": "Thing", "name": "システムキッチン" }]
}
</script>

about・mentions・mainEntityはリッチリザルトの条件ではなく、主題を宣言するための記述です。

BreadcrumbList：パンくずリスト

BreadcrumbListは、ページに表示しているパンくずリストと同じ順番で書きます。positionは1から始め、最後の項目（今のページ）は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": "コラム", "item": "https://example.com/column/" },
    { "@type": "ListItem", "position": 3, "name": "キッチンリフォームの費用と工期の目安" }
  ]
}
</script>

LocalBusiness：店舗・地域の事業

店舗や地域で営業する事業のページには、LocalBusiness（または飲食店のRestaurantなど、より具体的な型）を使います。Googleの説明では、nameとaddressが必須で、telephone、openingHoursSpecification、geo、urlなどが推奨です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "サンプル工務店 本店",
  "address": { "@type": "PostalAddress", "postalCode": "000-0000",
    "addressRegion": "〇〇県", "addressLocality": "〇〇市",
    "streetAddress": "〇〇町1-2-3" },
  "telephone": "+81-00-0000-0000",
  "openingHoursSpecification": [{ "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "09:00", "closes": "18:00" }]
}
</script>

住所や営業時間は、ページの表示とGoogleビジネスプロフィールに合わせます。

サイトの種類別：どの構造化データから入れるか

どの構造化データから入れるかはサイトの種類で決まり、会社のサイトならOrganization、ブログならBlogPosting、通販ならProduct、店舗ならLocalBusinessが出発点です。求人のページなら JobPosting で、必須プロパティと募集が終わったときの扱いは「採用サイトのSEO」で説明しています。

サイトの種類	まず入れる	次に検討する	補足
会社・サービスのサイト	Organization（トップ）、BreadcrumbList	WebSite（サイト名）	社名やロゴの表記を外部のプロフィールとそろえる
ブログ・オウンドメディア	BlogPosting または Article、BreadcrumbList	about・mentions、著者のPersonまたはOrganization	書き手や運営者が分かるページと合わせる
ネット通販	Product（Offerで価格・在庫）、BreadcrumbList	Review・AggregateRating（実際のレビューがある場合）	価格や在庫が変わったら構造化データも同時に更新する
店舗・地域のサービス	LocalBusiness（住所・営業時間）	Organization	Googleビジネスプロフィールの情報と食い違わないようにする
ニュース	NewsArticle	BreadcrumbList	datePublished と dateModified を正しく分ける

通販の商品ページ向けの詳しい書き方は「ECサイトのSEO」で説明しています。

実装と確認の手順

構造化データは、今の出力を調べてから出す場所を1つに決め、公開前に検証ツールで、公開後にSearch Consoleで確かめます。

実装の手順（WordPressの例）

今の出力を調べる：ソースで application/ld+json を検索します。テーマやSEOプラグインが、すでに出力していることがよくあります。
どこで出すかを1つに決める：プラグインで足りるものはプラグインに任せ、足りない部分（about・mentions など）だけを追加します。同じ型を2か所から出さないようにします。
テンプレートに組み込む：手で貼らず、タイトルや日付が記事のデータから入るようにします。
公開前に検証する：リッチリザルトテストとスキーママークアップ検証ツールで確認します。
公開後に監視する：Search Consoleのリッチリザルトのレポートでエラーの件数を、「URL検査」で個別のページの構造化データを確かめます。

リッチリザルトテストとスキーママークアップ検証ツールの違い

Googleのリッチリザルトの対象かを確かめるならリッチリザルトテスト（Google）、schema.orgの語彙として正しいかを確かめるならスキーママークアップ検証ツール（schema.org）を使い、公開前は両方で確かめます。

観点	リッチリザルトテスト	スキーママークアップ検証ツール
確認できること	リッチリザルトの対象になる型か、必須・推奨のプロパティが足りているか	schema.orgの語彙として正しいか（about・mentions など、リッチリザルトに関係しない記述も含む）
向いている場面	商品・パンくずリスト・記事など、検索結果での表示を確認したいとき	エンティティの宣言など、Googleの機能に限らない記述を確かめたいとき

リッチリザルトテストで「検出されたアイテムはありません」と出ても、対象でない型だけを書いている場合があり、壊れているとは限りません。

よくあるエラーと直し方

構造化データのよくあるエラーは、JSONの書き方の誤り、必須プロパティの不足、日付の誤り、レビューの使い方の誤りです。テーマとプラグインによる二重の出力は、どちらか一方を止めて直します。

起きる状況	原因	直し方
構造化データがまったく検出されない	末尾の余計なカンマ、全角の引用符、閉じ括弧の不足など、JSONの書き方の誤り	検証ツールでエラーの行を直す。手で貼らずテンプレートで出力する
「必須プロパティがありません」と出る	例：Productに offers・review・aggregateRating のどれもない	ページにある情報で補う。無ければその型を使わない
日付が正しく読まれない、更新のたびに公開日が変わる	「2026/10/9」のような形式、datePublished の上書き	ISO 8601形式（例：2026-10-09T09:00:00+09:00）で書き、更新日は dateModified に書く
レビューの星が表示されない	自社について自社で集めたレビューを、Organization・LocalBusinessに付けている	Googleはこの種のレビューを星の表示の対象にしていない。商品ページの実際のレビューなどで使う

当サイト（seoagent.jp）での実例：記事ごとに主題を宣言した

当サイト（seoagent.jp）では、記事の主題を検索エンジンに推測させる状態だったため、記事ごとに主題・テーマ・言及する事柄を決め、構造化データで宣言しました。対象は93語で、WikidataのIDは、実際に確認できた語だけに付けています。記事には mainEntity・about・mentions を、記事をまとめたトピックページには CollectionPage を出力しています。たとえばこの記事では、主題を「構造化データ」、テーマを「schema.org」「JSON-LD」としています。

この宣言で検索での表示やAIの回答が変わることは約束されていません。

よくある質問

WordPressのプラグインに任せていれば、自分で書く必要はありませんか？

多くの場合、基本の型はテーマやSEOプラグインが出力します。ただし、型が空だったりテーマと二重に出力されていたりすることがあるため、一度はソースで中身を確かめ、足りない部分だけを追加します。WordPress で出力元を突き止めて 1 つにまとめる手順は「WordPressの構造化データ」で説明しています。

Googleタグマネージャーで構造化データを入れてもよいですか？

入れられます。Googleは、タグマネージャーやJavaScriptでJSON-LDを追加する方法を案内しています。値はページの表示と食い違わないようにし、入れた後はリッチリザルトテストで確かめます。

構造化データを入れてから、検索に反映されるまでどのくらいかかりますか？

Googleが再びクロールして処理した後に反映されるため、期間は決まっていません。Search ConsoleのURL検査で構造化データが検出されているかを確かめ、必要ならインデックス登録をリクエストします。反映されてもリッチリザルトの表示が約束されるわけではない点は同じです。

SEOAGENTでできること

SEOAGENTでは、WordPressへの記事の公開・予約公開と、公開後の検索データの確認を進められます。構造化データの出力は、WordPress側のテーマやSEOプラグインの設定で行います。

サイト全体の技術的な点検項目はSEO内部対策とは、ほかの関連記事は「テクニカルSEOの記事一覧」にまとめています。

構造化データとは？JSON-LDの書き方・確認方法とAI検索との関係

構造化データとは

schema.orgとは

3つの書き方（形式）

構造化データと非構造化データの違い

構造化データでできること・できないこと

終わったリッチリザルト：FAQとHowTo

AI検索と構造化データの関係

JSON-LDの書き方

Organization：運営組織と sameAs

BlogPosting：記事と about・mentions・mainEntity

BreadcrumbList：パンくずリスト

LocalBusiness：店舗・地域の事業

サイトの種類別：どの構造化データから入れるか

実装と確認の手順

実装の手順（WordPressの例）

リッチリザルトテストとスキーママークアップ検証ツールの違い

よくあるエラーと直し方

当サイト（seoagent.jp）での実例：記事ごとに主題を宣言した

よくある質問

SEOAGENTでできること

参考情報

関連する記事

検索結果のサイト名とファビコン：Googleに正しく表示させる設定と確かめ方

WordPressの表示速度：遅い原因の切り分けと、当サイトの計測で効いた改善

クロールバジェットとは：Googleの説明と、気にすべきサイト・しなくてよいサイト

AIでSEO対策を、もっと続けやすく。

構造化データとは

schema.orgとは

3つの書き方（形式）

構造化データと非構造化データの違い

構造化データでできること・できないこと

終わったリッチリザルト：FAQとHowTo

AI検索と構造化データの関係

JSON-LDの書き方

Organization：運営組織と sameAs

BlogPosting：記事と about・mentions・mainEntity

BreadcrumbList：パンくずリスト

LocalBusiness：店舗・地域の事業

サイトの種類別：どの構造化データから入れるか

実装と確認の手順

実装の手順（WordPressの例）

リッチリザルトテストとスキーマ マークアップ検証ツールの違い

よくあるエラーと直し方

当サイト（seoagent.jp）での実例：記事ごとに主題を宣言した

よくある質問

SEOAGENTでできること

参考情報

関連する記事

検索結果のサイト名とファビコン：Googleに正しく表示させる設定と確かめ方

WordPressの表示速度：遅い原因の切り分けと、当サイトの計測で効いた改善

クロールバジェットとは：Googleの説明と、気にすべきサイト・しなくてよいサイト

AIでSEO対策を、もっと続けやすく。

リッチリザルトテストとスキーママークアップ検証ツールの違い