GitHub Actions Runner のバージョン切れ、どうする？2026年Macアップグレードチェックリスト

📋 目次

症状：Runnerはオンラインなのに、GitHub Actionsのジョブを受け付けない。
最速の対処：停止を待たず、更新経路を確認する。自動更新ノードは直ちに検証し、固定バージョンのノードは予備Macを用意してから段階更新します。

この記事は、個人開発者、小規模な開発チーム、制限ネットワークを管理するDevOps担当者、企業規模のRunnerプール運用者、そしてリリース責任者向けです。Macビルドノードを止められないなら、既存環境をいきなり上書きせず、隔離したMacで最小構成を検証してください。

最低バージョン実行の確認

GitHub Actions Runner のバージョン切れは、通常のワークフロー失敗とは扱いが異なります。コンパイルエラーやテスト失敗ならジョブは開始しますが、Runnerが実行対象の最低バージョンを満たさない場合、オンライン表示のままジョブを受け付けない可能性があります。

GitHubは2026年6月12日に、自ホストRunnerの最低バージョン実行に関する段階的な予定を公式告知しました。実際に対象となる範囲や適用時点は、最低バージョン実行の公式タイムラインと、アカウント内のRunnerダウンロード案内で確認してください。この記事の基準日は2026年8月26日です。

確認する対象は次の4つです。

個人、組織、Enterprise Cloudのどの管理階層に属するRunnerか
Runnerの自動更新が有効か、固定バージョン運用か
GitHubの管理画面に更新や実行要件の注記が出ていないか
Mac上のサービスログに更新失敗、接続失敗、ジョブ取得拒否が残っていないか

現行の利用可能バージョンは固定値として記事から転記せず、actions/runnerの公式リリース一覧とアカウント内の案内を同日に照合してください。検索結果や古いキャッシュに残ったバージョン番号を、現在の最低要件だと判断するのは危険です。

規模別の更新判断

個人開発者：単一ノードの保全

Macが1台しかない場合は、最初にRunnerのラベル、サービス状態、作業ディレクトリ、Xcode、証明書、キーチェーン、環境変数の復元情報を保存します。トークンそのものをログやバックアップへ平文で残さず、必要なら登録手順を安全な保管場所に記録してください。

更新中に唯一のMacが使えなくなると、ビルドだけでなく署名確認やリリース準備も止まります。短時間の作業でも、臨時のホスト環境または隔離したリモートMacを先に確保し、次の順で検証します。

予備MacへRunnerを登録する。
本番と同じラベルを設定する。
テスト用ワークフローでジョブの振り分けを確認する。
実際のプロジェクトをビルドする。
Macを再起動し、Runnerサービスが自動復旧するか確認する。

登録だけ成功しても合格ではありません。ラベルが違えばジョブは別ノードへ流れ、キーチェーンや署名設定が欠けていれば、テスト後のアーカイブで止まります。

小規模チーム：共有環境の段階更新

複数リポジトリが1台または少数のMacを共有している場合、固定ラベルだけでなく、Xcodeのバージョン、依存キャッシュ、証明書、プロビジョニングプロファイル、ローカルスクリプトを棚卸しします。特に、同じMac上でテストと配布を行う構成では、更新後の環境差が署名処理に現れやすくなります。

最初の更新対象は、リリース直前ではない低リスクのリポジトリに限定します。更新前後で次の証拠を保存してください。

Runnerのバージョンとサービス状態
ジョブの取得から完了までのログ
テスト結果と生成されたビルド成果物
署名、アーカイブ、配布処理の結果
予備ノードへ切り替える演習の記録

低リスクのリポジトリが通った後に、リリース系ワークフローを移します。普通のテストだけ成功し、署名やアーカイブが失敗しているなら、更新完了とは判定しません。

固定版・制限ネットワーク：更新責任の分離

自動更新を停止しているMacでは、オンライン状態を保つだけでは不十分です。更新サービスへの接続、プロキシ設定、パッケージの入手元、ファイルの検証情報、サービスアカウントの権限、ログ保存先を個別に確認します。

Runnerの監視と障害調査については、GitHub公式の監視・トラブルシューティング手順に沿って、管理画面とMac側ログを照合してください。ネットワーク制限が原因でも、TLS検証を無効にして通す方法を常用してはいけません。例外的に変更した場合は、変更理由、対象時間、復元方法、影響範囲を記録します。

企業ノードプール：分割と監査

企業のMac Runnerは、全台一括更新ではなく、管理責任と用途で分けます。まずRunnerグループ、CPUアーキテクチャ、ラベル、接続可能なリポジトリ、現在のバージョン、最終ジョブ時刻を一覧化します。管理画面での一覧確認に加え、必要なら自ホストRunner REST APIの公式仕様を使って棚卸しを自動化できます。

最初の対象は、リリースを担当しない非重要ノードです。登録、ジョブ取得、失敗率、成果物、公開経路を観察し、問題がなければ低リスクのノード群へ広げます。停止条件は、ジョブ取得の拒否、署名失敗、成果物の差異、サービスの再起動失敗、ログ欠落のいずれかです。

