Rosetta 2 が終わる前にやっておくこと〜Macのゲームと開発環境は、いつ何が動かなくなるのか〜

MacでSteamのゲームを遊んでいる人も、Unityや古いJavaで開発している人も、どこかでRosetta 2のお世話になっています。そのRosetta 2が、ついに終わりに向かって動き出しました😳

先に結論を書きます。いま（2026年9月）はまだ全部動きます。Appleのサポート記事では、Rosettaがふつうに使えるのはmacOS 27までで、macOS 28（2027年秋の見込み）からは「更新の止まった古いゲーム」向けだけに絞られます。ただしApple自身のページ同士で書いてあることが食い違っていて、どれを信じるかで猶予が1年変わります。

そこで今回は、「いつ止まるか」を一次情報で確かめたうえで、自分のMacでRosettaに頼っているものを全部洗い出し、何から手を付ければいいかを優先度つきでまとめました。数えてみたら、見かけの数字と本当に困る数がまるで違いました。

この記事は下調べが2つ、実験が3つあります。

先に実測した環境を書いておきます。★この記事の数字はこのMacに入っているものを数えた結果です。

用語集

【下調べ】いつ何が止まるのか ── Appleのページ同士が食い違っていた

まず一次情報です。Appleが出している3つのページを読み比べました。

上の2つは同じことを言っています。27までは全面的に使えて、28からはゲームだけです。問題は3つ目で、ここだけ「Rosettaは26まで」と読めます。Intel Mac の対応終了（これは26で正しい）とRosettaを1文にまとめてしまった書き方に見えますが、Appleは訂正を出していません。

もうひとつ、「ゲーム向けだけ残す」の中身はまだ公表されていません。どのゲームが対象なのか、判定は誰がどうするのか、そしてWineのような互換レイヤーが「ゲーム」として扱われるのか。ここは現時点で分からないことです。推測では書かず、分からないものとして扱います。

【下調べ・続き】Rosettaは「プロセス単位」で翻訳している

洗い出しの前に、何が止まって何が止まらないのかを決めておく必要があります。これを取り違えると、数える意味がなくなるからです。そこで、同じ小さなプログラムを3通りに作って確かめました。

#include <stdio.h>
#include <sys/sysctl.h>
/* 自分がRosettaで翻訳されて動いているかを自己申告する */
int main(void) {
    int t = 0; size_t n = sizeof t;
    sysctlbyname("sysctl.proc_translated", &t, &n, NULL, 0);
    printf("proc_translated=%d\n", t);
    return 0;
}

clang -arch x86_64            hello.c -o hello_x86_64
clang -arch arm64             hello.c -o hello_arm64
clang -arch x86_64 -arch arm64 hello.c -o hello_universal

★ポイントは arch -arm64 です。これを付けると「arm64 で起動しろ」と強制できるので、Rosettaを消さずに「Rosettaが無い状態」を再現できます。

Rosettaが無くなったときに出るエラーは、この Bad CPU type in executable です。見覚えがあったら、それが原因です。

次に、ライブラリを確かめました。x86_64 だけのライブラリを作り、同じプログラムからネイティブとRosettaの両方で読み込みます。

[ネイティブ] 読み込めない: ... mach-o file, but is an incompatible architecture
             (have 'x86_64', need 'arm64e' or 'arm64e.v1' or 'arm64' or 'arm64')
[翻訳中]     読み込めた answer()=42

もうひとつ分かったことがあります。ユニバーサルでも arch -x86_64 で起動すると、翻訳中（1）になりました。Mac版Steamの回で、ネイティブ対応のゲームなのにSteamから起動するとRosettaで動いてしまったのは、起動する側がx86_64を指定していると考えると辻褄が合います（Steamの中身までは確かめていません）。

【実験1】自分のMacでRosettaを通っているものを探す ── いま動いているものを見ても分からない

まず、いちばん手軽な方法から試しました。いま動いているプロセスを全部見て、翻訳中のものを数えます。アクティビティモニタの「種類」列と同じことを、コマンドでやっています。

vmmap <PID> | grep "Code Type"
#   ARM64               → ネイティブ
#   X86-64 (translated) → Rosettaで翻訳中

翻訳中は0件です。これだけ見ると「このMacはRosettaを使っていない」と言えそうですが、⚠違います。RosettaはIntel専用のものを起動したときにだけ現れるので、いま動いていないものは見えません。

