RAG（検索拡張生成）とは？向く業務・他方式との違い・導入から評価までの実践ガイド

RAG（Retrieval-Augmented Generation、検索拡張生成）は、質問に関連する社内文書や外部ナレッジを検索し、その検索結果を根拠としてLLMに回答させる設計です。モデル単体の知識だけに頼らず、回答時に外部の情報を参照できるため、更新される規程・製品情報・社内手順などを扱う業務で検討対象になります。RAGの原論文では、事前学習済みの生成モデルと、検索でアクセスする外部メモリを組み合わせる枠組みが示されています。RAG原論文

先に結論を述べると、RAGは「変わる知識について、参照元を示しながら回答したい」場合に有力です。ただし、文書が古い、権限設計が曖昧、検索精度を確認していない、といった状態では、LLMの性能だけを上げても期待した品質にはなりません。導入の成否は、検索対象のデータ整備、回答できない場合の扱い、評価データ、運用更新の設計で決まります。

本記事では、RAGの基礎だけでなく、採用判断、比較、PoC、評価、運用までを一続きで解説します。手順・スコア・テンプレートは、特記がない限りMojiによる実務上の提案です。モデル、入力データの品質、評価指標、許容できる誤りによって結論は変わるため、自社の実データで検証してください。

RAGとは：検索した根拠を渡してから回答を生成する仕組み

RAGは、主に次の流れで動きます。

1. 登録・整備：規程、FAQ、議事録、マニュアル、製品資料などを収集し、検索できる単位に分割する
2. 検索：質問に関連する文書断片を取得する
3. 文脈構成：取得した断片、質問、回答ルールをLLMへ渡す
4. 生成：根拠に沿って回答し、必要に応じて出典リンクや文書名を表示する
5. 記録・評価：質問、検索結果、回答、利用者の評価を残し、改善対象を特定する

たとえば「架空の例：2026年度の経費精算で、宿泊費の上限はいくらか」と聞かれたとき、RAGは経費規程の該当箇所を検索し、その箇所を根拠として回答します。ここで重要なのは、検索で取得できたことと、取得した根拠だけを使って正しく回答できたことは別の品質である点です。

RAGは万能な正答装置ではありません。検索対象に正しい情報がない、取得した情報が質問とずれている、LLMが根拠にない内容を補う、といった失敗は起こり得ます。そのため、検索と生成を分けて診断する評価設計が重要です。RAGCheckerは、検索モジュールと生成モジュールを対象にした診断指標を提案しています。RAGCheckerの原論文

RAGを採用すべきか：最初に確認する5つの判断基準

以下の条件が多く当てはまるほど、RAGを優先的に検証しやすくなります。

特に、RAG導入前に「どの文書を正本とするか」を決めてください。検索対象を増やすほど良いとは限りません。古いマニュアル、廃止済みFAQ、下書き資料を同じ重みで検索させると、もっともらしいが誤った回答の原因になります。

RAGに向く業務

• 社内規程、申請手順、オンボーディング資料を参照する社内ヘルプデスク
• 製品仕様、契約プラン、サポート手順に基づく問い合わせ一次対応
• 大量の提案書・議事録・調査資料から、該当箇所を探して要約する業務
• 品質管理文書や技術文書を横断し、関連する根拠を提示する検索・調査支援

RAGをそのまま当てはめにくい業務

• 回答よりも、決まったJSON形式・分類ルール・文体を安定して出すことが主目的の業務
• 検索対象に正本がなく、事実確認を外部の担当者が都度行う必要がある業務
• 送金、契約確定、顧客データ変更など、誤った実行が外部へ直接影響する業務
• 画像・表・図面が主な根拠で、テキスト抽出だけでは情報が欠落する業務

後者でもRAGが全く使えないわけではありません。ただし、回答支援に範囲を限定する、OCRや画像理解を組み合わせる、実行前に人が承認する、といった追加設計が必要です。AIに任せる操作範囲と承認・停止条件の決め方は、AIエージェントはどこまで任せるべきかも参照してください。

RAG・ロングコンテキスト・ファインチューニング・文章検索AIの違い

これらは代替関係ではなく、解決したい問題の層が異なります。以下は一般的な設計上の目安です。実際の選定結果は、モデル、対象文書の構造、入力品質、評価セット、許容誤差で変わります。

