構造化データとAI引用｜Googleの公式見解と実装の手順

AI Overviewsに引用されるために特別な構造化データは要らない、とGoogleは公式ドキュメントで説明しています。

引用の前提になるのは、ページがインデックスに登録されていて通常の検索でスニペット付きで表示できる状態にあることです。
構造化データはその状態を支える手段の1つとして入れるものです。

公式の記述と種類ごとの判断、実装と確認の手順をまとめました。
AI検索の仕様は変わり続けているため、ここでは2026年10月時点のGoogle検索セントラルの記述をもとにしています。

AI引用についてGoogleが公式に書いている3点

Googleは検索セントラルのAI機能に関するページで、AI OverviewsとAIモードに表示される条件を説明しています。

構造化データにかかわる記述を抜き出すと次のとおりです。

公式の記述	読み取れること
追加の要件はなく別途特別な見直しも要らない	通常の検索で表示される状態がそのまま前提になる
新しい機械可読ファイルやAI用のテキストファイルやマークアップは要らない	AI向けの専用ファイルを作っても条件は変わらない
特別なschema.orgの構造化データを足す必要はない	構造化データの種類で引用が決まるという説明はない
構造化データはページに見えている文と一致させる	本文にない内容をマークアップに書かない

条件として書かれているのは、インデックスへの登録とスニペット付きの表示と検索の技術的な要件の3つを満たしていることです。
条件を満たしても表示されるとは限らないという注記も同じページにあります。

周辺の仕様も動いています。
FAQのリッチリザルトは2026年5月7日以降Google検索に表示されなくなり、6月12日にはドキュメント自体が削除されました。

音声で読み上げる箇所を指定するspeakableはベータ版のままで、対象は米国の英語のニュース記事に限られています。

構造化データの作業を実際に進めるときの具体的な手順を確認します。
作業にかかる時間の目安は全体で約15分から30分程度です。

1. 対象となるWebページを1つ選び、画面上に実際に表示されている文章の中から、会社名や日付や主要な見出しのテキストを目視で確認します（所要時間の目安：3分）。
2. 選んだページの内容に対応する正しいschema.orgのボキャブラリーを決め、既存のテンプレートを参考にしながらマークアップのコードを組み立てます（所要時間の目安：10分）。
3. 完成したコードをリッチリザルトテストに貼り付けて、エラーや警告が表示されないことを確認してからサイトのテンプレートに組み込みます（所要時間の目安：5分）。

それでも構造化データを入れる3つの理由

文例：ご担当者様。
お世話になっております。
貴社サイトに掲載されている構造化データの記述について、OrganizationとArticleの部分でページ上の表記と一致しない箇所が数件見つかりました。
AI検索での正確な情報伝達とエラー防止のため、該当部分のコードを修正し、リッチリザルトテストで文法エラーが出ない状態へ更新をお願いできますでしょうか。

構造化データは引用の条件ではないものの、入れる理由は今も残っています。

理由の1つ目はページの意味を伝える手がかりになることです。
Googleのドキュメントは構造化データを、ページの内容についての明示的な手がかりと説明しています。

理由の2つ目はリッチリザルトです。
パンくずリストや記事や商品など対応する種類では、検索結果の見え方が変わります。

理由の3つ目は会社や店の情報をそろえることです。
会社名と住所と電話番号をOrganizationやLocalBusinessで書いてページの表記と合わせると、どのページを読んでも同じ会社の話だと伝わります。

cantik.co.jpでも失敗がありました。
JSON-LDを正規表現で選り分ける処理が入れ子の中のServiceという種類に誤って反応し、会社情報の記述を48ページで消していました。

修正では文字列の検索をやめてJSONとして読み込み、いちばん外側の種類だけを見るように変えました。
会社の情報は1か所で定義して、ほかのページからはIDで参照する形にすると管理しやすくなります。

FAQPageも27ページに入れていますが、2026年5月7日以降は検索結果でFAQとして表示されない状態です。
表示を目的に入れた構造化データは、仕様の変化で意味がなくなる場合があります。

6種類の構造化データを入れるかの判断表

入れるかどうかの分かれ目は、検索での表示が今も続いているかと、ページに同じ内容が見えているかの2点です。

