TL;DR ( 忙しい人のための3行まとめ )

RAG ( 検索拡張生成 ) は「教科書を持ち込んで試験を受ける」こと。最新情報や事実確認に強い。
Fine-tuning ( ファインチューニング ) は「猛勉強して脳の構造を変える」こと。口調、形式、専門的な推論パターンの固定に強い。
「自社データを覚えさせたい」なら、まずは RAG から始めるのが鉄則。いきなり Fine-tuning は事故の元。

Introduction

「 ChatGPT に社内マニュアルを全部覚えさせたいから、ファインチューニングしようと思うんだけど」

もしあなたの同僚がこう言ったら、全力で止めてください。これは、生成AI導入における 最も古典的かつ致命的な勘違い です。

多くのエンジニアやPMが「知識の注入」＝「学習 ( Training )」と考えがちですが、LLM ( 大規模言語モデル ) においてそれは効率的ではありません。
2025年現在、知識の参照には RAG、振る舞いの矯正には Fine-tuning、そしてその両者を組み合わせる Hybrid アプローチが主流です。

本記事では、両者の決定的な違いをエンジニアリング視点で解剖し、あなたのプロジェクトがどちらを選ぶべきかの「明確な判断基準」を提示します。

Comparison: The Chef Metaphor ( 料理人の比喩 )

技術的な詳細に入る前に、直感的な比喩で両者を理解しましょう。
ここに「優秀なフランス料理のシェフ ( = Pre-trained LLM )」がいます。

1. RAG ( Retrieval-Augmented Generation )

シェフに「和食のレシピ本」を渡すアプローチです。

動作: シェフは注文が入るたびにレシピ本 ( 外部DB ) をパラパラとめくり、そこに書かれた通りに調理します。
メリット: レシピ本を差し替えれば、明日からイタリアンも作れます。最新の流行メニューにも即座に対応可能です。
デメリット: いちいち本を読む時間がかかります ( レイテンシ増 )。

2. Fine-tuning

シェフを「和食の専門学校」に送り込み、数ヶ月間再教育するアプローチです。

動作: シェフは何も見ずに、体得した技術で完璧な天ぷらを揚げます。
メリット: 動作が速く、和食特有の「阿吽の呼吸」や「盛り付けの作法」まで完璧に身につきます。
デメリット: 専門学校に通う費用 ( コスト ) が莫大です。また、メニューが変わるたびに再教育が必要です。

Detailed Breakdown ( 詳細比較 )

エンジニアが気にするべき4つの軸で比較します。

比較軸	RAG ( 外部知識参照 )	Fine-tuning ( 追加学習 )
知識の更新	容易 ( データを足すだけ )	困難 ( 再学習が必要 )
ハルシネーション	抑制しやすい ( 根拠を提示可能 )	依然としてリスクあり ( 記憶違いを起こす )
得意タスク	具体的な事実検索、最新情報の回答	口調の統一、特定フォーマット ( JSON等 ) の出力、独特な推論
初期コスト	低 ( ベクトルDB構築のみ )	高 ( データセット作成 + GPUコスト )
ランニングコスト	高 ( 入力トークンが増えるため )	低 ( プロンプトが短くて済む )

💡 意外な落とし穴：コストの逆転現象

「RAGの方が安い」と一般に言われますが、大規模運用時は注意が必要です。
RAG は毎回大量のドキュメントをプロンプトに含めるため、入力トークン課金 が嵩みます。一方、Fine-tuning 済みのモデルは「質問」だけで答えられるため、トークン消費は最小限です。
月間数百万リクエストを超えるようなケースでは、Fine-tuning の方がトータルコストが安くなる分岐点が存在します。

Use Cases ( ケース別判断フロー )

どちらを採用すべきか迷ったときは、以下のフローチャートに従ってください。

Case 1: RAG を選ぶべきシーン

情報の鮮度が命: ニュース、株価、社内の日報、製品在庫など、分単位・日単位で変わる情報。
根拠の提示が必要: 「マニュアルの〇ページに書いてあります」という引用が必要な場合。
データ量が膨大: 数GB〜TB級のドキュメントは、学習データに収まりきりません。

Case 2: Fine-tuning を選ぶべきシーン

特定の「キャラ」になりきらせたい: 語尾が「〜だにゃ」の猫型bot、特定の作家風の文章生成など。
複雑な出力形式の厳守: 特殊な JSON スキーマや、独自のプログラミング言語を出力させたい場合。
プロンプトエンジニアリングの限界: 長すぎる指示 ( System Prompt ) を短縮し、レイテンシを下げたい場合。

Implementation Focus: Data Preparation

前回の記事で RAG の実装は紹介したので、ここでは Fine-tuning の難しさ を実感してもらうために、必要なデータ形式の違いを解説します。

RAG の場合：ドキュメントを突っ込むだけ

PDF や Markdown をそのまま読ませれば、ライブラリが勝手に分割・ベクトル化してくれます。

# RAGならこれだけ
loader = PyPDFLoader("manual.pdf")
documents = loader.load()
# あとはVectorDBに入れるだけ...

Fine-tuning の場合：高品質な Q&A ペアの量産が必要

OpenAI の gpt-4o-mini 等をファインチューニングする場合、以下のような JSONL 形式のデータを 数百〜数千件 用意する必要があります。
単なるテキストではなく、「理想的な会話例」を作成する工数は甚大です。

{"messages": [{"role": "system", "content": "あなたは弊社のカスタマーサポートAIです。"}, {"role": "user", "content": "返品はできますか？"}, {"role": "assistant", "content": "はい、商品到着後30日以内であれば、未使用品に限り返品を承っております。手続きはマイページから可能です。"}]}
{"messages": [{"role": "system", "content": "あなたは弊社のカスタマーサポートAIです。"}, {"role": "user", "content": "ログインできません。"}, {"role": "assistant", "content": "ご不便をおかけし申し訳ございません。パスワードの再設定はお済みでしょうか？ こちらのリンクから..."}]}
... (これをあと500個作成)

この「データ作成コスト ( Data Curation Cost )」こそが、Fine-tuning 最大の壁です。ゴミデータで学習させると、モデルの性能はベースモデルより悪化します ( これを Model Collapse と呼びます )。

Conclusion

結論：「まずは RAG、必要なら Hybrid」

2025年の開発現場における定石は以下の通りです。

まず RAG でシステムを構築する ( 9割のユースケースはこれで解決します )。
プロンプトだけでは回答の口調や形式が安定しない場合、あるいはコスト削減が必要な段階で、軽量モデルの Fine-tuning を検討する。
最終的に、Fine-tuning したモデルで RAG を行う Hybrid 構成にする。

「覚えさせる」のではなく「探させる」。このパラダイムシフトを受け入れることが、成功への第一歩です。

References

⚠️ 本記事に関する注意

本記事は執筆時点の情報に基づき作成しています。

AI 技術は発展が速いため、仕様や挙動が変更される可能性があります。