Microsoft Dev Box

解決する課題

新しい開発者がプロジェクトに参加するたびに、OS のセットアップ、SDK やツールの導入、リポジトリの取得、社内ポリシーの適用までを手作業で行うと、生産的に着手するまでに何日もかかります。Microsoft Dev Box は、こうした準備をあらかじめ作り込んだクラウド上の開発ワークステーションとしてオンデマンドに払い出し、環境構築の負担と差異を取り除きます。

• 新規参加者やプロジェクト切り替えのたびに発生する環境構築の待ち時間を短縮したい
• チーム間で開発環境を標準化し、「自分の端末では動く」という差異をなくしたい
• 重いビルドや大規模リポジトリを扱える高性能なマシンを、物理端末を購入せずに必要なときだけ使いたい
• 開発環境をEntra ID と Intune の統制下に置き、企業のセキュリティとコンプライアンスを満たしたい
• BYOD や遠隔地のメンバーにも、安全に統制された開発環境を配布したい

主要概念と用語

• Dev Box（開発ボックス）: 開発者に払い出される個別のクラウド開発マシン。ツールやリポジトリが構成済みの Windows ワークステーション
• Dev Center（開発センター）: Dev Box 全体を束ねる最上位の管理リソース。イメージ カタログやネットワーク接続などの共通設定をここに集約する
• プロジェクト（Project）: チームや製品の単位。どの Dev Box 定義を使えるか、誰が払い出せるかをプロジェクト単位で管理する
• Dev Box 定義（Dev Box Definition）: マシンの基となるイメージと**SKU（CPU・メモリ・ストレージ）**の組み合わせ。払い出されるマシンの仕様を決める
• Dev Box プール（Pool）: プロジェクト内で、ある定義とリージョン・ネットワーク設定をまとめた払い出しの母体。開発者はプールから自分の Dev Box を作成する
• イメージ（Image）: 既製のマイクロソフト製イメージのほか、Azure Compute Gallery のカスタム イメージを使ってツール導入済みの状態を作り込める
• ネットワーク接続（Network Connection）: Dev Box を企業の仮想ネットワークやオンプレミス資源に接続するための設定
• 開発者ポータル（Developer Portal）: 開発者が自分の Dev Box を作成・起動・停止・削除するセルフサービス画面

仕様・制限・クォータ

• 提供されるのは原則としてWindows のクライアント OSを備えた開発向けワークステーションで、開発者ごとに個別のマシンとして払い出される
• マシンの性能はDev Box 定義の SKUで決まり、用途に応じて CPU コア数・メモリ・ストレージを選べる。重いビルドには上位 SKU を割り当てる
• 管理は Microsoft Intune に統合され、Dev Box は管理対象デバイスとしてポリシー適用やコンプライアンス評価の対象になる
• 1 つのプロジェクトやユーザーが同時に持てる Dev Box 数には上限の設定があり、無秩序な増殖を抑えられる
• サブスクリプションやリージョンごとに、利用できる vCPU 数などにクォータがあり、規模に応じて引き上げを申請する
• 利用できるリージョンや SKU の種類は変動するため、計画時は対象リージョンの最新の提供状況を確認する

内部の仕組み

管理者は Dev Center を作り、その中に開発環境の元となるイメージと SKU を束ねた Dev Box 定義を用意します。プロジェクトには定義とネットワーク設定をまとめたプールを割り当て、開発者は開発者ポータルからプールを選んで自分の Dev Box を作成します。マシンの起動・構成・ライフサイクルはサービス側が受け持つため、利用者は環境構築を意識せずに使い始められます。

• 払い出し時は、選ばれたイメージから新しい仮想マシンをプロビジョニングし、定義どおりの SKU で起動する
• カスタム イメージにツールやリポジトリを焼き込んでおけば、起動直後から構成済みの状態で使える
• Dev Box は Entra ID で参加し、Intune の管理対象として企業ポリシーが適用される
• ネットワーク接続を介して、企業の仮想ネットワークやオンプレミスの社内リソースへ到達できる
• 開発者は接続クライアントやブラウザー経由でリモート デスクトップとして Dev Box に接続して作業する

