実務で使えるRAGシステム構成【完全ガイド】

RAG（Retrieval Augmented Generation）は、企業向けAI導入において最も実用化が進んでいるアーキテクチャの一つです。
しかし、PoCではうまく動いても、本番環境では 検索精度・権限制御・運用改善・コスト管理 の壁にぶつかることが少なくありません。

実務で使えるRAGを作るには、単に LLM + Vector DB を繋ぐだけでは不十分です。
必要なのは、検索・生成・評価・運用を一体で設計すること です。

本記事では、実務で通用するRAGシステム構成を、設計・実装・運用の観点から整理します。

---

RAGとは

RAGは、ユーザーの質問に対して関連文書を検索し、その検索結果をもとにLLMが回答を生成する仕組みです。

User Question
      ↓
Retriever
      ↓
Relevant Documents
      ↓
LLM
      ↓
Answer

この構成により、以下のような用途が実現できます。

• 社内ナレッジ検索
• FAQ自動回答
• AIチャットボット
• マニュアル検索
• 業務支援アシスタント

---

なぜRAGが必要なのか

LLM単体には、以下のような限界があります。

• 学習済み知識に依存する
• 企業固有の情報を知らない
• 最新情報を反映しにくい
• hallucinationが発生する

RAGでは、外部データを検索してから回答を生成するため、次の改善が期待できます。

• 社内情報を活用できる
• 根拠付き回答が可能
• 最新ドキュメントに追従しやすい
• hallucinationを抑制しやすい

---

RAGがPoCで終わりやすい理由

RAGのPoCでは、以下のような最小構成で始まることが多いです。

User → Vector DB → LLM → Answer

この構成は分かりやすい反面、本番では多くの問題が発生します。

よくある失敗

• Vector検索だけで精度が出ない
• Chunk設計が適当
• metadataがない
• 評価指標がない
• 権限制御がない
• ログがない
• 改善ループがない

つまり、AI機能としては成立していても、業務システムとして設計されていない ことが問題です。

---

実務で使えるRAGの全体アーキテクチャ

本番運用を前提にしたRAGは、以下のような構成になります。

User
 ↓
Web / Chat UI
 ↓
API Gateway
 ↓
Application Backend
 ├─ Authentication / Authorization
 ├─ Session / Conversation Management
 ├─ Query Processing
 ├─ Prompt Builder
 └─ Logging
 ↓
Retriever Layer
 ├─ Query Embedding
 ├─ Vector Search
 ├─ Keyword Search
 ├─ Hybrid Search
 └─ Re-ranking
 ↓
Context Builder
 ↓
LLM
 ↓
Answer + Citation + Feedback

さらに、裏側にはナレッジ投入基盤が必要です。

Documents
(PDF / DOCX / HTML / FAQ / DB / CSV)
      ↓
Ingestion Pipeline
      ↓
Text Extraction
      ↓
Cleaning / Normalization
      ↓
Chunking
      ↓
Embedding
      ↓
Vector Database

レイヤーごとの役割

1. UIレイヤー

ユーザーが質問する入口です。

代表例

• Webチャット
• 社内ポータル
• Slack / Teams Bot
• 管理画面

実務では、単なるチャットUIではなく以下が重要です。

• 根拠表示
• 引用元表示
• フィードバック導線
• エスカレーション導線

---

2. Application Backend

RAG全体を制御する中核層です。

主な役割

• 認証 / 権限制御
• 質問の前処理
• 会話履歴管理
• 検索クエリ生成
• Prompt構築
• ログ保存
• LLM呼び出し制御

この層を切り出しておくことで、LLMやVector DBを差し替えても、全体構造を維持しやすくなります。

---

3. Retriever Layer

RAG精度を最も左右する部分です。

主な処理

• Query Embedding
• Vector Search
• Keyword Search
• Hybrid Search
• Re-ranking

実務では、単純なVector Searchだけでは不十分なケースが多く、以下の構成がよく使われます。

Vector Search
+
Keyword Search
+
Re-ranking

