静的 RAG が負け始めている理由
- 〜2024年にかけて、エンタープライズ AI の標準アーキテクチャは事実上 RAG（Retrieval-Augmented Generation）だった。ベクトル DB に社内ドキュメントを投入し、ユーザーの質問をエンベディングで類似検索し、上位 k 件を LLM のコンテキストに注入して回答させる — この構成は実装容易性と初期精度の両面で優れ、多くの企業が PoC から本番運用へ素早く到達できた。しかし 2025年後半から、静的 RAG の限界が業務ユースケースで明確になってきた。
第一の問題は「質問の1ラウンド性」だ。RAG は基本的に「質問 → 検索 → 回答」の単発処理であり、複雑な業務質問（例: 「過去3ヶ月の営業データから、A商品の低迷要因を競合情報と照合して3つ挙げよ」）には不向きだ。検索と推論が分離されており、推論過程で「別の検索が必要」と判明しても自動的に再検索できない。人間のナレッジワーカーが当然行う「調べる→考える→追加で調べる→結論を出す」という反復プロセスを、静的 RAG は表現できない。
第二の問題は「ツール使用の欠落」である。業務質問の回答には検索だけでなく、社内 API 呼び出し、計算、グラフ生成、外部 SaaS 問い合わせなど、多様なツール操作が必要になる。静的 RAG はドキュメント検索に特化しているため、ツール統合が後付けの継ぎ接ぎになる。第三の問題は評価の困難さで、固定データセットによる Precision/Recall 評価では、業務上の「役に立ったか」を測れない。
これらの課題を構造的に解決するのがエージェンティックワークフローである。LLM が自律的にツールを選択・実行し、複数ステップで情報を収集・推論し、最終成果物を生成する。検索は「数あるツールの一つ」に格下げされ、エージェントの判断で使われる。2026年の新規エンタープライズ AI プロジェクトの過半数がこのパターンを第一選択にしている。
RAG を捨てる必要はない: ハイブリッド設計の勘所
誤解してはならないのは、エージェンティックワークフローは RAG を置き換えるのではなく、RAG を「内部ツールの一つ」として組み込む構成になる、ということだ。検索という行為自体は依然として業務質問の中核であり、高品質なベクトル検索・BM25・ハイブリッド検索の価値は変わらない。変わるのは「誰が」検索を発動するか、である。
推奨されるハイブリッド設計は次のようになる。エージェントのツールセットに retrieve_documents、retrieve_structured_data、query_api、compute、generate_chart などを登録し、システムプロンプトで「まず情報を集め、不足があれば追加取得し、最終回答を生成せよ」と指示する。retrieve_documents は従来の RAG エンジンそのままであり、ベクトル DB、リランカー、ハイブリッド検索の最適化はすべて再利用できる。
さらに、質問の複雑度に応じて「RAG だけで済ませる軽量パス」と「エージェントで深掘りする重量パス」を分岐させるルーターも実装する。単純な事実確認はレイテンシ優先で RAG のみ、複雑な分析はエージェントに委ねる。ルーター自体も小型 LLM で実装でき、全体のコスト最適化に効く。
コストと品質のトレードオフ
エージェンティックワークフローは品質向上と引き換えに、コストとレイテンシが大幅に増える。単発 RAG は LLM 呼び出し 1回で完結するが、エージェントは平均 5〜15回の LLM 呼び出しを行う。推論モデル（OpenAI o3、Claude Opus 4.7 等の拡張思考モード）を併用すると、1クエリあたりのコストが 10〜50倍になるケースも珍しくない。
したがってコスト設計は必須だ。推奨パターンは「モデル階層化」である。プランニング（次に何をすべきか決める）は高性能推論モデル、情報抽出や要約は中型モデル、最終出力の整形は軽量モデル、と段階ごとに使い分ける。これにより平均コストを 3〜5倍程度に抑えつつ、品質は静的 RAG の 2倍以上に向上させられる。
レイテンシ対策としては、ツール呼び出しの並列化が決定打になる。従来のエージェント実装はツールを直列実行していたが、2026年のフレームワーク（LangGraph、AutoGen、Mastra、Claude Agent SDK 等）はいずれも並列ツール呼び出しを標準サポートする。情報収集フェーズで複数ソースを同時クエリし、結果を統合してから次の意思決定に進む構成で、体感レイテンシを半減できる。
キャッシュ戦略も重要で、プロンプトキャッシュによりシステムプロンプトと長いツール定義の再送信コストをゼロに近づけられる。キャッシュ未使用と使用でコストが 70〜90% 違うこともある。
ガバナンスの大変更: 非決定性との付き合い方
RAG からエージェントへの移行で最も過小評価されているのが、ガバナンス側の変更だ。静的 RAG は「同じ質問には同じ回答」が成立しやすく、決定性に近い挙動を示す。一方エージェントは非決定的で、同じ質問でもツール選択順や情報の選定が変わり、回答が揺らぐ。金融・医療・法務など規制業界では、この非決定性が規制対応の障害になりうる。
対策として、2026年のエンタープライズエージェント設計では「ステップログの保存と再生可能性」が必須要件化している。エージェントの各ステップ（選択ツール、引数、結果、中間推論）を全て保存し、後から「なぜこの回答になったか」を再構成できるようにする。監査時には、特定の回答について「この資料を参照し、このツールを呼び、この中間判断を経て最終回答に至った」と説明可能でなければならない。
権限管理も変わる。RAG では「ユーザーが見られるドキュメントだけを検索対象にする」というフィルタリングで十分だったが、エージェントでは「そのユーザーに代わって、どのツールをどの権限で呼んでよいか」をきめ細かく制御する必要がある。前章で触れた Non-Human Identity と OAuth for Agents がここで効いてくる。
移行プレイブック: 段階的移行の6フェーズ
実務的な移行手順として、筆者が複数企業で実施した 6フェーズ・プレイブックを示す。第1フェーズは既存 RAG の評価ハーネス強化。エージェント化後の比較基準を作るため、50〜200件の代表的業務クエリに対する期待回答をゴールデンセットとして整備する。第2フェーズはツール抽出で、現行 RAG 周辺の補助処理（スプレッドシート検索、API 呼び出し等）をツール関数としてリファクタリングする。
第3フェーズは最初のエージェント実装。最小構成（retrieve + 1〜2ツール）でシンプルなエージェントループを組み、ゴールデンセットで RAG と対戦させる。第4フェーズはツール拡張で、業務上必要なツールを段階的に増やす。第5フェーズは本番シャドーデプロイで、ユーザーには RAG の回答を返しつつエージェントも並行実行し、結果をログに蓄積して品質を比較する。第6フェーズは段階的切替で、クエリ種別ごとに RAG → エージェントへ移行する。
この段階的移行の鍵は「シャドーデプロイ期間を最低 4週間確保する」ことだ。エージェントは失敗パターンが多様で、本番トラフィックを浴びないと発見できないエッジケースが必ず存在する。
評価ハーネスの再構築: LLM-as-a-Judge と行動評価
RAG 時代の評価指標（Precision@k、Recall@k、MRR）はエージェント評価には不十分だ。エージェントは「最終回答の正しさ」だけでなく「到達経路の妥当性」も評価する必要がある。2026年の主流は次の3層評価である。第1層は最終回答品質で、LLM-as-a-Judge（別の LLM に採点させる）と人手評価の組み合わせ。第2層は行動品質で、適切なツールを適切な順序で呼んだか、無駄な呼び出しがないかを評価。第3層はコスト効率で、トークン消費・レイテンシ・ツール呼び出し数。
LLM-as-a-Judge の実装では、Judge 用プロンプトに評価観点を構造化して与え、回答ごとに 1〜5 のスコアと根拠を出力させる。バイアス対策として、複数の Judge モデル（Claude、GPT、Gemini）でクロスチェックする手法や、Pairwise 評価が用いられる。行動評価には LangSmith、Braintrust、Arize、Phoenix などの LLM Ops プラットフォームが使われ、エージェント実行トレースを自動記録し、ステップごとのレイテンシ・コスト・失敗理由を可視化する。
おわりに: 段階的移行と正直な評価が鍵
RAG からエージェンティックワークフローへの移行は、2026年のエンタープライズ AI における不可逆な潮流である。しかし「いきなり全部をエージェント化する」のは失敗への近道だ。既存 RAG の資産を活かし、評価ハーネスを整備した上で、段階的にエージェント化を進める。品質・コスト・ガバナンスの3軸で継続的に測定し、正直に比較する文化を持てた組織だけが、エージェント時代の恩恵を本当に享受できる。