GitHub Actions macOS 26 Runner：arm64かIntelか？2026年

症状：macOS 26のRunnerを選べず、全ジョブをどちらかに寄せようとしている。
最短の対応：Apple Silicon向けの通常ビルドはarm64から試し、Intelでの検証・依存・納品要件があるジョブだけIntelに割り当てます。

この方針は、プロジェクトの実際の対応範囲をビルド成果物とテストで確認できる場合に適しています。両方のCPUアーキテクチャをサポートするなら、必要なジョブをマトリクスに分けて検証してください。

独立開発者：日常のiOS・macOSビルドに適したmacOS 26 Runnerを選びたい方。
Appleプラットフォームチーム：Intel向けの互換性や古い依存関係をまだ確認すべきか判断したい方。
CI・開発基盤の担当者：Runnerラベル、アーキテクチャ別のジョブ、例外タスクの保守ルールを決めたい方。

SECTION 01GitHub Actions macOS 26 Runnerの選定で分ける3つの軸

Runnerのホストアーキテクチャ、アプリが対象とするアーキテクチャ、実際にテストした範囲は別の情報です。arm64 Runnerでビルドが成功しても、その成果物がIntel環境で動くことやIntel上の問題が再現できることまでは証明されません。

この対応関係は、GitHubのRunner選択ドキュメントとmacOS 26提供開始の公式告知で確認できます。macOS 26のホストがarm64かIntelかという情報は、アプリが生成するバイナリの種類や、テストで網羅したCPU環境を示すものではありません。

AppleのUniversal macOSバイナリの説明に沿って、成果物が単一アーキテクチャかUniversalか、さらに各アーキテクチャで実行確認したかを記録してください。移行時は、AppleのApple Silicon向けビルドエラー解説も参照し、アーキテクチャに起因するエラーをソースコードの不具合と混同しないようにします。

SECTION 02独立開発者：日々のビルド対象から絞る

独立開発者が最初に選ぶのは、手元の開発機に合わせたRunnerではなく、リリース予定のアプリとCIで確認したい項目です。iOSアプリをApple Silicon向けにビルドする一般的なジョブならmacos-26から試し、Intel上での実行や互換性確認が必要な作業は別ジョブにします。

iOSプロジェクトではmacos-26とmacos-26-intelをどう分けるか

アプリの配布先がiPhoneやiPadであっても、それだけでIntel Runnerが不要とは決められません。ビルド対象のiOSデバイス、Simulatorのテスト構成、ビルドに使うMacのホストアーキテクチャを分けて、現在のworkflowが実際にどれを検証しているか確認します。

条件分岐： arm64のみを主な納品・検証対象とするならmacos-26を選びます。Intelでの動作確認、Intel限定の依存、またはIntel上でのみ再現する不具合が必要なら、その作業だけmacos-26-intelへ分けます。両方を保証する要件がある場合は、一方の成功をもう一方の合格に読み替えず、それぞれのジョブを設けてください。

SECTION 03Apple Silicon中心のチーム：arm64ワークフローを受け入れる

チームの標準ビルドをarm64に寄せる前に、依存パッケージ、ビルドスクリプト、サードパーティーActionが同じ環境で動くかを確認します。Apple Silicon向けの通常ジョブをまとめやすい一方、アーキテクチャを前提にしたバイナリ依存やスクリプトが残っていると、Runnerの切り替え時に失敗する可能性があります。

Xcode 27のGitHub ActionsではどのRunnerから試すか

GitHubは、Xcode 27のRunnerイメージが一般提供になったことを2026年10月15日の告知で案内しています。AppleのXcode 27リリースノートと合わせて、必要なXcode・SDK・ツールチェーンを確認してから、workflowのRunnerラベルを決めてください。

macos-26とmacos-26-intelのどちらでXcode 27を使う場合も、ラベルだけで利用可能なイメージやプロジェクトとの互換性を断定しないことが重要です。GitHubのホストRunner利用ガイドで現在のイメージ情報を確認し、実際のビルドとテストを通して受け入れます。

SECTION 04Intel対応を担うアプリチーム：互換性の確認を独立させる

