RAG方法の実装手順――7工程パイプラインを技術的に解説

RAG（Retrieval-Augmented Generation）の基本概念や定義については RAGとは何か――基本概念と全体像 を先に参照されたい。本記事はその先にある「実際にどう構築するか」に特化し、実装ステップの設計判断とトレードオフを作る側の目線で掘り下げる。

RAGは ETL→Chunking→Embedding→VectorDB→Retrieval→Generation→Evaluation の7工程で構成されるパイプラインであり、1工程でも設計が崩れればシステム全体の品質が低下する（Arpable・RAG完全ガイド2026）。以下では前半4工程（インデックス構築・オフライン）と後半3工程（クエリ処理・評価）に分けて、各ステップの実装上の勘所を体系的に示す。

RAG 方法の工程1〜4：インデックス構築フェーズ

インデックス構築はオフラインで完結する前処理工程だ。ここでの設計品質がシステム全体の精度上限を決める。「検索で的外れなチャンクしか返らない」という問題の大半は、このフェーズの設計ミスに起因する（Pionero・RAGパイプライン入門ガイド2026年版）。

工程1：ETL――ドキュメント収集とテキスト抽出

知識源となるドキュメントの範囲を明確に定義し、形式ごとに適切な抽出手段を選ぶ。抽出ツールの選定ミスは後続工程全体に悪影響を及ぼすため、入力フォーマットの棚卸しを最初に徹底する。

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

抽出後は、不要な空白・特殊文字・文字化けの除去と重複コンテンツの排除を行う。この前処理が不十分だとチャンキングおよび埋め込みの品質が著しく低下する。メタデータには更新日時・ソースURL・セクション名を付与しておくことで、後工程でのフィルタリングとインデックス鮮度管理が容易になる。

なお、社内文書をRAGのナレッジソースとして扱う際には著作権・個人情報の観点から利用範囲を整理しておく必要がある。文化庁「AIと著作権に関する考え方について」は、AI学習・生成と著作権の関係を整理した国内の権威ある参照資料である（文化庁・AIと著作権に関する考え方について（PDF））。RAGにおける個人情報・プライバシー保護の技術的手法については研究レベルでも議論が進んでおり（J-GLOBAL・Privacy protection in RAG: A novel method and evaluation）、本番導入前に法務・情報セキュリティ担当との連携を推奨する。

工程2：Chunking――意味の塊を崩さない分割設計

チャンキングはRAG 方法のなかで精度変動が最も大きいステップのひとつだ。チャンクが大きすぎれば無関係な情報がコンテキストに混入し、小さすぎれば意味の文脈が失われる。以下の4手法を用途に応じて使い分ける。

固定長チャンキングはトークン数で機械的に分割する最もシンプルな手法だ。256〜512トークン、オーバーラップ50〜100トークンが目安とされているが、ドメインや文書の文体によって変わるため実測して調整する。まずこれでベースラインを確立し、評価スコアを見ながら他手法へ移行するかを判断するのが効率的だ。

構造ベースのチャンキングは見出し（H1/H2/H3）やセクション区切りを基準に分割する。Markdownや構造化HTMLに有効で、意味の塊を崩さないため検索精度が安定しやすい。

再帰的テキスト分割（Recursive Character Splitting）は段落→文→単語の順で優先度の高い区切り文字を試みる方式だ。LangChainの RecursiveCharacterTextSplitter が代表実装で、構造が不明なドキュメントに汎用的に対応できる。

親子チャンキング（Parent-Child Chunking）は小さいチャンクで検索精度を確保し、ヒットしたら親チャンク（より広いコンテキスト）をプロンプトに渡す手法だ。LlamaIndexの「Small-to-Big Retrieval」がこれに相当する。検索の粒度と生成時のコンテキスト量を独立に最適化できる点が強みだが、インデックス設計が複雑になるというトレードオフがある。

工程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。

multilingual-e5-largeやbge-m3はオフライン環境での運用にも対応しており、情報セキュリティ要件が厳しい業務システムに向いている。埋め込みモデルのバージョンを変更した際は再インデックスが必要になる点も、運用設計に組み込んでおく必要がある。

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)

工程4：VectorDB――ベクトルを高速に検索可能な形で格納する

生成したベクトルはテキストとメタデータ（ファイル名・セクション・更新日時など）とともにベクトルDBに格納する。DBの選択は運用形態・スケール・既存インフラへの依存度によって変わる。

