RAG（検索拡張生成）とは何か：社内データをAIに使わせる仕組みと限界

RAGとは、質問に答える前にAIが自社の文書を検索し、見つかった内容を根拠として回答を生成する仕組みです。 モデル自体を作り変えるファインチューニングとは異なり、外部の情報源を都度参照する点が本質的な違いになります。「社内マニュアルを検索して答えてくれるチャットボット」の多くはこの仕組みで動いています。

RAG（Retrieval-Augmented Generation、検索拡張生成）は、生成AIを企業データに接続する際の最も一般的な設計パターンです。しかし「導入すれば社内の情報検索が解決する」という期待とは裏腹に、実際に触ってみると期待どおりに機能しないという声が多く聞かれます。本稿では、RAGの定義と仕組みを整理した上で、精度を左右する要因と、導入前に確認すべき判断軸を解説します。技術リテラシーとしてRAGを理解しておくことは、AI活用の投資判断を誤らないための土台になります。

RAGの定義：ファインチューニング・長文コンテキストとの違い

LLM（大規模言語モデル）に企業固有の情報を使わせる方法は、大きく3つに分類できます。

方式	やること	向いている用途	弱点
RAG	質問に関連する文書を検索し、その内容をプロンプトに含めて生成	更新頻度が高い情報、出典提示が必要な用途	検索精度に品質が依存する
ファインチューニング	追加データでモデルのパラメータ自体を再学習	話し方・専門用語・振る舞いの調整	情報更新のたびに再学習が必要、コストが高い
長文コンテキスト	関連文書をすべてプロンプトに直接貼り付ける	対象文書量が少なく限定的な場合	文書量が多いとコスト・速度・精度が悪化する

3方式のうち、RAGが企業導入で最も選ばれやすい理由は明確です。社内規定・マニュアル・議事録は日々更新され、モデルを再学習するファインチューニングでは追従コストが見合いません。また「なぜその回答になったか」を検証する必要がある業務（コンプライアンス確認、顧客対応の根拠提示など）では、参照した文書を明示できるRAGの構造が実務的に有利です。

一方で誤解しやすいのは、RAGが「モデルを賢くする技術」ではないという点です。RAGはモデルの知識そのものを増やしているのではなく、質問のたびに関連情報を外部から調達し、モデルに「この範囲で答えてください」と指示しているにすぎません。この理解を欠くと、後述する「期待どおり動かない」問題の原因を見誤ります。

仕組み：文書分割 → 埋め込み → 検索 → 生成の4ステップ

RAGの内部処理は、大きく4つのステップに分解できます。

STEP1：文書分割（チャンキング） 就業規則やマニュアルなど、長い文書をそのまま検索対象にすると、関連度の低い部分まで一緒に取得されてしまいます。そのため文書を意味のまとまり（数百〜千文字程度）で断片（チャンク）に分割します。分割の粒度と切り方が、後述する精度に直結する最初の分岐点です。

STEP2：埋め込み（Embedding） 各断片を、意味の近さを数値で表現した「ベクトル」に変換します。「有給休暇」と「年次休暇」のように表記が違っても意味が近い言葉を、ベクトル空間上の近い位置に配置する処理です。変換されたベクトルはベクトルデータベースに蓄積されます。

STEP3：検索（Retrieval） ユーザーの質問も同じ方式でベクトル化し、蓄積された断片の中から意味的に近いものを上位数件取得します。ここがRAGの名前の由来である「検索拡張」の中核です。

STEP4：生成（Generation） 取得した断片を「この情報をもとに答えてください」という指示とともにLLMに渡し、回答を生成させます。LLMは自身が学習時に持っていた知識ではなく、渡された断片の範囲内で回答することが期待されます。

精度を左右する4つの要因

RAGの回答精度は、モデルの性能よりも前後の設計に大きく依存します。実務で問題が出やすい順に整理します。

1. データ整備：検索対象がそもそも整理されているか

