RAG（検索拡張生成）とは何か｜定義・仕組み・コンテキストエンジニアリングにおける役割

RAG（検索拡張生成／Retrieval-Augmented Generation）とは、外部の知識ソースから関連情報を検索し、それを文脈に加えてAIに回答を生成させる技術である。モデルが学習していない最新情報や社内情報を補い、事実に基づく回答を促す。コンテキストエンジニアリングにおいて「知識をどう選んで渡すか」を担う代表的な構成要素にあたる。

生成AIには、原理的な制約がふたつある。学習時点の知識しか持たないこと。そして、学習していない事柄について、もっともらしい誤りを生成してしまうこと。この2つの課題に対する代表的な対処として広まったのが、RAG である。

本記事では、RAG の定義と仕組みを整理したうえで、RAG が「コンテキストエンジニアリング」という上位の設計概念のなかでどのような役割を担うかまでを扱う。

RAGの定義

RAG（Retrieval-Augmented Generation）は、日本語では「検索拡張生成」と訳される。文字通り、検索（Retrieval）によって外部情報を取り出し、それをモデルに渡す文脈に加えて（Augmented）、回答を生成（Generation）させる技術である。

通常の大規模言語モデル（LLM）は、学習時点までに獲得した知識をもとに回答を生成する。一方で、企業が業務で扱う情報の多くは、モデルの学習データには含まれない。社内マニュアル、契約書、顧客対応履歴、最新の業界動向。こうした情報を、回答のたびに検索して取り出し、AIに文脈として渡す。これが RAG の基本構造である。

ここで重要なのは、RAG はモデル自体を書き換える技術ではない、という点。モデルの重みを再学習させるファインチューニングとは異なり、RAG はモデルに「渡す文脈」を充実させるアプローチに位置する。

なぜRAGが必要なのか

LLM が抱える代表的な2つの限界が、RAG の必要性を生んだ。

第一に、知識の鮮度と範囲の問題。LLM は学習データのカットオフ時点までの情報しか持たない。学習に含まれない最新の出来事や、そもそも公開されていない社内情報には答えられない。

第二に、ハルシネーションの問題。LLM は知らないことを問われたとき、知らないと答える代わりに、もっともらしい誤った内容を生成してしまうことがある。これは確率的に最も自然な続きを生成する仕組みに由来する、構造的な性質である。

RAG はこの2つに対処する。外部の信頼できる知識ソースから関連情報を取り出し、その情報に基づいて回答するよう促すことで、知識の範囲を拡張し、根拠ある回答に近づける。「自社の文書のなかから答えを引いてきて、その範囲で答える」という運用が成立するため、業務における生成AI活用の現実的な選択肢として広く採用されている。

RAGの仕組み（基本の流れ）

RAG の基本的な処理は、おおむね次の流れで進む。

• 質問の入力：ユーザーからの質問（クエリ）が入力される
• 関連文書の検索：質問と関連性の高い文書を、外部の知識ソース（社内文書データベース、ベクトルデータベース等）から検索して取り出す
• 文脈への追加：取り出した文書を、AIに渡すプロンプトの文脈として追加する
• 回答の生成：AIは、追加された文脈に基づいて回答を生成する
• 出典の提示（実装による）：根拠となった文書を併せて提示する

検索の部分では、キーワード一致だけでなく、意味の近さを捉える「ベクトル検索」が広く使われる。質問と文書をそれぞれベクトル（数値の並び）に変換し、ベクトル空間上で近いものを検索する仕組みである。これにより「同じ意味だが異なる言葉で書かれた文書」も拾えるようになる。

実装は多様で、シンプルなキーワード検索と組み合わせるもの、複数の検索手法を組み合わせるハイブリッド型、検索結果を再ランキングする工夫を加えるものなど、設計上の選択肢は広い。

コンテキストエンジニアリングにおけるRAGの役割

RAG の位置づけを正確に理解するうえで欠かせないのが、上位概念であるコンテキストエンジニアリングとの関係である。

コンテキストエンジニアリング は、AIに「何を・いつ・どの形式で・どれだけ」渡すかを動的に設計する技術全体を指す。プロンプト本文、システム指示、外部ツールの結果、過去の対話履歴、そして検索された知識——AIに渡される文脈のすべてが対象になる。

このなかで RAG は、「知識をどう選んで渡すか」を担う構成要素として位置づけられる。コンテキストエンジニアリング全体のうち、外部知識の取得と注入の部分を担う技術、と理解するのが正確である。

