RAG・PEFT・ファインチューニングの違い｜AI最適化手法の選び方【2026年版】

---

RAGを業務に入れて6か月後、「思ったより賢くない」と言い始める現場は少なくない。PoC段階では感動したのに、本番に近づくほど、現場の不満が積み上がっていく。

その原因を調べると、モデルが悪いのではない場合が多い。RAGで解くべき問題にファインチューニングをかけ、PEFTで整えるべき問題をプロンプトだけで押し切り、社内文書の整備不足をモデル学習で埋めようとしている。

手法の選択ミスは、大きな手戻りを生む。本記事は、RAG・PEFT / LoRA / QLoRA・フルファインチューニング・RFTを、解決できる問題、副作用、コスト、評価、運用負荷の観点から整理する判断ガイドである。

何が変わったのか

「RAGかファインチューニングか」で悩むだけでは足りない。現場の選択肢は、RAG・PEFT・フルファインチューニング・RFTへ広がっている。

かつて、LLMを自社向けに最適化する方法は「RAGか、ファインチューニングか」という二択で語られがちでした。

社内文書を参照させるならRAG。モデルの答え方を変えたいならファインチューニング。この基本整理は今でも有効です。

しかし2026年現在、この二択だけでは現場の判断に足りません。RAGとフルファインチューニングの間に、PEFT、LoRA、QLoRAのような軽量な調整手法が実務上の選択肢として入ってきたからです。

さらに、検証可能な推論タスクではRFT、低コスト・低レイテンシ運用ではDistillationや小型モデル化も視野に入ります。

RAGで直るのは、知識の問題です。PEFTで直るのは、答え方の問題です。フルファインチューニングやRFTで直すのは、判断パターンや推論の質そのものの問題です。

問うべきことは「RAGとファインチューニングのどちらが優れているか」ではありません。自社の問題は何か。それをどこまで、どのように解決したいのか。この問いから逆算して、手法を選ぶ必要があります。

RAGクラスターにおける本記事の位置づけ

なぜ今重要なのか

LLM活用がPoCから本番へ進むほど、単なる精度向上ではなく、知識・出力形式・判断パターンのどこを変えるのかが重要になる。

LLM活用の初期段階では、プロンプトを工夫するだけで大きな改善が得られることがあります。

しかし、本番に近づくほど、問題はより具体的になります。

社内文書を根拠に答えられない。回答形式が毎回ぶれる。問い合わせ分類が社内ルールと合わない。JSON出力が崩れる。最新規程を参照しているはずなのに、回答トーンが統一されない。

こうした課題は、すべて同じ技術で解けるわけではありません。

OpenAIはモデル最適化について、Evals、プロンプト改善、ファインチューニングを組み合わせたフィードバックループとして説明しています。つまり、最初からファインチューニングに飛びつくのではなく、何を改善したいのかを評価で測れる状態にしてから、最適化手法を選ぶ必要があります。

AWSは、カスタム文書を参照するQAでは、ファインチューニングなしにRAGで構築でき、最新文書の取り込みや情報源提示に強みがあると説明しています。一方で、Hugging FaceはPEFTを、モデル全体を更新せずに少数の追加パラメータだけで効率的に適応させる手法として説明しています。

知識はRAGで外部参照し、答え方はPEFTで軽く整え、大きな振る舞い変更が必要なときだけフルファインチューニングを検討する。

さらに、検証可能な推論タスクではRFT、本番コストを下げたい場合はDistillationや小型モデル化も視野に入れます。これが、2026年版の現実的な順序です。

まず問うべきこと：自社の問題は何か、どこまで解決したいのか

技術を選ぶ前に、自社の困りごとと、解決したい深さを明確にする必要がある。

AI最適化で最も危険なのは、技術名から入ることです。

「RAGを入れたい」「ファインチューニングしたい」「LoRAを使いたい」という言葉は、解決策の名前であって、問題の名前ではありません。

まず確認すべきなのは、自社が何に困っているのかです。知識が古いのか。根拠を示せないのか。答え方が揃わないのか。分類が社内ルールと合わないのか。モデルの判断そのものが業務に合っていないのか。

