はじめに

Azure Copilot Resiliency Agent は、Azure 枠の中で「アプリケーションの回復性を設計・評価・改善する支援を、自然言語で行える AI エージェント」です。
Microsoft Learn の公式ページでは、

The Azure Copilot Resiliency Agent is an AI-powered assistant integrated into Azure Copilot that helps you design, assess, and improve the resiliency of your Azure workloads through natural language.
と紹介されています。要するに、「Azure Portal から対話しながら、回復性の見直しと修正をやってくれる存在」です。
今回のメモでは、公式ドキュメントに書かれているできることを整理したうえで、Preview 段階で見えてきた限界を、実際に試した経験を踏まえて書きます。
特に、ドキュメントでは AKS を前提にした説得力のある例が多い一方で、私が試した構成は Azure Container Apps + Blob Storage + Azure SQL Database という組み合わせでした。そのとき、公式の「リソース型チェック」が期待したとおりには動かず、既存リソースの回復性調整にも一貫性が見えづらい感触を覚えました。
この記事の結論を先に言うと、Resiliency Agent は「回復性の設計支援としては非常に有用」 ですが、Preview では依然として「対象リソースやアーキテクチャの理解範囲が限定されている」 という状態にあります。

本記事の目的

公式ドキュメントに基づき、Azure Copilot Resiliency Agent の主な能力を整理する
「Start Resilient」と「Get Resilient」で何ができるかを分かりやすく整理する
Preview の現時点での限界と、設計上の注意点を整理する
実際の体験談として、Azure Container Apps でも使おうとしたときに見えたギャップを共有する

公式ドキュメントに書かれている能力

Microsoft Learn の説明によると、Resiliency Agent は大きく 2 つのモードを持っています。

区分	目的	主な機能
🧱 Start Resilient	新規設計時の回復性設計	回復性レビュー、構成の推奨、Bicep テンプレート生成
🛠️ Get Resilient	既存ワークロードの改善	リソースの回復性評価、前提条件確認、修正スクリプト生成

公式では、「アーキテクチャでの設計支援」と「既存リソースの改善支援」という 2 本柱で説明されています。これは非常にわかりやすく、モダンな Azure の運用における回復性に関するワークフローを AI が支援する、という位置づけです。

1. Start Resilient: いち早く回復性を設計に組み込む

公式ドキュメントの中核は、次のような設計支援です。

アプリケーションのトポロジを自然言語で説明すると、回復性のベストプラクティスを提示する
回復性レポートを生成して、アーキテクチャに応じた推奨事項を示す
推奨構成が反映された Bicep テンプレートを生成する
つまり、「設計フェーズで回復性を後から直すのではなく、デプロイ前に組み込む」 という使い方を支援するものです。
特に、AKS・Redis・Storage・Cosmos DB のような例が出ており、初期構成の設計時のおすすめとして相性が良いと考えられます。
私が注目したのは、ここにある「アプリケーション全体を見て回復性をレビューする」という発想です。単なる個別リソースの設定確認ではなく、構成単位としての回復性設計を AI に考えさせるのが狙いで、これは有効だと感じました。

2. Get Resilient: 既存ワークロードを改善する

もう一方の軸が Get Resilient です。こちらは既存の Azure ワークロードを読み取り、回復性の可否と改善方法を支援します。
公式では、次のような機能が挙げられています。

リソース単位または Service Group 単位で、ゾーン耐性の状態を確認する
回復性有効化の前提条件やブロッカーを特定する
直接変換が可能な場合は設定変更を行う
再デプロイが必要な場合は手順とスクリプトを出す
追加のスクリプトを生成する（PowerShell / Azure CLI / Bicep など）
Service Group を使ってリソースを整理し、目標と遵守状況を管理する
ここが一番わかりやすいのは、「回復性の状態を診断したあとに、修正までセットで進める」 点です。回復性の知識やガイドの断片をブラウジングするよりも、会話の流れで改善アクションまで進めたいチームには刺さる構成です。

