ファインチューニングとRAGの違いは？使い分けと判断基準を実務で解説
- 追加学習でLLMの重み（パラメータ）を更新する
- 出力形式・口調・専門タスクの挙動を安定させやすい
- 知識を更新するには再学習が必要
- 学習用データの準備と評価の工数がかかる
- LoRAなど軽量な手法で学習コストを抑えられる
- 回答時に外部文書を検索しプロンプトへ挿入する
- モデルの重みは変更しない
- 文書を差し替えれば知識をすぐ更新できる
- 回答の根拠となる出典を示しやすい
- 検索精度が回答品質を大きく左右する
- 1. 課題を特定する「知識が足りない」のか「振る舞い・出力の型が合わない」のかを切り分ける
- 2. プロンプト設計で検証する指示・Few-shot例の工夫だけで要件を満たせるかを最初に確認する
- 3. 知識不足ならRAGを導入する社内規程・マニュアルなど更新される情報は検索で補い、出典を提示する
- 4. 振る舞いの課題ならファインチューニングを検討する出力形式・専門用語の使い方・分類タスクの一貫性を学習データで調整する
- 5. 評価指標で効果を比較する同一の評価データセットで正答率・根拠の妥当性・コストを比べて採否を決める
ファインチューニングとRAGの違いは？
ファインチューニングはモデル自体の振る舞いを変える手法で、RAGは回答するたびに外部の知識を参照させる手法です。
生成AIを業務に組み込むとき、最初に悩むのが「自社の知識やルールをLLMにどう反映させるか」です。反映させる手段は大きく2つあります。モデルの重み（パラメータ）を追加学習で調整するファインチューニングと、回答時に社内文書を検索してプロンプトに差し込む**RAG（Retrieval-Augmented Generation：検索拡張生成）**です。どちらも「自社向けにする」手段ですが、仕組みが違うため、得意なことと苦手なことがはっきり分かれます。
仕組みの違いは「どこに知識を持たせるか」
ファインチューニングは知識や癖をモデルの内部に持たせ、RAGはモデルの外にあるデータベースに持たせます。
RAGは、2020年にMeta（当時のFacebook AI Research）の研究者らが論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で提唱した考え方がもとになっています。現在の実装では、ユーザーの質問をもとにベクトル検索やキーワード検索で関連文書を取り出し、その内容を根拠としてLLMに回答を生成させる構成が一般的です。
ファインチューニングは、事前学習済みのLLMに自社のデータ（入力と望ましい出力の組）を追加で学習させ、モデルの出力傾向そのものを変えます。OpenAIのファインチューニングAPI、MicrosoftのAzure OpenAI、GoogleのVertex AI、Amazon Bedrockなど、主要なクラウドは何らかの形でファインチューニングの機能を提供しています。また、Microsoftの研究者らが2021年に発表したLoRAのように、一部のパラメータだけを学習して計算コストを抑える手法も広く使われています。
比較表で見る基本的な特性
知識の鮮度と根拠の示しやすさはRAGが有利で、出力形式や口調をそろえる点はファインチューニングが有利です。
| 観点 | ファインチューニング | RAG |
|---|---|---|
| 知識を持たせる場所 | モデルの重み（内部） | 外部の文書・データベース |
| 情報の更新 | 再学習が必要 | 文書を差し替えれば反映される |
| 回答の根拠提示 | 難しい（どのデータ由来か追いにくい） | 参照した文書を引用として示せる |
| 得意なこと | 出力形式・口調・専門タスクの型をそろえる | 最新情報や社内固有の事実に基づいて答える |
| 主な準備物 | 質の高い学習データセット | 整備された文書群と検索の仕組み |
| 権限制御 | モデル単位になりやすい | 文書単位でアクセス制御をかけやすい |
現場で説明するときは「ファインチューニングは“話し方と型”を教えるもの、RAGは“参照資料”を渡すもの」とたとえると、経営層にも伝わりやすいと感じています。
ファインチューニングとRAGはそれぞれどんな用途に向いている？
RAGは社内の事実に基づいて答える業務に向き、ファインチューニングは決まった形式での出力を安定させたい業務に向きます。
用途の向き不向きは、「求めているのが知識なのか振る舞いなのか」で整理すると判断しやすくなります。
RAGが向いている用途
規程やマニュアル、製品情報など、頻繁に変わり根拠を示す必要がある社内の知識を使う業務はRAGが第一候補です。
- 社内ヘルプデスク・規程の問い合わせ対応：就業規則や経費精算ルールなど、改定される文書をもとに回答する
- カスタマーサポートの回答支援：製品マニュアルやFAQ、過去の対応記録を検索して回答案を作る
- 営業・提案資料の下調べ：過去の提案書や事例集から関連する情報を集める
- 契約書・技術文書の調査：該当する条項や箇所を引用付きで示す
どれも「答えが文書の中にある」「文書が更新される」「根拠を確認したい」という3つの条件を満たします。AX推進の現場では、最初のユースケースとしてRAGによる社内検索・問い合わせ対応から始める組織が多いという印象です。
ファインチューニングが向いている用途
出力のフォーマットや専門的な言い回し、分類ルールなど、プロンプトの指示だけでは安定しない“型”を身につけさせたい場合に向きます。
- 定型フォーマットでの文書生成：社内独自の報告書形式や、特定のJSON構造での出力
- 分類・抽出タスク：問い合わせのカテゴリ分類、帳票からの項目抽出などを大量に処理する
- ブランドトーンの統一：自社らしい文体や表現ルールに沿った文章を生成する
- 小型モデルの性能向上：軽量なモデルを特定タスクに特化させ、推論コストや応答時間を抑える
注意したいのは、「社内知識を覚えさせるためにファインチューニングする」という発想です。事実の記憶を目的にした追加学習は、情報が更新されるたびに学習し直す必要があり、覚えた内容を正しく引き出せる保証もありません。主要ベンダーのドキュメントでも、まずプロンプトの工夫やRAGを検討するよう勧める趣旨の記述が見られます。知識の反映が目的なら、まずRAGを検討するのが安全です。
コスト・運用負荷・リスクにはどんな違いがある？
RAGは始めやすい一方で検索の品質管理が続き、ファインチューニングは準備と再学習に手間がかかる点が主な違いです。
初期費用だけで比べると判断を誤りやすくなります。運用を始めてから発生する負荷とリスクまで含めて比較することが重要です。
コストと運用負荷の比較
RAGはデータ整備と検索精度の改善に、ファインチューニングは学習データ作成と再学習に継続的な工数がかかります。
| 項目 | ファインチューニング | RAG |
|---|---|---|
| 初期に必要な作業 | 学習データの収集・整形・品質確認、学習と評価 | 文書の収集・分割（チャンク化）・インデックス作成 |
| 継続的に発生する作業 | ベースモデルの更新や要件変更に合わせた再学習 | 文書の追加・更新、検索精度のチューニング |
| 推論時のコスト | 追加の検索処理がなく、プロンプトを短くできる | 検索した文書を入れる分、入力トークンが増える |
| 必要なスキル | 機械学習の評価設計、データ作成のノウハウ | 検索システム設計、文書管理、権限設計 |
| つまずきやすい点 | 学習データの質と量の不足 | 文書の形式がバラバラで検索にかからない |
RAGのプロジェクトで工数を食うのは、LLMの部分よりも文書の整備であることが少なくありません。PDFの表が崩れる、古い版と新しい版が混在している、部署ごとに書式が違う、といった問題は、検索精度に直接響きます。「RAGはすぐ作れる」と見積もって後から苦労するケースは、多くの現場で聞く話です。
リスクとガバナンスの違い
RAGは参照元を確認できるため監査しやすく、ファインチューニングは学習データに機密情報が混ざるリスクに注意が必要です。
- ハルシネーション（もっともらしい誤り）：RAGは根拠を示せるため誤りに気づきやすい一方、検索結果が的外れだと誤った回答になる。ファインチューニングは根拠を追いにくく、誤りの原因を特定しにくい
- 情報漏えい：ファインチューニングで学習させた機密情報は、想定外の質問への回答に出てしまう可能性がある。RAGは文書単位で閲覧権限を管理できる
- 説明責任：業務で使うには「なぜその回答になったか」を説明できることが求められる場面が多く、引用を示せるRAGのほうが社内の合意を得やすい
- ベンダーへの依存：ファインチューニングしたモデルは特定のベースモデルに結びつくため、モデルの提供終了や乗り換えの際に作り直しが必要になる
特に規制の厳しい業界や、個人情報を扱う業務では、学習データに何が含まれているかを管理する体制を先に決めておくことをおすすめします。
どちらを選ぶべきかの判断手順は？
まずプロンプトの工夫で試し、知識が足りなければRAG、型が安定しなければファインチューニングの順で検討するのが基本です。
実務では、いきなりどちらかに決めるのではなく、小さく試しながら段階的に進めるほうが失敗を減らせます。
5ステップの判断フロー
課題を「知識が足りない」と「振る舞いが安定しない」に切り分けてから、手段を選びます。
- 目的と評価基準を決める：どの業務の、どの指標（正答率、処理時間、作業工数など）を改善したいのかを明確にする
- プロンプトの工夫だけで試す：指示文の改善や出力例の提示（Few-shot）で、どこまで要件を満たせるかを確かめる
- 失敗の原因を分類する：「必要な情報を知らない」ことが原因ならRAGへ、「形式や判断基準がぶれる」ことが原因ならファインチューニングへ進む
- 小さな評価用データセットで比較する：実際の業務の質問・入力を数十〜数百件集め、改善前後の結果を同じ基準で評価する
- 運用体制まで含めて決定する：文書の更新担当、再学習の頻度、品質監視の方法を決め、継続して運用できる形で本番に移す
ステップ3の切り分けを曖昧にしたまま進めると、「RAGを入れたのに出力形式がそろわない」「ファインチューニングしたのに最新の規程を答えられない」といった、手段と課題のズレが起きます。
判断に迷ったときのチェックリスト
情報の更新頻度、根拠提示の必要性、出力の型の厳しさの3点で、ほとんどのケースは判断できます。
| 質問 | 「はい」なら有力な選択肢 |
|---|---|
| 参照する情報は月単位・週単位で更新されるか | RAG |
| 回答の根拠（出典）を利用者に示す必要があるか | RAG |
| 利用者によって閲覧できる情報を分ける必要があるか | RAG |
| 決まった形式や文体での出力が必須か | ファインチューニング |
| 同じ種類のタスクを大量に処理し、推論コストを下げたいか | ファインチューニング |
| プロンプトが長くなりすぎて管理しきれないか | ファインチューニング |
意思決定者の立場からは、「どちらが技術的に優れているか」ではなく「自社の業務の変化に合わせて、どちらなら運用し続けられるか」という観点で判断することが、AX推進では重要だと考えています。
ファインチューニングとRAGを併用する構成とは？
併用では、ファインチューニングで出力の型と判断の癖を整え、RAGで最新の事実を渡すという役割分担が基本になります。
ファインチューニングとRAGは対立する選択肢ではなく、組み合わせることもできます。ただし、構成が複雑になるほど運用負荷も増えるため、併用する理由を明確にしておくことが前提です。
代表的な併用パターン
生成側のモデルを調整するパターンと、検索側の部品を調整するパターンの2つが代表的です。
| パターン | 構成 | 期待できる効果 |
|---|---|---|
| 生成モデルの調整 | RAGで取得した文書を、形式や口調を学習済みのLLMで回答にまとめる | 根拠に基づきつつ、社内フォーマットに沿った回答を安定して出せる |
| 検索部品の調整 | 埋め込み（Embedding）モデルやリランカーを社内の文書で追加学習する | 業界用語や社内の略語を含む質問でも、関連文書を見つけやすくなる |
| 役割に応じた使い分け | 分類や抽出は特化型の小型モデル、自由回答はRAG付きの汎用LLMで処理する | 処理コストと回答品質のバランスを取りやすい |
また、検索の精度を上げる工夫として、Anthropicが2024年に公開した「Contextual Retrieval」のように、文書の断片に前後の文脈情報を付け足してから検索用のインデックスを作る手法も紹介されています。ファインチューニングの前に、こうした検索側の改善で課題が解決することも少なくありません。
併用を始める前に確認したいこと
単独の構成で限界を確かめてから併用に進み、評価と運用の担当者を先に決めておくことが大切です。
- 単独の構成を先に試したか：RAGだけ、あるいはプロンプトの改善だけで要件を満たせないことを、評価データで確かめておく
- 評価の仕組みがあるか：検索の精度と回答の品質を分けて測れないと、どこを改善すべきか判断できない
- 更新の責任者が決まっているか：文書の更新はRAG側、モデルの再学習はファインチューニング側と、担当と頻度を明確にする
- ベースモデルの更新に対応できるか：主要ベンダーはLLMを頻繁に更新しているため、新しいモデルに乗り換えたときに再学習や再評価が必要になることを見込んでおく
現場の感覚としては、最初からファインチューニングとRAGの併用を前提に設計するよりも、RAGを本番で運用し、そこで見えた「型のぶれ」を解消する手段としてファインチューニングを追加する流れのほうが、投資の判断をしやすく、社内の説明もスムーズになりやすいと感じます。AXは技術を導入すれば終わりではなく、業務とともに改善し続ける取り組みです。手段の選択も、その前提で柔軟に見直していくことをおすすめします。
