最終更新：2025年10月25日

RAG完全ガイド｜仕組み・構造・最新動向【2025年版】

この記事はRAGの体系ガイドです。アーキテクチャ／設計思想／最新動向を整理し、導入判断から設計・運用までを一気に俯瞰できます。

📖 読了 12分｜🎯対象：開発統括・エンジニア
🛠 難易度：★★★☆☆

この記事の結論：RAGは工程分解と評価駆動で成功する。設計はClassic→Hybrid→Agenticの順に成熟し、現場では検索品質の最適化と運用の可観測性が鍵。

要点1：アーキテクチャはETL→Index→Retrieve→Generateの工程で捉える
要点2：分類はClassic/Hybrid/Agentic。要件で選び、段階的に進化させる
要点3：評価は再現率・精度・根拠整合・有用度で回す（ログを必ず設計）

→ 用語の確認は「#3-用語」へ、実装詳細は「#4/#6/#7/#8」各記事へ。

この記事の著者・監修者　ケニー狩野（Kenny Kano）

Arpable 編集部（Arpable Tech Team）

株式会社アープのテクノロジーリサーチチーム。人工知能の社会実装をミッションとし、最新の技術動向と実用的なノウハウを発信。役職：(株)アープ取締役／Society 5.0振興協会 AI社会実装推進委員長。中小企業診断士、PMP。

Toggle

RAGとは何か？なぜ今、LLM導入に不可欠なのか

要約：RAGはLLMの「嘘・古さ・専門外」を解決し、ビジネス利用の信頼性を担保する技術。知識の「注入」を担い、振る舞いを「矯正」するファインチューニングと使い分ける。

RAG（Retrieval-Augmented Generation：検索拡張生成）とは、一言で言えば「賢い新入社員（LLM）」に「最新の社内マニュアル（外部知識）」を検索・参照させながら回答させる技術です。LLMが持つ汎用的な知性に加え、企業固有の専門知識や最新情報を組み込むことで、その回答品質を飛躍的に高めます。

2025年現在、LLMのビジネス導入がPoC（概念実証）から本番運用（Production）へ移行する中で、RAGは「必須コンポーネント」とされています。なぜなら、LLM単体が持つ以下の3つの根本的な課題を解決するからです。

RAGが解決する3大課題（Why）

ハルシネーション（情報の捏造）： LLMが事実に基づかない情報を生成する問題です。RAGは「参照すべき根拠（Citation）」を明示的に与え、その範囲内で回答を強制することで、回答の信頼性を担保します。
ナレッジ・カットオフ（情報の古さ）： LLMの学習データは特定の時点（例：2024年まで）で停止しています。RAGはリアルタイムのデータベースやWebを検索することで、最新の情報を反映した回答を可能にします。
専門性・機密性の欠如： LLMは一般的な知識しか持ちません。RAGは「社内文書」「顧客DB」「専門ナレッジベース」など、非公開の機密情報やドメイン固有の知識を安全に参照させることを可能にします。

RAG vs ファインチューニング（概念整理）

ここで、RAGとファインチューニングの役割の違いを明確にしておきましょう。両者は目的が異なり、補完関係にあります。

RAG（検索拡張生成）： 外部から「知識」を注入・更新する技術です。「何を知っているか」を担当します。
ファインチューニング： LLMの「振る舞い」や「口調・スタイル」を矯正する技術です。「どう振る舞うか」を担当します。

（例：知識の追加・更新はRAG、LLMの口調を「カスタマーサポート風」にするのはファインチューニング、と使い分けます）

RAGアーキテクチャ：工程で理解する（ETL→Index→Retrieve→Generate）

要約：工程分解は品質と責務を明確にし、テストと評価を可能にする。まずは検索側の品質を底上げする。

RAGはETL（取込・整形）、Index（索引）、Retrieve（近傍探索）、Generate（制約付き生成）の工程で構成します。ETLではチャンキング戦略・正規化・メタデータ付与を定義し、IndexではHNSW/IVF等のパラメータを選定。Retrieveはフィルタとリランキングで命中率を高め、Generateは引用必須・出典ID・禁止語で堅牢化します。

Ingestion（取り込み）フェーズ：知識を「検索可能」な形に整える

Ingestionフェーズは、RAGの「仕込み」であり、回答品質の土台となります。目的は、元のドキュメントを「検索しやすい形」に加工し、データベースに格納することです。

ETL (取込・整形) の概念 (Why)： なぜドキュメントをそのまま使えないのでしょうか？それは、LLMが一度に読める情報量（コンテキストウィンドウ）に限界があるためです。ETL工程では、長文のPDFやWebページを意味のある単位（チャンク）に分割（チャンキング）します。これにより、検索ノイズを減らし、LLMが処理可能なサイズに最適化します。（実装詳細は「#8-技術(ETL)」「#7-技術(Chunk)」へ）
Index (索引) の概念 (Why)： なぜ「ベクトル化」が必要なのでしょうか？従来のキーワード検索では「AI」と「人工知能」を別物と認識してしまいます。一方、ベクトル化（Embedding）は、単語や文章の「意味」を数値の配列（ベクトル）に変換します。これにより、「意味が近い」文書を効率的に検索することが可能になります。（実装詳細は「#6-技術(Embedding)」へ）

Generation（生成）フェーズ：検索した知識から「回答」を生成する

Generationフェーズは、ユーザーの質問（クエリ）に対し、Ingestionフェーズで準備した知識を使ってリアルタイムに回答を生成する工程です。

Retrieve (近傍探索) の概念 (Why)： 検索の精度がRAGの生命線です。2025年現在、ベクトル検索（意味）とキーワード検索（完全一致）を組み合わせる「Hybrid Search（ハイブリッド検索）」が主流です。なぜなら、「AI」のような概念はベクトル検索が得意ですが、「製品型番A-100」や「田中太郎」といった固有名詞はキーワード検索が必須だからです。両者を組み合わせることで検索漏れを防ぎます。（実装詳細は「#4-技術(DB)」へ）
Reranker（再ランキング）の概念 (Why)： Retrieveの補助機能としてReranker（リランカー）が重要です。Retrieveで広く集めた候補（例: 50件）にはノイズも含まれます。Rerankerは、この50件をより高精度なモデルで再評価し、本当に重要な順（例: 5件）に並べ替える「精査」の役割を担います。
Generate (制約付き生成) の概念 (Why)： 検索した文書（コンテキスト）をLLMに渡し、回答を生成させます。この際、「取得した文書『だけ』を根拠に回答せよ」「出典IDを必ず明記せよ」といった厳格な制約（プロンプト）を与えることが、ビジネス利用での信頼性（トレーサビリティ）確保に不可欠です。

工程別のミニ指標

ETL：重複率・言語比率・更新遅延／Index：ビルド時間・サイズ／Retrieve：再現率@k・誤検出率／Generate：根拠整合・有用度スコア。

RAGの分類と選び方：Classic／Hybrid／Agentic

要約：Classicは単純構成で速い立ち上げ、Hybridは精度拡張、Agenticは自己修正・計画・検証まで含む。

Classic RAGは最小構成で、FAQや規程検索に最適。Hybrid RAGはBM25×ベクトルや再ランキングでカバレッジと精度を両立。Agentic RAGは計画・自己修正・評価のループを回し、運用での頑健性を高めます。用途とSLAに応じて段階的に採用します。

Classic RAG（第1世代：ナイーブRAG）

構造： 「Retrieve → Generate」という「一直線」のシンプルなパイプラインです。
思想・課題： 構造が単純で導入が容易ですが、「検索が失敗したら、回答も失敗する」という脆さ（もろさ）を抱えています。検索結果にノイズが多いと（Garbage In）、回答もノイズに汚染されます（Garbage Out）。

Hybrid RAG（第2世代：アドバンスドRAG）

構造： Classicと同じ「一直線」のパイプラインですが、「Retrieve（検索）工程の内部」が高度化（Hybrid Search + Reranker）した形態です。
思想・改善点： 検索の「精度」と「再現率」を徹底的に高め、LLMに渡す情報の品質を最大化するアプローチです。2025年現在、多くの本番環境で標準構成とされています。

Agentic RAG（第3世代：自己修正RAG）

構造： 最大の違いは「一直線」ではなく「ループ（反復）構造」を持つ点です。
思想・改善点： エージェント（Agent）と呼ばれる思考コンポーネントが介在します。エージェントは「①計画」し、「②検索を実行」し、結果を「③自己評価」します。もし評価が低い（例：情報が足りない）と判断すれば、「④検索クエリを変えてやり直す（自己修正）」といった自律的な動作が可能になります。

最小コード（Classic→Hybrid化のイメージ）

