構造化データを作成すればLLMO対策につながるのか？AIに伝わるサイト構造の考え方

LLMO対策について調べていると、よく目にする施策があります。

• Organizationの構造化データを入れる
• Productを設定する
• Articleを設定する
• FAQPageを設定する
• 著者情報をSchema.orgで記述する
• JSON-LDを追加する

これらは、どれも間違った施策ではありません。

むしろ、検索エンジンや機械にページの内容を明確に伝えるという意味では、構造化データは今でも重要です。

問題は、その先です。

構造化データを設定すれば、AIが自社を理解してくれる。 構造化データを増やせば、ChatGPTやGoogleのAI検索で引用されやすくなる。 だからLLMO対策では、まずSchema.orgを整備すればいい。

このように考えてしまうと、LLMO対策の優先順位を間違える可能性があります。

Googleは現在、生成AI検索向けの公式ガイドで、AI OverviewsやAI Modeに表示されるために特別なSchema.orgマークアップは必要ないと明確に説明しています。また、構造化データそのものも生成AI検索への掲載要件ではありません。

一方でGoogleは、構造化データがページ内容を理解し、検索結果上のリッチリザルトなどに活用するための重要な仕組みであるとも説明しています。

つまり、

構造化データは必要ないのではありません。 構造化データだけでは足りないのです。

LLMOinsightで実際の施策とAI回答の変化を継続的に観測している私たちも、この違いは非常に重要だと考えています。

本記事では、

• 構造化データは何のためにあるのか
• GoogleはAI検索と構造化データについて何と言っているのか
• なぜ構造化データだけではLLMO対策にならないのか
• AIが必要としている「情報」とは何なのか
• LLMOinsightの実測からどのような傾向が見えているのか
• 実際にはどの順番でサイトを改善すべきなのか

を整理します。

構造化データとは、Webページに書かれている情報の意味を、検索エンジンなどの機械が理解しやすい形式で記述する仕組みです。

Schema.orgには、企業、商品、記事、人物、レビューなど、さまざまな情報を表現するための語彙が定義されています。

たとえば商品ページに、

• 商品名
• ブランド名
• 価格
• 在庫状況
• レビュー評価

が掲載されていたとします。

人間であればページを見れば、それぞれの意味を理解できます。

一方、機械に対しては、

「この数字は価格です」

「この文字列はブランド名です」

「この数値はレビュー評価です」

と明示した方が理解しやすくなります。

その役割を担うのが構造化データです。

Googleも、構造化データをページ内容を理解するために利用すると説明しています。商品ページであれば、価格、在庫状況、レビューなどがGoogle検索上でより豊かに表示される可能性があります。

つまり構造化データは、

「ページにある情報へ名札を付ける」

ようなものです。

ここが非常に重要です。

名札を付けることはできます。

しかし、箱の中身そのものを増やすことはできません。

LLMO対策で最も注意したいのが、この考え方です。

たとえば、ある商品ページに完璧なProduct構造化データを実装したとします。

{
  "@type": "Product",
  "name": "商品A",
  "brand": "ブランドA",
  "offers": {
    "price": "9800"
  }
}

技術的には適切です。

しかし、ページ上に書かれている内容が、

高品質な商品です。 お客様から高い評価をいただいています。 こだわりの技術で作っています。

だけだったとしたらどうでしょうか。

AIが、

A社とB社ならどちらの品質が高い？

と聞かれた際に、そのページを根拠として使えるでしょうか。

難しいでしょう。

なぜなら、

• 何をもって高品質なのか
• 競合とどこが違うのか
• どのような試験を行ったのか
• 数値としてどれほど優れているのか
• 誰が評価したのか

といった、回答を作るための根拠が存在しないからです。

構造化データを増やしても、存在しない情報まで生み出すことはできません。

構造化データを理解するときは、宅配便をイメージすると分かりやすいかもしれません。

箱に、

精密機器 食品 冷蔵 取扱注意

というラベルを貼れば、箱の中身を適切に扱いやすくなります。

しかし、

空の箱に「高品質」「専門家監修」「比較データ」とラベルを貼っても、中身は空のままです。

