LLMOの構造化データ｜Schema.orgの書き方と実装手順

はじめに

「構造化データ」はSEOの文脈で語られることが多いが、LLMO（AI検索最適化）においても重要な役割を担います。AIがWebサイトの情報を正確に理解・引用するためには、構造化データが「道標」として機能します。

本記事では、構造化データの基本・LLMOとの関係・優先的に実装すべきSchema.orgタイプ・実装の確認方法を解説します。

構造化データとは

構造化データとは、Webページの内容を機械（検索エンジン・AI）が理解しやすい形式で記述する追加情報です。HTMLのコンテンツ自体はそのままに、「このテキストは会社名です」「この数値は評価スコアです」「この質問には対応する回答があります」という意味情報を追加することで、機械的な解釈を助ける。

最も一般的な形式が「JSON-LD」（JavaScript Object Notation for Linked Data）で、HTMLの<script type="application/ld+json">タグ内に記述します。

なぜ構造化データがLLMOに効くのか

理由1：AIの情報解釈の精度が上がる

構造化データがないと、AIは「このページのこのテキストが何を意味するか」をコンテキストから推測する必要があります。構造化データがあれば「会社名はXXX・設立年は2020年・所在地は東京都」という情報を明示的に機械に伝えられ、誤解釈のリスクが減ります。

理由2：FAQの内容が直接参照される

FAQPageのSchema.orgを実装すると、「質問：○○とは？　答え：△△です」という対応関係がAIに明確に伝わる。PerplexityやGoogleのAIオーバービューは、このFAQの構造を積極的に活用して回答を生成します。

理由3：検索結果でのリッチスニペット＋AI参照の相乗効果

構造化データを実装することで、Google検索での「リッチスニペット（星評価・FAQ展開等）」が表示されやすくなります。この視認性の向上が、AIのクローリング頻度・評価にもプラスの影響を与えると考えられます。

LLMO全体の施策について詳しく知りたい方は「LLMO対策の具体的なやり方」をご覧ください。

Schema.orgとは｜構造化データの基本

Schema.orgは、Webページの内容を機械が解釈できる形で記述するための共通の語彙集です。検索エンジン各社が共同で策定しており、「組織」「記事」「よくある質問」「商品」といった対象の種類（type）と、それぞれが持てる項目（property）が定義されています。

記述形式にはJSON-LD、Microdata、RDFaの3つがありますが、HTMLの構造と切り離して書けるJSON-LDが推奨される形式です。JSON-LDでは、@contextに語彙の参照先としてschema.orgを指定し、@typeで対象の種類を宣言したうえで、必要な項目を並べます。

前提として、構造化データに書く内容は、ページ上に表示されている情報と一致している必要があります。ページに存在しない情報を構造化データにだけ記述すると、意図した扱いを受けられない場合があります。

LLMOのために優先的に実装すべきSchema.orgタイプ

1. Organization（企業情報）

企業・サービスの基本情報を構造化するタイプ。AIが「この会社は何者か」を正確に理解するための基盤。

実装例（概念）

LLMO的な価値：「おすすめのWeb制作会社を教えて」「Vercel対応の会社はどこ？」という質問に対して、AIが正確に自社情報を参照できます。

2. FAQPage（よくある質問）｜そのまま使えるJSON-LD

FAQPageは、LLMOで最も即効性が高い構造化データの一つです。質問と回答の対応関係を明示する型です。ページ上にFAQのセクションがあることが前提で、表示していない質問を記述することはできません。

mainEntityの配列にQuestion型を並べ、それぞれのnameに質問文、acceptedAnswerのtextに回答文を入れます。回答文にはHTMLタグを含められますが、装飾目的のタグは外し、文章として読める状態にしておくと解釈が安定します。

以下は、質問文と回答文を差し替えるだけで使えるようにした雛形です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "ここに質問文を入れます",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "ここに回答文を入れます"
      }
    }
  ]
}
</script>

実装例（概念）

LLMO的な価値：ユーザーがAIに質問した際に、このFAQの「質問→答え」の対応関係が直接参照・引用されます。

3. Article（記事・ブログ）の書き方｜著者・公開日・更新日の指定

ブログ記事・ナレッジコンテンツに実装する構造化データ。著者情報・公開日・更新日を明示することで、E-E-A-TとコンテンツのFreshness（新鮮度）をAIに伝えます。

特に重要なプロパティ

• author：著者名・著者の専門性情報（PersonまたはOrganization）

• datePublished：公開日

• dateModified：最終更新日（鮮度の証明）

• headline：記事タイトル

• description：記事の要約

