RAGとは｜検索拡張生成の仕組み・用途・生成AI単体との違い

RAGとは、利用者の質問に関係する文書を検索し、その根拠を生成AIへ渡して回答させる仕組みです。 生成AI単体、長文投入、全文検索、ファインチューニングとの境界を明確にし、社内問い合わせで採用すべき条件、運用負荷、PoCの判定方法まで説明します。

RAGを採用するかは「更新される社内知識」で決める

RAG（Retrieval-Augmented Generation）は、利用者の質問に関係する資料を検索し、その資料を根拠として生成AIに回答させる構成です。Lewisらの原著論文は、生成モデルの内部知識と外部の非パラメトリックな記憶を組み合わせる枠組みとしてRAGを提示しました^[1]。企業実務では「外部記憶」を規程、製品マニュアル、FAQ、案件記録などの更新可能な文書群として実装します。

採用判断の中心は、生成AIを使いたいかではありません。回答根拠が社内文書にあり、その文書が定期的に更新され、利用者ごとに検索範囲を分ける必要があるかを確認します。たとえば人事規程の問い合わせでは、改定日と適用会社を示せるRAGが有効です。一方、「顧客への謝罪文を丁寧に直す」だけなら、文書検索を追加しても価値は小さく、通常の生成AIで足ります。

導入前の確認例として、頻出質問を10件選び、各質問について正本の文書ID、版、ページ、閲覧対象者を一意に記録します。複数の現行版が残る、ページを特定できない、回答者によって正解が変わる質問が多い場合は、RAG製品の比較へ進まず文書整備を先行させます。10件は準備状況を短時間で確かめるための例であり、業界共通の採用基準ではありません。記録できた質問は、そのままPoCの検索確認へ引き継げます。

問い合わせ窓口でRAGが担当する範囲

社内ITヘルプデスクを例にすると、RAGは質問を受け、許可されたマニュアルから候補箇所を探し、根拠付きの回答案を作るところまで担当します。アカウントの停止、端末の遠隔操作、例外申請の承認は別の業務機能です。回答と実行を一つにすると、検索誤りがそのまま状態変更へつながるため、最初の導入では切り離します。

RAGが向かないのは、正本が決まっていない文書群、口頭知識だけで正解が変わる案件、検索結果を人が確認できない高リスク判断です。文書管理が崩れている場合は、検索技術を導入する前に版、所有者、失効日の整理を行います。

RAGでも回答が正しくならない六つの理由

RAGは「資料を追加すれば事実誤りがなくなる仕組み」ではありません。検索前、検索中、生成時のどこでも失敗します。原因を分けておくと、モデル変更だけを繰り返す無駄を避けられます。

1. 正本の不備：改定前の規程と現行版が同時に検索対象へ入っています。
2. 取り込み漏れ：PDFの表や画像内文字が抽出されず、必要な数値が索引にありません。
3. 分割の崩れ：条件と例外を別々の断片にし、片方だけを取得します。
4. 検索語のずれ：社内略称と正式名称が対応せず、候補文書が上位へ来ません。
5. 回答の飛躍：取得文にはない結論をモデルが補ってしまいます。
6. 権限の欠落：閲覧不可の断片を検索してから表示段階で隠そうとします。

OpenAIのFile searchガイドは、ベクトルストア内のファイル検索をツールとして回答へ組み込む手順を示しています^[2]。ただし、業務文書の正本性、アクセス権限、回答承認まで代行する仕様ではありません。製品機能と自社の統制を分けて設計します。

文書、検索、回答の責任者を分ける

検索結果が悪いときに文書所有者へモデル調整を求めたり、文書の法的解釈を開発者へ委ねたりしないことが重要です。利用者からの誤答報告には、質問、取得断片、回答、最終修正、参照した文書版を一組で残し、担当領域へ振り分けます。

文書所有者が退職・異動した場合の代行者も決めます。更新通知が届かないまま索引だけ動き続ける状態は、停止していないように見えて実質的には旧版システムです。月次の運用会議では、誤答件数だけでなく未反映文書、所有者不明文書、権限例外の残件を確認します。

小規模試行で採否を判断する数値

以下は実績ではなく、社内規程問い合わせを想定した試算です。過去の問い合わせから100問を選び、現行規程で正解と根拠ページを付けます。60問を通常質問、20問を表・別紙参照、10問を旧版との競合、10問を「資料に答えがない質問」とします。

検索成功率 = 正しい根拠が上位5件に入った問数 ÷ 100
根拠一致率 = 回答が正しい文書・ページを示した問数 ÷ 100
適切な不回答率 = 根拠なし10問で推測しなかった問数 ÷ 10
確認短縮分 = 導入前の平均確認時間 - RAG回答確認時間

想定結果が検索成功88問、根拠一致82問、不回答9問、導入前12分、導入後5分なら、検索成功率88％、根拠一致率82％、適切な不回答率90％、確認短縮は1件7分です。検索成功なのに根拠一致が低ければ生成工程を直し、検索成功自体が低ければ文書抽出・分割・検索を見直します。四つの値を一つの総合点にすると改善箇所を失います。