さらに、どこまで解決したいのかも重要です。PoCで傾向を見たいだけなのか。本番で安定運用したいのか。監査や権限まで含めて担保したいのか。小型モデル化して低コスト・低レイテンシで動かしたいのか。

ここが曖昧なままでは、どの手法を選んでも失敗します。

RAGが解く問題と副作用

RAGは、知識不足・情報の古さ・根拠提示の問題を解く。一方で、文書品質、検索品質、権限設計に強く依存する。

たとえば人事部が、就業規則と人事FAQをRAGに読み込ませ、「これで問い合わせ対応は減るはずだ」と期待したとします。

ところが、古い規程が混ざったまま、権限のない人にも広く検索される設計になっていれば、RAGは「間違った根拠を堂々と出してくるAI」になります。

RAGは、Retrieval-Augmented Generation、つまり検索拡張生成です。モデルの内部知識だけで答えさせるのではなく、社内文書、FAQ、マニュアル、規程、ナレッジベースなどを検索し、その結果を根拠として回答させます。

RAGが得意なのは、知識を外に置くことです。参考書を持ち込める試験に似ています。頭の良いモデルに、最新の参考書を渡して答えさせる発想です。

しかし、ここに落とし穴があります。持ち込んだ参考書が3年前の版だったらどうなるでしょうか。内容が矛盾する2冊を同時に渡したらどうなるでしょうか。索引がなく、どこに何が書いてあるか分からなかったらどうなるでしょうか。

RAGは、文書整備という準備なしには機能しません。「とりあえずRAGを入れてみた」が失敗する理由は、ここにあります。

この表の読み方はシンプルです。RAGは「知識の更新」と「根拠提示」に強い一方で、文書の品質と検索設計に弱点を持ちます。

RAGは、「モデルの頭脳ではなく、会社の本棚を賢くする」技術です。

そのため、RAGを入れても、回答形式が崩れる、分類が揺れる、トーンが合わない、といった問題は残ることがあります。この場合、RAGだけで解決しようとするのではなく、プロンプト改善、Evals、PEFTの検討が必要になります。

また、RAGは社内コンテンツの混乱を隠してくれません。文書が古い、版管理がない、権限が曖昧、チャンキングが粗い場合、RAGはその問題をそのまま回答に反映します。RAGを選ぶなら、まず RAG導入の覚悟 と RAGデータパイプライン設計 を避けて通れません。

PEFT / LoRA / QLoRAが解く問題と副作用

RAGで知識は補えた。しかし回答が毎回ぶれる。その問題を、モデル全体を触らずに解く現実解がPEFTである。

ある開発チームでは、RAGで根拠文書は正しく取れているのに、JSON出力が頻繁に崩れる問題に悩んでいました。

そのたびにエンジニアが手で修正し、ログには「AIのせいでAPIが不安定」というタグが増えていきました。

このとき問題は、知識ではありません。答え方です。

PEFTは、Parameter-Efficient Fine-Tuningの略です。大規模モデルの全パラメータを更新するのではなく、一部の追加パラメータだけを学習して、モデルを効率的に特定タスクへ適応させる考え方です。

代表的な手法がLoRAとQLoRAです。LoRAは、更新するパラメータ数を減らし、少ないメモリでファインチューニングを行う手法です。QLoRAは、量子化とLoRAを組み合わせ、さらにメモリ効率を高めるアプローチです。

なお、2026年時点では、LoRAの改良版であるDoRA（Weight-Decomposed Low-Rank Adaptation）のように、重み更新を方向と大きさに分けて扱う派生手法も使われ始めています。特に低ランク設定で、LoRAより高い性能を狙える場合があります。

フルファインチューニングが外科手術だとすれば、PEFTは投薬治療に近い選択肢です。モデル全体を大きく切り開くのではなく、症状に合わせて一部の振る舞いを調整します。

ただし、薬が効く症状と効かない症状があるように、PEFTにも向き不向きがあります。「出力が毎回ぶれる」「分類が社内ルールに合わない」「JSONが崩れる」。これらはPEFTが得意とする症状です。

「社内の最新規程を知らない」は、PEFTでは治りません。RAGが必要です。

