MENU

Azure公式ドキュメント更新「seo, update outdated preview mentions」で確認すべき点

Azure

Azureの公式ドキュメント更新「seo, update outdated preview mentions」は、Azure全体の大規模な仕様変更というより、Durable Task SchedulerとDurable Functions周辺の古いプレビュー表記・APIバージョン・設定例を見直した更新です。実務で最初に確認すべきことは、2025-04-01-preview、Microsoft.Azure.Functions.ExtensionBundle.Preview、[4.29.0, 5.0.0) などの古い指定が、IaC、CI/CD、host.json、社内手順書に残っていないかです。

この更新は、MicrosoftDocs/azure-docs のコミット 4479982 として記録されており、コミット件名は「seo, update outdated preview mentions」、変更対象は5ファイル、差分は13行追加・11行削除です。コミット日時は2026年4月30日で、主に Durable Task Scheduler の REST API 参照、autopurge retention policies、Durable Functions の Extension Bundle 設定例が修正されています。(GitHub)

目次

Azureの公式ドキュメント更新「seo, update outdated preview mentions」で何が変わったか

今回のAzure公式ドキュメント更新で重要なのは、「preview」という言葉が減ったこと自体ではありません。実務上は、サンプルコードや設定例が、古いプレビュー前提から新しいAPIバージョン・通常のExtension Bundle参照へ寄せられた点を見るべきです。

確認箇所主な変更実務上の意味
Durable Task Scheduler の retention policies2025-04-01-preview から 2026-02-01 へ更新ARM API、Bicep、REST API呼び出しで古いプレビューAPIを参照していないか確認する
Durable Functions の host.json 例Microsoft.Azure.Functions.ExtensionBundle.Preview から Microsoft.Azure.Functions.ExtensionBundle へ変更JavaScript、Python、Java、PowerShellなど非.NET環境のFunction App設定を確認する
Extension Bundle のバージョン例[4.29.0, 5.0.0) から [4.32.0, 5.0.0) へ変更Durable Task Scheduler対応を期待するFunction Appで、拡張機能の読み込み条件を確認する
Durable Task Scheduler の目次REST API へのリンクが追加REST APIリファレンスを参照しやすくなった。社内ドキュメントのリンク先も見直す
Durable Functions の診断・パッケージ関連ページ手動アップグレード手順へのアンカーリンクを修正仕様変更というより、壊れた・古い参照の修正に近い

公式コミットでは、Durable Task Scheduler の REST APIリンク追加、retention policies のAPIバージョン変更、Bicepリソース定義の更新、host.json の Extension Bundle 例の変更が確認できます。(GitHub)

最優先で確認すべきポイント

2025-04-01-preview を使ったREST API・Bicepが残っていないか

今回の更新で最も運用影響が出やすいのは、Durable Task Scheduler の retention policies です。公式ドキュメントでは、retention policy の作成・更新APIが api-version=2026-02-01 の例に更新されています。REST APIリファレンス上でも、Retention Policies – Create Or Replace は API バージョン 2026-02-01 として掲載されています。(Microsoft Learn)

古い例を参照している場合は、次のような指定が残っていないか確認してください。

api-version=2025-04-01-preview

Bicepでは、次のような古いAPIバージョン指定が確認対象です。

resource retentionPolicy 'Microsoft.DurableTask/schedulers/retentionPolicies@2025-04-01-preview' = {
  name: 'default'
}

更新後の公式例では、次のように 2026-02-01 が使われています。

resource retentionPolicy 'Microsoft.DurableTask/schedulers/retentionPolicies@2026-02-01' = {
  parent: parentResource
  name: 'default'
  properties: {
    retentionPolicies: [
      {
        retentionPeriodInDays: 1
      }
    ]
  }
}

ただし、本番環境で単純に一括置換するのは避けるべきです。APIバージョンを変えると、要求本文、応答、バリデーション、エラーコードの扱いが変わる可能性があります。まず開発環境またはステージング環境で、Bicepの what-if、ARMテンプレートの検証、REST APIのレスポンス確認を行ってください。

