Azure AIのAPI用語マッピング更新で確認すべき点｜Deprecated誤判定を防ぐ

Azure AIの公式ドキュメント更新「Add API terminology mapping to lifecycle policy doc」で最初に確認すべき点は、ドキュメントやAzure AI Foundryポータルで表示されるライフサイクル名と、Models APIのlifecycleStatusの値が同じ意味ではないという点です。

結論から言うと、APIのDeprecatingは「非推奨だが既存顧客はまだ利用可能」、APIのDeprecatedは「すでに廃止済みで推論が使えない状態」を指します。ここを取り違えると、監視アラート、移行判断、ダッシュボード表示、CI/CDのデプロイ制御で誤判定が起きます。

2026年4月30日のMicrosoftDocs/azure-ai-docsのコミットでは、ライフサイクルポリシー文書にAPI用語の対応表と、プログラムでモデル状態を判定するロジックが追加されました。更新対象はconcepts-model-retirements-content.mdで、Models APIの主要フィールドとしてlifecycleStatus、deprecation.inference、deprecation.fineTune、SKUごとのdeprecationDateが整理されています。(GitHub)

Azure AIの公式ドキュメント更新「Add API terminology mapping to lifecycle policy doc」で何が変わったか

今回の更新は、新しいモデルや新しいAPIエンドポイントの追加ではなく、既存のライフサイクルポリシーを運用で誤解しないための説明強化と見るのが適切です。

変更点は主に次の3つです。

変更点	実務での意味
APIとドキュメント/ポータルの用語対応表を追加	Deprecatedという単語を見ただけで状態を判断しない
DeprecatingとDeprecatedの違いを明記	移行準備中なのか、すでに使えないのかを分けて扱える
プログラムでの状態判定ロジックを追加	監視、棚卸し、CI/CD、移行計画に組み込める

特に重要なのは、公式ドキュメント側の「Deprecated」とAPI側のDeprecatedが一致しない点です。公式ドキュメントでは、モデルのライフサイクルはPreview、Generally Available、Legacy、Deprecated、Retiredといった段階で説明されていますが、今回追加されたAPI対応表では、ドキュメント/ポータル上のDeprecatedはAPIではDeprecatingに対応します。(Microsoft Learn)

つまり、運用担当者が「APIでDeprecatedと返ってきたから、まだ非推奨期間中だ」と判断すると危険です。APIのDeprecatedは、ドキュメント/ポータル上ではRetired、つまり廃止済みの状態です。

最大の確認点は「Deprecated」の意味の違い

Azure AIやAzure OpenAIを業務システムに組み込んでいる場合、モデルの廃止対応は単なる情報確認ではありません。推論APIの停止、精度検証のやり直し、利用リージョンの変更、コスト見直し、社内承認などに直結します。

今回の更新で確認すべき用語対応は、次の表に集約できます。

ドキュメント/ポータル上の段階	Models APIのlifecycleStatus	deprecation.inferenceの目安	実務上の扱い
Preview	Preview	将来日または未設定	本番利用は慎重に判断する。変更や削除の可能性を前提にする
Generally Available	GenerallyAvailable	将来日	本番利用の候補。ただし廃止日やリージョン差分は確認する
Deprecated	Deprecating	将来日	既存顧客は推論可能。新規利用や新規顧客の利用可否に注意し、移行を開始する
Retired	Deprecated	過去日	廃止済み。推論は410 Goneになる前提で緊急対応する

公式ドキュメントでは、ドキュメント上でDeprecatedと表示されるモデルはAPIではlifecycleStatus: "Deprecating"として表れ、API値の"Deprecated"はモデルがRetiredで推論を提供しない状態を意味すると説明されています。(Microsoft Learn)

この違いは、特に次のようなコードや運用ルールで問題になります。

// 危険な例
if (model.lifecycleStatus === "Deprecated") {
  console.log("非推奨なので移行準備を開始");
}

この書き方だと、API上のDeprecatedを「まだ使える非推奨期間」と誤解しています。実際には、廃止済みとして扱うべきです。

Models APIで確認すべきフィールド

Azure AIのモデル状態をプログラムで確認する場合、Models APIを使います。REST APIリファレンスでは、次の形式でリージョン内のモデル一覧を取得する操作が示されています。(Microsoft Learn)

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

確認すべきフィールドは、単にlifecycleStatusだけではありません。

フィールド	確認する内容	見落とすと起きる問題
lifecycleStatus	モデルのAPI上のライフサイクル状態	DeprecatingとDeprecatedの誤読で移行判断を誤る
deprecation.inference	推論用途の非推奨・廃止に関する日付	推論停止の期限を見落とす
deprecation.fineTune	ファインチューニング用途の期限	学習は不可だが既存デプロイは使える、などの違いを見落とす
SKUごとのdeprecationDate	SKU単位の廃止日	Standard、Provisionedなどの差分を無視してしまう
skus	利用可能なSKUやSKUごとの情報	移行先で同じ運用形態を維持できない可能性を見落とす

