構造化データはAIに読まれているのか？ ── ChatGPTの実験結果と、それでもマークアップを続ける理由（2026年8月時点）

01 何が起きたか ── 構造化データがAIモデルに届いていないという実験結果

実験の中身 ── 誰が、何を、どうやって確かめたか

2026年、SEOコンサルタントのDan Petrovic氏（dejan.ai）が、ChatGPTのブラウジングツールが構造化データを利用しているかどうかを確かめる実験を公開しました。手法はシンプルです。まったく同じ本文を持つ2つのページを用意し、一方にはJSON-LD形式の構造化データを埋め込み、もう一方には埋め込みません。ページの内容は架空の企業「TechFlow Solutions」の会社概要・代表者情報・製品情報で、どちらのページも人間が読む文章としては同一です。この2ページに対してChatGPTのブラウジングツールで同じ質問（企業概要・代表者の経歴・提供製品など）を投げかけ、応答に差が出るかを観察するという設計です。

結果 ── 抽出されたのはプレーンテキストだけだった

結果は明確でした。Petrovic氏は「I don't see any evidence of schema even reaching the model（スキーマがモデルに届いている証拠は見当たらない）」と述べています。ブラウジングツールが取得していたのはプレーンテキストの本文のみで、JSON-LDやmetaタグ形式のスキーママークアップは、応答の生成に一切利用されていませんでした。構造化データの有無で応答内容に違いは生まれず、2ページとも同じ回答が返ってきています。この実験結果自体は、コメント欄で他の実務者からも一定の妥当性が指摘されており、少なくとも「現時点のChatGPTブラウジングツールが構造化データを読んでいる形跡はない」という点は、複数人の目で確認された事実として扱えます。

「なぜ抽出されないのか」──トークン化という説明

この結果を受けて、SEO実務者のMark Williams-Cook氏がLinkedIn上で技術的な補足を加えています。氏の指摘は、LLMが文章を処理する前段階であるトークン化のプロセスに関わるものです。JSON-LDのようなマークアップ言語は、"@type": "Organization"のように、キーと値がコロンや引用符で明示的に結びついた構造を持ちます。ところがトークン化の過程では、この文字列が意味のまとまりを保ったまま扱われるとは限らず、バラバラのトークンに分解されてしまう可能性が指摘されています。氏の言葉を借りれば「スキーマの主な価値はその明示性にあるが、まさにその明示性がトークン化の過程で失われてしまう」ということです。これは推測を含む技術的な仮説であり、Petrovic氏の実験結果そのもの（抽出されなかったという事実）とは切り分けて理解する必要があります。

鈴木謙一氏のコメント ── 「完全に無関係」とは言い切れない

この実験結果を日本語で紹介した鈴木謙一氏は、単純な「構造化データは無意味」という結論には距離を置いています。「構造化データがまったく無関係というのもまた違うのかなというのが僕の考えです。少なくともGoogleのLLM（Gemini）は、Google検索のインデックスを使っているのですから」と述べ、Google自身のAI OverviewやAIモードがナレッジグラフやショッピンググラフにアクセスしている以上、構造化データが間接的に関与する可能性はあるという見方を示しています。この「直接は届いていないが、間接的な関与はありうる」という2段構えの見立てが、本記事全体の立ち位置にもなります。

02 なぜ・背景 ── 構造化データは何のために作られ、どこまでを保証しているか

そもそも構造化データは何のために作られたか

Google公式の構造化データ入門は、その目的をこう説明しています。「Google uses structured data that it finds on the web to understand the content of the page, as well as to gather information about the web and the world in general（Googleはウェブ上で見つけた構造化データを、ページの内容を理解するために、またウェブや世界全般についての情報を集めるために使用する）」。この一文には、①ページ内容の理解と②リッチリザルトなどの検索結果表示という、性質の異なる2つの用途が同居しています。構造化データの導入を検討するとき、この2つを分けずに「効果があるかどうか」を一括りに論じてしまうと、01章のような実験結果と、Google公式の説明との間で話がかみ合わなくなります。