種類	今の検索での扱い	入れるかの目安
Article	記事の見出しや画像や日付をGoogleに伝える	記事ページに入れる
BreadcrumbList	パソコンの検索結果でサイトの階層を表示できる	階層のあるサイトは入れる
Organization／LocalBusiness	会社や店の名前と所在地と連絡先を伝える	会社概要や店舗のページに入れる
FAQPage	2026年5月7日以降は検索に表示されない	表示を目的に新しく足す理由はない
HowTo	2023年に表示を終えている	新しく足す理由はない
speakable	ベータ版で米国の英語ニュースのみ	日本語のサイトは対象外

表の上の3つは、表示の有無にかかわらずページの意味を伝える役に立ちます。
下の3つは今の日本語の検索で表示につながらないため、手間をかける順番は後ろになります。

よくある失敗は、すでに入っているFAQPageを慌てて全部消すことです。
消しても害がない一方で得もないため、テンプレートを直すついでに整理する程度で足ります。

自社のサイトで自社につけた評価の星も注意が要ります。
Googleは会社や店が自らのページに載せた自社の評価を、レビューのリッチリザルトとして表示しない扱いにしています。

判断のための具体的な数値の目安として、サイト全体のページ数が50ページ未満の小規模サイトであれば、OrganizationとBreadcrumbListの2種類を網羅するだけで作業時間の目安は合計2時間以内に収まります。
一方で500ページを超える規模のサイトの場合は、手作業による全ページへの個別実装を避け、テンプレートファイルに共通のJSON-LDを自動出力する仕組みを導入することで実装ミスの発生率を全体の1%以下に抑える判断基準とします。

実装と確認の5つの手順

ページに見えている情報を先に決めてから書くと、実装で迷わずに済みます。

1. 判断表から入れる種類を選び、ページに見えている会社名や日付などの情報を書き出します。
2. JSON-LDの形式で書きます。
   Googleは構造化データの形式としてJSON-LDを推奨しています。
3. WordPressでは本文欄に直接貼らず、テーマのテンプレートかプラグインから出力します。
   本文欄に貼ったscriptは、エディタの整形やプラグインの処理で壊れることがあります。
4. リッチリザルトテストでURLかコードを読み込み、エラーと警告を確かめます。
   種類を問わず文法を見るならSchema Markup Validatorも使えます。
5. 公開後はSearch Consoleの「拡張」の各レポートと、URL検査で読み取られたHTMLを確かめます。

手順の4と5で見る項目は別物です。
テストは書き方の正しさを見るもので、Search Consoleは実際にGoogleが読み取った結果を見るものです。

テストで合格してもSearch Consoleに出てこない場合は、URL検査で取得されたHTMLに構造化データが入っているかを見ます。
JavaScriptで後から足す仕組みや、キャッシュが古い版を返しているときに食い違いが起きます。

やってはいけない失敗の例として、構造化データの値をページ内に表示されている実際のテキストとは異なる内容で書き換えてしまう不正な実装があります。
これはGoogleのガイドラインに違反するため、検索順位の低下やリッチリザルト非表示の原因になります。
代わりに画面に視覚的に存在しているテキストと一字一句同じ文字列をマークアップに記述します。

AIに拾われやすい本文の書き方4つ

構造化データを整えたら、次は本文を見直します。

Ahrefsが2026年3月にまとめた調査（AI Overviewsの400万URLと86万3,000キーワード）では、引用元の62%が通常の検索で10位より下のページでした。
引用された内容は上位10位のページより約25.7%新しかったという結果も出ています。

順位の高さだけでは引用は決まらず、質問への答え方と情報の新しさが効いていると読めます。

1. 見出しの直下の1文で答える

見出しで立てた問いに、直下の1文で結論を書きます。
前置きを挟むと答えの文が後ろに下がり、引用される部分として切り出しにくくなります。

よくある勘違いとして、見出しのすぐ下には読者の興味を惹きつけるための挨拶や、記事全体の背景を説明するポエムのような前置きを長々と書かなければならないという思い込みがあります。
実際には検索ユーザーは答えをすぐに求めているため、前置きを挟むと文章の構造が複雑になり、AIが要約の冒頭文として正しく抽出しにくくなります。

なぜならAIのアルゴリズムは各セクションの先頭にある主述の関係が明確な文を答えの候補として優先的にスコアリングする傾向があるためです。
代わりに結論となる名詞止めや断定の文体を最初の1文目に置き、その補足説明を2文目以降に配置する構成にします。

