GitHub ActionsのNode 20非推奨に備え、Claude Codeでworkflowを更新する

GitHub Actionsは、Node 20で動くActionを段階的に廃止してきました。告知では、2026年6月16日にrunnerの既定がNode 24へ変わり、2026年9月23日にNode 20そのものが取り除かれる予定とされていました。どちらの日付も過ぎています。Node 20宣言のActionが残っているworkflowは、失敗しうる状態です。対応は、uses:行を、Node 24で動くタグへ引き上げることです。

この作業は、行を洗い出し、Actionごとに「どのタグからNode 24になるか」を調べ、書き換えて、動作を確かめる流れになります。洗い出しと書き換えはClaude Codeが得意な機械作業です。ただし、タグの境目はActionごとにずれていて、v5に上げれば済むとは限りません。

Node 20の廃止はいつ何が変わるのか

除去日は告知の公開後に何度か後ろへずれ、最終的に2026年9月23日と書き換えられました。除去が実際に走ったrunnerでは、Node 20宣言のActionは動きません。日付よりも、手元のworkflowに「Node 20で動くAction」が残っているかどうかが、いま失敗するかを決めます。

Node 20のまま使い続けるための逃げ道も用意されていました。ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=trueをworkflowのenvかrunnerの環境変数に置くと、6月16日以降もNode 20を使えます。ただし告知は、この設定が効くのはNode 20の除去までだと書いています。逃げ道は期限付きで、恒久策にはなりません。

更新の前に壊れる箇所を見つけたいときは、FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=trueをenvに置きます。Node 20宣言のActionもNode 24で強制的に動かせます。1つのworkflowだけで試す最小の形は次のとおりです。

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
    steps:
      - uses: actions/checkout@v4

このjobで失敗したステップのActionが、先にタグを上げる対象です。確かめ終えたらenvの行は消します。

自分のworkflowで対象を洗い出す

最初に、リポジトリが使っているActionとそのタグを一覧にします。対象は.github/workflowsだけではありません。自作のcomposite actionを.github/actionsに置いているなら、そちらのuses:も対象です。

grep -rhoE 'uses: *[^ #]+' .github \
  | sed -E 's/uses: *//' | sort | uniq -c | sort -rn

出力は「何回使われているか、どのActionのどのタグか」の一覧になります。actions/checkout@v4が20行、actions/upload-artifact@v4が6行、というように並びます。

ローカルアクション(./.github/actions/...)とDockerイメージ参照(docker://...)も混ざります。この2つはタグを持たないので、一覧から外しておくと見通しがよくなります。

grep -rhoE 'uses: *[^ #]+' .github \
  | sed -E 's/uses: *//' \
  | grep -vE '^(\./|docker://)' | sort | uniq -c | sort -rn

コミットSHAで固定している行は、uses: actions/checkout@<40桁のSHA> # v5のように、末尾のコメントにタグを書く形がよく使われます。この形の行は、タグだけ書き換えてもSHAが古いまま残ります。選んだタグに対応するSHAへ置き換え、コメントのタグも合わせて更新します。

Claude Codeに任せるなら、この一覧そのものを作らせるのが入口です。後述のプロンプトでも、最初のステップとして「uses:の一覧を作り、各Actionのaction.ymlを見てNode 20宣言のものを選ぶ」ことを指示します。

どのタグからNode 24になるか

Actionが何で動くかは、タグ時点のaction.ymlのruns.usingに書かれています。境目はこの値で決まります。主要なActionでは次のとおりです。

表の値は各タグのaction.ymlにあるruns.usingです。新しいタグが出たら、同じ箇所を見れば判定できます。上げる前に、対象タグのaction.ymlを開いて確かめてください。

Claude Code公式Actionは何で動くか

anthropics/claude-code-action@v1は、action.ymlのruns.usingがcompositeです。Node上で直接動くActionではなく、内側のステップを順に実行する形です。内側ではoven-sh/setup-bunをコミットSHAで固定して呼んでおり、そのタグ(v2.2.0)のruns.usingはnode24でした。

つまり、claude-code-action@v1の行は書き換えずに済みます。Claude Codeの公式ドキュメントのサンプルはactions/checkout@v6とanthropics/claude-code-action@v1の組み合わせで、こちらも追加の手当てが要りません。更新が必要になるのは、サンプルを写す前から使っていたactions/checkout@v4などの行です。

/batchでworkflowを一括更新する

/batchは、コードベース全体に及ぶ変更を5〜30の独立したユニットに分け、計画を見せてから、ユニットごとにバックグラウンドのサブエージェントをworktreeで隔離して走らせる組み込みスキルです。各サブエージェントが実装し、テストを走らせ、変更を公開します。コマンドの全体像は/batchの解説にあります。

ここでの使い分けは次のとおりです。

• workflowが数ファイル、uses:が十数行なら、ユニットに割るより、Claude Codeへ普通に頼むほうが速い
• workflowが数十ファイルあり、build・test・deployが別々に管理されているなら、ファイル群ごとにユニットを切る意味が出る

複数のリポジトリにまたがる場合は、/batchが分けるのが1つのリポジトリの中だけなので、リポジトリごとにセッションを開きます。

/batch .github 配下の全 workflow と composite action の uses: を、
Node 24 で動くタグへ引き上げる。
手順:
1. uses: の一覧を作る
2. 各 Action の action.yml を取得し、runs.using が node24 のタグを選ぶ
   (一つ上げれば足りるとは限らない。判定は runs.using で行う)
3. SHA 固定の行は、選んだタグに対応する SHA に置き換え、コメントのタグも更新する
4. 自作の composite action も同様に確認する
5. 変更後に actionlint を実行して結果を報告する

/batchは計画を出してから実行に入ります。そこでユニットの切り方を見ます。ファイル単位で切られていると、同じActionを複数のユニットが別々のタグへ書き換え、PRを統合したときに食い違いかねません。Action単位で切るよう、計画の段階で指示を足してください。

PRはユニットの数だけ並ぶので、レビューの負荷が先に来ます。更新が機械的な1行差し替えばかりなら、1PRにまとめるよう頼む選択肢もあります。

書き換えの検証にactionlintを使う

書き換えた後に、YAMLの構文や入力名の誤りを機械で拾っておくと、レビューが楽になります。actionlintをhookで走らせる設定を入れておけば、/batchの各サブエージェントが編集のたびに検証できます。

引き上げの前に確かめる条件

Node 24対応のタグは、動作条件も変わっています。

self-hosted runnerを使っているチームは、タグの引き上げより先にrunnerのバージョンとOSを確認します。順番を逆にすると、書き換えたworkflowがrunnerで起動しなくなります。

手順のまとめ

依存の更新を継続的に受けたいなら、RenovateやDependabotの更新PRをClaude Codeで検証する運用に組み込む形もあります。一度きりの引き上げは/batch、以降の追随はbotに任せる、という分担です。

Claude Code自身をGitHub Actionsに組み込む手順はClaude CodeをGitHub Actionsに組み込む解説に、claude_argsなどの入力はパラメータとclaude_argsの渡し方にあります。