schema.orgの種類(タイプ)とは、検索エンジンや生成AIにページの意味を正しく伝えるための「型」のことです。全体では数百種類ありますが、実務で必要になるのは記事・商品・企業・店舗など代表的な約20タイプに絞られます。本記事では、代表20タイプの一覧早見表、ページ目的から逆引きする選び方、JSON-LDでの実装と検証手順、そしてAI検索(LLMO/GEO)時代における意義までを一気通貫で整理します。まずは自分のページに該当するタイプを特定し、迷わず実装へ進める状態を目指しましょう。
- 代表20タイプの用途と向くページが一覧でわかる
- ページ目的から逆引きで最適なタイプを選べる
- JSON-LDでの実装・検証とAI検索での意義がわかる
記事はArticle、商品はProduct、企業はOrganization、店舗はLocalBusinessのように、ページ種別から対応タイプを即断できるよう早見表を用意しました。Googleが推奨するJSON-LDでの書き方、リッチリザルトテストでの検証、FAQやHowToの最新事情まで押さえれば、非エンジニアでも実装に着手できます。
そもそもschema.orgの「種類(タイプ)」とは何ですか?

schema.orgの種類(タイプ)とは、ページが「記事なのか」「商品なのか」「企業なのか」といった内容の意味を検索エンジンに伝えるための分類の型です。数百種類ありますが、各タイプは「プロパティ(属性)」を持ち、階層構造でつながっています。まずはこの全体像を押さえると、後の選び方が一気に理解しやすくなります。
TechSuite株式会社の「AI検索パートナーズ」は、こうしたタイプとプロパティの意味的文脈やエンティティ認識の仕組みを技術的に捉え、生成AIが引用・推薦しやすい構造化データの設計まで踏み込んで支援しています。
schema.orgとは何ですか?
schema.orgは、Web上の情報を共通の語彙(ボキャブラリ)で意味づけするための規格です。schema.orgは2011年にGoogle・Microsoft(Bing)・Yahoo!が共同で立ち上げ、後にYandexも参加した主要検索エンジン共通の語彙です(出典)。読み方は「スキーマ・オルグ」で、構造化データを記述する際の語彙の土台として広く使われています。
タイプとプロパティの関係は?
タイプは情報の「種類」を、プロパティはそのタイプが持つ「属性」を表します。schema.orgには数百種類のタイプと数千のプロパティが定義されています(出典)。たとえばPersonというタイプにはname・jobTitle・worksForなどのプロパティがあり、これらを組み合わせて意味を精緻に伝えます。下表で両者の関係を整理します。
| 用語 | 役割 | 例 |
|---|---|---|
| タイプ(型) | 情報の種類を表す | Article/Product/Person |
| プロパティ(属性) | タイプが持つ詳細情報 | name/author/price |
| ボキャブラリ | 語彙の集合体 | schema.org |
数百種類のタイプを全部使う必要はありますか?
結論として、すべて覚える必要も使う必要もありません。実務で使うタイプは代表的な約20種類に絞れます。自分のサイトに存在するページ種別に該当するものだけを選べば十分で、まずは記事・商品・企業・店舗など主要なタイプから着手するのが現実的です。次章で代表タイプを一覧化します。
まず押さえるべき基本ポイントは次のとおりです。
- タイプ=情報の種類、プロパティ=その属性
- 数百種類あるが使うのはごく一部でよい
- 自サイトのページ種別に合うものだけ選ぶ

数百種類と聞くと身構えますが、実際に使うのは一部だけ。まずは型と属性の関係だけ掴んでおけば大丈夫ですよ。
代表20タイプの一覧早見表はどうなっていますか?


