構造化データとは？SEOだけでなくAIにも伝わりやすくする基本を解説

「構造化データってよく聞くけど結局何なの」「FAQ のマークアップを入れると SEO に効くって本当」「AI にも伝わりやすくなるってどういう意味」。このあたりは、検索や LLMO の話を追っているとかなり出てきます。

でも実際には「コードを少し足す魔法」みたいに受け取られてしまって、本質が見えにくくなりがちです。とくに FAQ マークアップは、数年前の情報と 2026 年現在の挙動がまるで違うため、古い手法のまま量産すると逆効果になります。

この記事では、構造化データ とは何かを、SEO 用の小技としてではなく、検索エンジンやAIへページの意味を伝えやすくする土台 として整理します。LLMO の全体像から先に見たいなら、LLMOとは？SEOとの違い・やるべきこと・誤解を徹底解説 もつながりやすいです。

まず結論: 構造化データは「ページの意味を機械に説明する補助」

かなりざっくり言うと、構造化データは「このページは何のページで、ここにある情報は何を意味するのか」を検索エンジンへ伝えやすくする記述です。

たとえばページに記事タイトル・著者名・公開日・FAQ・パンくずがあっても、HTML を見ただけでは「どれがどの役割か」が曖昧なことがあります。そこで構造化データを使うと、これは Article、これは author、これは datePublished、これは FAQPage のように意味づけしやすくなります。

何に使われるのか

構造化データは、検索エンジン側で次のような用途に使われます。

Google Search Central の導入ガイドでも、構造化データは検索エンジンがページを理解しやすくするための標準化された形式として説明されています。つまり「星評価を出すためだけのもの」ではなく、本質は ページの意味を揃った形で渡すこと です。

schema.orgとは何か

構造化データの文脈で必ず出てくるのが schema.org です。これは Web 上の情報をどういう名前で表すかを決める共通語彙で、Article FAQPage BreadcrumbList Person Organization のような型(@type)やプロパティが定義されています。

初心者向けに言うと、schema.org は「構造化データを書くときの辞書」です。自由に好きなキー名を作るのではなく、既存の語彙に合わせることで検索エンジン側も理解しやすくなります。なお schema.org の語彙すべてに Google のリッチリザルトが対応しているわけではない点は重要で、後述するように「語彙としては有効だが、検索結果に何も出ない」型もあります。

JSON-LDとは何か

構造化データの書き方には JSON-LD・Microdata・RDFa がありますが、今かなり一般的なのは JSON-LD です。これは HTML 本文の見た目を直接いじるのではなく、application/ld+json タイプのスクリプトで意味情報を別に渡す方法で、Google も JSON-LD を推奨しています。

よくあるイメージはこんな感じです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データとは？",
  "author": {
    "@type": "Person",
    "name": "engineer.notes"
  }
}
</script>

このコード自体がユーザーに見えるわけではありません。でも検索エンジンは、ここから「これは記事ページなのだな」と読み取りやすくなります。重要なのは、この JSON を 手書きで毎回コピペせず、サーバー側で本文データから生成することです。後半でその実装を示します。

SEOではなぜ話題になるのか、そして「FAQで目立つ」が終わった話

構造化データが SEO の文脈で話題になるのは、検索結果の見え方に関わることがあるからです。ただし、ここでよくある二つの誤解があります。

誤解1: 構造化データを入れれば順位が上がる

これは雑に言いすぎです。Google は構造化データを検索の理解を助けるものとして説明していて、「入れれば必ず順位上昇」とは言っていません。構造化データはあくまでリッチリザルトの表示資格に関わるもので、Web 検索の順位そのものを直接押し上げるシグナルではありません。

誤解2: FAQマークアップを入れれば目立てる

これはもう完全に過去の常識です。時系列を押さえておくと判断を誤りません。

つまり 2026 年現在、FAQPage マークアップは検索結果の見た目には一切寄与しません。FAQ コンテンツ自体は本文として価値がありますが、「リッチリザGルトのためにFAQを量産する」動機は完全に消えました。次章で、これを知らずに量産した場合に何が起きるかを失敗例として詳しく扱います。

失敗例: FAQマークアップ量産で手動対策(ペナルティ)を受ける

