構造化データの保守を自動化する｜JSON-LDが壊れる5つの型と、CIで止める4段の検証（2026年）

構造化データ（JSON-LD）は、入れた日がいちばん正確です。テーマの更新、プラグインの入れ替え、翻訳の追加が積み重なると、見えている本文と JSON-LD の内容がずれていきます。画面に出ないので、壊れても誰も気づきません。

この記事では、構造化データを壊れないように保つ仕組みを整理します。書き方の入門ではなく、「誰が、いつ、何で、ずれに気づくか」が中心です。公開前の品質チェック全体は「記事更新の自動化は「品質ゲート」で決まる」、検索の数字の監視は「Search Console と GA4 の定点観測を自動化する」、2言語の翻訳と hreflang の運用は「日英2言語サイトの翻訳と更新を自動化する」で扱いました。ここでは構造化データだけに絞ります。

この記事が主に根拠にした情報：Google 検索セントラルの構造化データのガイドラインと更新履歴、2023〜2025年の公式ブログ、Search Console ヘルプ、Schema.org のリリース情報、W3C の JSON-LD 1.1、HTTP Archive の Web Almanac 2024。いずれも2026年10月28日に確認しました。

1. いま何が起きているか：リッチリザルトは減り、構造化データは残った

この3年でいちばん大きく変わったのは、Google が検索結果を簡素にする方針をとり、リッチリザルト（星や手順などがついた特別な表示）の種類を減らし続けていることです。

FAQ と HowTo の縮小から始まった

2023年8月8日、Google は FAQ のリッチリザルトを「よく知られた、権威のある政府・保健のサイト」に限ると発表しました。HowTo は同年9月13日にパソコンでも表示されなくなり、廃止されました。Google は同時に、使われていない構造化データは検索に問題を起こさないので、急いで消す必要はないと書いています。

2025年に7種、2026年に FAQ

2025年6月12日の公式ブログは、Course Info、ClaimReview、Learning Video など7種を段階的に終えると発表しました。理由は利用が少なく、価値が大きくなくなったことで、順位には影響せず、検索以外での使い方にも影響しないと明記しています。Practice problem の文書は2026年1月6日に削除され、FAQ のリッチリザルトは2026年5月7日から表示されなくなりました（文書は6月15日に削除）。

一方で、構造化データを使う場所は広がった

表示が減った一方で、構造化データそのものの利用は増えています。HTTP Archive の Web Almanac 2024 によると、JSON-LD を使うページは2022年の34%から2024年の41%に増えました。FAQ のリッチリザルトが縮小したあとも、パソコンの FAQPage の利用は0.2%から0.6%に増えています。表示されなくなった型が、そのまま残っているサイトが多いということです。

RDFa の利用率が高いのは、SNS 向けの Open Graph（64%）が RDFa として数えられるためです。Google が推奨するのは JSON-LD で、この記事も JSON-LD を前提にします。なお表示が終わった型は、少し遅れて Search Console のレポートと検証ツールからも消えます。レポートから消えたことを「エラーが直った」と読み違えないことが、保守の最初の注意点です。

2. 構造化データの保守とは何か：書くことより、ずれないこと

構造化データの保守とは、JSON-LD に書かれた内容が、いつも正しく、本文と一致している状態を保つ作業です。新しい型を足す作業ではありません。

なぜ、放っておくと壊れるのか

構造化データは、本文とは別の場所（多くは head の中の script 要素）に書かれます。本文を直す人は JSON-LD を見ず、JSON-LD を作った人は本文の変更を知りません。同じ情報が2か所にあるかぎり、時間とともにずれます。

Google の一般的なガイドラインは、構造化データがページの内容を正しく表すこと、見えていない内容をマークアップしないこと、最新の情報を出すことを求めています。違反すると、手動による対策でリッチリザルトの対象から外れることがあります（順位には影響しないと説明されています）。

ほかの保守作業との境界

この記事で扱う範囲を、ほかの運用作業と次のように切り分けます。

境界を決めるのは、担当を決めるためです。構造化データは SEO・開発・商品データのどの担当にも属さず、誰も責任を持たない部品になりがちです。

表示が終わっても、正確さは残す

