ファインチューニングとは?RAGとの違いやLoRAなど最新手法を比較

結論: ファインチューニングとは、事前学習済みのAIモデルに対して、特定のタスクや振る舞いを「追加学習」させ、その用途に特化した専門家へとカスタマイズする技術です。

Contents

LLMは「物知り」だが「仕事」は知らない

多くのエンジニアやプロジェクトマネージャーが最初に陥る誤解があります。「ファインチューニングすれば、社内の専門知識を全部覚えてくれるはずだ」という期待です。

Mikoto

え、違うんですか? 社内Wikiとか全部読ませれば、何でも答えてくれるスーパーAIができると思ってました…。

Yachi

残念ながら、それはよくある勘違いなんです。

この期待は半分正解で、半分間違いです。ファインチューニングの本質は「新しい知識の暗記」ではなく、「振る舞いや思考プロセスの矯正」にあります。

GPT-4やLlama 3といったベースモデルは、Web上の膨大なテキストを読み込んでいますが、それはあくまで「一般的な言語能力」と「広範な知識」を持っているに過ぎません。彼らは「頭のいい新人」ですが、あなたの会社の「日報の書き方」や「顧客対応のトーン&マナー」、あるいは「JSON形式でしか答えてはいけない」といった現場のルールは知りません。

この「頭のいい新人」に、特定の業務ルールや性格を叩き込む工程こそが、ファインチューニングなのです。

【ここでのポイント】ファインチューニングは「知識」を増やすためではなく、「性格」や「出力形式」を調整するために行います。知識を補いたい場合は、後述するRAGの方が適しています。

概念の整理:事前学習 vs ファインチューニング vs RAG

AI開発の現場では、モデルを賢くするために「事前学習」「ファインチューニング(FT)」「RAG(検索拡張生成)」という3つのアプローチが混在しがちです。これらを明確に区別するために、「プロの音楽家」に例えて考えてみましょう。

1. 事前学習 (Pre-training) = 音楽大学での基礎教育

モデルが生まれてから最初に受ける、最も過酷で長期間のトレーニングです。

  • やること: 楽典、聴音、楽器の基礎操作、あらゆるジャンルの名曲を数億曲聴き込む(Web全体のテキスト学習)。
  • 成果: どんな楽譜でも読めて、基礎的な演奏能力を持った「万能な音楽家」が誕生する。
  • コスト: 数億円〜数百億円(GPU数千基)。一般企業がゼロからやるものではありません。

2. ファインチューニング (Fine-Tuning) = 特定ジャンルのバンド練習

基礎教育を終えた音楽家を、特定のバンド(プロジェクト)に加入させるための練習期間です。

  • やること: 「うちはジャズバンドだから、こういうリズムで弾いてくれ」「ヘビメタだからもっと激しく」といったプレイスタイル(振る舞い)を体に染み込ませる。
  • 成果: 基礎能力はそのままで、特定ジャンルに特化した演奏ができるようになる。
  • コスト: 数万円〜数十万円(GPU1基〜)。

3. RAG (Retrieval-Augmented Generation) = 初見演奏

演奏中に、目の前に置かれた新しい楽譜(社内ドキュメント)を見て、その通りに弾く技術です。

  • やること: 記憶にない曲でも、楽譜を見れば弾ける。
  • 違い: FTが「体で覚える(重みの更新)」のに対し、RAGは「カンペを見て処理する(外部参照)」です。
Mikoto

なるほど! RAGはカンペを見ながら演奏してるんですね。

Yachi

その通りです。だから社内規定のような「AIが知らない情報」にはRAGが最強です。逆に「うちの会社の独特な言い回し」を真似させたいならFTが必要です。

Yachi

個人的には、まずRAGでの実装を試みることを強く推奨します。多くのビジネス課題はRAGで解決可能ですし、データの更新も容易だからです。ファインチューニングは、RAGだけではどうしても精度が出ない場合の「奥の手」として考えましょう。

【ここでのポイント】
事前学習: 基礎能力を作る(超高コスト)
FT: 特定の型を体に覚えさせる(中コスト)
RAG: 外部資料を見ながら回答させる(低コスト・知識更新が楽)

「RAG」や「ハルシネーション」についてはこちらの記事もチェック!

手法比較の全体像:3つのレイヤーとコスト感

「ファインチューニング」と一口に言っても、現在は技術の進化により3つのレイヤー(階層)に分かれています。これらは並列の選択肢ではなく、積み上げ式の工程です。

  1. Layer 1: SFT (Supervised Fine-Tuning) – 基礎工事
  2. Layer 2: PEFT (Parameter-Efficient Fine-Tuning) – コスト革命
  3. Layer 3: Alignment (RLHF / DPO) – 価値観の注入

