2026年11月2日に macOS 14 の托管 Runner イメージが退役予定です。退役後に慌てないよう、まず現行ワークフローを洗い出し、候補の Runner ラベルを並行して試してください。移行完了の判断は、実際のビルド、テスト、署名、公開までの経路が通るかどうかで行います。日付と対象ラベルはGitHubの退役公告で確認できます。
この記事は、まだ macOS 14 の Runner ラベルを指定している開発者、CI担当者、リリース担当者向けです。プロジェクトの依存関係や Xcode の組み合わせを確認し、影響を抑えながら切り替えたい場合に役立ちます。
最終更新：2026年10月7日。 退役日と対象ラベルはGitHubの公式公告、ソフトウェア構成の確認先は公式Runnerイメージ一覧です。公開前にも、公告の日付や brownout の予定、利用できるイメージが変更されていないか確認してください。
通知を確認したら、影響するワークフローを洗い出す
GitHubは2026年10月1日の公告で、macos-14、macos-14-large、macos-14-xlarge を退役対象として示し、退役予定日を2026年11月2日としています。移行先の候補ラベルと brownout の予定も同じ公告に記載されています。試行計画を立てる際は、日付や予定を記憶に頼らず、公告の最新状態を基準にしてください。
最初に確認するのは、リポジトリ内にラベルが記載されているかだけではありません。ブランチ条件、手動実行、再利用ワークフロー、リリース専用ジョブも調べ、どの経路が影響を受けるかを整理します。runs-on の指定や条件分岐はGitHub Actionsのワークフロー構文で確認できます。
- [ ] ワークフローと再利用ワークフローから、退役対象のラベル指定を探す
- [ ] ブランチ、タグ、手動実行など、各ジョブの起動条件を記録する
- [ ] ビルド、テスト、アーカイブ、署名、公開のどこでラベルを使うかを対応付ける
- [ ] brownout の実施予定と対象時間帯を公告で確認し、検証の予定に反映する
- [ ] ジョブの所有者と、移行判断を行う責任者を決める
GitHub Actions の macOS 14 Runner はいつ退役しますか。 公式公告では2026年11月2日が退役予定日です。ただし、実際の切り替え日や brownout の予定が更新される可能性を考慮し、作業開始時と本番変更前に公告を再確認します。
切り替え前に、比較に使う現行環境を記録する
新旧 Runner の結果を比べるには、現行環境の記録が必要です。Xcode や SDK、依存関係の解決方法、キャッシュの設定、ビルド引数、テスト対象が分からないままでは、失敗の原因がコードなのか環境差なのか切り分けにくくなります。
Runner ラベルは環境全体の固定を意味しません。macOS のバージョン、アーキテクチャ、インストール済みソフトウェアは、公式のRunnerイメージ一覧と対象イメージの内容を見て確認します。macOS 15 や macOS 26 を候補にする場合は、それぞれのmacOS 15イメージ清單とmacOS 26イメージ清單で、試行時点のソフトウェア構成を確認してください。
- [ ] 現行ワークフローの Xcode、SDK、依存管理ツールとその指定方法を残す
- [ ] 使用するキャッシュキー、キャッシュ対象、依存関係の取得手順を記録する
- [ ] 代表的なビルドログ、テスト結果、生成物を確認する方法を保存する
- [ ] アーカイブや署名を含むリリース手順を、ビルド手順と分けて記録する
- [ ] 記録時点の Runner ラベルとイメージ情報を残し、比較の基準にする
キャッシュのキーや復元条件に変更がある場合は、ワークフローの都合で以前の依存物を再利用していないかも確認します。キャッシュの保存・復元条件はGitHub Actionsの依存関係キャッシュ資料を参照し、根拠なく全キャッシュを削除するのではなく、必要な範囲だけを変えて比較します。
候補ラベルを隔離して、差分を観察する
macOS 14 から macOS 15 または macOS 26 に移す前に、何を確かめますか。 まず公告が移行先として示すラベルを確認し、候補を本番ジョブと分離して実行します。ラベル名だけで OS、アーキテクチャ、Xcode のバージョンを決めつけず、公式イメージの一覧と実行ログを突き合わせます。
初回の試行は、独立したブランチか並行ジョブで行います。本番の runs-on を一括で置き換えると、複数の変更が同時に入り、失敗時に原因や戻すべき設定が分かりにくくなります。候補ラベルは、公告とイメージ一覧で現時点の利用可否を確かめてから設定してください。
- [ ] 独立したブランチ、または本番と分離したジョブを用意する
- [ ] 候補 Runner のラベルを、公告と公式イメージの記載に照らして確認する
- [ ] OS、アーキテクチャ、Xcode、SDK、インストール済みツールをログで照合する
- [ ] 現行ジョブと同じコミット、依存関係、ビルド条件で実行する
- [ ] 試行結果を現行のログ、テスト、成果物確認方法と比較する
托管 Runner はGitHubが提供・管理する実行環境です。各ラベルの詳細や利用条件はGitHub托管Runnerの資料を確認し、固定したい環境条件がある場合は、ラベルを指定するだけで満たせると判断しないことが重要です。
失敗の原因を分け、必要な変更だけを加える
候補 Runner でジョブが失敗した場合は、ログをもとに差分の所在を特定します。システムツール、依存関係の解決、キャッシュ、シェルスクリプトの前提、アーキテクチャ条件など、原因の候補を分けてから一つずつ修正し、同じ条件で再実行してください。
macOS 14 に結び付いた設定がすべて必要とは限りません。一方で、根拠のない古い依存関係への固定や、キャッシュ全消去を先に行うと、原因を隠したり別の差分を持ち込んだりすることがあります。ログで確認できた失敗と、その修正が対応しているかを記録します。
- [ ] エラーが発生した段階と、直前に使われたツールをログで特定する
- [ ] OSの機能、依存関係、キャッシュ、スクリプト、アーキテクチャのどれに関係するかを切り分ける
- [ ] 変更を小さく保ち、修正前後のログと結果を保存する
- [ ] 修正したジョブだけでなく、関連するテストや成果物確認も再実行する
- [ ] macOS 14 固有の設定を残す場合は、必要な理由を明記する
特定の Xcode や SDK を必要とする場合は、その要件をプロジェクトの設定と公式イメージのソフトウェア一覧で照合します。固定したい理由が「従来と同じだから」だけであれば、実際に必要なツールや機能を確認してから判断してください。
公開前に、ビルドから配布までの受け入れ条件を満たす
ビルド成功だけでは、リリース経路まで移行できたとは限りません。候補 Runner でプロジェクト本来のビルドと対象テストを行い、アーカイブ、署名、公開に関わる処理をそれぞれ確認します。生成物は、プロジェクトで使っている検査方法に沿って、種類や署名の状態などを確認してください。
- [ ] 実プロジェクトのビルドが完了し、期待する生成物を確認できる
- [ ] 対象テストが実行され、結果と失敗時のログを記録できる
- [ ] アーカイブと署名の工程が通り、後続処理に必要な成果物を確認できる
- [ ] リリース経路を本番公開と切り離した方法で検証できる
- [ ] ビルドの合格と公開経路の合格を、別々の判断として記録する
真機やGUIセッションが必要な工程は、托管 Runner で代替できるかを実際の要件に照らして確認します。リモート Mac を検討する場合も、Runner の代わりになると一括りにせず、既存ワークフローとの接続方法、運用責任、実機が必要な工程の扱いを確認します。
本番切り替えは責任者の承認後に行い、戻す条件も決める
移行の検証で合格とする基準は何ですか。 候補 Runner 上で実プロジェクトのビルドと必要なテストが通り、アーカイブ、署名、公開までの対象工程が確認できた状態です。担当者が結果を確認するまでは、macOS 14 の指定を本番から取り除かないでください。
受け入れ後に本番のラベルを切り替え、不要になった旧ラベルの設定を整理します。切り替え時には、対象ブランチ、実行ログの確認担当、失敗時の停止・復旧方法を明確にしてください。切り替え後に成果物や署名が受け入れ条件を満たさない場合は、公開を止め、原因調査と回帰の判断を先に行います。
- [ ] 受け入れ条件と結果を、開発担当・CI担当・リリース担当が確認する
- [ ] 本番変更の担当者と実施タイミングを決める
- [ ] ラベル変更後の最初の実行結果と生成物を確認する
- [ ] 失敗時に公開を止める条件と、設定を戻す手順を用意する
- [ ] 問題がないことを確認してから、旧ラベルへの依存を整理する
移行後も托管 Runner の更新に合わせて環境確認が必要です。固定した macOS 環境、継続して稼働するビルドノード、ホスト単位の制御が要件に含まれる場合は、托管 Runner の運用特性だけで満たせるかを再評価します。セルフホスト型 Runner の運用責任や管理範囲はGitHubの自ホストRunner資料も確認してください。
托管 Runner はワークフローに組み込みやすい一方、イメージの退役や更新に応じた確認が必要で、実行環境を継続して保持する用途とは要件が異なります。固定環境や継続稼働、より細かなホスト制御が優先されるなら、遠隔Mac CIも比較対象になります。RUVCLOUDの利用条件や費用は料金案内で確認し、実行時間や運用の要件に合う場合に限って利用プランを検討してください。