rag 方法｜2026年版ガイド

RAGとは何か――基本概念と仕組みの全体像

RAG（Retrieval-Augmented Generation）は、大規模言語モデル（LLM）が回答を生成する際に、外部の知識データベースから関連情報をリアルタイムで検索・取得し、その内容を文脈として組み込む技術です。従来のLLMが学習時点の知識だけで回答を生成するのに対し、RAGは「検索」と「生成」を組み合わせることで、最新情報への対応・ハルシネーションの抑制・回答の根拠明示を同時に実現します。

本記事では、RAGの実装方法を段階的に解説します。データ準備からチャンキング・埋め込み・ベクトルDB構築・検索・プロンプト注入・生成まで、実際に動くシステムを構築するために必要な知識をすべて網羅します。コードスニペットやアーキテクチャ図も交えながら、初めてRAGを構築する方から、既存システムを改善したいエンジニアまで対応できる内容に仕上げています。

RAGの処理フロー――全体像を把握する

RAGシステムは「インデックス構築フェーズ」と「クエリ処理フェーズ」の2つに分かれます。まずフロー全体を把握してから、各ステップを詳しく見ていきましょう。

この2フェーズ構造を理解すると、各ステップでどのような設計判断が必要かが見えてきます。以下では順を追って解説します。

Step 1：ドキュメントの収集とテキスト抽出

RAGの品質はデータの質に直結します。どれだけ高度な検索・生成モデルを使っても、元のドキュメントが汚れていれば回答品質は下がります。まず「何を知識源にするか」を明確に定義し、適切な形式でテキストを取り出しましょう。

対応すべき主なドキュメント形式

形式	主な抽出ライブラリ／ツール	注意点
PDF	PyMuPDF、pdfplumber、LlamaParse	スキャンPDFにはOCRが必要（Tesseract等）
Word/Excel	python-docx、openpyxl、Unstructured	表・セルのレイアウト情報は失われやすい
HTML/Web	BeautifulSoup、Trafilatura、Jina Reader	ナビゲーションや広告テキストを除去する
データベース	SQLAlchemy＋カスタムローダー	カラム名・スキーマ情報も一緒に保持する
Markdown/テキスト	そのまま読み込み可（見出し構造を活用）	コードブロックを誤って分割しないよう注意

テキスト抽出後は、不要な空白・特殊文字・文字化けの除去、HTMLタグのストリッピング、重複コンテンツの排除といったクリーニングを行います。この前処理が不十分だと、後続のチャンキングや埋め込みの精度が著しく低下します。

Step 2：チャンキング――ドキュメントを適切な粒度に分割する

チャンキングはRAGの性能を左右する最重要ステップのひとつです。チャンクが大きすぎると無関係な情報がコンテキストに混入し、小さすぎると意味の文脈が失われます。用途に応じて戦略を選ぶことが重要です。

代表的なチャンキング戦略

実践的な選択指針：まずは固定長チャンキング（512トークン、オーバーラップ50）でベースラインを作り、評価スコアを確認してから構造ベースや親子チャンキングへ移行するアプローチが効率的です。

Step 3：埋め込み（Embedding）――テキストをベクトルに変換する

チャンク化したテキストを数値ベクトルに変換し、意味的な類似度計算を可能にするのが埋め込みモデルの役割です。埋め込みモデルの選択は検索精度に直接影響します。

主要な埋め込みモデルの比較

モデル	次元数	最大トークン	特徴
text-embedding-3-large（OpenAI）	3,072	8,191	多言語対応・高精度。API利用。
text-embedding-3-small（OpenAI）	1,536	8,191	コスト効率◎。日本語も十分対応。
multilingual-e5-large（Microsoft）	1,024	512	ローカル実行可。日本語精度が高い。
bge-m3（BAAI）	1,024	8,192	Dense＋Sparse＋Colbert対応。OSS。
Gemini text-embedding（Google）	768〜3,072	2,048	タスク別最適化（retrieval/classificationなど）

日本語ドキュメントを扱う場合の注意点：英語中心で学習されたモデルは日本語の意味空間での精度が落ちることがあります。multilingual-e5-largeやbge-m3はMTEBの日本語タスクでも高スコアを示しており、コストと精度のバランスを考慮して選択してください。

埋め込みの実装例（Python）

from openai import OpenAI

client = OpenAI()

def embed_texts(texts: list[str]) -> list[list[float]]:
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=texts
    )
    return [item.embedding for item in response.data]

# チャンクのリストを一括変換
chunks = ["チャンク1のテキスト", "チャンク2のテキスト", ...]
vectors = embed_texts(chunks)

Step 4：ベクトルデータベースへの保存と管理

