--- title: "Docker VMMとは？4.86の自前ハイパーバイザと切り替え判断【2026年8月時点】" url: "https://www.issoh.co.jp/tech/details/16896/" published: 2026-08-24 updated: 2026-09-27 categories: ["Kubernetes・コンテナ"] publisher: "株式会社一創" --- # Docker VMMとは？4.86の自前ハイパーバイザと切り替え判断【2026年8月時点】 Docker VMMは、Docker Desktopの下でLinux仮想マシンを動かす層をDocker自身が作り直したものです。2026年8月12日に公開されたDocker公式ブログでパブリックベータが告知され、Docker Desktop v4.86からMacとWindowsの双方で選べるようになりました。国内でこの話題が広がったのは8月20日前後ですが、一次情報の公開日は8月12日です。 この記事では、VMMという層が開発端末で何をしているのかを整理したうえで、切り替えの手順と要件、ベータ時点で分かっている制約、そして受託開発の現場で今切り替えるかどうかの線引きまでを扱います。 ## まとめ：切り替える条件と見送る条件を先に示す 結論から書きます。Arm向けイメージで開発が完結していて、データストアがPostgreSQLやMySQLなど一般的な構成であれば、ベータ期間中でも個人の開発端末で試す価値があります。一方、amd64イメージのエミュレーションに依存している現場は据え置きが妥当です。全社の標準を切り替える判断は、2026年10月末を目標とするGAまで待つほうが無理はありません。 - **層の位置づけ**：Docker DesktopはLinux仮想マシンを1つ起動し、その中でコンテナを動かす。その仮想マシンを作って回す部分がVMMで、今回そこが入れ替わった - **何が変わったか**：Mac版の4.35〜4.85は外部ライブラリのlibkrunが土台だったが、4.86からDocker自身が書いたハイパーバイザになり、Windowsにも同名の選択肢が加わった - **効く場面**：コンテナの起動、ホストとコンテナ間のファイル読み書き、アイドル時のメモリ返却という3点 - **要件**：Linux仮想マシンへのメモリ割り当てが4GB以上。切り替え後はバインドマウントの自動共有が働かないため、共有ディレクトリを手で登録する - **制約**：Mac側はRosettaに対応しないためamd64エミュレーションが遅い。MongoDBやCassandraがvirtiofs上で起動に失敗する場合があるとドキュメントに明記されている - **Linux**：ベータ期間中は対象外で、GAの時点で提供される予定 ## Docker VMMとはDocker Desktopの下で動く仮想化層のこと LinuxコンテナはLinuxカーネルの機能で隔離されるため、macOSやWindowsのカーネルの上で直接は動きません。そこでDocker Desktopは軽量なLinux仮想マシンを1つ起動し、その中でコンテナを走らせています。この仮想マシンを作り、CPUやメモリを割り当て、ホストとの間でファイルやネットワークを橋渡しする部分がVMM（Virtual Machine Manager）です。コンテナの概念そのものについては[コンテナと仮想マシンの違いから導入判断までをまとめた解説](https://www.issoh.co.jp/column/details/13000/)を先に読むと、層の重なりが理解しやすくなります。 ユーザーが日常的に触るのはdockerコマンドとイメージだけなので、この層は普段ほとんど意識されません。ところが起動が遅い、ソースコードのマウントが遅い、メモリを掴んだまま離さないといった不満は、多くがこの層の性質から来ています。今回Dockerが手を入れたのは、まさにその部分でした。 ### libkrunから自前実装へ替わったDocker Desktop 4.86の位置づけ Docker VMMという名前自体は新しくありません。Mac版では2024年11月のDocker Desktop 4.35からベータとして選べており、当時の土台は外部プロジェクトのlibkrunでした。公式ドキュメントは、4.35から4.85までがlibkrun、4.86以降がDocker自身のハイパーバイザという区切りを明記しています。つまり4.86は、名前は同じでも中身が入れ替わった版です。 この置き換えによって、DockerはmacOSとWindowsで同じ仮想化コードを持つことになりました。プラットフォームごとに別の基盤へ依存していた状態が解消されるため、片方だけで起きる不具合や設定差は減る方向へ働きます。同じエンジンはDocker Sandboxesの実行基盤にもなっていると報じられており、Docker Desktop以外の製品にも波及する土台という位置づけになります。 ### MacとWindowsで選べる仮想化方式と分離・速度の現在地 Docker VMMは唯一の方式ではなく、設定画面で切り替えられる選択肢の1つです。2026年8月時点でドキュメントに載っている顔ぶれは次のとおりです。 | ホスト | 選択肢 | 位置づけ | | ------- | -------------------- | ---------------- | | Mac | Docker VMM | 4.86で自前実装へ更新 | | Mac | Apple Virtualization | Rosettaを使う場合の選択肢 | | Mac | HyperKit | Intel機向けの旧方式 | | Windows | WSL 2 | 現行の既定バックエンド | | Windows | Docker VMM | 4.86で追加された新方式 | | Windows | Hyper-V | 分離を優先する従来方式 | GAの時点でLinuxが加わり、新規インストールの既定エンジンになる計画が公式ブログに書かれています。目標は2026年10月末です。既存環境がどう扱われるかは明示されていないため、更新前に現在の方式を控えておく運用が安全でしょう。 ## 起動・ファイル共有・メモリ返却という3つの変化を端末で測る見方 公式が挙げている改善は、コンテナ起動の速さ、ホストとコンテナ間のファイル読み書きの速さ、そしてアイドル時にメモリをホストへ返す挙動の3点です。注意したいのは、今回のパブリックベータの告知に具体的な数値が添えられていない点になります。速くなったという記述はあっても、何秒が何秒になったという公開値はありません。 参考になる数字は前世代のものだけです。2024年11月21日のDocker公式ブログは、4.35世代のVMMとApple Virtualization frameworkをM1・M2搭載機で比べ、大きなリポジトリでのgit statusが初回で約27秒から10秒弱へ、2回目以降は約3秒から1秒未満へ短縮したと示しています。ただしこれは土台がlibkrunだった時期の計測で、4.86の実装値としては扱えません。数字を根拠に社内へ提案するなら、自分の端末で測り直す必要があります。 ### 自分の端末で起動・入出力・メモリを測るなら実測対象を3つに絞る 測定項目を増やすと判断が鈍ります。切り替え前後で比べる対象は次の3つで足ります。いずれも切り替え前に同じ手順で記録しておき、切り替え後に同条件で取り直してください。 - **初回起動**：Docker Desktopを終了した状態から起動し、`docker run --rm hello-world`が返るまでの時間 - **マウント越しの読み書き**：ソースツリーをバインドマウントしたコンテナ内で、依存パッケージのインストールとgit statusを実行した時間 - **常駐メモリ**：ビルドを1本流したあと30分放置し、タスクマネージャやアクティビティモニタでDocker Desktopの常駐量を確認 3つ目がアイドル時のメモリ返却に対応します。従来はコンテナを止めても仮想マシンが確保したメモリがホストへ戻りにくく、開発端末の常駐量が積み上がる場面がありました。ここが改善されているかどうかは、終業時の実測値で判断できます。 ## WindowsでWSL 2やHyper-Vとどう使い分けるか Windowsの既定はWSL 2です。速度面で有利な一方、コンテナはWSL 2のユーティリティVMという共有基盤の上で動きます。分離を強くしたい場合はHyper-Vを選ぶ設計でしたが、こちらは起動やファイル入出力で不利です。公式ブログはDocker VMMの狙いを、Hyper-Vに相当する分離を保ちながらWSL 2に近い速度を出すことだと説明しています。この2つのトレードオフを埋める位置づけです。 切り替えを検討する前に確認したいのが、WSL 2バックエンドと組みで提供されてきた機能への依存です。WSL 2上の各ディストリビューションへdockerコマンドを通す統合設定や、WSL側のファイルシステムへ直接置いたソースツリーを前提にした手順が社内に残っていないかを洗い出してください。別方式へ移すと、この前提が変わります。 なお、デーモンを常駐させない構成そのものを見直したいのであれば、方式変更よりも実行系の選択が効きます。[Podmanとdockerの違いをデーモンレス・rootlessの仕組みから整理した記事](https://www.issoh.co.jp/tech/details/13202/)に、その判断材料をまとめてあります。 ## 有効化の手順と切り替える前に確かめるメモリ要件・設定項目の洗い出し 操作は設定画面だけで完結する仕組みです。Settingsを開き、Generalの中にあるVirtual Machine Managerから使いたい方式を選び、Apply & restartを押します。ベータ参加の申請やフィーチャーフラグは不要で、v4.86以降であれば誰でも切り替え可能です。Macで4.35以降のDocker VMMを既に使っていた場合は、設定が引き継がれ、更新後の再起動で新しいエンジンへ移ります。 要件はメモリです。Linux仮想マシンへ4GB以上を割り当てていないと選べません。SettingsのResourcesで現在の割り当てを確認し、下回っていれば先に引き上げておきます。 ### バインドマウントの自動共有が働かない場合に手動登録で対処する 切り替え後に真っ先に踏むのがここです。Docker VMMではバインドマウントの自動共有がサポートされないと明記されており、共有したいディレクトリはSettingsのResourcesにあるFile sharingへ手で登録します。登録漏れがあると、これまで動いていたdocker composeの定義が起動時に失敗します。プロジェクトのルートディレクトリと、外部に置いた設定ファイルやキーの置き場を切り替え前に洗い出しておけば、復旧に時間を取られません。 戻す操作も同じ画面です。元の方式を選んでApply & restartを押せば戻ります。ただし仮想マシンが入れ替わるため、切り替えの前後でイメージやボリュームが見えなくなる前提で準備しておくほうが安全です。レジストリから取り直せるイメージと、取り直せないボリュームを分けて控えておいてください。 ## パブリックベータ時点で分かっているRosettaやデータストアの制約 ドキュメントに書かれている制約は、切り替え可否を左右する具体的なものです。Mac側で最も影響が大きいのはRosettaに対応しない点で、amd64イメージをApple Silicon上でエミュレーションする構成は遅くなります。x86\_64前提のベースイメージや、Intel向けバイナリを含むビルドが残っている現場は、Apple Virtualization frameworkのままにしておく判断が合理的です。 データストアにも既知の注意があります。MongoDBやCassandraなど一部のデータベースが、virtiofsを使う構成で起動に失敗する場合があるとドキュメントは述べています。ローカル環境でこれらを直接動かしているなら、切り替え前に単体で起動を確かめてください。加えて、Linuxホストはベータ期間中の対象外です。 Macで軽さを求めて別製品へ移る選択肢もあります。[OrbStackの特徴・料金・使い方をまとめた記事](https://www.issoh.co.jp/tech/details/4058/)と、[Apple container 1.0とDocker Desktopの違いを扱った記事](/tech/details/7219/)に、それぞれの採用条件を整理してあります。本記事はDocker Desktopの中で方式を選ぶ話に限っているため、製品ごとの比較はそちらを参照してください。Docker Desktop本体の要件・無人インストール・課金境界は[Docker Desktopの導入手順とライセンス境界をまとめた記事](https://www.issoh.co.jp/tech/details/17442/)で扱っています。 ## 受託開発の端末でDocker VMMへ切り替える条件と見送る場面 ここからは判断です。ベータ版を業務端末へ入れるかどうかは、速さではなく再現性の観点で決めます。次の3条件がそろう場合は、個人の開発端末で切り替えて構いません。 - **Arm向けイメージで開発が完結している**：ベースイメージがマルチアーキテクチャ対応で、Rosettaによるエミュレーションを使っていない - **ローカルのデータストアが一般的な構成**：PostgreSQLやMySQL、Redisが中心で、既知の不具合が報告されている製品を直接動かしていない - **端末の常駐メモリが実務の支障になっている**：ブラウザやIDEと同時に動かすと余裕がなく、返却の改善が効く余地がある 逆に、次のどちらかに当てはまるなら見送ります。第一に、amd64エミュレーションが必要な案件を抱えている場合です。第二に、納品前の検証期間に入っている、あるいはビルド環境の構成を記録として残す必要がある案件を担当している場合になります。実行基盤が変わると、再現しない不具合の切り分けに手間がかかるためです。 チーム全体の標準を動かすのはGA後で足ります。ベータ期間は希望者の端末だけで並行検証を進め、上の3項目の実測値と、切り替え時に踏んだ手順を1枚の記録にまとめておくと、10月末以降の展開が短時間で済みます。 ### 端末とクラウド側の実行環境をそろえて本番との差を消すための運用設計 開発端末の方式選びで消せるのは、あくまで端末側の差です。本番との差が問題になっているなら、端末を速くしても解決しません。イメージのビルド方法やベースイメージの版、実行基盤の構成をクラウド側と合わせるところまで含めて設計する必要があります。自社での設計や運用に人手が足りない場合は、[一創のインフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)で、開発環境と本番環境の構成をそろえる設計から相談できます。 ## よくある質問 ### Docker VMMはWindowsのWSL 2より速いのですか？ 公式は速度でWSL 2を上回るとまでは述べていません。説明されているのは、Hyper-V相当の分離を保ちながらWSL 2に近い速度を目指す設計だという点です。分離を優先してHyper-Vを使ってきた環境では速度面の改善を体感しやすく、WSL 2から移る場合は分離の強化が主な動機になります。 ### 切り替えるとイメージやコンテナは作り直しになりますか？ 方式を変えると土台の仮想マシンが入れ替わるため、切り替え後にイメージやボリュームが見えなくなる前提で準備してください。レジストリにあるイメージは取り直せますが、ローカルにしかないボリュームのデータは事前のバックアップが要ります。`docker volume ls`の結果を控えてから作業すると、復旧が容易になります。 ### Apple Virtualization frameworkのままにすべき場面はありますか？ Rosettaでamd64イメージを動かしているなら、そのままにしてください。Docker VMMはRosettaに対応せず、Intel向けバイナリのエミュレーションが遅くなります。MongoDBやCassandraをローカルで直接動かしている場合も、起動を確かめるまでは切り替えを保留する判断が無難です。 ### Linuxの開発端末でも使えますか？ ベータ期間中は使えません。公式ブログはLinux対応をGAの時点で提供すると述べており、GAの目標は2026年10月末です。Linuxを標準端末にしているチームは、この時期以降に検証を始める前提で計画を組んでください。 ### GAで既定になったら自動的に切り替わりますか？ 公式が既定になると述べているのは、GA以降の新規インストールについてです。既存環境の扱いは明示されていないため、更新前にSettingsのGeneralで現在の方式を確認し、記録しておいてください。組織で配布しているなら、更新後に方式が変わっていないかを確かめる手順を運用へ入れておくと安全です。 ## 関連記事 - [docker-composeとは？複数コンテナをymlで定義し一括管理する仕組み](https://www.issoh.co.jp/tech/details/13282/)：切り替え後に共有ディレクトリの登録漏れで失敗する定義を読み解く助けになります - [Dockerの仕組みを原理から理解する｜コンテナ隔離とVMとの違い](https://www.issoh.co.jp/tech/details/2661/)：VMMという層がどこに位置するのかを、隔離の原理から確認できます - [Dev Container（devcontainer）のメリットとは｜開発環境を統一する仕組み](https://www.issoh.co.jp/tech/details/3728/)：端末ごとの差を設定ファイルで吸収する方法が分かります - [コンテナオーケストレーションとは？Kubernetesの役割と必要性の判断](https://www.issoh.co.jp/column/details/13003/)：端末の実行基盤から本番側の運用設計へ話を広げるときの材料です - [Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方](https://www.issoh.co.jp/tech/details/2928/)：本番の実行基盤と開発端末の差をどこまで許容するかの検討に役立ちます --- 出典: [Docker VMMとは？4.86の自前ハイパーバイザと切り替え判断【2026年8月時点】]()（株式会社一創）