迷った場合の出発点は、「知識を変えたいのか、出力の振る舞いを変えたいのか」を分けることです。前者にはRAG、後者にはファインチューニングやプロンプト設計が候補になります。長文を扱う場合も、ロングコンテキストLLMとRAGを二者択一にせず、少数の文書を深く読む処理と、多数文書から候補を絞る処理を分けて比較してください。ロングコンテキストLLMとRAGの違い、AIファインチューニングの基本、文章検索AIの仕組みも参考になります。

RAG導入の進め方：PoCから運用までの7ステップ

1. 業務と成功条件を1つに絞る

最初から「全社ナレッジを何でも答えるチャットボット」を目指さないことが重要です。対象業務は、質問者、参照する正本、期待する回答、失敗時の影響を明文化できる範囲に絞ります。

Mojiの提案：要件テンプレート

• 対象者：誰が使うか
• 質問範囲：何について答えるか／答えないか
• 正本：参照してよい文書、優先順位、文書オーナー
• 回答形式：回答文、出典、該当箇所、注意書きの要否
• 失敗時：回答拒否、追加質問、問い合わせフォーム、有人引き継ぎのどれにするか
• 成功条件：回答時間、根拠表示率、業務完了率、確認工数など

生成AI導入を製品選定から始めず、業務・利用者・入力データ・KPIから棚卸しする考え方は、生成AI導入前の業務棚卸しと現場定着の進め方で詳しく解説しています。

2. データの正本・更新・権限を棚卸しする

文書ごとに、所有者、最終更新日、適用期間、公開範囲、廃止状態を管理します。最低限、検索結果に「文書名」「版」「更新日」「原本URLまたは保管先」を持たせると、誤答の調査と更新影響の確認がしやすくなります。

個人情報、顧客情報、営業秘密を含む文書は、検索対象に入れる前に利用目的とアクセス権を確認してください。生成AIのリスクはモデルだけでなく、データ、システム、利用者、運用にまたがります。NISTの生成AI向けAI RMFプロファイルも、生成AIの設計・開発・利用・評価に信頼性の考慮を組み込むための補助資料として位置付けられています。NIST AI 600-1

社内承認を経ないAI利用や、入力データを管理できない状態のリスクは、シャドーAIとはもあわせて確認してください。

3. 文書を検索可能な単位へ整える

PDFをそのまま登録するだけでは、見出し、表、注記、改訂履歴、画像内テキストが欠落または混ざる場合があります。まず、回答に必要な情報がどこにあるかを確認し、文書種別ごとに変換方法を決めます。

• 見出し階層、章番号、製品名、対象部署、版数などのメタデータを保持する
• 意味の途中で切れない単位を基本に、質問で参照したい粒度へ分割する
• 表・図・画像が根拠になる文書は、テキスト抽出結果だけで回答可能かを実データで検証する
• 旧版・ドラフト・重複資料は、除外または検索順位を下げるルールを設ける

画像、表、図面、動画を根拠に含める場合は、テキストRAGの延長として安易に扱わず、入力形式ごとの再現性を確認してください。マルチモーダルRAG・VideoRAG、VLMとOCR・マルチモーダルRAGの使い分けが参考になります。

4. 小さなベースラインを作る

最初のPoCでは、複雑なエージェント構成や高度な検索手法を先に増やしません。対象文書、質問セット、回答ルールを固定し、比較の基準となる最小構成を作ります。

Mojiの提案：最小構成の回答ルール

• 取得した根拠に書かれていないことは、推測として断定しない
• 根拠が不足するときは「確認できない」と答え、参照先または問い合わせ先を案内する
• 重要な回答には、文書名・版・該当箇所を表示する
• 質問の対象部署・製品・時点が曖昧なら、回答前に確認する

5. 評価データセットを先に作る

RAGの評価は、質問と理想回答だけでは不十分です。「どの根拠を取るべきか」「根拠がないときに回答を控えられるか」も確認対象に含めます。RAGは検索と生成から成るため、最終回答だけを評価すると、失敗原因が検索か生成かを区別しにくくなります。RAGCheckerの原論文

Mojiの提案：評価データの最小列

評価データセットを作る具体的な設計・品質確認・更新方法は、RAG評価データセットの作り方で解説しています。

6. 検索・回答・運用を分けて評価する

評価は「回答が自然か」だけで終えません。少なくとも次の4層に分けます。

1. 検索品質：期待する根拠が上位候補に含まれるか
2. 根拠整合性：回答の主張が、取得した根拠で裏付けられているか
3. 業務品質：利用者が次の作業へ進める回答になっているか
4. 運用品質：応答時間、失敗率、問い合わせ削減量、更新反映の遅れを許容できるか

