Schema.orgとJSON‑LD、そしてSEO最適化の関係

仕事をしていると、いつもの作業が違った意味を持って見えてくる瞬間があります。

先人が教えてくれた通り、インターネットで見つけた例を真似して、深く考えずに作業を進めていると、作業が手に馴染む頃にふと頭に何かが浮かびます。

「これをやる意味は？」
「この人はどんな考えで作ったのか？」

その質問に自分で答えを見つけた瞬間、私はこれをちょっとした気づきと呼びます。

私にとってはschema.orgとJSON‑LDの作成がその一例でした。

初心者の頃は、「検索エンジンが理解しやすくするためのSEO対策」としてHTMLの上部に機械的に貼り付けていたものが、ある時を境に意味合いを変え始めました。

この投稿では、ウェブアプリケーションを作る中で気づいたschema.orgの根本的な存在理由と、「SEOを超えて」どのように活用できるかについて解説します。

世界中のオブジェクトをタグ付けし、関係を作る開発者の姿

私が気づいたこと：schema.orgは検索エンジン専用ではなかった

今回、schema.orgのドキュメントを徹底的に読んでみると、以前は見落としていた核心が見えてきました。

schema.orgは単に検索エンジンのためだけの仕組みではなかった。 ウェブ上であるか否かにかかわらず、世界中のあらゆる対象（物、ウェブページ、人、組織、事件など、あらゆるもの）をJSON形式で分類・体系化し、コンピュータで処理しやすいデータにするための「共通スキーマの取り決め」に近いものです。

実際、人間は元々それぞれの方法で分類・体系化します。 しかし問題は、誰が使い、誰が読むかによって基準が変わることです。schema.orgは、その基準を「普遍的に」統一するための取り決めと言えます。

そこで私はschema.orgの本質を次のようにまとめました。

Schema.org = 「世界のためのデータ規格」

検索エンジンを超え、ウェブ上のあらゆる情報を機械が読める（Machine‑readable）構造にするための、世界的な取り決めと言えるでしょう。

例えば、同じ意味を次のように呼びます。

  • 「著者」
  • 「Author」
  • 「作成者」

しかしschema.orgではこう統一します。

  • @type: Person
  • name: ...

言語が違っても、チームが違っても、システムが違っても「その意味」を同じにします。

こう整理すると起こること：『関係網』ができる

schema.orgを単に「検索エンジン用メタデータ」と見ると、行う作業はフィールドを埋めるだけです。

しかし「世界のデータ規格」と見ると、視点が一変します。

オブジェクト中心の接続が可能になる

人、場所、事件、物など、世界中のすべての『エンティティ』が互いに結びつきます。

  • ある記事のauthorが誰か
  • そのauthorがどのOrganizationに属しているか
  • その組織のurlとsameAsは何か

こうした情報が連結されると、機械は単一ページを読むだけでなく、関係網（グラフ）を描き始めます。

データのコンピュータ化がはるかに速くなる

オブジェクト中心のプログラミング言語が世界を変えてきたように、こう整理されたデータはサービス開発、統合、分析を迅速にします。 そしてここで私は叫びました。

「これがまさに…schema.orgの存在理由だったんだ！！」

これまで私はこれを「検索エンジンが好む構造を作るツール」としか考えていませんでした。この哲学を今になって悟るとは！

さらに面白くなるのはここからです。

内部データ通信規格をschema.orgベースに合わせることで、後で他サービスと連携したり、AIモデルにデータを投入したりする際に、別途の変換プロセスなしに「意味」を伝える可能性が高まります。

これはかなり大きな利点になると確信しています。

哲学を知ったら、やってみよう：SEOは「活用先の一つ」にすぎない

哲学を悟ると欲張りになります。 「これをSEOだけに使うのはもったいない」

しかし直面する現実もあります。

