スキーママークアップのバリデーションは混乱する ― 実際に使えるツールと本当に重要なエラーは？

バリデーションの全体像を整理します：

ツールとその用途:

なぜ結果が異なるのか:

リッチリザルトテスト:

• リッチリザルトを引き起こすスキーマのみ検証
• Google特有の要件を表示
• リッチリザルト非対象の有効なスキーマは無視される場合あり

Schema Markup Validator:

• Schema.org語彙でバリデーション
• より包括的なカバレッジ
• Google特有要件の検証はしない

ワークフロー:

ステップ1: リッチリザルトテスト リッチリザルトの適格性をチェック。 ここで出るエラーは最優先で修正。

ステップ2: Schema Markup Validator Schema.org標準でバリデーション。 追加の問題を発見。

ステップ3: サーチコンソール 継続的な準拠状況の監視。 サイト全体の問題を特定。

両方のツールで合格すれば安心です。

よくある構文エラーと修正方法：

エラー1：引用符の種類が違う

悪い例:

"name": "Article Title"

（WordやGoogleドキュメントの曲線引用符）

良い例:

"name": "Article Title"

（コードエディタの直線引用符）

修正： JSONはWordで書かず、必ずコードエディタで。

エラー2：カンマの抜けや過剰

悪い例:

{
  "name": "Title",
  "author": "John"
  "date": "2025-12-31"
}

（authorの後のカンマ抜け）

良い例:

{
  "name": "Title",
  "author": "John",
  "date": "2025-12-31"
}

エラー3：末尾カンマ

悪い例:

{
  "name": "Title",
  "author": "John",
}

（最後のプロパティの後のカンマ）

良い例:

{
  "name": "Title",
  "author": "John"
}

エラー4：括弧の対応ミス

開き括弧と閉じ括弧の数を数える。 全ての{には}、全ての[には]が必要。

プロのコツ： まずjsonlint.comなどのJSONバリデータで確認。 構文エラーをスキーマ固有エラーより先に検出できます。

FAQスキーマが最も一般的 ― 正しくバリデーションする方法：

必須構造：

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "質問は何ですか？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "ここに完全な回答文。"
    }
  }]
}

よくあるFAQスキーマエラー:

1. コンテンツ不一致: スキーマのQ&Aはページの表示内容と一致必須。 スキーマだけのQ&Aは不可。

2. 隠しコンテンツ: FAQがタブやアコーディオン内にあると検証不可の場合も。 一部実装はJSレンダリング必須。

3. FAQスキーマの複数設置: 基本的に1ページに1つが推奨。 複数あるとバリデータが混乱。

4. Answerテキストの欠落: 各QuestionにacceptedAnswer必須。 acceptedAnswerにはtextプロパティ必須。

FAQバリデーションチェックリスト:

• @contextと@typeが正しい
• mainEntityが配列
• 各項目に@type: Question
• name（質問文）がある
• acceptedAnswerとそのtextがある
• ページ内容と一致
• コンテンツは非表示でない

テスト方法:

1. リッチリザルトテストでライブURL検証
2. 「FAQ」リッチリザルト種別が出るか確認
3. プレビューで表示を確認

AI可視性のためのArticleスキーマのコツ：

必須Articleスキーマ例：

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事タイトル",
  "datePublished": "2025-12-30",
  "dateModified": "2025-12-31",
  "author": {
    "@type": "Person",
    "name": "著者名",
    "url": "https://yoursite.com/author/name"
  },
  "publisher": {
    "@type": "Organization",
    "name": "あなたの会社",
    "logo": {
      "@type": "ImageObject",
      "url": "https://yoursite.com/logo.png"
    }
  },
  "image": "https://yoursite.com/image.jpg"
}

各プロパティがAIに重要な理由:

よくあるArticleエラー:

1. author欠落: Googleは推奨だが必須でない。 AIは信頼性で利用。

2. 日付形式ミス: ISO 8601必須：“2025-12-31” NG: “December 31, 2025”

3. publisherロゴの欠落: 一部リッチリザルトで必須。 本物の画像URLを使用。

4. dateModifiedがdatePublishedより古い: 論理的に矛盾。 システムがフラグまたは無視。

AIとのつながり: 良いArticleスキーマはAIに内容を理解・信頼させる。 著者・日付は特に引用で重要。

大規模サイトでのスキーマバリデーション方法：

100ページ以上の大規模サイト向け:

オプション1：Screaming Frog

• サイト全体をクロール
• 「構造化データ」タブで確認
• エラー・警告をエクスポート
• エラータイプごとに絞り込み

オプション2：サーチコンソール

• エンハンスメントレポート
• スキーマ付き全ページを確認
• エラータイプ別にグループ化
• 重要エラーを優先修正

オプション3：カスタムスクリプト

• 各ページからスキーマ抽出
• プログラムで検証
• レポート生成

