型選定の判断プロセス (WebPage / Service / Organization / Audience / Country)

この章の位置づけ

本ガイドの中核章です。「自サイトでどの schema.org 型を使うか」を決める判断プロセスを、再現可能な思考フローとして整理します。

題材ははじめにで導入した架空の B2B SaaS Acme Workflow のサービス紹介ページです。以下の構造を組み立てるプロセスを解説します。

WebPage (ルート型)
├── isPartOf → WebSite (親サイト参照)
└── mainEntity → Service (このページの主題)
    ├── provider → Organization (提供者: Acme Inc.)
    ├── audience → Audience (対象: 業務担当者)
    └── areaServed → Country (提供地域: Japan)

各型を なぜ選んだか / 何を却下したか を順に説明します。

判断 1: ルート型に `WebPage` を選ぶ

何を表現したいか

「コーポレートサイトの 1 ページ」というメタ情報
ページタイトル / 説明文 / URL
このページが属するサイト (isPartOf)
このページの主題 (mainEntity)

候補

候補型	適する用途	今回の適否
`WebPage`	汎用的な Web ページ	✅ 採用
`Article`	ニュース / ブログ記事 / 解説記事	❌ サービス紹介は記事ではない
`Product`	物販商品ページ	❌ サービスは無形
`Organization` (単独)	組織情報のみのページ	❌ サービス情報が主題

WebPage は CreativeWork の派生型で、Web ページ全般を表す 最も汎用的なルート型 です。サービス紹介ページのように「記事 / 商品 / 組織紹介のいずれにも当てはまらない」場合、WebPage を選びます。

WebPage のサブクラス

schema.org には AboutPage / ContactPage / FAQPage / ItemPage 等の WebPage サブクラスもあります。ページの性質が明確 (例: 「会社概要」なら AboutPage) であれば、より具体的なサブクラスを選びます。サービス紹介ページは ItemPage (商品 / サービス紹介) を選ぶことも検討に値しますが、本ガイドでは汎用性を優先して WebPage を採用しました。

判断 2: `mainEntity` でページ主題を 1 つだけ宣言する

02 章で述べた通り、schema.org 公式の見解は明確です。

about can refer to multiple entities/topics, while mainEntity should be used for only the primary one

(about は複数のエンティティを参照できるが、mainEntity は主たる 1 つにのみ使う)

と明記しています。ページの主題は 1 つに絞る のが原則です。

`mainEntity` を使う意味

WebPage 自身が持つ name description は「ページ自体の情報」ですが、mainEntity は 「このページが何を語っているか」 を別レイヤーで宣言します。検索エンジンはこの主題を見て、ページの本質を理解します。

参照: schema.org/mainEntity / Schema.org Data Model — background notes (確認: 2026-06)

`mainEntity` を複数定義した場合の問題

複数主題を抱えるページは、そもそも「主題が曖昧」というサイト設計上の問題を抱えていることが多いです。検索エンジンの観点でも、主題が拡散したページは順位が安定しません。やむを得ず複数概念を扱うなら、ItemList で並列要素として表現するなど、別の構造を検討します。

判断 3: `mainEntity` の型に `Service` を選ぶ

主題は「Acme Workflow という SaaS」です。これを何の型で表現するかが次の判断です。

候補

候補型	性質	今回の適否
`Service`	無形のサービス (継続提供)	✅ 採用
`Product`	有形 / 単発購入の物品	❌ SaaS は買い切り物品ではない
`SoftwareApplication`	ダウンロード型ソフトウェア	△ SaaS には不適 (後述)
`WebApplication`	Web ベースアプリケーション	△ 選択肢になるが (後述)

Service は Intangible 配下で、「継続提供される無形のサービス」を表します。SaaS のように 継続契約で利用するサービス は Service がもっとも素直な選択です。

SoftwareApplication / WebApplication を選ばなかった理由

SoftwareApplication はインストール型ソフトウェア (デスクトップアプリ / モバイルアプリ) を主な想定としており、ダウンロード URL / OS 要件 / アプリストア情報を持ちます。SaaS には合いません。
WebApplication は SoftwareApplication のサブタイプで Web アプリ向けです。Acme Workflow のような「ログイン後に Web で使うアプリ」を厳密にモデリングするならこれも選択肢ですが、コーポレートサイトの サービス紹介ページ で表現するのは「アプリ自体」ではなく「提供サービス」なので、Service の方が文脈に合います。
もし「アプリの機能仕様」を中心に紹介するページ (e.g. App Store 風の機能一覧) なら WebApplication への切替を検討します。

`Service` で必須に近いプロパティ

