GitHub ActionsはNode 24既定へ：Node 20非推奨、runner更新、self-hosted確認ポイント

3行まとめ

Node 24既定

JavaScript Action本体をrunnerが実行するときの既定ランタイムがNode 24へ移る。

runs.usingの確認

`actions/setup-node`の`node-version`ではなく、Action metadataの`runs.using`を確認する。

runner/OS/CPU

self-hosted runnerではrunner binary、OS、architectureの条件も合わせて見る。

Node.jsアプリをNode 20でテストする話と、JavaScript Action本体の実行ランタイムは分けて判断します。

GitHub Actionsは、2026年6月16日以降、JavaScript Actionsを実行する既定ランタイムをNode 24へ移す段階に入ります。これはactions/setup-nodeで指定するアプリ側のNode.jsバージョンとは別の話です。

既存workflowが一律に同じ日に止まる、という変更ではありません。リスクは、runs.using: node20の自作Action、古い外部Action、Node 24に合わないself-hosted runner環境、macOS 13.4以下やARM32のようなOS/architecture条件で表面化します。

一時回避としてACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=trueは用意されていますが、Node 20はrunnerから秋に削除される予定です。恒久対応は、Action本体、runner、OS/CPUをNode 24前提で棚卸しすることです。

何が変わるのか。Node 24既定とNode 20非推奨を分ける

1. 2025年9月19日Node 20非推奨を案内

   GitHub Actions runner上のNode 20非推奨がChangelogで案内された。

2. 2026年5月19日移行日を更新

   editor noteで移行日が2026年6月16日に更新された。

3. 2026年6月16日Node 24既定化

   JavaScript Actionsを実行する既定ランタイムをNode 24へ移す段階に入る。

4. 2026年秋予定Node 20削除予定

   Node 20 opt-outはrunnerからNode 20が削除されるまでの一時策として扱う。

Node 24強制用の環境変数は、互換性を先に試すための確認手段です。

GitHubは2025年9月19日のChangelogで、GitHub Actions runner上のNode 20非推奨を案内しました。その後、2026年5月19日のeditor noteで移行日が2026年6月16日に更新されています。この記事では2026年6月16日JST時点の一次情報をもとに、利用者と管理者が見るべき範囲を整理します。

ここで大事なのは、変更対象が「workflowで実行する自分のNode.jsアプリ」ではなく、「JavaScript Action本体をrunnerがどのNode.jsで実行するか」だという点です。たとえば、アプリのテストでactions/setup-nodeを使い、node-version: 20を指定していること自体が、今回の告知で即禁止されるわけではありません。

2026年6月16日からNode 24が既定になる

GitHub Changelogは、runner v2.328.0がNode 20とNode 24の両方をサポートし、当初はNode 20を既定として使うこと、事前検証用の環境変数でNode 24を強制できることを示しています。そのうえで、2026年6月16日以降、runnerはNode 24を既定として使い始める、と説明しています。

つまり、読み方は「Node 24対応runnerが出た」だけでは足りません。実際の運用では、使っているActionがNode 24で動くか、self-hosted runnerが新しいrunnerへ追随しているか、古いOSやARM32のような制約に引っかからないかを見ます。

根拠

主な根拠は、GitHub Changelog、actions/runner v2.328.0 release、GitHub Docsのmetadata syntax、self-hosted runners reference、Node.js公式のprevious releasesです。GitHub CommunityやOSS issueで警告相談が増えていることは需要シグナルとして見ていますが、日付や仕様の根拠には使っていません。

Node 20 opt-outは秋までの一時策

2026年6月16日以降も、ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=trueを設定すれば、当面Node 20を使い続けられるとGitHubは説明しています。ただし、これは秋にrunnerからNode 20が削除されるまでの一時的な逃げ道です。

環境変数名にUNSECUREが含まれていることも軽く見ないほうがよいです。Node.js公式のprevious releasesでは、Node 20はすでにEOLの扱いになっています。どうしても短期復旧に使う場合は、対象workflow、理由、担当者、削除予定日、恒久対応のissueをセットで残すべきです。

事前検証はFORCE_JAVASCRIPT_ACTIONS_TO_NODE24で行う

