業務AI、特に生成AIを業務に組み込む際、ほぼ必ず直面する技術選定が Fine-tuning vs RAG である。両者の役割と適用範囲を正しく理解しないと、実装の方向性を誤り、PoC止まりや低精度な運用に陥る。

2026年の業界コンセンサスでは、「Prompt → RAG → Fine-tune → Distill」 の順で試すアプローチが推奨されている。多くのケースで RAG だけで業務要件を満たせるため、Fine-tuning は「RAGでは解決できない問題」が明確になった後で導入を検討するのが定石。本稿では両者の本質的な違い、ハイブリッド戦略、LoRA/QLoRA等の効率化技術までを実装目線で整理する。

各概念の基本についてはRAGとは、AI技術用語統合ガイド近日公開も参照されたい。

結論を先に述べる

ほとんどの業務AIユースケースで、まずRAGから始めるべきである。Fine-tuningは「RAGでは解決できない問題」が明確になった後で導入を検討するのが正解である。

両者は競合関係ではなく、補完関係にある。理想的には、RAGで知識を与えつつ、必要に応じてFine-tuningで振る舞いを調整するハイブリッド構成になる。

本質的な違い

観点 RAG Fine-tuning
目的 LLMに「知識」を持たせる LLMの「振る舞い」を変える
メカニズム 推論時に外部DBから情報を検索→コンテキスト追加 モデルパラメータ自体を再学習
更新頻度 即時（DB更新で反映） バッチ的（モデル再学習が必要）
学習データ 文書（マニュアル、FAQ、議事録など） 入力-出力ペアの例示
初期コスト 低（プロトタイプは数日） 中〜高（データ収集・学習・評価で数週間）
継続コスト 低（DBメンテのみ） 中（モデル再学習サイクルが必要）
出典明示 可能（どの文書から引用したか示せる） 困難（モデル内部に統合される）
メリット 透明性、即時更新、低コスト 一貫した振る舞い、低レイテンシ、トークン節約

RAGが向いているケース

以下に該当するなら、RAGから始めるべきである。

1. 社内データに基づく回答が必要

営業資料、技術文書、FAQ、過去の議事録、顧客履歴など、LLMが知らない情報に基づいて回答させたい場合。これらはRAGの本領である。

2. 情報が頻繁に更新される

製品仕様、料金表、法規制、業務マニュアルなど、月単位・週単位で更新される情報は、RAGで参照させるのが合理的。Fine-tuningでは追従できない。

3. 出典が必要

法務、医療、金融などの規制業界では「この回答はどの文書に基づいているか」を示す必要がある。RAGなら検索された文書を出典として返せるが、Fine-tuningでは困難。金融機関でのRAG実装論は金融機関のAI活用近日公開、医療機関での実装論は医療機関のAI活用近日公開を参照。

4. PoC段階・初期実装

不確実性が高い段階では、低コストで素早く動かせるRAGが現実的に有利。Fine-tuningで失敗すると数週間が水の泡になる。

Fine-tuningが向いているケース

RAGでは解決できない、以下のような問題がある場合にFine-tuningを検討する。

1. 特定の言い回し・出力形式が必要

医療の所見書、法務の契約書、営業資料など、特定のフォーマットや業界特有の言い回しを一貫して使わせたい場合。RAGで例示しても揺らぐ。

2. 大量の例示パターンを学ばせたい

「この種の質問にはこう回答する」「このタイプの入力はこう変換する」というパターンが数百〜数千ある場合、RAGのコンテキストには入りきらない。Fine-tuningで内部化させる。

3. レスポンス速度が重要

RAGは検索ステップが入るので応答が遅くなる。リアルタイム性が必要な場合（例: チャットボット）は、Fine-tuningのほうが速い。

4. トークンコストを下げたい

RAGはコンテキストに大量の文書を入れるためトークン消費が大きい。Fine-tuningで知識を内部化すれば、推論時のトークン量は減る。大規模運用ではコスト差が顕著になる。

5. 専門領域特化のモデル

医療診断補助、法律分析、業界特化チャットボットなど、汎用LLMでは精度が出ない領域。ドメイン特化のFine-tuningで顕著な改善が見込めるケースがある。

LoRA / QLoRA — 効率的なFine-tuningの主流手法

2026年の Fine-tuning 実装では、フルパラメータ学習ではなく PEFT（Parameter-Efficient Fine-Tuning） が主流となっている。代表的な手法が LoRA（Low-Rank Adaptation） と QLoRA（Quantized LoRA） である。

LoRA / QLoRA の概要

  • LoRA: ベースモデルのパラメータは固定し、小さな追加パラメータ（Low-Rank行列）のみを学習する。学習コストが大幅に下がる
  • QLoRA: LoRAに4-bit量子化を組み合わせ、コンシューマGPUでも 70B 規模のモデルを Fine-tuning 可能にする

実装の指針

業界では以下の指針が一般的とされる:

  • VRAMに余裕がある場合: LoRA を使う
  • コンシューマGPUで Fine-tuning したい場合: QLoRA を使う
  • 試行錯誤段階: まず QLoRA で rank=16 を試す
  • 品質が不足する場合: LoRA に切り替える
  • それでも不足する場合: 初めてフル学習を検討

データ品質の重要性

「データの質は量より重要」が経験則とされる。報道される事例では、500件の高品質データが10,000件の低品質データより良い結果を生むことがあるとされる。Fine-tuning の成否は、データ準備と評価設計に大きく依存する。

ハイブリッド戦略

実運用では、両者を組み合わせるのが多くのケースで最適解になる。

パターン1 / Fine-tuningで「型」、RAGで「内容」

