Azure Pipelines旧タスクは11月24日サポート終了：削除前にデプロイ・切戻し・DRを再検証する

結論：稼働継続とサポート継続を分け、復旧経路まで移行する

編集上の判断：11月24日より前の移行完了を社内目標として設定し、対象定義と責任者を確定してください。公開サービスの通常デプロイが動いていても、緊急時にだけ使う旧タスクが残れば、修正や復旧の実行経路を失うおそれがあります。

編集上の受入条件：置換後のパイプラインで、検証用環境への展開、意図した失敗、通知、旧成果物への切戻し、別環境への再構成を試験します。ジョブの成功、適用されたリソース構成、業務の疎通を別々に確認することを提案します。

背景と技術的要因：タスクはアプリとは別の実行依存

確認済み事実：Azure Pipelinesではタスクのメジャー版を指定します。マイナー版は通常自動更新されますが、新しいメジャー版へは定義変更が必要です。組織に存在するタスク版だけを利用できます。出典：タスクの種類と使用法。

編集上の分析：アプリのソースとIaCが残っていても、それらを実行するタスク、エージェント、モジュール、サービス接続が揃わなければ同じ結果を再現できません。パイプライン定義も本番アーキテクチャの依存関係に含め、利用頻度の低い復旧処理を調査から外さないでください。

編集上の整理：タスク版、Azモジュール版、PowerShell版、Azure REST API版は別の識別子です。AzurePowerShell@5への変更をPowerShell 5への固定や、利用APIの自動更新と同一視しないでください。実際に呼ぶコマンドと対象APIはスクリプトごとに確認します。

具体的な期日・対象タスク・バージョン

確認済み事実：専用告知では2026-11-24にサポートとセキュリティ更新等が終了します。提供終了エラーは表示されますが、それ自体でタスクやパイプラインは失敗しません。2027-03-15以降はタスクが削除され、参照するジョブ・パイプラインがブロックエラーで失敗します。この日程はAzure DevOps Services向けです。出典：タスク廃止告知。

確認済み事実：対象例にはAzurePowerShell@1からAzurePowerShell@5、AzureCloudPowerShellDeployment@1・@2からAzurePowerShell@5、DownloadPipelineArtifact@0からDownloadPipelineArtifact@2への置換が示されています。全対象は専用告知の一覧を照合してください。出典：タスク廃止告知。

日付の区別：専用告知の表示更新日＝2026-10-29、初回公表日＝null、サポート終了日＝2026-11-24、削除適用日＝2027-03-15、確認日＝2026-11-05です。AzureCloudPowerShellDeployment@1・@2の非推奨化日は2024-08-05で、今回のサポート終了日とは別です。旧AzurePowerShell@1の非推奨化日＝null。出典：タスク廃止告知。

編集上の資料照合：一般的なタスク説明ページの関連案内には10月15日という日付が残っています。本記事の日程は、より新しい10月29日更新の専用告知に基づきます。一般説明は版指定・実行制御の仕様確認に使用し、移行前には専用告知を再確認してください。

アーキテクチャ・実装・IaC：実行主体と入力を比較する

編集上の棚卸し：YAML、参照テンプレート、クラシックビルド・リリース、タスクグループを対象に、タスク名とメジャー版、実行条件、エージェントOS、サービス接続、成果物の入出力を記録します。旧版のリリース定義や保守ブランチに残る復旧用参照も調査します。

確認済み事実：AzurePowerShell@5は指定したAzure Resource Managerサービス接続で認証します。既定ではLinuxエージェントがPowerShell Core、WindowsがWindows PowerShellを使い、Windowsでpwsh=trueを指定するとPowerShell Coreを使います。azurePowerShellVersion、preferredAzurePowerShellVersion、errorActionPreference、FailOnStandardError等の入力があります。出典：AzurePowerShell@5リファレンス。

編集上の実装確認：旧入力をそのままコピーせず、azureSubscriptionに指定する接続の実行主体、テナント、サブスクリプション、RBACを実環境と照合します。権限不足の解決を目的とした恒久的な管理者権限の追加は移行の完了条件にせず、実行する操作から必要権限を定義します。

編集上のIaC検証：BicepやTerraformを実行するラッパータスク、Azモジュール、CLI、作業ディレクトリ、引数、状態保存先を比較します。planまたはwhat-ifで差分を確認したうえで検証環境へ適用し、リソースの実値を取得してください。タスク変更が対象リソースのAPI版を変更したかは、生成物や呼出し内容から個別に確認します。

運用・監視・フェイルオーバー・責任分界

確認済み事実：タスク共通のcontinueOnError=trueは失敗を後続処理で成功扱いにでき、conditionは後続ステップの実行を制御します。自動再試行はべき等性を保証しません。出典：タスクの種類と使用法。

編集上の監視案：パイプラインの成功率とは別に、対象旧タスクの残存件数、最後の実行、置換試験結果を管理します。11月24日以降も成功表示だけではサポート内の状態を証明できません。ログ文字列の検出を使う場合も、実際のログ形式と対象タスク一覧を照合し、未実行の定義は別途検査します。

編集上の異常系試験：認証失敗、必要モジュールの不足、スクリプトの異常終了を検証環境で発生させ、通知と承認ゲートが期待どおり動くか確認します。再試行で同じリソースや配布物を二重作成しないかも試験してください。秘密情報を出力する診断ログは避け、必要な構成情報だけを保全します。

編集上のDR検証：過去のアプリ成果物に戻すことと、削除される旧タスクを再実行することを分けます。現行の対応タスクから旧成果物を展開できるか、代替エージェントから別環境を再構成できるかを検証し、復旧時間を実測します。削除後に旧タスク参照へ戻す切戻しは成立すると仮定しません。

編集上の責任分界案：共通テンプレートは基盤担当、スクリプトと成果物の妥当性はアプリ担当、サービス接続の権限はID管理担当、通知と復旧試験は運用担当で分担します。委託先の作業完了と自社の受入判定を分け、対象外・残存項目・期限を記録してください。

適用上の前提：本記事は個別環境の設計保証や法的助言を行うものではありません。実装適用にあたっては、検証環境での事前テストおよび契約・業務範囲の確認が必要です。以下の実装チェックリストは編集上の提案です。