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

> Fine-tuningの定義、Prompt・RAG・蒸留との使い分け、LoRAなどの手法と、WebシステムでFine-tuningを選ぶ前に確認する評価・運用コストを整理します。

Canonical URL: https://labs.eastbraver.com/guides/fine-tuning
Published: 2026-07-14
Updated: 2026-07-15
Category: field-guide
Tags: llm-inference, model-ops, software-engineering

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

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

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

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

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

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

## 手段を並べると、選ぶ順番が見えてくる

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

[Amazon Bedrockのモデルカスタマイズ](https://docs.aws.amazon.com/bedrock/latest/userguide/custom-models.html)は、ラベル付きデータによるSupervised Fine-tuning、報酬関数を使うReinforcement Fine-tuning、教師モデルから生徒モデルへ転移する蒸留を提供しています。名前は違っても、いずれも「重みを変える」側の手段です。

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

## LoRAが下げたのは学習コスト、運用コストではない

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

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

- 学習データセットの整備と権利・個人情報の確認
- Model Versionと学習条件の記録
- ベースモデル更新時の再学習と回帰評価
- カスタムモデルの提供基盤・リージョン・費用
- 切り戻し先 (ベースモデル + Prompt) の維持

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

## よくある誤解

### Fine-tuningでモデルに最新知識を覚えさせられる

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

### 精度が出ないなら、まずFine-tuningを検討すべき

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

### 一度Fine-tuningすれば効果は続く

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

### 社内データで学習すれば安全に使える

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

## EastBraver Labsの判断基準

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

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

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

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

## 関連記事

- [エージェント運用の検証が主題に](/digest/ai-digest-20260704)
- [AI運用コストと基盤制約を点検](/digest/ai-digest-20260713)
- [モデル選定とエージェント運用が接続](/digest/ai-digest-20260714)

## 検証範囲

- 一次情報: 公式ドキュメント / 研究論文 / 設計面からの分析
- ローカル検証: 概念を整理するGuideなので、コードは動かしていません
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-14: 初版公開