RAGとは？社内資料をAIに読ませる仕組み
画像出典: 写真: Carl Lender from Sunrise, USA（CC BY 2.0 / Wikimedia Commons）
RAG（Retrieval-Augmented Generation／検索拡張生成）は、質問に関係する文書を先に検索し、その文書を質問文と一緒にAIへ渡してから答えさせる仕組みです。AIが社内資料を「覚えている」のではなく、答える直前に資料を手渡されているだけなので、回答の質は検索の精度と資料そのものの質に強く左右されます。回答がずれたときは、検索が拾えていないのか、渡した資料を無視してAIが作文したのかを切り分けるのが最初の一手です。
AIが社内資料を覚えたわけではありません。質問が届いた瞬間に別の仕組みが資料を検索し、見つかった数ページ分を質問文とセットでAIに手渡している——そのやり方が RAG（Retrieval-Augmented Generation、検索拡張生成）です。
この違いは細かい言葉遊びではありません。「覚えている」なら記憶違いを疑いますが、「手渡している」なら、渡す前の検索を疑うことになります。原因の探し方がまるごと変わるんです。
仕組みを一度おさえておくと、導入の判断も、うまく答えられないときの相談も、ぐっと具体的になります。
RAGとは何か？ひとことで言うと
RAG は、大規模言語モデル（LLM）が文章を生成するときに、外部のデータベースを検索する機能を組み合わせて出力の精度を上げる技術です。日本語では検索拡張生成、または取得拡張生成と呼ばれます。
AWS の公式ガイダンスは、RAG を「LLM を外部データ（たとえば企業の社内文書）で拡張する技術であり、その企業固有の用途に対して正確で有用な出力を生成するために必要な文脈をモデルに与えるもの」と説明しています。ここで出てくるコンテキスト（文脈）とは、AI が答えを作るときに目の前に置かれている材料のことです。
身近な例に置き換えると、閉架式の図書館のレファレンスカウンターに近い形です。利用者が質問すると、司書が書庫から関係のありそうな本を数冊持ってきて、担当者はその本を見ながら答える。担当者は蔵書をすべて暗記しているわけではなく、手元に運ばれてきた数冊の範囲で答えている——RAG での AI の立場はこれです。
RAGはどう動いている？検索・拡張・生成の3ステップ
名前のとおり、処理は大きく3つに分かれます。
- 検索（Retrieval）ユーザーの質問に対して、社内ドキュメントやナレッジベースなどの外部データソースから、関連する情報を探し出します。
- 拡張（Augmentation）見つかった情報を、ユーザーの質問文と一緒に生成AIへ入力します。ここが「拡張」と呼ばれる部分です。
- 生成（Generation）生成AIが、提示された根拠を踏まえて自然な文章で回答を作ります。
注目してほしいのは、AI が資料に触れるのが3ステップ目の直前だという点です。1と2をやっているのは AI 本体ではなく、その前段に置かれた検索の仕組みです。
検索の前に、文書は「数の並び」に変換されている
1ステップ目の検索を成り立たせるために、社内文書はあらかじめ埋め込み（embedding）という処理でベクトルデータベースに取り込まれています。埋め込みとは、テキストの意味的・文脈的な内容を捉えた数値表現のことです。
文章を数の並びに変えておくと、数値どうしの近さで「意味が近い文書」を判定できるようになります。だから「有給の繰り越し」と検索したときに、その言葉が一度も出てこない「年次有給休暇の取扱いについて」という文書を拾ってこられるわけです。単語の一致ではなく、意味の近さで探しているからです。
埋め込みそのものの中身については、言葉を数の並びに変える仕組みの記事で詳しく扱っています。RAG の精度を左右する土台なので、深掘りする価値のある部分です。
普通の生成AIと何が違う？
通常の LLM は、学習済みの知識の範囲内で回答を作ります。これに対して RAG は、事前に用意した社内文書や外部ソースを根拠として絞り込み、それに基づいて回答を作ります。
| 通常のLLM | RAG | |
|---|---|---|
| 答えの材料 | 学習済みの知識 | 学習済みの知識＋検索で渡された文書 |
| 社内固有の情報 | 知らない | 検索で拾えれば答えられる |
| 資料の更新 | モデル側の学習が必要 | データベースを更新すれば反映 |
| 精度を左右するもの | モデルの性能 | モデルの性能＋検索の精度＋資料の質 |
3行目が、実務では地味に効いてきます。社内規程が改定されたとき、RAG ならデータベース側の文書を差し替えれば次の質問から新しい内容で答えられます。モデルを学習し直す必要はありません。
そして4行目が、このあとの話の中心になります。RAG の回答品質は、AI の賢さだけでは決まりません。
RAGの弱点はどこにある？
導入してみて「思ったほど答えてくれない」となるケースは珍しくありません。原因は、だいたい次の3つに分類できます。
1. 検索精度に強く依存する
RAG の回答の質は、検索精度に強く依存します。検索が必要な情報を集められなければ、AI は不十分な材料のまま答えを作ることになり、誤情報の混入や現場の混乱、そこまでの投資が無駄になるリスクにつながります。
図書館の例に戻すと、司書が持ってきた本が見当違いなら、どれだけ優秀な担当者でもまともな回答は作れません。AI を高性能なものに替えても、この問題は解決しません。
2. データベースの質に引きずられる
回答品質は、ナレッジベースそのものの質にも左右されます。過去の情報や重複したデータが多いと、誤った情報を選んでしまうリスクが高まります。
ありがちなのが、旧版と新版の規程が両方入っているケースです。検索としては両方とも「関連あり」と判定されるので、AI は矛盾する2つの資料を渡されることになります。捨てるべき文書を捨てる作業が、実は精度改善の一番の近道ということが起こります。
3. 検索は正しいのに回答が不正確なことがある
「検索は正しく機能しているのに回答が不正確」というケースもあります。これは検索側ではなく、LLM 側がハルシネーション（事実に基づかない内容をもっともらしく生成してしまう現象）を起こしていることを示します。検索精度と生成精度は、別の問題です。
だからこそ、うまくいかないときは切り分けが要ります。
回答がずれたとき、どこを疑えばいい？
やることは1つです。AI に「その回答の根拠になった文書を見せて」と聞く。多くの RAG 製品は参照した文書名や該当箇所を表示できるようになっています。
- 関係ない文書が並んでいる → 検索側の問題。質問の言い回し、または文書の分け方を見直す
- 正しい文書が出ているのに回答が違う → 生成側の問題。ハルシネーションを疑い、プロンプトや設定を確認する
- そもそも該当文書が存在しない → データ投入の問題。その資料が取り込まれているかを確認する
- 古い版と新しい版が両方出ている → データベース整理の問題。旧版を除外する
この4分類ができるだけで、社内の担当者やベンダーへの相談が「なんか精度が悪い」から「検索は当たっているのに生成がずれています」に変わります。伝わり方がまったく違います。
逆に言えば、根拠文書を提示できない仕組みは、この切り分けができません。導入時に確認しておきたいポイントの1つです。
RAGを構成する要素と、忘れがちなセキュリティ
AWS のガイダンスは、RAG の技術的な構成要素を次のように整理しています。
- Foundation model：コンテキストとプロンプトを処理し、回答を生成・整形する LLM
- Guardrails：クエリ・プロンプト・検索されたコンテキスト・LLM の応答が、正確で責任ある倫理的なものであり、ハルシネーションやバイアスを含まないことを担保する仕組み
- Orchestrator：エンドツーエンドのワークフロー全体のスケジューリングと管理
AWS Prescriptive Guidanceの公表情報をもとに作成
AWS では Bedrock、Kendra、OpenSearch Service などが RAG パイプラインを構築するサービスとして提供されています。
ここで見落とされやすいのが、情報セキュリティへの配慮です。RAG は社内文書を扱う以上、アクセス制御やガードレールの設計が求められます。
資料そのものが整理されていない状態で RAG を入れても、期待した結果にはなりにくいです。旧版が残っている、同じ内容の文書が何十個もある、口頭で運用していて文書化されていない——こうした状態では、検索が拾ってくるものが不安定になります。
また、部署ごとに閲覧権限が分かれている資料をまとめて取り込むと、権限のない人に情報が渡ってしまう可能性があります。アクセス制御の設計を後回しにできる仕組みではありません。「まず資料の棚卸しから」という結論になることは、実際によくあります。
導入を検討する前に、手元で確かめられること
いきなり社内システムを組む前に、感触をつかむ方法があります。手持ちの PDF を数本、生成AI のチャットにそのまま添付して質問してみることです。
これは厳密には RAG ではなく、資料を丸ごと渡しているだけの状態ですが、「資料を渡された AI がどう答えるか」の感触は近いものが得られます。
- 資料に書いてあることを、書いてあるとおりに答えられるか
- 資料に書いていないことを聞いたとき、「書かれていません」と言えるか（作文してしまわないか）
- 複数の資料にまたがる質問に答えられるか
- 表や図が多い資料でも読み取れているか
特に2つ目が重要です。書かれていないことを堂々と答えてしまうなら、それが RAG になっても同じことが起きます。資料の量が増えるぶん、むしろ気づきにくくなります。
この段階で見えてくる課題——資料の書き方、表の扱いにくさ、質問の粒度——は、本格導入したときにそのまま出てくるものです。小さく試して詰まったところが、そのまま設計の論点になります。
RAGを知っておくと、何が変わるか
RAG は、AI に社内の知識を持たせる万能の魔法ではありません。検索・拡張・生成という3つの工程が直列につながった仕組みで、どこか1つが弱ければ、そこが全体の上限になります。
逆に言えば、工程が分かれているからこそ、悪いところを名指しできます。検索なのか、資料なのか、生成なのか。この3択で考えられるようになるだけで、「AI が使えない」という漠然とした感想が、直せる課題に変わります。
仕組みを知ってから、自分の職場の資料がどの状態にあるかを眺めてみる。導入するかどうかを決めるのは、そのあとで十分です。
よくある質問
RAGとは何ですか？
RAG（Retrieval-Augmented Generation、検索拡張生成）は、LLMがテキストを生成する際に外部データベースを検索する機能を組み合わせ、出力の精度を向上させる技術です。ユーザーの質問に関連する文書を先に検索し、その文書を質問文と一緒にAIへ渡してから回答を生成させます。
RAGと普通の生成AIは何が違いますか？
通常のLLMは学習済みの知識の範囲内で回答を生成しますが、RAGは事前に用意した社内文書や外部ソースを根拠として絞り込み、それに基づいて回答を生成します。そのため、モデルを学習し直さなくても、データベース側の文書を更新すれば新しい情報で答えられるようになります。
RAGを導入すればAIが嘘をつかなくなりますか？
なくなりません。検索は正しく機能しているのに回答が不正確というケースがあり、これは検索側ではなくLLM側がハルシネーションを起こしていることを示します。検索精度と生成精度は別の問題なので、根拠として提示された文書と回答が一致しているかを確認する運用が必要です。
RAGの精度が上がらないとき、まず何を見ればいいですか？
AIが回答の根拠にした文書を確認します。関係のない文書が並んでいれば検索側の問題、正しい文書が出ているのに回答がずれていれば生成側の問題、旧版と新版が両方出ていればデータベース整理の問題と切り分けられます。RAGの回答品質は検索精度とナレッジベースの質に強く依存するため、モデルを変える前にこの3点を確認するのが先です。
※記事で使用した内容・数値は変更される場合があります。最新情報は公式サイトをご確認ください。