Azure OpenAIのモデル廃止に備える方法｜確認手順・自動アップグレード・移行の進め方

Azure OpenAIのモデル廃止でつまずくのは、日付を知らなかったからではありません。「廃止」と書かれた状態でも既存のデプロイは動き続ける一方、「引退」に入った瞬間に推論が410 Goneを返すという段差を、運用側が同じ言葉として扱ってしまうからです。しかもModels APIが返すlifecycleStatusの値は、ドキュメントの表記と1段ずれています。この記事では2026年8月時点の公式ドキュメント実測をもとに、廃止日の確認経路・自動アップグレードとバージョン固定の挙動差・移行手順を、実装者の解像度で整理します。

まとめ：廃止対応で押さえる5点

先に結論です。この5点を運用へ落とせば、廃止で本番が止まる事態はほぼ防げます。

• 「廃止（Deprecated）」は新規顧客がデプロイを作れなくなる段階で、既存デプロイは動き続ける。「引退（Retired）」でサービスから削除され、推論はすべて410 Goneになる
• 一般提供（GA）モデルの引退日は、起動時点で18か月後にプログラム設定される。個別のアナウンスは出ないため、待っていても情報は来ない
• 確認の主経路はModels API。lifecycleStatusとdeprecation.inferenceを組で読む。従の経路がAzure Service Healthのアラート
• Standard系のデプロイは自動アップグレードされるが、プロビジョニング済み（PTU）は自動では上がらない。手で移す
• 引退日の延長は公式に不可と明言されている。交渉の余地がない期限として扱う

特に3点目と4点目の取り違えが多く見られます。「通知が来るはず」と「自動で上がるはず」を両方前提にした構成は、PTUを使っている環境で確実に落ちます。

Azure OpenAIの廃止と引退はどう違うのか｜ライフサイクル5段階の定義

Microsoft Foundryのモデルは、プレビューから引退まで5つの段階を進みます。段階ごとに「新しいデプロイを作れるか」と「既存のデプロイが動くか」が独立して変わる点が、運用設計の起点になります。

Azure OpenAIモデルにおける5つの段階とデプロイ可否・稼働可否の対応関係

公式の整理を表にすると次のとおりです。

ここでいう「既存顧客」はサブスクリプション単位で判定されます。該当バージョンをデプロイした実績があるかどうかで決まり、同じテナントに新設したサブスクリプションはアクセス権を引き継ぎません。検証環境を作り直しただけで、廃止段階のモデルが載せられなくなる場面があります。

なおレガシー段階は省略される場合があり、一般提供から廃止へ直接進むこともあります。「レガシー表示が出てから動けばよい」という前提は置けません。

一般提供モデルの18か月ライフサイクルと移行に使える重複期間の考え方

一般提供モデルは、起動から12か月で廃止段階に入り、18か月で引退します。この18か月はモデルごとの裁量ではなく、起動時にプログラムで設定される値です。

移行に使える重複期間も明示されています。置換モデルは引退の約90日から120日前に宣言され、Global Standardでは約90日前からテストできる一方、プロビジョニング済みリージョンでは約30日前からと幅が違います。PTUを使う環境ほど手を動かせる期間が短い設計です。

例外は2つ。ベンダー差として、Anthropic・DeepSeek・Fireworks・Mistral AIの一般提供モデルは18か月ではなく12か月のライフサイクルに従います。もうひとつがセキュリティ優先の廃止で、コンプライアンス上の問題が判明した場合、Microsoftは短縮通知での緊急提供終了を留保しています。

Models APIの値が公式ドキュメントの定義と1段ずれる落とし穴

実装で最も事故りやすいのがここです。Models APIのlifecycleStatusは、ドキュメントやFoundryポータルの段階名と一対一で対応しません。

つまりAPIがDeprecatedを返したときは「廃止」ではなく「引退済み」です。文字列だけで分岐を書くと、まだ動くモデルを止めたり、止まっているモデルを動くと誤認したりします。公式が示す判定順序は、lifecycleStatusがDeprecatedなら引退、Deprecatingなら廃止、deprecation.inferenceが今日より前なら状態表示の遅延に関わらず引退、という並びです。日付フィールドを最後の砦として併読してください。

Azure OpenAIモデル廃止スケジュールの確認方法｜API・ポータル・通知の3経路

確認経路は3つあり、役割が違います。ひとつに寄せると抜けが出ます。

Models APIでサブスクリプション内の廃止日を機械的に取る

主経路はModels APIです。サブスクリプションとリージョンを指定して、そのリージョンで扱えるモデルの一覧とライフサイクル情報をまとめて取得します。

