RAGとファインチューニングの違いは？選び方を解説【2026】

PR：本記事にはアフィリエイト広告（プロモーション）を含みます。

RAGとファインチューニングは、解いている問題が違います。モデルが知らない情報や古い情報を参照させたいならRAG、出力の形式や口調、指示の守り方を安定させたいならファインチューニングです。2026年時点では、知識を足す用途の第一候補はRAGであり、選択肢には「プロンプトに全部入れる」長文コンテキストも加わります。

3つは順番に試す手順ではなく、別々の問題に対する別々のレバーです。判断は、更新頻度・データ量・コストと遅延・出典提示の要否・権限管理・評価のしやすさの6点で行います。

3択の使い分け（結論）

RAG：モデルが知らない情報を、外側から参照させたいとき
ファインチューニング：出力の形式・口調・指示追従を揃えたいとき
長文コンテキスト：参照させたい情報が小さく、更新も少ないとき

Contents

RAGとファインチューニングはどちらを選ぶべきか？
RAGとファインチューニングは何が違うのか？
どちらを選ぶかは何で判断するのか？
長文コンテキストに全部入れれば済むのではないか？
ファインチューニングはいま選ぶ価値があるのか？【2026年の状況】
RAGとファインチューニングは併用できるのか？
よくある質問
まとめ

RAGとファインチューニングはどちらを選ぶべきか？

知識が足りないならRAG、振る舞いが安定しないならファインチューニングです。OpenAIは公式ドキュメント「Optimizing LLM Accuracy」で、精度向上を「文脈の最適化」と「モデルの最適化」の2軸で整理しています。どちらの軸に問題があるかで手段が決まります。

文脈の最適化（context optimization）が必要になる条件を、OpenAIは3つ挙げています。①モデルが学習データに含まれない知識を欠いている、②知識が古い、③専有情報の知識を必要とする。この軸が最大化するのは応答の正確さ（response accuracy）であり、RAGはここに効く手段です。

モデルの最適化（LLM optimization）が必要になる条件も、同じドキュメントで3つ挙げられています。①出力が一貫せずフォーマットが崩れる、②トーンや話し方が意図と違う、③推論の手順が一貫して守られない。この軸が最大化するのは振る舞いの一貫性（consistency of behavior）であり、ファインチューニングが効くのはこの軸です。

重要なのは、OpenAIがこの2つを「線形の手順」ではなく2軸の行列として示している点です。RAGを試してから次にファインチューニングへ進む、という順番の話ではありません。自分の困りごとがどちらの軸にあるかを先に決めると、検討すべき手段が1つに絞れます。

両方の軸に問題があるケースもあります。社内文書を参照させたい（文脈の問題）うえに、回答フォーマットも揃えたい（振る舞いの問題）という場合です。この構造から考えると、併用は例外ではなく2軸フレームの自然な帰結になります。

RAGとファインチューニングは何が違うのか？

RAGはモデルの外側に参照先を足す仕組み、ファインチューニングはモデル自身を学習データで更新する仕組みです。RAGは参照する文書を差し替えれば挙動が変わり、ファインチューニングは学習し直さないと変わりません。この「どこを書き換えるか」の違いが、運用上の差のほとんどを生みます。

RAGの出典は、Lewis らが2020年5月にarXivへ投稿した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」です。同論文はRAGを、事前学習済みのパラメトリックメモリと非パラメトリックメモリを組み合わせて言語生成を行うモデルとして定義しています。

パラメトリックメモリはモデルの重みに蓄えられた知識、非パラメトリックメモリは外部に置かれた検索対象の文書群を指します。RAGが外側に足す仕組みだという説明は、後者を差し替え可能な形でモデルの外に置くという構造を指しています。

ファインチューニングは、入力と理想的な出力の組を与えてモデルの重みを更新する手法です。OpenAIの「Supervised fine-tuning」ドキュメントは、この手法が適する用途として、分類、ニュアンスのある翻訳、特定フォーマットでの生成、指示追従の失敗の修正を挙げています。いずれも知識の追加ではなく、振る舞いの調整です。

観点	RAG	ファインチューニング
更新のしやすさ	参照文書を差し替えれば反映される	再学習しないと変わらない
必要なデータ	参照させたい文書そのもの	入力と出力の組（OpenAIは最小10件）
出典の提示	参照した文書を回答に添えられる	重みに溶けるため提示できない
得意な問題	知識不足・情報の陳腐化	形式・口調・指示追従のばらつき

RAGの内部構造（検索・チャンク分割・生成の流れ）は本記事の対象外です。仕組みの詳細はRAGとはなにか？なぜ企業活用で必須なのか？で解説しています。本記事は、その1階層上にある「RAGを採るかどうか」を扱います。

どちらを選ぶかは何で判断するのか？

判断軸は6つです。更新頻度、データ量、コストと遅延、出典提示の要否、権限管理、評価のしやすさ。このうち「毎日更新される」「誰が見てよい情報かが分かれている」「回答に根拠を添える必要がある」のいずれかに当てはまるなら、RAG側が有力になります。

