構造化データ実装前後のAI引用率を測ってみた！

構造化データを入れれば、ChatGPT検索やPerplexity、Google AI Overviewsに自社のページが
引用されやすくなる——そう聞いて実装を検討している人は多いはずだ。だが「なぜ効くと言われているのか」
「実際に何をどう実装すればいいのか」を、順序立てて理解した上で導入している人は意外と少ない。

本記事では、断定的な「〇%上がった」という話ではなく、①なぜFAQPage・HowToが引用に効くと
言われているのかという仕組み、②実装の要点とつまずきやすい点、③「AI引用率」を語る前に決めておくべき
こと、の3つを順に扱う。実装前後の変化を自分の手で測定する方法は、内容が独立した別記事にまとめる。

なぜFAQPage・HowToがAIに引用されやすいと言われるのか

構造化データそのものがAIに「選ばれる」わけではない。AIが文章から質問と答えの対応関係を機械的に抽出しやすくなる、あくまで補助的な効果だと理解しておく必要がある。

「構造化データを入れればAIに引用される」という説明は、半分正しく半分は誤解を招く。正確には、
AIが回答を生成する過程で参照元候補を絞り込む際、情報の対応関係が機械可読な形で示されているページの方が、
処理の途中で除外されにくいというだけの話だ。引用されるかどうかを直接決めているのは
コンテンツの内容そのものであり、構造化データはその内容を正しく伝えるための補助にすぎない。
この前提を踏まえた上で、具体的にどういう仕組みで補助になっているのかを見ていく。

LLMは非構造なテキストより、Q&A形式の対応関係を抽出しやすい

FAQPage・HowToマークアップは、質問と回答、手順とその順序をあらかじめ機械可読な形で提示するためのものだ。

LLMが回答を生成する際、地の文だけのページから「どの一文がこの質問への答えなのか」を都度推論して抽出するのは、処理コストがかかるうえに誤抽出のリスクもある。あらかじめ構造化された対応関係が用意されていれば、その推論の手間を省いて参照できる、という理屈である。

実際にschema.orgのFAQPageはquestionとacceptedAnswerというプロパティで質問と回答のペアを、HowToはstep・name・textというプロパティで手順の名称と内容、その順序を機械に伝える。地の文だけでは「これが質問でこれが答えです」という区切りは推測に頼るしかないが、これらのプロパティがあれば区切りそのものが明示される。

ただし例外がある。構造化データを入れても、本文側の説明が曖昧だったり不正確だったりすれば意味がない。マークアップはあくまで「答えの場所を示す標識」であり、答えの内容の質そのものを担保するものではない。標識だけ整えて中身が薄いページは、結局参照する価値がないと判断される。

Googleの公式見解とAI検索の関係を混同しない

「構造化データが検索順位に直接効く」という主張と、AIに引用されるかどうかの話は、別レイヤーの問題として区別する必要がある。

Googleは構造化データが検索順位の決定要因ではないと明言している。一方で、リッチリザルトの表示や、AI Overviewsのような生成型の検索結果がどのページを参照するかという判断においては、ページの内容をより正確に理解する材料として構造化データが扱われていると考えられている。「順位が上がる」という話と「AIに理解されやすくなる」という話は、目的も評価される場所も異なる。

ここで注意したいのは、AI検索エンジン各社は生成アルゴリズムの詳細を公開していないという点だ。そのため両者の因果関係を証明することはできない。ここまでの説明も、あくまで公開されているschema.orgの仕様とGoogleの公式ガイドラインから読み取れる「仕組み上の合理性」であり、実測された効果を主張するものではない。

構造化データを入れれば順位もAI引用も両方上がる、と一括りに考えてしまうのはよくある誤解だ。SEO目的であれば構造化データの優先度は中程度、AI引用を主目的にするなら優先度は高い、というふうに目的ごとに切り分けて考えた方が判断を誤らない。

実装の基本（要点のみ）

実装方法自体はすでに多くの記事が解説しているため、ここでは要点とつまずきやすい点、そして「実装したつもり」で終わらないための確認手順に絞る。