Google の入門ページは、構造化データをページの内容の理解と、人や会社などの情報の収集にも使うと説明しています。表示が終わった型でも、正しく書かれていれば害はなく、間違っていれば害が残ります。目標を「表示を出す」から「正確に保つ」に置き換えると、Google の対象変更に振り回されません。

3. JSON-LD が壊れる5つの型

構造化データの壊れ方は、だいたい5つの型に分けられます。型ごとに、気づける道具と止め方が違います。

型1：テンプレートの変更で壊れる

最も多いのが、テーマやプラグインの更新で出力が変わるケースです。SEO プラグインとテーマの両方が Organization を出す二重出力、日付が 28/10/2026 のように ISO 8601（日時の国際規格）でなくなる書式の変化、script 要素ごと消える出力の消失が典型です。Google の Article のドキュメントは日付にタイムゾーンを入れるよう勧めており、ないと Googlebot のタイムゾーンで扱われます。日欧で記事を出すサイトでは、日付が1日ずれて見える原因になります。

型2：必須プロパティが欠ける

Google の機能ごとのドキュメントには必須と推奨のプロパティがあり、必須が欠けたアイテムはリッチリザルトの対象になりません。原因の多くはデータ側にあります。商品画像の登録漏れ、価格が「お問い合わせ」で数値がない、といったケースです。テンプレートが正しくても、元のデータが欠ければ JSON-LD も欠けます。

型3：表示内容と一致しない

本文の価格と JSON-LD の価格が違う、本文にないレビューの星を書いている、といった不一致です。欧州で売るサイトには小数点の落とし穴もあります。オランダでは画面上「€ 1.299,00」と書きますが、Google の Product のドキュメントは小数点に「.」を使うよう求めています。表記をそのまま流すと、1,299ユーロが1.299ユーロと読まれます。

型4：廃止されたリッチリザルトが残る

表示が終わった型が残っていること自体は問題になりません。問題は保守の手間と誤解です。FAQ のために本文にない質問を JSON-LD に書く状態は、表示が終わっても手間だけを生みます。レポートから消えると、エラーも見えなくなります。

型5：多言語で食い違う

片方の言語だけ更新される、inLanguage が全ページ「ja」のまま、といった食い違いです。翻訳は本文だけを対象にしがちで、JSON-LD は工程から漏れます。第8章で扱います。

表のとおり、5つのうち3つ（1・3・5）はテンプレートとデータの設計で起きにくくできます。検査で拾うより安く済みます。

4. Google のリッチリザルトの対象：何が残り、何が消えたか

保守の範囲を決めるには、いま Google がどの型を使っているかを知る必要があります。Google の「サポートする構造化データ」のページには、2026年10月28日時点で25の項目が並んでいます。

残っている主な型

多くの会社サイトに関係するのは、次の型です。

一般的な会社サイトで保守が必要なのは、多くても5〜6種です。すべての型を追う必要はありません。

消えた型と、扱いの違い

2025年の7種は、9月9日に Search Console のレポート、Rich Results Test、検索での見え方のフィルタから外れました。一括エクスポート（BigQuery）では、該当する列が2025年10月1日までに NULL になると告知されました。

「外してよい」は「外さなければならない」ではありません。ただし残すなら、本文と一致させ続ける必要があります。

5. テンプレートから生成する設計

保守の自動化で最も効くのは、検査ではなく生成の仕方です。本文と同じデータから JSON-LD を組み立てれば、型1・3・5の多くが起きにくくなります。

原則1：情報の出どころを1つにする

価格、営業時間、著者名、公開日は、本文の値と JSON-LD の値を同じ変数から出します。Google の JavaScript での生成のドキュメントも、タグマネージャーで作る場合は情報を複製せず、ページから値を取り出す変数を使うよう勧めています。

「よい例」に共通するのは、JSON-LD を手で書く人がいなくなることです。

原則2：ページの種類と型を対応させる

ページを種類に分け、種類ごとに出す型を1つの表に決めます。この表が構造化データの「設計書」になります。

Google の Organization のドキュメントは、会社の情報をトップか会社概要の1ページに置けばよく、全ページに入れる必要はないとしています。

原則3：@graph と @id でつなぐ

