GitHub Actions、2.329.0未満のセルフホストランナーをブロック

GitHubは2026年9月29日、セルフホスト型のActionsランナーに対する最低バージョン規則の全面適用を始めました。GitHubの変更履歴の投稿で、日付は9月25日から変更されました。バージョン2.329.0より古いランナーは、GitHub Enterprise Cloudに登録できなくなりました。すでに登録済みの古いランナーは、ジョブを受け取らなくなります。

セルフホストランナーとは、GitHubがホストするマシンを使う代わりに、チームが自前のマシンにインストールしてGitHub Actionsのワークフローを実行する小さなプログラムです。チームは特殊なハードウェア、プライベートネットワーク、あるいはコスト削減のためにこれを使います。一度インストールしたきり更新していないランナーが、コードを一切変えていないのに、CIパイプライン（自動のビルドとテストの仕組み）を止めてしまうおそれが出てきました。

2つのバージョン規則

2026年6月12日のGitHubのスケジュール告知によると、2つの別々の制限があります。

規則	求められること	満たさない場合
登録	ランナーのバージョンが2.329.0以降	ランナーは登録も再登録もできない
ジョブの実行	新しいランナーのリリースを、それぞれ公開から30日以内にインストールする	すでに登録済みでも、ランナーはジョブを実行しなくなる

2つのうち、ジョブの規則のほうが厳しいものです。その最低バージョンは登録の最低ラインより上にあり、しかも動き続けます。ランナーは登録できるほど新しくても、ワークフローを実行するには古すぎることがあります。

影響を受けるのは誰か

この規則の対象は、GitHub.comと、GitHubの企業向けホスト型サービスであるGitHub Enterprise Cloudです。データを選んだ地域に保管するエディション、データレジデンシー付きのGitHub Enterprise Cloudでは、2026年7月31日から適用されています。企業が自社のサーバーにインストールする製品、GitHub Enterprise Serverは影響を受けません。

導入までの経緯

GitHubは6月にスケジュールを公開し、その後ブラウンアウトを実施しました。ブラウンアウトとは、短時間の計画的な遮断です。古いランナーを数時間止め、本当の期限の前に持ち主に気付いてもらうためのものです。

Enterprise Cloudでは、ブラウンアウトは決められた日の米東部時間の午前11時から午後3時に行われました。6月の告知によると、その範囲は毎週広がりました。

週	ブラウンアウトの日	遮断されたもの
1	8月24日	登録
2	8月31日、9月2日	登録
3	9月7日、9日、11日	登録とジョブの実行
4	9月14日、16日、18日	登録とジョブの実行

この規則の背景にはインフラがあります。DevOps.comの報道によると、GitHubは2024年初めにActionsを支えるバックエンドサービスの再構築を始めました。新しい基盤は1日に1億2,000万件を超えるジョブを処理します。企業は1分あたり、以前の7倍のジョブを開始できるようにもなりました。DevOps.comによれば、ランナーのバージョンを強制することで、すべてのランナーが新しい基盤で動くことが保証され、この移行が完了します。

ランナーの確認方法

GitHubの9月28日の投稿は、ランナーのバージョン廃止に関するREST APIも追加しています。このAPIは、ランナーの各バージョンについて、登録と実行の廃止日を返します。チームはこれを使えば、失敗したジョブで知るのではなく、次の期限が近づくのを前もって確認できます。

GitHubの6月の告知によると、自動更新をオンにしたランナーは、それだけで30日の規則を満たします。誰かが手動でアップグレードしているランナーは、期限内にとどまるために定期的な更新計画が必要です。

これは開発者にとって何を意味するか

ビルドが失敗する前に、今日すべてのセルフホストランナーを確認してください。各ランナーと、それぞれが報告するバージョンの一覧を作り、2.329.0未満のものから先にアップグレードしてください。それらのマシンは、すでに登録から締め出されています。

次に、各ランナーがどのように更新を受け取っているかを確認してください。仮想マシンのイメージやコンテナイメージに組み込まれたランナーは、よくある落とし穴です。それらはイメージに固定されたバージョンのまま起動します。チームはビルドの再現性を保つために、自動更新をオフにすることがよくあります。30日の期限の下では、そのイメージを少なくとも月に1回は作り直す必要があります。

この規則は一度きりの移行ではなく、恒久的なものとして扱ってください。新しいランナーのリリースが出るたびに、新たな30日のカウントが始まります。ランナーのバージョンをオペレーティングシステムと同じパッチ手順に組み込み、廃止APIを監視の仕組みにつないでください。

静かになったランナーに注意してください。この規則ができる前は、動いていないランナーはたいていマシンの故障を意味していました。今では、GitHubが単にジョブを送るのをやめただけかもしれません。