Azure Pipelines Agentsは、Azure Pipelinesでビルドやデプロイを実行するための「実行基盤」です。2026年5月8日付として確認される更新を見て、すぐに全パイプラインを書き換える必要があるわけではありません。GitHub上の対象ドキュメント履歴では、2026年5月7日の更新は非推奨メタデータの削除が中心で、エージェント仕様そのものの破壊的変更ではないと読み取れます。むしろ重要なのは、現在使っているAgentの種類、Node.jsランナー、ホストイメージ、ネットワーク許可、セルフホストAgentの更新設定を棚卸しすることです。(GitHub)
この記事では、Azure Pipelines Agentsの公式情報をもとに、管理者と開発者が確認すべき変更点、影響範囲、移行・展開時の注意点を実務目線で整理します。特に、Microsoft-hosted agents、Self-hosted agents、Azure Virtual Machine Scale Sets agents、Managed DevOps Poolsの使い分けに迷っているチームは、今の構成が本当に適切かを見直すきっかけにしてください。
まず結論：今回確認すべきポイントは「Agent更新」より「運用設計の見直し」
Azure Pipelines Agentsの更新情報を見るときは、更新日だけで「仕様変更が入った」と判断しないことが重要です。今回のようにドキュメントリポジトリ側でメタデータ整理が行われたケースでは、既存のYAMLやAgent poolに即時対応が必要とは限りません。一方で、公式ドキュメント全体では、Agentの選択肢、Node.jsランナーのライフサイクル、ホストイメージの更新、Managed DevOps Poolsの位置づけが継続的に変わっています。(Microsoft Learn)
管理者が優先して確認すべき項目は、次の5つです。
| 確認項目 | 影響を受けやすい環境 | すぐ確認すべき理由 |
|---|---|---|
| Agentの種類 | 全環境 | Microsoft-hosted、Self-hosted、VMSS、Managed DevOps Poolsで管理責任と制約が異なる |
| Agent.Version | Self-hosted agents | 古いAgentでは新しいタスクや機能が動かない可能性がある |
| Node.jsランナー | カスタムタスク、Marketplace拡張 | 古いNode.jsに依存するタスクは将来失敗する可能性がある |
| ホストイメージ | Microsoft-hosted agents | ubuntu-latest、windows-latest、macOS-latestの実体が変わる可能性がある |
| ネットワーク許可 | 社内環境・閉域環境へのデプロイ | IP範囲、プロキシ、VNet、ファイアウォール設計で失敗しやすい |
Azure Pipelines Agentsとは何か
Azure Pipelines Agentsは、Azure Pipelinesのジョブを実行するコンピューティング環境です。パイプラインが実行されると、システムは1つ以上のジョブを開始し、Agentはインストール済みのAgentソフトウェアを使ってジョブを処理します。基本的に、1つのAgentは一度に1つのジョブを実行します。(Microsoft Learn)
開発者から見ると、Agentは「ビルドコマンドやテストコマンドが実際に走る場所」です。管理者から見ると、Agentは「OS、ツール、権限、ネットワーク、コスト、セキュリティを管理する対象」です。この視点の違いを押さえないと、パイプラインの失敗原因をYAMLだけで探してしまい、実際にはAgent poolやネットワーク設定が原因だった、という切り分けミスが起きます。
Azure Pipelines Agentsの種類と選び方
Azure Pipelinesでは、主に4種類のAgentを使い分けます。公式ドキュメントでは、Microsoft-hosted agents、Self-hosted agents、Managed DevOps Pools agents、Azure Virtual Machine Scale Sets agentsが整理されています。(Microsoft Learn)
| Agentの種類 | 向いているケース | 注意点 |
|---|---|---|
| Microsoft-hosted agents | まずCI/CDを始めたい、標準ツールで足りる、管理負荷を下げたい | 毎回新しいVMが割り当てられるため、ジョブ間でファイルや設定は残らない |
| Self-hosted agents | 独自ツール、社内ネットワーク、永続キャッシュ、特殊な権限が必要 | OS更新、Agent更新、セキュリティ、クリーンアップを自分たちで管理する |
| Azure Virtual Machine Scale Sets agents | 自前Azureサブスクリプション上で自動スケールしたい | VMSSの作成・権限・ネットワーク設計が必要。macOSには対応しない |
| Managed DevOps Pools agents | カスタムAgent poolを楽に作り、スケールと管理をMicrosoft側に寄せたい | 対応リージョン、ネットワーク、イメージ、コスト設計を事前に確認する |
初心者や小規模チームは、まずMicrosoft-hosted agentsで開始するのが現実的です。依存ツールのインストールに時間がかかる、社内リソースに接続する、ビルド時間が長い、標準マシンのCPU・メモリ・ディスクが足りない、といった課題が出たら、Self-hosted agentsやManaged DevOps Poolsを検討します。
2026年時点で注目すべき変更点と影響範囲
2026年5月の更新は、仕様変更ではなくドキュメント管理上の更新として見る
対象ドキュメントのGitHub履歴では、2026年5月7日に「Remove deprecated ms.assetid metadata from all articles」というコミットがあり、655ファイルに影響するメタデータ整理が行われています。これはAzure Pipelines Agentの動作変更やYAML構文の変更ではなく、ドキュメント管理上の更新と見るのが妥当です。(GitHub)
そのため、管理者が取るべき行動は「更新日を見て慌てて設定変更する」ことではありません。Agent poolの一覧、Agent.Version、Node.jsランナー、イメージラベル、ネットワーク許可リストを確認し、将来の廃止・移行に備えることが実務上の優先事項です。
Managed DevOps Poolsは、VMSS Agentの移行候補として重要度が上がっている
公式ドキュメントでは、Managed DevOps PoolsはAzure DevOps Virtual Machine Scale Set agent poolsの進化形として説明されています。Agentを動かすVMやコンテナはユーザー自身のAzureサブスクリプションではなく、Microsoftが管理するAzureサブスクリプション側に配置されます。(Microsoft Learn)
特に、現在VMSS Agentを使っている組織は、Managed DevOps Poolsを比較対象に入れるべきです。Managed DevOps Poolsは、複数イメージの利用、数千Agent規模への対応、専用クォータ、複数Azure DevOps組織での利用など、VMSS Agentより運用しやすい機能を持つ一方、VMSS拡張スクリプトが使えない、VM予約が使えないなどの違いもあります。(Microsoft Learn)
| 観点 | VMSS agents | Managed DevOps Pools |
|---|---|---|
| VMの配置 | 自社Azureサブスクリプション | Microsoft管理のAzureサブスクリプション |
| スケール | 数百Agent規模 | 数千Agent規模に対応 |
| イメージ | 基本的に単一イメージ | 複数イメージをサポート |
| クォータ | Computeクォータを他サービスと共有 | Managed DevOps Poolsリソース専用 |
| 拡張スクリプト | 利用可能 | 非対応。必要なソフトはカスタムイメージ側で準備 |
| 移行時の注意 | 既存VMSS設定を維持しやすい | 設定項目の対応関係を確認して再設計する |
VMSS Agentをそのまま使い続けるべきケースもあります。たとえば、既存のVMSS拡張スクリプトに強く依存している場合や、サブスクリプション内のネットワーク設計を細かく制御したい場合です。一方、Agent poolの作成・更新・スケール管理に工数がかかっているなら、Managed DevOps Poolsへの段階移行を検討する価値があります。
Node.jsランナーのライフサイクルがカスタムタスクに影響する
Azure Pipelines Agentには、異なるNode.jsハンドラーを使うタスクをサポートするため、複数バージョンのNode.jsライブラリが含まれています。公式情報では、Azure Pipelines Agentは2026年1月からNode.js 24を含むようになり、Node.js 6、10、16は2026年11月に削除予定とされています。Node.js 20はAzure Pipelines上のサポート終了が2026年4月、削除予定が2027年4月です。(Microsoft Learn)
影響を受けるのは、主に次のような環境です。
| 対象 | 影響 | 対応 |
|---|---|---|
| 自作のAzure DevOps拡張 | 古いNode.jsハンドラー指定だと将来実行できない可能性がある | task.jsonの実行ハンドラーを確認し、現行Node.jsでテストする |
| Marketplaceの古いタスク | メンテナンス状況によって警告や失敗が出る可能性がある | タスクの更新履歴を確認し、代替タスクも検討する |
| Self-hosted agents | 古いAgentパッケージを使い続けるとランナー差分が残る | Agent.Versionを確認し、更新計画を作る |
| レガシー業務パイプライン | 警告を無視していると廃止時に突然止まる | 警告ログを定期的に確認する |
開発者は、ビルドエラーが出てから対応するのではなく、パイプラインログにNode.js関連の警告が出ていないかを確認してください。特に、社内で作ったカスタムタスクは「一度作って放置」されがちです。CI/CDの基盤変更時に最も止まりやすいのは、こうした見えにくい依存関係です。
Microsoft-hosted agentsのイメージ更新にも注意が必要
Microsoft-hosted agentsは管理が簡単ですが、指定したVMイメージの最新状態が毎回使われます。公式ドキュメントでは、Windows Server 2025 with Visual Studio 2026のパブリックプレビュー、Windows Server 2019 hosted agent imageの引退、Ubuntu 24.04、macOS 26のプレビュー、macOS 14 Sonomaの非推奨予定などが示されています。(Microsoft Learn)
特に注意したいのは、ubuntu-latest、windows-latest、macOS-latestのような「latest」指定です。便利ですが、実体が変わるとSDK、コンパイラ、Xcode、.NET、Node.js、ブラウザ、CLIツールのバージョン差分でビルドが壊れることがあります。
安定性を優先する本番向けパイプラインでは、以下のように明示的なイメージラベルを使う方が安全です。
pool:
vmImage: 'ubuntu-24.04'一方、常に新しい環境で検証したい検証用パイプラインでは、ubuntu-latestを使い、破壊的な差分を早めに検知する運用も有効です。本番と検証で同じYAMLを使い回すのではなく、目的に応じてイメージ指定を分けるのが実務的です。
管理者が確認すべきAzure Pipelines Agentsの設定
Agent.Versionを確認し、Self-hosted agentsの更新計画を作る
Azure Pipelinesでは、Agentソフトウェアが数週間ごとに更新されます。Microsoft-hosted agentsはMicrosoft側で最新状態が維持されますが、Self-hosted agentsでは自動更新や手動更新の扱いを理解しておく必要があります。公式ドキュメントでは、マイナーバージョン差分の場合は自動更新できる一方、対話モードで動かしている場合やメジャーバージョン更新では手動更新が必要になる可能性があると説明されています。(Microsoft Learn)
Azure DevOps CLIを使える環境では、次のようにAgent一覧やCapabilitiesを確認できます。
az pipelines agent list \
--pool-id <pool-id> \
--include-capabilities true \
--output table個別Agentの詳細を見る場合は、次のコマンドを使います。
az pipelines agent show \
--pool-id <pool-id> \
--agent-id <agent-id> \
--include-capabilities true確認すべきポイントは、Agent.Version、OS、インストール済みツール、オンライン状態、最後に実行したジョブです。古いAgentが残っている場合は、すぐに更新するだけでなく「なぜ更新されていないのか」を確認してください。サービスとして動作していない、ネットワーク制限でパッケージを取得できない、対話モード運用になっている、などの原因が考えられます。
Capabilitiesとdemandsを見直す
Self-hosted agentsには、実行可能な内容を示すCapabilitiesがあります。Agentが検出するSystem capabilitiesと、管理者が追加するUser capabilitiesがあり、パイプライン側のdemandsと一致するAgentにジョブが割り当てられます。(Microsoft Learn)
たとえば、特定のソフトウェアが入っているAgentだけでジョブを実行したい場合は、次のように指定できます。
pool:
name: Default
demands:
- SpecialSoftware
- Agent.OS -equals Linux注意点は、ソフトウェアをインストールしただけではCapabilitiesに反映されない場合があることです。公式ドキュメントでは、Self-hosted agentに新しいソフトウェアをインストールした後、新しいCapabilityを表示するにはAgentの再起動が必要とされています。(Microsoft Learn)
また、環境変数がCapabilitiesとして保存される点にも注意が必要です。機密性のある環境変数や頻繁に変わる変数をCapabilitiesに含めたくない場合は、VSO_AGENT_IGNOREで除外対象を指定します。たとえば、PATHはソフトウェア追加時に変わりやすいため、状況によっては除外を検討すべき変数です。(Microsoft Learn)
ネットワーク許可リストは「最新のIP範囲」を前提に運用する
Microsoft-hosted agentsから社内システムやファイアウォール配下のAzureリソースへアクセスさせる場合、IP許可リストの管理が必要になります。MicrosoftはAzureデータセンターのIP範囲を週次JSONファイルで公開しており、公式ドキュメントでは少なくとも週1回の確認が推奨されています。(Microsoft Learn)
ここで失敗しやすいのは、次の3点です。
| 失敗しやすい点 | 起きる問題 | 対策 |
|---|---|---|
| 古いIP範囲を許可したまま | ある日突然デプロイや接続テストが失敗する | 週次でIP範囲を更新する運用を作る |
| Azure DevOps組織のリージョンだけを許可 | 実際のAgent配置リージョンをカバーできない | Geography単位で関連リージョンを確認する |
| Service tagで簡単に許可できると思い込む | Microsoft-hosted agentsはService tagで単純に列挙できない | 公式手順に沿ってIP範囲で許可する |
また、Microsoft-hosted agentsから企業ネットワークへExpressRouteやVPNなどのプライベート接続で直接つなぐことはできず、通信はパブリックネットワーク経由になります。閉域性が重要なシステムへデプロイする場合は、Self-hosted agents、VMSS agents、Managed DevOps Poolsを検討してください。(Microsoft Learn)
Agent実行アカウントは最小権限で設計する
Self-hosted agentは、サービスまたは対話プロセスとして実行できます。本番運用では、OSのサービスマネージャーで管理でき、自動起動しやすいサービス実行が基本です。Windowsでは、Network ServiceやLocal Serviceのような権限が制限され、パスワード期限切れの影響を受けにくいサービスアカウントが推奨されています。(Microsoft Learn)
ただし、UIテストやブラウザ操作が必要な場合は、対話モードが必要になることがあります。この場合、自動サインインやスクリーンセーバー無効化に伴うセキュリティリスクがあります。UIテスト用Agentは、通常のビルドAgentと同じマシンに混在させず、物理的・ネットワーク的に保護された専用環境で運用するのが安全です。
開発者が確認すべきYAMLとタスク設定
pool指定が意図した場所にあるか確認する
YAMLでは、poolをパイプライン全体、ステージ、ジョブなど複数レベルで指定できます。公式ドキュメントでも、期待したイメージで実行されない場合は、どのレベルでpoolが指定されているか確認するよう説明されています。(Microsoft Learn)
次のようにジョブごとにOSを分けることもできます。
jobs:
- job: LinuxBuild
pool:
vmImage: 'ubuntu-24.04'
steps:
- script: echo "Build on Linux"
- job: WindowsBuild
pool:
vmImage: 'windows-2025'
steps:
- script: echo "Build on Windows"失敗しやすいのは、テンプレート側でpoolが上書きされているケースです。リポジトリ直下のYAMLだけでなく、共通テンプレート、ステージテンプレート、ジョブテンプレートも確認してください。
パスのハードコーディングを避ける
Microsoft-hosted agentsでは、毎回新しいVMが割り当てられ、ジョブ完了後に破棄されます。公式ドキュメントでは、ビルド環境やAgentリソースを参照する際に、ドライブ文字やリポジトリフォルダーをハードコーディングせず、変数を使うよう注意されています。(Microsoft Learn)
避けたい例は次のような指定です。
steps:
- script: dir C:\a\1\s代わりに、定義済み変数を使います。
steps:
- script: echo "$(Build.SourcesDirectory)"Self-hosted agentsでは作業ディレクトリが残りやすいため、逆に「前回の成果物が残っていてテストが通った」という事故も起きます。Microsoft-hosted agentsとSelf-hosted agentsを切り替える場合は、ワークスペースのクリーンアップ設定も一緒に見直してください。
カスタムタスクはNode.js依存を確認する
Azure Pipelinesの公式タスクはNode.js 20をユニバーサルハンドラーとして使う一方、顧客側のカスタムタスクではサポート終了済みのNode.jsバージョンに依存している可能性があります。公式ドキュメントでは、拡張機能やカスタムタスクの作成者に対し、現在のNode.jsバージョンで更新・テストすることが求められています。(Microsoft Learn)
確認手順はシンプルです。
| 手順 | 確認内容 |
|---|---|
| タスク一覧を洗い出す | 自作タスク、社内拡張、古いMarketplaceタスクを一覧化する |
| task.jsonを見る | 古いNode.jsハンドラー指定がないか確認する |
| 検証用Agentで実行する | Node.js 20または24を前提にテストする |
| 警告ログを確認する | パイプライン実行時のNode.js廃止警告を無視しない |
| 代替策を用意する | 更新されない外部タスクは置き換え候補を探す |
移行・展開時の注意点
Microsoft-hosted agentsを使い続ける場合
Microsoft-hosted agentsは、管理負荷を最小化したいチームに向いています。VMイメージは定期的に更新され、ジョブごとに新しいVMが使われるため、クリーンな環境で実行できます。一方で、ディスク容量やマシンスペックを個別に増やすことはできず、事前に独自ソフトウェアをプリロードすることもできません。必要なソフトはジョブ中にインストールするか、別のAgent方式を検討します。(Microsoft Learn)
判断基準は明確です。標準イメージでビルドが完了し、実行時間も許容範囲ならMicrosoft-hosted agentsで十分です。逆に、依存ツールのインストールだけで数分かかる、Dockerイメージのpullが重い、社内DBや閉域APIに接続する、ビルド成果物が大きすぎる場合は、Self-hosted agentsやManaged DevOps Poolsを検討します。
Self-hosted agentsを使う場合
Self-hosted agentsは自由度が高い反面、管理責任も増えます。公式ドキュメントでは、1台のマシンに複数Agentをインストールすることは可能としながらも、パフォーマンスやパイプライン結果に悪影響が出る可能性があるため、1マシン1Agentが強く推奨されています。(Microsoft Learn)
複数Agentを同じマシンに載せると、CPU、メモリ、ディスクI/O、npmやNuGetなどの共有キャッシュ、ブラウザテストのセッションが競合する可能性があります。特にビルドジョブはディスクI/Oを多く消費するため、「Agent数を増やしたのに遅くなった」という状態になりがちです。
Self-hosted agentsでは、次の運用ルールを最初に決めてください。
| 項目 | 推奨される運用 |
|---|---|
| OS更新 | 定期メンテナンス枠を決める |
| Agent更新 | Agent.Versionを定期確認し、必要時に更新する |
| 実行ユーザー | 最小権限のサービスアカウントを使う |
| ワークスペース | 不要ファイルを定期削除する |
| 機密情報 | 環境変数やCapabilitiesへの露出を避ける |
| 未信頼コード | 社内ネットワークに近いAgentでは実行しない |
VMSS agentsを展開する場合
Azure Virtual Machine Scale Sets agentsは、自前Azureサブスクリプション上で自動スケールするSelf-hosted agentを構成したい場合に使います。ただし、Azure PipelinesがVMSSのスケールを管理するため、VMSS側の自動スケールやオーバープロビジョニングは無効化する必要があります。公式ドキュメントでは、--disable-overprovisionと--upgrade-policy-mode manualが必要な設定として示されています。(Microsoft Learn)
また、VMSSイメージにAzure Pipelines Agentを事前インストールしてはいけません。Azure Pipelinesが新しいVMをプロビジョニングするときにAgentを自動インストールするためです。カスタムイメージには、ビルドに必要なSDK、CLI、証明書、プロキシ設定などを入れ、Agent本体はAzure Pipelinesに任せます。(Microsoft Learn)
VMSS agentsはWindowsとLinuxで利用できますが、macOS AgentはVMSSでは実行できません。また、Azure DevOps Services向けのVMSS Agent poolはAzure Publicのグローバルクラウドでサポートされ、他のナショナルクラウドでは制約があります。(Microsoft Learn)
Managed DevOps Poolsへ移行する場合
Managed DevOps Poolsへ移行する場合は、既存VMSS Agent poolの設定をそのままコピーするのではなく、設定項目の対応関係を確認して再設計します。たとえば、VMSSの「Automatically tear down virtual machines after every use」は、Managed DevOps PoolsではStateless poolまたはStateful poolの選択に対応します。Standby Agent数は、All week scheme、Flexible schedule、Automatic standby agent schedulingなどで置き換えます。(Microsoft Learn)
移行は一気に行わず、次の順序で進めるのが安全です。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 棚卸し | 既存VMSS poolのイメージ、ネットワーク、最大Agent数、待機Agent数を記録 | 現在の設定が説明できる状態にする |
| 検証 | Managed DevOps Poolsで同等のテスト用poolを作る | 非本番パイプラインが通る |
| 比較 | 実行時間、待機時間、コスト、失敗率を比較 | 移行メリットが数値で見える |
| 段階移行 | 影響の小さいパイプラインからpool名を切り替える | ロールバック手順を用意する |
| 本番適用 | 重要パイプラインを移す | 監視とログ確認を継続する |
Managed DevOps Poolsでは、2026年4月にAzure Pipelines Generation 2 imagesが提供され、従来のGeneration 1 Azure Pipelines imagesは更新されなくなったため、Generation 2への移行が推奨されています。Managed DevOps Poolsを使っている、または検討しているチームは、イメージ世代も確認してください。(Microsoft Learn)
よくある失敗と対策
latest指定に依存してビルドが突然壊れる
ubuntu-latestやwindows-latestは便利ですが、長期運用ではリスクがあります。SDKやランタイムの削除、OSイメージの変更、Visual StudioやXcodeの更新でビルドが失敗することがあります。本番パイプラインでは明示的なバージョン指定を使い、検証用パイプラインでlatestを試す運用が安全です。
Agentを更新したのにCapabilitiesが変わらない
Self-hosted agentにソフトウェアを追加しても、Agentを再起動しないとCapabilitiesに反映されないことがあります。インストール手順書には、必ず「Agent再起動」と「Capabilities確認」を入れてください。(Microsoft Learn)
ファイアウォールの許可リストを一度設定して放置する
Microsoft-hosted agentsのIP範囲は変わります。許可リストを固定したままにすると、ある日突然デプロイが失敗します。週次のIP範囲更新を手動で確認するのが難しい場合は、取得・比較・通知を自動化してください。(Microsoft Learn)
Self-hosted agentsで未信頼コードを実行する
社内ネットワークに接続できるSelf-hosted agentで、外部コントリビューターのコードや未レビューのスクリプトを実行するのは危険です。Microsoft-hosted agentsはジョブごとに再イメージ化されるため、未信頼コードの実行ではSelf-hosted agentsより安全な選択になる場合があります。(Microsoft Learn)
これから取るべき実務アクション
まず、Azure DevOpsのAgent poolsを開き、すべてのAgent poolを一覧化してください。次に、各poolについて「Agentの種類」「Agent.Version」「OSイメージ」「Node.js関連の警告」「ネットワーク接続先」「実行アカウント」「Capabilitiesとdemands」を確認します。
そのうえで、次の優先順位で対応すると効率的です。
| 優先度 | 対応内容 |
|---|---|
| 高 | 古いSelf-hosted agent、Node.js 6/10/16依存タスク、期限が近いホストイメージを洗い出す |
| 中 | latest指定を本番用と検証用で分け、イメージ更新の影響を早期検知する |
| 中 | Microsoft-hosted agentsのIP許可リスト更新手順を整備する |
| 中 | VMSS agents利用中のチームはManaged DevOps Poolsとの比較表を作る |
| 低 | 将来のManaged DevOps Pools機能やGeneration 2 imagesへの移行計画を整理する |
Azure Pipelines Agentsの運用で大切なのは、Agentを単なる「実行マシン」と見ないことです。Agentは、CI/CDの速度、安定性、セキュリティ、コストを左右する基盤です。2026年5月の更新をきっかけに、まずは現在のAgent poolを棚卸しし、古いNode.js依存、更新されていないSelf-hosted agent、曖昧なlatest指定、放置されたIP許可リストから順に見直してください。
コメント