構造化データとは？AIO対策で押さえておきたい仕組みと実装方法を解説

「構造化データを入れると、GoogleのAI Overviewに表示されやすくなる」という話を目にしたことはないでしょうか。AI Overviewへの対策、いわゆるAIO対策の一つとして、構造化データが挙げられる場面は増えています。

ただ、実際にどこまで効果が期待できるのかは、Google公式の情報や調査結果を確認したうえで、冷静に判断したいところです。

この記事では、構造化データの基本的な仕組みから、AIO対策で押さえておきたい理由、実装の手順、よくある実装エラーまでを、一次情報をもとに解説します。

構造化データとは

まずは構造化データがどのようなものなのか、基本から整理していきます。

Schema.orgの基本的な仕組み

構造化データとは、Webページの内容が何を表しているのかを、検索エンジンなどが理解しやすい形式で記述したものです。たとえば記事のページであれば、「これは記事であり、見出しはこれ、公開日はこれ、著者はこの人」といった情報を、人が読む本文とは別に、機械が読み取れる形で添えておくイメージです。

この記述に使う語彙（スキーマ）を作成・維持・推進しているのが「Schema.org」です。Schema.orgは、Google、Microsoft、Yahoo、Yandexの4社が設立し、現在は幅広いWebコミュニティの参加を得て運営されている共同の取り組みです。

（参照：Schema.org「About Schema.org」）

JSON-LD形式が推奨される理由

構造化データを記述する形式には、JSON-LD、microdata、RDFaの3種類があります。

Googleのドキュメントでは、マークアップが有効で、適切に実装されていれば、いずれの形式も有効とされています。そのうえで、Googleは一般的にJSON-LDの使用を推奨しています。ウェブサイトの所有者が実装と管理を最も容易に行える、つまりユーザーエラーが起きにくい形式であることが理由とされています。

JSON-LDは、HTMLの<script>タグの中に記述する方式で、ページの<head>や<body>に配置します。

ユーザーに見えるテキストの中にマークアップを挟まないため、入れ子になったデータも表現しやすく、CMSのJavaScriptコードなどでページに動的に挿入されたJSON-LDデータも、Googleは読み取れるとされています。

SEOとAIO対策での役割の違い

従来のSEOにおける構造化データの主な役割は、Googleにページの内容を正しく伝え、条件を満たす場合に、検索結果でリッチリザルト（評価の星印やパンくずなど、通常より情報量の多い表示）として表示されるようにすることでした。

一方、AIO対策における構造化データは、役割がやや異なります。

Googleは、AI Overviewsなどのためだけに必要となる特別な構造化データを示していません。そのため、AIO対策での構造化データは、AIに引用されるための決め手というよりも、ページの内容を正しく機械に伝える基盤として位置づけるのが現実的です。

AIO対策で構造化データを押さえておきたい理由

構造化データは「AIO対策に欠かせない」と言い切れるものではありません。それでもなぜ押さえておきたいのか、公式情報と調査結果をもとに整理します。

Google公式が示す構造化データの位置づけ

Googleの公式ドキュメント「AI 機能とウェブサイト」には、AI による概要やAI モードでサポートリンクとしてページが表示される条件として、ページがインデックスに登録されていること、Google 検索でスニペットが表示されること、検索の技術的要件を満たしていることが挙げられています。これ以外に追加の技術要件はなく、特別なschema.orgの構造化データを追加する必要もないと記載されています。

一方で、SEOのベストプラクティスの一つとして、構造化データをページに表示されるテキストと一致させることも挙げられています。構造化データを追加する場合は、ページに表示されている内容と合っていることが前提になります。

（参照：Google検索セントラル「AI 機能とウェブサイト」)

ページの内容を正しく伝える補助としての役割

Googleのドキュメントによると、構造化データは、ページの意図を伝えることで、Google検索がそのページをより正確に理解できるようにするためのものです。あわせて、リッチリザルトなど、より目を引く検索結果の表示につながることも、追加する理由として挙げられています。AI による概要への表示を直接増やす効果が公式に示されているわけではありませんが、ページの内容を機械が読み取りやすい形で伝えておくことは、検索全般の基本的な整備の一つといえます。

