構造化データとは、ページに書かれている情報の意味を、機械が解釈できる形式で明示的に伝えるための記述です。AIO対策（AI検索最適化）の文脈では「AIに正しく理解させるための実装」として語られますが、実装すれば引用されるという関係が保証されているわけではありません。
本記事は、AIO対策の一環として構造化データの実装を検討しているWeb担当者・制作会社の方に向けて、構造化データの役割、2026年時点で優先度の高い種類、実装と検証の手順を整理しています。あわせて、FAQ・HowToのリッチリザルトが終了した事実と、その扱い方についても触れます。
- AIO対策の文脈で構造化データが果たす役割
- FAQ・HowToのリッチリザルトが終了した経緯と現在地
- 2026年時点で優先度が高い構造化データの種類
- JSON-LDでの実装と、検証・運用の手順
- 自社メディアで構造化データを実装して観測した数値
読み終えると、構造化データに何をどこまで期待すべきかを切り分けたうえで、自社サイトで着手する順序を判断できるようになります。
構造化データとは？AIO対策における役割
構造化データとは、ページ上の情報が「何を指すのか」を機械に伝えるための記述です。人間は文脈から「これは著者名だ」「これは公開日だ」と判断できますが、機械にとっては同じ文字列にすぎません。その対応関係を明示するのが構造化データの役割です。
- 構造化データの定義と仕組み
- AIO・LLMOの文脈で構造化データが語られる理由
- 構造化データが保証するものと、しないもの
本セクションでは、仕組みを押さえたうえで、期待できる範囲と期待しすぎてはいけない範囲を切り分けます。
構造化データの定義と仕組み
構造化データは、語彙（ボキャブラリー）と記述形式（シンタックス）の組み合わせで成り立ちます。語彙は「どの言葉でどの概念を表すか」の辞書にあたり、Web上ではschema.orgが事実上の共通語彙として使われています。
記述形式にはJSON-LD・Microdata・RDFaがありますが、Googleは公式ドキュメントでJSON-LDを推奨しています。HTMLの構造と切り離して記述できるため、既存のマークアップに影響を与えにくく、保守もしやすい形式です。
AIO・LLMOの文脈で構造化データが語られる理由
AIO対策やLLMO対策の文脈で構造化データが挙がるのは、AIが情報を解釈する際の曖昧さを減らせると考えられているためです。誰が書いたか、いつの情報か、どの組織のものかが明示されていれば、機械が意味を取り違える余地は小さくなります。AIO全体の考え方はAIOとは？AI Overviewの仕組みとSEOへの影響・対策を解説で整理しています。
ただし、生成AIが構造化データをどの程度参照しているかは、各社が仕様を公開していないため外部からは確認できません。「AIが構造化データを読んでいるから引用される」という説明は、現時点では検証されていない仮説を含んでいると捉えるのが妥当です。
構造化データが保証するものと、しないもの
構造化データの実装は、検索結果での特定の見え方やランキング上の優遇を保証するものではありません。Googleの公式ドキュメントでも、構造化データはコンテンツの理解を助けるための記述として位置づけられています。
期待できるのは「意味が正確に伝わる確度を上げること」であり、伝わった内容そのものが薄ければ結果は変わりません。構造化データは中身を良く見せる装置ではなく、中身を正しく伝える配管に近いと考えると、投資判断を誤りにくくなります。
FAQ・HowToのリッチリザルト終了が構造化データに与えた影響
構造化データを検討するうえで、FAQとHowToのリッチリザルトがすでに終了している点は押さえておく必要があります。これらは長く「まず実装すべき定番」として紹介されてきましたが、検索結果での表示という観点では前提が変わりました。
- FAQ・HowToのリッチリザルトが終了するまでの経緯
- マークアップ自体を削除すべきかどうか
- 「FAQを入れればAIOに効く」への私たちの見方
本セクションでは、公式に公表されている経緯を時系列で整理したうえで、実務でどう扱うかの判断を示します。
FAQ・HowToのリッチリザルトが終了するまでの経緯
Googleの公式ドキュメントおよび公式ブログで公表されている変更を時系列にすると、以下のようになります（2026年7月時点で確認）。
| 時期 | 変更内容 |
|---|---|
| 2023年9月14日 | HowToのリッチリザルトが、デスクトップ・モバイルの双方で表示されなくなり、関連ドキュメントが削除された |
| 2023年9月 | FAQのリッチリザルトの表示対象が、著名で信頼できる政府・医療系サイトに限定された |
| 2026年5月7日 | FAQのリッチリザルトが、Google検索結果で表示されなくなった |
| 2026年6月 | FAQの検索での見え方に関するレポート、およびリッチリザルトテストでのサポートが終了した |
| 2026年8月（予定） | Search Console APIでのFAQリッチリザルトのサポートが終了する予定 |
出典は、GoogleのFAQPage構造化データのドキュメントおよび公式ブログ「Changes to HowTo and FAQ rich results」です。仕様は変更されることがあるため、実装前に最新の記述をご確認ください。
マークアップ自体を削除すべきかどうか
すでに実装済みのFAQPageマークアップを、急いで削除する必要はないとされています。Googleは、使われていない構造化データが検索において問題を引き起こすことはない旨を示しており、削除するかどうかは任意という位置づけです。
そのため、実務上の判断は「新規に工数をかけて実装する優先度は下がった」「既存のものは無理に剥がさなくてよい」という整理になります。サイトリニューアルなどで棚卸しする機会があれば、そのタイミングで見直す程度で足りると考えられます。
「FAQを入れればAIOに効く」への私たちの見方
AIO対策の記事や提案書では、いまだにFAQPageやHowToが「優先して実装すべき構造化データ」として紹介されている場面を見かけます。リッチリザルトとしては終了した仕様であり、その前提で書かれた情報は更新されていない可能性があります。
もっとも、リッチリザルトの終了は「FAQという情報の形が無意味になった」ことを意味しません。想定される問いに対して簡潔に答える構成は、AIが答えを抽出しやすい形として有効に働く可能性があります。区別すべきなのは、検索結果での装飾表示（リッチリザルト）と、情報の構造そのものです。
私たちの立場は、FAQは「マークアップのため」ではなく「読者の問いに答えるため」に置くべき、というものです。マークアップの有無で成果が決まるという説明を受けた場合は、その根拠を確認することをおすすめします。問いの形で情報を整える考え方はLLMOの編集力とは？AIに引用される記事へ整える5つの視点で扱っています。
AIO対策で優先度の高い構造化データの種類
FAQとHowToが選択肢から外れた分、限られた工数をどこに割くかが論点になります。AIO対策の観点では、「誰が」「どの組織の」「いつの」情報かを伝える種類の優先度が相対的に高いと考えられます。
- サイト全体に関わる種類
- 記事・著者に関わる種類
- 業種によって検討する種類
本セクションでは、種類ごとの用途と優先度の考え方を整理します。
サイト全体に関わる種類
まず着手しやすいのは、サイト単位で一度実装すれば済む種類です。運営主体を明示する記述は、情報の出どころを機械に伝える土台になります。
| 種類 | 伝える内容 | 実装の目安 |
|---|---|---|
| Organization | 運営組織の名称・ロゴ・所在地・公式SNS等 | サイトに1回 |
| WebSite | サイト名、サイト内検索の情報 | サイトに1回 |
| BreadcrumbList | ページの階層構造 | 各ページ |
Organizationでは、sameAsプロパティで公式SNSや企業情報ページなど外部の参照先を示せます。同一の主体であることを機械に伝える手がかりになるため、社名が一般名詞に近い企業ほど整備する価値があると考えられます。
記事・著者に関わる種類
コラムやオウンドメディアを運営している場合、記事単位の種類が中心になります。E-E-A-Tの観点で問われる「誰が書いたのか」を明示できる点が要点です。
| 種類 | 伝える内容 | 実装の目安 |
|---|---|---|
| Article / BlogPosting | 見出し、公開日、更新日、著者、発行者 | 記事ページ |
| Person | 著者・監修者の氏名、肩書、経歴ページ | 著者情報を持つページ |
著者情報は、マークアップだけを整えても実体が伴わなければ意味が薄くなります。プロフィールページ、経歴、実績といった参照先を用意したうえで、それらを構造化データで結びつける順序が現実的です。
業種によって検討する種類
事業内容によっては、追加で検討する種類があります。いずれもリッチリザルトの仕様が変更される可能性があるため、実装前に公式ドキュメントで対象と要件を確認してください。
- LocalBusiness：実店舗を持つ事業者の所在地・営業時間
- Product・Offer：ECサイトの商品情報・価格・在庫
- JobPosting：採用情報
- Event：セミナーやイベントの開催情報
構造化データの実装と検証の手順
実装は、記述・検証・運用の3段階に分けて考えると進めやすくなります。特に検証を省くと、エラーを抱えたまま気づかない状態になりやすいため注意が必要です。
- JSON-LD形式で記述する
- ツールで検証する
- WordPressでの実装の選択肢
本セクションでは、3段階のそれぞれで押さえるべき点を解説します。
JSON-LD形式で記述する
JSON-LDは、HTMLの本文とは独立してscriptタグ内に記述します。本文の構造を変更せずに追加・修正できるため、運用時の負担が小さい形式です。
記述時の原則は、ページに表示されている内容と構造化データの内容を一致させることです。表示されていない情報をマークアップする行為は、Googleの構造化データに関するガイドラインで禁止されており、対策の対象になる可能性があります。
ツールで検証する
記述した構造化データは、公開前にリッチリザルトテストやschema.orgのバリデータで構文を確認します。公開後は、Search Consoleの拡張レポートでエラーや警告を継続的に確認する運用が有効です。
よくあるエラーは、JSONの構文ミス（カンマやコロンの欠落）、必須プロパティの欠落、日付形式の誤りです。いずれも検証ツールで検出できるため、実装フローに組み込んでおくと手戻りを防げます。
WordPressでの実装の選択肢
WordPressの場合、テーマやSEOプラグインが構造化データを自動出力していることがあります。この状態で手動のマークアップを追加すると、同じ種類が重複したり、内容が矛盾したりする場合があります。
追加実装の前に、現状で何が出力されているかをリッチリザルトテストで確認することをおすすめします。出力元を把握しないまま重ねると、原因の切り分けが難しくなります。
構造化データとAI引用の関係｜自社メディアでの実測値
構造化データの効果を、それ単体で切り出して測ることは困難です。私たちは自社で運営する読書メディア「ブッククランチ（BOOK CRUNCH）」で、構造化データの実装を含む複数の施策をあわせて実施し、その結果を計測しています。
- 実装内容と観測した数値
- 構造化データ「だけ」では説明できないこと
- 効果測定で見る指標
本セクションでは、条件を明示した実測値と、その解釈の限界をあわせて示します。
実装内容と観測した数値
ブッククランチ（2020年より運営）では、構造化データの実装、検索上位面の確保、執筆者情報の整備によるE-E-A-Tの強化、書評・作品解説などの一次情報コンテンツの拡充を並行して行いました。計測結果は以下の通りです。
| 指標 | 実測値 | 計測条件 |
|---|---|---|
| AI回答内での被引用シェア（Share of Authority） | 19.8% | Microsoft Clarity／2026年5月17日〜6月15日 |
| AI回答内での被引用回数 | 約1.4万回 | 同上（30日間） |
| 生成AI経由の流入 | 月間18セッション → 104セッション（約5.8倍） | GA4実測／2025年12月→2026年5月 |
流入元は、ChatGPTを中心にCopilot・Claude・Perplexityへと多様化しました。取り組みの詳細は自社メディア事例：BOOK CRUNCHにまとめています。
構造化データ「だけ」では説明できないこと
上記の数値は、構造化データの実装だけによってもたらされたものではありません。コンテンツの拡充や執筆者情報の整備を同時に進めているため、寄与度を分解することはできていません。
「構造化データを入れたら被引用が何倍になった」という形で語れるデータを、私たちは持っていません。同様の主張を見かけた場合は、他の施策を並行していないか、比較対象が妥当かを確認する価値があると考えられます。構造化データは複数ある要素の一つとして扱うのが実態に近い捉え方です。
効果測定で見る指標
構造化データの実装後に確認する指標は、実装の健全性と、成果の2階層に分けると整理しやすくなります。
- 実装の健全性：Search Consoleの拡張レポートでのエラー・警告の件数
- 成果：AI経由の流入セッション数（GA4）、AI回答内での被引用、指名検索の推移
成果側の指標は、着手前の水準を記録しておかないと変化を判断できません。実装と同じタイミングで計測の仕組みを用意しておくことをおすすめします。
構造化データでよくある失敗
構造化データの失敗は、実装直後ではなく運用のなかで顕在化する傾向があります。着手前に把握しておくと、設計段階で避けやすくなります。
- 表示内容と構造化データが一致していない
- プラグイン任せで重複・矛盾が起きている
- エラーを放置している
本セクションでは、3つの失敗パターンと対処の方向性を整理します。
表示内容と構造化データが一致していない
ページに表示していない情報をマークアップする、実態と異なる評価を記述するといった実装は、Googleのガイドライン違反にあたります。手動による対策の対象となる可能性があるため、避けるべき実装です。
意図的でなくても、ページを更新したのに構造化データを直し忘れて不一致が生じる例があります。本文と構造化データを同じ工程で更新する運用にしておくと、ずれが起きにくくなります。
プラグイン任せで重複・矛盾が起きている
テーマとSEOプラグインの双方が同じ種類を出力し、内容が食い違っているケースがあります。機械にとってはどちらが正しいか判断できず、意味を伝えるという目的が損なわれます。
プラグインを導入している場合は、出力内容を一度確認し、どこを情報源とするかを決めてから設定を整える手順が有効です。
エラーを放置している
構造化データのエラーは、サイトの見た目に影響しないため気づかれにくい傾向があります。Search Consoleに警告が出ていても、日常の運用では目に入りません。
月次のサイト点検の項目に、拡張レポートの確認を入れておくと、放置を防ぎやすくなります。
構造化データとAIO対策に関するよくある質問（FAQ）
構造化データとAIO対策に関して、よく寄せられる質問をまとめました。
構造化データを実装すればAIに引用されるようになりますか？
実装したから引用されるという関係は確認されていません。構造化データはページの意味を機械に伝えるための記述であり、伝わる内容そのものの価値を高めるものではないためです。生成AIが構造化データをどの程度参照しているかも、各社が仕様を公開していないため外部からは検証できません。引用されやすさを高めたい場合は、構造化データの実装と並行して、他にない情報を持つことに投資する必要があると考えられます。
FAQPageの構造化データは、もう実装しなくてよいですか？
リッチリザルトを目的とするなら、新規に工数をかける優先度は下がりました。FAQのリッチリザルトは2026年5月にGoogle検索結果での表示が終了しているためです。ただし、すでに実装済みのマークアップを急いで削除する必要はないとされています。また、想定される問いに簡潔に答えるという情報の形自体は、リッチリザルトとは別に有効に働く可能性があります。詳細はGoogleの公式ドキュメントで最新の記述をご確認ください。
構造化データはSEOの順位に影響しますか？
ランキング上の優遇を保証するものではありません。Googleの公式ドキュメントでも、構造化データはコンテンツの理解を助ける記述として位置づけられています。一方で、リッチリザルトが表示される種類では、検索結果での見え方が変わることでクリック率に影響する場合があります。順位そのものを動かす施策としてではなく、正確に伝えるための実装として捉えるのが妥当です。
どの種類から実装すればよいですか？
サイト単位で一度実装すれば済むOrganization・WebSite・BreadcrumbListから着手する方法が取り組みやすいです。運営主体とサイト構造を機械に伝える土台になり、業種を問わず該当するためです。オウンドメディアを運営している場合は、続けてArticleとPerson（著者情報）を整えると、誰が書いた情報かを示せるようになります。
まとめ：構造化データは「正しく伝える配管」として設計する
構造化データは、ページの情報の意味を機械に伝えるための記述です。AIO対策の文脈では効果が過大に語られる場面もありますが、実装が保証するのは「意味が正確に伝わる確度」であり、伝える中身そのものは別に用意する必要があります。本記事のポイントは以下の通りです。
- 構造化データは中身を良く見せる装置ではなく、正しく伝える配管に近い
- HowToは2023年9月、FAQは2026年5月にリッチリザルトの表示が終了している
- 既存のFAQPageマークアップを急いで削除する必要はない
- Organization・WebSite・BreadcrumbListから着手し、次にArticle・Personを整える
- 実装の健全性と成果は分けて計測し、着手前の水準を記録しておく
アマノートは、自社メディアで構造化データの実装を含むAI検索最適化を運用し、その結果を計測しながら支援に反映しています。自社サイトでどの種類から着手すべきか、現在の実装に重複や不一致がないかといった整理からご相談いただけます。