MENU

Azure REST APIのNVMeマウント設定追加とは？DevOpsAzureSkuの変更点と確認ポイント

Azure

Azure REST APIでManaged DevOps PoolsをREST、ARMテンプレート、Bicep、独自ツールから管理している場合、今回の更新でまず確認すべき点はシンプルです。新しいプレビューAPIバージョン2026-04-17-previewで、DevOpsAzureSkuにNVMe一時ディスクのマウント先を指定する任意プロパティが追加されました。WindowsではwindowsNvmeDrive、LinuxではlinuxNvmePathを使い、未指定時はそれぞれN、/mnt/azure_nvme_tempが既定値になります。(GitHub)

すでにManaged DevOps Poolsを使っていても、Azure v6 SKUのNVMe一時ディスクを利用していない環境や、既定のマウント先で問題ない環境では、すぐに設定変更が必要とは限りません。一方で、ビルドキャッシュ、作業ディレクトリ、ツールチェーンの一時ファイル、コンテナ関連の中間データを特定のドライブやパスに置く設計をしている場合は、APIバージョン、IaC定義、SDK、パイプライン設定をあわせて確認する必要があります。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Azure REST APIの今回の更新で何が変わったのか

今回の変更は、Azure REST API仕様リポジトリのPR「Add NVMe mount properties to DevOpsAzureSku in new 2026-04-17-preview API version」として公開され、2026年5月20日にマージされています。対象はMicrosoft.DevOpsInfrastructure、つまりManaged DevOps Poolsに関するREST API仕様です。(GitHub)

追加されたプロパティは次の2つです。

プロパティ型必須役割既定値
windowsNvmeDrivestring任意Windows上のNVMeストライプボリュームのドライブ文字を指定するN
linuxNvmePathstring任意Linux上のNVMeストライプボリュームのマウントパスを指定する/mnt/azure_nvme_temp

重要なのは、これは「NVMe一時ディスクを有効化する設定」というより、Managed DevOps PoolsでAzure v6 SKUのNVMe一時ディスクが使われる場合に、ストライプボリュームをどこへマウントするかを指定できるようにする変更だという点です。PRの説明でも、Azure v6 SKU上のNVMe temp disk striped volumesのマウント先を顧客が構成できるようにする変更とされています。(GitHub)

旧APIバージョンではなく2026-04-17-previewで追加された理由

このプロパティは、既存の安定版APIバージョン2025-09-20を後から変更する形ではなく、新しいプレビューAPIバージョン2026-04-17-previewに追加されています。PRでは、Azureのバージョニング方針に従い、出荷済みの安定版ではなく新しいプレビューAPIバージョンで追加すると説明されています。(GitHub)

そのため、管理者や開発者が最初に見るべきポイントは「自分たちのコードやテンプレートがどのapi-versionを使っているか」です。

現在の利用状況影響
2025-09-20など既存の安定版APIを使っている新プロパティはそのままでは利用できない
2026-04-17-previewへ切り替えるwindowsNvmeDriveとlinuxNvmePathを指定できる
APIレスポンスを厳密に型チェックしている新しいフィールドへのSDK・スキーマ対応状況を確認する
ポータルやCLIだけで管理しているREST API仕様への反映と、各ツール側の対応タイミングに差が出る可能性がある

プレビューAPIは、本番環境で絶対に使えないという意味ではありません。ただし、安定版APIよりも変更余地があるため、いきなり全プールへ展開するのではなく、検証用プールで挙動を確認してから段階的に適用するのが安全です。

DevOpsAzureSkuのどこに設定するのか

DevOpsAzureSkuは、Managed DevOps Poolsのマシンに使うAzure SKUを表す定義です。新しい仕様では、nameが必須で、windowsNvmeDriveとlinuxNvmePathは任意プロパティとして追加されています。(GitHub)

REST APIのリクエストイメージとしては、プールのfabricProfile配下にあるskuへ指定する形になります。

