Fine-tuningとは — PromptやRAGとの使い分けを先に決める

Fine-tuningは、学習済みのLLMへ追加の学習データを与え、重みを更新して振る舞いを変える手法です。

先に結論を書いておくと、Webシステムで出会う課題の多くは、Fine-tuningへ進む前に解決策があります。重みを変える判断は、Promptと外部データで届かないことを評価で確認してからで遅くありません。

このGuideは、2026年7月14日時点の一次情報を基準にしています。手法名やProviderの提供範囲は変わり続けているため、採用時には利用するModel APIの最新の対応を確認してください。

Fine-tuningが得意なこと、苦手なこと

Fine-tuningで変えやすいのは、出力の形式・文体・分類基準といった「毎回同じように振る舞ってほしい」性質です。OpenAIのModel Optimizationガイドも、Fine-tuningの利点として、短いPromptで多様な入力を扱えることや、Token費用の削減を挙げています。

一方、最新の知識や自社データの反映は苦手です。学習した時点の情報で固定され、更新のたびに再学習が必要になります。知識の鮮度が問題なら、RAGやToolで実行時に渡す方が向いています。

手段	変えるもの	向いている課題	更新の速さ
Prompt Engineering	モデルへの入力	指示・例・出力契約の改善	即時
RAG	実行時に渡す知識	鮮度・出典・自社データ	データ更新で反映
Fine-tuning	モデルの重み	形式・文体・分類の一貫性	再学習が必要
蒸留 (Distillation)	小さいモデルの重み	大モデル品質の低コスト化	再学習が必要

Amazon Bedrockのモデルカスタマイズは、ラベル付きデータによるSupervised Fine-tuning、報酬関数を使うReinforcement Fine-tuning、教師モデルから生徒モデルへ転移する蒸留を提供しています。名前は違っても、いずれも「重みを変える」側の手段です。

OpenAIのガイドが示す順序も、評価を作る、Promptで改善する、それでも足りなければFine-tuning、という流れです。Promptの変更は即時に戻せますが、重みの変更は学習・評価・切り戻しのすべてが重くなるためです。

LoRAは、学習済みの重みを凍結したまま低ランク行列だけを学習することで、学習対象のパラメータを大幅に減らす手法です。Fine-tuningの学習コストは、この系統の手法でだいぶ下がりました。

ただし、下がったのは学習の費用です。運用側の負担は残ります。

Providerのベースモデルは更新され続けます。カスタムモデルはその更新へ自動では追従しません。「一度学習して終わり」にならない点が、Prompt改善との一番の違いだと思います。

知識の更新は再学習を意味します。日々変わる業務データや在庫状態は、RAGやToolで実行時に渡す方が現実的です。

先に評価セットと失敗の分類が必要です。指示が曖昧ならPrompt、根拠が無いならRAG、形式が壊れるならStructured Output。重みの問題だと確認できた失敗だけがFine-tuningの対象です。

ベースモデルの更新、入力分布の変化、業務ルールの変更で劣化します。回帰評価と再学習の計画まで含めて運用コストです。

学習データに含めた情報は、出力へ再現される可能性があります。個人情報・秘密情報・権利の確認は、学習前のデータ整備で行います。

EastBraver Labsでは、Prompt、RAGとTool、Fine-tuningの順で検討します。

Fine-tuningを選ぶのは、形式・文体・分類の一貫性が、評価セット上でPromptとRAGでは届かないと確認できたときだけです。感覚ではなく、同じ評価セットの差分で判断します。

採用する場合も、ベースモデルとPromptによる構成を切り戻し先として残します。学習データ・学習条件・評価結果はModel IDと一緒に記録し、ベースモデル更新時に再評価できる状態を保ちます。

重みを変える判断は、戻す手段を持ってから。ここは通常のリリース判断と同じです。