構造化データの種類一覧｜LLMO視点での選び方を解説

構造化データについて調べているけれど、「種類が多すぎてどれが自社サイトに必要なのか分からない」「実装してみたものの本当に効果があるのか実感できない」——そんなお悩みをお持ちではないでしょうか。

実は構造化データは、種類を一つずつ実装するだけでは十分な効果につながらないケースが多くあります。ページ単位のスキーマが、Organizationや運営者情報などサイト全体を支える情報とつながっていないと、検索エンジンやAI検索は「誰が」「何について」発信しているサイトなのかを解釈しにくいままになってしまうためです。

この記事では、LLMO対策を専門支援するAIコマース研究所が、実際の診断現場で見えてきた構造化データの整理パターンをもとに、種類の一覧から自社サイトに必要なスキーマの選び方まで解説します。読み終える頃には、自社サイトのどの情報から構造化データを整理していけばよいかが具体的に見えてくるはずです。

構造化データとは？検索エンジン・AIが情報を理解する仕組み

構造化データとは、Webページの内容を検索エンジンやAI検索エンジンが「意味」として理解できるように、HTML内に決められた形式で記述するデータのことです。

人間であれば「これは会社名」「これは価格」と文脈から自然に読み取れますが、検索エンジンのクローラーは本来、文字列を意味づけせずに処理しています。構造化データはこのギャップを埋め、情報の意味を明示的に伝えるための仕組みです。

この考え方の土台にあるのが「セマンティックWeb」という概念です。Webページの内容を単なる記号の羅列としてではなく、コンピュータにとっても意味を持ったデータとして扱えるようにすることを目指す構想で、構造化データはこれを実現するための具体的な技術にあたります。

構造化データとschema.orgの関係

構造化データを記述する際に使う語彙（ボキャブラリー）の標準規格が「schema.org」です。

Google・Microsoft・Yahoo!などの主要な検索エンジンが共同で策定・管理しており、Organization（組織）、Article（記事）、Product（商品）、Event（イベント）、Recipe（レシピ）など、あらゆるコンテンツ種別に対応する数百種類のタイプが定義されています。

どの検索エンジンでも共通で解釈される規格であるため、構造化データを実装する際はこのschema.orgに準拠した記述を行うのが基本です。

JSON-LD・microdata・RDFaという3つの記述形式

構造化データの「書き方」にあたるシンタックス（構文）には、主にJSON-LD・microdata・RDFaの3つがあります。中でもGoogleが推奨しているのがJSON-LDです。

HTMLの本文とは切り離してscriptタグ内に一括で記述できるため、既存のHTML構造を変更せずに導入でき、複数ページへの展開や保守がしやすいというメリットがあります。

これから構造化データを実装する場合は、まずJSON-LD形式を選んでおけば実務上大きな問題は生じません。

構造化データの種類一覧｜代表的なスキーマと使い分け

構造化データの種類は多岐にわたりますが、自社サイトの運用という観点では「コンテンツ系」「事業者・人物系」「サイト構造系」の3つに大きく分けて捉えると、全体像が把握しやすくなります。

すべてのタイプを覚える必要はなく、自社サイトの構成に関係する種類だけを押さえれば十分です。

コンテンツ系（Article／FAQPage／HowTo／Recipe／VideoObject等）

コンテンツ系は、記事やコンテンツそのものの内容を検索エンジンに伝えるための種類です。

ニュースやブログ記事を指定するArticle、よくある質問と回答をまとめるFAQPage、手順を示すHowTo、料理の材料や作り方を示すRecipe、動画情報を伝えるVideoObjectなどが代表的です。

いずれも実装することで、検索結果に通常のタイトル・説明文以上の情報を表示する「リッチリザルト」の対象になりやすくなります。たとえばFAQPageであれば質問と回答がそのまま検索結果に表示されるケースがあり、HowToであれば手順ごとにステップが展開されて表示されることがあります。

事業者・人物系（Organization／LocalBusiness／Person）

事業者・人物系は、「誰が」「どの組織が」その情報を発信しているのかを示す種類です。

