RAG（検索拡張生成）

← 用語集トップへ戻る

RAG とは：LLM の最大の弱点を補う仕組み

RAG（Retrieval-Augmented Generation）は、Meta（旧 Facebook）の研究者が2020年に発表した手法で、現在は ChatGPT・Claude・Gemini などほぼすべての主要 LLM 活用基盤で標準的に採用されています。「Retrieval（検索）」と「Generation（生成）」を組み合わせた造語で、「質問が来たら、まず関連情報を検索して取得し、その内容を LLM に渡してから回答を生成する」という二段階アーキテクチャを指します。

LLM 単体には3つの大きな弱点があります。①学習データの時点で知識が止まっている（時間的制約）、②社内ドキュメントなどクローズドな情報は知らない（プライバシー的制約）、③知らないことを「知らない」と言わず適当に答えてしまう（ハルシネーション）。RAG はこの3つを同時に解決できるため、企業の実務に AI を組み込む際の事実上の標準構成となっています。

RAG とファインチューニングの違い

LLM をカスタマイズする方法として RAG とよく比較されるのがファインチューニング（追加学習）です。ファインチューニングは「モデル自体に知識を覚えさせる」アプローチで、計算コストが高く、更新するたびに再学習が必要。一方 RAG は「モデルは触らず、外部から情報を渡す」アプローチで、データ更新が即座に反映され、コストが低く、誰がどの情報を渡したかも追跡可能です。企業利用では RAG が主流、特殊な文体・専門知識の習得が必要なケースでファインチューニングという使い分けが定着しつつあります。

なぜ「ハルシネーション」を防げるのか

LLM がハルシネーションを起こす根本原因は、「知らないことを知らないと判断できない」確率的生成モデルだから。RAG では「外部から取得した情報のみを根拠に回答せよ」とプロンプトで制約をかけるため、未知の事柄に対しては「該当情報が見つかりません」と返せるようになります。回答の出典として参照ドキュメントを明示できる点も、企業利用での信頼性に直結します。

RAG の仕組み：3つのコア技術

ベクトルデータベース（Vector DB）

RAG の心臓部となる、文書を「意味的な近さ」で検索できるデータベース。各文書を「ベクトル（数値の配列）」に変換して保存し、質問もベクトル化して、ベクトル空間内で「近いもの」を検索します。Pinecone・Weaviate・Chroma・Qdrant などが代表的なサービスで、近年は PostgreSQL の pgvector 拡張も普及しています。「リンゴ」と「果物」のような、キーワード一致では見つからない関連性も検索できる点が特徴。

エンベディング（Embedding）モデル

文書や質問を「ベクトル」に変換する AI モデル。OpenAI の text-embedding-3-small、Google の textembedding-gecko、Cohere の embed-multilingual-v3 などがあります。日本語対応・コスト・精度を比較してプロジェクトに合うものを選びます。同じ意味の文章は近いベクトルになる性質を使って、検索精度が決まる重要な要素です。

チャンク分割と再ランキング

長文ドキュメントは「チャンク」と呼ばれる小単位（200〜1000トークン程度）に分割して保存します。チャンクサイズは検索精度と LLM への入力量のバランスで決まり、調整が必要です。検索した複数チャンクの中から本当に関連性が高いものを選び直す「再ランキング（リランク）」を入れると、回答精度が劇的に向上します。

RAG の典型的なユースケース

社内ナレッジ検索 Bot

就業規則・社内マニュアル・過去の議事録・ベテランの暗黙知などを RAG に組み込み、「人事規定の有給休暇の計算方法を教えて」「過去の似た案件の見積り根拠は？」のような質問に即座に答えるシステム。情シス・人事・経理など、問い合わせ対応に時間を取られる部署で効果が大きいです。

カスタマーサポート自動応答

製品マニュアル・FAQ・過去の問い合わせ履歴を RAG に登録し、顧客からの問い合わせに一次回答する Bot。「型番Aの保証期間は？」「エラーコードB123の対処法は？」のような定型質問を機械が処理し、複雑な案件のみ人間にエスカレーション。サポート工数を3〜5割削減した事例が多数報告されています。

営業提案資料の自動生成

過去の提案書・成功事例・業界レポートを RAG に登録し、「新規顧客X社向けの提案骨子を作成して」と指示すると、関連事例を参照しながら初稿を出力。営業マンの提案書作成時間を半分以下に短縮できるケースもあります。

法務・契約レビュー支援

過去契約書・法務メモ・社内ガイドラインを RAG 化し、新規契約書のレビュー時に「過去の類似条項」「リスク評価のメモ」を参照しながらコメント案を生成。法務部の業務効率化と、レビュー漏れ防止に貢献します。

RAG 導入のステップ

ステップ1：データソースの整備

RAG は入力する文書の質で回答品質が9割決まります。古い情報・矛盾する記述・PDFスキャン画像などは事前にクリーンアップ。最新版に統一し、社内のどの文書を AI に渡すかを明確にするデータガバナンスが導入の第一歩です。

ステップ2：ベクトル DB の選定と構築

規模・予算・既存システムとの親和性で選定。月額数千円から始められるマネージドサービス（Pinecone, Weaviate Cloud）か、自社サーバ運用の OSS（Chroma, Qdrant, pgvector）かの判断が最初の分かれ目です。

ステップ3：エンベディング・チャンク戦略

使用するエンベディングモデルとチャンクサイズを決定。日本語データなら多言語対応モデルを選択し、業務文書なら 300〜600 トークン程度のチャンクサイズが目安。実データで何種類か試してから本番投入が安全です。

ステップ4：プロンプト設計

「以下の参照情報のみに基づいて回答してください。参照情報に記載がない場合は『該当情報が見つかりません』と回答してください」のような厳格な指示を含めることで、ハルシネーションを抑制。回答末尾に出典を明示する指示も標準化されています。

ステップ5：評価・改善ループ

本番運用では「回答精度のモニタリング」が必須。サンプル質問100件程度で正答率・回答時間・コストを測定し、データ追加・チャンク調整・プロンプト改善のサイクルを回します。LangSmith・Phoenix などの可観測性ツールを併用すると効率的です。

RAG でよくある失敗パターン

データ整備をせずに丸投げ

「とりあえず全社のドキュメント全部入れれば賢くなる」という発想は失敗の典型。古いドキュメント・重複・矛盾が混在すると、RAGは矛盾した回答を平然と出します。事前のクレンジング（最新版確定、不要文書削除、メタデータ付与）に全工数の3〜5割をかけるのが現実的な配分です。

検索精度の評価をスキップ

「LLM が回答してくれているから動いてる」と思っていても、実は「関連の薄い文書を引っ張ってきて、それっぽく繕って答えているだけ」のパターンが頻発。質問→検索結果→回答の3点をログで追い、検索段階の精度（Recall・Precision）を定期測定する必要があります。

セキュリティ・権限管理の軽視

RAG に投入したデータは、検索でヒットすれば誰にでも回答内容として返ります。部門限定・役職限定の情報は権限管理を実装しないと、機密情報漏洩のリスクに直結。ユーザーごとにアクセス可能なベクトル空間を分ける設計が必須です。

← 用語集トップへ戻る