datePublishedとdateModifiedは、年月日と時刻、タイムゾーンを含むISO 8601形式で記述します。dateModifiedは本文を実際に修正したときだけ更新し、修正していないページの日付を動かさないでください。authorには、個人名を入れる場合はPerson、組織名で示す場合はOrganizationを指定します。

＜書き方の例＞

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "ここに記事タイトルを入れます",
  "description": "ここに記事の要約を入れます",
  "author": {
    "@type": "Person",
    "name": "ここに著者名を入れます"
  },
  "publisher": {
    "@type": "Organization",
    "name": "ここに貴社の正式名称を入れます"
  },
  "datePublished": "2026-01-01T09:00:00+09:00",
  "dateModified": "2026-01-01T09:00:00+09:00"
}
</script>

4. BreadcrumbList（パンくずリスト）

サイトの階層構造をAIに伝えるパンくずリストの構造化データ。「このページはどのカテゴリに属するか」という文脈情報がAIの理解を助けます。

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

提供するサービス・製品の詳細情報を構造化するタイプ。「○○の料金は？」「○○のサービスの特徴は？」という質問への回答に使われます。

LLMO的に重要なプロパティ

• name：サービス名

• description：サービスの説明

• provider：提供会社

• offers：料金情報（AIに料金を正確に伝えられる）

6. Person（人物）

著者・専門家の情報を構造化するタイプ。E-E-A-Tの「Experience（経験）」「Expertise（専門性）」を機械的に伝えるために有効。

実装箇所：著者プロフィールページ・記事の著者情報セクション

構造化データの実装方法

Next.jsでの実装

Next.jsのApp Routerでは、ページコンポーネント内またはlayout.tsx内でJSON-LDを実装できます。

ヘッドレスCMSとの連携

Orizm等のヘッドレスCMSを使っている場合、CMSのコンテンツから自動的に構造化データを生成する仕組みを構築できます。

• ブログ記事ページ：ArticleのSchema.orgを自動生成（タイトル・著者・公開日をCMSから取得）

• 事例ページ：Case StudyのSchema.orgを自動生成

• FAQページ：FAQPageのSchema.orgを自動生成（CMSのQ&Aコンテンツから動的に生成）

構造化データの確認・テスト方法

Google Rich Results Test

GoogleのRich Results Testツール（search.google.com/test/rich-results）にURLを入力すると、構造化データが正しく実装されているかを確認できます。エラー・警告が表示された場合は修正が必要です。

Schema Markup Validator

Schema.orgが提供するバリデーター（validator.schema.org）でJSON-LDの構文チェックができます。

Google Search Console

Search ConsoleのリッチリザルトレポートでFAQ・記事等の構造化データが正しく認識されているかをモニタリングできます。

実装後の検証手順

実装したJSON-LDは、公開前と公開後の2段階に分けて確認します。使用するツールは、前掲の「構造化データの確認・テスト方法」を参照してください。

1. 構文を確認する：JSON-LDはカンマや括弧の欠落で全体が無効になります。まず構文エラーがないことを確認します。

2. 描画後のHTMLで確認する：JavaScriptで生成している場合、ソースコードの表示では確認できないことがあります。ブラウザの開発者ツールを開き、描画後のHTMLにscriptタグが含まれているかを確認します。

3. 公開後に認識を確認する：検索エンジン側が新しいHTMLを取得するまでには時間差があります。数日から数週間の幅を見込み、レポート上で認識されるまで待ちます。

4. 定期的に見直す：テンプレートの改修で構造化データが外れることがあります。改修のたびに主要なページを1つ選んで確認する運用にしておくと、欠落に気づきやすくなります。

構造化データ実装の優先順位

時間・リソースが限られる場合の実装優先順位を示す。

最優先（1週間以内）

• Organization（会社情報）：1回の実装でサイト全体に効果

• FAQPage：即効性が高く実装が比較的容易

高優先（1ヶ月以内）

• Article（記事ページ）：ブログ・ナレッジコンテンツへの実装

• BreadcrumbList：サイト全体への一括実装

中優先（3ヶ月以内）

• Service（サービスページ）：各サービスページへの実装

• Person（著者情報）：著者プロフィールへの実装

まとめ

構造化データはSEOのリッチスニペット獲得だけでなく、AIへの情報の機械可読性を高めるLLMO施策としても重要です。Organization・FAQPage・Articleの3つから始めることで、AIが自社情報を正確に理解・引用しやすい基盤が整う。

Next.jsとヘッドレスCMSを組み合わせた実装では、CMSのコンテンツから構造化データを自動生成する設計が特に効果的です。

次の記事では、LLMOとE-E-A-Tの関係——コンテンツの信頼性・権威性をどのように高めるかを解説します。