ChatGPTに引用される構造化データの書き方とは？失敗例も解説！

構造化データを実装したのに、ChatGPTでは自社サイトが一向に引用されない——そんなもどかしさを感じていませんか？JSON-LDを設置し、Googleのリッチリザルトテストでもエラーが出ていないのに、AI検索での引用は増えない。決して対策を怠っているわけではなく、多くの場合「構造化データをどこまで書けばAIに意味が伝わるのか」という基準が曖昧なまま実装が進んでしまっているのが実情です。

構造化データはただ設置すれば良いわけではなく、ChatGPTが参照元として認識できる形で「意味」を渡せているかどうかで、引用のされやすさが変わってきます。生成AIの認識・文脈理解プロセスを専門的に研究するAIコマース研究所では、診断・支援の現場で、実装はされているのに評価されにくい構造化データに共通する傾向をいくつも確認してきました。

本記事では、ChatGPTに引用されるための構造化データの正しい書き方から、JSON-LDの具体例、実装現場で見られがちな失敗パターンまでを解説します。読み終える頃には、自社サイトの構造化データをどこから見直せば良いか、具体的な着手点が見えてくるはずです。

構造化データを入れているのにChatGPTに引用されないのはなぜか

構造化データを設置してもChatGPTに引用されない主な理由は、Googleのリッチリザルト表示を目的とした従来のSEO向け構造化データと、AI検索エンジンが参照元を選ぶ際に評価する構造化データとでは、重視するポイントが異なるためです。

前者はページ要素をクローラーに分類させることが目的ですが、後者はサイトが「何者で」「何を根拠に」「いつ書いたか」をAIに意味として伝えられているかが問われます。

AI引用の仕組みはGoogleのリッチリザルトと何が違うのか

Googleのリッチリザルト向け構造化データは、検索結果画面に星評価や価格、画像などを表示させることが主な目的で、評価軸はクリック率やSERP上の占有率です。一方でChatGPTやGoogle AI Overviewsのような生成AI検索が参照する構造化データは、リッチリザルト表示ではなく「エンティティ認識」と「AI回答での引用率」が評価軸になります。

主に使われるスキーマも、Product・Recipe・Eventのようなリッチリザルト向けのものではなく、Organization・Article・FAQPage・Personといった、サイトや発信者の実体を定義するスキーマが中心です。同じ構造化データという言葉でも、設置目的が違えば選ぶべきスキーマも書き方も変わってくることを、まず押さえておく必要があります。

構造化データを入れているのにChatGPTに引用されない理由

「構造化データを入れているのにChatGPTに引用されない…」と嘆く人の多くは、すでにSEO対策の一環として何らかの構造化データを設置済みで、「これ以上何をすればChatGPTに引用されるのか分からない」という段階にいると思います。

リッチリザルトテストではエラーが出ていないため実装自体は正しいはずなのに、ChatGPTやPerplexityで自社名や扱っている専門分野について尋ねても、自社サイトが回答の根拠として挙がってこない。その原因は、構造化データの文法的な誤りではなく、AIに渡す情報の「意味の設計」が不足しているケースがほとんどです。

ChatGPTが記事を引用する仕組みと構造化データの役割

ChatGPTは、ページのビジュアルな見た目ではなく、テキストの意味的な文脈とメタデータを解析してコンテンツを理解しています。構造化データは、このセマンティクス理解を補強する「AIへの注釈」として機能し、AIがサイトをエンティティ（固有の存在）として認識し、回答生成時の参照元として採用するかどうかに影響します。

LLMはHTMLの見た目ではなく意味的な文脈を読んでいる

従来のSEOでは、見出しタグの使い方やページの視覚的なレイアウトが評価に影響することがありましたが、生成AI検索においては、ページがどのように表示されるかよりも「何について」「誰が」「どのような根拠で」書いているかという意味的な情報がより重視される傾向にあります。

