RAG（Retrieval-Augmented Generation） とは、日本語で「検索拡張生成」と訳される。LLM（大規模言語モデル）が回答を生成する前に、外部の知識源から関連情報を検索して、その情報を踏まえて回答する仕組みである。

業務AIの実装では、ほぼ標準的なアーキテクチャとなっており、2026年現在は基本的な「ベクトル検索 → LLM 生成」のシンプル構成から、Hybrid Search + Rerank の本番パターン、GraphRAG、Agentic RAG といった派生形まで多様化している。

なぜRAGが必要なのか

LLM単体には、業務AIで致命的な弱点が3つある。

  1. 学習データのカットオフ: モデルは学習時点までの情報しか知らない。最新情報や社内固有情報は持っていない
  2. ハルシネーション: 知らない情報について「もっともらしい嘘」を生成しがち
  3. 社内データの不在: ChatGPT が自社の業務マニュアル・顧客データ・過去の議事録を知っているわけではない

RAGはこの3つを構造的に解決する。**「LLMに毎回、関連する社内ドキュメントを参照させてから回答させる」**ことで、最新性・正確性・固有性を担保する。

ハルシネーション対策の全体論はAIハルシネーション対策の実装論近日公開で詳述している。

RAGの基本的な仕組み

RAGは大きく以下の流れで動く。

ユーザー質問
   ↓
[1] 質問を埋め込みベクトルに変換
   ↓
[2] ベクトルDBで類似度の高い文書を検索（Top-K）
   ↓
[3] 検索された文書を「コンテキスト」としてLLMに渡す
   ↓
[4] LLMがコンテキストを参照して回答生成
   ↓
ユーザーへ回答

ステップ[2]の「ベクトル検索」では、Pinecone、Weaviate、Qdrant、ChromaDB、PostgreSQL（pgvector拡張）などが使われる。Embedding モデルは OpenAI text-embedding-3、Cohere embed-v3、BGE、Voyage AI 等が選択肢となる。

2026年の本番RAGアーキテクチャ

シンプルな「Embed → 検索 → LLM」だけでは本番の精度要件を満たさないケースが多い。2026年の本番運用では以下のパターンが標準となっている。

Hybrid Search + Rerank パターン

質問
  ↓
[1] Hybrid Search（ベクトル検索 + キーワード検索 BM25）
  ↓ Top 50候補を取得
[2] Reranker でTop 5に再順位付け
  ↓
[3] LLM に渡して回答生成

Hybrid Search は、意味的類似性（ベクトル）と語彙的一致（BM25）の両方を活用することで単独のベクトル検索より高精度。Reranker は Cohere Rerank、BGE Reranker 等が使われ、検索品質を 15-30% 向上させると報告されている。

2026年の標準スタック

業界のベストプラクティスは以下の組み合わせに収束しつつある。

  • オーケストレーション: LangGraph
  • 検索: LlamaIndex Workflows
  • 評価: Ragas + Phoenix + Langfuse
  • ベクトルDB: Pinecone / Weaviate / Qdrant
  • Embedding: OpenAI text-embedding-3 / Voyage / Cohere

技術選定の論点は業務AIインフラの技術選定近日公開で詳しく扱っている。

GraphRAGとAgentic RAG — 2026年の発展形

GraphRAG（グラフRAG）

エンティティ間の関係性が重要な知識ベースでは、ベクトル検索だけでは「複数のエンティティを横断する推論」が苦手。GraphRAG は知識グラフ（Knowledge Graph）をベクトルインデックスと並行して構築し、グラフ上のトラバーサル（探索）でコンテキストを拡張する。

LinkedIn の GraphRAG 導入事例では、複数の関連エンティティをまたぐ推論が必要な問い合わせで、サポート解決時間が標準RAGより28.6%短縮された。Gartner は GraphRAG を2026年のデータ・アナリティクスの主要トレンドの一つに挙げている。

Agentic RAG（エージェント型RAG）

LLM 自身が検索プロセスを制御する形態。複数のクエリを発行し、部分的結果を統合し、コンテキストが十分かを判断する。

トレードオフとして、Agentic RAG は通常RAGの3〜10倍のトークンコスト、2〜5倍のレイテンシがかかる。マルチホップ質問、曖昧なクエリ、高リスク領域（法務・医療・金融）でこのコストを正当化する価値がある。Vectara の見立てでは、複雑な Agentic RAG ワークフローは2026〜2027年に主流化する。

AIエージェントの基本概念はAIエージェントとはで別途整理している。

典型的なユースケース

業務でRAGがフィットする領域:

  • 社内ナレッジ検索: 過去のFAQ、業務マニュアル、議事録から関連情報を引いて回答する
  • カスタマーサポート: 製品ドキュメント・サポート履歴を踏まえた問い合わせ対応（顧客接点業務のAI活用ガイド近日公開も参照）
  • 法務・コンプライアンス: 社内規程、契約書、判例から該当条文を引きつつ回答
  • 営業支援: 過去の商談記録、顧客資料、競合情報を引きつつ提案を作成
  • エンジニアリング支援: 自社コードベース・設計ドキュメントを参照したコード生成
  • 金融機関の応対: 商品説明、規制対応、顧客対応での出典明示型応答（金融機関のAI活用近日公開）
  • 医療機関の文書作成: 電子カルテ参照型の所見書・退院サマリー生成（医療機関のAI活用近日公開）

