RAGとは？仕組みをわかりやすく解説｜FTとの違い・始め方まで

【PR】本記事はプロモーションを含みます。

「社内ルールについて聞いても、一般論しか返ってこなくて使えない」

「もっともらしい嘘（ハルシネーション）が怖くて、業務に使えない」

そんな悩みを解決する技術がRAGです。RAG（検索拡張生成）とは、回答を作る前に社内文書などの外部情報から関連箇所を検索し、その情報を参照しながら回答を作る技術であり、LLMを「記憶だけで答える存在」から「調べてから答える存在」に変える仕組みです。

本記事では、RAGの仕組みを事前準備と回答時の2段フローで整理し、ファインチューニング（FT）との違いや精度を決める勘所まで解説します。結論は、知識の更新ならRAG、振る舞いの調整ならFTです。

要点（この記事の結論）

• RAGは「カンペを見て答えるAI」です。検索品質が回答品質を大きく左右します
• 知識の更新ならRAG、文体や振る舞いの調整ならファインチューニングが向きます。併用も可能です
• ハルシネーションは減らせますが、ゼロにはなりません。人手確認と評価が必要です
• データ整備が成否を分けます。チャンク設計とハイブリッド検索＋リランキングが精度の鍵です
• まず小さな社内FAQでのPoCから試すのが近道です（規模の目安に一次出典はありません）。実装は最小構成から始めてください

RAGとは？一言でいうと「カンペを見て答えるAI」

一文定義と略語展開（Retrieval-Augmented Generation）

RAGの正式名称はRetrieval-Augmented Generation（検索拡張生成）です。原論文はLewis et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”（NeurIPS 2020、arXiv初版2020-05-22、arXiv:2005.11401）で、Meta Researchの公式ページでも紹介されています（2026年9月8日時点）。

原論文の構成を一言でいうと、パラメトリックメモリ（BARTというseq2seqモデル）と、ノンパラメトリックメモリ（Wikipediaのdense vector index＋DPRレトリーバー）を組み合わせたものです。実験設定ではWikipediaの2018年12月ダンプを100語ずつ分割して約21Mドキュメントとし、FAISS＋HNSWで検索、学習時のtop-kは5または10でした。

たとえ話をすると、持ち込み不可の試験と持ち込み可の試験の違いです。LLM単体は暗記だけで答える受験生、RAGはカンペ（社内文書）の該当ページを探してから答える受験生です。

LLM単体（ChatGPT）との違い比較表

観点	LLM単体	RAG
答え方	学習時の記憶だけで答える	関連文書を検索して参照しながら答える
社内情報	学習していないため答えられない	社内文書を取り込めば答えられる
最新情報	学習カットオフ以降は知らない	インデックス差し替えで更新できる
根拠提示	出典を示しにくい	参照した文書を示せる

ChatGPTのようなLLMの使いこなしやなり方を体系的に知りたい方は、LLMエンジニアとは？仕事内容・必要スキル・学習ロードマップもあわせてご覧ください。

なぜRAGが必要なのか（LLMの3つの弱点）

弱点1〜3とRAGの対応表

原論文の問題意識は、パラメトリックなLLMだけでは知識へのアクセスや正確な操作が限定的で、知識集約型タスクで性能が劣ることでした。根拠提示（provenance）と知識更新が未解決問題とされています。なお「鮮度・社内情報・ハルシネーション」の3点整理は本記事側の整理であり、原論文の直接の列挙ではありません。

LLMの弱点	具体例	RAGの対応
鮮度カットオフがある	昨日の社内通達に答えられない	検索インデックスの差し替え（hot-swap）で再学習なしに更新できる
社内情報を知らない	就業規則を聞いても一般論になる	社内文書を取り込んで参照できる
ハルシネーションを起こす	もっともらしい嘘をつく	参照文書に基づくため、よりfactual・specific・diverseな生成が期待できる

「最新対応ができる」「よりfactualになる」という点は、いずれも原論文の主張と人間評価に基づきます（2026年9月8日時点）。

「RAGを入れれば賢くなるは半分正しい」の注意書き

RAGは万能ではありません。原論文も「よりfactual」と定性的に評価するに留まり、「賢くなる」「嘘が消える」とは断定していません。

