2026年7月8日、日本時間で公開が確認されたMicrosoft Azureの更新により、Azure Chaos Studioの「Workspaces and Scenarios」がPublic Previewになりました。結論からいうと、障害注入テストを個々のリソースやFaultから組み立てる従来方式に加え、アプリケーション単位のWorkspaceと、実際の障害パターンを表すScenarioを起点にテストできる新しいモデルが追加された形です。既存のChaos Experimentsは引き続き利用できるため、緊急の移行作業は必要ありません。(Microsoft Azure)
対応優先度が高いのは、Azure上で重要システムを運用しているSRE、クラウド基盤担当者、BCP・監査対応の責任者です。ただし、Azure Updatesにおける「In preview」は、原則として非運用環境での使用とテストを想定した段階です。まずは本番環境へ導入するのではなく、検証環境でWorkspaceのスコープ、権限、Scenarioの対象リソースを確認するのが適切です。(Microsoft Azure)
Azure Chaos Studio Workspaces and Scenariosで何が変わるのか
Azure Chaos Studioは、仮想マシンの停止、データベースのフェイルオーバー、DNS通信の遮断など、制御された障害をAzureリソースへ発生させ、アプリケーションの回復性を検証するサービスです。
今回のWorkspaces and Scenariosでは、テストの出発点が「どのFaultを実行するか」から「どの障害シナリオを検証するか」へ変わります。
| 新しい要素 | 役割 | 実務上の変化 |
|---|---|---|
| Workspace | テスト対象となるAzure環境を、サブスクリプション、リソースグループ、Service Groupのいずれかで定義する | アプリケーションや環境単位でテスト範囲を管理しやすくなる |
| Scenario | 複数のActionを組み合わせた、事前構成済みの障害テスト | Zone障害やDNS障害などを、個別に組み立てず実行できる |
| Scenario Library | Workspace内で発見したリソースから、実行可能なScenarioを提示する | 利用可能なテストを探す作業が減る |
| Scenario Designer | テンプレートのAction、順序、パラメーターを編集する | 標準Scenarioを自社構成に合わせて拡張できる |
| Managed Identity | ScenarioのActionを対象リソースへ実行する | 個人の資格情報ではなく、Azure RBACで影響範囲を制御できる |
| Scenario Report | 実行結果、Actionの状態、所要時間、タイムライン、実行フローを記録する | Game Day、障害振り返り、監査証跡に利用しやすくなる |
Workspaceはスコープ内のリソースを自動的に発見します。リソースが追加・削除された場合も変更を取り込み、現在の構成に適用できるScenarioを提示します。また、Workspace自体と対象リソースを同じAzureリージョンに配置する必要はありません。ただし、Workspaceリソースの作成先は、その時点でサポートされているリージョンから選ぶ必要があります。(Microsoft Learn)
重要なのは、単にAzure Portalの操作が簡単になっただけではない点です。複数のリソースにまたがる障害を「アプリケーションの障害パターン」として扱えるため、カオスエンジニアリングを特定の担当者だけが使う専門ツールから、開発・運用プロセスへ組み込みやすい仕組みに変えています。
従来のChaos Experimentsとの違い
Workspaces and Scenariosは、従来のExperimentsを置き換えるアップグレードではなく、別のリソースモデルです。
| 比較項目 | Workspaces and Scenarios | Experiments（クラシック） |
|---|---|---|
| テストの起点 | Zone停止、DNS障害などの障害パターン | Fault、Target、Capability |
| 対象リソース | Workspaceのスコープから自動発見 | TargetやCapabilityを個別に設定 |
| オーケストレーション | ScenarioテンプレートまたはScenario Designer | Step、Branch、Actionを直接構成 |
| Managed Identity | Workspace内のScenarioで共有 | Experimentごとに設定 |
| リージョン | Workspaceと対象リソースを別リージョンに配置可能 | TargetやCapabilityは対象リソースに関連付けて管理 |
| 主な用途 | 標準的な障害パターンを短時間で反復検証 | Faultや実行順序を細かく制御するテスト |
| 既存資産への影響 | 新規モデルとして追加 | 既存Experimentはそのまま継続可能 |
Microsoftは、新たに回復性テストを始める場合、まずWorkspaces and Scenariosを利用する方針を示しています。一方、既存Experimentは引き続きサポートされ、動作も変わりません。そのため、安定稼働している既存テストを急いで作り直す必要はありません。(Microsoft Learn)
実務では、標準的な障害パターンはScenarioへ寄せ、特殊なFaultや細かな実行制御が必要な既存テストはExperimentsに残す、という段階的な使い分けが現実的です。
Public Previewで利用できる主なScenario
Public Preview開始時点では、ネットワーク、可用性ゾーン、データベース、キャッシュ、メッセージングに関するScenarioテンプレートが用意されています。
| カテゴリー | Scenario | 検証できる内容 |
|---|---|---|
| ネットワーク | DNS Outage | NSGルールで送信先ポート53を遮断し、DNSキャッシュ、再試行、フォールバックを検証する |
| ID基盤 | Microsoft Entra ID Outage | Microsoft Entra IDエンドポイントへの通信を遮断し、認証失敗やトークン更新失敗への耐性を確認する |
| 可用性ゾーン | Compute Zone Down | 指定ゾーンのVMとVirtual Machine Scale Setsを停止し、ゾーン障害時の切り替えを検証する |
| ゾーン・DB | Compute Zone Down + PostgreSQL Failover | Compute Zone DownにPostgreSQL Flexible Serverのフェイルオーバーを組み合わせる |
| ゾーン・DB | Compute Zone Down + SQL Managed Instance Failover | Compute Zone DownにAzure SQL Managed Instanceのフェイルオーバーを組み合わせる |
| キャッシュ | Cache Stampede | Azure Managed Redisのフラッシュと、MySQL Flexible Server、App Serviceの再起動を組み合わせる |
| キャッシュ | Cache Stampede with Process Crash | App Serviceのプロセス停止を加えて、キャッシュとアプリケーションが同時に失敗する状況を作る |
| メッセージング | Event-Driven Messaging Disruption | Service BusキューやEvent Hubsエンティティを無効化し、再試行、デッドレター、バックプレッシャーを検証する |
Cache Stampede with Process Crashは、Public Preview時点ではWindows App Serviceが対象です。また、Event-Driven Messaging Disruptionでは、実行終了後に対象のService BusキューやEvent Hubsエンティティが再度有効化されます。(Microsoft Learn)
複数のリソース種別を使うScenarioは、必要なすべてのリソースがWorkspaceのスコープ内に存在する場合にライブラリへ表示されます。たとえば、Compute Zone Down + PostgreSQL Failoverを使うには、対象範囲内にVMまたはVirtual Machine Scale Setsと、PostgreSQL Flexible Serverが必要です。
Scenarioが表示されない場合は、サービスが未対応だと判断する前に、次の項目を確認してください。
- 対象リソースがWorkspaceのスコープ内にあるか
- 複合Scenarioに必要なリソース種別がすべて存在するか
- リソースがScenario固有の前提条件を満たしているか
- Scenarioの推奨状態が最新のリソース構成へ更新されているか
利用者・開発者への影響
SRE・クラウド運用担当者はGame Dayを標準化しやすくなる
従来は「VMを停止する」「データベースをフェイルオーバーする」といった個々の操作を組み合わせ、テスト対象も手動で管理する必要がありました。
Workspaces and Scenariosでは、アプリケーション単位でスコープを作り、Zone DownやDNS OutageなどのScenarioを選択できます。構成の異なる複数環境でも、同じ障害仮説と成功基準を使ってテストしやすくなります。
一方、自動検出されたリソースによって利用可能なScenarioが変化する点には注意が必要です。Workspaceを作成した時点の構成だけで安全性を判断せず、インフラ変更後に対象リソースと除外設定を再確認する運用が必要です。
アプリケーション開発者は回復処理を具体的に検証できる
各Scenarioは、アプリケーションコードで確認すべき項目と直結しています。
- DNS Outageでは、タイムアウト、DNSキャッシュ、代替エンドポイントを確認する
- Microsoft Entra ID Outageでは、アクセストークンのキャッシュと更新失敗時の動作を確認する
- データベースのフェイルオーバーでは、接続プールの再確立、再試行、処理の冪等性を確認する
- Cache Stampedeでは、リクエストの集約、指数バックオフ、負荷制限を確認する
- メッセージング障害では、デッドレター、再試行回数、コンシューマー停止時の滞留を確認する
Scenarioの「Succeeded」は、障害注入のActionが正常に完了したことを示します。アプリケーションが正常に回復したことまで自動的に保証するものではありません。Azure Monitorのメトリック、アプリケーションログ、外形監視、RTOやSLOの測定結果と組み合わせて判断する必要があります。(Microsoft Learn)
カスタムScenarioをコードとして管理できる
標準テンプレートで不足する場合は、Scenario DesignerでAction、パラメーター、依存関係を変更できます。Actionは並列または順次に実行でき、特定のActionが開始・成功・失敗した後に次のActionを動かす構成も可能です。
カスタムScenarioは、Microsoft.Chaos/workspaces/scenariosリソースとしてBicepなどから定義できます。公開時点のドキュメントでは、2026-05-01-previewのAPIバージョンが使用されています。IaCへ組み込める一方、Preview APIであるため、スキーマ変更を想定して本番パイプラインとの密結合は避けるべきです。(Microsoft Learn)
Managed Identityの設計がより重要になる
WorkspaceのManaged Identityが、すべてのScenarioのActionを実行します。ユーザーがScenarioを開始できる権限と、Managed Identityが対象リソースを操作できる権限は分離されています。
この二段階の認可により、次の両方を満たした場合にだけ障害が注入されます。
- ユーザーがWorkspace上でScenarioを実行できる
- WorkspaceのManaged Identityが対象リソースを操作できる
代表的なActionと必要なロールの例は次のとおりです。
| Actionの種類 | Managed Identityに必要となる代表的なロール |
|---|---|
| VMの停止、再起動、再デプロイ | Virtual Machine Contributor |
| NSGルールの変更 | Network Contributor |
| SQL、PostgreSQL、MySQLのフェイルオーバー | Contributor |
| Cosmos DBのフェイルオーバー | Cosmos DB Operator |
必要なロールが不足している場合、Scenario全体が開始されても、該当Actionは権限エラーで失敗します。反対に、サブスクリプション全体へ過大な権限を与えると、Workspaceのスコープ設定ミスが大きな障害につながります。自動ロール割り当てを使う場合も、作成後に付与範囲を確認してください。(Microsoft Learn)
対応要否を判断する基準
| 現在の状況 | 対応優先度 | 推奨する行動 |
|---|---|---|
| Azure上で複数リソースからなる重要システムを運用している | 高い | 非本番でWorkspaceを作り、Zone、DNS、ID障害のいずれかを検証する |
| Game DayやBCP訓練を手作業で実施している | 高い | ScenarioとReportで手順と証跡を標準化できるか評価する |
| 監査で回復性テストの実施記録を求められる | 高い | Scenario Reportと自社監視データを組み合わせた証跡方法を設計する |
| 既存のChaos Experimentsが安定稼働している | 中程度 | 既存テストは維持し、新規テストのみWorkspaceで比較する |
| 必要なリソースや障害パターンがScenarioにない | 中程度 | Experimentsを継続し、Scenarioカタログの拡充を監視する |
| Azure Chaos Studioを利用しておらず、重要ワークロードもない | 低い | 即時対応は不要。GAや対象サービス拡大を確認する |
既存ユーザーにとっては「移行対応」ではなく「新しい作り方の評価」です。新規ユーザーにとっては、従来よりもカオスエンジニアリングを始めやすい入口になります。
導入前に確認すべきポイント
| 確認項目 | 合格と判断できる状態 | 失敗しやすいポイント |
|---|---|---|
| 実行環境 | 非本番または影響を許容できる専用環境 | Public Previewを理由なく本番へ直接適用する |
| Workspaceのスコープ | 1つのアプリケーションや環境に限定されている | 最初からサブスクリプション全体を指定する |
| Managed Identity | 必要なリソースへ必要最小限のロールを付与している | リソースグループやサブスクリプションへ一律Contributorを付与する |
| Scenarioの前提条件 | 対象リソース、HA構成、OSなどの条件を確認済み | ライブラリに表示されたことだけで実行可能と判断する |
| 成功基準 | RTO、エラー率、再試行時間、キュー滞留量などが数値化されている | ScenarioのSucceededだけで成功と判断する |
| 除外設定 | 共有DB、管理用VM、踏み台などを必要に応じて除外している | スコープ内の全リソースへ一律にActionを実行する |
| 実行管理 | 実行責任者、停止判断、連絡先、復旧手順を決めている | ポータルの反応が遅いときにRunを再押下する |
| Reportの扱い | 保存先と閲覧権限を決めている | リソース名や識別子を含むReportを社外へそのまま共有する |
Scenario ReportでActionが「Skipped」になっていても、Scenario全体は成功扱いになる場合があります。対象外のリソースがスキップされたのであれば問題ありません。しかし、本来テストする予定だったリソースがSkippedの場合、その結果を有効な回復性テストとして扱うべきではありません。スコープ、リソース種別、リージョン、前提条件を再確認してください。(Microsoft Learn)
また、公式のPostgreSQL向けチュートリアルでは、Runを押した後に画面が切り替わらなくても再度実行しないよう注意されています。処理はすでにキューへ投入されている可能性があり、二重実行によって対象リソースへの影響が重なるためです。(Microsoft Learn)
非本番環境で試す最短手順
- 障害仮説を1つ決める
「可用性ゾーンが停止しても、5分以内にサービスが復旧する」など、検証したい内容を1文で定義します。 - 成功基準を数値で決める
RTO、HTTPエラー率、キュー滞留量、データベース再接続時間、アラート発報時間などを決めます。 - Microsoft.Chaosリソースプロバイダーを登録する
初めてChaos Studioを使うサブスクリプションでは、事前登録が必要です。 - Workspaceを作成する
最初の検証では、サブスクリプション全体ではなく、対象アプリケーションを含むリソースグループをスコープにするのが安全です。 - Managed IdentityとRBACを設定する
小規模な検証ではシステム割り当てID、複数Workspaceで権限を共通化する場合はユーザー割り当てIDを検討します。 - Scenarioを選び、対象と除外リソースを確認する
最初はDNS Outageや限定的なCompute Zone Downなど、影響を予測しやすいScenarioから始めます。 - 監視画面を開いた状態で実行する
Scenarioの実行画面だけでなく、Azure Monitor、Application Insights、アプリケーションのヘルスチェックを同時に確認します。 - Reportと監視データを照合する
Actionが成功した時刻と、エラー率上昇、フェイルオーバー、復旧時刻を比較します。問題が見つかった場合は修正後に同じScenarioを再実行します。
公式Quickstartでも、Workspaceの作成、スコープ設定、Managed Identityの設定、Scenarioの選択、実行、Report確認という順序が示されています。(Microsoft Learn)
事業戦略上の背景
公式の機能構成から読み取れるのは、MicrosoftがAzure Chaos Studioを、単発のFault注入サービスから継続的なレジリエンス検証基盤へ広げようとしていることです。
第一に、Workspaceをアプリケーション、環境、チーム、コンプライアンス境界ごとに分けられるようにしています。さらに、Service Groupを使えば、複数サブスクリプションにまたがるアプリケーションも1つのテスト境界として扱えます。これは、Azureリソースの配置ではなく、事業サービス単位で回復性を管理する企業を意識した設計です。(Microsoft Learn)
第二に、Scenario Reportが重視されています。Reportには実行対象、Actionの結果、所要時間、タイムライン、実行フローが記録されます。Microsoftは、その用途として運用証跡、障害振り返り、DORAなどの運用レジリエンス要件への対応を挙げています。単に障害を発生させるだけでなく、「定期的にテストしたことを説明できる状態」を製品価値に含めている点が特徴です。(Microsoft Learn)
第三に、Scenario Designer、Bicepリソース、REST APIが用意されています。公式概要では、CI/CDパイプラインのデプロイゲートとして回復性テストを実行する用途も示されています。将来的には、セキュリティテストや性能テストと同様に、レジリエンステストをリリース工程へ組み込む「Resilience as Code」が進む可能性があります。(Microsoft Learn)
今後の注目点
GA時期と本番利用条件
Public Previewでは、仕様変更、サポート条件、SLA、利用可能リージョンがGA時に変わる可能性があります。本番利用を判断する際は、GAの発表だけでなく、Preview利用条件とサポート範囲も確認する必要があります。
Scenarioカタログと対象サービスの拡充
現在のScenarioは、Zone、DNS、Microsoft Entra ID、データベース、キャッシュ、メッセージングが中心です。AKS、ストレージ、API Management、複数リージョン構成など、企業システムで利用頻度の高い構成が標準Scenarioへ追加されるかが注目点です。
Preview APIの安定化
カスタムScenarioのAPIは2026-05-01-previewです。APIバージョン、Bicepスキーマ、SDKの互換性が安定するまでは、ラッパースクリプトやモジュールを用意し、変更の影響を局所化すると安全です。
Reportの自動収集と監査運用
現状でもReportの閲覧とダウンロードが可能ですが、大規模運用では、保存期間、APIによる一括取得、チケットや監査基盤との連携方法が重要になります。ReportにはAzureリソースの名前や識別子が含まれるため、保存先と共有範囲も設計対象です。(Microsoft Learn)
課金体系
Azure Chaos Studioの価格ページでは、Chaos engineering experimentのAction実行時間に基づく課金が案内されています。Workspaces and Scenariosを多数の環境やCI/CDで反復実行する場合は、Public Preview時点の課金単位と、対象リソース側で発生する費用を事前に確認してください。(Microsoft Azure)
まとめ
Azure Chaos Studio Workspaces and ScenariosのPublic Previewは、障害注入テストをアプリケーション単位で設計し、標準Scenarioとして反復実行できるようにする更新です。自動リソース検出、Managed Identityによる影響範囲の制御、Scenario Reportによる証跡作成が主な強化点です。
既存のChaos Experimentsは継続利用できるため、移行を急ぐ必要はありません。一方、重要なAzureワークロードを運用している組織は、GAを待って情報収集するだけでなく、非本番環境で操作性と権限モデルを確認しておく価値があります。
最初の行動としては、対象を1つの非本番アプリケーションに限定し、リソースグループ単位のWorkspaceを作成してください。Managed Identityへ必要最小限の権限を付与し、1つのScenarioを、明確なRTOやエラー率の基準とともに実行します。Scenario Reportと実際の監視データを照合するところまで行えば、自社に導入すべきかを具体的に判断できます。
コメント