ファインチューニングはもう不要 IBMが解説する「モデル最適化の5ステップ」：IBMが示す生成AI最適化の新常識
「とりあえずファインチューニング」の時代はもう終わったのか？ IBMのマーティン・キーン氏が、ファインチューニングの位置付けの変化について説明した。さらに、実務で推奨されるモデル最適化の手順を紹介した。
自社の業務に特化した生成AIを構築する方法として、これまで有力視されてきたのが大規模言語モデル（LLM）の「ファインチューニング」だ。法律や金融、社内問い合わせ対応などの専門領域では、汎用（はんよう）モデルに独自データを追加学習させることで、業務に適した回答を生成できると考えられてきた。
しかし、汎用LLMの性能向上やコンテキストウィンドウの拡大、RAG（検索拡張生成）などの普及によって、ファインチューニングの位置付けは変わりつつある。
企業はファインチューニングを優先し続けていいのか。それとも、プロンプトやRAG、エージェントスキルによる調整から始めるべきなのか。IBMのマーティン・キーン氏（マネジャー兼IBMテクニカルトレーニングコンテンツクリエイター）が「LLMカスタマイズの現在地」と、「モデル最適化の順序」を紹介する。
LLMカスタマイズの現在地
併せて読みたいお薦め記事
LLMの関連記事
ファインチューニングとは、既に大量のデータで学習した基盤モデルに対し、特定分野のデータを使って追加学習を実施する手法だ。
基盤モデルには、インターネット上の文書などから得た一般的な知識がモデルの「重み」として組み込まれている。そこに法律契約書や社内のサポート履歴など、特定分野に絞ったデータを追加して学習させることで、狭い領域のタスクに強いモデルを構築する。キーン氏によると、2023年時点ではこの方法が専門分野において大きな成果を上げていた。
そこでキーン氏は、ある法律分野のAI企業の事例を紹介した。同社は、フロンティアモデルの開発企業と連携し、法律業務向けの独自モデルを構築した。弁護士を対象にしたブラインドテストでは、同社の専用モデルが、当時の代表的な汎用モデルである「GPT-4」よりも高く評価された。弁護士は97％の割合で、GPT-4ではなくファインチューニング済みモデルの回答を選んだという。
この結果だけを見れば、専門業務で汎用モデルの回答が不十分な場合は、自社データでファインチューニングすることが合理的に見える。
2025年には汎用モデルが独自モデルを逆転
ところが、キーン氏によるとその後数年で状況は変化したという。
法律業務向けの独自モデルを構築したAI企業は2025年、独自のベンチマークを作成した。ファインチューニング済みの専用モデルと、その時点で利用可能だった複数の汎用フロンティアモデルを比較するためだ。
その結果、法務分野のデータで特別に追加学習していない7つの汎用モデルが、同社の専用モデルを上回った。2023年にはGPT-4よりも高く評価されていた独自モデルが、その後に登場した一般的なモデルに追い越されたことになる。
金融分野でも同様の事例がある。金融情報サービスを手掛けるBloombergは、金融データを使って「BloombergGPT」をゼロから学習させた。しかし、その後の評価では、GPT-4やChatGPTが複数の金融ベンチマークでBloombergGPTを上回ったという。
これは、ファインチューニング自体に効果がないという意味ではない。問題は、汎用モデルの進化が速く、専用モデルの開発や評価、導入を進めている間に、新しい汎用モデルが性能を追い越す可能性があることだ。
汎用モデルが専門モデルに追いついた3つの理由
汎用モデルが、法律や金融などの専門領域でも高い性能を出せるようになった背景には、主に3つの変化がある。
1つ目は、コンテキストウィンドウの拡大だ。キーン氏によると、初期のGPT-3が一度に処理できる情報量は約2000トークンだった。一方、フロンティアモデルには、100万トークンを超える入力を扱えるものもある。入力上限が拡大したことで、数百ページに及ぶ法律文書や業務資料を、モデルの重みに学習させなくても、質問とともに直接読み込ませられるようになった。
例えば、契約書の内容をモデルに覚え込ませる代わりに、分析対象の契約書をその都度プロンプトに追加し、「責任範囲に関する条項を抽出する」「標準契約との差異を説明する」といった処理を実行できる。
情報をモデルの内部に固定的に保存するのではなく、必要なときに必要な資料を渡す設計が現実的になったことで、ファインチューニングの必要性は低下しつつあるとキーン氏は評価する。
2つ目は、推論能力の向上だ。従来のLLMは、学習済みの情報を基に、確率的に続きの文章を生成する性質が強かった。これに対して推論モデルは、回答を出す前に複数の手順を検討する「Extended thinking」と呼ばれる処理を実行する。
これにより、モデルは過去に何を学習したかだけでなく、質問を受けた時点で問題を分解し、条件を比較しながら回答を導き出せるようになった。専門知識を追加学習させなくても、十分な資料と指示を与えれば、その場で高度な分析や判断を実行できる場面が増えている。
3つ目は、汎用モデルの進化速度と推論コストの低下だ。汎用モデルは継続的に高性能化する一方、利用料金や処理コストも低下している。企業が独自モデルの学習データを収集し、学習、評価、導入までを進めている間に、新しい汎用モデルが登場する可能性がある。
独自モデルを公開した時点では高性能でも、次世代の汎用モデルに短期間で追い越されれば、追加学習に投じた費用を十分に回収できない。
さらに、基盤モデルの更新に合わせて専用モデルを再学習し、精度低下や意図しない挙動がないかどうかを評価し直す必要もある。ファインチューニングは一度実施して終わる作業ではなく、継続的な維持コストを伴う。
モデルの重みを変えずに専門性を高める
汎用モデルの性能が向上しただけでなく、モデルの重みを書き換えずに専門性を持たせるカスタマイズ手法が普及したことも、ファインチューニングの位置付けを変えている。
代表的な方法がRAG、コンテキストエンジニアリング、エージェントスキルだ。
RAGで最新情報や独自情報を与える
RAGでは、ユーザーから質問を受けた時点で、AIが関連する文書やデータを検索する。検索した情報を質問とともにプロンプトへ組み込み、LLMに回答を生成させる。
社内規定、製品情報、顧客対応履歴、技術マニュアルなどを、モデルの重みに学習させるのではなく、回答に必要な情報だけを実行時に与える仕組みである。
RAGの強みとして、情報を更新しやすいことが挙げられる。例えば、人事制度が変更された場合、ファインチューニング済みモデルでは再学習が必要になる可能性がある。RAGであれば、検索対象になっている規定文書を差し替えることで、変更内容を回答に反映できる。製品価格や契約条件、社内規定、法令など、頻繁に更新される情報を扱う場合は、知識をモデルに固定するファインチューニングよりもRAGの方が適している。
一方、RAGを導入すれば自動的に高精度な回答が得られるわけではない。検索対象の文書をどの単位で分割するか、どの情報を優先して取得するか、アクセス権限をどのように反映するかといった設計が回答の品質を左右することに注意が必要だ。
コンテキストエンジニアリングで入力を設計する
コンテキストエンジニアリングは、モデルに渡す情報全体を設計する考え方である。
質問文を工夫するだけではない。モデルの役割を定義するシステムプロンプト、回答時に参照させるデータ、出力形式、禁止事項、具体例、利用可能なツールなどを、1つの入力として最適に組み合わせる。
例えば、社内問い合わせに回答するAIであれば、次のような情報をまとめてモデルに渡す。
「あなたは情報システム部門の問い合わせ担当者である」と役割を指定し、関連する社内規定を追加する。回答は「結論」「操作手順」「問い合わせ先」の順に出力するよう指示し、不明な場合は推測せず担当部署へ誘導させる。
モデルの重みを変更しなくても、必要な情報と制約を適切に組み合わせることで、回答の品質や一貫性を高められる。
エージェントスキルで業務手順を与える
モデルに不足しているものが知識ではなく、業務の進め方やツールの使い方である場合は、「エージェントスキル」を利用できる。
エージェントスキルとは、特定の作業を実行するための手順、利用するツール、注意事項などを、Markdown形式のファイルなどにまとめたものだ。AIエージェントは、依頼された作業に応じて必要なスキルをオンデマンドで読み込む。
例えば、特定の社内データベースに対するSQLを生成させる場合、データベースの構造やクエリ作成手順をモデルへ追加学習させる必要はない。テーブル名、列名、結合条件、利用可能なSQL、実行前の確認手順などをスキルとして記述すれば、汎用モデルがその業務を実行できる。
データベースの構造や業務手順が変わった場合も、モデルを再学習するのではなく、スキルファイルを更新すればよい。モデルと業務手順を分離できるため、保守や監査もしやすくなる。
ファインチューニングには継続的なコストがかかる
ファインチューニングを実施する際は、学習以外にもさまざまな作業が発生する。
まず、望ましい入力と出力の組み合わせを大量に収集し、学習に適した形式へ整える作業だ。誤ったデータや偏った事例が含まれていれば、その傾向がモデルの回答にも反映される。
学習後には、想定した業務で精度が上がったかどうかを評価する。あるタスクの性能が向上する一方で、別のタスクの性能が低下する「回帰」が発生していないかどうかも確認する必要がある。
さらに、汎用モデルの世代が変われば、再度ファインチューニングや評価を実施する可能性がある。学習データの収集、評価、回帰テスト、モデル更新への追従を含めると、独自モデルの維持には継続的な費用と人員が必要になる。
現在でもファインチューニングが有効な3つのケース
ファインチューニングは不要になったわけではない。プロンプトやRAG、エージェントスキルでは解決しにくい明確な制約がある場合には有効な手法だ。
近年の実運用では、基盤モデルの全ての重みを変更するのではなく、一部の差分だけを学習する「LoRA」（既存の大規模AIモデルに対して低ランク行列を追加することで軽量にファインチューニングする手法）などのパラメーター効率の高い手法が利用されることもある。
LoRAでは、元のモデルのパラメーターはほとんど変更せず、回答の傾向を調整する小規模な追加パラメーターだけを学習させる。全ての重みを書き換える方法と比べて、必要な計算資源や学習時間、保存容量を抑えることができる。
一方、ファインチューニングが有効な場合もある。キーン氏は3つの事例を紹介する。
1．リアルタイム性や低レイテンシーが必要な場合
1つ目は、短い待ち時間で回答する必要がある場合だ。音声AIによる電話対応では、一般的に利用者が話し終えてから数秒以上待たされると、会話に不自然さが残る。電話対応に大型の推論モデルを使う場合、回答前に複数の処理を実行するため、高品質な回答を生成できる一方で、応答に時間がかかる場合がある。
一方、限られた業務に対応する小型モデルをファインチューニングすれば、複雑な推論処理を実行しなくても、必要な回答を短時間で生成できる可能性がある。このように、リアルタイム性が品質を左右する音声AIエージェントや、端末上で動作するAI、短時間に大量の処理を実行するシステムには、ファインチューニング済みの小型モデルが適している。
2．大型モデルの能力を小型モデルへ蒸留する場合
2つ目は、知識の蒸留（Knowledge Distillation）だ。蒸留では、高性能な大型モデルを「教師モデル」として利用する。教師モデルに大量の問題を解かせ、高品質な回答や推論結果を生成させる。その出力を学習データとして、小型モデルをファインチューニングする。これにより、大型モデルの振る舞いや判断傾向を、より軽量で安価なモデルへ移すことができる。
例えば、複雑な問い合わせへの回答例を大型モデルに作らせ、そのデータを使って小型モデルを学習する。実運用では小型モデルを使うことで、一定の回答品質を保ちながら、推論コストや応答時間を削減できる。
ただし、大型モデルが生成した出力に誤りが含まれていれば、その誤りも小型モデルへ引き継がれる可能性がある。そこで、教師データの品質確認は欠かせない。
3．正誤を自動判定できるタスクでRFTを使う場合
3つ目は、「強化学習ファインチューニング」（Reinforcement Fine-Tuning：RFT）だ。
RFTでは、モデルに問題を与えて複数の回答候補を生成させ、採点プログラムが各回答を評価する。高得点を得た回答を生成しやすくなるように、モデルのパラメーターを更新する。
固定された正解例だけを学習するのではなく、モデルが生成した複数の候補を評価しながら改善する点が特徴である。ただしRFTを適用しやすいのは、回答の正誤をプログラムで明確に判定できるタスクに限られる。
例えば、数学の問題に回答する、所定の条件を満たすデータの変換などでは、自動採点が可能である。一方、文章の読みやすさや顧客への配慮、経営判断の妥当性など、正解が1つに定まらない業務では、安定した採点基準を作ることが難しい。
実務では5段階でモデルを最適化する
企業が自社業務に生成AIを組み合わせる際は、最初からファインチューニングを前提にするのではなく、以下の段階に合わせて必要な手法を追加するようキーン氏は薦める。
第1段階 用途に合ったベースモデルを選択する
モデルによって、推論能力、処理速度、利用料金、扱えるコンテキスト量、画像や音声への対応状況は異なる。まずは複数の汎用モデルを実際の業務データで評価し、追加学習をしなくても要件を満たせるかどうかを確認する。
第2段階 プロンプトとコンテキストエンジニアリングを実施する
モデルの役割、回答形式、禁止事項、判断基準、具体例などを整理し、必要な情報を適切な順序でモデルに与える。プロンプトの改善だけで性能が安定するのであれば、独自モデルを構築する必要はない。
第3段階 RAGを導入する
社内固有の情報や頻繁に更新される情報が必要な場合は、関連文書を検索し、回答時にモデルへ渡す。知識不足が課題なのであれば、モデルの重みを変更する前にRAGで補えるかどうかを確認する。
第4段階 エージェントスキルを追加する
業務手順やツールの操作方法が不足している場合は、それらをスキルとして外部化する。モデルに全てを覚え込ませるのではなく、必要な手順を必要なときに参照させる。
第5段階 ファインチューニングを検討する
RAGやプロンプトでは解決できない応答速度の問題、極端な推論コスト、特定タスクにおける精度不足など、明確なボトルネックが残っている場合に限り、LoRAなどを使った追加学習を実施する。
ファインチューニングを目的にしない
生成AIを業務へ導入する際、独自モデルを構築すること自体を目的にするのは薦めないとキーン氏は説明する。
重要なのは、業務上の課題がどこにあるかを見極めることだ。モデルが社内情報を知らないことが問題ならRAGが候補になる。指示に従わないことが問題なら、プロンプトや評価方法を見直す必要がある。業務手順やツールの使い方が不足しているなら、エージェントスキルが適する。
ファインチューニングが必要になるのは、それらの方法では解消できない制約が残った場合である。
汎用モデルの性能向上が続く現在、企業に求められるのは「何をモデルに追加学習させるか」だけではない。「どの情報を検索させるか」「どの手順を外部から与えるか」「どの処理だけを小型モデルへ任せるか」を組み合わせて設計することが重要になる。
本稿は、IBM Technologyが2026年7月21日に公開した動画「Is Fine−Tuning Still Needed? LLMs, RAG,＆LoRA」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