たとえばホームページにOrganizationの情報を添えると、Googleが組織の管理情報を把握し、検索結果で組織を明確化できるようになるとされています。コラム記事にArticleの情報を添えると、記事のタイトルや作成者、日付情報などを明示的にGoogleに伝えられます。これらを組み合わせることで、「どの会社の、いつ、誰が書いた情報なのか」を機械に伝えやすくなります。

参照：Google検索セントラル「Google 検索における構造化データのマークアップの概要」「組織（Organization）の構造化データ」「記事（Article、NewsArticle、BlogPosting）の構造化データ」

引用数への影響に関する調査結果の読み方

構造化データと引用数の関係については、実際に検証した調査もあります。SEOツールを提供するAhrefsは、2025年8月から2026年3月にかけてJSON-LDを追加した1,885ページと、追加していない対照の4,000ページを比較し、Google AI Overviews、Google AI Mode、ChatGPTでの引用数の変化を調べました。

対照ページと比べた変化は、AI Overviewsで4.6%の減少（統計的に有意）、AI Modeで2.4%の増加、ChatGPTで2.2%の増加でした。AI ModeとChatGPTの差は、ゼロと統計的に区別できない範囲とされています。

Ahrefsは、スキーマの追加によって、どのプラットフォームでも引用数の大きな上昇は見られなかったとまとめています。AI Overviewsの減少については、追加したページも対照ページも調査前から引用数が下がっており、追加したページの下がり方がわずかに大きかった、という差です。Ahrefsは、原因がスキーマだとは断定できないとしています。

ただし、この調査にはいくつかの限界も示されています。対象は、2025年2月時点でAI Overviewsに100回以上引用されていたページに限られていること、JSON-LDの追加と同時に行われたほかの変更を完全には切り分けられないこと、測定期間が追加後30日間であること、JSON-LD以外の形式は検証していないことです。

Ahrefsは、まだAIに見つけられていないページについては、この調査では分からず、スキーマが何らかの役割を果たす可能性も残るとしています。

この結果は、「構造化データを追加すれば引用が増える」ことを裏づけるものではありません。一方で、構造化データがほかの用途で無意味だと示すものでもなく、Ahrefsもリッチリザルトなど、JSON-LDを使う理由はほかにもあるとしています。

なお、Ahrefsが最初に行った約600万URLの分析では、AIに引用されているページは、引用されていないページに比べてJSON-LDを持つ割合が3倍近くありました。

ただしAhrefsは、構造化データを入れているサイトは技術面の整備やコンテンツの質にも力を入れている傾向があり、相関であって因果とは限らないとしています。構造化データで引用率が上がるとする数字を目にした場合は、元の調査が相関を見たものか、追加の前後を対照ページと比べたものかを確認することが大切です。

（参照：Ahrefs「We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved.」（2026年5月11日公開・Louise Linehan氏））

構造化データ実装の基本知識

実際に実装する際に、押さえておきたい基本知識を整理します。

主要な実装タイプ（Article・FAQPage・Organization・BreadcrumbList）

代表的な構造化データのタイプには、次のようなものがあります。

タイプ	表す内容	主な使いどころ
Article	記事の見出し・公開日・著者など	コラムやブログ記事
FAQPage	質問と回答の組み合わせ	よくある質問を掲載したページ
Organization	会社名・ロゴ・組織のウェブサイトのURLなどの組織情報	トップページや会社概要ページ
BreadcrumbList	そのページがサイト階層内のどこに位置するか（パンくずリスト）	パンくずリストを表示しているページ

各タイプの選定基準と特徴

どのタイプを使うかは、ページの性質で決まります。代表的なものとして、コラムやブログの記事にはArticle、ホームページには組織の情報を伝えるOrganization、ページに表示されているパンくずリストにはBreadcrumbListがあります。BreadcrumbListは、そのページがサイト階層内のどこに位置するかを示すものです。

FAQPageについては、注意しておきたい点があります。Googleは2026年5月8日の更新履歴で、よくある質問のリッチリザルトのサポート終了を発表し、2026年5月7日以降、この機能がGoogle検索に表示されなくなったと説明しています。

そのため、検索結果でのFAQ表示を目的としてFAQPageを実装しても、表示されることはありません。ページ内の内容を整理する目的などで使うかどうかは、この点を踏まえて判断することになります。