LLMO対策でも同じです。

重要なのは、先に中身を用意することです。

たとえば、

• 自社で取得した実測データ
• 他社との比較結果
• 正式な料金
• 商品仕様
• 導入実績
• 調査条件
• 専門家の見解
• 利用者レビュー
• 独自調査
• 成功事例
• 失敗事例

などです。

こうした情報が存在して初めて、

これはProductです これはArticleです これはOrganizationです これはPersonです これはDatasetです

と構造化データで意味を補強する価値が生まれます。

ここは非常に重要です。

Googleは生成AI検索向けの公式ガイドで、サイト運営者が避けるべき考え方の一つとして、構造化データへの過度な集中を挙げています。

Googleによれば、生成AI検索に表示されるために構造化データは必須ではなく、特別なSchema.orgマークアップを追加する必要もありません。一方で、通常のSEO施策として構造化データを利用し続けることには意味があり、リッチリザルトへの適格性などに役立つと説明しています。

つまり、

Schemaを実装すればAI Overviewsに出る

という単純な関係ではありません。

GoogleのAI機能についても、従来の検索における基本的なSEOベストプラクティスが引き続き重要とされています。AI専用の新しい技術要件が用意されているわけではありません。

これはLLMO対策を考えるうえで、かなり重要なポイントです。

これも誤解されがちです。

Schema.orgには非常に多くのタイプとプロパティがあります。

だからといって、

設定できるSchemaは全部設定しよう

と考える必要はありません。

Googleの構造化データガイドラインでは、構造化データとして記述する内容と、ユーザーが実際にページ上で確認できる内容が一致していることが重要とされています。構造化データが技術的に正しくても、内容や品質に問題があればリッチリザルトとして表示されない可能性があります。

つまり、

マークアップの量ではなく、ページの実態との整合性が重要です。

これはLLMOでも同じように考えるべきです。

これも別の話として整理する必要があります。

構造化データの大きな用途の一つが、Google検索におけるリッチリザルトです。

Productであれば価格や在庫情報、Articleであればタイトルや画像、日付などが検索結果で利用される可能性があります。

これは非常に有用です。

しかし、

リッチリザルトへの適格性と、生成AI回答で推薦・引用されることは同じではありません。

検索結果上でページの情報を豊かに表示する仕組みと、

どの会社をおすすめすべきか どの商品がこのユーザーに合うか どの情報を回答の根拠にすべきか

というAI回答生成の判断は、分けて考える必要があります。

構造化データは後者を支える可能性はあります。

しかし、構造化データを入れたことだけで、その判断に必要な材料が増えるわけではありません。

LLMOinsightでは、単に現在のAIスコアを見るだけではなく、実施した施策を登録し、その後のAI回答の変化を継続的に観測しています。

たとえば、

• 比較表を追加した
• FAQを追加した
• レビューを追加した
• 導入事例を公開した
• プレスリリースを配信した
• 独自調査を公開した
• 商品の訴求内容を変更した

といった施策です。

これまでの観測では、業界や質問による差はあるものの、

比較表、FAQ、レビュー、プレスリリース、一次情報などを追加した後にAIスコアや回答内容へ変化が見られるケースがあります。

ここで興味深いのは、これらの多くが、

「構造化データを増やした施策」ではなく、「AIが使える情報そのものを増やした施策」

だということです。

もちろん、この観測だけから、

構造化データには効果がない

と結論付けることはできません。

AI回答には揺らぎがあります。

検索結果も変化します。

競合企業もコンテンツを更新します。

そのため、構造化データ単独の効果を完全に切り分けることは簡単ではありません。

しかし少なくとも、

「構造化データだけ追加すればLLMO対策は完了する」と考えられるだけの根拠は、現在の観測からはありません。

むしろ重要なのは、

AIがその企業について回答するときに必要な情報が、サイト上に存在するか

です。

たとえば、

A社とB社の違いを教えて

という質問で、自社がAI回答に出てこなかったとします。

そこで比較表を追加します。

改善前

これでは、ほとんど根拠になりません。

改善後

さらに、

• 比較条件
• データ取得日
• 調査方法
• 情報源

