azure-upgrade

Azure Upgrade

このスキルでは、既存の Azure ワークロードを、Azure 内で別の Azure サービス、ホスティングプラン、または SKU へ評価して自動アップグレードします。これには、プラン／ティアのアップグレード（例：Consumption → Flex Consumption）、サービス間の移行（例：App Service → Container Apps）、SKU の変更が含まれます。また、Azure SDK for Java のソースコードのモダナイゼーション（例：レガシーな Java com.microsoft.azure.* → モダンな com.azure.*）も対象です。クラウド間の移行は対象外です。その場合は azure-cloud-migrate を使用してください。

トリガー

ユーザーの意図	プロンプトの例
Azure Functions のプランをアップグレードする	「function app を Consumption から Flex Consumption にアップグレードして」
Functions のアップグレード候補を見つける	「Flex Consumption にアップグレードできる Consumption の Function App はありますか？」
ホスティングティアを変更する	「function app をより適したプランに移行して」
アップグレードの準備状況を評価する	「function app は Flex Consumption に対応していますか？」
プランの移行を自動化する	「Functions プランをアップグレードする手順を自動化して」
レガシーな Azure Java SDK をモダナイズする	「レガシーな Azure SDK for Java を移行して」、「レガシーな Azure Java SDK をアップグレードして」、「Java プロジェクトを com.microsoft.azure から com.azure に移行して」
Azure Cache for Redis（ACR/OSS）を Azure Managed Redis（AMR）に移行する	「Redis キャッシュを AMR に移行して」、「ACR から AMR」、「OSS から AMR」、「Premium P2 キャッシュを Managed Redis にアップグレードして」、「AMR SKU を選んで」、「Redis の IaC テンプレートを AMR 用に変換して」
Azure Cache for Redis Enterprise（ACRE）を Azure Managed Redis（AMR）に移行する	「Enterprise_E10 キャッシュを AMR に移行して」、「ACRE から AMR」、「ACRE の IaC テンプレートを AMR 用に更新して」、「EnterpriseFlash を AMR に移行して」、「地理レプリケーションされた Enterprise Redis を移行して」

ルール

1. フェーズは順番どおりに進めてください。選択したシナリオで明示的に許可されている場合に限り、作業を省略または延期し、その理由を移行ステータスに記録してください。
2. アップグレード操作の前に、必ず評価を生成してください。
3. シナリオのリファレンスを読み込み、そのルールに従ってください。
4. mcp_azure_mcp_get_azure_bestpractices および mcp_azure_mcp_documentation MCP ツールを使用してください。
5. 破壊的な操作には ask_user が必要です — global-rules
6. 続行する前に、必ず対象のプラン／SKU をユーザーに確認してください。
7. 新しいリソースを作成する場合は、必ず名前を提案してください（既定値：<source>-<target-suffix>。例：Flex Consumption への移行では <source>-flex）。作成前に、ユーザーが確認を求められて作業が止まることなく名前を変更できるよう、提案した名前をユーザーに伝えてください。ストレージアカウント、App Insights など、ほかの新規作成リソースにも同じパターンを適用します。サービス固有の既定値については、シナリオのリファレンスを参照してください。
8. Windows Consumption → Flex のソース変更ゲート：既定では、ソースアプリは読み取り専用として扱ってください。設定、トリガー、状態、デプロイ、バインディング、または存在に変更を加えるコマンドを実行する直前に、必ず ask_user を使用して変更内容を正確に説明し、明示的な承認を得てください。承認は操作ごとに必要であり、後続のソース変更には再利用できません。
9. ユーザーから明示的な確認を得ずに、元のアプリを削除または停止しないでください。
10. 承認が必要なワークフローを止めずに進めてください：各ステップの完了後、直ちに次の読み取り専用の事前確認を実施してください。次の操作に承認が必要な場合は、同じターン内に ask_user を呼び出してください。次のステップを知らせるだけで止まり、ユーザーが再度操作するのを待ってはいけません。
11. すべての自動化スクリプトは、冪等で再開可能である必要があります。

アップグレードのシナリオ

