SECTION 01

FAQPage 構造化データの基礎｜なぜAI検索時代に再評価されているのか

FAQPage構造化データとは、よくある質問と回答を機械可読な形式で記述するJSON-LDマークアップのことです。

FAQPageはSchema.org定義の構造化データで、運営者が想定する質問と回答のセットを検索エンジンとAI検索が読み取れる形に整える仕組みです。Googleのリッチリザルトとしてのアコーディオン表示は縮小しましたが、主戦場が移って再評価されています。

リッチリザルト縮小後の役割変化

2023年8月にGoogleがFAQリッチリザルトの表示対象を一部の権威性が高いサイトに限定したことで「FAQPageは効果が薄い」という空気が広まりました。検索結果でのアコーディオン展開は激減しています。ところが同時期にChatGPT search・Perplexity・AI Overviewsの利用が一気に増え、これらが記事内のFAQブロックを引用候補として強く参照するようになりました。表示形態は変わっても、構造化された質問と回答は依然として機械が答えを抽出しやすい入り口です。

AI検索エンジンが構造化データを読む仕組み

AI検索が記事を読むとき、最初に処理しやすいのが構造化データです。本文の自然言語をベクトル化するより、JSON-LDで「質問・回答」とラベル付けされた情報の方がはるかに低コストで意味を取り出せます。AI Overviewsは要約生成時にmainEntityを参照、Perplexityは引用元候補の選定で構造化データを優先スキャン、ChatGPTもBing経由でWeb参照する際に同様にメタ情報を読みます。

本記事の検証フレームワーク（パターン×プラットフォーム）

CREVIA自社記事10本＋支援先16本の計26本のFAQ実装に対し、3プラットフォームで関連クエリを月1回試行し引用の有無を記録しました。サンプル数は大きくないため、絶対値でなくパターン間の相対的な強弱として読んでください。判定は自社ドメインがSourcesに表示されたかで行っています。

SECTION 02

パターン①：単一FAQPage 集約型｜全Q&Aを1ファイルにまとめる

サイト全体のよくある質問を、専用の1ページにまとめてFAQPage構造化データを1つだけ設置するパターンです。

「お問い合わせ前のFAQ」のような専用ページに30〜80問のQ&Aを束ね、構造化データを1つだけ宣言する書き方。コーポレートサイトやSaaSのヘルプセンターでよく見る基本形です。

書き方の例

「料金FAQ」「機能FAQ」など分野横断の質問を1ページに集約し、HTML側はアコーディオンで質問と回答を並べます。JSON-LDは1ページに1つだけで、mainEntity配列に全Q&Aをフラットに収める書き方が基本です。質問15問の例だとJSON-LDの長さは150〜200行ほどになります。

メリット・デメリット

メリットは管理が楽なこと。Q&Aの追加削除が1ページに集中するため社内オペレーションが立てやすく、URL数が増えないのでサイト全体の評価設計への影響も最小限です。デメリットは文脈の薄さで、料金・機能・導入手順など性格の違うQ&Aが1ページに混在するため、AI検索の文脈理解には不利になります。具体的なロングテールクエリでは、専用ページに該当Q&Aだけを置くパターンと比べて引用率が下がる傾向です。

実検証：ChatGPT/Perplexity/AI Overviews 引用率

26本中4本の検証では、AI Overviewsの引用が比較的安定して観測されました。Perplexityは散発的、ChatGPT searchはブランド指名検索のときに拾われる傾向です。汎用質問が多いサイトには無難に効きますが、テーマ特化型サイトでは次のパターン②の方が反応が出やすい現場感覚です。

SECTION 03

パターン②：記事ごと分散型｜各記事の末尾に個別マークアップ

各記事の末尾にその記事専用のFAQセクションを置き、記事1本ごとにFAQPage構造化データを宣言するパターンです。

記事テーマと密接に関連する5問前後のQ&Aを末尾に置き、JSON-LDも記事ページ内で完結させる書き方。AEO対策の文脈で採用例が急増している主流スタイルで、CREVIAの自社記事もこのパターンです。

