「LLMに自社のデータを使わせたい」という相談で、ほぼ必ず登場する三文字がRAGです。本ガイドでは「RAGとは何か」を仕組みからやさしく解説し、なぜ多くの企業が採用しているのか、ファインチューニングとどう選ぶのか、そして実務に落とし込むときに押さえるべき勘所を整理します。

RAG（検索拡張生成）とは

RAGは Retrieval-Augmented Generation の略で、日本語では「検索拡張生成」と訳されます。ひとことで言えば、大規模言語モデル（LLM）に外部の知識ベースから関連情報を検索して取り込ませ、その内容を踏まえて回答を生成させる枠組みです。モデル本体は学習し直さず、回答するそのときに「根拠となる資料」を手元に渡してから答えさせる、というイメージが近いでしょう。

素のLLMは、学習した時点までの知識しか持っていません。そのため最新の社内規程や、そもそも学習データに含まれない自社固有の情報には答えられず、知らないことをもっともらしく埋めてしまう「ハルシネーション（幻覚）」も起こします。RAGは、この欠点を「外から最新の根拠を足す」という形で補う発想です。

仕組み：検索 → 文脈注入 → 生成

RAGの動きは、大きく次の流れで理解できます。

  • ① 検索（Retrieval）：利用者の質問を受け取り、社内文書などの知識ベースから関連しそうな箇所を探し出します。
  • ② 文脈注入（Augment）：見つかった文章を、質問とあわせてプロンプト（LLMへの指示文）に差し込みます。
  • ③ 生成（Generation）：LLMが、その渡された文脈を踏まえて回答を作ります。

この「検索した結果を文脈として注入してから生成する」という一連の流れこそが、Retrieval-Augmented（検索で拡張された）Generation（生成）という名前の由来です。

下準備：埋め込み・チャンク・ベクトル検索

①の検索を賢く行うために、事前の仕込みがあります。まず社内文書を扱いやすい大きさに分割します。これをチャンク化と呼びます。文書まるごとではなく、関連する一部分だけを取り出せるようにすることで、回答の精度を上げつつ、LLMに渡す分量（=コスト）も抑えられます。

次に、各チャンクを埋め込み（エンベディング）という処理で数値のベクトルに変換し、ベクトルデータベースに保存します。埋め込みは「文章の意味」を座標のように数値化したもので、意味が近い文章どうしはベクトルも近くなります。質問が来たら質問側もベクトル化し、意味的に近いチャンクを探す——これがベクトル検索（セマンティック検索）です。キーワードが完全に一致していなくても、意味の近い箇所を拾える点が、従来の単語一致検索との違いです。なお実務では、キーワード検索とベクトル検索を組み合わせる「ハイブリッド検索」もよく使われます。

なぜ企業はRAGを使うのか

RAGが企業で広く採られるのには、いくつかのはっきりした理由があります。

  • 最新・自社固有の情報を扱える：規程・製品ドキュメント・障害報告・運用手順書など、頻繁に変わる社内コンテンツに根ざした回答を返せます。情報が古くなったら、モデルを再学習せず知識ベース側を更新すればよいだけです。
  • ハルシネーションを抑えやすい：回答時に外部の根拠を取り込むため、モデルの知識の境界を補い、推測で埋める場面を減らせるとされています。
  • 出典を示せる：どの文書を根拠にしたかを提示できる構成にすれば、利用者が回答を検証でき、信頼につながります。
  • 大量の文書に強い：ベクトル検索は、膨大なチャンクの中からLLMに読ませる少数の候補へと素早く絞り込めます。

RAGとファインチューニング、どう選ぶ

「自社データでLLMを使う」もう一つの代表的な方法がファインチューニングです。両者は競合というより、役割が違います。

RAGはモデルを固定したまま、回答時に関連するテキストをプロンプトへ取り込む方式です。一方ファインチューニングは、学習済みモデルを自社データで追加学習させ、知識や振る舞いをモデルのパラメータ自体に焼き込みます。一般的な整理としては、頻繁に変わる知識はRAGに任せ、口調・指示への従い方・出力形式の安定といった「振る舞い」はファインチューニングで整える、という分担が分かりやすいでしょう。実際には、事実はRAGで供給し、形式の安定はファインチューニングで担保する、という両者を組み合わせたハイブリッド構成も少なくありません。

機密データの観点でも、RAGには利点があります。社内データを第三者のモデル学習に渡さず、安全な知識ベースに置いたまま、回答時にだけ参照させる設計が取りやすいためです。

RAGとファインチューニングの対比

項目 RAG（検索拡張生成） ファインチューニング
主な目的・役割 頻繁に更新される知識・事実の外部供給 モデルの口調・応答形式・振る舞いの固定化
モデル更新の必要性 不要（検索用知識ベースのみ更新） 必要（追加学習による重みの書き換え）
根拠の提示・ハルシネーション 検索した根拠文章を出典として提示可能 モデルのパラメータに焼き込まれるため出典提示は困難

企業導入の勘所

RAGは「LLMに検索をくっつければ完成」というほど単純ではありません。実務では、次の三点が成否を分けやすいポイントです。

  • データ整備：回答の質は、検索で取り込む情報の質に直結します。古い文書・重複・表記ゆれが混ざっていれば、その分だけ回答も揺らぎます。チャンクの切り方や、検索しやすい形への整理が出発点になります。
  • アクセス権限：利用者によって見てよい文書が異なる場合、その権限を検索の段階で反映する必要があります。ここを設計し忘れると、本来見えてはいけない情報が回答に紛れ込みかねません。
  • 評価（の継続）：回答が本当に根拠に基づいているか、関連する文書を取りこぼしていないかを継続的に測る仕組みが要ります。一度作って終わりではなく、検索精度と回答品質をモニタリングしていく前提で設計するのが現実的です。

RAGは、LLMという強力なエンジンに「自社の正しい情報」を供給する配管のような存在です。だからこそ、どんなデータを、どんな権限で、どう検索して渡すか——その設計が成果を左右します。

関連ツール

RAGの実装や運用に役立つ主要なOSSフレームワークの客観的な健全性データ（活発さや最新リリース状況）を確認できます。

  • langchain（LLMと外部ツールを繋ぐ開発フレームワーク）
  • llama-index（データ接続に特化したフレームワーク）
  • chromadb（AI向けのベクターストア）

関連ガイド

AIアプリを外部のツール・データソースへつなぐ標準規格はMCP（Model Context Protocol）とは、自社運用しやすいモデルの選択肢はオープンウェイトLLMとはもどうぞ。他の解説はガイド一覧から、最新動向はAIカテゴリでご覧いただけます。