この記事の要点：
- RAG（Retrieval-Augmented Generation、検索拡張生成）とは、質問に関係する文書を先に探し、その内容を質問と一緒にLLMへ渡して回答を作らせる仕組みです。2020年の論文で提案されました。
- 流れは「準備（文書を小さな塊に分けて検索できるようにする）」と「回答（探す→渡す→生成する）」の2段階です。誤りは、探す・渡す・読む・元の文書のどこでも起こりえます。
- 新しい情報や社内の情報を、モデルを作り直さずに使えるのが利点です。言葉づかいや出力の形を身につけさせたい場合は、ファインチューニングのほうが向いています。
- GoogleのAIによる概要やChatGPTの検索など、AI検索の多くは「検索してから答える」という同じ考え方で動いています。サイトにとっては、検索で見つかり、一部だけを切り出しても意味が通る書き方が大切になります。
- 自社でRAGを使うときは、資料の整理と権限の設定を先に行い、実際の質問セットで「正しい資料が見つかるか」と「回答が資料に沿っているか」を分けて点検します。
RAGとは：探してから答えるLLMの使い方
RAGとは、LLM（大規模言語モデル）に質問するときに、まず外部の文書から関係する部分を検索し、その部分を根拠として渡したうえで回答を作らせる方法です。日本語では「検索拡張生成」と呼ばれます。
LLMは、学習のときに読んだ文章をもとに答えます。そのため、学習の後に起きた出来事や、公開されていない社内の資料については、そのままでは正しく答えられません。RAGは、答える直前に必要な情報を探して渡すことで、この弱点を補います。
例：社員が「育児休業はいつから申請できますか」と聞いたとき、RAGを組み込んだ社内の質問窓口は、まず就業規則や手続きの案内から関係する箇所を探します。見つかった条文を質問と一緒にLLMへ渡し、LLMはその条文をもとに答えを書き、どの資料のどこを使ったかを添えます。モデルそのものは何も学び直していません。
考え方は、2020年にLewisらが発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で示されました。今では、特定の論文の手法というより、「検索と生成を組み合わせる仕組み」全般を指す言葉として使われています。LLMそのものの仕組みは「LLMとは」で説明しています。
RAGの仕組み：準備と回答の2段階
RAGは、文書を検索できる状態にしておく「準備」と、質問が来たときの「回答」の2段階で動きます。
準備：文書を検索できる形にする
- 文書を集める：社内の規程、製品の説明書、よくある質問、ウェブページなど、答えの根拠にしたい文書を集めます。
- 小さな塊（チャンク）に分ける：長い文書をそのまま渡すと、関係の薄い部分まで含まれます。そこで、段落や見出しの単位、または決まった長さで区切ります。区切り目で意味が切れないよう、前後を少し重ねることもあります。
- 埋め込み（ベクトル）に変える：それぞれの塊を、意味の近さを計算できる数の並び（埋め込み、ベクトル）に変えます。言い回しが違っても意味が近い文を見つけられるようになります。
- 索引に保存する：ベクトルと元の文章、出典のURLや更新日などの情報を一緒に保存します。保存先はベクトルデータベースなどと呼ばれます。
例：OpenAIのAPIの説明では、ファイルを検索用の保存先に加えると、自動で分割・埋め込み・索引への登録が行われ、分割の長さや重なりも指定できるとされています。分け方の初期値や上限は提供元ごとに違うため、使うサービスの説明で確かめます。
回答：探す・渡す・生成する
- 探す（Retrieval）：質問も同じ方法でベクトルに変え、意味の近い塊を探します。製品の型番のように言葉が完全に一致することが大切な場合に備えて、従来のキーワード検索を組み合わせる方法（ハイブリッド検索）もあります。
- 並べ直す：見つかった候補を、質問との関係の強さで並べ直し（再ランキング）、上位の数件だけを選びます。
- 渡す（Augmentation）：選んだ塊を、質問と指示文と一緒にLLMへ渡します。例：「次の資料だけを根拠に答え、資料に無いことは分からないと答えてください」。
- 生成する（Generation）：LLMが資料を読んで回答を作ります。どの資料を使ったかを出典として添えるサービスも多くあります。
Anthropicは、分割した塊が前後の文脈を失うことで検索に失敗しやすくなる点を取り上げ、塊ごとに文脈の説明を足してから索引に入れる方法（Contextual Retrieval）を公開しています。意味の検索とキーワードの検索、再ランキングを組み合わせる設計も紹介しています。こうした工夫が続いていることからも、RAGの品質は「何をどう探すか」に大きく左右されることが分かります。
RAGでできること・できないこと
RAGは、LLMの誤り（ハルシネーション）を減らす手段としてよく紹介されます。ただし、誤りが無くなるわけではありません。できることと、できないことを分けて理解しておきます。
| できること | 理由 |
|---|---|
| 学習の後に出た情報で答える | 答える時点で文書を探すため、文書を差し替えれば新しい情報を使える |
| 社内の資料など、公開されていない情報で答える | 自社で用意した文書を検索の対象にできる |
| 根拠を示す | 使った文書が分かるので、出典として表示できる |
| モデルを作り直さずに知識を足す | 文書の追加・更新だけで済む |
一方で、誤りは次のどの段階でも起こります。
| 起きる場所 | 例 | 対策の方向 |
|---|---|---|
| 元の文書 | 古い料金表や、内容の食い違う2つの資料が残っている | 文書に更新日と担当を持たせ、古いものを外す |
| 分割 | 表の見出しと数字が別の塊に分かれ、何の数字か分からなくなる | 見出しや表の単位で区切る。塊に文書名や見出しを付けておく |
| 検索 | 質問と言い回しが違い、正しい資料が見つからない。関係の薄い資料が上に来る | キーワード検索との組み合わせ、再ランキング、質問セットでの点検 |
| 生成 | 資料を読み違える、資料に無いことを補って書く | 資料に無いことは答えないよう指示する。出典を表示して人が確かめられるようにする |
つまり、RAGの答えの正しさは、LLMの性能だけでなく、元の文書の質と探し方で決まります。「AIが間違えた」と見えるとき、原因は渡した資料のほうにあることも少なくありません。
ファインチューニング・長い入力との違いと使い分け
ファインチューニングとは、学習済みのLLMに追加のデータで学習させ、モデルそのものの振る舞いを調整することです。RAGが答えるたびに文書を探して渡すのに対し、ファインチューニングはモデルの中身を変えます。LLMに自社の知識を使わせる主な3つの方法を比べると、次のとおりです。
| 方法 | やること | 向いている場面 | 注意点 |
|---|---|---|---|
| RAG | 答えるたびに関係する文書を探して渡す | 情報がよく変わる、文書の量が多い、出典を示したい | 検索の質が答えの質を左右する。文書の整備が必要 |
| ファインチューニング | 追加の学習でモデルそのものを調整する | 決まった文体や出力の形、特定の作業のやり方を身につけさせたい | 情報が変わるたびに学習し直す必要がある。根拠を示しにくい |
| 文書をそのまま入力に入れる | 検索せず、必要な資料を丸ごと質問と一緒に渡す | 資料が少なく、一度に読める量に収まる | 量が増えると入りきらない。毎回すべてを渡すため処理が重くなる |
判断の目安は、「知識を足したいのか、振る舞いを変えたいのか」です。知識を足したいならRAGか、資料が少なければそのまま入力に入れる方法、振る舞いを変えたいならファインチューニングが候補になります。両方を組み合わせることもできます。
AI検索とRAGの関係：検索エンジンが「探す」役を担う
AI検索の多くは、RAGと同じ「探してから答える」流れで動いています。違いは、探す対象が社内の文書ではなく、ウェブ全体の索引だという点です。
| サービス | 公式の説明から分かる「探す」部分 |
|---|---|
| GoogleのAIによる概要・AIモード | Google検索のインデックスから関連する結果を探す。質問を関連する複数の検索に広げて（query fan-out）、より多くのページを探すことがある。参照元になるのは、インデックスに登録され、スニペット付きで表示できるページ |
| ChatGPTの検索 | ウェブを検索し、回答に出典のリンクを付ける。サイトを検索結果に表示するためのクローラーとしてOAI-SearchBotを公開している |
| Claudeのウェブ検索 | ウェブを検索した結果をもとに回答し、出典を示す。検索結果の質を高めるためのクローラーとしてClaude-SearchBotを公開している |
各社とも、内部でどのように分割・検索・並べ替えをしているかの詳細は公開していません。ここで言えるのは、「答えを作る前に探す」という構造がRAGと共通していることまでです。
この構造から、サイトにとって大切な点が2つ見えてきます。1つは、AIの回答の材料になるには、まず「探す」段階で見つかる必要があることです。検索エンジンにインデックスされ、各社の検索用のクローラーに取得されている必要があります。もう1つは、ページは丸ごとではなく、一部分が切り出されて使われうることです。
LLMOとの関係：RAGの各段階で、サイト側ができること
AIの回答で自社の情報が正しく扱われる状態をつくる取り組みをLLMOと呼びます。RAGの流れに沿って考えると、サイト側でできることを段階ごとに整理できます。
| RAGの段階 | サイト側で確かめること |
|---|---|
| 集める（クロール） | Googlebotや各社の検索用のクローラーを止めていないか。表示に必要な内容がHTMLにあるか |
| 分ける・探す | 見出しが内容を表しているか。1つの段落で1つの問いに答えているか。質問に使われる言葉で書いているか |
| 渡す・生成する | 切り出された部分だけで意味が通るか。数字や条件に日付や前提が添えてあるか |
| 出典として示す | 誰が書いた、何についてのページかが分かるか。自社にしかない情報があるか |
中でも見落とされやすいのが「切り出されても意味が通るか」です。前後の文脈に頼った書き方は、一部分だけが渡されると意味が分からなくなります。
例：書き直す前「これは月額で、前述のプランより安くなります。」
例：書き直した後「サービスAのライトプランは月額で使えるプランで、スタンダードプランより月額が低く設定されています（2026年10月時点）。」
この例の「サービスA」は説明用の架空のもので、実在の料金体系を示すものではありません。主語を省かない、「前述の」「上記の」に頼らない、条件と日付を同じ文に置く、という書き方は、人が拾い読みするときにも役立ちます。ほかのページには無い手順や測定の結果など、一次情報を持つページは、探す段階で選ばれる理由を持ちます。
当サイト（seoagent.jp）では、記事ごとに主題・テーマ・言及する語を決め、構造化データで宣言しています（93語。Wikidataの項目は確認できた語だけ指定）。記事が何について書かれているかを、推測させずに伝えるための作業です。AIの回答での扱いが変わったかどうかは、まだ測定していません。
自社でRAGを使うときの進め方と注意点
社内の問い合わせ対応や、よくある質問の検索にRAGを使う場合は、次の順で進めると、問題の原因を切り分けやすくなります。
- 答えさせたい質問を集める：実際に受けた質問を、答えと根拠の資料と一緒に一覧にします。これが後の点検用の質問セットになります。
- 資料を整える：古い版や重複を外し、各資料に更新日と担当を付けます。表や画像の中にしか無い情報は、文章でも書いておきます。
- 見る権限を決める：人事や顧客の情報など、質問した人が本来見られない資料が答えに混ざらないよう、検索の段階で権限を反映させます。外部のサービスに資料を送る場合は、その扱いも確かめます。
- 小さく試して点検する：質問セットで、正しい資料が検索の上位に来ているか（探す段階）と、回答が資料に沿っているか（生成の段階）を分けて確かめます。
- 更新の流れを決める：資料を直したら索引も更新する手順を決めます。古い資料が残ると、古い答えが返り続けます。
回答を作るモデルは、大きなLLMに限りません。社内のサーバーや端末で動かしやすい小さな言語モデル（SLM）と組み合わせる構成もあり、資料を社外のサービスに送りたくない場合の選択肢になります。LLMとの違いは「SLM（小規模言語モデル）とは」で説明しています。
点検に使う質問セットの例
質問セットは、答えやすい質問だけでなく、間違えやすい種類の質問を混ぜて作ります。例：社内の問い合わせ対応に使う場合です。
| 質問の種類 | 質問の例 | 確かめること |
|---|---|---|
| 資料に答えがそのまま書いてある | 「経費精算の締め日はいつですか」 | 正しい資料が上位に来て、答えが資料と一致するか |
| 言い回しが資料と違う | 「立て替えたお金はいつまでに申請すればよいですか」 | 同じ資料を見つけられるか |
| 型番や固有名詞が鍵になる | 「型番X-100の保証期間は」 | 似た型番の資料と取り違えないか |
| 資料に答えが無い | 資料に載っていない制度についての質問 | 「分からない」と答え、推測で答えを作らないか |
| 資料が更新された | 改定前と改定後で答えが変わる質問 | 新しい版の資料を使って答えるか |
検索の結果と回答を分けて記録しておくと、誤りが「探す」段階で起きたのか、「生成」の段階で起きたのかを見分けられます。どれだけ正しく答えられるかは、資料の質や質問の種類によって大きく変わります。導入の前に、自社の質問セットで実際に確かめることが大切です。
よくある質問
RAGを使えば、ハルシネーションは無くなりますか？
無くなりません。資料が見つからない、関係の薄い資料が渡される、LLMが資料を読み違える、といった場合に誤りが起こります。出典を表示して人が確かめられるようにし、資料に無いことは答えないよう指示します。
RAGとAI検索は同じものですか？
同じではありませんが、AI検索の多くは、ウェブを検索してから答えを作るという点でRAGと同じ考え方で動いています。RAGは仕組みの名前、AI検索はそれを使ったサービスの形と考えると分かりやすくなります。
サイトをRAGに使われやすくするために、特別なファイルやタグは必要ですか？
Googleは、AIによる概要やAIモードに表示されるために、特別なファイルやマークアップは必要ないと説明しています。インデックスに登録されていること、内容がはっきり書かれていることが前提になります。
RAGとLLMOは、どういう関係ですか？
RAGはAIが答えを作る仕組み、LLMOはその仕組みの中で自社の情報が正しく扱われるようにするサイト側の取り組みです。AI検索の「探す」段階で見つかり、「渡す」段階で切り出されても意味が通るページにすることが、LLMOの具体的な作業になります。
RAGを作るのに、ベクトルデータベースは必須ですか？
必須ではありません。資料が少なければキーワード検索だけでも作れますし、資料をそのまま入力に入れる方法もあります。言い回しの違う質問にも対応したい場合に、埋め込みによる検索が役立ちます。
SEOAGENTでできること
SEOAGENTでは、記事づくりでも「資料を選んで渡し、確かめる」という流れを取り入れています。
- 自社資料・写真・文体：商品資料やよくある質問をURL・PDF・テキストで登録し、記事ごとに使う材料を選べます。使える期限を過ぎた資料は記事づくりに使いません。
- 品質チェック：記事の主張を資料や出典と照らし合わせ、確認できたものと確認できないものを分けて示します。
- AI検索・表示速度の診断：robots.txtを読み、検索の表示に使われるクローラーと学習に使われるクローラーを分けて確認できます。
LLMやAI検索に関する記事は「LLMO対策の記事一覧」にまとめています。
