Rosetta 2 はいつサポート終了？2026年企業Mac CI移行チェックリスト

Appleは、macOS 27をIntel専用macOSアプリに対する汎用的なRosettaサポートの最後の主要バージョンと案内しています。macOS 26.4以降では、移行を促す通知が表示される可能性もあります。したがって、macOS 27は「まだ動くから安心できる版」ではなく、企業が依存関係を発見して退出計画を確定する最後の大きな窓口です。

ここで3つの境界を混同しないでください。

• Intel MacのハードウェアがmacOS 27をサポートするか。
• Apple Silicon上でIntel専用macOSアプリをRosetta 2経由で実行できるか。
• Linux仮想マシン内のx86_64バイナリを、別の変換機構で実行できるか。

Rosetta 2の説明はmacOSアプリの実行環境に関するものです。Linux VM内のIntelバイナリは別の仕組みとして扱う必要があり、AppleのLinux VMに関する説明でも境界が分けられています。macOS 28の公開時期、最終的な挙動、例外範囲は、Appleが正式に確認するまで推測しないでください。

Apple Siliconを導入済みでも、CI全体がarm64化されているとは限りません。確認対象は主アプリだけではなく、ジョブから間接的に呼ばれる部品まで含めます。

第一歩：資産台帳の項目を固定する

次の項目を1行1資産で登録してください。

• ファイル名、配置パス、バージョン
• arm64、x86_64、Universal Binaryの別
• 呼び出すCIジョブとリリース工程
• 所有チームと代替案
• 失敗した場合の本番影響
• 実行確認日、ログ、ハッシュ、承認者

対象にはCIエージェント、シェルスクリプト、パッケージマネージャーのディレクトリ、LaunchAgent、プラグイン、動的ライブラリ、インストールスクリプト、前後処理、自社バイナリを含めます。依存の所在が不明なものは「問題なし」ではなく、未確認として隔離します。

第二歩：アーキテクチャを3段階で照合する

核となるコマンドだけで調査できます。

file /path/to/tool
lipo -info /path/to/tool
ps -axo pid,comm

fileで実行ファイルの形式を確認し、lipo -infoでUniversal Binaryの切片を確認します。実行中プロセスは、プロセス一覧とジョブログ、起動元スクリプトを突き合わせてください。シェルがarm64でも、そこから呼び出すCLIがx86_64ならRosetta依存は残ります。

第三歩：依存の種類を分けて責任者へ渡す

自社コードならarm64またはUniversal Binaryとして再ビルドできるかを開発チームへ渡します。提供元にarm64版があるツールは置き換え候補です。閉鎖的なプラグインや更新されない補助ツールは、CI基盤チームだけで解決しようとせず、例外承認へ回します。

Universal Binaryの生成方法は、AppleのUniversal Binary構築ガイドに沿って確認してください。ただし、2つの切片が存在するだけで受け入れてはいけません。署名、公証、プラグイン読み込み、実案件の生成物まで検証対象です。

x86_64のビルドツールをarm64へ移行する際は、次の順番で判定します。

1. 同一ツールのarm64版が公式に提供されているか確認する。
2. 依存ライブラリとプラグインがarm64に対応しているか調べる。
3. 自社コードをarm64、またはUniversal Binaryとして再ビルドする。
4. スクリプトのインタープリターと子プロセスの形式を確認する。
5. 実プロジェクトでビルド、テスト、署名、アーカイブ、配布を実行する。
6. 生成物のハッシュ、ログ、承認記録を保存する。

パッケージマネージャーのパスを置き換えただけでは不十分です。古いプラグインローダーがIntel版ライブラリを要求したり、インストール後スクリプトだけがx86_64の補助ツールを起動したりします。AppleのApple Silicon移行ドキュメントを参照しつつ、依存グラフの末端まで確認してください。

次の条件に当たるものは、互換ノードへ一時隔離します。

• arm64版の提供予定が確認できない。
• ソースコードがなく、再ビルドできない。
• 署名や公証の工程でarm64実行が確認できない。
• システム設定の安全性を下げないと動作しない。
• 再起動後の無人実行を再現できない。

互換ノードへ送る場合も、例外の所有者、代替案、終了日、対象ジョブを必ず登録します。

arm64ネイティブのジョブとRosetta依存ジョブを、同じキューやキャッシュで無差別に処理しないでください。ノードラベル、キュー、Runnerのタグ、キャッシュ領域を分離します。環境変数だけで切り替える方式は、ジョブの再実行時に別アーキテクチャのキャッシュを拾う危険があります。

二重検証では、代表性のある次のジョブを選びます。

• 通常のPull Requestビルド
• 単体テストと結合テスト
• アーカイブと署名
• 配布用パッケージの生成
• 失敗後の再実行
• ノード再起動後の無人復旧

比較するのは処理時間だけではありません。終了コード、生成物のハッシュ、署名状態、ログの差分、キュー待ち、再実行の結果、秘密情報へのアクセス、キャッシュの分離を確認します。処理時間や容量について企業の記録または本站実測がない場合、推測値で優劣を決めないでください。

Xcode 27のリリースノートとmacOS 27のリリースノートは、正式版の公開後に再確認します。RCの結果をそのまま本番互換性の証拠にはしません。

CIが一度成功しても、次の項目に失敗するなら本番投入を止めます。

• Keychainの参照が無人セッションで完了するか。
• コード署名と公証がarm64ノードで完了するか。
• 内部プラグインが正しいアーキテクチャで読み込まれるか。
• LaunchAgentやデーモンが再起動後に自動復旧するか。
• Universal Binaryの両方の切片が同じ署名・配布検証を通るか。
• セキュリティ設定を緩めずに動作するか。

