Azure OpenAIのモデル廃止。廃止日の確かめ方と移行で会社がやること

Azure OpenAIのモデル廃止とは、Azure上で動かしているOpenAIのモデルが、Microsoftの定めた段階に沿って新規の利用を止められ、最後にはサービスから外されることを指します。日本語版の公式ページで「廃止」と書かれた段階のモデルはまだ動いており、実際に止まるのは「引退」「退役」と書かれた提供終了日で、その日以降の呼び出しには410エラーが返ってきます。自動更新を止める設定にしていなければ、Global StandardやStandardなど従量課金のデプロイは、後継モデルが示されていれば提供終了日に自動で切り替わりますが、予約制のProvisionedは自分で移すことになります。どちらの場合も、使っているデプロイと日付を社内で先に押さえておきましょう。

Azure OpenAIそのものの仕組みや料金の見積もり方、自社で組むときの作業は、Azure OpenAIとは？ChatGPTとの違い・料金の見積もり方・自社構築に必要な作業で整理しています。

「廃止」と「引退」は別の段階｜止まるのは引退の日

Azure OpenAIのモデルは、公開から提供終了までの間に5つの段階を順に進みます。英語の原文の説明では、カタログのどのモデルも必ず5つのうちどれか1つの段階に入ることになります。

  • Preview（プレビュー）：試験的に提供されている段階です。提供終了の通知は、少なくとも30日前と短めになります。
  • GA（一般提供）：正式に提供されている段階になります。
  • Legacy（レガシー）：より新しいモデルがあり、移行を計画すべき段階です。新しいデプロイも作れますが、この段階を飛ばしてGAから次へ進むこともあります。
  • Deprecated（日本語版では「廃止」）：すでに使っている顧客は、引き続きデプロイの作成や管理が出来ます。新しい顧客は使えません。
  • Retired（日本語版では「引退」）：サービスから外され、すべての推論の呼び出しに410 Goneというエラーが返ります。

日本語版の公式ページは「廃止」がまだ動く段階

日本語版の公式ページでは、Deprecatedが「廃止」、Retiredが「引退」や「退役」と訳されています。普通の感覚で「廃止」と読むと、もう使えない状態を思い浮かべてしまうでしょう。実際には、日本語版の表で「廃止」と出ているモデルは、既存の顧客であればまだ呼び出せる状態になります。

止まるのは「引退」の日で、日本語版で「廃止」と書かれた段階ではまだ動いています。提供終了スケジュールの日本語版では、Retiredが「退役」、Retirement dateの列が「退職日」、Replacementの列が「交換」と訳されているので、読み替えが要ります。社内で共有するときは、DeprecatedやRetiredといった英語の段階名も一緒に書いておきましょう。

Models APIの値は画面の段階名と1つずれる

段階と日付は、Models APIというMicrosoftの管理用のAPIからも取り出せます。呼び出し先は次のURLで、{sub}にサブスクリプションのID、{location}に地域の名前を入れます。

GET https://management.azure.com/subscriptions/{sub}/providers/Microsoft.CognitiveServices/locations/{location}/models?api-version=2024-10-01

返ってくる値には、段階を表すlifecycleStatusや、提供終了の日付を表すdeprecation.inferenceなどの項目が含まれます。気を付けたいのは、APIの値が画面の段階名と1つずれている点です。画面でDeprecatedと表示される段階はAPIでは「Deprecating」、画面のRetiredはAPIでは「Deprecated」として返ってきます。

原文でも、APIの「Deprecated」はすでに提供を終えて推論に応じないモデルを意味する、と説明されています。プログラムで日付を集めて社内に流す仕組みを作るときは、この読み替えを最初に組み込んでください。

GAモデルの提供期間は18か月｜12か月で新規の顧客は使えなくなる

一般提供（GA）のモデルは、提供を始めた時点で18か月後の提供終了日がプログラムで決められています。その日付はModels APIでも取り出すことが出来ます。流れとしては、提供開始から12か月でDeprecatedになって新しい顧客は使えなくなり、18か月でRetiredとなって410エラーが返るようになります。