1. 更新頻度。 参照させたい情報が日次・週次で変わるならRAGが向きます。RAGは参照先の文書を差し替えるだけで次の回答から反映されるのに対し、ファインチューニングは学習データを作り直して再学習する工程が挟まるためです。逆に、年単位で変わらない社内ルールのような情報であれば、更新頻度は判断材料になりません。

2. データ量。 「ファインチューニングには大量のデータが必要」という前提は、現行の仕様と合っていません。OpenAIの公式ドキュメントは、与えられる最小の例数は10件であり、50〜100件で改善が見られると記載しています。同ドキュメントはまず50件のよく練られた実例から始めて結果を評価することを推奨しており、数万件を用意しないと始められない手法ではありません。

3. コストと遅延。 RAGは検索処理とプロンプトへの文書挿入が毎回発生するため、1リクエストあたりのトークン量と応答時間が増えます。ファインチューニングは学習時に初期コストがかかる代わりに、推論時のプロンプトを短くできます。RAG側で見落とされやすいのは、参照データを整える工数です。

参照データの整備は、RAGを選んだ後に効いてくる継続的なコストです。具体的な作業はRAGにおけるデータクレンジングの重要性で扱っています。

4. 出典提示の要否。 回答に「どの文書に基づくか」を添える必要があるならRAG一択です。RAGは検索した文書を手元に持ったまま回答を生成するため、参照元をそのまま提示できます。ファインチューニングは学習内容が重みに分散するため、この仕組みから考えると、出力の根拠となった学習例を特定して示すことはできません。

5. 権限管理。 閲覧できる情報が人によって違う場合、RAGが向きます。RAGは検索の段階で参照可能な文書を絞れるため、アクセス制御を文書単位で効かせられるためです。ファインチューニングは学習データが重みに焼き込まれる構造上、後から「この利用者にはこの情報を見せない」という切り分けを入れることができません。

6. 評価のしやすさ。 RAGは「正しい文書を取れたか」と「取れた文書から正しく答えたか」を分けて測れるため、精度が出ないときの切り分けがしやすい構造です。ファインチューニングは最終出力でしか評価できず、改善の当たりをつけにくくなります。

RAGの精度は、検索段階でどの方式を採るかに大きく左右されます。方式ごとの向き不向きはベクトル検索とは？仕組みとRAGでの役割で整理しています。

長文コンテキストに全部入れれば済むのではないか？

済む場合があります。Anthropicは「Introducing Contextual Retrieval」で、知識ベースが20万トークン（約500ページ）未満ならRAGを使わずプロンプトに全部入れてよいとしています。ただし同社は、コンテキストが伸びるほど想起精度が落ちる現象も指摘しています。

Anthropicは同記事で、プロンプトキャッシュがこの方式を現実的にしたと説明しています。同社の計測では、プロンプトキャッシュによって遅延は2倍以上短縮され、コストは最大90%削減されます。全文をプロンプトに入れる方式が毎回高くつくという前提は、キャッシュの有無で変わります。

なお20万トークンという数値は、Anthropic自身のモデルを前提とした記述です。扱えるコンテキスト長はモデルによって異なるため、自分が使うモデルの上限に読み替えて判断します。

反対側の錘も同じ発行元が示しています。Anthropicは「Effective context engineering for AI agents」（2025年9月29日公開）で、コンテキストウィンドウ内のトークン数が増えるほど、モデルがその情報を正確に想起する能力は低下すると述べています。同記事はこの性質について、劣化の緩やかさに差はあるものの全てのモデルで現れると書いています。

同記事はさらに、LLMには大量のコンテキストを解釈する際に消費する「attention budget（注意の予算）」があるとしています。新しいトークンを1つ入れるたびにこの予算は目減りするため、コンテキストは無制限に使える置き場ではなく有限の資源として扱う、というのが同社の立場です。

この2つを並べると判断の落とし所が見えます。参照させたい情報が小さく、更新が少なく、利用者全員に全文を見せてよいなら長文コンテキストで足ります。情報が大きい、頻繁に更新される、閲覧権限が分かれる、のいずれかに当てはまるならRAGを選ぶ、という切り方がこの仕組みから導けます。

私の実務でも、RAGにすべてを任せるのではなく、段階的なコンテキスト注入でAIを制御するアプローチが必要になってきています。単にRAGに探させるだけでなく、何をコンテキストウィンドウに入れるかを設計することが重要です。

検索のさせ方にも選択肢があります。Claude Codeのように、エージェントがGrepで必要な箇所を持ってくる挙動もあり、構造化されたデータではエージェントに探させるアプローチの方が精度が出る場合もあるというのが私の実感です。ベクトル検索としてのRAGは、大量のドキュメントを横断して探す用途で有効性が高くなります。

ファインチューニングはいま選ぶ価値があるのか？【2026年の状況】

価値はありますが、用途が絞られました。OpenAIは自社のファインチューニングプラットフォームを縮小しており、新規ユーザーはプラットフォームを利用できません。知識を足す目的での第一候補ではなくなった一方、出力形式や分類など振る舞いを揃える用途では引き続き有効な手段です。