「表示は保証されない」という、公式ドキュメント自身の留保

もう1点、公式ドキュメントが明記している重要な留保があります。構造化データ入門ページは、リッチリザルトについて「search results that are more engaging to users and might encourage them to interact more（ユーザーにとってより魅力的で、より多くの反応を促す可能性がある検索結果）」という条件付きの表現を使っています。「必ず表示される」とは一言も書かれていません。マークアップの実装は、リッチリザルトが表示される条件を満たすための必要条件ではあっても、表示を保証する十分条件ではないというのが、Google自身の立場です。この留保は、01章の実験がAIブラウジングツールについて示した結果と、構造の面でよく似ています。「実装したのに効果が出ない」と感じる背景には、そもそも公式が最初から効果を保証していないという事情が重なっていることが少なくありません。

LLMの「学習」段階と、いま使われている「ツール」は別物

01章の実験結果を読むときに混同しやすいのが、LLMが事前学習でウェブ全体をどう扱ったかという話と、いま目の前で動いているブラウジングツールがページをどう取得しているかという話です。Petrovic氏の実験が確かめたのは後者、つまり「ChatGPTのブラウジングツールというアプリケーションが、リアルタイムでページを取得するときに何を抽出するか」です。事前学習の段階でモデルがJSON-LDを含む大量のウェブテキストをどう扱ったかは、この実験の対象になっていません。ツールの実装は運営企業の判断で今後変更されうるものであり、「現時点のツールがそうである」ことと「LLMという技術全体が構造化データを扱えない」ことはイコールではありません。

RAGという仕組みの基本

もう1つ整理しておきたいのがRAG（Retrieval-Augmented Generation、検索拡張生成）という仕組みです。多くの生成AIの検索・ブラウジング機能は、ユーザーの質問に対して、①関連しそうな情報を外部から取得し、②それをプロンプトの一部として組み込み、③その文脈をもとにLLMが応答を生成する、という流れで動いています。01章の実験は、このうち「取得したページの中身をどう処理するか」という部分を扱ったものです。一方で、取得元となる検索インデックスやナレッジグラフそのものが、どのように構築されているかは別の話です。この区別が、04章の「型別に見る」で扱う内容の土台になります。

Google公式ドキュメントは、AIについて何も語っていない

実際に構造化データ入門のページ全体を確認すると、興味深い事実があります。このページには生成AI・AI Overview・AIモードといった言葉への直接の言及が見当たりません。構造化データの説明は、あくまで従来の検索結果とページ内容の理解という文脈で書かれています。これは「AIには使われない」ことの証拠にはなりませんが、少なくとも「Google公式が、構造化データとAI機能の関係を明示的に説明している文書」は、2026年8月時点で見当たらないという事実は確認できます。01章の実験結果と合わせて読むと、「AIへの効果」を語るための一次情報そのものが、公式側にはまだ十分に整備されていない段階だと分かります。

03 この記事で出てくる用語

本文で使う5つの用語を、先に整理しておきます。

04 型別に見る ── 適用範囲・この実験が測っていないこと・とるべき手順

🅰 検索（リッチリザルト）で今も効くこと

01章・02章の実験結果は、あくまでAIブラウジングツールでの理解に関するものであり、検索エンジンのリッチリザルト表示という従来の用途を否定するものではありません。Google公式の構造化データギャラリーには、FAQ・パンくずリスト・レシピ・イベントなど、対応するコンテンツタイプの一覧が掲載されています。これらの一覧に該当するページであれば、構造化データの実装は今も検索結果の見た目を変えうる、実務上の効果が確認されている施策です。「AIに効かないなら構造化データは不要」という短絡は、検索側の効果まで一緒に手放すことになりかねません。

🅱 この実験が測っていないこと