一件の質問が回答になるまで

「育児短時間勤務は入社直後でも申請できるか」という架空質問を例に流れを追います。利用者の所属会社と雇用区分を認証情報から取得し、閲覧可能な就業規則と育児介護規程だけを検索対象にします。質問文から「育児短時間勤務」「勤続期間」「適用除外」を検索条件へ展開し、現行版の関連節を候補として取得します。

1. 質問と利用者属性から、検索可能な文書集合を確定します。
2. 正式名称、社内略称、関連する除外条件を含めて検索します。
3. 取得した断片に文書ID、版、節番号があるかを検証します。
4. 条件本文と適用除外を同時に回答コンテキストへ渡します。
5. 回答案へ結論、適用条件、確認先、引用位置を出力します。
6. 根拠が足りなければ「人事へ確認」と返し、推測で埋めません。

この流れでは、RAGが申請可否を法的に確定するのではなく、担当者が確認すべき現行規程を短時間で提示します。自動回答まで広げるのは、適用条件が機械的に判定でき、例外を人へ戻せることを確認した後です。

更新頻度と利用件数から構成を見直す

試行後にRAGを継続するかは、文書更新と問い合わせ量の両方で判断します。月10件しか問い合わせがなく、文書が年1回しか変わらないなら、整備されたFAQと検索画面の方が保守しやすい場合があります。反対に、製品マニュアルが毎週更新され、月数千件の一次回答があるなら、更新反映を自動化する価値が高まります。

• 文書更新から索引反映までの時間が業務の許容範囲を超えた。
• 質問の30％以上で複数文書をまたぐ根拠が必要になった。
• 閲覧区分の追加により、利用者属性だけでは認可できなくなった。
• 回答確認時間が導入前より増え、根拠確認が複雑になった。
• 検索対象外の口頭知識が誤答原因の多数を占めるようになった。

これらはRAGを高度化する合図とは限りません。対象業務を狭める、FAQへ戻す、文書管理を改善する、専門窓口へ集約する選択肢も同じ表で比較します。

RAG採否メモに残す七項目

PoCの終了時には、デモの印象ではなく次の七項目を一ページへ記録します。対象業務、検索する正本、質問の母数、検索成功率、根拠一致率、1件当たり確認時間、対象外条件です。さらに、索引を停止した場合に元の検索・問い合わせ手順へ戻せるかを確認します。

生成AI単体・長文投入・検索システムとの違い

EmbeddingsはRAGで候補文書を探す技術の一つであり、RAGそのものではありません^[3]。キーワード検索、ベクトル検索、両者の併用から業務語彙に合う方法を選びます。読後に決めるべきことは製品名ではなく、自社の質問が「更新文書から根拠を探す問題」かどうかです。

RAGの仕組みを準備系と質問系に分ける

RAGは、文書を準備する処理と、利用者の質問へ答える処理の二系統で動きます。準備系では正本を収集し、文字を抽出し、検索単位へ分け、索引を作ります。質問系では利用者の権限を確認し、質問に関連する断片を取得し、回答モデルへ渡し、引用とともに結果を返します。両者を分けると、誤答が文書更新の遅れなのか、検索の失敗なのか、生成の飛躍なのかを追跡できます。

準備系:
正本登録 → 抽出 → 分割 → メタデータ付与 → 索引 → 品質検査
質問系:
認証 → 検索範囲の認可 → 質問変換 → 候補取得
→ 候補検証 → 根拠付き回答 → 利用者確認 → 評価ログ

検索では、質問と文書の語が同じ場合に強いキーワード検索と、言い換えを扱いやすいベクトル検索を使い分けます。製品番号、条番号、固有名詞はキーワードが重要です。「立替金を返してほしい」と「経費精算」のような言い換えでは意味検索が役立ちます。どちらか一方へ決め打ちせず、過去質問で候補順位を比較します。

取得した断片は、そのまま正しい根拠とは限りません。文書版、施行日、対象会社、閲覧区分を検証し、競合する二つの断片があれば回答を保留します。回答モデルには結論だけでなく、適用条件、該当しない条件、文書ID、節・ページを返させます。引用先が開けない場合は、利用者が検証できないため受入不合格です。

FAQ・全文検索・RAGの運用負荷を比較する

RAGは質問へ直接答えるため便利ですが、文書更新、索引、モデル利用、評価、監査の運用が増えます。質問数が少なく、答えが20件の定型FAQで収まるなら、FAQを整備した方が安く正確です。利用者が検索語を理解し、原文を読む必要がある業務では、全文検索の方が透明性を保ちやすい場合があります。

想定例として月1,500件の問い合わせがあり、担当者の確認が1件平均10分、RAG導入後の確認が6分になれば、短縮は月6,000分です。ただし、月80時間の文書・評価運用が増えるなら、正味の短縮は20時間です。この計算は実績ではなく、検討方法を示すものです。

月間確認短縮 = 1,500件 × (10分 - 6分) = 6,000分 = 100時間
正味短縮 = 100時間 - 追加運用80時間 = 20時間
1件当たり総費用 = (モデル費 + 検索費 + 運用人件費) ÷ 月間処理件数