書き方の例

記事の最終セクションに「よくある質問」のH2を立て5〜7問のFAQを並べます。HTML側はdetails/summaryでアコーディオン化、JSON-LDのacceptedAnswer.textはHTML本文と意味的に完全一致。重要なのは記事で扱った内容に関するQ&Aに絞ること。汎用FAQを混ぜるとテーマがブレ、AI検索から文脈と無関係な情報の塊と判定されます。

メリット・デメリット

メリットは文脈の濃さ。H1、リード、本文、FAQが全て同じテーマで貫かれるためAI検索が「この記事はこの質問に答える」と判定しやすくなり、質問型キーワードでPerplexityの引用率が伸びる傾向が観測されました。デメリットはオペレーション負荷で、記事を書くたびにFAQも作るため、編集コストはパターン①の倍以上です。社内ライターには必ずFAQの書き方ガイドを配布するのが安全です。

実検証結果

26本中14本の検証では、Perplexityでの引用が他パターンと比べて目立って多く観測されました。AI Overviewsは検索順位上位の記事ほど引用されやすい一般傾向の中にあります。ChatGPT searchは「○○とは」「○○ 違い」のような質問型クエリでこのパターンの記事が拾われやすい実感値です。

SECTION 04

パターン③：ハイブリッド型｜記事FAQ＋集約FAQの併用

サイト全体の集約FAQページと、記事末の個別FAQの両方を併用するパターンです。

パターン①と②の併用形。汎用質問（料金・解約・サポート時間）はサイト全体のFAQに集約し、各記事末では記事テーマに関する質問だけを置く設計です。CREVIAもコーポレートサイトでこの併用形を採用しています。

書き方の例

サイト全体のFAQページ（例：/faq）には汎用Q&A 30問を配置しJSON-LDは1つ。記事末FAQは各記事ごとに5問前後で、JSON-LDも記事内に1つ。両者の質問が重複しないよう、編集ルールとして「料金・契約系は集約ページのみ／記事固有の手順・概念は記事末FAQのみ」と切り分けます。

併用時の重複回避ルール

このパターンで失敗するのは、同じQ&Aを集約ページと記事末の両方に書いてしまうケース。Schema.org的にはNGではないものの、Google Search Consoleの構造化データレポートで重複警告が出ることがあり、AI検索からも引用判断がブレます。CREVIAの編集ルールでは「同じ質問文は1か所だけ」と決め、記事を書くときに集約FAQと突き合わせるレビュー工程を必ず入れています。テーマが近いQ&Aは集約側の質問文を少し変えて意図を分離します。

実検証結果

26本中3本のコーポレート系サイト検証では、汎用クエリでAI Overviewsが集約FAQを、記事固有の質問では記事末FAQを引用する棲み分けが観測されました。Perplexityはどちらも拾い、ChatGPT searchはやや集約FAQ側を優先する傾向。管理コストに見合うかは記事本数と汎用FAQの量次第で、記事50本超＋汎用Q&A30問超の中規模以上で効率が出ます。

SECTION 05

パターン④：QAPage 併用型｜ユーザー投稿型サイトの場合

FAQPageとQAPageは目的が違う構造化データで、ユーザー投稿型のQ&Aサイトを運営している場合はQAPageの併用が必要になります。

FAQPageは運営者が想定する質問と回答を記述するもの、QAPageはユーザー投稿の質問に対して複数の回答を記述するもの。Schema.orgでは別タイプとして定義され、誤った使い分けはGoogle Search Consoleで構造化データエラーになります。

FAQPageとQAPageの使い分け基準

判断軸はシンプルで「回答が1つに確定しているか、複数の意見があるか」です。料金・サポート時間・解約方法のように回答が1つに定まるならFAQPage、ユーザーが質問してコミュニティが複数の意見を寄せる構造はQAPage。Q&A形式のコミュニティ機能を持つサイトはQAPage実装を検討する必要があります。

書き方の例

