RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ

LLMに社内文書について質問すると、的外れな回答や「ハルシネーション（幻覚）」が返ってくる——。この問題を解決するのがRAG（Retrieval-Augmented Generation＝検索拡張生成）だ。

2026年現在、RAGはエンタープライズAI導入の最も一般的なアーキテクチャパターンとなった。しかし「RAGとは」で検索しても、概念の説明で終わる記事がほとんどだ。本記事はRAGの仕組みを図解するだけでなく、LangChainで実際にRAGパイプラインを構築し、ベクトルDBを選定し、RAGASで品質を評価するところまでカバーする。コピペで動くコード付きの実践ガイドだ。

RAGとは——LLMのハルシネーションを解決する検索拡張生成

RAGとは「Retrieval-Augmented Generation（検索拡張生成）」の略で、2020年にMeta AI（旧Facebook AI Research）の Patrick Lewis らが提唱した手法だ。LLMが回答を生成する前に、外部のデータベースやドキュメントから関連情報を検索（Retrieve）し、その情報を文脈としてプロンプトに含めてから生成（Generate）する。

なぜRAGが必要なのか

LLMには3つの根本的な限界がある。RAGはこれらすべてに対処する。

RAGとファインチューニングの違い

LLMに新しい知識を与える手法として、RAGとファインチューニングがよく比較される。

2026年の実務では、まずRAGを導入し、それでも不十分な場合にのみファインチューニングを検討するのが標準的なアプローチだ。

RAGパイプラインの仕組みを図解——チャンキングからレトリーバルまで

RAGパイプラインは大きく「インデックス構築（オフライン）」と「検索＋生成（オンライン）」の2フェーズで構成される。

Step 1: チャンキング（テキスト分割）

ドキュメントをそのまま埋め込むと、1つのベクトルに大量の情報が詰め込まれ、検索精度が下がる。そこでドキュメントを適切なサイズの「チャンク」に分割する。MinerUのようなPDF変換ツールで前処理すると精度が向上し、エンティティ単位の索引付けが必要ならGoogle LangExtract完全ガイド：LLMで非構造テキストから構造化抽出、ソース位置も追跡を併用すると、抽出結果に原文位置を残したままインデックスへ落とし込める。

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=200,       # チャンク間の重複（文脈の断絶を防ぐ）
    separators=["\n\n", "\n", "。", "、", " "],  # 日本語対応
)
chunks = splitter.split_documents(documents)

Step 2: 埋め込み（Embedding）

チャンクを数値ベクトルに変換する。2026年時点の主要モデル比較は以下の通りだ。

日本語ドキュメント中心のRAGなら、BGE-M3（ローカル）またはtext-embedding-3-large（API）が実績豊富だ。

Step 3: ベクトル検索

質問文を同じ埋め込みモデルでベクトル化し、ベクトルDB内のチャンクとのコサイン類似度を計算して上位k件を取得する。

Step 4: LLM生成

検索されたチャンクをプロンプトの「コンテキスト」として挿入し、LLMに回答を生成させる。

prompt_template = """以下のコンテキストに基づいて質問に回答してください。
コンテキストに記載がない場合は「情報がありません」と回答してください。

コンテキスト:
{context}

質問: {question}
回答:"""

ベクトルデータベース比較2026——Pinecone・Qdrant・Chroma・pgvector

ベクトルDBはRAGのパフォーマンスと運用コストを左右する重要な選択だ。2026年時点の主要ベクトルDBを比較する。

# Qdrantをローカルで起動（Docker）
docker run -p 6333:6333 qdrant/qdrant:latest

# pgvectorを既存PostgreSQLに追加
CREATE EXTENSION vector;
CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)  -- OpenAI embedding次元数
);

RAG構築の実践——LangChainでゼロから作る

ここからが実装パートだ。LangChainの基本的な使い方を前提に、RAGパイプラインをゼロから構築する。RAG From Scratchシリーズも参考になる。

最小構成のRAG（30行）

from langchain_community.document_loaders import DirectoryLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA

# 1. ドキュメント読み込み
loader = DirectoryLoader("./docs", glob="**/*.md")
documents = loader.load()

# 2. チャンキング
splitter = RecursiveCharacterTextSplitter(chunk_size=800, chunk_overlap=200)
chunks = splitter.split_documents(documents)

# 3. ベクトルDB構築
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./chroma_db")

# 4. RAGチェーン構築
llm = ChatOpenAI(model="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
    return_source_documents=True,
)

# 5. 質問
result = qa_chain.invoke({"query": "RAGの精度を向上させる方法は？"})
print(result["result"])
for doc in result["source_documents"]:
    print(f"  出典: {doc.metadata['source']}")

このコードだけで、ローカルのMarkdownファイルに対するRAGチャットボットが動作する。Chromaはインメモリ動作するため、外部サービスの設定は不要だ。

LlamaIndex版（より簡潔）

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

# 3行でRAG完成
documents = SimpleDirectoryReader("./docs").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()

response = query_engine.query("RAGの精度を向上させる方法は？")
print(response)