金額換算だけでなく、回答待ち時間、担当者間の品質差、根拠の追跡、誤答の影響を比較します。RAGの回答確認に専門家が毎回必要で、元文書を読む時間も変わらないなら、導入目的を「時間短縮」から「根拠候補の漏れ防止」へ修正するか、採用を見送ります。

文書改訂を検知して索引・評価・表示を更新する

RAGは、文書を一度登録して終わるシステムではありません。規程の承認、公開、施行、失効の各時点を文書管理のイベントとして扱い、どの時点で検索対象へ入れるかを決めます。公開前の草案を一般利用者へ見せない一方、施行日当日に旧版だけが残ることも避けなければなりません。

1. 文書所有者が文書ID、版、施行日、差分、公開範囲を登録します。
2. 取り込み処理が抽出結果を検査し、新しい索引へ登録します。
3. 改訂箇所に関係する固定質問と版競合ケースを再評価します。
4. 合格後に施行時刻を指定して新索引へ切り替えます。
5. 旧版は過去日付検索用として分離するか、保持規程に従い削除します。
6. 引用リンクと画面の版表示が新しい正本へ向くことを確認します。

OpenAIのFile search公式資料は、ファイルをベクトルストアへ追加し検索ツールから利用する流れを説明しています^[2]。ただし、社内文書の承認状態や施行日の業務管理は自社で実装します。製品側のアップロード完了を「業務上の公開完了」と同一視しません。

削除要求や閲覧権限変更は、元ファイルだけでなく断片、ベクトル、キャッシュ、評価ログへ反映します。反映範囲を追跡できない場合は、機密性の高い文書をRAGへ載せるべきではありません。

RAGのPoCを採否判断で終わらせる

PoCの目的は、回答画面を作ることではなく、対象業務でRAGを採用できるかを期限内に判断することです。開始時に採用、条件付き採用、見送りの基準を決めます。評価データや文書所有者が揃わないまま期間を延長し続けると、技術デモだけが残ります。

評価100問の内訳は、頻出質問だけにしません。通常60問、表・別紙15問、旧版競合10問、権限違反5問、根拠なし10問など、失敗してほしくない条件を含めます。各問には期待回答の文章ではなく、必須要素、正しい文書・ページ、許容できる不回答を付けます。

採用基準の想定例は、重要条件の誤り0件、越権返却0件、根拠一致90％以上、根拠なし質問の適切な不回答90％以上、担当者確認時間の中央値が導入前より短い、です。数値は業務影響で調整し、公開された他社値をそのまま使いません。

見送りでもPoCは失敗ではありません。正本が定まらない、質問数が少なくFAQで足りる、回答確認が短縮しない、運用担当を確保できないと分かったなら、RAGを作らない判断が成果です。終了時に未解決事項、再検討の条件、試験データの保存期限を記録します。

RAG採否を決めるための次作業

自社の問い合わせから、正解が現行文書に書かれている質問を100件選び、正しい文書・ページと「答えがない場合」の期待動作を付けてください。同じ問題をFAQ、全文検索、RAGで比較し、検索成功、根拠一致、適切な不回答、担当者の確認時間、月間運用負荷を別々に記録します。RAGが優位でも、文書所有者、索引更新、権限同期、誤答時の窓口を割り当てられなければ条件付き採用または見送りです。製品選定は、この業務要件と評価セットが固まった後に行います。

採否会議では、業務部門が「間違えると手続き・金額・顧客対応へ影響する質問」を先に確認し、情報システム部門が権限同期と更新遅延、文書管理者が正本と廃版の扱い、運用責任者が不回答時の引き継ぎ先を説明します。合格例は、重要質問20件の根拠一致100％、権限外文書の表示0件、文書改訂から索引反映まで1営業日以内、担当者の確認時間が従来比で短縮、というように業務条件へ結び付けます。数値は自社の試行で測る基準であり、RAG一般の性能値ではありません。FAQで十分な定型質問までRAGへ移さず、正本を決められない部門は文書整理を先行させます。議事録には採用、条件付き採用、見送りのいずれかと、未達項目の責任者・期限を残します。見送りの場合も、文書整備や権限同期が完了した後の再判定日を設定します。

参考文献・出典

1. Lewisほか「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」。Advances in Neural Information Processing Systems 33, 2020掲載の原著論文です。RAG（検索拡張生成）の定義と、パラメトリック記憶・非パラメトリック記憶を組み合わせる仕組みを確認（参照日：2026年7月31日）。
2. OpenAI公式ドキュメント「File search」。版は継続更新ページ（版番号なし）、更新日はページ内表示なしです。RAGの実装用途として、ベクトルストア内のファイルを意味検索・キーワード検索する仕様を確認（参照日：2026年7月30日）。
3. OpenAI公式ドキュメント「Vector embeddings」。版は継続更新ページ（版番号なし）、更新日はページ内表示なしです。意味検索に使うベクトル表現の用途を確認（参照日：2026年7月30日）。