同じFoundryのカタログに並ぶモデルでも、Anthropic・DeepSeek・Fireworks・Mistral AIのGAモデルは、18か月ではなく12か月のライフサイクルになっています。

既存の顧客かどうかはサブスクリプションごとに決まる

Deprecatedの段階でも使い続けられる既存の顧客かどうかは、会社単位ではなくサブスクリプション単位で判断されます。そのサブスクリプションで、該当するモデルのバージョンを一度でもデプロイしたことがあるかが基準になります。原文には「A new subscription under the same tenant doesn't inherit access.」とあり、同じテナントの中で新しく作ったサブスクリプションには権利が引き継がれません。

部署ごとに環境を分けるつもりでサブスクリプションを増やすと、思わぬところで引っかかります。新しく切ったサブスクリプションでは、Deprecatedのモデルをデプロイ出来なくなってしまいます。環境を作り直す予定がある会社は、移行の順番に気を付けてください。

提供終了日は延ばせない

提供終了日の延長は受け付けられていません。公式のよくある質問には「No. Retirement dates aren't extendable.」とあります。移行の手引きにも、例外の手続きはないと書かれています。さらに、コンプライアンスやセキュリティ上の問題があるときは短い予告で提供が終わる場合もあるとされ、表の日付より前に止まる可能性まで考えておく必要があるでしょう。

提供終了の通知はいつ・誰に届くか

提供終了の知らせは、GAモデルなら少なくとも60日前に、メールとAzure Service Healthの両方で届きます。ただし、メールが届く相手は会社の側で選べるわけではありません。

通知のタイミングはGAで60日以上前

プレビューのモデルは、少なくとも30日前の通知になります。後継モデルは、提供終了のおよそ90日前からGlobal Standardで試せるようになり、Provisionedの地域ではおよそ30日前からとなっています。後継の正式な指定は、提供終了の約90〜120日前に出されます。

モデルの新しいバージョンが既定に切り替わるときは、少なくとも2週間前に知らせが出ます。60日という期間は、テストと社内の調整を考えると決して長くはないでしょう。知らせを待たずに、公式の表で先に日付を拾っておくことをおすすめします。

通知メールはサブスクリプションの所有者に届く

通知のメールは、アクティブなデプロイがあるサブスクリプションの所有者へ自動で送られます。モデルのバージョンを説明した別のページでは、所有者と共同作成者にメールが届くと書かれています。どちらの記載でも、届く先はAzure上でその役割を持っている人のアドレスになります。

開発を外部に任せていて、サブスクリプションの名義が委託先になっている場合は、知らせそのものが社内に届かないことになってしまいます。立ち上げのときに情シスの担当者が個人のアカウントで所有者になり、その方が退職や異動をしていれば、知らせは誰にも読まれません。

Service Healthアラートの作り方

Azure Service Healthの正常性アドバイザリ（Health advisories）にも提供終了の知らせが載るので、ここにアラートを作っておくと見逃しにくくなります。公式文書の手順は次のとおりで、画面の名前は公式文書の英語表記のまま載せています。

  1. Azure portalでService Healthを開き、Service IssuesパネルでCreate service health alertを選びます。
  2. Scopeで、対象のサブスクリプションを選びます。
  3. ConditionのServicesでAzure OpenAI Serviceを選び、Regionsで地域を、Event typesで知らせの種類を選びます。
  4. Detailsで、アラートルールを置くリソースグループとアラートルール名を決めます。
  5. Notify me byで、メールアドレスやAzure Resource Managerのロールへのメールなど、知らせを受け取る方法を指定します。
  6. Createを押して作成します。

Service Healthの中に「Microsoft Foundry」という名前のサービスはないため、Azure OpenAI Serviceを選んでください。公式の注意書きには、すべてのサービスと地域を選んでも、使っていない地域のアラートは届かないとあります。地域を絞り込みすぎて取りこぼすより、広めに選んでおくほうが安心でしょう。

