構造化データは AI 検索に本当に必要か — Schema.org・フィード・API を混同しない

• 最終検証日：2026年8月13日
• Methodology バージョン：2026.08.44（訂正）
• 本文中の「2026.08.xx」：その訂正を行った判断基準の版の番号です。公開した版は書き換えず、訂正は新しい版として残しています
• 位置づけ：SILVE の操作モデル。業界標準の分類ではありません
• 関連記事：7 段階の整理 / 測定の 4 レイヤー / エージェント対応
• 難易度：実務（構造化データをどう扱うかの話です）

要点

一文で言うと — 「AI には構造化データが重要」は半分正しく、半分不正確です。Google は生成 AI 検索に構造化データは必須ではないと明記しており、AI 専用のマークアップも存在しません。

• それでも通常の SEO の一部として使い続けるのは良い考えだと Google 自身が書いています（リッチリザルトの対象になるため）
• ★ 正しく書いても表示は保証されません。 対象になり得ること（eligibility）と、実際に表示されること（visibility）は別です
• EC では話が変わります。 Merchant Center フィードとビジネスプロフィールは、AI の回答での可視性に役立ち得ると明記されています
• Schema.org ≠ JSON-LD ≠ 商品フィード ≠ API ≠ 取引プロトコル。 一つの数にまとめません

実務では — マークアップの量を増やすのではなく、機械可読な情報の正しさを保ってください。★ SILVE は現在、構造化データの有無を診断項目にしていません。 提供元が「生成 AI 検索の必須条件ではない」と名指ししているためです。ただし無関係でもありません —— 詳しくは本文で書きます。

先に、Google が何と言っているか

AI 検索の解説では「AI は構造化された情報を好む」「Schema.org は GEO 対策として必須」といった説明をよく見ます。

Google の生成 AI 向け最適化ガイドは、「過剰に注目しなくてよいもの」の一覧にこう書いています。

Overfocusing on structured data: Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add. However, it's a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results on Google Search.

生成 AI 検索に構造化データは必須ではなく、AI 専用の schema.org マークアップも存在しません。 ただし通常の SEO の一部として使い続けるのは良い考えである、とも書かれています。

同じ一覧には次もあります。

LLMS.txt files and other "special" markup: You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn't use them. ... Doing so will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them.

"Chunking" content: There's no requirement to break your content into tiny pieces for AI to better understand it.

では構造化データは無意味なのか。そうではありません。 ただし「どの目的で」有用なのかを分けないと話が噛み合いません。

「構造化データ」という言葉が広すぎる

AI 検索の議論では、少なくとも性質の違う 5 つが同じ言葉で呼ばれています。

すべて「機械可読」ですが、同じ技術でも同じ評価シグナルでもありません。

そして 2 と 3 の違いが、この記事で最も重要です。2 はクローラーに読ませるための説明で、3 は事業者がプラットフォームへ直接送るデータです。

Schema.org と JSON-LD も同じではない

Schema.org は語彙（何を表現するか）で、JSON-LD は記述形式（どう書くか）です。同じ語彙は Microdata や RDFa でも書けます。Google は 3 形式を扱い、JSON-LD を推奨形式としています。

したがって「JSON-LD を入れた」だけでは、何を表現したのかが分かりません。 見るべきは型・プロパティ・そして内容の正確性です。

Schema.org は何のためにあるか

Google は構造化データを、ページの意味について明示的な手掛かりを与える標準形式として使い、条件を満たせばリッチリザルトなどの対象になり得ます。

ここで効くのは eligibility（対象になり得ること）であって、表示の保証ではありません。Google は明記しています。

Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly.

正しく書いても表示されるとは限らない。 これは構造化データをどう扱うかを考えるときの出発点です。

「AI が理解する」と「AI 検索で有利になる」を分ける

Google は構造化データをページや世界の理解に使うと説明しています。しかし「構造化データを追加すると AI Overviews で引用される確率が上がる」という因果は示していません。

SILVE はこの 2 つを分けます。機械の理解に使われることと、生成 AI での露出が増えることは別の主張です。

「LLM は JSON が得意だから JSON-LD が有利」は根拠にならない

LLM が JSON 形式を扱えることと、Google 検索や ChatGPT 検索が Web 上の JSON-LD をランキングシグナルとして優遇することは別問題です。前者から後者は導けません。SILVE はこの種の推論を因果の根拠として採用しません。

構造化データは本文の代わりにならない

ページ本文に価格を書かず、JSON-LD にだけ "price": "9800" を入れる——これは「AI 用に情報を置いた」ことになりません。

Google のガイドラインは明確です。