Node 24へ先に寄せてテストするには、GitHubが示しているFORCE_JAVASCRIPT_ACTIONS_TO_NODE24=trueを使います。workflowのenv、またはrunner machine側の環境変数として使えるものです。

ただし、いきなり全workflowへ入れるより、低リスクのworkflow、代表的な外部Action、社内Action、self-hosted runner labelを選んで試すほうが現実的です。目的は警告を隠すことではなく、Node 24で落ちるActionやrunner環境を見つけることです。

上振れ/下振れ

すでに利用ActionがNode 24対応済みなら、警告が減り、対応は小さく済みます。一方で、古いAction、社内fork、dist/に古い依存を含むJavaScript Action、古いself-hosted runner、macOS 13.4以下やARM32の環境がある場合、単純な設定変更では終わりません。

既存workflowは即止まるのか

1. 1GitHub-hosted runner中心か

   runner binaryの更新はGitHub側が管理するため、まず警告と利用Actionのversionを確認する。

2. 2self-hosted runnerがあるか

   runner version、OS、architecture、自動更新の有無を確認する。

3. 3自作Actionや古い外部Actionがあるか

   Action metadataの`runs.using`、固定SHA、社内fork、ローカルActionを棚卸しする。

4. 4Node.jsテスト対象と分ける

   workflow内でアプリをNode 20でテストする設定は、Action本体の実行ランタイムとは別に読む。

一律に止まるかどうかではなく、どのActionがどのrunnerで動くかを見ます。

一律の答えはありません。GitHub-hosted runnerだけを使い、利用Actionも更新されているなら、管理者がrunner binaryを入れ替える作業はほぼありません。一方、self-hosted runner、自作JavaScript Action、古い外部Action、古いOSやARM32を使っている場合は、CI/CD停止リスクとして棚卸しが必要です。

ここを誤ると、「Node 20プロジェクトはGitHub Actionsでテストできなくなるのか」という別の話にずれてしまいます。今回の中心は、Action本体の実行ランタイムです。workflow内で自分のアプリをNode 20、Node 22、Node 24などでテストする話とは分けて読みます。

GitHub-hosted runner中心なら、まず警告と利用Actionを確認する

GitHub-hosted runnerだけを使っている場合、runner環境の更新はGitHub側が管理します。それでも、workflowでuses:しているActionの中にNode 20前提のものが残っていれば、警告や将来の失敗につながります。

最初に見るべきものは、workflow logの警告、.github/workflows/内のuses:、ローカルActionのaction.yml、古いcommit SHAで固定したActionです。公式Actionだから安全、Marketplaceにあるから安全、という扱いにはしません。利用しているrefが古ければ、更新済みの実装に乗れていない可能性があります。

self-hosted runnerはrunner版、OS、architectureを見る

self-hosted runnerがある組織では、runner v2.328.0がNode 20からNode 24への移行機能を含む起点になります。ただし、v2.328.0を入れれば長期的に完了、という意味ではありません。GitHub Docsは、self-hosted runnerが既定で自動更新されること、自動更新を無効にした場合も新しいrunner release公開後30日以内の更新が必要になることを説明しています。

この論点は、すでに取り上げた<a href="https://msft-watch.blog.mo-gmo.com/msft-49-github-actions-self-hosted-runner-minimum-version-enforcement/">GitHub Actionsのself-hosted runner最低バージョン適用</a>ともつながります。今回の記事はNode 24実行ランタイムの変更、前回の記事はrunner最低バージョンと登録/ジョブ実行要件の確認として分けて読むと、運用タスクを整理しやすくなります。

workflow内のNode.jsテスト対象とは別に読む

たとえば、次のようなworkflowがあるとします。

steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-node@v5
    with:
      node-version: 20
  - run: npm test

このnode-version: 20は、アプリやライブラリのテストに使うNode.jsを指定しているだけです。今回のGitHub Changelogが直接扱っているのは、actions/checkoutや自作ActionのようなAction本体をrunnerが実行するときのNode.jsです。

確認項目

• .github/workflows/内のuses:を一覧にする。
• ローカルActionのaction.ymlまたはaction.yamlを確認する。
• runs.using: node20を含むJavaScript Actionを探す。
• 古いtag、古いmajor version、commit SHA固定、社内forkを確認する。
• self-hosted runnerのversion、runner group、label、OS、architectureを記録する。
• runner machine側にACTIONS_ALLOW_USE_UNSECURE_NODE_VERSIONが設定されていないか確認する。

