Azure Infrastructure Resiliency Manager（プレビュー）は、Azure上のアプリケーションの回復性を「設計する」「評価する」「改善する」「訓練で検証する」ための統合体験です。結論から言うと、既存のAzureリソースを自動で移行・変更する新サービスではなく、Availability Zones、Azure Advisor、Azure Chaos Studio、Azure Monitor、Azure Copilotなどを横断し、アプリケーション単位で回復性の弱点を見つけて改善しやすくする管理レイヤーと考えると分かりやすいです。Microsoftは2026年6月にPublic Previewとして案内しており、プレビュー段階では本番適用を急ぐより、重要ワークロードの現状把握と非本番環境での検証から始めるのが現実的です。(マイクロソフト Azure)
Azure Infrastructure Resiliency Managerとは
Azure Infrastructure Resiliency Managerは、Azureで稼働するアプリケーションの回復性目標を定義し、現状を評価し、不足している構成を改善するためのセルフサービス型の管理機能です。Microsoft Learnでは、アプリケーションの回復性目標の設定、詳細な推奨事項の取得、Azure環境全体のレジリエンス体制の確認、シミュレートされた停止訓練、復旧計画によるゾーン停止からの復旧ができると説明されています。(Microsoft Learn)
ここでいう「回復性」は、単にバックアップを取ることではありません。たとえば、1つの可用性ゾーンに障害が起きてもアプリケーションを継続できるか、データベースやロードバランサーがゾーン冗長に対応しているか、フェールオーバー手順が実際に動くか、といった実運用上の耐障害性を指します。
これまでAzureの回復性対策は、Azure Advisorで推奨事項を確認し、Azure Monitorで監視し、Azure Chaos Studioで障害注入テストを行い、各サービスの可用性ゾーン設定を個別に確認する、という形になりがちでした。Azure Infrastructure Resiliency Managerは、これらをアプリケーション単位の目標に結び付け、改善アクションまでつなげる点が大きな変化です。Microsoftの発表でも、個別の回復性機能を置き換えるものではなく、Availability Zones、Azure Advisor、Azure Chaos Studio、Azure Monitor、Azure Copilotを補完し、目標駆動型のワークフローにまとめるレイヤーとして説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
何が変わるのか
今回のPublic Previewで重要なのは、「リソース単位のチェック」から「アプリケーション単位の回復性管理」へ視点を移しやすくなることです。
従来は、仮想マシン、データベース、AKS、ロードバランサー、ストレージなどを個別に確認し、それぞれの設定が可用性ゾーンやフェールオーバー要件を満たしているかを管理者が判断する必要がありました。Azure Infrastructure Resiliency Managerでは、複数のサブスクリプションやリソースグループにまたがるAzureリソースをサービスグループとしてまとめ、そこにゾーン回復性の目標を割り当てて評価できます。(Microsoft Learn)
| 観点 | 従来の確認方法 | Azure Infrastructure Resiliency Managerでの変化 |
|---|---|---|
| 評価単位 | VM、DB、ネットワークなど個別リソース中心 | サービスグループを使い、アプリケーションやワークロード単位で評価 |
| 推奨事項 | Azure Advisorなどで個別に確認 | 目標を満たしていないリソースに対して、文脈付きの推奨事項を確認 |
| 設計支援 | アーキテクトや運用担当者が手動でレビュー | Resiliency Agentにより、自然言語で設計改善やIaCテンプレート生成を支援 |
| 検証 | 個別にテスト計画や障害注入を設計 | 可用性ゾーン停止ドリルで、ゾーン障害を想定した訓練を実施 |
| 運用判断 | 監視、推奨、復旧手順が分散 | 回復性の状態、推奨事項、ドリル、復旧計画を同じ流れで扱える |
特に大きいのは、Azure Advisorの推奨事項を「見て終わり」にしにくくなる点です。Infrastructure Resiliency Managerでは、目標を満たさないリソースに対して、影響を受けるリソース、推奨理由、ステップバイステップの修復ガイダンス、利用可能な場合はコスト影響も確認できます。(Microsoft Learn)
対象者と影響範囲
影響が大きいのは、Azure上で業務アプリケーションや顧客向けサービスを運用しているチームです。特に、可用性ゾーン、DR、BCP、SRE、運用監視、IaCを扱う担当者は早めに確認しておく価値があります。
Azure管理者・SREが確認すべきこと
Azure管理者やSREにとっては、重要ワークロードの回復性を一覧で把握しやすくなる点が実務上のメリットです。Microsoft Learnでは、Resiliencyダッシュボードからリソースの回復性、サービスグループの回復性、推奨事項、復旧計画、ドリル、使用状況プランなどのメニューを確認できるとされています。(Microsoft Learn)
まず見るべきなのは、全リソースを一気に改善することではありません。優先度の高いアプリケーションを1つ選び、次の順で確認すると失敗しにくくなります。
| 確認項目 | 見るべきポイント |
|---|---|
| サービスグループ | アプリケーションを構成するVM、DB、LB、AKS、ネットワークなどが正しく含まれているか |
| 回復性目標 | まずはゾーン障害に耐える必要があるかを業務要件から判断する |
| 非回復性リソース | 単一ゾーン、単一インスタンス、非冗長構成になっている重要リソースがないか |
| 未評価リソース | サポート対象外、除外、カスタム構成のため評価されていないリソースがないか |
| 推奨事項 | コスト、停止時間、再デプロイ要否を見て、対応順を決める |
開発者・DevOps担当者が確認すべきこと
開発者やDevOps担当者にとって重要なのは、Resiliency AgentとIaC連携です。Resiliency AgentはAzure Copilotに統合された会話型AI体験で、アプリケーションの回復性改善をガイドします。新規アプリケーションでは自然言語で構成を説明して改善提案を受けたり、ARM、Bicep、TerraformのIaCテンプレートを生成したりできます。既存アプリケーションでは、リソース一覧を渡してサービスグループを作成し、目標設定、評価、修復ガイダンスを受けられます。(Microsoft Learn)
ただし、生成されたテンプレートをそのまま本番に適用するのは危険です。AIが提案する構成は、社内の命名規則、ネットワーク分離、セキュリティポリシー、SKU制約、リージョン制約、予算上限まで完全に理解しているとは限りません。IaCのレビューでは、少なくとも次の点を確認してください。
| 確認ポイント | 具体例 |
|---|---|
| 可用性ゾーン指定 | VM、VMSS、AKSノードプール、DBが想定ゾーンに分散されているか |
| SKUとリージョン | 対象リージョンでゾーン冗長構成や指定SKUが利用できるか |
| ネットワーク | Load Balancer、Application Gateway、NAT、Private Endpointなどの構成が既存設計と矛盾しないか |
| データ保護 | バックアップ、レプリケーション、RPO/RTOの要件を満たすか |
| コスト | ゾーン冗長化、追加インスタンス、レプリカ、データ転送による増額が許容範囲か |
| 変更影響 | 再作成が必要なリソース、短時間停止が必要な設定変更が含まれていないか |
重要なのは、Resiliency Agentを「自動変更ツール」ではなく「レビューを速くする補助線」として使うことです。Microsoft Learnでも、Resiliency Agentはリソースを自動変更せず、すべての操作には確認と手動実行が必要だと説明されています。(Microsoft Learn)
Public Previewでできる主なこと
Public Preview時点で注目すべき機能は、サービスグループ、回復性目標、推奨事項、Resiliency Agent、可用性ゾーン停止ドリルです。
サービスグループでアプリケーションをモデル化する
サービスグループは、アプリケーションやワークロードを表すAzureリソースの論理グループです。たとえば、Webアプリケーションであれば、フロントエンドのVMまたはApp Service、データベース、ロードバランサー、ネットワーク、監視関連リソースなどをまとめて扱うイメージです。可用性ゾーン停止ドリルの説明でも、サービスグループはアプリケーションまたはワークロードを表すAzureリソースの論理グループとされています。(Microsoft Learn)
この単位を誤ると、評価結果が実態とずれます。たとえば、DBだけをサービスグループに入れてWeb層を含めなければ、アプリケーション全体の耐障害性は判断できません。逆に、関係の薄いリソースを大量に含めると、推奨事項が散らばり、どこから対応すべきか分かりにくくなります。
実務では、最初から全社標準のグループ設計を作り込むより、障害時の影響が大きい1つの業務アプリケーションを選び、「本当に同時に復旧・監視・説明したい単位」でサービスグループを作るのが現実的です。
回復性目標を設定してギャップを確認する
Infrastructure Resiliency Managerでは、サービスグループにゾーン回復性の目標を割り当て、リソースが目標を満たしているかを確認できます。Microsoft Learnでは、現在のリリースでサポートされるのはゾーン回復性の目標のみとされています。(Microsoft Learn)
これは重要な制約です。つまり、現時点でこの機能だけを見て「リージョン障害対策まで十分」と判断してはいけません。可用性ゾーン内の障害に強くすることと、リージョン全体の障害に備えるDR設計は別の論点です。すでにAzure Site Recovery、Azure Backup、Geo冗長ストレージ、マルチリージョン構成などを使っている場合、それらの設計を置き換えるものではなく、まずはゾーン回復性の可視化・改善に使うと捉えるべきです。
推奨事項で改善の優先順位を決める
サービスグループに目標を割り当てると、回復性目標を満たしていないリソースに対して推奨事項が表示されます。推奨事項の詳細では、影響を受けるリソース、推奨理由、修復ガイダンス、利用可能な場合はコスト影響を確認できます。(Microsoft Learn)
ここで大切なのは、すべての推奨事項を即時対応するのではなく、業務影響と変更リスクで並べ替えることです。
| 優先度 | 対応すべき例 | 判断基準 |
|---|---|---|
| 高 | 顧客向けサービスの単一VM、単一DB、単一ゾーン依存 | 障害時に売上・信用・法令対応へ直結する |
| 中 | 社内業務システムの非冗長構成 | 停止許容時間はあるが、復旧遅延が業務に影響する |
| 低 | 開発・検証環境、短期利用リソース | 停止しても業務影響が限定的 |
| 保留 | サポート対象外、特殊なカスタム冗長構成 | 自動評価だけで判断せず、設計書や運用手順と照合する |
ゾーン冗長化は可用性を高める一方で、コスト増、構成変更、再デプロイ、性能特性の変化を伴うことがあります。Microsoft Learnでも、Infrastructure Resiliency Manager自体はプレビュー期間中無料で使える一方、PostgreSQLのような個別サービスでゾーン回復性を有効化すると、そのサービス側の価格に基づいて追加料金が発生する可能性があると説明されています。(Microsoft Learn)
可用性ゾーン停止ドリルで「本当に復旧できるか」を検証する
Public Previewで特に実務価値が高いのが、可用性ゾーン停止ドリルです。Infrastructure Resiliency Managerでは、個々のリソースでゾーン停止をシミュレートし、サービスグループの回復性を評価できます。これにより、アプリケーションのゾーン間回復性ソリューションが実際に機能するか、改善が必要なリソースはどれかを確認できます。(Microsoft Learn)
ドリルでは、障害の挿入、フェールオーバー、再保護、フェールバック、再保護の復元というライフサイクルが示されています。つまり、単にVMを止めて終わりではなく、復旧計画と組み合わせて、障害発生から復旧、元の冗長状態への復帰までを確認する考え方です。(Microsoft Learn)
ただし、ドリルは運用上のリスクもあります。障害注入は検証として有効ですが、対象リソースや構成によってはアプリケーション停止、性能低下、フェールオーバー後の整合性確認、想定外のアラート発報を伴います。
実施前には、次のチェックを行ってください。
| チェック項目 | 理由 |
|---|---|
| 非本番環境で先に実行する | Public Preview機能の挙動と社内手順を安全に確認するため |
| 対象サービスグループを絞る | 影響範囲を明確にし、不要な障害注入を避けるため |
| バックアップと復旧手順を確認する | フェールオーバー失敗時に戻せる状態にするため |
| 監視・通知チームへ事前連絡する | 本物の障害と誤認されることを防ぐため |
| 実施時間帯を決める | 業務影響、サポート体制、関係者の立ち会いを調整するため |
| 成功条件を定義する | 「何分以内に復旧」「どの機能が継続」などを測定可能にするため |
ドリル中は、統合メトリックでサービスグループとリソースの正常性をリアルタイム監視できます。また、実行履歴、メモ、証明、実行ごとのステータスを追跡できるため、監査や改善履歴の管理にも使いやすくなります。(Microsoft Learn)
導入前に確認すべき設定・権限・制約
Azure Infrastructure Resiliency Managerは便利ですが、プレビュー段階であること、対象がゾーン回復性中心であること、権限や再検出の考慮が必要であることを押さえておく必要があります。
RBAC権限を確認する
推奨事項を確認するには、サービスグループやリソースに対する適切なRBAC権限が必要です。Microsoft Learnでは、サービスグループレベルの推奨事項を表示するにはサービスグループリーダーのロール、リソースレベルの推奨事項を表示するには対象リソースへの閲覧者ロールが必要とされています。(Microsoft Learn)
よくある失敗は、Azureポータルでダッシュボードは見えるのに、推奨事項の詳細や一部リソースの状態が見えないケースです。これは機能の不具合ではなく、権限不足やスコープ違いの可能性があります。複数サブスクリプションをまたぐサービスグループを作る場合は、事前に管理グループ、サブスクリプション、リソースグループ単位の権限設計を確認してください。
新規リソース追加後は再検出を忘れない
目標を割り当てた後に追加されたリソースは、自動的に最新評価へ反映されない場合があります。Microsoft Learnでは、新しく追加されたリソースを含めるにはRediscoveryが必要だと説明されています。また、推奨事項数と非回復性リソース数には、推奨事項の更新に数時間かかるため一時的な差異が出る可能性があります。(Microsoft Learn)
運用では、デプロイ後のチェックリストに「サービスグループの再検出」と「回復性姿勢の再確認」を入れるとよいでしょう。特にCI/CDで頻繁にリソースを追加・削除する環境では、評価結果が古くならないように運用ルールを決めておく必要があります。
グローバルサービスだが、全リージョン・全リソースを同じように扱えるとは限らない
Infrastructure Resiliency Manager自体はグローバル、つまり特定のAzureリージョンにデプロイされない非リージョンサービスとして説明されています。任意のAzureリージョン内のリソースを管理・運用できる一方で、個別リソースのゾーン対応可否やSKU、リージョン対応状況は各Azureサービスに依存します。(Microsoft Learn)
たとえば、あるリージョンでは対象サービスのゾーン冗長構成が利用できても、別リージョンでは同じ構成が取れない場合があります。推奨事項を実装する前に、対象リージョン、SKU、サービス制約、既存ネットワーク設計を必ず確認してください。
移行・展開時の注意点
Azure Infrastructure Resiliency Managerを使い始めること自体は、既存ワークロードを別サービスへ移行する作業ではありません。しかし、推奨事項を実装する段階では、実質的にアーキテクチャ変更や再デプロイが発生することがあります。
「使い始める」と「推奨事項を適用する」を分けて考える
最初のステップは、サービスグループを作成し、回復性目標を設定し、現状を見える化することです。この段階では、リソース構成をすぐに変える必要はありません。
一方で、推奨事項を適用する段階では、次のような変更が発生する可能性があります。
- VMを単一ゾーンから複数ゾーン構成へ変更する
- データベースのゾーン冗長を有効化する
- ロードバランサーやネットワーク構成を見直す
- AKSノードプールのゾーン分散を調整する
- IaCテンプレートを修正して再デプロイする
- フェールオーバーや再保護の運用手順を更新する
これらはコスト、停止時間、性能、運用手順に影響します。特に本番環境では、「推奨されたから即適用」ではなく、変更計画、ロールバック手順、検証環境での再現、関係者承認をセットで進めてください。
既存のDR設計を置き換えない
Public Preview時点でサポートされるのはゾーン回復性の目標のみです。したがって、リージョン障害、データ破損、ランサムウェア、誤削除、広域ネットワーク障害などへの対策は、従来通りAzure Backup、Azure Site Recovery、Geo冗長、マルチリージョン設計、運用手順で考える必要があります。(Microsoft Learn)
Infrastructure Resiliency Managerは、まず「ゾーン障害に対して、アプリケーションがどこまで耐えられるか」を可視化・改善するための機能です。DR全体の完成度を評価するには、RTO、RPO、データ整合性、依存システム、DNS切り替え、外部接続、運用体制まで含めて別途レビューしてください。
プレビュー段階では本番変更を急がない
Azure Updatesにおける「In preview」は、すべてのAzure顧客が非本番用途とテスト目的で利用できる状態として説明されています。正式提供済みの本番向け機能とは扱いが異なるため、仕様変更、対象リソースの拡大、画面や操作手順の変更が起こる可能性を前提にしてください。(マイクロソフト Azure)
おすすめの進め方は、次の順番です。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 評価 | 重要ワークロードを1つ選び、サービスグループを作成 | 現状の回復性ギャップ一覧 |
| 検証 | 非本番環境で推奨事項とIaC生成を試す | 変更候補、コスト影響、停止影響の整理 |
| 訓練 | 可用性ゾーン停止ドリルを小さく実施 | フェールオーバー結果、復旧時間、改善点 |
| 計画 | 本番適用する推奨事項を優先順位付け | 変更計画、ロールバック手順、承認記録 |
| 展開 | 低リスクな改善から段階的に適用 | 改善後の回復性姿勢と運用手順 |
管理者が最初にやるべき確認手順
まずは大規模展開ではなく、1つの重要アプリケーションを使って評価するのが安全です。Microsoftの発表でも、Azureポータルで「Resiliency」を検索して新しいプラットフォームにアクセスし、テストアプリケーションまたは本番ワークロードで現在の回復性姿勢を確認することが推奨されています。(TECHCOMMUNITY.MICROSOFT.COM)
最初の確認手順
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | Azureポータルで「Resiliency」を検索 | 表示されない場合はテナント、権限、プレビュー利用可否を確認 |
| 2 | 重要アプリケーションを1つ選ぶ | いきなり全社リソースを対象にしない |
| 3 | サービスグループを作成 | 実際のアプリケーション依存関係に合わせてリソースを含める |
| 4 | ゾーン回復性目標を割り当てる | 業務要件に対して過剰・不足がないか確認 |
| 5 | 回復性状態を確認 | 回復性あり、非回復性、未評価リソースを分けて見る |
| 6 | 推奨事項を確認 | コスト、停止時間、再デプロイ要否で優先順位付け |
| 7 | 非本番でドリルを実行 | 本番影響を避け、監視・復旧手順を確認 |
| 8 | 改善計画に落とし込む | IaC、運用手順、監視、障害対応訓練に反映 |
この手順で重要なのは、可視化で終わらせないことです。回復性の弱点が見つかったら、誰が、いつ、どの環境で、どの変更を、どのリスク許容範囲で実施するかまで決める必要があります。
よくある誤解と失敗しやすいポイント
Azure Infrastructure Resiliency Managerを有効にすれば自動で高可用になるわけではない
この機能は、回復性の目標設定、評価、推奨、訓練を支援するものです。Resiliency Agentも自動でリソースを変更するわけではありません。すべての変更には利用者側の確認と実行が必要です。(Microsoft Learn)
推奨事項をすべて適用すれば最適とは限らない
ゾーン冗長化は多くの本番ワークロードで有効ですが、すべてのリソースに同じ水準を求めるとコストと運用負荷が増えます。開発環境、短期利用環境、停止許容時間が長い社内ツールまで一律に高可用化する必要はありません。業務影響とコストを比較して判断してください。
未評価リソースを無視しない
未評価リソースは「問題なし」ではありません。サポート対象外、手動除外、カスタム構成などの理由で自動評価されていない可能性があります。Microsoft Learnでも、ユーザーが除外したリソースやサービスでサポートされていないリソースは評価されないリソースとして扱われると説明されています。(Microsoft Learn)
ドリルを本番でいきなり実行しない
可用性ゾーン停止ドリルは強力ですが、障害注入を伴います。最初は非本番で実施し、監視、通知、復旧、ロールバック、関係者連絡の流れを確認してから、本番相当の訓練に進むべきです。
まとめ：まずは重要ワークロード1つで回復性の現在地を確認する
Azure Infrastructure Resiliency ManagerのPublic Previewは、Azureの回復性対策を個別リソースの設定確認から、アプリケーション単位の継続的な改善へ進めるための重要なアップデートです。Availability Zones、Azure Advisor、Azure Chaos Studio、Azure Monitor、Azure Copilotを横断し、目標設定、推奨事項、IaC支援、可用性ゾーン停止ドリルまでつなげられる点が大きな特徴です。(TECHCOMMUNITY.MICROSOFT.COM)
一方で、Public Preview時点ではゾーン回復性が中心であり、すべてのDR設計を代替するものではありません。利用開始時は、本番構成をすぐ変更するのではなく、重要アプリケーションを1つ選び、サービスグループを作成し、回復性目標を設定し、推奨事項と未評価リソースを確認するところから始めてください。
次に取るべき行動は明確です。Azureポータルで「Resiliency」を確認し、非本番または影響の小さいワークロードで、サービスグループ作成、回復性評価、推奨事項確認、ゾーン停止ドリルを小さく試します。その結果をもとに、コストと停止影響を見積もり、IaCと運用手順に反映する。これが、プレビュー段階で最も安全かつ実務に効く進め方です。
コメント