ファインチューニングとは？｜学習データ・評価・再学習の実務

ファインチューニングは、既存モデルの重み全体または追加パラメーターを、目的に沿った例で更新し、出力の振る舞いを調整する方法です。最新情報を随時覚えさせる仕組みとは限りません。分類、出力形式、語調、専門的な応答傾向など、基盤モデルと指示だけでは安定しない反復課題を、未閲覧データで改善できるときに検討します。

ファインチューニングを一文で定義し、対象を振る舞いに絞る

ファインチューニングとは、学習済みモデルを出発点に、追加データを使ってパラメーターを更新し、特定タスクへの応答傾向を変える工程です。全パラメーターを更新する方式もあれば、一部または追加した小さなパラメーターだけを学習する方式もあります。業務で重要なのは手法名ではなく、どの入力分布で、何を正解とし、どの誤りを減らすために更新するかです。

適した問いは、「問い合わせを12分類へ振り分ける」「指定されたJSON項目を欠かさず出す」「社内校閲基準に沿った修正案を作る」のように、正解または採点基準を繰り返し用意できる課題です。反対に、今日改訂された規程を正確に答える課題は、知識を検索時に取得する方が更新と出典管理をしやすい場合があります。学習データへ規程本文を入れても、次の改訂を自動では反映しません。

「追加学習」は広い表現で、継続事前学習、教師ありファインチューニング、選好に基づく調整、パラメーター効率のよい適応などを含み得ます。調達や社内説明では一括りにせず、目的、更新するパラメーター、必要データ、評価方法、成果物、再実行コストを明記します。

モデル名だけを成果物にせず、対象入力、対象外の利用、期待する出力、重大な失敗、基盤版、データ版を組にした「適用範囲」を定義します。別部署が同じ調整済みモデルを使いたい場合は、その範囲を自動で引き継がず、新しい入力分布と損失条件で評価し直します。

2026年は手法だけでなく提供継続と移行条件を先に確認する

ファインチューニングという技術概念は継続していますが、クラウド事業者ごとの提供状況は変わります。OpenAIは2026年5月8日付の公式更新で、同社の追加学習基盤を段階的に縮小し、新規利用者はアクセスできず、既存利用者の学習ジョブは一定期間継続、作成済みモデルの推論は基盤モデル廃止まで利用可能と説明しています^[3]。これは他社サービスや自社運用による同手法が終了したことを意味しません。

現在の採否判断では、学習性能に加えて、学習ジョブの新規作成期限、基盤モデルの廃止条件、学習データとチェックポイントの持ち出し可否、代替モデルへの移植方法を確認します。ベンダー固有のAPIを前提に作った評価やデータ形式が、別の環境でも読めるかを試します。サービス終了が発表されてから変換方法を探すと、元モデル、トークナイザー、前処理、ライセンスの違いで同じ挙動を再現できないことがあります。

「知識を入れる」「データが多いほどよい」という誤解を直す

第一の誤解は、ファインチューニングを社内文書の保存場所と考えることです。パラメーターへ影響を与えても、どの文書のどの箇所を根拠に答えたかを直接示せるとは限りません。頻繁に変わる価格、在庫、規程、担当者情報は、検索、データベース、ツール連携など外部の正本から取得する構成を先に比較します。

第二の誤解は、例を増やせば必ず改善するという考えです。誤ったラベル、担当者ごとに矛盾する書式、重複した顧客案件を大量に入れると、その矛盾まで学習します。件数より、対象業務の分布を覆っているか、正解が一貫しているか、禁止すべき出力が含まれているかを確認します。希少でも損失の大きいケースは、通常件数に比例させず評価へ明示的に入れます。

第三の誤解は、学習後のモデルが基盤モデルより常に優れるという期待です。狭い形式へ適応した結果、別の言語、長い入力、例外判断、安全な保留が弱くなることがあります。対象タスクの改善と対象外タスクの退行を別の評価群で測り、後者が許容範囲を超えたら採用しません。

全重み更新とLoRAを、変更量・保存物・配備方法で理解する

