GitHub Actions旧ランナーが停止へ｜9月25日の強制適用に備える実務チェック

GitHub Actions セルフホステッドランナー CI/CD DevOps

GitHub Enterprise Cloudで使うGitHub Actionsセルフホステッドランナーに、旧バージョンの強制停止が迫っています。 2026年9月14日（米国東部時間）から最終週のブラウンアウトが始まり、9月25日には全面適用されます。 日本時間では最終ブラウンアウトが9月17日・19日の午前0時〜4時にも予定されているため、夜間CIの停止を「一時的な障害」と誤認しない準備が必要です。

GITHUB ACTIONS / DEADLINE ALERT

旧ランナーは「登録できない」だけでなく、ジョブも止まる

2.329.0+登録時の最低版
30日以内新リリース追随期限
9月25日全面適用開始
2.337.09月15日時点の最新版

3行で分かる今回の変更

  • ランナーを新規登録・再登録するには、最低でもバージョン2.329.0が必要です。
  • 登録後も固定ではなく、新しいランナーリリースの公開から30日以内に更新しないとジョブを実行できなくなります。
  • GitHub Enterprise Cloudでは9月25日に全面適用。9月14日・16日・18日（米国東部時間）は登録と実行を断続的に止めるブラウンアウトです。

背景：なぜバージョンを強制するのか

GitHubはActionsのジョブ実行・ランナー通信基盤を再設計しました。公式発表によると、新基盤は1日1億2,000万件超のジョブを処理し、移行前の3倍超、企業が1分間に開始できるジョブ数は7倍になっています。

一方、古いランナーは新基盤と互換性がありません。これまでも「新リリースから30日以内に更新」という要件はありましたが、一部では一貫して強制されていませんでした。今回、その猶予運用が終わります。

条件必要な状態満たさない場合
登録・再登録2.329.0以上GitHubへ接続・登録できない
ジョブ実行各リリースから30日以内ジョブが割り当てられず、キュー滞留や失敗が起きる
重大なセキュリティ更新直ちに更新30日を待たずジョブ割り当てが停止する場合がある
自動更新更新サービスへ到達可能自動更新を有効にしていても古いまま残る

日本時間の停止予定

公式時刻は各日11:00〜15:00 ETです。9月の米国東部は夏時間（UTC-4）のため、日本時間では翌日の午前0:00〜4:00になります。

実施済み

9月15日 0:00〜4:00 JST

米国東部 9月14日
次回

9月17日 0:00〜4:00 JST

米国東部 9月16日
最終

9月19日 0:00〜4:00 JST

米国東部 9月18日
全面適用

9月25日 ET

時刻は公式発表に明記なし

ブラウンアウト中は、古いランナーの登録だけでなくジョブ実行も断続的にブロックされます。対象時間にキューが伸び、時間外に回復するなら、まずランナーバージョンを確認してください。

最初にやる棚卸し

GitHubのSettings → Actions → Runnersでは、名前・ラベル・接続状態を確認できます。ただし大量のランナーでは画面だけでなくAPIを使う方が確実です。

# 組織に登録されたランナーを一覧化
gh api --paginate \
  -H "Accept: application/vnd.github+json" \
  /orgs/YOUR_ORG/actions/runners \
  --jq '.runners[] | [.name, .os, .status, .busy, .version] | @tsv'

公式発表では、REST APIにランナーバージョンが追加されています。環境によっては利用するAPIバージョンや権限で項目の見え方が異なるため、空欄なら監査ログも確認します。

Enterprise Cloudでは、監査ログの次の登録イベントにバージョンが記録されます。

  • org.register_self_hosted_runner
  • repo.register_self_hosted_runner
  • enterprise.register_self_hosted_runner

ただし監査ログは登録時点の記録であり、現在接続中の全ランナーを完全に表す台帳ではありません。VMイメージ、コンテナイメージ、KubernetesのRunner Scale Set、停止中の予備機も別途棚卸ししてください。