次に、macOS自身の一覧を見ました。「このMacについて」→「詳細情報」→「システムレポート」→「アプリケーション」の「種類」列です。コマンドなら次の1行で出ます。

system_profiler SPApplicationsDataType -json
#   arch_kind: arch_arm_i64 → ユニバーサル
#              arch_arm     → Apple silicon だけ
#              arch_i64     → Intel だけ  ★ここが止まる

Intelだけの11本は、Visual Studio（for Mac）とその更新ツール、App Storeで入れた画像ツール、Porting KitのWineskin、Unreal Engine 5.7に付いてくる補助アプリ2つ、古いUE4の連携サービス、そしてUnityの UnityPlayer.app 4つでした。

⚠この Unity の4つは、よく見るとこのMacで動かすものではありません。macos_x64_player_... という名前のとおり、Intel Mac 向けにゲームを書き出すときの型紙で、隣には arm64 版とユニバーサル版の型紙も並んでいます。一覧の「Intelだけ」には、こういう使わないものも混ざります。

476本中11本なら大したことはない、と言いたいところですが、⚠この一覧は .app しか数えていません。コマンドやライブラリ、開発ツールの中身は出てこないので、本当に困るものがここから漏れていました。

【続き】.app以外まで数える ── 数字をそのまま読むと間違える

そこで、ファイルの先頭にある Mach-O ヘッダを直接読むスクリプトを書いて、開発ツールやゲームの置き場所を丸ごと数えました。lipo を1ファイルずつ呼ぶと遅すぎるので、先頭の数バイトだけを自分で読んでいます。

def cpus(path):
    with open(path, "rb") as f:
        head = f.read(8)
        magic_be = struct.unpack(">I", head[:4])[0]
        if magic_be in (0xCAFEBABE, 0xCAFEBABF):          # ユニバーサル
            n = struct.unpack(">I", head[4:8])[0]
            if not 1 <= n <= 8:                            # ⚠Javaの.classも同じ4バイト
                return None
            ...                                            # 各アーキのCPU番号を集める
        magic_le = struct.unpack("<I", head[:4])[0]
        if magic_le in (0xFEEDFACF, 0xFEEDFACE):           # 1アーキだけ
            return {struct.unpack("<i", head[4:8])[0] & 0xFFFFFFFF}
# arm64(0x0100000C) を含む → Rosettaが無くても動く
# x86_64(0x01000007) だけ → Rosettaが無いと動かない

⚠つまずきがひとつありました。ユニバーサルの目印 0xCAFEBABE は、Javaの .class ファイルと同じ4バイトです。そのままだと Java の部品を大量に Mach-O と誤認するので、「中のアーキ数が1〜8で、CPU番号が知っているもの」だけを数えるようにしました。

結果です。

Unreal Engine の 3,006個が目を引きます。これが全部止まるなら大ごとです。ただ、前の章で決めたとおり、本当に困るのは実行ファイルだけです。そこで、見つけたIntel専用のファイルを種類ごとに分けて数え直しました。種類もMach-Oヘッダの中に書いてあります。

3,006個のうち2,872個はオブジェクトファイルでした。組み立て前の部品で、実行されることはありません。本当に困る候補は49個、全体の1.6%です。Homebrew の7個も、Homebrew自身のテスト用の見本ファイルでした。

★「Intel専用のファイルの数」を数えると、困り具合を60倍に見積もってしまいます。数えるべきは「Intel専用の実行ファイル」で、しかも「同じ場所にarm64版が置いてないもの」です。

【続き・切り分け】本当に困るものは何だったのか

残った実行ファイルを1つずつ見ていくと、傾向がはっきりしました。本体はネイティブなのに、付属の道具だけIntel専用というものが多いのです。

【実験2・Unity 6.6】ライトの焼き込みで、本当にRosettaは動くのか

「中に入っている」と「実際に動く」は別です。そこで Unity で実際に焼き込みを走らせました。検証の途中で Unity が 6000.4.5f1 から 6000.6.0f1 に更新されたので、まず2つのバージョンの中身を比べておきます。

★Unity はいままさに移行の途中で、2つのバージョンの間にIntel専用の実行ファイルが3分の1に減っています。それでも、焼き込みの2つはまだ残っていました。

