AI実装録 / RAG の採用判断
RAG の採用判断 — 使わないという選択肢
最終更新: 2026年7月30日
「自社の情報を AI に扱わせたい」という要件に対して、RAG は現在の定石とされています。 しかし RAG は検索基盤・更新パイプライン・権限設計を伴う運用コストの高い構成であり、要件によってはより単純な構成で足ります。
本稿では、RAG が本当に必要になる条件と、使わない場合の選択肢を整理します。
RAG とは何か
RAG（Retrieval-Augmented Generation）とは、利用者の質問に応じて関連情報を検索し、その結果をモデルへの入力に加えて回答を生成する構成です。 モデルが学習していない自社固有の情報を、モデルを再学習させることなく扱えることが利点です。
重要なのは、RAG が解決するのは「生成のたびに、どの情報を渡すかが変わる」という問題だという点です。 渡す情報が毎回同じなら、検索は不要です。
RAG が有効になる条件
当社では、次の条件が重なる場合に RAG を検討します。
- 情報が頻繁に更新される：日次以上の更新があり、事前の作り置きが陳腐化する。
- 情報量が多く、全文を入力に載せられない：モデルの文脈長を大きく超える文書群を対象にする。
- 利用者によって見える範囲が異なる：権限に応じて参照可能な情報を分ける必要がある。
- 質問が事前に予測できない：自由な質問に対して、都度関連箇所を特定する必要がある。
逆に言えば、これらに当てはまらない要件に RAG を導入すると、検索品質の調整・インデックス更新・権限フィルタの検証という運用負荷だけを抱えることになります。
RAG が適する典型例
条件が揃いやすい業務の例を二つ挙げます。
問い合わせ対応の補助
企業の問い合わせフォームやチャット窓口の一次応答は、RAG の条件が揃いやすい領域です。 製品仕様・料金・手続きは改訂が続き、質問は自由形式で、参照すべき文書は文脈長に収まりません。
設計上の要点は次のとおりです。
- 答えられない質問を無理に生成させない：確信の持てない質問は「担当者におつなぎします」に倒し、人間へのエスカレーション経路を最初から設計します。
- 回答に出典を付ける：どの文書のどの記載に基づく回答かを利用者に示します。誤答の検知と訂正が利用者側でも可能になります。
- 回答ログを改善に回す：答えられなかった質問は、FAQ 文書側の不足を示すデータです。検索の調整だけでなく、元文書の拡充に使います。
システムマニュアル・社内規程の参照補助
業務システムの操作マニュアルや社内規程は、量が多く、バージョン更新があり、利用者の質問が予測できないという点で RAG に適します。 「マニュアルのどこに書いてあるか分からない」という探す時間の削減が主な価値であり、この用途では 回答文の生成よりも、該当箇所の特定と提示 に重心を置く設計が堅実です。
- 回答には必ずマニュアルの版数と該当節を併記し、最終確認は原文で行える形にします。
- 旧版の記述が回答に混入しないよう、版の切替時にインデックスの入替を運用手順に組み込みます。
いずれの用途でも、RAG は「担当者の代替」ではなく「一次案内と検索の補助」と位置づけ、判断を伴う回答は人間に接続することを基本とします。
使わない場合の選択肢
- 事前生成（バッチ編纂 + 静的配信）：内容が安定しているなら、LLM による生成を事前にバッチで行い、結果を静的に配信します。利用時のレイテンシとコストはゼロになり、出力の検証を配信前に済ませられます。
- 全文同梱：対象文書が文脈長に収まる規模なら、検索せず全文を入力に含めます。構成は最も単純で、検索漏れという故障モードが存在しません。
- 従来の検索：「関連文書を見つけたい」だけであれば、全文検索エンジンで足りる場合があります。生成が本当に必要かを先に問います。
当社が運営する京都の街コンテンツ配信基盤では、RAG を採用していません。
通りごとの解説コンテンツは、情報源（Wikipedia・自治体公式）の更新が緩やかで、対象も数十件と有限です。 このため、週次〜月次のバッチで LLM が構造化 JSON を編纂し、検証を通過したものを静的に配信する 事前生成 構成を選びました。
- 利用時に LLM を呼ばないため、応答は静的ファイル配信の速度で、利用量に比例する推論費用も発生しません。
- 出典とライセンス表記の検証を 配信前に 確定できます。RAG のように生成のたびに出典が変わる構成では、この検証は利用時に行うことになります。
「更新が緩やか・対象が有限・質問の形が固定」という条件が揃っていたため、RAG の運用コストを負う理由がありませんでした。
採用判断の整理
| 観点 | RAG が向く | 事前生成・全文同梱で足りる |
|---|---|---|
| 更新頻度 | 日次以上 | 週次以下 |
| 情報量 | 文脈長を大きく超える | 有限・文脈長に収まる |
| 権限分離 | 利用者ごとに異なる | 全員同じものを見る |
| 質問の形 | 自由・予測不能 | 定型・事前に列挙できる |
ベクトルデータベースの導入自体が目的化し、要件の検討より先に構成が決まっているケースです。 この場合、次の費用が見積りから漏れがちです。
- 検索品質の調整（チャンク分割・埋め込みモデル選定・検索結果の評価）
- 情報更新のたびに走るインデックス再構築のパイプライン運用
- 権限フィルタの設計と、その検証（権限を越えた情報が回答に混ざらないことの担保）
構成の複雑さは、そのまま障害モードの数になります。単純な構成で足りる要件に複雑な構成を当てないことが、運用の安定に直結します。
まとめ
RAG は「生成のたびに渡す情報が変わる」問題への解であり、それ以外の要件には過剰な構成です。 更新頻度・情報量・権限分離・質問の形の四点で要件を確認し、事前生成や全文同梱で足りるならそちらを選ぶ——「使わない」を含めた採用判断こそが設計です。
権限を伴う情報の取扱いについては データ・セキュリティ、モデルの使い分けについては モデル選定と多層構成 で扱っています。