作成には、アラートルールの対象を読み取る権限と、作成先のリソースグループへの書き込み権限が要ります。通知先をまとめるAction Groupを作るときは、リージョンをGlobalにしておきましょう。メールのほかにSMSやWebhookでも受け取ることが出来ます。

通知の届け先は人ではなく役割で決める

所有者へのメールだけに頼っていると、担当者が替わった時点で知らせの行き先がなくなってしまいます。アラートの宛先には、特定の人ではなく、複数人が読める共有のアドレスを入れておきましょう。あわせて、次の4つを社内で決めておくと抜けが減ります。

  • Notify me byには、情シスの代表アドレスやグループのアドレスなど、人の入れ替わりに左右されない宛先を入れる
  • サブスクリプションの所有者と共同作成者を年に1回見直し、退職・異動した方を外す
  • 委託開発なら、サブスクリプションの名義が誰か、知らせが届いたら何日以内に社内へ転送するかを取り決めておく
  • 届いた知らせを、誰が次の節の棚卸し表に書き込むかを決める

名義と宛先が決まっていれば、60日前の知らせを社内の担当へつなぎやすくなります。

使うAIの窓口を会社で1つにまとめる

モデルの入れ替えのたびに窓口が増えて困っているなら、使う環境を会社で1つにまとめる方法もあります。UPGEAR AI（アップギアAI）は、ChatGPT・Claude・Gemini・Perplexityを1つの契約で使える法人向けサービスです（人数無制限）。

資料をダウンロードUPGEAR AI（アップギアAI）を詳しく見る

2026年10月6日時点の提供終了日｜主要モデルと確かめ方

日付は、Microsoft Learnの提供終了スケジュールのページにある表で確かめるのが確実です。次の一覧は、2026年10月6日時点で公式の提供終了スケジュールに掲載されている日付から、社内ツールで使われていそうなものを抜き出したものになります。

  • gpt-4.1-nano（2025-04-14）：Deprecated、提供終了は2026年10月14日。後継モデルの記載はありません。
  • gpt-4o-transcribe・gpt-4o-mini-transcribe（2025-03-20）：GA、提供終了は2026年10月15日。
  • codex-mini（2025-05-16）：Deprecated、提供終了は2026年11月15日。
  • o1・o1-pro・o3・o3-deep-research・o3-pro：Deprecated、提供終了は2026年11月19日。後継はgpt-5.6-solです。
  • o3-mini・o4-mini：Deprecated、提供終了は2026年11月19日。後継はgpt-5.6-terraです。
  • gpt-4o（2024-05-13）：Deprecated、提供終了は2026年12月9日。後継はgpt-5.6-solです。
  • whisper・tts-hd（001）：提供終了は2026年12月15日。
  • gpt-5・gpt-5-mini・gpt-5-nano（2025-08-07）：GA、提供終了は2027年2月9日。
  • gpt-4o（2024-08-06）：Deprecated、提供終了は2027年4月14日。後継はgpt-5.1です。
  • gpt-4o（2024-11-20）：Legacy、提供終了は2027年4月14日。後継はgpt-5.1です。
  • gpt-4o-mini（2024-07-18）：Deprecated、提供終了は2027年4月14日。
  • gpt-4.1・gpt-4.1-mini（2025-04-14）：Deprecated、提供終了は2027年4月14日。
  • gpt-5.1（2025-11-13）：GA、提供終了は2027年5月15日。

※日付は2026年10月6日時点で、Microsoft Learnの「モデル引退スケジュール」（日本語版は2026年10月2日更新）に掲載されている提供終了日と後継モデルです。日付と後継モデルは変わることがあるため、作業の前に公式の表で確かめてください。

gpt-5-chat・gpt-5.1-chat・gpt-5.2-chat・gpt-5.3-chatは、2026年5月13日または6月29日にすでに提供を終えており、後継にはgpt-chat-latestが示されています。日付は動くことがあるため、ネット上の解説記事や販売会社のお知らせに残っている日付をそのまま信じないようにしましょう。実際に、gpt-4o（2024-05-13）を2026年10月1日に終了とする案内も見つかりますが、確認日時点の公式の表では2026年12月9日となっています。