01章の実験には、明確な範囲の限定があります。第一に、ChatGPTという1つのサービスの、ある時点でのブラウジングツールを対象にした実験であり、Perplexity・GoogleのAI Overview・AIモードなど、他のAI検索・AI回答機能でも同じ結果になるかは、この実験だけでは分かりません。第二に、02章で触れたRAGの4段階のうち、この実験が扱ったのは「取得したページを処理する」段階であり、検索インデックスやナレッジグラフを構築する「取得」段階そのもので構造化データが使われているかどうかは、対象外です。GoogleのAI Overviewやゲミニが、Google自身の検索インデックス（構造化データを使って構築されている可能性がある）を経由して情報を得ている場合、間接的な影響が生じる余地は残ります。第三に、これはある時点のスナップショットであり、AI企業各社がツールの実装を変更すれば、結果は変わりえます。第四に、実験で使われたのは「TechFlow Solutions」という架空企業の会社概要ページ1種類のみで、レシピ・イベント・商品レビューといった、リッチリザルトとの結びつきが強い他のコンテンツタイプで同じ結果になるかは、この実験だけでは判断できません。これらの限定を無視して「構造化データはAIに一切効かない」と一般化してしまうと、実験が示した以上のことを結論づけることになります。

🅲 今日からとるべき手順

以上を踏まえると、実務的な結論は「構造化データをやめる」でも「効果を過信する」でもなく、両方の可能性に備えて実装を続けながら、過度な期待はしないという中庸な立場になります。具体的には、①検索のリッチリザルトに対応するコンテンツタイプがあれば実装は継続する、②AIへの理解を高める主目的は本文の記述の質に置き、構造化データはその補完と位置づける、③AI経由の流入や引用については、構造化データの効果を前提にした施策より、本文そのものの一次情報の充実を優先する、という順序です。05章のチェックリストは、この3点を実際の作業に落とし込んだものです。

05 明日確認できるチェックリスト

チェックリストの狙い

以下は、04章で整理した3つの手順を、実際に手を動かして確認するための12項目です。前半は自サイトの構造化データが実際にどう出力されているかの棚卸し、後半は検索エンジン・生成AIの両方から見たときの実態確認です。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• Rich Results Testに自サイトの主要ページを1本入力し、検出された構造化データの種類とエラー件数を控える
• Search Consoleの「拡張」または「その他の構造化データ」レポートを開き、検出されているタイプの数を数える
• 自サイトのページのソースを表示し、「application/ld+json」という文字列が何箇所あるか数える
• 見つかったJSON-LDの中身をコピーし、オンラインのJSON検証ツールで構文エラーがないか確認する
• Schema.orgで自サイトが使っている型（例:Article）のページを開き、必須プロパティを3つ書き出す
• 使っているCMSやプラグインの管理画面を開き、構造化データの出力元が1つか複数か確認する
• 生成AIのチャットに自サイトのURLを渡し、内容を要約させて事実と一致するか確認する
• 上記の要約に、構造化データにしか記載していない情報(更新日や評価など)が反映されているか確認する
• 自サイトのmeta descriptionを1ページ開き、文字数が100〜160字に収まっているか数える
• 自サイトの見出し(h1〜h3)を1ページ分書き出し、番号が飛んだり戻ったりしていないか確認する
• 自サイトのrobots.txtを開き、AIクローラー(GPTBotなど)を意図せずブロックしていないか確認する
• 上記11項目のうち、5分以内に終わらなかった項目がいくつあったか数える

項目の内訳と、かかる時間の目安

12項目のうち、最初の6項目は自サイトの構造化データが技術的に正しく出力されているかの確認、7番目と8番目はAIが実際に何を読み取っているかの簡易確認、9番目と10番目は構造化データ以外の基本的な情報設計の確認、11番目はAIクローラーの受け入れ状況の確認です。すべてに目を通す時間の目安は1回あたり20〜30分程度で、最後の12番目は、この記事全体の狙いをそのまま自分の手で数字にする項目です。

何から手を付けるべきか

