ChatGPTやClaudeのような生成AIに社内マニュアルの内容を聞いても、的外れな答えが返ってくる——そんな経験はないだろうか。大規模言語モデル（LLM）は学習した時点までの一般知識しか持たず、あなたの会社の資料や最新のニュースは知らない。この「知らないこと」を外部データで補い、根拠に基づいた回答を作らせる仕組みがRAG（検索拡張生成）だ。
本記事ではRAGとは何かを、専門用語をかみ砕きながら解説する。仕組み・メリット・業務での使いどころ、精度を上げる工夫、そして「ファインチューニングとどう違うのか」という混同しやすい点まで整理していく。RAGは、AIを賢く作り直すのではなく、AIに「カンニングペーパー」を渡す技術だと考えると理解しやすい。
RAGとは何か
RAGは Retrieval-Augmented Generation の略で、日本語では「検索拡張生成」と訳される。名前のとおり、AIが回答を生成（Generation）する前に、関連する情報を外部から検索（Retrieval）して取り込み、その情報を根拠にして答えを作る手法である。2020年にMeta（当時Facebook）の研究チームが提唱した概念で、現在は企業の生成AI活用でもっとも一般的な構成のひとつになっている。
通常のLLMは、質問を受け取るとその場で頭の中（学習済みの知識）だけを頼りに答える。一方RAGでは、質問が来るたびにまず社内文書やデータベースを検索し、見つかった文章をAIに一緒に渡してから答えさせる。つまりAIは「記憶」ではなく「手元の資料」を読んで答えるため、事実に沿った回答になりやすい。
なぜRAGが必要とされるのか
LLM単体には3つの弱点がある。ひとつは学習データの締め切り以降の情報を知らないこと。次に、会社の非公開資料など学習に含まれない情報は答えられないこと。そして、もっともらしい嘘（ハルシネーション）を生み出すことだ。RAGは信頼できる情報源を回答の土台にすることで、これらの弱点をまとめて緩和する。近年はLLMが扱えるコンテキスト長（一度に読める文章量）が大きく伸びたが、社内の全文書を毎回丸ごと渡すのはコストも精度も現実的でないため、必要な箇所だけを検索して渡すRAGの価値は依然として高い。
RAGの仕組みを4ステップで理解する
RAGの処理は大きく分けて「事前準備」と「回答時」に分かれる。全体像を表で押さえておこう。
| 段階 | ステップ | やっていること |
|---|---|---|
| 事前準備 | ①インデックス化 | 社内文書を細かく分割し、意味を数値化（ベクトル化）してデータベースに保存 |
| 回答時 | ②検索 | ユーザーの質問と意味が近い文章をデータベースから探し出す |
| 回答時 | ③拡張 | 見つけた文章を質問文に添えてLLMへ渡す（プロンプトに埋め込む） |
| 回答時 | ④生成 | LLMが渡された資料を根拠に、自然な文章で回答を作る |
鍵になるのが②の検索方法だ。単純なキーワード一致ではなく、文章の「意味」をベクトル（数百〜数千次元の数値の並び）に変換して比較するベクトル検索が使われる。これにより「有給休暇」と質問して「年次有給の申請」という表現の文書を拾える、といった柔軟な検索が可能になる。
ベクトルデータベースの役割
意味をベクトル化した大量の文書を保存し、高速に近いものを探す専用の保管庫がベクトルデータベースだ。文書量が増えても素早く関連情報を取り出せるよう設計されており、RAGの検索性能を左右する重要な部品になる。Pinecone・Weaviate・Chroma・PostgreSQLの拡張であるpgvectorなど、選択肢は幅広い。
埋め込み（エンベディング）とチャンク分割
文章をベクトルに変換する処理を埋め込み（エンベディング）と呼び、専用のモデルが担う。また、長い文書をそのまま扱うと検索の粒度が粗くなるため、適切な長さに区切るチャンク分割が欠かせない。区切り方が大きすぎると無関係な情報が混ざり、小さすぎると文脈が失われるため、この設計がRAGの精度を大きく左右する。
RAGとファインチューニングの違い
「AIに独自情報を覚えさせる」という点で、RAGはファインチューニング（追加学習）と混同されやすい。しかし両者はアプローチが根本的に異なる。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 情報の持たせ方 | 外部データベースから都度参照 | モデル自体に学習させ内部に取り込む |
| 情報の更新 | データを差し替えるだけで即反映 | 再学習が必要で手間とコストが大きい |
| 得意なこと | 最新・大量の事実知識を扱う | 特定の文体・口調・専門タスクへの適応 |
| 回答根拠の提示 | 出典を示せる | 根拠の提示は難しい |
| 初期コスト | 比較的低い | 学習用データ整備と計算コストが高い |
頻繁に変わる事実情報を扱いたいならRAG、独特の口調や専門的な振る舞いを身につけさせたいならファインチューニング、と覚えておくとよい。両者は排他的ではなく、組み合わせて使うこともできる。
RAGの種類と発展形
ひとくちにRAGといっても、構成の洗練度によっていくつかの段階がある。導入検討時の共通言語として押さえておきたい。
| 種類 | 特徴 |
|---|---|
| Naive RAG（素朴なRAG） | 「検索→そのまま渡す→生成」の最小構成。手軽だが検索がずれると精度が落ちる |
| Advanced RAG | 検索の前後に工夫を加える。質問の言い換えや、拾った候補を並べ替えるリランキングで精度を高める |
| エージェンティックRAG | AI自身が「検索が足りない」と判断したら検索を繰り返すなど、自律的に精度を高める発展形 |
近年はAIエージェントの考え方と結び付いたエージェンティックRAGの実用化が進んでいる。一度の検索で終えず、必要に応じて検索や絞り込みを自ら繰り返すことで、複雑な質問にも耐えられる回答を目指す方向だ。
RAGの精度を高める工夫
RAGは「検索がうまくいくかどうか」がほぼすべてと言ってよい。実務では次のような改善策がよく使われる。
- ハイブリッド検索：意味で探すベクトル検索と、キーワード一致の従来型検索を併用し、取りこぼしを減らす
- リランキング：検索で拾った候補を、より精密なモデルで並べ替えて上位だけをAIに渡す
- チャンク設計の見直し：区切りの長さや重なり（オーバーラップ）を調整し、文脈を保つ
- メタデータ活用：部署・日付・文書種別などで絞り込み、無関係な文書を検索対象から外す
RAGの精度改善は「AIを変える」より「検索を良くする」に注力するのが近道だ。
RAGの業務活用例
RAGは「大量の社内文書があるが、必要な情報を探すのが大変」という課題と特に相性がよい。代表的な使いどころを挙げる。
社内ヘルプデスク・FAQ自動応答
就業規則・経費精算ルール・情報システムの手順書などを取り込めば、社員が自然な言葉で質問するだけで該当箇所を根拠に回答が返る。総務や情シスへの問い合わせ負荷を下げられる。
カスタマーサポート
製品マニュアルや過去の問い合わせ履歴を情報源にすることで、オペレーターの回答補助や一次対応の自動化に使える。出典を示せるため、回答の裏取りもしやすい。
専門文書の調査支援
契約書・論文・技術資料など、読み込むのに時間がかかる文書群に対して「この条件に該当する箇所は？」と尋ねられる。法務・研究開発・コンサルティングなど、根拠の明示が重視される業務で価値が高い。
RAGを構築する主なツール・サービス
RAGは自前でゼロから組むこともできるが、部品を提供するライブラリやクラウドサービスを使えば立ち上げは大きく速くなる。代表的な選択肢を性質ごとに整理する。
| 種類 | 例 | 役割 |
|---|---|---|
| 開発フレームワーク | LangChain / LlamaIndex | 検索・生成の処理をつなぐ土台。RAG構築の定番 |
| ベクトルDB | Pinecone / Weaviate / Chroma / pgvector | ベクトル化した文書を保存し高速検索する |
| クラウド統合型 | 各クラウドのAI検索サービス | 文書登録から検索までを一体で提供し設定が容易 |
まず小さく検証するなら、文書を登録するだけで使えるクラウド統合型やノーコード寄りのツールから入り、要件が固まってからフレームワークで作り込む流れが手戻りを抑えやすい。
RAG導入時の注意点
RAGは万能ではない。検索で拾ってくる元データの質が低ければ、回答の質もそれに引きずられる（いわゆる「ゴミを入れればゴミが出る」）。文書の整理・分割の仕方（チャンク設計）や、検索精度のチューニングが成否を分ける。また、機密文書を扱う場合はアクセス権限の設計やデータの取り扱いにも配慮が必要だ。RAGは「導入して終わり」ではなく、元データの整備と精度改善を続ける運用が前提になる。
どの生成AIサービスを土台にするか迷う場合は、ChatGPT・Claude・Geminiの3社比較も判断材料になる。用語の全体像をつかみたいときはAI用語総覧もあわせて参照してほしい。
よくある質問
RAGとファインチューニングはどちらを選ぶべきですか？
最新情報や大量の事実知識を扱いたいならRAGが向く。特定の文体や専門タスクへの適応が目的ならファインチューニングを検討する。多くの業務用途ではまずRAGから始めるのが手堅い。
RAGを使えばハルシネーションは完全になくなりますか？
大幅に減らせるが、ゼロにはできない。検索でうまく根拠を拾えなかった場合などは誤りが残る。出典表示や人によるチェックと併用するのが現実的だ。
RAGの導入にプログラミングは必須ですか？
本格的な構築には開発が必要だが、近年は社内文書を登録するだけでRAGを構築できるサービスやツールも増えており、ノーコードに近い形で試せる選択肢もある。
ベクトルデータベースとは何ですか？
文章の意味を数値の並び（ベクトル）に変換して保存し、意味の近い文書を高速に探せる専用データベースだ。RAGの検索部分を支える中核部品にあたる。
RAGはどんなデータでも扱えますか？
テキスト化できる文書が基本だが、PDF・表・画像なども前処理を工夫すれば扱える。ただしデータが整理されていないほど検索精度は落ちるため、元データの整備が重要になる。
個人でもRAGを試せますか？
試せる。手元の資料を読み込ませて質問できる機能を備えたAIサービスやツールがあり、小規模なら個人でもRAG的な使い方を体験できる。
RAGの精度が低いときはどこを見直せばよいですか？
まず検索部分を疑うのが定石だ。チャンクの区切り方、ハイブリッド検索やリランキングの導入、元文書の整理といった「検索を良くする」施策から着手すると改善しやすい。
コンテキスト長が伸びればRAGは不要になりますか？
不要にはならない。長文をまとめて渡せてもコストが増え、関連の薄い情報が混ざると精度が下がる。必要な箇所だけを選んで渡すRAGの利点は、コンテキストが伸びても残る。
まとめ
RAGは、生成AIに外部の信頼できる情報を検索させ、それを根拠に回答させる仕組みだ。AIそのものを作り替えるのではなく「参照する資料を渡す」発想のため、情報の更新が容易で、事実に沿った回答を得やすい。社内FAQやカスタマーサポートなど、大量の文書を抱える業務との相性がよく、AI活用の実務的な第一歩として広く使われている。精度は検索の質でほぼ決まるため、まずは自社の「よく聞かれる質問」と「その答えが書かれた文書」から、小さく試してみるのがおすすめだ。
