既存SaaSにRAGを組み込む前に決めること
「社内のマニュアルやFAQをAIに読ませて、チャットで質問すれば答えてくれるようにしたい」「プロダクト内のドキュメントに対してユーザーがAIに質問できる機能をつけたい」——ChatGPTの普及以降、この手の相談が急増しています。技術的には難しくなさそうに見えるのに、いざPoCを作ってみると「もっともらしい嘘」を返してきて止まる、という壁にほぼ全員がぶつかります。
RAG(Retrieval-Augmented Generation)は、既存SaaSに後付けできる機能です。作り直しは不要です。ただし「対象データを絞らず全部読ませる」「精度要件を決めずに作り始める」といった順序を間違えると、PoCで止まって終わります。この記事では、既存プロダクトにRAGを組み込む前に決めておくべきことを、発注者(PdM/CTO)向けに整理します。
RAGの仕組みを噛み砕く
RAGは「AIに社内文書を丸ごと学習させる」わけではありません。仕組みは次の3ステップです。
- 検索(Retrieval): ユーザーの質問を受けたら、まず社内文書・DBの中から関連しそうな箇所を検索で探す。ここは前記事で扱ったAI検索の後付けと同じ仕組み(埋め込み+ベクトル検索)を使う
- 抽出: 検索で見つかった関連箇所(数件〜数十件)だけを、AIモデルへの入力に含める
- 生成(Generation): 「この文書を根拠に、この質問に答えてください」という形でLLMに投げ、回答を生成させる
つまりRAGの「R」(検索)が精度の9割を決めます。生成AIのモデル自体を変えるより、検索でどれだけ的確な根拠を拾えるかのほうが、回答品質への影響が大きいという理解が重要です。「AIが賢くない」と感じる不具合の多くは、実際には「検索が的外れな箇所を拾ってきている」ことが原因です。
導入前に決めること1: 対象データの境界
最初によくある失敗が、「社内の全ドキュメントを対象にする」という無限定なスコープ設定です。これはPoCが終わらない最大の原因になります。
- まず1つの用途に絞る: 「カスタマーサポートのFAQ」「社内規定」「プロダクトのヘルプページ」など、質問の種類がある程度予測できる領域から始める。用途を絞ると検索対象データも絞れ、精度検証がしやすくなる
- データの鮮度と正確性を確認する: 古い版のマニュアルが混在していないか、矛盾する記述が複数箇所にないか。RAGは「文書に書かれていることをそれらしく答える」ため、元データが古ければ古い回答を自信満々に返す
- アクセス権限との整合: 部署限定の文書、顧客ごとに閲覧範囲が異なるデータなどが混在する場合、検索時にユーザーの権限でフィルタする設計が要る。ここを後回しにすると、権限外の情報が回答に漏れるセキュリティ事故になる
導入前に決めること2: 精度要件と評価方法
「精度を上げてください」という発注はほぼ確実に迷走します。何を測るかを先に決める必要があります。
- 正解セットを用意する: 実際に聞かれそうな質問と、期待する回答(または根拠文書)のペアを最低30〜50件は用意する。これがないと「良くなった」の判断ができない
- 評価軸を分ける: (a) 検索が正しい文書を拾えているか(Retrieval精度)、(b) 拾った文書から正しく回答を生成できているか(Generation精度)、の2軸で分けて評価する。この2つを混ぜて「なんとなく合ってる/間違ってる」で評価すると、どこを直せばいいか分からなくなる
- 目安値: 用途にもよりますが、社内ナレッジ用途であれば正解セットに対する「根拠文書の的中率」8割前後、「人間が見て許容できる回答」9割前後が最初の目標ラインとして現実的です。100%は目指さない(後述)
ハルシネーション対策は「防ぐ」より「気づける」設計
RAGを入れても、LLMが文書にない内容を作り出す「ハルシネーション」はゼロにはなりません。ゼロを目指すのではなく、間違いに気づける・被害を抑える設計にするのが現実的です。
- 根拠を必ず提示する: 回答と一緒に、参照した文書へのリンクや抜粋を表示する。ユーザーが「本当にそう書いてあるか」を確認できるだけで、誤情報がそのまま信じられるリスクは大きく下がる
- 「分からない」と言わせる: 関連文書が見つからない場合に無理に答えを生成させず、「該当する情報が見つかりませんでした」と返すようプロンプトを設計する。これだけでハルシネーションの体感頻度はかなり下がる
- 回答対象を限定する: 「文書に書かれている内容にのみ基づいて回答する」という制約をプロンプトに明示する。一般知識で補完させない
- 重要な業務(契約・医療・金銭が絡む判断)ほど人間の確認を挟む: 全自動回答にせず、社内向けであれば「ドラフト回答+担当者が確認して送信」のような一段挟む設計が安全
既存DBへの後付け: 何を追加するか
既存のRailsアプリ・PostgreSQLを使っている場合、RAGのために新しい基盤をまるごと立てる必要はありません。
- pgvectorを既存DBに導入し、文書の埋め込みベクトルを保存するテーブル(またはカラム)を追加する。既存の商品テーブルや記事テーブルとは別に、「ナレッジチャンク」用のテーブルを新設するのが一般的
- 既存文書(PDF・Notion・Confluence・DBの既存カラムなど)をチャンク分割(意味のまとまりごとに数百字単位で区切る)してから埋め込み生成する前処理バッチが必要になる。ここが実装工数の中心で、AI呼び出し自体より前処理の設計に時間がかかることが多い
- 文書が更新されるたびに再チャンク・再埋め込みする仕組み(バッチ or フック)を用意しないと、時間とともに回答が古い情報を参照し続ける
- LLM呼び出し部分はOpenAIやClaudeのAPIを使うのが一般的で、既存アプリからのAPI連携という点では他のAI機能後付けと同じ構成になる
つまり「pgvectorで検索基盤を足す」+「文書のチャンク化・更新パイプラインを作る」+「LLM APIへの問い合わせ処理を足す」の3点セットで、既存SaaSに追加する形になります。ゼロから専用システムを構築するより工数は小さく収まります。
コストの内訳
RAGのランニングコストは主に3つに分かれます。
- 埋め込み生成コスト: 初回の一括変換+以降の差分更新分。文書量が数万ページ規模でも、embedding APIの単価自体は低く、突出したコストにはなりにくい
- LLM呼び出しコスト: 質問1件ごとにLLMへ投げる根拠文書の量(トークン数)とモデルの単価で決まる。根拠文書を無制限に詰め込むとコストも精度も悪化するため、検索で「本当に関連する数件」に絞り込む設計がコスト最適化にも直結する
- 運用コスト: 文書更新の追従、精度モニタリング、プロンプトのチューニングなど、リリース後も継続的にかかる。ここをゼロと見積もって予算化すると、運用開始後に「誰がメンテするのか」で止まる
PoCで終わらせないために
RAGは「デモではそれっぽく動く」典型例でもあります。PoCから本番運用に進めるための考え方は、AI機能全般に共通する論点としてAI PoCが本番化しない理由と、失敗させない進め方で詳しく整理しています。RAG特有の観点としては、以下を本番投入前のチェックポイントにすることをお勧めします。
- 正解セットに対する評価が、事前に決めた基準(的中率・許容回答率)を満たしているか
- 文書の更新が自動的にベクトル・チャンクへ反映される運用になっているか
- 権限外データが回答に漏れない設計になっているか
- ハルシネーション時に被害が限定的な業務から先行リリースしているか
外注する場合に確認しておきたい点
RAG機能の実装を外部に依頼する場合、次を着手前に確認しておくと手戻りが減ります。
- 検索(Retrieval)と生成(Generation)を分けて評価する設計になっているか。「なんとなく動く」で終わらせず、正解セットでの数値評価を提案してくるか
- 対象データのスコープを絞る提案をしてくるか。「全社ドキュメントを最初から対象にする」提案は要注意
- 権限・アクセス制御の設計が、検索クエリレベルで組み込まれているか
- チャンク分割・埋め込み更新の運用設計まで含めて見積もっているか(初回構築だけで終わらせない)
- 既存DB(pgvector等)への後付けを前提とし、専用ベクトルDBが本当に必要な規模か判断できるか
RAGは「既存プロダクトに知識検索の機能を足す」改善であり、プロダクト全体の作り直しは不要です。ただし対象データの絞り込み・評価方法・ハルシネーション対策を決めずに着手すると、PoCが終わらない・本番化できないという結果になりやすい領域でもあります。
torcheees では Rails/PostgreSQL(pgvector)を用いたAI機能開発の支援 を行っており、AI・LLM活用の技術支援 を軸に、既存SaaSへのRAG後付けにも対応しています。検索基盤の後付けそのものについては既存プロダクトにAI検索を後付けする進め方も合わせてご覧ください。RAGに限らず、既存プロダクト改善に着手する前にまず何を見るべきかは既存プロダクトの改善、外部チームが最初に見る観点で整理しています。
まとめ
- RAGは「検索(Retrieval)」の精度が回答品質の9割を決める。対象データのスコープを絞り、正解セットでRetrieval/Generationを分けて評価する設計が不可欠
- ハルシネーションはゼロにできない前提で、根拠提示・「分からない」と言わせる設計・重要業務への人間確認を組み込むことでリスクを抑える
- 既存のPostgreSQLにpgvectorを足し、文書のチャンク化・埋め込み更新パイプラインを追加する形で、作り直しせず既存SaaSに後付けできる
「社内文書やFAQにAIで答えさせたいが、何から決めればいいか分からない」という段階でも構いません。torcheees の「既存プロダクト改善」診断では、対象データの棚卸しから精度要件の設計、既存DBへの後付け方針まで含めてご提示します。お問い合わせフォームからお気軽にご相談ください。