QAPageとFAQPageの違い｜判定は2つの質問で決まる【図解】

「よくある質問のページに、構造化データを入れておいて」。そう頼まれて調べ始めた人が、最初に手を止める場所があります。QAPageとFAQPage。名前のよく似た型が、2つ並んで出てくるからです。

さらに調べると、FAQPageは「もう終わった」という話まで出てきます。では今から入れるのは無駄なのか。QAPageなら意味があるのか。ここで判断がつかなくなります。

この記事は、Q&AページやFAQページにマークアップを入れる直前で迷っている方に向けて書きました。2つの型の見分け方から、Google検索での現在地、そしてAI検索での効き目まで、公式ドキュメントで確認できたことだけを図解で並べます。

この記事は、Q&Aページの運用を担当するマーケティング部の2人と、専門家の会話をはさみながら進みます。ご自身に近い立場の人の質問から読んでいただいて構いません。

• 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
• 高梨課長（マーケ課長）— 「誰が、どれくらいの手間でやるんですか？」を聞く役
• 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役

01そもそもQAPageとFAQPageの違いって、AI対策の話とどう関係するんですか？

若葉さん

若葉さんの発言

よくある質問のページに構造化データを入れようとしたら、QAPageとFAQPageという型が2つ出てきました。どちらを選ぶかで、ずっと止まっています。

鈴木さん

鈴木さんの発言

そこはページの見た目ではなく、「答えを書いたのが誰か」で決まります。まず、そこだけ押さえてしまいましょう。

QAPageもFAQPageも、質問と回答を機械に伝えるための書式です。人が読む画面は、どちらも同じように見えます。分かれるのは、書かれている中身の出どころです。

利用者が投稿した質問と、それに寄せられた回答。これを示すのがQAPageです。サイト運営者が用意した一問一答。こちらを示すのがFAQPageでした。schema.orgの定義でも、前者は「特定の質問とその回答に焦点を当てたWebページ」、後者は「1つ以上のよくある質問を提示するWebページ」と説明されています。

ここがAI検索の話とどうつながるのか。先に結論を書いておきます。型の選択は、AIに引用されるかどうかとは別の問題です。 型えらびはGoogle検索の機能に効くもので、AI検索での引用は、後半で扱うとおり別の材料で判断します。

02QAPageとFAQPageの違いは、AI検索最適化の前にどこを見れば分かりますか？

若葉さん

若葉さんの発言

「答えを書いた人」で決まるのは分かりました。でも、うちのFAQページも読者の質問をもとに作っています。これは利用者が書いたことになりますか？

鈴木さん

鈴木さんの発言

そこは分かれ目です。元になった疑問が読者のものでも、文章を書いたのが運営者ならFAQPage側になります。基準は書き手ではなく、「送信できるか」なんですよ。

Googleは、QAPageを使ってよいページとそうでないページを、具体例つきで示しています。使ってよいのは、1つの質問に複数の利用者が回答を投稿できるフォーラムのページや、製品サポートのページです。

使ってはいけない例も明記されています。サイト運営者が作成し、利用者が他の回答を送信できないFAQページには、QAPageマークアップを使用しません。 ここは表現があいまいなのではなく、公式ガイドラインにそのまま書かれている一文です。

見落とされやすい条件が、もう1つあります。質問の数です。QAPageが対象とするのは、1ページにつき1つの質問と、その回答群だけです。複数の質問を投稿できるページ、ハウツーガイド、Q&A形式のブログ記事は、どれも対象から外れます。

03QAPageとFAQPageは、AI検索対策の現場でどれくらい使われているんですか？

使われている広さにも、はっきりした差があります。schema.orgの集計では、FAQPageは全世界で100万〜1,000万ドメインに実装されています。対してQAPageは、1万〜10万ドメインにとどまります（2026年7月時点のGoogle集計値）。

差が生まれた理由は、対象の広さにあると考えられます。FAQPageは「サイトのFAQページ全般」に長く使われてきました。QAPageのほうは、はじめからフォーラムや製品サポートに用途が限られていたためです。

この差は、実務ではこう読みます。数が多いほうが正しい、という話ではありません。 自社のページがどちらの性質かで決まるだけで、多数派に合わせる理由はどこにもありません。

04なぜFAQPageのリッチリザルトは終わったの？AI検索の広がりと関係ある？

若葉さん

若葉さんの発言

そもそも、FAQPageが終わったというのは何が起きたんですか。ある日、急に消えたんでしょうか。

鈴木さん

鈴木さんの発言

いえ、段階を踏んで縮んでいきました。時系列で並べると、途中の判断が見えてきますよ。

FAQPageの表示は、いきなり消えたわけではありません。公式発表と更新履歴をたどると、いくつかの節目に分かれています。