まで掲載する。

こちらの方が、AIが比較回答を作る材料として利用しやすくなります。

そのうえで適切な構造化データを実装する。

この順番です。

ここまで読むと、

では構造化データはやらなくていいのか？

と思われるかもしれません。

そうではありません。

中身を整えた後の構造化データは、積極的に実装すべきです。

特に次のような情報は、機械に意味を明確に伝える価値があります。

Organization

企業名、ロゴ、URL、連絡先など、組織に関する情報です。

企業というエンティティを明確に伝えるための基本情報として整理しておきたい項目です。GoogleもOrganization構造化データを公式にサポートしています。

Product

商品名、ブランド、価格、在庫、レビューなどを記述できます。

ECや商品比較が重要な業界では特に有効です。Google検索でもProduct構造化データを使った検索体験が提供されています。

Article

記事のタイトル、著者、公開日、更新日、画像などを明確にできます。

特に専門記事や調査記事では、

誰が書いたのか

をページ上の情報と合わせて整理しておくことが重要です。

Review / AggregateRating

実際にレビュー情報が存在する場合、その内容を機械が理解しやすい形式で表現できます。

ただし、構造化データは実際のページ内容と一致している必要があります。

Dataset

独自調査や統計データを公開する企業では非常に興味深いタイプです。

GoogleはDataset構造化データなどのメタデータを、データセットの発見性を高めるために利用しています。

LLMO対策で一次情報を増やしていくのであれば、独自調査ページとDatasetの組み合わせは検討する価値があります。

構造化データから施策を考えると、

Productを入れよう FAQを入れよう Articleを入れよう

という発想になりがちです。

しかし、本来は逆です。

まずAI回答を確認します。

たとえば、

おすすめのLLMO対策ツールを教えて

という質問に対してAIが、

• 料金
• 対応AI
• 計測方法
• 導入実績
• サポート
• 分析機能

で比較しているとします。

その場合、確認するべきなのは、

自社サイトに、その6項目の根拠となる情報が存在するか

です。

不足していれば追加する。

その情報を適切なページへ配置する。

その後で、必要に応じて構造化データを設定します。

Schemaからコンテンツを逆算するのではありません。

AIが必要としている情報からページを逆算します。

構造化データを追加する前に、まず次の項目を確認することをおすすめします。

1．AIは自社を正しく認識しているか

企業名、商品名、サービス内容などに誤認がないか確認します。

2．AIが比較に使っている評価軸は何か

価格なのか、品質なのか、実績なのか。

AI回答そのものを確認します。

3．その評価軸の根拠が自社サイトに存在するか

「高品質です」と書くだけではなく、それを裏付ける情報が必要です。

4．競合には何があり、自社には何がないか

比較表、料金、レビュー、導入実績、専門家情報など、情報差を確認します。

5．一次情報を増やせないか

独自調査、利用データ、テスト結果、顧客事例など、他社がコピーできない情報を検討します。

6．情報同士の関係がページ上で分かりやすいか

本文、見出し、表、リンク構造などを整理します。

7．最後に構造化データを設定する

ここでOrganization、Product、Articleなどを利用して、すでに存在する情報の意味を機械へ明確に伝えます。

もう一つ重要なのが、実装後の計測です。

構造化データを追加した場合も、

実装しました。完了。

では意味がありません。

LLMOinsightでは、構造化データの追加も一つの施策として登録し、その後のAI回答を継続的に確認することができます。

たとえば、

8月1日

Product構造化データを改善

↓

8月5日

商品情報ページをクロール

↓

8月8日

同じベンチマーク質問を計測

↓

8月15日

再計測

という形です。

その間に、

• 登場率
• 推薦順位
• AIスコア
• 引用ページ
• 商品説明
• 誤情報

がどう変化したか確認します。

重要なのは、

「理論上効きそう」ではなく、「実際に回答が変わったか」

です。

LLMO対策では、

技術施策とコンテンツ施策を別々に考えすぎないこと

も重要です。

たとえばArticle構造化データを正しく設定しても、

