azure-upgrade
Azure のプランや SKU の乗り換えと、古い Java SDK の書き換えを評価つきで進めさせる
npx skills add microsoft/azure-skills/azure-upgrade入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 469,953
- 実用度
- 98
- GitHub star
- 1,623
- 最終更新
- 2026/11/7
頼み方の例
そのままコピーして使えますazure-upgradeスキルを使って、この Function App を Consumption から Flex Consumption に移せるか評価してください。移行できない理由があるなら先に全部挙げてください。実際の変更はまだ実行しないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- シェルコマンドを実行する記述があります
- 実行可能なスクリプトが 1 件同梱されています（Python）
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
いつ使うか
Azure の中で、いまの構成から別の構成へ乗り換えるときです。
乗り換えは大きく 3 種類
- プラン・SKU の変更Consumption → Flex Consumption、上位プランへ
- サービスをまたぐ移行App Service → Container Apps
- コードの近代化Java の
com.microsoft.azure.*→com.azure.*
Azure Cache for Redis から Azure Managed Redis への移行も含まれます。
移行表は 5 行
本文の移行表は 5 行です。Functions の Consumption → Flex Consumption（Linux と Windows で資料が別）、Java の SDK、Redis（通常版と Enterprise 版）から Azure Managed Redis です。App Service → Container Apps は例として挙がっていますが専用の資料は無く、表に無い移行は Azure MCP の文書とベストプラクティスの道具で調べる、と書かれています。
Redis の 2 つは、このスキルでは移行しません。通常版か Enterprise 版かを見分けて、Azure Managed Redis のチームが出している専用のスキル 2 つのどちらかを案内するだけです。
評価してから作業に入る
このスキルは評価と自動化された変更を持っています。先に「移せるか」を見て、それから作業に入る流れです。
- 特定移行元と移行先のプランや SKU を決め、利用者に確かめる
- 評価移せるかを調べる。場面ごとの資料を読む
- 事前準備設定・ID・構成を今のアプリから集める
- 移行新しいリソースを作り、設定を移し、コードを配置する
- 検証移行先の状態、HTTP のエンドポイントと HTTP 以外のトリガー、監視を確かめる
検証できない事情（アクセス制限など）があれば、セキュリティを緩めずに「保留」と記録し、成功とは報告しない決まりです。
進み具合は .azure-upgrade/<場面の ID>/upgrade-status.md に記録します。評価の報告や一時ファイルも同じフォルダに置き、git のリポジトリなら .gitignore に足します。接続文字列や鍵の値はディスクに書かない決まりです。どこかの段で失敗したら、次の段へ進まずに止まります。検証のあとは、深い検証を azure-validate、CI/CD の設定を azure-deploy に渡します。
組で入れないと止まるものがある
この公開元には組で入れないと止まるものがあります。全体の役割分担は microsoft/azure-skills の地図にまとめています。
使わないほうがいいとき
別のクラウドへ移すとき
別のクラウドへ移すとき。SKILL.md に「クラウドをまたぐ移行には使うな。azure-cloud-migrate を使え」と明記されています。
新規に作るとき
新規に作るとき。これはすでにあるものの乗り換えです。新規構成なら azure-prepare です。
可用性を点検したいとき
可用性を点検したいとき。azure-reliability です。
注意点
解析で見つかったこと
SKILL.md の解析では、外部への通信・シェルコマンドの実行・ファイルの書き換えの記述が見つかっています。az で Azure のリソースを変更し、Java の場合はソースコードも書き換えます。
確認なしに消したり止めたりしない決まり
本文の規則には、移行先のプランや SKU を必ず利用者に確かめること、破壊的な操作は ask_user で確認を取ることが書かれています。元のアプリは、明示の確認なしに消したり止めたりしません。元のアプリの片付けを持ちかけるのも、本番の切り替えが済み、片付けの前提がそろってからです。
新しく作るリソースには名前を提案し、作る前に利用者へ告げます。Flex Consumption への移行なら、既定は <元の名前>-flex です。Windows の Consumption から移すときは、元のアプリを読み取り専用として扱います。元のアプリを変える操作の直前に、毎回その操作ごとに ask_user で承認を取ります。
同梱の共通規則では、サブスクリプションやリージョンの選択、新しいリソースの作成、DNS やカスタムドメインの変更も確認の対象です。新しいアプリは同じリソースグループに横並びで作り、検証が済むまで元のアプリは動かしたままにします。
評価だけで止めるなら依頼文に書く
Java の SDK の書き換えはソースコードを変える
Java の SDK の書き換えは、ソースコードを変えます。com.microsoft.azure.* から com.azure.* への移行は、インポートだけでなく API の呼び出し方も変わります。流れの中で、git があれば java-upgrade/{実行 ID} というブランチを作り、段ごとにコミットします。テストは全部通ることが条件で、古い参照が残っていないかを grep で確かめてから終わります。対象は Maven か Gradle の Java だけで、.NET・Python・JavaScript・Go の SDK には使うなと書かれています。ブランチを確かめてから始めて、差分を読んでください。
Python 3.10 以上が前提
Python 3.10 以上が前提です。frontmatter に compatibility: python3.10+ と書かれています。使うのは Java の BOM を上げる同梱スクリプト（upgrade_bom.py）で、Python が無いか失敗したときは手作業の手順に切り替えると書かれています。
戻せない変更がある
戻せない変更があります。プランの変更やサービスをまたぐ移行は、元に戻すのに別の作業が必要です。このスキルが出す手順を流す前に、何が作り直されるかを確認してください。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
よくある質問
評価だけならリソースは変わりませんか
評価の段階は読み取りです。ただし自動アップグレードまで続く設計なので、読み取り専用の資格情報で動かすか、依頼文で区切るかのどちらかにしてください。
Consumption から Flex Consumption に移すと何が変わりますか
このスキルは移行の手順を、Linux の Consumption と Windows の Consumption で別々に持っています。どちらも .NET の in-process は先に isolated へ移す必要があります。Windows からは OS も Linux に変わるので、Windows 専用の依存や .NET Framework はそのままでは動きません。外せない Windows の依存があるなら、Windows の Elastic Premium に移す道も書かれています。Azure CLI 2.77.0 以上、resource-graph 拡張、jq、リソースグループの所有者か共同作成者の権限が前提です。プランの違いそのものは Microsoft のドキュメントが一次情報で、コールドスタートや同時実行の挙動が変わるので、移行の判断は公開元の案内を読んでからにしてください。