MENU

Azure REST API documentation update: Microsoft.Web 2026-06-01-previewの変更点と対応ポイント

Azure

Azure REST API documentation updateで今回まず押さえるべき結論は、既存のMicrosoft.Web API利用者が一律に移行する更新ではなく、App Service系リソースをREST API、IaC、独自SDK、運用自動化で管理しているチームが影響確認すべきプレビュー仕様の追加という点です。

特に確認すべき対象は、Microsoft.Web/sites、Microsoft.Web/serverfarms を直接操作しているスクリプト、api-version を固定しているREST呼び出し、OpenAPI/TypeSpecから生成したクライアント、カスタムRBAC、ポリシー、構成ドリフト検知です。2026-06-01-preview は名前の通りpreview API versionなので、本番環境へ機械的に切り替えるのではなく、検証環境でAPI応答、スキーマ、権限、リージョン対応を確認してから判断する必要があります。

目次

Azure REST API documentation updateで追加された内容

今回の更新は、Azure REST API仕様のリポジトリである Azure/azure-rest-api-specs のPR #42584として確認できます。同リポジトリはMicrosoft AzureのREST API仕様の標準的なソースであり、仕様完了後にSDKやAPIリファレンスドキュメント生成へつながる位置付けです。(GitHub)

PRでは、Microsoft.Web に対して新しいAPIバージョン 2026-06-01-preview を導入し、主に以下のリソースタイプを追加する内容になっています。PRタイトル上は、質問文にある3種類に加えて Microsoft.Web/sites/lastKnownGood/default も含まれています。2026年5月6日時点ではPRはOpenで、main へ27コミットをマージしようとしている状態です。(GitHub)

追加・変更点内容確認すべき観点
新APIバージョン2026-06-01-preview本番利用前にpreviewの扱い、対応リージョン、SDK生成状況を確認
サイト側のSiloMicrosoft.Web/sites/silosWeb App単位のSilo作成・更新・削除・一覧取得
App Service Plan側のSiloMicrosoft.Web/serverfarms/silosApp Service Plan単位のSilo管理
管理トラフィック設定Microsoft.Web/sites/managedTrafficConfig/defaultSilo間のトラフィック配分、優先度、フェイルオーバー設計
Last Known GoodMicrosoft.Web/sites/lastKnownGood/defaultロールバック先として使う正常リビジョンの確認・マーク
SDK/APIレビューSwagger、TypeSpec、Go、Java、JavaScriptのAPIレビューが作成自動生成クライアントや型定義の差分確認

Azure REST APIでは、リクエストURIにリソースパスとクエリ文字列を含め、Azure Resource ManagerプロバイダーAPIでは https://management.azure.com/ と api-version が使われます。したがって、既存コードが古い api-version を指定している限り、通常は勝手に新しいpreview APIへ切り替わるわけではありません。(Microsoft Learn)

新しいリソースタイプの意味を実務目線で整理する

今回の追加は、単にエンドポイントが増えるだけではありません。App Serviceのアプリ、App Service Plan、トラフィック制御、ロールバック対象をREST APIでより細かく扱うための仕様追加と見た方が分かりやすいです。

Microsoft.Web/sites/silos

Microsoft.Web/sites/silos は、Web Appに紐づくSiloを表すリソースです。TypeSpec上では親リソースが Site で、silos/{siloName} というセグメントを持ちます。操作としては、特定Siloの取得、作成または更新、タグ更新、削除、一覧取得が定義されています。(GitHub)

REST APIのパスは、概念的には次の形式になります。

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/silos/{siloName}?api-version=2026-06-01-preview

サイトSiloのプロパティには、siloLocation、primarySiteName、必須の primaryLocation、endpointStatus、trafficMode、networkingOverride、appSettingsOverrides、followLkg などが含まれます。また、provisioningState、revisionId、defaultHostName、globalHostName、monitorStatus、作成・更新時刻は読み取り用の性質を持ちます。(GitHub)

注意したいのは、trafficMode が「初回Silo作成時の入力専用で、GETでは返らない」と説明されている点です。構成管理ツールで「PUTした値がGETで返る」前提の差分検知をしていると、不要な再適用やドリフト誤検知が起きる可能性があります。

Microsoft.Web/serverfarms/silos

Microsoft.Web/serverfarms/silos は、App Service Planに紐づくSiloを表すリソースです。親リソースは AppServicePlan で、serverfarms/{name}/silos/{siloName} という構造になります。操作は取得、作成または更新、タグ更新、削除、一覧取得です。(GitHub)

