RAG失敗の80%はチャンキングで決まる ― 2026年、Hybrid Graph RAG本番設計の要点

miomio0705

はじめに ― 「失敗の80%はチャンキングにある」という新しい現実

「RAGの精度が上がらない」という相談を受けるとき、原因を探るとたいてい同じ場所にたどり着く。LLMではなく、データの前処理段階だ。

2026年に入って蓄積されてきた本番事例の分析によれば、RAG失敗の80%はチャンキング(文書分割)の設計に起因し、セマンティックチャンキングへの移行だけで忠実度スコアが0.47〜0.51から0.79〜0.82に改善したという報告が複数出ている。さらに俯瞰すると、RAG全体の失敗の73%は生成ではなく検索ステップで発生している。つまり、いくらLLMが賢くなっても、取得する情報が間違っていれば答えは間違う。この記事では、そこから逆算して「2026年に何を設計すべきか」を整理する。

トレンド1:Hybrid Graph RAGが本番環境のベースラインになった

2026年現在、単純なベクトル検索(Naive RAG)は本番のベースラインから外れ始めている。多くの企業が採用しているのは、BM25(キーワード検索)+ベクトル検索を組み合わせた Hybrid RAG、そしてそこにナレッジグラフ層を加えた Hybrid Graph RAG だ。

研究報告によれば、グラフ+テキストのハイブリッドアプローチは、ベクトルRAGと比較してマルチホップ質問の回答品質を最大35%改善する。「A社のB部門が参照するC規約の改訂履歴」のような、複数文書をまたいで推論が必要なクエリに対して、グラフ層が構造的な文脈を補完するからだ。

Graph RAGの実装では、エンティティと関係性を抽出してナレッジグラフを構築し、グラフ上のマルチホップトラバーサルを検索に組み合わせる。実装コストはNaive RAGの3〜5倍とされているが、複雑な業務文書を扱うユースケースでは投資対効果が出やすい。

まずHybrid RAGへ移行し、マルチホップ推論が必要な領域のみGraph RAGを適用するというのが、2026年の現実的な設計パターンだ。

トレンド2:記憶を持つエージェントRAG(ExpRAG)の台頭

2026年3月に公開されたarXiv論文「Retrieval-Augmented LLM Agents: Learning to Learn from Experience」(arxiv: 2603.18272)は、エージェントが過去の検索経験をメモリとして蓄積し、次回の検索戦略の改善に活かす ExpRAG アーキテクチャを提案した。

従来のAgentic RAGは「クエリが来るたびにゼロから検索する」という構成だったが、ExpRAGでは「前回このクエリタイプではどの検索戦略が効果的だったか」を記憶として保持する。これはエージェントが何を取得するかだけでなくどう取得するかを学習することを意味し、反復的なタスクでの精度向上が報告されている。

同じ方向性で、Agentic RAGに関する包括的サーベイ論文(arxiv: 2501.09136、2026年4月更新)も、「反省・計画・ツール使用・マルチエージェント協調」という4つのエージェント設計パターンをRAGパイプラインに組み込む方向性を体系化している。

設計者の視点で重要なのは、エージェント化によって生まれる新しい失敗モード―停止条件の曖昧さによる無限ループ、各ステップの失敗が複合するコンパウンドエラー―を最初から設計に織り込むことだ。

トレンド3:RAGセキュリティという新たな設計課題

2026年に入って、これまであまり議論されてこなかった領域が急浮上している。RAGシステムのセキュリティだ。

2本の新しい論文(arxiv: 2603.21654「Towards Secure Retrieval-Augmented Generation」、2604.08304「Securing RAG: A Taxonomy of Attacks, Defenses, and Future Directions」)は、RAGパイプラインが検索ステップを経由した攻撃に対して脆弱であることを体系的に整理した。具体的には、コーパス汚染(悪意ある文書をインデックスに混入させる)、クエリ操作(プロンプトインジェクション経由で検索結果を誘導する)、コンテキスト改ざんなどの攻撃パターンが報告されている。

本番にRAGを導入する際は、検索結果のフィルタリング、インデックスへのアクセス制御、取得コンテキストの検証といったセキュリティ層を設計段階から組み込む必要がある。これは「後から追加できる機能」ではなく、アーキテクチャの前提として扱うべき課題だ。