{
  "properties": {
    "fabricProfile": {
      "kind": "Vmss",
      "sku": {
        "name": "<Azure v6 SKU>",
        "windowsNvmeDrive": "N",
        "linuxNvmePath": "/mnt/azure_nvme_temp"
      }
    }
  }
}

WindowsだけのプールであればwindowsNvmeDrive、LinuxだけのプールであればlinuxNvmePathを中心に確認します。WindowsとLinuxのイメージを同じ管理基準で扱う場合は、両方を明示しておくと、後から設定意図を追いやすくなります。

ただし、値を明示すること自体が目的ではありません。既定値で問題ないなら、あえて指定しない選択も妥当です。指定する価値があるのは、既存のドライブ文字やマウントパスと衝突する場合、社内標準の作業パスに合わせたい場合、パイプラインの一時領域を明確に分離したい場合です。

NVMe一時ディスクのマウント先を変えると何が便利になるのか

Managed DevOps Poolsでは、ビルドエージェント上でソースのチェックアウト、依存関係の復元、テスト、パッケージング、成果物の作成などが実行されます。これらの処理では、一時ファイルやキャッシュが大量に発生します。

NVMe一時ディスクのマウント先を明示できると、次のような設計がしやすくなります。

活用シーン具体例設定時の判断基準
ビルドキャッシュを分離するnpm、NuGet、Gradle、Mavenなどのキャッシュを一時領域に寄せるキャッシュが再生成可能で、永続化が不要な場合
大きな中間生成物を扱うコンパイル中間ファイル、テスト用データ、展開前の一時パッケージパイプライン失敗時に消えても問題ない場合
Windowsのドライブ衝突を避ける既存ツールがNドライブを使っているため別ドライブにする社内ツール、セキュリティ製品、古いスクリプトの利用状況を確認する
Linuxの標準パスに合わせる/mnt/build-tempなど、運用ルールに沿ったパスへ変更するパス権限、所有者、既存ディレクトリとの衝突を確認する
パイプラインの可読性を上げる一時領域の場所をチーム内で統一するYAML、README、運用手順書で同じパスを使えるか確認する

注意点は、NVMe一時ディスクが「一時」ディスクであることです。Azure VMのNVMe一時ディスクに関する公式FAQでは、一時ディスクはローカルSSD上に作成される一時ディスクとして説明されています。(Microsoft Learn)

つまり、成果物、監査ログ、長期保存が必要なテスト結果などを置く場所としては適しません。使うなら「消えても再作成できるデータ」に限定するのが基本です。

影響を受けやすい管理者・開発者

今回のAzure REST API更新は、すべてのAzure利用者に影響するものではありません。影響を受けやすいのは、Managed DevOps PoolsをAPIや自動化で管理しているチームです。

特に次の担当者は確認しておくべきです。

対象者確認すべきこと
Azure管理者Managed DevOps PoolsのAPIバージョン、SKU、リソースプロバイダー登録状況
DevOps基盤担当エージェントの一時領域、ビルドキャッシュ、パイプライン標準パス
IaC担当ARMテンプレート、Bicep、Terraform、独自JSONスキーマの対応状況
アプリ開発チームパイプライン内で固定ドライブ・固定パスを参照していないか
SDK利用者利用中のAzure SDKに新プロパティが反映されているか
セキュリティ・監査担当一時領域に機密情報や永続保存すべきログを置いていないか

Managed DevOps Pools自体は、エージェントを利用するVMまたはコンテナーがMicrosoft Azureサブスクリプション側に格納されるフルマネージドサービスとして説明されています。(Microsoft Learn) そのため、従来のセルフホストエージェントのようにOSやディスク構成を細かく直接管理するのではなく、サービス側のAPI仕様に沿って構成を管理する考え方が重要になります。

すぐに対応が必要なケース、不要なケース

この更新を見て、すぐ全環境の設定を変更する必要はありません。まずは、次の基準で対応要否を分けると判断しやすくなります。