公式ドキュメントに基づく、典型的なユースケース

公式ページでは、次のような 3 パターンが例として示されています。

1. 「新しいアプリを作るときの回復性設計」

アプリケーション名、構成、利用するリソースを自然言語で伝えると、エージェントが回復性の観点で整理してくれます。ゾーン冗長性やレジリエント設計の観点で、設計チェックを自分の手ではなく AI に投げられるのは、プロジェクト開始時にとても有効です。

2. 「既存アプリの回復性を診断する」

対象リソースの状態を確認し、回復性が有効か、なぜ有効にならないか、前提条件があるかを確認できます。これは非常に現実的で、「試験環境だけでなく本番に近い運用で何が足りないか」を問い合わせる入口として便利です。

3. 「修正の自動化 or 手順化」

ドキュメントでは、修正を直接行うケースと、スクリプトや手順で案内するケースの両方があるとされています。ここは Azure のリソース特性に応じて変わるので、AI の役割が「すべてを自動でやる」ではなく、「変換が必要なものを案内する」ことにあるのがわかります。

Preview で見えてきた現実的な限界

ここからが本題です。
公式ドキュメントは、非常に明快に「できること」を書いています。ですが、Preview で現場感として見えてくるのは、「対象のリソースや構成を、どこまで正しく認識できるか」 という限界です。

1. ドキュメントの中心が AKS ベースになっていて、他の構成の表現が弱い

公式のサンプルでは、AKS や VM、Storage、Cosmos DB を中心にした例が多く、書かれている設計の軸が、モダンな Azure の考え方とかなり近いです。
また、Azure Copilot のエージェントの公式ドキュメントでも、

Azure Copilotエージェントでは、すべてのリソースの種類がサポートされない場合があります。
と明記されています。これは、今回のような Azure Container Apps など一部の PaaS リソースで「リソース型の検証が十分に進まない」現象を説明するうえで、非常に重要な前提条件です。Azure Copilotのエージェントにこの制限が書かれています。
その一方で、私が実際に試した構成は次のようなものでした。

Azure Container Apps
Azure Blob Storage
Azure SQL Database
既存の運用資産をアプリケーション側で再利用している構成
この組み合わせで、エージェントに「回復性を見て」「設計上の問題を確認して」「改善の提案をして」と依頼したところ、Azure Container Apps に関する情報不足や、リソース型の検証の不足を感じました。
つまり、公式としては「リソースの回復性を評価する」ことが示されていますが、実際にその対象が Azure Container Apps のような PaaS 要素であると、リソース検証の粒度がまだ弱い印象です。

2. 既存リソースへの回復性対応が、手元では一貫していない

公式では、Get Resilient で「ゾーン耐性の確認」「前提条件の確認」「in-place conversion / script generation」があるとされています。
ただし、実運用では次のような問題が残りました。

既存リソースの状態が、期待した評価基準にかなり依存している
身近な PaaS リソースでは、リソース型としての検証がうまく通らないことがある
変更できる計画が出ても、実際の構成差分とズレることがある
これは「AI が誤る」というより、現時点でのモデル対象が、リソース構成のモデル化と運用状況の表現としてまだ成熟していないと理解したほうが妥当です。

3. 実際に「回復性」には 2 層ある

ここは非常に重要です。
回復性には、少なくとも次の 2 層が混ざってきます。

アプリケーション設計としての回復性
- 再試行、バックオフ、CQRS、非同期処理、データ整合性、障害分離
Azure リソースとしての回復性
- ゾーン冗長、リージョン冗長、Storage の可用性、Database の冗長構成
  私は試していて、両方が重なると、過剰な修正提案や重複した改善提案が生まれることを感じました。
  たとえば、アプリケーション側で「タイムアウト」「再試行」「バックオフ」を実装しているのに、Azure リソース側でも回復性改善を提示されると、本当に必要な設計と、冗長な回復性対策が重なるケースがあります。
  これは非常に大事な観点です。回復性は、アプリケーションの設計とインフラの設計が関係し合うので、AI が両方を同時に扱うと、どちらが本丸かがぼやけやすいのです。