構造化データを一度も実装したことがない場合は、まず5番目のSchema.org確認から始め、自サイトのコンテンツに対応する型があるかを見るのが近道です。すでに実装済みの場合は、1番目から4番目までの技術的な棚卸しを優先し、エラーの有無を確認します。AIからの流入や引用にすでに関心がある場合は、7番目と8番目を先に済ませておくと、この記事の06章・07章で扱う内容と照らし合わせやすくなります。Search Consoleのレポートの見方に迷う場合は、当サイトのSearch Console お助けツールも参考になります。

06 施策の比較 ── 検索とAI理解、それぞれへの効果

比較表の見方

04章までの内容を、構造化データ以外の代替・併用手段と並べて整理します。効果の列は、あくまで公式ドキュメントの記述や01章の実験結果、業界内の一般的な理解に基づく現時点での整理であり、将来のアップデートで変わりうる評価だという前提で読んでください。

施策	検索(リッチリザルト)への効果	AIブラウジング理解への効果(現時点)	実装コストの目安
構造化データ(JSON-LD)	対応タイプなら表示に寄与しうる	今回の実験では未確認	中(型の選定と検証が必要)
meta description	スニペット文言に使われうる	プレーンテキストとして抽出される	低
見出し構造(h1〜h3)	ページ構成の理解を助ける	本文とともに抽出される	低〜中
本文の一次情報・具体性	コンテンツ評価全般に寄与	要約・引用の材料になりやすい	高(取材・検証が必要)
llms.txt	検索エンジンへの効果は未確認	AIクローラーの読み取りは限定的(自サイト実測)	低

無料で使える検証ツール一覧

構造化データの実装状況は、専門知識がなくても無料のツールで確認できます。05章のチェックリストと合わせて使う前提で、代表的なものを整理しました。

ツール	確認できること	提供元
Rich Results Test	リッチリザルトの対象となる構造化データの検出とエラー	Google
Search Consoleの拡張レポート	本番環境でGoogleが実際に検出しているタイプの一覧	Google
Schema.orgのValidator	JSON-LDの構文と、指定した型に対する必須プロパティの充足	Schema.org
ブラウザの「ページのソースを表示」	実際に出力されているJSON-LDの中身そのもの	ブラウザ標準機能

「RAGが構造化データを使う」には、2つの違う意味が混ざりやすい

ここまで見てきた「構造化データ」は、Webページに埋め込むJSON-LDのようなマークアップのことでした。一方で「RAGシステムは構造化データを活用する」という文脈では、まったく別のものを指している場合があります。RAGの実装解説では、リレーショナルデータベースやグラフデータベースといった、企業が内部に持つ構造化された情報源を検索対象に含める設計がしばしば紹介されます。これは、Webページ上のJSON-LDマークアップとは別物です。「RAGは構造化データを使うと聞いたから、自社サイトのJSON-LDもAIに読まれているはずだ」という連想は、この2つの意味の違いを踏まえていないと成立しません。当記事の調べた範囲では、Webページ上のSchema.orgマークアップがRAGの取得段階でどの程度の割合で利用されているかを示す、信頼できる統計は見当たりませんでした。無い統計を推測で埋めるより、この2つの「構造化データ」が別物であるという整理そのものを、答えとして扱います。

他のAIサービスでは検証されていないという限界

06章の比較表にある「AIブラウジング理解への効果(現時点)」は、あくまで01章で扱ったChatGPTのブラウジングツールを対象にした結果です。Perplexity・GoogleのAI Overview・AIモード・Claude等の他のAIサービスが、同じようにJSON-LDを読み飛ばすのか、それとも独自の実装で構造化データを部分的に利用しているのかは、公開されている実験としては確認できていません。特にGoogleのAI機能については、02章で触れたとおり自社の検索インデックスやナレッジグラフを経由している可能性があり、ChatGPTのブラウジングツールとは仕組みが異なる可能性があります。「主要なAIサービスすべてで構造化データが無視される」という一般化はできないというのが、現時点で言える範囲です。

JSON-LDの実装例（Article型）

実装のイメージを持てるよう、記事ページに使われるArticle型の最小構成を示します。実際のコードでは、値の部分を各ページの実データに置き換えます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事のタイトル",
  "datePublished": "2026-08-18",
  "dateModified": "2026-08-18",
  "author": { "@type": "Person", "name": "著者名" }
}
</script>

