Azure Chaos StudioをスクリプトやCI/CDから操作したいものの、「既存のExperimentを移行する必要があるのか」「パブリックプレビューを本番環境で使ってよいのか」と迷う管理者は多いでしょう。
結論から言うと、今回のAzure Chaos Studio CLI管理のパブリックプレビューは、新しいWorkspace／Scenarioモデルをaz chaosコマンドで管理できるようにする更新です。既存のclassic Experimentを強制的に置き換えるものではなく、現在のExperimentは引き続き利用できます。
そのため、既存の本番向けExperimentを急いで移行する必要はありません。一方、非本番環境で定型的な障害シナリオを繰り返し実行したい組織や、Chaos StudioをCI/CDへ組み込みたいチームにとっては、評価を始める価値があります。
Azure Chaos StudioのCLI管理パブリックプレビューで何が変わったのか
Microsoftは、2026年7月10日前後に確認された公式更新で、Azure Chaos StudioのWorkspaceとScenarioをAzure CLIから管理できる機能をパブリックプレビューとして案内しました。利用するには、Azure CLIへchaos拡張機能を追加します。(マイクロソフト アジュール)
az extension add --name chaos従来もAzure CLIやREST APIを使ってclassic Experimentを操作できましたが、今回の更新で追加されたaz chaosは、主に次の新しい管理モデルを対象としています。
- Workspaceの作成と管理
- 対象リソースの検出
- 利用可能なScenarioの確認
- Scenario構成の作成と更新
- 実行前の検証
- 必要な権限の確認と修正
- 障害テストの開始、状態確認、キャンセル
- 実行結果とレポートの確認
重要なのは、classic Experiment用の既存コマンドへ機能が追加されたのではなく、Workspace／Scenarioモデル用の新しいCLI管理機能が提供されたという点です。
まず確認したい対応要否
今回の更新によって、すべてのAzure Chaos Studio利用者に作業が発生するわけではありません。
| 利用状況 | 対応要否 | 推奨対応 |
|---|---|---|
| classic Experimentを本番運用している | 原則不要 | 現行構成を継続する |
| classic ExperimentをCLIやREST APIで自動実行している | 原則不要 | 既存スクリプトを維持する |
| 新しくChaos Studioを導入する | 評価推奨 | 非本番でWorkspaceを試す |
| 複数リソースに共通の障害パターンを適用したい | 評価推奨 | Scenarioカタログを確認する |
| CI/CDから障害テストを実行したい | 評価推奨 | CLIの検証・実行コマンドを試す |
| GA機能だけで本番運用したい | 現時点では見送り | classic Experimentを利用する |
| Scenarioカタログにない細かな障害を構成したい | 併用を検討 | classic Experimentを継続する |
| AKS Chaos Meshや動的ターゲット指定が必要 | classic推奨 | 既存モデルを利用する |
WorkspaceとScenarioはパブリックプレビューですが、classic Experimentは一般提供されています。Microsoftも両者を別のモデルとして位置付けており、Workspaceを導入しても既存Experimentには影響しません。(Microsoft Learn)
Workspace／Scenarioとclassic Experimentの仕様差分
Azure Chaos Studioの新しいモデルでは、個々の障害やターゲットを手作業で組み立てるのではなく、「ゾーン停止」「データベースフェイルオーバー」「依存サービス停止」といった障害シナリオを起点にテストを構成します。
主な違いは次のとおりです。
| 比較項目 | Workspace／Scenario | classic Experiment |
|---|---|---|
| 提供状態 | パブリックプレビュー | 一般提供 |
| 管理単位 | Workspace、Scenario、Config、Run | Experiment、Target、Capability |
| 対象リソースの登録 | スコープ内を自動検出 | リソースごとにTargetとCapabilityを有効化 |
| テストの作り方 | Scenarioテンプレートを選び、パラメーターを設定 | Fault、Step、Branch、Targetを個別に構成 |
| 推奨テスト | 検出したリソースから候補を提示 | Faultライブラリから利用者が選択 |
| 実行ID | WorkspaceのマネージドIDを共用 | ExperimentごとのマネージドID |
| 権限確認 | 実行前検証と権限修正機能を提供 | 不足権限が実行時に判明する場合がある |
| 対象範囲 | サブスクリプション、リソースグループ、Service Group | Experimentごとに対象を構成 |
| リージョン | 論理Workspaceから複数リージョンのリソースを扱える | Experimentと対象リージョンの条件を考慮 |
| 結果確認 | ScenarioレポートとAction単位の結果 | Experiment履歴とエラー情報 |
| 適した用途 | 共通的な障害パターンを素早く検証 | 詳細な障害構成や高度なカスタマイズ |
Workspaceでは、指定したスコープから対応リソースを検出し、利用可能なScenarioを提示します。classic Experimentよりも初期構成を簡略化しやすい一方、利用できる障害テストはScenarioカタログの内容に左右されます。(Microsoft Learn)
WorkspaceはExperimentの上位互換ではない
Workspace／Scenarioは、classic Experimentを単純に使いやすくした画面やコマンドではありません。
内部で使用するリソースモデルが異なり、WorkspaceはMicrosoft.Chaos/workspaces、Scenarioはその配下のリソースとして管理されます。classic Experimentで設定したTarget、Capability、Step、Branchが、自動的にScenarioへ変換されるわけではありません。
既存Experimentを移行する場合は、次の要素を改めて設計する必要があります。
- Workspaceのスコープ
- Workspaceで使用するマネージドID
- Scenarioの選択
- Scenario Configのパラメーター
- 対象リソースの除外条件
- Workspace IDへ付与するAzure RBAC
- 実行結果を評価する監視条件
したがって、「既存ExperimentをCLI対応させるためにWorkspaceへ移行する」という判断は適切ではありません。移行は、管理モデルを変更するメリットがある場合に限定するべきです。
Azure Chaos Studio CLIで実行できる主な操作
Azure Chaos Studio CLIでは、Workspaceの準備からScenario実行までを一連のコマンドで管理できます。
Azure CLIと拡張機能を確認する
chaos拡張機能を利用するには、Azure CLI 2.75.0以降が必要です。2026年7月時点の公式拡張機能一覧では、chaos拡張機能はプレビュー版として掲載されています。(Microsoft Learn)
az version
az extension add --name chaos
az extension show --name chaos --output tableすでにインストールしている場合は、次のコマンドで更新できます。
az extension update --name chaosプレビュー期間中はコマンド仕様や出力項目が変更される可能性があります。CI/CDで使用する場合は、実行環境ごとに拡張機能のバージョンを記録しておくことが重要です。
リソースプロバイダーを登録する
Azure Chaos Studioを利用するサブスクリプションでは、Microsoft.Chaosリソースプロバイダーを登録します。
az provider register --namespace Microsoft.Chaos登録状態は次のコマンドで確認できます。
az provider show \
--namespace Microsoft.Chaos \
--query registrationState \
--output tsvWorkspaceをセットアップする
az chaos setupを実行すると、Workspaceの作成、マネージドIDの設定、対象リソースの検出、利用可能なScenarioの評価までをまとめて実行できます。
az chaos setup \
--name <workspace-name> \
--resource-group <workspace-resource-group> \
--location <workspace-region> \
--scopes "/subscriptions/<subscription-id>/resourceGroups/<target-resource-group>"--scopesには、サブスクリプション、リソースグループ、Service GroupのリソースIDを指定できます。安全な既定値がないため、対象スコープは明示的な指定が必要です。複数のスコープを指定することもできます。(Microsoft Learn)
セットアップでは、通常、WorkspaceのマネージドIDにスコープのReaderロールが付与されます。組織の権限管理ルールによりCLIからロールを付与できない場合は、次のように自動付与を無効化できます。
az chaos setup \
--name <workspace-name> \
--resource-group <workspace-resource-group> \
--location <workspace-region> \
--scopes "/subscriptions/<subscription-id>/resourceGroups/<target-resource-group>" \
--skip-permissionsこの場合、Readerロールと各Actionに必要なロールを別途付与しなければなりません。
検出されたリソースとScenarioを確認する
Workspaceが認識したリソースは、次のコマンドで確認できます。
az chaos discovered-resource list \
--workspace-name <workspace-name> \
--resource-group <workspace-resource-group> \
--output table利用可能なScenarioは次のコマンドで確認します。
az chaos scenario list \
--workspace-name <workspace-name> \
--resource-group <workspace-resource-group> \
--output tableリソースを追加した後や権限を変更した後は、Scenarioの推奨結果を更新します。
az chaos workspace refresh-recommendation \
--name <workspace-name> \
--resource-group <workspace-resource-group>Scenarioは、必要なリソースタイプがWorkspaceのスコープ内で検出された場合に表示されます。複数種類のリソースを必要とするScenarioでは、必要な種類がすべて存在しなければ候補に表示されません。(Microsoft Learn)
Scenario Configを作成する
Scenario Configには、障害の継続時間、対象リージョン、可用性ゾーン、対象リソースなどを指定します。
az chaos scenario config create \
--workspace-name <workspace-name> \
--resource-group <workspace-resource-group> \
--scenario-name <scenario-name> \
--name <config-name> \
--parameters "[{key:duration,value:PT10M}]" \
--filters "{locations:[<target-region>],zones:[1]}"PT10MはISO 8601形式で10分を表します。利用できるパラメーターやフィルターはScenarioごとに異なるため、Scenarioの定義を確認して設定します。
可用性ゾーンを指定するzonesと、物理ゾーンを指定するphysical-zonesは同時には指定できません。(Microsoft Learn)
構成と権限を検証する
作成したScenario Configは、実行前に検証できます。
az chaos scenario config validate \
--workspace-name <workspace-name> \
--resource-group <workspace-resource-group> \
--scenario-name <scenario-name> \
--name <config-name>不足しているロール割り当てを確認する場合は、まず--what-ifで変更内容を確認します。
az chaos scenario config fix-permissions \
--workspace-name <workspace-name> \
--resource-group <workspace-resource-group> \
--scenario-name <scenario-name> \
--name <config-name> \
--what-if内容を確認して問題がなければ、--what-ifを外して実行します。
ロールを付与した直後は、Azure RBACの反映に時間がかかる場合があります。権限を修正しても検証に失敗する場合は、少し時間を置いてから再度検証します。(Microsoft Learn)
Scenarioを実行する
Scenario Configを実行するには、次のコマンドを使用します。
az chaos scenario run start \
--workspace-name <workspace-name> \
--resource-group <workspace-resource-group> \
--scenario-name <scenario-name> \
--config-name <config-name>run startは、既定で実行前の検証を行います。検証に失敗するとScenarioは開始されず、コマンドもエラーで終了します。
--skip-validationを付けると事前検証を省略できますが、初回実行や構成変更後の実行では使用すべきではありません。CI/CDで検証処理と実行処理を明確に分離している場合など、用途を限定して使用します。(Microsoft Learn)
導入前に満たすべき条件
Azure Chaos Studio CLIを試す前に、次の条件を確認します。
| 確認項目 | 条件・確認内容 |
|---|---|
| Azure CLI | 2.75.0以降 |
| CLI拡張機能 | chaos拡張機能をインストール |
| リソースプロバイダー | Microsoft.Chaosを登録 |
| 対象リソース | Chaos Studioが対応するAzureリソースが存在する |
| Workspaceのリージョン | パブリックプレビュー対象リージョンから選択 |
| 対象スコープ | サブスクリプション、リソースグループ、Service GroupのIDを明示 |
| Workspace作成権限 | リソースを作成できるContributor相当以上 |
| ロール割り当て権限 | Owner、User Access Administrator、または同等のカスタムロール |
| 実行用ID | システム割り当てまたはユーザー割り当てマネージドID |
| Action用権限 | VM、ネットワーク、データベースなどActionごとのRBAC |
2026年7月時点では、Workspaceを作成できるリージョンにJapan East、East US 2、West US 2、West Central US、North Europe、Sweden Central、UK Southが含まれます。Workspaceは論理リソースであるため、テスト対象のリソース自体がWorkspaceと同じリージョンに存在する必要はありません。(Microsoft Learn)
Workspaceのリージョンと対象リソースのリージョンは別に考える
たとえば、WorkspaceをJapan Eastに作成し、Japan Westや別リージョンの対象リソースをスコープへ含めることができます。
ただし、すべてのActionがすべてのリージョンやリソース構成に対応するとは限りません。Workspaceを作成できることと、希望するScenarioを実行できることは分けて確認してください。
ロール割り当て権限がない場合
az chaos setupでReaderロールを自動付与するには、実行ユーザーが対象スコープでロールを割り当てられる必要があります。
一般的なContributorロールには、他のIDへAzure RBACを割り当てる権限がありません。そのため、次のどちらかの運用が必要です。
- OwnerまたはUser Access Administratorがセットアップを行う
--skip-permissionsを指定し、権限管理者が別途ロールを付与する
権限分離を重視する企業環境では、後者の方が変更管理や監査に適しています。
WorkspaceのマネージドIDと権限設計
Workspaceでは、複数のScenarioが1つのマネージドIDを共有します。
classic ExperimentはExperiment単位でマネージドIDと権限を分けられますが、Workspaceでは権限範囲を広く設定すると、Workspace配下のScenario全体がその権限を利用できる状態になります。
代表的なActionで必要になるロールの例は次のとおりです。
| 操作対象 | 権限の例 |
|---|---|
| 仮想マシンの停止、再起動、再デプロイ | Virtual Machine Contributor |
| Network Security Groupの変更 | Network Contributor |
| データベースのフェイルオーバー | Contributorなど対象サービスに応じたロール |
| Azure Cosmos DBのフェイルオーバー | Cosmos DB Operator |
| VMのエージェントベースAction | 対象VMへのReaderとエージェント側の認証設定 |
Workspaceを実行する利用者にも権限が必要です。閲覧だけならReader、Scenario実行にはContributorまたはMicrosoft.Chaos/workspaces/scenarios/run/actionを含むカスタムロールが必要になります。(Microsoft Learn)
実務では、次のように権限を分離すると安全です。
- 開発、検証、本番でWorkspaceを分ける
- 最初はサブスクリプションではなく検証用リソースグループをスコープにする
- 本番用Workspaceには専用のユーザー割り当てマネージドIDを使用する
- Scenarioに不要なリソースは除外する
fix-permissionsの前に必ず--what-ifを確認する- Contributorを広範囲に付与せず、Actionに必要なロールへ限定する
利用できるScenarioの例
Workspaceでは、一般的な障害パターンをScenarioとして選択できます。公式ドキュメントでは、次のようなScenarioが案内されています。
- DNS Outage
- Microsoft Entra ID Outage
- Compute Zone Down
- Zone Down
- データベースフェイルオーバーを伴うゾーン障害
- DB Failover Under Load
- DB Restart Under Load
- Cache Stampede
- Event-Driven Messaging Disruption
- Dependency Blackout
- VM Hibernate
- CPU Pressure
- Physical Memory Pressure
CPU PressureやPhysical Memory Pressureなど、一部のScenarioではVMへエージェント拡張機能が一時的に導入されます。公式仕様では、実行時に拡張機能をインストールし、終了時に削除する構成が示されています。(Microsoft Learn)
ただし、Scenarioが「推奨」と表示されることは、業務上安全に実行できることを意味しません。推奨結果は、主にスコープ内に必要なリソースタイプが存在するかを基に評価されます。
次のような業務条件までは自動判断されません。
- テスト対象が本番トラフィックを処理しているか
- 停止してはいけないバッチ処理が実行中か
- フェイルオーバー先の容量が足りるか
- 監視アラートが正しく通知されるか
- データ整合性に影響する処理が進行中か
- 復旧後にアプリケーションが再接続できるか
既存実装との互換性で注意するポイント
既存Experimentはそのまま利用できる
Workspaceとclassic Experimentは併存できます。既存Experimentが無効化されたり、自動的にWorkspaceへ変換されたりすることはありません。(Microsoft Learn)
そのため、次のような段階的導入が可能です。
- 本番環境はGAのclassic Experimentを継続
- 新規の非本番テストはWorkspaceで作成
- 共通的な障害パターンはScenarioへ移行
- カタログにない障害はclassic Experimentで維持
- 両モデルの結果を同じAzure Monitorや運用ダッシュボードで評価
既存の自動化スクリプトは書き換え不要
classic Experimentを対象とした既存のAzure CLI、REST API、ARMテンプレート、Bicepなどは、Workspace用のaz chaosへ直ちに書き換える必要はありません。
一方、az chaosはclassic Experimentを透過的に管理するコマンドではありません。既存のExperiment名をWorkspace名へ置き換えるだけでは移行できないため、別の自動化処理として構築してください。
スケジュール実行や高度なターゲット指定は差分を確認する
ScenarioカタログにないFault、特定のエージェントベース障害、AKS Chaos Mesh、動的ターゲット指定、既存のスケジュール実行を利用している場合は、classic Experimentを維持する方が適しています。
CLIが利用できるようになったことだけを理由に、既存の柔軟なExperimentをScenarioへ置き換えると、必要なテスト範囲を狭めてしまう可能性があります。(Microsoft Learn)
パブリックプレビューをテストするときの注意点
本番環境への直接導入は避ける
WorkspaceとScenarioはパブリックプレビューです。一般提供機能と異なり、SLAや正式な本番サポートを前提にできません。Microsoftもプレビュー機能を現状有姿で提供し、本番利用を目的としないことを案内しています。(Microsoft Learn)
最初は次のような環境で評価してください。
- 開発用サブスクリプション
- 検証専用リソースグループ
- 本番データを持たないステージング環境
- トラフィックを遮断した複製環境
- 復旧手順を事前に確認できる小規模環境
スコープを広げすぎない
az chaos setupの--scopesにサブスクリプション全体を指定すると、Workspaceの検出範囲も広がります。
WorkspaceのマネージドIDへ広い権限を付与すれば、意図しないリソースがScenarioの対象候補になる可能性があります。初回評価では、対象リソースだけを含む専用リソースグループを指定するのが安全です。
--skip-validationを常用しない
az chaos scenario run startは、既定で事前検証を行います。--skip-validationを使うと実行時間を短縮できる場合がありますが、権限不足や構成不備を見逃す可能性があります。
少なくとも次の場合は検証を省略しないでください。
- Scenario Configを新規作成した
- 対象リソースを追加または削除した
- Workspaceのスコープを変更した
- マネージドIDを変更した
- Azure RBACを変更した
- Scenarioのパラメーターを変更した
- CLI拡張機能を更新した
自動的な権限修正は変更内容を確認する
fix-permissionsは便利ですが、内容を確認せずに実行すると、想定より広いスコープへ権限が付与される可能性があります。
必ず次の順序で実行します。
validateで不足権限を確認するfix-permissions --what-ifで変更予定を確認する- 対象スコープとロールをレビューする
- 必要に応じて権限管理者が手動で付与する
- RBAC反映後に再度
validateする - 検証成功後にScenarioを実行する
Service Groupをスコープにした場合、自動ロール割り当てが期待どおりに動作しない既知の制約も案内されています。その場合は、配下のサブスクリプションやリソースグループへ必要なロールを手動で割り当てます。(Microsoft Learn)
リソースが検出されない場合は権限とスコープを確認する
discovered-resource listに対象が表示されない場合、主に次の原因が考えられます。
- WorkspaceのマネージドIDにReaderが付与されていない
- スコープ内に対応リソースがない
- リソース検出やAzure Resource Graphへの反映が完了していない
- スコープとして指定したリソースグループが誤っている
- AKSのノードが別のマネージドリソースグループに存在する
特にAKSでは、クラスター本体とVM Scale Setsなどの実体が別のマネージドリソースグループに置かれることがあります。AKSリソースだけを含むスコープでは、期待するコンピュートリソースが検出されない可能性があります。(Microsoft Learn)
Scenarioレポートだけで成功判定しない
Scenarioレポートでは、Actionの実行結果、継続時間、対象リソース、実行フローなどを確認できます。
ただし、Actionが正常に実行されたことと、システムが障害に耐えられたことは別です。たとえば、VM停止Actionが成功しても、別リージョンへの切り替えやユーザー処理の継続に失敗していれば、レジリエンステストとしては失敗です。
Scenario実行時は、次の指標も同時に記録します。
- 可用性とエラー率
- API応答時間
- キュー滞留数
- データベース接続エラー
- フェイルオーバー時間
- アラート発報時間
- オンコール担当者への通知時間
- 自動復旧までの時間
- 手動対応が必要になった操作
- 復旧後のデータ整合性
Microsoftも、Scenarioレポートをアプリケーション独自のヘルスチェックと組み合わせて評価することを推奨しています。(Microsoft Learn)
キャンセルを復旧手段として過信しない
CLIには実行中のRunをキャンセルするコマンドがありますが、キャンセル操作だけを復旧計画にしてはいけません。
Actionごとに、終了時の自動復旧動作が異なります。ネットワーク制御を元に戻すAction、エージェントを削除するAction、フェイルオーバーや停止後にアプリケーション側の再接続確認が必要なActionなどがあります。
実行前に次の内容を整理してください。
- Scenarioを中断する条件
- CLIでのキャンセル手順
- Azure Portalからの停止手順
- 各リソースの手動復旧手順
- 復旧確認に使用するメトリック
- テスト責任者と承認者
- テスト中に連絡する運用担当者
CI/CDへ組み込む場合の実務ポイント
Azure Chaos Studio CLIの大きな利点は、WorkspaceとScenarioの操作をパイプラインから再現しやすくなることです。
ただし、パブリックプレビュー中は、単純にrun startを追加するだけでは安全な自動化になりません。
推奨するパイプライン構成
次のように処理を分離すると、誤実行を防ぎやすくなります。
- Azure CLIのバージョン確認
chaos拡張機能のバージョン確認- Azureへの認証
- 対象サブスクリプションの固定
- WorkspaceとScenario Configの存在確認
validateの実行- 権限変更内容の確認
- 人による承認
- Scenarioの実行
- Run IDの保存
- Azure Monitorなどでシステム状態を観測
- Scenarioレポートの保存
- 合否判定
- 復旧確認
本番に近い環境では、検証と実行の間に承認ゲートを設けるべきです。
サブスクリプションを明示的に固定する
パイプラインでは、意図しないサブスクリプションへ接続しないようにします。
az account set --subscription "<subscription-id>"
az account show --output table表示結果をログへ残し、Workspace名だけでなく、サブスクリプションID、リソースグループ名、Scenario名、Config名を実行前に確認してください。
プレビュー版の更新を自動適用しない
常に最新版へ自動更新すると、コマンドの変更によってパイプラインが突然失敗する可能性があります。
少なくとも次の情報を実行ログへ記録します。
az version
az extension show --name chaos拡張機能を更新するときは、検証環境でコマンド、出力JSON、終了コードを確認してから本番相当のパイプラインへ反映します。
Azure Chaos Studio CLIを導入すべき組織
次の条件に当てはまる場合は、非本番環境での評価に向いています。
- Chaos Studioを初めて導入する
- 共通的な障害パターンから試したい
- 手作業によるTargetやCapabilityの設定を減らしたい
- 複数のリソースグループやリージョンを横断してテストしたい
- 障害テストの構成をCLIで再現したい
- CI/CDに実行前検証を組み込みたい
- Scenario単位のレポートを残したい
- 開発チームごとにWorkspaceを分離したい
一方、次の条件ではclassic Experimentの継続が現実的です。
- 本番利用で一般提供機能が必須
- ScenarioカタログにないFaultを使用している
- 細かなStepやBranchを構成している
- AKS Chaos Meshを利用している
- 動的ターゲット指定が必要
- 既存Experimentの自動化が安定運用されている
- Experiment単位でIDと権限を厳密に分離している
導入する場合の推奨手順
Azure Chaos Studio CLIの評価は、次の順序で進めると安全です。
- 既存のclassic Experimentを一覧化する
- Workspaceへ置き換える目的を明確にする
- 検証専用リソースグループを用意する
- Azure CLI 2.75.0以降を準備する
chaos拡張機能をインストールするMicrosoft.Chaosを登録する- 最小限のスコープでWorkspaceを作成する
- 検出リソースと推奨Scenarioを確認する
- Workspace IDへ必要最小限のロールを付与する
- 短時間かつ影響の小さいScenario Configを作成する
validateとfix-permissions --what-ifを実行する- Azure Monitorの観測条件と中止条件を決める
- Scenarioを実行する
- レポートとアプリケーション指標を照合する
- classic Experimentとの使い分けを決定する
Azure Chaos Studio CLI管理のパブリックプレビューで最も重要な点は、既存Experimentの移行ではなく、Workspace／Scenarioモデルを自動化できる選択肢が増えたことです。
既存の本番環境は急いで変更せず、まず検証用リソースグループでCLIのセットアップ、権限検証、Scenario実行、レポート取得までを一巡させてください。その結果、Scenarioカタログで必要な障害を再現でき、権限共有やプレビュー機能の制約を許容できる場合に、段階的な導入を検討するのが適切です。
コメント