構造化データ（JSON-LD）の基本｜必須スキーマ6種と実装の全体像
「構造化データは入れたほうがいいと聞いたけれど、何をどれだけ入れればいいか分からない」——ホームページ運用のご相談で、最近こうしたお問い合わせが増えてきました。スキーマの種類は数百あり、Googleの公式ドキュメントを読んでも、全体像がつかみにくいのが実情です。
この記事では、中小企業のコーポレートサイトやサービスサイトで最低限押さえておきたい構造化データの基本を、必須スキーマ6種と実装の全体像という切り口で整理します。ENVY DESIGNは創業14年・法人11期目、500件以上の制作実績を持つ東京都港区のWeb制作会社です。自社サイトでAI検索流入を12ヶ月で約3倍に伸ばした経験や、実装で得た経験をもとに、現場で本当に必要な範囲に絞って解説します。
構造化データとは何か——「コンピュータに伝える」もうひとつのHTML
構造化データとは、ページの内容をコンピュータが機械的に理解できる形式で記述したメタ情報のことです。人間はページのタイトルを見て「ああ、この会社は税理士なんだな」とすぐ分かりますが、検索エンジンやAIはHTMLのテキストを読み解くだけでは、その内容の意味までは確実に把握できません。
そこで役に立つのが、schema.orgという国際的に標準化された語彙を使って「これは会社名」「これは営業時間」「これはFAQの質問」と明示的にラベル付けする仕組みです。これが構造化データです。
構造化データの記述形式には主に3種類あります。
- JSON-LD（JavaScript Object Notation for Linked Data）：scriptタグ内にJSON形式で記述
- Microdata：HTMLの属性として記述
- RDFa：HTML属性として記述する別方式
Googleが公式に推奨しているのはJSON-LDです。本文のHTMLと分離して記述できるため、デザイン崩れの心配がなく、CMSでもテンプレート側で一括管理しやすいのが利点です。新規実装・既存改修のいずれも、特段の理由がなければJSON-LDを選んでおくのが無難です。
なぜ構造化データが必要か——3つの活かし方
構造化データの効果は次の3つの活かし方に分けて考えると整理しやすくなります。
活かし方1：Google検索結果でのリッチリザルト表示
質問と回答がアコーディオンで展開される「よくある質問」枠、評価の星付き商品、レシピの調理時間表示など、通常の青いリンクより目立つ表示形式をリッチリザルトと呼びます。構造化データはこのリッチリザルト表示の前提条件です。
ただし2023年以降、FAQリッチリザルトは権威性の高いサイトに表示が絞られるなど、Googleはリッチリザルト表示を制限する方向にシフトしています。「構造化データ＝リッチリザルト狙い」という古い発想だけでは、投資対効果が合わないケースが増えています。
活かし方2：知識パネル・ナレッジグラフへの採用
Organization・LocalBusinessスキーマをしっかり整備すると、社名で検索した際の右側の知識パネルに情報が反映されやすくなります。知識パネルに会社名・ロゴ・所在地・電話番号が整って表示されると、ブランドへの信頼感に直結します。
活かし方3：AI検索（ChatGPT・Perplexity・Gemini等）への引用
ここが2026年時点で最も成長している領域です。AI検索は複数のWebページを読み込んで回答を生成する際、構造化データが整っているページを優先的に参照する傾向があります。当社ではAI検索からの流入を12ヶ月で約3倍に伸ばしましたが、その土台になったのが構造化データの網羅的な実装でした。詳細はAI検索からの流入を約3倍にした12ヶ月の施策記録で解説しています。
リッチリザルトが縮小しても、知識パネルとAI検索という2つの活かし方が残っています。構造化データ実装の価値は、短期の表示狙いから、中長期の「機械可読性の担保」にシフトしつつあります。
大手はやらない、中小企業こそ入れるべき——ポジショニングの話
少し角度を変えた話をさせてください。
私（岡野）が実際に調べてみると、いわゆるWeb業界の有名企業・大手ブランドのサイトでも、構造化データが実装されていなかったり、最小限にとどめられていたりするケースが少なくありません。これは「知識不足」というより、意図的な選択であるケースも少なくないと考えています。
すでに指名検索で十分な流入があり、ブランドが確立されている企業にとって、構造化データは投資対効果が合いにくい領域です。前述のとおり、実装・運用には継続的な手間がかかります。ブランド力で検索結果の上位とAI検索の引用をある程度カバーできるなら、「あえてやらない」という判断も経営としては合理的です。
一方で、中小企業はこの構図が真逆です。ブランド力で戦いにくい分、機械可読性が有力な打ち手になり得ます。構造化データを整えることで、AI検索・知識パネル・リッチリザルトといった「大手が重視していない入口」から、発注検討層に直接リーチできるようになります。いわば、大手が重視しない空白地帯は、中小企業にとって狙い目になり得る領域です。
ENVY DESIGNは構造化データ実装において業界でもかなり踏み込んだ対応を続けていますが、これは趣味でも技術遊びでもなく、「中小企業こそ力を入れるべき集客施策」だと考えているためです。自社サイトで12ヶ月で約3倍のAI検索流入を実現できたのも、この方針を早期に決めて実装してきた結果です。
つまり、構造化データに関しては——
- 大手・既存ブランド：あえて最小限にとどめる選択もあり得る
- 中小企業：むしろここで差を付けるべき領域
という整理になります。自社のポジションを踏まえて、投資判断をするのが合理的です。
必須スキーマ6種と使いどころ
schema.orgには数百種類のスキーマが定義されていますが、中小企業のコーポレートサイト・サービスサイトで実用上押さえるべきは6種類に絞れます。
スキーマ1：Organization——サイト全体を代表する企業情報
会社名、ロゴ、所在地、電話番号、SNSアカウントなど、運営組織の基本情報を記述するスキーマです。通常はトップページまたはサイト全体で1回だけ記述し、全ページに展開します。テーマ側のheader.phpで自動出力するのが一般的です。
スキーマ2：LocalBusiness——地域密着ビジネスの情報
Organizationの子分類にあたり、物理的な店舗・事業所を持つビジネスに使います。営業時間（openingHours）、緯度経度、受け入れ可能な決済手段などを記述できます。東京都港区のWeb制作会社といった地域性のある事業は、LocalBusinessを明示することで「近くのWeb制作会社」といった地域クエリでの認識が向上します。Organizationと両方実装するのが定石です。
スキーマ3：BlogPosting——ブログ記事・コラム
ブログやコラム記事に付与するスキーマです。記事タイトル、公開日、更新日、著者、画像などを記述します。AI検索が記事を引用するとき、著者情報と日付は引用判断の根拠として重要な役割を果たします。author配下には必ずPersonスキーマで著者を明示しましょう。Personスキーマの詳細（顔写真の必須性など）はPersonスキーマに顔写真は必須か｜中小企業向け実証と指針で検証しています。
スキーマ4：FAQPage——よくある質問ページ
質問と回答のペアを構造化して記述するスキーマです。発注検討フェーズの具体質問に対する回答をFAQPage化しておくと、AI検索に引用されやすくなります。FAQリッチリザルトは制限されましたが、AI検索への引用は別ロジックで判定されるため、FAQPage実装の価値は依然として高い状態です。AI検索に特化したFAQ戦略はAI検索時代のFAQ戦略で詳しく解説しています。
スキーマ5：Service——提供サービスの定義
サービスページ（/service/以下）で使うスキーマです。サービス名、提供者、対応エリア、料金プランなどを記述できます。offersフィールドにUnitPriceSpecificationで月額プランを記述すると、AI検索で「月額〇万円のWeb制作保守サービス」といった具体質問に対応しやすくなります。当社のAIO・GEO対策サービスでも、Serviceスキーマをoffers込みで実装しています。
スキーマ6：BreadcrumbList——パンくずリスト
ホーム→親階層→現在ページ、という階層構造を記述するスキーマです。視覚的なパンくず表示とは別に、JSON-LDでも必ず記述します。AIがサイト構造を正確に把握する重要な手がかりになります。最低3階層（ホーム／カテゴリ／個別ページ）を記述するのが基本です。
ページ種別ごとの実装マップ
6種のスキーマを、ページ種別ごとに「どれを入れるか」マッピングすると次のようになります。
- サイト全体共通：Organization＋LocalBusiness
- トップページ：Organization＋LocalBusiness
- 会社案内：Organization＋LocalBusiness＋BreadcrumbList
- ブログ記事：BlogPosting＋FAQPage（FAQセクションあれば）＋BreadcrumbList
- FAQ個別ページ：FAQPage＋BreadcrumbList
- サービスページ：Service（offers含む）＋FAQPage（あれば）＋BreadcrumbList
この組み合わせは「最低限」の構成です。たとえばレシピサイトならRecipe、求人ページならJobPosting、ECサイトならProductを追加していきます。ただし中小企業のサイトでは、この6種が揃っていないケースが圧倒的多数で、まずはここを整えるだけで他社との差が出ます。
現場でつまずきやすい実装ポイント
ここからは、構造化データを実装するときにつまずきやすいポイントと対処法をご紹介します。公式ドキュメントには書かれていない、現場寄りの注意点です。
ポイント1：FAQの本文数とJSON-LDの質問数が一致しない
HTMLのFAQセクションに7つの質問があるのに、JSON-LDのmainEntity配列には5つしか入っていない、というズレがよく起きます。原因はリライト時にHTMLだけ更新してJSON-LDを更新し忘れるパターンが多いです。Google Rich Results Testでは構文エラーにはならず通過してしまうため、見落としやすい事故です。
対処：リライト時に「HTML本文のh3（質問）の数」と「JSON-LDのQuestionオブジェクトの数」を目視で一致させる運用を固定化します。当社ではチェックリスト化して毎回確認しています。
ポイント2：回答テキスト内のダブルクォートでJSON-LDが壊れる
Answer.text 内にダブルクォート（半角の引用符）が含まれると、JSON全体がパースエラーで読み込まれません。人間には見えない不具合で、しかもテキスト表示は問題なく見えるため発見が遅れがちです。
対処：ダブルクォートは全角の「”」「“」に置換するか、バックスラッシュでエスケープ処理します。公開前にJSON.parse()等のバリデータで検証する習慣を付けると確実です。
ポイント3：画像URLが相対パスになっている
logo・image・authorのimageなどに相対パス（/images/logo.png）を入れると、schema.orgの仕様上は認識されにくいことがあります。
対処：画像URLは必ず絶対URL（https://envydesign.jp/images/logo.png）で記述します。
ポイント4：Organizationの重複記述
トップページと会社案内ページの両方で、別内容のOrganizationを記述してしまうケースがあります。情報が矛盾すると、検索エンジンは「どちらを信じていいか分からない」状態になります。
対処：Organizationはテーマ側で1回だけ生成し、全ページで同一内容を出力するのが基本です。会社案内ページで別途記述する場合は、@idで紐付けるか、そもそも重複させないルールにします。
ポイント5：BreadcrumbListのpositionが1から始まっていない
positionは1から連番で、欠番があってはいけません。2から始まっていたり、position 2が抜けていたりすると、パンくずスキーマ全体が無効扱いになります。
対処：BreadcrumbListを生成する際、必ずposition: 1をホームに割り当て、連番で増やします。
構造化データは記事の改修やページ修正のたびに、HTMLとJSON-LDの両方を調整する必要があり、運用の手間がかかる部分でもあります。当社ではできる限り対応していますが、制作会社でもここまで手が回っていないケースは多く、会社の方針として構造化データの実装・更新を提供範囲に含めていないところもあります。依頼先を検討する際は「構造化データの運用まで対応してもらえるか」を確認しておくと、後の運用フェーズで差が出やすいポイントです。
実装後の検証方法
構造化データを実装したら、必ず以下のツールで検証します。
- Google Rich Results Test：実装したURLを入力すると、検出されたスキーマの一覧と、リッチリザルトとして認識されるかの判定が出ます。公開直後だけでなく、大幅なリライト後にも都度チェックする習慣が大事です。
- Schema Markup Validator：schema.org公式のバリデータです。Google Rich Results Testがリッチリザルト対象スキーマに絞った判定をするのに対し、こちらは全スキーマの構文妥当性を検証します。Google対象外のスキーマ（たとえばCreativeWorkなど）を使う場合はこちらで検証します。
- Google Search Console「拡張」レポート：公開後しばらく経つと、Search Consoleの「拡張」セクションにFAQ・パンくず・商品・求人などの検出状況が表示されます。エラーがあれば通知されるので、運用フェーズでの監視に役立ちます。
AI検索時代における構造化データの意味
冒頭でも触れましたが、構造化データの価値は2026年時点で「リッチリザルト狙い」から「機械可読性の担保」へとシフトしています。
AI検索（ChatGPT・Perplexity・Gemini・GoogleのAI Overviews）は、複数のWebページを読み込んで回答を生成する仕組みです。このとき、ページが構造化データで「この情報は会社名」「この情報はFAQの回答」と明示していると、AIは引用元としてそのページを採用しやすくなります。
逆に、見た目は同じでも構造化データがないページは、AIにとって「本文から推測するしかないページ」になりがちです。同じ情報でも、構造化データがあるほうが引用候補として優位に立ちます。
当社が自社サイトでAI検索流入を約3倍に伸ばせた施策の中心は、この構造化データの網羅的な実装でした。特別な裏技ではなく、本記事で挙げた6種類のスキーマをページ種別ごとに適切に配置し、つまずきのない形で運用を継続したことが効いたと考えています。詳しい施策プロセスはAI検索からの流入を約3倍にした12ヶ月の施策記録をご覧ください。
おわりに：まずは「自サイトの現状把握」から
構造化データは、一度に全部を理想形に仕上げる必要はありません。現在のサイトでどのスキーマが実装されているか、ページ種別ごとに抜けはないか、を確認するところから始めるのが現実的です。
当社でも、新規制作・リニューアル時はもちろん、既存サイトのSEO改善やAIO・GEO対策のご相談では、構造化データの監査から入ることがほとんどです。「何が入っていて、何が抜けているか」の可視化だけでも、改善の優先順位が一気に明確になります。
構造化データの監査・実装・運用については、AIO・GEO対策（AI検索最適化）サービスで承っています。自社サイトの構造化データを見直したい場合は、お問い合わせフォームよりご相談ください。
よくある質問（FAQ）
Q. 構造化データを入れると検索順位は上がりますか？
A. 構造化データそのものは直接的なランキング要因ではありませんが、間接的な効果はあります。リッチリザルト表示によるCTR向上、知識パネル採用、AI検索への引用採用など、順位以外の流入経路が強化されます。
Q. JSON-LDとMicrodataはどちらを使うべきですか？
A. 特別な事情がなければJSON-LDを選ぶのが無難です。Googleも公式に推奨しており、HTMLとJSONを分離できるため保守性が高く、テーマ側で一括管理しやすい形式です。既存サイトでMicrodataが使われている場合は、リニューアル時にJSON-LDへ移行するのが一般的です。
Q. 構造化データを入れたのにリッチリザルトが出ません。なぜですか？
A. 2023年以降、特にFAQリッチリザルトは信頼性の高いサイトに絞られる傾向があります。構造化データが正しく実装されていても、Google側の判断で表示されないケースは珍しくありません。ただしAI検索への引用や知識パネル採用など、別の形で効果が出ていることが多いため、リッチリザルト非表示だけで失敗と判断しないことが大切です。
Q. どのスキーマから入れ始めるのが効果的ですか？
A. Organization＋LocalBusinessから始めるのが定石です。サイト全体に影響し、知識パネル採用やブランド検索対応にも効きます。次にBreadcrumbList（全ページ）、ブログ運用があればBlogPosting、FAQセクションがあればFAQPage、という順で整えていきます。
Q. 中小企業こそ構造化データに力を入れるべきというのは本当ですか？
A. 指名検索とブランド力で戦える大手と違い、中小企業は機械可読性を武器にできる余地が大きいです。構造化データを整えることで、AI検索や知識パネルから発注検討層に直接リーチできるようになります。大手が重視しない空白地帯は、中小企業にとって狙い目になり得る領域です。
関連記事