「使っているライブラリに脆弱性が見つかりました。至急アップデートをお願いします」。運用中のサイトを持っている会社には、この連絡が突然届きます。
そこで調べて分かるのが、そのバージョンはすでにサポート終了で、修正版が出ないという事実です。修正版が出ないということは、対応が「更新」ではなく「移行」になるという意味です。見積もりの桁が変わります。
2026年6月に出た React Router v8 は、この構図を考えるのにちょうどよい題材です。開発チーム自身が「できるだけ退屈にする」と表現したリリースでありながら、同時に2つのバージョンのセキュリティ更新が止まりました。
「退屈な」リリースでも、止まるところは決まっている
React Router v8 は2026年6月17日にリリースされました。v7 で用意されていた将来向けフラグ（middleware、Vite env API、Split Route Modules など）がすべて既定値になり、splitRouteModules はトップレベルの設定項目として既定で有効になりました。v7 からの更新は容易だと案内されています。
破壊的変更としてまとまっているのは、実質的に前提環境の引き上げです。
- ESM 専用での配布（tsconfig の target と lib は ES2022 へ）
- Node.js 22.22.0 以上
- React 19.2.7 以上
- Vite 7 以上
これらは「コードの書き換え」ではなく「動く場所の切り替え」です。 アプリケーションのソースを1行も直さなくても、CI で使っている Node のバージョンが古ければビルドは通りません。ESM 専用の配布になれば、CommonJS の require を前提にしている周辺ツールや設定ファイルが落ちます。
見積もりが跳ねるのはここです。変更点の一覧が短いことと、更新作業が軽いことは別の話で、前提環境の引き上げは影響範囲がプロジェクト全体に及びます。
本当に効くのは、旧版の終了のほう
同じリリースで、React Router v6 と Remix v2 が End of Life になりました。どちらも今後セキュリティ更新を受け取りません。
運用側から見ると、この一行のほうが実務的な意味を持ちます。
| 状態 | 脆弱性が出たときの選択肢 |
|---|---|
| サポート中の版を使っている | パッチ版へ更新する |
| サポート終了の版を使っている | サポート中の版へ移行する。回避策を自前で作る |
上の行なら数時間から数日で片が付きます。下の行はメジャーバージョンをまたぐ移行になり、規模によっては数週間の工程になります。脆弱性が公表されてからこの差に気づくと、選べる選択肢が「急いで移行する」しか残りません。
そして厄介なのは、EOL は事前に告知されているのに、運用中のサイトを持っている側にそれを見に行く習慣がないことです。フレームワークのブログを毎月読んでいる発注者はまずいません。
サポート期限は、どこを見れば分かるか
「一覧を出してください」と言われた側が困らないよう、確認できる場所も挙げておきます。特別なツールは要りません。
パッケージ自身のリリース情報。 メジャーバージョンのリリース記事に、旧版の扱いが書かれていることがほとんどです。React Router の場合も、v8 の告知に v6 と Remix v2 の End of Life が明記されていました。新しい版の告知は、同時に古い版の終了告知でもあるという読み方をすると、見落としが減ります。
実行環境のリリーススケジュール。 Node.js のように、バージョンごとのサポート期限が事前に公開されているものもあります。フレームワークが要求する下限は、この期限に引きずられて動きます。
依存関係の一覧そのもの。 npm ls --depth=0 で直接依存しているパッケージとバージョンが出ます。ここに並んだものだけでも把握できていれば、脆弱性情報が出たときに自社が該当するかを即座に判断できます。
大事なのは網羅性より更新頻度です。 直接依存だけの粗い一覧でも、年1回更新されていれば実務では十分に機能します。完璧な一覧を1度だけ作って放置するより、価値が続きます。
年1回のメジャーは、保守側に予定を作れる
React Router は年次のリリースサイクルへ移行すると表明しています。これは受け取る側にとって悪い話ではありません。いつ来るか分からない変更より、年1回と決まっている変更のほうが予算を組めます。
保守契約の中で扱うなら、次の形に落とすのが現実的です。
- 主要な依存パッケージについて、現在使用中のバージョンとサポート期限を一覧にする
- 年1回、その一覧を更新して発注者に共有する
- サポート終了の6か月前に、更新か移行かの判断をする場を設ける
3番目が肝心です。期限の直前に判断すると、選択肢が減った状態で決めることになります。 半年前なら、機能追加の案件と抱き合わせて工程を組む、といった選び方ができます。
保守費の内訳が見えないという話は保守費の値上げ理由がCI費用だったときにも書きましたが、依存パッケージの世代管理も同じで、契約書に書かれていない作業は誰もやらないまま時間だけが進みます。
保守契約に足しておく3行
依存パッケージの更新をめぐる往復は、契約段階の記述で大きく減らせます。書き足しておく価値があるのは次の3点です。
バージョン一覧の提出と更新頻度。 何をどのバージョンで使っているかが分からないと、脆弱性情報が出ても自社が該当するかを判断できません。年1回でも一覧があるだけで違います。
サポート終了の通知義務。 「使用中のパッケージがサポート終了を迎える場合、判明時点で通知する」。この一行があると、通知が来ないまま EOL を過ぎる事態を防げます。
更新と移行の切り分け。 パッチ版への更新は保守の範囲、メジャーバージョンをまたぐ移行は別途見積もり、というようにどこからが追加費用かを先に決めておくと、いざというときの交渉が短く済みます。
依存パッケージそのもののリスクについては、npm 12 で install スクリプトが既定オフになった件も合わせて参考にしてください。更新の頻度を上げるほど、更新そのものが攻撃面になるという別の論点が出てきます。
次にやること
運用中のサイトやシステムがあるなら、保守を委託している会社に「いま使っているフレームワークとその主要な依存のバージョン、およびサポート期限」を一覧で出してもらってください。 出てこない場合、それ自体が現状を示しています。
一覧が手元にあるなら、サポート終了までの残り期間が1年を切っているものだけを抜き出してください。 そこが次の予算に載せるべき範囲です。全部を一度に更新する必要はありません。
既存システムの依存関係の棚卸し、フレームワークのバージョン移行、保守体制の設計については、グリームハブの開発・AI・自動化のご相談で承っています。構成と規模によって工程が変わるため、個別にご相談ください。お問い合わせからどうぞ。
