RAGとは|仕組みと導入前に確認すべきこと
- 公開
- 2026-09-01
- 執筆
- 株式会社visum
- 読了目安
- 5分
この記事でわかること
- RAGの仕組みと必要な規模
- 失敗する2つの原因
- 権限と著作権の確認事項
RAG(検索拡張生成)は、生成AIが回答する前に社内文書を検索し、その内容を根拠にして答えさせる仕組みです。ChatGPTなどが自社の規程や製品情報を知らない、という問題を補います。
ただし導入すれば社内の情報検索が解決するわけではありません。元の文書が古ければ、古い回答が返ってきます。仕組みより先に確認すべきことがあります。
この記事では仕組みを簡潔に整理したうえで、導入前に確認すべき点を扱います。
まず確認する4項目
導入を検討する前に、以下を確認してください。
| # | 確認項目 | 該当したら |
|---|---|---|
| 1 | 対象の文書は何件あるか | 数十件なら別の方法で足りる場合がある |
| 2 | 文書は最新の状態か | 更新する運用が先 |
| 3 | 全員が見てよい文書か | アクセス権限の設計が必要 |
| 4 | 外部から集めた資料を含むか | 著作権の確認が必要 |
3と4を飛ばすと、後から作り直しになります。
RAGの仕組み
検索してから答える、という3段階です。
| 段階 | 内容 |
|---|---|
| 検索(Retrieval) | 質問に関連する情報を、社内文書などから探す |
| 拡張(Augmentation) | 見つかった情報を、質問と一緒にAIへ渡す |
| 生成(Generation) | 渡された情報を根拠に回答を作る |
通常の生成AIは、学習済みの一般知識から回答します。そのため自社の規程や製品仕様といった非公開情報には答えられません。
RAGでは、質問のたびに社内文書を検索して結果を渡すため、AIが学習していない情報にも答えられます。 回答の根拠となった文書を示せる点も特徴です。
この枠組み自体は2020年に論文で提案されたもので、新しい概念ではありません。社内データを生成AIに使わせる方法として、あらためて注目されています。
ファインチューニングとの違い
よく比較される手法です。
| RAG | ファインチューニング | |
|---|---|---|
| やること | 回答時に外部データを検索して渡す | モデル自体を追加学習させる |
| 情報の更新 | 文書を差し替えるだけ | 再学習が必要 |
| 根拠の提示 | できる | 難しい |
頻繁に更新される社内文書を扱うなら、RAGのほうが向いています。 規程が変わるたびに再学習させるのは現実的ではありません。
RAGが必要な規模かどうか
数十件の資料なら、RAGを構築しなくても足りる場合があります。
資料をアップロードして質問できるツールがあります。NotebookLMのように、指定した資料だけを根拠に回答するサービスです。
| 状況 | 現実的な選択 |
|---|---|
| 特定の数十件を扱いたい | 資料アップロード型のツール |
| 数千件以上を横断して検索したい | RAGの構築を検討 |
| 部署ごとに参照範囲を分けたい | RAGの構築を検討 |
「RAGを導入する」が目的化していないかを確認してください。解決したいのは情報が探せないことであって、RAGを入れることではありません。
小さく試すなら、まず数十件でツールを使ってみる。それで足りるなら構築は不要です。
導入して失敗する2つの原因
原因1:元の文書が古い
RAGは、渡された文書の内容をそのまま根拠にします。
古いマニュアルがインデックスされていれば、古い手順が回答されます。しかも根拠として文書名が示されるため、それらしく見えてしまいます。
導入前に確認すべきことがあります。
- 現行版と旧版が混在していないか
- 廃止された規程が残っていないか
- 誰が更新するかが決まっているか
3つ目が最も重要です。更新する人が決まっていない文書は、時間とともに必ず古くなります。
文書の整理はRAGを使わない作業ですが、この整理自体が業務の見直しになります。
原因2:アクセス権限が設計されていない
これが実務で最も起きる問題です。
社内文書をまとめてインデックスすると、検索対象に何が含まれるかを意識しなくなります。その結果、以下が起こりえます。
- 人事評価や給与に関する文書が回答に混ざる
- 特定部署限定の情報が、他部署の質問に対して出てくる
- 退職者に関する情報が参照される
ファイルサーバーで権限を分けていても、RAGのインデックスが権限を引き継ぐとは限りません。
対応としては、以下のいずれかが必要になります。
- インデックスする対象を、全員が見てよい文書に限定する
- 利用者の権限に応じて検索範囲を絞る仕組みを作る
1のほうが単純で確実です。 まず全社共通の文書だけで始め、必要になってから2を検討する順序が無理がありません。
個人情報を含む文書の扱い
権限の問題と関連します。
個人情報保護委員会は、生成AIに個人情報を含むプロンプトを入力する場合、特定された利用目的の達成に必要な範囲内かを十分に確認するよう求めています。
RAGでは、検索結果が自動でAIに渡されます。 質問のたびに人が入力内容を確認できません。
そのため、インデックスの段階で個人情報を含む文書を除外するかどうかを決めておく必要があります。
外部資料を含める場合の著作権
見落とされやすい論点です。文化庁の資料に、RAGへの明示的な言及があります。
RAG等を実装する際に、生成AIへの入力用として既存の著作物を含むデータベースを作成する場合。この場合は著作権法30条の4が適用されないことがある、とされています。対象は、データベースに含まれる著作物の創作的表現を出力させることを目的としたものです。
自社で作成した文書だけを対象にするなら通常は問題になりません。外部から集めた資料や、購入した資料を含める場合は確認が必要です。
判断が必要な場面では専門家にご相談ください。当社は法律事務所ではありません。著作権の考え方は生成AIと著作権で扱っています。
何から始めるか
- 解決したい問題を1つ決める(「どこに書いてあるか分からない」問い合わせが多い業務など)
- その業務で参照する文書が何件あるかを数える
- 数十件ならツールで試す。 数千件なら構築を検討
- インデックス対象を、全員が見てよい文書に限定する
- 更新する担当を決める
4と5を決めずに構築すると、後から作り直しになります。
なお、生成AIが自ら検索を繰り返す「Agentic RAG」といった発展形もありますが、まず基本形が機能してからの話です。
当社もAI導入支援を行う事業者として、この順序は導入検討の前提にしています。
参考
以下はすべて2026年9月1日に確認しました。
DOWNLOAD
検討用の資料をダウンロードできます
ツールの選び方と、社内で使われないまま終わる原因をまとめた資料です。メールアドレスの登録だけで受け取れます。
資料を受け取る全12ページ/PDF