Dev Box終了、Windows 365へそのまま移れる？開発環境を守る移行チェック

「Dev Boxが終わるなら、Windows 365に移せばいい」。移行先の名前は分かっても、今の開発環境まで引き継がれるとは限りません。先に確かめたいのは、手元だけに残ったコード、WSLのデータ、社内への接続、そして誰が新しい環境を用意するかです。

Microsoft Dev Boxの終了は2028年9月18日17:00 UTC（日本時間9月19日午前2時）。MicrosoftはWindows 365を推奨する一方、1対1の代替ではないと説明しています。この記事では、移行担当者と開発者が最初に合意したい差分を整理します。自社の環境での移行完了や性能を実測した記事ではありません。

終了期限と変わる運用

まず分けたいのは「終了まで現在の環境を使うこと」と「次の環境を準備すること」です。公式退役ガイドは、既存のDev Boxを移行中の一時的な環境として使いつつ、新たな長期依存を増やさないよう求めています。期限が先でも、イメージや配備手順を増やし続けると、移す対象も増えます。

Windows 365では、IntuneやMicrosoft Entra ID、ライセンスとプロビジョニングポリシーを使って対象のCloud PCを用意します。Dev Boxのprojectやpool、開発者が環境を作る流れが、同じ名前・同じ操作で残るという理解は避けましょう。

確かめる項目	移行前に決めること
環境を用意する人	開発者のセルフサービスを、管理者の配備・変更受付へどう置き換えるか
開発ツールと設定	イメージ、アプリ、スクリプトへ何を組み込み、何を利用者が設定するか
ユーザーデータ	新しいCloud PCへ持ち込む対象と、外部に保管し続ける対象を分ける
変更と責任	ライセンス、端末管理、接続障害、開発ツールをそれぞれ誰が担当するか

「移行後もこのコマンドで開発を始められる」と言えるかを、小さな代表環境で確かめるのが出発点です。製品名が決まったことと、作業が再現できたことを別の完了条件にします。

根拠：Microsoftの退役ガイド、Windows 365への移行ガイド。

消える前に保全する開発データ

移行ガイドは、新しいCloud PCのプロビジョニングに備えて、コード、WSLデータ、資格情報、ローカルのテスト資産を保全するよう案内しています。リポジトリにpushしたから全部済んだ、と考えると取りこぼしが生まれます。

コード：未commitの変更、未追跡ファイル、ローカルだけのブランチを洗い出す。
開発データ：WSL、ローカルDB、テスト用ファイル、再取得できない成果物の保存場所と復元手順を決める。
設定と秘密情報：ツール設定と、認証情報・証明書を区別する。秘密情報は組織の承認済み管理手順で再配布・更新し、記事の一般手順を理由に平文で持ち出さない。
再現手順：必要なバージョン、接続先、ビルド方法、社内依存を、別の担当者が再現できる形で残す。

保全は「コピーできた」だけで終えず、移行先で開ける、ビルドできる、必要なテストを動かせるところまで確認します。バックアップ先にファイルがあっても、復元に必要な権限や鍵が欠けていれば作業は戻りません。

Windows 365の復元ポイントも、移行元の資産を自動的に集めてくれる仕組みとは分けて考えます。公式の復元説明では、復元時点より後のローカル変更を失う可能性が示されています。コードの保管、業務データの保管、端末を過去の状態へ戻すことに、それぞれ担当と確認方法を置きましょう。

根拠：移行前の保全事項、復元ポイントの仕様。

mineo

主回線・予備回線

軽い連絡用か、外でも働く主回線かを選びたい人へ

そのSIMに任せる仕事を、先に決めよう。

容量で選ぶマイピタ、速度で選ぶマイそく。チャット中心なのか、会議にも使うのか。仕事の中身から、自分に合うプランを絞れます。

月に使うデータ量
昼の利用と速度制限
使う端末・回線の組み合わせ

自分の働き方に合うプランを、公式で見比べる。

mineo公式サイトへ

マイそくには平日昼間などの速度制限があります。会議や納品に使う場合は、制限条件まで確認してください。

ライセンスと接続は別々に検証

Windows 365 Enterpriseの要件では、Windows、Intune、Microsoft Entra ID P1、Windows 365のライセンス条件を確認する必要があります。今ある契約に何が含まれるかを管理者と照合し、Cloud PCのサイズ、利用人数、必要な管理機能を決めてから見積もります。

Dev Boxと月額だけを並べても、総額は比較できません。契約条件、使うサイズ、稼働の仕方、ネットワークの追加費用、管理工数を同じ前提にそろえる必要があります。このResearchでは、対象組織の日本円での契約価格や、既存環境の実利用額は確認できていません。一律に節約できるとは判断しません。

接続側では、Microsoft-hosted networkと、顧客側のAzureネットワークを使う構成の責任範囲を確認します。後者を選ぶ場合は、VNet、DNS、経路、ファイアウォール、帯域などを自社側で設計・運用する範囲が増えます。必要な接続先やプロキシ、TLS検査の扱いは、最新の公式要件と組織の方針を照合してください。

パイロットで確認するのは「Windows Appからログインできた」だけではありません。社内リポジトリへの接続、パッケージ取得、社内API、普段のビルド、長時間のセッションを、実際に使う場所と経路で試します。遅延や性能は自社環境の測定項目として扱い、製品の一般説明から実測値を推測しません。

移行に合わせてアカウント、共有方法、管理者権限も見直すなら、チームのセキュリティ点検で確認漏れを整理し、テナント固有の設定は管理者の手順へ落とし込めます。

根拠：Enterpriseの要件、ネットワーク要件。

代表環境から切り替えるチェックリスト

次の一手は、全員分の環境をまとめて作り直すことより、違いが分かる代表パイロットを決めることです。以下は、公式移行フローを実務上の確認順に整理したものです。個別のテナントで合格を保証する手順ではありません。

棚卸し：使っているDev Box、イメージ、開発ツール、接続先、保管しているデータを一覧にする。
利用場面を分ける：標準的な開発、重いビルド、特別なGPUや社内接続など、要求が違う作業を分ける。
対象構成を決める：ライセンス、サイズ、ネットワーク、アプリ配備、権限の担当者を決める。
保全と復元を試す：コード、WSL、テスト資産を退避し、代表のCloud PCで必要な作業を再現する。
合格条件を記録する：接続、ビルド、テスト、権限、費用を確認し、未解決事項と切戻し条件を残す。
段階的に展開する：対象を広げ、不要になったDev Box側の資源は依存関係と保持条件を確認してから、承認済みの廃止手順へ渡す。

【Noa's View】移行計画の主語を「サービス」から「明日の作業」へ変えると、確認すべき点が見えやすくなります。同じリポジトリを開き、同じテストを回し、必要な人が適切な権限で働けるか。その再現を確かめてから対象を広げる、という判断です。

今日できることは、ローカルだけにある資産を一つ洗い出し、保管先と復元確認の担当者を決めること。Windows 365という移行先の名称だけでは埋まらない差分を、作業と責任の一覧にしていきましょう。

出典・確認した資料

2026年10月15日確認。契約・提供条件は最新の公式情報を確認してください。