みなさん、こんにちは。
昨年の8月、当サイトで「Node.js 18から22へのアップグレード手順」をご紹介しました。
「これでしばらくは平和だ」と思っていたのも束の間、AWSからまたしても「例のメール」が届きました。
「[Action Required] AWS Lambda Node.js 20.x end-of-life」
Node.js 20.xのサポートが2026年4月30日に終了するとのことです。Lambdaの世界では、ランタイムのバージョンアップは避けて通れない「恒例行事」のようなものです。
今日は2026年3月12日。Node.js 20.xのサポート終了（EOL）である2026年4月30日まで、残された時間はあと約1か月半しかありません。
「まだ動いているし、期限が過ぎたとしても、編集不可になる9月30日までは半年も時間がある」と油断していると、気づいた時に「スキルのバグを直したいのにLambdaが編集不可になっていて詰んだ」という悪夢が現実になります。
今回は、20→24への移行を最小限の工数かつ「無事故」で終わらせるためのポイントをまとめました。
朗報 – コード修正は「0行」でいける！
今回の移行における最大の救いは、コードの書き換えがほぼ不要だということです。
振り返ってみれば、前回の18→22への移行は地獄でした。CommonJS（require）からES Modules（import）への変換、async/awaitへの全面的な書き換えなど、コードベース全体に手を入れる「大手術」が必要だったからです。
しかし、すでにNode.js 20でモダンなESM環境に移行済みであれば、最新のNode.js 24.x環境でもそのまま動作します。AIにコードの変換を頼む必要も、深夜にデバッグで頭を抱える必要もありません。今回はコードではなく、「インフラ設定の引っ越し」こそがメインイベントです。
Lambdaレイヤーの「使い回し」にはひと工夫が必要
aws-sdk-client-s3やopenaiなどのライブラリを「Lambdaレイヤー」に切り出して共通化している方は多いはずです。これらのバイナリ資産もそのまま使えますが、AWSコンソール上での「設定」には注意が必要です。
互換性ランタイムの罠
レイヤーには「このレイヤーがどのNode.jsバージョンで動作するか」を定義する「対応ランタイム」という属性があります。20.x専用として登録していたレイヤーは、そのままでは新しい24.xの関数から参照することができません。
「力技」で最速対応
私は以下の手順で、再ビルドなしの最短移行を行いました。
- 既存のレイヤーZIPファイルをそのまま手元に用意する（または再ダウンロード）
- 同じZIPファイルを新しいバージョンとして再アップロードする
- 互換性のあるランタイムとして「20.x」「22.x」「24.x」のすべてにチェックを入れて保存する
これでライブラリをビルドし直すことなく、最新の24.x環境に「互換レイヤー」として紐付けることが可能になります。
【重要】新規作成時にハマる「4つの死角」
既存の関数のランタイムを直接書き換えることも可能ですが、万が一の切り戻しを考えると、「新しい関数を24.xで作って、設定をコピーする」方が安全です。しかし、この際に「うっかり」忘れがちなポイントが4つあります。
① IAM権限（実行ロール）の紐付け
これが最大の落とし穴です。新しい関数を作った直後は、デフォルトの権限しかありません。
- 対策： 新しい関数の「設定」タブから、既存の（Node.js 20で使っていた）実行ロールをそのまま選択してください。新規でロールを作成してしまうと、S3の読み書きやログ出力のポリシーを当て忘れて、「コードは合っているのに動かない」という沼にハマります。
② Alexaエンドポイント（ARN）の更新
関数を新しく作れば、ARN（Amazon Resource Name）が物理的に変わります。
- Alexa側： 開発者コンソールの「エンドポイント」設定を、新しい関数のARNに上書きする。
- Lambda側： 新しい関数に「Alexa Skills Kit」のトリガーを追加し、スキルIDを正しく許可する。
これを忘れると、Alexaに話しかけても「スキルから応答がありません」と冷たくあしらわれることになります。
③ 環境変数の完全コピー
APIキーや接続文字列などを「環境変数」に入れている場合、それらは新しい関数では空っぽです。旧関数の設定画面からコピーして、新しい関数へ移植しましょう。
④ タイムアウトとメモリの同期
Lambdaの初期設定（3秒 / 128MB）のまま運用すると、OpenAIなどの外部APIを叩くスキルは高確率でタイムアウトします。旧関数でチューニングした設定値（例：60秒 / 512MB）を正確に反映させるのを忘れないでください。
動作テスト – 確証を得るための一工夫
切り替えが終わったら、Alexa実機、または開発者コンソールのテスト画面で動作確認をします。
今回はコード変更がないのでスムーズなはずですが、慎重を期すならコードの冒頭に以下を仕込んでおきましょう。
console.log("Runtime Check: Running on Node.js 24 environment");
CloudWatch Logsでこの文字が確認できれば、「間違いなく新しい環境が動いている」という確証が得られます。
後始末 – 古い関数の「掃除」を忘れずに
新しい環境での動作が安定したら、古いNode.js 20.xの関数は削除するか、少なくとも名前を OLD_ などに変えておきましょう。
AWSのスケジュールでは、4月30日のEOL後も2026年9月30日までは既存関数の更新が可能ですが、それ以降は完全に編集ができなくなります。「9月までまだあるから」と放置しておくと、その存在自体を忘れ、いざ障害が起きた時に「どれが本番だっけ？」と混乱を招くだけです。鉄は熱いうちに、掃除は動いているうちに、です。
後回しにせず作業を開始しましょう！
今回の移行は、ほとんどの人にとって「コードはそのまま、設定を丁寧にコピーする」だけの作業です。慣れていれば1関数あたり15分程度で終わります。
しかし、4月30日が近づくと、他のスキルの対応が重なったり、思わぬ権限トラブルで時間を取られたりと、焦りが生まれます。1か月半という時間は、エンジニアの感覚では「明日」も同然です。
9月29日の夜、編集不可になる直前に冷や汗をかかないために、この記事を読み終えた「今」、まずは1つ目のスキルの移行を終わらせてしまいましょう！
本日も最後までお読みいただきありがとうございました。
それでは、よいAlexaライフを！
