RAGとファインチューニングの違い｜再索引か再学習かを選ぶ

RAGとファインチューニングの違いは、回答時に外部資料を検索するか、学習例でモデルの応答傾向を変えるかです。規程、価格、在庫のように変わる知識はRAG、分類、文体、出力形式のように繰り返す振る舞いはファインチューニングが候補になります。どちらも評価データが作れない状態では導入しません。

RAGとファインチューニングは更新対象・出典・正解例で選ぶ

第一の質問は「更新したいものは何か」です。回答に使う規程、製品情報、過去事例を入れ替えたいならRAGを先に比較します。同じ入力でも分類ラベルや書式が安定しないなら、プロンプトと構造化出力を試した後にファインチューニングを検討します。知識と振る舞いの両方が必要なら併用候補ですが、失敗箇所を分離して測れることが前提です。

第二の質問は「回答時に出典を示す必要があるか」です。RAGは取得した文書IDと抜粋を出力へ結び付けやすく、文書の失効や権限も検索時に制御できます。ファインチューニング済みモデルの重みから、特定主張がどの学習例に由来するかを毎回答で示すことは容易ではありません。監査や訂正が必要な知識は外部の正本へ残します。

第三の質問は「正しい学習例を継続して作れるか」です。ファインチューニングには、入力と期待出力を一貫した基準で用意し、未閲覧データで比較する能力が必要です。RAGも評価不要ではなく、質問に対する正しい根拠文書と回答を用意します。どちらも正解を確定できないなら、方式選定を保留し、業務ルールの明文化から始めます。

比較軸を知識・振る舞い・更新・証拠・配備・撤退で定義する

機能名だけで比べず、業務で変えたい対象と保守作業へ軸を置きます。知識はどこに保存され、誰が正本を更新するか。振る舞いは指示、スキーマ、学習のどこで制御するか。更新は文書投入から反映まで何分かかるか。証拠は回答から原文へ到達できるか。配備は検索基盤とモデル基盤のどちらを運用するか。撤退はデータ、索引、アダプター、評価を別環境へ持ち出せるかを確認します。

RAGの原著は、事前学習モデルのパラメトリックな記憶と、検索できる非パラメトリックな記憶を組み合わせる構成を扱っています。arXivの現行版はv4で、2021年4月12日に改訂され、知識更新と出典追跡がパラメーターだけのモデルで課題になることを背景にしています^[1]。原著の実験結果を、自社文書すべてで同じ性能が出る保証として一般化してはいけません。

ファインチューニング側では、全重みを更新する方式と、LoRAのように少数の追加パラメーターを学習する方式を区別します。LoRA原著のarXiv v2は2021年10月16日改訂で、基盤重みを固定し低ランク行列を学ぶ設計を示しています^[2]。比較時は「ファインチューニング」という一列にまとめず、採用する方式と保存物を明記します。

AWS Prescriptive Guidanceの「Comparing Retrieval Augmented Generation and fine-tuning」は、独自文書を根拠付きで扱う質問応答ではRAGから検討する考え方を示しています。別のタスク適応が必要な場合は、ファインチューニングを比較対象にします。両方式の併用も選択肢としています^[6]。同ガイドは2024年10月28日初版のAWS向け資料であるため、本記事では製品の推奨ではなく、更新性・出典・タスク適応を分ける比較軸の補助に使います。

RAGとファインチューニングの違いを保守作業まで一覧にする

OpenAIの現行Vector Stores APIでは、処理済みファイルの集合を検索に利用し、ファイルの追加・削除、検索、処理状態、分割設定を扱います。固定版とページ更新日は明記されていないため、2026年7月30日の仕様確認として参照します^[3]。この仕様は一実装例であり、RAG一般の必須構成ではありません。

比較表の「RAGは知識、調整は振る舞い」は出発点であって絶対境界ではありません。原著RAG自体も学習工程を含み、カスタム学習で専門知識へ適応する方法もあります。業務選定では、更新の頻度、出典、評価可能性、移行負荷を基に、何を外部に残し何をパラメーターへ持たせるかを決めます。

両方式を同じ質問で比べる評価データを四群に分ける

RAGとファインチューニングを公平に比べるには、方式ごとに別の簡単な質問を使いません。実運用から代表質問を集め、現行知識、振る舞い、複合、回答不能の四群へ分けます。想定例として200件なら、現行知識80件、分類・形式60件、検索と形式の両方が必要な複合40件、資料に答えがない20件とします。各ケースに、期待回答、根拠文書ID、許容表現、重大度、期待する保留を付けます。

RAGの検索評価には質問と正解文書の組が必要です。正解文書が複数ある場合は許容集合を定義し、上位k件に一つでも入ればよいのか、特定の二文書を両方取得すべきかを分けます。ファインチューニングの評価では、同じ200件から根拠取得を除いた結果だけを測るのではなく、基盤モデル、最良プロンプト、調整後モデルが同じ入力でどう変わるかを対比較します。

評価データ汚染を共通IDで防ぐ

同じ原文から作った言い換えを、RAGの検索調整用と最終評価へ分けると、分割やキーワードが評価質問へ過度に合います。ファインチューニングでも、同じ顧客案件を学習と評価へ跨がせると、文章を覚えた効果を一般化と誤認します。source_id、customer_id、conversation_id、template_idを持ち、同じグループは開発または最終評価の片側へ寄せます。

検索、根拠、回答、形式、費用を別の式で測る

RAGは検索が失敗すれば生成も失敗するため、検索指標と回答指標を分離します。Recall@kは、正解文書が上位k件に入った質問の割合です。複数文書が必要なら、質問ごとに取得できた正解文書の割合を計算します。根拠支持率は、回答内の検証対象主張が取得文書で支えられた割合です。検索が合格しても、モデルが別の数値を生成すれば回答は不合格です。

検索到達: Recall@k = 正解文書が上位k件に入った質問数 ÷ 検索評価質問数
検索網羅: 文書網羅率 = 取得できた正解文書数 ÷ 必要な正解文書総数
根拠確認: 根拠支持率 = 根拠で支持された主張数 ÷ 検証対象主張数
形式確認: 形式一致率 = スキーマを満たした出力数 ÷ 評価出力数
安全確認: 重大誤り率 = 重大誤りを含むケース数 ÷ 評価ケース数
費用確認: 受入一件当たり費用 = (検索費 + 推論費 + 人件費 + 運用費) ÷ 受入件数

200件の想定評価で、RAGの正解文書取得が170件ならRecall@kは85.0%です。その170件中、回答まで正しいものが150件なら、検索成功後の回答正解率は88.2%ですが、全体の回答正解率は75.0%です。調整後モデルが形式一致190件でも、知識質問で重大な旧情報を5件答えたなら、形式点で相殺しません。

NIST AI 600-1は、生成AIに固有のリスクを組織の目的に応じて測定・管理するための横断的プロファイルです。2024年7月26日公開、案内ページ2026年4月8日更新で、特定のRAG合格率や学習件数を規定してはいません^[5]。本記事の母数と閾値は比較方法を示す想定例です。

ケース別にRAG、ファインチューニング、併用、見送りを選ぶ

RAGを優先するケースは、就業規則、商品仕様、価格表、保守記録など、正本が存在し、改訂や削除があり、回答時に版と出典を示したい業務です。文書のアクセス権を検索条件へ反映し、失効版を除外します。検索評価を作れないほど文書管理が乱れている場合は、索引構築より正本整理を先に行います。

ファインチューニングを比較するケースは、同じ情報を与えても12分類の境界が揺れる、指定JSONの項目が欠ける、社内の校閲基準に沿った指摘順が安定しないなど、応答傾向に反復した不良がある業務です。プロンプトとスキーマ検証で目標を満たせないこと、正しい例を十分に作れること、未閲覧データで改善することが条件です。

併用するケースは、最新規程を検索し、その内容を決められた分類と形式で返す業務です。RAGが根拠を取得し、調整済みモデルが形式を整えます。検索に失敗したとき、モデルが記憶だけで埋めないよう、根拠不足なら保留する制御を加えます。検索指標と形式指標の責任者も分けます。

見送るケースは、正本も正解例もなく、担当者の判断が一致しない業務です。将来予測や単一正答のない経営判断に、200件の正解率を無理に作りません。まず判断材料、責任者、許容される提案範囲を定義し、人の意思決定支援として小さく試します。

基盤モデル、RAG、調整、併用を一条件ずつ比較する

比較実験では、基盤モデルと最良プロンプトをA、RAG追加をB、ファインチューニングをC、併用をDとします。モデル版、温度、出力上限、評価200件、採点規則を固定します。Bでは検索設定だけ、Cでは学習済みモデルだけを変え、DはBとCの合格候補を組み合わせます。一度に検索、モデル、プロンプトをすべて変えると改善要因が分かりません。

1. 問いと目標を固定する：主要検索意図、利用者、完了条件、重大誤りを一つの比較票へ記載します。
2. Aを測る：基盤モデルに最良プロンプトを使い、四群のケース別結果を保存します。
3. Bを測る：正本を索引し、検索と回答を分けて採点します。
4. Cを測る：最終評価を学習から隔離し、同一入力で基盤との差を取ります。
5. Dを測る：検索失敗時の保留と、形式の安定が同時に働くか確認します。
6. 費用と時間を実測する：索引更新、再学習、人の確認、障害復旧を含めます。
7. 限定運用へ進める：重大条件を通過した最小構成だけを選び、旧経路を残します。

比較は全体平均だけでなく、ケースごとの勝敗を見ます。Bだけ正しい知識質問、Cだけ正しい形式質問、Dで新たに失敗した複合質問を抽出します。併用が最高点でも、運用費や原因調査時間が増え、単独方式が目標を満たすなら、より単純な構成を採用できます。

併用時は検索担当・生成担当・業務承認者の責任を分ける

検索担当は正本の投入、分割、メタデータ、権限、失効、再索引、Recall@kを管理します。生成担当は基盤モデル、指示、アダプター、出力スキーマ、根拠不足時の保留、回帰評価を管理します。業務承認者は正解定義、重大度、利用範囲、例外承認、再開判断を担います。一人が兼務しても、記録上の役割は分けます。

モデルが内部知識で正しく答えたように見えても、RAG業務では取得文書がなければ合格にしない設計が必要です。正解だが根拠のない回答を許すと、次の改訂後に古い記憶で答えても検知できません。併用の価値は、二方式を載せることではなく、知識の正本と応答傾向を別々に更新できる点にあります。

データ汚染を監視し、再索引と再学習のトリガーを分ける

RAGの汚染には、旧版と新版の同時投入、権限属性の欠落、テスト用文書の本番混入、評価質問をそのまま文書へ書くことがあります。ファインチューニングの汚染には、最終評価の学習利用、同一案件の跨ぎ、誤ラベル、モデル出力を未確認で正解にすることがあります。データ台帳は原文と学習例で別に持ち、共通のsource_idで関係を追います。

再索引のトリガーは、文書の発効・失効、権限変更、分割方法や埋め込みの変更、投入失敗の修復です。差分索引後に件数、失敗、版、権限を照合し、検索評価を実行します。再学習のトリガーは、同じ応答不良の増加、分類基準の改訂、基盤モデルの変更です。追加データを監査し、全評価と安全試験を経て配備します。

変更判定
if 正本・版・権限・分割が変わった:
    文書を更新し、必要範囲を再索引する
    Recall@k と権限テストを再実行する
if 分類・形式・応答方針が変わった:
    ラベル定義と学習データを改版する
    再学習候補を基盤モデルと比較する
if 両方が変わった:
    先に検索を合格させ、次に生成を評価する

保守後は変更した側だけでなく、もう一方の退行も確認します。再索引で長い文脈が増えると形式が崩れ、再学習で検索結果を無視する傾向が強まる可能性があります。併用構成では、検索合格かつ回答不合格、検索不合格かつ回答断定という組合せを監視します。

乗り換えコストはデータ変換、再評価、並行稼働、撤去まで見積もる

RAGの移行では、原文、メタデータ、アクセス権、分割、埋め込み、索引API、検索フィルターを移します。原文は持ち出せても、索引形式が独自なら再埋め込みと全検索評価が必要です。ファインチューニングの移行では、学習データ、基盤モデル、トークナイザー、前処理、アダプター、学習設定、評価を確認します。異なる基盤へアダプターだけを載せ替えられるとは限りません。

OpenAIは2026年5月8日の公式更新で、同社ファインチューニング基盤の段階的縮小、新規利用者の受付停止、既存モデルの推論を基盤モデル廃止まで継続する方針を示しました^[4]。これは、比較表に提供継続と基盤廃止を入れる必要性を示す現行事例です。特定企業の事情をファインチューニング一般の終了とは解釈しません。

移行総工数 =
  データ棚卸し
  + 形式変換
  + 再索引または再学習
  + 全評価
  + 権限・安全試験
  + 並行稼働
  + 利用者教育
  + 旧環境の証跡保管と撤去

想定例として200件の全評価を一件8分で人が確認すると、26.7時間です。二方式を並行比較すれば確認だけで53.3時間になり、データ変換や障害対応は別です。移行費用をAPI利用料だけで計算せず、専門担当の確認時間と旧環境の保持期間を加えます。

更新頻度・処理件数・確認単価を変えて費用の感度を比べる

RAGとファインチューニングの費用差は、初期構築費だけでは決まりません。RAGは文書の投入、再索引、検索評価、権限管理が継続します。ファインチューニングはラベル作成、学習、全評価、再配備、基盤モデル変更への追随が発生します。併用では両方が必要ですが、人の確認を減らせるなら業務費用が下がる可能性があります。比較期間を12か月などに固定し、同じ処理件数と品質目標で計算します。

RAGの12か月費用 =
  初期文書整備 + 検索構築
  + 月次(投入・索引・検索利用・検索評価)
  + 障害復旧 + 人の回答確認
調整モデルの12か月費用 =
  データ作成 + 初回学習 + 配備
  + 再学習回数 × (追加ラベル・学習・全評価・再配備)
  + 推論利用 + 退行確認 + 移行準備
併用の12か月費用 =
  RAG費用 + 調整費用 - 共通化できる評価・確認費

想定例として、文書改訂が毎月100件、応答方針の変更が年1回なら、知識更新を再学習へ寄せるほど再評価負荷が増えます。反対に、文書は年1回しか変わらず、月5万件の分類形式を人が直しているなら、調整で一件当たり確認時間を減らす効果が大きくなる可能性があります。この例は実績値ではなく、更新頻度と処理量が方式選択を変えることを示します。

一つの前提だけで結論を出さず、低位・標準・高位の三シナリオを作ります。例えば月間質問数が標準の半分でも回収できるか、再学習が年4回へ増えても運用できるかを確認します。費用差が小さい場合は、出典、権限、切り戻し、提供終了への強さを優先します。最安値の方式が、事故時に原因を追えず高い復旧費を生むなら、総費用では安くありません。

損益分岐は削減時間を実測してから求める

調整や併用によって一件の人手確認が3分短くなり、月2万件、担当者の一時間当たり人件費を4,000円とする想定なら、月間削減額は3分×2万件÷60×4,000円で400万円です。ただし、完全に削減できた時間だけを使い、待ち時間や別作業へ移った時間を二重に計上しません。月間の追加運用費が150万円、初期追加費が1,000万円なら、単純回収月数は1,000÷(400-150)で4か月です。品質低下や事故損失がある場合は回収計算を停止し、足切り条件を優先します。