JSON-LDでOrganizationスキーマを設置することで、AIは「このドメインは○○という企業が運営する、××分野の専門サイトである」という情報を、本文を読み解く手間なく直接取得できるようになります。この「AIに解釈させる」のではなく「AIに直接渡す」という発想の転換が、構造化データ設計の出発点になります。

ChatGPTが参照元として選ぶ際に見ているシグナル

AI検索が引用元を選ぶ際に参照するシグナルとしては、コンテンツの一次情報性（独自調査や専門家による監修があるか）、サイトのエンティティ認識度（検索エンジンのナレッジグラフへの登録状況）、構造化データによる意味的な明示（誰が・何を・いつ書いたか）、外部の権威あるサイトからの言及・引用の有無などが挙げられます。

このうち構造化データは、サイト側が能動的にコントロールできる数少ない直接的なシグナルです。他の要素（外部からの言及や専門家による監修の獲得）が時間のかかる中長期施策であるのに対し、構造化データの実装は比較的短期間で着手できるため、AI検索対策の中でも優先度の高い施策として位置づけられます。

ChatGPTへの引用を狙うために優先すべき構造化データ3種

ChatGPTへの引用を狙う場合、数あるスキーマの中でもOrganization・Article・FAQPageの3種類を優先的に実装することが、最も費用対効果の高い進め方です。この3種はいずれも「サイトの正体」「コンテンツの信頼性」「回答の直接引用素材」という、AI引用に直結する役割を担っています。

Organizationスキーマでサイトの正体を明示する

Organizationスキーマは、サイト全体を運営する企業・団体の情報をAIに伝える基盤となるスキーマです。サイト内の1ページだけに設置するのではなく、全ページのhead要素に共通して設置することで、AIがどのページからクロールしても同じエンティティ情報を取得できる状態が理想とされています。

特に重要なのが「sameAs」プロパティで、WikidataのQIDやWikipedia記事のURL、公式SNSアカウントのURLなどを列挙することで、AIがすでに持っている知識ベースと自社サイトを接続できるようになります。SNSアカウントのURLだけをsameAsに設定しているケースは少なくありませんが、AI検索の観点ではWikidataやWikipediaとの接続の方がエンティティ認識への効果が大きいとされている点は見落とされがちです。

Articleスキーマで一次情報性・信頼性を担保する

Articleスキーマは、個々の記事について「誰が」「どんな根拠で」「いつ」書いたかをデータとして明示する役割を担います。headline・description・author・publisher・datePublished・dateModifiedといった基本プロパティに加えて、about（記事が扱う概念の定義）やmentions（記事内で言及する関連エンティティ）、citation（参考にした外部ソース）を実装することで、記事の専門性や情報源の信頼性をAIに伝えやすくなります。

特にdateModifiedは、更新時に書き換えを忘れがちなプロパティです。本文を更新したのにdateModifiedが古いままだと、AIが情報の鮮度を正しく評価できず、せっかくの更新が評価に反映されない可能性があります。

FAQPageスキーマで回答をそのまま引用させる

FAQPageスキーマは、質問と回答のペアをAIにそのまま提示できる形式のため、ChatGPTへの引用効果が最も高いスキーマのひとつとされています。設計のポイントは、質問文を実際の検索クエリに近い自然な文体にすること、回答は質問に対して完結した一文から始めること、そして1ページあたり3〜10問程度に収めることです。

回答文の目安としては100〜250文字程度が引用されやすいとされており、「詳しくはこちらをご覧ください」のような不完全な回答で終わらせてしまうと、AIがそのまま使える情報がないため引用の対象から外れやすくなります。回答フィールド単体で意味が完結しているかどうかを、設置後に必ず確認することが重要です。

【JSON-LD例】ChatGPT引用を狙う構造化データの書き方

ここまで解説した3種のスキーマについて、実際のJSON-LDの記述例を紹介します。自社サイトの現状のコードと照らし合わせながら、不足しているプロパティがないか確認してみてください。

