RAGとは？仕組みを図解＋ファインチューニングとの違い・実装の始め方まで解説

「ChatGPTに会社のマニュアルを参照させて、質問に答えさせたい」「新しい論文を検索して要約してほしい」——こうした用途では、モデルが学習した知識だけでは足りません。回答に必要な資料を、使うときに渡す方法があります。

その方法の1つが RAG（Retrieval-Augmented Generation／検索拡張生成） です。外部の資料から関連情報を検索し、モデルが回答するときの参考情報に加えます。資料を参照する既製のAI機能もありますが、ファイルのアップロードがすべて同じ検索処理になるわけではありません。

この記事では、RAGの仕組みを3ステップで図解し、ベクトルデータベース・LangChain実装・ファインチューニングとの使い分けまで、初心者でも理解できるレベルで、しかし技術的にも正確に 解説します。

1. RAGとは何か——Retrieval-Augmented Generation

RAG（Retrieval-Augmented Generation） は直訳すると「検索（Retrieval）で拡張された（Augmented）、生成（Generation）」という意味です。日本語では「検索拡張生成」と訳されます。

一言で説明すると、「LLM（大規模言語モデル）が回答を作るときに、外部から検索した関連情報を参考にする仕組み」です。この記事の図では、先に検索してから回答する基本形を説明します。検索先はベクトルDBに限らず、既存のデータベースやキーワード検索も使えます。

料理に例えると

LLM単体は「記憶だけで料理を作るシェフ」です。優秀だけれど、知らないレシピは作れないし、冷蔵庫の中身も知りません。

RAGはそのシェフに「レシピ本を渡し、冷蔵庫の中身を伝えてから料理させる」仕組みです。シェフはレシピ本を参照しながら、今ある食材で最適な料理を作れるようになります。

「Retrieval」「Augmented」「Generation」の役割

ポイントは、LLM自体を再学習させるのではなく、質問が来るたびに「必要な知識」を外部から渡す という点です。これが後述するファインチューニングとの決定的な違いです。

この基本形と、既存のSQLや資料管理システムも検索先にできる点は、LangChainのRetrieval解説で確認できます。

2. なぜRAGが必要なのか——LLM単体の3つの限界

ChatGPTやClaudeなどのLLM単体では解決できない問題が3つあります。

限界1: 知識カットオフ（情報の鮮度）

LLMの学習済み知識だけでは、その後に変わった情報を確かめられません。知識カットオフはモデルごとに異なり、学習後の出来事は資料や検索で補う必要があります。

• 「昨日発表された新製品について教えて」→ 発表資料を確認する
• 「先週更新された利用規約の内容は？」→ 新しい規約を確認する
• 「今日の為替レートは？」→ 時刻付きのデータを確認する

RAGでは、ニュース、データベース、APIなどから取得した情報を回答に使えます。ただし、検索先が古ければ回答も古くなり得ます。資料の更新と検索結果の確認が必要です。

限界2: ハルシネーション（もっともらしい嘘）

LLMは知らない情報を聞かれても、それらしく見える答えを作ってしまう 傾向があります。これをハルシネーション（幻覚）と呼びます。

例えば、非公開の社内規則を渡さずに「この会社の休暇日数は？」と聞くと、資料にない日数をもっともらしく答える可能性があります。これは説明用の例であり、この記事で実行・観測した回答ではありません。

RAGでは実際の資料を検索して参照させ、根拠に基づく回答を目指します。文書名やページなどの出典情報を保存しておけば、回答と一緒に提示できます。ただし、引用を表示しただけで内容が正しいとは限りません。資料の検索漏れや、モデルの読み違いは残ります。

限界3: 社内データ・プライベートデータへのアクセス不可

公開モデルが、自社の非公開マニュアルや契約書の内容を知っている前提にはできません。必要な資料を参照させる場合も、利用権限と送信先を確認する必要があります。