結論として、実務で使う代表タイプは以下の約20種類です。用途・向くページ・主要プロパティ・Googleのリッチリザルト対応可否を一覧にまとめました。自分のページに近い行を探せば、使うべきタイプの当たりがつきます。
TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みを「バクヤスAI記事代行」で培い、その制作エンジンとナレッジをLLMO対策に転用して、タイプ選定からコンテンツ設計までを高速に進められる体制を整えています。
コンテンツ系とQ&A系のタイプは?
記事や質問を扱うページでは、Article系やFAQ系が中心になります。一般記事はArticle、報道記事はNewsArticle、ブログ投稿はBlogPostingを使い分けます。FAQPageやHowToは後述するように対応状況が変化しているため、最新事情を踏まえた判断が必要です。まずは記事系のタイプから確認しましょう。
EC・組織・店舗系のタイプは?
商品や企業情報を扱うページでは、Product・Organization・LocalBusinessが主役です。EC商品はProduct、企業はOrganization、実店舗や地域ビジネスはLocalBusinessが基本です。ReviewやAggregateRatingはProductと組み合わせて星評価を表現でき、信頼性の高い表示につながります。次の早見表で全体を俯瞰してください。
| タイプ | 用途 | 向くページ | 主要プロパティ | リッチリザルト対応 |
|---|---|---|---|---|
| Article | 一般記事 | 記事全般 | headline/author | △ |
| NewsArticle | ニュース | 報道記事 | author/datePublished | ○ |
| BlogPosting | ブログ投稿 | ブログ | headline/author | △ |
| FAQPage | よくある質問 | Q&A集約 | Question/acceptedAnswer | △(限定) |
| QAPage | 質問と回答 | 掲示板型Q&A | Question/suggestedAnswer | ○ |
| HowTo | 手順解説 | やり方ページ | step/tool | ✕(終了) |
| Product | 商品 | EC商品 | name/offers/brand | ○ |
| Review | レビュー | 評価記事 | reviewRating/author | ○ |
| AggregateRating | 評価集計 | 星評価表示 | ratingValue/reviewCount | ○ |
| Organization | 組織 | 企業情報 | name/logo/url | ○ |
| Person | 人物 | 著者・人物 | name/jobTitle/worksFor | ○ |
| LocalBusiness | 地域ビジネス | 実店舗 | address/openingHours | ○ |
| BreadcrumbList | パンくず | サイト階層 | itemListElement | ○ |
| WebSite | サイト検索 | サイト全体 | potentialAction | ○ |
| VideoObject | 動画 | 動画ページ | thumbnailUrl/uploadDate | ○ |
| ImageObject | 画像情報 | 画像ページ | contentUrl/license | △ |
| Event | イベント | 開催情報 | startDate/location | ○ |
| Recipe | レシピ | 料理ページ | ingredients/cookTime | ○ |
| SoftwareApplication | アプリ | ソフト紹介 | operatingSystem/offers | ○ |
| ItemList | リスト | カルーセル | itemListElement | ○ |
メディア系とその他のタイプは?
動画・画像・書籍・映画などにも専用タイプがあります。動画はVideoObject、画像はImageObject、書籍はBook、映画はMovieが該当します。データ集を公開するならDataset、複数項目を並べるならItemListやCarouselが使えます。対応可否はGoogle検索セントラルのドキュメントで最新情報を確認するのが安全です。



早見表で近い行を見つけたら、あとは主要プロパティを埋めるだけ。まずは自サイトに存在するページ種別に印をつけてみましょうね。
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援!
自分のページにはどのタイプを使えばよいですか?


