Fine-tuning と RAG: 本番運用での意思決定ガイド
RAGは知識のギャップを埋め、fine-tuningは振る舞いのギャップを埋めます。本番運用で実際に役立つ意思決定フレームワークと、2026年に主流となったハイブリッド構成を解説します。
Section 01 · 中核となる区別
fine-tuningとRAGの実際の違いは何か
もっとも有用なメンタルモデル: RAGは「いまモデルが見えるもの」を変える。fine-tuningは「モデルが毎回どう振る舞いがちか」を変える。
クイックアンサー
一文で表すと: RAGは推論時に関連コンテキストを注入して知識のギャップを埋めます。fine-tuningは学習時にモデルの重みを調整して振る舞いのギャップを埋めます。失敗モードに合った道具を選んでください。
本番LLMシステムが誤った答えを返すとき、その失敗は2つのうちどちらかにあります。モデルが正しい情報を持っていないか、モデルは情報を持っているのに使い方を誤っているかです。これらは別々の問題です。同じ問題として扱うと、高くつくうえに照準のずれた解決策に行き着きます。
RAGは関連ドキュメントを取得し、推論時にコンテキストウィンドウに含めます。知識が頻繁に変わる場合、出典の明示が必要な場合、領域が大きすぎてfine-tuningが現実的でない場合に最適です。モデルの重みは変わりません。
fine-tuningは、キュレートしたデータセットでモデルの重みを更新します。出力フォーマットの一貫性、特定のトーンやスタイル、強い分類性能、コンテキストに記述がなくてもポリシーに従う振る舞いが必要なときに最適です。
Section 02 · RAGを使うとき
RAGが明確に正解となる4つの状況
知識が頻繁に変わる
fine-tuningはスナップショットです。データが変わるたびに再学習が必要です。RAGは生きたドキュメントを読むため、更新は即時に反映されます。週次・月次で更新される知識ベース — 製品ドキュメント、社内ポリシー、リーガルファイリング — では、RAGが現実的な唯一の選択肢になります。
出典の明示が必要
RAGは名前付きドキュメントを取得するため、答えごとに参照したチャンクを引用できます。fine-tuning済みモデルは知識を重みに埋め込み、トレース可能な出所を残しません。コンプライアンス、リーガル、医療など、出典を示さなければならない用途ではRAGが必須です。
失敗モードが事実の欠落・古さにある
ユーザーが誤った答えを受け取る原因が、最近の出来事、独自データ、組織固有のコンテキストをモデルが知らないことなら、それは知識のギャップです。RAGはこれを直接埋めます。fine-tuningでは解決しません。リアルタイムでfine-tuningはできず、古いデータで学習すれば古い知識が焼き付くだけです。
知識ベースが大きい、あるいは多様
数万件の多様なドキュメントでfine-tuningすると、いろいろなことが少しずつ得意なモデルにはなりがちですが、必要なタスクで確実に良くなるわけではありません。RAGは各クエリに合わせて適切なパッセージを取得します。スケールするほどカバレッジは精緻になります。
Section 03 · fine-tuningを使うとき
fine-tuningが正解となる4つの状況
出力フォーマットの一貫性が必要
アプリケーションが構造化JSON、特定のXMLスキーマ、予測可能な応答形を要求し、それをプロンプトエンジニアリングだけでは確実に出せない場合、フォーマット例でのfine-tuningが効きます。毎回指示しなくても、モデルがその構造を出力するよう学習します。
失敗モードが事実ではなく振る舞いにある
モデルが正解は知っているのに、トーン、長さ、ブランドに合わないスタイルで書いてしまうなら、それは振る舞いのギャップです。望ましい振る舞いの例でfine-tuningすればこれを埋められます。RAGはここでは助けになりません。RAGはコンテキストを足しますが、スタイルは足せません。
ドメイン特化の強力な分類が必要
ルーティング、インテント分類、ラベリングのように、精度を非常に高く、レイテンシを低く保ちたいタスクでは、fine-tuning済みの小規模モデルがプロンプティング型の汎用モデルを安定して上回ります。分類タスクで7Bモデルをfine-tuningすると、コストの一部で GPT-5 をプロンプティングするより高性能になることが少なくありません。
prompt injectionに頼らないポリシー遵守が必要
ユーザーの発言に関係なく、すべての応答が特定のポリシー — 安全規則、規制要件、ブランドガイドライン — に従う必要があるなら、ポリシーをモデルにfine-tuningで埋め込むほうが、巧妙なユーザーに迂回されかねないシステムプロンプト指示よりも堅牢です。
Section 04 · 意思決定フレームワーク
選択前に立てるべき1つの問い
どちらかに踏み切る前に、この問いに答えてください: 私の失敗モードは知識のギャップか、振る舞いのギャップか?
| 観点 | RAG | fine-tuning |
|---|---|---|
| 対処する失敗モード | 事実の欠落・古さ | 誤った振る舞い・フォーマット |
| 知識の鮮度 | リアルタイム | 学習時のスナップショット |
| 出典の明示 | ネイティブ対応 | 対応なし |
| 初期コスト | 低〜中(インフラ) | 中〜高(学習) |
| クエリあたりコスト | 高め(検索+生成) | 低め(生成のみ) |
| イテレーション速度 | 速い(ドキュメント更新) | 遅い(再学習) |
| 最適な用途 | 知識集約型アプリ | スタイル、フォーマット、分類 |
| 2026年のデフォルト | 新規構築の多くで採用 | RAGの上に重ねて採用 |
意思決定ツリーは単純です。まずプロンプトエンジニアリングから始めます。それで足りなければ、失敗モードを特定します。事実の問題ならRAGを足す。振る舞いの問題ならfine-tuningを足す。両方ならハイブリッドで動かす。
Section 05 · 2026年の標準
ハイブリッドRAG+fine-tuning: 多くの本番システムが採る形
RAG対fine-tuningの議論は2026年にはほぼ決着しています。本番グレードのAIシステムの多くは両者を併用します。RAGが知識検索 — 最新ドキュメント、独自データ、引用付き応答 — を担い、fine-tuningが振る舞い — フォーマット、トーン、ポリシー遵守の一貫性 — を担います。両者は競合ではなく補完関係です。
典型的なハイブリッドスタック: フォーマットとポリシー遵守のためのfine-tuning済みベースモデルに、ドメイン固有の知識検索のためのRAGを上に重ねる構成です。fine-tuning実行は一度きり(あるいは振る舞い要件が変わるごとに四半期に一度)、RAGパイプラインはドキュメント変更に応じて継続的に更新されます。
まずプロンプトエンジニアリングを試す
Claude Sonnet 4.6、GPT-5.4、Gemini 2.5 Pro を構造化されたプロンプトで使えば、幅広い振る舞い要件をfine-tuningなしで満たせます。良いプロンプティングで必要なことができるなら、学習コストは見合いません。
知識ベースがコンテキストに収まるならRAGを省く
10万トークン程度に収まる知識ベースなら、プロンプトキャッシュ付きのフルコンテキスト読み込みでコンテキストウィンドウに直接入れられます。セットアップコストはRAGパイプラインより低く、レイテンシも多くのユースケースで競争力があります。
FAQ
よくある質問
RAGとfine-tuningは併用できますか?
できます。実際、本番アプリケーションでは併用が正解になることが多いです。フォーマット、トーン、ポリシー遵守の一貫性はベースモデルのfine-tuningで担保し、ドメイン知識はRAGレイヤーに任せます。両者は別の失敗モードを補完し合います。
2026年時点でfine-tuningとRAGのコスト比較は?
70億パラメータのオープンソースモデルのfine-tuningは、データセット規模と計算量によって200〜2,000ドルです。RAGのインフラは、マネージドのベクトルDBと検索計算で月額50〜500ドル程度です。fine-tuningは一度限りのコスト、RAGは継続コストです。
RAGとfine-tuningの選択でもっとも多い間違いは?
実態は知識不足なのにfine-tuningを選んでしまうことです。誤答を見て、正解で学習させれば直るだろうと考えるパターンですが、モデルが訓練例に過適合し、言い換えで失敗するためもろい解決になります。事実的失敗にはRAGの方が堅牢です。
ベースモデルが進化した2026年でもfine-tuningする価値はありますか?
多くの振る舞い要件についてはありません。GPT-5.4 や Claude Sonnet 4.6 を構造化されたシステムプロンプトで使えば、フォーマット、トーン、大半のポリシー要件はfine-tuningなしで満たせます。fine-tuningが効くのは、レイテンシ要件の厳しい分類タスク、特殊用語の多い専門領域、prompt injectionのリスクなしにポリシー遵守を保証したい場面などです。
よくある質問
- RAGとfine-tuningは併用できますか?
- できます。実際、本番アプリケーションでは併用が正解になることが多いです。フォーマット、トーン、ポリシー遵守の一貫性はベースモデルのfine-tuningで担保し、ドメイン知識はRAGレイヤーに任せます。両者は別の失敗モードを補完し合います。
- 2026年時点でfine-tuningとRAGのコスト比較は?
- 70億パラメータのオープンソースモデルのfine-tuningは、データセット規模と計算量によって200〜2,000ドルです。RAGのインフラは、マネージドのベクトルDBと検索計算で月額50〜500ドル程度です。fine-tuningは一度限りのコスト、RAGは継続コストです。
- RAGとfine-tuningの選択でもっとも多い間違いは?
- 実態は知識不足なのにfine-tuningを選んでしまうことです。誤答を見て、正解で学習させれば直るだろうと考えるパターンですが、モデルが訓練例に過適合し、言い換えで失敗するためもろい解決になります。事実的失敗にはRAGの方が堅牢です。
- ベースモデルが進化した2026年でもfine-tuningする価値はありますか?
- 多くの振る舞い要件についてはありません。GPT-5.4 や Claude Sonnet 4.6 を構造化されたシステムプロンプトで使えば、フォーマット、トーン、大半のポリシー要件はfine-tuningなしで満たせます。fine-tuningが効くのは、レイテンシ要件の厳しい分類タスク、特殊用語の多い専門領域、prompt injectionのリスクなしにポリシー遵守を保証したい場面などです。