注意点

セキュリティ上の理由でActionをcommit SHA固定しているチームは多いはずです。その方針自体は自然ですが、固定したSHAを更新する手順がないと、Action側のNode 24対応が公開されても、自分のworkflowだけ古い実装を使い続けます。固定と更新はセットで設計してください。

Action保守者はaction.ymlのruns.usingを見る

JavaScript Action

`runs.using`がAction本体のNode.jsランタイムを決める。

Composite Action

step内で呼ぶActionやshell処理を分けて確認する。

Docker Action

container image側のNode.jsと依存関係も確認する。

対応完了は、Node 24でActionのテストが通り、代表workflowで実行でき、利用者向けrelease/tagが更新されることまで見ます。

自作Actionや社内共通Actionを持っているチームは、利用者より一段深く確認します。見る場所は、Action metadataです。GitHub Docsのmetadata syntaxでは、JavaScript Actionのruns.usingにnode20とnode24が示されています。

ただし、すべてのaction.ymlをnode24へ書き換える、という作業ではありません。JavaScript Action、Composite Action、Docker container Actionでは、確認する場所と修正内容が違います。

JavaScript Actionはnode24へ移す

JavaScript Actionでは、runs.usingがAction本体をどのNode.jsランタイムで実行するかを決めます。Node 24対応へ進めるなら、たとえば次のようなmetadataを確認します。

runs:
  using: "node24"
  main: "dist/index.js"

mainだけでなく、preやpostを使っているActionも同じruntime指定の影響を受けます。runs.usingを書き換えるだけで終わりにせず、Node 24で実行したときに依存パッケージ、ファイルパス、ESM/CommonJS、ネイティブ依存、外部コマンド呼び出しが問題ないかを確認します。

Composite ActionとDocker Actionは同じ修正ではない

Composite Actionはruns.using: compositeで、複数のshell stepやAction呼び出しを束ねます。Docker container Actionはruns.using: dockerです。これらをJavaScript Actionと同じようにnode24へ書き換えると、Actionそのものが壊れます。

ただし、Composite Actionの中で呼び出している外部ActionがNode 20前提なら、その外部Actionは確認対象です。Docker Actionでも、コンテナ内でNode 20を使うかどうかは別の話として存在します。今回のGitHub Actions runnerのJavaScript Actions実行ランタイム変更と、コンテナ内のアプリ runtimeは分けて見ます。

依存パッケージとdist成果物を更新する

JavaScript Actionは、TypeScriptやbundlerで作ったdist/をリポジトリに含めて配布していることがあります。その場合、package.jsonやlockfileだけを更新しても、利用者が実行するdist/index.jsが古いままなら意味がありません。

Action保守者は、Node 24でinstall、build、testを行い、dist/やrelease tagまで更新します。利用者向けには、どのmajor versionまたはtagからNode 24対応なのか、runnerの最低versionがあるのか、破壊的変更があるのかをrelease noteに残すと、移行が進めやすくなります。

評価基準

対応完了の目安は、runs.usingがnode24になっていることだけではありません。Node 24でActionのテストが通り、代表workflowで動き、pre/postも確認済みで、利用者が参照するtagまたはreleaseが更新されていることです。

Action種別	runs.usingの例	Node 24移行で見る場所	主な注意点
JavaScript Action	node20またはnode24	main、pre、post、依存、dist/	node24対応と実行テストが必要
Composite Action	composite	内部のstep、呼び出し先Action	直接node24へ書き換えない
Docker Action	docker	Dockerfile、base image、entrypoint	runnerのJavaScript Action runtimeとは別に確認

Action利用者はusesしているActionを棚卸しする

公式Action

`actions/checkout`、`actions/setup-node`、`actions/cache`などのmajor versionと固定SHAを確認する。

外部Action

README、release、Marketplace、issueでNode 24対応状況を確認する。

社内Action/fork

社内共通Action、fork、古いcommit SHA固定を一覧化し、更新手順を決める。

ローカルAction

