自社のFAQページに、FAQPageのマークアップを入れるかどうか。この判断で手が止まっている方は多いはずです。
理由ははっきりしています。リッチリザルトが検索結果から消えたあと、この実装で何が起きるのかが分からないからです。効果があるとも無いとも言い切れないまま、コードだけが手元にある状態になります。
この記事は、質問と回答のペアを渡すだけでFAQPageのJSON-LDを書かせるプロンプトを、コピーして使える形でまとめました。あわせて、廃止後にこの実装をどんな目的で使うのかを先に決めてから手を動かす順番にしています。
こんなふうに調べていませんか
- FAQPageのリッチリザルトが廃止されたと聞いて、実装するかどうか迷っている
- mainEntityやacceptedAnswerの入れ子を、毎回正確に書くのが手間だと感じている
- 上司に「FAQの構造化データは入れておいて」と言われたが、目的が説明できない
この記事を読み終えたときに手に入るもの
- リッチリザルト廃止後にFAQPageを実装する意味を、社内に説明できるようになります
- 質問と回答を渡すだけで、貼り付けられるJSON-LDを生成できます
- 生成されたコードのどこを見れば入れ子の崩れに気づけるかが分かります
結論30秒でわかる、この記事の結論
- FAQPageのリッチリザルトは、2026年5月7日付けでGoogle検索から完全に姿を消しました。
- それでもschema.org自体はFAQPage型の定義を維持しており、Q&Aを機械可読な形式で記述する仕組みとしては現在も機能します。
- だから実装の目的は、見た目の改善ではなく情報の整理に絞ります。目的を置きかえないまま入れると、確かめようのない作業になります。
この記事は、あるマーケティング部の2人と、専門家のやり取りをはさみながら進みます。若葉さん（Web担当2年目）が「そもそもそれは何ですか」を、高梨課長（マーケ課長）が「誰が、どれくらいの手間でやるんですか」を聞きます。答えるのは鈴木さん（AIO/SEOの専門家・本誌監修）です。
01そもそもFAQPage schemaは、AI検索対策として何をしているんですか？
若葉さんFAQPageって、要は「よくある質問」のページに何かコードを足すことなんですよね。そのコードが何をしているのかが、いまひとつ掴めなくて…。
鈴木さん中身はとても素朴です。質問と答えの組に「これは質問」「これがその答え」と札を付けて並べているだけなんですよ。人が読む本文とは別に、機械向けの控えを置いておくイメージですね。
FAQPageは、schema.orgが定めている型のひとつです。ページに書いてあるQ&Aを、機械が読み取れる形で並べて書くための決まりごとです。
書き方には入れ子があります。FAQPageの下にmainEntity、その中にQuestion、さらにその中にacceptedAnswer、いちばん内側にAnswerという順番です。質問文はQuestionのname、回答文はAnswerのtextに入ります。
この入れ子が、手で書くときにいちばん間違えるところです。ひとつの質問に対して階層が四重に重なるので、Q&Aの数が増えるほど写し間違いが出ます。
この章のまとめ
FAQPageは、ページのQ&Aを機械可読な形で書く型です。入れ子は外側から順にたどれば迷いません。質問はname、回答はtextに入ります。
02リッチリザルトが消えたのに、FAQPage schemaの実装はAI対策として意味があるんですか？
FAQPageのリッチリザルトは、2026年5月7日付けでGoogle検索から完全に姿を消しました（出典: Google公式FAQPageドキュメント）。検索結果に折りたたみのQ&Aが並ぶ、あの見た目はもうありません。
ここで多いのが、「では実装そのものが無効になったのか」という受け取り方です。そうではありません。schema.org自体はFAQPage型の定義を維持しており、Q&Aを機械可読な形式で記述する仕組みとしては現在も機能します。
消えたのは表示のほうです。書き方の決まりは残っています。
2026年5月7日を境に、FAQPageは「見せるための実装」から「整理するための実装」に役割が変わりました。
役割が入れ替わったのに、目的だけが前のまま残ることがあります。ここが実装でいちばんつまずく場所です。コードの書き方より前に、「今も実装する意味があるのか」という判断でつまずいているわけです。
この章のまとめ
廃止されたのはリッチリザルト（見た目）で、schema.orgのFAQPage型は残っています。実装の目的だけを、見た目から整理へ置きかえます。
03AI検索最適化の順番で、FAQPage schemaの実装はどこに置くんですか？
高梨課長うちで着手するとなると、本文の手直しとコードの追加、どちらを先に回せばいいでしょうか。
鈴木さん本文が先です。構造化データがAIの理解やAI引用に効果を持つかどうかは、当メディアの検証では確認できていません。期待の掛け方を間違えると、作業の順番まで逆になってしまうんですよ。
当メディアの検証（別記事 AIOM-041）では、AI検索システムは非表示のJSON-LDより、表示されている本文を読み取る傾向が確認されています。
だから順番があります。先に本文のQ&Aを整え、そのあとで機械可読な控えとしてFAQPageを添える。この向きを逆にすると、読み取られる側の本文が薄いまま、控えだけが積み上がっていきます。
この章のまとめ
表示されている本文が先です。FAQPageは、その本文を機械可読な形で控えておく後段の作業として置きます。
04AIにFAQPage schemaを書かせるプロンプトは、AI検索対策としてどこをコピーするんですか？
自社のFAQページに新しくFAQPageマークアップを設置する場面や、既存のFAQ内容が更新された場面で使います。次のコードブロックの中身を、そのままコピーしてください。
あなたはテクニカルSEO/AIO実装のアシスタントです。
以下の入力データをもとに、schema.org準拠のFAQPage型JSON-LDを生成して
ください。
■入力データ
【FAQ一覧】
■生成ルール(必ず守ること)
1. @contextは"https://schema.org"を、@typeは"FAQPage"を使用すること。
2. mainEntityプロパティに、【FAQ一覧】の質問と回答をQuestion型の配列
として入れ子にすること。
3. 各QuestionのnameプロパティにはFAQの質問文を、acceptedAnswerプロパ
ティにはAnswer型を入れ子にしてtextプロパティに回答文を記載すること。
4. 【FAQ一覧】にない質問・回答を、AIが推測して作り出さないこと。
5. 出力の末尾に、「FAQPageのリッチリザルトは廃止されているため、この
実装で検索結果の見た目が変わることはない」旨を1行で添えること。
■出力形式
<script type="application/ld+json">タグで囲んだ、そのままHTMLに貼り付け
られるコードのみを出力してください。前置き・後書きの説明文は不要です。
コードの直後に、生成ルール5の注記を1行添えてください。使用AIツールはChatGPT等です。コピーした質問と回答をそのまま貼り付けるだけで動作し、無料プランの範囲で完結します。ファイルアップロードは不要です（2026年7月時点）。
区画には役割の分担があります。前半で「誰として、何を見て書くか」を決め、後半で「勝手をさせない」ようにしています。特に効いているのは、生成ルールの四番目と五番目です。
- 四番目 — 【FAQ一覧】にない質問・回答を、AIが推測して作り出さないこと
- 五番目 — 出力の末尾に、リッチリザルトは廃止されている旨を1行添えること
前者は、入っていない答えを創作させない歯止めです。後者は、ここまで確認した位置づけを出力そのものに残しておくための一文です。この2つを削ると、手元に残るのは根拠のないコードだけになります。
この章のまとめ
コピーするのはコードブロック全体です。立場・入力・生成ルール・出力形式の4区画のうち、創作の禁止と注記の指定を消さないでください。
05AI検索対策として、AIに渡す【FAQ一覧】はFAQPage schema向けにどう書くんですか？
使う変数
| 変数 | 説明 | 入力例 |
|---|---|---|
| 【FAQ一覧】 | FAQPageに含めたい質問と回答のペアを1組ずつ改行で列挙したもの | Q. 送料はいくらですか／A. 全国一律500円です（架空例） |
※入力例は説明のための仮のデータであり、実在のサイト・企業を示すものではありません。
渡すのは、質問と回答のペアです。それ以上の加工は要りません。質問文と回答文をJSON-LD用に整形する手作業を、そのまま預けてしまうのが目的だからです。
貼り付ける前に決めておくことがあります。未公開の商品情報や問い合わせ内容を含む質問・回答をプロンプトに貼り付ける際は、利用中のAIサービスの法人プラン・データ学習利用設定を事前に確認してください。
この章のまとめ
渡すのは公開済みの質問と回答です。未公開の情報を含めるかどうかは、貼り付ける前に契約プランと学習利用設定で決めます。
06出てきたFAQPage schemaのコードは、AI検索対策としてどこを確認するんですか？
出力されたコードは、そのまま公開しないでください。設置の前に、次の3点を確認します。
- mainEntity内の質問・回答の文言が、入力した内容と一致しているか
- acceptedAnswerの中に、Answer型が正しく入れ子になっているか（textプロパティが直下に来ていないか）
- リッチリザルト非対応の注記が、出力から省略されていないか
いちばん見落とされるのは2番目です。入れ子が崩れていても、構文エラーにはなりません。エラーが出ないので、目で見るしかない場所になります。
構文エラーの有無は、Googleのリッチリザルトテストで確認できます。ただしFAQPage型自体はリッチリザルト対象外のため、表示プレビューは出ません。構文の確認に用途を絞って使ってください。同じ手順は、別記事 AIOM-662 でも解説しています。
この章のまとめ
文言の一致・入れ子の通り・注記の有無の3点です。入れ子はエラーにならないので、テストに任せず目で見ます。
07AIO実装でFAQPage schemaが遠回りになるのは、どこからですか？
遠回りは、だいたい目的の置き忘れから始まります。
ひとつめ。リッチリザルト対策のつもりで新しく実装する。見た目は変わらないので、入れた効果を確かめる手立てがありません。作業だけが残ります。
ふたつめ。本文を整えずにコードだけ足す。読み取られる側の本文が薄いままでは、控えを増やしても中身は増えません。
みっつめ。効果があるものとして社内に説明する。構造化データがAI引用に効果を持つかどうかは確認できていません。確認できていないことは、そのまま伝えるほうが後で崩れません。
実装はあくまでコンテンツ情報の整理として位置づけてください。この一行を先に共有しておくだけで、上の3つはほとんど起きなくなります。
この章のまとめ
遠回りの入口は、目的を置きかえないまま手を動かすことです。整理のための実装だと決めてから入れると、手戻りが出ません。
08AIが添える説明文は、FAQPage schemaのAI検索最適化でなぜ疑うんですか？
若葉さん生成されたコードの下に、AIが説明も書いてくれるんですよね。あれはそのまま読んでいいんでしょうか。
鈴木さんそこは分けて見てください。コードは入力と照合できますが、説明文は照合できません。しかもFAQPageの廃止は比較的新しい話なので、古い前提のまま書かれてしまうことがあるんです。
FAQPageのリッチリザルト廃止は比較的新しい情報です。そのためAIの学習データによっては、「FAQPage実装で検索結果の表示が改善する」という古い前提の解説文を返す場合があります。
生成されたコード自体に問題がなくても、AIが添える説明文にこの古い前提が混ざっていないかを確認してください。ここまでのプロンプトと解説も、あくまでAIの出力です。特にFAQPageの効果に関する説明文は、鵜呑みにせず一次情報と照らし合わせてください。
AIの回答は実行のたびに揺らぎます。同じ入力でも、添えられる注記の文言や補足説明の書き方が変わることがあります。揺らぐのは説明文の側で、照合できるのはコードの側という切り分けを持っておくと、読み方に迷いません。
この章のまとめ
コードは入力と照合できますが、説明文は照合できません。古い前提が混ざっていないかを、一次情報と照らして人が見ます。
09更新やQAPageとの選び分けは、FAQPage schemaのLLMO対策でどうするんですか？
高梨課長FAQの中身は年に何度か直します。そのたびに全部やり直すのは、正直しんどいですね。
鈴木さんそこは軽く済みます。変わった質問と回答だけを渡し直せば、更新版が返ってきます。作り直しではなく差し替えの感覚ですね。
FAQの内容を更新した際は、変更後の質問と回答だけを【FAQ一覧】に入力し直せば、更新版のJSON-LDを再生成できます。プロンプトそのものを書き直す必要はありません。
もうひとつ、型の選び分けがあります。ひとつの質問に複数の回答候補があるコミュニティ型Q&Aでは、FAQPageでなくQAPage型が適切な場合があります。迷うときは、続けて「この内容はFAQPage・QAPageのどちらが適切ですか」と質問すると、判断材料が得られます。
この章のまとめ
更新は差分の入力だけで済みます。回答候補が複数ぶら下がる形なら別の型が合う場合があるので、AIに判断材料を出させてください。
10よくある質問
既存のFAQPageマークアップは、今すぐ削除したほうがいいですか？
削除する必要はありません。Google公式の廃止告知には、既存マークアップの削除を求める記述はありません（出典: Google公式FAQPageドキュメント）。残しておくことによる問題も、公式には言及されていません。ただし新規に実装する際は、検索結果の見た目改善を目的にしないでください。
FAQPage型の代わりに、本文へ直接Q&Aを書くだけでは不十分ですか？
本文中の見出しと回答文こそ優先すべきです。別記事 AIOM-041 のとおり、AI検索システムは非表示のJSON-LDより表示されている本文を読み取る傾向が確認されています。FAQPageは本文を補完する位置づけで扱ってください。
生成したコードは、どのツールで検証すればいいですか？
Googleのリッチリザルトテストで構文エラーの検出は可能ですが、FAQPage型自体はリッチリザルト対象外のため表示プレビューは出ません。構文エラーの有無を確認する用途に絞って使ってください。
同じ質問と回答を渡しても、出力が毎回違うのはなぜですか？
AIの回答は実行のたびに揺らぎます。同じ入力でも、添えられる注記の文言や補足説明の書き方が変わることがあります。コードの中身が入力と一致していれば、注記の言い回しの違いは気にしなくて構いません。
生成したコードを、社外の委託先と共有してもいいですか？
生成したコードを商用サイトで使う場合や、大量ページに自動適用する場合は、利用しているAIサービスの利用規約の範囲内で行ってください。共有する前に、渡す内容へ未公開情報が含まれていないかもあわせて確認してください。
11まとめ｜今日から始める3つのこと
FAQPageの実装でつまずくのは、コードの書き方より前の判断です。廃止されたのはリッチリザルトで、schema.orgの型は残っています。だから目的を、見た目の改善から情報の整理へ置きかえます。
入れ子の写し取りは、プロンプトへ預けます。預けないのは、目的を決めることと、入れ子と注記を目で見ることです。
今日この順でやります
目的を書きかえる
見た目の改善ではなく、Q&Aを機械可読に整えるためだと決めます
質問と回答を並べて渡す
公開済みの文をそのまま、1組ずつ改行で列挙します
入れ子と注記を見る
acceptedAnswerの中にAnswer型があるか、注記が残っているかを確かめます
AI検索では、こう聞かれています
FAQPageのリッチリザルトが廃止されたのに、まだ実装する意味はありますか？
「リッチリザルトが消えたのに、FAQPage schemaの実装はAI対策として意味があるんですか？」の章で、消えたものと残ったものを分けて説明しています
質問と回答からFAQPageのJSON-LDを作ってもらうには、どう頼めばいいですか？
「AIにFAQPage schemaを書かせるプロンプトは、AI検索対策としてどこをコピーするんですか？」の章に、そのままコピーできる形で置いています
FAQPageとQAPageは、どちらを使えばいいですか？
「更新やQAPageとの選び分けは、FAQPage schemaのLLMO対策でどうするんですか？」の章で、選び分けの目安を説明しています
次に読むなら、この記事です