つまり、RAG ≠ コンテキストエンジニアリングではない。RAG ⊂ コンテキストエンジニアリングである。RAG はコンテキストエンジニアリングの代表的な構成要素であり、極めて重要な部品の一つだが、コンテキストエンジニアリングが扱う領域はそれよりも広い。対話履歴の圧縮、ツール呼び出し結果の整形、複数情報源の優先順位設計など、RAG が直接扱わない部分も含む。

両者を別物として対立させるのも、同一視するのも、いずれも整理として正確ではない。RAG が知識調達を担い、コンテキストエンジニアリングがその上位で文脈設計全体を統括する。この階層関係を踏まえると、両者の役割が明快に見えてくる。

RAGの具体例

RAG が実際に活用される代表的な場面は、以下のようなものである。

• 社内ドキュメント検索ボット：社内規程、業務マニュアル、過去の議事録などを知識ソースとして、社員の質問にAIが回答する。「経費精算の上限はいくらか」「この契約条件の確認手順は」といった問い合わせに、規程文書を根拠として返す
• 製品サポートの自動応答：製品マニュアル、FAQ、過去の問い合わせ履歴を知識ソースとし、顧客からの問い合わせに対して根拠つきで回答する。サポート担当者の初動を支援する用途でも使われる
• 最新情報を反映した調査支援：業界レポート、ニュース記事、論文などを定期的に更新される知識ソースとして接続し、最新動向を踏まえた要約・調査を支援する

いずれの例にも共通するのは、「AIが知らない情報を、検索で補って答えさせる」という構造である。モデル自体は同じでも、何を渡すかで出力の質が変わる——この事実が、RAG が広く採用されてきた背景にある。

よくある質問

Q1. RAGとファインチューニングの違いは?

RAG はモデルに「渡す文脈」を充実させるアプローチであり、モデル自体は変更しない。一方ファインチューニングは、モデルの重みを追加学習で書き換える。RAG は知識の差し替えや更新が容易で、特定の文書を根拠として明示できる利点を持つ。ファインチューニングは特定の振る舞いや文体を恒常的に身につけさせたいときに有効。両者は対立ではなく、目的に応じて使い分けるか、組み合わせる技術である。

Q2. RAGとコンテキストエンジニアリングは同じものか?

同じものではない。RAG はコンテキストエンジニアリングの一部であり、特に「外部知識をどう選んで渡すか」を担う構成要素にあたる。コンテキストエンジニアリングはより広い概念で、対話履歴の管理、ツール結果の整形、複数情報源の統合など、AIに渡す文脈全体の動的設計を扱う。詳しくは コンテキストエンジニアリング を参照されたい。

Q3. RAGを導入すればハルシネーションは完全になくなるか?

完全にはなくならない。RAG は根拠ある回答を促す有効な手段だが、検索結果の品質、文書の網羅性、検索アルゴリズムの精度、モデルが文脈をどう解釈するかなど、複数の要因が品質を左右する。検索された文書から論理的に導けない内容を、モデルが補完して生成するケースもある。RAG は「ハルシネーションを大きく抑える技術」であって「ゼロにする技術」ではない、と理解するのが正確である。

Q4. どんな企業・どんな業務に向いているか?

社内文書・マニュアル・過去事例など、構造化されていない情報資産が大量に存在し、それらに基づく問い合わせ対応や調査業務が一定量ある組織で、特に有効に機能する。一方、創造的な発想や、文書化されていない現場の判断が中核となる業務では、RAG だけで価値を出すのは難しい。業務の性質に応じた使い分けが前提となる。

Q5. RAGの導入ハードルは高いか?

技術的な実装方法は近年大きく簡素化され、各種クラウドサービスや基盤モデル提供者が RAG 構築の機能を提供している。一方で、本質的なハードルは技術ではなく、「どの文書を、どう構造化して、どう更新し続けるか」という運用設計の側にある。知識ソースの整備と継続的なメンテナンス体制こそが、RAG の品質を決める最大の要因となる。

関連するAX for Revenueの概念

• コンテキストエンジニアリング｜RAG の上位概念。AI に渡す文脈全体を動的に設計する技術
• プロンプトエンジニアリング｜AI への指示文を最適化する関連技術
• Pillar 3: AX for Revenue を実装する｜AI を事業の収益創造に接続する実装論

RAG は、AI を効率化の道具から、事業の力に組み替えていくうえで重要な部品の一つである。ただし、RAG 単体で売上が動くわけではない。何を検索可能にし、何を AI に渡し、何を生み出させるか——その設計思想の側に、本当の差が宿る。「AIは効率化から、収益の創造へ」。その移行を実装で支える技術の一つとして、RAG は位置づけられる。

---

発行: 株式会社アルファドライブ