AI検索に「この会社の設立年は?」と質問したとき、正確に答えてもらえるかどうかは、コンテンツの書き方だけでなく、データの「渡し方」にも左右されます。
自然言語の文章に「弊社は2005年に設立されました」と書くのと、JSON-LDで "foundingDate": "2005" と記述するのとでは、AIの読み取り精度が異なります。
後者のような機械可読な形式が「構造化データ」です。
この記事では、構造化データがAI検索での引用にどう影響するのか、どの構造化データから実装すべきかを、研究データと実装手順をもとに解説します。
AIが「構造」を理解する仕組み——知識グラフの基本
構造化データの効果を理解するために、まず知識グラフという仕組みを押さえておきます。
知識グラフは、現実世界の事物(エンティティ)とその関係をグラフ構造で整理したデータベースです。 「東京 → 首都である → 日本」のように、主語・述語・目的語の三つ組(トリプル)で情報を表現します(Hogan et al., 2021, ACM Computing Surveys)。
2012年にGoogleのAmit Singhalが「Things, not strings(文字列ではなく、事物を理解する)」というコンセプトでGoogle Knowledge Graphを導入しました。 検索クエリに含まれる単語を単なる文字列ではなく、実世界のエンティティとして認識する仕組みです。 その基盤の一つがFreebase(Bollacker et al., 2008)で、データはWikidataに引き継がれ、現在も1億以上のエンティティが公開されています。
AIは知識グラフ的な知識をどの程度持っているか
Petroni et al.(2019年、Facebook AI Research)は「Language Models as Knowledge Bases?」という研究で、LLMが知識グラフに格納されているような事実をどの程度再現できるかを検証しました。
「ダンテは[空欄]で生まれた」という穴埋め形式の質問に対して、AIが「フィレンツェ」と正しく答えられるかをテストしています。
結果の概要は以下のとおりです。
| 関係のタイプ | AIの再現精度 |
|---|---|
| 「Xの首都はY」のような1対1の関係 | 高い |
| 「Xの言語はY」のような1対1の関係 | 高い |
| 「Xは Yに所属する」のようなN対Nの関係 | 低い |
| 出現頻度の低いエンティティの情報 | 低い |
つまり、AIは有名な事実はかなり正確に覚えていますが、複雑な関係やマイナーな情報は精度が落ちます。 ここに、構造化データで明示的に情報を伝える価値があります。
構造化データがAI検索の引用率に影響する理由
AI検索システムがWebページから情報を取り出す経路は2つあります。
- 自然言語テキストを読んでAIが情報を推定する
- JSON-LDなどの構造化データを直接パース(構文解析)する
前者は文脈に依存するため、同じ情報でも文章の書き方によって読み取り精度が変わります。 後者は機械可読な形式で記述されているため、パースの精度が安定しています。
エンティティの同一性を解決する
「Apple」が果物なのかテクノロジー企業なのか、文脈から判定する必要がある場面があります。
Schema.orgの sameAs プロパティを使えば、自社のWebページのエンティティがWikidataやWikipediaのどのエンティティと同一かを明示できます。
{
"@type": "Organization",
"name": "自社名",
"sameAs": [
"https://www.wikidata.org/wiki/Qxxxxxx",
"https://ja.wikipedia.org/wiki/自社名"
]
}
これにより、AI検索が自社を知識グラフ内の正しいエンティティに紐づける精度が上がります。
引用元としての選ばれやすさ
AI検索が回答を生成する際、引用元としてどのページを選ぶかは、そのページからどれだけ正確に情報を取り出せるかに影響されます。 構造化データが実装されたページは情報抽出の精度が高いため、引用元として選ばれやすくなる可能性があります。
実装すべきSchema.orgの優先順位
Schema.orgには800以上のデータ型がありますが、すべてを一度に実装する必要はありません。 マーケティングサイトで効果が高いものから順に実装するのが現実的です。
最優先(工数目安: 1〜2営業日)
Organization / LocalBusiness
企業の基本情報(所在地、連絡先、設立年、従業員数など)を構造化します。 AI検索が「この企業はどこにあるか」「連絡先は」といった質問に正確に回答するための基盤になります。
Article / BlogPosting
記事コンテンツの著者、公開日、更新日、見出し画像を明示します。 AI検索がコンテンツの信頼性と鮮度を判断する手がかりになります。
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "記事タイトル",
"author": {
"@type": "Person",
"name": "著者名"
},
"datePublished": "2025-01-15",
"dateModified": "2025-03-01"
}
BreadcrumbList
サイト構造のナビゲーションを明示します。 AI検索がサイト全体の構造を理解する助けになります。
次に着手(工数目安: 2〜3営業日)
FAQPage
質問と回答のペアを構造化します。 AI検索は質問文をクエリとしてマッチングし、対応する回答を引用する際にFAQPageスキーマを解析できます。
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "質問文",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答文"
}
}]
}
HowTo
手順の説明を構造化します。 各ステップの名前、説明、所要時間、必要な道具を明示できます。
Product / Offer
製品情報(名前、価格、在庫状況、レビュー評価など)を構造化します。 AI検索での製品比較や価格情報の正確な抽出に寄与します。
その後に追加(工数目安: 3〜5営業日)
- Event: イベント情報
- Person: 著者・経営者のプロフィール
- sameAs設定: Wikidata・Wikipedia等との紐づけ
実装後の検証方法
構造化データの実装が正しいかどうかは、以下のツールで検証できます。
- Google Rich Results Test: リッチリザルト対応の検証
- Schema.org Validator: スキーマの構文検証
- Google Search Console: 構造化データのインデックス状況確認
これらはGoogle検索向けのツールですが、構造化データの正確性はAI検索全般に対しても有効です。
知識グラフとLLMの統合が進む方向性
LLMと知識グラフを統合する研究が近年活発化しています。 統合のアプローチは大きく3つあります。
- 知識グラフの情報をLLMの入力や学習に組み込む
- LLMを使って知識グラフの構築・補完を行う
- 双方向に情報をやり取りする
この統合が進むほど、Webページの構造化データがAIの回答精度に直接影響するようになります。 構造化データの実装は、現在のSEOだけでなく、今後のAI検索対応としても投資価値のある施策です。
RAGベースのAI検索において、構造化データは検索・取得フェーズの精度を向上させます。 エンティティと関係が明示されたページは、RAGの検索段階で正確にマッチングされやすくなります。
まとめ
知識グラフと構造化データは、AIがWebコンテンツの「意味」を正確に把握するための基盤です。 Petroni et al.(2019年)の研究が示したとおり、AIは事実知識を暗黙的に保持していますが、その精度にはばらつきがあります。
Schema.orgの構造化データは、AIの暗黙知識を補完し、エンティティ間の関係を明確に伝えます。 初期工数は数営業日で、一度実装すれば継続的に効果を発揮します。
実装のステップは以下のとおりです。
- Organization / Article / BreadcrumbListから着手する(1〜2営業日)
- FAQPage / HowTo / Productを追加する(2〜3営業日)
- sameAsプロパティでWikidata等と紐づける(1〜2営業日)
- Google Rich Results Testで検証する
構造化データの実装は、従来のSEOとGEO対策の両方に効く、投資対効果の高い施策です。