標準シナリオだけが4か月で、処理件数が半分の低位シナリオでは追加運用費を差し引いた削減額が月50万円になり、回収は20か月へ延びる想定です。契約期間や基盤モデルの提供見通しが20か月より短いなら採用根拠は弱くなります。反対に、品質を保ったまま重大案件の確認時間まで短縮できるかは、金額換算だけでなく未閲覧評価と限定運用で確かめます。

感度表は四半期ごとに実績で更新します。文書改訂、再索引失敗、再学習、確認時間、事故復旧の実数を入れ、当初の想定から20%以上ずれた費目は採用方式の継続判断へ戻します。

採否は更新性・根拠・品質・運用・撤退の評価票で決める

評価票を使う前に、重大誤り0件、権限違反0件、評価データの直接汚染0件、正本と学習データの利用権限確認、切り戻し成功を足切りにします。一項目でも外れれば、合計点が高くても限定運用へ進めません。

想定判定は90点以上を限定運用候補、80〜89点を追加検証、79点以下を見送りとします。RAG単独が91点、併用が94点でも、目標が90点で併用の運用負荷が大きいならRAG単独を選べます。最高点ではなく、足切りと必要点を満たす最小構成を採用します。

正本も正解例もない案件と、原因を分離できない併用は向かない

向かないケースは、参照すべき資料が確定しておらず、期待出力も担当者ごとに異なる案件です。RAGは矛盾した文書を検索し、ファインチューニングは矛盾した例を学習します。文書所有者、ラベル定義、例外判断者を決められない間は、AI方式の比較より業務整理を優先します。

比較または運用を停止する条件：

• 権限外文書を一件でも取得し、回答またはログへ表示した
• 失効版の回答利用、または重大な学習退行が最終評価で見つかった
• 評価質問や同一案件が索引調整・学習と最終評価の両方へ混入した
• 再索引後の件数・失敗、または再学習後のデータ版を追跡できない
• サービス終了や基盤廃止に対する移行・手動経路を用意できない

権限漏えいは情報セキュリティ、学習データの権利は法務・個人情報保護、正本の矛盾は業務部門、提供終了と移行は調達・技術責任者へ引き継ぎます。検索担当だけでモデルを再学習せず、学習担当だけで文書を再投入せず、原因層の所有者が変更と再評価を承認します。

次に取る行動：20件を知識不良と振る舞い不良へ分ける

現在失敗している案件を20件選び、正しい資料が入力にない「知識不良」と、正しい資料があるのに形式や分類が崩れる「振る舞い不良」へ分けます。前者は小さな索引、後者はプロンプト改善で再試験し、同じ評価票に結果を記録します。この二つで目標を満たさない理由が明確になってから、再学習または併用へ進みます。

参考文献・一次情報

1. Patrick Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” arXiv:2005.11401v4, 2021年4月12日改訂（2026年7月30日参照）。
2. Edward J. Hu et al., “LoRA: Low-Rank Adaptation of Large Language Models,” arXiv:2106.09685v2, 2021年10月16日改訂（2026年7月30日参照）。
3. OpenAI, “Vector Stores API Reference,” ページ上の固定版・更新日表記なし（2026年7月30日参照）。
4. OpenAI, “Introducing improvements to the fine-tuning API and expanding our custom models program,” 2024年4月4日公開、2026年5月8日提供縮小情報を追記（2026年7月30日参照）。
5. NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1, 2024年7月26日公開、案内ページ2026年4月8日更新（2026年7月30日参照）。
6. AWS Prescriptive Guidance「Comparing Retrieval Augmented Generation and fine-tuning」（ガイド初版2024年10月28日、2026年7月31日参照）。RAGとファインチューニングの比較、および単独・併用の選定軸を確認するために使用。