この用語をシェア
概要
RAG（Retrieval-Augmented Generation、日本語では「検索拡張生成」）は、大規模言語モデル（LLM）が回答を生成する直前に、社内文書やマニュアル、Webページといった外部の知識ソースから関連情報を検索し、その検索結果を根拠としてプロンプトに追加してから最終的な応答を生成させる技術です。2020年にMeta（当時のFacebook AI Research）の研究者Patrick Lewisらが論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で提唱した手法が名称の由来とされ、LLM単体では避けられない「ハルシネーション（もっともらしい誤情報を生成する現象）」と「学習データのカットオフ以降の情報を知らない」という2つの弱点を補う実務的な解決策として、2023年以降の企業向けLLM導入ブームの中で急速に普及した。
RAGが広く採用される最大の理由は、モデル自体を再学習（ファインチューニング）することなく、参照する文書を差し替えるだけで回答内容を最新化・専門化できる点にある。たとえば社内規程が改訂された場合、ファインチューニングでは学習データを作り直してモデルを再学習する必要があるが、RAGであれば検索対象の文書ストアを更新するだけで、翌日には新しい規程に基づいた回答が得られる。また、回答の根拠となった文書の該当箇所を合わせて提示できるため、生成結果の出典を確認しながら利用できる「説明可能性」の高さも実務上の評価につながっている。
仕組み・詳細解説
RAGは大きく「リトリーバー（Retriever／検索器）」と「ジェネレーター（Generator／生成器）」という2つの構成要素を組み合わせたパイプラインである。ユーザーの質問が入力されると、まずリトリーバーが外部知識ベースから関連度の高い文書断片（チャンク）を検索し、その検索結果を質問文と一緒にプロンプトへ組み込んだ上で、ジェネレーター役のLLMが最終的な回答テキストを生成する。以下、実務で押さえておくべき4つの構成要素に分けて解説する。
チャンク分割とエンベディング（Embedding）
検索対象となる文書は、そのままの長さではLLMのコンテキストウィンドウに収まらないため、あらかじめ数百トークン程度の「チャンク」と呼ばれる単位に分割しておく。各チャンクはエンベディングモデルによって数百〜数千次元の数値ベクトルに変換され、ベクターデータベース（Pinecone、Weaviate、Milvus、Chroma、PostgreSQLの拡張機能であるpgvectorなど）に格納される。チャンクの区切り方（文単位か、見出し単位か、固定文字数かなど）や、チャンク同士を少し重複させる「オーバーラップ」の設計次第で、後続の検索精度が大きく変わるため、RAG構築における最初の勘所となる。
リトリーバー（検索）の仕組み
ユーザーの質問文も同じエンベディングモデルでベクトル化され、コサイン類似度などの指標を使ってベクターデータベース内の近傍チャンクを検索する（近似最近傍探索、ANN）。これを「セマンティック検索（意味検索）」と呼び、キーワードの完全一致に頼らず、表記ゆれや言い換えを含めて意味的に近い文書を拾える点が特徴である。一方で、固有名詞や型番、法令番号のような一致検索が重要な場面では意味検索だけでは取りこぼしが生じやすいため、従来型のキーワード検索（BM25など）と意味検索を組み合わせる「ハイブリッド検索」もよく採用される。
リランキングとコンテキスト構築
検索によって候補となるチャンクを多めに取得した後、それらをより精密な基準で並べ替える「リランキング（Re-ranking）」の工程を挟む構成も多い。リランカーはクエリとチャンクのペアをまとめて評価する専用モデルであり、単純なベクトル類似度よりも精度良く「本当に質問への回答に必要な文書」を絞り込める。最終的に選ばれた上位数件のチャンクが、システムプロンプトの一部としてLLMに渡され、「以下の文書を参考に、事実に基づいて回答してください」といった指示とともにジェネレーターへ入力される。
ジェネレーター（生成）と根拠の提示
ジェネレーターの役割自体は通常のLLMと同じであるが、RAGでは「与えられた文書の範囲内で回答し、文書にない情報は推測しない」よう指示するプロンプト設計が重要になる。加えて、回答文中に参照元の文書名やページ番号を脚注のように付記させる実装も一般的で、これにより利用者は生成された回答をそのまま信じるのではなく、元の一次情報に立ち返って検証できる。この「根拠の提示」こそが、RAGが単なる情報検索やLLM単体の応答生成と一線を画す実務上の価値である。
具体例・ユースケース
RAGは「社内の非公開情報」や「最新情報」をLLMに扱わせたい場面で特に有効であり、業種を問わず次のような形で導入が進んでいる。
- 企業内ナレッジベース: 社内規程、業務マニュアル、議事録を参照させる社内問い合わせチャットボット。人事・総務・情シスへの定型的な問い合わせ削減を目的に導入されるケースが多い
- カスタマーサポート: 製品マニュアルやFAQ、過去の問い合わせ履歴を参照した一次対応の自動化。回答の根拠となったマニュアルの該当箇所を提示することで、オペレーターの確認作業も効率化できる
- コールセンターのオペレーター支援: 顧客対応中にリアルタイムで関連マニュアルを検索・要約し、オペレーターの回答作成を補助する用途
- 研究・学術支援: 論文データベースやarXivの抄録を参照した文献調査、先行研究の要約
- 法務・コンプライアンス: 契約書ひな形、社内規程、法令改正情報を参照した一次チェック（最終判断は必ず法務担当者が行う前提での補助利用）
- ソフトウェア開発支援: 社内コードベースや技術ドキュメントを参照させ、既存実装の作法に沿ったコード生成・レビューコメント作成を行うコーディングアシスタント
- ECサイト・商品検索: 商品カタログやレビューを参照した商品比較・レコメンドの対話型インターフェース
- ニュース・時事情報: 学習データのカットオフ以降に発生した出来事を、ニュース記事やWeb検索結果を検索対象に加えることで回答に反映
代表的な構築ツール・サービス
RAGはゼロから自前実装することも可能だが、実務では次のようなフレームワーク・マネージドサービスを組み合わせて構築されることが多い。バージョンや提供状況は変化するため、詳細は各社公式情報を参照されたい。
| 分類 | 代表例 | 用途 |
|---|---|---|
| オーケストレーションフレームワーク | LangChain、LlamaIndex | 検索・プロンプト構築・生成の一連の処理をコードで組み立てるためのライブラリ |
| ベクターデータベース | Pinecone、Weaviate、Milvus、Chroma、pgvector | エンベディングベクトルの格納と近似最近傍検索 |
| マネージドRAGサービス | Amazon Bedrock Knowledge Bases、Azure AI Search、Google Vertex AI Search | チャンク分割・検索・リランキングまでをクラウド側で統合提供 |
| エンベディングモデル | OpenAI text-embedding、Cohere Embed、各社の多言語対応モデル | テキストをベクトルへ変換する処理 |
導入シナリオの一例：社内問い合わせチャットボット
代表的な導入手順としては、まず社内規程・マニュアル・過去のQ&Aをテキスト化し、適切な粒度でチャンクに分割してベクターデータベースへ登録する。次に、想定される質問例を集めたテストセットを作成し、実際に検索・生成させた回答を人手でレビューして、検索精度が低い領域（チャンク分割の粒度が不適切、専門用語の表記ゆれで検索漏れが起きる、など）を特定し改善する。最後に、個人情報や人事評価など機微な内容を含む質問は自動回答させず有人窓口へ転送するといった運用ルールを設け、段階的に対象範囲を広げていくのが実務上の定石である。
メリット・デメリット（注意点）
| メリット | デメリット・注意点 |
|---|---|
| モデルを再学習せず、参照文書の追加・更新だけで回答内容を最新化できる | 検索精度が低いと、そもそも的外れな文書を根拠に回答してしまい、ハルシネーションを完全には防げない |
| 回答の根拠となった文書箇所を提示でき、説明可能性・検証可能性が高い | 検索・リランキング・生成と処理段階が増えるため、単純なLLM呼び出しより応答が遅くなりやすい |
| ファインチューニングに比べて構築コスト・専門知識のハードルが低い | チャンク分割・エンベディングモデル選定・リランキングなど、精度を出すための調整項目が多い |
| 社外秘の情報をモデルの重みに焼き込まず、検索対象を分離して管理できる | アクセス権限のない文書までLLMが検索・回答に利用してしまう「権限漏れ」のリスク管理が必要 |
| 複数の情報源（社内文書＋Web検索＋データベース）を組み合わせやすい柔軟な構成 | 検索結果の量が多いほどプロンプトが長くなり、LLM利用料（トークン課金）が増加しやすい |
総じて、RAGは「LLMに知識を教え込む」のではなく「必要な知識をその都度手渡す」アプローチであり、知識の更新頻度が高い業務や、根拠提示が求められる業務との相性が良い。一方で、検索精度そのものがRAG全体の回答品質の上限を決めてしまうため、導入後も継続的な検索チューニングが欠かせない点は見落とされがちな注意点である。
混同されやすい用語・類似技術との違い
| 用語 | RAGとの違い |
|---|---|
| ファインチューニング | モデル自体の重みを追加学習で更新する手法。文体・口調・専門用語の言い回しを覚えさせるのには向くが、知識の更新には学習データの作り直しと再学習が必要になる。RAGは知識の更新、ファインチューニングは振る舞い・スタイルの調整、という使い分けが実務上の目安になる。両者は併用も可能である。 |
| ロングコンテキストLLM | 近年のLLMはコンテキストウィンドウが数十万〜百万トークン程度まで拡大しており、関連文書を検索せずまるごと入力する「ロングコンテキスト」アプローチも選択肢になってきた。ただし文書量が膨大な場合は依然としてトークン課金・応答速度の面でRAGによる絞り込みが有利であり、両者は対立技術というより使い分けの関係にある。 |
| セマンティック検索 | 意味的に近い文書を検索する技術そのものを指す言葉で、RAGの「リトリーバー」部分に相当する要素技術。セマンティック検索単体では検索結果一覧を返すだけだが、RAGはその検索結果をLLMに渡して自然文の回答を生成させるところまでを含む。 |
| ナレッジグラフ・GraphRAG | エンティティ（人物・組織・製品など）間の関係性をグラフ構造で表現し、それを検索対象に使う手法。通常のベクトル検索チャンクだけでは拾いにくい「AとBの関係」といった横断的な質問に強いとされ、後述するGraphRAGとして2024年以降注目されている。 |
| Function Calling／ツール利用 | LLMが外部API・関数を呼び出す仕組み全般を指す、より広い概念。RAGにおける文書検索も広義には「検索ツールの呼び出し」の一種と捉えられ、実装上はFunction Callingの仕組みを使ってRAGの検索処理を呼び出すケースも多い。 |
| AIエージェント／Agentic RAG | 従来のRAGは「検索を1回行ってから生成する」直線的な処理が基本だが、AIエージェントの考え方を取り入れ、検索結果が不十分なら再検索する、複数の検索クエリに分解するといった自律的な制御を行う構成は「Agentic RAG」と呼ばれ、両者は連続的な発展関係にある。 |
実務導入のポイント
RAGはプロトタイプ段階では容易に動くものが作れる一方、実運用では「検索精度が期待ほど出ない」という壁にぶつかりやすい。導入時に押さえておきたい実務上の観点は以下の通り。
- チャンク設計の見直し: 文書の種類（規程集、FAQ、議事録など）ごとに適したチャンクサイズ・分割単位は異なるため、一律の設定で済ませず種類別に調整する
- 評価指標の設定: 「検索した文書が本当に質問に関連しているか（Context Precision/Recall）」「生成された回答が検索文書の内容に忠実か（Faithfulness）」といった観点で評価用データセットを用意し、改善のたびに定量評価する
- ハイブリッド検索の採用: 意味検索だけでなくキーワード検索も組み合わせ、固有名詞や型番などの完全一致が必要な検索を取りこぼさないようにする
- アクセス権限の反映: 部署ごとに閲覧権限が異なる文書を扱う場合、検索結果に利用者の権限外の文書が混ざらないよう、検索基盤側でアクセス制御（フィルタリング）を実装する
- 更新運用の設計: 元文書が改訂された際に、ベクターデータベース側のチャンクも自動的に再登録・再エンベディングされる仕組みを用意し、情報の陳腐化を防ぐ
- 「わからない」と答えさせる設計: 検索結果に該当情報がない場合は無理に推測させず、「情報が見つかりませんでした」と回答させるプロンプト設計にすることで、ハルシネーションのリスクを下げる
2025〜2026年の最新動向
Agentic RAG：検索を自律的に繰り返す構成
従来の「1回検索して回答する」構成から発展し、LLM自身が「この検索結果では不十分」と判断した場合に検索クエリを言い換えて再検索したり、質問を複数の小さな検索クエリに分解して並行検索したりする、AIエージェントの考え方を取り入れたAgentic RAGの実装が広がっている。複雑な質問や複数文書にまたがる質問への回答精度向上が期待される一方、検索回数が増える分だけ応答時間とコストも増加するため、単純な質問には従来型の1回検索構成を使うといった使い分けが実務では検討されている。
GraphRAG：関係性を捉えた検索
Microsoft Researchが2024年に公開したGraphRAGをはじめ、文書からエンティティとその関係性を抽出してナレッジグラフを構築し、それを検索対象に加える手法が注目されている。単純なチャンク単位のベクトル検索では拾いにくい「組織全体の傾向を横断的にまとめて」といった要約・関係性重視の質問への対応力を高める狙いがあり、通常のベクトル検索と組み合わせるハイブリッドな構成での活用が進んでいる。
ロングコンテキストLLMとの使い分けの定着
GeminiやClaudeなど主要モデルのコンテキストウィンドウが大幅に拡大したことで、「RAGはロングコンテキストに置き換えられて不要になるのでは」という議論が一時話題になったが、実務では対象文書量が数十〜数百万文字規模になるとロングコンテキストだけでは処理コスト・速度の面で非効率になりやすく、依然としてRAGによる事前絞り込みが有効というのが2025〜2026年時点での実務的な見解である。両者を組み合わせ、RAGで絞り込んだ上位文書をロングコンテキストで丸ごと読ませるハイブリッド構成も採用されている。
マルチモーダルRAGの広がり
テキストだけでなく、図表・グラフを含むPDFや画像、音声データも検索対象に含める「マルチモーダルRAG」の実装が増えている。マルチモーダル対応のエンベディングモデルや、画像を含むページをそのまま解析できるLLMの登場により、従来はテキスト抽出が難しかった図表中心の資料もRAGの対象に組み込みやすくなってきている。
関連用語
- LLM（大規模言語モデル） - RAGが回答生成に用いるモデル本体
- ベクトルデータベース - RAGの検索基盤となるエンベディングの格納・検索技術
- プロンプトエンジニアリング - 検索結果を踏まえた回答指示の設計手法
- ファインチューニング - モデル自体を追加学習させるRAGの代替・併用手法
- Function Calling - LLMが検索処理などの外部ツールを呼び出す仕組み
- AIエージェント - Agentic RAGの土台となる自律的タスク実行の枠組み
- NLP（自然言語処理） - RAGが属する技術分野全体
- 生成AI（Generative AI） - RAGが実用性を高める対象となる上位概念
- Transformer - リトリーバー・ジェネレーター双方の基盤アーキテクチャ
- Large Language Model - LLMの正式名称・詳細解説
この用語についてもっと詳しく
RAG（Retrieval-Augmented Generation）に関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。
よくある質問（FAQ）
Q. RAG（Retrieval-Augmented Generation）とは何ですか
大規模言語モデル（LLM）が回答を生成する前に、社内文書やWebページなど外部の知識ソースから関連情報を検索し、その検索結果を根拠として回答を生成する技術です。LLM単体では扱えない社外秘の情報や、学習データのカットオフ以降の最新情報を回答に反映できる点が特徴です。
Q. RAGとファインチューニングはどう違いますか、どちらを選ぶべきですか
ファインチューニングはモデル自体の重みを追加学習で更新する手法で、文体・口調・専門用語の言い回しを覚えさせるのに向きます。一方RAGはモデルを変えずに参照文書を検索する手法で、知識の更新・追加に向きます。情報が頻繁に更新される業務にはRAG、特定の話し方・フォーマットを再現したい場合はファインチューニング、というのが実務上の使い分けの目安で、両者を併用するケースも珍しくありません。
Q. RAGを導入すればハルシネーションは完全になくなりますか
いいえ、完全にはなくなりません。RAGはあくまで「回答の根拠となる文書を検索して提示する」仕組みであり、検索精度が低く見当違いの文書がヒットした場合や、LLMが検索結果を無視して独自の内容を生成してしまった場合には、誤情報が生成されるリスクは残ります。重要な業務では、回答に添えられた根拠文書を人が確認する運用と組み合わせることが推奨されます。
Q. RAGの検索精度を上げるにはどうすればよいですか
代表的な改善策として、文書の分割単位（チャンクサイズ）を内容に合わせて調整すること、意味検索とキーワード検索を組み合わせるハイブリッド検索を採用すること、検索結果を再評価して絞り込むリランキングを挟むこと、実際の質問例を使った定量評価を継続的に行うことが挙げられます。検索精度がRAG全体の回答品質の上限を決めるため、生成側のプロンプト調整だけでは限界があります。
Q. ロングコンテキストLLMが普及すればRAGは不要になりますか
コンテキストウィンドウが拡大した近年のLLMであれば、比較的小規模な文書群はまるごと入力する運用も可能になってきています。ただし、対象文書量が大きくなるほどトークン課金や応答速度の面で非効率になりやすく、大規模な知識ベースを扱う場面では引き続きRAGによる事前絞り込みが有効というのが実務的な見方です。両者は対立技術ではなく、組み合わせて使われることも増えています。
Q. Agentic RAGやGraphRAGとは何ですか
Agentic RAGは、LLM自身が検索結果の十分性を判断し、必要に応じて検索クエリを言い換えて再検索するなど、AIエージェントの考え方を取り入れて検索プロセスを自律的に制御する構成を指します。GraphRAGは、文書からエンティティ間の関係性を抽出したナレッジグラフを検索対象に加える手法で、単純なベクトル検索では拾いにくい横断的な質問への対応力向上を狙ったアプローチです。いずれも2024年以降に注目が高まっている発展形です。
Q. RAGを構築する際に最初につまずきやすい点は何ですか
プロトタイプ自体は少ないコードで動かせますが、実運用では「検索結果が質問と微妙にずれている」「専門用語の表記ゆれで検索漏れが起きる」といった検索精度の問題に直面しやすい点です。チャンク分割の粒度、ハイブリッド検索の導入、リランキングの追加など、生成部分より検索部分のチューニングに時間をかける必要があることを想定しておくと、導入計画が立てやすくなります。