設計パターン / ベストプラクティス

• プロジェクト単位で定義を分ける: チームや製品ごとに必要なツールが異なるため、Dev Box 定義とプールをプロジェクトに合わせて用意する
• イメージを版管理する: カスタム イメージを Azure Compute Gallery でバージョン管理し、ツール更新を計画的に反映して再現性を保つ
• SKU を用途で使い分ける: 軽作業には小さめ、重いビルドやコンテナー作業には上位 SKU と、コストと性能のバランスをとる
• ネットワークを事前設計する: 社内リソースへ到達が必要なら、仮想ネットワーク接続と名前解決・経路を先に整える
• 自動停止を活用する: アイドル時にシャットダウンするスケジュールを設定し、稼働時間に応じたコストを抑える
• Intune ポリシーで統制する: コンプライアンス ポリシーや構成プロファイルを適用し、開発環境のセキュリティ水準を全台でそろえる

運用・監視

• マシンのライフサイクル（作成・起動・停止・削除）は開発者ポータルやサービス側に任せ、自動停止スケジュールで無駄な稼働を抑える
• 管理対象デバイスとして Intune からコンプライアンス状態や構成プロファイルの適用状況を監視する
• イメージ更新時は新しい版を定義へ反映し、開発者が最新の構成済み環境を払い出せるようにする
• 払い出しや権限はプロジェクトの RBAC で統制し、誰がどのプールを使えるかを明確にする
• 操作や管理イベントは Azure の監査ログ（アクティビティ ログ）で追跡し、ガバナンスに役立てる

コスト

課金は、おおむねDev Box の SKU（コンピューティング）とアタッチされたストレージの稼働量に基づきます。マシンを停止している間はコンピューティングの課金が抑えられる一方、ストレージは保持している分がかかるため、自動停止と不要なマシンの削除が効きどころです。

セキュリティ

• Dev Box は Microsoft Entra ID に参加し、サインインと条件付きアクセスを企業の ID 基盤で統制する
• Microsoft Intune の管理対象として、コンプライアンス ポリシーや構成プロファイルを全台へ適用する
• 社内リソースへの到達は仮想ネットワーク接続を介して行い、ネットワーク境界とアクセス経路を管理する
• 払い出しや管理の権限は Azure RBAC で最小化し、プロジェクト単位で誰が何をできるかを限定する
• データは Dev Box 内に閉じ込め、端末ローカルへ機微情報を残さない運用にできるため、BYOD でも統制を効かせやすい

関連サービス・比較

開発環境の提供という点では Azure Deployment Environments が近い関係にあります。Dev Box が開発者個人の作業マシンを払い出すのに対し、Deployment Environments はアプリの動作環境（インフラ一式）をテンプレートから払い出します。両者は同じ Dev Center 上で補完的に使えます。

ハンズオン / CLI例

# Dev Center とプロジェクトは事前に作成済みとする
# 拡張機能を追加（必要に応じて）
az extension add --name devcenter

# 自分が利用できるプロジェクトを一覧表示
az devcenter dev project list \
  --dev-center-name contoso-devcenter

# プロジェクト内で利用できる Dev Box プールを確認
az devcenter dev pool list \
  --dev-center-name contoso-devcenter \
  --project-name web-team

# プールから自分用の Dev Box を作成（払い出し）
az devcenter dev dev-box create \
  --dev-center-name contoso-devcenter \
  --project-name web-team \
  --pool-name win-dev-pool \
  --name my-devbox

# 接続用のリモートデスクトップ情報を取得
az devcenter dev dev-box show-remote-connection \
  --dev-center-name contoso-devcenter \
  --project-name web-team \
  --name my-devbox