複数の型は @graph でまとめ、@id で参照し合います。Organization に固定の @id を付け、記事の publisher からはその @id だけを参照すれば、会社名を変えるとき直す場所が1か所で済みます。@id は、2020年7月16日に W3C 勧告になった JSON-LD 1.1 の基本機能です。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example B.V.",
      "url": "https://example.com/"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/column/sample#article",
      "headline": "記事のタイトル",
      "inLanguage": "ja",
      "datePublished": "2026-10-28T09:00:00+01:00",
      "dateModified": "2026-10-28T09:00:00+01:00",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

値はテンプレートが埋めます。@id の URL は一度決めたら変えないでください。サイトの移転のときも、移行計画に入れます。

原則4：JavaScript で後から足すのは最後の手段

Google は商品について、動的に生成したマークアップはショッピングのクロールの頻度と信頼性を下げることがあるとし、最初の HTML に入れるよう勧めています。タグマネージャーでの追加は一時しのぎと考えてください。

6. CI での検証：4段で止める

テンプレートそのものが変われば、生成した JSON-LD も壊れます。そこで、デプロイのたびに見本URLを検査し、落ちたら公開を止める仕組みを CI（変更のたびに自動でテストを回す仕組み）に置きます。

1段目：構文（JSON として読めるか）

ページから application/ld+json の script 要素をすべて取り出し、JSON として読めるかを確かめます。末尾のカンマや、変数が空で "price": , になった状態はここで止まります。読めなければ構造化データ全体が無視されます。同時に同じ型が2つ以上ないかも数え、二重出力を拾います。

2段目：型（Schema.org として正しいか）

型とプロパティが Schema.org の語彙にあるかを確かめます。手で見るなら Schema Markup Validator（validator.schema.org）です。Google の旧「構造化データテストツール」の機能はここに移り、2021年8月9日に旧ツールは案内ページに替わりました。

Schema.org は年2回ほど更新され、2026年10月28日時点の最新は 2026年9月16日の Version 30.1（型826・プロパティ1,540）です。CI で語彙のファイルを使うなら、取り込んだ版を記録し、半年に1回更新します。

3段目：Google の要件（必須プロパティがあるか）

Schema.org として正しくても、Google の必須プロパティが欠ければ対象外です。手で見るなら Rich Results Test ですが、一括で呼ぶ公式 API は案内されていません（2026年10月28日時点）。そこで CI では、自分のサイトで使う型だけ、Google の必須・推奨プロパティを表にしたルールで確かめ、必須の欠落は止め、推奨の欠落は知らせます。

4段目：本文との一致

ヘッドレスブラウザでページを開き、価格・見出し・日付など本文にも出ている値を取り出して、JSON-LD の値と比べます。ガイドラインが「自動では確かめにくい」とする品質の項目のうち、機械で拾える部分をここで拾います。

4段目は書式の違い（「€ 1.299,00」と 1299.00）で誤検出が起きやすい段です。比べる前に数値と日付を正規化し、最初の2〜3週間は知らせるだけにして、ぶれを見てから止める検査に切り替えます。

見本URLの選び方

全ページを検査する必要はありません。ページの種類ごとに代表を決め、合計10〜20本を見本にします。種類ごとに「項目がそろったページ」と「欠けやすいページ（画像なし、翻訳直後など）」を1本ずつ入れると、型2を拾いやすくなります。

7. 公開後の監視：Search Console の拡張レポートと URL 検査

公開後は、Google が実際にどう読んだかを Search Console で確かめます。データの入力ミスや、見本に入っていないページの問題はここで見つかります。

拡張レポートの読み方

「拡張」の項目には、型ごとのリッチリザルトのステータスレポートが出ます。注意は3つです。数はページ数ではなくアイテム数、1つのアイテムが複数の問題を持っても無効の合計には1回だけ数える、例の一覧は最大1,000行。有効なアイテムは「重大な問題がなく表示されうるもの」で、有効でも表示は保証されません。

URL 検査 API で定点観測する

URL 検査 API を使えば、決めたURLのインデックス版で検出されたリッチリザルトと問題を毎週取り出せます。上限は1サイトあたり1日2,000回・1分600回で、数百本なら十分に収まります。