DB名	形態	スケール目安	選定のポイント
Chroma	OSS・ローカル	小〜中	PoC・プロトタイプに最適。セットアップが最速。
Pinecone	マネージドSaaS	大	フルマネージドで運用コストを抑えたい本番向け。
Weaviate	OSS / Cloud	中〜大	BM25＋Vectorのハイブリッド検索が標準搭載。
Qdrant	OSS / Cloud	中〜大	Rustベースで高速。メタデータフィルタリングが豊富。
pgvector（PostgreSQL拡張）	既存DB拡張	中	PostgreSQL環境があれば追加インフラ不要。SQLで操作できる。
FAISS（Meta）	ライブラリ	大（GPU対応）	超高速だがサーバー機能なし。ローカルバッチ処理向け。

PoC段階ではChroma、クラウド本番ではPineconeまたはQdrant、既存PostgreSQL環境があればpgvectorが現実的な選択肢だ。ハイブリッド検索を最初から組み込む場合はWeaviateが有力になる。DBの選定はランニングコストにも直結するため、初期段階から運用シナリオを意識した選択が求められる。

RAG 方法の工程5〜6：クエリ処理フェーズ（検索と生成）

クエリ処理はユーザーのリクエストに対してリアルタイムで実行されるオンライン工程だ。検索・プロンプト注入・生成の流れが連動する。ここでの設計ミスはユーザー体験に直接現れる。

工程5：Retrieval――ハイブリッド検索とリランキングでノイズを排除する

検索手法の選択はRAG 方法のなかで最も精度変動が大きいポイントだ。Dense検索（ベクトル類似検索）とSparse検索（BM25）を組み合わせてRRF（Reciprocal Rank Fusion）で統合するハイブリッド検索に、クロスエンコーダーによるリランキングを加えた構成が現時点のベストプラクティスとして広く採用されている（Zenn・RAG精度改善技術カオスマップ2026）。

Dense Retrievalはクエリと各チャンクの埋め込みベクトル間のコサイン類似度で順位付けする。意味的な類似性を捉えるため、言い換えや同義語にも対応できる。

Sparse Retrieval（BM25）はキーワードとの一致度を重視する。製品コード・固有名詞・専門用語のような完全一致が重要な場面でDenseを補完する。

リランキングは初回検索で上位20〜50件を取得し、クロスエンコーダー（CohereのRerank、bge-rerankerなど）でクエリとチャンクの適合度を再評価して上位k件に絞る。精度は向上するが計算コストが増大するため、レイテンシ要件と照らして導入可否を判断する必要がある。

そのほかの精度向上技法として以下が挙げられる。LLMに仮想的な回答文書を生成させてその埋め込みで検索するHyDE（クエリ自体が短すぎる場合に有効）、クエリを複数の言い換えに展開して結果をマージするMulti-Query Retrieval、日付・カテゴリなどで検索対象を事前に絞るメタデータフィルタリング、類似チャンクの重複返却を防ぐMMR（最大周辺関連性）。これらを組み合わせることで精度は高まる一方、実装の複雑さも比例して増す（Arpable・RAG完全ガイド2026）。

金融分野への応用については、金融庁金融研究センターがRAGを含む大規模言語モデルの評価手法を議論した資料を公開しており、実務領域での精度要件を考察する際の参考になる（金融庁・金融領域における大規模言語モデルの評価の進展とRetrieval（PDF））。

工程6：Generation――プロンプト設計とLLM選定