エンドポイントはAzure Resource Manager配下のCognitiveServicesプロバイダーで、サブスクリプションIDとリージョンを埋め込んだmodelsパスをGETし、api-version=2024-10-01を付けて呼びます。読むべきキーはlifecycleStatus、推論の廃止日を示すdeprecation.inference、微調整の廃止日を示すdeprecation.fineTune、SKUごとのdeprecationDateです。

この呼び出しを週次ジョブに入れ、稼働中のデプロイ名とモデルIDを突き合わせて「残り90日を切った行」を通知する仕組みまで作れば、廃止対応は定常運用へ載ります。ドキュメントの表を目視で追う運用は、モデル数が増えた時点で破綻します。

Azure Service Healthでアラートを設定するときの注意点

従の経路がAzure Service Healthです。影響を受けるサブスクリプションには正常性アドバイザリが表示され、メール・SMS・Webhookで受け取るアラートルールを作れます。

設定時に迷いやすいのがサービス名です。Service Healthに「Microsoft Foundry」という項目はなく、Azure OpenAI Serviceを選んでフィルタします。ブランド名の変更に引きずられて探すと見つかりません。受信先はアラートルールで指定できるため、開発チームの共有アドレスへ寄せておくと引き継ぎで情報が途切れません。

通知が届くタイミングと通知を待たずに移行を始める運用の組み方

能動的な通知が飛ぶのは2ケースです。一般提供モデルは引退の少なくとも60日前、プレビューモデルは少なくとも30日前。宛先はアクティブなデプロイを持つサブスクリプション所有者です。

ただし公式は「一般提供モデルの引退日は起動時に設定され、個別のお知らせはない」とも明記しています。60日前の通知は最終確認であり、移行計画の起点にはなりません。60日で評価から回帰テストまで畳めば、精度差の検証が省かれます。Models APIで半年先を見て90日前に着手する運びが現実的です。

自動アップグレードとバージョン固定｜挙動の差を設定値で押さえる

廃止日が来たときにデプロイがどうなるかは、デプロイの種類とversionUpgradeOptionの組で決まります。

versionUpgradeOptionの3つの値と、それぞれで起きること

Standard系デプロイでは、アップグレードのタイミングをOnceNewDefaultVersionAvailable・OnceCurrentVersionExpired・NoAutoUpgradeの3値から選べます。REST API、Azure PowerShell、Foundryポータルのいずれからも設定できます。

NoAutoUpgradeの意味を取り違えないでください。これは「そのバージョンを使い続けられる」設定ではなく、「引退日に停止させる」設定です。期限が来ればデプロイは動作を止めます。バージョンを固定したいだけならOnceCurrentVersionExpiredを選び、引退日に自動で後継へ移る形にしておくほうが安全側に倒れます。

自動アップグレードはリージョンごとに順次スケジュールされ、その日程はモデル引退スケジュールに事前公開されます。新しいバージョンがそのリージョンやSKUで未提供でも、アップグレード処理の側で利用可能にしたうえで切り替わる仕様です。

プロビジョニング済みデプロイが自動では上がらない場合の移行分岐

ここが構成による最大の分かれ目です。Global Standard・Data Zone Standard・Standardの3種はMicrosoftが自動アップグレードを管理しますが、プロビジョニング済み（PTU）のデプロイは自動アップグレードされません。利用側が手で置換モデルへ移す必要があります。

移行の方法は2通りです。インプレース移行は既存デプロイのモデルを差し替える形で、ダウンタイムなしに20分から30分でトラフィックが移ります。サイドバイサイド移行は新しいデプロイを作り、テスト後にトラフィックを切り替えて旧デプロイを削除する流れです。回帰テストの余地を残すならサイドバイサイドを選びます。

クォータの扱いも異なります。Standardの自動アップグレードではクォータが自動処理される一方、PTUでは移行前にターゲットモデルのクォータ確認が要ります。PTU容量自体はモデルに依存せずプロビジョニング済みマネージドデプロイ間で融通できるため、容量の再取得までは通常不要です。バッチデプロイはサイドバイサイド移行に従い、新モデルをデプロイしてジョブを再送信してから旧デプロイを畳みます。

プレビューモデルと微調整済みモデルで異なる提供終了時の基本前提

プレビューモデルは一般提供と前提が異なります。通常90日以内の提供終了日を持って起動し、決定が下されると強制的に後継へアップグレードされるか、置換なしで引退します。廃止されるプレビュー版に残る選択肢はありません。少なくとも30日の通知は出るものの、本番ワークロードには推奨されないと明記されています。

微調整済みモデルはトレーニングとデプロイの2フェーズで終了します。トレーニングが終わると新しい微調整はできなくなり、既存の学習済みモデルはデプロイに使える状態が続きます。gpt-4o（2024-08-06版）ならトレーニング終了が2027年4月1日より前、デプロイ終了が2027年10月1日という組です（2026年8月時点）。学習コストの償却期間はデプロイ終了日から逆算します。

