AWSは、Amazon WorkSpaces Personalがネスト仮想化をサポートし、Docker Desktopをクラウド上で動作させる構成を発表した。Power、PowerPro、General PurposeバンドルではWSL2、Kubernetes、Docker Compose、Androidエミュレータを含むDocker Desktopの全機能が動作し、StandardおよびPerformanceバンドルではDocker Offloadによりコンテナ実行が提供される。Laravelを軸とする個人開発者にとって、ローカル端末の固定化と環境再現性を同時に解決する手段となる。
バンドル別の実行モデルと運用上の利点
ネスト仮想化は、WorkSpaces PersonalおよびCoreバンドル全般で有効化された。Value、Amazon Linux 2、Windows Server 2016、Windows 10は対象外である。完全なローカル動作を求める構成ではPower、PowerPro、General Purposeが推奨され、Docker DesktopがWorkSpaces内部で完結する。コンテナ、ホスト、ネットワークが単一マシンに閉じる構成であり、Docker-in-Docker、Compose、エミュレータを含むすべてのワークフローが動作する。LaravelであればPHP、Composer、Node、データベースをDocker Composeで束ねる構成がそのまま再現できる。
StandardとPerformanceではDocker Offloadが使われる。Docker DesktopをリモートVMで実行する方式であり、エンドポイント側の仮想化は不要となる。CLI操作とビルド結果は手元に戻り、計算処理だけがクラウドへ移る。WorkSpaces側は軽量に保たれ、コストとプロビジョニングの面で有利である。両バンドルは同じ基盤の上で動作するため、IT部門は開発者のプロファイルに応じて戦略を並存できる。
クラウドデスクトップが解決する課題は三つある。ソースコードをエンドポイントに置かないこと、ゴールデンイメージで環境ドリフトを排除すること、開発端末のプロビジョニングを週単位から分単位に短縮すること。Docker Desktopはハイパーバイザを必要とし、従来のクラウドデスクトップはこれを提供できなかった。ネスト仮想化とDocker Offloadの組み合わせで、このギャップが埋まる。プラットフォームエンジニア、フルスタック開発者、モバイル開発者のそれぞれが、必要なコンテナワークフローを同じマネージド環境の上で実行できる。
WorkSpacesを単なるVDIのリフト＆シフトとして扱うことはアンチパターンである。レガシーの制約を引きずり、WorkSpacesのアーキテクチャ上の利点を逃す結果になる。設計段階からエラスティックな開発者セルフサービスを前提に置く必要がある。
周辺リリースで確認する点
Docker Desktop 4.88.0が発表された。Windows自動アップデートの失敗、WSL統合の問題が修正され、Gordon AIアシスタントの改善が含まれる。サポート終了にも注意が必要である。RHEL 8、Windows 10 21H2、Windows 11 22H2、macOS 13は次回リリース以降サポート対象外となる。Windows 10 22H2以上、Windows 11 23H2以上、macOS 14以上が必須となり、RHELは9または10への移行が次回リリースで必要となる。コンテナ内部のQEMUは8.1.5から10.0.4へ上がり、ARM64上での/sbin/ldconfigクラッシュが解消された。CVE-2025-23266として報告されたNVIDIA Container Toolkitの脆弱性は、バンドルされた1.17.8で影響を受けず、4.44以降への更新が前提となる。古いGoでビルドされたamd64バイナリはARM64エミュレーション下でセグフォルトする可能性があり、Go 1.25.4以降での再ビルドが推奨される。バンドルされるDocker ComposeおよびBuildxのバイナリはバージョン文字列の表示が異なり、互換性検証を伴う。
確認項目を整理する。
- 開発者の作業内容ごとにバンドル選定を分ける
- WSL2バックエンドの有効化を検証する
- ホストOSの最低バージョンに開発機とCIが準拠しているか確認する
- ARM64エミュレーション環境では依存バイナリを再ビルドする
- CDIモード利用の有無を確認し、CVE-2025-23266の影響範囲を点検する
- Docker Compose / Buildx のバージョン文字列差異を把握する