脆弱性対応は「上げるだけ」で終わらせない。Next.jsを安全に上げる夜の手順

今夜のひとこと

夜、コーヒー片手にチェックリストを眺めていたら、ふと思った。バージョンを上げる作業って、やること自体は地味なのに、なぜか後回しにしがちだ。たぶん「動いているものを触りたくない」気持ちのせいだと思う。でも、触らないリスクの方が大きい日もある。

今夜の話：今朝のニュースの「実践編」です

今朝の記事では、Node.jsとNext.jsの脆弱性と修正バージョンを紹介した。今夜はその続き。明日の仕事でそのまま使えるよう、手順に落とし込む。対象バージョンの詳細は今朝の記事を参照してほしい。ここでは「どう上げるか」に絞る。

手順1：まず対象をはっきりさせる

`node -v`でNode.jsのバージョンを確認し、プロジェクトの`package.json`でNext.jsのバージョンを見る。画像ライブラリのsharpは、自分で入れた覚えがなくても間接的に入っていることがあるので、`npm ls sharp`でも確認する。対象かどうか分からないまま上げないこと。これが最初の分かれ道だ。

手順2：作業は別ブランチで、変更は小さく

脆弱性対応と機能追加は混ぜない。別ブランチで上げて、lockfileごとコミットする。レビューする人が「何を上げたか」を一目で分かる状態にしておくと、後からの確認も楽になる。

手順3：検証は「ビルド＋主要画面＋画像」

ビルドが通ること、トップ・一覧・詳細など主要な画面が表示されること、そして画像が表示されること。sharpが絡む修正なら、画像まわりは必ず見る。ここを飛ばして本番に上げるのが一番危ない。

手順4：本番は「戻せる状態」で上げる

デプロイ前の状態に戻せることを確認してから上げる。上げたあとは主要な画面をもう一度見て、エラー監視に異常がないか確認する。上げることより、戻せることの方が大事だと思っている。

手順5：最後にチームへ共有メモを残す

上げたバージョン、確認した画面、残っている課題を短く残す。次に同じ対応をする人が迷わない。これをやるかどうかで、チームの対応速度はだいぶ変わる。

車の世界で言うと…

車の部品交換は、交換して終わりじゃない。組み付けたあとに検査して、試走して、記録を残す。Webのアップデートも同じで、「上げた」ことより「確認して、戻せる状態にした」ことの方が大事だと思っている。自動車業界に12年いた身としては、この感覚はそのまま通用する。

相棒キャラNibbleの一言

「チェックリスト、最後の1行まで埋まった？ ぼくは見てるだけだけど、応援してるよ。」

※本記事は2026年10月26日時点の情報です。対象バージョンの詳細は今朝の記事と各公式発表をご確認ください。