クラウド Mac mini の Rosetta 2 互換性対策

深夜2時、チーム内で最も古いiOSプロジェクトを、ローカルのIntel Macから開設したてのクラウド Mac mini M4 に移行した。pod install は問題なく完了したが、xcodebuild を起動した瞬間、have architecture 'x86_64', need 'arm64' という赤いエラーが一斉に噴き出した。これはネットワークの問題でも設定ファイルの誤りでもない。マシンのチップが変わったことが原因だ——Apple Silicon と Intel はまったく異なる命令セットを採用しており、長年蓄積された古いプロジェクトのサードパーティライブラリ、スクリプト、コマンドラインツールの中には、いまだ x86_64 時代のまま止まっているものが少なくない。移行は単純なコピー&ペーストでは済まず、まずアーキテクチャの壁を越える必要がある。

シーン:専有物理マシンで初回ビルドがいきなり失敗する

クラウド Mac mini の M4 チップは arm64 ネイティブの OS を動かしているが、プロジェクトの中には次のような「居座り組」が潜んでいることがある——ある署名ツールのプリコンパイル済みバイナリ、長年更新されていない CocoaPods のプライベートソース、あるいは CI スクリプトから直接呼び出している古いバージョンのコマンドラインツールなど。これらはローカルの Intel Mac 上では一度も問題を起こさなかったが、Apple Silicon マシンに移してはじめて正体を現す。

システムからの補足:このデバイスは専有物理マシンです。アーキテクチャの切り替え、Rosetta のインストール、システム設定の変更は自分自身のインスタンスにのみ作用し、他の「隣人」の実行環境には一切影響しません——これも共有型の仮想マシンではなく専有物理マシンを選ぶ理由の一つです。

Rosetta 2 とは何か、本当に必要になるのはいつか

Rosetta 2 は Apple が提供する動的トランスレーションレイヤーで、x86_64 でコンパイルされたバイナリを arm64 チップ上で動かせるようにするが、その代償として性能が低下する。「まず動かしてから最適化する」という過渡的なシーンには向いているが、長期的に依存すべきものではない——arm64 ネイティブ版が見つかる依存関係は、できるだけ早く置き換えるべきだ。

依存関係が Rosetta を必要としているか判定する

いきなりインストールするのではなく、まず次の2つのコマンドでどのファイルが「外来種」なのかを確認する:

file /usr/local/bin/some-tool
lipo -info /usr/local/lib/libSomeSDK.a

file はそれが Mach-O 64-bit x86_64 executable なのか arm64 バイナリなのかを直接教えてくれる。静的ライブラリについては lipo -info のほうが確実で、universal(x86_64 と arm64 の両方を含む)かどうかが分かる。出力に x86_64 しか表示されない場合、その項目は Rosetta 経由での互換動作に頼るか、ベンダーに arm64 版を求める必要がある。

3ステップで互換レイヤーを整える

ステップ1:Rosetta をインストールする

クラウド Mac mini 上で一度実行すればシステムレベルで有効になる:

softwareupdate --install-rosetta --agree-to-license

ステップ2:問題のある依存関係をすべて特定する

小さなループスクリプトを書いて Pods/ ディレクトリ内の静的ライブラリと依存バイナリを一括スキャンし、arm64 でないものをリストアップして記録しておく。以降のアップグレード時にこのリストと照らし合わせて一つずつ確認できる:

find Pods -name "*.a" -exec sh -c 'lipo -info "$1" | grep -q arm64 || echo "$1"' _ {} \;

ステップ3:必要に応じてアーキテクチャを明示的に指定して実行する

arm64 版がまだ見つからないコマンドラインツールについては、arch で明示的にアーキテクチャを指定し、Rosetta 経由で実行させる。システムに自動判定させてエラーになるのを待つべきではない:

arch -x86_64 /usr/local/bin/legacy-signing-tool --version

CocoaPods と Homebrew のアーキテクチャ競合を調べる

シミュレータビルドで「対応するアーキテクチャのスライスが見つからない」というエラーが出る場合、たいてい Podfile 内で arm64 シミュレータアーキテクチャを除外し忘れている、あるいは逆に arm64 実機アーキテクチャを誤って除外してしまっているケースだ。Podfile の末尾にシミュレータ向けの除外ルールを追加し、同時に Xcode のビルド設定にある Excluded Architectures の値が逆方向になっていないかも確認する。

Homebrew 側でよくある落とし穴は、新旧2種類のプレフィックスを混在させてしまうことだ——arm64 ネイティブの Homebrew は /opt/homebrew にインストールされるが、Rosetta 上で動く x86_64 版の Homebrew は /usr/local にインストールされる。この2つの brew を混在させると依存関係のバージョンが頻繁に衝突するため、一方だけを残し、.zshrc で PATH の優先順位を明示的に指定することを推奨する。

チェックリストとよくあるエラー対照表

移行後の検証:ネイティブか互換レイヤーか

ビルドが通ったからといって移行が完了したわけではない。重要な処理経路が実際に arm64 ネイティブモードで動いているのか、それとも常に Rosetta に頼りきっているのかを確認する必要がある。ビルドスクリプトに現在のプロセスのアーキテクチャを出力する自己診断の一行を加えておくとよい。もしメインのビルドフロー(周辺的なツールではなく)が長期的に Rosetta に依存していることが分かれば、それは置き換えの余地があることを示しており、次回の依存関係アップグレード計画に組み込む価値がある。

よくある質問