Agentic RAG実践ガイド｜4つのRAGパターン比較と選び方

「RAGを入れたのに、なぜか的外れな回答ばかり返ってくる…」

クライアント企業の社内ナレッジ検索プロジェクトで、まさにこの壁にぶつかりました。500ページ超の社内マニュアルをベクトルDBに格納し、検索→生成のパイプラインを組んだものの、「有給休暇の申請方法」を聞くと、なぜか「出張精算のフロー」が返ってくる。原因を調べると、固定長512トークンでチャンキングした結果、申請手順が2つのチャンクに分断されていたのです。

この経験から気づいたのは、RAGの成否は「どのパターンを選ぶか」と「チャンキング戦略」で8割決まるということです。2026年現在、RAGは大きく4つのパターンに分類され、それぞれ精度・コスト・実装難易度が大きく異なります。

この記事では、Naive RAG・Hybrid RAG・Graph RAG・Agentic RAGの4パターンを、実際のPythonコードとコピペ可能なプロンプトつきで徹底比較します。「どのパターンを、どの場面で使うべきか」が明確になるので、ぜひ最後まで読んでください。

4つのRAGパターン — 用途別おすすめ早見表

まず結論として、4パターンの特徴を一覧にまとめました。詳細は各セクションで解説します。

パターン	精度	コスト/クエリ	実装難易度	おすすめ用途
Naive RAG	70-80%	約$0.001	★☆☆☆☆	FAQ、単純な文書検索
Hybrid RAG	85-92%	約$0.005	★★☆☆☆	本番の標準構成、社内ナレッジ
Graph RAG	88-95%	約$0.01-0.05	★★★★☆	法務・医療など関係性が重要な領域
Agentic RAG	90-97%	約$0.02-0.10	★★★☆☆	複雑なマルチステップ質問、意思決定支援

精度：検索精度（Retrieval Precision）の目安。タスクとデータ品質により変動。コスト：GPT-4oクラスのモデル使用時（参照日: 2026-05-14）。

パターン選択の判断基準

迷ったときは、以下の3つの質問で絞り込めます。

1. 質問は単一文書で完結するか？ → Yes: Naive/Hybrid、No: Graph/Agentic
2. エンティティ間の関係性が重要か？ → Yes: Graph RAG、No: Hybrid/Agentic
3. 検索戦略を動的に変える必要があるか？ → Yes: Agentic RAG、No: Hybrid RAG

そもそもAgentic RAGとは何か

Agentic RAGは、従来のRAGパイプラインにAIエージェントの自律判断を組み込んだアーキテクチャです。従来のRAGが「検索→生成」の固定パイプラインだったのに対し、Agentic RAGではエージェントが「どのソースを検索するか」「追加検索が必要か」「回答の品質は十分か」を自ら判断します。

従来のRAGとの根本的な違い

項目	従来のRAG	Agentic RAG
検索戦略	固定（常に同じインデックスを検索）	動的（クエリに応じて検索先を選択）
検索回数	1回	必要に応じて複数回
ツール利用	なし	検索・計算・API呼び出し等
自己修正	なし	検索結果を評価し、不十分なら再検索
コスト	低い	10-100倍高い

Agentic RAGの3つの構成要素

Agentic RAGは以下の3要素で構成されます。

1. プランナー（Planning）：ユーザーの質問を分析し、検索戦略を決定する
2. ツール群（Tools）：ベクトル検索、キーワード検索、Web検索、計算ツール等
3. リフレクター（Reflection）：検索結果と生成回答の品質を評価し、必要なら再検索を指示する

事例区分: 自社検証
以下は弊社が実際に検証した4パターンの実装例です。実際のプロジェクトでは要件に応じてパラメータ調整が必要です。

パターン1：Naive RAG — まず動かす最小構成

Naive RAGは最もシンプルな構成です。文書をチャンクに分割し、ベクトルDBに格納し、クエリに類似するチャンクを取得してLLMに渡す。これだけです。