RAGは資料の関連部分を選んで渡す方法であり、それ自体が機密保護を保証する仕組みではありません。自社のDBに置いても、外部の埋め込みAPIやLLM APIを使えば資料・質問・検索結果が送信されます。検索時の利用者権限、送信先、保存・ログの扱いを確認してください。具体的な区別はFAQで説明します。

3. 仕組み——3ステップで動くRAG

RAGの動作は大きく分けて「事前準備（インデックス作成）」と「実行時（質問応答）」の2フェーズです。

事前準備フェーズ——ドキュメントをベクトル化して保存

1. 文書の収集：PDF、Word、HTML、Markdown等、使いたい文書を集める
2. チャンク分割：文書を適切な長さ（例：500〜1000文字）に分割する
3. 埋め込み（Embedding）：各チャンクを埋め込みモデル（例：OpenAI text-embedding-3-small）に通し、1536次元などのベクトル（数値の配列）に変換する
4. ベクトルDBに保存：チャンクと対応するベクトルを専用DB（Pinecone、Qdrant等）に格納

この作業はドキュメントが増えたときや更新されたときに実行します。

実行時フェーズ——質問に答える3ステップ

ユーザーから質問が来たときの処理は以下の通りです。

1. Step 1: Retrieval（検索）
   • 質問文を同じ埋め込みモデルでベクトル化する
   • ベクトルDBで質問に近いチャンクを上位K件（この例では3件）取得する
   • 近さの計算にはコサイン類似度などを使う
2. Step 2: Augmented（拡張）
   • 取得したチャンクを「参考情報」としてプロンプトに埋め込む
   • 「以下の情報を参考にして質問に答えてください: [検索結果] 質問: [ユーザーの質問]」のような形
3. Step 3: Generation（生成）
   • LLM（GPT、Claude、Geminiなど）が参考情報を基に回答を生成する
   • 必要に応じて「どの文書を参照したか」を引用として添える

具体例：社内の就業規則をChatGPTに聞く

以下の日数・勤続期間・条文番号は、仕組みを説明する架空の会社の規則です。実際の制度を示すものではありません。

「有給休暇は何日ありますか？」という質問の流れ:

1. 質問が埋め込みモデルでベクトル化 → [0.12, -0.45, 0.78, ...]
2. ベクトルDBから「休暇」「有給」関連のチャンク3件を取得
3. 取得したチャンク：「第15条 年次有給休暇 入社6ヶ月経過した社員には10日付与する...」「勤続年数に応じて最大20日まで...」等
4. プロンプト組み立て：「参考情報：第15条... 質問：有給休暇は何日ありますか？」
5. LLMが回答：「入社6ヶ月で10日、勤続年数に応じ最大20日付与されます（就業規則第15条参照）」

4. RAGの主要コンポーネント

RAGを構成する5つのコンポーネントを見ていきます。

① 埋め込みモデル（Embedding Model）

テキストを数値のベクトルに変換するAIモデルです。「意味的に似ているテキストは、ベクトル空間でも近い位置にある」ように訓練されています。

OpenAIモデルの標準次元と短縮方法は、公式Embeddingガイドを参照してください。候補を比較する際は、次元数だけでなく自社資料の検索結果を評価します。

② ベクトルデータベース

ベクトルを保存し、似たベクトルを検索するDBや拡張機能です。詳細は次章で解説します。

③ 検索エンジン（Retriever）

ベクトル検索に加え、キーワード検索（BM25など）やハイブリッド検索を組み合わせることも多い。

④ LLM（生成側）

最終回答を作る大規模言語モデル。GPT、Claude、Gemini、Llamaなど。商用APIでもOSSローカルモデルでも動きます。どの系列も版が次々に入れ替わるので、いまの具体的なモデル名は主要AIモデルの一覧で確かめてください。

⑤ プロンプトテンプレート

