OpenAIはセルフサービスFine-tuningの提供範囲を段階的に縮小している。
2026年5月7日以降、過去にFine-tuningを実行していない組織は新しい学習ジョブを作成できなくなった。7月2日には、Fine-tunedモデルで過去60日間に推論していない組織も新規ジョブを作成できなくなった。さらに、現在も利用資格を持つ既存顧客についても、2027年1月6日に新しいFine-tuningジョブの作成が終了する予定である。
既に作成済みのFine-tunedモデルによる推論は、基盤となるベースモデルが廃止されるまで継続する。ただし、これは現状のモデルを永続的に利用できるという意味ではない。ベースモデルの終了とともに推論も停止するため、Fine-tunedモデルには二重のライフサイクルがある。
段階的な変更
| 日付 | 変更 |
|---|---|
| 2026年5月7日 | 過去にFine-tuningを実行していない組織は新規学習を開始できなくなった |
| 2026年7月2日 | 過去60日以内にFine-tunedモデルで推論していない組織は新規学習ジョブを作成できなくなった |
| 2027年1月6日 | 現在のアクティブな既存顧客も新規学習ジョブを作成できなくなる |
| ベースモデル終了時 | そのベースモデルから作成したFine-tunedモデルの推論も終了する |
7月2日の条件は既に適用されている。組織が現在も新規学習可能かどうかは、過去の契約認識やダッシュボード表示だけで判断せず、管理者がAPIとコンソールで確認する必要がある。
何が残り、何が終了するか
今回の変更では「学習」と「推論」を分けて考える必要がある。
終了するもの
- 新しいFine-tuningジョブの作成
- 既存データセットを使った再学習
- 新しいデータを追加した継続的な更新
- ハイパーパラメータを変えた実験
- 新しいベースモデルへの同一手順での再学習
当面継続するもの
- 作成済みFine-tunedモデルへの推論
- 既存モデルを使うアプリケーション
- ベースモデルが提供されている期間の運用
運用中のモデルが動き続けるため、停止リスクが見えにくい。しかし、データ分布の変化、製品仕様の更新、規制対応、誤回答修正が必要になっても、再学習できなければモデルを改善できない。
Fine-tunedモデルには二つの期限がある
Fine-tunedモデルの寿命は次の短い方で決まる。
1. セルフサービス学習機能の終了
2. ベースモデルの提供終了2027年1月6日より前に新しい学習を完了しても、ベースモデルがその後廃止されれば推論は終了する。したがって、「期限前に最終版を1回作れば長期利用できる」という計画は成立しない。
モデル台帳には、Fine-tunedモデルIDだけでなく次を記録する必要がある。
- ベースモデル名とスナップショット
- 学習ジョブID
- 作成日時
- 学習方式
- 学習データのバージョン
- 検証データのバージョン
- ハイパーパラメータ
- 評価結果
- 利用中のシステム
- 月間リクエスト数
- ベースモデルの廃止予定
- 代替候補
- 担当部署
Fine-tunedモデルIDを環境変数へ保存しているだけでは、再現にも移行にも足りない。
最も重要なのはモデルではなく学習資産
API上に作成したモデルは、提供者のライフサイクルに依存する。一方、企業が長期的に保持すべき資産は次である。
- 原始データ
- 学習用データセット
- データ生成・洗浄手順
- 評価セット
- 採点基準
- 学習レシピ
- 本番での失敗事例
- モデル選択の意思決定記録
学習用JSONLだけを保存しても不十分である。元データからどのように会話形式へ変換したか、重複をどう除外したか、個人情報をどう処理したか、どの例を検証用へ分離したかが分からなければ再現できない。
推奨する構成は次の通りである。
training-assets/
raw/
normalized/
train/
validation/
evals/
transforms/
policies/
manifests/各データセットには、生成元、ライセンス、収集日時、除外条件、ハッシュ値を含むマニフェストを付ける。
代替手段は一つではない
Fine-tuningで解決していた問題を、そのまま別サービスのFine-tuningへ移すとは限らない。目的ごとに分解する必要がある。
| 目的 | 主な代替候補 |
|---|---|
| 最新知識を反映する | RAG、検索、データベース参照 |
| 出力形式を安定させる | Structured Outputs、スキーマ検証、再試行 |
| 文体を統一する | システムプロンプト、例示、後処理 |
| 分類精度を上げる | 小型分類器、ルール、埋め込み、別モデル |
| 長い業務手順を守らせる | ワークフロー分割、ツール実行、状態機械 |
| 推論コストを下げる | 小型モデル、ルーティング、キャッシュ、バッチ |
| 特定タスクの能力を上げる | 別ベンダーのFine-tuning、オープンウェイトモデル |
Fine-tuningは万能の知識注入機能ではない。頻繁に変わる規程、価格、商品情報を学習データへ入れると、更新のたびに再学習が必要になる。今回の提供縮小は、動的知識をモデル内部へ固定していた設計を見直す契機になる。
移行判断のための質問
各Fine-tunedモデルについて、次を明確にする。
何を改善しているか
- ベースモデルと比べてどの指標が改善したか
- 改善幅は統計的・業務的に意味があるか
- 現在の新しいベースモデルでも同じ改善が必要か
- プロンプト改善で代替できるか
何が失敗すると困るか
- 出力形式の崩れか
- 誤分類か
- 文体の不統一か
- 特定専門語の誤用か
- ツール選択の誤りか
- コスト増加か
問題を分解すると、Fine-tuningを使わずに制御層で解決できる場合がある。
再学習頻度はどの程度か
四半期ごとに更新しているモデルは、2027年1月以降に改善できなくなる。逆に、数年間更新していないモデルは、既に利用価値や監視体制が失われている可能性がある。
推奨する対応手順
1. 組織の利用資格を確認する
コンソールとAPIで、新しいFine-tuningジョブが作成可能か確認する。確認目的で本番データを送信せず、最小限の検証用設定を使う。
2. 全モデルを棚卸しする
次を横断検索する。
ft:
fine_tuning
fine-tuning
fine_tuned_model
training_file
validation_file開発、ステージング、本番、停止済みサービス、分析ノートブック、外部委託先を含める。
3. 利用実態で分類する
| 区分 | 判断 |
|---|---|
| 本番で高頻度利用 | 最優先で代替評価 |
| 低頻度だが重要 | 障害時の代替経路を用意 |
| 実験のみ | 再現資産を保存して停止 |
| 利用箇所不明 | ログと請求から特定 |
| ベースモデル終了予定 | 即時移行 |
4. ベースモデルとの差を再測定する
Fine-tunedモデルを作成した時点より、標準モデルが改善している可能性がある。同じ評価セットで、現在のベースモデル、新しい推奨モデル、Fine-tunedモデルを比較する。
比較項目には品質だけでなく、料金、レイテンシー、保守負担、監査可能性を含める。
5. 失敗事例を評価セットへ戻す
本番ログから、人手修正、再実行、顧客苦情、誤分類、拒否、形式崩れを抽出する。個人情報を除去した上で、回帰試験へ追加する。
学習データより評価データを優先して保存する。代替モデルを選ぶとき、評価セットがなければ移行の成否を判断できない。
6. 代替方式を並行評価する
最低でも次の3案を比較する。
- 新しい標準モデル＋プロンプト
- 標準モデル＋RAGまたはツール
- 別基盤でのFine-tuning
Fine-tuningを維持する案だけでなく、Fine-tuningを廃止する案も同じ条件で評価する。
7. 切り替え可能なモデル境界を作る
アプリケーションから特定モデルIDを直接呼ばず、内部のモデルゲートウェイまたは設定層を介す。
business application
-> model policy
-> provider adapter
-> model入力形式、出力検証、エラー分類、監視をアダプターへ集約すると、移行時の変更範囲を狭められる。
契約・監査上の論点
Fine-tuningでは、学習データの権利と機密性だけでなく、モデル廃止後の扱いを確認する必要がある。
- 学習ファイルの保存期間
- 削除手順
- 監査ログ
- データ処理地域
- 学習ジョブの再現性
- モデル利用停止後の識別子保持
- 障害・廃止時の通知方法
- 下流顧客への説明責任
特に規制対象業務では、「同じモデルを使っている」という説明だけでは不十分である。モデルを再学習できない期間に業務ルールが変わった場合、どの制御層で追従するかを決める必要がある。
よくある誤判断
推論が続くので対応は不要
再学習できない状態は、障害ではなく保守不能状態である。今日動くことと、半年後の変更へ対応できることは違う。
期限直前に最終学習を行えばよい
学習データ、評価、承認、本番展開には時間がかかる。さらにベースモデルの廃止日は別に存在する。
学習データさえあれば移行できる
前処理、検証分割、採点基準、ハイパーパラメータ、失敗例がなければ、同じ品質を再現できない。
別ベンダーで同じデータを学習すれば同じになる
モデル、トークナイザー、学習方式、安全制御が異なる。データ形式を変換し、評価セットで再検証する必要がある。
Fine-tuningをRAGへ置き換えればよい
RAGは知識参照には有効だが、文体、分類境界、出力習慣の学習とは目的が異なる。解決したい問題を分解する必要がある。
編集部分析
今回の変更は、企業が「モデル」を資産として所有しているのではなく、「特定ベンダーの特定時期の学習機能を利用する権利」を借りていることを明確にした。
Fine-tunedモデルは専用モデルに見えるが、実際にはベースモデル、API、学習基盤、推論基盤、提供地域、契約条件の上に成立している。どれか一つが終了すれば継続できない。
したがって、AIの競争力をFine-tunedモデルIDへ集約するべきではない。企業固有の競争力は、良質なデータ、評価方法、業務知識、失敗から学ぶ運用プロセスに置くべきである。これらを保持できれば、モデルやベンダーが変わっても再構築できる。
もう一つの重要な変化は、モデル改善の主戦場が「重みの更新」から「システム設計」へ移る可能性である。検索、ツール、ワークフロー、検証、ルーティングを組み合わせれば、学習なしでも高い業務精度を実現できるケースが増えている。
ただし、これはFine-tuningが不要になったという意味ではない。分類境界、特殊な生成形式、低コスト大量処理など、学習が有効な用途は残る。その場合は、学習可能な複数基盤を比較し、データと評価を移植できる状態にしておく必要がある。
実務チェックリスト
- [ ] 組織が現在も新規Fine-tuningジョブを作成できるか確認した
- [ ] すべてのFine-tunedモデルを台帳化した
- [ ] 各モデルのベースモデルと廃止予定を確認した
- [ ] 本番利用箇所と月間利用量を特定した
- [ ] 原始データと加工済み学習データを保存した
- [ ] 前処理コードとデータ分割方法を保存した
- [ ] ハイパーパラメータと学習結果を記録した
- [ ] 本番失敗例を評価セットへ追加した
- [ ] 現行の標準モデルと再比較した
- [ ] プロンプト、RAG、ツールによる代替を評価した
- [ ] 別基盤での学習可能性を検証した
- [ ] モデルIDをアプリケーションから分離した
- [ ] 2027年1月6日より前に移行方針を確定した