特に2026年現在、高性能なオープンソース小型LLMとQLoRAを組み合わせることで、社内の安全なインフラ、オンプレミス、専用クラウド環境のまま、商用APIの従量課金や機密データ外部送信のリスクを抑えながら、業務特化モデルを検証しやすくなっています。

これは、技術的なメモリ効率だけでなく、コスト管理と情報管理の観点でも大きな意味を持ちます。

PEFTは、「モデル全体をいじらずに、癖と話し方だけを矯正する家庭教師」です。ファインチューニングを気軽にする魔法ではありません。

学習コストと保存コストを下げる一方で、教師データの品質、評価、副作用確認の負担は残ります。

また、PEFTは知識更新の代替ではありません。最新の社内規程や製品情報を反映したいなら、PEFTではなくRAGが必要です。PEFTは、知識を覚えさせるよりも、答え方を整えるために使うのが安全です。

なお、コスト感はモデルサイズ、シーケンス長、バッチサイズ、GPU、クラウド単価で大きく変わります。一般論として、7B級モデルでもフルファインチューニングは単一の一般向けGPUでは重くなりやすい一方、LoRA / QLoRAでは学習対象を絞ることで、より小さなGPU環境やプライベートクラウドでも検証しやすくなります。

したがって、いきなりフルファインチューニングへ進むのではなく、まずPEFTで小さく検証するのが現実的です。

フルファインチューニングが解く問題と副作用

フルファインチューニングは強力だが、投資・評価・副作用確認・再学習運用の負担が最も大きい。

フルファインチューニングは、モデルのパラメータを大きく更新し、特定タスクに深く適応させる手法です。これは例えるなら、「特定の専門技能を極めた外科医」を育てるようなものです。

しかし、企業導入で直視すべき現実があります。

その外科医が新しい専門技術を習得した半年後、もともとできていた別の手術を、うまくこなせなくなっていたとしたらどうでしょうか。

AIの世界では、これは比喩ではありません。フルファインチューニングによる破滅的忘却や回帰劣化は、本番環境で静かに起こり得ます。学習直後には気づけず、数週間後に別タスクの品質低下として発覚することもあります。

そうした事故を、回帰テストなしに防ぐことはできません。

フルファインチューニングが向くのは、単なる出力形式の安定化ではなく、モデルの専門能力や判断パターンそのものを大きく変えたいケースです。

例えば、数万〜数十万件規模の教師データを投下して独自の専門家モデルを長期的に育てたい場合や、社内独自の評価指標で既存モデルを明確に上回る必要がある場合です。

しかし、フルファインチューニングは最も重い選択肢です。学習データを集める。正解データを作る。学習する。評価する。狙った性能が上がったか確認する。さらに、改善対象ではない能力が壊れていないかを回帰テストする。

ここまで含めて初めて、本番投入を検討できます。

フルファインチューニングとRFTは、手術そのものよりも術後検査にコストがかかる治療だと考えるべきです。

たとえば、社内トーンは揃ったが、根拠文書を無視しやすくなっていないか。分類精度は上がったが、例外ケースを潰していないか。JSON出力は安定したが、説明品質が落ちていないか。問い合わせ回答は速くなったが、安全側の断りが弱くなっていないか。

これらを確認せずに本番投入するのは危険です。

したがって、フルファインチューニングは「RAGで足りない知識を補う手段」ではありません。モデルの振る舞いそのものを大きく変える必要がある場合だけ、慎重に選ぶべき手法です。

なお、2026年5月時点で確認したOpenAI公式ドキュメントでは、RFT（Reinforcement Fine-Tuning）はo-series reasoning models向けで、現在はo4-miniを対象に提供されています。RFTは、カスタムgraderでモデル出力を評価し、その報酬信号に基づいて推論モデルの振る舞いを改善する手法です。

数値判定、コード生成、構造化出力、検証可能な推論タスクのように、採点基準を明確に作れる場合は、SFTやDPOだけでなくRFTも検討対象になります。