象徴的な例として、OpenAIの最適化ガイドではファインチューニング済みモデルにRAGを足したら精度が4pt低下した事例（GPT-4 FTで83%）が紹介されています。組み合わせれば必ず良くなるわけではなく、適材適所で選ぶ必要があります（2026年9月8日時点）。

RAGの仕組み（事前準備＋回答時の2段フロー）

RAGの定義はシンプルです。Microsoft Researchのブログでは「ユーザーのクエリに基づき情報を検索し、参照として回答を生成する技術」と説明されています。LangChain公式でもRetrieve（関連splitを取得）→Generate（質問＋取得データをプロンプトに入れて回答）の流れで定義されています（いずれも2026年9月8日時点）。

具体例で追いましょう。「有給休暇は何日前までに申請するの？」と聞かれた場合を考えます。

事前準備（収集→チャンク化→ベクトル化→DB保存）

回答する前の準備が前半です。LangChain公式の標準手順はLoad→Split→Embed→Storeです。

• 収集（Load）：休暇申請手順書や就業規則などの社内文書を集めます
• チャンク化（Split）：文書を検索しやすい単位に分割します。LangChainの出発点はRecursiveCharacterTextSplitterで、既定の区切りは[“\n\n”,”\n”,” “,””]です
• ベクトル化（Embed）：各チャンクを意味を表す数値ベクトル（埋め込み）に変換します
• DB保存（Store）：チャンクとベクトルの対応をベクトルDBに保存します

OpenAIの埋め込みモデルの最大入力は全モデルで8192トークン、単一リクエストの合計上限は300,000トークンです（2026年9月8日時点）。これがチャンク設計の上限の目安になります。

回答時（検索Retrieval→拡張Augmented→生成Generation）

質問が来てからの後半がRAGの本番です。

1. 検索（Retrieval）：質問文もベクトル化し、ベクトルDBから意味が近いチャンクを探します。たとえば「有給休暇の申請期限」の章がヒットします
2. 拡張（Augmented）：質問文＋ヒットした文書をプロンプトにまとめます。「以下の社内文書を参照して答えてください」という形です
3. 生成（Generation）：LLMが参照文書に基づいて回答を作ります。「3営業日前までに申請が必要です」といった形です

用語5点の一言説明

用語	一言説明
チャンク分割	文書を検索・参照しやすい単位に切ることです
埋め込み（Embedding）	文章の意味を数値ベクトルに変換することです。意味が近い文はベクトルも近くなります
ベクトルDB	チャンクとベクトルの対応を保存し、類似検索するDBです
ベクトル検索	意味の近さで探す検索です。キーワード一致がなくてもヒットします
プロンプト拡張	質問文に検索結果を付け足してLLMに渡すことです

ファインチューニングとの違い・使い分け

比較表1枚

OpenAIの最適化ガイドでは、RAGは「プロンプト生成前にドメイン固有文脈へのアクセスを与える」用途、ファインチューニングは「学習済み記憶の問題（振る舞い・一貫性）」用途と整理されています（2026年9月8日時点）。

観点	RAG	ファインチューニング（FT）
得意なこと	知識の更新・社内情報の参照	文体・トーン・形式・振る舞いの固定
新知識の追加	向く。インデックス差し替えで対応	向かない。OpenAIは代わりにRAGを検討と案内
更新コスト	文書追加のみで比較的軽い	再学習が必要
向く例	社内FAQ、最新マニュアル対応	接客口調の統一、出力形式の固定、コスト・レイテンシ最適化
併用	可能。RAGで文脈注入＋FTで振る舞い固定が一般的	同左

SFT（教師ありファインチューニング）は新しい知識の追加には不向きで、構造や形式のカスタマイズに向きます。開始の目安は50件以上の良質な例からとされています。また最小10件、改善が見えるのは50〜100件からとの記載もあり、いずれも目安として捉えてください（2026年9月8日時点）。

判断軸の一文

判断軸はシンプルです。まずRAGから試し、足りない振る舞いの部分を調整で補います。両者は積み重ね（stack）が可能です。

RAGのメリット・デメリット（万能ではない）

メリット