RAGは「存在する文書」しか検索できません。最新版と旧版のマニュアルが混在している、部署ごとに表記ゆれがある、口頭で伝達されているルールが文書化されていない——といった状態では、検索精度以前に正解となる文書自体が存在しないため機能しません。この課題の構造は中小企業のAI活用はどこから始めるかで詳しく扱っています。

2. チャンク分割：粒度と切り方

分割が粗すぎると無関係な情報が混入し、細かすぎると文脈が失われます。例えば「有給休暇の繰越ルール」が条文の後半にあり、前提条件が前半にある場合、機械的に文字数で分割すると前提条件だけが検索結果から漏れることがあります。見出し構造や段落単位を尊重した分割が必要です。

3. 検索品質：意味は近いが答えではない断片を拾う問題

ベクトル検索は「意味が近い文章」を探す技術であり、「正解を含む文章」を探す技術ではありません。「有給休暇の繰越」という質問に対し、「有給休暇の取得申請方法」という意味的に近いが答えを含まない断片が上位に来ることがあります。これを緩和する手法として、検索結果を再評価する「リランキング」や、キーワード検索とベクトル検索を組み合わせる「ハイブリッド検索」があります。

4. 評価：定量的に精度を測定しているか

「なんとなく良さそう」で運用を続けると、精度低下に気づけません。想定質問と正解文書のペアをテストセットとして用意し、検索結果に正解文書が含まれる割合（Recall）や、生成された回答が正解と一致する割合を定期的に測定する体制が必要です。評価の枠組みがないままモデルだけを新しくしても、体感精度は改善しません。

「社内Botが期待どおり動かない」典型原因

RAGを使った社内問い合わせBotを導入した企業から共通して聞かれる不満は、以下のパターンに集約されます。

質問の言い回しによって回答の質がばらつく これは検索段階の問題であることが多いです。「有給の繰越」と「有休はいつまで使える」のように表現が変わると、ベクトル検索がヒットする断片も変わります。表記ゆれを吸収する検索設計、または想定される言い回しのバリエーションをあらかじめ登録しておく工夫が有効です。

古い情報を根拠に答えてしまう 検索対象のドキュメントを更新しても、埋め込み処理（STEP2）を再実行しない限り検索結果には反映されません。文書更新とベクトルDBの再構築を連動させる運用フローが抜けているケースが多く見られます。

もっともらしいが誤った回答をする（ハルシネーション） 検索で取得した断片が質問と無関係だった場合、LLMはその断片から無理に回答を作り出すことがあります。「該当する情報が見つかりません」と正直に答えさせるためには、検索結果の関連度が一定の閾値を下回った場合に生成を止めるプロンプト設計が必要です。

そもそも検索対象の文書が古いExcelや紙にしかない これはRAG導入以前の課題です。文書化されていない業務知識をRAGで検索することはできません。

導入判断のチェックリスト

RAG導入を検討する際、着手前に以下を確認することを推奨します。

• 検索対象にしたい情報は、そもそも文書として存在しているか（口頭伝承・担当者の頭の中だけの情報ではないか）
• 文書の版管理・更新頻度は把握できているか（更新のたびにベクトルDBを再構築する運用は誰が担うか）
• 「わからない場合はわからないと答える」設計を組み込めるか
• 精度を定量的に測るテストセット（想定質問と正解文書のペア）を用意できるか
• 導入後、誰が継続的にチューニング（チャンク分割・検索方式の見直し）を担当するか

これらのうち特に最初の2つが未整備な状態でRAGを導入すると、技術的には正しく動いていても「期待した回答が返ってこないシステム」になりがちです。RAGはデータ整備とセットで検討すべき技術であり、この観点はLLM/AIをプロダクトに組み込む際のアーキテクチャ判断軸でも扱っている、精度要件とコストのトレードオフの一部です。ベクトルデータベースの選定や運用コストを考える際は、データベースの基礎で整理した「事業上の意思決定」としての視点も参考になります。

社内のデータ整備状況を棚卸しした上で、どこから着手すべきか判断に迷う場合は、現場に入って業務とデータを一緒に確認する伴走型の支援が有効な場面もあります。