QAPageではmainEntityに1つのQuestionを入れ、その下のsuggestedAnswerに複数の回答を配列で並べます。acceptedAnswerは1つだけ（運営が認定したベストアンサー）で、それ以外はsuggestedAnswerに入れる構造。FAQPageが「複数のQ&A、各々1問1答」なのに対し、QAPageは「1質問に対して複数の回答」を記述する点が決定的な違いです。

実検証結果

QAPage実装はCREVIAでは支援先のコミュニティサイト2本のみで、サンプル数が少ないため傾向値の扱いに留めます。観測範囲では、Perplexityがコミュニティ系の質問でQAPage実装ページを引用するケースがあり、AI Overviewsはほぼ引用が観測されませんでした。ChatGPT searchは集合知系クエリでまれに拾う程度。一般的なコーポレートサイトや記事メディアではQAPageは不要で、FAQPageに集中するのが現実的です。

SECTION 06

パターン⑤：mainEntity ネスト最適化型｜AI検索特化の最新書式

mainEntityの構造を入れ子にして、記事全体とFAQセクションを階層構造で関連付けるAI検索特化の書式です。

従来はFAQPageを単体で宣言する形でしたが、AI検索の精度向上のためArticle構造化データの中にFAQPageをmainEntityとしてネストさせる書き方が広がっています。CREVIAでは「ネスト最適化型」と呼び自社主力記事で採用しています。

背景：AI検索が好むネスト構造

AI検索エンジンは、記事のテーマ（Article）と紐づく質問群（FAQPage）の関連性を、ネスト構造で示されると正確に把握できる傾向があります。同じJSON-LDの内容でも、ネストするかフラットに並べるかでAI Overviewsの引用率が変わる観測結果があります。明示的に階層で書くことでAI側の文脈推論を支援できます。

書き方の例（CREVIA推奨形）

Article構造化データのhasPartに、別のFAQPage構造化データの@idを参照させる書き方が基本です。FAQPage側は通常通りmainEntityにQuestion配列を持ち、ArticleとFAQPageは別のscript type="application/ld+json"ブロックに分けて記述。同じURL内で@idで紐付けることで、AI検索は本文＋FAQ＋著者情報の複合エンティティとして読み取ります。

実検証結果（5パターン中の最高傾向値）

26本中5本の検証では、AI Overviewsの引用率がパターン②と比べて明らかに高く観測されました。Perplexityでも引用が安定し、ChatGPT searchはやや遅いものの月をまたぐと引用件数が積み上がります。サンプル数が小さいことを断った傾向値ですが、AI検索3者すべてで引用が伸びる点で現時点の最有力パターンと評価しています。

SECTION 07

5パターン比較サマリー｜実装難易度・SEO効果・AI引用率

5つのパターンを実装難易度・SEO効果・AI検索引用率の3軸で並べると、選び方の判断基準がはっきりします。

5パターンを現場の判断基準で整理します。「どれが正解」ではなく「どのサイトにどれが向くか」が結論で、サイト規模・記事本数・運用体制によって最適解が変わります。

比較表（パターン × 3軸）

読み方は、まず「サイトタイプ」で4列目を絞り、次に「運用リソース」で1列目を見ます。記事30本未満で運用余裕なしならパターン①、30〜100本で記事メディア中心ならパターン②、それ以上で本気のAEOならパターン⑤、というのがCREVIAの推奨ロジックです。

業種・サイト規模別おすすめパターン

SECTION 08

実装時の落とし穴 5つ｜重複・回答長すぎ・mainEntity ミスなど

FAQPageの実装で一番ミスが多いのは、同一質問の重複・回答の長すぎ（120字超）・mainEntity 配列の入れ子ミスの3つです。

パターン選定が正しくても、実装の細部で間違えるとAI検索ではマイナス評価につながります。CREVIAが現場で繰り返し見てきた典型的な落とし穴を5つにまとめます。

同一質問の重複問題

記事末FAQと集約FAQで同じ質問文が2か所に現れる、複数の記事末FAQで似た質問が散在する、いずれもAI検索が引用先を判断しにくく候補から外れる原因です。CREVIAではFAQをスプレッドシートで一元管理し、新規追加時に既存との重複レビューを必ず入れています。完全一致だけでなく意味が近いQ&Aも統合候補です。