検索結果とユーザー質問を組み合わせてLLMに渡すためのテンプレート。RAGの精度を左右する重要な要素です。

あなたは社内規則に詳しいアシスタントです。
以下の参考情報のみに基づいて質問に回答してください。
参考情報にない場合は「情報がありません」と回答してください。

【参考情報】
{retrieved_chunks}

【質問】
{user_question}

【回答】

5. ベクトルデータベースとは

ベクトルDBは、高次元のベクトルを保存し、似たものを検索するための索引や機能を備えています。専用サービスのほか、PostgreSQLのpgvectorなど、既存DBに機能を加える構成もあります。検索速度や精度は、索引・データ量・設定で変わります。

主要なベクトルDB比較

どれを選ぶべきか

料金表のPinecone・Weaviateは2026年10月9日に公式料金ページで確認しました。無料のソフトウェアでも、セルフホストのサーバー・保守費は別です。クラウドでは容量、検索量、追加AI機能、バックアップなどで総額が変わります。

• Pythonで検索を試したい：Chromaなど（使用パッケージとモデルを準備）
• 既存のPostgreSQL活用：pgvector（DBをまとめられる）
• インフラ管理をサービスに任せたい：Pineconeなどのマネージドサービス（索引・容量・権限の設定は必要）
• セルフホストしたい：QdrantまたはWeaviateなど（運用と権限を自分で管理）
• 資料が多い：Milvusなどを候補にし、実データで索引・容量・検索性能を評価

ちなみに、ホスティング先の選び方については PaaS（Vercel等）とレンタル・VPS・クラウドの比較 も参考になります。

6. 主な用途——どこでRAGは使われるか

RAGは、社内文書や商品情報などを参照して答えるシステムに使えます。ここでは用途の例を紹介します。

用途1: 社内ドキュメントQA（ナレッジベース）

就業規則、業務マニュアル、技術仕様書、議事録、営業資料などを検索し、社員の質問への参考情報にする用途です。利用者ごとに参照できる資料を分け、変更された文書を索引に反映する設計が必要です。

用途2: カスタマーサポート自動化

FAQやサポート履歴をRAG化し、チャットボットで一次対応を自動化。人間のオペレーターは複雑な問い合わせに集中できます。

用途3: 法律・医療の専門知識Q&A

判例、医学論文、ガイドラインなどの資料を検索し、専門家が確認するための参考情報をまとめる用途です。出典を表示し、資料の適用条件と回答内容を人が確認する設計が必要です。引用があるだけで、判断の正しさや安全性は保証されません。

用途4: 研究論文検索・要約

利用を許可された論文や抄録を検索し、「この研究テーマの動向は？」「この手法に関連する研究は？」といった質問の参考情報にする用途です。取得できた資料の範囲と発行日を示し、原文で結果や研究条件を確認します。

用途5: ECサイトの商品検索・FAQ

商品マニュアル、レビュー、返品ポリシー等を統合したRAG。「この掃除機はペットの毛にも対応していますか？」のような自然言語検索が可能に。

用途6: 開発者向けドキュメントチャット

ライブラリの公式ドキュメントを検索し、「この処理のサンプルコードは？」といった質問に答える用途です。版の異なる資料を混ぜないよう、対象の版も検索条件に含めます。

用途7: 社内コードベースの検索・説明

コードや設計資料を検索し、「この関数の使い方は？」「似た処理を実装しているファイルは？」といった質問の参考情報にする用途です。GitHub Copilot ChatやCursor、Claude Code等の開発AIでもコードの参照が役立ちますが、各製品の内部処理がこの図と同じとは限りません。

用途8: llms.txtなど新しいAI最適化

llms.txtは、サイトの資料への案内をテキストで用意する提案です。検索や資料収集の手がかりにできますが、AIが読み込むことや、正しく引用することを保証する規格ではありません。

7. RAG vs ファインチューニング——どちらを選ぶ