社内の資料には、日付と一緒に、公式の表で確かめた日も書き添えておきましょう。公式の文書にも、日付と後継モデルは変わることがあるので、アップグレードの前にスケジュールで最新の内容を確かめるよう書かれているため、作業の直前にもう一度開いてみてください。

gpt-4o・gpt-4o-miniの提供終了日と移行先

gpt-4oは、バージョンによって提供終了日と後継が分かれています。2024-05-13版は2026年12月9日に終わり、後継はgpt-5.6-solになります。2024-08-06版と2024-11-20版はどちらも2027年4月14日で、後継にはgpt-5.1が指定されています。同じgpt-4oという名前でも、バージョンが違えば対応の時期が4か月以上ずれることになってしまいます。

gpt-4o-mini（2024-07-18）とgpt-4.1・gpt-4.1-miniも2027年4月14日が提供終了日で、確認日時点ではいずれもDeprecatedの段階にあります。公式の例では、Standardのgpt-4o（2024-05-13）は提供終了日にgpt-5.6-solへ自動でアップグレードされると説明されています。使っているデプロイのバージョンは、Foundryポータルでデプロイを開き、Detailsタブで確かめることが出来ます。

ファインチューニング済みモデルは提供終了日が別に載っている

自社のデータで追加学習（ファインチューニング）したモデルは、元のモデルとは別に、デプロイの提供終了日が表に示されます。2026年10月6日時点の掲載では、gpt-4o（2024-08-06）とgpt-4o-miniをもとにしたものは2027年10月1日、gpt-4.1系をもとにしたものは2027年10月14日となっています。元のgpt-4o（2024-08-06）の提供終了日である2027年4月14日とは違う日付なので、同じモデル名でも取り違えないようにしましょう。

追加学習したモデルを新しいモデルへ載せ替えるときは、作り直しも含めて検討が要るため、通常のデプロイより早めに予定を組んでおくと安心です。

Azure Governmentは別の表で確かめる

政府機関向けのAzure Governmentでは、提供終了の日付が別のページにまとまっています。Global Standardは政府クラウドでは使えず、商用クラウドのすべてのモデルとバージョンがあるわけでもありません。原文では、政府クラウドは通常1つのモデルにつき1つのバージョンだけを扱い、新しいバージョンが出ると30日間だけ重なると説明されています。新しいバージョンが出てから30日しか重ならない前提で、移行の段取りを組んでおきましょう。

自動アップグレードの対象はStandard系｜Provisionedは自分で移す

提供終了日に新しいモデルへ自動で切り替わるのは、Global Standard・Data Zone Standard・Standardの3種類のデプロイ（Priority Processingも同じ扱い）です。切り替えは地域ごとに順番に進み、予定は提供終了スケジュールに前もって載せられます。一方で、予約制のProvisioned（PTU）は自動では切り替わらず、自分で移す必要があります。後継の欄が「—」のモデルは、提供終了日に自動で切り替わるとは公式の表から読み取れません。日付までに自分で移す前提で予定を組みましょう。

移し方には、20〜30分ほどで停止なしに入れ替えるin-placeと、新しいデプロイを並べて作って切り替えるside-by-sideの2通りが用意されています。Batchのデプロイは、新しいモデルをデプロイしてジョブを出し直すside-by-sideで移すことになります。

移行の手引きには「Auto-upgrade is only a safety net for pay-as-you-go deployments, not a migration plan.」とあり、自動アップグレードは従量課金のデプロイの安全網であって、移行の計画ではないと書かれています。返事が返ってくることと、業務で正しく動くことは別の話です。モデルが替わると、口調や書式、JSONの形、待ち時間、費用、ツールの呼び出し方まで変わることがあります。自動で切り替わる前に、業務で使う入力を流して結果を見比べておきましょう。

versionUpgradeOptionの3つの設定と業務への影響