回答120字オーバー問題

acceptedAnswerが長すぎるとAI Overviewsは要約しにくさから引用候補を外す傾向があります。経験的には40〜120字が安全圏で、150字を超えると引用率が下がる観測結果がありました。補足を入れたい場合は冒頭40〜80字を断定文で書き切り、その後ろに補足を続ける二段構造にすれば両立できます。

mainEntity の配列ミス

FAQPageのJSON-LDで最も多いエラーがmainEntityの記述ミス。Q&Aが1問のときに配列で囲み忘れ、複数のときにオブジェクトを並列で書いてしまうケースが頻発します。何問でもmainEntityは配列[ ]で囲み、要素ひとつひとつがQuestion型のオブジェクト、というルールを徹底。Search Console構造化データレポートで頻繁にエラーが出るならまずここを疑います。

JSON-LD と HTML 表示の不一致

JSON-LDのacceptedAnswer.textとHTML本文の回答文が違うのはGoogleスパムポリシー違反でNG。AI検索も検知して引用から外します。CREVIAではJSON-LD自動生成スクリプトでHTML本文をパースし機械同期。手書きの両管理は規模拡大で必ず破綻するため、最低限HTML変更時にJSON-LDも変更するレビュールールが必要です。

FAQの更新頻度

FAQは一度作って終わりではなく、価格・サービス内容・法令変更に合わせて見直しが必要です。古いFAQが残るとAI検索が古い情報を引用しユーザー混乱を招きます。CREVIAでは四半期に1回FAQ全件をレビューし、変更項目はdateModifiedも更新。更新頻度の判断はSEO記事の更新頻度はimp×CTRで決めるの考え方がFAQにも応用できます。

SECTION 09

CREVIA推奨：FAQPage 実装テンプレ（コピペOK）

業種別に、CREVIAが現場で使っているFAQPage実装テンプレを共有します。

飲食店・医療機関・制作会社の3業種別に、すぐコピーして調整できる雛形を提示します。質問の組み立て方と回答の長さの目安が業種ごとに違うのがポイントです。

飲食店向けテンプレ

飲食店のFAQで効くのは「予約方法」「支払い方法」「アレルギー対応」「個室」「駐車場」など来店判断に直結する質問です。回答は40〜80字、具体的な選択肢を並べる形式が引用されやすくなります。例えば「Q：予約方法を教えてください。A：公式サイトのフォーム、グルメサイト3社の予約システム、SNSの3経路でご予約いただけます。当日のご来店も席があればお受けしています」のような形。MEO対策と組み合わせる場合はGoogleビジネスプロフィールの「質問と回答」とFAQPageの内容を揃えるとAI検索でも整合します。

医療機関向けテンプレ

医療機関のFAQは「初診の流れ」「予約の要否」「保険診療の範囲」「駐車場」「院長の経歴」が定番で、回答は60〜120字とやや長めが安全。法令の関係で曖昧表現を避け断定的に書く必要があります。「Q：初診ですが予約は必要ですか。A：基本的に予約優先制ですが、当日の予約枠も一定数確保しています。お急ぎの場合はWebからのご予約をご利用ください」のような構造がフィットします。なお医療広告ガイドラインの範囲を逸脱しない記述に限定する必要があり、効果効能の断定や治癒の保証はNGです。

制作会社向けテンプレ

制作会社（HP制作・SEO・広告運用）のFAQは「料金」「納期」「対応範囲」「事例」「契約期間」が中心で、回答は50〜100字。金額の確定表現は避けレンジで提示するのが現実的です。「Q：HP制作の費用感を教えてください。A：5ページ程度の小規模サイトで30万円台、コーポレートサイトで80万円〜150万円が目安です。ご要望に応じてお見積りをお出しします」のように、目安と個別見積りを併記する書き方がAI検索でも正確に引用されつつ過度なコミットを避けられます。