短期間だけ使うノードは、更新よりも新規作成と廃棄の手順を整えた方が管理しやすい場合があります。長期稼働ノードは定期点検と切り戻し情報を残し、自動拡張するノードは新規作成時に最低バージョンを満たすイメージを使います。運用形態を分けず、同じ更新手順を全ノードへ適用するのは避けてください。

更新方式の判定リスト

次の条件で、更新を続行するか、いったん止めるかを決めてください。

[ ] GitHub公式告知とアカウント内のダウンロード案内を確認した
[ ] 対象Runnerの管理階層、ラベル、アーキテクチャ、現在版を記録した
[ ] 自動更新の有無と、制限ネットワークやプロキシの影響を確認した
[ ] 作業ディレクトリ、サービス設定、証明書、キーチェーン、環境変数を復元可能にした
[ ] 予備Macまたは隔離ノードで登録とラベル振り分けを確認した
[ ] 実プロジェクトのビルド、テスト、署名、アーカイブを完了した
[ ] 再起動後にサービスが復旧し、次のジョブを取得した
[ ] 予備ノードへの切り替え演習と、切り戻し手順を記録した

すべて確認できた場合だけ、低リスクのリポジトリから段階展開します。署名、アーカイブ、再起動復旧のどれかが未確認なら、更新を止めて予備ノードの検証を続けてください。

更新前後の実行手順

作業は、次の順序で進めると停止範囲を限定できます。

GitHubの公式告知、管理画面、アカウント内のダウンロード案内を確認します。
対象Macのラベル、権限、サービス設定、作業パス、署名環境を保存します。
予備Macまたは隔離ノードへ最小構成のRunnerを登録します。
runs-on のラベルが意図したノードへ解決されることを確認します。
実プロジェクトでビルド、テスト、署名、アーカイブを実行します。
Macを再起動し、Runnerサービスと必要な補助サービスの復旧を確認します。
ログ、成果物、実行時間、失敗内容を更新前と比較します。
停止条件に触れなければ、低リスク、通常系、リリース系の順に段階展開します。

コマンドを使う場合も、組織名、リポジトリ名、トークン、ユーザー名、パスは実値を記事や共有ログへ書かず、次のような置換値で管理します。

./config.sh --url https://github.com/<ORG>/<REPOSITORY> --token <REGISTRATION_TOKEN>
./run.sh

サービスの登録方法やMac上のパスは、使用しているRunnerの配布形態と公式ドキュメントの現行記述に合わせてください。自ホストRunnerの公式ドキュメントと、実機ログを優先し、過去記事のサービスパスをそのまま流用しないことが重要です。

切り戻しと合格判定

更新に失敗した場合、旧ディレクトリを急いで上書きしたり、登録トークンを再利用したりせず、まずジョブを検証済みの予備Macへ切り替えます。旧環境を復元する場合は、Runnerのバージョンだけでなく、Xcode、証明書、キーチェーン、依存キャッシュ、環境変数も同時に確認します。

判定は「Runnerがオンラインか」ではなく、次の4条件で行います。

ジョブが正しいラベルへ割り当てられる
実プロジェクトのビルドとテストが完了する
署名とアーカイブが再現できる
再起動後にサービスが復旧し、次のジョブを取得する

この条件を満たせない場合は、現行Macへの再試行を止め、予備ノードの増設またはノード再構築へ切り替えます。Mac CIのバックアップと再構築を設計するなら、Mac miniのレンタル構成ガイドで、必要な利用期間と運用形態も合わせて確認できます。

FAQ

自ホストRunnerの現在版を確認する方法

管理画面の表示だけでなく、Mac上のRunnerログとアカウント内の配布案内を照合します。登録階層によって確認場所が異なるため、リポジトリ、組織、Enterprise Cloudのどこで管理されているかを先に特定してください。

自動更新を無効にした場合の更新方針

固定版のMacは、更新パッケージの入手、検証、サービス権限、再起動復旧を自分で管理します。更新前に予備ノードを用意し、隔離環境で実ビルドを通してから本番へ反映します。

オンラインなのにジョブを受け取れない理由

接続状態と実行要件は別です。最低バージョンの対象になったRunnerは、管理画面上でオンラインでもジョブを受け付けない可能性があるため、公式注記とログを確認します。

更新失敗時の安全な復旧方法

最初に予備Macへジョブを切り替え、旧環境の復元情報を確認します。サービスだけ戻して終わりにせず、実ビルド、署名、アーカイブ、再起動後のジョブ取得まで検証してください。

MacDateを使う場合の切り替え判断

自前のMac miniを本番ノードにすると、機器の購入、保守、設置場所、障害時の交換、更新中の容量不足を自分で抱えることになります。単一ノードでは代替機の準備も難しく、固定版や制限ネットワークの運用では更新作業の責任が一人に集中します。

既存Macを止められない期間だけ、隔離したMacDateの環境へ最小構成を複製する方法なら、登録、ラベル、Xcodeビルド、署名、再起動復旧を先に確認できます。長期の安定した高負荷運用や物理USB機器が必須なら自前機が適しますが、更新前の待避、短期の増設、リリース前の検証環境が目的なら、MacDateの日本語サービス案内を候補に加えると、既存のMac Runnerを無理に上書きせずに切り替え演習を行えます。