blog

RAGとは何か――仕組み・アーキテクチャ・限界を体系的に解説

本記事は「RAG(検索拡張生成)とは何か」という基礎概念・仕組み・アーキテクチャの体系的理解に特化して解説する。チャンキング設計・埋め込みモデル選定・ベクトルDB構成など実装の具体的手順を知りたい方はRAGの作り方・実装方法ガイドを、ツール比較・サービス選定については別途専門記事を参照されたい。

RAGとは何か――仕組み・アーキテクチャ・限界を体系的に解説する概念図
RAGとは何か――仕組み・アーキテクチャ・限界を体系的に解説

RAGが解決しようとする問題――LLMの四つの構造的限界

本記事はRAGの全体像です。目的別に詳しくは、RAGの構築手順RAGの導入事例RAGツール・手法の比較をご覧ください。

RAG(Retrieval-Augmented Generation、検索拡張生成)とは、大規模言語モデル(LLM)が回答を生成する際に、外部の文書コーパスやデータベースから関連情報を動的に検索・取得し、その内容を根拠としてプロンプトへ注入する技術体系の総称である。2020年にMeta AI(当時のFacebook AI Research)がNeurIPSで発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」を端緒として急速に実用化が進み、2026年現在では企業の生成AI活用における中核的なアーキテクチャとなっている。

RAGが求められる背景には、LLM単体が抱える四つの構造的限界がある。

第一に知識カットオフ――モデルの学習データには締め切り日があり、それ以降の事実は保持されない。第二にハルシネーション――未知の質問に対してもっともらしく見える誤情報を生成する。第三に内部情報の欠如――自社マニュアルや契約書など学習対象外のドキュメントを参照できない。第四にファインチューニングのコスト――知識を追加するたびにモデルを再学習させるのは、時間・GPU費用ともに現実的でない。RAGはこれらを「モデルを作り直す」のではなく「必要なときに必要な情報を渡す」という設計思想で解決する。

RAGの概念図:ユーザーの質問に対して外部文書を検索し、LLMが根拠付きで回答を生成するフロー
RAGの概念:外部文書を検索してLLMの回答根拠とする

技術的位置づけとしては、深層学習を基盤とするLLMに対して検索エンジン的な機能を組み合わせたハイブリッドアーキテクチャである。深層学習の基礎についてはディープラーニングの仕組みと応用も参照されたい。

2026年に入り、RAGはより広い概念「コンテキストエンジニアリング」の一部として捉え直される潮流が生まれている(Algomatic「コンテキストエンジニアリングの歴史:RAGの過去から現在をたどる」)。LLMに何をどのように渡すかという設計全体を指すこの概念のなかで、RAGは「外部記憶からの動的なコンテキスト注入」を担う中核的な要素と位置づけられる。

RAGの処理フロー――インデックス構築から回答生成まで

RAGの動作は、事前のインデックス構築フェーズと、クエリごとに実行される検索・生成フェーズの二段階に大別される。

①クエリ入力 自然言語の質問 ②ベクトル化 埋め込み生成 ③類似検索 ベクトルDB照合 ④コンテキスト プロンプト結合 ⑤LLM生成 根拠付き回答を出力
RAGの処理フロー(検索・生成フェーズ)

インデックス構築フェーズ

まず対象文書(PDF・Word・HTML・データベースの行など)を取り込み、チャンキングによって検索可能な単位へ分割する。チャンクサイズは検索精度に直結する重要なパラメータであり、小さすぎると文脈が失われ、大きすぎるとノイズが増える。文書の論理構造(段落・セクション単位)に沿って調整することが基本であり、隣接チャンクを一部重複させる「オーバーラップ」は文脈断絶の緩和に有効である。

分割した各チャンクを埋め込みモデルにより高次元ベクトルへ変換し、ベクトルデータベース(Vector DB)へ格納する。格納時には文書名・更新日時・カテゴリといったメタデータを付与しておくことで、検索時のフィルタリングが可能になる。

検索・生成フェーズ