実際に書き直すときは、最初の1文だけで意味が完結しているかを声に出して読み上げて確認します。
もしその1文だけで質問に対する答えが成立していない場合は、文章の順番を入れ替えて結論を一番前に移動させます。

2. 比べる内容は表にする

料金の違いや種類の違いのように並べて比べる内容は、文章ではなく表にします。
行と列の見出しがあると、どの値が何の答えなのかが読み手にもAIにも伝わります。

見る場所や確認のしかたとして、まずは作成した表のHTMLに

タグが適切に使われているかを確認します。見る数字の基準として、行と列の交差するセル内に記載する数値や条件が、周辺の文章と完全に一致しているかをチェックします。

判断の線として、比較する項目が3つ以上あり、かつそれぞれの項目に2つ以上の共通する評価軸がある場合は表形式に変換します。
項目が2つ以下である場合や、比較軸が1つしかない場合は、表にせず箇条書きのリストのほうが読み取りやすくなります。

実装後はスマホの画面幅で見たときに表が画面の外にはみ出していないか、横スクロールのCSSが正しく適用されているかを実機で確認します。
表のレイアウトが崩れてセルの中身が重なっている状態は、AIのテキスト抽出精度を下げる原因になるため修正が必要です。

3. 更新した日と変わった点を書く

仕様が変わる話題では、いつ時点の情報かを本文に書きます。
構造化データの日付と本文の日付をそろえておくと食い違いが起きません。

記事を更新した日と変わった点を本文に明記する作業は、おおむね10分から15分ほどで完了します。

1. 記事の冒頭または末尾に、更新日を年月日まで明確に記載します。
2. 今回の更新で追加した情報や、修正した内容を箇条書きで3行程度にまとめて示します。
3. 構造化データのdateModifiedの値を、記事上に表示した更新日と一致させます。
4. プレビューで日時の表記とマークアップの記述に誤りがないことを確認して公開します。

4. 会社と書き手の情報をそろえる

会社名や所在地の表記を全ページで同じにし、誰が書いたかが分かるページを用意します。

文例：この記事は、構造化データの実装支援を5年以上行うWebマーケティング事業部が執筆しています。
執筆者情報の詳細や過去の監修実績については、運営者情報ページをご覧ください。

運営者情報の表記を統一するための確認作業には、おおむね20分ほどかかります。

1. 会社名・住所・連絡先の表記が、すべてのページのフッターや会社概要ページで完全に一致しているか確認します。
2. 記事ごとの著者欄に、実際の執筆者のプロフィールページへのリンクを設置します。
3. 構造化データのAuthorプロパティに、著者ページや組織のURLを正しく指定します。

引用されたかの測り方とよくある失敗

AI OverviewsとAIモードでの表示は、Search Consoleの検索パフォーマンスで検索タイプ「ウェブ」に含めて集計されます。

公式ヘルプには、AI Overviewsだけを切り出して見る方法が書かれていません。
そこでクエリごとの表示回数とクリックの変化を見ながら、実際に検索して引用の有無を記録します。

記録する項目は日付と検索語と引用の有無の3つで足ります。
同じ語を週に1回、同じ端末で調べると変化が追えます。

cantik.co.jpの90日分のSearch Consoleでは、「aio」「効果」「測定」を並べた検索語で2.3位にいながら表示357回でクリックが0でした（2026年9月20日時点）。
順位が高くても、AIの回答で用が済むとクリックは生まれにくくなります。

同じ時点で「構造化データ」「ai」「引用」を並べた検索語には自社の記事7本が表示され、最上位は4.4位でした。
同じ語で記事を重ねると、自社の記事同士で評価が分かれます。

よくある失敗をまとめると次の3つです。

• FAQPageを足せば引用されると考えて、全ページに同じ質問を入れる
• 本文にない料金や評価をマークアップだけに書く
• 同じ検索語で記事を何本も書き、自社の記事同士で競わせる

引用の有無を判断するための数値の目安として、直近30日間の表示回数が500回以上、平均掲載順位が10位以内のクエリを対象にします。

この条件に該当するクエリのうち、実際の検索結果画面で自社サイトがAIの回答枠に引用されている割合が20パーセント未満である場合は、本文の情報量やマークアップの記述を見直す判断基準にします。

測定と改善を繰り返す頻度としては、月に1回のペースで過去30日間のデータを比較し、引用率の増減を追うのが現実的です。