「LLMに独自知識を持たせる」方法としてRAGと並んでよく議論されるのが ファインチューニング（Fine-tuning） です。両者は根本的にアプローチが異なります。

根本的な違い

RAGが向いている場面

• 知識が頻繁に更新される（ニュース、社内文書、商品情報）
• 回答の根拠を明示する必要がある（法律、医療、金融）
• 質問ごとに必要な資料が異なり、毎回全文を渡すより関連部分を検索する構成を検討したい
• モデルを再学習せずに、資料を参照する試作を始めたい

ファインチューニングが向いている場面

• 特定の文体・トーンで回答させたい（企業ブランド、キャラクター性）
• 専門分野の言語パターンを学習させたい（医療用語、法律文体）
• プロンプト短縮や小さなモデルへの置換による費用削減を、学習費も含めて検証したい
• 期待する応答の学習例と、評価用データを用意できる

追加学習の提供条件はサービスごとに異なります。2026年10月9日に確認したOpenAIの公式資料では、ファインチューニングは新規利用者に提供されていません。利用できるモデル・契約条件を先に確認してください。

必要なら組み合わせて評価する

RAGとファインチューニングは組み合わせ可能です。例えば応答の形式を追加学習で調整し、更新される資料は検索で渡す構成があります。ただし、組み合わせれば必ず品質が上がるわけではありません。

まず期待する回答と評価方法を決め、指示や資料の追加で足りるか試します。資料の参照が必要ならRAG、出力の傾向を調整したいなら追加学習を検討します。費用・速度・回答品質は実際の入力で比べてください。OpenAIの改善手順も、評価と指示の改善を行い、必要な用途で追加学習を検討する流れです。追加学習後のモデルをローカルで動かせるかは、重みの配布・ライセンス・実行環境によります。

8. 自前で組む前に——手元の資料で試す手順

RAG を自分で組む前に、手元の資料で「検索して答えさせる形がそもそも役に立つか」を確かめると遠回りしません。多くの場合、最初の確認はコードを書かずにできます。

手順1：資料全体を渡せるか見積もる

資料全体が使うモデルのコンテキストに収まるなら、検索を挟まずに渡す方法もあります。Anthropicは2024年のContextual Retrieval解説で、20万トークン（約500ページ）未満なら全量をプロンプトへ入れる案と、プロンプトキャッシュによる効率化を紹介しました（公式解説）。20万トークンは全モデル共通の判定基準ではありません。現在のモデルの入力上限、資料の長さ、回答品質、費用で判断してください。

手順2：既製の「プロジェクト」機能に資料を入れて質問する

Claude の Projects は、入れた資料がコンテキストの上限に近づくと自動で RAG に切り替わり、最大10倍の量を扱えます。有料プランの機能で、切り替わると画面に表示が出て、回答時には「project knowledge search」ツールが使われます（Claude ヘルプセンター）。ChatGPT の Projects も資料を置いて質問でき、ファイル数などの上限はプランごとに決まっています。

手順3：答えが分かっている10問で確かめる

資料のどこに答えがあるか自分で分かっている質問を10問作り、次の3点を記録します。

1. 答えは正しいか
2. 根拠として示した箇所は合っているか
3. 資料に無いことを聞いたとき、「資料にありません」と答えるか

3つ目で作り話が出るなら、「資料に無ければ無いと答える」と指示し直して再確認します。10問は最初の試行の例であり、大半に答えられても本番適性や安全性が証明されるわけではありません。重要な質問、似た資料、矛盾、閲覧権限などの条件を増やして評価します。

手順4：制御が必要なら、自前とマネージドを比較する

検索改善の例として、AnthropicはContextual EmbeddingsとContextual BM25の組み合わせで上位20チャンクの検索失敗率が49%減り、再ランク併用で67%減ったと報告しています（同社の実験条件と結果）。これは同社の評価データによる検索の測定であり、自社の回答ミスが同じ割合で減る保証ではありません。