生成したベクトルを高速に類似検索できるよう、専用のベクトルDBに格納します。ベクトルDBはテキストとそのメタデータ（ファイル名・セクション・日付など）をセットで保持し、検索時に上位k件を返します。

主要なベクトルDBの比較

DB名	形態	スケール	特徴
Chroma	OSS・ローカル	小〜中	セットアップ最速。プロトタイプに最適。
Pinecone	マネージドSaaS	大	フルマネージド。運用コスト低。本番向け。
Weaviate	OSS／Cloud	中〜大	ハイブリッド検索（BM25＋Vector）が標準搭載。
Qdrant	OSS／Cloud	中〜大	Rustベースで高速。フィルタリング機能が豊富。
pgvector（PostgreSQL拡張）	既存DB拡張	中	既存PostgreSQL環境に追加可。SQLで操作できる。
FAISS（Meta）	ライブラリ	大（GPU対応）	超高速。サーバー機能なし。ローカルバッチ処理向け。

選択基準：プロトタイプ段階ではChroma、本番環境でクラウド運用するならPineconeかQdrant、既存のPostgreSQL環境があればpgvectorが現実的です。ハイブリッド検索を最初から組み込みたい場合はWeaviateが有力です。

Step 5：検索（Retrieval）――関連チャンクを精度よく見つける

インデックスが完成したら、ユーザーのクエリに対して最も関連性の高いチャンクを取得します。ここでの検索品質がRAGシステム全体の精度を決定づけます。

検索手法の種類と使い分け

検索精度を上げる追加テクニック

• HyDE（Hypothetical Document Embeddings）：クエリに対してLLMに「仮想的な回答文書」を生成させ、その文書のembeddingで検索する。クエリ自体が短すぎる場合に有効。
• クエリ拡張：LLMでクエリを複数の言い換えに展開し、それぞれで検索した結果をマージする（Multi-Query Retrieval）。
• メタデータフィルタリング：日付・カテゴリ・ファイル種別などで検索対象を事前に絞り込み、ノイズを減らす。
• 最大周辺関連性（MMR）：類似度が高いだけでなく、多様性も考慮して結果を選択する。似たチャンクが重複して返されることを防ぐ。

Step 6：プロンプト構築とコンテキスト注入

取得したチャンクをLLMに渡す方法はシンプルに見えますが、プロンプトの設計次第で回答の品質・信頼性が大きく変わります。適切なプロンプト構造を設計することが重要です。

基本的なRAGプロンプトテンプレート

system_prompt = """
あなたは与えられた【参考情報】のみに基づいて質問に答えるアシスタントです。
参考情報に含まれない内容については「情報がありません」と明示してください。
回答は簡潔かつ正確に行い、必要に応じて出典のセクション名を示してください。
"""

context_text = "\n\n".join([
    f"【出典: {chunk.metadata['source']}】\n{chunk.text}"
    for chunk in retrieved_chunks
])

user_message = f"""
【参考情報】
{context_text}

【質問】
{user_query}
"""

プロンプト設計のポイント

• 情報源の明示：各チャンクに出典ラベルを付けると、LLMが根拠を引用しやすくなり、ハルシネーションが減る。
• コンテキスト長の管理：GPT-4oは最大128Kトークン対応だが、コンテキストが長くなるほど「Lost in the Middle」現象（中間の情報を見落とす）が起きやすい。重要なチャンクは先頭か末尾に配置する。
• 指示の明確化：「参考情報にない場合は回答しない」と明示することで、LLM自身の知識による「事実誤認回答」を防ぐ。
• チャンク数の調整：top_k=3〜5が一般的な出発点。多すぎるとコンテキスト汚染、少なすぎると情報不足になる。

Step 7：生成（Generation）とLLMの選択

プロンプトが完成したら、LLMが最終的な回答を生成します。RAGでは生成モデル自体の性能も重要ですが、指示追従性（インストラクション・フォロー能力）が特に求められます。

RAGに適したLLMの選定基準

• コンテキスト長：取得するチャンクの数と長さによっては長いコンテキストが必要。最低32K、理想的には128K以上を推奨。
• 指示追従性：「参考情報のみで答える」「根拠を示す」といった指示を正確に実行できるか。GPT-4o・Claude 3.5 Sonnet・Gemini 1.5 Proは特に優秀。
• 日本語能力：日本語ドキュメントと日本語クエリを扱う場合、日本語の理解・生成精度が高いモデルを選ぶ。
• レイテンシとコスト：リアルタイムチャットならgpt-4o-mini・Gemini Flash、品質優先ならClaude 3.7 Sonnetなどを選ぶ。

Step 8：評価――RAGシステムの品質を定量的に測る

実装後は「なんとなく動く」状態から「品質が計測・改善できる」状態に移行することが重要です。RAGの評価はRetrieval（検索）とGeneration（生成）を分けて考えます。

