<style>
.run-hero{padding:clamp(24px,5vw,44px);border-radius:24px;background:linear-gradient(130deg,#0b1220,#164e63 55%,#0f766e);color:#fff}.run-hero h2{color:#fff;margin:.35em 0}.run-kicker{font-size:.82rem;letter-spacing:.12em;font-weight:700}.run-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.run-card{padding:18px;border:1px solid #99f6e4;border-radius:16px;background:#f0fdfa}.run-card strong{display:block;color:#0f766e;font-size:1.22rem}.run-table{overflow-x:auto;margin:20px 0}.run-table table{min-width:660px;width:100%;border-collapse:collapse}.run-table th,.run-table td{padding:11px;border:1px solid #cbd5e1;text-align:left;vertical-align:top}.run-table th{background:#ccfbf1;color:#134e4a}.run-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:10px;margin:20px 0}.run-step{padding:15px;border:1px solid #99f6e4;border-radius:14px;background:#f0fdfa}.run-step b{display:block;color:#0f766e}.run-note{padding:16px;border-left:5px solid #f59e0b;background:#fffbeb;border-radius:10px;margin:20px 0}@media(max-width:720px){.run-grid,.run-flow{grid-template-columns:1fr}}
</style>
DEVOPS / GITHUB ACTIONS / 2026.09.25
自前ランナーの更新を「いつか」から「30日以内」へ
CIが突然キューに残る前に、登録と実行で異なる二つの版数要件を確認しましょう。
2.329.0以上新規登録・再登録に必要な最低版
30日以内新しいランナー版の公開後、ジョブ実行のために更新する期間
9月25日GitHub Enterprise Cloudの全面適用開始日
3行要約
- GitHubは2026年6月12日に、自前で運用するGitHub Actionsランナーの最低版数適用計画を告知しました。GitHub Enterprise Cloudでは9月25日に全面適用が始まりました。
- 登録時の下限2.329.0と、ジョブ実行時の「新リリースから30日以内」は別の条件です。2.329.0に固定すれば安心、という意味ではありません。
- 管理者はランナーの実行版を棚卸しし、イメージ・コンテナ・構築スクリプトを更新して、キュー滞留を監視する必要があります。
背景：なぜランナーの版数が運用問題になるのか
セルフホストランナーは、GitHubが管理するホストではなく、企業のVMや物理サーバー、コンテナで動くCI実行プログラムです。自動更新を無効にした環境、外部への通信を絞った環境、古いイメージから毎回作り直す環境では、本体の版数が取り残されることがあります。
今回の発表日は6月12日、GitHub Enterprise Cloudでの全面適用日は9月25日です。発表日と実際の適用日を混同しないことが重要です。GitHub Enterprise Cloud with Data Residencyでは7月31日から適用されていました。対象はgithub.comとGitHub Enterprise Cloudで、GitHub Enterprise Serverはこの告知の対象外です。[^announcement]
何が新しいのか：登録と実行は別のゲート
| 場面 | 要件 | 古い場合に起きること |
|---|
| 新規登録・再登録 | ランナー 2.329.0 以上 | 登録できない |
| 既存ランナーでのジョブ実行 | 各新リリースの公開から30日以内に更新 | ジョブを受け取れず、ワークフローが待機・失敗し得る |
| 重大なセキュリティ更新 | GitHubがより早い更新を要求する場合がある | 更新までジョブの割り当てが止まる可能性 |
30日は「すべてのランナーが永久に2.329.0で動く」という意味ではありません。実行時の許容版は新しいリリースに合わせて動きます。GitHubは重大なセキュリティ更新について、通常の30日を待たずにキュー投入を止める可能性も明記しています。[^announcement]
技術的なポイントと企業への影響
自動更新が有効で、更新先へ接続できるランナーは通常の更新経路を使えます。一方、版数をピン留めしたコンテナやマシンイメージ、手動配布のランナーは継続的な更新が必要です。特に一時的なランナーを古いテンプレートから生成すると、ホストを再作成しても版数は古いままです。GitHubの告知はイメージ、スクリプト、コンテナ、デプロイ自動化の更新を求めています。[^announcement]
運用上の影響は、コードの変更ではなくCI基盤の可用性です。特定ラベルのランナーだけが更新漏れになると、そのラベルを指定するワークフローのみが待機します。監視ではワークフローの失敗数だけでなく、キュー滞留とランナーのオンライン状態も見るべきです。これは告知内容を踏まえた編集上の運用提案です。
実践：棚卸しから更新確認まで
1 棚卸し組織・リポジトリのランナー版と状態を確認
2 更新元VMイメージ・コンテナ・構築手順の版数を修正
3 段階適用代表的なラベルのランナーで試験ジョブを実行
4 監視キュー滞留と版数を定期チェック
GitHubの組織設定でセルフホストランナーを一覧し、version、status、busyを確認します。多数のランナーがある場合、公式REST APIの「List self-hosted runners for an organization」でも同じ情報を取得できます。API応答にはversionフィールドが含まれます。[^api] 監査ログの登録イベントにも版数はありますが、登録時の値であり、現在の全ランナー一覧の代替にはなりません。[^announcement]
次に、最新のランナーを使うようイメージや自動構築手順を更新します。更新後は代表的なワークフローを実行し、ジョブがランナーに割り当てられることを確認してください。版数更新の責任者と、リリースを確認する頻度も決めておくと、30日の期限を運用に落とし込めます。
リスクと限界
版数だけで正常性は証明できません。 ネットワーク、ラベル、権限、空き容量など別の理由でもジョブは待機します。更新後は実際のワークフローで検証してください。
- 2.329.0は登録の最低版であって、今後の実行を保証する固定版ではありません。
- APIの一覧はページ分割されるため、大規模組織では全ページを確認してください。[^api]
- この告知はGitHub Enterprise Serverにそのまま適用されません。環境ごとの公式案内を確認してください。[^announcement]
- 更新を急いでも、本番ランナーを一斉停止するとCIが止まります。段階的な入れ替えと試験ジョブを推奨します。
今後注目すべき点
ランナーの新リリース日、重大なセキュリティ更新の通知、組織内での実行版の分布を継続的に追ってください。特に固定イメージを利用するチームは、CI環境の更新をアプリケーション依存ライブラリの更新と同じ定期作業として扱う必要があります。
最終確認日：2026年9月28日
参照元
[^announcement]: GitHub Changelog: Minimum version enforcement timeline for self-hosted runners（2026年6月12日公開、適用日・対象環境・版数要件）
[^api]: GitHub Docs: REST API endpoints for self-hosted runners（ランナー一覧とversionフィールド）