4. Preview であることを踏まえると、運用判断は人が最後に行うべき

公式ドキュメントにもあるように、Resiliency Agent は Preview です。現時点では、

ゾーン回復性が中心
リージョン回復性や他の回復性観点は今後追加予定
テンプレート生成は Bicep が中心
一部操作は時間がかかることがある
といった制約があります。
この制約を踏まえると、Agent の提案を「そのまま採用する」のではなく、設計意図と運用要件を見ながら最終判断するのが正しい使い方です。
特に、回復性は費用・複雑さ・運用コストとのトレードオフがあります。AI が示した改善が、実際には過剰設計である場合があり得ます。そのため、最終的に「守るべき SLO」「許容できる費用」「運用の手間」という観点で判断する必要があります。

実務的な再試行と一時的障害対策の考え方

実際に Azure Container Apps、Blob Storage、Azure SQL Database を組み合わせて設計する場合、Resiliency Agent のような AI からの提案は、リソース単位ではなく、クライアント/アプリ側の再試行戦略まで含めて考えることが重要です。
要点だけ先に言うと、

クライアント側の再試行（指数バックオフ＋ジッタ）を基本にする
冪等性を設計に入れる（POST や更新系は idempotency key を持たせる）
サービス側のヘルスチェックや冗長化と組み合わせる
回路遮断（circuit breaker） とタイムアウトを使って負荷増加を抑える
Bicep で再試行ポリシーを直接定義するのではなく、アプリ実装側で設定する
というのが実務的なベースラインです。

1. Container Apps: アプリ層での耐性設計が中心になる

Container Apps では、アプリの外側のリソースやネットワーク問題を吸収するために、アプリ内の HTTP / DB クライアント側の再試行が重要です。

観点	推奨パターン
🔁 再試行	指数バックオフ＋ジッタ、`maxRetries 3〜5` 程度
⏱️ 遅延	初期遅延 200〜500 ms、最大 10〜30 s 程度
🧩 副作用	`POST` などは idempotency key を付与
🩺 ヘルスチェック	readiness / liveness を丁寧に設定
🏗️ 冗長化	複数レプリカ、複数環境、リビジョン切替

ポイントは、リトライさえ増やせばよいわけではないことです。副作用のある API やデータ更新では、同じ要求を何度も再実行してしまわないように設計しなければなりません。

2. Blob Storage: SDK の組み込み再試行と部分的リトライの設計

Blob Storage はネットワークや短時間のサービス遅延に対して、SDK 側の再試行で吸収しやすいのが特徴です。

観点	推奨パターン
🔁 再試行	Azure Storage SDK の `RetryOptions` を利用
⚙️ パラメータ	`maxRetries 3〜5`、`mode = Exponential`、`delay 200〜1000 ms`
📦 大容量アップロード	分割アップロード、チャンク単位で再送
📴 冪等性	`PUT` の上書きや条件付きリクエストを利用
📈 監視	429、5xx、タイムアウト、リトライ回数を可視化

特に大きなファイルを Blob に載せる場合、再開可能なアップロードやチャンク単位の再送が有効です。そこで重要なのは、単に「再試行を増やす」だけではなく、どのチャンクが失敗したかを設計に落とし込むことです。

3. Azure SQL Database: 接続の再試行と長時間トランザクションの回避

Azure SQL Database は、短いネットワーク断や一時的なフェイルオーバーに対して、クライアント側の再接続戦略が重要です。