自前で組む最小の形は次の章で、本番向けの改良（ハイブリッド検索・再ランクなど）はRAGとベクトルDBの実装ガイドで扱います。

9. 実装方法——LangChainで作るRAG

RAG実装の代表的なフレームワークを紹介した後、Pythonでの最小サンプルコードを示します。

主要フレームワーク

LangChainによる最小RAGサンプル

PDFの関連箇所を検索し、その内容を渡して回答させる学習用の例です。LangChain 1.xはPython 3.10以上が必要です。APIキーを環境変数OPENAI_API_KEYに設定し、使用するOpenAI APIモデルへアクセスできる環境を用意します。キーをコードや公開リポジトリへ書き込まないでください。

この例では、PDFのテキストと質問を埋め込みAPIへ、検索結果と質問をLLM APIへ送信します。Chromaを手元で動かしても、全処理がローカルで完結する例ではありません。APIはChatGPTの契約とは別に料金・利用条件を確認し、送信してよい非機密の資料で試してください。このコードは動作を確かめていない学習用の例です。動かす前に、使うライブラリの版で公式の書き方と照らしてください。

# pip install -U langchain-openai langchain-chroma langchain-text-splitters langchain-community pypdf
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma

# 1. ドキュメント読み込み
loader = PyPDFLoader("kisoku.pdf")
docs = loader.load()

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

