Azure Chaos Studioをコマンドラインから自動化したいものの、「既存のExperimentを作り直す必要があるのか」「プレビュー機能を本番運用に組み込んでよいのか」と判断に迷う担当者も多いでしょう。
結論から言うと、今回のPublic Previewでは、新しいAzure CLI拡張機能のaz chaosを使い、Chaos StudioのWorkspace作成、対象リソースの検出、Scenarioの構成・検証・実行までをCLIから一貫して操作できるようになりました。一方、従来のExperimentはそのまま動作し、移行も強制されません。既存環境を急いで変更する必要はなく、まずは非本番環境でCLI自動化の有効性を確認するのが適切です。(Microsoft Azure)
Azure Chaos StudioのAzure CLI対応で何が変わったのか
日本時間2026年7月10日付で確認された公式更新では、Azure CLIからAzure Chaos Studioのresilience Scenarioを作成・実行できるaz chaos拡張機能がPublic Previewとして案内されました。
これまでWorkspaceやScenarioをプログラムから細かく制御する場合、REST APIの呼び出しやJSONファイルの組み立てが必要でした。今回の更新後は、Azure CLIのコマンド体系に沿って、次の操作を実行できます。
- Chaos Studio Workspaceの作成
- Workspaceが対象とするスコープの設定
- 対象リソースの検出
- 利用可能なScenarioの推薦
- Scenario configurationの作成と更新
- 実行前の権限検証
- 必要なRBACロールの確認と付与
- Scenarioの開始、状態確認、キャンセル
- JSON、TSV、table形式による結果出力
中心となるのがaz chaos setupです。このコマンドは、Workspaceの作成、マネージドIDの設定、スコープへのReaderロール付与、対象リソースの検出、実行可能なScenarioの推薦までをまとめて処理します。(Microsoft Learn)
| 操作 | 主なコマンド |
|---|---|
| 初期セットアップ | az chaos setup |
| Workspace管理 | az chaos workspace |
| 検出済みリソースの確認 | az chaos discovered-resource list |
| 利用可能なScenarioの確認 | az chaos scenario list |
| Scenario構成の作成 | az chaos scenario config create |
| 実行前の検証 | az chaos scenario config validate |
| 権限不足の確認・修正 | az chaos scenario config fix-permissions |
| Scenario実行 | az chaos scenario run start |
| 実行状態の確認 | az chaos scenario run show |
| 実行キャンセル | az chaos scenario run cancel |
単に「ポータル操作をCLIに置き換えた」だけではありません。対象リソースの探索、Scenarioの推薦、権限の事前検証まで自動化できるため、CI/CDや定期的なレジリエンステストへ組み込みやすくなった点が重要です。
Workspaceと従来のExperimentの仕様差分
Azure Chaos Studioには、今回のCLI拡張機能が主に対象とする「Workspace／Scenarioモデル」と、従来からある「Experimentモデル」の2種類があります。
両者は同じリソースを壊して検証する仕組みではあるものの、構成方法や権限モデルが異なります。
| 比較項目 | Workspace／Scenario | Experiment（従来型） |
|---|---|---|
| 提供状況 | Public Preview | 一般提供 |
| 対象リソースの登録 | スコープ内から自動検出 | リソースごとにTargetとCapabilityを有効化 |
| テスト定義 | 障害パターン別のScenarioを利用 | Fault、Step、Branch、Targetを個別に構成 |
| マネージドID | Workspace単位で共有 | Experimentごとに用意 |
| 権限確認 | 実行前に検証可能 | 権限不足が実行時に表面化しやすい |
| 対象リージョン | Workspaceとは異なるリージョンも対象にできる | TargetやCapabilityにリージョン上の制約がある |
| 結果確認 | Scenario reportを生成 | Experimentの実行履歴を確認 |
| 適する用途 | 一般的な障害パターンを短時間で検証 | 独自Faultや複雑な構成を細かく制御 |
Workspaceでは、サブスクリプション、リソースグループ、Service Groupのいずれかをスコープとして指定します。Chaos Studioは、その範囲に存在する対応リソースを検出し、Compute Zone Down、DNS Outage、データベースフェイルオーバーなど、適用可能なScenarioを提示します。
従来のExperimentでは、対象リソースごとにTargetやCapabilityを有効化し、Fault、Step、Branchを手動で組み立てる必要がありました。自由度は高いものの、初期設定や権限管理が複雑になりやすい方式です。(Microsoft Learn)
既存のChaos Studio実装との互換性
今回の更新によって、既存のExperimentが停止したり、Workspaceへ自動移行されたりすることはありません。
WorkspaceとExperimentは独立したモデルとして共存します。既存のExperiment、Target、Capability、マネージドID、RBAC設定は従来どおり利用できます。したがって、すでに安定稼働しているExperimentを、今回のPublic Previewに合わせて書き直す必要はありません。(Microsoft Learn)
ただし、次の点には注意が必要です。
az chaosは既存スクリプトの単純な置き換えではない
新しいaz chaos拡張機能は、主にWorkspaceとScenarioを対象にしています。従来型ExperimentのREST APIスクリプトやARMテンプレートを、コマンド名だけ置き換えて移行できるわけではありません。従来型ExperimentをCLIから操作する既存実装は、そのまま維持するのが基本です。(Microsoft Learn)
Experimentの権限はWorkspaceに自動継承されない
従来型ではExperimentごとにマネージドIDとRBACロールを設定します。Workspaceでは、WorkspaceのマネージドIDを全Scenarioで共有します。
既存ExperimentのIDにVirtual Machine Contributorなどを付与していても、新しく作成したWorkspaceのIDが同じ権限を持つとは限りません。Workspace側でReaderロールとAction実行用ロールを改めて確認してください。(Microsoft Learn)
両モデルを使い分けてもよい
一般的なゾーン障害やDNS障害はWorkspaceで実行し、Scenarioカタログにない独自Faultは従来型Experimentで実行する、といった併用が可能です。
AKS Chaos Mesh、動的ターゲティング、スケジュール実行、カタログにない細かなagent-based faultが必要な場合は、引き続きExperimentが有力です。(Microsoft Learn)
今回の更新への対応が必要な利用者
利用状況によって、対応の優先度は異なります。
| 現在の利用状況 | 対応優先度 | 推奨対応 |
|---|---|---|
| 従来型Experimentを本番で安定運用中 | 低 | 既存実装を維持し、GAまでは移行を急がない |
| REST APIとJSONでWorkspaceを操作している | 高 | 非本番環境でaz chaosへの置き換えを検証 |
| CI/CDにレジリエンステストを組み込みたい | 中～高 | CLIのJSON出力と事前検証機能を評価 |
| 複数リージョンの環境を一元的に検証したい | 中～高 | Workspaceをアプリ単位または環境単位で試す |
| AKS Chaos Meshや独自Faultを使用している | 低 | 従来型Experimentを継続 |
| 本番利用にSLAや固定仕様が必要 | 低 | Public Preview終了まで本格導入を待つ |
| Chaos Studioをまだ利用していない | 任意 | 障害対応やBCP検証が課題ならPoCを検討 |
特に恩恵が大きいのは、REST API呼び出しやJSON生成を独自スクリプトで管理している組織です。CLIの入力形式と出力形式に統一することで、処理の可読性や保守性を改善できます。
一方、WorkspaceとScenarioはPublic Previewです。公式ドキュメントでは、SLAや限定保証の対象外であり、本番利用を目的とした機能ではないと明記されています。実運用の障害訓練をすぐ全面移行するのではなく、開発環境やステージング環境で評価してください。(Microsoft Learn)
導入前に確認する条件
Azure CLIと拡張機能
公式CLIリファレンスでは、chaos拡張機能はAzure CLI 2.75.0以降が前提です。公開時点の拡張機能一覧では1.0.0b1がPreviewとして掲載されています。
プレビュー期間中はバージョンや引数が変更される可能性があります。CI/CDで使用する場合は、検証した拡張機能のバージョンを記録し、更新前に回帰テストを行うことが重要です。(Microsoft Learn)
Microsoft.Chaosリソースプロバイダー
対象サブスクリプションでMicrosoft.Chaosリソースプロバイダーを登録する必要があります。
az provider register --namespace Microsoft.Chaos
az provider show \
--namespace Microsoft.Chaos \
--query registrationState \
--output tsv結果がRegisteredになってからWorkspaceを作成します。(Microsoft Learn)
対応リソース
Workspaceのスコープ内に、Chaos Studio Actionが対応するリソースが必要です。代表例は次のとおりです。
- Azure Virtual Machines
- Azure Virtual Machine Scale Sets
- Azure SQL Database
- Azure SQL Managed Instance
- Azure Database for PostgreSQL Flexible Server
- Azure Database for MySQL Flexible Server
- Network Security Group
- Azure Managed Redis
- App Service
- Service Bus
- Event Hubs
利用できるScenarioは、Workspaceが検出したリソースの種類によって変わります。複数サービスを組み合わせるScenarioでは、必要なリソースがすべてスコープ内に存在しなければ候補に表示されないことがあります。(Microsoft Learn)
Workspaceのリージョン
Public Preview期間中、Workspaceを作成できるリージョンは限定されています。公式ドキュメントの2026年7月時点の一覧にはJapan Eastが含まれています。
Workspaceは論理リソースであり、Workspace自体と対象リソースを同じリージョンに配置する必要はありません。ただし、対象サービスとActionがそのリソース構成に対応しているかは別途確認が必要です。(Microsoft Learn)
RBACとマネージドIDの確認ポイント
Workspaceでは、操作するユーザーとWorkspaceのマネージドIDの両方に権限が必要です。
| 操作 | 必要な権限の目安 |
|---|---|
| WorkspaceとScenarioの閲覧 | WorkspaceにReader |
| Scenarioの実行 | WorkspaceにContributor、または実行Actionを含むカスタムロール |
| Workspaceの作成・変更 | ContributorまたはOwner |
| マネージドIDへのロール付与 | 対象スコープにOwnerまたはUser Access Administrator |
| リソースの検出 | WorkspaceのIDにReader |
| VM停止・再起動 | WorkspaceのIDにVirtual Machine Contributor |
| NSGルールの変更 | WorkspaceのIDにNetwork Contributor |
| データベースフェイルオーバー | WorkspaceのIDに対象サービス用のContributorなど |
Readerだけではリソースを検出できますが、障害を注入するActionは実行できません。逆に、広いサブスクリプションスコープへContributorを付与すると、想定以上のリソースが障害対象になる危険があります。
自動権限付与を利用しない組織では、az chaos setupに--skip-permissionsを指定し、必要なロールだけを手動で付与します。(Microsoft Learn)
Azure CLIで安全に検証する手順
以下はAzure Cloud ShellのBashを想定した例です。最初の検証では、サブスクリプション全体ではなく、専用の非本番リソースグループをスコープにしてください。
Azure CLIと拡張機能を確認する
az version
az extension add --name chaos
az extension show \
--name chaos \
--query "{name:name, version:version}" \
--output tableすでにインストール済みの場合は、次のコマンドで更新できます。
az extension update --name chaosプレビュー拡張機能をCI/CDで利用するときは、更新前後のバージョンをログへ保存しておくと、コマンド仕様変更時の原因調査が容易になります。
操作対象のサブスクリプションを固定する
az login
az account set \
--subscription "<subscription-name-or-id>"
az account show \
--query "{name:name, id:id}" \
--output table複数サブスクリプションを扱う端末では、az account setを省略しないことが重要です。誤ったサブスクリプションでWorkspaceを作成すると、意図しないスコープへロールが付与される可能性があります。
Workspaceをセットアップする
TARGET_SCOPE=$(az group show \
--name rg-chaos-target-dev \
--query id \
--output tsv)
az chaos setup \
--name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--location japaneast \
--scopes "$TARGET_SCOPE"az chaos setupは、指定したリソースグループが存在しなければ作成し、Workspace、マネージドID、Readerロール、リソース検出、Scenario推薦をまとめて実行します。
ロール付与を自動化したくない場合は、次のように指定します。
az chaos setup \
--name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--location japaneast \
--scopes "$TARGET_SCOPE" \
--skip-permissionsサブスクリプション全体を最初から--scopesに指定するのは避けてください。技術的に指定可能でも、検出対象と権限付与範囲が広くなり、障害半径の確認が難しくなります。(Microsoft Learn)
検出されたリソースとScenarioを確認する
az chaos discovered-resource list \
--workspace-name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--output table
az chaos scenario list \
--workspace-name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--output table構成変更後に表示が古い場合は、推薦情報を更新します。
az chaos workspace refresh-recommendation \
--name chaos-ws-dev \
--resource-group rg-chaos-control-devこの段階で、想定外の本番リソースが一覧に含まれていないことを必ず確認してください。
Scenario configurationを作成する
次は、ゾーンを対象とするScenarioの構成例です。
az chaos scenario config create \
--workspace-name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--scenario-name "<scenario-name>" \
--name zone1-10min \
--parameters "[{key:duration,value:PT10M}]" \
--filters "{locations:[japaneast],zones:[1]}"<scenario-name>には、az chaos scenario listで確認した名前を指定します。PT10MはISO 8601形式の10分を表します。
指定できるパラメーターはScenarioごとに異なります。また、zonesとphysical-zonesは同時に指定できません。サンプルをそのまま本番環境へ流用せず、Scenarioの定義と対象リソースを確認してください。(Microsoft Learn)
実行前に権限を検証する
az chaos scenario config validate \
--workspace-name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--scenario-name "<scenario-name>" \
--name zone1-10min不足する権限を確認するときは、まず--what-ifを付けます。
az chaos scenario config fix-permissions \
--workspace-name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--scenario-name "<scenario-name>" \
--name zone1-10min \
--what-if表示されたロールと付与先を確認し、問題がなければ--what-ifを外して実行します。ロール割り当ての反映には数分かかることがあるため、直後の検証で失敗しても、すぐに設定を追加せず少し待ってから再実行してください。(Microsoft Learn)
Scenarioを実行・監視する
az chaos scenario run start \
--workspace-name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--scenario-name "<scenario-name>" \
--config-name zone1-10min返されたRun IDを使って状態を確認します。
az chaos scenario run show \
--workspace-name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--scenario-name "<scenario-name>" \
--run-id "<run-id>" \
--output table中止条件に達した場合は、次のコマンドを実行します。
az chaos scenario run cancel \
--workspace-name chaos-ws-dev \
--resource-group rg-chaos-control-dev \
--scenario-name "<scenario-name>" \
--run-id "<run-id>"run startでは、通常、実行前の検証が行われてからActionが開始されます。ただし、事前検証に成功したことは、アプリケーションが安全であることを保証するものではありません。(Microsoft Learn)
テスト時に必ず確認したい注意点
非本番環境から開始する
WorkspaceとScenarioはPublic Previewであり、SLAの対象ではありません。開発環境やステージング環境でCLI、権限、対象リソース、復旧手順を確認してから、利用範囲を検討してください。
「Public Previewだから無料」「失敗しても自動復旧する」とは限りません。
Scenarioの成功とアプリの耐障害性を混同しない
Scenario reportには、各Actionの成否、実行時間、対象リソース、実行順序が記録されます。しかし、Actionが成功しても、利用者から見たサービスが正常に復旧したとは限りません。
テスト中は、少なくとも次の指標を別途監視します。
- HTTPエラー率
- 応答時間
- スループット
- データベース接続エラー
- 接続プールの枯渇
- キューの滞留数
- フェイルオーバー完了時間
- 再試行回数
- RTOとRPO
- 利用者操作の成功率
公式ドキュメントでも、Scenario reportを独自のヘルスチェックや監視情報と組み合わせ、エンドツーエンドの復旧を検証することが推奨されています。(Microsoft Learn)
中止条件を先に決める
障害を注入してから判断するのでは遅すぎます。実行前に、例えば次のような中止条件を定めます。
- エラー率が5％を超えた状態が3分続く
- P95応答時間が通常時の3倍を超える
- データ不整合が1件でも検出される
- フェイルオーバーが想定RTOを超える
- 監視データを取得できなくなる
- 自動スケールによる追加リソース数が上限を超える
中止を判断する担当者とrun cancelを実行する担当者も決めておくと、実際の障害訓練に近い運用になります。
Action終了後の状態を確認する
Scenarioによっては、終了時にネットワークルールやメッセージングリソースの状態を自動的に戻すものがあります。一方、すべての構成で期待どおりに復旧するとは限りません。
実行後は、Scenario reportだけでなく、VM、データベース、NSG、Service Bus、Event Hubsなどの実際の状態を確認してください。自動復旧を前提にせず、手動復旧手順も準備しておくべきです。(Microsoft Learn)
実行コストと副次的コストを見込む
Azure Chaos Studioは、基本的にActionの実行時間に基づいて課金されます。また、CPU負荷や障害注入によって自動スケールが作動すると、VMやApp Serviceなど別サービスの利用料金が増える可能性があります。
長時間のScenarioを繰り返し実行する前に、Actionの継続時間、対象台数、自動スケール条件を確認してください。(Microsoft Azure)
よくある失敗と対処方法
| 症状 | 主な原因 | 対処 |
|---|---|---|
| 検出リソースが0件 | WorkspaceのIDにReaderがない | 対象スコープへReaderを付与 |
| リソースが一部しか表示されない | 非対応リソース、別リソースグループに存在 | Scenarioの対応リソースと実際の配置を確認 |
| validateが権限不足になる | Action実行用ロールがない | fix-permissions --what-ifで必要ロールを確認 |
| ロール付与後もvalidateに失敗 | RBAC反映待ち | 数分待って再実行 |
| すべてのActionがSkipped | filtersとリソースのリージョン・ゾーンが不一致 | locationsやzonesを確認 |
| AKSのノードが見つからない | VMSSがAKS管理用リソースグループに存在 | Workspaceのスコープを見直す |
| Service Groupで自動権限付与に失敗 | Public Previewの既知の制約 | 配下のサブスクリプションまたはRGへ手動付与 |
| CI/CDの解析が失敗 | table出力を文字列解析している | JSONまたはTSVと--queryを利用 |
| 拡張機能更新後にコマンドが変わった | Preview中の仕様変更 | バージョン固定と回帰テストを実施 |
特に、リソースを検出するためのReaderと、実際に障害を注入するためのAction固有ロールを混同しやすいため注意が必要です。ReaderだけではVM停止やNSG変更は実行できません。(Microsoft Learn)
本番導入を判断するための基準
現時点で導入を進めやすいのは、次の条件を満たすケースです。
- 非本番環境での利用である
- Scenarioカタログに目的の障害パターンがある
- REST APIやJSONスクリプトの保守負担を減らしたい
- CI/CDで実行前検証と結果取得を自動化したい
- WorkspaceのスコープとRBACを限定できる
- CLI拡張機能のバージョン変更を管理できる
- アプリケーション側の監視と中止条件を用意できる
一方、次のケースでは従来型Experimentを維持するか、Workspaceの一般提供を待つ方が安全です。
- 本番環境でのSLAが必要
- 変更管理上、Preview機能を利用できない
- AKS Chaos Meshや動的ターゲティングが必要
- Experimentのスケジュール実行を利用している
- ScenarioカタログにないFaultを細かく組み立てている
- 現行Experimentが安定稼働しており、自動化上の問題もない
今回の更新は、既存ユーザー全員に移行を求めるものではありません。Azure Chaos StudioのCLI自動化を簡単にする新しい選択肢です。
まずは専用の非本番リソースグループを用意し、az chaos setupでWorkspaceを作成してください。その後、検出されたリソースを目視確認し、validateとfix-permissions --what-ifを通してから、短時間・少数リソースのScenarioを実行するのが安全な進め方です。
コメント