RAG（検索拡張生成）とは？仕組み・構成・法人活用の完全ガイド

RAG（検索拡張生成）とは何か

RAG（Retrieval-Augmented Generation）は、LLM（大規模言語モデル）の回答生成に外部の知識検索を組み合わせる手法です。2020年にMeta AI Research（当時Facebook AI Research）が発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」が起源で、現在では法人向けAI導入の中核技術になっています。

通常のLLMは学習データの知識しか持ちません。GPT-4oやClaude 3はそれぞれ学習カットオフがあり、社内規程・最新製品情報・直近の議事録といった情報を持っていません。RAGはこの問題を「質問に関連する文書をリアルタイムで検索し、その文書を文脈として渡す」ことで解決します。

結果として、モデル自体を再学習することなく、自社固有の情報に基づいた正確な回答が可能になります。これがRAGが「コスト効率の高い知識活用手法」として注目される理由です。

LLMとRAGの根本的な違い

通常のLLM（ChatGPT等）に「弊社の就業規則での有給申請手順は？」と聞いても、モデルは学習データにないため回答できません。RAGを使うと、質問に対して社内文書DBを検索し、「就業規則 第○条」の該当箇所を取得してから回答を生成します。モデルが「知っている」のではなく、「検索して確認してから答える」構造が特徴です。

RAGの仕組み：検索・拡張・生成の3ステップ

RAGのパイプラインは「Retrieval（検索）」「Augmentation（拡張）」「Generation（生成）」の3ステップで構成されます。

Step 1: Retrieval（関連文書の検索）

ユーザーの質問をEmbeddingモデル（text-embedding-3-small等）でベクトル化し、ベクトルDBに対して類似度検索を実行します。コサイン類似度やドット積を使い、質問に意味的に近い文書チャンクを上位k件（通常3〜10件）取得します。

• Sparse検索（BM25/TF-IDF）：キーワード一致重視。専門用語・固有名詞に強い
• Dense検索（Embedding類似度）：意味的類似性重視。言い換え・同義語に強い
• Hybrid検索：両者を組み合わせてRRF（Reciprocal Rank Fusion）でスコアリング。本番推奨

Step 2: Augmentation（コンテキスト拡張）

検索で取得した文書チャンクをプロンプトに組み込みます。「以下の文書を参考に回答してください：\n\n[取得文書1]\n[取得文書2]\n\n質問：{ユーザー質問}」という形式が基本です。GPT-4oのコンテキスト長128Kトークンを活用し、複数文書を同時参照できます。

Step 3: Generation（回答生成）

拡張されたプロンプトをLLMに渡し、取得した文書に基づいた回答を生成します。適切なシステムプロンプトで「文書に記載のない情報は推測で答えない」という制約を設けることで、ハルシネーション（事実と異なる回答）を抑制できます。引用元の文書IDを回答に含める設計にすると、ユーザーが原典を確認できて信頼性が向上します。

RAGの構成要素：4つの技術コンポーネント

RAGシステムを構築するには4つの主要コンポーネントを理解する必要があります。

Embeddingモデル（文書ベクトル化）

テキストを多次元ベクトル（1536次元等）に変換するモデル。OpenAI text-embedding-3-small（$0.02/1Mトークン）が費用対効果に優れます。日本語精度を重視する場合はcl-nagoya/sup-simcse-jaやtext-embedding-3-large（3072次元）も選択肢です。文書の事前インデックス化時と質問ベクトル化時に使用します。

ベクトルDB（インデックス・検索エンジン）

ベクトルデータを高速に近傍検索するためのデータベース。主要選択肢を比較します。

チャンキング（文書分割）

長い文書をLLMのコンテキストウィンドウに収まるサイズに分割する処理。チャンクサイズは検索精度に直結します。

• Fixed-size chunking：500〜1000トークンで均等分割。実装が簡単だが文脈が切れる場合がある
• Recursive character splitting：段落→文→単語の順に自然な区切りで分割。LangChainのデフォルト
• Semantic chunking：意味的な区切りで分割。精度高いが計算コストが上がる
• オーバーラップ：隣接チャンク間で100〜200トークン重複させて文脈の切断を防ぐ

