Microsoft-hosted agents for Azure Pipelinesを利用している場合、まず確認すべき結論は「使っているVMイメージのラベル」「非推奨予定のイメージ」「ネットワーク許可リスト」「ビルド環境をハードコーディングしていないか」の4点です。特に、windows-latest、ubuntu-latest、macOS-latestのような“latest系”ラベルは便利ですが、将来のイメージ更新でツールやOSの前提が変わる可能性があります。
本記事では、Microsoft AzureのAzure Pipelinesで使うMicrosoft-hosted agentsについて、2026年5月8日時点で管理者・開発者が押さえるべき変更点、影響範囲、移行時の注意点を実務目線で整理します。パイプラインが突然失敗しないように、この記事を読みながら自社のYAML、クラシックパイプライン、ファイアウォール設定を順番に確認してください。
Microsoft-hosted agents for Azure Pipelinesとは
Microsoft-hosted agents for Azure Pipelinesは、Azure DevOps Services上のパイプラインジョブを実行するためにMicrosoftが管理するエージェント環境です。利用者側で仮想マシンを構築・保守する必要がなく、パイプラインで指定したVMイメージを使ってビルド、テスト、デプロイを実行できます。Microsoft公式情報では、Microsoft-hosted agentsはクラウド版のAzure DevOps Servicesでのみ利用でき、オンプレミスのAzure DevOps Serverでは利用できないと説明されています。(Microsoft Learn)
大きな特徴は、ジョブごとに新しい仮想マシンが割り当てられ、1つのジョブが終わるとそのVMが破棄される点です。つまり、前回のジョブでインストールしたツール、作成した一時ファイル、チェックアウトしたコードは次のジョブに引き継がれません。再現性の高いクリーンな環境で実行できる一方、依存関係のインストールやキャッシュ設計を誤ると、実行時間の増加や容量不足の原因になります。(Microsoft Learn)
2026年時点で押さえるべき主な変更点
Microsoft-hosted agentsの更新で特に注意したいのは、OSイメージと開発ツールのライフサイクルです。Azure PipelinesのVMイメージにはWindows、Linux、macOSがあり、それぞれ利用可能なラベルや非推奨スケジュールが異なります。
| 項目 | 公式情報で確認すべきポイント | 実務上の影響 |
|---|---|---|
| Windowsイメージ | windows-2025-vs2026がパブリックプレビューとして利用可能。windows-latestはwindows-2025として利用可能 | Visual Studio 2026対応を早期検証できる。ただし本番ビルドではプレビュー利用の可否を判断する必要がある |
| Windows Server 2019 | Windows Server 2019 hosted agent imageは2025年12月31日に廃止 | 古いwindows-2019指定が残っているとパイプライン失敗の原因になる |
| Linuxイメージ | ubuntu-latestはubuntu-24.04として利用可能。ubuntu-22.04も選択可能 | OS依存のパッケージ、ビルドツール、ランタイムの差分確認が必要 |
| Ubuntu 20.04 | Ubuntu 20.04イメージは廃止済み | 旧OS前提のビルドはubuntu-24.04またはubuntu-22.04へ移行が必要 |
| macOSイメージ | macOS-26はパブリックプレビュー、macOS-latestはmacOS-15として利用可能 | Xcodeやシミュレーターランタイムに依存するiOS/macOSアプリは検証が必要 |
| macOS 14 Sonoma | 2026年7月6日から非推奨、2026年11月2日に削除予定 | macOS-14指定のパイプラインは、削除日までにmacOS-15またはmacOS-latestへ移行する必要がある |
Windows Server 2025 with Visual Studio 2026のイメージは、現在のwindows-2025イメージとは別に提供され、将来的にVisual Studio 2026が一般提供になるとwindows-2025へ統合される予定です。プレビュー期間中はwindows-2025-vs2026を明示して検証できます。(Microsoft Learn)
macOS 14 Sonomaについては、非推奨開始が2026年7月6日、ブラウンアウト期間が2026年10月5日から10月31日、削除予定日が2026年11月2日とされています。ブラウンアウト期間中は対象イメージを使うジョブが一時的に失敗するため、削除日直前ではなく、余裕を持ってmacOS-15またはmacOS-latestへ移行してください。(Microsoft Learn)
影響を受けやすいパイプライン
Microsoft-hosted agentsの更新で影響を受けやすいのは、古いOSや特定バージョンの開発ツールを前提にしているパイプラインです。特に、次のような構成は早めに確認してください。
windows-2019、ubuntu-20.04、macOS-14など古いVMイメージを指定しているlatest系ラベルに任せたまま、OSやツールの変更テストをしていない- .NET、Node.js、Java、Python、Xcode、Visual Studioの特定バージョンに依存している
- ローカルPCやセルフホステッドエージェントでは成功するが、Microsoft-hosted agentsでは失敗する
- 社内ネットワーク、Azure Storage、プライベートAPIなどにIP制限をかけている
- Dockerイメージのpullや大容量アーティファクト生成でディスク容量を多く消費している
Microsoft-hosted agentsは、利用者が毎回同じ古いVMイメージに戻す仕組みではありません。公式情報でも、以前のVMイメージバージョンへロールバックする機能は提供されないとされています。環境差分に弱いビルドでは、使うイメージラベルと依存関係のバージョンを明示することが重要です。(Microsoft Learn)
管理者が確認すべき設定
エージェントプールと利用権限を確認する
Azure Pipelinesでは、Microsoft-hosted agents用にAzure Pipelinesという事前定義済みのエージェントプールが用意されています。YAMLパイプラインでpoolを指定しない場合、既定でAzure Pipelinesエージェントプールが使われます。パイプラインが想定外のイメージで動く場合は、パイプライン、ステージ、ジョブの各レベルでpool指定を確認してください。(Microsoft Learn)
管理者は、次の順に確認すると抜け漏れを減らせます。
| 確認項目 | 確認場所・方法 | 見落としやすいポイント |
|---|---|---|
| エージェントプールの権限 | Organization settings、Project settings、Agent pools | 一部ユーザーやプロジェクトに利用制限がかかっている場合がある |
| 使用中のVMイメージ | YAMLのpool.vmImage、クラシックパイプラインのAgent Specification | ステージやジョブ単位で上書きされていることがある |
| 並列ジョブ数 | Organization settings、Billing、Parallel jobs | 無料枠だけでは同時実行が詰まり、キュー待ちが増える |
| 古いイメージの利用状況 | Agent queuesでイメージ名をフィルター、または検出スクリプト | 使われていないと思っていた旧パイプラインが残っていることがある |
| ネットワーク許可設定 | ファイアウォール、Azure Storage、社内APIのIP制限 | Microsoft-hosted agentsのIP範囲は変わるため定期更新が必要 |
新しいAzure DevOps組織では、無料のMicrosoft-hosted parallel jobsが既定で付与されない場合があり、必要に応じてリクエストが必要です。また、プライベートプロジェクトでは無料枠や実行時間に制限があるため、組織全体の利用状況を見て追加購入やセルフホステッド化を検討してください。(Microsoft Learn)
ネットワークとファイアウォールの許可リストを更新する
Microsoft-hosted agentsから社内リソースやIP制限付きのAzureリソースへアクセスする場合、ネットワーク設定が最もトラブルになりやすい箇所です。公式情報では、Azure DevOpsがAzureグローバルネットワークを利用するためIP範囲は時間とともに変わり、Microsoftはリージョン別のIP範囲を含むJSONファイルを毎週公開していると説明されています。(Microsoft Learn)
重要なのは、Microsoft-hosted agentsをExpressRouteやVPNなどのプライベート接続で企業ネットワークへ直接接続できない点です。トラフィックはパブリックネットワークを経由します。社内サーバーへアクセスさせる場合は、サーバー側をインターネットから到達可能にし、必要なIP範囲をファイアウォールで許可する設計が必要です。(Microsoft Learn)
また、Microsoft-hosted agentsはサービス タグとして直接列挙できません。許可設定では、サービス タグに頼るのではなく、対象のAzure geographyに含まれる各リージョンのIP範囲を確認して許可リストへ反映します。macOSエージェントのIP範囲はAzureのIP一覧に含まれず、GitHubのmacOSクラウド側の情報を参照する必要があります。(Microsoft Learn)
macOS利用時はデータ所在地を確認する
macOSイメージを使う場合、データ主権や所在地要件にも注意が必要です。公式情報では、macOSイメージを実行するエージェントはAzure DevOps組織の場所に関係なく米国で実行されるとされています。日本国内や特定リージョン内で処理を完結させたい要件がある場合、macOSのMicrosoft-hosted agentsをそのまま使ってよいか、セキュリティ・法務・監査部門と確認してください。(Microsoft Learn)
開発者が確認すべきYAML設定
vmImageは「便利さ」より「再現性」を優先する
ubuntu-latestやwindows-latestは便利ですが、本番ビルドではイメージ更新の影響を受けやすくなります。安定性を重視するパイプラインでは、まず明示的なラベルを指定しましょう。
pool:
vmImage: 'ubuntu-24.04'WindowsでVisual Studio 2026の互換性を検証したい場合は、プレビュー用のwindows-2025-vs2026を使って別ジョブで検証するのが安全です。本番ジョブをいきなりプレビューイメージへ切り替えるのではなく、まず検証ジョブを追加して失敗条件を洗い出してください。
jobs:
- job: build_windows_current
pool:
vmImage: 'windows-2025'
steps:
- script: echo Build on Windows Server 2025
- job: validate_vs2026_preview
pool:
vmImage: 'windows-2025-vs2026'
steps:
- script: echo Validate Visual Studio 2026 preview imageLinuxとWindowsの両方で動作確認したい場合は、matrixを使うと差分を確認しやすくなります。
jobs:
- job: build
strategy:
matrix:
linux:
imageName: 'ubuntu-24.04'
windows:
imageName: 'windows-2025'
pool:
vmImage: $(imageName)
steps:
- script: echo Running on $(imageName)パスやドライブ文字をハードコーディングしない
Microsoft-hosted agentsでは、エージェントのファイルシステム構成が予告なく変わる可能性があります。公式情報でも、リポジトリを含むドライブ文字やフォルダーをハードコーディングせず、変数を使ってビルド環境やエージェントリソースを参照することが推奨されています。(Microsoft Learn)
避けるべき例は次のような書き方です。
steps:
- script: dir C:\agent\_work\1\s代わりに、Azure Pipelinesの変数を使います。
steps:
- script: |
echo Sources: $(Build.SourcesDirectory)
echo Workspace: $(Pipeline.Workspace)
echo Temp: $(Agent.TempDirectory)特に、テスト結果、ビルド成果物、一時ファイルの出力先を固定パスにしているパイプラインは要注意です。イメージ更新後に「ローカルでは成功するのにCIだけ失敗する」原因になりやすいです。
必要なツールはジョブ内で明示する
Microsoft-hosted agentsには多くのツールが含まれていますが、すべてのプロジェクトに必要なバージョンが入っているとは限りません。必要なソフトウェアが削除された、または新しいバージョンに置き換わった場合は、対象イメージのIncluded softwareを確認し、必要に応じてツールインストーラータスクやスクリプトでジョブ内に導入します。公式情報でも、追加ソフトウェアの要求はサポートチケットではなく、イメージ生成スクリプトを管理するGitHubリポジトリでissueを開くよう案内されています。(Microsoft Learn)
判断基準はシンプルです。
| 状況 | 推奨対応 |
|---|---|
| 一般的なバージョンでよい | Microsoft-hosted agentsのIncluded softwareを利用 |
| 特定バージョンが必要 | ジョブ内でツールを明示的にインストール |
| 毎回のインストール時間が重い | キャッシュや成果物の再利用を検討 |
| 特殊なSDK、社内ツール、CIS準拠イメージが必要 | セルフホステッドエージェント、スケールセットエージェント、Managed DevOps Poolsを検討 |
移行時の実務手順
Microsoft-hosted agentsの移行は、いきなり全パイプラインを書き換えるのではなく、影響調査から段階的に進めると安全です。
使っているイメージを棚卸しする
まず、Azure DevOps組織内で使っているVMイメージを棚卸しします。YAMLだけでなく、クラシックパイプラインやテンプレート化された共通YAMLも確認してください。公式の非推奨スケジュールでは、Azure DevOpsのAgent queuesでイメージ名をフィルターして確認する方法や、ジョブ履歴をスクリプトで検索する方法が案内されています。(Microsoft Learn)
確認対象の例は次のとおりです。
pool:
vmImage: 'windows-2019'pool:
vmImage: 'ubuntu-20.04'pool:
vmImage: 'macOS-14'これらのような旧イメージが見つかった場合は、単純にラベルだけを置き換えるのではなく、ビルドログ、依存パッケージ、テスト結果、成果物の差分を確認します。
互換性テスト用の一時ブランチを作る
移行では、本番パイプラインのYAMLを直接変更するより、まず一時ブランチや検証用パイプラインで新イメージを試す方法が安全です。
検証時は、次の点をログで確認します。
| 確認項目 | 見るべき内容 |
|---|---|
| OSバージョン | 期待したイメージで実行されているか |
| SDK・ランタイム | .NET、Node.js、Java、Pythonなどのバージョン |
| ビルドツール | Visual Studio、MSBuild、CMake、Xcodeなど |
| テスト結果 | 失敗が環境依存かコード依存か |
| 容量 | Docker pullや成果物生成後に空き容量が不足していないか |
| ネットワーク | Azure Storage、社内API、パッケージレジストリへ到達できるか |
公式情報では、WindowsとLinuxのMicrosoft-hosted agentsは2コアCPU、7GB RAM、14GB SSDのAzure汎用仮想マシンにプロビジョニングされ、パイプライン実行に使える空き領域は少なくとも10GBとされています。ディスク増量やより強力なマシンへの変更は受け付けられないため、容量不足が頻発する場合はパイプライン分割やセルフホステッド化を検討してください。(Microsoft Learn)
macOS 14利用中なら早めに移行する
macOS-14を使っている場合は、2026年11月2日の削除予定日より前に移行を完了させる必要があります。ブラウンアウト期間中はジョブが一時的に失敗するため、「削除直前に対応する」運用は危険です。
推奨される置き換えは次のようになります。
pool:
vmImage: 'macOS-15'または、将来の更新を受け入れる前提で次のように指定します。
pool:
vmImage: 'macOS-latest'iOS、watchOS、tvOS、visionOS向けのビルドでは、Xcodeやシミュレーターランタイムの差分が失敗原因になりやすいため、アプリのターゲットバージョンとXcodeバージョンを必ず確認してください。
よくある失敗と対処法
Microsoft-hosted agentsで起きるトラブルは、原因がある程度パターン化されています。エラーが出たら、まず次の表に当てはめて確認してください。
| 症状 | 主な原因 | 対処法 |
|---|---|---|
no space left on deviceで失敗する | 10GB程度の空き領域を使い切っている | 不要ファイル削除、Dockerイメージ削減、ジョブ分割、セルフホステッド化を検討 |
| ローカルでは成功するがCIで失敗する | ローカルにある依存関係がHosted agentにない | Included softwareを確認し、必要なツールをジョブ内で明示的にインストール |
| 想定外のOSで実行される | pool指定が別階層で上書きされている | pipeline、stage、jobレベルのpoolをすべて確認 |
| 社内サーバーへ接続できない | パブリック到達性やIP許可設定が不足 | DNS名/IPの公開到達性、ファイアウォールのIP許可範囲を確認 |
| Azure StorageのSAS IP承認エラー | Storage側でHosted agentのIP範囲が許可されていない | Azure Storageのネットワーク規則へIP範囲を追加、または実行前後にルールを更新 |
| 古いイメージ指定で失敗する | イメージが非推奨または削除済み | サポート中のイメージへ移行し、必要ならコンテナジョブやセルフホステッドを検討 |
Azure StorageのSAS IP承認エラーについて、公式情報では、Microsoft-hosted agentsからのIPアドレス範囲がStorage側の規則で許可されていないことが主な原因とされています。回避策として、StorageアカウントのIPネットワーク規則へHosted agentのIP範囲を追加する、パイプライン内で一時的にネットワークルールを更新する、またはセルフホステッドエージェント等を使う方法が挙げられています。(Microsoft Learn)
Microsoft-hosted agentsを使い続けるべきかの判断基準
Microsoft-hosted agentsは、標準的なビルド・テスト・デプロイには非常に扱いやすい選択肢です。ただし、すべての環境に向いているわけではありません。
| 選択肢 | 向いているケース | 向いていないケース |
|---|---|---|
| Microsoft-hosted agents | 標準的なCI/CD、OSS、一般的なWebアプリ、クリーン環境でのテスト | 特殊ツールが多い、容量や性能が足りない、社内ネットワークへ閉域接続したい |
| Self-hosted agents | 独自SDK、社内ツール、固定バージョン、閉域ネットワークが必要 | OS更新、セキュリティパッチ、スケール管理を自社で担えない |
| Scale set agents | Azure VMベースでスケールさせたい、大量ジョブを処理したい | 小規模で管理負荷を増やしたくない |
| Managed DevOps Pools | 管理負荷を抑えつつ専用性や柔軟性を高めたい | 既存のMicrosoft-hosted agentsで十分な小規模用途 |
セキュリティ面では、Microsoft-hosted agentsは各実行後に再イメージ化され、各エージェントは1つの組織専用、各VMには1つのエージェントのみがホストされます。一方で、Hosted imageはCIS hardening benchmarksに準拠していないため、CIS準拠が必要な場合はセルフホステッドエージェント、スケールセットエージェント、Managed DevOps Poolsの利用を検討する必要があります。(Microsoft Learn)
まず実施すべきチェックリスト
最後に、管理者と開発者がすぐに着手できる確認項目をまとめます。
| 優先度 | 実施内容 | 担当 |
|---|---|---|
| 高 | windows-2019、ubuntu-20.04、macOS-14など古いイメージ指定を棚卸しする | 管理者・開発者 |
| 高 | macOS-14利用中のパイプラインをmacOS-15またはmacOS-latestへ移行計画に入れる | 開発者 |
| 高 | 社内ネットワーク、Azure Storage、パッケージレジストリのIP許可設定を確認する | 管理者 |
| 中 | latest系ラベルを使う本番パイプラインで、明示的なイメージラベルへの切り替えを検討する | 開発者 |
| 中 | パス、ドライブ文字、一時ディレクトリのハードコーディングを変数参照へ修正する | 開発者 |
| 中 | 容量不足が起きるジョブを分割し、不要なDockerイメージや中間ファイルを削減する | 開発者 |
| 低 | Visual Studio 2026対応が必要なプロジェクトでwindows-2025-vs2026を検証する | 開発者 |
| 低 | Microsoft-hosted agentsで足りない要件を洗い出し、セルフホステッドやManaged DevOps Poolsを比較する | 管理者 |
Microsoft-hosted agents for Azure Pipelinesは、保守不要で始めやすい一方、VMイメージの更新、非推奨スケジュール、ネットワーク制約の影響を受けます。特に本番リリースに直結するパイプラインでは、「latestに任せる」だけでなく、使うイメージ、依存ツール、接続先、容量制約を明示的に管理することが安定運用の近道です。まずは現在のvmImage指定を棚卸しし、古いイメージとmacOS 14利用中のパイプラインから優先的に見直してください。
コメント