• 精度向上が期待できる：原論文ではオープンドメインQAの3タスクでSOTAを報告しています
• 改善幅の定量例がある：AnthropicのContextual Retrievalでは検索失敗率を49%削減、リランキング併用で67%削減（top-20失敗率5.7%→2.9%→1.9%）と報告されています。ただしAnthropicの自社データセットでの評価という条件付きです（2026年9月8日時点）
• 最新情報に対応できる：インデックス差し替えで再学習なしに更新できます
• 社内知識を使える：学習データにない非公開情報を参照できます
• 根拠提示ができる：参照文書を示せるため、確認作業がしやすくなります
• 更新が容易：文書を追加・差し替えれば反映できます

デメリット

• 検索品質に依存する：的外れな文書しか取れなければ回答も外れます
• 構築運用コストがかかる：検索とLLM振る舞いの両方を見る必要があります
• レイテンシが増える：検索ステップが加わる分、回答が遅くなります
• ハルシネーションはゼロにならない：OpenAIもFact-checkステップや評価が必要と指摘しています（2026年9月8日時点）

デメリットの誠実な開示が信頼につながります。社内導入の企画側の視点や費用対効果の考え方は、ローカルLLMのビジネス活用も参考になります。

精度を決める設計の勘所

RAGは「検索品質＝回答品質」ではなく、検索品質が回答品質を大きく左右する技術です。ここが本記事の差別化ポイントです。

チャンク設計の要点

チャンクの具体的推奨レンジに断定的な一次推奨値はありません。目安として使える一次的記述から先に示します。Anthropicは「通常は数百トークン以下」のチャンクに分割し、コンテキスト付与は通常50〜100トークンをprependすると述べています（2026年9月8日時点）。LangChain公式も「まずRecursiveCharacterTextSplitterから、必要に応じ調整」と述べるのみです。いずれも目安であり、文書の種類によって調整が必要です。

サイズ	起きやすい弊害
大きすぎる	関係ない情報が混ざり、検索精度と生成精度が落ちます。リランキングモデルの上限（例：512トークン、Pinecone公式、2026年9月8日時点）を超える場合もあります
小さすぎる	文脈が切れて意味がわからなくなります。検索ヒットが断片化します

日本語の文字数換算や日本語埋め込みモデルのベンチマーク数値の一次出典は未確認のため、本記事では定量比較しません。句読点や見出し単位で切るなど、文書構造を生かすことが目安として有効です。

ハイブリッド検索＋リランキングが定番の理由

ベクトル検索（意味の近さ）とキーワード検索（文字一致）には一長一短があります。Pinecone公式は両者を組み合わせるハイブリッド検索を解説しています。重み付け（alpha）や正規化が必要になる点にも注意が必要です（2026年9月8日時点）。

方式	強み	弱み
ベクトル検索	言い換え・同義語に強い	型番・固有名詞・略語に弱いことがある
キーワード検索（BM25等）	型番・固有名詞の完全一致に強い	言い換えに弱い
ハイブリッド検索	両者を補完できる	スコア融合の調整が必要

融合手法の代表例がRRF（Reciprocal Rank Fusion）です。スコアではなく順位を融合（1/(k+rank)、k=60が原論文値）するため、正規化不要の頑健な既定策とされています（Pinecone公式解説、2026年9月8日時点）。

さらにリランキング（rerank）は「2段階検索で最も手軽な品質改善策」とされています。代表例としてbge-reranker-v2-m3やcohere-rerank等があり、上限512トークンのものがあります（Pinecone公式、2026年9月8日時点）。流れとしては、広く候補を集めてから並べ替える2段階が定番です。

埋め込みモデルの仕様例として、OpenAI text-embedding-3-smallは1536次元、text-embedding-3-largeは3072次元（dimensions短縮可）、text-embedding-ada-002は1536次元です。Cohere embed-multilingual-v3.0は1024次元・512トークン、embed-v4.0は256/512/1024/1536の可変次元・128kトークン・100言語超（日本語含む）です。BGE-M3（BAAI/bge-m3）は1024次元・8192トークン・100言語超・MITライセンスです（いずれも2026年9月8日時点）。日本語対応の定量比較は未確認のため割愛します。モデルの入手先としてHugging Faceとは？使い方・主要モデル・料金まで解説もご覧ください。

