追記: 2026年6月17日の最新情報
2026年6月16日以降、GitHub ActionsではJavaScript actionの実行環境がNode 24既定へ進みます。これはself-hosted runnerの最低バージョン適用とは別の確認軸ですが、同じrunner棚卸しで見落としやすいポイントです。
GitHubの告知では、Node 24はmacOS 13.4以下と互換性がなく、ARM32のself-hosted runnerもNode 20非推奨後はサポート対象外になると説明されています。Node 20へ一時退避する環境変数も用意されていますが、秋にrunnerからNode 20が削除されるまでの暫定策として読むのが安全です。
runner更新計画を見直す場合は、v2.329.0以上という登録条件、release公開後30日以内の更新運用、そしてNode 24移行時のOS・アーキテクチャ条件を分けて確認してください。詳しい確認観点は、後発記事の GitHub ActionsはNode 24既定へ：Node 20非推奨、runner更新、self-hosted確認ポイント にまとめています。
このテーマをもう少し広げて見るなら、GitHub ActionsはNode 24既定へ：Node 20非推奨、runner更新、self-hosted確認ポイント と GitHub Copilot code reviewに組織単位runner設定：content exclusion、custom instructionsの確認ポイント も合わせて確認してください。最低バージョン適用と同じrunner棚卸しで、Node 24既定化後のOS・アーキテクチャ条件を分けて確認できます。
GitHub Actionsでself-hosted runnerを運用しているチームは、2026年夏から秋にかけてrunner更新を「いつもの保守作業」ではなく、CI/CD停止を避ける期限付きタスクとして扱う必要があります。GitHubは2026年6月12日、github.comおよびGitHub Enterprise Cloud with Data Residencyに対して、self-hosted runnerの最低バージョン要件の適用再開タイムラインを公開しました。
特に見落としやすいのは、要件が1つではないことです。登録または再登録にはrunner v2.329.0以上が必要になり、既存runnerでジョブを実行し続けるには各runner releaseを公開後30日以内に取り込む運用が求められます。つまり、v2.329.0を入れれば長期的に安全、という話ではありません。
ここではGitHub ChangelogとGitHub Docsをもとに、Data Residency利用者、GitHub Enterprise Cloud利用者、GitHub Enterprise Server中心のチームで確認すべき点を分けます。確認日は2026年6月14日（JST）です。
3行まとめ
GitHub Enterprise Cloud with Data Residencyでは、2026年7月31日にfull enforcementへ進みます。
GitHub Enterprise Cloud一般では、2026年9月25日がfull enforcementの日付です。
登録や再登録にはv2.329.0以上、ジョブ実行の継続にはrunner release公開後30日以内の更新が関係します。
runner本体だけでなく、AMI、VMイメージ、コンテナ、ARC、runner scale set、Firewall、監視通知まで確認します。
9月25日だけを覚えると、Data Residency利用者やbrownout前の検証を見落とすおそれがあります。
- GitHub Actionsのself-hosted runner最低バージョン適用は、GitHub Enterprise Cloud with Data Residencyでは2026年7月31日、GitHub Enterprise Cloudでは2026年9月25日にfull enforcementへ進みます。
- 登録または再登録にはv2.329.0以上が必要です。一方で、ジョブ実行を継続するにはrunner releaseを公開後30日以内に更新する運用が別に必要です。
- 影響確認はrunner本体だけでなく、AMI、VMイメージ、コンテナ、Actions Runner Controller、runner scale set、Firewall、社内ミラー、監視通知まで含めて棚卸しするのが現実的です。
今回の変更は何が止まり得るのか
停止リスクはコードの失敗ではなく、runnerの登録、再登録、実行継続の条件として表面化することがあります。
GitHubの告知は、self-hosted runnerを使うチームに対する最低バージョン要件の再開タイムラインです。対象は、GitHubが提供するGitHub-hosted runnerではなく、企業や開発チームが自分たちで管理しているrunnerです。オンプレミスのVM、クラウドVM、Kubernetes上のrunner、コンテナ化されたephemeral runnerなどがここに入ります。
登録できない問題と実行できない問題がある
根拠と影響
今回の変更でまず起き得るのは、古いrunnerが登録または再登録できなくなることです。GitHubの告知では、新しいActions基盤がrunnerを認識して接続できるようにするため、登録または再登録にはv2.329.0以上が必要だと説明されています。
もう1つは、既に登録済みのrunnerがジョブを実行できなくなることです。これはv2.329.0以上かどうかだけで判断できません。GitHub Docsでは、runnerの自動更新を無効にしている場合でも、新しいrunner versionが利用可能になってから30日以内に更新する必要があると説明されています。重大なセキュリティ更新では、更新されるまでジョブがキューされない可能性にも触れています。
hosted runnerだけなら優先度は下がる
条件
GitHub-hosted runnerだけを使っているチームでは、今回扱う運用負荷は比較的小さくなります。GitHub-hosted runnerのイメージ更新や利用料金の確認は別の話です。
一方、self-hosted runnerを少しでも使っている場合は、利用頻度が低くても棚卸しが必要です。古いリポジトリに残ったrunner、退職者が作った検証用runner、特定ラベルだけに紐づくrunnerは、普段のCIが通っているだけでは見つからないことがあります。
Actions周辺の変更とあわせて見る
2026年6月は、GitHub ActionsやGitHub Copilot周辺の管理者向け更新が続いています。たとえば、Actions上のAI自動化を扱う<a href="https://msft-watch.blog.mo-gmo.com/msft-47-github-agentic-workflows-public-preview-actions-github-token-cost-controls/">GitHub Agentic Workflowsのpublic preview</a>では、GITHUB_TOKEN、権限、課金管理が論点になります。今回のrunner更新は、そうした新しい自動化を載せる前の土台確認です。
セキュリティスキャンをActionsで回しているチームは、<a href="https://msft-watch.blog.mo-gmo.com/msft-36-codeql-2-25-6-swift-csharp-actions-sensitive-data/">CodeQL 2.25.6の更新</a>やcode scanning運用ともつながります。runnerが古くてジョブが止まると、ビルドだけでなく検査の継続性にも影響します。
期限はData ResidencyとEnterprise Cloudで違う
- 2026年7月31日
GitHub Enterprise Cloud with Data Residencyのfull enforcementです。Enterprise Cloud一般の9月25日を期限として読まないようにします。
- 2026年8月24日以降
GitHub Enterprise Cloud一般ではbrownoutが始まります。最初のbrownoutは検証開始日ではなく、検証済みで迎える日として扱います。
- 2026年9月25日
GitHub Enterprise Cloud一般のfull enforcementです。重要workflowはこの日まで待たず、8月前半までに更新と再登録テストを終えます。
- GHES
GitHub Enterprise Serverは現時点で今回の変更の対象外です。ただしEnterprise Cloud併用や共通runner imageがある場合は分けて確認します。
brownoutは米国東部時間で示されるため、日本の運用では日付をまたぐ深夜帯の確認になることがあります。
今回の告知で最も危ない読み違いは、9月25日だけを覚えてしまうことです。GitHub Enterprise Cloud with Data Residencyを使っているチームは、full enforcementが2026年7月31日と早く設定されています。
| 対象 | full enforcement | brownoutの扱い | 最初の見方 |
|---|---|---|---|
| GitHub Enterprise Cloud with Data Residency | 2026年7月31日 | 2026年6月29日から段階実施 | 7月中の本番影響を前提に逆算する |
| GitHub Enterprise Cloud | 2026年9月25日 | 2026年8月24日から段階実施 | 8月下旬までに棚卸しと更新を済ませる |
| GitHub Enterprise Server | 現時点では対象外 | 告知上は対象外 | Enterprise Cloud併用や共通イメージだけ確認する |
Data Residencyは7月31日を期限にする
根拠
GitHub Enterprise Cloud with Data Residencyのfull enforcementは2026年7月31日です。Data Residency環境を使っているチームは、Enterprise Cloud一般の9月25日を自分たちの期限として読んではいけません。
注意点
Data Residency向けのbrownoutは、GitHub告知ではすべて11:00から15:00 ETに実施されます。2026年6月から7月の米国東部時間は夏時間のため、日本時間では翌日0:00から4:00ごろに当たります。
| GitHub告知日（ET） | 種別 | 日本時間の目安 |
|---|---|---|
| 2026年6月29日 | Config | 6月30日 0:00-4:00 |
| 2026年7月6日、7月8日 | Config | 7月7日、7月9日 0:00-4:00 |
| 2026年7月13日、7月17日 | Config | 7月14日、7月18日 0:00-4:00 |
| 2026年7月15日 | Config + Runtime | 7月16日 0:00-4:00 |
| 2026年7月20日、7月22日、7月24日 | Config + Runtime | 7月21日、7月23日、7月25日 0:00-4:00 |
Configは登録や再登録の影響、Config + Runtimeは登録や再登録に加えてジョブ実行への影響が出る段階として読みます。日本の運用チームにとっては深夜帯になりやすいため、監視通知と翌朝の確認だけで足りるか、担当者の立ち会いが必要かを先に決めておくべきです。
Enterprise Cloudは9月25日だが、8月下旬から試される
根拠
GitHub Enterprise Cloud一般のfull enforcementは2026年9月25日です。ただし、brownoutは2026年8月24日から始まります。9月25日まで動かなくてよい、という意味ではありません。
| GitHub告知日（ET） | 種別 | 日本時間の目安 |
|---|---|---|
| 2026年8月24日 | Config | 8月25日 0:00-4:00 |
| 2026年8月31日、9月2日 | Config | 9月1日、9月3日 0:00-4:00 |
| 2026年9月7日、9月11日 | Config | 9月8日、9月12日 0:00-4:00 |
| 2026年9月9日 | Config + Runtime | 9月10日 0:00-4:00 |
| 2026年9月14日、9月16日、9月18日 | Config + Runtime | 9月15日、9月17日、9月19日 0:00-4:00 |
評価基準
Enterprise Cloud利用者は、最初のbrownoutを「検証の始まり」ではなく「検証済みであるべき日」として扱う方が安全です。リリース、月末締め、決算処理、顧客向けデプロイなど重要なworkflowがあるなら、8月前半までにrunner更新と再登録テストを終える計画が必要になります。
GHESは対象外だが、併用環境は別
注意点
GitHubの告知では、GitHub Enterprise Serverは現時点で今回の変更の対象外とされています。GHESだけを閉じた環境で使っているチームは、今回のfull enforcement日を直接の停止期限として読む必要はありません。
ただし、GHESとGitHub Enterprise Cloudを併用している場合、runnerイメージや更新手順を共通化していることがあります。クラウド側のrunnerだけが古い、あるいは共通のgolden imageが古くてクラウド側に影響する、といった形で問題が出る可能性があります。GHES対象外という一文は、runner更新を放置してよいという意味ではありません。
v2.329.0以上と30日以内更新は別条件
- 1登録・再登録
新しいrunner追加、runner再作成、登録トークンの使い直し、スケールアウト時の新規runnerではv2.329.0以上が最低条件になります。
- 2既存runnerの実行
既に登録済みでも、runner release公開後30日以内の更新に追従しているかを別に確認します。
- 3自動更新の実測
管理画面のversion表示だけでなく、再起動後の版、更新ログ、スケールアウト時の起動ログを確認します。
- 4OSと周辺更新
runner applicationが更新されても、VMやコンテナのOS、ツール、証明書、ネットワーク設定は別管理です。
v2.329.0以上なら十分、と読まず、現在利用可能なrunner releaseからどれだけ遅れているかも確認します。
ここでいちばん大切なのは、v2.329.0以上という最低登録版と、runner release公開後30日以内の更新を分けることです。ここを混同すると、対応が中途半端になります。
v2.329.0以上は登録と再登録の最低条件
登録要件
GitHub Changelogでは、runnerを設定または再登録するにはv2.329.0以上が必要だと説明されています。新しいrunnerを追加するとき、古いrunnerを作り直すとき、登録トークンを使い直すとき、オートスケールで新しいrunnerが起動するときに露出しやすい条件です。
注意点
たとえば、普段は既存runnerが動いていても、障害対応でrunnerを再作成した瞬間に古いイメージが使われると、登録で詰まる可能性があります。スケールアウト時だけ失敗する構成も考えられます。
ジョブ実行は30日以内更新が残る
実行継続の条件
GitHub Docsのself-hosted runners referenceでは、self-hosted runnerは既定でrunner softwareを自動更新すると説明されています。その一方で、自動更新を無効にしている場合でも、runner versionが公開されてから30日以内に更新する必要があるとされています。
評価基準
この30日ルールは、v2.329.0以上かどうかとは別に見ます。2026年6月14日確認時点でactions/runner releases/latestはv2.335.1を示していましたが、latest releaseは変わります。したがって記事公開後に読む場合は、手元のrunnerが単にv2.329.0以上かだけでなく、現在利用可能なrunner releaseからどれだけ遅れているかを確認してください。
「自動更新が効くはず」を実測する
確認項目
GitHub Docsでは、runner applicationの自動更新プロセスを定期的に確認することも推奨されています。runner applicationは自動更新されても、OSや他のソフトウェアの更新は別管理です。runnerが動いているVMやコンテナのセキュリティパッチまで自動で面倒を見てくれるわけではありません。
自動更新が効いているかは、管理画面のversion表示だけでなく、runner machine側のログでも確認します。GitHub Docsでは、runner application logやSelfUpdate logが_diagディレクトリにあることを案内しています。閉域環境、プロキシ配下、社内ミラー経由の構成では、実際に更新が成功しているかを一度確認しておく価値があります。
brownoutを本番停止前の検証日として使う
古いrunnerの登録や再登録に影響が出る段階として見ます。再作成手順や登録トークン利用時の挙動を確認します。
登録や再登録に加えて、古いrunnerのジョブ実行にも影響が出る段階として見ます。
検証用リポジトリ、低リスクのrunner group、代表的なlabelを選び、ビルド、テスト、ネットワーク接続を小さく確認します。
失敗したときに、どの通知で、誰が、何分後に気づき、どの手順で復旧するかを見ます。
11:00から15:00 ETは日本では深夜帯になりやすいため、立ち会いか翌朝確認かを先に決めます。
brownoutは本番重要workflowを初めて試す日ではなく、事前準備の結果を確認する日として使います。
GitHubはfull enforcementの前に、temporary brownoutsを段階的に実施すると説明しています。brownoutは古いrunnerを見つけるための警告期間です。本番の重要workflowをそこで初めて試すのではなく、事前に検証計画を組むためのカレンダーとして使います。
ConfigとRuntimeを分けて観察する
確認項目
Configのbrownoutでは、古いrunnerの登録や再登録ができない状態を確認することになります。Config + Runtimeでは、それに加えて古いrunnerがジョブを実行できない影響も出るとされています。
検証では、次のように観察点を分けると原因を追いやすくなります。
| 観察点 | 確認すること | 失敗時に見る場所 |
|---|---|---|
| 新規登録 | 古いイメージからrunnerが登録できるか | 登録手順、runner version、登録トークン |
| 再登録 | 既存runnerの再構成が通るか | config script、runner service、管理画面 |
| ジョブ実行 | 古いrunnerがworkflow jobを拾うか | workflow run、runner status、runner log |
| オートスケール | 起動したephemeral runnerが期待版か | コンテナイメージ、ARC、runner scale set |
| 通知 | 失敗を誰がいつ検知するか | Actions通知、監視、チャット通知 |
低リスクのworkflowで先に試す
注意点
brownoutの時間帯に、本番リリース用workflowだけを試すのは危険です。検証用リポジトリ、低リスクのrunner group、代表的なlabelを決め、ビルド、テスト、コンテナ利用、社内ネットワーク接続など必要なパターンを小さく確認します。
重要なのは、成功したかどうかだけではありません。失敗したときに、誰が、どの通知で、何分後に気づけるかを見ます。runner更新の問題は、開発者のコード変更や依存ライブラリの不具合と見分けにくい場合があります。通知文だけで原因が分からないと、復旧が遅れます。
日本時間では深夜帯に当たる
運用条件
GitHub告知のbrownoutは11:00から15:00 ETです。2026年夏の日本時間ではおおむね翌日0:00から4:00になります。日本チームがこの時間に立ち会えない場合、前日までに検証を終え、翌朝に結果を確認する運用を決める必要があります。
Data Residency利用者は6月末から7月下旬、Enterprise Cloud利用者は8月下旬から9月中旬に深夜帯の影響が続きます。運用カレンダーには、GitHub告知日と日本時間の両方を書いておくと混乱が減ります。
更新対象はrunner binaryだけではない
インストールディレクトリ、実行ユーザー、サービス化の方法、runner applicationへの書き込み権限を確認します。
Dockerfile、Packer template、AMI、VM image、Terraform、Bicep、ARM templateに古いrunnerが残っていないかを確認します。
controller、runner image、更新ポリシー、disableUpdate相当の設定、スケールアウト時の起動ログを見ます。
runner更新、release取得、証明書検査に必要なGitHubへの通信が遮断されていないかを確認します。
社内wiki、構成管理、標準作業手順、社内配布物が古いdownload URLや古いtarballを参照していないかを確認します。
既存runnerが動いていても、障害復旧や負荷増加で新しく作られるrunnerが古い場合はそこで詰まります。
self-hosted runnerの更新というと、runner binaryの入れ替えだけを考えがちです。しかし実際には、古いrunnerを再生成する仕組み全体を見る必要があります。
常設VMと手動インストールrunner
確認項目
常設VMにrunnerを手動でインストールしている場合、まずrunnerのインストールディレクトリ、実行ユーザー、サービス化の方法、更新権限を確認します。runner applicationに書き込み権限がなければ、自動更新が失敗する可能性があります。
注意点
手順書が古い場合も注意が必要です。新しい担当者が障害時に手順書どおり再作成したら、古いdownload URLや古いtarballを使ってしまうことがあります。社内wiki、構成管理、インストールスクリプト、標準作業手順を一緒に更新してください。
コンテナ、AMI、VMイメージ、golden image
条件
ephemeral runnerやオートスケール構成では、起動元のイメージが古いと、毎回古いrunnerが生まれます。Dockerfile、Packer template、AMI、VM image、Terraform、Bicep、ARM template、Kubernetes manifestなどを確認します。
Actions Runner Controllerやrunner scale setを使っている場合は、controller自体、runner image、更新ポリシー、disableUpdate相当の設定、スケールアウト時の起動ログを見ます。普段のジョブが成功していても、新規podや新規VMが古いrunnerで起動する問題は、負荷が増えたときに初めて出ることがあります。
Firewall、プロキシ、社内ミラー
注意点
runnerの更新は、GitHubへの通信、release取得、証明書検査、プロキシ設定に依存します。Firewallやプロキシで通信先を厳しく制限している環境では、runnerが更新版を取得できないことがあります。
ここで避けたいのは、古い許可リストを記事や手順書に固定し続けることです。通信先や更新仕様は変わる可能性があるため、GitHub Docsの最新情報を確認し、社内のネットワーク許可設定を更新する運用にしておく方が堅実です。
監視とトラブルシュートで見る場所
- 1workflow run
失敗時刻、対象job、使われたlabel、runner名を確認します。
- 2runner statusとversion
Enterprise、Organization、Repositoryのどの階層にrunnerが登録されているか、接続状態とversionを確認します。
- 3runner groupとlabel
self-hosted、linux、x64、gpu、release、prodなど、重要workflowが依存するlabelを特定します。
- 4runner側ログ
runner machineの_diagディレクトリ、Runner log、SelfUpdate logをworkflow runの時刻と合わせて見ます。
- 5更新・再登録・再実行
runner更新、再登録、新規runner追加、ジョブ再実行のどこで復旧するかを記録します。
固定のエラーメッセージだけに頼らず、workflow側とrunner machine側の時刻をつないで確認します。
runner更新の失敗は、workflowの失敗として表面化します。ただし、workflow runだけを見ると、アプリケーションのテスト失敗なのか、依存サービスの障害なのか、runner versionの問題なのかを切り分けにくくなります。
管理画面でrunner statusとversionを確認する
確認項目
まず、Enterprise、Organization、Repositoryのどの階層にself-hosted runnerが登録されているかを確認します。runner group、label、OS、接続状態、version、最終接続時刻を棚卸しします。
重要workflowがどのlabelに依存しているかも確認してください。self-hostedだけでなく、linux、x64、gpu、release、prodのような独自labelを使っている場合、古いrunnerが特定workflowだけに残ることがあります。
runner側ログとworkflow runをつなげる
切り分け
GitHub Docsでは、runner applicationのログやjob logの確認場所が説明されています。runner machineの_diagディレクトリには、runner applicationやworkerに関するログが残ります。自動更新の状態も、Runner logやSelfUpdate logで確認できます。
障害時には、workflow runの失敗時刻、runner名、runner group、runner machine側のログ時刻を合わせて見ます。ログ文言はGitHub側の実装で変わる可能性があるため、固定のエラーメッセージだけに依存しない方がよいです。
棚卸しスクリプトは補助にする
条件
EnterpriseやOrganization単位でrunnerが多い場合、APIやCLIを使った棚卸しが役に立ちます。ただし、権限、対象階層、Data Residency環境、社内ポリシーによって取得できる情報は変わります。
この記事では特定のAPIコマンドを万能手順としては扱いません。まず必要なのは、どの階層にrunnerがあるか、誰が管理しているか、どのworkflowに影響するかを把握することです。スクリプトはその確認を速くするための道具です。
最短の対応計画
- 最初の30分
runner一覧、version、OS、label、group、最終接続、重要workflowとの紐づきを集めます。
- 分類
更新済み、更新手順あり、手順不明、担当不明に分け、古いrunnerと不要runnerを見える化します。
- brownout前
runner更新、再登録、新規runner追加、オートスケール、ephemeral runnerの起動、重要workflowの実行を試します。
- full enforcement前
Data Residencyは7月31日、Enterprise Cloudは9月25日から逆算し、リリースや月末処理と重なるworkflowを先に検証します。
- 継続運用
actions/runner releasesの確認、社内承認、イメージ更新、検証、段階展開、ロールバック、失敗通知を1つの周期にします。
今回だけの手作業で終わらせず、runner release公開後30日以内に追従する運用へ移すことが再発防止になります。
期限まで余裕があるように見えても、runner更新は関係者が多くなりがちです。開発チーム、SRE、セキュリティ、ネットワーク、IT管理、リリース担当が別々に持っている情報をつなぐ必要があります。
まず30分でrunner一覧を作る
初動
最初の30分では、完璧な修正ではなく、対象の見える化を優先します。
| 確認項目 | 見たいこと |
|---|---|
| runner名、group、label | 重要workflowがどこに依存しているか |
| version | v2.329.0未満、またはlatestから大きく遅れていないか |
| OSと実行形態 | VM、コンテナ、Kubernetes、ARC、scale setのどれか |
| 自動更新 | 有効か、無効か、実際に成功しているか |
| 起動元 | AMI、VMイメージ、Dockerfile、社内ミラーが古くないか |
| 担当者 | 更新と障害対応の責任者が決まっているか |
評価基準
この時点で、更新済み、更新手順あり、手順不明、担当不明の4つに分けるだけでも十分に効果があります。
brownout前に更新と再登録を試す
検証項目
次に、古いrunnerを更新します。Data Residency利用者は7月31日を待たず、最初のbrownout前に主要runnerを更新しておくべきです。Enterprise Cloud利用者も、8月24日のbrownout前に検証を終える計画にします。
検証では、runnerの更新だけでなく、再登録、新規runner追加、オートスケール、ephemeral runnerの起動、重要workflowの実行まで見ます。既存runnerだけが動いていても、新規runnerが古いイメージから作られるなら、障害時や負荷増加時に詰まります。
30日追従を仕組みにする
継続運用
最後に、30日以内更新を継続運用へ移します。actions/runner releasesの確認、社内承認、イメージ更新、検証、段階展開、ロールバック、失敗通知までを1つの運用サイクルにします。
手作業で毎回対応する形だと、今回だけは乗り切れても次のrunner releaseで同じ問題が戻ります。RenovateやDependabot、社内のイメージ更新パイプライン、監視通知など、既存の仕組みにrunner更新を組み込めるかを確認してください。
待ってよいチームと今すぐ動くチーム
Data Residencyを使っている、閉域や社内ミラーでrunnerを管理している、オートスケールやephemeral runnerを使っている、重要なrelease workflowがself-hosted runnerに依存しているチームです。
GitHub-hosted runner中心でself-hosted runnerが少なく、自動更新が実際に機能し、重要workflowへの依存が小さいチームです。
GHES単独なら今回告知の直接対象ではありません。ただしEnterprise Cloud併用、GitHub.com上のリポジトリ、クラウド移行予定、共通runner imageがある場合は確認します。
使っていないつもりのrunnerがOrganizationに残っていないかを確認し、不要runnerは削除して管理対象を減らします。
緊急度は違っても、runner一覧とversionの確認を省いてよいチームは多くありません。
すべてのチームが同じ緊急度ではありません。とはいえ、何もしなくてよいチームは少数です。
今すぐ動くべきチーム
条件
GitHub Enterprise Cloud with Data Residencyを使っているチームは、7月31日がfull enforcementです。runnerを閉域環境や社内ミラーで管理している、オートスケールやephemeral runnerを使っている、重要なrelease workflowがself-hosted runnerに依存している場合も、すぐに棚卸しを始めるべきです。
セキュリティやコンプライアンスの都合でrunner更新に承認が必要な組織は、さらに早く動く必要があります。承認待ち、検証待ち、ネットワーク許可待ちが重なると、1か月はすぐに過ぎます。
計画対応でよいチーム
条件
GitHub-hosted runner中心でself-hosted runnerが少なく、runner自動更新が実際に機能していて、重要workflowへの依存が小さいチームは、緊急対応ではなく計画対応でもよいでしょう。
ただし、最低限のrunner一覧確認は必要です。使っていないつもりのrunnerがOrganizationに残っていることがあります。不要runnerは削除し、必要runnerだけを管理対象に残すと、その後の運用も楽になります。
GHES中心のチーム
注意点
GHES単独利用なら、今回のGitHub Changelog上の対象ではありません。ただし、Enterprise Cloudとの併用、GitHub.com上の公開リポジトリ、クラウド移行予定、共通runner imageがあるなら、対象資産を分けて見てください。
「GHESは対象外」という確認は、2026年6月14日時点の一次情報にもとづくものです。今後GitHubが別の告知を出す可能性はあるため、GHES運用者もrunner更新を完全に後回しにする理由にはしない方が安全です。
まとめ：7月31日と9月25日までに確認すること
古いself-hosted runnerは、登録不可、再登録不可、ジョブ実行不可という形でCI/CDに影響する可能性があります。
今回の変更は、単なるバージョンアップ告知ではありません。古いself-hosted runnerが登録できない、再登録できない、ジョブを実行できない、という形でCI/CDに出る可能性があります。
確認リストは次の通りです。
| 確認軸 | 見ること |
|---|---|
| 対象環境 | Data Residency、Enterprise Cloud、GHES、GitHub-hosted runnerのみのどれか |
| 期限 | Data Residencyは2026年7月31日、Enterprise Cloudは2026年9月25日 |
| 最低登録版 | 登録、再登録、新規runner追加にはv2.329.0以上 |
| 実行継続 | runner release公開後30日以内に更新する運用 |
| brownout | 11:00-15:00 ET、日本時間では深夜帯になりやすい |
| 更新資産 | VM、コンテナ、AMI、ARC、scale set、Firewall、社内ミラー、手順書 |
| 監視 | workflow run、runner status、runner log、SelfUpdate log、通知先 |
Microsoft Watch JapanはMicrosoft、GitHub、その他関係会社と非提携の独立ブログです。本記事は製品・サービス変更の確認を目的としたもので、投資助言ではありません。株価や評価額ではなく、開発者と管理者が触れるGitHub Actions運用への影響を中心に整理しました。
次に読むなら
参照した主な情報源
- GitHub Changelog「GitHub Actions: Minimum version enforcement timeline for self-hosted runners」（2026年6月12日公開、2026年6月14日JST確認）
GitHub Actions: Minimum version enforcement timeline for self-hosted runners
- GitHub Docs「Self-hosted runners reference」（2026年6月14日JST確認）
https://docs.github.com/en/actions/reference/runners/self-hosted-runners
- GitHub Docs「Monitoring and troubleshooting self-hosted runners」（2026年6月14日JST確認）
https://docs.github.com/actions/how-tos/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners
- GitHub actions/runner releases latest（2026年6月14日JST確認）
https://github.com/actions/runner/releases/latest
- Microsoft Watch Japan「2026年6月 重要トピックまとめ」
2026年6月 重要トピックまとめ