GitHub Actionsに廃止期限API、古いRunner停止を先回りできる

GitHubは2026年9月3日、GitHub ActionsのRunnerバージョンごとに、登録終了日と実行サポート終了日を取得できるREST APIを公開した。GitHubの9月3日付Changelog では、リポジトリ、Organization、Enterpriseの各レベルから照会でき、同時にGITHUB_TOKENのvulnerability-alerts権限と再利用可能なワークフロー向けの四つのjobコンテキストが追加されたことも示されている。

このAPIにセルフホストRunnerの実バージョンを定期的に渡せば、登録不能やジョブ実行停止に至る前に更新対象を洗い出せる。ただし停止を自動回避する機能ではなく、2026年9月3日時点で機械的に取得できるようになった期限情報を、既存のRunner管理へ組み込むための更新だ。

登録終了と実行終了は別々に監視する

エンドポイントはGET /actions/runners/deprecations/{version}で、応答にはrunner_version、registration_deprecates_at、runtime_deprecates_atが含まれる。TechPillowの更新解説 も、2026年9月3日に公開された機能として、このエンドポイントと三つの応答項目を確認している。

registration_deprecates_atは、そのバージョンで新規登録や再登録ができなくなる時点を表す。runtime_deprecates_atは、登録済みのRunnerがワークフロージョブを実行できなくなる時点であり、前者だけを見ても既存Runnerの停止リスクは判断できない。

監視画面や通知でも二つを一つの「廃止日」にまとめない方がよい。登録期限が近い場合は増設や再作成への影響、実行期限が近い場合は稼働中ジョブへの影響として扱えば、同じバージョンでも対応の優先度を分けられる。

Runner台帳と期限APIを結び付ける

監視の起点は、実際に使っているRunnerバージョンの棚卸しである。Runner一覧だけでなく、オートスケール用のVMイメージ、コンテナイメージ、インストールスクリプト、古いテンプレートも対象に含めないと、更新後の再作成で旧版が戻る可能性が残る。

1. リポジトリ、Organization、Enterpriseの管理範囲からRunnerのバージョンを収集し、重複を除く。
2. 各バージョンを廃止期限APIへ渡し、登録終了日と実行サポート終了日を別項目として保存する。
3. それぞれの期限までの残日数を計算し、組織の更新リードタイムを下回ったものを警告する。
4. 対象Runnerと、そのバージョンを生成するイメージや導入スクリプトを更新する。
5. 更新後にRunner一覧とジョブ受付状態を確認し、旧版が残っていないかを再照合する。

同じバージョンを使うRunnerが複数あれば、API照会はバージョン単位に集約し、結果を各Runnerへ結び付けられる。取得に失敗した場合は「期限なし」と扱わず、前回の取得値と取得日時を残したまま未確認として通知する方が、API障害とRunner障害を混同しにくい。

古いRunnerが実際に止まる条件は抽象的な懸念ではない。GitHubの セルフホストRunner最小バージョン適用日程 では、登録要件を下回る版は登録や再登録ができず、実行要件を下回る登録済みRunnerはジョブを実行できなくなると説明されている。GitHub Enterprise Cloudでは全面適用が2026年9月25日に予定され、その前にも登録や実行を一時的に遮断する期間が設定されている。

Dependabot alertsは読むjobだけに許可する

同日に追加されたvulnerability-alertsは、ワークフローのGITHUB_TOKENにDependabot alertsの読み取りを許可する専用権限で、値はreadまたはnoneとなる。依存関係アラートを取得する処理にvulnerability-alerts: readを設定すれば、より広い権限を持つトークンをその目的だけで渡す必要がなくなる。

権限は、アラートを読む監査jobに限定する構成が明快だ。permissionsを明示すると、同じjobで必要な別の権限が暗黙に残るとは限らないため、ソース取得や成果物操作も行う場合は、それぞれに必要な権限を併記する必要がある。

この変更が扱うのはDependabot alertsの読み取りであり、Runnerの更新や脆弱性の修正ではない。Runner期限の監視処理と同じワークフローに置く場合でも、権限エラーと実行基盤の期限切れを区別できるよう、jobと通知を分ける設計が適している。

再利用ワークフローは定義元を四つの値で残す

再利用可能なワークフローには、job.workflow_ref、job.workflow_sha、job.workflow_repository、job.workflow_file_pathが加わった。順に、現在のjobを定義したワークフローファイルの完全なref、コミットSHA、owner/repo、リポジトリルートからのファイルパスを表す。

既存のgithub.workflow_refとgithub.workflow_shaは呼び出し側の情報を示すのに対し、新しいjobコンテキストは現在のjobを定義したワークフローを指す。直接定義されたjobではworkflow_refが一致するが、再利用ワークフローでは異なり得るため、共有ワークフローの監査では両者を置き換えずに記録する必要がある。

• 実行内容をコミット単位で固定して追跡するならjob.workflow_shaを使う。
• 許可した共有リポジトリかを判定するならjob.workflow_repositoryを参照する。
• ブランチやタグを含む参照先を確認するならjob.workflow_refを使う。
• 同じリポジトリ内の定義ファイルを区別するならjob.workflow_file_pathを残す。

四つのjobコンテキストはGitHub Enterprise Serverでは提供されない。GitHub.comとGitHub Enterprise Serverの双方で同じ再利用ワークフローを動かす構成では、値が必ず存在する前提でデプロイ可否を決めず、明示的な入力など別の識別方法が必要になる。

今回の更新で得られたのは、Runnerの期限、Dependabot alertsを読む権限、再利用ワークフローの定義元という三種類の観測点である。このうち停止を先回りする鍵は、保有バージョンと二つの終了日を継続的に照合し、Runner本体だけでなく再生成元まで期限前に更新することにある。