`./.github/actions/`配下の`action.yml`または`action.yaml`を確認する。

reusable workflow

workflow templateや手動実行workflowに古いActionが残っていないか見る。

release、deployment、security scan、cache、artifactを扱うworkflowは、先に低リスク環境で試します。

Action利用者は、社内で自分が保守していないActionも見ます。workflowが成功しているから大丈夫、警告が出ていないから大丈夫、とは限りません。低頻度のrelease workflow、手動実行workflow、障害時だけ使うメンテナンスworkflowほど、古いActionが残りやすくなります。

公式Actionと外部Actionのバージョンを確認する

actions/checkout、actions/setup-node、actions/cacheのような公式Actionでも、利用しているmajor versionや固定SHAを確認します。たとえば、GitHub公式の個別ActionにはNode 24対応版が出ているものがありますが、自分のworkflowが古いrefを見ていれば更新の恩恵を受けません。

この記事では個別Actionの最新一覧を作り込みません。最新versionは変わるためです。代わりに、各ActionのREADME、release、Marketplace、GitHub Changelogを確認し、Node 24対応、runner最低version、破壊的変更の有無を確認する流れにします。

社内Actionとforkが見落としやすい

見落としやすいのは、./.github/actions/...のローカルAction、社内organizationの共通Action、外部Actionのfork、古いテンプレートからコピーされたworkflowです。Marketplaceに出ていないものは、誰かが更新してくれるとは限りません。

社内Actionの利用先が多い場合は、まず検索でruns.using: node20を探し、次にuses:でそのActionがどのリポジトリから呼ばれているかを追います。GitHub Advanced SecurityやCodeQL、release、deployment、artifact、cacheなど、権限や成果物に触るActionは特に慎重に更新します。

Dependabotや更新PRの扱いも決める

Actionのmajor version更新は、通常の依存更新と同じくレビューが必要です。Dependabotなどで更新PRを作る場合でも、GITHUB_TOKEN権限、fork PR、環境保護ルール、artifact、cache、release作成への影響を確認します。

GitHub Actionsまわりでは、bot-created pull requestのworkflow承認やGITHUB_TOKEN運用も更新が続いています。権限や承認の文脈は、<a href="https://msft-watch.blog.mo-gmo.com/msft-51-github-actions-bot-created-pr-workflows-approval-github-token/">GitHub Actionsでbot作成PRが承認後にCI実行可能になる件</a>も合わせて読むと、Action更新PRの扱いを考えやすくなります。

確認項目

• 公式Action、外部Action、社内Actionのmajor versionを確認する。
• 古いcommit SHA固定を一覧化し、更新手順を決める。
• ./.github/actions/配下のローカルActionを確認する。
• reusable workflowやworkflow templateに古いActionが残っていないか見る。
• release、deployment、security scan、cache、artifactを扱うworkflowは先に低リスク環境で試す。

注意点

Node 20警告を消すためだけに、未検証のmajor versionへ一括更新するのは危険です。Actionのmajor updateには、入力名、出力、認証、保存場所、cache仕様、artifact仕様の変更が含まれることがあります。警告対応とworkflowの権限変更を同じPRに詰め込みすぎないほうが、レビューしやすくなります。

self-hosted runnerはNode 24移行とrunner更新を同時に見る

1. 1runner release

   actions/runner v2.328.0以降のNode 20/Node 24移行機能とfeature flagを確認する。

2. 2更新ポリシー

   自動更新を止めているrunnerは、固定理由と更新計画を確認する。

3. 3実行基盤

   常設VM、コンテナ、ARC、golden imageを分けて、どこに古い環境が残るかを見る。

4. 4対象workflow

   runner label、通信経路、低頻度workflowを含めて代表実行を試す。

latest releaseだけで判断せず、自分のenterprise、organization、repositoryで案内されるdownload instructionsも確認します。

self-hosted runnerを運用している場合、Node 24対応はActionだけの問題ではありません。runner binary、runner image、OS、CPU、更新ポリシー、通信経路、オートスケール方式が関係します。

v2.328.0はNode 20/Node 24移行の起点

actions/runner v2.328.0 releaseには、Node 20からNode 24への移行に関するfeature flagging、opt-in/opt-out環境変数が含まれています。これは、Node 24移行を扱ううえで重要な起点です。

