【概 要】
「FAQ構造化データを入れると検索結果にアコーディオンが出る」——この認識のまま実装しようとしている方は、2026年現在、いったん前提を更新する必要があります。
Googleは2023年8月にFAQリッチリザルトの対象を大幅に絞り込み、2026年5月7日をもってFAQリッチリザルト自体の表示を終了しました。検索結果に折りたたみのQ&Aが並ぶ、あの見た目はもう戻ってきません。
では、FAQスキーマを書く意味はなくなったのか。私の答えは「SERPの見た目のためには無意味だが、AIに引用させるための整理としてはまだ価値がある」です。この記事では、現暗号資産ニュースメディア編集長として当サイトの記事にFAQ構造化データを実装してきた立場から、Claude CodeにJSON-LDを自動生成させる手順と、Rank Mathとの併用で私が実際にやらかした二重出力の失敗、そして検証方法までを順に書いていきます。
技術記事ではありますが、コードが読めない前提で進めます。コピペで動く形まで落とし込んでいるので、非エンジニアの方も安心して読み進めてください。
【目 次】
1. まず前提を更新する：FAQリッチリザルトは終了した
2026年の状況を正確に押さえておきます。Googleの公式ドキュメントには、次の内容が記載されています。
- 2026年5月7日：FAQリッチリザルトが検索結果に表示されなくなった
- 2026年6月：Search ConsoleのFAQ検索での見え方フィルタ、リッチリザルトレポート、リッチリザルトテストのFAQ対応を削除
- 2026年8月：Search Console APIでのFAQリッチリザルトのサポート終了
一方でGoogleは、既存のFAQマークアップをそのまま残しておいても問題はないという趣旨の案内も出しています。未使用の構造化データが検索にマイナスの影響を与えるわけではない、という従来の見解の延長線上にあります。
「2023年に政府・医療サイト以外は制限されていたFAQスニペットを、今回Googleが完全に廃止した」と解説。公式の終了スケジュール（5月7日表示終了、6月Search Console関連削除、8月API終了）も引用して伝えている。
つまり「消す必要はないが、リッチリザルト目的では書く意味がない」というのが2026年9月時点の正しい理解です。古いSEO記事を読んで「FAQスキーマでCTRが上がる」と信じたまま実装すると、期待した成果は出にくいので、ここは最初に切り分けておいてください。
2. それでもFAQ構造化データを書く3つの理由
前提を更新したうえで、私が当サイトの記事にFAQ構造化データを入れ続けている理由は3つあります。
理由1：AI検索に「引用しやすい塊」を渡せる
AI Overviewsや各種AI検索は、ページ全体を要約するより、問いと答えがセットになった短い塊を優先的に拾う傾向があります。FAQPageのJSON-LDは、まさに「質問文」と「その答え」を明示的にペアリングする形式です。
ここで正直に書いておくと、「FAQスキーマを入れるとAI検索での引用率が何％上がる」といった検証済みの数値を、私は執筆時点で持っていません。公式にそう明言された資料も確認できていません。ですからこれは効果が保証された施策ではなく、コストが極めて低いのでやっておく類の施策だと捉えています。
理由2：記事の構成が自動的に整う
FAQを書こうとすると、「この記事で読者が最後まで残る疑問は何か」を強制的に考えることになります。副産物ですが、この作業が記事のリライト精度を確実に上げます。検索意図の取りこぼしを見つける作業としては、キーワードツールを眺めるより手っ取り早いくらいです。
この視点をもう一段深く掘りたい方は、オーガニック検索の流入を3年で8倍にしたリライト手順で整理した優先順位づけの考え方と組み合わせると効率が上がります。
理由3：FAQPage以外のスキーマに応用が利く
JSON-LDの書き方・入れ方・検証の流れは、FAQPageでもArticleでもHowToでも共通です。FAQPageは構造化データの入り口として一番簡単で、失敗してもダメージが小さいので、練習台として最適だと思っています。
3. 実装方法は3通り、どれを選ぶか
WordPressでFAQ構造化データを入れる方法は、大きく3つあります。
| 方法 | 手間 | 向いている人 |
|---|---|---|
| Rank MathのFAQブロック | 小 | 記事数が少ない・コードを触りたくない |
| テーマのfunctions.phpに自動出力 | 中 | 全記事に統一フォーマットで入れたい |
| Claude CodeでJSON-LDを生成して貼る | 小〜中 | 記事ごとに内容を作り込みたい |
Rank Mathを使っている方は、まずFAQブロックを試すのが最短です。ブロックエディタでFAQブロックを挿入し、質問と回答を入力すれば、表示用のHTMLとFAQPageのJSON-LDが同時に出力されます。有料版のRank Math Proでなくても、FAQブロック自体は無料版で使えます。
では、なぜわざわざClaude Codeを使うのか。理由は記事本文のFAQセクションと構造化データの内容を完全に一致させたいからです。私は記事をMarkdownで書いてWordPressに投稿するワークフローを組んでいるので、原稿のFAQセクションからそのままJSON-LDを生成できる方が、手入力より速くてズレません。
4. Claude CodeにFAQ JSON-LDを生成させるプロンプト設計
ここからが本題です。Claude Codeに投げているプロンプトの骨格は、次のような形です。
“` articles/022_xxx.md の「## FAQ」セクションを読み、 schema.org の FAQPage 形式の JSON-LD を生成してください。
条件：
- Q&Aは本文に実際に書かれている内容だけを使い、要約や創作をしない
- acceptedAnswer の text は HTML タグを含まないプレーンテキストにする
- 出力は
“`
ポイントは3つです。
1つ目は「本文にある内容だけを使う」と明示すること。 これを書かないと、AIは親切心でFAQを増やしたり、回答をきれいに言い換えたりします。構造化データはページに表示されている内容と一致している必要があるため、本文と構造化データが食い違った状態が一番まずいのです。
2つ目は出力形式を先に固定すること。 `
3つ目はファイルパスを渡すこと。 本文をコピペで貼るのではなく「このファイルを読んで」と指示すれば、記事を修正したときに同じコマンドで作り直せます。Claude Codeを使う最大のメリットはここです。
生成されるJSON-LDは、こういう形になります。
“`json { “@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [ { “@type”: “Question”, “name”: “FAQ構造化データは今も入れる意味がありますか？”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “リッチリザルト目的では意味がありませんが、AI検索に引用されやすい形に整理する目的では有効だと考えています。” } } ] } “`
`mainEntity` は配列で、Questionを必要な数だけ並べます。構造としてはこれだけです。
なお、Claude Codeの実行環境そのものをまだ作っていない方は、Claude Codeで非エンジニアがWordPress自動投稿に挑む【後編】で環境構築から自動投稿までの流れを実録でまとめています。
ここまで読んで、ちょっと難しいなと感じた方は、DMM 生成AI CAMP 学び放題のようなスクールで学ぶのもひとつの方法です。独学だと実践で使えるまでにかなり時間がかかりがちですし、AIの進化は早く、学ぶべきことも加速度的に増えています。体系立てて学べる環境があると、遠回りを減らしやすくなります。
5. Rank Mathとの併用で私がやらかした二重出力
ここが今回いちばん正直に書いておきたい失敗談です。
私は当初、Rank MathのFAQブロックで本文にFAQを表示しつつ、Claude Codeで生成したJSON-LDもカスタムHTMLブロックで貼り付けていました。表示上は何も問題がなかったので、数週間気づきませんでした。
結果どうなったかというと、1ページに FAQPageのJSON-LDが2つ出力される状態になっていました。検証ツールにかけて初めて気づき、該当記事を全部見直すはめになりました。エラーとして弾かれるわけではないので、能動的に検証しない限り気づけません。
この失敗から決めたルールは単純です。
- FAQの表示と構造化データは、必ずどちらか一方のツールに任せる
- Rank MathのFAQブロックを使うなら、手動のJSON-LDは貼らない
- 手動のJSON-LDを貼るなら、FAQ本文は通常の見出し＋段落で書き、FAQブロックは使わない
私は後者に統一しました。理由は、記事をMarkdownで管理している以上、Markdown側を正とした方がバージョン管理が破綻しにくいからです。AI生成コンテンツの運用でつまずきやすいポイントは他にもあり、AIで作った記事がGoogleにペナルティを受けない5つの条件に別の観点でまとめています。
6. 検証手順：リッチリザルトテストが使えなくなった今
2026年6月にリッチリザルトテストのFAQ対応が削除されたため、従来の検証フローはそのまま使えません。現在は次の2つで確認しています。
Schema Markup Validator（validator.schema.org）
Googleのリッチリザルト向けではなく、schema.orgの仕様に沿っているかを検証する汎用ツールです。FAQリッチリザルトの終了とは無関係に動くので、構文エラーや型の間違いはここで拾えます。URLを入力するか、コードを直接貼り付けて検証します。
ブラウザの検証機能でJSON-LDの数を数える
二重出力を防ぐには、こちらが確実です。公開ページを開いてページのソースを表示し、`application/ld+json` で検索します。FAQPageが2つ以上ヒットしたら、その時点でどちらかを消すという運用にしています。
地味な作業ですが、私の失敗はまさにこれをやっていなかったために起きました。記事を公開したら1回だけソースを確認する、これをルーティンに入れるだけで防げます。
7. かかるコストと、どこから手をつけるか
この運用にかかっている費用は、ざっくり次の通りです。
- Claude Pro：JSON-LD生成とプロンプト運用の主軸
- Rank Math：無料版でも構造化データ機能は十分に使える
- エックスサーバー：WordPressの稼働環境
Rank Math Proは構造化データの種類を増やしたい場合には有用ですが、FAQPageだけが目的なら無料版で足ります。私自身、FAQ構造化データのためだけに有料版を契約する必要は感じていません。これらのツールはA8.netなどのASPでも案件として扱われていますが、必要のないものを先に契約しても記事の質は1ミリも上がらないというのが実感です。
まず手をつけるなら、既存記事のうち検索流入が多い上位5本だけにFAQ構造化データを入れて、ソース確認まで一巡させてみてください。全記事に展開するのはその後で十分です。
8. まとめ：実装前に確認するチェックリスト
最後に要点をチェックリストの形で整理します。
- FAQリッチリザルトは2026年5月7日に終了した。SERPの見た目を目的にした実装はもう成立しない
- 既存のFAQマークアップは残しておいても問題ない、というのがGoogleの案内
- 書く価値は「AI検索に引用しやすい塊を渡す」「記事構成が整う」「他スキーマへの練習になる」の3点
- Claude Codeへの指示は「本文にある内容だけ使う」「出力形式を固定」「ファイルパスを渡す」の3つを押さえる
- Rank MathのFAQブロックと手動JSON-LDの併用は二重出力の温床。どちらか一方に統一する
- 検証はSchema Markup Validatorと、ソース内の `application/ld+json` 検索の2本立てで行う
構造化データは、やれば必ず順位が上がる魔法ではありません。ただ、「自分の記事のどこが読者の疑問に答えているのか」を機械に伝わる形で言語化する作業だと捉えると、費用対効果は悪くないと思っています。
FAQ
Q. FAQリッチリザルトが終了したのに、FAQスキーマを新しく入れる必要はありますか？
A. 検索結果の見た目を目的にするなら不要です。AI検索に引用されやすい形へ整理する目的であれば入れる価値はありますが、効果を裏づける検証済みではありません。コストが低いから試している、という位置づけで捉えるのが正直なところです。
Q. すでに入っているFAQ構造化データは削除すべきですか？
A. Googleは既存のマークアップをそのまま残しても問題ない旨を案内しています。削除の必要はありません。ただし、同じページにFAQPageが二重で出力されていないかだけは確認しておくことをおすすめします。
Q. Rank Mathを使っていればClaude Codeは不要ですか？
A. 記事数が少なく、WordPress上で直接編集しているなら、Rank MathのFAQブロックだけで十分です。Claude Codeが効いてくるのは、Markdown原稿を正としたワークフローで、本文とJSON-LDの内容を機械的に一致させたい場合です。
Q. JSON-LDに書いたQ&Aは、本文に表示されていなくてもいいですか？
A. 構造化データはページ上に表示されている内容と一致させるのが原則です。本文にないQ&Aを構造化データにだけ書くのは避けてください。Claude Codeへの指示に「本文にある内容だけを使う」と明記しているのは、この事故を防ぐためです。
Q. 検証はリッチリザルトテストでできますか？
A. 2026年6月にリッチリザルトテストのFAQ対応は削除されたため、FAQの検証には使えません。schema.orgのSchema Markup Validatorと、公開ページのソースで `application/ld+json` を検索する方法の2つを使ってください。