FAQスキーマはAIO対策に効く？リッチリザルト終了後の扱いと、正しい実装方法【2026年最新】

「AIO対策として、FAQスキーマを実装しましょう」。AI検索への対策を調べていると、かなりの頻度で目にする施策ではないでしょうか。バクリにも、「FAQスキーマは入れたほうがいいのか」という相談がたびたび寄せられます。

ところが2026年5月、GoogleはFAQのリッチリザルト（検索結果に質問と回答が展開表示される機能）の表示を終了しました。加えて、構造化データを追加したページでもAIでの引用はほとんど増えなかった、という調査結果も公表されています。これまで「やっておくべき」とされてきた施策の前提が、短いあいだに大きく揺らいでいます。

では、FAQスキーマはもう実装しなくていいのか。すでに入れてあるものは外すべきなのか。本記事では、2026年に起きた変化と最新データを整理したうえで、FAQスキーマの現在の位置づけ、既存のスキーマの扱い、正しい実装方法、そしてスキーマより効果が期待できる「本文のFAQ」の作り方までを順に解説します。社内で方針を説明する立場の方にも、判断の材料としてご活用ください。

まずは自社のAI検索対策状況を無料で診断しませんか？

バクリ株式会社の「無料AIOアセスメント」では、ChatGPT・Gemini・Perplexityにおける自社の引用状況と改善ポイントを10分で可視化します。

【お知らせ】4月17日（金）に弊社代表荒川が書籍を発売しました！
AI時代を勝ち抜く最先端のノウハウをまとめた書籍『海外の先行事例に学ぶ AI検索最適化（AIO/AISEO/LLMO）実践ガイド』（著者：弊社代表取締役 荒川 大史）が、4月17日（金）よりKindleストアにて配信開始しました。

これからのビジネス戦略にぜひお役立てください！

1. FAQスキーマ（FAQPage）とは？AIO対策との関係

1-1. FAQスキーマの定義

FAQスキーマとは、ページに掲載している「よくある質問」とその回答を、検索エンジンなどの機械が読み取りやすい形で記述した構造化データのことです。構造化データというのは、ページの内容を決められた語彙と書式で整理し、機械に意味を伝えるための情報を指します。FAQスキーマの場合はSchema.orgで定められた「FAQPage」という型を使い、一般にJSON-LDという形式（データを記述するための書式の一つ）でページのHTMLに埋め込みます。

構造化データは、ページの見た目には表示されません。人間の読者が読むのはあくまで本文で、構造化データは機械に向けて本文の内容を整理して伝えるためのものだからです。たとえるなら、本文が「お客様に渡すパンフレット」だとすると、構造化データは「その中身を項目ごとにまとめた管理表」のような位置づけになります。

ここでよくある誤解が、「スキーマを書けば、本文にないことも検索エンジンに伝えられる」という考え方です。実際には、構造化データは本文に書かれている内容を整理して添えるもので、本文の代わりにはなりません。この前提は、4章の「本文のFAQ」や7章の注意点の話にもつながってくるので、最初に押さえておいてください。

1-2. FAQリッチリザルトとの関係

これまでFAQスキーマが広く実装されてきた最大の理由は、Googleの検索結果に「FAQリッチリザルト」が表示されることでした。リッチリザルトとは、通常のタイトルと説明文に加えて、追加の情報が装飾つきで表示される検索結果のことです。FAQの場合は、検索結果のページの説明文の下に質問と回答が展開できる形で並び、検索結果の中で目立つ効果がありました。

表示される面積が広がれば、ほかのページより目に留まりやすくなります。そのため、本文にFAQを設けたらスキーマもセットで入れる、という運用が多くのサイトで定着していきました。実際、担当者の方と話していると、FAQスキーマを「検索結果で目立たせるための施策」として理解しているケースが少なくありません。

裏を返せば、FAQスキーマの価値の大部分は、このリッチリザルトに支えられていたことになります。しかし2章で詳しく見るとおり、このリッチリザルトは2026年5月に終了しました。目に見える効果がなくなった今、FAQスキーマに何が残っているのかを考え直す必要が出てきたわけです。

1-3. AIO対策との関係

AI OverviewやChatGPTなど、AI検索全体で自社が引用・紹介される状態をつくる取り組みがAIOです。バクリでは、AIOを以下のように定義しています。

AIOの定義
主な対象：AI Overview＋各種生成AI（AI検索全般）
目的：AI Overview対策とLLM対策（その他AI対策）を合わせた総称。AI検索全体で引用・紹介される状態をつくること

FAQスキーマは、「AIが質問と回答の組み合わせを読み取りやすくなる」という理由から、AIO対策の施策として紹介されてきました。質問と回答が機械向けに整理されていれば、AIが「この質問への答えはこれだ」と判断しやすくなるはずだ、という考え方です。理屈としてはわかりやすく、リッチリザルトが終了したあとも「AIのために入れておくべき」という説明が残っているのは、このためでしょう。

ただ、理屈として筋が通っていることと、実際に引用が増えることは別の話です。たとえば、BtoBのマーケティング担当者が上司から「FAQスキーマを入れたらAIに載るのか」と聞かれたとき、根拠を示せなければ工数を確保する判断はしにくいはずです。そこで3章では、Googleの見解と公表されたデータをもとに、FAQスキーマがAIOにどの程度効くのかを検証していきます。

2. 2026年5月、FAQスキーマによるGoogleのリッチリザルトは終了した

2-1. 終了までの経緯

FAQリッチリザルトの終了は、突然の出来事ではありません。段階的に縮小されてきた流れを時系列で並べると、次のようになります。