古い情報のまま「FAQ で目立とう」とすると、効果がないどころか手動対策(Manual Action)の対象になり得ます。Search Console の用語では Spammy structured markup(スパム的な構造化マークアップ) と呼ばれます。現象から回避までを分解します。

AIにも伝わりやすいとはどういう意味か

「AI に伝わりやすくなる」と言うと、構造化データを入れるだけで AI が必ず引用してくれるように聞こえます。でも、そこまで単純ではありません。言えるのは次のレベルです。

• 検索エンジンや周辺システムがページの意味を揃って理解しやすくなる
• 記事・著者・組織・FAQ などの関係が機械的に解釈しやすくなる
• 要約・引用・参照の前提となる情報整理としては相性がよい

つまり AI 時代においても構造化データは「意味の整列」として価値があります。ただし 構造化データだけで AI 可視性が決まるわけではなく、本文の明快さ・根拠・更新性・内部リンクも同じくらい重要 です。FAQ リッチリザルトが廃止された今、FAQ コンテンツの価値は「検索結果の見た目」ではなく「本文として明快な問いと答えを提供すること」に完全に移った、と捉えるのが正確です。

サーバー側からArticle JSON-LDを出す実コード(Laravel/PHP)

JSON-LD は手書きでコピペすると本文とすぐにずれます。記事の DB レコードから サーバー側で生成 するのが実務の基本です。ここでは Laravel/PHP を例に、記事モデルから Article の JSON-LD を組み立てるヘルパを示します。

まず、JSON-LD を組み立てる純粋関数を用意します。日付は ISO 8601(c フォーマット)で出すのがポイントです。

// app/Support/ArticleJsonLd.php
function build_article_json_ld(array $a): string
{
    $data = [
        '@context'      => 'https://schema.org',
        '@type'         => 'Article',
        'headline'      => mb_substr($a['title'], 0, 110),
        'datePublished' => $a['published_at']->format('c'), // 2026-06-13T09:00:00+09:00
        'dateModified'  => $a['updated_at']->format('c'),
        'author'        => [
            '@type' => 'Person',
            'name'  => $a['author_name'],          // 必須級。空にしない
            'url'   => $a['author_url'] ?? null,
        ],
        'publisher'     => [
            '@type' => 'Organization',
            'name'  => 'engineer.notes',
            'logo'  => [
                '@type' => 'ImageObject',
                'url'   => 'https://example.com/logo.png',
            ],
        ],
        'image'         => $a['og_image'] ? [$a['og_image']] : [],
        'mainEntityOfPage' => [
            '@type' => 'WebPage',
            '@id'   => $a['canonical_url'],
        ],
    ];

    // null や空配列を落として、余計なフィールドを出さない
    $data = array_filter($data, fn($v) => $v !== null && $v !== []);

    return json_encode(
        $data,
        JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE
    );
}

Blade テンプレート側では、この文字列をそのままスクリプトタグに流し込みます。{!! !!} でエスケープを抑止しますが、入力は DB の自前データに限るのが安全です。

{{-- resources/views/articles/show.blade.php の <head> 内 --}}
<script type="application/ld+json">
{!! build_article_json_ld([
    'title'        => $article->title,
    'published_at' => $article->published_at,
    'updated_at'   => $article->updated_at,
    'author_name'  => $article->author?->name ?? 'engineer.notes',
    'author_url'   => $article->author?->profile_url,
    'og_image'     => $article->og_image_url,
    'canonical_url'=> route('articles.show', $article->slug),
]) !!}
</script>

BreadcrumbList も同様に、パンくずの配列から position 付きで生成します。Article と BreadcrumbList は別々のスクリプトタグに分けても、@graph でまとめても構いません。

Rich Results Testでエラーが出た時の修正例

JSON-LD は見た目に出ないので、壊れていても気づきにくいのが厄介です。実装したら リッチリザルト テスト(search.google.com/test/rich-results)に URL かコードを入れて検証します。よく出るエラー・警告と直し方を実例で挙げます。

「Missing field 'name'(in 'author')」は典型的なつまずきです。原因の切り分け手順は次のとおりです。

なお、エラー(Error) はリッチリザルト資格を失う必須フィールドの問題、警告(Warning) は推奨フィールドの欠落で資格自体は維持されます。まずエラーをゼロにし、警告は余力があれば潰す、という優先順位で十分です。

技術ブログで特に入れやすいもの