一方で、v2.328.0を固定すれば十分、とは書けません。runner releaseにはprogressive release policyがあり、latest releaseと自分のenterprise、organization、repositoryで案内されるdownload instructionsが完全に一致しない場合があります。運用上は、管理画面やdownload instructionsで対象環境のrunner版を確認します。

自動更新を止めているrunnerは特に注意する

GitHub Docsは、self-hosted runnerが既定で自動更新されることを説明しています。自動更新を止めるには、登録時に--disableupdateを指定します。コンテナやephemeral runnerでは、自動更新が毎回走ることを避けるために、イメージ側でrunner versionを管理する設計もあります。

ただし、自動更新を止めても更新義務が消えるわけではありません。GitHub Docsは、自動更新を無効にした場合、新しいrunner versionが利用可能になってから30日以内に更新する必要があると説明しています。30日を超えると、GitHub Actions serviceがそのrunnerへjobをqueueしない可能性があります。

常設VM、コンテナ、ARC、golden imageを分ける

常設VMに手動でrunnerを入れている場合は、runner install directory、実行ユーザー、service化、更新権限を確認します。コンテナやephemeral runnerなら、Dockerfile、base image、entrypoint、runner download URL、イメージの再作成タイミングを見ます。

Actions Runner Controllerやrunner scale setを使っているなら、controller、runner image、scale set client、Kubernetes manifest、helm chart、社内ミラー、Packer template、AMI、VM imageも対象です。普段のrunnerが新しくても、障害復旧やスケールアウトで古いrunnerが再生成される構成では、そこで詰まります。

条件

self-hosted runnerは、GitHubへjob assignmentを受け取り、新しいrunner applicationをdownloadするための通信が必要です。Firewall、proxy、証明書検査、社内ミラーを使っている環境では、runner releaseを取得できるかも確認してください。

運用資産	見る場所	失敗しやすい点
常設VM	runner directory、service、実行ユーザー	自動更新権限がない
ephemeral container	Dockerfile、base image、entrypoint	起動するたび古いrunnerになる
ARC/runner scale set	controller、runner image、manifest	scale-out時だけ古いrunnerが出る
golden image	AMI、VM image、Packer template	障害復旧時に古いrunnerが復活する
社内ミラー	配布tarball、社内wiki、proxy	最新release取得に失敗する

古いOSとARM32で何が起きるのか

macOS 13.4以下

Node 24非互換として、runner移行やworkflow移管を検討する。

ARM32

Node 20非推奨後のサポート外化を前提に代替先を決める。

その他の環境

Docsの対応表だけでなく、Node 24での実行結果を確認する。

GitHub Docs上の一般的なself-hosted runner対応と、Node 24移行時の制約は分けて読みます。

GitHub Changelogは、Node 24移行に伴うOS/architectureの制約にも触れています。ここはself-hosted runner運用者が見落としやすいところです。Actionのコードを直しても、runner machine側がNode 24に合わなければ失敗します。

macOS 13.4以下はNode 24非互換として扱う

GitHub Changelogは、Node 24がmacOS 13.4以下と互換性がないと説明しています。古いMac miniや固定されたmacOS imageをself-hosted runnerとして残しているチームは、OS upgrade、runner移行、該当workflowの移管を検討する必要があります。

GitHub Docsのself-hosted runners referenceでは、macOS 11.0以降がsupported operating systemsとして示されています。ただし、Node 24移行ではChangelog側のmacOS 13.4以下非互換も合わせて読みます。Docs上の一般的なrunner対応条件と、今回のJavaScript Actions runtime移行に伴う制約を混同しないことが大事です。

ARM32 self-hosted runnerはNode 20非推奨後にサポート外へ向かう

GitHub Changelogは、Node 24がARM32を公式サポートしていないため、Node 20非推奨後にARM32 self-hosted runnerがサポートされなくなると説明しています。古いRaspberry Pi、組み込み機器、社内ラボ用の軽量runnerを使っている場合は、Linux ARM64またはx64環境へ移す計画が必要です。

ここでも、GitHub Docs上のself-hosted runner referenceにはARM32がprocessor architectureとして載っています。だから安全、とは読めません。Node 24移行では、GitHub ChangelogのNode 24/ARM32制約を合わせて判断します。