APIリファレンス上でも、lifecycleStatusはStable、Preview、GenerallyAvailable、Deprecating、Deprecatedなどの値を取り得る列挙型として定義されています。今回のライフサイクル文書の対応表だけでなく、API定義側の値も踏まえて、未知の値や想定外の値を安全側に倒す実装にしておくべきです。(Microsoft Learn)

運用影響：誰が何を確認すべきか

この更新は、開発者だけでなく、クラウド管理者、ソリューションアーキテクト、技術意思決定者にも影響します。特にAzure AIを本番ワークロードで利用している組織では、ドキュメント更新を「読むだけ」で終わらせず、既存の運用フローに反映する必要があります。

役割	確認すべきこと	具体的な対応
開発者	モデル状態判定ロジック	Deprecatedを非推奨扱いしていないかコードを確認する
クラウド管理者	利用中モデルとリージョン	サブスクリプション、リージョン、SKUごとにModels APIで棚卸しする
SRE/運用担当	監視とアラート	Deprecating、過去日のdeprecation.inference、410 Goneを検知対象にする
ソリューションアーキテクト	移行先モデルと検証計画	代替モデル、性能、コスト、リージョン制約を整理する
技術意思決定者	移行期限と業務影響	廃止日までの検証・承認・リリース計画を確保する

標準デプロイ種別ではモデル廃止時にMicrosoft側で自動アップグレードが管理されるケースがありますが、Provisionedデプロイは自動アップグレードされず、利用者側で手動移行が必要とされています。したがって、デプロイ種別を確認せずに「Azure側で自動移行されるはず」と考えるのは危険です。(Microsoft Learn)

実装ではlifecycleStatusと日付を組み合わせて判定する

実務では、lifecycleStatusだけを見て状態を決めるのではなく、deprecation.inferenceの日付も組み合わせて判定します。公式ドキュメントでも、モデルの段階をプログラムで判断するには両方のフィールドを確認する考え方が示されています。(Microsoft Learn)

以下は、運用ダッシュボードや移行チェック用スクリプトに組み込むための簡易例です。

type ModelStage =
  | "Preview"
  | "GA"
  | "Deprecated"
  | "Retired"
  | "Unknown";

function resolveModelStage(model: {
  lifecycleStatus?: string;
  deprecation?: {
    inference?: string;
  };
}): ModelStage {
  const status = model.lifecycleStatus;
  const inferenceDate = model.deprecation?.inference
    ? new Date(model.deprecation.inference)
    : null;

  const now = new Date();

  if (status === "Deprecated") {
    return "Retired";
  }

  if (inferenceDate && inferenceDate < now) {
    return "Retired";
  }

  if (status === "Deprecating") {
    return "Deprecated";
  }

  if (status === "GenerallyAvailable") {
    return "GA";
  }

  if (status === "Preview") {
    return "Preview";
  }

  return "Unknown";
}

この実装で大切なのは、Deprecatedを「移行準備中」ではなく「廃止済み」として扱うことです。また、deprecation.inferenceが過去日になっている場合は、lifecycleStatusの反映遅れや表示差分に備えてRetiredとして扱うほうが安全です。

既存コードで見直すべき条件分岐

すでにAzure AIのモデル情報をAPIで取得している場合、次のような条件分岐を探してください。

if (model.lifecycleStatus === "Deprecated") {
  // deprecatedとして扱う
}

このような実装は、今回の用語対応に照らすと誤判定の可能性があります。望ましいのは、次のように状態を正規化してから業務ロジックに渡す構成です。

const stage = resolveModelStage(model);

switch (stage) {
  case "Retired":
    // 新規デプロイ不可。推論停止を前提に緊急対応
    break;

  case "Deprecated":
    // 既存利用は可能でも移行を開始
    break;

  case "GA":
    // 本番利用可。ただし廃止日と代替モデルは継続確認
    break;

  case "Preview":
    // 本番利用はリスク評価が必要
    break;

  default:
    // 未知の値は安全側に倒す
    break;
}

監視やCI/CDでは、stageを内部共通ラベルとして使うと管理しやすくなります。たとえば、ダッシュボードでは「API raw value」と「運用上の解釈」を並べて表示すると、開発者と運用担当の認識ずれを防げます。

API raw value: Deprecating
Operational stage: Deprecated
Action: 代替モデルの検証を開始

移行準備ではModel Retirement Scheduleも合わせて見る

Models APIはプログラムで状態を確認するのに向いていますが、移行計画ではModel Retirement Scheduleも確認する必要があります。公式のスケジュールページでは、Foundry Modelsの現在のライフサイクル、廃止日、推奨される代替モデルが一覧化されています。(Microsoft Learn)

確認手順は次の流れが実務的です。