失敗の切分けデバッグ手順

OpenAIの最適化ガイドの問題分解では、検索軸（正しい文脈を渡したか）とLLM軸（渡した文脈で正しく答えたか）に切り分けて評価します（2026年9月8日時点）。

1. 検索結果を確認する：正しいチャンクが上位に来ているかを見ます。来ていなければチャンク設計やハイブリッド検索を見直します
2. 生成を確認する：正しい文脈を渡しているのに間違える場合は、プロンプトやモデルの指示追従を見直します
3. 直す優先順位：まず検索側から直します。検索が外れているのに生成をいじっても改善しません

評価指標の例として、AnthropicはPass@k（正解チャンクが上位kに入ったか）を使っています（Anthropic公式、2026年9月8日時点）。評価セットを用意して継続的に測ることが大切です。

構造化データの活用と対比したい場合は、Text-to-SQLとは？仕組み・精度・ユースケースを解説も参考になります。

データ基盤視点の取込〜更新パイプライン

データエンジニアの強みが出るのがこの領域です。「文書を集める」で止まらず、運用まで設計します。なお本節の実装パターンは一般論の整理であり、一次出典未確認の内容を含みます。

差分更新・メタデータ付与・鮮度管理

文書が更新されたら全文作り直しではなく、変わったチャンクだけ追加・更新・削除するのが目安として効率的です。

メタデータ（文書ID、更新日、部署、公開範囲など）を付与しておくと、後述のフィルタや鮮度管理に使えます。古い文書が混ざると誤回答の原因になるため、更新日での絞り込みやアーカイブの仕組みを検討します。

取込時変換の例として、AWS公式ブログではBedrock Knowledge Basesのカスタムチャンキング（Lambda）による変換が紹介されています。ただしAnthropic手法の応用例であり、一般的な差分更新の一次出典ではない点にご注意ください（2026年9月8日時点）。

権限連動・品質テストの考え方

• 権限連動：誰が見られる文書かをメタデータで管理し、検索時にフィルタします
• 品質テスト：評価用の質問と正解文書のセットを用意し、Pass@kなどで定期測定します

ベクトルDBの代表例としてはPineconeやQdrant等があります。Pineconeにはメタデータフィルタや名前空間の機構があり、料金ページではStarter無料〜Builder月$20定額〜Standard月$50最小〜Enterprise月$500最小と案内されています。Qdrant CloudはvCPU・RAM・ディスク等の時間課金で、無料枠は0.5vCPU/1GB RAM/4GB Diskの単一ノードです。いずれも変動が激しいため2026年9月8日時点の情報としてご確認ください。代表例の列挙に留め、詳細単価の比較はしません。

権限・PII・監査の実装パターン

実装パターンを3点紹介します。

• メタデータフィルタ：部署や役職などの属性で検索対象を絞ります
• 参照のみ埋め込み：原文全文ではなく参照用に加工した情報を埋め込む方法です
• 回答来歴：いつ・どの文書版を参照して答えたかを記録し、監査に備えます

ローカルで動かす選択肢を知りたい方は、Ollamaとは？ローカルLLMの使い方・モデル・料金まで解説もご覧ください。

始め方3段階と2026年の派生型

3段階（Custom GPT→Dify等のノーコード→LangChain／LlamaIndex）

いきなり本格構築せず、段階を踏むのが近道です。なおCustom GPTやDify等の具体的な手順・料金の一次出典は未確認のため、製品名の列挙と公式リンクでの確認に留めます。

段階	向く人	制御範囲の目安
Custom GPT等のカスタム機能	プログラミングなしで試したい方	限定的（設定の範囲内）
Dify等のノーコード	画面操作でパイプラインを作りたい方	中程度（部品の組み合わせ）
LangChain／LlamaIndex等のフレームワーク	Pythonで作り込みたい方	高い（コードで全面制御）

PoCから本番までの費用相場の総額は未確認のため、本記事では断定しません。埋め込み料金の例として、OpenAI text-embedding-3-smallは$0.02/1Mトークン、text-embedding-3-largeは$0.13/1Mトークン、Batch利用で半額と案内されています（2026年9月8日時点）。総額は文書量や検索基盤で変わるため、公式の最新料金をご確認ください。