たとえば、コードレビュー支援やセキュリティチェックのように、「重大な見落としを減らしたいが、誤検知も増やしすぎたくない」タスクでは、graderをどう設計するかが成否を分けます。RFTは、こうした検証可能なタスクで、単なる模倣ではなく採点基準に沿った振る舞いを強めたい場合に候補になります。

併用設計：RAG + PEFTが現実解になるケース

企業導入では、RAGで知識を参照し、PEFTで答え方を整え、Evalsで継続評価する構成が現実解になりやすい。

実務では、RAG、PEFT、フルファインチューニングのどれか一つだけで解くよりも、組み合わせた方が自然なケースが多くあります。

たとえば、社内規程QAを考えてみます。最新の規程やFAQを参照するにはRAGが必要です。しかし、回答を「結論 → 根拠 → 注意点 → 関連規程」の形式で毎回安定させたい場合、RAGだけでは不十分なことがあります。

その場合、プロンプト改善に加えて、PEFTで回答形式やトーンを整える選択肢が出てきます。

また、問い合わせ分類では、FAQや過去事例を参照するRAGだけでなく、社内カテゴリに沿って分類するためのPEFTが有効になる場合があります。

このとき重要なのは、検索品質と出力品質を分けて評価することです。

あるSaaS企業の典型例を考えてみましょう。

RAG導入から3週間後、サポートチームから「全然使えない」と報告が入りました。開発チームは焦ります。検索設定を見直す。チャンキングを変える。Embeddingモデルを替える。2週間の修正作業。それでも改善しない。

限界を感じたエンジニアが、ログを1件ずつ開いて見たとき、ようやく気づきました。

検索は、正しい文書を拾っていた。

問題は別の場所にありました。回答フォーマットが毎回崩れ、「結論」「根拠」「注意点」の順番がバラバラで、サポート担当者がコピーしてそのまま使えない形で出力されていたのです。

検索品質と出力品質を分けて評価していれば、2週間は要りませんでした。

このように、「精度が悪い」という一言だけでは、打ち手を誤ります。検索が悪いのか、文書が悪いのか、プロンプトが悪いのか、出力形式が悪いのか、モデルの判断が悪いのか。ここを分解できる企業だけが、RAG、PEFT、フルファインチューニングを正しく使い分けられます。

最終判断表：どの手法を選ぶべきか

ニーズ別に見ると、RAG・PEFT・フルファインチューニング・RFTの役割分担は明確になる。

ここまでの内容を、実務判断に使える形で整理します。

この表で大事なのは、「◎が多い手法を選ぶ」ことではありません。自社の最重要ニーズに合っているかを見ることです。

最新情報と根拠提示が最重要ならRAGです。回答形式と分類安定性が最重要ならPEFTです。モデルの専門能力そのものを大きく変えたいなら、フルファインチューニングが候補になります。採点基準を明確に作れる推論タスクなら、RFTも検討対象になります。

まとめ

AI最適化手法は、技術名ではなく、自社の問題と解決したい深さから選ぶべきである。

RAG、PEFT、フルファインチューニング、RFT。これらは競合する技術ではありません。それぞれが、違う問題を解くための道具です。

大工が「この現場をハンマーだけで仕上げよう」と言えば、誰もが止めるでしょう。しかしAIプロジェクトでは、同じことが起きがちです。

RAGで解くべき問題をファインチューニングで解こうとする。PEFTで整えるべき問題をプロンプトだけで押し切ろうとする。RFTが向く検証可能なタスクなのに、評価基準を作らないままモデルだけを替えようとする。

知識を足したいなら、RAG。答え方を整えたいなら、PEFT。モデルの振る舞いそのものを大きく変えたいなら、フルファインチューニング。検証可能な推論タスクを報酬信号で改善したいなら、RFT。

ただし、どれも万能ではありません。

RAGは、文書品質と検索品質に依存します。PEFTは、教師データの癖と評価負担を抱えます。フルファインチューニングは、投資と副作用確認が重くなります。RFTは、grader設計とreward hacking対策が重要になります。

あなたの現場の問題は、何ですか。それを、どこまで、どのように解決したいですか。

この問いに正直に答えられたとき、最適な手法は自然と見えてきます。

専門用語まとめ

