RAG Is Not Dead — Agentic RAG, Hybrid Retrieval, and Multi-Agent Orchestration in 2026
miomio0705
ふぁるこんLABO
本番環境で学んだRAGとAIエージェント設計の現実：2026年最新トレンド総まとめ
miomio0705
なぜ今、RAGとAIエージェントが注目されるのか
2026年に入り、生成AIの話題は「使えるかどうか」から「どう本番に乗せるか」に完全に移行した。RAGを試したことがある開発者なら、プロトタイプは動いたのに本番で精度が出ない、あるいはレイテンシが想定の3倍になったという経験を持つはずだ。AIエージェントについても同様で、「企業が開発したエージェントのうち本番稼働しているのはわずか5%」という数字が現実を物語っている（Dataikuより）。今回は自分たちが実際に手を動かしながら学んだ設計上のトレードオフを、最新の研究・事例と合わせて整理する。
トレンド1：ハイブリッド検索＋Agentic RAGの本番パターン
RAGの設計で最初に直面する問いは「密ベクトル検索だけで十分か」だ。結論から言うと、規制業種（法務・医療・金融）では不十分だった。BM25とdense embeddingを組み合わせたハイブリッド検索に、Cohereのrerankerを重ねる構成が、現時点で最もロバストだという判断に至った。さらに、エージェント的な検証ステップを挟んで「検索が失敗していないか」を確認してから回答を生成する設計が、幻覚を大幅に減らしてくれた。
Redis「RAG at Scale」が指摘するように、本番RAGで最も費用対効果が高かったのはモデルのアップグレードではなく評価インフラの整備だった。Ragas・TruLensといった評価ハーネスを先に導入し、「どの検索変更が実際に精度を上げたか」を計測できる体制を作る。これがないと改善の方向性が見えない。Agentic RAGサーベイ論文（arXiv 2501.09136）も同様に、単純なクエリにはモジュール型RAGで十分であり、Agentic RAGを導入する判断は「複数ステップの推論が必要か」という問いに対して計測値で答えるべきだと述べている。
# ハイブリッド検索の最小構成例（Python）
from rank_bm25 import BM25Okapi
from sentence_transformers import SentenceTransformer
import numpy as np
def hybrid_search(query, corpus, top_k=10):
# BM25スコア
tokenized = [doc.split() for doc in corpus]
bm25 = BM25Okapi(tokenized)
bm25_scores = bm25.get_scores(query.split())
# Dense embeddingスコア
model = SentenceTransformer('intfloat/multilingual-e5-large')
query_emb = model.encode(query)
doc_embs = model.encode(corpus)
dense_scores = np.dot(doc_embs, query_emb)
# 正規化して合算（alpha=0.5でバランス）
alpha = 0.5
combined = alpha * (bm25_scores / bm25_scores.max()) \
+ (1 - alpha) * (dense_scores / dense_scores.max())
return np.argsort(combined)[::-1][:top_k]
rerankerのステップはCohere APIを呼ぶかcross-encoderをローカルに持つかでレイテンシが大きく変わる。コスト重視ならcross-encoder、精度重視ならCohereのクラウドAPIという使い分けになった。
トレンド2：マルチエージェントオーケストレーションの現実
AIエージェントをマルチ構成にした瞬間に生まれる問題は「エージェント間の受け渡し」だ。Dataikuの調査では、本番稼働できていないエージェントの失敗原因の大半は、エージェント品質そのものではなくオーケストレーション境界での不整合だった。実際に自分たちが5つのサービスにまたがる自動化パイプラインを構築したとき、ボトルネックになったのは各エージェントの判断精度ではなく、状態（state）の受け渡し形式のミスマッチだった。
フレームワーク選択については、2026年フレームワーク比較（jangwook.net）が示すように、LangGraphとCrewAIで役割が分かれてきた。CrewAIはコードが少なく（プロトタイプ20行程度）、役割ベースのエージェント設計を素早く試すのに向いている。一方、LangGraphはPyPIの月間ダウンロードが3,450万件と圧倒的で、有向グラフとして状態遷移を明示的に管理できるため、フォールトトレランスが求められる本番環境に適している。自分たちの判断は「プロトタイプはCrewAI、本番移行はLangGraph」だった。
# LangGraphで状態を持つエージェントの基本構造
from langgraph.graph import StateGraph, END
from typing import TypedDict, List
class AgentState(TypedDict):
messages: List[str]
retrieval_results: List[str]
verified: bool
def retrieve_node(state: AgentState) -> AgentState:
# 検索ロジック
results = hybrid_search(state['messages'][-1], corpus)
return {**state, 'retrieval_results': results}
def verify_node(state: AgentState) -> AgentState:
# 検索結果が十分か検証
verified = len(state['retrieval_results']) > 0
return {**state, 'verified': verified}
def generate_node(state: AgentState) -> AgentState:
# 回答生成（略）
return state
graph = StateGraph(AgentState)
graph.add_node('retrieve', retrieve_node)
graph.add_node('verify', verify_node)
graph.add_node('generate', generate_node)
graph.add_edge('retrieve', 'verify')
graph.add_conditional_edges(
'verify',
lambda s: 'generate' if s['verified'] else END
)
graph.set_entry_point('retrieve')
chain = graph.compile()
トレンド3：LLM推論効率化の最前線（REOとRLoT）
モデルの推論コストをどう下げるかは、本番で毎月請求書を見るたびに頭を悩ませる問題だ。2026年前半の注目技術は2つある。一つはREO（Reasoning Efficiency Optimization）で、Chain-of-Thoughtの「過剰推論（Overthinking）」を削減するアプローチだ。Early ExitやPruningを使って推論ステップ数を減らしながら精度を維持する。もう一つはRLoT（RL-of-Thoughts、arXiv 2505.14140）で、強化学習でナビゲーターモデルをトレーニングし、タスクに合わせた論理構造を動的に構築する手法だ。
インフラレベルでは、MITが2026年2月に発表した新手法が訓練効率を70〜210%向上させたと報告している。本番推論では、continuous batching・paged attention・speculative decoding・量子化を組み合わせることで、最適化前比でエネルギー消費を73%削減できることが示されている（Google Cloud Blog）。自分たちのケースではINT8量子化とspeculative decodingの組み合わせがレイテンシとコストのバランスで最善だった。
トレンド4：国内企業の導入事例から見えた現実
国内でAIエージェントを実際に本番稼働させている事例として注目したのがトヨタ自動車の「O-Beya」だ。複数のAIエージェントがエンジニアの専門知識を分担し、若手への技術継承を支援している。縦割りになりがちな専門知識を複数エージェントで横断的にカバーするという設計は、マルチエージェント設計の良いリファレンスになる。
金融領域ではMILIZEが複数のLLMを活用した「MILIZE Financial AGENT」でカスタマーサポートと事務処理を自動化している。KPMGジャパンがまとめたように、LLMの単体利用では段階的推論の不足とユーザーのデータ入力負荷という2つの課題がある。AIエージェントが「Planning → Tool Use → Reflection」のサイクルを自律的に回すことで、これらの課題を解消するアーキテクチャが標準化されつつある。
導入プロセスで共通して見えた教訓は、「重要な最終判断には必ず人間の承認ステップを入れる」ことだ。Human-in-the-loopを設計段階から組み込むかどうかで、本番後のトラブル件数が大きく変わった。特に金融・医療・法務では、エージェントが自律的に実行できる範囲を明示的にスコープしておくことが必須だ。
実装提案：評価ファーストのRAGエージェント構築フロー
以上を踏まえて、自分たちが採用しているフローは次の通りだ。
- Step 1：評価ハーネスを先に作る（Ragas or TruLens）。ゴールドセットを50〜100件用意し、Faithfulness・Answer Relevancyの基準値を決める
- Step 2：Naive RAGでベースラインを計測。ここで十分な精度が出れば複雑化は不要
- Step 3：ハイブリッド検索＋rerankerで改善。BM25 + dense + rerankerの構成で計測
- Step 4：必要ならAgentic化。「複数ステップの推論が必要」「外部ツール呼び出しが必要」のどちらかが計測で判明したときのみ
- Step 5：LangGraphで状態管理。本番移行前にフォールトトレランスと観測可能性（logging、トレース）を設計
まとめと今後の展望
本番RAGとAIエージェントの設計で一貫して言えることは、「シンプルから始めて計測値で判断する」だ。Agentic RAGは万能ではなく、シンプルな検索で十分なユースケースに複雑さを持ち込むとコストとレイテンシが跳ね上がる。エージェントオーケストレーションの失敗は9割がエージェント品質ではなく受け渡し設計の問題だ。LLM推論効率化はREOとRLoTが主戦場になっており、インフラ最適化と組み合わせることでコストを大幅に削減できる。2026年後半はAgentic RAGの評価手法の標準化と、マルチエージェントのオーケストレーション層の成熟が進むと予測している。国内では自律型エージェントの法的責任の整理が進み、金融・医療での本番事例が増えていくはずだ。
ABOUT ME