2026年現在の実務標準では、すべてのパラメータを更新する「フルパラメータ・チューニング」を行うケースは稀です。コストと精度のバランスから、以下のような特性の違いがあります。

手法レイヤー手法の例計算コスト(VRAM)データ作成難易度変化の性質主な用途
Full SFT古典的FT極大 (H100複数必須)脳全体を書き換える基盤モデル開発
PEFTLoRA / QLoRA (RTX 4090等で可)特定スキルを追加実務の9割はこれ
AlignmentDPO / RLHF中〜小 (ペアデータ)好み・安全性の調整チャットボット仕上げ
Yachi

数年前まではFull SFTが主流でしたが、今は計算リソースの無駄遣いと言っても過言ではありません。LoRAやQLoRAの精度がFull SFTに肉薄している現在、あえてフルパラメータを選ぶ理由は、基盤モデルそのものを開発する企業以外にはほとんどありません。

【Layer 1】SFT (Supervised Fine-Tuning):基礎工事

Supervised Fine-Tuning(教師ありファインチューニング)は、すべてのカスタマイズの土台となる工程です。別名「インストラクション・チューニング」とも呼ばれます。

「次トークン予測機」から「チャットボット」へ

事前学習を終えた直後のBaseモデルは、単に「次の単語を予測するマシン」です。「こんにちは」と入力すると、挨拶を返すのではなく「……良い天気ですね」と小説の続きを書き始めてしまうことがあります。

Mikoto

え、挨拶してくれないんですか?

Yachi

Baseモデルは「会話」を知らないんです。ただ「文章の続き」を予測しているだけなので。

SFTでは、入力(Prompt)に対して期待される出力(Completion)をペアで学習させ、「指示に対して答えを返す」という対話の作法を教え込みます。

フルパラメータの限界

かつてはモデルの全パラメータ(70億モデルなら70億個の重み)をすべて更新していましたが、これには2つの致命的な課題がありました。

  1. VRAM不足: 巨大なモデルをすべてメモリに展開し、誤差逆伝播を行うには、数百万円する業務用GPUが何枚も必要になります。
  2. 破滅的忘却 (Catastrophic Forgetting): 特定のタスクに適応しすぎた結果、事前学習で獲得した汎用的な論理能力や、他のタスクの処理能力が崩壊する現象です。

これらを解決するために登場し、現在のデファクトスタンダードとなったのが次の「PEFT」です。

【Layer 2】PEFT (LoRA / QLoRA):コスト革命

PEFT(Parameter-Efficient Fine-Tuning)は、モデルのパラメータを効率的に調整する技術群の総称です。中でもLoRA (Low-Rank Adaptation) とその派生である QLoRA が、現在のAI開発を支えています。

ギターとエフェクターの関係

LoRAの仕組みを直感的に理解するには、エレキギターの音作りをイメージしてください。

  • ギター本体(ベースモデル): フェンダーやギブソンのような名機。構造は複雑で高価。改造しようとして分解すると元に戻せなくなるリスクがある。
  • エフェクター(LoRAアダプター): ギターとアンプの間に繋ぐ小さな箱。これを踏むだけで、音色が「歪んだロック」や「幻想的なコーラス」に変わる。

LoRAは、巨大なベースモデル(ギター本体)の重みは一切変更せず「冷凍保存」します。その代わりに、少数の追加パラメータ(エフェクター)だけを学習させます。

Mikoto

あ、本体はいじらないんですね! それなら壊れる心配もなさそうです。

Yachi

まさにその通り。しかもエフェクターを付け替えるだけで、同じギターで別の曲も弾けるようになります。これがLoRAの柔軟性です。

推論時には、ベースモデルの出力にこの追加パラメータの影響を足し合わせることで、あたかもモデル全体が学習したかのような振る舞いを実現します。

LoRA / QLoRA の凄まじいメリット

  1. 圧倒的な軽さ: 学習するパラメータ数は全体の0.1%〜1%未満。生成されるアダプターファイルは数百MB程度で済みます。
  2. スイッチング: 1つのベースモデルに対して、「カスタマーサポート用アダプター」「プログラミング用アダプター」を切り替えるだけで、即座に人格を変えられます。
  3. QLoRAによる民主化: QLoRAは、ベースモデルを4bitに量子化(圧縮)した状態でLoRAを適用する技術です。これにより、70Bクラスの超巨大モデルであっても、単一のハイエンドGPUで学習可能になりました。

