ファインチューニングとは｜RAGとの違いと、先に試すべきことの順番

結論から言うと、ファインチューニングは「AIの答え方の癖を作り替える作業」であって、「AIに新しい知識を覚えさせる作業」ではありません。ここを取り違えたまま検討に入ると、まず確実に遠回りします。

私が最初に誤解したのもここでした。社内の情報をAIに答えさせたい、という話を「じゃあ学習させればいい」と受け取ってしまい、データを揃える算段まで立てたところで、そもそも用途が違うと気づいた。同じ勘違いをしている人をその後も何度か見たので、まずその線引きから書きます。

結論

多くの業務課題は、実のところ3番目まで行きません。私が関わった範囲では、プロンプトの書き方と、出力を確認する手順を決めるところで解決してしまうものがほとんどでした。

ファインチューニングが実際にやっていること

Microsoft の解説では、ファインチューニングは学習済みのモデルを、特定のタスク向けに、小さめの専用データで追加学習させ、重みを少し調整する処理と説明されています。ゼロからモデルを作るのではなく、既にある土台を目的に寄せる、という位置づけです。

得られる効果として挙げられているのは、だいたい次の3つです。

• 精度が上がる：そのタスクの例で訓練するぶん、汎用のプロンプトより狙った出力に近づく
• プロンプトが短くなる：例をプロンプトに毎回並べる必要が減り、トークン数と応答時間が下がる
• 小さいモデルで足りるようになる：特定タスクなら、大きいモデルに近い性能を安いモデルで出せる場合がある

3番目は見落とされがちですが、運用コストの話としては一番効きます。大きなモデルの出力を使って小さなモデルを訓練する「蒸留（Distillation）」という形も、公式ドキュメントに具体例つきで載っています。

向いている用途

Azure OpenAI のドキュメントは、ファインチューニングが効く場面をかなり具体的に列挙しています。私が読んで納得したのは次のあたりです。

場面	なぜ効くか
プロンプトが長くなりすぎている	例外パターンを継ぎ足した結果の長大な指示を、モデル側に持たせられる
口調・トーンを揃えたい	問い合わせ対応やブランド表現の一貫性を保てる
決まった形式で出力させたい	特定のフォーマットやスキーマでの出力を安定させられる
使えるツールが多すぎる	ツール定義を全部書かなくても呼び分けの精度が上がる

共通しているのは、「正解のかたち」が決まっていて、それを何度も繰り返す仕事だという点です。逆に言えば、毎回答えが変わるもの、正解が状況次第で決まるものには噛み合いません。

向いていない用途

一番多い誤用が、冒頭に書いた「知識を入れる」です。Microsoft の比較記事は、選び方をこう整理しています。

• ファインチューニングを選ぶ：特定タスクの性能が要る／独自性の高いデータがある／内容が頻繁に更新されない
• RAGを選ぶ：最新の情報が要る／扱う話題が広い／学習用のデータや計算資源が限られている

社内規程やマニュアルは改訂されます。価格表は変わります。それらを学習に埋め込むと、改訂のたびに学習をやり直す運用になり、しかも古い内容を自信たっぷりに答える状態が生まれます。この失敗のかたちはAIハルシネーション対策で書いたものと同じで、間違い方としては最悪の部類です。

RAGとの違いと、組み合わせ方

	何を変えるか	更新のしかた
RAG	答えるときに読ませる材料	元の文書を差し替えれば即反映
ファインチューニング	モデル自身の答え方	再学習が必要

この表のとおり、触っている層が違います。仕組みそのものはRAGとはのほうで書いたので、ここでは選択の話に絞ります。

両者は排他ではありません。Azure OpenAI のドキュメントには、検索で取ってきた情報をうまく使い、関係のない情報を無視するようモデルを訓練するという組み合わせ方が挙げられています。材料はRAGで渡し、その材料の扱い方をファインチューニングで仕込む、という分担です。

ただ、これは順番として最後にくる話です。RAGが動いていないうちから両方に手を出すと、うまくいかなかったときにどちらが原因か切り分けられなくなります。私は、片方ずつしか変えないようにしています。

見落とされやすいコスト

公式ドキュメントは利点だけでなく、課題もはっきり書いています。読んでおいたほうがいいのは次の5点です。

