Azure Dev Box を導入したものの、表示されるのは 8 vCPU／32 GB 以上の高性能 SKU だけ――。フロントエンドや QA、ジュニア開発者には「2 vCPU／8 GB」「4 vCPU／16 GB」程度で十分、という現場は少なくありません。本記事では、2025年11月時点の最新仕様を踏まえ、低スペック構成の可否、代替サービスの現実解、そして Dev Box を継続利用する場合のコスト最適化まで、一気通貫で解説します。
結論：Dev Box で 2 vCPU／8 GB は使えない。必要なら Windows 365 または AVD／通常の Azure VM を選ぶ
2025年11月時点、Microsoft Dev Box で選択できるコンピュート SKU は 8 vCPU／32 GB を下限とするラインアップのみです。ポータルの価格ページおよび REST API の SKU 列挙でも 8／16／32 vCPU（Intel／AMD）と各種ストレージ容量の組み合わせだけが定義されており、2 vCPU／8 GB や 4 vCPU／16 GB は仕様上存在しません。
また、「SKU を増やしてほしい」というサポート要請は不可です。Microsoft Q&A でも「2コア／4コア SKU は現時点で未提供、8コア以上のみ」と明言されています。容量不足やクォータの拡張はサポート対象ですが、SKU 追加要望は対象外です。
重要トピック：Dev Box は Windows 365 へ機能統合の方針。小型 SKU の解は Windows 365 側にある
2025年11月1日に、Dev Box の機能を Windows 365 に取り込む公式アナウンスが公開されました。これに伴い、Dev Box は新規顧客受付を停止（既存顧客は継続利用可）、開発者向け機能は Windows 365 に段階的に統合される方針です。顧客要望として 「2/4 コアの小型 SKU への対応」 が挙げられており、今後は Windows 365 を主軸としてより広い SKU オプションを提供する旨が示されています。
実際、Windows 365（Business／Enterprise）は 2 vCPU／8 GB や 4 vCPU／16 GB といった小型構成を既にサポートしており、常時利用が前提の軽作業やタスクワーカー、検証用途にはこちらが適します。
背景：なぜ Dev Box に小型 SKU がないのか（設計思想から読み解く）
- 用途の想定：Dev Box は「開発者が即座に使える高性能ワークステーション」をクラウドで提供するサービスで、ビルドや IDE、エミュレーターを想定したメモリ・I/O 余裕のある構成が前提です。
- コストモデル：Dev Box は時間課金＋月額上限（Max Monthly Price）のハイブリッド。高頻度利用なら上限で打ち止め、低頻度利用なら起動時間に応じて課金というモデルで、軽作業を小型で常時起動する設計とは異なる思想です。
- 今後の提供形態：小型 SKU ニーズは Windows 365 へ統合して満たす方針が明言され、Dev Box 自体を小型化する方向にはありません。
実務に効く「回答・解決策」まとめ
| 項目 | 内容 |
|---|---|
| 現状の制限 | Dev Box は 8 vCPU 以上の SKU のみ提供。2 vCPU／8 GB・4 vCPU／16 GB は選択肢自体が存在しない。 |
| 代替案 | 1) Windows 365 Cloud PC：2 vCPU／8 GB など小規模構成あり。常時利用の軽作業やタスクワーカーに適合。 2) Azure Virtual Desktop（AVD）／通常の Azure VM：任意サイズを選択可。単発検証や一時利用、マルチセッションなど柔軟に設計可能。 |
| コスト削減策（Dev Box を使い続ける場合） | ハイバネーション（休止）：8／16 vCPU SKU のみ対応。32 vCPU は非対応。 自動停止スケジュール：プール単位で毎日指定時刻に停止／休止。 切断時停止（Stop on disconnect）：RDP 切断後、猶予（60〜480分）経過で自動停止。休止対応の定義が前提。 |
| サポート依頼 | 不足は リージョン容量／vCPU クォータの調整依頼のみ。2/4 コア SKU の追加要望は不可。 |
| ロードマップの注意 | Dev Box 機能は Windows 365 へ統合。新規顧客受付は 2025/11/01 で停止。小型 SKU は Windows 365 側でカバー。 |
Dev Box を継続利用する場合のコスト最適化：徹底ガイド
ハイバネーション（休止）を前提に設計する
Dev Box のコストを劇的に下げる鍵はハイバネーションです。休止を有効化した定義から作られた Dev Box は、停止ではなく「メモリ状態を保存して休止」でき、休止中はコンピュート課金が発生しません（ストレージは継続）。対象は 8／16 vCPU SKU のみ、32 vCPU は非対応である点に注意してください。また、休止には「休止対応イメージ」「定義側での有効化」が必要です。
- 互換性の注意：Memory Integrity（HVCI）や特定の最適化イメージは休止非対応。Nested Virtualization の有効化が必要なケースもあります。
- 運用のコツ：初回から休止対応の定義で払い出す。既存ボックスは休止対応へ切替できないため再作成を検討。
自動停止スケジュールで毎日確実に止める
プール単位のAutostopを使えば、終業時刻（例：19:00 JST）に一斉停止／休止できます。休止対応の定義から作られた Dev Box はスケジュール到来時に休止、非対応なら停止になります。これだけで夜間の無駄な稼働を撲滅可能です。
切断時停止（Stop on disconnect）で「放置」を撲滅する
RDP 切断後に設定した猶予（60〜480分）が過ぎると自動停止する仕組み。作業が長引いた際の誤停止を防ぐため、まずは180分など余裕を持った値から始め、実績を見ながら短縮していくのが現場では安全です。なお、休止対応の定義で作成された Dev Box にのみ適用されます。
ポータル操作手順（GUI）
休止（ハイバネーション）の有効化
- 「Dev Center」→「Dev Box 定義」を開き、対象定義を編集。
- 「ハイバネーションを有効化」にチェックして保存。以後、その定義から作る Dev Box は休止可能に。
自動停止スケジュールの設定
- 「プロジェクト」→「Dev Box プール」→該当プールの「編集」。
- 「管理」→「コスト制御」で「スケジュール停止」を有効化し、時刻とタイムゾーンを設定。
切断時停止の設定
- 「プロジェクト」→「Dev Box プール」→プールの「編集」。
- 「Stop on disconnect」を有効化し、猶予時間（60〜480分）を設定。
IaC／CLI で一括適用する（Bicep／CLI スニペット）
スケジュール停止（Autostop）の Bicep
// 例：毎日 23:00 JST に停止/休止（休止対応定義の Dev Box は休止）
resource schedule 'Microsoft.DevCenter/projects/pools/schedules@2024-05-01-preview' = {
name: '${projectName}/${poolName}/daily-stop-2300'
properties: {
type: 'Stop'
frequency: 'Daily'
time: '23:00'
timeZone: 'Asia/Tokyo'
state: 'Enabled'
location: location
}
}
上記のスキーマは Microsoft.DevCenter テンプレートの projects/pools/schedules リソースで提供されています。
切断時停止（Stop on disconnect）の CLI
# 猶予 180 分で有効化（プール単位）
az devcenter admin pool update \
--resource-group <rg> \
--project <projectName> \
--pool-name <poolName> \
--stop-on-disconnect status="Enabled" grace-period-minutes="180"
猶予は 60〜480 分の範囲で設定できます。
休止対応の Dev Box 定義を CLI で有効化
# 既存の定義を休止対応に切り替え
az devcenter admin devbox-definition update \
--resource-group <rg> \
--dev-center-name <devCenterName> \
--dev-box-definition-name <defName> \
--hibernateSupport Enabled
休止を有効にするには、イメージ側も休止対応である必要があります。
要件別の推奨パターン
| ユースケース | 推奨サービス | 理由 |
|---|---|---|
| フロントエンド／QA／軽作業を常時利用 | Windows 365（2 vCPU／8 GB 〜） | 小型 SKU を選べ、起動待ちのない常時稼働に強い。Intune/Entra による統合管理。 |
| 開発・ビルド・エミュレーター多用 | Dev Box（8/16/32 vCPU） | 高性能を即時払い出し、開発者セルフサービスとガードレール（Dev Center）の両立。ハイバネーションでコスト抑制。 |
| 多数ユーザーの一時利用／マルチセッション | Azure Virtual Desktop | 任意サイズとマルチセッションにより高集約。費用効率良くピークを吸収。 |
| 短期 PoC／特殊サイズ・GPU・スポット活用 | 通常の Azure VM | サイズ自由度が最大。従来の IaaS 運用に慣れたチームで設定しやすい。 |
コスト試算の考え方（数字に依存しない実務フレーム）
Dev Box は「ストレージは常時課金／コンピュートは稼働時間課金（上限あり）」という特性を押さえれば、概算は自社の勤務実態から再現できます。
- 1日の実稼働時間を定義（例：7.5h）。
- 自動停止スケジュールとStop on disconnectで「夜間・週末ゼロ稼働」を徹底。
- 月間稼働時間＝実労働日数×1日の実稼働時間。
- コンピュート料金（時間単価×稼働時間）＋ストレージ料金 ≦ 月額上限の場合は上限で打ち止め。
このフレームに自社の勤務パターン（在宅率、PC 放置の癖、時差チームの重なり）を反映させ、休止を最大化する運用へ改善していくのが王道です。
運用ベストプラクティス（現場で効く 10 項）
- ペルソナ別定義：ビルド多用／IDE 重い人は 16 vCPU、それ以外は 8 vCPU。定義でローカル管理者権限やイメージを分離。
- 初回から休止対応：休止非対応で作ってしまうと後から切替不可。配布前に必ずイメージと定義をチェック。
- プールのコスト制御を強制：Autostop＋Stop on disconnect の二段構えで「消し忘れ」をゼロに。
- ガバナンス：Dev Center／Project の RBAC を明確化。開発者セルフサービスの範囲とガードレールの境界を定義。
- ネットワーク：Dev Box／Windows 365／AVD／VM を同一セグメントに収容する場合は NSG/Firewall/Private DNS を標準化。
- イメージ戦略：Azure Compute Gallery と Image Builder（AIB）でバージョン管理。休止対応フラグをテンプレート化。
- セキュリティ：HVCI 非対応の制約を理解し、必要に応じて代替コントロール（Defender for Endpoint、条件付きアクセス等）で補完。
- 監視と FinOps：稼働時間とユーザー行動を可視化し、猶予時間の最適化（180→120→90 分…）で段階的に節約。
- スケール設計：ビルドピークに合わせて 16→32 vCPU へ一時的にスケールアップ、終了後に元へ戻す運用ルールを定義。
- 教育：「切断＝放置」とならないよう、開発者ポータルからの手動休止／停止も周知徹底。
Windows 365／AVD／Azure VM を選ぶ場合の具体アドバイス
Windows 365 の押さえどころ
- 小型 SKU が豊富：2/8、4/16 を中心に幅広い選択肢。常時起動前提のペルソナに最適。
- 運用のシンプルさ：Intune と Entra 統合、プロビジョニングはプロファイルで統一化。
- Dev Box 統合の流れ：Dev Box の開発者特化機能が段階的に Windows 365 に入ってくる見通し。
Azure Virtual Desktop（AVD）／通常の Azure VM の押さえどころ
- サイズ自由度：単発検証や GPU、メモリ最適化サイズなど、要件に応じた自由度が高い。
- マルチセッション：AVD の Pooled で利用率を最大化。タスクベースの大人数に強い。
- コスト制御：スケールセッション管理やスケジュール停止、スポット VM など IaaS の定石がそのまま効く。
よくある質問（FAQ）
Q. サポートに「2/4 コア SKU を有効化してほしい」と依頼すれば可能？
A. いいえ。現在は 8 コア以上のみ。SKU 追加リクエストは受け付けられず、クォータや容量の調整のみが対象です。
Q. Dev Box の休止は全 SKU で使える？
A. いいえ。8／16 vCPU は対応、32 vCPU は非対応です。イメージと定義の双方で休止を有効化する必要があります。
Q. 自動停止と切断時停止は併用できる？
A. はい。プールのスケジュール停止で日次の締め、Stop on disconnect で日中の放置を抑え、二段構えでコストを最小化できます。
Q. これから初めて導入するなら Dev Box と Windows 365 のどちらを選ぶべき？
A. 小型 SKU を前提にしたい場合は Windows 365 を第一候補に。Dev Box は既存利用ならコスト制御を強化して継続、あるいは段階的に Windows 365 へ寄せる方針が現実的です（Dev Box の新規顧客受付は 2025/11/01 から停止）。
実行チェックリスト：明日からできる 7 ステップ
- 現状の Dev Box 定義を棚卸し（休止対応フラグ／SKU／ローカル管理者権限）。
- 休止非対応の定義は作り直し、プールへ段階展開。
- 全プールにスケジュール停止を適用（まずは 19:00 JST）。
- Stop on disconnect を 180 分で有効化、以降 120→90 分に短縮。
- Windows 365 の小型 SKU で「軽作業」ペルソナを移行検証。
- AVD／通常 VM で特殊サイズ・GPU の PoC を実施。
- FinOps ダッシュボードで稼働実績を可視化、月次で閾値を見直し。
最後に：選定の指針
低スペック SKU を Dev Box で「裏技的に」有効化する方法はありません。現状の正攻法は、Windows 365 に小型 SKU の役割を任せる、または AVD／通常 VM でサイズ自由度を確保すること。そして、Dev Box を継続する場合は休止＋自動停止＋切断時停止の三本柱でムダな稼働を徹底的に削ることです。これが、品質とコストを両立させる最短距離です。
参考：構成の比較早見表
| 観点 | Dev Box | Windows 365 | AVD／通常 VM |
|---|---|---|---|
| SKU 下限 | 8 vCPU／32 GB 以上（32/128 まで） | 2/8、4/16 など小型あり | 任意（シリーズから選択） |
| 課金モデル | 時間課金＋月額上限、休止でコンピュート無課金（ストレージは継続） | ユーザー／月 | 時間課金（予約・スポット・自動停止で最適化） |
| 停止自動化 | スケジュール停止、切断時停止、休止対応あり | 自動起動／再起動、運用は Intune で制御 | スケジュール、スケールイン、Host Pool の調整 |
| 今後の方向性 | Windows 365 へ機能統合（新規顧客受付停止） | Dev Box 機能取り込みが進む見込み | 従来どおり（IaaS／AVD として運用） |
（本記事の仕様・提供状況は 2025年11月時点の公開情報に基づいています。導入前には必ず自社テナントでの表示 SKU・機能可用性を確認してください。）
コメント