優先順位付けフレームワーク:

テンプレート問題は最重要: ブログテンプレートにエラーがあれば 全ブログ記事が同じエラーを持つ。 テンプレ修正=数百ページの修正。

私たちのワークフロー:

1. 月1回Screaming Frogクロール
2. 構造化データレポートをエクスポート
3. テンプレエラーと個別エラーを特定
4. テンプレートを最初に修正
5. 個別修正はまとめて対応
6. サーチコンソールで検証

スキーマがAI可視性に与える具体的な効果：

なぜスキーマがAIに重要か:

1. 明示的な構造: AIは推測せずに済む。 スキーマで内容を明確に伝える。

2. 関係性の明瞭化: 著者→記事→出版社 AIがつながりを理解。

3. データ抽出: FAQPage＝明確なQ&Aペア。 AIが正確に抽出・引用。

AIに特に有効なスキーマタイプ:

私たちのテスト: スキーマありページ vs スキーマなしページ 同じ内容・構造。 スキーマ有はAI引用が35%多い。

注意点: スキーマだけで引用確約されない。 コンテンツ品質が最優先。 スキーマは「AIが良質コンテンツを理解」する助け。

AI向けバリデーション: FAQPageとArticleスキーマ重視。 エラーなし・クリーンな実装を。 内容とスキーマが一致していることを確認。

私のバリデーションワークフロー全体：

公開前のバリデーション:

ステップ1：JSON構文チェック jsonlint.comで確認 基本的な構文ミスを事前検出

ステップ2：Schema Markup Validator validator.schema.orgで貼り付け Schema.org準拠を確認

ステップ3：リッチリザルトテスト Google公式ツールでテスト リッチリザルト適格性を確認

ステップ4：プレビュー確認 リッチリザルトの見た目を確認 表示が正しいかチェック

公開後のバリデーション:

ステップ1：実際のURLでテスト リッチリザルトテストでライブURL確認 スキーマが正しくレンダリングされているか

ステップ2：サーチコンソール監視 インデックス登録後2～3日待つ エンハンスメントレポートを確認

ステップ3：リッチリザルトの出現確認 実際に検索してリッチリザルトを確認

継続的監視:

• 毎週：サーチコンソールで新規エラー確認
• 毎月：Screaming Frogクロール
• 四半期ごと：全スキーマ監査

クイックチェックリスト:

• JSON構文が有効
• Schema.org語彙が正しい
• Google要件を満たす
• 内容がスキーマと一致
• ライブページでレンダリング
• サーチコンソールがクリーン
• リッチリザルトが表示

よくあるバリデーション問題の即効修正：

「必須プロパティがありません」 スキーマタイプごとに必須プロパティを確認。 不足プロパティを追加。 Google公式ドキュメント参照。

「無効なプロパティ値」 主に日付・URL形式ミス。 日付：ISO 8601（2025-12-31） URL：絶対URL（https://…）

「プロパティが認識されません」 プロパティ名のタイポ。 schema.orgで正しい綴りを確認。 大文字・小文字区別あり：“datePublished"は"DatePublished"でない。

「無効なJSON-LD構文」 jsonlint.comでチェック。 引用符・カンマ・括弧を確認。 動作例と比較。

「ページ内に内容がありません」 スキーマが実在しない内容を参照。 内容を追加するかスキーマから削除。 不可視な内容は不可。

「同一ページ内の複数アイテム」 通常はOKだが整理が必要。 複数アイテムは@graph利用推奨。 各アイテムに必須プロパティを。

デバッグ用ツール: Chrome拡張「Structured Data Testing Tool」 右クリックですぐテスト。

困ったときは: Googleの例と比較。 最小限の有効スキーマに絞る。 一つずつプロパティを足しながら確認。

とてもわかりやすくなりました。自分のバリデーションワークフロー：

公開前:

1. コードエディタでスキーマ作成（直線引用符）
2. JSON構文検証（jsonlint.com）
3. Schema.org準拠チェック（validator.schema.org）
4. Google適格性テスト（リッチリザルトテスト）
5. リッチリザルトの見た目確認

公開後:

1. リッチリザルトテストで実際のURL確認
2. インデックス登録を待つ
3. サーチコンソールでエンハンスメント確認
4. 検索でリッチリザルト表示を確認

エラー優先度:

• パースエラー＝即修正
• 必須欠落＝即修正
• 無効値＝速やかに修正
• 警告＝該当時のみ検討

自サイトの場合:

• FAQPageとArticleスキーマに注力
• 一貫性のためテンプレート利用
• 毎月Screaming Frogで監査
• AI引用を追跡して関連性確認

重要な気付き: エラーは必ず修正。 警告は内容に応じて任意。 複数ツールで全体像が見える。

スキーマバリデーションの謎が解けました。ありがとうございました。