Microsoft.Azure.Functions.ExtensionBundle.Preview を使っていないか

非.NETの Durable Functions アプリでは、host.json の extensionBundle が重要です。今回の更新では、Durable Task Scheduler を使うクイックスタートの例が、Preview Bundleではなく通常のExtension Bundleを使う形に変わっています。公式ドキュメントでは、Durable Task Scheduler対応には Microsoft.Azure.Functions.ExtensionBundle のバージョン 4.32.0 以降を使う例が示されています。(Microsoft Learn)

古い設定例は次のような形です。

{
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Preview",
    "version": "[4.29.0, 5.0.0)"
  }
}

確認後に検討すべき新しい例は次の形です。

{
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.32.0, 5.0.0)"
  }
}

ここで注意したいのは、host.json の変更だけで動作保証が完了するわけではないことです。Function Appのランタイム、使用言語、Durable Functions SDK、デプロイ方式、ローカル開発環境のAzure Functions Core Toolsなども合わせて確認する必要があります。

社内手順書の古いアンカーリンクを修正する

今回のコミットには、Durable Functions の診断ページやパッケージ概要ページで、手動アップグレード手順へのアンカーリンクを修正する変更も含まれています。これはアプリケーションの動作を直接変える変更ではありませんが、社内Wiki、設計書、障害対応Runbookに古いリンクを貼っている場合、調査時に目的の箇所へたどり着けない原因になります。(Microsoft Learn)

特に、障害対応手順に「Durable Functions extensionを手動アップグレードする」といったリンクがある場合は、リンク先が現在のMicrosoft Learnと一致しているか確認してください。

運用影響は「すぐ壊れる」より「古い前提で運用し続ける」リスクが大きい

この更新だけで、既存のAzureリソースが自動的に変更されるわけではありません。重要なのは、開発チームや運用チームが古いドキュメント例をコピーしたまま使い続けることです。

対象放置した場合のリスク確認方法
Bicep / ARMテンプレート古いプレビューAPIバージョンに固定される2025-04-01-preview を検索する
REST API呼び出しサンプルと現行リファレンスがずれ、将来の保守が難しくなるCI/CDスクリプト、運用スクリプトを確認する
host.jsonPreview Extension Bundleに依存したままになるMicrosoft.Azure.Functions.ExtensionBundle.Preview を検索する
社内ドキュメント障害対応時に古いリンクや古い手順へ誘導されるRunbook、Wiki、設計書を確認する
autopurge設定オーケストレーション履歴を想定より早く削除するretention policyの値と対象ステータスを確認する

最初の作業として、リポジトリ全体で次のように検索すると効率的です。

rg "2025-04-01-preview|ExtensionBundle\.Preview|4\.29\.0|manually-upgrade-the-durable-functions-extension" .

PowerShell環境なら、次のように確認できます。

Get-ChildItem -Recurse -File |
  Select-String "2025-04-01-preview|ExtensionBundle\.Preview|4\.29\.0|manually-upgrade-the-durable-functions-extension"

Durable Task Schedulerのautopurgeは設定値を見直す価値がある

「seo, update outdated preview mentions」というコミット名だけを見ると軽微な更新に見えますが、autopurge retention policies は運用上かなり重要です。Durable Task Scheduler の autopurge は、完了したオーケストレーション履歴データを定期的に削除するための機能です。公式ドキュメントでは、Completed、Failed、Canceled、Terminated などの終端ステータスが削除対象として説明されています。(Microsoft Learn)

一方で、Pending、Running、Suspended、Continued_As_New のような非終端ステータスは対象外として扱われます。ContinueAsNew を使うワークフローでは、見かけ上の状態だけで削除対象を判断しないよう注意が必要です。(Microsoft Learn)

たとえば、次のような考え方で保持期間を分けると、運用と調査のバランスを取りやすくなります。