ユーザーのクエリを同じ埋め込みモデルでベクトル化し、Vector DBに対してコサイン類似度または内積による近傍探索を実行する。取得した上位チャンクをオリジナルのクエリと結合してプロンプトを構成し、LLMへ入力する。LLMは渡された文書内容を根拠として自然言語で回答を生成する。

この「意味的な近さで検索する」仕組みは、表層的な文字列一致ではなく意味空間上の距離に基づく。テキストマイニングの観点からみると、RAGの検索層はその応用形の一つといえる。詳細はテキストマイニングの基礎と応用を参照されたい。BERTに代表される言語モデルがこの埋め込み生成の基盤を支えており、BERTとNLP基礎ガイドも理解の補助として有益である。

日本語文書を扱うRAGでは、辞書型RAGと日本語特化モデルを用いたRAGの精度差が文書ドメインによって異なることが情報処理学会のワークショップでも示されており(J-STAGE「Comparison of dictionary-type RAG and RAG using Japanese and…」2023年SWOシンポジウム)、日本語固有の形態素解析や語彙の扱いがシステム設計の重要な変数となっている。

RAGの主要アーキテクチャ――Naive RAGからAgentic RAGまで

RAGは単一の手法ではなく、精度や用途に応じた複数のアーキテクチャバリアントを持つ。2026年時点での主要な分類を以下に整理する(Arpable「RAG完全ガイド2026|次世代RAGの選び方」、Zenn「RAG精度改善技術のカオスマップ」を参照)。

アーキテクチャ 概要 得意な場面 主な限界
Naive RAG クエリ→ベクトル検索→プロンプト注入→生成の基本フロー シンプルなFAQ・社内Q&A 検索漏れ・Lost in the Middle問題
Advanced RAG クエリ変換・ハイブリッド検索・Re-rankingを追加 曖昧なクエリ・大規模文書コーパス パイプライン複雑化・レイテンシ増
Modular RAG 検索・生成・評価コンポーネントを柔軟に組み替え 要件が多様・段階的な追加検索が必要な場合 設計・運用コストが高い
Graph RAG エンティティ間の関係をグラフ構造で表現・検索 複数文書にまたがる関係性の分析 グラフ構築コスト・ドメイン知識が必要
Agentic RAG LLMが自律的に複数回の検索・ツール呼び出しを実行 多段推論・複雑なタスク分解が必要な場合 制御が難しく誤推論が連鎖するリスク

Qiitaの記事「Hybrid Search、Graph RAG、Agentic RAGで精度を10倍にする」が指摘するとおり、2026年時点ではベクトル検索単独での運用は精度面で競争力を保ちにくくなっており、ベクトル検索とBM25等のキーワード検索を組み合わせるハイブリッド検索が事実上の標準となりつつある。

Advanced RAGの主要技術

クエリ変換(Query Rewriting)は、ユーザーの曖昧な質問をLLMが検索に最適な形へ書き換えてから検索する手法である。「先月の件」のような省略表現を具体的なキーワードへ展開する。HyDE(Hypothetical Document Embeddings)は、質問に対する仮想的な回答文を生成し、その仮回答を使って検索する逆転的なアプローチである。Re-rankingでは、初期検索で取得した候補チャンクをCross-Encoderなどで再スコアリングし、最も関連性の高いものだけをプロンプトへ絞り込む。

産業ドメイン向けのRAGでは、クエリが要求する能力をL1(事実検索)・L2(推論)・L3(予測)・L4(創造)の4レベルに分類し、求められる能力の層によって適切なアーキテクチャを選択する考え方も提示されている(Zenn「RAG精度改善技術のカオスマップ」)。生成AIの基盤となる生成モデルの概念についてはGAN(敵対的生成ネットワーク)の仕組みも参照されたい。

RAGとファインチューニング――比較と使い分けの基準

LLMに外部知識を持たせる手段としてしばしばRAGと比較されるのがファインチューニングである。また、コンテキスト長の拡大に伴い「全文書をプロンプトへ入れる」ロングコンテキスト戦略との比較も重要になっている。三者の特性を以下に整理する。