• 読者に見えないコンテンツをマークアップしない
• マークアップはページ内容の真の表現でなければならない
• ユーザーを欺いたり誤解させたりする目的で使わない
• ページの実際の主題に関連していなければならない
• 古くなった時間依存の情報にはリッチリザルトを表示しない

つまり構造化データは本文の代替ではなく、本文についての機械可読な説明です。

「あるか」より「正しいか」

本文が「在庫なし」なのに Product 構造化データが "availability": "InStock" になっている。これは機械可読である以前にデータの整合が壊れています。

したがって診断で見るべきは、スキーマがあるかよりスキーマが正しいかです。

量を競わない

プロパティを 100 個入れれば 50 個より AI に強い、という根拠はありません。意味のないプロパティ数ではなく、事業上重要で事実確認できる属性を見ます。

EC では話が変わる

ここからが本題です。一般のコンテンツサイトと EC では、機械可読データの位置づけが根本的に違います。

Google は生成 AI 向けガイドの中で、ローカルビジネスと EC について次のように述べています。

Using products like Merchant Center (such as Merchant Center feeds) and Google Business Profiles can help your products and services to be visible in both AI responses and other Google Search results.

これは構造化データについての記述とは対照的です。 構造化データは「生成 AI 検索に必須ではない」とされる一方、Merchant Center フィードと Google ビジネスプロフィールは AI の回答での可視性に役立ち得ると明記されています。

フィードの利点は鮮度

Google は商品データを渡す経路として、ページ上の Product 構造化データと Merchant Center へ直接送るフィードを区別しています。そして更新のタイミングについてこう述べています。

Feeds can be used for weekly, daily, or even hourly updates, at your time of choice.

一方クロールについては、

Google does not guarantee how long it takes before changes on your site will be processed through crawling.

価格・在庫・セールは頻繁に変わります。 クローラーが次に来るまで待つと、プラットフォーム側のデータが古いままになり得ます。

ただし「両方やれば安全」でもない

ここは草稿段階で見落としがちな点です。Google は両方使うことの副作用も書いています。

When Google combines data from your website and Google Merchant Center feeds, it can lead to data inconsistency issues due to lag.

サイトとフィードの両方からデータを取ると、遅延によって不整合が起きうる。 つまり「フィードも入れたから万全」ではなく、両者を一致させ続ける運用が必要になります。

これはランキングの問題ではなく運用の問題

AI が「この商品は 9,800 円で在庫があります」と答えたのに、実際は 12,800 円で在庫切れだった。これは順位の問題ではありません。情報の正確性という運用上の失敗です。

EC では「情報があるか」だけでなく「今も正しいか」が問われます。

OpenAI も構造化された商品フィードを使っている

OpenAI は ChatGPT の商品体験のために、商品フィードを正式な連携経路として提供しています。仕様は「OpenAI が取り込んで索引化する共有のフラットファイルスキーマ」と説明され、目的は正確な価格・在庫・販売者情報とともに適切な商品を提示することとされています。

ただし誰でもすぐ接続できるわけではありません（2026.08.43 で追記）。 OpenAI の導入ガイドは「Onboarding product feeds in ChatGPT is currently available to approved partners.」と明記しており、2026 年 8 月時点では承認されたパートナー向けのオンボーディングです。申請フォームから応募する形になります。

仕様に合わせてフィードを作れば即座に接続できる、と読まないでください。 ここは事業者側で整えられる準備状態と、プラットフォーム側が決める参加資格の境目です。

Google 互換の商品データ形式にも対応しており、互換プロファイルでは各行に次を要求します。

id / title / description / link / image_link / availability / price / brand

さらに identifier_exists を省略するか yes にする場合は、有効な gtin または mpn が必要です。本当に識別子を持たない商品のときだけ no にします。

ここまで来ると、SEO のマークアップというより商品カタログの基盤です。 ページに JSON-LD を貼る話ではなく、事業者がプラットフォームへカタログを提供する連携です。

更新の運用まで提供元が示している

OpenAI は提供方法についてこう案内しています。

It is generally recommended to provide the entire feed once a day via file upload, and then send updates throughout the day via the API.

If your feed is small, you can provide both the entire feed and regular updates via the API.

全件は日次でファイル、日中の差分は API。 これは層 3（フィード）と層 4（API）が役割分担する具体例です。

なお「Fresh before rich」は SILVE の原則の名前であって、OpenAI の表現ではありません（2026.08.43 で帰属を明確化）。 ここで言えるのは、この運用が SILVE の原則と整合しているということです。

そして層 4 の実装先は動きます。 Google では Content API for Shopping が 2026 年 8 月 18 日に終了し、Merchant API が後継になります（公式のリリースノートと Google Ads Scripts の Advanced APIs の両方に「Content API for Shopping will be sunset on August 18, 2026.」とあります。リリースノートには延長申請のフォームも案内されています）。古い記事や社内手順が Content API を前提にしていないか確認してください。

