JSON-LD誕生の歴史とは？W3C標準化からGoogle推奨までの変遷を解説

JSON-LDは、2010年にW3Cのコミュニティグループで開発が始まり、2014年1月16日にW3C勧告として標準化された構造化データの記述形式です。2020年7月には1.1が勧告され、旧1.0はSuperseded（後継規格への置き換え）となりました。GoogleはSEO向け構造化データの形式としてJSON-LDを推奨しており、実装や管理のしやすさが評価されています。本記事では誕生の背景から標準化の年表、Google採用の理由、検索以外への広がりまでを一次情報に基づき時系列で解説します。

JSON-LDの歴史とは？結論を先出しで解説

JSON-LDの歴史は、大きく4つの段階に分けて理解できます。2010年の誕生、2012〜2014年のW3C標準化、Googleによる推奨とSEOへの浸透、そして検索を超えた多用途化という流れです。まずはこの全体像を押さえてから、各段階の詳細を見ていきます。

そもそもJSON-LD（JSON for Linked Data）とは何か

JSON-LDとは、通常のJSON形式にリンクトデータの意味情報を追加できるように設計された、W3CによるRDFの直列化（シリアライズ）形式です。名称の「LD」はLinked Data（リンクトデータ）を指し、Webページ内の情報を機械が読み取り、Web上の他のデータと結びつけて理解できるようにすることを目的としています。開発当初のステータスは「Year started 2010」とされ、現在もW3C Recommendation（勧告）として位置づけられています（出典）。

JSON-LDは、専用の解析器を使わずとも通常のJSONパーサーで処理できる点が特徴です。@contextや@typeといった特別なキーを使うことで、既存のJSON文書に少し手を加えるだけで意味構造を付与できます。この設計思想が、後述するGoogleの採用理由にも直結しています。

なぜ今「JSON-LDの歴史」を知る意味があるのか

結論として、JSON-LDが「なぜ生まれ、なぜ標準になったか」を理解すると、構造化データを導入する際の判断基準がより明確になります。単に実装方法を知るだけでなく、標準化の背景にある設計思想を知ることで、AI検索時代における構造化データの役割まで見通せるようになります。

TechSuite株式会社の「AI検索パートナーズ」は、生成AIが引用・推薦する仕組みを構造化データや意味的文脈、エンティティ認識の観点から技術的に捉え、LLMO・GEO・AEOの施策を一次情報設計まで踏み込んで支援しています。JSON-LDの歴史的経緯を踏まえた設計は、こうした技術的アプローチの土台にもなっています。

フェーズ	時期	主な出来事	意味
誕生期	2010年〜	コミュニティグループで開発開始	草の根での仕様策定
標準化期	2012〜2014年	W3C勧告（1.0）	国際標準としての承認
普及期	2014年以降	Google推奨・SEO活用	実務での本格採用
多用途化期	2018年以降	1.1勧告・VC・IoTへの応用	検索を超えた基盤技術化

JSON-LDはなぜ誕生したのか？背景と設計思想

JSON-LDが誕生した最大の理由は、既存のRDF/XMLやMicrodata・RDFaが実装者にとって扱いにくく、開発者に馴染みのあるJSON形式でリンクトデータを表現する手段が求められたためです。開発者が使い慣れたJSONの延長として意味情報を付与できる仕組みを作ることが、当初からの狙いでした。

RDF/XMLやMicrodata・RDFaが抱えていた実装の難しさ

RDF/XMLは冗長な記法が多く、MicrodataやRDFaはHTML本文にタグを埋め込む形式であるため、既存のマークアップに手を加える必要があり、実装や保守の負荷が高いという課題がありました。特にRDF/XMLはWebアプリケーション開発者にとって学習コストが高く、広く普及するには至りませんでした。

一方でMicrodataやRDFaは、HTMLの属性としてitemscopeやvocab、propertyなどを本文中に追加する形式です。本文構造とマークアップが密結合するため、デザイン変更や実装修正の際にデータ構造まで崩れてしまうリスクが指摘されていました。

「既存JSONからの移行労力を減らす」という設計思想

JSON-LDの設計目標のひとつは、開発者が既存のJSONをJSON-LDに変換する労力をできる限り減らすことでした。専用ツールを使わずに、通常のJSON文書へわずかな修正を加えるだけでLinked Dataを作成できることを目指した設計です（出典）。

この思想により、すでにAPIレスポンスなどでJSONを扱っていた開発者は、大きな学習コストをかけずにセマンティックWebの世界に参加できるようになりました。TechSuite株式会社の「AI検索パートナーズ」は、こうした構造化データの設計思想を踏まえ、検索意図や想定質問を分解して高品質な構造化コンテンツを設計する仕組みを、自社の「バクヤスAI記事代行」事業で培った制作エンジンとして活用しています。