比較項目 RAG ファインチューニング ロングコンテキスト(全文入力)
知識の更新性 ◎ 文書差し替えで即時反映 △ 再学習が必要 ○ ファイル差し替えで対応
初期コスト ○ 比較的低い △ GPU・時間コスト大 △ トークン課金が高額になりやすい
根拠・出典の提示 ◎ 取得元文書を明示可 ✗ 根拠が不透明 ○ 原文を含む
大量文書への対応 ◎ 数百万文書規模でも可 ○ 学習データに取り込める ✗ コンテキスト長に制限
ハルシネーション抑制 ◎ 根拠文書が制約として機能 △ 効果は限定的 ○ 原文参照で抑制しやすい
文体・挙動のカスタマイズ △ システムプロンプトで対応 ◎ 深くカスタマイズ可能 △ 限定的

RAGとファインチューニングは排他的ではない。業界固有の用語や文体をファインチューニングで習得させ、事実情報はRAGで動的に補完するという組み合わせは、実装として合理的な選択肢となる。機械学習の基礎的な理解については機械学習の基礎と実践も参照されたい。

コンテキスト長の拡大(2026年時点で一部のモデルでは百万トークン規模が利用可能になっているとされる)は「全文書をプロンプトへ入れれば検索不要ではないか」という議論を呼んでいる。しかしトークン課金・レイテンシ・後述するLost in the Middle問題の観点から、大量文書への対応においてはRAGが依然として現実的な選択肢であり続けるとみられる。今後はロングコンテキストとRAGの役割分担・組み合わせの設計がより精緻化されていく方向と予想される。

RAGの評価指標と代表的な技術的課題

検索層と生成層を分けて評価する

RAGシステムの品質評価では、検索層と生成層を独立して測定することが重要である。「正しい文書を取得できているか」と「取得文書に忠実な回答を生成できているか」は別の問題であり、どちらが弱いかによって対処法が異なる。

評価指標 評価対象 意味
Context Precision 検索層 取得チャンクのうち質問と関連するものの割合
Context Recall 検索層 正解に必要な情報がどれだけ取得されているか
Faithfulness(忠実性) 生成層 生成された回答が取得文書の内容から逸脱していないか
Answer Relevancy 生成層 生成された回答がユーザーの質問に対してどれだけ的確か

これらの指標を自動算出するフレームワークとしてRAGASが広く利用されている。LLM自身を評価者として用い、テストセット全体に対するスコアを算出することで、チャンキング設計の変更や埋め込みモデルの切り替えが実際の精度に与える影響を定量的に追うことができる(Pionero「RAGパイプライン入門ガイド」)。

代表的な技術的課題と対処の方向性

Lost in the Middle 問題:プロンプト中間部に配置された情報をLLMが見落としやすいという現象である。取得チャンク数を上位3〜5件に絞り、Re-rankingで最重要チャンクを先頭に配置することで緩和できる。

検索精度のボトルネック:ベクトル検索は意味的類似度には強いが、固有名詞や専門用語の完全一致には弱い。ベクトル検索とBM25等のキーワード検索を組み合わせるハイブリッド検索が現実的な対処法となる。スパースモデリングの観点からのアプローチについてはスパースモデリングの基礎も参考になる。

データ鮮度と品質管理:インデックス化された文書が古いままでは誤情報の根拠となりかねない。文書更新時の自動再インデックスパイプラインの整備と、メタデータ(更新日時)を用いた優先度制御が必要になる。

アクセス制御:全社共用のRAGでは、権限のないユーザーに機密文書の内容が届くリスクがある。文書レベルのACL(アクセス制御リスト)をVector DBのフィルタリング機能と連動させる「Row-level Security」の実装が求められる(Money Forward Admina「RAGとは?情シスが知るべき生成AIの課題を解決」)。