時期	出来事
2023年8月	FAQリッチリザルトの表示が、信頼性の高い政府・健康関連のサイトに限定される
2026年5月7日	Google検索でのFAQリッチリザルトの表示を終了
2026年5月8日	Googleがドキュメントに終了を告知
2026年6月15日	FAQリッチリザルトのドキュメントを削除

表を見るとわかるように、最初の大きな変化は2023年8月でした。この時点で表示対象が信頼性の高い政府・健康関連のサイトに限定されたため、多くのサイトでは、すでにFAQリッチリザルトは表示されていなかったのです。2026年の終了は、それを全サイトに広げた最終段階と言えます。

もう一つ目を向けておきたいのは、表示の終了、ドキュメントでの告知、ドキュメントの削除と、手続きが段階的に進んでいる点です。告知は表示が終わった翌日だったので、検索結果の変化に先に気づいた担当者の方もいたかもしれません。

現場でよく相談されるのが、「FAQの表示が消えた気がするが、サイトの不具合だろうか」というものです。2023年以降の経緯を知っていれば、これはサイト側の問題ではなく、Google側の変更によるものだと判断できます。社内で説明を求められたときも、この年表を示せば話が通りやすくなるでしょう。

2-2. FAQスキーマは「無効」になったわけではない

ここで注意したいのは、終了したのはGoogleの検索結果でのリッチリザルトの表示だという点です。FAQPageという型自体は、Schema.orgの仕様として引き続き存在しています。ページにFAQスキーマが残っていても、それによってGoogle検索で不利になることはありません。

「リッチリザルト終了」というニュースだけが広まると、「FAQスキーマは使えなくなった」「入れたままだと評価が下がるのでは」と受け止められがちです。実際、終了の告知のあと、既存のスキーマを急いで削除すべきかという相談をいただくことがありました。とはいえ、終わったのはあくまでGoogle検索での表示機能で、構造化データの書き方そのものが否定されたわけではないのです。

この区別がついていないと、判断を誤りやすくなります。たとえば、自社サイトの全ページからFAQスキーマを外す作業に時間をかけたものの、その間に本文の改善が止まってしまう、というケースです。表示は終わったが型は生きている、という整理を押さえておけば、5章で扱う「削除・維持・新規実装」の判断も落ち着いて進められるはずです。

2-3. HowToのリッチリザルトも先に終了している

手順を構造化するHowToのリッチリザルトも、FAQより先に、2023年に表示が終了しています。HowToは、作業の手順を構造化データで記述し、検索結果に手順を並べて見せるためのものでした。質問と回答、手順といった「説明型」のリッチリザルトは、検索結果からなくなる流れにあると見てよいでしょう。

一方で、すべての構造化データが対象外になったわけではありません。商品、レビュー、記事、パンくずリストなどの構造化データは、引き続きGoogleのリッチリザルトの対象です。ECサイトの商品ページや、メディアの記事ページなどでは、今もリッチリザルトの対象として意味を持っています。

ここから読み取れるのは、「構造化データはもう不要」とひとくくりにするのは早計だということです。たとえば、ECサイトの運営担当者がFAQリッチリザルト終了のニュースを見て、商品ページの構造化データまで外してしまうと、まだ有効なリッチリザルトの機会を自分から手放すことになりかねません。型ごとに状況が違うことを踏まえ、自社のサイトでどの型を使っているのかを一度棚卸ししておくと安心です。

3. FAQスキーマはAIOに効くのか｜Googleの見解と最新データ

3-1. Googleの見解｜生成AI機能に構造化データは必要ない

Googleは2026年に公開した生成AI機能向けの公式ガイドで、生成AI検索のために構造化データは必須ではなく、特別なschema.orgのマークアップを追加する必要もないと明記しています。

同じくGoogleの「AI機能とウェブサイト」のページでも、AI OverviewやAIモードに表示されるための条件は、ページがインデックスされ、スニペット付きで検索結果に表示できる状態であることだけだと説明されています。AI専用の構造化データは不要というわけです。インデックスとはGoogleがページを読み込んで登録すること、スニペットは検索結果に表示される説明文のことを指します。つまり、通常の検索結果に問題なく表示されているページであれば、AI機能に載るための前提はすでに満たしていることになります。

ただしGoogleは、構造化データはリッチリザルトの対象になるために、SEO全体の一部として使い続けるのがよいとも述べています。ここは読み飛ばされやすいところです。「AIには不要」という部分だけを切り取ると構造化データ全体を軽く見てしまいがちですが、Googleの立場は、AIのために特別なことはしなくてよい、通常のSEOとしては構造化データを活用してよい、という二つを併せたものだと読むのが自然でしょう。

3-2. Ahrefsの調査｜構造化データを追加しても引用は増えなかった

Ahrefsは2026年5月、2025年8月〜2026年3月の間にJSON-LDの構造化データを新たに追加した1,885ページを追跡した結果を公表しました。追加しなかった比較対象のページを用意し、追加前後30日間のAIでの引用数の変化を比べるという方法です。比較対象を置いているので、検索環境全体の変化の影響をある程度切り分けられる設計になっています。

AIサービス	引用数の変化（比較対象との差）	判定
AI Overview	−4.6%	統計的に有意な減少
AIモード	+2.4%	誤差の範囲
ChatGPT	+2.2%	誤差の範囲

結果を見ると、構造化データを追加しても、AIでの引用が増えたという結果は得られませんでした。AIモードとChatGPTはわずかにプラスですが、いずれも誤差の範囲です。AI Overviewでは統計的に有意な減少が出ていますが、この小さな減少についても、Ahrefsは構造化データが原因とは断定できないとしています。「減ったのだから外したほうがいい」と読むのは行き過ぎでしょう。