RAG評価フレームワーク: RAGAS

RAGの品質を測定する代表的フレームワーク RAGAS（RAG Assessment） は、4つの主要指標で評価する。

指標 内容 本番目標値
Faithfulness 生成回答が検索コンテキストに忠実か（ハルシネーションがないか） > 0.9
Answer Relevancy 回答が質問に的確に答えているか > 0.85
Context Precision 検索された文書が質問に関連しているか > 0.8
Context Recall 必要な情報が検索結果に含まれているか > 0.8

これらのスコアは、生成側と検索側を分離して問題を診断できる点が特徴。Context Precision/Recall が低ければ検索改善（チャンク分割、Reranker追加等）、Faithfulness が低ければプロンプト設計の見直し、というように対処が明確になる。

評価フレームの設計論全般はAI評価フレームの実装論近日公開を参照されたい。

RAGの典型的な落とし穴

業務RAGで初心者がハマる代表パターン:

落とし穴1 / そのままドキュメントを突っ込む

PDFやWord文書をそのままベクトルDBに入れると、表・図・脚注の構造が壊れて検索精度が出ない。前処理（チャンク分割、構造化、メタデータ付与）が成果の80%を決める。チャンクサイズの最適値はドキュメント特性で異なり、256〜1024トークンの範囲で実験する。Late Chunking、Semantic Chunking、Hierarchical Chunking 等の手法が選択肢となる。

落とし穴2 / 検索精度を測定していない

「LLMがそれっぽく答えている」と「検索が正しい文書を引いている」は別問題。検索段階の精度（Precision、Recall）を独立に評価する仕組み（RAGAS等）が必要。

落とし穴3 / 文書更新に追従できない

社内文書は常に更新される。インデックスの再構築・差分更新の仕組みを最初から設計しないと、半年後には古い情報を返す RAG になる。CDC（Change Data Capture）パターンでの差分更新、定期 reindexing の運用設計が必要。

落とし穴4 / Rerank を入れていない

ベクトル検索の Top-K（例 Top 50）をそのまま LLM に渡すと、ノイズが多く回答精度が下がる。Reranker で Top 5 に絞ることで品質が大きく改善する。

落とし穴5 / Hybrid Search を入れていない

ベクトル検索だけでは「固有名詞」「型番」「正確な用語」の検索が苦手。BM25 等のキーワード検索を併用する Hybrid Search が必須。

落とし穴6 / コスト管理の甘さ

Embedding コスト、Reranker コスト、LLM 生成コストの合計が予算を超えやすい。クエリ数 × Top-K × トークン数のコスト構造を初期から設計する。

長文コンテキストモデル vs RAG

Claude 4.6（1M トークン）、Gemini 2.5（2M トークン）など、超長文コンテキストモデルの登場で「もう RAG いらないのでは」という議論が起きている。実務的には以下の整理が定着しつつある。

  • 長文コンテキスト: 1回のクエリで参照する文書が固定で、かつ毎回同じ範囲を参照する場合に有効。プロンプトキャッシングと組み合わせれば実コストも下がる
  • RAG: 大規模文書群から関連箇所のみを抽出する場合、文書更新が頻繁な場合、出典明示が必要な場合に依然として優位

両者は補完関係であり、ハイブリッド構成が現実解。

Fine-tuningとの違い

RAGとFine-tuningはしばしば対比される。両者は補完関係にある。

観点 RAG Fine-tuning
目的 「知識」を与える 「振る舞い」を変える
データ更新 容易（DBを更新するだけ） モデル再学習が必要
初期コスト 低 高
出典明示 可能 困難
適用シーン 社内データを参照させる 特定の言い回し・出力形式を学ばせる

2026年の推奨アプローチは「Prompt → RAG → Fine-tune → Distill」の順で試すこと。多くのケースで RAG だけで業務要件を満たす。Fine-tuning を組み合わせるのは「特定の出力形式」「ドメイン固有の言い回し」を厳密に守らせたい場合に限られる。詳細はFine-tuning vs RAGを参照。

まとめ

RAGは、業務AIの「LLMが社内のことを知らない」問題を解決する標準アーキテクチャである。実装そのものは現代のフレームワーク（LangGraph、LlamaIndex Workflows 等）で難しくないが、前処理・評価・更新運用の設計で成果が大きく変わる。

2026年の業務 RAG プロジェクトでは、以下を意識すべきである。

  1. シンプルな構成から始めて、必要に応じて Hybrid Search、Rerank、GraphRAG、Agentic RAG へ拡張する段階的アプローチ
  2. RAGAS 等で検索品質と回答品質を独立に評価する仕組み
  3. 文書更新・運用のサイクルを最初から設計
  4. コスト構造の継続モニタリング

FDE型コンサル等のAI支援を選ぶ際の枠組みはAX支援サービスの選び方、AI導入の意思決定全般はFDE型コンサルティング完全解説、PoC脱出論はAI PoC止まり脱出フレームワークで扱っている。

関連記事: