この記事は、ファインチューニング（追加学習）の位置づけと、RAG・プロンプトとの使い分けを整理する実務ガイドです。特定のモデルやサービスへの導入手順、性能向上を保証するものではありません。
「自社の仕事に合うAIにしたい」と考えたとき、ファインチューニングという言葉が出てくる。けれど、プロンプトを工夫すること、外部資料を検索して渡すこと、学習済みモデルへ追加のデータで学習することは、同じ操作ではない。
NISTは、ファインチューニングを事前学習済みモデルへタスクや領域に固有の情報を加える学習段階として整理している。ゼロからモデルをつくるのではなく、すでに学習されたモデルを土台に、目的へ適応させる工程だ。ここでは「AIを賢くする」という一言にまとめず、何を変え、何を変えない方法なのかを分けて考える。
01 ファインチューニングは、学習済みモデルへの追加学習である
ファインチューニングは、学習済みのモデルへ、特定のタスクや領域に関するデータを使って追加の学習を行う。モデルの内部にあるパラメータの振る舞いを調整し、汎用的なモデルを特定の用途へ適応させる工程として扱われる。
大切なのは、入力欄へ指示を送るだけの利用とは層が違うことだ。
| 方法 | 主に変えるもの | 反映される場所 |
|---|---|---|
| プロンプト | その一回の目的、条件、形式 | 推論時に渡す入力と文脈 |
| RAG | 回答へ参照させる情報 | 推論時に検索・追加する外部文脈 |
| ファインチューニング | 特定タスクや領域へのモデルの適応 | 追加学習後のモデルの振る舞い |
この表は技術を完全に分離するものではない。実際には、追加学習したモデルへプロンプトを渡したり、ファインチューニングしたモデルへRAGを組み合わせたりすることもある。最初に役割を分けるのは、目的と手段を取り違えないためだ。
02 「知識を覚えさせる」と「振る舞いを適応させる」は同じではない
ファインチューニングを「社内文書を全部覚えさせる方法」と捉えると、更新、権限、出典の問題が見えにくくなる。学習用データを用意しても、その資料がいつの版なのか、誰が利用を許可したのか、出力から原文へ戻れるのかは別に設計しなければならない。
一方、RAGは、質問に関連する外部データを検索してから、生成モデルへ文脈として渡す構成である。情報源を更新したり、回答に出典を表示したりする経路を設計しやすい場合がある。どちらが優れているかではなく、変えたい対象がモデルの振る舞いなのか、参照する情報なのかを先に決める。
| 変えたいもの | 先に検討する方法 | 残る確認点 |
|---|---|---|
| 回答の形式や分類の傾向 | プロンプト、評価、必要ならファインチューニング | 基準どおりか、例外に耐えられるか |
| 更新される社内規程や資料 | RAG | 検索結果、版、権限、出典 |
| 特定領域の安定した表現 | ファインチューニングの検討 | 学習データの品質、汎用性、再評価 |
これは導入を決める表ではなく、最初の問いをそろえるための整理である。目的が「最新資料を根拠に答える」なら、モデルへ知識を埋め込む前に、検索と出典の経路を設計する必要がある。
03 データの量より、目的と品質を先に見る
ファインチューニングでは、学習させるデータが結果へ影響する。IPA掲載の中核人材育成プログラム卒業プロジェクト資料も、学習データの量と質が性能に大きく関係し、ノイズや重複を取り除くことが重要だと説明している。データを増やすだけでは、望ましい振る舞いが安定するとは限らない。
学習データを考える前に、少なくとも次を残す。
- どのタスクを安定させたいのか
- よい出力と、採用できない出力をどう区別するのか
- どのデータを使う権限と根拠があるのか
- 例外、失敗、未確認を学習データへどう含めるのか
- 学習後に、別のデータでどう評価するのか
とくに、正解らしい例だけを集めると、モデルが条件の違いを見落としたり、常に断定する傾向を学習したりする可能性がある。学習用データは、知識の倉庫ではなく、望ましい振る舞いを説明する設計資料として扱う方が、後の評価につながる。
04 汎用性が下がる可能性も含めて考える
特定の領域へ適応させると、目的に合う出力が得やすくなる可能性がある。一方で、適応させた範囲の外では、もとの汎用性や柔軟さが変わることもある。IPA掲載の中核人材育成プログラム卒業プロジェクト資料も、特化した分だけ汎用性が低下する可能性に注意を促している。
そのため、学習前後で一つの代表例だけを比べるのではなく、次のような複数の問いを用意する。
| 評価する面 | 問い |
|---|---|
| 目的への適合 | 想定したタスクを、基準どおりに処理できるか |
| 例外への対応 | 不明、対象外、入力不足を保留できるか |
| 汎用性 | 目的外の質問で不自然な断定や取り違えが増えていないか |
| 安全性 | 個人情報、秘密情報、権限外の内容を出力しないか |
| 説明可能性 | どのデータと基準で調整したかを追跡できるか |
ここでいう評価表は、公式資料を置き換える規格ではなく、編集部が導入前に置く確認欄の提案である。数値が一つ上がったことだけで、実際の利用に耐えると判断しない。
05 最新情報や出典が必要なら、まずRAGを考える
RAGは、外部のデータベースや文書から質問に関連する情報を検索し、その結果を生成の文脈へ加える。学習済みモデルそのものを更新せずに、参照対象を入れ替えられる設計にできるため、更新される規程、製品情報、社内資料などでは検討しやすい。
ただし、RAGも検索品質と権限の問題を引き受ける。正しい資料を登録しただけでは、質問に必要な箇所が検索されるとは限らない。取得した資料が利用者に表示してよいものか、回答が原文を越えていないか、出典へ戻れるかを確認する必要がある。
ファインチューニングとRAGは競争相手ではない。形式や振る舞いを調整したモデルへ、RAGで更新情報を渡す構成も考えられる。ただし、組み合わせるほど、どの層が出力へ影響したかを評価しにくくなるため、最初は目的を一つに絞る方が追跡しやすい。
06 プロンプトの工夫で解ける問題を先に分ける
ファインチューニングを始める前に、プロンプトと評価の設計で解ける問題かを確認する。目的、読者、入力、出力形式、分からない場合の応答、確認手順を明確にすると、モデルを追加学習しなくても改善できる場合がある。
次の順番で小さく試すと、何が効いたのかを残しやすい。
- 出力の目的と合格条件を言葉にする
- 代表的な入力と失敗例を集める
- プロンプトを変えて、同じ評価セットで比べる
- RAGが必要なら、検索結果と生成結果を分けて確認する
- それでも特定の振る舞いが安定しない場合に、追加学習を検討する
この順番は、すべてのケースに当てはまる決まりではない。学習データを作ること自体が目的にならないよう、改善したい失敗がどこにあるのかを先に特定するための編集部の提案である。
07 ファインチューニングは、導入後も評価を続ける工程である
ファインチューニングは、一度実行して終わる魔法のボタンではない。データの版、評価基準、対象タスク、失敗例、利用者の権限、モデルの更新を記録し、出力が変わった理由を追えるようにする必要がある。
「ファインチューニングとは」を短くまとめるなら、学習済みモデルを特定のタスクや領域へ適応させる追加学習である。RAGは外部情報を検索して文脈へ加え、プロンプトは推論時の入力を設計する。どの方法を選んでも、最後に残るのは、目的・データ・評価・確認の責任だ。
モデルへ何を覚えさせるかを急ぐ前に、何を変えたいのか、何を変えたくないのかを分ける。その境界が見えていれば、ファインチューニングを使う判断も、使わない判断も、後から説明できる形になる。