「ログインしていると成功する」構成は、CIサーバーとしての完成形ではありません。再起動、セッション切断、認証情報の再取得、失敗後の再実行までを受け入れ試験に含めます。

注意：Rosettaの警告が表示されないことは、Rosetta依存がない証拠ではありません。依存する子プロセス、プラグイン、前後処理の実行記録まで残してください。

macOS 27ではIntelアプリをまだ実行できますか？

現時点では、macOS 27はIntel専用macOSアプリに対する汎用的なRosettaサポートを提供する最後の主要バージョンとAppleが案内しています。ただし、これはCI移行を先送りしてよいという意味ではありません。macOS 27.0の正式版リリースノートと対象ツールの対応状況を確認し、arm64で本番ジョブが完了する証拠を先に取得してください。

Mac CIがRosetta 2に依存しているか確認するには？

実行ファイルだけでなく、CIエージェント、シェルスクリプト、パッケージマネージャー、プラグイン、動的ライブラリ、LaunchAgent、インストーラーの前後処理を調査します。fileやlipoで形式を確認し、実行中プロセスのアーキテクチャと呼び出し元をログへ残してください。アプリが起動しただけでは、子プロセスまでarm64とは判断できません。

x86_64のビルドツールをarm64へ移行する方法は？

まず提供元のarm64版へ置き換え、選択肢がなければ自社コードをarm64またはUniversal Binaryとして再ビルドします。依存ライブラリ、プラグイン、スクリプトの呼び出し先も同時に確認し、実案件のコンパイル、署名、アーカイブ、配布まで通してください。インストール成功だけでは移行完了とは扱いません。

企業はmacOS 27向けの互換ノードを残すべきですか？

残す場合は、対象ジョブ、責任者、代替計画、終了日を例外台帳に登録してください。新しいx86_64依存を受け入れる恒久ノードにすると、移行の判断が遅れます。arm64ノードで同じジョブを実行でき、署名や復旧まで確認できたものから互換ノードの対象外へ移します。

Rosettaのサポート終了でCIスクリプトは何が壊れますか？

Intel専用のCLI、パッケージマネージャー配下の実行ファイル、プラグインローダー、動的ライブラリ、インストーラーの前後処理、署名や公証の補助ツールが候補です。特にシェルから起動される子プロセスは見落とされやすいため、成功ログだけでなく実行ファイルの形式、終了コード、生成物のハッシュ、再起動後の復旧結果を確認します。

必要なMacの台数を開発者数だけで決めないでください。最低限、次の変数を分けます。

• arm64へ移行済みのジョブ数
• 1ノードあたりの有効な同時実行数
• 互換ノードへ残るジョブ数
• リリース集中時のピーク
• 障害時に必要な予備経路
• 互換ノードを閉じる予定日

既存のApple Siliconノードで二重実行する余力がない場合は、購入、短期のリモートMacレンタル、混合ノードのいずれかを比較します。価格、納期、物理アクセス、運用担当、データ境界を同じ条件で見てください。長期にわたり高負荷で安定運用し、物理機器や専用ネットワークが必要なら自社購入が向きます。一方、移行期間だけ検証容量を増やす場合は、CALMVPSのMac利用プランで短期ノードを用意し、実際のCIジョブを通してから恒久調達を決める方法があります。

短期検証を行う場合は、まず隔離したApple SiliconのリモートMacを1組用意し、実際の署名、アーカイブ、配布、再起動復旧を確認します。CALMVPSの利用を検討するなら、日本向けの申込み案内で提供条件を確認し、社内のアクセス制御とログ保存方針に適合するかを先に確認してください。サービスの利用だけでセキュリティ要件が満たされるとは判断せず、あなたのCI設計側で責任分界を記録します。

IT責任者

• [ ] x86_64依存資産に所有者が設定されている
• [ ] macOS 27の更新対象と保留対象が分かれている
• [ ] 互換ノードに終了日がある
• [ ] 失敗時のロールバック経路が確認されている

ツールチェーン責任者

• [ ] arm64版またはUniversal Binaryの根拠がある
• [ ] 子プロセス、プラグイン、動的ライブラリを確認した
• [ ] 実案件で署名、アーカイブ、配布を完了した
• [ ] 生成物のハッシュとログを保存した

CI基盤責任者

• [ ] 原生池と互換池のキューが分離されている
• [ ] キャッシュと環境変数がアーキテクチャ間で混ざらない
• [ ] Pull Request、テスト、リリースを二重実行した
• [ ] 再起動後の無人復旧を確認した

セキュリティ・購買責任者

• [ ] Keychain、署名、公証、内部プラグインを検証した
• [ ] 安全設定を下げる例外が残っていない
• [ ] ピーク時と障害時の容量を説明できる
• [ ] 購入、レンタル、混合運用の採用条件が比較されている

既存の「Intel Macを使っていない」という確認だけでは不十分です。Apple SiliconのMacでRosettaプロセスを起動していないこと、arm64の生成物が正しく署名されること、ノード再起動後もCIが自動復旧することまで揃って、初めて本番移行の証拠になります。

手元のMacだけで二重検証を行うと、リリース集中時の容量不足や失敗時の代替経路を確認できません。購入したMacを先に余らせるより、CALMVPSのリモートMacで隔離した試験ノードを用意し、実ジョブ、署名、復旧、アクセス権限を確認してから長期購入台数を決める方が、移行期の判断を誤りにくくなります。検証結果が揃った時点で、短期レンタルを終了するか、継続的な混合ノードとして組み込むかを決定してください。