Azure Pipelines Agent v4.272.0 が 2026年4月8日に公開されました。派手な大型リリースではありませんが、セルフホスト エージェントを運用しているなら見逃しにくい更新です。GitHub Releases 上では pre-release 扱いなので、本番プールを一斉更新するより、影響のあるパイプラインを絞って検証するのが現実的です。特に、TRX の再実行でテスト結果がぶれやすい環境、fetchFilter と submodule を併用する大きなリポジトリ、4.x/.NET 8 前提の互換性管理を進めているチームは確認しておく価値があります。(GitHub)
なお、Azure Pipelines では GitHub Actions の「runner」に近いものも、正式には self-hosted agent と呼ばれます。この記事では、Azure Pipelines Agent v4.272.0 の変更点、実際に効く場面、すぐ更新すべきかの判断基準、安全な展開手順まで、セルフホスト エージェント運用の視点で整理します。(Microsoft Learn)
Azure Pipelines Agent v4.272.0 の変更点
公開情報を実務向けに要約すると、今回のリリースで押さえるべき点は次の3つです。(GitHub)
| 変更点 | 内容 | 影響が大きいケース |
|---|---|---|
| TRX 再実行検知 | 再実行された TRX を識別し、最新試行ベースで最終合否を評価できるよう改善 | flaky test の再実行を使う CI |
submodule の fetchFilter | git submodule update にも filter を渡せるよう改善 | 大きな submodule を持つリポジトリ |
| 配布パッケージの選択 | vsts-agent-* と pipelines-agent-* の使い分けが重要 | 旧 Node 依存 task を残す環境 |
ここで重要なのは、今回の2つの機能変更がどちらも「入れた瞬間に全パイプラインで自動有効」ではないことです。TRX 再実行検知は isDetectTestRunRetry が有効なときだけ動作し、submodule への fetchFilter 反映も UseFetchFilterInGitSubmoduleUpdate が既定で false です。つまり v4.272.0 は、既存環境を壊さずに互換性の穴を埋めるための下地を入れた更新、と見るのが実務的です。(GitHub)
また、同じ GitHub Releases ページでは v4.272.0 が pre-release、v4.271.0 が Latest と表示されています。すぐに全台更新するより、まず検証用プールで確認し、その後に段階展開するほうが安全です。(GitHub)
小さな更新でもセルフホスト運用で無視しにくい理由
Azure Pipelines のエージェントは広く後方互換ですが、Microsoft は「サポートするのは最新エージェントのみ」と案内しています。さらに Azure Pipelines では、プラットフォーム機能や task 側の要件によって新しい agent が必要になることがあり、互換性のある agent が見つからないとパイプライン実行は失敗します。変更点が少なく見えるリリースでも、セルフホスト エージェントでは放置コストが発生しやすい、ということです。(Microsoft Learn)
この点で、Microsoft-hosted agents はメンテナンスと更新が自動で進みます。一方、セルフホスト エージェントは、自分たちで更新タイミング、検証範囲、配布パッケージ、ホスト OS の互換性まで管理しなければなりません。v4.272.0 が重要なのは、まさにこのセルフホスト側の運用負荷に直結するからです。(Microsoft Learn)
変更点を実務でどう見るべきか
テスト再実行時の結果が実態に近づく
PR #5496 では、再実行された TRX ファイルを検知し、同じテストの 最新試行だけ で最終結果を評価できるようにしています。従来は retry ごとに独立した test run として扱われ、最初は失敗しても再実行で成功した flaky test が、全体としては失敗件数を水増しする可能性がありました。Azure DevOps でも「最初は失敗、再実行で成功」は flaky test の典型例として扱われているため、この改善は test summary の精度を上げる方向の変更です。(GitHub)
| ケース | 従来の見え方 | v4.272.0 で期待できる方向 |
|---|---|---|
| 同一テストが失敗 → 再実行で成功 | 失敗件数が膨らみやすい | 最新試行ベースでの評価に寄せやすい |
| flaky test が多い環境 | ノイズが多く分析しづらい | 本当に直すべき失敗を見分けやすい |
ただし、この挙動は既定でオフです。上流タスクが isDetectTestRunRetry=true を渡す設計なので、agent を v4.272.0 にしただけで全パイプラインの test summary が即座に変わるわけではありません。逆に言えば、既存の見え方を壊さずに段階導入しやすい更新でもあります。(GitHub)
fetchFilter と submodule の組み合わせがようやく実務向きになる
fetchFilter は Azure Pipelines の checkout で使える既存機能で、blob:none や tree:0 による partial clone を指定できます。ところが PR #5518 によると、従来はこの filter が親リポジトリの git fetch にしか効かず、submodules: true や submodules: recursive を使うと submodule 側がフル clone になっていました。v4.272.0 では、専用フラグが有効な場合に限り、git submodule update にも --filter を付けられるようになります。(Microsoft Learn)
steps:
- checkout: self
fetchFilter: blob:none
submodules: recursiveこの改善が効くのは、巨大な monorepo、履歴に大きな blob を多く抱える submodule、拠点間 VPN 越しで clone が遅い build node です。セルフホスト エージェントはキャッシュやディスク運用を自前で最適化することが多いため、「親だけ軽くなって、submodule は重いまま」という無駄を減らせる可能性があります。ただし、これも既定ではオフなので、fetchFilter を書いただけで submodule まで自動で軽量化される、と考えないほうが安全です。(GitHub)
4.x 系の互換性管理では OS と配布パッケージを見誤れない
4.x agent は .NET 8 ベースです。.NET 8 に非対応の OS でセルフホスト エージェントを動かしているなら、先にホスト OS を更新する必要があります。Azure DevOps Services では 3.x agent はサポート外で、4.x の利用が推奨されています。さらに Azure DevOps Server では、サーバーの世代ごとにサポートされる agent バージョンが異なります。クラウドと同じ感覚で「とりあえず最新 agent を入れる」と進めると、OS や Server 側の前提でつまずきやすい点は見落とせません。(Microsoft Learn)
GitHub では、v4.272.0 に対して従来互換の vsts-agent-* と、旧 Node を含まない pipelines-agent-* の2系統が提供されています。ここは単なるファイル名の違いではなく、task 互換性に直結します。(GitHub)
| パッケージ系統 | 含まれる Node ランタイム | 向いている環境 |
|---|---|---|
vsts-agent-* | 6, 10, 16, 20, 24 | 古い custom task / marketplace task が残る環境 |
pipelines-agent-* | 16, 20, 24 | 旧 Node 依存を減らしたい環境 |
サードパーティ task や社内 task が古い Node handler を前提にしている可能性が少しでもあるなら、いきなり pipelines-agent-* に寄せるより、まずは vsts-agent-* で更新し、依存を棚卸ししてから軽量系パッケージへ寄せるほうが失敗しにくいです。(GitHub)
今すぐ更新するべきかの判断基準
ここまでを踏まえると、Azure Pipelines Agent v4.272.0 の扱いは次のように切り分けると判断しやすくなります。(GitHub)
| 状況 | 判断の目安 |
|---|---|
| Microsoft-hosted agent のみ使っている | 原則として手動対応は不要 |
| セルフホストで TRX 再実行や flaky test の見え方に困っている | v4.272.0 を検証候補にする価値が高い |
セルフホストで fetchFilter + submodule を使う大規模リポジトリを運用している | 検証用プールで効果確認する価値が高い |
| 本番プールしかなく、現状問題がない | pre-release なので v4.271.0 維持や後続 stable 待ちも妥当 |
| Azure DevOps Server の旧世代を使っている | 先に server と agent の対応関係を確認する |
要するに、今すぐ全員が飛びつく更新ではないが、該当するユースケースを持つセルフホスト運用者には見逃しにくい という位置づけです。
セルフホストエージェントを安全に更新する手順
事故を避けたいなら、更新は次の順序で進めるのが堅実です。
| 手順 | 具体的にやること | 確認ポイント |
|---|---|---|
| 影響調査 | 対象 pool、ホスト OS、配布パッケージ、代表的な pipeline を洗い出す | 4.x/.NET 8 対応か |
| カナリア更新 | 1台または 1 pool だけ v4.272.0 にする | checkout と test publish の挙動 |
| 配布方法の選択 | UI 更新か、手動入れ替えか決める | 手動なら checksum を照合 |
| 段階展開 | 問題なければ pool 単位で広げる | third-party task の互換性 |
Agent pools 画面からは Update all agents や個別の Update agent を実行できます。手動で差し替える場合は、GitHub Releases に掲載されている SHA-256 を照合しておくと、運用上の安心感が大きくなります。また、長期運用のセルフホスト エージェントは interactive 実行より service 実行のほうが自動更新の体験がよい、という Microsoft の案内も押さえておきたいポイントです。(Microsoft Learn)
検証で見るべきログ
v4.272.0 を試すなら、次の3点を見ると成否を判断しやすくなります。(GitHub)
- submodule を使う pipeline で、checkout 周りのログに
git submodule updateと filter 関連の挙動が反映されているか - TRX を publish する pipeline で、再実行を含む test summary が従来より実態に近いか
- marketplace task や社内 task で Node handler 由来のエラーが出ていないか
更新時にハマりやすいポイント
v4.272.0 は変更点自体は少なめですが、運用では次の勘違いが起きやすいです。(GitHub)
| 落とし穴 | 起きる理由 | 回避策 |
|---|---|---|
| pre-release を stable と同じ感覚で全台更新する | GitHub 上では正式安定版扱いではない | まず検証用プールで確認する |
fetchFilter を書けば submodule も軽くなると思う | 反映は専用フラグ前提で既定はオフ | ログで実際のコマンドを確認する |
| agent を上げれば test summary が自動で変わると思う | TRX 再実行検知も既定はオフ | task 側の有効化状況を確認する |
pipelines-agent-* に変えても全部動くと思う | 旧 Node 依存 task が残っている可能性がある | task 棚卸し後に切り替える |
| Azure DevOps Server でもクラウド同様に最新 agent を入れればよいと思う | server バージョンごとに対応 agent が異なる | server 側のサポート行列を先に確認する |
最初にやるべきことは単純です。自分の pool が Microsoft-hosted か self-hosted かを切り分け、そのうえで TRX 再実行, fetchFilter + submodule, 古い Node 依存 task, .NET 8 対応 OS の4点を確認してください。1つでも当てはまるなら、Azure Pipelines Agent v4.272.0 は検証する価値があります。逆に当てはまらないなら、pre-release であることを踏まえ、現行 stable を維持しつつ次の stable を待つ運用でも十分に合理的です。(GitHub)
コメント