実装コード：15分で動くNaive RAG

LlamaIndexを使った最小構成の実装例です。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, llama-index>=0.12.0, openai>=1.30.0
# pip install llama-index llama-index-llms-openai llama-index-embeddings-openai

import os
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.llms.openai import OpenAI
from llama_index.embeddings.openai import OpenAIEmbedding

# 環境変数にAPIキーを設定（ハードコードNG）
# export OPENAI_API_KEY="sk-..."

Settings.llm = OpenAI(model="gpt-4o", temperature=0)
Settings.embed_model = OpenAIEmbedding(model="text-embedding-3-small")

# 1. ドキュメント読み込み
documents = SimpleDirectoryReader("./docs").load_data()

# 2. インデックス構築（チャンク分割→埋め込み→格納）
index = VectorStoreIndex.from_documents(
    documents,
    chunk_size=512,      # デフォルト512トークン
    chunk_overlap=50,    # 隣接チャンクとの重複
)

# 3. クエリ実行
query_engine = index.as_query_engine(similarity_top_k=3)
response = query_engine.query("有給休暇の申請方法を教えてください")
print(response)

ポイント：

• chunk_size=512はデフォルト値。ドメインによって256-2048の間で調整する
• similarity_top_k=3は取得チャンク数。多すぎるとノイズが増え、少なすぎると情報が不足する
• 埋め込みモデルはtext-embedding-3-smallがコスト効率最良（参照日: 2026-05-14）

Naive RAGの限界

Naive RAGは単純なFAQ検索には十分ですが、以下の場面で精度が大きく低下します。

• 複数文書を横断する質問（例：「AとBの違いは？」）
• 特定の固有名詞や型番を含む検索（ベクトル検索はキーワード完全一致が苦手）
• 表やリストの中のデータ検索

実際に検証したところ、Naive RAGパイプラインの検索精度は約70-80%で頭打ちになります（arxiv:2601.07711）。次のHybrid RAGでこの壁を突破します。

パターン2：Hybrid RAG — 本番環境の標準構成

Hybrid RAGは、ベクトル検索（意味的類似度）とキーワード検索（BM25）を組み合わせる構成です。2026年の本番環境では、この構成が事実上のスタンダードになっています。

なぜHybridが必要なのか

ベクトル検索は「意味」を捉えますが、固有名詞や型番の完全一致が苦手です。一方、BM25は文字列の一致に強いですが、表現が違う同義語を捉えられません。この2つを組み合わせることで、互いの弱点を補完します。

OpenAIのVector Store APIでは、内部的にReciprocal Rank Fusion（RRF、定数k=60）を使ってベクトル検索とBM25の結果を統合しています（参照: eesel AI, 2026-05-14）。

実装コード：LangChainでHybrid Search

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, langchain>=0.3.0, langchain-openai>=0.3.0
# pip install langchain langchain-openai langchain-community chromadb rank-bm25

from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain_community.retrievers import BM25Retriever
from langchain.retrievers import EnsembleRetriever
from langchain_core.documents import Document
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough

# ドキュメント準備（実際にはローダーで読み込み）
docs = [Document(page_content=text, metadata={"source": src}) for text, src in your_docs]

# 1. ベクトル検索用インデックス
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(docs, embeddings)
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

# 2. BM25検索用インデックス
bm25_retriever = BM25Retriever.from_documents(docs, k=5)

# 3. Ensemble（Hybrid）検索 — 重みで調整
hybrid_retriever = EnsembleRetriever(
    retrievers=[vector_retriever, bm25_retriever],
    weights=[0.6, 0.4],  # ベクトル60%、BM25 40%が出発点
)

# 4. RAGチェーン構築
llm = ChatOpenAI(model="gpt-4o", temperature=0)
prompt = ChatPromptTemplate.from_template(
    "以下のコンテキストに基づいて回答してください。n"
    "コンテキストに含まれない情報は「該当する情報が見つかりませんでした」と回答してください。nn"
    "コンテキスト:n{context}nn質問: {question}"
)

