Azure AIを使って生成AIアプリを運用している場合、2026年4月30日の公式ドキュメント更新「Fix retirement dates, add Fireworks/DeepSeek partners, add FT section」で最初に確認すべきことは、利用中モデルの提供終了日、置換モデル、パートナーモデルの扱い、そしてファインチューニング済みモデルの終了スケジュールです。
この更新は、単なるドキュメント修正ではありません。モデルの廃止日が変わると、移行計画、検証期間、予算、リージョン設計、プロビジョニング済みデプロイの切り替え作業に直接影響します。特にAzure AI FoundryやAzure OpenAI系のモデルを本番運用している開発者、クラウド管理者、ソリューションアーキテクトは、今使っているモデル名だけでなく、バージョン、SKU、リージョン、デプロイ種別まで確認する必要があります。
今回のポイントは、gpt-5系チャットモデルの提供終了日修正、gpt-4o 2024-11-20の推奨置換モデル変更、FireworksとDeepSeekのパートナーセクション追加、Fine-tuned modelsセクション追加の4つです。MicrosoftDocsのコミットでは、対象ファイルのms.dateが2026年4月30日に更新され、チャットモデルの提供終了日修正、DeepSeek/Fireworksパートナー追加、FTセクション追加などが明記されています。(GitHub)
Azure AIの公式ドキュメント更新「Fix retirement dates, add Fireworks/DeepSeek partners, add FT section」で何が変わったか
今回の更新対象は、Microsoft Foundry / Azure OpenAI系のモデル提供終了スケジュールです。公式ドキュメントでは、各モデルのライフサイクルステージ、提供終了日、推奨される置換モデルを確認でき、非推奨化や提供終了前の移行計画に使うものと説明されています。(Microsoft Learn)
主な変更は次のとおりです。
| 変更点 | 内容 | 影響を受けやすい読者 |
|---|---|---|
| チャットモデルの提供終了日修正 | 一部のgpt-5系chatモデルの提供終了日が2026年6月9日に修正 | AIアプリ開発者、運用担当者 |
| gpt-4oの置換モデル修正 | gpt-4o 2024-11-20の置換先がgpt-5.1に修正 | 既存のgpt-4o利用者 |
| DeepSeekパートナー追加 | パートナーセクションにDeepSeek-V4-Flashが追加 | モデル選定担当、アーキテクト |
| Fireworksパートナー追加 | 13件のPreviewモデルが追加 | オープンモデル評価担当、研究開発チーム |
| Fine-tuned modelsセクション追加 | トレーニング終了日とデプロイ終了日を分けて確認可能に | ファインチューニング運用者 |
見落としやすいのは、モデル名だけでは判断できない点です。たとえばgpt-4oを使っていても、2024-05-13、2024-08-06、2024-11-20では状態や置換先の確認が必要です。Azure AIの運用では、モデルファミリーではなく「モデル名 + バージョン + デプロイ種別」で影響を洗い出すのが基本です。
まず確認すべきはモデル提供終了日と置換先
今回の更新で実務上もっとも重要なのは、提供終了日と置換モデルの修正です。
公式のモデル提供終了スケジュールでは、gpt-5-chat、gpt-5.1-chat、gpt-5.2-chat、gpt-5.3-chatなどのPreviewチャットモデルに、2026年6月9日の提供終了日が掲載されています。また、gpt-4o 2024-11-20はGAのまま、提供終了日が2026年10月1日、置換モデルがgpt-5.1として示されています。(Microsoft Learn)
gpt-5系chatモデルを使っている場合の確認ポイント
PreviewのchatモデルをPoCや社内ツールで使っている場合でも、次の3点はすぐに確認してください。
| 確認項目 | 見るべき場所 | 判断基準 |
|---|---|---|
| モデル名とバージョン | Azure AI Foundryのデプロイ一覧、IaC、設定ファイル | gpt-5-chat系か、gpt-5.1-chat系か、バージョンまで確認 |
| 提供終了日 | 公式のModel retirement schedule | 2026年6月9日以前に検証・切り替えを完了できるか |
| 置換モデル | Replacement列 | 置換先がある場合は、品質・コスト・レイテンシを比較 |
Previewモデルは本番利用に向きません。Microsoftのライフサイクル説明でも、PreviewモデルはGAになる保証がなく、置換PreviewやGAモデルへ強制アップグレードされるか、置換なしで終了する可能性があるとされています。(Microsoft Learn)
実務では、Previewモデルを本番の中核処理に使う場合、少なくとも次の逃げ道を用意しておくべきです。
- 同じAPI契約で呼び出せる代替モデルを1つ以上用意する
- モデルIDをアプリケーションコードに直書きせず、設定値やFeature Flagで切り替えられるようにする
- 代表的なプロンプトセットで、回答品質・安全性・レスポンス時間を定期比較する
- 提供終了日の30日前ではなく、60〜90日前から移行テストを始める
gpt-4o 2024-11-20利用者は「置換先がgpt-5.1」であることを前提に検証する
今回の更新では、gpt-4o 2024-11-20のReplacementがgpt-4.1からgpt-5.1へ修正されています。コミット上でも、gpt-4o 2024-11-20 replacement: gpt-4.1 → gpt-5.1と説明されています。(GitHub)
これは、単に表の文字が変わったというより、移行先候補の評価軸が変わる可能性があります。たとえば、既存アプリで次のような使い方をしている場合は、gpt-5.1で再検証が必要です。
| 利用シーン | 検証すべき点 |
|---|---|
| カスタマーサポートBot | 回答の一貫性、トーン、禁止事項への反応、長文問い合わせの処理 |
| 社内ナレッジ検索RAG | 引用精度、検索結果の要約品質、根拠のない補完が増えないか |
| コード生成・レビュー | 既存ルールへの準拠、差分説明の正確性、セキュリティ指摘の粒度 |
| JSON生成・関数呼び出し | スキーマ準拠率、再試行率、ツール呼び出しの安定性 |
| 多言語対応 | 日本語・英語・中国語など、主要言語での品質差 |
特にRAGや業務ワークフローでは、「新しいモデルの方が高性能だからそのまま移行できる」と考えるのは危険です。モデル変更で回答文体、要約の長さ、根拠の扱い、拒否応答の出方が変わることがあります。移行前に、実データに近い評価セットを使って比較してください。
Fine-tuned modelsセクション追加で、トレーニング終了とデプロイ終了を分けて管理する必要がある
今回追加されたFT sectionは、ファインチューニング済みモデルを使っている組織にとって重要です。公式スケジュールでは、Fine-tuned modelsはトレーニングとデプロイの2段階で提供終了すると説明されています。トレーニングが終了しても、既存のファインチューニング済みモデルのデプロイがすぐ使えなくなるとは限りませんが、デプロイ終了日を過ぎると推論やデプロイでエラーが返る可能性があります。(Microsoft Learn)
公式のモデル提供終了スケジュールには、次のようなFine-tuned modelsの終了日が掲載されています。(Microsoft Learn)
| モデル | バージョン | トレーニング終了日 | デプロイ終了日 |
|---|---|---|---|
| gpt-4.1 | 2025-04-14 | 2027-04-14以降 | 2027-10-14 |
| gpt-4.1-mini | 2025-04-14 | 2027-04-14以降 | 2027-10-14 |
| gpt-4.1-nano | 2025-04-14 | 2027-04-14以降 | 2027-10-14 |
| gpt-4o | 2024-08-06 | 2027-04-01以降 | 2027-10-01 |
| gpt-4o-mini | 2024-07-18 | 2027-04-01以降 | 2027-10-01 |
| o4-mini | 2025-04-16 | 2027-04-16以降 | 2027-10-16 |
注意したいのは、既存顧客向けの条件です。公式表では、注記として「既存顧客向け」であり、それ以外ではベースモデルの提供終了に合わせてトレーニングが終了すると説明されています。(Microsoft Learn)
ファインチューニングを運用している場合、次のように管理対象を分けてください。
| 管理対象 | 確認すべきこと | 失敗しやすいポイント |
|---|---|---|
| ベースモデル | どのモデル・バージョンを元にしているか | デプロイ名だけ見てベースモデルを確認しない |
| トレーニング | 新しい学習ジョブをいつまで作れるか | 再学習の期限をデプロイ終了日と混同する |
| デプロイ | 推論エンドポイントがいつまで使えるか | 学習済みだから永続的に使えると誤解する |
| 評価データ | 置換モデルで再学習が必要か | 旧モデルの評価基準をそのまま使う |
| コスト | 再学習・再評価・並行稼働の費用 | 移行期間の二重コストを見積もらない |
FTモデルは、通常のベースモデルより移行に時間がかかります。単に新しいモデルへ切り替えるだけでなく、再学習、評価、セーフティテスト、業務部門レビューが必要になるためです。提供終了日が遠く見えても、評価データの整備から逆算して計画することが重要です。
DeepSeekとFireworksの追加は「モデル選択肢の拡大」と「ガバナンス確認」の両方で見る
今回の更新では、DeepSeekとFireworksがパートナーセクションに追加されています。公式スケジュールでは、パートナーとコミュニティ由来のモデルとして、DeepSeekセクションにDeepSeek-V4-Flash、Fireworksセクションに複数のPreviewモデルが掲載されています。(Microsoft Learn)
DeepSeek-V4-Flashは用途と安全性評価をセットで確認する
DeepSeek-V4-Flashは、高速・高スループット寄りのモデルとして注目されやすい一方、業務利用では安全性評価を省略できません。Microsoft Foundryのモデルカタログでは、DeepSeek-V4-Flashについて、他モデルよりアラインメントが弱いと見られる点、潜在的に有害な出力リスクや安全性・jailbreakベンチマークでの低スコアに触れ、Azure AI Content Safetyとの併用と本番システムでの独自評価を推奨しています。(Azure AI)
そのため、DeepSeek-V4-Flashを検討する場合は、次の順番で判断すると安全です。
| 判断項目 | 採用しやすいケース | 慎重に判断すべきケース |
|---|---|---|
| レイテンシ | 高頻度チャット、分類、要約など | 高度な法務・医療・金融判断 |
| コスト | 大量リクエストを処理したい | 出力ミスの損失が大きい |
| 安全性 | 出力を後段で検査・制御できる | ユーザーに直接回答を返す |
| 評価体制 | 独自の安全性評価セットがある | 評価データが未整備 |
| ガードレール | Content Safetyやポリシーフィルタを組み込める | モデル単体の応答に依存する |
Fireworks追加ではPreview、データ共有、コンプライアンスを確認する
Fireworks on Foundryは、Microsoft Foundry内でFireworks AIのモデルやカスタムモデルを使えるPreview機能です。公式ドキュメントでは、PreviewはSLAなしで提供され、本番ワークロードには推奨されないと説明されています。(Microsoft Learn)
さらに、Fireworks on FoundryではMicrosoftとFireworks AIの間でデータが共有され、異なるコンプライアンスやデータ処理ルールが適用されます。EU Data Boundary、FedRAMP、PCI DSSに関する注意も明記されています。(Microsoft Learn)
Fireworksを試す前に、技術チームだけで判断せず、セキュリティ、法務、コンプライアンス部門と次の点を確認してください。
| 確認項目 | 具体的な確認内容 |
|---|---|
| データ分類 | 個人情報、決済情報、機密文書を送信しない設計か |
| 利用リージョン | 利用したいリージョンとデプロイ種別で提供されているか |
| Preview扱い | SLAなしでもPoC・検証用途として許容できるか |
| ガードレール | 既定のGuardrailsや追加のContent Safetyを使うか |
| 監査 | だれが有効化し、どのプロジェクトで使うか記録できるか |
| BYOM | カスタムモデルの場合、対応アーキテクチャと制限を満たすか |
Fireworks on Foundryでは、カタログモデルの利用だけでなく、独自またはファインチューニング済みのオープンウェイトモデルを持ち込むBYOMも扱えます。ただし、LoRAやadapter-based modelsは現時点のPreviewではサポート対象外で、フルウェイトモデルが前提です。(Microsoft Learn)
Azure AI運用チームが今すぐ行うべき影響確認
今回の更新を受けて、最初にやるべきことは「公式表を読む」ではなく、「自社の利用実態と公式表を突き合わせる」ことです。
影響確認の実務手順
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | Azure AI Foundry、Azure OpenAI、IaC、環境変数からデプロイ一覧を棚卸しする | モデル名・バージョン・リージョン・SKU一覧 |
| 2 | Model retirement scheduleと照合する | 提供終了日・置換モデル一覧 |
| 3 | Preview、Deprecated、GAを分類する | リスク別の移行優先度 |
| 4 | StandardかProvisionedかを確認する | 自動アップグレード可否 |
| 5 | 代表プロンプトで置換モデルを評価する | 品質・安全性・コスト比較表 |
| 6 | 移行日、ロールバック手順、通知先を決める | 移行計画書 |
特にProvisioned deploymentsを使っている場合は注意が必要です。公式ドキュメントでは、Standard系の一部デプロイではMicrosoftがモデル提供終了時の自動アップグレードを管理すると説明されていますが、Provisioned deploymentsは自動アップグレードされず、利用者が手動で移行する必要があると明記されています。(Microsoft Learn)
APIでライフサイクル情報を確認する方法
手作業だけで確認すると、複数リージョン・複数サブスクリプションの運用では漏れが出ます。Microsoftのライフサイクル説明では、Models APIを使って、任意のモデルのlifecycleStatus、deprecation、SKUごとのdeprecationDateを確認できるとされています。(Microsoft Learn)
GET https://management.azure.com/subscriptions/{sub}/providers/Microsoft.CognitiveServices/locations/{location}/models?api-version=2024-10-01ここで注意すべきなのは、ドキュメント上のステージ名とAPIの値が完全に同じ意味で使われない点です。公式説明では、ドキュメントやポータル上のDeprecatedはAPIではDeprecatingとして表れ、APIのDeprecatedはすでにRetiredで推論を提供しない状態を意味すると説明されています。(Microsoft Learn)
運用監視に組み込む場合は、単にlifecycleStatusだけを見るのではなく、deprecation.inferenceやSKUごとのdeprecationDateも合わせて判定してください。
監視ルールの例
| 条件 | アクション |
|---|---|
lifecycleStatusがPreview | 本番利用していないか確認し、代替モデルを登録 |
lifecycleStatusがDeprecating | 移行チケットを作成し、期限を設定 |
deprecation.inferenceが90日以内 | 検証環境で置換モデルをデプロイ |
deprecation.inferenceが30日以内 | 本番切り替え日とロールバック手順を確定 |
API上でDeprecated | すでに利用不可の可能性があるため緊急対応 |
開発者・クラウド管理者・意思決定者別の確認ポイント
今回のAzure AI公式ドキュメント更新は、関係者ごとに見るべき観点が異なります。
| 役割 | 確認すべきこと | 判断のポイント |
|---|---|---|
| 開発者 | モデルID、API互換性、レスポンス形式、JSON出力 | 置換モデルで既存コードが壊れないか |
| クラウド管理者 | サブスクリプション、リージョン、SKU、権限、通知 | 影響範囲と移行作業者を特定できるか |
| ソリューションアーキテクト | モデル選定、フェイルオーバー、RAG構成、ガードレール | 単一モデル依存を避けられるか |
| セキュリティ担当 | Content Safety、データ共有、ログ、監査 | Fireworks/DeepSeek利用時のリスクを説明できるか |
| 技術意思決定者 | コスト、SLA、Preview利用可否、移行スケジュール | 本番投入の判断基準が明文化されているか |
特にグローバル展開している組織では、リージョン差にも注意が必要です。Microsoftのライフサイクル説明では、すべてのモデルとバージョンの組み合わせが全リージョンで利用できるわけではなく、新しいモデルが一部リージョンで先に利用可能になることもあると説明されています。(Microsoft Learn)
よくある失敗と回避策
モデル名だけで影響有無を判断する
gpt-4oやgpt-5-chatのようなモデル名だけで判断すると、バージョン差を見落とします。Azure AIのモデル移行では、必ずバージョンまで確認してください。
悪い例は「gpt-4oだからまだ大丈夫」と判断することです。正しくは「gpt-4oのどのバージョンか」「Replacement列は何か」「現在のデプロイ種別は何か」まで確認します。
Previewモデルを本番の標準モデルとして扱う
Previewモデルは、APIスキーマやランタイム、提供期間が変わる可能性があります。PoCでは便利ですが、本番では代替モデル、ロールバック、品質評価を前提に使う必要があります。
Provisioned deploymentの手動移行を忘れる
Standard系の自動アップグレードに慣れていると、Provisioned deploymentでも自動で切り替わると誤解しがちです。Provisionedを使っている場合は、移行作業、容量確保、負荷テストを明示的に計画してください。
Fine-tuned modelsのトレーニング終了日だけを見る
ファインチューニングでは、トレーニング終了日とデプロイ終了日が分かれます。新規学習ができなくなるタイミングと、既存推論が使えなくなるタイミングを別々に管理しないと、再学習計画が破綻します。
FireworksやDeepSeekを「追加されたから安全に使える」と誤解する
モデルカタログや提供終了スケジュールに掲載されたことは、すべての業務で本番利用できることを意味しません。Preview、データ共有、責任分界、安全性評価、Content Safetyの設定を必ず確認してください。
移行準備で作るべきチェックリスト
最後に、今回の更新を受けてチーム内で使えるチェックリストを整理します。
| チェック項目 | 完了条件 |
|---|---|
| 利用中モデルの棚卸し | モデル名、バージョン、リージョン、SKU、デプロイ種別が一覧化されている |
| 提供終了日の確認 | 公式スケジュールと照合し、90日以内・180日以内の対象を抽出している |
| 置換モデルの検証 | Replacement列のモデルで品質・安全性・コストを比較している |
| Preview利用の整理 | Previewモデルを本番で使っている場合、代替モデルと切り替え手順がある |
| FTモデルの確認 | トレーニング終了日とデプロイ終了日を分けて管理している |
| Fireworks/DeepSeekの評価 | データ共有、Content Safety、リージョン、Preview条件を確認している |
| 通知設定 | Azure Service Healthやメール通知の受信者が最新化されている |
| ロールバック手順 | 切り替え後に旧モデルまたは別モデルへ戻す手順がある |
| 予算確認 | 並行稼働、再評価、再学習、PTU確保の費用を見積もっている |
Azure AIのモデル更新は、モデル性能だけの話ではなく、運用継続性、コンプライアンス、コスト管理に関わる変更です。今回の「Fix retirement dates, add Fireworks/DeepSeek partners, add FT section」は、利用中モデルの棚卸しと移行計画を見直すよいタイミングです。
まずは、自社のAzure AI Foundry / Azure OpenAIデプロイ一覧を取得し、公式のModel retirement scheduleと照合してください。そのうえで、提供終了日が近いモデル、Previewのまま本番利用しているモデル、Fine-tuned models、Fireworks/DeepSeekなどの新しいパートナーモデルを分けて評価すると、移行漏れや本番障害のリスクを大きく減らせます。
コメント