検証用に空のプロジェクトを作り、光源1つと箱・床だけのシーンをエディタのスクリプトで自動的に焼き込んで閉じるようにしました。その間に起動したプロセスを記録し、あわせてmacOSのログでRosettaの動きを見ます。

var s = new LightingSettings { lightmapper = LightingSettings.Lightmapper.ProgressiveCPU,
                               lightmapResolution = 10 };
Lightmapping.lightingSettings = s;
Lightmapping.bakeCompleted += OnDone;     // 終わったら次の方式へ、全部終わったら Exit
Lightmapping.BakeAsync();

⚠画面なしのバッチモード（-batchmode）は、Unity Personal では起動しませんでした（'com.unity.editor.headless' was not found）。画面ありで -executeMethod を使っています。

焼き込みの方式を3つ試した結果です。

Unity 自身のログにも、はっきり出ていました。

Launching external process: .../Unity.app/Contents/Helpers/JobProcess
[BakePipeline::BakeStage] Background thread started. Calling LightBaker.
Launching external process: .../Unity.app/Contents/Helpers/LightBaker
[BakePipeline::BakeStage] LightBaker bake took 6574.09ms and succeeded.

そして macOS のログでは、LightBaker が起動した直後に、Rosetta の翻訳係 oahd-helper が次の番号で起動していました（LightBaker 65847 → oahd-helper 65848）。Intel専用のものが、Rosettaを通って動いた証拠です。

ただし、2つ注意があります。

• ⚠新しい方式でも JobProcess（x86_64）は起動しました。焼き込みの下準備で使われていて、ここはまだ Rosetta 頼みです
• ⚠新しい方式は com.unity.render-pipelines.core パッケージが必要です。入っていない空のプロジェクトでは Light baking failed with error code 9. で失敗しました

Unity 6.6 は、スクリプトで Progressive CPU を指定すると「非推奨なので Unity Compute GPU を使え」という警告を出します。移行先はもう用意されている、ということです。

初回だけ5分半待たされた

もうひとつ、はっきり差が出たところがあります。同じ焼き込みを2回やると、1回目だけ極端に遅かったのです。

2回目は、Intel専用の道具が同じように起動しているのに（記録は7回）、翻訳係は1回も起動していません。Rosettaは一度翻訳した結果を保存しておき、次からはそれを使います。1回目の待ちがすべて翻訳のせいとは言い切れません（プロジェクトを初めて開いたときの準備も重なっています）が、「Intel専用の道具は、最初の1回がとても遅いことがある」のは確かです。

⚠記録でひとつ、つまずきました。起動した瞬間のプロセスを vmmap で見ると、LightBaker が「ARM64」と出たのです。自作の x86_64 のプログラムで確かめると、起動した瞬間は ARM64、0.02秒後には X86-64 (translated) でした。Rosettaが翻訳を始める前の一瞬を見ていたわけです。起動直後の見た目は信じないほうがいいです。

【実験3】macOS 26.6 の警告は、本当に出るのか

Appleは「macOS 26.4以降、Rosettaに頼るアプリを起動すると通知が出ることがある」と書いています。「ことがある」なので、実際に試しました。

ふつうに配布されているアプリでは、通知は出ました。つまり、ここ最近「このアプリは今後動かなくなります」という通知を見た覚えがあれば、それが自分のMacのRosetta依存の一覧です😅

★もうひとつ、ログを見ていて気づいたことがあります。どちらの場合も、起動した瞬間に ecosystemanalyticsd: Performing rosetta analysis という行が出ていました。macOSは、Rosettaで動いたアプリを記録しています。Appleが「影響するアプリの数」を把握できているのは、こういう仕組みがあるからでしょう。

【ゲーム側】Steam と互換レイヤーはどうなるのか

Macでゲームを遊ぶ人にとって、影響の出方は2通りに分かれます。

Mac版のゲームをSteamで遊んでいる場合

• Steam本体（steam_osx）はユニバーサルでした。2025年6月のベータから Apple silicon ネイティブになっています
• このMacに入っている Mac版のゲーム（Endless Sky・Battle for Wesnoth）の本体もユニバーサル
• ⚠ただしp971で測ったとおり、Steamから起動するとネイティブのゲームでもRosettaで動くことがあります。Rosettaが無くなったときに「arm64で起動し直してくれる」のか「起動できない」のかは、macOS 28が出るまで分かりません
• ★確かめ方と逃げ道はp986に書きました。.app を直接開くとネイティブで動きます