最初の節目は2023年8月8日です。FAQPageのリッチリザルトが、よく知られていて信頼のおける政府ウェブサイトおよび医療ウェブサイトに限定されました。この時点で、一般企業のFAQページは表示の対象から外れています。

同じ流れで、2023年9月13日にはHowToのリッチリザルトがパソコンでも表示されなくなりました。実質的な全廃です。

そして2026年5月7日、FAQPageのリッチリザルトはGoogle検索の検索結果から完全に表示が終わりました。さらに2026年6月15日、Google検索セントラルはFAQPageのドキュメントページ自体を削除しています。

なお、この動きが「AI検索が広がったから」だと説明した公式情報は見当たりません。時期が重なっていることと、原因であることは別です。この記事では、確認できた事実の順番だけを並べています。

05QAPageだけが残ったのは、AI検索対策として何を意味しますか？

同じ期間に、QAPageは反対の扱いを受けています。2026年3月24日、ディスカッションフォーラムとQAページ向けに新しいプロパティが追加されました。ドキュメントも削除されず、維持と拡張の対象になっています。

現在Googleが公式に案内している構造化データの一覧、いわゆる検索ギャラリーにも、この差が出ています。FAQ（よくある質問）は掲載されていません。Q&Aは、独立した機能として載っています。

ここで混同されやすいのが、「Googleが表示をやめたこと」と「schema.orgがFAQPageという型をやめたこと」の区別です。この2つは別の出来事です。

schema.orgの語彙としてのFAQPageは、いまも存在します。非推奨（deprecated）の注記も付いていません。変わったのは、Google検索という1つの検索エンジンにおける表示の可否だけです。

Google自身も2023年8月の発表時点で、この点に触れています。構造化データを削除する必要はなく、使われていない構造化データが検索で問題を起こすこともない、という説明です。AI検索対策の観点で言えば、すでに書いてあるものを慌てて剥がす理由はないということになります。

06うちのページはQAPageを使えますか？AI対策として判定する順番は？

高梨課長

高梨課長の発言

判定の基準は分かってきました。ただ、うちにはサポートページもフォーラムも記事のFAQもあります。担当者が迷わず仕分けられる形にしたいのですが。

鈴木さん

鈴木さんの発言

2つの質問に順番に答えるだけで分かれます。順番が大事で、逆から見ると迷いますよ。

判定は、2段の絞り込みです。順番を守ると、ほとんどのページは迷わず片付きます。

1問目は「利用者が回答を追加投稿できるか」です。ここがいいえなら、QAPageは選べません。運営者だけが回答を書くページは、内容がどれだけQ&Aらしくても対象外になります。

2問目は「1つの質問とその回答群に絞られているか」です。1問目がはいでも、複数の質問が並ぶページはQAPageの対象になりません。

両方がはいのときだけ、QAPageの実装に進みます。片方でもいいえなら、そのページは対象外です。従来型のFAQページをQAPageに置き換える、という発想が成り立たないのは、この1問目で止まるからです。

07QAPageの実装は、AI検索最適化のついでにどこまで書けばいいですか？

高梨課長

高梨課長の発言

実装すると決めた場合、どこまで書けば足りますか。項目が多いと、担当者の手が止まります。

鈴木さん

鈴木さんの発言

必須は4系統だけです。まずそこを埋めて、余力があれば推奨の項目を足す。その順番で十分ですよ。

Googleの公式ドキュメントによると、QAPageの必須プロパティは4系統です。mainEntity・answerCount・nameの3つが必須で、加えてacceptedAnswerかsuggestedAnswerのどちらかが1つ以上必要になります。

コピーして使える最小構成は、次のとおりです。

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "mainEntity": {
    "@type": "Question",
    "name": "質問のタイトルをここに入力",
    "answerCount": 3,
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "ベストアンサーの本文をここに入力",
      "author": {
        "@type": "Person",
        "name": "回答者のユーザー名"
      }
    }
  }
}

authorは必須ではありませんが、Google公式は推奨プロパティとして挙げています。質問者や回答者のプロフィールページがあるなら、author.urlで一意に結びつけることが勧められています。

JSON-LDそのものの書き方に自信がない場合は、別記事『JSON-LDの書き方入門』で基礎から扱っています。書式のエラーは、この記事の最後に挙げるテストツールで確認できます。

08QAPageやFAQPageなど構造化データを足せば、AI検索の引用は増えるんですか？

高梨課長

高梨課長の発言

正直、ここがいちばん知りたいところです。工数をかけてマークアップを足せば、AIの回答に載りやすくなるんでしょうか。

鈴木さん

鈴木さんの発言

そこは、期待させる書き方をしたくない場所です。確認できた範囲では、増えると言える根拠が見つかりませんでした。

まずGoogle自身の立場です。Google検索セントラルの「AI機能とウェブサイト」ガイド（2025年12月更新）は、AI機能に表示されるために特別なschema.orgの構造化データを追加する必要はない、と明記しています。QAPageやFAQPageだけを優遇する仕組みも、公式ドキュメントには見当たりません。