1. データの質と量：対象領域を代表する、質の高いデータが十分に要る。足りない・偏っていると、過学習や偏りを起こして汎用性が落ちる
2. 学習とホスティングの追加費用：作って終わりではなく、そのモデルを置いておく費用がかかる
3. 入出力ペアの整形：フォーマットの作り方が性能と使い勝手を左右する
4. 再実行が要る：データを更新したとき、そしてベースモデルが新しくなったときにやり直しになる
5. 試行錯誤が前提：ハイパーパラメータの調整に実験と検証を繰り返す必要がある

4番が、検討段階では一番過小評価されていると感じます。基盤モデルは更新され続けます。「一度作れば終わり」ではなく、追いかけ続ける対象がひとつ増えるという理解が要ります。

2026年8月時点の状況

ここは事情が動いているので、確認できた事実だけ書きます。

OpenAI の公式ドキュメントには、同社がファインチューニングのプラットフォームを縮小しており、新規ユーザーには開放されていないと明記されています。既存の利用者は今後数か月はトレーニングジョブを作成でき、作成済みのファインチューニング済みモデルは、ベースとなるモデルが廃止されるまで推論に使える、という案内です。

一方で、Azure OpenAI 側にはファインチューニングの提供が続いており、教師ありファインチューニング（SFT）や、推論モデル向けの強化ファインチューニング（RFT）などの手順がドキュメント化されています。学習データは JSONL 形式で用意する、という点は共通です。

つまり、「どこでやるか」で前提がまるごと変わる状態です。この記事を読んだ時点でも状況が動いている可能性があるので、検討するなら、使う予定のサービスの公式ドキュメントを必ず自分で開いてください。私はこの一件で、基盤の提供方針そのものがリスク要因になるということを学びました。

手を出す前に踏む順番

OpenAI のドキュメントも、評価 → プロンプト → 必要に応じて学習、という流れで説明しています。私が実際に使っている順番も、ほぼ同じです。

1. 良し悪しを測る方法を先に決める：何をもって「うまくいった」とするかが無いと、学習しても改善したか分からない
2. プロンプトで詰める：出力例を数個渡す形（few-shot）まで含めて試す。プロンプトのコツで書いた要素を先に潰す
3. 材料の問題ならRAG：知識不足・情報が古いことが原因なら、学習ではなく検索側の問題
4. それでも残る癖にだけ学習を当てる：長すぎるプロンプト、揃わない形式、といった限定的な対象に絞る

1を飛ばすと、あとで判断できなくなります。「なんとなく良くなった気がする」で数十万円かかる意思決定はできません。

やめておいたほうがいい条件も挙げておきます。

• 同じ形の仕事が月に数回しかない：作る手間と維持の手間が上回る
• 質の揃った事例を数百件そろえられない：データが足りないまま進めても精度が出ない
• 正解が人によって割れる：何を学習させるかで揉めて、そもそも進まない

3番目は技術ではなく合意の問題です。生成AI導入の落とし穴でも書きましたが、決まっていないことは、そのまま設計の穴として残ります。

こうした「どの手段をどの順で当てるか」の判断は、個人で試すぶんには手を動かせば分かってきます。ただ、組織として導入する話になると、評価の設計やデータの扱いまで含めて整理が要るので、講座などで一度体系立てて押さえる選択肢もあります。

もう一つ、手を動かして身につけたあとの話をしておきます。RAG やファインチューニングの当て分けを判断できる人は、いま実務側で足りていません。会社の仕事だけで場数を踏むのは難しいので、副業や業務委託の案件で「AIを組み込む側」の経験を取りにいくのは現実的な手です。どんな案件があるか、単価がいくらかを見るだけでも、いま自分に足りない要素がはっきりします。

私の結論

ファインチューニングは、モデルの答え方を作り替える手段です。知識を新しくする手段ではないし、賢さを底上げする万能薬でもありません。

そして、多くの場合は出番が来ません。私が見てきた範囲では、プロンプトの設計と、出力を確認する手順を決めるところで大半が片づきました。それでも残った「毎回同じ形で、同じ癖で答えてほしい」という要求に対してだけ、検討する価値がある。

もう一つ、今回調べ直して考えを変えたことがあります。基盤側の提供方針は変わります。自分たちの仕組みが、他社の一機能の存続に依存していないかを、導入判断の材料に入れておくべきでした。外部システムとのつなぎ方についてはMCPとはでも触れましたが、依存先を増やす判断は、増やす前にしか止められません。