GitHub Actions：セルフホストランナーのバージョン強制適用スケジュールについて
GitHub は、自ホストランナーのアーキテクチャ移行完了に伴い、2026 年までにバージョン要件を厳格化し、古いバージョンの使用停止と定期的なアップデート義務を課す方針を発表した。
キーポイント
新プラットフォームへの移行背景
信頼性と可用性向上のためバックエンドを再設計し、日次ジョブ実行数が 1.2 億件以上（旧来の 3 倍）に増加した結果、互換性のない旧バージョンランナーのサポートを終了する。
必須となる二つの要件
登録にはバージョン 2.329.0 以上が必要であり、ジョブ実行を継続するには新リリース公開から 30 日以内にアップデートを行うことが義務付けられる（自動更新有効なら自動対応）。
厳格化のタイムラインと段階的実施
2026 年 7 月 31 日（Data Residency 版）および 9 月 25 日（通常版）に完全施行され、それまでに登録やジョブ実行を断続的にブロックする「ブラウンアウト」が実施される。
セキュリティ更新時の即時対応
重大なセキュリティアップデートが公開された場合、適用されるまで即座にジョブキューイングが一時停止され、運用上のリスク管理が強化される。
登録と実行の段階的制限
最低バージョン未満のランナーは登録できなくなり、さらに高いバージョン要件を満たさない場合、既存ランナーもジョブの実行を停止します。
事前通知と監査機能の提供
強制実施前に、古くなったランナーでの実行時に注釈が表示され、REST API を通じてバージョン情報を取得してアップグレード計画を立てることが可能になります。
監査ログの限界と大規模環境への対応
監査ログイベントは登録時に記録されるため、接続中のランナーの完全なインベントリにはならない。大規模なファームでは UI ではなく監査ログ REST API をクエリして確認する必要がある。
影響分析・編集コメントを表示
影響分析
この発表は、GitHub Actions の基盤インフラを刷新した結果として、運用上の保守責任をユーザー側に明確に転嫁する重要な転換点です。企業や開発チームは、自ホストランナーの管理プロセスを見直し、自動更新の徹底や定期的な手動アップグレード体制を構築する必要が生じます。これにより、プラットフォーム全体の安定性とセキュリティが向上する一方で、運用負荷の増大という課題も発生します。
編集コメント
インフラの刷新に伴う必然的な措置ですが、30 日という猶予期間と自動更新の有無による運用差は、各組織の管理体制を問われる重要なポイントです。
GitHub Actions は、github.com およびデータ居住性を備えた GitHub Enterprise Cloud におけるセルフホストランナーのバージョン要件の適用を再開します。この変更は、信頼性と可用性を高めるために GitHub Actions のコア部分を再構築するというより広範な取り組みの一環です。2024 年初頭、Actions チームはジョブ実行とランナー通信を支えるバックエンドサービスの再設計を開始しました。これは、顧客が依存する信頼性、可用性、およびパフォーマンスのための基盤的な投資です。新しいアーキテクチャでは、現在 1 日あたり 1 億 2000 万件を超えるジョブを処理しており、移行前の 3 倍以上のボリュームに対応可能となりました。また、以前よりも 7 倍多くのジョブを 1 分間に開始できるようになり、企業にとって大きなメリットとなっています。バージョン要件の適用再開は、この移行完了に向けた次のステップです。すべてのランナーが新しいプラットフォームに移行するにつれ、更新されたインフラストラクチャと互換性のない古いランナーバージョンはもはやサポートできなくなります。
新しいプラットフォームとの互換性を維持するためには、以下の 2 つの要件をともに満たす必要があります:
ランナーを設定または（再）登録する場合：ランナーはバージョン 2.329.0 以降である必要があります。これは、新しいアーキテクチャがランナーを認識し、接続を許可するために必要な最小バージョンです。
ワークフロージョブの実行を継続する場合：ランナーは、各新リリースの公開から 30 日以内にインストールすることで最新の状態を維持する必要があります。これは既存の要件ですが、一部のケースでは一貫して適用されていませんでした。
バージョン 2.329.0 は、新しいプラットフォームに登録して更新を受け取るために必要な最小限のバージョンに過ぎません。ジョブを実行するための恒久的な最低バージョンではありません。ジョブ実行のための有効な最低バージョンは、新しいランナーリリースが公開されるにつれて時間とともに引き上げられていきます。
自動更新が有効になっているランナーは、更新サービスへの到達が可能である限り、30 日間の要件を自動的に満たします。
自動更新が無効になっているランナーは、定期的なスケジュールで手動アップグレードする必要があります。登録時の最低要件を満たすだけでは不十分です。2.329.0 に固定され、それ以降更新が行われないランナーでは、ジョブを受け取ることができなくなります。
ソフトウェアのどのリリース（メジャーバージョン、マイナーバージョン、パッチバージョンを問わず）も、利用可能な更新として認められます。更新が利用可能になってから 30 日以内にランナーを更新しない場合、GitHub Actions サービスは当該ランナーへのジョブキューイングを停止します。さらに、重要なセキュリティ更新が公開された場合、GitHub Actions はその更新が適用されるまで、該当ランナーへのジョブキューイングを一時的に一時停止します。
実施スケジュール
各実施日の前に、Actions では一時的なブラウンアウト（機能制限）が実行されます。ブラウンアウトはまず、サポートされていないランナーバージョンの登録を断続的にブロックすることから始まり、その後、サポートされていないランナーでのジョブ実行も断続的にブロックする範囲に拡大します。これらのブラウンアウトにより、実施開始前に古いランナーを特定し、対応措置を講じることができます。
GitHub Enterprise Cloud（データレジデンシー機能付き）: 完全な実施は 2026 年 7 月 31 日に開始されます。
GitHub Enterprise Cloud: 完全実施は2026年9月25日から開始されます。
各実施日付以降:
登録に必要な最小バージョン（例：2.329より古いランナー）未満のセルフホストランナーは、登録または再登録ができなくなります。
ワークフロージョブの実行に必要な最小バージョン（つまり、登録用最小バージョンよりも高いバージョン）未満の既存ランナーも、以前に登録されていた場合でも、ワークフロージョブの実行を停止します。
すべての段階的制限（ブラウンアウト）は、以下の日付に東部標準時11:00から午後3:00まで実施されます。
GitHub Enterprise Cloud with Data Residency
実施日：2026年7月31日
週 | 頻度 | タイプ | 結果 | 日付
---|---|---|---|---
第1週 | 1日 | 設定 | 古いバージョンのランナーは登録できません | 6月29日
第2週 | 2日 | 設定 | 古いバージョンのランナーは登録できません | 7月6日、7月8日
第3週 | 3日 | 設定、および設定＋実行 | 古いバージョンのランナーは登録できません；「設定＋実行」の日にはジョブの実行もできなくなります | 7月13日（設定）、7月15日（設定＋実行）、7月17日（設定）
第4週 | 3日 | 設定＋実行 | 古いバージョンのランナーは登録できず、ジョブも実行できません | 7月20日、7月22日、7月24日
完全実施 | — | — | 完全実施開始 | 2026年7月31日
GitHub Enterprise Cloud
実施日：2026年9月25日
週 | 頻度 | タイプ | 結果 | 日付
---|---|---|---|---
第1週 | 1日 | 設定 | 古いバージョンのランナーは登録できません | 8月24日
第2週 | 2日 | 設定 | 古いバージョンのランナーは登録できません | 8月31日、9月2日
第3週
3日間
設定、および設定＋ランタイム
古いバージョンのランナーは登録できません。設定＋ランタイムの日には、ジョブの実行もできなくなります。
9月7日（設定）、9月9日（設定＋ランタイム）、9月11日（設定）
第4週
3日間
設定＋ランタイム
古いバージョンのランナーは登録できず、ジョブの実行も行われません。
9月14日、9月16日、9月18日
適用開始
—
—
完全な適用が開始されます
2026年9月25日
適用前に何が見えるか
準備を支援するため、Actions は以下のものを提供します。
古いランナーでワークフローを実行する際に、ランタイムジョブのアノテーションが表示されます。
サポートされていないランナーバージョンの特定とアップグレード計画の策定を支援するための API およびツール。まずは、REST API にランナーバージョンを追加しました。
エンフォースメント（強制適用）前にセルフホストドランナーをアップグレードしない場合:
新しいランナーは Actions への登録に失敗する可能性があります。
既存のランナーはジョブの取得や実行を停止する可能性があります。
非対応のランナーを対象としたワークフローは、キューに残ったままになるか失敗する可能性があります。
アップグレードが必要なランナーを特定する
組織が GitHub Enterprise Cloud またはデータレジデンシー機能を備えた GitHub Enterprise Cloud を使用している場合、エンタープライズオーナーは、以下のランナー登録イベントの監査ログを照会することで、現在登録されているランナーバージョンを監査できます。各イベントにはランナーバージョンが含まれます:
org.register_self_hosted_runner: 組織にスコープされた登録イベント
repo.register_self_hosted_runner: リポジトリにスコープされた登録イベント
enterprise.register_self_hosted_runner: エンタープライズにスコープされた登録イベント
注：監査ログのイベントは登録時に記録されます。これにより、現在登録中のランナーを把握できますが、接続されているすべてのランナーの完全なインベントリを提供するものではありません。大規模なファームの場合、UI ではなく監査ログ REST API を経由して照会することを検討してください。
必要な対応
CI/CD ワークフローへの混乱を防ぐために：
すべてのセルフホスト型ランナーを最新サポートバージョンにアップグレードしてください。
インストールスクリプト、VM イメージ、コンテナイメージ、およびデプロイ自動化を更新してください。
古いキャッシュされたイメージまたはテンプレートから構築したランナーを再作成してください。
注：この変更は github.com に適用されます。GitHub Enterprise Cloud およびデータレジデンシー機能を備えた GitHub Enterprise Cloud も含まれます。現時点で GitHub Enterprise Server への影響はありません。
Actions の中断のない利用を保証する最善の方法は、事前にセルフホスト型ランナーをアップグレードすることです。詳細については、セルフホスト型ランナーのドキュメントをご覧ください。
フィードバックの共有
GitHub コミュニティに参加して、フィードバックやご質問をお寄せください。
この投稿「GitHub Actions: Minimum version enforcement timeline for self-hosted runners」は、The GitHub Blog で最初に公開されました。
原文を表示
GitHub Actions is resuming enforcement of version requirements for self-hosted runners on github.com and GitHub Enterprise Cloud with Data Residency. This change is part of a broader effort to rebuild the core of GitHub Actions to increase our reliability and availability. In early 2024, the Actions team began rearchitecting the backend services that power job execution and runner communication—a foundational investment in the reliability, availability, and performance our customers depend on. The new architecture now handles over 120 million jobs per day, more than three times the volume before the migration, and enables enterprises to start seven times more jobs per minute than previously possible. Resuming version enforcement is the next step in completing this migration: as all runners move onto the new platform, older runner versions that are incompatible with the updated infrastructure can no longer be supported.
There are two requirements that together keep a runner compatible with the new platform:
To configure or (re)register a runner: The runner must be on version 2.329.0 or later. This is the minimum version required for the new architecture to recognize the runner and allow it to connect.
To continue executing workflow jobs: The runner must stay up to date by installing each new runner release within 30 days of its publication. This is an existing requirement but was not consistently enforced in some cases.
Version 2.329.0 is only the minimum required to register with the new platform and receive updates. It is not a permanent minimum version for running jobs. The effective minimum version for job execution moves forward over time as new runner releases are published.
Runners with auto-update enabled meet the 30-day requirement automatically, as long as they can reach the update service.
Runners with auto-update disabled must be upgraded manually on a regular cadence. Meeting the registration minimum on its own isn’t enough. A runner pinned to 2.329.0 that never updates again will not pick up jobs.
Any release of the software, whether a major, minor, or patch version, qualifies as an available update. If the runner is not updated within 30 days of an update being available, the GitHub Actions service will stop queuing jobs to it. Additionally, when a critical security update is published, GitHub Actions will pause job queuing to the runner until the update has been applied.
Enforcement timeline
Ahead of each enforcement date, Actions will run temporary brownouts. Brownouts will start by intermittently blocking registration of unsupported runner versions, then expand to also intermittently blocking job execution on unsupported runners. These brownouts help you identify outdated runners and take action before enforcement begins.
GitHub Enterprise Cloud with Data Residency: Full enforcement begins July 31, 2026.
GitHub Enterprise Cloud: Full enforcement begins September 25, 2026.
After each enforcement date:
Self-hosted runners below the minimum version required for registration (e.g., runners older than 2.329) won’t be able to register or reregister.
Existing runners below the minimum version required to execute workflow jobs (i.e., a higher version than the registration minimum) will stop running workflow jobs, even if they were previously registered.
All brownouts run from 11:00 AM to 3:00 PM ET on the dates listed below.
GitHub Enterprise Cloud with Data Residency
Enforcement date: July 31, 2026
Week
Cadence
Type
Outcome
Dates
Week 1
1 day
Config
Runners on older versions cannot be registered
June 29
Week 2
2 days
Config
Runners on older versions cannot be registered
July 6, July 8
Week 3
3 days
Config, and Config + Runtime
Runners on older versions cannot be registered; on the Config + Runtime day, they also will not execute jobs
July 13 (Config), July 15 (Config + Runtime), July 17 (Config)
Week 4
3 days
Config + Runtime
Runners on older versions cannot be registered and will not execute jobs
July 20, July 22, July 24
Enforcement
—
—
Full enforcement begins
July 31, 2026
GitHub Enterprise Cloud
Enforcement date: September 25, 2026
Week
Cadence
Type
Outcome
Dates
Week 1
1 day
Config
Runners on older versions cannot be registered
August 24
Week 2
2 days
Config
Runners on older versions cannot be registered
August 31, September 2
Week 3
3 days
Config, and Config + Runtime
Runners on older versions cannot be registered; on the Config + Runtime day, they also will not execute jobs
September 7 (Config), September 9 (Config + Runtime), September 11 (Config)
Week 4
3 days
Config + Runtime
Runners on older versions cannot be registered and will not execute jobs
September 14, September 16, September 18
Enforcement
—
—
Full enforcement begins
September 25, 2026
What you’ll see before enforcement
To help you prepare, Actions will provide:
Runtime job annotations when workflows run on outdated runners.
APIs and tooling to help you identify unsupported runner versions and plan upgrades. To start, we have added the runner version to the REST API.
If you don’t upgrade your self-hosted runners before enforcement:
New runners may fail to register with Actions.
Existing runners may stop picking up or executing jobs.
Workflows targeting unsupported runners may remain queued or fail.
Identify runners that need upgrading
If your organization uses GitHub Enterprise Cloud or GitHub Enterprise Cloud with Data Residency, enterprise owners can audit which runner versions are currently registering by querying the audit log for the following runner registration events, each of which includes the runner version:
org.register_self_hosted_runner: Registration events scoped to an organization
repo.register_self_hosted_runner: Registration events scoped to a repository
enterprise.register_self_hosted_runner: Registration events scoped to the enterprise
Note: Audit log events are recorded at registration time. This gives you visibility into runners that are actively registering, but is not a complete inventory of all connected runners. For large fleets, consider querying via the audit log REST API rather than the UI.
What you need to do
To avoid disruption to your CI/CD workflows:
Upgrade all self-hosted runners to the latest supported version.
Update installation scripts, VM images, container images, and deployment automation.
Recreate runners you’ve built from older cached images or templates.
Note: This change applies to github.com, including GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency. GitHub Enterprise Server isn’t impacted at this time.
Upgrading your self-hosted runners ahead of time is the best way to ensure uninterrupted use of Actions. For more information, see the self-hosted runner documentation.
Share your feedback
Join the GitHub Community to share your feedback or for any questions.
The post GitHub Actions: Minimum version enforcement timeline for self-hosted runners appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み