OpenAIの「Supervised fine-tuning」ドキュメントは、現況を3点に分けて記載しています。①プラットフォームは新規ユーザーには開放されていない、②既存ユーザーは今後数か月はトレーニングジョブを作成できる、③ファインチューニング済みモデルは、そのベースモデルが廃止されるまで推論に利用できる。すでに稼働しているモデルが即座に止まるわけではありません。

これはOpenAI1社の動きであり、ファインチューニングという手法そのものが終わったという話ではありません。クラウド各社が提供するマネージドのファインチューニング機能や、オープンウェイトモデルに対する追加学習の手段は別に存在します。どのモデルを土台に据えるかという判断は企業でLLMを活用する時にどのLLMを選択するべきか？で整理しています。

OpenAIが挙げているファインチューニングの適用先は、分類、ニュアンスのある翻訳、特定フォーマットでの生成、指示追従の失敗の修正の4つです。4つとも、モデルに新しい知識を教える用途ではなく、振る舞いの一貫性を上げる用途に寄っています。2軸フレームでいうモデルの最適化の側にすべて収まります。

この整理から考えると、2026年にファインチューニングを検討すべきなのは、プロンプトを工夫しても出力のばらつきが残り、その振る舞いを揃えることが業務上の要件になっている場合に限られます。「社内の情報を覚えさせたい」が動機であれば、検討すべきはRAGか長文コンテキストです。

私の実感でも同じです。ChatGPTが登場した当初はファインチューニングが注目されていましたが、いまの市場ではRAGがほぼ第一選択で、ファインチューニングを選ぶ場面はほとんどありません。モデルが大規模すぎて重みを変えるのは難しく、一般的なビジネス活用では当面不要な知識だと考えています。

一方で、今後ローカルLLMのような小型モデルを使う可能性があるなら、ファインチューニングは有効になりえます。特にフィジカルAIの領域では、独自データによるファインチューニングが期待されているアプローチです。

RAGとファインチューニングは併用できるのか？

できます。基本形は「知識はRAGで足し、出力の形式や口調はファインチューニングで揃える」という役割分担です。OpenAIの2軸フレームに当てはめると、文脈の最適化とモデルの最適化の両方に問題があるときが併用の条件になります。

併用を検討する前に必要なのが評価です。OpenAIの「Supervised fine-tuning」ドキュメントは「Good evals first!」として、評価の仕組みを整えてからでなければファインチューニングに投資しないよう明記しています。ファインチューニング後のモデルがベースモデルより良くなったかを判定する手段がなければ、投資の是非を決められないためです。

評価が無い状態で2つの手法を同時に入れると、精度が動いた原因がRAG側にあるのかファインチューニング側にあるのかを切り分けられなくなります。この構造から考えると、片方ずつ入れて効果を測り、両方が必要だと確認できた場合にのみ併用する順序が妥当です。

例えば、社内規程を参照させながら回答フォーマットを固定したい問い合わせ対応では、規程の検索をRAGで担い、回答テンプレートへの追従をファインチューニングで担う構成が考えられます。想定例であり、この構成で精度がどれだけ改善するかは、自社のデータと評価セットで検証する対象です。

よくある質問

プロンプトエンジニアリングだけで解決できるのはどこまでですか？

まず試すべき手段です。OpenAIの「Optimizing LLM Accuracy」は、プロンプトエンジニアリングが通常もっとも良い出発点だとしています。理由は、入力を与えて出力を判定する過程で「自分のユースケースにとっての精度」を定義せざるを得ないからです。一方、学習データに含まれない社内情報を補うことはできないため、そこから先はRAGか長文コンテキストの検討に移ります。

社内データの管理リスクは、RAGとファインチューニングのどちらが低いですか？

運用面ではRAGが低くなります。RAGは参照先の文書を削除・差し替えすれば、次の回答から反映されるためです。ファインチューニングは学習データの内容が重みに反映される構造上、特定のデータだけを後から取り消すには再学習が必要になります。削除要求への対応や情報の取り扱い範囲が要件に含まれる場合、この差は設計段階で効いてきます。

蒸留（ディスティレーション）はファインチューニングと何が違いますか？

教師データの作り方が違います。蒸留は、大きなモデルの出力を教師データとして小さなモデルを学習させる手法で、目的はコストと速度の改善に置かれます。ファインチューニングは、人が用意した理想的な入出力の組でモデルを更新する手法です。学習でモデルの重みを更新する点は共通しており、蒸留はファインチューニングの一形態として実施されます。

RAGとファインチューニングは何から学び始めればよいですか？

評価の作り方からです。OpenAIが「Good evals first!」として評価を先に置いているとおり、どちらの手法も「良くなったか」を判定できなければ選定も改善もできません。次に、手元の小さな資料をプロンプトに入れて答えさせる長文コンテキストを試し、資料が増えて入りきらなくなった段階でRAGへ進む順序が、仕組みの依存関係に沿っています。