REST APIのパスは、概念的には次の形式です。

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/serverfarms/{serverFarmName}/silos/{siloName}?api-version=2026-06-01-preview

プロパティには、siloLocation、primaryServerFarmName、必須の primaryLocation、instanceNumberOverride、zoneRedundantOverride、読み取り用の provisioningState、作成・更新時刻が含まれます。(GitHub)

このリソースは、アプリ単体ではなくホスティング基盤側のSiloを扱うため、影響範囲がアプリより広くなる可能性があります。検証時は、既存のスケール設定、ゾーン冗長、課金、容量制限と合わせて確認するのが安全です。

Microsoft.Web/sites/managedTrafficConfig/default

Microsoft.Web/sites/managedTrafficConfig/default は、Web App配下の管理トラフィック設定です。TypeSpec上では managedTrafficConfig の名前が default に固定され、取得、作成または更新、一覧取得が定義されています。(GitHub)

REST APIのパスは、概念的には次の形式です。

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/managedTrafficConfig/default?api-version=2026-06-01-preview

プロパティには、trafficMode と endpoints が含まれます。trafficMode は Active または Passive などのSiloフェイルオーバーモードを表し、endpoints にはリージョン、優先度、重み、重みが自動計算されたかどうかを表す項目が含まれます。priority と weight は1〜1000の範囲として定義されています。(GitHub)

検証用のリクエスト本文イメージは次のようになります。実行時は最新仕様、利用可能リージョン、対象サブスクリプションでのサポート状態を必ず確認してください。

{
  "properties": {
    "trafficMode": "Active",
    "endpoints": [
      {
        "region": "eastus",
        "weight": 80
      },
      {
        "region": "westus",
        "weight": 20
      }
    ]
  }
}

この設定は、マルチリージョン構成や段階的なトラフィック移行を自動化するチームにとって重要です。一方で、既存のAzure Front Door、Traffic Manager、Application Gatewayなどの外部ルーティング設計とどう共存するかは、実環境の構成で確認する必要があります。

Microsoft.Web/sites/lastKnownGood/default

PRタイトルには Microsoft.Web/sites/lastKnownGood/default も含まれています。これは、Web AppのLast Known Good、つまりロールバック先として使える正常リビジョンの状態を表すリソースです。取得、現在のサイト状態をLast Known Goodとしてマークする mark アクション、一覧取得が定義されています。(GitHub)

REST APIのパスは、概念的には次の形式です。

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/lastKnownGood/default?api-version=2026-06-01-preview

mark アクションは、概念的には次のような呼び出しになります。

POST /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/lastKnownGood/default/mark?api-version=2026-06-01-preview

プロパティはシンプルで、siteName と読み取り用の createdTime が定義されています。TypeSpecでは、Last Known Goodは単純な読み取り中心のデータモデルであり、通常のプロビジョニング対象リソースとは性質が異なることも示されています。(GitHub)

影響を受けやすいチームと、すぐ確認すべき場所

今回のAzure REST API documentation updateで、全ユーザーが即時対応する必要はありません。影響が大きいのは、Microsoft.Webをコードで直接管理しているチームです。