一方で、この調査にはいくつかの限界があります。まず、対象はすでにAI Overviewで多く引用されていたページに限られており、まだ引用されていないページへの効果は検証されていません。次に、FAQPageだけでなく、Article、Productなど複数の型をまとめて分析しているため、FAQスキーマ単体の効果を示したものとは言えません。さらに、追加後の観察期間は30日間で、それより長い期間でどうなるかはこの調査からはわかりません。

それでも、「FAQスキーマを入れればAIに引用される」という説明には、少なくとも現時点で十分な根拠がないと言えます。

3-3. Microsoft Bingの見解｜LLMの理解に役立つ

一方で、別の見解もあります。Microsoft BingのFabrice Canel氏は、2025年3月にドイツで開かれたSMX Munich（検索マーケティングのカンファレンス）で、スキーママークアップがMicrosoftの大規模言語モデルによるコンテンツの理解に役立っていると述べました。大規模言語モデル（LLM）とは、文章を理解したり生成したりする生成AIの土台となる技術のことです。

この発言からは、Microsoft CopilotなどBingを使うAIサービスでは、構造化データが何らかの形で使われている可能性があると考えられます。Googleが「生成AI機能に構造化データは不要」としているのとは、少し温度感の違う見解と言えるでしょう。

ただし、注意して読みたいのは、「理解に役立つ」ことと「引用されやすくなる」ことは同じではないという点です。それが引用のされやすさにどの程度影響するかは、公表されていません。たとえば社内の会議で「Bingはスキーマを使っていると言っているから、全ページに実装すべきだ」という意見が出たとしても、この発言だけでは工数をかける根拠として弱いはずです。とはいえ、スキーマを使う可能性のあるサービスが存在するという事実は、5章で見る「既存のスキーマを削除しなくてよい」という判断の裏付けの一つになります。

3-4. データから言えること

ここまで見てきた情報源の内容を、ひとつの表にまとめます。

情報源	内容
Google	生成AI機能に構造化データは不要。リッチリザルトのためには引き続き有効
Ahrefs	構造化データの追加で、AIでの引用は増えなかった
Microsoft Bing	スキーマはLLMの理解に役立っている

並べてみると、それぞれの見解は一見ばらばらに見えるかもしれません。けれども、よく読むと矛盾しているわけではないことがわかります。GoogleはAIのために特別な構造化データは要らないと言い、Ahrefsは追加しても引用は増えなかったというデータを示し、Bingは理解には役立っていると述べている。どれも、構造化データが引用を大きく左右するとは言っていない点で共通しているのです。

こうした情報を踏まえると、FAQスキーマは、AIでの引用を増やす「決め手」にはならないが、害もない。これが2026年10月時点での整理です。

実務に置き換えれば、FAQスキーマを「やれば成果が出る施策」として優先度を上げる理由は見当たらない一方、すでにあるものを慌てて外す理由もない、ということになります。では、AIOで成果を出すためには何に力を入れればよいのか。次の章では、AIが実際に読んでいる「本文」に目を向けていきます。

4. AIOに効くのはスキーマより「本文のFAQ」

4-1. AIが読んでいるのは本文

構造化データは、本文の内容を機械に向けて整理したものにすぎません。そのうえ、Ahrefsの調査記事では、主要なAIシステムが情報をリアルタイムに取得するとき、JSON-LDを読み取っていなかったという別の実験結果も紹介されています。AIが回答をつくるときの材料は、基本的にページの本文だということです。

この点は、FAQスキーマの位置づけを考えるうえで大きな意味を持ちます。スキーマにどれだけ丁寧に質問と回答を書いても、AIがその部分を読んでいなければ、引用の材料にはなりません。反対に、本文に明確な質問と回答が書かれていれば、スキーマがなくてもAIがそれを拾える余地は十分にあります。

たとえば、地方で整体院を営む方が「予約なしでも施術を受けられますか」という質問に答えたいとしましょう。この答えをスキーマの中にしか書いておらず、本文に載せていなければ、AIにも来院を検討している読者にも届きません（そもそも7章で見るとおり、本文にない内容をスキーマに書くこと自体が避けるべき書き方です）。本文のFAQに書いておけば、両方に届けられます。

だからこそ、FAQスキーマの有無より、本文にどんな質問と回答が書かれているかのほうが、AIOにとっては重要なのです。

4-2. 本文のFAQがAIOに役立つ理由

本文にFAQを設けることには、AIOの観点から見ていくつかの利点があります。

まず、質問と答えが1対1で明確になる点です。AIがある質問への答えを探すとき、見出しや段落が入り混じった長い文章よりも、「この問いにはこう答える」と区切られた部分のほうが、該当する箇所を見つけやすくなります。

次に、関連する問いをカバーできる点も見逃せません。AI Overviewは、入力された検索語だけでなく、関連する複数の問いの検索結果からも情報源を選んでいる可能性があります。本文の中で関連する質問に答えておけば、そうした問いへの答えとして引用される余地が広がるわけです。たとえば「FAQスキーマとは」と調べた人に対して、AIが「今も実装すべきか」という周辺の問いまで含めて回答をまとめる場面を想像すると、わかりやすいかもしれません。

そして、読者の疑問を先回りできることも利点の一つです。これはAIのためというより、読者のための改善と言えます。サービスページを読んだ人が「結局いくらかかるのか」「どこまで対応してくれるのか」と迷ったとき、その答えがページ内にあれば、問い合わせる前に不安を解消できます。結果として、Googleが重視する「人の役に立つコンテンツ」にもつながっていきます。

