Microsoft FoundryのGAモデルは原則18か月、410 Goneを前提に移行を自動化する方法

Microsoft FoundryでGAモデルを本番利用する企業は、モデルを恒久的なクラウド資源として扱ってはいけない。

Microsoftのライフサイクルポリシーでは、GAモデルは原則として公開から18か月後に終了する。公開から12か月が経過すると新規顧客への提供が制限され、終了のおよそ90日前にGlobal Standard向け代替が利用可能になり、Provisioned向け代替はおよそ30日前に利用できる。終了後の推論は410 Goneを返す。

Previewモデルはさらに不確実である。30日以上の通知で新しいPreviewまたはGAへ強制更新される場合があり、代替なしで終了する場合もある。終了日の延長例外はない。

GAモデルの基本ライフサイクル

この90日と30日の差は重要である。Provisioned利用者は代替モデルを同じ配備方式で評価できる期間が短い。

終了日は通知を待たず取得する

MicrosoftはGAモデルの終了日を公開時にプログラム上設定し、Models APIから取得できるとしている。個別メールが来るまで何もしない運用では遅い。

台帳へ最低限保存する。

deployment_name
model_family
model_version
deployment_type
region
version_upgrade_option
retirement_date
replacement_model
business_owner
technical_owner
monthly_tokens
criticality
fallback_deployment
last_eval_date

Models APIを定期的に取得し、前回との差分を監視する。

• 新しい終了日が追加された
• 代替モデルが指定された
• 状態がDeprecatedへ変化した
• 利用可能リージョンが変わった
• Previewの強制更新が予定された

ポータル画面を人が確認する作業では、複数Subscription、複数リージョン、複数部門の漏れを防げない。

versionUpgradeOptionの意味

Standard配備では、モデルバージョン更新の挙動をversionUpgradeOptionで制御できる。

OnceNewDefaultVersionAvailable

新しい既定バージョンが利用可能になると更新する。新機能や改善を早く利用できる一方、評価前に出力特性が変わる可能性がある。

OnceCurrentVersionExpired

現在のバージョンが終了するときに更新する。変更時期を遅らせられるが、終了直前まで移行を先送りすると、問題発生時の調整時間が少ない。

NoAutoUpgrade

自動更新しない。モデルが終了すると配備は動作しなくなる。固定バージョンの再現性を優先できるが、手動移行を忘れると停止する。

どの設定が正しいかはワークロードによって異なる。

設定値だけで安全性は決まらない。自動更新を選ぶ場合でも、更新後の自動評価と切り戻しが必要である。

Previewを本番へ置く際の責任

MicrosoftはPreviewモデルを本番ワークロードへ推奨していない。Previewは次のいずれかになる。

• 新しいPreviewへ強制更新
• GAへ強制更新
• 代替なしで終了

通知は最低30日とされるが、企業の変更管理、セキュリティ審査、顧客通知、負荷試験を考えると短い。

Previewを利用する場合は次を実装する。

• Preview専用の配備
• 本番主経路との分離
• 固定した評価セット
• モデル変更検知
• 出力特性の自動比較
• 即時停止できるFeature Flag
• GAまたは別ベンダーへのFallback
• Preview利用を明示するリスク承認

Previewを便利な早期アクセスとして扱うのではなく、変更可能性を含む外部依存として扱う。

410 Goneを障害として初めて知ってはいけない

モデル終了後の410 Goneは突発障害ではなく、予告された恒久停止である。

アプリケーションが410を一般的な5xxと同じように再試行すると、成功しないリクエストを繰り返し、キューと費用監視を混乱させる。

エラー処理を分類する。

429 -> バックオフして再試行
500/503 -> 一時障害として再試行
401/403 -> 認証・権限エラーとして停止
404 -> 配備名またはルートを確認
410 -> モデル終了。再試行せずFallbackへ切り替え、重大アラート

410を受けた場合は、次を自動化する。

1. 再試行を停止
2. 承認済みFallbackへルーティング
3. 対象配備と呼び出し元を特定
4. オーナーへ通知
5. 未処理キューを隔離
6. 影響件数を記録

ただし、Fallbackモデルが同じ品質、費用、データ地域を満たすとは限らない。事前承認された組み合わせだけを使う。

Replacementが発表されてからでは遅い作業

Microsoftは正式な代替モデルを終了のおよそ90〜120日前に決めるとしている。これは、あまり早く代替を固定すると、移行時点で最適ではなくなるためである。