# Classic：ベクトル検索のみ
hits_vec = retrieve_vec(index, query, k=8)
# Hybrid：キーワード×ベクトルのハイブリッド
hits_bm25 = retrieve_bm25(corpus, query, k=20)
hits = rerank(hits_bm25 + hits_vec, model="cross-encoder")

Agenticへの発展はLangGraphなどの状態管理で、条件分岐・再試行・自己評価をワークフローに組み込みます（詳細は「LangGraphによるRAG設計」へ）。

評価・テスト・運用：何を計測し、どう改善する？

要約：まず再現率と根拠整合。人手評価は少量・高品質から始め、ログで運用指標を拡張。

品質計測は再現率（Recall）、精度（Precision）、根拠整合（Citation）、有用度（Task Success）で行います。A/Bは同一コーパス・同期間・同温度で比較し、クリック後満足まで追跡。テストデータはユースケース別の代表質問を10〜30個用意し、異常系（未回答・誤引用）も含めます。

RAG評価の2つの側面（概念整理）

RAGの品質評価は、パイプラインの「検索」と「生成」の2つの側面で捉える必要があります。どちらがボトルネックになっているかを特定することが改善の鍵です。

Retriever（検索）の評価： 検索側が正しく機能しているか。
- Context Precision (検索適合率): 取得した文書は、本当にクエリと関連していたか？（ノイズの評価）
- Context Recall (検索再現率): 回答に必要な文書を、すべて取得できていたか？（検索漏れの評価）
Generator（生成）の評価： 生成側が正しく機能しているか。
- Faithfulness (根拠整合性): 生成された回答は、取得した文書の内容に忠実か？（ハルシネーションの評価）
- Answer Relevancy (回答関連性): 最終的な回答は、ユーザーのクエリの意図に答えているか？（的外れな回答の評価）

評価駆動開発（Evaluation-Driven Development）の思想

RAG開発は「作って終わり」ではなく、「評価指標」を先に定義し、そのスコアを継続的に改善する「評価駆動開発」の思想が不可欠です。本番環境では、これらの指標をリアルタイムで監視する「可観測性（Observability）」の設計が運用品質の生命線となります。

運用の落とし穴（回避策）

① チャンク過大→要点喪失。② メタデータ不足→フィルタ不可。③ Rerank未整備→ノイズ混入。まずはRetriever上流を改善し、生成側は引用必須・禁止語で制約します。

【2025年版】RAGの最新動向と今後の展望

要約：RAGは「マルチモーダル化」「グラフ化」「自動最適化」へ進化。長文コンテキストLLMの登場後も、リアルタイム性・コスト・ノイズ制御の観点からRAGの重要性は変わらない。

動向1：Multi-modal RAG（テキスト以外の検索）

従来のRAGはテキスト（Text）データが対象でした。最新の動向では、画像、表（Table）、音声（Audio）データも検索対象とする「マルチモーダルRAG」が注目されています。「このグラフが示す傾向は？」といったクエリに対し、画像や表を直接参照して回答を生成します。

動向2：Graph RAG（関係性の検索）

ベクトル検索は「意味の近さ」を探す技術です。これに対し、ナレッジグラフ（知識同士の『関係性』）を検索基盤とする「グラフRAG」が登場しています。「A社とB社の共通の取引先は？」といった、より複雑な因果関係や構造的な問いに答えることを目指すアプローチです。

動向3：RAGの自動最適化（AutoRAG / Self-RAG）

RAGのパイプラインは非常に複雑で、どのEmbeddingモデル、どのチャンキング戦略、どのLLMを選ぶかによって性能が大きく変わります。この最適な組み合わせ自体をAIが自動で評価・構築する「AutoRAG」のようなフレームワークが台頭しています。

動向4：LLMのコンテキストウィンドウ巨大化の影響（RAGは不要になるか？）

2024年から2025年にかけて、LLMが一度に読める情報量（コンテキストウィンドウ）が100万トークンを超えるなど劇的に増加しました。「すべての文書をLLMに直接読み込ませればRAGは不要になる」という議論がありますが、結論から言えばRAGの重要性は変わりません。なぜなら、(1) 全文検索はコストと遅延（レイテンシ）が膨大になる、(2) 関連性の低い大量の情報を与えるとLLMの精度が逆に低下する（ノイズの問題）、(3) リアルタイムの知識（例：DBの最新在庫）を反映できない、といった課題が残るためです。RAGは「長文コンテキストLLMに与える『最適な情報』を絞り込む」役割として、より重要性を増しています。