SEO・AIO

構造化データの入れ方

Schema/JSON-LDの役割・書き方・検証方法を、BtoBサイトの実務目線で解説します。

この記事の要点

構造化データは「内容を正しく伝える補助」です。検索順位やリッチリザルトの表示、AIでの引用を保証するものではありません。
実態と異なるSchemaは逆効果です。ページに書かれていない情報をマークアップしてはいけません。
記述はJSON-LD形式が一般的で、HTMLの<head>内に置きます。公開前にGoogleのリッチリザルトテストで検証します。

— 01

構造化データとは何か

構造化データとは、Webページに書かれている情報の「意味」を、検索エンジンやAIが理解しやすい形式で明示する仕組みです。人間は「株式会社○○」という文字列を見れば会社名だと分かりますが、機械にとっては単なる文字の並びです。そこで「これは会社名」「これは所在地」「これは公開日」といったラベルを、決められた語彙（ボキャブラリ）で付けます。この共通の語彙がSchema.org（スキーマ・ドット・オルグ）です。

Schema.orgはGoogle・Microsoft・Yahoo・Yandexが共同で立ち上げた語彙の標準で、Organization（組織）やArticle（記事）といった「型（Type）」と、name（名前）やurlといった「プロパティ（Property）」が定義されています。構造化データは、このSchema.orgの語彙を使ってページの内容を注釈します。

重要なのは、構造化データはあくまで「伝え方」だという点です。ページの内容そのものを良くするものではありません。中身の薄いページに構造化データを足しても、中身が充実するわけではありません。構造化データは、すでにページにある情報を、機械が誤解しないように整理して渡す役割を担います。

構造化データで起こり得ること・起こらないこと

起こり得ること	起こらないこと（保証されないこと）
検索エンジンがページの内容を正確に解釈する補助になる	検索順位が上がる
リッチリザルト表示の条件を満たす場合がある	リッチリザルトが必ず表示される
AIがページの事実を解釈する手がかりになり得る	AIに必ず引用される

構造化データを入れたのに順位が変わらない、リッチリザルトが出ない、という相談は珍しくありません。これは構造化データの役割を正しく理解すれば想定の範囲です。構造化データは「正しく伝える」ための投資であり、「成果を保証する」ものではありません。

— 02

種類別の役割と使いどころ

Schema.orgには数百の型がありますが、BtoBサイトで実務上把握しておきたいのは限られています。代表的な種類と役割を整理します。

Organization（組織）

会社名・ロゴ・所在地・連絡先・公式SNSなどを伝えます。サイト全体を代表する会社情報の核になる型です。トップページや会社概要ページに置く形が一般的です。name・url・logoに加え、sameAs（公式SNSや外部プロフィールのURL）を添えると、会社という実体（エンティティ）の認識を助ける手がかりになります。

WebSite（サイト）

サイト全体の基本情報を伝えます。サイト名やURLを示します。かつてはSearchActionでGoogle検索結果にサイトリンク検索ボックスを出す用途がありましたが、Googleではこの機能が廃止されており、現在この用途では使えません。

BreadcrumbList（パンくずリスト）

ページがサイト内のどの階層にあるかを伝えます。「ホーム > サービス > SIGNAL」のような階層を機械可読にします。検索結果のURL表示がパンくず形式になる場合があり、サイト構造を伝えるうえで効果が分かりやすい型です。実装の手間が小さく、効果も把握しやすいため、優先度が高い種類です。

Article / BlogPosting（記事）

ブログやコラム記事の見出し・著者・公開日・更新日などを伝えます。ニュースに近い記事にはNewsArticle、一般的なブログ記事にはBlogPostingを使うのを目安とします。著者（author）や発行元（publisher）を示すことは、誰が書いた情報かという信頼性の手がかりになります。

FAQPage（よくある質問）

ページ内のよくある質問と回答を構造化します。ここで重要な注意点があります。FAQPageは必須ではありません。また、入れたからといってリッチ表示やAIでの引用が保証されるわけではありません。さらに、GoogleはFAQリッチリザルトのサポートを終了しており、FAQPageを入れてもGoogle検索でFAQがリッチ表示されることはありません。よくある質問はまず本文として分かりやすく書くことが先で、構造化データは補助として位置づけます。

Product / Service（製品・サービス）

Productは物理的な製品やパッケージ商品、Serviceは提供するサービスを伝えます。BtoBでは、明確に定義された製品やプランがある場合にProduct、コンサルティングや受託のような役務にServiceを検討します。価格やレビューといったプロパティは、実際にページ上に表示している情報だけをマークアップします。表示していない価格やレビューをマークアップするのは規約違反であり逆効果です。

LocalBusiness（実店舗・拠点）

実店舗や来訪を受ける拠点がある事業で使います。営業時間・所在地・電話番号などを伝えます。BtoBでも、オフィスへの来訪や地域での認知が重要な場合に検討します。一方、来訪のないオンライン中心の事業ではOrganizationで足りることが多く、無理にLocalBusinessを付ける必要はありません。

型の選び方の原則

型は「ページの実態に合うもの」を選びます。記事ページにProductを付ける、サービス紹介ページにArticleを付けるといった、実態と型のズレは混乱の元です。1ページ1つの主役の型を基本とし、そこにパンくず（BreadcrumbList）や組織情報（Organization）を補助的に組み合わせる、という整理が分かりやすい指針です。

— 03

JSON-LDの書き方の基本

構造化データの記述方式にはJSON-LD・Microdata・RDFaがありますが、現在はJSON-LDでの記述が一般的で、Googleも推奨しています。JSON-LDは本文のHTMLと分離して<script>タグにまとめて書けるため、保守がしやすい点が利点です。

基本の構文

JSON-LDは、<head>内（<body>内でも動作しますが<head>が一般的）に次の形で置きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png"
}
</script>

@contextは語彙の出どころで、https://schema.org を指定します。
@typeはこのデータが何を表すかの型です。
それ以降は、その型に定義されたプロパティと値の組です。

値は必ず、ページに実際に表示されている内容と一致させます。これが構造化データの大前提です。

Organizationの例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://x.com/example",
    "https://www.linkedin.com/company/example"
  ]
}
</script>

BreadcrumbListの例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "サービス",
      "item": "https://example.com/services/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "SIGNAL",
      "item": "https://example.com/services/signal"
    }
  ]
}
</script>

positionは階層の順番、nameは表示名、itemはそのページのURLです。実際のパンくず表示と順序・名称を揃えます。

BlogPostingの例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "構造化データ実装ガイド",
  "datePublished": "2026-06-26",
  "dateModified": "2026-06-26",
  "author": {
    "@type": "Organization",
    "name": "株式会社サンプル"
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}
</script>

headlineはページのタイトルと整合させ、datePublished・dateModifiedは実際の公開日・更新日を入れます。日付はISO 8601形式（2026-06-26など）が無難です。

複数の型を1ページに置くとき

1ページに複数の構造化データを置くのは問題ありません。たとえばブログ記事ページなら、BlogPosting・BreadcrumbList・（必要なら）FAQPageを別々の<script>で並べる、あるいは@graphを使って1つのスクリプトにまとめる方法があります。いずれの方法でも、各データの内容がページの実態と一致していることが前提です。

— 04

BtoBで優先すべきもの

すべての型を入れる必要はありません。BtoBサイトでは、効果が分かりやすく実態とのズレが起きにくいものから優先します。優先度の目安を示します。

優先度	種類	主な対象ページ	理由
高	Organization	トップ・会社概要	会社という実体を機械に正しく伝える核
高	BreadcrumbList	下層の全ページ	構造を伝えやすく実装の手間が小さい
高	WebSite	トップ	サイト全体の基本情報
中	Article / BlogPosting	ブログ・コラム	著者・公開日で情報の出どころを示す
中	Service / Product	サービス・製品ページ	提供内容を明確に伝える（実態と一致が条件）
状況次第	LocalBusiness	実拠点がある場合	来訪・地域認知が重要なときのみ
補助	FAQPage	FAQのある記事	必須でなく保証もなし。本文整備が先

まずOrganization・WebSite・BreadcrumbListを正しく入れ、記事にはArticle系を付ける——この基本セットが、多くのBtoBサイトでの出発点になります。Service/Productは、ページに表示している情報の範囲で慎重にマークアップします。FAQPageは「入れれば得」というものではなく、本文が整っていることが前提の補助だと捉えてください。

— 05

よくある実装ミスと検証方法

構造化データの相談で頻出する失敗パターンを挙げます。多くは「実態とのズレ」と「検証の省略」に起因します。

よくある実装ミス

ページにない情報をマークアップする：本文に表示していない価格・評価・レビューを構造化データだけに書く。これは規約違反で、最も避けるべき失敗です。
必須プロパティの欠落：型ごとに推奨・必須とされるプロパティが抜けていて、対象として認識されない。
構文エラー：カンマの過不足、引用符の閉じ忘れ、波括弧の対応ミスなどでJSONとして壊れている。
型と実態のズレ：記事ページにProduct、サービスページにArticleなど、ページの種類に合わない型を付ける。
URLや日付の不整合：itemのURLが実在しない、datePublishedが実際の公開日と違う。
noindexページへのマークアップ：そもそもインデックスされないページに構造化データを入れても表示対象にならない。
画像URLの絶対パス漏れ：ロゴや画像を相対パスで書き、検索エンジンが取得できない。

検証方法

公開前と公開後に、必ず次のツールで検証します。

リッチリザルトテスト（Google）：URLまたはコードを入力すると、Googleがリッチリザルトの対象として認識できる構造化データを検出し、エラーや警告を表示します。リッチリザルトに関わる型の確認に使います。
スキーマ検証ツール（Schema Markup Validator）：Schema.org準拠の観点で構文や型の妥当性を確認します。リッチリザルト対象外の型も検証できます。
Search Consoleの「拡張」レポート：公開後、Googleが実際に検出した構造化データのエラー・警告を継続的に確認できます。Breadcrumbsなど、検出された種類ごとにステータスが分かります。

検証は一度きりではありません。サイト改修やテンプレート変更で構造化データが壊れることがあるため、公開後もSearch Consoleで定期的に確認します。「入れて終わり」にしないことが、構造化データを健全に保つコツです。

— 06

AIに伝えるうえでの構造化

AI検索（AI Overviews・ChatGPT・Perplexityなど）の文脈で「構造化データを入れればAIに載るのか」という質問が増えています。ここは誤解が多い領域なので、丁寧に整理します。

まず前提として、構造化データを入れればAIに引用される、という保証はありません。AIが何を引用するかは各サービスのアルゴリズム次第で、構造化データの有無だけで決まるものではありません。

そのうえで、構造化データはAIに対しても「事実を誤解なく伝える」補助になり得ます。会社名・サービス内容・所在地・連絡先・公開日といった事実が、テキストとして機械可読に整理されていれば、AIがページの内容を解釈する手がかりになります。逆に、重要な情報が画像の中の文字やPDFだけにある状態では、構造化データ以前に内容が読まれにくくなります。

AIに事実を伝えるうえで効くのは、構造化データという「形式」だけでなく、本文そのものの整理です。次のような書き方が、機械にも人にも伝わりやすくなります。

結論を最初に書く（answer-first）
1つの段落で1つの論点を扱う
数値・条件・出典を具体的に添える
質問形の見出しに対して、直後で簡潔に答える

構造化データは、こうして整理された事実に正しいラベルを付ける役割です。本文の整理（中身）と構造化データ（伝え方）は両輪であり、構造化データだけを足してもAIに伝わる量は大きく変わりません。AI向けの本文の書き方は関連記事「AIに引用されないサイトの共通点」、AI向けの要点ファイルの位置づけは関連記事「llms.txtとは・書き方」も参照してください。

— 07

直し方の優先順位

構造化データを一度にすべて整えようとすると工数が膨らみます。インパクトと手間で段階を分けると効率的です。

段階	主な作業	ねらい
第1段階（土台・即）	Organization・WebSite・BreadcrumbListを正しく入れる／壊れている構造化データを直す	会社と構造を正しく伝える
第2段階（記事・サービス）	Article/BlogPostingを記事に付与／Service・Productを実態の範囲でマークアップ	各ページの内容を正確に伝える
第3段階（検証と運用）	リッチリザルトテストとSearch Consoleで継続検証／本文の整理と並行で改善	壊れを防ぎ健全に保つ

順番が重要です。土台（Organization・BreadcrumbList）が整っていない状態で、FAQPageやProductのような個別の型から手を付けても、効果は把握しにくくなります。また、どの型も「実態と一致しているか」「壊れていないか」をリッチリザルトテストとSearch Consoleで確認してから次に進みます。

構造化データの整備は、本文の整理（中身を分かりやすくする）とセットで進めると効果が出やすくなります。構造化データは伝え方の改善であり、伝える中身の改善と両輪で捉えてください。

まとめ