観点	推奨パターン
🔁 接続再試行	EF Core の `EnableRetryOnFailure`、`SqlClient` の再試行ポリシー
⏱️ パラメータ	`maxRetries 3〜5`、`maxDelay 15〜30 s`
🧱 トランザクション	長時間トランザクションを避ける
♻️ フェイルオーバー	接続文字列とタイムアウトの調整
📈 監視	接続失敗、再接続、フェイルオーバー、長時間クエリ

SQL 系では、再試行自体よりも操作が安全に再実行できる設計が大事です。もし更新処理が冪等でない場合、途中失敗により重複更新や二重登録が起こりやすくなります。

4. 共通の設計パターン: 冪等性と回路遮断の重要性

ここが一番大事な実務上のポイントです。

冪等性: POST や更新処理では、idempotency key を付与して重複実行を防ぐ
指数バックオフ＋ジッタ: ランダムに遅延を混ぜて、同時再試行の波を分散する
回路遮断: 短時間で失敗が連続したら一時的に遮断し、負荷を下げる
タイムアウト: すべての外部呼び出しに上限を入れて、無限待ちを防ぐ
可観測性: リトライ回数、429、5xx、レイテンシを記録してアラート化する
つまり、**Resiliency Agent で「回復性を推奨しても、実際の効き目はクライアント実装次第」**というのが、非常に大事な点です。

5. Bicep でできることと、できないことの整理

実はここが実践的に重要です。
Bicep では、

Storage Account の冗長性（例: ZRS / GZRS）
Azure SQL のサービス層やゾーン冗長に関する選択
Container Apps の複数インスタンスや環境定義
は指定できます。
一方で、再試行ポリシーそのものは主にアプリケーション層の設定です。たとえば 「SDK の指数バックオフや maxRetries」は Bicep では一般に設定できず、アプリコードかクライアントライブラリ設定で扱うのが正しい考え方です。
そのため、Resiliency Agent が Bicep を生成できるとしても、インフラの設計とアプリケーションの再試行設計は別物と意識しておくべきです。
これは、今回私が一番感じたことでもあります。AI がリソース・レイヤーの回復性を提案してくれても、実運用での耐障害設計はクライアント側の設計が肝になるのです。

実際に試してみて感じたこと

私が Azure Container Apps + Blob Storage + Azure SQL Database の構成で試したとき、最も印象的だったのは次の 2 点です。

1. 「回復性を見てほしい」と依頼したが、リソース型を正しく特定できない場面がある

最初に試したのは、

Container Apps を使っている
Blob Storage が状態管理やファイル保存に使われている
Azure SQL Database がデータ管理に使われている
という構成で、Resiliency Agent に「この構成で回復性を確認して」と頼んだことです。
そのときの感触として、Azure Container Apps のようなワークロード層に対する詳細な検証が弱く、実際のリソース型のチェックが十分に行えないという状態でした。
これは、リソースの種類や設計意図の理解にまだ限界があるためだと捉えています。

2. 「既存リソースの改善」が説明通りに効かないことがある

もう一つ試したのは、既存のリソースに対する改善策の生成です。たとえば、

既存の Azure SQL Database をどこまでゾーン冗長化できるか
Blob Storage をどのまま使いつつ、回復性を高められるか
App 側と Azure 側でどこまで重複するか
という観点で質問しました。
結果として、エージェントがリソースの状態を説明してくれるものの、実運用上の前提条件や、既存構成への適用判断が十分に明示されないことがありました。
この現象は、Resiliency Agent が「一般論としての回復性」「Azure の推奨構成」を出す一方で、その構成を手元の実際のリソースに当てはめるときの個別条件の高度さにまだ踏み込めていない、という見方がしやすいです。

「設計側の回復性」と「リソース側の回復性」は別物だ

ここは、今後の設計判断にとってかなり重要です。
回復性を考えるとき、1 つの見方として次のように整理できます。

アプリケーションの設計としての回復性
- 再試行
- 障害分離
- 自動復旧
- 非同期化
- データ整合性設計
Azure リソースの回復性
- ゾーン冗長
- リージョン冗長
- 可用性構成
- Storage / Database の冗長性
  この 2 つが重なると、過剰な対策が生まれやすくなります。
  たとえば、