4-3. スキーマと本文のFAQの比較

ここまでの内容を、FAQスキーマと本文のFAQの違いとして整理すると、次のようになります。

観点	FAQスキーマ	本文のFAQ
読み手	機械（検索エンジン・一部のAI）	人とAIの両方
Googleのリッチリザルト	2026年5月に終了	関係なし
AIでの引用への効果	有意な増加は確認されていない	答えが明確なら引用の候補になる
実装の手間	JSON-LDの記述が必要	原稿を書くだけ

表で並べると、両者は役割の違うものだとはっきりします。FAQスキーマの読み手は検索エンジンや一部のAIといった機械に限られるのに対し、本文のFAQは人とAIの両方に読まれます。スキーマにとって大きな見返りだったGoogleのリッチリザルトはすでに終了しており、AIでの引用についても有意な増加は確認されていません。

もう一方の本文のFAQは、答えが明確であれば引用の候補になり、しかも原稿を書くだけで用意できます。限られた工数の中でどちらから手をつけるべきかと聞かれたら、本文のFAQから、と答えるのが妥当でしょう。

とはいえ、両者は対立するものでもありません。本文のFAQがしっかり書けていれば、それをもとにスキーマを生成することもできます。順番としては、まず本文を整え、余力があればスキーマを添える、という考え方が無理のない進め方です。この順番の感覚は、次の5章で既存スキーマの扱いを判断するときの土台にもなります。

5. 既存のFAQスキーマはどうする？削除・維持・新規実装の判断

5-1. 既存のFAQスキーマは削除しなくてよい

すでに実装しているFAQスキーマは、削除する必要はありません。2章で見たとおりGoogle検索で不利になることはなく、3章で触れたBingのように、構造化データを使う可能性のあるサービスもあるからです。削除の作業に時間を使うくらいなら、その時間を本文の改善に回したほうが得られるものは大きいでしょう。

現場でよく受けるのが、「使われていないコードを残しておくのは気持ちが悪い」という相談です。その感覚は理解できますが、FAQスキーマが本文と正しく対応している限り、残しておいてマイナスになる要素は見当たりません。むしろ、全ページを開いてスキーマを外し、表示に問題がないかを確かめる作業のほうが、手間がかかります。

ただし、例外もあります。本文のFAQと内容が食い違っているスキーマや、本文にないFAQを記述しているスキーマは、修正または削除してください（7章参照）。たとえば、料金を改定した際に本文だけを直し、スキーマには古い料金が残っているようなケースです。判断に迷ったら、ページの本文とスキーマの中身を並べて見比べ、一致しているかどうかを基準にするとよいでしょう。

5-2. 新規の実装は「手間がかからない範囲」で

これから新しいページにFAQを設ける場合、FAQスキーマの実装は手間がかからない範囲で行えば十分です。WordPressのSEOプラグインなどで、本文のFAQから自動的に生成できるなら、追加しておいて損はありません。本文と自動で連動していれば、食い違いが起きにくいという利点もあります。

逆に、FAQスキーマを手作業で全ページに実装するために工数を割くのは、費用対効果が見合わないでしょう。3章で見たとおり、構造化データの追加でAIでの引用が増えたというデータはなく、その工数を本文のFAQの質を上げることに使ったほうが、読者にもAIにも届きやすいからです。

判断に迷いやすいのは、「一部のページだけ手作業で入れるのはどうか」というケースです。たとえば、問い合わせの多い主力サービスのページにだけは入れておきたい、という場合が考えられます。そのページの本文のFAQがすでに十分に整っていて、更新のたびにスキーマも直す運用ができるのであれば、入れてもかまいません。ただ、更新を忘れて本文と食い違うおそれを抱えるくらいなら、無理に入れなくても困ることはない、というのが私たちの考えです。

5-3. 優先順位

ここまでの判断を、状況ごとに表にまとめました。自社のページがどれに当てはまるかを確認しながら読んでみてください。

状況	判断
既存のFAQスキーマが本文と一致している	そのまま維持
既存のFAQスキーマが本文と食い違っている	修正または削除
新規ページで、自動生成できる	実装してよい
新規ページで、手作業が必要	本文のFAQを優先し、スキーマは後回し

表の上半分は、既存のスキーマについての判断です。基準はシンプルで、本文と一致していれば維持し、食い違っていれば修正または削除します。ここで見るべきなのは、スキーマがあるかどうかより、本文と一致しているかどうか。この点さえ押さえておけば、大きく外すことはありません。

下半分は、新規ページについての判断になります。CMSやプラグインで自動生成できる環境なら実装してよく、手作業が必要なら本文のFAQを優先してスキーマは後回しにします。ここでいう後回しは「やらない」と決めることとは少し違い、本文が固まって運用に余裕ができたときに改めて検討する、という意味合いです。

たとえば、Web担当者が少なく、ほかの業務と兼任しているような会社であれば、手作業でのスキーマ実装はいったん見送り、本文のFAQの見直しに集中するのが現実的でしょう。

なお、構造化データ全体の実装方針（Article、Organization、Productなど）については、[構造化データのAIO実装に関する記事｜内部リンク先URL]で詳しく解説しています。

6. FAQスキーマの実装方法｜JSON-LDの書き方

6-1. 基本の構造

FAQスキーマは、入れ子になった構造で記述します。最初は記号が多くて戸惑うかもしれませんが、全体の型の中に質問の一覧があり、その一つひとつに答えがぶら下がっている、という関係さえつかめば難しくありません。要素を整理すると次のとおりです。