オーケストレーション状態設定例判断基準
Completed1〜7日正常終了の履歴を長く残す必要が低い場合
Failed14〜60日障害分析や再発防止に使う場合
Terminated14〜60日手動停止の理由を後から確認したい場合
Canceled7〜30日キャンセルが業務上の証跡になる場合
デフォルト7〜30日個別指定がない状態に適用する基本値

公式例では、CLI、Azure Resource Manager、Bicepでretention policiesを設定できることが示されています。また、CLIを使う場合は az extension add --name durabletask や az extension update --name durabletask によってDurable Task CLI拡張を準備する流れが掲載されています。(Microsoft Learn)

運用環境では、次のような極端な設定に注意してください。

{
  "retentionPeriodInDays": 0,
  "orchestrationState": "Completed"
}

0 は「できるだけ早く削除する」意図で使われるため、正常終了の履歴をほとんど残さない運用になります。コストや容量を抑えるには有効ですが、問い合わせ対応、監査、障害調査で履歴が必要な環境では不向きです。

開発者が確認すべきこと

開発者は、まずアプリケーションの設定とパッケージを確認してください。特に Durable Functions と Durable Task Scheduler を組み合わせている場合、host.json、SDK、Extension Bundle、ローカル開発環境の整合性が重要です。

確認すべき項目は次のとおりです。

確認項目見る場所判断基準
Extension Bundlehost.jsonPreview Bundleではなく、通常のExtension Bundleを使う方針か
Bundleバージョンhost.jsonDurable Task Scheduler対応に必要な範囲か
Durable Functions SDKpackage.json、requirements.txt、.csprojなど言語ごとの公式案内と合っているか
分散トレーシングhost.json、Application Insights期待したトレースが出るか
ローカル検証emulator、Azurite、Functions Core Tools本番前にオーケストレーションを再現できるか

Durable Functions の分散トレーシングについては、.NET Isolatedでは Microsoft.Azure.Functions.Worker.Extensions.DurableTask のバージョン条件、非.NETアプリでは Microsoft.Azure.WebJobs.Extensions.DurableTask の手動インストール条件が公式ページに記載されています。今回の変更は主にリンク修正ですが、トレースが出ない場合はパッケージとExtension Bundleの両方を確認してください。(Microsoft Learn)

クラウド管理者が確認すべきこと

クラウド管理者は、個別アプリのコードだけでなく、IaC、デプロイパイプライン、Azure Policy、運用スクリプトまで見る必要があります。特に、REST APIを直接呼び出しているスクリプトは見落とされやすいポイントです。

確認順序は次の流れが現実的です。

手順作業成果物
1リポジトリ全体で古い文字列を検索する影響ファイル一覧
2Bicep、ARM、Terraform、スクリプトを分類する修正対象の優先順位
3開発環境で 2026-02-01 に変更して検証するデプロイ差分とエラー有無
4retention policyの値を棚卸しする削除対象と保持期間の一覧
5ステージングで既存オーケストレーションを使って検証する削除・保持の挙動確認
6本番反映手順とロールバック手順を用意する変更計画

APIバージョンの更新は、単なる文字列修正ではありません。変更後に「作成できるか」だけでなく、「既存リソースを更新したときに差分が意図どおりか」「DELETE時の挙動が監査要件と合っているか」まで確認してください。

ソリューションアーキテクトと技術判断者が確認すべきこと

ソリューションアーキテクトや技術判断者にとって、この更新は「Durable Task Schedulerを本格採用してよいか」を見直す材料になります。ただし、ドキュメントから古いpreview表記が減ったことだけで、すべての要件が満たされたと判断するのは危険です。

判断時は、次の観点で確認してください。

観点確認内容
サービスの適用範囲対象リージョン、料金、スケール要件、対応プラン
運用要件履歴保持、監査、障害調査、バックアップ方針
開発体験ローカルemulator、CI/CD、SDK対応、言語ごとの制約
セキュリティマネージドID、RBAC、ネットワーク制御、権限分離
既存資産との整合Azure Storage ProviderやMSSQL Providerからの移行可否
サポート判断本番利用可否、SLA、組織内の承認プロセス