Intel向けアプリを継続して配布するチームでは、「ビルドが通った」と「Intelで使えることを確認した」を別の判定にします。Intel向けの成果物が必要なのか、Intel上でアプリを実行するテストが必要なのか、特定のアーキテクチャでのみ起きる不具合の再現が必要なのかを、リリース要件ごとに分けてください。

macOS 26 Intel Runnerを使うべき作業

macos-26-intelは、Intel環境を対象とする実行確認や、Intelでしか再現しない問題の切り分けなど、Intelホスト上の検証が必要なタスクに割り当てます。成果物が複数アーキテクチャを含む場合も、生成物の構成と実行テストの記録を分け、ビルド成功だけから互換性を推定しないでください。

SECTION 05遺産となった依存とリリース工程を管理するチーム

古いバイナリ依存やビルドスクリプトが残る場合は、Runnerを切り替える前に、各コンポーネントが要求するアーキテクチャとエラーの発生条件を記録します。Intel上でのみ再現した問題があるなら、その確認ジョブにIntel Runnerを残す理由を明記し、ほかのworkflowまで一律にIntelへ移すのは避けます。

署名、テスト端末の登録、Runnerのアーキテクチャも、別の要件として扱います。AppleのXcodeシステム要件でツールチェーンの条件を確認し、GitHubの大規模Runnerに関するmacOSの制約も必要な場合に個別に参照してください。特定の端末識別子やホスト動作が必要な工程は、利用するRunnerラベルと実際のworkflowで検証します。特定Runnerに関する条件を、すべてのmacOS Runnerの制限として一般化しないでください。

SECTION 06CI基盤の担当者：標準ラベルと例外の責任を決める

CI基盤を運用する場合、Runnerの選択はラベルを決めて終わりではありません。どのチームが架構マトリクスを保守し、依存の変更やXcode更新時に誰が再確認するかまで決める必要があります。単一アーキテクチャ、arm64とIntelのマトリクス、Intel専用の例外タスクのいずれを採用するかは、プロジェクトが約束する対応範囲に合わせます。

試行から標準化までの手順

• 対象を棚卸しします。 成果物の対象アーキテクチャ、必須テスト、Intelでの実行要件、バイナリ依存、署名工程を書き出します。
• ジョブを小さく選びます。 代表的なビルドとテストを選び、まず標準候補のRunnerラベルで実行します。
• 実プロジェクトで確認します。 ビルド結果だけでなく、テスト、成果物の構成、依存の読み込み、署名工程を確認します。
• Intel要件を切り分けます。 Intelで動かす必要のあるテストや問題再現だけをmacos-26-intelに割り当てます。
• 必要な場合だけマトリクスにします。 両アーキテクチャのサポートを約束するプロジェクトは、各環境の結果を独立して記録します。
• 例外の所有者を決めます。 Intel専用ジョブの理由、見直す担当者、依存変更後の再検証方法を記録します。

2026年11月2日更新。GitHubのmacOS 26一般提供告知、Runner選択・利用・大規模Runnerの公式資料、Xcode 27の提供告知およびAppleのリリースノートを基に記載しています。ラベル、利用可能なイメージ、適用条件は変更される可能性があるため、公開前と運用変更時に各公式資料を再確認してください。

GitHub-hosted Runnerは、ジョブごとに扱うホスト環境や運用上の制約を確認して使う仕組みです。ホスト状態を継続して保持したい、ホストをより細かく管理したい、またはチーム専用のMac環境を継続運用したい場合は、ラベルの違いだけで移行を決めず、実ジョブの結果と必要な運用条件を並べて比較してください。必要な期間だけMac環境を確保したい場合は、MACNOXの料金案内で条件を確認できます。標準Runnerで要件を満たし、ホスト管理が不要なら、GitHub-hosted Runnerのまま運用する方が適切です。専用環境の継続性やホスト制御が必要なときに限り、MACNOXの利用方法も比較対象に加えてください。

SECTION 07関連記事

• Xcode 27 Runnerの本番投入に向けた受け入れチェックリスト
• 企業内ネットワークや端末要件から選ぶGitHub Actions Runner