ここで期待の置きどころを、いったん置き直しておきます。マークアップは「AIに拾わせる装置」ではありません。 検索エンジンの機能に向けた書式であり、AIの回答に載るかどうかは、後半で見るとおり別の層で決まります。

09QAPageやFAQPageに関するAI検索最適化の実験データは、どこまで信じていいんですか？

実証データも見ておきます。Ahrefsが2026年5月に公開した調査は、JSON-LDスキーマを新しく追加した1,885ページと、追加していない4,000ページを比べました。結果は、いずれのプラットフォームでも意味のある増加は確認されなかった、というものです。

内訳はAI Overviewsで-4.6%、AI Modeで+2.4%、ChatGPTで+2.2%でした。-4.6%は統計的に有意ですが、対象ページはもともと減少傾向にあり、原因は断定できないと著者自身が書いています。

この調査には、読み方の注意があります。Article・FAQ・Product・HowToなど複数のスキーマ種別をまとめて扱っていて、FAQPage・QAPage単体を分離した検証は行われていません。 著者自身が限界として明記している点です。

引用率の研究をさらに追いたい方は、別記事『FAQ構造化データと引用率の関係』と『構造化データとAI引用の相関』で扱っています。

10AIは本当にQAPageのJSON-LDを読んでいる？LLMOの視点で何が分かりましたか？

もう1つの手がかりが、AIシステムが実際にJSON-LDを読んでいるのかという技術検証です。searchVIUは2025年12月、ChatGPT・Claude・Perplexity・Gemini・Google AI Modeを対象に、ページを直接取得したときの挙動を実験しています。

結果は、いずれのシステムも非表示のJSON-LDを読み取っていなかった、というものでした。読まれていたのは、視認できるHTML本文だけです。著者は、この結果がリアルタイム取得時に限られると留保も付けています。

LLMOの視点で整理すると、優先順位が見えてきます。土台は、画面に見えている本文です。 その上に、抜き出しやすい書き方が乗ります。非表示のマークアップは、いまのところ読まれたという確認が取れていない層になります。

だからマークアップが無駄だ、という話ではありません。Google検索のリッチリザルトという、確認できている用途がQAPageには残っています。 目的を「AIに引用してもらうため」と置くと根拠が薄くなる、ということです。

11いま入っているFAQPageは、AI検索対策としてどう扱えばいいですか？

高梨課長

高梨課長の発言

いま入っているFAQPageは、どうするのが正解ですか。消す作業にも工数はかかります。

鈴木さん

鈴木さんの発言

急いで消す理由は見当たりません。 増やすかどうかだけ、目的を分けて考えれば十分です。

いま入っているマークアップについては、削除する必要はありません。使われていない構造化データが検索で問題を起こすことはない、というのがGoogleの説明です。剥がす工数をかけるより、そのままにしておくほうが実務的だと言えます。

新しく足す場合は、話が変わります。FAQPageの新規実装には、FAQコンテンツの制作と、マークアップの整合を保ち続ける運用がついてきます。効果が実証されていない施策にこの運用コストをかける根拠は、いまのところ乏しいと言えます。

一方でQAPageは、フォーラムや製品サポートページを運営しているなら、いまも現役のリッチリザルト獲得手段として実装する価値があります。ここは判断が分かれるところではありません。

12QAPageとFAQPageの違いを、AI対策の優先順位にどう落としますか？

若葉さん

若葉さんの発言

つまり、型を選ぶ話とAI検索の話は、いったん切り離して考えるということですね？

鈴木さん

鈴木さんの発言

そのとおりです。切り離すと、やることが3つに減ります。 最後にその順番を整理しましょう。

ここまでを実務の順番に並べ替えます。判定・実装・確認の3段です。

まず判定です。利用者が回答を追加投稿できるか、質問が1つに絞られているか。この2問で、QAPageを使うかどうかが決まります。

次に実装です。QAPageなら、mainEntity・name・answerCountと回答本体を書きます。FAQPageの新規実装は、AI検索での引用ねらいではなく、別の理由で説明できるときだけにします。

最後に確認です。画面に出ている文とマークアップの中身が一致しているかを見て、Rich Results Testでエラーと警告を確かめます。ここまで通って、はじめて公開です。

13よくある質問

14まとめ｜今日やる3つのこと

QAPageとFAQPageは、回答を書く人という1点で分かれます。QAPageは利用者が投稿する質問と回答、FAQPageは運営者が用意する一問一答です。

Google検索での現在地は対照的で、FAQPageの表示は終わり、QAPageには項目が追加されました。一方で、構造化データを足せばAI検索の引用が増える、と言える根拠は確認できていません。実験で読まれていたのは、視認できるHTML本文のほうでした。