RAG（Retrieval-Augmented Generation）とは、質問に関係する情報を資料から検索し、その内容をLLMへ渡して回答を作る仕組みです。モデルを再学習させる方法ではなく、回答する直前に外部情報を参照させる方法と考えると理解しやすくなります。
社内マニュアル、製品仕様、FAQ、議事録などを生成AIへ参照させたいとき、すべてを長いプロンプトへ貼り付ける方法には限界があります。RAGなら、質問に必要な部分だけを検索し、根拠と一緒に回答へ渡せます。
この記事では、RAGの構成、質問から回答までの5段階、向いている資料、精度を上げる確認点、最小検証の進め方を解説します。
情報確認日：2026年7月17日（日本時間）
結論：RAGは検索結果をLLMの入力へ追加する仕組み
RAGの3要素
- Retrieve：質問に関係する資料の断片を取得する
- Augment：取得した断片を質問と一緒に入力へ加える
- Generate：追加された情報を根拠に回答を生成する
RAGの目的は、LLMが最初から持っていない社内情報や更新された情報を、問い合わせ時に参照できるようにすることです。検索結果が不適切なら回答も不適切になりやすいため、モデルだけでなく検索品質を評価する必要があります。
- 質問：利用者が問い合わせる
- 検索：質問に近い資料断片を探す
- 追加：質問と資料断片をプロンプトへまとめる
- 生成：LLMが回答を作る
- 確認：回答と参照元を利用者へ示す
RAGと学習・ファインチューニングの違い
「自分の資料をAIに覚えさせる」と説明されることがありますが、一般的なRAGはモデルの重みを書き換えません。資料を検索可能な形で保存し、質問のたびに必要な箇所を入力へ加えます。
| 方法 | 何を変えるか | 向く目的 |
|---|---|---|
| 長いプロンプト | その1回の入力 | 少量の資料を一度だけ参照する |
| RAG | 検索対象と取得処理 | 更新される資料から根拠を探す |
| ファインチューニング | モデルの振る舞い | 出力形式や応答傾向を揃える |
最新の価格表や規程を答えさせたい場合は、内容を更新しやすいRAGが候補です。一方、常に決まった分類ラベルを返すよう振る舞いを調整したい場合は、プロンプト設計やファインチューニングも比較します。
RAGが回答を作るまでの5段階
1．資料を収集して更新責任を決める
PDF、Webページ、社内Wiki、FAQなどを集めます。重要なのはファイル数ではなく、正本がどれか、誰が更新するか、古い版をどう除外するかです。矛盾する新旧資料を両方入れると、検索が成功しても回答は安定しません。
2．資料を検索しやすい単位へ分割する
長い文書を、そのまま1件として扱うのではなく、見出しや段落に沿って小さな断片へ分割します。断片が大きすぎると不要な情報が増え、小さすぎると前提が失われます。文書の種類に合わせて調整し、タイトル、更新日、URLなどのメタデータも残します。
3．質問と近い断片を検索する
キーワード検索、ベクトル検索、両方を組み合わせた検索などで候補を取得します。固有の製品番号はキーワードが効きやすく、言い換えを含む質問は意味の近さを扱う検索が役立つ場合があります。
4．質問と検索結果をLLMへ渡す
取得した断片を「参照情報」として質問へ追加し、資料にない内容は推測せず、不明と答えるよう指示します。参照情報と命令を明確に分けることは、回答品質だけでなくセキュリティ上も重要です。
役割: 社内手続きの案内担当
ルール:
- 参照情報だけを根拠に回答する
- 根拠がなければ「資料では確認できません」と答える
- 回答末尾に出典名を示す
参照情報:
{{retrieved_chunks}}
質問:
{{user_question}}5．回答と引用元を表示する
回答だけでなく、参照した文書名、URL、該当見出し、更新日を表示します。利用者が原文へ戻れる設計にすると、誤りを発見しやすくなります。
RAGに向いている資料・向かない資料
| 資料・用途 | 相性 | 理由 |
|---|---|---|
| 社内規程・手順書 | よい | 正本と更新日を管理しやすい |
| 製品FAQ・仕様 | よい | 質問と根拠箇所を対応させやすい |
| 議事録 | 条件付き | 決定事項と雑談を分ける必要がある |
| 画像だけのスキャンPDF | 前処理が必要 | OCRとレイアウト確認が必要 |
| 出典不明のメモ | 不向き | 回答根拠として信頼性を判定できない |
| 厳密な数値計算 | RAGだけでは不十分 | 検索後にコードや業務システムで計算すべき |
RAGの精度を上げる5つの確認点
- 資料品質：正本、更新日、対象部署、公開範囲が明確か
- 分割品質：回答に必要な前後関係を保てているか
- 検索品質：正しい断片が上位に入るか
- 回答制約：資料にない内容を推測しない指示があるか
- 評価データ：実際の質問と期待する根拠を用意したか
まず「正しい断片を取得できたか」と「取得した断片から正しく答えたか」を分けて記録します。回答だけを採点すると、検索失敗と生成失敗を区別できません。
| 質問 | 期待する資料 | 取得 | 回答 | 対応 |
|---|---|---|---|---|
| 経費申請の期限は？ | 経費規程 3.2 | 成功 | 成功 | 維持 |
| 旧プランの料金は？ | 料金表 2026-07 | 失敗 | 失敗 | 古い版を除外 |
小さく始めるRAGの検証手順
- 用途を1つに限定する
- 正本となる10〜20文書だけを選ぶ
- 利用者が実際に尋ねる20問を集める
- 各質問に期待する資料名と箇所を付ける
- 検索結果と回答を別々に採点する
- 権限、ログ、更新、削除の運用を決める
- 限定した利用者へ公開して誤りを収集する
注意：アクセス権のない文書を検索結果へ混ぜないでください。RAGは便利な検索窓にもなり得るため、元資料と同じか、それ以上に厳しい権限確認が必要です。
AIの基本構成から確認したい場合はAIの基本、外部処理を実行する仕組みとの違いはTool Callingの仕組みも参考になります。
まとめ
RAGは、質問に関連する資料を取得し、その内容を追加してLLMへ回答させる仕組みです。導入時はモデル選びより先に、正本、分割、検索、引用、評価、権限を設計します。
最初から全社文書を入れず、1用途・少量の資料・20問程度の評価セットから始めると、どこで品質が落ちているかを判断しやすくなります。