ここ数本、MacでWindowsのゲームを動かす話ばかり書いてきました。5つの手段を並べた回でも移行ガイドの回でも、結論はいつも「互換レイヤーは入口で止まる」でした。
ならば、そもそも翻訳を挟まずに済むMac版はどうなのか。今回はそこを確かめます。手を動かしてみたら、想像していたのとまったく違うところでつまずきました😳
・手元のライブラリのMac対応率：13本中3本でした
・★ネイティブかRosettaかを見分ける2つの手順（コマンド2つ・コピペで使えます）
・★eightの数え間違い：`arm64e` を見落として結果が55%も狂った話
・★★同じゲームが、Steam経由だとRosettaで動いた——直接起動するとネイティブ
・その代償：同じ画面を出すのにCPU時間が1.44倍
互換レイヤーの話が3本続いたので、ネイティブを見に行く
この記事は実測回です。検証に使ったのは、Steamで配られている無料かつオープンソースのMac対応タイトルを2本。
| タイトル | ライセンス | 導入後の容量 |
|---|---|---|
| Endless Sky | GPL 3.0 | 419MB（ダウンロード404.53MB・約25秒） |
| Battle for Wesnoth | GPL 2.0 | 665MB（ダウンロード610.56MB） |
オープンソースを選んだのは、権利関係を気にせず中身を調べて書けるからです。当ブログは以前の回から「検証は無料のものだけ」という方針でやっています。
OpenTTDも入れるつもりでしたが、「ライセンスがありません」で失敗しました。調べてみると、これは単なる追加忘れではありませんでした。
OpenTTDはオープンソースで、他のストアや公式サイトでは無料で配られています。ところが日本のSteamストアでは、単体で取得する選択肢が出てきません（公開APIで見ても購入・取得の選択肢が空でした）。ページに並んでいるのは別ソフトとの抱き合わせで¥1,200のバンドルだけです。
★「オープンソースだから無料で手に入る」とは限らない——同じソフトでも、どのストアから取るかで話が変わります。今回は有料のものは扱わない方針なので、ここで打ち切りました。
用語集
| 用語 | 平たく言うと |
|---|---|
| ネイティブ | そのCPU向けに直接作られていること。Apple SiliconのMacならarm64向け。翻訳が挟まらないので速い |
| Rosetta 2 | Intel向け（x86_64）のプログラムを、Apple SiliconのMacで動かすための変換の仕組み。動くけれど、そのぶん余計な仕事が増えます |
| ユニバーサルバイナリ | 1つのファイルの中にIntel向けとApple Silicon向けの両方を入れたもの。Macが状況に応じてどちらかを選んで動かします |
| arm64e | arm64の強化版で、ポインタ認証という安全機構が入ったもの。★これも立派なApple Siliconネイティブです（この記事で一度つまずきます） |
| lipo | Macに最初から入っているコマンド。そのファイルが何向けのコードを持っているかを一覧できます |
| vmmap | 同じくMac標準のコマンド。今まさに動いているプログラムが、どちらで動いているかを教えてくれます |
手元のライブラリで、Mac版があったのは13本中3本
まず身も蓋もない現実から。eightのSteamライブラリにあるゲームについて、Mac版が存在するかどうかを数えました。
| 手元のライブラリ | 本数 |
|---|---|
| Mac版がある | 3本（23%） |
| Mac版がない | 10本（77%） |
| 合計 | 13本 |
4本に1本もありません。以前調べたとき、Steam全体でmacOSの利用シェアが2.21%（Linuxの3.69%より下）という数字が出ていました。手元の実感もそれと矛盾しない結果です。
ただ、これは「eightがWindows向けのゲームばかり買ってきた」という話でもあります。最初からMacで遊ぶつもりで選べば、話は変わります。実際、無料のオープンソースゲームだけでもMac対応はたくさんありました。
見分け方①：バイナリが何を持っているか
ここからが本題です。Mac版があったとして、それがApple Silicon向けに作られているのか、Intel向けのものをRosettaで動かしているのかは、見た目では分かりません。
調べるコマンドは1行です。
lipo -archs "/Applications/○○.app/Contents/MacOS/○○"返ってくる文字列で、こう読みます。
| 出力 | 意味 |
|---|---|
x86_64 arm64 | ユニバーサル。両方入っている |
x86_64 arm64e | ユニバーサル。★arm64e もネイティブです |
arm64 | Apple Silicon専用。Intel Macでは動きません |
x86_64 | ★Intel専用。Rosettaでしか動きません |
今回入れた2本を調べると、どちらもユニバーサルでした。
$ lipo -archs "Endless Sky.app/Contents/MacOS/Endless Sky"
x86_64 arm64
$ lipo -archs "The Battle for Wesnoth.app/Contents/MacOS/The Battle for Wesnoth"
x86_64 arm64ここまでは順調です。「両方持っているならApple Siliconで動くだろう」と、このときは思っていました。
★eightの数え間違い——arm64eを見落とした
せっかくなので、Mac全体でどれくらいネイティブ化が進んでいるのかも数えてみました。/Applications と /System/Applications にある全アプリを lipo にかけるスクリプトを書いたところ、こんな結果が出ました。
87本中48本（55%）がIntel専用。しかもその中にSafari・メール・計算機・システム設定まで入っていました。
さすがにおかしい、と手が止まりました。macOS標準のアプリがIntel専用なわけがありません。個別に確かめると、原因はすぐ分かりました。
$ lipo -archs /System/Applications/Calculator.app/Contents/MacOS/Calculator
x86_64 arm64e ← 「arm64」ではなく「arm64e」eightのスクリプトが arm64e を「arm64ではない」と判定していたのでした。arm64e はポインタ認証という安全機構が付いた強化版で、れっきとしたApple Siliconネイティブです。macOSのシステムアプリはほぼ全部これでした。
判定を直したら、結果がひっくり返りました。
| 分類 | 本数 | 割合 |
|---|---|---|
| ユニバーサル | 76本 | 87.4% |
| Apple Siliconのみ | 9本 | 10.3% |
| ★Intel専用 | 2本 | 2.3% |
55%が2.3%になりました😅 残ったIntel専用の2本は、古い画像変換ツールと、Microsoftが開発を終了したMac版の統合開発環境でした。
Macのアプリ側の移行は、もうほぼ終わっています。この前提が、次の節の驚きにつながります。
見分け方②：実際にどちらで動いているか
lipo が教えてくれるのは「何を持っているか」であって、「実際にどちらで動いているか」ではありません。ここが今回いちばん大事なところでした。
動いているプログラムを調べるには、こうします。
# プロセスIDを調べて、その中身を見る
$ vmmap <プロセスID> | grep "Code Type:"
Code Type: ARM64 ← ネイティブで動いている
Code Type: X86-64 (translated) ← ★Rosettaで翻訳されているコマンドが苦手な方は、アクティビティモニタでも同じことが分かります。「CPU」タブの列に「種類」を出すと、Apple か Intel かが表示されます。
★★同じゲームが、Steam経由だとRosettaで動いた
では実際に、Endless Skyを起動して確かめます。Steamのライブラリから「プレイ」を押しました。
Process: Endless Sky [37529]
Identifier: io.github.endless-sky
Version: 0.11.2 (1)
Code Type: X86-64 (translated) ← ★Rosetta！
Parent Process: steam_osx [35448]ユニバーサルバイナリを持っているのに、Rosettaで動いていました。
不思議なのは、親であるSteam本体のほうです。同じように調べると、こうでした。
Process: steam_osx [35448]
Identifier: com.valvesoftware.steam
Code Type: ARM64 ← Steam自身はネイティブSteamはネイティブで動いているのに、そこから起動したゲームだけが翻訳されている。ここでようやく、比較すべきことが見えました。同じゲームを、Steamを通さずに直接起動してみます。
結果はこうなりました。
| タイトル | Steamから起動 | .appを直接ひらく |
|---|---|---|
| Endless Sky | X86-64 (translated) | ARM64 |
| Battle for Wesnoth | X86-64 (translated) | ARM64 |
最初の比較で、Steam経由なのに ARM64 と表示された回がありました。直接起動した実体がまだ残っている状態でSteamの「プレイ」を押すと、macOSがすでに動いているほうに引き渡してしまうためでした。
きちんと終了させてから測り直したところ、3回とも translatedで再現しました。1回の結果で決めなくてよかったです😅
その代償はCPU時間1.44倍だった
「動いているのだから、別にいいのでは」と思うかもしれません。eightもそう思ったので、測りました。
やり方は単純です。ゲームを起動してタイトル画面のまま40秒放置し、その間に消費したCPU時間を比べます。同じ絵を出しているだけなので、条件は揃っています。
3回とも1.4倍台で揃いました。今回のような軽い2Dのゲームでは、遊んでいて違いを感じることはありません。ただ同じ絵を出すのに1.4倍の仕事をしているのは確かで、ノート型なら発熱やバッテリーに効いてきますし、重いゲームであれば話は変わってきます。
場所は
~/Library/Application Support/Steam/steamapps/common/<ゲーム名>/ です。ここにある .app をFinderからひらけば ARM64 で起動します。⚠ ただしSteamの実績・プレイ時間の記録・オーバーレイは効かなくなる可能性があります。今回の2本はSteamの機能を使っていないので実害はありませんでしたが、そうでないゲームでどうなるかは確かめていません。
原因について、分かったことと分からなかったこと
ここは正直に、切り分けたところまでを書きます。
| 疑ったこと | 確かめた結果 |
|---|---|
| ゲームがIntel専用のライブラリを使っている？ | 違う。リンクしているのはSDL2・libpng・OpenAL等だけで、Steamのライブラリは1つも使っていません |
| Steamのオーバーレイが原因？ | 違う。gameoverlayrenderer.dylib はユニバーサルでした |
| Steam本体がIntel向けだから引きずられる？ | 違う。steam_osx はARM64で動いています |
| Steamの中に古い部品が残っている？ | 一部そう。61件中6件がIntel専用のまま（i386のものも2件）。ただしこれが直接の原因かは断定できません |
状況からは、Steamがゲームを起動するときに、意図的にIntel向けの動き方を選んでいるように見えます。Mac版のゲームには古いものも多く、確実に動く側に倒しているのだとすれば理解できる判断です。
ただしそれを裏づける証拠は取れていません。分かったのは「そうなる」という事実と、「.appを直接ひらけば回避できる」という対処までです。
まとめ
- 手元のライブラリでMac版があったのは13本中3本（23%）。ただしこれは買い方の問題でもあり、最初からMacで遊ぶつもりで選べば選択肢はあります
- 見分け方は2段階。
lipo -archsで「何を持っているか」、vmmap | grep "Code Type:"で「どちらで動いているか」。アクティビティモニタの「種類」列でも同じことが分かります - ★
arm64eもApple Siliconネイティブです。eightはここを見落として、Safariや計算機まで「Intel専用」に数えてしまいました（55% → 実際は2.3%） - 手元の87本のうちIntel専用は2本だけ。Macのアプリ側の移行はほぼ終わっています
- ★★同じゲームが、Steam経由だとRosettaで動き、.appを直接ひらくとネイティブで動きました。2タイトルとも同じ挙動で、3回とも再現しています
- Steam本体（
steam_osx）はARM64で動いているのに、そこから起動したゲームだけが翻訳される、というのが奇妙なところです - ★代償はCPU時間1.44倍（8.78秒 対 6.08秒・3回平均）。軽いゲームでは体感できませんが、確実に余計な仕事をしています
- 対処は.appを直接ひらくこと。ただしSteamの実績やプレイ時間の記録は効かなくなる可能性があります
- 原因は断定できていません。ゲーム側の依存でもオーバーレイでもSteam本体でもないことまでは切り分けました
今回いちばん面白かったのは、「ネイティブ対応しているか」と「ネイティブで動いているか」が別問題だったことです。前回はWhiskyの中身がIntel向けで、入れ物だけがネイティブという話を書きました。今回はその逆で、中身はちゃんとネイティブなのに、動かし方のせいで翻訳されていたわけです。
そして自分の数え間違いで55%という数字を一度出してしまったのも、正直に書いておくべきところだと思いました。lipo は文字列を返すだけなので、読む側が意味を知らないと簡単に間違えます。測るのは簡単でも、正しく読むのは別の技術なのだと改めて思いました😊
それでは、今回はここまで。最後までありがとうございました😊
【実測環境】Apple M4 / メモリ32GB / macOS 26.5.2 (25F84)、2026年8月2日の作業記録です。検証に使ったのはSteamで配布されている無料かつオープンソースの2タイトル（Endless Sky 0.11.2 / GPL 3.0、The Battle for Wesnoth / GPL 2.0）で、いずれも公式のSteam版をそのまま導入しています。アーキテクチャの判定は lipo -archs、実行時の判定は vmmap の Code Type 行によります。CPU時間はタイトル画面で40秒放置し、ps -o time= の差分を3回測って平均しました（Steam経由 9.16／8.91／8.26秒、直接起動 6.14／6.25／5.86秒）。アプリの集計対象は /Applications と /System/Applications にある87本で、実行ファイルを取得できなかったものは除いています。ライブラリの本数はSteamの公開APIでMac対応の有無を照会した集計値で、★個々のタイトル名・アカウント名・ライブラリ画面は掲載していません（ゲームの環境変数にはアカウント名とセッショントークンが出力されるため、記録からも除外しています）。3本目に予定していたOpenTTDは、ライセンスがアカウントに無く導入していません。原因の特定には至っておらず、本文中の「Steamが意図的にIntel向けを選んでいる」は推測であって検証できていません。