• 全体の型：FAQPage
• mainEntity：質問の一覧
• 各質問の型：Question（nameに質問文）
• 各質問の答え：acceptedAnswerにAnswerの型を入れ、textに回答文

まず、ページ全体が「FAQのページである」ことを示すのがFAQPageです。その中のmainEntityに、質問を並べていきます。各質問はQuestionという型で表し、nameに質問文を入れます。そして、その質問への答えをacceptedAnswerの中にAnswerという型で入れ、textに回答文を書く、という流れです。

初めて書く方がつまずきやすいのは、acceptedAnswerの中にさらに型を指定する部分でしょう。質問の中に答えが入り、その答えにも型がある、という二重の構造になっているため、括弧の閉じ忘れが起きやすいのです。次の記述例で、どの括弧がどこに対応しているかを確認しながら読むと理解しやすくなります。

また、ここで書く質問文と回答文は、本文に表示されているものと同じ内容にしておくことが前提になります。この点は7章で改めて取り上げます。

6-2. JSON-LDの記述例

基本の構造を踏まえて、実際のJSON-LDの記述例を見てみましょう。ここでは、問い合わせを受け付けるサービスのページに、質問を二つ載せる場合を想定しています。

<script type=”application/ld+json”>
{
  “@context”: “https://schema.org”,
  “@type”: “FAQPage”,
  “mainEntity”: [
    {
      “@type”: “Question”,
      “name”: “見積もりは無料ですか？”,
      “acceptedAnswer”: {
        “@type”: “Answer”,
        “text”: “はい、無料です。現地調査が必要な場合も費用はかかりません。”
      }
    },
    {
      “@type”: “Question”,
      “name”: “最短でいつから対応できますか？”,
      “acceptedAnswer”: {
        “@type”: “Answer”,
        “text”: “お問い合わせから3営業日以内に対応できます。繁忙期は前後する場合があります。”
      }
    }
  ]
}
</script>

記述例の中で、”@type”: “Question”から始まるまとまりが、質問一つ分にあたります。質問を増やしたいときは、このまとまりを丸ごと複製し、カンマで区切ってmainEntityの角括弧の中に並べていきます。最後のまとまりの後ろにはカンマを付けない、という点も忘れないようにしてください。カンマの過不足は、よくあるつまずきの一つです。

回答文の書き方にも目を向けてみてください。どちらの回答も、1文目で結論を示し、2文目で条件や例外を補っています。これは8章で説明する本文のFAQの書き方と同じ形です。スキーマの回答文は本文と一致させるのが前提なので、本文のFAQを結論から書いておけば、スキーマの回答文も自然とわかりやすくなります。

実際に使うときは、質問文と回答文を自社のFAQの内容に差し替えてください。記述例の文言を残したままにすると、本文と食い違う原因になるので注意が必要です。

6-3. 設置する場所

JSON-LDは、ページのHTMLの<head>内、または<body>内のどこに置いても構いません。ページの見た目には影響しないため、デザインが崩れる心配もありません。

自分でHTMLを編集できる環境なら、<head>内にまとめて置いておくと、あとから探しやすくなります。ただし、記事ごとに内容が変わるFAQスキーマを、すべてのページに共通するテンプレートに書いてしまうと、どのページにも同じFAQが出力されてしまいます。これは7章で触れる「使い回し」の状態にあたるため、避けたいところです。

WordPressなどのCMSを使っている場合は、SEOプラグインの機能や、FAQブロックの機能で自動的に出力されることもあります。この場合、自分で書き足す前に、すでに出力されていないかを確かめておくことが大切です。プラグインとテーマの両方がFAQスキーマを出力していて、同じ内容が二重に記述されている、というケースもあります。ブラウザでページのソースを表示し、「FAQPage」で検索してみると、どこから出力されているかの手がかりがつかめるはずです。

6-4. 検証方法

FAQは2026年にGoogleのリッチリザルトの対象から外れたため、記述が正しいかの確認には、Schema.orgが提供するSchema Markup Validatorを使います。構文の誤りや、必須のプロパティの抜けがないかを確認できるツールです。プロパティとは、nameやtextのように、型の中に入れる項目のことを指します。

使い方は難しくありません。検証したいページのURLか、JSON-LDのコードを入力すると、読み取られた型と項目が一覧で表示されます。そこで確認したいのは、FAQPageの中に意図したとおりの質問が並んでいるか、それぞれに回答が入っているか、エラーや警告が出ていないか、といった点です。

これまでリッチリザルトの確認を習慣にしていた方ほど、以前と同じ手順で検証しようとして迷うことがあるかもしれません。FAQはもうGoogleのリッチリザルトの対象外なので、構文の確認はSchema Markup Validatorで行う、と頭を切り替えておくと混乱せずに済みます。

検証は実装した直後だけでなく、本文のFAQを更新したときにも行っておくと安心です。7章で触れるように、本文とスキーマの食い違いは更新のタイミングで起きやすいからです。

7. FAQスキーマを実装するときの注意点

7-1. 本文に表示されている内容と一致させる

Googleの構造化データの一般的なガイドラインでは、ページの読者に表示されていない内容を構造化データでマークアップしてはいけないとされています。FAQスキーマに書く質問と回答は、本文に表示されているものと一致させてください。

なぜこの決まりがあるのかを考えると、構造化データの役割がよくわかります。1章で触れたとおり、構造化データは本文の内容を機械に向けて整理して伝えるためのものです。本文にない情報を構造化データにだけ書くと、機械には伝わっていても人間の読者には見えない、という状態になります。検索エンジンの側から見れば、読者が確認できない情報で検索結果に影響を与えようとしている、と受け取られかねません。

