社内のサーバーやKubernetesで GitHub Actions のセルフホストランナーを動かしていると、ランナーの版が古くなり、GitHub がジョブを割り当てなくなることがあります。ほかに使えるランナーがなければ、ワークフローは待ち状態のまま進みません。自動更新を止めてコンテナイメージでランナーの版を固定している運用で、起こりうる止まり方です。
この「何日以内に更新すればよいか」の説明が、2026年11月10日に GitHub のドキュメントの原稿（github/docs リポジトリ）で書き換えられ、11月11日の時点で公開中の docs.github.com にも反映されています。GitHub.com と GitHub Enterprise Cloud では 30日から63日に変わり、版ごとの終了予定日を返す REST API への案内が加わっています。GitHub Enterprise Server の版のページは30日のままです。本記事では、変更点を原文に沿って整理し、期限を確かめる手順を提案します。
何が変わったか
変更は、セルフホストランナーの説明のページと、各所で使われる警告の部品（Actions Runner Controller のトラブルシューティングのページなどにも表示される）の2つです。
| 変更前 | 変更後（11月10日） | |
|---|---|---|
| GitHub.com・GitHub Enterprise Cloud | 新しい版が使えるようになってから30日以内 | 新しい版が使えるようになってから63日以内 |
| GitHub Enterprise Server | 30日以内 | 30日以内（変わらず） |
| 期限の起点 | 記載なし | 「更新できるようになる日は、その版の公開日と異なることがある」 |
| 期限の確かめ方 | actions/runner のリリースの通知を勧める | GitHub.com・GitHub Enterprise Cloud では、加えて版ごとの終了予定を返す REST API を案内 |
期限を過ぎたときの扱いは、警告の部品に「新しいメジャー・マイナー・パッチのいずれかの版が使えるようになってから期限内に更新しないと、GitHub Actions のサービスはそのランナーにジョブを割り当てない」と書かれています。さらに「重大なセキュリティの更新が必要な場合は、更新するまでジョブを割り当てない」とあり、こちらには日数の猶予が書かれていません。
自動更新を止めていないランナーは、ドキュメントによると、ジョブが割り当てられたとき、またはジョブがなければ公開から1週間以内に自ら更新します。今回の期限が問題になるのは、主に config.sh に --disableupdate を付けて登録し、版をイメージで管理している場合です。
期限の起点は「公開日」ではない
今回の書き換えで重要なのは、63日の起点です。ドキュメントは、期限の起点を「新しい版が使えるようになった日」とし、その日が公開日と異なりうると明記しました（GitHub.com・GitHub Enterprise Cloud の版のページだけにある記述です）。
つまり、actions/runner のリリースページの日付に63日を足しても、正しい期限になるとは限りません。版ごとの期限は、次の REST API で確かめるのが確実です。
版ごとの終了予定日を返す API
ランナーの版ごとの終了予定を返すエンドポイントが、11月2日に GitHub のドキュメントの REST API の定義データに加わりました。組織用とリポジトリ用があり、GitHub Enterprise Cloud の版のページにはエンタープライズ用もあります。GitHub Enterprise Server の版の REST API のページには載っていません。
GET /orgs/{org}/actions/runners/deprecations/{version}
GET /repos/{owner}/{repo}/actions/runners/deprecations/{version}
GET /enterprises/{enterprise}/actions/runners/deprecations/{version} # GitHub Enterprise Cloud応答には、次の2つの日付が入ります。
runtime_deprecates_at：この日を過ぎると、この版のランナーにジョブが割り当てられなくなる日。より新しい版がまだない場合はnull。registration_deprecates_at：この日を過ぎると、この版のランナーを新たに登録できなくなる日。登録に必要な最低の版（定義の記載では現在 2.329.0）より古い版にだけ設定され、それ以外はnull。
ドキュメントには、次の権限が書かれています。
- 組織用：組織の管理者の権限が必要です。personal access token（classic）では
admin:orgのスコープ、fine-grained のトークンでは「Self-hosted runners」の組織の権限（読み取り）で使えます。 - リポジトリ用：リポジトリの管理者の権限が必要です。classic では
repoのスコープ、fine-grained では「Administration」のリポジトリの権限（読み取り）です。 - エンタープライズ用：classic では
manage_runners:enterpriseのスコープが必要で、fine-grained のトークンや GitHub App のトークンでは使えません。
組織のランナーの版を一覧にして期限を出す例
組織に登録されたランナーの版を集め、版ごとに終了予定日を表示するスクリプトの例です。gh（GitHub CLI）にログインし、組織の管理者の権限で実行します。
#!/usr/bin/env bash
# 使い方: ORG=your-org ./check-runner-eol.sh
set -euo pipefail
: "${ORG:?ORG を指定してください}"
gh api --paginate "/orgs/$ORG/actions/runners" \
-q '.runners[] | select(.version != null) | .version' | sort -uV |
while read -r v; do
gh api "/orgs/$ORG/actions/runners/deprecations/$v" \
-q '[.runner_version, (.runtime_deprecates_at // "未定"), (.registration_deprecates_at // "なし")] | @tsv'
done | { printf '版\tジョブが割り当てられなくなる日\t登録できなくなる日\n'; cat; }ランナーの一覧の version は、「一度でもサービスに接続したランナーにだけ設定される」と定義にあるため、未接続のランナーは除いています。このスクリプトは、偽の gh コマンドと架空の応答で組み立てを確かめただけで、実際の組織では実行していません。 本番で使う前に、検証用の組織で動作を確かめてください。
自動更新を止めている場合の運用（編集部の提案）
ここからは編集部の提案です。
1. ランナーの版を固定している場所を洗い出す。 Dockerfile、Actions Runner Controller の設定、社内サーバーの構成管理など、ランナーの版を書いている場所を一覧にします。CI の部品の一覧づくりは、GitHub Actions のサプライチェーンの継続監査の記事も参考になります。
2. 期限は API の日付で管理する。 上のスクリプトを定期的に実行し、runtime_deprecates_at が近い版を担当者に知らせます。63日は「余裕が増えた」というより、「起点が見えにくくなったので API で確かめる」と捉えるのが安全です。
3. 重大なセキュリティの更新に備える。 重大な更新では日数の猶予がないと書かれています。イメージを作り直してランナーを入れ替える手順を、普段から短い時間で回せるようにしておきます。
4. GHES は30日のまま。 GitHub Enterprise Server を併用している場合、同じイメージでも期限が異なります。GHES の版のドキュメントには終了予定日の API の案内がないため、actions/runner のリリースの通知などで新しい版を追います。
ランナーの運用費や CI の費用を、保守の見積もりにどう入れるかは、CI の従量課金と保守契約の記事で扱いました。
確認した範囲
2026年11月11日に、github/docs の原稿と、変更のコミット a682515（2026年11月10日）、REST API の定義を加えたコミット 7b168cc（11月2日）を確認しました。あわせて docs.github.com の公開ページを GitHub.com・GitHub Enterprise Cloud・GitHub Enterprise Server の版ごとに開き、63日と30日の書き分け、終了予定日の API の有無が原稿と一致することを確かめました（資料調査）。GitHub の変更履歴（Changelog）の Actions の項目（10月・11月）には、この変更の告知は見当たりませんでした。API の呼び出しは行っておらず、実際の版ごとの終了予定日は確認していません。スクリプトは偽の
ghと架空の応答で組み立てだけを確かめました。
セルフホストランナーを含む CI/CD の運用の見直しや、ランナーのイメージの更新を自動化する仕組みづくりは、グリームハブの開発・AI・自動化のご相談で承っています。構成によって進め方が変わるため、お問い合わせからご相談ください。
参考資料
- GitHub Docs — Self-hosted runners reference（Runner software updates on self-hosted runners）
- GitHub Docs — REST API endpoints for self-hosted runners
- GitHub Enterprise Cloud Docs — REST API endpoints for self-hosted runners（エンタープライズ用）
- GitHub Enterprise Server Docs — Self-hosted runners reference（30日）
- github/docs — commit a682515（Clarify self-hosted runner deprecation dates）
- github/docs — commit 7b168cc（Update OpenAPI Description）
- actions/runner — Releases
