macos-14を指定したジョブが実行できず、CIが止まっている。
GitHub ActionsのmacOS 14 Runnerは2026年11月2日に廃止されています。まず現在のRunner文書とイメージ一覧で候補ラベルを絞り、macOS・Xcode・CPUアーキテクチャを照合してください。そのうえで隔離または二重実行し、ビルド、テスト、署名、成果物を確認してから切り替えます。GitHubの廃止告知
この記事の対象
macos-14、macos-14-large、macos-14-xlargeをワークフローで使っているAppleプラットフォーム開発チームは、影響するジョブを棚卸しして移行計画を立てる必要があります。
署名・テスト・リリースを担当するCIエンジニアや、macOSツールチェーンを管理するDevOps・開発基盤担当者向けに、移行先の判定と切り替え条件を整理します。
最終更新：2026年11月8日。退役日はGitHubの公式告知で確認し、利用可能なラベルとイメージ情報はGitHub-hosted Runnerの現行文書およびRunnerイメージ一覧を基準にしています。
退役ラベルと候補環境の切り分け
廃止対象はmacos-14、macos-14-large、macos-14-xlargeです。これらを指定するジョブは、同じラベルへの依存を解消しない限り移行対象になります。ワークフロー内のruns-onだけでなく、再利用ワークフロー、複数ジョブのマトリックス、外部アクションから呼び出すジョブも確認します。GitHubの告知に示された移行方向だけで、すべての候補ラベルやインストール済みソフトウェアまで確定したと判断しないでください。
| 確認対象 | 移行時の見方 | 次の判断 |
|---|---|---|
| macOSラベル | 現行Runner文書で提供状況を確認 | 対象OSが必要条件を満たす候補だけ残す |
| Xcode・SDK | イメージのソフトウェア一覧とAppleの要件を照合 | 必要なXcodeがなければ別環境を検討 |
| CPUアーキテクチャ | ラベル名だけで決めず、実行ログと文書で確認 | Intel依存があれば該当する実行環境を確保 |
| ネットワーク・認証 | プライベート依存先や署名情報への経路を確認 | 接続条件を満たすRunnerに限定 |
macOS 14 Runnerの廃止後、どのラベルに変更するか。
macos-15やmacos-26などを候補として調べる場合も、ラベルが現在提供されているか、対象イメージに必要なツールがあるかを先に確認します。名称が新しいことやlatestであることは、プロジェクトのXcode、SDK、CPU要件を満たす根拠にはなりません。上記の現行Runner文書とイメージ一覧を合わせて参照してください。
XcodeとOSの互換性を照合
RunnerのmacOSバージョンを変えても、プロジェクトのXcodeやSDK要件まで自動的に満たされるわけではありません。まず現行ログからXcode、Swift、SDK、選択したSimulatorの情報を記録し、新しいイメージで同じ要件を再現できるかを確認します。Xcodeの対応OSや機能は、AppleのXcode 26リリースノートとXcodeのシステム要件に照らします。
macos-14からmacos-15またはmacos-26へ移す前に何を検証するか。
リリースノートで必要なXcodeの対応条件を確認し、候補イメージにそのXcodeとSDKが含まれるかを調べます。正式版を前提にした本番ジョブとBetaを試す検証ジョブは分け、Betaで通った結果をそのまま正式リリースの受け入れ条件にしないでください。Xcodeの選択をワークフローで明示している場合は、選択処理が新イメージでも同じツールチェーンを指しているかをログで照合します。
CPUとネイティブ依存の適合確認
アーキテクチャの変更は、ジョブが起動しただけでは検知しきれません。バイナリ依存、独自のビルドスクリプト、キャッシュ、外部ツールが特定CPU向けに構成されていると、依存関係の導入は成功しても、コンパイルやテストで失敗することがあります。既存ログでアーキテクチャを確認したうえで、候補Runnerの実際の環境と照合してください。
Intel向けのビルドが残っている場合はどうするか。
Intel専用のバイナリやスクリプトがあるなら、現行文書でIntelアーキテクチャのRunnerが利用可能か確認し、必要なジョブだけをその環境に割り当てます。該当するホスト環境を確保できない場合は、依存をApple Silicon対応にできるか、別のビルド経路が必要かを個別に判断します。ラベル名からCPUを推測せず、実行ログで実際のアーキテクチャを確認してください。
ビルドとリリース成果物の受け入れ
移行の合否は、ジョブが成功したかだけで決めず、成果物まで同じ条件で確かめます。クリーンビルド、プロジェクトのテスト、必要なSimulator実行、署名、アーカイブを代表的なワークフローで確認し、旧環境と新環境のログおよび成果物情報を保存します。Simulatorの種類、プライベート依存、配布用の認証情報を使う場合は、項目ごとに実行結果を照合してください。
Runner変更後にXcodeとSimulatorのテストが正常か、どう確かめるか。
同一コミットで新旧環境を別ジョブとして試し、Xcodeの選択結果、テスト対象のSimulator、テストレポート、アーカイブと署名の結果を比較します。ログには失敗箇所に加えて、Runnerラベル、OS、ツールチェーンの情報も残します。単一のビルド成功だけでは、Simulatorテストや配布経路まで受け入れたことにはなりません。GitHubのマトリックス実行の説明を使えば、候補環境を分けて並行検証できます。
ネットワークと運用条件の確認
macOS CIの移行では、ビルド結果以外に、プライベート依存先への接続、社内ネットワークの許可条件、キャッシュ、認証情報の取り扱いも確認します。キャッシュはOSやツールチェーンが変わると古い内容が再利用され、原因の切り分けを難しくすることがあります。キャッシュキーに環境条件を含め、必要に応じて新環境用のキャッシュとして検証してください。GitHubの依存キャッシュ文書では、キャッシュの仕組みとキーによる復元条件を確認できます。
自ホスト型Runnerを選ぶ場合、OSイメージの維持だけでなく、ネットワーク到達性、Runnerの登録・更新、認証情報の保護、障害時の復旧もチーム側の運用範囲になります。自ホスト型Runnerのネットワークと運用要件を確認し、GitHub-hosted環境と同じ責任分担だと思い込まないようにします。利用可能性や待ち時間は、旧イメージでの経験から新環境へ一般化せず、実際の運用ログで評価してください。
隔離試行から切り替えまでの確認項目
次の項目を満たすまでは、リリース用ワークフローの既定ラベルを変更しない進め方が安全です。
- [ ] ワークフローと再利用定義を検索し、廃止対象の3ラベルが残るジョブを洗い出した。
- [ ] 現行文書とイメージ一覧で候補ラベル、macOS、Xcode、SDK、CPUを照合した。
- [ ] 依存関係の取得、ネイティブ依存のビルド、テストを候補Runnerで個別に確認した。
- [ ] Simulator、署名、アーカイブ、成果物の各条件を同一コミットで比較した。
- [ ] プライベート依存先、ネットワーク許可、キャッシュ、認証情報の動作を確認した。
- [ ] ログと成果物を保存し、失敗時に旧経路または別候補へ戻す条件を決めた。
移行先は、次の分岐で決めます。
- 必要なmacOS・Xcode・CPU条件を満たし、隔離試行でテストと配布まで通る場合：その候補を本番に段階的に切り替えます。
- XcodeやCPU条件の一部が合わない場合：該当ジョブだけ別ラベルまたは別の実行環境へ分け、全ジョブを一括移行しません。
- 署名、ネットワーク、成果物の比較が未完了の場合：切り替えを保留し、未確認項目を解消してから再試行します。
継続的に実行する際は、選定理由、検証したコミット、ツールチェーン、失敗時の戻し方も記録しておくと、次のイメージ変更時に判断を再現できます。ラベル変更を完了条件にせず、プロジェクト固有の受け入れ結果を記録に残してください。
継続検証用のMac環境を選ぶ場合
GitHub-hosted Runnerは既存のActionsワークフローに組み込みやすい一方、利用可能なラベルやイメージ内のソフトウェアを確認し続ける必要があり、プライベート依存への接続条件やジョブ間で保持したい環境も別途設計が必要です。自ホスト環境はネットワークや環境を調整しやすい反面、ホストの更新、Runnerの維持、復旧を担当する運用負荷が増えます。
毎回のCI実行だけでなく、チームが継続してアクセスできる実Mac環境で開発・検証したい場合は、RUVCLOUDのMac環境も候補になります。レンタル環境が必要な期間や使い方に合うかは、料金案内で確認し、実際のプロジェクト、ツールチェーン、署名手順を使って受け入れ試験を行ってください。常時稼働のCI運用や物理機器との接続が必須なら、自社管理のMacや既存Runnerのほうが適する場合もあります。まずは候補環境で同じコミットのビルドとテストを再実行し、CIの代替にできる範囲を確かめてから判断してください。