renue

ARTICLE

RAG（検索拡張生成）とは？仕組み・ファインチューニングとの違い・LangChainでの実装方法

公開日: 2026/4/3

RAGの仕組み・ベクトルDB・ファインチューニングとの違い・LangChainでの実装方法を解説。

RAG（検索拡張生成）とは何か？基本概念をわかりやすく解説

RAG（Retrieval-Augmented Generation：検索拡張生成）とは、大規模言語モデル（LLM）が回答を生成する前に、外部の知識ベースやデータベースから関連情報を検索・取得し、その情報をもとに回答を生成する技術です。2020年にMeta AI（当時のFacebook AI Research）が発表した論文で提唱され、以降LLMを実用システムに組み込む際の標準的なアーキテクチャとして広く採用されています。

従来のLLMは学習済みの知識のみで回答を生成するため、学習データのカットオフ以降の情報には対応できず、社内固有の情報も参照できません。RAGはこの課題を解決し、最新情報や専門ドキュメントを活用した精度の高い回答生成を可能にします。

RAGを構成する主な要素は以下の3つです。

  • ドキュメントストア（知識ベース）：社内マニュアル、契約書、技術仕様書などのテキストデータを格納する場所
  • ベクトルデータベース（Vector DB）：ドキュメントを数値ベクトルとして保存・検索するデータベース
  • LLM（大規模言語モデル）：検索された情報を文脈として受け取り、自然言語で回答を生成するモデル

RAGの仕組み：ベクトル検索と埋め込みモデルの役割

RAGの処理フローは大きく2つのフェーズに分かれます。

インデックス作成フェーズ（オフライン処理）

  1. ドキュメントをチャンク（断片）に分割する
  2. 埋め込みモデル（Embedding Model）を使って各チャンクを高次元ベクトルに変換する
  3. 変換したベクトルをベクトルDBに格納する

推論フェーズ（オンライン処理）

  1. ユーザーの質問文を埋め込みモデルでベクトル化する
  2. ベクトルDB上でコサイン類似度などを用いた近傍検索を行い、関連チャンクを取得する
  3. 取得したチャンクとユーザーの質問をプロンプトに組み込み、LLMに送信する
  4. LLMが文脈を踏まえた回答を生成する

埋め込みモデルとしては、OpenAIのtext-embedding-3-smallやtext-embedding-ada-002、日本語向けにはintfloat/multilingual-e5-largeなどが広く利用されています。ベクトルDBにはFaiss、Chroma、Pinecone、Weaviate、pgvectorなどが選択肢として挙げられます。

RAGとファインチューニングの違い：どう使い分けるか

LLMをカスタマイズする手法として、RAGと並んで「ファインチューニング（Fine-tuning）」がよく比較されます。両者の特性と使い分けポイントを整理します。

項目 RAG ファインチューニング
知識の更新 DB更新のみで対応可能 再学習が必要
導入コスト 比較的低い GPU・データ準備コストが高い
情報の透明性 参照元を示しやすい 根拠の追跡が難しい
出力スタイル制御 プロンプトで調整 学習データで調整可能
最適なユースケース 社内ドキュメント検索・FAQ 特定ドメイン・文体の習得

RAGが適するケース：頻繁に更新される情報を扱う場合、情報の出典を明示したい場合、社内固有の大量ドキュメントを検索したい場合。

ファインチューニングが適するケース：特定の文体・回答スタイルをモデルに習得させたい場合、ドメイン固有の語彙・表現を強化したい場合、推論速度を最優先にしたい場合。

近年は両者を組み合わせた「RAG＋ファインチューニング」アーキテクチャも増えており、ファインチューニングでドメイン知識を習得させたうえでRAGによる最新情報参照を行うハイブリッド構成が注目されています。

LangChainとLlamaIndexを使ったRAG実装の基本ステップ

実際にRAGシステムを構築する際に広く利用されているフレームワークがLangChainとLlamaIndexです。それぞれの特徴と、LangChainを使った基本的な実装フローを紹介します。

LangChainとLlamaIndexの違い

  • LangChain：チェーン・エージェント・ツール連携など、LLMアプリ全般を構築するための汎用フレームワーク。RAG以外にも幅広いユースケースに対応
  • LlamaIndex：ドキュメントの取り込み・インデックス作成・クエリに特化した設計。RAG構築に特化した機能が充実しており、複雑なデータ構造の扱いに強い

LangChainでのRAG実装ステップ（Python例）

以下は、LangChainを使ったシンプルなRAGパイプラインの構築例です。

from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.chat_models import ChatOpenAI

# 1. ドキュメント読み込み
loader = TextLoader("company_manual.txt", encoding="utf-8")
documents = loader.load()

# 2. チャンク分割
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(documents)

# 3. 埋め込み生成＆ベクトルDB作成
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(chunks, embeddings)

# 4. Retrieverの設定
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