自動アップグレードの動きは、デプロイごとのversionUpgradeOptionという設定で決まります。設定はFoundryポータル、REST API、PowerShellのどれからでも変えることが出来ます。3つの設定を、業務で起きることの言葉に置き換えると次のようになります。

  • OnceNewDefaultVersionAvailable（ポータルの表記はUpgrade once new default version becomes available）：新しい既定のバージョンが出た時点で更新されます。止まる心配は小さい反面、知らないうちに中身が替わる時期が3つの中で早く来ます。
  • OnceCurrentVersionExpired（ポータルの表記はOnce the current version expires）：今のバージョンが提供終了日を迎えた時点で更新されます。それまでは中身が変わらず、提供終了日に知らないうちに中身が替わります。
  • NoAutoUpgrade（ポータルの表記はOpt out of automatic model version upgrades）：自動では更新しません。中身は替わりませんが、提供終了日を過ぎるとデプロイが止まります。

止まる設定と、知らないうちに中身が替わる設定の、どちらの痛手が大きいかは業務によって違ってきます。回答の文面を人が読む社内のチャット用途なら、中身が替わっても気づいて直しやすいため、OnceCurrentVersionExpiredのままでもよいでしょう。出力をそのまま別のシステムに渡す用途では、JSONの形が変わると後ろの処理が崩れてしまうため、NoAutoUpgradeにして日付までに自分で移すほうが管理しやすくなります。

ただしNoAutoUpgradeは、移行を忘れると提供終了日にそのまま止まってしまいます。選んだ設定とその理由は、次の節の棚卸し表に書き残しておいてください。

地域とデプロイの種類で提供状況が変わる

すべてのモデルとバージョンの組み合わせが、すべての地域で使えるわけではありません。新しいモデルは、Global Standard、Global Provisioned、Data Zone、地域を指定するStandardやProvisionedの順に広がっていきます。Global Standard以外での提供は保証されていないため、データを指定した地域の中で処理したくて地域指定のデプロイを選んでいる会社は、後継モデルが使える時期が遅れる場合もあると考えておきましょう。後継が自分の地域とデプロイの種類にいつ来るかは、移行の計画を立てる前に確かめてください。

社内のデプロイを棚卸しする｜記入例つきの一覧表

移行の最初の作業は、社内でどのデプロイが、どのモデルの、どのバージョンで動いているかを1枚の表にまとめることです。委託開発の場合も、表の中身は開発会社に埋めてもらい、社内で持っておくようにしましょう。

デプロイ名モデルバージョンデプロイの種類自動更新の設定提供終了日（確認日）担当使っている部署
chat-soumugpt-4o2024-05-13StandardOnceCurrentVersionExpired2026-12-09（2026-10-06確認）情シス担当A総務部（社内規程の問い合わせBOT）
faq-bot-prodgpt-4o-mini2024-07-18Global StandardNoAutoUpgrade2027-04-14（2026-10-06確認）委託先＋情シス担当A営業部（お客様への返信の下書き）
invoice-extractgpt-4.12025-04-14Data Zone Provisioned自動では移らない（手動で移行）2027-04-14（2026-10-06確認）情シス担当B経理部（請求書の読み取り）
minutes-whisperwhisper001StandardOnceNewDefaultVersionAvailable2026-12-15（2026-10-06確認）情シス担当B全社（会議の文字起こし）

※表は記入例です。デプロイ名・担当・部署は架空のもので、提供終了日は2026年10月6日時点で公式の提供終了スケジュールに掲載されている日付です。

表を作るときは、Foundryポータルのデプロイの一覧で名前とモデルを拾い、各デプロイのDetailsタブでバージョンを確かめていく流れになります。自動更新の設定が表示されないデプロイは、OnceCurrentVersionExpiredと同じ扱いです。提供終了日の列には、日付と一緒に、公式の表で確かめた日を必ず書き込んでください。

使っている部署の列は、技術の担当者だけでは埋まらないことが多いため、総務や各部署の責任者にも聞き取りをしましょう。この表があれば、知らせが届いたときに影響する部署と担当がすぐ分かるようになります。表は四半期に1回、公式の提供終了スケジュールと突き合わせて更新していくのが現実的です。