構造化データ（Schema/JSON-LD）は、ページの内容を検索エンジンとAIに正確に伝えるための補助です。順位・リッチリザルト・AI引用を保証するものではありません。
実態と異なるSchemaは逆効果です。ページに表示している情報だけをマークアップします。
記述はJSON-LD形式が一般的で、<head>内に置きます。
BtoBではOrganization・WebSite・BreadcrumbListが優先度の高い基本セットです。記事にはArticle/BlogPostingを付けます。FAQPageは必須でも保証でもなく、本文整備が先です。
公開前にリッチリザルトテストとスキーマ検証ツールで確認し、公開後はSearch Consoleで継続検証します。
AIに伝えるうえでは、構造化データ（伝え方）と本文の整理（中身）の両輪が重要です。
整備は土台→記事/サービス→検証運用の順で、本文の整理とセットで進めます。

よくあるご質問

構造化データを入れれば検索順位は上がりますか？

上がるとは限りません。構造化データはページの内容を正確に伝える補助であり、検索順位を直接上げるものではありません。順位は内容の質や検索意図との一致など、別の要因で決まります。

構造化データを入れればリッチリザルトは必ず表示されますか？

必ずではありません。リッチリザルトの表示は検索エンジン側の判断であり、構造化データが正しくても表示されないことがあります。リッチリザルトテストで対象として認識されることと、実際に表示されることは別です。

JSON-LDとMicrodataはどちらで書くべきですか？

現在はJSON-LDが一般的で、Googleも推奨しています。本文のHTMLと分離して<head>内にまとめて書けるため、保守がしやすい点が利点です。

FAQPageの構造化データは入れるべきですか？

必須ではありません。入れてもリッチ表示やAIでの引用が保証されるわけではありません。よくある質問はまず本文として分かりやすく書き、構造化データは補助として位置づけてください。

ページに表示していない価格やレビューをマークアップしてもよいですか？

いけません。ページに表示していない情報を構造化データだけに書くのは規約違反で、評価上も逆効果です。実際に表示している情報だけをマークアップします。

構造化データが正しいかはどう確認すればよいですか？

公開前にGoogleのリッチリザルトテストとスキーマ検証ツール（Schema Markup Validator）で確認します。公開後はSearch Consoleの「拡張」レポートで、検出されたエラー・警告を継続的に確認します。

BtoBサイトでまず入れるべき構造化データは何ですか？

Organization（会社情報）・WebSite（サイト情報）・BreadcrumbList（パンくず）が優先度の高い基本セットです。記事ページにはArticle/BlogPostingを付けます。Service/Productは実態と一致する範囲で慎重にマークアップします。

構造化データを入れればAIに引用されますか？

保証はありません。AIが何を引用するかは各サービスの判断によります。ただし、事実が機械可読に整理されていればAIがページを解釈する手がかりにはなり得ます。構造化データ（伝え方）と本文の整理（中身）を両輪で進めることが重要です。

この記事の著者

飯田友広

代表取締役

Netsujo株式会社代表取締役。京都発のWeb3・AI実装スタートアップを2023年6月に創業。京都府ワーキンググループ「Chain UP KYOTO」参画(2026-03-10)、京都美術工芸大学での講義・龍谷大学でのセミナー実績、ITコミュニティ「みやこでIT」(connpassメンバー592名・イベント158回以上・2019年2月から運営)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。ソーシャル企業認証「S認証」取得企業(2026-02)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。

プロフィールを見る

この記事が向いている方

自社サイトに構造化データを入れたいが、何から手を付ければよいか分からない方
OrganizationやBreadcrumbListなど、BtoBで優先すべき種類を整理したい方
入れたつもりの構造化データが正しいか不安なWeb担当者
AIに事実を正しく伝えるための土台づくりを検討している方

— 壁打ち相談

読者のよくある相談

記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。

Q. どの構造化データから入れればよいか分かりません。

Organization・WebSite・BreadcrumbListの基本セットから、現状に合わせて優先順位を整理します。

Q. 入れた構造化データが正しいか不安です。

リッチリザルトテストとSearch Consoleで、実態とのズレや壊れがないかを一緒に確認します。

Q. AIに事実を正しく伝えたいです。

構造化データ（伝え方）と本文の整理（中身）の両輪で、AIに解釈されやすい土台づくりを壁打ちできます。

上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。

壁打ち相談を送る

検索・AI時代のWeb営業基盤をつくる

公開情報からの無料Web診断で構造化データの有無や実態とのズレを確認し、精密分析ではページの実態に合ったJSON-LDをコードとして納品します。検索順位やAI掲載を保証するものではありません。

SIGNALのプランを見る