公式クイックスタートでは、Durable Task Schedulerを Durable Functions のバックエンドとして使い、オーケストレーションやエンティティのランタイム状態を保存できることが説明されています。Azure上でFunction AppとDurable Task Schedulerを作成する流れや、タスクハブ単位のRBAC割り当ても案内されています。(Microsoft Learn)

移行準備で失敗しやすいポイント

「preview表記が消えた＝すべて本番利用OK」と判断する

今回の更新は、古いプレビュー表記を整理する意味合いが強いものです。サービスの提供状態、料金、リージョン、SLA、サポート範囲は、必ず最新の公式ページとAzure Portalで確認してください。

APIバージョンだけを一括置換する

2025-04-01-preview を 2026-02-01 に置き換えるだけでは不十分です。要求本文、レスポンス、エラー処理、SDK生成コード、Bicepの型チェックまで確認してください。

autopurgeの保持期間を短くしすぎる

履歴削除はコストや容量の管理に役立ちますが、障害調査や監査の証跡を失うリスクがあります。特に Failed、Terminated、Canceled の保持期間は、開発者だけで決めず、運用・セキュリティ・業務担当者と合意しておくべきです。

Preview Extension Bundleの削除だけで検証を終える

host.json を更新しても、Function Appが期待どおり起動し、Durable Task Schedulerに接続し、オーケストレーションが完了し、Application Insightsやダッシュボードで追跡できるところまで確認しなければ、本番反映の判断材料としては不足です。

社内ドキュメントの更新を後回しにする

今回のような公式ドキュメント更新では、運用手順書のリンクやスクリーンショットが古くなりがちです。障害対応時に古いpreview手順へ誘導されると、復旧時間が長くなります。コード修正と同じタイミングでRunbookも更新してください。

実務で使える確認チェックリスト

本番環境に関係するリポジトリや手順書で、次の項目を確認してください。

チェック確認内容
APIバージョン2025-04-01-preview が残っていないか
BicepMicrosoft.DurableTask/schedulers/retentionPolicies@2025-04-01-preview が残っていないか
REST APIretention policies の作成・更新・削除で 2026-02-01 を検証したか
host.jsonMicrosoft.Azure.Functions.ExtensionBundle.Preview を使っていないか
Extension Bundle[4.32.0, 5.0.0) のようにDurable Task Scheduler対応範囲を使っているか
CLIaz extension update --name durabletask を実行できる運用になっているか
autopurgeCompleted、Failed、Canceled、Terminated の保持期間が業務要件と合っているか
監視Application Insights、Durable Task Scheduler dashboardで状態を確認できるか
社内文書古いアンカーリンク、古いスクリーンショット、preview前提の説明が残っていないか
ロールバック変更後に問題が出た場合の戻し方を決めているか

まず取るべき次の行動

最初にやるべきことは、既存環境への影響範囲の特定です。リポジトリ、IaC、CI/CD、社内Runbookを対象に、2025-04-01-preview、ExtensionBundle.Preview、[4.29.0, 5.0.0) を検索してください。

次に、Durable Task Schedulerの retention policies を使っている場合は、2026-02-01 のREST APIまたはBicepで開発環境に反映し、作成・更新・削除の動作を確認します。最後に、非.NETのDurable Functionsアプリでは host.json のExtension Bundle設定を見直し、ローカル、ステージング、本番の順にオーケストレーション実行と監視を確認します。

今回のAzure公式ドキュメント更新は小さな差分に見えますが、プレビュー前提の設定が残っている環境では、保守性と将来の移行リスクに直結します。コード、インフラ、運用手順をセットで確認することが、最も安全で実務的な対応です。

Azure
REST API Azure Microsoft Learn Durable Functions Durable Task Scheduler

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次