【使い分け必須】従来のRAGとは異なる、Agentic RAGについて解説します
近年の大規模言語モデル（LLM）は、チャットや問い合わせに対して瞬時に回答を返せるようになり、ビジネスや開発現場でも幅広く活用されています。しかし、LLM だけに頼ると、すでに学習されていない最新情報や機密資料などを参照できないケースもあるのが現状です。
そこで注目されているのが**Retrieval-Augmented Generation（RAG）**です。さらに最近では、この RAG をさらに発展させた Agentic RAG という手法も登場しています。本記事では、エンジニア向けに RAG/Agentic RAG の仕組みやメリットを解説します。
1. RAG（Retrieval-Augmented Generation）とは？
1-1. “外部の知識”を組み合わせる仕組み
通常の大規模言語モデルは、学習済みのデータに基づいて回答を生成します。しかし、学習時点で得られなかった情報や最新のデータに対応したい場合、LLM 単独では限界があることも事実です。
たとえば、
- 最新の製品マニュアルの内容を回答に反映したい
- 社内ドキュメントを踏まえてまとめたい
といった要望に対して、LLM が学習データだけでは十分にカバーできないケースがあります。そこで登場するのが RAG（Retrieval-Augmented Generation） です。
RAG の基本フローは以下のとおりです。
- 外部の知識ソース（文書やデータベースなど）を検索して関連情報を取得する
- 検索結果を「文脈情報（コンテキスト）」として LLM に入力し、回答を生成する
このように、必要なデータを都度引き出して LLM が回答に活用できる点が RAG の大きな特徴です。
1-2. 「検索」の重要性
LLM は一度学習したデータをもとに推論しますが、必ずしも更新された情報や限定的な文書を直接参照できるわけではありません。
たとえば、
- 学習後に改訂された製品マニュアル
- 機密性の高い社内限定資料
など、モデル外部にある情報をリアルタイムで参照したい場面は多くあります。これらを効率よく取得し、LLM に渡すための仕組みが RAG の「検索（Retrieval）」部分です。
外部情報を “必要なときに必要な分だけ” 動的に取り込み、回答生成に活用できるのが RAG の強みといえます。
【宣伝】AI開発に関する最新トピックや、初心者からプロ向けのTIPSをX（旧Twitter）で日々発信しています。「もっと知りたい」「最新情報を逃したくない」と感じていただけたら、ぜひフォローをお願いします！👇👇
X(twitter) 👉 https://x.com/AI_masaou
2. Traditional RAG：シンプルな「検索＋生成」のワークフロー
2-1. Traditional RAG の大まかな処理手順
-
追加ドキュメントのベクトル化とデータベース格納
外部文書（マニュアルや PDFなど）を Embedding Model でベクトル変換し、Vector Database に保存。 -
クエリのベクトル化による類似検索
ユーザからの問い合わせ文（クエリ）も同じ Embedding Model でベクトル化。Vector Database からクエリと類似度の高い文書を検索。 -
LLM に関連ドキュメントを渡して回答生成
検索で得られた文書を LLM の入力に追加し、回答を生成。
2-2. Traditional RAG のメリットとデメリット
-
メリット
- ワンステップで完結するため、実装が比較的シンプル
- 関連文書だけを LLM に渡すので、不要情報を削減しやすい
-
デメリット
- クエリが曖昧・複雑な場合、適切な文書を取得できないことがある
- 基本的には「問い合わせ→回答」の 1 回きりのため、回答の再検証や追加検索などが自動では行われない
シンプルさゆえに扱いやすい一方で、複雑な問い合わせや不確定要素が多い場合には十分に対応できないケースがあります。
3. Agentic RAG：エージェントが検索・回答を“多層的”に行う
3-1. なぜ Agentic RAG が生まれたのか
Traditional RAG は「入力されたクエリをベースに関連文書を取得→回答」で完結するため、
- クエリが曖昧なとき
- 回答に足りない情報があるとき
などは、ユーザが手動で再度検索し直す必要がありました。
一方、Agentic RAG では、回答を生成する前後に “エージェント（LLM Agent）” が検索クエリを最適化したり、回答の妥当性をチェックしたりするステップを組み込みます。これにより、回答精度を高めるための再試行や追加検索が半自動的に行われるようになります。
3-2. Agentic RAG の代表的なワークフロー
-
クエリ最適化
- ユーザからの質問文をそのまま使わず、より検索に適した形に書き換える
- 例: 曖昧な表現をテクニカルな用語に置き換える、検索文脈を補足するなど
-
必要情報の判断と取得
- エージェントが「追加データを取得する必要があるか」「別のツール・API を呼び出すべきか」を判断
- 必要に応じて再度検索を実行、あるいは外部 API からの情報を取り込む
-
回答生成
- エージェントによって書き換えられたクエリや取得済みデータを用いて、LLM が回答を作成
-
回答のレビューと再試行
- エージェントが回答内容を評価し、不足があれば追加検索やプロンプト再生成を行う
- 最終的にユーザに返す回答を洗練させる
3-3. 検索の“前段階”が増えるメリット
Traditional RAG とは異なり、Agentic RAG では検索や回答生成の前後でエージェントが積極的に介入します。その結果、以下のような利点があります。
- 曖昧な問い合わせにも柔軟に対応できる
- 自動で追加情報を探しに行くため、ユーザが何度もクエリを手直しする必要が減る
- 複数ステップで情報を深掘りし、より高品質な回答を得られる
4. Agentic RAG の可能性と注意点
4-1. 複数ステップで回答を発展させる
エージェントが再試行や再検索を行うことで、ユーザが手動で行っていた “追加調査” を一部自動化できます。たとえば、
- まず大まかな結論を導く
- その裏付けとなる文献やデータを追加で取りに行く
- 必要に応じて再度回答を補足する
といった段階的なタスクをエージェントが連続して実行できるようになります。
4-2. 外部ツールとの連携
Agentic RAG は、外部の API や翻訳ツール、電卓などと連携することでさらにパワーアップします。
- 「最新のニュース情報を取得してほしい」
- 「計算が必要な数値を算出してほしい」
など、LLM 単独では難しい処理もエージェントが判断して実行すれば、回答精度が向上する可能性があります。
4-3. 実装・運用が複雑化しやすい
一方で、自由度が高くなる分、以下のようなリスクも考えられます。
- 不要な検索が増えてコストが大きくなる
- エージェントが想定外の処理を行い、誤った結果を持ってきてしまう
適切なプロンプト設計やエージェントの制御、監視が必要です。また、機密情報を扱う場合は、検索範囲やアクセス権限の管理など、セキュリティ面の配慮も重要になります。
5. Traditional RAG と Agentic RAG の使い分け
-
Traditional RAG
- クエリが明確で、1 回の検索で十分に回答が得られる場合
- シンプルな Q&A
-
Agentic RAG
- クエリが曖昧で、複数ステップの情報探索が必要な場合
- 回答の再検証や複数の外部ソースとの連携を考慮したい場合 |
6. まとめと展望
RAG は「LLM の学習データだけに頼らず、外部情報を組み合わせる」ことで柔軟な回答を得るための有力なアプローチです。さらに、Agentic RAG を取り入れることで、AI 自身が必要な情報源を探しに行き、回答を何度もブラッシュアップする流れを自動化しやすくなります。
-
メリット
- 多段階の情報探索が可能
- ユーザの再問い合わせの手間を削減
-
注意点
- 実装や運用が複雑化するリスク
- エージェントの暴走や不要なリソース消費を防ぐ仕組みが必要
今後は、外部ツール連携やガバナンスの最適化、さらには複数のエージェント同士の連携など、多方面での進化が期待されています。エンジニアとしては、こうした新たな RAG/Agentic RAG の動向を注視しつつ、自社システムやサービスに合う形で導入を検討してみる価値があるでしょう。
最後に
人間がふだんやっている「資料を集め、足りなければ他のソースも探して、回答を洗練させる」というプロセスを、AI がある程度自動化できる世界が近づいています。
RAG と Agentic RAG は、そんな “人間的な情報収集・思考プロセス” をシステムに組み込み、高度化するための注目技術です。今後さらに便利なツールやフレームワークが登場し、開発・運用のハードルが下がることも期待できます。ぜひこの機会に、エンジニアとして RAG を活用したシステム開発の可能性を探ってみてください。
ここまでお付き合いいただき、ありがとうございます。今後もAI分野の新しい活用方法や開発テクニックを、X（旧Twitter）でいち早く紹介していきます。少しでも興味があれば、ぜひフォローして最新情報をチェックしてくださいね！👇
Discussion