状況対応優先度理由
Managed DevOps Poolsを使っていない低対象サービス外
Managed DevOps Poolsを使っているが、APIで管理していない低〜中ポータルやCLI側の対応状況確認が中心
REST APIやIaCでプールを作成・更新している高api-versionとスキーマ変更の影響を受けやすい
Azure v6 SKUを使い、NVMe一時ディスクの場所を制御したい高今回の新プロパティの直接的な対象
ビルドスクリプトがNドライブや/mnt/azure_nvme_tempを前提にしている高既定値や変更後のパスと衝突する可能性がある
成果物を一時ディスクに保存している高データ消失リスクの設計見直しが必要

特に危険なのは、「高速そうだから」という理由だけで成果物やログの保存先をNVMe一時ディスクに変更することです。ビルド中間ファイルやキャッシュには向いていますが、ビルド成果物はAzure Pipelinesの成果物公開、ストレージ、リポジトリ、パッケージフィードなど、適切な保存先へ退避させる必要があります。

管理者が確認すべき設定ポイント

APIバージョンを棚卸しする

最初に、Managed DevOps Poolsを作成・更新している箇所を洗い出します。REST API、ARMテンプレート、Bicep、CI/CD内のaz rest、社内ポータル、GitHub ActionsやAzure Pipelinesから呼び出すスクリプトなどが対象です。

確認すべき文字列はapi-versionです。今回の新プロパティを使うには、対象呼び出しが2026-04-17-previewになっている必要があります。仕様ファイルでも、info.versionは2026-04-17-previewとして定義されています。(GitHub)

Windowsのドライブ文字を確認する

windowsNvmeDriveには、Windows上のNVMeストライプボリュームのドライブ文字を指定します。公式仕様の説明では例としてNが示されており、未指定時もNが既定値です。(GitHub)

確認すべき点は次のとおりです。

  • 既存のビルドツールがNドライブを別用途で使っていないか
  • セキュリティ製品、バックアップ製品、社内エージェントが同じドライブ文字を前提にしていないか
  • PowerShellスクリプトやバッチファイルで固定ドライブを参照していないか
  • N:のようにコロン付きで指定していないか

仕様上は「ドライブ文字」としてNのような値が示されています。実装側でどのような入力検証が行われるかは環境やAPIの実装に依存するため、コロン付きのN:ではなく、公式説明に沿ってNのように指定するのが安全です。

Linuxのマウントパスを確認する

linuxNvmePathには、Linux上のNVMeストライプボリュームのマウントパスを指定します。未指定時の既定値は/mnt/azure_nvme_tempです。(GitHub)

Linuxでは、パスの衝突と権限が問題になりやすいです。たとえば、既存スクリプトで/mnt配下に別のディレクトリを作成している場合や、コンテナ実行時に同じパスをボリュームマウントしている場合は、想定外の上書きや権限エラーが起きる可能性があります。

安全に使うには、次の観点で確認します。

  • 指定パスが既存の重要ディレクトリと衝突しないか
  • ビルドユーザーが読み書きできるか
  • パイプライン内のコンテナジョブから参照する必要があるか
  • キャッシュ削除やクリーンアップ処理がそのパスを対象にしているか
  • パスを変更した場合、既存のYAMLやスクリプトが追従できるか

SDKと自動生成クライアントの対応を確認する

PRでは、Swagger、TypeSpec、Go、Python、JavaScript、JavaなどのAPIレビューが作成されたことが示されています。(GitHub) これは、REST API仕様の変更が各言語SDKや生成コードに波及し得ることを意味します。

ただし、仕様リポジトリに変更が入った直後に、すべてのSDKパッケージで同時に利用できるとは限りません。SDKを使っている場合は、次を確認します。

確認項目見るべきポイント
SDKのモデル定義windowsNvmeDrive、linuxNvmePathがプロパティとして存在するか
APIバージョン指定SDK側で2026-04-17-previewを選べるか
シリアライズ未知のプロパティが落とされないか
型チェック独自ラッパーやJSONスキーマでエラーにならないか
CI/CDSDK更新によりビルドやテストが壊れないか

