そう語られがちですが、実際はそこまで単純ではありません。
GoogleはAI向けの専用スキーマを用意していないと示しています。
ただ無駄という話でもなく、むしろ逆です。
AIが本文を読み違えるリスクを下げる土台として、いま効いてきています。
総務省の令和6年版情報通信白書によると、デジタル化が「未実施」と答えた割合は大企業で約25%、中小企業で約70%。
この差は、AI検索の時代にそのまま見つけてもらえるかどうかの差になります。
📌 この記事でわかること
- 1
構造化データはAI引用を保証しませんが、ページ内容を機械が読める形で示し、本文の解釈のブレを減らす土台になります。
詳しく見る → - 2
最初に入れるべき構造化データはArticle・Organization・BreadcrumbListの3種で、10人以下の会社ならこの範囲で足ります。
詳しく見る → - 3
記述方式はJSON-LDがGoogle推奨で、本文のHTMLに触れずテンプレートのhead内へ一度組み込めば全記事に反映できます。
詳しく見る → - 4
検証ツールのエラーは必須項目の欠落なので修正し、警告は推奨項目の未記入なので実体がなければ埋めなくて構いません。
詳しく見る → - 5
GoogleはAI向けの専用スキーマを用意しておらず、llms.txtも主要検索エンジンが公式対応を表明していません。
詳しく見る →
この記事の監修者
味生 豊
aOn株式会社 代表 / デジタル支援パッケージ「ツナギト」開発者
愛媛県出身。建設業で12年半の経営経験を持ち、西日本全域250件以上の施工管理実績と官公庁入札案件30件以上の落札実績を持つ。オウンドメディア「エネプラ.com」では、LED工事のワンストップ対応を軸に月間15万PV・月間10数件の問い合わせを獲得し、成約率3割以上を実現。この実体験からSEO・Webマーケティングの道へ進み、現在は中小企業向け伴走型デジタル支援パッケージ「ツナギト」を開発・運営。HP制作・SEO対策・AI活用・業務自動化までをワンストップで提供している。
📑 この記事の内容
構造化データがAI引用に効く理由｜AIが情報を読む仕組みから理解する
基本の考え方：構造化データとは、ページの内容を検索エンジンやAIが機械的に読み取れる形式で記述したマークアップです。
結論：構造化データはAI引用を保証しませんが、内容の解釈のブレを減らす土台になります。
- 要点1：AI検索の普及により、利用者はリンクを読み歩かずAIが抜粋した情報だけで判断する行動へ移りつつあります
- 要点2：構造化データの役割は、ページの内容を機械が読み取れる形式で示し、本文の解釈のブレを防ぐことです
- 要点3：発行元や著者をマークアップで機械に伝えることで、E-E-A-Tのシグナルが明示されます
未実施の割合の差はおよそ45ポイント。サイトの中身を機械が読める形に整えているかも、この延長線上の話です。
デジタル化「未実施」の企業割合
（出典：令和6年版 情報通信白書｜各国企業のデジタル化の状況｜政府機関（.go.jp）, 2024）
aOnが2026年4月にまとめた社内レポートでは、これからはto B・to Cに加えて「to A（AI）」の時代になる、と整理しています。検索結果のリンクを上から読み歩く行動は減り、AIが抜粋した情報だけに触れて判断する。抜粋される側になるには、AIが本文を読んだとき「何について書かれた、どんな種類のページか」を取り違えないことが前提になります。
大規模言語モデルが構造化データをもとに推論する枠組みの研究でも、整理された形式を参照させる設計の有効性が報告されています。人間なら文脈で補える「この日付は公開日か更新日か」「この名前は著者か取材相手か」を、機械は本文だけで区別できません。その曖昧さを先回りして潰す作業なんですよね。
構造化データを入れたからAIが引用する、という因果はありません。できるのは引用されやすい構造にしておくところまでです。発行元や著者が機械に伝わり、E-E-A-Tのシグナルが明示される。得られるのはそこまでです。
💡 ポイント
守備範囲は「AIに正しく理解させる」ところまで。引用されるかは本文の中身と信頼性で決まります。
構造化データは引用の保証書やなくて、誤読を防ぐ下ごしらえですね。まずAIに正しく読ませる、そこから先は中身の勝負だと思います。
どのスキーマを選ぶ？Article・FAQPage・HowTo・Organizationの使い分け
このセクションでは：スキーマとは、ページの種類や役割をschema.orgの語彙で指定する型の定義です。
結論：最初に入れるべきはArticle・Organization・BreadcrumbListの3種です。
- 要点1：記事ページの土台となるArticleの選択
- 要点2：authorとpublisherによる発信主体の明示
- 要点3：本文に実際のQ&Aがないままマークアップだけを足すと、本文との不一致として扱われます
種類は膨大ですが、全部は必要ありません。10人以下の会社ならこの範囲で足ります。
まず押さえる4つのマークアップ
- Article（またはBlogPosting）：記事ページの本体を示す
- Organization：会社そのものをサイト全体で示す
- BreadcrumbList：サイト内の位置を示す
- author / publisher：誰が書いて誰が出したかを伝える
スキーマ別の役割と優先度
| スキーマ | 役割 | 優先度 |
|---|---|---|
| Article | 見出し・公開日・著者 | 高 |
| Organization | 会社名・ロゴ | 高 |
| BreadcrumbList | 階層と文脈 | 中 |
| FAQPage / HowTo | Q&Aや手順の構造 | 低 |
見落とされがちなのがauthor・publisher・sameAsです。authorで書き手を、publisherで発行元を指定し、sameAsに公式SNSや掲載ページのURLを並べる。これで「誰が書いた記事か」が機械の側で紐づきます。著者名を本文に書くだけでは、機械にとってただの文字列のままなんです。本文にないQ&Aをマークアップだけで足すのも、不一致として扱われる典型です。
FAQPageは扱いに注意が必要です。2026年5月7日をもって、FAQの検索結果での表示は終了しました。見た目の変化を狙って入れるスキーマではなくなったわけです。Q&Aの構造を機械が把握しやすくなる意味は残るので、記事内に実際のQ&Aがある場合だけ入れる判断が現実的でしょう。
⚠️ 注意
マークアップは本文の写しです。本文にない情報を構造化データにだけ書くと不一致になります。
スキーマ選定は「何者が出した情報か」を伝える作業でもあります。
欲張って全部入れる必要はないですよ。ArticleとOrganizationとBreadcrumbList、この3つを丁寧に埋めるほうが効きます。
JSON-LDでの実装手順｜記述→設置→検証の3ステップ
ざっくり言うと：JSON-LDとは、構造化データをJavaScript Object Notationの形式でまとめて記述する方式です。
結論：実装は記述・設置・検証の3ステップで完了します。
- 要点1：Google推奨の記述形式としてのJSON-LD
- 要点2：JSON-LDは記事テンプレートのhead内へ組み込み、全記事へ自動出力する形が安全です
- 要点3：検証ツールのエラーは必須項目の欠落なので修正し、警告は推奨項目の未記入なので実体がなければ放置します
記述方式はJSON-LD、microdata、RDFaの3つ。結論としてはJSON-LDで問題ないです。
3つの記述方式の違い
JSON-LD
本文と分けて1か所に置く方式。Google推奨で、テンプレート化しやすく保守も軽い。
microdata
HTMLタグに属性を書き足す方式。本文を改修すると記述が崩れやすい。
RDFa
同じく属性を書き足す方式。記述量が多く、保守の負荷が重くなりがち。
本文のHTMLをいじらずに済むのが強みです。記述はこの分量から始められます。
{ "@context": "https://schema.org", "@type": "Article", "headline": "記事タイトル", "author": { "@type": "Person", "name": "著者名" }, "publisher": { "@type": "Organization", "name": "会社名" } }分かれ目は、記事ごとに手で貼るのか、テンプレート側で自動出力するのかです。数本までは手作業で回りますが、その先で必ず抜けが出ます。aOnの社内レポートでも、AIに引用される情報はSERP上位20位以内から選ばれる確率が高いと整理し、記事を積み上げてE-E-A-Tを育てる前提とセットに置いています。
記述から検証までの3ステップ
- 記述する
JSON-LDでArticle・author・publisherを最小構成で書く。まずはこの分量で十分。 - 設置する
記事テンプレートのhead内へ組み込み、全記事に自動出力される状態にする。 - 検証する
リッチリザルトテストとスキーママークアップ検証ツールで確認し、公開後はSearch Consoleの拡張レポートで検出状況を追う。
書いたら必ず検証します。使うのはリッチリザルトテスト、スキーママークアップ検証ツール、Search Consoleの拡張レポート。前の2つは即座に結果が出て、Search Consoleは公開後の検出状況を追えます。情報源の質が精度を左右する点は、検索拡張生成の研究でも指摘されています。
検証するとエラーと警告が両方出ます。エラーは必須項目の欠落なので直す。警告は推奨項目の未記入なので、実体がないなら放置で構いません。無理に埋めるほうが危険です。
🔴 重要
エラーは直す、警告は実体があるときだけ埋める。この線引きで作業は止まらなくなります。
基本は以下の記事で扱っています。
手貼りは必ずどこかで抜けます。最初からテンプレート側に仕込んでおくほうが、後々ラクですよ。
AI時代の集客、何から始めればいいか迷っていませんか？
➤まずは無料で相談してみる！（お気軽にご状況をお聞かせください）よくある質問
よくある質問について：実務で直面しやすい疑問や判断に迷いやすいポイントを中心に、読者から多く寄せられる質問を観点別に整理しました。本文と併せてチェックリストとして活用してください。
構造化データを入れればAIに引用されますか？
引用は保証されません。構造化データの役割は、ページの種類や著者・発行元を機械が誤読しないよう整えることです。引用されるかどうかは本文の中身と信頼性の蓄積で決まるため、まずは誤解のない土台を作る施策として位置づけてください。
最初に入れるべきスキーマはどれですか？
Article（またはBlogPosting）、Organization、BreadcrumbListの3種です。あわせてauthorとpublisherで「誰が書いて誰が出したか」を指定し、sameAsに公式SNSや掲載ページのURLを並べておくと、発信主体が機械側で紐づきます。
FAQPageは今でも入れる意味がありますか？
2026年5月7日にFAQの検索結果での表示は終了したため、見た目の変化を狙う理由はなくなりました。ただしQ&Aの構造を機械が把握しやすくなる意味は残るので、記事内に実際のQ&Aがある場合だけ入れる判断が現実的です。
検証で出た警告は全部直すべきですか？
いいえ。エラーは必須項目の欠落なので必ず直しますが、警告は推奨項目の未記入です。実体のない情報を無理に埋めると本文との不一致になり、かえって危険です。実際に存在する情報があるときだけ追記してください。
この記事を読んだ方がよく検索する質問
llms.txtは設置したほうがいいですか？
2026年8月時点で、主要な検索エンジンは公式に対応を表明していません。設置自体のコストは低いものの、AI引用の決め手になる保証はないため、まずはArticleやOrganizationなど既存の構造化データの整備を優先するのが現実的です。
効果が出るまでどれくらいかかりますか？
Search Consoleでの検出は数日〜数週間で確認できます。ただしAIに引用されるかは記事の蓄積と信頼性次第なので、短期の順位変動ではなく、テンプレート側に組み込んで全記事に効かせる中長期の投資と考えてください。
自分で実装できますか？外注すべきですか？
ArticleとOrganizationまでなら、テンプレートにJSON-LDを1ブロック追加するだけで自力対応が可能です。記事ごとの手貼りは必ず抜けが出るため、テンプレート側で自動出力する設計にできるかどうかが外注判断の分かれ目になります。
プラグインを入れていれば十分ですか？
基本形は自動で出力されることが多いですが、authorやsameAsが空のまま出ている例は珍しくありません。一度リッチリザルトテストで実際の出力を確認し、著者情報と発信主体が埋まっているかだけは自分の目で確かめてください。
実装に着手する順番
構造化データはAI引用の保証書ではなく誤読を防ぐ下ごしらえです。Articleとauthorから着手し、検証ツールでの確認までを一区切りにしてください。
- Articleとauthorを記事テンプレートのhead内へ組み込み、全記事に自動出力される状態から始めてください。
- OrganizationとsameAsで発信主体を機械に紐づけ、著者名が単なる文字列で終わる状態を解消してください。
- リッチリザルトテストとSearch Consoleで検出状況を確認し、エラーだけを直して警告は実体があるときのみ埋めてください。
参考文献
参考情報について：本記事の信頼性を担保するため、公的統計・学術論文・業界専門媒体を中心に、複数の一次情報源を参照しました。各出典は執筆時点で確認できる最新情報に基づいています。
- 令和6年版 情報通信白書｜各国企業のデジタル化の状況｜政府機関（.go.jp）, 2024
- StructGPT: 大規模言語モデルが構造化データ上で推論するための汎用フレームワーク (原題: Structgpt: A general framework for large language model to reason over structured data)｜J Jiang, K Zhou, Z Dong, K Ye, X Zhao, 2023
- 知識指向の検索拡張生成に関するサーベイ (原題: A survey on knowledge-oriented retrieval-augmented generation)｜M Cheng, Y Luo, J Ouyang, Q Liu, H Liu, L Li, 2025
- 検索拡張生成システムにおける信頼性: サーベイ (原題: Trustworthiness in retrieval-augmented generation systems: A survey)｜Y Zhou, W Zhang, J Shao, Y Liu, X Li, J Jin, 2024