構造化データは「入れれば入れるほどAI検索に強くなる」というものではありません。Googleは生成AI検索のために特別なマークアップは不要だと公式に説明しています。
それでも実装する価値はどこにあるのか、具体的に何を・どう書き・どう検証すればよいのかを、本記事では手順に絞って解説します。
記事執筆者:認定SEOコンサルタント 三田健司
構造化データとは?AI検索の文脈で語られる理由

構造化データの基本的な仕組み
構造化データとは、ページの内容を検索エンジンやAIが機械的に理解できる形で記述する仕組みのことです。人間が読む本文とは別に、ページのどこが会社名で、どこが住所で、どこがFAQなのかをタグ付けして伝えます。
代表的な記述形式がJSON-LDで、後述する通りGoogleも公式にこの形式を推奨しています。構造化データそのものはページの見た目を変えるものではなく、あくまで裏側の情報整理です。
なぜ「AI検索」の記事でこのテーマが繰り返し出てくるのか
AI検索対策(GEO)の記事で構造化データが必ずと言っていいほど登場するのは、数少ない「自社サイトだけで完結する、具体的な作業」だからです。AIがどの情報を拾うかという仕組み自体は外部要因が大きく、自社側でコントロールできる範囲は限られています。
その中で構造化データは、実装するかどうか・どう書くかを自社の裁量だけで決められる数少ない項目です。だからこそ本記事では「効果があるかどうか」ではなく「どう実装し、どう確認するか」に絞って解説します。
Google公式が「必須ではない」と言う意味を正しく理解する
生成AI機能に特別なマークアップは不要
Googleは検索の生成AI機能について、公式ガイドで次のように述べています。「Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add.」
つまり、生成AIのためだけに用意すべき専用のスキーマは存在しません。同じガイドでは、llms.txtのようなAI向け専用ファイルについても「作成する必要はなく、作っても害にも益にもならない」という趣旨の説明がされています。
それでも実装する価値がある理由
「必須ではない」は「意味がない」とは違います。構造化データは従来型のリッチリザルト(検索結果でのFAQ表示や評価の星表示など)には引き続き関わり、Search Consoleのリッチリザルトレポートでも状態を追跡できます。
構造化データは「AI検索用の裏ワザ」ではなく「検索エンジン全体にページの情報を正確に伝えるための基本動作」だと捉えるのが実態に近いと言えます。実装するとしても、この位置づけを誤解しないことが重要です。
JSON-LDが推奨される理由と基本の書き方
なぜGoogleはJSON-LDを勧めるのか
構造化データの記述形式には主にJSON-LD、Microdata、RDFaの3つがありますが、Googleの公式ドキュメントはJSON-LDを推奨形式として明記しています。理由は、scriptタグの中に独立して埋め込めるため、本文のHTMLと混ざらず実装・保守がしやすいことです。
JavaScriptで動的に生成した場合でも読み取れる点、ネストした複雑なデータを表現しやすい点もJSON-LDが選ばれる理由です。中小企業サイトで新たに実装するなら、まずJSON-LD一択で問題ありません。
最小限のOrganizationマークアップの例
例えば会社情報を伝えるOrganizationスキーマは、次のように最小限の項目だけでも成立します。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "会社名",
"url": "https://example.co.jp/",
"logo": "https://example.co.jp/logo.png"
}
</script>
name・url・logoの3項目だけでも構造化データとしては有効です。電話番号や住所、SNSのURLなどは、sameAsやcontactPointといったプロパティで追加していく形になります。
中小企業サイトに入れるべき3種類の構造化データ

Organization/LocalBusiness ― 会社そのものを説明する
会社概要ページやトップページに入れる基本のマークアップです。実店舗や来店型のビジネスであれば、OrganizationではなくLocalBusiness(業種によってはより詳細なサブタイプ)を使うことで、住所や営業時間を構造化して伝えられます。
これはAccessGEOの過去記事でも触れた、AIに正しく認識される会社概要ページの書き方と地続きのテーマです。ページ本文の情報とマークアップの情報が食い違わないようにすることが前提になります。
FAQPage ― よくある質問をそのまま構造化する
ページ内に実際に表示しているFAQの質問と回答を、そのままFAQPageスキーマとしてもマークアップします。本文に存在しない質問をマークアップだけに追加することは、Googleのガイドラインで禁止されています。
本記事の末尾にも「よくある質問」を用意していますが、これも同じ考え方に沿った構成です。表示していない質問をマークアップに含めないことがポイントです。
Article ― ブログ記事に著者・日付情報を持たせる
ブログ記事にはArticleスキーマで、見出し・著者名・公開日・更新日を構造化します。執筆者名を明記することは、E-E-A-Tの観点でもArticle構造化データの観点でも共通して重要です。
Organization/LocalBusiness、FAQPage、Articleの3種類が、中小企業サイトにおいて優先度の高い実装範囲だと考えています。
実装手順:ページ選定からデプロイまでの5ステップ
ステップ1〜3|対象ページの選定からマークアップ追加まで
Google公式の手順に沿うと、まず①既存のコンテンツがあり、一定の検索トラフィックがあるページを選ぶことから始めます。空白のページや、ユーザーには見えない情報にだけマークアップを追加することは推奨されていません。
次に②該当ページのHTML内に script type=”application/ld+json” としてマークアップを追加し、③本文の内容とマークアップの内容が一致しているかを確認します。
ステップ4〜5|検証とデプロイ後の確認
④デプロイ前にRich Results Testで妥当性を確認し、⑤公開後はSearch Consoleのリッチリザルトレポートで継続的に状態を監視します。この2つのツールの使い方は次の章で具体的に解説します。
WordPressの場合、テーマやプラグインが一部の構造化データ(パンくずリストなど)を自動生成していることもあるため、実装前に既存の出力と重複していないかを確認しておくと二重マークアップを避けられます。
検証手順:Rich Results Testとスキーマ検証で潰すべきエラー