通常の全重み更新では、基盤モデルの多数のパラメーターへ勾配を反映します。大規模モデルでは計算資源、保存容量、モデルごとの配備負荷が大きくなります。LoRAは基盤重みを固定し、重み変化を低ランク行列として学習する方法です。原著論文の現行arXiv版はv2で、2021年10月16日に改訂され、学習対象パラメーターとメモリを大幅に減らす実験結果を示しています^[1]。

LoRAで保存されるアダプターは基盤モデルと組み合わせて利用します。基盤モデル版が変われば、同じアダプターでも挙動が保たれるとは限りません。アダプターを統合して配備するか、推論時に切り替えるかでも運用が変わります。Hugging FaceのPEFT公式文書は、少数の追加パラメーターを学習する方式を扱い、2026年7月30日の参照時点では安定版0.19.0を案内しています^[2]。

教師あり調整の概念的な流れ
1. 入力 x と期待出力 y の組を準備する
2. 基盤モデルから予測 y_hat を得る
3. y と y_hat の差を損失 L として計算する
4. 全重みまたは選択した追加パラメーターを更新する
5. 学習に使っていない検証データで過適合を監視する
6. 未閲覧の最終評価で基盤モデルと比較する

学習損失は最適化の内部信号であり、業務合格率そのものではありません。損失が下がっても、金額の転記、禁止表現、安全な回答保留など、業務上の重大条件が改善したとは限りません。エポックごとの損失と、ケース別の業務評価を分けて保存します。

一貫した形式や分類は候補、最新知識と完全な安全保証は対象外にする

向いている用途は、分類ラベルが定義され、同じ基準で多数の例を作れる仕事です。問い合わせ意図の分類、定型要約、固有のJSON構造、文章校正の指摘種別などが候補になります。長い指示や多数の例を毎回プロンプトへ入れている場合、調整によって入力を短くできる可能性もあります。ただし、品質、速度、費用を実測して判断します。

条件付きの用途は、専門分野の応答です。専門語の使い方や説明順を学ばせることはできますが、事実の正確性は別の根拠取得と検証が必要です。NIST AI 600-1は、生成AI特有のリスクへ用途に応じた評価と管理を行うための横断資料で、2024年7月26日公開、案内ページは2026年4月8日更新です^[4]。学習したから監視を外せるという根拠にはなりません。

できないことは、未知の事実を確実に正しくする、すべての偏りを除去する、機密情報の記憶を完全に防ぐ、将来の基盤モデル変更後も同一動作を保証することです。高影響の判断では、ファインチューニング済みモデルの出力だけで承認を完了させず、根拠、ルール、人の判断を組み合わせます。

プロンプト、構造化出力、RAG、ファインチューニングの境界を引く

最初にプロンプトと出力スキーマを整えます。短い指示と数件の例で合格するなら、更新が容易で比較費用も小さいため、学習を追加する理由は弱くなります。次に、誤りが知識不足なのか振る舞い不安定なのかを分けます。更新される文書を根拠付きで答える課題はRAG、同じ情報を渡しても分類や形式が崩れる課題はファインチューニングの候補です。

併用も可能です。ファインチューニングで分類や回答形式を安定させ、RAGで現行資料を渡します。その場合、検索の評価と生成の評価を分け、失敗時にどちらを直すか判別できるログを持ちます。併用しただけで相互の弱点が消えるわけではありません。

学習・検証・最終評価を案件単位で分け、汚染を検査する

データは実運用の入力分布から集め、正常例、難しい境界例、拒否・保留すべき例を含めます。想定例として1,000案件があるなら、学習700、検証150、最終評価150へ分けます。ただし、同一顧客・原文・会話から派生した例は、一つの集合へまとめます。行単位の無作為分割では、ほぼ同じ文章が学習と評価に入り、実際より高い点が出ます。

時間による変化が大きい業務では、古い期間を学習、新しい期間を最終評価へ置く時間分割も行います。例えば1〜5月を学習・検証、6月を最終評価とすれば、未来の入力に近い条件を試せます。部署や商品が偏るなら層別し、各層の件数と重大ケースを台帳へ記録します。少数層の悪化を全体平均で隠しません。

データ汚染の四つの検査

