はじめに：なぜLLMカスタマイズが必要か
汎用LLMは幅広いタスクに対応できるが、企業固有の知識や業界特有の用語に対しては精度が不足する場合がある。McKinseyの調査（2025年）によれば、LLMを業務導入した企業の68%が「カスタマイズなしでは実用精度に達しなかった」と回答している。
LLMを企業の業務に適合させる手法として、RAG（Retrieval-Augmented Generation：検索拡張生成）とファインチューニング（Fine-tuning）の2つが代表的である。両者は設計思想が根本的に異なり、適するユースケースも異なる。
手法概要の比較
| 項目 | RAG | ファインチューニング |
|---|---|---|
| 概要 | 外部知識を検索し、プロンプトに付加 | モデル自体の重みを更新 |
| データの扱い | 外部DB/ベクトルストアに保存 | モデルに学習させる |
| ベースモデル変更 | なし（そのまま利用） | あり（重みを更新） |
| 知識の更新 | ドキュメント更新で即反映 | 再学習が必要 |
| 初期構築期間 | 1〜4週間 | 2〜8週間 |
| 運用コスト | 検索基盤の維持費 | 推論コスト（ホスティング） |
| 代表的なユースケース | 社内FAQ、ドキュメント検索 | 文体統一、専門用語理解 |
1. 精度の比較
RAGの精度特性
RAGは、検索された外部ドキュメントをコンテキストとしてLLMに渡す仕組みである。そのため、精度は以下の2要素に依存する。
- 検索精度：適切なドキュメントが検索されるか
- 生成精度：検索結果をもとにLLMが正確な回答を生成するか
| 精度要因 | 影響度 | 対策 |
|---|---|---|
| チャンク分割の質 | 高い | セマンティックチャンキング |
| Embedding モデルの選択 | 高い | 多言語対応モデルの使用 |
| 検索結果のリランキング | 中程度 | Cross-Encoderの導入 |
| プロンプト設計 | 中程度 | Few-shot例の最適化 |
ファインチューニングの精度特性
ファインチューニングは、モデルの内部パラメータを更新するため、特定のタスクやドメインに特化した精度向上が見込める。
| 精度要因 | 影響度 | 対策 |
|---|---|---|
| 学習データの品質 | 非常に高い | データクリーニング・アノテーション |
| 学習データの量 | 高い | 最低500〜1,000サンプル |
| ハイパーパラメータ | 中程度 | 学習率・エポック数の調整 |
| ベースモデルの選択 | 高い | タスクに適したモデルサイズ |
精度比較のまとめ
| シナリオ | RAG | ファインチューニング |
|---|---|---|
| 最新情報への対応 | 優位（即時更新） | 不利（再学習必要） |
| 固有名詞・社内用語 | 良好（検索次第） | 優位（学習済み） |
| 回答の一貫性 | 検索結果に依存 | 高い一貫性 |
| ハルシネーション抑制 | 優位（根拠あり） | 改善されるが残る |
| 複雑な推論 | LLM能力に依存 | タスク特化で向上 |
2. コスト比較
初期構築コスト
| コスト項目 | RAG | ファインチューニング |
|---|---|---|
| データ準備 | $2,000〜$10,000 | $5,000〜$30,000 |
| Embedding生成 | $100〜$500 | - |
| ベクトルDB構築 | $500〜$2,000 | - |
| 学習コスト | - | $500〜$5,000 |
| 開発工数 | 2〜4人月 | 3〜6人月 |
| 合計（概算） | $10,000〜$30,000 | $20,000〜$80,000 |
月間運用コスト
| コスト項目 | RAG | ファインチューニング |
|---|---|---|
| LLM API料金 | $500〜$5,000 | $200〜$3,000 |
| ベクトルDB | $50〜$500 | - |
| ホスティング | - | $200〜$2,000（セルフホスト時） |
| データ更新作業 | $200〜$1,000 | $1,000〜$5,000（再学習時） |
| 月間合計 | $750〜$6,500 | $400〜$10,000 |
RAGは入力トークンが増加するため、API料金が高くなる傾向がある。一方、ファインチューニング済みモデルは短いプロンプトで正確な回答が得られるため、推論コストが抑えられる場合がある。
3. 構築期間の比較
| フェーズ | RAG | ファインチューニング |
|---|---|---|
| 要件定義 | 1週間 | 1〜2週間 |
| データ準備 | 1〜2週間 | 2〜4週間 |
| 開発・構築 | 1〜2週間 | 1〜2週間 |
| テスト・調整 | 1〜2週間 | 2〜4週間 |
| 合計 | 4〜7週間 | 6〜12週間 |
RAGは既存のマネージドサービス（Amazon Bedrock Knowledge Bases、Azure AI Search等）を活用することで、構築期間を大幅に短縮できる。ファインチューニングは、学習データの準備に最も時間がかかる。
4. データ要件の比較
| データ要件 | RAG | ファインチューニング |
|---|---|---|
| 必要データ形式 | ドキュメント（PDF/Word/HTML等） | 入出力ペア（JSON/JSONL） |
| 最低データ量 | 数十ドキュメント | 500〜1,000サンプル |
| データ品質要件 | 中程度 | 高い（アノテーション品質が重要） |
| データ更新頻度 | 随時可能 | 再学習のたびに必要 |
| 機密データの扱い | 外部DBに保存 | モデルに学習される |
データプライバシーの観点
RAGでは、機密データはベクトルDBに保存され、LLMのモデル自体には含まれない。そのため、LLMプロバイダーにデータを送信する際のリスクはプロンプトに含まれる範囲に限定される。
ファインチューニングでは、機密データがモデルの重みに反映される。OpenAIやAnthropicのファインチューニングAPIを使用する場合、学習データをプロバイダーに送信する必要がある。自社環境でのファインチューニング（オープンソースモデル利用）であれば、データを外部に出さずに済む。
5. 運用負荷の比較
| 運用項目 | RAG | ファインチューニング |
|---|---|---|
| ドキュメント更新 | 低負荷（ファイル入替） | 高負荷（再学習） |
| モデル更新対応 | 影響なし | 再ファインチューニング必要 |
| 品質モニタリング | 検索精度の監視 | 出力品質の監視 |
| スケーリング | ベクトルDBのスケール | モデルホスティングのスケール |
| 障害対応 | 検索基盤の復旧 | モデルサービングの復旧 |
ベースモデルがアップデートされた場合、RAGはそのまま新モデルに切り替えが可能である。ファインチューニングの場合は、新モデルに対して再度ファインチューニングが必要となり、その都度コストと工数が発生する。
ハイブリッドアプローチ
実務では、RAGとファインチューニングを組み合わせた「ハイブリッドアプローチ」も採用されている。
| 組み合わせパターン | 説明 | 適するケース |
|---|---|---|
| RAG + ファインチューニング済みモデル | 検索結果をFT済みモデルに渡す | 専門用語が多い業界 |
| RAG + LoRA | 軽量ファインチューニングで文体を調整 | 回答スタイルの統一が必要 |
| ファインチューニング + キャッシュ | FT済みモデルの回答をキャッシュ | 同一質問が多い環境 |
ユースケース別推奨
| ユースケース | 推奨手法 | 理由 |
|---|---|---|
| 社内ナレッジ検索 | RAG | ドキュメント更新が頻繁 |
| カスタマーサポート | RAG | FAQ・マニュアルの即時反映 |
| 法務文書作成支援 | RAG + FT | 専門用語+最新判例の両立 |
| コード生成（社内フレームワーク） | ファインチューニング | 社内コーディング規約の学習 |
| レポート自動生成 | ファインチューニング | 文体・フォーマットの統一 |
| 多言語翻訳（専門分野） | ファインチューニング | 業界特有の翻訳パターン |
まとめ：判断フレームワーク
RAGとファインチューニングの選択は、以下の判断基準で整理できる。
RAGが適するケース：
- データの更新頻度が高い（週次以上）
- 回答の根拠を明示する必要がある
- 構築期間を短く抑えたい
- 機密データをモデルに含めたくない
ファインチューニングが適するケース：
- 出力の文体・フォーマットを統一したい
- 専門用語の理解を深く求める
- 推論コストを抑えたい
- データの更新頻度が低い（月次以下）
多くの企業では、まずRAGから始めて精度を検証し、必要に応じてファインチューニングを追加するアプローチが現実的である。
関連記事
AIの導入でお悩みの方は、ALLFORCESの無料相談をご利用ください。