RAGとマルチエージェントを本番投入してわかったこと：オーケストレーション境界が壊れる理由とLangGraph移行判断
なぜほとんどのRAG・エージェントは本番に届かないのか
今年に入って、社内の複数プロジェクトでRAGシステムとマルチエージェント基盤を本番投入する機会があった。PoC段階では「動いた」ものが、本番環境で思ったとおりに機能しないケースが続出した。Deloitte調査によれば、企業の72%がGenAIイニシアチブを抱えているにもかかわらず、本番まで到達するのはわずか15〜20%という現実がある。そしてエンタープライズAIエージェントに限っては、本番到達率がさらに低く、わずか5%という数字が報告されている（Dataiku「Agent orchestration explained」）。この記事では、実際に手を動かした経験から、今のAI技術スタックのどこが本番のボトルネックになるのかを整理する。
トレンド1：RAGの本番パターン——評価基盤なしでは何も改善できない
ここ半年でRAGアーキテクチャは急速に成熟した。Redis「RAG at Scale: How to Build Production AI Systems in 2026」では、本番運用チームが共通して辿り着く構成として「ページ単位のチャンキング → セマンティックキャッシュ → ハイブリッド検索（BM25 + dense embeddings）+ Cohere reranker + エージェント的な検証ステップ」という積み上げパターンが紹介されている。クエリルーティングを追加するだけでコストを40%削減し、レイテンシを35%改善した事例も報告されている。
ただし、個人的に最も効いたのは「評価基盤の整備」だった。モデルを替えてもチャンクサイズを変えても、評価ハーネスがなければ何が改善したのか判断できない。Galileo「RAG Architecture: From Naive Pipelines to Agentic」でも「ほとんどのRAGシステムは検索段階ではなく、評価段階で失敗する」と指摘されている。リグレッションを捕捉できないまま本番デプロイするのは、ブレーキなしで走るようなものだ。
実装上の判断として推奨するシーケンスは以下の通りだ。まず1クエリ・1検索パスで始める。リコールがボトルネックになった時点でクエリ拡張を追加する。上位K件の質が問題になった時点でリランキングを追加する。反復クエリがコストやレイテンシを圧迫した時点でキャッシュを追加する（参考：bitontree「RAG Architecture: 5 Production Patterns」）。この順序を守ることで、複雑性が明確な失敗モードに紐付き、無駄なレイテンシ増を防げる。
トレンド2：マルチエージェントオーケストレーション——本番5%の壁とフレームワーク選択
2026年時点で、エンタープライズAIワークフローの45%以上がエージェントオーケストレーションフレームワークを採用する見通しとなっているが（Kore.ai）、実際に本番稼働しているのはそのごく一部だ。本番到達率が5%にとどまる理由はエージェント単体の品質ではなく、「オーケストレーション境界」で発生する障害だという点が重要だ。複数エージェント間のハンドオフ・状態受け渡し・エラー伝播が最も壊れやすい箇所になる。
フレームワーク比較では、2026年時点の選択肢は明確になってきた（Alicelabs「Best AI Agent Frameworks 2026」・PEC Collective「AI Agent Frameworks Compared」）。LangGraphはグラフベースのステートフル実行で、障害後にエージェントを正確な中断点から再開するdurable executionとhuman-in-the-loopインタラプトを持つ。Klarna、Replit、Elasticが本番で採用している実績がある。CrewAIは役割ベースのチーム型で、プロトタイピングが速い反面、複雑な状態管理は苦手だ。A2Aプロトコル対応が追加されてエージェント間相互運用性は向上しているが、LangChainエコシステムへの依存度がないぶんLangGraphに軍配が上がる場面が増えている。
私たちが最終的にLangGraphを選んだ理由は「本番で何かが壊れた時に原因を追えるか」という観点だった。グラフとして状態遷移を可視化できるため、どのノードで何が失敗したかを明確に特定できる。CrewAIでのプロトタイプはエラーが連鎖した際の挙動が予測しにくく、本番デバッグに時間がかかりすぎた。
トレンド3：LLM推論効率の新手法——RLoTとMITのTLT
モデル自体の効率化では、学習時間と推論時間の両面で進展があった。MITが発表したTLT（Targeted Learning Technique）は、学習のダウンタイムを活用して推論LLMのトレーニングを加速する手法で、追加計算オーバーヘッドなしに70〜210%の学習加速を実現した（MIT News「New method could increase LLM training efficiency」）。
推論時間の効率化では、RLoT（RL-of-Thoughts）が注目に値する（arxiv「RL of Thoughts: Navigating LLM Reasoning with Inference-time RL」）。推論時間に強化学習を使ってナビゲーターモデルを訓練し、タスク固有の論理構造を適応的に構築する手法で、既存の推論時間技術を最大13.4%上回る性能を示している。また、speculative decoding・paged attention・quantizationの組み合わせ（Google Cloud「Five techniques to reach the efficient frontier of LLM inference」）は、ホスティングコストを現実的な水準に保つために今や必須の技術セットになっている。運用コストの観点では、これらを組み合わせないとGPUコストが経営上の問題になることを身をもって経験した。
トレンド4：国内動向——トヨタO-Beya、MILIZE、博報堂のマルチエージェント実装
国内でも具体的な本番事例が出始めた（EQUES「AIエージェントの業務活用事例6選」）。トヨタ自動車は「O-Beya」というAIエージェント基盤を導入し、9つのエージェントが開発分野ごとに連携して若手への技術継承と開発スピード向上を実現している。明確なタスク境界を持つ「開発支援」という領域から始めた点が成功要因の一つだろう。MILIZEの「MILIZE Financial AGENT」は金融業務特化型で、複数のLLMを適材適所で組み合わせて顧客対応・事務処理・口座開設案内を自動化している。博報堂テクノロジーズの「マルチエージェント ブレストAI」は、役割分担したAI同士が自律的に議論して多様なアイデアを生成するという新しい活用形態だ（参考：AX「LLMのマルチエージェント」）。
共通した課題はハルシネーションリスクと、マルチエージェント構成の設計・運用コストの高さだ。特に金融・医療など誤りが許されない領域では、エージェント出力の検証レイヤーをどう設計するかが差別化ポイントになっている。
実装提案：ハイブリッドRAG + LangGraphエージェントの基本構成
以下は、ハイブリッドRAGをLangGraphエージェントに組み込む最小構成例だ。まずハイブリッド検索部分：
from langchain_community.retrievers import BM25Retriever
from langchain_community.vectorstores import Chroma
from langchain.retrievers import EnsembleRetriever
from langchain_cohere import CohereRerank
from langchain.retrievers.contextual_compression import ContextualCompressionRetriever
# Dense retriever（ベクトル検索）
vectorstore = Chroma.from_documents(docs, embedding=embeddings)
dense_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})
# Sparse retriever（BM25）
bm25_retriever = BM25Retriever.from_documents(docs)
bm25_retriever.k = 20
# ハイブリッド: BM25 60% + Dense 40%
ensemble_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, dense_retriever],
weights=[0.6, 0.4]
)
# Reranker で上位5件に絞り込む
compressor = CohereRerank(top_n=5, model="rerank-english-v3.0")
compression_retriever = ContextualCompressionRetriever(
base_compressor=compressor,
base_retriever=ensemble_retriever
)
次に、LangGraphでこの検索をエージェントのノードとして組み込む：
from langgraph.graph import StateGraph, END
from typing import TypedDict, List
class AgentState(TypedDict):
query: str
retrieved_docs: List[str]
answer: str
needs_retry: bool
def retrieve_node(state: AgentState) -> AgentState:
docs = compression_retriever.invoke(state["query"])
# 検索品質の評価: スコアが低ければリトライフラグを立てる
if not docs or (hasattr(docs[0], 'metadata') and
docs[0].metadata.get('relevance_score', 1.0) < 0.5):
return {**state, "retrieved_docs": [], "needs_retry": True}
return {**state, "retrieved_docs": [d.page_content for d in docs], "needs_retry": False}
def generate_node(state: AgentState) -> AgentState:
context = "\n".join(state["retrieved_docs"])
answer = llm.invoke(f"Context: {context}\n\nQuestion: {state['query']}")
return {**state, "answer": answer.content}
def query_expand_node(state: AgentState) -> AgentState:
expanded = llm.invoke(f"Rephrase this query for better retrieval: {state['query']}")
return {**state, "query": expanded.content, "needs_retry": False}
def should_retry(state: AgentState) -> str:
return "expand" if state["needs_retry"] else "generate"
# グラフ構築
builder = StateGraph(AgentState)
builder.add_node("retrieve", retrieve_node)
builder.add_node("generate", generate_node)
builder.add_node("expand", query_expand_node)
builder.set_entry_point("retrieve")
builder.add_conditional_edges("retrieve", should_retry, {
"generate": "generate",
"expand": "expand"
})
builder.add_edge("expand", "retrieve")
builder.add_edge("generate", END)
graph = builder.compile()
このパターンで重要なのは needs_retry という状態管理だ。検索品質が閾値を下回った時点でクエリ拡張ノードに遷移し、再検索する。LangGraphのグラフ構造があることで、このフィードバックループを明示的に表現でき、デバッグ時に「どの状態でループしているか」が一目でわかる。CrewAIでやっていた時は同等のロジックが暗黙的で、本番ログから原因追跡するのに何時間もかかっていた。
ビジネス活用事例から学ぶ成功パターン
本番到達に成功しているプロジェクトには共通パターンがある（Medium「5 Generative AI Use Cases Actually Delivering ROI in 2026」）。①コンテンツスループットが高い（処理量が多い）、②タスク境界が明確で定義しやすい、③既存システムとのインテグレーションポイントが限られている——この3条件だ。コード生成・レビュー補助はこれを満たしており、Klarna（LangGraph採用）やRepilitで深くワークフローに組み込まれた事例がある。トヨタO-Beyaも「開発支援」という明確なタスク境界から始めている点が成功要因の一つだろう。
一方、失敗したPoC案件に共通していたのは「デモ最適化されていて、統合が考慮されていない」という構造的問題だった。実際のシステムに繋いで初めて出てくるエラーハンドリング・認証・レート制限・データスキーマの不整合が本番投入を阻む壁になる。この教訓はKPMGのLLMエージェント導入レポートでも繰り返し言及されていた（KPMG「LLM AIエージェント」）。
まとめ：今からやること3つ
技術は成熟してきているが、本番化のプラクティスはまだ整っていない段階だ。本番到達率5%という現実は、裏を返せば「ちゃんとやれば95%の競合に先行できる」ということでもある。今すぐ取り組むべきことを3点挙げる。
第一に評価基盤の構築——RAGの改善サイクルはここからしか始まらない。テストケースのキュレーションと自動リグレッション検出が最優先だ。第二にLangGraphの採用検討——ステートフルなエージェントが必要になった時点で、CrewAIからの移行コストよりLangGraphを最初から使うほうが長期的に安い。第三に国内事例の継続追跡——トヨタO-BeyaやMILIZEのような具体的な事例は、社内での導入提案に使いやすい。オーケストレーション境界の設計と評価基盤の整備、この2点が2026年後半の勝負どころだと判断している。