Azure OpenAIモデル廃止前の移行手順｜評価・デプロイ切替・回帰テストの回し方

手順は3工程です。順序より、各工程で何を固定するかが結果を左右します。

工程1：公式の置換モデルを決めて自社ワークロードで精度差を評価する

まず確認するのは、モデル引退スケジュールの「交換」列です。公式に置換が示されている組もあれば、空欄のままの行もあります。空欄なら同系統の後継から自分で選びます。

評価では、Foundryポータルのモデルランキングとベンチマーク比較、デプロイ時のモデル比較機能、そして自社ワークロードでの評価を組み合わせます。ここで見るべきは総合スコアではなく、実際に流している入力での出力差です。プロンプトの調整や微調整で以前の精度に合わせられるかまで確認して、初めて置換候補が確定します。どのモデルが候補になるかを系統から絞りたい場合は、Azure OpenAI Serviceのモデル一覧と選び方で系統別のコンテキスト長や提供終了日を整理しています。

見落とされやすいのがパラメータの互換性です。世代をまたぐと推論強度の既定値や対応APIが変わる場合があり、同じ入力で同じ形の出力が返るかは精度とは別枠で確認します。

工程2：新旧デプロイを切り替えるときの安全な並走構成と切戻し経路

切替の起点は、新旧を並走させる構成です。新しいデプロイ名で置換モデルを立て、アプリケーション側はデプロイ名を環境変数などで外出しにしておきます。コードにgpt-4oのようなモデルIDを直書きしていると、切替のたびにリリースが要ります。

並走期間はトラフィックを一部だけ新デプロイへ流し、応答時間・エラー率・出力の形式を旧デプロイと並べて見ます。異常が出たら環境変数を戻すだけで切戻せる状態を保ってください。旧デプロイの削除は、並走で問題が出ないと確認できてからで構いません。

PTU環境では自動では上がらないため、この並走構成が事実上の必須手順です。Standard環境でもOnceCurrentVersionExpiredへ任せきりにせず、期限前に自分の手で切り替えたほうが、障害の発生タイミングを選べます。

工程3：回帰テストで本番影響を抑える主要4つの検証観点の並べ方

回帰テストは4つの観点で組みます。第1に出力フォーマットで、JSONスキーマや区切り記号に依存した後段処理が壊れないか。第2に判断の一致率で、分類や抽出なら旧モデルの結果を正解セットとして測る工程です。第3にトークン消費で、推論モデルへ移ると思考トークンの分だけコストが跳ねます。第4にレイテンシで、タイムアウト設定が新モデルの応答時間に耐えるかを見ます。

この4観点を1回のテストで通そうとすると粒度が粗くなりがちです。フォーマットと一致率は自動テストへ、消費とレイテンシは並走期間の実測へ、と置き場所を分けるほうが精度が出ます。Azure OpenAI Serviceの基本的な仕組みと料金体系を前提知識として押さえておくと、コスト側の見積りが早く終わります。

Azure OpenAIモデル廃止対応の構成をどう決めるか｜採用条件と見送る場面

ここまでの仕様を踏まえて、どの構成を採るかを言い切ります。

自動アップグレードに任せてよい構成条件と任せてはいけない業務条件

自動アップグレードに任せてよいのは、次の3条件がすべて成立する場合です。

1. デプロイの種類がStandard系である：PTUでは自動で上がらない
2. 出力が人の目を経由する：チャットUIや下書き生成のように、形式の揺れを人が吸収できる
3. 出力フォーマットに依存した後段処理がない：スキーマ検証やパース処理を挟んでいない

逆に、出力をそのままデータベースへ入れる構成、他システムへ連携する構成、業務判断を自動で確定させる構成では任せるべきではありません。自動アップグレードはバージョンが変わることだけを保証し、出力の互換性までは保証しないからです。この場合はOnceCurrentVersionExpiredで版を保ち、期限の90日前から手で移します。

ベンダー差と通知期間の短さを織り込んだ本番モデル採用時の判断基準

採用時点で廃止のコストまで見込むなら、ライフサイクルの長さを選定軸に入れます。Azureが販売するOpenAI系の一般提供モデルは18か月ですが、Anthropic・DeepSeek・Fireworks・Mistral AIの一般提供モデルは12か月です。同じ期間で見れば移行回数が1.5倍になります。

通知期間の差も無視できません。Standard（トークン単位）の推論プランにおけるFireworksモデルは、提供終了に先立つ事前通知が15日間とされています。60日前提の運用ルールを敷いていると、この15日で対応しきれません。パートナー経由のモデルを本番に載せるなら、通知期間をモデル単位で確認し、移行の自動化度合いを上げておく必要があります。

