RAGは「外部知識を検索してプロンプトに渡す」手法、ファインチューニングは「モデル自体を追加学習で作り替える」手法であり、知識をどこに持たせるかが根本的に異なる。 この違いを理解しておくと、後の比較軸や選定ステップがすっきり読める。まずは両者の仕組みを、動作原理に沿って個別に整理する。

RAG（Retrieval-Augmented Generation／検索拡張生成）は、モデルそのものは変更せず、回答に必要な知識を外部から検索してプロンプトに添える手法だ。

事前準備として、社内ドキュメントやFAQを適度な長さに分割（チャンク化）し、埋め込みモデルでベクトル化してベクトルデータベースに格納しておく。ユーザーから質問が来たら、その質問をベクトル化し、近い意味のチャンクを検索で取り出す。取り出したチャンクを「参考情報」として質問と一緒にLLMに渡し、その情報に基づいて回答を生成させる。

この構造の利点は、知識がモデルの外側にある点だ。ドキュメントを差し替えれば、モデルを再学習せずに知識を更新できる。また、どのチャンクを根拠に回答したかを示せるため、出典の提示や検証がしやすい。一方で、検索で適切なチャンクを引けなければ回答品質が落ちるため、チャンク設計と検索精度が成否を左右する。

ファインチューニングは、既存の学習済みモデルに対して、追加のデータセットで再学習を行い、モデルの重み（パラメータ）そのものを目的に合わせて調整する手法だ。知識や振る舞いをモデルの内部に染み込ませるイメージになる。

流れとしては、まず「入力と望ましい出力」のペアからなる教師データを用意する。データの品質と量がそのまま結果を左右するため、ここが最も労力のかかる工程だ。次に、用意したデータでモデルを追加学習させ、検証データで精度や副作用を確認し、問題なければデプロイする。全パラメータを更新する方式は計算コストが大きいため、一部のパラメータだけを効率的に調整するLoRAなどの手法（PEFT）が実務ではよく使われる。

利点は、出力のフォーマットや文体、専門領域の言い回しといった「振る舞い」を安定して再現できる点だ。反面、知識を更新するたびに再学習が必要で、外部知識の即時反映には向かない。

RAGとファインチューニングは、コスト・精度・データ要件という観点で性質が大きく異なるため、自社の制約に照らして比較軸を決めることが選定の出発点になる。 「どちらが優れているか」ではなく「自社のユースケースではどの軸が効くか」で考える。ここでは選定に使う代表的な比較軸を、コスト・精度・データの3つの観点から掘り下げる。

コスト面では、初期投資と運用維持費を分けて考える必要がある。

RAGの初期投資は、ドキュメントのチャンク化、ベクトルデータベースの構築、検索パイプラインの実装が中心だ。モデルの再学習が不要なため、機械学習の専門人材がいなくても着手しやすい。運用維持費としては、検索のたびに発生する埋め込みの呼び出しと、プロンプトが長くなることによる入力トークンの増加が継続的に乗る。

ファインチューニングの初期投資は、教師データの整備と学習の計算リソースに集中する。質の高いデータを用意する人手と、学習を回すGPU環境のコストが主な負担だ。一方で運用時は、外部知識を毎回プロンプトに詰める必要がない分、推論時のトークン量を抑えやすい。ただし知識を更新するたびに再学習のコストが再発する。

総じて、初期に小さく始めやすいのはRAG、知識が安定していて長期に大量利用するならファインチューニングが有利になりやすい。実際の損益分岐は利用規模と更新頻度で変わるため、後述のPoCで自社の数値を取って判断する。

精度の観点では、知識の鮮度とハルシネーションの起きやすさに違いが出やすい。

RAGは、回答の根拠となる情報を検索で都度持ってくるため、元のドキュメントを更新すれば最新の内容を反映できる。根拠チャンクを提示できるので、誤りの検証もしやすい。ただし、検索が的外れなチャンクを引いた場合や、関連情報が見つからない場合には、かえって誤った文脈に引きずられて品質が下がることがある。