「フルパラメータの方が精度が良いのでは?」と思うかもしれませんが、数学的推論などの極めて複雑なタスクを除けば、実務上のタスク(要約、分類、抽出、変換)においてLoRAはフルパラメータと遜色ない性能を発揮することが多くの研究で示されています。

Yachi

個人的には、中小規模のプロジェクトなら「QLoRA」一択だと考えています。家庭用のゲーミングPC(RTX 3090/4090)レベルで学習が回せるようになったのは革命的で、これにより試行錯誤のサイクルを高速に回せるメリットの方が、微々たる精度の差よりも遥かに重要だからです。

【ここでのポイント】PEFT(特にLoRA/QLoRA)は、モデル本体を固定し、少量の追加パーツだけを学習させる技術です。低コストかつ高性能で、現在の実務における標準手法となっています。

AI開発に不可欠な「GPU」の基礎知識はこちらの記事をチェック!

【Layer 3】Alignment (RLHF / DPO):価値観の注入

SFTで「指示に従うこと」はできるようになりましたが、まだ「人間にとって好ましい回答」ができるとは限りません。嘘をついたり、危険な発言をしたりする可能性があります。そこで行うのがアライメント(調整)です。

「正解」ではなく「好み」を教える

ここでは「1+1=2」のような事実ではなく、「どちらの回答がより役に立つか」「どちらが安全か」という価値観を教えます。

複雑なRLHFから、シンプルなDPOへ

かつてChatGPT(GPT-3.5)が採用したRLHF (Reinforcement Learning from Human Feedback) は、報酬モデルを別途構築して強化学習を行う複雑なパイプラインが必要で、学習も不安定でした。

現在、オープンソース界隈や実務で主流になりつつあるのが DPO (Direct Preference Optimization) です。

  • 仕組み: 報酬モデルをあえて作らず、「勝ちデータ(好ましい回答)」と「負けデータ(好ましくない回答)」のペアをモデルに直接提示し、勝ちデータの確率を上げ、負けデータの確率を下げるように調整します。
  • メリット: SFTと同じような感覚で安定して学習でき、計算リソースもRLHFより遥かに軽量です。
Mikoto

RLHFとかDPOとか、アルファベットが多くて混乱してきました…。

Yachi

難しく考えなくて大丈夫です。要は「こっちの回答の方がイケてるよ」と教えるのがDPOです。RLHFは昔の難しいやり方、DPOは今の簡単なやり方、と覚えておけばOKです。

「個人開発レベルでもモデルの安全性を担保できるようになった」というのは、DPOの功績と言えるでしょう。

「RLHF」の具体的な仕組みについてはこちらの記事をご覧ください。

燃料の確保:高品質なデータセット作成戦略

アルゴリズムの進化は日進月歩ですが、結局のところモデルの性能を決めるのは「データ」です。“Garbage In, Garbage Out”(ゴミを入れたらゴミが出る) の原則は、AI時代においても絶対です。

量より質:LIMA仮説

「LIMA仮説(Less Is More for Alignment)」という興味深い研究結果があります。これによれば、モデルは事前学習の段階ですでに知識の大半を持っており、ファインチューニングに必要なのは「特定のスタイルを引き出すための、少量の高品質なデータ」だけで十分だとされています。
スタイルを真似させるだけなら数百件、新しいタスクを覚えさせる場合でも数千件あれば、実用的なモデルが作れます。

データセットの具体例:SF宇宙戦艦のオペレーション

実務では、目的とするタスクの文脈に沿ったデータセット(JSONL形式など)を準備します。ここでは、一般的な会話ではなく、特殊な専門用語と厳格なルールが求められるシナリオを考えてみましょう。

作成例:宇宙戦艦のAIオペレーター
目的:緊急時の冷静かつ的確な状況報告と、軍事プロトコルの遵守。

このように、「緊急コードの確認」「復唱」「警告の付与」といったアライメント(振る舞いのルール)をデータの中に埋め込むことで、モデルはそのパターンを学習します。

データの作り方:AIに作らせる

人間がすべて手書きするのはコストが高すぎます。現在は、GPT-4などの上位モデルに「教師」となってもらい、データを作成させる合成データ(Synthetic Data)のアプローチが一般的です。
「マニュアルを読み込ませて、そこから想定されるQ&Aを100個作って」と指示すれば、高品質な学習データが短時間で手に入ります。

Mikoto