更新手順：自動更新を前提にしすぎない

通常のセルフホステッドランナーは自動更新します。しかし、外向き通信制限、読み取り専用ファイルシステム、使い捨てイメージ、--disableupdate設定などで更新が残らないケースがあります。

  1. actions/runnerの最新リリースを確認する。
  2. 検証用ランナーを1台更新し、代表的なワークフローを実行する。
  3. インストールスクリプト、AMI・VMテンプレート、コンテナイメージの固定版を更新する。
  4. ローリング方式で本番ランナーを入れ替える。
  5. UIまたはAPIでIdleに戻り、ジョブを受け取れることを確認する。

2026年9月15日の最終確認時点で、actions/runnerの最新公開版はv2.337.0です。これは記事執筆時点の値であり、更新作業時には必ずreleases/latestを再確認してください。

ネットワークと更新ログも確認する

自動更新を有効にしていても、GitHubの更新サービスへ接続できなければ版は古いままです。公式ドキュメントはconfigスクリプトの--checkで必要なネットワークサービスへの到達性を診断する方法を案内しています。

./config.sh --check \
  --url https://github.com/YOUR_ORG/YOUR_REPO \
  --pat YOUR_TEMPORARY_PAT

診断用トークンをログやシェル履歴へ残さない運用にしてください。更新処理はランナー配置先の_diag/Runner_*と_diag/SelfUpdate*ログで追えます。

Linuxサービスなら状態も確認します。

systemctl --type=service | grep actions.runner
sudo journalctl -u actions.runner.YOUR_ORG-YOUR_REPO.runner01.service -n 100

企業への影響

影響は「CIが少し遅くなる」に留まりません。セルフホステッドランナーは、社内ネットワーク内のデプロイ、コード署名、モバイルアプリのビルド、GPUテストなど代替しにくい処理を担います。

  • リリースパイプラインがキューのまま停止する
  • 緊急修正のデプロイやロールバックが実行できない
  • オートスケール時に古いゴールデンイメージから起動した全台が登録に失敗する
  • 一時的な回避として権限の強い手動作業が増え、監査性が落ちる

特に危険なのは、稼働中の1台だけ更新して安心することです。スケールアウト元のイメージや、災害復旧用テンプレートが古ければ、負荷増大や復旧時に初めて問題が表面化します。

リスクと限界

  • 2.329.0は永続的な安全版ではなく、登録できる最低線です。実行可能な最低版はリリースのたびに移動します。
  • GitHub Enterprise Serverは今回の適用対象外ですが、各GHES版が同梱するランナー要件には従う必要があります。
  • 自動更新はランナーアプリだけを対象とし、OS、Docker、ツールチェーンは更新しません。
  • 一斉更新は稼働枠を減らすため、検証後にローリング更新します。
  • 最新版にも変更リスクがあります。ジョブの代表セットとロールバック用イメージを用意します。

9月25日までの実務チェックリスト

  • リポジトリ・組織・Enterpriseの全ランナーを棚卸しした
  • 最新版と30日要件を満たすか確認した
  • 停止中の予備機とオートスケール用イメージも更新した
  • _diagで自動更新の成功を確認した
  • 9月17日・19日午前0〜4時のブラウンアウトを運用担当へ共有した
  • 代表的なビルド、署名、デプロイを検証した
  • キュー滞留時間とOfflineランナーにアラートを設定した
  • 緊急時のGitHub-hosted runnerまたは手動手順を文書化した

今後注目すべき点

9月25日の全面適用後は、「最低版を一度上げる」作業ではなく、ランナー更新を継続運用に組み込む必要があります。リリース監視、イメージ再ビルド、段階的ロールアウト、接続確認を自動化し、30日より短い社内SLOを設けるのが現実的です。

また、GitHubは重大なセキュリティ更新時には30日の猶予を待たずジョブ割り当てを止める可能性を明記しています。通常更新と緊急更新で別の手順を準備してください。

参照元

最終確認日：2026年9月15日

Previous Post Next Post