Azure Chaos Studioでカオスエンジニアリングを始めたいものの、「実験の組み立て方が分からない」「対象リソースの選定や権限設定が難しい」と感じていた担当者にとって、今回の発表は大きな変更です。2026年7月8日にAzure Updatesで公開・更新された「Azure Chaos Studio Workspaces and Scenarios enter public preview」により、個別の障害アクションを一つずつ設計する方法に加え、アプリケーションの範囲を指定して実障害に近いシナリオを選ぶ方式がパブリックプレビューになりました。(Microsoft Azure)
結論からいえば、新しくレジリエンステストを始める組織は、Workspaces and Scenariosを優先して試す価値があります。一方、既存のChaos Experimentsを急いで移行する必要はありません。従来のExperimentsは引き続きサポートされます。また、現段階はパブリックプレビューであるため、まず非本番環境で権限、対象範囲、復旧判定を検証するのが現実的です。Azure Updatesでもプレビュー機能は、非運用環境での利用とテストを前提としたステータスとして説明されています。(Microsoft Azure)
Azure Chaos StudioのWorkspaces and Scenariosで何が変わるのか
公式ドキュメントの内容を実務の観点から整理すると、主な変更点は次のとおりです。(Microsoft Learn)
| 変更点 | 発表内容 | 実務上の意味 |
|---|---|---|
| Workspaceの追加 | サブスクリプション、リソースグループ、サービスグループをスコープとして指定 | アプリケーションや環境単位でテスト対象をまとめやすくなる |
| リソースの自動検出 | スコープ内の対応リソースを検出し、利用可能なScenarioを提示 | 対象リソースを一つずつ登録する作業を減らせる |
| Scenarioテンプレート | Zone DownやDNS Outageなど、実障害を想定したテストを提供 | 個別Faultではなく、障害パターンからテストを始められる |
| Scenario Designer | テンプレートのAction、順序、パラメーターをポータル上で編集 | 高度なシナリオもスクリプトなしで設計しやすい |
| Scenario report | 実行結果、対象リソース、所要時間、実行フローを記録 | 振り返り、監査、障害対応訓練の証跡として利用できる |
| Bicepによる定義 | Workspace配下のScenarioをAzureリソースとして定義可能 | シナリオのコード管理や環境間での再利用につなげられる |
Workspaceがアプリケーション単位の入口になる
Workspaceは、Azure Chaos Studioにおける新しい上位リソースです。作成時に次のいずれかをスコープとして設定します。
- サブスクリプション
- リソースグループ
- サービスグループ
Chaos Studioはスコープ内の対応リソースを検出し、実行可能なScenarioをライブラリに表示します。リソースを後から追加または削除した場合も検出内容が更新されます。(Microsoft Learn)
Workspaceは、アプリケーション単位、開発・ステージング・本番などの環境単位、チーム単位、コンプライアンス境界単位で分けられます。例えば、一つのリソースグループにアプリケーションの主要コンポーネントをまとめている場合、そのリソースグループをWorkspaceのスコープにすることで、比較的限定された範囲から検証を始められます。
また、Workspaceは論理リソースであり、Workspace自身と対象リソースを同じAzureリージョンに配置する必要はありません。ただし、Workspaceを作成できるリージョンや、各Actionが対象リソースで利用できるかは事前に確認する必要があります。(Microsoft Learn)
Scenarioで障害パターンからテストを始められる
従来のChaos Experimentsでは、Fault、ターゲット、Action、Step、Branchなどを組み合わせて実験を構築します。柔軟性は高い一方で、初めて利用する担当者は「どのFaultを、どの順序で、どのリソースに適用すればよいか」を設計しなければなりませんでした。
Scenarioは、この開始点を変えます。DNS障害、可用性ゾーン障害、データベースフェイルオーバーなど、実際に発生し得る障害パターンを選ぶと、必要なActionや実行順序があらかじめ構成されます。
これにより、「VMを停止させる」こと自体ではなく、次のようなアプリケーション全体の確認に集中できます。
- 別ゾーンへ正常にトラフィックが切り替わるか
- データベース接続がフェイルオーバー後に回復するか
- DNS解決失敗時にリトライが暴走しないか
- 認証基盤に接続できない場合に適切に縮退できるか
- メッセージング停止時にデータを消失しないか
Scenario reportでテストの証跡を残せる
Scenarioの実行後には、次の情報を含むScenario reportを生成できます。
- Scenario名、Workspace名、実行ID
- 実行の開始時刻と終了時刻
- 各Actionの成功、失敗、スキップ
- Actionごとの対象リソースとパラメーター
- Actionの実行タイムライン
- StepやBranchを含む実行フロー
レポートはダウンロードでき、変更管理チケット、障害訓練の記録、事後レビュー、監査資料などに添付できます。(Microsoft Learn)
ただし、Scenario reportが成功しても、アプリケーションのレジリエンスが証明されたとは限りません。レポートが主に示すのは、Chaos StudioのActionがどのように実行されたかです。RTOを満たしたか、ユーザー影響が許容範囲だったか、データが欠損しなかったかは、Azure Monitorやアプリケーション独自のヘルスチェック、ログ、分散トレースと組み合わせて判定する必要があります。公式ドキュメントも、レポートと独自の監視情報を組み合わせるよう案内しています。(Microsoft Learn)
ポータルだけでなくBicepでも定義できる
カスタムScenarioは、AzureポータルのScenario Designerだけでなく、Microsoft.Chaos/workspaces/scenariosリソースとして定義できます。公式ドキュメントでは、プレビューAPIである2026-05-01-previewを使用したBicepの例が公開されています。(Microsoft Learn)
Scenarioには、主に次の要素を定義します。
- 実行するAction
- 実行時間
- 実行時に受け取るパラメーター
- Action同士の依存関係
- 前のActionを待つ条件
- タイムアウトや実行前の待機時間
例えば、特定ゾーンのVMを停止し、その停止処理が開始された後にPostgreSQLのフェイルオーバーを実行する、といった連鎖障害をコードで表現できます。
プレビューAPIは仕様が変わる可能性があるため、現段階では本番CI/CDへ直結させるより、リポジトリ内で検証用テンプレートとして管理するところから始めるのが安全です。
パブリックプレビューで利用できる主なScenario
2026年7月時点の公式Scenarioカタログには、次のようなテンプレートが掲載されています。(Microsoft Learn)
| Scenario | 主な対象 | 確認できること |
|---|---|---|
| DNS Outage | Network Security Group、Virtual Network | DNSキャッシュ、フォールバック、リトライ処理 |
| Microsoft Entra ID Outage | Network Security Group、Virtual Network | 認証失敗、トークン更新失敗、認可処理への波及 |
| Compute Zone Down | Virtual Machines、Virtual Machine Scale Sets | クロスゾーンへの切り替え、負荷分散、復旧時間 |
| Compute Zone Down + PostgreSQL Failover | VM、VMSS、Azure Database for PostgreSQL Flexible Server | ゾーン障害とDBフェイルオーバーが重なった場合の接続回復 |
| Compute Zone Down + SQL Managed Instance Failover | VM、VMSS、Azure SQL Managed Instance | DBフェイルオーバー後の再接続、データ整合性、RTO |
| Cache Stampede | Azure Managed Redis、MySQL Flexible Server、App Service | キャッシュ消失時のDB負荷、バックオフ、負荷制御 |
| Cache Stampede with Process Crash | Azure Managed Redis、MySQL、Windows App Service | キャッシュ消失とアプリプロセス停止が重なった場合の回復 |
| Event-Driven Messaging Disruption | Azure Service Bus、Event Hubs | リトライ、デッドレター、バックプレッシャー、再処理 |
Scenarioは、必要なリソースタイプがWorkspaceのスコープ内に存在するときにライブラリへ表示されます。複数のサービスを組み合わせるScenarioでは、必要なリソースタイプがすべて検出されなければ候補に出ない場合があります。(Microsoft Learn)
また、Scenarioごとに前提条件があります。例えば、Cache Stampede with Process CrashのApp Serviceプロセス停止は、現時点ではWindows App Serviceのみが対象です。PostgreSQLのフェイルオーバーScenarioを試す場合は、高可用性が有効なFlexible Serverが必要です。(Microsoft Learn)
Workspaces and Scenariosと従来のChaos Experimentsの違い
Workspaces and Scenariosは、従来のExperimentsを廃止する機能ではありません。両者は別のモデルとして提供され、既存のExperimentsは引き続き動作します。(Microsoft Learn)
| 比較項目 | Workspaces and Scenarios | Experiments classic |
|---|---|---|
| 設計の開始点 | Zone Downなどの障害パターン | 個別のFaultやAction |
| リソース選択 | スコープ内を検出し、Scenarioを推奨 | ターゲットやSelectorを個別に構成 |
| 権限管理 | WorkspaceのマネージドIDをScenario間で共有 | ExperimentごとにマネージドIDを設定 |
| カスタマイズ | Scenario Designer、Bicep、Actionの依存関係 | Step、Branch、Actionを直接設計 |
| 主な成果物 | 構造化されたScenario report | 実験の実行履歴と詳細 |
| 向いている用途 | 一般的な障害パターンの標準化、定期訓練 | 特殊なFault、細かな対象選択、高度な独自実験 |
新規導入では、まずWorkspaces and Scenariosで代表的な障害パターンを検証し、テンプレートでは表現できないケースにExperimentsを使う構成が分かりやすいでしょう。
既存利用者については、現在のExperimentsを書き換える必要はありません。共通化しやすいゾーン障害やDNS障害だけをScenarioへ移し、特殊な実験は従来モデルに残すという併用も可能です。
利用者と開発者にはどのような影響があるのか
インフラ・SRE担当者はテストを標準化しやすくなる
SREやクラウド運用担当者にとって大きいのは、障害訓練の開始コストが下がることです。
従来は、VM停止、NSG変更、データベースフェイルオーバーなどを個別に設計し、それぞれの実行順序を決める必要がありました。Scenarioを利用すれば、「可用性ゾーン障害を検証する」「DNS停止時の挙動を確認する」という共通の目的から始められます。
チームごとに異なる実験を作るのではなく、共通Scenarioと合否基準を用意することで、複数システムのレジリエンスを同じ観点で比較しやすくなります。
アプリケーション開発者にも確認事項が増える
今回の機能は、インフラ担当者だけのものではありません。障害発生時に問題となるのは、Azureリソースの復旧だけではなく、アプリケーションコードの挙動です。
開発者は、少なくとも次の処理を確認する必要があります。
- 指数バックオフを含む適切なリトライ
- リトライ回数やタイムアウトの上限
- DBフェイルオーバー後のコネクションプール再作成
- 二重送信に耐える冪等性
- メッセージの再処理と順序保証
- キャッシュ消失時のリクエスト集約
- 認証サービス停止時の縮退動作
- 障害中のユーザー向けエラー表示
例えば、PostgreSQL自体が数分でフェイルオーバーしても、アプリケーションが切断済みのコネクションを保持し続ければサービスは回復しません。Workspaces and Scenariosは、こうした「インフラは復旧したが、アプリは復旧しない」という問題を見つけるために利用できます。(Microsoft Azure)
管理者や監査担当者は実行証跡を確認しやすくなる
Scenario reportにより、「いつ、どの障害を、どのリソースに対して実行したか」を残しやすくなります。
ただし、レポートだけを監査証跡として提出するのではなく、次の情報も組み合わせるべきです。
- テストの承認記録
- 事前に定義した合否基準
- Azure Monitorのメトリック
- アプリケーションログ
- RTOやRPOの実測結果
- 発見した問題と修正内容
- 再テストの結果
なお、ダウンロードしたScenario reportにはAzureリソース名や識別子が含まれます。組織外へ共有する場合は、機密情報や構成情報が含まれていないか確認してください。(Microsoft Learn)
対応が必要かを判断する基準
| 現在の状況 | 対応優先度 | 推奨対応 |
|---|---|---|
| ゾーン冗長やDB高可用性を採用しているが、実障害テストをしていない | 高 | 非本番でWorkspaceを作成し、Zone Down系Scenarioを試す |
| Service BusやEvent Hubsを使う重要システムがある | 高 | メッセージ停止時の再処理、デッドレター、バックプレッシャーを検証 |
| 監査やBCPで定期的な障害訓練の証跡が必要 | 高 | Scenario reportと独自の監視結果を組み合わせる運用を設計 |
| 既存のChaos Experimentsを安定運用している | 中 | 移行せず、標準化できる実験だけScenarioとの重複を評価 |
| 対応Scenarioに必要なリソースがそろっていない | 中 | カスタムScenarioまたは従来のExperimentを検討 |
| すぐに本番環境の自動テストへ組み込みたい | 要注意 | パブリックプレビューのため、非本番検証と社内承認を先行 |
| Azure上に重要な分散システムを持っていない | 低 | GAやScenario追加の情報を継続確認 |
特に、冗長構成を採用しただけで「障害に強い」と判断している組織は、優先的に検証すべきです。冗長化が正しく動くかどうかは、ロードバランサーのヘルスプローブ、接続先設定、リトライ実装、データ整合性など、複数の構成に左右されます。
Workspaces and Scenariosを試す手順
検証対象と障害仮説を一つに絞る
最初からサブスクリプション全体を対象にするのではなく、一つの非本番アプリケーションを選びます。
そのうえで、次のように障害仮説を明文化します。
可用性ゾーン1のコンピュートが停止しても、APIは10分以内に回復し、処理中のメッセージを失わない。
「Zone Downを実行する」だけでは、成功条件が分かりません。障害を注入する前に、何を確認するテストなのかを定義することが重要です。
非本番のリソースグループをスコープにする
AzureポータルでChaos Studioを開き、Workspaceを作成します。事前にサブスクリプションへMicrosoft.Chaosリソースプロバイダーを登録しておく必要があります。(Microsoft Learn)
初回はサブスクリプション全体ではなく、検証対象だけを含むリソースグループをスコープにするのが安全です。
マネージドIDへ必要最小限の権限を設定する
Workspaceは、システム割り当てまたはユーザー割り当てのマネージドIDを使用してActionを実行します。
権限は二段階で確認されます。
- Scenarioを開始する利用者が、Workspaceを操作できること
- WorkspaceのマネージドIDが、対象リソースを変更できること
例えば、VM操作にはVirtual Machine Contributor、NSG操作にはNetwork Contributor、データベースフェイルオーバーには対象リソースへのContributor権限などが必要です。権限が不足すると、Scenario自体は開始されても該当Actionが失敗する場合があります。(Microsoft Learn)
安全性を高めるには、次の3層を分けて設計します。
| 制御レイヤー | 役割 | 推奨設定 |
|---|---|---|
| Workspaceのスコープ | 検出・選択できるリソースの範囲 | 初回は非本番の単一リソースグループ |
| マネージドIDのRBAC | 実際に変更できるリソースの範囲 | 対象リソースだけに必要最小限のロールを付与 |
| Scenarioの除外設定 | 今回の実行から保護するリソース | 踏み台、共有DB、管理用VMなどを除外 |
Scenarioの除外設定は誤操作防止には役立ちますが、セキュリティ境界の代わりにはなりません。最終的な影響範囲は、マネージドIDへ付与したRBACで制限するべきです。(Microsoft Learn)
合否判定に使うメトリックを決める
テスト前に、Azure Monitorやアプリケーション監視で確認する指標を決めます。
例として、次のような基準が考えられます。
- 5xxエラー率が事前に決めた上限を超えない
- RTO以内に正常応答率が回復する
- 処理中メッセージの消失がない
- デッドレター件数が許容範囲内である
- DBフェイルオーバー後に接続数が正常化する
- キャッシュ消失後もDBのCPUや接続数が上限を超えない
- 認証障害時にリトライが無制限に増加しない
数値はシステムごとに異なります。Azureの復旧完了だけでなく、ユーザーが利用できる状態へ戻った時点を基準にしてください。
Scenarioを実行してレポートと監視結果を比較する
WorkspaceのScenarioライブラリから対象を選び、必要なゾーン、実行時間、除外リソースなどを設定します。実行中は、Chaos StudioのAction状態だけでなく、アプリケーション側のメトリックとログも監視します。
終了後はScenario reportを生成し、次の観点で振り返ります。
- 予定したActionがすべて実行されたか
- 権限不足による失敗がなかったか
- 復旧時間は目標以内だったか
- データ欠損や二重処理がなかったか
- アラートが想定どおり発報したか
- 運用担当者が異常を認識できたか
- 手順書どおりに対応できたか
問題を修正した後、同じScenarioを再実行します。1回成功しただけで完了にせず、構成変更やアプリケーション更新後も再現できる状態にすることが重要です。
導入時に失敗しやすいポイント
いきなりサブスクリプション全体をスコープにする
自動検出が便利だからといって、初回から広いスコープを設定すると、意図しないリソースがScenario候補に含まれる可能性があります。
特に共有サブスクリプションでは、別チームのリソース、管理用VM、共通ネットワーク、共有データベースを巻き込まないよう注意が必要です。
最初は次の構成が安全です。
- 非本番専用のリソースグループ
- 環境ごとに分けたWorkspace
- 環境ごとに分けたユーザー割り当てマネージドID
- 本番と非本番で異なるRBAC
- Scenarioごとの除外リソース
Scenarioの成功だけを合格とする
ActionのステータスがSucceededでも、ユーザー視点では長時間停止していた可能性があります。
例えば、VMの停止と再起動に成功しても、ロードバランサーが正常なインスタンスへ切り替えられなければアプリケーションは停止したままです。Scenario reportとアプリケーションのSLOを必ず分けて評価してください。
自動ロール割り当てを無条件で利用する
Workspace作成時には、必要なRBACロールを自動割り当てするオプションがあります。小規模な検証では便利ですが、権限管理が厳格な組織では、どのリソースへ何の権限が付与されるかを確認してから利用すべきです。(Microsoft Learn)
本番相当環境では、カスタムロールやリソース単位の割り当ても検討し、サブスクリプション全体へのContributor付与は避けるのが基本です。
料金と周辺サービスのコストを見落とす
現行のAzure Chaos Studio価格ページでは、実験Actionの実行時間に応じたaction-minute単位の従量課金が案内されています。また、障害によってオートスケールが発生すると、追加されたVMやApp Serviceなど別サービスの料金も増える可能性があります。(Microsoft Azure)
Workspaces and Scenariosのプレビュー利用前には、次の項目を確認してください。
- Chaos Studio自体の課金条件
- 対象リージョンの料金
- オートスケールによる追加リソース
- Azure Monitorのログ取り込み量
- テスト用環境の稼働時間
- 契約プランにおけるプレビュー条件
Microsoftの事業戦略上の狙い
今回の発表は、単なるAzureポータルの操作改善ではありません。Azure Chaos Studioを、専門家が個別Faultを組み立てるツールから、アプリケーションチームが定期的にレジリエンスを検証するプラットフォームへ広げる動きと考えられます。
障害注入からレジリエンス検証へ軸を移している
従来は「VMを止める」「CPU負荷を上げる」といったFaultが中心でした。Workspaces and Scenariosでは、「ゾーン障害から回復できるか」「認証基盤停止時にサービスを維持できるか」という業務上の問いから始められます。
これは、カオスエンジニアリングの導入障壁を下げ、SREだけでなく開発者、運用責任者、監査担当者にも利用範囲を広げる方向です。
実行結果を組織的な証拠に変えようとしている
Scenario reportが標準で用意されたことも重要です。
障害訓練が一度限りの技術検証で終わると、経営層や監査部門は成果を確認できません。定期的なレポートとして残せれば、レジリエンス改善の進捗、BCP訓練、変更管理の証跡として扱いやすくなります。
AIを利用した運用自動化を見据えている
Microsoftは関連発表として、GitHub Copilot CLI向けのChaos Studio Skillと、外部エージェントからChaos Studioを操作するMCPサーバーも案内しています。Workspaceの作成、Scenarioの選択、実行、結果分析を会話型インターフェースや自律エージェントから行う構想です。(Microsoft Azure)
この流れからは、将来的にChaos Studioを次のような運用へ組み込む狙いが読み取れます。
- デプロイ後の自動レジリエンステスト
- SREエージェントによる障害仮説の検証
- インシデント修正後の自動再現テスト
- Azure Monitorの異常とScenario結果の相関分析
- 継続的なレジリエンス評価
ただし、自律エージェントに障害注入を任せる場合でも、承認フロー、対象範囲、実行時間帯、停止条件を人間側で厳格に管理する必要があります。
今後注目すべきポイント
GAの時期とサポート条件
Microsoftの公式ブログでは、一般提供を2026年後半に目標としているものの、予定は変更される可能性があると説明しています。(Microsoft Azure)
GAまでに確認したいのは、次の項目です。
- SLAと正式なサポート範囲
- 課金体系
- 利用可能リージョン
- Scenario reportの保存期間
- RBACとカスタムロール
- Azure Policyへの対応
- CI/CDからの実行方法
- APIバージョンの安定化
Scenarioカタログの拡充
公式ブログでは、ストレージアカウントのフェイルオーバー、Front DoorやApplication Gateway、部分的なゾーン劣化、AKSネイティブのPod障害、利用者が観測するリージョン障害などが今後の候補として挙げられています。これらは現時点で提供を保証された機能ではなく、検討中の方向性として捉える必要があります。(Microsoft Azure)
AIアプリケーション向けには、検索結果のドリフト、トークン制限、負荷によるモデル挙動の変化など、従来のインフラ障害とは異なるScenarioも検討されています。
WorkspacesとExperimentsの使い分け
GA後も、すべての実験がWorkspacesへ統合されるとは限りません。
一般的な障害パターンはScenario、特殊なFaultや細かなターゲット制御はExperimentsという使い分けが続く可能性があります。既存利用者は、移行計画を作るより先に、現在の実験を次の2種類へ分類するとよいでしょう。
- 標準Scenarioで置き換えられる実験
- 独自要件がありExperimentsに残す実験
対応判断の結論と次にやること
Azure Chaos Studio Workspaces and Scenariosのパブリックプレビューは、カオスエンジニアリングを「個別Faultの設計」から「実障害パターンの検証」へ近づけるアップデートです。
新規利用者、ミッションクリティカルなAzureシステムを運用する組織、障害訓練の証跡を必要とする組織は、早めに非本番環境で評価する価値があります。一方、既存のChaos Experimentsは引き続きサポートされるため、今回の発表だけを理由に移行する必要はありません。
最初の一歩として、次の流れで1件だけ検証してください。
- 非本番の一つのリソースグループを選ぶ
- 障害仮説とRTOなどの合否基準を決める
- 必要最小限のRBACでWorkspaceを作る
- Zone DownまたはDNS Outageを選ぶ
- 保護するリソースを除外する
- Azure Monitorとアプリケーションログを監視しながら実行する
- Scenario reportと実測値を比較する
- 問題を修正し、同じScenarioを再実行する
この一連の流れを再現できてから、対象システムの追加、Bicepによるコード化、CI/CDや定期訓練への組み込みを検討するのが安全です。
コメント