Schema.org とフィードを同じ点数にしてはいけない

EC サイト A は Product 構造化データがあり、フィードは無く、在庫データの更新は月 1 回。EC サイト B は構造化データもフィードもあり、価格と在庫を高頻度で更新している。

「Product 構造化データあり = 10 点」で同じ評価にするのは粗すぎます。 エージェントが実際に商品を扱う段階では、B のほうが運用上準備できている可能性が高いからです。

5 層と 7 段階の対応

前提記事の 7 段階と組み合わせると、どの層がどこで効くのかが見えます。

これは SILVE の操作上の対応づけであり、各プラットフォームのランキング構造そのものではありません。

面白いのは、行動に近づくほど機械可読性が重く効くこと

一般的な AI 検索では、完全な構造化データは必須ではありません。しかし AI が比較し、選び、在庫を確認し、購入する段階へ進むほど、機械可読なデータの重要性が上がります。

行動には曖昧さが許されないからです。

「おすすめのランニングシューズを教えて」なら、多少曖昧な本文からでも回答は組み立てられます。しかし「黒・27cm・在庫あり・2 万円以下のものを買って」となると、商品識別・色・サイズ・価格・在庫が機械可読かつ最新でなければ成立しません。

OpenAI の商品フィードもこの環境と整合していますが、「識別子・バリエーション・価格・在庫がすべて必須」ではありません（2026.08.43 で精密化）。 経路によって扱いが違います。

「必須級」という言い方は、必須と推奨と条件付き必須を潰してしまいます。 この記事の主題が「仕様を混同しない」である以上、ここは分けて書きます。

SILVE は現在どう扱っているか

構造化データは、SILVE の診断項目にありません。

Google の生成 AI 最適化ガイドが、「構造化データは生成 AI 検索の必須条件ではない」と名指しで述べているためです。同じ節に「llms.txt は不要」「AI 向けの書き直しは不要」 「コンテンツの細切れ化は不要」も並んでいます。

では無関係かというと、そうではありません。 同じ提供元が、別の資料でこう書いています。

max-snippet による量的制限は、publisher が別途利用を許諾している場合には適用されない。 たとえば publisher が in-page structured data の形でコンテンツを提供している場合、 または Google とライセンス契約がある場合。

Google が構造化データと AI 機能を直接結んでいる、唯一の明示的な記述です。 「必須ではない」と「固有の効き方をする」は、両立します。

SILVE が診断項目にしていない理由

SILVE の診断項目には、2 つの入場条件があります。

1. これが欠けていると、機械に何が伝わらなくなるかを 1 文で言えること
2. 何個中何個で数えられる実体があること

構造化データの「有無」は、1 つ目を満たしません。 「Organization スキーマが無いと組織が特定できない」とは、一次資料から言えません。 Google は組織の理解にページの内容そのものも使うと述べています。

一方、2 つ目を満たす形はあります —— 「構造化データが、本文に見えているテキストと一致しているか」。 Google は AI 機能の資料で「構造化データは本文と一致させること」と明記し、 構造化データの入門資料でも「利用者に見えていない情報を構造化データに入れてはならない」 と書いています。

これは有無ではなく一致を測るので、そのサイトに実在する構造化データの数が分母になります。 SILVE は現在これを候補として置いており、判定には使っていません。 検出器を作るときの誤検出（日付の表記形式の違いなど）を、まだ詰められていないためです。

なお SILVE は総合スコアそのものを出しません。 単位の違うもの（クローラー・ページ・画像）を 1 つの数にまとめるには変換率が要り、その変換率に根拠が無いためです。 詳しくは AI 検索の成果はどう測るか を読んでください。

事業別に何を優先するか

一般企業（BtoB） — まず Organization 情報・サービス内容・価格・対象者・事例・運営者情報・問い合わせ経路が本文で明確であること。Schema.org を追加するならページ内容と一致した適切な型を使う。ただし Organization スキーマを完璧にすることを最重要施策とは扱いません。

メディア — Article・著者・日付・Organization・パンくずが自然な候補。ただし Article スキーマがあることより、記事自体に一次情報と正確な出典があることを優先します。 Google も生成 AI 検索では、他サイトの要約ではない独自性のあるコンテンツを重視するよう案内しています。

EC — 優先度が上がります。Product / Offer / 価格 / 在庫 / バリエーションの適切な構造化データ、Merchant Center のデータ、価格と在庫の更新頻度、GTIN / MPN / ブランドなどの識別情報。事業上妥当なら ChatGPT の商品フィードも検討対象です。

ローカルビジネス — LocalBusiness スキーマを書いて終わりではありません。Google ビジネスプロフィールのようなプラットフォーム側のデータを正確に保つことが別の準備状況として存在します。