# 3. 埋め込み + ベクトルDB構築
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(chunks, embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

# 4. 検索（質問に近いチャンクを3件取る）
question = "有給休暇は何日ありますか？"
found = retriever.invoke(question)
context = "\n\n".join(d.page_content for d in found)

# 5. 根拠を渡して回答を生成
llm = ChatOpenAI(model="gpt-6-luna")
answer = llm.invoke([
    {"role": "system", "content": "次の資料だけを根拠に答えてください。資料に無ければ「資料にありません」と答えてください。\n\n" + context},
    {"role": "user", "content": question},
])
print(answer.content)
print("参照元:", [d.metadata for d in found])

この例はPDFから関連箇所を検索し、GPT-6 Lunaに参考情報を渡して回答させる構成です。最後に取得した文書のメタデータも出力します。ページなどの情報は元資料・ローダーに依存し、回答文の引用が正しいかは別途確認が必要です。

gpt-6-lunaは2026年10月9日に公式モデルページで確認したIDです。利用前に公式モデル一覧で、対応API・利用条件・料金を確かめてください。モデルを選ぶ際は、同じ資料と質問で根拠の読み取り、回答品質、速度、費用を比較します。

上のコードはLangChain 1.x系のパッケージ構成を使う例です。LangChain 1.0で、古いサンプルのlangchain.chains（RetrievalQAなど）は別パッケージlangchain-classicへ移りました。ここではテキスト分割をlangchain_text_splittersから読み込み、公式が「2-Step RAG」と呼ぶ形——先に検索し、見つかった根拠を渡して回答を作る——を2段で書いています。読み込み先とPython要件は、公式移行ガイドで確認してください。実装時は使用したパッケージの版を記録し、再現できる環境で検証します。

より本番向けの実装では

• チャンク分割の最適化（セマンティック分割、階層チャンク等）
• ハイブリッド検索（ベクトル + キーワードBM25の組み合わせ）
• リランキング（Cohere Rerank、voyage-rerank等で検索結果を再並び替え）
• クエリ書き換え（HyDE、Multi-Queryなどで検索精度向上）
• 評価パイプライン（RAGASを使った自動評価）

10. RAGの課題と対策

RAGの実運用では、次の点を確認します。

課題1: チャンク分割の難しさ

文書をどう分割するかで検索精度が大きく変わります。短すぎると文脈が失われ、長すぎると検索精度が落ちます。

対策：

• セマンティック分割（意味的なまとまりで区切る）
• オーバーラップ設定（隣接チャンクと一部重複させる）
• 階層的チャンク（親子構造で保存し、検索は子・参照は親）

課題2: Retrieval（検索）の精度

似ているようで違うチャンクを取ってしまう、重要な情報を取り逃がす等。

対策：

• ハイブリッド検索（ベクトル + BM25キーワード）
• リランキングモデルで検索後に並び替え
• 複数クエリ生成（同じ質問を異なる言い回しで検索）

課題3: コンテキスト長の制限

LLMに渡せるトークン数には上限があり、大量のチャンクは渡せません。

対策：

• K件を絞る（上位3〜5件）
• 要約を先に作ってから渡す
• 長コンテキストのLLMを使う（渡せる量はモデルごとに違い、いまは100万トークン級のものもある。使うモデルの上限は公式ドキュメントで確かめる）

課題4: 評価の難しさ

RAGの回答品質を客観的に測るのは難しい。正解データをどう作るかが課題。

対策：

• RAGAS（RAG評価用OSSフレームワーク）を使う
• 回答の正確性、回答の関連性、検索の忠実性等の指標を自動計算
• LLM-as-a-Judge（別のLLMに採点させる）

課題5: 多言語・マルチモーダル

日本語と英語が混在するドキュメント、画像入りPDF、表やグラフなどの処理が難しい。

対策：

• 多言語対応の埋め込みモデル（BGE-M3、Cohere Multilingual）
• 画像・表はLLMで事前にテキスト化（OCR + VLM）
• マルチモーダル埋め込み（CLIP、Nomic等）

11. 主要ツール・サービス一覧

RAG構築に使える主要ツールをカテゴリ別にまとめます。

フレームワーク・ライブラリ

• LangChain——検索・モデル・データソースの統合
• LlamaIndex——データ接続特化
• Haystack——エンタープライズ向け
• DSPy——プロンプト自動最適化

ベクトルDB（マネージド）

• Pinecone——マネージドのベクトル検索
• Weaviate Cloud——GraphQL対応
• Qdrant Cloud——Qdrantのマネージドサービス
• Zilliz Cloud——Milvusのマネージド版

ベクトルDB（OSS・セルフホスト）

• Chroma——Pythonから利用できるベクトル検索
• Qdrant——ベクトル検索とフィルター
• Weaviate——OSS版
• Milvus——ベクトルデータベース
• pgvector——PostgreSQL拡張

埋め込みモデル

• OpenAI text-embedding-3——APIで埋め込みを生成
• Voyage AI——Anthropicのドキュメントが紹介
• Cohere Embed——多言語対応
• BGE-M3——多言語対応のローカル実行候補

ノーコード・マネージドRAGサービス

• ChatGPT Projects / 既存のCustom GPTs——追加資料を参照する既製機能、処理や利用条件は機能ごとに確認
• Claude Projects——AnthropicのRAG機能
• Notion AI——Notion内のドキュメント検索
• Microsoft Copilot (Microsoft 365)——社内資料の参照機能を検討する候補、契約・接続・権限の条件を確認
• Dify——OSSのノーコードAI構築プラットフォーム
• Vertex AI Agent Builder——Google CloudのRAG構築サービス
• Amazon Bedrock Knowledge Bases——AWSのマネージドRAG

評価ツール

• RAGAS——OSSのRAG評価フレームワーク
• TruLens——LLMアプリ評価全般
• LangSmith——LangChain公式のトレース・評価

ファインチューニングをもっと詳しく知りたい人は、ファインチューニング入門もあわせてどうぞ。RAGとの使い分けや手法（LoRA/QLoRA）を初心者向けに解説している。

FAQ

2026年10月9日に、料金・製品の提供条件・APIのデータ処理などの記述を公式資料で見直しました。コードやAPIの実行、請求額、実環境の機密保護は検証していません。実装時は各サービスの最新条件を確認してください。