置き換えモデルへの移行手順と、終える前のチェックリスト

移行は、Microsoftの移行の手引きにある6つの段階に沿って進めると漏れが少なくなります。

移行の6つの段階

手引きでは、Discover、Assess、Adapt、Validate、Roll out、Retireの順に進めるよう示されています。社内でやることに置き換えると、次のような流れになります。

  1. Discover：使っているデプロイとモデルを洗い出します。前の節の棚卸し表がこれに当たります。
  2. Assess：後継モデルの候補と、影響を受ける業務を見極めます。
  3. Adapt：プロンプトや出力の受け取り方を、新しいモデルに合わせて直します。
  4. Validate：決めておいたテスト用データで、旧モデルと新モデルの結果を比べます。
  5. Roll out：新しいデプロイへ利用を移します。
  6. Retire：古いデプロイを片付けます。

手引きが勧めるのは、テストを始める前に、代表的な入力と期待する出力、合格の基準をテスト用データとして固定しておくことです。本番の入力と出力の記録は自分で有効にする設定で、有効にする前の分はさかのぼって取れない（原文では「never retroactive」）とされています。記録を取る設定は、移行の話が出る前に有効にしておきましょう。

デプロイの作成・切り替えとデプロイ名の変更

Standard系でも、後継が別のモデルなら、自分で移すときは新しいデプロイを作るところから始まります。新しいデプロイを作ったら、社内ツールがどのデプロイ名を呼んでいるかを確かめ、新しいデプロイへ向け直すことになります。別のデプロイを並べて切り替える方法なら、問題が出たときに元のデプロイへ戻しやすくなるのが利点です。切り替えた後も提供終了日まではしばらく古いデプロイを残し、戻し方を手順書に書いておいてください。

料金の差を確かめる

後継のモデルは、100万トークンあたりの単価が前のモデルと同じとは限りません。2026年9月17日時点の公式の料金ページ（Global・米ドル表示）では、GPT-4o miniは入力0.15ドル・出力0.60ドル、GPT-5.4 miniは入力0.75ドル・出力4.50ドルと表示されていました。小型のモデル同士でも、出力が月に1,000万トークンある社内ツールなら、出力の分だけで6ドルが45ドルとなり、毎月39ドルの上乗せになります。金額は小さく見えても、利用が多い部署ほど差が広がるため、棚卸し表の部署ごとに利用量を当てはめてみてください。

※料金は2026年9月17日時点でAzureの公式料金ページに表示されていた見積もりの価格（米ドル）です。公式ページには、実際の価格はMicrosoftとの契約の種類、購入日、為替レートによって異なる場合があると書かれています。

Azure OpenAIの料金の仕組みと見積もりの立て方は、Azure OpenAIの料金の解説でまとめています。

SDK・APIのバージョンはモデルとは別に管理する

モデルのバージョンと、APIのバージョンは別のものになります。公式の説明でも、モデルそのもののバージョンと、デプロイを呼び出すAPIのバージョンの2つを考える必要があるとされています。APIのバージョンは、呼び出すときのapi-versionという値で指定します。モデルの新しいバージョンが出ても、APIのバージョンまで上げる必要があるとは限りません。APIのバージョンの更新とモデルの提供終了は別々にやって来るため、2つの予定は棚卸し表で分けて持っておきましょう。