chain = (
    {"context": hybrid_retriever, "question": RunnablePassthrough()}
    | prompt
    | llm
)

result = chain.invoke("品番XJ-2024の耐熱温度は？")

チューニングポイント：

• weights=[0.6, 0.4]はベクトル寄りの初期値。固有名詞検索が多い場合はBM25の重みを上げる
• Rerankerを追加するとさらに精度向上（Cohere Rerank APIやBGE-reranker-v2が実績あり）
• チャンクサイズは512トークンが精度・F1スコアともに最良との検証結果が報告されている

Hybrid RAGで実現できる精度

Hybrid RAGを導入すると、Naive RAGの70-80%から85-92%程度まで検索精度が向上します。大多数のユースケースではこの構成で十分です。ただし、「部品Aの不具合が部品Bに影響する経路は？」のような関係性を追うクエリには限界があります。それがGraph RAGの出番です。

パターン3：Graph RAG — 複雑な関係性を扱う

Graph RAGは、ベクトルDBに加えてナレッジグラフ（知識グラフ）を構築し、エンティティ間の関係性を活用して検索精度を高めるアプローチです。

ナレッジグラフが解決する問題

通常のRAGでは、「AはBに影響する」「BはCの原因になる」という情報が別々のチャンクに格納されます。「AはCに影響するか？」という質問には、マルチホップ推論が必要ですが、ベクトル検索だけではAとCの関係を直接見つけることが困難です。

ナレッジグラフは、こうしたエンティティ間の関係を明示的に保持するため、マルチホップの質問にも対応できます。

実装コード：LlamaIndex × PropertyGraph

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, llama-index>=0.12.0
# pip install llama-index llama-index-graph-stores-neo4j neo4j

import os
from llama_index.core import PropertyGraphIndex, SimpleDirectoryReader, Settings
from llama_index.graph_stores.neo4j import Neo4jPropertyGraphStore
from llama_index.llms.openai import OpenAI

Settings.llm = OpenAI(model="gpt-4o", temperature=0)

# Neo4jに接続（Docker等で事前にneo4jを起動しておく）
graph_store = Neo4jPropertyGraphStore(
    username="neo4j",
    password=os.environ["NEO4J_PASSWORD"],  # 環境変数から取得
    url="bolt://localhost:7687",
)

documents = SimpleDirectoryReader("./docs").load_data()

# PropertyGraphIndexを構築（LLMがエンティティと関係を自動抽出）
index = PropertyGraphIndex.from_documents(
    documents,
    property_graph_store=graph_store,
    show_progress=True,
)

# クエリ実行
query_engine = index.as_query_engine(
    include_text=True,     # グラフ＋テキストの両方を使う
    similarity_top_k=5,
)

response = query_engine.query("部品Aの不具合がシステム全体に与える影響は？")

ポイント：

• ナレッジグラフの構築にはLLMを使うため、初期構築コストが高い（文書量に比例）
• Neo4jの代わりにNebula GraphやFalkorDBも使用可能
• 法務（契約条項間の関係）、医療（症状→疾患→治療の連鎖）、製造業（部品の依存関係）で特に有効

Graph RAGの注意点

Graph RAGは強力ですが、万能ではありません。ナレッジグラフの構築にLLMを使うため、抽出精度がLLMの能力に依存します。また、グラフの更新コスト（新しい文書を追加するたびにエンティティと関係を再抽出）も考慮が必要です。

2026年5月時点の研究では、Agentic RAGが単一の埋め込みベース検索ツールだけでGraph RAGと同等以上の精度を示すケースも報告されており（arxiv:2604.09666）、必ずしもグラフ構築が必要とは限りません。

パターン4：Agentic RAG — エージェントが検索を自律判断