Organizationスキーマの記述例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "株式会社〇〇",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png"
  },
  "description": "〇〇分野における専門メディアを運営する企業です。",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q〇〇〇〇〇〇",
    "https://ja.wikipedia.org/wiki/〇〇",
    "https://twitter.com/example"
  ],
  "knowsAbout": ["LLMO", "SEO", "生成AI最適化", "構造化データ"]
}
</script>

サイト全体のheadに設置し、@idを固有のURLで統一することで、複数ページに同じ情報を重複定義してしまうミスを避けられます。

Articleスキーマの記述例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/article-slug/#article",
  "headline": "記事タイトル（60文字以内）",
  "description": "記事の要約（150文字程度）",
  "datePublished": "2026-08-01T09:00:00+09:00",
  "dateModified": "2026-08-05T09:00:00+09:00",
  "inLanguage": "ja",
  "author": {
    "@type": "Organization",
    "name": "株式会社〇〇"
  },
  "publisher": {
    "@id": "https://example.com/#organization"
  },
  "about": {
    "@type": "Thing",
    "name": "構造化データ",
    "description": "AI検索エンジンにコンテンツの意味を伝えるための設計手法"
  }
}
</script>

authorはPersonスキーマで担当者名を明示できる場合はより信頼性が高まりますが、組織として発信する場合はOrganizationスキーマでも問題ありません。

FAQPageスキーマの記述例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化データを実装すれば必ずChatGPTに引用されますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "構造化データの実装だけで引用が確約されるものではありませんが、AIがサイトの意味を正確に認識しやすくなるため、引用される可能性を高める土台として有効とされています。"
      }
    },
    {
      "@type": "Question",
      "name": "FAQPageスキーマは何問くらい設置すべきですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "1ページあたり3〜10問程度が目安です。重複した概念の質問は避け、それぞれの回答が単体で意味の伝わる完結文になるよう設計します。"
      }
    }
  ]
}
</script>

構造化データを実装しても引用されないサイトに共通する課題

構造化データを設置しているのにChatGPTに引用されないサイトには、コードの文法エラーではなく「AIに渡している意味の設計」に共通の課題が見られます。AIコマース研究所のLLMO対策チームが実際の診断・支援先で繰り返し確認してきた傾向として、実装の有無よりも設計の質が引用率を左右しているケースが多いというのが実感です。

実装はしているが「意味が伝わっていない」パターン

もっとも多く見られるのが、構造化データ自体は設置されているものの、about・mentions・sameAsといった「意味を明示するプロパティ」が空欄、あるいはテキストの断片をそのまま入れているだけのケースです。例えばaboutプロパティに「LLMOに関する記事」とテキストだけを記述しているサイトは少なくありませんが、これでは概念をThingスキーマとして定義していないため、AIが記事のトピックを正確に把握しづらくなります。

LLMO診断をする中で、こうした「型は合っているが中身が薄い」構造化データが、実装済みサイトの半数以上に見られます。必須プロパティを埋めることだけを目的化してしまい、AIが実際に参照できる情報量が不足している状態だといえます。

FAQ・Article・Organizationがバラバラに設置され連携していないパターン

もうひとつよく見られるのが、FAQPage・Article・Organizationのそれぞれは設置されているものの、@idの参照関係が結ばれておらず、AIから見ると別々の孤立した情報として扱われてしまっているケースです。本来はArticleスキーマのpublisherプロパティからOrganizationスキーマの@idを参照し、ひとつのエンティティ群として認識させることが望ましいのですが、コピー&ペーストで構造化データを使い回した結果、@idが重複していたり、参照が正しく結ばれていなかったりする実装が散見されます。

個々のスキーマが正しくても、エンティティ同士のつながりが分断されていると、AIがサイト全体を一貫した情報源として評価しにくくなる点は、見落とされやすい落とし穴のひとつです。

実装後に確認すべき効果検証・モニタリングの方法

構造化データは実装して終わりではなく、正しく認識されているかの検証と、実際にAI検索でどう扱われているかの継続的なモニタリングまでがセットです。検証を怠ると、エラーが出たまま放置されたり、効果が出ているかどうか判断できないまま運用が止まってしまったりします。