参照：Google検索セントラル「ドキュメントの更新履歴・最新情報」（2026年5月8日・6月15日の更新）、「組織（Organization）の構造化データ」「パンくずリスト（BreadcrumbList）の構造化データ」「記事（Article、NewsArticle、BlogPosting）の構造化データ」

sameAsでほかのページとの関連付けを示す仕組み

Organizationの構造化データには、「sameAs」というプロパティがあります。Googleのドキュメントでは、組織に関する追加情報がほかのウェブサイトにある場合に、必要に応じてそのページのURLを含めるものと説明されています。

例として、ソーシャルメディアやレビューサイトにある組織のプロフィールページが挙げられており、複数のURLを指定することもできます。

Schema.orgでは、sameAsは「その対象が何であるかを明確に示す、参照用のウェブページのURL」と定義されています。たとえば、WikipediaのページやWikidataのエントリ、公式サイトなどが例に挙がっています。自社の公式のSNSアカウントなどを指定しておくことは、同じ組織に関する情報であることを示すための記述といえます。

なお、Googleのドキュメントでは、Organizationには必ず指定しなければならないプロパティはなく、組織に関連するプロパティをできるだけ多く追加することが推奨されています。

（参照：Google検索セントラル「組織（Organization）の構造化データ」（最終更新：2026年9月12日）、Schema.org「sameAs」）

構造化データの実装ステップ

ここからは、実際に構造化データを実装する手順を、3つのステップで紹介します。

Step1 – 実装タイプを選定する

まず、実装したいページの種類を整理し、そのページに合うタイプを決めます。コラム記事ならArticle、トップページや会社概要ページならOrganization、パンくずリストを表示しているページならBreadcrumbListといった具合です。

ページに表示されていない情報についてはマークアップしないという原則を、最初に確認しておくと安心です。

Step2 – JSON-LDコーディング

次に、決めたタイプに合わせてJSON-LDを記述します。Organizationの記述例は次のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社〇〇",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.facebook.com/〇〇",
    "https://x.com/〇〇"
  ]
}
</script>

記述する内容は、ページに表示されている情報と合わせます。Googleの構造化データのガイドラインでは、ページの読者に表示されないコンテンツをマークアップしないよう示されています。

たとえば、JSON-LDでパフォーマーを記述した場合は、HTMLの本文でも同じパフォーマーが記述されている必要がある、という例が挙げられています。

Step3 – リッチリザルトテストとGoogle Search Consoleで検証

記述したら、Googleが提供するリッチリザルトテストで、コードにエラーがないかを確認します。Googleのドキュメントでは、重大なエラーを修正したうえで、重大ではない問題の修正も検討するよう案内されています。

公開後は、Google Search Consoleで確認します。Search Consoleのリッチリザルトレポートは、パンくずリストや商品スニペット、動画など、サポートされているタイプについて、Googleが有効なマークアップを検出した場合に表示されます。

ArticleやOrganizationは、この一覧に含まれていないため、専用のレポートが出ない場合があります。その場合は、URL検査ツールで、ページの構造化データが検出されているかを確認します。

参照：Google検索セントラル「構造化データに関する一般的なガイドライン」（最終更新：2026年9月16日）、「組織（Organization）の構造化データ」、Search Consoleヘルプ「リッチリザルトレポートの概要」

よくある実装エラーと対策

実装後に起こりやすい問題と、その対処の考え方を整理します。

不正確なマークアップによるリッチリザルトからの除外

構造化データに問題があると、Googleから手動による対策が実施される可能性があります。構造化データに関する手動による対策を受けたページは、リッチリザルトとして表示されなくなります。なお、この場合でも、Googleウェブ検索でのページの掲載順位には影響しないとされています。

ガイドラインでは、ページの読者に表示されないコンテンツをマークアップしないこと、関連性がないコンテンツや誤解を招くコンテンツをマークアップしないこと、構造化データがページのコンテンツを正確に表していることなどが示されています。手動対策の有無は、Search Consoleの「手動による対策」レポートで確認できます。

(参照：Google検索セントラル「構造化データに関する一般的なガイドライン」最終更新：2026年9月16日)

実装後も引用されない場合の診断