プレビュー版の本番投入も同様です。90日刻みで期限が来るモデルを本番に置けば四半期ごとに移行作業が発生するため、本番はGA版へ寄せる線引きが結局は安く付きます。

モデル移行を見送ってよい時期と前倒しで着手すべき代表的な3つの場面

見送ってよいのは、引退日まで1年以上あり、後継モデルの置換が公式に宣言されていない段階です。置換は引退の約90日から120日前に決まるため、それより早く動くと移行先が最終的な推奨と食い違いかねません。Microsoft自身も生成AIの改善速度を理由にこの時期を選んでいます。

前倒しすべきなのは3つの場面です。ひとつはPTUを使っていて移行の重複期間が約30日しかない場合。ふたつめは微調整済みモデルを運用していて、トレーニング終了とデプロイ終了の二段の期限がある場合。みっつめは推論モデル系を使っていて、後継の推論強度や対応APIが変わる場合です。たとえばOpenAI直APIのo1が提供終了する経緯はOpenAI o1のAPI提供終了と移行先で扱いましたが、Azure側でも同系統の期限が2026年後半に集中しています。

2026年8月時点で近い期限を抜き出すと次のとおりです。網羅版は公式のモデル引退スケジュールを参照してください。

o3-miniの置換先がo4-miniで、そのo4-mini自体も約2週間後に引退する構図に注意してください。公式の置換列をそのまま採れば、2か月後にもう一度移行が必要です。この種の連鎖は表を1行ずつ見ていては気付けないため、移行先候補の引退日まで含めて確認します。廃止スケジュールを織り込んだ構成の設計や、移行時の評価・回帰テストまで含めて相談したい場合は、生成AI開発・AI受託開発で個別の要件に沿って対応します。

よくある質問

Azure OpenAIのモデル廃止について、実装前によく確認される点をまとめます。

廃止されたモデルを呼び出すとどうなりますか？

返る結果は段階ごとに別です。廃止（Deprecated）段階なら既存のデプロイは動き続け、これまでどおり応答が返る状態です。引退（Retired）段階へ入るとサービスから削除され、すべての推論要求が410 Goneを返します。エラーハンドリングでは、レート制限やタイムアウトと区別して410を検出しアラートへ回す分岐を入れると、原因の切り分けが早く済みます。

モデルの提供終了日を延長してもらえますか？

できません。公式ドキュメントは延長も例外の取得も不可と明記し、モデル引退スケジュールとModels APIで公開されたタイムラインを前提に移行を計画する方針を示しています。交渉余地のある期限ではないため、社内の年間計画へ固定の作業として組み込んでください。

自動アップグレードのタイミングは制御できますか？

Standardデプロイでは制御が可能です。versionUpgradeOptionをOnceNewDefaultVersionAvailable（新しい既定版が出たら上げる）、OnceCurrentVersionExpired（引退時にだけ上げる）、NoAutoUpgrade（上げない）の3値から選択する仕組みです。ただしNoAutoUpgradeでは引退日にデプロイが動作を停止します。プロビジョニング済みデプロイはそもそも自動アップグレードの対象外で、手動移行になります。

埋め込みモデルも同じライフサイクルで廃止されますか？

いいえ、扱いが分かれます。text-embedding-3-large・text-embedding-3-small・text-embedding-ada-002の埋め込み系には、推論モデルより長いタイムラインが設定されており、2026年8月時点の引退日はいずれも2028年2月9日です。ただし埋め込みにはモデル間のアップグレードという概念がなく、モデルを変えるならベクトルを全件作り直す前提になる点は別途見込んでください。

Azure Government環境では廃止の扱いが変わりますか？

変わる部分があります。政府機関向けクラウドではGlobal Standardデプロイが提供されず、商用クラウドで使えるモデルやバージョンがすべて揃うわけでもありません。加えて、サポートされるバージョンが一度に1つだけで、新バージョン提供時の重複期間は30日間とされています。商用クラウドの90日前提で移行計画を組むと間に合いません。

関連記事

• Azure OpenAI Serviceのモデル一覧と選び方｜GPT・推論・埋め込み・音声を用途別に整理：系統別のカタログと提供終了日の網羅版を確認できます。
• Azure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説：サービスの定義・料金体系・導入事例から入りたい場合の入口です。
• OpenAI o1とは？API提供終了（2026年10月23日）と移行先：OpenAI直APIの提供終了と移行先の考え方を扱っています。
• Azure OpenAIでGPT-5を使う方法｜デプロイ・クォータ・推論パラメータの実装手順：デプロイ名の設計と移行時のパラメータ差分を実装目線で扱います。