前提として、記述形式や設定手順そのものに目新しさはない。差が出るのは、実装後にきちんと検証しているかどうかと、内容とマークアップが一致しているかどうかの2点だ。

JSON-LD形式で書き、実装後は必ず検証ツールで確認する

記述形式はJSON-LD一択で問題ない。HTMLのタグに直接属性を埋め込む方式（Microdata）も仕様上は存在するが、実装・保守のしやすさで劣るため、新規に実装するなら選ぶ理由はない。

Googleが推奨する形式であり、WordPressの主要なSEOプラグインでもJSON-LD形式での出力に対応が進んでいる。プラグインのFAQブロックやHowToブロックを使えば、コードを書かなくてもJSON-LDが自動生成される場合が多く、保守コストが低い。

実装後は、Googleが提供するリッチリザルトテストと、スキーマ マークアップ検証ツールの両方で確認する。前者はGoogle検索での表示可否、後者はschema.orgの仕様に沿った記法になっているかを確認するためのもので、目的が異なるため両方確認しておいた方がいい。URLを入力するだけで、エラー・警告の有無が一覧で表示される。

例外として、ページの表示内容と一致しないマークアップは避ける必要がある。実際にはFAQが表示されていないページにFAQPageを入れる、手順が存在しないページにHowToを入れる、といった実装は、Googleのガイドライン上スパムとみなされるリスクがある。実装後にエラーが出ていなくても、内容との一致は機械的にはチェックされないため、目視での確認を省かないこと。

「AI引用率」という言葉を語る前に決めておくべきこと

「AI引用率」は業界標準の定義がまだ存在しない指標であり、ChatGPT検索・Perplexity・Google AI Overviewsのどれを対象にするかで挙動がまったく異なる。実装の前に、自社が何をもって「引用された」とみなすかを決めておく必要がある。

「引用が増えた」と言うためには、まず「引用」の定義を先に固定する必要がある。定義を後回しにしたまま実装を進めると、あとで「結局何を比較すればいいのか」という壁に必ずぶつかる。

これはAIサービスごとに出典表示の仕様が違うためだ。回答文中に参照元のURLをそのまま表示するサービスもあれば、ドメイン名だけを示すもの、出典を一切明示せず情報だけを回答に取り込むものまで、挙動が混在している。同じ基準で数えなければ、実装前後の差分を測ること自体ができない。

具体的には、対象とするAIサービスごとに「引用された」の基準を決めておくとよい。たとえば回答内に自社URLがそのまま出典として表示された回数、出典表示はなくても自社のサービス名・ドメイン名が回答文中に言及された回数、といった具合に、サービスごとに数え方を分けて設計する。1つの共通指標に無理にまとめようとすると、どのAIサービスの何が効いたのかが分からなくなる。

ただし例外もある。同じプロンプトでも、AI側の回答は日によって変動する。プロンプトを変えるだけで結果が大きく変わることもあるため、同一プロンプト・同一条件で継続的に観測しない限り、「実装が効いた」のか「AI側のゆらぎ」なのかを区別できない。この観測の具体的な設計（プロンプトの固定方法、記録項目、実装前後の比較期間の区切り方）は、内容が独立した別記事で扱う。

よくある質問

まとめ

FAQPage・HowToの構造化データは、AIに「答えの場所」を伝えるための標識であって、答えの質そのものや、検索・引用での優先順位を保証するものではない。この違いを理解せずに実装だけを進めると、変化がないときに何を疑えばいいのか分からなくなる。

参考となる公式情報・公的相談先

• Google検索セントラル「構造化データに関するガイドライン」
• schema.org「FAQPage」
• schema.org「HowTo」

本記事の情報について

本記事は、schema.orgおよびGoogle検索セントラルの公開情報をもとに、構造化データとAI検索の関係について仕組みの観点から整理したものです。AI検索エンジンの生成アルゴリズムは各社非公開であり、実装効果を定量的に保証するものではありません。記載内容は執筆時点のものであり、各AIサービスの仕様は変更される場合があります。