Macで Windows のゲームを遊ぶ話を、これまで何回か書いてきました。Whisky亡きあと、Macで無料でどこまで遊べるのか ではゲーム画面に一度も辿り着けず、Apple純正のGame Porting Toolkitを使い倒す でも Steam が起動しませんでした。どちらも 互換レイヤー、つまり「Windows のふりをする仕組み」の上での話です。
そこで当然、こう思うわけです。「ふりをさせるからうまくいかないのでは。素直にWindowsそのものを入れればいいのでは」と😅
今回は、無料で使える仮想マシンソフト2つ ── VMware Fusion と UTM ── にそれぞれ Windows 11 ARM を入れて確かめました。知りたかったのは1点だけです。3Dアクセラレーションが本当に効いているのか。絵が出ることと、GPUが仕事をしていることは別だからです。
結果を先に言うと、片方は本当に効いていて、ゲームが動きました。そしてもう片方では、カタログの数字が全部そちらのほうが上なのに、GPUが一切描いていませんでした😳
もうひとつ、先にお断りしておきます。この記事で分かるのは「土俵に上がれるか」までです。3Dが効いているかどうかは調べれば分かりますが、個々のゲームが動くかどうかは、結局のところ動かしてみないと分かりません。普通に遊べるものもあれば、特定のタイミングで落ちるもの、そもそも起動しないものもあります。そのあたりも最後に書きました。
実験は3つあります。章タイトルに【承前】と付いている章は、直前の章の続きです。
【前置き】「Windowsを入れれば遊べるのでは」という素朴な疑問
Apple Silicon の Mac で Windows のゲームを動かすには、大きく2つの道があります。
①はp956とp967で試して、どちらもゲーム画面に届きませんでした。今回は②です。
そして②で決定的なのは、図の右下に書いた「仮想GPUが3Dを持っているか」です。仮想マシンの中の Windows から見えるGPUは、本物のグラフィックボードではなくソフトウェアで作られた偽物のGPUです。この偽物が、①ホストのMetalに仕事を投げるのか、②ただの表示装置でしかないのかで、結果がまるで変わります。
用語集
今回は略語が多いので、先に並べておきます。
| 用語 | 平たく言うと | なぜそれが効くのか |
|---|---|---|
| ホスト / ゲスト | ホスト=土台側(今回はmacOS)。ゲスト=仮想マシンの中で動くOS(今回はWindows) | 「どちら側の話か」を取り違えると、原因の切り分けができなくなる |
| 仮想GPU | 仮想マシンがゲストに見せる、ソフトウェア製のグラフィックカード | これが3D命令をホストへ橋渡しするかどうかが、今回の分かれ目 |
| WDDM | Windowsのグラフィックドライバの規格。1.2、1.3のように版がある | 版が新しい=速い、ではない。後で実際に逆転する |
| 機能レベル (Feature Level) | そのGPUがDirectXのどの世代の機能まで持っているかの表記。11_0、12_1など | ★「ソフトウェアで実装した」場合も同じ表記になるので、数字だけでは速さが分からない |
| WARP | GPUが無いときにWindowsが使う、CPUだけで絵を描く仕組み | 絵は出るが桁違いに遅い。今回いちばんの落とし穴 |
| DOD (Display Only Device) | 「画面を出すだけ」で描画エンジンを持たないデバイスの種別 | これに当たると、3Dは自動的にWARP(CPU)に落ちる |
| Prism | ARM版Windowsが、x64向けのソフトを動かすための変換の仕組み | Macのx86ゲームにおけるRosettaに相当する。変換が二段になる |
| Vendor ID | デバイスの製造元を表す番号。0x15AD=VMware、0x1AF4=Red Hat、0x1414=Microsoft | ★この番号ひとつで、絵を描いているのが誰かが分かる |
| アンチチート | 不正行為を防ぐためにゲームへ組み込まれる監視の仕組み | ★仮想マシンでの実行そのものを違反として扱うことがある。後述 |
【下調べ】仮想化と互換レイヤーは、何が違うのか
言葉として似ていますが、やっていることは正反対です。
互換レイヤーは、Windowsを用意しません。ゲームが「Windowsさん、この絵を描いて」と呼びかけたら、その呼びかけをその場でmacOSの言葉に翻訳して渡します。Windowsは一枚も存在しません。だから軽いのですが、翻訳できない呼びかけが出てきた瞬間に止まります。p956でSteamが真っ黒になったのはこれでした。
仮想マシンは逆で、本物のWindowsを丸ごと動かします。ゲームから見れば、そこにあるのは正真正銘のWindowsです。翻訳できずに止まる、ということが起きません。そのかわり、Windowsのライセンスとディスク容量が要ります。
ただし、ひとつだけ嘘をつく部分があります。グラフィックカードです。Macに刺さっているのはApple製のGPUで、Windows用のドライバはありません。そこで仮想マシンソフトは「ソフトウェアで作った架空のグラフィックカード」をゲストに見せます。
この架空のカードが3Dの仕事を受け付けてホストのMetalへ橋渡しするなら、ゲームは動きます。受け付けないなら、WindowsはCPUだけで絵を描くWARPという仕組みに切り替えます。切り替わっても絵は出ます。出ますが、実用にはなりません。
だから「動いた」だけでは何も分からない
絵が出た時点で満足すると、CPUが必死に描いた絵を見て「GPUが効いている」と誤解します。p967でも同じ罠を踏みました(32bitのベンチが動いてしまい、危うくD3DMetalを通っていない数字を載せるところでした)。先に経路を確定させてから測る、が今回の進め方です。
【実験の準備・Mac】2つの無料ソフトに、同じWindowsを入れる
条件を揃えるため、2つとも同じ Windows 11 ARM(ビルド26200)を入れ、CPUとメモリの割当も揃えました。
| 項目 | VMware Fusion | UTM |
|---|---|---|
| 価格 | どちらも無料(VMware Fusionは2024年11月に個人・商用とも無償化) | |
| 土台 | VMware独自 | QEMU 9.1 |
| ゲストOS | Windows 11 Pro ARM64(10.0.26200) | |
| 割り当てCPU | 4 | |
| 割り当てメモリ | 16GB | |
| Windowsライセンス | 認証済み | 未認証のまま(動作には影響なし) |
ホストは Mac(M4)です。⚠ Windows 11 ARM を仮想マシンで使うにはWindowsのライセンスが要ります。「仮想マシンソフトが無料」なのと「無料で遊べる」のは別の話なので、ここは正直に書いておきます。
【実験1・VMware Fusion】起動する前に、ログで経路を確かめる
面白いことに、VMを起動しなくても経路の見当がつきます。VMware Fusion は設定ファイルとログに、かなりの情報を書き出しているからです。
まず設定ファイル(.vmx)です。
mks.enable3d = "TRUE" ← 3Dが有効
svga.vramSize = "268435456" ← 256MB
svga.graphicsMemoryKB = "8388608" ← 8GB
guestOS = "arm-windows11-64"
次にログ(vmware.log)。ここにホスト側が何で描いているかが書いてあります。
mks ISBRendererComm: Sandbox Renderer: MTLRenderer
mks MKSRenderMain: Found Full Renderer: ISBRenderer (MTLRenderer)
MTLRenderer ── Metalです。つまり VMware は、ゲストのDirectXの命令を受け取って、最終的にホストのMetalで描いています。ここまでは期待どおりでした。
★能力の一部が、わざわざ下げられている
同じログに、もうひとつ面白いものがありました。VMware は「レンダラの素の能力」と「ゲストに見せる値」を両方出しています。
| 能力 | レンダラ素の力 | ゲストに見せる値 | |
|---|---|---|---|
| supports3D | 1 | 1 | |
| baseCapsLevel | 11 | 9 | ★下げられた |
| maxPointSize | 511 | 189 | ★下げられた |
| sm5(Shader Model 5) | 1 | 1 | 維持 |
| gl43(OpenGL 4.3) | 1 | 1 | 維持 |
| maxTextureSize | 16384 | 16384 | 維持 |
土台の世代表記(baseCapsLevel)は 11 から 9 へ落とされているのに、DirectX側の能力(sm5)は維持されています。この時点で「DirectX 11相当までは使えそうだ」という見当が立ちました。あとはゲストの中で答え合わせをするだけです。
【承前】ゲスト側のdxdiagで答え合わせ
Windows を起動して dxdiag(DirectX 診断ツール)を実行しました。
| 項目 | 値 |
|---|---|
| Card name | VMware SVGA 3D |
| ★Device Type | ★Full Device |
| ドライバ | vm3dum64_loader.dll(ARM64版・247,752バイト) |
| ★D3D Status | ★Enabled |
| DDI Version | 11.1 |
| ★Feature Levels | ★11_0, 10_1, 10_0, 9_3, 9_2, 9_1 |
| Driver Model | WDDM 1.2 |
| Dedicated Memory | 4 MB(Shared 8,189MB) |
| DirectX 12 Ultimate | 使用不可 |
| Hardware Scheduling | AlwaysOff |
Direct3D は Enabled、デバイス種別は Full Device。ログの MTLRenderer と辻褄が合いました。WARPには落ちていません。
ついでに面白かったのが、CPUの見え方です。
プロセッサ: Apple silicon (4 CPUs), ~2.0GHz
OS : Windows 11 Pro ARM64 (10.0, ビルド 26200)
WindowsがCPUを「Apple silicon」と表示しています。仮想化なのでCPUの命令はそのまま通っていて、変換が入るのはx64のゲームを動かすときだけ(Prism)です。この1行に、仮想マシンの構造がよく出ています😊
ただし天井もはっきりしました。機能レベルは 11_0 まで、DirectX 12 Ultimate は使用不可です。DirectX 12 を必須にしているゲームは、そもそも起動しません。
【実験2・VMware Fusion】実際に3Dのゲームを動かす
能力が分かったので、実際に動かします。Steam で配信されている基本無料の3Dオンラインゲームを使いました。
結論から言うと、普通に動きました。
- ランチャーが日本語で正しく描画された。p956でWine上のSteamが真っ黒になった問題は起きない
- ゲーム本体が起動し、3Dで組まれたログイン画面が出た
- ログイン後、屋外のミッション画面まで到達。地形・植生・空・キャラクター・HUDが揃って描画され、動いていた
ここで起きていることを整理すると、なかなかの構造になっています。
互換レイヤーで2回失敗した身としては、あっさり通ってしまったのが拍子抜けするほどでした。「本物のWindowsを用意する」という力技は、確かに効きます。
【実験3・UTM】同じ手順をUTMで ── 数字は全部上だった
次にUTMです。同じ手順で Windows を起動し、同じ dxdiag を実行しました。
まず素の情報から。
| 項目 | VMware Fusion | UTM (QEMU) |
|---|---|---|
| Manufacturer / Model | VMware, Inc. / VMware20,1 | QEMU / QEMU Virtual Machine |
| ★プロセッサ名 | ★Apple silicon | ★virt-9.1 |
| MaxClockSpeed | 2000 | 1000 |
| メモリ / 論理CPU | 16GB / 4 | 16GB / 4 |
同じApple Siliconの上で動いているのに、ゲストに見えるCPU名が違います。VMwareは実物の名前をそのまま見せ、QEMUは「virt-9.1」という一般名を見せています。
そしてディスプレイの情報です。ここで予想が外れました。
| 項目 | VMware Fusion | UTM (QEMU) |
|---|---|---|
| Card name | VMware SVGA 3D | Red Hat VirtIO GPU DOD controller |
| DDI Version | 11.1 | 12 |
| ★Feature Levels | 11_0 まで | 12_1 まで |
| Driver Model | WDDM 1.2 | WDDM 1.3 |
| D3D Status | Enabled | Enabled |
UTMのほうが、数字が全部上です。DirectXの世代(DDI 12 > 11.1)も、機能レベル(12_1 > 11_0)も、ドライバの規格(WDDM 1.3 > 1.2)も。D3D Status もどちらも Enabled です。
カタログだけ並べたら、UTMのほうが高性能に見えます。
【承前・切り分け】Vendor ID 0x1414 が意味すること
ところが、同じ画面の別の行を見ると話が反転します。
| 項目 | VMware Fusion | UTM (QEMU) |
|---|---|---|
| ★Device Type | Full Device | Display-Only Device |
| PCI上のデバイス | VEN_15AD&DEV_0406(VMware) | VEN_1AF4&DEV_1050(Red Hat) |
| ★Vendor ID / Device ID | 0x15AD / 0x0406 | 0x1414 / 0x008C |
| Dedicated Memory | 4 MB | 0 MB |
| ドライバ | vm3dum64_loader.dll | viogpudo.sys |
2つ、決定的なものがあります。
①UTMのデバイス種別は Display-Only Device です。DOD=画面を出すだけで、描画エンジンを持っていません。ドライバ名の viogpudo.sys の末尾も do=Display Only です。
②UTM側の Vendor ID が 0x1414 です。PCIバス上にいるデバイスは Red Hat(VEN_1AF4)なのに、DirectXが報告する製造元は0x1414 ── Microsoftの番号です。
これが答えでした。UTMでは、Direct3Dの相手が仮想GPUではなく、WindowsのWARP(CPUで絵を描く仕組み)になっています。
機能レベル 12_1 は、速いからではなく「ソフトで実装しているから」
WARPはCPUでDirectXを実装したものなので、その気になれば新しい世代の機能まで名乗れます。だからUTM側は 12_1 まで出るし、末尾に 1_0_CORE という描画を伴わない項目まで並びます。
一方VMwareの 11_0 は、Metalに繋がった本物の経路の天井です。数字が小さいほうが、実際には絵を描いています。
【ここから整理】2つを1枚の表にする
| VMware Fusion | UTM (QEMU) | |
|---|---|---|
| 価格 | どちらも無料(Windowsのライセンスは別途必要) | |
| ゲストから見たCPU | Apple silicon | virt-9.1 |
| 仮想GPU | VMware SVGA 3D | Red Hat VirtIO GPU DOD |
| デバイス種別 | Full Device | Display-Only Device |
| 3Dを描くのは | ホストのGPU(Metal) | CPU(WARP) |
| DirectXの天井 | 機能レベル 11_0 | 12_1(ただしソフトウェア) |
| DirectX 12 のゲーム | 動かない(Ultimateは使用不可) | 実用にならない |
| 3Dゲーム | 動いた | 実用外 |
| 向いている用途 | Windowsアプリ全般+DX11世代までのゲーム | 画面が出れば良い作業(開発・検証・事務) |
ひとことでまとめると、「無料の仮想マシンでWindowsのゲームを遊びたいなら、選択肢はVMware Fusionの一択」です。UTMが劣っているという話ではなく、UTMの仮想GPUはそもそも3Dを担当していないので、目的が違います。
【整理】見落としやすい、もうひとつの壁
ここまでは「技術的に動くか」の話でした。ところがもう1枚、壁があります。
⚠ アンチチートです。
対戦要素のあるオンラインゲームの多くは、Easy Anti-Cheat や BattlEye といった監視の仕組みを組み込んでいます。これらは改造ツールを見つけるだけでなく、「仮想マシンの中で動いていること」自体を検出します。そして多くのタイトルでは、仮想環境での実行が利用規約の違反として扱われます。
「動くこと」と「動かしてよいこと」は別
仮想マシンの中でもゲームは普通に起動しますし、遊べてしまいます。検出されるのはその後です。結果として、アカウントが停止されることがあります。不正行為をしていなくても、です。
遊びたいタイトルがある場合は、遊ぶ前にそのゲームの利用規約と、アンチチートが入っているかどうかを確認してください。Steamの製品ページには、導入されているアンチチートが記載されています。
この記事の検証では、以下のように区別しています。
- 技術的に3Dが効いているかの確認は、ゲームを使わずに
dxdiagとログだけで完結します。アカウントを一切危険に晒しません - 実際にゲームを動かす確認は、アンチチートの有無と規約を先に調べてから行うべきです
正直に言うと、eightはこの順序を軽く見ていました。「無料で遊べるかどうか」ばかり調べて、「動かしてよいかどうか」を調べていなかったのです。仮想マシンでゲームを試そうとしている方は、ここだけは先に確認してください🙏
【整理】結局、仮想マシンはMacゲームの答えになるのか
技術的な答えと、実用上の答えが違う回になりました。
技術的には「答えになる」と言えます。互換レイヤーで2回つまずいた「ゲーム画面に辿り着けない」問題は、仮想マシンでは起きませんでした。本物のWindowsなので、翻訳できずに止まる箇所がありません。
実用上は、条件がかなり付きます。
- Windowsのライセンスが要る。仮想マシンソフトが無料でも、ここは無料になりません
- ディスクを100GB前後持っていかれる(Windows本体+ゲーム)
- DirectX 12 のゲームは動かない。天井は11_0(DX11世代まで)
- ⚠アンチチート入りのオンラインゲームは、規約上そもそも動かしてはいけないことが多い
この4つを並べると、「アンチチートの無い、DirectX 11世代までのシングルプレイのゲームを、Windowsのライセンスを持っている人が遊ぶ」という、かなり絞られた条件になります。
★そして、条件を満たしても「やってみないと分からない」
ここまで環境の側の話をしてきましたが、最後に正直に書いておきたいことがあります。
ここまでの条件を全部満たしていても、そのゲームが動くかどうかは、結局のところ動かしてみるまで分かりません。
今回1本が最後まで動いたことは、「仮想マシンならゲームが動く」の証明にはなっていません。証明できたのは「VMware Fusionの仮想GPUは、DirectXの命令を本当にホストのGPUへ渡している」という、その1点だけです。そこから先は、タイトルごとの話になります。
実際に起きることは、ざっくり3つに分かれます。
| 結果 | どういう状態か | よくある原因 |
|---|---|---|
| 普通に遊べる | 起動して、最後まで動く | 使っている機能が、仮想GPUの持っている範囲に収まっている |
| ★特定のタイミングで落ちる | 起動はする。特定の場面・特定の演出・一定時間後などで急に落ちる | そこで初めて呼ばれる機能が、仮想GPU側に無い/実装が違う。いちばん厄介 |
| そもそも起動しない | 起動直後に落ちる、エラーが出る、画面が出ない | DirectX 12 必須、必要な機能レベルに届かない、アンチチートに弾かれる |
厄介なのは真ん中です。1時間遊べたので大丈夫だと思っていたら、特定のステージに入った瞬間に落ちる。あるいは特定のエフェクトが出る場面だけ落ちる。「動いた」と判断した後から出てくるので、事前に見抜けません。
仮想GPUは、本物のグラフィックカードの機能を全部そろえているわけではありません。よく使われる機能から順に実装されていて、端のほうは抜けていたり、本物と挙動が違ったりします。そして、ゲームがその端の機能をいつ呼ぶかは、遊んでみないと分からないわけです。
結論:この記事で分かるのは「土俵に上がれるか」まで
dxdiag で分かるのは、3Dが効いているか・DirectXの天井がどこかまでです。ここが駄目ならどのゲームも駄目だと言い切れます(UTMがそれです)。
でも、ここが大丈夫だったからといって、個々のゲームが動く保証にはなりません。遊びたいタイトルがあるなら、返金できるうちに実際に試すのがいちばん確実です。
互換レイヤー(GPTK)が「入口は狭いが、通れれば速い」だとすると、仮想マシンは「入口は広いが、通ったあとに別の門がいくつもある」という感じでした。
つまずき集
今回は測定より、仮想マシンの中を操作すること自体でつまずきました。同じことをする方の参考になればと思います。
- ★ゲストの中へまとめて文字を送ると、1文字が連打される。
dxdiagと打ったつもりがaaaa…が60文字入り、ブラウザで検索が走りました。1文字ずつ送るか、クリップボード経由で貼るのが確実です - ★クリップボードは片方向だった。ホスト→ゲストは通るのに、ゲスト→ホストは返ってきません(
Set-Clipboardの結果がMac側に現れない)。結果の取り出しには使えません - ★結果の持ち出しはHTTPが確実。Mac側で受信用の小さなサーバーを立て、ゲストのPowerShellから
Invoke-RestMethod -Method Putで投げる形にしました。共有フォルダもゲスト側ツールも要りませんpowershell -NoProfile -ExecutionPolicy Bypass -Command "iwr http://<MacのIP>:8765/go.ps1 -OutFile $env:TEMP\go.ps1 -UseBasicParsing; & $env:TEMP\go.ps1" - ⚠ゲストから見たMacのアドレスが、ソフトによって違う。VMware Fusion は NAT が
vmnet8で 172.16.229.1、UTM は 192.168.64.1 でした。スクリプト側に候補を並べて順に試すのが楽です - ★
dxdiagは二重起動すると何も書かない。1回目の出力が0バイトで、原因がこれでした。先にGet-Process dxdiag | Stop-Process -Forceしてから起動します - ★
.ps1に日本語を書くと文字化けする。Windows PowerShell 5.1 は.ps1をANSIとして読むため、スクリプト内のラベルが蜿門セ玲律譎・になりました。スクリプトはASCIIだけで書きます(p977で.batに同じ罠を踏んでいます) - ⚠
dxdiagの出力はCP932。Mac側で読むときに指定が要ります - ★遅延スクリーンショットがPowerShellの窓を撮ってしまう。
powershell -WindowStyle Hiddenで窓を出さないのが正解でした - ⚠Windows 11 の仮想マシンは暗号化される(TPMのため)。そのため
vmrunのようなコマンドから起動しようとするとパスワードを求められます。GUIから起動すればキーチェーン任せで済みます
まとめ
無料の仮想マシンソフト2つに Windows 11 ARM を入れ、3Dが本当に効いているかを確かめました。
- ★VMware Fusion は3Dが本当に効いていた。ホスト側のログに
MTLRenderer、ゲスト側のdxdiagにFull DeviceとD3D Status: Enabled。実際に3Dのゲームが動いた- 翻訳が2段(x64→ARMのPrism、DirectX→SVGA3D→Metal)入っているのに絵が出る
- ★WindowsがCPUを「Apple silicon」と表示する。仮想化なので命令はそのまま通っている
- ★天井は機能レベル 11_0。DirectX 12 Ultimate は使用不可
- ★★UTMは、カタログの数字が全部VMwareより上なのに、GPUが一切描いていなかった
- DDI 12 > 11.1、機能レベル 12_1 > 11_0、WDDM 1.3 > 1.2。D3D Status もどちらも Enabled
- ★決め手は2つ。デバイス種別が
Display-Only Deviceであることと、Vendor ID が0x1414(Microsoft) だったこと - → Direct3Dの相手はWARP(CPUで描く仕組み)。機能レベル 12_1 は「ソフトで実装しているから名乗れる」だけ
- ★★数字が小さいほうが、実際には絵を描いている
- ⚠技術的に動くことと、動かしてよいことは別。アンチチート入りのオンラインゲームは、仮想マシンでの実行そのものが規約違反として扱われることがある。遊ぶ前に確認する
- 実用上の条件は「アンチチート無し」「DX11世代まで」「Windowsのライセンスあり」「ディスク100GB」。かなり絞られる
- ★★そして条件を満たしても、動くかどうかは結局やってみるまで分からない
- 結果は3つに分かれる。普通に遊べる/★特定のタイミングで落ちる/そもそも起動しない
- いちばん厄介なのは真ん中。「動いた」と判断した後から出てくるので事前に見抜けない
- 仮想GPUは本物の機能を全部そろえてはいない。端のほうは抜けていたり挙動が違ったりする
- →
dxdiagで分かるのは「土俵に上がれるか」まで。個々のゲームが動く保証にはならない
今回いちばん怖いと思ったのは、UTM側の数字がどれも立派だったことです。DDIも機能レベルもWDDMも、VMwareより新しい世代を名乗っていました。あの表だけを見せられたら、「UTMのほうが高性能ですね」と答えていたはずです😳
実際には Display-Only Device の一行と、0x1414 という5文字が全部をひっくり返していました。p967で「動いた≠意図した経路で動いた」を学んだつもりでいましたが、今回はその逆向き ── 数字が良く見えるほうが実は動いていないという形で出てきました。カタログの数字は、それが誰によって実装されているかとセットで見ないと意味がないのだと思います。
使ったのは無料のソフト2つと、dxdiag という Windows 標準のツールだけです。ゲームを起動しなくても3Dが効いているかどうかはここまで分かるので、手元の仮想マシンでも同じ表が作れると思います😊
それでは、今回はここまで。最後までありがとうございました😊