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

TL;DR

• 最初の選択肢は常に RAG: 「LLM に独自知識を持たせたい」と感じたら、まずは RAG（Retrieval-Augmented Generation、検索拡張生成） を検討します。コスト・更新性・出典追跡のいずれの観点でも導入コストが圧倒的に低いです。
• ファインチューニングは形式制御で効く: ファインチューニング（Fine-tuning、追加学習） は「文体・形式・口調を強く制御したい」「タスク自体を最適化したい」場面で効きます。「知識を覚えさせる」目的では効率が悪く、しばしば不正確になります。
• 実務はハイブリッドが王道: 「RAG で知識を供給し、ファインチューニングで形式を固定する」が 2026 年現在の定番パターンです。
• 7 軸比較で RAG が優位: 更新頻度 / 知識量 / 出典必要性 / 推論コスト / 学習コスト / 形式制御 / プライバシーで比較すると、RAG が有利な軸が多数派です。

要点サマリ表

観点	内容
何の話	LLM に独自知識・独自挙動を持たせる代表的 2 アプローチの選定
結論	迷ったら RAG。形式制御や応答の一貫性が必須なときのみ FT を検討
適用範囲	社内 QA bot / 製品マニュアル応答 / 専門領域チャット等の業務 LLM 活用全般
私の評価	RAG をベースに、必要に応じて軽量 FT（LoRA / QLoRA）を重ねるハイブリッドが 2026 年の現実解

背景・経緯

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

このとき技術選定で頻繁に並ぶのが RAG と ファインチューニング の 2 択です。「どっちがいいですか」という問いは月に何度も聞かれますが、問いの立て方自体が雑であり、実際は「どの軸で何を優先したいか」次第です。

特に 2026 年現在は LoRA（Low-Rank Adaptation、低ランク適応） や QLoRA（Quantized LoRA、量子化版 LoRA） といった効率的ファインチューニング手法が普及し、コンシューマ GPU でも追加学習が可能になりました。これにより「FT が現実的選択肢に入った」と感じる場面は確かに増えていますが、それでも判断軸の整理は必須です。本稿では判断軸を分解し、現実的な落とし所を示します。

本題の詳細

RAG とは（30 秒で）

質問が来た瞬間に外部ドキュメントを検索し、関連箇所をプロンプトに差し込んでから LLM に回答させる方式です。知識は LLM の外部 に置かれます。ドキュメント更新は DB を入れ替えるだけで済み、出典の URL もそのまま回答に付けられます。

flowchart TD
  A[ユーザー質問] --> B[Embedding 生成]
  B --> C[Vector DB 検索]
  C --> D[関連チャンク Top-K]
  D --> E[プロンプト組み立て<br/>質問 + 検索結果]
  E --> F[LLM 推論]
  F --> G[回答 + 出典]

ここで登場する用語を整理します。

• Embedding（埋め込み）: テキストを高次元ベクトルに変換し、意味的近さを計算可能にする表現
• Vector DB（ベクトル DB）: Embedding を効率的に検索するための専用データベース（Pinecone / Qdrant / Weaviate 等）
• Top-K: 検索結果の上位 K 件をプロンプトに組み込む設定値
• Reranker（再ランキング）: 一次検索の結果を別のモデルで並べ替え、精度を高める仕組み

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

独自データセット（質問-回答ペアや、特定形式の文章）で LLM の重みを追加学習します。代表的な手法は LoRA に代表される効率的ファインチューニングで、フルパラメータ更新は実務では稀です。QLoRA はさらに 4-bit 量子化を組み合わせ、コンシューマ GPU でも 13B クラスのモデルを学習可能にしました。

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

7 軸での比較

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

7 軸中 5 軸で RAG が有利で、ファインチューニングが明確に勝つのは「推論コスト」と「形式制御」の 2 軸のみ、というのが実態です。Red Hat の整理でも、データの動的性・チーム成熟度・予算のいずれにおいても RAG の方がアクセスしやすいと結論づけられています。

判断フロー（推奨）

実務でそのまま使える判断フローは以下です。

flowchart TD
  A[独自知識を LLM に持たせたい] --> B{出典を回答に<br/>付ける必要があるか}
  B -- Yes --> C[RAG ほぼ確定]
  B -- No --> D{知識更新頻度は}
  D -- 月 1 回以上 --> E[RAG]
  D -- ほぼ更新なし --> F{形式・口調を<br/>強く制御したいか}
  F -- Yes --> G[ファインチューニング検討]
  F -- No --> H[RAG（無難）]

迷ったら RAG、というのが基本姿勢です。理由は「私の考察」で詳しく述べます。

ハイブリッド戦略

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

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

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

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

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

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

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

比較・代替手法

該当なし（本題詳細の「7 軸での比較」表に集約済み）。

私の考察

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

第一に: FT は知識追加に向かない

LLM はファインチューニングで「事実」を覚えるよりも、「答え方の癖」を覚える方が圧倒的に得意です。事実を覚えさせようとすると、しばしば学習元になかった事実を自信満々に捏造する ハルシネーション（hallucination、幻覚） の強化が起きます。

Red Hat の整理でも、知識が動的に変わる用途には RAG を推奨しており、FT は静的なパターンに向くと明記されています。Anyscale のブログでも同様の論調です。

第二に: 運用コストの非対称性

RAG は最悪でも「検索結果が悪かった」で済みますが、FT はモデル全体の挙動が変わるため、回帰テストの範囲が広く、リリースが重くなります。

MVP フェーズで FT に踏み切るのは、ROI 的にほぼ割に合わないというのが私の現場感覚です。LoRA / QLoRA でハードルが下がったとはいえ、評価データセットの整備・回帰テスト・本番監視まで含めると総コストは依然として大きいです。

第三に: ベースモデルの世代交代スピード

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

例外: 形式制御が必須なケース

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

結語: この判断は永続ではない

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

参考リンク

• Retrieval-Augmented Generation (RAG) — 概要と実装パターン (Pinecone)
• Fine-tuning vs RAG — 選定の考え方 (Anyscale)
• RAG vs. fine-tuning (Red Hat, 2026-02-17)