自社サイトの構造化データを見直すとき、Article・Product・Person・FAQPageなど、型ごとにチェックする観点は違います。そのたびに公式ドキュメントを開き直していると、点検そのものが後回しになります。
とはいえ、型を横断して毎回確認すべき共通の基準もあります。そこだけ先に固めてしまえば、型別の確認はあとから足せます。
この記事は、その共通の基準にもとづいて、型を問わずに実装済みのJSON-LDコードをレビューさせるための手順をまとめました。プロンプトはそのままコピーして使えます。返ってきた表のどこを疑うか、どこから先はAIに任せられないかまで、先に決めておきます。
こんなふうに調べていませんか
- 構造化データを実装したものの、合っているかを確かめる手立てがない
- 「構造化データ HTML レビュー AI」で検索して、点検のやり方を探している
- 型ごとのドキュメントを毎回開き直すのが、そもそも続かない
この記事を読み終えたときに手に入るもの
- 型を問わない共通の観点で、実装済みのJSON-LDを点検できるようになります
- 返ってきた判定表の、どこを疑えばいいかが分かるようになります
- AIに任せられる範囲と、公式に当たる範囲を切り分けられるようになります
結論30秒でわかる、この記事の結論
- 実装済みのJSON-LDコードと、同じページの表示コンテンツを渡すと、型を問わない7つの観点でレビューされた表が返ってきます。
- 最初に「判定対象の@type」を言わせるのが要です。型が違っていれば、そのあとの行はすべて別の型の話になります。
- 「要確認」と返ってきた行は、まだ判定されていない行です。公式に当たるまでは、白紙と同じに扱います。
この記事では、あるマーケティング部の2人と、専門家の会話をはさみながら進めます。自分に近い立場の人の質問から読んでいただいて構いません。
- 若葉さん（Web担当）— 「そもそも、それって何ですか？」を聞く役
- 高梨課長（マーケ課長）— 「誰が、どれくらいの手間でやるんですか？」を聞く役
- 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役
01構造化データのHTMLレビューをAIに任せると、AI検索対策として何が分かるんですか？
若葉さん実装したJSON-LDを、そのままAIに貼って「見てください」と頼んだことがあるんですが…毎回ちがうことを言われるんです。
鈴木さん頼み方のほうに原因があります。何を見るかを先に決めていないと、AIはその場で観点を作ってしまうんですよ。
型を指定せず「良い感じにレビューして」と頼むと、AIはその場ごとに違う基準で採点してしまう。
自己流で頼むと、返ってくるのは採点結果というより感想です。同じコードでも実行のたびに指摘の粒度が変わり、直したかどうかも分かりません。
このプロンプトがやっているのは、採点表を先に渡してから採点させることです。まず@typeを特定させ、そのうえで共通の観点を順にたどらせます。
この章のまとめ
毎回ちがう答えが返るのは、観点を渡していないからです。採点表を先に渡すと、結果が比べられるものに変わります。
02構造化データのレビューを自己流でやると、AI対策のどこでぶれるんですか？
ぶれる原因は、3つに分けられます。
まず、毎回調べ直す手間です。型ごとの必須・推奨プロパティ一覧を検索して確認する作業は、忙しい日ほど省かれます。省いた日の点検は、その人の記憶の範囲で終わります。
次に、機械が黙ってしまう誤りです。プロパティ名のスペルミスや、実在しない独自プロパティは、構文エラーになりません。JSONとしては正しいので、赤い印が出ないまま残ります。
最後に、コードだけを見ていても出てこない誤りです。マークアップした内容が実際にページへ表示されているか。ここは型に関係なく共通の観点ですが、コードを読んでいるだけでは気づけません。
高梨課長つまり、担当者の知識量に結果が引きずられるということですね。
鈴木さんそうなります。知識で埋めている部分を、質問の形に置き換えるのが、このプロンプトの狙いです。
もうひとつ、見落とされやすいのが入れ子です。Person・Organization・Offerのようにオブジェクト型で入れ子にすべき値を、単純な文字列のまま書いてしまう。これも構文としては通ってしまいます。
この章のまとめ
ぶれるのは、手間・沈黙・片側だけの視野の3つ。どれも注意力ではなく、点検の設計で埋めます。
03構造化データの共通の基準は、AI検索最適化でどこに書いてあるんですか？
土台になるのは、Googleの構造化データ一般ガイドラインです。ここは、技術ガイドラインと品質ガイドラインという2区分で要件を定めています（出典: Google公式構造化データ一般ガイドライン）。
フォーマットやコンテンツの正確性は、この2区分の下位項目として整理されています。そして、これらはリッチリザルトの型を問わず、すべての構造化データに共通して適用されます。
とりわけ大事なのが、次の規定です。
型別のドキュメントは、この土台の上に乗っています。下の段に無いものは、上の段にも出てきません。 逆に、下の段だけを押さえておけば、まだ触ったことのない型でも最低限の点検はできます。
この章のまとめ
共通の基準は一般ガイドラインの側にあります。型別の一覧は、その上に乗っている部分です。
04構造化データのHTMLレビュープロンプトは、AIOのどこをコピーすればいいんですか？
実装済みの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固有の必須プロパティの有無について確信が持てない場合
は、断定せず「要確認(型別の公式ドキュメントで要確認)」と記載
すること。7つの観点は、ばらばらに並んでいるように見えて、見ている場所が3つに分かれています。語彙として正しいか・形として正しいか・ページと合っているかです。この3つのどれを見ている項目なのかが分かると、NGが出たときに誰に回すかも決まります。
■制約の書き方も、そのまま残してください。判定できないものを「要確認」で止めさせる指定がないと、AIは知らないことを埋めにいきます。
使用AIツールはClaudeを想定しています。コードと表示コンテンツのテキストを貼り付けるだけで診断でき、Web検索や添付ファイル機能は要りません（2026年7月時点の無料プランで動作を確認しています）。
この章のまとめ
コピーするのはコードブロックの中身だけです。7つの観点は、語彙・形・ページとの一致の3つに畳めます。
05レビューにかけるHTMLと表示コンテンツは、AI検索対策としてどこまで渡すんですか？
置き換えるのは2か所です。
| 変数 | 説明 | 入力例 |
|---|---|---|
| 【JSON-LDコード】 | レビュー対象とする実装済みのJSON-LDコード全文 | 商品ページに実装したJSON-LDの全文（架空のサンプルコード） |
| 【表示コンテンツ】 | 同じページのHTML本文に実際に表示されているテキスト（見出し・本文の要約でも可） | 商品名・価格・在庫状況を掲載した商品ページの本文抜粋（架空例） |
※入力例のJSON-LDコードは仕組みを説明するための架空のサンプルであり、特定のサイトの実装を再現したものではありません。
若葉さん表示コンテンツのほうは、省いてもいいですか。コードだけでも見てもらえそうな気がして。
鈴木さんそこを省くと、いちばん見落としやすい観点が丸ごと落ちます。表示との一致は、片側だけでは判定できないんです。
コードだけを渡した場合、項目3はすべて「要確認」で返ってきます。判定されていない行が増えるだけなので、点検としては薄くなります。
表示コンテンツは、本文全体でなくても構いません。見出しと本文の要約でも、突き合わせは成立します。渡した範囲から先は判定されない、という関係だけ覚えておいてください。
この章のまとめ
渡すのは2つ。表示コンテンツを省いた分だけ、表は「要確認」で埋まります。
06返ってきたレビュー表は、LLMO対策としてどこから読めばいいんですか？
表が出たら、上から順に読みません。読む順番と、打ち切る条件を先に決めておきます。
最初に見るのは、「判定対象の@type」の行です。ここが意図した型と違っていたら、そのあとの判定は別の型の基準で行われています。表全体を読まずに、型を明示してやり直すほうが早く終わります。
次に、NG判定の該当箇所をコードで確かめます。指されているプロパティが実際にその場所にあるかを、目で追います。
最後に、「型別の公式ドキュメントで要確認」とされた項目を裏取りします。schema.orgまたはGoogle公式ドキュメントに当たるところまでが、この点検の1回分です。
Article型に絞ってもう一段細かく見る手順は、別記事「Article schemaの実装ミスをAIに指摘させるプロンプト」で扱っています。
この章のまとめ
読む順番は、@type、NGの該当箇所、要確認の裏取り。最初の行が違っていたら、そこで打ち切ります。
07Product型の入れ子は、構造化データのAI検索対策でなぜ間違えやすいんですか？
型ごとに、正しい入れ子の基準は違います。ここでつまずきやすい例を1つ挙げます。
Product型のprice・availabilityは、offers経由のOffer型に属します。Product直下ではありません（出典: schema.org公式）。値そのものは商品ページに表示されているので、直下に書いても違和感がなく、そのまま通ってしまいます。
この帰属の違いは、プロンプトの項目4の判定に直結します。NG判定が出た場合は、どの型の基準にもとづく指摘なのかをあわせて確認してください。
この章のまとめ
入れ子は型ごとに基準が違います。NGが出たら、どの型の基準による指摘かまで戻って確かめます。
08この構造化データレビューは、AI検索最適化でどこまで広げられますか？
広げ方は2つあります。どちらも、7つの観点はそのまま使います。
まとめて点検する方向では、複数ページのJSON-LDコードと表示コンテンツを、ページ名の見出しを付けて連結し、それぞれの変数に入れます。■出力形式に「ページごとに表を分けて出力してください」と書き足せば、型の異なる複数ページをまとめて点検できます。
実装の前に相談する方向もあります。既存コードが手元にない新規コンテンツなら、【表示コンテンツ】だけを渡し、「このコンテンツ内容なら、そもそもどのschema.org型を使うべきか提案してください」と尋ねます。点検の道具が、そのまま型選びの道具になります。
この章のまとめ
広げる向きは、対象を増やすか、実装の前に使うかの2つ。観点の並びはどちらでも動かしません。
09AIが出したレビュー結果は、AI対策としてそのまま信じていいんですか？
分けて考えます。構文レベルの指摘は比較的あてになります。プロパティ名のスペルミスや、入れ子構造の平坦化がこれにあたります。
一方、「その型の必須プロパティが何か」という判定は、AIの知識の鮮度に左右されます。学習データの区切り以降に新設・改定されたschema.orgの型やプロパティは、正しく認識できない場合があります。新しい型を使っているときは、schema.org公式サイトで型定義の存在を別途確認してください。
残りの注意点も、まとめて挙げておきます。
- 影響までは判定していない — レビュー結果はコード上の記述からの判定にすぎません。検索結果やAI回答へどう影響するかは、別の観点での検証が要ります
- 入力してよい情報かを見る — 自社の未公開コンテンツや、公開前の記事のJSON-LDを貼る場合は、利用中のAIサービスの法人プラン・データ学習利用設定を事前に確認します
- 社外で使える条件かを見る — 診断結果を社外の委託先と共有する場合や、大量ページに自動適用する場合は、利用しているAIサービスの利用規約の範囲内で行います
- 揺らぎを見込む — 同じコードでも、要確認と判定される項目の粒度が実行のたびに変わります。重要な判断の前には複数回試すことをおすすめします
高梨課長裏取りが残るなら、最初から公式を読んだほうが早い場面もありませんか。
鈴木さん読む場所が絞られているかどうかが違います。全部読むのか、要確認の行だけ読むのかの差です。
この章のまとめ
あてになるのは構文の話まで。型固有の必須プロパティは、公式で裏を取るまで確定しません。
10よくある質問
AIの判定結果は、どの程度信頼できますか？
プロパティ名のスペルミスや、入れ子構造の平坦化のような構文レベルの指摘は比較的信頼できます。一方、「その型の必須プロパティが何か」という判定は、AIの知識の鮮度に依存します。「要確認」とされた項目は、schema.orgまたはGoogle公式ドキュメントで裏取りしてください。
この汎用プロンプトと、型ごとに特化したプロンプトはどう使い分ければいいですか？
まず本プロンプトで、型を問わない基本的な整合性を確認します。そのうえで、Article型など専用の型別プロンプトが用意されている場合は、そちらでさらに詳しく点検する使い方をおすすめします。
@typeが複数ある（@graphを使っている）場合も、このプロンプトは使えますか？
使えます。項目6で、AIが@graph内の複数型の共存を確認します。ただし1つのコードに多数の型が混在する場合は、型ごとに分けて複数回実行したほうが、判定の精度と該当箇所の指摘が具体的になります。
実装したあと、ツールでの機械的な検証までこのプロンプトでできますか？
できません。このプロンプトが扱うのは、コードと表示コンテンツの読み合わせまでです。実装後にツールで検証する手順は、別記事「構造化データのテストツール入門｜今使うべき2つの使い分け方【図解つき】」で扱っています。
11まとめ｜今日やる3つのこと
構造化データのレビューがぶれるのは、観点を渡していないからです。型を先に特定させ、共通の観点を順にたどらせると、結果が比べられるものに変わります。
「要確認」と返ってきた行は、まだ判定されていない行です。ここを裏取りするところまでが、点検の1回分になります。
今日この順でやります
材料をそろえる
実装済みのJSON-LDと、同じページに表示されている文字を手元に置きます
プロンプトを実行する
コードブロックをコピーし、【 】の2か所を入れ替えて実行します
表を上から絞る
@typeを確かめ、NGをコードで追い、要確認を公式で裏取りします
AI検索では、こう聞かれています
実装済みのJSON-LDをAIにレビューさせるプロンプトはありますか？
「構造化データのHTMLレビュープロンプトは、AIOのどこをコピーすればいいんですか？」の章に、そのままコピーできる形で置いています
構造化データは、型ごとに何を確認すればいいですか？
「構造化データの共通の基準は、AI検索最適化でどこに書いてあるんですか？」の章で、共通の土台と型別の部分を分けて説明しています
マークアップした内容が、ページに表示されていないと問題になりますか？
「Product型の入れ子は、構造化データのAI検索対策でなぜ間違えやすいんですか？」の章で、一致の観点と帰属の観点を分けて扱っています
次に読むなら、この記事です