これにより、意味的類似性 と キーワード一致 の両方を活用できます。

4. Context Builder

検索結果をそのままLLMに渡すのではなく、回答に必要な文脈を整理する層です。

主な役割

• 上位文書の選定
• 重複排除
• 長さ制御
• metadata付与
• 引用情報の整形

ここが弱いと、不要な情報が増えたり、重要な文脈が欠けたりして、回答精度が安定しません。

---

5. LLM Layer

最終回答を生成する層です。

主な役割

• 文脈をもとに自然言語で回答
• 必要に応じて要約
• 回答形式の統一
• 引用付き出力

重要なのは、LLMに自由回答させるのではなく、使ってよい情報源と出力ルールを明示すること です。

提供されたコンテキストのみを使って回答すること
不明な場合は「情報が見つかりません」と答えること
推測で補完しないこと

データ投入基盤（Ingestion Pipeline）

実務RAGでは、検索前のデータ設計 が非常に重要です。

対象データ

• PDF
• DOCX
• HTML
• FAQ
• 社内Wiki
• DBデータ
• CSV / Excel

基本フロー

Document Upload
      ↓
Text Extraction
      ↓
Cleaning
      ↓
Chunking
      ↓
Embedding
      ↓
Indexing

Chunking設計

ChunkingはRAG精度に大きく影響します。

ベストプラクティス

• 500〜1000 tokens程度で分割
• セクション単位で意味を切る
• 見出し情報を保持する
• metadataを付与する

metadata例

{
  "source": "manual.pdf",
  "department": "support",
  "version": "v2",
  "language": "ja"
}

NGパターン

• PDF丸ごと1chunk
• ランダム分割
• metadataなし

Chunkが大きすぎるとノイズが増え、短すぎると文脈が切れてしまいます。

---

実務でよくある技術スタック

Layer	Technology Example
Frontend	React / Next.js
Backend	NestJS / FastAPI
LLM	OpenAI / Claude / Azure OpenAI
Embedding	OpenAI Embeddings / bge / e5
Vector DB	Pinecone / Weaviate / pgvector
Storage	MinIO / S3
Queue	Redis / BullMQ
Monitoring	Prometheus / Grafana
Logging	ELK / OpenSearch

---

検索精度を上げる方法

Hybrid Search

実務では、Vector Searchだけに依存しないことが重要です。

Vector Search
+
Keyword Search
+
Re-ranking

Re-ranking基準

• semantic similarity
• keyword match
• document score
• metadata priority

Vector検索は便利ですが、それだけでは精度が安定しないケースが多くあります。

---

RAGとFine-tuningの違い

AI導入では、RAGとFine-tuningの使い分けがよく議論されます。

Approach	特徴
RAG	外部データを検索して回答に利用する
Fine-tuning	モデル自体を追加学習して振る舞いを変える

RAGのメリット

• データ更新が容易
• 最新情報を反映しやすい
• hallucinationを抑制しやすい
• 比較的低コストで始めやすい

Fine-tuningのメリット

• 特定タスクに強い
• 応答スタイルを制御しやすい
• 業務特化の精度改善が可能

実務で多い構成

RAG
+
Prompt Engineering
Optional Fine-tuning

Prompt設計

LLMの暴走を防ぐには、Prompt設計が重要です。

提供された情報のみを使って回答すること
不明な場合は「情報が見つかりません」と回答すること
推測で補完しないこと

ただし、Promptだけで品質を改善しようとするのは危険です。
検索やデータ設計に問題がある場合、Promptだけでは限界があります。

認証・権限制御

企業向けRAGでは、権限制御 は必須です。

例

• 部署ごとに参照できる文書を制御
• 顧客ごとにデータを分離
• ロールごとに表示範囲を変更

RAGは 「検索できること自体がリスク」 になるため、アクセス制御がないと重大なセキュリティ問題になります。

---

会話履歴管理

会話型UIでは、直前の質問文脈を扱う必要があります。

例