会社名・ロゴ・所在地・電話番号・SNSアカウントなど運営組織の基本情報を記述するOrganization、店舗の営業時間や地図情報などを含むLocalBusiness、個人のプロフィール・職業・経歴などを示すPersonがこれにあたります。

Organizationスキーマを整備しておくと、社名で検索した際の情報表示に組織の基本情報が反映されやすくなり、ブランドとしての信頼性の土台になります。この事業者・人物系は、通常はサイト全体で1回だけ記述し、全ページに展開する運用が一般的です。

サイト構造系（BreadcrumbList／WebSite等）

サイト構造系は、サイト全体の構造や、ページがサイト内のどの階層に位置するかを示す種類です。

代表例がBreadcrumbList（パンくずリスト）で、「position」というプロパティで階層を指定することで、検索結果にサイト内の位置関係が表示されるようになります。

ユーザーがサイト構造を直感的に把握しやすくなるだけでなく、検索エンジンにとってもサイト全体のクロール効率を高める効果が期待できます。

構造化データを実装するメリットとLLMO・SEOの影響

構造化データを実装する主なメリットは、検索エンジンがコンテンツの内容を正確に理解しやすくなることと、検索結果でリッチリザルトが表示されやすくなることの2点です。

ただし、構造化データの実装そのものが検索順位を直接押し上げるわけではない点には注意が必要です。

ChatGPT・AI Overviewsなど生成AI検索からの引用獲得

近年注目度が高まっているのが、ChatGPT・Google AI Overviews・Geminiといった生成AI検索における構造化データの役割です。

これらのAI検索は、複数のWebページの情報を統合して回答を生成する仕組みを持っており、その過程で意味的に整理された情報を持つページが参照されやすい傾向があります。

ただし、この分野はアルゴリズムの変更や研究の進展が頻繁であるため、「構造化データを入れれば必ず引用される」といった断定はできず、あくまで「情報を解釈しやすくする土台を整える施策」として捉えるのが実務上は適切です。

リッチリザルト表示によるCTR向上

構造化データを正しくマークアップすると、通常のタイトル・URL・説明文だけの表示とは異なる、情報量の多い「リッチリザルト」として検索結果に表示されやすくなります。

商品情報であれば価格やレビュー評価、イベント情報であれば日時や場所といった詳細情報がひと目で分かる形で表示されるため、ユーザーのクリック意欲を高めやすくなります。

構造化データの有無自体が検索順位の判断基準にはならないとGoogle側から説明されている一方で、リッチリザルトによるクリック率の向上は、結果として間接的な集客改善につながる可能性があります。

【事例】構造化データ同士のつながりを設計する重要性

構造化データは、種類ごとに単体で実装するだけでは、検索エンジンやAI検索にとって十分に意味のある情報にならないケースがあります。私たちAIコマース研究所が見てきたとあるBtoB企業のオウンドメディアの事例では、代表者プロフィールにPerson構造化データが実装されていたものの、そのPersonがどのOrganizationに所属し、どの記事を執筆し、どのServiceに関与しているのかという情報同士のつながりが記述されていませんでした。

これは、社員名簿に名前だけが載っていて、所属部署も担当業務も書かれていない状態に近いといえます。Person単体では「誰か」がいることは伝わっても、「その人が何者で、何をしているのか」という文脈までは検索エンジンやAI検索に伝わりません。

そこで私たちが行ったのが、Person→Organization→Article→Serviceという関係性の整理です。代表者を単独のPersonとして定義するだけでなく、Organizationとの所属関係、各記事のauthorプロパティによるArticleとの紐付け、提供するServiceとの関係を構造化データ上で明示しました。その結果、サイト内に散在していた「人物」「事業主体」「記事」「サービス」がそれぞれ独立した情報としてではなく、一つの専門領域を構成する情報群としてつながる状態になりました。

この整理によって検索順位やAI引用率が直接的に向上すると断定することはできません。しかし、検索エンジンやAI検索に対して「誰が、どの組織で、何について発信し、何を提供しているのか」を解釈しやすい情報構造を用意できるという点で、構造化データを個別のスキーマの寄せ集めとして捉えるのではなく、情報同士の関係性の設計として捉える視点は、実装の質を左右する重要なポイントだと考えています。

