RAG vs ファインチューニング vs プロンプトエンジニアリング：自社データの適切な活用法

生成AIや大規模言語モデル（LLM）を自社業務へ本格的に組み込む際、最大の設計判断となるのが「自社固有のデータやドメイン知識をどのようにモデルへ反映させるか」という点です。汎用的なLLMは広範な一般知識を有しているものの、社内規程、独自商品仕様、顧客履歴といった非公開データにはアクセスできません。

自社データを反映させる代表的な技術的アプローチとしては、「プロンプトエンジニアリング（コンテキストへの直接注入）」「RAG（検索拡張生成）」「ファインチューニング（追加学習）」の3つが存在します。しかし、それぞれの得意領域や前提条件を取り違え、「知識を追加するために莫大な費用をかけてファインチューニングを試みたが失敗した」「文体や振る舞いを固定したいのにRAGだけで解決しようとして破綻した」といった課題に直面する企業が後を絶ちません。

本記事では、これら3つのアプローチの特性を客観的・技術的な観点から詳細に比較し、自社の要件やリソースに応じた適切な選定基準を提示します。

1. 3つのアプローチの基本概念と役割の違い

まずは各アプローチが「モデルのどの部分に対して作用するのか」という構造的な違いを整理します。

プロンプトエンジニアリング（In-Context Learning）

プロンプトエンジニアリングは、モデルの重みパラメータを変更せず、LLMへの入力プロンプト（システムプロンプトやユーザー入力）に必要な参照データや指示文を直接埋め込む手法です。コンテキストウィンドウの範囲内であれば、ルール、数件の入出力例（Few-shot）、参照ドキュメントを即座に反映させることができます。モデルの再学習や外部検索インフラを必要としないため、最も着手コストが低いアプローチです。

RAG（検索拡張生成）

RAGは、外部のデータベース（ベクトル検索エンジンやリレーショナルDB）に社内文書をインデックス化しておき、ユーザーの質問に関連する情報を検索してプロンプトのコンテキストへ動的に注入する手法です。モデル自体は事前に学習された既存のLLM（Foundation Model）をそのまま使用し、必要な知識のみを実行時に「参照資料」として渡す設計をとります。

ファインチューニング（追加学習・微調整）

ファインチューニングは、数千〜数万件規模の高品質な「指示と期待される回答」のデータセット（LoRA等のパラメータ効率的微調整手法を含む）を用いて、モデルの重みパラメータそのものを微調整・更新する手法です。モデルそのものの言語表現、専門用語の理解、出力形式、特定の思考パターンを恒久的に染み込ませるために用いられます。

2. 徹底比較：5つの重要評価軸

3つのアプローチを技術選定する際には、以下の5つの評価軸から総合的に比較検討することが望ましいとされています。

評価軸	プロンプトエンジニアリング	RAG（検索拡張生成）	ファインチューニング
知識の即時性・更新性	高（即時反映可能）	高（DB更新で即座に反映）	低（再学習・再デプロイが必要）
初期開発・学習コスト	極小（プロンプト設計のみ）	中（検索パイプライン構築）	高（データ作成・GPU学習環境）
必要データの形式と準備負荷	不要または少量テキスト	既存ドキュメント（PDF/Markdown等）	高品質な入出力ペア（JSONL等）
文体・トーン・形式の制御力	中（指示による制約）	低〜中（プロンプト指示に依存）	高（モデル自体に振る舞いが定着）
ハルシネーション抑制と根拠明示	注入情報に依存（中）	高（出典元の明示・引用が可能）	低〜中（学習知識の想起のため幻覚リスク残存）

軸① 知識の鮮度と更新コスト（即時性）

自社データが頻繁に更新される場合、ファインチューニングは適していません。モデルの重みに知識を焼き付ける作業は時間がかかり、日々の規程改定や製品価格の変動に追従させるには都度再学習コストが発生します。一方でRAGは、検索対象のデータベースを更新するだけで、次の推論時から即座に最新データを参照できるため、「動的に変化する知識の提供」において決定的な優位性を持ちます。

軸② 開発および運用のコスト構造