リッチリザルトテストでのエラー確認

実装後は、Googleが提供するリッチリザルトテストで、JSON-LDが正しく認識されているかをまず確認します。ここでエラーが出る構造化データはクローラーに正しく処理されない可能性があり、AI検索側の評価にも影響しうるため、JSON-LDの構文エラーや必須プロパティの欠落、@idの重複がないかを優先的に修正してください。

WordPressを利用している場合は、Rank MathやYoast SEOといったプラグインでArticle・FAQ・Organizationなどの主要スキーマを自動生成できるため、コードを直接書けない担当者でも実装のハードルを下げられます。ただし、プラグインで自動生成した場合でも、リッチリザルトテストでの出力確認は必ず習慣化することをおすすめします。

ChatGPT・Perplexityでの引用状況の確認方法

技術的な検証が済んだら、実際にChatGPTやPerplexity、Google AI Overviewsで自社ブランド名や専門分野に関するクエリを入力し、自社サイトが引用元として挙がってくるかを確認します。加えて、Google Search Consoleの検索パフォーマンスレポートでAI Overviews経由の掲載ページを確認したり、Googleのナレッジパネルの表示有無をチェックしたりすることも、エンティティとしての認識度合いを測る手がかりになります。

AI検索は再学習のサイクルに依存するため、実装直後に劇的な変化が出るとは限らず、数週間から数ヶ月単位で継続的に確認していく姿勢が必要です。

構造化データ対策は自社実装と外注どちらを選ぶべきか

構造化データ対策を自社で進めるか外注するかは、社内にJSON-LDを扱えるエンジニアリソースがあるか、そして継続的な効果測定・改善サイクルを回せる体制があるかによって判断が分かれます。どちらが優れているというよりも、自社の状況に合わせて選ぶべき問題です。

自社実装が向いているケース

WordPressなどのCMSを利用しており、Rank MathやYoast SEOのようなプラグインで主要スキーマを自動生成できる環境であれば、FAQPageスキーマから着手して段階的にArticle・Organizationへと広げていく自社実装が現実的な選択肢になります。

まずは主要なサービスページやアクセスの多い記事から着手し、リッチリザルトテストで検証しながら進めれば、専門知識がなくても一定のレベルまでは対応可能です。

外注（LLMO対策会社）が向いているケース

一方で、独自のCMSを利用している、あるいはエンティティ設計やナレッジグラフとの接続まで踏み込んで対策したいという場合は、生成AIの引用ロジックを専門的に扱う会社への相談が有効な選択肢になります。

特に、構造化データは正しく設置しても効果が数値として見えにくいため、「実装したつもり」で運用が止まってしまうケースも少なくありません。継続的な検証・改善のサイクルまで任せられる体制があるかどうかは、外注先を検討する際の重要な判断材料になります。

LLMO対策会社を選ぶ際に確認したいチェックポイント

構造化データの実装だけでなく、AI検索全体への対策まで見据えて外注を検討するのであれば、以下の観点を確認しておくと選定の失敗を防ぎやすくなります。

まず、構造化データの実装だけでなく、コンテンツの設計段階からAI引用を意識した提案ができるかどうかです。JSON-LDのコードを書けるだけの会社と、生成AIがどのような文脈理解のプロセスでサイトを評価しているかを踏まえて設計できる会社とでは、成果の出方が変わってきます。

次に、実装後のモニタリング・改善提案まで伴走してくれるかどうかも重要な確認ポイントです。構造化データは一度設置して終わりではなく、AI検索の仕様変化に合わせて継続的に見直す必要があるため、単発の実装代行で終わる契約なのか、継続的なモニタリング体制があるのかは事前に確認しておきたいところです。

こうした観点で自社の現状を客観的に把握したい場合、AIコマース研究所ではLLMO無料診断を提供しています。構造化データの実装状況やエンティティ設計の課題を専門チームの視点で確認できるため、外注を検討する際の判断材料としても、まず自社実装で改善すべき点を把握する目的でも活用いただけます。

