--- title: "構造化データは AI 検索に効果があるのか" canonical_url: "https://olein-design.com/blog/structured-data-ai-search" language: "ja" date_published: "2026-08-10T08:54:58+09:00" date_modified: "2026-08-11T17:54:23+09:00" content_type: "post" author: "久野晃司" description: "構造化データを追加すると、AI 検索で引用されやすくなるのでしょうか。Google の公式情報をもとに、直接的な効果を断定できない理由、導入する実務的な価値、WordPress で重複や不一致を確認する方法を整理します。" taxonomies: category: - "AI" - "ホームページ運営" --- # 構造化データは AI 検索に効果があるのか Google の AI Overviews や AI Mode など、生成 AI を使った検索機能が広がるなかで、「構造化データを追加すれば、AI に引用されやすくなるのでは」と考える方もいると思います。 先に結論をお伝えすると、**構造化データを追加すれば AI 検索での引用が増える、と確認できる公式情報はありません**。少なくとも Google は、AI Overviews や AI Mode に表示されるための特別な構造化データは必要ないと説明しています。 一方で、構造化データそのものに意味がないわけでもありません。記事、著者、事業者、公開日などの情報を決められた形式で表し、検索エンジンがページの内容や関係を理解する手がかりにできます。 僕は、構造化データを「AI に引用されるための裏技」ではなく、**人が確認できる情報を、検索エンジンにも正確に伝えるための仕組み**として考えるのがよいと思っています。 この記事では、構造化データと AI 検索の関係、事業サイトで検討しやすい種類、WordPress で確認したい重複や不一致について整理します。 ## 構造化データとは何か 構造化データは、ページに掲載している情報の種類や属性を、機械が処理しやすい決められた形式で表したデータです。 たとえば、ブログ記事には次のような情報があります。 - 記事のタイトル - 著者 - 公開日と更新日 - 記事を公開している事業者 - 記事の URL - 記事を表す画像 人がページを読めば、それぞれの意味を前後の文脈や見た目から判断できます。しかし、検索エンジンにとっては、どの文字列が著者名で、どの日付が更新日なのか、HTML だけでは曖昧な場合があります。 そこで、`Article`、`Person`、`Organization` などの語彙を使い、情報の意味や関係を表します。広く使われている語彙が [Schema.org](https://schema.org/) であり、Google が多くの場合に推奨している記述形式が `JSON-LD` です。 [Google の構造化データに関する案内](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)では、構造化データをページ内容の情報を提供し、ページの内容を分類するための標準化された形式として説明しています。Google は `JSON-LD`、Microdata、RDFa を扱えますが、実装や保守をしやすく、入力ミスも起こりにくい形式として、一般に `JSON-LD` を推奨しています。 ただし、構造化データは人が読む本文の代わりにはなりません。**本文にない情報を構造化データへ足すのではなく、ページ上で確認できる情報を機械可読化する**のが基本です。 ## 構造化データで AI 検索の引用は増えるのか 現時点では、構造化データの追加によって AI 検索での引用が増えるとは断定できません。 Google は [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) で、AI Overviews や AI Mode に補助リンクとして表示されるための追加要件や特別な最適化はないと説明しています。ページが Google 検索にインデックスされ、スニペットを表示できる状態であることが技術的な前提です。 同じ案内では、AI 機能のために新しい機械可読ファイルや特別なマークアップを用意する必要はなく、専用の Schema.org 構造化データも不要だと明記されています。 つまり、次のような説明は避けた方がよいでしょう。 - 構造化データを入れると AI に引用されやすくなる - `JSON-LD` を追加すれば、AI が内容を正しく理解する - FAQ の構造化データが AI の回答材料になる - 構造化データは AI 検索対策の必須項目である AI 検索がどのページを参照するかは、利用者の質問、ページの内容、クロールやインデックスの状態、検索サービス側の仕組みなど、複数の条件に左右されます。各サービスの選択方法がすべて公開されているわけでもなく、構造化データだけの影響を分けて測ることも簡単ではありません。 そのため、構造化データについては次の3つを分けて考える必要があります。 | 分類 | 現時点での整理 | | --- | --- | | 確認できていること | 検索エンジンがページ、記事、著者、組織などを理解する手がかりになる | | 条件によって期待できること | 対応する検索機能やリッチリザルトの表示対象になり得る | | **確認できていないこと** | AI 検索での引用件数や引用される確率が直接上がること | **「検索エンジンへ情報を伝えやすくすること」と「AI 検索に引用されること」は、同じではありません。** ## それでも構造化データを導入する価値 AI 検索への直接的な効果を確認できなくても、構造化データには通常の検索やサイト運用における実務的な価値があります。 ### ページと情報の関係を伝えられる 構造化データを使うと、このページが記事であること、その著者が誰であるか、どの事業者が公開しているかといった関係を明示できます。 Google も、構造化データをページ内容を理解するために使い、その情報をもとに検索結果へリッチリザルトを表示する場合があると説明しています。 ただし、[Google の構造化データに関する一般ガイドライン](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)では、正しく実装しても検索結果への表示は保証されないことが明記されています。構造化データに問題があった場合の手動対策も、通常のウェブ検索順位ではなく、リッチリザルトの表示資格に関係するものです。 構造化データは、検索順位を直接上げるための設定というより、検索エンジンによる情報理解と検索結果表示を補助する仕組みとして捉えた方が分かりやすいでしょう。 ### 情報の不一致を見つける確認項目になる 構造化データを設計すると、本文、著者プロフィール、サイト設定、公開日、更新日などの情報をどこから取得するか考える必要があります。 たとえば、画面には個人名が著者として表示されているのに、構造化データでは事業者名が `author` になっていれば、情報の不一致に気づけます。サイト上の屋号と `Organization` の `name` が異なる場合も同様です。 WordPress の投稿データ、ユーザー情報、サイト設定など、同じ情報源から画面表示と構造化データを生成できれば、修正箇所を減らしやすくなります。反対に、本文とは別に構造化データを毎回手入力すると、更新漏れや矛盾が起きやすくなります。 **保守性を左右するのは `JSON-LD` という形式そのものではなく、画面表示と同じ情報源から無理なく生成できる設計かどうかです。** ### アクセシビリティとは分けて考える 構造化データとセマンティックな HTML は、どちらも情報の意味を機械へ伝えるために使われますが、役割は同じではありません。 `JSON-LD` を追加しても、見出しの階層、ナビゲーション、フォームのラベル、画像の代替テキストなどが改善されるわけではありません。 [W3C のページ構造に関する案内](https://www.w3.org/WAI/tutorials/page-structure/)では、HTML と WAI-ARIA を使ってページの領域や見出し、内容の構造を示すことが、利用者の移動や理解を助けると説明しています。 アクセシビリティのためには、適切な見出し、`main`、`nav`、`article`、リスト、表などを内容に応じて使うことが先です。構造化データは、その代わりになるものではありません。 ## 事業サイトで検討しやすい構造化データ Schema.org には多くの型がありますが、使えるものをすべて追加する必要はありません。ページに実際に存在し、継続して正確に管理できる情報を選びます。 ### `Organization` または `LocalBusiness` `Organization` は、事業者名、URL、ロゴ、所在地、連絡先、公式プロフィールなど、組織に関する情報を表す型です。 [Google の `Organization` に関する案内](https://developers.google.com/search/docs/appearance/structured-data/organization)では、ホームページへ組織の構造化データを追加することで、組織の情報を理解し、同名の組織と区別する助けになると説明しています。ロゴなど、検索結果の表示に影響する可能性がある項目もあります。 実装時は、次のような点を確認します。 - サイトに表示している事業者名と `name` が一致しているか - `url` が正式なサイト URL になっているか - ロゴの URL を検索エンジンが取得できるか - `sameAs` が事業者本人の公式プロフィールを指しているか - 所在地や連絡先が、ページ上の情報と一致しているか 店舗や地域に根ざした事業では、より具体的な `LocalBusiness` の下位型が適している場合があります。一方、個人の活動を示すサイトでは `Person` が適切な場合もあります。事業形態だけで機械的に決めず、サイトが誰の、どのような情報を示しているかで判断します。 ### `Article` または `BlogPosting` ブログ記事では、`Article` またはその下位型である `BlogPosting` を利用できます。 [Google の記事構造化データに関する案内](https://developers.google.com/search/docs/appearance/structured-data/article)では、記事ページのタイトル、画像、日付、著者などを Google が理解する助けになると説明しています。 主に確認したい項目は次のとおりです。 - `headline` - `author` - `datePublished` - `dateModified` - `image` - `mainEntityOfPage` 構造化データに著者名を入れるだけでなく、ページ上にも著者名を表示し、可能であれば著者プロフィールへリンクします。公開日と更新日も、読者が見える日付と一致させます。 記事内容を見直していないのに、テーマの更新やキャッシュ処理だけで `dateModified` が変わる設計には注意が必要です。何を「記事の更新」とみなすかを決めておくと、表示と構造化データの両方を管理しやすくなります。 ### `BreadcrumbList` `BreadcrumbList` は、ページがサイト内のどの階層にあるかを表します。 パンくずリストを画面に表示している場合は、そのリンク先や順序と構造化データを一致させます。テーマと SEO プラグインの両方がパンくずリストを生成している場合は、見た目だけでなく構造化データの出力元も確認します。 ### `FAQPage` は AI 対策として追加しない `FAQPage` は、サイト運営者が用意した質問と回答を表す Schema.org の型です。しかし、FAQ の構造化データを追加したからといって、AI 検索の回答に使われるとは確認できません。 さらに Google は、2026年5月7日から FAQ リッチリザルトを Google 検索に表示しない方針へ変更し、同年6月には関連ドキュメントも削除しました。[Google Search Central のドキュメント更新履歴](https://developers.google.com/search/updates) Schema.org の型として `FAQPage` が存在することと、Google 検索で目に見える機能に使われることは別です。 質問と回答が読者にとって必要なら、まずページ上に分かりやすく掲載します。**検索結果や AI 回答への表示だけを目的に、`FAQPage` を追加する必要はありません。** ## WordPress で起こりやすい重複と不一致 WordPress では、テーマ、SEO プラグイン、構造化データ専用プラグイン、独自に追加したコードが、それぞれ構造化データを出力する可能性があります。 ここで注意したいのは、`