見るものは多くありません。週1回15分、無効アイテムの増減と API の結果の差分だけを見るのが続く形です。検索の数字全体の見方は「Search Console と GA4 の定点観測を自動化する」にまとめました。

修正の検証と「レポートから消えた」の区別

混同しやすいのが、型の表示が終わってレポートから消えたことと、問題が直ったことです。BigQuery では終了した型の列が NULL になり、NOT is_learning_videos のような条件が行を落とすと Google は注意しています。IS NOT TRUE のように NULL でも動く書き方にしておくと、型が終わっても集計が壊れません。

8. 多言語サイトでの inLanguage と hreflang の整合

日欧に向けたサイトで起きやすいのが、本文は翻訳されたのに、JSON-LD の言語や名前が元のままという食い違いです。

inLanguage と hreflang は役割が違う

inLanguage はそのコンテンツの言語を表す Schema.org のプロパティで、値は BCP 47 の言語コードです。hreflang はほかの言語版がどこにあるかを伝える仕組みで、言語は ISO 639-1、地域は ISO 3166-1 Alpha 2 のコードを使います（ja、en、en-NL など）。

Google は、hreflang や lang 属性でページの言語を判定してはいないと説明しています。間違えても検索の言語判定は狂いにくい一方、ほかのサービスがデータを読むときには間違った言語として伝わります。

そろえるべき5つの項目

Google の hreflang のドキュメントは、各言語版が自分自身とほかの全言語版を示すこと、相互の参照がないと無視されうることを求めています。構造化データの側も、これと矛盾しないようにそろえます。

最後の行は見落としやすい項目です。Organization の name を正式な登記名（オランダなら「B.V.」付き）にし、言語ごとの通称は alternateName に入れると、名前が揺れません。

翻訳の工程に JSON-LD を入れる

本文と同じデータから出していれば、翻訳されたデータからそのまま英語版の JSON-LD ができます。手書きが残っていれば、翻訳の対象に JSON-LD を入れるか、テンプレートに移します。対訳の管理は「日英2言語サイトの翻訳と更新を自動化する」で扱いました。CI では言語ごとに見本URLを用意し、inLanguage が locale と一致するかを確かめます。

9. AI 検索の時代に、構造化データはどう位置づくか

「AI 検索のために構造化データを足すべきか」という相談が増えています。推測が多い領域なので、公式に書かれていることだけを整理します。

Google の公式の説明

Google の「AI 機能とウェブサイト」のページは、AI Overviews や AI Mode に出るために追加の要件や特別な最適化はなく、AI 向けのファイルや特別な Schema.org の構造化データも要らないと明記しています。2026年6月15日には、llms.txt は Google 検索に必要なく、順位にも影響しないという注記も加わりました。

一方で同じページは、SEO の基本として構造化データが見えているテキストと一致していることを挙げています。AI 向けに足すより、今あるものを正確に保つことが公式の答えです。

AI 検索を理由に保守の方針を変える必要はありません。Google 以外の AI サービスの使い方は、公式の説明がないかぎり推測で設計に組み込まないのが安全です。ただし Organization の正式名称・ロゴ・識別子（オランダなら KvK 番号）は、Google のドキュメントのとおり同名の別組織と区別してもらう意味があるので、表示の有無に関係なく保守の対象に残してください。

10. 欧州で運用するときの注意

日欧で売るサイトは、構造化データでも欧州固有の条件を抱えます。ここでは3つを挙げます。

価格の表示ルールと、構造化データの価格

EU のオムニバス指令を受け、オランダでは2023年1月1日から、値引きの「元の価格」に過去30日の最低価格を使うルールが適用され、消費者・市場庁（ACM）は違反した通販に罰金を科しています。Google の Product のドキュメントは、元の価格を StrikethroughPrice として書く方法を示しています。本文の元の価格と構造化データの取り消し線価格が別のデータから出ていると、片方だけ法令に合わない状態が生まれます。

デジタル製品パスポートと EEA の表示

EU のデジタル製品パスポート（DPP）は、欧州委員会によると登録簿が2026年7月20日に稼働し、2027年2月18日から一部の電池で義務になります。Schema.org は30.1で DPP を結びつける語彙を加えましたが、Google が検索で使うかは公表されていません。法令対応としてデータを持ち、構造化データに出すかは別に判断します。また EEA では、デジタル市場法への対応として、2024年から旅行・地域・買い物の検索で構造化データを使ったカルーセル（ベータ版）が出ています。