• 著者プロフィールが存在しない
• 誰が監修したのか分からない
• 更新日だけ新しく内容は古い
• 情報源がない
• 独自の見解がない

のであれば、マークアップだけ充実している状態になります。

反対に、非常に価値のある独自調査を公開していても、

• タイトル構造が分かりにくい
• 著者情報がない
• 調査条件が曖昧
• ページ同士の関係が分からない
• クロールしにくい
• 構造化データもない

のであれば、情報の価値を十分に伝え切れていない可能性があります。

理想は、

良い情報 × 分かりやすいページ構造 × 適切な構造化データ

です。

どれか一つだけではありません。

ここまでを整理すると、LLMO対策における優先順位は次のようになります。

STEP1：AI回答を分析する

自社、競合、評価軸、引用元を確認します。

STEP2：不足情報を特定する

AIが回答するために必要なのに、自社サイトにない情報を探します。

STEP3：情報を作る

比較、料金、一次データ、事例、レビュー、FAQなどを追加します。

STEP4：ページを整理する

見出し、表、内部リンク、ページ構成などを改善します。

STEP5：構造化データを設定する

情報の意味を機械へ明確に伝えます。

STEP6：施策として登録する

何を、いつ、なぜ変更したか記録します。

STEP7：同じ質問を継続計測する

AI回答が本当に変わったか確認します。

この一連の流れが、LLMOinsightが考えるLLMO改善の基本です。

答えは、

いいえ。構造化データは重要ですが、それだけではLLMO対策として十分ではありません。

Google自身も、生成AI検索に表示されるために構造化データは必須ではなく、AI向けの特別なSchema.orgマークアップも必要ないと説明しています。

一方で、構造化データはページ内容を機械が理解するうえで有用であり、検索結果上のさまざまな機能にも利用されています。

したがって、

「構造化データは意味がない」

も間違いです。

正しくは、

構造化データは、価値のある情報を機械へ正しく伝えるための手段であり、価値のある情報そのものを作る施策ではない。

ということです。

空の箱にラベルを付けても、中身は増えません。

まず、

• 独自データ
• 比較
• 正式な商品情報
• 導入実績
• 専門家の知見
• レビュー
• 調査結果
• 事例

など、AIが引用する理由になる情報を作る。

次に、その情報を人間にも機械にも理解しやすく整理する。

そして構造化データによって意味を補強する。

最後に、実施した施策を記録し、AI回答が実際に変わったか計測する。

この順番が重要です。

LLMO対策は、

Schema.orgの項目を埋める作業ではありません。

AIが自社について回答するときに、

「この会社を挙げる理由がある」 「このページを引用する理由がある」

という状態を作ることです。

構造化データは、その状態を機械へ伝えるための重要な補助線です。

しかし、主役はあくまで情報そのものです。

次回は、LLMO対策で非常によく実施されている施策を検証します。

「FAQを追加すればAI引用率は上がる」は本当か？

FAQは、AIが質問と回答の関係を理解しやすいコンテンツ形式です。

しかし、

FAQを20個追加する FAQPageの構造化データを設定する

だけで、AIからの引用が増えるのでしょうか。

LLMOinsightで実際にFAQ施策を登録した際のAI回答変化も踏まえながら、

「効果のあるFAQ」と「追加してもほとんど意味のないFAQ」の違い

を検証します。

LLMO対策でよく語られる施策を、公式情報とLLMOinsightの実測・検証をもとに一つずつ整理しています。

1. 【第1回】SEO記事を増やせばLLMO対策になるのか？SEO記事を増やす前に見るべきこと
2. 【第2回】構造化データを作成すればLLMO対策につながるのか？AIに伝わるサイト構造の考え方（本記事）
3. 【第3回】FAQを追加すればAI引用率は上がる？LLMO対策で効果のあるFAQ・ないFAQの違い
4. 【第4回】プレスリリースはAI検索に効果があるのか？LLMO対策で「企業の一次情報」が重要な理由
5. 【第5回】口コミを増やせばAI評価も上がるのか？LLMO対策でレビューをどう考えるべきか
6. 【第6回】LLMO対策で「これだけやればいい」は本当か？5つの検証から見えた施策の優先順位