Agentic RAGは、RAGパイプラインにエージェントの自律的な判断を組み込む最先端のアプローチです。エージェントがクエリの複雑さを判断し、検索戦略を動的に選択し、検索結果の品質を自己評価して必要なら再検索を行います。

アーキテクチャ全体像

Agentic RAGのフローは以下の通りです。

1. クエリ分析：エージェントがユーザーの質問を分析し、必要な検索戦略を決定
2. ツール選択：ベクトル検索、キーワード検索、Web検索、データベースクエリ等から最適なツールを選択
3. 検索実行：選択したツールで検索を実行
4. 結果評価：検索結果の関連性と十分性を評価
5. 再検索/回答生成：不十分なら別のツールで再検索、十分なら回答を生成

実装コード：LangGraph × ReActエージェント

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, langgraph>=0.4.0, langchain-openai>=0.3.0
# pip install langgraph langchain-openai langchain-community chromadb

from typing import Annotated, Literal
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_core.tools import tool
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.prebuilt import ToolNode

# --- ツール定義 ---
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma(persist_directory="./chroma_db", embedding_function=embeddings)

@tool
def search_knowledge_base(query: str) -> str:
    """社内ナレッジベースをベクトル検索します。社内規定、マニュアル、FAQ等を検索する場合に使用。"""
    results = vectorstore.similarity_search(query, k=5)
    return "nn".join([f"[{r.metadata.get('source', '不明')}]n{r.page_content}" for r in results])

@tool
def search_by_keyword(query: str) -> str:
    """キーワード完全一致検索。品番・型番・人名など固有名詞を検索する場合に使用。"""
    results = vectorstore.similarity_search(query, k=5, filter=None)
    # 実際にはBM25等のキーワード検索を使用
    return "nn".join([r.page_content for r in results])

@tool
def evaluate_answer_quality(question: str, answer: str, context: str) -> str:
    """回答の品質を評価し、追加検索が必要かを判定します。"""
    llm = ChatOpenAI(model="gpt-4o", temperature=0)
    eval_prompt = f"""以下の回答の品質を評価してください。
質問: {question}
コンテキスト: {context}
回答: {answer}

評価基準:
1. コンテキストに基づいているか（根拠あり/なし）
2. 質問に完全に答えているか（完全/部分的/未回答）
3. ハルシネーションはないか（なし/あり）

結果を「PASS」または「NEED_MORE_SEARCH: [追加で必要な検索内容]」で返してください。"""
    return llm.invoke(eval_prompt).content

tools = [search_knowledge_base, search_by_keyword, evaluate_answer_quality]

# --- グラフ構築 ---
llm = ChatOpenAI(model="gpt-4o", temperature=0).bind_tools(tools)

def agent_node(state: MessagesState):
    system_msg = """あなたは社内ナレッジを検索するAIエージェントです。
以下のルールに従って回答してください：
1. まずユーザーの質問を分析し、最適な検索ツールを選択する
2. 検索結果が不十分な場合は、別のツールで追加検索する
3. 回答は必ず検索結果に基づくこと。推測で回答しない
4. 該当情報がない場合は正直に「見つかりませんでした」と回答する"""
    messages = [{"role": "system", "content": system_msg}] + state["messages"]
    return {"messages": [llm.invoke(messages)]}

def should_continue(state: MessagesState) -> Literal["tools", END]:
    last = state["messages"][-1]
    return "tools" if last.tool_calls else END

graph = StateGraph(MessagesState)
graph.add_node("agent", agent_node)
graph.add_node("tools", ToolNode(tools))
graph.add_edge(START, "agent")
graph.add_conditional_edges("agent", should_continue)
graph.add_edge("tools", "agent")

app = graph.compile()

# 実行
result = app.invoke({"messages": [{"role": "user", "content": "品番XJ-2024の耐熱温度と、それを使用している製品一覧を教えて"}]})

ポイント：