直接重複は正規化した全文ハッシュ、近似重複はn-gramや埋め込み類似度、原文共有はsource_id、会話共有はconversation_idで調べます。さらに、正答作成時にモデル出力をそのまま採用した「自己生成ラベル」を識別します。自己生成例を使う場合は専門担当が原文と照合し、人が確定したラベルと区別します。

dataset_record
識別子: case_id, source_id, conversation_id, customer_group
入出力: input, expected_output, allowed_variants
評価管理: risk_class, split, label_author, reviewer
履歴管理: created_at, policy_version, duplicate_group
権利管理: contains_personal_data, usage_rights, provenance

個人情報、著作物、契約データを学習へ使えるかは、保有していることと利用権限があることを分けて確認します。削除要求や保存期限に対応できないデータは入れません。後から一件を除外する必要が生じた場合に、どの学習ジョブとモデルへ含まれたか追跡できるよう、データ版と実行IDを結び付けます。

基盤モデルを固定し、一変更ずつ比較実験を進める

比較では、まず基盤モデルと最良のプロンプトをベースラインとして保存します。次にデータ版、基盤モデル版、乱数、学習方式、主要ハイパーパラメーター、チェックポイントを記録します。同時にデータと学習条件を変えると改善要因が分からないため、初回は一つの設定差に絞ります。

1. 業務指標を確定する：形式一致、分類、重大誤り、処理費用などを学習前に決めます。
2. ベースラインを測る：最終評価を封印したまま、開発・検証集合で基盤モデルを調整します。
3. データを監査する：重複、ラベル不一致、権利、個人情報、少数ケースの偏りを確認します。
4. 小規模に学習する：少ないエポックまたはアダプターから始め、検証損失と業務指標を保存します。
5. 未閲覧評価を一度実行する：採用候補を絞ってから最終集合を開き、基盤モデルと対比較します。
6. 安全と退行を確認する：対象外タスク、保留、権限、悪意入力を別群で試します。
7. 限定配備する：利用者、件数、期間を絞り、旧版へ即時に戻せる状態で監視します。

OpenAIの現行Evals APIは、評価タスクにテスト基準とデータソースの構造を持たせ、異なるモデルや設定で実行できる仕様です。文書の固定版と更新日はページに示されていないため、2026年7月30日の参照内容として扱います^[5]。特定APIを使わなくても、ケースIDと採点規則を固定すれば同じ比較設計を作れます。

改善幅、重大誤り、クラス別F1、受入一件当たり費用を計算する

分類では全体正解率だけでなく、各クラスの適合率と再現率を計算します。件数の少ない重要クラスを平等に見るなら、クラスごとのF1を平均するMacro-F1を使います。生成では、形式一致、必須項目、根拠一致、人の受入を別項目にします。文章の似ている度合いだけで、契約額や期限の誤りを合格にしません。

全体評価: 正解率 = 正解件数 ÷ 評価件数 × 100
分類評価: 適合率 = 真陽性 ÷ (真陽性 + 偽陽性)
分類評価: 再現率 = 真陽性 ÷ (真陽性 + 偽陰性)
分類評価: F1 = 2 × 適合率 × 再現率 ÷ (適合率 + 再現率)
比較評価: 改善幅 = 調整後の指標 - 基盤モデルの指標
安全評価: 重大誤り率 = 重大誤り件数 ÷ 評価件数 × 100
費用評価: 受入一件当たり費用 = (推論費 + 人件費 + 配備費) ÷ 受入件数

想定例として最終評価150件で基盤モデルの合格が111件、調整後が126件なら、合格率は74.0%から84.0%へ10ポイント改善です。しかし重大誤りが1件から3件へ増えたなら、合計合格率だけで採用しません。調整後だけ正解した件数と基盤だけ正解した件数を出し、どのケースが入れ替わったか確認します。

採点者が必要な項目では、二名の一致率も測ります。150件中135件で同じ判定なら一致率90.0%ですが、重大クラスの不一致が残る場合は正解基準を直します。採点揺れをモデル差と誤認しないため、判断理由と根拠をケースへ付けます。