たとえば、一部の質問だけを本文に載せ、スキーマにはもっと多くの質問を書いておく、というケースを見かけることがあります。「機械にはたくさん伝えておいたほうが有利だろう」という発想かもしれませんが、これはガイドラインに反する書き方です。また、本文の回答を要約してスキーマに書いた場合も、意味が変わっていないかは確かめておく必要があるでしょう。迷ったときは、スキーマの質問と回答は本文からそのまま写す、というルールにしておけば悩まずに済みます。

7-2. 回答に広告的な文言を入れない

回答の中に、過度な宣伝文句や問い合わせへの誘導だけを書くのは避けたいところです。質問に対して、事実にもとづいて端的に答えることが基本になります。

FAQはもともと、読者が抱く疑問に答えるための場所です。ところが営業的な意図が強くなると、「詳しくはお問い合わせください」「多くのお客様にご満足いただいています」といった回答になりがちです。読者からすれば、質問への答えが得られないまま問い合わせを促されることになり、かえって不信感につながりかねません。

AIの側から見ても、答えのない回答は使いどころがありません。「見積もりは無料ですか」という質問に「お気軽にご相談ください」とだけ書かれていても、それを質問への答えとして引用するのは難しいからです。

もちろん、FAQの最後に問い合わせ先を案内すること自体が悪いわけではありません。たとえば、まず「はい、無料です」と答えたうえで、「現地調査の日程はお問い合わせの際に調整します」と続けるように、答えを先に示し、案内は補足として添える順番を意識すると、読者にとっても自然な流れになります。広告的な文言を入れたくなったときは、その一文が質問への答えになっているかを自問してみてください。

7-3. 同じFAQを複数のページに使い回さない

サイト全体で共通のFAQを、すべてのページに同じ内容で記述するのは避けてください。そのページの内容に関係する質問と回答に絞るのが原則です。

こうした使い回しが起きやすいのは、FAQスキーマをテンプレートやフッターに組み込んでいるケースです。たとえば、会社概要や支払い方法に関するFAQを、サイト全体のテンプレートにまとめて入れてしまうと、商品ページにもコラム記事にも同じFAQスキーマが出力されます。担当者にそのつもりがなくても、仕組みの上で使い回しの状態になってしまうわけです。

同じ質問と回答があちこちのページに並んでいると、そのFAQがどのページの内容を説明しているのかが曖昧になります。読者にとっても、記事を読みに来たのに、関係のない支払い方法の説明が出てくるのは親切とは言えないでしょう。

対処としては、共通のFAQは「よくある質問」の専用ページにまとめ、各ページにはそのページのテーマに直接関係する質問だけを置くと、すっきり整理できます。たとえばリフォーム会社のサイトなら、キッチンの施工事例のページにはキッチンに関する質問を、浴室のページには浴室に関する質問を置く、という分け方です。こうしておけば、ページごとのFAQが本文の内容と自然に結びつきます。

7-4. ユーザーが投稿・回答する形式はFAQPageではない

ユーザーが質問を投稿し、複数の人が回答するQ&Aサイトのようなページは、FAQPageではなく、QAPageという別の型の対象です。FAQPageは、サイトの運営者が質問と回答の両方を書くページに使います。

両者の違いは、「誰が書いているか」と「答えがいくつあるか」で考えるとわかりやすいでしょう。FAQPageでは、運営者が質問を用意し、それに対する公式の答えを一つずつ示します。一方のQ&Aサイトでは、ひとつの質問に対して複数のユーザーから異なる答えが寄せられ、その中から役に立つものが選ばれていく形になります。

判断に迷いやすいのは、ユーザーから寄せられた質問に運営者が回答し、それを掲載しているページです。たとえば、問い合わせフォームに届いた質問を選び、運営者が答えを書いてFAQとして公開している場合、質問の出どころはユーザーでも、質問と回答をまとめて掲載しているのは運営者です。この場合は、FAQPageとして扱うのが自然と考えられます。

反対に、会員が自由に質問を投稿し、ほかの会員が回答するコミュニティ機能を持つページなら、QAPageの対象です。自社サイトにどちらの形式のページがあるのかを、実装の前に確認しておくとよいでしょう。

7-5. 本文のFAQを更新したら、スキーマも更新する

料金や対応範囲などを変更したとき、本文のFAQだけを直して、スキーマの更新を忘れるケースはよくあります。手作業で管理している場合は、とくに注意が必要です。

このつまずきが起きるのは、本文とスキーマが別々の場所で管理されているからです。本文は記事の編集画面で直せますが、スキーマはHTMLのソースやプラグインの設定画面など、普段あまり開かない場所に書かれていることが少なくありません。担当者が替わったときに、スキーマの存在自体が引き継がれていない、ということも起こりえます。

その結果、本文では新しい料金を案内しているのに、スキーマには古い料金が残っている、という食い違いが生まれます。これは7-1で見た「本文と一致させる」という原則に反する状態です。

防ぐ方法として現実的なのは、CMSで本文から自動生成できる仕組みにしておくことです。そうすれば、本文を直すだけでスキーマも追従するため、食い違いを防げます。手作業での管理を続ける場合は、FAQを更新する際の手順書に「スキーマも確認する」という一行を加えておくと、担当者が替わっても抜け漏れが起きにくくなるでしょう。6章で紹介した検証ツールで、更新後の内容を確かめる習慣もあわせて持っておきたいところです。

8. AIOに効く本文のFAQの作り方