• LangGraphのStateGraphでエージェントのフローを明示的に定義
• ツールのdocstringがエージェントのツール選択判断に直結するため、わかりやすく具体的に書く
• evaluate_answer_qualityツールで自己評価ループを実現（最大3回の再検索を推奨）
• コストは1クエリあたり$0.02-0.10。単純な質問にはNaive/Hybridで対応し、複雑な質問のみAgenticに回すAdaptive構成が実務的

Adaptive RAG：クエリの複雑さに応じて自動振り分け

2026年のベストプラクティスとして注目されているのが、Adaptive RAG（適応型RAG）です。クエリ分類器が質問の複雑さを判定し、適切なパイプラインに振り分けます。

• 単純な事実質問 → Naive RAG（低コスト・高速）
• 固有名詞を含む質問 → Hybrid RAG（キーワード検索併用）
• 関係性を追う質問 → Graph RAG（マルチホップ推論）
• 複雑なマルチステップ質問 → Agentic RAG（自律判断）

これにより、コストを抑えつつ複雑な質問にも対応できる構成が実現します。

4パターン機能・コスト徹底比較

機能比較テーブル

機能	Naive RAG	Hybrid RAG	Graph RAG	Agentic RAG
ベクトル検索	○	○	○	○
キーワード検索	×	○	△	○
マルチホップ推論	×	×	○	○
自己修正・再検索	×	×	×	○
動的ツール選択	×	×	×	○
リアルタイム情報	×	×	×	○（Web検索ツール追加時）
構築時間	15分	1-2時間	1-3日	半日-1日
スケーラビリティ	高	高	中	中-高

コスト比較（GPT-4o使用時）

パターン	1クエリあたり	月10,000クエリ	初期構築コスト
Naive RAG	〜$0.001	〜$10	低（ベクトルDB＋埋め込みのみ）
Hybrid RAG	〜$0.005	〜$50	低-中（BM25インデックス追加）
Graph RAG	〜$0.01-0.05	〜$100-500	高（グラフ構築にLLM費用）
Agentic RAG	〜$0.02-0.10	〜$200-1,000	中（ツール定義＋フロー設計）

コストはGPT-4oの料金体系（入力$2.50/1Mトークン、出力$10.00/1Mトークン）で試算。最終確認日: 2026-05-14。実際のコストはモデル選択、チャンクサイズ、検索回数により変動します。

用途別おすすめマトリクス

用途	おすすめパターン	理由
社内FAQ・マニュアル検索	Hybrid RAG	コストと精度のバランスが最良
カスタマーサポート	Hybrid RAG + Reranker	回答精度が直接CXに影響するため
法務・コンプライアンス	Graph RAG	条文間の参照関係が重要
医療情報検索	Graph RAG	症状→疾患→治療の連鎖を追跡
経営意思決定支援	Agentic RAG	複数ソース横断＋計算が必要
R&D・技術調査	Agentic RAG	Web検索と社内データの統合

コピペで使えるプロンプト5選

RAGの品質を左右するプロンプトを5つ、そのまま使える形で紹介します。実際に社内プロジェクトで検証済みのものです。

プロンプト1：チャンキング戦略設計

文書の特性に合ったチャンキング戦略を設計するプロンプトです。

# 注意: このプロンプトの出力結果は、必ず少量のテストデータで検証してから本番適用してください。

あなたはRAGシステムのチャンキング設計の専門家です。
以下の文書特性に基づいて、最適なチャンキング戦略を提案してください。

【文書特性】
- 文書タイプ: {社内マニュアル/契約書/技術仕様書/FAQ等}
- 平均文書長: {ページ数または文字数}
- 構造: {見出しあり/なし、表あり/なし、箇条書きあり/なし}
- 検索クエリの特徴: {短文質問/複雑な質問/固有名詞中心}

【出力形式】
1. 推奨チャンキング手法（固定長/再帰的/セマンティック/ドキュメント構造ベース）
2. 推奨chunk_size（トークン数）と根拠
3. 推奨chunk_overlap（トークン数）と根拠
4. 前処理で注意すべき点（表の扱い、ヘッダーの付与等）
5. 検証方法（どう確認すればチャンキングが適切かを判断できるか）