構造化データの選び方｜自社サイトにどのスキーマが必要か判断する3つのポイント

構造化データの種類は数多くありますが、自社サイトに必要なものを選ぶ際は「サイトの種類」「ページの役割」「情報同士のつながり」という3つの視点で整理すると判断しやすくなります。

サイトの種類（オウンドメディア／コーポレート／ECサイト）で変わる優先度

自社サイトがどのようなサイトかによって、優先すべき構造化データの種類は変わります。オウンドメディアであればArticleやFAQPage、HowToといったコンテンツ系の実装優先度が高くなります。

コーポレートサイトであればOrganizationやLocalBusinessといった事業者系の情報整備が土台になります。

ECサイトであれば商品情報を示すProductや、レビュー情報を示すReviewといった、購買行動に直結する種類の優先度が高くなる傾向があります。まずは自社サイトの主目的を確認し、そこに紐づく種類から着手するのが遠回りにならない進め方です。

記事単位で対策すべきスキーマとサイト全体で対策すべきスキーマの違い

構造化データには、記事ページごとに個別に実装すべき種類と、サイト全体で一度整備すれば全ページに反映される種類があります。

ArticleやFAQPage、HowToなどは記事の内容ごとに個別の記述が必要になりますが、Organizationやパンくずリストにあたるスキーマは、テーマファイルなどで一度設定すれば全ページに自動的に展開できる場合が多くあります。

この違いを理解せずに、すべての種類を記事ごとに個別対応しようとすると、実装工数が想定以上に膨らんでしまうことがあります。まずはサイト全体で1回整備すれば済む種類から着手し、その後に記事単位のコンテンツ系スキーマへ広げていく順序がおすすめです。

構造化データの実装方法と確認方法

構造化データの実装は、JSON-LD形式でscriptタグ内に記述し、正しく認識されているかをツールで確認するという2ステップで進めます。

JSON-LDでの記述例

たとえばFAQ情報をマークアップする場合、schema.orgの「FAQPage」というタイプを使い、質問にあたる「Question」と回答にあたる「Answer」のプロパティを組み合わせて記述します。パンくずリストであれば「BreadcrumbList」タイプの中で、各階層を「position」というプロパティを使って番号順に指定します。

記事であれば「Article」やその派生タイプの中で、タイトル・公開日・著者・発行元といった情報をプロパティとして記述していきます。いずれもGoogleが提供する構造化データマークアップ支援ツールを使えば、専門知識がなくてもある程度自動的にコードを生成できます。

実装後に確認すべき3つのツール

構造化データは1文字の記述ミスでも正しく認識されないことがあるため、実装後の確認が欠かせません。確認方法としては、埋め込まれている構造化データをすべて検証できる「スキーママークアップ検証ツール」、リッチリザルトの対象となる項目のみを検出する「リッチリザルトテスト」、そして公開後に実際のインデックス状況を確認できる「Googleサーチコンソールの拡張レポート」の3つを使い分けるのが基本です。

前者2つは公開前のチェックに、サーチコンソールは公開後の継続的なモニタリングに向いています。「無効」と判定されているページがないかを定期的に確認する運用を組み込んでおくと安心です。

構造化データ対策を外注する場合のチェックポイント

構造化データの実装は、正しい種類の選定と記述の正確性さえ押さえれば、自社での対応も十分可能です。一方で、サイトの規模が大きく記事数が多い場合や、Person・Organization・Article・Serviceといった情報同士の関係性まで踏み込んで設計したい場合は、専門的な知見を持つ外部への相談が近道になることもあります。

外注を検討する際は、単に「構造化データを実装できるか」だけでなく、「自社サイトのどの情報とどの情報をつなげるべきかを、生成AI検索の文脈理解の観点から設計できるか」という視点で会社を見極めることが重要です。実装の手数だけを請け負う会社と、情報構造そのものを診断・設計できる会社とでは、得られる成果に差が出やすい領域だからです。

私たちAIコマース研究所では、こうした自社サイトの構造化データの実装状況や、情報同士のつながりの整理状況を確認できるLLMO無料診断を、毎月10社限定で提供しています。自社でどこから着手すべきか判断に迷う場合は、まず現状を客観的に把握するところから検討してみてください。