移行チェックリスト

  • 棚卸し表のすべてのデプロイに、提供終了日と確認日が入っている日付は公式の提供終了スケジュールで確かめ、確かめた日も一緒に書きます。
  • 後継モデルが、自分の地域とデプロイの種類でいつ使えるかを確かめたGlobal Standard以外では、後継が使えるようになる時期が遅れることがあります。
  • テスト用データ（代表的な入力・期待する出力・合格の基準）を固定した旧モデルの結果を残しておくと、新モデルと比べやすくなります。
  • 出力の書式とJSONの形を、後ろにつながるシステムで読めるか確かめた人が読むチャットより、別のシステムへ渡す処理のほうが影響を受けやすくなります。
  • 待ち時間と、1か月の費用の見込みを旧モデルと比べた単価が変わる場合は、部署ごとの利用量で月の金額に直して比べます。
  • 新しいデプロイの割り当て（クォータ）が足りているか確かめた利用が多い時間帯に上限へ当たらないかを、切り替えの前に見ておきます。
  • 元のデプロイへの戻し方と、戻すかどうかを決める人を決めた提供終了日までは、古いデプロイを残しておく前提で手順を組みます。
  • 社内規程やAIの利用ルールに書いたモデル名・データの扱いとずれていないか確かめた処理する地域やモデル名をルールに書いている場合は、文面も直します。
  • 利用部署へ知らせを出し、問い合わせの窓口を伝えた次の節のひな形を使えます。
  • 古いデプロイを片付け、棚卸し表を更新した使わなくなったデプロイが残っていると、次の棚卸しで迷う原因になります。

社内ルールにモデル名や処理する地域を書いている会社は、移行に合わせてルールの文面も直す必要があります。ルールの作り方は生成AIの社内ガイドラインの作り方で紹介しています。

利用部署へ出す社内通知文のひな形

利用部署への知らせは、いつ、何が変わり、部署で何をしてほしいかの3点に絞ると読まれやすくなります。次のひな形の【】の部分を、棚卸し表から埋めて使ってみてください。

件名：【社内ツール名】で使っているAIモデルの切り替えのお知らせ（【切り替え日】）

【部署名】のみなさま

【社内ツール名】で使っているAIのモデルが、提供元の予定により【提供終了日】で提供を終えます。
これに合わせて、【切り替え日】に新しいモデル（【後継モデル名】）へ切り替えます。

■いつ
　【切り替え日】【時間帯】（作業中も利用できる予定です／【停止する時間】は利用できません）

■何が変わるか
　・回答の言い回しや長さが、これまでと変わることがあります
　・【出力の形式が変わる場合はここに記入】

■お願いしたいこと
　・【確認期間】の間、いつもの使い方で試し、気になる回答があれば下記へお送りください
　・業務で使っているプロンプトのひな形がある場合は、【期限】までに共有してください

■問い合わせ先
　【担当部署・共有アドレス】

（日付の確認日：【公式の表で日付を確かめた日】）

経営者向けには、影響するツールの数、切り替え日、費用の増減の見込み、止まった場合の業務への影響の4つを1枚にまとめて報告するとよいでしょう。切り替えの後に回答の質が落ちたという声が出たとき、どの窓口へ送ればよいかが決まっていれば、現場の混乱を小さく抑えることが出来ます。

自社で運用し続けるか、既製の法人向けサービスを使うか

Azure OpenAIを自社で組んで使う限り、ここまでの棚卸し、テスト、切り替え、社内への知らせは、モデルが入れ替わるたびに自社で回すことになります。GAモデルの提供期間は18か月のため、使うモデルが1つでも、遅くとも1年半ごとに同じ作業が巡ってきます。複数のモデルを使い分けていれば時期がずれて、年に何度も対応が来ることもあるでしょう。

社内ツールの中身が、プロンプトを送って回答を表示するだけのチャットであれば、自社で作って運用し続ける理由は薄くなっていきます。その場合は、既製の法人向けサービスを使う形と並べて考えてみてください。選ぶときは、どのAIのどのモデルが使えるのか、管理者が使わせるモデルを切り替えられるのか、データがどこで管理されるのかを確かめておきましょう。

反対に、社内のシステムと深くつながった処理や、追加学習したモデルを使う業務は、自社で運用を続ける意味が残ります。どちらを選ぶ場合も、使っているモデルと部署を棚卸し表で把握することが出発点になります。費用の見通しの立て方は生成AIのコスト管理、複数のAIを1つの環境でまとめて使う考え方はマルチAIとはで詳しくまとめています。

4つのAIを、1つの契約と1つの管理画面で