プロンプト2：検索クエリ最適化（Query Rewriting）

ユーザーのあいまいな質問を、検索に適した形式に変換するプロンプトです。

# 注意: 数字と固有名詞は、根拠（出典/計算式）を添えてください。

あなたはRAGシステムの検索クエリ最適化エンジンです。
ユーザーの質問を、ベクトル検索とキーワード検索の両方で最適な結果が得られるように変換してください。

【入力】
ユーザーの元の質問: {question}

【出力形式】
1. ベクトル検索用クエリ: {意味的に豊かな自然文に書き換え}
2. キーワード検索用クエリ: {固有名詞・型番・数値を抽出}
3. サブクエリ分解: {複合的な質問は2-3のサブクエリに分割}
4. フィルタ条件: {日付範囲、カテゴリ、部門等のメタデータフィルタ}

【ルール】
- 元の質問の意図を変えない
- 略語は正式名称に展開する（例: 有休→有給休暇）
- 質問に暗黙の条件があれば明示化する

プロンプト3：回答品質評価（RAG Judge）

RAGの生成回答がハルシネーションを含んでいないかを自動評価するプロンプトです。

# 注意: この評価プロンプトは自動品質チェックの一部として使用してください。最終判断は人間が行うことを推奨します。

あなたはRAGシステムの品質評価官です。
以下の回答を4つの基準で厳密に評価してください。

【評価対象】
質問: {question}
検索されたコンテキスト: {retrieved_context}
生成された回答: {generated_answer}

【評価基準（各1-5点）】
1. Faithfulness（忠実性）: 回答はコンテキストの情報のみに基づいているか？
   - 5点: 全ての主張にコンテキスト内の根拠がある
   - 1点: コンテキストにない情報を含んでいる（ハルシネーション）

2. Relevance（関連性）: 質問に対して的確に答えているか？
   - 5点: 質問の全ての側面に回答している
   - 1点: 質問と無関係な内容

3. Completeness（完全性）: 必要な情報を網羅しているか？
   - 5点: 追加情報の必要なし
   - 1点: 重要な情報が欠落している

4. Groundedness（根拠性）: 主張に具体的な根拠（ソース名、数値等）が示されているか？

【出力形式】
- 総合判定: PASS（平均4.0以上） / FAIL（平均4.0未満）
- 各基準のスコアと根拠
- FAILの場合: 具体的な改善案

プロンプト4：ハルシネーション検出

生成回答の各文がコンテキストに裏付けられているかを1文ずつ検証するプロンプトです。

# 注意: 不足している情報があれば、最初に質問してから作業を開始してください。

あなたはファクトチェッカーです。
生成された回答の各文を、提供されたコンテキストと照合し、裏付けの有無を判定してください。

【コンテキスト】
{retrieved_context}

【生成された回答】
{generated_answer}

【出力形式】各文ごとに：
| # | 文 | 判定 | 根拠 |
|---|---|------|------|
| 1 | {文1} | ✅裏付けあり / ⚠️部分的 / ❌根拠なし | コンテキストの該当箇所 or 「該当なし」 |

【最終判定】
- ❌が1つでもあれば: HALLUCINATION_DETECTED — 該当箇所を修正または削除
- ⚠️のみ: REVIEW_NEEDED — 人間による確認を推奨
- 全て✅: CLEAN

プロンプト5：RAGパイプライン診断

RAGの精度が低い場合に、ボトルネックを特定するための診断プロンプトです。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

あなたはRAGシステムのデバッグ専門家です。
以下の情報を分析し、精度低下の原因を特定してください。

【症状】
{精度が低い具体的な症状。例: 「特定のカテゴリの質問だけ的外れな回答が返る」}