構造化データを実装しても、AI Overviewに表示されるとは限りません。前述のとおり、Googleは特別な構造化データは不要としており、構造化データの追加だけで引用が増えるとも限らないためです。また、Googleは、要件とベストプラクティスをすべて満たしていても、インデックス登録と配信は保証されていないとしています。

引用されない場合は、構造化データ以外の基本要件を順に確認します。Googleのドキュメントでは、AI による概要やAI モードでサポートリンクとして表示されるには、ページがインデックスに登録されており、Google 検索でスニペットが表示され、検索の技術的要件を満たしている必要があるとされています。

そのうえで、クロールがrobots.txtに加えてCDNやホスティングインフラストラクチャでも許可されていること、サイトの内部リンクから見つけやすいこと、重要なコンテンツがテキスト形式で提示されていること、構造化データがページに表示されるテキストと一致していることなどが、SEOの基本として挙げられています。

技術的な問題の確認には、Search Consoleでサイトを確認することが案内されています。

参照：Google検索セントラル「AI 機能とウェブサイト」

定期的な見直しが望ましい理由

ページの内容を更新したのに、構造化データだけが古いままになっていると、表示されている内容とマークアップが食い違う原因になります。

構造化データはページのコンテンツを正確に表している必要があるとされているため、担当者名や料金、会社情報などを変更した場合は、構造化データも合わせて更新しておくと安心です。

また、検索エンジン側の仕様が変わることもあります。たとえばFAQのリッチリザルトは、2026年5月7日以降、Google検索に表示されなくなりました。

以前は表示されていた機能が変更されることもあるため、Google検索セントラルの更新履歴など、公式ドキュメントを定期的に確認する習慣があると望ましいです。

参照：Google検索セントラル「ドキュメントの更新履歴・最新情報」

AIO対策を最大化するために

構造化データを含むAIO対策が実を結び、AI経由でサイトを訪れる人が増えたとしても、その後の対応が整っていなければ、成果につなげにくくなります。

AIO対策を最大化するには、訪れた人とどう接点をつくるかも合わせて考えることが大切です。

AI経由で訪れた検討度の高い訪問者を逃さずにアプローチする

Googleは、AIによる概要が表示される検索結果ページからのクリックは質が高く、ユーザーがサイトに長く滞在する傾向があると説明しています。

AIによる概要などの回答を読んだうえでサイトを訪れる人は、すでにある程度の情報を得ており、より詳しく知りたいという状態で来訪しているケースが多いと考えられます。

たとえば、料金ページや導入事例のページを時間をかけて読み、問い合わせフォームの手前まで進みながら、そのまま離脱してしまう訪問者もいます。

リアルタイムでニーズを把握する

こうした訪問者の気持ちは、時間が経つにつれて変わっていく可能性があります。

疑問が残ったままページを離れてしまう前に、関心が高まったタイミングで声をかけられるかどうかが、問い合わせに進んでもらえるかを左右する場合があります。

OPTEMOで訪問者とのリアルタイムな接点をつくる

OPTEMOは、訪問者が特定のページを閲覧していることや、長時間滞在していることを検知してアラートを飛ばし、担当者がチャットや音声通話で直接やり取りできるツールです。

あらかじめ決められた回答を返すチャットボットとは異なり、人が直接対応する点が特徴です。問い合わせフォームの入力直前でとどまっている訪問者とのコミュニケーションを通じて、離脱の抑制や問い合わせへの接続につなげます。

まとめ

構造化データは、Google公式でもAI Overviewsのために特別なものを追加する必要はないとされており、Ahrefsの調査でも、追加による引用数の大きな増加は確認されていません。AIO対策では、構造化データを引用の決め手として期待しすぎず、ページの内容を正しく機械に伝える基盤として、押さえておくという位置づけが現実的です。

一方で、こうした対策は、AI経由で訪れた訪問者との接点が成立して初めて成果につながるものでもあります。検討度の高い訪問者がページ内で疑問を抱えたまま離脱してしまう状況には、記事や構造化データの対策だけでは対応しきれない側面があります。

こうした検討度の高い訪問者を拾いきれていない可能性に課題を感じている場合は、訪問者の行動をリアルタイムで把握しながら有人で対応できるOPTEMOの活用事例が参考になるかもしれません。

OPTEMOの具体的な機能や導入事例については、こちらの資料からご確認いただけます。