「うちのサイトで使っているフレームワーク、まだ大丈夫ですか」。発注側がこう尋ねるとき、聞きたいのは技術の優劣ではなく、来期の予算に移行費を積む必要があるのかという一点です。
SolidStartで起きたことは、その判断の練習に向いています。2026年8月4日に2.0の安定版が出て、その約1週間後に、フレームワーク自体は今後、保守リリースだけを続けると案内されました。新しいバージョンが出たのに役割は終わりに向かう、という一見ちぐはぐな状況です。
何が起きたのか
2.0では、Solid 1のアプリ向けに、これまで別途使っていたビルド調整の層（Vinxi）を外し、ViteのEnvironment APIを直接使う構成になりました。動かすにはNode.js 24以上とVite 8が必要で、設定の置き場所も app.config.ts から vite.config.ts へ移ります。
8月中旬に公開されたSolid 2.0のリリース候補の告知では、サーバー関数がコアの機能になり、配信の層は新しい「start mode」へ、ファイルベースのルーティングは特定のルーターに依存しない別パッケージへ移ったと説明されています。そのうえで、start modeがSolidStartを置き換えるとされました。今SolidStartを本番で使っていても壊れるものはなく、SolidStartには保守リリースが続き、移行ガイドも公開されています。Solid 2.0自体は、2026年9月24日時点でまだリリース候補の段階です。
「保守モード」を3段階に分けて読む
告知の言葉だけで慌てないために、状態を分けます。
| 状態 | 実際に起きること | 発注側の判断 |
|---|---|---|
| 新機能が止まる | 今動いている機能はそのまま | 予算化は不要。次の改修時に検討 |
| 保守リリースのみ | 不具合・脆弱性の修正は届く | 移行の見積りだけ取っておく |
| 更新が止まる | 依存する言語・ビルドの更新に追随できない | 期限を決めて移行する |
今回のSolidStartは真ん中の段階です。ここで全面的な作り直しを提案されたら、根拠を確認してください。作り直しが必要になるのは、たいていフレームワーク本体ではなく、周辺の依存が先に動けなくなったときです。
効いてくるのは、周辺の必須条件
2.0がNode.js 24以上を求める点は、実務ではフレームワークの話より重く出ます。古いNodeのまま止まっているサーバー、CIのイメージ、ホスティングの対応状況が、そのまま移行可否を決めます。
見積りを取るときは、次の単位で分けて出してもらうと比較できます。
- 設定ファイルの移動と、ビルドが通るまでの作業
- Node・Viteの前提を満たすための実行環境側の作業
- 使っているプラグイン・ライブラリで、対応していないものの置き換え
- 表示・フォームなど、利用者に見える部分の確認作業
「一式でいくら」の見積りは、どこが重いのかを隠します。4つに分かれていれば、今期にやる範囲と来期に回す範囲を発注側で決められます。
もう1つ確認しておくのは、セキュリティ更新が届く経路です。フレームワーク本体が保守リリースを続けていても、依存しているライブラリ側が先に更新を止めることがあります。脆弱性の通知を誰が受け取り、誰が影響を判断するのかが決まっていない状態は、バージョンの新旧よりも実害に近い問題です。
依存の寿命は、契約書側に書いておく
フレームワークの終了予定は、制作を発注した時点では誰にも分かりません。決められるのは、終了が告知されたときに誰が何をするかです。保守契約に、使用している主要な依存の一覧と、更新終了が告知された場合の連絡・見積りの手順を入れておくと、判断が属人的になりません。
同じ構図は他でも起きています。CDNのバージョン指定が変わった例はhtmx 4.0の更新制御、開発元の体制が変わった例はTailwindの買収と依存の中身で扱いました。ビルド基盤側の動きはViteの統合ツールチェーンにまとめています。
今週やるとしたら、棚卸しだけ
移行の前に、自社サイトが何に乗っているかを一覧にします。フレームワークとそのバージョン、Nodeのバージョン、ホスティング、ビルドの実行場所、主要なプラグイン。この一覧があるだけで、次に同じ告知が出たときの初動が変わります。
2026年9月24日に、SolidStart 2.0の安定版の告知、Solid 2.0のリリース候補の告知、npmの公開履歴を確認して整理した調査記事です。SolidStart 2.0への移行作業やビルドの実行は行っていません。移行手順の詳細は公式の移行ガイドを確認してください。
使っているフレームワークの棚卸しや、移行範囲の切り分けは、グリームハブへご相談ください。