SDKが未対応でも、検証目的でREST APIを直接呼び出せる場合があります。ただし、本番運用でREST直書きとSDK利用が混在すると、設定差分を追いにくくなります。採用するなら、運用チーム内で「どの経路からプールを更新するか」を決めておくべきです。

移行・展開時のおすすめ手順

今回の変更は任意プロパティの追加ですが、ディスクのマウント先はパイプラインの安定性に直結します。次の順序で進めると、失敗を減らせます。

| 手順 | 作業内容 | 失敗しやすいポイント |
| -: | ———————————– | —————————————– |
| 1 | Managed DevOps Poolsの一覧と利用SKUを棚卸しする | v6 SKUの利用有無を確認せず全プールに適用する |
| 2 | REST API、IaC、SDKのapi-versionを確認する | テンプレートだけ更新し、社内ツール側が旧APIのままになる |
| 3 | Windows/Linuxごとの既定マウント先を確認する | Nドライブや/mnt/azure_nvme_tempを既存用途と衝突させる |
| 4 | 検証用プールで新プロパティを指定する | 本番プールでいきなり変更する |
| 5 | パイプラインで読み書き、容量、権限、クリーンアップを確認する | 成果物を一時ディスクへ置いたままにする |
| 6 | 監視とロールバック手順を用意して段階展開する | 失敗時に既定値へ戻す手順を用意していない |
| 7 | チームのYAMLテンプレートと運用ドキュメントを更新する | 設定値だけ変えて利用者に周知しない |

REST API仕様では、プールの作成・更新にPools_CreateOrUpdateやPools_Updateが定義されており、これらは長時間操作として扱われます。(GitHub) そのため、展開スクリプトではリクエスト送信後にすぐ成功扱いにせず、操作完了までポーリングし、プールの状態と実際のパイプライン実行結果まで確認することが重要です。

よくある失敗パターンと対策

既定値を知らずに既存ドライブと衝突する

Windowsでは未指定時にNが使われます。既存の社内スクリプトやツールがNドライブを前提にしている場合、明示的に別のドライブ文字を指定するか、スクリプト側の参照先を見直す必要があります。

対策は、パイプライン内で固定ドライブを使っている箇所を検索することです。PowerShell、バッチ、YAML、テスト設定ファイルを対象に、N:\、N:、/mnt/azure_nvme_tempなどを検索します。

一時ディスクを永続ストレージのように使う

NVMe一時ディスクは、名前の通り一時領域です。キャッシュや中間生成物には向きますが、ビルド成果物、監査ログ、長期保存が必要なテストレポートには向きません。

Managed DevOps Poolsでは、空のデータディスクをエージェントに接続して追加ストレージを得る構成も公式ドキュメントで説明されています。(Microsoft Learn) ただし、今回のwindowsNvmeDriveとlinuxNvmePathはデータディスク追加の設定ではなく、NVMe一時ディスクのマウント先を指定するプロパティです。容量不足対策なのか、一時処理の高速化・分離なのかを切り分けて考える必要があります。

プレビューAPIを全環境へ一括適用する

2026-04-17-previewを使わないと新プロパティは利用できませんが、プレビューAPIへの切り替えは影響範囲を確認してから行うべきです。特に、社内でAPIレスポンスを厳密に検証している場合、新しいAPIバージョンに含まれる他の差分でエラーが起きる可能性があります。

対策は、まず検証用リソースグループと検証用プールで、同じイメージ、同じSKU、同じパイプラインを使って比較することです。旧APIで成功していたパイプラインを新APIのプールでも実行し、ディスクの存在、パス、権限、容量、クリーンアップ後の状態を確認します。

SDK更新だけで対応済みと思い込む

SDKに新プロパティが追加されても、実際に使うにはAPIバージョン、リクエスト本文、実行環境のSKU、パイプラインの参照パスがそろっている必要があります。SDKの型だけ更新されていても、プール側が対象SKUでなければ期待した挙動にならない可能性があります。

対策は、SDK更新後に単体テストだけで終わらせず、実際のプール作成または更新、エージェント起動、パイプライン実行まで含めて検証することです。

実務で使う設定例