ファインチューニングは、学習させた領域の言い回しやパターンを安定して再現できる一方、知識はモデル内部に固定されるため、学習時点以降の更新は再学習しないと反映されない。学習データに含まれない問いに対しては、もっともらしい誤答（ハルシネーション）を返しやすい傾向がある。

知識が頻繁に変わる領域では鮮度を保ちやすいRAG、変化が少なく振る舞いの一貫性が重要な領域ではファインチューニングが噛み合いやすい。

データの観点では、必要なデータの種類・量・品質が両手法で大きく異なる。

RAGが必要とするのは、検索対象となる「知識ドキュメント」そのものだ。教師データのように入出力ペアを作り込む必要はなく、既存の社内文書やFAQ、マニュアルをチャンク化すれば出発点に立てる。データ整備のハードルは比較的低い。ただし、ドキュメントが古い・重複が多い・構造が不揃いだと検索精度が落ちるため、元データの整理は効いてくる。

ファインチューニングが必要とするのは、「入力と望ましい出力」のペアからなる教師データだ。望ましい振る舞いを十分にカバーする量と、一貫した品質が求められ、この整備に最も手間がかかる。データが少ない、あるいは品質がばらつくと、学習が安定せず期待した効果が出にくい。

手元に整った知識文書はあるが教師データを作る余力がない、という状況は珍しくない。その場合はRAGから始めるのが現実的だ。

RAGが向くのは、知識が頻繁に更新される領域や、教師データを大量に用意しにくい状況である。 外部の知識を差し替えるだけで対応できるRAGの特性が、こうした場面で効いてくる。代表的な2つのケースを具体的に見ていく。

社内ドキュメントや規程集のように、内容が定期的に改訂される知識を扱う場合は、RAGが噛み合いやすい。

規程、業務マニュアル、製品仕様、FAQといった文書は、組織の運用に合わせて頻繁に更新される。ファインチューニングでこれらをモデルに覚え込ませると、改訂のたびに再学習が必要になり、運用が回らなくなりやすい。RAGなら、検索対象のドキュメントを差し替えるだけで最新版を参照させられるため、更新の運用コストを大幅に抑えられる。

加えて、RAGは回答の根拠となった文書を提示できるため、「どの規程のどの条項に基づく回答か」を示せる。社内の問い合わせ対応やナレッジ検索では、この根拠提示が回答の信頼性を担保する。改訂履歴の管理が重要な領域ほど、知識を外部に持つRAGの構造が運用に合う。

ラオス語やタイ語のように、学習データが相対的に少ない低リソース言語を扱う場合も、RAGが有力な選択肢になる。

低リソース言語は、ファインチューニングに必要な質の高い教師データを十分に集めること自体が難しい。データが乏しい状態で無理に追加学習を行うと、かえって出力が不安定になりやすい。一方RAGは、その言語で書かれた既存のドキュメント（規程、マニュアル、ナレッジ）を検索対象に据えれば、教師データを作らずとも、その言語・その組織固有の知識に基づいた回答を引き出せる。

当社が事業を展開する東南アジアでは、現地語の社内文書は存在するが、機械学習用に整備された対訳データは乏しい、という状況が一般的だ。こうした環境では、まず手元の現地語ドキュメントをRAGの知識源として活用し、必要に応じて言語特性に強い埋め込みモデルを選ぶアプローチが現実的だ。

ファインチューニングが向くのは、出力の形式や文体を厳密に揃えたい場合や、推論コストを下げるために挙動を小型モデルへ移したい場合である。 知識の更新よりも「振る舞いの一貫性」や「推論効率」が重視される場面で効いてくる。代表的な2つのケースを見ていく。

出力のフォーマットや文体を厳密に統一したい場合は、ファインチューニングが効果を発揮しやすい。

たとえば、決まったJSONスキーマで必ず出力させたい、特定の業界用語や敬語の水準を一貫して守らせたい、自社のトーン&マナーに沿った文章を安定して生成させたい、といった要件だ。これらはプロンプトの指示だけでは揺らぎが残りやすく、入力によっては形式が崩れることがある。

ファインチューニングで望ましい出力例を十分に学習させると、こうした「振る舞い」をモデルの内部に定着させられ、毎回プロンプトで細かく指示しなくても安定して再現できるようになる。プロンプトが短くなる分、推論時のトークンも抑えられる。形式の逸脱が業務上許されない用途や、大量に同じフォーマットを生成し続ける用途では、この一貫性が大きな価値になる。

推論コストを抑える目的で、大型モデルの挙動を小型モデルに移したい場合も、ファインチューニングが選択肢になる。

大型モデルは高精度だが、呼び出しごとの単価やレイテンシが大きい。そこで、大型モデルの出力を教師データとして小型モデルにファインチューニングし、特定タスクに限って近い品質を出せるようにする「蒸留」と呼ばれるアプローチがある。対象タスクを絞れば、小型モデルでも実用的な精度を保ちつつ、推論コストとレイテンシを下げられる可能性がある。

このアプローチは、同種のタスクを大量に・継続的に処理する用途で投資が回収されやすい。一方、タスクが多様で変化が激しい場合は、蒸留した小型モデルの守備範囲を外れやすく、効果が限定的になる。対象を十分に絞り込めるか、そして再学習の運用を継続できるかを見極めたうえで採用する。

結論として、知識の更新頻度が高くデータ整備の余力が限られるならRAG、振る舞いの一貫性と推論効率を重視し再学習を運用に乗せられるならファインチューニングが基本線になる。 ここまでの比較軸を一覧表にまとめ、さらに両者を組み合わせるハイブリッドという選択肢まで含めて、全体像を整理する。

下表は、ここまでの比較軸を一覧化したものだ。自社の制約に当てはめて、どの軸が効くかを確認してほしい。多くの組織では「まずRAGで素早く立ち上げ、必要な部分だけファインチューニングを足す」順序が現実的な出発点になる。

表はあくまで一般的な傾向であり、実際の優劣は利用規模・更新頻度・データの整い方で変わる。最終判断は次章のPoCで自社の数値を取ってから行う。

RAGとファインチューニングは二者択一ではなく、併用して双方の強みを活かす設計もできる。

典型的なのは、ファインチューニングで「振る舞い」を整え、RAGで「知識」を供給する組み合わせだ。たとえば、自社のトーンや出力フォーマット、専門領域の言い回しはファインチューニングでモデルに定着させ、頻繁に更新される具体的な知識はRAGで都度検索して渡す。これにより、形式の一貫性と知識の鮮度を同時に狙える。

ただし、併用は構成要素が増える分、運用の複雑さとコストも増す。検索パイプラインの保守と、再学習の運用の両方を抱えることになるため、最初から欲張らない方がよい。まずは片方（多くの場合RAG）で立ち上げ、形式の揺らぎや特定タスクの精度がボトルネックになって初めて、その部分にファインチューニングを足す。課題が顕在化してから併用へ段階的に広げるのが、投資を無駄にしない進め方だ。

手法選定は、ユースケースの棚卸し（Step 1）、PoCでの検証（Step 2）、本番移行前のガバナンス確認（Step 3）の3ステップで進めると失敗しにくい。 机上の比較だけで決め打ちせず、小さく検証して自社の数値で判断する流れを作ることが重要だ。各ステップでやるべきことを順に見ていく。

最初のステップは、対象とするユースケースと、その知識がどれくらいの頻度で更新されるかを棚卸しすることだ。

具体的には、「何に答えさせたいのか」「その答えの根拠となる知識はどこにあるのか」「その知識はどのくらいの頻度で変わるのか」「望ましい出力の形式はどの程度厳密か」を洗い出す。更新頻度が高くフォーマットの自由度も許されるなら、RAG寄りの判断材料になる。更新は少ないが形式の一貫性が厳しく問われるなら、ファインチューニングが候補に入る。

同時に、手元にある資産も確認する。整った知識ドキュメントはあるか、教師データを作れる人手と時間はあるか。多くの組織では「知識文書はあるが教師データを作る余力はない」状態であり、その場合はRAGから始めるのが理にかなう。ここで前提を言語化しておくと、次のPoCで何を検証すべきかが明確になる。

