GitHub Actionsで「Node.js 20 actions are deprecated」という警告が出ている場合、まず対応すべきことは、.github/workflows内で使っているActionをNode.js 24対応版へ更新し、必要に応じてself-hosted runnerのバージョンとOS条件を確認することです。特にactions/checkout、actions/setup-node、actions/setup-dotnet、actions/upload-artifactの古いメジャーバージョンを使っているリポジトリは、ワークフローが将来の実行環境で失敗しないよう、早めに棚卸ししてください。
今回の「Update deprecated Node.js 20 GitHub Actions to Node.js 24 compatible versions」は、microsoft/aspireリポジトリのPR #15829で行われた実例です。単にバージョン番号を上げるだけでなく、どのワークフローに影響があるか、SHA pinningをどう扱うか、self-hosted runnerで何を確認すべきかまで含めて見る必要があります。PRは2026年4月3日にmainへマージされ、tests.yml、refresh-typescript-sdks.yml、reproduce-flaky-tests.ymlの3ファイルが対象になっています。(GitHub)
GitHub ActionsのNode.js 20非推奨対応で何が変わるのか
GitHub ActionsのNode.js 20非推奨対応は、「自分のアプリがNode.js 20で動いているか」という話とは別です。ここで問題になるのは、uses:で呼び出しているJavaScript Actionそのものが、内部実行ランタイムとしてNode.js 20を使っているケースです。
GitHubのChangelogでは、Node.js 20のEOLを受けてGitHub Actionsでの非推奨化が進められ、2026年6月2日からrunnerがNode.js 24をデフォルトで使い始めると説明されています。事前検証にはFORCE_JAVASCRIPT_ACTIONS_TO_NODE24=trueを使えますが、Node.js 20へ一時的に戻すためのACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=trueは恒久的な回避策ではありません。(The GitHub Blog)
重要なのは、次の2つを分けて考えることです。
| 観点 | 意味 | 例 |
|---|---|---|
| Actionの実行ランタイム | actions/checkoutなどのActionが内部で使うNode.js | actions/checkout@v4がNode.js 20警告の対象になる可能性 |
| プロジェクトのNode.jsバージョン | テストやビルド対象のアプリが使うNode.js | actions/setup-nodeのnode-version: 20や24 |
たとえば、actions/setup-node@v6を使いながら、アプリの都合で一時的にnode-version: 20を指定することは、ActionランタイムのNode.js 24対応とは別の話です。警告対応の第一歩は、setup-nodeでインストールするNode.jsではなく、uses:で参照しているActionのバージョンを確認することです。
microsoft/aspireのPR #15829で更新された内容
microsoft/aspireのPR #15829では、Node.js 20で動作する古いGitHub Actionsを、Node.js 24対応版に更新しています。PR本文とコミット説明では、対象Actionとしてactions/checkout、actions/setup-dotnet、actions/setup-node、actions/upload-artifactが挙げられています。更新は、リポジトリ内の他ワークフローですでに使われていた新しいSHAにそろえる形で行われました。(GitHub)
| 対象ファイル・ジョブ | 更新されたAction | 変更の意味 |
|---|---|---|
.github/workflows/tests.ymlのcli_starter_validation_windows | actions/checkout、actions/setup-dotnet、actions/setup-node、actions/upload-artifact | Windows上のCLIスターター検証ジョブで古いActionを更新 |
.github/workflows/refresh-typescript-sdks.yml | actions/checkout、actions/setup-dotnet | TypeScript SDK更新系ワークフローのActionを更新 |
.github/workflows/reproduce-flaky-tests.yml | actions/upload-artifact | flaky test再現用ワークフローのartifactアップロード処理を更新 |
PRのコミット説明では、代表的な更新としてactions/checkoutはv4.2.2からv6.0.2へ、actions/setup-dotnetはv4.3.1またはv4からv5.2.0へ、actions/setup-nodeはv4.4.0からv6.3.0へ、actions/upload-artifactはv4.6.1からv7.0.0へ変更されています。(GitHub)
ここで注目すべき点は、「全部を最新タグへ雑に置き換えた」のではなく、既存リポジトリ内で使われている互換性確認済みのSHAに合わせていることです。企業やOSSプロジェクトでSHA pinningを採用している場合、actions/checkout@v6のようなメジャータグへ直接置き換えるより、対応するリリースタグのコミットSHAを確認して置き換える運用のほうが、安定性と監査性を保ちやすくなります。
対応が必要なリポジトリの判断基準
GitHub Actionsを使っているすべてのリポジトリが同じ緊急度で対応すべきとは限りません。ただし、次の条件に当てはまる場合は優先度を高くしてください。
actions/*@v4や古いSHAを使っている
actions/checkout@v4、actions/setup-node@v4、actions/upload-artifact@v4のように、古いメジャーバージョンを参照している場合は要確認です。GitHub Docsでは、uses:でActionを指定する際にGit ref、SHA、Docker tagなどでバージョンを明示すること、特に安定性とセキュリティの観点ではリリース版のコミットSHAが最も安全だと説明されています。(GitHub Docs)
ただし、「v4だから必ず失敗する」と機械的に判断するのは危険です。ActionごとにNode.js 24対応のタイミングやバックポート方針が異なるため、各ActionのRelease notesを確認してください。
self-hosted runnerを使っている
GitHub-hosted runnerだけを使っているリポジトリよりも、self-hosted runnerを使っているリポジトリのほうが確認項目は増えます。GitHubのChangelogでは、Node.js 24はmacOS 13.4以下と互換性がなく、ARM32はNode.js 24の公式サポート対象外であることが示されています。(The GitHub Blog)
また、ActionごとのRelease notesでも最低runnerバージョンに触れられています。たとえばactions/setup-nodeではNode.js 24対応リリースでrunner v2.327.1以降が必要とされ、actions/upload-artifact@v6でもNode.js 24実行とrunner 2.327.1以上が説明されています。(GitHub)
独自JavaScript Actionを持っている
自社・自プロジェクトのカスタムActionを.github/actionsや別リポジトリで管理している場合は、action.ymlまたはaction.yamlのruns.usingを確認します。GitHub DocsではJavaScript Actionのruns.usingとしてnode20とnode24が記載されており、Node.js 24を使う場合はruns.using: 'node24'を指定します。(GitHub Docs)
runs:
using: 'node24'
main: 'dist/index.js'独自Actionでは、runs.usingを書き換えるだけでは不十分なことがあります。依存パッケージ、ビルド成果物、ESM/CJS、Node.js標準APIの非推奨警告まで確認してください。
まず確認すべきファイルとコマンド
最初に見る場所は、リポジトリ内の.github配下です。特に.github/workflows/*.yml、.github/workflows/*.yaml、.github/actions/**/action.ymlを確認します。
ローカルで確認するなら、次のように検索すると影響範囲を洗い出しやすくなります。
# ワークフローで使っているActionを一覧する
rg "uses:\s*[^#]+" .github/workflows .github/actions
# Node.js 20で実行される独自JavaScript Actionを探す
rg "using:\s*['\"]node20['\"]" .github
# 主要な公式Actionの古い参照を探す
rg "actions/(checkout|setup-node|setup-dotnet|upload-artifact)@v[1-5]" .githubSHA pinningしている場合は、単純な@v4検索だけでは見つかりません。たとえば次のような指定です。
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70bこの場合は、SHAがどのリリースに対応しているかをActionのリポジトリで確認し、Node.js 24対応済みのリリースタグまたはそのSHAへ更新します。チームでRenovateやDependabotを使っている場合も、SHA pinningの更新ルールが有効になっているか確認してください。
実務で使える移行手順
GitHub ActionsのNode.js 24対応は、全ワークフローを一気に書き換えるより、影響が大きいジョブから順に確認するほうが安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | .github配下のuses:を棚卸し | 公式Action、サードパーティAction、独自Actionに分ける |
| 2 | Node.js 24対応版を確認 | Release notes、README、Marketplace、タグを確認 |
| 3 | 変更PRを小さく作る | CI基盤の変更とアプリ改修を混ぜない |
| 4 | FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=trueで事前検証 | 警告だけでなく失敗ログも確認 |
| 5 | self-hosted runnerを更新 | runnerバージョン、OS、CPUアーキテクチャを確認 |
| 6 | artifact、cache、checkout周りを重点確認 | 保存先、認証情報、キャッシュ挙動の変化に注意 |
公式Actionを更新する
代表的な更新例は次のようになります。実際には各ActionのRelease notesを確認し、プロジェクトの方針に合わせてメジャータグ、固定バージョン、SHAのいずれかを選びます。
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: 24
- uses: actions/upload-artifact@v7
with:
name: test-results
path: test-results/ここでのnode-version: 24は、アプリやテストで使うNode.jsの指定です。Action自体のNode.js 24対応は、actions/setup-node@v6のようにActionの参照バージョンを上げることで行います。両者を混同すると、警告が消えないまま「Node.js 24にしたはず」と誤解しやすくなります。
SHA pinningしている場合の考え方
セキュリティを重視する組織では、次のようにタグではなくSHAでActionを固定していることがあります。
- uses: actions/checkout@de0fac2...この運用では、PR #15829のように「Node.js 24対応版のタグに対応するSHAへ更新する」流れが自然です。タグ参照は読みやすい一方で、セキュリティレビューや再現性の観点ではSHA pinningのほうが望ましい場面があります。GitHub Docsでも、リリース版ActionのコミットSHAを使うことは安定性とセキュリティの面で最も安全とされています。(GitHub Docs)
運用ルールとしては、次のどちらかに寄せると混乱を避けられます。
| 運用 | 向いているケース | 注意点 |
|---|---|---|
actions/checkout@v6のようなメジャータグ | 小規模チーム、更新作業を軽くしたい場合 | メジャータグの中での変更をRelease notesで追う |
| リリースタグ相当のSHA | 監査・再現性・サプライチェーン対策を重視する場合 | RenovateやDependabotでSHA更新を自動化する |
Actionごとの確認ポイント
actions/checkout
actions/checkoutは多くのワークフローの先頭で使われます。古いバージョンのまま残っていると、ほぼすべてのCIで警告が出る原因になります。
PR #15829ではactions/checkoutがv4.2.2からv6.0.2相当へ更新されています。actions/checkoutのRelease notesでは、v6.0.0でNode.js 24サポートに関するREADME更新や認証情報の保存方法変更が含まれ、v6.0.2ではtag handlingの修正などが行われています。(GitHub)
注意したいのは、checkout後にDocker container actionや独自スクリプトでGit認証情報を参照しているケースです。persist-credentialsの挙動や保存場所に依存した処理がある場合、単純なバージョンアップで後続ステップが失敗する可能性があります。
actions/setup-node
actions/setup-nodeは、Node.jsプロジェクトだけでなく、フロントエンドのビルド、Playwright、Docusaurus、TypeScript SDK生成などでも使われます。
PR #15829ではactions/setup-nodeがv4.4.0からv6.3.0相当へ更新されています。actions/setup-nodeのRelease notesでは、v5.0.0でNode.js 24対応が入り、runner v2.327.1以降が必要とされています。また、v6.3.0ではnode-version-file: package.json使用時にdevEngines.runtimeを優先する変更が説明されています。(GitHub)
移行時は、次の点を確認してください。
node-version、node-version-file、.nvmrc、.node-versionのどれでNode.jsを決めているかpackageManagerやlockfileに応じたキャッシュ挙動が変わらないかnpm ci、pnpm install --frozen-lockfile、yarn install --immutableが同じ結果になるか- Node.js 20から24へアプリ側も上げる場合、テストとビルドが通るか
特に、Actionの更新とアプリのNode.js更新を同じPRで行うと、失敗時の原因切り分けが難しくなります。まずActionだけをNode.js 24対応版へ更新し、その後にアプリ側のNode.jsバージョンを見直すほうが安全です。
actions/setup-dotnet
.NET系プロジェクトでは、actions/setup-dotnetの更新も対象になります。PR #15829ではactions/setup-dotnetがv4.3.1またはv4からv5.2.0相当へ更新されています。
actions/setup-dotnetのRelease notesでは、v5.0.0でNode.js 24へのアップグレードと、runner v2.327.1以上への更新が必要であることが示されています。v5.2.0ではworkloads inputやcross-architectureの.NETインストール向けarchitecture inputのサポートが追加されています。(GitHub)
確認すべきポイントは、.NET SDKのバージョン指定とActionのバージョン指定を混同しないことです。
- uses: actions/setup-dotnet@v5
with:
dotnet-version: '9.0.x'この例では、actions/setup-dotnet@v5がActionのバージョンで、dotnet-versionがインストールする.NET SDKのバージョンです。Node.js 24対応で更新するのは前者です。
actions/upload-artifact
actions/upload-artifactは、テスト結果、ビルド成果物、スクリーンショット、ログなどを保存するワークフローで使われます。PR #15829ではactions/upload-artifactがv4.6.1からv7.0.0相当へ更新されています。
actions/upload-artifactのRelease notesでは、v6.0.0でNode.js 24をデフォルトで実行するようになり、self-hosted runnerでは2.327.1以上が必要とされています。v7.0.0では単一ファイルの直接アップロードを可能にするarchiveパラメータやESM対応が説明されています。(GitHub)
移行時は、次のようなartifact周りの仕様を確認してください。
| 確認項目 | なぜ重要か |
|---|---|
pathが複数ファイル・ディレクトリ・globのどれか | direct upload系の新機能と相性を確認するため |
if-no-files-foundの設定 | 成果物がない時にCIを失敗させるか判断するため |
| artifact名の重複 | matrix jobで同名artifactが衝突しないか確認するため |
| 保存対象に秘密情報が含まれないか | ログや成果物にtokenや.envが混入しないようにするため |
事前検証用の設定例
Node.js 24でActionを実行したときの影響を早めに確認したい場合は、ワークフローまたはジョブにFORCE_JAVASCRIPT_ACTIONS_TO_NODE24=trueを設定します。GitHubのChangelogでも、Node.js 24を事前に強制利用する方法としてこの環境変数が案内されています。(The GitHub Blog)
name: CI
on:
pull_request:
push:
env:
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: 24
- run: npm ci
- run: npm testこの設定は、移行前の検証に役立ちます。ただし、警告が出なくなっただけで安全と判断しないでください。次のような観点でログを見る必要があります。
uses:で呼び出した各Actionが失敗していないか- cache restore/saveの挙動が変わっていないか
- artifactのアップロード・ダウンロード結果が同じか
- checkout後のGit操作、submodule、LFS、認証情報が問題なく動くか
- matrix jobやWindows/macOS runnerでも同じように通るか
失敗しやすいポイント
警告が出たActionだけを更新して終わる
GitHub Actionsの警告は、実行されたジョブに出ます。つまり、普段動いていないworkflow、手動実行のworkflow、scheduleだけで動くworkflowに古いActionが残っていることがあります。
.github/workflows全体を検索し、push、pull_request、workflow_dispatch、schedule、release、deploymentなど、すべてのトリガーを対象に棚卸ししてください。
サードパーティActionの対応状況を確認しない
公式Actionだけでなく、サードパーティActionもJavaScript ActionであればNode.js 20非推奨の影響を受ける可能性があります。特に、数年前から更新されていないAction、リポジトリがアーカイブされているAction、READMEにNode.js 24対応が明記されていないActionは注意が必要です。
代替案は次の順で検討すると現実的です。
| 状況 | 対応案 |
|---|---|
| 新しいメジャーバージョンがある | Release notesを確認して更新 |
| メンテナンスが止まっている | 代替Actionへ移行 |
| 小さな処理だけをしている | run:ステップへ置き換える |
| 自社利用で重要度が高い | forkしてruns.using: node24対応を検討 |
setup-nodeの更新とアプリのNode.js更新を混ぜる
Node.js 24対応という言葉だけを見ると、アプリのNode.jsも同時に20から24へ上げたくなります。しかし、CI基盤のAction更新とアプリ実行環境の更新は、影響範囲が違います。
まずは次のように分けてください。
1つ目のPRでは、actions/checkoutやactions/setup-nodeなどのAction参照だけを更新します。2つ目のPRで、必要に応じてnode-version、Docker image、package engine、lockfile、テストを更新します。
この順番にすると、CIが失敗したときに「Actionの互換性問題」なのか「アプリがNode.js 24で動かない問題」なのかを切り分けやすくなります。
self-hosted runnerの更新を後回しにする
GitHub-hosted runnerではなくself-hosted runnerを使っている場合、Actionだけを更新してもrunner側が古いと失敗する可能性があります。各ActionのRelease notesで最低runnerバージョンを確認し、OSとアーキテクチャも合わせて確認してください。
特に注意が必要なのは、古いmacOSを使っているrunner、ARM32環境、長期間更新していないオンプレミスrunnerです。Node.js 24の非互換条件に該当する場合は、runner更新だけでなく、ホストOSやハードウェアの見直しが必要になります。(The GitHub Blog)
チームで進める場合のチェックリスト
対応漏れを防ぐには、個別の警告対応ではなく、リポジトリ運用のチェックリストに落とし込むのが効果的です。
| チェック項目 | 完了条件 |
|---|---|
.github/workflows内のuses:を一覧化した | 公式Action、外部Action、独自Actionに分類済み |
| Node.js 20で動くActionを特定した | 対象Actionとファイル名がPRに記載されている |
| 公式ActionをNode.js 24対応版へ更新した | Release notesを確認済み |
| SHA pinningの更新方針を決めた | タグ運用かSHA運用かが明確 |
| self-hosted runnerを確認した | runnerバージョン、OS、CPUアーキテクチャを確認済み |
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24で検証した | 主要workflowが成功している |
| artifact、cache、checkoutの挙動を確認した | 成果物・キャッシュ・認証情報に問題がない |
| DependabotまたはRenovateの設定を見直した | 今後のAction更新が検知される |
まとめ：まずは.github配下の棚卸しから始める
今回のGitHub Actions Node.js 24対応は、単なる定期的なバージョンアップではありません。2026年6月2日以降、runner側でNode.js 24がデフォルトになるため、Node.js 20で動く古いJavaScript Actionを放置すると、警告だけでなくワークフロー失敗につながる可能性があります。(The GitHub Blog)
microsoft/aspireのPR #15829は、actions/checkout、actions/setup-dotnet、actions/setup-node、actions/upload-artifactを対象に、影響範囲を絞ってNode.js 24対応版へ更新した実例です。自分のリポジトリでも、まず.github/workflowsと.github/actionsを検索し、古いAction、SHA pinning、self-hosted runner、独自Actionのruns.usingを確認してください。
次に取るべき行動は明確です。.github配下のAction参照を一覧化し、Node.js 24対応版へ更新するPRを小さく作り、FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=trueで主要ワークフローを検証しましょう。CI基盤の更新とアプリ本体のNode.js更新を分けて進めることが、短期間で安全に移行するための最も現実的な方法です。
コメント