一方、企業側は代替名が決まる前から次を準備できる。

• 評価セット
• 重大失敗の定義
• 負荷試験
• PromptとTool Schemaのバージョン管理
• モデルルーティング層
• シャドー実行基盤
• 費用比較ダッシュボード
• 顧客通知テンプレート
• セキュリティ審査項目

代替モデル発表後に評価基盤から作り始めると、90日を有効に使えない。

Provisioned利用者の移行

Provisionedでは、容量予約、リージョン、契約、スループットが移行を複雑にする。

確認する。

• 代替モデルが同じリージョンで利用可能か
• 必要なProvisioned容量を確保できるか
• 新旧配備を並行保持できるか
• 契約上の重複費用
• PTU換算が同じか
• トークン化で実効処理量が変わらないか
• ピーク時の余力
• 切り替え後の容量解放手順

代替が30日前に利用可能になっても、社内調達や容量確保に時間がかかる場合がある。営業担当と早期に調整する。

Fine-tunedモデルは二段階で終了する

Fine-tunedモデルには、Trainingの終了とDeploymentの終了がある。

• Training終了後は新しい学習を作れない
• 既存の学習済みモデルはDeployment終了まで推論できる
• Deployment終了後は推論と配備がエラーになる

この二つを混同すると、推論は動いているのに再学習できない状態へ入る。

台帳には次を分けて記録する。

base_model_retirement
training_retirement
deployment_retirement
last_retrain_date
training_dataset_version
replacement_training_path

学習データ、前処理、評価、ハイパーパラメータをAzure上のモデルIDだけに依存させない。

モデル終了を通常運用へ組み込む

毎日

• Models APIの差分取得
• 新規終了日と状態変更の検知

毎週

• 180日以内に終了する配備を一覧化
• 所有者未設定の配備を通知

毎月

• 代替候補で自動評価
• 月間量と移行費用を更新
• Fallbackの疎通確認

四半期

• 実際の切り替え演習
• Preview利用の再承認
• 不要な配備と古いモデルを削除

終了対応を一度限りのプロジェクトではなく、クラウド資産管理の定常業務にする。

推奨アラート設計

通知はメールだけでなく、Issue、チケット、Slack、運用ダッシュボードへ接続する。

モデルゲートウェイの設計

アプリケーションがAzureの配備名を直接持つと、移行範囲が広がる。

内部用途名を定義する。

support-chat-primary
contract-analysis-high-accuracy
batch-classification-low-cost
agent-planning

用途名からSubscription、リージョン、配備、モデルバージョンへ解決する。

support-chat-primary
  -> subscription A
  -> region eastus
  -> deployment chat-v3
  -> model version YYYY-MM-DD

切り替え時はルーティング設定だけを更新し、業務コードを変更しない。

編集部分析

Microsoft Foundryのライフサイクルは、モデル終了を例外的なイベントではなく、予定されたクラウド運用として扱うべきことを示している。

18か月という期間は長く見えるが、モデル選定、セキュリティ審査、評価、Provisioned容量、顧客通知、段階移行を含めると余裕は大きくない。特に代替モデルが正式に定まるのは終了の90〜120日前であり、実装チームが使える時間はさらに短い。

重要なのは、終了日を知ることではなく、終了日から逆算して機械的に作業が始まる仕組みを持つことである。

モデルをアプリケーションの一部として固定するのではなく、期限付きの外部依存として台帳化する。Models API、評価パイプライン、ルーティング、Fallbackを組み合わせれば、モデル終了は緊急対応ではなく通常のリリース作業になる。

実務チェックリスト

• [ ] 全Subscriptionとリージョンの配備を台帳化した
• [ ] Models APIから終了日を自動取得している
• [ ] 配備ごとのversionUpgradeOptionを確認した
• [ ] Previewモデルを本番利用する承認がある
• [ ] 410 Goneを恒久停止として処理する
• [ ] 承認済みFallback配備がある
• [ ] 180日前から段階アラートを出す
• [ ] 代替発表前から評価基盤を準備している
• [ ] Provisioned容量と重複費用を計画した
• [ ] Fine-tunedのTraining終了とDeployment終了を分けた
• [ ] 用途名と実モデル配備を分離した
• [ ] モデル切り替え演習を定期実施している

一次情報

• Foundry Models lifecycle and support policy
• Azure OpenAI model retirement schedule
• Working with models and version upgrades