結論として、ページの目的(記事・商品・企業・店舗・イベント等)から逆引きで選ぶのが最短です。1ページ1目的を基準に、該当するタイプをまず1つ決め、必要に応じてサブタイプや関連タイプを組み合わせます。ここでは選び方の考え方を体系化します。
TechSuite株式会社の「AI検索パートナーズ」は、サイト・コンテンツ・検索導線の構造を捉えてボトルネックを特定し、業種や商材に合わせたタイプ選定と実装方針を顧客ごとに個別設計して実行まで伴走します。
ページ種別からどう逆引きしますか?
まずは「このページは何のページか」を一言で言い切ることから始めます。記事はArticle、商品はProduct、企業はOrganization、店舗はLocalBusinessと、目的に対応するタイプを起点に選びます。イベント告知ならEvent、料理紹介ならRecipeというように、ページの主目的をそのまま型に置き換えるのがコツです。下表を逆引きガイドとして使ってください。
| ページの目的 | 選ぶタイプ | 補足で組み合わせるタイプ |
|---|---|---|
| 記事・コラム | Article/BlogPosting | Person(著者) |
| 商品販売 | Product | Review/AggregateRating |
| 企業情報 | Organization | BreadcrumbList |
| 実店舗紹介 | LocalBusiness | AggregateRating |
| イベント告知 | Event | Organization(主催) |
リッチリザルト対応のタイプを優先すべき?
効果を実感しやすいのは、Googleがリッチリザルトに対応するタイプです。まずはProductやEvent、Recipeなど検索結果の見た目が変わるタイプから優先すると費用対効果が高くなります。一方、Organizationのようにリッチリザルトが出なくても、AIや検索エンジンの理解を助ける「理解補助」の意味で有効なタイプもあります。両者を区別して優先度をつけましょう。
サブタイプや@graphはどう使いますか?
より具体的な情報を持つ場合は、サブタイプを使うと精度が上がります。Organizationなど多くのタイプには詳細なサブタイプがあり、可能なら具体的なサブタイプでマークアップするのが望ましいとされています(出典)。1ページに複数タイプを持たせたい場合は、@graphで記事と著者と組織などを関連づけて記述するのが実務的です。
タイプ選びで迷ったら、次の順で判断すると整理しやすくなります。
- ページの主目的を一言で言い切る
- 対応する代表タイプを1つ決める
- 必要ならサブタイプや@graphで補強する



「このページは何のページか」を言い切れれば、選ぶタイプはほぼ決まります。逆引きで考えると迷いにくいですね。
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援!
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
どの形式で書いて実装・検証すればよいですか?


結論として、記述形式はJSON-LDが推奨で、実装後は必ず検証ツールで確認します。非エンジニアなら自動生成ツールやCMSのプラグインを使い、リッチリザルトテストで表示可否をチェックする流れが現実的です。形式の違いと実装手順を整理します。
TechSuite株式会社の「AI検索パートナーズ」は、技術実装を担う人材とコンテンツ制作人材が一つのチームで連携し、戦略設計から実装・効果測定・改善までを一気通貫で伴走できる体制を整えています。
なぜJSON-LDが推奨されるのですか?
JSON-LDはHTML本文と分離して記述でき、管理しやすいためGoogleが推奨しています。Googleがサポートする形式はJSON-LD・Microdata・RDFaの3種類で、そのうちJSON-LDが推奨されています(出典)。scriptタグ内にまとめて書けるため、既存のHTMLを崩さず追加・修正できる点が実務上の大きな利点です。
| 形式 | 特徴 | 使いどころ |
|---|---|---|
| JSON-LD | HTMLと分離・管理容易 | 基本はこれを推奨 |
| Microdata | HTMLタグに直接記述 | 既存実装の保守 |
| RDFa | 属性で意味づけ | 特定要件のみ |
非エンジニアはどう実装しますか?
コードに不慣れな場合は、ツールとCMS機能を活用するのが近道です。JSON-LDの自動生成ツールや、WordPressなどCMSのプラグイン・テーマ機能を使えば手書きせずに実装できます(出典)。生成したコードは内容と一致しているかを確認し、テンプレート単位で反映すると運用がぶれにくくなります。手動記述の場合も基本構造は同じです。
実装後はどう検証しますか?
実装したら、公開前後で必ず検証します。Googleのリッチリザルトテストで対象タイプの表示可否を確認し、schema.orgのマークアップ検証ツールで文法エラーを点検します。公開後はSearch Consoleの拡張レポートでエラーや警告を継続的にモニタリングすると、仕様変更にも早く気づけます。なお、Googleの動作定義はschema.org公式ではなくGoogle検索セントラルのドキュメントに従う点に注意してください(出典)。
実装から検証までのチェックリストです。
- JSON-LDで記述する
- リッチリザルトテストで表示可否を確認
- Search Consoleで継続モニタリング



