RAGでは構造化データが不要なら、AI検索でも不要なのか

「RAGの観点では、構造化データは必要ない」。AI検索対策会社の担当者から、そんな趣旨の返信が届きました。僕が気になったのは、RAGという技術の説明そのものよりも、その話を公開WebサイトのAI検索対策全体へ広げてよいのか、という点でした。

僕は当時、自分の情報サイトで一次情報を増やし、記事同士の関係や著者情報を整理し、検索システムへ内容を伝える構造化データも整えていました。営業企業が提案していたのは、生成AIが企業を紹介するときに自社を推薦・引用してもらうための対策です。ところが、担当者から届いた技術的な説明では、RAGで情報を取得する際の話が中心になっていました。

そもそもRAGとは何をする技術で、構造化データにはどんな役割があるのでしょうか。今回は「必要か不要か」の二択にする前に、話している対象を分けて考えました。

RAGは、外部の資料を参照してAIの回答を作る手法です

RAGはRetrieval-Augmented Generation（検索拡張生成）の略で、生成AIが回答するときに外部から関連資料を探して参照する仕組みです。例えば、質問に関係する文書を検索し、その内容を確認しながら回答を生成する使い方があります。

この方法では、参照したい文章を取得できることが重要です。だからといって、参照先のすべてのページに特定の構造化データが必須というわけではありません。必要なデータ形式や情報の管理方法は、使う検索システムや設計によっても変わります。

ここで注意したいのは、RAGとAI検索を完全に別物として切り離せないことです。検索プラットフォームの2026年の公式ガイドでも、検索のAI機能がRAGや関連する追加検索を使って情報を取得することが説明されています。

公式資料：検索プラットフォーム公式｜生成AI検索向けWebサイト最適化ガイド（2026年7月10日更新）。

構造化データは、Webページの情報を明示するための手掛かりです

構造化データは、ページに書かれている内容を、決まった形式で検索システムなどへ伝えるためのデータです。例えば、記事の著者、企業の情報、商品などを、ページ本文とは別に一定の項目で表せます。

人間が文章を読めることと、検索システムがそのページの意味や情報をどう解釈するかは、同じ問いではありません。構造化データは、後者について明示的な手掛かりを追加する方法の一つです。

ただし、構造化データを付ければ必ず検索結果で目立つ、AIに引用されるというわけではありません。公式ガイドも、構造化データが検索のリッチリザルト表示に役立つ一方で、表示自体は保証されないと説明しています。

公式資料：検索プラットフォーム公式｜構造化データの仕組みと役割。

AI検索専用の特別な構造化データは、Google検索では要求されていません

2026年に公表された検索プラットフォームの生成AI検索ガイドでは、AI検索向けに専用の構造化データや特別なマークアップを追加する必要はないと説明されています。既存のSEOの基本を重視するという方針も明確です。

同時に、この公式ガイドは、従来の構造化データを使い続けることには意味があり、通常検索のリッチリザルトへの対応にも役立つとしています。つまり「AI検索だけの特別な構造化は必須ではない」と「構造化データを全部やめてよい」は別の話です。

これは検索プラットフォームの公開ガイドについて確認できる範囲です。ほかの生成AIサービスすべての内部処理や掲載条件まで、同じ仕様だと断定するものではありません。

公式資料：検索プラットフォーム公式｜生成AI検索に不要な特殊施策と継続すべきSEO、およびAI検索機能とWebサイトの技術要件。

僕が整理したかったのは、「取得」と「情報の整理」の違いです

営業担当者からの説明を受けたとき、僕は「今回のテーマはRAGの仕組みを作ることではなく、AIに引用される企業を作ることだ」と論点を戻しました。

例えば、ある文書の本文をAIが取得できたとしても、その文書が誰の活動について書かれ、どの会社に属する情報で、どの情報が正式な一次資料なのかを、サイト全体として分かりやすく示す課題は残ります。

そこで僕は、一次情報、人物や企業を指すEntity（実体）、記事同士の関係、構造化データなどを一体で整理するという自分のサイト改善の方針を説明しました。これは実際に行っていた情報設計の考え方であり、その全要素が生成AIの推薦確率を高めたと実証した結果ではありません。

具体的には、同じ著者の記事を公式の人物ページへ結び付けるような設計もあります。

Webサイト上の人物の示し方は、AI時代に著者ページを独立させる理由でも扱っています。

「必要ない」は、何に対して必要ないのかを確かめます

今回の会話で混同しやすかったのは三つの違う問いです。第一に、RAGで文書を取得するために特定の構造化データが必須なのか。第二に、検索エンジンがWebページの意味や情報を理解するうえで構造化データに役割があるのか。第三に、構造化データを追加すると自社がAIから引用される回数が増えるのか、という問いです。

第一と第二は技術や用途を分けて考える必要があり、第三には実際の測定が必要です。一つ目の問いで必須ではないと判断できても、残りの問いへ同じ結論を広げることはできません。

僕は担当者への反論文で、RAGによる取得方法の議論と、Web上で企業や情報源を発見・理解しやすくする設計の議論を分けました。本人の記録には、その文章を送ったとの報告がありますが、送信後の画面までは今回確認していません。

今回の議論で確認できたことと、測っていないこと

今回確認できたのは、営業担当者がRAGを根拠として構造化データの必要性を論じ、それに対して僕が論点の違いを指摘したことです。また、公式資料によって、RAGがAI検索の情報取得にも使われること、AI検索専用の特殊な構造化データは要求されていないこと、従来の構造化データにはSEO上の役割があることを確認できました。

一方、僕が自分のサイトで構造化データを追加したことによって、AI検索で引用される回数や推薦順位が何件変化したのかは、この会話では測定されていません。営業企業の手法が無効だったことも、今回の記録では立証されていません。

「RAGだから不要」と結論を急ぐより、何の仕組みで、どんな目的に対して、どこまで確認できた話なのかを分ける。それがこのやり取りから再利用できる知です。

技術的な論点を整理することと、その説明にAIから強い賛同を得ることも別です。AIの高評価を根拠の代わりにしない方法は、AIに「100%正しい」と言われても、その評価は証拠になるのかにまとめています。

このKnowledgeの関連知識

議論の発端：AI検索で推薦されたスクリーンショットは、どこまで成果を証明できるのか。営業企業の推薦画像を検証した一連の背景と、表示事実の読み方です。

Web上で人物を示す具体例：AI時代に著者ページを独立させる理由。本人の活動や記事を、同じ公式人物ページへ結び付ける設計を扱います。

根拠の確認段階：出典URLがあることと、内容を事実確認したことを分ける。技術的な主張が本当に公式資料で裏付けられているかを確かめる方法です。