AIを育てるための教材を、別のAIに作らせるんですか? なんだか不思議な感じですね。

Yachi

そうですね。でもこれが一番効率的で品質も高いんです。人間が手作業で作るとどうしても揺らぎが出ますが、GPT-4ならルール通りの綺麗なデータを量産してくれますから。

意思決定フローチャート:どの手法を選ぶべきか

最後に、あなたのプロジェクトがどの手法を採用すべきか、判断基準を整理します。

  1. Case A: 「最新情報」や「事実の正確さ」が最優先
  2. 推奨: FTしない。RAG(検索システム)を構築してください。
  3. FTしてもハルシネーション(嘘)はなくなりません。むしろ流暢に嘘をつくようになります。
  4. Case B: 「JSONで出力したい」「特定の口調にしたい」
  5. 推奨: SFT (LoRA / QLoRA)
  6. 最もコスパが良い選択肢です。数百件のデータでLoRAアダプターを作成すれば、安価に実現できます。
  7. Case C: 「回答の安全性」や「人間らしさ」を向上させたい
  8. 推奨: SFT済みモデルに DPO を適用。
  9. ユーザーのフィードバック履歴(Good/Bad)があるなら、それをDPO用データセットに変換して学習させましょう。
  10. Case D: 「社内独自のプログラミング言語」など、未知の知識を教え込みたい
  11. 推奨: 継続事前学習 (Continued Pre-training)
  12. これはFTの範疇を超え、莫大なテキストデータと計算リソースが必要です。通常はここまでする前にRAGで解決できないか再考すべきです。

多くの企業にとっての最適解(Sweet Spot)は、「7B〜14Bクラスの扱いやすいモデル」+「RAGによる知識補完」+「QLoRAによる微調整」の組み合わせです。

【ここでのポイント】
・正確な知識が必要なら RAG
・振る舞いや形式を固定したいなら SFT(LoRA)
・安全性や好みを調整したいなら DPO

自分の目的がどこにあるかを明確にすることで、無駄な開発コストを抑えられます。

よくある質問と誤解 (FAQ)

OpenAIのAPIでファインチューニングするのと、自前でLoRAをするのはどっちが良い?

A: 手軽さならAPI、自由度と機密性なら自前LoRAです。
OpenAIのFine-tuning APIはサーバー管理が不要で非常に楽ですが、作成したモデルをダウンロードして持ち出すことはできません(ロックイン)。また、従量課金であり、データの検閲フィルタもかかります。
自前でLoRAを行う(AWSやローカルGPUを使用)場合、環境構築の手間はありますが、学習データが自社インフラから出ることがなく、作成したモデルを完全に所有・配布できます。機密情報を扱う場合は自前LoRAが推奨されます。

ファインチューニングすればハルシネーション(嘘)はなくなりますか?

A: なくなりません。むしろ悪化するリスクがあります。
ファインチューニングは「それっぽい文章を作る能力」を高めるため、事実ではないことも自信満々に語る「流暢な嘘つき」になる可能性があります。
事実の正確性(Factuality)を担保したい場合は、必ずRAG(外部情報の参照)を併用し、モデルには「検索結果に基づいて回答する」という振る舞いをFTで教え込むのが定石です。


まとめ

ファインチューニングは、AIモデルを「ただの物知り」から「頼れる実務パートナー」へと進化させるための強力な手段です。しかし、それは魔法ではなく、地道な「データの準備」と「適切な手法(LoRAやDPO)の選択」によって成り立っています。

  • 知識を入れたいならRAG
  • 振る舞いを変えたいならSFT (LoRA)
  • 価値観を磨きたいならDPO

この使い分けを意識し、まずは小規模なLoRA学習から始めてみてください。たった数百件のデータセットでも、あなたのモデルは見違えるような「プロの顔」を見せてくれるはずです。

Yachi

生成AI開発は「習うより慣れろ」の世界です。まずはHugging Faceにある小さなモデルと、数十件のデータでLoRAを回してみてください。「あ、本当に口調が変わった!」という小さな体験から始めてみましょう。

この記事を書いた人

生成AIコンサルタント / テックリード

外資系IT企業にて社内の生成AI活用推進と
生成AIプロダクト開発リードを担当。

かつてはWeb系のエンジニアとして、
モダンな技術スタックでのシステム開発から
数百億レコード規模のデータベース運用までを
フルスタックに経験。

「コードも書けるコンサルタント」として、
活用論と実装論の両面から、
現場で使えるIT知識を発信します。

私と本サイトの詳細は運営者情報をご確認ください。

Contents