Azure REST APIでAzure Chaos Studioを自動化している場合、今回の更新で最初に確認すべきことは「api-version=2026-05-01-previewを使うべきか」ではなく、「プレビューAPIを採用する前に、既存の実験・ターゲット管理・SDK生成・長時間操作の扱いに影響が出ないか」です。
2026年5月5日更新分として確認されるこのAzure REST API documentation updateは、Chaos Studio向けに2026-05-01-preview APIバージョンを追加する内容です。GitHub上のPRは2026年5月6日にmainへマージされており、PR説明では、以前の2026-02-01-preview仕様を移植し、Workspaces、Scenarios、ScenarioConfigurations、ScenarioRuns、DiscoveredResourcesなどの新しいリソース群を追加する更新として説明されています。(GitHub)
Azure REST APIのChaos Studio 2026-05-01-previewで何が変わったか
今回の更新は、単にAPIバージョンの数字が増えたというより、Chaos Studioを「実験単位」だけでなく「ワークスペース、シナリオ、構成、実行、検出リソース」というまとまりで扱う方向にAPI面が拡張された点が重要です。
最終的なOpenAPIでは、ChaosManagementClientのバージョンとして2026-05-01-previewが定義され、タグには従来のExperiments、Targets、Capabilitiesに加えて、Workspaces、DiscoveredResources、Scenarios、ScenarioRuns、ScenarioConfigurationsなどが含まれています。(GitHub)
| 変更領域 | 主な内容 | 実務で見るべきポイント |
|---|---|---|
| APIバージョン | 2026-05-01-previewが追加 | プレビュー版のため、本番自動化へ即適用せず検証環境で確認する |
| Workspaces | Chaos Studioのワークスペース作成、更新、削除、一覧取得、推奨更新 | スコープ、Managed Identity、LROの扱いを確認する |
| Scenarios | 障害注入の流れをシナリオとして定義 | 既存のExperiment中心の設計とどう使い分けるかを整理する |
| ScenarioConfigurations | シナリオの実行条件、パラメーター、除外条件、フィルターを管理 | 本番リソース除外、タグ除外、ゾーン指定の誤設定を防ぐ |
| ScenarioRuns | シナリオ実行の状態確認、一覧取得、キャンセル | 202/Locationヘッダーを使うポーリング処理を実装する |
| DiscoveredResources | ワークスペース配下で検出された対象リソースを参照 | 実行前の対象確認や監査に活用する |
注意したいのは、PR本文ではWorkspaceOperationResultsも新規リソースとして挙げられていますが、最終的なOpenAPIのタグやexamplesではWorkspaces、ScenarioRuns、ScenarioConfigurations、DiscoveredResourcesなどを中心に確認できます。実装担当者はPRの要約だけで判断せず、最終OpenAPIとexamplesを基準にしてください。(GitHub)
すぐ対応が必要な人、様子見でよい人
今回のAzure REST API更新は、Chaos Studioを使っているすべてのユーザーに即時対応を求めるものではありません。既存の一般公開APIで実験の作成、開始、停止だけを行っている場合、まずは利用中のapi-versionを固定できているかを確認するのが現実的です。
Microsoft Learnの既存サンプルでは、Chaos Studio REST APIを使って実験の作成・変更・削除、実行の表示・開始・停止、ターゲットや機能の管理を行えると説明されており、サンプルは一般公開されている2023-11-01で確認されています。(Microsoft Learn)
| 優先度 | 対象者 | 対応方針 |
|---|---|---|
| 高 | Azure REST APIを直接呼び出してChaos StudioをCI/CDに組み込んでいるチーム | api-version固定、LRO処理、レスポンス差分を確認する |
| 高 | OpenAPIからSDKやクライアントを自動生成している開発チーム | 新しいタグ、モデル、enum、メソッド名衝突を検証する |
| 中 | SRE、Platform Engineering、信頼性検証チーム | Workspaces/Scenariosを使う運用設計が必要か評価する |
| 中 | RBACやManaged Identityを管理するクラウド運用チーム | 権限修復、スコープ設定、最小権限の範囲を確認する |
| 低 | Azure Portal中心でChaos Studioを手動利用しているユーザー | すぐ変更せず、公式ドキュメントと利用可能リージョンを確認する |
特に注意すべきなのは、「最新のpreviewを常に使う」ような実装です。Azure REST APIではapi-versionを明示できるため、安定運用したい自動化では、意図せず新しいプレビュー仕様へ切り替わらないようにする必要があります。
Workspaces追加で確認すべき設定
Workspacesは、今回の更新で特に重要なリソースです。TypeSpec上では、Workspaceに対して取得、作成または更新、PATCH更新、削除、リソースグループ配下の一覧取得、サブスクリプション全体の一覧取得、推奨更新のrefreshRecommendationsが定義されています。(GitHub)
Workspaceモデルでは、TrackedResourceとしてlocationやtagsを持ち、Managed Service Identityを設定できます。プロパティには、読み取り専用のprovisioningState、読み取り専用のcommunicationEndpoint、子シナリオで使うワークスペース単位のscopesが含まれます。(GitHub)
検証環境で作成リクエストを確認する場合は、少なくとも次の観点を見てください。
az rest --method put \
--url "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Chaos/workspaces/{workspaceName}?api-version=2026-05-01-preview" \
--body '{
"location": "japaneast",
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{identityName}": {}
}
},
"properties": {
"scopes": [
"/subscriptions/{subscriptionId}/resourceGroups/{targetResourceGroupName}"
]
}
}'Workspace作成のexampleでは、properties.scopesに対象スコープのARMリソースIDを指定し、UserAssignedのManaged Identityを使う形式が示されています。また、作成・更新の応答例にはazure-asyncoperationやlocationヘッダーが含まれているため、クライアント側では非同期操作として扱う前提で実装してください。(GitHub)
ScenariosとScenarioConfigurationsは「実行前チェック」が重要
Scenariosは、障害注入の流れを定義するリソースです。Scenarioモデルには、説明、パラメーター定義、1つ以上のactions、推奨情報などが含まれます。ScenarioActionにはactionId、duration、アクション固有のparameters、依存関係を表すrunAfter、待機時間のwaitBefore、タイムアウト、外部リソース参照などが定義されています。(GitHub)
ScenarioConfigurationsは、シナリオを実行するための具体的な設定です。scenarioId、実行時パラメーター、除外条件、フィルターを持ち、除外条件では特定リソースID、タグ、リソースタイプを指定できます。フィルターではlocation、論理ゾーンのzones、物理ゾーンのphysicalZonesを扱えます。(GitHub)
この構造で失敗しやすいのは、「シナリオ定義は正しいが、構成で対象リソースを広げすぎる」ケースです。たとえば、タグ除外を入れ忘れると、本番VMや本番ストレージがシナリオの対象に含まれる可能性があります。Chaos Studioは制御された障害注入を行うためのサービスですが、対象範囲の設計を誤ると、検証のつもりが実障害に近い影響を出してしまいます。
ScenarioConfigurationsにはValidate、Execute、FixResourcePermissionsが用意されています。ValidateとExecuteのexamplesでは、いずれも202応答とlocationヘッダーによるポーリング先が示されています。(GitHub)
実務では、次の順序で運用するのが安全です。
| 手順 | 実施内容 | 確認すること |
|---|---|---|
| 事前確認 | WorkspaceのscopesとManaged Identityを確認 | 対象範囲が検証環境に限定されているか |
| シナリオ作成 | 障害注入のactions、duration、依存関係を定義 | アクションの順序、継続時間、外部リソース参照が妥当か |
| 構成作成 | parameters、exclusions、filtersを設定 | 本番タグ、保護対象リソース、対象リージョンを除外できているか |
| Validate実行 | 実行前に構成を検証 | 権限不足、対象リソース不足、状態エラーがないか |
| 必要に応じて権限修復 | FixResourcePermissionsを確認 | いきなり権限付与せず、dry run相当のwhatIfを検討する |
| Execute実行 | 検証済みの構成を実行 | 202応答後のLocationをポーリングする |
| 実行後確認 | ScenarioRunsで結果を確認 | 影響を受けたリソース、アクション結果、エラーを記録する |
長時間操作の扱いを見直す
今回の更新で見落としやすいのが、LRO、つまりLong Running Operationの扱いです。ScenarioConfigurationsのExecute、Validate、FixResourcePermissions、WorkspacesのRefreshRecommendations、ScenarioRunsのCancelなどは、同期的に完了する単純なAPI呼び出しとして扱わない方が安全です。
WorkspacesのrefreshRecommendations exampleでは、202応答と/evaluations/latestへのlocationヘッダーが示されています。ScenarioRunsのCancel exampleでも、202応答と実行リソースへのlocationヘッダーが示されています。(GitHub)
最低限、クライアント側では次を実装してください。
1. POSTまたはPUTの応答ステータスを確認する
2. 202が返った場合はLocationまたはazure-asyncoperationを取得する
3. Retry-Afterがあれば尊重する
4. ポーリング先でSucceeded、Failed、Canceledなどの終端状態を確認する
5. 失敗時はx-ms-correlation-request-idや応答本文をログに残すScenarioRunsのGet exampleでは、完了時の200だけでなく、実行中の202応答でもbodyにstatus: Runningなどの状態が含まれる例が示されています。単純に「200以外は失敗」とする古いRESTクライアントでは、実行中の処理を誤検知する可能性があります。(GitHub)
物理ゾーン指定を使う場合の注意点
ScenarioConfigurationsでは、論理ゾーンを表すzonesと、物理ゾーンを表すphysicalZonesを扱えます。ただしTypeSpec上では、zonesとphysicalZonesは相互排他的で、プレビューでは物理ゾーンは1つのみサポートされると説明されています。(GitHub)
これは、可用性ゾーンをまたいだ障害シナリオを作るチームにとって重要です。Azureの論理ゾーン番号はサブスクリプションによって対応する物理ゾーンが異なる場合があるため、複数サブスクリプションを対象にした訓練では、単にzones: ["1"]と書くだけでは意図した物理データセンター相当の範囲にならない可能性があります。
physicalZonesを使うexampleでは、westus2-az1のような形式で物理ゾーンを指定しています。またScenarioRunの応答例には、物理ゾーンが各サブスクリプションの論理ゾーンへどのように解決されたかを示すzoneResolutionが含まれています。(GitHub)
ゾーン障害訓練で確認すべきポイントは次の通りです。
| 確認項目 | ありがちなミス | 対策 |
|---|---|---|
zonesとphysicalZones | 両方を同時に指定する | 片方だけを使う |
| 対象リージョン | locationと物理ゾーンのリージョンが合わない | westus2ならwestus2-az1のように揃える |
| 複数サブスクリプション | 論理ゾーン番号を同じ意味だと思い込む | ScenarioRunのzoneResolutionを記録する |
| 本番影響 | 本番タグ付きリソースを含めてしまう | exclusionsでタグ、リソースID、タイプを明示的に除外する |
既存のExperiment API利用者が確認すべきこと
既存のChaos Studio運用では、Experiments、Targets、Capabilitiesを中心に使っているケースが多いはずです。Microsoft LearnのREST APIサンプルでも、リソースプロバイダー操作の一覧取得、ターゲットタイプの確認、ターゲット有効化、Capability有効化、Experimentの作成・開始・キャンセルなどが紹介されています。(Microsoft Learn)
そのため、既存運用でまずやるべきことは、すべてのAPI呼び出しを2026-05-01-previewへ置き換えることではありません。以下のように、現在の自動化が何に依存しているかを棚卸ししてください。
# リポジトリ内でChaos Studio関連のREST呼び出しを探す例
grep -R "Microsoft.Chaos" .
grep -R "api-version=" .
grep -R "chaos" .確認するポイントは、次の4つです。
| 確認対象 | 見るべき内容 |
|---|---|
api-version | 固定されているか、変数でpreviewに切り替わる設計になっていないか |
| 生成SDK | 新しいリソースやenumが追加されてもビルドが通るか |
| LRO処理 | 202、Location、Retry-After、終端状態を扱えるか |
| 監査ログ | 実行対象、実行者、Managed Identity、影響リソースを追跡できるか |
APIバージョンを上げる判断は、「新しいWorkspaces/Scenariosを使いたいか」「既存Experiment APIだけで十分か」で分けると失敗しにくくなります。既存の安定運用を優先する場合は、今のapi-versionを維持し、別ブランチや検証環境で2026-05-01-previewを試すのが現実的です。
移行前チェックリスト
2026-05-01-previewを試す場合は、以下のチェックリストを順に確認してください。
| チェック項目 | 合格条件 |
|---|---|
| APIバージョン管理 | 本番と検証でapi-versionを明示的に切り替えられる |
| クライアント生成 | OpenAPIから生成したSDKが既存コードと衝突しない |
| Workspace設計 | scopesが検証対象に限定され、Managed Identityが明確 |
| RBAC | 必要な権限だけを付与し、権限修復の影響範囲を確認済み |
| Scenario設計 | actionのduration、依存関係、外部リソース参照をレビュー済み |
| ScenarioConfiguration | exclusionsとfiltersで本番・保護対象を除外済み |
| Validate | Execute前に検証APIを呼び、結果を確認している |
| LROポーリング | 202応答を正常な途中状態として扱える |
| 失敗時対応 | Failed、Canceled、RequiresAttentionなどの状態をログ化できる |
| ロールバック | 既存APIバージョンに戻せる構成になっている |
ScenarioConfigurationsのFixResourcePermissionsには、権限修復結果やロール割り当て結果を表すモデルが含まれ、リクエストにはwhatIfを指定できるモデルも定義されています。権限系のAPIは便利ですが、対象スコープを広げると意図しないロール付与につながるため、まずは影響範囲を確認してから使うべきです。(GitHub)
よくある失敗と回避策
| 失敗パターン | なぜ問題になるか | 回避策 |
|---|---|---|
api-versionだけをpreviewに差し替える | レスポンス、LRO、モデル構造の違いで既存処理が壊れる | 差分検証用のブランチを作る |
| 202応答をエラー扱いする | 実行中のScenarioRunを失敗と誤判定する | Locationポーリングを実装する |
| enumを固定値だけで処理する | プレビューで状態値が追加・変更される可能性がある | unknown値をログ化して処理継続できる設計にする |
| 本番タグを除外しない | 障害注入対象に本番リソースが入る可能性がある | exclusionsでタグとリソースIDを二重に指定する |
zonesとphysicalZonesを混同する | 意図したゾーン障害訓練にならない | 目的が論理ゾーンか物理ゾーンかを事前に決める |
| 権限修復をいきなり実行する | Managed Identityに過剰な権限を付与する可能性がある | 事前レビューとdry run相当の確認を行う |
| PR説明だけで実装する | 最終OpenAPIとPR途中の説明が異なる場合がある | preview/2026-05-01-preview/openapi.jsonとexamplesを確認する |
次に取るべき行動
今回のAzure REST API更新は、Chaos Studioをより構造化して自動化したいチームにとって重要です。ただし、2026-05-01-previewはプレビューAPIなので、既存の安定運用を置き換える前に、利用目的を明確にする必要があります。
まずは、現在のChaos Studio自動化で使っているapi-versionを棚卸ししてください。次に、Workspaces、Scenarios、ScenarioConfigurations、ScenarioRunsを使う価値があるかを検証環境で判断します。採用する場合は、LROポーリング、Managed Identity、RBAC、除外条件、ゾーン指定、実行結果の監査まで含めて設計しましょう。
既存のExperiment中心の運用で要件を満たしているなら、すぐに移行する必要はありません。一方で、シナリオベースの再利用、実行前検証、検出リソースの確認、ゾーン障害訓練をREST APIで統制したい場合は、2026-05-01-previewを検証する価値があります。
コメント