対象影響度確認ポイント
Azure REST APIを直接呼ぶ運用スクリプト高api-version、URLパス、PUT/PATCH本文、レスポンス差分
Bicep/ARMテンプレート/Terraform AzAPI利用者中〜高新resource typeを使う予定があるか、既存テンプレートへ影響がないか
SDK自動生成・内製クライアント利用者高Go、Java、JavaScriptなどの生成コード差分、型のreadOnly変更
カスタムRBAC利用者中Microsoft.Web/* を細かく許可している場合の新操作対応
Azure Policy・監査・CMDB管理者中新resource typeを許可/拒否/棚卸し対象に含めるか
App Serviceをポータル中心で運用している利用者低すぐの作業は少ないが、将来の機能公開時に確認

PRでは、APIViewがSwagger、TypeSpec、Go、Java、JavaScriptのAPIレビューを作成しているため、SDKや型定義を使うチームはREST APIのURLだけでなく、生成コードの差分も確認すべきです。(GitHub)

また、PR上では BreakingChangeReviewRequired や BreakingChange-Approved-BugFix、Approved-Suppression といったラベルや、readOnlyプロパティに関する検証コメントも確認できます。これは必ずしも既存サービスの動作破壊を意味するわけではありませんが、OpenAPI定義やSDK生成に依存している場合は、型の読み書き可否が変わる可能性を見落とさない方がよいポイントです。(GitHub)

移行ではなく「検証計画」として進める

2026-06-01-preview はpreview API versionです。AzureのPublic previewは、一般提供前に評価・フィードバックする段階であり、機能が変更される可能性や、リージョン・サブスクリプション・容量による制限があり、明示されていない限り本番ワークロード向けではないとされています。(Microsoft Learn)

そのため、対応の進め方は「既存APIからの移行」ではなく、次のような検証計画として扱うのが現実的です。

手順作業失敗しやすいポイント
1既存コードから Microsoft.Web と api-version を検索古いスクリプトやCI/CD内の az rest を見落とす
2本番ではなく検証サブスクリプションで試すpreviewを本番の標準APIとして扱ってしまう
3GET/LISTから動作確認するいきなりPUT/DELETEを実行して影響範囲を広げる
4default 固定名のリソースを確認するmanagedTrafficConfig/{任意名} のように誤った名前で呼ぶ
5PUT/PATCH本文からreadOnly項目を除外するprovisioningState や作成時刻を送って検証エラーになる
6SDK生成差分をレビューするRESTの成功だけ確認し、型定義やCIの破損を見逃す
7ロールバック手順を文書化するLast Known Goodの意味を運用手順に落とし込まない

既存リポジトリでは、まず次のように検索すると影響範囲を絞り込めます。

rg "Microsoft.Web/(sites|serverfarms)|api-version=" .

az rest を使っている場合は、URL内の api-version を確認します。

rg "az rest|management.azure.com|202[0-9]-[0-9]{2}-[0-9]{2}" .

IaCでは、BicepやARMテンプレートの type と apiVersion、Terraform AzAPIの type = "Microsoft.Web/...@..." を確認します。新しいSilo系リソースを採用するまでは、既存テンプレートのAPIバージョンを機械的に 2026-06-01-preview へ上げる必要はありません。

設定確認で特に注意したいポイント

Silo名は命名規則に注意する

sites/silos と serverfarms/silos の siloName は、英数字で始まり英数字で終わり、途中にハイフンを含められる形式として定義されています。アンダースコアや末尾ハイフンを使う命名ルールを既存システムで採用している場合、Silo名にはそのまま流用できない可能性があります。(GitHub)

default 固定の子リソースを任意名にしない

managedTrafficConfig と lastKnownGood は、リソース名が default に固定されています。複数設定を作れるリソースのように扱うと、パス設計やIaCのモジュール化で失敗します。(GitHub)

GETで返らない項目を差分検知に使わない

サイトSiloの trafficMode は初回作成時の入力専用で、GETでは返らないと説明されています。Terraform風の差分検知や独自の構成監査で「設定値が返らない＝ドリフト」と判断すると、毎回更新しようとするループが起きる可能性があります。(GitHub)

重みと優先度は範囲チェックを入れる

managedTrafficConfig のエンドポイント設定では、priority と weight が1〜1000の範囲です。外部の重み付け設定を流用する場合、0、10000、百分率のまま渡す、といったミスが起きやすいため、デプロイ前にバリデーションを入れてください。(GitHub)

カスタムロールは新操作を拒否する可能性がある

組み込みロールではなく、Microsoft.Web/sites/* や Microsoft.Web/serverfarms/* を細かく制限したカスタムロールを使っている場合、新しいSiloやmanagedTrafficConfigの操作が許可されない可能性があります。実際のアクション名は、利用可能になった時点でAzure側のProvider Operationsを確認し、最小権限の範囲で追加するのが安全です。

まず取るべきアクション

この更新を見たら、最初にやるべきことはAPIバージョンの一括変更ではありません。次の順序で確認してください。

  • 本番・検証・CI/CDにある Microsoft.Web のREST API呼び出しを棚卸しする
  • api-version がどこで固定されているかを確認する
  • OpenAPI、TypeSpec、SDK生成を使っている場合はreadOnlyや型定義の差分を確認する
  • Silo、managedTrafficConfig、Last Known Goodを使う業務要件があるかを整理する
  • preview APIは検証環境でのみ試し、リージョン、権限、レスポンス、ロールバック手順を記録する
  • PRがOpenであることを踏まえ、正式なドキュメント反映やマージ後の差分を再確認する

今回のAzure REST API documentation updateは、App Service系のマルチリージョン運用、トラフィック制御、ロールバック自動化に関わる可能性がある重要な変更です。ただし、2026-06-01-preview はpreviewであり、既存環境へ急いで適用するものではありません。まずは影響範囲を棚卸しし、検証環境でGET/LIST、権限、スキーマ差分、SDK生成を確認するところから始めるのが、最も安全で実務的な対応です。

Azure
APIバージョン App Service Azure Resource Manager Microsoft.Web Azure REST API

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次