RAGとファインチューニングのどちらを使うべきかは、「AIに知識を足したいのか」「AIの振る舞いを変えたいのか」で判断するのが基本です。社内規程や製品マニュアル、最新の価格表のように、AIが知らない情報に基づいて答えさせたいなら、RAGが向いています。文書を検索して回答の根拠として渡す仕組みなので、文書を差し替えればすぐに最新の情報に追随でき、回答の出典も示せます。一方、決まった書式で出力させたい、自社特有の文体や判断の型を身につけさせたい、特定の分類作業を安定してこなさせたい、といった「振る舞い」の調整には、ファインチューニングが向いています。
実務では、まずプロンプトの工夫とRAGで試し、それでも解決しない振る舞いの課題があるときにファインチューニングを検討する、という順番が、費用と手間の面で合理的です。両者は対立する選択肢ではなく、目的に応じて組み合わせることもできます。
この記事は、生成AIを業務やサービスに組み込もうとしていて、RAGとファインチューニングのどちらを選ぶべきか迷っている開発担当者、プロジェクトの責任者、事業担当者に向けて書いています。それぞれの仕組みの違い、判断の基準、費用と更新のしやすさの違い、目的別の選び方、組み合わせ方、よくある誤解と失敗までを順に説明します。
RAGとファインチューニングの仕組みの違い
まず、二つの手法が何をしているのかを整理します。
RAG（検索拡張生成）は、利用者の質問に関係する文書を検索で探し、その内容を生成AIへの入力に加えて回答を作らせる仕組みです。AIのモデル自体には手を加えず、回答のたびに必要な情報を外から渡します。たとえるなら、試験のときに参考書の該当ページを開いて見せながら答えさせるやり方です。
ファインチューニングは、既存のモデルに、自社で用意した入力と出力の例を追加で学習させ、モデルの振る舞いを調整する手法です。モデルの内部の値そのものが変わります。たとえるなら、答え方の練習を繰り返させて、癖や型を身につけさせるやり方です。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 変えるもの | モデルへの入力（渡す情報） | モデル自体（内部の値） |
| 得意なこと | 手元の文書に基づいて答える、最新の情報に追随する | 出力の形式、文体、判断の型をそろえる |
| 情報の更新 | 文書を差し替えればすぐ反映 | 再学習が必要 |
| 出典の提示 | できる（使った文書を示せる） | 難しい（どこから得た知識か示せない） |
| 準備するもの | 対象の文書、検索の仕組み | 質の高い入力と出力の例を多数 |
| 初期の手間 | 検索の仕組みと文書の整備 | 学習データの作成と学習、評価 |
| 運用の手間 | 文書の更新、検索の改善 | 再学習、モデルの版の管理 |
ここで押さえておきたいのは、ファインチューニングは「知識を覚えさせる」ことが不得意だという点です。社内規程の内容を学習させても、モデルが条文を正確に覚えて引き出せるとは限らず、似た内容を混ぜたもっともらしい回答を作ってしまうことがあります。また、規程が改定されるたびに学習し直す必要があります。正確な情報に基づいて答えさせたい場面では、RAGの方が確実です。
判断の基準：知識を足すか、振る舞いを変えるか
どちらを使うかは、解決したい課題が「知識の不足」なのか「振る舞いのずれ」なのかを見極めることから始めます。
知識の不足が課題の場合
次のような課題は、知識の不足によるものです。RAGを検討します。
- 社内規程や手順書の内容について答えられない
- 自社製品の仕様や価格を知らない
- 最新の情報（今月の変更、新しい制度など）を知らない
- 顧客ごと、案件ごとの情報に基づいて答えられない
- 回答の根拠を示す必要がある
振る舞いのずれが課題の場合
次のような課題は、振る舞いのずれによるものです。まずプロンプトの工夫を試し、それでも足りなければファインチューニングを検討します。
- 出力の形式が安定しない（決まった項目、決まった構造で出してほしい）
- 自社の文体や言葉づかいに合わない
- 業界特有の言い回しや略語を正しく扱えない
- 特定の分類や判定の作業で、期待どおりの判断をしない
- 長い指示や多くの例を毎回渡しており、入力が長く費用や応答時間がかさむ
最後の項目は見落とされがちですが、ファインチューニングを検討する実務的な理由の一つです。プロンプトに多くの例を入れて振る舞いを制御している場合、その振る舞いをモデルに学習させれば、毎回の入力を短くでき、費用と応答時間を抑えられる可能性があります。
まずプロンプトで試す
振る舞いの課題であっても、すぐにファインチューニングに進む必要はありません。指示を具体的に書く、出力の形式を明示する、望ましい回答の例を数件示す（Few-shotプロンプト）、といったプロンプトの工夫で解決することは多くあります。プロンプトの変更はすぐに試せて、元に戻すのも簡単です。複数の案を同じ評価用のデータで比べることも容易なので、改善の手応えを短い期間で確かめられます。プロンプトでは解決しない、あるいはプロンプトが長くなりすぎる場合に、ファインチューニングを検討します。
費用と更新性の違い
二つの手法は、費用のかかり方と、情報や振る舞いを更新するときの手間が異なります。
RAGの費用
RAGの費用は、文書を取り込んで検索できるようにする仕組みの構築、文書の前処理と整備、検索用のデータベースの運用、そして回答のたびに生成AIに渡す入力の量に応じた利用料で構成されます。検索で取得した文書を毎回入力に含めるため、一回あたりの入力が長くなり、利用料が増える傾向があります。
ファインチューニングの費用
ファインチューニングの費用は、学習データの作成、学習の実行、学習したモデルの評価、そして学習したモデルの利用料や運用費で構成されます。費用の中で大きくなりやすいのは、学習データの作成です。質の高い入力と出力の例を十分な数だけ用意するには、業務を知っている人の時間が多く必要になります。また、提供元によっては、ファインチューニングしたモデルの利用料が通常のモデルと異なる場合があります。料金体系は変わることがあるため、最新の情報を確認してください。
更新のしやすさ
| 変化 | RAGでの対応 | ファインチューニングでの対応 |
|---|---|---|
| 規程や価格が変わった | 文書を差し替える | 学習データを直して再学習する |
| 対象の文書を増やしたい | 文書を追加して取り込む | 学習データを追加して再学習する |
| 出力の形式を変えたい | プロンプトを変更する | 学習データを作り直して再学習する |
| 基盤のモデルが新しくなった | そのまま新しいモデルに切り替えられることが多い | 新しいモデルで学習し直す必要がある |
情報が頻繁に変わる用途では、RAGの更新のしやすさが大きな利点になります。一方、ファインチューニングで調整した振る舞いは、基盤のモデルが更新されると学習し直す必要があり、継続的な手間がかかります。生成AIを組み込んだシステムの費用の考え方は、生成AIを組み込んだシステム開発の費用とAPI利用料の見積もり方で詳しく扱っています。
目的別の選び方と組み合わせ方
代表的な目的ごとに、選び方の目安を示します。
| 目的 | 主な手法 | 補足 |
|---|---|---|
| 社内規程・マニュアルへの問い合わせ対応 | RAG | 出典の提示と更新のしやすさが重要 |
| 製品の仕様・価格の案内 | RAG | 情報の変更に即時に追随する必要がある |
| 定型の書式での報告書・要約の作成 | プロンプト、必要に応じてファインチューニング | 形式の安定が課題ならファインチューニングを検討 |
| 問い合わせの分類・振り分け | プロンプト、必要に応じてファインチューニング | 分類の数が多く判断が細かい場合に効果が出やすい |
| 自社の文体での文章作成 | プロンプト、必要に応じてファインチューニング | 文体の例を多く用意できる場合 |
| 社内文書に基づき、決まった形式で回答 | RAGとファインチューニングの組み合わせ | 知識はRAG、形式はファインチューニングで担う |
組み合わせて使う
知識と振る舞いの両方に課題がある場合は、二つを組み合わせます。例えば、社内文書の内容はRAGで渡し、回答の形式や文体はファインチューニングで調整したモデルに担わせる、という構成です。また、RAGの検索の部分（文書の並べ替えや、質問の書き換え）に、小さなモデルをファインチューニングして使う方法もあります。
具体的な場面の例
架空の例として、保険の代理店が、営業担当者向けに商品の説明を支援するAIを作る場合を考えます。商品の約款や改定の情報は頻繁に更新され、回答には根拠を示す必要があるため、知識の部分はRAGで扱います。一方で、社内のルールとして、顧客への説明文は決まった順番（商品の概要、保障の内容、注意事項、確認事項）で書く必要があり、プロンプトで指示しても順番が崩れることがありました。この場合、まずプロンプトに出力例を加えて改善を試み、それでも安定しなければ、過去の承認済みの説明文を学習データにしてファインチューニングを検討する、という順番で進めます。
別の架空の例として、通販事業者が、問い合わせメールを数十種類の分類に振り分けたい場合を考えます。必要なのは知識ではなく判断の型なので、RAGは主役になりません。まずプロンプトに分類の定義と例を示して試し、分類の数が多く、プロンプトが長くなりすぎて費用と応答時間がかさむなら、過去に担当者が分類した記録を学習データにしてファインチューニングを検討します。
判断の手順とチェックリスト
どちらを使うかは、次の手順で判断します。
- 解決したい課題を具体的に書き出す：どんな質問や作業で、どんな出力が期待どおりでないのか
- 課題を「知識の不足」と「振る舞いのずれ」に分ける
- 評価用のデータを用意する：課題を代表する入力と、期待する出力の組
- 知識の不足にはRAGを、振る舞いのずれにはプロンプトの工夫を試す
- 評価用のデータで結果を測る
- 振る舞いの課題が残る場合、ファインチューニングの学習データを用意できるかを確認する
- 学習データの作成、学習、評価、再学習の手間と費用を見積もり、得られる効果と比べる
- ファインチューニングを行う場合も、小さな規模で試して評価してから本格的に進める
3の評価用のデータは、手法を比べるための共通の物差しになります。手法を変えるたびに同じデータで評価すれば、効果を客観的に比べられます。評価の進め方はRAGの回答精度を改善する方法も参考になります。
手法選びのチェックリスト
- 課題が知識の不足か、振る舞いのずれかを区別した
- 回答の根拠を示す必要があるかを確認した
- 情報が更新される頻度を確認した
- プロンプトの工夫を十分に試した
- 評価用のデータで効果を測っている
- ファインチューニングの学習データを、質と量の両面で用意できるか確認した
- 学習データに含まれる情報の取り扱い（個人情報、機密情報）を確認した
- 基盤のモデルが更新されたときの再学習の手間を見込んだ
- 使うモデルの提供元でファインチューニングが提供されているか、条件を確認した
ファインチューニングを行う場合の進め方
判断の結果、ファインチューニングを行うことにした場合は、次の点に注意して進めます。
学習データを集めて整える
学習データは、入力と期待する出力の組として作ります。過去の業務の記録（担当者が書いた報告書、分類した問い合わせの記録など）を使えることが多いものの、そのままでは基準がそろっていないことがほとんどです。まず「良い出力」の基準を文章にし、その基準に合う記録だけを選ぶか、基準に合わせて直します。数を集めることよりも、基準がそろっていることの方が結果に効きます。個人名や顧客の情報が含まれる記録は、伏せ字にするなどの処理をしてから使い、学習データを外部のサービスに送ってよいかを社内のルールに照らして確認します。
評価用のデータを学習に混ぜない
評価用のデータを学習データにも使ってしまうと、評価の結果が実際よりも良く見えます。最初に評価用のデータを取り分けておき、学習には使わないようにします。
元のモデルと比べる
学習したモデルは、必ず元のモデル（プロンプトの工夫だけを加えたもの）と同じ評価用のデータで比べます。目的の振る舞いが改善していても、学習させなかった種類の入力で性能が落ちていることがあるため、目的以外の入力も評価に含めておくと安心です。
版を管理する
学習データ、学習の設定、学習したモデル、評価の結果を、版ごとに記録しておきます。基盤のモデルが更新されたときや、学習データを追加したときに、どの版が最も良かったかを比べられるようにし、問題があれば前の版に戻せる状態にしておきます。
よくある誤解と失敗
ファインチューニングで社内の知識を覚えさせようとする
社内文書を学習させれば、その内容を正確に答えられるようになると考えがちですが、ファインチューニングは知識の正確な再現には向いていません。誤った内容を自信を持って答える原因にもなります。知識を扱うならRAGを使います。
プロンプトの工夫を試さずにファインチューニングに進む
ファインチューニングには、学習データの作成と再学習の手間がかかります。プロンプトの工夫で解決する課題に対してファインチューニングを行うと、手間と費用に見合いません。まずプロンプトで試し、評価の結果を見て判断します。
学習データの質を軽く見る
ファインチューニングの結果は、学習データの質に大きく左右されます。担当者によって判断がばらばらな記録や、誤りを含む記録をそのまま学習させると、その揺らぎや誤りをモデルが学習してしまいます。学習データは、業務を知っている人が確認し、基準をそろえてから使います。
RAGの精度の問題をファインチューニングで解決しようとする
RAGの回答が間違う原因の多くは、検索で正しい文書が取れていないことにあります。この場合、モデルをファインチューニングしても改善しません。まず検索の失敗か生成の失敗かを切り分けます。
一度の学習で終わりだと考える
ファインチューニングしたモデルは、業務の変化や基盤のモデルの更新に合わせて、学習し直す必要が出てきます。提供元が古いモデルの提供を終了すれば、新しいモデルで学習し直さなければなりません。学習データと評価の仕組みを残しておき、再学習を定期的な運用の一部として計画しておくことで、そのたびに一から作り直す事態を避けられます。
よくある質問
Q. 小さな会社でもファインチューニングは使えますか？
使うこと自体は可能ですが、学習データの作成と評価の手間を考えると、多くの場合はプロンプトの工夫とRAGで十分です。毎日大量に同じ形式の処理をしていて、プロンプトの長さが費用や応答時間の負担になっている、といった明確な理由があるときに検討するのがよいでしょう。モデル選びの観点は業務に使うLLMの選び方で解説しています。
Q. ファインチューニングとRAGのどちらが費用を抑えられますか？
用途によって異なります。RAGは毎回の入力が長くなりやすく、ファインチューニングは学習データの作成と再学習に費用がかかります。利用の量、情報の更新頻度、学習データの用意のしやすさを踏まえて、評価用のデータで効果を比べたうえで、総額を見積もって判断します。
Q. 小さなモデルを自社用に調整して使う方法もありますか？
あります。大きなモデルの出力を手本にして小さなモデルを学習させる蒸留のような手法や、公開されているモデルを自社の環境で調整する方法があります。費用や応答速度、データの取り扱いの要件が厳しい場合に選択肢になりますが、運用の手間は増えます。
Otsumuに相談できること
課題が「社内文書に基づいて答えさせたい」という知識の不足であれば、まずはRAGを試すのが近道です。対象の文書が限られていれば、既製のサービスを使ったり、社内のエンジニアが小さく試作したりして、自社で進められることも多いはずです。振る舞いの課題についても、プロンプトの工夫で解決できることが多いため、この記事の判断の手順に沿って、まず評価用のデータを用意するところから始めてみてください。
一方で、課題が知識と振る舞いのどちらにあるのか切り分けがつかない、RAGを作ったが精度が上がらず手法の見直しを検討している、ファインチューニングの学習データの作り方や評価の設計に不安がある、といった場合は、経験のある外部の力を借りた方が、遠回りを避けられます。RAGの構築の流れはRAGシステムの構築手順で解説しています。
Otsumuでは、課題の切り分けと評価用データの設計から、RAGの構築、プロンプトの改善、必要な場合のファインチューニングの検討と実施、運用中の評価までを一貫して支援しています。目的から逆算して必要な手法に絞り、AIを活用した少人数の開発で、小さく試して効果を確かめてから進めます。詳しくはRAG開発や生成AIシステム開発のページをご覧ください。
自社の課題にどちらの手法が合いそうか、状況を伺いながら一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01