「構造化データを実装して」と言われて、JSON-LDを書き終えた。あとは公開するだけ——のはずが、ふと「これ、本当に合っているんだろうか」と不安になった。そんな経験はありませんか。
調べてみると、以前よく紹介されていた「Structured Data Testing Tool」というツール名が出てくるのに、実際にアクセスしてみると様子が違う。どうやら、今は別のツールを使うのが正解らしい——というところまでは分かったものの、結局どれを、どんな順番で使えばいいのかがはっきりしません。
この記事は、JSON-LDを書き終えて、これから検証しようとしている方を想定して書きました。今使うべき2つの公式ツールの使い方から、エラーが出たときの直し方、そして公開したあとも見ておくべきポイントまで、図解と会話をはさみながら順番に整理します。
こんなふうに調べていませんか
- 「構造化データ テストツール」で検索したら、名前だけ古いツールの記事が出てきて混乱した
- JSON-LDを書き終えたが、そのまま公開していいのか不安になっている
- リッチリザルトテストでエラーが出たが、何をどう直せばいいのか分からない
この記事を読み終えたときに手に入るもの
- 今使うべき2つの検証ツールを、目的に応じて使い分けられるようになります
- エラーメッセージの意味が分かり、どこを直せばいいか判断できるようになります
- 公開後も定期的に確認すべきポイントが分かります
結論30秒でわかる、この記事の結論
- 構造化データの検証は、現在Google公式の「Rich Results Test」と、schema.org運営の「Schema Markup Validator」という2つのツールを使い分けます。
- 以前よく紹介されていた「Structured Data Testing Tool」は、2021年8月にGoogle側のサポートが終了しています。
- 検証でエラーがないことと、AI検索に引用されることは別の話です。ここを混同しないことが、遠回りを防ぐ最初の一歩です。
この記事では、ある会社のマーケティング部の2人と、専門家の会話をはさみながら進めます。あなたに近い立場の人の質問から読んでいただいて構いません。
- 若葉さん（Web担当2年目）— 「そもそも、それって何のためにやるんですか？」を聞く役
- 高梨課長（マーケ課長）— 「誰が、どれくらいの手間でやるんですか？」を聞く役
- 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役
01そもそも、構造化データのテストツールは、AI検索対策として必要なんですか？
若葉さんあの…そもそもの話なんですが、JSON-LDって書き終えたら、そのまま公開しちゃダメなんでしょうか。テストって、何のためにやるんですか？
鈴木さんいい質問です。ひとことで言うと、書いたコードが、検索エンジンやAIから見て「本当に読み取れる状態になっているか」を、公開前に確かめる作業なんですよ。
JSON-LDの書き方そのものは、@context・@type・プロパティという3つの部品を並べるだけです（書き方は別記事『JSON-LDの書き方入門｜3つのコピペ例で今日から書ける【図解つき】』で解説しています）。ただ、人が手で書く以上、カンマの数え間違いや括弧の対応ミスは、どうしても起こります。
問題は、そうした小さなミスがあっても、ブラウザの画面には何も表示されないことです。JSON-LDは<script>タグの中に書くため、目に見えるページの見た目は変わりません。ミスがあるかどうかは、機械的に確認しない限り、書いた本人にも分からないのです。
このたとえで言うと、テストツールは「車が完成したかどうか」ではなく、「公道（検索結果）に出しても大丈夫な状態か」を確かめるものです。見た目が完成していても、検査を受けていない車を公道に出すのはリスクがあります。JSON-LDも同じで、書き終えたことと、検証を終えたことは別の話です。
この章のまとめ
テストツールは、JSON-LDが検索エンジンやAIから見て正しく読み取れる状態かどうかを、公開前に機械的に確かめるものです。ミスがあってもブラウザの見た目は変わらないため、検証を省略すると気づけません。
02テストツールでエラーが出なければ、AI検索に引用されるんですか？
大森部長検証さえ通しておけば、AIに引用されるようになるという理解でいいのか。
鈴木さんそこは、はっきり分けてお伝えします。検証はあくまで構文の話で、引用されるかどうかとは別の軸なんです。
この章のまとめ
検証ツールが見ているのは構文の正しさまでです。引用されるかどうかは別の軸にあり、この記事の範囲外だと捉えてください。
03AIOで今、実際に使うべき構造化データのテストツールは、どれとどれですか？
高梨課長鈴木さん、テストツールと一口に言っても、いくつか名前を聞いたことがあります。結局、今はどれを使えばいいんでしょうか。
鈴木さん現在使うべき公式ツールは、2つに絞られます。 Google公式の「Rich Results Test」と、Schema.orgコミュニティが運営する「Schema Markup Validator」です。
この2つは、検証する範囲が異なります。
| ツール名 | 運営元 | 検証範囲 | 主な用途 |
|---|---|---|---|
| Rich Results Test | Googleのリッチリザルトに対応した項目のみ | 自社ページがGoogle検索でリッチリザルトの対象になるか確認する | |
| Schema Markup Validator | Schema.orgコミュニティ | schema.org仕様全般 | Google固有の絞り込みなしで、構文自体の正しさを幅広く確認する |
この章のまとめ
今使うべき公式ツールは、Rich Results Test（Google運営・リッチリザルト対応項目のみ）とSchema Markup Validator（schema.orgコミュニティ運営・仕様全般）の2つです。
042つのテストツールは、AI検索対策としてどう使い分けるんですか？
若葉さん2つあると聞くと、どちらを先に開けばいいのか迷ってしまいます。
鈴木さん順番は決まっています。まずRich Results Test、そこで足りないときにSchema Markup Validatorです。
Google Search Central公式ドキュメントは、まずRich Results Testから始めることを案内しています。より汎用的な検証をしたいときに、Schema Markup Validatorを使うという使い分けです（出典: Google Search Central「構造化データの一般ガイドライン」）。
この2つは、競合するツールではありません。 Rich Results Testは、対応する範囲がGoogleのリッチリザルトに関わる項目に限られます。一方Schema Markup Validatorは、Googleが対応していないプロパティも含め、schema.org仕様全体を確認できます。目的に応じて、両方を使うのが実務的な進め方です。
この章のまとめ
まずRich Results Testから始め、より広く確認したいときにSchema Markup Validatorを使います。2つは競合するツールではなく、目的に応じて併用するものです。
05前によく聞いた構造化データのテストツール「Structured Data Testing Tool」は、AI検索対策でもう使えないんですか？
若葉さん実は検索したときに、「Structured Data Testing Tool」っていう名前の解説記事もたくさん出てきたんです。これは、さっきの2つとは別のものなんでしょうか。
鈴木さんそれはもう使えない、旧ツールの名前です。今でも解説記事が残っているので混同しやすいんですが、順を追って説明しますね。
構造化データの検証方法を検索すると、今でも「Structured Data Testing Tool」という名称を紹介する記事が見つかります。しかしこのツールは、現在の検証手順には使えません。
Rich Results Testは2020年7月に正式版へ移行しています（※当時の告知原文までは確認できていません）。旧Structured Data Testing Toolの終了方針は、同年12月のGoogle公式ブログで告知されました。
業界からの反発を受け、Googleはこのツールをschema.orgコミュニティへ移管しました。2020年12月に移行方針が発表され、2021年5月にschema.org側でSchema Markup Validatorが公開されています。Google自身によるサポートは、2021年8月に終了しました。
この章のまとめ
「Structured Data Testing Tool」はschema.orgコミュニティへ移管され、Google側のサポートは終了しています。名前は残っていますが、当時のツールそのものは動いていません。
06テストツールの旧名称の解説記事を見つけたら、AI検索ではどう扱えばいいんですか？
若葉さん検索して出てきた解説記事は、どう見分ければいいんでしょうか。
鈴木さん判断は簡単です。旧ツール名が手順に出てきたら、その記事は古いと考えてください。
現在、旧ツールのURLにアクセスすると、Rich Results TestまたはSchema Markup Validatorへ案内するページへリダイレクトされます。「Structured Data Testing Tool」という名称の解説記事を見かけた場合は、更新日が古い可能性を疑ってください。
この章のまとめ
判断基準は1つです。旧ツール名が手順に出てくる記事は、そのまま真似せず、現行2ツールでの手順に読み替えてください。
07Rich Results Testは、AI検索最適化のテストツールとして具体的にどう使うんですか？
高梨課長使うべきツールは分かりました。それで、Rich Results Testって、実際どういう手順で使えばいいんでしょうか。専任がいないので、手順が多いと厳しいのですが。
鈴木さん手順は6つありますが、難しい作業はありません。 URLかコードを貼り付けて、ボタンを押すだけの流れです。
Rich Results Testは、次の手順で使用します。
Rich Results Testの使い方
search.google.com/test/rich-results にアクセスする
ブラウザで開くだけです
検証方法を選ぶ
公開済みのページなら「URL」、未公開のコードなら「コードスニペット」を選びます
URLまたはコードを入力し、テストを実行する
入力欄に貼り付けてボタンを押します
検出されたリッチリザルトの候補を確認する
ページから検出できたリッチリザルトの種類が一覧表示されます
エラー・警告の内容を確認する
該当するプロパティ名とともに、問題の詳細が表示されます
プレビューで表示イメージを確認する
対応するリッチリザルトについて、検索結果での見え方を確認できます
Rich Results Testは、Search Console内からも実行できます。Search Consoleに登録済みのサイトであれば、URL検査ツールと連携した形で、同様の検証が可能です。
この章のまとめ
Rich Results Testは、URLかコードを貼り付けてボタンを押すだけの6ステップです。Search Console内からも実行でき、対応するリッチリザルトの表示イメージまで確認できます。
08テストツールでエラーが出たら、何が原因で、AI検索では何を見るんですか？
若葉さんさっき試しにやってみたら、実際にエラーが出ました…。「Missing field」って書いてあるんですが、これはどういう意味なんでしょうか。
鈴木さん落ち着いてください、よくあるエラーです。 実際に出るエラーは、大きく2種類に分かれます。意味が分かれば、直し方もすぐに見えてきますよ。
実際の検証で頻出するエラーには、次の2種類があります（出典: Search Console ヘルプ「Rich result error messages」）。
| エラー表示 | 意味 | 対処法 |
|---|---|---|
| Missing field 'プロパティ名' | 指定された必須プロパティが欠落している、または値が空になっている | 該当プロパティを、要求されている形式で追加する |
| Invalid object type for field 'プロパティ名' | プロパティの値が、期待されるデータ型と一致していない | 該当プロパティに求められる正しいデータ型に修正する |
この章のまとめ
頻出エラーは「Missing field」（必須プロパティの欠落）と「Invalid object type for field」（型の不一致）の2種類です。まず、どちらの型のエラーかを見分けてください。
09構造化データのエラーは、AI対策としてどこから直せばいいんですか？
若葉さん意味は分かったんですが、実際に直すときは何から手をつければいいんでしょうか。
鈴木さんエラー表示に出てくるプロパティ名が、そのまま直す場所の目印になります。
必須プロパティが1つでも欠けると、そのページはリッチリザルトの対象になりません（出典: Google Search Central「構造化データの一般ガイドライン」）。エラーメッセージにはプロパティ名が具体的に表示されるため、該当するリッチリザルトの型別ドキュメントと照らし合わせて修正すれば、大半のケースは解消できます。
この章のまとめ
エラーメッセージのプロパティ名を手がかりに、型別ドキュメントと照らし合わせます。「Missing field」なら追加、「Invalid object type」なら型の修正です。
10Schema Markup Validatorは、AI検索のテストツールとしてRich Results Testと何がちがうんですか？
高梨課長Rich Results Testでエラーがなければ、それで検証は終わりということでいいんでしょうか。
鈴木さんそこが、もう1つ押さえておきたいポイントです。 Rich Results Testは、あくまでGoogleのリッチリザルトに対応した項目だけを見ています。それ以外まで確認したいときに、Schema Markup Validatorが要るんです。
Schema Markup Validatorは、次の手順で使用します。
- validator.schema.org にアクセスする
- URLまたはコードを入力し、「Run Test」を実行する
- 検出されたマークアップの一覧を確認する — schema.org仕様に含まれるプロパティが、Google固有の絞り込みなしで幅広く表示されます
- エラー・警告を確認する — 必須プロパティの欠落や型の不一致など、構文レベルの問題が表示されます
Rich Results TestはGoogleのリッチリザルト対応項目に限定されます。一方Schema Markup Validatorは、schema.org仕様全体を対象にするため、Googleが未対応のプロパティも含めて確認できます。 両者は競合するツールではなく、目的に応じて併用するものと捉えてください。
この章のまとめ
Rich Results TestはGoogle対応項目だけ、Schema Markup Validatorはschema.org仕様全体を見ます。Googleが未対応のプロパティまで確認したいときは、後者を使ってください。
11実装から公開まで、AI検索対策として構造化データのテストツールをどの順に通すんですか？
高梨課長2つのツールを、実務ではどういう順番で回すのが正しいのでしょうか。
鈴木さん実装 → 2つで検証 → 修正 → 再検証、この一巡を公開前に必ず通してください。
この順番には理由があります。Rich Results Testを先に通すのは、リッチリザルトとして表示される見込みがあるかを先に確かめられるからです。そのうえでSchema Markup Validatorにかけると、リッチリザルトの対象になっていないプロパティまで含めて、構文の正しさを確認できます。修正したあとは、必ず同じ2つにもう一度かけ直してください。1つのエラーを直したつもりで、別のプロパティを壊しているケースがあります。
著者情報のPerson schemaを検証する際、Schema Markup Validatorでどの項目を確認すればいいかは、別記事『著者Person schemaの書き方とE-E-A-T効果』でも扱っています。
この章のまとめ
実装→2つのツールで検証→修正→再検証という流れを、公開前に一度通してください。修正したら、必ずもう一度かけ直します。
12テストツールでの検証を終えて公開したら、それでAI検索対策は終わりですか？
高梨課長検証が通ったら、あとは公開して終わり、で大丈夫でしょうか。
鈴木さんそこも、もう一歩あります。 検証は公開前の一時的なチェックです。公開後は、Search Consoleでの継続監視が必要になります。
公開後の継続的な監視には、Search Consoleの「拡張」セクションにあるリッチリザルトレポートを使います。このレポートは、サイト全体でGoogleが検出した構造化データの有効性をサンプル監視するものです。有効・無効アイテムの件数を時系列で追跡できます。特定のURLに影響する問題を詳しく確認したい場合は、レポートから対象URLを選び、URL検査ツールで詳細を確認する流れです（出典: Search Console ヘルプ「リッチリザルトレポートの概要」）。
この章のまとめ
公開前の検証だけでなく、Search Consoleのリッチリザルトレポートによる継続監視が必要です。有効・無効アイテムの件数を時系列で追えます。
13監視する構造化データの種類は、AIOではずっと同じなんですか？
大森部長監視の対象そのものが変わることはあるのか。
鈴木さんあります。表示されなくなったリッチリザルトの種類が、実際に出ています。 対象が今も有効かの確認まで含めて、検証は完結します。
なお、Googleが監視するリッチリザルトの種類は固定ではありません。FAQ rich resultsは2026年5月7日を境に、検索結果へ表示されなくなりました。Search ConsoleとRich Results TestでのFAQ関連サポートも、段階的に廃止が進んでいます（出典: Google Search Central「FAQPageの構造化データ」）。FAQPage自体のマークアップは、schema.orgの型として引き続き有効ですが、リッチリザルトとしての表示は期待できなくなりました。FAQ・HowTo構造化データと引用率の関係は、別記事『FAQ・HowTo構造化データと引用率の関係を一次データで検証』で詳しく扱っています。
この章のまとめ
監視対象のリッチリザルトの種類自体も見直され続けています。マークアップがschema.orgの型として有効でも、リッチリザルトとしての表示は期待できない場合があります。
14よくある質問
Rich Results TestとSchema Markup Validatorは、どちらか一方だけ使えば十分ですか？
目的が異なるため、両方の使用をおすすめします。Rich Results TestはGoogleのリッチリザルトに対応できるかの確認に向いています。Schema Markup Validatorは、schema.org仕様全体としての構文の正しさの確認に向いています。
旧ツールのURLをブックマークしているのですが、開くとどうなりますか？
現行ツールへの案内ページへリダイレクトされます。旧ツール自体はGoogleのサポートが2021年8月に終了して動いていないため、ブックマークはRich Results TestとSchema Markup Validatorに置き換えてください。
Search Consoleのリッチリザルトレポートに表示されないリッチリザルトの種類がある場合、実装が間違っているんですか？
そうとは限りません。Googleが監視・表示するリッチリザルトの種類自体が見直され続けています。FAQ rich resultsのように廃止された種類もあるため、まず対象のリッチリザルトが現在も有効かを確認してください。
Rich Results Testでよく出るエラーは、具体的にどう直せばいいですか？
代表的なのは「Missing field」（必須プロパティの欠落）と「Invalid object type for field」（値の型の不一致）です。エラー表示にはプロパティ名が含まれるため、該当するリッチリザルトの型別ドキュメントで正しい形式を確認し、その通りに修正します。
15まとめ｜今日やる3つのこと
構造化データの検証は、Google公式の「Rich Results Test」と、schema.org運営の「Schema Markup Validator」を使い分けることが基本です。2021年に終了した旧「Structured Data Testing Tool」と混同しないよう注意してください。
公開前の検証だけでなく、Search Consoleのリッチリザルトレポートによる継続監視が必要です。そして、検証対象のリッチリザルト自体が現在も有効かの確認まで含めて、初めて構造化データの検証は完結します。
今日この順でやります
Rich Results Testで、自社の主要ページを検証する
URLを貼り付けてテストを実行するだけです
Schema Markup Validatorで、schema.org仕様全体としての構文エラーがないか確認する
Google未対応のプロパティも含めて見られます
Search Consoleのリッチリザルトレポートを開き、対象のリッチリザルトが現在も有効かを確認する
公開後の定点観測を習慣にします
AI検索では、こう聞かれています
構造化データのテストツールって、結局どれを使えばいいんですか？
「AIOで今、実際に使うべき構造化データのテストツールは、どれとどれですか？」の章で、図と表を使って説明しています
書いたJSON-LDが合っているか、どうやって確認すればいいですか？
「Rich Results Testは、AI検索最適化のテストツールとして具体的にどう使うんですか？」に、6ステップの手順があります
エラーが出たら、どこを直せばいいですか？
「構造化データのエラーは、AI対策としてどこから直せばいいんですか？」の章で、直す順番を整理しています
「Structured Data Testing Tool」ってまだ使えますか？
「よくある質問」の2つ目で答えています（結論：使えません）
次に読むなら、この記事です