GitHub Docsの対応OS/architectureも合わせて見る

self-hosted runnerの一般要件として、LinuxではRHEL 8以降、CentOS 8以降、Debian 10以降、Ubuntu 20.04以降などが示されています。WindowsはWindows 10/11 64-bitやWindows Server 2016/2019/2022、macOSは11.0以降です。processor architectureはx64、ARM64、ARM32が示されています。

Node 24移行では、この一般要件に加えて、macOS 13.4以下とARM32の注意を重ねて見ます。特に長く動いているself-hosted runnerは、OSやCPUよりもworkflow labelだけで管理されていることがあります。label名だけで判断せず、実機のOS、architecture、runner versionを確認してください。

注意点

古いOSやARM32は、普段の軽いworkflowでは問題が見えないことがあります。問題が出るのは、特定のJavaScript Action、pre/post step、release workflow、月に数回だけ動くメンテナンスworkflowかもしれません。低頻度workflowまで棚卸し対象に入れる理由はここにあります。

移行の確認手順。まず小さく探して、代表workflowで試す

1. 1探す

   ローカルActionの`runs.using: node20`とworkflow内の`uses:`を分けて検索する。

2. 2分類する

   公式Action、外部Action、社内Action、self-hosted runnerを分ける。

3. 3Node 24で試す

   Node 24強制用の環境変数で低リスクworkflowから代表実行する。

4. 4直す

   失敗箇所をAction、runner、OS/CPUに切り分けて修正する。

5. 5opt-outを外す

   一時回避策に依存していないことを確認して削除する。

6. 6監視する

   警告、workflow log、runner log、低頻度workflowを継続確認する。

移行完了は、代表workflowがNode 24で通り、警告が消え、Node 20 opt-outに依存していない状態です。

移行作業は、全リポジトリへ一括変更を入れるより、検索、分類、代表workflowでの検証、修正、opt-out削除、監視の順で進めると安全です。Node 24移行はCI/CD基盤の変更なので、普段の依存更新よりも失敗時の影響範囲を先に決めておきます。

リポジトリ内のnode20指定とusesを探す

まず、ローカルActionとworkflowを分けて検索します。例としては、次の観点です。

rg "runs\\.using:.*node20|using: ['\\\"]node20|uses:" .github

実際のリポジトリでは、Actionが.github/actions/以外に置かれていることもあります。社内共通Actionが別リポジトリにある場合は、organization単位の検索やcode searchも使います。検索で見つけたものを、JavaScript Action、Composite Action、Docker Action、外部Action、reusable workflowに分類します。

Node 24強制で代表workflowを試す

次に、FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=trueを使い、代表workflowをNode 24前提で試します。いきなり本番release workflowではなく、低リスクのbuild、test、lint、security scan、staging deployなどから始めます。

見る場所は、workflow logだけではありません。self-hosted runnerならrunner machine側のlog、_diag、service log、container logも見ます。失敗した場合、ActionコードがNode 24非互換なのか、依存Actionが古いのか、runner/OS/architectureが原因なのかを分けて記録します。

失敗したらAction、runner、OS/CPUに切り分ける

Node 24強制で落ちた場合、まずAction本体のエラーを見ます。main、pre、postのどこで落ちているか、require/import、native dependency、filesystem、external commandに問題があるかを確認します。

次にrunner環境を見ます。runner versionが古い、self-hosted runnerの自動更新が止まっている、OSが古い、ARM32で動いている、proxyで更新や外部通信が詰まる、といった原因です。最後に、workflow内でテストしているアプリ側Node.jsの問題と混同していないかを確認します。

評価基準

移行完了と見なす目安は、代表workflowがNode 24で通ること、Node 20警告が解消していること、ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSIONに依存していないこと、self-hosted runnerの古いOS/ARM32に代替方針があることです。加えて、更新済みActionのtagやSHAが社内テンプレートにも反映されているかを確認します。

一時回避策を使う場合の線引き

対象を絞る

組織全体やrunner machine側へ広く入れる前に、必要なworkflowだけに限定する。

理由を残す

どのActionがNode 24で失敗するのか、なぜ必要なのかを記録する。

