症状：主アプリはUniversal Binaryなのに、CIのコード生成器やプラグインだけがx86_64で動いている。 最短解法：Rosettaの完全終了を待たず、隔離したApple Siliconノードで依存関係、arm64ビルド、テスト、署名、再起動復旧を順に確認し、Intel向けには別の互換パイプラインを残してください。
この判断は、macOSアプリ本体だけでなく、Framework、動的ライブラリ、プラグイン、コマンドラインツール、ビルド補助プログラムまで管理しているチーム向けです。リモート Mac CIを運用するDevOps担当者、Intel Mac向け製品を出荷するリリース責任者にも適用できます。
**最終更新：2026年9月20日。** macOS 27の公開日とRosettaに関する扱いは、[AppleのmacOS 27提供開始の発表](https://www.apple.com/newsroom/2026/09/major-updates-for-apples-software-platforms-are-now-available/?utm_source=openai)、[macOS 27リリースノート](https://developer.apple.com/documentation/macos-release-notes/macos-27-release-notes?changes=latest_minor&utm_source=openai)、Rosettaの技術文書を基に確認しています。
最初に判定基準を固定する
Appleは、2026年9月14日にmacOS 27を正式公開し、通常のIntelアプリに対するRosettaの一般的な対応はmacOS 27が最後の大きなバージョンになると案内しています。後続では一部の古いゲーム向けに限定的な機能が残る扱いですが、macOS 27の時点でIntel専用アプリがすべて起動不能になった、という意味ではありません。詳細はAppleのRosetta翻訳環境に関する説明で確認できます。
したがって、移行の合否を「Rosettaがインストールされているか」で決めてはいけません。合格条件は、クリーンなApple Siliconノードと新規のCIアカウントで、Rosettaを前提にせず本番相当の構築、テスト、署名、成果物生成まで完了することです。
| 確認対象 | 合格の証拠 | 2点 | 1点 | 0点 |
|---|---|---|---|---|
| 実行ファイルと依存関係 | file、lipo -info、依存一覧 | arm64またはUniversal | 代替計画あり | x86_64のみ |
| ビルドツール | 実プロセスの架構情報とログ | arm64で完了 | 一部Intel依存 | Rosettaが必須 |
| テスト | 起動、単体、統合、プラグイン試験 | 原生経路で完了 | 追加試験待ち | 転訳経路のみ |
| CIとキャッシュ | 空キャッシュ・新規クローンで再現 | 再現可能 | 条件付き | 旧成果物に依存 |
| 署名と公開 | Keychain、署名、公証、最終成果物 | 全工程完了 | 手動介入あり | Intelツールが阻害 |
| 互換線 | Intel向け成果物と責任範囲 | 独立運用 | 期限付き暫定 | 本線がIntel依存 |
第一段階：主アプリ以外の架構を洗い出す
まずリポジトリ、生成物、依存パッケージを次の単位に分けます。
- アプリ本体とヘルパーアプリ
- App Extension、プラグイン、Service
- Framework、XCFramework、動的ライブラリ、静的ライブラリ
- コード生成器、CLI、デーモン、カスタムBuild Phase
- テスト用ツール、署名、公証、配布補助ツール
file path/to/binary を実行し、Universal Binaryの内部スライスは lipo -info path/to/binary で確認します。arm64とx86_64の両方があればUniversal Binaryですが、それだけで実行時にRosettaが不要になるわけではありません。
依存台帳には、入手元、呼び出し箇所、必要な架構、更新可能性、担当者、阻害レベル、撤去条件を記録してください。Apple Silicon向けの移植方針はAppleのApple Silicon開発者資料にも整理されています。
第二段階：CIツールがRosetta依存か確認する
「どうやってCIツールのRosetta依存を調べるか」という問いには、実行ファイルの検査だけでは不十分です。次の3つの実行環境を分けて、同じコマンドの結果を比較します。
- 開発者がログインした対話型ターミナル
- SSHセッション
- Runnerサービスが使用するCIアカウント
uname -m、arch、which tool-name、file "$(which tool-name)" を記録します。PATH、Homebrewの配置、SDK、RubyやNode.jsなどのランタイムが異なると、手元ではarm64版を使っていても、Runnerだけが古いIntel版を呼び出します。
コンパイラのラッパー、シェルスクリプト、コード生成器、パッケージマネージャー、独自Build Phaseも対象です。Xcodeの設定値や架構指定は、Xcode Build Settings Referenceと実際のビルドログを突き合わせます。
合格は「Rosettaがある環境で動いた」ではなく、「新規アカウントとクリーンノードでarm64のまま完了した」です。arch -x86_64、x86_64固定のパス、Intel専用SDKがログに残る場合は、代替、再構築、交換のいずれかを決めるまで本線に昇格させません。
第三段階：x86_64依存を分類して止める
第三者製Framework、XCFramework、SDK、閉源プラグインは、一つずつ実際の対象スライスを確認します。対応は次の4分類に固定すると、担当者不在のままIntel依存が残りにくくなります。
- 更新：arm64を含む新しい版へ移行する
- 再構築：ソースからarm64またはUniversal Binaryを生成する
- 交換：別のライブラリや機能実装へ置き換える
- 保留：Intel互換線だけで使い、期限と終了条件を記録する
**注意:** Universal Binaryは「両方の架構を格納した形式」です。呼び出し先のCLI、子プロセス、プラグイン、署名済みヘルパーまでarm64対応とは限らないため、形式名だけを合格証拠にしないでください。
第四段階：転訳経路ではなく原生経路を試験する
試験は、Apple Silicon上で次の順に実施します。
- アプリのarm64起動と基本操作
- 単体テスト、統合テスト、UIテスト
- プラグインとExtensionの読み込み
- コード生成、パッケージ解決、成果物収集
- 署名、公証、配布用アーカイブの生成
- ノード再起動後のRunner、Keychain、定期タスクの復旧
第五段階：キャッシュ、署名、公開工程を空にする
CI移行で見落としやすいのは、ビルド本体ではなく古い成果物が残る周辺工程です。キャッシュキー、依存ダウンロード先、unameやarchによる条件分岐、x86_64固定パス、Runnerの起動スクリプトを確認します。
その後、キャッシュを削除し、全く新しいクローンから同じコミットを実行してください。成功した成果物が以前のIntelビルドを再利用していないこと、依存解決がarm64向けに行われていることをログで確認します。
署名工程では、実行アカウント、Keychainのロック状態、証明書、プロビジョニング情報、公証処理、最終アーカイブの架構を個別に記録します。ここでIntel専用の補助ツールが呼ばれるなら、ビルド成功だけを理由に出荷へ進めません。
第六段階：リモート Mac CIの本線と互換線を分ける
リモート Mac CIをIntel工具链からarm64へ移す場合、最初から旧パイプラインを削除するのではなく、同一コミットをApple Siliconの候補本線と旧互換線へ流します。候補本線は原生ビルド、テスト、署名、再起動復旧までを担当し、互換線はIntelユーザー向け成果物など責任範囲を限定します。
自社で検証用ノードをすぐ用意できない場合は、MACGPUのリモートMac環境を隔離ノードとして使い、既存CIの設定を複製して比較できます。導入前に、必要なSSH権限、Runnerの常駐方法、Keychainの扱い、持ち込めない秘密情報を整理してください。構成候補を比較する際は、Apple Silicon Macの選定情報も確認できます。
受け入れ判定
- 合格：新規アカウント、空キャッシュ、全依存、署名、再起動復旧をarm64で完了
- 期限付き整改：本線はarm64で成立し、互換線にだけ未移行依存が残る
- 阻止：本番ビルド、署名、テストのいずれかがRosettaまたはIntel専用ツールを必須とする
現在のIntel Macだけで確認を続ける方法は、Apple Silicon上のarm64挙動、RunnerのPATH差異、Rosettaを経由したプラグイン問題を発見しにくいという欠点があります。仮想環境や共有クラウドだけに寄せる方法も、物理Mac固有の署名、Keychain、常駐Runnerの再起動復旧を同じ条件で検証できない場合があります。
そのため、既存環境をすぐ廃止するのではなく、まずMACGPUのApple SiliconリモートMacに同じコミットとCI手順を複製し、原生ビルドと公開工程を確認する方法が現実的です。短期間の移行検証や一時的なCIノードが必要なら、購入前に隔離環境で受け入れ判定まで進められます。恒常的な高負荷運用や物理インターフェースが必要な場合は、自社保有のMacの方が適するため、互換線をいつまでレンタル環境で運用するかも同時に決めてください。