【システム構成】
- チャンキング: {手法、chunk_size、overlap}
- 埋め込みモデル: {モデル名}
- ベクトルDB: {DB名}
- 検索方式: {ベクトルのみ/Hybrid/Agentic}
- LLM: {モデル名}
- top_k: {数値}

【失敗事例】
質問: {うまくいかなかったクエリ}
期待する回答: {あるべき回答}
実際の回答: {返ってきた回答}
検索されたチャンク: {取得されたチャンクの概要}

【診断出力】
1. 問題の層（チャンキング/埋め込み/検索/生成のどこか）
2. 推定原因（3つまで、確信度つき）
3. 検証方法（各原因の確認手順）
4. 修正案（優先度順）

【要注意】よくある失敗パターンと回避策

10社以上のRAG導入支援で繰り返し見てきた失敗パターンを4つ紹介します。

失敗1：チャンクサイズのデフォルト固定

❌ よくある間違い：chunk_size=512をそのまま全文書に適用する

⭕ 正しいアプローチ：文書の構造に合わせてチャンキング戦略を設計する。再帰的分割（RecursiveCharacterTextSplitter）で見出し→段落→文の順に分割し、表やコードブロックは分断しない設定にする。

なぜこれが重要か：RAG障害の80%は検索層に起因し、その大半がチャンキングの問題です。固定長512トークンで分割すると、手続きの途中や表の途中で切断され、検索時に不完全な情報が返ります。実際のプロジェクトでは、マニュアル系文書は1,024トークン、FAQ系は256トークンと、文書タイプごとに最適値が異なりました。

失敗2：ベクトル検索だけで本番運用

❌ よくある間違い：ベクトル検索のみで「品番XJ-2024」を検索し、全く関係ない結果が返る

⭕ 正しいアプローチ：Hybrid RAG（ベクトル＋BM25）を標準構成にする。固有名詞・型番・人名を含む検索はキーワード検索の方が確実。

なぜこれが重要か：ベクトル検索は意味的類似度に基づくため、「XJ-2024」と「XJ-2025」を区別できないことがあります。BM25を併用するだけで、固有名詞検索の精度が大幅に向上します。大規模な企業デプロイメントでは、Hybrid検索はほぼ必須とされています。

失敗3：いきなりGraph RAGを導入

❌ よくある間違い：「最先端だから」とGraph RAGから始め、ナレッジグラフの構築・維持コストに圧倒される

⭕ 正しいアプローチ：まずHybrid RAGで精度を検証し、「マルチホップ推論が必要なクエリが全体の何%を占めるか」を計測してからGraph RAGの導入を判断する。

なぜこれが重要か：Graph RAGのナレッジグラフ構築にはLLM費用がかかり、更新運用も複雑です。Agentic RAGが単一の埋め込みベース検索ツールだけでGraph RAGと同等の精度を達成する研究結果もあり、本当にグラフ構造が必要なケースは限定的です。

失敗4：評価パイプラインなしの本番デプロイ

❌ よくある間違い：「精度は感覚的に良さそう」で本番投入し、サイレントにハルシネーションが発生し続ける

⭕ 正しいアプローチ：デプロイ前に評価パイプラインを構築する。最低限、以下の3指標を自動計測する体制を整える。

• 検索精度（Retrieval Precision）：取得されたチャンクのうち、回答に有用だった割合
• 回答忠実性（Faithfulness）：回答がコンテキストに基づいているか
• ハルシネーション率：コンテキストにない情報を生成した割合（本番目標：5%未満）

なぜこれが重要か：RAGのハルシネーションは一見もっともらしい文章で返ってくるため、ユーザーが気づかないまま誤った情報を信じてしまいます。自動評価がなければ、問題の発見が遅れ、信頼の失墜につながります。上記プロンプト3「回答品質評価」を定期的に実行する仕組みを入れてください。

セキュリティとガバナンス

RAGシステムを本番運用する際、見落とされがちなセキュリティ上の注意点をまとめます。

アクセス制御の設計