担当を決める

誰がAction更新、runner更新、OS/CPU移行を進めるのかを決める。

期限を置く

秋のNode 20削除予定を前提に、削除条件と確認日を設定する。

変数名に含まれる「unsecure」を軽く扱わず、恒久対応のissueと紐づけて管理します。

ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=trueは、短期復旧には役立ちます。しかし、この設定を恒久対応のように扱うと、秋のNode 20削除で再び詰まります。例外運用として使うなら、期限と削除条件を決めます。

ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSIONは期限付き

GitHub Changelogは、Node 20 opt-outが秋にNode 20をrunnerから削除するまでの一時的なものだと説明しています。したがって、opt-outを設定したworkflowには、なぜ必要なのか、どのActionがNode 24で失敗するのか、誰が直すのか、いつ削除するのかを残します。

環境変数を組織全体やrunner machine側へ広く入れると、どのworkflowが本当に困っているのか分かりにくくなります。最初は対象を絞り、恒久対応のissueと紐づけるほうが安全です。

全体に入れる前に影響範囲を絞る

止まると困るrelease workflowや顧客向けdeploy workflowに限って一時回避を使う、という判断はあり得ます。ただし、その場合も、低リスクworkflowではNode 24強制検証を続け、原因のあるActionを直す必要があります。

一時回避を入れたあとに警告が減ると、対応が終わったように見えます。実際には、EOLのNode 20を使い続けているだけです。運用カレンダーやチケットに削除日を置き、月次レビューで残っていないかを見るのがよいです。

安全ではないNode versionという名前を軽く扱わない

UNSECURE_NODE_VERSIONという名前は、単なる警告文ではありません。Node 20がEOLに入った後もAction本体をNode 20で実行し続けることを意味します。外部からのpull request、token、artifact、release、deploymentを扱うworkflowでは、とくに例外運用の範囲を狭くします。

条件

opt-outを使う場合は、対象workflow、理由、失敗しているAction名、削除予定日、担当者、恒久対応PRを記録します。設定は広く入れすぎず、Node 24対応が完了したら削除確認まで行います。

公開後に更新を追うポイント

GitHub Changelog

Node 24既定化の進捗、Node 20削除時期、OS/architectureの注意を確認する。

actions/runner releases

latest release、progressive release policy、環境別download instructionsを見る。

GitHub Docs

metadata syntaxとself-hosted runners referenceを合わせて確認する。

OSS issue

警告文やつまずきやすい箇所を拾い、仕様や期限は一次情報へ戻って確認する。

この記事の確認時点と、自分の導入時点の公式情報を必ず照合します。

GitHub Actionsのrunner、Docs、Changelogは更新タイミングが揃わないことがあります。この記事では2026年6月16日JST時点の一次情報を確認していますが、導入前には必ず公式ページを再確認してください。

GitHub Changelogとactions/runner releasesを再確認する

Changelogでは、Node 24既定化の進捗、Node 20削除時期、OS/architectureの注意が更新される可能性があります。actions/runner releaseでは、latest release、対象environmentで案内されるdownload instructions、progressive release policyを見ます。

runner releaseのページには、v2.328.0でNode 20からNode 24へのmigration feature flagging、opt-in/opt-out環境変数が入ったことが示されています。今後の実運用では、v2.328.0だけでなく、最新releaseと自社環境への配布状態を確認します。

GitHub Docsはmetadataとself-hosted runnerの両方を見る

Action保守者はmetadata syntaxを見ます。runs.usingでnode20とnode24がどう扱われるか、main、pre、postがどのruntimeで実行されるかを確認します。

self-hosted runner運用者はself-hosted runners referenceを見ます。対応OS、processor architecture、自動更新、--disableupdate、30日以内更新、通信要件、ephemeral runner、ARCの考え方が分かれています。Node 24移行だけを切り出さず、runner運用全体と合わせて見ます。

需要シグナルは警告文とOSS issueから拾う

GitHub CommunityやOSS issueは、読者がどこでつまずいているかを見るには役立ちます。たとえば、Node 20警告が出るがどのActionを更新すればよいか分からない、公式Actionのmajor updateへどう移るべきか分からない、といった相談です。