LlamaIndexは「データフレームワーク」としての設計思想で、LangChainより少ないコードでRAGを構築できる。一方、カスタマイズ性はLangChainが優る。

LangChain vs LlamaIndex——どちらを選ぶか

実務ではLlamaIndexでプロトタイプを素早く作り、要件が複雑化したらLangChainに移行するパターンが多い。

Advanced RAG——HyDE・Multi-Queryで検索精度を上げる

基本的なRAGパイプラインでは、ユーザーの質問文と関連ドキュメントの「言い回しの違い」によって検索精度が下がることがある。Advanced RAGはこの問題に対処する技術群だ。

HyDE（Hypothetical Document Embeddings）

ユーザーの質問に対して、LLMが「仮想的な回答ドキュメント」を生成し、そのドキュメントの埋め込みベクトルで検索する手法だ。質問文より回答文のほうがドキュメントとの類似度が高くなるという洞察に基づく。

Multi-Query Retriever

1つの質問を複数の異なる表現に言い換え、それぞれで検索して結果を統合する。「異なる視点からの検索」で網羅性を高める。

from langchain.retrievers.multi_query import MultiQueryRetriever

retriever = MultiQueryRetriever.from_llm(
    retriever=vectorstore.as_retriever(),
    llm=ChatOpenAI(model="gpt-4o-mini"),
)
# 1つの質問から3つのバリエーションを自動生成して検索
docs = retriever.invoke("RAGの精度向上方法")

Agentic RAG

LLMがエージェントとして動作し、「どのデータソースから検索すべきか」を自律的に判断する。単一のベクトルDBだけでなく、SQL DB、Web検索、API呼び出しを組み合わせる高度なアプローチだ。2026年はMCP（Model Context Protocol）との統合により、エージェントが外部ツールにアクセスするパターンが急速に普及している。

RAGの品質評価——RAGASフレームワークで定量化する

RAGパイプラインを構築したら、品質を定量的に評価する必要がある。RAGAS（Retrieval Augmented Generation Assessment）は、RAGパイプライン評価の業界標準フレームワークだ。

3つの評価指標

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
from datasets import Dataset

# 評価データセット
eval_data = Dataset.from_dict({
    "question": ["RAGとは何ですか？"],
    "answer": ["RAGは検索拡張生成の手法で..."],
    "contexts": [["RAGはRetrieval-Augmented Generationの略で..."]],
    "ground_truth": ["RAGはLLMの回答精度を向上させる技術で..."],
})

result = evaluate(eval_data, metrics=[faithfulness, answer_relevancy, context_recall])
print(result)
# {'faithfulness': 0.92, 'answer_relevancy': 0.88, 'context_recall': 0.85}

RAG vs ロングコンテキスト——1Mトークン時代にRAGは不要か？

2026年、Claude Opus 4.6やGPT-5.4は100万トークン（約75万文字）のコンテキストウィンドウを持つ。「ドキュメントを全部コンテキストに入れれば、RAGは不要では？」という疑問が自然に浮かぶ。

結論：RAGとロングコンテキストは「競合」ではなく「補完」の関係だ。数十ファイルの小規模プロジェクトならロングコンテキストで十分だが、数千〜数万件のドキュメントを扱うエンタープライズ用途ではRAGが不可欠だ。実際、2026年の多くのエンタープライズRAGシステムは「RAGで関連ドキュメントを絞り込み → ロングコンテキストで深く理解する」というハイブリッドアプローチを採用している。

コスト試算：1,000件のドキュメントを扱う場合

• ロングコンテキスト：1,000件 × 平均2,000トークン = 200万トークン入力。Claude Opus 4.6で$10/クエリ。月100クエリで$1,000/月
• RAG：検索で上位5件に絞り込み → 10,000トークン入力。Claude Opus 4.6で$0.05/クエリ。月100クエリで$5/月 + ベクトルDB費用

大量ドキュメントを扱う場合、RAGのコスト優位は200倍になる。

エンタープライズRAG——Dify・RAGFlow・Onyxの使い分け

コードを書かずにRAGを構築できるエンタープライズ向けツールも充実している。とくにDify、RAGFlow、Onyxが2026年の三大選択肢だ。

選定の指針

• 非エンジニアがRAGチャットボットを作りたい → Dify（GUIでフロー構築、最も直感的）
• PDF・表・複雑なドキュメントを扱う → RAGFlow（DeepDocエンジンが表やレイアウトを正確に抽出）
• 社内の既存ツール（Slack/Confluence等）と連携 → Onyx（コネクタが豊富、検索特化）
• フルカスタマイズが必要 → LangChain/LlamaIndex（コードベースで完全制御）

参照ソース

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（RAG原論文, 2020）
• LangChain Documentation — RAG
• LlamaIndex Documentation
• RAGAS — Evaluation Framework for RAG
• Qdrant — Vector Search Engine（GitHub）
• Chroma — AI-native Embedding Database（GitHub）
• pgvector — Open-source Vector Similarity Search for Postgres
• RAGFlow — Deep Document Understanding RAG Engine（GitHub）
• Dify — Open-source LLM App Development Platform（GitHub）
• HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels（arXiv）