日本と欧州で比べる

同じテンプレートでも、値の書式と、値が満たすべきルールが地域で変わります。日欧で売るなら、価格と日時の正規化を4段目に必ず入れてください。

11. 点検の頻度とチェックリスト

自動化しても、人が見るべき場面は残ります。何を、どの頻度で、誰が見るかを決めます。

頻度の目安

間違うと損害が出るもの（価格・在庫）ほど頻度を短くし、デプロイのたびに止めます。

時間は DevNJ の目安です。毎週15分で済む状態を作ることが自動化の目標です。

12. 費用と工数の幅

次は DevNJ の目安で、統計ではありません。外注の時間単価は80ユーロ、円は1ユーロ＝175円で換算しています。

段階2の月額は CI の実行時間の超過分程度、段階3はクロール用のサーバーや有料のクローラーを使うかで変わります。

手作業との比べ方

自動化の価値は、ツール代より人の時間と、気づくまでの日数で測ります。

月6〜10時間が1〜2時間になれば、単価80ユーロ換算で月およそ320〜720ユーロ分の時間が浮きます。手書きの箇所が多い、プラグインが3つ以上構造化データを出す、言語が3つ以上ある、商品が数千点ある、のいずれかに当たると、費用は幅の上限に近づきます。

13. よくある失敗

よく見る失敗を、原因と対策で整理します。いずれも検査より設計で防ぐほうが安く済みます。

2行目は、Google の「ユーザー第一のコンテンツ」のページが内容を変えずに日付だけを新しくすることを検索エンジン向けの兆候に挙げている点とも関わります。

やってはいけないこと

保守の自動化でやってはいけないことを挙げます。

14. ケースで考える（架空の3社）

ここからは、架空の3社で、どの段階まで自動化するかを考えます。実在の企業ではありません。

A社は二重出力を止めて会社情報を1つの Organization にまとめるだけで、初期12時間前後・月額0ユーロに収まります。B社は「€ 12,50」の表記が JSON-LD に入っていたため、価格を数値データから出し直し、30日最低価格の元の価格も同じデータから出します。C社はページが少ないので、段階1で足ります。

15. 導入の手順：4週間で進める

4週間で導入する手順です。週ごとの作業は1〜2日分を目安にしています。

1. 1週目：棚卸し。ページを種類に分け、見本URLを2本ずつ選びます。JSON-LD の型と、出している仕組み（テーマ、プラグイン、タグマネージャー、手書き）を一覧にし、二重出力と終了した型に印を付けます
2. 2週目：設計書とテンプレート。ページの種類と型の対応表を作り、価格・日付・言語を本文と同じデータから出す形に寄せます。Organization の @id を決めます
3. 3週目：CI の4段。1段目と2段目を止める検査として入れ、3段目と4段目は知らせるだけで始めます
4. 4週目：監視と定例。URL 検査 API の週次取得を組み、拡張レポートを見る担当と曜日、四半期の確認を予定に入れます
5. 5週目以降：切り替え。誤検出の幅を見て、必須の欠落と価格・在庫の不一致を止める検査に切り替えます

要点は、最初から全部を止めないことです。誤検出で公開が止まり続けると、検査そのものを外したくなります。

16. チェックリスト

導入時と四半期ごとに、次の項目を確かめてください。

設計

• ページの種類と出す型の対応表（設計書）がある
• 価格・日付・営業時間・著者・言語は、本文と同じデータから出している
• 同じ型を2つの仕組み（テーマとプラグインなど）が出していない
• Organization は1つの @id で、全言語で同じ値を使っている

CI

• 見本URLが種類ごと・言語ごとにあり、合計10〜20本以上ある
• JSON として読めない、同じ型が重複する場合は公開を止める
• Schema.org の語彙の版を記録し、半年に1回更新している
• Google の必須プロパティの欠落は止め、推奨の欠落は知らせる
• 価格と在庫は本文と突き合わせ、小数点と通貨を正規化している

監視と運用