構造化データを消すべきか

いいえ。 正しく使われている構造化データを「AI 検索に必須ではないから」という理由で削除する必要はありません。Google は現在もリッチリザルト等に使っています。

重要なのは、万能な GEO ハックとして過大評価しないことです。

リッチリザルトの成功事例を AI 検索の効果に流用しない

Google は構造化データを導入したサイトのリッチリザルト経由の改善事例を紹介しています。しかしそれはリッチリザルトの成果です。 そこから「構造化データで ChatGPT の引用が増える」とは言えません。測定のレイヤーが違います。

4 つの原則

1. Correct before complete — 大量にプロパティを足すより、まず正確であること
2. Visible content first — スキーマだけに重要情報を隠さない
3. Platform-specific data when appropriate — EC ならフィード等を検討する
4. Fresh before rich（行動に近い領域） — 価格・在庫など行動に近い情報ほど更新性を重視する

まとめ

• 「AI には構造化データが重要」は、半分正しく半分不正確です
• Google は生成 AI 検索に構造化データは必須ではないと明記しています。 AI 専用のマークアップも存在しません
• しかし通常の SEO の一部として使い続けるのは良い考えだとも書いています。 リッチリザルトの対象になるためです
• 正しく書いても表示は保証されません。 eligibility と visibility は別です
• EC では話が変わります。 Google は Merchant Center フィードとビジネスプロフィールが AI の回答での可視性に役立ち得ると明記しています
• フィードの利点は鮮度です。 ただしサイトとフィードの併用は遅延による不整合を生み得ます
• Schema.org ≠ JSON-LD ≠ 商品フィード ≠ API ≠ 取引プロトコル。 一つの数にまとめません
• SILVE は構造化データの有無を診断項目にしていません。 提供元が「生成 AI 検索の必須条件ではない」と明記しているためです。ただし max-snippet の量的制限が in-page structured data に適用されないという記述はあり、無関係ではありません

最終的に問われるのは、マークアップがあるかではありません。機械が必要な情報を、正確に、最新の状態で、適切な経路から利用できるかです。

評価すべきなのは構造化データの量ではなく、機械可読な情報の正しさです。

次に読む

• エンティティとは何か — 構造化データで何を宣言するのか
• 取得と引用を分ける — 書いたものがどう使われるか

Framework Record

この記事の判断を、あとから検証できる形で記録したものです。本文の結論（Core Rules）と、SILVE が内部で持つ記録の項目、参照した一次資料が入っています。

Framework Name: Machine-readable Data Readiness Version: Methodology 2026.08.184 Status: SILVE Operational Model（業界標準ではない） Last Verified: 2026-08-20 実装: 診断項目にはありません。「構造化データが本文と一致しているか」を候補として置いていますが、判定には使っていません

Layers

層	目的	現在の扱い
1. Semantic Web Structure	文書と UI の意味構造	エージェント対応カテゴリで評価
2. Page Structured Data	エンティティと内容の明示	診断項目にしていない（有無は測らない。本文との一致は候補）
3. Platform Data Feed	プラットフォームへの直接提供	未実装（公開サイトから判定できない）
4. Data API	機械的な取得・更新	未実装
5. 能力（Capability） / Interaction Protocol	capability の提示・商品探索・操作・取引	未実装 / 別カテゴリ

Core Rules

1. 構造化データを生成 AI 検索の直接的な順位要因として扱う根拠は確認できていない（「順位要因ではないと証明された」ではない。2026.08.43 で表現を訂正）
2. Schema.org ≠ JSON-LD（語彙と記述形式）
3. Schema.org ≠ Product Feed（クローラー向けの説明と、プラットフォームへの直接提供）
4. Product Feed ≠ API ≠ Interaction Protocol（プロトコルの射程は取引だけとは限らない）
5. Eligibility ≠ 可視性
6. Machine-readable ≠ correct
7. 公開サイトから判定できないものは推測せず「観測できない」と表示する
8. 事業に不要なデータ経路が無いことを減点しない

Operational Principles

Correct before complete. そしてコマース・エージェント用途では Fresh before rich.

一次資料

• Google Search Central — Google's Guide to Optimizing for Generative AI Features on Google Search https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
• Google Search Central — General Structured Data Guidelines https://developers.google.com/search/docs/appearance/structured-data/sd-policies
• Google Search Central — Share your product data with Google https://developers.google.com/search/docs/specialty/ecommerce/share-your-product-data-with-google
• OpenAI Developers — Products（Agentic Commerce 商品フィード仕様） https://developers.openai.com/commerce/specs/file-upload/products
• OpenAI Developers — Product feeds https://developers.openai.com/commerce/specs