Windowsで既定のNドライブを明示する例

{
  "sku": {
    "name": "<Azure v6 SKU>",
    "windowsNvmeDrive": "N"
  }
}

既定値と同じでも、あえて明示することで「このプールではNVMe一時ディスクをNドライブとして扱う」という設計意図を残せます。複数チームでプールを共用する場合や、YAMLテンプレート内でNドライブを使う場合は、明示しておく価値があります。

Linuxで社内標準の一時パスに寄せる例

{
  "sku": {
    "name": "<Azure v6 SKU>",
    "linuxNvmePath": "/mnt/build-temp"
  }
}

このように独自パスへ変更する場合は、パイプライン内のキャッシュ設定、DockerやPodmanなどの一時ディレクトリ、テストツールの出力先、削除スクリプトを合わせて更新します。特にLinuxでは、パスの所有者と権限を確認しないと、ビルドユーザーから書き込めずに失敗することがあります。

WindowsとLinuxの両方を定義する例

{
  "sku": {
    "name": "<Azure v6 SKU>",
    "windowsNvmeDrive": "T",
    "linuxNvmePath": "/mnt/agent-temp"
  }
}

複数OSのプール設計を同じIaCテンプレートで管理している場合は、このように両方の値を定義しておくと、OSごとの差分が見えやすくなります。ただし、指定した値が各OSの既存設定やツールと衝突しないことを事前に確認してください。

導入前チェックリスト

本番展開前には、次の項目を確認しておくと安全です。

チェック項目確認内容
APIバージョン2026-04-17-previewを使う箇所と使わない箇所を明確にしたか
SKU対象がAzure v6 SKUで、NVMe一時ディスクの利用を想定しているか
WindowsパスwindowsNvmeDriveの値が既存ドライブと衝突しないか
LinuxパスlinuxNvmePathが既存ディレクトリやマウント設定と衝突しないか
パイプラインYAML、スクリプト、ツール設定で固定パスを参照していないか
データ種別一時ディスクに永続保存すべきデータを置いていないか
SDK利用言語のSDKや生成クライアントが新APIに対応しているか
権限プール作成・更新に必要なAzure側とAzure DevOps側の権限があるか
ロールバックプロパティ未指定または旧設定へ戻す手順を用意したか
周知開発チームに新しい一時領域の使い方を共有したか

Managed DevOps Poolsを利用するには、Azureサブスクリプション、リソースプロバイダー、Azure DevOps組織、作成権限などの前提条件も必要です。公式ドキュメントでは、Microsoft.DevOpsInfrastructureやMicrosoft.DevCenterのリソースプロバイダー登録、Azure DevOps組織やプロジェクト側の権限確認が説明されています。(Microsoft Learn)

今回の更新への現実的な対応方針

今回のAzure REST API更新は、既存環境を大きく壊す破壊的変更というより、Managed DevOps PoolsでNVMe一時ディスクのマウント先を柔軟に制御するための拡張です。ただし、ディスクの場所はビルドスクリプトやキャッシュ戦略に直結するため、軽く扱うとパイプライン障害につながります。

対応方針は次のように考えると実務的です。

まず、Managed DevOps PoolsをAPIやIaCで管理しているかを確認します。次に、対象プールがAzure v6 SKUとNVMe一時ディスクの利用を想定しているかを確認します。そのうえで、既定値のNと/mnt/azure_nvme_tempで問題ないなら、無理に変更せず、ドキュメント化だけ行います。既存ドライブや社内標準パスとの衝突がある場合は、2026-04-17-previewを検証環境で使い、windowsNvmeDriveまたはlinuxNvmePathを明示して段階的に展開します。

最後に、NVMe一時ディスクは「高速な作業領域」として扱い、永続化が必要な成果物やログは別の保存先へ逃がす設計にしてください。今回の変更をきっかけに、パイプラインの一時領域、キャッシュ、成果物保存先を整理しておくと、Managed DevOps Poolsの運用安定性を高められます。

Azure
NVMe Azure REST API Managed DevOps Pools DevOpsAzureSku

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次