次に、PoC（概念実証）の規模で、コストと精度を実際に計測する。机上の比較表ではなく、自社のデータと自社のクエリで数値を取ることが目的だ。

検証では、代表的なクエリのセットを用意し、選んだ手法での回答品質（正答率、根拠の妥当性、形式の遵守度）と、1回あたりのコスト・レイテンシを計測する。RAGなら検索が適切なチャンクを引けているか、ファインチューニングなら学習領域外でどの程度崩れるかを重点的に見る。

PoCは「うまくいくか」だけでなく「どこで失敗するか」を見つける場でもある。フォールスな回答が出る条件、コストが想定を超える条件を洗い出し、本番でのリスクを事前に把握する。小さく回して得た数値があれば、初期コストと運用コストの損益分岐を自社の前提で試算でき、Step 1で立てた仮説を裏付けたり修正したりできる。

本番移行の前に、セキュリティとガバナンスの要件を確認する。精度とコストが見合っても、ここを詰めずに本番化すると、情報漏えいやコンプライアンス上の問題につながりかねない。

RAGの場合は、知識を外部のベクトルデータベースに保持するため、誰がどの文書を検索できるかというアクセス制御が論点になる。権限のないユーザーに、検索を通じて機密文書の内容が露出しないよう、文書単位・利用者単位の制御を設計する。ファインチューニングの場合は、学習データがモデルの内部に取り込まれる点に注意がいる。機密情報を学習させると、モデルの出力を通じて意図せず再現されるリスクがあるため、学習データの選別とマスキングが重要になる。

加えて、データを外部のクラウドAPIに送ってよいか、保存場所や保持期間の規程に反しないか、といったデータ主権の要件も確認する。これらを本番化のチェックリストとして整理し、関係部門の承認を得てから移行する。

RAGでもファインチューニングでも、導入後につまずく原因の多くは事前に予見できる典型パターンに集約される。 RAGならチャンク設計と検索精度、ファインチューニングなら追加学習による既存能力の劣化が代表例だ。先に知っておけば回避しやすい。2つの落とし穴を具体的に見ていく。

RAGで最も多いつまずきが、チャンク設計のミスによる検索精度の低下だ。

ドキュメントを分割する単位が大きすぎると、1つのチャンクに複数の話題が混ざり、検索でノイズの多い情報が返ってきて回答がぼやける。逆に小さすぎると、文脈が途切れて、回答に必要な情報が複数チャンクに分断され、検索で取りこぼす。見出しや段落の構造を無視して機械的に文字数で切ると、文の途中で分断されて意味が壊れることもある。

回避策としては、文書の論理構造（見出し・段落・項目）に沿って分割し、チャンクに前後の文脈や見出し情報を付与して、単体でも意味が通るようにする。チャンク同士を少し重ねる（オーバーラップ）と、境界付近の情報落ちを減らせる。さらに、検索で取りすぎた候補を関連度で並べ替える再ランキングを挟むと精度が安定する。チャンク設計は一度で完成しないため、実際のクエリで検索結果を確認しながら調整していく。

ファインチューニングで見落とされがちなのが、カタストロフィック・フォーゲッティング（破滅的忘却）だ。これは、新しいタスクを追加学習させた結果、モデルが元々持っていた汎用的な能力を失ってしまう現象を指す。

特定領域のデータだけで強く学習させると、その領域には強くなる一方で、それ以外の一般的な質問への対応が崩れることがある。狭いタスクに最適化したつもりが、汎用性とのバランスを欠いてしまうわけだ。

回避策としては、全パラメータを書き換えるのではなく、一部のパラメータだけを調整するLoRAなどの手法を使い、元のモデルへの影響を抑える。学習率を上げすぎない、学習を回しすぎない（過学習させない）、汎用的なデータを一定割合混ぜて学習させる、といった工夫も有効だ。そして何より、追加学習の後は対象タスクの精度だけでなく、元々できていた一般的なタスクが劣化していないかを検証データで必ず確認する。狭い指標だけを見て「精度が上がった」と判断しないことが、破滅的忘却を見逃さないための要になる。