手順	作業内容	成果物
利用中モデルを棚卸しする	サブスクリプション、リージョン、モデル名、バージョン、SKUを一覧化	モデル利用台帳
Models APIで状態を取得する	lifecycleStatusとdeprecation関連フィールドを取得	APIベースの現状一覧
Retirement Scheduleと突き合わせる	廃止日、代替モデル、現行ステージを確認	移行対象リスト
代替モデルを検証する	精度、レイテンシ、コスト、レート制限、リージョンを比較	検証結果レポート
移行方式を決める	自動アップグレード、手動移行、並行稼働を選ぶ	移行計画
アラートを設定する	廃止日接近、Deprecating検知、410 Goneを監視	運用監視ルール

ここで重要なのは、モデル名だけで判断しないことです。同じモデルファミリーでも、バージョン、リージョン、SKU、デプロイ種別によって運用上の扱いが変わる可能性があります。

よくある誤解と失敗しやすいポイント

APIのDeprecatedを「まだ使える」と誤解する

最も危険な誤解です。今回の更新では、APIのDeprecatedはRetired、つまり廃止済みを意味すると明確化されています。移行猶予がある状態は、APIではDeprecatingです。(Microsoft Learn)

ポータル表示とAPI値をそのまま同一視する

Azure AI Foundryポータルやドキュメント上の表示は、利用者向けのライフサイクル名です。一方、Models APIのlifecycleStatusはAPI上の値です。画面表示とAPI値をそのまま文字列比較すると、運用判断を誤る可能性があります。

lifecycleStatusだけで判定する

deprecation.inferenceが過去日であれば、lifecycleStatusに遅れや差分があっても廃止済みとして扱うべきケースがあります。特にバッチ処理や夜間監視では、日付比較を入れておくと安全です。

deprecation.fineTuneとdeprecation.inferenceを混同する

ファインチューニングの期限と推論の期限は同じとは限りません。学習はできないが既存の推論は継続できる、または推論停止に向けて別途対応が必要、というケースを切り分ける必要があります。

Provisionedデプロイの移行を後回しにする

Provisionedデプロイは自動アップグレードされないため、移行先の容量、PTU、テスト期間、切り替え方式を早めに決める必要があります。標準デプロイの自動アップグレード前提で計画すると、本番環境の切り替えが間に合わない可能性があります。(Microsoft Learn)

Legacyの扱いをAPIだけで決めようとする

ライフサイクル説明にはLegacyが含まれますが、今回追加されたAPI用語対応表ではPreview、Generally Available、Deprecated、Retiredが中心です。Legacyを厳密に扱う必要がある場合は、Models APIだけで完結させず、Model Retirement Scheduleや公式ドキュメント側の表示と突き合わせる運用にしておくのが安全です。(Microsoft Learn)

すぐに実施したいチェックリスト

Azure AIを本番で利用している場合は、今回の更新を受けて次の確認を行ってください。

チェック項目	判断基準
lifecycleStatus === "Deprecated"を移行準備扱いしていないか	該当する場合はRetired扱いに修正する
Deprecatingを検知できているか	移行準備のトリガーとして扱う
deprecation.inferenceを日付比較しているか	過去日ならRetiredとして扱う
リージョン別にModels APIを確認しているか	単一リージョンの結果だけで判断しない
SKUごとのdeprecationDateを見ているか	StandardとProvisionedなどの違いを見落とさない
Model Retirement Scheduleを確認しているか	代替モデルと廃止日を移行計画に反映する
Service Healthやメール通知だけに依存していないか	APIベースの定期チェックも併用する
移行先モデルの評価項目を定義しているか	精度、レイテンシ、コスト、リージョン、クォータを比較する

まず着手すべきなのは、コード検索です。リポジトリ内でlifecycleStatus、Deprecated、Deprecating、deprecation.inferenceを検索し、誤った条件分岐がないか確認してください。次に、利用中のサブスクリプションとリージョンを対象にModels APIを実行し、移行対象モデルを一覧化します。

まとめ：今回の更新は「用語の確認」ではなく「誤判定防止」のために読む

Azure AIの公式ドキュメント更新「Add API terminology mapping to lifecycle policy doc」は、一見すると小さなドキュメント修正に見えます。しかし、本番運用では重要度の高い更新です。

確認すべき要点は明確です。ドキュメント/ポータル上のDeprecatedは、APIではDeprecatingです。APIのDeprecatedはRetired、つまり廃止済みとして扱います。そして、状態判定ではlifecycleStatusだけでなく、deprecation.inferenceの日付も組み合わせます。

開発者は判定ロジックを修正し、クラウド管理者は利用中モデルを棚卸しし、アーキテクトは代替モデルの検証計画を立てるべきです。今回の更新をきっかけに、Azure AIのモデルライフサイクル監視をAPIベースで定期実行できる状態にしておくと、今後のモデル廃止や移行にも落ち着いて対応できます。