アプリケーション側で再試行とバルクアップロードの設計をしているのに、さらに Azure 側で冗長化を追加する
Blob と SQL の分離設計があるのに、既存リソース型の自動修正がそのまま推奨される
Service Group とアプリケーションの障害耐性が競合してしまう
といったケースです。
ここは、AI が「回復性に関する提案」を大量に出しやすいので、**「どこまでが必要で、どこまでが過剰か」**を自分で判断するフェーズが必須です。
将来的には、Resiliency Agent が「設計上の回復性」と「Azure リソースの回復性」をどう整理して提示するかが、重要な進化ポイントになると思います。

公式ドキュメントで見える、Preview の明確な限界

公式ドキュメントにも、Preview に対する注意点があります。

ゾーン回復性が中心で、リージョナル回復性の考慮は今後の拡張対象
Start Resilient のテンプレート生成は Bicep ベースが中心
リソース操作がすべて直接実行されるわけではない
一部の大きな Service Group では時間がかかる
この説明を踏まえると、Resiliency Agent は「設計・評価・修正の支援ツール」であって、インフラ全体を完全に自律制御する存在ではないことがわかります。
そのため、現時点の使い方は次のように整理すると良さそうです。

使い方	向いているケース	注意点
🧭 事前設計の相談	新規アプリ開発、設計レビュー	そのまま採用せず設計意図と照合する
🔎 既存構成の診断	Azure での見直し、SRE / DevOps 連携	ライフサイクルや実装構成を前提に確認する
🏗️ テンプレート生成	Bicep 導入時の骨組み作成	その後の運用要件と要件整合を確認する
⚠️ 自動修正の実行	簡潔な構成変更	影響範囲が大きい場合は慎重に評価する

まとめ

Azure Copilot Resiliency Agent は、Azure 向けに「回復性の設計・診断・改善」を自然言語で進められる点で、かなり興味深い存在です。
公式ドキュメントベースで見ると、次のような能力が明確にあります。

アプリケーション全体の回復性を設計する支援ができる
既存リソースの回復性状態をレビューできる
前提条件やブロッカーを確認できる
修正のためのスクリプトやテンプレートを生成できる
一方で、Preview 段階では次のような現実があると感じました。
AKS を中心としたドキュメントになっており、Container Apps など別の構成を正しく扱う余地がまだ少ない
リソース型の検証と、既存構成への適用の一貫性にまだばらつきがある
アプリケーション側の回復性と Azure リソース側の回復性が重なると、過剰な改善提案になりやすい
Preview であるため、最終判断は人間が行うべき
これは決して「使えない」という話ではありません。むしろ、回復性の設計に AI を使う前提として、非常に有意義なテーマだと感じています。
今後の進化に期待したいのは、次の 2 点です。

より広い Azure リソース型を正しく評価できるようになること
アプリケーション回復性とリソース回復性を適切に分離して提示できること
この 2 点が進むと、Resiliency Agent は本当に「設計から運用まで一貫して支える存在」になっていくと考えています。

参考リンク

おわりに

回復性は、インフラだけの話ではなく、アプリケーション設計、データ思考、運用ポリシー、チーム体制まで含めて考える必要があります。Resiliency Agent はその入口として非常に有用ですが、AI にすべてを任せる前に、人間が設計意図を持つことが大事だと感じました。
Preview 時点での限界を知ったうえで使うと、AI は「回復性のアイデア出し」には非常に強く、また「局所的な見直し」を高速に進めるには便利です。逆に、組織の設計方針や運用方針が曖昧なまま使うと、AI はがんばりすぎて過剰な回復性設計を提案してしまうこともあります。
その意味で、Resiliency Agent は「自動化の代替」ではなく、設計判断を支える相棒として使うならかなり価値が高いツールだと考えています。