Windowsのゲームを互換レイヤーで遊んでいる場合

こちらは深刻です。Whisky の Wine は194個中194個、Wineskin は549個中548個が x86_64でした。Macで配られてきた無料のWineは、ほぼすべてRosettaの上で動いています。

• Whisky は開発が終わっています（p956）。Apple silicon 版が出る見込みはありません。⚠2026年9月時点では、初回に取りに行くWine一式の配布も止まっています。入れてある人は、Wine一式（Libraries フォルダ）を消さないでください（Whiskyの使い方とインストール手順）
• Porting Kit（p989）は Wineskin を使うので、同じく x86_64 です
• 有料の CrossOver 27 は ARM64 ネイティブ版を試験中です。報道では2027年初めの予定で、Intel Mac と32bitは切り捨て。いまのプレビューには「D3DMetal が無い」「ゲームランチャーが動かない」「既存のボトルを ARM64 へ移せない」という制限があります
• ⚠Appleの「古いゲーム向けにRosettaを残す」に、Wineのような互換レイヤーが含まれるかは公表されていません

【開発環境側】Homebrew・Python・Node・Java を確かめる

開発ツールは、自分でコマンドを叩いて確かめられるのが救いです。このMacの結果と、確かめるコマンドを並べます。

Java だけは、macOS がアーキまで表示してくれます。

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    21.0.2 (arm64) "Eclipse Adoptium" - "OpenJDK 21.0.2" ...
    1.8.0_302 (x86_64) "Eclipse Temurin" - "Eclipse Temurin 8" ...

Java 8 を「Rosettaが無い状態」で起動すると、予想どおり止まりました。

$ arch -arm64 /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home/bin/java -version
arch: posix_spawnp: .../temurin-8.jdk/Contents/Home/bin/java: Bad CPU type in executable

ただし、名前だけで java を呼ぶと 21（arm64）が選ばれていたので、困るのは Java 8 に固定しているプロジェクトだけです。

では置き換えられるのか。配布元のAPIに問い合わせると、配布元によって答えが違いました。

★「Java 8 だから置き換えられない」ではなく、「Temurin 8 だから置き換えられない」でした。配布元を変えれば済みます。

【整理】いまやること ── 優先度つき一覧

ここまでの結果を、手を付ける順番に並べました。

★いちばん確実な逃げ道は、macOS 27 に留まることです。どのページの書き方でも、27 で Rosetta が全部消えるとはされていません（9月9日の開発者ニュースを除く）。急いで 28 に上げなければ、少なくとも2027年秋までは今までどおり動きます。

【手順】自分のMacで確かめる

1. .app を一覧にする

system_profiler SPApplicationsDataType -json \
 | python3 -c 'import json,sys
d=json.load(sys.stdin)["SPApplicationsDataType"]
for a in d:
    if a.get("arch_kind")=="arch_i64": print(a["_name"], "-", a["path"])'

2. 気になるファイルのアーキを見る

lipo -archs /path/to/file      # ★1回に1ファイルだけ（複数渡すとエラー）
#   arm64 / arm64e が入っていれば大丈夫。x86_64 だけなら止まる

3. Rosettaが無い状態を再現する

arch -arm64 /path/to/command --version
#   Bad CPU type in executable と出たら、Rosettaが無いと動かない

⚠画面のあるアプリにはやらないでください。起動してしまうと、放置していたアプリほど自動更新が走ることがあります。コマンドの道具で試すのが安全です。

4. いま翻訳中のプロセスを見る

for p in $(pgrep -x "アプリ名"); do vmmap "$p" | grep "Code Type"; done
#   X86-64 (translated) なら Rosetta で動いている

5. フォルダを丸ごと数える

開発ツールやゲームの置き場所をまとめて調べるなら、この記事で使ったやり方がそのまま使えます。要点は3つです。

• ファイル先頭の Mach-O ヘッダでアーキを判定する（0xCAFEBABE は Java の .class と区別する）
• 同じヘッダの filetype を読んで、実行ファイル（2）だけを数える（オブジェクトファイル（1）やライブラリ（6）は後回し）
• 同じ場所に arm64 版が並んでいないかを見る（x86_64 → arm64 と名前を読み替えて探す）

つまずき集

まとめ

