RAGとは？導入すべき業務の判断基準・他方式との違い・評価の進め方

RAG（Retrieval-Augmented Generation、検索拡張生成）は、質問に関連する文書やデータを検索し、取得した情報を根拠としてLLMに回答させる設計です。RAGの原論文では、事前学習済みの生成モデルと、検索でアクセスする非パラメトリックな外部メモリを組み合わせる枠組みが示されています。RAG原論文

先に結論を述べると、RAGが向くのは「更新される知識について、利用者が根拠を確認しながら回答を得たい業務」です。たとえば社内規程、製品仕様、サポート手順、品質文書、契約プランの案内などが候補になります。

一方で、正本が定まっていない、検索対象の権限を分けられない、現在在庫・確定価格・残高のような値を確定したい、といったケースでは、RAGだけで解決しようとしないことが重要です。文書を探して説明する仕事、DBや業務APIで現在値を確定する仕事、決まった形式で出力する仕事を分けて設計してください。

本記事の手順、判定表、テンプレートは、特記がない限りMojiによる実務上の提案です。モデル、入力データの品質、評価セット、許容できる誤り、運用体制によって結論は変わるため、自社の実データで検証してください。

まず判断：RAGを優先して検証しやすい5条件

次の条件に多く当てはまるなら、RAGのPoCを優先的に検討しやすい状態です。

導入前に最優先で決めることは、検索対象の「正本」です。廃止済みの手順書、過去の価格表、ドラフトを同じ条件で検索すると、もっともらしく見えても誤った回答が生まれます。RAGの品質は、モデル名だけでなく、検索対象に何を入れ、何を除外するかで大きく変わります。

RAGとは：検索・文脈構成・生成を分けて考える

実装には違いがありますが、業務用RAGはおおむね次の流れです。

1. 文書を整備する：正本となる規程、FAQ、マニュアル、議事録などを収集し、版・更新日・閲覧権限などのメタデータを付与する。
2. 検索する：質問に関係する文書または文書断片を取得する。
3. 文脈を構成する：質問、取得した根拠、回答ルールをLLMへ渡す。
4. 回答を生成する：根拠に沿って回答し、文書名、版、該当箇所などを表示する。
5. 評価・改善する：質問、検索候補、LLMへ渡した文脈、回答、利用者評価を記録して失敗箇所を特定する。

たとえば「架空の例：経費精算で宿泊費の上限はいくらか」と質問された場合、RAGは経費規程の該当箇所を探して回答します。ただし、正しい根拠を取得できたことと、取得した根拠だけを使って回答できたことは別の品質です。

RAGの評価研究であるRAGCheckerも、検索モジュールと生成モジュールの両方を診断する指標を提案しています。最終回答だけを見ていると、原因が検索漏れなのか、ノイズ混入なのか、生成時の根拠逸脱なのかを切り分けにくくなります。RAGChecker原論文

回答が的外れなときの切り分けは、社内RAGが的外れな回答を返す原因と改善方法で詳しく解説しています。

RAG・ロングコンテキスト・ファインチューニング・DB/API直接照会の違い

以下は一般的な設計上の目安です。モデル、入力品質、評価指標、許容誤差によって最適な構成は変わるため、同じ質問セットで比較してください。

迷った場合は、まず「知識を変えたいのか」「出力の振る舞いを変えたいのか」「現在値を確定したいのか」を分けてください。更新文書の説明にはRAG、出力形式の調整にはプロンプト設計やファインチューニング、現在値の確定には正となるDB・APIを優先する、という切り分けが出発点になります。

ロングコンテキストLLMとRAGの違い、AIファインチューニングの基本、文章検索AIの仕組み、RAGとリアルタイムのDB・API直接照会の使い分けもあわせて確認してください。

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

1. 対象業務を1つに絞り、合否基準を先に決める

最初から「全社の何でも答えるチャットボット」を作るのではなく、質問者、正本、期待回答、失敗時の影響を定義できる業務に絞ります。

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

• 対象者：誰が、どの場面で使うか
• 質問範囲：答えること／答えないこと
• 正本：参照してよい文書、優先順位、文書オーナー
• 回答形式：回答文、引用、版、注意書きの要否
• 失敗時：回答保留、追加質問、問い合わせ先、有人引き継ぎ
• 成功条件：根拠到達率、根拠整合性、業務完了率、確認工数、応答時間

製品選定より先に業務・利用者・KPIを棚卸しする方法は、生成AI導入前の業務棚卸しと現場定着の進め方を参照してください。

2. 正本・更新・権限を棚卸しする

各文書に、所有者、最終更新日、適用期間、版、公開範囲、廃止状態を持たせます。少なくとも検索結果に文書名、更新日、版、原本への参照先を残すと、回答の確認と更新影響の調査がしやすくなります。

Mojiの提案：個人情報、顧客情報、営業秘密を含む可能性がある文書は、検索対象へ登録する前に、利用目的、登録可否、閲覧権限、外部のOCR・埋め込み生成・LLMなどへの送信有無を確認してください。これは検索時のアクセス制御とは別に、データを取り込む段階で決める統制です。NISTの生成AI向けAI RMFプロファイルは、生成AIのリスク管理に向けた行動を提示する補助資料として公開されています。NIST AI 600-1

社内文書を対象にするRAGでは、回答後に非表示にするのではなく、検索段階から利用者の権限に応じて取得対象を制御する設計が必要です。MicrosoftのRAG関連ドキュメントでも、プライベートコンテンツを扱う際には粒度の細かいアクセス制御が必要であり、文書レベルのアクセス制御やセキュリティフィルターが案内されています。Microsoft Learn：RAG and Generative AI

