社内データをLLMで活用したいとき、多くの組織が最初に直面する問いが「RAGとファインチューニングのどちらを選ぶべきか」です。大半のユースケースではRAGから始めるのが合理的で、RAGでは届かない「出力スタイル」「専門用語の理解」「分類タスク」にファインチューニングを重ねる段階的アプローチが王道です。本記事では両者の本質的な違い、メリット・デメリット、コスト構造、そしてユースケース別の選定基準を体系的に解説します。
RAGとファインチューニング、何が違うのか
RAGとファインチューニングは、LLMに社内知識を活用させるための手段という点では共通していますが、アプローチが根本的に異なります。RAGは外部の知識ソースを検索し、取得した結果をLLMのプロンプトに組み込むことで「知識を追加」する手法です。一方、ファインチューニングはLLMの重み自体を追加学習で更新し、「振る舞いや内在化された知識」を変更する手法です。
この違いは、データ更新の頻度、求められる出力スタイル、許容できる開発コストのいずれにも影響します。RAGが「必要なときに図書館から本を借りる」アプローチだとすれば、ファインチューニングは「教材で勉強して知識を頭に入れる」アプローチです。どちらが優れているかではなく、どのような要件に向いているかの問題として捉えることが重要です。
【RAG vs ファインチューニングの概念比較】
RAG(検索拡張生成)
[質問] --> [検索] --> [知識取得] --> [LLM] --> [回答]
|
v
[外部知識ベース]
(更新容易)
特徴: 知識を「外付け」する / モデルは変更しない
ファインチューニング
[質問] --> [追加学習済みLLM] --> [回答]
^
|
[学習済みデータ]
(更新は再学習必要)
特徴: 知識や振る舞いを「モデル自体」に埋め込むそれぞれのメリット・デメリット
両者の特性を多面的に比較すると、得意分野と不得意分野が明確に見えてきます。以下の比較表を出発点に、自社の要件と照らし合わせて評価してください。
| 比較軸 | RAG | ファインチューニング |
|---|---|---|
| データ更新の容易さ | 容易(インデックス再構築のみ) | 再学習が必要 |
| 初期構築コスト | 低（数日〜数週間） | 中〜高（数週間〜数ヶ月） |
| 運用コスト | API従量 + ベクトルDB維持 | 学習基盤 + 定期再学習 |
| 精度（最新情報への回答） | 高 | 学習時点で固定 |
| 精度（出力スタイル） | プロンプトで調整 | 高（内在化） |
| ハルシネーション対策 | 検索結果を根拠に抑制 | 効果は限定的 |
| 必要な専門スキル | アプリケーション開発中心 | ML専門知識が必要 |
| スケーラビリティ | 高（検索を水平拡張可） | モデルごとに再学習 |
| 透明性・説明可能性 | 高（出典提示が可能） | 低（内部化される） |
RAGの最大の強みはデータ更新の容易さと透明性です。新しい文書を追加するだけでナレッジが広がり、回答の根拠を提示できるため監査にも強い構成となります。一方ファインチューニングは、RAGでは表現しきれない「特定の語り口」「高度な分類タスク」「長期的な振る舞い変更」で力を発揮します。
ユースケース別の判断基準
どちらを選ぶべきかは、突き詰めればユースケースで決まります。以下の推奨一覧とフローチャートを参考に、自社の要件を整理してみてください。
| ユースケース | RAG | FT | 両方 | 理由 |
|---|---|---|---|---|
| 社内FAQ・ナレッジ検索 | ◎ | △ | ○ | 頻繁な更新と出典表示が必要 |
| 契約書・規程のQA | ◎ | × | ○ | 根拠提示が必須 |
| 最新ニュース回答 | ◎ | × | △ | 知識カットオフ問題 |
| 特定文体のコピー生成 | △ | ◎ | ○ | 文体はモデルに内在化 |
| 社内用語の分類タスク | △ | ◎ | ○ | 少数ショットより学習が有利 |
| 医療・法律領域QA | ○ | ○ | ◎ | 専門語彙 + 最新情報の両立 |
| チャットボット（定型対応） | ◎ | △ | ○ | 業務手順をRAGで参照 |
| コーディング支援 | ○ | ◎ | ◎ | 社内ライブラリの習得 |
【RAG / ファインチューニング 選定の判断ツリー】
Q1. 参照するデータは頻繁に更新される？
├── Yes → RAGを選択
│ └── Q2. 出力スタイルに強い要件がある？
│ ├── Yes → RAG + ファインチューニング併用
│ └── No → RAG単体で十分
│
└── No → Q3. 特定の文体・分類タスクが必要？
├── Yes → ファインチューニングを検討
│ └── Q4. 知識も同時に与えたい？
│ ├── Yes → RAG + FT 併用
│ └── No → ファインチューニング単体
│
└── No → Q5. 根拠提示が重要？
├── Yes → RAG
└── No → プロンプト設計で十分な場合も判断の指針としては、「答えの根拠が必要か」「データが頻繁に更新されるか」の2問に答えるだけで、多くのケースはRAG優勢という結論に辿り着きます。ファインチューニングを検討するのは、RAGで実現しきれない要件が明確になった段階で十分です。
コスト比較
コスト構造は初期構築、運用、更新の3フェーズに分けて考えます。RAGは初期構築が軽く、運用はAPI従量とベクトルDBの維持費が中心です。ファインチューニングは初期の学習コストと、データセット作成・品質管理の人件費が大きな比重を占めます。
例えば、1万文書のPoCクラスRAGは、OpenAI APIとChromaを使えば初期構築コストは数万円〜十数万円程度、月額運用費もAPI呼び出し量次第で数万円に収まることが多い水準です。同等規模のファインチューニング（LoRA/QLoRA）はデータセット整備を含めて数十万〜数百万円規模となり、再学習コストも定期的に発生します。
# RAG構築の最小コスト試算スクリプト
doc_count = 10000
avg_tokens_per_doc = 500
embed_cost_per_1m = 20 # 円(text-embedding-3-small)
query_per_day = 500
tokens_per_query = 2000
gen_cost_per_1m_in = 300 # 円(gpt-4o-mini想定)
embed_cost = (doc_count * avg_tokens_per_doc / 1_000_000) * embed_cost_per_1m
monthly_gen = (query_per_day * 30 * tokens_per_query / 1_000_000) * gen_cost_per_1m_in
print(f"初期エンベディングコスト: {embed_cost:.0f}円")
print(f"月額生成コスト: {monthly_gen:.0f}円")組み合わせアプローチ（RAG + ファインチューニング）
両者は競合ではなく補完関係として捉えるのが実務的です。ファインチューニングで「モデルに専門領域の感覚」を与え、RAGで「最新で正確な事実」を供給する組み合わせは、特に専門性の高い領域で強力に機能します。例えば医療領域では、医学用語の理解をファインチューニングで、最新のガイドラインや社内マニュアルをRAGで供給する構成が典型です。
組み合わせの注意点は、ファインチューニング済みモデルもRAGから渡されたコンテキストを正しく参照できることを必ず確認することです。「学習した知識」と「検索で渡された情報」が矛盾した場合の振る舞いを、事前に評価しておきましょう。
# ファインチューニング済みモデルでRAGを構築する設定例
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
# ファインチューニング済みのカスタムモデルを利用
llm = ChatOpenAI(
model="ft:gpt-4o-mini:your-org:medical-tone:xxxxxxxx",
temperature=0
)
vectordb = Chroma(
persist_directory="./medical_docs",
embedding_function=OpenAIEmbeddings()
)
qa = RetrievalQA.from_chain_type(
llm=llm,
retriever=vectordb.as_retriever(search_kwargs={"k": 5}),
return_source_documents=True
)まとめ――「まずRAG、次にファインチューニング」が基本戦略
- RAGは知識の追加、ファインチューニングは振る舞いの変更に向く
- 初期構築・データ更新の容易さで、ほとんどのケースはRAG優勢
- 出力スタイルや分類タスクではファインチューニングが効く
- 専門領域では両者を組み合わせることで相乗効果が得られる
DE-STKではRAG構築からファインチューニング設計、両者の組み合わせアーキテクチャまで、社内データ活用の全フェーズをワンストップで支援しています。どちらを選ぶべきか判断に迷う段階でぜひご相談ください。
よくある質問(FAQ)
Q. RAGとファインチューニングのどちらを先にやるべきですか?
多くのケースではRAGから始めることを推奨します。RAGは構築が比較的容易で、データ更新も柔軟に行えます。RAGで精度が不十分な場合や、特定の出力スタイルが必要な場合にファインチューニングを追加する段階的アプローチが効率的です。「RAGで届かない壁」を定量的に確認してから、ファインチューニングに進むのが健全な意思決定プロセスです。
Q. ファインチューニングにはどのくらいのデータが必要ですか?
LoRA/QLoRAを使った効率的なファインチューニングなら、数百〜数千件の高品質なデータセットで効果が出ます。ただし、データの品質がモデルの性能に直結するため、量より質を重視してください。ノイズの多い1万件より、専門家がレビューした500件の方が成果に繋がりやすい傾向にあります。
Q. RAGとファインチューニングを両方使うのは冗長ではないですか?
冗長ではありません。ファインチューニングでモデルに専門知識の「理解力」を与え、RAGで最新・正確な「知識」を注入するアプローチは相乗効果があります。特に医療や法律など専門性の高い領域で有効で、ファインチューニング単独や RAG単独では届かない品質に到達することがあります。