Rich Results Testの使い方
GoogleのRich Results Testは、URLまたはコードを直接貼り付けるだけでマークアップの妥当性を確認できる無料ツールです。ページがまだ公開されていない場合は、コード貼り付けでチェックできます。
結果画面では「有効なアイテム」「エラー」「警告」が項目ごとに表示されるため、赤字のエラーから優先して直していきます。
よくあるエラーとその直し方
最も多いのは必須プロパティの欠落です。Organizationであればnameとurl、FAQPageであれば各質問のmainEntityとacceptedAnswerが欠けていると、リッチリザルトの対象から外れます。
もう一つ多いのが、本文とマークアップの内容が一致していないケースです。ページを更新したのにマークアップ側のテキストを直し忘れる、というミスは実装後しばらくしてから起こりがちです。
デプロイ後の監視とよくあるトラブル
Search Consoleのリッチリザルトレポートで見るべき指標
公開後はSearch Consoleの各種構造化データレポート(FAQ、パンくずリストなど)で、「有効」「エラー」「警告」の件数推移を定期的に確認します。件数が急に増えた場合は、テンプレート変更やプラグインの更新が原因であることが多いです。
URL検査ツールを使えば、特定の1ページについてGoogleが構造化データをどう認識しているかをピンポイントで確認できます。
テンプレート変更で構造化データが壊れるケース
WordPressのテーマやプラグインを更新した後、それまで正常だった構造化データが出力されなくなる、あるいは重複して出力されるようになることがあります。定期的な検証を「実装した時だけ」で終わらせないことが重要です。
弊社でも月に一度は主要ページのRich Results Testを見直す運用にしています。
構造化データを入れてもAI検索の露出が変わるとは限らない理由

AccessGEO自身の実測から見えること
AccessGEOでは自社サイトにOrganization・FAQPage・Articleの構造化データを実装した上で、ChatGPT・Gemini・Google AI Overviewsに同じ質問を毎日投げ続け、回答内に「アクセス・リンク」という社名が含まれるかどうかを観測しています。2026年7月4日から9月24日までの76日間・2,257回の観測では、自社名が言及された割合は27.4%でした。
内訳を見ると、指名検索に近い質問では93.8%、地域名とMEO系の質問では83.6%と高い一方、県域規模の一般的な比較・推薦系の質問では20.4%、残り6設問については76日間を通じて0.0%のままです。構造化データを整えたことで、これらの質問での露出が底上げされたという証拠はいまのところありません。
構造化データは「土台」であって「ブースター」ではない
この結果は、構造化データが無意味だという意味ではありません。むしろ露出の差を生んでいるのはマークアップの有無ではなく、指名検索に近いかどうか・情報量が十分かどうかといった、もっと根本的な要因だと考えるのが妥当です。
構造化データは「入れれば露出が増える施策」ではなく「入れていないと不利になりうる基礎工事」と位置づけるのが実態に近い、というのが実測を続けている立場からの結論です。
よくある質問
Q1. 構造化データを入れると、AI検索に必ず表示されますか?
いいえ。Google自身も生成AI検索に特別なマークアップは不要だと説明しており、構造化データの実装とAIの回答に自社が表示されるかどうかは別の問題です。本記事で紹介した実測でも、構造化データの有無だけで露出が変わったという結果は出ていません。
Q2. MicrodataやRDFaでも良いですか?
文法上は有効ですが、Googleが推奨し、実装・保守のしやすさでも優れているのはJSON-LDです。新規に実装するのであれば、特別な理由がない限りJSON-LDを選んでください。
Q3. 構造化データの実装だけを外注できますか?
可能です。ただし本文の内容とマークアップの内容を一致させ続ける運用(テーマ更新時の確認など)まで含めて依頼するのが望ましく、実装して終わりにしないことが重要です。
関連記事




まとめ
構造化データは、Google公式が明言する通り生成AI検索のための必須要件ではありませんが、JSON-LDでOrganization・FAQPage・Articleを整えておくことは、検索エンジン全体に対する基本的な情報整理として引き続き価値があります。実装はページ選定→マークアップ追加→内容の一致確認→Rich Results Testでの検証→デプロイ後の監視、という5ステップで進めるとミスを減らせます。
一方で、AccessGEOの実測が示す通り、構造化データを整えるだけでAI検索の露出が底上げされるわけではありません。まず自分でできる範囲を整えたうえで、実際にAIにどう見えているかを継続的に確認したい場合は、無料のGEO診断もあわせてご活用ください。
御社がどう紹介されているか、無料で診断
3つのAIに実際に質問し、御社と競合の出方をレポートにしてお送りします。
費用はかかりません。営業のご連絡もいたしません。


コメント