1. Search Consoleから過去30日間の検索クエリデータをCSV形式でダウンロードします。
2. 表示回数が上位のクエリを50件抽出し、実際にブラウザで検索してAIによる引用の有無を目視で確認します。
3. 確認結果をスプレッドシートに記録し、前月との引用率の差分を算出します。
4. 引用されていない主要クエリについて、本文の網羅性や構造化データの記述に不足がないか検証します。

知らないと損する注意点

構造化データを入れれば引用されると思われがちな誤解

構造化データを追加すればそれだけでAI Overviewsに引用されるという思い込みがあります。
実際には構造化データはページの内容を検索エンジンに正しく伝えるための補足的な手段であり、引用の直接的な条件ではありません。
なぜならGoogleは特別なマークアップがなくてもインデックスとスニペットの要件を満たしていれば引用対象になると明言しているからです。
ご自身のサイトで構造化データだけに頼っていないかを確かめるには、マークアップを実装したページが通常の検索結果で正しく上位に表示され、スニペットが意図通りに生成されているかを確認してください。

古い仕様のままでも問題ないと思われがちな誤解

すでに提供が終了した仕様の構造化データをそのままにしておいても影響はないという思い込みがあります。
実際には検索エンジンの仕様変更に伴ってサポートされなくなったコードを放置しても検索順位に直ちに悪影響が出るとは限りませんが、メンテナンスの行き届いていない印象を招きコードの管理コストを無駄に増やす原因になります。
なぜならGoogleは検索結果の表示形式を定期的に見直しており、廃止されたリッチリザルトのコードは読み取られても機能しなくなるためです。
ご自身のサイトの状況を確かめるには、過去に設置したFAQPageやHowToなどのコードが現在の検索結果でどのように扱われているかをSearch Consoleやリッチリザルトテストで点検してください。

すべての検索語で上位を狙うべきと思われがちな誤解

アクセス数を増やすために同じような内容の記事を大量に作って複数の検索語で上位を狙うべきだという思い込みがあります。
実際には似たテーマの記事を何本も作ると自社のサイト内で評価が分散してしまい、かえってAIの回答に引用されにくくなります。
なぜならAIは同じドメイン内から似た情報を重複して選ぶよりも、明確に整理された単一のページを引用元として好む傾向があるためです。
ご自身のサイトの状況を確かめるには、アクセス解析ツールやSearch Consoleを開き、同じような検索クエリに対して複数のページが同時に表示されて共食いを起こしていないかを調べてみてください。

いまの状態を確認するチェックリスト

各項目の状態をご自身で確かめて、サイトの現在の立ち位置を把握してください。

• 必要な構造化データを正しく実装できている
• マークアップの値とページの本文が一致している
• 古いFAQPageの記述を放置していない
• 見出し直下の1文で結論を答えている
• 比べる内容を表形式にまとめている
• 記事の更新日と変わった点を明記している
• 会社名や所在地の表記を全ページでそろえている
• Search Consoleの拡張レポートでエラーを確認できている

もし×の項目が多い場合は、まずはページ上のテキストと構造化データの記述を一致させる作業から始めてください。
次に見出し直下の1文目を見直して結論を明快にする修正を進めると効果的です。
日々の業務で手が回らない場合は、構造化データや本文の修正を専門家に任せる選択肢もあります。
お困りの際は無料相談からお気軽にお問い合わせください。

よくある質問

Q. AI Overviewsに引用されるために最も大事な構造化データはどれですか？

特定の種類はありません。

Googleは特別なschema.orgの構造化データを足す必要はないと説明しています。
会社情報や記事の情報を、ページの表記と一致させて書くことが基本です。

Q. 構造化データの実装に専門知識は要りますか？

WordPressならプラグインで基本の種類を出力でき、書き方の知識がなくても始められます。

ただし自動で出る内容がページの表記と合っているかは、リッチリザルトテストとURL検査で確かめる必要があります。

Q. llms.txtのようなAI用のファイルを置けば引用されやすくなりますか？

Googleの検索については、そうした説明はありません。

公式ドキュメントにはAI用のテキストファイルを新たに作る必要はないと書かれています。
cantikでは、構造化データの点検と本文の書き直しをAIO対策としてZOOM・電話・メールでご相談いただけます。

▶ 関連サービス：AIO・LLMO・GEO対策