ファインチューニング（FT）は、すでにあるモデルに追加の学習をさせて、口調や出力フォーマット、特定タスクの精度を自分用に寄せていく技術です。中でも LoRA と、それをさらに省メモリにした QLoRA は、GPU を 1〜2 枚しか使えない環境でも実用的に回せるため、いまや個人やスタートアップの定番になりました。本ガイドは「いつ FT を選ぶか」から、手法の違い・データの作り方・主要サービス・実施手順・つまずきどころまでを、図とともに実務目線で整理します。
大前提として、FT は「知識を足す」技術ではなく「振る舞いを寄せる」技術です。ここを取り違えると、時間とお金をかけたのに成果が出ない、という失敗に直結します。最初の節で向き不向きをはっきりさせます。
01そもそも FT が効くのはどんなときか
「精度が足りない＝とりあえず FT」と考えがちですが、FT・RAG・プロンプト設計は役割が違う道具です。FT が向く問題と、別の手段のほうが速くて安い問題を、最初に切り分けます。
FIG.1 「指示で直る／知識が足りない／振る舞いを寄せたい」で道具を選ぶ
FT が向くのは、出力の「形」や「クセ」を毎回そろえたいケースです。
- 会社固有の口調・トーンを一貫させたい（広報文、サポート返信など）
- 毎回きっちり同じ出力フォーマット（決まった JSON 構造、定型レポート）を守らせたい
- 分類・抽出・タグ付けなど、入力と正解の型が決まったタスクの精度を底上げしたい
- 特定ドメインの言い回しや専門用語に慣れさせたい
- 小さめのモデルを自社タスク専用に鍛え、推論コストと遅延を下げたい
逆に向かないのは、次のようなケースです。
- 新しい知識を覚えさせたい → 最新の社内文書や仕様は RAG（検索で根拠を渡す）のほうが正確で、間違いの追跡もしやすい
- 頻繁に更新される情報 → 情報が変わるたびに学習し直すのは非現実的。RAG なら再学習不要
- 一度きり・少量のカスタマイズ → まずはプロンプトに例（few-shot）を入れて様子を見るので十分なことが多い
FT は知識を「教える」のではなく、出力の型と語り口を体に覚えさせる作業に近い。
02主要な手法：Full・LoRA・QLoRA
FT のやり方はいくつかありますが、実務でまず押さえるのは Full Fine-tuning・LoRA・QLoRA の 3 つです。違いは「どこまでのパラメータを動かすか」と「必要な GPU メモリ」です。
FIG.2 動かす範囲を絞るほど、必要な GPU は軽くなる
Full Fine-tuning（全パラメータ更新）
モデルの全パラメータを学習し直す、最も「重い」やり方です。GPU を何枚も使い、数日〜数週かかることもあります。最新の巨大モデルでは現実的でなく、中規模のオープンモデル（例：Llama 3.1 8B クラス）でようやく手が届く規模感。品質は最も高くなり得ますが、コストとデータ量の要求が大きいため、多くの現場では次の LoRA で十分です。
LoRA（Low-Rank Adaptation）
モデル本体の重みは凍結したまま、各層に小さな「追加行列」を差し込み、その部分だけを学習します。動かすパラメータは元の数千分の一以下になり、それでも多くのタスクで Full の9〜9.5 割程度の品質に届くのが強みです。
- 保存サイズが小さい：学習結果（アダプタ）は数十 MB 程度。フルモデルの数十 GB と比べて持ち運びが楽
- 学習が速い・安い：GPU 1〜2 枚・数時間で回せることが多い
- 差し替えが容易：1 つの土台モデルに対し、用途別のアダプタを複数用意して読み込み時に切り替えられる
2026 年時点の定番設定としては、ランク r=16 前後・対象を全 linear 層に広げる、といったところから始め、必要に応じて調整するのが扱いやすい出発点です（最適値はタスク・データ量で変わるため、必ず検証して決めます）。
QLoRA（4-bit 量子化 + LoRA）
QLoRA は、凍結した本体を 4-bit（NF4 という形式）に圧縮してメモリに載せ、その上で LoRA を学習する手法です。これにより必要な GPU メモリが大きく下がり、コンシューマ向け GPU でも大きめのモデルが扱えるようになります。目安として、7B クラスは 16-bit で約 14GB 必要なところが 4-bit では 5〜6GB に、70B クラスは約 140GB が 50GB 弱まで圧縮できる、という報告があります。
圧縮の代償として品質はわずかに下がり（Full の 8〜9 割程度が目安）、純粋な LoRA より一段落ちることもありますが、「手元の GPU で大きいモデルを試せる」価値のほうが大きい場面が多く、個人開発の主力になっています。
その先の手法（DoRA など）
LoRA をさらに改良した手法も実用域に入っています。代表が DoRA（重みを「大きさ」と「向き」に分けて調整する LoRA の発展形）で、推論時の追加コストなしに LoRA より Full に近づける、と報告されています。ほかにも GaLore・PiSSA・VeRA など選択肢は増えていますが、まずは LoRA / QLoRA を基準に、物足りなければ DoRA を試す、という順番が無難です。
03学習データの作り方
FT の成否はデータで 9 割決まります。手法の細かいチューニングより、まず「良い例を揃える」ことに時間を使うべきです。
形式
対話モデルの FT では、1 行 1 サンプルの JSONL が標準です。会話のやり取りを messages 配列で表します。
{"messages": [
{"role": "system", "content": "あなたは丁寧な営業担当です"},
{"role": "user", "content": "見積をください"},
{"role": "assistant", "content": "承知しました。まず利用人数と..."}
]}分類や抽出タスクなら、user に入力文、assistant に「望ましい出力（ラベルや JSON）」をそのまま入れます。本番で出してほしい形そのものを正解側に書くのがコツです。
件数の目安
用途によって必要量は変わりますが、最初の感覚として次くらいを目安にします（少なく始めて、効果を見て増やすのが安全）。
| 用途 | 最初の目安件数 |
|---|---|
| 口調・トーンをそろえる | 100〜500 件 |
| 抽出タスク（要素の取り出し） | 500〜2,000 件 |
| 分類タスク | 1,000〜5,000 件 |
| 専門ドメインへの適応 | 3,000〜10,000 件 |
量より品質
ここが最重要です。件数を増やすより、間違いのない例をそろえるほうが効きます。「きれいな 500 件は、ノイズ混じりの 5,000 件に勝つ」とよく言われるのは、モデルがデータの間違いまで忠実に学んでしまうからです。1,000 件のうち 10% に誤りがあれば、その誤りごと再現するモデルができ上がります。新規データを大量に集める前に、まず既存の少数例を点検しましょう。
04主要なサービスと選び方
FT は自前の GPU でも、マネージドサービスでも実施できます。2026 年時点の選択肢を、提供形態ごとに整理します。各社の対応モデルや料金は頻繁に変わるため、着手前に必ず公式の最新情報を確認してください。
クラウド型・オープンモデル
Together AI / Fireworks AI が代表。Llama・Qwen・Mistral などを LoRA で学習し、そのまま推論まで使える。手早く試したいとき向き。
クラウド型・各社モデル
Google は Vertex AI で Gemini / Gemma を LoRA でチューニング可能。Anthropic の Claude は自己サービスの FT API は提供せず、Amazon Bedrock 経由や法人向けカスタム提供が中心。
セルフホスト
Hugging Face PEFT・Axolotl・Unsloth・TRL などで自前の GPU 上に構築。Unsloth は省メモリ・高速化で人気。一番自由で、運用責任も自分持ち。
かつて FT の入門先として定番だった OpenAI のファインチューニングは、2026 年に大きく動きました。対応モデルは GPT-4o 系から GPT-4.1 系へ移り、さらにファインチューニング API 自体が縮小・終了の方向へ向かっています（新規受付の停止が告知されています）。これは「特定ベンダーの FT API に依存しすぎない」ことの重要さを示す例でもあります。OpenAI で FT を検討していた用途は、オープンモデル＋クラウド FT（Together / Fireworks 等）や、そもそも FT が要るのかの再点検（RAG・プロンプトで足りないか）に振り直すのが現実的です。
コスト感（あくまで目安）
料金は変動が激しいので正確な数字は各社の料金ページで確認するのが前提ですが、規模感をつかむために 2026 年時点の傾向を挙げます。
- クラウド LoRA：学習トークン課金が一般的。小さめモデル（〜16B 級）は概ね 1M トークンあたり $0.5 前後から、70B 級になると数 $ 規模に上がる傾向
- OpenAI 系：モデルにより 1M 学習トークンあたり $1〜$3 程度（nano が安く、上位ほど高い）。ただし上述のとおり提供縮小中
- セルフホスト QLoRA：GPU の時間貸し。ハイエンド GPU を数時間借りるオーダー
- 推論側の追加費用も忘れない：FT 済みモデルの推論は素のモデルより割高になる場合がある（提供形態により倍率が異なる）
05実施手順
どのサービスを使っても、進め方の骨格は共通です。小さく回して、評価で確かめてから広げるのが鉄則です。
用途を 1 つに絞る
口調？分類？フォーマット固定？を明確に。欲張ると評価がぼやけて改善できなくなる。
学習データを用意
まず 100〜1,000 件の高品質な例から。本番で出したい形そのものを正解側に書く。
検証データを切り出す
全体の 10〜20% を学習に使わず取り置き、過学習や効果を測る物差しにする。
学習を実行
loss の推移を見ながら回す。検証 loss が下げ止まり・反転したら過学習のサイン。
評価セットで効果を確認
固定の「お手本問題集（Golden Set）」で、FT 前後の改善幅を数字で比べる。
段階的に本番投入
一部トラフィックで A/B 比較し、悪化していないかを観測。いきなり全面切替はしない。
ロールバック手段を確保
問題が出たら即座に旧モデル（素のモデル or 旧アダプタ）へ戻せる導線を用意しておく。
Common Pitfalls
FT が失敗するときの典型パターン
うまくいかない理由はだいたい決まっています。先に知っておくと回避できます。
FIG.3 学習データだけ良くなり、未知の入力で悪化し始める点が「やりすぎ」の境界
- 量ばかり増やして品質を見ない：誤った例を学び、間違いを再現するモデルになる
- 過学習：学習データの言い回しにしか答えられず、少し違う入力で崩れる
- 知識を入れたつもりが入っていない：FT は振る舞いの調整。最新情報や事実の追加は RAG の役割
- 土台モデルの世代交代で陳腐化：ベースが新しくなると、旧アダプタは作り直しになりがち。再学習しやすい仕組みにしておく
06まとめ
ファインチューニングは、口調・出力フォーマット・決まったタスクの精度を自分用に固定したいときに力を発揮します。逆に「新しい知識を足したい」「情報が頻繁に変わる」なら RAG、「指示の工夫で直る」ならプロンプト設計が先です。手法は LoRA / QLoRA を基準に、個人 GPU でも実用的に回せる時代になりました。物足りなければ DoRA などの発展手法へ。
始め方はいたってシンプルです。用途を 1 つに絞り、100〜1,000 件の高品質データを用意し、検証セットで効果を測りながら小さく回す。サービスや料金は移り変わりが速いので（OpenAI の FT 縮小がよい例）、特定ベンダーに固定されすぎず、評価と差し替えのしやすさを設計に織り込んでおくのが、長く使える FT 運用のコツです。