主要な評価指標

指標名	評価対象	概要
Context Recall	Retrieval	正解チャンクが取得できているか（再現率）
Context Precision	Retrieval	取得チャンクの中にノイズがないか（精度）
Faithfulness	Generation	回答が参照チャンクの内容に忠実か（ハルシネーション検出）
Answer Relevancy	Generation	回答がクエリに対して適切に答えているか
Answer Correctness	End-to-End	正解（グラウンドトゥルース）との一致度

評価フレームワークとしてRAGAS（Python製、上記指標を一括計算）やLangSmith（LangChain系のトレーシング・評価プラットフォーム）が広く使われています。まずRAGASで自動評価を導入し、スコアが低い指標に絞って改善施策を打つサイクルが効率的です。

Advanced RAG：精度をさらに高める発展的手法

基本的なRAGが動いたら、次は精度のボトルネックを特定して高度な手法を組み込みます。以下に代表的な発展手法を整理します。

Corrective RAG（CRAG）

検索結果の品質を自動評価し、スコアが低い場合はWebサーチやクエリ書き換えで補完する仕組みです。「取得したチャンクが実は関連性が低かった」という問題に対処できます。

Self-RAG

LLM自身が「検索が必要か」「取得した結果は使えるか」「回答は根拠に忠実か」を判断するReflectionトークンを生成しながら動作します。動的な検索制御が可能になり、不要な検索を省いてレイテンシを下げることもできます。

Agentic RAG

RAGをAIエージェントの一機能として位置づけ、複数の検索ソース（社内DB・外部API・Webなど）を動的に使い分ける構成です。LangGraphやLlamaIndexのWorkflowsで実装されるケースが増えています。複数ステップの推論が必要な複雑な質問に対応できます。

GraphRAG

Microsoftが提唱した手法で、ドキュメントからエンティティ（人物・組織・概念）と関係性を抽出してナレッジグラフを構築し、グラフ構造を活用して検索します。ドキュメント間の関係性や全体的なサマリーが必要なクエリに強みを持ちます。

よくある失敗パターンと対処法

症状	原因	対処法
関係ないチャンクが返ってくる	埋め込みモデルの言語ミスマッチ、チャンクサイズ過大	多言語モデルに変更、チャンクを小さく、リランキングを追加
ハルシネーションが多い	プロンプトの指示が曖昧、コンテキスト不足	「情報外の回答禁止」を明示、top_k増加、Faithfulnessを評価
同じ内容のチャンクが複数返る	重複ドキュメント、オーバーラップ過多	MMRで多様性を確保、インデックス時に重複排除
回答の根拠が古い	インデックスが更新されていない	差分更新パイプラインの整備、メタデータに更新日時を付与しフィルタリング
レイテンシが長すぎる	リランキングや検索のオーバーヘッド	キャッシュ活用、非同期検索、ANN（近似最近傍）インデックスの調整

RAG実装に使えるフレームワークとツールまとめ

• LangChain：RAGのオーケストレーションに最もよく使われるフレームワーク。多数のLLM・ベクトルDB・ローダーに対応。コンポーネントのLCEL記法で処理チェーンを宣言的に構築できる。
• LlamaIndex：データのインデックス管理に特化。親子チャンキング・クエリルーティング・エージェント機能が充実。RAG特化の要件には LangChainより直感的な場合が多い。
• Haystack（deepset）：エンタープライズ向けのRAGパイプラインフレームワーク。評価・モニタリングが充実。
• DSPy（Stanford）：プロンプトを手動で書くのではなく、最適なプロンプトを自動最適化するアプローチ。RAGのパイプライン全体をプログラムとして定義し、評価指標に対して最適化できる。
• RAGAS：RAGの評価専用ライブラリ。Context Recall・Faithfulnessなどを自動計算。評価データセットの自動生成機能も持つ。

まとめ

RAGの実装は、大きく「インデックス構築」と「クエリ処理」の2フェーズに分かれ、各ステップで設計判断が求められます。最終的な品質を決めるのはモデルだけでなく、チャンキング戦略・埋め込みモデルの選択・検索手法の組み合わせ・プロンプトの設計という4つの要素の総合力です。

まずはシンプルな構成（固定長チャンキング＋text-embedding-3-small＋Chroma＋gpt-4o-mini）でプロトタイプを作り、RAGASで評価スコアを計測したうえで、ボトルネックとなっているステップに絞って改善を加えていくアプローチが最も効率的です。評価ループを継続的に回すことで、実運用に耐えるRAGシステムへと育てることができます。

関連記事

• rag とは（総合ガイド）
• rag 事例
• rag 比較
• rag 無料