構造化データの種類に関するよくある質問

構造化データの種類はいくつありますか？

schema.orgには数百種類のタイプが定義されていますが、自社サイトで押さえるべきは十数種類程度です。
すべてを網羅する必要はなく、Article・FAQPage・Organizationなど自社サイトの目的に紐づく種類から選んで実装するのが実務上の進め方です。

構造化データは画像にも設定できますか？

ImageObjectというタイプを使うことで、画像に関する情報を構造化データとして記述できます。
ライセンス情報や作成者情報などを含めることで、画像検索での発見可能性を高める効果が期待できます。記事内の主要な画像に付与するのが一般的です。

構造化データの書き方の基本を教えてください。

Googleが推奨するJSON-LD形式で、scriptタグ内にschema.orgのタイプとプロパティを記述します。
HTMLの本文とは切り離して1カ所にまとめて書けるため、既存ページのデザインを崩さずに導入でき、複数ページへの展開・保守もしやすい形式です。

なぜJSON-LDが推奨されるのですか？

HTMLの表示内容と切り離して一元管理できるため、実装・保守のしやすさで優れているためです。
microdataやRDFaのようにHTML要素の中に直接埋め込む形式と異なり、既存のマークアップを変更せずに追加・修正できる点が実務上のメリットです。

構造化データのsameasとは何ですか？

sameAsは、同一の人物・組織を指す外部URL（公式SNS・Wikipedia等）を紐づけるプロパティです。
PersonやOrganizationスキーマに設定することで、検索エンジンやAI検索が「この人物・組織は誰なのか」をより正確に識別しやすくなる傾向があります。

構造化データを設定してもリッチリザルトが表示されないのはなぜですか？

記述エラーやページ内容との不一致、対象外のスキーマである等の理由が考えられます。
リッチリザルトはGoogle側の判断で表示可否が決まるため、正しく実装しても必ず表示されるとは限りません。まずはリッチリザルトテストでエラーの有無を確認することが対処の第一歩です。

構造化データとSEO対策会社に依頼する場合の費用相場はどれくらいですか？

依頼範囲によって幅がありますが、実装の代行のみか、情報構造の設計まで含むかで費用感は大きく変わります。
単発の実装代行は比較的低コストで依頼できる一方、Person・Organization・Articleなどの関係性設計まで含むコンサルティング型の支援は、継続的な費用が発生するのが一般的です。

LLMOとは何ですか？構造化データとどう関係しますか？

LLMOとは、ChatGPTやGoogle AI Overviewsなど生成AI検索から正しく認識・引用されるための対策のことです。
構造化データは、生成AI検索が情報の意味を解釈する際の手がかりの一つとなるため、LLMO対策の土台となる施策の一つに位置づけられます。

構造化データの種類を選ぶ際、最初に何から着手すべきですか？

まずはサイト全体で1回設定すれば済むOrganizationとパンくずリストから着手するのが効率的です。
その後、記事単位で個別に対応が必要なArticleやFAQPageといったコンテンツ系のスキーマへと段階的に広げていく順序がおすすめです。

構造化データの実装状況は自分で診断できますか？

スキーママークアップ検証ツールやリッチリザルトテストを使えば、基本的な実装状況は自分で確認できます。
ただし、Person・Organization・Article・Serviceといった情報同士のつながりまで踏み込んだ診断には専門的な知見が必要になるため、LLMO無料診断のような第三者チェックを活用する方法もあります。

構造化データの種類を理解し、自社に必要なスキーマから実装を始めましょう

構造化データには数多くの種類がありますが、すべてを網羅する必要はなく、自社サイトの目的に紐づくコンテンツ系・事業者系・サイト構造系の中から優先度の高いものを選んで実装していくことが大切です。

あわせて、Person・Organization・Article・Serviceのように情報同士のつながりを意識した設計を行うことで、検索エンジンだけでなく生成AI検索にとっても「誰が、何を発信しているサイトか」を解釈しやすい情報構造に近づけることができます。

まずは自社サイトにある情報を棚卸しし、どの種類から整理すべきかを見極めるところから始めてみてください。