RAGとは？仕組みと社内導入で失敗しない設計原則をわかりやすく解説
RAG（検索拡張生成）の仕組みを検索→文脈注入→生成の3段階で解説し、ファインチューニングとの使い分け、権限・鮮度・チャンク・評価の失敗パターン、PoCから本番への進め方をまとめました。
RAG（Retrieval-Augmented Generation、検索拡張生成）とは、質問に関連する文書を先に検索で集め、その内容を根拠としてLLMに回答を生成させる仕組みです。LLMが学習時に知らない社内の規程やマニュアルについて出典付きで答えさせる標準的な方法で、モデル自体を作り直すファインチューニングより導入が速く、文書が更新されたときの追従も容易です。
仕組みを「検索→文脈注入→生成」の3段階に分けて説明したあと、ファインチューニングや長文コンテキストとの使い分け、向く業務と向かない業務、社内導入で繰り返し起きる失敗（権限、鮮度、チャンク、評価不足）の原因、PoCから本番までの進め方、評価指標の考え方を整理します。
この記事でわかること
- 埋め込み・ベクトル検索・チャンク・プロンプト注入が、それぞれ何をしているか
- RAG、ファインチューニング、長文コンテキスト投入の使い分けの判断表
- RAGに向く業務と、SQLやワークフローで解くべき業務の見分け方
- 権限漏えい・情報の鮮度・チャンク設計・評価不足という4つの典型的な失敗の仕組みと対策
- PoCから本番までの4フェーズと、検索と生成を分けて測る評価指標
RAGの仕組み：検索→文脈注入→生成
RAGは2つの処理に分かれます。事前の「索引作り」では、文書をPDFやWordから文字として抽出し、400〜800文字程度の「チャンク」に分割し、各チャンクを埋め込みモデルで数百〜千数百次元の数値ベクトルに変換して、ベクトルDBに保存します。埋め込みとは、意味の近い文章が近い座標に置かれるように文章を数値化する処理で、「有給休暇の申請方法」と「年休を取るには」が別の言葉でも近くに並びます。
質問が来たときの「応答」では、質問文を同じ埋め込みモデルでベクトルにし、コサイン類似度で近いチャンクを上位5〜10件取り出します。取り出したチャンクを「参考資料」としてプロンプトに入れ、「この資料だけを根拠に答え、資料番号を示せ」と指示してLLMに生成させます。回答に付いた番号を元文書へのリンクに変えれば、利用者は根拠を確認できます。これがRAGの全体で、LLMは検索エンジンの結果を読んで答える係に過ぎません。
| 構成要素 | 役割 | 執筆時点の選択肢の例 | 設計で決めること |
|---|---|---|---|
| 文書抽出 | PDF・Office・HTMLから本文と表を取り出す | Apache Tika、Docling、pypdf | 表と2段組みの崩れ方、画像内文字のOCR要否 |
| チャンク分割 | 検索と根拠の単位に切る | 固定長、段落・見出し優先、Parent-child | サイズ（400〜800文字）、オーバーラップ、見出しパンくずの付与 |
| 埋め込みモデル | 文章をベクトルに変換 | bge-m3、qwen3-embedding、各クラウドの埋め込みAPI | 日本語対応、次元数、取り込みと検索で同一モデル |
| ベクトルDB | 近傍検索と権限フィルタ | pgvector、Qdrant、Weaviate、Chroma | 権限をWHERE句で効かせられるか、既存DBに相乗りできるか |
| 生成モデル | 根拠を読んで回答を書く | gemma4、Qwen3.x（ローカル）、クラウドAPI | コンテキスト長、日本語品質、データを外に出せるか |
| オーケストレーション | 上記をつなぎ、UIとログを提供 | Open WebUI、Dify、自作（Python） | 権限連携、同期、評価の仕組みを持てるか |
ベクトル検索だけでは型番や部署名のような固有語を取りこぼすため、実務ではキーワード検索（BM25）を併用する「ハイブリッド検索」と、候補を並べ直す再ランクモデルを組み合わせます。Open WebUIやDifyには両方の設定があり、自作するならPostgreSQLの全文検索拡張を足します。
ファインチューニング・長文コンテキストとの使い分け
| 観点 | RAG | ファインチューニング | 長文コンテキスト投入（全文をプロンプトに入れる） |
|---|---|---|---|
| 得意なこと | 知識の参照、出典提示 | 文体・形式・専門的な振る舞いの学習 | 少量の文書を漏れなく読ませる |
| 知識の更新 | 文書を差し替えるだけ | 再学習が必要 | プロンプトを変えるだけ |
| 出典の提示 | チャンク単位で可能 | 不可（知識が重みに溶ける） | 可能だが位置指定は粗い |
| 権限制御 | 検索時にフィルタできる | 不可。学習した内容は全員に出る | 投入前にアプリ側で制御 |
| 必要なデータ量 | 文書があればよい | 数百〜数千の教師データ | 文書があればよい |
| コストの出方 | 索引作りと検索基盤 | 学習のGPU時間と評価工数 | 毎回のトークン量（文書量 × 質問数） |
| 向く規模 | 数百〜数十万文書 | データ量より「振る舞い」が問題のとき | 合計で数万トークン以内の文書群 |
判断のルールは単純です。「知らないことを答えさせたい」ならRAG、「答え方を変えたい」ならまずプロンプトの改善、それでも足りなければファインチューニング、両方必要なら併用です。執筆時点のモデルは128K〜256Kトークンの文脈を扱えるので、対象が規程集1冊程度（合計で数万トークン）なら検索を挟まず全文を毎回渡すほうが取りこぼしがなく、実装も単純です。文書が増えて毎回の投入量とコストが膨らんだ時点でRAGに移行する、という順番も成立します。
向いている業務・向かない業務
| 業務 | 向き・不向き | 理由 | 代わりに使うもの |
|---|---|---|---|
| 社内規程、手順書、FAQへの問い合わせ | 向く | 答えが特定の文書の特定の箇所にある | ― |
| 過去の問い合わせチケットからの類似事例検索 | 向く | 言い回しが違っても意味で引ける | ― |
| 製品マニュアルの横断検索 | 向く（表の多い文書は抽出品質に注意） | 版ごとの差分も文書として持てる | 表はOCR・構造化抽出を併用 |
| 「先月の部門別売上合計は」などの集計 | 向かない | 検索は文書を「見つける」だけで、数値を「集計」しない | SQL、BI、LLMにSQLを書かせる構成 |
| 「条件Xに該当する契約をすべて列挙」 | 向かない | 上位k件しか取らないため網羅性が保証されない | 構造化データベースと全件スキャン |
| 秒単位で変わる情報（在庫、稼働状況） | 向かない | 索引の更新が追いつかない | APIをツールとして呼ぶ（MCPなど） |
| 文書同士が矛盾している領域 | 要注意 | 矛盾した根拠を両方渡すと回答も揺れる | 先に文書の棚卸しと廃止 |
よくある失敗とその仕組み
権限：ベクトル索引は誰が見てよいかを知らない
最も重い失敗です。ファイルサーバーでは部長しか開けなかった人事評価の資料が、索引に入った瞬間に全員の質問に対する根拠候補になります。ベクトル索引は「近いかどうか」しか見ておらず、権限を知りません。対策は、文書ごとに閲覧を許すグループを保存し、検索クエリの中でフィルタすることです。検索後にアプリで捨てる方式は、捨てる前の本文がログに残る、上位k件がすべて権限外で根拠ゼロになる、の2つの理由で不十分です。実装はpgvectorでの権限フィルタ付き検索で示しています。
PoCでは「公開文書だけ」で始めてください。権限設計が済む前に人事・経理・顧客情報を索引に入れると、PoCの結果を見た経営層が本番化を急ぎ、権限設計が後追いになります。索引に入れる文書の区分を最初に決めることが、後から一番効く判断です。
鮮度：更新された文書と削除された文書
規程が改定されても索引が古いままなら、RAGは自信を持って旧版を答えます。削除された文書はさらに厄介で、元の場所から消えても索引には残ります。対策は、文書のURIと内容ハッシュを保存し、夜間同期で「変わった文書は再取り込み、消えた文書は索引からも削除」を機械的に行うことです。回答には「この情報は2026年9月時点の規程に基づく」のように、根拠文書の更新日を添えます。
チャンク：小さすぎても大きすぎても外す
200文字で切ると「前条の規定にかかわらず」のような主語のない断片になり、3,000文字で切ると1チャンクに複数の話題が混ざって検索の的が絞れません。段落や見出しの境界を優先し、各チャンクの先頭に「文書名 > 章 > 節」を付け、表は行単位でテキスト化するのが基本形です。小さなチャンクで検索して、その親（章全体）を根拠として渡すParent-child方式は、規程やマニュアルで安定した結果を出します。
評価不足：「なんとなく良い」で本番に出る
テストセットがないと、精度が悪いときに検索が外しているのか生成が根拠を無視しているのか分からず、埋め込みモデルを変えるべきかプロンプトを変えるべきかも決められません。30〜50問の質問と期待する根拠文書、模範回答を最初に用意し、設定を変えるたびに同じセットを流します。評価指標は後述します。
抽出品質とコンテキスト長：見えない切り捨て
PDFの表や2段組みは既定の抽出器で崩れ、「見出しと数値がずれた表」がそのまま索引に入ります。TikaやDoclingのような構造を保つ抽出器に替え、取り込み後のチャンクを目視で数件確認する手順を挟みます。もう1つ、Ollamaの既定コンテキスト長は4096トークンで、8チャンク分の根拠を渡すと超過分が警告なく切り捨てられます。RAGでは8192以上に設定し、渡したチャンク数と長さをログに残して、切り捨てが起きていないことを確認してください。
「根拠が見つからないときは見つからないと答える」を、プロンプトで先に定義してください。定義がないとLLMは一般知識で埋めた回答を返し、利用者は出典付きの回答と区別できません。検索結果がゼロのときはLLMを呼ばず固定文を返す実装が最も確実です。
導入ステップ：PoCから本番へ
| フェーズ | 期間の目安 | やること | 次に進む条件 |
|---|---|---|---|
| PoC | 2〜4週間 | 1部署、公開文書50〜200件、質問30〜50問のテストセット。Open WebUIかDifyで最短構成 | Recall@8が0.8以上、担当者が「これなら使う」と言う |
| 評価と設計 | 2週間 | 失敗パターンの分類、権限モデルと同期方式の決定、ツール選定 | 権限区分と索引対象の文書一覧が承認される |
| パイロット | 1〜2か月 | 2〜3部署、SSO、権限フィルタ、夜間同期、フィードバックボタン、ログ | 権限テスト100%、利用者の評価が集まる |
| 本番 | 継続 | 全社展開、月次の評価セット再実行、文書棚卸しの運用、モデル更新の手順化 | ― |
ツールは要件で決めます。「まず触る」ならUIも設定も揃った既製品、「文書単位の権限とファイルサーバー同期」が要件になった時点で自作かカスタマイズ可能な基盤、という順番です。
| 観点 | Open WebUI（内蔵RAG） | Dify（ナレッジ） | 自作（pgvector + Python） | SaaS付属のAI検索 |
|---|---|---|---|---|
| 権限連携 | ナレッジ単位の共有 | ナレッジ単位の公開範囲 | 文書単位、IdPグループ連携が可能 | 製品の権限モデルに従う |
| カスタマイズ | 設定項目の範囲 | ワークフローで分岐や外部API | すべて | ほぼ不可 |
| 運用負荷 | 低い | 中（コンテナ15個前後） | 高い（自分で保守） | 低い |
| データの所在 | 自社 | 自社 | 自社 | 事業者 |
| 向く判断 | チャットに文書を添える用途 | 問い合わせ分類や起票まで組む | 権限・同期・評価を本気でやる | すでに文書がそのSaaSにある |
構築手順はOpen WebUIの構築ガイドとDifyのセルフホストガイドに、全社展開の前に決めるルールは生成AIの社内利用ガイドラインにまとめています。
評価指標の考え方
指標は「検索」「生成」「運用」の3層に分け、検索と生成を必ず別々に測ります。検索が正しく生成が間違う場合と、検索が外している場合とでは、直す場所がまったく違うからです。
| 層 | 指標 | 測り方 | 出発点の目安 |
|---|---|---|---|
| 検索 | Recall@k | 期待する根拠文書のチャンクが上位k件（k=8など）に入った割合 | 0.8以上 |
| 検索 | MRR | 正解チャンクが何位に出たかの逆数の平均。上位に出るほど高い | 0.6以上 |
| 生成 | 根拠性（groundedness） | 回答の各文が渡したチャンクで裏付けられるか。人手で0/1/2 | 平均1.6以上 |
| 生成 | 正答率 | 模範回答と照らして正しいか。人手評価 | 用途で決める |
| 生成 | 「見つからない」の適切さ | 根拠がない質問に対して、推測せず固定文を返した割合 | 100% |
| 運用 | 権限テスト | 権限のない利用者で同じ質問。ヒット0件が100%であること | 100%（必須） |
| 運用 | 応答時間、フィードバック | p95の応答秒数、回答への「役に立った」率 | 社内チャットで15秒以内 |
根拠性の判定にLLMを使う「LLM-as-a-judge」は、人手評価の代わりではなく補助として使います。同じモデルに自分の回答を採点させると甘くなる傾向があるので、まず30問を人手で採点し、LLMの採点との一致率を確認してから、残りの問題や継続的な回帰テストに使うのが安全な順序です。埋め込みモデルの変更は索引の作り直しと評価の全件再実行を伴うので、通常のパラメータ調整とは別の「移行作業」として計画してください。
よくある質問
RAGとファインチューニングの違いは？
RAGは検索した文書を毎回プロンプトに入れて答えさせる方式で、知識の更新は文書の差し替えで済み、出典も示せます。ファインチューニングはモデルの重みを追加学習で変える方式で、文体や形式、専門的な振る舞いの調整に向きますが、知識の更新に再学習が要り、出典も権限制御もできません。
RAGに必要なものは？
本文を取り出せる文書、埋め込みモデル、ベクトル検索ができるデータベース、生成用のLLM、それらをつなぐアプリ、そして評価用の質問セットです。最小構成ならOpen WebUIとOllamaだけで揃い、本番では権限モデル、同期ジョブ、ログ、フィードバックの仕組みが加わります。
RAGの精度はどう測りますか？
質問と期待する根拠文書のペアを30〜50問用意し、検索はRecall@kとMRR、生成は根拠性と正答率を人手で採点します。権限のない利用者で結果がゼロになることも指標に含めます。設定を変えるたびに同じセットを流し、検索と生成のどちらが劣化したかを分けて見ます。
まとめ
RAGは「検索で根拠を集め、その範囲で答えさせる」仕組みで、LLMは検索結果を読む係です。使い分けは、知識ならRAG、振る舞いならプロンプトとファインチューニング、少量の文書なら全文投入。社内導入の失敗は権限・鮮度・チャンク・評価不足の4つに集約され、いずれも設計段階で決めておけば防げます。PoCは公開文書と30問のテストセットから始め、権限フィルタを検索の中に入れた時点で本番に進んでください。
次に読む
- pgvectorとPythonで作る社内文書RAG：権限フィルタ付き検索の設計とコード
- Difyをセルフホストする：ナレッジ機能とワークフローでのRAG構築
- Open WebUIで社内ChatGPT環境を作る：内蔵RAG機能の設定と限界