8-1. 質問の選び方

FAQに載せる質問は、想像で作るのではなく、実際に寄せられている質問から選びます。想像で作った質問は書き手が答えやすいものに偏りがちで、読者が本当に知りたいこととずれてしまうからです。

拾い方としては、主に三つの情報源があります。一つめは、問い合わせや営業の現場でよく聞かれる質問です。営業担当者やカスタマーサポートの方に「最近よく聞かれることは何か」と尋ねるだけでも、FAQの候補はかなり集まります。二つめは、Search Consoleで、そのページに流入している質問形式のクエリです。検索パフォーマンスのレポートで「〜とは」「〜できる？」のような問いかけの形の検索語を探すと、読者がどんな疑問を持ってページに来ているのかが見えてきます。

三つめは、生成AIにそのページのテーマについて質問したとき、関連して出てくる問いです。これはAIOならではの視点と言えます。AIに「〇〇について知りたい」と聞き、回答の中で触れられている論点や、続けて聞かれそうな問いを拾うと、関連する問いをカバーしやすくなります。4章で触れた「関連する問いへの答えとして引用される余地」を広げるための作業です。

三つの情報源のうち、どれか一つに頼るより、組み合わせて使うほうが漏れは少なくなります。現場の声で読者の本音を、検索語で検索時点の疑問を、AIで周辺の論点を拾う、というように役割を分けて考えるとよいでしょう。

8-2. 回答の書き方

回答は、1文目で結論を言い切るのが基本です。「はい、無料です」「〇〇の場合は対応できません」のように、質問に対する答えを最初の一文で示します。そのうえで、2文目以降に例外や数字、手順といった条件や補足を書いていきます。

もう一つ意識したいのが、1つの回答で1つの質問に答えることです。たとえば「料金はいくらですか」という質問の回答に、支払い方法や納期の話まで混ぜてしまうと、どの部分が料金の答えなのかがわかりにくくなります。複数の論点がある場合は、質問を分けたほうが読みやすくなるでしょう。

なぜ結論を先に書くのがよいのか。AIが回答を組み立てるとき、1文目で結論が示されている回答は、そのまま答えとして使いやすくなるからです。前置きが長く、結論が段落の最後に出てくるような回答だと、どの部分が答えなのかを見極めにくくなります。

よくあるのが、「〜については、お客様の状況によってさまざまですが」と前置きから入る書き方です。丁寧に書こうとするほどこうなりがちですが、読者にとっても答えにたどり着くまでが遠く感じられます。書き終えたら、1文目だけを読んで質問に答えられているかを確かめてみてください。

8-3. 配置と数

FAQは、記事やサービスページの末尾にまとめて置くのが一般的です。本文を読み終えた読者が、残った疑問を確認する場所として機能するからです。サービスページであれば、料金や流れの説明を読んだあと、問い合わせボタンの手前にFAQがあると、迷っている読者の背中を押す役割も果たしてくれます。

数は、そのページに本当に必要な質問に絞ります。数を増やすことが目的になると、内容の薄い質問が混ざり、かえってページの質を下げることになりかねません。たとえば「AIに引用されやすくするために、とにかく質問を増やそう」と考え、答えが一言で終わる質問や、本文の繰り返しにすぎない質問を並べてしまうケースです。読者はスクロールしても新しい情報に出会えず、途中で読むのをやめてしまうかもしれません。

判断の目安としては、その質問を削ったときに困る読者がいるかどうかを考えてみるとよいでしょう。実際に問い合わせで聞かれている質問であれば、削ると同じ問い合わせが続くことになります。一方、書き手が「念のため」と足した質問は、削っても困る人がいないことが多いものです。そうした質問を外していくと、自然とそのページに合った数に落ち着きます。

8-4. 一次情報を入れる

「料金はいくらですか」に「ケースによって異なります」とだけ答えるFAQは、AIにも読者にも役に立ちません。読者は目安を知りたくて質問しているのに、答えが得られないからです。AIにとっても、具体的な情報のない回答をわざわざ引用する理由は見当たりません。

そこで回答には、具体的な料金の目安、対応した件数、よくある失敗と防ぎ方など、自社だからこそ書ける情報を入れてください。たとえば工務店のサイトなら、「費用は工事の範囲によって変わりますが、よくご依頼いただく内容ではこのくらいが目安です」と、幅を持たせながらも目安を示すだけで、回答の価値は大きく変わります。料金を出しにくい業種でも、どのような条件で金額が変わるのかを説明すれば、読者は自分のケースに当てはめて考えられるでしょう。

Googleは、独自で有用なコンテンツが生成AI機能での露出に最も長期的な影響を与えると述べています。一次情報、つまり自社が実際に経験したり持っていたりする情報は、他社のページには書かれていないものです。FAQは短い文章の積み重ねですが、だからこそ一つひとつの回答に自社ならではの情報が入っているかどうかで、ページ全体の価値に差が出ます。

9. FAQスキーマとFAQのAIOへの効果を確かめる方法

9-1. 比較対象を置いて確かめる

FAQスキーマや本文のFAQが、自社サイトで効果があるかを確かめるには、施策を行うページと行わないページを分けて比べる方法が確実です。Ahrefsも、スキーマの効果を自社で検証する方法として、追加するページと追加しないページを用意し、30日後に比較することを提案しています。3章で紹介したAhrefsの調査と同じ考え方を、自社サイトに当てはめるわけです。

全ページに一斉に実装してしまうと、変化がFAQによるものか、検索環境全体の変化によるものかが判断できません。AI検索での引用は、こちらが何もしていなくても増えたり減ったりすることがあるため、比べる相手がいないと施策の効果を切り分けられないのです。

