RAG vs ファインチューニング vs ロングコンテキスト — LLM に知識を入れる方法の選択
LLM 導入の検討が少し進むと、必ず出てくる質問があります。「自社のデータをどうやってモデルに入れるのか?」です。選択肢は 3 つです。検索して差し込む RAG、モデルの重みを変えるファインチューニング、ドキュメントを丸ごとプロンプトに入れるロングコンテキストです。結論を先に書くと、変わり続ける事実とドキュメントの知識は RAG がデフォルト、出力形式・口調・ドメインの振る舞いを固定したいときがファインチューニング、知識全体が小さくてあまり変わらないなら、ロングコンテキストにプロンプトキャッシュを重ねるのが最もシンプルな出発点です。 3 つは排他の関係ではなく、組み合わせる対象です。コスト感覚は 2026 年半ば基準です。
ひと目でわかる比較 #
| 区分 | RAG | ファインチューニング | ロングコンテキスト |
|---|---|---|---|
| 方式 | 関連ドキュメントを検索してプロンプトに注入 | 追加学習で重みを修正 | 知識全体をプロンプトに含める |
| 知識の更新 | ドキュメントの追加・修正が即時反映 | 再学習が必要 | プロンプト差し替えで即時反映 |
| 初期コスト | 検索パイプラインの構築 | 学習 1 回 (LoRA で数百ドル台) | ほぼなし |
| 推論コスト | 短いプロンプトを維持 | プロンプト短縮の効果 | ドキュメントのサイズに比例 (キャッシュで緩和) |
| 出典の提示 | 可能 (根拠ドキュメントを引用) | 不可 | 部分的 (ドキュメント内の位置を指示) |
| 適した要件 | 事実・ドキュメントの Q&A | 形式・口調・振る舞いの固定 | 小規模で固定的な知識 |
RAG — 知識を検索して、そのつど注入します #
RAG は、質問が来るたびに関連するドキュメントの断片を検索してプロンプトに付け足す構造です。強みは運用特性から生まれます。ドキュメントを追加すればその瞬間から回答に反映され、どのドキュメントを根拠に答えたかを引用でき、権限ごとに検索範囲を分けるアクセス制御も検索レイヤーで解決します。知識が数百万トークン以上に育っても、プロンプトは検索された数千トークンに一定に保たれるため、推論コストが知識のサイズから切り離されます。
弱点も構造から生まれます。回答品質の上限は検索品質です。必要なドキュメントを見つけられなければ、モデルがどれだけ良くても間違えます。この失敗パターンの診断は RAG 深掘り #1 で扱いました。埋め込み、チャンキング、ベクトルストアという可動部品が増えるのもコストです。パイプラインを最初に作る過程はドキュメント Q&A ボット実戦で扱いました。
ファインチューニング — 知識ではなく、振る舞いを教える道具です #
最もよくある誤解が「自社データでファインチューニングすれば、その内容を知るようになる」です。ファインチューニングで新しい事実を注入するのは非効率で、既存の能力が一部押し出されたり、学習した事実をもっともらしく混ぜてしまう副作用が付いてきます。ファインチューニングが得意なのは振る舞いの固定です。常に指定した JSON スキーマだけで答えさせる、ブランドの口調を保つ、ドメイン特有の分類・抽出の精度を引き上げる、毎回プロンプトに入れていた長い指示文をモデルに畳み込んで遅延とトークンコストを削る、というのが典型です。
コストは思ったより下がりました。重み全体を学習し直す代わりに LoRA・QLoRA で小さなアダプターだけを学習するのが標準になり、オープンウェイトのモデルなら学習 1 回で数百ドル台、マネージド API のファインチューニングは学習トークンあたりの課金(100 万トークンあたり数十ドル台)です。負担はコストより運用です。学習データセットの構築と評価の仕組みが必要で、知識の更新のたびに再学習が要り、自前ホスティングならサービング側の決定(量子化、GPU の調達)が付いてきます。
ロングコンテキスト — 全部入れてキャッシュする、最もシンプルな方法 #
コンテキストウィンドウが数十万〜100 万トークン級に広がったことで、3 つ目の選択肢が実用になりました。社内規定集、製品マニュアル、API ドキュメント程度の知識なら、検索なしでドキュメント全体をプロンプトに入れる構成です。ここにプロンプトキャッシュを重ねると、繰り返しの呼び出しでドキュメント部分の入力トークン料金が大幅に割引され、最初のトークンまでの遅延も減るため、「RAG を作る前にまず全部入れてみる」が合理的な最初の一手になります。
境界条件がはっきりしています。知識全体がコンテキストに余裕を持って収まること(おおよそ数十万トークン以下)、あまり変わらないこと(キャッシュ無効化の防止)、呼び出しパターンが同じドキュメントを繰り返し参照すること — この 3 つがそろってキャッシュが生きます。ドキュメントが育ち続けるとトークンコストが正比例で付いてきて、コンテキストの中間に置かれた情報の回収率が落ちる問題もドキュメントが大きいほど効いてきます。そこが RAG に移るタイミングです。
組み合わせ — 3 つは競合ではなく階層です #
実戦の構成はほとんどが組み合わせです。事実は RAG で、振る舞いはファインチューニングで、小規模で固定的な知識はコンテキストでが基本の配置です。ドキュメント Q&A にはファインチューニングではなく RAG を使い、その RAG の回答形式が崩れ続けるなら形式固定用のファインチューニングを重ね、毎回の呼び出しに共通で入る規則・用語集はキャッシュされたシステムプロンプトに置く、という形です。API で始めるか自前ホスティングに行くかは API vs 自前ホスティングの計算と同じで、ファインチューニングしたモデルは自前ホスティング側に天秤を傾ける変数になります。
選択の手順 #
- 要件が知識なのか振る舞いなのかをまず分けます: 「X を知っている必要がある」なら RAG かロングコンテキスト、「X のように答える必要がある」ならファインチューニングです。この区分ひとつで半分は片付きます。
- 知識のサイズと更新頻度を測ります: 数十万トークン以下 + 更新がまれなら、ロングコンテキスト + キャッシュで始めます。それより大きいか毎日更新されるなら RAG です。
- 出典の提示とアクセス制御の要件を確認します: 根拠の引用、ユーザーごとの閲覧権限が求められるなら検索レイヤーが必要なので、RAG に確定です。
- ファインチューニングは最後に重ねます: プロンプトの指示では形式・口調が保てないと確認してから始めることで、学習データセットへの投資が空回りしません。
- コストは呼び出しパターンで検算します: 呼び出し量 × 平均プロンプトトークンで RAG とロングコンテキストの月額を比較し、ファインチューニングのプロンプト短縮効果が学習コストを相殺する時点を計算します。
まとめ #
- 変わり続ける事実・ドキュメントの知識は RAG、形式・口調・振る舞いの固定はファインチューニング、小規模で固定的な知識はロングコンテキスト + キャッシュです。
- ファインチューニングを知識注入の道具として使うのが、最もよくある間違いです。ファインチューニングが教えるのは事実ではなく振る舞いです。
- ロングコンテキストは、知識が数十万トークン以下で更新がまれなときの最もシンプルな出発点です。ドキュメントが育ったら RAG に移ります。
- RAG の上限はモデルではなく検索品質です。答えが間違っていたら、まず検索から診断します。
- 実戦は組み合わせです。事実は RAG、振る舞いはファインチューニング、共通の規則はキャッシュされたコンテキストという配置から出発します。