• 前の質問を踏まえたFollow-up
• 会話要約
• セッション単位の履歴保持

ただし、履歴を無制限に渡すとコストとノイズが増えるため、要約戦略 が重要です。

---

ログと監査

本番運用では、以下を記録する必要があります。

• ユーザー質問
• 検索結果
• 生成回答
• 利用したドキュメント
• フィードバック
• エラー

これにより、誤回答分析や改善ループを回せるようになります。

---

評価設計

RAGは、評価なしに品質を語れません。

主な評価指標

Metric	説明
Retrieval Recall	正しい文書を拾えているか
Answer Accuracy	回答が正しいか
Hallucination Rate	誤回答率
Citation Accuracy	引用の正確性
Latency	応答速度

評価フロー

Test Question Set
      ↓
Retriever Evaluation
      ↓
LLM Response Evaluation
      ↓
Human Review
      ↓
Improvement

代表質問セットを用意し、継続的に比較できる状態を作ることが重要です。

---

コスト最適化

RAGは、LLMコストだけでなくEmbeddingやVector DBコストも発生します。

主なコスト

• Embedding
• LLM inference
• Vector DB
• Storage
• Monitoring

最適化ポイント

• キャッシュ
• 小さいモデルの利用
• 必要最小限のコンテキスト
• バッチEmbedding
• 検索結果の上位件数調整
• プロンプト圧縮

Cache
+
Smaller Model
+
Optimized Retrieval
+
Prompt Compression

本番運用（ここが差になる）

RAGは作って終わりではありません。
本番では以下の運用が必要です。

必須運用

• モニタリング
• 誤回答分析
• データ更新
• Prompt改善
• Retriever改善
• 権限制御確認
• コスト監視

改善ループ

User Feedback
      ↓
Error Analysis
      ↓
Data / Prompt / Retrieval Update
      ↓
Re-evaluation
      ↓
Production Deployment

改善対象は主に以下です。

• データ不足
• Chunking不適切
• 検索精度不足
• Prompt不適切
• 権限制御漏れ

---

実用構成で失敗しやすいポイント

1. データ整理をせずにRAGを作る

ナレッジが整理されていないと、検索品質が安定しません。

2. Vector Searchだけに依存する

キーワード条件が重要なケースでは、Hybrid Searchが必要です。

3. Promptだけで品質を上げようとする

検索やデータ設計に根本原因がある場合、Promptだけでは限界があります。

4. 評価セットがない

改善前後の比較ができず、品質が運用任せになります。

5. 権限制御を軽視する

企業導入では重大なセキュリティ問題になります。

---

実用的な最小構成

PoCから本番初期へ進む段階では、以下の最小構成が現実的です。

User
 ↓
Chat UI
 ↓
Backend
 ↓
Hybrid Retriever
 ↓
LLM
 ↓
Answer + Citation

裏側には以下を持ちます。

• Document ingestion
• Chunking
• Embedding
• Vector DB
• Logging
• Feedback collection

これにより、最小限のコストで本番導入しやすくなります。

---

CTO向けチェックリスト

データ

• 対象ナレッジが整理されている
• metadata設計がある
• 更新フローがある

検索

• Vector SearchだけでなくKeyword Searchも検討している
• Re-rankingがある
• Chunking方針が決まっている

セキュリティ

• 権限制御がある
• ログ監査ができる
• 機密情報の扱いが定義されている

運用

• 評価セットがある
• フィードバックループがある
• コスト監視がある

---

まとめ

RAGの実務構成は、単なる LLM + Vector DB ではありません。
本番で価値を出すには、以下が必要です。

• データ投入基盤
• Retriever設計
• Context Builder
• 権限制御
• 評価
• ログ / 監査
• 継続改善

つまり、RAGは 「生成AI機能」 ではなく、
検索・生成・運用を統合した業務システム として設計することが重要です。

お問い合わせ先：
Webサイト：https://nkk.com.vn
メール：[e-mail]
LinkedIn：https://www.linkedin.com/company/nkktech