ただし、移行日、削除時期、サポート条件、環境変数の意味は一次情報に戻って確認します。二次情報や古いissueには、過去の移行日や古い警告文が残っていることがあります。

導入判断のまとめ

1. 1設定を分ける

   `actions/setup-node`の`node-version`とAction metadataの`runs.using`を分ける。

2. 2Actionを棚卸しする

   公式Action、外部Action、社内Action、ローカルAction、固定SHAを確認する。

3. 3runnerを確認する

   self-hosted runnerではversion、OS、architecture、自動更新を確認する。

4. 4代表workflowで試す

   低リスク環境でNode 24強制実行を行い、失敗箇所を切り分ける。

5. 5例外を閉じる

   一時回避策を使う場合も、期限、担当、削除条件を決める。

Action本体、利用workflow、self-hosted runner、OS/CPUを分けて見ることが実務上の近道です。

GitHub ActionsのNode 24既定化は、Node.js一般のバージョンアップ記事として読むより、CI/CD基盤の棚卸しとして扱うほうが実務的です。Action本体、利用workflow、self-hosted runner、OS/CPUを分けて見る必要があります。

導入担当者の判断順は次の通りです。

1. actions/setup-nodeのnode-versionと、Action metadataのruns.usingを分ける。
2. .github/workflows/のuses:とローカルActionを棚卸しする。
3. runs.using: node20のJavaScript ActionをNode 24でテストする。
4. 外部Action、公式Action、社内fork、古いSHA固定を更新対象に入れる。
5. self-hosted runnerのversion、自動更新、OS、architecture、runner imageを確認する。
6. macOS 13.4以下、ARM32、古いLinux/Windows/macOSを別枠で確認する。
7. ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSIONは期限付きの一時回避としてだけ使う。
8. GitHub Changelog、runner release、GitHub Docs、Node.js公式情報を公開前と導入前に再確認する。

まずは小さく検索し、代表workflowでNode 24強制を試す。そこで出た失敗をAction、runner、OS/CPUに分けて直す。この順番なら、6月16日以降の運用変更を小さく試しながら進められます。

次に読むなら

更新履歴・非提携表記

1. 2026年6月16日JST一次情報を確認

   GitHub Changelog、actions/runner v2.328.0 release、GitHub Docs、Node.js official previous releasesを確認した。

2. 導入前対象環境を再確認

   対象リポジトリ、runner group、OS/architecture、利用Actionのreleaseを再確認する。

3. 表記独立サイトとして掲載

   Microsoft Watch JapanはMicrosoft Corporation、GitHub, Inc.および関係会社と提携していない独立サイトです。

runner、Docs、Changelogは今後更新される可能性があります。

2026年6月16日JSTに、GitHub Changelog、actions/runner v2.328.0 release、GitHub Docs metadata syntax、GitHub Docs self-hosted runners reference、Node.js official previous releasesを確認しました。GitHub Actionsのrunner、Docs、Changelogは今後更新される可能性があります。導入前には、対象リポジトリ、runner group、OS/architecture、利用Actionのreleaseを再確認してください。

Microsoft Watch JapanはMicrosoft Corporation、GitHub, Inc.および関係会社と提携していない独立サイトです。Microsoft、GitHub、GitHub Actions、Node.jsなどの名称は各社の商標または登録商標です。この記事は製品・サービス情報の整理であり、投資助言ではありません。

GitHub Actions、GitHub Copilot、Windows、Azure、Microsoft 365の開発者向け更新を継続して追う場合は、<a href="https://msft-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月重要トピックまとめ</a>、<a href="https://msft-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>、<a href="https://msft-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>も利用できます。本文の確認を終えた後の補助導線として置いています。

参照した主な情報源

• GitHub Changelog「Deprecation of Node 20 on GitHub Actions runners」

Deprecation of Node 20 on GitHub Actions runners

• actions/runner release「v2.328.0」

https://github.com/actions/runner/releases/tag/v2.328.0

• GitHub Docs「Metadata syntax reference」

https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax

• GitHub Docs「Self-hosted runners reference」

https://docs.github.com/en/actions/reference/runners/self-hosted-runners

• Node.js公式「Previous Releases」

https://nodejs.org/en/about/previous-releases