# 5. RAGチェーン構築
llm = ChatOpenAI(model="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)

# 6. 質問
answer = qa_chain.run("有給休暇の申請方法を教えてください")
print(answer)

上記のフローにより、社内マニュアルの内容を参照した回答が生成されます。実運用では、ChromaをpgvectorやPineconeなどのマネージドサービスに差し替えたり、プロンプトテンプレートをカスタマイズすることでより精度の高いシステムを構築できます。

RAGの精度を高めるための実践テクニック

RAGシステムを実際に運用すると、「検索精度が低い」「回答が的外れ」「ハルシネーションが減らない」といった課題に直面することがあります。以下の手法で精度向上を図ることができます。

チャンク設計の最適化

チャンクサイズは検索精度に直結します。サイズが小さすぎると文脈が失われ、大きすぎるとノイズが増えます。一般的には300〜600トークン程度が推奨されますが、ドキュメントの種類に応じて調整が必要です。オーバーラップ（重複）を設けることで、チャンク境界での情報欠落を防ぐことができます。

ハイブリッド検索

ベクトル検索（セマンティック検索）のみでなく、BM25などの全文検索（キーワード検索）と組み合わせるハイブリッド検索が有効です。LangChainのEnsembleRetrieverやLlamaIndexのQueryFusionRetrieverを使うことで実装できます。

リランキング（再ランク付け）

検索結果をそのままLLMに渡す前に、Cohere RerankやBGE Rerankerなどのリランキングモデルを使って関連度順に並び替えることで、LLMが最も重要な情報を優先的に参照できるようになります。

メタデータフィルタリング

ドキュメントに部門・日付・カテゴリなどのメタデータを付与し、検索時にフィルタリングすることで、無関係なドキュメントを排除して精度を高めることができます。

社内ドキュメントAI・RAGシステムの構築支援

社内マニュアル・契約書・技術仕様書を活用したRAGベースAIの設計・実装・運用を支援します。

RAGシステム導入の相談はこちら

RAGの主な活用シーンと導入効果

RAGは様々なビジネス場面で活用されています。代表的なユースケースと期待できる効果を紹介します。

社内ナレッジ検索・問い合わせ対応

社内規程・マニュアル・FAQをRAGで検索できるようにすることで、人事・総務・法務への問い合わせを削減できます。新入社員が自律的に情報を探せる環境を構築でき、オンボーディングの効率化にも繋がります。

契約書・法務ドキュメント検索

大量の契約書から特定の条項を素早く検索・比較できます。法務チームの作業時間短縮や、契約リスクの早期発見に役立ちます。

技術サポート・ヘルプデスク

製品マニュアルや過去のサポート履歴をRAGで検索し、サポート担当者へのアシスト機能として活用できます。回答の一貫性が向上し、対応品質が均一化します。

営業支援

提案書・事例集・競合情報などを社内で横断検索できるようにすることで、営業担当者が必要な情報にすぐアクセスできる環境を整備できます。

RAGシステム導入時の注意点とよくある失敗

RAGは万能ではありません。導入時に陥りやすい課題と対策を整理します。

  • ドキュメント品質への依存：インデックスに取り込むドキュメントが古い・不正確・重複していると、生成される回答の品質も低下します。定期的なドキュメント管理が不可欠です。
  • ハルシネーションの残存：RAGを使ってもLLMが検索結果を無視して誤情報を生成するケースがあります。回答に参照元ドキュメントを明示させる設計が重要です。
  • レイテンシの問題：検索＋生成の2段階処理のため、純粋なLLM呼び出しより応答時間が長くなりがちです。ベクトルDBのインフラ設計やキャッシュ戦略を考慮する必要があります。
  • セキュリティ・アクセス制御：社内の機密ドキュメントを扱う場合、誰がどの情報にアクセスできるかのアクセス制御をRAGシステムに組み込む必要があります。

よくある質問（FAQ）

Q1. RAGとChatGPTのGPTsは何が違いますか？

ChatGPTのGPTsは、OpenAIのインフラ上でWebブラウジングや外部APIを呼び出す機能です。一方、RAGは自社の任意のドキュメントを独自のベクトルDBに格納し、自社システム内で完結するアーキテクチャです。データの管理権と秘匿性をより強くコントロールできる点がRAGの強みです。

Q2. ベクトルDBは何を選べばいいですか？

小規模なPoC（概念実証）にはChromaやFaiss（ローカル動作）が手軽です。本番運用ではPinecone（フルマネージド）、pgvector（PostgreSQL拡張）、Weaviate（オープンソース）などが選択肢となります。既存インフラとの親和性や運用コスト、スケーラビリティを考慮して選択することを推奨します。

Q3. 日本語ドキュメントに対してRAGはうまく機能しますか？

日本語対応の埋め込みモデル（multilingual-e5-large、text-embedding-3-largeなど）を使用すれば、日本語ドキュメントでも高精度な検索が可能です。ただし、形態素解析を組み合わせたキーワード検索との併用（ハイブリッド検索）で精度がさらに向上します。

Q4. RAGシステムの構築にどれくらいのコストがかかりますか？

クラウドAPIを活用したPoC構築であれば、開発費用として数十万円〜が目安です。本番運用では、ベクトルDBのホスティング費用（数万円/月〜）、埋め込み処理・LLM呼び出しのAPIコスト、セキュリティ対策・アクセス制御の実装コストなどが加わります。社内ドキュメントの規模と更新頻度によって大きく変動します。

Q5. RAGはどのLLMと組み合わせて使えますか？

RAGはLLMに依存しないアーキテクチャのため、OpenAI GPT-4o、Anthropic Claude、Google Gemini、Azure OpenAI、Mistral、オープンソースのLlama 3など、ほぼあらゆるLLMと組み合わせることができます。LangChainはこれらのLLMを統一的なインターフェースで扱えるため、LLMの切り替えも容易です。

Q6. GraphRAGとは何ですか？

GraphRAGは、Microsoftが発表した手法で、ドキュメントからエンティティとその関係性をグラフ構造として抽出し、知識グラフを用いて検索・推論を行う拡張型RAGです。従来のベクトル検索では難しかった「関係性を横断した複雑な質問」への対応力が向上します。

navigate_before記事一覧へ戻る