ソース	ターゲット	リファレンス
Azure Functions Consumption Plan（Linux）	Azure Functions Flex Consumption Plan	workflow.md
Azure Functions Consumption Plan（Windows）	Azure Functions Flex Consumption Plan	workflow.md
レガシー Azure Java SDK（com.microsoft.azure.*）	モダン Azure Java SDK（com.azure.*）	languages/java/README.md
Azure Cache for Redis（ACR/OSS）Basic/Standard/Premium	Azure Managed Redis（AMR）	services/redis/redis-to-amr.md
Azure Cache for Redis Enterprise（ACRE）/ Enterprise Flash	Azure Managed Redis（AMR）	services/redis/redis-to-amr.md

Functions Consumption-to-Flex の振り分け： 名前が指定されたアプリの場合は、Azure プラットフォームを確認し、該当する Linux または Windows のワークフローのみを読み込みます。サブスクリプション全体を検出する場合は、両方のプラットフォームを評価します。Linux では az functionapp flex-migration list を使用し、Windows ではワークフローに記載された手動の検出と互換性チェックを実施します。Windows の結果は、アプリごとのコード互換性を評価するまで候補として扱います。

SDK のアップグレードシナリオ（例：Java のレガシー版からモダン版への移行）では、Azure サービス／プラン／SKU のアップグレードとは別のソースコードのモダナイズフローを実行します。以下の手順ではなく、シナリオのリファレンスに従ってください。

該当するシナリオがない場合は、mcp_azure_mcp_documentation と mcp_azure_mcp_get_azure_bestpractices ツールを使用して、アップグレードパスを調査してください。

MCP ツール

ツール	目的
mcp_azure_mcp_get_azure_bestpractices	ターゲットサービスの Azure ベストプラクティスを取得します
mcp_azure_mcp_documentation	アップグレードシナリオに関する Azure ドキュメントを検索します
mcp_azure_mcp_appservice	App Service と Functions のプラン詳細を照会します
mcp_azure_mcp_applicationinsights	監視の構成を確認します

手順

1. 特定 — ソースとターゲットの Azure プラン／SKU を特定します。ユーザーに確認を求めます。
2. 評価 — 既存のアプリがアップグレードに対応できるかを分析し、シナリオのリファレンスを読み込みます（例：workflow.md）
3. 移行前 — 既存のアプリから設定、ID、構成を収集します
4. アップグレード — 自動化されたアップグレード手順を実行します（新しいリソースの作成、設定の移行、コードのデプロイ）
5. 検証 — 選択したシナリオで定義されたチェックを使用します。ターゲットリソースの状態、該当する HTTP エンドポイントと非 HTTP トリガー、監視を確認します。アクセス制限やテストリソースの利用不可によって実行できない場合は、検証を延期として記録します。セキュリティを自動的に緩和したり、機能面で成功したと報告したりしてはいけません。
6. ユーザーへの確認 — パフォーマンスの検証と IaC の更新を提案します。ソースのクリーンアップは、選択したシナリオで本番環境への切り替えが確認され、クリーンアップの前提条件がすべて満たされている場合に限り提案します。
7. azure-validate に引き継いで詳細な検証を行うか、azure-deploy に引き継いで CI/CD を設定します

進捗は <UPGRADE_DIR>/upgrade-status.md で管理します。パスの解決については、Artifact Output Policy を参照してください。

参考資料

• 全般ルール
• ワークフローの詳細
• Functions
  • Linux
    • Consumption から Flex Consumption への移行
    • 評価
    • 自動化スクリプト
  • Windows
    • Consumption から Flex Consumption への移行
    • 評価
    • 自動化スクリプト
• Redis
  • Redis（ACR または ACRE）から AMR への移行 — 専用の amr-migration-skill（ACR/OSS）または acre-to-amr-migration-skill（Enterprise）に案内します
• Java SDK 移行テンプレート
  • 計画テンプレート
  • 進捗テンプレート
  • 概要テンプレート

次のステップ

アップグレードの検証後、次の担当に引き継ぎます。

• azure-validate — アップグレード後の詳細な検証を行う場合
• azure-deploy — 新しいアプリの CI/CD を設定する場合