RAG vs ファインチューニング — どちらをいつ選ぶか

TL;DR

• 「LLM に独自知識を持たせたい」と感じたとき、最初に検討すべきは ほぼ常に RAG です。コスト・更新性・出典追跡の観点で導入コストが圧倒的に低いです。
• ファインチューニングは 「文体・形式・口調を強く制御したい」「タスク自体を最適化したい」 場面で効きます。「知識を覚えさせる」目的でのファインチューニングは効率が悪く、しばしば不正確になります。
• 実務では 両者を排他的に選ぶのではなく、ハイブリッド にするのが普通で、「RAG で知識を供給し、ファインチューニングでフォーマットを固定する」が王道パターンです。
• 7 つの判断軸（更新頻度 / 知識量 / 出典必要性 / 推論コスト / 学習コスト / 形式制御 / プライバシー）で比較すると、RAG が有利な軸が多数派です。

背景: なぜこの問いが頻出するのか

LLM をプロダクトに組み込もうとすると、ほぼ必ず 「自社固有の知識を答えさせたい」 という要件に行き当たります。社内ドキュメント、製品マニュアル、過去の問い合わせログなど、汎用 LLM が学習していない情報を扱う必要があります。

このとき技術選定で頻繁に並ぶのが、

• RAG (Retrieval-Augmented Generation): 質問が来た瞬間に外部ドキュメントを検索し、関連箇所をプロンプトに差し込んでから LLM に回答させる方式
• ファインチューニング (Fine-tuning): 独自データで LLM の重み自体を追加学習し、知識や挙動を内在化させる方式

の 2 択です。「どっちがいいですか」という問いは月に何度も聞かれますが、問いの立て方自体が雑 で、実際は「どの軸で何を優先したいか」次第です。本稿では判断軸を分解して整理します。

RAG とは（30 秒で）

質問 → ベクトル検索 → 関連チャンク取得 → プロンプトに差し込み → LLM が回答、という流れです。

[ユーザー質問]
   ↓
[Embedding] → [Vector DB 検索]
   ↓
[関連チャンク Top-K]
   ↓
[プロンプト組み立て: 質問 + 検索結果]
   ↓
[LLM 推論]
   ↓
[回答 + 出典]

知識は LLM の外部 に置かれます。ドキュメント更新は DB を入れ替えるだけで済み、出典の URL もそのまま回答に付けられます。

ファインチューニングとは（30 秒で）

独自データセット（質問-回答ペアや、特定形式の文章）で LLM の重みを追加学習します。代表的な手法は LoRA / QLoRA に代表される効率的ファインチューニングで、フルパラメータ更新は実務では稀です。

[ベースモデル] + [独自データセット] → [追加学習] → [カスタムモデル]

知識は モデルの重みの中 に取り込まれます。推論時は追加データの差し込み不要で、応答が高速になり得ます。一方、知識を更新するには 再学習が必要 で、出典追跡もできません。

7 軸での比較

判断軸	RAG	ファインチューニング	推奨
知識の更新頻度	◎（DB 入れ替えで即反映）	×（再学習が必要）	RAG
扱える知識量	○（数百万チャンク以上 OK）	△（学習データ規模に依存）	RAG
出典の追跡可能性	◎（チャンク元 URL を返せる）	×（重みに溶けて追跡不能）	RAG
推論コスト	△（プロンプトが長くなる）	○（追加コンテキスト不要）	FT
学習・運用コスト	○（DB 構築のみ）	×（GPU 学習・評価サイクル）	RAG
形式・口調の制御	△（プロンプトで頑張る）	◎（重みに焼き込める）	FT
プライバシー（データ非公開）	○（自社 DB に留める）	○（自社モデルに留める）	引き分け

7 軸中 5 軸で RAG が有利 で、ファインチューニングが明確に勝つのは「推論コスト」と「形式制御」の 2 軸のみ、というのが実態です。

判断フロー（推奨）

独自知識を LLM に持たせたい
   ↓
出典を回答に付ける必要があるか？
   ├─ Yes → RAG ほぼ確定
   └─ No → 知識更新頻度は？
        ├─ 月 1 回以上 → RAG
        └─ ほぼ更新なし → 形式・口調を強く制御したいか？
             ├─ Yes → ファインチューニング検討
             └─ No → RAG（無難）

迷ったら RAG、というのが基本姿勢です。理由は後述します。

ハイブリッド戦略

実務では「RAG か FT か」の二択ではなく 両者を組み合わせる のが王道です。代表パターンは次の 2 つです。

パターン A: RAG（知識） + FT（形式）

社内 QA bot を作る場合の典型例です。

• 知識（製品仕様・FAQ・過去問い合わせ）→ RAG で外部 DB に置き、更新性と出典を確保
• 回答フォーマット（敬語の段階・定型挨拶・回答テンプレ）→ ファインチューニング で重みに固定

知識更新時に再学習が不要で、かつ毎回プロンプトに「敬語で答えろ」と書く必要もありません。

パターン B: 検索クエリ生成のための小さな FT + RAG

ユーザーの自然文質問を 検索に最適なクエリに書き換える 部分だけ小型モデルでファインチューニングし、後段は通常の RAG で回す構成です。検索精度（特に Recall）が劇的に上がります。

私の考察

「ファインチューニングで知識を覚えさせたい」という相談を受けることが多いのですが、ほぼ全ケースで RAG を勧めて います。理由は次の 3 点です。

第一に、ファインチューニングは知識の追加学習に向いていません。LLM はファインチューニングで「事実」を覚えるよりも、「答え方の癖」を覚える方が圧倒的に得意です。事実を覚えさせようとすると、しばしば 学習元になかった事実を自信満々に捏造する（ハルシネーションの強化）という最悪の挙動を見せます。これは複数の実証研究でも報告されています（要検証、参考: Anyscale ブログ）。

第二に、運用コストの非対称性 です。RAG は最悪でも「検索結果が悪かった」で済みますが、FT は モデル全体の挙動が変わる ので、回帰テストの範囲が広く、リリースが重くなります。MVP フェーズで FT に踏み切るのは、ROI 的にほぼ割に合わないというのが私の現場感覚です。

第三に、LLM 自体の進化スピード です。ベースモデルが半年で世代交代する現状で、独自 FT モデルを作ると 次世代モデルへの追従コスト がそのまま運用負債になります。RAG ならベースモデルを差し替えるだけで世代追従できます。

ただし、「形式や口調を厳密に制御したい」「同じ問いに対して常に同じテンプレで答えさせたい」というユースケースでは FT が効きます。コールセンター応答、医療文書フォーマットなど、形式逸脱が許されない領域 では FT の出番です。

最後に強調しておきたいのは、この比較は永久に同じ結論ではない という点です。もしファインチューニング技術が大きく進化し、知識追加の精度が劇的に上がれば判断は変わり得ます。今の時点（2026 年 5 月）の私の判断は「迷ったら RAG」ですが、半年後にこの記事を読み返したときに、自分の判断がアップデートされている可能性は十分ありえます。

参考リンク

• Retrieval-Augmented Generation (RAG) — 概要と実装パターン (Pinecone)
• Fine-tuning vs RAG — 選定の考え方 (Anyscale)