「社内の資料をAIに読ませて、質問すれば答えてくれるようにしたい」という要望は、多くの会社で最初に出てきます。その実現方式としてよく挙がるのがRAG（Retrieval-Augmented Generation／検索拡張生成）です。この記事では、RAGが何をする仕組みなのかを整理し、導入を検討する前に決めておくべきことを扱います。
対象は、業務改善の担当者、情報システムの担当者、社内のナレッジ管理を担う方です。実装方法ではなく、発注・検討の前に理解しておくべき前提に絞ります。
一文で言うと
RAGとは、質問に関係しそうな文書をまず検索し、その文書を材料として渡したうえでAIに答えさせる仕組みです。
この用語は、2020年にPatrick Lewisらが発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（arXiv:2005.11401、NeurIPS 2020）で提示されました。同論文では、事前学習済みのseq2seqモデルが持つパラメトリック記憶と、検索器を通じてアクセスする外部インデックス（同論文ではWikipediaの密ベクトルインデックス）というノンパラメトリック記憶を組み合わせる構成が示されています。
実務的に言い換えると、「AIが覚えていること」だけで答えさせるのではなく、「その都度、外の資料を引いてから答えさせる」ということです。
検索・取得・生成の3ステップ
| ステップ | やっていること | ここで失敗すると |
|---|---|---|
| 1. 検索（Retrieval） | 質問に関係しそうな文書を、社内文書のインデックスから探す | 関係する文書が候補に入らず、回答の材料が欠ける |
| 2. 取得（Augmentation） | 候補のうち上位数件を取り出し、AIへの入力に添える | 古い版や関係の薄い文書が材料になる |
| 3. 生成（Generation） | 渡された文書を材料に、AIが回答文を組み立てる | 材料にない内容を補って書いてしまう |
注目すべきは、1と2で取りこぼした文書は、3の材料には入らないという点です。ただし、材料に入らなかったからといってAIが黙るわけではありません。生成モデルは事前学習で得た知識（パラメトリック記憶）も併せ持っており、Lewis らの原論文も、この事前学習済みモデルと外部インデックスの併用としてRAGを定式化しています。
つまり検索が外れたときに起こるのは「答えが出ない」ことではなく、社内文書に根拠づいていない回答が、根拠づいた回答と同じ見た目で返ることです。利用者からは区別がつきません。だからRAGでは、回答に出典を必ず添える設計と、出典が実際にその内容を含むかを人が確認する運用が要ります。
ファインチューニングやキーワード検索との違い
| 方式 | 何をするか | 向いていること | 注意点 |
|---|---|---|---|
| RAG | その都度、外部文書を検索して材料に使う | 内容が更新される社内文書を扱う。根拠を示す | 検索設計が回答の根拠性を左右する。権限制御は機密性のために別途必須 |
| ファインチューニング | モデル自体を追加学習させる | 出力の形式・文体・振る舞いを寄せる | 更新のたびに再学習が要る。根拠の提示には向かない |
| キーワード検索 | 語の一致で文書を探す | 正式名称・型番など、語が確定している検索 | 言い換えや同義語に弱い |
実務では対立するものではなく、組み合わせて使われます。特にキーワード検索は「社内でしか使わない略語」に強く、RAGの検索段でキーワード検索を併用する構成は珍しくありません。「RAGにすればキーワード検索が不要になる」とは考えないほうが安全です。
もう一点、3方式のいずれを採ってもモデルが事前学習で得た知識は残ります。RAGは社内文書を「材料として足す」仕組みであって、モデルの知識を「置き換える」仕組みではありません。この区別は、次章の「自動的に解決しないこと」を読むうえでの前提になります。
RAGで改善し得ること
- 根拠を示せる：回答の材料に使った文書を提示できるため、利用者が原典に当たれる
- 更新が反映しやすい：文書を差し替えれば次回の検索から反映される。モデルの再学習を伴わない
- 社内固有の情報に答えられる：一般公開されていない規程・仕様・手順を材料にできる
- 権限に応じた出し分けができる（設計した場合に限る）：利用者の閲覧権限で検索対象を絞れる
4つ目に「設計した場合に限る」と付けているのは、これが自動では備わらないためです。次章で扱います。
RAGでは自動的に解決しないこと
RAGは「AIが嘘をつかなくなる仕組み」ではありません。検索で正しい文書が取れていても、生成の段階で材料にない内容を補うことは起こり得ます。「幻覚（ハルシネーション）をなくす」といった断定的な説明には注意してください。
誤取得
質問の言い回し次第で、関係の薄い文書が上位に来ることがあります。特に、似た構成の文書（過去の見積書、部署別の同名手順書など）が多い環境では起こりやすくなります。
古い文書
改訂前の版が残っていると、それが材料に選ばれることがあります。RAGは「どちらが最新か」を判断しません。版管理されていない文書群をそのまま対象にすると、古い規程に基づく回答が出ることがあります。
権限の漏れ
検索対象を利用者の閲覧権限で絞っていないと、本来アクセスできない文書の内容が回答の中に現れ得ます。ファイルサーバー側で権限が設定されていても、RAGの検索インデックス側が同じ制御を持っているとは限りません。これは仕組みの欠陥ではなく、設計しなければ実装されないという性質の問題です。権限の考え方はAIに渡す情報の管理と権限設計で扱った最小権限の枠組みがそのまま適用できます。
取り込んだ文書経由の指示混入
検索して取り出した文書の中に、AIへの指示のように読めるテキストが含まれていると、それが指示として解釈される可能性があります。社外から受け取ったファイルやWebページを取り込む構成では、この論点を検討対象に入れる必要があります。詳細はプロンプトインジェクション攻撃の実務リスクで扱っています。
導入前に決める3点
ツールの選定より前に決めておくと、後戻りが減ります。
1. 対象文書の範囲
- どのフォルダ・システムを対象にするか（全社の共有フォルダを丸ごと、は避ける）
- 版管理されているか。改訂前の版をどう除外するか
- 個人情報・顧客から預かった情報・営業秘密が含まれていないか
- スキャンPDFなど、テキストとして読めない文書がどれだけあるか
実務上、ここで一番時間がかかるのは文書の整理そのものです。RAGの導入プロジェクトが遅れる原因の多くは技術ではなく、対象文書が整っていないことにあります。
2. 権限の反映方法
- 利用者ごとの閲覧権限を、検索の段階でどう反映するか
- 人事異動・退職時に、権限の変更がどれだけ速く反映されるか
- 回答に出典を示すとき、閲覧権のない文書名を出さない設計になっているか
3つ目は見落とされやすい論点です。文書の中身を出さなくても、ファイル名が出るだけで情報になる場合があります（「○○社_買収検討_v3.xlsx」など）。
3. 良し悪しの評価方法
「体感で良くなった」では継続的な改善ができません。導入前に評価の形を決めておきます。
- 実際に社内で聞かれている質問を、主要な業務領域を一通り覆う範囲であらかじめ集めておく（件数より網羅性を優先する）
- それぞれに「正しい根拠文書はどれか」を人が決めておく
- 検索段で正しい文書が候補に入ったか（検索の評価）と、回答が正しかったか（回答の評価）を分けて見る
- 誤りが出たとき、検索の問題か生成の問題かを切り分けられるようにする
評価を検索と生成に分けるのが要点です。分けずに「回答の正答率」だけを見ると、改善すべき場所が分かりません。正しい文書が候補に入っていたのか、入っていたのに答えが違ったのかを切り分けられるようにしておくと、次に手を入れる場所が決まります。
リスク管理の枠組みを社内で整えたい場合、米国NISTが公表している「AI Risk Management Framework（AI RMF 1.0、2023年1月公表）」が参考になります。同フレームワークはGovern／Map／Measure／Manageという機能で構成されており、「測る（Measure）」を独立した機能として置いている点は、上記の評価設計の考え方と整合します。生成AIに特化した補助文書として、Generative AI Profile（NIST-AI-600-1、2024年7月公表）も公開されています。
PoCで止める条件
試験導入は「うまくいったら本番へ」だけでなく、止める条件も先に決めておきます。
- 用意した評価用の質問に対し、検索段で正しい文書が入る割合が改善の見込みなく低い
- 対象文書の版管理が整わず、古い版を除外できない
- 利用者ごとの権限を検索に反映できない
- 回答の確認にかかる時間が、自分で探す時間を上回る
4つ目は実務で効きます。回答を毎回検証しなければ使えないなら、業務時間は減りません。導入判断の考え方は業種横断・AI業務補助の経営判断軸の整理が使えます。
関連する記事
RAGの材料になる社内文書の品質は、日々の業務記録の作り方に左右されます。会議記録を業務の中で整える工程は生成AIで議事録を作る業務フローで扱っています。検索で得た根拠を使って文章を作る場合の検証工程は生成AIで記事を作る編集工程を参照してください。
チェックリスト
- 対象文書の範囲を、フォルダ単位で具体的に決めているか
- 改訂前の版を除外する方法があるか
- 対象文書に個人情報・NDA対象情報・営業秘密が混ざっていないか確認したか
- 利用者ごとの閲覧権限を、検索段で反映する設計になっているか
- 出典表示で、閲覧権のない文書名が出ない設計になっているか
- 評価用の質問を事前に集め、正解となる根拠文書を決めているか
- 検索の評価と回答の評価を分けて見られるか
- PoCを止める条件を、開始前に決めているか
まとめ
RAGは「検索してから答えさせる」仕組みであり、モデルを作り替えるものではありません。だからこそ、成否を決めるのは生成の巧拙よりも、対象文書の整備・権限の反映・評価の設計という地味な3点です。
ただしこの3点は、同じものを良くするわけではありません。回答の根拠性を左右するのは対象文書の整備と検索の設計であり、機密性を担うのは権限の反映です。評価の設計は、その両方が意図どおり効いているかを確かめるためにあります。権限制御を強めても回答の根拠性は上がらない、という区別を持っておいてください。
ツール選定の前に、対象文書の範囲を決め、評価用の質問を集めてください。この2つがないまま始めると、良くなったのか悪くなったのかを判断できないまま工数だけが増えます。
引用元・参考文献
原論文・標準・公的機関
- Patrick Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401（2020年5月投稿、NeurIPS 2020／確認日：2026年8月6日）：https://arxiv.org/abs/2005.11401
- NIST『AI Risk Management Framework (AI RMF 1.0)』（2023年1月26日公表／確認日：2026年8月6日）：https://www.nist.gov/itl/ai-risk-management-framework
- NIST『Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile』（NIST-AI-600-1、2024年7月公表／確認日：2026年8月6日）
- 総務省・経済産業省『AI事業者ガイドライン（第1.2版）』（令和8年3月31日公表／確認日：2026年8月6日）掲載ページ：https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
※ 本稿はRAGの基本的な考え方と導入前の検討事項を一般情報として整理したものです。特定製品の性能値・精度・改善率は扱っていません。RAGの構成や用語は実装・製品により異なります。AI事業者ガイドラインは版が改定されるため、参照時は掲載ページで最新版をご確認ください。