例: 医療レポート生成

  • Fine-tuning: 医師の所見書フォーマット、医学用語、構造を学習
  • RAG: 患者カルテ、診療ガイドライン、過去の類似症例を検索してコンテキスト追加

これにより、適切なフォーマットで具体的な患者データに基づくレポートが生成できる。

パターン2 / RAGで一次対応、Fine-tuningで難ケース

例: カスタマーサポート

  • RAG: 一般的な問い合わせはRAGで処理
  • Fine-tuning: 特定のクレーム対応、丁寧な謝罪、返金処理など、振る舞いの一貫性が重要な領域はFine-tuningモデルに振り分け

パターン3 / PEFT × RAG の本番運用

業界の本番運用パターンとして、PEFT（LoRA/QLoRA）で「ドメインの言い回し・書き方」を学習させたモデルに、推論時に RAG で「最新の文書・データ」を注入する構成が広がりつつある。例えば法務アシスタントなら、法律推論パターンを Fine-tune しつつ、判例・条文を動的に検索する形。

2026年の推奨アプローチ順序

業界の標準的な順序は以下とされる。

1. プロンプトエンジニアリングのみで試す（数日）
   ↓ 不足あり
2. RAGを追加（数週間）
   ↓ 不足あり
3. Fine-tune（LoRA/QLoRA）を追加（数週間〜数ヶ月）
   ↓ コスト/速度問題あり
4. より小さなモデルへ Distill（蒸留）（数ヶ月）

最初から Fine-tuning に飛びつくと、不要な複雑性とコストを抱える。実装の順序自体が、PoC止まり回避の鍵である（AI PoC止まり脱出フレームワーク参照）。

選定の意思決定フロー

業務AIで選定に迷った時のフロー:

質問1: 社内固有の知識・最新情報を参照する必要があるか
  YES → RAGが必須。次にFine-tuningも必要かを判断
  NO  → Fine-tuningかプロンプトエンジニアリングのみで足りる

質問2: 特定の出力フォーマット・振る舞いを徹底させたいか
  YES → Fine-tuningを検討
  NO  → RAGとプロンプトで対応可能

質問3: 情報の更新頻度はどれくらいか
  毎日〜毎週 → RAGが必須
  半年〜年単位 → Fine-tuningも検討可

質問4: 出典明示が必要か
  YES → RAGが必須
  NO  → Fine-tuning単体も検討可

質問5: 推論コスト・レイテンシは重要か
  YES → Fine-tuning（or 蒸留）で軽量化
  NO  → RAG 単体でOK

よくある誤解

誤解1 / 「Fine-tuningすれば賢くなる」

Fine-tuningは賢さの向上ではなく振る舞いの調整である。LLM本来の推論能力以上のものは引き出せない。賢さが必要なら、より高性能なベースモデル（GPT、Claude、Gemini 等の上位モデル）を選ぶ方が効果的である。

誤解2 / 「RAGだけで何でもできる」

RAGの精度は検索の精度に依存する。検索が外せば、コンテキストにゴミが入りLLMの回答品質が劣化する。前処理・評価・更新の設計が極めて重要。詳細はRAGとは、評価フレームの設計はAI評価フレームの実装論近日公開を参照。

誤解3 / 「両方やればベスト」

両方を導入すれば設計・運用・コストが2倍になる。本当にハイブリッドが必要なケース以外では、どちらか一方に絞るほうが運用持続性が高い。

誤解4 / 「Fine-tuningはフル学習が前提」

2026年現在、LoRA/QLoRA等の PEFT が事実上の標準。フル学習はリソース・コスト的に正当化できるケースが限られる。

誤解5 / 「データは多ければ多いほどよい」

データの質は量より重要。少数の高品質ペアの方が大量の低品質データより良い結果を生むことがある。

コスト構造の比較（概算レンジ）

実装コストの概算レンジを整理する（実際は要件・規模で大きく変動する）。

項目 RAG Fine-tuning (LoRA/QLoRA)
初期実装 数百万〜 数百万〜
データ準備 文書整理・チャンク化中心 高品質ペア作成（時間がかかる）
学習コスト なし LoRA: 数万円、QLoRA: 数千円〜
推論コスト コンテキスト増分の token cost 通常モデルと同等
運用 文書更新・再インデックス モデル再学習サイクル

ROI測定の枠組みはAI ROIの測定方法近日公開、技術選定の論点全般は業務AIインフラの技術選定近日公開を参照。

実務での順序（再掲）

経験的に、業務AI実装は以下の順序で進めるのが安全である。

  1. プロンプトエンジニアリングのみで試す（数日）
  2. 不足ならRAGを追加（数週間）
  3. それでも特定の振る舞いが安定しない部分に Fine-tuning（LoRA/QLoRA）を追加（数週間〜数ヶ月）
  4. 大規模本番運用ではコスト/速度を考慮し、より小さなモデルへの Distill（蒸留）も視野に

最初から Fine-tuning に飛びつくと、不要な複雑性とコストを抱える。

まとめ

Fine-tuningとRAGは、技術選定で迷うべき問いではない。そもそも目的が異なる技術であり、ほとんどのケースでは「まずRAG、必要に応じて Fine-tuning（LoRA/QLoRA）追加」が正解である。

「Fine-tuningを使えば賢くなる」「RAGで全て解決する」のような単純化された理解は、実装フェーズで必ず壁にぶつかる。両者の本質的な違いを理解した上で、業務の要件に応じて使い分け、必要なら組み合わせる——これが業務AIの設計者に求められる判断力である。

業務適用の支援を選ぶ際の枠組みはAX支援サービスの選び方、FDE型コンサル等の選択肢はFDE型コンサルティング完全解説で扱っている。

関連記事: