ファインチューニングと蒸留

この記事の目的

ファインチューニング(fine-tuning、FT)と蒸留(distillation)を「いつ選ぶべきで、いつ選ぶべきでないか」から判断できるようになります。プロンプト・RAG外部の知識ソースを検索し、結果を LLM の入力に加えて回答の根拠にする手法。検索の判断を Agent に任せる構成は Agentic RAG と呼ばれる。 との使い分け、手法の概観(SFT「指示 → 望ましい応答」の模範例で LLM を追加学習させる工程。指示追従・形式・文体を調整し、新しい事実も学習し得るが、正確な再現や容易な更新は保証されない。鮮度・出典・権限が重要な知識は検索との比較・併用を検討する。・選好最適化・蒸留)、データ準備、そして FT 資産の運用(ベースモデル更新との共存)までを扱います。2026-08 時点で API 各社の FT 提供メニュー自体が縮小・限定される傾向にあり、「そもそも提供されているか」も判断材料になる、という現実も含めて整理します。

対象読者

• 「プロンプトでは品質が頭打ちなので FT したい」という要望の妥当性を判断するエンジニア・テックリード
• 小型モデルへの置き換え(コスト・レイテンシ削減)を蒸留で実現できないか検討しているエンジニア

前提知識

• モデル選定ガイド — FT・蒸留は「モデル選定の延長」にある手段
• Agent 向けプロンプト設計 — FT の前に尽くすべき第一手段
• 評価データセットの構築と保守 — FT の成否を判定するにも学習データを作るにも必要な規律

本文

概要: FT は「最後の手段」になりやすい

ファインチューニングとは、既存モデルの重みを自分のデータで追加調整することです。強力に聞こえますが、実務では最後の手段になりやすい手段です。理由は 4 つあります。

1. 頻繁に変わる事実の管理には不利です: FT でも新しい事実を学習できますが、更新・削除には追加学習や再構築が必要になり、正確な再現は保証されません。新しい事実の学習と幻覚モデルが事実でない内容をもっともらしく生成する現象。「もっともらしい続きを生成する」という学習目的の自然な帰結であり、対策は指示の強化ではなく、根拠の外部供給(RAG)・出典要求・検証という構造側にある。増加を報告した実験もあります(参考資料)。鮮度・出典・閲覧権限が重要な社内情報は、まず RAG と比較します。FT と検索を併用する設計も可能です
2. 資産がモデル世代に固定されます: FT 済みモデルはベースモデルの世代に紐づき、ベースの退役とともに作り直しになります。モデル更新の速い時代には維持費の高い資産です
3. 投資が大きい: 質の高い学習データの準備・評価・再チューニングの運用は、プロンプト改善より桁違いに重い投資です
4. 提供の前提が変わりやすい: 2026-08 時点では、API 経由の FT はフロンティア(最上位)モデルを対象にしないのが通例で、提供メニューの縮小・限定も起きています(後述)。FT 前提の設計はベンダー提供の継続というリスクを抱えます

まず押さえるべき使い分けの原則です。

FT を選ぶ前のチェックリスト

FT の検討に入る前に、次をすべて確認します(主要ベンダーも「評価 → プロンプト改善を先に、FT は最後」という順序を公式に案内しています)。

• 評価データセットがあり、現状の品質を数値で説明できる(これがないと FT の成否も判定できません)
• プロンプト改善(指示の明確化・few-shot 例・構造化)を評価付きで試し、頭打ちの証拠がある
• 知識・鮮度の課題を切り分け、RAG との比較または併用の必要性を評価した
• 上位モデル・別モデルへの変更で足りないことを確認した(FT の開発・運用コストより、単価の高いモデルの方が安いことは珍しくありません)
• タスクが明確に定義され、良質なラベル付きデータを用意できる
• 使いたいモデルに FT の提供経路がそもそも存在する(2026-08 時点、後述)
• ベースモデル更新時の再チューニング(データ・評価・ジョブのやり直し)を運用として引き受けられる

手法の概観

基本的な指示追従が不足する場合は、SFT で挙動を整えてから、必要なら選好最適化で仕上げる構成を検討します。既に指示調整されたモデルなら追加 SFT が不要な場合もあり、開始モデルの能力と評価結果から工程を選びます。

提供状況(2026-09-10 確認) は流動的で、ここは「原則」ではなくスナップショットとして読んでください(一次情報発信源そのものの情報(論文の原典・公式ドキュメント・公式ブログ・規格本文・法令)。解説・まとめ(二次情報)と区別し、根拠は一次情報に置くのが情報リテラシーの基本。二次情報は「存在を知る」までに使い、一次まで遡って確かめる。の記録: research/professional/fine-tuning.md)。

• API 経由の FT は、提供されている場合でも対象モデルと手法が限定されるため、モデル世代名だけでは判断できません
• 提供メニューの縮小も現実に起きています。ある大手は FT プラットフォームの新規受付を停止し縮小を告知しており、段階的な終了日程(既存顧客も 2027-01 には新規の FT ジョブを作成できなくなる)も公表済みです。別の大手は第一者 API で FT を提供していません(従来の Bedrock Claude 3 Haiku 経路も告知 EOL 期日 2026-09-10 を経過。実施範囲は下表・TODO 参照)。一方で、クラウド ML 基盤側は SFT・選好・蒸留を比較的広く提供しています
• オープンウェイトモデルは自前 FT の自由度が最大で、LoRA などの効率的な手法で自社インフラ・マネージド基盤の両方から実施できます(主要 LLM の全体像)。「FT が本当に必要な要件」がある場合、モデル選定がオープンウェイトに寄る一因になります

蒸留によるコスト削減

蒸留とは、上位モデル(教師)の出力を学習データにして、小型モデル(生徒)を SFT する手法です。Agent の文脈では「ティア混在設計(モデル選定ガイド)の発展形」と捉えると位置づけが明確になります。

• 使いどころ: 上位モデルで品質が確認できた特定のタスク(分類・抽出・定型応答など)を、小型モデルで安く・速く量産したいとき。タスクが絞られているほど効きます
• ワークフロー: (1) 本番で上位モデルの入出力を収集する → (2) 評価で良い出力だけを選別する → (3) それを教師データに小型モデルを SFT する → (4) 同じ評価セットで教師とのギャップを測る。入出力の保存と評価がこのループの前提インフラです
• 注意点: 教師の誤りもそのまま学びます(収集データの選別が品質を決めます)。また、入力の分布が変わると生徒の品質は静かに劣化するため、本番分布の監視と再蒸留の運用が要ります
• 蒸留も最終段は SFT なので、FT の提供状況・制約(前節)がそのまま適用されます

データ準備

FT の成否はデータの質で決まります。ここは評価データセットの構築と保守の規律がそのまま流用できます。

• 量より質・分布: 公式の目安として「最低 10 例から動くが、意味のある改善は 50〜100 例あたりから」という規模感が示される例があります。数を稼ぐより、本番の入力分布を代表し、模範出力の品質が揃っていることが重要です
• 形式: チャット形式(system / user / assistant のメッセージ列)の JSONL が一般的です。本番と同じプロンプト構造で作ります(学習時と推論時の形式がずれると効きません)
• 学習用と評価用を分離する: 評価セットのケースを学習データに混ぜると、改善の測定が「カンニング済みの試験」になります(汚染防止)
• 本番ログから採るならマスキングを通す: 個人情報・機密の除去は評価データセットと同じ前提条件です

評価と運用

• FT 前後を同じ評価スイートで比較する: FT の投入判断は「学習が収束した」ではなく、評価セットでの改善と、既存能力の劣化(意図しない挙動変化)がないことの両方で行います(回帰テストと CI 組み込み)
• ベースモデル更新と共存する: FT 済みモデルは「ベースが退役するまで使える」のが通例で、ベース更新時は新ベースでの再チューニング + 再評価が必要です。これはバージョニング・デプロイ・モデル更新追従の「モデル更新は期限付きの計画タスク」に、再チューニング工程が加わるということです
• 再現可能性を保つ: 学習データセット・ジョブ設定・ハイパーパラメータをバージョン管理し、「このモデルは何から作られたか」を追跡可能にします(プロンプトと同じ資産管理の規律です。プロンプト資産の管理とバージョニング)
• FT してもプロンプトは要る: FT は挙動の傾向を調整するもので、指示・文脈が不要になるわけではありません。FT 後のプロンプトは軽くできることが多い一方、FT とプロンプトの役割分担を評価で確かめながら調整します

FT 経路の提供状態をモデル単位で照合する

2026-09-10 確認の具体例です。モデル提供の GA とチューニング手法の GA は別に管理します。

Bedrock の既存カスタムモデルのオンデマンド配備、既存 PT、基盤モデルの EOL はそれぞれ条件を確認します。EOL 当日の実停止はここでは実呼出し検証していません。地域別の状態と個別契約がある場合の扱いも、AWS の対象行と契約で確認します。Google SFT の SLA 対象外という条件も、本番学習工程の可用性設計に含めます。

実務での注意点

アンチパターン

チェックリスト

関連トピック

• モデル選定ガイド — FT・蒸留の手前にある「モデルを変える」という選択肢とティア混在設計
• RAG 実装パターン — 知識の問題を解く第一選択
• Agent 向けプロンプト設計 — FT の前に尽くす第一手段
• 評価データセットの構築と保守 — 学習データ・評価データに共通する規律
• バージョニング・デプロイ・モデル更新追従 — ベース退役の追跡と FT 資産の更新運用
• 主要 LLM の全体像 — オープンウェイトという自前 FT の選択肢
• 学習用合成データの実務 — FT・蒸留・選好調整複数の応答への人間(または AI)の選好から「良い応答」の基準を学ばせる LLM の学習工程(RLHF・DPO など)。有用さ・無害さ・トーンを形作る一方、迎合(sycophancy)や過剰な拒否の由来にもなる。に使うデータの作り方(本記事のデータ作成側)
• 小型言語モデル(SLM)の活用戦略 — 蒸留で小型モデルを得意領域に強くする戦略側
• セルフホスト推論の実務 — FT した独自モデルを実際に動かす提供層
• MLOps と LLMOps の統合 — FT を始めた組織が既存 ML 基盤と合流する点
• 「自社モデルを持つか」の判断 — FT・継続事前学習既製モデルを大量のドメインコーパスで追加的に事前学習し、特定分野の言語・知識に適応させる手法。FT より重く、「自社モデルを持つ」段階の 1 つ。ベース世代の交代のたびに追従コストがかかる。への投資を経営判断として扱う上位記事

参考資料

• 提供仕様・終了日程: docs.cloud.google.com (アクセス日: 2026-09-10)

• 提供仕様・終了日程: docs.cloud.google.com (アクセス日: 2026-09-10)

• 提供仕様・終了日程: docs.aws.amazon.com (アクセス日: 2026-10-03)

• Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?  — 新しい事実の SFT 学習と幻覚への影響を、閉じた QA の条件で評価した研究(アクセス日: 2026-09-10)

• Model optimization(OpenAI)  — 「評価 → プロンプト → FT」の順序と FT 手法の整理(2026-07 時点で FT プラットフォームの縮小が告知されている点も含め)(アクセス日: 2026-07-07)

• Vertex AI のモデルチューニング(Google)  — SFT・選好・蒸留(教師 → 生徒)というメニュー構成の例(アクセス日: 2026-07-07)

• Amazon Bedrock: Fine-tune a model  — クラウド基盤経由の FT 対象モデル一覧の例(アクセス日: 2026-07-07)

• Glossary: Fine-tuning(Anthropic)  — 第一者 API で FT を提供していない旨の公式記載(アクセス日: 2026-07-07)

TODO・未確認事項

変わりやすい項目(定点観測)

• FT プラットフォームの提供継続・新規受付の状況(終了日程公表済み(2027-01-06)・完了の実施確認は次回観測)
• FT 対象モデルの世代(旧世代限定の傾向が続くか)と、蒸留機能の GA / preview 状態
• オープンウェイト側の FT 手法・マネージド提供の広がり