RAG（検索拡張生成）とは？仕組みと導入のポイント
ChatGPTのような生成AIに社内のマニュアルや過去の議事録について質問しても、学習していない情報については答えられません。この課題を解決する技術として近年注目されているのが「RAG（検索拡張生成）」です。仕組みを理解しておくと、AI開発会社との会話もスムーズになります。
RAGとは何か、通常のAIチャットと何が違うのか
RAG（Retrieval-Augmented Generation、検索拡張生成）とは、AIが回答を生成する前に、関連する情報を外部のデータベースから検索し、その検索結果を踏まえて回答を組み立てる仕組みです。
通常のAIチャットは、学習時点までの一般的な知識をもとに回答を生成しますが、自社の最新のマニュアルや非公開の社内文書については当然知りません。RAGを使うと、質問のたびに社内文書を検索し、その内容を根拠として回答できるようになるため、社内特有の情報にも対応できます。
ファインチューニングとの違い
社内特有の情報にAIを対応させる方法としては、RAGのほかに「ファインチューニング（追加学習）」という手法もあります。ファインチューニングはモデル自体に社内情報を学習させ直す手法である一方、RAGはモデル自体は変更せず、回答時に外部の文書を参照させる手法です。
ファインチューニングは学習コストが高く、情報の更新のたびに再学習が必要になるのに対し、RAGは参照する文書を差し替えるだけで最新情報に対応できるため、情報が頻繁に更新される社内文書との相性が良く、多くの企業でまず検討される選択肢になっています。
RAGの基本的な仕組み
RAGはおおまかに「検索」と「生成」の2段階で動作します。まずユーザーの質問を受け取ると、あらかじめベクトル化（数値化）して保存しておいた社内文書の中から、質問と意味的に関連性の高い文書を検索します。次に、検索でヒットした文書の内容を質問文と一緒にAIに渡し、その情報をもとに回答を生成させます。
この仕組みにより、AIは「学習した知識」だけでなく「検索で見つけた最新の根拠情報」を組み合わせて回答できるため、事実に基づいた正確な回答をしやすくなります。
ベクトル検索とキーワード検索の違い
従来のキーワード検索は、質問文に含まれる単語と文書内の単語が一致するかどうかで検索結果を決めます。一方、ベクトル検索は文章の意味を数値の集合（ベクトル）として表現し、意味的な近さで検索するため、質問文と文書で使われている言葉が完全に一致していなくても、意味が近い文書を見つけ出せます。
たとえば「有給休暇の申請方法」という質問に対して、文書内に「年次有給休暇の取得手続き」と書かれていた場合、キーワード検索では表記の違いからヒットしないことがありますが、ベクトル検索であれば意味的な近さから正しく検索結果に含めることができます。
文書の分割（チャンク化）という前処理
RAGを構築する際、社内文書をそのまま検索対象にするのではなく、一定の長さの単位（チャンク）に分割してからベクトル化するのが一般的です。1つの文書が長大な場合、丸ごと検索対象にすると関連性の低い部分まで含まれてしまい、AIの回答精度が下がる原因になります。
チャンクの分割方法（見出し単位で区切るか、一定の文字数で機械的に区切るか）は、回答精度に大きく影響する設計上のポイントです。この前処理の質が、RAGシステム全体の使い勝手を左右すると言っても過言ではありません。
回答の根拠を示す「引用元表示」機能
業務利用のRAGシステムでは、AIが回答を生成する際に、どの文書のどの部分を根拠にしたのかを合わせて表示する「引用元表示」機能を組み込むことが一般的です。回答だけを提示されるよりも、根拠となる文書箇所が分かることで、利用者が内容の正確性を自分で確認しやすくなり、AIの回答に対する信頼性も高まります。
引用元表示は、AIが誤った情報を作り出してしまう「ハルシネーション」のリスクを利用者側が発見しやすくする効果もあるため、社内向け・顧客向けを問わず、実務で使うRAGシステムには欠かせない機能の一つといえます。
RAGが向いている活用シーン
RAGは、社内のFAQ対応、マニュアル検索、契約書や規程集からの該当箇所の抽出、カスタマーサポートの一次回答など、「決まった情報源をもとに正確に答える」用途に特に向いています。
逆に、創造的な文章生成やアイデア出しのような、決まった正解のない用途にはRAGの効果は限定的です。自社がAIに何をしてほしいのかによって、RAGが適した構成かどうかが変わってきます。
単一文書源のシンプルなRAGと複数ソース統合型RAG
最もシンプルなRAGは、一つの文書群（例：規程集のみ）を対象に検索・回答する構成です。まずはこの単一ソース型から始め、精度や運用に慣れてから、複数のシステム（社内Wiki、過去の問い合わせ履歴、外部の公開情報など）を横断的に検索できる統合型RAGへと発展させていく進め方が現実的です。
複数ソースを統合する場合、情報源ごとに更新頻度や信頼度が異なるため、どの情報源を優先して回答に反映するかのルール設計も必要になり、単一ソース型に比べて開発・運用の難易度が高くなります。
社外向けカスタマーサポートへの応用
社内利用だけでなく、自社サービスのヘルプページやFAQを情報源としたRAGを、顧客向けのチャットボットに応用する動きも広がっています。この場合、社内利用時以上に「わからないことは正直にわからないと答える」設計が重要になります。顧客に誤った案内をしてしまうと信頼を損なうため、回答の確信度が低い場合は有人サポートへ引き継ぐ設計を組み込むことが推奨されます。
RAG導入で確認しておきたいポイント
RAGを導入する際は、単に技術を選定するだけでなく、運用面での準備も重要になります。
- 検索対象となる社内文書が整理・更新されているか（古い情報が混ざっていないか）
- 文書の更新時にRAGのデータベースへ反映する運用フローがあるか
- AIが「わからない」と答えるべき場面で、誤った情報を作り出してしまわないか（回答精度の検証）
- 検索対象データのアクセス権限（誰がどの文書を検索できるか）
古い文書が混在するリスクへの対処
社内文書には、更新されずに放置された古いマニュアルや、既に廃止された規程が残っていることがよくあります。RAGはこうした古い文書も等しく検索対象にしてしまうため、最新版と旧版が混在していると、AIが誤った情報を根拠として回答してしまうリスクがあります。
RAG導入をきっかけに、対象文書を棚卸しして最新版に一本化する作業を並行して行う企業も多く、この整理作業自体が導入プロジェクトの重要な一部になります。
導入コストと開発会社への相談ポイント
RAGシステムの構築は、対象文書の量や種類、社内システムとの連携範囲によって規模感が大きく変わります。まずは特定の部署・特定の文書群（例：カスタマーサポートのFAQのみ）に絞ってPoCとして始め、効果を検証してから対象範囲を広げていく進め方が一般的です。
開発会社に相談する際は、「どの文書を対象にしたいか」「どのくらいの回答精度を求めるか」を具体的に伝えられると、見積もりの精度も上がりやすくなります。
運用開始後の改善サイクルも見込んでおく
RAGは導入して終わりではなく、実際に利用者からの質問と回答の履歴を蓄積し、回答精度が低かった質問のパターンを分析して、文書の追加やチャンク分割の見直しを重ねていく運用が前提になります。導入時の見積もりだけでなく、運用開始後の改善作業にどの程度の工数・費用がかかるのかも、開発会社との相談時に確認しておくと、導入後の想定外のコストを防げます。