プロパティ	値域	役割
`name`	Text	サービス名
`description`	Text	簡潔な説明
`provider`	Organization / Person	提供者 (判断 4)
`serviceType`	Text	サービスのカテゴリ
`audience`	Audience	対象 (判断 6)
`areaServed`	AdministrativeArea 等	提供地域 (判断 7)

name / description 以外は任意ですが、検索エンジンに豊かな情報を渡すには provider / audience / areaServed を埋めるのが推奨です。

判断 4: `provider` に `Organization` を入れる

サービスの提供者を provider で宣言します。

Person か Organization か

個人事業 / フリーランス → Person
会社 / 団体 → Organization

Acme Workflow は架空の Acme Inc. が提供する SaaS なので、Organization を選びます。

Google ガイドラインによる根拠

Organization Schema Markup (確認: 2026-05) は組織情報のマークアップを推奨しており、ナレッジパネルや検索結果でのロゴ表示などの基盤になります。Service.provider として参照するだけでなく、サイト全体で Organization を一意に定義しておくと、複数ページから @id で参照できます (後述の @id 戦略)。

`Organization` で埋めるべき主要プロパティ

プロパティ	役割
`name`	会社名
`url`	コーポレートサイトの URL (canonical)
`logo`	ロゴ画像 URL
`sameAs`	関連 URL の配列 (Wikipedia / SNS 等)
`contactPoint`	連絡先情報 (`ContactPoint` 型)

Organization の sameAs

sameAs には Wikipedia ページ / 公式 SNS アカウント / 公式 Crunchbase ページ等の URL を配列で並べます。Google が「これらは同一組織を指す」という認識を持ちやすくなり、ナレッジパネル統合の精度が上がります。

`Organization` のサブタイプ

Organization には Corporation / EducationalOrganization / GovernmentOrganization / LocalBusiness 等のサブタイプがあります。

株式会社なら Corporation を選んでもよい (ただし Organization のままでも問題なし)
実店舗を持つ業態なら LocalBusiness 系を強く推奨 (営業時間 / 住所 / 地図情報を表現できる)
SaaS 提供企業のように実店舗が主目的でない場合は Organization で十分

判断に迷ったら Organization を選ぶのが安全です。Google は親型 Organization でも適切に解釈します。

判断 5: `WebPage.isPartOf` で親 `WebSite` を参照する

isPartOf は「このリソースが属する上位リソース」を示すプロパティです。WebPage から見たとき、それが属する WebSite (サイト全体) を参照します。

なぜ親 `WebSite` を表現するか

サイト全体の名前 / URL を 1 箇所で定義できる
複数ページ間で WebSite 定義を共有でき、整合性を保てる
Google 検索結果の「サイト名」表示の情報源になる (Site names 参照。サイト名に使われる WebSite はホームページへの設置が要件)

なお、旧 Sitelinks search box (SearchAction) は 2024-11 に廃止済みのため、WebSite を定義する目的に検索アクションは含めません。

`WebSite` の最小定義例

{
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "url": "https://example.com/",
  "name": "Acme Inc.",
  "publisher": { "@id": "https://example.com/#organization" }
}

@id を URL ベースで一意化し、publisher に Organization を @id で参照することで、サイト構造を綺麗に表現できます。

判断 6: `mainEntity.audience` に `Audience` を使う

サービスの対象利用者を audience で宣言します。

`Audience` の型階層

Audience は Intangible 配下で、対象利用者全般を表す汎用型です。サブタイプとして以下があります。

Audience subclass の決定木

対象利用者の性質	推奨型
企業 / 業種別 (B2B SaaS / 業務ツール / 法人サービス)	`BusinessAudience`
個人の属性ベース (年齢 / 性別 / ライフスタイル)	`PeopleAudience`
教育系 (学生 / 教師 / 教材対象者)	`EducationalAudience`
医療 (医療従事者 / 患者)	`MedicalAudience`
上記いずれにも当てはまらない / 不明	`Audience` (汎用)

Acme Workflow の場合

Acme Workflow は業務担当者向けの B2B SaaS なので、BusinessAudience が適切です。

{
  "@type": "BusinessAudience",
  "audienceType": "業務担当者",
  "name": "中小企業の業務担当者"
}

audienceType は対象を文字列で表現するプロパティで、Audience (および全サブタイプ) で使えます。

audience を文字列だけで書かない

"audience": "業務担当者" のように単純文字列で書く実装をたまに見かけますが、これは型として不正です。schema.org の audience プロパティの値域は Audience 型なので、必ず { "@type": "...", ... } 形式のオブジェクトで書きます。型階層を活かすメリット (Google が対象を構造化された情報として認識する) も失われます。

判断 7: `mainEntity.areaServed` に `Country` を使う

サービスを提供する地域を areaServed で宣言します。

値域の候補

areaServed の値域は AdministrativeArea / GeoShape / Place / Text です。

