ファインチューニングはおすすめ？｜RAGで足りるケースと学習が必要なケース

生成AI（LLM）をビジネスに活用する際、必ず直面するのが「モデルを自社専用にカスタマイズすべきか（ファインチューニング）」、それとも「外部データベースを参照させるべきか（RAG）」という問いです。

「自社の専門知識を覚えさせるなら、学習（ファインチューニング）が必要だ」と考えがちですが、実務レベルでは「まずはRAG（Retrieval-Augmented Generation）を検討し、それでは解決できない課題がある場合にのみファインチューニングを検討する」のが鉄則となっています。本記事では、IT実務者の視点から、両者の違い、コスト、選定基準を、公式ドキュメントや実例に基づき徹底的に解説します。

ファインチューニングとRAGの根本的な違い

結論から述べると、両者は「脳のアップグレード」か「オープンブックテスト」かの違いに例えられます。

ファインチューニングとは「振る舞い」の最適化

ファインチューニングは、既存の学習済みモデル（GPT-4やLlama 3など）に対して、特定のデータセットを用いて追加訓練を行うプロセスです。これにより、モデルは特定の「口調」「専門用語の使われ方」「出力形式（JSONなど）」を深く学習します。

ただし、新しい事実や日々更新される情報を覚えさせるには不向きです。OpenAIの公式ドキュメントでも、ファインチューニングは「特定のタスクに対するパフォーマンス向上」や「出力の型の固定」に有効であると説明されています。

RAG（検索拡張生成）とは「外部知識」の参照

RAGは、ユーザーの質問に関連する情報を外部のデータベース（ベクトル検索エンジンなど）から検索し、その情報を「コンテキスト（参考情報）」としてモデルに渡す手法です。モデル自体を再学習させる必要はなく、最新のPDFやExcel、Webページの内容を即座に回答に反映させることが可能です。

業務システムの自動化において、例えばSFA・CRM・MAのデータ連携全体図を構築する場合、各ツールに散らばった動的なデータを扱うにはRAGが圧倒的に有利です。

【比較表】ファインチューニング vs RAG 5つの評価軸

プロジェクトの要件に合わせて、以下の比較表を参考に手法を選択してください。

ファインチューニングが必要な3つのケース

「RAGで十分」と言われる昨今ですが、それでもファインチューニングが強く推奨されるケースがあります。

1. 特殊な出力フォーマット・構造を維持する必要がある

例えば、出力を厳密なJSON形式に固定したい、あるいは医療や法務の非常に特殊な文書フォーマットを守らなければならない場合です。プロンプトエンジニアリング（指示出し）だけでは、稀に形式が崩れることがありますが、数千件のサンプルでファインチューニングされたモデルは、その「型」を外さなくなります。

2. 業界特有の言語パターンや微細なニュアンスを習得させる

一般的なLLMが理解しにくい「業界特有の略称」や「社内だけで使われる暗黙の了解」に基づいた文章構成が必要な場合です。例えば、広告運用の自動化において、特定のクリエイティブの良し悪しを判断する「独自の美的感覚」を模倣させるには、過去の成功事例を学習させることが有効です。

データに基づいた意思決定を加速させるアーキテクチャについては、CAPIとBigQueryで構築する自動最適化データアーキテクチャの解説が参考になります。

3. 実行時のトークンコストを極限まで削減したい

RAGは回答のたびに、数千〜数万文字の参照テキストをプロンプトに流し込みます。これに対し、ファインチューニング済みモデルは知識やスタイルがモデル内部にあるため、長い指示（システムプロンプト）を省略できます。大量のリクエストが発生するBtoCサービスでは、長期的に見て1リクエストあたりのコストを抑えられる可能性があります。

RAGで十分（あるいはRAGが最適）なケース

多くの実務現場では、RAGが最適解となります。その理由は「正確性」と「運用コスト」にあります。

1. 頻繁に更新される情報を扱う

社内規定、商品マニュアル、最新の在庫状況などは日々更新されます。これらを反映するために毎日ファインチューニングを行うのは非現実的です。RAGであれば、ドキュメントをベクトルDBにアップロードするだけで、数分後には最新情報に基づいた回答が可能になります。

2. 回答の根拠（ソース）を明示する必要がある

ビジネス用途では「AIが言っていることは本当か？」という検証が欠かせません。RAGは「参照したPDFの3ページ目」を引用として提示できるため、ユーザーの信頼を獲得しやすく、ハルシネーション（もっともらしい嘘）のリスクを大幅に軽減できます。

3. 開発スピードと低コストを重視する

OpenAIの「GPTs」やGoogleの「Vertex AI Search and Conversation」などの登場により、コーディングなしでRAGを構築できる環境が整っています。まずはRAGでプロトタイプを作成し、精度に限界を感じたとき初めてファインチューニングを検討するのが、現代のDXにおける最短ルートです。

特にバックオフィス業務において、SaaSコスト削減と負債の剥がし方をマニュアル化するようなプロジェクトでは、既存ドキュメントの即時反映が求められるため、RAGが第一選択となります。

実装ステップ：RAGから始めるべき手順

実務担当者がまず取り組むべき、RAG構築のステップを紹介します。

STEP 1：データクレンジングとチャンク分割

PDFやWord、Notionのデータを、AIが読み取りやすいサイズに分割（チャンキング）します。

• 1チャンクあたり500〜1,000文字程度が目安。
• 表組み（Table）は構造が崩れやすいため、Markdown形式に変換して保存するのがコツです。

STEP 2：埋め込みモデル（Embedding）の選定

テキストを数値（ベクトル）に変換するモデルを選びます。

• OpenAI text-embedding-3-small: 安価で高性能。
• Cohere Embed v3: 多言語対応に強く、日本語の検索精度が高い。

STEP 3：ベクトル検索精度の評価

ユーザーの質問に対して、適切なドキュメントがヒットするかをテストします。ここで精度が出ない場合、モデルの問題ではなく「データの切り出し方」や「検索クエリの作り方（Query Expansion）」に問題があるケースがほとんどです。

よくあるエラーと対処法：

「回答が『分かりません』となる」：検索エンジンのヒット件数（k値）を増やすか、ハイブリッド検索（キーワード検索＋ベクトル検索）を導入してください。

コストと運用：見落としがちな隠れコスト

「ファインチューニングは高い、RAGは安い」というのは一面的な見方です。

• RAGのコスト: ベクトルDBの維持費（PineconeやWeaviate等）、回答ごとのコンテキスト読み取りトークン費用。
• ファインチューニングのコスト: 高品質な教師データ（数百〜数千件）の作成人件費、再学習ごとの計算費用、専用モデルをホストするための固定費。

特に、専門知識を扱う場合は「教師データの作成」に現場のエキスパートが拘束されるコストが最も重くなります。これを見落とすと、プロジェクトのROIが成立しなくなります。

まとめ：自社にとっての最適解を導き出すために

現代のAI活用において、「ファインチューニングから入るのは、極めて特殊なケースのみ」です。まずはRAGをベースとしたシステムを構築し、そこで浮き彫りになった「口調の不安定さ」や「特定の処理の失敗」を解消するために、部分的にファインチューニングを組み合わせる「ハイブリッドアプローチ」が最も推奨されます。

自社のデータ基盤を整え、AIを道具として使いこなすためには、モデルの選定以上に「データの流れ」を設計することが重要です。例えば、モダンデータスタックを用いたデータ基盤を構築しておけば、RAGへのデータ供給もスムーズになり、将来的なAI活用の幅が広がります。

まずは、自社がAIに「何をさせたいのか（知識の提供か、振る舞いの模倣か）」を明確にすることから始めましょう。