再学習は入力分布・基準・基盤モデルの変化を起点にし、旧版を残す

再学習の候補は、実運用で同じ失敗種別が増え、正しい追加例を十分に作れる場合です。毎月という日付だけで実行せず、入力分布の変化、ラベル基準の改訂、基盤モデルの変更、主要指標の低下をトリガーにします。規程や商品情報が変わっただけなら、重みではなくRAGの文書更新と再索引で済むかを先に確認します。

新しい失敗例を加えるときは、元の最終評価をすべて学習へ移しません。一部を学習候補へ移したら、新しい未閲覧ケースを補充し、評価版を上げます。再学習を重ねるほど、過去の評価を見ながら調整した影響が蓄積します。四半期ごとに完全未閲覧の監査集合を用意するなど、最終評価への適合を検出する仕組みが必要です。

切り戻しには、旧モデルIDだけでなく、対応する指示、前処理、トークナイザー、評価結果、配備設定を残します。新旧を同時に呼び出せる期間を設け、重大警告が一件出たら旧版へ戻す条件を設定します。旧版の基盤モデル自体が利用終了なら、手動処理または別方式への縮退経路が必要です。

採否は100点評価票と重大条件の足切りで決める

評価票の前に、重大誤り0件、データ利用権限の未確認0件、最終評価への直接重複0件、切り戻し試験合格、必要運用期間中の提供見通し確認を足切りにします。いずれかが欠ける場合、総合点を出しても本番採用へ進みません。

想定例では90点以上を限定運用候補、80〜89点を追加検証、79点以下を見送りとします。配点は業務損失に合わせて評価前に固定します。正解率が重要な分類と、書式安定が重要な下書きでは重みが異なります。不採用時も、どのデータと指標がそろえば再検討するかを残します。

正解を作れない課題、頻繁な知識更新、高影響の自動判断には向かない

向かないケースは、専門家同士でも正解が定まらず、採点基準を作れない業務です。評価不能なまま学習すると、モデルが良くなったかを学習損失で代用することになります。また、毎日変わる情報を覚えさせたい、数十件しかなく個人情報を除くと例が残らない、提供終了までに投資を回収できない場合は別手段を優先します。

学習または配備を停止する条件：

• 学習データへ利用権限不明の情報、削除対象、誤ラベルが混入した
• 検証損失は下がる一方、業務指標が二回連続で悪化した
• 未閲覧評価で重大誤りが一件でも基盤モデルより増えた
• 対象外タスクの退行が許容幅を超え、利用範囲を隔離できない
• 基盤モデルまたは学習サービスの終了に対する移行経路がない

個人情報と学習利用は個人情報保護・法務、著作物と契約データは法務・調達、偏りや不利益な判断は業務責任者とリスク担当、基盤モデルの移行は技術・調達へ引き継ぎます。技術担当だけで「精度が上がった」と判断せず、データの権利と業務影響を別の承認項目にします。

次に取る行動：失敗50件を分類し、学習以外の手段を比較する

現在の基盤モデルで失敗した実案件を50件集め、知識不足、指示の曖昧さ、出力形式、分類の不安定、権限・安全の五群へ分けます。知識不足はRAG、指示の問題はプロンプト、形式はスキーマ検証で先に再試験します。それでも同じ振る舞い不良が残る群だけを、ファインチューニングの小規模実験へ進めてください。

参考文献・一次情報

1. ファインチューニング手法に関する原著論文：Edward J. Hu et al., “LoRA: Low-Rank Adaptation of Large Language Models,” arXiv:2106.09685v2, 2021年10月16日改訂（2026年7月30日参照）。
2. Hugging Face, “PEFT Documentation,” 参照時の安定版0.19.0（2026年7月30日参照）。
3. OpenAI, “Introducing improvements to the fine-tuning API and expanding our custom models program,” 2024年4月4日公開、2026年5月8日提供縮小情報を追記（2026年7月30日参照）。
4. NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1, 2024年7月26日公開、案内ページ2026年4月8日更新（2026年7月30日参照）。
5. OpenAI, “Evals API Reference,” ページ上の固定版・更新日表記なし（2026年7月30日参照）。