判定：適合します。 2026年10月8日時点で、GitHub Enterprise Cloudの自ホストRunnerに対するバージョン強制適用は始まっています。登録時の最低バージョンと、実行中Runnerの退役状況を別々に確認し、段階更新したうえで実際のMac CIジョブを通してください。固定バージョンのままにしたり、自動更新を止めたままにしたりする運用は、継続的な適合を保証しません。適用日と対象範囲はGitHubの強制適用に関する公式告知で確認できます。
対象読者：GitHub ActionsのmacOS Runner群を管理し、ノードの状況確認や更新が必要な企業IT担当者。
iOS/macOS CI基盤を担当し、Runnerのジョブ受け付けとビルド結果を確かめたいプラットフォームエンジニア。
組織のRunnerバージョン監視と保守手順を整えたい技術責任者。
最終更新：2026年10月8日。GitHubの公式告知、自ホストRunnerの管理文書、およびバージョン退役REST APIを参照しています。
00適用範囲と二つの判定基準
今回の変更では、「Runnerを登録できるか」と「登録済みRunnerがワークフローを実行できるか」を分けて判断します。GitHub Enterprise Cloudでは、2026年9月29日にバージョン強制適用が始まり、バージョン2.329.0未満のRunnerは新規登録または再登録ができません。公式告知が示す登録要件を、稼働中のRunnerに適用される恒久的な最低実行バージョンと取り違えないでください。
帯域外のGitHub Enterprise Cloud（データレジデンシー対応）は、公式告知で2026年7月31日から強制適用の対象とされています。一方、GitHub Enterprise Serverはこの告知の対象外です。自社環境のエディションと適用範囲を先に確認し、個別の状態は告知と退役APIの最新情報に照らして判断してください。
Runner 2.329.0は登録と実行の共通最低バージョンですか？
いいえ。2.329.0は、該当するGitHub Enterprise Cloudで新規登録・再登録を行うための基準です。実行中のRunnerについては、新しいRunnerの公開に伴って実行サポートの条件が変わるため、特定のバージョンを長期的な実行最低値として固定できません。Runnerのバージョン退役REST APIで対象バージョンの状態を確認してください。
「オンライン」と表示されていることも、更新要件を満たし、実際にジョブを受け付けられることの証明にはなりません。監視画面の状態に加え、バージョンの適合性と実ジョブの完了を別の判定項目として管理します。
01更新前の棚卸しと退役確認
まず、リポジトリ、組織、企業の各スコープにあるmacOS Runnerを一覧化します。Runner名、バージョン、オンライン状態、稼働中か待機中か、登録スコープ、担当するワークフロー、更新方式を記録し、更新対象と影響するiOS CI/CDの経路を結び付けます。管理画面と運用ログの確認には、GitHubの自ホストRunner管理ガイドが利用できます。
次に、バージョン退役APIから登録と実行のサポート状況を調べ、結果を棚卸し表に反映します。オンライン状態だけで「更新不要」と判断せず、登録要件と実行サポートの期限を個別に記録してください。
古いGitHub Actions Runnerは実行できなくなりますか？
古いバージョンが直ちにすべての環境で実行停止になる、と一律には言えません。登録可否と、実行中Runnerのサポート状況は異なる条件で判定されます。対象バージョンの退役状態をAPIで確認し、保守対象外となる期限が示されている場合は、その前に更新計画へ組み込みます。
自ホストRunnerの退役日はどこで確認できますか？
GitHubのRunnerバージョン退役REST APIを使い、該当するバージョンの登録・実行に関する状態を確認します。APIの結果を資産台帳のRunnerバージョンと照合し、確認日と判定結果も残してください。手元のRunner名だけで退役日を推測したり、古い記録を流用したりしないことが重要です。
02更新経路の選択と判断
更新方法は、Runnerをどう配備しているかで分けます。各方式の長所だけでなく、更新が止まる要因と、再作成時に旧バージョンが戻る経路も確認してください。
| 管理方式 | 選択しやすい条件 | 更新前に確認する点 |
|---|---|---|
| 自動更新を利用 | 更新サービスへ接続でき、更新後の動作を監視できる | 通信制限、更新失敗の通知、更新後の実ジョブ |
| 自動更新を無効化して手動保守 | バージョン固定や変更承認を優先する | 定期更新の担当、退役前の期限管理、切り戻し手順 |
| イメージ・コンテナ・自動化で配備 | ノードをテンプレートから再作成する | インストールスクリプト、基底イメージ、キャッシュに残るRunnerの版 |
GitHubの自ホストRunner更新に関する公式文書を基準に、自動更新の設定と運用条件を照合します。自動更新を無効にしている場合は、台帳と退役APIを定期的に確認する手順、更新担当、更新できない場合の切り戻し条件を明文化します。
自動更新を止めたRunnerはどう保守しますか？
自動更新を止めたままにする場合、担当者による更新サイクルを別途設け、退役前に新しいRunnerへ入れ替えられる仕組みが必要です。更新日だけでなく、更新後に対象ワークフローが成功した証拠も保管します。保守予定が空欄のRunnerや、担当が不明なRunnerは、更新済みとみなさず優先的に確認してください。
注意： 更新したRunnerが稼働していても、次回のノード作成で古いバージョンに戻る場合があります。インストールスクリプト、基底イメージ、コンテナイメージ、キャッシュされたテンプレートを一緒に点検し、置き換えたノードにも更新済みバージョンが反映されることを確かめます。
03段階更新とMac CIの受け入れ
一括更新ではなく、影響を限定できる非重要ノードから試行し、結果を見て残りのビルドプールへ広げます。更新作業は次の順で進めます。
- [ ] 対象Runnerの登録範囲、利用ワークフロー、バージョン、更新方式を台帳と照合する。
- [ ] APIで登録と実行のサポート状況を確認し、退役対象または期限が近いノードを特定する。
- [ ] 自動更新ノードは更新サービスへの接続と更新結果を確認する。手動保守ノードは更新手順と切り戻し条件を準備する。
- [ ] 非重要ノードで更新を試し、Runnerが対象ジョブを受け付けることを確認してから、段階的に対象を広げる。
- [ ] 実際のiOS CI/CDワークフローを実行し、必要なツールチェーン、ビルド、テストの完了を確認する。
- [ ] 署名やリリースを担うノードでは、それらの権限とエンドツーエンドの処理結果を別途確かめ、ログを保存する。
更新後の検証では、Runnerが接続中という表示だけで受け入れを完了しないでください。ジョブが割り当てられない、キューに残る、実行途中で失敗する場合は、更新状態、Runnerログ、ワークフローの実行記録を照合します。GitHubの監視・トラブルシューティング文書も参照し、原因と復旧判断の証拠を残してください。
04継続運用に組み込む更新管理
バージョン退役の確認を、臨時の対応で終わらせず定期保守に組み込みます。資産台帳と退役APIの情報を照合し、対象バージョン、確認日、更新担当、更新期限を記録します。GitHubが適用日や更新ルールを変更した場合も、監視条件と手順を見直します。
運用チェックリスト
- [ ] 登録バージョンの基準と、実行バージョンの退役状況を別々に管理している。
- [ ] Runnerのスコープ、バージョン、稼働状態、用途、更新方式を台帳で追跡できる。
- [ ] イメージや自動化から旧バージョンが再投入されないことを確認している。
- [ ] 更新失敗、更新サービスへの接続不可、ジョブの滞留や失敗について、担当と切り戻し条件が決まっている。
- [ ] 更新後の実ジョブ結果と、署名・リリースの検証記録を保管している。
Runner群を自社で維持する方式は、構成やネットワークを細かく管理できる反面、更新作業、ハードウェアの調達・維持、故障時の代替手段を社内で担う必要があります。更新中だけMacの構築枠を増やしたい場合や、移行期間の容量を補いたい場合は、NUKCLOUDのサービス案内でリモートMac環境を確認し、自社運用との適合性を比較できます。
長期にわたり固定負荷を処理する環境や、物理機器への直接接続が必要なワークロードでは、自社でMacを保有するほうが適する場合があります。一方、更新時の一時的な増枠やCI環境の評価では、保有端末の調達・保守負担を避けられるレンタルが候補になります。必要な期間と作業内容が明確になったら、日本向けのリモートMac利用案内を確認し、実ジョブでの受け入れを前提に検討してください。