構造化データのHTMLコードをAIにレビューさせる実践手順

自社サイトの構造化データを見直すとき、Article・Product・Person・FAQPageなど型ごとにチェック観点は異なります。とはいえ、型を横断して毎回確認すべき共通の基準もあります。本記事で扱うのは、その共通基準にもとづき、型を問わずに実装済みのJSON-LDコードをレビューする汎用的な手順です。

01この記事でわかること

• 実装済みのJSON-LDコードをAIに渡し、型を問わず共通の7つの観点でレビューさせるプロンプト
• 入力する情報（JSON-LDコードとページの表示コンテンツ）と、得られる出力（型を明記した判定表と修正案）
• 型別の専用チェックと、この汎用チェックをどう使い分けるか

03課題の整理（なぜ難しいか）

構造化データのレビューを自己流で行うと、チェックする観点がその日の気分や担当者の知識量によってばらつきます。

• 型ごとの必須・推奨プロパティ一覧を毎回検索して確認するのは手間がかかる
• スペルミスのプロパティ名や実在しない独自プロパティが、構文エラーにならないまま残る
• マークアップした内容が実際にページへ表示されているかという、型に関係なく共通の観点が見落とされやすい
• Person・Organization・Offerなどオブジェクト型で入れ子にすべき値を、単純な文字列のまま書いてしまう

この後のプロンプトは、型ごとの個別基準をAIの知識に委ねつつ、共通して確認すべき観点だけを漏らさず問う設計にしています。

04プロンプト本体

自社で実装済みの構造化データJSON-LDを、型を限定せずに公開前または定期点検のタイミングでレビューする場面で使います。

あなたはschema.org準拠の構造化データに詳しいテクニカルSEO/AIOの
アナリストです。以下のJSON-LDコードと表示コンテンツを、型を問わ
ない7つの観点にもとづいてレビューしてください。

■レビュー対象のJSON-LDコード
【JSON-LDコード】

■同じページの表示コンテンツ
【表示コンテンツ】

■チェック項目(まず@typeを特定したうえで、この7項目を判定すること)
1. @typeが、schema.orgの語彙に実在する型名であるか(スペルミスや、
   存在しない独自の型名になっていないか)。
2. 使用されているプロパティ名が、その@type(またはその親クラス)に
   schema.org上で定義されているプロパティであるか。
3. 【表示コンテンツ】と照らして、JSON-LDに書かれた内容が実際に
   ページ上に表示されている情報と一致しているか。表示されていない
   情報だけがJSON-LDにのみ記述されていないか。
4. Person・Organization・Offerなど、本来オブジェクト型で入れ子に
   すべきプロパティが、単純な文字列のまま平坦化されていないか。
5. 日付関連のプロパティ(datePublished等)が存在する場合、ISO 8601
   形式で記述されているか。
6. 同一ページ内に複数の@typeが記述されている場合、@graphなど適切
   な構造で衝突なく共存しているか。
7. その@typeにおいて一般的に推奨されるプロパティのうち、
   【表示コンテンツ】から埋められる情報があるのに空欄になって
   いるものがないか。

■出力形式
まず「判定対象の@type: 〇〇」を1行で明記したうえで、以下の表形式
で7項目すべてについて出力してください。
| チェック項目 | 判定(OK/NG/要確認) | 該当箇所 | 修正案 |
表の後に、NGと判定した項目の数を1行でまとめること。

■制約
- 【JSON-LDコード】・【表示コンテンツ】に実際に書かれていない内容
  から、問題の有無を推測しないこと。判定できない項目は「要確認」
  とし、理由を該当箇所欄に書くこと。
- その@type固有の必須プロパティの有無について確信が持てない場合
  は、断定せず「要確認(型別の公式ドキュメントで要確認)」と記載
  すること。

使う変数

※入力例のJSON-LDコードは仕組みを説明するための架空のサンプルであり、特定のサイトの実装を再現したものではありません。

05出力の見方と分析の観点

出力された表は、次の3点を中心に確認してください。

• 「判定対象の@type」が、意図した型と一致しているか（AIが型を誤認識したまま判定を進めていないか）
• NG判定の該当箇所が、実際のコードの該当プロパティを正しく指しているか
• 「型別の公式ドキュメントで要確認」とされた項目について、実際にschema.orgまたはGoogle公式ドキュメントで裏取りしたか

型ごとに正しい入れ子構造の基準は異なります。たとえばProduct型のprice・availabilityは、offers経由のOffer型に属し、Product直下ではありません（出典: schema.org公式）。この帰属の違いは項目4の判定に直結するため、NG判定が出た場合はどの型の基準にもとづく指摘かをあわせて確認してください。

Article型に特化したチェック手順は、別記事『Article schemaの実装ミスをAIに指摘させるプロンプト』で扱っています。実装後にツールでの機械的な検証まで行う手順は、別記事『構造化データのテスト・検証ツールの使い方｜旧ツールとの違いも解説』を参照してください。

06応用パターン

応用1: 複数ページ・複数型を一度にまとめてチェックする

複数ページのJSON-LDコードと表示コンテンツをページ名の見出し付きで連結し、【JSON-LDコード】【表示コンテンツ】にそれぞれ入力してください。■出力形式に「ページごとに表を分けて出力してください」と1行加えると、型の異なる複数ページをまとめて点検できます。

応用2: そもそもどの型を使うべきかをAIに提案させる

既存コードが手元にない新規コンテンツの場合は、【表示コンテンツ】だけを渡してください。「このコンテンツ内容なら、そもそもどのschema.org型を使うべきか提案してください」と質問すると、実装前の型選定に使えます。

07注意点

AIによるレビュー結果は、あくまでコード上の記述からの判定にすぎません。実際に検索結果やAI回答へどう影響するかは、別の観点での検証が必要です。

自社の未公開コンテンツや、公開前の記事のJSON-LDをプロンプトに貼り付ける際は、利用中のAIサービスの法人プラン・データ学習利用設定を事前に確認してください。

診断結果を社外の委託先と共有する場合や、大量ページに自動適用する場合は、利用しているAIサービスの利用規約の範囲内で行ってください。

AIの回答は実行のたびに揺らぎます。同じコードでも、要確認と判定される項目の粒度が実行のたびに変わることがあるため、重要な判断の前には複数回試すことをおすすめします。

AIの学習データの区切り以降に新設・改定されたschema.orgの型やプロパティは、正しく認識できない場合があります。特に新しい型を使っている場合は、schema.org公式サイトで型定義の存在を別途確認してください。

08FAQ