• 拡張レポートを週1回見る担当と曜日が決まっている
• URL 検査 API で、見本と主要ページを週1回取り出している
• 四半期に Google の更新履歴を、自分のサイトで使う型の名前で確かめている
• 多言語の各版で inLanguage と hreflang がそろい、相互に指している

17. まとめ

• 構造化データは、入れた日がいちばん正確で、放っておくと本文とずれていく。保守の目標は「表示を出す」より「間違ったことを書かない」に置く
• Google のリッチリザルトは2023年から縮小が続き、HowTo は2023年9月、FAQ は2026年5月7日に表示を終えた。使われていない構造化データは害にならないが、保守の手間は残る
• 壊れ方はテンプレートの変更・必須の欠落・表示との不一致・廃止された型・多言語の食い違いの5つ。うち3つは、本文と同じデータからテンプレートで生成すれば起きにくくなる
• デプロイのたびに、構文・型・Google の要件・本文との一致の4段を CI で確かめ、公開後は拡張レポートと URL 検査 API を週1回見る
• 多言語サイトでは inLanguage・hreflang・Organization の @id をそろえ、欧州向けでは価格の小数点と30日最低価格のルールに注意する
• AI 検索のために特別な構造化データは要らないと Google は明記している。今あるものを正確に保つほうが先

参考にした情報源

Google 検索セントラル（構造化データ）

• Introduction to structured data markup in Google Search — Google Search Central：構造化データの用途
• General structured data guidelines — Google Search Central：技術・品質のガイドライン
• Structured data markup that Google Search supports — Google Search Central：2026年10月時点で対応している25項目
• Latest Google Search Documentation Updates — Google Search Central：FAQ の終了（2026年5月7日）
• Changes to HowTo and FAQ rich results — Google Search Central Blog：2023年8月の縮小と9月の HowTo 終了
• Simplifying the search results page — Google Search Central Blog：2025年の7種の終了
• Here's an update on our efforts to simplify the search results page — Google Search Central Blog：2025年11月の追加の整理
• Article structured data — Google Search Central：必須なし
• Organization structured data — Google Search Central：置く場所と組織の区別
• Breadcrumb structured data — Google Search Central：パソコンだけの表示
• Product snippet structured data — Google Search Central：必須プロパティと価格の小数点
• Merchant listing structured data — Google Search Central：取り消し線価格
• Generate structured data with JavaScript — Google Search Central：タグマネージャーで情報を複製しない
• Influence your byline dates in Google Search — Google Search Central：表示する日付と構造化データの日付
• New Search experiences in EEA — Google Search Central Blog：EEA の構造化データのカルーセル

Google 検索セントラル（多言語・AI・品質）

• Tell Google about localized versions of your page — Google Search Central：hreflang の相互参照
• AI features and your website — Google Search Central：AI 機能に特別な構造化データは不要
• Creating helpful, reliable, people-first content — Google Search Central：日付だけを新しくすることへの注意

Search Console

• Rich result status reports — Search Console ヘルプ：有効・無効の定義
• Usage limits — Search Console API：URL 検査の上限
• Rich Results Test — Google：Google の要件の確認

Schema.org・W3C・調査

• Schema.org releases — Schema.org：Version 30.1（2026年9月16日）
• Schemas — Schema.org：型826・プロパティ1,540
• inLanguage — Schema.org：BCP 47 の言語コード
• Schema Markup Validator — Schema.org：型とプロパティの確認
• JSON-LD 1.1 — W3C：2020年7月16日の W3C 勧告
• Structured Data — HTTP Archive Web Almanac 2024：書式ごとの利用率と FAQPage の推移

欧州の制度

• ACM wil einde aan nepkortingen na komst strengere regels — ACM：2023年1月からの30日最低価格のルール
• ACM legt boetes op aan webwinkels voor nepkortingen — ACM：値引き表示の罰金の事例
• Digital Product Passport — European Commission：DPP の概要
• Batteries (Digital Product Passport) — European Commission：登録簿の稼働（2026年7月20日）と電池の義務化（2027年2月18日）

いずれも2026年10月28日に確認したものです。Google の対象となる型や要件は変わるため、導入の前に公式の更新履歴で最新の情報を確認してください。費用と工数、点検の頻度は DevNJ の実務上の目安で、サイトの規模と構成によって変わります。