技術ブログなら、まずは次のあたりが現実的です。リッチリザルトとしての見え方の有無も併記します。

実務でどう進めるとよいか

かなり現実的には、次の順で十分です。

ここで大事なのは、「マークアップの正しさ」と「本文の整合性」を一致させることです。FAQ と言いながら本文に質問と回答がない、著者情報が実態とずれている、公開日が本文と合っていない、という状態は手動対策の入り口になります。

よくある失敗(まとめ)

構造化データに関するよくある質問

Q. 構造化データを入れたら検索順位は上がりますか？

A. 直接の順位ブーストはありません。構造化データはリッチリザルトの表示資格に関わるもので、Web 検索の順位を押し上げるシグナルではない、と Google は明言しています。リッチリザルトでクリック率が上がる間接効果はありますが、まず本文品質が前提です。

Q. FAQ マークアップは今でも入れる意味がありますか？

A. 検索結果の見た目という意味では、ほぼありません。Google は 2023 年 8 月に FAQ リッチリザルトを政府・医療系に限定し、2026 年 5 月にすべてのサイトで完全廃止しました。入れるなら「本文に実在する Q&A の意味づけ」目的に限り、表示目的の量産は避けてください。

Q. JSON-LD と Microdata はどちらを使うべきですか？

A. JSON-LD が標準です。Google も推奨しており、HTML 本文と分離して書けるので、サーバー側でデータから生成しやすく保守も楽です。Microdata は本文タグに属性を埋め込む古い形式で、新規実装ではほぼ使われません。

Q. すべてのページに構造化データを入れるべきですか？

A. すべてである必要はありません。記事詳細・商品ページ・イベントページなど、リッチリザルトの対象になるページから優先します。技術ブログなら Article と BreadcrumbList を全記事に、Organization をサイト共通で、が現実的な範囲です。

Q. 構造化データのテスト方法は？

A. Google のリッチリザルト テストで「リッチリザルト資格があるか」を、Schema Markup Validator で「schema.org として構文が正しいか」を確認します。コードを書いたらまずこの二つで即時チェックし、本番反映後は Search Console の拡張レポートで数日かけて追います。

Q. 「Missing field 'name'(in 'author')」と出ました。どう直しますか？

A. author オブジェクトはあるが name が空です。テンプレートで著者名が null のまま出ているのが典型。author.name に必ず文字列を入れ、個人著者でなければ Organization 型で組織名を入れます。空の author を出すくらいなら author ごと省く方が安全です。修正後にリッチリザルト テストで再検証してください。

Q. Search Console に「手動による対策(Spammy structured markup)」が出ました。

A. 本文に存在しない内容をマークアップした、型と実態がずれている、などが原因です。該当ページの構造化データは無視され、リッチリザルト資格を失います(Web 検索からは消えません)。本文と一致しない構造化データを全該当ページで是正し、手動対策レポートから「審査をリクエスト」を送ります。表面的な修正では再審査が通りません。

Q. AI Overviews や AI 検索の引用対策に有効ですか？

A. 内容を機械が理解・要約する手がかりにはなり得ますが、構造化データだけで引用されるわけではありません。明快な本文・根拠・更新性・内部リンクが土台で、その上で Article や Organization の整理が補助として効く、という位置づけです。

まとめ

構造化データ は、SEO の小技というより ページの意味を検索エンジンやAIへ伝えやすくする土台 です。schema.org という共通語彙を使い、JSON-LD で記事・著者・パンくずなどの意味を整理して渡します。実装は手書きせず、記事データからサーバー側で生成し、リッチリザルト テストでエラーゼロを確認するのが基本です。

そして 2026 年の重要な前提として、FAQ リッチリザルトはすでに全廃されています。FAQ を表示目的で量産する手法は効果がないだけでなく、本文とずれれば手動対策の対象になります。入れれば自動で順位や AI 引用が上がるわけではなく、本文の品質・見出し構造・根拠・更新性が前提にあって、その上で構造化データが「理解の補助」として効く、と見るのが実務では自然です。

参考リンク

• Google Search Central: Introduction to structured data markup in Google Search
• Google Search Central: Article (Article, NewsArticle, BlogPosting) structured data
• Google Search Central: Structured data general guidelines (spam policies)
• Google Search Central: Rich Results Test
• Schema.org: Schema.org
• Search Console ヘルプ: 手動による対策レポート