RAGにおけるセマンティック検索:文書の意味空間上での類似度により関連チャンクを取得する仕組みを示す図
意味空間上の近さで関連チャンクを取得するセマンティック検索

RAGの現在地と研究上の論点

2026年時点でのRAG研究の焦点は、単純な検索精度の改善から、より複雑な問いへの対応へと移行している。マルチモーダルRAGでは、テキストに加えて画像・音声・動画をデータソースとして検索・活用できる拡張が進む。テキストとその他モダリティを統合する基盤技術についてはマルチモーダルAIの仕組みと応用に詳しい。

Self-RAGはLLM自身が「この時点で検索が必要か」「取得文書は十分な品質か」を自己評価しながら生成を進める仕組みである。必要なときだけ検索するためシンプルなクエリではオーバーヘッドを避けられる。Corrective RAG(CRAG)は取得文書の品質をLLMが評価し、低品質と判断した場合にWeb検索へフォールバックする手法である。RAGシステムの反復的な精度改善に強化学習的なアプローチを組み合わせる研究も進んでおり、強化学習の基礎と応用が参考になる。

日本語処理に特化したRAGの比較研究では、汎用的なベクトル検索と辞書型RAGの精度差が文書ドメインによって異なることが示されており、日本語固有の形態素解析や語彙の扱いがシステム設計の重要な変数となっている(J-STAGE「Comparison of dictionary-type RAG and RAG using Japanese and…」情報処理学会 第23回SWOシンポジウム 2023)。

RAGは「シンプルな発想」と「実装の難しさ」が共存する技術領域である。基本フローは直感的に理解できるが、実際の精度を業務要件に合わせて作り込むには、チャンキング設計・埋め込みモデル選定・ハイブリッド検索・Re-ranking・評価サイクルという多層的な工夫が求められる。生成AIを業務の中核に据えようとする実務者・研究者にとって、RAGアーキテクチャの原理と限界を正確に把握することが、設計判断の出発点となる。


弊社が開発するDeepAI(クリスタルメソッド株式会社)は、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現するバーチャルヒューマン/AIアバターソリューションです。リップシンク・表情生成・音声合成・対話AIを組み合わせ、接客・研修・面接練習・広報などの用途に活用されています。詳細はクリスタルメソッド ブログからご覧ください。


関連記事

参考文献

監修

河合 継(クリスタルメソッド株式会社 代表取締役)

AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番組でのAI解説実績を持つAI研究者として、AIの研究開発を主導している。
運営会社について編集方針


関連記事(rag 詳細ガイド)


AIの業務活用をご検討の方へ

クリスタルメソッドは、バーチャルヒューマンをはじめとするAIの開発・業務導入を支援しています。生成AI・AIエージェントの活用や、自社業務へのAI導入をご検討の際は、お気軽にご相談ください。

AIブログ購読

 
クリスタルメソッドがお届けする
AIブログの更新通知を受け取る

Study about AI

AIについて学ぶ

  • 生成AIオンプレミス導入と規制リスク——Anthropic輸出規制が示す自社インフラ回帰の必然

    生成AIオンプレミス導入と規制リスク——Anthropic輸出規制が示す自社インフラ回帰の必然

    Anthropicの輸出規制命令——生成AIオンプレミス導入が「規制リスク対策」に変わった瞬間 2026年6月、米国政府はAnthropicに対し、新モデル「M...

  • EU AI規制 企業対応の実務——ENISAとAnthropicの協議が示す日本企業への含意

    EU AI規制 企業対応の実務——ENISAとAnthropicの協議が示す日本企業への含意

    ENISAがAnthropicと直接協議——EU AI規制の監視が生成AIへ本格移行 欧州サイバーセキュリティ機関ENISA(European Union Ag...

  • Claude障害が招く業務影響と対策——AI依存リスクの経営管理指針

    Claude障害が招く業務影響と対策——AI依存リスクの経営管理指針

    Claude障害の実態:2026年6月インシデントが示すもの 2026年6月18日、AnthropicのAIチャットボット「Claude」(claude.ai)...

View more