RAG

Retrieval-Augmented Generationの略。外部文書を検索し、その結果を根拠としてLLMに回答させる手法。

PEFT

Parameter-Efficient Fine-Tuningの略。モデル全体ではなく、一部の追加パラメータを学習して効率的に適応させる手法。

LoRA

Low-Rank Adaptationの略。更新するパラメータ数を減らし、少ないメモリでモデルを調整するPEFT手法の一つ。

QLoRA

量子化とLoRAを組み合わせ、さらにメモリ効率を高める手法。大規模モデルを限られた計算資源で調整する選択肢になる。

DoRA

Weight-Decomposed Low-Rank Adaptationの略。LoRAの派生手法の一つで、重み更新を方向と大きさに分けて扱う。特に低ランク設定で、LoRAより高い性能を狙える場合がある。

フルファインチューニング

モデルのパラメータを大きく更新し、特定タスクや領域に深く適応させる手法。強力だが、投資と副作用確認が重い。

SFT

Supervised Fine-Tuningの略。入力と望ましい出力のペアを使って、モデルの応答を教師ありで調整する手法。

DPO

Direct Preference Optimizationの略。好ましい応答と好ましくない応答の比較データを用いて、モデルの出力傾向を調整する手法。

RFT

Reinforcement Fine-Tuningの略。graderによる報酬信号を使い、推論モデルの振る舞いを改善するファインチューニング手法。

Distillation

大きなモデルの出力や振る舞いを、小型モデルへ移す考え方。低コスト・低レイテンシで本番運用したい場合に検討される。

Evals

AIの出力品質を評価するための仕組み。RAG、PEFT、ファインチューニングのどれを選ぶ場合でも、改善前後を比較する基盤になる。

参考文献 / 出典

次に読むならこの3本

補足Q&A

Q1.
最初に試すべきなのはRAG、PEFT、フルファインチューニングのどれですか？

A1.
多くの場合、まずはプロンプト改善とRAGから検討し、出力形式や分類が安定しない場合にPEFTを検討します。

フルファインチューニングは、投資と副作用確認が重いため、明確な評価セットと事業上の必要性がある場合に限って検討するのが安全です。

Q2.
PEFTやLoRAはRAGの代わりになりますか？

A2.
代わりにはなりません。PEFTは知識更新ではなく、モデルの振る舞いを軽量に調整する手法です。

最新文書や社内規程を根拠に答えたい場合はRAGが必要です。PEFTは、回答形式、分類、トーン、タスク適応を安定させる目的で使うのが自然です。

Q3.
ファインチューニングすれば社内文書を覚えさせられますか？

A3.
理論上は可能でも、社内文書の更新や根拠提示には向きません。

文書が頻繁に変わる場合や、回答根拠を示したい場合はRAGが適しています。ファインチューニングで知識を覚えさせると、更新時に再学習が必要になり、出典提示も難しくなります。

Q4.
フルファインチューニングの最大のリスクは何ですか？

A4.
最大のリスクは、狙った改善以外の振る舞いが変わる副作用です。

そのため、フルファインチューニングでは、改善対象の評価だけでなく、既存能力が落ちていないかを確認する回帰テストと安全性評価が必要です。

Q5.
RFTはどんな場合に検討すべきですか？

A5.
採点基準を明確に作れる、検証可能な推論タスクで検討します。

数値判定、コード生成、構造化出力、セキュリティレビューのように、graderで出力を採点できるタスクではRFTが候補になります。ただし、grader設計、reward hacking対策、Evalsによる検証が必須です。

Q6.
Distillationや小型モデル化はどこに位置づけられますか？

A6.
多くの場合、RAGやPEFTで設計した振る舞いを、本番向けの小型モデルへ移す後段の最適化として位置づけられます。

大きなモデルで高品質な応答を作り、その出力を教師データとして小型モデルを調整すれば、低コスト・低レイテンシで運用しやすくなります。ただし、蒸留後の小型モデルはteacherと完全に同等になるわけではありません。許容できる範囲で性能が落ちる前提で、Evalsによって品質低下の許容ラインを決めておく必要があります。

更新履歴