@context・@type・@idでJSONに意味を与える仕組み

JSON-LDは「context」の概念に基づき、JSONのプロパティをオントロジーの概念、つまりRDFモデルへマッピングします。contextは文書に埋め込むことも、別ファイルとしてHTTP Linkヘッダで参照することも可能です（出典）。

また解決可能なIRIを使うことで、リンク先の追加RDF文書をたどり新しいデータを発見できます。この原則は「Follow Your Nose」と呼ばれ、FOAF（Friend of a Friend）などの語彙で人物や関係性を表す際に活用されてきました。

形式	記述方式	本文との結合度	実装難易度
RDF/XML	XMLタグ	低い	高い
Microdata	HTML属性	高い	中程度
RDFa	HTML属性	高い	中程度
JSON-LD	scriptタグでJSON埋め込み	低い	低い

JSON-LDはいつW3C勧告になったのか？標準化の年表

JSON-LD 1.0は2012年のWorking Draftから始まり、2014年1月16日にW3C勧告となりました。開発は当初「JSON for Linked Data Community Group」で進められ、その後RDF Working Groupに移管されて評価・改善・標準化が行われています。

2010年、JSON for Linked Data Community Groupで開発開始

JSON-LDは2010年にJSON for Linked Data Community Groupという有志の集まりで開発が始まり、その後W3CのRDF Working Groupへ引き継がれて標準化が進められました。編集者にはGregg Kellogg、Pierre-Antoine Champin、Dave Longleyが名を連ね、以前の編集者としてManu Sporny、Markus Lanthalerが関わっています。著者にはManu Sporny、Dave Longley、Gregg Kellogg、Markus Lanthaler、Niklas Lindströmの名前が記録されています（出典）。

コミュニティグループで生まれた仕様が、Web標準を管轄するW3Cの正式なワーキンググループに引き継がれたという経緯は、実務ニーズから生まれた技術が国際標準へ格上げされた好例といえます。

2012年Working Draftから2014年1月16日のW3C勧告まで

W3Cの公開履歴によると、JSON-LD 1.0は2012年7月12日にWorking Draftとして公開され、2013年4月11日にLast Call Working Draft、2013年9月10日にCandidate Recommendation、2013年11月5日にProposed Recommendationを経て、2014年1月16日に正式なRecommendation（勧告）となりました（出典）。

この一連のステップは、W3Cが仕様を段階的にレビューし、実装可能性や相互運用性を確認しながら標準化を進める標準的なプロセスです。約1年半にわたる審査を経て国際標準として確立されたことがわかります。

開発を支えた主要人物と団体の変遷

JSON-LDの標準化プロセスは「Community Group→RDF Working Group→JSON-LD Working Group」という団体の変遷をたどっています。現在はJSON-LD Working Groupが仕様の保守を担っており、Web標準としての継続的な運用体制が敷かれています。

TechSuite株式会社の「AI検索パートナーズ」は、こうした標準化プロセスのように業種・規模・課題ごとの構造やボトルネックを丁寧に捉え、企業ごとに構造化データの実装状況を個別診断し、解決策の提示から実行までを伴走する形でLLMO対策を支援しています。標準化の変遷を知ることは、自社サイトの構造化データが今どの段階にあるかを見極める手がかりにもなります。

日付	ステータス	内容
2012-07-12	Working Draft	最初の草案公開
2013-04-11	Last Call WD	最終草案として意見募集
2013-09-10	Candidate Recommendation	実装検証段階へ移行
2013-11-05	Proposed Recommendation	正式勧告の提案
2014-01-16	Recommendation	W3C勧告として確定
2020-11-03	Retired	1.1により後継化

JSON-LD 1.0から1.1でどう変わったのか？

JSON-LD 1.1は2018年9月11日のFirst Public Working Draftから始まり、2020年7月16日にW3C勧告となりました。これにより1.0はSuperseded Recommendation、さらに2020年11月3日にRetiredという扱いに変わっています。

JSON-LD Working Groupの発足と2018年のFPWD

1.1の策定は専門のJSON-LD Working Groupが発足したことで本格化し、2018年9月11日にFirst Public Working Draftが公開されました。1.0を策定したRDF Working Groupとは別に、JSON-LD専属のワーキンググループが立ち上がったことは、この仕様がRDF全体の中でも独立した重要性を持つと認められた証といえます。

その後複数回のWorking Draft、Candidate Recommendationの改訂を重ねながら仕様の精緻化が進められ、2020年5月7日にProposed Recommendationへ到達しています。

2020年7月16日の1.1勧告と1.0のSuperseded・Retired化

2020年7月16日、JSON-LD 1.1はW3C勧告として正式に承認されました。これにより1.0はSuperseded Recommendation（後継仕様に置き換えられた勧告）となり、さらに同年11月3日には公開履歴上でRetired（廃止）扱いに変更されています（出典）。

