最初に結論を述べます。RAG（検索拡張生成）とファインチューニング（追加学習）は、競合する選択肢ではありません。「解いている問題」が違います。 RAGは「知識・事実をAIに注入する」技術、ファインチューニングは「振る舞い（文体・出力形式・口調）をAIに教え込む」技術です。そして、企業が「うちはファインチューニングが必要だ」と考えるケースの多くは、実はRAGで解ける——最新の社内知識や商品情報に基づいて正しく答えてほしいだけ、というものだからです。費用対効果の観点では、まずRAGで本番化し、その効果と限界が見えてから、必要ならファインチューニングを足す——この順番が正解です。
本記事は、私がRAGで「専門商材の誤答を構造的に排除」した音声接客AIを本番運用した経験をもとに、両者の違い・費用構造・判断軸を、発注者・意思決定者の視点で整理します。これは生成AI導入のコストシリーズの一篇です。
1. 両者は「解く問題」が違う
最初に、この区別を腹落ちさせてください。ここを取り違えると、不要な投資をします。
| RAG（検索拡張生成） | ファインチューニング（追加学習） | |
|---|---|---|
| 何をするか | 質問時に関連知識を検索して渡す | モデルの重みを追加学習で更新する |
| 解く問題 | 「正しい事実・知識で答えさせたい」 | 「特定の文体・形式・振る舞いにしたい」 |
| 知識の更新 | データを差し替えれば即反映 | 再学習が必要（更新のたびにコスト） |
| 出典の提示 | できる（どの文書を根拠にしたか追える） | 難しい（重みに溶け込む） |
| 幻覚（誤答）対策 | 強い（根拠を渡せる） | 弱い（知識は教えられるが古くなる） |
たとえるなら——RAGは「カンペを持たせて答えさせる」、ファインチューニングは「話し方そのものを訓練する」。商品情報や社内規程のように変わり続ける知識を正しく扱いたいなら、訓練（ファインチューニング）ではなく、最新のカンペ（RAG）を渡すべきです。
私が構築した音声接客AIは、まさにこれでした。店舗の専門商材について正確に答える必要がありましたが、商品情報は変わり続けます。これをファインチューニングで教え込むと、商品が変わるたびに再学習が必要で、現実的ではありません。そこで**RAG（pgvector / Bedrock）で商品知識を検索して根拠として渡し、「誤答を構造的に排除」**する設計にしました。応答は約1.5秒、知識の更新はデータの差し替えだけで済みます。
2. 費用構造の違い
費用対効果を判断するために、両者のコスト構造を分解します。
RAG のコスト
- 検索インフラの運用費——ベクトルDB（pgvector / Pinecone 等）やハイブリッド検索の運用、埋め込み生成の費用。
- 推論時のトークン増——検索した知識をプロンプトに乗せる分、入力トークンが増える（=API利用なら従量課金が増える）。
- 初期構築——文書の取り込み・分割（チャンク化）・索引付けのパイプライン整備。
ポイントは、知識の更新に追加の学習コストがかからないこと。データを差し替えれば即反映されます。変化の速い知識ほど、RAGの費用対効果が際立ちます。
ファインチューニングのコスト
- 学習の初期費——データセットの準備（ここが最も重い。良質な教師データ作成は高コスト）、GPU学習費。
- 知識更新ごとの再学習費——情報が変わるたびに、原則やり直し。
- 評価・検証費——学習で性能が落ちていないか（破滅的忘却など）の検証。
一方で、ファインチューニングにはRAGにはない利点もあります。プロンプトに知識を毎回乗せる必要がないので、推論時のトークンが減り、低遅延・低単価になりうる。さらに、大きなモデルの振る舞いを小さく安いモデルに蒸留できれば、本番の推論コストを構造的に下げられます。これは大量・常時稼働のワークロードで効いてきます。
3. 判断フレームワーク：まずRAG、必要ならファインチューニング
費用対効果を最大化する判断は、次のフローです。
AIに「最新の事実・知識」で正しく答えてほしい？
└─ Yes → RAG（知識を検索して渡す。更新はデータ差し替えで即反映）
それに加えて、次のどれかが「明確な要件」か？
├─ 特定の文体・口調・出力形式を徹底したい → ファインチューニング
├─ ドメイン特有の言語・専門用語を深く理解させたい → ファインチューニング
├─ 推論の遅延・単価を下げたい（プロンプトを短く）→ ファインチューニング/蒸留
└─ いずれも不明確 → RAG だけで十分。ファインチューニングは見送る
判断をコードで表すと、こうなります。要件を型で表現し、取りこぼしをなくす設計です。
/** AI適応の要件。各フラグは「明確な要件か」をブール値で表す（曖昧なら false）。 */
interface AdaptationRequirements {
/** 最新の事実・社内知識に基づいて答える必要があるか */
readonly needsFreshKnowledge: boolean;
/** 特定の文体・口調・出力形式を徹底する必要があるか */
readonly needsConsistentStyle: boolean;
/** ドメイン特有の言語・専門用語の深い理解が必要か */
readonly needsDomainLanguage: boolean;
/** 推論の低遅延・低単価が事業要件として必須か（プロンプト短縮・蒸留） */
readonly needsLowLatencyOrCost: boolean;
}
type Recommendation = "rag-only" | "rag-then-fine-tune" | "fine-tune-led";
/** 「まずRAG」を基本線に、ファインチューニングが正当化される時だけ足す。 */
export function recommendApproach(req: AdaptationRequirements): Recommendation {
const fineTuneSignals =
Number(req.needsConsistentStyle) +
Number(req.needsDomainLanguage) +
Number(req.needsLowLatencyOrCost);
// 知識が要るのにRAGがない構成は危険（幻覚の温床）。知識要件は常にRAGで満たす。
if (req.needsFreshKnowledge) {
return fineTuneSignals > 0 ? "rag-then-fine-tune" : "rag-only";
}
// 知識更新が要らず、振る舞い要件だけが強いならファインチューニング主導もありうる
return fineTuneSignals >= 2 ? "fine-tune-led" : "rag-only";
}
このロジックの背骨は、**「知識が要るなら必ずRAGを基盤に置く」**ことです。ファインチューニングは、その上に「振る舞い」を足すための選択肢として、要件が明確なときだけ採用します。
4. 「ファインチューニングが必要」という思い込みの正体
現場でよく聞くのが、「うちの業務は特殊だから、AIをファインチューニングしないと使えない」という声です。しかし、深掘りすると、その大半は**「最新の社内知識・商品情報・規程に基づいて正しく答えてほしい」**という要望です。それは——RAGで解ける問題です。
ファインチューニングが本当に必要なのは、次のような「振る舞い」の要件があるときだけです。
- 出力形式の徹底——常に決まったJSON構造・帳票フォーマットで返させたい（ただし、これも構造化出力（制約付きデコード）で解けることが多い）。
- 特定の文体・ブランドボイス——大量の例で「らしさ」を一貫させたい。
- ドメイン言語の深い理解——一般モデルが苦手な専門領域の語彙・推論。
- コスト/遅延の最適化——大きなモデルの振る舞いを小さなモデルに蒸留して、本番単価を下げたい。
「特殊な業務だからファインチューニング」ではなく、「特殊な振る舞いが要るからファインチューニング」。この区別が、不要な学習投資を防ぎます。多くの場合、まずRAGで本番化すれば、ファインチューニングなしで十分な品質に届きます。
5. 発注者のためのチェックリスト
「AIを自社向けにカスタマイズしたい」という要望を、適切な投資判断に落とし込むための質問です。
RAG / ファインチューニング 発注チェックリスト
- 解きたいのは「知識」か「振る舞い」か——最新の事実で答えさせたいなら、まずRAG。
- ベンダーが「まずRAG」を提案できるか——いきなりファインチューニングを勧める相手は、コストを膨らませる可能性。
- 知識の更新頻度を確認したか——頻繁に変わる知識をファインチューニングで教えるのは、再学習コストの罠。
- 出典・根拠を追えるか——RAGなら「どの文書を根拠に答えたか」を提示でき、誤答時の原因究明ができる。
- 評価（精度測定）の仕組みがあるか——RAGでもファインチューニングでも、効果を数字で測れないと投資判断ができない。
私の立ち位置: 私は、AI適応の要望をまず「知識 vs 振る舞い」で切り分け、ほとんどのケースでRAGによる本番化から始めます。音声接客AIでは、RAGで専門商材の誤答を構造的に排除し、知識更新をデータ差し替えだけで回せる設計にしました。ファインチューニングや蒸留は、文体・低遅延・原価といった要件が明確になってから、費用対効果を測って足します。
よくある質問（FAQ）
Q. RAGとファインチューニング、どちらを選ぶべきですか？
解きたい問題で決まります。最新の事実・社内知識に基づいて正しく答えてほしいなら、まずRAG。特定の文体・出力形式・ドメイン言語を徹底したい、または推論の遅延・単価を下げたいなら、ファインチューニングを足します。両者は競合ではなく、RAGを基盤に、必要なら振る舞いをファインチューニングで補う、という関係です。
Q. 「うちの業務は特殊だからファインチューニングが必要」では？
その多くは、実はRAGで解けます。「特殊な業務」の正体が「最新の社内知識・商品情報で答えてほしい」なら、それは知識の問題でRAGの領域です。ファインチューニングが本当に必要なのは、特定の文体・出力形式・ドメイン言語の徹底や、コスト/遅延の最適化といった「振る舞い」の要件があるときだけです。
Q. 費用はどちらが安いですか？
知識が変わり続けるならRAGが圧倒的に有利です。RAGは知識更新がデータ差し替えだけで済む一方、ファインチューニングは情報が変わるたびに再学習コストがかかります。逆に、知識が安定していて大量・常時稼働なら、ファインチューニング（特に小さなモデルへの蒸留）で推論単価を下げられる場合があります。まずRAGで本番化し、効果と限界を見てから判断するのが費用対効果を最大化します。
Q. RAGでも間違った答え（幻覚）は出ますか？
出ることがあります。RAGは「根拠を渡す」ことで誤答を大幅に減らせますが、検索の精度が低い・根拠がプロンプトに正しく反映されない・アクセス制御が甘い、といった本番特有の落とし穴があります。これらを設計で潰すことが重要で、別記事「本番RAGの落とし穴」で詳説します。
Q. ファインチューニングはやめた方がいいのですか？
いいえ。要件が明確なら有効です。文体・出力形式の徹底、ドメイン言語の理解、そして大きなモデルの振る舞いを小さく安いモデルに蒸留して本番単価を下げる——これらはファインチューニングの得意領域です。重要なのは順番。まずRAGで本番化し、残った「振る舞い」の課題に対して、費用対効果を測ってファインチューニングを足すことです。
まとめ：知識はRAG、振る舞いはファインチューニング
AI適応の投資で損をしないために、押さえるべきは次の通りです。
- RAGとファインチューニングは「解く問題」が違う——知識の注入か、振る舞いの教え込みか。
- 「ファインチューニングが必要」の多くは、実はRAGで解ける——変わり続ける知識はRAGで。
- コスト構造が違う——RAGは更新が即時で安い、ファインチューニングは再学習費がかかる。
- ファインチューニングは「振る舞い」要件が明確な時だけ——文体・形式・ドメイン言語・蒸留。
- まずRAGで本番化し、必要ならファインチューニングを足す——この順番が費用対効果を最大化する。
「AIを自社向けに賢くしたい」「ファインチューニングすべきか相談したい」——その判断こそ、費用対効果を大きく左右します。要件を「知識 vs 振る舞い」で切り分け、最小の投資で最大の効果を出す設計を、本番運用品質でお引き受けします。