LLM（回答生成エンジン）

検索結果を受け取り最終回答を生成するモデル。RAGでは検索精度が高いほどLLMへの依存度が下がるため、コスト重視ならGPT-4o miniやClaude 3 Haikuも有効です。日本語文書を扱う場合はGPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Proのいずれかが実績豊富です。

RAGの法人活用パターン4選

法人でRAGが最も活用されているユースケースを4つ紹介します。

社内文書検索・ナレッジベース

最も普及しているユースケース。社内規程・マニュアル・製品仕様書・過去議事録をRAGのソースとして、従業員がチャットで質問できる仕組みです。Confluence・SharePoint・Notionとの連携が多く、情報検索時間を平均40〜70%削減した事例が多数あります。構築費用の目安は月5〜30万円（SaaS型）または初期200〜500万円（カスタム構築）。

顧客対応FAQ自動応答

製品FAQ・利用規約・サポート履歴をRAGソースとして、カスタマーサポートチャットボットに活用。GPT-4oのような汎用LLMだけでは自社製品の詳細に回答できないため、RAGが必須となります。応答精度が高まることで有人対応へのエスカレーション率が20〜40%低下します。

契約書・規約チェック

法務部門での活用が急増しています。契約書テンプレートや過去の契約事例をRAGソースとして、「この条項は弊社標準と異なるか」「同様の条件で過去締結した事例はあるか」を自動チェック。弁護士事務所での活用も進んでいます。機密性が高いため、オンプレミスのLlamaやMistralと組み合わせる事例も多くあります。

議事録・報告書の横断分析

過去の会議議事録や週次報告書をRAGで検索可能にし、「過去1年で○○プロジェクトに関して議論された内容をまとめて」といった横断分析が可能になります。Notion AI・Slackのサーチ機能の上位互換として機能します。

RAG構築の費用相場と期間

RAGの構築形態は大きく「SaaS型（ノーコード）」と「カスタム構築」に分かれます。

月次ランニングコストの主な内訳：ベクトルDB費用（月1〜5万円）、Embedding API費用（月0.5〜5万円）、LLM API費用（月5〜30万円）、サーバー・インフラ費用（月2〜10万円）。

RAG vs ファインチューニング：用途別比較

RAGとファインチューニングは、どちらも「LLMに特定の知識・スタイルを持たせる」手法ですが、仕組みと適用場面が大きく異なります。

結論として、「情報を検索して答えたい」ならRAG、「一定のスタイル・形式で出力したい」ならファインチューニングが適しています。詳細はファインチューニング完全ガイドを参照してください。

RAG導入の注意点と対策

RAGを本番環境で運用する際に必ず対処すべき課題を3点説明します。

ハルシネーション対策

RAGはハルシネーションを「抑制」しますが「ゼロ」にはできません。対策として：（1）システムプロンプトで「提供文書以外の情報で回答しない」と明示する、（2）「情報が見つかりませんでした」という応答パターンを設計する、（3）回答に引用元（文書名・ページ番号）を必ず付与する、（4）重要回答の事後サンプリング検証を月次で実施する。

検索精度の問題

RAGの回答品質は検索精度に直結します。典型的な問題と対策：（1）チャンクサイズが大きすぎ→チャンクを500トークン以下に細分化する、（2）表形式データが検索されない→テーブルをテキスト形式（Markdown）に変換してインデックス化する、（3）日本語の表記ゆれ→形態素解析（MeCab）を前処理に追加する。

データ鮮度の管理

ベクトルDBのデータが古くなると誤った情報を回答します。対策：（1）文書更新時に自動でEmbeddingを再生成するパイプラインを構築する、（2）各チャンクにタイムスタンプを付与し、古いデータをスコアで減点する、（3）月次でインデックスの全量再構築を自動化する。コスト管理についてはAI APIコスト制御ガイドも参照してください。