UPGEAR AIは、ChatGPT・Claude・Gemini・Perplexityを1つの契約で、1つの画面から使える法人向けサービスです。会話の途中でもモデルを切り替えられ、管理者ダッシュボードで利用ログや権限、モデルごとのON/OFFを管理できます。基盤は国内サーバー（AWSの日本リージョン）で稼働しています。料金は月額30,000円（税抜）から。どのプランも利用人数は無制限で、料金は利用量に応じたプラン設計です（人数の目安はライト1〜5名・スタンダード6〜20名・プレミアム21〜50名）。初期費用100,000円（税抜）が別途かかります。

UPGEAR AIの詳細を見る

よくある質問

日本語版の公式ページで「廃止」と書かれたモデルは、もう使えませんか？
まだ使えます。日本語版の公式ページでは、英語のDeprecatedが「廃止」、Retiredが「引退」や「退役」と訳されています。「廃止」の段階では、すでにそのサブスクリプションで使っている顧客はデプロイの作成や管理を続けられます。呼び出しに410エラーが返って止まるのは、「引退」の提供終了日を過ぎてからです。
提供終了日を延ばしてもらうことは出来ますか？
出来ません。公式のよくある質問で、提供終了日は延長できないと明記されています。移行の手引きにも例外の手続きはないと書かれているため、公式の表に載っている日付までに移す前提で予定を組んでください。
Standardのデプロイで使っていれば、何もしなくても大丈夫ですか？
止まることは避けられても、何もしなくてよいわけではありません。Global Standard・Data Zone Standard・Standardは、後継モデルが示されていれば提供終了日に自動でアップグレードされますが、NoAutoUpgradeを設定したデプロイは止まります。また、自動で切り替わったモデルは口調や書式、JSONの形、費用が変わることがあるため、業務で使う入力で事前に結果を確かめておくことをおすすめします。
提供終了の通知メールが届いていません。対象ではないということですか？
そうとは限りません。通知メールは、アクティブなデプロイがあるサブスクリプションの所有者に送られます。名義が委託先だったり、所有者が退職していたりすると、社内の誰も受け取っていないことがあります。公式の提供終了スケジュールで日付を確かめ、Service Healthのアラートに共有のアドレスを登録しておくと安心です。
新しいサブスクリプションを作れば、廃止の段階のモデルを使い続けられますか？
使えません。Deprecatedの段階で使い続けられる既存の顧客かどうかは、サブスクリプション単位で判断されます。同じテナントの中で新しく作ったサブスクリプションには権利が引き継がれないため、新しいサブスクリプションではそのモデルをデプロイできません。
モデルを移すときは、APIのバージョンも一緒に上げる必要がありますか？
必ずしも必要ではありません。モデルのバージョンと、呼び出しに使うAPIのバージョン（api-version）は別のものです。モデルの新しいバージョンが出ても、APIのバージョンを上げなくてよい場合があります。2つの予定は分けて管理してください。

まとめ

Azure OpenAIのモデルは、Preview・GA・Legacy・Deprecated・Retiredの5つの段階を進み、止まるのはRetiredの提供終了日になります。日本語版の公式ページではDeprecatedが「廃止」、Retiredが「引退」「退役」と訳されているため、「廃止」の段階はまだ動くと読み替えてください。GAモデルは提供開始から12か月で新しい顧客が使えなくなり、18か月で提供を終えます。

通知はGAモデルで少なくとも60日前に、サブスクリプションの所有者へのメールとService Healthに届きます。所有者の退職や委託先の名義で知らせが埋もれないよう、Service Healthのアラートに共有のアドレスを登録しておきましょう。Standard系は自動で切り替わる一方で、Provisionedは自分で移す必要があり、versionUpgradeOptionの設定しだいで、止まるか、知らないうちに中身が替わるかが決まります。

日付は変わることがあるため、2026年10月6日時点の掲載を目安にしつつ、作業の前に公式の表で確かめることが出来るよう、棚卸し表に確認日を残しておきましょう。法人のAI活用に関する他の記事はAI活用コラム一覧をご覧ください。