ChatGPTに引用される構造化データの書き方に関するよくある質問

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

LLM構造化データとは、ChatGPTやGeminiなどの大規模言語モデルに、ページの意味や信頼性を正確に伝えるためのJSON-LD設計を指す呼び方です。
従来のSEO向け構造化データがリッチリザルト表示を目的とするのに対し、AI検索での引用・エンティティ認識を主目的とする点が異なります。

スキーマとschemaの違いは何ですか？

スキーマ（schema）は構造化データの記述形式そのものを指す用語で、Schema.orgが定めた語彙を使ってJSON-LD形式で記述します。
「Organization」「Article」「FAQPage」など、目的ごとに定義された型（タイプ）があり、それぞれAIに伝える情報の種類が異なります。

構造化データの実装にコーディングの専門知識は必要ですか？

基本的なHTML知識があれば実装可能です。
JSON-LDはscriptタグ内にJSON形式で記述するだけでページの見た目に影響しないため、WordPressであればRank MathやYoast SEOなどのプラグインで自動生成することもできます。

構造化データの効果はどれくらいの期間で出ますか？

AI検索への引用効果は、数週間から数ヶ月単位で確認していく必要があります。
Google AI Overviewsへの掲載は実装後2〜4週間程度で変化が見られることがある一方、ChatGPT・GeminiはAIモデルの再学習サイクルに依存するため、より長い期間で評価する必要があります。

Wikidataに登録されていなくても構造化データは効果がありますか？

Wikidata未登録でも、Organization・Article・FAQPageスキーマの実装自体はAI検索への効果を持ちます。
ただし、sameAsプロパティでWikidataのQIDを指定できる場合は、AIによるエンティティ認識の精度がより高まるとされているため、並行してWikidataへの登録を進めることが望ましいとされています。

構造化データを設置したらChatGPTに必ず引用されますか？

構造化データの設置だけで引用が確約されるわけではありません。
AIがサイトの意味を認識しやすくなる土台として有効ですが、コンテンツ自体の専門性や更新頻度、外部からの言及なども合わせて評価される傾向があります。

FAQPage以外に優先すべき構造化データはありますか？

Organization・Articleスキーマの実装も優先度が高いとされています。
Organizationはサイト運営者の実体を、Articleは記事の著者・公開日・トピックをAIに伝える役割を担っており、FAQPageと組み合わせることで相乗効果が期待できます。

構造化データの対策を外注する場合の費用相場はいくらですか？

依頼先や対応範囲によって幅がありますが、月額数十万円規模の継続支援プランを提示している会社が一般的です。
単発の実装代行のみか、モニタリング・改善提案まで含む継続支援かによって費用感が変わるため、見積もり時に対応範囲を確認することが重要です。

構造化データを実装したのにAI検索での引用が増えない場合、何を疑うべきですか？

まずabout・mentions・sameAsなど、意味を明示するプロパティが空欄や簡易的な記述に留まっていないか確認してください。
文法エラーがなくても、AIが参照できる情報量が不足しているケースが診断現場では多く見られる傾向があります。

構造化データの実装を自社と外注のどちらで進めるか、判断基準はありますか？

WordPressでプラグインを使える環境なら自社実装、エンティティ設計まで踏み込みたい場合は外注が向いています。
継続的な検証・改善のサイクルを回せる社内体制があるかどうかも、判断材料のひとつになります。

構造化データは「AIに情報を見せる」から「AIに意味を渡す」設計へ

構造化データによるChatGPT対策で最も重要なのは、「AIに情報を見せる」設計から「AIに意味を渡す」設計へと発想を転換することです。本記事のポイントを振り返ります。

構造化データの実装は、数あるAI検索対策の中でも自社でコントロールしやすく、今すぐ着手できる施策のひとつです。まずは自社サイトのOrganizationスキーマとFAQPageの回答内容から見直してみてください。