• ★いま（2026年9月）はまだ全部動く。Appleのサポート記事では、Rosettaが全面的に使えるのはmacOS 27まで、macOS 28（2027年秋の見込み）からは更新の止まった古いゲーム向けだけ
• ⚠★Apple自身のページが食い違っている。9月9日の開発者ニュースだけは「Rosettaは26まで」と読める。訂正は出ていない
• ⚠「ゲーム向けに残す」の中身は未公表。Wineのような互換レイヤーが含まれるかは分からない
• ★★Rosettaはプロセス単位。ネイティブのプロセスは x86_64 のライブラリを読み込めない（incompatible architecture）。だから本当に困るのはIntel専用の実行ファイルだけ
• Rosettaが無いときのエラーは Bad CPU type in executable。arch -arm64 を付けると、Rosettaを消さずに再現できる
• ★いま動いているプロセスを見ても分からない。547個中、翻訳中は0件だった
• ⚠システム情報の一覧は.appしか数えない。476本中Intelだけは11本だったが、開発ツールの中身はここに出てこない。しかもその11本には、Intel Mac向けに書き出すための型紙のような、このMacでは動かさないものも混ざる
• ★★ファイルの数で数えると60倍に見積もる。Unreal Engine の「Intel専用3,006個」のうち2,872個はオブジェクトファイルで、arm64版の無い実行ファイルは49個（1.6%）だった
• 本当に困るのは、本体はネイティブなのに付属の道具だけIntel専用というもの。Unity の焼き込み、UE の iPhone 実機用の道具、そして Java 8
• ★★Unity 6.6 で焼き込みを実際に動かすと、Progressive CPU と GPU はどちらも Intel専用の LightBaker で焼いていた（Rosettaの翻訳係の起動も確認）。新しい Unity Compute GPU は arm64 のワーカーで焼き、焼き込み中のRosettaは0回。ただし下準備の JobProcess は x86_64 のまま
• ★Unity は 6.4 → 6.6 で Intel専用の実行ファイルが 52 → 17。Android用JDKは arm64 になった。いままさに移行の途中
• ★Intel専用の道具は最初の1回が極端に遅いことがある（下準備が 335秒 → 2回目 7秒）。2回目は Rosetta の翻訳係が起動せず、翻訳済みの結果が使われていた
• ★Wine はほぼ全部 x86_64（Whisky 194/194、Wineskin 548/549）。CrossOver 27 の ARM64 版は2027年初めの予定だが、既存のボトルは移せないとされている
• ★Java 8 は「置き換えられない」ではなく「Temurin 8 だから置き換えられない」だった。Azul Zulu には arm64 版がある
• macOS 26.6 では、App Storeで入れたIntel専用アプリを開くと通知が出た。そしてmacOSはRosettaで動いたアプリをログに記録している

終わりが近いと聞くと全部が止まるように思えますが、数えてみると、本当に困るものはずっと少なく、しかもどこにあるかをコマンドで特定できました。いちばん怖いのは、ふだん見えない場所にある付属の道具が、ある日いきなり起動しなくなることです。いまのうちに一度、自分のMacを数えておくのがおすすめです😊

それでは、今回はここまで。最後までありがとうございました😊

参考サイト

• If you need to install Rosetta on your Mac（Apple サポート。2026-09-14 更新。「macOS 27まで」「macOS 28から古いゲーム向けだけ」の記述）
• Upcoming changes to Rosetta support for Intel-based macOS apps（Apple Developer ニュース。2026-09-01。macOS 26.4 の通知と、macOS 27が最後という記述）
• App Store submissions now open for the latest OS releases（Apple Developer ニュース。2026-09-09。⚠「macOS 26がRosettaの最後」と読める記述）
• Apple’s Own Pages Disagree on When Rosetta Support Actually Ends（The Mac Observer。3つのページの食い違いを指摘）
• Announcing the Transition of Apple silicon Unity Editor from Rosetta 2（Unity Discussions。Unityスタッフによる告知。残っているのは主にCPUライトマッパーという説明はこのスレッド。★この記事の実測では Progressive GPU も Intel専用の LightBaker を通っていた）
• First Apple Silicon-native CrossOver build in testing as Rosetta's end nears（AppleInsider。CrossOver 27 プレビューの制限と時期）
• Valve's Steam gaming client is finally getting an Apple Silicon native upgrade（AppleInsider。Steam本体のネイティブ化）
• Adoptium API ／ Azul Metadata API（Java 8 の arm64 版の有無を問い合わせた先）