取得したチャンクをLLMに渡す際のプロンプト設計は、回答の品質・信頼性に直結する。以下の構造が実装の出発点として機能する。

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}
"""

コンテキスト長の管理：コンテキストが長くなるほど「Lost in the Middle」現象（プロンプト中間部の情報を見落とす）が生じやすくなる。重要なチャンクは先頭または末尾に配置し、top_kは3〜5を出発点として評価しながら調整する。多すぎればコンテキスト汚染、少なすぎれば情報不足となる。

LLM選定の軸：指示追従性（「参考情報のみで答える」という指示を正確に実行できるか）と対応コンテキスト長（最低32K、用途によっては128K以上）が主要な評価軸だ。日本語ドキュメントを扱う場合は日本語の理解・生成精度も事前に確認する。レイテンシ優先の構成ではコスト効率の高い軽量モデル、品質優先の構成では高性能モデルという使い分けが現実的だ。

RAG 方法の工程7：評価・継続改善と発展的アーキテクチャ

「なんとなく動く」状態から「品質が計測・改善できる」状態に移行することが、本番運用への必須ステップだ。RAGの評価はRetrieval（検索）とGeneration（生成）を分けて計測するのが基本であり、指標ごとにボトルネックを特定して改善施策を絞り込む。

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

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

よくある失敗と対処：

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

発展的アーキテクチャの選択

基本的なRAGが動作し評価スコアが計測できたら、ボトルネックに応じて高度な手法を段階的に組み込む。2025〜2026年にかけて、RAGは単なる検索拡張生成を超えてエージェント型アーキテクチャやマルチモーダル対応へと広がりつつある（algomatic・コンテキストエンジニアリングの歴史）。

Corrective RAG（CRAG）は検索結果の品質を自動評価し、スコアが低い場合はWebサーチやクエリ書き換えで補完する。「取得したチャンクが実は無関係だった」という問題に対処できる。

Self-RAGはLLM自身が「検索が必要か」「取得結果は使えるか」「回答は根拠に忠実か」をReflectionトークンとして判断しながら動作する。不要な検索を省いてレイテンシを低減できる一方、実装の複雑さが増すというトレードオフがある。

Agentic RAGはRAGをAIエージェントの一機能として位置づけ、社内DB・外部API・Webなど複数の検索ソースを動的に使い分ける。LangGraphやLlamaIndexのWorkflowsで実装されるケースが増えており、複数ステップの推論が必要な複雑なクエリに適する。

GraphRAGはMicrosoftが提唱した手法で、ドキュメントからエンティティと関係性を抽出してナレッジグラフを構築し、グラフ構造を活用して検索する。ドキュメント間の関係性や全体サマリーが必要なクエリに強みを持つが、グラフ構築のコストと運用の複雑さがトレードオフとなる（Zenn・RAG精度改善技術カオスマップ2026）。

RAGには固有の限界もある。コンテキスト長に収まらない大量の情報を同時参照できない点、ドキュメント間の複雑な関係性の推論が弱い点、インデックス鮮度管理や評価データセット整備という継続的な運用負荷が伴う点は、設計段階で許容できるかを明確にしておく必要がある。Fine-tuningや外部APIとの組み合わせも含めてアーキテクチャを選定することが重要だ。

実際のシステム構成やユースケースについては RAGの活用事例 を、他手法との選定基準については RAG比較ガイド を参照されたい。コストを抑えた検証方法は RAGの無料活用 にまとめている。RAGの基盤技術であるディープラーニングの原理については ディープラーニングの仕組み、機械学習全般の体系的な理解には 機械学習入門 が参考になる。テキストマイニングとの組み合わせ方法は テキストマイニング解説 も役立つ。

弊社が開発するDeepAI（バーチャルヒューマン／AIアバターソリューション）は、リップシンク・表情生成・音声合成・対話AIを組み合わせた構成を採用している。対話品質の向上にRAGを組み合わせるアーキテクチャは技術的な選択肢の一つであり、実装の検討に際してはご相談いただきたい。

---

参考文献

• 文化庁「AIと著作権に関する考え方について」（解説資料）
  https://www.bunka.go.jp/seisaku/chosakuken/pdf/94097701_02.pdf
• 金融庁金融研究センター「金融領域における大規模言語モデルの評価の進展とRetrieval」DP2024-3
  https://www.fsa.go.jp/frtc/seika/discussion/2024/DP2024-3.pdf
• J-GLOBAL「Privacy protection in RAG: A novel method and evaluation」
  http://jglobal.jst.go.jp/en/public/202602247563360891
• Arpable「RAG完全ガイド2026｜次世代RAGの選び方」
  https://arpable.com/artificial-intelligence/rag/rag-complete-guide/
• algomatic「コンテキストエンジニアリングの歴史：RAGの過去から現在をたどる」
  https://tech.algomatic.jp/entry/2026/01/28/190559
• Pionero「RAGパイプライン入門ガイド【2026年版】」
  https://www.pionero.io/ja/blog-detail/rag-pipeline/
• Zenn「RAG精度改善技術のカオスマップ　74の技術を6分類で整理」
  https://zenn.dev/epicai_techblog/articles/a78517cc0d5df2