迷ったらJSON-LD、そして必ず検証ツールでチェック。この2点を守るだけで実装の失敗はぐっと減りますよ。
AI検索時代(LLMO/GEO)で構造化データはどう効きますか?


結論として、構造化データはAIにコンテンツの意味を正しく理解させ、引用や推薦につながる土台になります。直接のランキング要因ではありませんが、エンティティやナレッジグラフとの結びつきを強め、AI検索での露出に間接的に寄与し得ます。最新の使い分けとあわせて解説します。
TechSuite株式会社の「AI検索パートナーズ」は、自社サイトでAI Share of Voiceが高水準にあり、支援事例でAI Overviewの引用率を改善した実績を踏まえ、AI検索経由での成果につながる構造化とコンテンツ設計を提供しています。
エンティティやナレッジグラフとどう関係しますか?
構造化データは、ページ内の人・組織・商品などを「エンティティ」として明確化します。OrganizationやPersonでエンティティ情報を明示すると、検索エンジンやAIが企業や著者を正確に認識しやすくなります。この積み重ねがナレッジグラフとの結びつきを強め、AIが情報源として信頼しやすい状態を作ります。LLMOとは何かを押さえると、この意義がより理解しやすくなります。
生成AIや音声検索にどう役立ちますか?
構造化データはAIの理解を助け、生成AIや音声検索での引用にも貢献し得ます。構造化データはAIの理解を助け、音声検索やLLMOにも貢献し得るとされています(出典)。実際の対策では、LLMO対策の進め方やAI検索対策とあわせて設計すると効果が高まります。GEO(生成エンジン最適化)の視点も参考になります。
FAQやHowToは今も実装する意味がありますか?
リッチリザルト目的なら効果は限定的ですが、理解補助としては依然有効です。2023年8月にGoogleはFAQリッチリザルトを信頼できる政府・医療機関サイトに限定し、HowToリッチリザルトのサポートを終了しました(出典)。表示装飾は期待しにくくなったものの、AIが問いと答えを抽出しやすくする意味では記述する価値が残ります。
AI検索時代に押さえたい注意点です。
- 直接の順位要因ではなくリッチリザルトも保証されない
- ページ内容と構造化データを必ず一致させる
- 過剰マークアップを避け定期的にメンテナンスする



装飾効果だけでなく、AIに正しく理解させる土台として構造化データを捉え直すと、これからの価値が見えてきます。
よくある質問
- schema.orgのタイプは全部覚える必要がありますか?
覚える必要はありません。実務で使うのは代表的な約20タイプに絞られ、自サイトに存在するページ種別に該当するものだけを選べば十分です。まずは記事・商品・企業・店舗など主要タイプから始めるとよいでしょう。
- 複数のタイプを1ページに使ってもよいですか?
問題ありません。記事と著者と組織のように、複数タイプを@graphで関連づけて記述するのが実務的です。ページ内容と一致していれば、複数タイプの併用はむしろ理解を助けます。
- FAQやHowToは今から実装しても意味がありますか?
リッチリザルト目的では効果が限定的です。2023年8月にFAQは限定表示となりHowToは終了しましたが、AIが問いと答えを抽出しやすくする理解補助としては価値が残ります。目的を分けて判断しましょう。
まとめ
schema.orgの種類(タイプ)は数百ありますが、実務で必要なのは記事・商品・企業・店舗などの代表約20タイプに絞られます。ページの目的を一言で言い切り、逆引きで対応タイプを決めるのが最短の選び方です。
記述形式はJSON-LDが推奨で、実装後はリッチリザルトテストやSearch Consoleで必ず検証します。FAQやHowToの対応状況は変化しているため、最新のGoogle検索セントラルの情報を確認しながら使い分けましょう。
構造化データは直接の順位要因ではないものの、AIにコンテンツを正しく理解させ、AI検索での引用につながる土台になります。過剰マークアップを避け、内容と一致させながら継続的に整備していくことが成果への近道です。
参考にした情報源



