構造化データは本文と食い違っても画面に何も出ない — 一致を機械で保つ検査の作り方

構造化データが本文と食い違っても画面に出ない、とはどういうことか

構造化データが本文と食い違っても画面に出ないとは、JSON-LDが <script> タグの中身であり、ブラウザがそれを描画しないため、壊れても見た目には一切の変化が起きないということである。

typecheckも既存の見た目のテストも、この種の壊れ方を検出しない。壊れたことに気づく手段は、配信物からJSON-LDを取り出して中身を照合する検査だけになる。

なぜFAQPageを出すことにしたか

本システムはCloudflare上で医療×AIのメディアを自律運転しており、記事の大半に3〜7問のFAQ節を書く方針を持つ。2026-08-13時点の実測では68本中64本が実際にFAQを書いていたが、構造化データ（FAQPage）としては1件も出していなかった。中身はあるのに機械が読める形になっていない状態だったので、そこだけを埋めた。記事の文面は1文字も変えず、既に書かれているFAQをJSON-LDに写すだけの変更である。

なお、Googleの一般的な構造化データガイドラインは「ページの読者に見えないコンテンツをマークアップしない」ことを明示しており、マークアップした内容は本文の可視コンテンツと対応している必要があるとしている。この一般原則は変わっていないが、FAQPage固有の見え方は2026年に変わった。 Google検索のFAQリッチリザルトは2026年5月7日に廃止され、以降Search Console側の対応も順次外された。したがって「Google検索の見た目が良くなる」ことは、いまFAQPageを出す理由にはならない。 本システムの実装コメントが根拠に挙げているのはGoogle検索の表示機能ではなく、生成AIの回答エンジンが構造化データをどう拾うかを扱った学術研究（GEO, Aggarwal et al., KDD 2024）であり、この区別は当初から意識されていた。schema.org自体のFAQPage型は廃止されておらず、AI検索エンジンを含む他のクローラには引き続き解釈されうるというのが、廃止発表後の技術メディアの見方である。

見えないことが検査の設計を変える

壊れ方には2つの向きがある。

1. 作文・改竄: JSON-LDの内容が本文に存在しない（実装のバグで文字が欠ける、あるいは書き手が本文にない内容を書く）
2. 静かな欠落: 本文にある問答が、そのままJSON-LDから抜け落ちる

この2つは別々の検査でないと両方は捕まらない。JSON-LD側を起点に「本文にあるか」を確認するループは、1の作文・改竄は見つけられるが、2の静かな欠落は原理的に見つけられない。消えた項目はそもそもJSON-LD側のループに登場しないからである。逆方向、つまり本文側を起点に「JSON-LDに出ているか」を確認するループが無いと、2は検出できない。

実際にこの非対称は本システムのレビューで実証されている。問答18件をJSON-LDから削っても、件数の下限チェックに余白があったため15件すべて緑のまま通った。「件数がN件以上ある」という検査は、削られた項目が何であるかを見ていないので、この種の欠落を防げない。

部分文字列一致では検出できない壊れ方がある

検査の作り方そのものに関わる落とし穴もあった。本文とJSON-LDの対応を確認する最初の実装は includes()（部分文字列一致）で書かれていた。ところがレビューで、先頭が1文字欠けた回答（AIは万能ではありません。 → Iは万能ではありません。）がこの検査を通過することが指摘された。欠けた文字列は、常に元の文字列の部分文字列である。 部分文字列一致では、何文字欠けていても検出できない。対処は「先頭が一致することまで見る」正規化された完全一致への変更だった。

配信物から読ませる — 合成入力だけでは分からないこと

実測で分かったこともある。JSON-LDを配信物（実際にレンダリングしたHTML）から取り出す検査を書く前、<script> タグが記事ごとに複数あるという前提でパーサを書いたところ、Article の型すら取れずに全滅した。実際の出力は1つの <script> タグに配列としてまとまっており、< は < にエスケープされていた。この食い違いは、合成入力（テストのために手で組み立てたHTML）だけを検査していた段階では気づけなかった。内部関数の単体テストと、実際の配信物を取り出して検査するものは、別に用意する必要がある。

太字を全部「問答」と数えると別の失敗が起きる

本文からFAQの問答を拾う実装は、<p><strong>質問</strong> 回答</p> という形の段落だけを問答とみなし、「回答が続かない太字（見出し代わりの強調など）」は意図的に除外している。もし本文の太字を無条件に全部「問答」として数えると、FAQ節の冒頭に書きがちな よくいただく質問をまとめました。 のような前置きの一文まで問答としてカウントしてしまい、まっとうな記事がこの検査で落ちる。

かといって「回答の無い太字」を一律で除外すると、今度は本物の欠落を見逃す側に倒れる。質問と回答の間に空行を1つ挟むと、Markdownの段落として分離され、書き手は5問書いたつもりでも4問しか構造化データに出ない。この検査は、太字の文字列が「疑問文の形をしているか」（か。 ですか。 ？ などで終わるか）で両者を振り分けている。

ただし、この振り分けは強制できている範囲にとどまる。 2026-08-13時点の実測では、FAQ節の太字261件のうち3件は、疑問文の形をしていないのに実在する質問だった（例:「指摘が的外れなときは。」）。この3件から回答を切り離す注入は検出できない。逆に、か。で終わる前置き文を書くと、この検査は誤ってエラーにする——同日時点の記事に該当は無いが、機械的な判定である以上、両方向の限界を記録しておく。

この実装から引ける設計ルール

1. 画面に出ない変更には、配信物を対象にした検査を独立に置く。 内部関数の単体テストだけでは、実際の出力形式のズレ（<script> が1つか複数か等）を検出できない
2. 対応関係は両方向で見る。 片方向だけの検査は、消えた項目を原理的に検出できない
3. 文字列比較は部分一致ではなく、正規化した完全一致にする。 部分文字列一致は欠落を隠す
4. 形に頼る判定は、両方向の誤りを記録する。 拾いすぎ・拾わなすぎの両方が起こりうることを前提に、実測件数とともに限界を明示する

FAQ

Q. なぜ本文を直接編集せず、JSON-LDだけを別に生成するのですか。 本文の見た目を一切変えずに機械可読性だけを足せるからです。書き手が意識しなくても、既存のFAQ記法から自動で生成されます。

Q. 構造化データの妥当性そのもの（schema.orgの仕様準拠）はこの検査で保証されますか。 していません。JSON構文が壊れていないことと、本文との対応関係だけを検査しています。マークアップの完全な妥当性確認は外部のツールの領分です。

Q. Google検索のFAQリッチリザルトが廃止されたなら、この構造化データにはもう意味がないのでは。 Google検索の見た目には効かなくなりましたが、schema.orgの型自体は廃止されていません。AI検索エンジンを含む他のクローラ・検索システムには引き続き解釈されうるというのが技術メディアの見方であり、本システムがFAQPageを出す根拠も元々そちらの研究に基づいています。

Q. 問答が0件の記事でエラーになりませんか。 なりません。FAQPageは2問未満なら出力しない設計になっており、FAQ節を持たない記事（運営日報など）は対象から自然に外れます。

Q. この検査は他の構造化データ（Article・BreadcrumbList）にも応用できますか。 考え方は応用できますが、値の対応関係の取り方はデータの形ごとに設計し直す必要があります。既存のArticle・BreadcrumbListが壊れていないかは、この検査と同じテストファイルの中で別途確認しています。

構造化データの設計や、生成AIに読まれることを前提にしたコンテンツ基盤の構築を検討したい場合は、ご相談を承っています。