トレンド4:マルチエージェントを使うべきかどうかの判断基準が整理された

Princetonの研究グループが2026年に発表した分析によれば、同一のツールとコンテキストを与えた場合、ベンチマークタスクの64%ではシングルエージェントがマルチエージェントと同等またはそれ以上の性能を示した。マルチエージェント化すると精度は約2.1ポイント上がるが、コストは約2倍、レイテンシは10〜30倍になる。

マルチエージェントが正当化されるのは以下のケースに限定されると考えてよい。

  • 真の並列処理が求められるタスク
  • 各サブタスクに異なる専門能力が必要な場合
  • コンテキストウィンドウが単一パス完了には長すぎる場合
  • 監査証跡のために別エージェントの分離が規制上必要な場合

「とりあえずマルチエージェント」で複雑さだけが増す設計を避けるために、この判断基準は明示的に持っておきたい。

実装提案:Hybrid RAG検索パイプラインのコード例

まず最初に実装すべきはHybrid RAG(BM25+ベクトル検索+Reranker)だ。以下はPythonでのシンプルな構成例:

from langchain.retrievers import BM25Retriever, EnsembleRetriever
from langchain_community.vectorstores import Qdrant
from langchain.retrievers.document_compressors import CrossEncoderReranker
from langchain_community.cross_encoders import HuggingFaceCrossEncoder

# BM25検索とベクトル検索を並列実行
bm25_retriever = BM25Retriever.from_documents(docs, k=20)
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})

# Ensembleで統合(BM25:30%, Vector:70%)
ensemble_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, vector_retriever],
    weights=[0.3, 0.7]
)

# Cross-Encoderでリランク(上位5件に絞る)
model = HuggingFaceCrossEncoder(model_name="cross-encoder/ms-marco-MiniLM-L-6-v2")
compressor = CrossEncoderReranker(model=model, top_n=5)
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=ensemble_retriever
)

# 検索実行:top-50取得 → rerank → top-5をLLMへ
results = compression_retriever.get_relevant_documents(query)

このパターン(top-50取得 → rerank → top-5を渡す)でRAGASメトリクスが15〜30%改善するというデータが複数の本番事例から報告されている。Naive RAGからの移行コストが最も低く、精度改善効果が大きい、最初の一手として推薦できる構成だ。

ビジネス活用事例

Hybrid Graph RAGの実用例として、法務・コンプライアンス領域での採用が進んでいる。複数の契約書と規約文書にまたがる「条項Aが条項Bと矛盾しないか」という複雑な質問に対して、グラフ構造が文書間の参照関係を保持することで、Naive RAGでは答えられなかった質問に対応できるようになっている。

カスタマーサポートでは、製品マニュアル(静的ナレッジ → RAG)と在庫・注文データ(ライブデータ → MCP)を組み合わせたハイブリッド構成が増えている。「この製品の交換部品は在庫ありますか?交換手順を教えてください」という一つのクエリに対して、RAGがマニュアルを検索し、MCPがリアルタイム在庫を参照する分業が機能し始めている。

インシデント対応では、マルチエージェントRAGがアクション可能な推奨事項を100%の率で提示したという事例も報告されており、シングルエージェントの1.7%と比べて劇的な改善が見られている。

まとめ ― 2026年のRAG設計で押さえておくべきこと

今回の調査で得た知見を3点に絞ると:

  1. チャンキングを最初に直す。失敗の80%がここにある。セマンティックチャンキングへの移行と、Rerankerによる「渡さない判断」を設計に組み込む。
  2. Hybrid RAGを本番ベースラインにする。BM25+ベクトル+Rerankerの組み合わせは、コストと精度のバランスが最も取れた現実解だ。Graph RAGはマルチホップ推論が必要な領域に限定して追加する。
  3. マルチエージェントは必要なときだけ。コスト・レイテンシ・複雑さのコストは非線形に増大する。判断基準を持った上でシングルエージェントから始めるのが現実的だ。

RAGのセキュリティという新しい課題も見えてきた。これは後回しにできない設計の前提として、早めに取り組みを始めておきたい。

次のスプリントでやろうとしていること:セマンティックチャンキングへの移行、Rerankerの閾値チューニング、そしてExpRAGのコンセプトを自分たちのユースケースで小規模に試すこと。また気づきがあれば書く。

ABOUT ME
記事URLをコピーしました