最小RAGコードはLLMエンジニア記事へ

本記事は仕組み解説に集中するため、最小RAGコードは掲載しません。手を動かしたい方は、最小RAGのPython実装コード付きのLLMエンジニアとは？仕事内容・必要スキル・学習ロードマップで実際に動かしてみてください。仕組みを理解してからコードを読むと、Load→Split→Embed→Storeの意味がすっと頭に入ります。

2026年派生型の一行整理とロングコンテキストとの補完関係

2026年の派生型は3つ押さえれば十分です。

派生型	一行整理
Agentic RAG	エージェント（LLM）が推論中にいつ・どう検索するかを自律判断する方式です。LangChain公式が2-Step RAG（高速・制御高）と対比しています（2026年9月8日時点）
GraphRAG	LLMが生成したナレッジグラフ＋コミュニティ検出・要約を用いる構造化RAGです。Microsoft Researchが2024年2月13日のブログで公開し、OSSは2024年7月2日公開です。リポジトリに保守モードの注意書きがあるため研究プロジェクトとして捉えてください（2026年9月8日時点）
CAG	Cache-Augmented Generationの略で、検索を介さず全関連文書を事前ロードしKV-cacheを事前計算する検索フリー手法です。管理可能な知識規模向けで、論文はChan et al. arXiv:2412.15605（2024年12月20日、WWW Companion 2025採録）です。実装はGitHubで公開されています（2026年9月8日時点）

CAGの制約として、全知識がコンテキスト窓に収まる必要があり、超長文で劣化の可能性があると論文等で明記されています。特定製品の最新の窓サイズは本記事では断定しません。結論として、ロングコンテキストとRAGは代替ではなく補完関係です。文書量・コスト・速度に応じて使い分けます。使い分けの目安として、静的FAQはCAG、汎用はStandard RAG、複雑な推論はAgentic、関係性探索はGraphが向きます。

よくある質問（FAQ 7問）

Q1. RAGとファインチューニングはどちらを選ぶべき？

ドメイン知識の注入ならRAG、振る舞いや形式の固定ならファインチューニングが向きます。OpenAIの整理でも同じ区分です。まずRAGから試し、不足分を調整で補うのが判断軸です。併用も可能です（2026年9月8日時点）。

Q2. RAGを使えばハルシネーションは完全になくなる？

いいえ、完全にはなくなりません。減らすことはできますが、検索漏れ・古い資料の混入・生成時の読み違いなどで残ります。OpenAIもFact-checkステップや評価が必要と指摘しています。人手確認を組み込んでください（2026年9月8日時点）。

Q3. チャンク・埋め込み・ベクトルDBとは？

チャンク分割は文書を検索しやすい単位に切ること、埋め込みは文章の意味を数値ベクトルに変えること、ベクトルDBはそれらを保存して類似検索するDBです。意味検索のために必要な3点セットです。チャンクの具体的推奨レンジに断定的な一次推奨値はなく、Anthropicの「数百トークン以下」等の目安を文書に応じて調整してください（2026年9月8日時点）。

Q4. ベクトル検索とキーワード検索の違いは？ハイブリッド検索とは？

ベクトル検索は意味の近さで探し、キーワード検索は文字一致で探します。前者は言い換えに強く型番に弱く、後者は逆の傾向があります。両者を組み合わせるのがハイブリッド検索で、リランキングと組み合わせるのが定番です（2026年9月8日時点）。

Q5. 構築にプログラミングは必要？どう始める？

必須ではありません。Custom GPT等の手軽な方法、Dify等のノーコード、LangChain／LlamaIndex等のフレームワークの3段階があります。具体的な製品手順・料金の一次出典は未確認のため、公式ドキュメントをご確認ください。最小実装の骨子はLoad→Split→Embed→Storeで、コードで試すならLLMエンジニアの記事が近道です。

Q6. 精度が低い・的外れな回答になる原因は？

よくある原因は、チャンク不適切、ベクトル検索のみで固有名詞に弱い、古い文書混在、評価なしの4点です。対策はチャンク見直し、ハイブリッド検索＋リランキング、メタデータでの鮮度管理、評価セットの用意です。まず検索結果が正しいかを確認し、検索側から直します。