直面する問題

  • schema.orgのドキュメント量は本当に膨大で、すべてを把握するのは事実上不可能です。
  • 種類が多すぎて、「どのジャンルにどの属性を入れるか」以前に構造自体を決めるのが難しい。

そこで私は最低限これだけは整理しておくべきだと考えました。

これだけ知っておこう 1：JSON‑LDでの@マークの正体

JSON‑LDで@が付くキーワードは、一般データではなくJSON‑LD自体のルールを定義するメタ情報です。 内容（name, url, image…）と、その内容の規格（@type, @context…）を分離するために存在します。

まずよく使う3つだけ知っておけば十分です。

@context: 「私が使う単語の辞書はどこ？」

"@context": "https://schema.org"

この一行はこう宣言します。

「これから私が使うname、authorなどの単語はschema.orgの辞書に従うものとする」

@type: 「このデータブロックの正体は何？」

"@type": "BlogPosting"

Person、Organization、Article、Productなどの「オブジェクトの種類」を指定します。

@id: 「このオブジェクトの一意識別子は何？」

"@id": "https://example.com/posts/schema-org"

世界中で唯一このオブジェクトを指し示せる名前タグのようなものです。通常はURLを指定します。

まとめるとこうです。

  • name、urlなどのキーは 内容
  • @context、@type、@idなどのキーは 容器の規格

これだけ知っておこう 2：どのジャンルにどの属性を入れるか探し方

schema.orgは世界中のすべてを扱おうとするため、数千ものタイプがあります。 すべてを暗記しようとすると疲れます。代わりに階層構造をたどる方法が現実的です。

1) 最上位オブジェクトThingから始める

すべてのオブジェクトの祖先はThingです。 ここで基本的な属性が共有されています。

  • name
  • description
  • url
  • image

そして枝分かれします。

  • 人か？ → Person
  • 場所か？ → Place
  • 無形の著作物か？ → CreativeWork（ブログ投稿、書籍、映画など）
  • 組織か？ → Organization

ウェブページの投稿なら、ほぼCreativeWork系から始めます。

2) 「全部埋める」ではなく「コアから」埋める

schema.orgページの下部にあるProperties from ...リストを見ます。 そこに出てくるものを中心に埋めますが、すべて埋める必要はありません。

最初はこう考えると楽です。

  • 検索エンジンが要求する必須に近いもの
  • このオブジェクトを説明するのに必ず必要なもの

3) 最も簡単な道：Google構造化データガイドを答え合わせに使う

schema.org公式ドキュメントは膨大で、最初は疲れます。 代わりにGoogleは、ウェブでよく使われるジャンル別に「推奨される属性」をまとめています。

  • 記事（Article）
  • Breadcrumb
  • Event
  • FAQ
  • Product
  • Review …など。

リンク: Google 検索がサポートする構造化データ マークアップ

ウェブ開発者であれば、このページは必ずブックマークに入れておきましょう。

例：BlogPostingの最小形（感覚を掴むため）

以下は「ざっくりこうなっている」感覚を掴むための例です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/posts/schema-ldjson-seo",
  "headline": "Schema.orgとJSON‑LD、そしてSEO最適化の関係",
  "datePublished": "2026-02-04",
  "author": {
    "@type": "Person",
    "name": "jesselab"
  }
}
</script>

この程度を記述すれば、この記事が「何であるか」「誰が書いたか」「いつ発行されたか」といった主要な情報がかなり明確になります。

締めくくり：私は今、schema.orgを違う目で見る

以前の私はschema.orgを「SEOのためのチェックリスト」とみなしていました。 そのため作業も単に「埋める」だけでした。

しかし今は違います。

schema.orgは世界をデータで表現するための約束であり、JSON‑LDはその約束をウェブに乗せる形式、SEOはその結果得られる多くの利点の一つに過ぎません。

こうした視点の変化で「なぜやるのか」がはっきりし、作業は単なるコピー＆ペーストではなく設計へと変わります。

私にとってそれが今回のちょっとした気づきでした。