このタグは、ページのHTML内、通常は<head>要素の中に1つだけ配置します。実装後は、05章のチェックリスト4番目にあるとおり、JSON検証ツールで構文エラーがないかを確認し、Rich Results Testで想定どおりに検出されるかを確かめる、という2段階の確認が欠かせません。headlineとdatePublishedは、Article型の必須プロパティとしてよく案内される項目ですが、対応タイプによって必須項目は異なるため、03章で触れたSchema.orgのページで、実装したい型ごとに確認する必要があります。ゼロから手書きするのが手間な場合は、当サイトの構造化データ自動作成ツールでたたき台を作ってから、値を書き換える方法もあります。

実装コストの考え方

上の比較表からも分かるとおり、構造化データの実装コストは「中」程度で、meta descriptionや見出し構造ほど手軽ではない一方、本文の一次情報を充実させるほどのコストもかかりません。この位置づけを踏まえると、本文の質を犠牲にしてまで構造化データの精緻化に時間を割く優先順位ではないというのが、01章から06章までの内容を踏まえた実務的な整理です。すでに対応タイプのコンテンツがあり、実装のハードルが低いのであれば継続する価値はありますが、新規に大きな工数を割く判断は、04章の🅲で示した順序に沿って検討することをおすすめします。

07 当サイトでの実測 ── Fan-Out APIによるカバレッジ測定という手法

「読まれているか」を機械的に確認するもう1つの方法

当サイトでは、記事を公開する際にFan-Out APIと呼ぶ仕組みを使い、生成AIが想定しうる複数の関連質問（サブクエリ）に対して、その記事の本文がどこまで回答をカバーしているかを機械的に判定しています。これは構造化データの検証ではなく、本文のプレーンテキストがどれだけの問いに答えられているかを測る手法です。01章の実験が示した「AIブラウジングツールが読むのは本文のプレーンテキストである」という結果を踏まえると、AIからの理解を高めたいのであれば、構造化データよりも先に、この「本文が実際にどこまでの問いに答えられているか」を測るほうが、直接的な確認になると当サイトでは考えています。

08 このテーマの、これまで

検索品質評価ガイドラインとの接続

本記事02章で触れた「Googleが公式に何を保証し、何を保証していないか」という視点は、以前182ページの検索品質評価ガイドライン本体を読み込み、改訂履歴を時系列で整理した記録（【2026年8月時点】Google検索品質評価ガイドラインの最新版と改訂履歴）とも重なります。ガイドラインが「単一の評価や単一の要因が特定のページの順位に直接影響することはない」と明記している点は、構造化データという単一の施策だけで結果が変わると期待しすぎないという、本記事の立場とも一致します。

「出力は在った。だから誰も測らなかった」という記録との接続

01章の実験が示したのは「構造化データを出力してはいるが、それが実際にAIに読まれているとは限らない」という現実です。これは以前、当サイト自身のdatePublished・og:type・用語ハイライト・sitemapの4項目について、「値は出力されていたが、その値が正しいかを一度も検証していなかった」という状態を機械的に発見した記録（archives/128）と、構造がよく似ています。「出す」ことと「効いているかを測る」ことは別の作業だという教訓は、構造化データにもそのまま当てはまります。

noindexの宿題を一夜で畳んだ記録との接続

05章のチェックリストで「実際にツールを開いて確認する」ことを繰り返し勧めているのは、以前、公開済み記事の8割が検索エンジンに正しく認識されていなかった状態に気づき、一夜で公開状態へ切り替えた記録（archives/98）があるためです。無料のツールで実際に確認する行為そのものが、思い込みに気づく手段になり得ることは、今回のテーマでも変わりません。あわせて、AIクローラー向けのllms.txtという別の施策についても、設置しただけでは効果測定にならないという記録（archives/68）を残しています。「読まれているか」を機械的に確認する姿勢は、施策の種類が変わっても共通です。