はじめに
2025年頃から「AIエージェント」というキーワードが急速に広まり、2026年に入ってからはその応用の一つである Agentic RAG も注目を集めています。
RAG (Retrieval-Augmented Generation) は、検索によって取得した文書を元にLLMが回答を生成するアーキテクチャで、エンタープライズ検索や社内ナレッジ検索などで広く利用されています。近年は、単純な検索＋生成の構成から、ReRankingやSelf-RAGなど様々な改良手法が提案されており、RAGの設計も進化を続けています。
その延長線上にあるのが、LLMが検索やツール利用を動的に制御する Agentic RAG です。
従来のRAGは検索→回答生成という比較的シンプルなパイプラインですが、Agentic RAGではLLMが状況に応じて検索や推論を繰り返しながら回答を構築します。
このような構造により、より複雑な問題に対応できる可能性がある一方で、
- 本当に精度は向上するのか
- 追加されるコストや複雑さに見合うのか
といった疑問もあります。
そこで今回は、社内でいくつかのRAG手法を比較する簡単な実験を行いました。また、2026年に発表された最新の研究論文も合わせて紹介し、Agentic RAGの現状を整理してみたいと思います。
Agentic RAGを試してみた
実験設定
まず、複数のRAGアーキテクチャを比較する簡単な実験を行いました。
実験は社内の実験プラットフォーム上に構築したRAG環境を用いて実施しました。評価には 弊社製品の関連文書から構成されたQA評価セット を使用しています。内容としては、製品ドキュメントを対象とした典型的なエンタープライズ検索に近いタスクです。
評価方法は LLM-as-judge による自動評価を採用しました。回答生成および評価には Claude 4.5 Sonnet を使用しています。
今回比較した手法は以下の5種類です。
Naive RAG
最もシンプルなRAGです。
検索で取得したチャンクをそのままコンテキストとしてLLMに渡し、回答を生成します。今回は検索結果の上位4チャンクを使用しました。
RAGのベースラインとして広く使われている構成です。
RAG + ReRanking
検索で取得したチャンクを 再ランキング (ReRanking) によって選別する構成です。
今回は
- 検索で10チャンク取得
- ReRankerで重要度を評価
- 上位4チャンクをLLMへ入力
という手順を採用しました。
RAGの精度改善手法として比較的よく使われる構成です。
ReAct
ReAct (Reasoning and Acting) は、LLMが推論とツール利用を交互に行うエージェント型のアプローチです。
RAGをツールとしてLLMに与え、必要に応じて検索を行いながら回答を生成します。
論文 https://arxiv.org/abs/2210.03629
Adaptive RAG
Adaptive RAGは、回答の信頼性を高めるために 複数段階の検索や検証を行うRAG構成です。
検索結果の確認や再検索を行いながら回答を生成するため、より複雑なワークフローになります。Agentic RAGの代表的な構成の一つとして研究されています。
論文 https://arxiv.org/abs/2403.14403
LangGraphの実装例 https://docs.langchain.com/oss/python/langgraph/agentic-rag
Deep Agent
LangChainで公開されている Deep Agent も比較対象として評価しました。ツールを利用しながら複数ステップの推論を行う、より汎用的なエージェント型アーキテクチャです。
https://github.com/langchain-ai/deepagents
実験結果
各手法の評価結果をまとめたものが次の表です。
| 単純RAG | 単純RAG + ReRanking | ReAct | Adaptive RAG | Deep Agent | |
|---|---|---|---|---|---|
| 評価 | 3.2 | 3.1 | 3.2 | 3.1 | 3.2 |
| 時間(ms) | 5175.7 | 9015.5 | 8742.8 | 29444.8 | 8281.8 |
| LLM呼出回数 | 1.0 | 2.0 | 2.3 | 7.1 | 2.2 |
| トークン数 | 2417.1 | 4852.1 | 5969.7 | 10728.6 | 18366.1 |
| コスト(¥) | 1.36 | 2.56 | 3.08 | 6.41 | 8.59 |
結果を見ると、評価スコアには大きな差は見られませんでした。
一方で、Agentic RAGに分類される手法では
- LLM呼び出し回数
- トークン消費量
- レイテンシ
が増加する傾向が見られました。
今回の設定では、Naive RAGやReRanking付きRAGでも十分に高い性能が得られるという結果になりました。
もちろんこの結果だけで一般的な結論を出すことはできませんが、少なくとも今回のようなエンタープライズ検索に近いタスクでは、Agentic RAGの明確な優位性は確認できませんでした。
論文紹介①
Is Agentic RAG worth it?
ちょうど実験を行っていたタイミングで、興味深い論文が公開されました。
Is Agentic RAG worth it? https://arxiv.org/abs/2601.07711
この論文では、従来のRAGとAgentic RAGを複数のタスクで比較し、その費用対効果を分析しています。
論文の主な結論は次の通りです。
- Agentic RAGは推論能力自体は高い
- しかし精度改善は限定的
- 一方で 計算コストとレイテンシは増加する
その結果、実運用の観点では Enhanced RAG（ReRankingなどを組み合わせたRAG）でも十分な場合が多いと述べられています。
今回の社内実験の結果も、少なくとも方向性としてはこの論文の結果と一致するものでした。
論文紹介②
A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces
一方で、Agentic RAGの可能性を示す研究も発表されています。
A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces https://arxiv.org/abs/2602.03442
この研究では、Agentic RAGが十分に性能を発揮できない原因の一つとして、検索インターフェースの設計を指摘しています。
従来のRAGでは、
- 一度の検索で固定数のチャンクを取得する
- その結果をそのままLLMに渡す
という比較的単純な構造になっています。
A-RAGではこれを拡張し、
- キーワード検索
- セマンティック検索
- 文書単位の取得
- チャンク単位の取得
といった複数の検索インターフェースをLLMに提供します。
これにより、LLMが状況に応じて検索戦略を選択できるようになり、より複雑な情報探索や multi-hop reasoning が可能になるとしています。
つまり、
- 現在のAgentic RAGがうまく機能しないのは
- アーキテクチャがまだ発展途上である可能性がある
という立場の研究と言えます。
おわりに
今回は、社内で行った簡単な比較実験と、2026年に公開された2本の論文を紹介しました。
今回の実験では、少なくともエンタープライズ検索に近いタスクにおいては、Agentic RAGの明確な優位性は確認できませんでした。一方で、研究コミュニティではAgentic RAGの改良に関する研究も活発に進んでいます。
Agentic RAGについては、研究や実装の方向性によって評価が変わる可能性もあり、まだ議論の続いているテーマと言えそうです。
今後の研究や実装の動向も追いながら、引き続き最良のサービスを提供できるよう、今後の研究や実装の動向も追っていきます。
