セルフホストRunnerが9月25日に停止も、古いイメージを棚卸し

GitHub Enterprise Cloudでは2026年9月25日からバージョン要件が完全適用され、要件を満たさないセルフホストRunnerはジョブを実行できなくなる。回避するには、稼働中のRunnerを最新版へ更新するだけでなく、コンテナイメージ、VMテンプレート、インストールスクリプト、自動構築経路から古い版を除く必要がある。

標準の自動更新を使う常設Runnerは、更新サービスへの到達と更新完了をログで確かめる。--disableupdateを指定したRunnerや、コンテナから生成するエフェメラルRunnerは、更新済みイメージを作成して限定展開し、検証ジョブの成功後に本番の生成元を切り替える。

期限と停止条件を切り分ける

GitHubの適用スケジュール では、GitHub Enterprise Cloudの完全適用日は2026年9月25日とされている。登録時の最低要件はバージョン2.329.0以上だが、これはジョブ実行時の固定された最低版ではない。既存Runnerも各リリースの公開後30日以内に更新しなければならず、実行要件を下回るとジョブを処理できない。

完全適用前の停止試験では、9月7日と11日に古いRunnerの登録が一時的に遮断され、9月9日には登録とジョブ実行の両方が対象となる。9月14日、16日、18日には両方を遮断する試験が予定されている。対象はGitHub Enterprise Cloud上の要件外Runnerであり、GitHub Enterprise Serverは今回の適用対象ではない。

Runnerと生成元を一つの台帳にする

棚卸しは、リポジトリ、Organization、Enterpriseの各階層に登録されたRunnerから始める。Runner名、適用範囲、ラベル、OS、アーキテクチャ、現在のバージョン、常設かエフェメラルか、自動更新の設定、生成元、管理担当を同じ台帳に記録する。

Enterprise Cloudの監査ログでは、org.register_self_hosted_runner、repo.register_self_hosted_runner、enterprise.register_self_hosted_runnerの各イベントから、登録時のRunnerバージョンを確認できる。ただし、イベントが記録されるのは登録時であり、監査ログだけでは接続済みRunnerの完全な在庫表にならない。

そのため、Runner一覧をクラウド資産、仮想化基盤、Kubernetesの設定、構成管理リポジトリと照合する。停止中のVM、災害復旧用テンプレート、キャッシュされたイメージ、必要時だけ起動するRunnerも対象に含める。稼働個体が新しくても、その生成元に古いパッケージが残っていれば再発条件は消えていない。

更新経路ごとに入れ替える

セルフホストRunnerの公式仕様 によれば、標準設定ではRunnerアプリケーションが自動更新される。--disableupdateで自動更新を止めた場合は、新版の公開から30日以内に手動更新が必要で、メジャー、マイナー、パッチのすべてが対象となる。重大なセキュリティ更新では30日を待たず、更新されるまでジョブがキューに入らない場合がある。

常設Runnerの自動更新を使う場合は、更新先へ通信できることと、更新後のプロセスが新しいバイナリで再開したことを確認する。手動更新する常設Runnerは、一台ずつジョブの割り当てから外し、実行中ジョブがなくなってからサービスを停止する。更新、再接続、検証ジョブの順に確認し、成功した個体を戻してから次へ進む。

コンテナやVMからRunnerを生成する環境では、稼働個体ではなく生成元を先に修正する。手順は次の通りだ。

1. Dockerfile、Packer定義、cloud-init、構成管理、起動スクリプトを検索し、Runnerのバージョン、ダウンロードURL、チェックサム、ベースイメージを固定している箇所を特定する。
2. 対象OSとアーキテクチャに対応する公式パッケージへ更新し、配布元が提示するチェックサムをビルド定義へ反映する。
3. 更新済みイメージを新しい識別子で作成し、ソースのコミットとRunner版を追跡できるようにする。既存タグは検証前に上書きしない。
4. 限定ラベルまたは検証用Runnerグループへ少数展開し、合格後に本番の起動テンプレートやデプロイ設定を切り替える。
5. 古い自動スケーリング設定、キャッシュ、災害復旧テンプレートを生成経路から外す。ロールバック用に保存する場合も、新規Runnerを起動できない状態にする。

ログで更新完了を確認する

GitHub上のOnlineやIdleは接続状態を示すもので、更新成功の証明にはならない。Runnerの監視手順 では、インストール先の_diagディレクトリにあるRunner_ログとSelfUpdateログで自動更新の動作を確認できる。Runnerアプリケーションの自動更新には、OSやほかのソフトウェアの更新は含まれない。

ログでは、更新の検出、取得、展開、プロセスの再起動、GitHubへの再接続を時系列で追う。プロキシや許可リストを使う環境では、更新用エンドポイントへの通信失敗も確認する。更新後のプロセスが報告するバージョンを台帳へ戻せば、設定上の予定ではなく稼働実態を記録できる。

エフェメラルRunnerの診断ログは個体の破棄とともに失われるため、検証前に外部ストレージへ転送する。ログにはイメージの識別子、Runner版、対象ラベルを関連付け、どの生成元から作られた個体がどのジョブを処理したか追跡できるようにする。

新しい生成元から検証する

検証ジョブは接続確認だけで終えず、実際のワークフローが使う経路を小さく再現する。対象ラベルを明示し、リポジトリのチェックアウト、必要なランタイムの起動、Artifactまたはキャッシュの読み書き、コンテナの利用、社内パッケージレジストリへの接続を必要な範囲で確認する。資格情報は検証専用の最小権限とし、本番デプロイは実行しない。

合格条件は、新しいイメージから生成したRunnerへジョブが割り当てられ、想定した処理を完了し、更新や通信のエラーが診断ログに残らないことだ。エフェメラルRunnerでは、一つのジョブを処理した後に登録が解除され、運用側の自動化によって個体が破棄されることも確認する。

OS、アーキテクチャ、ネットワーク区画、Runnerラベルが異なる場合は、組み合わせごとに検証する。最後に生成元からもう一度Runnerを作り直し、期待する版で登録されて同じ検証を通過するか確かめる。これにより、手作業で直した個体だけでなく、将来の増設や障害復旧でも古いRunnerが再生成されない状態を確認できる。