LLMを評価者に使う方法は、大量の一次判定を補助できますが、判定基準の設計と、人による抜き取り確認が必要です。LLM as a judge（自動評価）、AIの評価とはも参照してください。

7. 更新・監視・改善を業務に組み込む

本番運用では、文書更新がRAGの品質を左右します。更新通知、再インデックス、旧版の除外、評価セットへの追加、障害時の切り戻しを運用として定義してください。NIST AI RMFは、AIシステムを設計、開発、配備、利用する組織がAIリスクを管理し、信頼でき責任あるAIの開発・利用を促すための任意の枠組みです。NIST AI RMF 1.0

RAGの評価チェックリスト

以下は、PoCの合否判断や本番移行前のレビューに使えるMojiによるチェックリストです。

• □ 実際の質問、曖昧な質問、誤字を含む質問で検索テストをした
• □ 正しい根拠が検索上位に出ない質問を特定した
• □ 正本ではない旧版・ドラフトを優先していない
• □ 回答文の重要な主張に、確認可能な根拠を付けられる
• □ 根拠がない質問に対し、もっともらしい回答を作らずに保留・案内できる
• □ 権限の異なる利用者で、閲覧できる検索結果が分離されている
• □ 重要度の高い質問は、業務担当者が評価・承認している
• □ 文書更新後に、対象箇所を再評価する手順がある
• □ 回答時間、1問い合わせあたりの処理量、監視工数を計測できる
• □ 重大な誤答・情報開示が起きたときの停止条件と連絡経路がある

RAGの費用を左右する条件

RAGの費用は「チャット画面を作る費用」だけでは決まりません。初期費用と継続費用を分け、次の要素を見積もります。

したがって、「文書数」だけから一律の費用を出すことはできません。特に、スキャンPDF、複雑な表、頻繁な改訂、部門別の厳格な権限管理がある場合は、データ整備と運用設計の比重が大きくなります。PoCでは、対象範囲を限定し、回答品質・確認工数・更新作業を測ったうえで、対象文書や利用者を広げる判断をしてください。

Graph RAG・Agentic RAGはいつ検討するか

通常のRAGで評価課題が明確になってから、派生設計を検討します。新しい名称の方式を先に採用すること自体を目的にしないことが重要です。

Graph RAG

人物、組織、製品、施策などの関係性や、データ全体を横断する問いが重要な場合に候補になります。Microsoft ResearchのGraphRAGは、テキスト抽出、ネットワーク分析、LLMによるプロンプティングと要約を組み合わせてテキストデータセットを扱う技術として説明されています。Microsoft Researchは、グローバル検索を対象に、知識グラフとコミュニティ情報を用いて関連情報を選択する設計も説明しています。Microsoft ResearchのGraphRAGプロジェクト、GraphRAGのグローバル検索に関する解説

一方で、グラフの構築・更新・検証にもコストがかかります。単純なFAQ検索で十分なら、まず通常のRAGで検索漏れ、文書構造、メタデータの課題を確認する方が比較しやすいでしょう。Graph RAGと従来RAGの違いを参照してください。

Agentic RAG

質問を分解し、複数回検索し、必要に応じてツールを呼び出す設計です。複雑な調査には有効な場合がありますが、検索回数、実行時間、コスト、失敗経路も増えます。まずは、いつ再検索し、いつ人に引き継ぎ、どの操作を禁止するかを評価可能な形で定義してください。エージェンティックRAGとは、API・MCP・A2Aの違いも関連します。

まとめ：RAG導入は「モデル選定」ではなく「根拠を管理する業務設計」から始める

RAGは、更新される外部知識を参照し、根拠付きで回答する生成AIを設計する有力な方法です。ただし、導入判断は「RAGを使えるか」ではなく、次の順で進めると失敗を減らせます。

1. 対象業務と、誤答してはいけない条件を決める
2. 正本・更新者・閲覧権限を持つデータだけを棚卸しする
3. 小さな対象範囲でベースラインを作る
4. 検索、根拠整合性、業務完了、運用の4層で評価する
5. 評価結果を基に、検索改善、Graph RAG、Agentic RAG、マルチモーダル化を比較する

RAGの品質は、モデル名だけで決まりません。質問、原本データ、検索設計、回答ルール、評価セット、更新運用を一つのシステムとして設計することが、継続利用できるRAGへの近道です。