候補型	適する用途
`Country`	国全体 (例: 日本)
`State`	都道府県 / 州
`City`	市区町村
`AdministrativeArea`	行政区分の汎用型
`GeoShape`	緯度経度のポリゴン
`Place`	特定の場所 (会場 / 店舗等)
`Text`	構造化されない文字列 (非推奨)

Acme Workflow の場合

Acme Workflow は日本全国でサービス提供しているので、Country を使います。

{
  "@type": "Country",
  "name": "Japan"
}

Country は AdministrativeArea のサブタイプで、国を表す型です。複数国で提供する場合は areaServed を配列にします。

ISO 3166 コードの併記

identifier プロパティで ISO 3166-1 alpha-2 コード (JP 等) を併記すると、検索エンジンが国を一意に識別しやすくなります。

`@id` 戦略 — オブジェクト間参照の設計

複数オブジェクトを含む JSON-LD では、@id の付け方が 保守性を大きく左右 します。

規約

@id の URL は、そのオブジェクトを表す URL ベースに フラグメント (#xxx) を付けて一意化する
フラグメント名は概念名 (#organization, #website, #webpage, #service) を使う
同じ概念は サイト全体で同じ @id を使う

例

`@id`	表すオブジェクト
`https://example.com/#organization`	サイト全体の Organization (Acme Inc.)
`https://example.com/#website`	サイト全体の WebSite
`https://example.com/services/workflow/#webpage`	このサービス紹介ページの WebPage
`https://example.com/services/workflow/#service`	Acme Workflow という Service

なぜこの規約か

URL ベース: 識別子としてグローバルに一意になる (@id は URI なので URL を使うのが慣習)
フラグメント: # 以降はサーバーに送られないので URL として副作用がない
概念名: @id を読むだけで何のオブジェクトかが分かる
サイト全体で統一: 複数ページで Organization を参照しても、@id が一致していれば検索エンジンが「同じ Organization」と認識する

`@id` 衝突の典型パターン

ページごとに違う Organization @id を使う (https://example.com/page-a/#organization と https://example.com/page-b/#organization) → 別組織として認識される
動的に生成する @id (timestamp や UUID 含む) → ページ更新で別オブジェクト扱いになる
@id を URL ではなく単純な文字列で書く ("@id": "organization") → 識別子として弱く、複数サイト間でぶつかる可能性

自サイト適用 decision tree

ここまで Acme Workflow を題材に判断プロセスを示しました。自サイトに応用する場合の汎化された分岐 を以下にまとめます。

ステップ 1: ルート型を決める

ページの性質から WebPage のサブクラスを選びます。

ページの性質	推奨ルート型
サービス / 製品紹介 / 一般	`WebPage` (or `ItemPage`)
会社概要	`AboutPage`
連絡先	`ContactPage`
FAQ	`FAQPage`
チェックアウト	`CheckoutPage`
検索結果	`SearchResultsPage`

ステップ 2: `mainEntity` の型を決める

ページの主題は何かを決め、それを表す型を選びます。

ページ主題	mainEntity 型
無形サービス (SaaS / コンサル / 専門サービス)	`Service`
有形商品 / 単発購入物	`Product`
記事 / ブログ投稿	`Article` (or `BlogPosting` / `NewsArticle`)
組織紹介ページ	`Organization`
イベント告知	`Event`
FAQ ページ全体	`FAQPage` のとき主題は QA リスト
求人募集	`JobPosting`
レシピ	`Recipe`
動画	`VideoObject`
ランディング (主題複合)	最も主たるエンティティ 1 つに絞る

ステップ 3: `provider` / `publisher` / `author` を決める

主題に応じて関係者を表現します。

主題型	関連プロパティ	値域
`Service`	`provider`	`Organization` / `Person`
`Product`	`manufacturer` / `brand`	`Organization` / `Brand`
`Article`	`author` / `publisher`	`Person` / `Organization`
`Event`	`organizer` / `performer`	`Organization` / `Person`
`Recipe`	`author`	`Person` / `Organization`

ステップ 4: 対象 / 地域を決める (必要に応じて)

対象 / 地域の宣言	プロパティ	値域
対象利用者	`audience`	`Audience` 系 (decision 6 の決定木)
提供地域	`areaServed`	`Country` / `State` / `City` / `Place`
言語	`inLanguage`	`Language` / `Text` (IETF BCP 47、例: `ja`)

ステップ 5: `@id` で関係を結ぶ

サイト全体の Organization / WebSite を 1 箇所に定義し、各ページから @id で参照します。

却下した代替案の整理

判断のトレースを残すため、ここまでで「採用しなかった選択肢」を整理します。

場面	採用した型	却下した型	却下理由
ルート型	`WebPage`	`Article`	サービス紹介は記事ではない
ルート型	`WebPage`	`Product`	サービスは無形
ルート型	`WebPage`	`ItemPage`	より汎用な `WebPage` で十分 (将来サイト構成変更時に他ページに転用しやすい)
主題	`Service`	`Product`	継続契約のサービスは Product ではない
主題	`Service`	`SoftwareApplication`	インストール型ソフトウェアではない
主題	`Service`	`WebApplication`	サービス紹介ページはアプリ機能仕様ではない
提供者	`Organization`	`Person`	個人ではなく会社
対象	`BusinessAudience`	`Audience` (汎用)	サブタイプで業種文脈を表現したい
対象	`BusinessAudience`	文字列のみ	値域違反
地域	`Country`	`Place`	国全体なので Place は過剰
地域	`Country`	`Text`	構造化情報が失われる

このあと

ここまでで型選定の判断プロセスを完了しました。次章 04. 実装 + 検証 + 運用では、ここで決めた型を組み合わせて Acme Workflow の 完成 JSON-LD を提示し、Google Rich Results Test での検証手順と継続運用の規範を扱います。

この章の位置づけ
判断 1: ルート型に WebPage を選ぶ
- 何を表現したいか
- 候補
判断 2: mainEntity でページ主題を 1 つだけ宣言する
- mainEntity を使う意味
- mainEntity を複数定義した場合の問題
判断 3: mainEntity の型に Service を選ぶ
- 候補
- Service で必須に近いプロパティ
判断 4: provider に Organization を入れる
判断 5: WebPage.isPartOf で親 WebSite を参照する
- なぜ親 WebSite を表現するか
- WebSite の最小定義例
判断 6: mainEntity.audience に Audience を使う
判断 7: mainEntity.areaServed に Country を使う
- 値域の候補
- Acme Workflow の場合
@id 戦略 — オブジェクト間参照の設計
自サイト適用 decision tree
却下した代替案の整理
このあと

この章の位置づけ​

判断 1: ルート型に WebPage を選ぶ​

何を表現したいか​

候補​

判断 2: mainEntity でページ主題を 1 つだけ宣言する​

mainEntity を使う意味​

mainEntity を複数定義した場合の問題​

判断 3: mainEntity の型に Service を選ぶ​

候補​

Service で必須に近いプロパティ​

判断 4: provider に Organization を入れる​

Person か Organization か​

Google ガイドラインによる根拠​

Organization で埋めるべき主要プロパティ​

Organization のサブタイプ​

判断 5: WebPage.isPartOf で親 WebSite を参照する​

なぜ親 WebSite を表現するか​

WebSite の最小定義例​

判断 6: mainEntity.audience に Audience を使う​

Audience の型階層​

Audience subclass の決定木​

Acme Workflow の場合​

判断 7: mainEntity.areaServed に Country を使う​

値域の候補​

Acme Workflow の場合​

@id 戦略 — オブジェクト間参照の設計​

規約​

例​

なぜこの規約か​

@id 衝突の典型パターン​

自サイト適用 decision tree​

ステップ 1: ルート型を決める​

ステップ 2: mainEntity の型を決める​

ステップ 3: provider / publisher / author を決める​

ステップ 4: 対象 / 地域を決める (必要に応じて)​

ステップ 5: @id で関係を結ぶ​

却下した代替案の整理​

このあと​

この章の位置づけ

判断 1: ルート型に `WebPage` を選ぶ

何を表現したいか

候補

判断 2: `mainEntity` でページ主題を 1 つだけ宣言する

`mainEntity` を使う意味

`mainEntity` を複数定義した場合の問題

判断 3: `mainEntity` の型に `Service` を選ぶ

候補

`Service` で必須に近いプロパティ

判断 4: `provider` に `Organization` を入れる

Person か Organization か

Google ガイドラインによる根拠

`Organization` で埋めるべき主要プロパティ

`Organization` のサブタイプ

判断 5: `WebPage.isPartOf` で親 `WebSite` を参照する

なぜ親 `WebSite` を表現するか

`WebSite` の最小定義例

判断 6: `mainEntity.audience` に `Audience` を使う

`Audience` の型階層

Audience subclass の決定木

Acme Workflow の場合

判断 7: `mainEntity.areaServed` に `Country` を使う

値域の候補

Acme Workflow の場合

`@id` 戦略 — オブジェクト間参照の設計

規約

例

なぜこの規約か

`@id` 衝突の典型パターン

自サイト適用 decision tree

ステップ 1: ルート型を決める

ステップ 2: `mainEntity` の型を決める

ステップ 3: `provider` / `publisher` / `author` を決める

ステップ 4: 対象 / 地域を決める (必要に応じて)

ステップ 5: `@id` で関係を結ぶ

却下した代替案の整理

このあと