GitHubの告知では、macOS-14、macOS-14-large、macOS-14-xlargeのRunnerラベルが2026年11月2日に廃止されます。公式告知に期限が示されているため、今週は候補Runnerを決め、実際のリリースワークフローを隔離環境で検証してください。合格したジョブから段階的に切り替え、戻し方も先に確保します。
このガイドは、GitHub ActionsのiOSリリース流水線を管理するIT・プラットフォーム担当者向けです。
Xcode、アーカイブ、署名を確認するリリースエンジニアにも役立ちます。
Mac CIの予算と容量を判断する技術管理者は、代替Macが必要なジョブの切り分けに使えます。
最終更新：2026年10月26日。退役日と対象ラベルはGitHubの退役告知で確認しています。Runnerの選択肢は公式のRunner選択ガイドとRunnerイメージのリポジトリも照合してください。実際のXcode、OS、署名結果は、チームのワークフローログで再確認が必要です。
退役前は現状維持より、リリース基準の記録を優先する
移行の出発点は、ラベルを一括置換することではありません。リリースを止めずに比較できるよう、現在の成功条件を一つの実ワークフローから記録します。組織全体のラベル棚卸しやBrownout時の障害対応ではなく、既存iOSリリースを新環境で成立させるための準備に絞ります。
次の項目を、成功したリリース実行のログや設定から保存します。
- [ ] ワークフローで指定しているRunnerラベルと、実行ログに出た実際の環境を記録する
- [ ] 使用されたXcodeとビルド設定、依存関係の解決結果を記録する
- [ ] ビルド、テスト、アーカイブで確認する成果物と合否条件を明文化する
- [ ] 署名、書き出し、アップロードまでの手順と、リリースを止める条件を確認する
- [ ] 本番の署名資格情報を使うジョブと、検証用ジョブを区別する
この基準がないままRunnerを変えると、成功・失敗の原因がOSなのか、Xcodeなのか、依存関係なのか判別しにくくなります。成果物と署名結果を比較対象に含め、ログだけで合格としないのが要点です。
Runnerのラベル変更と、実環境の互換性確認は分ける
macOS-15やmacOS-26を候補にする場合も、ラベルが選べることはアプリの互換性を保証しません。GitHubが示す代替ラベルは候補として扱い、各プロジェクトのOS要件、アーキテクチャ、Xcode要件と照合します。Xcodeごとの対応OSはAppleのシステム要件で確認してください。
RunnerのOS、CPUアーキテクチャ、導入されたXcodeは、それぞれ別に確認する情報です。Runnerイメージの更新情報と実行ログの両方を照らし合わせ、指定したXcodeが実際に選択されたかも確認します。古い依存関係やビルドスクリプトが新しい環境で動くかは、タグ名から推測せず、対象プロジェクトで試します。
優先順位はジョブの影響範囲で決めます。通常ビルドとテストは、実行条件を固定して比較しやすいものから検証します。正式署名や公開を行うジョブは、資格情報の保護と承認経路を確認してから別段階で扱います。
本番切替の前に、隔離ワークフローで同じリリースを再現する
候補Runnerは、非本番ブランチまたは隔離したワークフローで試します。変更するのはRunnerだけではなく、依存関係やスクリプトの差分もログに残します。移行前と同じコミット、同じビルド設定を使えば、差が出た場所を絞り込めます。
- [ ] 新しいRunnerラベルでジョブが起動し、想定したOSとアーキテクチャがログに記録される
- [ ] 指定したXcodeが選ばれ、依存関係の解決とビルドが完了する
- [ ] 必要なテストを実行し、失敗の有無とログを比較する
- [ ] アーカイブを生成し、書き出した成果物を検証する
- [ ] 署名とアップロードを、許可された資格情報と経路で確認する
署名の検証では、アーカイブ生成だけで判断しないでください。Appleの配布用署名とコード署名の資料を参照し、プロジェクトの配布方法に合う検証手順を組み立てます。隔離ジョブに本番資格情報を渡さない設計は、GitHubの安全な利用に関するガイドとも照合します。
よくある移行判断は、ラベルではなくログと合否条件で決める
廃止前に先に直すワークフロー
対象のmacOS-14 Runnerを使っているリリース経路から、ビルド、アーカイブ、署名、アップロードの実行記録を集めます。正式公開に直結するものを特定し、隔離検証、承認、回退の担当者と条件を決めてから変更します。単なるラベル検索だけで、ジョブの重要度や公開経路を判断しないようにします。
macOS-15またはmacOS-26でのXcode検証
候補ラベルの現行イメージとXcodeの対応条件を確認し、実行ログでOS、アーキテクチャ、選択されたXcodeを記録します。同じコミットと設定でビルド・テストを行い、成果物と失敗ログを比較してください。候補の利用可否やイメージ内容が変わる場合は、公式情報を改めて確認します。
公開前のアーカイブ・署名・アップロード確認
本番と同じ処理順でアーカイブを作り、配布用の署名を検証し、アップロードまで到達するか確かめます。公開先への影響を避けるため、検証用資格情報や承認ゲートを用意し、本番公開の実行条件と分けて合否を記録します。環境保護ルールはGitHubのデプロイ環境に関する説明を参照してください。
失敗時の回退と代替Mac
切替後の失敗で公開が止まる条件、検証済みRunnerへ戻す手順、切替を中断する担当者をあらかじめ定めます。macOS-14ラベルを将来の回退先として当てにするのではなく、別の対応済みRunnerへ戻す設計にします。必須ジョブが候補環境で通らない場合は、必要なOS、署名権限、接続先、稼働条件を整理し、代替Macの要件として評価します。
合格したジョブから段階的に本番へ移す
一度に全ワークフローを切り替えると、失敗時に原因と影響範囲の切り分けが難しくなります。隔離検証を通過し、回退手順を実行できるジョブから本番に進めます。リリースに直結するジョブを切り替える際は、承認と公開停止条件も合わせて確認します。
各段階で、Runnerラベルと実行ログの環境が一致しているかを確認してください。同時実行による競合があるワークフローでは、GitHubの並行実行制御の説明を参照し、同じリリースが意図せず重複しないよう設計します。
- [ ] 検証済みジョブだけを本番へ進め、対象コミットと実行結果を記録する
- [ ] 公開停止条件と、切替を取り消す担当者を明確にする
- [ ] 各実行でRunnerラベル、実環境、Xcode、成果物を確認する
- [ ] 失敗した場合は原因を記録し、検証済みの回退先へ戻す
- [ ] 次のジョブへ広げる前に、署名と公開経路の合格を確認する
代替Macは、候補Runnerで通らないジョブの要件が固まってから選ぶ
代替Macの検討は、Runner移行に失敗したからという理由だけで始めず、通らないジョブの要件を特定してから行います。必要なmacOS、Xcode、アーキテクチャ、署名資格情報へのアクセス、ネットワーク接続、停止時の対応を整理してください。これらを満たすか実ジョブで確認できない環境は、リリース用の承継先として合格にできません。
GitHubのホストRunnerで続ける場合は、ラベルとイメージの更新を追い、ワークフロー側で実環境を記録する運用が必要です。Macを自社で保有する場合は、調達に加え、保守、更新、アクセス管理を自社で担うことになります。リモートMacのレンタルは実機を使う選択肢ですが、必要な権限、接続条件、利用条件を実ワークフローで確認し、期待した受入れ条件に合うか判断してください。
MESHLAUNCHのリモートMacを候補に含める場合も、説明だけで本番適合と判断せず、実際のリリースタスクで環境、署名、接続、復旧手順を検証してから決めます。提供内容の確認にはMESHLAUNCHの案内を参照し、調達先の条件が合うかは日本向けMac miniの案内で最新情報を確認してください。候補Runnerの互換性が確認でき、予備Macに求める条件も実証できた段階で、必要なリリースだけをレンタル環境に承継するのが安全です。