プロンプトエンジニアリングは初期投資が最小である反面、大量のコンテキストを毎回送信すると入力トークンコストが累積します。ファインチューニングは学習データの作成・選別（アノテーション）やGPUリソースの確保に高い初期費用がかかりますが、推論時に余計なコンテキストを渡さずに済むため、長期的には1リクエストあたりのトークン費用を圧縮できる可能性があります。 RAGはその中間であり、ベクトルDBの運用費や検索レイテンシが発生するものの、全体的な費用対効果のバランスが取りやすい構成と評価されています。

軸③ 文体・振る舞い（Behavior）の制御力

社内チャットボットのように「特定のペルソナを厳密に維持したい」「業界固有の難解なフォーマットで常にJSONを出力させたい」「特定のプログラミング言語の構文ルールを徹底したい」というケースでは、ファインチューニングが極めて強力です。プロンプトによる指示だけではプロンプトインジェクションや文脈の長大化によって振る舞いが揺らぎやすいのに対し、モデルの内部表現として定着させることが可能です。

軸④ ハルシネーション抑制と説明責任（Auditability）

業務システムにおいて「なぜその回答が出力されたのか」という根拠（監査証跡）の提示が求められる場合、RAGが最も適しています。RAGは回答生成時に参照したドキュメントの段落やURLを引用情報（Citation）としてユーザーに明示できるため、ファクトチェックが容易であり、ハルシネーションの発生を大幅に抑止できます。

3. 適切な技術選定の判断基準

これらの特性を踏まえると、自社のユースケースに応じて以下のような選定基準を設けることが合理的です。

【判断フロー】
自社データの反映目的は何か？
　├─ 「新しい知識やファクト情報」の参照・更新が中心
　│　　└─ データ量はコンテキスト内に収まるか？
　│　　　　├─ Yes ──> 【プロンプトエンジニアリング】（参照資料を直挿入）
　│　　　　└─ No  ──> 【RAG（検索拡張生成）】（大量文書・高更新頻度）
　│
　└─ 「文体・特殊な推論パターン・厳格な出力形式」の定着が中心
　　　　├─ プロンプトのFew-shotで十分満たせるか？
　　　　│　　├─ Yes ──> 【プロンプトエンジニアリング】
　　　　│　　└─ No  ──> 【ファインチューニング】（高品質データセットを用意）

ケーススタディ

社内FAQ・就業規則検索ボット: 【RAG推奨】 規程の改定が年数回発生し、回答には参照条文の提示が必須となるため、RAGが最も費用対効果と正確性の観点で優位です。
法務契約書の条項分類・定型リスク抽出: 【ファインチューニングまたはハイブリッド】 大量の過去契約書から特定のリスク条項を分類する作業では、分類基準が複雑でプロンプトだけではブレが生じやすいため、過去の判例データを用いたファインチューニングが威力を発揮します。
カスタマーサポート自動返信（ハイブリッド構成）: 近年増えているのが「ハイブリッド型」のアーキテクチャです。ブランドの丁寧な口調や禁則事項の遵守をファインチューニングによって小型モデルに学習させ、個別の製品在庫や最新のトラブルシューティング手順はRAG経由で取得するという組み合わせにより、品質と運用の両立を図る事例が見られます。

まとめ：単一の手法に固執せず段階的な検証を

「RAGか、ファインチューニングか」という二者択一の議論に陥ることは避けるべきです。生成AIシステム開発のベストプラクティスとしては、以下の段階的ステップを踏むことが推奨されます。

第1段階: まずは強力なフロンティアモデルと入念なプロンプトエンジニアリング（Few-shot含む）で要件が満たせるかを検証する。
第2段階: 参照すべきデータ量がコンテキストを超過する場合や、知識のリアルタイム更新・出典明示が必要な場合は、RAGパイプラインを構築する。
第3段階: RAGの検索精度が十分担保されているにもかかわらず、回答の文体制御、特有の推論様式、または小型モデル化によるコスト・レイテンシ削減が至上命題となった段階で、初めてファインチューニングの導入を検討する。

自社が解決したい課題の本質が「知識（Knowledge）の補完」なのか、それとも「振る舞い（Behavior）の適応」なのかを見極めることが、成功への最短ルートと言えるでしょう。