ただしRetiredとはいえ、既存の多くの実装は1.0の記法をベースにしており、後方互換性が意識された設計になっているため、1.0時代のマークアップが即座に無効になるわけではありません。

1.1で強化されたcontext・framing・処理アルゴリズム

1.1では、contextの入れ子や複数値の扱い、フレーミング（framing）と呼ばれるデータ整形処理、APIや処理アルゴリズムの明確化などが強化されました。加えて、RDF Dataset Canonicalizationという正規化の仕組みが整理され、順序の異なる2つのJSON-LD文書が同じ情報を表す場合でも、正規形にしてから署名できるようになりました。これは後述するVerifiable Credentialsの署名基盤としても重要な意味を持ちます（出典）。

TechSuite株式会社の「AI検索パートナーズ」は、技術的アプローチを担う人材とAIを活用したコンテンツ制作人材が一つのチームで連携し、戦略設計から技術実装、効果測定、改善までを一気通貫で支援する体制を敷いており、こうした仕様変化への追従も体制面から支えています。

項目	1.0	1.1
勧告日	2014-01-16	2020-07-16
現在の位置づけ	Retired	現行のRecommendation
context処理	基本的な単一階層	入れ子・複数値対応を強化
正規化処理	限定的	Dataset Canonicalizationを整備

なぜGoogleはJSON-LDを推奨しているのか？

Googleが構造化データの形式としてJSON-LDを推奨する最大の理由は、実装と管理が最も容易でユーザーエラーが少ないことです。Schema.orgの語彙と組み合わせることで、検索結果でのリッチリザルト表示にもつながります。

Schema.org・Google Knowledge Graphとの結びつき

JSON-LDはSchema.orgの語彙と組み合わせて使われることが多く、Googleのナレッジグラフが情報を整理・理解するための重要な手がかりとして機能しています。GoogleはJSON-LD、Microdata、RDFaの3形式に対応していますが、多くの場合でJSON-LDを推奨形式としています（出典）。

JSON-LDは<script type="application/ld+json">としてページの<head>や<body>に埋め込む形式で記述され、本文のHTML構造とは独立して管理できます。この分離性が、CMSやテンプレートを使った大規模な運用にも向いている理由です。

「実装と管理が最も容易でユーザーエラーが少ない」という理由

Googleの検索セントラルでは、JSON-LDが構造化データの中でも実装・管理のしやすさに優れる形式として位置づけられています。本文のマークアップに手を加えずにデータブロックとして追加・削除できるため、デザイン変更やテンプレート改修時にも構造化データが崩れにくいという利点があります。

また、data-vocabulary.orgを使ったマークアップは2020年1月の告知以降、Googleのリッチリザルトでサポートが終了しており、現在の検索用構造化データはSchema.orgの語彙を使うことが標準になっています（出典）。旧来の語彙から現在の標準への移行が進んだことも、JSON-LD普及の後押しになりました。

リッチリザルトの効果が示す導入企業の実績値

構造化データの導入効果は、Google自身が公開している実績値からも読み取れます。TechSuite株式会社の「AI検索パートナーズ」が支援するAI検索経由の受注率は、従来のSEO経由と比較して約3倍という実績があり、露出や順位ではなく受注という成果に直結させることを重視しています。構造化データの整備も、こうした成果につながる土台のひとつです。

実際に、Rotten Tomatoesは構造化データを10万ページに追加したことでクリック率が25%向上し、The Food Networkは全ページの80%で構造化データを有効化してアクセスが35%増加したと報告されています。楽天は滞在時間が1.5倍に、Nestléはリッチリザルトが表示されたページでクリック率が82%向上したという結果も示されています（出典）。

企業・サービス	取り組み	成果
Rotten Tomatoes	10万ページに構造化データを追加	CTR+25%
The Food Network	全ページの80%で機能を有効化	アクセス+35%
楽天	構造化データを活用	滞在時間1.5倍
Nestlé	リッチリザルト対応	CTR+82%

こうした背景を理解しておくと、LLMO対策の具体的な進め方を検討する際にも、構造化データをどの範囲まで整備すべきかの判断材料になります。

検索を超えた広がりとAI検索時代の価値とは？

JSON-LDはSEO目的の構造化データだけでなく、Verifiable Credentials、ActivityPub、IoTのThing Descriptionなど、検索以外の多くの技術基盤にも採用されています。生成AI検索が広がる現在では、機械可読データとしての価値がさらに注目されています。

Verifiable CredentialsとVC規格の分裂

JSON-LDはW3CのVerifiable Credentials Data Modelにも採用され、@contextを通じて意味論を外部参照する仕組みが、デジタル証明書の相互運用性を支えています。ただしVCの規格は後にmDoc/mDL、SD-JWTといった形式にも分裂しており、単一の標準に収まらず併存している状況です（出典）。

順序の異なる2つのJSON-LD文書が同じ情報を表す場合があるため、完全性検証にはRDF Dataset Canonicalizationで正規形に変換したうえで署名する仕組みが採用されています。これがVerifiable Credentialsの署名基盤の一部になっています（出典）。

ActivityPub・IoTのThing Descriptionへの応用

JSON-LDはActivity Streamsの記述形式としても採用されており、これは分散型SNSの基盤プロトコルであるActivityPubの土台にもなっています。さらにIoT分野では、モノの機能や通信方法を機械可読に記述するWeb of ThingsのThing Descriptionにも使われており、SPDXなどのソフトウェア部品表の記述にも応用されています（出典）。

検索以外の分野に広がった背景には、JSON-LDが特定のドメインに依存せず、汎用的な意味構造を表現できる柔軟性があります。

AI検索（LLMO/GEO）時代におけるJSON-LDの位置づけ

JSON-LDは初めてW3C勧告となった2014年以降、10年以上にわたって利用が拡大し続けており、Schema.orgを使ったSEO向け構造化データとして人気の選択肢であり続けています。現在のJSON-LD Working Groupの憲章は2028年1月まで設定されており、今後も継続的な仕様の見直しが予定されています（出典）。

TechSuite株式会社の「AI検索パートナーズ」は、自社サイトにおけるAI Share of Voiceが高水準を維持しており、支援先ではAI Overviewの引用率を改善した実績があります。JSON-LDによる機械可読な情報整理は、こうしたAI検索での引用・推薦のされやすさにも影響する要素のひとつです。構造化データの歴史を理解したうえで、LLMOとは何かという基礎から見直すことも、AI検索時代の対策として有効です。あわせてAI検索最適化に関する用語の整理も参考にしていただくと理解が深まります。

分野	概要	関連技術
Verifiable Credentials	デジタル証明書の相互運用	RDF Dataset Canonicalization
ActivityPub	分散型SNSの基盤	Activity Streams
Web of Things	IoT機器の機能記述	Thing Description
ソフトウェア部品表	依存関係の記述	SPDX

よくある質問

JSON-LDは誰が作ったのですか？

JSON-LDは2010年にJSON for Linked Data Community Groupという有志の集まりで開発が始まりました。編集者にはGregg Kellogg、Pierre-Antoine Champin、Dave Longleyが、以前の編集者にはManu Sporny、Markus Lanthalerが名を連ねています。その後W3CのRDF Working Groupに引き継がれ、正式な標準化プロセスに乗りました。

JSON-LDはいつW3C勧告になりましたか？

JSON-LD 1.0は2014年1月16日にW3C勧告となりました。その後1.1が2020年7月16日に勧告され、1.0はSuperseded、さらに同年11月3日にはRetiredという位置づけに変わっています。

なぜGoogleはJSON-LDを推奨しているのですか？

Googleは構造化データの形式としてJSON-LD、Microdata、RDFaの3形式に対応していますが、実装と管理が最も容易でユーザーエラーが少ないという理由から、多くの場合でJSON-LDを推奨しています。本文のHTML構造と分離して記述できる点も、大規模な運用に向いています。

JSON-LDは検索以外にも使われていますか？

はい。JSON-LDはSchema.orgを使ったSEO目的以外にも、Verifiable Credentialsによるデジタル証明、ActivityPubを基盤とする分散型SNS、IoT機器の機能を記述するWeb of ThingsのThing Description、SPDXといったソフトウェア部品表の記述など、幅広い分野で応用されています。

まとめ

JSON-LDは2010年にコミュニティグループで誕生し、W3CのRDF Working Groupを経て2014年1月16日にW3C勧告となりました。2020年7月には1.1が勧告され、旧1.0はSuperseded・Retiredという位置づけに変わっています。

Googleは実装と管理の容易さを理由にJSON-LDを構造化データの推奨形式としており、リッチリザルトによる実際の成果も報告されています。さらにVerifiable CredentialsやActivityPub、IoTなど検索以外の分野にも応用が広がり、AI検索時代における機械可読データとしての価値も高まっています。

誕生から現在までの流れを一枚の年表として押さえておくことで、自社の構造化データ対応やLLMO・GEO対策を検討する際の判断材料として役立てられます。

参考にした情報源

• JSON-LD – Wikipedia（日本語版）
• Application/ld+json – Wikipedia（英語版）
• 構造化データマークアップの入門編 – Google 検索セントラル
• JSON-LD 1.0 publication history – W3C
• JSON-LD 1.1 publication history – W3C
• JSON-LD Working Group Charter – W3C