Q7. ロングコンテキストがあればRAGは不要？

不要にはなりません。補完関係です。全知識が窓に収まらない場合やコスト・速度を考えるとRAGが有効です。CAGのように全量を事前ロードする手法も管理可能な規模向けであり、超長文での劣化も指摘されています。使い分けの目安は本文の派生型の節を参照してください。

Q8. RAGのコストはどれくらい？

埋め込み料金の例として、OpenAI text-embedding-3-smallは$0.02/1Mトークン、text-embedding-3-largeは$0.13/1Mトークンです（2026年9月8日時点）。PoCから本番までの総額は文書量や検索基盤で変わるため、本記事では断定しません。公式の最新料金をご確認ください。

Q9. 日本語の社内文書でも精度は出ますか？

日本語対応の埋め込みモデル選定が鍵です。Cohere embed-v4.0（100言語超・日本語含む）やBGE-M3（100言語超・MITライセンス）等の多言語対応モデルがあります（2026年9月8日時点）。句読点や見出し単位で切るなど、文書構造を生かす分割も有効です。日本語での定量比較の一次出典は未確認のため、評価セットで自社文書での精度を測ってください。

まとめ

関連記事

• LLMエンジニアとは？仕事内容・必要スキル・学習ロードマップ：最小RAGのPython実装コード付き。仕組みを理解した後の実装にどうぞ
• ローカルLLMのビジネス活用：社内導入・企画側の視点を知りたい方に
• Text-to-SQLとは？仕組み・精度・ユースケースを解説：構造化データ活用との対比に
• Ollamaとは？ローカルLLMの使い方・モデル・料金まで解説：ローカル実行の選択肢を知りたい方に
• Hugging Faceとは？使い方・主要モデル・料金まで解説：埋め込みモデル探しに
• Difyとは？できること・使い方・料金・商用利用：ノーコードでRAGアプリを試したい方に

参考文献

• Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020： https://arxiv.org/abs/2005.11401
• Meta Research 公式出版物ページ： https://ai.meta.com/research/publications/retrieval-augmented-generation-for-knowledge-intensive-nlp-tasks/
• Microsoft Research GraphRAGブログ： https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
• LangChain RAG定義・手順： https://docs.langchain.com/oss/python/deepagents/rag
• LangChain RecursiveCharacterTextSplitter： https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter
• LangChain Splitters概要： https://docs.langchain.com/oss/python/integrations/splitters
• LangChain Retrieval（Agentic RAG対比）： https://docs.langchain.com/oss/python/langchain/retrieval
• Anthropic Contextual Retrieval： https://www.anthropic.com/engineering/contextual-retrieval
• OpenAI Optimizing LLM Accuracy： https://developers.openai.com/api/docs/guides/optimizing-llm-accuracy
• OpenAI Embeddings Guide： https://developers.openai.com/api/docs/guides/embeddings
• OpenAI Supervised Fine-Tuning： https://developers.openai.com/api/docs/guides/supervised-fine-tuning
• OpenAI text-embedding-3-small： https://developers.openai.com/api/docs/models/text-embedding-3-small
• Pinecone Hybrid Search： https://docs.pinecone.io/guides/search/hybrid-search
• Pinecone Reciprocal Rank Fusion： https://docs.pinecone.io/guides/search/reciprocal-rank-fusion
• Pinecone Rerank Results： https://docs.pinecone.io/guides/search/rerank-results
• Pinecone Pricing： https://www.pinecone.io/pricing/
• Qdrant Pricing： https://qdrant.tech/pricing/
• Cohere Embed Docs： https://docs.cohere.com/docs/cohere-embed
• BAAI bge-m3（Hugging Face）： https://huggingface.co/BAAI/bge-m3
• AWS Contextual Retrieval on Bedrock： https://aws.amazon.com/blogs/machine-learning/contextual-retrieval-in-anthropic-using-amazon-bedrock-knowledge-bases/
• Microsoft GraphRAG GitHub： https://github.com/microsoft/graphrag
• Chan et al. CAG arXiv:2412.15605： https://arxiv.org/abs/2412.15605
• CAG GitHub（実装）： https://github.com/hhhuang/CAG