はじめに
RAG（Retrieval-Augmented Generation）を導入したものの、期待通りの成果が得られていない。そんな声を最近よく耳にします。
「社内ナレッジベースを構築したけど、複雑な質問には答えられない」
「情報は取得できるけど、文脈を理解した回答にならない」
「検索精度は上がったけど、実際の業務には使えない」
実は、これらの課題は従来のRAGの構造的な限界から生じています。2025年現在、この問題を解決する新たなアプローチとして注目されているのが「Agentic RAG」です。
本記事では、従来のRAGがなぜ限界に達したのか、そしてAgentic RAGがどのようにその限界を突破するのかを、実装例を交えながら解説していきます。
従来のRAGの仕組みと限界
従来のRAGの基本アーキテクチャ
従来のRAGは大きく2つのフェーズで構成されています。まずオフライン索引フェーズでは、文書を小さなチャンク（通常500トークン程度）に分割し、各チャンクを埋め込みモデルでベクトル化してデータベースに保存します。
次にオンラインクエリフェーズでは、以下のような処理が行われます：
# 1. ユーザーの質問をベクトル化
query_embedding = embedding_model.encode(user_query)
# 2. 類似度検索でTop-K個の関連チャンクを取得
results = vector_db.query(
query_embeddings=[query_embedding],
n_results=5 # 固定値
)
# 3. 取得したチャンクをコンテキストとしてLLMに渡す
context = "\n".join(results['documents'][0])
prompt = f"Context: {context}\n\nQuestion: {user_query}"
answer = llm.generate(prompt)
一見シンプルで効率的に見えるこのアーキテクチャですが、実際の運用では様々な問題に直面します。
なぜ従来のRAGは限界に達したのか
従来のRAGには構造的な3つの大きな問題があります。
まず単一パス問題です。従来のRAGは「一度検索して、一度生成する」という固定的なフローで動作します。この単純なフローでは、最初の検索で不十分な情報しか得られなかった場合、もう挽回する機会がありません。
次に固定パラメータ問題があります。実際の実装では、top_k=5、chunk_size=500、threshold=0.7といったパラメータが事前に固定されています。「昨日の会議の内容は？」という単純な質問と、「過去3ヶ月の売上推移から来期の戦略を提案して」という複雑な質問に対して、同じパラメータで対応することの限界は明らかです。
そして検証不在問題も深刻です。従来のRAGには「取得した情報が本当に適切か」を判断する仕組みがありません。関連性が低い文書でも、そのまま使用して回答を生成してしまいます。
実例：従来のRAGが苦手とするシナリオ
実際によくある失敗パターンを見てみましょう。
シナリオ1：多段階推論が必要な質問
ユーザー：「A社との契約条件を踏まえて、B社への提案内容を検討してください」
従来のRAG：
1. "A社 契約"で検索 → A社の情報のみ取得
2. B社の情報が不足したまま回答生成
3. 結果：不完全な提案
シナリオ2：情報統合が必要な場合
ユーザー：「今期の各部門の課題をまとめて改善策を提示してください」
従来のRAG：
1. "部門 課題"で検索 → 一部の部門情報のみ取得
2. 全体像が見えないまま回答生成
3. 結果：偏った分析
Agentic RAGとは何か
コンセプトの革新：パイプラインからツール化へ
Agentic RAGの本質は、RAGシステムに「自律的な判断能力」を持たせることです。従来のRAGとAgentic RAGの最も大きな違いを、実装レベルで比較してみましょう：
従来型：固定パイプライン
class TraditionalRAG:
def process(self, query):
# 固定的な処理の流れ
embeddings = self.embed(query)
docs = self.retrieve(embeddings)
answer = self.generate(query, docs)
return answer
Agentic RAG：動的ツール選択
class AgenticRAG:
def process(self, query):
# エージェントが判断
agent = Agent()
# 検索が必要か判断
if agent.needs_retrieval(query):
strategy = agent.select_strategy(query)
docs = self.retrieve_with_strategy(query, strategy)
# 情報が十分か評価
while not agent.is_sufficient(docs, query):
# 戦略を変更して再検索
strategy = agent.refine_strategy(query, docs)
additional_docs = self.retrieve_with_strategy(query, strategy)
docs.extend(additional_docs)
return self.generate(query, docs)
この違いは単なる実装の差ではありません。Agentic RAGでは、エージェントが主体的に判断を下し、状況に応じて戦略を変更します：
class Agent:
def analyze_query(self, query):
"""クエリの複雑度を分析"""
complexity = self.assess_complexity(query)
if complexity == "simple":
return {"strategy": "direct_answer", "retrieval_needed": False}
elif complexity == "moderate":
return {"strategy": "single_retrieval", "top_k": 3}
else: # complex
return {"strategy": "iterative_retrieval", "max_iterations": 5}
Agentic RAGのメカニズム
Agentic RAGには3つの重要なメカニズムが組み込まれています。
意思決定メカニズムでは、エージェントがクエリの特性を分析し、過去の文脈を考慮しながら最適な検索戦略を動的に決定します。検索タイプ（semantic/keyword/hybrid）、取得数、再ランキングの必要性などを状況に応じて調整します。
反復的改善プロセスにより、情報が不十分な場合は自動的にクエリを改善して再検索を行います。この反復プロセスにより、最初の検索で見逃した重要な情報も段階的に収集できます。
自己検証システムでは、エージェントが取得した文書の関連性を自動評価し、閾値以下の文書をフィルタリングします。情報が不足している場合は、Web検索など代替戦略を自動的に提案・実行します。
技術アーキテクチャ
三層アーキテクチャ
Agentic RAGは明確に分離された三層構造を持ちます：
- エージェント層：推論と計画を担当（PlanningAgent、RoutingAgent、ValidationAgent）
- ツール層：モジュール化されたRAGコンポーネント（検索、再ランキング、インデックス、Web検索）
- データ層：多様な知識源の統合（ベクトルDB、ドキュメントストア、外部API）
動的検索の流れ
Mermaidを使って、Agentic RAGの動的な処理フローを視覚化してみましょう：
実装時の落とし穴と対策
Agentic RAGの実装には2つの主要な課題があります。
レイテンシの問題は、複数回の推論と検索を行うことで発生します。対策として、Redisなどの高速キャッシュの活用、並列処理による検索の高速化、頻繁にアクセスされるクエリ結果の事前キャッシングなどが有効です。
コスト管理も重要な課題です。トークン消費の最適化のため、コンテキストを重要度でランク付けし、トークン制限内で最大限の情報を含めるような仕組みが必要です。
技術トレンドと市場動向
2025年に発表された最新の研究によれば、Agentic RAGは2つの重要な方向に進化しています。
Reasoning Agentic RAGの台頭により、従来の検索だけでなく、推論能力を強化したシステムが登場しています。System 1（高速な直感的判断）とSystem 2（深い分析的推論）を組み合わせ、クエリに応じて最適な推論戦略を選択します。
マルチモーダル対応も進んでいます。テキストだけでなく、画像や表データも統合的に扱えるようになってきました。画像コンテキストの分析や、複数のモダリティ（テキスト、表、グラフ）からの統合検索が可能になっています。
まとめ
従来のRAGからAgentic RAGへの進化は、単なる機能追加ではなく、根本的なパラダイムシフトです。
Agentic RAGの本質は「自律的な知識獲得システム」です。単にRAGにAgentを追加したのではなく、RAGコンポーネントを分解し、エージェントが動的に編成する全く新しいアーキテクチャとして生まれ変わりました。固定的なパイプラインから、状況に応じて戦略を変える適応的システムへの進化により、従来のRAGが苦手としていた複雑な推論や動的な情報統合が可能になりました。
実践的な導入においては、すべてをAgentic RAGにする必要はありません。要求精度80%で十分な業務領域から始め、社内FAQ、ドキュメント検索、一次サポートなど、失敗してもリカバリー可能な領域で経験を積みながら、段階的に適用範囲を広げていくアプローチが現実的です。