進め方としては、テーマや流入の規模が近いページをいくつか選び、片方のグループにだけ施策を行います。たとえば、サービス紹介のページが複数あるなら、その一部にだけ本文のFAQを追加し、残りはそのままにしておく、という分け方です。比較するときは、施策を行う前の状態も記録しておくと、変化を読み取りやすくなります。

ありがちな失敗は、比較の途中で対照側のページにも手を入れてしまうことです。比較の期間中は、対照側のページをできるだけ触らずにおくことを、関係者のあいだで共有しておきましょう。

9-2. 見る指標

比較の際に見る指標と、その確認方法を表にまとめました。

指標	確認方法
AIでの言及・引用	FAQに関係する質問をAIに定期的に投げて記録する
生成AI機能での表示回数	Search Console（生成AIパフォーマンスレポート）
ページのクリック数・クリック率	Search Console
問い合わせ前の質問の減少	問い合わせ内容の記録

AIでの言及・引用は、FAQに関係する質問をAIに定期的に投げ、自社が触れられたかどうかを記録していきます。同じ質問を同じ間隔で続けると、変化を追いやすくなります。生成AI機能での表示回数や、ページのクリック数・クリック率は、Search Consoleで確認できます。

最後の項目は見落とされがちですが、本文のFAQが読者の疑問を解消していれば、同じ質問の問い合わせが減るはずです。これはAIOとは別の、FAQ本来の成果と言えます。たとえば、FAQに支払い方法の説明を追加したあと、支払い方法についての問い合わせが落ち着いてきたなら、そのFAQは役割を果たしていると判断できるでしょう。営業やサポートの担当者に問い合わせの内容を記録してもらう仕組みがあると、この変化を捉えやすくなります。

バクリでは、AI検索での引用状況の可視化から、FAQを含むコンテンツの改善、効果の検証までを一貫して支援しています。

10. FAQスキーマとAIOに関するよくある質問

Q1. FAQのリッチリザルトは、もう表示されないのですか？

表示されません。Googleは2026年5月7日で、Google検索でのFAQリッチリザルトの表示を終了しました。ただ、2023年8月以降はすでに政府・健康関連の一部のサイトに限定されていたため、多くのサイトにとっては、以前から表示されない状態が続いていたことになります。なお、終了したのは検索結果での表示で、FAQPageという型自体はSchema.orgの仕様として引き続き存在しています。

Q2. 既存のFAQスキーマは削除したほうがよいですか？

削除する必要はありません。Google検索で不利になることはなく、Bingのようにスキーマを理解に使っているサービスもあるため、ほかのサービスで使われる可能性もあります。削除に時間をかけるより、本文のFAQの改善に時間を使うほうが得策でしょう。ただし、本文と内容が食い違っているものや、本文にないFAQを記述しているものは、修正または削除してください。

Q3. FAQスキーマを入れると、AI Overviewに引用されやすくなりますか？

現時点で、その根拠は十分ではありません。Googleは生成AI機能のために構造化データは必要ないとしており、Ahrefsが1,885ページを追跡した調査でも、構造化データの追加による引用の有意な増加は見られませんでした。ただしこの調査は、すでに引用の多いページを対象に、複数の型をまとめて分析したものです。引用を増やしたいなら、まず本文のFAQの質を高めることをおすすめします。

Q4. ChatGPTはFAQスキーマを読んでいますか？

OpenAIは公式には説明していません。Ahrefsの調査では、ChatGPTでの引用に、構造化データの追加による有意な変化は見られませんでした（比較対象との差は誤差の範囲）。また同じAhrefsの記事では、主要なAIシステムが情報をリアルタイムに取得する際にJSON-LDを読み取っていなかった、という別の実験結果も紹介されています。ChatGPTを意識するなら、本文の書き方を優先するのが現実的でしょう。

Q5. FAQは何問くらい載せればよいですか？

決まった数はありません。問い合わせや営業の現場で実際に聞かれる質問から、そのページに本当に必要なものに絞ってください。数を増やすことを目的にすると、内容の薄い質問が混ざりやすくなり、かえってページの質を下げかねません。迷ったときは、その質問を削ったら困る読者がいるかどうかを考えてみると、載せるべき質問を見極めやすくなります。

11. まとめ｜FAQスキーマより、本文のFAQの質がAIOを左右する

FAQスキーマは、2026年5月のFAQリッチリザルトの終了で、Google検索での目に見える効果を失いました。構造化データを追加してもAIでの引用は増えなかったという調査もあり、「FAQスキーマを入れればAIに引用される」と言える根拠は今のところ見当たりません。既存のスキーマは本文と一致していれば維持し、新規は手間のかからない範囲で十分です。

力を入れるべきは本文のFAQです。まずは自社のサービスページのFAQを開き、「ケースによって異なります」で終わっている回答がないか確認するところから始めてみてはいかがでしょうか。

まずは自社のAI検索対策状況を無料で診断しませんか？

バクリ株式会社の「無料AIOアセスメント」では、ChatGPT・Gemini・Perplexityにおける自社の引用状況と改善ポイントを10分で可視化します。

【お知らせ】4月17日（金）に弊社代表荒川が書籍を発売しました！
AI時代を勝ち抜く最先端のノウハウをまとめた書籍『海外の先行事例に学ぶ AI検索最適化（AIO/AISEO/LLMO）実践ガイド』（著者：弊社代表取締役 荒川 大史）が、4月17日（金）よりKindleストアにて配信開始しました。

これからのビジネス戦略にぜひお役立てください！