ベクトルDBに格納された情報に対して、ユーザーの権限に応じたアクセス制御が必要です。「人事部の機密文書」が一般社員の検索結果に表示されてはなりません。

• チャンクのメタデータにaccess_levelやdepartmentを付与し、検索時にフィルタリング
• OpenAIのVector Store APIではユーザー権限に応じたフィルタが利用可能
• 社外秘文書は専用のインデックスに分離し、APIレベルでアクセスを制限

プロンプトインジェクション対策

RAGシステムでは、検索されたチャンクにプロンプトインジェクションが仕込まれるリスクがあります。ガードレールの導入を推奨します。詳しくはAIエージェント ガードレール比較｜NeMo・LlamaFirewall・Guardrails AIをご覧ください。

本番運用のモニタリング

RAGを本番に入れたら終わりではありません。継続的なモニタリングが必要です。

必須モニタリング指標

指標	目標値	計測方法
検索精度	≧85%	週次サンプリング評価（50件）
回答忠実性	≧90%	LLM-as-Judge（プロンプト3使用）
ハルシネーション率	＜5%	プロンプト4で自動検出
レイテンシ（P95）	＜3秒	APMツール（DataDog等）
ユーザー満足度	≧4.0/5.0	回答後のフィードバックボタン

NVIDIA AgentIQのようなAIエージェント運用可視化ツールを導入すると、これらの指標を統合的にダッシュボード管理できます。詳しくはAgentIQとは？NVIDIA製AI運用見える化基盤の記事を参照してください。

ドリフト検知と継続的改善

RAGの精度は時間とともに劣化します。社内文書の更新、新規文書の追加、ユーザーの質問パターンの変化により、構築時の前提が崩れるためです。

• インデックスの定期更新：文書更新を検知し、自動的に再チャンキング・再埋め込みを実行
• クエリログ分析：「回答が見つかりませんでした」の頻度を監視し、ナレッジベースのギャップを特定
• A/Bテスト：チャンクサイズやRerankerの変更はA/Bテストで効果を検証してから全面適用

参考・出典

• Is Agentic RAG worth it? An experimental comparison of RAG approaches — arXiv（参照日: 2026-05-14）
• Do We Still Need GraphRAG? Benchmarking RAG and GraphRAG for Agentic Search Systems — arXiv（参照日: 2026-05-14）
• Build a custom RAG agent with LangGraph — LangChain公式ドキュメント（参照日: 2026-05-14）
• Agentic RAG With LlamaIndex: Architecture Guide — LlamaIndex公式ブログ（参照日: 2026-05-14）
• Five guides to building and scaling production-ready AI agents — Google Cloud Blog（参照日: 2026-05-14）
• RAG in Production 2026: Chunking Strategies, Embedding Costs, and What Actually Works at Scale — Abhishek Gautam（参照日: 2026-05-14）
• Best Practices for AI Agent Implementations: Enterprise Guide 2026 — OneReach.ai（参照日: 2026-05-14）

まとめ：今日から始める3つのアクション

1. 今日やること：上記のNaive RAGコード（パターン1）を手元の文書で動かし、プロンプト5「RAGパイプライン診断」で現状の精度を確認する
2. 今週中：Hybrid RAG（パターン2）に切り替え、BM25を追加。固有名詞検索の精度改善を確認する
3. 今月中：プロンプト3「回答品質評価」を自動実行する評価パイプラインを構築し、ハルシネーション率5%未満を目標に運用を開始する

---

あわせて読みたい：

• AIエージェント ガードレール比較｜NeMo・LlamaFirewall・Guardrails AI — RAGシステムのセキュリティ強化に
• AgentIQとは？NVIDIA製AI運用見える化基盤 — RAGの運用監視ツール
• MCP認可の実装ガイド｜OAuth 2.1対応 — エージェントのツール連携時のセキュリティ

---

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。
100社以上の企業向けAI研修・導入支援。著書累計3万部突破。
SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。