社内RAGの権限管理、オンプレミス／ローカルRAGの導入判断、シャドーAIのリスクと対策も関連します。

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

PDFを登録するだけでは、見出し、表、脚注、改訂履歴、画像内の文字が欠落・混在する場合があります。文書種別ごとに、回答に必要な情報を保てているか確認してください。

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

画像・表・図面が回答根拠になる場合は、テキストRAGの延長として一律に扱わず、OCR、VLM、マルチモーダルRAGを比較してください。VLMとOCR・マルチモーダルRAGの使い分け、マルチモーダルRAG・VideoRAGが参考になります。

4. 最小構成のベースラインを作る

最初のPoCでは、複雑なエージェントや特殊な検索方式を先に増やしません。対象文書、質問セット、回答ルールを固定した最小構成を作り、後から加える変更と比較できる基準を持ちます。

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

• 取得した根拠にない内容を断定しない
• 根拠が不足する場合は「確認できない」とし、原本または問い合わせ先を案内する
• 重要な回答には文書名、版、該当箇所を示す
• 部署、製品、適用時点が曖昧な質問には、回答前に確認質問を返す

5. 評価データを回答実装より先に作る

評価データは「質問」と「理想回答」だけで作りません。期待する根拠、回答してはならない条件、重要度、判定者を含めます。RAGCheckerも、検索と生成を分けた詳細な診断の必要性を示しています。RAGChecker原論文

作成・品質確認・更新の詳細は、RAG評価データセットの作り方で解説しています。

6. 検索・根拠整合性・業務品質・運用を分けて評価する

1. 検索品質：期待根拠が候補に含まれるか。
2. 根拠整合性：回答中の重要な主張が、取得根拠で裏付けられるか。
3. 業務品質：利用者が次の業務へ進める回答になっているか。
4. 運用品質：応答時間、失敗率、更新反映の遅れ、確認工数を許容できるか。

LLMを評価者として使う場合は、大量の一次判定を補助できますが、評価基準を明文化し、重要ケースは人が抜き取り確認します。LLM as a judge（自動評価）、AIの評価とはも参照してください。

7. 文書更新と障害対応を通常業務へ組み込む

本番運用では、更新通知、再インデックス、旧版の除外、評価セットの追加、障害時の切り戻しを担当業務として定義します。NISTのAI RMFは任意利用のリスク管理フレームワークであり、AIの設計、開発、利用、評価へ信頼性の考慮を組み込むことを目的としています。AI RMF 1.0のコアはGOVERN、MAP、MEASURE、MANAGEの4機能で構成されます。NIST AI Risk Management Framework、NIST AI RMF Core

PoC合否に使うRAG評価チェックリスト

以下はMojiによるチェックリストです。チェック数だけで本番化を決めず、重要度の高い質問で何が失敗したかを確認してください。

• □ 実際の質問、言い換え、曖昧な質問、誤字を含む質問で検索を確認した
• □ 正しい根拠が候補に入らない質問を特定した
• □ 最新版より旧版・ドラフトが優先されていない
• □ 回答の重要な主張ごとに、確認可能な根拠を示せる
• □ 根拠がない質問に対して、もっともらしい回答を作らず保留できる
• □ 権限の異なる利用者で、検索結果・引用・キャッシュが分離されている
• □ 重要度の高い質問を業務担当者が評価している
• □ 文書更新後に、影響する質問を再評価する手順がある
• □ 回答時間、トークン量、再試行率、確認工数を測定できる
• □ 重大な誤答または情報開示時の停止条件・連絡経路がある

費用を左右する条件：文書数だけでは見積もれない

特に、スキャンPDF、複雑な表、頻繁な改訂、部門別の厳格な権限管理がある場合は、データ整備と運用設計の比重が大きくなります。PoCでは対象範囲を限定し、品質だけでなく、更新作業と確認工数も記録してから対象を拡大してください。

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

Graph RAG：データ全体の関係・テーマを問うとき

Graph RAGは、人物、組織、製品、施策などの関係性や、文書集合全体にまたがるテーマを扱う必要がある場合の候補です。MicrosoftのGraphRAGでは、データセット全体のテーマを問うような質問に対し、コミュニティレポートを使うグローバル検索を案内しています。一方、コミュニティ階層の選択は、回答の詳細さだけでなく、実行時間やLLMリソースにも影響します。Microsoft GraphRAG：Global Search

通常のRAGで、検索漏れ、メタデータ不足、文書構造の問題を確認する前にグラフ化を始めると、原因と効果を比較しにくくなります。Graph RAGと従来RAGの違いを参照してください。

Agentic RAG：再検索・分解・ツール利用が必要なとき

Agentic RAGは、質問を分解し、複数回の検索やツール利用を行う設計です。複雑な調査に役立つ場合がある一方、実行経路、検索回数、待ち時間、コスト、失敗パターンも増えます。導入時は、再検索する条件、人に引き継ぐ条件、外部操作を許可しない条件を評価可能な形で定義してください。

エージェンティックRAGとは、AIエージェントのガードレール設計もあわせて確認してください。

まとめ：RAG導入は「根拠を管理できる業務か」から判断する

RAGは、更新される文書を検索し、根拠を添えて回答する仕組みとして有力です。ただし、導入成否はLLM単体では決まりません。次の順で進めると、比較と改善をしやすくなります。

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

RAGは「文書を入れれば答えてくれる機能」ではなく、原本データ、検索、回答ルール、権限、評価、更新運用を一つのシステムとして扱う設計です。まずは、正本と評価基準を定められる小さな業務から検証してください。