Azure Pipelines task library の v272/v273 更新で最初に見るべきなのは、「自分たちのパイプラインで使っているタスクが、非推奨化・セキュリティ修正・Node.js 24対応・実行時の挙動修正のどれに当たるか」です。特に AzureCLI、AzurePowerShell、Azure App Service/Function/ARM デプロイ系、FtpUpload、SQL DACPAC、VSTest、UniversalPackages、DownloadBuildArtifacts を使っているチームは、通常のリリースノート確認だけでなく、実行ログとカナリア実行まで確認しておくべきです。
2026年4月20日時点では、microsoft/azure-pipelines-tasks の v272 が 2026年3月31日、v273 が 2026年4月20日に公開されています。v272は依存パッケージ更新と一部タスクの安定化、v273はセキュリティ修正、非推奨化、Node.js 24移行、AzureCLI/VSTest/SQL/FTPまわりの実務影響が目立つリリースです。(GitHub)
まず確認すべき結論
Azure Pipelines task library の v272/v273 は、「新機能を試すかどうか」よりも「既存パイプラインが自動的に新しいマイナーバージョンを使って影響を受けないか」を確認する更新です。
Microsoft Learn では、Azure Pipelines のタスクはバージョン管理され、YAML では AzureCLI@2 のようにメジャーバージョンを指定します。新しいマイナーバージョンは通常自動的に使われ、メジャーバージョンが変わる場合は手動変更が必要です。つまり、YAMLを変更していなくても、同じ @2 や @3 の中で挙動が変わる可能性があります。(Microsoft Learn)
| 最初に見る観点 | 該当しやすいタスク | 初動 |
|---|---|---|
| 非推奨化 | AzureCLI@1、DownloadGitHubNpmPackage@1、DownloadGitHubNugetPackage@1 | 置き換え計画を作り、対象パイプラインを棚卸しする |
| セキュリティ修正 | Azure App Service、Azure Function、ARM、Azure CLI、Azure PowerShell、Key Vault、File Copy、Jenkins、Kubelogin など | 本番デプロイ系パイプラインを優先して再実行・ログ確認する |
| Node.js 24対応 | AppCenterDistribute@3、DownloadBuildArtifacts@0、AzureSpringCloud@0 など | self-hosted agent とカスタムタスクの互換性を確認する |
| 実行時不具合の修正 | AzureCLI@3、AzurePowerShell@5、VSTest@2/@3、FtpUpload@2、SQL DACPAC系 | 失敗していた既知シナリオが改善するか、逆に副作用がないかを確認する |
Azure Pipelines task library とは何が更新される場所か
Azure Pipelines task library は、Azure Pipelines で標準提供されるタスク群の実装リポジトリです。GitHub上の README では、Azure Pipelines と Team Foundation Server に標準提供されるタスクが含まれると説明されています。(GitHub)
Azure Pipelines のタスクは、ビルド、テスト、ツールインストール、Azureリソース操作などを行う自動化の部品です。Microsoft Learn の task reference でも、タスクはパイプラインを定義するための構成要素と説明されています。(Microsoft Learn)
実務上は、次のような場所で影響が出ます。
| 利用箇所 | 影響の出方 |
|---|---|
| YAML pipeline | AzureCLI@2、VSTest@3 などのタスク指定で影響を受ける |
| Classic build/release pipeline | UI上で選択しているタスクバージョンが更新対象になる |
| self-hosted agent | Node.jsランナー、ツールインストール、ネットワーク制限の影響を受けやすい |
| カスタムタスク/Marketplace拡張 | Node.jsランナー移行や非推奨ランタイムの影響を受けやすい |
| Azure DevOps Server | Azure DevOps Services と同じタイミング・同じ機能とは限らない |
オンプレミスの Azure DevOps Server を使っている場合は、Azure DevOps Services 向けのリリース内容をそのまま適用できるとは限りません。Microsoft Learn の task reference でも、利用中の Azure DevOps のバージョンによって機能サポートが異なるため、バージョンセレクターを確認するよう案内されています。(Microsoft Learn)
v272の要点: 依存パッケージ更新と安定化が中心
v272では、多くの Azure系タスクで task-lib と azure-arm-rest common package の更新が行われました。リリースノートでは、AzureAppServiceManage、AzureAppServiceSettings、AzureFunctionApp、AzureResourceGroupDeployment、AzureResourceManagerTemplateDeployment、AzureRmWebAppDeployment、AzureVmssDeployment、AzureWebAppContainer、JenkinsDownloadArtifacts、KubeloginInstaller などに同種の更新が入っています。(GitHub)
PR #21942 では、対象タスクで azure-arm-rest を 3.271.1 に更新し、このバージョンが OpenSSL 3.6.1 を使用すること、また azure-pipelines-task-lib が古いタスクでは 5.2.8 へ更新することが説明されています。(GitHub)
v272で特に実務上確認したいのは、次の4つです。
| 変更 | 対象 | 確認ポイント |
|---|---|---|
task-lib / azure-arm-rest 更新 | Azureデプロイ系タスク、Jenkins、Kubelogin | サービス接続、認証、Azure REST呼び出し、Key Vault取得のログ |
PublishTestResults@2 の retry-detection flag 読み取り改善 | テスト結果公開 | Linux agent で retry-detection 関連の環境変数を使っている場合 |
UniversalPackages@0 の ArtifactTool install pre-execution化 | Azure Artifacts | Universal Package のダウンロード/発行前のツール取得ログ |
VSTest@2/@3 の GetItemProperty対応 | Windows上のテスト実行 | 古い wmic 依存の問題が出ていた環境 |
PublishTestResults@2 では、Linux agent の非Windowsフローで retry-detection flag を環境変数からより確実に読む修正が入っています。該当フラグを使っていない通常のテスト結果公開では大きな挙動変化は起きにくい一方、再実行検出を使っているチームはログを確認する価値があります。(GitHub)
VSTest@2/@3 では、現代的なWindows環境で問題になりやすい wmic 依存を避け、PowerShell Get-ItemProperty を使う修正が入っています。古いテスト環境や Visual Studio Test Platform の検出で失敗していた場合は、改善が期待できます。(GitHub)
v273の要点: セキュリティ修正・非推奨化・Node.js 24対応
v273は、v272よりも影響範囲を広めに見積もるべきリリースです。リリースノートでは、@azure/msal-browser 4.x 脆弱性対応、AzureCLI@1 などの非推奨化、Node.js 24 migration、FtpUpload@2 の basic-ftp 更新、SQL DACPAC系のセキュリティ修正、VSTest@2/@3 のバージョン解析修正などがまとまっています。(GitHub)
Azure系タスクの @azure/msal-browser 脆弱性対応
v273では、多数のAzure関連タスクで @azure/msal-browser まわりの脆弱性対応が入っています。PR #21990 では、Component Governance alert 396990に対応するため、18の影響タスクで azure-pipelines-tasks-azure-arm-rest を 3.271.1 から 3.272.1 へ更新し、脆弱な @azure/[email protected] を置き換える流れが説明されています。(GitHub)
また PR #21986 では、CG alerts 396991/396992 に対して、@azure/[email protected] と 4.28.2 の高重大度脆弱性を解消するため、[email protected] 経由で @azure/[email protected] と @azure/[email protected] へ更新する内容が説明されています。(GitHub)
影響を受けやすいのは、次のようなタスクファミリーです。
| タスク領域 | 代表例 |
|---|---|
| Azure CLI / PowerShell | AzureCLI@2、AzureCLI@3、AzurePowerShell@4、AzurePowerShell@5 |
| Azure App Service / Web App | AzureAppServiceManage@0、AzureAppServiceSettings@1、AzureRmWebAppDeployment@3/@4/@5、AzureWebAppContainer@1 |
| Azure Functions | AzureFunctionApp@1/@2、AzureFunctionAppContainer@1、AzureFunctionOnKubernetes@0/@1 |
| ARM / Resource Group | AzureResourceGroupDeployment@2、AzureResourceManagerTemplateDeployment@3 |
| その他Azure系 | AzureKeyVault@2、AzureFileCopy@4/@5/@6、AzureVmssDeployment@0/@1、KubeloginInstaller@0、AzureMysqlDeployment@1 |
| 連携系 | JenkinsDownloadArtifacts@1/@2 |
これらは「ビルド」よりも「認証してAzureリソースを操作する」タスクが多いため、サービス接続、マネージドID、サービスプリンシパル、Key Vault参照、ARMテンプレートデプロイのログを優先して確認します。
AzureCLI@1などの非推奨化
v273で見逃せないのが、AzureCLI@1、DownloadGitHubNpmPackage@1、DownloadGitHubNugetPackage@1 の非推奨化です。リリースノートでは、これら3つのタスクを deprecate したことが明記されています。(GitHub)
PR #21950 では、AzureCLI@1 は AzureCLI@2 以降、DownloadGitHubNpmPackage@1 は Npm@1、DownloadGitHubNugetPackage@1 は NuGetCommand@2 または DotNetCoreCLI@2 への移行が示されています。(GitHub)
| 非推奨タスク | 推奨される移行先 | 実務での注意点 |
|---|---|---|
AzureCLI@1 | AzureCLI@2 またはそれ以降 | scriptType、認証方式、inline script の実行差分を確認する |
DownloadGitHubNpmPackage@1 | Npm@1 | GitHub Packagesやnpm feedの認証設定を先に整理する |
DownloadGitHubNugetPackage@1 | NuGetCommand@2 または DotNetCoreCLI@2 | NuGet.config、サービス接続、feed権限を確認する |
非推奨化は、即座に全パイプラインが失敗するという意味ではありません。ただし、リポジトリの DEPRECATION.md では、非推奨タスクには削除90日前にバナーが表示されること、移行ガイダンスは各タスク定義の deprecation message を参照することが説明されています。(GitHub)
Node.js 24 migrationはself-hosted agent利用者ほど重要
v273では、AppCenterDistribute@3、DownloadBuildArtifacts@0、AzureSpringCloud@0 などで Node.js 24 migration が入っています。(GitHub)
Azure Pipelines Agent の Node.js runner に関するMicrosoft Learnでは、Azure Pipelines Agent は 2026年1月から Node.js 24 を同梱し、拡張機能・カスタムタスク作成者は Node.js 24 で更新・テストする必要があると案内されています。あわせて、Node.js 20のサポート終了は2026年4月、削除日は2027年4月、Node.js 16/10/6の削除日は2026年11月とされています。(Microsoft Learn)
ここで重要なのは、標準タスクの一部がNode.js 24対応しても、Marketplace拡張や社内カスタムタスクが自動的に安全になるわけではないことです。self-hosted agentを運用しているチームは、次を確認してください。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| エージェントの種類 | Microsoft-hosted / self-hosted | self-hosted はNode runnerの同梱状況を必ず確認 |
カスタムタスクの task.json | execution セクション | 古い Node handler に依存していないか |
| Marketplace拡張 | 拡張の更新履歴 | Node.js 20/24対応の記載があるか |
| 実行ログ | warning / deprecation message | Node.js EOL警告が出ていないか |
AzureCLI@3の安定性改善
AzureCLI@3 では2つの実務的な修正が入っています。
1つ目は、az version が成功終了しても stdout が空になるケースに備え、az --version へフォールバックする修正です。PR #22009 では、UseAzVersion feature flag が有効な場合に az version の空出力で後続のバージョン解析が失敗するケースを避けるため、フォールバック条件を追加したと説明されています。(GitHub)
2つ目は、Azure DevOps CLI extension のインストール改善です。PR #22010 では、通常の az extension add -n azure-devops -y がネットワーク制限などで失敗した場合に、wheelファイルを取得して az extension add --source でインストールするフォールバックが追加されています。(GitHub)
企業ネットワーク、プロキシ、閉域寄りのself-hosted agentでAzure CLI拡張のインストール失敗が起きていた場合は、v273後に改善する可能性があります。ただし、フォールバック先へのアクセスもネットワーク制限を受けるため、プロキシ・許可リスト・TLS検査の設定確認は引き続き必要です。
SQL DACPAC系はfeature flagの状態まで確認する
SqlAzureDacpacDeployment@1 と SqlDacpacDeploymentOnMachineGroup@0 では、Invoke-Expression 利用箇所に関するセキュリティ修正が入っています。PR #21947 では、ユーザー指定の additional arguments によってPowerShellコマンドが注入されるリスクを防ぐ修正が説明されています。(GitHub)
ただし、このPRでは、サニタイズされた処理経路は Enable shell tasks arguments validation と EnableSqlAdditionalArgumentsSanitization の両方が有効な場合に使われると説明されています。つまり、v273を確認するだけでなく、自組織・対象パイプラインでfeature flagがどう扱われているかまで見ておくべきです。(GitHub)
特に次のような AdditionalArguments を使っている場合は、検証環境で実行してから本番に反映します。
| 引数パターン | 確認すべきこと |
|---|---|
セミコロン ; を含む | 値として扱われるか、区切りとして誤解されないか |
$() や $env: を含む | Azure Pipelines macroとPowerShell展開の期待値がずれていないか |
| シングルクォートや括弧を含む | 引数が欠落・変形していないか |
sqlpackage の /p: オプション | 従来と同じデプロイ結果になるか |
FtpUpload@2とVSTest@2/@3も確認対象
FtpUpload@2 では、脆弱性対応として basic-ftp パッケージの更新が行われています。PR #22017 では、以前 5.2.0 へ更新されたものの、そのバージョンも脆弱と判定されたため、5.3.0へ更新したと説明されています。(GitHub)
VSTest@2/@3 では、非数値の接頭辞・接尾辞を含むバージョン文字列から数値バージョンを抽出できるよう、単純なsplitではなく正規表現で major.minor.patch を抽出する修正が入っています。古いexeや特殊なバージョン表示を持つテスト環境で失敗していた場合は、改善対象になります。(GitHub)
影響範囲を洗い出す手順
まずは、YAMLリポジトリで対象タスクを機械的に検索します。rg が使える場合は、次のように確認できます。
rg -n "AzureCLI@1|DownloadGitHubNpmPackage@1|DownloadGitHubNugetPackage@1|AzureCLI@2|AzureCLI@3|AzurePowerShell@4|AzurePowerShell@5|AzureRmWebAppDeployment@3|AzureRmWebAppDeployment@4|AzureRmWebAppDeployment@5|AzureResourceManagerTemplateDeployment@3|AzureResourceGroupDeployment@2|AzureFunctionApp@1|AzureFunctionApp@2|AzureKeyVault@2|AzureFileCopy@4|AzureFileCopy@5|AzureFileCopy@6|FtpUpload@2|SqlAzureDacpacDeployment@1|SqlDacpacDeploymentOnMachineGroup@0|VSTest@2|VSTest@3|VsTest@2|VsTest@3|UniversalPackages@0|UniversalPackages@1|DownloadBuildArtifacts@0" .rg がない場合は、標準の grep でも構いません。
grep -RInE "AzureCLI@1|DownloadGitHubNpmPackage@1|DownloadGitHubNugetPackage@1|AzureCLI@2|AzureCLI@3|AzurePowerShell@5|FtpUpload@2|SqlAzureDacpacDeployment@1|VSTest@2|VSTest@3|DownloadBuildArtifacts@0" .Classic pipeline を使っている場合は、YAML検索だけでは漏れます。Azure DevOps のUIでClassic build/release pipelineを開き、次の観点で確認します。
| 確認対象 | 見るポイント |
|---|---|
| タスク名 | 非推奨化された Azure CLI v1、GitHub package download系がないか |
| タスクバージョン | @1、@2、@3 などのメジャーバージョン |
| Agent pool | Microsoft-hostedかself-hostedか |
| Service connection | Azure Resource Manager、service principal、secretの特殊文字 |
| 失敗履歴 | v272/v273適用後に増えた認証・パース・ツール取得エラー |
優先順位の付け方
全パイプラインを同時に修正しようとすると、リリース作業が止まりやすくなります。次の順で優先順位を付けると実務的です。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | 本番Azureリソースへデプロイするパイプライン | 認証・ARM・App Service・Function系の影響が事業影響に直結する |
| 高 | 非推奨タスクを使うパイプライン | 将来的な削除や警告対応を先送りしないため |
| 高 | SQL DACPACで追加引数を多用するパイプライン | 引数サニタイズとfeature flagの影響を受ける可能性がある |
| 中 | self-hosted agentで動くパイプライン | Node.js runner、プロキシ、ツールキャッシュの差が出やすい |
| 中 | VSTest、PublishTestResults、UniversalPackagesを使うCI | テスト結果・成果物取得の挙動差分を確認したい |
| 低 | 単純なスクリプト中心のCI | 対象タスクがなければ緊急度は低い |
カナリア実行で見るべきログ
確認用のカナリア実行では、単に「成功したか」だけで判断しないでください。次のログを見ます。
| ログ項目 | 見る理由 |
|---|---|
| タスクのVersion表示 | v272/v273系のタスクへ更新されているか確認する |
| deprecation warning | AzureCLI@1 などの警告を見逃さない |
| Node.js warning | 古いNode runner依存の警告がないか確認する |
| Azure認証ログ | service connection、Key Vault、ARM deployの失敗を早期発見する |
| Azure CLI extension install | azure-devops extension の通常インストール/フォールバックの挙動を確認する |
| SQL additional arguments | 引数が意図通り渡されているか確認する |
| Artifact/Test result | 成果物取得、テスト結果公開、VSTest検出が正常か確認する |
特に本番リリース系では、直近で成功した1本とv273後の1本を比較します。差分がないように見えても、警告が増えている場合は運用負債になります。
非推奨タスクの移行例
AzureCLI@1からAzureCLI@2以降へ移行する
AzureCLI@1 を使っている場合は、単に @2 に書き換えるだけで終わらせず、入力項目とスクリプトの実行方式を確認します。
- task: AzureCLI@2
inputs:
azureSubscription: 'my-service-connection'
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
az account show
az group list --output table確認するポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
azureSubscription | 既存のサービス接続名と一致しているか |
scriptType | bash、ps、pscore など実行環境に合っているか |
scriptLocation | inline scriptかscript pathか |
| 出力形式 | 後続ステップが az の出力をパースしていないか |
| 権限 | サービスプリンシパルやFederated credentialsの権限が足りているか |
GitHub package download系は標準タスクへ寄せる
DownloadGitHubNpmPackage@1 と DownloadGitHubNugetPackage@1 は、PR #21950でそれぞれ Npm@1、NuGetCommand@2 または DotNetCoreCLI@2 への移行が示されています。(GitHub)
移行時は、タスク置き換えより先に認証設計を見直します。GitHub Packages、Azure Artifacts、外部NuGet feedが混在している場合、タスクを変えたことで認証情報の参照先が変わることがあります。
| パッケージ種別 | 移行先候補 | 先に確認すること |
|---|---|---|
| npm | Npm@1 | .npmrc、registry、認証トークン、scope |
| NuGet | NuGetCommand@2 | NuGet.config、feed、service connection |
| .NET CLI中心 | DotNetCoreCLI@2 | restore、pack、publish の分離 |
よくある失敗パターン
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| YAMLを変えていないのに動作が変わった | 同一メジャーバージョン内のマイナー更新が自動適用された | タスクVersion表示と直近成功ログを比較する |
| 非推奨タスクを後回しにした | すぐ落ちないため優先度が下がる | 対象タスクを検索し、移行チケットを作る |
| SQL DACPACの引数が変形した | 引数サニタイズ、引用符、セミコロンの扱い | 検証環境で AdditionalArguments を個別テストする |
| self-hosted agentだけ失敗する | Node.js runner、プロキシ、ツールキャッシュ、権限の差 | Microsoft-hostedとself-hostedで同じジョブを比較する |
| Azure CLI extensionが入らない | ネットワーク制限、プロキシ、許可リスト不足 | wheel fallbackのログと外部アクセス可否を確認する |
| VSTestの検出に失敗する | バージョン文字列や古いexeの扱い | v273後のVSTestログでバージョン抽出結果を見る |
役割別の初動
| 役割 | 最初にやること | 目的 |
|---|---|---|
| DevOps engineers | YAML検索、カナリア実行、失敗ログ比較 | 影響パイプラインを最短で特定する |
| Azure DevOps admins | self-hosted agent、Node.js runner、タスク制限、非推奨警告を確認 | 組織全体の運用リスクを下げる |
| Build and release teams | 本番リリース系、SQL、FTP、Artifact、Testの代表パイプラインを検証 | リリース直前の予期しない失敗を防ぐ |
| Security/Platform teams | @azure/msal-browser、basic-ftp、SQL injection系修正の適用状況を確認 | 脆弱性対応の証跡を残す |
次に取るべきアクション
Azure Pipelines task library の v272/v273 release wave は、見た目の大きな機能追加よりも、既存パイプラインの土台を更新するリリースです。最初にやるべきことは、対象タスクの棚卸し、非推奨タスクの移行計画、self-hosted agentとNode.js 24対応の確認、本番系パイプラインのカナリア実行です。
対象タスクが見つかったら、すぐに本番YAMLを大きく書き換えるのではなく、代表パイプラインを1本ずつ検証します。特に AzureCLI@1、GitHub package download系、SQL DACPACの追加引数、Azureリソースデプロイ系タスクは、失敗してから対応するよりも、警告が出ている段階で移行した方が安全です。
v272/v273をきっかけに、Azure Pipelines task library の更新確認を定例運用に入れておくと、今後のNode.js runner移行、非推奨タスク削除、依存パッケージ脆弱性対応にも追随しやすくなります。
コメント