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

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

先に、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 は現在どう採点しているか — そして、19% を 8% へ下げた話

この記事を書くために一次資料を検証した結果、自分の配点が根拠に対して重すぎることが分かりました。 隠さずに書きます。

配点対象の合計は 20 → 7。実効重みは 104 → 91。全体に占める割合は約 19% → 約 8% になりました。

なぜ下げたのか

Google が挙げている構造化データの有用性は、通常の検索でのリッチリザルトの対象化です。生成 AI 検索には必須ではないと明記されています。

SILVE はこれを最初から evidenceDirectness: supporting として記録していました。「資料を引いている」ことと「その資料がこの項目を検証している」ことを分ける仕組みです。

しかし supporting な根拠しか持たない項目群が、スコアの約 1/5 を決めていました。 これは説明できません。

とくに structured_data.organization の 8 点は「ブランドを実体として認識させる起点」という理由づけでしたが、Organization スキーマを入れればブランドが実体として確立される、という根拠は確認できていません。 ここが最大の過大評価でした。

なぜ 0 にしないのか

同じ資料が「通常の SEO の一部として使い続けるのは良い考え」とも述べているからです。0 にするのは根拠の読み違いで、方向が逆に振れるだけです。

現在の位置づけは「AI 検索のための必須項目」ではなく、Google 検索での機械的理解とリッチリザルト対象化の基盤の一部です。

スコアが動いた分は「サイトの変化」ではありません

配点を変えると、サイトを何も変えていないのにスコアが動きます。 SILVE はこれを分解して表示します。

実走（cybozu.co.jp）では 38 点 → 42 点。構造化データの評価が低いサイトなので、その重みが下がった分だけ上がりました。

前回比 +4点（うちサイト側の変化 +0点 / 評価基準の更新による影響 +4点）

この版は構造化データ 4 項目の重みだけを変えており、検出ロジックも他項目の重みも変えていません。分解が siteDelta = 0 になることは確認済みです。

基準を変えた側が、その影響を自分で説明できないなら、基準を変える資格がありません。

採点していないもの

フィードは別の項目にするべきで、推測してはいけない

Merchant Center や OpenAI の商品フィードへの対応は、Schema.org の項目の一部にしません。 別の「プラットフォームデータの準備状況」として持つほうが正確です。

そして重要な制約があります。公開サイトを見るだけでは、フィード連携をしているかどうか判定できない場合があります。 その場合は推測せず、「観測できない」と表示します。 未実装のまま置いているのはこのためです。

商品フィードがないことを減点しない

フィードは有用ですが、事業の種類に依存します。 メディアサイトに商品フィードが無いことを減点するのは不合理です。BtoB のコンサルティング会社も同様です。

機械可読の準備状況は「その事業に必要なデータ経路があるか」で評価します。

事業別に何を優先するか

一般企業（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 は構造化データへの配点を約 19% から約 8% へ下げました。 この記事を書くための検証が、自分の基準へ跳ね返った結果です

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

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

Framework Record

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

Framework Name: Machine-readable Data Readiness Version: Methodology 2026.08.44 Status: SILVE Operational Model（業界標準ではない） Last Verified: 2026-08-13 実装: src/lib/metrics/structured-data.ts（5 項目 / 配点対象 4 項目 / 実効重み 7。改定前は 20）

Layers

層	目的	現在の扱い
1. Semantic Web Structure	文書と UI の意味構造	エージェント対応カテゴリで評価
2. Page Structured Data	エンティティと内容の明示	配点対象（7 / 91、改定前は 20 / 104）
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